From axelinux at hotmail.com  Thu Nov  1 00:23:56 2007
From: axelinux at hotmail.com (axel @ieee.org)
Date: Thu, 1 Nov 2007 02:23:56 +0200
Subject: FutureFeature - Split KDE packages
Message-ID: <BLU112-W29B3EAA49ED49460002913D58C0@phx.gbl>


Maybe a few days before the official release of Fedora 8 isn't the right time to discuss this matter but I'll give it a try.

I know that Fedora is a Gnome based distribution but I prefer using KDE instead. However one thing that I don't like about KDE is that it installs in your system many programs that you don't really need or want. Of course this happens because that's how KDE packages come from kde.org I believe e.g. kdemultimedia, kdenetwork

I think it would be a good idea to split those big packges into smaller/seperate ones. This way users will be able to install only the utilities they want. To understand better what I mean take a look at the following links from archlinux and gentoo.

http://kdemod.ath.cx/features.html
http://www.gentoo.org/doc/en/kde-split-ebuilds.xml

One more thing is that KDE menus have the same programs in more than one categories. Not a very good way to organize your pc. There are a lot of entries that show up in the Administration, System, and Settings menus.

I don't know how difficult or easy would be to spli the kde packages but I believe it would be a good idea. Maybe this could be done if not for KDE3 for KDE4 which is a few months away.

What do you think?

Regards,
axel
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us



From kevin.kofler at chello.at  Thu Nov  1 00:50:15 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 1 Nov 2007 00:50:15 +0000 (UTC)
Subject: FutureFeature - Split KDE packages
References: <BLU112-W29B3EAA49ED49460002913D58C0@phx.gbl>
Message-ID: <loom.20071101T004220-28@post.gmane.org>

axel @ieee.org <axelinux <at> hotmail.com> writes:
> Maybe a few days before the official release of Fedora 8 isn't the right time
> to discuss this matter but I'll give it a try.

Obviously new features won't make it into F8, they might be considered for F9 
though.

> I know that Fedora is a Gnome based distribution but I prefer using KDE
> instead.

That's why there's a KDE SIG (Special Interest Group). :-)

> I think it would be a good idea to split those big packges into
> smaller/seperate ones. This way users will be able to install only the
> utilities they want.

This has come up in our KDE SIG IRC meetings already, and I'm afraid the 
consensus was that it is not desirable, it would be a PITA to maintain. What we 
did is split the less used apps of some components into -extras subpackages 
which are not installed on the live CD.

> One more thing is that KDE menus have the same programs in more than one
> categories. Not a very good way to organize your pc. There are a lot of
> entries that show up in the Administration, System, and Settings menus.

Those are bugs in the respective programs (their menu entries have too many 
categories), we have filed bugs for all those we know about. If you notice a 
duplicate, please first check RH Bugzilla to see if it has already been filed, 
if not file a bug there.

        Kevin Kofler



From airlied at redhat.com  Thu Nov  1 12:22:04 2007
From: airlied at redhat.com (Dave Airlie)
Date: Thu, 01 Nov 2007 22:22:04 +1000
Subject: KDE logout options with F8
In-Reply-To: <20071031091902.101120@gmx.net>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<20071031091902.101120@gmx.net>
Message-ID: <1193919724.3113.2.camel@clockmaker.usersys.redhat.com>

On Wed, 2007-10-31 at 10:19 +0100, Joachim Frieben wrote:
> > gdm is the default login manager in the base X group. It can't
> > be removed from there.
> > 
> > Bill
> 
> Rahul's position on this seems to be more coherent. When you want a
> plain X environment without GNOME nor KDE [and haven't selected any of
> both at install and -only- then], you simply don't want to get
> bothered by any of overloaded GDM and KDM with face browser stuff and
> the like and pulling in tons of additional packages you don't want to
> have installed either.
> XDM is a perfectly valuable and lightweight login manager. Why
> wouldn't it be a valid choice when it's even shipped by upstream Xorg?

Please don't drag upstream X.org into this, xdm is a horror upstream is
glad gdm/kdm exist and merely continue shipping xdm as something for
system builders..

it isn't valuable or valid.

Dave.



From poelstra at redhat.com  Thu Nov  1 02:41:03 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 31 Oct 2007 19:41:03 -0700
Subject: F9 Feature Process
Message-ID: <47293CBF.7020900@redhat.com>

After FESCo discusses and votes on the new development process proposed by Jesse Keating at http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal tomorrow I would start a new discussion culminating in a vote by FESCo one week from now (November 8) as to how we want the Feature process to work for Fedora 9.

I gave some initial thoughts are here: http://poelcat.wordpress.com/2007/10/16/fedora-8-feature-retrospective/

Overall I believe we can roll most of the process forward for F9, however a few tweaks and clarifications to the process will help things run smoother and make my job easier because then I can help guide the process in a way that is consistent with what everyone wants and agrees to.

The current policy is here: http://fedoraproject.org/wiki/Features/Policy

To start the discussion, I have listed the specific issues I think need to be addressed.  Other input and opinions are welcome too!  I think this threads the conversation better and keeps all the information in one place.

http://fedoraproject.org/wiki/Features/F9PolicyReview.

Thanks,
John


~~~~~~~~~~~~~~ Quick Overview if you don't want to visit the wiki ~~~~~~~~~~~~~~~~~~~~

Here are some of the big issues from my perspectiveones:

1) What is a FEATURE and how should the policy be clarified http://fedoraproject.org/wiki/Features/Policy#definition
  -considering that anyone can commit new code and packages to Fedora what is unique about a feature?
  -it is waste of everyone's time to have someone create a feature page and then for FESCo to say "denied--that isn't a feature"

2) Do we have common agreement on the purpose of creating a feature page?
  -marketing?
  -testing?
  -release notes?
  -other?
  -all of the above?

3) What if someone creates a nice enhancement to Fedora that is new in the upcoming release but no feature page is created for it?  For example, system-config-firewall in F8.

To someone not familiar with Fedora wouldn't they expect http://fedoraproject.org/wiki/Releases/8/FeatureList and http://fedoraproject.org/wiki/Releases/8/ReleaseSummary to contain the same information or for there to only be one page? The ReleaseSummary page is really good by the way!

4) How do we (realistically) encourage people to keep their feature pages up to date?  It was a pain to keep hounding people to keep the status of their pages up to date--very few people kept them updated every 2 weeks.  Considering how short our release cycle is I don't think we can go much longer than that.

5) What does "Feature Freeze" really mean? 
  --Do we want to be more disciplined? If we aren't feature frozen are we willing to move the end of the schedule to allow adequate testing time?
  --What is the point of having a milestone that we don't really follow?

6) What if a feature is not ''complete'' at Feature Freeze?  
  -How do we decide to drop it versus give it more time?

7) How do we define a feature as ''complete''?



From mclasen at redhat.com  Thu Nov  1 03:34:20 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 31 Oct 2007 23:34:20 -0400
Subject: F9 Feature Process
In-Reply-To: <47293CBF.7020900@redhat.com>
References: <47293CBF.7020900@redhat.com>
Message-ID: <1193888060.4875.24.camel@localhost.localdomain>


On Wed, 2007-10-31 at 19:41 -0700, John Poelstra wrote:

> ~~~~~~~~~~~~~~ Quick Overview if you don't want to visit the wiki ~~~~~~~~~~~~~~~~~~~~
> 
> Here are some of the big issues from my perspectiveones:
> 
> 1) What is a FEATURE and how should the policy be clarified http://fedoraproject.org/wiki/Features/Policy#definition
>   -considering that anyone can commit new code and packages to Fedora what is unique about a feature?
>   -it is waste of everyone's time to have someone create a feature page and then for FESCo to say "denied--that isn't a feature

I think it is worth making it more explicit that there are different
kinds of features. Something like "replace program a with program b" or
"rewrite program c" (examples are esd -> pulseaudio, or NM) is very
different from "gradually improve fedora wrt. to foo" (examples are
better laptop support, less power consumption). For the former, it makes
sense to have a contingency plan, which will usually be "stay with the
old version". For the latter, it is fine to just do as much as you get
done for this release, and continue improving the situation afterwards.
For the gradual improvement type features, the main question at feature
freeze time is if we have achieved enough of an improvement to make a
big splash about it.


> 2) Do we have common agreement on the purpose of creating a feature page?
>   -marketing?
>   -testing?
>   -release notes?
>   -other
>   -all of the above?

Pretty much all of the above, I'd say, plus some more
    - developer synchronization if several people work on a feature
    - cross-distro and upstream communication; I find it e.g. a big 
      help to look at Ubuntu blueprints occasionally to see how their
      plans line up with ours


> To someone not familiar with Fedora wouldn't they expect http://fedoraproject.org/wiki/Releases/8/FeatureList
> and http://fedoraproject.org/wiki/Releases/8/ReleaseSummary to contain the same information or for there to only 
> be one page? The ReleaseSummary page is really good by the way!

I would expect FeatureList to be the starting point, and ReleaseSummary
the end result of turning it into a shiny and attractive document.


> 6) What if a feature is not ''complete'' at Feature Freeze?  
>   -How do we decide to drop it versus give it more time?

This really depends on the type of feature; for the gradual features discussed about, dropping them is not very 
meaningful. For "replace existing functionality" or "new stuff" features, dropping could be a possibility, but 
looking at this at feature freeze time is really too late; if we want to be serious about dropping features, we 
need to do closer monitoring of features before the freeze, and ensure that the contingency plans are in place
and that people are aware of the approaching freeze, and don't miss it by accident. 

Out of interest, I didn't see any information about how we did in terms of features that made it in vs features 
that were dropped or deferred in your F8 recap. Did we drop anything, and if so, have you looked at why ?


Matthias



From Axel.Thimm at ATrpms.net  Thu Nov  1 04:46:47 2007
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 1 Nov 2007 06:46:47 +0200
Subject: linux1394 and f8
In-Reply-To: <1193844283.10224.7.camel@localhost6.localdomain6>
References: <47288307.7060306@nostar.net>
	<1193844283.10224.7.camel@localhost6.localdomain6>
Message-ID: <20071101044647.GA16429@puariko.nirvana>

On Wed, Oct 31, 2007 at 09:24:43AM -0600, Richi Plana wrote:
> On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
> > I am running 7.92, and I see that the new firewire stack is in place. 
> > There is a page at the linux1394 wiki that suggests that kernel 
> > packagers build the old stack into the kernel for the time being:
> > 
> > http://wiki.linux1394.org/JujuMigration
> > 
> > Any chance of this happenign for Fedora 8?
> 
> Axel Thimms (of ATRPMS fame) is distributing an ieee1394-kmdl package
> which, I think, is compiled to use the old stack. They are doing it
> because MythTV is incompatible (read: doesn't work) with the new
> firewire stack. The only unfortunate thing is that he is distributing a
> "libraw1394" package (which collides with a package on Fedora) in order
> to provide support for the kernel module. I have suggested using a
> different name for the package and placing the library in a different
> directory (to be loaded by mythtv with LD_LIBRARY_PATH), and hopefully
> that will fix any conflicts with Fedora.

But mythtv is not the only app affected by this - every ffmeg using or
derived project is affected, so half a multimedia system's packages
would have to be special treated for not really any gain.

Even upstream classifies the current state of the stack as "not end
user deployable". So the reasons some advocates of "no replacement"
policies are reversed - the replacement is *less* experimental than
the original and is know to work.

This raises the question about the target audience of Fedora: Early
adoptors means that they are willing to break their systems and aid in
unbreaking them. Unfortunately the true audience is less willing to
see their systems break for a year waiting for a solution.

Is ATrpms damaging Fedora's core cause? Perhaps, as these users are
not building and pressure to get things fixed (same could be said
about the nvidia drivers). But since the main motors of juju are at
Red Hat they don't need and further motivation by screaming end users,
so actually it's good thing for everyone. ;)

> (I just checked and they don't seem to be doing it for F8 but you could
> probably grab the src.rpm and compile it and update it for your kernel.)

Actually you need to swap out the tarball with sources matching F8's
kernel, just rebuilding will most probably not work.

Alternatively Fedora could ship a kernel with both modules and
blacklist the old ones. So users would just need to adjust the
blacklisting config and I would have less work to do :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/66bac8bc/attachment.sig>

From sundaram at fedoraproject.org  Thu Nov  1 04:58:01 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 01 Nov 2007 10:28:01 +0530
Subject: F9 Feature Process
In-Reply-To: <47293CBF.7020900@redhat.com>
References: <47293CBF.7020900@redhat.com>
Message-ID: <47295CD9.9070508@fedoraproject.org>

John Poelstra wrote:

> To someone not familiar with Fedora wouldn't they expect 
> http://fedoraproject.org/wiki/Releases/8/FeatureList and 
> http://fedoraproject.org/wiki/Releases/8/ReleaseSummary to contain the 
> same information or for there to only be one page? The ReleaseSummary 
> page is really good by the way!

Feature list is more developer oriented. Release Summary is a subset of 
the feature list highlighting major features and "themes". If there are 
for example 3 user interface related features, 4 security related ones 
and 2 performance related ones, we want to highlight them together in 
the release summary.  The actual release announcement is sort of like a 
easter language and is not easily translatable and we needed an 
alternative that was closer to a press release. It is in fact the press 
release writing attempt that was combined with the release notes 
overview and morphed into the release summary for Fedora Core 5 and 
since it turned out be fairly successful (a lot of users and reviews 
referenced that), we continue doing it.

Rahul



From bbbush.yuan at gmail.com  Thu Nov  1 05:06:07 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Thu, 1 Nov 2007 13:06:07 +0800
Subject: rawhide report: 20071031 changes
In-Reply-To: <200710311134.l9VBY0Gq027040@porkchop.devel.redhat.com>
References: <200710311134.l9VBY0Gq027040@porkchop.devel.redhat.com>
Message-ID: <76e72f800710312206m39dec493t307a67a4ae3de291@mail.gmail.com>

2007/10/31, Build System <buildsys at redhat.com>:
> New package mknbi
>         Utility for creating network bootable images
>
>
>
> Updated Packages:
>
> NetworkManager-openvpn-1:0.7.0-2.svn3047.fc8
> --------------------------------------------
> * Wed Oct 31 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-2.svn3047.fc8
> - BuildRequire gettext
>
> * Tue Oct 30 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-1.svn3047.fc8
> - Upgrade to trunk, needed to be compatible with NM 0.7.0, rebuild for F-8
>
> OpenEXR-1.6.0-5.fc8
> -------------------
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-5
> - multiarch conflicts in OpenEXR (#342781)
> - don't own %_includedir/OpenEXR (leave that to ilmbase)
>
> QuantLib-0.8.1-4.fc8
> --------------------
> * Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.8.1-4
> - fix more conflicting manpages (bz 322201)
> - fix multilib conflict (bz 343041)
>
> R-2.6.0-3.fc8.1
> ---------------
> * Tue Oct 30 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3.1
> - fix missing perl requires
>
> * Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3
> - fix multilib conflicts (bz 343061)
>
> * Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-2
> - add R CMD javareconf to post (bz 354541)
> - don't pickup bogus perl provides (bz 356071)
> - use xdg-open, drop requires for firefox/evince (bz 351841)
>
> SDL_mixer-1.2.8-4.fc8
> ---------------------
> * Tue Oct 30 2007 Warren Togami <wtogami at redhat.com> - 1.2.8-4
> - SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio directly
>   avoids applications from locking up
>
> anaconda-11.3.0.50-1
> --------------------
> * Wed Oct 31 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.50-1
> - Fix creating users in kickstart (#358901)
>
> * Tue Oct 30 2007 Jeremy Katz <katzj at redhat.com> - 11.3.0.49-1
> - Fix language display (#358411)
> - Avoid dmraid traceback with live installs over previously existing
>   install (#357401)
>
> apollon-1.0.1-12.fc8
> --------------------
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.1-12
> - -libs subpkg, multiarch conflicts in apollon (#340661)
>
> compiz-0.6.2-3.fc8
> ------------------
> * Thu Oct 25 2007 Sebastian Vahl <fedora at deadbabylon.de> - 0.6.2-3
> - Include kde-desktop-effects in kde subpackage
> coreutils-6.9-9.fc8
> -------------------
> * Tue Oct 30 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-9
> - applied upstream patch for runuser to coreutils-selinux.patch(#232652)
> - modified coreutils-i18n.patch because of sort -R in
>   a non C locales(fix by Andreas Schwab) (#249315)
> - allow cp -a to rewrite file on different filesystem(#219900)
>   (based on upstream patch)
> - License tag to GPLv2+
>
> * Thu Oct 25 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-8
> - applied upstream patch for cp and mv(#248591)
>
> * Thu Aug 23 2007 Pete Graner <pgraner at redhat.com> - 6.9-7
> - Fix typo in spec file. (CVS merge conflict leftovers)
>
> dmraid-1.0.0.rc14-4.fc8
> -----------------------
> * Tue Oct 30 2007 Alasdair Kergon <agk at redhat.com> - 1.0.0.rc14-4
> - Fix SEGV on "dmraid -r -E" (bz 236891).
>
> * Wed Apr 18 2007 Peter Jones <pjones at redhat.com> - 1.0.0.rc14-3
> - Fix jmicron name parsing (#219058)
>
> eclipse-1:3.3.0-30.fc8
> ----------------------
> * Tue Oct 30 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-30
> - Actually apply permgen patch.  Ugh.
>
> * Tue Oct 30 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-29
> - Move popd at end of %install to allow aot-compile-rpm to allow it to
>   use the current directory for its temp directory.
>
> * Mon Oct 29 2007 Andrew Overholt <overholt at redhat.com> 3.3.0-28
> - Add patch for memory issues with IcedTea.
>
> em8300-kmod-0.16.3-6.2.6.23.1_42.fc8
> ------------------------------------
> * Wed Oct 31 2007 Ville Skytt? <ville.skytta at iki.fi> - 0.16.3-6
> - Don't run depmod during build even if System.map is available.
> - Run "make install" in verbose mode.
> - Build for kernel 2.6.23.1-42.fc8.
>
> * Thu Oct 18 2007 Ville Skytt? <ville.skytta at iki.fi>
> - Rebuild for kernel 2.6.23.1-23.fc8.
>
> fedora-release-notes-8.0.0-3
> ----------------------------
> * Tue Oct 30 2007 Paul W. Frields <stickster at gmail.com> - 8.0.0-3
> - Fix release number in description
>
> firefox-2.0.0.8-2.fc8
> ---------------------
> * Tue Oct 30 2007 Christopher Aillon <caillon at redhat.com> 2.0.0.8-2
> - Tweak the default backspace behavior to be more in line with
>   GNOME convention, Mozilla upstream, and other distros
>
> gparted-0.3.3-13.fc8
> --------------------
> * Tue Oct 30 2007 Deji Akingunola <dakingun at gmail.com> - 0.3.3-13
> - Fix crash after refresh bug (Bug #309251, patch by Jim Hayward)
> - Fix to use realpath properly (Bug #313281, patch by Jim Hayward)
>
> gtk-nodoka-engine-0.6-5.fc8
> ---------------------------
> * Mon Oct 29 2007 Martin Sourada <martin.sourada at seznam.cz> - 0.6-5
> - fix gimp crashing in some dialogs when using Small theme
>  - rhbz #291121 and rhbz #355931
>
> hal-info-20071030-1.fc8
> -----------------------
> * Tue Oct 30 2007 David Zeuthen <davidz at redhat.com> - 20071030-1.fc8
> - Update to latest upstream release
>
> kaffeine-0.8.5-5.fc8
> --------------------
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.8.5-5
> - multiarch conflicts in kaffeine (#341681)
>
> * Wed Sep 19 2007 Ville Skytt? <ville.skytta at iki.fi> 0.8.5-4
> - Avoid autotools re-run after configure (unclean upstream tarball?)
>
> kdebase-6:3.5.8-5.fc8
> ---------------------
> * Tue Oct 30 2007 Bill Nottingham <notting at redhat.com> - 6:3.5.8-5
> - use correct path for gdm socket, so you get proper options on logout
>   (http://bugs.kde.org/show_bug.cgi?id=149045)
>
> * Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4
> - -libs: Obsoletes: %name ... to help out multilib upgrades
> - -libs conditional (f8+)
>
> * Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-3
> - respin (for openexr-1.6.0)
> - -libs: %post/%postun /sbin/ldconfig
>
> kdegraphics-7:3.5.8-5.fc8
> -------------------------
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-5
> - -libs; Requires: %name (multilib upgrades again)
> - scriptlets fixes
>
> kdemultimedia-6:3.5.8-8.fc8
> ---------------------------
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-8
> - -libs: Requires: %name (multilib upgrades again)
> - scriptlet fixes
>
> kdenetwork-7:3.5.8-4.fc8
> ------------------------
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-4
> - libs: Requires: %{name}... (multilib upgrades)
> - fixup scriptlets
>
> kdevelop-9:3.5.0-4.fc8
> ----------------------
> * Wed Oct 31 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 9:3.5.0-4
> - %post/%postun libs -p /sbin/ldconfig
>
> * Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 9:3.5.0-3
> - -devel, -libs subpkgs, multiarch conflicts (#341791)
>
> kernel-2.6.23.1-42.fc8
> ----------------------
> * Tue Oct 30 2007 Dave Jones <davej at redhat.com>
> - Disable PCI MMCONFIG by default. (Boot with pci=msi if you need it)
>   Works around bz 329241 amongst others.
>
> libglade-1:0.17-20.fc8
> ----------------------
> * Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:0.17-20
> - clarify license as LGPL version 2 or later
> - remove bundled libintl (GPL) in %prep to be absolutely sure that it isn't
>   used
> - patch libglade-config to generate cflags/libs values at runtime instead of
>   build-time and hence be multiarch compatible (#342131); we can get away with
>   this because the entire (legacy) library stack is stable and isn't going to
>   change in any significant way
> - enumerate more of the %files list to narrow scope of wildcards
> - re-encode ChangeLog as UTF-8
> - preserve timestamps for files copied from source to installed package
>
> * Mon Oct 02 2006 Paul Howarth <paul at city-fan.org> 1:0.17-19
> - add new buildreq libtool and use the system libtool instead of the bundled
>   one to avoid /usr/lib64 rpaths
> - add patch to fix non-weak-symbols issues in libglade-gnome.so
> - include epoch in versioned gnome-libs-devel dependencies
>
> * Sat Aug 26 2006 Paul Howarth <paul at city-fan.org> 1:0.17-18
> - include epoch in versioned libxml-devel dependencies
>
> libuser-0.56.6-2
> ----------------
> * Wed Oct 31 2007 Miloslav Trma? <mitr at redhat.com> - 0.56.6-2
> - Fix uninitialized memory usage when SELinux is disabled
>
> mcstrans-0.2.7-1.fc8
> --------------------
> * Tue Oct 30 2007 Steve Conklin <sconklin at redhat.com> 0.2.7-1
> - Fixed a compile error and added compliant init script
>
> * Thu Sep 13 2007 Dan Walsh <dwalsh at redhat.com> 0.2.6-1
> - Check for max_categories and error out
>
> mkinitrd-6.0.19-4.fc8
> ---------------------
> * Tue Oct 30 2007 Peter Jones <pjones at redhat.com> - 6.0.19-4
> - Work around dmraid dependency detection after livecd install.
> - Fix "ide-disk.ko" detection.
>
> nautilus-2.20.0-6.fc8
> ---------------------
> * Tue Oct 30 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-6
> - Fix audio preview command-line to use decodebin so playbin doesn't
>   pop up a window for videos detected as audio
>
> * Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-5
> - Add patch from upstream to get audio preview working again
>   (#332251)
>
> * Wed Oct 03 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
> - Move /usr/lib/nautilus/extensions-1.0 to the extensions package
>
> pulseaudio-0.9.7-0.17.svn20071017.fc8
> -------------------------------------
> * Tue Oct 30 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.7-0.17.svn20071017
> - fix #322481
>
> python-2.5.1-15.fc8
> -------------------
> * Tue Oct 30 2007 James Antill <jantill at redhat.com> - 2.5.1-15
> - Do codec lowercase in C Locale.
> - Resolves: 207134 191096
> - Fix stupid namespacing in pysqlite, minimal upgrade to 2.3.3 pysqlite
> - Resolves: 263221
>
> * Wed Oct 24 2007 James Antill <jantill at redhat.com> - 2.5.1-14
> - Remove bintuils dep. for live CD ... add work around for ctypes
>
> * Mon Oct 22 2007 James Antill <jantill at redhat.com> - 2.5.1-13
> - Add tix buildprereq
> - Add tkinter patch
> - Resolves: #281751
> - Fix ctypes loading of libraries, add requires on binutils
> - Resolves: #307221
> - Possible fix for CVE-2007-4965 possible exploitable integer overflow
> - Resolves: #295971
>
> rhgb-8.0.2-1.fc8
> ----------------
> * Mon Oct 29 2007 Ray Strode <rstrode at redhat.com> 8.0.2-1
> - update to 8.0.2
> - Adds some debugging infrastructure
> - Fixes a potential race condition
>
> selinux-policy-3.0.8-42.fc8
> ---------------------------
> * Tue Oct 30 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-42
> - Make tcbdomain
> - Allow domain domain:fd use
> - Dontaudit rpm_rw_pipes
>
> * Mon Oct 29 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-41
> - Fix labeling on /var/run/bluetoothd_address
> - Allow tmpreaper to search logs directory
>
> synce-gnomevfs-0.9.0-6.fc8
> --------------------------
> * Tue Oct 30 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
> - 0.9.0-6
> - fix BR
>
> system-config-date-1.9.16-1.fc8
> -------------------------------
> * Tue Oct 30 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.16-1
> - use warning dialog, exit gracefully if hwclock fails to allow operation in a
>   XEN guest (#357311)
>
> xapian-core-1.0.2-6.fc8
> -----------------------
> * Thu Oct 25 2007 Adel Gadllah <adel.gadllah at gmail.com> 1.0.2-6
> - Fix multilib conflict in devel package (RH #343471)
>
> Broken deps for i386
> ----------------------------------------------------------
>         kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
>         kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
>
>
>
> Broken deps for x86_64
> ----------------------------------------------------------
>         kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
>
>
>
>
>
>
>
>



  Updating  : selinux-policy               ##################### [ 32/125]
  Updating  : selinux-policy-mls           ##################### [ 33/125]
libsepol.mls_from_string: invalid MLS context s0:
libsepol.mls_from_string: could not construct mls context structure
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert
system_u:object_r:fixed_disk_device_t:s0: to sid
invalid context system_u:object_r:fixed_disk_device_t:s0:
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule:  Failed!
  Updating  : selinux-policy-targeted      ##################### [ 34/125]
libsepol.mls_from_string: invalid MLS context s0:s0
libsepol.mls_from_string: could not construct mls context structure
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert
system_u:object_r:fixed_disk_device_t:s0:s0 to sid
invalid context system_u:object_r:fixed_disk_device_t:s0:s0
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule:  Failed!



-- 
bbbush ^_^



From wtogami at redhat.com  Thu Nov  1 06:14:29 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 01 Nov 2007 02:14:29 -0400
Subject: rose[0-9] interfaces?
Message-ID: <47296EC5.4070903@redhat.com>

Huh?  I resumed from hibernate with kernel-2.6.23.1-42.fc8.x86_64 and I 
noticed these bogus looking devices in iwconfig, ifconfig, and kernel 
module rose loaded.  Any idea what might have loaded this module, or 
what it is?

Warren Togami
wtogami at redhat.com

[root at newcaprica ~]# iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

irda0     no wireless extensions.

tun0      no wireless extensions.

virbr0    no wireless extensions.

rose0     no wireless extensions.

rose1     no wireless extensions.

rose2     no wireless extensions.

rose3     no wireless extensions.

rose4     no wireless extensions.

rose5     no wireless extensions.

rose6     no wireless extensions.

rose7     no wireless extensions.

rose8     no wireless extensions.

rose9     no wireless extensions.

[root at newcaprica ~]# ifconfig rose0
rose0     Link encap:AMPR ROSE  HWaddr 0000000000
           NOARP  MTU:249  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[root at newcaprica ~]# lsmod |grep rose
rose                   57377  0
ax25                   70461  1 rose



From jfrieben at gmx.de  Thu Nov  1 06:49:21 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Thu, 01 Nov 2007 07:49:21 +0100
Subject: KDE logout options with F8
In-Reply-To: <1193919724.3113.2.camel@clockmaker.usersys.redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<20071031091902.101120@gmx.net>
	<1193919724.3113.2.camel@clockmaker.usersys.redhat.com>
Message-ID: <20071101064921.272800@gmx.net>

> Please don't drag upstream X.org into this, xdm is a horror upstream is
> glad gdm/kdm exist and merely continue shipping xdm as something for
> system builders..
> 
> it isn't valuable or valid.
> 
> Dave.

Nevertheless, a user who simply wants a plain X environment is encumbered by packages he hasn't asked for [GDM + GNOME requires] without even the possibility to dismiss them during install.
I suppose that a user who deliberately unchecks GNOME and KDE does know what he wants and does and imposing GDM onto him is against the often cited 'freedom of choice' unless you consider tracking down and uninstalling the related packages by the user post install as a reasonable duty.
I have used XDM for a couple of years back when Red Hat Linux still booted into runlevel 3 by default, and I had no complaints about it.
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail



From aphukan at fedoraproject.org  Thu Nov  1 06:58:40 2007
From: aphukan at fedoraproject.org (Amitakhya Phukan)
Date: Thu, 01 Nov 2007 12:28:40 +0530
Subject: file system mount
Message-ID: <47297920.60509@fedoraproject.org>

hi all!

i have a system with fedora 7 and rhel 5 installed. recently, i changed
the f7 to rawhide. now whenever i boot up, it mounts all the file
systems related to rhel5 along with it and displays on the desktop.
dmesg says /dev/sda1 mounted on /media/_1 and so on. I want to disable
this feature. i don't know if this is anything useful ?? i even don't
know if its a feature or a bug... can any one please help me out with
this thing ? i understand hal is doing this (??), but why ? and even
when i unmount it, the same can still be found in /media. right clicking
on those partitions give me the option of mounting/unmounting them. but
i don't want to let them appear in my rawhide systems totally. anyone
else has this experience on rawhide??how do i disable it ??

thanks in advance.

with regards,
amitakhya phukan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aphukan.vcf
Type: text/x-vcard
Size: 216 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/6d6d4390/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/6d6d4390/attachment.sig>

From david at lovesunix.net  Thu Nov  1 07:14:50 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 01 Nov 2007 08:14:50 +0100
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <64b14b300710270752r68bda22eqfa901c3db7c16e3d@mail.gmail.com>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<5256d0b0710250311x119c24d5k2c2d77c5a202fe7f@mail.gmail.com>
	<64b14b300710251211r5244f124ma62fcb48cf143dd8@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
	<4720F01E.9030802@fedoraproject.org>
	<64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>
	<64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>
	<64b14b300710270720nd4502f4m1c39ae1fb536635c@mail.gmail.com>
	<47234A5F.4000701@fedoraproject.org>
	<64b14b300710270752r68bda22eqfa901c3db7c16e3d@mail.gmail.com>
Message-ID: <1193901290.3048.10.camel@dawkins>


l?r, 27 10 2007 kl. 16:52 +0200, skrev Valent Turkovic:
> On 10/27/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> > Valent Turkovic wrote:
> > > On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> > >> https://core.fluendo.com/gstreamer/trac/ticket/24
> > >> previous link was a duplicate, sorry.
> > >>
> > >> Valent.
> > >>
> > >
> > > This is the reply I got from fluendo support:
> > >
> > >       to              Valent Turkovic <valent.turkovic at gmail.com>
> > >       cc              Fluendo Store Manager <contact at fluendo.com>
> > >       date            Oct 26, 2007 10:42 AM
> > >       subject         Re: Fluendo codecs in Fedora 8?
> > >
> > > Yes we know about that problem and we are pushing Intel everyday to
> > > provide us with a version of IPP that does not do text relocation.
> > >
> > > Sorry for the frustration that it creates.
> >
> > You can consider filing a RFE against SELinux policy to not deny this.
> >
> > Rahul
> >
> 
> Thanks Rahul, I'll try that...

What is the bug number for this?

If we can't make this happen then the Codecbuddy feature kinda falls
apart, requiring the user first to click his way through a dialog then
drop to a shell and invoke SELinux magic in accordance to the "known
issues" page which.. nobody appears to read.

- David, your friend neighborhood QA monkey.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/bb7901c1/attachment.sig>

From lemenkov at gmail.com  Thu Nov  1 07:47:31 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Thu, 1 Nov 2007 10:47:31 +0300
Subject: What's the current status of mp3-licensing issues?
Message-ID: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>

Hello All!
While reading docs for well-known mpg123 I found the following:

=================================
Some notes about patents and mpg123 by Thomas Orgis
---------------------------------------------------

There has been a lot of confusion over mp3 (or more generic mpeg audio)
patents and licensing issues due to the patents held by Fraunhofer and
marketed by Thomson.  So, yes, there are patents held by Fraunhofer
that are claimed to cover mpeg audio technology. There are also claims
that they cover any similar technology (like OGG).  You may argue if
these patents are valid at all (being illegal software patents, or being
preceded by known scientific publications), but they are internationally
accepted by patent authorities and if you want to use mp3 commercially
you should check

        http://www.mp3licensing.org

for the Fraunhofer/Thomson opinion and their terms.

Since mpg123 is only a mpeg audio player, a good deal of patents
that describe the encoding process (the tricky part) will not apply.
Also, statements from the patent holders up to now always allowed the
non-commercial distribution of mpeg audio decoders without any fee.
They want you to pay for a license when you want to make money by selling
a decoder, though. We don't sell mpg123.  Additionally, one should not
forget the fact that the ideas are getting old; the basic (funded by
government, btw.) research was somewhen back around the 80s and many
patents are going to expire soon, best example in Germany:

P/DE 35 06 912 Method of transmission of an audio signal using grouping
of amplitude values

Application was 22.02.1986 in Germany (and around Europe in the same
time Jan/Feb 1986).  German patents last 20 years... now we have
24.07.2006. Time has come...

The idea of a patent is to make the inventor open the invention to
the public by giving him some safe time to turn this invention into
economical benefit.  People using (and improving!) the technology freely
after that time is _the_ most important aspect of that idea.

Oh, I should mention the "core" mp3 patent (from
http://gauss.ffii.org/PatentView/EP287578):

DE 3629434 / EP287578 Digital coding process

Application date in Germany was 29.08.1986 - that means that in a month
from now (remember: 24.07.2006) this patent finds its natural end.

Then, there are other patents listed on the Fraunhofer/Thomson website
that came very late... The one about join stereo coding was applied for
in Feb 1995. Did mpg123 implement that already back then? History is a
bit blurry there...  There is a patent applied for in 1997, but probably
covering encoding only. Still, even if that weren't the case - the basic
decoding functionality of mpg123 didn't change that much after 1997;
and they couldn't have patented existing functionality.  In general,
few patents seem to cover decoders at all. Of course, with me being no
lawyer, that statement is not trustworthy...

Bottom line is:

While Fraunhofer/Thomson don't want to charge free software players -
they said that a long time ago, the time for they being able to place
such charges is expiring or has already expired. One should really think
before adding mp3pro/surround support to mpg123, though, since there
are for sure more recent patents for that.

And don't forget: The progress bar is covered by a patent, too.
=================================

Briefly speaking from the above notes we may find the following:

* Looks like Ogg "violates" patents as well as mp3.
* Fraunhofer patents already expired in Europe.

What about US?

-- 
With best regards!



From sundaram at fedoraproject.org  Thu Nov  1 08:09:01 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 01 Nov 2007 13:39:01 +0530
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
Message-ID: <4729899D.6050600@fedoraproject.org>

Peter Lemenkov wrote:

> that describe the encoding process (the tricky part) will not apply.
> Also, statements from the patent holders up to now always allowed the
> non-commercial distribution of mpeg audio decoders without any fee.

Such non-commercial use restrictions are not compatible with Free and 
open source software or the Fedora licensing guidelines. moreover GPL 
license also requires a written non-limiting patent grant or we can't 
include GPL software that infringes patents on regions that enforce 
patents on software.

> Bottom line is:
> 
> While Fraunhofer/Thomson don't want to charge free software players -
> they said that a long time ago, the time for they being able to place
> such charges is expiring or has already expired. One should really think
> before adding mp3pro/surround support to mpg123, though, since there
> are for sure more recent patents for that.
> 
> And don't forget: The progress bar is covered by a patent, too.
> =================================
> 
> Briefly speaking from the above notes we may find the following:
> 
> * Looks like Ogg "violates" patents as well as mp3.

"Looks" are not enough. The claim should be very specific.

> * Fraunhofer patents already expired in Europe.
> 
> What about US?

http://en.wikipedia.org/wiki/MP3#Licensing_and_patent_issues
http://www.tunequest.org/a-big-list-of-mp3-patents/20070226/
http://www.mp3licensing.com/patents/index.html

Rahul



From giallu at gmail.com  Thu Nov  1 09:10:06 2007
From: giallu at gmail.com (Gianluca Sforna)
Date: Thu, 1 Nov 2007 10:10:06 +0100
Subject: Rebuild sysprof-kmod for final kernel
In-Reply-To: <200710312255.58489.ville.skytta@iki.fi>
References: <d5ad21470710310307k271c7104n1b3aa66c70617077@mail.gmail.com>
	<1193830981.9762.4.camel@localhost.localdomain>
	<200710312255.58489.ville.skytta@iki.fi>
Message-ID: <d5ad21470711010210s56e4c8e2x167fb65f448f944e@mail.gmail.com>

On 10/31/07, Ville Skytt? <ville.skytta at iki.fi> wrote:

> http://cvs.fedora.redhat.com/viewcvs/rpms/em8300-kmod/F-8/em8300-kmod.spec?r1=1.42&r2=1.43&makepatch=1&diff_format=h

Yeah looks like cleaner, but it would probably not work in my case
since I have an hardcoded depmod command in Makefile:

install:
        $(KMAKE) modules_install
        [ -e /sbin/depmod ] && /sbin/depmod


So my option now seems to be:
1. patch Makefile
2. remove (or %exclude) generated files

Thanks for your help



From axelinux at hotmail.com  Thu Nov  1 09:19:34 2007
From: axelinux at hotmail.com (axel @ieee.org)
Date: Thu, 1 Nov 2007 11:19:34 +0200
Subject: FutureFeature - Split KDE packages
In-Reply-To: <loom.20071101T004220-28@post.gmane.org>
References: <BLU112-W29B3EAA49ED49460002913D58C0@phx.gbl>
	<loom.20071101T004220-28@post.gmane.org>
Message-ID: <BLU112-W192A5621E5E713D4CF0A9FD58C0@phx.gbl>


> > I know that Fedora is a Gnome based distribution but I prefer using KDE
> > instead.
> 
> That's why there's a KDE SIG (Special Interest Group). :-)

Sorry, didn't know that. :)
 
> > I think it would be a good idea to split those big packges into
> > smaller/seperate ones. This way users will be able to install only the
> > utilities they want.
> 
> This has come up in our KDE SIG IRC meetings already, and I'm afraid the 
> consensus was that it is not desirable, it would be a PITA to maintain. What we 
> did is split the less used apps of some components into -extras subpackages 
> which are not installed on the live CD.

Ok, I understand.
 
> > One more thing is that KDE menus have the same programs in more than one
> > categories. Not a very good way to organize your pc. There are a lot of
> > entries that show up in the Administration, System, and Settings menus.
> 
> Those are bugs in the respective programs (their menu entries have too many 
> categories), we have filed bugs for all those we know about. If you notice a 
> duplicate, please first check RH Bugzilla to see if it has already been filed, 
> if not file a bug there.

I will take a look on that also. Thanks.

axel

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/b6cb8567/attachment.htm>

From buildsys at redhat.com  Thu Nov  1 09:48:14 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 1 Nov 2007 05:48:14 -0400
Subject: rawhide report: 20071101 changes
Message-ID: <200711010948.lA19mEFd008334@porkchop.devel.redhat.com>

 

 
Updated Packages:

boswars-2.4.1-3.fc8
-------------------

Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From sailer at sailer.dynip.lugs.ch  Thu Nov  1 09:52:09 2007
From: sailer at sailer.dynip.lugs.ch (Thomas Sailer)
Date: Thu, 01 Nov 2007 10:52:09 +0100
Subject: rose[0-9] interfaces?
In-Reply-To: <47296EC5.4070903@redhat.com>
References: <47296EC5.4070903@redhat.com>
Message-ID: <1193910729.29699.11.camel@unreal.localdomain>

On Thu, 2007-11-01 at 02:14 -0400, Warren Togami wrote:
> Huh?  I resumed from hibernate with kernel-2.6.23.1-42.fc8.x86_64 and I 
> noticed these bogus looking devices in iwconfig, ifconfig, and kernel 
> module rose loaded.  Any idea what might have loaded this module, or 
> what it is?

Both AX25 and ROSE are adaptations of the X.25 protocol for use over
(low speed) radio links. See for example:
http://rose.fpac.free.fr/MINI-HOWTO/

ROSE seems to be using an adjustable number of pseudo devices
configurable with the rose_ndevs parameter of the rose module, so these
devices aren't bogus.

I don't know what loaded the module. Maybe one of networking tools like
ifconfig attempting to create a socket with every possible protocol
family and the kernel then autoloading protocol family modules? Now the
question is where you got the rose module. It hasn't been compiled into
redhat kernels for a long time. If you want to avoid these modules being
loaded, you could put:
alias net-pf-3 off
alias net-pf-11 off
into /etc/modprobe.conf.

Tom




From ivazqueznet at gmail.com  Thu Nov  1 09:55:02 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 01 Nov 2007 05:55:02 -0400
Subject: Rebuild sysprof-kmod for final kernel
In-Reply-To: <d5ad21470711010210s56e4c8e2x167fb65f448f944e@mail.gmail.com>
References: <d5ad21470710310307k271c7104n1b3aa66c70617077@mail.gmail.com>
	<1193830981.9762.4.camel@localhost.localdomain>
	<200710312255.58489.ville.skytta@iki.fi>
	<d5ad21470711010210s56e4c8e2x167fb65f448f944e@mail.gmail.com>
Message-ID: <1193910902.3250.3.camel@ignacio.lan>

On Thu, 2007-11-01 at 10:10 +0100, Gianluca Sforna wrote:
> So my option now seems to be:
> 1. patch Makefile
> 2. remove (or %exclude) generated files

I recommend the former.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/ff375d89/attachment.sig>

From caillon at redhat.com  Thu Nov  1 10:20:36 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 01 Nov 2007 11:20:36 +0100
Subject: KDE logout options with F8
In-Reply-To: <20071101064921.272800@gmx.net>
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<20071031091902.101120@gmx.net>	<1193919724.3113.2.camel@clockmaker.usersys.redhat.com>
	<20071101064921.272800@gmx.net>
Message-ID: <4729A874.4090100@redhat.com>

Joachim Frieben wrote:
>> Please don't drag upstream X.org into this, xdm is a horror upstream is
>> glad gdm/kdm exist and merely continue shipping xdm as something for
>> system builders..
>> 
>> it isn't valuable or valid.
>> 
>> Dave.
> 
> Nevertheless, a user who simply wants a plain X environment is encumbered by packages he hasn't asked for [GDM + GNOME requires] without even the possibility to dismiss them during install.
> I suppose that a user who deliberately unchecks GNOME and KDE does know what he wants and does and imposing GDM onto him is against the often cited 'freedom of choice' unless you consider tracking down and uninstalling the related packages by the user post install as a reasonable duty.
> I have used XDM for a couple of years back when Red Hat Linux still booted into runlevel 3 by default, and I had no complaints about it.

Or maybe they just unchecked both because the words "GNOME" and "KDE" 
mean nothing to them, coming from a win/mac background.  Or maybe they 
aren't used to their trackpad's behavior under linux and uncheck one of 
them (both aren't checked by default, IIRC) accidentally.  If the user 
is truly advanced enough, there are other and IMO better ways to get the 
exact package set that they want.  Such as kickstart, re-spinning, etc.



From pemboa at gmail.com  Thu Nov  1 10:31:58 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 1 Nov 2007 05:31:58 -0500
Subject: FutureFeature - Split KDE packages
In-Reply-To: <BLU112-W192A5621E5E713D4CF0A9FD58C0@phx.gbl>
References: <BLU112-W29B3EAA49ED49460002913D58C0@phx.gbl>
	<loom.20071101T004220-28@post.gmane.org>
	<BLU112-W192A5621E5E713D4CF0A9FD58C0@phx.gbl>
Message-ID: <16de708d0711010331o334eea97t3a50282e06b4a74b@mail.gmail.com>

On 11/1/07, axel @ieee.org <axelinux at hotmail.com> wrote:
>
>  > > I know that Fedora is a Gnome based distribution but I prefer using KDE
> > > instead.
> >
> > That's why there's a KDE SIG (Special Interest Group). :-)
>
> Sorry, didn't know that. :)

http://fedoraproject.org/wiki/SIGs/KDE

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From mschwendt.tmp0701.nospam at arcor.de  Thu Nov  1 11:14:31 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Thu, 1 Nov 2007 12:14:31 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071031212850.E09144D04AE@magilla.localdomain>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
Message-ID: <20071101121431.c1b70d9a.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 31 Oct 2007 14:28:50 -0700 (PDT), Roland McGrath wrote:

> Can this robot be taught to take into account updates pending in bodhi but
> not yet pushed?  i.e. either suppress complaints in those cases, or cite
> rel-eng rather than the maintainer as the party who need to take action.

Only if bodhi offers a related interface (preferably for anonymous
users, or else extra effort is needed to handle the authentication,
since the script is still run within the Extras Signers group
environment).

  http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora

Patches are welcome in case anybody is up-to-date wrt bodhi.



From jkeating at redhat.com  Thu Nov  1 11:49:04 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 1 Nov 2007 07:49:04 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071101121431.c1b70d9a.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<20071101121431.c1b70d9a.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071101074904.7dd9cb16@redhat.com>

On Thu, 1 Nov 2007 12:14:31 +0100
Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:

> Only if bodhi offers a related interface (preferably for anonymous
> users, or else extra effort is needed to handle the authentication,
> since the script is still run within the Extras Signers group
> environment).
> 
>   http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora
> 
> Patches are welcome in case anybody is up-to-date wrt bodhi.

bodhi has a cli agent that is coming along pretty well.  It uses a lot
of the same framework that the pkgdb-client uses.  Making sure that it
can work anonymously for scripts such as this is definitely a goal.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/17b5868c/attachment.sig>

From silfreed at silfreed.net  Thu Nov  1 12:01:40 2007
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Thu, 1 Nov 2007 08:01:40 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071031212850.E09144D04AE@magilla.localdomain>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
Message-ID: <200711010801.40465.silfreed@silfreed.net>

On Wednesday 31 October 2007, Roland McGrath wrote:
> Can this robot be taught to take into account updates pending in bodhi but
> not yet pushed? ?i.e. either suppress complaints in those cases, or cite
> rel-eng rather than the maintainer as the party who need to take action.

My vote would be to *not* ignore packages that are in updates-testing; this is 
a real upgrade path problem for end-users, despite whether the packages will 
be available "soon".

-Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/9386c592/attachment.sig>

From lmacken at redhat.com  Thu Nov  1 12:29:03 2007
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 1 Nov 2007 08:29:03 -0400
Subject: pending Fedora 7 testing updates
In-Reply-To: <20071030143049.7b1cb7da@redhat.com>
References: <200710301925.28858.opensource@till.name>
	<20071030143049.7b1cb7da@redhat.com>
Message-ID: <20071101122903.GF3543@crow.boston.redhat.com>

On Tue, Oct 30, 2007 at 02:30:49PM -0400, Jesse Keating wrote:
> On Tue, 30 Oct 2007 19:25:23 +0100
> Till Maas <opensource at till.name> wrote:
> 
> > there are many pending Fedora 7 testing updates currently in Bodhi,
> > when will they be pushed to the testing repository? The oldest
> > waiting updates seem to be 7 days old now.
> 
> 
> We've been having compose issues with the -testing repo. Luke has been
> working like a madman on trying to resolve the issues.

https://bugzilla.redhat.com/show_bug.cgi?id=360291

We seem to have hit a bug in mash/yum that causes yum.resolveDeps() to
infinitely churn when trying to solve ppc updates-testing dependencies.

luke



From ssorce at redhat.com  Thu Nov  1 13:04:23 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 01 Nov 2007 09:04:23 -0400
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <4729899D.6050600@fedoraproject.org>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<4729899D.6050600@fedoraproject.org>
Message-ID: <1193922263.26382.127.camel@localhost.localdomain>

On Thu, 2007-11-01 at 13:39 +0530, Rahul Sundaram wrote:

>  moreover GPL 
> license also requires a written non-limiting patent grant or we can't 
> include GPL software that infringes patents on regions that enforce 
> patents on software.

This statement is wrong and false. Please consult legal and get
corrected.

Simo.



From mschwendt.tmp0701.nospam at arcor.de  Thu Nov  1 13:06:14 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Thu, 1 Nov 2007 14:06:14 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711010801.40465.silfreed@silfreed.net>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
Message-ID: <20071101140614.8be492fa.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 1 Nov 2007 08:01:40 -0400, Douglas E. Warner wrote:

> On Wednesday 31 October 2007, Roland McGrath wrote:
> > Can this robot be taught to take into account updates pending in bodhi but
> > not yet pushed? ?i.e. either suppress complaints in those cases, or cite
> > rel-eng rather than the maintainer as the party who need to take action.
> 
> My vote would be to *not* ignore packages that are in updates-testing; this is 
> a real upgrade path problem for end-users, despite whether the packages will 
> be available "soon".

They are not ignored. What Rolands wants is to not spam the package
maintainers when updates have been submitted in the Fedora Updates
System already and only wait for the right admins to publish them into
the repository.



From tcallawa at redhat.com  Thu Nov  1 13:29:19 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 01 Nov 2007 09:29:19 -0400
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <1193922263.26382.127.camel@localhost.localdomain>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<4729899D.6050600@fedoraproject.org>
	<1193922263.26382.127.camel@localhost.localdomain>
Message-ID: <1193923760.21765.71.camel@localhost.localdomain>


On Thu, 2007-11-01 at 09:04 -0400, Simo Sorce wrote:
> On Thu, 2007-11-01 at 13:39 +0530, Rahul Sundaram wrote:
> 
> >  moreover GPL 
> > license also requires a written non-limiting patent grant or we can't 
> > include GPL software that infringes patents on regions that enforce 
> > patents on software.
> 
> This statement is wrong and false. Please consult legal and get
> corrected.

>From GPLv2:

"If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations, then
as a consequence you may not distribute the Program at all. For example,
if a patent license would not permit royalty-free redistribution of the
Program by all those who receive copies directly or indirectly through
you, then the only way you could satisfy both it and this License would
be to refrain entirely from distribution of the Program."

~spot



From tcallawa at redhat.com  Thu Nov  1 13:36:07 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 01 Nov 2007 09:36:07 -0400
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
Message-ID: <1193924167.21765.78.camel@localhost.localdomain>


On Thu, 2007-11-01 at 10:47 +0300, Peter Lemenkov wrote:
> What about US?

The Fraunhofer/Thomson patents have not expired in the US.
They are not willing to give us an unrestricted patent grant.

US Patent 5559834 expires September 24, 2013
US Patent 4942607 expires February 3, 2008
US Patent 5812672 expires September 2, 2015
US Patent 5579430 expires November 26, 2013
US Patent 5321729 expires June 24, 2011
US Patent 5706309 expires January 6, 2015
US Patent 5227990 expires July 13, 2010
US Patent 4821260 expires December 16, 2007
US Patent 5214742 expires May 25, 2010
US Patent 6185539 expires February 6, 2018
US Patent 5703999 expires November 18, 2016
US Patent 5924060 expires July 13, 2016
US Patent 5701346 expires February 2, 2015
US Patent 6009399 expires April 16, 2017
US Patent 5384811 expires January 24, 2012
US Patent 5736943 expires April 7, 2015
US Patent 5742735 expires April 21, 2015
US Patent 5455833 expires October 3, 2012

In addition, Alcatel-Lucent holds patents which may relate to MP3 and
MPEG encoding. This is still pending appeal (Alcatel-Lucent v
Microsoft). It is not clear whether they will give out an unstricted
patent grant.

US Patent 5341457 expires Aug 20, 2013.
US Patent RE39,080 expires April 25, 2023.

~spot



From ssorce at redhat.com  Thu Nov  1 13:54:46 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 01 Nov 2007 09:54:46 -0400
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <1193923760.21765.71.camel@localhost.localdomain>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<4729899D.6050600@fedoraproject.org>
	<1193922263.26382.127.camel@localhost.localdomain>
	<1193923760.21765.71.camel@localhost.localdomain>
Message-ID: <1193925286.12404.10.camel@localhost.localdomain>

On Thu, 2007-11-01 at 09:29 -0400, Tom "spot" Callaway wrote:
> On Thu, 2007-11-01 at 09:04 -0400, Simo Sorce wrote:
> > On Thu, 2007-11-01 at 13:39 +0530, Rahul Sundaram wrote:
> > 
> > >  moreover GPL 
> > > license also requires a written non-limiting patent grant or we can't 
> > > include GPL software that infringes patents on regions that enforce 
> > > patents on software.
> > 
> > This statement is wrong and false. Please consult legal and get
> > corrected.
> 
> >From GPLv2:
> 
> "If you cannot distribute so as to satisfy simultaneously your
> obligations under this License and any other pertinent obligations, then
> as a consequence you may not distribute the Program at all. For example,
> if a patent license would not permit royalty-free redistribution of the
> Program by all those who receive copies directly or indirectly through
> you, then the only way you could satisfy both it and this License would
> be to refrain entirely from distribution of the Program."

I know this very well, but the phrase I cited is not correct.
We probably have tons of GPL software that infringes on tons of patents,
we simply don't know. And we don't "require a written non-limiting
patent grant" for it. We need something like that only for software that
"knowingly" infringes on specific patent where the patent holder
"denied" explicitly consent to distribution and we think they are right.

I know the specific MP3 case "probably" qualify, but I found the phrase
by itself is completely misleading.

Moreover if we were certain a patent had verifiable prior art, or we
considered it invalid (in the sense we were reasonably certain it
wouldn't stand in court) or we were reasonably certain our code does not
infringe because works around it, then we would *not* need again any
written permission, no matter what the patent holder say or require.

Finally GPL is vague and today we should start specifying if it is GPLv2
or GPLv3 as they have slightly different behaviors toward patents.

In summary, I would like for Rahul to be more careful with wording when
it comes to legal matters, or to state the case precisely. Generic
statements like his are just confusing for people that is not versed in
law and may not understand exactly the boundaries of the statement.

Simo.

Simo.



From tcallawa at redhat.com  Thu Nov  1 13:57:20 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 01 Nov 2007 09:57:20 -0400
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <1193925286.12404.10.camel@localhost.localdomain>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<4729899D.6050600@fedoraproject.org>
	<1193922263.26382.127.camel@localhost.localdomain>
	<1193923760.21765.71.camel@localhost.localdomain>
	<1193925286.12404.10.camel@localhost.localdomain>
Message-ID: <1193925440.21765.83.camel@localhost.localdomain>


On Thu, 2007-11-01 at 09:54 -0400, Simo Sorce wrote:
> I know the specific MP3 case "probably" qualify, but I found the
> phrase by itself is completely misleading.

To meet the criteria, we need to either feel certain that the code
utilizes patents without permission, or to be told by the patent holder
that a license is necessary to implement patents.

In the case of MP3, both criteria have been met.

~spot



From silfreed at silfreed.net  Thu Nov  1 14:29:17 2007
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Thu, 1 Nov 2007 10:29:17 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071101140614.8be492fa.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711010801.40465.silfreed@silfreed.net>
	<20071101140614.8be492fa.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200711011029.17787.silfreed@silfreed.net>

On Thursday 01 November 2007, Michael Schwendt wrote:
> They are not ignored. What Rolands wants is to not spam the package
> maintainers when updates have been submitted in the Fedora Updates
> System already and only wait for the right admins to publish them into
> the repository.

Sorry if I'm being dense, just trying to make sure I'm understanding;

So Roland would like to not spam the devel list when a package is sitting in 
updates-testing and has been pushed to stable by its maintainer?

If a package is just sitting in updates-testing and hasn't been pushed, then I 
still see the email as valid since there is a broken upgrade path that needs 
maintainer attention.

-Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/185d5baa/attachment.sig>

From jkeating at redhat.com  Thu Nov  1 14:35:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 1 Nov 2007 10:35:42 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711011029.17787.silfreed@silfreed.net>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711010801.40465.silfreed@silfreed.net>
	<20071101140614.8be492fa.mschwendt.tmp0701.nospam@arcor.de>
	<200711011029.17787.silfreed@silfreed.net>
Message-ID: <20071101103542.78d2815c@redhat.com>

On Thu, 1 Nov 2007 10:29:17 -0400
"Douglas E. Warner" <silfreed at silfreed.net> wrote:

> So Roland would like to not spam the devel list when a package is
> sitting in updates-testing and has been pushed to stable by its
> maintainer?
 
Roland would not like to get the individual mail that is sent to each
maintainer.  It can remain on the list sent to the -devel list though.

> If a package is just sitting in updates-testing and hasn't been
> pushed, then I still see the email as valid since there is a broken
> upgrade path that needs maintainer attention.

That's just it.  It doesn't require maintainer attention anymore,
they've done their job.  It's now up to rel-eng to make the push
happen.  Spamming the maintainer doesn't do any good.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/1908f234/attachment.sig>

From kevin.kofler at chello.at  Thu Nov  1 15:15:54 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 1 Nov 2007 15:15:54 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!
	5@redhat.com> <loom.20071031T182928-261@post.gmane.org>
	<20071031145933.18929ef2@redha! t.com>
Message-ID: <loom.20071101T151523-786@post.gmane.org>

Jesse Keating <jkeating <at> redhat.com> writes:
> Both of these changes take time to do, and time to recompose trees to
> make the release out of, and likely would lead to a slip of the Fedora
> 8 release.

I know it's too late for Fedora 8, but Fedora 8 won't be the last Fedora 
release ever. ;-)

        Kevin Kofler



From kevin.kofler at chello.at  Thu Nov  1 15:19:35 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 1 Nov 2007 15:19:35 +0000 (UTC)
Subject: KDE logout options with F8
References: <200710302208.03091.singularitaet@gmx.net>	<200710302212.50847.ml@deadbabylon.de>	<200710302302.19495.singularitaet@gmx.net>	<200710302308.47617.ml@deadbabylon.de>	<4727B0A7.9050909@fedoraproject.org>	<loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<20071031091902.101120@gmx.net>	<1193919724.3113.2.camel@clockmaker.usersys.redhat.com>
	<20071101064921.272800@gmx.net> <4729A874.4090100@redhat.com>
Message-ID: <loom.20071101T151739-370@post.gmane.org>

Christopher Aillon <caillon <at> redhat.com> writes:
> Or maybe they just unchecked both because the words "GNOME" and "KDE" 
> mean nothing to them, coming from a win/mac background.  Or maybe they 
> aren't used to their trackpad's behavior under linux and uncheck one of 
> them (both aren't checked by default, IIRC) accidentally.

If they accidentally uncheck both GNOME and KDE, they're going to have bigger 
issues with the resulting system than the login manager.

        Kevin Kofler



From myfedora at richip.dhs.org  Thu Nov  1 15:23:45 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 01 Nov 2007 09:23:45 -0600
Subject: KDE logout options with F8
In-Reply-To: <4729A874.4090100@redhat.com>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
	<200710302302.19495.singularitaet@gmx.net>
	<200710302308.47617.ml@deadbabylon.de>
	<4727B0A7.9050909@fedoraproject.org>
	<loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<20071031091902.101120@gmx.net>
	<1193919724.3113.2.camel@clockmaker.usersys.redhat.com>
	<20071101064921.272800@gmx.net> <4729A874.4090100@redhat.com>
Message-ID: <1193930625.24857.17.camel@localhost6.localdomain6>

On Thu, 2007-11-01 at 11:20 +0100, Christopher Aillon wrote:
> Or maybe they just unchecked both because the words "GNOME" and "KDE" 
> mean nothing to them, coming from a win/mac background.  Or maybe they 
> aren't used to their trackpad's behavior under linux and uncheck one of 
> them (both aren't checked by default, IIRC) accidentally.  If the user 
> is truly advanced enough, there are other and IMO better ways to get the 
> exact package set that they want.  Such as kickstart, re-spinning, etc.

Now that's being silly. So the only reason Gnome and KDE can both be
unchecked is so that people with butterfingers get a chance to
accidentally do it??? That if expert users want only X, they'll click on
only X to find X + something and must actually respin? Then what's that
option for?

Let's look at cases where the user knows what they're doing:

Users who want only X include students who want to try programming
directly for X Windows, perhaps as part of a Comp Sci course. Or
embedded software devices who wish to create their own X widgets or base
it off of others (other than GTK+ and qt) and don't want to clutter up
their install. But whatever it is, if the option boxes say "no Gnome"
and "no KDE", that, to me, means just plain old X.

If a user select X + KDE, then they should get KDM. If a user selects X
+ KDE + Gnome, then they should get KDM and GDM installed with GDM
active. If they select X + Gnome, then they should get GDM.

Which user who intentionally wants only X would want GDM (and the libs
it pulls in)?

Now let's look cases where the user ends up with a configuration out of
ignorance or carelessness:

In the case where GDM is installed, they get a nice log in screen with
all the bells and whistles, log in to an xedit window managed by TWM. If
XDM is installed, they log in to pretty much the same thing. Either way,
the accident-prone user is at a loss. BETTER to have a warning during
install-time that no advanced Desktop Environment (explain what it is,
if necessary) and ask if the install should proceed.

As I said, I think this thread is getting silly. There are certain
expectations as to the results of installation choices. I've already
outlined them above. Let's not sacrifice those for unintentional
scenarios.

If it's technical issues that keep it from happening, then it's best to
discuss that and figure out how to overcome them (and how much priority
they'll be given) for F9.

Respins are for when the default distro cannot reasonably satisfy the
chosen valid use-cases. In this case, there's just no reason to pass it
off to respinning.
--

Richi Plana



From kevin.kofler at chello.at  Thu Nov  1 15:26:21 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 1 Nov 2007 15:26:21 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
Message-ID: <loom.20071101T152020-62@post.gmane.org>

Christopher Aillon <caillon <at> redhat.com> writes:
> We should get to the point where we have one login manager, and just 
> swap out the toolkits/UI.  Logging in is something that we seriously 
> should not have multiple packages for.

And then what guarantees us the KDE frontend is not going to get the same 
treatment KNetworkManager got for F8 (i.e. the backend getting upgraded to an 
experimental, completely incompatible snapshot which is not supported by the 
KDE frontend yet, and way too late in the release cycle (after the feature 
freeze!) so there's no way the KDE frontend can be fixed in time)?

The way NetworkManager 0.7 has been handled in F8 makes me very distrustful of 
such "one backend, multiple frontend" solutions.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Nov  1 15:29:37 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 1 Nov 2007 15:29:37 +0000 (UTC)
Subject: file system mount
References: <47297920.60509@fedoraproject.org>
Message-ID: <loom.20071101T152643-909@post.gmane.org>

Amitakhya Phukan <aphukan <at> fedoraproject.org> writes:
> i have a system with fedora 7 and rhel 5 installed. recently, i changed
> the f7 to rawhide. now whenever i boot up, it mounts all the file
> systems related to rhel5 along with it and displays on the desktop.
> dmesg says /dev/sda1 mounted on /media/_1 and so on. I want to disable
> this feature. i don't know if this is anything useful ?? i even don't
> know if its a feature or a bug... can any one please help me out with
> this thing ? i understand hal is doing this (??), but why ? and even
> when i unmount it, the same can still be found in /media. right clicking
> on those partitions give me the option of mounting/unmounting them. but
> i don't want to let them appear in my rawhide systems totally. anyone
> else has this experience on rawhide??how do i disable it ??

Fedora 7 has a file called
/usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi
to prevent this from happening, here's its contents:
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">
<device>
  <match key="@block.storage_device:storage.hotpluggable" bool="false">
    <match key="@block.storage_device:storage.removable" bool="false">
      <merge key="volume.ignore" type="bool">true</merge>
    </match>
  </match>
</device>
</deviceinfo>

If that file is no longer there in Fedora 8, try adding it and see if that 
helps.

        Kevin Kofler



From cebbert at redhat.com  Thu Nov  1 15:31:18 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Thu, 01 Nov 2007 11:31:18 -0400
Subject: KDE logout options with F8
In-Reply-To: <loom.20071101T152020-62@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
Message-ID: <4729F146.5060806@redhat.com>

On 11/01/2007 11:26 AM, Kevin Kofler wrote:
> treatment KNetworkManager got for F8 (i.e. the backend getting upgraded to an 
> experimental, completely incompatible snapshot which is not supported by the 
> KDE frontend yet, and way too late in the release cycle (after the feature 
> freeze!) so there's no way the KDE frontend can be fixed in time)?
> 

Please tell me you're kidding.

I you're not, then what are KDE users supposed to use?



From kevin.kofler at chello.at  Thu Nov  1 15:37:01 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 1 Nov 2007 15:37:01 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<4729F146.5060806@redhat.com>
Message-ID: <loom.20071101T153251-553@post.gmane.org>

Chuck Ebbert <cebbert <at> redhat.com> writes:
> Please tell me you're kidding.
> 
> I you're not, then what are KDE users supposed to use?

knetworkmanager is now a dummy package which configures the GNOME-based 
nm-applet to run under KDE. (It'll work in Kicker, just like puplet and other 
GTK+-based tray applets.) This also means we had to drag in several GNOME libs 
onto the KDE live CD just for nm-applet. We're hoping to have a usable 
knetworkmanager to push as an update (replacing the dummy package) at some 
point.

        Kevin Kofler



From rdieter at math.unl.edu  Thu Nov  1 15:40:25 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 01 Nov 2007 10:40:25 -0500
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<4729F146.5060806@redhat.com>
Message-ID: <fgcs1a$t1v$1@ger.gmane.org>

Chuck Ebbert wrote:

> On 11/01/2007 11:26 AM, Kevin Kofler wrote:
>> treatment KNetworkManager got for F8 (i.e. the backend getting upgraded
>> to an experimental, completely incompatible snapshot which is not
>> supported by the KDE frontend yet, and way too late in the release cycle
>> (after the feature freeze!) so there's no way the KDE frontend can be
>> fixed in time)?

> Please tell me you're kidding.

you've enterred a kidding-free zone

> If you're not, then what are KDE users supposed to use?

NetworkManager-gnome, aka nm-applet, is the only viable option atm.  The
knetworkmanager package in F8 is currently nothing more than a shell for
using nm-applet.  When/if knetworkmanager works again, an upgrade path back
to using the real deal is possible.

-- Rex



From jkeating at redhat.com  Thu Nov  1 15:57:23 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 1 Nov 2007 11:57:23 -0400
Subject: KDE logout options with F8
In-Reply-To: <loom.20071101T152020-62@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
Message-ID: <20071101115723.5628d3fb@redhat.com>

On Thu, 1 Nov 2007 15:26:21 +0000 (UTC)
Kevin Kofler <kevin.kofler at chello.at> wrote:

> And then what guarantees us the KDE frontend is not going to get the
> same treatment KNetworkManager got for F8 (i.e. the backend getting
> upgraded to an experimental, completely incompatible snapshot which
> is not supported by the KDE frontend yet, and way too late in the
> release cycle (after the feature freeze!) so there's no way the KDE
> frontend can be fixed in time)?
> 
> The way NetworkManager 0.7 has been handled in F8 makes me very
> distrustful of such "one backend, multiple frontend" solutions.

The timeline of NetworkManager was /clearly/ communicated in multiple
FESCo meetings.  I'm sorry if nobody from the KDE sig paid attention
and sought out resources to work with NM developer to make sure the KDE
side of things panned out.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/fbfc619a/attachment.sig>

From P at draigBrady.com  Thu Nov  1 16:24:14 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Thu, 1 Nov 2007 16:24:14 +0000
Subject: laptop hard disk etiquette
In-Reply-To: <472260A1.9080208@draigBrady.com>
References: <49139.192.54.193.51.1193412817.squirrel@rousalka.dyndns.org>	<472209D2.7090803@draigBrady.com>
	<472260A1.9080208@draigBrady.com>
Message-ID: <4729FDAE.3000301@draigBrady.com>

P?draig Brady wrote:
> P?draig Brady wrote:
> 
> 1. ubuntu dicks with the drive spin down timers when on battery

I've heard that by default ubuntu does not mess with these timers,
but will if one sets laptop-mode in /etc/default/acpi-support, anyway...

> 2. fedora does not (as Bill suggested)
> 3. fedora should probably not (as Alan suggested)
> 4. fedora should probably default to relatime mount option
>    on laptops at least (as Ingo suggested here:
>    http://kerneltrap.org/node/14148 )

As Jeff points out F8 will have relatime configured on
by default for all mounts. Yay for sensible defaults!

> Noting that this laptop was running FC4 for most of its life,
> and that it has the following defaults:
> # hdparm -I /dev/sda | grep "Advanced power management level"
>         Advanced power management level: 128 (0x80)
> Using the smart Power_On_Hours value, shows that in total
> it has load cycled on average once every 48s:
> # echo "scale=2; (4718*60*60)/351675" | bc
> 48.29
> 
> That's far too aggressive, especially considering this
> laptop is plugged in most of the time.
> But also note that atime updates were enabled (as per default),
> which probably exacerbated the problem.
> I'll disable that first on all partitions and if that
> doesn't suffice I'll make the "unloading" less agressive
> using the `hdparam -B $level /dev/sda` command.

Disabling atime manually on F7, gets my hard disk
[un]load cycle frequency to decrease from once every 48s
to once every 108s:

$ echo "((4765-4718)*60*60)/(353361-351795)" | bc
108

That's around what I think it should be as a limit,
so can we add "anti hard drive ware technology"
to the new features in the F8 release notes :)

I did also notice a bug which mentions that this
issue may be triggered by changes in kernel 2.6.10?
https://bugzilla.redhat.com/show_bug.cgi?id=146628

cheers,
P?draig.



From rdieter at math.unl.edu  Thu Nov  1 17:25:39 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 01 Nov 2007 12:25:39 -0500
Subject: knetworkmanager, nm-0.7
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com>
Message-ID: <fgd26j$kgu$1@ger.gmane.org>

Jesse Keating wrote:

> On Thu, 1 Nov 2007 15:26:21 +0000 (UTC)
> Kevin Kofler <kevin.kofler at chello.at> wrote:

>> The way NetworkManager 0.7 has been handled in F8 makes me very
>> distrustful of such "one backend, multiple frontend" solutions.
> 
> The timeline of NetworkManager was /clearly/ communicated in multiple
> FESCo meetings. 

Fact is, it was a last-minute thing, squeezed in late.  We all know it.  A
mostly worthwhile thing, which is why FESCo was ok with it.  And, btw, I
agree with that decision ultimately.(1)

But... please don't try to argue that this was something that the KDE SIG
could have reasonably expected or planned for.   Even if we had, I don't
think upstream knetworkmanager could have sync'd to such a moving target
that is nm-0.7 atm. 

-- Rex

(1) Of course, 'twould have been *much* better to have introduced nm-0.7
much earlier in the release cycle, I think we can all agree to that.



From mclasen at redhat.com  Thu Nov  1 17:52:12 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 01 Nov 2007 13:52:12 -0400
Subject: knetworkmanager, nm-0.7
In-Reply-To: <fgd26j$kgu$1@ger.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org> <47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com>  <fgd26j$kgu$1@ger.gmane.org>
Message-ID: <1193939532.4063.28.camel@localhost.localdomain>


On Thu, 2007-11-01 at 12:25 -0500, Rex Dieter wrote:

> > 
> > The timeline of NetworkManager was /clearly/ communicated in multiple
> > FESCo meetings. 
> 
> Fact is, it was a last-minute thing, squeezed in late.  We all know it.  A
> mostly worthwhile thing, which is why FESCo was ok with it.  And, btw, I
> agree with that decision ultimately.(1)

The timing was certainly not ideal, due to the fact that we didn't have
Dan fulltime until late in the cycle. But realistically, what is the
alternative ? Unless we want to always do the hard work, and then let
Ubuntu and others ship it first...



From dwalsh at redhat.com  Thu Nov  1 17:58:49 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Thu, 01 Nov 2007 13:58:49 -0400
Subject: NFS Update and SELinux
In-Reply-To: <1193856288.12145.9.camel@localhost6.localdomain6>
References: <1193856288.12145.9.camel@localhost6.localdomain6>
Message-ID: <472A13D9.4010105@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richi Plana wrote:
> Hi,
> 
> On F7, the latest nfs-utils update (1:1.1.0-4.fc7.x86_64) seems to be
> resulting in a lot of SELinux denials (accesses to /dev/usbmon?).
> 
> Not knowing what to do next, I thought I'd ask at fedora-devel. Is there
> something I should do that I'm not (ie. rebooting, restarting some
> daemon, restorecon)? Is this a bug in nfs-utils?
> selinux-policy-targeted? Is this some malicious software update?
> 
> I could use a little help in troubleshooting.
> --
> 
> Richi Plana
> 
Please attach avc messages?

These devices should be labeled usb_device_t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHKhPZrlYvE4MpobMRAuEUAKDXrIiy+AZX9FRtzN/IW4j1j132BgCg5B0f
VcRfN3kBu5YCs04hX2zdHBw=
=1N/R
-----END PGP SIGNATURE-----



From jkeating at redhat.com  Thu Nov  1 18:13:39 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 1 Nov 2007 14:13:39 -0400
Subject: knetworkmanager, nm-0.7
In-Reply-To: <fgd26j$kgu$1@ger.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com> <fgd26j$kgu$1@ger.gmane.org>
Message-ID: <20071101141339.4cc751a9@redhat.com>

On Thu, 01 Nov 2007 12:25:39 -0500
Rex Dieter <rdieter at math.unl.edu> wrote:

> But... please don't try to argue that this was something that the KDE
> SIG could have reasonably expected or planned for. 

I don't see how you can say you didn't expect it when you yourself, as
a member of the KDE sig, knew it was landing late.  That's my
argument.  Whether or not you could have done something is a different
argument, but please don't act like this was a big surprise sprung on
you days before the release.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071101/0880dcd7/attachment.sig>

From drago01 at gmail.com  Thu Nov  1 18:18:36 2007
From: drago01 at gmail.com (dragoran)
Date: Thu, 1 Nov 2007 19:18:36 +0100
Subject: knetworkmanager, nm-0.7
In-Reply-To: <20071101141339.4cc751a9@redhat.com>
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com> <loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com> <fgd26j$kgu$1@ger.gmane.org>
	<20071101141339.4cc751a9@redhat.com>
Message-ID: <f6ca9fed0711011118q4a41fac8hb51dc9640836cfcd@mail.gmail.com>

On 11/1/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Thu, 01 Nov 2007 12:25:39 -0500
> Rex Dieter <rdieter at math.unl.edu> wrote:
>
> > But... please don't try to argue that this was something that the KDE
> > SIG could have reasonably expected or planned for.
>
> I don't see how you can say you didn't expect it when you yourself, as
> a member of the KDE sig, knew it was landing late.  That's my
> argument.  Whether or not you could have done something is a different
> argument, but please don't act like this was a big surprise sprung on
> you days before the release.

http://mail.gnome.org/archives/networkmanager-list/2007-September/msg00115.html
(so its not that nobody cared about it)



From myfedora at richip.dhs.org  Thu Nov  1 18:27:34 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 01 Nov 2007 12:27:34 -0600
Subject: NFS Update and SELinux
In-Reply-To: <472A13D9.4010105@redhat.com>
References: <1193856288.12145.9.camel@localhost6.localdomain6>
	<472A13D9.4010105@redhat.com>
Message-ID: <1193941654.3848.5.camel@localhost6.localdomain6>

Hi, Daniel.

On Thu, 2007-11-01 at 13:58 -0400, Daniel J Walsh wrote:
> Please attach avc messages?
> 
> These devices should be labeled usb_device_t

Thanks for the tip.

Well, after reading your email, I checked the context and it's
definitely labeled "device_t". I looked at my selinux file_contexts and
the closest match for /dev/usbmon? was /dev/.* (which gave it a context
of device_t).

More info:

selinux-policy-targeted-2.6.4-48.fc7

I haven't edited it. And:

# ll -Z /dev/usb*
lrwxrwxrwx  root root
system_u:object_r:device_t       /dev/usbdev1.1_ep00 ->
bus/usb/1/1_ep/00
lrwxrwxrwx  root root
system_u:object_r:device_t       /dev/usbdev1.1_ep81 ->
bus/usb/1/1_ep/81
lrwxrwxrwx  root root
system_u:object_r:device_t       /dev/usbdev1.2_ep00 ->
bus/usb/1/2_ep/00
lrwxrwxrwx  root root
system_u:object_r:device_t       /dev/usbdev1.2_ep81 ->
bus/usb/1/2_ep/81
lrwxrwxrwx  root root
system_u:object_r:device_t       /dev/usbdev2.1_ep00 ->
bus/usb/2/1_ep/00
lrwxrwxrwx  root root
system_u:object_r:device_t       /dev/usbdev2.1_ep81 ->
bus/usb/2/1_ep/81
crw-------  root root system_u:object_r:device_t       /dev/usbmon0
crw-------  root root system_u:object_r:device_t       /dev/usbmon1
crw-------  root root system_u:object_r:device_t       /dev/usbmon2

FYI.

Thanks!
--

Richi Plana



From limb at jcomserv.net  Thu Nov  1 18:29:51 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 1 Nov 2007 13:29:51 -0500 (CDT)
Subject: yum: rpm_check_debug vs. depsolve: rhnlib needs python(abi) = 
 2.4
In-Reply-To: <20071101182255.GA6715@mail.harddata.com>
References: <20071101145710.GV21171@angus.ind.WPI.EDU>
	<32346.63.85.68.164.1193928980.squirrel@mail.jcomserv.net>
	<20071101163932.GA21171@angus.ind.WPI.EDU>
	<57573.63.85.68.164.1193935171.squirrel@mail.jcomserv.net>
	<20071101182255.GA6715@mail.harddata.com>
Message-ID: <32393.63.85.68.164.1193941791.squirrel@mail.jcomserv.net>


> On Thu, Nov 01, 2007 at 11:39:31AM -0500, Jon Ciesla wrote:
>>
>> I expect that we(http://fedoraproject.org/wiki/SIGs/LiveUpgrade) might
>> want to find a way to deal with this, maybe not with Obsoletes, but
>> something inthe f-r.rpm %postinstall or something.  Maybe not.
>
> It seems to me that if a package blocks something in updates
> and is an "orphan" (both conditions tested in one time or another)
> then it should be marked for a removal; otherwise I would be very
> careful about doing anything hasty.  Likely packages deleted
> that way should be marked quite prominently in logs.

Agreed.  I wouldn't want to pull something off someone's system just
because Fedora stopped carrying it, if the user finds it useful.  In the
case of an abi dep, like rhnlib and python, yum sees that the upgrade will
break rhnlib, so won't do it with rhnlib there, which is The Right Thing
To Do.  Maybe we just leave all as it is, and add a list of dead packages
to the release notes for each release, so you know what to pull beforehand
if you want.

>    Michal
>


-- 
novus ordo absurdum



From rdieter at math.unl.edu  Thu Nov  1 18:42:58 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 01 Nov 2007 13:42:58 -0500
Subject: knetworkmanager, nm-0.7
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com> <fgd26j$kgu$1@ger.gmane.org>
	<20071101141339.4cc751a9@redhat.com>
Message-ID: <fgd6nj$4lu$1@ger.gmane.org>

Jesse Keating wrote:

> On Thu, 01 Nov 2007 12:25:39 -0500
> Rex Dieter <rdieter at math.unl.edu> wrote:
> 
>> But... please don't try to argue that this was something that the KDE
>> SIG could have reasonably expected or planned for.
> 
> I don't see how you can say you didn't expect it when you yourself, as
> a member of the KDE sig, knew it was landing late. 

OK, fair enough.  

I guess my only point was that that landing so late, with a nm-0.7
prerelease, screwed knetworkmanager.  It was simply a casualty of the
decision (but I guess we all know that by now).

Like I said, I'm ok with the decision.  Can't make a fancy fedora omlette
without breaking a few eggs.

-- Rex




From jspaleta at gmail.com  Thu Nov  1 18:44:51 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 1 Nov 2007 10:44:51 -0800
Subject: yum: rpm_check_debug vs. depsolve: rhnlib needs python(abi) =
	2.4
In-Reply-To: <32393.63.85.68.164.1193941791.squirrel@mail.jcomserv.net>
References: <20071101145710.GV21171@angus.ind.WPI.EDU>
	<32346.63.85.68.164.1193928980.squirrel@mail.jcomserv.net>
	<20071101163932.GA21171@angus.ind.WPI.EDU>
	<57573.63.85.68.164.1193935171.squirrel@mail.jcomserv.net>
	<20071101182255.GA6715@mail.harddata.com>
	<32393.63.85.68.164.1193941791.squirrel@mail.jcomserv.net>
Message-ID: <604aa7910711011144g4ca5e3eej685391b864232f02@mail.gmail.com>

On 11/1/07, Jon Ciesla <limb at jcomserv.net> wrote:
> Agreed.  I wouldn't want to pull something off someone's system just
> because Fedora stopped carrying it, if the user finds it useful.  In the
> case of an abi dep, like rhnlib and python, yum sees that the upgrade will
> break rhnlib, so won't do it with rhnlib there, which is The Right Thing
> To Do.  Maybe we just leave all as it is, and add a list of dead packages
> to the release notes for each release, so you know what to pull beforehand
> if you want.

We need to carry around information as to what the Fedora "repository"
has stopped carrying as an optional repository metadata. Once we do
that, we can teach clientside tools to parse such repository level
data and then local admins can decide how to deal with packages which
are no longer being provided.

We could use this sort of metadata to inform users about orphaned as
well as deprecated packages on a repository by repository basis.

-jef



From david at fubar.dk  Thu Nov  1 18:41:41 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 01 Nov 2007 14:41:41 -0400
Subject: file system mount
In-Reply-To: <47297920.60509@fedoraproject.org>
References: <47297920.60509@fedoraproject.org>
Message-ID: <1193942501.7233.10.camel@localhost.localdomain>


On Thu, 2007-11-01 at 12:28 +0530, Amitakhya Phukan wrote:
> hi all!
> 
> i have a system with fedora 7 and rhel 5 installed. recently, i changed
> the f7 to rawhide. now whenever i boot up, it mounts all the file
> systems related to rhel5 along with it and displays on the desktop.

Rawhide only mounts fixed drives only when you login and only if you put
in the root password and don't unclick the "Remember authorization"
check box. Like this

 http://people.freedesktop.org/~david/pk-gnome-mount.png

so it's most likely your own doing. There's no good UI in Rawhide/F8 for
doing it except 'polkit-grant --delete <username>' as the super user.
For F9 there will be a GNOME UI for managing these authorizations as
well as the defaults; work-in-progress looks like this

 http://people.freedesktop.org/~david/polkit-gnome-authorizations.png

but the UI is likely to change.

Hope this helps.

      David

 




From david at fubar.dk  Thu Nov  1 18:42:40 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 01 Nov 2007 14:42:40 -0400
Subject: file system mount
In-Reply-To: <1193942501.7233.10.camel@localhost.localdomain>
References: <47297920.60509@fedoraproject.org>
	<1193942501.7233.10.camel@localhost.localdomain>
Message-ID: <1193942560.7233.12.camel@localhost.localdomain>


On Thu, 2007-11-01 at 14:41 -0400, David Zeuthen wrote:
> On Thu, 2007-11-01 at 12:28 +0530, Amitakhya Phukan wrote:
> > hi all!
> > 
> > i have a system with fedora 7 and rhel 5 installed. recently, i changed
> > the f7 to rawhide. now whenever i boot up, it mounts all the file
> > systems related to rhel5 along with it and displays on the desktop.
> 
> Rawhide only mounts fixed drives only when you login and only if you put
> in the root password and don't unclick the "Remember authorization"
> check box. Like this
> 
>  http://people.freedesktop.org/~david/pk-gnome-mount.png
> 
> so it's most likely your own doing. There's no good UI in Rawhide/F8 for
> doing it except 'polkit-grant --delete <username>' as the super user.
  ^^^^^

s/doing/undoing/

     David




From limb at jcomserv.net  Thu Nov  1 18:40:12 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 1 Nov 2007 13:40:12 -0500 (CDT)
Subject: yum: rpm_check_debug vs. depsolve: rhnlib needs python(abi) = 
 2.4
In-Reply-To: <604aa7910711011144g4ca5e3eej685391b864232f02@mail.gmail.com>
References: <20071101145710.GV21171@angus.ind.WPI.EDU>
	<32346.63.85.68.164.1193928980.squirrel@mail.jcomserv.net>
	<20071101163932.GA21171@angus.ind.WPI.EDU>
	<57573.63.85.68.164.1193935171.squirrel@mail.jcomserv.net>
	<20071101182255.GA6715@mail.harddata.com>
	<32393.63.85.68.164.1193941791.squirrel@mail.jcomserv.net>
	<604aa7910711011144g4ca5e3eej685391b864232f02@mail.gmail.com>
Message-ID: <42023.63.85.68.164.1193942412.squirrel@mail.jcomserv.net>

Posting Jeff's +1 Insightful back to the list I inadvetently hijacked the
topic from. :)

> On 11/1/07, Jon Ciesla <limb at jcomserv.net> wrote:
>> Agreed.  I wouldn't want to pull something off someone's system just
>> because Fedora stopped carrying it, if the user finds it useful.  In the
>> case of an abi dep, like rhnlib and python, yum sees that the upgrade
>> will
>> break rhnlib, so won't do it with rhnlib there, which is The Right Thing
>> To Do.  Maybe we just leave all as it is, and add a list of dead
>> packages
>> to the release notes for each release, so you know what to pull
>> beforehand
>> if you want.
>
> We need to carry around information as to what the Fedora "repository"
> has stopped carrying as an optional repository metadata. Once we do
> that, we can teach clientside tools to parse such repository level
> data and then local admins can decide how to deal with packages which
> are no longer being provided.
>
> We could use this sort of metadata to inform users about orphaned as
> well as deprecated packages on a repository by repository basis.
>
> -jef
>


-- 
novus ordo absurdum



From sgrubb at redhat.com  Thu Nov  1 18:52:19 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Thu, 1 Nov 2007 14:52:19 -0400
Subject: yum: rpm_check_debug vs. depsolve: rhnlib needs python(abi) =
	2.4
In-Reply-To: <604aa7910711011144g4ca5e3eej685391b864232f02@mail.gmail.com>
References: <20071101145710.GV21171@angus.ind.WPI.EDU>
	<32393.63.85.68.164.1193941791.squirrel@mail.jcomserv.net>
	<604aa7910711011144g4ca5e3eej685391b864232f02@mail.gmail.com>
Message-ID: <200711011452.19936.sgrubb@redhat.com>

On Thursday 01 November 2007 02:44:51 pm Jeff Spaleta wrote:
> We need to carry around information as to what the Fedora "repository"
> has stopped carrying as an optional repository metadata. Once we do
> that, we can teach clientside tools to parse such repository level
> data and then local admins can decide how to deal with packages which
> are no longer being provided.

This would be really handy for those of us that run rawhide as the first 
indication that something is no longer shipped is a failed upgrade of a 
library that it uses. At that point you don't know if a recompiled package is 
on the way or not.

-Steve



From notting at redhat.com  Thu Nov  1 18:56:49 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 1 Nov 2007 14:56:49 -0400
Subject: Fedora Core 6 EOL, new branch restrictions
Message-ID: <20071101185649.GB30240@nostromo.devel.redhat.com>

As stated:
https://www.redhat.com/archives/fedora-announce-list/2007-November/msg00000.html

Fedora Core 6 will EOL on Friday, December 7. After this time, no more updates
will be accepted.

Note that after the release of Fedora 8 (scheduled for Thursday, November 8), new
Fedora 6 branches will no longer be created for packages.

Bill

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From jspaleta at gmail.com  Thu Nov  1 19:13:36 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 1 Nov 2007 11:13:36 -0800
Subject: yum: rpm_check_debug vs. depsolve: rhnlib needs python(abi) =
	2.4
In-Reply-To: <200711011452.19936.sgrubb@redhat.com>
References: <20071101145710.GV21171@angus.ind.WPI.EDU>
	<32393.63.85.68.164.1193941791.squirrel@mail.jcomserv.net>
	<604aa7910711011144g4ca5e3eej685391b864232f02@mail.gmail.com>
	<200711011452.19936.sgrubb@redhat.com>
Message-ID: <604aa7910711011213t254e7925qe0923c3693a8e0f@mail.gmail.com>

On 11/1/07, Steve Grubb <sgrubb at redhat.com> wrote:
> This would be really handy for those of us that run rawhide as the first
> indication that something is no longer shipped is a failed upgrade of a
> library that it uses. At that point you don't know if a recompiled package is
> on the way or not.

I'm hopefully we can have the metadata in place before F9.

https://hosted.fedoraproject.org/projects/packagedb/ticket/57

The harder part is going to be teaching the clientside tools how to
parse it and use it in useful ways.

-jef



From jspaleta at gmail.com  Thu Nov  1 19:22:01 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 1 Nov 2007 11:22:01 -0800
Subject: file system mount
In-Reply-To: <1193942501.7233.10.camel@localhost.localdomain>
References: <47297920.60509@fedoraproject.org>
	<1193942501.7233.10.camel@localhost.localdomain>
Message-ID: <604aa7910711011222t2fe12dfmd237998f759f4cee@mail.gmail.com>

On 11/1/07, David Zeuthen <david at fubar.dk> wrote:
>  http://people.freedesktop.org/~david/polkit-gnome-authorizations.png
>
> but the UI is likely to change.
>
> Hope this helps.

Is per device policy granting in the works? So that certain disks are
mountable but others aren't  on a user by user basis?

-jef"Idle thought: How well does policy granting work with sabayon?"spaleta



From david at fubar.dk  Thu Nov  1 19:55:40 2007
From: david at fubar.dk (David Zeuthen)
Date: Thu, 01 Nov 2007 15:55:40 -0400
Subject: file system mount
In-Reply-To: <604aa7910711011222t2fe12dfmd237998f759f4cee@mail.gmail.com>
References: <47297920.60509@fedoraproject.org>
	<1193942501.7233.10.camel@localhost.localdomain>
	<604aa7910711011222t2fe12dfmd237998f759f4cee@mail.gmail.com>
Message-ID: <1193946940.8766.7.camel@localhost.localdomain>


On Thu, 2007-11-01 at 11:22 -0800, Jeff Spaleta wrote:
> On 11/1/07, David Zeuthen <david at fubar.dk> wrote:
> >  http://people.freedesktop.org/~david/polkit-gnome-authorizations.png
> >
> > but the UI is likely to change.
> >
> > Hope this helps.
> 
> Is per device policy granting in the works? So that certain disks are
> mountable but others aren't  on a user by user basis?

See the last two paragraphs of

 http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html

Basically the way it works right now is that Mechanisms split actions
depending on type. Specifically for hal there's a "fixed" and
"removable" split. For NM there will be "can-dial-to-trusted-number" and
"can-dial-to-untrusted-number"; then the act of making something a
trusted number is some other privileged operation (e.g. trusted numbers
are the ones listed in a file in /etc, whatever, I don't know).

FWIW, we might add functionality later (the API is extensible) such that
PolicyKit can answer questions like

 "Is $PROCESS authorized to do $ACTION on $OBJECT on behalf of the user"

 (now it's "Is $PROCESS authorized to do $ACTION on behalf of the user")

but right now this isn't there - mainly because there's a ton of
problems in how to sanely describe an object
(/dev/sda? /dev/disk/by-label ? phonenumber? etc.) and also how to build
sane UI around this. Hope this helps.

> -jef"Idle thought: How well does policy granting work with sabayon?"spaleta

Someone just needs to do it. It's more interesting, however, to consider
PolicyKit together with http://freeipa.org/page/Main_Page . As a matter
of fact, I'm already working with the FreeIPA guys on this.

     David




From fedora at leemhuis.info  Thu Nov  1 20:15:53 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 01 Nov 2007 21:15:53 +0100
Subject: EPEL report week 43 2007
In-Reply-To: <20071029133847.3d43a32b.mschwendt.tmp0701.nospam@arcor.de>
References: <4724ECEE.6080508@leemhuis.info>
	<20071029133847.3d43a32b.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <472A33F9.90904@leemhuis.info>



On 29.10.2007 13:38, Michael Schwendt wrote:
> On Sun, 28 Oct 2007 21:11:26 +0100, Thorsten Leemhuis wrote:
>>  * lots of packages in epel5 were moved from testing to the proper repo;
>> see
>> [https://www.redhat.com/archives/epel-devel-list/2007-October/msg00045.html
>> this thread] for some details
> Do "cvs up Config_EPEL.py" on the buildsys master to be able to define
> in the repoprune_keepdict how many pkgs to keep in the testing repos.
> For a very long time we've relied on the old defaults only: keep=1 for
> development, keep=2 for stable repos, plus the kmod whitelists. So
> for EPEL it has been keep=2 for *all* repos so far.

Seems to work fine afaics. Many thx for your help Michael!

CU
knurd



From cra at WPI.EDU  Thu Nov  1 20:20:37 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 1 Nov 2007 16:20:37 -0400
Subject: knetworkmanager, nm-0.7
In-Reply-To: <1193939532.4063.28.camel@localhost.localdomain>
References: <4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com> <fgd26j$kgu$1@ger.gmane.org>
	<1193939532.4063.28.camel@localhost.localdomain>
Message-ID: <20071101202037.GA18705@angus.ind.WPI.EDU>

On Thu, Nov 01, 2007 at 01:52:12PM -0400, Matthias Clasen wrote:
> 
> On Thu, 2007-11-01 at 12:25 -0500, Rex Dieter wrote:
> 
> > > 
> > > The timeline of NetworkManager was /clearly/ communicated in multiple
> > > FESCo meetings. 
> > 
> > Fact is, it was a last-minute thing, squeezed in late.  We all know it.  A
> > mostly worthwhile thing, which is why FESCo was ok with it.  And, btw, I
> > agree with that decision ultimately.(1)
> 
> The timing was certainly not ideal, due to the fact that we didn't have
> Dan fulltime until late in the cycle. But realistically, what is the
> alternative ? Unless we want to always do the hard work, and then let
> Ubuntu and others ship it first...

Since when do we care about who ships what first?  Are we going to 
begin emulating the commercial software world where it is more 
important to ship broken half-baked stuff first so we can beat 
everyone else in the industry, rather than waiting until something is 
really ready before shipping it?



From jspaleta at gmail.com  Thu Nov  1 20:40:47 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 1 Nov 2007 12:40:47 -0800
Subject: knetworkmanager, nm-0.7
In-Reply-To: <20071101202037.GA18705@angus.ind.WPI.EDU>
References: <4727E19F.1010405@fedoraproject.org>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com> <loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com> <fgd26j$kgu$1@ger.gmane.org>
	<1193939532.4063.28.camel@localhost.localdomain>
	<20071101202037.GA18705@angus.ind.WPI.EDU>
Message-ID: <604aa7910711011340t17ca82c1l63a0780c6dc4381e@mail.gmail.com>

On 11/1/07, Chuck Anderson <cra at wpi.edu> wrote:
> Since when do we care about who ships what first?

I think its fair to say that people want to get some credit for the
hard work they are point into getting the deeper design stuff "right."
 It matters to developer morale and to overall health of the project.
We have to do a much better job at being able to point out the cool
crap that is going on under the hood and getting the laypress talking
about it and getting end-users excited about it.  The hard work needs
to be appreciated exactly because its HARD work.

But we seem to be stuck in a linux enthusiastic culture where the
technology under the hood isn't as important as the paint job and the
futurist styling.  We have to try to change the tone of the
discussion. We have to find a way to encourage people who are writing
articles and reviews to stop focusing on the immediate shallow gains
of each distribution release, but to start talking about how the
technology introduced in each release enables advances in future
releases.  As long as releases are reviewed as end-products and not an
steps along a path, the HARD work that Fedora developers are doing
will always be less applauded than it deserves to be.

But how do we do this?  My best idea would be to start extending the
Feature proposal process so that it has a multiple release horizon for
features, with technology milestones per release along that feature
path.  This gives us legitimate "technology preview" talking points
for features introduced in a release that aren't completely there yet
without the pressure of flipping the switch and turning them on by
default to claim them as our own.

-jef



From myfedora at richip.dhs.org  Thu Nov  1 20:54:07 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 01 Nov 2007 14:54:07 -0600
Subject: knetworkmanager, nm-0.7
In-Reply-To: <604aa7910711011340t17ca82c1l63a0780c6dc4381e@mail.gmail.com>
References: <4727E19F.1010405@fedoraproject.org>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org> <47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<20071101115723.5628d3fb@redhat.com> <fgd26j$kgu$1@ger.gmane.org>
	<1193939532.4063.28.camel@localhost.localdomain>
	<20071101202037.GA18705@angus.ind.WPI.EDU>
	<604aa7910711011340t17ca82c1l63a0780c6dc4381e@mail.gmail.com>
Message-ID: <1193950447.5338.11.camel@localhost6.localdomain6>

On Thu, 2007-11-01 at 12:40 -0800, Jeff Spaleta wrote:
> On 11/1/07, Chuck Anderson <cra at wpi.edu> wrote:
> > Since when do we care about who ships what first?
> 
> I think its fair to say that people want to get some credit for the
> hard work they are point into getting the deeper design stuff "right."
>  It matters to developer morale and to overall health of the project.
> We have to do a much better job at being able to point out the cool
> crap that is going on under the hood and getting the laypress talking
> about it and getting end-users excited about it.  The hard work needs
> to be appreciated exactly because its HARD work.

+100

You don't know how frustrating it can get whenever you hear some news
about Ubuntu-this or Ubuntu-that. Heck, I just read this recent article
entitled "In-Depth Roadmap Analysis For Ubuntu Hardy Heron 8.04" and I'm
surprised to see how far back Ubuntu lags Fedora, and yet none of it
gets publicized. It can be very demoralizing to hear that now Wal-mart
is releasing an Everex Linux PC based on Ubuntu so that people start
equating linux with Ubuntu. There are so many talented people working
behind Fedora. Granted, the reason that lay people are so enamored with
Ubuntu is because Ubuntu devs are doing everything they can to satisfy
their wants while Fedora devs want a technically-superior product that
is still easy to use. In the meantime, Fedora devs keep plodding along
knowing in their hearts that they're doing the right thing, but how far
can that take not being appreciated.

Rahul and Max have done a fine job of getting recognized, but still, we
have to beef up marketing and advertising as well as prioritizing making
Fedora easy to use and choice-friendly while maintaining high technical
standards.

Say what you will, but for me, a great motivator for continuing to work
and innovate is the satisfaction seeing my work used, appreciated and
occasionally complimented.

If it makes any diff.: To Fedora devs, _I_ get what you guys are doing
and I'm doing my best to get people to recognize that in my little
corner of the globe.
--

Richi Plana



From caillon at redhat.com  Thu Nov  1 23:23:05 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 02 Nov 2007 00:23:05 +0100
Subject: knetworkmanager, nm-0.7
In-Reply-To: <fgd26j$kgu$1@ger.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<20071101115723.5628d3fb@redhat.com>
	<fgd26j$kgu$1@ger.gmane.org>
Message-ID: <472A5FD9.2080500@redhat.com>

Rex Dieter wrote:
> (1) Of course, 'twould have been *much* better to have introduced nm-0.7
> much earlier in the release cycle, I think we can all agree to that.

I can't.  Much earlier in the release cycle, NM was not functioning to 
any level of usefulness.  So, we'd have had a rawhide with "broken" 
networking for everybody that had forgotten how to use ifconfig and 
iwconfig and all those nasty command-line thingies.



From caillon at redhat.com  Thu Nov  1 23:34:59 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 02 Nov 2007 00:34:59 +0100
Subject: KDE logout options with F8
In-Reply-To: <loom.20071101T152020-62@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
Message-ID: <472A62A3.1050504@redhat.com>

Kevin Kofler wrote:
> Christopher Aillon <caillon <at> redhat.com> writes:
>> We should get to the point where we have one login manager, and just 
>> swap out the toolkits/UI.  Logging in is something that we seriously 
>> should not have multiple packages for.
> 
> And then what guarantees us the KDE frontend is not going to get the same 
> treatment KNetworkManager got for F8 (i.e. the backend getting upgraded to an 
> experimental, completely incompatible snapshot which is not supported by the 
> KDE frontend yet, and way too late in the release cycle (after the feature 
> freeze!) so there's no way the KDE frontend can be fixed in time)?

Without people that care about making things work actually stepping up 
to _do_ the work, you have no guarantees about anything ever working.

When NM 0.7 was first added to rawhide, even the GNOME applet was not 
really functioning.  Connecting to wireless networks was not even 
implemented in the applet.  VPN didn't work, and a plethora of other 
bugs.  Yet the GNOME applet now works for F8.  I truly believe that if 
someone cared enough, the KDE applet would also be working.

> The way NetworkManager 0.7 has been handled in F8 makes me very distrustful of 
> such "one backend, multiple frontend" solutions.

We made it clear from the start of the F8 cycle that we were going to be 
doing the NM feature, and it was tracked in FESCo meetings.  So the fact 
that KNM is non functioning should not be a reflection on anything other 
than lack of people doing the work for KNM.



From rodd at clarkson.id.au  Fri Nov  2 02:56:50 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 02 Nov 2007 13:56:50 +1100
Subject: file system mount
In-Reply-To: <loom.20071101T152643-909@post.gmane.org>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
Message-ID: <1193972210.13091.5.camel@localhost.localdomain>


On Thu, 2007-11-01 at 15:29 +0000, Kevin Kofler wrote:
> Amitakhya Phukan <aphukan <at> fedoraproject.org> writes:
> > i have a system with fedora 7 and rhel 5 installed. recently, i changed
> > the f7 to rawhide. now whenever i boot up, it mounts all the file
> > systems related to rhel5 along with it and displays on the desktop.
> > dmesg says /dev/sda1 mounted on /media/_1 and so on. I want to disable
> > this feature. i don't know if this is anything useful ?? i even don't
> > know if its a feature or a bug... can any one please help me out with
> > this thing ? i understand hal is doing this (??), but why ? and even
> > when i unmount it, the same can still be found in /media. right clicking
> > on those partitions give me the option of mounting/unmounting them. but
> > i don't want to let them appear in my rawhide systems totally. anyone
> > else has this experience on rawhide??how do i disable it ??
> 
> Fedora 7 has a file called
> /usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi
> to prevent this from happening, here's its contents:
> <?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->
> 
> <deviceinfo version="0.2">
> <device>
>   <match key="@block.storage_device:storage.hotpluggable" bool="false">
>     <match key="@block.storage_device:storage.removable" bool="false">
>       <merge key="volume.ignore" type="bool">true</merge>
>     </match>
>   </match>
> </device>
> </deviceinfo>
> 
> If that file is no longer there in Fedora 8, try adding it and see if that 
> helps.


Kevin,

I've had a collection of mounts on my HD that I hadn't seen show up in
f7, but were showing in rawhide in the disk mounter applet.

The mounts included:

'/' (I'm using '/1' for this install),

'/var' (which should be '/var/www' anyway, and was already mounted
as /var/www in my filesystem),

'/mnt/vmware' (which was mounted and already a part of my filesystem),
and

'/boot' (this install of rawhide has '/boot' as part of '/1')

and aren't the sort of thing I would have thought should have been
showing up as available.

The addition of this file above has removed them from appearing in the
disk mounter applet.  Should it be included in f8 by default?  From
where I sit, it makes things as I would expect them to be.


R.

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From kevin.kofler at chello.at  Fri Nov  2 03:48:29 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 2 Nov 2007 03:48:29 +0000 (UTC)
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<472A62A3.1050504@redhat.com>
Message-ID: <loom.20071102T034429-412@post.gmane.org>

Christopher Aillon <caillon <at> redhat.com> writes:
> We made it clear from the start of the F8 cycle that we were going to be 
> doing the NM feature, and it was tracked in FESCo meetings.  So the fact 
> that KNM is non functioning should not be a reflection on anything other 
> than lack of people doing the work for KNM.

So to sum up, "tough, we won't ever wait for KDE to support a new version 
before upgrading, even if the version we're upgrading to hasn't even been 
released yet". Yet if it had been us KDE SIG folks doing the upgrade, the GNOME 
frontend broken and the KDE one updated in time, I'm sure you would have forced 
us to revert the backend and complained loudly about us upgrading to an 
unstable version which breaks GNOME. But upgrading to an unstable version which 
breaks KDE is acceptable. :-/

        Kevin Kofler



From kevin.kofler at chello.at  Fri Nov  2 03:52:00 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 2 Nov 2007 03:52:00 +0000 (UTC)
Subject: knetworkmanager, nm-0.7
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<20071101115723.5628d3fb@redhat.com>
	<fgd26j$kgu$1@ger.gmane.org> <472A5FD9.2080500@redhat.com>
Message-ID: <loom.20071102T034840-757@post.gmane.org>

Christopher Aillon <caillon <at> redhat.com> writes:
> I can't.  Much earlier in the release cycle, NM was not functioning to 
> any level of usefulness.  So, we'd have had a rawhide with "broken" 
> networking for everybody that had forgotten how to use ifconfig and 
> iwconfig and all those nasty command-line thingies.

So the right thing would have been to postpone the feature to F9, not squeeze 
it into F8 after the feature freeze, without caring about what breaks.

        Kevin Kofler



From asayama at sm.sony.co.jp  Fri Nov  2 04:36:22 2007
From: asayama at sm.sony.co.jp (Kazunori Asayama)
Date: Fri, 02 Nov 2007 13:36:22 +0900 (JST)
Subject: rawhide report: 20071031 changes
Message-ID: <20071102.133622.123368474.asayama@echo.sm.sony.co.jp>

Yuan Yijun wrote:
>   Updating  : selinux-policy               ##################### [ 32/125]
>   Updating  : selinux-policy-mls           ##################### [ 33/125]
> libsepol.mls_from_string: invalid MLS context s0:
> libsepol.mls_from_string: could not construct mls context structure
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> libsepol.sepol_context_to_sid: could not convert
> system_u:object_r:fixed_disk_device_t:s0: to sid
> invalid context system_u:object_r:fixed_disk_device_t:s0:
> libsemanage.semanage_install_active: setfiles returned error code 1.
> semodule:  Failed!
>   Updating  : selinux-policy-targeted      ##################### [ 34/125]
> libsepol.mls_from_string: invalid MLS context s0:s0
> libsepol.mls_from_string: could not construct mls context structure
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> libsepol.sepol_context_to_sid: could not convert
> system_u:object_r:fixed_disk_device_t:s0:s0 to sid
> invalid context system_u:object_r:fixed_disk_device_t:s0:s0
> libsemanage.semanage_install_active: setfiles returned error code 1.
> semodule:  Failed!

PS3 can't boot maybe due to the same error. The udev complains as
following when booting and the hard disk drive 'ps3d' cannot be
accessed:

  udevd-event[492]: file_contexts:  invalid context system_u:object_r:fixed_disk_device_t:s0:s0

  udevd-event[492]: selinux_setfilecon: matchpathcon(/dev/ps3da) failed
  ...

It looks like there is an extra ':s0' at the end of the entry of
'/dev/ps3d.*'.



From vikigoyal at gmail.com  Fri Nov  2 05:24:48 2007
From: vikigoyal at gmail.com (Vikram Goyal)
Date: Fri, 2 Nov 2007 10:54:48 +0530
Subject: KDE logout options with F8
In-Reply-To: <4729A874.4090100@redhat.com>
References: <4729A874.4090100@redhat.com>
Message-ID: <20071102052448.GA12297@holycow.viki.com>

On Thu, Nov 01, 2007 at 11:20:36AM +0100, Christopher Aillon wrote:
> Joachim Frieben wrote:
> >>Please don't drag upstream X.org into this, xdm is a horror upstream is
> >>glad gdm/kdm exist and merely continue shipping xdm as something for
> >>system builders..
> >>
> >>it isn't valuable or valid.
> >>
> >>Dave.
> >
> >Nevertheless, a user who simply wants a plain X environment is encumbered 
> >by packages he hasn't asked for [GDM + GNOME requires] without even the 
> >possibility to dismiss them during install.
> >I suppose that a user who deliberately unchecks GNOME and KDE does know 
> >what he wants and does and imposing GDM onto him is against the often 
> >cited 'freedom of choice' unless you consider tracking down and 
> >uninstalling the related packages by the user post install as a reasonable 
> >duty.
> >I have used XDM for a couple of years back when Red Hat Linux still booted 
> >into runlevel 3 by default, and I had no complaints about it.
> 
> Or maybe they just unchecked both because the words "GNOME" and "KDE" 
> mean nothing to them, coming from a win/mac background.  Or maybe they 
> aren't used to their trackpad's behavior under linux and uncheck one of 
> them (both aren't checked by default, IIRC) accidentally.  If the user 
> is truly advanced enough, there are other and IMO better ways to get the 
> exact package set that they want.  Such as kickstart, re-spinning, etc.
> 
This can be avoided two ways maybe:

1} One of them can be greyed out. No changes can be done i.e selected by
   default;)
2} A big fat 'clear and present danger' warning can be displayed to the
   user about where he/she is going to land.
-- 
vikram...
         ||||||||
         ||||||||
^^'''''^^||root||^^^'''''''^^
        // \\   ))
       //(( \\// \\
      // /\\ ||   \\
     || / )) ((    \\
-- 
"I'd love to go out with you, but I'm converting my calendar watch from
Julian to Gregorian."
-- 
 #
~|~
 =



From spng.yang at gmail.com  Fri Nov  2 06:02:59 2007
From: spng.yang at gmail.com (Ken YANG)
Date: Fri, 02 Nov 2007 14:02:59 +0800
Subject: is there GUI tools to change partition label?
Message-ID: <472ABD93.1010509@gmail.com>


hi all,


we know e2label can change partition label, but
i found gparted can not change partition label.

are there some GUI tools to change partition label?

thanks in advance



From caillon at redhat.com  Fri Nov  2 07:41:08 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 02 Nov 2007 08:41:08 +0100
Subject: knetworkmanager, nm-0.7
In-Reply-To: <loom.20071102T034840-757@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<20071101115723.5628d3fb@redhat.com>	<fgd26j$kgu$1@ger.gmane.org>
	<472A5FD9.2080500@redhat.com>
	<loom.20071102T034840-757@post.gmane.org>
Message-ID: <472AD494.409@redhat.com>

Kevin Kofler wrote:
> Christopher Aillon <caillon <at> redhat.com> writes:
>> I can't.  Much earlier in the release cycle, NM was not functioning to 
>> any level of usefulness.  So, we'd have had a rawhide with "broken" 
>> networking for everybody that had forgotten how to use ifconfig and 
>> iwconfig and all those nasty command-line thingies.
> 
> So the right thing would have been to postpone the feature to F9, not squeeze 
> it into F8 after the feature freeze, without caring about what breaks.

Somehow the GNOME applet works, even though it was pretty much the same 
state the KDE one is when it first landed.  If someone wanted it to work 
badly enough, it would be.  Because all the notice in the world was given.



From caillon at redhat.com  Fri Nov  2 08:26:29 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 02 Nov 2007 09:26:29 +0100
Subject: KDE logout options with F8
In-Reply-To: <loom.20071102T034429-412@post.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<472A62A3.1050504@redhat.com>
	<loom.20071102T034429-412@post.gmane.org>
Message-ID: <472ADF35.6040608@redhat.com>

Kevin Kofler wrote:
> Christopher Aillon <caillon <at> redhat.com> writes:
>> We made it clear from the start of the F8 cycle that we were going to be 
>> doing the NM feature, and it was tracked in FESCo meetings.  So the fact 
>> that KNM is non functioning should not be a reflection on anything other 
>> than lack of people doing the work for KNM.
> 
> So to sum up, "tough, we won't ever wait for KDE to support a new version 
> before upgrading, even if the version we're upgrading to hasn't even been 
> released yet". Yet if it had been us KDE SIG folks doing the upgrade, the GNOME 
> frontend broken and the KDE one updated in time, I'm sure you would have forced 
> us to revert the backend and complained loudly about us upgrading to an 
> unstable version which breaks GNOME. But upgrading to an unstable version which 
> breaks KDE is acceptable. :-/

I'm still waiting on the KDE guys to come through with fixing the Qt 
Firefox port.  We allowed them to check in code to Mozilla upstream, and 
  then they dropped it and haven't kept it up to date.  So we just CVS 
removed it from CVS HEAD this past week.

It's not like we're asking for a rewrite of both the backend and the 
frontend.  Just an applet (in Qt which I hear is so much easier to code 
for than GTK+).  Bottom line is: nobody did the work, we have a way to 
workaround it by forcing the GNOME applet, and this is the non-"default" 
spin.



From mk at crc.dk  Fri Nov  2 08:34:22 2007
From: mk at crc.dk (Mogens Kjaer)
Date: Fri, 02 Nov 2007 09:34:22 +0100
Subject: Fedora 8 blocker update - testers needed (still!)
In-Reply-To: <1193511065.4523.4.camel@localhost.localdomain>
References: <1193440738.3838.71.camel@metroid.rdu.redhat.com>	<4722784B.50508@fedoraproject.org>
	<1193511065.4523.4.camel@localhost.localdomain>
Message-ID: <472AE10E.6050308@crc.dk>

Will Woods wrote:
> On Sat, 2007-10-27 at 04:59 +0530, Rahul Sundaram wrote:
...
>> You might want to look at the status of
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=251493
>>
>> This appears to be hardware specific. If it can't fixed, the workaround 
>> should be documented in the common bugs page.
>>
>> Workaround is to boot with "pci=nomsi,nommconf"
> 
> Added to http://fedoraproject.org/wiki/Bugs/F8Common
> 
> davej's comment sounds like we might get a fix for this before F8. Cool!

The F8-RC3-x86_64 DVD boots for installation on an HP DC7700, and
the machine boots after installation without any extra kernel options.

Supercool!

Thank you very much.

Mogens

-- 
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk at crc.dk Homepage: http://www.crc.dk



From ich at frank-schmitt.net  Fri Nov  2 09:34:23 2007
From: ich at frank-schmitt.net (Frank Schmitt)
Date: Fri, 02 Nov 2007 10:34:23 +0100
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<472A62A3.1050504@redhat.com>
	<loom.20071102T034429-412@post.gmane.org>
	<472ADF35.6040608@redhat.com>
Message-ID: <m3bqadc7og.fsf@mid.gehheimdienst.de>

Christopher Aillon <caillon at redhat.com> writes:

> It's not like we're asking for a rewrite of both the backend and the
> frontend.  Just an applet (in Qt which I hear is so much easier to
> code for than GTK+).  Bottom line is: nobody did the work, we have a
> way to workaround it by forcing the GNOME applet, and this is the
> non-"default" spin.

Yeah, we understood. KDE users are second class citizens in Fedora. Bye.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.



From opensource at till.name  Fri Nov  2 09:36:01 2007
From: opensource at till.name (Till Maas)
Date: Fri, 02 Nov 2007 10:36:01 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711010801.40465.silfreed@silfreed.net>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
Message-ID: <200711021036.10842.opensource@till.name>

On Do November 1 2007, Douglas E. Warner wrote:

> My vote would be to *not* ignore packages that are in updates-testing; this
> is a real upgrade path problem for end-users, despite whether the packages
> will be available "soon".

Imho it should be valid to have a package in F7 updates-testing with a higher 
nevr than in F8. Afaik targets updates-testing at experienced users who are 
willing to test packages and should be able to handle situations, where there 
is no upgrade path to the next stable release. Otherwise it would be very 
annoying to get an update into the oldest supported Fedora release. E.g. one 
updates a package foo for devel, F8 and F7:

1) build the package for devel, F8, F7, create update announcements for F8 and 
F7.
2) Request push to testing for F8
[wait]
3) Request push to stable for F8
[wait]
4) Request push to testing for F7
[wait]
5) Request push to stable for F7

This doubles the work for every maintainer to get an update for one package 
because one has to login twice as much into bodhi.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/eb848698/attachment.sig>

From jkeating at redhat.com  Fri Nov  2 10:09:19 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 06:09:19 -0400
Subject: KDE logout options with F8
In-Reply-To: <m3bqadc7og.fsf@mid.gehheimdienst.de>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>
	<loom.20071101T152020-62@post.gmane.org>
	<472A62A3.1050504@redhat.com>
	<loom.20071102T034429-412@post.gmane.org>
	<472ADF35.6040608@redhat.com> <m3bqadc7og.fsf@mid.gehheimdienst.de>
Message-ID: <20071102060919.0dcfb947@redhat.com>

On Fri, 02 Nov 2007 10:34:23 +0100
Frank Schmitt <ich at frank-schmitt.net> wrote:

> Yeah, we understood. KDE users are second class citizens in Fedora.
> Bye.

You are what your (upstream) developers make of you.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/90305a29/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Nov  2 10:09:58 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 02 Nov 2007 11:09:58 +0100
Subject: KDE logout options with F8
In-Reply-To: <m3bqadc7og.fsf@mid.gehheimdienst.de>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727B54A.4080806@fedoraproject.org>
	<20071031003225.GB3972@nostromo.devel.redhat.com>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<loom.20071031T041957-355@post.gmane.org>
	<m3bqadc7og.fsf@mid.gehheimdienst.de>
Message-ID: <1193998198.21573.24.camel@rousalka.dyndns.org>


Le vendredi 02 novembre 2007 ? 10:34 +0100, Frank Schmitt a ?crit :

> Yeah, we understood. KDE users are second class citizens in Fedora. Bye.

No you've not understood. Fedora is not merely in the business of
distributing upstream (GNOME or KDE) projects. It's also doing
development. When one Fedora group develops or is deeply involved in a
new feature (new gcc, fixing the distro for UTF-8, selinux, pulseaudio
etc) every other group in the distro is supposed to follow suit and use
the new feature on the announced target. Because Fedora wants to create
new innovative features and that'll only happen if there is distro-wide
solidarity with the Fedora groups that do create those features.

The KDE SIG does not get any special dispensation because one feature
has been mostly developed by GNOME people and they can't stomack
anything starting with G.

And that's not a KDE users vs GNOME users thing, that's a KDE developers
vs GNOME developers thing, and all our users are Fedora users foremost.
You do not "own" users exclusively, just because they use your apps does
not mean your agenda is the users agenda (and I've written this to Java
developers, OpenOffice.org developers, etc before, so don't go oppressed
KDE user on me now)

You're part of the $distro you follow the $distro agenda. You want a say
in the $distro agenda you develop innovative stuff @$distro that will
make $distro shine.

And there is the sad (for you) fact that Red Hat is involved in Fedora,
and Red Hat pays GNOME people, so you have paid GNOME people in Fedora
doing work that orients Fedora GNOME-way. If you want to balance things
out the path is not hampering the Red Hat-paid GNOME Fedora people but
get one way or another more KDE developers involved in Fedora.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/50a85cf3/attachment.sig>

From caillon at redhat.com  Fri Nov  2 10:12:37 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 02 Nov 2007 11:12:37 +0100
Subject: KDE logout options with F8
In-Reply-To: <m3bqadc7og.fsf@mid.gehheimdienst.de>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<472A62A3.1050504@redhat.com>	<loom.20071102T034429-412@post.gmane.org>	<472ADF35.6040608@redhat.com>
	<m3bqadc7og.fsf@mid.gehheimdienst.de>
Message-ID: <472AF815.1070603@redhat.com>

Frank Schmitt wrote:
> Yeah, we understood. KDE users are second class citizens in Fedora. Bye.

I'm more complaining about the (upstream) developers than the users.  We 
obviously care about the users because we're doing the workaround for them.

What if KNM isn't ready for F9?  Do we still hold back on moving GNOME 
forward because we don't have a KDE version working?  How long do we 
have to wait for KDE development to catch up?

Yes, I understand more time would have been nice for F8.  But it would 
have also been nice if the upstream KNM maintainer would have comitted 
his code to SVN sooner instead of sitting on it.  That prevented testing 
in Fedora sooner, and prevented bug fixes getting back to him.

If people want a good experience for KDE all around, then we could use 
some development work.  Join the KDE SIG.  Help make sure that upstream 
developers get their code released publicly.  Contribute fixes and code. 
  Because if we don't have enough people doing that, Fedora KDE will 
suffer.  It just so happens that nobody bothered to do the work in time.



From buildsys at redhat.com  Fri Nov  2 10:23:44 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 2 Nov 2007 06:23:44 -0400
Subject: rawhide report: 20071102 changes
Message-ID: <200711021023.lA2ANiJQ030284@porkchop.devel.redhat.com>

 

Removed package jogl

Updated Packages:

anaconda-11.3.0.50-2
--------------------
* Thu Nov 01 2007 Peter Jones <pjones at redhat.com> - 11.3.0.50-2
- Fix path for swapoff in fix for #357401 .

rhgb-1:0.17.7-3.fc8
-------------------
* Thu Nov 01 2007 Ray Strode <rstrode at redhat.com> 0.17.7-3
- Downgrade rhgb for F-8 release, since 8.0.2 is causing
  problems on some machines.

rhpxl-0.49-2.fc8
----------------
* Thu Nov 01 2007 Jeremy Katz <katzj at redhat.com> - 0.49-2
- Workaround for crasher when starting firstboot (#362721)

* Thu Sep 06 2007 Adam Jackson <ajax at redhat.com> 0.49-1
- rhpxl 0.49.  Fixes domainful PPC machines, and avoids probing for serial
  mice since they make USB devices go boom.
- Fix License.
- Update URL to point to the new home.

Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  2 10:33:35 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 2 Nov 2007 11:33:35 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711021036.10842.opensource@till.name>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
Message-ID: <20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 02 Nov 2007 10:36:01 +0100, Till Maas wrote:

> Imho it should be valid to have a package in F7 updates-testing with a higher 
> nevr than in F8.

Why isn't the same update built also for F8?
Why do you want to limit the testing to one dist?

> Afaik targets updates-testing at experienced users

And rawhide also targets experienced users, doesn't it?

> who are 
> willing to test packages and should be able to handle situations, where there 
> is no upgrade path to the next stable release.

The fun will start when we get multiple updates-testing repositories.
So far, F7 updates-testing has been the only one.

For some time we've excluded F7 updates-testing from the upgradepath
check, only to notice that F8 test1 got nearer and nearer with
packagers not preparing their updates (often even version upgrades)
for 'devel' at all. Unless it's a version upgrade, it's always
possible to update an old dist without breaking the upgrade path
(just increase %{release} appropriately).

Maybe in the future, the upgrade-path warning will be integrated into
the updates system. That might be less annoying than receiving a mail.



From rc040203 at freenet.de  Fri Nov  2 10:41:36 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 11:41:36 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1194000096.3454.23.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 11:33 +0100, Michael Schwendt wrote:
> On Fri, 02 Nov 2007 10:36:01 +0100, Till Maas wrote:
> 
> > Imho it should be valid to have a package in F7 updates-testing with a higher 
> > nevr than in F8.
ACK.

> Why isn't the same update built also for F8?
> Why do you want to limit the testing to one dist?
E.g. to evaluate for distro specific issues? Remember, that though a
particular spec might be identical for different distros, it's
infrastructure underneath might be different.

> For some time we've excluded F7 updates-testing from the upgradepath
> check,
Which is the correct approach, IMO, because testing will receive
experimental stuff, which is by no means guaranteed to end up in
"updates".

Ralf




From harald at redhat.com  Fri Nov  2 10:55:20 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 02 Nov 2007 11:55:20 +0100
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <1193924167.21765.78.camel@localhost.localdomain>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<1193924167.21765.78.camel@localhost.localdomain>
Message-ID: <fgevmo$pt1$1@ger.gmane.org>

Tom "spot" Callaway wrote:
> On Thu, 2007-11-01 at 10:47 +0300, Peter Lemenkov wrote:
>> What about US?
> 
> The Fraunhofer/Thomson patents have not expired in the US.
> They are not willing to give us an unrestricted patent grant.
> 
> US Patent 5559834 expires September 24, 2013
> US Patent 4942607 expires February 3, 2008
> US Patent 5812672 expires September 2, 2015
> US Patent 5579430 expires November 26, 2013
> US Patent 5321729 expires June 24, 2011
> US Patent 5706309 expires January 6, 2015
> US Patent 5227990 expires July 13, 2010
> US Patent 4821260 expires December 16, 2007
> US Patent 5214742 expires May 25, 2010
> US Patent 6185539 expires February 6, 2018
> US Patent 5703999 expires November 18, 2016
> US Patent 5924060 expires July 13, 2016
> US Patent 5701346 expires February 2, 2015
> US Patent 6009399 expires April 16, 2017
> US Patent 5384811 expires January 24, 2012
> US Patent 5736943 expires April 7, 2015
> US Patent 5742735 expires April 21, 2015
> US Patent 5455833 expires October 3, 2012

So, in Fedora 28 we may be able to include MP3 support? :)

> 
> In addition, Alcatel-Lucent holds patents which may relate to MP3 and
> MPEG encoding. This is still pending appeal (Alcatel-Lucent v
> Microsoft). It is not clear whether they will give out an unstricted
> patent grant.
> 
> US Patent 5341457 expires Aug 20, 2013.
> US Patent RE39,080 expires April 25, 2023.
> 
> ~spot
> 



From limb at jcomserv.net  Fri Nov  2 10:55:23 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 2 Nov 2007 05:55:23 -0500 (CDT)
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <fgevmo$pt1$1@ger.gmane.org>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<1193924167.21765.78.camel@localhost.localdomain>
	<fgevmo$pt1$1@ger.gmane.org>
Message-ID: <3269.63.85.68.164.1194000923.squirrel@mail.jcomserv.net>


> Tom "spot" Callaway wrote:
>> On Thu, 2007-11-01 at 10:47 +0300, Peter Lemenkov wrote:
>>> What about US?
>>
>> The Fraunhofer/Thomson patents have not expired in the US.
>> They are not willing to give us an unrestricted patent grant.
>>
>> US Patent 5559834 expires September 24, 2013
>> US Patent 4942607 expires February 3, 2008
>> US Patent 5812672 expires September 2, 2015
>> US Patent 5579430 expires November 26, 2013
>> US Patent 5321729 expires June 24, 2011
>> US Patent 5706309 expires January 6, 2015
>> US Patent 5227990 expires July 13, 2010
>> US Patent 4821260 expires December 16, 2007
>> US Patent 5214742 expires May 25, 2010
>> US Patent 6185539 expires February 6, 2018
>> US Patent 5703999 expires November 18, 2016
>> US Patent 5924060 expires July 13, 2016
>> US Patent 5701346 expires February 2, 2015
>> US Patent 6009399 expires April 16, 2017
>> US Patent 5384811 expires January 24, 2012
>> US Patent 5736943 expires April 7, 2015
>> US Patent 5742735 expires April 21, 2015
>> US Patent 5455833 expires October 3, 2012
>
> So, in Fedora 28 we may be able to include MP3 support? :)

Actually, if we don't slip schedules too badly, (2018-2007)*2+8= Fedora
30.  Or, I suppose, 29, if it's Feb 6 2018. :)

-- 
novus ordo absurdum



From harald at redhat.com  Fri Nov  2 11:05:45 2007
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 02 Nov 2007 12:05:45 +0100
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <3269.63.85.68.164.1194000923.squirrel@mail.jcomserv.net>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>	<1193924167.21765.78.camel@localhost.localdomain>	<fgevmo$pt1$1@ger.gmane.org>
	<3269.63.85.68.164.1194000923.squirrel@mail.jcomserv.net>
Message-ID: <fgf0a9$vsu$1@ger.gmane.org>

Jon Ciesla wrote:
>> So, in Fedora 28 we may be able to include MP3 support? :)
> 
> Actually, if we don't slip schedules too badly, (2018-2007)*2+8= Fedora
> 30.  Or, I suppose, 29, if it's Feb 6 2018. :)
> 

Doh, my internal clock is already set to 2008 :)



From limb at jcomserv.net  Fri Nov  2 11:01:56 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 2 Nov 2007 06:01:56 -0500 (CDT)
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <fgf0a9$vsu$1@ger.gmane.org>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<1193924167.21765.78.camel@localhost.localdomain>
	<fgevmo$pt1$1@ger.gmane.org>
	<3269.63.85.68.164.1194000923.squirrel@mail.jcomserv.net>
	<fgf0a9$vsu$1@ger.gmane.org>
Message-ID: <6029.63.85.68.164.1194001316.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>>> So, in Fedora 28 we may be able to include MP3 support? :)
>>
>> Actually, if we don't slip schedules too badly, (2018-2007)*2+8= Fedora
>> 30.  Or, I suppose, 29, if it's Feb 6 2018. :)
>>
>
> Doh, my internal clock is already set to 2008 :)

I thought so, if you were a bit less far off I'd have said you needed to
yum update tzdata. :)

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From laroche at redhat.com  Fri Nov  2 11:29:54 2007
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 2 Nov 2007 12:29:54 +0100
Subject: updated git repos
Message-ID: <20071102112954.GA7005@dudweiler.stuttgart.redhat.com>

Hello all,

http://jur-linux.org/git/ is now updated to track
many current fedora projects. Also git was updated
to the newest upstream release 1.5.3.5.
Let me know if you stilll find anything unusual or
want to propose a change/addition.

Loading the summary page can still take quite some time
as this server is also a Fedora mirror, so the overview
page often needs to read in all data from disk.

If anyone feels like hacking on gitweb: The main summary
page only displays the time of last change as special info
on the individual projects, so if that part would not call
"git" as external app, then loading that page should be much
less of a resource problem.

regards,

Florian La Roche



From opensource at till.name  Fri Nov  2 11:40:53 2007
From: opensource at till.name (Till Maas)
Date: Fri, 02 Nov 2007 12:40:53 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200711021240.58803.opensource@till.name>

On Fr November 2 2007, Michael Schwendt wrote:
> On Fri, 02 Nov 2007 10:36:01 +0100, Till Maas wrote:
> > Imho it should be valid to have a package in F7 updates-testing with a
> > higher nevr than in F8.
>
> Why isn't the same update built also for F8?

I did not say, that the update is not built for F8, but it will be in F8 
updates-testing and not in F8.

> Why do you want to limit the testing to one dist?

I want to have testing simultaneously for two dists, with a package in F-7 
updates-testing and F-8 updates-testing. But then there will be no upgrade 
path from F-7 updates-testing to F-8. There will be one to F-8 
updatest-testing.

> > Afaik targets updates-testing at experienced users
>
> And rawhide also targets experienced users, doesn't it?

Yes and not every rpm/update in Rawhide makes it into the next stable release 
and there are also rpms that are removed from rawhide without adding a newer 
version afaik.

> > who are
> > willing to test packages and should be able to handle situations, where
> > there is no upgrade path to the next stable release.
>
> The fun will start when we get multiple updates-testing repositories.
> So far, F7 updates-testing has been the only one.
>
> For some time we've excluded F7 updates-testing from the upgradepath
> check, only to notice that F8 test1 got nearer and nearer with
> packagers not preparing their updates (often even version upgrades)
> for 'devel' at all. Unless it's a version upgrade, it's always
> possible to update an old dist without breaking the upgrade path
> (just increase %{release} appropriately).

Imho the only solution here is to warn the maintainer when a push to stable is 
requested and this would break the upgrade path. But when there is a valid 
upgrade path from F-7 updates-testing to F-8 updates-testing (but not from 
F-7 to F-8), then this should not be a problem.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/847991e3/attachment.sig>

From rdieter at math.unl.edu  Fri Nov  2 11:52:20 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 02 Nov 2007 06:52:20 -0500
Subject: KDE logout options with F8
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<472A62A3.1050504@redhat.com>
	<loom.20071102T034429-412@post.gmane.org>
	<472ADF35.6040608@redhat.com>
Message-ID: <fgf31k$991$1@ger.gmane.org>

Christopher Aillon wrote:


> I'm still waiting on the KDE guys to come through with fixing the Qt
> Firefox port.  We allowed them to check in code to Mozilla upstream, and
>   then they dropped it and haven't kept it up to date.  So we just CVS
> removed it from CVS HEAD this past week.

Don't even go there.  

-- Rex



From somlo at cmu.edu  Fri Nov  2 11:55:55 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Fri, 2 Nov 2007 07:55:55 -0400
Subject: Fedora 8 test on Mac Pro ?
Message-ID: <20071102115555.GC18109@hedwig.net.cmu.edu>

I'm trying to set up Fedora 8 test on a Mac Pro, and while the install
completed smoothly, it hangs when booting from the hard drive, in
rc.sysinit, at or immediately after running /sbin/start_udev.

I booted off the rescue disk and ran yum update successfully. Now, it
manages to get as far as 'Setting hostname', still in rc.sysinit,
before freezing up completely.

Is this a known problem ? Any ideas about how to proceed pinning down
the root cause ?

Thanks much,
Gabriel



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  2 11:56:20 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 2 Nov 2007 12:56:20 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194000096.3454.23.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
Message-ID: <20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 02 Nov 2007 11:41:36 +0100, Ralf Corsepius wrote:

> > Why isn't the same update built also for F8?
> > Why do you want to limit the testing to one dist?
>
> E.g. to evaluate for distro specific issues? Remember, that though a
> particular spec might be identical for different distros, it's
> infrastructure underneath might be different.

You didn't answer the questions, especially not because an "identical
spec" does not break any upgrade path. Differences in the build deps
don't either. And changes under the hood can be done with an increase
of the least-significant portion of the EVR, that is to the right of
%{?dist}, for instance. You don't bump V without properly evaluating a
version upgrade, first.

So, let me rephrase the questions:

Why is an update prepared and built for an older dist, which breaks
[read: will break] the upgrade path, without starting this
experimental activity in the latest dist? Why does that dist-specific
test-update get a higher EVR than released packages for the newer
dist(s), such as 'devel'?

For the very rare case that the results of the tests with the old dist
decide on the roadmap of the pkg in the newer dist(s), it still
creates a scenario in which an upgrade path gets broken. Because even
if the test-update remains in updates-testing forever, and in 'devel'
the pkg doesn't move forward, you require your guinea pigs to clean up
their installations manually, if you decide to not push the update
into stable.

> > For some time we've excluded F7 updates-testing from the upgradepath
> > check,
> Which is the correct approach, IMO, because testing will receive
> experimental stuff, which is by no means guaranteed to end up in
> "updates".

Too often it ends up in "updates", and that's not limited to updates
we can observe in Fedora Extras.



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  2 12:20:50 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 2 Nov 2007 13:20:50 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711021240.58803.opensource@till.name>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<200711021240.58803.opensource@till.name>
Message-ID: <20071102132050.407fbb59.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 02 Nov 2007 12:40:53 +0100, Till Maas wrote:

> > Why isn't the same update built also for F8?
> 
> I did not say, that the update is not built for F8, but it will be in F8 
> updates-testing and not in F8.

Where do you see a broken upgrade path then?

The upgrade path ends with:

  ... F8 + F8 updates + F8 updates-testing --> rawhide

An EVR upgrade in F8 updates-testing can only break the path to
rawhide, not the path to older dists.

When rawhide becomes F8 (i.e. F8 is released officially), we exclude it
from the upgrade path check for some time again, because it is normal
that may get behind in pkg EVRs (due to expected breakage of build
deps etc.) But while preparing the next gold release, it is important
to learn about broken upgrade paths.
 
> > Why do you want to limit the testing to one dist?
> 
> I want to have testing simultaneously for two dists, with a package in F-7 
> updates-testing and F-8 updates-testing. But then there will be no upgrade 
> path from F-7 updates-testing to F-8. There will be one to F-8 
> updatest-testing.

How do you know that the script will report a broken upgrade path in
that case? We don't have a 2nd testing repo yet. Skimming over the
part of the code, all that should matter is that the F8 test-update
has a higher EVR than the F7 test-update.  In short: packages in the
dist '8' repo family must have a pkg EVR that is '>=' than the EVR of
pkgs in the dist '7' repo family.

> > > Afaik targets updates-testing at experienced users
> >
> > And rawhide also targets experienced users, doesn't it?
> 
> Yes and not every rpm/update in Rawhide makes it into the next stable release 
> and there are also rpms that are removed from rawhide without adding a newer 
> version afaik.

Removed packages are ignored. Even a check for proper "Obsoletes"
would be insufficient.



From rc040203 at freenet.de  Fri Nov  2 12:42:55 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 13:42:55 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1194007375.3454.38.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 12:56 +0100, Michael Schwendt wrote:
> On Fri, 02 Nov 2007 11:41:36 +0100, Ralf Corsepius wrote:
> 
> > > Why isn't the same update built also for F8?
> > > Why do you want to limit the testing to one dist?
> >
> > E.g. to evaluate for distro specific issues? Remember, that though a
> > particular spec might be identical for different distros, it's
> > infrastructure underneath might be different.
> 
> You didn't answer the questions, especially not because an "identical
> spec" does not break any upgrade path. Differences in the build deps
> don't either. And changes under the hood can be done with an increase
> of the least-significant portion of the EVR, that is to the right of
> %{?dist}, for instance. You don't bump V without properly evaluating a
> version upgrade, first.
C'mon, you are once more trying to push people to adopt your (IMO:
broken) vision.

IMO, testing should not be off any relevance EVR wise, except for 2
cases:

- If a package is being pushed from testing to updates (currenly not
possible due to bodhi's design), the EVR must comply to the EVR in
"dist" and "dist+1"

- The EVR  of a package in testing must be greater than "dist".

Anything else is overengineering.

> So, let me rephrase the questions:
> 
> Why is an update prepared and built for an older dist, which breaks
> [read: will break] the upgrade path, without starting this
> experimental activity in the latest dist?
E.g. for what I said above.

Example: "Package X works in FC-8 but doesn't work in FC-7".

=> People start addressing the FC-7 issue by building packages for FC-7
and want their FC-7 audience to test their attempts. FC-8 is completely
irrelevant at this point.

Ralf




From sundaram at fedoraproject.org  Fri Nov  2 12:54:09 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 02 Nov 2007 18:24:09 +0530
Subject: knetworkmanager, nm-0.7
In-Reply-To: <1193950447.5338.11.camel@localhost6.localdomain6>
References: <4727E19F.1010405@fedoraproject.org>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>
	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<20071101115723.5628d3fb@redhat.com>
	<fgd26j$kgu$1@ger.gmane.org>	<1193939532.4063.28.camel@localhost.localdomain>	<20071101202037.GA18705@angus.ind.WPI.EDU>	<604aa7910711011340t17ca82c1l63a0780c6dc4381e@mail.gmail.com>
	<1193950447.5338.11.camel@localhost6.localdomain6>
Message-ID: <472B1DF1.9020005@fedoraproject.org>

Richi Plana wrote:

> Rahul and Max have done a fine job of getting recognized, but still, we
> have to beef up marketing and advertising as well as prioritizing making
> Fedora easy to use and choice-friendly while maintaining high technical
> standards.

Not directly at you personally but if half of the people who crib about 
it joined in the marketing efforts and helped out, we would be much 
further ahead than we are now.

Rahul



From opensource at till.name  Fri Nov  2 13:07:12 2007
From: opensource at till.name (Till Maas)
Date: Fri, 02 Nov 2007 14:07:12 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102132050.407fbb59.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711021240.58803.opensource@till.name>
	<20071102132050.407fbb59.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200711021407.21087.opensource@till.name>

On Fr November 2 2007, Michael Schwendt wrote:
> On Fri, 02 Nov 2007 12:40:53 +0100, Till Maas wrote:
> > > Why isn't the same update built also for F8?
> >
> > I did not say, that the update is not built for F8, but it will be in F8
> > updates-testing and not in F8.
>
> Where do you see a broken upgrade path then?
>
> The upgrade path ends with:
>
>   ... F8 + F8 updates + F8 updates-testing --> rawhide
>
> An EVR upgrade in F8 updates-testing can only break the path to
> rawhide, not the path to older dists.

Here is an example from the report:
    Zim
      F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
Zim-0.21-1.fc7 is in F7 updates-testing but the version in F8 is older. Btw. 
there is already a request to add Zim-0.21-1.fc8 to F8 updates-testing.

> How do you know that the script will report a broken upgrade path in
> that case? We don't have a 2nd testing repo yet. Skimming over the
> part of the code, all that should matter is that the F8 test-update
> has a higher EVR than the F7 test-update.  In short: packages in the
> dist '8' repo family must have a pkg EVR that is '>=' than the EVR of
> pkgs in the dist '7' repo family.

It seemed to me, that we discuss here, how we would like the script to behave. 
Btw. imho there should be a warning when a stable package in F7 is evr-higher 
than a stable package in F8, even when there is a newer package in 
F8-updates-testing.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/d85ec0ee/attachment.sig>

From kevin.kofler at chello.at  Fri Nov  2 13:10:05 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 2 Nov 2007 13:10:05 +0000 (UTC)
Subject: Package EVR problems in Fedora 2007-10-31
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
Message-ID: <loom.20071102T130254-644@post.gmane.org>

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> Which is the correct approach, IMO, because testing will receive
> experimental stuff, which is by no means guaranteed to end up in
> "updates".

But surely it should end up in updates-testing or updates for higher versions 
and in Rawhide too (except during the final devel freeze, in which case you 
should prepare the update as a 0-day testing update if it isn't suitable for 
tagging straight into the upcoming release).

IMHO the following inequalities should hold, where "stable" is release + 
(stable) updates:
Fedora n stable <= Fedora n testing
Fedora n stable <= Fedora n+1 stable
Fedora n testing <= Fedora n+1 testing
During the final devel freeze, Fedora n+1 stable/testing for Rawhide are the 
updates pending to be pushed to stable resp. testing at the point of the 
release. Otherwise, Rawhide is both Fedora n+1 stable and testing, which 
implies that Rawhide should normally have newer versions than updates-testing 
in any release when it's not frozen.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Nov  2 13:11:56 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 2 Nov 2007 13:11:56 +0000 (UTC)
Subject: Package EVR problems in Fedora 2007-10-31
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
Message-ID: <loom.20071102T131115-221@post.gmane.org>

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> Example: "Package X works in FC-8 but doesn't work in FC-7".
> 
> => People start addressing the FC-7 issue by building packages for FC-7
> and want their FC-7 audience to test their attempts. FC-8 is completely
> irrelevant at this point.

That's what the -n.fc7.1 versioning scheme is for.

        Kevin Kofler



From rc040203 at freenet.de  Fri Nov  2 13:37:12 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 14:37:12 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <loom.20071102T131115-221@post.gmane.org>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
Message-ID: <1194010632.3454.50.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 13:11 +0000, Kevin Kofler wrote:
> Ralf Corsepius <rc040203 <at> freenet.de> writes:
> > Example: "Package X works in FC-8 but doesn't work in FC-7".
> > 
> > => People start addressing the FC-7 issue by building packages for FC-7
> > and want their FC-7 audience to test their attempts. FC-8 is completely
> > irrelevant at this point.
> 
> That's what the -n.fc7.1 versioning scheme is for.
Wrong again. It's one (broken) way to approach this.

If you really want to force release tags, better automatically assign
them to packages (then YOU have full control over them), instead of
trying to push people around with your personals visions,

Ralf




From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  2 13:45:09 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 2 Nov 2007 14:45:09 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194007375.3454.38.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
Message-ID: <20071102144509.06f50983.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 02 Nov 2007 13:42:55 +0100, Ralf Corsepius wrote:

> C'mon, you are once more trying to push people to adopt your (IMO:
> broken) vision.

Ridiculous.

Actually, it's the opposite. I'm not the one who's fighting the use of
scripts like upgradecheck, just because some of its (not even daily)
mails are considered an annoyance by a few package maintainers. Take a
deep breath, mash warns about broken deps in rawhide every day, even
when a packager can only wait for another packager to fix something
first.

It's not even my script (except for contributions). If some committee
rules that the script must not be run anymore because packagers complain
about it, I've learnt to not care anymore. I draw my conclusions and
move on. Why spend time on stuff that's not appreciated?

But I distinguish between people, who think about improving the checks
(or who suggest improvements), and people who put most of their energy
into pointing out there negative views. Previously, when F7
updates-testing became mandatory, more maintainers have requested to
not ignore updates-testing in the checks.

Some of the scripts have saved many a packager's ass -- and more than
once. Broken upgrade paths have caused nasty soname/deps breakage
during dist upgrades before.

> - If a package is being pushed from testing to updates (currenly not
> possible due to bodhi's design),

?? What do you mean? How have the many packagers done it? Marking a
test update "stable" does work, doesn't it? Do you see a pattern in
the way you criticise achievements? You focus on any flaws you see,
totally ignoring the positive rest that has been real progress.

> Example: "Package X works in FC-8 but doesn't work in FC-7".

If it works, why isn't it put into F-8 (or devel)?

I can answer that for you.

Case 1) The usual procedure is that the packager still focuses on F-7
and does not use F-8/rawhide yet. The update is prepared for F-7 only,
neglecting F-8/rawhide completely.

Case 2) The usual %{?dist} and "make tag" breakage. Wrong release
bumps as the cause of broken upgrade paths.

Case 3) You refer to an already released pkg in F-7 and F-8, which is
reported as being broken in F-7 only. Let's assume you prepare a
version upgrade as a test update for F-7, not testing the same code
for F-8 or devel. You try to cherry-pick your target audience by
releasing an exclusive test upgrade for an old(er) dist, neglecting to
test the same stuff for the newer dists. What is so wrong about
warning about the broken upgrade path? Especially when you learn
that the test update works for F-7, you need to bring F-8 and devel
on par with F-7 anyway.

> => People start addressing the FC-7 issue by building packages for FC-7
> and want their FC-7 audience to test their attempts. FC-8 is completely
> irrelevant at this point.

It isn't, because if the test environments are so much different that
one dist malfunctions while the other doesn't, you need to test the
updates for both dists and not just for one. 

--- WARNING ---

Just for Ralf, the next upgradecheck report [send to this list only]
will exclude F-7 updates-testing. Have fun drawing *your* own
conclusions. :-/



From buildsys at fedoraproject.org  Fri Nov  2 13:45:34 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri,  2 Nov 2007 09:45:34 -0400 (EDT)
Subject: For Ralf: Package EVR problems in Fedora 2007-11-02
Message-ID: <20071102134534.0B9B615212D@buildsys.fedoraproject.org>

Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
FC6-updates, FE6, F7, F7-updates, F8

Fedora AT FamilleCollet com:
    glpi
      F7-updates > F8 (0:0.70-0.3.rc2.fc7 > 0:0.70-0.2.rc1.fc8)
    
akahl AT iconmobile com:
    php-channel-phing
      F7-updates > F8 (0:1.0.0-5.fc7 > 0:1.0.0-4.fc8)
    
andreas bierfert AT lowlatency de:
    rxvt-unicode
      F7-updates > F8 (0:8.4-1.fc7 > 0:8.3-1.fc8)
    
    wine
      F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)
    
    wine-docs
      F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)
    
aportal AT univ-montp2 fr:
    gputils
      FE6 > F7 (0:0.13.5-1.fc6 > 0:0.13.4-2.fc6)
      FE6 > F8 (0:0.13.5-1.fc6 > 0:0.13.4-4.fc8)
    
    kbackup
      FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
      FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)
    
    pikloops
      FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)
    
bjohnson AT symetrix com:
    dbmail
      FE6 > F7-updates (0:2.2.7-1.fc6 > 0:2.2.5-5.fc7)
      FE6 > F8 (0:2.2.7-1.fc6 > 0:2.2.5-7.fc8)
    
    gscan2pdf
      FE6 > F7-updates (0:0.9.17-2.fc6 > 0:0.9.16-1.fc7)
      FE6 > F8 (0:0.9.17-2.fc6 > 0:0.9.16-1.fc8)
    
    libsieve
      FE6 > F7 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
      FE6 > F8 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
    
    mailgraph
      FE6 > F7 (0:1.14-1.fc6 > 0:1.12-5.fc7)
      FE6 > F8 (0:1.14-1.fc6 > 0:1.12-5.fc7)
    
    perl-PDF-API2
      FE6 > F7-updates (0:0.65-1.fc6 > 0:0.62-2.fc7)
      FE6 > F8 (0:0.65-1.fc6 > 0:0.62-2.fc8)
    
    queuegraph
      FE6 > F7 (0:1.1-2.fc6 > 0:1.1-1.fc7)
      FE6 > F8 (0:1.1-2.fc6 > 0:1.1-1.fc7)
    
cgoorah AT yahoo com au:
    kdmtheme
      FE6 > F8 (0:1.2.1-1.fc6 > 0:1.1.3-2.fc8)
      F7-updates > F8 (0:1.2.1-1.fc7 > 0:1.1.3-2.fc8)
    
    piklab
      FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
      FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)
    
    toped
      F7-updates > F8 (0:0.8.6-1.fc7 > 0:0.8.5-2.fc8)
    
    xcircuit
      FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
      F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)
    
chris stone AT gmail com:
    cksfv
      FE6 > F8 (0:1.3.12-2.fc6 > 0:1.3.12-1.fc8)
      F7-updates > F8 (0:1.3.12-2.fc7 > 0:1.3.12-1.fc8)
    
    poker-network
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)
    
    poker2d
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
      FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)
    
cweyl AT alumni drew edu:
    Zim
      FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
      F7-updates > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
    
enrico scholz AT informatik tu-chemnitz de:
    libextractor
      FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)
    
    libtasn1
      FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
      FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)
    
    mimetic
      FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
      FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)
    
    util-vserver
      FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
      FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)
    
    xmlrpc-c
      FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
      FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)
    
foolish AT guezz net:
    gtk-recordmydesktop
      F7-updates > F8 (0:0.3.6-1.fc7.1 > 0:0.3.4-1.fc8.1)
    
    gtranslator
      F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)
    
    recordmydesktop
      F7-updates > F8 (0:0.3.6-1.fc7 > 0:0.3.4-1.fc8)
    
frank-buettner AT gmx net:
    ctapi-cyberjack
      FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
      F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)
    
gauret AT free fr:
    basket
      F7-updates > F8 (0:1.0.2-3.fc7 > 0:1.0.2-2.fc8)
    
gecko-maint AT redhat com:
    seamonkey
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)
    
gemi AT bluewin ch:
    q
      F7-updates > F8 (0:7.8-1.fc7 > 0:7.6-2.fc7)
    
    yap
      F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)
    
green AT redhat com:
    liblrdf
      FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)
    
    zynaddsubfx
      FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)
    
i AT stingr net:
    weechat
      F7-updates > F8 (0:0.2.6-1.fc7 > 0:0.2.5-1.fc8)
    
jeff AT ocjtech us:
    jrtplib
      FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)
    
jkeating AT redhat com:
    mock
      F7-updates > F8 (0:0.8.4-2.fc7 > 0:0.7.6-1.fc8)
    
john AT ncphotography com:
    bugzilla
      FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
      FE6 > F8 (0:3.0.2-2.fc6 > 0:3.0.2-0.fc8)
    
karen-pease AT uiowa edu:
    fortune-firefly
      FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
      FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)
    
    nethack-vultures
      FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)
    
lemenkov AT gmail com:
    flashrom
      FE6 > F7-updates (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc7)
      FE6 > F8 (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc8)
    
    fuse-python
      FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
      F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8)
    
lxtnow AT gmail com:
    specto
      FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
      F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)
    
    wammu
      FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
      F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)
    
mfleming+rpm AT enlartenment com:
    mcabber
      FE6 > F7-updates (0:0.9.4-1.fc6 > 0:0.9.3-3.fc7)
      FE6 > F8 (0:0.9.4-1.fc6 > 0:0.9.3-6.fc8)
    
    mlmmj
      FE6 > F7 (0:1.2.15-1.fc6 > 0:1.2.14-2.fc7)
    
michel sylvan AT gmail com:
    python-nltk
      FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
      FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)
    
mikeb AT redhat com:
    python-cheetah
      FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)
    
mmcgrath AT redhat com:
    cacti
      FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)
    
    nagios-plugins
      FE6 > F8 (0:1.4.8-9.fc6 > 0:1.4.8-7.fc8)
      F7-updates > F8 (0:1.4.8-9.fc7 > 0:1.4.8-7.fc8)
    
    phpMyAdmin
      FE6 > F8 (0:2.11.2-1.fc6 > 0:2.11.0-1.fc8)
      F7-updates > F8 (0:2.11.2-1.fc7 > 0:2.11.0-1.fc8)
    
    python-meld3
      FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
      FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
    
    smolt
      FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc7)
      FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)
    
mtasaka AT ioa s u-tokyo ac jp:
    jd
      F7-updates > F8 (0:1.9.7-0.2.beta071101.fc7 > 0:1.9.6-1.fc8)
    
    kazehakase
      FE6 > F8 (0:0.5.0-1.fc6 > 0:0.4.9-2.svn3312.fc8)
      F7-updates > F8 (0:0.5.0-1.fc7 > 0:0.4.9-2.svn3312.fc8)
    
    mirage
      FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
      F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)
    
    xscreensaver
      F7-updates > F8 (1:5.03-14.fc7 > 1:5.03-12.fc8)
    
nhorman AT redhat com:
    irqbalance
      FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
      FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)
    
nphilipp AT redhat com:
    rss-glx
      F7-updates > F8 (0:0.8.1.p-16.fc7 > 0:0.8.1.p-15.fc8)
    
ondrejj AT salstar sk:
    climm
      FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)
      F7-updates > F8 (0:0.6.1-1.fc7 > 0:0.6-2.fc8)
    
packages AT amiga-hardware com:
    kdetv
      FE6 > F8 (0:0.8.9-7.fc6 > 0:0.8.9-6.fc8)
      F7-updates > F8 (0:0.8.9-7.fc7 > 0:0.8.9-6.fc8)
    
    SILLY
      FE6 > F8 (0:0.1.0-4.fc6 > 0:0.1.0-3.fc8)
      F7-updates > F8 (0:0.1.0-4.fc7 > 0:0.1.0-3.fc8)
    
paul AT city-fan org:
    gnome-libs
      FE6 > F7 (1:1.4.2-7.fc6 > 1:1.4.2-5.fc7)
      FE6 > F8 (1:1.4.2-7.fc6 > 1:1.4.2-6.fc8)
    
pingoufc4 AT yahoo fr:
    rkward
      FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)
      F7-updates > F8 (0:0.4.8-2.fc7 > 0:0.4.7-4.fc8)
    
rc040203 AT freenet de:
    perl-DBIx-DBSchema
      FE6 > F8 (0:0.35-1.fc6 > 0:0.34-1.fc8)
      F7-updates > F8 (0:0.35-1.fc7 > 0:0.34-1.fc8)
    
    perl-File-NCopy
      F7-updates > F8 (0:0.35-3.fc7 > 0:0.34-6.fc8)
    
    perl-Params-Util
      F7-updates > F8 (0:0.30-1.fc7 > 0:0.29-1.fc8)
    
    perl-Set-IntSpan
      FE6 > F8 (0:1.13-1.fc6 > 0:1.12-1.fc8)
      F7-updates > F8 (0:1.13-1.fc7 > 0:1.12-1.fc8)
    
rcritten AT redhat com:
    mod_nss
      FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
      F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)
    
rmeggins AT redhat com:
    adminutil
      FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
      F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)
    
    mozldap
      FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
      F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)
    
robert AT marcanoonline com:
    eclipse-subclipse
      FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
      F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)
    
roland AT redhat com:
    monotone
      FE6 > F8 (0:0.37-3.fc6 > 0:0.36-2.fc8)
      F7-updates > F8 (0:0.37-3.fc7 > 0:0.36-2.fc8)
    
s adam AT diffingo com:
    fwfstab
      FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
      F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)
    
sandmann AT redhat com:
    libgtop2
      FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)
    
silfreed AT silfreed net:
    qgis
      FE6 > F7-updates (0:0.9.0-1.fc6 > 0:0.8.1-11.fc7)
    
splinux25 AT gmail com:
    lostirc
      FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)
    
tagoh AT redhat com:
    anthy
      F7-updates > F8 (0:9100d-1.fc7 > 0:9100b-1.fc8)
    
    kasumi
      F7-updates > F8 (0:2.3-1.fc7 > 0:2.2-6.fc8)
    
    ruby
      F7-updates > F8 (0:1.8.6.111-1.fc7 > 0:1.8.6.110-2.fc8)
    
tcallawa AT redhat com:
    xbase
      F7-updates > F8 (0:2.0.0-8.fc7 > 0:2.0.0-7.fc8)
    
----------------------------------------------------------------------

adminutil: rmeggins AT redhat com
  FE6 > F8 (0:1.1.5-1.fc6 > 0:1.1.4-2.fc8)
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.4-2.fc8)

anthy: tagoh AT redhat com
  F7-updates > F8 (0:9100d-1.fc7 > 0:9100b-1.fc8)

basket: gauret AT free fr
  F7-updates > F8 (0:1.0.2-3.fc7 > 0:1.0.2-2.fc8)

bugzilla: john AT ncphotography com
  FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
  FE6 > F8 (0:3.0.2-2.fc6 > 0:3.0.2-0.fc8)

cacti: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.8.6j-9.fc6 > 0:0.8.6j-8.fc7)

cksfv: chris stone AT gmail com
  FE6 > F8 (0:1.3.12-2.fc6 > 0:1.3.12-1.fc8)
  F7-updates > F8 (0:1.3.12-2.fc7 > 0:1.3.12-1.fc8)

climm: ondrejj AT salstar sk
  FE6 > F8 (0:0.6.1-1.fc6 > 0:0.6-2.fc8)
  F7-updates > F8 (0:0.6.1-1.fc7 > 0:0.6-2.fc8)

ctapi-cyberjack: frank-buettner AT gmx net
  FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
  F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)

dbmail: bjohnson AT symetrix com
  FE6 > F7-updates (0:2.2.7-1.fc6 > 0:2.2.5-5.fc7)
  FE6 > F8 (0:2.2.7-1.fc6 > 0:2.2.5-7.fc8)

eclipse-subclipse: robert AT marcanoonline com
  FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
  F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)

flashrom: lemenkov AT gmail com
  FE6 > F7-updates (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc7)
  FE6 > F8 (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc8)

fortune-firefly: karen-pease AT uiowa edu
  FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
  FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)

fuse-python: lemenkov AT gmail com
  FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
  F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8)

fwfstab: s adam AT diffingo com
  FE6 > F8 (0:0.02-2.fc6 > 0:0.01.1-7.fc8)
  F7-updates > F8 (0:0.02-2.fc7 > 0:0.01.1-7.fc8)

glpi: Fedora AT FamilleCollet com
  F7-updates > F8 (0:0.70-0.3.rc2.fc7 > 0:0.70-0.2.rc1.fc8)

gnome-libs: paul AT city-fan org
  FE6 > F7 (1:1.4.2-7.fc6 > 1:1.4.2-5.fc7)
  FE6 > F8 (1:1.4.2-7.fc6 > 1:1.4.2-6.fc8)

gputils: aportal AT univ-montp2 fr
  FE6 > F7 (0:0.13.5-1.fc6 > 0:0.13.4-2.fc6)
  FE6 > F8 (0:0.13.5-1.fc6 > 0:0.13.4-4.fc8)

gscan2pdf: bjohnson AT symetrix com
  FE6 > F7-updates (0:0.9.17-2.fc6 > 0:0.9.16-1.fc7)
  FE6 > F8 (0:0.9.17-2.fc6 > 0:0.9.16-1.fc8)

gtk-recordmydesktop: foolish AT guezz net
  F7-updates > F8 (0:0.3.6-1.fc7.1 > 0:0.3.4-1.fc8.1)

gtranslator: foolish AT guezz net
  F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8)

irqbalance: nhorman AT redhat com
  FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
  FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)

jd: mtasaka AT ioa s u-tokyo ac jp
  F7-updates > F8 (0:1.9.7-0.2.beta071101.fc7 > 0:1.9.6-1.fc8)

jrtplib: jeff AT ocjtech us
  FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)

kasumi: tagoh AT redhat com
  F7-updates > F8 (0:2.3-1.fc7 > 0:2.2-6.fc8)

kazehakase: mtasaka AT ioa s u-tokyo ac jp
  FE6 > F8 (0:0.5.0-1.fc6 > 0:0.4.9-2.svn3312.fc8)
  F7-updates > F8 (0:0.5.0-1.fc7 > 0:0.4.9-2.svn3312.fc8)

kbackup: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
  FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2-1.fc8)

kdetv: packages AT amiga-hardware com
  FE6 > F8 (0:0.8.9-7.fc6 > 0:0.8.9-6.fc8)
  F7-updates > F8 (0:0.8.9-7.fc7 > 0:0.8.9-6.fc8)

kdmtheme: cgoorah AT yahoo com au
  FE6 > F8 (0:1.2.1-1.fc6 > 0:1.1.3-2.fc8)
  F7-updates > F8 (0:1.2.1-1.fc7 > 0:1.1.3-2.fc8)

libextractor: enrico scholz AT informatik tu-chemnitz de
  FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)

libgtop2: sandmann AT redhat com
  FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)

liblrdf: green AT redhat com
  FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)

libsieve: bjohnson AT symetrix com
  FE6 > F7 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
  FE6 > F8 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)

libtasn1: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
  FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)

lostirc: splinux25 AT gmail com
  FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)

mailgraph: bjohnson AT symetrix com
  FE6 > F7 (0:1.14-1.fc6 > 0:1.12-5.fc7)
  FE6 > F8 (0:1.14-1.fc6 > 0:1.12-5.fc7)

mcabber: mfleming+rpm AT enlartenment com
  FE6 > F7-updates (0:0.9.4-1.fc6 > 0:0.9.3-3.fc7)
  FE6 > F8 (0:0.9.4-1.fc6 > 0:0.9.3-6.fc8)

mimetic: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
  FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)

mirage: mtasaka AT ioa s u-tokyo ac jp
  FE6 > F8 (0:0.9-1.fc6 > 0:0.8.3-2.fc8.2)
  F7-updates > F8 (0:0.9-1.fc7 > 0:0.8.3-2.fc8.2)

mlmmj: mfleming+rpm AT enlartenment com
  FE6 > F7 (0:1.2.15-1.fc6 > 0:1.2.14-2.fc7)

mock: jkeating AT redhat com
  F7-updates > F8 (0:0.8.4-2.fc7 > 0:0.7.6-1.fc8)

mod_nss: rcritten AT redhat com
  FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
  F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)

monotone: roland AT redhat com
  FE6 > F8 (0:0.37-3.fc6 > 0:0.36-2.fc8)
  F7-updates > F8 (0:0.37-3.fc7 > 0:0.36-2.fc8)

mozldap: rmeggins AT redhat com
  FE6 > F8 (0:6.0.5-1.fc6 > 0:6.0.4-2.fc8)
  F7-updates > F8 (0:6.0.5-1.fc7 > 0:6.0.4-2.fc8)

nagios-plugins: mmcgrath AT redhat com
  FE6 > F8 (0:1.4.8-9.fc6 > 0:1.4.8-7.fc8)
  F7-updates > F8 (0:1.4.8-9.fc7 > 0:1.4.8-7.fc8)

nethack-vultures: karen-pease AT uiowa edu
  FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)

perl-DBIx-DBSchema: rc040203 AT freenet de
  FE6 > F8 (0:0.35-1.fc6 > 0:0.34-1.fc8)
  F7-updates > F8 (0:0.35-1.fc7 > 0:0.34-1.fc8)

perl-File-NCopy: rc040203 AT freenet de
  F7-updates > F8 (0:0.35-3.fc7 > 0:0.34-6.fc8)

perl-Params-Util: rc040203 AT freenet de
  F7-updates > F8 (0:0.30-1.fc7 > 0:0.29-1.fc8)

perl-PDF-API2: bjohnson AT symetrix com
  FE6 > F7-updates (0:0.65-1.fc6 > 0:0.62-2.fc7)
  FE6 > F8 (0:0.65-1.fc6 > 0:0.62-2.fc8)

perl-Set-IntSpan: rc040203 AT freenet de
  FE6 > F8 (0:1.13-1.fc6 > 0:1.12-1.fc8)
  F7-updates > F8 (0:1.13-1.fc7 > 0:1.12-1.fc8)

php-channel-phing: akahl AT iconmobile com
  F7-updates > F8 (0:1.0.0-5.fc7 > 0:1.0.0-4.fc8)

phpMyAdmin: mmcgrath AT redhat com
  FE6 > F8 (0:2.11.2-1.fc6 > 0:2.11.0-1.fc8)
  F7-updates > F8 (0:2.11.2-1.fc7 > 0:2.11.0-1.fc8)

piklab: cgoorah AT yahoo com au
  FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
  FE6 > F8 (0:0.15.0-1.fc6 > 0:0.14.5-2.fc8)

pikloops: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)

poker-network: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-2.fc8)

poker2d: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
  FE6 > F8 (0:1.2.0-3.fc6 > 0:1.2.0-1.fc8)

python-cheetah: mikeb AT redhat com
  FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)

python-meld3: mmcgrath AT redhat com
  FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
  FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)

python-nltk: michel sylvan AT gmail com
  FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
  FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)

q: gemi AT bluewin ch
  F7-updates > F8 (0:7.8-1.fc7 > 0:7.6-2.fc7)

qgis: silfreed AT silfreed net
  FE6 > F7-updates (0:0.9.0-1.fc6 > 0:0.8.1-11.fc7)

queuegraph: bjohnson AT symetrix com
  FE6 > F7 (0:1.1-2.fc6 > 0:1.1-1.fc7)
  FE6 > F8 (0:1.1-2.fc6 > 0:1.1-1.fc7)

recordmydesktop: foolish AT guezz net
  F7-updates > F8 (0:0.3.6-1.fc7 > 0:0.3.4-1.fc8)

rkward: pingoufc4 AT yahoo fr
  FE6 > F8 (0:0.4.8-2.fc6 > 0:0.4.7-4.fc8)
  F7-updates > F8 (0:0.4.8-2.fc7 > 0:0.4.7-4.fc8)

rss-glx: nphilipp AT redhat com
  F7-updates > F8 (0:0.8.1.p-16.fc7 > 0:0.8.1.p-15.fc8)

ruby: tagoh AT redhat com
  F7-updates > F8 (0:1.8.6.111-1.fc7 > 0:1.8.6.110-2.fc8)

rxvt-unicode: andreas bierfert AT lowlatency de
  F7-updates > F8 (0:8.4-1.fc7 > 0:8.3-1.fc8)

seamonkey: gecko-maint AT redhat com
  F7-updates > F8 (0:1.1.5-1.fc7 > 0:1.1.3-8.fc8)

SILLY: packages AT amiga-hardware com
  FE6 > F8 (0:0.1.0-4.fc6 > 0:0.1.0-3.fc8)
  F7-updates > F8 (0:0.1.0-4.fc7 > 0:0.1.0-3.fc8)

smolt: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc7)
  FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)

specto: lxtnow AT gmail com
  FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
  F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)

toped: cgoorah AT yahoo com au
  F7-updates > F8 (0:0.8.6-1.fc7 > 0:0.8.5-2.fc8)

util-vserver: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
  FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)

wammu: lxtnow AT gmail com
  FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
  F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)

weechat: i AT stingr net
  F7-updates > F8 (0:0.2.6-1.fc7 > 0:0.2.5-1.fc8)

wine: andreas bierfert AT lowlatency de
  F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)

wine-docs: andreas bierfert AT lowlatency de
  F7-updates > F8 (0:0.9.48-1.fc7 > 0:0.9.47-1.fc8)

xbase: tcallawa AT redhat com
  F7-updates > F8 (0:2.0.0-8.fc7 > 0:2.0.0-7.fc8)

xcircuit: cgoorah AT yahoo com au
  FE6 > F8 (0:3.4.27-1.fc6 > 0:3.4.26-23.fc8)
  F7-updates > F8 (0:3.4.27-1.fc7 > 0:3.4.26-23.fc8)

xmlrpc-c: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
  FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)

xscreensaver: mtasaka AT ioa s u-tokyo ac jp
  F7-updates > F8 (1:5.03-14.fc7 > 1:5.03-12.fc8)

yap: gemi AT bluewin ch
  F7-updates > F8 (0:5.1.1-8.fc7 > 0:5.1.1-7.fc8)

Zim: cweyl AT alumni drew edu
  FE6 > F8 (0:0.21-1.fc6 > 0:0.19-1.fc7)
  F7-updates > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)

zynaddsubfx: green AT redhat com
  FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)



From ian at stams.strath.ac.uk  Fri Nov  2 13:41:32 2007
From: ian at stams.strath.ac.uk (Ian Thurlbeck)
Date: Fri, 02 Nov 2007 13:41:32 +0000
Subject: F8: Bug in diff ?
Message-ID: <472B290C.9030300@stams.strath.ac.uk>


Dear All

please confirm that what I'm seeing here is a bug before I bugzilla it.

Create 2 files, f1, f2 with contents "abc" and "abc " (without quotes),
i.e. the same line with a space on the end.

Diff ignoring whitespace:

diff -b f1 f2

should produce no diff output, but does on F8. Works fine on FC6.

version: diffutils-2.8.1-17.fc8

Thanks

Ian
-- 
Ian Thurlbeck                http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK,  G1 1XH
Tel: +44 (0)141 548 3667           Fax: +44 (0)141 552 2079



From jkeating at redhat.com  Fri Nov  2 13:47:57 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 09:47:57 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194010632.3454.50.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
Message-ID: <20071102094757.0088b25c@redhat.com>

On Fri, 02 Nov 2007 14:37:12 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> > That's what the -n.fc7.1 versioning scheme is for.  
> Wrong again. It's one (broken) way to approach this.
> 
> If you really want to force release tags, better automatically assign
> them to packages (then YOU have full control over them), instead of
> trying to push people around with your personals visions,

We don't really care how you do your versioning, so long as your
upgrade paths work, and that you don't introduce an nevra on F7 that
won't upgrade to the nevra(s) on F8.  We ask that you don't manually
put in ".fc7" yourself and if you want it to use the dist tag instead,
but that's not mandatory.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/d3382794/attachment.sig>

From skvidal at fedoraproject.org  Fri Nov  2 13:49:21 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 02 Nov 2007 09:49:21 -0400
Subject: F8: Bug in diff ?
In-Reply-To: <472B290C.9030300@stams.strath.ac.uk>
References: <472B290C.9030300@stams.strath.ac.uk>
Message-ID: <1194011361.2654.10.camel@cutter>


On Fri, 2007-11-02 at 13:41 +0000, Ian Thurlbeck wrote:
> Dear All
> 
> please confirm that what I'm seeing here is a bug before I bugzilla it.
> 
> Create 2 files, f1, f2 with contents "abc" and "abc " (without quotes),
> i.e. the same line with a space on the end.
> 
> Diff ignoring whitespace:
> 
> diff -b f1 f2
> 
> should produce no diff output, but does on F8. Works fine on FC6.
> 
> version: diffutils-2.8.1-17.fc8
> 

confirmed both on f8 and f6.

open a bug, please.

-sv




From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  2 14:04:58 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 2 Nov 2007 15:04:58 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711021407.21087.opensource@till.name>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711021240.58803.opensource@till.name>
	<20071102132050.407fbb59.mschwendt.tmp0701.nospam@arcor.de>
	<200711021407.21087.opensource@till.name>
Message-ID: <20071102150458.2fde3860.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 02 Nov 2007 14:07:12 +0100, Till Maas wrote:

> > The upgrade path ends with:
> >
> >   ... F8 + F8 updates + F8 updates-testing --> rawhide
> >
> > An EVR upgrade in F8 updates-testing can only break the path to
> > rawhide, not the path to older dists.
> 
> Here is an example from the report:
>     Zim
>       F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
> Zim-0.21-1.fc7 is in F7 updates-testing but the version in F8 is older. Btw. 
> there is already a request to add Zim-0.21-1.fc8 to F8 updates-testing.

Yes, but if you only repeat Roland McGrath's request, that one has
been noticed. Perhaps bodhi already offers an interface where to
retrieve a list of pending push requests. Perhaps it doesn't yet.

It's not too long before F8 updates-testing will be opened, and then
push requests will be processed frequently again and won't sit in pending
for a long time.

> It seemed to me, that we discuss here, how we would like the script to behave. 
> Btw. imho there should be a warning when a stable package in F7 is evr-higher 
> than a stable package in F8, even when there is a newer package in 
> F8-updates-testing.

And other maintainers disagree, because as soon as they've pushed an
update to "F8 updates-testing", they don't want to the receive a mail
that tells them that the pkg in "F7 updates" is still newer than "F8
updates".



From rc040203 at freenet.de  Fri Nov  2 14:10:00 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 15:10:00 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102144509.06f50983.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<20071102144509.06f50983.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1194012601.3454.75.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 14:45 +0100, Michael Schwendt wrote:
> On Fri, 02 Nov 2007 13:42:55 +0100, Ralf Corsepius wrote:
> 
> > C'mon, you are once more trying to push people to adopt your (IMO:
> > broken) vision.
> 
> Ridiculous.
Thanks, actually that's what I think about your and Kevin's rationale.
All you are doing is trying to supress and force the community to use
ONE single scheme: your truth.

> Actually, it's the opposite. I'm not the one who's fighting the use of
> scripts like upgradecheck, just because some of its (not even daily)
> mails are considered an annoyance by a few package maintainers.
Yes, e.g. by me. This upgradecheck does neither reflect my way of
packaging nor does it produce correct results.

E.g. atm 90% of all complaints currently are against FC-6 and F-8.
Cause: Fc-6 automatically getting pushed, F-8 being in deep freeze.

>  Take a
> deep breath, mash warns about broken deps in rawhide every day, even
> when a packager can only wait for another packager to fix something
> first.
I tell you what: I push them to /dev/null, because in 95% of all cases
these messages are "false alarms" or alarms caused by rel-engs
work-flow.

> > - If a package is being pushed from testing to updates (currenly not
> > possible due to bodhi's design),
> 
> ?? What do you mean? How have the many packagers done it?
Withdrawing a package from testing and then repushing to stable is the
only way I found. 

>  Marking a
> test update "stable" does work, doesn't it?
Well, it didn't do yesterday.

>  Do you see a pattern in
> the way you criticise achievements?
Yes, there is a pattern: I don't see bodhi nor the current release flow
to be achievements to be proud of.

> > Example: "Package X works in FC-8 but doesn't work in FC-7".
> 
> If it works, why isn't it put into F-8 (or devel)?
>
> I can answer that for you.
> 
> Case 1) The usual procedure is that the packager still focuses on F-7
> and does not use F-8/rawhide yet. The update is prepared for F-7 only,
> neglecting F-8/rawhide completely.
You've got it conversely. 

Look at what I wrote: F-8 works, but the same package for F-7 has shown
to be broken (after release!)

Such things happen, e.g. because 
* the infrastructure underneath is different
* a "presumed to be harmless update" triggers something on F-7, but
doesn't trigger the same issue (e.g. because this bug had been fixed in
F-8 and F-8 is using a newer version) on F-8.
...

One approach being applied by maintainers would be: 
"Trial and error" on "updates-testing".

> Case 2) The usual %{?dist} and "make tag" breakage. Wrong release
> bumps as the cause of broken upgrade paths.
That's not what I am talking about. I am talking about packages in testing.

> Case 3) You refer to an already released pkg in F-7 and F-8, which is
> reported as being broken in F-7 only. 
Right, that's the case I am talking about.

> Let's assume you prepare a
> version upgrade as a test update for F-7, not testing the same code
> for F-8 or devel. You try to cherry-pick your target audience by
> releasing an exclusive test upgrade for an old(er) dist, neglecting to
> test the same stuff for the newer dists. What is so wrong about
> warning about the broken upgrade path? Especially when you learn
> that the test update works for F-7, you need to bring F-8 and devel
> on par with F-7 anyway.

You are presuming the cause for the bug to be inside of the package
exposing the issue. In such cases propagating a fix to F-8 would be
appropriate, but in many cases, this is not the case.

Ralf




From rc040203 at freenet.de  Fri Nov  2 14:12:34 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 15:12:34 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102094757.0088b25c@redhat.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
Message-ID: <1194012754.3454.79.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 09:47 -0400, Jesse Keating wrote:
> On Fri, 02 Nov 2007 14:37:12 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > > That's what the -n.fc7.1 versioning scheme is for.  
> > Wrong again. It's one (broken) way to approach this.
> > 
> > If you really want to force release tags, better automatically assign
> > them to packages (then YOU have full control over them), instead of
> > trying to push people around with your personals visions,
> 
> We don't really care how you do your versioning, so long as your
> upgrade paths work,
The actual question behind this is: Are the EVRs of packages in testing
supposed to be updates < testing < rawhide?

I.e. are upgrades from testing to rawhide relevant?

Ralf




From rc040203 at freenet.de  Fri Nov  2 14:16:13 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 15:16:13 +0100
Subject: For Michael: [Was: Package EVR problems in Fedora 2007-11-02]
In-Reply-To: <20071102134534.0B9B615212D@buildsys.fedoraproject.org>
References: <20071102134534.0B9B615212D@buildsys.fedoraproject.org>
Message-ID: <1194012974.3454.85.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 09:45 -0400, buildsys at fedoraproject.org wrote:
> Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
> FC6-updates, FE6, F7, F7-updates, F8

> rc040203 AT freenet de:
>     perl-DBIx-DBSchema
>       FE6 > F8 (0:0.35-1.fc6 > 0:0.34-1.fc8)
>       F7-updates > F8 (0:0.35-1.fc7 > 0:0.34-1.fc8)

Update pending and blocked by rel-eng for 2 days.

>     perl-File-NCopy
>       F7-updates > F8 (0:0.35-3.fc7 > 0:0.34-6.fc8)
Update pending and blocked by rel-eng for 8 days.
    
>     perl-Params-Util
>       F7-updates > F8 (0:0.30-1.fc7 > 0:0.29-1.fc8)
Update pending and blocked by rel-eng for 2 days.

>     perl-Set-IntSpan
>       FE6 > F8 (0:1.13-1.fc6 > 0:1.12-1.fc8)
>       F7-updates > F8 (0:1.13-1.fc7 > 0:1.12-1.fc8)
Update pending and blocked by rel-eng for 2 days.


All none of my business. It's rel-eng's turn to do their job

Ralf




From jkeating at redhat.com  Fri Nov  2 14:28:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 10:28:34 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194012754.3454.79.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
Message-ID: <20071102102834.6f4337d0@redhat.com>

On Fri, 02 Nov 2007 15:12:34 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> The actual question behind this is: Are the EVRs of packages in
> testing supposed to be updates < testing < rawhide?
> 
> I.e. are upgrades from testing to rawhide relevant?

IMHO yes.  Any package that could potentially go out for a release (if
it's in -testing, it could potentially go out) should have an nevra
that sorts lower than release+1.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/e519ebc4/attachment.sig>

From jdennis at redhat.com  Fri Nov  2 14:30:25 2007
From: jdennis at redhat.com (John Dennis)
Date: Fri, 02 Nov 2007 10:30:25 -0400
Subject: F8: Bug in diff ?
In-Reply-To: <472B290C.9030300@stams.strath.ac.uk>
References: <472B290C.9030300@stams.strath.ac.uk>
Message-ID: <472B3481.8000700@redhat.com>

Ian Thurlbeck wrote:
> 
> Dear All
> 
> please confirm that what I'm seeing here is a bug before I bugzilla it.
> 
> Create 2 files, f1, f2 with contents "abc" and "abc " (without quotes),
> i.e. the same line with a space on the end.
> 
> Diff ignoring whitespace:
> 
> diff -b f1 f2
> 
> should produce no diff output, but does on F8. Works fine on FC6.
>

Ha, that's amusing, I noticed the same thing yesterday but I thought it
was me being silly and ignored it thinking how could one of the most
heavily used utilities be this broken and not have any reported bugs?

The options -w and -b report differences where none exist.

This was confirmed by looking at the two files in a hex editor just to 
make sure a non-printing character wasn't the culprit, but the areas 
flagged as different were byte identical and turning off -w or -b 
resulted in no differences, completely counterintuitive.

-- 
John Dennis <jdennis at redhat.com>



From rc040203 at freenet.de  Fri Nov  2 14:33:34 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 15:33:34 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102102834.6f4337d0@redhat.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
Message-ID: <1194014014.3454.90.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 10:28 -0400, Jesse Keating wrote:
> On Fri, 02 Nov 2007 15:12:34 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > The actual question behind this is: Are the EVRs of packages in
> > testing supposed to be updates < testing < rawhide?
> > 
> > I.e. are upgrades from testing to rawhide relevant?
> 
> IMHO yes.  Any package that could potentially go out for a release (if
> it's in -testing, it could potentially go out) should have an nevra
> that sorts lower than release+1.
IMHO no. 

It renders the primary purpose of "testing" absurd: "testing" packages
for "updates" (testing == volatile, scratch, ... irrelevant)

What matters, is packages which are being pushed from "testing" to
"updates" containing appropriate EVRS at the very moment they are being
pushed.

Ralf




From opensource at till.name  Fri Nov  2 14:38:31 2007
From: opensource at till.name (Till Maas)
Date: Fri, 02 Nov 2007 15:38:31 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102150458.2fde3860.mschwendt.tmp0701.nospam@arcor.de>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711021407.21087.opensource@till.name>
	<20071102150458.2fde3860.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <200711021538.37829.opensource@till.name>

On Fr November 2 2007, Michael Schwendt wrote:
> On Fri, 02 Nov 2007 14:07:12 +0100, Till Maas wrote:

> > Here is an example from the report:
> >     Zim
> >       F7-updates-testing > F8 (0:0.21-1.fc7 > 0:0.19-1.fc7)
> > Zim-0.21-1.fc7 is in F7 updates-testing but the version in F8 is older.
> > Btw. there is already a request to add Zim-0.21-1.fc8 to F8
> > updates-testing.
>
> Yes, but if you only repeat Roland McGrath's request, that one has
> been noticed. Perhaps bodhi already offers an interface where to
> retrieve a list of pending push requests. Perhaps it doesn't yet.

He did not make it clear to me, which push requests he meant. I understood 
that he meant the request from testing to stable, e.g. in the above case it 
rel-eng should be notified in case the Zim maintainer already requested a 
push for Zim from  F-8 updates-testing to F-8 stable.

I guess an integration into Bodhi like you suggested would be the best way, 
where a maintainer gets a warning before adding something to a stable repo 
when it breaks the upgrade path. Then at leas the upgrade-path breakages will 
not happen unintentionally.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/5428a939/attachment.sig>

From sundaram at fedoraproject.org  Fri Nov  2 14:35:35 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 02 Nov 2007 20:05:35 +0530
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194014014.3454.90.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>	<20071031212850.E09144D04AE@magilla.localdomain>	<200711010801.40465.silfreed@silfreed.net>	<200711021036.10842.opensource@till.name>	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>	<1194000096.3454.23.camel@mccallum.corsepiu.local>	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>	<1194007375.3454.38.camel@mccallum.corsepiu.local>	<loom.20071102T131115-221@post.gmane.org>	<1194010632.3454.50.camel@mccallum.corsepiu.local>	<20071102094757.0088b25c@redhat.com>	<1194012754.3454.79.camel@mccallum.corsepiu.local>	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
Message-ID: <472B35B7.5020700@fedoraproject.org>

Ralf Corsepius wrote:
> On Fri, 2007-11-02 at 10:28 -0400, Jesse Keating wrote:
>> On Fri, 02 Nov 2007 15:12:34 +0100
>> Ralf Corsepius <rc040203 at freenet.de> wrote:
>>
>>> The actual question behind this is: Are the EVRs of packages in
>>> testing supposed to be updates < testing < rawhide?
>>>
>>> I.e. are upgrades from testing to rawhide relevant?
>> IMHO yes.  Any package that could potentially go out for a release (if
>> it's in -testing, it could potentially go out) should have an nevra
>> that sorts lower than release+1.
> IMHO no. 
> 
> It renders the primary purpose of "testing" absurd: "testing" packages
> for "updates" (testing == volatile, scratch, ... irrelevant)
> 
> What matters, is packages which are being pushed from "testing" to
> "updates" containing appropriate EVRS at the very moment they are being
> pushed.

If the package has a lower E-V-R when it is pushed into the testing 
repository, it won't show up as an update for those enabling 
updates-testing repository. We need to fix it while it is in the testing 
repository itself for testers to find out about *other issues* in the 
package.

Rahul



From jkeating at redhat.com  Fri Nov  2 14:39:57 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 10:39:57 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194014014.3454.90.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
Message-ID: <20071102103957.35e43403@redhat.com>

On Fri, 02 Nov 2007 15:33:34 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> It renders the primary purpose of "testing" absurd: "testing" packages
> for "updates" (testing == volatile, scratch, ... irrelevant)
> 
> What matters, is packages which are being pushed from "testing" to
> "updates" containing appropriate EVRS at the very moment they are
> being pushed.

Do you often build a package for testing, find out it works, and then
go and rebuild it /again/ with a proper nvr?

A good nevra strategy across your branches should give you the freedom
to use always good nevras for testing, so on the chance that one of
your builds is good it can just be moved and you don't have to rebuild
just to use a good nevra.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/c3af3817/attachment.sig>

From jkeating at redhat.com  Fri Nov  2 14:45:19 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 10:45:19 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <200711021538.37829.opensource@till.name>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<200711021407.21087.opensource@till.name>
	<20071102150458.2fde3860.mschwendt.tmp0701.nospam@arcor.de>
	<200711021538.37829.opensource@till.name>
Message-ID: <20071102104519.46c2871e@redhat.com>

On Fri, 02 Nov 2007 15:38:31 +0100
Till Maas <opensource at till.name> wrote:

> He did not make it clear to me, which push requests he meant. I
> understood that he meant the request from testing to stable, e.g. in
> the above case it rel-eng should be notified in case the Zim
> maintainer already requested a push for Zim from  F-8 updates-testing
> to F-8 stable.
> 
> I guess an integration into Bodhi like you suggested would be the
> best way, where a maintainer gets a warning before adding something
> to a stable repo when it breaks the upgrade path. Then at leas the
> upgrade-path breakages will not happen unintentionally.


Keep in mind that there is some fuzzy time between when we've frozen
for a release and when we start pushing updates for that release.
Updates for 8 should start being pushed out on Monday/Tuesday.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/216088b1/attachment.sig>

From rc040203 at freenet.de  Fri Nov  2 14:48:36 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 15:48:36 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102103957.35e43403@redhat.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
Message-ID: <1194014916.3454.96.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 10:39 -0400, Jesse Keating wrote:
> On Fri, 02 Nov 2007 15:33:34 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > It renders the primary purpose of "testing" absurd: "testing" packages
> > for "updates" (testing == volatile, scratch, ... irrelevant)
> > 
> > What matters, is packages which are being pushed from "testing" to
> > "updates" containing appropriate EVRS at the very moment they are
> > being pushed.
> 
> Do you often build a package for testing, find out it works, and then
> go and rebuild it /again/ with a proper nvr?
I did so, once or twice, but in general, I rarely do so.

> A good nevra strategy across your branches should give you the freedom
> to use always good nevras for testing, so on the chance that one of
> your builds is good it can just be moved and you don't have to rebuild
> just to use a good nevra.
No disagreement on this. But I really don't see what you gain by forcing
EVRs to "updates < testing < rawhide" for "packages in testing".

Ralf





From jkeating at redhat.com  Fri Nov  2 14:53:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 10:53:12 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194014916.3454.96.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
Message-ID: <20071102105312.1f12d258@redhat.com>

On Fri, 02 Nov 2007 15:48:36 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> No disagreement on this. But I really don't see what you gain by
> forcing EVRs to "updates < testing < rawhide" for "packages in
> testing".

That's simply because you're failing to consider that things which are
in testing have (high) potential to make it into stable.  It would be
better for maintainers to fix nevra issues while the build is still in
testing than to wait until it hits updates.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/69015500/attachment.sig>

From pertusus at free.fr  Fri Nov  2 14:54:40 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 2 Nov 2007 15:54:40 +0100
Subject: For Michael: [Was: Package EVR problems in Fedora 2007-11-02]
In-Reply-To: <1194012974.3454.85.camel@mccallum.corsepiu.local>
References: <20071102134534.0B9B615212D@buildsys.fedoraproject.org>
	<1194012974.3454.85.camel@mccallum.corsepiu.local>
Message-ID: <20071102145440.GA2572@free.fr>

On Fri, Nov 02, 2007 at 03:16:13PM +0100, Ralf Corsepius wrote:
> On Fri, 2007-11-02 at 09:45 -0400, buildsys at fedoraproject.org wrote:
> >     perl-Set-IntSpan
> >       FE6 > F8 (0:1.13-1.fc6 > 0:1.12-1.fc8)
> >       F7-updates > F8 (0:1.13-1.fc7 > 0:1.12-1.fc8)
> Update pending and blocked by rel-eng for 2 days.
> 
> 
> All none of my business. It's rel-eng's turn to do their job

It is linked with the release freeze. I guess that, at that time of the
release, the nevr should be against F8 updates pending. Or even not
reported at all during the freeze(s).  As you also say, it may be
reasonable to have, for some period of time testing > rawhide, but it
should only be temporary, since when the release comes (and one should
argue, when the alpha comes), the upgrade path should be sane, and
testing packages should end up in the stable branch.

--
Pat



From rc040203 at freenet.de  Fri Nov  2 15:02:00 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 16:02:00 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102105312.1f12d258@redhat.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
Message-ID: <1194015720.3454.105.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 10:53 -0400, Jesse Keating wrote:
> On Fri, 02 Nov 2007 15:48:36 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > No disagreement on this. But I really don't see what you gain by
> > forcing EVRs to "updates < testing < rawhide" for "packages in
> > testing".
> 
> That's simply because you're failing to consider that things which are
> in testing have (high) potential to make it into stable.
That's "updates < testing" ... a necessary condition, because otherwise
you won't be able to install a package from "testing".

>   It would be
> better for maintainers to fix nevra issues while the build is still in
> testing than to wait until it hits updates.
Are you saying packages in "testing" automatically hit "updates"?
This would be the next design flaw. This renders "testing" further
useless.

I sense we seemingly we have a basic divergence on the purpose of
testing. 

You seem to understand it as a "delay queue" for updates, giving some
people a chance to check packages and withdraw them when they feel they
need to.

I understand "testing" as "auxiliary repo" taking candidate packages for
"updates", which generally should only be pushed by request, not "by
timeout" nor by "no receiving complaints".


Ralf




From rc040203 at freenet.de  Fri Nov  2 15:06:19 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 16:06:19 +0100
Subject: For Michael: [Was: Package EVR problems in Fedora 2007-11-02]
In-Reply-To: <20071102145440.GA2572@free.fr>
References: <20071102134534.0B9B615212D@buildsys.fedoraproject.org>
	<1194012974.3454.85.camel@mccallum.corsepiu.local>
	<20071102145440.GA2572@free.fr>
Message-ID: <1194015979.3454.111.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 15:54 +0100, Patrice Dumas wrote:
> On Fri, Nov 02, 2007 at 03:16:13PM +0100, Ralf Corsepius wrote:
> > On Fri, 2007-11-02 at 09:45 -0400, buildsys at fedoraproject.org wrote:
> > >     perl-Set-IntSpan
> > >       FE6 > F8 (0:1.13-1.fc6 > 0:1.12-1.fc8)
> > >       F7-updates > F8 (0:1.13-1.fc7 > 0:1.12-1.fc8)
> > Update pending and blocked by rel-eng for 2 days.
> > 
> > 
> > All none of my business. It's rel-eng's turn to do their job
> 
> It is linked with the release freeze.
Exactly. ... The point is: This script accuses packagers, though they
can't do anything about it.

All they did was to "request pushes" and "rel-eng" having decided not to
process them, ... in this case due to the release-freeze (an
understandable purpose).

A clever script, and a reasonable work-flow would take this situation
into account. It would know that the updates are available and would not
complain.

Ralf



From pertusus at free.fr  Fri Nov  2 15:06:07 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 2 Nov 2007 16:06:07 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194015720.3454.105.camel@mccallum.corsepiu.local>
References: <loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
	<1194015720.3454.105.camel@mccallum.corsepiu.local>
Message-ID: <20071102150607.GC2572@free.fr>

On Fri, Nov 02, 2007 at 04:02:00PM +0100, Ralf Corsepius wrote:
> 
> I sense we seemingly we have a basic divergence on the purpose of
> testing. 
> 
> You seem to understand it as a "delay queue" for updates, giving some
> people a chance to check packages and withdraw them when they feel they
> need to.
> 
> I understand "testing" as "auxiliary repo" taking candidate packages for
> "updates", which generally should only be pushed by request, not "by
> timeout" nor by "no receiving complaints".

Even in that case they are meant to go to updates, and in that case
should be, at some point < rawhide when rawhide becomes the next
version.

Having timeouts for pushing from testing to updates has been discussed
in the past, if I recall well, and I think that auto-pushing was not
accepted. However, and if I recall well, there could be some auto-pushing 
after a delay when there is enough positive 'karma' for a package (2 people 
approving the update if I recall well).

--
Pat



From jkeating at redhat.com  Fri Nov  2 15:49:36 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 11:49:36 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194015720.3454.105.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
	<1194015720.3454.105.camel@mccallum.corsepiu.local>
Message-ID: <20071102114936.14cbd484@redhat.com>

On Fri, 02 Nov 2007 16:02:00 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> > That's simply because you're failing to consider that things which
> > are in testing have (high) potential to make it into stable.  
> That's "updates < testing" ... a necessary condition, because
> otherwise you won't be able to install a package from "testing".

And if you make the next logical leap, F7-updates < F8(-updates).  So
your F7-updates-testing build had better have a lower nevra than that
which is either going into f8-updates(-testing), or already released on
F8 in some way.

> >   It would be
> > better for maintainers to fix nevra issues while the build is still
> > in testing than to wait until it hits updates.  
> Are you saying packages in "testing" automatically hit "updates"?

No, only if a maintainer chooses such and certain requirements happen,
like karma points reaching a threshold.

> This would be the next design flaw. This renders "testing" further
> useless.
> 
> I sense we seemingly we have a basic divergence on the purpose of
> testing. 
> 
> You seem to understand it as a "delay queue" for updates, giving some
> people a chance to check packages and withdraw them when they feel
> they need to.
> 
> I understand "testing" as "auxiliary repo" taking candidate packages
> for "updates", which generally should only be pushed by request, not
> "by timeout" nor by "no receiving complaints".

It's not a me or you thing.  This seems to be a you vs the rest of the
maintainers thing.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/1b31d543/attachment.sig>

From jkeating at redhat.com  Fri Nov  2 15:50:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 11:50:37 -0400
Subject: For Michael: [Was: Package EVR problems in Fedora 2007-11-02]
In-Reply-To: <1194015979.3454.111.camel@mccallum.corsepiu.local>
References: <20071102134534.0B9B615212D@buildsys.fedoraproject.org>
	<1194012974.3454.85.camel@mccallum.corsepiu.local>
	<20071102145440.GA2572@free.fr>
	<1194015979.3454.111.camel@mccallum.corsepiu.local>
Message-ID: <20071102115037.5e5bc7b2@redhat.com>

On Fri, 02 Nov 2007 16:06:19 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> A clever script, and a reasonable work-flow would take this situation
> into account. It would know that the updates are available and would
> not complain.


Which is what was requested by Roland and started this entire thread.
Funny how we've looped.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/f021d498/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  2 15:54:33 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 2 Nov 2007 16:54:33 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194012601.3454.75.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<20071102144509.06f50983.mschwendt.tmp0701.nospam@arcor.de>
	<1194012601.3454.75.camel@mccallum.corsepiu.local>
Message-ID: <20071102165433.240c0ebf.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 02 Nov 2007 15:10:00 +0100, Ralf Corsepius wrote:

> E.g. atm 90% of all complaints currently are against FC-6 and F-8.
> Cause: Fc-6 automatically getting pushed, F-8 being in deep freeze.

Only querying bodhi can fix that, which points back to the beginning
of this thread.

But even before the final freeze of rawhide, the report has been full of
issues for many weeks. And it has been created after the rawhide report
and after seeing test-update announcements, but prior to pushing FE6.

> > Case 3) You refer to an already released pkg in F-7 and F-8, which is
> > reported as being broken in F-7 only. 
>
> Right, that's the case I am talking about.

I know. Still, cases 1+2 are typical causes of upgrade path issues,
such as mass-updates pushed to an old stable dist before checking
that the same version upgrade builds also for the newer dists.

> > Let's assume you prepare a
> > version upgrade as a test update for F-7, not testing the same code
> > for F-8 or devel. You try to cherry-pick your target audience by
> > releasing an exclusive test upgrade for an old(er) dist, neglecting to
> > test the same stuff for the newer dists. What is so wrong about
> > warning about the broken upgrade path? Especially when you learn
> > that the test update works for F-7, you need to bring F-8 and devel
> > on par with F-7 anyway.
> 
> You are presuming the cause for the bug to be inside of the package
> exposing the issue. In such cases propagating a fix to F-8 would be
> appropriate, but in many cases, this is not the case.

What does it matter? All that matters is _where_ you apply the fix.
If you need to bump EV instead of just R, you break the upgrade path
(and then you need to bump EV in the same way for all newer dists).
If you can work around a problem in dependencies, however, you can
restrict yourself to bumping just R (the least-significant portion of
it).

Much of this discussion is pure theory, a playground for a theoretical
(albeit valid but rare) use-case of updates-testing. So what? How
often does it happen that you need to bump EV in the way described
above?



From rc040203 at freenet.de  Fri Nov  2 16:04:40 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 17:04:40 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102114936.14cbd484@redhat.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
	<1194015720.3454.105.camel@mccallum.corsepiu.local>
	<20071102114936.14cbd484@redhat.com>
Message-ID: <1194019481.3454.125.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 11:49 -0400, Jesse Keating wrote:
> On Fri, 02 Nov 2007 16:02:00 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > > That's simply because you're failing to consider that things which
> > > are in testing have (high) potential to make it into stable.  
> > That's "updates < testing" ... a necessary condition, because
> > otherwise you won't be able to install a package from "testing".
> 
> And if you make the next logical leap, F7-updates < F8(-updates).  So
> your F7-updates-testing build had better have a lower nevra than that
> which is either going into f8-updates(-testing), or already released on
> F8 in some way.
... yes, testing == scratch, volatile ... potential junk, you're on your
own, use at your risk.

> > >   It would be
> > > better for maintainers to fix nevra issues while the build is still
> > > in testing than to wait until it hits updates.  
> > Are you saying packages in "testing" automatically hit "updates"?
> 
> No, only if a maintainer chooses such and certain requirements happen,
> like karma points reaching a threshold.
> 
> > This would be the next design flaw. This renders "testing" further
> > useless.
> > 
> > I sense we seemingly we have a basic divergence on the purpose of
> > testing. 
> > 
> > You seem to understand it as a "delay queue" for updates, giving some
> > people a chance to check packages and withdraw them when they feel
> > they need to.
> > 
> > I understand "testing" as "auxiliary repo" taking candidate packages
> > for "updates", which generally should only be pushed by request, not
> > "by timeout" nor by "no receiving complaints".
> 
> It's not a me or you thing.  This seems to be a you vs the rest of the
> maintainers thing.
I realize you don't want to discuss but to "pull your cart through",
Sarge - sad, ...

Ralf




From chasd at silveroaks.com  Fri Nov  2 16:23:12 2007
From: chasd at silveroaks.com (chasd)
Date: Fri, 2 Nov 2007 11:23:12 -0500
Subject: KDE logout options with F8
In-Reply-To: <20071102114114.17A9873128@hormel.redhat.com>
References: <20071102114114.17A9873128@hormel.redhat.com>
Message-ID: <CAAFE32C-D402-4BCF-933D-509919666526@silveroaks.com>

Frank Schmitt   writes:

> Yeah, we understood. KDE users are second class citizens in Fedora.  
> Bye.

It could be worse.
You could be a PPC user and want to log in using XDM ;)


Charles Dostale



From jkeating at redhat.com  Fri Nov  2 16:25:54 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 12:25:54 -0400
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <1194019481.3454.125.camel@mccallum.corsepiu.local>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<20071031212850.E09144D04AE@magilla.localdomain>
	<200711010801.40465.silfreed@silfreed.net>
	<200711021036.10842.opensource@till.name>
	<20071102113335.3595c273.mschwendt.tmp0701.nospam@arcor.de>
	<1194000096.3454.23.camel@mccallum.corsepiu.local>
	<20071102125620.4d42930f.mschwendt.tmp0701.nospam@arcor.de>
	<1194007375.3454.38.camel@mccallum.corsepiu.local>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
	<1194015720.3454.105.camel@mccallum.corsepiu.local>
	<20071102114936.14cbd484@redhat.com>
	<1194019481.3454.125.camel@mccallum.corsepiu.local>
Message-ID: <20071102122554.2f4d0828@redhat.com>

On Fri, 02 Nov 2007 17:04:40 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> I realize you don't want to discuss but to "pull your cart through",
> Sarge - sad, ...

Language issue.  I have no idea what you're talking about here.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/80b2263a/attachment.sig>

From jspaleta at gmail.com  Fri Nov  2 16:33:35 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 2 Nov 2007 08:33:35 -0800
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <20071102105312.1f12d258@redhat.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
Message-ID: <604aa7910711020933k9a7cb69m447547448c24adf7@mail.gmail.com>

On 11/2/07, Jesse Keating <jkeating at redhat.com> wrote:
> That's simply because you're failing to consider that things which are
> in testing have (high) potential to make it into stable.  It would be
> better for maintainers to fix nevra issues while the build is still in
> testing than to wait until it hits updates.

Is there a case here for better expose of scratch/personal
repositories for tagetted test of packages with alternative evrs which
sort badly compared to released packages?

-jef



From rc040203 at freenet.de  Fri Nov  2 17:07:02 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 02 Nov 2007 18:07:02 +0100
Subject: Package EVR problems in Fedora 2007-10-31
In-Reply-To: <604aa7910711020933k9a7cb69m447547448c24adf7@mail.gmail.com>
References: <20071031203946.4CFF015212F@buildsys.fedoraproject.org>
	<loom.20071102T131115-221@post.gmane.org>
	<1194010632.3454.50.camel@mccallum.corsepiu.local>
	<20071102094757.0088b25c@redhat.com>
	<1194012754.3454.79.camel@mccallum.corsepiu.local>
	<20071102102834.6f4337d0@redhat.com>
	<1194014014.3454.90.camel@mccallum.corsepiu.local>
	<20071102103957.35e43403@redhat.com>
	<1194014916.3454.96.camel@mccallum.corsepiu.local>
	<20071102105312.1f12d258@redhat.com>
	<604aa7910711020933k9a7cb69m447547448c24adf7@mail.gmail.com>
Message-ID: <1194023222.3454.166.camel@mccallum.corsepiu.local>

On Fri, 2007-11-02 at 08:33 -0800, Jeff Spaleta wrote:
> On 11/2/07, Jesse Keating <jkeating at redhat.com> wrote:
> > That's simply because you're failing to consider that things which are
> > in testing have (high) potential to make it into stable.  It would be
> > better for maintainers to fix nevra issues while the build is still in
> > testing than to wait until it hits updates.
> 
> Is there a case here for better expose of scratch/personal
> repositories for tagetted test of packages with alternative evrs which
> sort badly compared to released packages?

Not necessarily better, but there is a way:
koji --scratch ...

and then either direct users to the corresponding koji pages to let them
d/l them from there

or the maintainer manually download them from koji-pages and stuff them
into a personal web site.

None of them are convenient to use and imply a considerable amount of
work to users and maintainers.

Ralf




From david at fubar.dk  Fri Nov  2 18:47:55 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 02 Nov 2007 14:47:55 -0400
Subject: file system mount
In-Reply-To: <1193972210.13091.5.camel@localhost.localdomain>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
Message-ID: <1194029275.25712.13.camel@oneill.fubar.dk>


On Fri, 2007-11-02 at 13:56 +1100, Rodd Clarkson wrote:
> I've had a collection of mounts on my HD that I hadn't seen show up in
> f7, but were showing in rawhide in the disk mounter applet.
> 
> The mounts included:
> 
> '/' (I'm using '/1' for this install),

Stems from another OS on your hard disk.

> '/var' (which should be '/var/www' anyway, and was already mounted
> as /var/www in my filesystem),

I bet the label of the file system is /var - that's what we display.

> '/mnt/vmware' (which was mounted and already a part of my filesystem),
> and
> 
> '/boot' (this install of rawhide has '/boot' as part of '/1')

Again, from another OS.

> and aren't the sort of thing I would have thought should have been
> showing up as available.

Why not? These are partitions on your hard disk. We simply just show
them as of F8. Now, you can complain that the text used in the UI for
these are misleading and I have to agree. We just take it from the label
of the file system at this point [1]. So go complain to the people who
chose the labels on your behalf. [2]

(Oh, and we also hide mounts for mount points at well-known locations,
e.g. FHS2.3 and some oddities like /var/log/audit and /var/tmp.)

So to fix this, either relabel these file systems (man e2label) but
please be careful to update the /etc/fstab files of the OS's using them
since Fedora defaults to LABEL=. Eventually we'll get the "rename file
system" from the UI going and this should be a lot easier.

      David

[1] : We could be more creative and try to guess what the file system is
used for; e.g. look for /etc/fedora-release, /etc/debian_release and so
forth (including trying to guess if it's Windows XP, Mac OS X or
whatever). So instead of showing "/" we could show "Fedora Core 7
(Moonshine)". That approach has it's ups and downs (guess is dangerous)
thus why it's not implemented at this point.

[2] : This is a rant to the Anaconda team. It is beyond me why you guys
decided to use LABEL= when UUID= is available for ext2/ext3 like since
forever. Another complaint is the name chosen for the file systems;
instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I
know this screws people on updates but at least these people could
rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or
Anaconda could prompt the user. Thanks for looking into this.




From david at fubar.dk  Fri Nov  2 19:00:08 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 02 Nov 2007 15:00:08 -0400
Subject: file system mount
In-Reply-To: <1194029275.25712.13.camel@oneill.fubar.dk>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>
Message-ID: <1194030008.25712.16.camel@oneill.fubar.dk>


On Fri, 2007-11-02 at 14:47 -0400, David Zeuthen wrote:
> [2] : This is a rant to the Anaconda team. It is beyond me why you guys
> decided to use LABEL= when UUID= is available for ext2/ext3 like since
> forever. 

https://bugzilla.redhat.com/show_bug.cgi?id=364441

> Another complaint is the name chosen for the file systems;
> instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I
> know this screws people on updates but at least these people could
> rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or
> Anaconda could prompt the user. Thanks for looking into this.

https://bugzilla.redhat.com/show_bug.cgi?id=364451

     David

ps. Sorry if I sounded too harsh in my previous mail.




From lesmikesell at gmail.com  Fri Nov  2 19:16:05 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 02 Nov 2007 14:16:05 -0500
Subject: file system mount
In-Reply-To: <1194029275.25712.13.camel@oneill.fubar.dk>
References: <47297920.60509@fedoraproject.org>	<loom.20071101T152643-909@post.gmane.org>	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>
Message-ID: <472B7775.1090603@gmail.com>

David Zeuthen wrote:
> 
> [1] : We could be more creative and try to guess what the file system is
> used for; e.g. look for /etc/fedora-release, /etc/debian_release and so
> forth (including trying to guess if it's Windows XP, Mac OS X or
> whatever). So instead of showing "/" we could show "Fedora Core 7
> (Moonshine)". That approach has it's ups and downs (guess is dangerous)
> thus why it's not implemented at this point.

How about giving a hint as to which _physical_ disk it is?  Imagine you 
had a couple of scsi controllers each with a bunch of disks, plus some 
sata and USB volumes and you add one (which might currently have labels 
that match other drives) and want to format it.  Which one is it?  Or a 
drive in the system fails and isn't detected.  How do you find which one
it was?

> [2] : This is a rant to the Anaconda team. It is beyond me why you guys
> decided to use LABEL= when UUID= is available for ext2/ext3 like since
> forever. Another complaint is the name chosen for the file systems;
> instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I
> know this screws people on updates but at least these people could
> rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or
> Anaconda could prompt the user. Thanks for looking into this.

How do you change the UUID's on md arrays?  I often clone machines by 
separating RAID1 drives and letting them sync to new partners.  If those 
separated drives ever find themselves back in the same machine, I 
wouldn't want them to rebuild automatically.

-- 
  Les Mikesell



From david at fubar.dk  Fri Nov  2 19:18:56 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 02 Nov 2007 15:18:56 -0400
Subject: file system mount
In-Reply-To: <472B7775.1090603@gmail.com>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>
	<472B7775.1090603@gmail.com>
Message-ID: <1194031136.25712.21.camel@oneill.fubar.dk>


On Fri, 2007-11-02 at 14:16 -0500, Les Mikesell wrote:
> David Zeuthen wrote:
> > 
> > [1] : We could be more creative and try to guess what the file system is
> > used for; e.g. look for /etc/fedora-release, /etc/debian_release and so
> > forth (including trying to guess if it's Windows XP, Mac OS X or
> > whatever). So instead of showing "/" we could show "Fedora Core 7
> > (Moonshine)". That approach has it's ups and downs (guess is dangerous)
> > thus why it's not implemented at this point.
> 
> How about giving a hint as to which _physical_ disk it is?  Imagine you 
> had a couple of scsi controllers each with a bunch of disks, plus some 
> sata and USB volumes and you add one (which might currently have labels 
> that match other drives) and want to format it.  Which one is it?  Or a 
> drive in the system fails and isn't detected.  How do you find which one
> it was?

You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..
Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit
most of this before F9 as part of the gio/gvfs hacking. Stay tuned!

> > [2] : This is a rant to the Anaconda team. It is beyond me why you guys
> > decided to use LABEL= when UUID= is available for ext2/ext3 like since
> > forever. Another complaint is the name chosen for the file systems;
> > instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I
> > know this screws people on updates but at least these people could
> > rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or
> > Anaconda could prompt the user. Thanks for looking into this.
> 
> How do you change the UUID's on md arrays?  I often clone machines by 
> separating RAID1 drives and letting them sync to new partners.  If those 
> separated drives ever find themselves back in the same machine, I 
> wouldn't want them to rebuild automatically.

I'm failing to see why this question relevant to this discussion? 

I'm simply just asking the Anaconda to a) use UUID instead of LABEL (if
applicable; e.g. some FS's don't have UUID); and b) use some sane labels
by default. The user is still free to edit /etc/fstab to use LABEL=
instead of UUID= and/or relabel his drives or do whatever he wants.

      David




From david at fubar.dk  Fri Nov  2 19:26:00 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 02 Nov 2007 15:26:00 -0400
Subject: file system mount
In-Reply-To: <1194031136.25712.21.camel@oneill.fubar.dk>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>
	<472B7775.1090603@gmail.com>
	<1194031136.25712.21.camel@oneill.fubar.dk>
Message-ID: <1194031560.25712.28.camel@oneill.fubar.dk>


On Fri, 2007-11-02 at 15:18 -0400, David Zeuthen wrote:
> On Fri, 2007-11-02 at 14:16 -0500, Les Mikesell wrote:
> > David Zeuthen wrote:
> > > 
> > > [1] : We could be more creative and try to guess what the file system is
> > > used for; e.g. look for /etc/fedora-release, /etc/debian_release and so
> > > forth (including trying to guess if it's Windows XP, Mac OS X or
> > > whatever). So instead of showing "/" we could show "Fedora Core 7
> > > (Moonshine)". That approach has it's ups and downs (guess is dangerous)
> > > thus why it's not implemented at this point.
> > 
> > How about giving a hint as to which _physical_ disk it is?  Imagine you 
> > had a couple of scsi controllers each with a bunch of disks, plus some 
> > sata and USB volumes and you add one (which might currently have labels 
> > that match other drives) and want to format it.  Which one is it?  Or a 
> > drive in the system fails and isn't detected.  How do you find which one
> > it was?
> 
> You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..
> Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit
> most of this before F9 as part of the gio/gvfs hacking. Stay tuned!

Also, just wanted to add, this discussion is mostly about what we use as
names _on the desktop_. Still, your request is valid; if we have a bunch
of similarly named drives then, sure, we should add the device name or
other unique identifier.

However, things like formatting drives, partitioning, setting up LVM and
RAID are most likely going to happen from a dedicated UI that will
display more relevant stuff. I was kinda working on this a while back;
here are some screenshots

 http://people.freedesktop.org/~david/gnome-disk-utility.png
 http://people.freedesktop.org/~david/hal-md-normal.png
 http://people.freedesktop.org/~david/hal-md-degraded.png
 http://people.freedesktop.org/~david/hal-md-recover.png

but then other things became important. Hopefully for F10 we can have
something like this... But now we're drifting off-topic :-)

     David




From lkundrak at redhat.com  Fri Nov  2 19:45:34 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Fri, 02 Nov 2007 20:45:34 +0100
Subject: Fedora 8 test on Mac Pro ?
In-Reply-To: <20071102115555.GC18109@hedwig.net.cmu.edu>
References: <20071102115555.GC18109@hedwig.net.cmu.edu>
Message-ID: <1194032734.7987.48.camel@localhost.localdomain>


On Fri, 2007-11-02 at 07:55 -0400, Gabriel L. Somlo wrote:
> I'm trying to set up Fedora 8 test on a Mac Pro, and while the install
> completed smoothly, it hangs when booting from the hard drive, in
> rc.sysinit, at or immediately after running /sbin/start_udev.
> 
> I booted off the rescue disk and ran yum update successfully. Now, it
> manages to get as far as 'Setting hostname', still in rc.sysinit,
> before freezing up completely.
> 
> Is this a known problem ? Any ideas about how to proceed pinning down
> the root cause ?

Does it always stop at the very same place? Could you please add the
command 'set -x' somewhere near the beginning of rc.sysinit to see what
is the command that does the hang.

Also, could you please add "lsmod" somewhere between udevtrigger and the
hang place?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lesmikesell at gmail.com  Fri Nov  2 19:47:02 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 02 Nov 2007 14:47:02 -0500
Subject: file system mount
In-Reply-To: <1194031136.25712.21.camel@oneill.fubar.dk>
References: <47297920.60509@fedoraproject.org>	<loom.20071101T152643-909@post.gmane.org>	<1193972210.13091.5.camel@localhost.localdomain>	<1194029275.25712.13.camel@oneill.fubar.dk>	<472B7775.1090603@gmail.com>
	<1194031136.25712.21.camel@oneill.fubar.dk>
Message-ID: <472B7EB6.9060100@gmail.com>

David Zeuthen wrote:

>> How about giving a hint as to which _physical_ disk it is?  Imagine you 
>> had a couple of scsi controllers each with a bunch of disks, plus some 
>> sata and USB volumes and you add one (which might currently have labels 
>> that match other drives) and want to format it.  Which one is it?  Or a 
>> drive in the system fails and isn't detected.  How do you find which one
>> it was?
> 
> You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..

No - sdb1 tells me what order the OS detected it it.  It says nothing 
about the physical connection or even which controller is involved. 
Does anyone actually use this system with a large number of disks that 
sometimes need attention?  If the drive that was sdb yesterday fails in 
a way that keeps it from being detected, sdb will mean something else 
after a reboot.

> Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit
> most of this before F9 as part of the gio/gvfs hacking. Stay tuned!

>> How do you change the UUID's on md arrays?  I often clone machines by 
>> separating RAID1 drives and letting them sync to new partners.  If those 
>> separated drives ever find themselves back in the same machine, I 
>> wouldn't want them to rebuild automatically.
> 
> I'm failing to see why this question relevant to this discussion? 

Same general rant about not being able to tell/control what is really 
going on.  I don't like the system to guess, especially when I know the 
answer will likely be wrong.

> I'm simply just asking the Anaconda to a) use UUID instead of LABEL (if
> applicable; e.g. some FS's don't have UUID); and b) use some sane labels
> by default. The user is still free to edit /etc/fstab to use LABEL=
> instead of UUID= and/or relabel his drives or do whatever he wants.

And similarly, I'd like a way to peg these to physical 
controller/cable/drive selects because the UUIDs and labels are all 
going to be the same on disks that I've cloned with DD or letting 
RAID1's rebuild.  I know you can't on USB, but about everything else has 
a controller/target/LUN concept to identify it.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From david at fubar.dk  Fri Nov  2 20:07:23 2007
From: david at fubar.dk (David Zeuthen)
Date: Fri, 02 Nov 2007 16:07:23 -0400
Subject: file system mount
In-Reply-To: <472B7EB6.9060100@gmail.com>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>	<472B7775.1090603@gmail.com>
	<1194031136.25712.21.camel@oneill.fubar.dk>
	<472B7EB6.9060100@gmail.com>
Message-ID: <1194034043.25712.37.camel@oneill.fubar.dk>


On Fri, 2007-11-02 at 14:47 -0500, Les Mikesell wrote:
> David Zeuthen wrote:
> 
> >> How about giving a hint as to which _physical_ disk it is?  Imagine you 
> >> had a couple of scsi controllers each with a bunch of disks, plus some 
> >> sata and USB volumes and you add one (which might currently have labels 
> >> that match other drives) and want to format it.  Which one is it?  Or a 
> >> drive in the system fails and isn't detected.  How do you find which one
> >> it was?
> > 
> > You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..
> 
> No - sdb1 tells me what order the OS detected it it.  It says nothing 
> about the physical connection or even which controller is involved. 
> Does anyone actually use this system with a large number of disks that 
> sometimes need attention?  If the drive that was sdb yesterday fails in 
> a way that keeps it from being detected, sdb will mean something else 
> after a reboot.

Of course. That's why we show the LABEL right now. We could show the
UUID but that's fugly. Btw, have you tried installing the RPM
gnome-mount-nautilus-properties, right clicking the icon and choose
Properties?

 http://people.freedesktop.org/~david/gm-n-p-1.png
 http://people.freedesktop.org/~david/gm-n-p-2.png

This UI needs to be reworked to work better for enterprise use cases but
basically does the job of properly identifying the drive...

> Same general rant about not being able to tell/control what is really 
> going on.  I don't like the system to guess, especially when I know the 
> answer will likely be wrong.

No one is doing any guessing here; we just display the LABEL of the file
system. If you happen to have useless and/or multiple labels you get to
keep them :-)

Please keep in mind this discussion is about what to show on the
desktop. Which means that it needs to work for a lot of people and
displaying scary stuff like UUID, device files is, generally, not going
to work I think. At least not in GNOME. Hence, we need a dedicated UI
for this - like gnome-disk-utility that I pointed you to in the other
mail. Someone just needs to finish it so it's ready for Fedora.

> > I'm simply just asking the Anaconda to a) use UUID instead of LABEL (if
> > applicable; e.g. some FS's don't have UUID); and b) use some sane labels
> > by default. The user is still free to edit /etc/fstab to use LABEL=
> > instead of UUID= and/or relabel his drives or do whatever he wants.
> 
> And similarly, I'd like a way to peg these to physical 
> controller/cable/drive selects because the UUIDs and labels are all 
> going to be the same on disks that I've cloned with DD or letting 
> RAID1's rebuild.  I know you can't on USB, but about everything else has 
> a controller/target/LUN concept to identify it.

Sure, that's something gnome-disk-utility should do. But it needs work
until it's ready.

     David




From myfedora at richip.dhs.org  Fri Nov  2 17:10:11 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 02 Nov 2007 11:10:11 -0600
Subject: Updating selinux-policy-targeted Causes SELinux Denials
Message-ID: <1194023411.10665.6.camel@localhost6.localdomain6>

Hi,

Should I be concerned that every time an update to
selinux-policy-targeted occurs, it causes actions that the current
running SELinux seems to prevent? I'm talking about SELinux
preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
(restorecon_t) "write"ing to a pipe with label "rpm_t".

Are these actions legal? And does SELinux preventing them cause an error
in the actual install? Or should these just be treated as warnings?

I'm guessing that the selinux applications are just trying to
communicate back to the RPM process. I'm wondering if there's anything
important in that communication that should be allowed, or if not, there
must be some way to clean this up.

(If this isn't the right place to ask, could someone redirect me to the
correct one?)
--

Richi Plana



From bruno at wolff.to  Fri Nov  2 20:17:15 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Fri, 2 Nov 2007 15:17:15 -0500
Subject: file system mount
In-Reply-To: <1194031136.25712.21.camel@oneill.fubar.dk>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>
	<472B7775.1090603@gmail.com>
	<1194031136.25712.21.camel@oneill.fubar.dk>
Message-ID: <20071102201715.GA17699@wolff.to>

> On Fri, 2007-11-02 at 14:16 -0500, Les Mikesell wrote:
> > 
> > How do you change the UUID's on md arrays?  I often clone machines by 
> > separating RAID1 drives and letting them sync to new partners.  If those 
> > separated drives ever find themselves back in the same machine, I 
> > wouldn't want them to rebuild automatically.

The man page for mdadm suggests that this can be done by using the update
(or U) option when assembling an existing array to specify a new UUID.
I have never tried this personally, so you would probably want to test
it before relying on it.



From jwilliam at xmission.com  Sat Nov  3 00:49:37 2007
From: jwilliam at xmission.com (Jerry Williams)
Date: Fri, 2 Nov 2007 18:49:37 -0600
Subject: F8rc3 Checking Filesystems fails. rhgb bug?
Message-ID: <000301c81db3$69912310$020aa8c0@a18>

I am loading Fedora-8-i386-DVD.iso using nfs and pxeboot and Kickstart.
Everything goes okay until I reboot and then it says:
Checking filesystems [FAILED]

And it lets me enter the root password and I can't seem to find anything
wrong with any of the file systems.

But at the grub menu if I hit e and edit and remove rhgb from the command
line.
Then it seems to boot okay.

And then once it has booted that way it is fine.
And will reboot without any problems.
I see there is an update to rhgb.

Thanks,
Jerry




From jkeating at redhat.com  Sat Nov  3 00:53:04 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 2 Nov 2007 20:53:04 -0400
Subject: F8rc3 Checking Filesystems fails. rhgb bug?
In-Reply-To: <000301c81db3$69912310$020aa8c0@a18>
References: <000301c81db3$69912310$020aa8c0@a18>
Message-ID: <20071102205304.6f0518ae@redhat.com>

On Fri, 2 Nov 2007 18:49:37 -0600
"Jerry Williams" <jwilliam at xmission.com> wrote:

> I see there is an update to rhgb.


Yes, this update, plus the rhpxl update combine to fix this issue.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071102/7324efbe/attachment.sig>

From chitlesh at fedoraproject.org  Sat Nov  3 07:04:50 2007
From: chitlesh at fedoraproject.org (Chitlesh GOORAH)
Date: Sat, 3 Nov 2007 08:04:50 +0100
Subject: KDE logout options with F8
In-Reply-To: <200710302212.50847.ml@deadbabylon.de>
References: <200710302208.03091.singularitaet@gmx.net>
	<200710302212.50847.ml@deadbabylon.de>
Message-ID: <13dbfe4f0711030004v3a9f9629jb25d84d8d91f1672@mail.gmail.com>

On 10/30/07, Sebastian Vahl wrote:
> To get the buttons to show up you have to use kdm as your loginmanager.

I'm not sure whether this is the solution.

In FEL I have the same bug, knowing the fact that FEL is kde based.

I've installed FEL from its livecd and did the updates.
Then I had the shutdown options. but once rebooted, the shutdown
options are gone.
I've removed gdm.
Still the bug persists.

chitlesh(~)[1]$cat /etc/sysconfig/desktop
DESKTOP="KDE"
DISPLAYMANAGER="KDE"

Chitlesh
-- 
http://clunixchit.blogspot.com



From pertusus at free.fr  Sat Nov  3 09:44:14 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 3 Nov 2007 10:44:14 +0100
Subject: rpms/olpc-utils/OLPC-2 olpc-utils.spec,1.4,1.5
In-Reply-To: <200711030026.lA30QmuX014371@cvs-int.fedora.redhat.com>
References: <200711030026.lA30QmuX014371@cvs-int.fedora.redhat.com>
Message-ID: <20071103094414.GB2663@free.fr>

On Fri, Nov 02, 2007 at 08:26:48PM -0400, Bernardo Innocenti wrote:
> Author: bernie
> 
> +#git clone git://dev.laptop.org/projects/olpc-utils; cd olpc-utils; ./autoconf.sh; (up the version in configure.ac); make dist

This should include a tag, a date or whatever is uitable for git such
that somebody can checkout the exact same source than the one that was
used for that package, even if there has been some changes in the git
afterwards. Moreover (up the version in configure.ac) seems suspicious,
this shouldn't be done, that is you shouldn't have to modify the git
result.

You can have a look at
http://fedoraproject.org/wiki/Packaging/SourceURL

--
Pat



From pertusus at free.fr  Sat Nov  3 09:50:02 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 3 Nov 2007 10:50:02 +0100
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.4,1.5 sources,1.5,1.6
In-Reply-To: <200711030033.lA30XnqZ014621@cvs-int.fedora.redhat.com>
References: <200711030033.lA30XnqZ014621@cvs-int.fedora.redhat.com>
Message-ID: <20071103095002.GC2663@free.fr>

On Fri, Nov 02, 2007 at 08:33:49PM -0400, Bernardo Innocenti wrote:
> Author: bernie
> --- .cvsignore	1 Nov 2007 10:04:05 -0000	1.4
> +++ .cvsignore	3 Nov 2007 00:33:17 -0000	1.5
> @@ -1,3 +1,4 @@
>  olpc-utils-0.15.tar.bz2
>  olpc-utils-0.20.tar.bz2
>  olpc-utils-0.31.tar.bz2
> +olpc-utils-0.32.tar.bz2

You can add instead of replacing, but it is not what is done in general,
since it allows to verify that there is no old cruft lying around.

> diff -u -r1.5 -r1.6
> --- sources	1 Nov 2007 10:04:05 -0000	1.5
> +++ sources	3 Nov 2007 00:33:17 -0000	1.6
> @@ -1,2 +1,3 @@
>  db22edfb32dfe4474444e3abedf47e09  olpc-utils-0.20.tar.bz2
>  f282dfc7f8840d6ba2cb048d2f16e4eb  olpc-utils-0.31.tar.bz2
> +ce0329cc0c0f51bfe515c4ee7dd387e8  olpc-utils-0.32.tar.bz2

Here, it is clearly wrong, you should only list the latest. Maybe you
should have alook at:

http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo

--
Pat



From buildsys at redhat.com  Sat Nov  3 10:21:11 2007
From: buildsys at redhat.com (Build System)
Date: Sat, 3 Nov 2007 06:21:11 -0400
Subject: rawhide report: 20071103 changes
Message-ID: <200711031021.lA3ALBXD013833@porkchop.devel.redhat.com>

 

 
Updated Packages:

selinux-policy-3.0.8-44.fc8
---------------------------
* Thu Nov 01 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-44
- Add policy.xml to devel
- Dontaudit tmpreaper getattr on lost_found dir
- Additional bluetooth file context
- Allow dhcpc to transition to networkmanager

* Tue Oct 30 2007 Dan Walsh <dwalsh at redhat.com> 3.0.8-43
- Add type definition for /dev/kvm

Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From mszpak at wp.pl  Sat Nov  3 11:46:08 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Sat, 03 Nov 2007 12:46:08 +0100
Subject: Fedora 8 Test3 and problem with updates
Message-ID: <fghn21$6dv$1@ger.gmane.org>

Hi,


Yesterday I installed Fedora 7.92 (i386) and the installation process
finished quite fast and without visible problems. There were almost 300
updates available so I started to do it in groups.

After about 100 updates and a few restarts something ate the Infinity
theme for gdm, which was set by default in t3. Login screen doesn't look
very nice, but I'm still able to login.
Was it intended to removed that theme?

In a meantime yum configuration started points to "normal" repository
(not development).

Later I wanted to update packages started with "f" (yum update f*), but
after downloading several packages installation process failed. I
separated problematic package - fedora-gnome-theme. The problem looks like:


=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 fedora-gnome-theme      noarch     8.0.0-1.fc8      fedora
10 k
Installing for dependencies:
 bluecurve-icon-theme    noarch     8.0.0-1.fc8      fedora
5.1 M
 fedora-icon-theme       noarch     1.0.0-1.fc8      fedora
115 k

Transaction Summary
=============================================================================
Install      3 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 5.2 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
Package metacity needs redhat-artwork >= 0.62, this is not available.
Package nodoka-theme-gnome needs redhat-artwork >= 7.0.0, this is not
available.
Package gdm needs redhat-artwork >= 5.0.11-1, this is not available.
Package system-config-display needs redhat-artwork >= 0.61-1, this is
not available.
Complete!


I was able to update metacity, but had problem with some other package -
redhat-artwork seemed to has the same files as some fedora package.

Could it be conflict between packages installed from development
repository and those from "normal" fedora repository (after yum
configuration switch)?


Regards
Marcin



From mszpak at wp.pl  Sat Nov  3 11:51:46 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Sat, 03 Nov 2007 12:51:46 +0100
Subject: Fedora 8 Test3 and lack of sound settings in a firstboot
Message-ID: <fghnci$6t1$1@ger.gmane.org>

Hi again,


In Fedora 7 there was a sound detection step in a firstboot. It's
missing in 7.92. Was it regarded as useless or there were problems with
integration with PulseAudio?


Regards
Marcin



From jkeating at redhat.com  Sat Nov  3 11:55:56 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 3 Nov 2007 07:55:56 -0400
Subject: Fedora 8 Test3 and lack of sound settings in a firstboot
In-Reply-To: <fghnci$6t1$1@ger.gmane.org>
References: <fghnci$6t1$1@ger.gmane.org>
Message-ID: <20071103075556.54587495@redhat.com>

On Sat, 03 Nov 2007 12:51:46 +0100
"Marcin Zaj?czkowski" <mszpak at wp.pl> wrote:

> In Fedora 7 there was a sound detection step in a firstboot. It's
> missing in 7.92. Was it regarded as useless or there were problems
> with integration with PulseAudio?

Pretty much regarded as useless.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/b663848d/attachment.sig>

From andrewparker at bigfoot.com  Sat Nov  3 12:12:19 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Sat, 3 Nov 2007 08:12:19 -0400
Subject: Fedora 8 Test3 and lack of sound settings in a firstboot
In-Reply-To: <20071103075556.54587495@redhat.com>
References: <fghnci$6t1$1@ger.gmane.org> <20071103075556.54587495@redhat.com>
Message-ID: <6c3f5e6c0711030512w2f011ab1hfa0645b048156fdc@mail.gmail.com>

On 11/3/07, Jesse Keating <jkeating at redhat.com> wrote:
> On Sat, 03 Nov 2007 12:51:46 +0100
> "Marcin Zaj?czkowski" <mszpak at wp.pl> wrote:
>
> > In Fedora 7 there was a sound detection step in a firstboot. It's
> > missing in 7.92. Was it regarded as useless or there were problems
> > with integration with PulseAudio?
>
> Pretty much regarded as useless.
>

I found it useful.  If no sound is produced, it prompts you to send
some debug files off to bugzilla (which I didn't do as the debug info
was sufficient to determine that someone else already had done).  I've
also had an entertaining time in the past where some processes have
prevented other processes accessing the sound card.  At first boot, I
am as as confident as I can be that that this isn't the case.



From buildsys at fedoraproject.org  Sat Nov  3 12:42:41 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Sat,  3 Nov 2007 08:42:41 -0400 (EDT)
Subject: Fedora Extras Package Build Report 2007-11-03
Message-ID: <20071103124241.91EDF15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 10

    cacti-0.8.7-2.fc6
    Django-0.96.1-1.fc6
NEW glpi-0.70-0.3.rc2.fc6 : Free IT asset management software
    jd-1.9.7-0.2.beta071101.fc6
    nas-1.9a-3.fc6
    PySolFC-1.1-4.fc6
NEW PySolFC-cardsets-1.1-3.1 : Various cardsets for PySolFC
    sparse-0.4-2.fc6
    xscreensaver-5.03-1.12.fc6
    zaptel-1.4.6-1.fc6


Changes in Fedora Extras 6: 


cacti-0.8.7-2.fc6
-----------------
* Sat Oct 13 2007 Mike McGrath <mmcgrath at redhat.com> - 0.8.7-2
- Upstream released new version
- No longer need to patch for /etc/cacti/*

Django-0.96.1-1.fc6
-------------------
* Thu Nov 01 2007 Michel Salim <michel.sylvan at gmail.com> 0.96.1-1
- i18n security update: CVE-2007-5712, bz#357051

glpi-0.70-0.3.rc2.fc6
---------------------
* Thu Nov 01 2007 Remi Collet <Fedora at FamilleCollet.com> - 0.70-0.3.rc2
- correct source

* Thu Nov 01 2007 Remi Collet <Fedora at FamilleCollet.com> - 0.70-0.2.rc2
- Release Candidate 2

* Mon Oct 08 2007 Remi Collet <Fedora at FamilleCollet.com> - 0.70-0.2.rc1
- From review #322781 : fix Source0 and macros
- Requires php-domxml for EL4

jd-1.9.7-0.2.beta071101.fc6
---------------------------
* Fri Nov 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyoa.c.jp> - 1.9.7-0.2.071101
- 1.9.7 beta 071101

nas-1.9a-3.fc6
--------------
* Fri Nov 02 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9a-3
- add better patch for #247468

* Fri Nov 02 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9a-2
- add patch to fix #247468

* Sun Oct 28 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9a-1
- update to 1.9a to fix #245712

* Sat Aug 18 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9-4
- fix for bug #245712

* Sat Aug 11 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9-3
- fix for bug #250453

* Fri May 04 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9-2.fc6
- rebuild for the new ppc64 arch

PySolFC-1.1-4.fc6
-----------------
* Thu Nov 01 2007 Stewart Adam <s.adam at diffingo.com> 1.1-4
- Provides: pysol since PySolFC is almost a drop-in replacement for
  the now unmaintained pysol

PySolFC-cardsets-1.1-3.1
------------------------
* Thu Nov 01 2007 Stewart Adam <s.adam at diffingo.com> 1.1-3.1
- Bump FC-6 for the tagging issues resulting from no dist tag

* Thu Oct 25 2007 Stewart Adam <s.adam at diffingo.com> 1.1-3
- Remove BR python-devel
- Add dot to %description
- Remove preinstalled cardsets
- Use a dir PySolFC actually recognizes

* Wed Oct 24 2007 Stewart Adam <s.adam at diffingo.com> 1.1-2
- Own dirs we create
- Remove %{?dist} tag
- Fix URL, description and summary
- Don't place any executable files in the RPM

sparse-0.4-2.fc6
----------------
* Thu Nov 01 2007 Roland McGrath <roland at redhat.com> - 0.4-2
- Upgrade to 0.4
- Install man pages, c2xml.
- Run make check in rpmbuild.

* Tue Aug 28 2007 Roland McGrath <roland at redhat.com> - 0.3-2
- Canonicalize License: tag.

* Thu May 03 2007 Roland McGrath <roland at redhat.com> - 0.3-1
- Upgrade to 0.3

xscreensaver-5.03-1.12.fc6
--------------------------
* Thu Nov 01 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-1.12
- Patch from upstream to fix screen depth problem (also "really"
  fix bug 336331).

* Mon Oct 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-1.11
- Suppress compiler warning

* Sat Oct 06 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-1.10
- Fix the maximum value on demo configuration dialog
- Change the encoding of XScreenSaver.ad and man files (bug 319101)

* Tue Oct 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-1.9
- Change the default browser to xdg-open

* Mon Sep 24 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-1.8
- Some cleanup.

zaptel-1.4.6-1.fc6
------------------
* Thu Nov 01 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.4.6-1
- Update to 1.4.6
- Apply patch to fix AST-2007-024



From Matt_Domsch at dell.com  Sat Nov  3 12:53:16 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Sat, 3 Nov 2007 07:53:16 -0500
Subject: Fedora 8 Test3 and problem with updates
In-Reply-To: <fghn21$6dv$1@ger.gmane.org>
References: <fghn21$6dv$1@ger.gmane.org>
Message-ID: <20071103125316.GD6839@auslistsprd01.us.dell.com>

On Sat, Nov 03, 2007 at 12:46:08PM +0100, Marcin Zaj?czkowski wrote:
> In a meantime yum configuration started points to "normal" repository
> (not development).

That's OK.  Until Fedora 8 is released, the "normal" repository points
at the development repository on the backend.

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From mark.bidewell at alumni.clemson.edu  Sat Nov  3 14:51:20 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Sat, 3 Nov 2007 10:51:20 -0400
Subject: F8 rc2 to F8 final
Message-ID: <bfdeacfa0711030751xcf04d35na749335ead15a976@mail.gmail.com>

Will F8 rc2 be upgradeable to F8 final via yum or is a reinstall required?

Mark Bidewell



From tibbs at math.uh.edu  Sat Nov  3 15:38:02 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 03 Nov 2007 10:38:02 -0500
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <1193753498.15341.67.camel@localhost.localdomain>
References: <47270A91.7070305@n-dimensional.de>
	<1193751987.5775.2.camel@localhost.localdomain>
	<1193753498.15341.67.camel@localhost.localdomain>
Message-ID: <ufawsszuyp1.fsf@epithumia.math.uh.edu>

>>>>> "AJ" == Adam Jackson <ajackson at redhat.com> writes:

AJ> Not a huge problem, actually, since the avivo driver doesn't ship
AJ> an xinf file yet.  But yeah, if you ship one, then kudzu will
AJ> match devices with the IDs listed in it to the driver named at the
AJ> end of the file, which means you'll be set up at install time with
AJ> that driver.

On this subject, the openchrome driver that was recently reviewed did
include a .xinf file.  Would this be problematic?

 - J<



From sundaram at fedoraproject.org  Sat Nov  3 16:16:21 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 03 Nov 2007 21:46:21 +0530
Subject: F8 rc2 to F8 final
In-Reply-To: <bfdeacfa0711030751xcf04d35na749335ead15a976@mail.gmail.com>
References: <bfdeacfa0711030751xcf04d35na749335ead15a976@mail.gmail.com>
Message-ID: <472C9ED5.1090400@fedoraproject.org>

Mark Bidewell wrote:
> Will F8 rc2 be upgradeable to F8 final via yum or is a reinstall required?
> 

Yum update would work.

Rahul



From fedora at leemhuis.info  Sat Nov  3 16:56:32 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 03 Nov 2007 17:56:32 +0100
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <ufawsszuyp1.fsf@epithumia.math.uh.edu>
References: <47270A91.7070305@n-dimensional.de>	<1193751987.5775.2.camel@localhost.localdomain>	<1193753498.15341.67.camel@localhost.localdomain>
	<ufawsszuyp1.fsf@epithumia.math.uh.edu>
Message-ID: <472CA840.1080502@leemhuis.info>

On 03.11.2007 16:38, Jason L Tibbitts III wrote:
>>>>>> "AJ" == Adam Jackson <ajackson at redhat.com> writes:
> 
> AJ> Not a huge problem, actually, since the avivo driver doesn't ship
> AJ> an xinf file yet.  But yeah, if you ship one, then kudzu will
> AJ> match devices with the IDs listed in it to the driver named at the
> AJ> end of the file, which means you'll be set up at install time with
> AJ> that driver.
> On this subject, the openchrome driver that was recently reviewed did
> include a .xinf file.  Would this be problematic?

My 2 cent: afaics it's fine to ship one. The package is not getting
installed  by default, so no harm is done for ordinary users. For those
users that actually installed the package manually everything works as
it should when kudzu touches the xorg.conf the next time.

Cu
knurd



From kevin.kofler at chello.at  Sat Nov  3 17:23:33 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 3 Nov 2007 17:23:33 +0000 (UTC)
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.4,1.5 sources,1.5,1.6
References: <200711030033.lA30XnqZ014621@cvs-int.fedora.redhat.com>
	<20071103095002.GC2663@free.fr>
Message-ID: <loom.20071103T172214-477@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> You can add instead of replacing, but it is not what is done in general,
> since it allows to verify that there is no old cruft lying around.
[snip]
> Here, it is clearly wrong, you should only list the latest. Maybe you
> should have alook at:

Yet "make upload" leaves the old sources listed there, so many packages still 
have them, the maintainers clean up only occasionally if at all. This is hardly 
the only package with old sources still listed.

        Kevin Kofler



From pertusus at free.fr  Sat Nov  3 17:26:40 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 3 Nov 2007 18:26:40 +0100
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.4,1.5 sources,1.5,1.6
In-Reply-To: <loom.20071103T172214-477@post.gmane.org>
References: <200711030033.lA30XnqZ014621@cvs-int.fedora.redhat.com>
	<20071103095002.GC2663@free.fr>
	<loom.20071103T172214-477@post.gmane.org>
Message-ID: <20071103172639.GA2533@free.fr>

On Sat, Nov 03, 2007 at 05:23:33PM +0000, Kevin Kofler wrote:
> Patrice Dumas <pertusus <at> free.fr> writes:
> > You can add instead of replacing, but it is not what is done in general,
> > since it allows to verify that there is no old cruft lying around.
> [snip]
> > Here, it is clearly wrong, you should only list the latest. Maybe you
> > should have alook at:
> 
> Yet "make upload" leaves the old sources listed there, so many packages still 
> have them, the maintainers clean up only occasionally if at all. This is hardly 
> the only package with old sources still listed.

It is still a mistake.

--
Pat



From ville.skytta at iki.fi  Sat Nov  3 18:26:21 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sat, 3 Nov 2007 20:26:21 +0200
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.4,1.5 sources,1.5,1.6
In-Reply-To: <20071103172639.GA2533@free.fr>
References: <200711030033.lA30XnqZ014621@cvs-int.fedora.redhat.com>
	<loom.20071103T172214-477@post.gmane.org>
	<20071103172639.GA2533@free.fr>
Message-ID: <200711032026.23179.ville.skytta@iki.fi>

On Saturday 03 November 2007, Patrice Dumas wrote:
> On Sat, Nov 03, 2007 at 05:23:33PM +0000, Kevin Kofler wrote:
> >
> > Yet "make upload" leaves the old sources listed there, so many packages
> > still have them, the maintainers clean up only occasionally if at all.
> > This is hardly the only package with old sources still listed.
>
> It is still a mistake.

Use "make new-sources" instead of "make upload" to take care of that 
automatically.



From jkeating at redhat.com  Sat Nov  3 18:31:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 3 Nov 2007 14:31:41 -0400
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.4,1.5 sources,1.5,1.6
In-Reply-To: <200711032026.23179.ville.skytta@iki.fi>
References: <200711030033.lA30XnqZ014621@cvs-int.fedora.redhat.com>
	<loom.20071103T172214-477@post.gmane.org>
	<20071103172639.GA2533@free.fr>
	<200711032026.23179.ville.skytta@iki.fi>
Message-ID: <20071103143141.5cc86168@redhat.com>

On Sat, 3 Nov 2007 20:26:21 +0200
"Ville Skytt?" <ville.skytta at iki.fi> wrote:

> Use "make new-sources" instead of "make upload" to take care of that 
> automatically.

Which is what is outlined in the wiki page that the OP posted.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/cba9762d/attachment.sig>

From mszpak at wp.pl  Sat Nov  3 18:34:21 2007
From: mszpak at wp.pl (=?ISO-8859-1?Q?Marcin_Zaja=3Bczkowski?=)
Date: Sat, 03 Nov 2007 19:34:21 +0100
Subject: Fedora 8 Test3 and problem with updates
In-Reply-To: <20071103125316.GD6839@auslistsprd01.us.dell.com>
References: <fghn21$6dv$1@ger.gmane.org>
	<20071103125316.GD6839@auslistsprd01.us.dell.com>
Message-ID: <fgieve$73e$1@ger.gmane.org>

On 2007-11-03 13:53, Matt Domsch wrote:
> On Sat, Nov 03, 2007 at 12:46:08PM +0100, Marcin Zaj?czkowski wrote:
>> In a meantime yum configuration started points to "normal" repository
>> (not development).
> 
> That's OK.  Until Fedora 8 is released, the "normal" repository points
> at the development repository on the backend.

Thanks, I thought it's done at fedora-release package level, but if
later fedora and fedora-updates points also to development then ok.


Regards
Marcin



From jdennis at redhat.com  Sat Nov  3 20:01:32 2007
From: jdennis at redhat.com (John Dennis)
Date: Sat, 03 Nov 2007 16:01:32 -0400
Subject: rpmbuild stops with debugedit error on F8
Message-ID: <472CD39C.4050206@redhat.com>

On F8 when I run rpmbuild I consistently get this error:

/usr/lib/rpm/debugedit: -b arg has to be either the same length as -d 
arg, or more than 1 char shorter

then the build fails. Any ideas?

its being called from /usr/lib/rpm/find-debuginfo.sh, I would expect the 
tools to be self consistent, I'm kinda at a loss as to what it's 
complaining about.

-- 
John Dennis <jdennis at redhat.com>



From mattdm at mattdm.org  Sat Nov  3 20:15:03 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 3 Nov 2007 16:15:03 -0400
Subject: rawhide -- sb live sound suddenly messed up?
Message-ID: <20071103201503.GA13640@jadzia.bu.edu>

I have a Creative Labs 4.1 (that is, 2 front, 2 rear, 1 subwoofer) digital
speaker system hooked up to an SB Live sound card. This has always had the
well-known quirk of digital being disabled by default, but suddenly as of a
week or so ago, there's a new problem: no sound except that meant for the
rear channels. I can mess with boosting that to the point where it's heard
from the subwoofer and front speakers as well, but I can't actually get the
main, normal sound to happen at all.

Anyone else seeing this? I believe it started sometime between Test 3 and
now.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mszpak at wp.pl  Sat Nov  3 20:58:01 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Sat, 03 Nov 2007 21:58:01 +0100
Subject: Fedora 8 Test3 and problem with updates
In-Reply-To: <fgieve$73e$1@ger.gmane.org>
References: <fghn21$6dv$1@ger.gmane.org>	<20071103125316.GD6839@auslistsprd01.us.dell.com>
	<fgieve$73e$1@ger.gmane.org>
Message-ID: <fgincp$un4$1@ger.gmane.org>

On 2007-11-03 19:34, Marcin Zaj?czkowski wrote:
> On 2007-11-03 13:53, Matt Domsch wrote:
>> On Sat, Nov 03, 2007 at 12:46:08PM +0100, Marcin Zaj?czkowski wrote:
>>> In a meantime yum configuration started points to "normal" repository
>>> (not development).
>> That's OK.  Until Fedora 8 is released, the "normal" repository points
>> at the development repository on the backend.
> 
> Thanks, I thought it's done at fedora-release package level, but if
> later fedora and fedora-updates points also to development then ok.

Btw, to prevent confusions of the readers it's still unknown (for me)
why the main problem with update occurred.


Marcin



From triad at df.lth.se  Sat Nov  3 21:25:08 2007
From: triad at df.lth.se (Linus Walleij)
Date: Sat, 3 Nov 2007 22:25:08 +0100 (CET)
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
Message-ID: <Pine.GSO.4.60.0711032221030.5764@igloo.df.lth.se>

On Thu, 1 Nov 2007, Peter Lemenkov wrote:

> Briefly speaking from the above notes we may find the following:
> * Looks like Ogg "violates" patents as well as mp3.

http://en.wikipedia.org/wiki/Vorbis#Licensing

Linus



From roland at redhat.com  Sat Nov  3 22:18:54 2007
From: roland at redhat.com (Roland McGrath)
Date: Sat,  3 Nov 2007 15:18:54 -0700 (PDT)
Subject: rpmbuild stops with debugedit error on F8
In-Reply-To: John Dennis's message of  Saturday,
	3 November 2007 16:01:32 -0400 <472CD39C.4050206@redhat.com>
References: <472CD39C.4050206@redhat.com>
Message-ID: <20071103221854.B0B4B4D04C0@magilla.localdomain>

> On F8 when I run rpmbuild I consistently get this error:
> 
> /usr/lib/rpm/debugedit: -b arg has to be either the same length as -d 
> arg, or more than 1 char shorter
> 
> then the build fails. Any ideas?

Please show the complete log and the exact reference to reproducing this.



From jos at xos.nl  Sat Nov  3 22:42:56 2007
From: jos at xos.nl (Jos Vos)
Date: Sat, 3 Nov 2007 23:42:56 +0100
Subject: Zimbra packages in Fedora
In-Reply-To: <47261CC8.8040507@fedoralinks.org>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
Message-ID: <20071103224256.GB29965@jasmine.xos.nl>

On Mon, Oct 29, 2007 at 12:47:52PM -0500, Robert 'Bob' Jensen wrote:

> Well just my personal opinion... Zimbra might be doing well but the 
> deployment system leaves a lot to be desired. Best I can tell (installed 
> on CentOS5) the current version available is packaged with a broken 
> tomcat server. There are some other things that should or would need to 
> be addressed also such as the way zimbra provides things like mysqld, 
> postfix, ok everything that makes zimbra work.
> 
> Step one disable the firewall, step two disable SElinux, step three run 
> the install script that will do a lot of things including install the 
> rpms...

I'm a bit surprised this thread had so few reactions.  Zimbra is really
a very useful piece of software and the "groupware" category of software
is really missing from Fedora (and most other distros, AFAIK).

IIRC there are build instructions (don't remember if they provide a
src.rpm or spec file, it's a while ago that I looked into it).

But: does it run without a non-free Java?

And: can for the bundled packages that you list above the standard Fedora
versions be used instead?

And last but not least: does Zimbra have a true Open Source license?

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From ngompa13 at gmail.com  Sat Nov  3 22:48:15 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Sat, 3 Nov 2007 17:48:15 -0500
Subject: Zimbra packages in Fedora
In-Reply-To: <20071103224256.GB29965@jasmine.xos.nl>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
	<20071103224256.GB29965@jasmine.xos.nl>
Message-ID: <8278b1b0711031548x6f804627yb0acdf91b633e210@mail.gmail.com>

I do not know about the first two, but I do know that Zimbra v4.x is under
MPL 1.1, while Zimbra 5.x is under Y!PL 1.0. OSI has not said anything about
Y!PL, but from the differences between Y!PL and MPL, it should be considered
a truly open source license. Also, Zimbra 4.x used to be hosted on
SourceForge.

On 11/3/07, Jos Vos <jos at xos.nl> wrote:
>
> On Mon, Oct 29, 2007 at 12:47:52PM -0500, Robert 'Bob' Jensen wrote:
>
> > Well just my personal opinion... Zimbra might be doing well but the
> > deployment system leaves a lot to be desired. Best I can tell (installed
> > on CentOS5) the current version available is packaged with a broken
> > tomcat server. There are some other things that should or would need to
> > be addressed also such as the way zimbra provides things like mysqld,
> > postfix, ok everything that makes zimbra work.
> >
> > Step one disable the firewall, step two disable SElinux, step three run
> > the install script that will do a lot of things including install the
> > rpms...
>
> I'm a bit surprised this thread had so few reactions.  Zimbra is really
> a very useful piece of software and the "groupware" category of software
> is really missing from Fedora (and most other distros, AFAIK).
>
> IIRC there are build instructions (don't remember if they provide a
> src.rpm or spec file, it's a while ago that I looked into it).
>
> But: does it run without a non-free Java?
>
> And: can for the bundled packages that you list above the standard Fedora
> versions be used instead?
>
> And last but not least: does Zimbra have a true Open Source license?
>
> --
> --    Jos Vos <jos at xos.nl>
> --    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/4f575392/attachment.htm>

From jon at fedoraunity.org  Sat Nov  3 22:58:11 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Sat, 03 Nov 2007 16:58:11 -0600
Subject: Zimbra packages in Fedora
In-Reply-To: <20071103224256.GB29965@jasmine.xos.nl>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>	<47261CC8.8040507@fedoralinks.org>
	<20071103224256.GB29965@jasmine.xos.nl>
Message-ID: <472CFD03.7000706@fedoraunity.org>

Jos Vos wrote:
> I'm a bit surprised this thread had so few reactions.  Zimbra is really
> a very useful piece of software and the "groupware" category of software
> is really missing from Fedora (and most other distros, AFAIK).

Zimbra is not distro friendly. It ships it's own versions of everything
and also requires selinux to be off and iptables to be off.

> 
> IIRC there are build instructions (don't remember if they provide a
> src.rpm or spec file, it's a while ago that I looked into it).

They don't provide srpms. Even their rpms need to be installed with
their install script. The rpms themselves assume very strange things
that would never be accepted into fedora in their current state.. and
this is just from watching the massive errors when installing without
their installer script (and with selinux enforcing.. now that was a
mess.. had to rebuild the server). I started to audit a policy for
Zimbra and it made me green in the face.

> 
> But: does it run without a non-free Java?

I'm not sure what java they build against, but tomcat is broken on
Centos 5 after *any* yum updates and some other strange issues. Maybe
bob can chime in with his findings, it pissed me off enough I stopped
working on it.

> 
> And: can for the bundled packages that you list above the standard Fedora
> versions be used instead?

I really wish they would release an "addon" package set that could be
integrated with existing distro maintained packages, but I highly doubt
this will ever happen. This being after I've studied their install
system and have had Zimbra in testing for a while.

Please don't get me wrong... +1 to Zimbra for putting together a cool
system, but don't expect to have a multipurpose machine after letting
zimbra have it's way with your bits. A derivative distro would be more
useful then what they have now :-/


-- 
Jonathan Steffan
daMaestro
Fedora Unity - http://fedoraunity.org/
GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59



From jos at xos.nl  Sat Nov  3 23:10:48 2007
From: jos at xos.nl (Jos Vos)
Date: Sun, 4 Nov 2007 00:10:48 +0100
Subject: Zimbra packages in Fedora
In-Reply-To: <472CFD03.7000706@fedoraunity.org>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
	<20071103224256.GB29965@jasmine.xos.nl>
	<472CFD03.7000706@fedoraunity.org>
Message-ID: <20071103231048.GA31592@jasmine.xos.nl>

On Sat, Nov 03, 2007 at 04:58:11PM -0600, Jonathan Steffan wrote:

> They don't provide srpms. Even their rpms need to be installed with
> their install script. The rpms themselves assume very strange things
> that would never be accepted into fedora in their current state.. and
> this is just from watching the massive errors when installing without
> their installer script (and with selinux enforcing.. now that was a
> mess.. had to rebuild the server). I started to audit a policy for
> Zimbra and it made me green in the face.

[...]

> I really wish they would release an "addon" package set that could be
> integrated with existing distro maintained packages, but I highly doubt
> this will ever happen. This being after I've studied their install
> system and have had Zimbra in testing for a while.
> 
> Please don't get me wrong... +1 to Zimbra for putting together a cool
> system, but don't expect to have a multipurpose machine after letting
> zimbra have it's way with your bits. A derivative distro would be more
> useful then what they have now :-/

This all is even worse than what I already from what I read and tried
(but I didn't go as far as you did).

I'm afraid is not in their interest if distros are capable of including
Zimbra.  They use Open Source mainly as a marketing tool, for the rest
the Open Source world can't do a lot with it :-(.

B.t.w., Red Hat eXchange (commercial and expensive add-ons for RHEL)
includes Zimbra.  Wondering if installing those RPMs (I assume they
provide RPMs) screw up your RHEL system too.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From ngompa13 at gmail.com  Sat Nov  3 23:13:27 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Sat, 3 Nov 2007 18:13:27 -0500
Subject: Zimbra packages in Fedora
In-Reply-To: <20071103231048.GA31592@jasmine.xos.nl>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
	<20071103224256.GB29965@jasmine.xos.nl>
	<472CFD03.7000706@fedoraunity.org>
	<20071103231048.GA31592@jasmine.xos.nl>
Message-ID: <8278b1b0711031613m7bbd18f8x825ff878026de3c1@mail.gmail.com>

If they do have RPMs, wouldn't they have to release SRPMs too? And I don't
think Red Hat is stupid enough to just say all willy nilly that the SELinux
should be shut off for Zimbra. They probably did some work to make Zimbra
play nice with SELinux.

On 11/3/07, Jos Vos <jos at xos.nl> wrote:
>
> On Sat, Nov 03, 2007 at 04:58:11PM -0600, Jonathan Steffan wrote:
>
> > They don't provide srpms. Even their rpms need to be installed with
> > their install script. The rpms themselves assume very strange things
> > that would never be accepted into fedora in their current state.. and
> > this is just from watching the massive errors when installing without
> > their installer script (and with selinux enforcing.. now that was a
> > mess.. had to rebuild the server). I started to audit a policy for
> > Zimbra and it made me green in the face.
>
> [...]
>
> > I really wish they would release an "addon" package set that could be
> > integrated with existing distro maintained packages, but I highly doubt
> > this will ever happen. This being after I've studied their install
> > system and have had Zimbra in testing for a while.
> >
> > Please don't get me wrong... +1 to Zimbra for putting together a cool
> > system, but don't expect to have a multipurpose machine after letting
> > zimbra have it's way with your bits. A derivative distro would be more
> > useful then what they have now :-/
>
> This all is even worse than what I already from what I read and tried
> (but I didn't go as far as you did).
>
> I'm afraid is not in their interest if distros are capable of including
> Zimbra.  They use Open Source mainly as a marketing tool, for the rest
> the Open Source world can't do a lot with it :-(.
>
> B.t.w., Red Hat eXchange (commercial and expensive add-ons for RHEL)
> includes Zimbra.  Wondering if installing those RPMs (I assume they
> provide RPMs) screw up your RHEL system too.
>
> --
> --    Jos Vos <jos at xos.nl>
> --    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/7df3ebfa/attachment.htm>

From ivazqueznet at gmail.com  Sat Nov  3 23:16:01 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 03 Nov 2007 19:16:01 -0400
Subject: Zimbra packages in Fedora
In-Reply-To: <8278b1b0711031613m7bbd18f8x825ff878026de3c1@mail.gmail.com>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
	<20071103224256.GB29965@jasmine.xos.nl>
	<472CFD03.7000706@fedoraunity.org>
	<20071103231048.GA31592@jasmine.xos.nl>
	<8278b1b0711031613m7bbd18f8x825ff878026de3c1@mail.gmail.com>
Message-ID: <1194131761.6278.9.camel@ignacio.lan>

On Sat, 2007-11-03 at 18:13 -0500, King InuYasha wrote:
> If they do have RPMs, wouldn't they have to release SRPMs too?

Not necessarily. There's no provision that says that packaging metadata
has to be under the same license as the software.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/1795dd8a/attachment.sig>

From ngompa13 at gmail.com  Sat Nov  3 23:27:19 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Sat, 3 Nov 2007 18:27:19 -0500
Subject: Zimbra packages in Fedora
In-Reply-To: <1194131761.6278.9.camel@ignacio.lan>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
	<47261CC8.8040507@fedoralinks.org>
	<20071103224256.GB29965@jasmine.xos.nl>
	<472CFD03.7000706@fedoraunity.org>
	<20071103231048.GA31592@jasmine.xos.nl>
	<8278b1b0711031613m7bbd18f8x825ff878026de3c1@mail.gmail.com>
	<1194131761.6278.9.camel@ignacio.lan>
Message-ID: <8278b1b0711031627n25384868u500ac783245cb30e@mail.gmail.com>

Well, the source code for Zimbra 4.x is large, the specfiles i think are
generated by the Makefile in \ZimbraBuild folder. The structure seems
similar in Zimbra 5.0 RC1, so there is a piece of the mystery there...

On 11/3/07, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> wrote:
>
> On Sat, 2007-11-03 at 18:13 -0500, King InuYasha wrote:
> > If they do have RPMs, wouldn't they have to release SRPMs too?
>
> Not necessarily. There's no provision that says that packaging metadata
> has to be under the same license as the software.
>
> --
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
>
> PLEASE don't CC me; I'm already subscribed
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/31a85209/attachment.htm>

From roland at redhat.com  Sat Nov  3 23:30:34 2007
From: roland at redhat.com (Roland McGrath)
Date: Sat,  3 Nov 2007 16:30:34 -0700 (PDT)
Subject: rpmbuild stops with debugedit error on F8
In-Reply-To: John Dennis's message of  Saturday,
	3 November 2007 19:05:00 -0400 <472CFE9C.10506@redhat.com>
References: <472CD39C.4050206@redhat.com>
	<20071103221854.B0B4B4D04C0@magilla.localdomain>
	<472CFE9C.10506@redhat.com>
Message-ID: <20071103233034.7F16D4D04C0@magilla.localdomain>

Ok, it's simply as it says.  /rpmbuild/build is 15 chars and /usr/src/debug
is 14 chars.  That's just a bad choice for the directory name.  In koji
builds go under /builddir/build/BUILD (21 chars), so there is no problem.
The default for vanilla rpmbuild is /usr/src/redhat/BUILD (21 chars).

It's a technical limitation of the debugedit program that, like the error
message says, the length of the top build directory name has to be 14 chars
(to match /usr/src/debug), or more than 15 chars.  It does a very limited
kind of rewriting of the very complex DWARF formats, so there has to be
enough room in the existing string table for the new directory name.
Making it able to cope in the general case opens huge cans of worms, and is
absolutely not going to happen any time soon (or ever in that program as it
exists today).

Suffice it to say it is far, far more work than is justified to avoid the
arcane but trivial caveat that the base directory name used for builds must
be at least 16 chars long.


Thanks,
Roland



From the.masch at gmail.com  Sun Nov  4 00:00:09 2007
From: the.masch at gmail.com (masch)
Date: Sun, 4 Nov 2007 00:00:09 +0000
Subject: F8 Nvidia Ethernet Ip Problem
Message-ID: <93d66b780711031700t7eadca8fvd98f76b00482e029@mail.gmail.com>

I'm trying to set up Fedora 8 RC3 and i can't set up my network
device. I have nVidia MP55 ethernet and i'm can't get my ip from DHCP,
i have dual boot with WinXp, Sorry :D , and it work well. I was using
Fedora 7 and it's work too....

Can anybody know what it's the probem??

Salu2..



From cjdahlin at ncsu.edu  Sun Nov  4 00:45:28 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Sat, 03 Nov 2007 20:45:28 -0400
Subject: F8 Nvidia Ethernet Ip Problem
In-Reply-To: <93d66b780711031700t7eadca8fvd98f76b00482e029@mail.gmail.com>
References: <93d66b780711031700t7eadca8fvd98f76b00482e029@mail.gmail.com>
Message-ID: <472D1628.2080607@ncsu.edu>

masch wrote:
> I'm trying to set up Fedora 8 RC3 and i can't set up my network
> device. I have nVidia MP55 ethernet and i'm can't get my ip from DHCP,
> i have dual boot with WinXp, Sorry :D , and it work well. I was using
> Fedora 7 and it's work too....
>
> Can anybody know what it's the probem??
>
> Salu2..
>
>   
I've had this issue too. MCP55 on an Asus Striker Extreme mobo. For me 
it only worked with the stock F7 kernel. Even yum updating to a more 
recent F7 broke it.



From lsof at nodata.co.uk  Sun Nov  4 01:02:31 2007
From: lsof at nodata.co.uk (nodata)
Date: Sun, 04 Nov 2007 02:02:31 +0100
Subject: Zimbra packages in Fedora
In-Reply-To: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
References: <8278b1b0710281746p65cc7f58sd3078d78185dba63@mail.gmail.com>
Message-ID: <1194138151.2772.9.camel@sb-home>


Am Sonntag, den 28.10.2007, 19:46 -0500 schrieb King InuYasha:
> I had noticed how well that Zimbra has been doing, and I was wondering
> if it would be possible for someone to make packages for Zimbra to be
> included in Fedora?
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Is Zimbra still distributed as a horrible huge bundle of mess?



From ssorce at redhat.com  Sun Nov  4 01:18:45 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Sat, 03 Nov 2007 21:18:45 -0400
Subject: What's the current status of mp3-licensing issues?
In-Reply-To: <Pine.GSO.4.60.0711032221030.5764@igloo.df.lth.se>
References: <adf480660711010047k2d1877b5i694ca765263c9b29@mail.gmail.com>
	<Pine.GSO.4.60.0711032221030.5764@igloo.df.lth.se>
Message-ID: <1194139125.21823.70.camel@localhost.localdomain>

On Sat, 2007-11-03 at 22:25 +0100, Linus Walleij wrote:
> On Thu, 1 Nov 2007, Peter Lemenkov wrote:
> 
> > Briefly speaking from the above notes we may find the following:
> > * Looks like Ogg "violates" patents as well as mp3.
> 
> http://en.wikipedia.org/wiki/Vorbis#Licensing

To my reading this section claims quite the contrary.

Let's not witch hunt on programs that can or may, or could violate
patents.
Unless we know for sure a program implements a very specific patent
covered method then only if there is a specific patent holder that comes
out and claims a specific patent is violated by a specific
program/library we should care.

Anything else is just going to be a mainly waste of time IMO.

Simo.



From bobhillegas at gmail.com  Sun Nov  4 01:23:11 2007
From: bobhillegas at gmail.com (Bob Hillegas)
Date: Sat, 3 Nov 2007 20:23:11 -0500
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7 (again)
Message-ID: <9978803b0711031823v712c85f8vd0d09fda315c6b82@mail.gmail.com>

I saw a posting in the archive on Oct  30th with this identical problem. It
didn't appear to be resolved.
Has anyone come up with a solution?
What kind on authorization needs to be established on 127.0.0.1 for rpcbind?

OR is this a quota issue?

This worked fine up until the last yum update.

Thanks, BobH


[root]# service rpcbind restart
Stopping rpcbind:                                          [  OK  ]
Starting rpcbind:                                          [  OK  ]
[root]# service nfs restart
Shutting down NFS mountd:                                  [FAILED]
Shutting down NFS daemon:                                  [FAILED]
Shutting down NFS quotas:                                  [FAILED]
Shutting down NFS services:                                [  OK  ]
Starting NFS services:                                     [  OK  ]
Starting NFS quotas: Cannot register service: RPC: Authentication error; why
= Client credential too weak
rpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).
                                                           [FAILED]
Starting NFS daemon:                                       [FAILED]

>From /var/log/messages:
Nov  3 20:16:18 north rpcbind: rpcbind terminating on signal. Restart with
"rpcbind -w"
Nov  3 20:16:18 north rpcbind: cannot bind * on udp6: Address already in use
Nov  3 20:16:18 north rpcbind: cannot bind tcp6: Address already in use
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to unset(rquotad):
request from unauthorized host
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to unset(rquotad):
request from unauthorized host
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to set(rquotad):
request from unauthorized host
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to unset(nfs): request
from unauthorized host
Nov  3 20:16:28 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:28 north kernel: RPC: failed to contact local rpcbind server
(errno 13).
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to set(nfs): request
from unauthorized host
Nov  3 20:16:28 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:28 north kernel: RPC: failed to contact local rpcbind server
(errno 13).
Nov  3 20:16:28 north nfsd[6683]: nfssvc: writing fds to kernel failed:
errno 13 (Permission denied)
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to set(nfs): request
from unauthorized host
Nov  3 20:16:28 north nfsd[6683]: nfssvc: writing fds to kernel failed:
errno 13 (Permission denied)
Nov  3 20:16:28 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:28 north kernel: RPC: failed to contact local rpcbind server
(errno 13).
Nov  3 20:16:28 north kernel: NFSD: Using /var/lib/nfs/v4recovery as the
NFSv4 state recovery directory
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to unset(nlockmgr):
request from unauthorized host
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to set(nlockmgr):
request from unauthorized host
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to unset(nlockmgr):
request from unauthorized host
Nov  3 20:16:28 north rpcbind: connect from 127.0.0.1 to unset(nfs): request
from unauthorized host
Nov  3 20:16:28 north nfsd[6683]: nfssvc: Permission denied
Nov  3 20:16:28 north kernel: NFSD: starting 90-second grace period
Nov  3 20:16:28 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:29 north kernel: RPC: failed to contact local rpcbind server
(errno 13).
Nov  3 20:16:29 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:29 north kernel: RPC: failed to contact local rpcbind server
(errno 13).
Nov  3 20:16:29 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:29 north kernel: RPC: failed to contact local rpcbind server
(errno 13).
Nov  3 20:16:29 north kernel: nfsd: last server has exited
Nov  3 20:16:29 north kernel: nfsd: unexporting all filesystems
Nov  3 20:16:29 north kernel: call_verify: server localhost requires
stronger authentication.
Nov  3 20:16:29 north kernel: RPC: failed to contact local rpcbind server
(errno 13).



-- 
BobH
bobhillegas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071103/b32da490/attachment.htm>

From mschwendt.tmp0701.nospam at arcor.de  Sun Nov  4 10:11:00 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 4 Nov 2007 11:11:00 +0100
Subject: NFS problem after update to rpcbind-0.1.4-8.fc7 (again)
In-Reply-To: <9978803b0711031823v712c85f8vd0d09fda315c6b82@mail.gmail.com>
References: <9978803b0711031823v712c85f8vd0d09fda315c6b82@mail.gmail.com>
Message-ID: <20071104111100.9efdbcfb.mschwendt.tmp0701.nospam@arcor.de>

On Sat, 3 Nov 2007 20:23:11 -0500, Bob Hillegas wrote:

> I saw a posting in the archive on Oct  30th with this identical problem. It
> didn't appear to be resolved.
> Has anyone come up with a solution?

Some of the people on fedora-list and in bugzilla have added an entry
to /etc/hosts.allow, noticing the corresponding changelog comment in
"rpm -q --changelog rpcbind". That has fixed it for them, but with
other installations it is not needed, as nfs starts fine:

# service nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]

# rpm -q rpcbind nfs-utils
rpcbind-0.1.4-11.fc8
nfs-utils-1.1.0-6.fc8



From trond.danielsen at gmail.com  Sun Nov  4 11:24:50 2007
From: trond.danielsen at gmail.com (Trond Danielsen)
Date: Sun, 4 Nov 2007 12:24:50 +0100
Subject: Fedora 8 on Asus S5A;
	asus_laptop parameters and wireless enable/disable function key
Message-ID: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>

Hi,

My laptop has a wireless enable/disable function key, which previously
only disabled the wireless network and it could only be enabled by
rebooting into Windows. In Fedora 8 I can finally both enable and
disable the network by adding the parameter wapf=4 to modprobe
(modprobe asus_laptop wapf=4). This means that I can finally wipe out
my Windows partition. Horray! :)

My question is very simple: Which component should I file the bug against?

Regard,
-- 
Trond Danielsen



From drago01 at gmail.com  Sun Nov  4 11:38:34 2007
From: drago01 at gmail.com (drago01)
Date: Sun, 04 Nov 2007 12:38:34 +0100
Subject: Fedora 8 on Asus S5A;
 asus_laptop parameters and wireless enable/disable function key
In-Reply-To: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
References: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
Message-ID: <472DAF3A.6090006@gmail.com>

Trond Danielsen wrote:
> Hi,
>
> My laptop has a wireless enable/disable function key, which previously
> only disabled the wireless network and it could only be enabled by
> rebooting into Windows. In Fedora 8 I can finally both enable and
> disable the network by adding the parameter wapf=4 to modprobe
> (modprobe asus_laptop wapf=4). This means that I can finally wipe out
> my Windows partition. Horray! :)
>
> My question is very simple: Which component should I file the bug against?
>
>   
kernel



From kwizart at gmail.com  Sun Nov  4 12:06:18 2007
From: kwizart at gmail.com (KH KH)
Date: Sun, 4 Nov 2007 13:06:18 +0100
Subject: Fedora 8 on Asus S5A;
	asus_laptop parameters and wireless enable/disable function key
In-Reply-To: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
References: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
Message-ID: <e1760170711040406pd92a21ej36ff7c4e86bc7f67@mail.gmail.com>

2007/11/4, Trond Danielsen <trond.danielsen at gmail.com>:
> Hi,
>
> My laptop has a wireless enable/disable function key, which previously
> only disabled the wireless network and it could only be enabled by
> rebooting into Windows. In Fedora 8 I can finally both enable and
> disable the network by adding the parameter wapf=4 to modprobe
> (modprobe asus_laptop wapf=4). This means that I can finally wipe out
> my Windows partition. Horray! :)
>
> My question is very simple: Which component should I file the bug against?

Did you sent your /proc/acpi/dsdt file to the asus4acpi project at sourceforge ?

Nicolas (kwizart )

> Regard,
> --
> Trond Danielsen
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From ndbecker2 at gmail.com  Sun Nov  4 12:08:55 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 04 Nov 2007 07:08:55 -0500
Subject: Is devel frozen?
Message-ID: <fgkcon$b3k$2@ger.gmane.org>

I built python-which successfully, but it's not showing up in devel.  Do I
need to do something, or is this because devel is currently frozen?  (I
can't run mock on my dblatex package because it requires python-which - is
there a workaround?)



From jkeating at redhat.com  Sun Nov  4 12:15:15 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 4 Nov 2007 07:15:15 -0500
Subject: Is devel frozen?
In-Reply-To: <fgkcon$b3k$2@ger.gmane.org>
References: <fgkcon$b3k$2@ger.gmane.org>
Message-ID: <20071104071515.28b96b93@redhat.com>

On Sun, 04 Nov 2007 07:08:55 -0500
Neal Becker <ndbecker2 at gmail.com> wrote:

> I built python-which successfully, but it's not showing up in devel.
> Do I need to do something, or is this because devel is currently
> frozen?  (I can't run mock on my dblatex package because it requires
> python-which - is there a workaround?)

Builds from devel/ are going into dist-f9.  Rawhide is still being
composed from f8-final which is the frozen Fedora 8 bits.  This is so
that we can easily transition early adopters of Fedora 8 to the final
bits on release day without dumping all the F9 stuff on them.  The day
after release (Friday) rawhide should start seeing F9 content.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071104/8fb570c0/attachment.sig>

From fedora at camperquake.de  Sun Nov  4 12:39:51 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 4 Nov 2007 13:39:51 +0100
Subject: Is devel frozen?
In-Reply-To: <20071104071515.28b96b93@redhat.com>
References: <fgkcon$b3k$2@ger.gmane.org> <20071104071515.28b96b93@redhat.com>
Message-ID: <20071104133951.0be38340@lain.camperquake.de>

Hi.

On Sun, 4 Nov 2007 07:15:15 -0500, Jesse Keating wrote

> Builds from devel/ are going into dist-f9.  Rawhide is still being
> composed from f8-final which is the frozen Fedora 8 bits.  This is so
> that we can easily transition early adopters of Fedora 8 to the final
> bits on release day without dumping all the F9 stuff on them.  The day
> after release (Friday) rawhide should start seeing F9 content.

I am not quite up to speed on the proposal.. is this planned to be
changed for F9 and later?



From buildsys at redhat.com  Sun Nov  4 12:42:12 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 4 Nov 2007 07:42:12 -0500
Subject: rawhide report: 20071104 changes
Message-ID: <200711041242.lA4CgCBx030116@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From jkeating at redhat.com  Sun Nov  4 12:56:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 4 Nov 2007 07:56:38 -0500
Subject: Is devel frozen?
In-Reply-To: <20071104133951.0be38340@lain.camperquake.de>
References: <fgkcon$b3k$2@ger.gmane.org> <20071104071515.28b96b93@redhat.com>
	<20071104133951.0be38340@lain.camperquake.de>
Message-ID: <20071104075638.3aab7d52@redhat.com>

On Sun, 4 Nov 2007 13:39:51 +0100
Ralf Ertzinger <fedora at camperquake.de> wrote:

> I am not quite up to speed on the proposal.. is this planned to be
> changed for F9 and later?

In F9 we hope to be able to stage the F9 bits into the final location
(or something close to it with redirects) that we can point people to,
while allowing F(??) builds to show up in the traditional rawhide
location.  We just don't have the capability of doing that this release.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071104/88ca0f90/attachment.sig>

From fedora at camperquake.de  Sun Nov  4 13:06:45 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 4 Nov 2007 14:06:45 +0100
Subject: Is devel frozen?
In-Reply-To: <20071104075638.3aab7d52@redhat.com>
References: <fgkcon$b3k$2@ger.gmane.org> <20071104071515.28b96b93@redhat.com>
	<20071104133951.0be38340@lain.camperquake.de>
	<20071104075638.3aab7d52@redhat.com>
Message-ID: <20071104140645.1b9f5b76@lain.camperquake.de>

Hi.

On Sun, 4 Nov 2007 07:56:38 -0500, Jesse Keating wrote

> In F9 we hope to be able to stage the F9 bits into the final location
> (or something close to it with redirects) that we can point people to,
> while allowing F(??) builds to show up in the traditional rawhide
> location.  We just don't have the capability of doing that this
> release.

Thanks.



From ndbecker2 at gmail.com  Sun Nov  4 13:12:57 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 04 Nov 2007 08:12:57 -0500
Subject: Is devel frozen?
References: <fgkcon$b3k$2@ger.gmane.org> <20071104071515.28b96b93@redhat.com>
Message-ID: <fgkggp$l0u$1@ger.gmane.org>

Jesse Keating wrote:

> On Sun, 04 Nov 2007 07:08:55 -0500
> Neal Becker <ndbecker2 at gmail.com> wrote:
> 
>> I built python-which successfully, but it's not showing up in devel.
>> Do I need to do something, or is this because devel is currently
>> frozen?  (I can't run mock on my dblatex package because it requires
>> python-which - is there a workaround?)
> 
> Builds from devel/ are going into dist-f9.  Rawhide is still being
> composed from f8-final which is the frozen Fedora 8 bits.  This is so
> that we can easily transition early adopters of Fedora 8 to the final
> bits on release day without dumping all the F9 stuff on them.  The day
> after release (Friday) rawhide should start seeing F9 content.
> 

So what change is needed to mock to point it to the correct repos?



From subhodip at fedoraproject.org  Sun Nov  4 13:22:03 2007
From: subhodip at fedoraproject.org (subhodip biswas)
Date: Sun, 4 Nov 2007 18:52:03 +0530
Subject: problem with fuse
Message-ID: <539333cb0711040522o15626ccapa1a26d28ff462c9a@mail.gmail.com>

Hi !

i was testing a ltsp setup...in order to support localdev i installed
fuse and added user to it.

problem is lsmod | grep fuse does no always return a output. i have to
manually modprobe fuse . after this lsmod | grep fuse gives an output.

what is wrong?? what i am missing??

-- 
GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From trond.danielsen at gmail.com  Sun Nov  4 14:36:31 2007
From: trond.danielsen at gmail.com (Trond Danielsen)
Date: Sun, 4 Nov 2007 15:36:31 +0100
Subject: Fedora 8 on Asus S5A;
	asus_laptop parameters and wireless enable/disable function key
In-Reply-To: <e1760170711040406pd92a21ej36ff7c4e86bc7f67@mail.gmail.com>
References: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
	<e1760170711040406pd92a21ej36ff7c4e86bc7f67@mail.gmail.com>
Message-ID: <409676c70711040636i1e97025an5e6aa086b88579d5@mail.gmail.com>

2007/11/4, KH KH <kwizart at gmail.com>:
> 2007/11/4, Trond Danielsen <trond.danielsen at gmail.com>:
> > Hi,
> >
> > My laptop has a wireless enable/disable function key, which previously
> > only disabled the wireless network and it could only be enabled by
> > rebooting into Windows. In Fedora 8 I can finally both enable and
> > disable the network by adding the parameter wapf=4 to modprobe
> > (modprobe asus_laptop wapf=4). This means that I can finally wipe out
> > my Windows partition. Horray! :)
> >
> > My question is very simple: Which component should I file the bug against?
>
> Did you sent your /proc/acpi/dsdt file to the asus4acpi project at sourceforge ?

The laptop is already supported by the asus_laptop driver:

http://sourceforge.net/tracker/index.php?func=detail&aid=1455776&group_id=81433&atid=562934

Dmesg snippet below:

asus-laptop: Asus Laptop Support version 0.42
asus-laptop:   S5A model detected
Registered led device: asus:mail


-- 
Trond Danielsen



From sandeen at redhat.com  Sun Nov  4 15:29:43 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 04 Nov 2007 09:29:43 -0600
Subject: problem with fuse
In-Reply-To: <539333cb0711040522o15626ccapa1a26d28ff462c9a@mail.gmail.com>
References: <539333cb0711040522o15626ccapa1a26d28ff462c9a@mail.gmail.com>
Message-ID: <472DE567.9030609@redhat.com>

subhodip biswas wrote:
> Hi !
> 
> i was testing a ltsp setup...in order to support localdev i installed
> fuse and added user to it.
> 
> problem is lsmod | grep fuse does no always return a output. i have to
> manually modprobe fuse . after this lsmod | grep fuse gives an output.
> 
> what is wrong?? what i am missing??
> 

The fuse initscript will load the module (/etc/init.d/fuse)

unfortunately:
[root at localhost ~]# chkconfig --add fuse
service fuse does not support chkconfig

on an F8test3-ish box.

-Eric



From sandeen at redhat.com  Sun Nov  4 15:43:27 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 04 Nov 2007 09:43:27 -0600
Subject: problem with fuse
In-Reply-To: <472DE567.9030609@redhat.com>
References: <539333cb0711040522o15626ccapa1a26d28ff462c9a@mail.gmail.com>
	<472DE567.9030609@redhat.com>
Message-ID: <472DE89F.2060409@redhat.com>

Eric Sandeen wrote:

> unfortunately:
> [root at localhost ~]# chkconfig --add fuse
> service fuse does not support chkconfig
> 
> on an F8test3-ish box.

Bugzilla Bug 228088: chkconfig support
https://bugzilla.redhat.com/show_bug.cgi?id=228088

Bummer that didn't get fixed for F8.

-Eric



From mark.bidewell at alumni.clemson.edu  Sun Nov  4 16:42:48 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Sun, 4 Nov 2007 11:42:48 -0500
Subject: virt-manager
Message-ID: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>

I was looking at virt-manager in F8 and I notoced that it no longer
seems to have gui install capability.  has this been removed
intentionally or is this a bug?

Mark Bidewell



From berrange at redhat.com  Sun Nov  4 16:52:20 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Sun, 4 Nov 2007 16:52:20 +0000
Subject: virt-manager
In-Reply-To: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
References: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
Message-ID: <20071104165220.GA4103@redhat.com>

On Sun, Nov 04, 2007 at 11:42:48AM -0500, Mark Bidewell wrote:
> I was looking at virt-manager in F8 and I notoced that it no longer
> seems to have gui install capability.  has this been removed
> intentionally or is this a bug?

It only has the install capability if managing a local hypervisor - on par
with previous Fedora release. Although we added remote management support, the 
latter does not yet allow creation of VMs, because we're waiting for storage
managemnet APIs in libvirt - creation of VMs remotely will be enable during
a F8 update.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From halfline at gmail.com  Sun Nov  4 16:54:24 2007
From: halfline at gmail.com (Ray Strode)
Date: Sun, 4 Nov 2007 11:54:24 -0500
Subject: virt-manager
In-Reply-To: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
References: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
Message-ID: <45abe7d80711040854g1632533bh199a1b91a0775a1e@mail.gmail.com>

Hi,

On Nov 4, 2007 11:42 AM, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> I was looking at virt-manager in F8 and I notoced that it no longer
> seems to have gui install capability.  has this been removed
> intentionally or is this a bug?
I think the UI is just a lot more complicated to use then it used to
be.  If you go

File > Open Connection

then choose "Connect" it will create an item in the window.  You then
need to click a paper icon with a star in the upper right hand corner.
Or something like that.

--Ray



From mark.bidewell at alumni.clemson.edu  Sun Nov  4 16:59:04 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Sun, 4 Nov 2007 11:59:04 -0500
Subject: virt-manager
In-Reply-To: <45abe7d80711040854g1632533bh199a1b91a0775a1e@mail.gmail.com>
References: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
	<45abe7d80711040854g1632533bh199a1b91a0775a1e@mail.gmail.com>
Message-ID: <bfdeacfa0711040859x6863764ek94cb8fb63ed36074@mail.gmail.com>

found it Thx

On Nov 4, 2007 11:54 AM, Ray Strode <halfline at gmail.com> wrote:
> Hi,
>
>
> On Nov 4, 2007 11:42 AM, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> > I was looking at virt-manager in F8 and I notoced that it no longer
> > seems to have gui install capability.  has this been removed
> > intentionally or is this a bug?
> I think the UI is just a lot more complicated to use then it used to
> be.  If you go
>
> File > Open Connection
>
> then choose "Connect" it will create an item in the window.  You then
> need to click a paper icon with a star in the upper right hand corner.
> Or something like that.
>
> --Ray
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From berrange at redhat.com  Sun Nov  4 17:14:27 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Sun, 4 Nov 2007 17:14:27 +0000
Subject: virt-manager
In-Reply-To: <45abe7d80711040854g1632533bh199a1b91a0775a1e@mail.gmail.com>
References: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
	<45abe7d80711040854g1632533bh199a1b91a0775a1e@mail.gmail.com>
Message-ID: <20071104171427.GB4103@redhat.com>

On Sun, Nov 04, 2007 at 11:54:24AM -0500, Ray Strode wrote:
> Hi,
> 
> On Nov 4, 2007 11:42 AM, Mark Bidewell <mark.bidewell at alumni.clemson.edu> wrote:
> > I was looking at virt-manager in F8 and I notoced that it no longer
> > seems to have gui install capability.  has this been removed
> > intentionally or is this a bug?
> I think the UI is just a lot more complicated to use then it used to
> be.  If you go
> 
> File > Open Connection
> 
> then choose "Connect" it will create an item in the window.  You then
> need to click a paper icon with a star in the upper right hand corner.

It shouldn't be neccessary to explicitly connect to the local machine - if 
you have no existing host connections remembered in gconf, it will try to 
automatically add a connection to the local Xen or KVM instance.  Yes, the
'new VM' icon has proved to be a little too subtle for many people, so 
we'll likely revise that bit of UI to make it more obvious in an update.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From valent.turkovic at gmail.com  Sun Nov  4 18:15:57 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 4 Nov 2007 19:15:57 +0100
Subject: Fluendo codecs in Fedora 8?
In-Reply-To: <1193901290.3048.10.camel@dawkins>
References: <64b14b300710241306o6ee9acbdhca084f8e7f9cfae1@mail.gmail.com>
	<121988a30710251215h7e0f172dnb4ad6b4a9c8f7d82@mail.gmail.com>
	<64b14b300710251232v1a7eb8f8rab48f80a94119cf7@mail.gmail.com>
	<4720F01E.9030802@fedoraproject.org>
	<64b14b300710251353j48f13363tf77b36853f663a1b@mail.gmail.com>
	<64b14b300710251356wdc793fenda3e37da5d0dacc@mail.gmail.com>
	<64b14b300710270720nd4502f4m1c39ae1fb536635c@mail.gmail.com>
	<47234A5F.4000701@fedoraproject.org>
	<64b14b300710270752r68bda22eqfa901c3db7c16e3d@mail.gmail.com>
	<1193901290.3048.10.camel@dawkins>
Message-ID: <64b14b300711041015u5250fe98t17d11bcbaedb7215@mail.gmail.com>

On 11/1/07, David Nielsen <david at lovesunix.net> wrote:
>
> l?r, 27 10 2007 kl. 16:52 +0200, skrev Valent Turkovic:
> > On 10/27/07, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> > > Valent Turkovic wrote:
> > > > On 10/25/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> > > >> https://core.fluendo.com/gstreamer/trac/ticket/24
> > > >> previous link was a duplicate, sorry.
> > > >>
> > > >> Valent.
> > > >>
> > > >
> > > > This is the reply I got from fluendo support:
> > > >
> > > >       to              Valent Turkovic <valent.turkovic at gmail.com>
> > > >       cc              Fluendo Store Manager <contact at fluendo.com>
> > > >       date            Oct 26, 2007 10:42 AM
> > > >       subject         Re: Fluendo codecs in Fedora 8?
> > > >
> > > > Yes we know about that problem and we are pushing Intel everyday to
> > > > provide us with a version of IPP that does not do text relocation.
> > > >
> > > > Sorry for the frustration that it creates.
> > >
> > > You can consider filing a RFE against SELinux policy to not deny this.
> > >
> > > Rahul
> > >
> >
> > Thanks Rahul, I'll try that...
>
> What is the bug number for this?
>
> If we can't make this happen then the Codecbuddy feature kinda falls
> apart, requiring the user first to click his way through a dialog then
> drop to a shell and invoke SELinux magic in accordance to the "known
> issues" page which.. nobody appears to read.
>
> - David, your friend neighborhood QA monkey.
>

https://bugzilla.redhat.com/show_bug.cgi?id=355291

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From halfline at gmail.com  Sun Nov  4 18:24:14 2007
From: halfline at gmail.com (Ray Strode)
Date: Sun, 4 Nov 2007 13:24:14 -0500
Subject: virt-manager
In-Reply-To: <20071104171427.GB4103@redhat.com>
References: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
	<45abe7d80711040854g1632533bh199a1b91a0775a1e@mail.gmail.com>
	<20071104171427.GB4103@redhat.com>
Message-ID: <45abe7d80711041024r45b75e26q47b45595afa6dae6@mail.gmail.com>

Hi,


> It shouldn't be neccessary to explicitly connect to the local machine - if
> you have no existing host connections remembered in gconf, it will try to
> automatically add a connection to the local Xen or KVM instance.  Yes, the
> 'new VM' icon has proved to be a little too subtle for many people, so
> we'll likely revise that bit of UI to make it more obvious in an update.
I don't think it did for me, but it's been a couple of days, so I may
be misremembering.

--Ray



From chris.stone at gmail.com  Sun Nov  4 19:02:07 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 4 Nov 2007 12:02:07 -0700
Subject: Doxygen and multilib
In-Reply-To: <4728B575.40300@redhat.com>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
Message-ID: <d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>

On 10/31/07, Eric Sandeen <sandeen at redhat.com> wrote:
> Linus Walleij wrote:
> > OK so I have that problem where Doxygen generates links as hashes
> > including something like a time stamp, so the -devel packages end up
> > causing multilib conflicts.
> >
> > Is there some silver bullet to actually SOLVE this?
> >
> > I saw that Hans solved this by tar.gz:ing up the docs and add as separate
> > source and then suppress compile-time building of the docs, replacing with
> > pre-generated contents.
> >
> > Myself I simply deleted the docs for now.
> >
> > I sort of believe Doxygen should be fixed to do something more
> > predictable, atleast on request.
>
> I'd like to see that too - I took a quick look at how it generates the
> hashes, and couldn't find it.  :)  But if it could be seeded with some
> predictable thing based on what it's parsing, maybe it could be made
> consistent?

doxygen is using its own home brewed md5 hash generator in the libmd5/
directory.  This code gets called from the MemberDef::setAnchor()
function in src/memberdef.cpp

My guess is that doxygen's libmd5 code does not work correctly on
64bit systems.  Perhaps doxygen should be enhanced to use the
coreutils md5 algorithm or mhash or something.



From chris.stone at gmail.com  Sun Nov  4 19:37:53 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 4 Nov 2007 12:37:53 -0700
Subject: Doxygen and multilib
In-Reply-To: <d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
	<d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
Message-ID: <d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>

On 11/4/07, Christopher Stone <chris.stone at gmail.com> wrote:
> On 10/31/07, Eric Sandeen <sandeen at redhat.com> wrote:
> > Linus Walleij wrote:
> > > OK so I have that problem where Doxygen generates links as hashes
> > > including something like a time stamp, so the -devel packages end up
> > > causing multilib conflicts.
> > >
> > > Is there some silver bullet to actually SOLVE this?
> > >
> > > I saw that Hans solved this by tar.gz:ing up the docs and add as separate
> > > source and then suppress compile-time building of the docs, replacing with
> > > pre-generated contents.
> > >
> > > Myself I simply deleted the docs for now.
> > >
> > > I sort of believe Doxygen should be fixed to do something more
> > > predictable, atleast on request.
> >
> > I'd like to see that too - I took a quick look at how it generates the
> > hashes, and couldn't find it.  :)  But if it could be seeded with some
> > predictable thing based on what it's parsing, maybe it could be made
> > consistent?
>
> doxygen is using its own home brewed md5 hash generator in the libmd5/
> directory.  This code gets called from the MemberDef::setAnchor()
> function in src/memberdef.cpp
>
> My guess is that doxygen's libmd5 code does not work correctly on
> 64bit systems.  Perhaps doxygen should be enhanced to use the
> coreutils md5 algorithm or mhash or something.
>

Okay, I think I found the bug.  md5lib/md5_loc.h does not appear to
look correct when compiled on a system with 64bit integers.

This might be a quick fix, but I think ideally doxygen should use some
system wide library for computing md5 hashes.

It also appears doxygen uses its own version of libpng.

I think also the doxygen spec file should BR graphviz.  The configure
script checks for the location of dot.



From valent.turkovic at gmail.com  Sun Nov  4 20:08:15 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Sun, 4 Nov 2007 21:08:15 +0100
Subject: Most obvious Fedora 8 bugs
Message-ID: <64b14b300711041208j393e7c92u71b1a048b7b0d5@mail.gmail.com>

I didn't manage to test it before but not that I have tested Fedora 8
RC3 here are the most obvious bugs I came across:

https://bugzilla.redhat.com/show_bug.cgi?id=366001 - PulseAudio
distorts audio (over amplification)

https://bugzilla.redhat.com/show_bug.cgi?id=366041 - anaconda manual
partition weridness

https://bugzilla.redhat.com/show_bug.cgi?id=355291 - RFE: Allow
fluendo codecs to work with SELinux enabled

https://bugzilla.redhat.com/show_bug.cgi?id=236881 - Firefox doesn't
install Flash plugin when it is needed and absent

These bugs are the ones that most average desktop users are going to
notice. The most obvious is the audio distortion bug because
everything sounds just terrible! :(

On more positive side I must admit I'm impressed with performance of
wireless and suspend on few laptops I have tested fedora 8 RC3 - it
JustWorks(tm) :)

Hope this helps,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From chris.stone at gmail.com  Sun Nov  4 20:26:50 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 4 Nov 2007 13:26:50 -0700
Subject: Doxygen and multilib
In-Reply-To: <d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
	<d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
	<d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>
Message-ID: <d9c612bf0711041226p339a189ex46b19067422a02a9@mail.gmail.com>

On 11/4/07, Christopher Stone <chris.stone at gmail.com> wrote:
> On 11/4/07, Christopher Stone <chris.stone at gmail.com> wrote:
> > On 10/31/07, Eric Sandeen <sandeen at redhat.com> wrote:
> > > Linus Walleij wrote:
> > > > OK so I have that problem where Doxygen generates links as hashes
> > > > including something like a time stamp, so the -devel packages end up
> > > > causing multilib conflicts.
> > > >
> > > > Is there some silver bullet to actually SOLVE this?
> > > >
> > > > I saw that Hans solved this by tar.gz:ing up the docs and add as separate
> > > > source and then suppress compile-time building of the docs, replacing with
> > > > pre-generated contents.
> > > >
> > > > Myself I simply deleted the docs for now.
> > > >
> > > > I sort of believe Doxygen should be fixed to do something more
> > > > predictable, atleast on request.
> > >
> > > I'd like to see that too - I took a quick look at how it generates the
> > > hashes, and couldn't find it.  :)  But if it could be seeded with some
> > > predictable thing based on what it's parsing, maybe it could be made
> > > consistent?
> >
> > doxygen is using its own home brewed md5 hash generator in the libmd5/
> > directory.  This code gets called from the MemberDef::setAnchor()
> > function in src/memberdef.cpp
> >
> > My guess is that doxygen's libmd5 code does not work correctly on
> > 64bit systems.  Perhaps doxygen should be enhanced to use the
> > coreutils md5 algorithm or mhash or something.
> >
>
> Okay, I think I found the bug.  md5lib/md5_loc.h does not appear to
> look correct when compiled on a system with 64bit integers.
>
> This might be a quick fix, but I think ideally doxygen should use some
> system wide library for computing md5 hashes.
>
> It also appears doxygen uses its own version of libpng.
>
> I think also the doxygen spec file should BR graphviz.  The configure
> script checks for the location of dot.
>

gah, actually it appears ints are 32bits on 64bit systems, so this
file is probably correct.

Unrelated, but this looks wrong in the pilot-link-devel package:
pi-md5.h:#define UINT32 unsigned long



From chris.stone at gmail.com  Sun Nov  4 23:23:14 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Sun, 4 Nov 2007 16:23:14 -0700
Subject: Doxygen and multilib
In-Reply-To: <d9c612bf0711041226p339a189ex46b19067422a02a9@mail.gmail.com>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
	<d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
	<d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>
	<d9c612bf0711041226p339a189ex46b19067422a02a9@mail.gmail.com>
Message-ID: <d9c612bf0711041523u17a6b72csaf79334053e0339a@mail.gmail.com>

After more investigation, I found out this bug is already fix in
doxygen-1.5.3.  Than never pushed the new release, rawhide is still
using 1.5.2.



From triad at df.lth.se  Sun Nov  4 23:27:26 2007
From: triad at df.lth.se (Linus Walleij)
Date: Mon, 5 Nov 2007 00:27:26 +0100 (CET)
Subject: Doxygen and multilib
In-Reply-To: <d9c612bf0711041523u17a6b72csaf79334053e0339a@mail.gmail.com>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
	<d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
	<d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>
	<d9c612bf0711041226p339a189ex46b19067422a02a9@mail.gmail.com>
	<d9c612bf0711041523u17a6b72csaf79334053e0339a@mail.gmail.com>
Message-ID: <Pine.GSO.4.60.0711050025260.8239@igloo.df.lth.se>

On Sun, 4 Nov 2007, Christopher Stone wrote:

> After more investigation, I found out this bug is already fix in
> doxygen-1.5.3.  Than never pushed the new release, rawhide is still
> using 1.5.2.

Hm, hm, looks like that bug will then just go away shortly.

Linus



From mcepl at redhat.com  Sun Nov  4 23:32:40 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 00:32:40 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <loom.20071030T224723-163@post.gmane.org>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030! 5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
Message-ID: <slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>

On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
> I have suggested at least 2 technical solutions, none of which 
> needs any changes to Anaconda:

May add one more possible solution: what about dropping Base 
X group from anaconda altogether and why not to treat it as 
a library, which is required by another components (do we have 
a group for glibc)?

By reading the most of the previous messages (and there was a lot 
of them), it seems to me that actually nobody wants ?Base X? 
group for its own sake. Either there are people who want ?Plain 
old X as seen in Project Athena many years ago? (BTW, Project 
Athena @ MIT switched to Gnome as default) or some lightweight 
window manager (which one?). IMHO, the answer to the first 
request is that whoever wants it is such a weirdo, that he should 
be required to install appropriate packages just via yum (maybe 
with package xorg-x11-plain-old-environment or something) and 
doesn't deserve a place in anaconda.

The other group is much more interesting. I really don't like 
a tendency of Fedora moving with its system requirements 
somewhere close to the one of Windows Vista (yes, we would have 
to fix anaconda first, but that's another issue, let's keep this 
X specific). It would be nice if people who are interested in 
this created some group of packages (with their own desktop 
manager? -- is there anything else than [gkx]dm?) so that we 
could fourth environment (even though this would be probably very 
virtual not consisting from packages originally intended to be 
part of one environment) besides Gnome, KDE, and XFCE. Are there 
any friends of WindowMaker around here (that would be nice for 
higher degree of compatibility with Mac OS X)? Or IceWM?

On xdm theme -- if anybody is interested in this; well, 
xorg-x11-xdm src.rpm is 400k -- it shouldn't be unfathomable for 
interested geek to fix it and maintain it (and I would be glad to 
meet you, because xdm bugs in bugzilla are always for me, desktop 
team bugmaster, kind of nightmare).

What do you think?

Mat?j



From bobhillegas at gmail.com  Mon Nov  5 00:13:51 2007
From: bobhillegas at gmail.com (Bob Hillegas)
Date: Sun, 4 Nov 2007 18:13:51 -0600
Subject: NFS problem after update to rpcbind-0.1.4.8.fc7
In-Reply-To: <9978803b0711041607k44bcc1c3k75c729ff92f8f36d@mail.gmail.com>
References: <9978803b0711040738m7b13d49bke8ceddb659f1bebb@mail.gmail.com>
	<9978803b0711041607k44bcc1c3k75c729ff92f8f36d@mail.gmail.com>
Message-ID: <9978803b0711041613l3ac6af75sa1cc0e06984e9765@mail.gmail.com>

The previous emails got the server so that nfs service is loading OK. but
still doesn't complete the mount that it did prior to rpcbind update.
This is the F7 server serving the directories...

[bobh at north ~]# uname -a
Linux north.rosestar.lan 2.6.23.1-10.fc7 #1 SMP Fri Oct 19 15:39:08 EDT 2007
i686 i686 i386 GNU/Linux
[ bobh at north ~]# rpm -q rpcbind nfs-utils
rpcbind-0.1.4-8.fc7
nfs-utils-1.1.0-4.fc7
[bobh at north ~]# cat /etc/hosts.*
 #
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
 portmap:        192.168.47., LOCAL
mountd:         192.168.47., LOCAL
rquotad:        192.168.47., LOCAL
lockd:          192.168.47., LOCAL
statd:          192.168.47., LOCAL
# --------------------------------------------------------------------------
ipop3d:         192.168.47., LOCAL
sshd:           192.168.47., LOCAL
# --------------------------------------------------------------------------
ALL:            127.0.0., localhost

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
ALL: ALL


This is the F6 workstation trying to mount a directory...
[bobh at south ~]$ uname -a
Linux south.rosestar.lan 2.6.22.9-61.fc6 #1 SMP Thu Sep 27 18:48:03 EDT 2007
i686 i686 i386 GNU/Linux
[ bobh at south ~]$ rpm -q rpcbind nfs-utils
package rpcbind is not installed
nfs-utils-1.0.10-14.fc6
[bobh at south ~]$ cat /etc/hosts.*
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
 # ------------------------------------------------------------------
lockd:          192.168.47., LOCAL
mountd:         192.168.47., LOCAL
portmap:        192.168.47., LOCAL
rquotad:        192.168.47., LOCAL
statd:          192.168.47., LOCAL
# ------------------------------------------------------------------
ALL:            127.0.0., localhost

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
# -------------------------------------------------------------------
ALL: ALL

[bobh at south ~]$ sudo mount /mnt/north/home/; echo $?
32

Didn't work

/var/log/messages from server on failed attempt.
Nov  4 18:06:14 north rpcbind: connect from 192.168.47.138 to
getport/addr(nfs): request from unauthorized host

What kind of authorization does it need?

Thanks, BobH

-- 
BobH
bobhillegas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071104/2f1b67c8/attachment.htm>

From bobhillegas at gmail.com  Mon Nov  5 00:30:31 2007
From: bobhillegas at gmail.com (Bob Hillegas)
Date: Sun, 4 Nov 2007 18:30:31 -0600
Subject: Fwd: NFS problem after update to rpcbind-0.1.4.8.fc7
In-Reply-To: <9978803b0711041607k44bcc1c3k75c729ff92f8f36d@mail.gmail.com>
References: <9978803b0711040738m7b13d49bke8ceddb659f1bebb@mail.gmail.com>
	<9978803b0711041607k44bcc1c3k75c729ff92f8f36d@mail.gmail.com>
Message-ID: <9978803b0711041630u5e20ce2bv56cd252c68b49467@mail.gmail.com>

One last change made it work! I added rpcbind: 192.168.47., LOCAL to my
server's /etc/hosts.allow. (See below updated files).

This is the F7 server serving the directories...
[bobh at north ~]# uname -a
Linux north.rosestar.lan 2.6.23.1-10.fc7 #1 SMP Fri Oct 19 15:39:08 EDT 2007
i686 i686 i386 GNU/Linux
[bobh at north ~]# rpm -q rpcbind nfs-utils
rpcbind-0.1.4-8.fc7
nfs-utils-1.1.0-4.fc7
[bobh at north ~]# cat /etc/hosts.*
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
portmap:        192.168.47., LOCAL
mountd:         192.168.47., LOCAL
rquotad:        192.168.47., LOCAL
lockd:          192.168.47., LOCAL
statd:          192.168.47., LOCAL
rpcbind:        192.168.47., LOCAL
# --------------------------------------------------------------------------
ipop3d:         192.168.47., LOCAL
sshd:           192.168.47., LOCAL
# --------------------------------------------------------------------------
ALL:            127.0.0., localhost

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
ALL: ALL


This is the F6 workstation trying to mount a directory...
[bobh at south ~]$ uname -a
Linux south.rosestar.lan 2.6.22.9-61.fc6 #1 SMP Thu Sep 27 18:48:03 EDT 2007
i686 i686 i386 GNU/Linux
[bobh at south ~]$ rpm -q rpcbind nfs-utils
package rpcbind is not installed
nfs-utils-1.0.10-14.fc6
[bobh at south ~]$ cat /etc/hosts.*
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# ------------------------------------------------------------------
lockd:          192.168.47., LOCAL
mountd:         192.168.47., LOCAL
portmap:        192.168.47., LOCAL
rquotad:        192.168.47., LOCAL
statd:          192.168.47., LOCAL
# ------------------------------------------------------------------
ALL:            127.0.0., localhost

#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
# -------------------------------------------------------------------
ALL: ALL

[bobh at south ~]$ sudo mount /mnt/north/home/; echo $?
0

Now it works!! Thanks for your assistance and patience. this posting is for
the archive.
Thanks, BobH

-- 
BobH
bobhillegas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071104/07afcf72/attachment.htm>

From pertusus at free.fr  Mon Nov  5 01:02:39 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 02:02:39 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
References: <4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
Message-ID: <20071105010239.GA3632@free.fr>

On Mon, Nov 05, 2007 at 12:32:40AM +0100, Matej Cepl wrote:
> On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
> > I have suggested at least 2 technical solutions, none of which 
> > needs any changes to Anaconda:
> 
> part of one environment) besides Gnome, KDE, and XFCE. Are there 
> any friends of WindowMaker around here (that would be nice for 
> higher degree of compatibility with Mac OS X)? Or IceWM?

I am a small desktop user. For the display managers, there are wdm, 
xdm and slim (but they lack integration with consolekit). For the 
desktop (in fact window managers), fvwm, fluxbox, icewm, WindowMaker 
pekwm and other I forgot about. Among the file managers, there is 
gentoo (although it should be better inegrated with xdg-open use), 
and rox-filer could be packaged (I have a spec). I wanted 
to package ivman for automounting, but it turned out to have too 
much issues. I have developped halevt to replace ivman, but so far 
nobody has packaged it (I don't want to maintain it in fedora since 
I am upstream). There are many dockaps packaged, but more wouldn't 
hurt. For openoffice, I haven't seen obvious replacements (I tried 
to package Ted, but it is a nightmare). To replace firefox, there 
is dillo, but it lacks functionalities, more promising is links-hacked 
(I have a spec) or maybe links2. Last xpdf/gv are much lighter than 
evince.

So there are many pieces in place, but still some lacking parts or 
missing features. In any case, I don't think that a comps group would be
useful for 3 reasons:
* there is a lot of diversity, 
* this sets of packages are more geared toward power users, 
* minimal usable set is very small (a display manager, a window manager) 

> On xdm theme -- if anybody is interested in this; well, 
> xorg-x11-xdm src.rpm is 400k -- it shouldn't be unfathomable for 
> interested geek to fix it and maintain it (and I would be glad to 
> meet you, because xdm bugs in bugzilla are always for me, desktop 
> team bugmaster, kind of nightmare).
> 
> What do you think?

I could look at the packaging part (in some future, though), but not at 
the code.

--
Pat



From jkeating at redhat.com  Mon Nov  5 01:59:44 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 4 Nov 2007 20:59:44 -0500
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<4728C284.405030! 5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
Message-ID: <20071104205944.62f906e7@redhat.com>

On Mon, 05 Nov 2007 00:32:40 +0100
Matej Cepl <mcepl at redhat.com> wrote:

> May add one more possible solution: what about dropping Base 
> X group from anaconda altogether and why not to treat it as 
> a library, which is required by another components (do we have 
> a group for glibc)?

You can get the X libraries and not have an X server.  You can do an
install with gnome/kde that is set up to be used remotely on other X
servers, without actually installing a local X server.  The Base X
group is the group that adds a local X server (and all the appropriate
fonts/drivers/etc...) so that X can be used locally on the system.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071104/41d4b322/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov  5 02:01:20 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 05 Nov 2007 07:31:20 +0530
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <20071105010239.GA3632@free.fr>
References: <4727EFF2.6050505@fedoraproject.org>	<1193799897.11243.24.camel@localhost.localdomain>	<4727F17D.2090305@fedoraproject.org>
	<4728A579.4040901@redhat.com>	<4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com>	<4728B36C.4060403@fedoraproject.org>
	<4728C284.405030!5@redhat.com>	<loom.20071031T182928-261@post.gmane.org>	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
Message-ID: <472E7970.4000701@fedoraproject.org>

Patrice Dumas wrote:
I have developped halevt to replace ivman, but so far
> nobody has packaged it (I don't want to maintain it in fedora since 
> I am upstream). 

I don't understand that logic. Why wouldn't you want to maintain it in 
Fedora just because you are upstream?

Rahul



From otto_rey at yahoo.com.ar  Mon Nov  5 04:24:06 2007
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Sun, 4 Nov 2007 20:24:06 -0800 (PST)
Subject: F8 Nvidia Ethernet Ip Problem
Message-ID: <747045.28141.qm@web52411.mail.re2.yahoo.com>

File a bug

----- Mensaje original ----
De: Casey Dahlin <cjdahlin at ncsu.edu>
Para: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Enviado: s?bado 3 de noviembre de 2007, 21:45:28
Asunto: Re: F8 Nvidia Ethernet Ip Problem

masch wrote:
> I'm trying to set up Fedora 8 RC3 and i can't set up my network
> device. I have nVidia MP55 ethernet and i'm can't get my ip from
 DHCP,
> i have dual boot with WinXp, Sorry :D , and it work well. I was using
> Fedora 7 and it's work too....
>
> Can anybody know what it's the probem??
>
> Salu2..
>
>   
I've had this issue too. MCP55 on an Asus Striker Extreme mobo. For me 
it only worked with the stock F7 kernel. Even yum updating to a more 
recent F7 broke it.

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list





      ____________________________________________________________________________________
Yahoo! Noticias
Todo lo que ten?s que saber sobre Elecciones Presidenciales 2007 encontralo en Yahoo! Noticias.
http://ar.news.yahoo.com/elecciones2007/



From cjdahlin at ncsu.edu  Mon Nov  5 05:17:45 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Mon, 05 Nov 2007 00:17:45 -0500
Subject: F8 Nvidia Ethernet Ip Problem
In-Reply-To: <747045.28141.qm@web52411.mail.re2.yahoo.com>
References: <747045.28141.qm@web52411.mail.re2.yahoo.com>
Message-ID: <472EA779.3080804@ncsu.edu>

Otto Rey wrote:
> File a bug
>   
This one seems to describe the symptoms:
https://bugzilla.redhat.com/show_bug.cgi?id=258661
> ----- Mensaje original ----
> De: Casey Dahlin <cjdahlin at ncsu.edu>
> Para: Development discussions related to Fedora <fedora-devel-list at redhat.com>
> Enviado: s?bado 3 de noviembre de 2007, 21:45:28
> Asunto: Re: F8 Nvidia Ethernet Ip Problem
>
> masch wrote:
>   
>> I'm trying to set up Fedora 8 RC3 and i can't set up my network
>> device. I have nVidia MP55 ethernet and i'm can't get my ip from
>>     
>  DHCP,
>   
>> i have dual boot with WinXp, Sorry :D , and it work well. I was using
>> Fedora 7 and it's work too....
>>
>> Can anybody know what it's the probem??
>>
>> Salu2..
>>
>>   
>>     
> I've had this issue too. MCP55 on an Asus Striker Extreme mobo. For me 
> it only worked with the stock F7 kernel. Even yum updating to a more 
> recent F7 broke it.
>
>   



From rc040203 at freenet.de  Mon Nov  5 07:14:32 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 05 Nov 2007 08:14:32 +0100
Subject: How to set %vendor in mock?
Message-ID: <1194246872.26832.7.camel@mccallum.corsepiu.local>

Hi,

in the past, I used to set up %vendor in mock by adding
...
config_opts['macros'] += '%vendor       VENDOR'
...
to customized mock *.cfgs.


This stopped working with FC7's recent upgrade to mock-0.8.x:

# mock --configdir=/foo/etc/mock -r fedora-7-i386-test init
INFO: mock suid wrapper version 0.8.4 
ERROR: unsupported operand type(s) for +=: 'dict' and 'str'
Traceback (most recent call last):
  File "/usr/libexec/mock.py", line 333, in <module>
    main(retParams)
  File "/usr/libexec/mock.py", line 249, in main
    execfile(cfg)
  File "/foo/etc/mock/fedora-7-i386-test.cfg", line 7, in <module>
    config_opts['macros'] += '%vendor   VENDOR'
TypeError: unsupported operand type(s) for +=: 'dict' and 'str'

Any ideas?

Ralf




From tmz at pobox.com  Mon Nov  5 07:24:17 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 5 Nov 2007 02:24:17 -0500
Subject: How to set %vendor in mock?
In-Reply-To: <1194246872.26832.7.camel@mccallum.corsepiu.local>
References: <1194246872.26832.7.camel@mccallum.corsepiu.local>
Message-ID: <20071105072417.GB2295@psilocybe.teonanacatl.org>

Ralf Corsepius wrote:
> Hi,
> 
> in the past, I used to set up %vendor in mock by adding
> ...
> config_opts['macros'] += '%vendor       VENDOR'
> ...
> to customized mock *.cfgs.
> 
> 
> This stopped working with FC7's recent upgrade to mock-0.8.x:
> 
> # mock --configdir=/foo/etc/mock -r fedora-7-i386-test init
> INFO: mock suid wrapper version 0.8.4 
> ERROR: unsupported operand type(s) for +=: 'dict' and 'str'
> Traceback (most recent call last):
>  File "/usr/libexec/mock.py", line 333, in <module>
>    main(retParams)
>  File "/usr/libexec/mock.py", line 249, in main
>    execfile(cfg)
>  File "/foo/etc/mock/fedora-7-i386-test.cfg", line 7, in <module>
>    config_opts['macros'] += '%vendor   VENDOR'
> TypeError: unsupported operand type(s) for +=: 'dict' and 'str'
> 
> Any ideas?

I haven't tested this, but I just updated mock today and was looking
at the changes in the defaults.cfg file.  The example given there is:

config_opts['macros']['Add_your_macro_name_here'] = "add macro value here"

So I'd guess that you want to try something like this:

config_opts['macros']['vendor'] = "VENDOR"

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Drugs may lead to nowhere, but at least it's the scenic route.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071105/db786f4a/attachment.sig>

From mcepl at redhat.com  Mon Nov  5 08:08:11 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 09:08:11 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <loom.20071030T224723-163@post.gmane.org>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071104205944.62f906e7@redhat.com>
Message-ID: <bkv205xquc.ln2@hubmaier.ceplovi.cz>

On Sun, 04 Nov 2007 20:59:44 -0500, Jesse Keating scripst:
> You can get the X libraries and not have an X server.  You can do an
> install with gnome/kde that is set up to be used remotely on other X
> servers, without actually installing a local X server.  The Base X group
> is the group that adds a local X server (and all the appropriate
> fonts/drivers/etc...) so that X can be used locally on the system.

And both of these are probably such corner cases, that I would gladly not 
bother 95% of all users of anaconda with them (causing confusion about 
xdm among other things). Whoever wants them, will have to fiddle with the 
configuration manually so much anyway, that one more 'yum install' 
probably won't hurt.

> Fedora -- All my bits are free, are yours?

Ehmm, although I suspect I know the answer, I cannot resist -- swfdec or 
gnash? ;-)

Mat?j



From rc040203 at freenet.de  Mon Nov  5 08:52:18 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 05 Nov 2007 09:52:18 +0100
Subject: How to set %vendor in mock?
In-Reply-To: <20071105072417.GB2295@psilocybe.teonanacatl.org>
References: <1194246872.26832.7.camel@mccallum.corsepiu.local>
	<20071105072417.GB2295@psilocybe.teonanacatl.org>
Message-ID: <1194252738.26832.23.camel@mccallum.corsepiu.local>

On Mon, 2007-11-05 at 02:24 -0500, Todd Zullinger wrote:
> Ralf Corsepius wrote:
> > Hi,
> > 
> > in the past, I used to set up %vendor in mock by adding
> > ...
> > config_opts['macros'] += '%vendor       VENDOR'
> > ...
> > to customized mock *.cfgs.
> > 
> > 
> > This stopped working with FC7's recent upgrade to mock-0.8.x:
> > 
> > # mock --configdir=/foo/etc/mock -r fedora-7-i386-test init
> > INFO: mock suid wrapper version 0.8.4 
> > ERROR: unsupported operand type(s) for +=: 'dict' and 'str'
> > Traceback (most recent call last):
> >  File "/usr/libexec/mock.py", line 333, in <module>
> >    main(retParams)
> >  File "/usr/libexec/mock.py", line 249, in main
> >    execfile(cfg)
> >  File "/foo/etc/mock/fedora-7-i386-test.cfg", line 7, in <module>
> >    config_opts['macros'] += '%vendor   VENDOR'
> > TypeError: unsupported operand type(s) for +=: 'dict' and 'str'
> > 
> > Any ideas?
> 
> I haven't tested this, but I just updated mock today and was looking
> at the changes in the defaults.cfg file.  The example given there is:
> 
> config_opts['macros']['Add_your_macro_name_here'] = "add macro value here"
> 
> So I'd guess that you want to try something like this:
> 
> config_opts['macros']['vendor'] = "VENDOR"

Thanks, using
config_opts['macros']['%vendor'] = "VENDOR"
in *.cfgs seems to do it on fc7.

Problem: This change seems incompatible to older mocks and is breaking
sharing *.cfg's with them:

(On a machine using an older mock)
...
Traceback (most recent call last):
  File "/usr/bin/mock", line 995, in ?
    main()
  File "/usr/bin/mock", line 951, in main
    execfile(cfg)
  File "/home/build/etc/mock//fedora-7-i386-test.cfg", line 7, in ?
    config_opts['macros']['%vendor'] = 'VENDOR'
TypeError: object does not support item assignment

Ralf






From mcepl at redhat.com  Mon Nov  5 09:08:59 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 10:08:59 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
Message-ID: <b63305xquc.ln2@hubmaier.ceplovi.cz>

On Mon, 05 Nov 2007 02:02:39 +0100, Patrice Dumas scripst:
> I am a small desktop user. For the display managers, there are wdm, xdm
> and slim (but they lack integration with consolekit).

davidz? How complicated is to fix that? Does {wdm,slim} use PAM?

> For the desktop
> (in fact window managers), fvwm, fluxbox, icewm, WindowMaker pekwm and
> other I forgot about.

I would suspect, that here is the answer -- just pick one (although 
WindowMaker means much more than just a window manager, I guess).

> (I don't want to maintain it in fedora since I am upstream).

As other people noted already, this in itself is not the reason. You may 
be swamped in other work too much anyway, so you won't bother with Fedora 
clueless users, but there are many upstream maintainers/authors who 
maintain their packages in Fedora as well.

> For openoffice, I haven't seen obvious replacements

I think, just don't go there -- although KOffice friends will hate me for 
saying this, if you need compatibility with MS Office or full-blown 
office suite, you need OO.o. Period. Others are just not there (yet?). 

And of course, when you say OO.o, don't say "lightweight" in the same 
sentence, or you will be laughed out. I guess that for now, people using 
your virtual DE will have to settle on Google Apps or something of that 
sort. I know, Google Apps are not free, but for now (until some free web 
apps will develop?), it is used I guess by people who don't use full-
blown office suite anyway.

> To replace
> firefox, there is dillo, but it lacks functionalities, more promising is
> links-hacked (I have a spec) or maybe links2.

Actually, I think firefox is probably bigger problem than Openoffice.org. 
If you want to use Google Apps as your "producitivty applicationis" (or 
whateever is the current buzzword for this kind of programs) then 
probably things like links are not good enough. Is there anything from 
http://en.wikipedia.org/wiki/List_of_web_browsers#Gecko-based_browsers or 
http://en.wikipedia.org/wiki/List_of_web_browsers#KHTML_and_WebKit-
based_browsers which would be useful for you? Just from browsing 
Wikipedia, Atlantis http://www.akcaagac.com/index_atlantis.html looks 
pretty nice. I don't know how good its Javascript/AJAX support is though.

> So there are many pieces in place, but still some lacking parts or
> missing features. In any case, I don't think that a comps group would be
> useful for 3 reasons:

Certainly not now, until dust settles a little bit on your ideas. But 
then it could be a good place to organize and coordinate the effort, and 
tool to promote and organize community developing the DE.

However, one more question came to my mind while thinking about this post 
-- "Why not XFCE"? We already have something marked as a lightweight 
environment. Why not to join their effort?

> * there is a lot of diversity,

that shouldn't be problem -- just follow your heart and be open to change 
the groups whenever you are persuaded that you made a mistake. It's 
better to have one real thing, than a mess lightweight environment is now.

> * this sets of packages are more geared toward power users,

And? Why only newbies should have a toolbox ready to use?

> * minimal usable set is very small (a display manager, a window manager)

I am not sure about it. You just have to look wider I suppose.

Best,

Mat?j



From rjones at redhat.com  Mon Nov  5 09:13:38 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 05 Nov 2007 09:13:38 +0000
Subject: virt-manager
In-Reply-To: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
References: <bfdeacfa0711040842r10c62d3w90f84f6b939bbae5@mail.gmail.com>
Message-ID: <472EDEC2.1080400@redhat.com>

Mark Bidewell wrote:
> I was looking at virt-manager in F8 and I notoced that it no longer
> seems to have gui install capability.  has this been removed
> intentionally or is this a bug?

This is a usability regression.  The button for installing used to be 
prominent but now has changed to a strange, small icon on the right hand 
side of the hypervisor title line.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071105/0a27ca8c/attachment.bin>

From pertusus at free.fr  Mon Nov  5 09:26:36 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 10:26:36 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <472E7970.4000701@fedoraproject.org>
References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<472E7970.4000701@fedoraproject.org>
Message-ID: <20071105092636.GA2841@free.fr>

On Mon, Nov 05, 2007 at 07:31:20AM +0530, Rahul Sundaram wrote:
> Patrice Dumas wrote:
> I have developped halevt to replace ivman, but so far
>> nobody has packaged it (I don't want to maintain it in fedora since I am 
>> upstream). 
>
> I don't understand that logic. Why wouldn't you want to maintain it in 
> Fedora just because you are upstream?

Because I think that being upstream and the primary maintainer of a
package in fedora (or any distro) is not a very good idea. If there are
conflict of interest between upstream and the distro (think about name
space, install paths, quality), I think that having a maintainer who is
not the primary upstream maintainer is a good thing. Having upstream
co-maintain, or even do the packaging work is a good idea, but I think
that upstream should not have the last saying for the package.

--
Pat



From mcepl at redhat.com  Mon Nov  5 09:44:05 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 10:44:05 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <4727F17D.2090305@fedoraproject.org>
	<4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<472E7970.4000701@fedoraproject.org> <20071105092636.GA2841@free.fr>
Message-ID: <585305xsp8.ln2@hubmaier.ceplovi.cz>

On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
> Because I think that being upstream and the primary maintainer of a
> package in fedora (or any distro) is not a very good idea. If there are
> conflict of interest between upstream and the distro (think about name
> space, install paths, quality), I think that having a maintainer who is
> not the primary upstream maintainer is a good thing. Having upstream
> co-maintain, or even do the packaging work is a good idea, but I think
> that upstream should not have the last saying for the package.

Well, I would be bothered with stuff like this for some huge packages 
(OOo), but I don't think (with all due respect to your utility) one 
reasonable guy should IMHO be able to keep two hats on his head. And you 
wouldn't be the first one (by far).

Mat?j



From pertusus at free.fr  Mon Nov  5 09:59:42 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 10:59:42 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <b63305xquc.ln2@hubmaier.ceplovi.cz>
References: <1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<b63305xquc.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071105095942.GB2841@free.fr>

On Mon, Nov 05, 2007 at 10:08:59AM +0100, Matej Cepl wrote:
> On Mon, 05 Nov 2007 02:02:39 +0100, Patrice Dumas scripst:
> > I am a small desktop user. For the display managers, there are wdm, xdm
> > and slim (but they lack integration with consolekit).
> 
> davidz? How complicated is to fix that? Does {wdm,slim} use PAM?

Yes they use pam. They just need to pass the right pam environment
variables to pam_ck_connector, but lately I have seen the following in
the consolekit changelog:
        * Add new helper for getting tty from DISPLAY (William Jon McCann)
so I was hoping everything could be automatic, I asked for an
explanation on the hal list, and directly to David, so far no answer.

> > For the desktop
> > (in fact window managers), fvwm, fluxbox, icewm, WindowMaker pekwm and
> > other I forgot about.
> 
> I would suspect, that here is the answer -- just pick one (although 
> WindowMaker means much more than just a window manager, I guess).

What else? 

> > (I don't want to maintain it in fedora since I am upstream).
> 
> As other people noted already, this in itself is not the reason. You may 
> be swamped in other work too much anyway, so you won't bother with Fedora 
> clueless users, but there are many upstream maintainers/authors who 
> maintain their packages in Fedora as well.

See my answer to Rahul for why I find it bad.

> > For openoffice, I haven't seen obvious replacements
> 
> I think, just don't go there -- although KOffice friends will hate me for 
> saying this, if you need compatibility with MS Office or full-blown 
> office suite, you need OO.o. Period. Others are just not there (yet?). 

I know.

> And of course, when you say OO.o, don't say "lightweight" in the same 
> sentence, or you will be laughed out. I guess that for now, people using 
> your virtual DE will have to settle on Google Apps or something of that 
> sort. I know, Google Apps are not free, but for now (until some free web 
> apps will develop?), it is used I guess by people who don't use full-
> blown office suite anyway.

I don't think that it is a real replacement. Since it is server-side you
have to have internet, trust the server... But indeed it can be of help.

> > To replace
> > firefox, there is dillo, but it lacks functionalities, more promising is
> > links-hacked (I have a spec) or maybe links2.
> 
> Actually, I think firefox is probably bigger problem than Openoffice.org. 
> If you want to use Google Apps as your "producitivty applicationis" (or 
> whateever is the current buzzword for this kind of programs) then 
> probably things like links are not good enough. Is there anything from 

Indeed. It may be for browsing with simple javascript (there is
currently no css suppport).

> http://en.wikipedia.org/wiki/List_of_web_browsers#Gecko-based_browsers or 
> http://en.wikipedia.org/wiki/List_of_web_browsers#KHTML_and_WebKit-
> based_browsers which would be useful for you? Just from browsing 
> Wikipedia, Atlantis http://www.akcaagac.com/index_atlantis.html looks 
> pretty nice. I don't know how good its Javascript/AJAX support is though.

Indeed, looks cool. Seems that WebCore has javascript support.

> > So there are many pieces in place, but still some lacking parts or
> > missing features. In any case, I don't think that a comps group would be
> > useful for 3 reasons:
> 
> Certainly not now, until dust settles a little bit on your ideas. But 
> then it could be a good place to organize and coordinate the effort, and 
> tool to promote and organize community developing the DE.

I don't think that dust will settle. The desktop is a moving target,
with kde/gnome/xfce ruling freedesktop and having resources put by 
vendors in these efforts (redhat is a good example of a company pushing 
the desktop innovations which also means breaking existing apps). So 
things change a lot (fonts, handling, hal/ConsoleKit, utf8), while there 
is no resources (that is paid developpers) put for light DE. I also 
think that light DE developers may be reluctant to add new features 
(only a guess, though). As a result light DE will always be catching up, 
with doing things as root needed, ugly workaround for things to work.
To put things clearly before somebody misinterpret my words, I am not
complaining about those breakages. But they happen a lot and big desktop
developpers don't care about compatibility with existing stuff or
helping light DE to have backward compatibility -- still not a
complaint, but a remark.

> However, one more question came to my mind while thinking about this post 
> -- "Why not XFCE"? We already have something marked as a lightweight 
> environment. Why not to join their effort?

I help with xfce packaging when I can (I reviewed thunar, for example,
and see ristretto review). And xfce related applications are light, in
general (thunar, for example is a lightweight file manager). I used xfce
in the past (fedora 3, maybe 4?) but then it became to take time to
launch, and then I switched to fluxbox.
 
> > * there is a lot of diversity,
> 
> that shouldn't be problem -- just follow your heart and be open to change 
> the groups whenever you are persuaded that you made a mistake. It's 
> better to have one real thing, than a mess lightweight environment is now.

Right.

> > * this sets of packages are more geared toward power users,
> 
> And? Why only newbies should have a toolbox ready to use?

Power usres knwo what to install and have precise choices, so a group
won't be of much use for them. It would be interesting for newbies who
want something light. But also a trap for them, they'll have to mount
manually their usb sticks as root by looking at the bottom of dmesg...

> > * minimal usable set is very small (a display manager, a window manager)
> 
> I am not sure about it. You just have to look wider I suppose.

Nothing more is necessary for lightweight DE. Of course there are lots
of apps that can be optional but are suited for lightweight DE
(dockapps, gmrun, xdvi, xfig, conky, gv and many others...).

--
Pat



From mtasaka at ioa.s.u-tokyo.ac.jp  Mon Nov  5 09:59:52 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Mon, 05 Nov 2007 18:59:52 +0900
Subject: rpms/blt/devel blt.spec,1.14,1.15
In-Reply-To: <200711050916.lA59Gj2E003781@cvs-int.fedora.redhat.com>
References: <200711050916.lA59Gj2E003781@cvs-int.fedora.redhat.com>
Message-ID: <472EE998.5050706@ioa.s.u-tokyo.ac.jp>

Sergio Pascual (sergiopr) wrote, at 11/05/2007 06:16 PM +9:00:
> Author: sergiopr
> 
> Modified Files:
> 	blt.spec 
> Log Message:
> * Mon Nov 05 2007 Sergio Pascual <sergiopr at fedoraproject.org> 2.4-18
> - Providing file in /etc/ld.so.conf.d (bug #333081)
> 
> 
> 
> Index: blt.spec
> ===================================================================
> RCS file: /cvs/pkgs/rpms/blt/devel/blt.spec,v
> retrieving revision 1.14
> retrieving revision 1.15
> diff -u -r1.14 -r1.15
> --- blt.spec	23 Oct 2007 09:42:53 -0000	1.14
> +++ blt.spec	5 Nov 2007 09:16:10 -0000	1.15
> @@ -58,13 +58,21 @@
>  echo 'package ifneeded BLT 2.4 "if {[llength [info commands tk]] > 0} {load [file join $dir libBLT24.so]} else {load [file join $dir libBLTlite24.so] BLT}"' > $DIRECTORY/pkgIndex.tcl
>  cp -p -r library/dd_protocols $DIRECTORY
>  rm -f html/Makefile.vc
> +# File in /etc/ld.so.conf.d
> +mkdir -p $RPM_BUILD_ROOT/%{_sysconfdir}/ld.so.conf.d
> +echo "%{_libdir}/blt2.4" >> $RPM_BUILD_ROOT/%{_sysconfdir}/ld.so.conf.d/ds9-%{_arch}.conf
>  

Why is this ld.so.conf.d file named as ds9-%_arch.conf?

Regards,
Mamoru



From mcepl at redhat.com  Mon Nov  5 09:45:14 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 10:45:14 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <4727F17D.2090305@fedoraproject.org>
	<4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<472E7970.4000701@fedoraproject.org> <20071105092636.GA2841@free.fr>
Message-ID: <aa5305xsp8.ln2@hubmaier.ceplovi.cz>

On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
> Because I think that being upstream and the primary maintainer of a
> package in fedora (or any distro) is not a very good idea.

Moreover, you hope that your utility will be used by other distros, 
right? Then you will get peer review and feedback from your package 
maintaining colleagues.

Mat?j



From pertusus at free.fr  Mon Nov  5 10:02:16 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 11:02:16 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <585305xsp8.ln2@hubmaier.ceplovi.cz>
References: <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<472E7970.4000701@fedoraproject.org>
	<20071105092636.GA2841@free.fr>
	<585305xsp8.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071105100216.GC2841@free.fr>

On Mon, Nov 05, 2007 at 10:44:05AM +0100, Matej Cepl wrote:
> On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
> > Because I think that being upstream and the primary maintainer of a
> > package in fedora (or any distro) is not a very good idea. If there are
> > conflict of interest between upstream and the distro (think about name
> > space, install paths, quality), I think that having a maintainer who is
> > not the primary upstream maintainer is a good thing. Having upstream
> > co-maintain, or even do the packaging work is a good idea, but I think
> > that upstream should not have the last saying for the package.
> 
> Well, I would be bothered with stuff like this for some huge packages 
> (OOo), but I don't think (with all due respect to your utility) one 
> reasonable guy should IMHO be able to keep two hats on his head. And you 
> wouldn't be the first one (by far).

I have seen a lot of reviews where this issue shows up, upstream being
willing to put an app in fedora, but not for fedora, in order to gain a
wider audience. Those conflicts were easily seen. I don't want to be in
that situation. If my app is good enough somebody else will package it
(and I will gladly review it).

--
Pat



From pertusus at free.fr  Mon Nov  5 10:07:24 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 11:07:24 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <aa5305xsp8.ln2@hubmaier.ceplovi.cz>
References: <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<472E7970.4000701@fedoraproject.org>
	<20071105092636.GA2841@free.fr>
	<aa5305xsp8.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071105100724.GD2841@free.fr>

On Mon, Nov 05, 2007 at 10:45:14AM +0100, Matej Cepl wrote:
> On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
> > Because I think that being upstream and the primary maintainer of a
> > package in fedora (or any distro) is not a very good idea.
> 
> Moreover, you hope that your utility will be used by other distros, 
> right? Then you will get peer review and feedback from your package 
> maintaining colleagues.

Not if they don't contact me, and this doesn't change the issue. Conflict 
of interest are better ruled if the last word is for the distro. And so 
far halevt is not in any distro (that I know of). It was proposed to 
debian but the submitter withdrawed his submission.

I have seen signs that show that a few people (at least 2) use it.

--
Pat



From buildsys at redhat.com  Mon Nov  5 10:49:54 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 5 Nov 2007 05:49:54 -0500
Subject: rawhide report: 20071105 changes
Message-ID: <200711051049.lA5Ansug032618@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From rjones at redhat.com  Mon Nov  5 11:45:05 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 05 Nov 2007 11:45:05 +0000
Subject: Fedora policy on setting up a SIG mailing list?
Message-ID: <472F0241.6010609@redhat.com>

Over in the diaspora of OCaml users we thought it might be an idea to 
have a Fedora-ocaml mailing list to discuss various issues.

Is there a policy on Fedora mailing lists?  The nearest I could find was 
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines/ConfiguringLists 
but that doesn't cover the issue of setting up a Fedora mailing list.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071105/9deaa6c8/attachment.bin>

From mcepl at redhat.com  Mon Nov  5 12:03:54 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 13:03:54 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<b63305xquc.ln2@hubmaier.ceplovi.cz> <20071105095942.GB2841@free.fr>
Message-ID: <slrnfiu1la.g32.mcepl@hubmaier.ceplovi.cz>

On 2007-11-05, 09:59 GMT, Patrice Dumas wrote:
>> Atlantis http://www.akcaagac.com/index_atlantis.html looks 
>> pretty nice.  I don't know how good its Javascript/AJAX 
>> support is though.
>
> Indeed, looks cool. Seems that WebCore has javascript support.

It seems like being non-free research/education project. I wonder 
if maintainer could be persuaded to relicense under some open 
source license when somebody from big distr would take an 
interest.

Mat?j



From mcepl at redhat.com  Mon Nov  5 12:01:13 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 13:01:13 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<b63305xquc.ln2@hubmaier.ceplovi.cz> <20071105095942.GB2841@free.fr>
Message-ID: <slrnfiu1g9.ei8.mcepl@hubmaier.ceplovi.cz>

On 2007-11-05, 09:59 GMT, Patrice Dumas wrote:
>> I would suspect, that here is the answer -- just pick one 
>> (although WindowMaker means much more than just a window 
>> manager, I guess).
>
> What else? 

Well, it's confusing (at least for me) to distinguish between 
WindowMaker and GNUStep -- at least in Debian (which I used 
before coming to RedHat) WM tend to develop a list of wm-* 
packages almost as long as g* and k* packages. I am not sure 
which one of them would qualify as parts of GNUStep and which 
ones are just addons on WM, but there are plenty of them all over 
the place.

> Indeed, looks cool. Seems that WebCore has javascript support.

Sure it has -- and konqueror (using KJS which is what WebCore JS 
support is based upon) works with GMail, AFAIK.

> I don't think that dust will settle. The desktop is a moving 
> target, with kde/gnome/xfce ruling freedesktop and having 
> resources put by vendors in these efforts (redhat is a good 
> example of a company pushing the desktop innovations which also 
> means breaking existing apps).

Well, then probably point is to keep the list packages in DE just 
as long as you and people who will be on it with you will be able 
to maintain.  Moreover, it seems to me that (under the influence 
of server guys, I think) many core changes in Fedora (thinking 
pulseaudio, policykit, packagekit, and hopefully now even 
NetworkManager) will be much more open to non-{Gnome,KDE} 
environments.

> I used xfce in the past (fedora 3, maybe 4?) but then it became 
> to take time to launch, and then I switched to fluxbox.

Jus to make sure, that I understand -- you claim, that XFCE is 
not as lightweight as it used to be, or in other words, that 
their effort to build lightweight equivalent of Gnome failed?

>> > * minimal usable set is very small (a display manager, 
>> > a window manager)
>> 
>> I am not sure about it. You just have to look wider I suppose.
>
> Nothing more is necessary for lightweight DE. Of course there are lots
> of apps that can be optional but are suited for lightweight DE
> (dockapps, gmrun, xdvi, xfig, conky, gv and many others...).

I don't know -- would you allow some email client, for example (I 
heard a lot of good things about Sylpheed in this respect) or do 
you expect most of the apps to be console ones running in 
xterm/rxvt/whatever?

Mat?j



From gilboad at gmail.com  Mon Nov  5 12:21:02 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 05 Nov 2007 14:21:02 +0200
Subject: The KDE-SIG needs (your) help
In-Reply-To: <200710292315.23149.ml@deadbabylon.de>
References: <200710292315.23149.ml@deadbabylon.de>
Message-ID: <1194265262.12341.11.camel@gilboa-work-dev.localdomain>

On Mon, 2007-10-29 at 23:15 +0100, Sebastian Vahl wrote:
> This is a request for participation:
> The KDE-SIG [1] is atm lacking active contributors. And we really need some 
> help in doing our job to provide a good KDE version in Fedora - especially 
> with the upcoming KDE 4.0 and the inclusion in Fedora 9.
> 
> If you don't know how you could help us here is a list (which is also in the 
> wiki):
> 
> * Packagers: There are so many interesting packages that are not yet packaged 
> for Fedora. Package it to improve the user experience. 
> 

I intended to help more with F8... but failed miserably.
Hopefully I'll be able to free more time on F9.

> * Reviewers: Only a few persons are doing the kde-related reviews. Help us 
> reviewing so that more packages could be included. 
> 
> * Testers: If you love KDE use the development version or the updates-testing 
> repository and report bugs, bugs, bugs, request enhancements or features. We 
> need your feedback to improve KDE. 

I assume that KDE4's staging ground will be kde-redhat, right?

- Gilboa



From abo at kth.se  Mon Nov  5 12:21:32 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Mon, 05 Nov 2007 13:21:32 +0100
Subject: Package XYZ is not signed
In-Reply-To: <1193768704.6165.7.camel@sb-home>
References: <47324ed80710251748v2860b0d7j5f5cca06890ce8@mail.gmail.com>
	<1193367084.5910.2.camel@localhost.localdomain>
	<1193592127.7011.4.camel@sb-home>  <4724F3B9.4010608@lordmorgul.net>
	<1193768704.6165.7.camel@sb-home>
Message-ID: <1194265292.2123.31.camel@home.alexander.bostrom.net>

tis 2007-10-30 klockan 19:25 +0100 skrev nodata:

> It worries me massively, from a security perspective, that someone from
> inside Red Hat would say something as wrong as this. 

Trusting the network is sadly quite common. That sort of thinking is
something we in the Unix and free software world need to get rid of
right now if we want to keep telling people we have the most secure
systems.

I'd much rather trust "packages signed with the rawhide auto-sign key"
than "packages which the internet sends you when you ask for rawhide
bits".

/abo



From pertusus at free.fr  Mon Nov  5 12:49:36 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 13:49:36 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfiu1g9.ei8.mcepl@hubmaier.ceplovi.cz>
References: <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<b63305xquc.ln2@hubmaier.ceplovi.cz>
	<20071105095942.GB2841@free.fr>
	<slrnfiu1g9.ei8.mcepl@hubmaier.ceplovi.cz>
Message-ID: <20071105124936.GC2635@free.fr>

On Mon, Nov 05, 2007 at 01:01:13PM +0100, Matej Cepl wrote:
> On 2007-11-05, 09:59 GMT, Patrice Dumas wrote:
> 
> Well, it's confusing (at least for me) to distinguish between 
> WindowMaker and GNUStep -- at least in Debian (which I used 
> before coming to RedHat) WM tend to develop a list of wm-* 
> packages almost as long as g* and k* packages. I am not sure 

Ok, I don't know about that. Maybe a relevant comps group could be
something like gnustep desktop.

> > I don't think that dust will settle. The desktop is a moving 
> > target, with kde/gnome/xfce ruling freedesktop and having 
> > resources put by vendors in these efforts (redhat is a good 
> > example of a company pushing the desktop innovations which also 
> > means breaking existing apps).
> 
> Well, then probably point is to keep the list packages in DE just 
> as long as you and people who will be on it with you will be able 
> to maintain.  Moreover, it seems to me that (under the influence 
> of server guys, I think) many core changes in Fedora (thinking 
> pulseaudio, policykit, packagekit, and hopefully now even 
> NetworkManager) will be much more open to non-{Gnome,KDE} 
> environments.

I hope that too, but currently this is not the trend I am seeing. That
is the server/light DE will catch up, but then there will be a newer
breaking. 

> > I used xfce in the past (fedora 3, maybe 4?) but then it became 
> > to take time to launch, and then I switched to fluxbox.
> 
> Jus to make sure, that I understand -- you claim, that XFCE is 
> not as lightweight as it used to be, or in other words, that 
> their effort to build lightweight equivalent of Gnome failed?

It is much lighter than gnome, but heavier than fluxbox.

> > Nothing more is necessary for lightweight DE. Of course there are lots
> > of apps that can be optional but are suited for lightweight DE
> > (dockapps, gmrun, xdvi, xfig, conky, gv and many others...).
> 
> I don't know -- would you allow some email client, for example (I 
> heard a lot of good things about Sylpheed in this respect) or do 
> you expect most of the apps to be console ones running in 
> xterm/rxvt/whatever?

sylpheed seems to have a good record, but I personally use mutt.

Maybe what could be more interesting than a comps group which doesn't
seems to fit very well in my opinion, because of the diversity and
optionality, a spin with the most used light apps could be done. I dream
of that since a lot of time, but I don't think it is worth it as long as
the integration isn't good enough. Moreover I am not persuaded that it
would be useful, even though it should be fun.

--
Pat



From limb at jcomserv.net  Mon Nov  5 13:08:36 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 5 Nov 2007 07:08:36 -0600 (CST)
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <585305xsp8.ln2@hubmaier.ceplovi.cz>
References: <4727F17D.2090305@fedoraproject.org>
	<4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org>
	<4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr> <472E7970.4000701@fedoraproject.org>
	<20071105092636.GA2841@free.fr> <585305xsp8.ln2@hubmaier.ceplovi.cz>
Message-ID: <38058.63.85.68.164.1194268116.squirrel@mail.jcomserv.net>


> On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
>> Because I think that being upstream and the primary maintainer of a
>> package in fedora (or any distro) is not a very good idea. If there are
>> conflict of interest between upstream and the distro (think about name
>> space, install paths, quality), I think that having a maintainer who is
>> not the primary upstream maintainer is a good thing. Having upstream
>> co-maintain, or even do the packaging work is a good idea, but I think
>> that upstream should not have the last saying for the package.
>
> Well, I would be bothered with stuff like this for some huge packages
> (OOo), but I don't think (with all due respect to your utility) one
> reasonable guy should IMHO be able to keep two hats on his head. And you
> wouldn't be the first one (by far).

I maintain two (I think) packages for which I am upstream.  I suspect I
wasn't the first, either.

> Mat??j
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From jdennis at redhat.com  Mon Nov  5 13:52:20 2007
From: jdennis at redhat.com (John Dennis)
Date: Mon, 05 Nov 2007 08:52:20 -0500
Subject: rpmbuild stops with debugedit error on F8
In-Reply-To: <20071103233034.7F16D4D04C0@magilla.localdomain>
References: <472CD39C.4050206@redhat.com>	<20071103221854.B0B4B4D04C0@magilla.localdomain>	<472CFE9C.10506@redhat.com>
	<20071103233034.7F16D4D04C0@magilla.localdomain>
Message-ID: <472F2014.4080002@redhat.com>

Roland McGrath wrote:
> Ok, it's simply as it says.  /rpmbuild/build is 15 chars and /usr/src/debug
> is 14 chars.  That's just a bad choice for the directory name.  In koji
> builds go under /builddir/build/BUILD (21 chars), so there is no problem.
> The default for vanilla rpmbuild is /usr/src/redhat/BUILD (21 chars).
> 
> It's a technical limitation of the debugedit program that, like the error
> message says, the length of the top build directory name has to be 14 chars
> (to match /usr/src/debug), or more than 15 chars.  It does a very limited
> kind of rewriting of the very complex DWARF formats, so there has to be
> enough room in the existing string table for the new directory name.
> Making it able to cope in the general case opens huge cans of worms, and is
> absolutely not going to happen any time soon (or ever in that program as it
> exists today).
> 
> Suffice it to say it is far, far more work than is justified to avoid the
> arcane but trivial caveat that the base directory name used for builds must
> be at least 16 chars long.

Thank you very much Roland, I really appreciate the explanation! I would 
have been really stuck without it.

The only thing I might take issue with is your belief the error message 
is patently obvious. There is no reference to the top build directory or 
the requirements for it's length. Just something cryptic about 1 
character differentials in arguments passed to what is essentially a 
private rpm utility unlikely to ever be invoked directly.

May I suggest the error message be replaced with something which would 
direct a developer to the root cause of the problem, especially since 
this is a somewhat arcane limitation.

This is what rpmbuild spits out:

extracting debug info from 
/var/tmp/freeradius-1.1.7-3.2.ipa.fc8-root-jdennis/usr/lib/rlm_passwd-1.1.7.so
/usr/lib/rpm/debugedit: -b arg has to be either the same length as -d 
arg, or more than 1 char shorter
error: Bad exit status from /var/tmp/rpm-tmp.74023 (%install)

I truly would never have matched the fact a build directory of 
"/rpmbuild/build" was the offending culprit, the string does not even 
appear in the error message.

Maybe rpmbuild should stop immediately with an error if you invoke it 
with a topdir which is unacceptable to it's internal operation.

Filed as bug: https://bugzilla.redhat.com/show_bug.cgi?id=366781

-- 
John Dennis <jdennis at redhat.com>



From mark.bidewell at alumni.clemson.edu  Mon Nov  5 14:24:34 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Mon, 5 Nov 2007 09:24:34 -0500
Subject: Repo Suggestion
Message-ID: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>

Last week I tried moving to updates-testing in order to test latest KDE on
F7.  The resulting kernel update was mismatched with kernel-devel so I could
not install the nvidia drivers.  My suggestion is this.  Would it be
possible to segregate updates according to package type (similiar to the
SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc
and deps) and System( kernel etc.)  so testing bleeding edge packages from
one package group won't break other system packages?

Mark Bidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071105/14c9d7d8/attachment.htm>

From ajackson at redhat.com  Mon Nov  5 14:00:30 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 05 Nov 2007 09:00:30 -0500
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <ufawsszuyp1.fsf@epithumia.math.uh.edu>
References: <47270A91.7070305@n-dimensional.de>
	<1193751987.5775.2.camel@localhost.localdomain>
	<1193753498.15341.67.camel@localhost.localdomain>
	<ufawsszuyp1.fsf@epithumia.math.uh.edu>
Message-ID: <1194271230.15341.122.camel@localhost.localdomain>

On Sat, 2007-11-03 at 10:38 -0500, Jason L Tibbitts III wrote:
> >>>>> "AJ" == Adam Jackson <ajackson at redhat.com> writes:
> AJ> Not a huge problem, actually, since the avivo driver doesn't ship
> AJ> an xinf file yet.  But yeah, if you ship one, then kudzu will
> AJ> match devices with the IDs listed in it to the driver named at the
> AJ> end of the file, which means you'll be set up at install time with
> AJ> that driver.
> 
> On this subject, the openchrome driver that was recently reviewed did
> include a .xinf file.  Would this be problematic?

Openchrome appears to be a complete superset of the existing via driver,
which is unmaintained and in some cases actively broken.  So I have no
problem with openchrome actively claiming devices.

- ajax



From pertusus at free.fr  Mon Nov  5 14:39:39 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 15:39:39 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <38058.63.85.68.164.1194268116.squirrel@mail.jcomserv.net>
References: <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<472E7970.4000701@fedoraproject.org>
	<20071105092636.GA2841@free.fr>
	<585305xsp8.ln2@hubmaier.ceplovi.cz>
	<38058.63.85.68.164.1194268116.squirrel@mail.jcomserv.net>
Message-ID: <20071105143939.GE2635@free.fr>

On Mon, Nov 05, 2007 at 07:08:36AM -0600, Jon Ciesla wrote:
> 
> I maintain two (I think) packages for which I am upstream.  I suspect I
> wasn't the first, either.

No, you are not the first since when I said in the past that it was not
a good idea to be primary maintainer in fedora and upstream several
people already said they were and some other people also said that it
was fine to be upstream and primary maintainer in fedora. In any case
this is primarily my opinion, not anything official, and I will happily
review a package whose upstream is submitting to fedora. Since I
disagree with this practice, however, I will avoid to do it myself.

--
Pat



From katzj at redhat.com  Mon Nov  5 14:42:27 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 05 Nov 2007 09:42:27 -0500
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030! 5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
Message-ID: <1194273747.6317.58.camel@localhost.localdomain>

On Mon, 2007-11-05 at 00:32 +0100, Matej Cepl wrote:
> On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
> > I have suggested at least 2 technical solutions, none of which 
> > needs any changes to Anaconda:
> 
> May add one more possible solution: what about dropping Base 
> X group from anaconda altogether and why not to treat it as 
> a library, which is required by another components (do we have 
> a group for glibc)?

The problem is that its components *aren't* libraries.  If they were,
they'd be appropriately required by packages and thus automatically
pulled in.  So where do you propose putting those packages so that they
get installed on the system?

Jeremy



From jima at beer.tclug.org  Mon Nov  5 14:47:01 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 5 Nov 2007 08:47:01 -0600 (CST)
Subject: Repo Suggestion
In-Reply-To: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>
References: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0711050842030.4486@beer.tclug.org>

On Mon, 5 Nov 2007, Mark Bidewell wrote:
> Last week I tried moving to updates-testing in order to test latest KDE on
> F7.  The resulting kernel update was mismatched with kernel-devel so I could
> not install the nvidia drivers.  My suggestion is this.  Would it be
> possible to segregate updates according to package type (similiar to the
> SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc
> and deps) and System( kernel etc.)  so testing bleeding edge packages from
> one package group won't break other system packages?

  Not to derail your idea, but is this necessarily anything that `yum 
--enablerepo=updates-testing --exclude=kernel\* upgrade` wouldn't fulfill?
  At this point my brain started muttering something about "hey, wouldn't a 
`yum groupupgrade` command be awesome?"  Which led me to look at the yum 
man page...which fails me.  It only has groupupdate.  *sad panda*
  Seth, would `groupupgrade` be a simple add-on?  Or just pointless?  Not 
sure if obsoletes are important enough...

  So yeah, in summary, I'm guessing `yum --enablerepo=updates-testing 
groupupdate "KDE (K Desktop Environment)"` will do what you want.

      Jima



From skvidal at fedoraproject.org  Mon Nov  5 14:48:12 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 05 Nov 2007 09:48:12 -0500
Subject: Repo Suggestion
In-Reply-To: <Pine.LNX.4.64.0711050842030.4486@beer.tclug.org>
References: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>
	<Pine.LNX.4.64.0711050842030.4486@beer.tclug.org>
Message-ID: <1194274092.2654.94.camel@cutter>


On Mon, 2007-11-05 at 08:47 -0600, Jima wrote:
> On Mon, 5 Nov 2007, Mark Bidewell wrote:
> > Last week I tried moving to updates-testing in order to test latest KDE on
> > F7.  The resulting kernel update was mismatched with kernel-devel so I could
> > not install the nvidia drivers.  My suggestion is this.  Would it be
> > possible to segregate updates according to package type (similiar to the
> > SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc
> > and deps) and System( kernel etc.)  so testing bleeding edge packages from
> > one package group won't break other system packages?
> 
>   Not to derail your idea, but is this necessarily anything that `yum 
> --enablerepo=updates-testing --exclude=kernel\* upgrade` wouldn't fulfill?
>   At this point my brain started muttering something about "hey, wouldn't a 
> `yum groupupgrade` command be awesome?"  Which led me to look at the yum 
> man page...which fails me.  It only has groupupdate.  *sad panda*
>   Seth, would `groupupgrade` be a simple add-on?  Or just pointless?  Not 
> sure if obsoletes are important enough...
> 

what would groupupgrade do that groupupdate doesn't do? and more to the
point, what is it you think groupupdate does?

-sv




From fedora at leemhuis.info  Mon Nov  5 14:52:34 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 05 Nov 2007 15:52:34 +0100
Subject: Repo Suggestion
In-Reply-To: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>
References: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>
Message-ID: <472F2E32.4070601@leemhuis.info>

On 05.11.2007 15:24, Mark Bidewell wrote:
> Last week I tried moving to updates-testing in order to test latest KDE
> on F7.  The resulting kernel update was mismatched with kernel-devel so
> I could not install the nvidia drivers.  My suggestion is this.  Would
> it be possible to segregate updates according to package type (similiar
> to the SUSE buildservice) or even just along the lines of Desktop
> (KDE/GNOME/etc and deps) and System( kernel etc.)  so testing bleeding
> edge packages from one package group won't break other system packages?

That's IMHO the wrong way forward.

The real solution is to build kmods in livna for testing. That is
unlikely to happen. But it's my plan for rpmfusion, as we'll use the
current Fedora push scripts there, which make dealing with a testing
repo much easier.

CU
knurd



From ajackson at redhat.com  Mon Nov  5 14:21:35 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 05 Nov 2007 09:21:35 -0500
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
References: <loom.20071030T224723-163@post.gmane.org>
	<4727D05D.6060903@fedoraproject.org>
	<20071031011317.GA8370@nostromo.devel.redhat.com>
	<4727DA73.1070908@fedoraproject.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030! 5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
Message-ID: <1194272495.15341.136.camel@localhost.localdomain>

On Mon, 2007-11-05 at 00:32 +0100, Matej Cepl wrote:
> On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
> > I have suggested at least 2 technical solutions, none of which 
> > needs any changes to Anaconda:
> 
> May add one more possible solution: what about dropping Base 
> X group from anaconda altogether and why not to treat it as 
> a library, which is required by another components (do we have 
> a group for glibc)?

The major problem with this is there's almost nothing in the distro that
requires the X server itself at the rpm level.  The various X drivers
do, but nothing requires them besides the xorg-x11-drivers metapackage.
rhpxl and compiz require Xorg, but it's quite possible to want a system
without them, so you don't want to have just those two be responsible
for pulling in the X server.

The base-x group in comps is actually pretty minimal on its own.  I'd be
happy with trimming it down to the bare minimum, marking it non-visible,
and having the various desktop groups depend on it (in comps, not in
their packaging).

Of course this is predicated on comps having a groupreq mechanism, which
it doesn't.

> The other group is much more interesting. I really don't like 
> a tendency of Fedora moving with its system requirements 
> somewhere close to the one of Windows Vista (yes, we would have 
> to fix anaconda first, but that's another issue, let's keep this 
> X specific). It would be nice if people who are interested in 
> this created some group of packages (with their own desktop 
> manager? -- is there anything else than [gkx]dm?) so that we 
> could fourth environment (even though this would be probably very 
> virtual not consisting from packages originally intended to be 
> part of one environment) besides Gnome, KDE, and XFCE. Are there 
> any friends of WindowMaker around here (that would be nice for 
> higher degree of compatibility with Mac OS X)? Or IceWM?

I would say something here about senseless duplication of effort, but
it's not likely to convince anybody.

That said, if someone wanted to have a WindowMaker Desktop group in
comps, that'd be fine; it should depend on base-x though.

> On xdm theme -- if anybody is interested in this; well, 
> xorg-x11-xdm src.rpm is 400k -- it shouldn't be unfathomable for 
> interested geek to fix it and maintain it (and I would be glad to 
> meet you, because xdm bugs in bugzilla are always for me, desktop 
> team bugmaster, kind of nightmare).

Please, just pretend xdm doesn't exist.

I wish we had a way to mark packages as actively deprecated.  I don't
want to orphan xdm, I want that no one work on it ever again.

- ajax



From mark.bidewell at alumni.clemson.edu  Mon Nov  5 14:57:58 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Mon, 5 Nov 2007 09:57:58 -0500
Subject: Repo Suggestion
In-Reply-To: <Pine.LNX.4.64.0711050842030.4486@beer.tclug.org>
References: <bfdeacfa0711050624ta0fdc10m37d2f25bf264dc57@mail.gmail.com>
	<Pine.LNX.4.64.0711050842030.4486@beer.tclug.org>
Message-ID: <bfdeacfa0711050657k4d39dc7xb311f3b0ef0900bb@mail.gmail.com>

Mea Culpa Yes I forgot about the group* commands  that would do what I
wanted.  Thanks

On 11/5/07, Jima <jima at beer.tclug.org> wrote:
>
> On Mon, 5 Nov 2007, Mark Bidewell wrote:
> > Last week I tried moving to updates-testing in order to test latest KDE
> on
> > F7.  The resulting kernel update was mismatched with kernel-devel so I
> could
> > not install the nvidia drivers.  My suggestion is this.  Would it be
> > possible to segregate updates according to package type (similiar to the
> > SUSE buildservice) or even just along the lines of Desktop
> (KDE/GNOME/etc
> > and deps) and System( kernel etc.)  so testing bleeding edge packages
> from
> > one package group won't break other system packages?
>
> Not to derail your idea, but is this necessarily anything that `yum
> --enablerepo=updates-testing --exclude=kernel\* upgrade` wouldn't fulfill?
> At this point my brain started muttering something about "hey, wouldn't a
> `yum groupupgrade` command be awesome?"  Which led me to look at the yum
> man page...which fails me.  It only has groupupdate.  *sad panda*
> Seth, would `groupupgrade` be a simple add-on?  Or just pointless?  Not
> sure if obsoletes are important enough...
>
> So yeah, in summary, I'm guessing `yum --enablerepo=updates-testing
> groupupdate "KDE (K Desktop Environment)"` will do what you want.
>
>      Jima
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071105/5ba1d41c/attachment.htm>

From dcbw at redhat.com  Mon Nov  5 15:00:21 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 05 Nov 2007 10:00:21 -0500
Subject: Fedora 8 on Asus S5A; asus_laptop parameters and wireless
	enable/disable function key
In-Reply-To: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
References: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
Message-ID: <1194274821.18807.18.camel@localhost.localdomain>

On Sun, 2007-11-04 at 12:24 +0100, Trond Danielsen wrote:
> Hi,
> 
> My laptop has a wireless enable/disable function key, which previously
> only disabled the wireless network and it could only be enabled by
> rebooting into Windows. In Fedora 8 I can finally both enable and
> disable the network by adding the parameter wapf=4 to modprobe
> (modprobe asus_laptop wapf=4). This means that I can finally wipe out
> my Windows partition. Horray! :)
> 
> My question is very simple: Which component should I file the bug against?

Ideally asus_laptop would handle the wapf value _itself_.  You shouldn't
have to do anything.  There's really no excuse in 2007 to have to
specify this sort of thing manually.  The bug should likely be filed
against asus_laptop upstream, or if it's in the kernel, kernel bugzilla.
Furthermore, the asus_laptop module should support the rfkill framework
that's already in the kernel in 2.6.23.  Not a rant at you or anything,
just at asus_laptop not Just Working.

Dan



From pertusus at free.fr  Mon Nov  5 15:10:56 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 5 Nov 2007 16:10:56 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <1194272495.15341.136.camel@localhost.localdomain>
References: <1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<1194272495.15341.136.camel@localhost.localdomain>
Message-ID: <20071105151056.GI2635@free.fr>

On Mon, Nov 05, 2007 at 09:21:35AM -0500, Adam Jackson wrote:
> 
> I would say something here about senseless duplication of effort, but
> it's not likely to convince anybody.

I guess that I am bised, but it seems to me that, at least, fvwm,
fluxbox and icewm are not duplicate, and don't duplicate xfce/gnome/kde
either. And dockapps based desktop don't duplicate big desktop either.
I don't know WindowMaker, though.

> Please, just pretend xdm doesn't exist.

I personally am interested in having xdm maintained, since wdm is based
on it. To be honest, I have asked the wdm maintainer to rebase on latest
xdm, but he still hasn't done it. But in any case wdm suits my needs 
much better than gdm (at least starts infinitely faster). I agree that 
xdm itself is a bit too minimalistic, especially since there is no 
simple way to change the session if I recall well.

--
Pat



From mcepl at redhat.com  Mon Nov  5 15:53:41 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Nov 2007 16:53:41 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030! 5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<1194272495.15341.136.camel@localhost.localdomain>
Message-ID: <slrnfiuf45.3g7.mcepl@hubmaier.ceplovi.cz>

On 2007-11-05, 14:21 GMT, Adam Jackson wrote:
> The major problem with this is there's almost nothing in the 
> distro that requires the X server itself at the rpm level.

OK, sorry that's remnants of my Debianist thinking -- I used to 
install from minimal install of Debian to almost fully loaded 
system just by

aptitude install lyx kontact

being quite certain that most of the stuff needed will be there.

No, that's not criticism of Red Hat, just forgot that fully 
defined dependencies are not present everywhere.

> The base-x group in comps is actually pretty minimal on its 
> own.  I'd be happy with trimming it down to the bare minimum, 
> marking it non-visible, and having the various desktop groups 
> depend on it (in comps, not in their packaging).

Sure, that would be perfect for me.

> I would say something here about senseless duplication of 
> effort, but it's not likely to convince anybody.

Read my question ?Why do you not use XFCE? later in the thread.

> Please, just pretend xdm doesn't exist.

I would sometimes wanted to hear the explanation (remember I was 
talking about fixing and maintaining xdm), but for the purposes 
of this discussion you can quite happily

s!xdm!simple display manager w/o Gnome and KDE libs!

I just wasn't sure there are alternatives to [xgk]dm.

> I wish we had a way to mark packages as actively deprecated.  I don't
> want to orphan xdm, I want that no one work on it ever again.

Yes, please, I am always lost with xdm bugs ... :-)

Mat?j



From tibbs at math.uh.edu  Mon Nov  5 16:06:14 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Nov 2007 10:06:14 -0600
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfiuf45.3g7.mcepl@hubmaier.ceplovi.cz>
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030! 5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<1194272495.15341.136.camel@localhost.localdomain>
	<slrnfiuf45.3g7.mcepl@hubmaier.ceplovi.cz>
Message-ID: <ufak5ow3ceh.fsf@epithumia.math.uh.edu>

>>>>> "MC" == Matej Cepl <mcepl at redhat.com> writes:

MC> aptitude install lyx kontact

MC> being quite certain that most of the stuff needed will be there.

MC> No, that's not criticism of Red Hat, just forgot that fully
MC> defined dependencies are not present everywhere.

If those packages require an X server then something is rather wrong
with the dependencies, unless by "fully defined dependencies" you mean
"has way more dependencies than actually needed".

You can install those things on a headless server and run them over
the network.  No X server is needed on the machine where they're
installed.

 - J<



From tibbs at math.uh.edu  Mon Nov  5 16:07:27 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Nov 2007 10:07:27 -0600
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <1194271230.15341.122.camel@localhost.localdomain>
References: <47270A91.7070305@n-dimensional.de>
	<1193751987.5775.2.camel@localhost.localdomain>
	<1193753498.15341.67.camel@localhost.localdomain>
	<ufawsszuyp1.fsf@epithumia.math.uh.edu>
	<1194271230.15341.122.camel@localhost.localdomain>
Message-ID: <ufafxzk3ccg.fsf@epithumia.math.uh.edu>

>>>>> "AJ" == Adam Jackson <ajackson at redhat.com> writes:

AJ> Openchrome appears to be a complete superset of the existing via
AJ> driver, which is unmaintained and in some cases actively broken.
AJ> So I have no problem with openchrome actively claiming devices.

So then should the existing via driver stop claiming them?  Otherwise
don't we start running into unspecified behavior when multiple .xinf
files claim a device?

 - J<



From janina at rednote.net  Mon Nov  5 16:21:34 2007
From: janina at rednote.net (Janina Sajka)
Date: Mon, 5 Nov 2007 11:21:34 -0500
Subject: Inaccessible Post-GDM But Pre-Desktop Dialogs
Message-ID: <20071105162134.GD6342@rednote.net>

There is at least one potential dialog that breaks accessibility after a
user logs in, but before Orca (or Gok) loads. I became aware of this one
demonstrating Orca in Italian to a CompSci professor at a recont F/OSS
symposium in Florence.

The dialog we came across advises of available updates. It does not talk
(in my case). So, it's an accessibility show-stopper.

Generically speaking, all such potential pop-ups need to be vetted for
accessibility. What about the one that says: "you're not connected to
the Internet," for instance?

Of course, one might also ask why an ordinary user is being prompted for
sysadmin tasks. In the current instance, that's seems inappropriate,
imho, though the generic problem remains.

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From xavier at bachelot.org  Mon Nov  5 16:21:31 2007
From: xavier at bachelot.org (Xavier Bachelot)
Date: Mon, 05 Nov 2007 17:21:31 +0100
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <ufafxzk3ccg.fsf@epithumia.math.uh.edu>
References: <47270A91.7070305@n-dimensional.de>	<1193751987.5775.2.camel@localhost.localdomain>	<1193753498.15341.67.camel@localhost.localdomain>	<ufawsszuyp1.fsf@epithumia.math.uh.edu>	<1194271230.15341.122.camel@localhost.localdomain>
	<ufafxzk3ccg.fsf@epithumia.math.uh.edu>
Message-ID: <472F430B.8090808@bachelot.org>

Jason L Tibbitts III wrote:
>>>>>> "AJ" == Adam Jackson <ajackson at redhat.com> writes:
> 
> AJ> Openchrome appears to be a complete superset of the existing via
> AJ> driver, which is unmaintained and in some cases actively broken.
> AJ> So I have no problem with openchrome actively claiming devices.
> 
yes, openchrome is based on what used to be the via xorg driver.

> So then should the existing via driver stop claiming them?  Otherwise
> don't we start running into unspecified behavior when multiple .xinf
> files claim a device?
> 
>  - J<
> 
My understanding is openchrome will only claim a device if it's manually 
installed (obviously), and if the user invokes system-config-display 
again after that. Does this make sense ?


Regards,
Xavier



From ajackson at redhat.com  Mon Nov  5 16:11:34 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 05 Nov 2007 11:11:34 -0500
Subject: How to generate videoaliases/foo.xinf for hwdata?
In-Reply-To: <472F430B.8090808@bachelot.org>
References: <47270A91.7070305@n-dimensional.de>
	<1193751987.5775.2.camel@localhost.localdomain>
	<1193753498.15341.67.camel@localhost.localdomain>
	<ufawsszuyp1.fsf@epithumia.math.uh.edu>
	<1194271230.15341.122.camel@localhost.localdomain>
	<ufafxzk3ccg.fsf@epithumia.math.uh.edu> <472F430B.8090808@bachelot.org>
Message-ID: <1194279094.15341.153.camel@localhost.localdomain>

On Mon, 2007-11-05 at 17:21 +0100, Xavier Bachelot wrote:

> My understanding is openchrome will only claim a device if it's manually 
> installed (obviously), and if the user invokes system-config-display 
> again after that. Does this make sense ?

Well, kudzu, but yes.

But I'm super eager to drop the old via driver in F9, so don't be
surprised if xorg-x11-drivers starts installing openchrome instead of
via by default.

- ajax



From katzj at redhat.com  Mon Nov  5 16:51:29 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 05 Nov 2007 11:51:29 -0500
Subject: Inaccessible Post-GDM But Pre-Desktop Dialogs
In-Reply-To: <20071105162134.GD6342@rednote.net>
References: <20071105162134.GD6342@rednote.net>
Message-ID: <1194281489.31380.8.camel@localhost.localdomain>

On Mon, 2007-11-05 at 11:21 -0500, Janina Sajka wrote:
> There is at least one potential dialog that breaks accessibility after a
> user logs in, but before Orca (or Gok) loads. I became aware of this one
> demonstrating Orca in Italian to a CompSci professor at a recont F/OSS
> symposium in Florence.
> 
> The dialog we came across advises of available updates. It does not talk
> (in my case). So, it's an accessibility show-stopper.
> 
> Generically speaking, all such potential pop-ups need to be vetted for
> accessibility. What about the one that says: "you're not connected to
> the Internet," for instance?

They're actually from the same source.  The problem here is that things
in the notification area (puplet, nm-applet, etc) are all started by
gnome-session as is the panel, orca, etc.  If one of the notification
area applets wants to show a notification bubble, they just do a
libnotify call.  But there's no way to ensure that the panel is up (and
thus that their icon is actually visible) much less if other things like
a11y technologies are running.

We really need a way to serialize some of this.  Unfortunately, that'll
end up coming at the cost of a (slightly) slower login time

Jeremy



From Michael_E_Brown at dell.com  Mon Nov  5 17:10:08 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 5 Nov 2007 11:10:08 -0600
Subject: How to set %vendor in mock?
In-Reply-To: <1194252738.26832.23.camel@mccallum.corsepiu.local>
References: <1194246872.26832.7.camel@mccallum.corsepiu.local>
	<20071105072417.GB2295@psilocybe.teonanacatl.org>
	<1194252738.26832.23.camel@mccallum.corsepiu.local>
Message-ID: <20071105171007.GA4778@humbolt.us.dell.com>

On Mon, Nov 05, 2007 at 09:52:18AM +0100, Ralf Corsepius wrote:
> On Mon, 2007-11-05 at 02:24 -0500, Todd Zullinger wrote:
> > Ralf Corsepius wrote:
> > > Hi,
> > > 
> > > in the past, I used to set up %vendor in mock by adding
> > > ...
> > > config_opts['macros'] += '%vendor       VENDOR'
> > > ...
> > > to customized mock *.cfgs.
> > > 
> > > 
> > > This stopped working with FC7's recent upgrade to mock-0.8.x:
> > > 
> > > # mock --configdir=/foo/etc/mock -r fedora-7-i386-test init
> > > INFO: mock suid wrapper version 0.8.4 
> > > ERROR: unsupported operand type(s) for +=: 'dict' and 'str'
> > > Traceback (most recent call last):
> > >  File "/usr/libexec/mock.py", line 333, in <module>
> > >    main(retParams)
> > >  File "/usr/libexec/mock.py", line 249, in main
> > >    execfile(cfg)
> > >  File "/foo/etc/mock/fedora-7-i386-test.cfg", line 7, in <module>
> > >    config_opts['macros'] += '%vendor   VENDOR'
> > > TypeError: unsupported operand type(s) for +=: 'dict' and 'str'
> > > 
> > > Any ideas?
> > 
> > I haven't tested this, but I just updated mock today and was looking
> > at the changes in the defaults.cfg file.  The example given there is:
> > 
> > config_opts['macros']['Add_your_macro_name_here'] = "add macro value here"
> > 
> > So I'd guess that you want to try something like this:
> > 
> > config_opts['macros']['vendor'] = "VENDOR"
> 
> Thanks, using
> config_opts['macros']['%vendor'] = "VENDOR"
> in *.cfgs seems to do it on fc7.
> 
> Problem: This change seems incompatible to older mocks and is breaking
> sharing *.cfg's with them:
> 
> (On a machine using an older mock)
> ...
> Traceback (most recent call last):
>   File "/usr/bin/mock", line 995, in ?
>     main()
>   File "/usr/bin/mock", line 951, in main
>     execfile(cfg)
>   File "/home/build/etc/mock//fedora-7-i386-test.cfg", line 7, in ?
>     config_opts['macros']['%vendor'] = 'VENDOR'
> TypeError: object does not support item assignment

If you want to share configs between different versions, then you will
need a bit of python magic. The config file is (for now) a
fully-interpreted python source file. You could easily check the type of
config_opts['macros'] and then add the appropriate version-specific
magic to it.

--
Michael



From fedora at leemhuis.info  Mon Nov  5 17:29:45 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 05 Nov 2007 18:29:45 +0100
Subject: EPEL report week 44 2007
Message-ID: <472F5309.8040102@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week44

Heads up: we didn't meet in recent weeks; we really should try to get a
proper meeting this Wednesday (e.g two days from now). If you are
interested in EPEL: come, join us!

----
= Weekly EPEL Summary =

Week 44/2007

== Most important happenings ==

 * Seems testing stable move went well; at least we only got one
complaint of a broken dep, which was fixed ;-)

 * Some discussions about redistributing EPEL binaries; see this thread:
https://www.redhat.com/archives/epel-devel-list/2007-November/msg00005.html

 * EPEL will now only keep only one version of a packages in testing
(e.g. only the latest one and not one older one in addition, as done in
the proper repos); see
https://www.redhat.com/archives/epel-devel-list/2007-November/msg00000.html

== Meeting ==

No meeting past week. Next meeting 20071107 at 17:00 UTC in #fedora-meeting

== Stats ==

=== General ===

Number of EPEL Contributors: 137

=== EPEL 5 ===

Number of source packages: 716

Number of binary packages:  1376

There are 10 new Packages:

 * cdpr | Cisco Discovery Protocol Analyzer
 * func | Remote config, monitoring, and management api
 * perl-LockFile-Simple | Simple file locking scheme
 * perl-Tk | Perl Graphical User Interface ToolKit
 * postgis | Geographic Information Systems Extensions to PostgreSQL
 * ruby-ldap | Ruby LDAP libraries
 * tre | POSIX compatible regexp library with approximate matching
 * unshield | Install InstallShield applications on a Pocket PC
 * wordpress | WordPress blogging software
 * wv2 | A library which allows access to Microsoft? Word files

=== EPEL 4 ===

Number of source packages: 440

Number of binary packages:  888

There are 6 new Packages:

 * func | Remote config, monitoring, and management api
 * perl-LockFile-Simple | Simple file locking scheme
 * perl-Tk | Perl Graphical User Interface ToolKit
 * ruby-ldap | Ruby LDAP libraries
 * unshield | Install InstallShield applications on a Pocket PC
 * wv2 | A library which allows access to Microsoft? Word files

----
["CategoryEPELReports"]



From orion at cora.nwra.com  Mon Nov  5 17:47:20 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 05 Nov 2007 10:47:20 -0700
Subject: Rawhide uninstallable
Message-ID: <472F5728.4020306@cora.nwra.com>

Seems like rawhide has been uninstallable for the last few days.  This 
seems to be a bad sign to me.  Is it?


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From jkeating at redhat.com  Mon Nov  5 17:51:03 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 5 Nov 2007 12:51:03 -0500
Subject: Rawhide uninstallable
In-Reply-To: <472F5728.4020306@cora.nwra.com>
References: <472F5728.4020306@cora.nwra.com>
Message-ID: <20071105125103.52aa6919@redhat.com>

On Mon, 05 Nov 2007 10:47:20 -0700
Orion Poplawski <orion at cora.nwra.com> wrote:

> Seems like rawhide has been uninstallable for the last few days.
> This seems to be a bad sign to me.  Is it?

It's not a bad sign.  It's an issue with buildinstall that only seems
to effect the rawhide creation process in usually unrepeatable ways.
I'm looking into it today, but the final f8 compose did not have any of
these compose issues.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071105/651f684a/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov  5 17:55:40 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 05 Nov 2007 23:25:40 +0530
Subject: Rawhide uninstallable
In-Reply-To: <472F5728.4020306@cora.nwra.com>
References: <472F5728.4020306@cora.nwra.com>
Message-ID: <472F591C.8060708@fedoraproject.org>

Orion Poplawski wrote:
> Seems like rawhide has been uninstallable for the last few days.  This 
> seems to be a bad sign to me.  Is it?

What are you talking about? What problem are you facing?

Rahul



From mszpak at wp.pl  Mon Nov  5 18:17:25 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Mon, 05 Nov 2007 19:17:25 +0100
Subject: Infinity theme for gdm removed from Fedora?
Message-ID: <fgnmnm$p76$1@ger.gmane.org>

Hi,


In Fedora 8 Test3 the default theme for gdm (login screen) is Infinity.
One of the available updates removes it completely (after restart there
is an error message about missing files and in fact those files are
missing).
Was it intended to remove that theme?


Regards
Marcin



From bpeck at redhat.com  Mon Nov  5 18:33:50 2007
From: bpeck at redhat.com (Bill Peck)
Date: Mon, 05 Nov 2007 13:33:50 -0500
Subject: Rawhide uninstallable
In-Reply-To: <472F591C.8060708@fedoraproject.org>
References: <472F5728.4020306@cora.nwra.com>
	<472F591C.8060708@fedoraproject.org>
Message-ID: <472F620E.7050802@redhat.com>

Rahul Sundaram wrote:
> Orion Poplawski wrote:
>> Seems like rawhide has been uninstallable for the last few days.  
>> This seems to be a bad sign to me.  Is it?
>
> What are you talking about? What problem are you facing?
>
> Rahul
>

The images directory has not been populated for days.



From caillon at redhat.com  Mon Nov  5 18:43:53 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 05 Nov 2007 19:43:53 +0100
Subject: KDE logout options with F8
In-Reply-To: <fgf31k$991$1@ger.gmane.org>
References: <loom.20071030T224723-163@post.gmane.org>	<4727B54A.4080806@fedoraproject.org>	<20071031003225.GB3972@nostromo.devel.redhat.com>	<4727D05D.6060903@fedoraproject.org>	<20071031011317.GA8370@nostromo.devel.redhat.com>	<4727DA73.1070908@fedoraproject.org>	<20071031014811.GA13676@nostromo.devel.redhat.com>	<4727DF0E.7090308@fedoraproject.org>	<1193795538.11243.3.camel@localhost.localdomain>	<4727E19F.1010405@fedoraproject.org>	<20071031020715.GA14902@nostromo.devel.redhat.com>	<4727E511.9000504@fedoraproject.org>	<1193797294.11243.7.camel@localhost.localdomain>	<loom.20071031T041957-355@post.gmane.org>	<47286CCE.9020401@redhat.com>	<loom.20071101T152020-62@post.gmane.org>	<472A62A3.1050504@redhat.com>	<loom.20071102T034429-412@post.gmane.org>	<472ADF35.6040608@redhat.com>
	<fgf31k$991$1@ger.gmane.org>
Message-ID: <472F6469.3050001@redhat.com>

Rex Dieter wrote:
> Christopher Aillon wrote:
> 
> 
>> I'm still waiting on the KDE guys to come through with fixing the Qt
>> Firefox port.  We allowed them to check in code to Mozilla upstream, and
>>   then they dropped it and haven't kept it up to date.  So we just CVS
>> removed it from CVS HEAD this past week.
> 
> Don't even go there.  

But you already did[1] which proves my point exactly.

 > Keep on waiting....  Dirk was going to help work on it was never 
granted cvs access.

"Was going to" contribute.  But didn't.  As David Baron asked in the 
bug[2] you conveniently linked to, "Why should [Mozilla] give cvs access 
to people who haven't yet written any patches to Mozilla?"  I've never 
heard of someone use that as an excuse for refusing to patch something. 
  Submit your patch(es) and let others check them in until you get 
access.  Or are you telling me that the fact that KNM wasn't done on 
time is because a few KDE guys don't have commit access to Fedora's 
repository?

Please.


[1] http://rdieter.livejournal.com/2007/11/02/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=297788



From roland at redhat.com  Mon Nov  5 20:29:05 2007
From: roland at redhat.com (Roland McGrath)
Date: Mon,  5 Nov 2007 12:29:05 -0800 (PST)
Subject: rpmbuild stops with debugedit error on F8
In-Reply-To: John Dennis's message of  Monday,
	5 November 2007 08:52:20 -0500 <472F2014.4080002@redhat.com>
References: <472CD39C.4050206@redhat.com>
	<20071103221854.B0B4B4D04C0@magilla.localdomain>
	<472CFE9C.10506@redhat.com>
	<20071103233034.7F16D4D04C0@magilla.localdomain>
	<472F2014.4080002@redhat.com>
Message-ID: <20071105202905.102634D0435@magilla.localdomain>

> The only thing I might take issue with is your belief the error message 
> is patently obvious. 

I never said that!  I said that what the error message says is true.

> May I suggest the error message be replaced with something which would 
> direct a developer to the root cause of the problem, especially since 
> this is a somewhat arcane limitation.

I'm sure the rpm maintainers would be happy to accept such a patch.  Using
both actual directory names in the message rather than just "-b arg" would
probably make it clear enough.

> Maybe rpmbuild should stop immediately with an error if you invoke it 
> with a topdir which is unacceptable to it's internal operation.

Well, it can cope in certain cases, basically when other cruft happens to
even out.  So it really doesn't know for sure until it knows.  


Thanks,
Roland



From debarshi.ray at gmail.com  Mon Nov  5 20:40:50 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 6 Nov 2007 02:10:50 +0530
Subject: glade3 in fedora7
In-Reply-To: <1186967894.3339.30.camel@localhost.localdomain>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com>
	<9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com>
	<1182676374.7266.2.camel@localhost.localdomain>
	<467E95A5.2060506@fedoraproject.org>
	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
Message-ID: <3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>

https://bugzilla.redhat.com/show_bug.cgi?id=177747
https://bugzilla.redhat.com/show_bug.cgi?id=220710

These review requests seem abandoned.

Would it be alright if I picked up the Specs and SRPMs, polished them
up a bit and submitted a review request?

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From rc040203 at freenet.de  Mon Nov  5 20:51:57 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 05 Nov 2007 21:51:57 +0100
Subject: How to set %vendor in mock?
In-Reply-To: <20071105171007.GA4778@humbolt.us.dell.com>
References: <1194246872.26832.7.camel@mccallum.corsepiu.local>
	<20071105072417.GB2295@psilocybe.teonanacatl.org>
	<1194252738.26832.23.camel@mccallum.corsepiu.local>
	<20071105171007.GA4778@humbolt.us.dell.com>
Message-ID: <1194295918.9673.10.camel@mccallum.corsepiu.local>

On Mon, 2007-11-05 at 11:10 -0600, Michael E Brown wrote:
> On Mon, Nov 05, 2007 at 09:52:18AM +0100, Ralf Corsepius wrote:
> > On Mon, 2007-11-05 at 02:24 -0500, Todd Zullinger wrote:
> > > Ralf Corsepius wrote:
> > > > Hi,
> > > > 
> > > > in the past, I used to set up %vendor in mock by adding
> > > > ...
> > > > config_opts['macros'] += '%vendor       VENDOR'
> > > > ...
> > > > to customized mock *.cfgs.
> > > > 
> > > > 
> > > > This stopped working with FC7's recent upgrade to mock-0.8.x:
> > > > 
> > > > # mock --configdir=/foo/etc/mock -r fedora-7-i386-test init
> > > > INFO: mock suid wrapper version 0.8.4 
> > > > ERROR: unsupported operand type(s) for +=: 'dict' and 'str'
> > > > Traceback (most recent call last):
> > > >  File "/usr/libexec/mock.py", line 333, in <module>
> > > >    main(retParams)
> > > >  File "/usr/libexec/mock.py", line 249, in main
> > > >    execfile(cfg)
> > > >  File "/foo/etc/mock/fedora-7-i386-test.cfg", line 7, in <module>
> > > >    config_opts['macros'] += '%vendor   VENDOR'
> > > > TypeError: unsupported operand type(s) for +=: 'dict' and 'str'
> > > > 
> > > > Any ideas?
> > > 
> > > I haven't tested this, but I just updated mock today and was looking
> > > at the changes in the defaults.cfg file.  The example given there is:
> > > 
> > > config_opts['macros']['Add_your_macro_name_here'] = "add macro value here"
> > > 
> > > So I'd guess that you want to try something like this:
> > > 
> > > config_opts['macros']['vendor'] = "VENDOR"
> > 
> > Thanks, using
> > config_opts['macros']['%vendor'] = "VENDOR"
> > in *.cfgs seems to do it on fc7.
> > 
> > Problem: This change seems incompatible to older mocks and is breaking
> > sharing *.cfg's with them:
> > 
> > (On a machine using an older mock)
> > ...
> > Traceback (most recent call last):
> >   File "/usr/bin/mock", line 995, in ?
> >     main()
> >   File "/usr/bin/mock", line 951, in main
> >     execfile(cfg)
> >   File "/home/build/etc/mock//fedora-7-i386-test.cfg", line 7, in ?
> >     config_opts['macros']['%vendor'] = 'VENDOR'
> > TypeError: object does not support item assignment
> 
> If you want to share configs between different versions, then you will
> need a bit of python magic. The config file is (for now) a
> fully-interpreted python source file.
Right, this change in mock broke what has been functional for a long
time. You have incompatibly changed the command-line interface and the
configuration file format.

Ralf




From ajackson at redhat.com  Mon Nov  5 20:30:08 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 05 Nov 2007 15:30:08 -0500
Subject: Severe X breakage heads up
Message-ID: <1194294608.15341.204.camel@localhost.localdomain>

I plan to rebase the X server to git master a week from today (Monday,
November 12), which means the changes should hit rawhide on Tuesday.

DEAR SHORT ATTENTION SPAN PEOPLE:

% sudo sed -i -e '/^\[main\]/ a exclude=xorg-*' /etc/yum.conf

Run that line to opt out of the disaster.  Thank you for your time.

Now for some details.

This X server requires libpciaccess.  Not all of the drivers have been
ported yet.  Not all of them will be ported by Monday, though I'll try
to have the big three of {radeon,intel,nv} and the vesa driver converted
by then.  This should cover most people.  I hope.

If your driver is not ported, you'll see an error like this in the X
log:

(EE) module ABI major version (1) doesn't match the server's version (3)

This means switch to vesa, or else back down to F8 X.

Mesa will rebase in the same go.  This may or may not break 3D for you.
It shouldn't, but it might.  Likewise libdrm, but that's unlikely to be
a problem in and of itself.  I'm quite likely to update those two
components sometime this week, they should be relatively low impact on
their own.

This server will also introduce input hotplug support.  TBH I have no
idea how this should be set up at the moment.  I'll try to get something
working at least for the machines I have here, but that might only be
good enough for static configuration same as F8 and earlier.  If someone
wants to own the i-h part of this that'd be awesome, otherwise we'll get
to it as we have time.

I think those are the highlights.  If there are any further questions,
please ask, I may have missed something.  If any bugs come up in the
transition, please do file them!  We need to know what breaks so we know
what we need to fix.  And of course, all patches and assistance are
greatly appreciated.

- ajax



From j.w.r.degoede at hhs.nl  Mon Nov  5 21:19:18 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 05 Nov 2007 22:19:18 +0100
Subject: glade3 in fedora7
In-Reply-To: <3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
References: <1182662333.5754.2.camel@localhost.localdomain>	<76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com>	<9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com>	<1182676374.7266.2.camel@localhost.localdomain>	<467E95A5.2060506@fedoraproject.org>	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>	<469C7B45.4070407@rasmil.dk>	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
Message-ID: <472F88D6.1020202@hhs.nl>

Debarshi 'Rishi' Ray wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=177747
> https://bugzilla.redhat.com/show_bug.cgi?id=220710
> 
> These review requests seem abandoned.
> 
> Would it be alright if I picked up the Specs and SRPMs, polished them
> up a bit and submitted a review request?
> 

Glade3 has been incorperated into gtk-2.12.0, and thus will be in F-8, its 
called gtkbuilder now and this is considered the future of glade (AFAIK)

Regards,

Hans



From mclasen at redhat.com  Mon Nov  5 21:25:09 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 05 Nov 2007 16:25:09 -0500
Subject: glade3 in fedora7
In-Reply-To: <472F88D6.1020202@hhs.nl>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com>
	<9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com>
	<1182676374.7266.2.camel@localhost.localdomain>
	<467E95A5.2060506@fedoraproject.org>
	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
Message-ID: <1194297909.5020.6.camel@localhost.localdomain>


On Mon, 2007-11-05 at 22:19 +0100, Hans de Goede wrote:
> Debarshi 'Rishi' Ray wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=177747
> > https://bugzilla.redhat.com/show_bug.cgi?id=220710
> > 
> > These review requests seem abandoned.
> > 
> > Would it be alright if I picked up the Specs and SRPMs, polished them
> > up a bit and submitted a review request?
> > 
> 
> Glade3 has been incorperated into gtk-2.12.0, and thus will be in F-8, its 
> called gtkbuilder now and this is considered the future of glade (AFAIK)
> 

This is so inaccurate that one could call it wrong. gtk 2.12 does
contain GtkBuilder, which is a piece of code very similar in
functionality to libglade, which it will obsolete over time. The file
format used by GtkBuilder is different from the glade file format, and
we hope that ui builders will soon start to support the GtkBuilder
format in addition to the glade format. 

GtkBuilder is in no way a replacement for glade, gazpacho or glade-3



From debarshi.ray at gmail.com  Mon Nov  5 21:44:31 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 6 Nov 2007 03:14:31 +0530
Subject: glade3 in fedora7
In-Reply-To: <1194297909.5020.6.camel@localhost.localdomain>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<467E95A5.2060506@fedoraproject.org>
	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
	<1194297909.5020.6.camel@localhost.localdomain>
Message-ID: <3170f42f0711051344p7269bc24hbccdc985fcd807d4@mail.gmail.com>

Matthias,

+ So, should I make the package and submit the review?

+ If yes, what should be the name of the package? glade3 or glade?

+ Should it be parallely installable with glade2?

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From mclasen at redhat.com  Mon Nov  5 21:44:38 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 05 Nov 2007 16:44:38 -0500
Subject: glade3 in fedora7
In-Reply-To: <3170f42f0711051344p7269bc24hbccdc985fcd807d4@mail.gmail.com>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<467E95A5.2060506@fedoraproject.org>
	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
	<1194297909.5020.6.camel@localhost.localdomain>
	<3170f42f0711051344p7269bc24hbccdc985fcd807d4@mail.gmail.com>
Message-ID: <1194299078.5020.9.camel@localhost.localdomain>


On Tue, 2007-11-06 at 03:14 +0530, Debarshi 'Rishi' Ray wrote:
> Matthias,
> 
> + So, should I make the package and submit the review?

Well, there is already a package and a review; it would be enough to
revive it/take it over.

> + If yes, what should be the name of the package? glade3 or glade?
>
> + Should it be parallely installable with glade2?

Since I am not sure that glade3 is actually a drop-in replacement for
glade2 I would say that it should be glade3 and should not conflict with
or obsolete glade2.  But I haven't investigated this closely.



From debarshi.ray at gmail.com  Mon Nov  5 21:49:57 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 6 Nov 2007 03:19:57 +0530
Subject: glade3 in fedora7
In-Reply-To: <1194299078.5020.9.camel@localhost.localdomain>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
	<1194297909.5020.6.camel@localhost.localdomain>
	<3170f42f0711051344p7269bc24hbccdc985fcd807d4@mail.gmail.com>
	<1194299078.5020.9.camel@localhost.localdomain>
Message-ID: <3170f42f0711051349u1d1296d0i868bb77a59c03033@mail.gmail.com>

> Well, there is already a package and a review; it would be enough to
> revive it/take it over.

That is what I meant. :-)

> Since I am not sure that glade3 is actually a drop-in replacement for
> glade2 I would say that it should be glade3 and should not conflict with
> or obsolete glade2.  But I haven't investigated this closely.

Ok.

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From sundaram at fedoraproject.org  Mon Nov  5 21:45:52 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Nov 2007 03:15:52 +0530
Subject: Fedora policy on setting up a SIG mailing list?
In-Reply-To: <472F0241.6010609@redhat.com>
References: <472F0241.6010609@redhat.com>
Message-ID: <472F8F10.4090801@fedoraproject.org>

Richard W.M. Jones wrote:
> Over in the diaspora of OCaml users we thought it might be an idea to 
> have a Fedora-ocaml mailing list to discuss various issues.
> 
> Is there a policy on Fedora mailing lists?  The nearest I could find was 
> http://fedoraproject.org/wiki/Communicate/MailingListGuidelines/ConfiguringLists 
> but that doesn't cover the issue of setting up a Fedora mailing list.

Afaik, you just have to ask the infrastructure team. We probably need a 
policy soon though.

Rahul



From hughsient at gmail.com  Mon Nov  5 23:49:41 2007
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 05 Nov 2007 23:49:41 +0000
Subject: Fedora 8 on Asus S5A; asus_laptop parameters and wireless
	enable/disable function key
In-Reply-To: <1194274821.18807.18.camel@localhost.localdomain>
References: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
	<1194274821.18807.18.camel@localhost.localdomain>
Message-ID: <1194306581.13432.16.camel@hughsie-laptop>

On Mon, 2007-11-05 at 10:00 -0500, Dan Williams wrote:
> Furthermore, the asus_laptop module should support the rfkill
> framework that's already in the kernel in 2.6.23.

Totally agree, this is where this functionality belongs.

Richard.




From notting at redhat.com  Tue Nov  6 00:31:51 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 5 Nov 2007 19:31:51 -0500
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
References: <4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
Message-ID: <20071106003151.GA500@nostromo.devel.redhat.com>

Matej Cepl (mcepl at redhat.com) said: 
> May add one more possible solution: what about dropping Base 
> X group from anaconda altogether and why not to treat it as 
> a library, which is required by another components (do we have 
> a group for glibc)?

group dependencies don't currently exist.

Bill



From poelstra at redhat.com  Tue Nov  6 00:37:29 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 05 Nov 2007 16:37:29 -0800
Subject: F9 Feature Process
In-Reply-To: <1193888060.4875.24.camel@localhost.localdomain>
References: <47293CBF.7020900@redhat.com>
	<1193888060.4875.24.camel@localhost.localdomain>
Message-ID: <472FB749.8030602@redhat.com>

Matthias Clasen wrote:
> Out of interest, I didn't see any information about how we did in terms of features that made it in vs features 
> that were dropped or deferred in your F8 recap. Did we drop anything, and if so, have you looked at why ?
> 

Thanks for all of your feedback.  I will make sure FESCo considers it 
when they discuss changes to the policy.

In terms of stats on features that were dropped or deferred--I did not 
actively track them, but that is in interesting question.  Would there 
be value in doing that or is anecdotal evidence enough?  I ask because 
tracking it is all manual :)

In almost all of the cases, FESCo and the feature owner(s) agreed that a 
particular feature wasn't ready enough and should be deferred a the time 
approval was being voted on OR features with stale statuses that I 
raised at FESCo after not hearing back from the feature owner when it 
was pretty much known that that particular feature was not going to be 
completed.

Then there were a couple of features where the feature was approved, 
nothing happened with it and then it was dropped because the owner said 
it wasn't really considered a feature... 
http://fedoraproject.org/wiki/Releases/8/Bookmarks

John



From mclasen at redhat.com  Tue Nov  6 00:45:38 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 05 Nov 2007 19:45:38 -0500
Subject: F9 Feature Process
In-Reply-To: <472FB749.8030602@redhat.com>
References: <47293CBF.7020900@redhat.com>
	<1193888060.4875.24.camel@localhost.localdomain>
	<472FB749.8030602@redhat.com>
Message-ID: <1194309938.7067.4.camel@localhost.localdomain>


On Mon, 2007-11-05 at 16:37 -0800, John Poelstra wrote:

> 
> Then there were a couple of features where the feature was approved, 
> nothing happened with it and then it was dropped because the owner said 
> it wasn't really considered a feature... 

I hope that the nicely done F8 release summary will really drive home
the value of doing the feature tracking and more people will come
forward to do some advertising for the stuff they are doing.
Just comparing the numbers, the recently published feature list for the
next Ubuntu release was some 130 items long, while I currently see ~10
items in CategoryFeatureFedora9. Admittedly, there is probably some 75%
or so in the Ubuntu list that is just hot air or nice ideas that will
never get done, but still...

Matthias



From poelstra at redhat.com  Tue Nov  6 01:03:47 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 05 Nov 2007 17:03:47 -0800
Subject: Fedora Rel-Eng Meeting Recap 2007-NOV-05
Message-ID: <472FBD73.5060705@redhat.com>

Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-05

Please make corrections and clarifications to the wiki page.

== F8 ==
  * off to the mirrors; torrents are in progress
  * later this afternoon hope to get a push of F8 updates(-testing) done 
and drop the mirror-manager redirect
  * F8 is unlocked in bodhi so the requests will now show up in the list.
    * 170 0-day updates so far

== Post F8 ==
  * implement new development cycle
  * change of names from "development" tree to "rawhide"
    * making these changes early next week
    * f13 to send out a proposal
  * we need to prioritize F8Target blocker bug
  * other details in IRC transcript

== IRC Transcript ==



From katzj at redhat.com  Tue Nov  6 01:55:07 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 05 Nov 2007 20:55:07 -0500
Subject: F9 Feature Process
In-Reply-To: <1194309938.7067.4.camel@localhost.localdomain>
References: <47293CBF.7020900@redhat.com>
	<1193888060.4875.24.camel@localhost.localdomain>
	<472FB749.8030602@redhat.com>
	<1194309938.7067.4.camel@localhost.localdomain>
Message-ID: <1194314107.31380.33.camel@localhost.localdomain>

On Mon, 2007-11-05 at 19:45 -0500, Matthias Clasen wrote:
> On Mon, 2007-11-05 at 16:37 -0800, John Poelstra wrote:
> > Then there were a couple of features where the feature was approved, 
> > nothing happened with it and then it was dropped because the owner said 
> > it wasn't really considered a feature... 
> 
> I hope that the nicely done F8 release summary will really drive home
> the value of doing the feature tracking and more people will come
> forward to do some advertising for the stuff they are doing.
> Just comparing the numbers, the recently published feature list for the
> next Ubuntu release was some 130 items long, while I currently see ~10
> items in CategoryFeatureFedora9. Admittedly, there is probably some 75%
> or so in the Ubuntu list that is just hot air or nice ideas that will
> never get done, but still...

I also suspect that our list is just gearing up as we only _just_
finished the release as of late Friday :-)  And there's another ~ 25-30
in CategoryProposedFeature.  I think we'll end up with a pretty healthy
list for Fedora 9.

Jeremy



From aphukan at fedoraproject.org  Tue Nov  6 04:59:43 2007
From: aphukan at fedoraproject.org (Amitakhya Phukan)
Date: Tue, 06 Nov 2007 10:29:43 +0530
Subject: file system mount
In-Reply-To: <1193942501.7233.10.camel@localhost.localdomain>
References: <47297920.60509@fedoraproject.org>
	<1193942501.7233.10.camel@localhost.localdomain>
Message-ID: <472FF4BF.1040407@fedoraproject.org>

David Zeuthen wrote:
>
> Rawhide only mounts fixed drives only when you login and only if you put
> in the root password and don't unclick the "Remember authorization"
> check box. Like this
>
>  http://people.freedesktop.org/~david/pk-gnome-mount.png
>
> so it's most likely your own doing. There's no good UI in Rawhide/F8 for
> doing it except 'polkit-grant --delete <username>' as the super user.
> For F9 there will be a GNOME UI for managing these authorizations as
> well as the defaults; work-in-progress looks like this
>
>  http://people.freedesktop.org/~david/polkit-gnome-authorizations.png
>
> but the UI is likely to change.
>
> Hope this helps.
>
>       David
>
>  
>
>
>   
hi david,

sorry for the late feedback.. i was out of office for sometime and hence
didn't access my mails.

> Rawhide only mounts fixed drives only when you login and only if you put
> in the root password and don't unclick the "Remember authorization"
> check box. Like this
>
>  http://people.freedesktop.org/~david/pk-gnome-mount.png
>
> so it's most likely your own doing.
no it was not my doing.. what i did was i pointed my repositories to a
local rawhide sync tree and then i did a yum -y update. i never have
seen the screen you have mentioned in the above URL. Moreover, I have
never logged in as root (well, except for su - )and I clearly have not
used the "Keep/Forget authorisation" thing since Fedora 1.I just wanted
to know what is doing this thing, and if it is a feature of rawhide
*only*, I don't have any problems..I can wait for the stable release of
F8..

btw, that again makes me think...what feature is enabled/disabled in
rawhide and stable release and why ??

just some thoughts..

regards,
amit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aphukan.vcf
Type: text/x-vcard
Size: 216 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/50e6da7e/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/50e6da7e/attachment.sig>

From trond.danielsen at gmail.com  Tue Nov  6 07:29:14 2007
From: trond.danielsen at gmail.com (Trond Danielsen)
Date: Tue, 6 Nov 2007 08:29:14 +0100
Subject: Fedora 8 on Asus S5A;
	asus_laptop parameters and wireless enable/disable function key
In-Reply-To: <1194306581.13432.16.camel@hughsie-laptop>
References: <409676c70711040324o1734104ex40893056c72bc55d@mail.gmail.com>
	<1194274821.18807.18.camel@localhost.localdomain>
	<1194306581.13432.16.camel@hughsie-laptop>
Message-ID: <409676c70711052329mee0a1edu1f17b1ad39c2bd3b@mail.gmail.com>

2007/11/6, Richard Hughes <hughsient at gmail.com>:
> On Mon, 2007-11-05 at 10:00 -0500, Dan Williams wrote:
> > Furthermore, the asus_laptop module should support the rfkill
> > framework that's already in the kernel in 2.6.23.
>
> Totally agree, this is where this functionality belongs.
>
> Richard.

I'll take a closer look at the asus_laptop module and the rfkill
framework and either come up with a patch or send a bugreport to the
upstream project.

Thanks for the feedback.

-- 
Trond Danielsen



From jonathan at jonmasters.org  Tue Nov  6 07:32:48 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Tue, 06 Nov 2007 02:32:48 -0500
Subject: F9 Feature Process
In-Reply-To: <1194309938.7067.4.camel@localhost.localdomain>
References: <47293CBF.7020900@redhat.com>
	<1193888060.4875.24.camel@localhost.localdomain>
	<472FB749.8030602@redhat.com>
	<1194309938.7067.4.camel@localhost.localdomain>
Message-ID: <1194334368.27842.96.camel@perihelion>

On Mon, 2007-11-05 at 19:45 -0500, Matthias Clasen wrote:

> I hope that the nicely done F8 release summary will really drive home
> the value of doing the feature tracking and more people will come
> forward to do some advertising for the stuff they are doing.
> Just comparing the numbers, the recently published feature list for the
> next Ubuntu release was some 130 items long, while I currently see ~10
> items in CategoryFeatureFedora9. Admittedly, there is probably some 75%
> or so in the Ubuntu list that is just hot air or nice ideas that will
> never get done, but still...

* 131). Send all the developers into space at least once.

:-)

Jon.




From pertusus at free.fr  Tue Nov  6 08:32:51 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 6 Nov 2007 09:32:51 +0100
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.6,1.7 sources,1.7,1.8
In-Reply-To: <200711060029.lA60TS3a017114@cvs-int.fedora.redhat.com>
References: <200711060029.lA60TS3a017114@cvs-int.fedora.redhat.com>
Message-ID: <20071106083251.GD2616@free.fr>

On Mon, Nov 05, 2007 at 07:29:28PM -0500, Bernardo Innocenti wrote:
> @@ -1 +1,2 @@
>  f64cae9acc5961afb4bf7c6fc985ff18  olpc-utils-0.33.tar.bz2
> +ca2a83b5d4b34e66298a1262a84d6e95  olpc-utils-0.41.tar.bz2

This is still not fixed? I warned a week ago.

--
Pat



From kzak at redhat.com  Tue Nov  6 10:33:53 2007
From: kzak at redhat.com (Karel Zak)
Date: Tue, 6 Nov 2007 11:33:53 +0100
Subject: file system mount
In-Reply-To: <1194031136.25712.21.camel@oneill.fubar.dk>
References: <47297920.60509@fedoraproject.org>
	<loom.20071101T152643-909@post.gmane.org>
	<1193972210.13091.5.camel@localhost.localdomain>
	<1194029275.25712.13.camel@oneill.fubar.dk>
	<472B7775.1090603@gmail.com>
	<1194031136.25712.21.camel@oneill.fubar.dk>
Message-ID: <20071106103353.GQ2871@petra.dvoda.cz>

On Fri, Nov 02, 2007 at 03:18:56PM -0400, David Zeuthen wrote:
> 
> On Fri, 2007-11-02 at 14:16 -0500, Les Mikesell wrote:
> > David Zeuthen wrote:
> > > 
> > > [1] : We could be more creative and try to guess what the file system is
> > > used for; e.g. look for /etc/fedora-release, /etc/debian_release and so
> > > forth (including trying to guess if it's Windows XP, Mac OS X or
> > > whatever). So instead of showing "/" we could show "Fedora Core 7
> > > (Moonshine)". That approach has it's ups and downs (guess is dangerous)
> > > thus why it's not implemented at this point.
> > 
> > How about giving a hint as to which _physical_ disk it is?  Imagine you 
> > had a couple of scsi controllers each with a bunch of disks, plus some 
> > sata and USB volumes and you add one (which might currently have labels 
> > that match other drives) and want to format it.  Which one is it?  Or a 
> > drive in the system fails and isn't detected.  How do you find which one
> > it was?
> 
> You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..

 Don't use device names at all. I think better for LABEL= is an unique
 system ID + path.  Something like LABEL="FooSys:/boot".

> Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit
> most of this before F9 as part of the gio/gvfs hacking. Stay tuned!
> 
> > > [2] : This is a rant to the Anaconda team. It is beyond me why you guys
> > > decided to use LABEL= when UUID= is available for ext2/ext3 like since
> > > forever. Another complaint is the name chosen for the file systems;
> > > instead of e.g. "/" maybe you could use "F8-/", "F8-/var/www" etc. I
> > > know this screws people on updates but at least these people could
> > > rename the labels (e.g. from "F8-/" to "F9-/") when they upgrade. Or
> > > Anaconda could prompt the user. Thanks for looking into this.

 I think Anaconda could prompt the user for an unique ID rather than
 use the same prefix (F8, F9, ...) for all installations on the Earth.
 Don't forget that you can move HDD between more systems.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From triad at df.lth.se  Tue Nov  6 11:23:29 2007
From: triad at df.lth.se (Linus Walleij)
Date: Tue, 6 Nov 2007 12:23:29 +0100 (CET)
Subject: Removal of pam_console questions
Message-ID: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>

I read this some time ago:
http://fedoraproject.org/wiki/Releases/FeatureRemovePAMConsole

I guess libmtp and libnjb which I maintain need to be updated to work with 
HAL ACLs. They both create a node /dev/libxxx-nnn and place a file in 
/etc/security/console.perms.d/ each, like this:

<libnjb>=/dev/libnjb*
<console> 0600 <libnjb> 0600 root

However I am not certain as to how one migrate to HAL+ACLs for this, can 
someone point to a package which is properly migrated already and tell 
how it's basically done so I can have a look and fix this?

(If you wanna hack the packages in CVS since you think it's quicker to 
just do it than explain how to do it, then just go ahead...)

Linus



From stransky at redhat.com  Tue Nov  6 11:29:43 2007
From: stransky at redhat.com (Martin Stransky)
Date: Tue, 06 Nov 2007 12:29:43 +0100
Subject: New firefox-2.0.0.9 in F7/F8/Rawhide
Message-ID: <47305027.3030904@redhat.com>

There's a new firefox 2.0.0.9 (gecko-libs 1.8.1.9) in Fedora build 
roots. Please rebuild your packages.



From buildsys at redhat.com  Tue Nov  6 11:55:31 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 6 Nov 2007 06:55:31 -0500
Subject: rawhide report: 20071106 changes
Message-ID: <200711061155.lA6BtVrE013194@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From tmz at pobox.com  Tue Nov  6 12:25:39 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 6 Nov 2007 07:25:39 -0500
Subject: rpms/diffutils/F-8 diffutils-2.8.4-i18n.patch, 1.2, 1.3
	diffutils.spec, 1.22, 1.23
In-Reply-To: <200711061213.lA6CD0G4031253@cvs-int.fedora.redhat.com>
References: <200711061213.lA6CD0G4031253@cvs-int.fedora.redhat.com>
Message-ID: <20071106122539.GD2295@psilocybe.teonanacatl.org>

Tim Waugh wrote:
> Update of /cvs/pkgs/rpms/diffutils/F-8
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31229
> 
> Modified Files:
> 	diffutils-2.8.4-i18n.patch diffutils.spec 
> Log Message:
> * Tue Nov  6 2007 Tim Waugh <twaugh at redhat.com> 2.8.1-18
> - Fixed multibyte speed improvement patch (bug #363381).

I think you mean bug #363831. :)

Bug #363381 is: "gnome-python2-gtkmozembed needs to be rebuilt against
firefox-2.0.0.8-1.fc7"

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my life, I have prayed but one prayer: oh Lord, make my enemies
ridiculous. And God granted it.
    -- Voltaire

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/8fe08027/attachment.sig>

From jkeating at redhat.com  Tue Nov  6 14:00:13 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 6 Nov 2007 09:00:13 -0500
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.6,1.7 sources,1.7,1.8
In-Reply-To: <20071106083251.GD2616@free.fr>
References: <200711060029.lA60TS3a017114@cvs-int.fedora.redhat.com>
	<20071106083251.GD2616@free.fr>
Message-ID: <20071106090013.7e006ad8@redhat.com>

On Tue, 6 Nov 2007 09:32:51 +0100
Patrice Dumas <pertusus at free.fr> wrote:

> On Mon, Nov 05, 2007 at 07:29:28PM -0500, Bernardo Innocenti wrote:
> > @@ -1 +1,2 @@
> >  f64cae9acc5961afb4bf7c6fc985ff18  olpc-utils-0.33.tar.bz2
> > +ca2a83b5d4b34e66298a1262a84d6e95  olpc-utils-0.41.tar.bz2
> 
> This is still not fixed? I warned a week ago.
> 
> --
> Pat
> 


Are you sending it directly to Bernardo?  He may not be on this list.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/6699f1ab/attachment.sig>

From lkundrak at redhat.com  Tue Nov  6 13:12:00 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 06 Nov 2007 14:12:00 +0100
Subject: Infinity theme for gdm removed from Fedora?
In-Reply-To: <fgnmnm$p76$1@ger.gmane.org>
References: <fgnmnm$p76$1@ger.gmane.org>
Message-ID: <1194354720.7729.34.camel@localhost.localdomain>


On Mon, 2007-11-05 at 19:17 +0100, Marcin Zaj?czkowski wrote:
> Hi,
> 
> 
> In Fedora 8 Test3 the default theme for gdm (login screen) is Infinity.
> One of the available updates removes it completely (after restart there
> is an error message about missing files and in fact those files are
> missing).
> Was it intended to remove that theme?

I guess not. Do you have an idea which package did remove it. Do you
have a log?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From pertusus at free.fr  Tue Nov  6 13:30:14 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 6 Nov 2007 14:30:14 +0100
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.6,1.7 sources,1.7,1.8
In-Reply-To: <20071106090013.7e006ad8@redhat.com>
References: <200711060029.lA60TS3a017114@cvs-int.fedora.redhat.com>
	<20071106083251.GD2616@free.fr>
	<20071106090013.7e006ad8@redhat.com>
Message-ID: <20071106133013.GF2616@free.fr>

On Tue, Nov 06, 2007 at 09:00:13AM -0500, Jesse Keating wrote:
> On Tue, 6 Nov 2007 09:32:51 +0100
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > On Mon, Nov 05, 2007 at 07:29:28PM -0500, Bernardo Innocenti wrote:
> > > @@ -1 +1,2 @@
> > >  f64cae9acc5961afb4bf7c6fc985ff18  olpc-utils-0.33.tar.bz2
> > > +ca2a83b5d4b34e66298a1262a84d6e95  olpc-utils-0.41.tar.bz2
> > 
> > This is still not fixed? I warned a week ago.
> 
> Are you sending it directly to Bernardo?  He may not be on this list.

I am sending where a reply to the commit mail sends.

--
Pat



From bernie at codewiz.org  Tue Nov  6 13:48:01 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Tue, 06 Nov 2007 08:48:01 -0500
Subject: rpms/olpc-utils/OLPC-2 .cvsignore,1.6,1.7 sources,1.7,1.8
In-Reply-To: <20071106090013.7e006ad8@redhat.com>
References: <200711060029.lA60TS3a017114@cvs-int.fedora.redhat.com>	<20071106083251.GD2616@free.fr>
	<20071106090013.7e006ad8@redhat.com>
Message-ID: <47307091.8050007@codewiz.org>

On 11/06/07 09:00, Jesse Keating wrote:
> On Tue, 6 Nov 2007 09:32:51 +0100
> Patrice Dumas <pertusus at free.fr> wrote:
> 
>> On Mon, Nov 05, 2007 at 07:29:28PM -0500, Bernardo Innocenti wrote:
>>> @@ -1 +1,2 @@
>>>  f64cae9acc5961afb4bf7c6fc985ff18  olpc-utils-0.33.tar.bz2
>>> +ca2a83b5d4b34e66298a1262a84d6e95  olpc-utils-0.41.tar.bz2
>> This is still not fixed? I warned a week ago.
>
> Are you sending it directly to Bernardo?  He may not be on this list.

I'm subscribed, but I don't read every single thread and failed
to notice Patrice's observations.  This list munges the Reply-To
header, so please add me to Cc to make sure I notice your future
reviews.

Patrice, yesterday I noticed this problem myself and fixed
it right here:

 revision 1.8
 date: 2007/11/06 00:46:43;  author: bernie;  state: Exp;  lines: +0 -5
 Kill off all the old source tarballs.

I've also just learned about "make new-sources".  Previously,
I was stupidly using "make upload" to update my tarballs!
Please, forgive this newbie packager :-)

I've also spotted additional comments on the source tarball,
which I will address with the next round of changes.
Thank you for your review.

Moreover, after 5-6 iterations, I'm starting to feel the urge
to automate my work-flow from patching the source to pushing
the binary rpms a little more.  That would solve another
class of mistakes caused by distraction, and would remove
the tedious part of maintaining packages.  Are there some
quick automake macros for generating spec files from
configure.ac?  And maybe a recipes for extracting the log
file from git's log?

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From bernie at codewiz.org  Tue Nov  6 14:29:49 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Tue, 06 Nov 2007 09:29:49 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1194294608.15341.204.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
Message-ID: <47307A5D.4020607@codewiz.org>

On 11/05/07 15:30, Adam Jackson wrote:

> This server will also introduce input hotplug support.  TBH I have no
> idea how this should be set up at the moment.  I'll try to get something
> working at least for the machines I have here, but that might only be
> good enough for static configuration same as F8 and earlier.  If someone
> wants to own the i-h part of this that'd be awesome, otherwise we'll get
> to it as we have time.

Maybe I could help here.  I added input hotplug support
for Xserver 1.4 on the OLPC not long ago.

The package changes are not in CVS because I'm still
overwhelmed by other urgent work, but all the srpms are
available for reference here:

  http://www.codewiz.org/pub/olpc-bernie/source/

Forgive me stuffing x11-input.fdi in the Xserver package
and installing it to /etc/hal/fdi.  That was just a kludge
to avoid modifying hal too.

It took me a while to get i-h right because I had no idea
what was needed, and I was also confused by longstanding
bugs in our kernel drivers, but in retrospect it didn't
take that much tweaking, at least for our fixed platform.

One non trivial change for Fedora would be moving the kbd
config away from xorg.conf.  Both Gnome and KDE can already
override the server settings through XKB.  The various
display managers, I'm afraid, don't do anything by default.
Same with startx.

The X server also supports receiving XKB configuration from
HAL, and Daniel Stone seems to think that a good design for a
fallback would be writing the default keyboard layout inside
a copy of x11-input.fdi and writing it to /etc/hal/fdi/.

We should also consider adjusting also system-config-keyboard
accordingly.

Also, I'm not sure if this is a good right time to do it, but
we may benefit from switching to evdev for mice and keyboards,
if only to put let that horrible /dev/input/mice and its
emulated PS/2 protocol rest in peace :-)


> I think those are the highlights.  If there are any further questions,
> please ask, I may have missed something.  If any bugs come up in the
> transition, please do file them!  We need to know what breaks so we know
> what we need to fix.  And of course, all patches and assistance are
> greatly appreciated.

That's great work.  I'm Looking forward to see it landing on
rawhide!

My only rawhide machine is a G4 laptop at home, and my time
to contribute is very limited.  So I can't do much more
than testing and answering questions on IRC.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From nicolas.mailhot at laposte.net  Tue Nov  6 15:00:11 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 6 Nov 2007 16:00:11 +0100 (CET)
Subject: Severe X breakage heads up
Message-ID: <39403.192.54.193.53.1194361211.squirrel@rousalka.dyndns.org>


Le Mar 6 novembre 2007 15:29, Bernardo Innocenti a ?crit :

> Also, I'm not sure if this is a good right time to do it, but
> we may benefit from switching to evdev for mice and keyboards,
> if only to put let that horrible /dev/input/mice and its
> emulated PS/2 protocol rest in peace :-)

+20

95% of the user-reported problems with evdev are due to the user
switching himself and failing to do it properly (because switching to
evdev requires setting an awful lot of xorg parameters to "evdev", and
if you forget to change one xorg won't fail cleanly but work in a
strange hybrid buggy PS/2+evdev input mode, and users will assume this
buggy mode is evdev itself).

Just switching to evdev can fix an awful lot of multimedia key problem
reports.

-- 
Nicolas Mailhot
Who finaly found the last evdev directive to add so up
is not printscreen



From dwalsh at redhat.com  Tue Nov  6 15:16:33 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 06 Nov 2007 10:16:33 -0500
Subject: Updating selinux-policy-targeted Causes SELinux Denials
In-Reply-To: <1194023411.10665.6.camel@localhost6.localdomain6>
References: <1194023411.10665.6.camel@localhost6.localdomain6>
Message-ID: <47308551.5060200@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richi Plana wrote:
> Hi,
> 
> Should I be concerned that every time an update to
> selinux-policy-targeted occurs, it causes actions that the current
> running SELinux seems to prevent? I'm talking about SELinux
> preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
> (restorecon_t) "write"ing to a pipe with label "rpm_t".
> 
> Are these actions legal? And does SELinux preventing them cause an error
> in the actual install? Or should these just be treated as warnings?
> 
> I'm guessing that the selinux applications are just trying to
> communicate back to the RPM process. I'm wondering if there's anything
> important in that communication that should be allowed, or if not, there
> must be some way to clean this up.
> 
> (If this isn't the right place to ask, could someone redirect me to the
> correct one?)
> --
> 
> Richi Plana
> 
No,  I am hoping to eliminate a lot of these in the future.  What these
avc's are referring to is the redirection of stdout/stderr.  When rpm is
running an update it redirects the terminal output to its fifo_files. So
any confined domain that runs as part of a post install script will
check whether it has access to stdin, stdout, stderr on the terminal or
whatever is acting as the terminal.  Since these confined domains do not
have policy allowing them to talk to pipes owned by rpm, the kernel
generates avc messages and closes the file descriptors and replaces them
with open file descriptors to /dev/null.  The apps will continue running
and complete successfully, but ugly avc messages are generated.  In
Updates to policy I am going to globally start dontauditing these access.


# Allow all domains to use fds past to them
allow domain domain:fd use;
optional_policy(`
	rpm_dontaudit_rw_pipes(domain)
')

Should be in Fedora 8 and beyond as well as in the next update to Fedora 7.

Redirection of Stdout/Stderr account for the largest percentage of
SELinux AVC's and most are just noice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHMIVQrlYvE4MpobMRAt+6AJ0UGeJjIz94iqDNM5HHGsuCJGJgrgCgqpWK
0eaM8OKv3PG2x+sVXLV9Tl4=
=Fh29
-----END PGP SIGNATURE-----



From dwalsh at redhat.com  Tue Nov  6 15:27:41 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 06 Nov 2007 10:27:41 -0500
Subject: NFS Update and SELinux
In-Reply-To: <1193941654.3848.5.camel@localhost6.localdomain6>
References: <1193856288.12145.9.camel@localhost6.localdomain6>	<472A13D9.4010105@redhat.com>
	<1193941654.3848.5.camel@localhost6.localdomain6>
Message-ID: <473087ED.7020101@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richi Plana wrote:
> Hi, Daniel.
> 
> On Thu, 2007-11-01 at 13:58 -0400, Daniel J Walsh wrote:
>> Please attach avc messages?
>>
>> These devices should be labeled usb_device_t
> 
> Thanks for the tip.
> 
> Well, after reading your email, I checked the context and it's
> definitely labeled "device_t". I looked at my selinux file_contexts and
> the closest match for /dev/usbmon? was /dev/.* (which gave it a context
> of device_t).
> 
> More info:
> 
> selinux-policy-targeted-2.6.4-48.fc7
> 
> I haven't edited it. And:
> 
> # ll -Z /dev/usb*
> lrwxrwxrwx  root root
> system_u:object_r:device_t       /dev/usbdev1.1_ep00 ->
> bus/usb/1/1_ep/00
> lrwxrwxrwx  root root
> system_u:object_r:device_t       /dev/usbdev1.1_ep81 ->
> bus/usb/1/1_ep/81
> lrwxrwxrwx  root root
> system_u:object_r:device_t       /dev/usbdev1.2_ep00 ->
> bus/usb/1/2_ep/00
> lrwxrwxrwx  root root
> system_u:object_r:device_t       /dev/usbdev1.2_ep81 ->
> bus/usb/1/2_ep/81
> lrwxrwxrwx  root root
> system_u:object_r:device_t       /dev/usbdev2.1_ep00 ->
> bus/usb/2/1_ep/00
> lrwxrwxrwx  root root
> system_u:object_r:device_t       /dev/usbdev2.1_ep81 ->
> bus/usb/2/1_ep/81
> crw-------  root root system_u:object_r:device_t       /dev/usbmon0
> crw-------  root root system_u:object_r:device_t       /dev/usbmon1
> crw-------  root root system_u:object_r:device_t       /dev/usbmon2
> 
> FYI.
> 
> Thanks!
> --
> 
> Richi Plana
> 
Ok please update to the latest fc7 policy.
selinux-policy-2.6.4-53.fc7 is in testing.

I definitely see a path match for this in there.

grep usbmon policy-20070501.patch
+/dev/usbmon[0-9]+      -c
gen_context(system_u:object_r:usb_device_t,s0)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHMIftrlYvE4MpobMRAkgdAKCm8fRWlWQDWUmkMDHvGRNdk1+CfwCfXlJg
PJ6V75ukrSeM2iwOwX0rvoI=
=up/s
-----END PGP SIGNATURE-----



From mclasen at redhat.com  Tue Nov  6 15:24:34 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 06 Nov 2007 10:24:34 -0500
Subject: Severe X breakage heads up
In-Reply-To: <47307A5D.4020607@codewiz.org>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
Message-ID: <1194362674.3963.10.camel@localhost.localdomain>


On Tue, 2007-11-06 at 09:29 -0500, Bernardo Innocenti wrote:

> 
> One non trivial change for Fedora would be moving the kbd
> config away from xorg.conf.  Both Gnome and KDE can already
> override the server settings through XKB.  The various
> display managers, I'm afraid, don't do anything by default.
> Same with startx.

This will change soon for gdm, I think. The gdm rewrite will make it
possible to have a keyboard layout selector on the login screen, very
similar to what you have inside the session. At least that is one of the
goals.

> Also, I'm not sure if this is a good right time to do it, but
> we may benefit from switching to evdev for mice and keyboards,
> if only to put let that horrible /dev/input/mice and its
> emulated PS/2 protocol rest in peace :-)

Switching to evdev is also planned for F9, and will probably be part of
the "big breakage".



From notting at redhat.com  Tue Nov  6 15:39:26 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 6 Nov 2007 10:39:26 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1194294608.15341.204.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
Message-ID: <20071106153926.GA12526@nostromo.devel.redhat.com>

Adam Jackson (ajackson at redhat.com) said: 
> This X server requires libpciaccess.  Not all of the drivers have been
> ported yet.  Not all of them will be ported by Monday, though I'll try
> to have the big three of {radeon,intel,nv} and the vesa driver converted
> by then.  This should cover most people.  I hope.

Is there any reason to do the rebase until this is done for
radeon/intel/nv?

Bill



From stransky at redhat.com  Tue Nov  6 15:45:27 2007
From: stransky at redhat.com (Martin Stransky)
Date: Tue, 06 Nov 2007 16:45:27 +0100
Subject: New firefox-2.0.0.9 in F7/F8/Rawhide
Message-ID: <47308C17.6010600@redhat.com>

There's a new firefox 2.0.0.9 (gecko-libs 1.8.1.9) in Fedora build
roots. Please rebuild your packages.



From ajackson at redhat.com  Tue Nov  6 15:21:27 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 06 Nov 2007 10:21:27 -0500
Subject: Severe X breakage heads up
In-Reply-To: <20071106153926.GA12526@nostromo.devel.redhat.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<20071106153926.GA12526@nostromo.devel.redhat.com>
Message-ID: <1194362487.15341.212.camel@localhost.localdomain>

On Tue, 2007-11-06 at 10:39 -0500, Bill Nottingham wrote:
> Adam Jackson (ajackson at redhat.com) said: 
> > This X server requires libpciaccess.  Not all of the drivers have been
> > ported yet.  Not all of them will be ported by Monday, though I'll try
> > to have the big three of {radeon,intel,nv} and the vesa driver converted
> > by then.  This should cover most people.  I hope.
> 
> Is there any reason to do the rebase until this is done for
> radeon/intel/nv?

No.  I should have phrased this better: the rebase won't happen until
those are done.  But I expect that'll be Monday.

- ajax



From paul at city-fan.org  Tue Nov  6 16:19:11 2007
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 06 Nov 2007 16:19:11 +0000
Subject: Updating selinux-policy-targeted Causes SELinux Denials
In-Reply-To: <47308551.5060200@redhat.com>
References: <1194023411.10665.6.camel@localhost6.localdomain6>
	<47308551.5060200@redhat.com>
Message-ID: <473093FF.9040703@city-fan.org>

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Richi Plana wrote:
>> Hi,
>>
>> Should I be concerned that every time an update to
>> selinux-policy-targeted occurs, it causes actions that the current
>> running SELinux seems to prevent? I'm talking about SELinux
>> preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
>> (restorecon_t) "write"ing to a pipe with label "rpm_t".
>>
>> Are these actions legal? And does SELinux preventing them cause an error
>> in the actual install? Or should these just be treated as warnings?
>>
>> I'm guessing that the selinux applications are just trying to
>> communicate back to the RPM process. I'm wondering if there's anything
>> important in that communication that should be allowed, or if not, there
>> must be some way to clean this up.
>>
>> (If this isn't the right place to ask, could someone redirect me to the
>> correct one?)
>> --
>>
>> Richi Plana
>>
> No,  I am hoping to eliminate a lot of these in the future.  What these
> avc's are referring to is the redirection of stdout/stderr.  When rpm is
> running an update it redirects the terminal output to its fifo_files. So
> any confined domain that runs as part of a post install script will
> check whether it has access to stdin, stdout, stderr on the terminal or
> whatever is acting as the terminal.  Since these confined domains do not
> have policy allowing them to talk to pipes owned by rpm, the kernel
> generates avc messages and closes the file descriptors and replaces them
> with open file descriptors to /dev/null.  The apps will continue running
> and complete successfully, but ugly avc messages are generated.  In
> Updates to policy I am going to globally start dontauditing these access.
> 
> 
> # Allow all domains to use fds past to them
> allow domain domain:fd use;
> optional_policy(`
> 	rpm_dontaudit_rw_pipes(domain)
> ')
> 
> Should be in Fedora 8 and beyond as well as in the next update to Fedora 7.
> 
> Redirection of Stdout/Stderr account for the largest percentage of
> SELinux AVC's and most are just noice.

The net effect of this is to throw away any scriptlet output (e.g. error 
messages), isn't it? Whilst people running a GUI update tool won't see 
these anyway, us luddites that still use yum from the command line so as 
to see if there are any problems during an update won't be able to see 
this output.

Yes, I know that this doesn't represent a change from current policy; I 
usually add local policy to allow this output when I see the avcs, but 
if they're dontaudited then I won't see any hint of there being a problem.

Paul.



From bpepple at fedoraproject.org  Tue Nov  6 16:22:43 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 06 Nov 2007 11:22:43 -0500
Subject: New firefox-2.0.0.9 in F7/F8/Rawhide
In-Reply-To: <47305027.3030904@redhat.com>
References: <47305027.3030904@redhat.com>
Message-ID: <1194366163.1748.9.camel@nixon>

On Tue, 2007-11-06 at 12:29 +0100, Martin Stransky wrote:
> There's a new firefox 2.0.0.9 (gecko-libs 1.8.1.9) in Fedora build 
> roots. Please rebuild your packages.

Thanks for the heads up.

/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/e5615c2a/attachment.sig>

From ndbecker2 at gmail.com  Tue Nov  6 16:32:07 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 06 Nov 2007 11:32:07 -0500
Subject: ERROR: You can not forcibly move tags between branches
Message-ID: <fgq4u7$1no$1@ger.gmane.org>

Trying to update uncrustify package from upstream.
Got devel done OK, but trying to update F-8 I get:

make tag build
cvs diff: [16:29:48] obtained lock in /cvs/pkgs/rpms/uncrustify/F-8
[nbecker at nbecker1 F-8]$ cvs tag  -c uncrustify-0_40-1_fc8
ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different branch
ERROR: You can not forcibly move tags between branches
uncrustify-0_30-1:devel:nbecker:1167579422
uncrustify-0_30-1_fc7:devel:nbecker:1167851084
uncrustify-0_30-1_fc5:FC-5:nbecker:1167851116
uncrustify-0_30-1_fc6:FC-6:nbecker:1167851121
uncrustify-0_35-1_fc8:devel:nbecker:1184943650
uncrustify-0_35-1_fc7:F-7:nbecker:1184944278
uncrustify-0_35-1_fc7:F-7:nbecker:1184946102
uncrustify-0_35-1_fc7:F-7:nbecker:1184949990
uncrustify-0_35-1_fc7:F-7:nbecker:1184966044
uncrustify-0_35-2_fc8:devel:jkeating:1188364241
uncrustify-0_40-1_fc8:devel:nbecker:1194365909
uncrustify-0_40-1_fc8:devel:nbecker:1194366260
uncrustify-0_40-1_fc8:devel:nbecker:1194366320
uncrustify-0_40-1_fc9:devel:nbecker:1194366430
cvs tag: Pre-tag check failed
cvs [tag aborted]: correct the above errors first!
make: *** [tag] Error 1




From jeff at ocjtech.us  Tue Nov  6 16:36:30 2007
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 6 Nov 2007 10:36:30 -0600
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <fgq4u7$1no$1@ger.gmane.org>
References: <fgq4u7$1no$1@ger.gmane.org>
Message-ID: <935ead450711060836x2222b9a1j49c80e0a7f67b979@mail.gmail.com>

You need to update your "common" directory and re-tag/re-build. When you
updated the "devel" branch the scripts in your old "common" directory
created a tag with the "fc8" tag.

On 11/6/07, Neal Becker <ndbecker2 at gmail.com> wrote:
>
> Trying to update uncrustify package from upstream.
> Got devel done OK, but trying to update F-8 I get:
>
> make tag build
> cvs diff: [16:29:48] obtained lock in /cvs/pkgs/rpms/uncrustify/F-8
> [nbecker at nbecker1 F-8]$ cvs tag  -c uncrustify-0_40-1_fc8
> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different
> branch
> ERROR: You can not forcibly move tags between branches
> uncrustify-0_30-1:devel:nbecker:1167579422
> uncrustify-0_30-1_fc7:devel:nbecker:1167851084
> uncrustify-0_30-1_fc5:FC-5:nbecker:1167851116
> uncrustify-0_30-1_fc6:FC-6:nbecker:1167851121
> uncrustify-0_35-1_fc8:devel:nbecker:1184943650
> uncrustify-0_35-1_fc7:F-7:nbecker:1184944278
> uncrustify-0_35-1_fc7:F-7:nbecker:1184946102
> uncrustify-0_35-1_fc7:F-7:nbecker:1184949990
> uncrustify-0_35-1_fc7:F-7:nbecker:1184966044
> uncrustify-0_35-2_fc8:devel:jkeating:1188364241
> uncrustify-0_40-1_fc8:devel:nbecker:1194365909
> uncrustify-0_40-1_fc8:devel:nbecker:1194366260
> uncrustify-0_40-1_fc8:devel:nbecker:1194366320
> uncrustify-0_40-1_fc9:devel:nbecker:1194366430
> cvs tag: Pre-tag check failed
> cvs [tag aborted]: correct the above errors first!
> make: *** [tag] Error 1
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/bb988e24/attachment.htm>

From limb at jcomserv.net  Tue Nov  6 16:28:58 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 6 Nov 2007 10:28:58 -0600 (CST)
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <fgq4u7$1no$1@ger.gmane.org>
References: <fgq4u7$1no$1@ger.gmane.org>
Message-ID: <29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>



> Trying to update uncrustify package from upstream.
> Got devel done OK, but trying to update F-8 I get:
>
> make tag build
> cvs diff: [16:29:48] obtained lock in /cvs/pkgs/rpms/uncrustify/F-8
> [nbecker at nbecker1 F-8]$ cvs tag  -c uncrustify-0_40-1_fc8
> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different
> branch
> ERROR: You can not forcibly move tags between branches
> uncrustify-0_30-1:devel:nbecker:1167579422
> uncrustify-0_30-1_fc7:devel:nbecker:1167851084
> uncrustify-0_30-1_fc5:FC-5:nbecker:1167851116
> uncrustify-0_30-1_fc6:FC-6:nbecker:1167851121
> uncrustify-0_35-1_fc8:devel:nbecker:1184943650
> uncrustify-0_35-1_fc7:F-7:nbecker:1184944278
> uncrustify-0_35-1_fc7:F-7:nbecker:1184946102
> uncrustify-0_35-1_fc7:F-7:nbecker:1184949990
> uncrustify-0_35-1_fc7:F-7:nbecker:1184966044
> uncrustify-0_35-2_fc8:devel:jkeating:1188364241
> uncrustify-0_40-1_fc8:devel:nbecker:1194365909
> uncrustify-0_40-1_fc8:devel:nbecker:1194366260
> uncrustify-0_40-1_fc8:devel:nbecker:1194366320
> uncrustify-0_40-1_fc9:devel:nbecker:1194366430
> cvs tag: Pre-tag check failed
> cvs [tag aborted]: correct the above errors first!
> make: *** [tag] Error 1

Re-tag in f-8 with "TAG_OPTS=-F make tag", should fix it.  Should be OK
since youve got the f9 tag in devel already.

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From limb at jcomserv.net  Tue Nov  6 16:30:08 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 6 Nov 2007 10:30:08 -0600 (CST)
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <935ead450711060836x2222b9a1j49c80e0a7f67b979@mail.gmail.com>
References: <fgq4u7$1no$1@ger.gmane.org>
	<935ead450711060836x2222b9a1j49c80e0a7f67b979@mail.gmail.com>
Message-ID: <31221.63.85.68.164.1194366608.squirrel@mail.jcomserv.net>


> You need to update your "common" directory and re-tag/re-build. When you
> updated the "devel" branch the scripts in your old "common" directory
> created a tag with the "fc8" tag.

Yeah, that too.  I forgot, I did rm -rf <package> && cvs co <package>
after the branching. . .


-- 
novus ordo absurdum



From ndbecker2 at gmail.com  Tue Nov  6 16:44:50 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 06 Nov 2007 11:44:50 -0500
Subject: ERROR: You can not forcibly move tags between branches
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
Message-ID: <fgq5m2$40u$1@ger.gmane.org>

Jon Ciesla wrote:

[...]
> 
> Re-tag in f-8 with "TAG_OPTS=-F make tag", should fix it.  Should be OK
> since youve got the f9 tag in devel already.
> 

Like this?

TAG_OPTS=-F make tag
cvs tag -F -c uncrustify-0_40-1_fc8
ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different branch
ERROR: You can not forcibly move tags between branches




From limb at jcomserv.net  Tue Nov  6 16:44:38 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 6 Nov 2007 10:44:38 -0600 (CST)
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <fgq5m2$40u$1@ger.gmane.org>
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
	<fgq5m2$40u$1@ger.gmane.org>
Message-ID: <46961.63.85.68.164.1194367478.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>
> [...]
>>
>> Re-tag in f-8 with "TAG_OPTS=-F make tag", should fix it.  Should be OK
>> since youve got the f9 tag in devel already.
>>
>
> Like this?
>
> TAG_OPTS=-F make tag
> cvs tag -F -c uncrustify-0_40-1_fc8
> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different
> branch
> ERROR: You can not forcibly move tags between branches

See message on updating common. . .:)

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From ndbecker2 at gmail.com  Tue Nov  6 16:59:17 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 06 Nov 2007 11:59:17 -0500
Subject: ERROR: You can not forcibly move tags between branches
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
	<fgq5m2$40u$1@ger.gmane.org>
	<46961.63.85.68.164.1194367478.squirrel@mail.jcomserv.net>
Message-ID: <fgq6h5$7oo$1@ger.gmane.org>

Jon Ciesla wrote:

> 
>> Jon Ciesla wrote:
>>
>> [...]
>>>
>>> Re-tag in f-8 with "TAG_OPTS=-F make tag", should fix it.  Should be OK
>>> since youve got the f9 tag in devel already.
>>>
>>
>> Like this?
>>
>> TAG_OPTS=-F make tag
>> cvs tag -F -c uncrustify-0_40-1_fc8
>> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different
>> branch
>> ERROR: You can not forcibly move tags between branches
> 
> See message on updating common. . .:)
> 
Are you sure about this?  I think the problem is that the tag was already
(mistakenly) applied to devel.  Probably because I did the tag in devel
before discovering that I needed to update common.

AFAICT, the only workaround is just bump to 0_40-2.  That's what I did, now
it's building.




From limb at jcomserv.net  Tue Nov  6 17:12:02 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 6 Nov 2007 11:12:02 -0600 (CST)
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <fgq6h5$7oo$1@ger.gmane.org>
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
	<fgq5m2$40u$1@ger.gmane.org>
	<46961.63.85.68.164.1194367478.squirrel@mail.jcomserv.net>
	<fgq6h5$7oo$1@ger.gmane.org>
Message-ID: <11359.63.85.68.164.1194369122.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>
>>
>>> Jon Ciesla wrote:
>>>
>>> [...]
>>>>
>>>> Re-tag in f-8 with "TAG_OPTS=-F make tag", should fix it.  Should be
>>>> OK
>>>> since youve got the f9 tag in devel already.
>>>>
>>>
>>> Like this?
>>>
>>> TAG_OPTS=-F make tag
>>> cvs tag -F -c uncrustify-0_40-1_fc8
>>> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different
>>> branch
>>> ERROR: You can not forcibly move tags between branches
>>
>> See message on updating common. . .:)
>>
> Are you sure about this?  I think the problem is that the tag was already
> (mistakenly) applied to devel.  Probably because I did the tag in devel
> before discovering that I needed to update common.

That's true.  The old common is what caused the invalid fc8 tag to appear
in devel, and the tag -F should have fixed it, I've never had that not
work.

> AFAICT, the only workaround is just bump to 0_40-2.  That's what I did,
> now
> it's building.

Will you be bumping and rebuilding devel also, to avoid an EVR problem?

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From myfedora at richip.dhs.org  Tue Nov  6 17:45:13 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 06 Nov 2007 10:45:13 -0700
Subject: NFS Update and SELinux
In-Reply-To: <473087ED.7020101@redhat.com>
References: <1193856288.12145.9.camel@localhost6.localdomain6>
	<472A13D9.4010105@redhat.com>
	<1193941654.3848.5.camel@localhost6.localdomain6>
	<473087ED.7020101@redhat.com>
Message-ID: <1194371113.4985.3.camel@localhost6.localdomain6>

On Tue, 2007-11-06 at 10:27 -0500, Daniel J Walsh wrote:
> Ok please update to the latest fc7 policy.
> selinux-policy-2.6.4-53.fc7 is in testing.
> 
> I definitely see a path match for this in there.
> 
> grep usbmon policy-20070501.patch
> +/dev/usbmon[0-9]+      -c
> gen_context(system_u:object_r:usb_device_t,s0)

Yes, so did I. I just didn't bother to post. I'm glad to say that it
WORKSFORME, though.

I _WAS_ thinking of asking, however, what sort of actions can be placed
in the %post section of packages which need immediate action? I know
some services restart themselves after package updates (but some don't.
I wonder if this should be made policy). In the case of selinux, would a
kernel module reload solve the mislabeled device files? A restart? (I
did notice that at one point in time, I got an advisory to restart the
computer after a set of updates. I can't remember where or what it was
now)
--

Richi Plana



From caillon at redhat.com  Tue Nov  6 17:52:58 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 06 Nov 2007 18:52:58 +0100
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <fgq4u7$1no$1@ger.gmane.org>
References: <fgq4u7$1no$1@ger.gmane.org>
Message-ID: <4730A9FA.9060007@redhat.com>

Neal Becker wrote:
> Trying to update uncrustify package from upstream.
> Got devel done OK, but trying to update F-8 I get:

You need to cvs update the common/ directory for all packages before 
tagging.  Until you do, they have dist defined to .fc8 so the tag in 
devel was given an f8 tag instead of f9.

You likely committed to devel, tagged, then backed up a level, cvs 
updated to get F-8/ (which also updated common/) and then tried tagging.


> 
> make tag build
> cvs diff: [16:29:48] obtained lock in /cvs/pkgs/rpms/uncrustify/F-8
> [nbecker at nbecker1 F-8]$ cvs tag  -c uncrustify-0_40-1_fc8
> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different branch
> ERROR: You can not forcibly move tags between branches



From ndbecker2 at gmail.com  Tue Nov  6 17:57:07 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 06 Nov 2007 12:57:07 -0500
Subject: ERROR: You can not forcibly move tags between branches
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
	<fgq5m2$40u$1@ger.gmane.org>
	<46961.63.85.68.164.1194367478.squirrel@mail.jcomserv.net>
	<fgq6h5$7oo$1@ger.gmane.org>
	<11359.63.85.68.164.1194369122.squirrel@mail.jcomserv.net>
Message-ID: <fgq9tj$kpf$1@ger.gmane.org>

Jon Ciesla wrote:

> 
>> Jon Ciesla wrote:
>>
>>>
>>>> Jon Ciesla wrote:
>>>>
>>>> [...]
>>>>>
>>>>> Re-tag in f-8 with "TAG_OPTS=-F make tag", should fix it.  Should be
>>>>> OK
>>>>> since youve got the f9 tag in devel already.
>>>>>
>>>>
>>>> Like this?
>>>>
>>>> TAG_OPTS=-F make tag
>>>> cvs tag -F -c uncrustify-0_40-1_fc8
>>>> ERROR: The tag uncrustify-0_40-1_fc8 is already applied on a different
>>>> branch
>>>> ERROR: You can not forcibly move tags between branches
>>>
>>> See message on updating common. . .:)
>>>
>> Are you sure about this?  I think the problem is that the tag was already
>> (mistakenly) applied to devel.  Probably because I did the tag in devel
>> before discovering that I needed to update common.
> 
> That's true.  The old common is what caused the invalid fc8 tag to appear
> in devel, and the tag -F should have fixed it, I've never had that not
> work.
> 
>> AFAICT, the only workaround is just bump to 0_40-2.  That's what I did,
>> now
>> it's building.
> 
> Will you be bumping and rebuilding devel also, to avoid an EVR problem?
> 

I didn't know there would be a problem.  Can I find an description of this
problem somewhere?  Do you mean that the 0_40-2_fc8 would appear to be
newer than the 0_40-1_fc9?



From jkeating at redhat.com  Tue Nov  6 19:03:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 6 Nov 2007 14:03:35 -0500
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <fgq9tj$kpf$1@ger.gmane.org>
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
	<fgq5m2$40u$1@ger.gmane.org>
	<46961.63.85.68.164.1194367478.squirrel@mail.jcomserv.net>
	<fgq6h5$7oo$1@ger.gmane.org>
	<11359.63.85.68.164.1194369122.squirrel@mail.jcomserv.net>
	<fgq9tj$kpf$1@ger.gmane.org>
Message-ID: <20071106140335.290fbf09@redhat.com>

On Tue, 06 Nov 2007 12:57:07 -0500
Neal Becker <ndbecker2 at gmail.com> wrote:

> Do you mean that the 0_40-2_fc8 would appear to be
> newer than the 0_40-1_fc9?

Yes, 0.40-2 is nvr higher than 0.40-1

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/9613dc2c/attachment.sig>

From myfedora at richip.dhs.org  Tue Nov  6 18:04:09 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 06 Nov 2007 11:04:09 -0700
Subject: Severe X breakage heads up
In-Reply-To: <1194362674.3963.10.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
Message-ID: <1194372249.4985.8.camel@localhost6.localdomain6>

On Tue, 2007-11-06 at 10:24 -0500, Matthias Clasen wrote:
> On Tue, 2007-11-06 at 09:29 -0500, Bernardo Innocenti wrote:
> 
> > One non trivial change for Fedora would be moving the kbd
> > config away from xorg.conf.  Both Gnome and KDE can already
> > override the server settings through XKB.  The various
> > display managers, I'm afraid, don't do anything by default.
> > Same with startx.
> 
> This will change soon for gdm, I think. The gdm rewrite will make it
> possible to have a keyboard layout selector on the login screen, very
> similar to what you have inside the session. At least that is one of the
> goals.

Why is that functionality being added to a desktop manager? What exactly
is the definition for a desktop manager these days? I've always found
the name "desktop manager" to be a bit misleading. In my mind, I've
always thought of it as just a user login system (determining the user
for a session). Are desktop managers supposed to handle more than that?
--

Richi Plana



From jkeating at redhat.com  Tue Nov  6 19:10:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 6 Nov 2007 14:10:12 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1194372249.4985.8.camel@localhost6.localdomain6>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<1194372249.4985.8.camel@localhost6.localdomain6>
Message-ID: <20071106141012.0ff39a03@redhat.com>

On Tue, 06 Nov 2007 11:04:09 -0700
Richi Plana <myfedora at richip.dhs.org> wrote:

> Why is that functionality being added to a desktop manager? What
> exactly is the definition for a desktop manager these days? I've
> always found the name "desktop manager" to be a bit misleading. In my
> mind, I've always thought of it as just a user login system
> (determining the user for a session). Are desktop managers supposed
> to handle more than that?

What if you need to use your native layout in order to type in your
username correctly, or password due to muscle memory.  

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/4029af58/attachment.sig>

From pbrobinson at gmail.com  Tue Nov  6 18:14:54 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 6 Nov 2007 18:14:54 +0000
Subject: Severe X breakage heads up
In-Reply-To: <20071106141012.0ff39a03@redhat.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<1194372249.4985.8.camel@localhost6.localdomain6>
	<20071106141012.0ff39a03@redhat.com>
Message-ID: <5256d0b0711061014nf901161q92675ec5c7f8b46c@mail.gmail.com>

> Richi Plana <myfedora at richip.dhs.org> wrote:
>
> > Why is that functionality being added to a desktop manager? What
> > exactly is the definition for a desktop manager these days? I've
> > always found the name "desktop manager" to be a bit misleading. In my
> > mind, I've always thought of it as just a user login system
> > (determining the user for a session). Are desktop managers supposed
> > to handle more than that?
>
> What if you need to use your native layout in order to type in your
> username correctly, or password due to muscle memory.

This is important for the auto config with no x.org file as when i use
no config with the intel drivers i get a US layout not the expected UK
layout. See bug from a while ago here
https://bugzilla.redhat.com/show_bug.cgi?id=252319

Peter



From jspaleta at gmail.com  Tue Nov  6 18:19:57 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Nov 2007 09:19:57 -0900
Subject: Severe X breakage heads up
In-Reply-To: <1194372249.4985.8.camel@localhost6.localdomain6>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<1194372249.4985.8.camel@localhost6.localdomain6>
Message-ID: <604aa7910711061019j1fcc1d85k9755e237ef8fc378@mail.gmail.com>

On 11/6/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> Why is that functionality being added to a desktop manager? What exactly
> is the definition for a desktop manager these days? I've always found
> the name "desktop manager" to be a bit misleading. In my mind, I've
> always thought of it as just a user login system (determining the user
> for a session). Are desktop managers supposed to handle more than that?


rpm -qi gdm
Gdm (the GNOME Display Manager)

gdm makes it possible for you to login to the system. Let's avoid
trying to shoe-horn what that means into legacy concepts like
"desktop."

There are absolutely real situations where a computer will have
multi-lingual users. Wouldn't it be great if those  users could have
their native keyboard layout at the login screen for login names and
passwords.

-jef"Semantical games are my chosen blood sport"spaleta



From loupgaroublond at gmail.com  Tue Nov  6 18:34:23 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Tue, 6 Nov 2007 13:34:23 -0500
Subject: Severe X breakage heads up
In-Reply-To: <604aa7910711061019j1fcc1d85k9755e237ef8fc378@mail.gmail.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<1194372249.4985.8.camel@localhost6.localdomain6>
	<604aa7910711061019j1fcc1d85k9755e237ef8fc378@mail.gmail.com>
Message-ID: <7f692fec0711061034o58b81b04tb4a4a2207b44b571@mail.gmail.com>

On 11/6/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On 11/6/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> > Why is that functionality being added to a desktop manager? What exactly
> > is the definition for a desktop manager these days? I've always found
>
> There are absolutely real situations where a computer will have
> multi-lingual users. Wouldn't it be great if those  users could have
> their native keyboard layout at the login screen for login names and
> passwords.

+1

Some people also use dvorak.  Typing in my password in Qwerty is hard
enough, but when I've physically remapped my keyboard, remembering
Qwerty just to type in a password (let alone what happens when I need
to play with GRUB) is a huge pain in the rear.

-Yaakov



From mszpak at wp.pl  Tue Nov  6 18:34:14 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Tue, 06 Nov 2007 19:34:14 +0100
Subject: nfs-utils update problem (broken deps)
Message-ID: <fgqc37$t5a$1@ger.gmane.org>

Fedora 7.92 and updates from devel. It was tested before official
updates for F8, but they should be already in devel (I don't have access
to that machine now).

Marcin


[root at szpak ~]# yum update nfs*
Loading "refresh-updatesd" plugin
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package nfs-utils.i386 1:1.1.0-6.fc8 set to be updated
--> Processing Dependency: libgssglue.so.1(libgssapi_CITI_2) for
package: nfs-utils
--> Processing Dependency: libgssglue.so.1 for package: nfs-utils
--> Processing Dependency: libgssglue for package: nfs-utils
---> Package nfs-utils-lib.i386 0:1.1.0-3.fc8 set to be updated
--> Running transaction check
---> Package libgssglue.i386 0:0.1-4.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Updating:
 nfs-utils               i386       1:1.1.0-6.fc8    fedora
262 k
 nfs-utils-lib           i386       1.1.0-3.fc8      fedora
59 k
Installing for dependencies:
 libgssglue              i386       0.1-4.fc8        fedora
21 k

Transaction Summary
=============================================================================
Install      1 Package(s)
Update       2 Package(s)
Remove       0 Package(s)

Total download size: 342 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
Package libtirpc needs libgssapi.so.2, this is not available.
Package libtirpc needs libgssapi.so.2(libgssapi_CITI_2), this is not
available.
Complete!



From kevin.kofler at chello.at  Tue Nov  6 18:39:52 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 6 Nov 2007 18:39:52 +0000 (UTC)
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<b63305xquc.ln2@hubmaier.ceplovi.cz>
Message-ID: <loom.20071106T183853-230@post.gmane.org>

Matej Cepl <mcepl <at> redhat.com> writes:
> Wikipedia, Atlantis http://www.akcaagac.com/index_atlantis.html looks 
> pretty nice. I don't know how good its Javascript/AJAX support is though.

Unfortunately, Atlantis is not Free Software.

        Kevin Kofler



From jspaleta at gmail.com  Tue Nov  6 18:40:28 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Nov 2007 09:40:28 -0900
Subject: Severe X breakage heads up
In-Reply-To: <7f692fec0711061034o58b81b04tb4a4a2207b44b571@mail.gmail.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<1194372249.4985.8.camel@localhost6.localdomain6>
	<604aa7910711061019j1fcc1d85k9755e237ef8fc378@mail.gmail.com>
	<7f692fec0711061034o58b81b04tb4a4a2207b44b571@mail.gmail.com>
Message-ID: <604aa7910711061040g7e6b01b8xbfe71a748b474d46@mail.gmail.com>

On 11/6/07, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> Some people also use dvorak.

It's important that we make the effort to make using Fedora easier for
those with diagnosed mental impairments...even dvorak users.

-jef"has a theory.. that there is a high correlation between esperanto
speakers and dvorak users"spaleta



From mszpak at wp.pl  Tue Nov  6 18:42:32 2007
From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=)
Date: Tue, 06 Nov 2007 19:42:32 +0100
Subject: libgnome update problem (broken deps) (Was: Re: Fedora 8 Test3 and
 problem with updates)
In-Reply-To: <fgincp$un4$1@ger.gmane.org>
References: <fghn21$6dv$1@ger.gmane.org>	<20071103125316.GD6839@auslistsprd01.us.dell.com>	<fgieve$73e$1@ger.gmane.org>
	<fgincp$un4$1@ger.gmane.org>
Message-ID: <fgqcip$ute$1@ger.gmane.org>

Hi again,

Today I was able to narrow problem down to a dew packages (I installed
remaining over a hundred other updates).
I'm unable to update libgnome. redhat-artwork >= 7.0.0 seems to be
already installed, but fedora-icon-theme conflicts sharing the same
files. If needed I can make more tests.

Marcin


[root at szpak ~]# yum update libgnome*
Loading "refresh-updatesd" plugin
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package libgnome-devel.i386 0:2.20.1-2.fc8 set to be updated
---> Package libgnome.i386 0:2.20.1-2.fc8 set to be updated
--> Processing Dependency: fedora-gnome-theme >= 8.0.0 for package:
libgnome
--> Running transaction check
---> Package fedora-gnome-theme.noarch 0:8.0.0-1.fc8 set to be updated
--> Processing Dependency: bluecurve-icon-theme for package:
fedora-gnome-theme
--> Processing Dependency: fedora-icon-theme for package:
fedora-gnome-theme
--> Running transaction check
---> Package fedora-icon-theme.noarch 0:1.0.0-1.fc8 set to be updated
---> Package bluecurve-icon-theme.noarch 0:8.0.0-1.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Updating:
 libgnome                i386       2.20.1-2.fc8     fedora
966 k
 libgnome-devel          i386       2.20.1-2.fc8     updates
82 k
Installing for dependencies:
 bluecurve-icon-theme    noarch     8.0.0-1.fc8      fedora
5.1 M
 fedora-gnome-theme      noarch     8.0.0-1.fc8      fedora
10 k
 fedora-icon-theme       noarch     1.0.0-1.fc8      fedora
115 k

Transaction Summary
=============================================================================
Install      3 Package(s)
Update       2 Package(s)
Remove       0 Package(s)

Total download size: 6.2 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
ERROR with rpm_check_debug vs depsolve:
Package nodoka-theme-gnome needs redhat-artwork >= 7.0.0, this is not
available.
Complete!



From mszpak at wp.pl  Tue Nov  6 18:49:32 2007
From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=)
Date: Tue, 06 Nov 2007 19:49:32 +0100
Subject: Infinity theme for gdm removed from Fedora?
In-Reply-To: <1194354720.7729.34.camel@localhost.localdomain>
References: <fgnmnm$p76$1@ger.gmane.org>
	<1194354720.7729.34.camel@localhost.localdomain>
Message-ID: <fgqcvs$ute$2@ger.gmane.org>

On 2007-11-06 14:12, Lubomir Kundrak wrote:
> On Mon, 2007-11-05 at 19:17 +0100, Marcin Zaj?czkowski wrote:
>>
>> In Fedora 8 Test3 the default theme for gdm (login screen) is Infinity.
>> One of the available updates removes it completely (after restart there
>> is an error message about missing files and in fact those files are
>> missing).
>> Was it intended to remove that theme?
> 
> I guess not. Do you have an idea which package did remove it. Do you
> have a log?

Today I updated another one hundred packages and one of them installed
Infinity theme again.

Marcin



From kevin.kofler at chello.at  Tue Nov  6 18:51:35 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 6 Nov 2007 18:51:35 +0000 (UTC)
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!
	5@redhat.com> <loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<1194272495.15341.136.camel@localhost.localdomain>
	<slrnfiuf45.3g7.mcepl@h!
	ubmaier.ceplovi.cz> <ufak5ow3ceh.fsf@epithumia.math.uh.edu>
Message-ID: <loom.20071106T184852-158@post.gmane.org>

Jason L Tibbitts III <tibbs <at> math.uh.edu> writes:
> If those packages require an X server then something is rather wrong
> with the dependencies, unless by "fully defined dependencies" you mean
> "has way more dependencies than actually needed".
> 
> You can install those things on a headless server and run them over
> the network.  No X server is needed on the machine where they're
> installed.

They're using soft dependencies, where the admin can decide to treat these as 
hard dependencies or ignore them. There's 2 levels of soft dependencies, 
Recommends and Suggests, where the first defaults to be treated like a hard 
dependency and the second defaults to be ignored.

There's proposals for adding these to RPM too, but that hasn't happened yet. 
Once added to RPM, the proponents will also have to convince Fedora that using 
them in Fedora is a good idea if they want those features to get actively used.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Nov  6 18:54:57 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 6 Nov 2007 18:54:57 +0000 (UTC)
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <loom.20071030T224723-163@post.gmane.org>
	<20071031014811.GA13676@nostromo.devel.redhat.com>
	<4727DF0E.7090308@fedoraproject.org>
	<1193795538.11243.3.camel@localhost.localdomain>
	<4727E19F.1010405@fedoraproject.org>
	<20071031020715.GA14902@nostromo.devel.redhat.com>
	<4727E511.9000504@fedoraproject.org>
	<1193797294.11243.7.camel@localhost.localdomain>
	<4727E818.8020202@fedoraproject.org>
	<1193797979.11243.11.camel@localhost.localdomain>
	<4727EBED.4020909@fedoraproject.org>
	<1193799384.11243.21.camel@localhost.localdomain>
	<4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!
	5@redhat.com> <loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<1194272495.15341.136.camel@localhost.localdomain>
	<slrnfiuf45.3g7.mcepl@h! ubmaier.ceplovi.cz>
Message-ID: <loom.20071106T185156-375@post.gmane.org>

Matej Cepl <mcepl <at> redhat.com> writes:
> > I wish we had a way to mark packages as actively deprecated.  I don't
> > want to orphan xdm, I want that no one work on it ever again.
> 
> Yes, please, I am always lost with xdm bugs ... 

KDM is derived from XDM and the current KDE packages share some files with XDM 
instead of duplicating them, so KDE will need changes if you remove XDM. (This 
is also why there's currently no KDE updates from kde-redhat for EL5. I'd 
suggest just rebuilding the FC6 xorg-x11-xdm for EL5 in kde-redhat, it would be 
the easiest way to solve this problem.)

        Kevin Kofler



From mclasen at redhat.com  Tue Nov  6 18:57:06 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 06 Nov 2007 13:57:06 -0500
Subject: libgnome update problem (broken deps) (Was: Re: Fedora 8 Test3
	and problem with updates)
In-Reply-To: <fgqcip$ute$1@ger.gmane.org>
References: <fghn21$6dv$1@ger.gmane.org>
	<20071103125316.GD6839@auslistsprd01.us.dell.com>
	<fgieve$73e$1@ger.gmane.org> <fgincp$un4$1@ger.gmane.org>
	<fgqcip$ute$1@ger.gmane.org>
Message-ID: <1194375426.3963.15.camel@localhost.localdomain>


On Tue, 2007-11-06 at 19:42 +0100, Marcin Zaj?czkowski wrote:

> ERROR with rpm_check_debug vs depsolve:
> Package nodoka-theme-gnome needs redhat-artwork >= 7.0.0, this is not
> available.
> Complete!
> 

What version of nodoka-theme-gnome do you have installed ?
I don't see that dependency here:

[mclasen at localhost gtk]$ rpm -q nodoka-theme-gnome
nodoka-theme-gnome-0.3.2-2.fc8
[mclasen at localhost gtk]$ rpm -q --requires nodoka-theme-gnome
fedora-icon-theme  
gtk-nodoka-engine >= 0.3.1.1
nodoka-metacity-theme  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1




From kevin.kofler at chello.at  Tue Nov  6 19:10:53 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 6 Nov 2007 19:10:53 +0000 (UTC)
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <4727EFF2.6050505@fedoraproject.org>
	<1193799897.11243.24.camel@localhost.localdomain>
	<4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
Message-ID: <loom.20071106T185542-975@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> I am a small desktop user. For the display managers, there are wdm, 
> xdm and slim (but they lack integration with consolekit). For the

I think my KDM ConsoleKit patch should be fairly easy to adapt to any 
XDM-derived display manager, as KDM is also derived from XDM. The only caveat 
is that it includes GPL code derived from GDM, so it will make your display 
manager GPLed, and you can't use it if its license isn't GPL-compatible. 
(Luckily, the X11 license used in XDM is GPL-compatible.)

> to package ivman for automounting, but it turned out to have too 
> much issues. I have developped halevt to replace ivman, but so far 
> nobody has packaged it (I don't want to maintain it in fedora since 
> I am upstream).

I think you should really maintain it in Fedora. Being upstream, you're the one 
who knows it best, and you also actively use the package. Moreover, you're 
already an experienced Fedora packager, so your case is different from the one 
of upstream developers only wanting to get their software into Fedora which you 
identify as a possible cause of conflicts of interest (but which IMHO isn't 
necessarily bad either).

I'm the upstream maintainer of Quarticurve, the unofficial Qt 4 port of the 
Bluecurve widget theme, and I maintain it in Fedora. The situation was much 
like yours, Fedora is the first distribution to package it. And I think it's 
working out well.

> For openoffice, I haven't seen obvious replacements (I tried 
> to package Ted, but it is a nightmare).

KOffice maybe? Yes, it requires the kdelibs, but it's not anywhere near as 
bloated as OO.o is.

If you can live without a full office suite, AbiWord and Gnumeric are also good 
options.

> To replace firefox, there is dillo, but it lacks functionalities, more
> promising is links-hacked (I have a spec) or maybe links2.

Hmmm, maybe Konqueror? But then you'll be loading most of KDE into memory 
anyway, so why not use KDE in the first place? ;-)

By the way, this isn't that wacky a question, people from KDE and GNOME have 
analyzed memory requirements for different setups, and the lightweight WM setup 
ended up requiring more memory once they started different apps, because they 
all used different libraries or no libraries at all, whereas the full desktop 
environments have most of their code shared across applications.

        Kevin Kofler



From myfedora at richip.dhs.org  Tue Nov  6 19:18:38 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 06 Nov 2007 12:18:38 -0700
Subject: Severe X breakage heads up
In-Reply-To: <604aa7910711061019j1fcc1d85k9755e237ef8fc378@mail.gmail.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<1194372249.4985.8.camel@localhost6.localdomain6>
	<604aa7910711061019j1fcc1d85k9755e237ef8fc378@mail.gmail.com>
Message-ID: <1194376718.5917.6.camel@localhost6.localdomain6>

On Tue, 2007-11-06 at 09:19 -0900, Jeff Spaleta wrote:
> On 11/6/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> > Why is that functionality being added to a desktop manager? What exactly
> > is the definition for a desktop manager these days? I've always found
> > the name "desktop manager" to be a bit misleading. In my mind, I've
> > always thought of it as just a user login system (determining the user
> > for a session). Are desktop managers supposed to handle more than that?
> 
> 
> rpm -qi gdm
> Gdm (the GNOME Display Manager)
> 
> gdm makes it possible for you to login to the system. Let's avoid
> trying to shoe-horn what that means into legacy concepts like
> "desktop."
> 
> There are absolutely real situations where a computer will have
> multi-lingual users. Wouldn't it be great if those  users could have
> their native keyboard layout at the login screen for login names and
> passwords.

"Shoe-horning gdm into a legacy concept" wasn't my intention. Just
making sure that features are in their rightful place to avoid
duplication of (and possibly conflicting) effort.

"gdm makes it possible for you to login to the system" is exactly what I
had in mind for gdm (and other "deskop managers", or "display manager"
in the case of gdm). If having the wrong keyboard type makes it
impossible to log in, then yes, I do agree that lacking that, by
definition, would mean a failure in the system. Me, I'm just trying to
understand the logic behind it (not saying there isn't any or it's
wrong).

Semantics is good. As a firm believer in Agile Modeling concepts, I
agree with the tenet "Your goal is to build a shared understanding, it
isn't to write detailed documentation."
--

Richi Plana



From oliver at linux-kernel.at  Tue Nov  6 19:47:21 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 06 Nov 2007 20:47:21 +0100
Subject: Contacts to FSF to resolve license issue!?
Message-ID: <4730C4C9.2090707@linux-kernel.at>

Hi!

A few days ago, I stumbled across the freshmeat announcement of
nodemon/growler [0]. Both are NASA projects under NOSA 1.3 license.
While in the first moment I thought, NOSA is free, FSF page list this
license (at least in version 1.3) as non-free. After reading the
description, I was clear for me why it is non-free. [1]

However, I contacted Mr. Bryan Green (author of nodemon/growler) and
asked him if there's a chance to release the software under a *really
free* license or if there's a chance to get a new version of NOSA (eg
1.4), that actually is FSF compliant and therefor software can be
included into Fedora.

But it seems, NASA already tried to get in touch with FSF to solve the
issue, but FSF wasn't very cooperative (no offense!).

I'd be glad, if someone has good contacts to FSF and we can bring
together NASA and FSF, to solve that issue. Not only for nodemon/growler
 to make it into Fedora, but also to make the world just another bit
*more* free! I know of some people, who'll be smiling about this
sentence... :-) Don't you?

-of

[0] http://people.nas.nasa.gov/~bgreen/nodemon/
    http://people.nas.nasa.gov/~bgreen/growler/
[1] http://www.fsf.org/licensing/licenses/; Search for NASA.



From pertusus at free.fr  Tue Nov  6 20:56:23 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 6 Nov 2007 21:56:23 +0100
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
In-Reply-To: <loom.20071106T185542-975@post.gmane.org>
References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<loom.20071106T185542-975@post.gmane.org>
Message-ID: <20071106205623.GB2627@free.fr>

On Tue, Nov 06, 2007 at 07:10:53PM +0000, Kevin Kofler wrote:
> Patrice Dumas <pertusus <at> free.fr> writes:
> > I am a small desktop user. For the display managers, there are wdm, 
> > xdm and slim (but they lack integration with consolekit). For the
> 
> I think my KDM ConsoleKit patch should be fairly easy to adapt to any 
> XDM-derived display manager, as KDM is also derived from XDM. The only caveat 
> is that it includes GPL code derived from GDM, so it will make your display 
> manager GPLed, and you can't use it if its license isn't GPL-compatible. 
> (Luckily, the X11 license used in XDM is GPL-compatible.)

Why don't you use libck-connector.so or even simplier pam_ck_connector?

> I think you should really maintain it in Fedora. Being upstream, you're the one 
> who knows it best, and you also actively use the package. Moreover, you're 

I am ready to comaintain the package, and as I already said, even do all
the work of packaging. But a maintainer in fedora should be there to
have the final word.

> already an experienced Fedora packager, so your case is different from the one 
> of upstream developers only wanting to get their software into Fedora which you 
> identify as a possible cause of conflicts of interest (but which IMHO isn't 
> necessarily bad either).

Conflict of interest may arise after the import.

> KOffice maybe? Yes, it requires the kdelibs, but it's not anywhere near as 
> bloated as OO.o is.
> 
> If you can live without a full office suite, AbiWord and Gnumeric are also good 
> options.

Indeed, it is much less heavy than OO.

> By the way, this isn't that wacky a question, people from KDE and GNOME have 
> analyzed memory requirements for different setups, and the lightweight WM setup 
> ended up requiring more memory once they started different apps, because they 
> all used different libraries or no libraries at all, whereas the full desktop 
> environments have most of their code shared across applications.

I could have a look, but I doubt a lot that in my use case it is true.

It would mean that 
some xterms, some with vi + xpdf + firefox + mutt + fluxbox
consumes more memory than
some gterm + gedit + evince + firefox + evolution (or maybe something 
  lighter I don't know) + gnome 

I can check, but I doubt so much. Do you want that I check, and in that
case do you have an explanation on how to measure the footprints?

--
Pat



From ml at deadbabylon.de  Tue Nov  6 21:05:49 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 6 Nov 2007 22:05:49 +0100
Subject: KDE-SIG weekly report (45/2007)
Message-ID: <200711062205.55258.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
?to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 45/2007

Time: 2007-11-06 17:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06

Meeting log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06?action=AttachFile&do=get&target=fedora-kde-sig-2007-11-06.txt

----------------------------------------------------------------------------------

= Participants =

ArthurPemberton 
KevinKofler
LaithJuwaidah
RexDieter
SebastianVahl
PavelShevchuk 

----------------------------------------------------------------------------------

= Agenda =

* Introduce new KDE-SIG-Members 
* Nodoka-Theme for KDE (Thread on fedora-art-list) 
* Changing the wallpaper every hour - infinity-24 (complete) 
* Planned early updates for F8 
* The weekly talk about KDE4 (status of kdebase-workspace and so on)

= Summary =

o Nodoka-Theme for KDE: 
- LaithJuwaidah has adapted Nodoka-Metacity-Theme to dekorator 
- We will probably need to port dekorator to KDE4 (because it's maintainer 
seems to stop working on it) 
- Another option would be to use native port for kwin4 
- A third option would be to use the code of polyester (it's looking is fairly 
close the same and is available for KDE3 and KDE4) 
- It's still undecided in which package it should be put 
- The theme would only be available as an optional update and not set as 
default in Fedora 8 

o Changing the wallpaper every hour: 
- LaithJuwaidah has written a perl script to change the wallpaper every hour 
(like Gnome does now with Infinity wallpaper) 
- using this script with kdewebdesktop would be prefered over an usage in cron 

o supposed early updates for F8: 
- KDE 3.95.0 development platform 
- There are also some minor updates in kde-settings and 
fedorainfinity-kdm-theme 
- kdegames4 as an replacement for kdegames(3) would only be an option if sound 
is working 

o The weekly talk about KDE4: 
- kdelibs4 for KDE 3.95.0 is already done, kdepimlibs will follow 
- kdebase-runtime will be included into existing kdebase4 
- We will need reviews for the splitting of KDE4's kdebase package

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/99f08786/attachment.sig>

From wwoods at redhat.com  Tue Nov  6 22:36:06 2007
From: wwoods at redhat.com (Will Woods)
Date: Tue, 06 Nov 2007 17:36:06 -0500
Subject: Most obvious Fedora 8 bugs
In-Reply-To: <64b14b300711041208j393e7c92u71b1a048b7b0d5@mail.gmail.com>
References: <64b14b300711041208j393e7c92u71b1a048b7b0d5@mail.gmail.com>
Message-ID: <1194388566.22068.29.camel@metroid.rdu.redhat.com>


On Sun, 2007-11-04 at 21:08 +0100, Valent Turkovic wrote:
> I didn't manage to test it before but not that I have tested Fedora 8
> RC3 here are the most obvious bugs I came across:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=366001 - PulseAudio
> distorts audio (over amplification)

Never noticed it here. I'd suggest you use the GNOME volume control app
(or any other ALSA volume control app) to change the volume on the
actual hardware devices - one of those might just be set too high.

Has anyone else seen this? Might end up being a FAQ/CommonBug if a lot
of people see it.

> https://bugzilla.redhat.com/show_bug.cgi?id=366041 - anaconda manual
> partition weridness

"average desktop users" generally don't manually partition drives. 

> https://bugzilla.redhat.com/show_bug.cgi?id=355291 - RFE: Allow
> fluendo codecs to work with SELinux enabled

Works fine for me in F8 Final. The bug is closed.

> https://bugzilla.redhat.com/show_bug.cgi?id=236881 - Firefox doesn't
> install Flash plugin when it is needed and absent

This is a tricky and ongoing problem. Adobe provides a nice yum repo for
flash, so at least there's that. I actually haven't tested this in a
little while - ugly proprietary plugins get low priority on my list. But
I'll look at it now that I have a little more time.

See also https://bugzilla.redhat.com/show_bug.cgi?id=334311

> On more positive side I must admit I'm impressed with performance of
> wireless and suspend on few laptops I have tested fedora 8 RC3 - it
> JustWorks(tm) :)

Well hey, that's good. And it should be getting even better over time -
a few things we wanted fixed for F8 will get fixed later on, in
post-release updates. 

Thanks for testing!

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/8c7cdcfa/attachment.sig>

From debarshi.ray at gmail.com  Tue Nov  6 22:38:57 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 7 Nov 2007 04:08:57 +0530
Subject: glade3 in fedora7
In-Reply-To: <472F88D6.1020202@hhs.nl>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<1182676374.7266.2.camel@localhost.localdomain>
	<467E95A5.2060506@fedoraproject.org>
	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
Message-ID: <3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>

> Glade3 has been incorperated into gtk-2.12.0, and thus will be in F-8, its
> called gtkbuilder now and this is considered the future of glade (AFAIK)

libglade (http://www.jamesh.id.au/software/libglade/) and Glade
(http://glade.gnome.org/) are separate projects.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From debarshi.ray at gmail.com  Tue Nov  6 22:40:37 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 7 Nov 2007 04:10:37 +0530
Subject: glade3 in fedora7
In-Reply-To: <3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<467E95A5.2060506@fedoraproject.org>
	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
	<3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>
Message-ID: <3170f42f0711061440g64d233cav15b55a00f00b5844@mail.gmail.com>

I have re-opened the Glade-3 review request at
https://bugzilla.redhat.com/show_bug.cgi?id=177747

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From sundaram at fedoraproject.org  Tue Nov  6 22:41:25 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Nov 2007 04:11:25 +0530
Subject: glade3 in fedora7
In-Reply-To: <3170f42f0711061440g64d233cav15b55a00f00b5844@mail.gmail.com>
References: <1182662333.5754.2.camel@localhost.localdomain>	<467E95A5.2060506@fedoraproject.org>	<62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com>	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>	<469C7B45.4070407@rasmil.dk>	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>	<1186967894.3339.30.camel@localhost.localdomain>	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>	<472F88D6.1020202@hhs.nl>	<3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>
	<3170f42f0711061440g64d233cav15b55a00f00b5844@mail.gmail.com>
Message-ID: <4730ED95.6060009@fedoraproject.org>

Debarshi 'Rishi' Ray wrote:
> I have re-opened the Glade-3 review request at
> https://bugzilla.redhat.com/show_bug.cgi?id=177747
> 

AFAIK, you are supposed to open a new package review request and reclose 
the older one as a dup of the current review request. Otherwise the 
package status reports would show the original submitter as the package 
maintainer.

Rahul



From debarshi.ray at gmail.com  Tue Nov  6 22:51:21 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 7 Nov 2007 04:21:21 +0530
Subject: glade3 in fedora7
In-Reply-To: <4730ED95.6060009@fedoraproject.org>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>
	<469C7B45.4070407@rasmil.dk>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
	<3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>
	<3170f42f0711061440g64d233cav15b55a00f00b5844@mail.gmail.com>
	<4730ED95.6060009@fedoraproject.org>
Message-ID: <3170f42f0711061451w367ab1b9xefefb345d4957d3c@mail.gmail.com>

> AFAIK, you are supposed to open a new package review request and reclose
> the older one as a dup of the current review request. Otherwise the
> package status reports would show the original submitter as the package
> maintainer.

Matthias Clasen wanted me to "revive it / take it over". I hope that
is what I did.

In any case, when I request for CVS, I shall be enlisted as the
maintainer. So hopefully there would be no issues.

Regards,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From bernie at codewiz.org  Tue Nov  6 23:09:42 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Tue, 06 Nov 2007 18:09:42 -0500
Subject: Severe X breakage heads up
In-Reply-To: <39403.192.54.193.53.1194361211.squirrel@rousalka.dyndns.org>
References: <39403.192.54.193.53.1194361211.squirrel@rousalka.dyndns.org>
Message-ID: <4730F436.5060107@codewiz.org>

(cc davidz, hal ml)

On 11/06/07 10:00, Nicolas Mailhot wrote:

> 95% of the user-reported problems with evdev are due to the user
> switching himself and failing to do it properly (because switching to
> evdev requires setting an awful lot of xorg parameters to "evdev", and
> if you forget to change one xorg won't fail cleanly but work in a
> strange hybrid buggy PS/2+evdev input mode, and users will assume this
> buggy mode is evdev itself).

With input hotplug, we have exactly *zero* instances of
"evdev" in xorg.conf :-)

And the new evdev 1.2 also deduces the fancy bits stuff
directly from /dev/input/event* devices, as set by the
drivers.

This is where an OLPC-specific bug creeped: the combined
driver for the touchpad and glide sensor was improperly
setting the bits that describe the axes supported by
the input device.

HAL also is too strict: to detect a device as a touchpad,
it requires abs X/Y axes and PRESSURE.  We lack pressure
in the glide-sensor, so it was not being recognized
properly.

Now we're faking the PRESSURE axis just to satisfy hal.
If we just remove the check for PRESSURE, hal would
confuse analog joysticks with touchpads.

In order to detect a joysticks, we could look for the
presence of buttons.  I don't have one to test with.
Can anyone do a quick test and report what bits are
set in evdev?


> Just switching to evdev can fix an awful lot of multimedia key problem
> reports.

Moreover, it would let applications to discern multiple
input devices from one another.  Very useful for music and
videogames.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From bernie at codewiz.org  Tue Nov  6 23:16:56 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Tue, 06 Nov 2007 18:16:56 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1194362674.3963.10.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
Message-ID: <4730F5E8.8020109@codewiz.org>

On 11/06/07 10:24, Matthias Clasen wrote:

> This will change soon for gdm, I think. The gdm rewrite will make it
> possible to have a keyboard layout selector on the login screen, very
> similar to what you have inside the session. At least that is one of the
> goals.

Where does it read the defaults from?  It has to be a file
easily editable from system-config-keyboard.

Maybe we could just augment /etc/sysconfig/keyboard?


> Switching to evdev is also planned for F9, and will probably be part of
> the "big breakage".

Ah, cool!  Who's doing this work?  I'd like to resync
my OLPC packaging work if possible.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From jspaleta at gmail.com  Tue Nov  6 23:32:38 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Nov 2007 14:32:38 -0900
Subject: Severe X breakage heads up
In-Reply-To: <1194362674.3963.10.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
Message-ID: <604aa7910711061532g405f2804k9ef5b7546464901d@mail.gmail.com>

On 11/6/07, Matthias Clasen <mclasen at redhat.com> wrote:
> This will change soon for gdm, I think. The gdm rewrite will make it
> possible to have a keyboard layout selector on the login screen, very
> similar to what you have inside the session. At least that is one of the
> goals.

Would it be possible for gdm to know what each user prefers as a
keyboard layout?
Like if I use the face browser and select a user foo with the mouse.
Can gdm know user foo's default keyboard layout and use it for the
password entry?

-jef



From orion at cora.nwra.com  Tue Nov  6 23:32:37 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 06 Nov 2007 16:32:37 -0700
Subject: Looking for help with my packages
In-Reply-To: <Pine.LNX.4.64.0710161901090.4486@beer.tclug.org>
References: <47154463.5070108@cora.nwra.com>
	<Pine.LNX.4.64.0710161901090.4486@beer.tclug.org>
Message-ID: <4730F995.5030904@cora.nwra.com>

Jima wrote:
> On Tue, 16 Oct 2007, Orion Poplawski wrote:
>>    * perl-Device-SerialPort -- Linux/POSIX emulation of 
>> Win32::SerialPort functions
> 
>  I maintained this in my personal repo before you got it into Fedora, so 
> I'm willing to step up as a comaintainer. :-)
>  Not really too familiar with any of the others. :-|
> 
>      Jima
> 

Okay, add yourself here:

https://admin.fedoraproject.org/pkgdb/packages/name/perl-Device-SerialPort


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From orion at cora.nwra.com  Tue Nov  6 23:39:57 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 06 Nov 2007 16:39:57 -0700
Subject: Looking for help with my packages
In-Reply-To: <20071017095206.e0eb2b3e.tsmetana@redhat.com>
References: <47154463.5070108@cora.nwra.com>
	<20071017095206.e0eb2b3e.tsmetana@redhat.com>
Message-ID: <4730FB4D.6060703@cora.nwra.com>

Tom?? Smetana wrote:
> Hello.
> 
> Since I maintain NUT I can help you with this one.  Even take it over.
>>      * apcupsd -- APC UPS Power Control Daemon for Linux
> 
> I would be interested in this one as well (maintain/co-maintain):
>>      * gocr -- GNU Optical Character Recognition program
> 
> Regards.
> 

Thanks!

I've released ownership so you can take over.

https://admin.fedoraproject.org/pkgdb/packages/name/apcupsd
https://admin.fedoraproject.org/pkgdb/packages/name/gocr

There are some active apcupsd SElinux issues that are getting processed 
as well.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From orion at cora.nwra.com  Tue Nov  6 23:46:48 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Tue, 06 Nov 2007 16:46:48 -0700
Subject: Looking for help with my packages
In-Reply-To: <604aa7910710161623s509addfcvc290dbc6fb40a8ac@mail.gmail.com>
References: <47154463.5070108@cora.nwra.com>
	<604aa7910710161623s509addfcvc290dbc6fb40a8ac@mail.gmail.com>
Message-ID: <4730FCE8.5020408@cora.nwra.com>

Jeff Spaleta wrote:
> On 10/16/07, Orion Poplawski <orion at cora.nwra.com> wrote:
>>      * python-basemap -- Plots data on map projections (with continental
>> and political boundaries)
>>
>>      * python-basemap-data -- Data for python-basemap
>>
>>      * python-dateutil -- Powerful extensions to the standard datetime
>> module
>>
>>      * python-matplotlib -- Python plotting library
>>
>>      * python-numarray -- Python array manipulation and computational
>> library
>>
>>      * pytz -- World Timezone Definitions for Python
> 
> I'm going to have to take all of these over.  Most of this stuff is
> associated with matplotlib. Is there anything currently which needs
> python-numarray? Does it do anything that numpy doesn't take care of
> now?  I might decide to let this one expire if its there only for
> backwards compatibility.
> 
> -jef
> 

Thanks!

I've released ownership except for python-numarray in pkgdb.  I think 
gdl (one of my packages) is the only one that still uses it.  I suppose 
a patch to upstream shifting to numarray would be accepted.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From mclasen at redhat.com  Wed Nov  7 00:14:52 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 06 Nov 2007 19:14:52 -0500
Subject: Severe X breakage heads up
In-Reply-To: <604aa7910711061532g405f2804k9ef5b7546464901d@mail.gmail.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<604aa7910711061532g405f2804k9ef5b7546464901d@mail.gmail.com>
Message-ID: <1194394492.3963.19.camel@localhost.localdomain>


On Tue, 2007-11-06 at 14:32 -0900, Jeff Spaleta wrote:
> On 11/6/07, Matthias Clasen <mclasen at redhat.com> wrote:
> > This will change soon for gdm, I think. The gdm rewrite will make it
> > possible to have a keyboard layout selector on the login screen, very
> > similar to what you have inside the session. At least that is one of the
> > goals.
> 
> Would it be possible for gdm to know what each user prefers as a
> keyboard layout?
> Like if I use the face browser and select a user foo with the mouse.
> Can gdm know user foo's default keyboard layout and use it for the
> password entry?

You mean the value that you set inside your session ? Unlikely, unless
you want gdm to poke around in the gconf database in your home
directory. I guess it would be possible to make gdm remember the value
you set on the login screen per-user and set it up for you if you use
the face browser. That is not going to help for the user name entry,
though...



From mclasen at redhat.com  Wed Nov  7 00:17:54 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 06 Nov 2007 19:17:54 -0500
Subject: Severe X breakage heads up
In-Reply-To: <4730F5E8.8020109@codewiz.org>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<4730F5E8.8020109@codewiz.org>
Message-ID: <1194394674.3963.23.camel@localhost.localdomain>


On Tue, 2007-11-06 at 18:16 -0500, Bernardo Innocenti wrote:
> On 11/06/07 10:24, Matthias Clasen wrote:
> 
> > This will change soon for gdm, I think. The gdm rewrite will make it
> > possible to have a keyboard layout selector on the login screen, very
> > similar to what you have inside the session. At least that is one of the
> > goals.
> 
> Where does it read the defaults from?  It has to be a file
> easily editable from system-config-keyboard.

The gconf database of the gdm user, I think. It is debatable if that is
easily editable from system-config-keyboard and if it should. Why do you
think that would be necessary ?


> > Switching to evdev is also planned for F9, and will probably be part of
> > the "big breakage".
> 
> Ah, cool!  Who's doing this work?  I'd like to resync
> my OLPC packaging work if possible.

The X guys.



From jspaleta at gmail.com  Wed Nov  7 00:25:18 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Nov 2007 15:25:18 -0900
Subject: Severe X breakage heads up
In-Reply-To: <1194394492.3963.19.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<604aa7910711061532g405f2804k9ef5b7546464901d@mail.gmail.com>
	<1194394492.3963.19.camel@localhost.localdomain>
Message-ID: <604aa7910711061625m5061cac1k9a736a4f67637203@mail.gmail.com>

On 11/6/07, Matthias Clasen <mclasen at redhat.com> wrote:
> You mean the value that you set inside your session ? Unlikely, unless
> you want gdm to poke around in the gconf database in your home
> directory. I guess it would be possible to make gdm remember the value
> you set on the login screen per-user and set it up for you if you use
> the face browser. That is not going to help for the user name entry,
> though...

right.. but isnt that sort of the point of the face browser..so you
don't have to use the keyboard for username entry?

-jef



From sundaram at fedoraproject.org  Wed Nov  7 01:44:36 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Nov 2007 07:14:36 +0530
Subject: glade3 in fedora7
In-Reply-To: <3170f42f0711061451w367ab1b9xefefb345d4957d3c@mail.gmail.com>
References: <1182662333.5754.2.camel@localhost.localdomain>	
	<3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com>	
	<469C7B45.4070407@rasmil.dk>	
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>	
	<1186967894.3339.30.camel@localhost.localdomain>	
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>	
	<472F88D6.1020202@hhs.nl>	
	<3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>	
	<3170f42f0711061440g64d233cav15b55a00f00b5844@mail.gmail.com>	
	<4730ED95.6060009@fedoraproject.org>
	<3170f42f0711061451w367ab1b9xefefb345d4957d3c@mail.gmail.com>
Message-ID: <47311884.1000301@fedoraproject.org>

Debarshi 'Rishi' Ray wrote:
>> AFAIK, you are supposed to open a new package review request and reclose
>> the older one as a dup of the current review request. Otherwise the
>> package status reports would show the original submitter as the package
>> maintainer.
> 
> Matthias Clasen wanted me to "revive it / take it over". I hope that
> is what I did.

What I outlined is the way to revive it.

> In any case, when I request for CVS, I shall be enlisted as the
> maintainer. So hopefully there would be no issues.

The package status reports at 
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus use 
bugzilla queries to determine the maintainer and not CVS.

Rahul



From sundaram at fedoraproject.org  Wed Nov  7 02:00:05 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Nov 2007 07:30:05 +0530
Subject: Contacts to FSF to resolve license issue!?
In-Reply-To: <4730C4C9.2090707@linux-kernel.at>
References: <4730C4C9.2090707@linux-kernel.at>
Message-ID: <47311C25.7090201@fedoraproject.org>

Oliver Falk wrote:
> Hi!
> 
> A few days ago, I stumbled across the freshmeat announcement of
> nodemon/growler [0]. Both are NASA projects under NOSA 1.3 license.
> While in the first moment I thought, NOSA is free, FSF page list this
> license (at least in version 1.3) as non-free. After reading the
> description, I was clear for me why it is non-free. [1]
> 
> However, I contacted Mr. Bryan Green (author of nodemon/growler) and
> asked him if there's a chance to release the software under a *really
> free* license or if there's a chance to get a new version of NOSA (eg
> 1.4), that actually is FSF compliant and therefor software can be
> included into Fedora.
> 
> But it seems, NASA already tried to get in touch with FSF to solve the
> issue, but FSF wasn't very cooperative (no offense!).
> 
> I'd be glad, if someone has good contacts to FSF and we can bring
> together NASA and FSF, to solve that issue. Not only for nodemon/growler
>  to make it into Fedora, but also to make the world just another bit
> *more* free! I know of some people, who'll be smiling about this
> sentence... :-) Don't you?

Brett Smith, brett AT fsf.org is the licensing compliance engineer at 
FSF is probably best suited to handle such cases. Do you have more 
information on what exactly NASA suggested to FSF?

Rahul



From sundaram at fedoraproject.org  Wed Nov  7 02:04:36 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Nov 2007 07:34:36 +0530
Subject: libgnome update problem (broken deps) (Was: Re: Fedora 8 Test3
 and problem with updates)
In-Reply-To: <1194375426.3963.15.camel@localhost.localdomain>
References: <fghn21$6dv$1@ger.gmane.org>	<20071103125316.GD6839@auslistsprd01.us.dell.com>	<fgieve$73e$1@ger.gmane.org>
	<fgincp$un4$1@ger.gmane.org>	<fgqcip$ute$1@ger.gmane.org>
	<1194375426.3963.15.camel@localhost.localdomain>
Message-ID: <47311D34.5070208@fedoraproject.org>

Matthias Clasen wrote:
> On Tue, 2007-11-06 at 19:42 +0100, Marcin Zaj?czkowski wrote:
> 
>> ERROR with rpm_check_debug vs depsolve:
>> Package nodoka-theme-gnome needs redhat-artwork >= 7.0.0, this is not
>> available.
>> Complete!
>>
> 
> What version of nodoka-theme-gnome do you have installed ?
> I don't see that dependency here:
> 
> [mclasen at localhost gtk]$ rpm -q nodoka-theme-gnome
> nodoka-theme-gnome-0.3.2-2.fc8

In one of the systems that I looked at there was a duplicate package 
which resulted in conflicts. It is better to run

# package-cleanup --cleandupes

to check. package-cleanup is part of yum-utils.

Rahul



From ndbecker2 at gmail.com  Wed Nov  7 02:29:54 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 06 Nov 2007 21:29:54 -0500
Subject: desktop file handling question
Message-ID: <fgr7v2$iuf$1@ger.gmane.org>

I just updated kdiff3 from upstream.  It has added:
%{_datadir}/applnk/.hidden/kdiff3plugin.desktop

I just added this to %files.  I'm guessing it doesn't need special handling,
like desktop-file-install?



From tmz at pobox.com  Wed Nov  7 02:36:11 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 6 Nov 2007 21:36:11 -0500
Subject: rpms/mock/devel .cvsignore, 1.25, 1.26 mock.spec, 1.43, 1.44
	sources, 1.28, 1.29
In-Reply-To: <200711062336.lA6Na8di026355@cvs-int.fedora.redhat.com>
References: <200711062336.lA6Na8di026355@cvs-int.fedora.redhat.com>
Message-ID: <20071107023611.GE2295@psilocybe.teonanacatl.org>

Michael E Brown wrote:
> +# Compat for RHEL3 build
> +%if %(test "%{dist}" == ".el3" && echo 1 || echo 0)
> +# needed for RHEL3 build, python-devel doesnt seem to Require: python in
> +# RHEL3
> +BuildRequires:  python
> +# override sitelib because this messes up on x86_64
> +%define python_sitelib %{_exec_prefix}/lib/python2.2/site-packages/
> +%endif

Would it be cleaner to use the %{rhel} macro for this test?  Or isn't
that available outside of the build system?

# Compat for RHEL3 build
%if 0%{?rhel}>= 3
# python-devel doesn't seem to Require: python in RHEL3
BuildRequires:  python
# override sitelib because this messes up on x86_64
%define python_sitelib %{_exec_prefix}/lib/python2.2/site-packages/
%endif

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But I have grown older, and you have grown colder.  And nothing is
very much fun, anymore.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071106/a37cd930/attachment.sig>

From kevin.kofler at chello.at  Wed Nov  7 03:07:32 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 7 Nov 2007 03:07:32 +0000 (UTC)
Subject: KDE-SIG weekly report (45/2007)
References: <200711062205.55258.ml@deadbabylon.de>
Message-ID: <loom.20071107T025919-174@post.gmane.org>

Sebastian Vahl <ml <at> deadbabylon.de> writes:
> - We will probably need to port dekorator to KDE4 (because it's maintainer 
> seems to stop working on it) 
> - Another option would be to use native port for kwin4 
> - A third option would be to use the code of polyester (it's looking is
> fairly close the same and is available for KDE3 and KDE4)

Just to clarify: these are not 3 options for the same thing: the first two are 
the options for the KWin theme, i.e. the window decorations. The third one is 
an option (IMHO the most promising one) for the widget style. The window 
decorations are the borders of the window, in particular the title bar and the 
buttons on it. They are a theme for the window manager, i.e. KWin (and 
Beryl/Compiz-fusion which can display KWin themes). In the GNOME world, this is 
nodoka-metacity-theme. The widget style defines how things like menus, buttons, 
scrollbars, text boxes and the like look. This is a team for the widget 
toolkit, i.e. Qt. (And as both Qt 3 and 4 will be in use for the near future, 
we'll need versions for both, whereas for the KWin theme, only version 4 will 
be relevant once we get kdebase-workspace 4 in.) In the GNOME world, this is 
gtk-nodoka-engine.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Nov  7 03:22:04 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 7 Nov 2007 03:22:04 +0000 (UTC)
Subject: Dropping Base X group? [Was: Re: KDE logout options with F8]
References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com>
	<4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com>
	<4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com>
	<loom.20071031T182928-261@post.gmane.org>
	<slrnfislko.k5f.mcepl@hubmaier.ceplovi.cz>
	<20071105010239.GA3632@free.fr>
	<loom.20071106T185542-975@post.gmane.org>
	<20071106205623.GB2627@free.fr>
Message-ID: <loom.20071107T031332-713@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:
> Why don't you use libck-connector.so or even simplier pam_ck_connector?

I looked at how GDM does things, found their code fairly easy to port to KDM 
and did just that.

> I can check, but I doubt so much. Do you want that I check, and in that
> case do you have an explanation on how to measure the footprints?

Tracking down the original articles might be a good starting point. Here's the 
memory benchmark Lubo? Lu??k from KDE has made in 2006: 
http://ktown.kde.org/~seli/memory/desktop_benchmark.html I know there have been 
earlier measurements done, also by the GNOME developers. Maybe there's also 
newer ones.

        Kevin Kofler



From mclasen at redhat.com  Wed Nov  7 05:58:22 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 07 Nov 2007 00:58:22 -0500
Subject: Severe X breakage heads up
In-Reply-To: <604aa7910711061625m5061cac1k9a736a4f67637203@mail.gmail.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<604aa7910711061532g405f2804k9ef5b7546464901d@mail.gmail.com>
	<1194394492.3963.19.camel@localhost.localdomain>
	<604aa7910711061625m5061cac1k9a736a4f67637203@mail.gmail.com>
Message-ID: <1194415102.3963.29.camel@localhost.localdomain>


On Tue, 2007-11-06 at 15:25 -0900, Jeff Spaleta wrote:
> On 11/6/07, Matthias Clasen <mclasen at redhat.com> wrote:
> > You mean the value that you set inside your session ? Unlikely, unless
> > you want gdm to poke around in the gconf database in your home
> > directory. I guess it would be possible to make gdm remember the value
> > you set on the login screen per-user and set it up for you if you use
> > the face browser. That is not going to help for the user name entry,
> > though...
> 
> right.. but isnt that sort of the point of the face browser..so you
> don't have to use the keyboard for username entry?

Sure. I was trying to make the point that you still need to have a
keyboard selector on the login screen, for people who prefer typing
their name.



From jspaleta at gmail.com  Wed Nov  7 06:08:38 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Nov 2007 21:08:38 -0900
Subject: Severe X breakage heads up
In-Reply-To: <1194415102.3963.29.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47307A5D.4020607@codewiz.org>
	<1194362674.3963.10.camel@localhost.localdomain>
	<604aa7910711061532g405f2804k9ef5b7546464901d@mail.gmail.com>
	<1194394492.3963.19.camel@localhost.localdomain>
	<604aa7910711061625m5061cac1k9a736a4f67637203@mail.gmail.com>
	<1194415102.3963.29.camel@localhost.localdomain>
Message-ID: <604aa7910711062208m6e170239h64e48fd843478ff3@mail.gmail.com>

On Nov 6, 2007 8:58 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> Sure. I was trying to make the point that you still need to have a
> keyboard selector on the login screen, for people who prefer typing
> their name.


Sure, I didn't mean to imply you could get away with not having the
selector present. I was just thinking that you could link a default
layout per user in the browser as a convienence so my chinese
co-worker doesn't need to re-select every time they go to login.

-jef



From debarshi.ray at gmail.com  Wed Nov  7 06:12:42 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 7 Nov 2007 11:42:42 +0530
Subject: glade3 in fedora7
In-Reply-To: <47311884.1000301@fedoraproject.org>
References: <1182662333.5754.2.camel@localhost.localdomain>
	<645d17210708121449y70beafe0k11a1e80e785e58d@mail.gmail.com>
	<1186967894.3339.30.camel@localhost.localdomain>
	<3170f42f0711051240q30d48c9xeb4f895df515f90@mail.gmail.com>
	<472F88D6.1020202@hhs.nl>
	<3170f42f0711061438r5c54f059xe52b7e27c6d804e5@mail.gmail.com>
	<3170f42f0711061440g64d233cav15b55a00f00b5844@mail.gmail.com>
	<4730ED95.6060009@fedoraproject.org>
	<3170f42f0711061451w367ab1b9xefefb345d4957d3c@mail.gmail.com>
	<47311884.1000301@fedoraproject.org>
Message-ID: <3170f42f0711062212y4b6150ebs8cd1196e6c152df1@mail.gmail.com>

> What I outlined is the way to revive it.

My mistake then. Thanks for the pointer.

The glade3 review request is now at
https://bugzilla.redhat.com/show_bug.cgi?id=369381

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From debarshi.ray at gmail.com  Wed Nov  7 06:52:39 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 7 Nov 2007 12:22:39 +0530
Subject: No pushes to updates-testing for F-7?
Message-ID: <3170f42f0711062252p5e7246a0n6917c6d913946347@mail.gmail.com>

It seems no one has been signing and pushing packages to
updates-testing for F-7 for the last 12 days or so.

https://admin.fedoraproject.org/updates/F7/pending/opyum-0.0.3-1.fc7
https://admin.fedoraproject.org/updates/F7/pending/libedit-2.10-3.20070831cvs.fc7
https://admin.fedoraproject.org/updates/F7/pending/bouml-3.0.2-1.fc7

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From rjones at redhat.com  Wed Nov  7 11:58:47 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 07 Nov 2007 11:58:47 +0000
Subject: ANNOUNCE: fedora-ocaml mailing list
Message-ID: <4731A877.70008@redhat.com>

We've set up a mailing list for discussion of Fedora & OCaml issues. 
Anything to do with packaging, maintenance, bugs, contacting 
maintainers, wishlists, new packages, EPEL, etc.

https://www.redhat.com/mailman/listinfo/fedora-ocaml-list

Co-admins of the list are G?rard Milmeister and myself.

More about the OCaml SIG:

http://fedoraproject.org/wiki/SIGs/OCaml

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/eb3c44d7/attachment.bin>

From mschwendt.tmp0701.nospam at arcor.de  Wed Nov  7 12:14:07 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 7 Nov 2007 13:14:07 +0100
Subject: ERROR: You can not forcibly move tags between branches
In-Reply-To: <11359.63.85.68.164.1194369122.squirrel@mail.jcomserv.net>
References: <fgq4u7$1no$1@ger.gmane.org>
	<29954.63.85.68.164.1194366538.squirrel@mail.jcomserv.net>
	<fgq5m2$40u$1@ger.gmane.org>
	<46961.63.85.68.164.1194367478.squirrel@mail.jcomserv.net>
	<fgq6h5$7oo$1@ger.gmane.org>
	<11359.63.85.68.164.1194369122.squirrel@mail.jcomserv.net>
Message-ID: <20071107131407.abb28751.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 6 Nov 2007 11:12:02 -0600 (CST), Jon Ciesla wrote:

> > Are you sure about this?  I think the problem is that the tag was already
> > (mistakenly) applied to devel.  Probably because I did the tag in devel
> > before discovering that I needed to update common.
> 
> That's true.  The old common is what caused the invalid fc8 tag to appear
> in devel, and the tag -F should have fixed it, I've never had that not
> work.

You don't need -F when you update "common", since the next time you
run "make tag" in devel, the new %dist value will make it into a new tag.

But you still cannot move the old tag from devel to F-8, not with -F
either. Hence in the F-8 branch you need to bump to something like
5%{dist}.1



From buildsys at redhat.com  Wed Nov  7 12:20:42 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 7 Nov 2007 07:20:42 -0500
Subject: rawhide report: 20071107 changes
Message-ID: <200711071220.lA7CKgwP032479@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From buildsys at fedoraproject.org  Wed Nov  7 12:21:07 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Wed,  7 Nov 2007 07:21:07 -0500 (EST)
Subject: Package EVR problems in Fedora 2007-11-07
Message-ID: <20071107122107.CC04315212E@buildsys.fedoraproject.org>

Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6,
FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8, F8-updates,
F8-updates-testing

aportal AT univ-montp2 fr:
    gputils
      FE6 > F7 (0:0.13.5-1.fc6 > 0:0.13.4-2.fc6)
    
    kbackup
      FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)
    
    pikloops
      FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)
    
bjohnson AT symetrix com:
    dbmail
      FE6 > F7-updates (0:2.2.7-1.fc6 > 0:2.2.5-5.fc7)
    
    gscan2pdf
      FE6 > F7-updates (0:0.9.17-2.fc6 > 0:0.9.16-1.fc7)
    
    libsieve
      FE6 > F7 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)
    
    mailgraph
      FE6 > F7 (0:1.14-1.fc6 > 0:1.12-5.fc7)
    
    perl-PDF-API2
      FE6 > F7-updates (0:0.65-1.fc6 > 0:0.62-2.fc7)
    
    queuegraph
      FE6 > F7 (0:1.1-2.fc6 > 0:1.1-1.fc7)
    
bruno AT postle net:
    hugin
      FE6 > F7-updates (0:0.6.1-11.fc6 > 0:0.6.1-7.fc7)
    
cgoorah AT yahoo com au:
    piklab
      FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)
    
chris stone AT gmail com:
    poker-network
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)
    
    poker2d
      FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)
    
enrico scholz AT informatik tu-chemnitz de:
    libextractor
      FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)
    
    libtasn1
      FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
      FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)
    
    mimetic
      FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
      FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)
    
    util-vserver
      FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
      FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)
    
    xmlrpc-c
      FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
      FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)
    
frank-buettner AT gmx net:
    ctapi-cyberjack
      FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
      F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)
    
green AT redhat com:
    liblrdf
      FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)
    
    zynaddsubfx
      FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)
    
i AT stingr net:
    weechat
      F7-updates > F8 (0:0.2.6-1.fc7 > 0:0.2.5-1.fc8)
    
jeff AT ocjtech us:
    jrtplib
      FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)
    
    zaptel
      FE6 > F7 (0:1.4.6-1.fc6 > 0:1.4.2.1-1.fc7)
    
jnovy AT redhat com:
    netpbm
      FC6-updates > F8 (0:10.35.32-1.fc6 > 0:10.35-17.fc8)
      F7-updates > F8 (0:10.35.32-1.fc7 > 0:10.35-17.fc8)
    
john AT ncphotography com:
    bugzilla
      FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)
    
karen-pease AT uiowa edu:
    fortune-firefly
      FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
      FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)
    
    nethack-vultures
      FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)
    
lemenkov AT gmail com:
    flashrom
      FE6 > F7-updates (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc7)
    
    fuse-python
      FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
      F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8)
    
lxtnow AT gmail com:
    specto
      FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
      F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)
    
    wammu
      FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
      F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)
    
matthias AT rpmforge net:
    proftpd
      F7-updates > F8 (0:1.3.1-2.fc7 > 0:1.3.1-1.fc8)
    
mfleming+rpm AT enlartenment com:
    mcabber
      FE6 > F7-updates (0:0.9.4-1.fc6 > 0:0.9.3-3.fc7)
    
    mlmmj
      FE6 > F7 (0:1.2.15-1.fc6 > 0:1.2.14-2.fc7)
    
michel sylvan AT gmail com:
    Django
      FE6 > F7 (0:0.96.1-1.fc6 > 0:0.96-1.fc7)
    
    python-nltk
      FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
      FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)
    
mikeb AT redhat com:
    python-cheetah
      FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)
    
mmcgrath AT redhat com:
    cacti
      FE6 > F7-updates (0:0.8.7-2.fc6 > 0:0.8.6j-8.fc7)
      FE6 > F8 (0:0.8.7-2.fc6 > 0:0.8.6j-10.fc8)
    
    phpMyAdmin
      FE6 > F8 (0:2.11.2-1.fc6 > 0:2.11.0-1.fc8)
      F7-updates > F8 (0:2.11.2-1.fc7 > 0:2.11.0-1.fc8)
    
    python-meld3
      FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
      FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
    
    smolt
      FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc7)
      FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)
    
nhorman AT redhat com:
    irqbalance
      FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
      FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)
    
paul AT city-fan org:
    gnome-libs
      FE6 > F7 (1:1.4.2-7.fc6 > 1:1.4.2-5.fc7)
    
rcritten AT redhat com:
    mod_nss
      FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
      F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)
    
robert AT marcanoonline com:
    eclipse-subclipse
      FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
      F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)
    
sandmann AT redhat com:
    libgtop2
      FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)
    
splinux25 AT gmail com:
    lostirc
      FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)
    
tcallawa AT redhat com:
    xbase
      F7-updates > F8 (0:2.0.0-8.fc7 > 0:2.0.0-7.fc8)
    
than AT redhat com:
    qt4
      F7-updates > F8 (0:4.3.2-4.fc7 > 0:4.3.2-1.fc8)
    
tmraz AT redhat com:
    authconfig
      FC6-updates > F7-updates (0:5.3.18-0.1.fc6 > 0:5.3.15-1.fc7)
    
----------------------------------------------------------------------

authconfig: tmraz AT redhat com
  FC6-updates > F7-updates (0:5.3.18-0.1.fc6 > 0:5.3.15-1.fc7)

bugzilla: john AT ncphotography com
  FE6 > F7-updates (0:3.0.2-2.fc6 > 0:3.0.2-0.fc7)

cacti: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.8.7-2.fc6 > 0:0.8.6j-8.fc7)
  FE6 > F8 (0:0.8.7-2.fc6 > 0:0.8.6j-10.fc8)

ctapi-cyberjack: frank-buettner AT gmx net
  FE6 > F8 (0:3.0.5-1.fc6 > 0:3.0.4-1.fc8)
  F7-updates > F8 (0:3.0.5-1.fc7 > 0:3.0.4-1.fc8)

dbmail: bjohnson AT symetrix com
  FE6 > F7-updates (0:2.2.7-1.fc6 > 0:2.2.5-5.fc7)

Django: michel sylvan AT gmail com
  FE6 > F7 (0:0.96.1-1.fc6 > 0:0.96-1.fc7)

eclipse-subclipse: robert AT marcanoonline com
  FE6 > F8 (0:1.2.4-1.fc6 > 0:1.2.2-6.fc8)
  F7-updates > F8 (0:1.2.4-2.fc7 > 0:1.2.2-6.fc8)

flashrom: lemenkov AT gmail com
  FE6 > F7-updates (0:0-0.4.20071028svn2897.fc6 > 0:0-0.2.20071003svn2817.fc7)

fortune-firefly: karen-pease AT uiowa edu
  FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6)
  FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6)

fuse-python: lemenkov AT gmail com
  FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8)
  F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8)

gnome-libs: paul AT city-fan org
  FE6 > F7 (1:1.4.2-7.fc6 > 1:1.4.2-5.fc7)

gputils: aportal AT univ-montp2 fr
  FE6 > F7 (0:0.13.5-1.fc6 > 0:0.13.4-2.fc6)

gscan2pdf: bjohnson AT symetrix com
  FE6 > F7-updates (0:0.9.17-2.fc6 > 0:0.9.16-1.fc7)

hugin: bruno AT postle net
  FE6 > F7-updates (0:0.6.1-11.fc6 > 0:0.6.1-7.fc7)

irqbalance: nhorman AT redhat com
  FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6)
  FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7)

jrtplib: jeff AT ocjtech us
  FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7)

kbackup: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.5.3-1.fc6 > 0:0.5.2-1.fc7)

libextractor: enrico scholz AT informatik tu-chemnitz de
  FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7)

libgtop2: sandmann AT redhat com
  FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7)

liblrdf: green AT redhat com
  FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7)

libsieve: bjohnson AT symetrix com
  FE6 > F7 (0:2.2.6-2.fc6 > 0:2.2.5-1.fc7)

libtasn1: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7)
  FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7)

lostirc: splinux25 AT gmail com
  FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7)

mailgraph: bjohnson AT symetrix com
  FE6 > F7 (0:1.14-1.fc6 > 0:1.12-5.fc7)

mcabber: mfleming+rpm AT enlartenment com
  FE6 > F7-updates (0:0.9.4-1.fc6 > 0:0.9.3-3.fc7)

mimetic: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7)
  FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7)

mlmmj: mfleming+rpm AT enlartenment com
  FE6 > F7 (0:1.2.15-1.fc6 > 0:1.2.14-2.fc7)

mod_nss: rcritten AT redhat com
  FE6 > F8 (0:1.0.7-2.fc6 > 0:1.0.7-1.fc8)
  F7-updates > F8 (0:1.0.7-2.fc7 > 0:1.0.7-1.fc8)

nethack-vultures: karen-pease AT uiowa edu
  FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7)

netpbm: jnovy AT redhat com
  FC6-updates > F8 (0:10.35.32-1.fc6 > 0:10.35-17.fc8)
  F7-updates > F8 (0:10.35.32-1.fc7 > 0:10.35-17.fc8)

perl-PDF-API2: bjohnson AT symetrix com
  FE6 > F7-updates (0:0.65-1.fc6 > 0:0.62-2.fc7)

phpMyAdmin: mmcgrath AT redhat com
  FE6 > F8 (0:2.11.2-1.fc6 > 0:2.11.0-1.fc8)
  F7-updates > F8 (0:2.11.2-1.fc7 > 0:2.11.0-1.fc8)

piklab: cgoorah AT yahoo com au
  FE6 > F7-updates (0:0.15.0-1.fc6 > 0:0.14.5-1.fc7)

pikloops: aportal AT univ-montp2 fr
  FE6 > F7-updates (0:0.2.5-1.fc6 > 0:0.2.4-1.fc7)

poker-network: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-2.fc7)

poker2d: chris stone AT gmail com
  FE6 > F7-updates (0:1.2.0-3.fc6 > 0:1.2.0-1.fc7)

proftpd: matthias AT rpmforge net
  F7-updates > F8 (0:1.3.1-2.fc7 > 0:1.3.1-1.fc8)

python-cheetah: mikeb AT redhat com
  FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7)

python-meld3: mmcgrath AT redhat com
  FE6 > F7 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)
  FE6 > F8 (0:0.6.3-1.fc6 > 0:0.6-2.fc7.1)

python-nltk: michel sylvan AT gmail com
  FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8)
  FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8)

qt4: than AT redhat com
  F7-updates > F8 (0:4.3.2-4.fc7 > 0:4.3.2-1.fc8)

queuegraph: bjohnson AT symetrix com
  FE6 > F7 (0:1.1-2.fc6 > 0:1.1-1.fc7)

smolt: mmcgrath AT redhat com
  FE6 > F7-updates (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc7)
  FE6 > F8 (0:0.9.9.2-1.fc6 > 0:0.9.9-1.fc8)

specto: lxtnow AT gmail com
  FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8)
  F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8)

util-vserver: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7)
  FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7)

wammu: lxtnow AT gmail com
  FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8)
  F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8)

weechat: i AT stingr net
  F7-updates > F8 (0:0.2.6-1.fc7 > 0:0.2.5-1.fc8)

xbase: tcallawa AT redhat com
  F7-updates > F8 (0:2.0.0-8.fc7 > 0:2.0.0-7.fc8)

xmlrpc-c: enrico scholz AT informatik tu-chemnitz de
  FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7)
  FE6 > F7 (0:1.06.18-1.fc6 > 0:1.06.11-2.fc7)

zaptel: jeff AT ocjtech us
  FE6 > F7 (0:1.4.6-1.fc6 > 0:1.4.2.1-1.fc7)

zynaddsubfx: green AT redhat com
  FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7)



From buildsys at fedoraproject.org  Wed Nov  7 12:43:38 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Wed,  7 Nov 2007 07:43:38 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-07
Message-ID: <20071107124338.6AE2815212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 5

    hugin-0.6.1-11.fc6
NEW koules-1.4-1.fc6 : Action game with multiplayer, network and sound support
    plone-3.0.2-2.fc6
    qdbm-1.8.76-1.fc6
    zope-2.10.5-1.fc6


Changes in Fedora Extras 6: 


hugin-0.6.1-11.fc6
------------------
* Mon Nov 05 2007 Bruno Postle <bruno at postle.net> 0.6.1-11
- fix for CVE-2007-5200 hugin unsafe temporary file usage
- bug #332401; bug #362851; bug #362861; bug #362871
- fix Source tag
- update license GPL -> GPLv2+

* Mon Aug 13 2007 Bruno Postle <bruno at postle.net> 0.6.1-7
- rebuild for boost soname change
- add enblend dependency as enblend is now in fedora

koules-1.4-1.fc6
----------------
* Sun Oct 28 2007 Lubomir Kundrak <lkundrak at redhat.com> 1.4-1
- From Red Hat Linux 4.2 back into life

plone-3.0.2-2.fc6
-----------------
* Tue Nov 06 2007 Jonathan Steffan <jon a fedoraunity.org> 3.0.2-2
- Add plone hotfix 20071106 (CVE-2007-5741)

qdbm-1.8.76-1.fc6
-----------------
* Sun Nov 04 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.76-1
- 1.8.76

* Wed Aug 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.75-3.dist.2
- Mass rebuild (buildID or binutils issue)

* Fri Aug 03 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.75-3.dist.1
- License update

* Sat Jun 16 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.75-3
- Fix java directory

zope-2.10.5-1.fc6
-----------------
* Sat Nov 03 2007 Jonathan Steffan <jon a fedoraunity.org> 2.10.5-1
- Update to zope 2.10.5



From paul at city-fan.org  Wed Nov  7 13:14:18 2007
From: paul at city-fan.org (Paul Howarth)
Date: Wed, 07 Nov 2007 13:14:18 +0000
Subject: desktop file handling question
In-Reply-To: <fgr7v2$iuf$1@ger.gmane.org>
References: <fgr7v2$iuf$1@ger.gmane.org>
Message-ID: <4731BA2A.8040407@city-fan.org>

Neal Becker wrote:
> I just updated kdiff3 from upstream.  It has added:
> %{_datadir}/applnk/.hidden/kdiff3plugin.desktop
> 
> I just added this to %files.  I'm guessing it doesn't need special handling,
> like desktop-file-install?

No, you _must_ run desktop-file-install

See: http://fedoraproject.org/wiki/Packaging/Guidelines#desktop

Paul.



From lkundrak at redhat.com  Wed Nov  7 13:26:34 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 07 Nov 2007 14:26:34 +0100
Subject: nfs-utils update problem (broken deps)
In-Reply-To: <fgqc37$t5a$1@ger.gmane.org>
References: <fgqc37$t5a$1@ger.gmane.org>
Message-ID: <1194441994.6559.2.camel@localhost.localdomain>


On Tue, 2007-11-06 at 19:34 +0100, Marcin Zaj?czkowski wrote:
> Package libtirpc needs libgssapi.so.2, this is not available.
> Package libtirpc needs libgssapi.so.2(libgssapi_CITI_2), this is not

What version of libtirpc do you have? Aren't you updating against
outdated mirror? libtirpc-0.1.7-13.fc8 and libtirpc-0.1.7-12.fc8 do not
require libgssapi, but libgssglue.so.1 instead.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From green at redhat.com  Wed Nov  7 13:35:55 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 07 Nov 2007 05:35:55 -0800
Subject: Mesa license issue?
In-Reply-To: <1193834673.21765.20.camel@localhost.localdomain>
References: <1193821480.5825.29.camel@localhost>	<1193823500.5825.33.camel@localhost>	<1193834344.21765.18.camel@localhost.localdomain>
	<1193834673.21765.20.camel@localhost.localdomain>
Message-ID: <4731BF3B.9000204@redhat.com>

Tom "spot" Callaway wrote:
> NM, it looks like SGI signed off on that change upstream when they moved
> to hosting those files at Khronos.

Do you have a reference or link explaining this?  I'm working with the 
JOGL upstream developers on their use of SGI FreeB licensed code and 
this was their reaction to me removing JOGL from Fedora (for now)...

> This seems like a harsh overreaction. Sun's legal team reviewed our 
 > use of the code covered under the SGI FreeB license and (with our
 > prodding) approved it despite potential legal exposure to Sun.
> 
> I don't think SGI's OpenGL sample implementation has been relicensed. 
 > I just downloaded the Mesa 7 sources and there is no mention of the
 > Khronos group anywhere. The portions of code we are using (the
 > GLU tessellator and mipmap code) have as far as I know been
> written basically once in the industry and we're not going to pull 
 > out their inclusion in JOGL. Both Mesa and XFree86 seem to be
 > comfortable including code covered by the SGI FreeB license.
> 
> If you have a more concrete pointer regarding a relicensing of this 
 > code I'll look into it.

Thanks,

AG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/85889896/attachment.vcf>

From atkac at redhat.com  Wed Nov  7 14:12:45 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 7 Nov 2007 15:12:45 +0100
Subject: When will be CVS replaced by modern version control system?
Message-ID: <20071107141245.GA4888@evileye.englab.brq.redhat.com>

Hi all,

CVS has already passed over best years. I'm wonder why modern
project like Fedora still has sources in this ancient system. Are here
any plans to replace it by git, mercurial, svn or other more modern
version control system?

Adam

-- 
Adam Tkac, Red Hat, Inc.



From ndbecker2 at gmail.com  Wed Nov  7 14:14:37 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 07 Nov 2007 09:14:37 -0500
Subject: desktop file handling question
References: <fgr7v2$iuf$1@ger.gmane.org> <4731BA2A.8040407@city-fan.org>
Message-ID: <fgsh8e$jm$1@ger.gmane.org>

Paul Howarth wrote:

> Neal Becker wrote:
>> I just updated kdiff3 from upstream.  It has added:
>> %{_datadir}/applnk/.hidden/kdiff3plugin.desktop
>> 
>> I just added this to %files.  I'm guessing it doesn't need special
>> handling, like desktop-file-install?
> 
> No, you _must_ run desktop-file-install
> 
> See: http://fedoraproject.org/wiki/Packaging/Guidelines#desktop
> 
> Paul.
> 

Does this look correct?
(Note, make install already installed into the same path. I'm assuming
desktop-file-install is OK with source==dest and --delete-original)

desktop-file-install  --vendor fedora \
        --dir $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden \
        --delete-original \
        $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden/kdiff3plugin.desktop




From monkeyboythom at gmail.com  Wed Nov  7 14:25:39 2007
From: monkeyboythom at gmail.com (Monkey Boy)
Date: Wed, 7 Nov 2007 09:25:39 -0500
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
Message-ID: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>

<Dr.Rumack>I just want to tell you all good luck. We're all counting on
you.</Dr.Rumack>

-- 
The difference between blogging and flogging is that flogging actually
leaves an impression on people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/a8dac943/attachment.htm>

From lesmikesell at gmail.com  Wed Nov  7 14:28:15 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 07 Nov 2007 08:28:15 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
Message-ID: <4731CB7F.9090808@gmail.com>

Adam Tkac wrote:
> Hi all,
> 
> CVS has already passed over best years. I'm wonder why modern
> project like Fedora still has sources in this ancient system. Are here
> any plans to replace it by git, mercurial, svn or other more modern
> version control system?

Do any of the modern projects have functional compatibility with the 
widely used CVS as a design goal?   Svn, for example, has very different 
concepts for tagging and requires some workflow changes for most 
organizations to switch.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From caillon at redhat.com  Wed Nov  7 14:38:14 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 07 Nov 2007 15:38:14 +0100
Subject: F9 Feature Process
In-Reply-To: <47293CBF.7020900@redhat.com>
References: <47293CBF.7020900@redhat.com>
Message-ID: <4731CDD6.90804@redhat.com>

John Poelstra wrote:
> 4) How do we (realistically) encourage people to keep their feature 
> pages up to date?  It was a pain to keep hounding people to keep the 
> status of their pages up to date--very few people kept them updated 
> every 2 weeks.  Considering how short our release cycle is I don't think 
> we can go much longer than that.

Before we ask this question, first ask what do we gain vs. lose from 
people updating the page every two weeks?  Do we gain anything?  Not 
much, really.  We get a false sense of security that it will get done on 
time or it won't get done on time.  A feature can get lots of work early 
on and then the maintainer(s) go AWOL and leave it at 70%.  Or there can 
be no updates for a long while as they are doing other things and then 
it gets done within the final two weeks before freeze.

And we lose engineering time from having to update the page.  For some 
of our contributors who are not paid to work on Fedora, this could be a 
non-insignificant portion of the time they can allot to Fedora.

Is it really worth getting people to update their feature page every two 
weeks?  I'd argue it's much better to start looking for updates in the 
week or two prior to the freeze as those will be more meaningful.  We 
should also encourage people to update their page regularly (or when 
their feature is completed), but I'm not convinced that enforcing this 
is a good idea.



From lightsolphoenix at gmail.com  Wed Nov  7 14:55:08 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 7 Nov 2007 09:55:08 -0500
Subject: Possible Replacements for the system-config-* utilities?
Message-ID: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>

Well, now that F8 is approaching release, I wanted to bring up the
possibility of updating the configuration utilities again.  I'd be
willing to work on such a project (fixing the frontend problems so the
utilities could be used without X, etc.), but I'm not entirely
familiar with all the options covered by the utilities (for example,
I've never used the cluster management or bootloader editor systems,
and I'm not completely familiar with all of the configuration files
here).  First of all, is there a preferred language for development
like this?  I've actually done very little to no Python development
(though I've done development in similar RAD languages like Ruby, Java
and C# so I'm familiar with the general concepts), but I'll give it a
shot in Python if that's preferred.  Secondly, is there a decent
resource for covering some of the configuration files required by the
programs?



From Christian.Iseli at licr.org  Wed Nov  7 14:55:03 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Wed, 7 Nov 2007 15:55:03 +0100
Subject: Petabytes and hierarchical storage management
Message-ID: <20071107155503.19d9377e@ludwig-alpha.unil.ch>

Hi folks,

Anybody here aware of open source tools to have a HSM solution in
Fedora ?

What I'm basically after is something that
 - mounts and behaves like a normal filesystem
 - can manage petabytes
 - automatically migrates files to tapes (or other fancy low cost per
megabytes storage device), based on some policy when they are unused
for some period of time, and loads them back the next time a process
attempts to open those files
 - can be exported through NFS and samba

Cheers,
					Christian



From mike.cohler at gmail.com  Wed Nov  7 15:01:57 2007
From: mike.cohler at gmail.com (Mike C)
Date: Wed, 7 Nov 2007 15:01:57 +0000 (UTC)
Subject: smolt server problem?
Message-ID: <loom.20071107T145835-699@post.gmane.org>

Does anyone know if there is a current server problem for smolt?

I posted some experiences in Fedora list, finally resulting in

"I wonder if this is related to the issue I am seeing:
On trying to simply view my profile I get in the browser:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /show.

Reason: Error reading from remote server

This comes from the server listed at the bottom of the web page
Apache/2.2.3 (Red Hat) Server at smolt.fedoraproject.org Port 80

So it seems that the problems appear to be within the smolt server."

I have copied this from:
http://marc.info/?l=fedora-list&m=119443732001288&w=2
and see related thread.



From jkeating at redhat.com  Wed Nov  7 15:05:31 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 7 Nov 2007 10:05:31 -0500
Subject: F9 Feature Process
In-Reply-To: <4731CDD6.90804@redhat.com>
References: <47293CBF.7020900@redhat.com>
	<4731CDD6.90804@redhat.com>
Message-ID: <20071107100531.541b6e0a@redhat.com>

On Wed, 07 Nov 2007 15:38:14 +0100
Christopher Aillon <caillon at redhat.com> wrote:

> Before we ask this question, first ask what do we gain vs. lose from 
> people updating the page every two weeks?  Do we gain anything?  Not 
> much, really.  We get a false sense of security that it will get done
> on time or it won't get done on time.  A feature can get lots of work
> early on and then the maintainer(s) go AWOL and leave it at 70%.  Or
> there can be no updates for a long while as they are doing other
> things and then it gets done within the final two weeks before freeze.
> 
> And we lose engineering time from having to update the page.  For
> some of our contributors who are not paid to work on Fedora, this
> could be a non-insignificant portion of the time they can allot to
> Fedora.
> 
> Is it really worth getting people to update their feature page every
> two weeks?  I'd argue it's much better to start looking for updates
> in the week or two prior to the freeze as those will be more
> meaningful.  We should also encourage people to update their page
> regularly (or when their feature is completed), but I'm not convinced
> that enforcing this is a good idea.

I agree that "every two weeks" seems arbitrary.  However we could time
getting updates a week or so before the Alpha, before the Beta, and
obviously more updates as we get nearer the final freeze.

Also it should be made known that we can do special snapshot live and
dvd spins of Rawhide at any point when it would make sense for a
Feature.  If a Feature has hit a significant milestone but it is still
too far away from either Alpha/Beta/rc's or one of the weekly snapshot
attempts after Beta, we can create a snapshot and highlight the Feature
in question.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/9f6b7637/attachment.sig>

From jima at beer.tclug.org  Wed Nov  7 15:15:04 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 7 Nov 2007 09:15:04 -0600 (CST)
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0711070914280.4486@beer.tclug.org>

On Wed, 7 Nov 2007, Monkey Boy wrote:
> <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> you.</Dr.Rumack>

  Surely you can't be serious!

      Jima



From markg85 at gmail.com  Wed Nov  7 15:23:05 2007
From: markg85 at gmail.com (Mark)
Date: Wed, 7 Nov 2007 16:23:05 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
Message-ID: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>

Hey,

Fedora 8 has dropped the readahead program which was fine because it
wasn't speeding up anything at all (not in my experience) but i do
think we need some kind of a caching for the start menu and serveral
other programs.

This is the current case when you install fedora (any version) and go
to the start menu:
- Sometimes it doesn't even show up on the first click simply because
it still has to load/start(? just feels slow)
- When it pops up (the first time after boot) the icons are not there
at first.. they come quick but they should be pre cached

What would be best with the start menu:
- During boot the start menu and all it's icons (actually all the
default icons) should be cached so that the start menu pops up right
away when you click on it and all the icons are in place and vissible.

Now about the caching itself.
Wouldn't it be best to precache all the applications that are gonna be
started anyway? like:
- gome-desktop
- gnoma-panel
- the default gnome applets
- nautilus
- firefox
- the default mail client (forgot the name)
- the default wallpaper
- precache all the icons that where on the desktop in the last session
so they appear fast when gnome starts
- perhaps also GDM so that you don't see the picture building up like
you see at this moment in nearly all linux distributions.
- Also for gdm: perhaps a good idea to fade it in like in windows..
was also requested here:
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/22903 but it
doesn't seem like they got far with it. it's not in gutsy (i didn't
see it).

And perhaps some less importand programs that get used often:
- Pidgin
- the most used irc client (whichever one that is)
- and probable a dozen more

So what do you think of those suggestions?
lets make Fedora 9 more user friendly than Fedora 8 (not that 8 or 7
are not friendly).

Btw.. what is gonna be the idea with Fedora 9? is it gonna be a
release with a ton of new features but no (or nearly no) improvements
to current features? or is it gonne be a release to improve all the
current features of fedora? that last part would be good for fedora.

Mark



From jeff at ocjtech.us  Wed Nov  7 15:23:08 2007
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 7 Nov 2007 09:23:08 -0600
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <Pine.LNX.4.64.0711070914280.4486@beer.tclug.org>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
	<Pine.LNX.4.64.0711070914280.4486@beer.tclug.org>
Message-ID: <935ead450711070723n59cae05cq23c0d9a07784bca@mail.gmail.com>

On 11/7/07, Jima <jima at beer.tclug.org> wrote:
>
> On Wed, 7 Nov 2007, Monkey Boy wrote:
> > <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> > you.</Dr.Rumack>
>
>   Surely you can't be serious!
>

Yes, I am serious. Ans stop calling me Shirley.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/980c586d/attachment.htm>

From jeff at ocjtech.us  Wed Nov  7 15:40:18 2007
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 7 Nov 2007 09:40:18 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
Message-ID: <935ead450711070740i304ef716ra1a9823cf1b878e4@mail.gmail.com>

On 11/7/07, Adam Tkac <atkac at redhat.com> wrote:

>
> CVS has already passed over best years. I'm wonder why modern
> project like Fedora still has sources in this ancient system. Are here
> any plans to replace it by git, mercurial, svn or other more modern
> version control system?
>

It's been discussed many times on this list and others.  Search the
archives.  The main problems is that no one can agree on which version
control system to switch to. Both Git and Mercurial have strong proponents.
Bazaar and Subversion have proponents as well.

A related problem has been that until recently Koji supported only CVS.
I've seen recent work on Koji to support Git and SVN but that code isn't
running on the production buildsystems AFAIK.  I haven't seen any work on
Plague yet (Plague will be needed until Koji is ready to build packages for
EPEL).

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/7bb28fc0/attachment.htm>

From rdieter at math.unl.edu  Wed Nov  7 15:48:28 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 07 Nov 2007 09:48:28 -0600
Subject: desktop file handling question
References: <fgr7v2$iuf$1@ger.gmane.org> <4731BA2A.8040407@city-fan.org>
	<fgsh8e$jm$1@ger.gmane.org>
Message-ID: <fgsmod$lu0$1@ger.gmane.org>

Neal Becker wrote:

> Does this look correct?
> (Note, make install already installed into the same path. I'm assuming
> desktop-file-install is OK with source==dest and --delete-original)
> 
> desktop-file-install  --vendor fedora \
>         --dir $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden \
>         --delete-original \
>         $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden/kdiff3plugin.desktop

I'd recommend instead:
 desktop-file-install  --vendor="" \
     --dir $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden
     $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden/kdiff3plugin.desktop

Or (prefered)
echo "NoDisplay=true" >> \
$RPM_BUILD_ROOT%{_datadir}/applnk/.hidden/kdiff3plugin.desktop
 desktop-file-install  --vendor="" \
     --dir $RPM_BUILD_ROOT%{_datadir}/applications/kde
     --delete-original \
     $RPM_BUILD_ROOT%{_datadir}/applnk/.hidden/kdiff3plugin.desktop

and talk to upstream about making the latter change, so as not to use the
legacy applnk dirs at all.

-- Rex



From triad at df.lth.se  Wed Nov  7 16:28:03 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 7 Nov 2007 17:28:03 +0100 (CET)
Subject: Removal of pam_console questions
In-Reply-To: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
Message-ID: <Pine.GSO.4.60.0711071726440.27844@igloo.df.lth.se>

Hm either:

1. NOBODY have a clue how HAL ACLs work or how to use them or,

2. EVERYBODY knows that and they're just shaking their heads because I'm
    so lame I don't get this simple thing...

I wonder which one it is.

Linus



From notting at redhat.com  Wed Nov  7 16:59:39 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 7 Nov 2007 11:59:39 -0500
Subject: Removal of pam_console questions
In-Reply-To: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
Message-ID: <20071107165939.GA21013@nostromo.devel.redhat.com>

Linus Walleij (triad at df.lth.se) said: 
> I read this some time ago:
> http://fedoraproject.org/wiki/Releases/FeatureRemovePAMConsole
>
> I guess libmtp and libnjb which I maintain need to be updated to work with 
> HAL ACLs. They both create a node /dev/libxxx-nnn and place a file in 
> /etc/security/console.perms.d/ each, like this:
>
> <libnjb>=/dev/libnjb*
> <console> 0600 <libnjb> 0600 root
>
> However I am not certain as to how one migrate to HAL+ACLs for this, can 
> someone point to a package which is properly migrated already and tell how 
> it's basically done so I can have a look and fix this?
>
> (If you wanna hack the packages in CVS since you think it's quicker to just 
> do it than explain how to do it, then just go ahead...)

They 'both create a node'... is this a manually created device node,
not through udev?

Bill



From triad at df.lth.se  Wed Nov  7 17:07:48 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 7 Nov 2007 18:07:48 +0100 (CET)
Subject: Removal of pam_console questions
In-Reply-To: <20071107165939.GA21013@nostromo.devel.redhat.com>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
	<20071107165939.GA21013@nostromo.devel.redhat.com>
Message-ID: <Pine.GSO.4.60.0711071805160.1084@igloo.df.lth.se>

On Wed, 7 Nov 2007, Bill Nottingham wrote:

[thanks for answering...]

>> They both create a node /dev/libxxx-nnn and (...)
>
> They 'both create a node'... is this a manually created device node,
> not through udev?

It's created by udev, in order for pam_console to have something to hold 
on to, since it's a link to /dev/usb/00x/0yy/... (unpredictable, opaque 
device node).

This is then used by USB like the usermode scanner driver in 
sane-backends. (Same method there I think.)

Linus



From silfreed at silfreed.net  Wed Nov  7 17:08:40 2007
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Wed, 7 Nov 2007 12:08:40 -0500
Subject: Removal of pam_console questions
In-Reply-To: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
Message-ID: <200711071208.46014.silfreed@silfreed.net>

On Tuesday 06 November 2007, Linus Walleij wrote:
> However I am not certain as to how one migrate to HAL+ACLs for this, can
> someone point to a package which is properly migrated already and tell
> how it's basically done so I can have a look and fix this?

You can take a look at my harmony package and see how I set things up with 
udev, hal, pam_console, and PolicyKit.  It didn't make it into Fedora due to 
trademark concerns, but you can still follow the review and see how things 
look.
https://bugzilla.redhat.com/show_bug.cgi?id=328161

-Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/efa72f3d/attachment.sig>

From alan at clueserver.org  Wed Nov  7 17:11:07 2007
From: alan at clueserver.org (alan)
Date: Wed, 7 Nov 2007 09:11:07 -0800 (PST)
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0711070910450.32256@blackbox.fnordora.org>

On Wed, 7 Nov 2007, Monkey Boy wrote:

> <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> you.</Dr.Rumack>

"Where wolf?  There wolf!"

-- 
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.



From mdehaan at redhat.com  Wed Nov  7 18:12:09 2007
From: mdehaan at redhat.com (Michael DeHaan)
Date: Wed, 07 Nov 2007 13:12:09 -0500
Subject: Call for developers!  It's Func!  Systems management is fun again!
Message-ID: <4731FFF9.6010105@redhat.com>

Hey folks!

I sent this out to fedora-list, but this is really just as much a 
developer topic.   Several us have been working on a neat network 
application called Func lately, which is part of Fedora hosted projects ...

https://hosted.fedoraproject.org/projects/func

Func is basically a remote RPC system with integrated secure certificate 
exchange, all massively pluggable in python.   It comes with a lot of 
modules useful for control of remote systems, you can easily script 
communications to multiple machines,  and easily write new modules on 
both the client side and the server side.   Whether this means running 
remote commands,  querying hardware inventory, or controlling a bunch of 
robots or LED signs -- we really intend this to be a generic and crazy 
simple thing to use.    The Wiki helps explain this in a lot of detail.

Func comes with some neat scripts that integrate with lots of Fedora 
tools -- like Smolt (find all my laptops with exploding batteries), 
Nagios (query lots of plugins remotely without even having to have 
nagios installed), and so on.   There's  also a shiny inventory app that 
tracks changes to all of your systems using git... written in /just/ 200 
lines of Python.   Hopefully  that demonstrates how powerful the Func 
API can be.

Anyhow, we'd really like all of you (especially Sysadmin, Python, or 
network programming types) to get involved.   Also, if you are writing a 
new Fedora app that needs remote communications capability, you can use 
func to establish a PKI infrastructure.    It's already in Fedora and 
EPEL alike.

Contribute new modules, hack on the core, or share some interesting 
scripts you have to automate all of your Fedora and Enterprise Linux 
machines.  If this sounds like something you are interested in, check 
out the Wiki (https://hosted.fedoraproject.org/projects/func), join the 
mailing list, and stop by #func on irc.freenode.net -- your questions, 
ideas, and of course code are always welcome!

--Michael



From dwalsh at redhat.com  Wed Nov  7 17:18:16 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 07 Nov 2007 12:18:16 -0500
Subject: NFS Update and SELinux
In-Reply-To: <1194371113.4985.3.camel@localhost6.localdomain6>
References: <1193856288.12145.9.camel@localhost6.localdomain6>	<472A13D9.4010105@redhat.com>	<1193941654.3848.5.camel@localhost6.localdomain6>	<473087ED.7020101@redhat.com>
	<1194371113.4985.3.camel@localhost6.localdomain6>
Message-ID: <4731F358.7040405@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richi Plana wrote:
> On Tue, 2007-11-06 at 10:27 -0500, Daniel J Walsh wrote:
>> Ok please update to the latest fc7 policy.
>> selinux-policy-2.6.4-53.fc7 is in testing.
>>
>> I definitely see a path match for this in there.
>>
>> grep usbmon policy-20070501.patch
>> +/dev/usbmon[0-9]+      -c
>> gen_context(system_u:object_r:usb_device_t,s0)
> 
> Yes, so did I. I just didn't bother to post. I'm glad to say that it
> WORKSFORME, though.
> 
> I _WAS_ thinking of asking, however, what sort of actions can be placed
> in the %post section of packages which need immediate action? I know
> some services restart themselves after package updates (but some don't.
> I wonder if this should be made policy). In the case of selinux, would a
> kernel module reload solve the mislabeled device files? A restart? (I
> did notice that at one point in time, I got an advisory to restart the
> computer after a set of updates. I can't remember where or what it was
> now)
> --
> 
> Richi Plana
> 
selinux-policy attempts to fix labeling as it updates.  Most of the time
you should/would not need to do anything.  But occasionally restarting
domains/programs is necessary.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHMfNXrlYvE4MpobMRAkRZAKDSAZZbR18OXhNuOrEpTLRozQvhswCgyg9y
LO0s27NTLG8sjFf6n4BZBFU=
=XUHT
-----END PGP SIGNATURE-----



From jwboyer at gmail.com  Wed Nov  7 17:41:58 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 7 Nov 2007 11:41:58 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
Message-ID: <20071107114158.6cf5f250@weaponx>

On Wed, 7 Nov 2007 15:12:45 +0100
Adam Tkac <atkac at redhat.com> wrote:

> Hi all,
> 
> CVS has already passed over best years. I'm wonder why modern
> project like Fedora still has sources in this ancient system. Are here
> any plans to replace it by git, mercurial, svn or other more modern
> version control system?

Replacing a VCS for the fun of it is pretty pointless.  Can you
elaborate on a workflow you would like to see that CVS is not suited
to?  Right now, CVS works fine for what we do, which is mostly editing
spec files.

I am by no means a proponent of CVS.  I think it sucks.  But we have no
_usecase_ for a different VCS at the moment.

josh



From david at lovesunix.net  Wed Nov  7 17:46:11 2007
From: david at lovesunix.net (David Nielsen)
Date: Wed, 07 Nov 2007 18:46:11 +0100
Subject: F9 Feature Process
In-Reply-To: <4731CDD6.90804@redhat.com>
References: <47293CBF.7020900@redhat.com>  <4731CDD6.90804@redhat.com>
Message-ID: <1194457571.4622.14.camel@dawkins>


ons, 07 11 2007 kl. 15:38 +0100, skrev Christopher Aillon:

> 
> Is it really worth getting people to update their feature page every two 
> weeks?  I'd argue it's much better to start looking for updates in the 
> week or two prior to the freeze as those will be more meaningful.  We 
> should also encourage people to update their page regularly (or when 
> their feature is completed), but I'm not convinced that enforcing this 
> is a good idea.

Having reasonably updatyed feature pages really aids in advocacy. It
gives us a place to point people to as a means of showing what is
coming. Additionally not having the updated before the last few weeks
makes it look like we never do anything, which we can agree is untrue.

Meaning is not just having a finished product, it's marketing it,
getting people interested in the product and it's placing it in a larger
software ecosystem. Please feel free to tell us empty but expensive
sounding words of love when explaining to us how your feature will
improve our lives. We like that.. it makes us all hot and bothered about
Fedora.

I'd say every 2-4 weeks we ping the feature owners who haven't updated
and ask them to take the time to put down a few words on the progress.

Preview writers will have places to look when getting excited about the
next Fedora. Also having clear progress on active features makes them
visible so that when we release, the feature will be known as born and
raised in Fedora.. hopefully a growing commitment to telling the world
on going what we are doing will reducing the amount of reviews I have to
read wherein Ubuntu is credited as the genesis for half our features.
The horrible journalistic skills involved here just makes the situation
even sadder - nobody actually checks their facts and never have I seen a
review get amended when I send in factual corrections. I want our
features praised when they come out.. in Fedora.. I want our developers
to get the attribution they sorely deserve. Please help make that
happen, update your feature page.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/539b63ee/attachment.sig>

From opensource at till.name  Wed Nov  7 18:38:41 2007
From: opensource at till.name (Till Maas)
Date: Wed, 07 Nov 2007 19:38:41 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107114158.6cf5f250@weaponx>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
Message-ID: <200711071938.48209.opensource@till.name>

On Mi November 7 2007, Josh Boyer wrote:

> Replacing a VCS for the fun of it is pretty pointless.  Can you
> elaborate on a workflow you would like to see that CVS is not suited
> to?  Right now, CVS works fine for what we do, which is mostly editing
> spec files.

"cvs diff" makes afaik a network connection, which makes it very slow compared 
to a modern vcs. Also tagging / commit takes very long imho, but maybe this 
is because of all the hook scripts. Afaik, there is nothing than one can do 
about it as a maintainer to speed this up.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/c809e0de/attachment.sig>

From bpepple at fedoraproject.org  Wed Nov  7 18:49:16 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 07 Nov 2007 13:49:16 -0500
Subject: Plan for tomorrows (20071108) FESCO meeting
Message-ID: <1194461356.16428.9.camel@nixon>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic Misc - Feature Process -
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00003.html - poelcat 

/topic FESCo meeting -- Free discussion around Fedora

You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, but we'll most likely will if we don't run out of time).
You can also propose topics in the meeting while it is in the "Free
discussion around Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing... 
Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/44a9d21e/attachment.sig>

From dcbw at redhat.com  Wed Nov  7 19:38:03 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 07 Nov 2007 14:38:03 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <935ead450711070740i304ef716ra1a9823cf1b878e4@mail.gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<935ead450711070740i304ef716ra1a9823cf1b878e4@mail.gmail.com>
Message-ID: <1194464283.3449.13.camel@localhost.localdomain>

On Wed, 2007-11-07 at 09:40 -0600, Jeffrey Ollie wrote:
> On 11/7/07, Adam Tkac <atkac at redhat.com> wrote:
>         
>         CVS has already passed over best years. I'm wonder why modern
>         project like Fedora still has sources in this ancient system.
>         Are here
>         any plans to replace it by git, mercurial, svn or other more
>         modern
>         version control system? 
> 
> It's been discussed many times on this list and others.  Search the
> archives.  The main problems is that no one can agree on which version
> control system to switch to. Both Git and Mercurial have strong
> proponents. Bazaar and Subversion have proponents as well. 
> 
> A related problem has been that until recently Koji supported only
> CVS.  I've seen recent work on Koji to support Git and SVN but that
> code isn't running on the production buildsystems AFAIK.  I haven't
> seen any work on Plague yet (Plague will be needed until Koji is ready
> to build packages for EPEL). 

It wouldn't be that hard to add to plague either, as long as the method
of getting the common directory and using tags and such works.

Dan

> Jeff
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From andy at smile.org.ua  Wed Nov  7 19:52:01 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Wed, 7 Nov 2007 21:52:01 +0200
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711071938.48209.opensource@till.name>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<200711071938.48209.opensource@till.name>
Message-ID: <20071107195201.GA4263@serv.smile.org.ua>

Hi Till Maas!

 On Wed, Nov 07, 2007 at 07:38:41PM +0100, Till Maas wrote next:

> "cvs diff" makes afaik a network connection, which makes it very slow compared 
> to a modern vcs. 
Modern vcs requires additional space for this operation.
And second, I doubt in usefull status of this feature. IMHO, in practice (another
words 'very often') you need to make diff between vcs' *.spec and current.
You just make copy *.spec to *.spec.orig and use simple diff command.

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From jwboyer at gmail.com  Wed Nov  7 19:53:39 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 7 Nov 2007 13:53:39 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711071938.48209.opensource@till.name>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<200711071938.48209.opensource@till.name>
Message-ID: <20071107135339.30ca308a@weaponx>

On Wed, 07 Nov 2007 19:38:41 +0100
Till Maas <opensource at till.name> wrote:

> On Mi November 7 2007, Josh Boyer wrote:
> 
> > Replacing a VCS for the fun of it is pretty pointless.  Can you
> > elaborate on a workflow you would like to see that CVS is not suited
> > to?  Right now, CVS works fine for what we do, which is mostly editing
> > spec files.
> 
> "cvs diff" makes afaik a network connection, which makes it very slow compared 
> to a modern vcs. Also tagging / commit takes very long imho, but maybe this 
> is because of all the hook scripts. Afaik, there is nothing than one can do 
> about it as a maintainer to speed this up.

You're going to come across that in any centralized type workflow.
Which, ultimately, is exactly what Fedora is.

josh



From a.badger at gmail.com  Wed Nov  7 20:05:58 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 07 Nov 2007 12:05:58 -0800
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107135339.30ca308a@weaponx>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<200711071938.48209.opensource@till.name>
	<20071107135339.30ca308a@weaponx>
Message-ID: <47321AA6.4080603@gmail.com>

Josh Boyer wrote:
> On Wed, 07 Nov 2007 19:38:41 +0100
> Till Maas <opensource at till.name> wrote:
> 
>> On Mi November 7 2007, Josh Boyer wrote:
>>
>>> Replacing a VCS for the fun of it is pretty pointless.  Can you
>>> elaborate on a workflow you would like to see that CVS is not suited
>>> to?  Right now, CVS works fine for what we do, which is mostly editing
>>> spec files.
>> "cvs diff" makes afaik a network connection, which makes it very slow compared 
>> to a modern vcs. Also tagging / commit takes very long imho, but maybe this 
>> is because of all the hook scripts. Afaik, there is nothing than one can do 
>> about it as a maintainer to speed this up.
> 
> You're going to come across that in any centralized type workflow.
> Which, ultimately, is exactly what Fedora is.
> 
...for tagging/commit.

diff can be done without a network connection every single time even 
with centralized management.

-Toshio



From mclasen at redhat.com  Wed Nov  7 20:17:28 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 07 Nov 2007 15:17:28 -0500
Subject: Removal of pam_console questions
In-Reply-To: <Pine.GSO.4.60.0711071726440.27844@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
	<Pine.GSO.4.60.0711071726440.27844@igloo.df.lth.se>
Message-ID: <1194466648.4333.15.camel@localhost.localdomain>


On Wed, 2007-11-07 at 17:28 +0100, Linus Walleij wrote:
> Hm either:
> 
> 1. NOBODY have a clue how HAL ACLs work or how to use them or,
> 
> 2. EVERYBODY knows that and they're just shaking their heads because I'm
>     so lame I don't get this simple thing...
> 
> I wonder which one it is.

Probably more like 

 3. This is a very busy list, and not the best place to ask hal
questions, since the hal developers may be busy doing other things (or
maybe not on this list at all). You have a much better chance getting
answers to specific hal questions on the hal mailing list, I'd expect.

hal at lists.freedesktop.org is the hal list.

Matthias



From tjanouse at redhat.com  Wed Nov  7 20:26:11 2007
From: tjanouse at redhat.com (Tomas Janousek)
Date: Wed, 7 Nov 2007 21:26:11 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107195201.GA4263@serv.smile.org.ua>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<200711071938.48209.opensource@till.name>
	<20071107195201.GA4263@serv.smile.org.ua>
Message-ID: <20071107202611.GA31380@redhat.com>

Hello,

On Wed, Nov 07, 2007 at 09:52:01PM +0200, Andy Shevchenko wrote:
>  On Wed, Nov 07, 2007 at 07:38:41PM +0100, Till Maas wrote next:
> > "cvs diff" makes afaik a network connection, which makes it very slow compared 
> > to a modern vcs. 
> 
> Modern vcs requires additional space for this operation.
> And second, I doubt in usefull status of this feature. IMHO, in practice (another
> words 'very often') you need to make diff between vcs' *.spec and current.
> You just make copy *.spec to *.spec.orig and use simple diff command.

Well, in practice, I sometimes need a whole patchset from some old history of
the specfile. This is practically impossible with cvs, so I keep a git mirror
of the entire cvs directory, anyway.

-- 
TJ. (Brno, CZ), BaseOS, Red Hat



From jwboyer at gmail.com  Wed Nov  7 20:37:58 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 7 Nov 2007 14:37:58 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <47321AA6.4080603@gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<200711071938.48209.opensource@till.name>
	<20071107135339.30ca308a@weaponx> <47321AA6.4080603@gmail.com>
Message-ID: <20071107143758.419e9a46@weaponx>

On Wed, 07 Nov 2007 12:05:58 -0800
Toshio Kuratomi <a.badger at gmail.com> wrote:

> Josh Boyer wrote:
> > On Wed, 07 Nov 2007 19:38:41 +0100
> > Till Maas <opensource at till.name> wrote:
> > 
> >> On Mi November 7 2007, Josh Boyer wrote:
> >>
> >>> Replacing a VCS for the fun of it is pretty pointless.  Can you
> >>> elaborate on a workflow you would like to see that CVS is not suited
> >>> to?  Right now, CVS works fine for what we do, which is mostly editing
> >>> spec files.
> >> "cvs diff" makes afaik a network connection, which makes it very slow compared 
> >> to a modern vcs. Also tagging / commit takes very long imho, but maybe this 
> >> is because of all the hook scripts. Afaik, there is nothing than one can do 
> >> about it as a maintainer to speed this up.
> > 
> > You're going to come across that in any centralized type workflow.
> > Which, ultimately, is exactly what Fedora is.
> > 
> ...for tagging/commit.
> 
> diff can be done without a network connection every single time even 
> with centralized management.

Yes, true.

josh



From lesmikesell at gmail.com  Wed Nov  7 20:57:50 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 07 Nov 2007 14:57:50 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107202611.GA31380@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<200711071938.48209.opensource@till.name>	<20071107195201.GA4263@serv.smile.org.ua>
	<20071107202611.GA31380@redhat.com>
Message-ID: <473226CE.60201@gmail.com>

Tomas Janousek wrote:
> Hello,
> 
> On Wed, Nov 07, 2007 at 09:52:01PM +0200, Andy Shevchenko wrote:
>>  On Wed, Nov 07, 2007 at 07:38:41PM +0100, Till Maas wrote next:
>>> "cvs diff" makes afaik a network connection, which makes it very slow compared 
>>> to a modern vcs. 
>> Modern vcs requires additional space for this operation.
>> And second, I doubt in usefull status of this feature. IMHO, in practice (another
>> words 'very often') you need to make diff between vcs' *.spec and current.
>> You just make copy *.spec to *.spec.orig and use simple diff command.
> 
> Well, in practice, I sometimes need a whole patchset from some old history of
> the specfile. This is practically impossible with cvs, so I keep a git mirror
> of the entire cvs directory, anyway.

If you run cvsweb (now viewvc) on the cvs repository it is easy to 
cherry-pick any file/revision you want or diff between any committed 
versions through the browser interface.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From pertusus at free.fr  Wed Nov  7 21:20:01 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 7 Nov 2007 22:20:01 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
Message-ID: <20071107212000.GA2558@free.fr>

On Wed, Nov 07, 2007 at 04:23:05PM +0100, Mark wrote:
> Hey,
> 
> Now about the caching itself.
> Wouldn't it be best to precache all the applications that are gonna be
> started anyway? like:

You mean on a gnome desktop? Or in fedora? I personnally don't start
much of those apps, and so would a kde/xfce user.

--
Pat



From mszpak at wp.pl  Wed Nov  7 21:21:38 2007
From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=)
Date: Wed, 07 Nov 2007 22:21:38 +0100
Subject: libgnome update problem (broken deps) (Was: Re: Fedora 8 Test3
 and problem with updates)
In-Reply-To: <47311D34.5070208@fedoraproject.org>
References: <fghn21$6dv$1@ger.gmane.org>	<20071103125316.GD6839@auslistsprd01.us.dell.com>	<fgieve$73e$1@ger.gmane.org>	<fgincp$un4$1@ger.gmane.org>	<fgqcip$ute$1@ger.gmane.org>	<1194375426.3963.15.camel@localhost.localdomain>
	<47311D34.5070208@fedoraproject.org>
Message-ID: <fgta93$urp$1@ger.gmane.org>

On 2007-11-07 03:04, Rahul Sundaram wrote:
> Matthias Clasen wrote:
>> On Tue, 2007-11-06 at 19:42 +0100, Marcin Zaj?czkowski wrote:
>>
>>> ERROR with rpm_check_debug vs depsolve:
>>> Package nodoka-theme-gnome needs redhat-artwork >= 7.0.0, this is not
>>> available.
>>> Complete!
>>
>> What version of nodoka-theme-gnome do you have installed ?
>> I don't see that dependency here:
>>
>> [mclasen at localhost gtk]$ rpm -q nodoka-theme-gnome
>> nodoka-theme-gnome-0.3.2-2.fc8
> 
> In one of the systems that I looked at there was a duplicate package
> which resulted in conflicts. It is better to run
> 
> # package-cleanup --cleandupes
> 
> to check. package-cleanup is part of yum-utils.

cleandupes didn't help, but anm old version of nodoka-theme-gnome was a
problem. It relies on redhat-artwork. Newer version of
nodoka-theme-gnome depends on fedora-icon-theme, but fedora-icon-theme
doesn't obsolete redhat-artwork and I was required to remove completely
redhat-artwork (and for satisfy dependency nodoka-theme-gnome) and later
install new nodoka-theme-gnome (and fedora-icon-theme for satisfy
dependency).

Maybe fedora-icon-theme should obsoletes redhat-artwork (if they have
shared files)?


Thanks for help
Marcin



From mszpak at wp.pl  Wed Nov  7 21:23:30 2007
From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=)
Date: Wed, 07 Nov 2007 22:23:30 +0100
Subject: nfs-utils update problem (broken deps)
In-Reply-To: <1194441994.6559.2.camel@localhost.localdomain>
References: <fgqc37$t5a$1@ger.gmane.org>
	<1194441994.6559.2.camel@localhost.localdomain>
Message-ID: <fgtaci$urp$2@ger.gmane.org>

On 2007-11-07 14:26, Lubomir Kundrak wrote:
> On Tue, 2007-11-06 at 19:34 +0100, Marcin Zaj?czkowski wrote:
>> Package libtirpc needs libgssapi.so.2, this is not available.
>> Package libtirpc needs libgssapi.so.2(libgssapi_CITI_2), this is not
> 
> What version of libtirpc do you have? Aren't you updating against
> outdated mirror? libtirpc-0.1.7-13.fc8 and libtirpc-0.1.7-12.fc8 do not
> require libgssapi, but libgssglue.so.1 instead.

I had to update all four packages is a one transaction and then it worked.


Thanks for help
Marcin



From notting at redhat.com  Wed Nov  7 21:42:42 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 7 Nov 2007 16:42:42 -0500
Subject: Removal of pam_console questions
In-Reply-To: <Pine.GSO.4.60.0711071805160.1084@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
	<20071107165939.GA21013@nostromo.devel.redhat.com>
	<Pine.GSO.4.60.0711071805160.1084@igloo.df.lth.se>
Message-ID: <20071107214242.GA6190@nostromo.devel.redhat.com>

Linus Walleij (triad at df.lth.se) said: 
>> They 'both create a node'... is this a manually created device node,
>> not through udev?
>
> It's created by udev, in order for pam_console to have something to hold on 
> to, since it's a link to /dev/usb/00x/0yy/... (unpredictable, opaque device 
> node).
>
> This is then used by USB like the usermode scanner driver in sane-backends. 
> (Same method there I think.)

So, the best place to look is:

/usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi
 or
/usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi

Here, you'd write/generate stanzas that match on the proper IDs, and
append some sort of capability string that defines the device. (Possibly
piggybacking on the portable_audio_player definitions, although I don't
know how standardized they are.

Then, look at:

/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi

Here you'd write/generate stanzas that:

- match against that added capability of the device in HAL
- appends access_control to the capabilities
- merges in the access_control.file and type that show the proper device
  node, and the 'type' of the device

The HAL list probably has more examples of this to crib from.

Bill



From sandeen at redhat.com  Wed Nov  7 21:43:25 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 07 Nov 2007 15:43:25 -0600
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
Message-ID: <4732317D.3080303@redhat.com>

Mark wrote:
> What would be best with the start menu:
> - During boot the start menu and all it's icons (actually all the
> default icons) should be cached so that the start menu pops up right
> away when you click on it and all the icons are in place and vissible.

Seems like it would be better if gnome itself did this precaching when
it starts - not the boot process.  (maybe that's what you meant).  I
don't know if gnome does its own caching of the icons after the first
read, or if it reads the files each time you click and hopes for OS
caching?  I agree though, waiting for the first click to go drag the
icons off the disk is painful.

> Now about the caching itself.
> Wouldn't it be best to precache all the applications that are gonna be
> started anyway? like:
> - gome-desktop
> - gnoma-panel
> - the default gnome applets
....

that's called "readahead" right?  We have the infrastructure, but I
think it needs some love.  It's hard to keep the file list up to date,
and when it's wrong, it hurts more than it helps...

-Eric



From Lam at Lam.pl  Wed Nov  7 21:45:56 2007
From: Lam at Lam.pl (Leszek Matok)
Date: Wed, 7 Nov 2007 22:45:56 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
Message-ID: <20071107224556.5dfb328c@pensja.lam.pl>

Dnia 2007-11-07, o godz. 16:23:05 Mark <markg85 at gmail.com> napisa?(a):

> What would be best with the start menu:
> - During boot the start menu and all it's icons (actually all the
> default icons) should be cached so that the start menu pops up right
> away when you click on it and all the icons are in place and vissible.
Not at boot. Not by any external readahead-like program. It should be loaded
by gnome-panel and its "main menu" icon or the default main menu, only, if it
is visible (added to the panel).

I can only guess that some people have the menu and don't use it, and not
loading it leaves some memory for other programs. Sounds like a nice feature
for low-end machines. On my low-end machine, loading the menu and icons can
take up to a minute. Imagine yourself waiting a whole minute longer to be able
to use your DE.

> Wouldn't it be best to precache all the applications that are gonna be
> started anyway? like:
> - gome-desktop
(...)
Yeah, especially by KDE users.

> - firefox
> - the default mail client (forgot the name)
> - the default wallpaper
I don't use those, so leave my system faster, and for you: why longer the boot
time, when you will get the apps loaded as soon as you log in and run them?

> - precache all the icons that where on the desktop in the last session
> so they appear fast when gnome starts
Again: not before someone logs in, and if you log in, they get loaded anyhow.

> - perhaps also GDM so that you don't see the picture building up like
> you see at this moment in nearly all linux distributions.
BTW: what happened to the "die-ugly-pattern-die-die-die" patch for Xorg? Or is
just my Fedora broken in the ugly-pattern matter?

> And perhaps some less importand programs that get used often:
Only if your session history shows that you use the programs. That would
require gathering and keeping of lots of statistics about files opened by you
when you're logged in. This would expand to precache documents which you're
going to open in a minute and so on, but I'm afraid

Instead of going after precaching things which then get wiped from memory when
I do things other ways than usual, losing the time instead of gaining it,
let's concentrate on making it obvious to people that something is going on.
You can't make everything to happen instantly. Making slow things a little bit
less slow doesn't gain anything, when the system isn't responsive. I need an
immediate response to my actions, then I can wait as long it takes to finish
the task.

I mean, if I open a document, a video file, a new gnome-terminal tab, I have
to wait few seconds to see any effect (like OOo popup, MPlayer window, new
terminal tab, without shell at first). This makes me wonder: did I really
press that button? Did I double-click that icon?

I've seen tens (!) of people running two-digit number of Outlook Express or
Word instances on Windows just because there was no indication that the
program was already being scheduled to be run. I'm very glad that in Fedora
(at least in GNOME), when I run a program from the panel, I see an immediate
effect (it's a new button in wnck-applet). I can see the computer is doing
what I'm telling it to do. But other than running things from the panel, all
my other tasks leave me wondering all the time: did I really press that button
or should I press it few more times?

This isn't easy to fix today, after years of lousy programming. Now it's
impossible to make it some system-wise user notification system. Or am I
wrong? Maybe there's some wonder libusermadnesspreventer.so that can be linked
to fix any program? :) Or is open market expected to regulate things (good
programs win over bad programs - is Evolution still the default MTA?) over
time?

Okay, thanks for reading to this point, I think I'm done. Thanks again.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/1baa8693/attachment.sig>

From mcepl at redhat.com  Wed Nov  7 21:47:07 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 07 Nov 2007 22:47:07 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
Message-ID: <slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>

On 2007-11-07, 21:20 GMT, Patrice Dumas wrote:
> On Wed, Nov 07, 2007 at 04:23:05PM +0100, Mark wrote:
>> Now about the caching itself.
>> Wouldn't it be best to precache all the applications that are gonna be
>> started anyway? like:
>
> You mean on a gnome desktop? Or in fedora? I personnally don't start
> much of those apps, and so would a kde/xfce user.

I am Gnome user, but there are some applications on Mark's list 
which I wouldn't touch with ten feet pole -- pidgin stands out as 
a shining example. Why in the world it should be cached for me?

Mat?j



From marc at mwiriadi.id.au  Wed Nov  7 22:03:15 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Thu, 08 Nov 2007 07:03:15 +0900
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <20071107212000.GA2558@free.fr>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
Message-ID: <1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>


On Wed, 2007-11-07 at 22:20 +0100, Patrice Dumas wrote:
> On Wed, Nov 07, 2007 at 04:23:05PM +0100, Mark wrote:
> > Hey,
> > 
> > Now about the caching itself.
> > Wouldn't it be best to precache all the applications that are gonna be
> > started anyway? like:
> 
> You mean on a gnome desktop? Or in fedora? I personnally don't start
> much of those apps, and so would a kde/xfce user.
> 
> --
> Pat
> 
One of the speeding up while not on boot but in operation can be preload
which I have uploaded to bugzilla already and needs a sponsor. 
https://bugzilla.redhat.com/show_bug.cgi?id=333491


http://sourceforge.net/projects/preload

I'll quote from their page.

"preload is an adaptive readahead daemon. It monitors applications that
users run, and by analyzing this data, predicts what applications users
might run, and fetches those binaries and their dependencies into memory
for faster startup times."

Cheers,

Marc



From tjanouse at redhat.com  Wed Nov  7 22:19:35 2007
From: tjanouse at redhat.com (Tomas Janousek)
Date: Wed, 7 Nov 2007 23:19:35 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <473226CE.60201@gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<200711071938.48209.opensource@till.name>
	<20071107195201.GA4263@serv.smile.org.ua>
	<20071107202611.GA31380@redhat.com> <473226CE.60201@gmail.com>
Message-ID: <20071107221935.GA4371@redhat.com>

On Wed, Nov 07, 2007 at 02:57:50PM -0600, Les Mikesell wrote:
> If you run cvsweb (now viewvc) on the cvs repository it is easy to 
> cherry-pick any file/revision you want or diff between any committed 
> versions through the browser interface.

A whole patchset, a whole patch set ...

-- 
TJ. (Brno, CZ), BaseOS, Red Hat



From dwalsh at redhat.com  Wed Nov  7 22:27:39 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 07 Nov 2007 17:27:39 -0500
Subject: Updating selinux-policy-targeted Causes SELinux Denials
In-Reply-To: <473093FF.9040703@city-fan.org>
References: <1194023411.10665.6.camel@localhost6.localdomain6>	<47308551.5060200@redhat.com>
	<473093FF.9040703@city-fan.org>
Message-ID: <47323BDB.5020509@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Howarth wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Richi Plana wrote:
>>> Hi,
>>>
>>> Should I be concerned that every time an update to
>>> selinux-policy-targeted occurs, it causes actions that the current
>>> running SELinux seems to prevent? I'm talking about SELinux
>>> preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
>>> (restorecon_t) "write"ing to a pipe with label "rpm_t".
>>>
>>> Are these actions legal? And does SELinux preventing them cause an error
>>> in the actual install? Or should these just be treated as warnings?
>>>
>>> I'm guessing that the selinux applications are just trying to
>>> communicate back to the RPM process. I'm wondering if there's anything
>>> important in that communication that should be allowed, or if not, there
>>> must be some way to clean this up.
>>>
>>> (If this isn't the right place to ask, could someone redirect me to the
>>> correct one?)
>>> -- 
>>>
>>> Richi Plana
>>>
>> No,  I am hoping to eliminate a lot of these in the future.  What these
>> avc's are referring to is the redirection of stdout/stderr.  When rpm is
>> running an update it redirects the terminal output to its fifo_files. So
>> any confined domain that runs as part of a post install script will
>> check whether it has access to stdin, stdout, stderr on the terminal or
>> whatever is acting as the terminal.  Since these confined domains do not
>> have policy allowing them to talk to pipes owned by rpm, the kernel
>> generates avc messages and closes the file descriptors and replaces them
>> with open file descriptors to /dev/null.  The apps will continue running
>> and complete successfully, but ugly avc messages are generated.  In
>> Updates to policy I am going to globally start dontauditing these access.
>>
>>
>> # Allow all domains to use fds past to them
>> allow domain domain:fd use;
>> optional_policy(`
>>     rpm_dontaudit_rw_pipes(domain)
>> ')
>>
>> Should be in Fedora 8 and beyond as well as in the next update to
>> Fedora 7.
>>
>> Redirection of Stdout/Stderr account for the largest percentage of
>> SELinux AVC's and most are just noice.
> 
> The net effect of this is to throw away any scriptlet output (e.g. error
> messages), isn't it? Whilst people running a GUI update tool won't see
> these anyway, us luddites that still use yum from the command line so as
> to see if there are any problems during an update won't be able to see
> this output.
> 
> Yes, I know that this doesn't represent a change from current policy; I
> usually add local policy to allow this output when I see the avcs, but
> if they're dontaudited then I won't see any hint of there being a problem.
> 
> Paul.
> 
Your right, I will change it to rpm_rw_pipes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHMjvbrlYvE4MpobMRAiNOAJ94NZPDegUO18Q2lSQZO7G25X+uygCfaxzm
qTuEIkXteGRrmBX8lqGcm+E=
=FZLG
-----END PGP SIGNATURE-----



From markg85 at gmail.com  Wed Nov  7 22:30:12 2007
From: markg85 at gmail.com (Mark)
Date: Wed, 7 Nov 2007 23:30:12 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>
Message-ID: <6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>

> One of the speeding up while not on boot but in operation can be preload
> which I have uploaded to bugzilla already and needs a sponsor.
> https://bugzilla.redhat.com/show_bug.cgi?id=333491
>
>
> http://sourceforge.net/projects/preload
>
> I'll quote from their page.
>
> "preload is an adaptive readahead daemon. It monitors applications that
> users run, and by analyzing this data, predicts what applications users
> might run, and fetches those binaries and their dependencies into memory
> for faster startup times."
>
> Cheers,
>
> Marc

Hi,

is that "preload" also caching the files that it puts in its list?
if that's the case than this program would be a wonderful program to
have in fedora.

Assuming the program is doing the following: you just work on your
computer and that daemon is registering all files that you access. the
most used files(?) are getting cached at next boot right?

@the other replies
i agree that it shouldn't just cache some pre set programs.. some
users might not use them and that will bee a pure waste of memory..
but it was just a idea to get this caching of the ground in Fedora.
The best thing would be the assumption that i've written above (or
that's what i think would work best). In my case Pidgin would be (or i
would add it) in the list because i use it quite often.

More brainstorming on this would be cool.
And what are the current caching systems? wasn't there a Google SOC
(Summer Of Code) about the caching this year.. and how did that one
ended up?



From marc at mwiriadi.id.au  Wed Nov  7 22:37:14 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Thu, 08 Nov 2007 07:37:14 +0900
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>
	<6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>
Message-ID: <1194475034.3498.14.camel@strikeforce.mwiriadi.id.au>


On Wed, 2007-11-07 at 23:30 +0100, Mark wrote:
> > One of the speeding up while not on boot but in operation can be preload
> > which I have uploaded to bugzilla already and needs a sponsor.
> > https://bugzilla.redhat.com/show_bug.cgi?id=333491
> >
> >
> > http://sourceforge.net/projects/preload
> >
> > I'll quote from their page.
> >
> > "preload is an adaptive readahead daemon. It monitors applications that
> > users run, and by analyzing this data, predicts what applications users
> > might run, and fetches those binaries and their dependencies into memory
> > for faster startup times."
> >
> > Cheers,
> >
> > Marc
> 
> Hi,
> 
> is that "preload" also caching the files that it puts in its list?
> if that's the case than this program would be a wonderful program to
> have in fedora.
> 
> Assuming the program is doing the following: you just work on your
> computer and that daemon is registering all files that you access. the
> most used files(?) are getting cached at next boot right?
> 

Yes thats how it works. It is all automated with the config files
under /etc  The biggest benefit is that it updates itself.  

It saves the list every 3600 seconds. Download the SRPM and give it a go
to get a better idea.

Cheers,

Marc



From markg85 at gmail.com  Wed Nov  7 22:40:07 2007
From: markg85 at gmail.com (Mark)
Date: Wed, 7 Nov 2007 23:40:07 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <1194475034.3498.14.camel@strikeforce.mwiriadi.id.au>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>
	<6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>
	<1194475034.3498.14.camel@strikeforce.mwiriadi.id.au>
Message-ID: <6e24a8e80711071440q7bf128cka057d06d0fcaca8c@mail.gmail.com>

> > Assuming the program is doing the following: you just work on your
> > computer and that daemon is registering all files that you access. the
> > most used files(?) are getting cached at next boot right?
> >
>
> Yes thats how it works. It is all automated with the config files
> under /etc  The biggest benefit is that it updates itself.
>
> It saves the list every 3600 seconds. Download the SRPM and give it a go
> to get a better idea.
>
> Cheers,
>
> Marc

I will... as soon as Fedora 8 is out. it definitely sounds like a
smart caching system.



From markg85 at gmail.com  Wed Nov  7 22:41:46 2007
From: markg85 at gmail.com (Mark)
Date: Wed, 7 Nov 2007 23:41:46 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>
	<6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>
Message-ID: <6e24a8e80711071441x63f2c0c8y2e91c491609a0f0b@mail.gmail.com>

I just found this one: http://kerneltrap.org/node/6642
seems like the kernel already has caching build in.. it just needs to
be expanded with that patch set?..



From ville.skytta at iki.fi  Wed Nov  7 22:52:58 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 8 Nov 2007 00:52:58 +0200
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107221935.GA4371@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<473226CE.60201@gmail.com> <20071107221935.GA4371@redhat.com>
Message-ID: <200711080052.59383.ville.skytta@iki.fi>

On Thursday 08 November 2007, Tomas Janousek wrote:
> On Wed, Nov 07, 2007 at 02:57:50PM -0600, Les Mikesell wrote:
> > If you run cvsweb (now viewvc) on the cvs repository it is easy to
> > cherry-pick any file/revision you want or diff between any committed
> > versions through the browser interface.
>
> A whole patchset, a whole patch set ...

yum install cvsps ; man cvsps



From lesmikesell at gmail.com  Wed Nov  7 23:08:54 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 07 Nov 2007 17:08:54 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107221935.GA4371@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<200711071938.48209.opensource@till.name>	<20071107195201.GA4263@serv.smile.org.ua>	<20071107202611.GA31380@redhat.com>
	<473226CE.60201@gmail.com> <20071107221935.GA4371@redhat.com>
Message-ID: <47324586.9090203@gmail.com>

Tomas Janousek wrote:
> On Wed, Nov 07, 2007 at 02:57:50PM -0600, Les Mikesell wrote:
>> If you run cvsweb (now viewvc) on the cvs repository it is easy to 
>> cherry-pick any file/revision you want or diff between any committed 
>> versions through the browser interface.
> 
> A whole patchset, a whole patch set ...

If you have the tar download option enabled you can grab any trees you 
want and do your own diffs.  Unless you do it really often it should be 
easier to get them as needed instead of keeping a whole repository 
updated just in case.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From green at redhat.com  Thu Nov  8 00:55:29 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 07 Nov 2007 16:55:29 -0800
Subject: common-lisp-controller for Fedora
Message-ID: <47325E81.4010706@redhat.com>

I've created a draft Feature page on the wiki to copy Debian's 
common-lisp-controller package and methodology for installing Common 
Lisp implementations and libraries.

http://fedoraproject.org/wiki/Features/CommonLispController

This will require changes to all common lisp implementations in Fedora, 
so I'm looking for support from those packagers (some of whom are on copy).

Also, this is not something I can do on my own.  I'm hoping there are 
like-minded people out there that are interesting in making Fedora a 
great platform for deploying Lisp based infrastructure.  So, are there 
any willing to help over the next 6 months?

Thanks!

AG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/d08b82d8/attachment.vcf>

From kevin.kofler at chello.at  Thu Nov  8 01:12:38 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 8 Nov 2007 01:12:38 +0000 (UTC)
Subject: common-lisp-controller for Fedora
References: <47325E81.4010706@redhat.com>
Message-ID: <loom.20071108T010912-860@post.gmane.org>

Anthony Green <green <at> redhat.com> writes:
> I've created a draft Feature page on the wiki to copy Debian's 
> common-lisp-controller package and methodology for installing Common 
> Lisp implementations and libraries.

How does this fit together with natively-compiled implementations like gcl? 
Does this imply radically changing them to work more like an interpreter and 
load natively-compiled versions as shared libraries like what was done to GCJ? 
If it does, who is going to do the work? And is this really a good idea? For 
what it's worth, Maxima seems to cope just fine with the current 
implementation.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Nov  8 01:20:00 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 8 Nov 2007 01:20:00 +0000 (UTC)
Subject: No pushes to updates-testing for F-7?
References: <3170f42f0711062252p5e7246a0n6917c6d913946347@mail.gmail.com>
Message-ID: <loom.20071108T011831-74@post.gmane.org>

Debarshi 'Rishi' Ray <debarshi.ray <at> gmail.com> writes:
> It seems no one has been signing and pushing packages to
> updates-testing for F-7 for the last 12 days or so.

It's because the following bug is breaking the composes of the F7 
updates-testing repo:
https://bugzilla.redhat.com/show_bug.cgi?id=360291
Looks like a fix is available now, hopefully to land in production ASAP.

        Kevin Kofler



From michael.wiktowy at gmail.com  Thu Nov  8 02:12:53 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Wed, 7 Nov 2007 21:12:53 -0500
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
Message-ID: <3e4ec4600711071812g5a30dcfeu390b77d356ac18b5@mail.gmail.com>

On 11/7/07, Monkey Boy <monkeyboythom at gmail.com> wrote:
> <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> you.</Dr.Rumack>
>

Obligatory Spaceballs chaser:
"But when will then be now?"
"Soon."



From rdieter at math.unl.edu  Thu Nov  8 03:09:42 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 07 Nov 2007 21:09:42 -0600
Subject: ggz reviews
Message-ID: <fgtulm$l9f$1@ger.gmane.org>

As threaten awhile back, I worked on packaging up ggz-related stuff,
http://www.ggzgamingzone.org/
(needed for kdegames4, at least), initial reviews are in (thumbs up!):

libggz: http://bugzilla.redhat.com/370741
ggz-client-libs: http://bugzilla.redhat.com/370751

-- Rex



From smooge at gmail.com  Thu Nov  8 04:03:11 2007
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 7 Nov 2007 21:03:11 -0700
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
Message-ID: <80d7e4090711072003y20962bc9ye5ba2d89b0719817@mail.gmail.com>

On Nov 7, 2007 7:25 AM, Monkey Boy <monkeyboythom at gmail.com> wrote:
> <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> you.</Dr.Rumack>
>
> --


Looks like I picked the wrong week to quit sniffing glue.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From pemboa at gmail.com  Thu Nov  8 04:18:25 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 7 Nov 2007 22:18:25 -0600
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <80d7e4090711072003y20962bc9ye5ba2d89b0719817@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
	<80d7e4090711072003y20962bc9ye5ba2d89b0719817@mail.gmail.com>
Message-ID: <16de708d0711072018k24ff47eej5609c34995175516@mail.gmail.com>

On Nov 7, 2007 10:03 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> On Nov 7, 2007 7:25 AM, Monkey Boy <monkeyboythom at gmail.com> wrote:
> > <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> > you.</Dr.Rumack>
> >
> > --
>
>
> Looks like I picked the wrong week to quit sniffing glue.


You can have my stash.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From green at redhat.com  Thu Nov  8 06:52:33 2007
From: green at redhat.com (Anthony Green)
Date: Wed, 07 Nov 2007 22:52:33 -0800
Subject: common-lisp-controller for Fedora
In-Reply-To: <loom.20071108T010912-860@post.gmane.org>
References: <47325E81.4010706@redhat.com>
	<loom.20071108T010912-860@post.gmane.org>
Message-ID: <4732B231.2020606@redhat.com>

Kevin Kofler wrote:
> Anthony Green <green <at> redhat.com> writes:
>> I've created a draft Feature page on the wiki to copy Debian's 
>> common-lisp-controller package and methodology for installing Common 
>> Lisp implementations and libraries.
> 
> How does this fit together with natively-compiled implementations like gcl? 

It is perfectly compatible.

> Does this imply radically changing them to work more like an interpreter and 
> load natively-compiled versions as shared libraries like what was done to GCJ? 

No.

> If it does, who is going to do the work? And is this really a good idea? For 
> what it's worth, Maxima seems to cope just fine with the current 
> implementation.

Sure, Maxima doesn't depend on pre-installed libraries of lisp code.

What's at issue is:

  - Where to the library sources get installed?
  - Where do the implementation dependent fasl and/or other binary files 
get installed?
  - How do we manage fasl updates when a lisp implementation changes?
  - How do they all hook into asdf or similar
  - How do we scale to include the hundreds of Common Lisp libraries 
that gentoo and others package?
  - etc etc etc

AG

> 
>         Kevin Kofler
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071107/b571dac2/attachment.vcf>

From laroche at redhat.com  Thu Nov  8 09:39:51 2007
From: laroche at redhat.com (Florian La Roche)
Date: Thu, 8 Nov 2007 10:39:51 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
Message-ID: <20071108093951.GA3744@dudweiler.stuttgart.redhat.com>

On Wed, Nov 07, 2007 at 03:12:45PM +0100, Adam Tkac wrote:
> Hi all,
> 
> CVS has already passed over best years. I'm wonder why modern
> project like Fedora still has sources in this ancient system. Are here
> any plans to replace it by git, mercurial, svn or other more modern
> version control system?

Hello Adam,

AFAIK koji has gooten support for different backends, so now testing
out the git backend would be very good.

This is also important for our Secondary Arch plans that should be
finalized at some point.

regards,

Florian La Roche



From tsmetana at redhat.com  Thu Nov  8 09:49:43 2007
From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana)
Date: Thu, 8 Nov 2007 10:49:43 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
Message-ID: <20071108104943.318fcb5e@dhcp-lab-165.englab.brq.redhat.com>

On Wed, 7 Nov 2007 16:23:05 +0100
Mark <markg85 at gmail.com> wrote:

> Hey,
> 
> Fedora 8 has dropped the readahead program which was fine because it
> wasn't speeding up anything at all (not in my experience) but i do
> think we need some kind of a caching for the start menu and serveral
> other programs.

I think Jeff Garzik has mentioned Jens Axboe's fcache in this list
before, but it received little attention.  Wouldn't it be worth trying?
Or did someone try that with Fedora?  It sounds like a generic enough
solution to "a faster startup" problem.

Relevant link is:
http://lkml.org/lkml/2006/5/15/46

Regards.

-- 
Tom?? Smetana




From atkac at redhat.com  Thu Nov  8 10:08:19 2007
From: atkac at redhat.com (Adam Tkac)
Date: Thu, 8 Nov 2007 11:08:19 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107114158.6cf5f250@weaponx>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
Message-ID: <20071108100819.GA12141@evileye.englab.brq.redhat.com>

On Wed, Nov 07, 2007 at 11:41:58AM -0600, Josh Boyer wrote:
> On Wed, 7 Nov 2007 15:12:45 +0100
> Adam Tkac <atkac at redhat.com> wrote:
> 
> > Hi all,
> > 
> > CVS has already passed over best years. I'm wonder why modern
> > project like Fedora still has sources in this ancient system. Are here
> > any plans to replace it by git, mercurial, svn or other more modern
> > version control system?
> 
> Replacing a VCS for the fun of it is pretty pointless.  Can you
> elaborate on a workflow you would like to see that CVS is not suited
> to?  Right now, CVS works fine for what we do, which is mostly editing
> spec files.
> 
> I am by no means a proponent of CVS.  I think it sucks.  But we have no
> _usecase_ for a different VCS at the moment.
> 
> josh

It's not replacement for fun. Yes, CVS works and I believe it will
work to end of universe. But question is if We have something better
than CVS. And We have. There're some common problems (yes, CVS and
SVN suffer :) )

- you have to keep huge changes on your machine when you're doing
  bigger patch. And it is really confusing sometimes
- you can't easily move source tree under development. When I want to
  do development on more machines I have to do ssh, diff, scp, patch. It's
  pretty annoying
- when you're doing on some feature you can't do on it simulateously
  with maintenance & bugfixing. You have to diff, save diff, fix bug,
  commit, dig your uncomplete "feature" patch, patch source and
  continue on development
- CVS server outage :)

all this common problems are solvable with CVS. But I know really better
workflows which cannot be used with CVS. Also I don't believe that
it's hard to switch from one VCS to other if We have arguments. Yes,
it will need some work like all improvements.

Adam

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From atkac at redhat.com  Thu Nov  8 10:20:29 2007
From: atkac at redhat.com (Adam Tkac)
Date: Thu, 8 Nov 2007 11:20:29 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108093951.GA3744@dudweiler.stuttgart.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071108093951.GA3744@dudweiler.stuttgart.redhat.com>
Message-ID: <20071108102029.GA12788@evileye.englab.brq.redhat.com>

On Thu, Nov 08, 2007 at 10:39:51AM +0100, Florian La Roche wrote:
> On Wed, Nov 07, 2007 at 03:12:45PM +0100, Adam Tkac wrote:
> > Hi all,
> > 
> > CVS has already passed over best years. I'm wonder why modern
> > project like Fedora still has sources in this ancient system. Are here
> > any plans to replace it by git, mercurial, svn or other more modern
> > version control system?
> 
> Hello Adam,
> 
> AFAIK koji has gooten support for different backends, so now testing
> out the git backend would be very good.

Perfect news! Use git as primary VCS would be great. If you need some
help with this project let me know.

Adam

> 
> This is also important for our Secondary Arch plans that should be
> finalized at some point.
> 
> regards,
> 
> Florian La Roche
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From xiyou.wangcong at yahoo.com.cn  Thu Nov  8 10:26:14 2007
From: xiyou.wangcong at yahoo.com.cn (WANG Cong)
Date: Thu, 8 Nov 2007 18:26:14 +0800
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <6e24a8e80711071441x63f2c0c8y2e91c491609a0f0b@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<1194472995.3498.6.camel@strikeforce.mwiriadi.id.au>
	<6e24a8e80711071430o180ab793n6defb09fa57319f8@mail.gmail.com>
	<6e24a8e80711071441x63f2c0c8y2e91c491609a0f0b@mail.gmail.com>
Message-ID: <20071108182614.33276bcd@hacking>

On Wed, 7 Nov 2007 23:41:46 +0100
Mark <markg85 at gmail.com> wrote:

> I just found this one: http://kerneltrap.org/node/6642
> seems like the kernel already has caching build in.. it just needs to
> be expanded with that patch set?..
> 

That's old.

That patch set was already merged into kernel source. Kernel's readahead, of course, stands in kernel space. While preload[1] is in userspace.

[1] http://sourceforge.net/projects/preload
__________________________________________________
?????????????????????????????
http://cn.mail.yahoo.com



From mschmidt at redhat.com  Thu Nov  8 11:01:20 2007
From: mschmidt at redhat.com (Michal Schmidt)
Date: Thu, 8 Nov 2007 12:01:20 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <20071108104943.318fcb5e@dhcp-lab-165.englab.brq.redhat.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071108104943.318fcb5e@dhcp-lab-165.englab.brq.redhat.com>
Message-ID: <20071108120120.69ff29a9@brian.englab.brq.redhat.com>

On Thu, 8 Nov 2007 10:49:43 +0100
Tom?? Smetana <tsmetana at redhat.com> wrote:

> I think Jeff Garzik has mentioned Jens Axboe's fcache in this list
> before, but it received little attention.  Wouldn't it be worth
> trying? Or did someone try that with Fedora?  It sounds like a
> generic enough solution to "a faster startup" problem.
> 
> Relevant link is:
> http://lkml.org/lkml/2006/5/15/46

I helped Jens with testing fcache. I used Debian at the time, but it
should work on any distro. The improvement in boot-up speed was nice.

The problem is fcache is not upstream and it won't be. Jens saw fcache
only as a proof-of-concept hack. He abandoned its development. He had
an idea for a better and easier to use solution. It was supposed to be
more automatic with no special "priming" mode. I don't think he ever
got to implement it though.

Michal



From buildsys at redhat.com  Thu Nov  8 11:42:50 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 8 Nov 2007 06:42:50 -0500
Subject: rawhide report: 20071108 changes
Message-ID: <200711081142.lA8Bgo1H014336@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8











From ndbecker2 at gmail.com  Thu Nov  8 11:50:17 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 08 Nov 2007 06:50:17 -0500
Subject: openid support for f9?
Message-ID: <fgut5p$2b1$1@ger.gmane.org>

It seems that openid is moving along.  Maybe f9 can integrate openid as an
SSO solution?

http://lwn.net/Articles/255774/



From ndbecker2 at gmail.com  Thu Nov  8 11:52:37 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 08 Nov 2007 06:52:37 -0500
Subject: hg built OK on EL4, now what?
Message-ID: <fguta6$3bk$1@ger.gmane.org>

36917 (mercurial): Build on target fedora-4-epel succeeded.
     Build logs may be found at
http://buildsys.fedoraproject.org/logs/fedora-4-epel/36917-mercurial-0.9.5-2.el4/

1) What is the next step?

2) Where are the rpms built (I'd like to grab a copy to test)?



From mschwendt.tmp0701.nospam at arcor.de  Thu Nov  8 12:02:10 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Thu, 8 Nov 2007 13:02:10 +0100
Subject: hg built OK on EL4, now what?
In-Reply-To: <fguta6$3bk$1@ger.gmane.org>
References: <fguta6$3bk$1@ger.gmane.org>
Message-ID: <20071108130210.482c55f0.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 08 Nov 2007 06:52:37 -0500, Neal Becker wrote:

> 36917 (mercurial): Build on target fedora-4-epel succeeded.
>      Build logs may be found at
> http://buildsys.fedoraproject.org/logs/fedora-4-epel/36917-mercurial-0.9.5-2.el4/
> 
> 1) What is the next step?

With plague? None. The packages are pushed into the testing
repos by the EPEL signers.

> 2) Where are the rpms built (I'd like to grab a copy to test)?
 
http://buildsys.fedoraproject.org/plague-results/



From jkeating at redhat.com  Thu Nov  8 12:06:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 8 Nov 2007 07:06:26 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108100819.GA12141@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
Message-ID: <20071108070626.7764f8e9@redhat.com>

On Thu, 8 Nov 2007 11:08:19 +0100
Adam Tkac <atkac at redhat.com> wrote:

> But I know really better
> workflows which cannot be used with CVS.

Can you outline what kind of better workflow you'd like to see?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/a676fd63/attachment.sig>

From fedora at leemhuis.info  Thu Nov  8 12:10:57 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 08 Nov 2007 13:10:57 +0100
Subject: hg built OK on EL4, now what?
In-Reply-To: <fguta6$3bk$1@ger.gmane.org>
References: <fguta6$3bk$1@ger.gmane.org>
Message-ID: <4732FCD1.2080704@leemhuis.info>

On 08.11.2007 12:52, Neal Becker wrote:
> 36917 (mercurial): Build on target fedora-4-epel succeeded.
>      Build logs may be found at
> http://buildsys.fedoraproject.org/logs/fedora-4-epel/36917-mercurial-0.9.5-2.el4/
> 1) What is the next step?

Wait -- they will get into epel-testing with the next push which are
done two or three times a week. Some weeks later it will should make it
into EPEL proper. If you want to prevent the later or need a urgent
push/a testing -> proper move contact
epel_signers-members [AT] fedoraproject.org

> 2) Where are the rpms built (I'd like to grab a copy to test)?

http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/

HTH

CU
knurd



From atkac at redhat.com  Thu Nov  8 12:16:09 2007
From: atkac at redhat.com (Adam Tkac)
Date: Thu, 8 Nov 2007 13:16:09 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108070626.7764f8e9@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
Message-ID: <20071108121609.GA14018@evileye.englab.brq.redhat.com>

On Thu, Nov 08, 2007 at 07:06:26AM -0500, Jesse Keating wrote:
> On Thu, 8 Nov 2007 11:08:19 +0100
> Adam Tkac <atkac at redhat.com> wrote:
> 
> > But I know really better
> > workflows which cannot be used with CVS.
> 
> Can you outline what kind of better workflow you'd like to see?

I wrote it in previous mail. I like distributed VCS workflow - local
repository, local braches, local commits etc.

Adam

> 
> -- 
> Jesse Keating
> Fedora -- All my bits are free, are yours?



> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From abartlet at samba.org  Thu Nov  8 12:26:31 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Thu, 08 Nov 2007 23:26:31 +1100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108121609.GA14018@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
	<20071108121609.GA14018@evileye.englab.brq.redhat.com>
Message-ID: <1194524791.13184.82.camel@naomi>


On Thu, 2007-11-08 at 13:16 +0100, Adam Tkac wrote:
> On Thu, Nov 08, 2007 at 07:06:26AM -0500, Jesse Keating wrote:
> > On Thu, 8 Nov 2007 11:08:19 +0100
> > Adam Tkac <atkac at redhat.com> wrote:
> > 
> > > But I know really better
> > > workflows which cannot be used with CVS.
> > 
> > Can you outline what kind of better workflow you'd like to see?
> 
> I wrote it in previous mail. I like distributed VCS workflow - local
> repository, local braches, local commits etc.

Is that useful with the centralised tasks that distribution building
requires, such as koji?

On the Samba team we are presented with a very similar issue -
distributed VCS systems are very attractive, but we also do a lot of our
QA with a central build farm, which realistically only works for the
centralised modal.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/5cfaa580/attachment.sig>

From dr.diesel at gmail.com  Thu Nov  8 12:27:54 2007
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 8 Nov 2007 06:27:54 -0600
Subject: Special Thanks
Message-ID: <2a28d2ab0711080427h3c975d29mc1ffda9f2f7ec43d@mail.gmail.com>

To all of you that go above and beyond.  I read countless emails
supporting and helping the development cycle at all hours.  The team
from RedHat that is constantly helping, including weekend nights, you
guys know who you are!  A special thanks to all of you.

F8 is better than ever, something to be proud of, I can't wait too see
what F9 brings!

Andy

--



From jima at beer.tclug.org  Thu Nov  8 12:31:03 2007
From: jima at beer.tclug.org (Jima)
Date: Thu, 8 Nov 2007 06:31:03 -0600 (CST)
Subject: Special Thanks
In-Reply-To: <2a28d2ab0711080427h3c975d29mc1ffda9f2f7ec43d@mail.gmail.com>
References: <2a28d2ab0711080427h3c975d29mc1ffda9f2f7ec43d@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0711080630180.4486@beer.tclug.org>

On Thu, 8 Nov 2007, Dr. Diesel wrote:
> F8 is better than ever, something to be proud of, I can't wait too see
> what F9 brings!

  We don't even get a break?  Aww, man!
  Back to the grindstone. :-(

      Jima

  ;-)



From ngompa13 at gmail.com  Thu Nov  8 12:36:35 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 8 Nov 2007 06:36:35 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194524791.13184.82.camel@naomi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
	<20071108121609.GA14018@evileye.englab.brq.redhat.com>
	<1194524791.13184.82.camel@naomi>
Message-ID: <8278b1b0711080436w43576f72s54c963c8675c54e@mail.gmail.com>

Well, Bazaar and Mercurial can both support semi-centralized repository
systems. In the Enano CMS Project, we created a public mirror of all the
repositories that are worked on in Nighthawk, which is the build and
development server of all the work in Mercurial revisions of Enano CMS.
While realistically Fedora cannot have such a system, the principle of
designating certain branches of repositories for central authorization so
that stuff like QA can manage it is possible with a single repository
setting. Heck, I think even Ubuntu does that with Bazaar. Though as far as
distributed VCSes go, I prefer Mercurial. Since Fedora is a Linux OS, I
suppose it is fine to use GIT, but I try to avoid non-cross platform VCSes.

On Nov 8, 2007 6:26 AM, Andrew Bartlett <abartlet at samba.org> wrote:

>
> On Thu, 2007-11-08 at 13:16 +0100, Adam Tkac wrote:
> > On Thu, Nov 08, 2007 at 07:06:26AM -0500, Jesse Keating wrote:
> > > On Thu, 8 Nov 2007 11:08:19 +0100
> > > Adam Tkac <atkac at redhat.com> wrote:
> > >
> > > > But I know really better
> > > > workflows which cannot be used with CVS.
> > >
> > > Can you outline what kind of better workflow you'd like to see?
> >
> > I wrote it in previous mail. I like distributed VCS workflow - local
> > repository, local braches, local commits etc.
>
> Is that useful with the centralised tasks that distribution building
> requires, such as koji?
>
> On the Samba team we are presented with a very similar issue -
> distributed VCS systems are very attractive, but we also do a lot of our
> QA with a central build farm, which realistically only works for the
> centralised modal.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/ <http://samba.org/%7Eabartlet/>
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Red Hat Inc.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/8b37c886/attachment.htm>

From jkeating at redhat.com  Thu Nov  8 12:59:48 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 8 Nov 2007 07:59:48 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108121609.GA14018@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
	<20071108121609.GA14018@evileye.englab.brq.redhat.com>
Message-ID: <20071108075948.7b24b3f0@redhat.com>

On Thu, 8 Nov 2007 13:16:09 +0100
Adam Tkac <atkac at redhat.com> wrote:

> I wrote it in previous mail. I like distributed VCS workflow - local
> repository, local braches, local commits etc.

That doesn't outline an improved workflow.  In fact, it outlines
adding /more/ steps for maintainers to get their changes into a place
that actually matters.  The vast majority of packages are simply just a
spec file and the source tar.  The interaction with the SCM is minimal
at best, update a spec (or import an srpm), make tag build, move on
with life.  If you're adding (confusing) steps like "oh, I commited,
but I actually have to /push/ that commit somewhere for the buildsystem
to notice" I don't see where this adds value for the majority of
maintainers.

Don't get me wrong, I absolutely love distributed source control, but I
don't necessarily think it applies itself well to a centralized package
scm.

This is why I ask for envisioned workflows, something that is appealing
to both people with lots of patches to manage (which really, we scream
upstream upstream upstream, you shouldn't have a pile of patches except
for specific cases), and to the far more common spec file + sources
reference to tarball people.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/7f88edd0/attachment.sig>

From marc at mwiriadi.id.au  Thu Nov  8 13:06:31 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Thu, 08 Nov 2007 22:06:31 +0900
Subject: Special Thanks
In-Reply-To: <Pine.LNX.4.64.0711080630180.4486@beer.tclug.org>
References: <2a28d2ab0711080427h3c975d29mc1ffda9f2f7ec43d@mail.gmail.com>
	<Pine.LNX.4.64.0711080630180.4486@beer.tclug.org>
Message-ID: <1194527191.27158.10.camel@strikeforce.mwiriadi.id.au>


On Thu, 2007-11-08 at 06:31 -0600, Jima wrote:
> On Thu, 8 Nov 2007, Dr. Diesel wrote:
> > F8 is better than ever, something to be proud of, I can't wait too see
> > what F9 brings!
> 
>   We don't even get a break?  Aww, man!
>   Back to the grindstone. :-(
> 
>       Jima
> 
>   ;-)
> 

I agree great job all.  The most stable release I have ever tried :)

Cheers,

Marc



From alexl at redhat.com  Thu Nov  8 13:46:20 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Thu, 08 Nov 2007 14:46:20 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <20071108120120.69ff29a9@brian.englab.brq.redhat.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071108104943.318fcb5e@dhcp-lab-165.englab.brq.redhat.com>
	<20071108120120.69ff29a9@brian.englab.brq.redhat.com>
Message-ID: <1194529580.20968.55.camel@dhcp-208-188.arn.redhat.com>


On Thu, 2007-11-08 at 12:01 +0100, Michal Schmidt wrote:
> > 
> > Relevant link is:
> > http://lkml.org/lkml/2006/5/15/46
> 
> I helped Jens with testing fcache. I used Debian at the time, but it
> should work on any distro. The improvement in boot-up speed was nice.
> 
> The problem is fcache is not upstream and it won't be. Jens saw fcache
> only as a proof-of-concept hack. He abandoned its development. He had
> an idea for a better and easier to use solution. It was supposed to be
> more automatic with no special "priming" mode. I don't think he ever
> got to implement it though.

So very sad. Yet again "perfect" is the enemy of "good"....



From valent.turkovic at gmail.com  Thu Nov  8 13:50:02 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 8 Nov 2007 14:50:02 +0100
Subject: fedora 8 torrents
Message-ID: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>

I have already seeded 5GB of Fedora 8 DVD, my download is only 20% complete.
My upload is limited at 8Mbits/s but only 2-3 are currently used...
come on people, what are you waiting for :)

ps. when will be fedora 8 gnome live cd available? And the home page
is still showing 1 day till fedora 8, isn't today the date?

ps.  I'm in Europe and here is 3PM allready. I hoped that by 10AM
fedora will be officially out - but I guess that was the case with
openSUSE so I mixed the time zones...

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From harald at redhat.com  Thu Nov  8 13:52:51 2007
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 08 Nov 2007 14:52:51 +0100
Subject: smolt server problem?
In-Reply-To: <loom.20071107T145835-699@post.gmane.org>
References: <loom.20071107T145835-699@post.gmane.org>
Message-ID: <fgv4bj$ots$1@ger.gmane.org>

Mike C wrote:
> Does anyone know if there is a current server problem for smolt?
> 
> I posted some experiences in Fedora list, finally resulting in
> 
> "I wonder if this is related to the issue I am seeing:
> On trying to simply view my profile I get in the browser:
> 
> Proxy Error
> 
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request GET /show.
> 
> Reason: Error reading from remote server
> 
> This comes from the server listed at the bottom of the web page
> Apache/2.2.3 (Red Hat) Server at smolt.fedoraproject.org Port 80
> 
> So it seems that the problems appear to be within the smolt server."
> 
> I have copied this from:
> http://marc.info/?l=fedora-list&m=119443732001288&w=2
> and see related thread.
> 

Something in Smolt is producing some sort of memory leak or python2.4's garbage collector is bad.
Yesterday I made some massive improvements for the SQL queries, which hopefully will go live soon (today?). :-)

Stay tuned.



From lesmikesell at gmail.com  Thu Nov  8 13:54:06 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 08 Nov 2007 07:54:06 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <8278b1b0711080436w43576f72s54c963c8675c54e@mail.gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<20071108100819.GA12141@evileye.englab.brq.redhat.com>	<20071108070626.7764f8e9@redhat.com>	<20071108121609.GA14018@evileye.englab.brq.redhat.com>	<1194524791.13184.82.camel@naomi>
	<8278b1b0711080436w43576f72s54c963c8675c54e@mail.gmail.com>
Message-ID: <473314FE.5060008@gmail.com>

King InuYasha wrote:
> Well, Bazaar and Mercurial can both support semi-centralized repository
> systems. In the Enano CMS Project, we created a public mirror of all the
> repositories that are worked on in Nighthawk, which is the build and
> development server of all the work in Mercurial revisions of Enano CMS.
> While realistically Fedora cannot have such a system, the principle of
> designating certain branches of repositories for central authorization so
> that stuff like QA can manage it is possible with a single repository
> setting. Heck, I think even Ubuntu does that with Bazaar. Though as far as
> distributed VCSes go, I prefer Mercurial. Since Fedora is a Linux OS, I
> suppose it is fine to use GIT, but I try to avoid non-cross platform VCSes.

Svk has an interesting magic ability to work with a mirrored subversion 
project.  That lets you treat the subversion repository as centralized 
but people who prefer to work with a local copy can run svk, tell it to 
sync with the subversion copy, then make a local branch for their 
changes.  When they merge the branch changes back to the mirrored 
project, svk automagically commits them to the central subversion repo. 
  I haven't done this myself but there are some tutorials floating 
around on the net with the steps for this procedure.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From valent.turkovic at gmail.com  Thu Nov  8 13:55:31 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 8 Nov 2007 14:55:31 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>
Message-ID: <64b14b300711080555n5b62b5a2pacca35e6bc31d816@mail.gmail.com>

On 11/7/07, Matej Cepl <mcepl at redhat.com> wrote:
> On 2007-11-07, 21:20 GMT, Patrice Dumas wrote:
> > On Wed, Nov 07, 2007 at 04:23:05PM +0100, Mark wrote:
> >> Now about the caching itself.
> >> Wouldn't it be best to precache all the applications that are gonna be
> >> started anyway? like:
> >
> > You mean on a gnome desktop? Or in fedora? I personnally don't start
> > much of those apps, and so would a kde/xfce user.
>
> I am Gnome user, but there are some applications on Mark's list
> which I wouldn't touch with ten feet pole -- pidgin stands out as
> a shining example. Why in the world it should be cached for me?
>
> Mat?j

What app do you recommend as an multi-IM client?

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From mschick at redhat.com  Thu Nov  8 14:03:22 2007
From: mschick at redhat.com (Matthew Schick)
Date: Thu, 08 Nov 2007 09:03:22 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <473314FE.5060008@gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
	<20071108121609.GA14018@evileye.englab.brq.redhat.com>
	<1194524791.13184.82.camel@naomi>
	<8278b1b0711080436w43576f72s54c963c8675c54e@mail.gmail.com>
	<473314FE.5060008@gmail.com>
Message-ID: <1194530602.3177.3.camel@buddychrist.rdu.redhat.com>


On Thu, 2007-11-08 at 07:54 -0600, Les Mikesell wrote:
> King InuYasha wrote:
> > Well, Bazaar and Mercurial can both support semi-centralized repository
> > systems. In the Enano CMS Project, we created a public mirror of all the
> > repositories that are worked on in Nighthawk, which is the build and
> > development server of all the work in Mercurial revisions of Enano CMS.
> > While realistically Fedora cannot have such a system, the principle of
> > designating certain branches of repositories for central authorization so
> > that stuff like QA can manage it is possible with a single repository
> > setting. Heck, I think even Ubuntu does that with Bazaar. Though as far as
> > distributed VCSes go, I prefer Mercurial. Since Fedora is a Linux OS, I
> > suppose it is fine to use GIT, but I try to avoid non-cross platform VCSes.
> 
> Svk has an interesting magic ability to work with a mirrored subversion 
> project.  That lets you treat the subversion repository as centralized 
> but people who prefer to work with a local copy can run svk, tell it to 
> sync with the subversion copy, then make a local branch for their 
> changes.  When they merge the branch changes back to the mirrored 
> project, svk automagically commits them to the central subversion repo. 
>   I haven't done this myself but there are some tutorials floating 
> around on the net with the steps for this procedure.

There's also git-svn.  Lets you use the upstream svn server for the
centralized repository but still gives you all the distributed features
of git.
-- 
Matthew Schick
Systems Administrator, Engineering Operations
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/68fa88f4/attachment.sig>

From gilboad at gmail.com  Thu Nov  8 14:06:26 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Thu, 08 Nov 2007 16:06:26 +0200
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <3e4ec4600711071812g5a30dcfeu390b77d356ac18b5@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
	<3e4ec4600711071812g5a30dcfeu390b77d356ac18b5@mail.gmail.com>
Message-ID: <1194530786.757.17.camel@gilboa-work-dev.localdomain>

On Wed, 2007-11-07 at 21:12 -0500, Michael Wiktowy wrote:
> On 11/7/07, Monkey Boy <monkeyboythom at gmail.com> wrote:
> > <Dr.Rumack>I just want to tell you all good luck. We're all counting on
> > you.</Dr.Rumack>
> >
> 
> Obligatory Spaceballs chaser:
> "But when will then be now?"
> "Soon."
> 

Computer: Ten... nine... eight... six... 
President: Six?!?!? What happened to seven? 
Computer: Just kidding! Seven... six... five... four... three... two...
one... have a nice day. 
All: Thank you.

...

- Gilboa





From marc at mwiriadi.id.au  Thu Nov  8 14:18:42 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Thu, 08 Nov 2007 23:18:42 +0900
Subject: Ownership gnome-themes-extras
Message-ID: <1194531522.27158.22.camel@strikeforce.mwiriadi.id.au>

I would like to claim ownership of gnome-themes-extras it has been
updated to version 2.20.

Does anyone have any objections?

Also is the recommendation to break down the packages into smaller
packages or would the gnome-themes-extras be able to be included as one
big package?

Cheers,

Marc



From choeger at cs.tu-berlin.de  Thu Nov  8 14:23:03 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-1?Q?Christoph_H=F6ger?=)
Date: Thu, 08 Nov 2007 15:23:03 +0100
Subject: fedora 8 torrents
In-Reply-To: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
References: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
Message-ID: <47331BC7.3090304@cs.tu-berlin.de>

Hi,

where did you get the torrent from?
I would like to use my High Speed Access at university for seeding.

Valent Turkovic schrieb:
> I have already seeded 5GB of Fedora 8 DVD, my download is only 20% complete.
> My upload is limited at 8Mbits/s but only 2-3 are currently used...
> come on people, what are you waiting for :)
> 
> ps. when will be fedora 8 gnome live cd available? And the home page
> is still showing 1 day till fedora 8, isn't today the date?
> 
> ps.  I'm in Europe and here is 3PM allready. I hoped that by 10AM
> fedora will be officially out - but I guess that was the case with
> openSUSE so I mixed the time zones...
> 
> Valent.
> 



From caillon at redhat.com  Thu Nov  8 14:23:48 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 08 Nov 2007 15:23:48 +0100
Subject: F9 Feature Process
In-Reply-To: <1194457571.4622.14.camel@dawkins>
References: <47293CBF.7020900@redhat.com> <4731CDD6.90804@redhat.com>
	<1194457571.4622.14.camel@dawkins>
Message-ID: <47331BF4.4010307@redhat.com>

David Nielsen wrote:
> ons, 07 11 2007 kl. 15:38 +0100, skrev Christopher Aillon:
> 
>> 
>> Is it really worth getting people to update their feature page every two 
>> weeks?  I'd argue it's much better to start looking for updates in the 
>> week or two prior to the freeze as those will be more meaningful.  We 
>> should also encourage people to update their page regularly (or when 
>> their feature is completed), but I'm not convinced that enforcing this 
>> is a good idea.
> 
> Having reasonably updatyed feature pages really aids in advocacy. It
> gives us a place to point people to as a means of showing what is
> coming. Additionally not having the updated before the last few weeks
> makes it look like we never do anything, which we can agree is untrue.
> 
> Meaning is not just having a finished product, it's marketing it,
> getting people interested in the product and it's placing it in a larger
> software ecosystem. Please feel free to tell us empty but expensive
> sounding words of love when explaining to us how your feature will
> improve our lives. We like that.. it makes us all hot and bothered about
> Fedora.

So let's have beat reporters.  Come to the weekly SIG meetings.  Ask 
questions about features.  Write a blog report about the progress. 
Maybe have it in FWN.  Having people write about it in this fashion is 
much more excitement generating than a boring static page that people 
have to manually check every so often.

Engineers want to work on the features not the paragraphs, or maybe they 
aren't good at writing things in an exciting way.  If we really want to 
generate excitement, and get people interested in things, then features 
pages is IMO the wrong approach.



From bpepple at fedoraproject.org  Thu Nov  8 14:26:33 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 08 Nov 2007 09:26:33 -0500
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <64b14b300711080555n5b62b5a2pacca35e6bc31d816@mail.gmail.com>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>
	<64b14b300711080555n5b62b5a2pacca35e6bc31d816@mail.gmail.com>
Message-ID: <1194531993.1969.4.camel@nixon>

On Thu, 2007-11-08 at 14:55 +0100, Valent Turkovic wrote:
> What app do you recommend as an multi-IM client?

If your feeling adventurous, you might try Empathy which uses the
Telepathy framework and the Gossip front-end.

/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/f62bbe9b/attachment.sig>

From gary at mlbassoc.com  Thu Nov  8 14:27:40 2007
From: gary at mlbassoc.com (Gary Thomas)
Date: Thu, 08 Nov 2007 07:27:40 -0700
Subject: fedora 8 torrents
In-Reply-To: <47331BC7.3090304@cs.tu-berlin.de>
References: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
	<47331BC7.3090304@cs.tu-berlin.de>
Message-ID: <47331CDC.8020205@mlbassoc.com>

Christoph H?ger wrote:
> Hi,
> 
> where did you get the torrent from?

Indeed - all of the FC8 torrents have vanished from http://torrent.fedoraproject.org/ :-(

> I would like to use my High Speed Access at university for seeding.

> Valent Turkovic schrieb:
>> I have already seeded 5GB of Fedora 8 DVD, my download is only 20%
>> complete.
>> My upload is limited at 8Mbits/s but only 2-3 are currently used...
>> come on people, what are you waiting for :)
>>
>> ps. when will be fedora 8 gnome live cd available? And the home page
>> is still showing 1 day till fedora 8, isn't today the date?
>>
>> ps.  I'm in Europe and here is 3PM allready. I hoped that by 10AM
>> fedora will be officially out - but I guess that was the case with
>> openSUSE so I mixed the time zones...
>>
>> Valent.
>>
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



From nicu_fedora at nicubunu.ro  Thu Nov  8 14:28:07 2007
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 08 Nov 2007 16:28:07 +0200
Subject: fedora 8 torrents
In-Reply-To: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
References: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
Message-ID: <47331CF7.10501@nicubunu.ro>

Valent Turkovic wrote:
> ps. when will be fedora 8 gnome live cd available? And the home page
> is still showing 1 day till fedora 8, isn't today the date?

Yup, unfortunately we don't have a counter for hours and minutes...

> ps.  I'm in Europe and here is 3PM allready. I hoped that by 10AM
> fedora will be officially out - but I guess that was the case with
> openSUSE so I mixed the time zones...

Fedora releases are based on the US time, so you have a few more minutes 
of waiting.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro



From skvidal at fedoraproject.org  Thu Nov  8 14:26:06 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 08 Nov 2007 09:26:06 -0500
Subject: fedora 8 torrents
In-Reply-To: <47331BC7.3090304@cs.tu-berlin.de>
References: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
	<47331BC7.3090304@cs.tu-berlin.de>
Message-ID: <1194531966.15170.0.camel@cutter>


On Thu, 2007-11-08 at 15:23 +0100, Christoph H?ger wrote:
> Hi,
> 
> where did you get the torrent from?
> I would like to use my High Speed Access at university for seeding.

the release will be up in 30 minutes. Just wait 30 minutes.

-sv




From shap at eros-os.com  Thu Nov  8 14:31:09 2007
From: shap at eros-os.com (Jonathan S. Shapiro)
Date: Thu, 08 Nov 2007 09:31:09 -0500
Subject: When will CVS be replaced by modern version control system?
Message-ID: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>

I have to say that since we switched to mercurial we haven't looked
back. We are finding advantages to distributed VCS even though our
workflow model is basically centralized.

For purposes of centralized workflow, the main change is that
centralized processing is triggered by "push" rather than by "commit".
With this exception, the workflow is basically unchanged relative to
other centralized workflows.

What hg is buying us is the following:

  1. I can set up a temporary local workspace, make and retract local
     commits, figure out what the heck I was doing, and easily generate
     a consolidated commit at the end.

     This is VERY helpful when I am multitasking (one problem, one
     workspace). It is also very helpful when I am moving work back
     and forth between office and home and don't want to commit
     centrally yet.

  2. We can pull changesets laterally to accept patches or to
     collaborate with outsiders for review, and then have the
     reviewer push them forward into the central repo.

  3. The ability to work on airplanes or in remote locations and
     recover when we screw up.

So far, we aren't making a lot of use of patch queues, mainly because we
haven't had time to learn about that much.

I'm not pushing for any change. I'm just trying to answer the workflow
question.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org



From lkundrak at redhat.com  Thu Nov  8 14:33:37 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 08 Nov 2007 15:33:37 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108100819.GA12141@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
Message-ID: <1194532417.6559.21.camel@localhost.localdomain>


On Thu, 2007-11-08 at 11:08 +0100, Adam Tkac wrote:
> On Wed, Nov 07, 2007 at 11:41:58AM -0600, Josh Boyer wrote:
> > On Wed, 7 Nov 2007 15:12:45 +0100
> > Adam Tkac <atkac at redhat.com> wrote:
> > 
> > > Hi all,
> > > 
> > > CVS has already passed over best years. I'm wonder why modern
> > > project like Fedora still has sources in this ancient system. Are here
> > > any plans to replace it by git, mercurial, svn or other more modern
> > > version control system?

We don't use it as a true version conrtol system anyways.

> It's not replacement for fun. Yes, CVS works and I believe it will
> work to end of universe. But question is if We have something better
> than CVS. And We have. There're some common problems (yes, CVS and
> SVN suffer :) )

And other VC systems have no problems, right?

> - you have to keep huge changes on your machine when you're doing
>   bigger patch. And it is really confusing sometimes

Careful branching and tagging enables you to be able to commit often while avoiding a big mess.

> - you can't easily move source tree under development. When I want to
>   do development on more machines I have to do ssh, diff, scp, patch. It's
>   pretty annoying

The abovve + CVS update. And what's wrong with ssh, diff, scp and patch?
If you're doing one thing over and over -- ever heard of scripts?

> - when you're doing on some feature you can't do on it simulateously
>   with maintenance & bugfixing. You have to diff, save diff, fix bug,
>   commit, dig your uncomplete "feature" patch, patch source and
>   continue on development

Branches.

> - CVS server outage :)

Other services never have outages?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From sb at monkey-mind.net  Thu Nov  8 14:35:07 2007
From: sb at monkey-mind.net (Steven Bakker)
Date: Thu, 8 Nov 2007 15:35:07 +0100
Subject: fedora 8 torrents
In-Reply-To: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
References: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
Message-ID: <20071108153507.2c0d9906@cluestix.noc.ams-ix.net>

On Thu, 8 Nov 2007 14:50:02 +0100 Valent Turkovic wrote:

> I have already seeded 5GB of Fedora 8 DVD, my download is only 20%
> complete. My upload is limited at 8Mbits/s but only 2-3 are currently
> used

Torrent has not been officially released, hence not many people are seeding.

> ... come on people, what are you waiting for :)

We're waiting for the torrent files to show up. ;-)

> ps. when will be fedora 8 gnome live cd available? And the home page
> is still showing 1 day till fedora 8, isn't today the date?

> ps.  I'm in Europe and here is 3PM allready. I hoped that by 10AM
> fedora will be officially out - but I guess that was the case with
> openSUSE so I mixed the time zones...

Max wrote:

  On Thursday November 8th (about 3:00 PM GMT), ...

Mainland Europe is in timezone CET, i.e. GMT+1 (or, more accurately
UTC+1), so you'll have to wait until 16:00 CET.

I'm used to 24-hour time indications, so I initially thought "Hey, 3 in
the morning? Sweet!" Until I read "PM"... ;-)

-- Steven



From caillon at redhat.com  Thu Nov  8 14:36:48 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 08 Nov 2007 15:36:48 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <473226CE.60201@gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<200711071938.48209.opensource@till.name>	<20071107195201.GA4263@serv.smile.org.ua>	<20071107202611.GA31380@redhat.com>
	<473226CE.60201@gmail.com>
Message-ID: <47331F00.30708@redhat.com>

Les Mikesell wrote:
> If you run cvsweb (now viewvc) on the cvs repository it is easy to 
> cherry-pick any file/revision you want or diff between any committed 
> versions through the browser interface.

Not so.  You can only view devel/



From jkeating at redhat.com  Thu Nov  8 14:47:20 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 8 Nov 2007 09:47:20 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
Message-ID: <20071108094720.1a18ded1@redhat.com>

On Thu, 08 Nov 2007 09:31:09 -0500
"Jonathan S. Shapiro" <shap at eros-os.com> wrote:

> What hg is buying us is the following:
> 
>   1. I can set up a temporary local workspace, make and retract local
>      commits, figure out what the heck I was doing, and easily
> generate a consolidated commit at the end.
> 
>      This is VERY helpful when I am multitasking (one problem, one
>      workspace). It is also very helpful when I am moving work back
>      and forth between office and home and don't want to commit
>      centrally yet.
> 
>   2. We can pull changesets laterally to accept patches or to
>      collaborate with outsiders for review, and then have the
>      reviewer push them forward into the central repo.
> 
>   3. The ability to work on airplanes or in remote locations and
>      recover when we screw up.
> 
> So far, we aren't making a lot of use of patch queues, mainly because
> we haven't had time to learn about that much.
> 
> I'm not pushing for any change. I'm just trying to answer the workflow
> question.

Have you ever found yourself needing to do any of those things within
the context of our Package VCS?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/054c7d9e/attachment.sig>

From valent.turkovic at gmail.com  Thu Nov  8 14:50:30 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 8 Nov 2007 15:50:30 +0100
Subject: fedora 8 torrents
In-Reply-To: <47331BC7.3090304@cs.tu-berlin.de>
References: <64b14b300711080550q40cc3d9avede471451dc39588@mail.gmail.com>
	<47331BC7.3090304@cs.tu-berlin.de>
Message-ID: <64b14b300711080650v3b618f09naeb8ba8cd56639cd@mail.gmail.com>

On 11/8/07, Christoph H?ger <choeger at cs.tu-berlin.de> wrote:
> Hi,
>
> where did you get the torrent from?
> I would like to use my High Speed Access at university for seeding.
>

I got them from here:
http://linuxtracker.org/

and if you search for "feodra 8" on digg there ware a few mirrors
links for ISO files there... but I like to seed so I was waiting for
torrents...

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From andy at smile.org.ua  Thu Nov  8 14:55:45 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Thu, 8 Nov 2007 16:55:45 +0200
Subject: fedora 8 could be first
Message-ID: <20071108145545.GB4263@serv.smile.org.ua>

Hi!

In the koji/bodhi web interface the Fedora 7 is default parameter for 'New
update' form. Please, set it to Fedora 8. Thanks.

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From rc040203 at freenet.de  Thu Nov  8 14:58:21 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 08 Nov 2007 15:58:21 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
Message-ID: <1194533901.9673.433.camel@mccallum.corsepiu.local>

On Thu, 2007-11-08 at 09:31 -0500, Jonathan S. Shapiro wrote:
> I have to say that since we switched to mercurial we haven't looked
> back. We are finding advantages to distributed VCS even though our
> workflow model is basically centralized.
> 
> For purposes of centralized workflow, the main change is that
> centralized processing is triggered by "push" rather than by "commit".
> With this exception, the workflow is basically unchanged relative to
> other centralized workflows.
Right things are different, that's all.

> What hg is buying us is the following:
[..]
> 
> I'm not pushing for any change. I'm just trying to answer the workflow
> question.
Where in Fedora's package development would you see niches to apply
these aspects? I don't see any.

Finally, being a long term CVS user, would has very mixed experiences
wrt. SVN, and who has recently been confronted with both git and
mercurial, I can't deny finding both git and hg as not to be suitable
for centralized development. They don't really buy much.

Ralf





From fedora at camperquake.de  Thu Nov  8 15:04:01 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 8 Nov 2007 16:04:01 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071108094720.1a18ded1@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
Message-ID: <20071108160401.5990cfea@dhcp03.addix.net>

Hi.

On Thu, 8 Nov 2007 09:47:20 -0500, Jesse Keating wrote:

> Have you ever found yourself needing to do any of those things within
> the context of our Package VCS?

Most of it is probably useless in this context.
But being able to work offline is an argument for me.

As is being able to generate local diffs.



From jdieter at gmail.com  Thu Nov  8 15:33:08 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 08 Nov 2007 17:33:08 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
Message-ID: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>

Within the next five or six hours, there should be deltarpms available
for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
when they become available.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/3593d8a5/attachment.sig>

From lmacken at redhat.com  Thu Nov  8 15:39:41 2007
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 8 Nov 2007 10:39:41 -0500
Subject: fedora 8 could be first
In-Reply-To: <20071108145545.GB4263@serv.smile.org.ua>
References: <20071108145545.GB4263@serv.smile.org.ua>
Message-ID: <20071108153940.GF11043@crow.myhome.westell.com>

On Thu, Nov 08, 2007 at 04:55:45PM +0200, Andy Shevchenko wrote:
> Hi!
> 
> In the koji/bodhi web interface the Fedora 7 is default parameter for 'New
> update' form. Please, set it to Fedora 8. Thanks.

There is a "New Update" link for each release, which will pre-populate
the release field.  I plan on unifying this form in the near future to
allow pushing for multiple releases at once.

luke



From myfedora at richip.dhs.org  Thu Nov  8 16:01:18 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 08 Nov 2007 09:01:18 -0700
Subject: openid support for f9?
In-Reply-To: <fgut5p$2b1$1@ger.gmane.org>
References: <fgut5p$2b1$1@ger.gmane.org>
Message-ID: <1194537678.25638.12.camel@localhost6.localdomain6>

On Thu, 2007-11-08 at 06:50 -0500, Neal Becker wrote:
> It seems that openid is moving along.  Maybe f9 can integrate openid as an
> SSO solution?
> 
> http://lwn.net/Articles/255774/

Certainly an interesting concept, but that would pull us way too far
into the Internet space (as opposed to local or even private domain
space). How would an openid user map to Linux in terms of UID? Would a
uid be assigned on a local machine? On the domain (if the machine the
person is logging into happens to be a part of a bigger network)? Does
the OpenID spec have provisions for account authorization and
information? There are still some UNIX-y things needed by current
distributions that we have to find solutions for.

OTOH, it ties well with the Gnome Online Desktop idea, once you get past
(or provide for) the things that traditional Unix accounts need. It
would do well on truly public kiosks where authorization can be some
public default and accounting based in OpenID.

I was going to try my hand at writing an OpenID PAM module, but found a
project already started on google
(http://code.google.com/p/pam-openid/ ) It's linked to from these blogs:
http://kveton.com/blog/2006/12/10/openid-pam/ and
http://yablog-gary.blogspot.com/2007/10/openid-pam-and-apache.html .
According to one site, they had some discussion going, but the posts
were lost or yanked.

At any rate, I'll play around with the idea and post results there.
--

Richi Plana



From jonathan.underwood at gmail.com  Thu Nov  8 16:04:49 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 8 Nov 2007 16:04:49 +0000
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
Message-ID: <645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>

On 08/11/2007, Jonathan Dieter <jdieter at gmail.com> wrote:
> Within the next five or six hours, there should be deltarpms available
> for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
> when they become available.

For x86_64 as well as i386?



From david at lovesunix.net  Thu Nov  8 16:06:02 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 08 Nov 2007 17:06:02 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <1194531993.1969.4.camel@nixon>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>
	<64b14b300711080555n5b62b5a2pacca35e6bc31d816@mail.gmail.com>
	<1194531993.1969.4.camel@nixon>
Message-ID: <1194537962.2836.4.camel@dawkins>


tor, 08 11 2007 kl. 09:26 -0500, skrev Brian Pepple:
> On Thu, 2007-11-08 at 14:55 +0100, Valent Turkovic wrote:
> > What app do you recommend as an multi-IM client?
> 
> If your feeling adventurous, you might try Empathy which uses the
> Telepathy framework and the Gossip front-end.

I second that recommendation, Empathy does it all and with style.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/28b66fc8/attachment.sig>

From myfedora at richip.dhs.org  Thu Nov  8 16:05:43 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 08 Nov 2007 09:05:43 -0700
Subject: NFS Update and SELinux
In-Reply-To: <4731F358.7040405@redhat.com>
References: <1193856288.12145.9.camel@localhost6.localdomain6>
	<472A13D9.4010105@redhat.com>
	<1193941654.3848.5.camel@localhost6.localdomain6>
	<473087ED.7020101@redhat.com>
	<1194371113.4985.3.camel@localhost6.localdomain6>
	<4731F358.7040405@redhat.com>
Message-ID: <1194537943.25638.15.camel@localhost6.localdomain6>

On Wed, 2007-11-07 at 12:18 -0500, Daniel J Walsh wrote:
> Richi Plana wrote:
> > I _WAS_ thinking of asking, however, what sort of actions can be placed
> > in the %post section of packages which need immediate action? I know
> > some services restart themselves after package updates (but some don't.
> > I wonder if this should be made policy). In the case of selinux, would a
> > kernel module reload solve the mislabeled device files? A restart? (I
> > did notice that at one point in time, I got an advisory to restart the
> > computer after a set of updates. I can't remember where or what it was
> > now)
> > --
> > 
> > Richi Plana
> > 
> selinux-policy attempts to fix labeling as it updates.  Most of the time
> you should/would not need to do anything.  But occasionally restarting
> domains/programs is necessary.

Being security-related, shouldn't actions needed to ensure effectivity
be encouraged? If not a system restart, what about that "domain
restarting" that you mentioned? How is that performed? Would it cover
all cases?
--

Richi Plana



From jdieter at gmail.com  Thu Nov  8 16:16:37 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 08 Nov 2007 18:16:37 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
Message-ID: <1194538597.3737.14.camel@jndwidescreen.lesbg.loc>

On Thu, 2007-11-08 at 16:04 +0000, Jonathan Underwood wrote:
> On 08/11/2007, Jonathan Dieter <jdieter at gmail.com> wrote:
> > Within the next five or six hours, there should be deltarpms available
> > for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
> > when they become available.
> 
> For x86_64 as well as i386?
> 
Afraid not yet.  Give me a day or two and I should have them up and
ready to go.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/1092bd0d/attachment.sig>

From janina at rednote.net  Thu Nov  8 16:26:35 2007
From: janina at rednote.net (Janina Sajka)
Date: Thu, 8 Nov 2007 11:26:35 -0500
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
Message-ID: <20071108162635.GE6342@rednote.net>

Kelly Miller writes:
> Well, now that F8 is approaching release, I wanted to bring up the
> possibility of updating the configuration utilities again.  I'd be
> willing to work on such a project (fixing the frontend problems so the
> utilities could be used without X, etc.), but I'm not entirely
> familiar with all the options covered by the utilities (for example,
> I've never used the cluster management or bootloader editor systems,
> and I'm not completely familiar with all of the configuration files
> here).  First of all, is there a preferred language for development

If you use gtk2 you get accessibility support pretty much by default.
You also get the opportunity for scripted testing via Dogtail (and/or
LDTP) as these rely on the accessibility framework.

Janina


> like this?  I've actually done very little to no Python development
> (though I've done development in similar RAD languages like Ruby, Java
> and C# so I'm familiar with the general concepts), but I'll give it a
> shot in Python if that's preferred.  Secondly, is there a decent
> resource for covering some of the configuration files required by the
> programs?
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From lmacken at redhat.com  Thu Nov  8 16:41:16 2007
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 8 Nov 2007 11:41:16 -0500
Subject: No pushes to updates-testing for F-7?
In-Reply-To: <loom.20071108T011831-74@post.gmane.org>
References: <3170f42f0711062252p5e7246a0n6917c6d913946347@mail.gmail.com>
	<loom.20071108T011831-74@post.gmane.org>
Message-ID: <20071108164116.GG11043@crow.myhome.westell.com>

On Thu, Nov 08, 2007 at 01:20:00AM +0000, Kevin Kofler wrote:
> Debarshi 'Rishi' Ray <debarshi.ray <at> gmail.com> writes:
> > It seems no one has been signing and pushing packages to
> > updates-testing for F-7 for the last 12 days or so.
> 
> It's because the following bug is breaking the composes of the F7 
> updates-testing repo:
> https://bugzilla.redhat.com/show_bug.cgi?id=360291
> Looks like a fix is available now, hopefully to land in production ASAP.

I just patched yum on releng1, and successfully mashed
f7-updates-testing.  It should get rsync'd to our master mirror shortly.

Much thanks to our yum-ninja Tim Lauridsen for tracking down and patching
the depsolver bug!


luke



From myfedora at richip.dhs.org  Thu Nov  8 16:42:07 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 08 Nov 2007 09:42:07 -0700
Subject: openid support for f9?
In-Reply-To: <1194537678.25638.12.camel@localhost6.localdomain6>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
Message-ID: <1194540127.26595.4.camel@localhost6.localdomain6>

A question for the fedora folks: in terms of libraries, what should I
use in pam modules for:

a) string processing & manipulation support (glib?)
b) Network access (specifically HTTP and HTTPS)
c) Diffie-Hellman Key Exchange

Some have multiple implementations and I'm wondering if there are any
that are considered a "core" part of any Fedora installation. By "core",
I really just mean something that's most likely to be installed by even
the most stripped-down version of Fedora.
--

Richi Plana


On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> On Thu, 2007-11-08 at 06:50 -0500, Neal Becker wrote:
> > It seems that openid is moving along.  Maybe f9 can integrate openid as an
> > SSO solution?
> > 
> > http://lwn.net/Articles/255774/
> 
> Certainly an interesting concept, but that would pull us way too far
> into the Internet space (as opposed to local or even private domain
> space). How would an openid user map to Linux in terms of UID? Would a
> uid be assigned on a local machine? On the domain (if the machine the
> person is logging into happens to be a part of a bigger network)? Does
> the OpenID spec have provisions for account authorization and
> information? There are still some UNIX-y things needed by current
> distributions that we have to find solutions for.
> 
> OTOH, it ties well with the Gnome Online Desktop idea, once you get past
> (or provide for) the things that traditional Unix accounts need. It
> would do well on truly public kiosks where authorization can be some
> public default and accounting based in OpenID.
> 
> I was going to try my hand at writing an OpenID PAM module, but found a
> project already started on google
> (http://code.google.com/p/pam-openid/ ) It's linked to from these blogs:
> http://kveton.com/blog/2006/12/10/openid-pam/ and
> http://yablog-gary.blogspot.com/2007/10/openid-pam-and-apache.html .
> According to one site, they had some discussion going, but the posts
> were lost or yanked.
> 
> At any rate, I'll play around with the idea and post results there.
> --
> 
> Richi Plana
> 



From mattdm at mattdm.org  Thu Nov  8 16:48:23 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 8 Nov 2007 11:48:23 -0500
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
Message-ID: <20071108164823.GA26392@jadzia.bu.edu>

On Wed, Nov 07, 2007 at 09:55:08AM -0500, Kelly Miller wrote:
> here).  First of all, is there a preferred language for development
> like this?  I've actually done very little to no Python development

Almost certainly Python.

The key reason these utilties need rewriting is to separate the user
interface (GUI, full-screen text-mode, and command-line) from the possibly
privileged actions they need to perform. 

This should be done using PolicyKit -- see
<http://fedoraproject.org/wiki/Releases/FeaturePolicyKit>.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From ville.skytta at iki.fi  Thu Nov  8 17:08:19 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 8 Nov 2007 19:08:19 +0200
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <47331F00.30708@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<473226CE.60201@gmail.com> <47331F00.30708@redhat.com>
Message-ID: <200711081908.19695.ville.skytta@iki.fi>

On Thursday 08 November 2007, Christopher Aillon wrote:
> Les Mikesell wrote:
> > If you run cvsweb (now viewvc) on the cvs repository it is easy to
> > cherry-pick any file/revision you want or diff between any committed
> > versions through the browser interface.
>
> Not so.  You can only view devel/

All branches can be seen below per-package subdirs at 
http://cvs.fedora.redhat.com/viewcvs/rpms/



From a.badger at gmail.com  Thu Nov  8 17:21:56 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 08 Nov 2007 09:21:56 -0800
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071108094720.1a18ded1@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
Message-ID: <473345B4.7030609@gmail.com>

Jesse Keating wrote:
> On Thu, 08 Nov 2007 09:31:09 -0500
> "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> 
>> What hg is buying us is the following:
>>
>>   1. I can set up a temporary local workspace, make and retract local
>>      commits, figure out what the heck I was doing, and easily
>> generate a consolidated commit at the end.
>>
>>      This is VERY helpful when I am multitasking (one problem, one
>>      workspace). It is also very helpful when I am moving work back
>>      and forth between office and home and don't want to commit
>>      centrally yet.
>>
>>   2. We can pull changesets laterally to accept patches or to
>>      collaborate with outsiders for review, and then have the
>>      reviewer push them forward into the central repo.
>>
>>   3. The ability to work on airplanes or in remote locations and
>>      recover when we screw up.
>>
>> So far, we aren't making a lot of use of patch queues, mainly because
>> we haven't had time to learn about that much.
>>
>> I'm not pushing for any change. I'm just trying to answer the workflow
>> question.
> 
> Have you ever found yourself needing to do any of those things within
> the context of our Package VCS?
> 
Actually, yes for #1 and #3.  #2, I think would go hand in hand with 
policies for bringing new packagers in as comaintainers for existing 
packages.

Most of the time, we don't think about it because cvs doesn't offer us 
the tools to make these workflows possible but it makes sense once you 
have the tools.
As an example, when creating the python egg guidelines, I had to try 
permutations of package builds that would generate eggs and see what the 
pros and cons of each one were.  I had to make changes in how eggs were 
generated in a providing spec file in one package and changes to how a 
package consumed those eggs in another spec file.  Because cvs doesn't 
have the ability to do #1, I had to create spec files with commented 
lines and build a matrix of things I had tried together.  Being able to 
create a few temporary trees locally would have helped because I could 
have committed each alternative to their own local branch, scripted a 
test that tried each of the providing branches against each of the 
consuming branches, and then only pushed the branch that was proven to 
work into the central repository.

-Toshio



From mcepl at redhat.com  Thu Nov  8 17:19:49 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 08 Nov 2007 18:19:49 +0100
Subject: When will be CVS replaced by modern version control system?
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<1194532417.6559.21.camel@localhost.localdomain>
Message-ID: <slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>

On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
>> > > any plans to replace it by git, mercurial, svn or other 
>> > > more modern version control system?
>
> We don't use it as a true version conrtol system anyways.

Could you elaborate on this answer a little bit, please?

>> - CVS server outage :)
>
> Other services never have outages?

They don't -- have you ever heard about distributed VC? If the 
repository I am working against has outage, then I don't care.

Mat?j



From mcepl at redhat.com  Thu Nov  8 17:26:50 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 08 Nov 2007 18:26:50 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>
	<64b14b300711080555n5b62b5a2pacca35e6bc31d816@mail.gmail.com>
Message-ID: <slrnfj6hmq.hsl.mcepl@hubmaier.ceplovi.cz>

On 2007-11-08, 13:55 GMT, Valent Turkovic wrote:
> What app do you recommend as an multi-IM client?

If you need strictly gaim replacement (sorry, pidgin replacement) 
I would second recommendation of empathy+telepathy. However, 
I went other way and I am now with xchat-gnome+bitlbee.

Mat?j



From opensource at till.name  Thu Nov  8 17:40:17 2007
From: opensource at till.name (Till Maas)
Date: Thu, 08 Nov 2007 18:40:17 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107195201.GA4263@serv.smile.org.ua>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711071938.48209.opensource@till.name>
	<20071107195201.GA4263@serv.smile.org.ua>
Message-ID: <200711081840.27702.opensource@till.name>

On Mi November 7 2007, Andy Shevchenko wrote:

> Modern vcs requires additional space for this operation.

When I try to emulate this with CVS, I also need the additional space.

> And second, I doubt in usefull status of this feature. IMHO, in practice
> (another words 'very often') you need to make diff between vcs' *.spec and
> current. You just make copy *.spec to *.spec.orig and use simple diff
> command.

How can I do this when I have uncommited changes in the spec, but there is a 
newer version in the repository?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/1cb8ed5b/attachment.sig>

From ssorce at redhat.com  Thu Nov  8 17:54:12 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 12:54:12 -0500
Subject: openid support for f9?
In-Reply-To: <1194537678.25638.12.camel@localhost6.localdomain6>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
Message-ID: <1194544452.3271.54.camel@localhost.localdomain>

On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> Certainly an interesting concept, but that would pull us way too far
> into the Internet space (as opposed to local or even private domain
> space). How would an openid user map to Linux in terms of UID? Would a
> uid be assigned on a local machine? On the domain (if the machine the
> person is logging into happens to be a part of a bigger network)? Does
> the OpenID spec have provisions for account authorization and
> information? There are still some UNIX-y things needed by current
> distributions that we have to find solutions for.

We have the problem of UIDs in the enterprise space right now even
without OpenID in the mix.

The problem being Posix and Linux/UNIX really are not "network-aware"
when it comes to identity.

The UID/GID are *local* by nature. All tricks used up today like NIS and
LDAP to sync UIDs/GIDs all over, are just *bad* hacks.

There are only 2 solutions that have a long term breath.

1. move to 128bit UID/GIDs that are really UUIDs
  problem is, most apps wont work, need changes in the kernel, in a
word:
	unachievable

2. Make UIDs/GIDs *only* a local thing.
  this mean changes in the vfs only, you need a mapping facility so that
you can translate them for (network) file systems.

For network file systems it is probably easier.
I expect preconcept opposition for normal filesystems tho. But that is
needed too, because if you want to use an USB pen drive or external
disk, or even an iSCSI partition you need to be able to map a UUID
stored on the filesystem to the local UID that make sense for the kernel
and all existing applications, or you are back requiring all machines in
the world synchronize with your own machines UIDs and GIDs.

/Simo "I do not except anything but a flame from this email" sadly.



From walters at redhat.com  Thu Nov  8 18:03:48 2007
From: walters at redhat.com (Colin Walters)
Date: Thu, 08 Nov 2007 13:03:48 -0500
Subject: openid support for f9?
In-Reply-To: <1194544452.3271.54.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
Message-ID: <1194545028.3422.19.camel@space-ghost.verbum.private>

On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:

> 1. move to 128bit UID/GIDs that are really UUIDs
>   problem is, most apps wont work, need changes in the kernel, in a
> word:
> 	unachievable
> 
> 2. Make UIDs/GIDs *only* a local thing.
>   this mean changes in the vfs only, you need a mapping facility so that
> you can translate them for (network) file systems.

3. Ignore UIDs as an implementation detail of the local OS, and use
situation-specific logic to Do The Right Thing.
 
For example, if I copy/restore my /home directory on a remote server and
then sync it back to a new install, and the current UID happens to be
different because Fedora changes UIDs to start with 700 in Fedora 10
because we need more for system services, the clearly right thing here
is to just change the UID of all the files downloaded to 700, not keep
500 and fail.  

If you frame the problem too generally, then yes, it becomes impossible
to solve.  But for most of them, I think the right answer is to not try
to push all logic into the OS (filesystem/kernel/libc), but apply
situation-specific logic to do the right thing.




From sundaram at fedoraproject.org  Thu Nov  8 18:01:51 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 08 Nov 2007 23:31:51 +0530
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
Message-ID: <47334F0F.5030106@fedoraproject.org>

Jonathan Dieter wrote:
> Within the next five or six hours, there should be deltarpms available
> for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
> when they become available.

Great. Is this planned to be default for Fedora 9?

Rahul



From alan at redhat.com  Thu Nov  8 18:09:27 2007
From: alan at redhat.com (Alan Cox)
Date: Thu, 8 Nov 2007 13:09:27 -0500
Subject: openid support for f9?
In-Reply-To: <1194544452.3271.54.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
Message-ID: <20071108180927.GA12738@devserv.devel.redhat.com>

On Thu, Nov 08, 2007 at 12:54:12PM -0500, Simo Sorce wrote:
> The problem being Posix and Linux/UNIX really are not "network-aware"
> when it comes to identity.

They make certain assumptions about what a uid or gid is, and also about
the way they can be manipulated. However that is a *solved* problem.

> The UID/GID are *local* by nature. All tricks used up today like NIS and
> LDAP to sync UIDs/GIDs all over, are just *bad* hacks.

They work, they solve the problem for local users and they make it easy
locally to solve the "who owns this" problem, as opposed to the "can I ..." 
problem.

> 1. move to 128bit UID/GIDs that are really UUIDs
>   problem is, most apps wont work, need changes in the kernel, in a
> word:
> 	unachievable

This doesn't work anyway - a UUID is intended to avoid collisions, it is
not intended to be securely unique.

> 2. Make UIDs/GIDs *only* a local thing.
>   this mean changes in the vfs only, you need a mapping facility so that
> you can translate them for (network) file systems.

Yes - which unfsd supported in 1994 or so.

> I expect preconcept opposition for normal filesystems tho. But that is
> needed too, because if you want to use an USB pen drive or external
> disk, or even an iSCSI partition you need to be able to map a UUID
> stored on the filesystem to the local UID that make sense for the kernel
> and all existing applications, or you are back requiring all machines in
> the world synchronize with your own machines UIDs and GIDs.

For remote access to data you need to stop thinking in terms of "if I say
I am number 6 you say yes" and instead move to managing key chains via 
kerberos and similar systems - exactly as AFS has dealt with the problem
and NFSv4 has the framework to handle it.

Short of having a DNS like global "phonebook" for UIDs the solvable problem
is "can I have access to xyz"

Not co-incidentally the kernel has a key management service now, which is
ideal for such purposes.

Alan



From mclasen at redhat.com  Thu Nov  8 18:13:40 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 08 Nov 2007 13:13:40 -0500
Subject: openid support for f9?
In-Reply-To: <1194544452.3271.54.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
Message-ID: <1194545620.4204.12.camel@localhost.localdomain>


On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
> On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> > Certainly an interesting concept, but that would pull us way too far
> > into the Internet space (as opposed to local or even private domain
> > space). How would an openid user map to Linux in terms of UID? Would a
> > uid be assigned on a local machine? On the domain (if the machine the
> > person is logging into happens to be a part of a bigger network)? Does
> > the OpenID spec have provisions for account authorization and
> > information? There are still some UNIX-y things needed by current
> > distributions that we have to find solutions for.
> 
> We have the problem of UIDs in the enterprise space right now even
> without OpenID in the mix.
> 
> The problem being Posix and Linux/UNIX really are not "network-aware"
> when it comes to identity.

This seems like an excellent occasion to point to the freeIPA project
(wwww.freeeipa.org), which we will hopefully start to appear in Fedora
fairly soon.





From rc040203 at freenet.de  Thu Nov  8 18:19:44 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 08 Nov 2007 19:19:44 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<1194532417.6559.21.camel@localhost.localdomain>
	<slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
Message-ID: <1194545984.9673.458.camel@mccallum.corsepiu.local>

On Thu, 2007-11-08 at 18:19 +0100, Matej Cepl wrote:
> On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
> >> > > any plans to replace it by git, mercurial, svn or other 
> >> > > more modern version control system?

> >> - CVS server outage :)
> >
> > Other services never have outages?
> 
> They don't -- have you ever heard about distributed VC? If the 
> repository I am working against has outage, then I don't care.
And how do you pull/push if the remote server is down?

Ralf




From david at lovesunix.net  Thu Nov  8 18:21:16 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 08 Nov 2007 19:21:16 +0100
Subject: openid support for f9?
In-Reply-To: <1194545620.4204.12.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<1194545620.4204.12.camel@localhost.localdomain>
Message-ID: <1194546076.2836.6.camel@dawkins>


tor, 08 11 2007 kl. 13:13 -0500, skrev Matthias Clasen:
> On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
> > On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> > > Certainly an interesting concept, but that would pull us way too far
> > > into the Internet space (as opposed to local or even private domain
> > > space). How would an openid user map to Linux in terms of UID? Would a
> > > uid be assigned on a local machine? On the domain (if the machine the
> > > person is logging into happens to be a part of a bigger network)? Does
> > > the OpenID spec have provisions for account authorization and
> > > information? There are still some UNIX-y things needed by current
> > > distributions that we have to find solutions for.
> > 
> > We have the problem of UIDs in the enterprise space right now even
> > without OpenID in the mix.
> > 
> > The problem being Posix and Linux/UNIX really are not "network-aware"
> > when it comes to identity.
> 
> This seems like an excellent occasion to point to the freeIPA project
> (wwww.freeeipa.org), which we will hopefully start to appear in Fedora
> fairly soon.

http://freeipa.org/page/Main_Page
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/2e2d1ea0/attachment.sig>

From caillon at redhat.com  Thu Nov  8 18:35:18 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 08 Nov 2007 19:35:18 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711081908.19695.ville.skytta@iki.fi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<473226CE.60201@gmail.com>
	<47331F00.30708@redhat.com>
	<200711081908.19695.ville.skytta@iki.fi>
Message-ID: <473356E6.2030204@redhat.com>

Ville Skytt? wrote:
> On Thursday 08 November 2007, Christopher Aillon wrote:
>> Les Mikesell wrote:
>> > If you run cvsweb (now viewvc) on the cvs repository it is easy to
>> > cherry-pick any file/revision you want or diff between any committed
>> > versions through the browser interface.
>>
>> Not so.  You can only view devel/
> 
> All branches can be seen below per-package subdirs at 
> http://cvs.fedora.redhat.com/viewcvs/rpms/

Ah, that's new then.  Thanks for the tip.



From rc040203 at freenet.de  Thu Nov  8 18:34:50 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 08 Nov 2007 19:34:50 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711081840.27702.opensource@till.name>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711071938.48209.opensource@till.name>
	<20071107195201.GA4263@serv.smile.org.ua>
	<200711081840.27702.opensource@till.name>
Message-ID: <1194546890.9673.469.camel@mccallum.corsepiu.local>

On Thu, 2007-11-08 at 18:40 +0100, Till Maas wrote:
> On Mi November 7 2007, Andy Shevchenko wrote:
> 
> > Modern vcs requires additional space for this operation.
> 
> When I try to emulate this with CVS, I also need the additional space.
Right _you_ would have to have _one_ modified source tree in parallel if
_you_ would want to do this. These so called modern VCS force you to do
so. Also, with svn etc. you have the whole history bloating and
polluting your checkout (Now try recursively grepping a deep source-tree
with a long history. Try gcc's (svn) source-tree to experience what I am
referring to).

> > And second, I doubt in usefull status of this feature. IMHO, in practice
> > (another words 'very often') you need to make diff between vcs' *.spec and
> > current. You just make copy *.spec to *.spec.orig and use simple diff
> > command.
> 
> How can I do this when I have uncommited changes in the spec, but there is a 
> newer version in the repository?
How is that a problem with CVS? With CVS you typically work on a
checkout, so it's up to you how to handle mergers.

Ralf





From jkeating at redhat.com  Thu Nov  8 18:41:19 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 8 Nov 2007 13:41:19 -0500
Subject: After Fedora 8 comes Fedora 9!
Message-ID: <20071108134119.4653a86b@redhat.com>

The development cycle of Fedora 9 will begin in earnest tomorrow.  This
will mark the first attempt at composing Rawhide with package builds
that target Fedora 9.  There is quite a number of them built up
already, over 800.  This will be a bumpy ride at first as we start to
see where all these builds gets us.  In the next couple of weeks we the
project will work on setting a schedule for Fedora 9, start reviewing
proposed Features, and come up with an overall idea of what we'd like
to accomplish this time around.

For those of you that were early adopters of Fedora 8 and joined the
Rawhide bandwagon, but want to get off at the Fedora 8 stop, I suggest
that you ensure your 'development' yum repo is disabled.  For those of
you that wish to continue to enjoy Rawhide, I suggest you ensure that
your 'fedora', and any updates repos are disabled, and make sure that
your development repo remains enabled.

During the development of Fedora 8 we experimented with a few things to
help users and developers of Fedora have a smooth ride through the
development cycle.  Those experiments have worked out pretty well and
have been incorporated into the overall development strategy, as
oulined here:
http://fedoraproject.org/wiki/ReleaseEngineering/Overview  As we look forward to Fedora 9 we hope to make the experience even more enjoyable and at the same time even more beneficial to all involved.  I welcome suggestions and discussion on how to improve things, which is always a constant goal of mine.

So lets all sit back, relax, and enjoy a day of rest for Fedora 8.
Tomorrow it starts up all over again!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/8d1793d2/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From a.badger at gmail.com  Thu Nov  8 18:48:48 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 08 Nov 2007 10:48:48 -0800
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194546890.9673.469.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<200711071938.48209.opensource@till.name>	<20071107195201.GA4263@serv.smile.org.ua>	<200711081840.27702.opensource@till.name>
	<1194546890.9673.469.camel@mccallum.corsepiu.local>
Message-ID: <47335A10.3070900@gmail.com>

Ralf Corsepius wrote:
> On Thu, 2007-11-08 at 18:40 +0100, Till Maas wrote:
>> On Mi November 7 2007, Andy Shevchenko wrote:
>>
>>> Modern vcs requires additional space for this operation.
>> When I try to emulate this with CVS, I also need the additional space.
> Right _you_ would have to have _one_ modified source tree in parallel if
> _you_ would want to do this. These so called modern VCS force you to do
> so. Also, with svn etc. you have the whole history bloating and
> polluting your checkout (Now try recursively grepping a deep source-tree
> with a long history. Try gcc's (svn) source-tree to experience what I am
> referring to).
> 
svn just keeps two copies around.  working tree and pristine last checkout.

True distributed VCS keeps all history around.  However, they also 
typically keep the history in a compressed or other binary form so the 
problem you have with recursive grep is not nearly so bad in those systems.

Also, some VCS's (for instance, bazaar) do differentiate between 
repositories and working trees/branches and checkouts.  So "bzr checkout 
--lightweight" will get you a CVS-like checkout without history.

-Toshio



From davej at redhat.com  Thu Nov  8 18:52:11 2007
From: davej at redhat.com (Dave Jones)
Date: Thu, 8 Nov 2007 13:52:11 -0500
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <20071108134119.4653a86b@redhat.com>
References: <20071108134119.4653a86b@redhat.com>
Message-ID: <20071108185211.GA3888@redhat.com>

On Thu, Nov 08, 2007 at 01:41:19PM -0500, Jesse Keating wrote:

 > For those of you that were early adopters of Fedora 8 and joined the
 > Rawhide bandwagon, but want to get off at the Fedora 8 stop, I suggest
 > that you ensure your 'development' yum repo is disabled.  For those of
 > you that wish to continue to enjoy Rawhide, I suggest you ensure that
 > your 'fedora', and any updates repos are disabled, and make sure that
 > your development repo remains enabled.

People get bitten by this every release.  And no doubt, people
will this release too, because not all useres will read your
announcement.

Could we do a final update to fedora-release just before we
do the final compose to do the right thing to the repo files?

I'm sure I was talking with someone about this not too long ago,
and it was a "solved" problem, but from your message, it seems
that isn't the case.

	Dave

-- 
http://www.codemonkey.org.uk



From ssorce at redhat.com  Thu Nov  8 18:53:54 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 13:53:54 -0500
Subject: openid support for f9?
In-Reply-To: <20071108180927.GA12738@devserv.devel.redhat.com>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<20071108180927.GA12738@devserv.devel.redhat.com>
Message-ID: <1194548034.3271.94.camel@localhost.localdomain>

On Thu, 2007-11-08 at 13:09 -0500, Alan Cox wrote:
> On Thu, Nov 08, 2007 at 12:54:12PM -0500, Simo Sorce wrote:
> > The problem being Posix and Linux/UNIX really are not "network-aware"
> > when it comes to identity.
> 
> They make certain assumptions about what a uid or gid is, and also about
> the way they can be manipulated. However that is a *solved* problem.

Alan, I think we live on diffrent planets then :-)
I deal with ID mappings problems since ever in the Samba world, and I
rewrote the idmap subsystem twice, please trust me when I say the
problem is *far* from being solved, for anything but ideal cases which
do not exist on real networks.

> > The UID/GID are *local* by nature. All tricks used up today like NIS and
> > LDAP to sync UIDs/GIDs all over, are just *bad* hacks.
> 
> They work, they solve the problem for local users and they make it easy
> locally to solve the "who owns this" problem, as opposed to the "can I ..." 
> problem.

They are a hack that can be made to work, but to me this is not a good
definition of "work", and they definitely do not "just work".

> > 1. move to 128bit UID/GIDs that are really UUIDs
> >   problem is, most apps wont work, need changes in the kernel, in a
> > word:
> > 	unachievable
> 
> This doesn't work anyway - a UUID is intended to avoid collisions, it is
> not intended to be securely unique.

True, but there is almost no way to get something securely unique, and
anyway that's absolutely not the point. What we need is exactly to
avoiding collisions, not securely unique IDs.

> > 2. Make UIDs/GIDs *only* a local thing.
> >   this mean changes in the vfs only, you need a mapping facility so that
> > you can translate them for (network) file systems.
> 
> Yes - which unfsd supported in 1994 or so.

I know, there have been experiments that's why I am somewhat confident
we can easily do this.

> > I expect preconcept opposition for normal filesystems tho. But that is
> > needed too, because if you want to use an USB pen drive or external
> > disk, or even an iSCSI partition you need to be able to map a UUID
> > stored on the filesystem to the local UID that make sense for the kernel
> > and all existing applications, or you are back requiring all machines in
> > the world synchronize with your own machines UIDs and GIDs.
> 
> For remote access to data you need to stop thinking in terms of "if I say
> I am number 6 you say yes" and instead move to managing key chains via 
> kerberos and similar systems - exactly as AFS has dealt with the problem
> and NFSv4 has the framework to handle it.

I think in CIFS terms, and there the problem was solved from scratch
basically. NFSv4 is ok too, as they finally moved from trusting the
client to not trusting it. But we have to do mapping for NFSv3.

> Short of having a DNS like global "phonebook" for UIDs the solvable problem
> is "can I have access to xyz"

Exactly, but yet you need to represent identity in term of UIDs and GIDs
in the POSIX world, hence why I am slowly advocating for *local* mapping
tables. Network mapping tables simply do not work.

> Not co-incidentally the kernel has a key management service now, which is
> ideal for such purposes.

Not sure what the key management thing wins you, if you mean to store
the mapping in there, yes it can be a huge help, but the mechanism we
use to store the temporary mappings is not important, what matter is
having filesystem (and not just netwrok ones) drivers support mapping,
with a way to store mappings on removable drivers when needed. Think
agaion of a USB pen drive formatted ext2, you need at least a file where
you map the UID used on the disk to the identity used (be it an email or
a kerberos principal or whatever you can think of to represent an
identity) and for groups too. 



From ssorce at redhat.com  Thu Nov  8 18:58:59 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 13:58:59 -0500
Subject: openid support for f9?
In-Reply-To: <1194545620.4204.12.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<1194545620.4204.12.camel@localhost.localdomain>
Message-ID: <1194548339.3271.99.camel@localhost.localdomain>

On Thu, 2007-11-08 at 13:13 -0500, Matthias Clasen wrote:
> On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
> > On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> > > Certainly an interesting concept, but that would pull us way too far
> > > into the Internet space (as opposed to local or even private domain
> > > space). How would an openid user map to Linux in terms of UID? Would a
> > > uid be assigned on a local machine? On the domain (if the machine the
> > > person is logging into happens to be a part of a bigger network)? Does
> > > the OpenID spec have provisions for account authorization and
> > > information? There are still some UNIX-y things needed by current
> > > distributions that we have to find solutions for.
> > 
> > We have the problem of UIDs in the enterprise space right now even
> > without OpenID in the mix.
> > 
> > The problem being Posix and Linux/UNIX really are not "network-aware"
> > when it comes to identity.
> 
> This seems like an excellent occasion to point to the freeIPA project
> (wwww.freeeipa.org), which we will hopefully start to appear in Fedora
> fairly soon.

Yes actually I will try to pursue my plan as part of FreeIPA as well.
Right now freeipa still uses the classic approach (all uids need to be
consolidated), because the other plan needs kernel and userland support,
and anyway other Unices will need it for long.

But if you are interested in Identity management problems, be sure to
follow that project as I am willing to tackle one of them at a a time
there.

/Simo not afraid of trying to fight with the Mills.



From triad at df.lth.se  Thu Nov  8 18:59:46 2007
From: triad at df.lth.se (Linus Walleij)
Date: Thu, 8 Nov 2007 19:59:46 +0100 (CET)
Subject: Removal of pam_console questions
In-Reply-To: <20071107214242.GA6190@nostromo.devel.redhat.com>
References: <Pine.GSO.4.60.0711061218040.3358@igloo.df.lth.se>
	<20071107165939.GA21013@nostromo.devel.redhat.com>
	<Pine.GSO.4.60.0711071805160.1084@igloo.df.lth.se>
	<20071107214242.GA6190@nostromo.devel.redhat.com>
Message-ID: <Pine.GSO.4.60.0711081958420.685@igloo.df.lth.se>

On Wed, 7 Nov 2007, Bill Nottingham wrote:

> So, the best place to look is:
> /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi

Thanks Bill, exactly what I needed, plus the extra info, perfect. I'll get 
around to removing the pam_console stuff now...

Linus



From jkeating at redhat.com  Thu Nov  8 19:03:10 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 8 Nov 2007 14:03:10 -0500
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <20071108185211.GA3888@redhat.com>
References: <20071108134119.4653a86b@redhat.com>
	<20071108185211.GA3888@redhat.com>
Message-ID: <20071108140310.7f71028f@redhat.com>

On Thu, 8 Nov 2007 13:52:11 -0500
Dave Jones <davej at redhat.com> wrote:

> People get bitten by this every release.  And no doubt, people
> will this release too, because not all useres will read your
> announcement.
> 
> Could we do a final update to fedora-release just before we
> do the final compose to do the right thing to the repo files?
> 
> I'm sure I was talking with someone about this not too long ago,
> and it was a "solved" problem, but from your message, it seems
> that isn't the case.

The fedora-release currently in rawhide only has fedora and updates
enabled.  However if you at any point had modified your development
repo file, then you would have a .rpmnew file sitting there with
development disabled, but your modified one would still be enabled.  We
don't want to stomp on local configuration which is why .rpmnew would
get created.  This is why I stated that people should /ensure/, rather
than just trusting that the package upgrade did the right thing.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/2f99e795/attachment.sig>

From sundaram at fedoraproject.org  Thu Nov  8 19:02:36 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 09 Nov 2007 00:32:36 +0530
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <20071108185211.GA3888@redhat.com>
References: <20071108134119.4653a86b@redhat.com>
	<20071108185211.GA3888@redhat.com>
Message-ID: <47335D4C.6040102@fedoraproject.org>

Dave Jones wrote:
> On Thu, Nov 08, 2007 at 01:41:19PM -0500, Jesse Keating wrote:
> 
>  > For those of you that were early adopters of Fedora 8 and joined the
>  > Rawhide bandwagon, but want to get off at the Fedora 8 stop, I suggest
>  > that you ensure your 'development' yum repo is disabled.  For those of
>  > you that wish to continue to enjoy Rawhide, I suggest you ensure that
>  > your 'fedora', and any updates repos are disabled, and make sure that
>  > your development repo remains enabled.
> 
> People get bitten by this every release.  And no doubt, people
> will this release too, because not all useres will read your
> announcement.
> 
> Could we do a final update to fedora-release just before we
> do the final compose to do the right thing to the repo files?
> 
> I'm sure I was talking with someone about this not too long ago,
> and it was a "solved" problem, but from your message, it seems
> that isn't the case.

It is already the case. I guess this is just a reminder for those 
twiddling with their repository files.

Rahul



From ssorce at redhat.com  Thu Nov  8 19:08:35 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 14:08:35 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194545984.9673.458.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<1194532417.6559.21.camel@localhost.localdomain>
	<slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
	<1194545984.9673.458.camel@mccallum.corsepiu.local>
Message-ID: <1194548915.3271.102.camel@localhost.localdomain>

On Thu, 2007-11-08 at 19:19 +0100, Ralf Corsepius wrote:
> On Thu, 2007-11-08 at 18:19 +0100, Matej Cepl wrote:
> > On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
> > >> > > any plans to replace it by git, mercurial, svn or other 
> > >> > > more modern version control system?
> 
> > >> - CVS server outage :)
> > >
> > > Other services never have outages?
> > 
> > They don't -- have you ever heard about distributed VC? If the 
> > repository I am working against has outage, then I don't care.
> And how do you pull/push if the remote server is down?

You commit locally and keep working.
When the repo is up you push down everything in one go.

If you need patches from others they can share their repo or send you
mails that keep the whole meta-data.

DVCS really have *no* problems with outages. Only centralized VCS has.

Simo.



From ssorce at redhat.com  Thu Nov  8 19:11:20 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 14:11:20 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194546890.9673.469.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711071938.48209.opensource@till.name>
	<20071107195201.GA4263@serv.smile.org.ua>
	<200711081840.27702.opensource@till.name>
	<1194546890.9673.469.camel@mccallum.corsepiu.local>
Message-ID: <1194549080.3271.104.camel@localhost.localdomain>

On Thu, 2007-11-08 at 19:34 +0100, Ralf Corsepius wrote:
> On Thu, 2007-11-08 at 18:40 +0100, Till Maas wrote:
> > On Mi November 7 2007, Andy Shevchenko wrote:
> > 
> > > Modern vcs requires additional space for this operation.
> > 
> > When I try to emulate this with CVS, I also need the additional space.
> Right _you_ would have to have _one_ modified source tree in parallel if
> _you_ would want to do this. These so called modern VCS force you to do
> so. Also, with svn etc. you have the whole history bloating and
> polluting your checkout (Now try recursively grepping a deep source-tree
> with a long history. Try gcc's (svn) source-tree to experience what I am
> referring to).

Man you can't use --exclude= ?
Or use better tools like cscope/ctags/whatever ?

Simo.



From jdieter at gmail.com  Thu Nov  8 19:14:59 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 08 Nov 2007 21:14:59 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <47334F0F.5030106@fedoraproject.org>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<47334F0F.5030106@fedoraproject.org>
Message-ID: <1194549299.10285.5.camel@jndwidescreen.lesbg.loc>


On Thu, 2007-11-08 at 23:31 +0530, Rahul Sundaram wrote:
> Jonathan Dieter wrote:
> > Within the next five or six hours, there should be deltarpms available
> > for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
> > when they become available.
> 
> Great. Is this planned to be default for Fedora 9?
> 

I really hope so.  The real issue is that the build system needs to be
set up to generate the deltarpms and I don't know koji/bodhi.

The idea is that when the buildsystem is able to generate deltarpms
(hopefully very soon), we'll start making the official repositories
presto-enabled.  *If* we don't have any problems, we *may* then make it
the default for Fedora 9.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/700172e1/attachment.sig>

From lesmikesell at gmail.com  Thu Nov  8 19:21:31 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 08 Nov 2007 13:21:31 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<20071108100819.GA12141@evileye.englab.brq.redhat.com>	<1194532417.6559.21.camel@localhost.localdomain>
	<slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
Message-ID: <473361BB.5050002@gmail.com>

Matej Cepl wrote:
> On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
>>>>> any plans to replace it by git, mercurial, svn or other 
>>>>> more modern version control system?
>> We don't use it as a true version conrtol system anyways.
> 
> Could you elaborate on this answer a little bit, please?
> 
>>> - CVS server outage :)
>> Other services never have outages?
> 
> They don't -- have you ever heard about distributed VC? If the 
> repository I am working against has outage, then I don't care.

But what's the point?  If you make a change that can't be committed to 
the central repository, why should anyone else care?  And if others are 
  making conflicting changes and you can't update from them, you'll just 
keep wasting your time.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mmcgrath at redhat.com  Thu Nov  8 19:21:47 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 08 Nov 2007 13:21:47 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
Message-ID: <473361CB.1040107@redhat.com>

Adam Tkac wrote:
> Hi all,
>
> CVS has already passed over best years. I'm wonder why modern
> project like Fedora still has sources in this ancient system. Are here
> any plans to replace it by git, mercurial, svn or other more modern
> version control system?
>   

We've tried this in the past a couple of times.  The problem is we need 
someone that has these qualities:

1) A vision from developer to build system on how this is supposed to work.
2) Time to write up and convince others its the right way to go.
3) Time to proof of concept it and implement it
4) Time to work with the infrastructure team on a migration plan
5) A little bit of craziness.

I hate CVS like the next guy, but it turns out converting to something 
else is a very large commitment. 

    -Mike



From jdieter at gmail.com  Thu Nov  8 19:26:47 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Thu, 08 Nov 2007 21:26:47 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
Message-ID: <1194550007.10285.13.camel@jndwidescreen.lesbg.loc>


On Thu, 2007-11-08 at 16:04 +0000, Jonathan Underwood wrote:
> On 08/11/2007, Jonathan Dieter <jdieter at gmail.com> wrote:
> > Within the next five or six hours, there should be deltarpms available
> > for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
> > when they become available.
> 
> For x86_64 as well as i386?
> 

Sorry, but I'm afraid I've run into some problems generating the F7 ->
F8 deltarpms and they won't be ready until tomorrow morning my time (UTC
+0200).

On a better note, deltarpms for Fedora 8 updates are ready.  The good
news is that you no longer have to use "deltaurl=".  All you do is set
"baseurl=http://lesloueizeh.com/f8/i386/updates"
in /etc/yum.repos.d/fedora-updates.repo.  The bad news (at least for me)
is that it means you will be downloading both deltarpms and regular rpms
from our school's mirror and I believe our bandwidth is limited to
100GB/month.

This means I'll either need some help mirroring the deltarpms or we need
to get the official repositories to include them very soon.

I'll post again when I have the F7 -> F8 deltarpms ready.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/42fc9483/attachment.sig>

From lesmikesell at gmail.com  Thu Nov  8 19:29:38 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 08 Nov 2007 13:29:38 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711081908.19695.ville.skytta@iki.fi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<473226CE.60201@gmail.com>
	<47331F00.30708@redhat.com>
	<200711081908.19695.ville.skytta@iki.fi>
Message-ID: <473363A2.8030707@gmail.com>

Ville Skytt? wrote:
> On Thursday 08 November 2007, Christopher Aillon wrote:
>> Les Mikesell wrote:
>>> If you run cvsweb (now viewvc) on the cvs repository it is easy to
>>> cherry-pick any file/revision you want or diff between any committed
>>> versions through the browser interface.
>> Not so.  You can only view devel/
> 
> All branches can be seen below per-package subdirs at 
> http://cvs.fedora.redhat.com/viewcvs/rpms/

Thanks - is that link mentioned publicly anywhere?  It might be the 
handiest place to find the history of just about every spec file known 
to man.

The relevant point about branches here is that CVS doesn't version 
directories.  Like rcs, all the history is contained in each file 
separately, which has both good and bad side effects.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From pemboa at gmail.com  Thu Nov  8 19:33:58 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 8 Nov 2007 13:33:58 -0600
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <20071108164823.GA26392@jadzia.bu.edu>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
	<20071108164823.GA26392@jadzia.bu.edu>
Message-ID: <16de708d0711081133u50f36a86h93aa974b878f00e8@mail.gmail.com>

On Nov 8, 2007 10:48 AM, Matthew Miller <mattdm at mattdm.org> wrote:
> On Wed, Nov 07, 2007 at 09:55:08AM -0500, Kelly Miller wrote:
> > here).  First of all, is there a preferred language for development
> > like this?  I've actually done very little to no Python development
>
> Almost certainly Python.
>
> The key reason these utilties need rewriting is to separate the user
> interface (GUI, full-screen text-mode, and command-line) from the possibly
> privileged actions they need to perform.
>
> This should be done using PolicyKit -- see
> <http://fedoraproject.org/wiki/Releases/FeaturePolicyKit>.



If these utilities are going to be rewritten, please make it public, I
have a feature that I would like to see in them, and I am willing to
work on myself.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From pemboa at gmail.com  Thu Nov  8 19:34:39 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 8 Nov 2007 13:34:39 -0600
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
Message-ID: <16de708d0711081134t3e741ea1k3d34b266bad25021@mail.gmail.com>

On Nov 7, 2007 8:55 AM, Kelly Miller <lightsolphoenix at gmail.com> wrote:
> Well, now that F8 is approaching release, I wanted to bring up the
> possibility of updating the configuration utilities again.  I'd be
> willing to work on such a project (fixing the frontend problems so the
> utilities could be used without X, etc.), but I'm not entirely
> familiar with all the options covered by the utilities (for example,
> I've never used the cluster management or bootloader editor systems,
> and I'm not completely familiar with all of the configuration files
> here).  First of all, is there a preferred language for development
> like this?  I've actually done very little to no Python development
> (though I've done development in similar RAD languages like Ruby, Java
> and C# so I'm familiar with the general concepts), but I'll give it a
> shot in Python if that's preferred.  Secondly, is there a decent
> resource for covering some of the configuration files required by the
> programs?


I don't think C# is RAD.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From alan at redhat.com  Thu Nov  8 19:38:58 2007
From: alan at redhat.com (Alan Cox)
Date: Thu, 8 Nov 2007 14:38:58 -0500
Subject: openid support for f9?
In-Reply-To: <1194548034.3271.94.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<20071108180927.GA12738@devserv.devel.redhat.com>
	<1194548034.3271.94.camel@localhost.localdomain>
Message-ID: <20071108193858.GC13151@devserv.devel.redhat.com>

On Thu, Nov 08, 2007 at 01:53:54PM -0500, Simo Sorce wrote:
> Alan, I think we live on diffrent planets then :-)

Quite possibly. I make mine one, two, third one out unless we missed one.

> I deal with ID mappings problems since ever in the Samba world, and I
> rewrote the idmap subsystem twice, please trust me when I say the
> problem is *far* from being solved, for anything but ideal cases which
> do not exist on real networks.

Its a solved problem - I'm not saying its solved in RHEL or for our customerbase
thats a different thing.

> > This doesn't work anyway - a UUID is intended to avoid collisions, it is
> > not intended to be securely unique.
> 
> True, but there is almost no way to get something securely unique, and
> anyway that's absolutely not the point. What we need is exactly to
> avoiding collisions, not securely unique IDs.

You cannot avoid collisions using ids that are defacto publically visible.
I will choose to clash with your ID because I'm bad. 

> > Short of having a DNS like global "phonebook" for UIDs the solvable problem
> > is "can I have access to xyz"
> 
> Exactly, but yet you need to represent identity in term of UIDs and GIDs
> in the POSIX world, hence why I am slowly advocating for *local* mapping
> tables. Network mapping tables simply do not work.

They work very well when the authetication domain and the user domain and
the set of systems overlap - thats actually not that uncomoon. When they don't
you need mapping at that level - be it group or system.

> with a way to store mappings on removable drivers when needed. Think
> agaion of a USB pen drive formatted ext2, you need at least a file where
> you map the UID used on the disk to the identity used (be it an email or
> a kerberos principal or whatever you can think of to represent an
> identity) and for groups too. 

That makes a lot of sense for deciding who is who, its absolutely useless
for authentication purposes. Having a key which says "please sir I'm root"
doesn't solve the trust problem on a network.

How you do the uid mapping is I think not too important. You would want
to load a table of [disk uid][local uid] into a stacking fs or similar and
that can be done by parsing the fs in user space (with a default 'root only'
rights set until its parsed and loaded). Its not quite that simple because
you need to add new user mappings and know what is free. Thats not a trivial
excercise on GFS2 I suspect.

Truth be told however what most people want for removable storage is blanket
ownership by themself.

Alan




From frank-buettner at gmx.net  Thu Nov  8 19:45:51 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Thu, 08 Nov 2007 20:45:51 +0100
Subject: Update form F7 to F8 freeze at 26%
Message-ID: <4733676F.2000209@gmx.net>

Hello,

I have try to update an F7 installation to F8, but at dependency check
it freeze all ways at 26%.
It happens in the text and gui mode.
anaconda use 100% CPU and 97% of all memory.

Idear how get out, what goes wrong?

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/ebad947d/attachment.bin>

From jwboyer at gmail.com  Thu Nov  8 19:50:39 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 8 Nov 2007 13:50:39 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194548915.3271.102.camel@localhost.localdomain>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<1194532417.6559.21.camel@localhost.localdomain>
	<slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
	<1194545984.9673.458.camel@mccallum.corsepiu.local>
	<1194548915.3271.102.camel@localhost.localdomain>
Message-ID: <20071108135039.2a37fbd9@zod.rchland.ibm.com>

On Thu, 08 Nov 2007 14:08:35 -0500
Simo Sorce <ssorce at redhat.com> wrote:

> On Thu, 2007-11-08 at 19:19 +0100, Ralf Corsepius wrote:
> > On Thu, 2007-11-08 at 18:19 +0100, Matej Cepl wrote:
> > > On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
> > > >> > > any plans to replace it by git, mercurial, svn or other 
> > > >> > > more modern version control system?
> > 
> > > >> - CVS server outage :)
> > > >
> > > > Other services never have outages?
> > > 
> > > They don't -- have you ever heard about distributed VC? If the 
> > > repository I am working against has outage, then I don't care.
> > And how do you pull/push if the remote server is down?
> 
> You commit locally and keep working.
> When the repo is up you push down everything in one go.
> 
> If you need patches from others they can share their repo or send you
> mails that keep the whole meta-data.
> 
> DVCS really have *no* problems with outages. Only centralized VCS has.

It does.  Our buildsys requires a single repository to pull (or
checkout) from to do builds.  So until your changes are present in
there, you still suffer from the "outage" problem if you want to
actually build packages for others to consume in the official repos.

josh



From dwalsh at redhat.com  Thu Nov  8 20:00:10 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Thu, 08 Nov 2007 15:00:10 -0500
Subject: NFS Update and SELinux
In-Reply-To: <1194537943.25638.15.camel@localhost6.localdomain6>
References: <1193856288.12145.9.camel@localhost6.localdomain6>	<472A13D9.4010105@redhat.com>	<1193941654.3848.5.camel@localhost6.localdomain6>	<473087ED.7020101@redhat.com>	<1194371113.4985.3.camel@localhost6.localdomain6>	<4731F358.7040405@redhat.com>
	<1194537943.25638.15.camel@localhost6.localdomain6>
Message-ID: <47336ACA.1090406@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richi Plana wrote:
> On Wed, 2007-11-07 at 12:18 -0500, Daniel J Walsh wrote:
>> Richi Plana wrote:
>>> I _WAS_ thinking of asking, however, what sort of actions can be placed
>>> in the %post section of packages which need immediate action? I know
>>> some services restart themselves after package updates (but some don't.
>>> I wonder if this should be made policy). In the case of selinux, would a
>>> kernel module reload solve the mislabeled device files? A restart? (I
>>> did notice that at one point in time, I got an advisory to restart the
>>> computer after a set of updates. I can't remember where or what it was
>>> now)
>>> --
>>>
>>> Richi Plana
>>>
>> selinux-policy attempts to fix labeling as it updates.  Most of the time
>> you should/would not need to do anything.  But occasionally restarting
>> domains/programs is necessary.
> 
> Being security-related, shouldn't actions needed to ensure effectivity
> be encouraged? If not a system restart, what about that "domain
> restarting" that you mentioned? How is that performed? Would it cover
> all cases?
> --
> 
> Richi Plana
> 
If a policy update added confinement to an application for example, a
service CONFINEDAPP restart would be required to get the app to run with
the new context.  We do not intend to do this, since restarting the app
might result in loss of data or some other evil thing.  Updating gcc or
glibc has similar problems.  So this is not exclusive to SELinux.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHM2rKrlYvE4MpobMRAsW/AJ99WY96jAlxn0vV+nDgFloQHoYOHwCaA42q
FMKjpHMcHkAZh/yuBX80r0w=
=V+OM
-----END PGP SIGNATURE-----



From darrellpf at gmail.com  Thu Nov  8 20:05:05 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Thu, 8 Nov 2007 12:05:05 -0800
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <f6e5806f0711081205q81d5c28v1559d6eaebf82b7d@mail.gmail.com>

On Nov 8, 2007 11:45 AM, Frank B?ttner <frank-buettner at gmx.net> wrote:
> Hello,
>
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
>
> Idear how get out, what goes wrong?
>

For large upgrades, I've had more success using yum and updating selectively.

For instance, I might update Openoffice first (because it is large),
then update xorg packages (because there are lots of them and they're
not typically dependent on anything).  After some of the obvious
groups are out of the way I'll start updating all the a*, b*, c*
packages. Often I will leave gnome for the last because it can bring
in a lot of dependencies.

darrell



From lkundrak at redhat.com  Thu Nov  8 20:05:53 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 08 Nov 2007 21:05:53 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<1194532417.6559.21.camel@localhost.localdomain>
	<slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>
Message-ID: <1194552353.6559.32.camel@localhost.localdomain>


On Thu, 2007-11-08 at 18:19 +0100, Matej Cepl wrote:
> On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
> >> > > any plans to replace it by git, mercurial, svn or other 
> >> > > more modern version control system?
> >
> > We don't use it as a true version conrtol system anyways.
> 
> Could you elaborate on this answer a little bit, please?

No, I am tired. Read the following line carefully and think a bit about
what should it do in a version control system:

$ cvs diff -rkoules-1_4-2_fc8 -rkoules-1_4-1_fc7 koules.spec 

> >> - CVS server outage :)
> >
> > Other services never have outages?
> 
> They don't -- have you ever heard about distributed VC? If the 
> repository I am working against has outage, then I don't care.

I was asking about other services, not version control systems. Do you
cache your favourite webs in case they have outage? Utilizing remote
services is just the way how the Internet works.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From ville.skytta at iki.fi  Thu Nov  8 20:09:12 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 8 Nov 2007 22:09:12 +0200
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <473363A2.8030707@gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711081908.19695.ville.skytta@iki.fi>
	<473363A2.8030707@gmail.com>
Message-ID: <200711082209.12707.ville.skytta@iki.fi>

On Thursday 08 November 2007, Les Mikesell wrote:
> Ville Skytt? wrote:
>
> > All branches can be seen below per-package subdirs at
> > http://cvs.fedora.redhat.com/viewcvs/rpms/
>
> Thanks - is that link mentioned publicly anywhere?

I don't know, but there's a prominent "Web interface for the CVS" link at 
https://fedoraproject.org/wiki/UsingCvs (to which 
http://cvs.fedora.redhat.com/ redirects to), and that link points to 
http://cvs.fedoraproject.org/viewcvs/ and from there I think it's pretty 
obvious.



From ssorce at redhat.com  Thu Nov  8 20:41:56 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 15:41:56 -0500
Subject: openid support for f9?
In-Reply-To: <20071108193858.GC13151@devserv.devel.redhat.com>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<20071108180927.GA12738@devserv.devel.redhat.com>
	<1194548034.3271.94.camel@localhost.localdomain>
	<20071108193858.GC13151@devserv.devel.redhat.com>
Message-ID: <1194554516.3271.131.camel@localhost.localdomain>

On Thu, 2007-11-08 at 14:38 -0500, Alan Cox wrote:

> Its a solved problem - I'm not saying its solved in RHEL or for our customerbase
> thats a different thing.

Ok put this way I can agree, it's vague enough I can attach my meaning
of 'solved' :-)

> > > This doesn't work anyway - a UUID is intended to avoid collisions, it is
> > > not intended to be securely unique.
> > 
> > True, but there is almost no way to get something securely unique, and
> > anyway that's absolutely not the point. What we need is exactly to
> > avoiding collisions, not securely unique IDs.
> 
> You cannot avoid collisions using ids that are defacto publically visible.
> I will choose to clash with your ID because I'm bad. 

Ok I think we are mixing things here, it seem we are mixing the need to
uniquely represent identities with the need to authenticate them.
Please let's not mix the two, they are connected but separate problems.

> > > Short of having a DNS like global "phonebook" for UIDs the solvable problem
> > > is "can I have access to xyz"
> > 
> > Exactly, but yet you need to represent identity in term of UIDs and GIDs
> > in the POSIX world, hence why I am slowly advocating for *local* mapping
> > tables. Network mapping tables simply do not work.
> 
> They work very well when the authetication domain and the user domain and
> the set of systems overlap - thats actually not that uncomoon. When they don't
> you need mapping at that level - be it group or system.

It's not about it being common or uncommon, it is about the pain when
you have to merge 2 or more domains (thin the mess in small shops when
you have >10 machines which have never been synchronized).
Right now it is a huge pain. If you make mapping the default an make
UIDs/GIDs make sense only locally, you are in a position to remove the
pain completely.

> > with a way to store mappings on removable drivers when needed. Think
> > agaion of a USB pen drive formatted ext2, you need at least a file where
> > you map the UID used on the disk to the identity used (be it an email or
> > a kerberos principal or whatever you can think of to represent an
> > identity) and for groups too. 
> 
> That makes a lot of sense for deciding who is who, its absolutely useless
> for authentication purposes. Having a key which says "please sir I'm root"
> doesn't solve the trust problem on a network.

Again I am not sure why you are mixing authentication with
authorization.
Authentication is absolutely necessary, but it is a different problem.
Once you are authenticated you need an ID to represent you. I am not
advocating the UUID to be a blanket credential by itself.

This is solved in the most modern network file systems like CIFS and
NFSv4, for others we will still suffer the "trust the whole remote
machine" problem, but that is no different from what we have today.

> How you do the uid mapping is I think not too important.

True, in fact I didn't propose a mechanism, I am trying to find out how
well or bad people can receive the message we need something like that
first.

>  You would want
> to load a table of [disk uid][local uid] into a stacking fs or similar and
> that can be done by parsing the fs in user space (with a default 'root only'
> rights set until its parsed and loaded).

Exactly!

>  Its not quite that simple because
> you need to add new user mappings and know what is free. Thats not a trivial
> excercise on GFS2 I suspect.

Yes, it is not in some complex cases, the worst when networked apps
transmit a Posix UID/GID over the network (like NFSv2/3 does), in that
case the app need to be changed or you need to go back to use a shared
table until the app is fixed.

The nice thing is that allowing mapping at the system level does not
preclude sharing existing maps at a group/domain level.

> Truth be told however what most people want for removable storage is blanket
> ownership by themself.

Sometimes they do, sometimes they don't.
If I have a drive I connect to a multi-user system (maybe a once a week
backup drive or something) I want to keep the ownership clean.

Clearly, ownership in this case is not meant to protect data when the
disk is moved to an untrusted machine, but it is still useful inside a
trusted group.

Ideally a "portable drive file system" would allow to make "everyone" or
even a group owner of a file, a concept that, unfortunately is not
allowed by the posix semantics :-( but can be nonetheless made to work
with a mapping system probably.

Simo.



From abartlet at samba.org  Thu Nov  8 20:59:34 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Fri, 09 Nov 2007 07:59:34 +1100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <473314FE.5060008@gmail.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
	<20071108121609.GA14018@evileye.englab.brq.redhat.com>
	<1194524791.13184.82.camel@naomi>
	<8278b1b0711080436w43576f72s54c963c8675c54e@mail.gmail.com>
	<473314FE.5060008@gmail.com>
Message-ID: <1194555574.13184.106.camel@naomi>


On Thu, 2007-11-08 at 07:54 -0600, Les Mikesell wrote:
> King InuYasha wrote:
> > Well, Bazaar and Mercurial can both support semi-centralized repository
> > systems. In the Enano CMS Project, we created a public mirror of all the
> > repositories that are worked on in Nighthawk, which is the build and
> > development server of all the work in Mercurial revisions of Enano CMS.
> > While realistically Fedora cannot have such a system, the principle of
> > designating certain branches of repositories for central authorization so
> > that stuff like QA can manage it is possible with a single repository
> > setting. Heck, I think even Ubuntu does that with Bazaar. Though as far as
> > distributed VCSes go, I prefer Mercurial. Since Fedora is a Linux OS, I
> > suppose it is fine to use GIT, but I try to avoid non-cross platform VCSes.
> 
> Svk has an interesting magic ability to work with a mirrored subversion 
> project.  That lets you treat the subversion repository as centralized 
> but people who prefer to work with a local copy can run svk, tell it to 
> sync with the subversion copy, then make a local branch for their 
> changes.  When they merge the branch changes back to the mirrored 
> project, svk automagically commits them to the central subversion repo. 
>   I haven't done this myself but there are some tutorials floating 
> around on the net with the steps for this procedure.

Some members of the Samba team tried that, and it didn't end up working
too well.  Particularly as moving the commits upstream basically
amounted to a mega-patch with any authorship and commit details just
being in the log.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/84182916/attachment.sig>

From choeger at cs.tu-berlin.de  Thu Nov  8 20:59:47 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=)
Date: Thu, 08 Nov 2007 21:59:47 +0100
Subject: Monodevelop out of date
Message-ID: <473378C3.7000000@cs.tu-berlin.de>

Hi,

is actually someone packaging monodevelop? We are at v0.13.1 in the 
repos and 0.17 is out.
If help is needed to build monodevelop I would volunteer, if someone 
tells me how to.

regards



From lordmorgul at gmail.com  Thu Nov  8 21:03:52 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Thu, 08 Nov 2007 13:03:52 -0800
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <473379B8.4040400@gmail.com>

Frank B?ttner wrote:
> Hello,
> 
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
> 
> Idear how get out, what goes wrong?
> 
> Thanks.

You're going to want to remove any packages that were installed from other
sources for sure.  If you have things like Sun's java, older nvidia/ati rpms,
rpms from other distros, etc, get rid of them prior to upgrade and try that.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From david at lovesunix.net  Thu Nov  8 21:12:41 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 08 Nov 2007 22:12:41 +0100
Subject: Monodevelop out of date
In-Reply-To: <473378C3.7000000@cs.tu-berlin.de>
References: <473378C3.7000000@cs.tu-berlin.de>
Message-ID: <1194556361.2836.13.camel@dawkins>


tor, 08 11 2007 kl. 21:59 +0100, skrev Christoph H?ger:
> Hi,
> 
> is actually someone packaging monodevelop? We are at v0.13.1 in the 
> repos and 0.17 is out.
> If help is needed to build monodevelop I would volunteer, if someone 
> tells me how to.

I already have a bug for this with a tested up date (though only to beta
1 - I suspect I'll bump the build once #371741 goes away)

Regardless:
https://bugzilla.redhat.com/show_bug.cgi?id=251787
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/5ba6d666/attachment.sig>

From opensource at till.name  Thu Nov  8 21:21:56 2007
From: opensource at till.name (Till Maas)
Date: Thu, 08 Nov 2007 22:21:56 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194546890.9673.469.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711081840.27702.opensource@till.name>
	<1194546890.9673.469.camel@mccallum.corsepiu.local>
Message-ID: <200711082222.01473.opensource@till.name>

On Do November 8 2007, Ralf Corsepius wrote:
> On Thu, 2007-11-08 at 18:40 +0100, Till Maas wrote:
> > On Mi November 7 2007, Andy Shevchenko wrote:

> > > And second, I doubt in usefull status of this feature. IMHO, in
> > > practice (another words 'very often') you need to make diff between
> > > vcs' *.spec and current. You just make copy *.spec to *.spec.orig and
> > > use simple diff command.
> >
> > How can I do this when I have uncommited changes in the spec, but there
> > is a newer version in the repository?
>
> How is that a problem with CVS? With CVS you typically work on a
> checkout, so it's up to you how to handle mergers.

Where do I get the specfile that I could copy to .spec.orig to create a diff 
in this case? E.g. following the described procedure:

cvs commit && cp -a *.spec *.spec.orig
vim *.spec
cvs up *.spec
[now changes from the repository are merged]

How can I now do a diff that shows the changes between my working copy and the 
contents of the repository?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/0b5df477/attachment.sig>

From markg85 at gmail.com  Thu Nov  8 21:22:12 2007
From: markg85 at gmail.com (Mark)
Date: Thu, 8 Nov 2007 22:22:12 +0100
Subject: Fedora 9 Feature suggestion - The start menu and caching
In-Reply-To: <slrnfj6hmq.hsl.mcepl@hubmaier.ceplovi.cz>
References: <6e24a8e80711070723p55ca6500y2666039149d78907@mail.gmail.com>
	<20071107212000.GA2558@free.fr>
	<slrnfj4cir.4fr.mcepl@hubmaier.ceplovi.cz>
	<64b14b300711080555n5b62b5a2pacca35e6bc31d816@mail.gmail.com>
	<slrnfj6hmq.hsl.mcepl@hubmaier.ceplovi.cz>
Message-ID: <6e24a8e80711081322x50a84cdel9ffd820ae05cc0ca@mail.gmail.com>

Lets not make this a thread about pidgin replacements oke?
keep it in the caching subject please.



From lesmikesell at gmail.com  Thu Nov  8 21:24:47 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 08 Nov 2007 15:24:47 -0600
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194555574.13184.106.camel@naomi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<20071108100819.GA12141@evileye.englab.brq.redhat.com>	<20071108070626.7764f8e9@redhat.com>	<20071108121609.GA14018@evileye.englab.brq.redhat.com>	<1194524791.13184.82.camel@naomi>	<8278b1b0711080436w43576f72s54c963c8675c54e@mail.gmail.com>	<473314FE.5060008@gmail.com>
	<1194555574.13184.106.camel@naomi>
Message-ID: <47337E9F.1010008@gmail.com>

Andrew Bartlett wrote:
> On Thu, 2007-11-08 at 07:54 -0600, Les Mikesell wrote:
>> King InuYasha wrote:
>>> Well, Bazaar and Mercurial can both support semi-centralized repository
>>> systems. In the Enano CMS Project, we created a public mirror of all the
>>> repositories that are worked on in Nighthawk, which is the build and
>>> development server of all the work in Mercurial revisions of Enano CMS.
>>> While realistically Fedora cannot have such a system, the principle of
>>> designating certain branches of repositories for central authorization so
>>> that stuff like QA can manage it is possible with a single repository
>>> setting. Heck, I think even Ubuntu does that with Bazaar. Though as far as
>>> distributed VCSes go, I prefer Mercurial. Since Fedora is a Linux OS, I
>>> suppose it is fine to use GIT, but I try to avoid non-cross platform VCSes.
>> Svk has an interesting magic ability to work with a mirrored subversion 
>> project.  That lets you treat the subversion repository as centralized 
>> but people who prefer to work with a local copy can run svk, tell it to 
>> sync with the subversion copy, then make a local branch for their 
>> changes.  When they merge the branch changes back to the mirrored 
>> project, svk automagically commits them to the central subversion repo. 
>>   I haven't done this myself but there are some tutorials floating 
>> around on the net with the steps for this procedure.
> 
> Some members of the Samba team tried that, and it didn't end up working
> too well.  Particularly as moving the commits upstream basically
> amounted to a mega-patch with any authorship and commit details just
> being in the log.

But isn't that a matter of choice?  That is, you should be able to merge 
your changes to the mirrored svn project at the same frequency you you 
be doing commits without svk involved - if you want to or the project 
management says you have to.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From lightsolphoenix at gmail.com  Thu Nov  8 21:32:23 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Thu, 08 Nov 2007 16:32:23 -0500
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <16de708d0711081133u50f36a86h93aa974b878f00e8@mail.gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>	<20071108164823.GA26392@jadzia.bu.edu>
	<16de708d0711081133u50f36a86h93aa974b878f00e8@mail.gmail.com>
Message-ID: <47338067.3070709@gmail.com>

Arthur Pemberton wrote:
> If these utilities are going to be rewritten, please make it public, I
> have a feature that I would like to see in them, and I am willing to
> work on myself.
>   
Obviously.  I can't think of any other decent way of doing this.  I'm 
just not sure where to host it at.



From choeger at cs.tu-berlin.de  Thu Nov  8 21:37:28 2007
From: choeger at cs.tu-berlin.de (=?UTF-8?B?Q2hyaXN0b3BoIEjDtmdlcg==?=)
Date: Thu, 08 Nov 2007 22:37:28 +0100
Subject: Monodevelop out of date
In-Reply-To: <1194556361.2836.13.camel@dawkins>
References: <473378C3.7000000@cs.tu-berlin.de>
	<1194556361.2836.13.camel@dawkins>
Message-ID: <47338198.5070807@cs.tu-berlin.de>

Hi,

I could not build your 0.16 package. It fails with

./src/Mono.Addins.Gui/Mono.Addins.Gui/AddinInstallerDialog.cs(40,35): 
error CS0246: The type or namespace name `PackageCollection' could not 
be found. Are you missing a using directive or an assembly reference?
./src/Mono.Addins.Gui/Mono.Addins.Gui/AddinManagerDialog.cs(39,30): 
error CS0246: The type or namespace name `SetupService' could not be 
found. Are you missing a using directive or an assembly reference?

although all buildrequirements are fulfilled.

David Nielsen schrieb:
> tor, 08 11 2007 kl. 21:59 +0100, skrev Christoph H?ger:
>> Hi,
>>
>> is actually someone packaging monodevelop? We are at v0.13.1 in the 
>> repos and 0.17 is out.
>> If help is needed to build monodevelop I would volunteer, if someone 
>> tells me how to.
> 
> I already have a bug for this with a tested up date (though only to beta
> 1 - I suspect I'll bump the build once #371741 goes away)
> 
> Regardless:
> https://bugzilla.redhat.com/show_bug.cgi?id=251787
> 



From skvidal at fedoraproject.org  Thu Nov  8 21:37:10 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 08 Nov 2007 16:37:10 -0500
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <47338067.3070709@gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
	<20071108164823.GA26392@jadzia.bu.edu>
	<16de708d0711081133u50f36a86h93aa974b878f00e8@mail.gmail.com>
	<47338067.3070709@gmail.com>
Message-ID: <1194557830.15170.42.camel@cutter>


On Thu, 2007-11-08 at 16:32 -0500, Kelly Miller wrote:
> Arthur Pemberton wrote:
> > If these utilities are going to be rewritten, please make it public, I
> > have a feature that I would like to see in them, and I am willing to
> > work on myself.
> >   
> Obviously.  I can't think of any other decent way of doing this.  I'm 
> just not sure where to host it at.

hosted.fedoraproject.org !!!


of course!

-sv




From myfedora at richip.dhs.org  Thu Nov  8 21:45:48 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 08 Nov 2007 14:45:48 -0700
Subject: openid support for f9?
In-Reply-To: <1194544452.3271.54.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
Message-ID: <1194558348.29460.20.camel@localhost6.localdomain6>

On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
> On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> > Certainly an interesting concept, but that would pull us way too far
> > into the Internet space (as opposed to local or even private domain
> > space). How would an openid user map to Linux in terms of UID? Would a
> > uid be assigned on a local machine? On the domain (if the machine the
> > person is logging into happens to be a part of a bigger network)? Does
> > the OpenID spec have provisions for account authorization and
> > information? There are still some UNIX-y things needed by current
> > distributions that we have to find solutions for.
> 

> 1. move to 128bit UID/GIDs that are really UUIDs
>   problem is, most apps wont work, need changes in the kernel, in a
> word:
> 	unachievable

Not to worry, gentlefolk. I've already had a word with the OpenID
Foundation and they've agreed that it is a problem that they'll address
with OpenID 2.1. In fact, they've already conferred with IANA and now
they're coming up with a scheme for allowing the distributed
registration and authentication of OpenID to be given, for each account
created, a 128-bit unique IP address that's portable (you can take it
with you to a different OpenID Provider). A private space is said to be
reserved for use by system resources and daemons.

Microsoft has uncharacteristically agreed that the convenience this
brings outweighs the usual technical arguments (read: laziness). This
was better than their original idea: having UTF-16 encoded OpenID
strings as process UIDs w/ BOM. They have agreed to ship a 128-bit UID
capable kernel in their next release of Windows entitled "Leghorn".

NEC has decided to get on the bandwagon, predicting that banks will soon
switch to OpenID, by coming out with ATMs that allow processes to run
using this universal ID system. The new ATMs will have Gnome as its
graphical environment and users automatically get their preferred
settings including background and screensaver if available from the
Internet.

Oh, and yes, flying pig.

Seriously, though, thanks for the various insights. I'll look into the
various means by which arbitrary accounts are mapped into local space.
--

Richi Plana



From pemboa at gmail.com  Thu Nov  8 21:50:05 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 8 Nov 2007 15:50:05 -0600
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <47338067.3070709@gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
	<20071108164823.GA26392@jadzia.bu.edu>
	<16de708d0711081133u50f36a86h93aa974b878f00e8@mail.gmail.com>
	<47338067.3070709@gmail.com>
Message-ID: <16de708d0711081350m46b11c30w934d49bb10f58d9a@mail.gmail.com>

On Nov 8, 2007 3:32 PM, Kelly Miller <lightsolphoenix at gmail.com> wrote:
> Arthur Pemberton wrote:
> > If these utilities are going to be rewritten, please make it public, I
> > have a feature that I would like to see in them, and I am willing to
> > work on myself.
> >


> Obviously.  I can't think of any other decent way of doing this.  I'm
> just not sure where to host it at.


I meant please make the  _decision_ to do so (rewrite) public. And
also, please hold a few RFC sessions to discuss things before anyone
goes off coding on a tangent.




-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From david at lovesunix.net  Thu Nov  8 21:52:04 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 08 Nov 2007 22:52:04 +0100
Subject: Monodevelop out of date
In-Reply-To: <47338198.5070807@cs.tu-berlin.de>
References: <473378C3.7000000@cs.tu-berlin.de>
	<1194556361.2836.13.camel@dawkins> <47338198.5070807@cs.tu-berlin.de>
Message-ID: <1194558724.2836.17.camel@dawkins>


tor, 08 11 2007 kl. 22:37 +0100, skrev Christoph H?ger:
> Hi,
> 
> I could not build your 0.16 package. It fails with
> 
> ./src/Mono.Addins.Gui/Mono.Addins.Gui/AddinInstallerDialog.cs(40,35): 
> error CS0246: The type or namespace name `PackageCollection' could not 
> be found. Are you missing a using directive or an assembly reference?
> ./src/Mono.Addins.Gui/Mono.Addins.Gui/AddinManagerDialog.cs(39,30): 
> error CS0246: The type or namespace name `SetupService' could not be 
> found. Are you missing a using directive or an assembly reference?
> 
> although all buildrequirements are fulfilled.

hrmm that did not used to happen.. I promise once gmcs gets unfucked on
x86_64 I'll get right back to my Fedora duties and I'll have a look at
that.

Pain makes the world feel real.. bring it!

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/83efcbe3/attachment.sig>

From ssorce at redhat.com  Thu Nov  8 21:54:58 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 08 Nov 2007 16:54:58 -0500
Subject: openid support for f9?
In-Reply-To: <1194554516.3271.131.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<20071108180927.GA12738@devserv.devel.redhat.com>
	<1194548034.3271.94.camel@localhost.localdomain>
	<20071108193858.GC13151@devserv.devel.redhat.com>
	<1194554516.3271.131.camel@localhost.localdomain>
Message-ID: <1194558898.3271.134.camel@localhost.localdomain>

On Thu, 2007-11-08 at 15:41 -0500, Simo Sorce wrote:
> Authentication is absolutely necessary, but it is a different problem.
> Once you are authenticated you need an ID to represent you. I am not
> advocating the UUID to be a blanket credential by itself.

Replying myself just to be clear, when I say UUID I do not mean the RFC
definition of it, just the english one: Unique User IDentifier.

It can be anything, even an email address for what I care.
Any string that can be unique will do, it only needs to be abstract as
it should be made possible to represent anything as an Identity: A user,
a group, a machine, a service, a process, an abstract concept like
"Authenticated user", or "everyone" too in theory.

Simo.



From tonynelson at georgeanelson.com  Thu Nov  8 22:07:47 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Thu, 8 Nov 2007 17:07:47 -0500
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194550007.10285.13.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
	<1194550007.10285.13.camel@jndwidescreen.lesbg.loc>
Message-ID: <p04330101c35935040240@[192.168.123.162]>

At 9:26 PM +0200 11/8/07, Jonathan Dieter wrote:
 ...
>On a better note, deltarpms for Fedora 8 updates are ready.  The good
>news is that you no longer have to use "deltaurl=".  All you do is set
>"baseurl=http://lesloueizeh.com/f8/i386/updates"
>in /etc/yum.repos.d/fedora-updates.repo.  The bad news (at least for me)
>is that it means you will be downloading both deltarpms and regular rpms
>from our school's mirror and I believe our bandwidth is limited to
>100GB/month.

100 GiB is not much.  Will "deltaurl=" still work as before, with non-delta
updates coming from the baseurl or mirrorlist?
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From wtogami at redhat.com  Thu Nov  8 22:31:30 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 08 Nov 2007 17:31:30 -0500
Subject: Smoothening SELinux Devel During F9 Cycle
Message-ID: <47338E42.1020009@redhat.com>

I just spoke at length with dwalsh about ways we can smoothen 
testing/development of SELinux during the F9 cycle.  Here are ideas that 
we came up with.

NOTE: I was wrong in believing that new things were confined late in the 
F8 cycle.  Dan said new things were confined even before Test1, just 
nobody noticed until late.  He said new things actually aren't confined 
very often.  He did however take responsibility for the -42 mistake, 
which caused great distress during the past freeze.

These two rules should help to smoothen this out for the next cycle.

RULE #1:
=======
When new confines happen (or anything causing the default rules to be 
more restrictive), Dan will write up an e-mail summary describing the 
new restrictions and notify fedora-devel-announce.  This is to set 
expectations and make it easier for people to test for breakage and 
submit reports to fine tune the selinux-policy.  If we reach the final 
freeze and a confined application is still broken, we can consider 
unconfining it.

RULE #2:
=======
During the freeze period when rel-eng reviews and allows/denies changes, 
Dan will write more explicit %changelog entries and poke rel-eng@ when 
he wants a build to be included.  The %changelog entries should make it 
easier to test the changes and to make a determination whether we want 
to allow it in the release.

Grow Awareness
==============
Additionally, we need to do more training/blog announcements/etc both to 
Red Hat engineers and Fedora developers to not be so afraid of SELinux. 
  I know that I personally became a lot more comfortable with running 
with enforcing mode only after he sat down and showed me how easy it is 
to use audit2allow -M.  We need to do more promotion of these VERY BASIC 
SKILLS and how to file a proper AVC bug report.

All developers need to be comfortable about running with enforcing mode, 
to help to fix the SELinux rules rather than live in denial.

(Lame pun?)

Warren Togami
wtogami at redhat.com



From kzak at redhat.com  Thu Nov  8 23:25:00 2007
From: kzak at redhat.com (Karel Zak)
Date: Fri, 9 Nov 2007 00:25:00 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108100819.GA12141@evileye.englab.brq.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
Message-ID: <20071108232500.GZ2871@petra.dvoda.cz>

On Thu, Nov 08, 2007 at 11:08:19AM +0100, Adam Tkac wrote:
> On Wed, Nov 07, 2007 at 11:41:58AM -0600, Josh Boyer wrote:
> > On Wed, 7 Nov 2007 15:12:45 +0100
> > Adam Tkac <atkac at redhat.com> wrote:
> > 
> > Replacing a VCS for the fun of it is pretty pointless.  Can you
> > elaborate on a workflow you would like to see that CVS is not suited
> > to?  Right now, CVS works fine for what we do, which is mostly editing
> > spec files.

 Nonsense.

 My work is searching and fixing bugs, rebasing, reviewing, testing
 and backporting patches. The spec files are decoration around this
 work... Sorry, but editing spec files is 0.001% of my work on
 Fedora/RHEL.

> > I am by no means a proponent of CVS.  I think it sucks.  But we have no
> > _usecase_ for a different VCS at the moment.
> > 
> 
> It's not replacement for fun. Yes, CVS works and I believe it will
> work to end of universe. But question is if We have something better
> than CVS. And We have. There're some common problems (yes, CVS and
> SVN suffer :) )

 Few notes:

 * many people around Fedora are still not well educated about new
   content tracking tools. So we are not ready for the change.

 * many people still think about VCS as about a patches/source code
   archive -- that's very wrong. A good content tracker is a
   __development tool__. For example with GIT you can do non-linear
   development, rebasing, prototyping, bug bsearch, easily
   send/receive patches by mail, generate customized changelogs,
   scripting, off-line work, ...

 * __unfortunately__, we don't maintain source code in our VCS! We use
   it for *.patch files + commit messages. It means you can't use all
   modern features -- just because GIT, Hg, ... are designed for work
   with source code (unlike Quilt, StGIT).


    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From pmr at pajato.com  Thu Nov  8 23:07:09 2007
From: pmr at pajato.com (Paul Michael Reilly)
Date: Thu, 08 Nov 2007 18:07:09 -0500
Subject: (It pains me to say) KDE and broken logout
Message-ID: <4733969D.9080103@pajato.com>

First let it be known that I read every last character of the original 
dreadful thread as a result of logout not working for me using the RC3 
F8 bits (the live Fedora and KDE x86_64 spins).  And I've confirmed that 
my issue is definitely not GDM vs KDM.

The behavior I see after installing the KDE spin is that logout works 
perfectly after I login for the first time.  After the second and 
subsequent logins I  get empty air (nothing happens) when I click on the 
Logout menu item.

I'll try posting a bug report (again) after traffic on redhat.com 
subsides.  Meanwhile, I've switched back to F7 since either no KDE or no 
SUSPEND are both non-starters.  But I do intend to dust off another 
laptop/desktop to install Rawhide and gather more information on the 
problem.  To that end I'm open to suggestions for troubleshooting the issue.

-pmr



From seandarcy2 at gmail.com  Fri Nov  9 01:32:07 2007
From: seandarcy2 at gmail.com (seandarcy)
Date: Thu, 08 Nov 2007 20:32:07 -0500
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <20071108134119.4653a86b__2283.32277988574$1194547412$gmane$org@redhat.com>
References: <20071108134119.4653a86b__2283.32277988574$1194547412$gmane$org@redhat.com>
Message-ID: <fh0dao$4tt$1@ger.gmane.org>

Jesse Keating wrote:
.................
> 
> For those of you that were early adopters of Fedora 8 and joined the
> Rawhide bandwagon, but want to get off at the Fedora 8 stop, I suggest
> that you ensure your 'development' yum repo is disabled.  For those of
> you that wish to continue to enjoy Rawhide, I suggest you ensure that
> your 'fedora', and any updates repos are disabled, and make sure that
> your development repo remains enabled.

OK. Did that. Now:

yum upgrade
Loading "refresh-updatesd" plugin
Could not retrieve mirrorlist 
http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=x86_64 
error was
[Errno 14] HTTP Error 404: Not Found

rpm -qif fedora-updates.repo
Name        : fedora-release               Relocations: (not relocatable)
Version     : 8                                 Vendor: Fedora Project
Release     : 3                             Build Date: Mon 29 Oct 2007 
10:25:49 PM EDT

cat fedora-updates.repo
[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
enabled=1
...........

sean



From sundaram at fedoraproject.org  Fri Nov  9 01:33:30 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 09 Nov 2007 07:03:30 +0530
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <fh0dao$4tt$1@ger.gmane.org>
References: <20071108134119.4653a86b__2283.32277988574$1194547412$gmane$org@redhat.com>
	<fh0dao$4tt$1@ger.gmane.org>
Message-ID: <4733B8EA.7040105@fedoraproject.org>

seandarcy wrote:
> Jesse Keating wrote:
> .................
>>
>> For those of you that were early adopters of Fedora 8 and joined the
>> Rawhide bandwagon, but want to get off at the Fedora 8 stop, I suggest
>> that you ensure your 'development' yum repo is disabled.  For those of
>> you that wish to continue to enjoy Rawhide, I suggest you ensure that
>> your 'fedora', and any updates repos are disabled, and make sure that
>> your development repo remains enabled.
> 
> OK. Did that. Now:
> 
> yum upgrade
> Loading "refresh-updatesd" plugin
> Could not retrieve mirrorlist 
> http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=x86_64 

The mirrorlist among other things are down with the traffic from Fedora 
8 downloads.  Fedora infrastructure team is working on resolving this. 
Try again later.

Rahul



From myfedora at richip.dhs.org  Fri Nov  9 01:44:08 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 08 Nov 2007 18:44:08 -0700
Subject: Wireless WPA2 Personal Missing
Message-ID: <1194572648.2163.6.camel@localhost6.localdomain6>

So I installed Werewolf on a laptop, and now I can't get wireless
working. I've set up WPA2 Personal Security and it worked with F7 +
NetworkManager. For now, I can't see the "WPA2 Personal" option in F8. I
thought that was one of the supported systems. Bug or known issue?

The second isn't a big problem but might be something the devs might be
interested in. I've a DLink DWL-G650 PCMCIA card and I used to use
madwifi's ath_pci module with it in F7. Worked like a charm. Apparently
in F8, there's a module that keeps getting loaded called ath5k.
Unfortunately, NetworkManager isn't picking up the interface when that
gets loaded. I rmmod it and modprobe ath_pci and everything seems to
work (except I can't get WPA2 Personal to work). Bug?
--

Richi Plana



From rodd at clarkson.id.au  Fri Nov  9 01:58:47 2007
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 09 Nov 2007 12:58:47 +1100
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
Message-ID: <1194573529.2860.7.camel@localhost.localdomain>

For those outside the US, 'Airplane!' might have been released as
'Flying High!'

What do you make of that?

I can make a hat, a broach, a pterodactyl!


R.



On Wed, 2007-11-07 at 09:25 -0500, Monkey Boy wrote:
> <Dr.Rumack>I just want to tell you all good luck. We're all counting
> on you.</Dr.Rumack>
> 
> -- 
> The difference between blogging and flogging is that flogging actually
> leaves an impression on people. 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From katzj at redhat.com  Fri Nov  9 02:06:37 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 08 Nov 2007 21:06:37 -0500
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <4733B8EA.7040105@fedoraproject.org>
References: <20071108134119.4653a86b__2283.32277988574$1194547412$gmane$org@redhat.com>
	<fh0dao$4tt$1@ger.gmane.org>  <4733B8EA.7040105@fedoraproject.org>
Message-ID: <1194573997.20915.14.camel@localhost.localdomain>

On Fri, 2007-11-09 at 07:03 +0530, Rahul Sundaram wrote:
> The mirrorlist among other things are down with the traffic from Fedora 
> 8 downloads.  Fedora infrastructure team is working on resolving this. 
> Try again later.

Things should be back up and running now

Jeremy



From skvidal at fedoraproject.org  Fri Nov  9 02:20:57 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 08 Nov 2007 21:20:57 -0500
Subject: After Fedora 8 comes Fedora 9!
In-Reply-To: <4733B8EA.7040105@fedoraproject.org>
References: <20071108134119.4653a86b__2283.32277988574$1194547412$gmane$org@redhat.com>
	<fh0dao$4tt$1@ger.gmane.org>  <4733B8EA.7040105@fedoraproject.org>
Message-ID: <1194574857.15170.54.camel@cutter>


On Fri, 2007-11-09 at 07:03 +0530, Rahul Sundaram wrote:
> > http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-8&arch=x86_64 
> 
> The mirrorlist among other things are down with the traffic from Fedora 
> 8 downloads.  Fedora infrastructure team is working on resolving this. 
> Try again later.

Actually, that's not what appears to have happened. The site that
mirrorlist app runs on went off line due to some kind of switch failure.
But since no fedora distribution release traffic was going through there
it is unlikely that the failure was due to the fedora release.

Just to be VERY clear.

-sv




From markg85 at gmail.com  Fri Nov  9 02:24:28 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 9 Nov 2007 03:24:28 +0100
Subject: Codec Buddy misleading.
Message-ID: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>

Hey,

Today is my first day in Fedora 8 (like probably a lot of people) and
when i want to play a movie i get codec buddy which is absolutely
fine! But now the misleading part comes. I live in Europe. for me it's
not illegal to install the "gstreamer-bad-plugins" or just packages
that get me mpeg/xvid/divx/aac/any_codec support and yet codec buddy
gives me only payed options. I didn't start using fedora a few years
ago to start paying for codecs!

Now my idea to get this better is to make codec buddy location
specific. When you install fedora you select the country where you
live. If codec buddy uses that information than it can point me to the
right direction where i can get my codecs for free. I ujnderstand that
Fedora can't include those codecs in there own repositories but
wouldn't it be possible to make a community driven (codec) repository
that contains all the packages that are not allowed in the USA but are
in EU (probably everywhere EXCEPT the USA). Fedora at least has to
notify the users that paying isn't needed if you don't live in the
USA!!

Redhat can just make a "eu base" just for this..?? it doesn't need to
cost redhat much (one dedicated server in the EU somewhere under
another name not connected to RedHat).. perhaps even free if they can
join up with for example NLUUG (and if nluug is willing of course)
cause this codec stuff is getting really annoying to get working every
time i install fedora..

Otherwise if this isn't a good idea in the eyes of the redhat people
than i would like to start the "Codec Group" (just made that up) to
make distribution packages of all the codecs for all the linux based
operating systems. i'm in but not all by myself and only of the idea
above (or something to solve the issue) is not approved. i hope that
at least 2 other people could join me.. and someone with multiple
package systems (rpm and apt) would be a gread help.

Let me know what you thing,
Mark.



From michael.wiktowy at gmail.com  Fri Nov  9 02:58:40 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Thu, 8 Nov 2007 21:58:40 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
Message-ID: <3e4ec4600711081858uffe12edr76cd281fec5c04e@mail.gmail.com>

On Nov 8, 2007 9:24 PM, Mark <markg85 at gmail.com> wrote:
> Let me know what you thing,
> Mark.

1) You should do a quick search of the archives before posting
questions ... this has been asked and answered many times ... many
many times.
2) This question is likely best asked on fedora-list and not fedora-devel-list.
3) Type 'rpm -Uvh http://rpm.livna.org/livna-release-8.rpm' as root
and install enough codecs to fill your boots.

/Mike

PS. It seems an opinion from Redhat legal has just arrived that might
make this question far less asked.
http://lwn.net/Articles/257559/



From jspaleta at gmail.com  Fri Nov  9 03:11:35 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 8 Nov 2007 18:11:35 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
Message-ID: <604aa7910711081911t4a271acbse9dfc9cf51309838@mail.gmail.com>

On Nov 8, 2007 5:24 PM, Mark <markg85 at gmail.com> wrote:
> Now my idea to get this better is to make codec buddy location
> specific. When you install fedora you select the country where you
> live. If codec buddy uses that information than it can point me to the
> right direction where i can get my codecs for free.

We just got a legal ruling concerning what we can do to reference 3rd
party repositories.
Please read over the recent discussion in fedora-advisory-list with
the Subject "Legal Update"
starting on Nov 7

The legal ruling allows us to reference such 3rd party repositories on
fedora project webpages, in a controlled manner.  We can't include
links to this stuff in any packages with distribute..even if we were
Wile E. Coyote clever and employed geoip or other location tricks.
Technical we co do it.. but if Red Hat Legal isn't cool with it... we
can't do it..because at the end of the day its Red Hat that has to
assume the legal liability here. We just have to grit our teeth and
accept it.

We, as in the fedora project, have some wiggle room now to reference
3rd party repositories in our webspace. What I would like to see is
some effort by users of those 3rd party repositories to impact
upstream codeina development so that its easy for third party repos to
hook into codeina as an additional vendor for codecs via packages.
So when users see the link to the crusty repo on our webpages, they go
there and are instructed to install crustyrpms-release package for the
crusty repository, it reconfigures codeina to include crusty
repository as a codec vendor.

-jef"super genius and ACME value club member"spaleta

-jef



From ngompa13 at gmail.com  Fri Nov  9 03:18:00 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 8 Nov 2007 21:18:00 -0600
Subject: Codec Buddy misleading.
In-Reply-To: <604aa7910711081911t4a271acbse9dfc9cf51309838@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<604aa7910711081911t4a271acbse9dfc9cf51309838@mail.gmail.com>
Message-ID: <8278b1b0711081918q5da74baeu977f94548658bfe5@mail.gmail.com>

Again, why is it that codeina cannot just search existing repositories for
codecs? I know there are some codecs that are not included in Fedora by
default, and such an ability is useful.

On Nov 8, 2007 9:11 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:

> On Nov 8, 2007 5:24 PM, Mark <markg85 at gmail.com> wrote:
> > Now my idea to get this better is to make codec buddy location
> > specific. When you install fedora you select the country where you
> > live. If codec buddy uses that information than it can point me to the
> > right direction where i can get my codecs for free.
>
> We just got a legal ruling concerning what we can do to reference 3rd
> party repositories.
> Please read over the recent discussion in fedora-advisory-list with
> the Subject "Legal Update"
> starting on Nov 7
>
> The legal ruling allows us to reference such 3rd party repositories on
> fedora project webpages, in a controlled manner.  We can't include
> links to this stuff in any packages with distribute..even if we were
> Wile E. Coyote clever and employed geoip or other location tricks.
> Technical we co do it.. but if Red Hat Legal isn't cool with it... we
> can't do it..because at the end of the day its Red Hat that has to
> assume the legal liability here. We just have to grit our teeth and
> accept it.
>
> We, as in the fedora project, have some wiggle room now to reference
> 3rd party repositories in our webspace. What I would like to see is
> some effort by users of those 3rd party repositories to impact
> upstream codeina development so that its easy for third party repos to
> hook into codeina as an additional vendor for codecs via packages.
> So when users see the link to the crusty repo on our webpages, they go
> there and are instructed to install crustyrpms-release package for the
> crusty repository, it reconfigures codeina to include crusty
> repository as a codec vendor.
>
> -jef"super genius and ACME value club member"spaleta
>
> -jef
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071108/6d197d7a/attachment.htm>

From jwboyer at gmail.com  Fri Nov  9 03:27:47 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 8 Nov 2007 21:27:47 -0600
Subject: Codec Buddy misleading.
In-Reply-To: <8278b1b0711081918q5da74baeu977f94548658bfe5@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<604aa7910711081911t4a271acbse9dfc9cf51309838@mail.gmail.com>
	<8278b1b0711081918q5da74baeu977f94548658bfe5@mail.gmail.com>
Message-ID: <20071108212747.11f1626d@zod.rchland.ibm.com>

On Thu, 8 Nov 2007 21:18:00 -0600
"King InuYasha" <ngompa13 at gmail.com> wrote:

> Again, why is it that codeina cannot just search existing repositories for
> codecs? I know there are some codecs that are not included in Fedora by
> default, and such an ability is useful.

Again, why is it you can't read the archives?

josh



From lightsolphoenix at gmail.com  Fri Nov  9 04:46:48 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Thu, 08 Nov 2007 23:46:48 -0500
Subject: (It pains me to say) KDE and broken logout
In-Reply-To: <4733969D.9080103@pajato.com>
References: <4733969D.9080103@pajato.com>
Message-ID: <4733E638.4010001@gmail.com>

Paul Michael Reilly wrote:
> The behavior I see after installing the KDE spin is that logout works 
> perfectly after I login for the first time.  After the second and 
> subsequent logins I  get empty air (nothing happens) when I click on 
> the Logout menu item.
The problem is aRts - or, more specifically, artsshell, which runs when 
aRts is supposed to be shutting down... except for some reason, it never 
seems to get around to that, leaving a black screen.

Or are you referring to something else?



From rdieter at math.unl.edu  Fri Nov  9 05:08:05 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 08 Nov 2007 23:08:05 -0600
Subject: (It pains me to say) KDE and broken logout
References: <4733969D.9080103@pajato.com>
Message-ID: <fh0q03$ue1$1@ger.gmane.org>

Paul Michael Reilly wrote:

> First let it be known that I read every last character of the original
> dreadful thread as a result of logout not working for me using the RC3
> F8 bits (the live Fedora and KDE x86_64 spins).  And I've confirmed that
> my issue is definitely not GDM vs KDM.

Already fixed, afaik, is your box fully up to date?  (We released a few
0-day updates).

In particular, was knetworkmanger-0.2-0.7 fixing
http://bugzilla.redhat.com/367711

-- Rex



From cjdahlin at ncsu.edu  Fri Nov  9 05:08:40 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Fri, 09 Nov 2007 00:08:40 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108135039.2a37fbd9@zod.rchland.ibm.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<20071107114158.6cf5f250@weaponx>	<20071108100819.GA12141@evileye.englab.brq.redhat.com>	<1194532417.6559.21.camel@localhost.localdomain>	<slrnfj6h9l.hsl.mcepl@hubmaier.ceplovi.cz>	<1194545984.9673.458.camel@mccallum.corsepiu.local>	<1194548915.3271.102.camel@localhost.localdomain>
	<20071108135039.2a37fbd9@zod.rchland.ibm.com>
Message-ID: <4733EB58.3010707@ncsu.edu>

Josh Boyer wrote:
> On Thu, 08 Nov 2007 14:08:35 -0500
> Simo Sorce <ssorce at redhat.com> wrote:
>
>   
>> On Thu, 2007-11-08 at 19:19 +0100, Ralf Corsepius wrote:
>>     
>>> On Thu, 2007-11-08 at 18:19 +0100, Matej Cepl wrote:
>>>       
>>>> On 2007-11-08, 14:33 GMT, Lubomir Kundrak wrote:
>>>>         
>>>>>>>> any plans to replace it by git, mercurial, svn or other 
>>>>>>>> more modern version control system?
>>>>>>>>                 
>>>>>> - CVS server outage :)
>>>>>>             
>>>>> Other services never have outages?
>>>>>           
>>>> They don't -- have you ever heard about distributed VC? If the 
>>>> repository I am working against has outage, then I don't care.
>>>>         
>>> And how do you pull/push if the remote server is down?
>>>       
>> You commit locally and keep working.
>> When the repo is up you push down everything in one go.
>>
>> If you need patches from others they can share their repo or send you
>> mails that keep the whole meta-data.
>>
>> DVCS really have *no* problems with outages. Only centralized VCS has.
>>     
>
> It does.  Our buildsys requires a single repository to pull (or
> checkout) from to do builds.  So until your changes are present in
> there, you still suffer from the "outage" problem if you want to
> actually build packages for others to consume in the official repos.
>
>   
This, as Red Hat's GIT-RE team is learning, is because the notion of a 
distributed build system hasn't really been spec'd out. I have some 
notion of how to do it, and I've almost figured out a workflow with 
buildbot.
> josh
>
>   



From jdieter at gmail.com  Fri Nov  9 06:03:54 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Fri, 09 Nov 2007 08:03:54 +0200
Subject: Deltarpms for F7 -> F8
Message-ID: <1194588234.18429.5.camel@jndwidescreen.lesbg.loc>

Deltarpms are now available for an upgrade from Fedora 7 to Fedora 8
(i386 only) using the yum-presto plugin.  To use, first make sure your
Fedora 7 system is completely up-to-date and then follow the steps in:

http://fedoraproject.org/wiki/YumUpgradeFaq

The only change is that after step 3, add
deltaurl=http://lesloueizeh.com/f8/i386/fedora
to /etc/yum.repos.d/fedora.repo

If you have any questions, ask on #fedora on IRC or the mailing list.

To give you an idea of the savings, I've downloaded the entire 12G
Fedora 8 repository, and I only had to download 2.1G of rpms and drpms
applied against our local Fedora 7 repository.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/0c39eb7e/attachment.sig>

From jdieter at gmail.com  Fri Nov  9 06:06:38 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Fri, 09 Nov 2007 08:06:38 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <p04330101c35935040240@[192.168.123.162]>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
	<1194550007.10285.13.camel@jndwidescreen.lesbg.loc>
	<p04330101c35935040240@[192.168.123.162]>
Message-ID: <1194588398.18429.9.camel@jndwidescreen.lesbg.loc>


On Thu, 2007-11-08 at 17:07 -0500, Tony Nelson wrote:
> At 9:26 PM +0200 11/8/07, Jonathan Dieter wrote:
>  ...
> >On a better note, deltarpms for Fedora 8 updates are ready.  The good
> >news is that you no longer have to use "deltaurl=".  All you do is set
> >"baseurl=http://lesloueizeh.com/f8/i386/updates"
> >in /etc/yum.repos.d/fedora-updates.repo.  The bad news (at least for me)
> >is that it means you will be downloading both deltarpms and regular rpms
> >from our school's mirror and I believe our bandwidth is limited to
> >100GB/month.
> 
> 100 GiB is not much.  Will "deltaurl=" still work as before, with non-delta
> updates coming from the baseurl or mirrorlist?

We made a design decision with yum-presto-0.4.x to not support deltaurl
anymore (mainly because it increased the size and complexity of the code
by a large factor).

In the short term, that's a pain because the official repositories
aren't presto-enabled, but once they do become presto-enabled, all you
will have to do is install yum-presto without making any configuration
changes.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/31da45b0/attachment.sig>

From wtogami at redhat.com  Fri Nov  9 06:12:03 2007
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 09 Nov 2007 01:12:03 -0500
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194588398.18429.9.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>	<1194550007.10285.13.camel@jndwidescreen.lesbg.loc>	<p04330101c35935040240@[192.168.123.162]>
	<1194588398.18429.9.camel@jndwidescreen.lesbg.loc>
Message-ID: <4733FA33.6020602@redhat.com>

Jonathan Dieter wrote:
> 
> We made a design decision with yum-presto-0.4.x to not support deltaurl
> anymore (mainly because it increased the size and complexity of the code
> by a large factor).
> 
> In the short term, that's a pain because the official repositories
> aren't presto-enabled, but once they do become presto-enabled, all you
> will have to do is install yum-presto without making any configuration
> changes.
> 
> Jonathan
> 

Has there been any talk about presto-enabling the official F8 repo?

I suppose it would be pretty safe, given that it only effects people who 
choose to install the plugin.  Additional bandwidth/disk usage for the 
mirrors would be relatively small for the benefit.

Warren Togami
wtogami at redhat.com



From jdieter at gmail.com  Fri Nov  9 06:28:31 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Fri, 09 Nov 2007 08:28:31 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <4733FA33.6020602@redhat.com>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
	<1194550007.10285.13.camel@jndwidescreen.lesbg.loc>
	<p04330101c35935040240@[192.168.123.162]>
	<1194588398.18429.9.camel@jndwidescreen.lesbg.loc>
	<4733FA33.6020602@redhat.com>
Message-ID: <1194589711.22486.6.camel@jndwidescreen.lesbg.loc>

On Fri, 2007-11-09 at 01:12 -0500, Warren Togami wrote:
> Jonathan Dieter wrote:
> > 
> > We made a design decision with yum-presto-0.4.x to not support deltaurl
> > anymore (mainly because it increased the size and complexity of the code
> > by a large factor).
> > 
> > In the short term, that's a pain because the official repositories
> > aren't presto-enabled, but once they do become presto-enabled, all you
> > will have to do is install yum-presto without making any configuration
> > changes.
> > 
> > Jonathan
> > 
> 
> Has there been any talk about presto-enabling the official F8 repo?
> 
> I suppose it would be pretty safe, given that it only effects people who 
> choose to install the plugin.  Additional bandwidth/disk usage for the 
> mirrors would be relatively small for the benefit.

Yeah, as I mentioned in another thread, the issue is that we have to get
the koji to generate the deltarpms and bodhi to publish them.  It was
originally on the list of things to get done before F8, but then other
tasks that took higher priority took longer than expected.

The goal now (at least as far as I understand it) is to get the buildsys
stuff done and then presto-enable the F8 repository.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/6ec10088/attachment.sig>

From sundaram at fedoraproject.org  Fri Nov  9 07:29:18 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 09 Nov 2007 12:59:18 +0530
Subject: Fedora 8 - Common Bugs and Known Issues
Message-ID: <47340C4E.9020101@fedoraproject.org>

Hi

As usual,

https://fedoraproject.org/wiki/Bugs/F8Common

Let me know if there are other common issues (with a reference to the 
bugzilla report) and if there are any known workarounds to them. Just 
add them yourself if you have wiki write access and we will review them 
periodically.  Thanks for your assistance.

=== CD/DVD Install Hangs ===

There appears to be an issue between ISOLINUX and certain BIOSes where 
the USB keyboard does not work at the boot menu. This can be worked 
around by holding down the "shift" key during bootup to force the 
bootloader into text mode.

[http://bugzilla.redhat.com/239585 Bug 239585] - On certain systems, the 
CD/DVD may hang during boot with message "Ready". Most of the bugs that 
caused this are thought to be fixed.

=== Sun Java Bug ===

[https://bugzilla.redhat.com/show_bug.cgi?id=254144 Bug 254144] Fedora 8 
includes [http://icedtea.classpath.org/wiki//Main_Page IcedTea], a free 
and open source derivative of OpenJDK.  Users trying to install Sun Java 
might run across a bug with the Sun JVM that makes it incompatible with 
the newer libX11 included in Fedora 8.

Workaround is  [https://bugzilla.redhat.com/show_bug.cgi?id=254144#c14 
documented]. We highly recommend using IcedTea instead.

=== Suspend/Resume Problem With Nvidia cards ===

Suspend option in the menu has been deliberately disabled in this 
release on systems with Nvidia cards since the default "nv" Xorg driver 
from Nvidia has a number of problems in handling of suspend and resume 
correctly. If you wish to override this default, add a file that 
contains ALLOW_NV_SUSPEND="yes" under /etc/pm/config.d

=== NetworkManager cannot connect to EAP-TLS secured wireless networks ===

[https://bugzilla.redhat.com/show_bug.cgi?id=323371 Bug 323371] - The 
!NetworkManager 0.7 snapshot included in Fedora 8 cannot connect to 
networks that use encrypted certificate files for authentication. A fix 
will be available soon.

=== NetworkManager fails to see wireless networks with Intel 3945 
chipsets ===

[https://bugzilla.redhat.com/show_bug.cgi?id=319071 Bug 319071] If you 
have the Intel 3945 wireless chipset, you may experience trouble finding 
and associating with wireless networks in NetworkManager. Try adding

{{{options iwl3945 disable_hw_scan=1
}}}

to /etc/modprobe.conf

=== Cannot start ssh: Service will not start after installation of the 
x86_64 version ===

[https://bugzilla.redhat.com/364971 Bug 364971] - /usr/sbin/sshd: 
Permission denied

This issue should be fixed by updating to the latest 
selinux-targeted-policy which is greater than 
selinux-policy-targeted-3.0.8-44.fc8

Rahul



From pmr at pajato.com  Fri Nov  9 07:35:43 2007
From: pmr at pajato.com (Paul Michael Reilly)
Date: Fri, 09 Nov 2007 02:35:43 -0500
Subject: (It pains me to say) KDE and broken logout
In-Reply-To: <4733E638.4010001@gmail.com>
References: <4733969D.9080103@pajato.com> <4733E638.4010001@gmail.com>
Message-ID: <47340DCF.6090604@pajato.com>

Kelly Miller wrote:
> Paul Michael Reilly wrote:
>> The behavior I see after installing the KDE spin is that logout works 
>> perfectly after I login for the first time.  After the second and 
>> subsequent logins I  get empty air (nothing happens) when I click on 
>> the Logout menu item.
> The problem is aRts - or, more specifically, artsshell, which runs when 
> aRts is supposed to be shutting down... except for some reason, it never 
> seems to get around to that, leaving a black screen.
> 
> Or are you referring to something else

Since I'm not getting a black screen, I'm guessing it is something else. 
  For me, clicking on the Logout menu item had no effect at all.

-pmr




From tmraz at redhat.com  Fri Nov  9 08:23:40 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 09 Nov 2007 09:23:40 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108232500.GZ2871@petra.dvoda.cz>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108232500.GZ2871@petra.dvoda.cz>
Message-ID: <1194596620.6250.43.camel@vespa.kabelta.loc>

On Fri, 2007-11-09 at 00:25 +0100, Karel Zak wrote:

>  * __unfortunately__, we don't maintain source code in our VCS! We use
>    it for *.patch files + commit messages. It means you can't use all
>    modern features -- just because GIT, Hg, ... are designed for work
>    with source code (unlike Quilt, StGIT).
That's because the pkgs CVS tree purpose is very different. And I think
that CVS is pretty good and adequate tool for this purpose. To utilize
these wonderful features of DVCSs we'd probably just need some set of
scripts which would make interaction with the pkgs CVS and your prefered
local DVCS repository easy and automated. Such as importing an upstream
tarball into your DVCS, pulling patches from pkgs CVS and rebasing them.
Exporting these rebased patches into pkgs CVS and so on.

The problems, the reasons why such script do not exist yet, here are
many - people having different prefered DVCS with different feature
sets, different prefered workflow when rebasing, etc. etc.

How we can obtain such scripts? Only when some developer who already
uses a DVCS interacting with the pkgs CVS tree writes them and publishes
them. Of course they would be useful only to people who use the same
DVCS and have similar workflow.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From braden at endoframe.com  Fri Nov  9 08:34:19 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 09 Nov 2007 03:34:19 -0500
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <1194597259.4214.4.camel@hinge.endoframe.net>

On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
> Hello,
> 
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
> 
> Idear how get out, what goes wrong?

No; but I had exactly the same problem. :-/

I tried removing non-Fedora RPMs I had installed (just jdk and icc) as
Andrew Farris suggested; but unfortunately that had no effect.

Ultimately I gave up and did a fresh install.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From opensource at till.name  Fri Nov  9 08:47:27 2007
From: opensource at till.name (Till Maas)
Date: Fri, 09 Nov 2007 09:47:27 +0100
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194550007.10285.13.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<645d17210711080804x2e8e9a5p503be882fab477ff@mail.gmail.com>
	<1194550007.10285.13.camel@jndwidescreen.lesbg.loc>
Message-ID: <200711090947.38129.opensource@till.name>

On Do November 8 2007, Jonathan Dieter wrote:

> in /etc/yum.repos.d/fedora-updates.repo.  The bad news (at least for me)
> is that it means you will be downloading both deltarpms and regular rpms
> from our school's mirror and I believe our bandwidth is limited to
> 100GB/month.

Maybe you can add a redirect rule for the regular rpms, so that they are 
downloaded from somewhere else, e.g.

RedirectMatch (.*)\.rpm$ http://www.example.com/fedora/release/8/$1.rpm

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/91431643/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Nov  9 09:02:04 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 9 Nov 2007 10:02:04 +0100 (CET)
Subject: When will be CVS replaced by modern version control system?
Message-ID: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>


Le Ven 9 novembre 2007 00:25, Karel Zak a ?crit :

>  * __unfortunately__, we don't maintain source code in our VCS!

It's not unfortunate at all, the stuff in our VCS has not the same
target as the stuff in upstream VCS and there needs to be a big red
line between them.

Releases happen upstream. Development happens upstream. Fedora rpm
patches are an overlay of upstream work, need to be as limited and
static as possible. Anything else is fork-receipe and short path to
maintenance hell.

And sure it is not very convenient for developpers, because
developpers typically do not want to think about this stuff and would
be happy to have their IDE directly plugged into production or user
systems. But that's basic maintenance discipline that makes everyone
else's life easier.

-- 
Nicolas Mailhot



From lkundrak at redhat.com  Fri Nov  9 09:11:20 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Fri, 09 Nov 2007 10:11:20 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <1194599480.19966.0.camel@localhost.localdomain>


On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
> Hello,
> 
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
> 
> Idear how get out, what goes wrong?

Tried looking at the log if there's anything suspicious there? Tried
strace?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From frank-buettner at gmx.net  Fri Nov  9 09:26:03 2007
From: frank-buettner at gmx.net (frank-buettner at gmx.net)
Date: Fri, 9 Nov 2007 10:26:03 +0100 (CET)
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <1194599480.19966.0.camel@localhost.localdomain>
References: <4733676F.2000209@gmx.net>
	<1194599480.19966.0.camel@localhost.localdomain>
Message-ID: <53387.192.168.0.1.1194600363.squirrel@homer>

>
> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
>> Hello,
>>
>> I have try to update an F7 installation to F8, but at dependency check
>> it freeze all ways at 26%.
>> It happens in the text and gui mode.
>> anaconda use 100% CPU and 97% of all memory.
>>
>> Idear how get out, what goes wrong?
>
> Tried looking at the log if there's anything suspicious there? Tried
> strace?
>
> --
> Lubomir Kundrak (Red Hat Security Response Team)
>

At the console not errors or something is shown.:(
Where will be the logfiles written at the update process?



From mike.cohler at gmail.com  Fri Nov  9 09:37:03 2007
From: mike.cohler at gmail.com (Mike C)
Date: Fri, 9 Nov 2007 09:37:03 +0000 (UTC)
Subject: Wireless WPA2 Personal Missing
References: <1194572648.2163.6.camel@localhost6.localdomain6>
Message-ID: <loom.20071109T093318-213@post.gmane.org>

Richi Plana <myfedora <at> richip.dhs.org> writes:

> The second isn't a big problem but might be something the devs might be
> interested in. I've a DLink DWL-G650 PCMCIA card and I used to use
> madwifi's ath_pci module with it in F7. Worked like a charm. Apparently
> in F8, there's a module that keeps getting loaded called ath5k.

You can add ath5k to the blacklist file at
/etc/modprobe.d/blacklist

Then the new ath5k driver won't be loaded at boot time, and you can then have
the ath_pci module loaded instead.



From kzak at redhat.com  Fri Nov  9 09:52:30 2007
From: kzak at redhat.com (Karel Zak)
Date: Fri, 9 Nov 2007 10:52:30 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>
Message-ID: <20071109095230.GB2871@petra.dvoda.cz>

On Fri, Nov 09, 2007 at 10:02:04AM +0100, Nicolas Mailhot wrote:
> 
> Le Ven 9 novembre 2007 00:25, Karel Zak a ?crit :
> 
> >  * __unfortunately__, we don't maintain source code in our VCS!
> 
> It's not unfortunate at all, the stuff in our VCS has not the same
> target as the stuff in upstream VCS and there needs to be a big red
> line between them.

 You can set the big red line in modern content trackers -- tags,
 branches and rebase are your friends. This is not problem.

> Releases happen upstream. Development happens upstream. Fedora rpm
> patches are an overlay of upstream work, need to be as limited and
> static as possible. Anything else is fork-receipe and short path to
> maintenance hell.

 We still maintain non-trivial number of non-upstream patches.

> And sure it is not very convenient for developpers, because
> developpers typically do not want to think about this stuff and would
> be happy to have their IDE directly plugged into production or user
> systems. But that's basic maintenance discipline that makes everyone
> else's life easier.

 I think the best way (for Fedora project) is Tom Mraz's suggestion:
 use stupid central CVS as a storage for patch files and locally use
 scripts that convert these patches as code to/from real DVCS.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From frank-buettner at gmx.net  Fri Nov  9 08:44:13 2007
From: frank-buettner at gmx.net (frank-buettner at gmx.net)
Date: Fri, 9 Nov 2007 09:44:13 +0100 (CET)
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <1194597259.4214.4.camel@hinge.endoframe.net>
References: <4733676F.2000209@gmx.net>
	<1194597259.4214.4.camel@hinge.endoframe.net>
Message-ID: <55880.192.168.0.1.1194597853.squirrel@homer>

> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
>> Hello,
>>
>> I have try to update an F7 installation to F8, but at dependency check
>> it freeze all ways at 26%.
>> It happens in the text and gui mode.
>> anaconda use 100% CPU and 97% of all memory.
>>
>> Idear how get out, what goes wrong?
>
> No; but I had exactly the same problem. :-/
>
> I tried removing non-Fedora RPMs I had installed (just jdk and icc) as
> Andrew Farris suggested; but unfortunately that had no effect.
>
> Ultimately I gave up and did a fresh install.
>
> --
> Braden McDaniel                           e-mail: <braden at endoframe.com>
> <http://endoframe.com>                    Jabber: <braden at jabber.org>
>
On my system I think there is no none Fedora RPM installed.
Are there a way to check this?



From valent.turkovic at gmail.com  Fri Nov  9 10:44:36 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 9 Nov 2007 11:44:36 +0100
Subject: java-plugin not working in F8
Message-ID: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>

Hi,

I installed java plugin via 'yum install java-plugin' and firefox
still complains that plugin is not installed...
I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).


$ ls -al /usr/lib/mozilla/plugins/*
lrwxrwxrwx 1 root root    34 2007-11-09 11:21
/usr/lib/mozilla/plugins/libjavaplugin.so ->
/etc/alternatives/libjavaplugin.so
-rwxr-xr-x 1 root root 54276 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-basic-plugin.so
-rw-r--r-- 1 root root   167 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-basic-plugin.xpt
-rwxr-xr-x 1 root root 86040 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-complex-plugin.so
-rw-r--r-- 1 root root  3227 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-complex-plugin.xpt
-rwxr-xr-x 1 root root 90780 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so
-rw-r--r-- 1 root root  4312 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-gmp-plugin.xpt
-rwxr-xr-x 1 root root 53732 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-mully-plugin.so
-rw-r--r-- 1 root root   167 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-mully-plugin.xpt
-rwxr-xr-x 1 root root 77572 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so
-rw-r--r-- 1 root root  2211 2007-10-17 16:19
/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.xpt

$ ls -al /etc/alternatives/libjavaplugin.so
lrwxrwxrwx 1 root root 55 2007-11-09 11:21
/etc/alternatives/libjavaplugin.so ->
/usr/lib/jvm/jre-1.7.0-icedtea/lib/i386/gcjwebplugin.so

What is the issue?

I have only one java site can you please give me a few more links just
to make sure it is not the issue with the site I'm visiting.

Thank you,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From nphilipp at redhat.com  Fri Nov  9 11:08:28 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 09 Nov 2007 12:08:28 +0100
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <20071108164823.GA26392@jadzia.bu.edu>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
	<20071108164823.GA26392@jadzia.bu.edu>
Message-ID: <1194606508.9672.11.camel@gibraltar.str.redhat.com>

On Thu, 2007-11-08 at 11:48 -0500, Matthew Miller wrote:
> On Wed, Nov 07, 2007 at 09:55:08AM -0500, Kelly Miller wrote:
> > here).  First of all, is there a preferred language for development
> > like this?  I've actually done very little to no Python development
> 
> Almost certainly Python.
> 
> The key reason these utilties need rewriting is to separate the user

They don't need rewriting, they need refactoring. There's too much logic
in the tools already to be able to make throwing it all away and
beginning from scratch feasible without breaking things. There's also a
lot of wheel-reinvention in the tools as they are today, i.e. a
potential for code consolidation between the tools.

> interface (GUI, full-screen text-mode, and command-line) from the possibly
> privileged actions they need to perform. 

I agree that UI and logic need separation and ...

> This should be done using PolicyKit -- see
> <http://fedoraproject.org/wiki/Releases/FeaturePolicyKit>.

... using PolicyKit to encapsulate privileged operations is what I had
in mind, at least for my tools (date, nfs, services, samba, users). Mind
that not all logic needs to be run with elevated privileges.

Just for the record, I'm open for contributions, especially in the area
of (lack of) TUIs. I'm not so open for contributions that begin with
"let's rewrite this from scratch".

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From buytenh at marvell.com  Fri Nov  9 11:22:09 2007
From: buytenh at marvell.com (Lennert Buytenhek)
Date: Fri, 9 Nov 2007 12:22:09 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071109095230.GB2871@petra.dvoda.cz>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>
	<20071109095230.GB2871@petra.dvoda.cz>
Message-ID: <20071109112208.GA12660@xi.wantstofly.org>

On Fri, Nov 09, 2007 at 10:52:30AM +0100, Karel Zak wrote:

> > And sure it is not very convenient for developpers, because
> > developpers typically do not want to think about this stuff and would
> > be happy to have their IDE directly plugged into production or user
> > systems. But that's basic maintenance discipline that makes everyone
> > else's life easier.
> 
> I think the best way (for Fedora project) is Tom Mraz's suggestion:
> use stupid central CVS as a storage for patch files and locally use
> scripts that convert these patches as code to/from real DVCS.

I've been doing something like that, but only for the packaging
(i.e. no exploded trees.)  I have a local CVS->git conversion of the
Fedora CVS tree which I use for things like:

1. Being able to quickly see the history of a package and changes
   between packaging in different versions of that package without
   having to go through the CVS server (which is on another
   continent than the one I am on -- I guess the latency from the US
   is probably not too bad.)

2. Visualising branches with gitk, to make it easier to see where
   F-7/F-8 branches have forked off from devel, etc.

3. Maintaining trivial patches for the ARM port such as the one in
   BZ#245441 (when a new upstream release comes out, just run 'git
   pull' and be done.)

4. Maintaining not-so-trivial patches, such as patches to make
   packages build cross, or patches to make packages build with
   uClibc instead of glibc.


There are a number of observations to be made about keeping local
changes to packages:

- For patches in category (3), you could argue that these should
  just be merged upstream, and that would remove the need to make
  maintainance of separate patches easier.

  The truth is that they aren't always merged quickly, and giving
  arch teams unrestricted CVS access only solves part of the problem
  (e.g. what if you want to commit a patch that solves an issue but
  you're not sure whether the maintainer will like it, but he
  isn't responding -- you'll still have to maintain the patches
  separately somehow for some time.)

- Also, the patches in category (4) are unlikely to be merged into
  Fedora any time soon, and the "We can stick with CVS because we
  don't have to make life easier for forks because those people
  should just be working on upstream Fedora instead" argument doesn't
  really apply, because we have enough local changes that you wouldn't
  even _want_ to have in Fedora. ;-)

- Besides, the existence of OLPC-2 branches for various packages
  suggests that we _do_ want to accommodate forks to a limited
  extent.

  Note that in a distributed VCS, the OLPC-2 specific stuff wouldn't
  have to live on the main Fedora VCS server, and could very easily
  live on a separate box.  (Whether this is desirable for the OLPC-2
  stuff or not is a separate issue, I'm just saying that it is easily
  possible in a DVCS.)  (And whether the result can still be called
  Fedora or not is also a separate issue.)

- [ Also, putting our cross/uClibc patches in a VCS that understands
    branches makes it easier for us to keep those sets of patches on
    different branches, i.e. keep them separate, and only merge them
    the moment you want to build a package.          ]

If you have a need to maintain local changes to packages, IMHO
you're _much_ better off if you keep them in a VCS that is connected
to the upstream Fedora VCS in some sense.

I _could_ just have checked out Fedora CVS, committed that into my
own CVS tree, and started hacking on that, but then I would just be
making life a lot harder for myself, as that would make pulling in
new upstream changes hell, and would probably lead to a permanent
fork.


As an example, Fedora's rpm packaging looks somewhat like this in
gitweb:

	http://git.wantstofly.org/?p=fedora/rpm.git;a=summary

The tags in the upper half correspond with tags in CVS.  The heads
on the bottom correspond with each of the branches in CVS -- note
how that in the git conversion, different branches live in one
repository, and are merely different versions of the same thing,
instead of living in separate subdirectories in the same module.

To see the individual commits, click on 'shortlog' next to the
branch name (under 'heads'.)

In gitk, it ends up looking something like this:

	http://www.wantstofly.org/~buytenh/fedora-git-rpm.png

Note that it is really easy to see:
- where F-7/F-8 forked off from devel
- whether there have been patches applied to F-7 or F-8 that
  haven't been committed to devel yet or vice versa
- etc.

Two more examples (gcc and glibc) are here:
	http://git.wantstofly.org/?p=fedora/gcc.git;a=summary
	http://git.wantstofly.org/?p=fedora/glibc.git;a=summary



From u.lehmann at de.tecosim.com  Fri Nov  9 11:26:31 2007
From: u.lehmann at de.tecosim.com (utz lehmann)
Date: Fri, 09 Nov 2007 12:26:31 +0100
Subject: yum bug? resolving depencies loop (was: Re: Update form F7 to F8
	freeze at 26%)
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <1194607591.25255.22.camel@donner.tecosim.de>

Hello

On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
> 
> Idear how get out, what goes wrong?

I think it's a yum bug.

I had this this too. Upgrading a f7 x86_64 system with the DVD.

Then i tried to make the upgrade with yum.
Installed the f8 fedora-release rpm manually.
Started yum update _with only_ the DVD as repository:
yum --disablerepo='*' --enablerepo=f8-dvd update

After a some time it loops while resolving depencies with no progress.
I guess the same happens while upgrading with the DVD.

I have captures of the looping yum if anyone is interested.

With all repositories (fedora everything + others) a "yum update"
doesn't loop. But i it gave others errors (decencies, conflicts).

I'm doing the f7->f8 now in small steps with yum update (all repos
enabled) and resolve the errors manually. So i don't have the original
rpm database anymore.


utz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/d6f15889/attachment.sig>

From mike at miketc.com  Fri Nov  9 11:28:15 2007
From: mike at miketc.com (Mike Chambers)
Date: Fri, 09 Nov 2007 05:28:15 -0600
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
Message-ID: <1194607695.4630.1.camel@scrappy.miketc.com>

On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> Hi,
> 
> I installed java plugin via 'yum install java-plugin' and firefox
> still complains that plugin is not installed...
> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).

Just install the java-icedtea-plugin (just look for icedtea) from Fedora
and it will work just fine.

Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
as well?

-- 
Mike Chambers
Madisonville, KY

"The best lil town on Earth!"



From nphilipp at redhat.com  Fri Nov  9 11:37:42 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 09 Nov 2007 12:37:42 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071107114158.6cf5f250@weaponx>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
Message-ID: <1194608262.9672.30.camel@gibraltar.str.redhat.com>

On Wed, 2007-11-07 at 11:41 -0600, Josh Boyer wrote:
> On Wed, 7 Nov 2007 15:12:45 +0100
> Adam Tkac <atkac at redhat.com> wrote:
> 
> > Hi all,
> > 
> > CVS has already passed over best years. I'm wonder why modern
> > project like Fedora still has sources in this ancient system. Are here
> > any plans to replace it by git, mercurial, svn or other more modern
> > version control system?
> 
> Replacing a VCS for the fun of it is pretty pointless.  Can you
> elaborate on a workflow you would like to see that CVS is not suited
> to?

- Embargoed security fixes. With CVS you need to jump through hoops over
hoops to get this right, e.g.: internal CVS server with developer write
access that syncs to public read-only CVS server only those pieces not
tagged as embargoed. Then all kinds of people complain about lack of
openness. With a DVCS, I can do the changes locally, or push them to the
SooperSekrit(tm) embargo repository of my choosing (we could have a
locked down one where koji pulls from, this could automatically pull
from the public repository to get normal changes) and push things public
once they are public.

- Quick operations. I usually "cvs ci", "make tag build" on several
Fedora versions of my packages in parallel to overcome the sheer
slowness of CVS. Then Murphy comes around and breaks not one, but all of
these builds -> unnecessary lost time for me, unnecessary lost CPU
cycles on the builders.

- People without write access could do proposed changes in their local
repos and (in Mercurial lingo) "hg bundle" and send them in a mail, or
let me pull their repos.

- With a DVCS, we could put the several Fedora/EPEL versions into
branches and merge between them. Think of that, real merges which (how
crass) would automatically add new patches and all that with history
info! Patches with history even though they've been renamed! Oh, the
decadence!

>   Right now, CVS works fine for what we do, which is mostly editing
> spec files.
>
> I am by no means a proponent of CVS.  I think it sucks.  But we have no
> _usecase_ for a different VCS at the moment.

That is not true. CVS itches me at a number of places that's not funny
anymore. See above for some examples. The fun thing is that there are
DVCSs out there that don't need huge retraining for people coming from
CVS.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From valent.turkovic at gmail.com  Fri Nov  9 11:44:53 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 9 Nov 2007 12:44:53 +0100
Subject: PulseAudio distorts audio (over amplification)
Message-ID: <64b14b300711090344x158bf875wc2dfb08d107dabf8@mail.gmail.com>

I reported this bug for F8 RC3 and it is still present in F8 final.

https://bugzilla.redhat.com/show_bug.cgi?id=366001

Does anybody else has this issue? Is this bug that is only notices on
some hardware (audio drivers) or not?

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Fri Nov  9 11:47:55 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 9 Nov 2007 12:47:55 +0100
Subject: java-plugin not working in F8
In-Reply-To: <1194607695.4630.1.camel@scrappy.miketc.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
Message-ID: <64b14b300711090347s6989f48n90ee8b367bd89b74@mail.gmail.com>

On Nov 9, 2007 12:28 PM, Mike Chambers <mike at miketc.com> wrote:
> On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> > Hi,
> >
> > I installed java plugin via 'yum install java-plugin' and firefox
> > still complains that plugin is not installed...
> > I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
>
> Just install the java-icedtea-plugin (just look for icedtea) from Fedora
> and it will work just fine.
>
> Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
> as well?

AFAIK java-plugin is the same as java-icedtea-plugin

look for your self:

# yum search icedtea
java-1.7.0-icedtea-plugin.i586 : IcedTea Web Browser Plugin

java-1.7.0-icedtea-devel.i586 : IcedTea Development Environment
java-1.7.0-icedtea-javadoc.i586 : IcedTea API Documentation
java-1.7.0-icedtea-demo.i586 : IcedTea Demos
java-1.7.0-icedtea-src.i586 : IcedTea Source Bundle
java-1.7.0-icedtea.i586 : IcedTea Runtime Environment
java-1.7.0-icedtea-plugin.i586 : IcedTea Web Browser Plugin
java-1.7.0-icedtea.i586 : IcedTea Runtime Environment

# yum install java-1.7.0-icedtea-plugin
Setting up Install Process
Parsing package install arguments
Package java-1.7.0-icedtea-plugin - 1.7.0.0-0.19.b21.snapshot.fc8.i586
is already installed.
Nothing to do


valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From mharris at mharris.ca  Fri Nov  9 11:57:58 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Fri, 09 Nov 2007 06:57:58 -0500
Subject: java-plugin not working in F8
In-Reply-To: <1194607695.4630.1.camel@scrappy.miketc.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
Message-ID: <47344B46.6070604@mharris.ca>

Mike Chambers wrote:
> On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
>> Hi,
>>
>> I installed java plugin via 'yum install java-plugin' and firefox
>> still complains that plugin is not installed...
>> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
> 
> Just install the java-icedtea-plugin (just look for icedtea) from Fedora
> and it will work just fine.
> 
> Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
> as well?

I'm running F8/x86_64 and haven't manually installed any Java stuff yet, 
just whatever might have been installed by anaconda by default.  Up 
until now I hadn't visited any web pages with Java on them.

A lot of people have been having problems with Java it seems, and so I 
decided to try to get it to work myself.  I google searched for a "Java 
test", went to the Sun page, and it just worked automatically already, 
presumeably with iced-tea, which I assume was installed for me already 
by anaconda.  I went to a variety of other Java websites to test it out 
and have had no problems at all so far.  All Java sites work in firefox 
for me automatically.

As mentioned above, I haven't had to install anything, configure 
anything, or do anything manual for this to work, it just works out of 
the box on x86_64, at least for me.

I can only assume that the people having the problems either:

1) Are coming from an upgrade of a previous OS release
or
2) Have Sun, IBM, or some other Java installed already, or are trying to 
install some other Java
3) Have upgraded and didn't get iced-tea by default perhaps.

Anyhow, worst case scenario -> do a fresh OS install and Java seems to 
work in firefox right out of the box.  ;o)



-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From mcepl at redhat.com  Fri Nov  9 12:01:31 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 09 Nov 2007 13:01:31 +0100
Subject: When will be CVS replaced by modern version control system?
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108232500.GZ2871@petra.dvoda.cz>
	<1194596620.6250.43.camel@vespa.kabelta.loc>
Message-ID: <rpud05xk7i.ln2@hubmaier.ceplovi.cz>

On Fri, 09 Nov 2007 09:23:40 +0100, Tomas Mraz scripst:
> The problems, the reasons why such script do not exist yet, here are
> many - people having different prefered DVCS with different feature
> sets, different prefered workflow when rebasing, etc. etc.
> 
> How we can obtain such scripts? Only when some developer who already
> uses a DVCS interacting with the pkgs CVS tree writes them and publishes
> them. Of course they would be useful only to people who use the same
> DVCS and have similar workflow.

http://wiki.darcs.net/DarcsWiki/Tailor/VersionOne

Mat?j



From frank-buettner at gmx.net  Fri Nov  9 12:18:47 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Fri, 09 Nov 2007 13:18:47 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <53387.192.168.0.1.1194600363.squirrel@homer>
References: <4733676F.2000209@gmx.net>	<1194599480.19966.0.camel@localhost.localdomain>
	<53387.192.168.0.1.1194600363.squirrel@homer>
Message-ID: <47345027.3050607@gmx.net>

frank-buettner at gmx.net schrieb:
>> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
>>> Hello,
>>>
>>> I have try to update an F7 installation to F8, but at dependency check
>>> it freeze all ways at 26%.
>>> It happens in the text and gui mode.
>>> anaconda use 100% CPU and 97% of all memory.
>>>
>>> Idear how get out, what goes wrong?
>> Tried looking at the log if there's anything suspicious there? Tried
>> strace?
>>
>> --
>> Lubomir Kundrak (Red Hat Security Response Team)
>>
> 
> At the console not errors or something is shown.:(
> Where will be the logfiles written at the update process?
> 

So after run yum upgrade per hand, I see that there will be an race
condition at checking the deps.
I thing this is the reason why the update will fail:(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/1ae41dec/attachment.bin>

From lkundrak at redhat.com  Fri Nov  9 12:27:32 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Fri, 09 Nov 2007 13:27:32 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <47345027.3050607@gmx.net>
References: <4733676F.2000209@gmx.net>
	<1194599480.19966.0.camel@localhost.localdomain>
	<53387.192.168.0.1.1194600363.squirrel@homer>
	<47345027.3050607@gmx.net>
Message-ID: <1194611252.19966.6.camel@localhost.localdomain>


On Fri, 2007-11-09 at 13:18 +0100, Frank B?ttner wrote:
> frank-buettner at gmx.net schrieb:
> >> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
> >>> Hello,
> >>>
> >>> I have try to update an F7 installation to F8, but at dependency check
> >>> it freeze all ways at 26%.
> >>> It happens in the text and gui mode.
> >>> anaconda use 100% CPU and 97% of all memory.
> >>>
> >>> Idear how get out, what goes wrong?
> >> Tried looking at the log if there's anything suspicious there? Tried
> >> strace?
> >>
> >> --
> >> Lubomir Kundrak (Red Hat Security Response Team)
> >>
> > 
> > At the console not errors or something is shown.:(
> > Where will be the logfiles written at the update process?
> > 
> 
> So after run yum upgrade per hand, I see that there will be an race
> condition at checking the deps.
> I thing this is the reason why the update will fail:(

A 'race condition'?
Could you please be more specific or post a log from yum, prefferably
with some higher debug level?

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nphilipp at redhat.com  Fri Nov  9 12:28:13 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 09 Nov 2007 13:28:13 +0100
Subject: Obligatory Airplane! Quote; 1 Day until Fedora 8
In-Reply-To: <1194573529.2860.7.camel@localhost.localdomain>
References: <cf79c1c0711070625x7ea0f75fgdc4ecb251dd4ff02@mail.gmail.com>
	<1194573529.2860.7.camel@localhost.localdomain>
Message-ID: <1194611293.9672.31.camel@gibraltar.str.redhat.com>


On Fri, 2007-11-09 at 12:58 +1100, Rodd Clarkson wrote:
> For those outside the US, 'Airplane!' might have been released as
> 'Flying High!'

"Die unglaubliche Reise in einem verr?ckten Flugzeug" beats all other
titles of that movie.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From twoerner at redhat.com  Fri Nov  9 12:36:24 2007
From: twoerner at redhat.com (Thomas Woerner)
Date: Fri, 09 Nov 2007 13:36:24 +0100
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
Message-ID: <47345448.1060705@redhat.com>

Kelly Miller wrote:
> Well, now that F8 is approaching release, I wanted to bring up the
> possibility of updating the configuration utilities again.  I'd be
> willing to work on such a project (fixing the frontend problems so the
> utilities could be used without X, etc.), but I'm not entirely
> familiar with all the options covered by the utilities (for example,
> I've never used the cluster management or bootloader editor systems,
> and I'm not completely familiar with all of the configuration files
> here).  First of all, is there a preferred language for development
> like this?  I've actually done very little to no Python development
> (though I've done development in similar RAD languages like Ruby, Java
> and C# so I'm familiar with the general concepts), but I'll give it a
> shot in Python if that's preferred.  Secondly, is there a decent
> resource for covering some of the configuration files required by the
> programs?
> 

Hello Kelly,


There is already work ongoing. The project name is system-config. If you 
want to know more about this, please have a look at 
http://fedoraproject.org/wiki/SystemConfig. Yet, the wiki-pages are not 
complete, but they should reflect the desired way to go.

Currently there is some review going on for the existing tools 
altogether with building up the base classes and functions for the new 
framework (in an early stage). A big problem is the text interface, 
because there is no ui library, which can be used as a drop-in without 
big modifications in the ui itself and the config tools, that provides 
the needed widgets and functionality.

As there is lots of work to do, every helping hand is welcome.

There will be an own email list shortly. You can also join the irc 
channel #system-config on irc.freenode.net. If you are interested in 
participating in this project, feel free to contact us in the irc channel.


Thanks,
Thomas



From frank-buettner at gmx.net  Fri Nov  9 12:47:15 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Fri, 09 Nov 2007 13:47:15 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <1194611252.19966.6.camel@localhost.localdomain>
References: <4733676F.2000209@gmx.net>	<1194599480.19966.0.camel@localhost.localdomain>	<53387.192.168.0.1.1194600363.squirrel@homer>	<47345027.3050607@gmx.net>
	<1194611252.19966.6.camel@localhost.localdomain>
Message-ID: <473456D3.8020506@gmx.net>

Lubomir Kundrak schrieb:
> On Fri, 2007-11-09 at 13:18 +0100, Frank B?ttner wrote:
>> frank-buettner at gmx.net schrieb:
>>>> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
>>>>> Hello,
>>>>>
>>>>> I have try to update an F7 installation to F8, but at dependency check
>>>>> it freeze all ways at 26%.
>>>>> It happens in the text and gui mode.
>>>>> anaconda use 100% CPU and 97% of all memory.
>>>>>
>>>>> Idear how get out, what goes wrong?
>>>> Tried looking at the log if there's anything suspicious there? Tried
>>>> strace?
>>>>
>>>> --
>>>> Lubomir Kundrak (Red Hat Security Response Team)
>>>>
>>> At the console not errors or something is shown.:(
>>> Where will be the logfiles written at the update process?
>>>
>> So after run yum upgrade per hand, I see that there will be an race
>> condition at checking the deps.
>> I thing this is the reason why the update will fail:(
> 
> A 'race condition'?
> Could you please be more specific or post a log from yum, prefferably
> with some higher debug level?
> 
> Thanks,
Yes, I try to find out witch packages must be removed to get it work.
I think the problem is, that there are very much packages with wrong
versions tag. (*.fc6.*,*.fc7.*)

After remove this packages temporally via rpm -e --nodeps
the upgrade to F8 will work. After the upgrade I reinstall it with yum
install.

avahi qt-config vim-X11 compat-wxGTK26 glib-devel xsupplicant NetworkManager
pcre-devel openofice.org-base  openoffice.org-emailmerge
gnome-python2-gtksourceview openoffice.org-pyuno python-imaging-tk
openoffice.org-javafilter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/fd34e416/attachment.bin>

From valent.turkovic at gmail.com  Fri Nov  9 12:51:27 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 9 Nov 2007 13:51:27 +0100
Subject: java-plugin not working in F8
In-Reply-To: <47344B46.6070604@mharris.ca>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
Message-ID: <64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>

On Nov 9, 2007 12:57 PM, Mike A. Harris <mharris at mharris.ca> wrote:
> Mike Chambers wrote:
> > On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> >> Hi,
> >>
> >> I installed java plugin via 'yum install java-plugin' and firefox
> >> still complains that plugin is not installed...
> >> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
> >
> > Just install the java-icedtea-plugin (just look for icedtea) from Fedora
> > and it will work just fine.
> >
> > Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
> > as well?
>
> I'm running F8/x86_64 and haven't manually installed any Java stuff yet,
> just whatever might have been installed by anaconda by default.  Up
> until now I hadn't visited any web pages with Java on them.
>
> A lot of people have been having problems with Java it seems, and so I
> decided to try to get it to work myself.  I google searched for a "Java
> test", went to the Sun page, and it just worked automatically already,
> presumeably with iced-tea, which I assume was installed for me already
> by anaconda.  I went to a variety of other Java websites to test it out
> and have had no problems at all so far.  All Java sites work in firefox
> for me automatically.
>
> As mentioned above, I haven't had to install anything, configure
> anything, or do anything manual for this to work, it just works out of
> the box on x86_64, at least for me.
>
> I can only assume that the people having the problems either:
>
> 1) Are coming from an upgrade of a previous OS release
> or
> 2) Have Sun, IBM, or some other Java installed already, or are trying to
> install some other Java
> 3) Have upgraded and didn't get iced-tea by default perhaps.
>
> Anyhow, worst case scenario -> do a fresh OS install and Java seems to
> work in firefox right out of the box.  ;o)

I only installed java-plugin, I already had java installed
out-of-the-box in this fresh Fedora 8 Gnome Live CD install.

I tested one java page prior to installing java-plugin and it said
that java wasn't installed, after instalation of java-plugin I now
tested it again with following pages:
http://www.javatester.org/
http://www.java.com/en/download/help/testvm.xml

and both say I don't have java plugin installed.

Any other ideas?

Valent.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Fri Nov  9 12:54:22 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 9 Nov 2007 13:54:22 +0100
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
	<64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
Message-ID: <64b14b300711090454q67f9278ao5718b3f414018a72@mail.gmail.com>

When I type "about:plugins" in firefox I see the following plugins installed:

NPAPI Plugins Wrapper 0.9.91.5
Totem Web Browser Plugin 2.20.1
Helix DNA Plugin: RealPlayer G2 Plug-In Compatible (compatible; Totem)
Windows Media Player Plug-in 10 (compatible; Totem)
DivX(R) Web Player
QuickTime Plug-in 7.2.0

and I also instaled this one:
Shockwave Flash

Should java be listed here?

Valent.
-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From mkevac at gmail.com  Fri Nov  9 12:55:06 2007
From: mkevac at gmail.com (Kevac Marko)
Date: Fri, 9 Nov 2007 15:55:06 +0300
Subject: pptp-linux (pptp) on a Fedora DVD
Message-ID: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>

Hello.

Here, in Russian Federation, 90% of home internet providers use PPTP
for the internet access.
So 80% of Fedora users from Russian Federation have same problem of
installing and configuring pptp client. It includes very unpleasant
"go to another box with internet connection, download rpm package, go
back and install it".

I don't know what situation is in another countries with pptp, but i
be very glad to see pptp client on a Fedora DVD.

So, questions are:
1. Why pptp package is still not there? Some license issues?
2. Will it be included in Fedora DVD?
3. How can i help?

-- 
Sincerely yours, Kevac Marko



From opensource at till.name  Fri Nov  9 12:59:56 2007
From: opensource at till.name (Till Maas)
Date: Fri, 09 Nov 2007 13:59:56 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071108070626.7764f8e9@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108070626.7764f8e9@redhat.com>
Message-ID: <200711091400.00643.opensource@till.name>

On Do November 8 2007, Jesse Keating wrote:
> On Thu, 8 Nov 2007 11:08:19 +0100
>
> Adam Tkac <atkac at redhat.com> wrote:
> > But I know really better
> > workflows which cannot be used with CVS.
>
> Can you outline what kind of better workflow you'd like to see?

Afaik, git and hg (and maybe other modern vcs) would make comaintaining 
packages a lot easier, because the comaintainer can work on their copy of a 
package and then submit it to the main maintainer and then the main 
maintainer can verify it and commit it to the official repository, where 
packages are built from.

Also it would be nice, if it was easier to sync branches in the vcs or only 
use one branch for all stable distributions or even all, when there is no 
need for several branches. E.g. many of my packages use identical specs for 
all branches, because the packages are so simple, that there are no big 
changes between new releases. Or changes that may break a lot.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/37f2348b/attachment.sig>

From jonathan at jonmasters.org  Fri Nov  9 13:06:30 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Fri, 09 Nov 2007 08:06:30 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
Message-ID: <1194613590.3255.10.camel@perihelion>

On Fri, 2007-11-09 at 03:24 +0100, Mark wrote:

> Today is my first day in Fedora 8 (like probably a lot of people) and
> when i want to play a movie i get codec buddy which is absolutely
> fine! But now the misleading part comes. I live in Europe. for me it's
> not illegal to install the "gstreamer-bad-plugins" or just packages
> that get me mpeg/xvid/divx/aac/any_codec support and yet codec buddy
> gives me only payed options. I didn't start using fedora a few years
> ago to start paying for codecs!
> 
> Now my idea to get this better is to make codec buddy location
> specific. When you install fedora you select the country where you
> live. If codec buddy uses that information than it can point me to the
> right direction where i can get my codecs for free. I ujnderstand that
> Fedora can't include those codecs in there own repositories but
> wouldn't it be possible to make a community driven (codec) repository
> that contains all the packages that are not allowed in the USA but are
> in EU (probably everywhere EXCEPT the USA). Fedora at least has to
> notify the users that paying isn't needed if you don't live in the
> USA!!

IANAL, but the European situation is still subject to re-interpretation
in the future, and it's certainly far more fine-grained than US v.s EU.
in any case. I think the language could do with being clear, however
there's only so much that can be explained in dialog box real estate.

Jon.




From j.w.r.degoede at hhs.nl  Fri Nov  9 13:14:36 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 09 Nov 2007 14:14:36 +0100
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>	<1194607695.4630.1.camel@scrappy.miketc.com>	<47344B46.6070604@mharris.ca>
	<64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
Message-ID: <47345D3C.5000406@hhs.nl>

Valent Turkovic wrote:
> On Nov 9, 2007 12:57 PM, Mike A. Harris <mharris at mharris.ca> wrote:
>> Mike Chambers wrote:
>>> On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
>>>> Hi,
>>>>
>>>> I installed java plugin via 'yum install java-plugin' and firefox
>>>> still complains that plugin is not installed...
>>>> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
>>> Just install the java-icedtea-plugin (just look for icedtea) from Fedora
>>> and it will work just fine.
>>>
>>> Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
>>> as well?
>> I'm running F8/x86_64 and haven't manually installed any Java stuff yet,
>> just whatever might have been installed by anaconda by default.  Up
>> until now I hadn't visited any web pages with Java on them.
>>
>> A lot of people have been having problems with Java it seems, and so I
>> decided to try to get it to work myself.  I google searched for a "Java
>> test", went to the Sun page, and it just worked automatically already,
>> presumeably with iced-tea, which I assume was installed for me already
>> by anaconda.  I went to a variety of other Java websites to test it out
>> and have had no problems at all so far.  All Java sites work in firefox
>> for me automatically.
>>
>> As mentioned above, I haven't had to install anything, configure
>> anything, or do anything manual for this to work, it just works out of
>> the box on x86_64, at least for me.
>>
>> I can only assume that the people having the problems either:
>>
>> 1) Are coming from an upgrade of a previous OS release
>> or
>> 2) Have Sun, IBM, or some other Java installed already, or are trying to
>> install some other Java
>> 3) Have upgraded and didn't get iced-tea by default perhaps.
>>
>> Anyhow, worst case scenario -> do a fresh OS install and Java seems to
>> work in firefox right out of the box.  ;o)
> 
> I only installed java-plugin, I already had java installed
> out-of-the-box in this fresh Fedora 8 Gnome Live CD install.
> 
> I tested one java page prior to installing java-plugin and it said
> that java wasn't installed, after instalation of java-plugin I now
> tested it again with following pages:
> http://www.javatester.org/
> http://www.java.com/en/download/help/testvm.xml
> 
> and both say I don't have java plugin installed.
> 
> Any other ideas?
> 

Repeating myself:

Run mozilla-plugin-config (once, as root)


Regards,

Hans



From kzak at redhat.com  Fri Nov  9 13:18:56 2007
From: kzak at redhat.com (Karel Zak)
Date: Fri, 9 Nov 2007 14:18:56 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <rpud05xk7i.ln2@hubmaier.ceplovi.cz>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108232500.GZ2871@petra.dvoda.cz>
	<1194596620.6250.43.camel@vespa.kabelta.loc>
	<rpud05xk7i.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071109131856.GE2871@petra.dvoda.cz>

On Fri, Nov 09, 2007 at 01:01:31PM +0100, Matej Cepl wrote:
> On Fri, 09 Nov 2007 09:23:40 +0100, Tomas Mraz scripst:
> > The problems, the reasons why such script do not exist yet, here are
> > many - people having different prefered DVCS with different feature
> > sets, different prefered workflow when rebasing, etc. etc.
> > 
> > How we can obtain such scripts? Only when some developer who already
> > uses a DVCS interacting with the pkgs CVS tree writes them and publishes
> > them. Of course they would be useful only to people who use the same
> > DVCS and have similar workflow.
> 
> http://wiki.darcs.net/DarcsWiki/Tailor/VersionOne

 We don't talk about a bridge between CVS and DVCS. We need a way how
 convert src.rpm to real source code tree that is managed by DVCS.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From lists at dresco.co.uk  Fri Nov  9 13:22:58 2007
From: lists at dresco.co.uk (Jon Escombe)
Date: Fri, 9 Nov 2007 13:22:58 +0000 (GMT)
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090454q67f9278ao5718b3f414018a72@mail.gmail.com>
Message-ID: <21607069.141194614578456.JavaMail.root@epia.dresco.co.uk>


----- "Valent Turkovic" <valent.turkovic at gmail.com> wrote:
> When I type "about:plugins" in firefox I see the following plugins
> installed:
> 
> NPAPI Plugins Wrapper 0.9.91.5
> Totem Web Browser Plugin 2.20.1
> Helix DNA Plugin: RealPlayer G2 Plug-In Compatible (compatible;
> Totem)
> Windows Media Player Plug-in 10 (compatible; Totem)
> DivX(R) Web Player
> QuickTime Plug-in 7.2.0
> 
> and I also instaled this one:
> Shockwave Flash
> 
> Should java be listed here?
> 
> Valent.
> -- 

The IcedTea plugin didn't work for me out of the box either, but uninstalling the nspluginwrapper RPM did the trick here.. ( java only appeared in about:plugins after I did this). Strangely however, it stayed working after I reinstalled nspluginwrapper, but by that point there had been both firefox & nspluginwrapper updates..

Regards,
Jon



From paul at city-fan.org  Fri Nov  9 13:25:26 2007
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 09 Nov 2007 13:25:26 +0000
Subject: pptp-linux (pptp) on a Fedora DVD
In-Reply-To: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
References: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
Message-ID: <47345FC6.6000304@city-fan.org>

Kevac Marko wrote:
> Hello.
> 
> Here, in Russian Federation, 90% of home internet providers use PPTP
> for the internet access.
> So 80% of Fedora users from Russian Federation have same problem of
> installing and configuring pptp client. It includes very unpleasant
> "go to another box with internet connection, download rpm package, go
> back and install it".
> 
> I don't know what situation is in another countries with pptp, but i
> be very glad to see pptp client on a Fedora DVD.
> 
> So, questions are:
> 1. Why pptp package is still not there? Some license issues?

If there was a license issue, it wouldn't be in Fedora at all.

> 2. Will it be included in Fedora DVD?
> 3. How can i help?

I use pptp to connect to my ADSL provider, as do many people throughout 
Europe. I think it's a reasonable request to add this small package to 
the default spin. Raising the issue here is a good start.

Paul.



From j.w.r.degoede at hhs.nl  Fri Nov  9 11:53:06 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 09 Nov 2007 12:53:06 +0100
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090347s6989f48n90ee8b367bd89b74@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>	<1194607695.4630.1.camel@scrappy.miketc.com>
	<64b14b300711090347s6989f48n90ee8b367bd89b74@mail.gmail.com>
Message-ID: <47344A22.2040203@hhs.nl>

Valent Turkovic wrote:
> On Nov 9, 2007 12:28 PM, Mike Chambers <mike at miketc.com> wrote:
>> On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
>>> Hi,
>>>
>>> I installed java plugin via 'yum install java-plugin' and firefox
>>> still complains that plugin is not installed...
>>> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
>> Just install the java-icedtea-plugin (just look for icedtea) from Fedora
>> and it will work just fine.
>>
>> Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
>> as well?
> 
> AFAIK java-plugin is the same as java-icedtea-plugin
> 
> look for your self:
> 
> # yum search icedtea
> java-1.7.0-icedtea-plugin.i586 : IcedTea Web Browser Plugin
> 
> java-1.7.0-icedtea-devel.i586 : IcedTea Development Environment
> java-1.7.0-icedtea-javadoc.i586 : IcedTea API Documentation
> java-1.7.0-icedtea-demo.i586 : IcedTea Demos
> java-1.7.0-icedtea-src.i586 : IcedTea Source Bundle
> java-1.7.0-icedtea.i586 : IcedTea Runtime Environment
> java-1.7.0-icedtea-plugin.i586 : IcedTea Web Browser Plugin
> java-1.7.0-icedtea.i586 : IcedTea Runtime Environment
> 
> # yum install java-1.7.0-icedtea-plugin
> Setting up Install Process
> Parsing package install arguments
> Package java-1.7.0-icedtea-plugin - 1.7.0.0-0.19.b21.snapshot.fc8.i586
> is already installed.
> Nothing to do
> 
> 

The trick is to run "mozilla-plugin-config" once as root, this sets up 
nspluginwrapper to find the plugin and possibly other plugins too.

We need to document and fix this, this should be done automagically.

Regards,

Hans



From Christian.Iseli at licr.org  Fri Nov  9 13:32:35 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Fri, 9 Nov 2007 14:32:35 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <473456D3.8020506@gmx.net>
References: <4733676F.2000209@gmx.net>
	<1194599480.19966.0.camel@localhost.localdomain>
	<53387.192.168.0.1.1194600363.squirrel@homer>
	<47345027.3050607@gmx.net>
	<1194611252.19966.6.camel@localhost.localdomain>
	<473456D3.8020506@gmx.net>
Message-ID: <20071109143235.3a57b793@ludwig-alpha.unil.ch>

On Fri, 09 Nov 2007 13:47:15 +0100, Frank B?ttner wrote:
> Yes, I try to find out witch packages must be removed to get it work.
> I think the problem is, that there are very much packages with wrong
> versions tag. (*.fc6.*,*.fc7.*)

I seem to be hitting the same problem upgrading my F-7 laptop.

So far, I have removed java-1.5.0-gcj and the whole openoffice stack,
but still no-go...

					Christian



From valent.turkovic at gmail.com  Fri Nov  9 13:33:40 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 9 Nov 2007 14:33:40 +0100
Subject: java-plugin not working in F8
In-Reply-To: <47345D3C.5000406@hhs.nl>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
	<64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
	<47345D3C.5000406@hhs.nl>
Message-ID: <64b14b300711090533q26a6be38x10dbaad775f1fd4c@mail.gmail.com>

On Nov 9, 2007 2:14 PM, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>
> Valent Turkovic wrote:
> > On Nov 9, 2007 12:57 PM, Mike A. Harris <mharris at mharris.ca> wrote:
> >> Mike Chambers wrote:
> >>> On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> >>>> Hi,
> >>>>
> >>>> I installed java plugin via 'yum install java-plugin' and firefox
> >>>> still complains that plugin is not installed...
> >>>> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
> >>> Just install the java-icedtea-plugin (just look for icedtea) from Fedora
> >>> and it will work just fine.
> >>>
> >>> Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
> >>> as well?
> >> I'm running F8/x86_64 and haven't manually installed any Java stuff yet,
> >> just whatever might have been installed by anaconda by default.  Up
> >> until now I hadn't visited any web pages with Java on them.
> >>
> >> A lot of people have been having problems with Java it seems, and so I
> >> decided to try to get it to work myself.  I google searched for a "Java
> >> test", went to the Sun page, and it just worked automatically already,
> >> presumeably with iced-tea, which I assume was installed for me already
> >> by anaconda.  I went to a variety of other Java websites to test it out
> >> and have had no problems at all so far.  All Java sites work in firefox
> >> for me automatically.
> >>
> >> As mentioned above, I haven't had to install anything, configure
> >> anything, or do anything manual for this to work, it just works out of
> >> the box on x86_64, at least for me.
> >>
> >> I can only assume that the people having the problems either:
> >>
> >> 1) Are coming from an upgrade of a previous OS release
> >> or
> >> 2) Have Sun, IBM, or some other Java installed already, or are trying to
> >> install some other Java
> >> 3) Have upgraded and didn't get iced-tea by default perhaps.
> >>
> >> Anyhow, worst case scenario -> do a fresh OS install and Java seems to
> >> work in firefox right out of the box.  ;o)
> >
> > I only installed java-plugin, I already had java installed
> > out-of-the-box in this fresh Fedora 8 Gnome Live CD install.
> >
> > I tested one java page prior to installing java-plugin and it said
> > that java wasn't installed, after instalation of java-plugin I now
> > tested it again with following pages:
> > http://www.javatester.org/
> > http://www.java.com/en/download/help/testvm.xml
> >
> > and both say I don't have java plugin installed.
> >
> > Any other ideas?
> >
>
> Repeating myself:
>
> Run mozilla-plugin-config (once, as root)
>

Jup, you were right.

Everything works ok now, but why isn't this automatically done?!?
Should this be posted as a bug?

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From stransky at redhat.com  Fri Nov  9 13:37:16 2007
From: stransky at redhat.com (Martin Stransky)
Date: Fri, 09 Nov 2007 14:37:16 +0100
Subject: java-plugin not working in F8
In-Reply-To: <47344A22.2040203@hhs.nl>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>	<1194607695.4630.1.camel@scrappy.miketc.com>	<64b14b300711090347s6989f48n90ee8b367bd89b74@mail.gmail.com>
	<47344A22.2040203@hhs.nl>
Message-ID: <4734628C.5060002@redhat.com>

It's fixed in the latest firefox/nspluginwrapper update for F8.

Hans de Goede wrote:
> The trick is to run "mozilla-plugin-config" once as root, this sets up 
> nspluginwrapper to find the plugin and possibly other plugins too.
> 
> We need to document and fix this, this should be done automagically.
> 
> Regards,
> 
> Hans
> 



From katzj at redhat.com  Fri Nov  9 14:02:55 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 09 Nov 2007 09:02:55 -0500
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <1194616975.20915.31.camel@localhost.localdomain>

On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
> 
> Idear how get out, what goes wrong?

Hmm... I wonder if this is the same loop case that got fixed in the yum
depsolving code a day or two ago.

For anyone hitting this, can you use the update image[1] at
http://katzj.fedorapeople.org/updates-f8-yumloop.img and see if it
helps?

Jeremy

[1] http://fedoraproject.org/wiki/Anaconda/Updates



From katzj at redhat.com  Fri Nov  9 14:05:22 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 09 Nov 2007 09:05:22 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071109095230.GB2871@petra.dvoda.cz>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>
	<20071109095230.GB2871@petra.dvoda.cz>
Message-ID: <1194617122.20915.33.camel@localhost.localdomain>

On Fri, 2007-11-09 at 10:52 +0100, Karel Zak wrote:
>  I think the best way (for Fedora project) is Tom Mraz's suggestion:
>  use stupid central CVS as a storage for patch files and locally use
>  scripts that convert these patches as code to/from real DVCS.

FWIW, I think that seeing some people work on some various
implementations of this could be a really useful way forward on the
whole SCM discussion.  It gives us a good way to test out new workflows
and see how they really _do_ work without forcing everyone to change at
once.  And then when we get to something markedly better, we can revisit
the idea of changing out the canonical method.

Jeremy



From mcepl at redhat.com  Fri Nov  9 14:07:55 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 09 Nov 2007 15:07:55 +0100
Subject: When will be CVS replaced by modern version control system?
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<20071108100819.GA12141@evileye.englab.brq.redhat.com>
	<20071108232500.GZ2871@petra.dvoda.cz>
	<1194596620.6250.43.camel@vespa.kabelta.loc>
	<rpud05xk7i.ln2@hubmaier.ceplovi.cz>
	<20071109131856.GE2871@petra.dvoda.cz>
Message-ID: <slrnfj8qdr.684.mcepl@hubmaier.ceplovi.cz>

On 2007-11-09, 13:18 GMT, Karel Zak wrote:
> We don't talk about a bridge between CVS and DVCS. We need 
> a way how convert src.rpm to real source code tree that is 
> managed by DVCS.

OK, then I don't get it -- what's wrong with git-{cvs,svn,bzr,hg} 
except that some of these tools are missing? And ocassionaly some 
tag (or branch) would be done in the Fedora git repository from 
which everybody would clone?

Matej



From Christian.Iseli at licr.org  Fri Nov  9 14:21:59 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Fri, 9 Nov 2007 15:21:59 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <20071109143235.3a57b793@ludwig-alpha.unil.ch>
References: <4733676F.2000209@gmx.net>
	<1194599480.19966.0.camel@localhost.localdomain>
	<53387.192.168.0.1.1194600363.squirrel@homer>
	<47345027.3050607@gmx.net>
	<1194611252.19966.6.camel@localhost.localdomain>
	<473456D3.8020506@gmx.net>
	<20071109143235.3a57b793@ludwig-alpha.unil.ch>
Message-ID: <20071109152159.580320e5@ludwig-alpha.unil.ch>

On Fri, 9 Nov 2007 14:32:35 +0100, Christian Iseli wrote:
> I seem to be hitting the same problem upgrading my F-7 laptop.
> 
> So far, I have removed java-1.5.0-gcj and the whole openoffice stack,
> but still no-go...

Ok, it seems "rpm -e NetworkManager" does the trick...

Cheers,
					Christian



From bdwheele at indiana.edu  Fri Nov  9 14:23:41 2007
From: bdwheele at indiana.edu (Wheeler,  Brian David)
Date: Fri,  9 Nov 2007 09:23:41 -0500
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <1194616975.20915.31.camel@localhost.localdomain>
References: <4733676F.2000209@gmx.net>
	<1194616975.20915.31.camel@localhost.localdomain>
Message-ID: <20071109092341.unrqkltn4c0084os@webmail.iu.edu>

It looks like its stopping at the same place.

Brian


Quoting Jeremy Katz <katzj at redhat.com>:

> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
>> I have try to update an F7 installation to F8, but at dependency check
>> it freeze all ways at 26%.
>> It happens in the text and gui mode.
>> anaconda use 100% CPU and 97% of all memory.
>>
>> Idear how get out, what goes wrong?
>
> Hmm... I wonder if this is the same loop case that got fixed in the yum
> depsolving code a day or two ago.
>
> For anyone hitting this, can you use the update image[1] at
> http://katzj.fedorapeople.org/updates-f8-yumloop.img and see if it
> helps?
>
> Jeremy
>
> [1] http://fedoraproject.org/wiki/Anaconda/Updates
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>






From rms at 1407.org  Fri Nov  9 14:26:07 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Fri, 9 Nov 2007 14:26:07 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <1194613590.3255.10.camel@perihelion>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
Message-ID: <20071109142607.GB6603@roque.1407.org>

On Fri, Nov 09, 2007 at 08:06:30AM -0500, Jon Masters wrote:
> On Fri, 2007-11-09 at 03:24 +0100, Mark wrote:
> 
> > Today is my first day in Fedora 8 (like probably a lot of people) and
> > when i want to play a movie i get codec buddy which is absolutely
> > fine! But now the misleading part comes. I live in Europe. for me it's
> > not illegal to install the "gstreamer-bad-plugins" or just packages
> > that get me mpeg/xvid/divx/aac/any_codec support and yet codec buddy
> > gives me only payed options. I didn't start using fedora a few years
> > ago to start paying for codecs!
> > 
> > Now my idea to get this better is to make codec buddy location
> > specific. When you install fedora you select the country where you
> > live. If codec buddy uses that information than it can point me to the
> > right direction where i can get my codecs for free. I ujnderstand that
> > Fedora can't include those codecs in there own repositories but
> > wouldn't it be possible to make a community driven (codec) repository
> > that contains all the packages that are not allowed in the USA but are
> > in EU (probably everywhere EXCEPT the USA). Fedora at least has to
> > notify the users that paying isn't needed if you don't live in the
> > USA!!
> 
> IANAL, but the European situation is still subject to re-interpretation
> in the future, and it's certainly far more fine-grained than US v.s EU.
> in any case. I think the language could do with being clear, however
> there's only so much that can be explained in dialog box real estate.

Every patent is valid by default. You have to go to court to prove it's
a software patent, hence invalid.

This has been estimated to cost many tens of thousands of Euros to do,
so Codec Buddy is not being misleading.

You either have a patent license, or proved in court that it is an
invalid patent, other than that, you risk bein in a patent infringement
situation, which is something I believe Red Hat definitely doesn't want
to fall into.

Rui

-- 
This statement is false.
Today is Pungenday, the 21st day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?



From mharris at mharris.ca  Fri Nov  9 14:34:11 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Fri, 09 Nov 2007 09:34:11 -0500
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
	<64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
Message-ID: <47346FE3.1030608@mharris.ca>

Valent Turkovic wrote:
> On Nov 9, 2007 12:57 PM, Mike A. Harris <mharris at mharris.ca> wrote:
>> Mike Chambers wrote:
>>> On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
>>>> Hi,
>>>>
>>>> I installed java plugin via 'yum install java-plugin' and firefox
>>>> still complains that plugin is not installed...
>>>> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
>>> Just install the java-icedtea-plugin (just look for icedtea) from Fedora
>>> and it will work just fine.
>>>
>>> Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
>>> as well?
>> I'm running F8/x86_64 and haven't manually installed any Java stuff yet,
>> just whatever might have been installed by anaconda by default.  Up
>> until now I hadn't visited any web pages with Java on them.
>>
>> A lot of people have been having problems with Java it seems, and so I
>> decided to try to get it to work myself.  I google searched for a "Java
>> test", went to the Sun page, and it just worked automatically already,
>> presumeably with iced-tea, which I assume was installed for me already
>> by anaconda.  I went to a variety of other Java websites to test it out
>> and have had no problems at all so far.  All Java sites work in firefox
>> for me automatically.
>>
>> As mentioned above, I haven't had to install anything, configure
>> anything, or do anything manual for this to work, it just works out of
>> the box on x86_64, at least for me.
>>
>> I can only assume that the people having the problems either:
>>
>> 1) Are coming from an upgrade of a previous OS release
>> or
>> 2) Have Sun, IBM, or some other Java installed already, or are trying to
>> install some other Java
>> 3) Have upgraded and didn't get iced-tea by default perhaps.
>>
>> Anyhow, worst case scenario -> do a fresh OS install and Java seems to
>> work in firefox right out of the box.  ;o)
> 
> I only installed java-plugin, I already had java installed
> out-of-the-box in this fresh Fedora 8 Gnome Live CD install.

I don't have anything called "java-plugin" installed, but Java seems to 
be working fine:

pts/7 mharris at hammer:~$ rpm -q java-plugin
package java-plugin is not installed


> I tested one java page prior to installing java-plugin and it said
> that java wasn't installed, after instalation of java-plugin I now
> tested it again with following pages:
> http://www.javatester.org/
> http://www.java.com/en/download/help/testvm.xml
> 
> and both say I don't have java plugin installed.

Both of those pages work for me and correctly detect "Java 1.7.0 from 
Sun Microsystems".  Again, note that I did not install Sun Java, so this 
message is coming from iced-tea presumeably.  Here's a query of my 
system showing what packages containing 'java' in the name that are 
installed:

pts/7 mharris at hammer:~$ rpm -qa | grep java | sort
glib-java-0.2.6-8.fc7
java-1.5.0-gcj-1.5.0.0-17.fc8
java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8
java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8
java_cup-0.10-0.k.6jpp.1
tzdata-java-2007i-1.fc8


> Any other ideas?

If you have any proprietary Java packages installed, remove them, and if 
you are missing any of the above packages, install them.  Then restart 
firefox, or reboot.


-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From bdwheele at indiana.edu  Fri Nov  9 14:37:06 2007
From: bdwheele at indiana.edu (Wheeler,  Brian David)
Date: Fri,  9 Nov 2007 09:37:06 -0500
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <20071109152159.580320e5@ludwig-alpha.unil.ch>
References: <4733676F.2000209@gmx.net>
	<1194599480.19966.0.camel@localhost.localdomain>
	<53387.192.168.0.1.1194600363.squirrel@homer>
	<47345027.3050607@gmx.net>
	<1194611252.19966.6.camel@localhost.localdomain>
	<473456D3.8020506@gmx.net>
	<20071109143235.3a57b793@ludwig-alpha.unil.ch>
	<20071109152159.580320e5@ludwig-alpha.unil.ch>
Message-ID: <20071109093706.dzichfwg0004sgg8@webmail.iu.edu>

Hmm.  I did an yum erase NetworkManager and then tried the installation 
again and it hangs in the same place.

Brian

Quoting Christian Iseli <Christian.Iseli at licr.org>:

> On Fri, 9 Nov 2007 14:32:35 +0100, Christian Iseli wrote:
>> I seem to be hitting the same problem upgrading my F-7 laptop.
>>
>> So far, I have removed java-1.5.0-gcj and the whole openoffice stack,
>> but still no-go...
>
> Ok, it seems "rpm -e NetworkManager" does the trick...
>
> Cheers,
> 					Christian
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>





From rc040203 at freenet.de  Fri Nov  9 14:42:56 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 09 Nov 2007 15:42:56 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194608262.9672.30.camel@gibraltar.str.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<1194608262.9672.30.camel@gibraltar.str.redhat.com>
Message-ID: <1194619376.9673.520.camel@mccallum.corsepiu.local>

On Fri, 2007-11-09 at 12:37 +0100, Nils Philippsen wrote:

> - With a DVCS, we could put the several Fedora/EPEL versions into
> branches and merge between them. 
We could do the same if fedora's package CVS would have used real CVS
branches instead of branch directories.

Ralf




From abo at kth.se  Fri Nov  9 14:51:24 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Fri, 09 Nov 2007 15:51:24 +0100
Subject: openid support for f9?
In-Reply-To: <1194548034.3271.94.camel@localhost.localdomain>
References: <fgut5p$2b1$1@ger.gmane.org>
	<1194537678.25638.12.camel@localhost6.localdomain6>
	<1194544452.3271.54.camel@localhost.localdomain>
	<20071108180927.GA12738@devserv.devel.redhat.com>
	<1194548034.3271.94.camel@localhost.localdomain>
Message-ID: <1194619884.26035.53.camel@home.alexander.bostrom.net>

tor 2007-11-08 klockan 13:53 -0500 skrev Simo Sorce:

> Exactly, but yet you need to represent identity in term of UIDs and GIDs
> in the POSIX world, hence why I am slowly advocating for *local* mapping
> tables. Network mapping tables simply do not work.

I totally agree with you here.

> Think
> agaion of a USB pen drive formatted ext2, you need at least a file where
> you map the UID used on the disk to the identity used (be it an email or
> a kerberos principal or whatever you can think of to represent an
> identity) and for groups too. 

Yes, the design problem is how to store the mapping database for
different types of file systems and what to use as global identities
(unless the file system has support for them natively). Probably you'd
want to support a number of different schemes. OpenID would be one,
Kerberos another, Mugshot account, PKI and GPG key IDs, uuids, and so
on.

You'd need to think about policies and who to trust, but it's hard to
see how it could come out any worse than the current non-system.

/abo



From notting at redhat.com  Fri Nov  9 13:56:21 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 9 Nov 2007 08:56:21 -0500
Subject: java-plugin not working in F8
In-Reply-To: <47345D3C.5000406@hhs.nl>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
	<64b14b300711090451n5954cb7cx265cd90034df5bc9@mail.gmail.com>
	<47345D3C.5000406@hhs.nl>
Message-ID: <20071109135621.GA21895@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> Repeating myself:
>
> Run mozilla-plugin-config (once, as root)

Furthermore, we're working on getting this fixed to automatically work
in an update.

Bill



From abo at kth.se  Fri Nov  9 15:00:18 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Fri, 09 Nov 2007 16:00:18 +0100
Subject: openid support for f9?
In-Reply-To: <fgut5p$2b1$1@ger.gmane.org>
References: <fgut5p$2b1$1@ger.gmane.org>
Message-ID: <1194620418.26035.61.camel@home.alexander.bostrom.net>

tor 2007-11-08 klockan 06:50 -0500 skrev Neal Becker:
> It seems that openid is moving along.  Maybe f9 can integrate openid as an
> SSO solution?

Stuff to do:

      * Browser support/plugin to help with managing them.
      * Help with signing up to an OpenID identity provider, integrated
        with above. (Mugshot, Online Desktop?)
      * Support in packaged web apps.

Uhm... What else?

As always, the mantra is work upstream, making sure it can be packaged
well.

/abo



From Christian.Iseli at licr.org  Fri Nov  9 15:02:13 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Fri, 9 Nov 2007 16:02:13 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <20071109093706.dzichfwg0004sgg8@webmail.iu.edu>
References: <4733676F.2000209@gmx.net>
	<1194599480.19966.0.camel@localhost.localdomain>
	<53387.192.168.0.1.1194600363.squirrel@homer>
	<47345027.3050607@gmx.net>
	<1194611252.19966.6.camel@localhost.localdomain>
	<473456D3.8020506@gmx.net>
	<20071109143235.3a57b793@ludwig-alpha.unil.ch>
	<20071109152159.580320e5@ludwig-alpha.unil.ch>
	<20071109093706.dzichfwg0004sgg8@webmail.iu.edu>
Message-ID: <20071109160213.07b97b42@ludwig-alpha.unil.ch>

On Fri,  9 Nov 2007 09:37:06 -0500, Wheeler,  Brian David wrote:
> Hmm.  I did an yum erase NetworkManager and then tried the installation 
> again and it hangs in the same place.

Argh.  /me removed OpenOffice, java-gcj, compat-*, and a bunch of
*-devel (mostly those with no .fc7 in the release tag).

I also ran
package-cleanup --orphans
and removed those (after doing a yum update to the latest F-7 stuff).

I did not remove livna stuff, FWIW...

Good luck,
					Christian



From janina at rednote.net  Fri Nov  9 15:03:49 2007
From: janina at rednote.net (Janina Sajka)
Date: Fri, 9 Nov 2007 10:03:49 -0500
Subject: Inaccessible Post-GDM But Pre-Desktop Dialogs
In-Reply-To: <1194281489.31380.8.camel@localhost.localdomain>
References: <20071105162134.GD6342@rednote.net>
	<1194281489.31380.8.camel@localhost.localdomain>
Message-ID: <20071109150349.GF6342@rednote.net>

Jeremy Katz writes:
> On Mon, 2007-11-05 at 11:21 -0500, Janina Sajka wrote:
> > There is at least one potential dialog that breaks accessibility after a
> > user logs in, but before Orca (or Gok) loads. I became aware of this one
> > demonstrating Orca in Italian to a CompSci professor at a recont F/OSS
> > symposium in Florence.
> > 
> > The dialog we came across advises of available updates. It does not talk
> > (in my case). So, it's an accessibility show-stopper.
> > 
> > Generically speaking, all such potential pop-ups need to be vetted for
> > accessibility. What about the one that says: "you're not connected to
> > the Internet," for instance?
> 
> They're actually from the same source.  The problem here is that things
> in the notification area (puplet, nm-applet, etc) are all started by
> gnome-session as is the panel, orca, etc.  If one of the notification
> area applets wants to show a notification bubble, they just do a
> libnotify call.  But there's no way to ensure that the panel is up (and
> thus that their icon is actually visible) much less if other things like
> a11y technologies are running.
> 
> We really need a way to serialize some of this.  Unfortunately, that'll
> end up coming at the cost of a (slightly) slower login time
> 
So, it sounds like the proper fix is upstream in Gnome development? But,
what's the short term work around for the Fedora 8 user? Right now it's a
crap shoot whether one can access the desktop with Orca, or not.
Clearly, it may often be possible to go run a 'yum update,' but it won't
always be possible to do that.

Janina

> Jeremy
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From martin.sourada at seznam.cz  Fri Nov  9 13:16:13 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Fri, 09 Nov 2007 14:16:13 +0100
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
Message-ID: <1194614173.30993.2.camel@pc-notebook>

On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> Hi,
> 
Hi Valent,

> I installed java plugin via 'yum install java-plugin' and firefox
> still complains that plugin is not installed...
> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
> 
> 
> $ ls -al /usr/lib/mozilla/plugins/*
> lrwxrwxrwx 1 root root    34 2007-11-09 11:21
> /usr/lib/mozilla/plugins/libjavaplugin.so ->
> /etc/alternatives/libjavaplugin.so
> -rwxr-xr-x 1 root root 54276 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-basic-plugin.so
> -rw-r--r-- 1 root root   167 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-basic-plugin.xpt
> -rwxr-xr-x 1 root root 86040 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-complex-plugin.so
> -rw-r--r-- 1 root root  3227 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-complex-plugin.xpt
> -rwxr-xr-x 1 root root 90780 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so
> -rw-r--r-- 1 root root  4312 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-gmp-plugin.xpt
> -rwxr-xr-x 1 root root 53732 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-mully-plugin.so
> -rw-r--r-- 1 root root   167 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-mully-plugin.xpt
> -rwxr-xr-x 1 root root 77572 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so
> -rw-r--r-- 1 root root  2211 2007-10-17 16:19
> /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.xpt
> 
> $ ls -al /etc/alternatives/libjavaplugin.so
> lrwxrwxrwx 1 root root 55 2007-11-09 11:21
> /etc/alternatives/libjavaplugin.so ->
> /usr/lib/jvm/jre-1.7.0-icedtea/lib/i386/gcjwebplugin.so
> 
> What is the issue?
> 
> I have only one java site can you please give me a few more links just
> to make sure it is not the issue with the site I'm visiting.
> 
> Thank you,
> Valent.
> 
> -- 
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
> 

As I have the same output as you and my java is working and in
about:plugins it's listed as 

GCJ Web Browser Plugin 1.4
        File name: gcjwebplugin.so
        The GCJ Web Browser Plugin executes Java applets.
        
I wonder why yours does not. Did you restarted firefox? 

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/91ba39a0/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Nov  9 15:17:25 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 10 Nov 2007 00:17:25 +0900
Subject: ppc builder of plague buildsys hanging?
Message-ID: <47347A05.3020801@ioa.s.u-tokyo.ac.jp>

Hello.

Would someone check ppc builder of plague buildsys?
It seems that this builder is not accepting any build requests.

Regards,
Mamoru



From nphilipp at redhat.com  Fri Nov  9 16:17:54 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 09 Nov 2007 17:17:54 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194619376.9673.520.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<1194608262.9672.30.camel@gibraltar.str.redhat.com>
	<1194619376.9673.520.camel@mccallum.corsepiu.local>
Message-ID: <1194625074.9672.39.camel@gibraltar.str.redhat.com>


On Fri, 2007-11-09 at 15:42 +0100, Ralf Corsepius wrote:
> On Fri, 2007-11-09 at 12:37 +0100, Nils Philippsen wrote:
> 
> > - With a DVCS, we could put the several Fedora/EPEL versions into
> > branches and merge between them. 
> We could do the same if fedora's package CVS would have used real CVS
> branches instead of branch directories.

"The use of [branching and merging with CVS] cripples the mind
[...]" (sorry, Edsger). I like walking with my feet instead of having to
use crutches.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From loupgaroublond at gmail.com  Fri Nov  9 16:29:16 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 9 Nov 2007 11:29:16 -0500
Subject: Smolt and software information
Message-ID: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>

Hey list,

There's been a bit of conversation lately in #smolt about collecting
information about partitioning, hard drive sizes, and most
importantly, file system types.  I feel it might be just a touch out
of scope for smolt, since so far our policy has been hardware only.
The reason this appeals to me the most is if there is any interest in
file system type used, this would be a good place to collect those
statistics.  Personally, when we go make changes to the 'smolt
protocol', we'll leave out the mount point used, so no one knows how
big any given partition is on a particular machine.  I have two
questions for everyone.

1) Is this useful?  Is this something that we feel the community would
like to see, and that it isn't something that is deserving of a second
statistics aggregator (like a popularity contest for packages would
be)

2) Are there any privacy concerns?  Remember smolt is voluntary, and
so far we don't link any information to machines other than a single
UUID that is privately stored.  Mainly, the implementation will
probably be just simply parsing through /etc/fstab.

Thanks in advance for any input you all are willing to share.

Cheers,
Yaakov



From janina at rednote.net  Fri Nov  9 16:33:46 2007
From: janina at rednote.net (Janina Sajka)
Date: Fri, 9 Nov 2007 11:33:46 -0500
Subject: Firefox 3
In-Reply-To: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
Message-ID: <20071109163346.GG6342@rednote.net>

Now that we're at the beginning of F-9 development, I'd like to
resurrect this question regarding Firefox 3. Can we expect FF3 in F-9?
It is slated for release during the development cycle, as I understand
it.

Meanwhile, I can attest the a11y support in FF3, which I have been
building from Takanori San's SRPMS. Hopefully, the yelp and devhelp
conflicts will now also prove historical.

Janina

MATSUURA Takanori writes:
> Hi all,
> 
> I put firefox-trunk SRPM based on current fedora rawhide one at
> http://homepage2.nifty.com/t-matsuu/install-memo/fc/
> 
> Notice: this package breaks the dependency against devhelp and yelp.
> 
> Janina Sajka <janina at rednote.net> wrote:
> >Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
> >near ready for prime time, but I have a compelling reason to start using
> >ff3 fairly soon and would rather install from rpm, of course.
> >
> >BTW: My compelling reason is that FF3 will contain a11y support that
> >should prove superior to any yet seen on any platform. Fingers crossed,
> >etc ...
> 
> 
> MATSUURA Takanori
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From walters at redhat.com  Fri Nov  9 16:50:06 2007
From: walters at redhat.com (Colin Walters)
Date: Fri, 09 Nov 2007 11:50:06 -0500
Subject: Firefox 3
In-Reply-To: <20071109163346.GG6342@rednote.net>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net>
Message-ID: <1194627006.6328.1.camel@space-ghost.verbum.private>


On Fri, 2007-11-09 at 11:33 -0500, Janina Sajka wrote:
> Now that we're at the beginning of F-9 development, I'd like to
> resurrect this question regarding Firefox 3. Can we expect FF3 in F-9?

Yes, I think it makes sense.  We should toss up a Feature page for it
probably.  Or perhaps combine it with a XULRunner feature, because
it will make getting Fx3 in significantly easier if other packages are
converted to xulrunner to avoid breaking them.




From lsof at nodata.co.uk  Fri Nov  9 16:53:07 2007
From: lsof at nodata.co.uk (nodata)
Date: Fri, 09 Nov 2007 17:53:07 +0100
Subject: Smolt and software information
In-Reply-To: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
Message-ID: <1194627187.2686.8.camel@sb-home>


Am Freitag, den 09.11.2007, 11:29 -0500 schrieb Yaakov Nemoy:
> Hey list,
> 
> There's been a bit of conversation lately in #smolt about collecting
> information about partitioning, hard drive sizes, and most
> importantly, file system types.  I feel it might be just a touch out
> of scope for smolt, since so far our policy has been hardware only.
> The reason this appeals to me the most is if there is any interest in
> file system type used, this would be a good place to collect those
> statistics.  Personally, when we go make changes to the 'smolt
> protocol', we'll leave out the mount point used, so no one knows how
> big any given partition is on a particular machine.  I have two
> questions for everyone.
> 
> 1) Is this useful?  Is this something that we feel the community would
> like to see, and that it isn't something that is deserving of a second
> statistics aggregator (like a popularity contest for packages would
> be)
> 
> 2) Are there any privacy concerns?  Remember smolt is voluntary, and

A loaded question!

> so far we don't link any information to machines other than a single
> UUID that is privately stored.

Privately stored, but not under any form of access control. Smolt lets
the non-admin of a box submit a smolt profile.

Besides, didn't RHN do this? Wasn't one of the reasons for Satellite
server being invented because people don't want their own servers giving
out this kind of information? If yes, then the same reasons apply to
smolt.

Sometimes it *is* useful to give out a smolt UUID to let someone (e.g. a
kernel developer) get at hardware information for a bug report. That's
okay. If you then "extended" smolt to give out more information (it
won't stop here btw), then some of those people won't provide that
information any more, unless they can choose which information they
send.

>   Mainly, the implementation will
> probably be just simply parsing through /etc/fstab.
> 
> Thanks in advance for any input you all are willing to share.
> 
> Cheers,
> Yaakov
> 



From orion at cora.nwra.com  Fri Nov  9 16:57:38 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 09 Nov 2007 09:57:38 -0700
Subject: LSB init scripts - automatic start
In-Reply-To: <200711081730.lA8HUk1G017806@cvs-int.fedora.redhat.com>
References: <200711081730.lA8HUk1G017806@cvs-int.fedora.redhat.com>
Message-ID: <47349182.50800@cora.nwra.com>

Jon Ciesla (limb) wrote:
> Author: limb
> 
> Update of /cvs/pkgs/rpms/moodle/F-8
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17700
> 
> Modified Files:
> 	moodle.init moodle.spec sources 
> Log Message:
> Bump to upstream, fix initscript for bugfix 246986.
> 
> 
> 
> Index: moodle.init
> ===================================================================
> RCS file: /cvs/pkgs/rpms/moodle/F-8/moodle.init,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- moodle.init	13 Apr 2007 22:54:23 -0000	1.2
> +++ moodle.init	8 Nov 2007 17:30:09 -0000	1.3
> @@ -10,6 +10,17 @@
>  # description:  Enable the Moodle cron job
>  #
>  
> +### BEGIN INIT INFO
> +# Provides: lsb-moodle
> +# Required-Start: $local_fs $network $remote_fs
> +# Required-Stop: $local_fs $network $remote_fs
> +# Default-Start:  2 3 4 5
> +# Default-Stop: 0 1 6
> +# Short-Description: start and stop Moodle cron job
> +# Description: Moodle is an online courseware system
> +### END INIT INFO

I believe this (having Default-Start) will enable the service by 
default.  Previously, most packages ("Extras") are not supposed to be 
enabled by default (have - in chkconfig line).  Please be aware.





-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From pemboa at gmail.com  Fri Nov  9 17:13:58 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 9 Nov 2007 11:13:58 -0600
Subject: Possible Replacements for the system-config-* utilities?
In-Reply-To: <1194606508.9672.11.camel@gibraltar.str.redhat.com>
References: <a785db460711070655v4e463002p762445b03e5df33f@mail.gmail.com>
	<20071108164823.GA26392@jadzia.bu.edu>
	<1194606508.9672.11.camel@gibraltar.str.redhat.com>
Message-ID: <16de708d0711090913m3d3ec5b7n9ef5106417708232@mail.gmail.com>

On Nov 9, 2007 5:08 AM, Nils Philippsen <nphilipp at redhat.com> wrote:
> On Thu, 2007-11-08 at 11:48 -0500, Matthew Miller wrote:
> > On Wed, Nov 07, 2007 at 09:55:08AM -0500, Kelly Miller wrote:
> > > here).  First of all, is there a preferred language for development
> > > like this?  I've actually done very little to no Python development
> >
> > Almost certainly Python.
> >
> > The key reason these utilties need rewriting is to separate the user
>
> They don't need rewriting, they need refactoring. There's too much logic
> in the tools already to be able to make throwing it all away and
> beginning from scratch feasible without breaking things. There's also a
> lot of wheel-reinvention in the tools as they are today, i.e. a
> potential for code consolidation between the tools.

Agreed. We don't have time to do them from scratch, other tools need
to be written:
http://fedoraproject.org/wiki/SystemConfig/Missing

I would like to see, and I am willing to work on, all these tools
being able to function on remote machines via SSH. I can provide
details of my idea if anyone is interested.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From debarshi.ray at gmail.com  Fri Nov  9 17:17:51 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Fri, 9 Nov 2007 22:47:51 +0530
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
Message-ID: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>

Right now I was trying to build the proxyknife package (review:
https://bugzilla.redhat.com/show_bug.cgi?id=322091) and found that
while Koji builds it successfully
(http://koji.fedoraproject.org/koji/taskinfo?taskID=231772), I could
not use rpmbuild to build it locally. It would fail in the middle of
the %build stanza.

The trick to solve this was to:
$ unset CFLAGS
$ CXXFLAGS
...since I usually set them as:
export CFLAGS=-I/home/rishi/include
export CXXFLAGS=-I/home/rishi/include

So would it be a good idea to unset these two variables by default,
the way we unset DISPLAY, at the beginning of the rpmbuild process?

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From loupgaroublond at gmail.com  Fri Nov  9 17:18:27 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 9 Nov 2007 12:18:27 -0500
Subject: Smolt and software information
In-Reply-To: <1194627187.2686.8.camel@sb-home>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194627187.2686.8.camel@sb-home>
Message-ID: <7f692fec0711090918s170ba1bcsafa96edae45eba14@mail.gmail.com>

On Nov 9, 2007 11:53 AM, nodata <lsof at nodata.co.uk> wrote:
> > 2) Are there any privacy concerns?  Remember smolt is voluntary, and
>
> A loaded question!
>
> > so far we don't link any information to machines other than a single
> > UUID that is privately stored.
>
> Sometimes it *is* useful to give out a smolt UUID to let someone (e.g. a
> kernel developer) get at hardware information for a bug report. That's
> okay. If you then "extended" smolt to give out more information (it
> won't stop here btw), then some of those people won't provide that
> information any more, unless they can choose which information they
> send.

We do know about some of the standing privacy concerns, but
implementing the solutions is more a time issue.  I have winter break
from school in about six weeks, so I'll have a month of cold weather
to inspire some good smolt hacking.  Until then, I'm just going over
an idea brought up.

Access controls on the UUID script - Probably a trivial patch to make
it root readable only.  I should probably file a bug on it.

Selective information submission - Probably also a good idea, though
the implementation is less than trivial.

Giving out a secondary UUID that has access controls applied - In our
bug reports, the solution is far from trivial, and the number one
thing to do as soon as the semester is over.

We're always listening for ideas about security and privacy, of
course, if you have more good points. :)

Cheers,
Yaakov



From jfrieben at gmx.de  Fri Nov  9 17:26:03 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Fri, 09 Nov 2007 18:26:03 +0100
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
In-Reply-To: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
References: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
Message-ID: <20071109172603.211120@gmx.net>

> The trick to solve this was to:
> $ unset CFLAGS
> $ CXXFLAGS
> ...since I usually set them as:
> export CFLAGS=-I/home/rishi/include
> export CXXFLAGS=-I/home/rishi/include
> 
> So would it be a good idea to unset these two variables by default,
> the way we unset DISPLAY, at the beginning of the rpmbuild process?

I suppose that setting the appropriate environment variable CPPFLAGS instead of abusing C[XX]FLAGS for this purpose would have been sufficient to avoid your problems.
-- 
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger



From lsof at nodata.co.uk  Fri Nov  9 17:29:31 2007
From: lsof at nodata.co.uk (nodata)
Date: Fri, 09 Nov 2007 18:29:31 +0100
Subject: Smolt and software information
In-Reply-To: <7f692fec0711090918s170ba1bcsafa96edae45eba14@mail.gmail.com>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194627187.2686.8.camel@sb-home>
	<7f692fec0711090918s170ba1bcsafa96edae45eba14@mail.gmail.com>
Message-ID: <1194629371.2686.12.camel@sb-home>


Am Freitag, den 09.11.2007, 12:18 -0500 schrieb Yaakov Nemoy:
> On Nov 9, 2007 11:53 AM, nodata <lsof at nodata.co.uk> wrote:
> > > 2) Are there any privacy concerns?  Remember smolt is voluntary, and
> >
> > A loaded question!
> >
> > > so far we don't link any information to machines other than a single
> > > UUID that is privately stored.
> >
> > Sometimes it *is* useful to give out a smolt UUID to let someone (e.g. a
> > kernel developer) get at hardware information for a bug report. That's
> > okay. If you then "extended" smolt to give out more information (it
> > won't stop here btw), then some of those people won't provide that
> > information any more, unless they can choose which information they
> > send.
> 
> We do know about some of the standing privacy concerns, but
> implementing the solutions is more a time issue.  I have winter break
> from school in about six weeks, so I'll have a month of cold weather
> to inspire some good smolt hacking.  Until then, I'm just going over
> an idea brought up.
> 
> Access controls on the UUID script - Probably a trivial patch to make
> it root readable only.  I should probably file a bug on it.

Done: https://bugzilla.redhat.com/show_bug.cgi?id=373211

> 
> Selective information submission - Probably also a good idea, though
> the implementation is less than trivial.
> 
> Giving out a secondary UUID that has access controls applied - In our
> bug reports, the solution is far from trivial, and the number one
> thing to do as soon as the semester is over.
> 
> We're always listening for ideas about security and privacy, of
> course, if you have more good points. :)
> 
> Cheers,
> Yaakov
> 



From jspaleta at gmail.com  Fri Nov  9 17:30:24 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 9 Nov 2007 08:30:24 -0900
Subject: Firefox 3
In-Reply-To: <1194627006.6328.1.camel@space-ghost.verbum.private>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net>
	<1194627006.6328.1.camel@space-ghost.verbum.private>
Message-ID: <604aa7910711090930g58eda282p5d01c358ab462654@mail.gmail.com>

On Nov 9, 2007 7:50 AM, Colin Walters <walters at redhat.com> wrote:
> Yes, I think it makes sense.  We should toss up a Feature page for it
> probably.  Or perhaps combine it with a XULRunner feature, because
> it will make getting Fx3 in significantly easier if other packages are
> converted to xulrunner to avoid breaking them.

I wanted xulrunner so bad leading up to f8.. i was tempted to build a
time machine, go to the future, package xulrunner and ff3 and learn
who was going to win the world series, then bring the packages back
with me to the present and make a hefty vegas bet.

-jef



From debarshi.ray at gmail.com  Fri Nov  9 17:39:05 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Fri, 9 Nov 2007 23:09:05 +0530
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
In-Reply-To: <20071109172603.211120@gmx.net>
References: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
	<20071109172603.211120@gmx.net>
Message-ID: <3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>

> I suppose that setting the appropriate environment variable CPPFLAGS
> instead of abusing C[XX]FLAGS for this purpose would have been sufficient
> to avoid your problems.

Yes, I should have used CPPFLAGS to set the include directory. Thanks
for pointing out.

However it still bothers me that rpmbuild takes the environment's
CFLAGS and CXXFLAGS instead of forcing its own. Since Koji normally
uses:
CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions ...
CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions ..
FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions ...
would it not be better if rpmbuild used the same values and ignored
the user's environment?

If a package, indeed, needed some custom value for CFLAGS, CXXFLAGS
and FFLAGS, I believe that can be done through the spec file itself
and the user's environment setting would not be required.

What do you think?

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From limb at jcomserv.net  Fri Nov  9 18:49:59 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 9 Nov 2007 12:49:59 -0600 (CST)
Subject: LSB init scripts - automatic start
In-Reply-To: <47349182.50800@cora.nwra.com>
References: <200711081730.lA8HUk1G017806@cvs-int.fedora.redhat.com>
	<47349182.50800@cora.nwra.com>
Message-ID: <28791.63.85.68.164.1194634199.squirrel@mail.jcomserv.net>


> Jon Ciesla (limb) wrote:
>> Author: limb
>>
>> Update of /cvs/pkgs/rpms/moodle/F-8
>> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17700
>>
>> Modified Files:
>> 	moodle.init moodle.spec sources
>> Log Message:
>> Bump to upstream, fix initscript for bugfix 246986.
>>
>>
>>
>> Index: moodle.init
>> ===================================================================
>> RCS file: /cvs/pkgs/rpms/moodle/F-8/moodle.init,v
>> retrieving revision 1.2
>> retrieving revision 1.3
>> diff -u -r1.2 -r1.3
>> --- moodle.init	13 Apr 2007 22:54:23 -0000	1.2
>> +++ moodle.init	8 Nov 2007 17:30:09 -0000	1.3
>> @@ -10,6 +10,17 @@
>>  # description:  Enable the Moodle cron job
>>  #
>>
>> +### BEGIN INIT INFO
>> +# Provides: lsb-moodle
>> +# Required-Start: $local_fs $network $remote_fs
>> +# Required-Stop: $local_fs $network $remote_fs
>> +# Default-Start:  2 3 4 5
>> +# Default-Stop: 0 1 6
>> +# Short-Description: start and stop Moodle cron job
>> +# Description: Moodle is an online courseware system
>> +### END INIT INFO
>
> I believe this (having Default-Start) will enable the service by
> default.  Previously, most packages ("Extras") are not supposed to be
> enabled by default (have - in chkconfig line).  Please be aware.
>

Should I alter Moodle to not start by default?  I assumed this setting
would mean that Moodle's service* would start on boot, not install.

I could do so, and add something to the documentation.


*cron job

>
>
>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  orion at cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com
>


-- 
novus ordo absurdum



From markg85 at gmail.com  Fri Nov  9 18:03:48 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 9 Nov 2007 19:03:48 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <20071109142607.GB6603@roque.1407.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
Message-ID: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>

Oke imagine one of the following cases:

1st:
I have a official Windows Vista home premium (sadly!!.. came with my
notebook) so in a way i've already payed for those patents. Now i want
to play the same file on Linux and than you have to buy a license on
it AGAIN!!?? Doesn't make any sense at all.

2nd:
If you live in the USA codec buddy isn't misleading at all.. that's
just the sad truth for the people in the USA. But for EU people it now
seems that they have to comply the USA law and have to buy the codecs
which they absolutely don't need to do. So for me in the EU it's
misleading. if i would have been in USA it would have been fine.

And is it illegal to say that "Repository X has the codec you want for
free. Click here to read the installation instructions" which than
points to a site hosted in the EU with the instructions. i can't
imagine that that's illegal in USA.

This really should be sorted out in a nice way for Fedora 9.



From notting at redhat.com  Fri Nov  9 18:06:53 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 9 Nov 2007 13:06:53 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
Message-ID: <20071109180653.GB4063@nostromo.devel.redhat.com>

Mark (markg85 at gmail.com) said: 
> 1st:
> I have a official Windows Vista home premium (sadly!!.. came with my
> notebook) so in a way i've already payed for those patents. Now i want
> to play the same file on Linux and than you have to buy a license on
> it AGAIN!!?? Doesn't make any sense at all.

By that logic:

I have a DVD player in my bedroom, that I paid for the patents to play
DVDs. I then want to add a DVD player in my living room. I have to
buy a license for those patents AGAIN!!?? Doesn't make any sense at all.

No one ever said the rights you got with your Windows install were
transferable.

Bill



From markg85 at gmail.com  Fri Nov  9 18:10:06 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 9 Nov 2007 19:10:06 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <20071109180653.GB4063@nostromo.devel.redhat.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109180653.GB4063@nostromo.devel.redhat.com>
Message-ID: <6e24a8e80711091010r3e18b764hc351d40234a6d26a@mail.gmail.com>

2007/11/9, Bill Nottingham <notting at redhat.com>:
> Mark (markg85 at gmail.com) said:
> > 1st:
> > I have a official Windows Vista home premium (sadly!!.. came with my
> > notebook) so in a way i've already payed for those patents. Now i want
> > to play the same file on Linux and than you have to buy a license on
> > it AGAIN!!?? Doesn't make any sense at all.
>
> By that logic:
>
> I have a DVD player in my bedroom, that I paid for the patents to play
> DVDs. I then want to add a DVD player in my living room. I have to
> buy a license for those patents AGAIN!!?? Doesn't make any sense at all.
>
> No one ever said the rights you got with your Windows install were
> transferable.
>
> Bill

You have a point there.
Anyway.. i hope you agree that it needs some changes for the next
fedora.. or even a update for the existing one.



From rms at 1407.org  Fri Nov  9 18:11:11 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Fri, 9 Nov 2007 18:11:11 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
Message-ID: <20071109181111.GF6603@roque.1407.org>

On Fri, Nov 09, 2007 at 07:03:48PM +0100, Mark wrote:
> And is it illegal to say that "Repository X has the codec you want for
> free. Click here to read the installation instructions" which than
> points to a site hosted in the EU with the instructions. i can't
> imagine that that's illegal in USA.

Yes it is. Search for DeCSS and the 2600 magazine.

Rui

-- 
Hail Eris!
Today is Pungenday, the 21st day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?



From david at lovesunix.net  Fri Nov  9 18:17:02 2007
From: david at lovesunix.net (David Nielsen)
Date: Fri, 09 Nov 2007 19:17:02 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
Message-ID: <1194632222.2989.8.camel@dawkins>


fre, 09 11 2007 kl. 19:03 +0100, skrev Mark:
> Oke imagine one of the following cases:

We have been over this before please search the archives, every case in
fact. 

Do you think we enjoy keeping media support from our users when we have
perfectly good implementations available under OSI approved licenses?

If there was a legal way to make this work, we would be doing it.

Pretty please, every 3 months someone posts the exact same 3 ideas you
did.. they are not new and they have been debated. I'm sorry but please
understand how frustrating it is to have to repeatedly have this debate.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/d900a965/attachment.sig>

From rc040203 at freenet.de  Fri Nov  9 18:17:38 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 09 Nov 2007 19:17:38 +0100
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
In-Reply-To: <3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>
References: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
	<20071109172603.211120@gmx.net>
	<3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>
Message-ID: <1194632258.9673.561.camel@mccallum.corsepiu.local>

On Fri, 2007-11-09 at 23:09 +0530, Debarshi 'Rishi' Ray wrote:

> However it still bothers me that rpmbuild takes the environment's
> CFLAGS and CXXFLAGS instead of forcing its own. Since Koji normally
> uses:
> CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions ...
> CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions ..
> FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions ...
> would it not be better if rpmbuild used the same values and ignored
> the user's environment?
No idea what you are talking about, rpmbuild sets them, and it's
rpmbuild which sets them inside of build systems.

May-be you don't have redhat-rpm-config installed?

> If a package, indeed, needed some custom value for CFLAGS, CXXFLAGS
> and FFLAGS, 
Packages are not supposed to override these flags, they are supposed to
use them.

Ralf





From jspaleta at gmail.com  Fri Nov  9 18:19:31 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 9 Nov 2007 09:19:31 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091010r3e18b764hc351d40234a6d26a@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109180653.GB4063@nostromo.devel.redhat.com>
	<6e24a8e80711091010r3e18b764hc351d40234a6d26a@mail.gmail.com>
Message-ID: <604aa7910711091019g6f87b6e3qa5ab14217acc49f5@mail.gmail.com>

On Nov 9, 2007 9:10 AM, Mark <markg85 at gmail.com> wrote:
> You have a point there.
> Anyway.. i hope you agree that it needs some changes for the next
> fedora.. or even a update for the existing one.

I'll meet you in Washington DC to talk to the US congress to change
the laws so we no longer have to worry about the complexity of
contributory infringement when we point people to resources outside of
our direct control. I'm sure if we shake congressional members hard
enough they will see the illogic of the situation.

-jef"No one sane will claim that the legal issues associated with
patents and contributory infringement follow any school of logic
informed by practicality, common sense or scientific methodology.
Trying to make sense of the situation in terms of what we can and
cannot using the logic of an engineer or a scientist simply will not
work and will only lead to personal despair, confusion, and drug
abuse. It's too late for me, but you still have a chance to save
yourself by choosing to focus on other areas that need improvement not
encumbered by legal issues."spaleta



From Lam at Lam.pl  Fri Nov  9 18:21:46 2007
From: Lam at Lam.pl (Leszek Matok)
Date: Fri, 9 Nov 2007 19:21:46 +0100
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
In-Reply-To: <3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>
References: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
	<20071109172603.211120@gmx.net>
	<3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>
Message-ID: <20071109192146.35f50d9e@pensja.lam.pl>

Dnia 2007-11-09, o godz. 23:09:05 "Debarshi 'Rishi' Ray"
<debarshi.ray at gmail.com> napisa?(a):

> If a package, indeed, needed some custom value for CFLAGS, CXXFLAGS
> and FFLAGS, I believe that can be done through the spec file itself
> and the user's environment setting would not be required.
I build RPM-s locally from time to time (or more often) and I have to admit,
using environment variables has saved me hours of spec file editing. Imagine
recompiling more than one srpm, more than one time, with different options
(like benchmarking -Os vs -O2 or something). You can easily alias rpm to
always clear the environment, won't that solve your problem without
introducing new problems to other users? :)

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/0e5907a7/attachment.sig>

From debarshi.ray at gmail.com  Fri Nov  9 18:26:53 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Fri, 9 Nov 2007 23:56:53 +0530
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
In-Reply-To: <1194632258.9673.561.camel@mccallum.corsepiu.local>
References: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
	<20071109172603.211120@gmx.net>
	<3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>
	<1194632258.9673.561.camel@mccallum.corsepiu.local>
Message-ID: <3170f42f0711091026s2e9829e2wc30dcbaa5a2a1782@mail.gmail.com>

> No idea what you are talking about, rpmbuild sets them, and it's
> rpmbuild which sets them inside of build systems.

Set those variables to something else (export CFLAGS=....) and then
run rpmbuild. rpmbuild will not override your settings.

> May-be you don't have redhat-rpm-config installed?

$ rpm -q redhat-rpm-config
redhat-rpm-config-9.0.1-1.fc8

-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov  9 18:37:53 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 9 Nov 2007 19:37:53 +0100
Subject: ppc builder of plague buildsys hanging?
In-Reply-To: <47347A05.3020801@ioa.s.u-tokyo.ac.jp>
References: <47347A05.3020801@ioa.s.u-tokyo.ac.jp>
Message-ID: <20071109193753.3753c798.mschwendt.tmp0701.nospam@arcor.de>

On Sat, 10 Nov 2007 00:17:25 +0900, Mamoru Tasaka wrote:

> Hello.
> 
> Would someone check ppc builder of plague buildsys?
> It seems that this builder is not accepting any build requests.

I've noticed it, too, but cannot reach any infrastructure admins
on IRC so far. The server is unavailable via ssh.

As a work-around I've started the plague-builder ppc1. It's
picking up the pending CVE fixes while I write this.



From jkeating at redhat.com  Fri Nov  9 18:48:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 9 Nov 2007 13:48:26 -0500
Subject: rawhide report: 20071109 changes
In-Reply-To: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
References: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
Message-ID: <20071109134826.334610c7@redhat.com>

On Fri, 9 Nov 2007 12:40:10 -0500
Build System <buildsys at redhat.com> wrote:

> rawhide report: 20071109 changes

THUMP!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/0ab01c3c/attachment.sig>

From jwilson at redhat.com  Fri Nov  9 18:49:28 2007
From: jwilson at redhat.com (Jarod Wilson)
Date: Fri, 09 Nov 2007 13:49:28 -0500
Subject: linux1394 and f8
In-Reply-To: <20071101044647.GA16429@puariko.nirvana>
References: <47288307.7060306@nostar.net>	<1193844283.10224.7.camel@localhost6.localdomain6>
	<20071101044647.GA16429@puariko.nirvana>
Message-ID: <4734ABB8.10205@redhat.com>

Axel Thimm wrote:
> On Wed, Oct 31, 2007 at 09:24:43AM -0600, Richi Plana wrote:
>> On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
>>> I am running 7.92, and I see that the new firewire stack is in place. 
>>> There is a page at the linux1394 wiki that suggests that kernel 
>>> packagers build the old stack into the kernel for the time being:
>>>
>>> http://wiki.linux1394.org/JujuMigration
>>>
>>> Any chance of this happenign for Fedora 8?
[...]
> Alternatively Fedora could ship a kernel with both modules and
> blacklist the old ones. So users would just need to adjust the
> blacklisting config and I would have less work to do :)

Yeah, in retrospect, we probably should have built both stacks and just
blacklisted the old one by default, and provided userspace bits
(basically just libraw1394) that could operate with both stacks...

That said, we're reasonably close to having ohci 1.0 controllers playing
nice w/the new stack. I just got back from lunch, diving back into the
code now, actually. :)

-- 
Jarod Wilson
jwilson at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/d55496cf/attachment.sig>

From frank-buettner at gmx.net  Fri Nov  9 18:53:06 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Fri, 09 Nov 2007 19:53:06 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <473456D3.8020506@gmx.net>
References: <4733676F.2000209@gmx.net>	<1194599480.19966.0.camel@localhost.localdomain>	<53387.192.168.0.1.1194600363.squirrel@homer>	<47345027.3050607@gmx.net>	<1194611252.19966.6.camel@localhost.localdomain>
	<473456D3.8020506@gmx.net>
Message-ID: <4734AC92.6040000@gmx.net>

Frank B?ttner schrieb:
> Lubomir Kundrak schrieb:
>> On Fri, 2007-11-09 at 13:18 +0100, Frank B?ttner wrote:
>>> frank-buettner at gmx.net schrieb:
>>>>> On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have try to update an F7 installation to F8, but at dependency check
>>>>>> it freeze all ways at 26%.
>>>>>> It happens in the text and gui mode.
>>>>>> anaconda use 100% CPU and 97% of all memory.
>>>>>>
>>>>>> Idear how get out, what goes wrong?
>>>>> Tried looking at the log if there's anything suspicious there? Tried
>>>>> strace?
>>>>>
>>>>> --
>>>>> Lubomir Kundrak (Red Hat Security Response Team)
>>>>>
>>>> At the console not errors or something is shown.:(
>>>> Where will be the logfiles written at the update process?
>>>>
>>> So after run yum upgrade per hand, I see that there will be an race
>>> condition at checking the deps.
>>> I thing this is the reason why the update will fail:(
>> A 'race condition'?
>> Could you please be more specific or post a log from yum, prefferably
>> with some higher debug level?
>>
>> Thanks,
> Yes, I try to find out witch packages must be removed to get it work.
> I think the problem is, that there are very much packages with wrong
> versions tag. (*.fc6.*,*.fc7.*)
> 
> After remove this packages temporally via rpm -e --nodeps
> the upgrade to F8 will work. After the upgrade I reinstall it with yum
> install.
> 
> avahi qt-config vim-X11 compat-wxGTK26 glib-devel xsupplicant NetworkManager
> pcre-devel openofice.org-base  openoffice.org-emailmerge
> gnome-python2-gtksourceview openoffice.org-pyuno python-imaging-tk
> openoffice.org-javafilter
> 
> 

Yes this has resolve it. Not nice, but it works.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/818f93e0/attachment.bin>

From choeger at cs.tu-berlin.de  Fri Nov  9 18:54:33 2007
From: choeger at cs.tu-berlin.de (=?UTF-8?B?Q2hyaXN0b3BoIEjDtmdlcg==?=)
Date: Fri, 09 Nov 2007 19:54:33 +0100
Subject: Monodevelop out of date
In-Reply-To: <1194558724.2836.17.camel@dawkins>
References: <473378C3.7000000@cs.tu-berlin.de>	<1194556361.2836.13.camel@dawkins>
	<47338198.5070807@cs.tu-berlin.de>
	<1194558724.2836.17.camel@dawkins>
Message-ID: <4734ACE9.2070404@cs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

do you have any idea what could be missing?

David Nielsen schrieb:
> tor, 08 11 2007 kl. 22:37 +0100, skrev Christoph H?ger:
>> Hi,
>>
>> I could not build your 0.16 package. It fails with
>>
>> ./src/Mono.Addins.Gui/Mono.Addins.Gui/AddinInstallerDialog.cs(40,35): 
>> error CS0246: The type or namespace name `PackageCollection' could not 
>> be found. Are you missing a using directive or an assembly reference?
>> ./src/Mono.Addins.Gui/Mono.Addins.Gui/AddinManagerDialog.cs(39,30): 
>> error CS0246: The type or namespace name `SetupService' could not be 
>> found. Are you missing a using directive or an assembly reference?
>>
>> although all buildrequirements are fulfilled.
> 
> hrmm that did not used to happen.. I promise once gmcs gets unfucked on
> x86_64 I'll get right back to my Fedora duties and I'll have a look at
> that.
> 
> Pain makes the world feel real.. bring it!
> 
> - David
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHNKzohMBO4cVSGS8RAhRlAJ9FjIDDtXqyDD3mpfgNAoyVa92MwQCeLrl4
fmVPi76m4rmdNOtGP/vXGRg=
=qdMo
-----END PGP SIGNATURE-----



From mharris at mharris.ca  Fri Nov  9 19:30:40 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Fri, 09 Nov 2007 14:30:40 -0500
Subject: rpmbuild: unset CFLAGS & CXXFLAGS ?
In-Reply-To: <20071109192146.35f50d9e@pensja.lam.pl>
References: <3170f42f0711090917s2738e755sff1c3913bcd38282@mail.gmail.com>
	<20071109172603.211120@gmx.net>
	<3170f42f0711090939v26ac128ct4484bf63a6ccf51@mail.gmail.com>
	<20071109192146.35f50d9e@pensja.lam.pl>
Message-ID: <4734B560.9010807@mharris.ca>

Leszek Matok wrote:
> Dnia 2007-11-09, o godz. 23:09:05 "Debarshi 'Rishi' Ray"
> <debarshi.ray at gmail.com> napisa?(a):
> 
>> If a package, indeed, needed some custom value for CFLAGS, CXXFLAGS
>> and FFLAGS, I believe that can be done through the spec file itself
>> and the user's environment setting would not be required.
> I build RPM-s locally from time to time (or more often) and I have to admit,
> using environment variables has saved me hours of spec file editing. Imagine
> recompiling more than one srpm, more than one time, with different options
> (like benchmarking -Os vs -O2 or something). You can easily alias rpm to
> always clear the environment, won't that solve your problem without
> introducing new problems to other users? :)

That can be done easily enough by rpm itself as well:

rpmbuild -ba --define 'optflags -O77 -funslide -funpotato' foo.spec

alias rpmgentoobuild='rpmbuild --define \'optflags -O77 -funslide\' '

then you can do:

rpmgentoobuild -ba foo.spec


Don't forget to pass the rice!


-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From markg85 at gmail.com  Fri Nov  9 19:36:53 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 9 Nov 2007 20:36:53 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <20071109181111.GF6603@roque.1407.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
Message-ID: <6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>

2007/11/9, Rui Miguel Silva Seabra <rms at 1407.org>:
> On Fri, Nov 09, 2007 at 07:03:48PM +0100, Mark wrote:
> > And is it illegal to say that "Repository X has the codec you want for
> > free. Click here to read the installation instructions" which than
> > points to a site hosted in the EU with the instructions. i can't
> > imagine that that's illegal in USA.
>
> Yes it is. Search for DeCSS and the 2600 magazine.
>
> Rui

Than i'm happy i don't live there.

2007/11/9, David Nielsen <david at lovesunix.net>:
>
> fre, 09 11 2007 kl. 19:03 +0100, skrev Mark:
> > Oke imagine one of the following cases:
>
> We have been over this before please search the archives, every case in
> fact.
>
> Do you think we enjoy keeping media support from our users when we have
> perfectly good implementations available under OSI approved licenses?
>
> If there was a legal way to make this work, we would be doing it.
>
> Pretty please, every 3 months someone posts the exact same 3 ideas you
> did.. they are not new and they have been debated. I'm sorry but please
> understand how frustrating it is to have to repeatedly have this debate.
>
> - David

I understand it completely... i just wish it wasn't working like this.
kinda limited democracy

2007/11/9, Jeff Spaleta <jspaleta at gmail.com>:
> On Nov 9, 2007 9:10 AM, Mark <markg85 at gmail.com> wrote:
> > You have a point there.
> > Anyway.. i hope you agree that it needs some changes for the next
> > fedora.. or even a update for the existing one.
>
> I'll meet you in Washington DC to talk to the US congress to change
> the laws so we no longer have to worry about the complexity of
> contributory infringement when we point people to resources outside of
> our direct control. I'm sure if we shake congressional members hard
> enough they will see the illogic of the situation.
>
> -jef"No one sane will claim that the legal issues associated with
> patents and contributory infringement follow any school of logic
> informed by practicality, common sense or scientific methodology.
> Trying to make sense of the situation in terms of what we can and
> cannot using the logic of an engineer or a scientist simply will not
> work and will only lead to personal despair, confusion, and drug
> abuse. It's too late for me, but you still have a chance to save
> yourself by choosing to focus on other areas that need improvement not
> encumbered by legal issues."spaleta

sooner or later even the USA will change his mind on those patents.
move fedora to The Netherlands (or any EU country) and all problems
are solved. would be a big boost for open source as well.



From sandeen at redhat.com  Fri Nov  9 19:54:32 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 09 Nov 2007 13:54:32 -0600
Subject: Smolt and software information
In-Reply-To: <1194627187.2686.8.camel@sb-home>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194627187.2686.8.camel@sb-home>
Message-ID: <4734BAF8.4060406@redhat.com>

nodata wrote:

>> 2) Are there any privacy concerns?  Remember smolt is voluntary, and
> 
> A loaded question!

:)  While I understand the privacy concerns, I don't think that choice
of filesystem is particularly more private than, say, choice to run
selinux, or default runlevel.  Do you have any privacy concerns directly
related to collecting this new (filesystem) information, aside from the
bigger picture that affects all data collected?

Thanks,
-Eric



From loupgaroublond at gmail.com  Fri Nov  9 19:58:39 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 9 Nov 2007 14:58:39 -0500
Subject: Smolt and software information
In-Reply-To: <4734BAF8.4060406@redhat.com>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194627187.2686.8.camel@sb-home> <4734BAF8.4060406@redhat.com>
Message-ID: <7f692fec0711091158p791899f1u5e5598e201ee71d4@mail.gmail.com>

On Nov 9, 2007 2:54 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> :)  While I understand the privacy concerns, I don't think that choice
> of filesystem is particularly more private than, say, choice to run
> selinux, or default runlevel.  Do you have any privacy concerns directly
> related to collecting this new (filesystem) information, aside from the
> bigger picture that affects all data collected?

nope, that's why I asked if anyone else has.

-Yaakov



From alexl at users.sourceforge.net  Fri Nov  9 20:25:21 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 09 Nov 2007 13:25:21 -0700
Subject: rawhide report: 20071109 changes
In-Reply-To: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com> (Build
	System's message of "Fri\, 9 Nov 2007 12\:40\:10 -0500")
References: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
Message-ID: <33y7d7xj2m.fsf@allele2.eebweb.arizona.edu>

>>>>> Build System  writes:

> New package Democracy Democracy Player

[...]

> Broken deps for i386
> ----------------------------------------------------------
>	Democracy - 0.9.5.1-11.fc8.i386 requires firefox = 0:2.0.0.5
>	Democracy - 0.9.5.1-11.fc8.i386 requires libboost_python.so.2

Democracy has been obsoleted by Miro, so it should not be in rawhide
anymore.  It is marked as a dead.package in CVS:

http://cvs.fedoraproject.org/viewcvs/rpms/Democracy/devel/

Alex



From rms at 1407.org  Fri Nov  9 20:31:42 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Fri, 9 Nov 2007 20:31:42 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
Message-ID: <20071109203142.GA6642@roque.1407.org>

On Fri, Nov 09, 2007 at 08:36:53PM +0100, Mark wrote:
> sooner or later even the USA will change his mind on those patents.
> move fedora to The Netherlands (or any EU country) and all problems
> are solved. would be a big boost for open source as well.

You don't get it, it wouldn't solve the problem.

You'd still have to go to the courts in order to prove that they are
software patents and as such invalid.

Do you have tens of thousands of Euros?

Rui

-- 
Fnord.
Today is Pungenday, the 21st day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?



From jkeating at redhat.com  Fri Nov  9 20:52:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 9 Nov 2007 15:52:42 -0500
Subject: rawhide report: 20071109 changes
In-Reply-To: <33y7d7xj2m.fsf@allele2.eebweb.arizona.edu>
References: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
	<33y7d7xj2m.fsf@allele2.eebweb.arizona.edu>
Message-ID: <20071109155242.4b6a97b0@redhat.com>

On Fri, 09 Nov 2007 13:25:21 -0700
Alex Lancaster <alexl at users.sourceforge.net> wrote:

> Democracy has been obsoleted by Miro, so it should not be in rawhide
> anymore.  It is marked as a dead.package in CVS:
> 
> http://cvs.fedoraproject.org/viewcvs/rpms/Democracy/devel/

Blocked.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/1271b287/attachment.sig>

From dgboles at gmail.com  Fri Nov  9 21:04:27 2007
From: dgboles at gmail.com (David Boles)
Date: Fri, 09 Nov 2007 16:04:27 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<1194613590.3255.10.camel@perihelion>	<20071109142607.GB6603@roque.1407.org>	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
Message-ID: <4734CB5B.1040605@gmail.com>

on 11/9/2007 2:36 PM, Mark wrote:
> 2007/11/9, Rui Miguel Silva Seabra <rms at 1407.org>:
>> On Fri, Nov 09, 2007 at 07:03:48PM +0100, Mark wrote:
>> Yes it is. Search for DeCSS and the 2600 magazine.
>>
>> Rui
> 
> Than i'm happy i don't live there.
> 
> 2007/11/9, David Nielsen <david at lovesunix.net>:
>> fre, 09 11 2007 kl. 19:03 +0100, skrev Mark:
>> We have been over this before please search the archives, every case in
>> fact.
>>
>> Do you think we enjoy keeping media support from our users when we have
>> perfectly good implementations available under OSI approved licenses?
>>
>> If there was a legal way to make this work, we would be doing it.
>>
>> Pretty please, every 3 months someone posts the exact same 3 ideas you
>> did.. they are not new and they have been debated. I'm sorry but please
>> understand how frustrating it is to have to repeatedly have this debate.
>>
>> - David
> 
> I understand it completely... i just wish it wasn't working like this.
> kinda limited democracy
> 
> 2007/11/9, Jeff Spaleta <jspaleta at gmail.com>:
>> On Nov 9, 2007 9:10 AM, Mark <markg85 at gmail.com> wrote:
>> I'll meet you in Washington DC to talk to the US congress to change
>> the laws so we no longer have to worry about the complexity of
>> contributory infringement when we point people to resources outside of
>> our direct control. I'm sure if we shake congressional members hard
>> enough they will see the illogic of the situation.
>>
>> -jef"No one sane will claim that the legal issues associated with
>> patents and contributory infringement follow any school of logic
>> informed by practicality, common sense or scientific methodology.
>> Trying to make sense of the situation in terms of what we can and
>> cannot using the logic of an engineer or a scientist simply will not
>> work and will only lead to personal despair, confusion, and drug
>> abuse. It's too late for me, but you still have a chance to save
>> yourself by choosing to focus on other areas that need improvement not
>> encumbered by legal issues."spaleta
> 
> sooner or later even the USA will change his mind on those patents.
> move fedora to The Netherlands (or any EU country) and all problems
> are solved. would be a big boost for open source as well.


I can *not* stand it any longer!

You want a KDE based RPM type Linux distro? You want proprietary software
so you can listen to your music? And so that you can watch your videos?
And the video drivers to do that with and with which to play your games?

You want *all* the proprietary software at one general site? One with
mirrors? Not 'officially' supported but well known and sometimes spoken of
in public? With the RPMs made mostly by the same people that work for the
distro? You want your disto, as described above, to be 'free' of US patent
problems and the 'elitist Fedora attitude'?

Are you people blind? Hardheaded? Or just plain stupid?

Please switch to Mandriva. Please. Save those of us that actually like
Fedora, the way it is provided to us by these fine Fedora people, from the
endless whining posts that go on and on and on. All because *you* actually
have to make an effort to use a geek OS such as Linux.

-- 

  David




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/d7906dec/attachment.sig>

From notting at redhat.com  Fri Nov  9 21:37:06 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 9 Nov 2007 16:37:06 -0500
Subject: LSB init scripts - automatic start
In-Reply-To: <28791.63.85.68.164.1194634199.squirrel@mail.jcomserv.net>
References: <200711081730.lA8HUk1G017806@cvs-int.fedora.redhat.com>
	<47349182.50800@cora.nwra.com>
	<28791.63.85.68.164.1194634199.squirrel@mail.jcomserv.net>
Message-ID: <20071109213706.GA2098@nostromo.devel.redhat.com>

Jon Ciesla (limb at jcomserv.net) said: 
> Should I alter Moodle to not start by default?  I assumed this setting
> would mean that Moodle's service* would start on boot, not install.

Correct, but it's still generally done that services don't start by
default.

Bill



From braden at endoframe.com  Fri Nov  9 22:02:44 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 09 Nov 2007 17:02:44 -0500
Subject: Bad arg to %patch
Message-ID: <4734D904.30705@endoframe.com>

Since installing F8, I'm seeing this at the beginning of 'make tag' and 
'make build' operations:

   error: line 101: Bad arg to %patch: %build

   error: line 101: Bad arg to %patch: %build

Am I missing some package?

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From alan at redhat.com  Fri Nov  9 22:36:01 2007
From: alan at redhat.com (Alan Cox)
Date: Fri, 9 Nov 2007 17:36:01 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <20071109203142.GA6642@roque.1407.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
Message-ID: <20071109223601.GB5480@devserv.devel.redhat.com>

On Fri, Nov 09, 2007 at 08:31:42PM +0000, Rui Miguel Silva Seabra wrote:
> You don't get it, it wouldn't solve the problem.
> 
> You'd still have to go to the courts in order to prove that they are
> software patents and as such invalid.
> 
> Do you have tens of thousands of Euros?

I think you are the one missing the point Rui. Anyone can sue anyone for
anything - they are just likely to lose if they do something stupid.

>From an EU perspective the patent situation is passably clear and there is
some caselaw for purely software patents. There is also some caselaw on
DeCSS (Finland) although it disagrees with UK caselaw and will eventually
no doubt end up in the european court for harmonisation.

So from an EU perspective it makes a lot of sense. Unfortuantely from a US
perspective it makes rather less sense because the US idea of contributory
infringement is rather unfriendly.



From markg85 at gmail.com  Fri Nov  9 22:46:13 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 9 Nov 2007 23:46:13 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <20071109223601.GB5480@devserv.devel.redhat.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
Message-ID: <6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>

2007/11/9, Alan Cox <alan at redhat.com>:
> On Fri, Nov 09, 2007 at 08:31:42PM +0000, Rui Miguel Silva Seabra wrote:
> > You don't get it, it wouldn't solve the problem.
> >
> > You'd still have to go to the courts in order to prove that they are
> > software patents and as such invalid.
> >
> > Do you have tens of thousands of Euros?
>
> I think you are the one missing the point Rui. Anyone can sue anyone for
> anything - they are just likely to lose if they do something stupid.
>
> >From an EU perspective the patent situation is passably clear and there is
> some caselaw for purely software patents. There is also some caselaw on
> DeCSS (Finland) although it disagrees with UK caselaw and will eventually
> no doubt end up in the european court for harmonisation.
>
> So from an EU perspective it makes a lot of sense. Unfortuantely from a US
> perspective it makes rather less sense because the US idea of contributory
> infringement is rather unfriendly.

A little different question.
I know that RedHat is based in the USA but how about all the people
that make Fedora? is the majority of that in non USA countries? i' m
just wondering that..

@David Boles
I like fedora. i tried a dozen linux distributions but i keep coming
back to Fedora. The fact that i like it doesn't mean that i agree on
all parts (like this) but i understand why it's done so i will just
have to use livna for it.. (actually makes codec buddy completely
useless for me..)



From ndbecker2 at gmail.com  Fri Nov  9 22:46:56 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Nov 2007 17:46:56 -0500
Subject: Simplified contribution process?
Message-ID: <fh2o11$l59$1@ger.gmane.org>

One thing that I believe is overly difficult.  Perhaps others have solved
this, I'm just following the fedora recommendations.

I have:
package/devel
package/F-8
package/whatever.

I seem to need to update sources and spec files in each.  Typically they are
the same.  Actually, I would think needing different source of spec file is
the exception.

Can't this be simplified?  There is a lot of duplication.  I have to
remember to update sources, spec, cvs commit in each, and then build in
each - when usually they are all the same.




From nicolas.mailhot at laposte.net  Fri Nov  9 22:53:33 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 09 Nov 2007 23:53:33 +0100
Subject: Simplified contribution process?
In-Reply-To: <fh2o11$l59$1@ger.gmane.org>
References: <fh2o11$l59$1@ger.gmane.org>
Message-ID: <1194648813.19653.1.camel@rousalka.dyndns.org>


Le vendredi 09 novembre 2007 ? 17:46 -0500, Neal Becker a ?crit :

> Can't this be simplified?  There is a lot of duplication.  I have to
> remember to update sources, spec, cvs commit in each, and then build in
> each - when usually they are all the same.

When you need to build a package with the same sources specs and patches
cvs-import.sh is awfully convenient. Just  import the same srpm in
different branches, cvs update and make build

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/2bd5f9c9/attachment.sig>

From buildsys at fedoraproject.org  Fri Nov  9 22:58:09 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri,  9 Nov 2007 17:58:09 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-09
Message-ID: <20071109225809.5A70315212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 11

    cobbler-0.6.3-2.fc6
    fedora-ds-base-1.1.0-2.0.fc6
    jd-1.9.7-0.3.beta071109.fc6
    koan-0.6.3-3.fc6
    koffice-1.6.3-13.fc6
    ntfs-3g-1.1104-1.fc6
    python-GeoIP-1.2.1-6.fc6
    rxvt-2.7.10-13.fc6
NEW wqy-zenhei-fonts-0.2.16-0.2.20071031cvs.fc6 : WenQuanYi Zen Hei CJK Font
    xpdf-3.02-4.fc6
    zope-2.10.5-2.fc6


Changes in Fedora Extras 6: 


cobbler-0.6.3-2.fc6
-------------------
* Wed Nov 07 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.3-2
- Upstream changes (see CHANGELOG)
- now packaging javascript file(s) seperately for WUI
- backup state files on upgrade 
- cobbler sync now has pre/post triggers, so package those dirs/files
- WebUI now has .htaccess file
- removed yum-utils as a requirement

fedora-ds-base-1.1.0-2.0.fc6
----------------------------
* Wed Nov 07 2007 Rich Megginson <rmeggins at redhat.com> - 1.1.0-2.0
- This is the beta2 release
- new file added to package - /etc/sysconfig/dirsrv - for setting
- daemon environment as is usual in other linux daemons

* Thu Oct 18 2007 Rich Megginson <rmeggins at redhat.com> - 1.1.0-1.3
- upgrade to latest sources - fixes many, many bugs
- remove /var/tmp/dirsrv from package

jd-1.9.7-0.3.beta071109.fc6
---------------------------
* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

* Fri Nov 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyoa.c.jp> - 1.9.7-0.2.beta071101
- 1.9.7 beta 071101

koan-0.6.3-3.fc6
----------------
* Wed Nov 07 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.3-3
- Release bump to appease the build system.

* Wed Nov 07 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.3-2
- Upstream changes (see CHANGELOG)

koffice-1.6.3-13.fc6
--------------------
* Fri Nov 09 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 
1.6.3-13
- CVE-2007-4352 CVE-2007-5392 CVE-2007-5393 (#372611)

* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org>
1.6.3-12
- rebuild (for openexr-1.6.0)
- -libs: %post/%postun -p /sbin/ldconfig

* Wed Sep 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org>
1.6.3-11
- rebuild (for poppler) 
- re-enable (kross)ruby support (f8+)

* Wed Aug 22 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
1.6.3-10
- rebuild for buildid

ntfs-3g-1.1104-1.fc6
--------------------
* Thu Nov 08 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1104-1
- bump to 1.1104

python-GeoIP-1.2.1-6.fc6
------------------------
* Thu Sep 13 2007 Michael Fleming <mfleming+rpm at enlartenment.com> 1.2.1-6
- Add patch to expose country codes courtesy of Ignacio Vazquez-Adams
  (bz #243696)
- Update License tag per guidelines.

rxvt-2.7.10-13.fc6
------------------
* Wed Nov 07 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.7.10-13
- use utempter instead of wtmp/utmp (#214130)

* Wed Aug 22 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.7.10-12
- new license tag

wqy-zenhei-fonts-0.2.16-0.2.20071031cvs.fc6
-------------------------------------------
* Fri Nov 02 2007 Qianqian Fang <fangqq at gmail.com> 0.2.16-0.2.20071031cvs
- spec file clean up

* Thu Nov 01 2007 Qianqian Fang <fangqq at gmail.com> 0.2.16-0.1.20071031cvs
- initial packaging for Fedora (# 361121)

xpdf-3.02-4.fc6
---------------
* Fri Nov 09 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1:3.02-4
- resolve 372461, 372471, 372481

zope-2.10.5-2.fc6
-----------------
* Thu Nov 08 2007 Jonathan Steffan <jon a fedoraunity.org> 2.10.5-2
- Update permissions for zopectl and runzope



From sundaram at fedoraproject.org  Fri Nov  9 23:01:56 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 10 Nov 2007 04:31:56 +0530
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<1194613590.3255.10.camel@perihelion>	<20071109142607.GB6603@roque.1407.org>	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>	<20071109181111.GF6603@roque.1407.org>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<20071109203142.GA6642@roque.1407.org>	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
Message-ID: <4734E6E4.3020807@fedoraproject.org>

Mark wrote:

> A little different question.
> I know that RedHat is based in the USA but how about all the people
> that make Fedora? is the majority of that in non USA countries? i' m
> just wondering that..

 From the legal perspective that is pretty much irrelevant since Red Hat 
is the legal entity that takes on liability for the Fedora Project but 
if you want to some contribution stats, the CVS commits map would give 
you some idea

http://fedoraproject.org/maps/cvs-commits/

Most of the contributions are from US and Europe though I see commits 
from South America, Africa, India, China, Japan, New Zealand etc. 
Basically all over the map.

Rahul



From jspaleta at gmail.com  Fri Nov  9 23:09:07 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 9 Nov 2007 14:09:07 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <4734E6E4.3020807@fedoraproject.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
Message-ID: <604aa7910711091509m3c447fb5t3b55736dcd3d6c5c@mail.gmail.com>

On Nov 9, 2007 2:01 PM, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> http://fedoraproject.org/maps/cvs-commits/

MAPS!!!!!!!!!

-jef



From kevin.kofler at chello.at  Fri Nov  9 23:09:58 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 9 Nov 2007 23:09:58 +0000 (UTC)
Subject: Simplified contribution process?
References: <fh2o11$l59$1@ger.gmane.org>
Message-ID: <loom.20071109T230811-30@post.gmane.org>

Neal Becker <ndbecker2 <at> gmail.com> writes:
> I seem to need to update sources and spec files in each.

Actually you only need to upload the new sources once, the lookaside cache is 
per package, not per branch. Then you can copy and 
commit %{name}.spec, .cvsignore and sources (and new patches, if any) all at 
once.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Nov  9 23:16:56 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 9 Nov 2007 23:16:56 +0000 (UTC)
Subject: Codec Buddy misleading.
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<1194613590.3255.10.camel@perihelion>	<20071109142607.GB6603@roque.1407.org>	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>	<20071109181111.GF6603@roque.1407.org>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<20071109203142.GA6642@roque.1407.org>	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
Message-ID: <loom.20071109T231223-339@post.gmane.org>

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>  From the legal perspective that is pretty much irrelevant since Red Hat 
> is the legal entity that takes on liability for the Fedora Project but

A wacky idea, and I'm sure there are lots of reasons it is a bad idea, still 
it's something I've been wondering about ever since the whole "Fedora 
Foundation" talk: Why not create a Fedora foundation in a EU country? That 
might help solve this issue. And wasn't the main problem with the idea of a 
Fedora Foundation US tax laws? Maybe one of the EU countries has more 
advantageous laws?

        Kevin Kofler



From braden at endoframe.com  Fri Nov  9 23:14:00 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Fri, 09 Nov 2007 18:14:00 -0500
Subject: Bad arg to %patch
In-Reply-To: <4734D904.30705@endoframe.com>
References: <4734D904.30705@endoframe.com>
Message-ID: <fh2pjo$pqe$1@ger.gmane.org>

Braden McDaniel wrote:
> Since installing F8, I'm seeing this at the beginning of 'make tag' and 
> 'make build' operations:
> 
>   error: line 101: Bad arg to %patch: %build
> 
>   error: line 101: Bad arg to %patch: %build
> 
> Am I missing some package?

Argh. Nevermind. I goofed and checked in something to my spec file that 
wasn't supposed to go in.

Braden



From sundaram at fedoraproject.org  Fri Nov  9 23:29:58 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 10 Nov 2007 04:59:58 +0530
Subject: Codec Buddy misleading.
In-Reply-To: <loom.20071109T231223-339@post.gmane.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<1194613590.3255.10.camel@perihelion>	<20071109142607.GB6603@roque.1407.org>	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>	<20071109181111.GF6603@roque.1407.org>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<20071109203142.GA6642@roque.1407.org>	<20071109223601.GB5480@devserv.devel.redhat.com>	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
Message-ID: <4734ED76.3050307@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>>  From the legal perspective that is pretty much irrelevant since Red Hat 
>> is the legal entity that takes on liability for the Fedora Project but
> 
> A wacky idea, and I'm sure there are lots of reasons it is a bad idea, still 
> it's something I've been wondering about ever since the whole "Fedora 
> Foundation" talk: Why not create a Fedora foundation in a EU country? That 
> might help solve this issue. And wasn't the main problem with the idea of a 
> Fedora Foundation US tax laws? Maybe one of the EU countries has more 
> advantageous laws?

The administrative overhead in setting up a foundation is pretty high 
and there are lots of limitations including how much a single 
organization can fund a foundation and things like that. One way out 
that I have suggested earlier (and got rejected) is

http://conservancy.softwarefreedom.org/

It is U.S based but if it is a foundation (by proxy) the liability is 
much less. Moving from U.S to Europe isn't really a good solution if 
there is no guarantee that the political powers in Europe won't make 
things worse with all the constant lobbying going on. Red Hat and others 
are pushing for patent reform in U.S and that IMO is a good thing to be 
involved in. Refer http://fedoraproject.org/wiki/CodecBuddy. This is 
linked from the  initial message in codeina.

Rahul



From orion at cora.nwra.com  Fri Nov  9 23:47:11 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Fri, 09 Nov 2007 16:47:11 -0700
Subject: New mock logging
Message-ID: <4734F17F.1030905@cora.nwra.com>

How do I get rid of the:

2007-11-09 16:46:03,285 - util.py:194:DEBUG:

prefix that seems to have appeared with mock 0.8 (0.8.4)?  At least from 
the build.log.  Might be useful in the other logs...

Thanks!

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From rms at 1407.org  Fri Nov  9 23:50:43 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Fri, 9 Nov 2007 23:50:43 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <20071109223601.GB5480@devserv.devel.redhat.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
Message-ID: <20071109235043.GB9111@roque.1407.org>

On Fri, Nov 09, 2007 at 05:36:01PM -0500, Alan Cox wrote:
> On Fri, Nov 09, 2007 at 08:31:42PM +0000, Rui Miguel Silva Seabra wrote:
> > You don't get it, it wouldn't solve the problem.
> > 
> > You'd still have to go to the courts in order to prove that they are
> > software patents and as such invalid.
> > 
> > Do you have tens of thousands of Euros?
> 
> I think you are the one missing the point Rui.

Why would you say so...

>  Anyone can sue anyone for
> anything - they are just likely to lose if they do something stupid.

... still you get to spend tens of thousands of Euros proving your
innocence, as far as patent infringement goes.

> >From an EU perspective the patent situation is passably clear and there is
> some caselaw for purely software patents. There is also some caselaw on
> DeCSS (Finland) although it disagrees with UK caselaw and will eventually
> no doubt end up in the european court for harmonisation.

Passably clear, yes. Expensive for people running a business, also yes.

> So from an EU perspective it makes a lot of sense. Unfortuantely from a US
> perspective it makes rather less sense because the US idea of contributory
> infringement is rather unfriendly.

Yes.

Rui

-- 
Pzat!
Today is Pungenday, the 21st day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?



From markg85 at gmail.com  Fri Nov  9 23:56:43 2007
From: markg85 at gmail.com (Mark)
Date: Sat, 10 Nov 2007 00:56:43 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <4734ED76.3050307@fedoraproject.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
Message-ID: <6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>

That map is interesting :) central europe seems to be committing heavy as well.

Anyway.. i just found something interesting.
Sourceforge is hosted in the US right?

the gstreamer plugins (bad, ugly and ffmpeg and some others) are hosted on SF..
Now why is that not a problem? and putting a rpm on the fedora mirrors
with the codecs is..?? sounds kinda strange but it does seem to be the
case.. (same case for freedesktop.org)

so hows that working?



From gemi at bluewin.ch  Sat Nov 10 00:07:25 2007
From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister)
Date: Sat, 10 Nov 2007 01:07:25 +0100
Subject: Simplified contribution process?
In-Reply-To: <loom.20071109T230811-30@post.gmane.org>
References: <fh2o11$l59$1@ger.gmane.org>
	<loom.20071109T230811-30@post.gmane.org>
Message-ID: <1194653245.12545.1.camel@localhost.localdomain>

On Fri, 2007-11-09 at 23:09 +0000, Kevin Kofler wrote:
> Actually you only need to upload the new sources once, the lookaside
> cache is 
> per package, not per branch. Then you can copy and 
> commit %{name}.spec, .cvsignore and sources (and new patches, if any)
> all at 
> once.
Meld is quite helpful to synchronize the different branches.
-- 
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich



From jwboyer at gmail.com  Sat Nov 10 00:10:45 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 9 Nov 2007 18:10:45 -0600
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
Message-ID: <20071109181045.3b336b17@vader.jdub.homelinux.org>

On Fri, 9 Nov 2007 20:36:53 +0100
Mark <markg85 at gmail.com> wrote:

> I understand it completely... i just wish it wasn't working like this.
> kinda limited democracy

Democracy is a form of government.  It is not a blanket right to
infringe on other people's rights.

josh



From ndbecker2 at gmail.com  Sat Nov 10 00:21:47 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 09 Nov 2007 19:21:47 -0500
Subject: mock-0.8.4-2.fc8 broken?
Message-ID: <fh2tir$4rb$1@ger.gmane.org>

mock build RPM/SRPMS/qct-1.4-2.fc8.src.rpm
INFO: mock suid wrapper version 0.8.4
ERROR: Could not find required config file: /etc/mock/default.cfg
ERROR:   Did you forget to specify the chroot to use with '-r'?

There is no default.cfg.  There IS a defaults.cfg.



From alan at redhat.com  Sat Nov 10 00:31:56 2007
From: alan at redhat.com (Alan Cox)
Date: Fri, 9 Nov 2007 19:31:56 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <20071109235043.GB9111@roque.1407.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
Message-ID: <20071110003156.GA11246@devserv.devel.redhat.com>

On Fri, Nov 09, 2007 at 11:50:43PM +0000, Rui Miguel Silva Seabra wrote:
> > I think you are the one missing the point Rui.
> Why would you say so...

Because the cost of a lawsuit case is irrelevant

> >  Anyone can sue anyone for
> > anything - they are just likely to lose if they do something stupid.
> 
> ... still you get to spend tens of thousands of Euros proving your
> innocence, as far as patent infringement goes.

But I can accuse you of that whenever I like whether its true or not. So its
irrelevant to the discussion, its a totally specious argument.



From lfarkas at bppiac.hu  Sat Nov 10 00:32:41 2007
From: lfarkas at bppiac.hu (Farkas Levente)
Date: Sat, 10 Nov 2007 01:32:41 +0100
Subject: kernel crash during fedora 8 upgrade on hp nx6125?
Message-ID: <4734FC29.7010309@bppiac.hu>

hi,
after some google search i found out how to get through the dependencies
resolution after 26% (remove dbus, expat and avahi) i able to ugrade 3
of my workstations to f8. the problem comes when i try to upgrade my hp
nx6125 laptop which has exactly the same packages installed as my
workstations and works with fedora 7 (i386 and still would like to use
i386). after another few google i found these:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=3277
http://www.clasohm.com/blog/one-entry?entry_id=14560
http://ubuntuforums.org/showthread.php?t=119426
i exactly has the same syndrome with f8 upgrade from dvd ie. it'e
terrible slow (10-100 times!!!). if i gives the noapic nolapic kernel
option for the installer it's use the normal speed, but kernel crash
when start /sbin/loader.
so my question is there any solution for this?
is it a kernel bug or is there any solution to be able to upgrade to f8
and use it in an acceptable speed?
thanks in advance.

-- 
  Levente                               "Si vis pacem para bellum!"



From alan at redhat.com  Sat Nov 10 00:33:00 2007
From: alan at redhat.com (Alan Cox)
Date: Fri, 9 Nov 2007 19:33:00 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
References: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
Message-ID: <20071110003300.GB11246@devserv.devel.redhat.com>

On Sat, Nov 10, 2007 at 12:56:43AM +0100, Mark wrote:
> with the codecs is..?? sounds kinda strange but it does seem to be the
> case.. (same case for freedesktop.org)
> 
> so hows that working?

SF.net just provides hosting and shelters under the US "hey we just host it"
protections



From kevin.kofler at chello.at  Sat Nov 10 00:50:32 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Nov 2007 00:50:32 +0000 (UTC)
Subject: Simplified contribution process?
References: <fh2o11$l59$1@ger.gmane.org>
	<loom.20071109T230811-30@post.gmane.org>
	<1194653245.12545.1.camel@localhost.localdomain>
Message-ID: <loom.20071110T003113-318@post.gmane.org>

G?rard Milmeister <gemi <at> bluewin.ch> writes:
> Meld is quite helpful to synchronize the different branches.

I usually just use the same specfile, with %{?fedora} conditionals when needed, 
that way there's nothing to merge. :-) Rex Dieter likes working that way too. 
Other maintainers prefer separate specfiles, which has some advantages (more 
straightforward to read, need to worry only about one branch at a time) and 
some drawbacks (merging is harder, need to worry about each branch separately).

How I personally work is that if I have to fix something quickly for a branch 
without pulling in the latest from devel (or without updating devel because 
it's going to get a new version which has the fix upstream shortly), e.g. 
during final devel freeze, I'll change the branch only and use n%{?dist}.m 
versioning. An example where I did this: strigi 0.5.5 in F8 had a build-related 
problem. The problem was already fixed upstream in 0.5.7, but I didn't want to 
pull in 0.5.7 into F8 for several reasons (freeze, worry about breaking things, 
which turned out legitimate because 0.5.7 needs a new kdelibs4 to match the API 
changes). So I built a 0.5.5-1.fc8.2 with a patch for this issue in F8 only. F7 
was not affected by the issue due to the different binutils in use (no 
build-id), and I didn't bother updating devel because I knew 0.5.7 would go 
there soon anyway, so I edited only the specfile for F8. Dropping the quick 
hack later is easy in such a case, just copy over the new specfile from devel, 
making them the same again. (Now some pedants will undoubtedly complain that 
this loses changelog entries, and in fact Deji left the extra F8 changelog 
entries in when he merged Strigi 0.5.7 from devel to F8, but I'd say the 
entries are irrelevant because the updated package is derived from a different 
branch which never got the quick hack in the first place, so I don't bother 
readding them when I do this sort of merges. There's pedantic arguments both 
for leaving the entries in or not, I simply prefer the most practical way.)

        Kevin Kofler



From kevin.kofler at chello.at  Sat Nov 10 01:02:42 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Nov 2007 01:02:42 +0000 (UTC)
Subject: Codec Buddy misleading.
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
Message-ID: <loom.20071110T010110-452@post.gmane.org>

Rui Miguel Silva Seabra <rms <at> 1407.org> writes:
> ... still you get to spend tens of thousands of Euros proving your
> innocence, as far as patent infringement goes.

In most European courts, the loser pays all legal fees. (Now don't ask me for a 
list of exceptions, but this is the usual way things are handled in most of 
Europe.)

        Kevin Kofler



From kevin.kofler at chello.at  Sat Nov 10 01:18:08 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Nov 2007 01:18:08 +0000 (UTC)
Subject: Codec Buddy misleading.
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
Message-ID: <loom.20071110T011142-629@post.gmane.org>

Mark <markg85 <at> gmail.com> writes:
> That map is interesting :) central europe seems to be committing heavy as
> well.

Most of the commits in the area around here probably come from the Red Hat Brno 
office. Then of course there's a few of us community maintainers in Vienna (at 
least Oliver Falk and me). A bit farther from here, there's also the Red Hat 
Stuttgart office.

        Kevin Kofler



From markg85 at gmail.com  Sat Nov 10 01:35:35 2007
From: markg85 at gmail.com (Mark)
Date: Sat, 10 Nov 2007 02:35:35 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <20071110003300.GB11246@devserv.devel.redhat.com>
References: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
	<20071110003300.GB11246@devserv.devel.redhat.com>
Message-ID: <6e24a8e80711091735s796ad4a8ib221495790d26414@mail.gmail.com>

2007/11/10, Alan Cox <alan at redhat.com>:
> On Sat, Nov 10, 2007 at 12:56:43AM +0100, Mark wrote:
> > with the codecs is..?? sounds kinda strange but it does seem to be the
> > case.. (same case for freedesktop.org)
> >
> > so hows that working?
>
> SF.net just provides hosting and shelters under the US "hey we just host it"
> protections

i still don't see why it can't be hosted on fedora.. i understand the
patent part but if SF can do it than anyone can right? it's not that
fedora has more users than sf.net.. i think it's actually the
opposite.

I just find it all very strange.. some us sites can host it.. some
can't.. it's confusing.



From jwboyer at gmail.com  Sat Nov 10 01:41:13 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 9 Nov 2007 19:41:13 -0600
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091735s796ad4a8ib221495790d26414@mail.gmail.com>
References: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
	<20071110003300.GB11246@devserv.devel.redhat.com>
	<6e24a8e80711091735s796ad4a8ib221495790d26414@mail.gmail.com>
Message-ID: <20071109194113.4fe4cb3d@vader.jdub.homelinux.org>

On Sat, 10 Nov 2007 02:35:35 +0100
Mark <markg85 at gmail.com> wrote:

> 2007/11/10, Alan Cox <alan at redhat.com>:
> > On Sat, Nov 10, 2007 at 12:56:43AM +0100, Mark wrote:
> > > with the codecs is..?? sounds kinda strange but it does seem to be the
> > > case.. (same case for freedesktop.org)
> > >
> > > so hows that working?
> >
> > SF.net just provides hosting and shelters under the US "hey we just host it"
> > protections
> 
> i still don't see why it can't be hosted on fedora.. i understand the
> patent part but if SF can do it than anyone can right? it's not that
> fedora has more users than sf.net.. i think it's actually the
> opposite.
> 
> I just find it all very strange.. some us sites can host it.. some
> can't.. it's confusing.

If you really want to know the answer to this question, you should seek
out a lawyer familiar with the US laws.  Asking on a developers mailing
list is not a good idea.

josh



From sundaram at fedoraproject.org  Sat Nov 10 01:38:09 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 10 Nov 2007 07:08:09 +0530
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091735s796ad4a8ib221495790d26414@mail.gmail.com>
References: <6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<20071109203142.GA6642@roque.1407.org>	<20071109223601.GB5480@devserv.devel.redhat.com>	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>	<4734E6E4.3020807@fedoraproject.org>	<loom.20071109T231223-339@post.gmane.org>	<4734ED76.3050307@fedoraproject.org>	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>	<20071110003300.GB11246@devserv.devel.redhat.com>
	<6e24a8e80711091735s796ad4a8ib221495790d26414@mail.gmail.com>
Message-ID: <47350B81.5060608@fedoraproject.org>

Mark wrote:
> 2007/11/10, Alan Cox <alan at redhat.com>:
>> On Sat, Nov 10, 2007 at 12:56:43AM +0100, Mark wrote:
>>> with the codecs is..?? sounds kinda strange but it does seem to be the
>>> case.. (same case for freedesktop.org)
>>>
>>> so hows that working?
>> SF.net just provides hosting and shelters under the US "hey we just host it"
>> protections
> 
> i still don't see why it can't be hosted on fedora.. i understand the
> patent part but if SF can do it than anyone can right? it's not that
> fedora has more users than sf.net.. i think it's actually the
> opposite.
> 
> I just find it all very strange.. some us sites can host it.. some
> can't.. it's confusing.

That's law for you.

Rahul



From abartlet at samba.org  Sat Nov 10 01:53:41 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Sat, 10 Nov 2007 12:53:41 +1100
Subject: Smolt and software information
In-Reply-To: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
Message-ID: <1194659621.430.24.camel@naomi>


On Fri, 2007-11-09 at 11:29 -0500, Yaakov Nemoy wrote:
> Hey list,
> 
> There's been a bit of conversation lately in #smolt about collecting
> information about partitioning, hard drive sizes, and most
> importantly, file system types.  I feel it might be just a touch out
> of scope for smolt, since so far our policy has been hardware only.
> The reason this appeals to me the most is if there is any interest in
> file system type used, this would be a good place to collect those
> statistics.  

> 2) Are there any privacy concerns?  Remember smolt is voluntary, and
> so far we don't link any information to machines other than a single
> UUID that is privately stored.  Mainly, the implementation will
> probably be just simply parsing through /etc/fstab.
> 
> Thanks in advance for any input you all are willing to share.

The more we move into tracking software, the more I'm concerned about
smolt.  I've chosen to participate so far, because I would like my
hardware supported better, but for software you risk disclosing things
people perhaps didn't want public like:

 - Do I run patented codecs?
 - Do I run a proprietary kernel module?
 - Do I run software I would rather not let others know I run?

Part of the problem is that the data isn't just sent in terms of a UUID.
Even if not stored, the transmission of the smolt info contains a lot of
personally identifiable information, such as IP addresses, which can be
back-analysed to an identity, and tracked as the UUID remains constant,
but a reported IP moves around the globe...

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071110/79d5843e/attachment.sig>

From loupgaroublond at gmail.com  Sat Nov 10 02:35:52 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 9 Nov 2007 21:35:52 -0500
Subject: Smolt and software information
In-Reply-To: <1194659621.430.24.camel@naomi>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194659621.430.24.camel@naomi>
Message-ID: <7f692fec0711091835u5717c7d5qf24f3a999b67a498@mail.gmail.com>

On Nov 9, 2007 8:53 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> The more we move into tracking software, the more I'm concerned about
> smolt.  I've chosen to participate so far, because I would like my
> hardware supported better, but for software you risk disclosing things
> people perhaps didn't want public like:
>
>  - Do I run patented codecs?
>  - Do I run a proprietary kernel module?
>  - Do I run software I would rather not let others know I run?

The client isn't set up to do so yet, but if you wanted, it's possible
to exclude a certain hardware item, because you don't want it revealed
that you use a proprietary driver.  We don't record the other bits of
information.  This has also been heavily discussed.  I hate to think
that every time I ask honest questions about privacy, people suddenly
think smolt is some evil thing because it has inherent privacy
questions.  This is why I post questions all the time.

> Part of the problem is that the data isn't just sent in terms of a UUID.
> Even if not stored, the transmission of the smolt info contains a lot of
> personally identifiable information, such as IP addresses, which can be
> back-analysed to an identity, and tracked as the UUID remains constant,
> but a reported IP moves around the globe...

This I think is the number one concern.  Smolt does not store any IP
related information in it's database.  The source code is available as
it is open source.  The server that accepts the incoming data does
receive an IP address, and that is infact unavoidable.  We encourage
you to use Tor or other privacy tools if you have a *real* problem.
Our privacy policy states that we don't collect any IP information,
and any identifying information aside from the UUID is entirely
voluntary.

smolts.org AFAIK is hosted in the US.  Personally I'm worried that the
Patriot Act and friends will require us to maintain IP logs on the
caching server that is the part that most people interact with when
they actually interact with Smolt.  When that happens, we are, and
pardon my french here, screwed.  Since IANAL, there is really little I
can say about the privacy issues, although I would personally look at
international hosting.

So when you don't mention any objections to storage of filesystem type
used, that means I have your +0 vote on that issue? ;-P

-Yaakov



From dmalcolm at redhat.com  Sat Nov 10 02:53:03 2007
From: dmalcolm at redhat.com (Dave Malcolm)
Date: Fri, 09 Nov 2007 21:53:03 -0500
Subject: [SCRIPT] Autogenerating BuildRequires for specfiles
Message-ID: <1194663183.2603.3.camel@shirehorse2>

Whilst attempting to package crystalspace I got sick of scanning the
configure.ac by hand, and wrote a script to try to automate this.

Attached is the result; you give it the path to an unpacked/prepped
source tree, and it looks inside at the
configure.ac/configure.in/configure scripts (if any), scouring them for
header file references, then using rpm and yum to figure out what
provides them, and finally spits out a sorted list of BuildRequires:
lines.

It uses some special-casing/heuristics/hacks to try to generate
something sane.

This was useful to me, and I suspect to other, so perhaps (suitably
renamed) it could live in the rpmdevtools package?

If anyone's familiar with the yum api, there's some major optimization
that could be done (I call out to yum each time, rather than setting it
up in code and amortizing the startup costs)

Hope this helps
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autospec.py
Type: text/x-python
Size: 5821 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/cf1894a3/attachment.py>

From rc040203 at freenet.de  Sat Nov 10 02:58:02 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 10 Nov 2007 03:58:02 +0100
Subject: Bogus permissions on 8/Everything/i386/os/Packages/*.rpm
Message-ID: <1194663482.9673.577.camel@mccallum.corsepiu.local>

Hi,

There seem to be several packages in 8/Everything/i386/os/Packages which carry bogus permissions:

# lftp download.fedora.redhat.com:/pub/fedora/linux/releases/8/Everything/i386/os/Packages
> ls Inventor*
-rwxr-xr-x    4 ftp      ftp       1545445 Oct 27 02:23 Inventor-2.1.5-30.fc8.i386.rpm
-rwxr-xr-x    2 ftp      ftp       3112019 Oct 27 02:23 Inventor-data-2.1.5-30.fc8.i386.rpm
-rwxr-xr-x    2 ftp      ftp        559130 Oct 27 02:23 Inventor-demos-2.1.5-30.fc8.i386.rpm
-rwxr-xr-x    4 ftp      ftp        967385 Oct 27 02:23 Inventor-devel-2.1.5-30.fc8.i386.rpm
-rwxr-xr-x    2 ftp      ftp        996292 Oct 27 02:23 Inventor-examples-2.1.5-30.fc8.i386.rpm
-rwxr-xr-x    4 ftp      ftp        771479 Oct 27 02:23 InventorXt-2.1.5-30.fc8.i386.rpm
-rwxr-xr-x    4 ftp      ftp        103502 Oct 27 02:23 InventorXt-devel-2.1.5-30.fc8.i386.rpm

Ralf




From jkeating at redhat.com  Sat Nov 10 03:01:59 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 9 Nov 2007 22:01:59 -0500
Subject: Bogus permissions on 8/Everything/i386/os/Packages/*.rpm
In-Reply-To: <1194663482.9673.577.camel@mccallum.corsepiu.local>
References: <1194663482.9673.577.camel@mccallum.corsepiu.local>
Message-ID: <20071109220159.049d0a80@redhat.com>

On Sat, 10 Nov 2007 03:58:02 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> Hi,
> 
> There seem to be several packages in 8/Everything/i386/os/Packages
> which carry bogus permissions:

This is known, a side-effect of an heavy handed bitflip.  While "bogus"
does it /really/ cause any harm?  Not to say that we won't "fix" this,
we're just choosing to wait until things calm down a little bit before
adding more churn.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/5e3f0e28/attachment.sig>

From rc040203 at freenet.de  Sat Nov 10 03:08:55 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 10 Nov 2007 04:08:55 +0100
Subject: Bogus permissions on 8/Everything/i386/os/Packages/*.rpm
In-Reply-To: <20071109220159.049d0a80@redhat.com>
References: <1194663482.9673.577.camel@mccallum.corsepiu.local>
	<20071109220159.049d0a80@redhat.com>
Message-ID: <1194664135.9673.584.camel@mccallum.corsepiu.local>

On Fri, 2007-11-09 at 22:01 -0500, Jesse Keating wrote:
> On Sat, 10 Nov 2007 03:58:02 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > Hi,
> > 
> > There seem to be several packages in 8/Everything/i386/os/Packages
> > which carry bogus permissions:
> 
> This is known, a side-effect of an heavy handed bitflip.  While "bogus"
> does it /really/ cause any harm?
No, not really, but ... I would expect the fact RH/Fedora is shipping
*.rpms +x'ed will cause people think *rpms should be +x'ed? 

Esp. WIN-users tend to think so, because they are used to using some
"self-installing packages" (InstallShield etc.).

So, no it's not a biggy, but it's also not nice.

>   Not to say that we won't "fix" this,
> we're just choosing to wait until things calm down a little bit before
> adding more churn.
;) Resyncing the mirrors?

Ralf




From abartlet at samba.org  Sat Nov 10 03:38:06 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Sat, 10 Nov 2007 14:38:06 +1100
Subject: Smolt and software information
In-Reply-To: <7f692fec0711091835u5717c7d5qf24f3a999b67a498@mail.gmail.com>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194659621.430.24.camel@naomi>
	<7f692fec0711091835u5717c7d5qf24f3a999b67a498@mail.gmail.com>
Message-ID: <1194665886.430.30.camel@naomi>


On Fri, 2007-11-09 at 21:35 -0500, Yaakov Nemoy wrote:
> On Nov 9, 2007 8:53 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> > The more we move into tracking software, the more I'm concerned about
> > smolt.  I've chosen to participate so far, because I would like my
> > hardware supported better, but for software you risk disclosing things
> > people perhaps didn't want public like:
> >
> >  - Do I run patented codecs?
> >  - Do I run a proprietary kernel module?
> >  - Do I run software I would rather not let others know I run?
> 
> The client isn't set up to do so yet, but if you wanted, it's possible
> to exclude a certain hardware item, because you don't want it revealed
> that you use a proprietary driver.  We don't record the other bits of
> information.  This has also been heavily discussed.  I hate to think
> that every time I ask honest questions about privacy, people suddenly
> think smolt is some evil thing because it has inherent privacy
> questions.  This is why I post questions all the time.

Thankyou for taking so much time and effort to consider the issues, and
for your thoughtful reply. 

> This I think is the number one concern.  Smolt does not store any IP
> related information in it's database.  The source code is available as
> it is open source.  The server that accepts the incoming data does
> receive an IP address, and that is infact unavoidable.  

> So when you don't mention any objections to storage of filesystem type
> used, that means I have your +0 vote on that issue? ;-P

It seems harmless enough, but most things do :-)

Perhaps just list it if the filesystems are in the standard set supplied
with Fedora?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071110/ce4bd74d/attachment.sig>

From sandeen at redhat.com  Sat Nov 10 03:46:46 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Fri, 09 Nov 2007 21:46:46 -0600
Subject: Smolt and software information
In-Reply-To: <1194665886.430.30.camel@naomi>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>	<1194659621.430.24.camel@naomi>	<7f692fec0711091835u5717c7d5qf24f3a999b67a498@mail.gmail.com>
	<1194665886.430.30.camel@naomi>
Message-ID: <473529A6.5080304@redhat.com>

Andrew Bartlett wrote:

> Perhaps just list it if the filesystems are in the standard set supplied
> with Fedora?

So if someone were using "mynewsecretfs" don't report it?  I guess I
could see that.  Although keeping up the "acceptable to report" list
might be a trick.

-Eric

> Andrew Bartlett
> 
> 



From jkeating at redhat.com  Sat Nov 10 03:53:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 9 Nov 2007 22:53:45 -0500
Subject: Bogus permissions on 8/Everything/i386/os/Packages/*.rpm
In-Reply-To: <1194664135.9673.584.camel@mccallum.corsepiu.local>
References: <1194663482.9673.577.camel@mccallum.corsepiu.local>
	<20071109220159.049d0a80@redhat.com>
	<1194664135.9673.584.camel@mccallum.corsepiu.local>
Message-ID: <20071109225345.38aeabbc@redhat.com>

On Sat, 10 Nov 2007 04:08:55 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:

> ;) Resyncing the mirrors?

Well, permission changes are pretty darn fast, yet it is still churn
and still bandwidth consumed.  I'd just rather not get in the way of
all those happy people trying to get to Fedora 8 (:

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071109/9bad3e77/attachment.sig>

From rc040203 at freenet.de  Sat Nov 10 04:06:08 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sat, 10 Nov 2007 05:06:08 +0100
Subject: Bogus permissions on 8/Everything/i386/os/Packages/*.rpm
In-Reply-To: <20071109225345.38aeabbc@redhat.com>
References: <1194663482.9673.577.camel@mccallum.corsepiu.local>
	<20071109220159.049d0a80@redhat.com>
	<1194664135.9673.584.camel@mccallum.corsepiu.local>
	<20071109225345.38aeabbc@redhat.com>
Message-ID: <1194667578.9673.596.camel@mccallum.corsepiu.local>

On Fri, 2007-11-09 at 22:53 -0500, Jesse Keating wrote:
> On Sat, 10 Nov 2007 04:08:55 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > ;) Resyncing the mirrors?
> 
> Well, permission changes are pretty darn fast, yet it is still churn
> and still bandwidth consumed.  I'd just rather not get in the way of
> all those happy people trying to get to Fedora 8 (:
Hmm. Fix issues ASAP, before they propagate to/infect more users?
Many users still might not have started to download, or might be midst
of downloading.

I don't know what would be better in this case. The risk of corrupting
something definitely exists, provided you can't know which kind of
mirroring scripts/strategies (wget, lftp, reposync, yum caching,
apt, ..) users apply.

I am not sure what would better in this case.

All I can say, if I was still a low bandwidth user, I were very upset
when experiencing that files which are supposed to be constant are being
re-downloaded :)

Ralf




From P at draigBrady.com  Sat Nov 10 04:16:46 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Sat, 10 Nov 2007 04:16:46 +0000
Subject: thanks for F8!
Message-ID: <473530AE.9060305@draigBrady.com>

I just updated and did a mini review:
http://www.pixelbeat.org/docs/f8.html

In summary it rocks!

thanks again,
P?draig.



From rhally at mindspring.com  Sat Nov 10 07:15:53 2007
From: rhally at mindspring.com (Richard Hally)
Date: Sat, 10 Nov 2007 02:15:53 -0500
Subject: rawhide report: 20071109 changes
In-Reply-To: <20071109134826.334610c7@redhat.com>
References: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
	<20071109134826.334610c7@redhat.com>
Message-ID: <47355AA9.6030203@mindspring.com>

Jesse Keating wrote:
> On Fri, 9 Nov 2007 12:40:10 -0500
> Build System <buildsys at redhat.com> wrote:
> 
>> rawhide report: 20071109 changes
> 
> THUMP!
> 

Yippy kii yea! Now we're back to the old bust'em up.

On a fresh install of F8 (default install minus the "office and productivity" 
stuff) switching to the development repo and updating ~150 packages, I get a 
problem going to runlevel 5 (something about "x" respawning too fast) and no 
login screen. Runlevel 3 login and startx works.

replacing the gdm package that was in the update with the previously installed 
gdm fixed the problem.

Richard



From caillon at redhat.com  Sat Nov 10 09:04:35 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 10 Nov 2007 10:04:35 +0100
Subject: Firefox 3
In-Reply-To: <20071109163346.GG6342@rednote.net>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net>
Message-ID: <47357423.9030004@redhat.com>

Janina Sajka wrote:
>> Janina Sajka <janina at rednote.net> wrote:
>> >Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
>> >near ready for prime time, but I have a compelling reason to start using
>> >ff3 fairly soon and would rather install from rpm, of course.

Stay tuned for an update in the next two weeks.  We got this working 
last week, but there's a few things we want to clean up before it's put 
into rawhide.  Putting it into rawhide will also mean breaking several 
things such as epiphany, yelp, devhelp, and every other application that 
uses gecko right now.  So there is a high cost that we want to be in a 
position to communicate well as to the proper way to solve rather than 
simply leave broken for people to figure it out.



From rms at 1407.org  Sat Nov 10 09:56:57 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Sat, 10 Nov 2007 09:56:57 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <20071110003156.GA11246@devserv.devel.redhat.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
Message-ID: <20071110095657.GA6631@roque.1407.org>

On Fri, Nov 09, 2007 at 07:31:56PM -0500, Alan Cox wrote:
> On Fri, Nov 09, 2007 at 11:50:43PM +0000, Rui Miguel Silva Seabra wrote:
> > > I think you are the one missing the point Rui.
> > Why would you say so...
> 
> Because the cost of a lawsuit case is irrelevant
> 
> > >  Anyone can sue anyone for
> > > anything - they are just likely to lose if they do something stupid.
> > 
> > ... still you get to spend tens of thousands of Euros proving your
> > innocence, as far as patent infringement goes.
> 
> But I can accuse you of that whenever I like whether its true or not. So its
> irrelevant to the discussion, its a totally specious argument.

In any normal case, the accuser has to prove your guilt.

But as far as I have understood about patents, you have to prove your
innocence.

I don't think it's an irrelevant or totally specious argument.

Rui

-- 
This statement is false.
Today is Prickle-Prickle, the 22nd day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?



From wolfy at nobugconsulting.ro  Sat Nov 10 11:24:03 2007
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 10 Nov 2007 13:24:03 +0200
Subject: mock-0.8.4-2.fc8 broken?
In-Reply-To: <fh2tir$4rb$1@ger.gmane.org>
References: <fh2tir$4rb$1@ger.gmane.org>
Message-ID: <473594D3.7030603@nobugconsulting.ro>

On 11/10/2007 02:21 AM, Neal Becker wrote:
> mock build RPM/SRPMS/qct-1.4-2.fc8.src.rpm
> INFO: mock suid wrapper version 0.8.4
> ERROR: Could not find required config file: /etc/mock/default.cfg
> ERROR:   Did you forget to specify the chroot to use with '-r'?
>
> There is no default.cfg.  There IS a defaults.cfg.
>
>   
Just ln -s /etc/mock/your_most_used_config.cfg  to /etc/mock/default.cfg
Or use -r to specify the config file to use.



From buildsys at redhat.com  Sat Nov 10 11:36:46 2007
From: buildsys at redhat.com (Build System)
Date: Sat, 10 Nov 2007 06:36:46 -0500
Subject: rawhide report: 20071110 changes
Message-ID: <200711101136.lAABaktW023135@porkchop.devel.redhat.com>

New package proxyknife
	Customizable multithreaded proxy hunter

New package python-minihallib
	Library to handle HAL devices and events


Removed package Democracy

Updated Packages:

Miro-0.9.9.9-1.fc9
------------------
* Fri Nov 09 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.9.9.9-1
- Update to latest upstream (0.9.9.9)
- Build against gecko-libs 1.8.1.9 (firefox 2.0.0.9)
- Include xine_extractor in package (thanks to Jason Farrell)
- Drop Miro-setup.py.patch

OpenEXR-1.6.0-5.fc8
-------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-5
- multiarch conflicts in OpenEXR (#342781)
- don't own %_includedir/OpenEXR (leave that to ilmbase)

alpine-0.99999-2.fc9
--------------------
* Fri Nov 09 2007 Joshua Daniel Franklin <joshuadfranklin at yahoo.com> 0.99999-2
- update to latest

archivemail-0.7.2-1.fc9
-----------------------
* Fri Nov 09 2007 Jon Ciesla <limb at jcomserv.net> 0.7.2-1
- Update to 0.7.2.

bibletime-1.6.5-1.fc9
---------------------
* Tue Nov 06 2007 Deji Akingunola <dakingun at gmail.com> 1.6.5-1
- 1.6.5

brasero-0.6.1-2.fc9
-------------------
* Fri Nov 09 2007 Denis Leroy <denis at poolshark.org> - 0.6.1-2
- Rebuild to pick up new totem version (#361361)

cfitsio-3.060-1.fc9
-------------------
* Fri Nov 09 2007 Matthew Truch <matt at truch.net> - 3.060-1
- Update to 3.060 bugfix release.
- Add static package (BZ 372801)

chkconfig-1.3.37-1
------------------
* Thu Nov 08 2007 Bill Nottingham <notting at redhat.com> 1.3.37-1
- make no options do --list (#290241, #176184)
- sr at Latn -> sr at latin

chmsee-1.0.0-1.27.fc9
---------------------
* Sat Nov 10 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.27
- build for firefox-2.0.0.9

* Sat Aug 11 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.23
- update to 1.0.0
- build for firefox-2.0.0.6
- update License field to GPLv2

* Sat Jul 21 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-0.22.beta2
- fix desktop file

devhelp-0.16.1-3.fc9
--------------------
* Fri Nov 09 2007 Matthew Barnes <mbarnes at redhat.com> - 0.16.1-3.fc9
- Rebuild against gecko-libs 1.8.1.9.

dhcpv6-0.99.0-2.fc9
-------------------
* Fri Nov 09 2007 David Cantrell <dcantrell at redhat.com> - 0.99.0-2
- Rebuild

funtools-1.4.0-4.fc9
--------------------
* Fri Nov 09 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 1.4.0-4
- Adding some packages to devel requires

galeon-2.0.3-14.fc9
-------------------
* Fri Nov 09 2007 Alex Lancaster <alexl at users.sourceforge.net> - 2.0.3-14
- Rebuild with gecko lib 1.8.1.9

* Wed Sep 19 2007 Denis Leroy <denis at poolshark.org> - 2.0.3-12
- Added patch to fix image load preference (#292361)
- Added patch to fix print dialog crash (#285661)

* Wed Aug 22 2007 Denis Leroy <denis at poolshark.org> - 2.0.3-11
- F-8 rebuild

gdm-1:2.21.2-0.2007.11.09.1.fc9
-------------------------------
* Fri Nov 09 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.09.1
- Update to today's snapshot

gnome-python2-extras-2.19.1-10.fc9
----------------------------------
* Fri Nov 09 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-10.fc9
- Rebuild against gecko-libs 1.8.1.9.

hunspell-1.2.1-2.fc9
--------------------
* Fri Nov 09 2007 Caolan McNamara <caolanm at redhat.com> - 1.2.1-2
- pkg-config cockup
hunspell-gl-0.20071107-1.fc9
----------------------------
* Fri Nov 09 2007 Caolan McNamara <caolanm at redhat.com> - 0.20071107-1
- latest dictionaries
jd-1.9.7-0.3.beta071109.fc9
---------------------------
* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

* Fri Nov 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyoa.c.jp> - 1.9.7-0.2.beta071101
- 1.9.7 beta 071101

* Fri Oct 05 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.6-1
- 1.9.6

kdeedu-3.95.2-1.fc9
-------------------
* Fri Nov 09 2007 Rex Dieter <rdieter[AT]fedoraprojec.org> 3.95.2-1
- kdeedu-3.95.2 
- resume ppc, ppc64 builds (#370771)

* Wed Nov 07 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.0-4
- ExcludeArch: ppc ppc64 (#370771)

* Wed Nov 07 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.0-2
- Obsoletes/Provides: kalgebra (#371121)

kdelibs4-3.95.2-1.fc9
---------------------
* Fri Nov 09 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.2-1
- kde-3.95.2

kdepimlibs-3.95.2-1.fc9
-----------------------
* Fri Nov 09 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.2-1
- kde-3.95.2

libdhcp-1.99.0-2.fc9
--------------------
* Fri Nov 09 2007 David Cantrell <dcantrell at redhat.com> - 1.99.0-2
- Rebuild for new upstream release of dhcpv6

mash-0.2.9-1.fc9
----------------
* Fri Nov 09 2007 Bill Nottingham <notting at redhat.com> 0.2.9-1
- handle noarch excludearch for packages without source
  rpms (<rob.myers at gtri.gatech.edu>)
- use yum's pkgSack, not yumLocalPackage

mercurial-0.9.5-6.fc9
---------------------
* Fri Nov 09 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.5-6
- rpmlint fixes

* Fri Nov 09 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.5-5
- /etc/mercurial/hgrc.d missing

* Fri Nov 09 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.5-3
- Fix to last change

mkinitrd-6.0.19-4.fc9
---------------------
* Fri Nov 09 2007 Jeremy Katz <katzj at redhat.com> - 6.0.19-4
- rebuild for new libdhcp4client

* Sat Oct 20 2007 Bill Nottingham <notting at redhat.com> - 6.0.19-3
- pull the right dynamic linker when multiple ones are present (#336161)

* Thu Sep 27 2007 Peter Jones <pjones at redhat.com> - 6.0.19-1
- Fix nosegneg library discovery in get_dso_deps() harder (#244730)

mksh-32-1.fc9
-------------
* Sat Nov 10 2007 Robert Scheck <robert at fedoraproject.org> 32-1
- Upgrade to 32
- Solved fork problems in %check (thanks to Thorsten Glaser)

mod_nss-1.0.7-2.fc9
-------------------
* Thu Oct 18 2007 Rob Crittenden <rcritten at redhat.com> 1.0.7-2
- Register functions needed by mod_proxy if mod_ssl is not loaded.

mono-1.2.5.1-4.fc9
------------------
* Fri Nov 09 2007 Ray Strode <rstrode at redhat.com> - 1.2.5.1-4
- Apply dropped patch (bug 371781), found by Eskil Bylund

* Wed Nov 07 2007 Alexander Larsson <alexl at redhat.com> - 1.2.5.1-3
- Fix overflow in Mono.Math.BigInteger class (#367551)
  CVE-2007-5197

* Fri Oct 05 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 1.2.5.1-1
- bump
- added new parts (mono-linker, resgen and mono-cecil)

osgal-1:0.6.1-2.fc9
-------------------
* Fri Nov 09 2007 Christopher Stone <chris.stone at gmail.com> 1:0.6.1-2
- Rebuild against OSG2.2

osgcal-0.1.46-3.fc9
-------------------
* Fri Nov 09 2007 Christopher Stone <chris.stone at gmail.com> 0.1.46-3
- Rebuild against OSG2.2

pam_krb5-2.2.21-1
-----------------
* Fri Nov 09 2007 Nalin Dahyabhai <nalin at redhat.com> - 2.2.21-1
- make sure that we have tokens when checking the user's .k5login (#371761)

* Thu Nov 08 2007 Nalin Dahyabhai <nalin at redhat.com>
- set perms on the user's KEYRING: ccache so that the user can write to it
- suppress an error message if a KEYRING: ccache we're about to destroy has
  already been revoked

* Fri Oct 26 2007 Nalin Dahyabhai <nalin at redhat.com> - 2.2.20-1
- move temporary ccaches which aren't used for serializing from FILE: type
  into MEMORY: type
- don't barf during credential refresh when $KRB5CCNAME isn't set

perl-Crypt-OpenSSL-Bignum-0.04-1.fc9
------------------------------------
* Fri Nov 09 2007 Wes Hardaker <wjhns174 at hardakers.net> - 0.04-1
- Update to upstream 0.4
- GPL to GPL+ based on LICENSE file
- Include new LICENSE file
perl-Crypt-OpenSSL-X509-0.5-1.fc9
---------------------------------
* Fri Nov 09 2007 Wes Hardaker <wjhns174 at hardakers.net> - 0.5-1
- update to upstream 0.5 containing a MANIFEST fix
- Add Test::Pod and Module::Install to build requirements
perl-Digest-SHA-5.45-1.fc9
--------------------------
* Fri Nov 09 2007 Wes Hardaker <wjhns174 at hardakers.net> - 5.45-1
- Update to upstream 5.45
- Change license to match new licensing tags

plplot-5.7.4-5.fc9
------------------
* Fri Nov 09 2007 - Orion Poplawski <orion at cora.nwra.com> - 5.7.4-5
- Update to latest svn: adds cairo, drops plmeta, plrender
- Rebuild for new octave api

policycoreutils-2.0.31-14.fc9
-----------------------------
* Fri Nov 09 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-14
- Fix semanage to handle state where policy.xml is not installed

ppp-2.4.4-3
-----------
* Fri Nov 09 2007 Martin Nagy <mnagy at redhat.com> 2.4.4-3
- removed undesired files from the package (#241753)

scim-pinyin-0.5.91-21.fc9
-------------------------
* Fri Nov 09 2007 Huang Peng <phuang at redhat.com> - 0.5.91-21
- Save user data in temp files, and then overwrite old files to fix bug 237439.

sysstat-8.0.2-3.fc9
-------------------
* Fri Nov 09 2007 Ivana Varekova <varekova at redhat.com> - 8.0.2-3
- used macros instead of var, etc

system-config-firewall-1.0.10-1.fc9
-----------------------------------
* Fri Nov 09 2007 Thomas Woerner <twoerner at redhat.com> 1.0.10-1
- fixed problem with network devices (rhbz#331671)
- dropped obsolete translation no.po (rhbz#332331)

vsftpd-2.0.5-20.fc9
-------------------
* Thu Nov 08 2007 Martin Nagy <mnagy at redhat.com> - 2.0.5-20
- Correct calling of pam_end (#235843).

xorg-x11-drv-mouse-1.2.3-2.fc9
------------------------------
* Fri Nov 09 2007 Adam Jackson <ajax at redhat.com> 1.2.3-2
- mouse-1.2.3-sleep-less.patch: Don't usleep(300000) at exit.

xorg-x11-proto-devel-7.3-5.fc9
------------------------------
* Fri Nov 09 2007 Kristian H??gsberg <krh at redhat.com> - 7.3-5
- Bump and rebuild.

xpdf-1:3.02-4.fc9
-----------------
* Fri Nov 09 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1:3.02-4
- resolve 372461, 372471, 372481

yelp-2.20.0-6.fc9
-----------------
* Fri Nov 09 2007 Matthew Barnes <mbarnes at redhat.com> - 2.20.0-6
- Rebuild against gecko-libs 1.8.1.9.

* Mon Nov 05 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-5
- Fix a crash in search (#361041)

Broken deps for i386
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.i386 requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.i386 requires libmtp.so.6
	anaconda - 11.3.0.50-2.i386 requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.i386 requires libdhcp.so.1
	anaconda - 11.3.0.50-2.i386 requires libdhcp6client-0.10.so.0
	blam - 1.8.3-9.fc8.i386 requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.i386 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.i386 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.i386 requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	kst-fits - 1.4.0-8.fc8.i386 requires cfitsio = 0:3.040
	mkinitrd - 6.0.19-4.fc9.i386 requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc9.i386 requires libdhcp6client-0.10.so.0
	openoffice.org-core - 1:2.3.0-6.6.fc8.i386 requires libhunspell-1.1.so.0
	openvrml-devel - 0.16.6-6.fc9.i386 requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.i386 requires firefox = 0:2.0.0.8
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.i386 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.i386 requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.i386 requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.i386 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1



Broken deps for x86_64
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.x86_64 requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.x86_64 requires libmtp.so.6()(64bit)
	amarok - 1.4.7-7.fc8.i386 requires libmtp.so.6
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp4client-3.0.6.so.0()(64bit)
	blam - 1.8.3-9.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.x86_64 requires gecko-devel = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.i386 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.x86_64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	kst-fits - 1.4.0-8.fc8.x86_64 requires cfitsio = 0:3.040
	mkinitrd - 6.0.19-4.fc9.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc9.i386 requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc9.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	openoffice.org-core - 1:2.3.0-6.6.fc8.x86_64 requires libhunspell-1.1.so.0()(64bit)
	openvrml-devel - 0.16.6-6.fc9.i386 requires firefox-devel = 0:2.0.0.8
	openvrml-devel - 0.16.6-6.fc9.x86_64 requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.x86_64 requires firefox = 0:2.0.0.8
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.x86_64 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.x86_64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.x86_64 requires libtotem-plparser.so.9()(64bit)
	rhythmbox - 0.11.2-11.fc9.i386 requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.i386 requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1



Broken deps for ppc
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.ppc requires libmtp.so.6
	amarok - 1.4.7-7.fc8.ppc64 requires libmtp.so.6()(64bit)
	anaconda - 11.3.0.50-2.ppc requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.ppc requires libdhcp.so.1
	anaconda - 11.3.0.50-2.ppc requires libdhcp6client-0.10.so.0
	blam - 1.8.3-9.fc8.ppc requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.ppc requires gecko-devel = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.ppc64 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.ppc requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.ppc requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	kst-fits - 1.4.0-8.fc8.ppc requires cfitsio = 0:3.040
	mkinitrd - 6.0.19-4.fc9.ppc requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc9.ppc requires libdhcp6client-0.10.so.0
	openoffice.org-core - 1:2.3.0-6.6.fc8.ppc requires libhunspell-1.1.so.0
	openvrml-devel - 0.16.6-6.fc9.ppc64 requires firefox-devel = 0:2.0.0.8
	openvrml-devel - 0.16.6-6.fc9.ppc requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.ppc requires firefox = 0:2.0.0.8
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libtotem-plparser.so.9()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.ppc requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)



Broken deps for ppc64
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc64 requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.ppc64 requires libmtp.so.6()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	epiphany - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.ppc64 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.ppc64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	kst-fits - 1.4.0-8.fc8.ppc64 requires cfitsio = 0:3.040
	mkinitrd - 6.0.19-4.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	openoffice.org-core - 1:2.3.0-6.6.fc8.ppc64 requires libhunspell-1.1.so.0()(64bit)
	openvrml-devel - 0.16.6-6.fc9.ppc64 requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.ppc64 requires firefox = 0:2.0.0.8
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc64 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libtotem-plparser.so.9()(64bit)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)





From nphilipp at redhat.com  Sat Nov 10 12:41:41 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sat, 10 Nov 2007 13:41:41 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194533901.9673.433.camel@mccallum.corsepiu.local>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<1194533901.9673.433.camel@mccallum.corsepiu.local>
Message-ID: <1194698501.4580.28.camel@gibraltar.str.redhat.com>

On Thu, 2007-11-08 at 15:58 +0100, Ralf Corsepius wrote:
> On Thu, 2007-11-08 at 09:31 -0500, Jonathan S. Shapiro wrote:
> > I have to say that since we switched to mercurial we haven't looked
> > back. We are finding advantages to distributed VCS even though our
> > workflow model is basically centralized.
> > 
> > For purposes of centralized workflow, the main change is that
> > centralized processing is triggered by "push" rather than by "commit".
> > With this exception, the workflow is basically unchanged relative to
> > other centralized workflows.
> Right things are different, that's all.

Welcome to the 21st century (SCNR).

When talking about the Fedora packaging repository, the only real
difference would be the use of "hg ci; hg push" instead of "cvs ci".
This could easily be wrapped into a "make commit" target which would
make the underlying VCS implementation really uninteresting to the
packager.

> > What hg is buying us is the following:
> [..]
> > 
> > I'm not pushing for any change. I'm just trying to answer the workflow
> > question.
> Where in Fedora's package development would you see niches to apply
> these aspects? I don't see any.
> 
> Finally, being a long term CVS user, would has very mixed experiences
> wrt. SVN, and who has recently been confronted with both git and
> mercurial, I can't deny finding both git and hg as not to be suitable
> for centralized development. They don't really buy much.

Would you elaborate on that? Without examples where these tools
allegedly are lacking this is only your opinion.

I have switched over several of my projects from CVS to mercurial and
have found that everything I did with CVS I could do with mercurial, but
with much less hassle.

For example, merging between branches can become hairy with CVS, as
noted in the Cederqvist[1]: "[...] If you just use the cvs update -j
R1fix m.c command again, CVS will attempt to merge again the changes
which you have already merged, which can have undesirable side
effects.[...]". Modern VCSes remember what I have merged already and
only attempt to merge the rest, with them branching and merging are easy
and enjoyable every-day operations.

As for other areas where CVS and other VCSs are lacking, I'd suggest
viewing "Tech Talk: Linus Torvalds on git"[2].

[1]: http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_5.html#SEC61
[2]: http://www.youtube.com/watch?v=4XpnKHJAok8

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Sat Nov 10 12:49:06 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sat, 10 Nov 2007 13:49:06 +0100
Subject: Update form F7 to F8 freeze at 26%
In-Reply-To: <4733676F.2000209@gmx.net>
References: <4733676F.2000209@gmx.net>
Message-ID: <1194698946.4580.30.camel@gibraltar.str.redhat.com>


On Thu, 2007-11-08 at 20:45 +0100, Frank B?ttner wrote:
> Hello,
> 
> I have try to update an F7 installation to F8, but at dependency check
> it freeze all ways at 26%.
> It happens in the text and gui mode.
> anaconda use 100% CPU and 97% of all memory.
> 
> Idear how get out, what goes wrong?

https://bugzilla.redhat.com/show_bug.cgi?id=371111

-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Sat Nov 10 13:07:28 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sat, 10 Nov 2007 14:07:28 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071108094720.1a18ded1@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
Message-ID: <1194700048.4580.39.camel@gibraltar.str.redhat.com>

On Thu, 2007-11-08 at 09:47 -0500, Jesse Keating wrote:
> On Thu, 08 Nov 2007 09:31:09 -0500
> "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> 
> > What hg is buying us is the following:
[...]
> > I'm not pushing for any change. I'm just trying to answer the workflow
> > question.
> 
> Have you ever found yourself needing to do any of those things within
> the context of our Package VCS?

Wrong question. These are just additional benefits you get from using a
DVCS. The killer features I'd see in using e.g. git or mercurial over
CVS (and partly SVN) would be:

a) quick operations by avoiding round-trips to a remote server if not
necessary
b) easy branching and merging
c) atomic operations
d) co-maintainers (or maintainer apprentices) wouldn't need commit
access to the main repository
e) ability to do embargoed stuff like security fixes before they're
public

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Sat Nov 10 13:10:38 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sat, 10 Nov 2007 14:10:38 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194700048.4580.39.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
Message-ID: <1194700238.4580.41.camel@gibraltar.str.redhat.com>

On Sat, 2007-11-10 at 14:07 +0100, Nils Philippsen wrote:

> a) quick operations by avoiding round-trips to a remote server if not
> necessary
> b) easy branching and merging
> c) atomic operations
> d) co-maintainers (or maintainer apprentices) wouldn't need commit
> access to the main repository
> e) ability to do embargoed stuff like security fixes before they're
> public

f) ability to rename things, especially handy for re-worked patches in
our context

-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From alan at redhat.com  Sat Nov 10 13:21:39 2007
From: alan at redhat.com (Alan Cox)
Date: Sat, 10 Nov 2007 08:21:39 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <20071110095657.GA6631@roque.1407.org>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
Message-ID: <20071110132139.GC6788@devserv.devel.redhat.com>

On Sat, Nov 10, 2007 at 09:56:57AM +0000, Rui Miguel Silva Seabra wrote:
> > But I can accuse you of that whenever I like whether its true or not. So its
> > irrelevant to the discussion, its a totally specious argument.
> 
> In any normal case, the accuser has to prove your guilt.

In a civil dispute its balance of probability

> But as far as I have understood about patents, you have to prove your
> innocence.

In the US maybe. In other countries it is more complicated. In particular
in many of these countries you wouldn't contest the patent you would cite
the caselaw on patentability of software and business methods.

> I don't think it's an irrelevant or totally specious argument.

For europe I think it is. It doesn't help for the Red Hat case because
as a US company Red Hat is obliged to obey US law.



From fedora at camperquake.de  Sat Nov 10 15:13:08 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 10 Nov 2007 16:13:08 +0100
Subject: Automatic RPM provides for libraries
Message-ID: <20071110161308.2554226c@lain.camperquake.de>

Hi.

I just notices something strange on my local system and would
like to check if I screwed up or something in RPM changed.


Assume I package a library and the RPM file contains two files:

/usr/lib/libfoo.so.1 -> libfoo.so.1.0.0
/usr/lib/libfoo.so.1.0.0

Now, my experience so far was that the RPM file will (automagically)
Provide: libfoo.so.1

Now, several RPMs I built locally instead
Provide: libfoo.so.1.0.0

This kind of wreaks havoc with installed programs which depend on
the old requires.

Did I screw up?
Has RPM changed?
Has something in libfoo changed that causes this?



From jkeating at j2solutions.net  Sat Nov 10 15:42:45 2007
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 10 Nov 2007 10:42:45 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194700238.4580.41.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
Message-ID: <20071110104245.6b783490@j2solutions.net>

On Sat, 10 Nov 2007 14:10:38 +0100
Nils Philippsen <nphilipp at redhat.com> wrote:

> > a) quick operations by avoiding round-trips to a remote server if
> > not necessary
> > b) easy branching and merging
> > c) atomic operations
> > d) co-maintainers (or maintainer apprentices) wouldn't need commit
> > access to the main repository
> > e) ability to do embargoed stuff like security fixes before they're
> > public  
> 
> f) ability to rename things, especially handy for re-worked patches in
> our context

I don't disagree that those things are nice with DVCS.  What I question
is the amount of times they're necessary to warrant the extra
complexity of a DVCS thrown at every user.

And still I continue to hear just features of dvcs, but not applied to
a workflow for our Package vcs.

-- 
Jesse Keating RHCE      (jkeating.livejournal.com)
Fedora Project          (fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)



From rms at 1407.org  Sat Nov 10 15:59:55 2007
From: rms at 1407.org (Rui Miguel Silva Seabra)
Date: Sat, 10 Nov 2007 15:59:55 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <20071110132139.GC6788@devserv.devel.redhat.com>
References: <20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
Message-ID: <20071110155954.GC6631@roque.1407.org>

On Sat, Nov 10, 2007 at 08:21:39AM -0500, Alan Cox wrote:
> On Sat, Nov 10, 2007 at 09:56:57AM +0000, Rui Miguel Silva Seabra wrote:
> > > But I can accuse you of that whenever I like whether its true or not. So its
> > > irrelevant to the discussion, its a totally specious argument.
> > 
> > In any normal case, the accuser has to prove your guilt.
> 
> In a civil dispute its balance of probability
> 
> > But as far as I have understood about patents, you have to prove your
> > innocence.
> 
> In the US maybe. In other countries it is more complicated. In particular
> in many of these countries you wouldn't contest the patent you would cite
> the caselaw on patentability of software and business methods.
> 
> > I don't think it's an irrelevant or totally specious argument.
> 
> For europe I think it is. It doesn't help for the Red Hat case because
> as a US company Red Hat is obliged to obey US law.

Okay, thanks for your insight :)

Rui

-- 
P'tang!
Today is Prickle-Prickle, the 22nd day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?



From lesmikesell at gmail.com  Sat Nov 10 17:48:42 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sat, 10 Nov 2007 11:48:42 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071110104245.6b783490@j2solutions.net>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>	<20071108094720.1a18ded1@redhat.com>	<1194700048.4580.39.camel@gibraltar.str.redhat.com>	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
Message-ID: <4735EEFA.2040601@gmail.com>

Jesse Keating wrote:
> 
>>> a) quick operations by avoiding round-trips to a remote server if
>>> not necessary
>>> b) easy branching and merging
>>> c) atomic operations
>>> d) co-maintainers (or maintainer apprentices) wouldn't need commit
>>> access to the main repository
>>> e) ability to do embargoed stuff like security fixes before they're
>>> public  
>> f) ability to rename things, especially handy for re-worked patches in
>> our context
> 
> I don't disagree that those things are nice with DVCS.  What I question
> is the amount of times they're necessary to warrant the extra
> complexity of a DVCS thrown at every user.
> 
> And still I continue to hear just features of dvcs, but not applied to
> a workflow for our Package vcs.

And in particular, they don't describe how that workflow ensures that 
the central build system knows that all distributed operations are 
synchronized and what happens if they aren't.  I assume that's a solved 
problem with these systems since they don't make much sense otherwise, 
but...

--
   Les Mikesell
    lesmikesell at gmail.com



From pertusus at free.fr  Sat Nov 10 18:40:50 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 10 Nov 2007 19:40:50 +0100
Subject: Automatic RPM provides for libraries
In-Reply-To: <20071110161308.2554226c@lain.camperquake.de>
References: <20071110161308.2554226c@lain.camperquake.de>
Message-ID: <20071110184050.GB2817@free.fr>

On Sat, Nov 10, 2007 at 04:13:08PM +0100, Ralf Ertzinger wrote:
> Hi.
> 
> I just notices something strange on my local system and would
> like to check if I screwed up or something in RPM changed.
> 
> 
> Assume I package a library and the RPM file contains two files:
> 
> /usr/lib/libfoo.so.1 -> libfoo.so.1.0.0
> /usr/lib/libfoo.so.1.0.0
> 
> Now, my experience so far was that the RPM file will (automagically)
> Provide: libfoo.so.1

rpm automatically provides the soname of the library (if I'm not wrong). 
It may happen (as a bug or on purpose) that libfoo has libfoo.so.1.0.0 
as soname. In that case it is strange, however, to have the libfoo.so.1 
file. Do you have a precise example?

--
Pat



From kevin at scrye.com  Sat Nov 10 21:37:17 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 10 Nov 2007 14:37:17 -0700
Subject: Doxygen and multilib
In-Reply-To: <Pine.GSO.4.60.0711050025260.8239@igloo.df.lth.se>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
	<d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
	<d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>
	<d9c612bf0711041226p339a189ex46b19067422a02a9@mail.gmail.com>
	<d9c612bf0711041523u17a6b72csaf79334053e0339a@mail.gmail.com>
	<Pine.GSO.4.60.0711050025260.8239@igloo.df.lth.se>
Message-ID: <20071110143717.374fd239@ghistelwchlohm.scrye.com>

On Mon, 5 Nov 2007 00:27:26 +0100 (CET)
triad at df.lth.se (Linus Walleij) wrote:

> On Sun, 4 Nov 2007, Christopher Stone wrote:
> 
> > After more investigation, I found out this bug is already fix in
> > doxygen-1.5.3.  Than never pushed the new release, rawhide is still
> > using 1.5.2.
> 
> Hm, hm, looks like that bug will then just go away shortly.

Does that mean we should mass rebuild all the doxygen dependent
packages (at least in rawhide) to fix any multilib issues caused by
this bug? 

> Linus

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071110/f4b2c4a5/attachment.sig>

From rc040203 at freenet.de  Sun Nov 11 02:36:32 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 11 Nov 2007 03:36:32 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711082222.01473.opensource@till.name>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711081840.27702.opensource@till.name>
	<1194546890.9673.469.camel@mccallum.corsepiu.local>
	<200711082222.01473.opensource@till.name>
Message-ID: <1194748592.2765.27.camel@mccallum.corsepiu.local>


On Thu, 2007-11-08 at 22:21 +0100, Till Maas wrote:
> On Do November 8 2007, Ralf Corsepius wrote:
> > On Thu, 2007-11-08 at 18:40 +0100, Till Maas wrote:
> > > On Mi November 7 2007, Andy Shevchenko wrote:
> 
> > > > And second, I doubt in usefull status of this feature. IMHO, in
> > > > practice (another words 'very often') you need to make diff between
> > > > vcs' *.spec and current. You just make copy *.spec to *.spec.orig and
> > > > use simple diff command.
> > >
> > > How can I do this when I have uncommited changes in the spec, but there
> > > is a newer version in the repository?
> >
> > How is that a problem with CVS? With CVS you typically work on a
> > checkout, so it's up to you how to handle mergers.
> 
> Where do I get the specfile that I could copy to .spec.orig to create a diff 
> in this case? E.g. following the described procedure:
> 
> cvs commit && cp -a *.spec *.spec.orig
> vim *.spec
> cvs up *.spec
> [now changes from the repository are merged]
> 
> How can I now do a diff that shows the changes between my working copy and the 
> contents of the repository?
cvs diff -u *.spec

Ralf




From peter at thecodergeek.com  Sun Nov 11 04:34:39 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Sat, 10 Nov 2007 20:34:39 -0800
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194748592.2765.27.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711081840.27702.opensource@till.name>
	<1194546890.9673.469.camel@mccallum.corsepiu.local>
	<200711082222.01473.opensource@till.name>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
Message-ID: <1194755679.27165.3.camel@localhost6.localdomain6>

On Sun, 2007-11-11 at 03:36 +0100, Ralf Corsepius wrote:
> cvs diff -u *.spec

Meld will graphically show you the differences, if that's your
preference. Personally, I like the visual cues of syntax-highlighting,
provided by the colordiff tool. So my diff checking tends to be:

$ cvs diff -u branch-dir/ | colordiff | less -R

Of course, this is very tedious to type, so I've just set a cvsdiff
function in my .bash_profile that makes it much simpler:

cvsdiff() { cvs diff -u "$@" | colordiff | less -R }

Then it's a simple "cvsdiff foo/bar.spec" etc. to check my working copy
versus what's in the CVS tree currently. Bash-completion then makes that
"cvsd<tab>" :)
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071110/fdb6616b/attachment.sig>

From gafton at gafton.net  Sun Nov 11 05:49:46 2007
From: gafton at gafton.net (Cristian Gafton)
Date: Sun, 11 Nov 2007 00:49:46 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <473361CB.1040107@redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<473361CB.1040107@redhat.com>
Message-ID: <1194760186.11318.135.camel@alienpad.rpath.com>

On Thu, 2007-11-08 at 13:21 -0600, Mike McGrath wrote:

> We've tried this in the past a couple of times.  The problem is we need 
> someone that has these qualities:
> 
> 1) A vision from developer to build system on how this is supposed to work.
> 2) Time to write up and convince others its the right way to go.
> 3) Time to proof of concept it and implement it
> 4) Time to work with the infrastructure team on a migration plan
> 5) A little bit of craziness.
> 
> I hate CVS like the next guy, but it turns out converting to something 
> else is a very large commitment. 

Above and beyond the required development time, you need somebody
willing to push, shove, coerce, scream, threaten, scare and otherwise
will the new system into existence. I still hold in my mail archives a
bunch of nastygrams from back when the current setup was introduced,
some from the very folks who are very friendly to the system today...

I thought I'd drop in to mention that judging from the current size of
this thread, anyone who takes up "write up and convince others its the
right way to go" has a very, very hard task.

Cristian
-- 
Cristian Gafton
gafton at gafton.net



From mmahut at fedoraproject.org  Sun Nov 11 10:46:59 2007
From: mmahut at fedoraproject.org (Marek Mahut)
Date: Sun, 11 Nov 2007 11:46:59 +0100
Subject: Fedora Astronomy spin
Message-ID: <4736DDA3.6070101@fedoraproject.org>

Hello Fedora developers,

I want to build a Fedora spin for astronomers and astrophysicists. In
first place, I've proposed it as Feature, but now that already 3 people
want to help this project, I think about special Astronomy SIG which
will be responsible for this spin and other astronomy packages. The
second argument for this is that fesco isn't sure if spins should be
considered as features.

   http://fedoraproject.org/wiki/Features/FedoraAstronomy

If you are interested to join and help us, please add your name to the
wiki under section "interested people".

   Thank you!

-- 
Marek Mahut                           http://www.fedoraproject.org/
Fedora Project                              http://www.jamendo.com/



From laroche at redhat.com  Sun Nov 11 10:51:49 2007
From: laroche at redhat.com (Florian La Roche)
Date: Sun, 11 Nov 2007 11:51:49 +0100
Subject: gitweb performance of summary page
In-Reply-To: <20071102112954.GA7005@dudweiler.stuttgart.redhat.com>
References: <20071102112954.GA7005@dudweiler.stuttgart.redhat.com>
Message-ID: <20071111105149.GA9352@dudweiler.stuttgart.redhat.com>

On Fri, Nov 02, 2007 at 12:29:54PM +0100, Florian La Roche wrote:
> Loading the summary page can still take quite some time
> as this server is also a Fedora mirror, so the overview
> page often needs to read in all data from disk.


For the summary page gitweb calls for each project the
external command:
    git for-each-ref --format=%(committer) --sort=-committerdate --count=1 refs/heads

If the data is not already cached, this adds quite some time until
the overview page is ready. While seeing the time of the last commit
is pretty nice, it should also not be really essential, so I have
just removed it for now. The right thing todo would be to cache this
time somehow intelligently. Even better is to read new patches
coming in via RSS instead of looking at the summary page.


> If anyone feels like hacking on gitweb: The main summary
> page only displays the time of last change as special info
> on the individual projects, so if that part would not call
> "git" as external app, then loading that page should be much
> less of a resource problem.


Resolved for me, but might wait for an even better patch.

regards,

Florian La Roche



From ville.skytta at iki.fi  Sun Nov 11 11:06:06 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 11 Nov 2007 13:06:06 +0200
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194755679.27165.3.camel@localhost6.localdomain6>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
	<1194755679.27165.3.camel@localhost6.localdomain6>
Message-ID: <200711111306.06913.ville.skytta@iki.fi>

On Sunday 11 November 2007, Peter Gordon wrote:
>
> $ cvs diff -u branch-dir/ | colordiff | less -R
>
> Of course, this is very tedious to type

/usr/bin/cdiff (in the colordiff package) would simplify that a bit :)



From peter at thecodergeek.com  Sun Nov 11 11:37:30 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Sun, 11 Nov 2007 03:37:30 -0800
Subject: colordiff & "cvs diff -u" [Was: Re: When will be CVS replaced by
	modern version control system?]
In-Reply-To: <200711111306.06913.ville.skytta@iki.fi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
	<1194755679.27165.3.camel@localhost6.localdomain6>
	<200711111306.06913.ville.skytta@iki.fi>
Message-ID: <1194781050.7485.6.camel@tuxhugs>

On Sun, 2007-11-11 at 13:06 +0200, Ville Skytt? wrote:
> On Sunday 11 November 2007, Peter Gordon wrote:
> >
> > $ cvs diff -u branch-dir/ | colordiff | less -R
> >
> > Of course, this is very tedious to type
> 
> /usr/bin/cdiff (in the colordiff package) would simplify that a bit :)

Er, thanks for the suggestion; but..

Unfortunately, it comes with no man/info page. If I try its --help
option, it shows me the help output for gzip (eh? O_o). 

In amusing twist of irony, Google is not helpful either. (It gives me
results for the C. difficile toxin which is apparently a sign of very
bad gastrointestinal happenings...)

Where would I find appropriate documentation for this tool? I know I'm
missing something somewhere but it's 3:36 AM right now and my brain's
not entirely efficient. T_T

Thanks again!
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/3cbf450e/attachment.sig>

From ville.skytta at iki.fi  Sun Nov 11 11:49:48 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 11 Nov 2007 13:49:48 +0200
Subject: colordiff & "cvs diff -u" [Was: Re: When will be CVS replaced
	by modern version control system?]
In-Reply-To: <1194781050.7485.6.camel@tuxhugs>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711111306.06913.ville.skytta@iki.fi>
	<1194781050.7485.6.camel@tuxhugs>
Message-ID: <200711111349.49427.ville.skytta@iki.fi>

On Sunday 11 November 2007, Peter Gordon wrote:
> On Sun, 2007-11-11 at 13:06 +0200, Ville Skytt? wrote:
> > On Sunday 11 November 2007, Peter Gordon wrote:
> > > $ cvs diff -u branch-dir/ | colordiff | less -R
> > >
> > > Of course, this is very tedious to type
> >
> > /usr/bin/cdiff (in the colordiff package) would simplify that a bit :)
[...]
> Where would I find appropriate documentation for this tool?

I'm not aware of anything else besides "less /usr/bin/cdiff".



From buildsys at redhat.com  Sun Nov 11 12:16:36 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 11 Nov 2007 07:16:36 -0500
Subject: rawhide report: 20071111 changes
Message-ID: <200711111216.lABCGa7M003933@porkchop.devel.redhat.com>

 

 
Updated Packages:

amarok-1.4.7-8.fc9
------------------
* Sat Nov 10 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-8
- rebuild

* Sun Oct 07 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-7
- use xdg-open to start the configured browser

* Sat Oct 06 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.4.7-6
- add "alpha" to the list of archs where HelixPlayer is not available
  (bug 318431)

blam-1.8.3-10.fc9
-----------------
* Tue Nov 06 2007 Peter Gordon <peter at thecodergeek.com> - 1.8.3-10
- Rebuild for new Gecko (Firefox 2.0.0.9).
- Bump Release to 10 to maintain upgrade path from F-8.

* Sat Sep 08 2007 Peter Gordon <peter at thecodergeek.com> - 1.8.3-8
- Add mono-web runtime dependency; fixes bugs 282331 (Blam does not open
  links with commas correctly) and 277561 (Blam does nothing useful).

* Fri Aug 17 2007 Peter Gordon <peter at thecodergeek.com> - 1.8.3-7
- Add gnome-sharp runtime dependency; fixes bug 253200.
- Update License tag in accordance with new guidelines.

chmsee-1.0.0-1.29.fc9
---------------------
* Sat Nov 10 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.29
- should be BuildRequires: gecko-devel
- but since /usr/lib/gecko-libs-1.8.1.9 is still not there, this build will not work

* Sat Nov 10 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.28
- try build for gecko-libs-1.8.1.9

* Sat Aug 11 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.23
- update to 1.0.0
- build for firefox-2.0.0.6
- update License field to GPLv2

emacs-vm-8.0.5.504-1.fc9
------------------------
* Sun Nov 11 2007 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 8.0.5.504-1
- Update to version 8.0.5
- Remove patch to fix Makefile from 8.0.3

epiphany-2.20.1-4.fc9
---------------------
* Sat Nov 10 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-4
- Rebuild against newer gecko

* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-3
- Rebuild against new dbus-glib

* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Add patch to allow epiphany to use the plugins wrapped by
  nspluginwrapper (#334751)

gail-1.20.1-2.fc9
-----------------
* Sun Nov 11 2007 Matthias Clasen <mclasen at redhat.com> - 1.20.1-2
- Fix a crash in gnome-system-log (#357211)

gossip-0.28-1.fc9
-----------------
* Sat Nov 10 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.28-1
- Update to 0.28.
- Disable help.
- Add BR on gnome-keyring-devel.

gtkmozembedmm-1.4.2.cvs20060817-15.fc9
--------------------------------------
* Fri Nov 09 2007 Ha??kel Gu??mar <karlthered at gmail.com> - 1.4.2.cvs20060817-15
- rebuild against gecko-libs 1.8.1.9

* Fri Aug 10 2007 Ha??kel Gu??mar <karlthered at gmail.com> - 1.4.2.cvs20060817-14
- rebuild against gecko-libs 1.8.1.6

* Fri Jul 20 2007 Jesse Keating <jkeating at redhat.com> - 1.4.2.cvs20060817-13
- rebuild against gecko-libs 1.8.1.5
- Extend path arch patch to ppc64 as well

kdelibs4-3.95.2-2.fc9
---------------------
* Sat Nov 10 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.2-2
- BR: strigi-devel >= 0.5.7, soprano-devel >= 1.97.1
- License: LGPLv2 (only)

kismet-0.0.2007.10.R1-2.fc9
---------------------------
* Sat Nov 10 2007 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.0.2007.10.R1-2
- rebuilt for new libexpat

kst-1.4.0-9.fc9
---------------
* Sat Nov 10 2007 Matthew Truch <matt at truch.net> - 1.4.0-9
- Bump build to pick up new cfitsio

openoffice.org-1:2.3.0-6.7.fc9
------------------------------
* Fri Nov 09 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.0-6.7
- rebuild for hunspell

openvrml-0.16.6-8.fc9
---------------------
* Fri Nov 09 2007 Braden McDaniel  <braden at endoframe.com> - 0.16.6-8
- Backed out inadvertent change.

* Fri Nov 09 2007 Braden McDaniel  <braden at endoframe.com> - 0.16.6-7
- Updated firefox dependency to 2.0.0.9.

* Fri Oct 26 2007 Braden McDaniel  <braden at endoframe.com>
- Updated license tags to LGPLv2+, GPLv2+.

revisor-2.0.5-7.fc9
-------------------
* Sat Nov 10 2007 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.0.5-7
- Minor bugfixes in packaging

soprano-1.97.1-2.fc9
--------------------
* Sat Nov 10 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.97.1-2
- glibc/open patch

* Sat Nov 10 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.97.1-1
- soprano-1.97.1 (soprano 2 beta 4)

wqy-bitmap-fonts-0.9.9-0.fc9
----------------------------
* Sat Nov 10 2007 Qianqian Fang <fangqq at gmail.com> 0.9.9-0
- include the complete CJK Extension A glyphs (6,582 x 4 point sizes), provide full coverage to Standard GB18030
- first round standard-compliance validation for all CJK basic characters between U4E00-U9FA5
- numerous bitmap glyph fine-tuning and corrections

Broken deps for i386
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.i386 requires PyQt = 0:3.17.1
	anaconda - 11.3.0.50-2.i386 requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.i386 requires libdhcp.so.1
	anaconda - 11.3.0.50-2.i386 requires libdhcp6client-0.10.so.0
	epiphany-extensions - 2.20.1-2.fc8.i386 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.i386 requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	mkinitrd - 6.0.19-4.fc9.i386 requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc9.i386 requires libdhcp6client-0.10.so.0
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.i386 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.i386 requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.i386 requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.i386 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1



Broken deps for x86_64
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.x86_64 requires PyQt = 0:3.17.1
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp4client-3.0.6.so.0()(64bit)
	epiphany-extensions - 2.20.1-2.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.x86_64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	mkinitrd - 6.0.19-4.fc9.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc9.i386 requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc9.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.x86_64 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.x86_64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.x86_64 requires libtotem-plparser.so.9()(64bit)
	rhythmbox - 0.11.2-11.fc9.i386 requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.i386 requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1



Broken deps for ppc
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc requires PyQt = 0:3.17.1
	anaconda - 11.3.0.50-2.ppc requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.ppc requires libdhcp.so.1
	anaconda - 11.3.0.50-2.ppc requires libdhcp6client-0.10.so.0
	epiphany-extensions - 2.20.1-2.fc8.ppc requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.ppc requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	mkinitrd - 6.0.19-4.fc9.ppc requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc9.ppc requires libdhcp6client-0.10.so.0
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libtotem-plparser.so.9()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.ppc requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)



Broken deps for ppc64
----------------------------------------------------------
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc64 requires PyQt = 0:3.17.1
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	epiphany-extensions - 2.20.1-2.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.ppc64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	mkinitrd - 6.0.19-4.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc64 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libtotem-plparser.so.9()(64bit)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)





From nphilipp at redhat.com  Sun Nov 11 13:53:11 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 14:53:11 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071110104245.6b783490@j2solutions.net>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
Message-ID: <1194789191.3575.5.camel@gibraltar.str.redhat.com>


On Sat, 2007-11-10 at 10:42 -0500, Jesse Keating wrote: 
> On Sat, 10 Nov 2007 14:10:38 +0100
> Nils Philippsen <nphilipp at redhat.com> wrote:
> 
> > > a) quick operations by avoiding round-trips to a remote server if
> > > not necessary
> > > b) easy branching and merging
> > > c) atomic operations
> > > d) co-maintainers (or maintainer apprentices) wouldn't need commit
> > > access to the main repository
> > > e) ability to do embargoed stuff like security fixes before they're
> > > public  
> > 
> > f) ability to rename things, especially handy for re-worked patches in
> > our context
> 
> I don't disagree that those things are nice with DVCS.  What I question
> is the amount of times they're necessary to warrant the extra
> complexity of a DVCS thrown at every user.
> 
> And still I continue to hear just features of dvcs, but not applied to
> a workflow for our Package vcs.

In that case, enjoy the list of problem areas below, i.e. where
non-distributed VCSs stand in the way. I've marked things where the
workflow would benefit with "===> ... <===" ;-).

How I see it is that the features of DVCSs are often deficiencies in
non-distributed VCSs. Using a better VCS would be worthwhile because of
the many situations where CVS stands in the way (and SVN isn't much
better):

- Slow operations, almost(?(*)) everything needs server round-trips,
just one example: for the CVS changelog I like to grep the changes in
the RPM %changelog. It usually takes a 10-20 seconds round-trip to
generate the diff of the spec file. That sucks. Same goes for tagging
though this isn't as tragic as you can chain the build after it in the
same make command. ===> I would be a good deal happier and probably more
productive if these operations were quicker <===.

(*) ok, just about everything with CVS. SVN manages to diff *against the
currently checked out revision* without a round trip. Big deal.

- Merging sucks with CVS. We currently have that byzantine setup of
not-real-branches-but-subdirectories specifically because merging with
CVS is an exercise in masochism and copying files around is much easier.
I thought that this was a mistake from the beginning, but with CVS that
wasn't obvious and when we did it there were few real alternatives.
Practically CVS is of no help for merging, the person in front of the
computer is effectively the VCS. Linus asks a good question in his
Google Techtalk speech (paraphrased): "How many of you merged branches
with CVS and enjoyed the experience?".

        - I regularly do the same release for 3 Fedora versions --
        Rawhide, F8, F7 nowadays -- (or more than one at least) and ===>
        it'd be so much better if I could change the spec file, add one
        patch, remove a second and update another just in the devel
        branch, then merge that changeset over to the other Fedora
        versions <===. If there are conflicts, the VCS shouldn't clutter
        up my files but run a tool like meld which lets me resolve the
        conflicts rather easily. And it should remember the merges, so I
        can merge again in the future and keep my sanity. With CVS/SVN,
        this is a no go.

        - Often I get bug reports with specific patches and related
        changed spec files. Again, often these changes are done against
        an older revision of the spec file so I need to re-do the
        changes so they match what is current. ===> If we used a DVCS,
        people could just e.g. "hg bundle" up their changes they did in
        their own repo, attach them to the bug or mail them to me, I
        could unbundle the changeset into the repo, merge and be happy
        <===.

These extra "complexities"(**) you mention, in fact the whole VCS
implementation, could easily be hidden behind "make [up|update]", "make
[commit|ci]", etc. Makefile targets.

(**): ... which I don't deem really complex. It took me about half an
hour to "master" the switch from CVS to Hg. Let me postulate that CVS
just isn't deemed as complex because we're used to it.

I know that we get by with using CVS, but I hope we're not content with
just getting by. CVS is at points so cumbersome that I think we're at a
point where we need reasons for staying with it rather than for moving
away from it. We consistently push the envelope in new technology in the
distribution, I think we should do the same in how the distribution is
built.

Mind that people mastered the "complexities" of having to deal with
bodhi as well, which was much more disruptive for someone who in the
past got by with "cvs up, <change stuff>, cvs ci, make tag build". If
they can do that, they can surely master using a DVCS, especially if
it's 90% command line compatible like Mercurial. If we don't hide the
used VCS and its complexity behind Makefile targets anyway that is.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Sun Nov 11 14:07:12 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 15:07:12 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <4735EEFA.2040601@gmail.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net> <4735EEFA.2040601@gmail.com>
Message-ID: <1194790032.3575.15.camel@gibraltar.str.redhat.com>

Hi Les,

On Sat, 2007-11-10 at 11:48 -0600, Les Mikesell wrote:

> And in particular, they don't describe how that workflow ensures that 
> the central build system knows that all distributed operations are 
> synchronized and what happens if they aren't.

that's actually easy. The now central and only repository would in fact
become one of many repositories, with one notable difference -- koji
would get its files from that repository. What is now "commit to central
repository, tag, build" would become "commit to local repository, tag,
push local changes to build repository, build". The synchronizing
between repositories is done by the DVCS tool or tools. Mind that DVCS
don't rely on every repository having the same content (that would be
rather pointless).

This way, projects where Fedora is upstream *cough*RHEL*cough* can have
their own build repositories, pull changes from the Fedora build
repository, and we could eventually pull back changes from theirs if
they are worthwhile. Another benefit which would avoid unnecessary
manual work.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From jkeating at redhat.com  Sun Nov 11 14:16:52 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 11 Nov 2007 09:16:52 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194790032.3575.15.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
	<4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
Message-ID: <20071111091652.6ca7536b@redhat.com>

On Sun, 11 Nov 2007 15:07:12 +0100
Nils Philippsen <nphilipp at redhat.com> wrote:

> "commit to local repository, tag,
> push local changes to build repository, build".

You can't just tag locally.  You need to ensure that the same tag
hasn't been applied to the central repo by somebody else while you were
"away".

Or maybe you want to just verify that at push time, and then yell at
the maintainer to fix his stuff because that tag already exists?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/3a45732e/attachment.sig>

From laroche at redhat.com  Sun Nov 11 14:55:59 2007
From: laroche at redhat.com (Florian La Roche)
Date: Sun, 11 Nov 2007 15:55:59 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071111091652.6ca7536b@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
	<4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
	<20071111091652.6ca7536b@redhat.com>
Message-ID: <20071111145559.GA13074@dudweiler.stuttgart.redhat.com>

On Sun, Nov 11, 2007 at 09:16:52AM -0500, Jesse Keating wrote:
> On Sun, 11 Nov 2007 15:07:12 +0100
> Nils Philippsen <nphilipp at redhat.com> wrote:
> 
> > "commit to local repository, tag,
> > push local changes to build repository, build".
> 
> You can't just tag locally.  You need to ensure that the same tag
> hasn't been applied to the central repo by somebody else while you were
> "away".
> 
> Or maybe you want to just verify that at push time, and then yell at
> the maintainer to fix his stuff because that tag already exists?

Hello Jesse,

I think over time we might reach a state where the commit into
the master automatically triggers the package rebuild.
And people can submit test builds to a more widely distributed
set of servers.

regards,

Florian La Roche



From nphilipp at redhat.com  Sun Nov 11 15:07:28 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 16:07:28 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194698501.4580.28.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<1194533901.9673.433.camel@mccallum.corsepiu.local>
	<1194698501.4580.28.camel@gibraltar.str.redhat.com>
Message-ID: <1194793648.3575.69.camel@gibraltar.str.redhat.com>

Just for the record, I'm not really interested in private forks of this
discussion. I'll answer some things now that I've received as a personal
mail, slightly edited/rephrased where necessary to protect anonymity. In
the future I won't be so forthcoming -- I'll just reply to the list
fully quoted.

Someone wrote:
> On Sat, 2007-11-10 at 13:41 +0100, Nils Philippsen wrote:
[...] 
> > I have switched over several of my projects from CVS to mercurial and
> > have found that everything I did with CVS I could do with mercurial, but
> > with much less hassle.
> You are the only person with write access, I presume?

Not really. In fact, just about every Fedora translator can -- either by
ways of Transifex or directly -- commit to the repositories.

> You are committing all of your local changes into hg, immediately when
> you change a file locally? (I am use to use checkouts with uncommitted
> local changes)

That's the idea. With Hg (and git and others likely, too), you can
commit every small change because committing isn't expensive. This way I
can easily revert things I broke in between (again without time
consuming network round trips).

> Whenever I use hg I repeatedly find myself in endless
> "pull/merge/commit/push" loops I couldn't get out of. In the end
> causing me to loose changes/patches and having to resurrect work from
> other sources.

With every VCS where more than one person can commit -- distributed or
not -- you have that problem: The person second to commit must bear the
burden of merging. It's only that Hg, git, ... make merging much simpler
than you're used to from CVS.

Take a situation where someone commits a change to a file just before I
wanted to do that. With CVS it goes like this:

nils at gibraltar:~/test/vcs/cvstest/co2> cvs ci
cvs commit: Examining .
cvs commit: Up-to-date check failed for `a'
cvs commit: Examining CVSROOT
cvs [commit aborted]: correct above errors first!

Then you need to "cvs up", which will implicitely try to merge the
changes. In the event of conflicts CVS will garble the file with
snippets of the conflicting revisions ("<<<...", "===...", ">>>..."),
you need to resolve the conflict in the file without aid of
3way-diff-tools like meld and commit. Hopefully you haven't left any of
the conflict markers in the file at this point ;-).

With Mercurial it goes like this:

nils at gibraltar:~/test/vcs/hgtest/co2> hg ci
No username found, using 'nils at gibraltar.str.redhat.com' instead
nils at gibraltar:~/test/vcs/hgtest/co2> hg push
pushing to /home/nils/test/vcs/hgtest/repo
searching for changes
abort: push creates new remote branches!
(did you forget to merge? use push -f to force)

Then I run "hg pull -u; hg merge", it looks like this:

nils at gibraltar:~/test/vcs/hgtest/co2> hg pull -u
pulling from /home/nils/test/vcs/hgtest/repo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
not updating, since new heads added
(run 'hg heads' to see heads, 'hg merge' to merge)
nils at gibraltar:~/test/vcs/hgtest/co2> hg merge
merging a
conflicts detected in /home/nils/test/vcs/hgtest/co2/a
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

In this case the merger had conflicts, "hg merge" automatically invoked
"meld" which allowed me to easily resolve the conflict, then I committed
again and pushed.

These two ways look very similar to me, with the notable exception of
the automatic invocation of meld in the Hg case (which is of great help
when resolving conflicts).

> Another regression in using hg: WAY more interactive actions required to
> achieve the same purpose.

"cvs up" vs. "hg pull -u" and "cvs ci" vs. "hg ci; hg push" aren't way
more in my book. In fact, you wouldn't need to (shouldn't!) push with
every single small commit. In our case of packaging, you only needed to
push before building or when you're done for the day, leave for lunch,
after every few commits if you're afraid of merging...

To avoid "WAY more interactive actions", we could easily do the VCS
actions as Makefile targets, then let "tag" depend on "push" (or let it
implicitly do that). That way packagers wouldn't have to adapt to
changes even if we switched from a VCS to clerks filing things on paper
and people wouldn't notice a thing (except that things were slightly
slower than with CVS ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From lesmikesell at gmail.com  Sun Nov 11 15:25:26 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 11 Nov 2007 09:25:26 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194790032.3575.15.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>	<20071108094720.1a18ded1@redhat.com>	<1194700048.4580.39.camel@gibraltar.str.redhat.com>	<1194700238.4580.41.camel@gibraltar.str.redhat.com>	<20071110104245.6b783490@j2solutions.net>
	<4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
Message-ID: <47371EE6.8090901@gmail.com>

Nils Philippsen wrote:

>> And in particular, they don't describe how that workflow ensures that 
>> the central build system knows that all distributed operations are 
>> synchronized and what happens if they aren't.
> 
> that's actually easy. The now central and only repository would in fact
> become one of many repositories, with one notable difference -- koji
> would get its files from that repository. What is now "commit to central
> repository, tag, build" would become "commit to local repository, tag,
> push local changes to build repository, build". The synchronizing
> between repositories is done by the DVCS tool or tools. Mind that DVCS
> don't rely on every repository having the same content (that would be
> rather pointless).

This is a different operation than having every developer have his own 
copy - or at least one in every location where development happens. The 
ability to work disconnected was being touted as a feature,  But what 
happens if a release needed to be done at the central build system and 
the work some remote developer thinks is committed has not actually made 
it there because it is still disconnected?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From nphilipp at redhat.com  Sun Nov 11 15:51:02 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 16:51:02 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071111091652.6ca7536b@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net> <4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
	<20071111091652.6ca7536b@redhat.com>
Message-ID: <1194796262.3575.107.camel@gibraltar.str.redhat.com>

On Sun, 2007-11-11 at 09:16 -0500, Jesse Keating wrote:
> On Sun, 11 Nov 2007 15:07:12 +0100
> Nils Philippsen <nphilipp at redhat.com> wrote:
> 
> > "commit to local repository, tag,
> > push local changes to build repository, build".
> 
> You can't just tag locally.  You need to ensure that the same tag
> hasn't been applied to the central repo by somebody else while you were
> "away".

And how's that different from CVS? Of course, "make tag" should take
things "upstream" to the "central" repository and yell if the tag
already exists. Been there, done that, you might want to take a look at
the Makefiles of my system-config-* packages(*). If a tag existed
already, either the tagging itself or the subsequent push fails.

(*): E.g. http://hg.fedoraproject.org/hg/hosted/system-config-users --
note that these have been written for slightly older Mercurial versions
where using the same tag was possible without --force'ing things. They
could be a bit simpler with current versions.

We could also resort to letting "koji build" do the tagging to keep
things more controlled -- i.e. "koji build <some changeset id>" would
checkout the package, attempt to "reserve"(**) the tag, build and tag on
success which would obviate the need for "make force-tag". Of course,
people should be prohibited from pushing changes to e.g. .hgtags for
such a scheme.

(**): or tag, build and eventually untag on failure. This would
coincidentally make starting multiple builds for the same tag impossible
which can or at least at some point could be done.

> Or maybe you want to just verify that at push time, and then yell at
> the maintainer to fix his stuff because that tag already exists?

I see no tangible difference to how things are today -- in both cases,
"make tag" (or "make build") fails.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Sun Nov 11 16:08:27 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 17:08:27 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <47371EE6.8090901@gmail.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net> <4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
	<47371EE6.8090901@gmail.com>
Message-ID: <1194797307.3575.126.camel@gibraltar.str.redhat.com>

On Sun, 2007-11-11 at 09:25 -0600, Les Mikesell wrote:

> This is a different operation than having every developer have his own 
> copy - or at least one in every location where development happens. The 
> ability to work disconnected was being touted as a feature,  But what 
> happens if a release needed to be done at the central build system and 
> the work some remote developer thinks is committed has not actually made 
> it there because it is still disconnected?

If you're disconnected, "make build" or a not yet existent "make commit"
fails. Of course you need a connection to get the build system to build
a package. But you can develop things locally (make srpm, make
i386, ..., test things) and e.g. easily revert changes that didn't work
out because you have a VCS available, even in a plane. The hurdle to
experiment with new things is much lower if you can easily get back to a
working state.

Being able to work disconnected (to a feasible extent) is just one
feature of a distributed VCS:

- Take a sponsor and a new contributor. With a DVCS, the new contributor
wouldn't need immediate write access to the build repository. He could
do his thing in his local repository (for which he wouldn't need
anybody's permission). His sponsor would check what he did (AFAIK
they're expected to keep an eye on what their sponsored people do) and
could pull changesets from that person's repo, or apply bundled
changesets that got sent around via mail, then build. If the sponsor has
enough trust in that person, write access can be granted and the
contributor can push/build by himself.

- I won't elaborate on embargoed security fixes again, neither will I do
that on the possibility of a two-way flow of changes between Fedora and
downstream (forked) distributions.
+
Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From laroche at redhat.com  Sun Nov 11 16:30:26 2007
From: laroche at redhat.com (Florian La Roche)
Date: Sun, 11 Nov 2007 17:30:26 +0100
Subject: patches for python-bugzilla
Message-ID: <20071111163026.GA14636@dudweiler.stuttgart.redhat.com>

Hello Will Woods,

I've upload patches to python-bugzilla to:
http://www.jur-linux.org/git/?p=python-bugzilla-laroche.git;a=summary

regards,

Florian La Roche



From nphilipp at redhat.com  Sun Nov 11 16:39:14 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 17:39:14 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194625074.9672.39.camel@gibraltar.str.redhat.com>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<20071107114158.6cf5f250@weaponx>
	<1194608262.9672.30.camel@gibraltar.str.redhat.com>
	<1194619376.9673.520.camel@mccallum.corsepiu.local>
	<1194625074.9672.39.camel@gibraltar.str.redhat.com>
Message-ID: <1194799154.3575.153.camel@gibraltar.str.redhat.com>

On Fri, 2007-11-09 at 17:17 +0100, Nils Philippsen wrote:
> On Fri, 2007-11-09 at 15:42 +0100, Ralf Corsepius wrote:
> > On Fri, 2007-11-09 at 12:37 +0100, Nils Philippsen wrote:
> > 
> > > - With a DVCS, we could put the several Fedora/EPEL versions into
> > > branches and merge between them. 
> > We could do the same if fedora's package CVS would have used real CVS
> > branches instead of branch directories.
> 
> "The use of [branching and merging with CVS] cripples the mind
> [...]" (sorry, Edsger). I like walking with my feet instead of having to
> use crutches.

Hyperbole provokes PMs (which have slipped under my radar so far).
Apologies for the hyperbole, here my answers (again slightly edited):

Someone wrote:
> Wrt. the implementation of "branches" in Fedora's package CVS, AFAICT,
> the only reason it has been done the way it currently is was RH's
> stubborness on ACLs[...].

We had dir-style non-branches long before we had ACLs (long before there
was a publicly writable repository). IMO it should be possible to set
ACLs for certain individual branches if you need it. I don't know if
that can be done with any VCS discussed.

> >  Note that branching is not even half
> > of the rent, merging is where things get tricky with CVS.
> It does a way better job on merging than e.g. hg does.

I've yet to see examples where merging between branches with CVS is
easier than merging between different branches in Hg or git. Even
experts on the matter of CVS[1] seem to differ:

"""
5.7 Merging from a branch several times
[...]
If you just use the cvs update -j R1fix m.c command again, CVS will
attempt to merge again the changes which you have already merged, which
can have undesirable side effects.

So instead you need to specify that you only want to merge the changes
on the branch which have not yet been merged into the trunk. To do that
you specify two `-j' options, and CVS merges the changes from the first
revision to the second revision. [...]
"""

With Hg (or git) I merge once, I merge twice or even umpteen times, I
don't care. They remember what I already merged and only attempt to
merge what's new. If there are conflicts in the new stuff, they won't
overwrite my files but let me resolve them in a 3way diff tool like
meld.

I'd like to read one specific example where merging in CVS is actually
easier than in Hg or git. I won't hold my breath.

> Also, cvs-branch merging is at least one magnitude easier than merging
> "branches" in VCS's which lack the concept of branches, such as git,
> hg, and svn.

Hg at least (I'm sure git as well) does know "named" branches just like
CVS, take a look at the "hg branch" command. Woot, several branches,
right there in your own repository!

Nils

References:
[1]: again the same link from the Cederqvist which AFAIK is considered
"The Reference" for CVS:
http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_5.html#SEC61
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From jamatos at fc.up.pt  Sun Nov 11 17:22:51 2007
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Sun, 11 Nov 2007 17:22:51 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <4734CB5B.1040605@gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<4734CB5B.1040605@gmail.com>
Message-ID: <200711111722.52795.jamatos@fc.up.pt>

On Friday 09 November 2007 21:04:27 David Boles wrote:
> You want a KDE based RPM type Linux distro?

This was useless and it only serves to add noise to the conversation, it is 
difficult to parse as well. Which bit do you want to stress, kde, rpm, linux 
or distribution?

-- 
Jos? Ab?lio



From fedora at camperquake.de  Sun Nov 11 17:34:08 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 11 Nov 2007 18:34:08 +0100
Subject: Automatic RPM provides for libraries
In-Reply-To: <20071110184050.GB2817@free.fr>
References: <20071110161308.2554226c@lain.camperquake.de>
	<20071110184050.GB2817@free.fr>
Message-ID: <20071111183408.12c20c73@lain.camperquake.de>

Hi.

On Sat, 10 Nov 2007 19:40:50 +0100, Patrice Dumas wrote

> > Now, my experience so far was that the RPM file will (automagically)
> > Provide: libfoo.so.1
> 
> rpm automatically provides the soname of the library (if I'm not
> wrong). It may happen (as a bug or on purpose) that libfoo has
> libfoo.so.1.0.0 as soname. In that case it is strange, however, to
> have the libfoo.so.1 file. Do you have a precise example?

Indeed, the library soname had changed between the two versions I
was looking at.

One current example is mcs (which is in Fedora, the currently built
version has a different soname from the version currently in CVS HEAD,
which I have not rebuilt yet, due to this problem)



From dgboles at gmail.com  Sun Nov 11 17:39:29 2007
From: dgboles at gmail.com (David Boles)
Date: Sun, 11 Nov 2007 12:39:29 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <200711111722.52795.jamatos@fc.up.pt>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<4734CB5B.1040605@gmail.com>
	<200711111722.52795.jamatos@fc.up.pt>
Message-ID: <47373E51.8050604@gmail.com>

Jos?? Matos wrote:
> On Friday 09 November 2007 21:04:27 David Boles wrote:
>> You want a KDE based RPM type Linux distro?
> 
> This was useless and it only serves to add noise to the conversation, it is 
> difficult to parse as well. Which bit do you want to stress, kde, rpm, linux 
> or distribution?


All of them of course. These are the most common complaints here with
Fedora. KDE. Lack of non FOSS support. Etc. That disto, the one I
mentioned, does/has all of these 'problems' solved.

If *I* was as unhappy with Fedora as these users appear to be I would
look elsewhere. And i would have do that a long time ago.

What do you think Jose? Better to switch or is it just easier to complain?
-- 


  David



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/1eedcf77/attachment.sig>

From lesmikesell at gmail.com  Sun Nov 11 18:05:56 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 11 Nov 2007 12:05:56 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194797307.3575.126.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>	<20071108094720.1a18ded1@redhat.com>	<1194700048.4580.39.camel@gibraltar.str.redhat.com>	<1194700238.4580.41.camel@gibraltar.str.redhat.com>	<20071110104245.6b783490@j2solutions.net>
	<4735EEFA.2040601@gmail.com>	<1194790032.3575.15.camel@gibraltar.str.redhat.com>	<47371EE6.8090901@gmail.com>
	<1194797307.3575.126.camel@gibraltar.str.redhat.com>
Message-ID: <47374484.7060502@gmail.com>

Nils Philippsen wrote:
>  
>> This is a different operation than having every developer have his own 
>> copy - or at least one in every location where development happens. The 
>> ability to work disconnected was being touted as a feature,  But what 
>> happens if a release needed to be done at the central build system and 
>> the work some remote developer thinks is committed has not actually made 
>> it there because it is still disconnected?
> 
> If you're disconnected, "make build" or a not yet existent "make commit"
> fails. Of course you need a connection to get the build system to build
> a package. But you can develop things locally (make srpm, make
> i386, ..., test things) and e.g. easily revert changes that didn't work
> out because you have a VCS available, even in a plane. The hurdle to
> experiment with new things is much lower if you can easily get back to a
> working state.
> 
> Being able to work disconnected (to a feasible extent) is just one
> feature of a distributed VCS:

Which still doesn't address what happens in practice when the remote 
repository containing changes that the central repo doing the official 
build needs is still disconnected - or how anyone knows about it. Or how 
the much larger conflicts that would be likely with the ability to do 
more work off line would be handled when they do reach the repo where 
the build is done.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From nphilipp at redhat.com  Sun Nov 11 18:34:00 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Sun, 11 Nov 2007 19:34:00 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <47374484.7060502@gmail.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net> <4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
	<47371EE6.8090901@gmail.com>
	<1194797307.3575.126.camel@gibraltar.str.redhat.com>
	<47374484.7060502@gmail.com>
Message-ID: <1194806040.3575.209.camel@gibraltar.str.redhat.com>


On Sun, 2007-11-11 at 12:05 -0600, Les Mikesell wrote:
> Nils Philippsen wrote:
> >  
> >> This is a different operation than having every developer have his own 
> >> copy - or at least one in every location where development happens. The 
> >> ability to work disconnected was being touted as a feature,  But what 
> >> happens if a release needed to be done at the central build system and 
> >> the work some remote developer thinks is committed has not actually made 
> >> it there because it is still disconnected?
> > 
> > If you're disconnected, "make build" or a not yet existent "make commit"
> > fails. Of course you need a connection to get the build system to build
> > a package. But you can develop things locally (make srpm, make
> > i386, ..., test things) and e.g. easily revert changes that didn't work
> > out because you have a VCS available, even in a plane. The hurdle to
> > experiment with new things is much lower if you can easily get back to a
> > working state.
> > 
> > Being able to work disconnected (to a feasible extent) is just one
> > feature of a distributed VCS:
> 
> Which still doesn't address what happens in practice when the remote 
> repository containing changes that the central repo doing the official 
> build needs is still disconnected - or how anyone knows about it.

That's the same if you don't commit your changes to the CVS repo before
building. For all practical purposes regarding this discussion, you can
equate a CVS commit with a Hg push. Without committing to the build
repository, there is nothing from which to build. Nothing new here.

>  Or how 
> the much larger conflicts that would be likely with the ability to do 
> more work off line would be handled when they do reach the repo where 
> the build is done.

You would be notified when pushing that the push would create new
branches in the upstream repository. Unless you were forcing the push
(not a good idea obviously), you would merge locally, whereby you would
be the one to resolve the conflicts. The automatic invocation of meld
(or another 3way diff tool) helps tremendously.

If anything it would be worse with CVS: when working disconnectedly, you
would have to resolve the conflicts, only that you would have to do so
without the help of the VCS -- only you and your vim (or emacs, or ...)
-- and in one go. With a DVCS, you could merge your individual changes
step by step instead of the whole work at once which should make
resolving conflicts much easier.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From peter at thecodergeek.com  Sun Nov 11 20:15:00 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Sun, 11 Nov 2007 12:15:00 -0800
Subject: colordiff & "cvs diff -u" [Was: Re: When will be CVS replaced
	by modern version control system?]
In-Reply-To: <200711111349.49427.ville.skytta@iki.fi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711111306.06913.ville.skytta@iki.fi>
	<1194781050.7485.6.camel@tuxhugs>
	<200711111349.49427.ville.skytta@iki.fi>
Message-ID: <1194812100.11618.2.camel@tuxhugs>

On Sun, 2007-11-11 at 13:49 +0200, Ville Skytt? wrote:
> I'm not aware of anything else besides "less /usr/bin/cdiff".

Completely overlooked that. T_T
Thanks very much!
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/6a59f5fc/attachment.sig>

From green at redhat.com  Sun Nov 11 20:18:18 2007
From: green at redhat.com (Anthony Green)
Date: Sun, 11 Nov 2007 12:18:18 -0800
Subject: common-lisp-controller for Fedora
In-Reply-To: <47325E81.4010706@redhat.com>
References: <47325E81.4010706@redhat.com>
Message-ID: <4737638A.2050805@redhat.com>

Anthony Green wrote:
> I've created a draft Feature page on the wiki to copy Debian's 
> common-lisp-controller package and methodology for installing Common 
> Lisp implementations and libraries.
> 
> http://fedoraproject.org/wiki/Features/CommonLispController

Here are some sample packages for comment:

* http://spindazzle.org/Fedora/cl-asdf-20071110-2.fc8.src.rpm

Many lisp implementations come with asdf already, but 
common-lisp-controller needs access to some code that doesn't appear to 
ship in some (sbcl for instance).  We will need to install an 
independently packaged one.

* http://spindazzle.org/Fedora/common-lisp-controller-6.12-2.fc8.src.rpm

This package provides the core scripts and lisp code.

* http://spindazzle.org/Fedora/sbcl-1.0.10-2.fc8.src.rpm

Here's a version of sbcl that has been modified to work with 
common-lisp-controller.

* http://spindazzle.org/Fedora/cl-s-xml-20051120-1.fc8.src.rpm

This is a sample lisp library (Fedora currently packages none due to 
lack of standards).  Install this, fire up sbcl, and enter "(require 
's-xml)".  common-lisp-controller fires off the compiler and fasl files 
are produced under /var/cache/common-lisp-controller.  Note that I'm 
prefixing the package name with "cl-".  I was against this for java 
libraries, but I'm for it in the lisp world.  Many libraries already use 
that prefix upstream.

I'd love to get some feedback from maintainers of the lisp implementations.

Thanks,

AG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: green.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/f2a2650e/attachment.vcf>

From lesmikesell at gmail.com  Sun Nov 11 20:18:55 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Sun, 11 Nov 2007 14:18:55 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194806040.3575.209.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>	<20071108094720.1a18ded1@redhat.com>	<1194700048.4580.39.camel@gibraltar.str.redhat.com>	<1194700238.4580.41.camel@gibraltar.str.redhat.com>	<20071110104245.6b783490@j2solutions.net>
	<4735EEFA.2040601@gmail.com>	<1194790032.3575.15.camel@gibraltar.str.redhat.com>	<47371EE6.8090901@gmail.com>	<1194797307.3575.126.camel@gibraltar.str.redhat.com>	<47374484.7060502@gmail.com>
	<1194806040.3575.209.camel@gibraltar.str.redhat.com>
Message-ID: <473763AF.3080405@gmail.com>

Nils Philippsen wrote:

>>>> This is a different operation than having every developer have his own 
>>>> copy - or at least one in every location where development happens. The 
>>>> ability to work disconnected was being touted as a feature,  But what 
>>>> happens if a release needed to be done at the central build system and 
>>>> the work some remote developer thinks is committed has not actually made 
>>>> it there because it is still disconnected?
>>> If you're disconnected, "make build" or a not yet existent "make commit"
>>> fails. Of course you need a connection to get the build system to build
>>> a package. But you can develop things locally (make srpm, make
>>> i386, ..., test things) and e.g. easily revert changes that didn't work
>>> out because you have a VCS available, even in a plane. The hurdle to
>>> experiment with new things is much lower if you can easily get back to a
>>> working state.
>>>
>>> Being able to work disconnected (to a feasible extent) is just one
>>> feature of a distributed VCS:
>> Which still doesn't address what happens in practice when the remote 
>> repository containing changes that the central repo doing the official 
>> build needs is still disconnected - or how anyone knows about it.
> 
> That's the same if you don't commit your changes to the CVS repo before
> building.

Except that it is obvious to all concerned and you don't proceed to do 
more work on the premise that everything is OK.

> For all practical purposes regarding this discussion, you can
> equate a CVS commit with a Hg push. Without committing to the build
> repository, there is nothing from which to build. Nothing new here.

Yes, but what is the procedure to know whether it was done?

>>  Or how 
>> the much larger conflicts that would be likely with the ability to do 
>> more work off line would be handled when they do reach the repo where 
>> the build is done.
> 
> You would be notified when pushing that the push would create new
> branches in the upstream repository. Unless you were forcing the push
> (not a good idea obviously), you would merge locally, whereby you would
> be the one to resolve the conflicts. The automatic invocation of meld
> (or another 3way diff tool) helps tremendously.
> 
> If anything it would be worse with CVS: when working disconnectedly, you
> would have to resolve the conflicts, only that you would have to do so
> without the help of the VCS -- only you and your vim (or emacs, or ...)
> -- and in one go. With a DVCS, you could merge your individual changes
> step by step instead of the whole work at once which should make
> resolving conflicts much easier.

Isn't it a rare case where you'd want to try to resolve conflicts 
offline - given that you might not be working against actual current 
revisions anyway?   And online, doesn't meld work with CVS?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From paul at all-the-johnsons.co.uk  Sun Nov 11 23:38:00 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 11 Nov 2007 23:38:00 +0000
Subject: Problem building from a zip file
Message-ID: <1194824280.5153.6.camel@T7.Linux>

Hi,

The latest version of boo comes in a zip file. How do I get it to
dearchive to a directory called "boo" (or something like that)?

I'm doing a rebuild of all the mono packages I currently maintain.

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/f9861be8/attachment.sig>

From wtogami at redhat.com  Sun Nov 11 23:39:34 2007
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 11 Nov 2007 18:39:34 -0500
Subject: selinux-policy semodule install problem
Message-ID: <473792B6.5020308@redhat.com>

http://koji.fedoraproject.org/packages/selinux-policy/3.0.8/
I upgraded my F8 system from -44 (F8 GA) to -48.
Then to -51.
Then I noticed tomboy stopped working with:
type=AVC msg=audit(1194819849.390:39): avc:  denied  { execheap } for 
pid=4191 comm="tomboy" scontext=unconfined_u:system_r:unconfined_t:s0 
tcontext=unconfined_u:system_r:unconfined_t:s0 tclass=process

nirik said tomboy was working for him with -47, so I tried to downgrade 
to -47.  I see this during the RPM transaction.

Preparing...                ########################################### 
[100%]
    1:selinux-policy         ########################################### 
[ 50%]
    2:selinux-policy-targeted########################################### 
[100%]
libsepol.scope_copy_callback: xguest: Duplicate declaration in module: 
type/attribute xguest_mozilla_home_t Cannot allocate memory.
libsemanage.semanage_link_sandbox: Link packages failed Cannot allocate 
memory.
semodule:  Failed!

Now whenever I try to upgrade or downgrade to any version of 
selinux-policy I see this error.

Any idea what is going on?

Warren Togami
wtogami at redhat.com



From tmz at pobox.com  Sun Nov 11 23:57:03 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 11 Nov 2007 18:57:03 -0500
Subject: Problem building from a zip file
In-Reply-To: <1194824280.5153.6.camel@T7.Linux>
References: <1194824280.5153.6.camel@T7.Linux>
Message-ID: <20071111235703.GA21164@psilocybe.teonanacatl.org>

Paul wrote:
> The latest version of boo comes in a zip file. How do I get it to
> dearchive to a directory called "boo" (or something like that)?

The %setup macro will handle zip files fine.  If the zip archive
doesn't contain a directory, you can use the -c option to create it
before unzipping.  The options for %setup are documented at:

http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s04.html#id2971580

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All of us could take a lesson from the weather.  It pays no attention
to criticism.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/80768ec1/attachment.sig>

From bnocera at redhat.com  Mon Nov 12 02:37:23 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 12 Nov 2007 02:37:23 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
Message-ID: <1194835043.2306.26.camel@cookie.hadess.net>


On Sat, 2007-11-10 at 00:56 +0100, Mark wrote:
> That map is interesting :) central europe seems to be committing heavy as well.
> 
> Anyway.. i just found something interesting.
> Sourceforge is hosted in the US right?
> 
> the gstreamer plugins (bad, ugly and ffmpeg and some others) are hosted on SF..

They're hosted on freedesktop.org.

> Now why is that not a problem? and putting a rpm on the fedora mirrors
> with the codecs is..?? sounds kinda strange but it does seem to be the
> case.. (same case for freedesktop.org)
> 
> so hows that working?
> 



From mharris at mharris.ca  Sun Nov 11 11:26:02 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Sun, 11 Nov 2007 06:26:02 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <200711111306.06913.ville.skytta@iki.fi>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
	<1194755679.27165.3.camel@localhost6.localdomain6>
	<200711111306.06913.ville.skytta@iki.fi>
Message-ID: <4736E6CA.3040108@mharris.ca>

Ville Skytt? wrote:
> On Sunday 11 November 2007, Peter Gordon wrote:
>> $ cvs diff -u branch-dir/ | colordiff | less -R
>>
>> Of course, this is very tedious to type
> 
> /usr/bin/cdiff (in the colordiff package) would simplify that a bit :)

Dude!  Rock on!

After just showing a newbie in IRC colour ls, colour grep, and a few 
others yesterday, I said something along the lines "time to google for a 
colour diff anytime about now".  I was sure I'd heard of one in the 
past, but couldn't remember for sure. ;o)

Incidentally, there is a plugin for thunderbird called "Colored Diffs" 
that does colour highlighting on diffs pretty nicely as well.




(P.S. Yes, I'm aware I spelled colour both ways.  The Canadian way for 
proper Canadian usage of the word, and the American way to match literal 
usage in commands.  ;o)   People point that out to me all the time, so I 
thought I'd jump the gun this time.  ;o)


-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From jonathan.underwood at gmail.com  Sun Nov 11 23:17:12 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 11 Nov 2007 23:17:12 +0000
Subject: License review for new itext version
In-Reply-To: <471DFA82.4050708@fedoraproject.org>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse> <471C4CF3.7030200@hhs.nl>
	<200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
	<471DFA82.4050708@fedoraproject.org>
Message-ID: <645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>

On 23/10/2007, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> vonbrand at inf.utfsm.cl wrote:
>
> >
> > Is this an OSI-approved license? Does it make sense to grind it through
> > that process?
>
> The recommended OSI process is for those who wrote the license to send
> it for approval. We could ask FSF for a review however if that is not
> already done by Spot.

It seems that pdftk has been dropped. dead.package reads:

"The package pdftk was going to EOL, becouse it contains a modified
copy of iText. IText contains several licensing issue which caused,
that this package was going into EOL:"

This seems like an over-reaction. The contentious clause in the license reads:

"You acknowledge that Software is not designed,licensed or intended for use in
the design, construction, operation or maintenance of any nuclear facility."

This clause in no way restricts your freedom to use the software. You
can still use it in your home-built nuclear reactor if you wish. By
doing so, you're acknowldeging that the software wasn't designed to be
used in this way, and all liability is with you.

What are the other of the "several" issues with the license? Could the
ex-package maintainer offer a bit more explanation?

Cheers,
Jonathan.



From t.matsuu at gmail.com  Sat Nov 10 15:28:41 2007
From: t.matsuu at gmail.com (MATSUURA Takanori)
Date: Sun, 11 Nov 2007 00:28:41 +0900
Subject: Firefox 3
In-Reply-To: <47357423.9030004@redhat.com>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net> <47357423.9030004@redhat.com>
Message-ID: <6f27515e0711100728ia6fd899hf32ae5be017cfc22@mail.gmail.com>

Hi all,

Now I put my firefox-trunk (3.0b2pre now) package at
http://t-matsuu.sakura.ne.jp/install-memo/fc/
The package is based on firefox-2.0.0.8-2.
It includes some adhoc artifice to success to build.

libgtkembedmoz.so and libxpcom.so is not built by default. now.
This change may affects yelp and devhelp (and AdobeReader-8.*) packages.

Feel free to incorporate to firefox package in Fedora.

regards,

Takanori



From jonathan.underwood at gmail.com  Sun Nov 11 23:38:32 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 11 Nov 2007 23:38:32 +0000
Subject: License review for new itext version
In-Reply-To: <645d17210711111523q32e2505fp9dbb5021ac44f599@mail.gmail.com>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse> <471C4CF3.7030200@hhs.nl>
	<200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
	<471DFA82.4050708@fedoraproject.org>
	<645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>
	<645d17210711111523q32e2505fp9dbb5021ac44f599@mail.gmail.com>
Message-ID: <645d17210711111538u4b896ec8qc9ca63b466e8976d@mail.gmail.com>

On 11/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> On 11/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> > What are the other of the "several" issues with the license? Could the
> > ex-package maintainer offer a bit more explanation?
> >
>
> Aha, a bit of digging leads to:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=236309
>
> which details the problems with itext licensing (on which pdftk
> depends). I guess the nuclear use is a small issue compared to the
> others :(.
>

To continue the monologue, it seems itext upstream is now entirely
licensed as either LGPL 2 or MPL. As such, I can't see a reason it
can't be reinstated in Fedora.



From mharris at mharris.ca  Sun Nov 11 11:42:42 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Sun, 11 Nov 2007 06:42:42 -0500
Subject: colordiff & "cvs diff -u" [Was: Re: When will be CVS replaced by
	modern version control system?]
In-Reply-To: <1194781050.7485.6.camel@tuxhugs>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
	<1194755679.27165.3.camel@localhost6.localdomain6>
	<200711111306.06913.ville.skytta@iki.fi>
	<1194781050.7485.6.camel@tuxhugs>
Message-ID: <4736EAB2.9050201@mharris.ca>

Peter Gordon wrote:
> On Sun, 2007-11-11 at 13:06 +0200, Ville Skytt? wrote:
>> On Sunday 11 November 2007, Peter Gordon wrote:
>>> $ cvs diff -u branch-dir/ | colordiff | less -R
>>>
>>> Of course, this is very tedious to type
>> /usr/bin/cdiff (in the colordiff package) would simplify that a bit :)
> 
> Er, thanks for the suggestion; but..
> 
> Unfortunately, it comes with no man/info page. If I try its --help
> option, it shows me the help output for gzip (eh? O_o). 

Interestingly enough, I did "yum install colordiff", and rpm was my 
friend at finding the documentation.  ;o)

rpm -ql <package>	- list all files in package
rpm -qd <package>	- list documentation for package
rpm -qc <package>	- list config files for package


> In amusing twist of irony, Google is not helpful either. (It gives me
> results for the C. difficile toxin which is apparently a sign of very
> bad gastrointestinal happenings...)
> 
> Where would I find appropriate documentation for this tool? I know I'm
> missing something somewhere but it's 3:36 AM right now and my brain's
> not entirely efficient. T_T

rpm can be your friend too!  ;oP

-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From dr.diesel at gmail.com  Sun Nov 11 18:05:40 2007
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Sun, 11 Nov 2007 13:05:40 -0500
Subject: Yumex broken?
Message-ID: <2a28d2ab0711111005t36579435i990ff6c866f19cf9@mail.gmail.com>

No matter how many times I "yum clean all" Yumex always crashes on
comps-f8.  Standard yum in console works great!

13:03:29 : Yum Config Setup
13:03:29 : Loading "priorities" plugin
13:03:29 : Yum Version : 3.2.7
13:03:29 : GUI Setup Completed
13:03:29 : Setup Yum : Transaction Set
13:03:31 : 347 packages excluded due to repository priority protections
13:03:32 : Setup Yum : RPM Db.
13:03:32 : Setup Yum : Repositories.
13:03:32 : Setup Yum : Package Sacks
13:03:32 : Setup Yum : Updates
13:03:34 : Loaded update Metadata from updates
13:03:34 : Setup Yum : Groups
13:03:51 : Failure getting
http://fedora.mirrors.tds.net/pub/fedora/updates/8/x86_64/repodata/comps-f8.xml:
13:03:51 :   --> [Errno -1] Metadata file does not match checksum
13:03:51 : Trying other mirror.
13:03:59 : Failure getting
ftp://ftp.uci.edu/mirrors/fedora/linux/updates/8/x86_64/repodata/comps-f8.xml:
13:03:59 :   --> [Errno -1] Metadata file does not match checksum
13:03:59 : Trying other mirror.
13:04:14 : Failure getting
http://fedora.mirror.facebook.com/linux/updates/8/x86_64/repodata/comps-f8.xml:
13:04:14 :   --> [Errno -1] Metadata file does not match checksum
13:04:14 : Trying other mirror.

--



From skvidal at fedoraproject.org  Mon Nov 12 04:49:50 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Sun, 11 Nov 2007 23:49:50 -0500
Subject: Yumex broken?
In-Reply-To: <2a28d2ab0711111005t36579435i990ff6c866f19cf9@mail.gmail.com>
References: <2a28d2ab0711111005t36579435i990ff6c866f19cf9@mail.gmail.com>
Message-ID: <1194842990.2025.0.camel@cutter>


On Sun, 2007-11-11 at 13:05 -0500, Dr. Diesel wrote:
> No matter how many times I "yum clean all" Yumex always crashes on
> comps-f8.  Standard yum in console works great!
> 
> 13:03:29 : Yum Config Setup
> 13:03:29 : Loading "priorities" plugin
> 13:03:29 : Yum Version : 3.2.7
> 13:03:29 : GUI Setup Completed
> 13:03:29 : Setup Yum : Transaction Set
> 13:03:31 : 347 packages excluded due to repository priority protections
> 13:03:32 : Setup Yum : RPM Db.
> 13:03:32 : Setup Yum : Repositories.
> 13:03:32 : Setup Yum : Package Sacks
> 13:03:32 : Setup Yum : Updates
> 13:03:34 : Loaded update Metadata from updates
> 13:03:34 : Setup Yum : Groups
> 13:03:51 : Failure getting
> http://fedora.mirrors.tds.net/pub/fedora/updates/8/x86_64/repodata/comps-f8.xml:
> 13:03:51 :   --> [Errno -1] Metadata file does not match checksum
> 13:03:51 : Trying other mirror.
> 13:03:59 : Failure getting
> ftp://ftp.uci.edu/mirrors/fedora/linux/updates/8/x86_64/repodata/comps-f8.xml:
> 13:03:59 :   --> [Errno -1] Metadata file does not match checksum
> 13:03:59 : Trying other mirror.
> 13:04:14 : Failure getting
> http://fedora.mirror.facebook.com/linux/updates/8/x86_64/repodata/comps-f8.xml:
> 13:04:14 :   --> [Errno -1] Metadata file does not match checksum
> 13:04:14 : Trying other mirror.
> 

There was a corruption in the last update of the comps-f8.xml file.
We're trying to figure out why this is happening but for the short run
just yum clean all and/or wait for the mirrors to get the update.

-sv




From jonathan.underwood at gmail.com  Sun Nov 11 23:23:56 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 11 Nov 2007 23:23:56 +0000
Subject: License review for new itext version
In-Reply-To: <645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse> <471C4CF3.7030200@hhs.nl>
	<200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
	<471DFA82.4050708@fedoraproject.org>
	<645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>
Message-ID: <645d17210711111523q32e2505fp9dbb5021ac44f599@mail.gmail.com>

On 11/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> What are the other of the "several" issues with the license? Could the
> ex-package maintainer offer a bit more explanation?
>

Aha, a bit of digging leads to:

https://bugzilla.redhat.com/show_bug.cgi?id=236309

which details the problems with itext licensing (on which pdftk
depends). I guess the nuclear use is a small issue compared to the
others :(.



From loupgaroublond at gmail.com  Mon Nov 12 04:54:11 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Sun, 11 Nov 2007 23:54:11 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <1194835043.2306.26.camel@cookie.hadess.net>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>
	<4734E6E4.3020807@fedoraproject.org>
	<loom.20071109T231223-339@post.gmane.org>
	<4734ED76.3050307@fedoraproject.org>
	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>
	<1194835043.2306.26.camel@cookie.hadess.net>
Message-ID: <7f692fec0711112054g2b042057s993dd83e2c1513b@mail.gmail.com>

On Nov 11, 2007 9:37 PM, Bastien Nocera <bnocera at redhat.com> wrote:
>
> On Sat, 2007-11-10 at 00:56 +0100, Mark wrote:
> > That map is interesting :) central europe seems to be committing heavy as well.
> >
> > Anyway.. i just found something interesting.
> > Sourceforge is hosted in the US right?
> >
> > the gstreamer plugins (bad, ugly and ffmpeg and some others) are hosted on SF..
>
> They're hosted on freedesktop.org.

The first patent holder that sues freedesktop.org is just going to
look like a bad guy.

a) The press will look really bad

b) freedesktop.org does not make million dollar annual profits from
these codecs the way Red Hat, Novell, or Mandrivia would and they
could never hope to seek the same level of damages

c) lawyers might take this case on good will, because of the high
profile nature, and the understanding of how open source works and is
good for the legal industry, and one of these lawyers might bust these
patents.

I hope these arguments are enough for people to realize that just
because it's open source does not mean Red Hat can *afford* to use the
software.

Cheers,
Yaakov



From jonathan.underwood at gmail.com  Sun Nov 11 23:22:15 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 11 Nov 2007 23:22:15 +0000
Subject: License review for new itext version
In-Reply-To: <645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse> <471C4CF3.7030200@hhs.nl>
	<200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
	<471DFA82.4050708@fedoraproject.org>
	<645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>
Message-ID: <645d17210711111522v22e7d550n4f4b5ce845396fef@mail.gmail.com>

On 11/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> What are the other of the "several" issues with the license? Could the
> ex-package maintainer offer a bit more explanation?
>

Aha, a bit of digging leads to:

https://bugzilla.redhat.com/show_bug.cgi?id=236309

which details the problems with itext licensing (on which pdftk
depends). I guess the nuclear use is a small issue compared to the
others :(.



From markg85 at gmail.com  Sun Nov 11 20:30:42 2007
From: markg85 at gmail.com (Mark)
Date: Sun, 11 Nov 2007 21:30:42 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <47373E51.8050604@gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<4734CB5B.1040605@gmail.com> <200711111722.52795.jamatos@fc.up.pt>
	<47373E51.8050604@gmail.com>
Message-ID: <6e24a8e80711111230q47f0b601wbec256ffa8aaa99f@mail.gmail.com>

2007/11/11, David Boles <dgboles at gmail.com>:
> Jos?(c) Matos wrote:
> > On Friday 09 November 2007 21:04:27 David Boles wrote:
> >> You want a KDE based RPM type Linux distro?
> >
> > This was useless and it only serves to add noise to the conversation, it is
> > difficult to parse as well. Which bit do you want to stress, kde, rpm, linux
> > or distribution?
>
>
> All of them of course. These are the most common complaints here with
> Fedora. KDE. Lack of non FOSS support. Etc. That disto, the one I
> mentioned, does/has all of these 'problems' solved.
>
> If *I* was as unhappy with Fedora as these users appear to be I would
> look elsewhere. And i would have do that a long time ago.
>
> What do you think Jose? Better to switch or is it just easier to complain?

Both are easy and you need to calm down.
posting suggestions here on how to improve fedora isn't wrong!
and in this case the suggestion came from a complaint.



From michel.sylvan at gmail.com  Sun Nov 11 17:24:22 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Sun, 11 Nov 2007 12:24:22 -0500
Subject: devhelp broken again?
In-Reply-To: <f224c6140711110910j5be83ba5p713cbc60e470bdff@mail.gmail.com>
References: <f224c6140711110910j5be83ba5p713cbc60e470bdff@mail.gmail.com>
Message-ID: <f224c6140711110924i6fcf50cbs97cb990161ecc264@mail.gmail.com>

On 11/11/2007, Michel Salim <michel.sylvan at gmail.com> wrote:
> When submitting a Koji build for F-8, I get the following error:
>
> Executing /usr/sbin/mock-helper yum --installroot
> /var/lib/mock/dist-f8-build-75037-9557/root install  'flex' 'devhelp'
> 'glib2-devel' 'bison'
> Error: Missing Dependency: gecko-libs = 1.8.1.8 is needed by package devhelp
>

Looks like the devhelp rebuild was pushed, and then unpushed by Jesse:

keating - 2007-11-08 12:43:36
Unpushing this (and all firefox related updates) until all deps are met.

There is a composite entry in the update system for F-7:

https://admin.fedoraproject.org/updates/F7/FEDORA-2007-3140

that pushes yelp, devhelp, epiphany and firefox, but no corresponding
entry for F-8. What seems to have happened is that Koji is for some
reason already using Firefox 2.0.0.9, but does not have access to the
matching devhelp.

Could someone push the needed packages?

Thanks,

-- 
Michel



From j.w.r.degoede at hhs.nl  Sun Nov 11 10:44:02 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 11 Nov 2007 11:44:02 +0100
Subject: lm_sensors (libsensors) soname breaking update will hit rawhide soon
Message-ID: <4736DCF2.8080607@hhs.nl>

Hi all,

As already announced some time ago, F-9 / rawhide will move to 
lm_sensors-3.0.0
as that brings several big advantages.

However this new version also comes with a new API and thus a new 
soname. This
new API is not 100% compatible to the old API, so packages which use 
libsensors
will need to have patches written.

This will affect the following packages:
gkrellm *
ksensors **
gnome-sensors-applet **
kdebase
net-snmp
net-snmp-libs
nagios-plugins
xfce4-sensors-plugin

*) A patch fixing gkrellm is already in Fedora devel CVS and has been 
send and
    accepted upstream
**) The 2 are mine and I will be taking care of them

See the gkrellm patch for some ideas of the needed changes, and howto 
write a
patch so that the resulting code will work with both the old and the new
lm_sensors. Once a patch has been written, please send it upstream and 
send it
to me, I will then put it on the lm_sensors upstream wiki, so that early 
3.0.0
testers will have access to all available patches, and also to avoid
duplication of effort between us and Suse, who will be moving to 3.0.0 too.

Talking about this, before writing a patch, please check:
http://www.lm-sensors.org/wiki/Download

As any known patches to adapt software to the new API are published there.

---

Since rawhide will be raw enough as is the coming days, I will not be 
building
lm_sensors-3.0.0 immediately. However I have an lm_sensors-3.0.0 package 
ready
in the CVS devel branch, so to get 3.0.0 to adapt your packages, check out
lm_sensors from CVS and do a local build in the devel branch.

Please prepare your packages for the new lm_sensors, I will be building 
it in
rawhide one week from now, so on Saturday 17 November.

If you have trouble adapting your package please let me know and I'll 
try to help.

Thanks & Regards,

Hans




From paul at xelerance.com  Mon Nov 12 05:35:32 2007
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 12 Nov 2007 00:35:32 -0500 (EST)
Subject: Codec Buddy misleading.
In-Reply-To: <20071110132139.GC6788@devserv.devel.redhat.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
Message-ID: <Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>

On Sat, 10 Nov 2007, Alan Cox wrote:

> For europe I think it is. It doesn't help for the Red Hat case because
> as a US company Red Hat is obliged to obey US law.

Red Hat is also a German company. Those people could release a German
version that includes it. Say in a German-only repository on german
servers (and mirrors outside of red hat's control).

It wouldn't be much different from Livna now. Which is an argument in
favor of keeping the codecs in such an outside repository as-is.

However, I am still of the opinion that non-us people shouldn't be misled
to buy things that they're fully entitled to from free and available
software, just because of the main location of Fedora's main contributor
(Red Hat). Which is why I think the Codec Buddy feature suggesting
non-free software should be removed. Americans illegally installing
livna rpms is not Red Hat's problem. Europeans mistakingly paying for
non-free software is an issue for the Fedora Community.

Paul



From paul at xelerance.com  Mon Nov 12 05:37:46 2007
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 12 Nov 2007 00:37:46 -0500 (EST)
Subject: Codec Buddy misleading.
In-Reply-To: <loom.20071110T010110-452@post.gmane.org>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<loom.20071110T010110-452@post.gmane.org>
Message-ID: <Pine.LNX.4.64.0711120036540.21249@newtla.xelerance.com>

On Sat, 10 Nov 2007, Kevin Kofler wrote:

> In most European courts, the loser pays all legal fees. (Now don't ask me for a
> list of exceptions, but this is the usual way things are handled in most of
> Europe.)

Yes, but legal fees are usually set by the court, and are not based on hiring
the most expensive lawyer in a DOS attack fashion. They are very reasonable.

Paul



From adrian at lisas.de  Mon Nov 12 06:04:15 2007
From: adrian at lisas.de (Adrian Reber)
Date: Mon, 12 Nov 2007 07:04:15 +0100
Subject: chain build in F-8
Message-ID: <20071112060414.GA4257@lisas.de>


I updated libmpd in F-8 and F-7 and I would now like to build gmpc which
depends on the new version of libmpd. chain-build failed for me with
F-8. What is the correct way to get libmpd in my buildroot? Do I have to
push it to testing? Just wait a bit longer? Thanks.

		Adrian



From dgboles at gmail.com  Mon Nov 12 06:05:45 2007
From: dgboles at gmail.com (David Boles)
Date: Mon, 12 Nov 2007 01:05:45 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711111230q47f0b601wbec256ffa8aaa99f@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<4734CB5B.1040605@gmail.com>
	<200711111722.52795.jamatos@fc.up.pt>	<47373E51.8050604@gmail.com>
	<6e24a8e80711111230q47f0b601wbec256ffa8aaa99f@mail.gmail.com>
Message-ID: <4737ED39.8030308@gmail.com>

Mark wrote:
> 2007/11/11, David Boles <dgboles at gmail.com>:
> 
> Both are easy and you need to calm down.
> posting suggestions here on how to improve fedora isn't wrong!
> and in this case the suggestion came from a complaint.

Calm down? Me?

Everything that my 'suggestion' recommended has been discussed almost to
the point of nausea here and on most of the other Fedora lists. And this
repeats on about a four month cycle. As have the explanations from the
'Fedora people' and the answers of why things are as they are and why
they are *not* going to change. Ever. Never. At no time. Sounds
permanent does it not? No matter how much whining is posted. Period.
Money talks and bull$hit walks. So to speak.

So my 'suggestion', Mandriva's distribution, was a general solution to
the complaints. An attempt to stop the endless cycle of 'I wants' and 'I
am being slighted'. Because it, Mandriva, actually 'fits' most, if not
all, of these common complaints. There are four distributions, that I
can think of here, different distributions, that fit this mold. Simple
enough?

Shoes too tight? Get new shoes. Car won't start? Get it fixed. Or
replace it with another. Not happy with where you live? Move.

Still not happy with Fedora after *all* the explanations of why it is
like it is and might just not match what *you* think it should be in the
end? Then, please, try something else. And then complain to them because
their distribution is not 'just like I want it to be' for me.

Think about it. Does it make sense to you?

BTW Calm? - Call me Mellow Yellow.  ;-)
-- 


  David



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/f549becc/attachment.sig>

From debarshi.ray at gmail.com  Mon Nov 12 06:13:57 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 12 Nov 2007 11:43:57 +0530
Subject: Packaging Starplot and related data files
Message-ID: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>

I am packaging Starplot (http://starplot.org/) for Fedora and would
like to discuss some license related issues.

The main Starplot program that gets built from
http://starplot.org/downloads/starplot-0.95.4.tar.gz is licensed under
GPLv2+. However, the Starplot data files distributed as
datahttp://starplot.org/data/gliese3-0.95.tar.gz and
http://starplot.org/data/yale5-0.95.tar.gz seem to be under a
"Redistributable, no modification permitted" license.

----

This is what the COPYING says:

                     NOTE ON STAR DATA FILES

 Everyone is permitted to copy and distribute verbatim copies
 of this copyright note, but changing it is not allowed.

The Makefile and .spec file of this data set are licensed under the GNU GPL,
of which you should have received a copy with the StarPlot documentation.
The GPL also applies to the text documentation (README, INSTALL) for this data
set, except where it would conflict with the licensing requirements described
below.  The GPL does ***NOT*** apply to the star data files enclosed or
generated.  The data files in the orig-data directory originate from the
Astronomical Data Center (http://adc.gsfc.nasa.gov) at NASA Goddard Space
Flight Center, and are copyrighted by their respective authors.  Upon asking
the ADC about the permissibility of their redistribution, I was told the
following:

        Yes, you are free to distribute the files with your program.
        Although, we do ask that you acknowledge, your source (the ADC)
        and the original authors.

        See: http://adc.gsfc.nasa.gov/adc/acknowledge_adc.html
        for more information.

My conclusions are that (1) you are free to redistribute the ADC data files.
However, (2) you must not delete any documentation giving credit for the data
files, for example in the README; and (3) the data files must NOT be altered in
any way (without permission of the original authors).  Therefore (4) it is NOT
permissible to redistribute the *.stars files which the StarPlot conversion
program creates from the ADC data files.  I have confirmed these conclusions
with the ADC.

The above text is Copyright (C) 2000  Kevin B. McCarty.

----

The following copyright notice is found in the README:

COPYRIGHT NOTE

It is safe to redistribute the files in the orig-data directory,
which, as noted above, are freely available on the Astronomical Data Center
web site.  However, since these are copyrighted data, you may NOT redistribute
modified versions of them.  This is why I have the StarPlot-format data files,
*.stars, generated at install time instead of being available for download.
I would advise that you NOT redistribute these *.stars data files.  See the
file COPYING for more information.

----

Can these data files be packaged as starplot-data for Fedora? Please advise.

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From bnocera at redhat.com  Mon Nov 12 06:16:52 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 12 Nov 2007 06:16:52 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
Message-ID: <1194848212.2306.55.camel@cookie.hadess.net>


On Mon, 2007-11-12 at 00:35 -0500, Paul Wouters wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
> 
> > For europe I think it is. It doesn't help for the Red Hat case because
> > as a US company Red Hat is obliged to obey US law.
> 
> Red Hat is also a German company. Those people could release a German
> version that includes it. Say in a German-only repository on german
> servers (and mirrors outside of red hat's control).
> 
> It wouldn't be much different from Livna now. Which is an argument in
> favor of keeping the codecs in such an outside repository as-is.
> 
> However, I am still of the opinion that non-us people shouldn't be misled
> to buy things that they're fully entitled to from free and available
> software, just because of the main location of Fedora's main contributor
> (Red Hat). Which is why I think the Codec Buddy feature suggesting
> non-free software should be removed. Americans illegally installing
> livna rpms is not Red Hat's problem. Europeans mistakingly paying for
> non-free software is an issue for the Fedora Community.

That is utter crock. If you know about the repositories, you probably
already have the packages installed already, or that window would remind
you to install them. If you don't know about them, we can't actually
point you at them.

The bottom line is that people who didn't know how to get playback
software for their videos and music will now know how to, or at least
have a way to.

In fact, most of this software and the way it made it in Fedora was done
in Britain and Spain. So I'm not buying the "martyr from Europe who
shelled out 30 euros" story.

Cheers



From gilboad at gmail.com  Sat Nov 10 08:26:39 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 10 Nov 2007 10:26:39 +0200
Subject: pptp-linux (pptp) on a Fedora DVD
In-Reply-To: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
References: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
Message-ID: <1194683199.18914.3.camel@gilboa-home-dev.localdomain>

On Fri, 2007-11-09 at 15:55 +0300, Kevac Marko wrote:
> Hello.
> 
> Here, in Russian Federation, 90% of home internet providers use PPTP
> for the internet access.
> So 80% of Fedora users from Russian Federation have same problem of
> installing and configuring pptp client. It includes very unpleasant
> "go to another box with internet connection, download rpm package, go
> back and install it".
> 
> I don't know what situation is in another countries with pptp, but i
> be very glad to see pptp client on a Fedora DVD.
> 
> So, questions are:
> 1. Why pptp package is still not there? Some license issues?
> 2. Will it be included in Fedora DVD?
> 3. How can i help?
> 
> -- 
> Sincerely yours, Kevac Marko
> 


/+1
In general I'd rather see l2tp and pptp supported out of the box.

Can you file a RFE in bugzilla and post the link?

- Gilboa



From dr.diesel at gmail.com  Sun Nov 11 17:26:30 2007
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Sun, 11 Nov 2007 12:26:30 -0500
Subject: Core 2 Duo not fast enough for Mplayer?
Message-ID: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>

This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
relevent.  About 1/2 way down Mplayer tells me my Core 2 Duo is not
fast enough to play a small video!  This is a 100% fresh install of F8
yesterday (+ all updates to date).  No problems with F7.  I also tried
switching to ALSA as suggested by mplayer, but then I'm getting
"Unable to find control PCM 0"

The video is very slow and choppy.  Totem movie player has no problem
with it.  Xine plays about 5 seconds, pauses for a second then
continues.

Any thoughts?

[root at localhost ~]# mplayer /home/garage/Desktop/p1010008.mov
MPlayer 1.0rc2-4.1.2 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU          4300  @ 1.80GHz (Family: 6,
Model: 15, Stepping: 2)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
Creating config file: /root/.mplayer/config
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /home/garage/Desktop/p1010008.mov.
Quicktime/MOV file format detected.
[mov] Video stream found, -vid 0
[mov] Audio stream found, -aid 1
VIDEO:  [jpeg]  320x240  24bpp  15.000 fps    0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG decoder)
==========================================================================
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 8000 Hz, 1 ch, u8, 64.0 kbit/100.00% (ratio: 8000->8000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 8000Hz 1ch u8 (1 bytes per sample)
Starting playback...
VDec: vo config request - 320 x 240 (preferred colorspace: Planar 422P)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar 422P as output csp (no 1)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: reducing / aligning filtersize 1 -> 4
SwScaler: reducing / aligning filtersize 1 -> 4
SwScaler: reducing / aligning filtersize 1 -> 1
SwScaler: reducing / aligning filtersize 9 -> 8
[swscaler @ 0xd36070]SwScaler: BICUBIC scaler, from yuv422p to yuv420p
using MMX2
[swscaler @ 0xd36070]SwScaler: using 4-tap MMX scaler for horizontal
luminance scaling
[swscaler @ 0xd36070]SwScaler: using 4-tap MMX scaler for horizontal
chrominance scaling
[swscaler @ 0xd36070]SwScaler: using 1-tap MMX "scaler" for vertical
scaling (YV12 like)
[swscaler @ 0xd36070]SwScaler: 320x240 -> 320x240
VO: [xv] 320x240 => 320x240 Planar YV12
A:  14.2 V:  13.6 A-V:  0.640 ct: -0.018 205/205  2%  1%  0.1% 50 0

           ************************************************
           **** Your system is too SLOW to play this!  ****
           ************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
    e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

A:  25.0 V:  25.1 A-V: -0.028 ct: -0.087 377/377  2%  1%  0.1% 81 0

Exiting... (End of file)
[root at localhost ~]#



From michel.sylvan at gmail.com  Sun Nov 11 17:10:56 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Sun, 11 Nov 2007 12:10:56 -0500
Subject: devhelp broken again?
Message-ID: <f224c6140711110910j5be83ba5p713cbc60e470bdff@mail.gmail.com>

When submitting a Koji build for F-8, I get the following error:

Executing /usr/sbin/mock-helper yum --installroot
/var/lib/mock/dist-f8-build-75037-9557/root install  'flex' 'devhelp'
'glib2-devel' 'bison'
Error: Missing Dependency: gecko-libs = 1.8.1.8 is needed by package devhelp

The package builds fine in F-9 and on my local machine -- trying an
F-7 build as well.

-- 
Michel



From oisin.feeley at gmail.com  Sat Nov 10 20:40:45 2007
From: oisin.feeley at gmail.com (Oisin Feeley)
Date: Sat, 10 Nov 2007 15:40:45 -0500
Subject: Random question about Koji's reporting of completion date vs.
	finished date
Message-ID: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>

Why are the start/complete dates reported in the Koji interface
different to the finished dates?

For example, this nspluginwrapper build[1]
reports a start/complete date of 21 Sept. 2007, but the
buildinfo page for the package[2] displays a "finished"
date of 09 Nov 2007 (entry for nspluginwrapper-0.9.91.5-3.fc8
is approximately halfway down the page currently).

Thanks to anyone that can point me to a quick answer and
also a good place for further reading on this.

Oisin Feeley

1. http://koji.fedoraproject.org/koji/buildinfo?buildID=19193

2. http://koji.fedoraproject.org/koji/packageinfo?packageID=4831



From j.w.r.degoede at hhs.nl  Sat Nov 10 19:31:04 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 10 Nov 2007 20:31:04 +0100
Subject: lm_sensors (libsensors) soname breaking update will hit rawhide soon
Message-ID: <473606F8.5090902@hhs.nl>

Hi all,

As already announced some time ago, F-9 / rawhide will move to lm_sensors-3.0.0 
as that brings several big advantages.

However this new version also comes with a new API and thus a new soname. This 
new API is not 100% compatible to the old API, so packages which use libsensors 
will need to have patches written.

This will affect the following packages:
gkrellm *
ksensors **
gnome-sensors-applet **
kdebase
net-snmp
net-snmp-libs
nagios-plugins
xfce4-sensors-plugin

*) A patch fixing gkrellm is already in Fedora devel CVS and has been send and
    accepted upstream
**) The 2 are mine and I will be taking care of them

See the gkrellm patch for some ideas of the needed changes, and howto write a 
patch so that the resulting code will work with both the old and the new 
lm_sensors. Once a patch has been written, please send it upstream and send it 
to me, I will then put it on the lm_sensors upstream wiki, so that early 3.0.0 
testers will have access to all available patches, and also to avoid 
duplication of effort between us and Suse, who will be moving to 3.0.0 too.

Talking about this, before writing a patch, please check:
http://www.lm-sensors.org/wiki/Download

As any known patches to adapt software to the new API are published there.

---

Since rawhide will be raw enough as is the coming days, I will not be building 
lm_sensors-3.0.0 immediately. However I have an lm_sensors-3.0.0 package ready 
in the CVS devel branch, so to get 3.0.0 to adapt your packages, check out 
lm_sensors from CVS and do a local build in the devel branch.

Please prepare your packages for the new lm_sensors, I will be building it in 
rawhide one week from now, so on Saturday 17 November.

If you have trouble adapting your package please let me know and I'll try to help.

Thanks & Regards,

Hans



From peter at thecodergeek.com  Mon Nov 12 07:53:48 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Sun, 11 Nov 2007 23:53:48 -0800
Subject: chain build in F-8
In-Reply-To: <20071112060414.GA4257@lisas.de>
References: <20071112060414.GA4257@lisas.de>
Message-ID: <1194854028.19003.2.camel@tuxhugs>

On Mon, 2007-11-12 at 07:04 +0100, Adrian Reber wrote:
> I updated libmpd in F-8 and F-7 and I would now like to build gmpc
> which
> depends on the new version of libmpd. chain-build failed for me with
> F-8. What is the correct way to get libmpd in my buildroot? Do I have
> to
> push it to testing? Just wait a bit longer? Thanks.

Once it's pushed to stable, it's available for buildroots. Until then,
if you need it for another package please email
rel-eng at fedoraproject.org noting that you'd like that package (with full
NVR) added to the buildroot override, and reason for it.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/f03c9a2d/attachment.sig>

From peter at thecodergeek.com  Mon Nov 12 07:55:33 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Sun, 11 Nov 2007 23:55:33 -0800
Subject: colordiff & "cvs diff -u" [Was: Re: When will be CVS replaced
	by modern version control system?]
In-Reply-To: <4736EAB2.9050201@mharris.ca>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
	<1194755679.27165.3.camel@localhost6.localdomain6>
	<200711111306.06913.ville.skytta@iki.fi>
	<1194781050.7485.6.camel@tuxhugs> <4736EAB2.9050201@mharris.ca>
Message-ID: <1194854133.19003.5.camel@tuxhugs>

On Sun, 2007-11-11 at 06:42 -0500, Mike A. Harris wrote:
> Interestingly enough, I did "yum install colordiff", and rpm was my 
> friend at finding the documentation.  ;o)
> 

RPM...Friendly? Who are you, and what have you done with Mike Harris? :P

Jokes aside, thanks for the info. I didn't realize it had that
capability. :)
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/5e87231e/attachment.sig>

From valent.turkovic at gmail.com  Mon Nov 12 08:54:05 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 12 Nov 2007 09:54:05 +0100
Subject: sending multiple (different) smolt profiles
Message-ID: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>

Hi,

I have 2 laptops and I used the smoltSendProfile and I seem to get the
same url for both laptops, ie. the later sent profile overwrites the
previous one...

I'm sending both profiles from same adsl line and I'm behing a NAT
adsl router, so could this be an issue (same IP) ?

Is this a feature or a bug?

How can I send multiple laptop profiles and see them all online?

Thank you very much in advance,
Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Mon Nov 12 08:56:04 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 12 Nov 2007 09:56:04 +0100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
Message-ID: <64b14b300711120056q4daaab33pb53854ef9b976bdf@mail.gmail.com>

On 11/12/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> Hi,
>
> I have 2 laptops and I used the smoltSendProfile and I seem to get the
> same url for both laptops, ie. the later sent profile overwrites the
> previous one...
>
> I'm sending both profiles from same adsl line and I'm behing a NAT
> adsl router, so could this be an issue (same IP) ?
>
> Is this a feature or a bug?
>
> How can I send multiple laptop profiles and see them all online?
>
> Thank you very much in advance,
> Valent.
>

This is the profile:
http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From fedora at camperquake.de  Mon Nov 12 08:58:10 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 09:58:10 +0100
Subject: Automatic RPM provides for libraries
In-Reply-To: <20071111183408.12c20c73@lain.camperquake.de>
References: <20071110161308.2554226c@lain.camperquake.de>
	<20071110184050.GB2817@free.fr>
	<20071111183408.12c20c73@lain.camperquake.de>
Message-ID: <20071112095810.56d902de@dhcp03.addix.net>

Hi.

On Sun, 11 Nov 2007 18:34:08 +0100, Ralf Ertzinger wrote:

> Indeed, the library soname had changed between the two versions I
> was looking at.

Turns out this was an upstream mistake, newer releases will have the
old soname back.



From triad at df.lth.se  Mon Nov 12 09:16:51 2007
From: triad at df.lth.se (Linus Walleij)
Date: Mon, 12 Nov 2007 10:16:51 +0100 (CET)
Subject: Praise for F-8
Message-ID: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>

Too seldom I say what I really feel when it's positive:

F-8 totally kicks ass. It works like a charm on this brand new x86_64 
SMP thing, extremely interactive during high load (CFS scheduler I 
believe), the new IcedTea java is awesome for being done in such a 
hurry. The new theme engine is really good. The new bluetooth and phone 
stuff just works (that's more than you can say of ANY other OS/Distro).

Also, and didn't say in time for F-7: I love Bodhi. It's very convenient 
and makes you feel a lot better when pushing updates.

Linus



From valent.turkovic at gmail.com  Mon Nov 12 09:17:52 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 12 Nov 2007 10:17:52 +0100
Subject: java-plugin not working in F8
In-Reply-To: <47344B46.6070604@mharris.ca>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
Message-ID: <64b14b300711120117u31d8f149t32b70b7ec404b123@mail.gmail.com>

On Nov 9, 2007 12:57 PM, Mike A. Harris <mharris at mharris.ca> wrote:
> Mike Chambers wrote:
> > On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> >> Hi,
> >>
> >> I installed java plugin via 'yum install java-plugin' and firefox
> >> still complains that plugin is not installed...
> >> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
> >
> > Just install the java-icedtea-plugin (just look for icedtea) from Fedora
> > and it will work just fine.
> >
> > Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
> > as well?
>
> I'm running F8/x86_64 and haven't manually installed any Java stuff yet,
> just whatever might have been installed by anaconda by default.  Up
> until now I hadn't visited any web pages with Java on them.
>
> A lot of people have been having problems with Java it seems, and so I
> decided to try to get it to work myself.  I google searched for a "Java
> test", went to the Sun page, and it just worked automatically already,
> presumeably with iced-tea, which I assume was installed for me already
> by anaconda.  I went to a variety of other Java websites to test it out
> and have had no problems at all so far.  All Java sites work in firefox
> for me automatically.
>
> As mentioned above, I haven't had to install anything, configure
> anything, or do anything manual for this to work, it just works out of
> the box on x86_64, at least for me.
>
> I can only assume that the people having the problems either:
>
> 1) Are coming from an upgrade of a previous OS release
> or
> 2) Have Sun, IBM, or some other Java installed already, or are trying to
> install some other Java
> 3) Have upgraded and didn't get iced-tea by default perhaps.
>
> Anyhow, worst case scenario -> do a fresh OS install and Java seems to
> work in firefox right out of the box.  ;o)
>
>
>
> --
> Mike A. Harris
>
> Come and join us on the #fedora8 IRC help forum on irc.freenode.net
>
>

Just an update; I installed a fresh Fedora 8 from Gnome Live CD and by
default java doesn't work.

I have installed latest updates and I will now install java-plugin and
test it again and give you feedback.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Mon Nov 12 09:32:21 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 12 Nov 2007 10:32:21 +0100
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711120117u31d8f149t32b70b7ec404b123@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
	<64b14b300711120117u31d8f149t32b70b7ec404b123@mail.gmail.com>
Message-ID: <64b14b300711120132t6d159f7ftf5d610ac35accdfe@mail.gmail.com>

On Nov 12, 2007 10:17 AM, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> On Nov 9, 2007 12:57 PM, Mike A. Harris <mharris at mharris.ca> wrote:
>
> > Mike Chambers wrote:
> > > On Fri, 2007-11-09 at 11:44 +0100, Valent Turkovic wrote:
> > >> Hi,
> > >>
> > >> I installed java plugin via 'yum install java-plugin' and firefox
> > >> still complains that plugin is not installed...
> > >> I'm running 32bit fedora (I saw previous mails regarding F7 on 64bit).
> > >
> > > Just install the java-icedtea-plugin (just look for icedtea) from Fedora
> > > and it will work just fine.
> > >
> > > Otherwise, maybe you need to create a link to /usr/lib/mozilla/plugins
> > > as well?
> >
> > I'm running F8/x86_64 and haven't manually installed any Java stuff yet,
> > just whatever might have been installed by anaconda by default.  Up
> > until now I hadn't visited any web pages with Java on them.
> >
> > A lot of people have been having problems with Java it seems, and so I
> > decided to try to get it to work myself.  I google searched for a "Java
> > test", went to the Sun page, and it just worked automatically already,
> > presumeably with iced-tea, which I assume was installed for me already
> > by anaconda.  I went to a variety of other Java websites to test it out
> > and have had no problems at all so far.  All Java sites work in firefox
> > for me automatically.
> >
> > As mentioned above, I haven't had to install anything, configure
> > anything, or do anything manual for this to work, it just works out of
> > the box on x86_64, at least for me.
> >
> > I can only assume that the people having the problems either:
> >
> > 1) Are coming from an upgrade of a previous OS release
> > or
> > 2) Have Sun, IBM, or some other Java installed already, or are trying to
> > install some other Java
> > 3) Have upgraded and didn't get iced-tea by default perhaps.
> >
> > Anyhow, worst case scenario -> do a fresh OS install and Java seems to
> > work in firefox right out of the box.  ;o)
> >
> >
> >
> > --
> > Mike A. Harris
> >
> > Come and join us on the #fedora8 IRC help forum on irc.freenode.net
> >
> >
>
> Just an update; I installed a fresh Fedora 8 from Gnome Live CD and by
> default java doesn't work.
>
> I have installed latest updates and I will now install java-plugin and
> test it again and give you feedback.
>

The bug is still present ie. after installing java-plugin java still
doesn't work.

After running 'mozilla-plugin-config' java works in Firefox.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From kzak at redhat.com  Mon Nov 12 09:32:49 2007
From: kzak at redhat.com (Karel Zak)
Date: Mon, 12 Nov 2007 10:32:49 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194796262.3575.107.camel@gibraltar.str.redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
	<4735EEFA.2040601@gmail.com>
	<1194790032.3575.15.camel@gibraltar.str.redhat.com>
	<20071111091652.6ca7536b@redhat.com>
	<1194796262.3575.107.camel@gibraltar.str.redhat.com>
Message-ID: <20071112093249.GG2871@petra.dvoda.cz>

On Sun, Nov 11, 2007 at 04:51:02PM +0100, Nils Philippsen wrote:
> On Sun, 2007-11-11 at 09:16 -0500, Jesse Keating wrote:
> > On Sun, 11 Nov 2007 15:07:12 +0100
> > Nils Philippsen <nphilipp at redhat.com> wrote:
> > 
> > > "commit to local repository, tag,
> > > push local changes to build repository, build".
> > 
> > You can't just tag locally.  You need to ensure that the same tag
> > hasn't been applied to the central repo by somebody else while you were
> > "away".
> 
> And how's that different from CVS? Of course, "make tag" should take
> things "upstream" to the "central" repository and yell if the tag
> already exists. Been there, done that, you might want to take a look at
> the Makefiles of my system-config-* packages(*). If a tag existed
> already, either the tagging itself or the subsequent push fails.
> 
> (*): E.g. http://hg.fedoraproject.org/hg/hosted/system-config-users --
> note that these have been written for slightly older Mercurial versions
> where using the same tag was possible without --force'ing things. They
> could be a bit simpler with current versions.
> 
> We could also resort to letting "koji build" do the tagging to keep
> things more controlled -- i.e. "koji build <some changeset id>" would
> checkout the package, attempt to "reserve"(**) the tag, build and tag on
> success which would obviate the need for "make force-tag". Of course,
> people should be prohibited from pushing changes to e.g. .hgtags for
> such a scheme.

 Note, git supports GPG signed tags -- it would be nice to use

    koji build <tag> <gpgkeyid>

 as a way how build a trusted rpm package.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From denis at poolshark.org  Mon Nov 12 09:34:24 2007
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 12 Nov 2007 01:34:24 -0800
Subject: chain build in F-8
In-Reply-To: <1194854028.19003.2.camel@tuxhugs>
References: <20071112060414.GA4257@lisas.de> <1194854028.19003.2.camel@tuxhugs>
Message-ID: <47381E20.2010506@poolshark.org>

Peter Gordon wrote:
> On Mon, 2007-11-12 at 07:04 +0100, Adrian Reber wrote:
>> I updated libmpd in F-8 and F-7 and I would now like to build gmpc
>> which
>> depends on the new version of libmpd. chain-build failed for me with
>> F-8. What is the correct way to get libmpd in my buildroot? Do I have
>> to
>> push it to testing? Just wait a bit longer? Thanks.
> 
> Once it's pushed to stable, it's available for buildroots. Until then,
> if you need it for another package please email
> rel-eng at fedoraproject.org noting that you'd like that package (with full
> NVR) added to the buildroot override, and reason for it.

I hit the same problem all the time with the gtkmm updates, which are 3 
to 4-deep dependency chains. How could we automate this ? Having to mail 
rel-eng for this seems particularly inefficient, and it's also a 
regression from the plague/FC-6 days...

-denis



From guhvies at gmail.com  Mon Nov 12 09:41:33 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 09:41:33 +0000
Subject: Praise for F-8
In-Reply-To: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
Message-ID: <a227b70c0711120141p3d56c8al48189b0ac642597c@mail.gmail.com>

On 12/11/2007, Linus Walleij <triad at df.lth.se> wrote:
> Too seldom I say what I really feel when it's positive:
>
> F-8 totally kicks ass.
Lucky you. I can not get past selecting drivers to use on a fresh
install before it baffs with a double error or some such. I guess that
means I am on FC7 for now.

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From nphilipp at redhat.com  Mon Nov 12 09:47:35 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 12 Nov 2007 10:47:35 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
Message-ID: <1194860855.3575.224.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-12 at 00:35 -0500, Paul Wouters wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
> 
> > For europe I think it is. It doesn't help for the Red Hat case because
> > as a US company Red Hat is obliged to obey US law.
> 
> Red Hat is also a German company. Those people could release a German
> version that includes it. Say in a German-only repository on german
> servers (and mirrors outside of red hat's control).

Are you a lawyer? I don't think so. As I see it, if Red Hat Germany did
such a thing the U.S. based Red Hat Inc. would be equally liable before
U.S. courts as if it did it by itself.

Nils (not a lawyer as well)
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From mcepl at redhat.com  Mon Nov 12 09:56:32 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 12 Nov 2007 10:56:32 +0100
Subject: Codec Buddy misleading.
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
Message-ID: <gjkl05x62j.ln2@hubmaier.ceplovi.cz>

On Mon, 12 Nov 2007 00:35:32 -0500, Paul Wouters scripst:
>> For europe I think it is. It doesn't help for the Red Hat case because
>> as a US company Red Hat is obliged to obey US law.
> 
> Red Hat is also a German company. Those people could release a German
> version that includes it. Say in a German-only repository on german
> servers (and mirrors outside of red hat's control).

Don't go there -- you are trying to do an analysis of the venue for 
litigation in the international context. That's one of the most 
complicated things you can do in the international private law. I have 
two law degrees, one from U.S. university dealing explicitly with the 
international law, and still I wouldn't be very sure what the result of 
such analysis is. However, it is highly probable in my opinion (and I 
have been out of the legal practice for couple of years, so don't take 
this as a lawyer advice) that your suggested transaction structure would 
have no effect on the ability of American plaintiffs to sue Red Hat in 
USA.

Translated into plain English -- bad idea.

Best,

Mat?j



From johannbg at hi.is  Mon Nov 12 10:07:03 2007
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Mon, 12 Nov 2007 10:07:03 +0000
Subject: Praise for F-8
In-Reply-To: <a227b70c0711120141p3d56c8al48189b0ac642597c@mail.gmail.com>
References: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
	<a227b70c0711120141p3d56c8al48189b0ac642597c@mail.gmail.com>
Message-ID: <473825C7.9010805@hi.is>

ne... wrote:
> On 12/11/2007, Linus Walleij <triad at df.lth.se> wrote:
>   
>> Too seldom I say what I really feel when it's positive:
>>
>> F-8 totally kicks ass.
>>     
Totally does ;) ...
> Lucky you. I can not get past selecting drivers to use on a fresh
> install before it baffs with a double error or some such. I guess that
> means I am on FC7 for now.
>
> ne...
>   
Could you be more specific of what is preventing you to do
fresh install/upgrade to FC8? ( "fresh install before it baffs with a 
double error or some such ")
Provide us with double error or some such output...
And some HW info and take a look at 
https://fedoraproject.org/wiki/Bugs/F8Common
to see if any fits your scenario?

Best regards
                Johann B.



From panemade at gmail.com  Sun Nov 11 07:05:14 2007
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Sun, 11 Nov 2007 12:35:14 +0530
Subject: Firefox 3
In-Reply-To: <47357423.9030004@redhat.com>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net> <47357423.9030004@redhat.com>
Message-ID: <f4586a2e0711102305x6b0144cfu68f45aa139cbb3c1@mail.gmail.com>

Hi,
On Nov 10, 2007 2:34 PM, Christopher Aillon <caillon at redhat.com> wrote:
> Janina Sajka wrote:
> >> Janina Sajka <janina at rednote.net> wrote:
> >> >Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
> >> >near ready for prime time, but I have a compelling reason to start using
> >> >ff3 fairly soon and would rather install from rpm, of course.
>
> Stay tuned for an update in the next two weeks.  We got this working
> last week, but there's a few things we want to clean up before it's put
> into rawhide.  Putting it into rawhide will also mean breaking several
> things such as epiphany, yelp, devhelp, and every other application that
> uses gecko right now.  So there is a high cost that we want to be in a
> position to communicate well as to the proper way to solve rather than
> simply leave broken for people to figure it out.
     Good News that last week mozilla developers resolved all beta1
blocker bugs. According to their weekly meeting status, beta1 is code
complete now. So I am waiting for Firefox 3's Beta1(M9) release. once
its released we can think on its inclusion in rawhide.

Regards,
Parag.



From guhvies at gmail.com  Mon Nov 12 10:29:24 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 10:29:24 +0000
Subject: Praise for F-8
In-Reply-To: <473825C7.9010805@hi.is>
References: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
	<a227b70c0711120141p3d56c8al48189b0ac642597c@mail.gmail.com>
	<473825C7.9010805@hi.is>
Message-ID: <a227b70c0711120229t2e91b927w5f39db29953a2ad7@mail.gmail.com>

On 12/11/2007, "J?hann B. Gu?mundsson" <johannbg at hi.is> wrote:
> ne... wrote:
> > Lucky you. I can not get past selecting drivers to use on a fresh
> > install before it baffs with a double error or some such. I guess that
> > means I am on FC7 for now.
> Could you be more specific of what is preventing you to do
> fresh install/upgrade to FC8?
I am trying to do a fresh install. I do not do upgrades. I adjust my grub.conf
to boot the kernel I need so I can do a hard drive install. I get to
select language and keyboard. I then specify that I am doing a hard
drive install when I then get told I need to specify drivers. I then
need to select the sata_sil and sata_nv drivers. At this point I get a
double free error. I cannot proceed further from here.

> Provide us with double error or some such output...
> And some HW info and take a look at
AMD X2 4400+ Gigabyte GA-K8NS Ultra-939 mobo, 2x 80GB & 1x 200GB
Western Digital hard drives.

> https://fedoraproject.org/wiki/Bugs/F8Common
> to see if any fits your scenario?
Nope, none do.

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From debarshi.ray at gmail.com  Mon Nov 12 10:44:29 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 12 Nov 2007 16:14:29 +0530
Subject: openssl097a package retirement
In-Reply-To: <1187726092.3852.37.camel@vespa.kabelta.loc>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
Message-ID: <3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>

[Continuing from the fedora-maintainers list.]

On 22/08/2007, Tomas Mraz <tmraz at redhat.com> wrote:
> If there will not be any serious objections I'll retire openssl097a
> package in rawhide.
>
> It doesn't make much sense to maintain this old version of openssl in
> Fedora.

I am packaging httrack, which has the following snippet:

      /* We are compatible with 0.9.6/7/8 and potentially above */
      handle = dlopen("libssl.so.0.9.8", RTLD_LAZY);
      if (handle == NULL) {
        handle = dlopen("libssl.so.0.9.7", RTLD_LAZY);
      }
      if (handle == NULL) {
        handle = dlopen("libssl.so.0.9.6", RTLD_LAZY);
      }
      if (handle == NULL) {
        /* Try harder */
        handle = dlopen("libssl.so", RTLD_LAZY);
      }
      if (handle == NULL) {
        /* Try harder */
        handle = dlopen("libssl.so.0", RTLD_LAZY);

Are libssl.so.0.9.8 and libssl.so.9.8b compatible? Can I patch the
source to use libssl.so.9.8b?

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From gianluca.cecchi at gmail.com  Mon Nov 12 10:45:31 2007
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 12 Nov 2007 11:45:31 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
Message-ID: <561c252c0711120245t5f0345fcic6a67476c50c229e@mail.gmail.com>

Sort off-topic for this list, I presume, but could it be that on FC7 your
mplayer config was different?
You are using xv videoutput device (probably your or mplayer default if you
have not a config file).
may be a problem in using xvideo with your drivers?
Does it change anything if you use instead -vo x11 for playing it?
perhaps totem and xine use x11 as default?
On Sun, 11 Nov 2007 12:26:30 -0500 Dr. Diesel wrote:

VO: [xv] 320x240 => 320x240 Planar YV12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/de90c375/attachment.htm>

From nicolas.mailhot at laposte.net  Mon Nov 12 10:45:36 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 11:45:36 +0100 (CET)
Subject: Praise for F-8
Message-ID: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>


Le Lun 12 novembre 2007 11:29, ne... a ?crit :

>> Provide us with double error or some such output...
>> And some HW info and take a look at
> AMD X2 4400+ Gigabyte GA-K8NS Ultra-939 mobo, 2x 80GB & 1x 200GB
> Western Digital hard drives.

I can't speak for the install part since I use a rolling rawhide setup
but this hardware should work fine once installed (I have a AMD X2
4400+ + Gigabyte GA-K8N Ultra-9 mobo, maxtor drives)

-- 
Nicolas Mailhot



From guhvies at gmail.com  Mon Nov 12 10:56:34 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 10:56:34 +0000
Subject: Praise for F-8
In-Reply-To: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
Message-ID: <a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>

On 12/11/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le Lun 12 novembre 2007 11:29, ne... a ?crit :
>
> >> Provide us with double error or some such output...
> >> And some HW info and take a look at
> > AMD X2 4400+ Gigabyte GA-K8NS Ultra-939 mobo, 2x 80GB & 1x 200GB
> > Western Digital hard drives.
>
> I can't speak for the install part since I use a rolling rawhide setup
> but this hardware should work fine once installed (I have a AMD X2
> 4400+ + Gigabyte GA-K8N Ultra-9 mobo, maxtor drives)
My thoughts exactly till I got the double free error. This box also has
FC7, FC6, FC5, FC4 & FC3 installs on it. Plus openSUSE 10.1 & CentOS 5.
Never had any problems before yesterday. My hard drives are all SATA tho...

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From opensource at till.name  Sun Nov 11 09:33:39 2007
From: opensource at till.name (Till Maas)
Date: Sun, 11 Nov 2007 10:33:39 +0100
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <1194748592.2765.27.camel@mccallum.corsepiu.local>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>
	<200711082222.01473.opensource@till.name>
	<1194748592.2765.27.camel@mccallum.corsepiu.local>
Message-ID: <200711111033.43678.opensource@till.name>

On So November 11 2007, Ralf Corsepius wrote:
> On Thu, 2007-11-08 at 22:21 +0100, Till Maas wrote:

> > How can I now do a diff that shows the changes between my working copy
> > and the contents of the repository?
>
> cvs diff -u *.spec

And this will not create a network connection?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071111/e02f14fd/attachment.sig>

From martin at bugs.unl.edu.ar  Mon Nov 12 11:14:02 2007
From: martin at bugs.unl.edu.ar (Martin Marques)
Date: Mon, 12 Nov 2007 08:14:02 -0300
Subject: colordiff & "cvs diff -u" [Was: Re: When will be CVS replaced
 by	modern version control system?]
In-Reply-To: <4736EAB2.9050201@mharris.ca>
References: <20071107141245.GA4888@evileye.englab.brq.redhat.com>	<1194748592.2765.27.camel@mccallum.corsepiu.local>	<1194755679.27165.3.camel@localhost6.localdomain6>	<200711111306.06913.ville.skytta@iki.fi>	<1194781050.7485.6.camel@tuxhugs>
	<4736EAB2.9050201@mharris.ca>
Message-ID: <4738357A.5020102@bugs.unl.edu.ar>

Mike A. Harris escribi?:
> 
> Interestingly enough, I did "yum install colordiff", and rpm was my
> friend at finding the documentation.  ;o)
> 
> rpm -ql <package>    - list all files in package
> rpm -qd <package>    - list documentation for package
> rpm -qc <package>    - list config files for package

So many years using rpm and I never paid attention to these query options.

Thanks for this excellent tip.


-- 
 21:50:04 up 2 days,  9:07,  0 users,  load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Mart?n Marqu?s         |   SELECT 'mmarques' ||
Centro de Telem?tica        |       '@' || 'unl.edu.ar';
Universidad Nacional        |   DBA, Programador,
    del Litoral             |   Administrador
---------------------------------------------------------



From buildsys at redhat.com  Mon Nov 12 11:29:00 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 12 Nov 2007 06:29:00 -0500
Subject: rawhide report: 20071112 changes
Message-ID: <200711121129.lACBT0rq001092@porkchop.devel.redhat.com>

New package ruby-flexmock
	Mock object library for ruby

New package rubyripper
	Open-source secure ripper for Linux

New package ultimatestunts
	UltimateStunts is a remake of the famous DOS-game Stunts


 
Updated Packages:

NetworkManager-openvpn-1:0.7.0-3.svn3047.fc9
--------------------------------------------
* Sun Nov 11 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-3.svn3047
- Copy spec from F-8
- Lower required NM version, F-8 version not yet in Rawhide

* Wed Oct 31 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-2.svn3047
- BuildRequire gettext

* Tue Oct 30 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-1.svn3047.fc8
- Upgrade to trunk, needed to be compatible with NM 0.7.0, rebuild for F-8

TnL-data-071111-1.fc9
---------------------

alleggl-0.4.3-1.fc9
-------------------
* Sun Nov 11 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.4.3-1
- New upstream release 0.4.3
- Drop prebuild doxygen Source as upstream now includes prebuild doxygen docs

bodhi-0.4.0-1.fc9
-----------------
* Sun Nov 11 2007 Luke Macken <lmacken at redhat.com> - 0.4.0-1
- Lots of bodhi-client features

elfutils-0.131-1.fc9
--------------------
* Sun Nov 11 2007 Roland McGrath <roland at redhat.com> - 0.131-1
- Update to 0.131
  - libdw: DW_FORM_ref_addr support; dwarf_formref entry point now deprecated;
    	   bug fixes for oddly-formatted DWARF
  - libdwfl: bug fixes in offline archive support, symbol table handling;
	     apply partial relocations for dwfl_module_address_section on ET_REL
  - libebl: powerpc backend support for Altivec registers

epiphany-extensions-2.20.1-2.fc9
--------------------------------
* Tue Nov 06 2007 Peter Gordon <peter at thecodergeek.com> - 2.20.1-2
- Rebuild for new Gecko (Firefox 2.0.0.9)

* Mon Oct 15 2007 Peter Gordon <peter at thecodergeek.com> - 2.20.1-1
- Update to new upstream release (2.20.1), which fixes the "About" dialog of
  the AdBlocker extension and contains updated translations for Thai (th) and
  Catalan (ca). 
- Use the system libtool for building, to avoid unnecessary RPATH inclusions.

* Tue Sep 18 2007 Peter Gordon <peter at thecodergeek.com> - 2.20.0-1
- Update to new upstream release (2.20.0).

fmio-2.0.8-10.fc9
-----------------
* Sun Nov 11 2007 Andy Shevchenko <andy at smile.org.ua> 2.0.8-10
- do not require WindowMaker for GUI part (#222758)
- do not build drivers with direct I/O (#205721)

glibmm24-2.14.2-1.fc9
---------------------
* Sun Nov 04 2007 Denis Leroy <denis at poolshark.org> - 2.14.2-1
- Update to 2.14.2, BRs update

gmpc-0.15.1-1.fc9
-----------------
* Sun Nov 11 2007 Adrian Reber <adrian at lisas.de> - 0.15.1-1
- update to 0.15.1
- dropped gmpc-fix-album-play-order.diff patch
- two more plugins (avahi, shout)

gnome-keyring-2.20.1-4.fc9
--------------------------
* Sun Nov 11 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.1-4
- Don't ship a .la file (#370531)

* Thu Oct 25 2007 Christopher Aillon <caillon at redhat.com> - 2.20.1-3
- Rebuild

* Mon Oct 15 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.1-2
- Disable the auto-unlock question for now (#312531)

gtkmm24-2.12.3-1.fc9
--------------------
* Sun Nov 11 2007 Denis Leroy <denis at poolshark.org> - 2.12.3-1
- Update to 2.12.3, bug fix

haproxy-1.3.12.4-1.fc9
----------------------
* Mon Nov 05 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 1.3.12.4-1
- update to 1.3.12.4

* Thu Nov 01 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 1.3.12.3-1
- update to 1.3.12.3

* Fri Sep 21 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 1.3.12.2-3
- fix init script 'reload' task

hunspell-pt-0.20071106-1.fc9
----------------------------
* Sun Nov 11 2007 Caolan McNamara <caolanm at redhat.com> - 0.20071106-1
- latest version

icecream-0.8.0-3.20071101svn.fc9
--------------------------------

irssi-0.8.12-2.fc9
------------------
* Sun Nov 11 2007 Marek Mahut <mmahut fedoraproject.org> - 0.8.12-2
- Enabling perl build-in support as per request in BZ#375121

libmpd-0.14.0-1.fc9
-------------------
* Sun Nov 11 2007 Adrian Reber <adrian at lisas.de> - 0.14.0-1
- update to 0.14.0

liferea-1.4.7-1.fc9
-------------------
* Sun Nov 11 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.4.7-1
- Update to 1.4.7.

metacity-2.20.0-4.fc9
---------------------
* Sun Nov 11 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Fix a crash when the number of workspaces is 1

mkinitrd-6.0.19-5.fc9
---------------------
* Sun Nov 11 2007 Jeremy Katz <katzj at redhat.com> - 6.0.19-5
- and another rebuild

mono-1.2.5.2-1.fc9
------------------
* Sun Nov 11 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.2.5.2-1
- Bump to next version

* Fri Nov 09 2007 Ray Strode <rstrode at redhat.com> - 1.2.5.1-4
- Apply dropped patch (bug 371781), found by Eskil Bylund

* Wed Nov 07 2007 Alexander Larsson <alexl at redhat.com> - 1.2.5.1-3
- Fix overflow in Mono.Math.BigInteger class (#367551)
  CVE-2007-5197

monodevelop-0.17-3.fc9
----------------------
* Sun Nov 11 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.17-3
- excludearch ppc64

* Sun Nov 11 2007 David Nielsen <david at lovesunix.net> - 0.17-2
- Remove support for Fedora < 5
- rediff config patch

* Thu Nov 08 2007 David Nielsen <david at lovesunix.net> - 0.17-1
- Update to MonoDevelop Beta 2

nas-1.9.1-2.fc9
---------------
* Sun Nov 11 2007 Frank B??ttner  <frank-buettner at gmx.net> - 1.9.1-2
- fix spec file

* Sun Nov 11 2007 Frank B??ttner  <frank-buettner at gmx.net> - 1.9.1-1
- update to 1.9.1
 - remove unneeded patches

ndesk-dbus-0.6.0-1.fc9
----------------------
* Thu Nov 08 2007 David Nielsen <david at lovesunix.net> - 0.6.0-1
- bump to 0.6.0 
- clean up spec
- upstream is now officially renamed to ndesk-dbus as promised

netembryo-0.0.4-1.fc9
---------------------
* Sun Nov 11 2007 Dominik Mierzejewski <rpm at greysector.net> 0.0.4-1
- updated to release
pitivi-0.11.0-2.fc9
-------------------
* Sun Nov 11 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.0-2
- Add missing BR

pychess-0.8-0.1.beta1.fc9
-------------------------
* Sun Nov 11 2007 Michel Salim <michel.sylvan at gmail.com> - 0.8-0.1.beta1
- Update to 0.8beta1
python-minihallib-0.1.10-1.fc9
------------------------------
* Sun Nov 11 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.10-1
- update to the last release

qjackctl-0.3.1a-5.fc9
---------------------
* Mon Nov 12 2007 Anthony Green <green at redhat.com> 0.3.1a-5
- Force use of qmake-qt4 again.  I'm getting closer.

* Mon Nov 12 2007 Anthony Green <green at redhat.com> 0.3.1a-4
- Force use of qmake-qt4 again.

* Mon Nov 12 2007 Anthony Green <green at redhat.com> 0.3.1a-3
- Force use of qmake-qt4.

rhythmbox-0.11.3-1.fc9
----------------------
* Mon Nov 12 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.3-1
- Update to 0.11.3
- Remove a whole load of upstreamed patches

* Sat Nov 10 2007 Matthias Clasen <mclasen at redhat.com> - 0.11.2-14
- Rebuild against newer libmtp

* Wed Oct 31 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.2-13
- Rebuild for new totem

smb4k-0.8.6-1.fc9
-----------------
* Sun Nov 11 2007 Marcin Garski <mgarski[AT]post.pl> 0.8.6-1
- Update to 0.8.6

taglib-1.5-0.6.20071111svn.fc9
------------------------------
* Sun Nov 11 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.5-0.6.20071111svn
- svn20071111 snapshot (#376241)

tomboy-0.8.1-2.fc9
------------------
* Tue Nov 06 2007 Ray Strode <rstrode at redhat.com> - 0.8.1-2
- Fix bug 252294 (CVE-2005-4790)

totem-2.21.2-1.fc9
------------------
* Mon Nov 12 2007 - Bastien Nocera <bnocera at redhat.com> - 2.21.2-1
- Update to 2.21.2

vala-0.1.4-2.fc9
----------------
* Sun Nov 11 2007 Michel Salim <michel.sylvan at gmail.com> - 0.1.4-2
- Add build dependency on devhelp

* Fri Oct 19 2007 Michel Salim <michel.sylvan at gmail.com> - 0.1.4-1
- Update to 0.1.4
- Put newly-added documentation in its own subpackage (depends on devhelp)

xorg-x11-drv-radeonhd-0.0.2-0.16.20071105git.fc9
------------------------------------------------
* Sun Nov 11 2007 Hans Ulrich Niedermann <hun at n-dimensional.de> - 0.0.2-0.16.20071105git
- Updated README.fedora.
- Improved git commit log message.
- First F-7 and F-8 builds.

Broken deps for i386
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.i386 requires PyQt = 0:3.17.1
	TnL - 070909-2.fc8.i386 requires TnL-data = 0:070909
	TnL-data - 071111-1.fc9.noarch requires TnL >= 0:071111
	anaconda - 11.3.0.50-2.i386 requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.i386 requires libdhcp.so.1
	anaconda - 11.3.0.50-2.i386 requires libdhcp6client-0.10.so.0
	gnome-python2-totem - 2.20.0-1.fc8.i386 requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.i386 requires perl(Date::Calc)
	ruby-gtkmozembed - 0.16.0-14.fc9.i386 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1



Broken deps for x86_64
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.x86_64 requires PyQt = 0:3.17.1
	TnL - 070909-2.fc8.x86_64 requires TnL-data = 0:070909
	TnL-data - 071111-1.fc9.noarch requires TnL >= 0:071111
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp4client-3.0.6.so.0()(64bit)
	gnome-python2-totem - 2.20.0-1.fc8.x86_64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.x86_64 requires perl(Date::Calc)
	ruby-gtkmozembed - 0.16.0-14.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1



Broken deps for ppc
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc requires PyQt = 0:3.17.1
	TnL - 070909-2.fc8.ppc requires TnL-data = 0:070909
	TnL-data - 071111-1.fc9.noarch requires TnL >= 0:071111
	anaconda - 11.3.0.50-2.ppc requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.ppc requires libdhcp.so.1
	anaconda - 11.3.0.50-2.ppc requires libdhcp6client-0.10.so.0
	gnome-python2-totem - 2.20.0-1.fc8.ppc requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc requires perl(Date::Calc)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)



Broken deps for ppc64
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc64 requires PyQt = 0:3.17.1
	TnL - 070909-2.fc8.ppc64 requires TnL-data = 0:070909
	TnL-data - 071111-1.fc9.noarch requires TnL >= 0:071111
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	gnome-python2-totem - 2.20.0-1.fc8.ppc64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc64 requires perl(Date::Calc)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)





From markg85 at gmail.com  Mon Nov 12 11:30:11 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 12:30:11 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <gjkl05x62j.ln2@hubmaier.ceplovi.cz>
References: <1194613590.3255.10.camel@perihelion>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<gjkl05x62j.ln2@hubmaier.ceplovi.cz>
Message-ID: <6e24a8e80711120330w10de190bt9353324e9996c93e@mail.gmail.com>

Oke this discussion is getting big now.
Lets just draw a few conclusion here (of my own)

Fedora is a distribution for everyone in the world right?
Codec buddy is "the" solution for the codec issue right?
Because Fedora is for the world Codec buddy should be as well and has
(my opinion) to be made for the world as well. not just US.



From sundaram at fedoraproject.org  Mon Nov 12 11:30:42 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 12 Nov 2007 17:00:42 +0530
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711120330w10de190bt9353324e9996c93e@mail.gmail.com>
References: <1194613590.3255.10.camel@perihelion>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<20071109203142.GA6642@roque.1407.org>	<20071109223601.GB5480@devserv.devel.redhat.com>	<20071109235043.GB9111@roque.1407.org>	<20071110003156.GA11246@devserv.devel.redhat.com>	<20071110095657.GA6631@roque.1407.org>	<20071110132139.GC6788@devserv.devel.redhat.com>	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>	<gjkl05x62j.ln2@hubmaier.ceplovi.cz>
	<6e24a8e80711120330w10de190bt9353324e9996c93e@mail.gmail.com>
Message-ID: <47383962.2050404@fedoraproject.org>

Mark wrote:
> Oke this discussion is getting big now.
> Lets just draw a few conclusion here (of my own)
> 
> Fedora is a distribution for everyone in the world right?
> Codec buddy is "the" solution for the codec issue right?
> Because Fedora is for the world Codec buddy should be as well and has
> (my opinion) to be made for the world as well. not just US.

Just in case, you haven't yet understood the issue, Fedora is not a 
separate legal entity. Red Hat is the legal entity behind Fedora and is 
legally bound by U.S laws and cannot ignore it.

If you have a actual solutions to any problems, feel free to detail it. 
Otherwise, we are just going in circles here.

Rahul



From markg85 at gmail.com  Mon Nov 12 11:38:59 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 12:38:59 +0100
Subject: "Extension Buddy" for Fedora 9?
Message-ID: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>

Hey,

A few days ago i installed Audacious on my Fedora 8 and it works fine!
no issue with that. But now i wanted to open up a .m3u file extension
and fedora didn't know what to do with it.. so i had to select the
audio player for it manually (Audacious). And there are a lot more
extensions that fedora doesn't know of. .m3u is just an example.

Now because of this i'm wondering if it would be a good idea to have a
"Codec Budde" for the extensions (lets call it Extension Buddy) that
fixes extensions for files if the program than can play it is
installed or that it shows a list of possible applications that can
handle that extension (like Codec Buddy with the codecs) or that it
lets you select a default application for every single extension (that
last part is needed in linux).

So what do you think of it?
good idea? bad idea?

Thanx,
Mark.



From dtimms at iinet.net.au  Mon Nov 12 11:39:43 2007
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 12 Nov 2007 22:39:43 +1100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <64b14b300711120056q4daaab33pb53854ef9b976bdf@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<64b14b300711120056q4daaab33pb53854ef9b976bdf@mail.gmail.com>
Message-ID: <47383B7F.5020209@iinet.net.au>

Valent Turkovic wrote:
> On 11/12/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
>> Hi,
>>
>> I have 2 laptops and I used the smoltSendProfile and I seem to get the
>> same url for both laptops, ie. the later sent profile overwrites the
>> previous one...
>>
>> I'm sending both profiles from same adsl line and I'm behing a NAT
>> adsl router, so could this be an issue (same IP) ?
>>
>> Is this a feature or a bug?
>>
>> How can I send multiple laptop profiles and see them all online?
>>
>> Thank you very much in advance,
>> Valent.
>>
> 
> This is the profile:
> http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
Hey Valent,

I noticed that myself when I first looked at your distorted audio entry 
in bugzilla - I saw a machine with vmware graphics and vmware {amd} 
pcnet card.
I was about to say that doesn't make sense in the bug, so I decided to 
copy an paste the uuid from the bugzilla again. I then found that it was 
showing the HP machine that matched what you had attached in the bug.

1. Did you send an entry for a vmware machine at all ?
- if not then the "universally unique" ids might be gettting screwed and 
the smolt folks need to know quick smart.

2. Did you copy your data between new and old machines {or vms}, perhaps 
copying the storage of the smolt UUID ?

3. {smolt devs} Perhaps the web interface is having problems - eg the 
data is correctly sent and stored, but we are actually getting a 
different record's entry sometimes when we query the smolt data ?

DaveT.



From darrellpf at gmail.com  Sat Nov 10 07:22:03 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Fri, 9 Nov 2007 23:22:03 -0800
Subject: rawhide report: 20071109 changes
In-Reply-To: <47355AA9.6030203@mindspring.com>
References: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
	<20071109134826.334610c7@redhat.com> <47355AA9.6030203@mindspring.com>
Message-ID: <f6e5806f0711092322qacb1321r69221397aa56a561@mail.gmail.com>

Richard Hally <rhally at mindspring.com> wrote:

>
> Yippy kii yea! Now we're back to the old bust'em up.
>
> On a fresh install of F8 (default install minus the "office and productivity"
> stuff) switching to the development repo and updating ~150 packages, I get a
> problem going to runlevel 5 (something about "x" respawning too fast) and no
> login screen. Runlevel 3 login and startx works.
>
> replacing the gdm package that was in the update with the previously installed
> gdm fixed the problem.
>

I also updated. It starts for me but is very minimal. Just a box with
names and not much else.

darrell



From fedora at camperquake.de  Mon Nov 12 11:46:23 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 12:46:23 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
Message-ID: <20071112124623.310b19d2@dhcp03.addix.net>

Hi.

On Mon, 12 Nov 2007 12:38:59 +0100, Mark wrote:

> So what do you think of it?
> good idea? bad idea?

Usually the programs installed register a list of extensions they are
able to handle. audacious seems to miss the m3u extension, this is 
a bug. Please file in bugzilla.



From markg85 at gmail.com  Mon Nov 12 11:46:37 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 12:46:37 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <47383962.2050404@fedoraproject.org>
References: <1194613590.3255.10.camel@perihelion>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<gjkl05x62j.ln2@hubmaier.ceplovi.cz>
	<6e24a8e80711120330w10de190bt9353324e9996c93e@mail.gmail.com>
	<47383962.2050404@fedoraproject.org>
Message-ID: <6e24a8e80711120346s2c989b7exf6916cb49cd76d1f@mail.gmail.com>

2007/11/12, Rahul Sundaram <sundaram at fedoraproject.org>:
> Mark wrote:
> > Oke this discussion is getting big now.
> > Lets just draw a few conclusion here (of my own)
> >
> > Fedora is a distribution for everyone in the world right?
> > Codec buddy is "the" solution for the codec issue right?
> > Because Fedora is for the world Codec buddy should be as well and has
> > (my opinion) to be made for the world as well. not just US.
>
> Just in case, you haven't yet understood the issue, Fedora is not a
> separate legal entity. Red Hat is the legal entity behind Fedora and is
> legally bound by U.S laws and cannot ignore it.
>
> If you have a actual solutions to any problems, feel free to detail it.
> Otherwise, we are just going in circles here.
>
> Rahul

Well my solution would be to separate fedora from rad hat completely
and make it EU based or officially based in a country with no (nearly
no) patent stuff but i guess red hat isn't willing to do that.. Or
split it off with no home for Fedora at all. just only fans and
contributors without one actual location (that's how KDE works
right?).

Just one big global family ("sponsored" by red hat).

but i doubt that any of this will actually happen.



From sundaram at fedoraproject.org  Mon Nov 12 11:47:06 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 12 Nov 2007 17:17:06 +0530
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711120346s2c989b7exf6916cb49cd76d1f@mail.gmail.com>
References: <1194613590.3255.10.camel@perihelion>	<20071109223601.GB5480@devserv.devel.redhat.com>	<20071109235043.GB9111@roque.1407.org>	<20071110003156.GA11246@devserv.devel.redhat.com>	<20071110095657.GA6631@roque.1407.org>	<20071110132139.GC6788@devserv.devel.redhat.com>	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>	<gjkl05x62j.ln2@hubmaier.ceplovi.cz>	<6e24a8e80711120330w10de190bt9353324e9996c93e@mail.gmail.com>	<47383962.2050404@fedoraproject.org>
	<6e24a8e80711120346s2c989b7exf6916cb49cd76d1f@mail.gmail.com>
Message-ID: <47383D3A.6000101@fedoraproject.org>

Mark wrote:

> 
> Well my solution would be to separate fedora from rad hat completely
> and make it EU based or officially based in a country with no (nearly
> no) patent stuff but i guess red hat isn't willing to do that.. Or
> split it off with no home for Fedora at all. just only fans and
> contributors without one actual location (that's how KDE works
> right?).

Having Fedora with no home is a good way to kill it. KDE doesn't work 
like that. It has a registered non-profit foundation.

http://ev.kde.org/

Your solution isn't a practical one.

Rahul



From michael.wiktowy at gmail.com  Mon Nov 12 11:53:44 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Mon, 12 Nov 2007 06:53:44 -0500
Subject: SELinux Troubleshooter messages from upgrade from F7->F8
In-Reply-To: <3e4ec4600711101123n3ca28c9va454a2566f089bb8@mail.gmail.com>
References: <3e4ec4600711101123n3ca28c9va454a2566f089bb8@mail.gmail.com>
Message-ID: <3e4ec4600711120353x6025c92fx462c2ffc8107f0b7@mail.gmail.com>

(Disclaimer: SELinux haters please reserve your bile for one of the
other many many long "SELinux-sux" threads ... this isn't intended as
one of them as I like SELinux and just want to provide my feedback to
make it better.)

Well ... I didn't put selinux in permissive mode when I did a yum
upgrade. Partially to tempt fate; partially because I figured it
should work regardless.; partially because I forgot :]

Things seem to be working OK but there are a couple of glitches that I
am trying to track down yet.

So here are the setroubleshoot errors that appeared in my logs for the
complete yum upgrade:

Nov  9 02:39:19 localhost setroubleshoot:      SELinux is preventing
/sbin/ldconfig (ldconfig_t) "write" to ldconfig (var_t).      For
complete SELinux messages. run sealert -l
1594b6a8-1f16-44c9-b7ee-f5ef4621257f
Nov  9 02:41:56 localhost setroubleshoot:      SELinux is preventing
/sbin/restorecon (restorecon_t) "write" to pipe:[50470] (rpm_t).
For complete SELinux messages. run sealert -l
6caaa2ac-84bb-4962-a78e-b10e24f8fef0
Nov  9 02:51:46 localhost setroubleshoot:      SELinux is preventing
/usr/sbin/nscd (nscd_t) "write" to pipe:[50470] (rpm_t).      For
complete SELinux messages. run sealert -l
e7ace06a-0a4b-4832-bdac-1f538535f5a3
Nov  9 02:51:46 localhost setroubleshoot:      SELinux is preventing
semanage (semanage_t) "write" to pipe:[50470] (rpm_t).      For
complete SELinux messages. run sealert -l
e2c86088-44f8-4e9b-b71c-d1ea72a2b3d3
Nov  9 02:52:14 localhost setroubleshoot:      SELinux is preventing
/usr/sbin/useradd (useradd_t) "read write" to faillog (var_log_t).
 For complete SELinux messages. run sealert -l
de30be19-d51b-482e-b112-6fa9954a70e9
Nov  9 03:04:27 localhost setroubleshoot:      SELinux is preventing
/usr/sbin/semodule (semanage_t) "write" to pipe:[50470] (rpm_t).
For complete SELinux messages. run sealert -l
e2c86088-44f8-4e9b-b71c-d1ea72a2b3d3
Nov  9 03:09:36 localhost setroubleshoot:      SELinux prevented
/sbin/setfiles from using the terminal 0.      For complete SELinux
messages. run sealert -l 74507fc1-6b02-4285-92d9-d0123f0cea60
Nov  9 03:09:42 localhost setroubleshoot: [rpc.ERROR] exception
DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect
to socket /var/run/dbus/system_bus_socket: Connection refused
Traceback (most recent call last):   File
"/usr/lib/python2.5/site-packages/setroubleshoot/server.py", line 434,
in RunFaultServer     setroubleshootd_dbus = SetroubleshootdDBus()
File "/usr/lib/python2.5/site-packages/setroubleshoot/server.py", line
345, in __init__     self.bus = dbus.SystemBus()   File
"/usr/lib/python2.5/site-packages/dbus/_dbus.py", line 201, in __new__
    private=private)   File
"/usr/lib/python2.5/site-packages/dbus/_dbus.py", line 107, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.5/site-packages/dbus/bus.py", line 121, in
__new__     bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect
to socket /var/run/dbus/system_bus_socket: Connection refused

There were multiple repetitons of each of them (particularly the
ldconfig_t one).

My questions:
1) Should SELinux stay out of the way for a yum upgrade in
enforcing/targetted mode?
2) Is there a straightforward way to go back and reinstall all the
currently installed rpms (while not in enforcing mode) so that some of
these blocked pre-post script activities are allowed to do their
thing? There are just too many affected packages to do this manually.
3) Are these bugzilla-worthy?

/Mike



From caillon at redhat.com  Mon Nov 12 11:56:47 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 12 Nov 2007 12:56:47 +0100
Subject: rawhide report: 20071112 changes
In-Reply-To: <200711121129.lACBT0rq001092@porkchop.devel.redhat.com>
References: <200711121129.lACBT0rq001092@porkchop.devel.redhat.com>
Message-ID: <47383F7F.6030202@redhat.com>

Build System wrote:
> NetworkManager-openvpn-1:0.7.0-3.svn3047.fc9
> --------------------------------------------
> * Sun Nov 11 2007 Tim Niemueller <tim at niemueller.de> 1:0.7.0-3.svn3047
> - Copy spec from F-8
> - Lower required NM version, F-8 version not yet in Rawhide

This should really get a bug filed against the NM package in rawhide. 
Don't revert the requires to something that really won't work with the 
package just to satisfy deps.

My guess is that dcbw intended for the F8 package to get inherited into 
rawhide for now, but since someone else had to rebuild the package for a 
dbus-glib issue, that is overriding the dist-f8 version....



From loupgaroublond at gmail.com  Sat Nov 10 03:56:12 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Fri, 9 Nov 2007 22:56:12 -0500
Subject: Smolt and software information
In-Reply-To: <473529A6.5080304@redhat.com>
References: <7f692fec0711090829j1b80e26fr5905c2577b2cd7f9@mail.gmail.com>
	<1194659621.430.24.camel@naomi>
	<7f692fec0711091835u5717c7d5qf24f3a999b67a498@mail.gmail.com>
	<1194665886.430.30.camel@naomi> <473529A6.5080304@redhat.com>
Message-ID: <7f692fec0711091956t71f11cd6jc371f4572c022427@mail.gmail.com>

On Nov 9, 2007 10:46 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> Andrew Bartlett wrote:
>
> > Perhaps just list it if the filesystems are in the standard set supplied
> > with Fedora?

Nope, the issue was brought up because we already know what Fedora
users use.  What Red Hat tell them is good for them.  (Actually, ext3
is the default for historical and stability reasons.)

Some users use other OSes shockingly enough; more suprising is that
they don't always like ext3.  (You might say they are impatient, and
want their files faster.  They call this 'performance', which confuses
me.)  It's been mentioned that statistics on that (Just like with
SELinux) would be interesting.

>
> So if someone were using "mynewsecretfs" don't report it?  I guess I
> could see that.  Although keeping up the "acceptable to report" list
> might be a trick.

I think we just need a 'modify what we send link' and then a list of
checkboxes to disclude information.  This way it's there,
configurable, etc....

Anything else would be tricky.

-Yaakov



From markg85 at gmail.com  Mon Nov 12 12:12:51 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 13:12:51 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <20071112124623.310b19d2@dhcp03.addix.net>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
Message-ID: <6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>

2007/11/12, Ralf Ertzinger <fedora at camperquake.de>:
> Hi.
>
> On Mon, 12 Nov 2007 12:38:59 +0100, Mark wrote:
>
> > So what do you think of it?
> > good idea? bad idea?
>
> Usually the programs installed register a list of extensions they are
> able to handle. audacious seems to miss the m3u extension, this is
> a bug. Please file in bugzilla.

Not the kind of reply that i was hoping to see ^_^
i will fill a bug report.

but lets take another extension. .rar
a "Extension Buddy" would be handy for that. (i know how to get rar
capability but it's just for the idea!)



From dtimms at iinet.net.au  Mon Nov 12 12:13:06 2007
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 12 Nov 2007 23:13:06 +1100
Subject: probs with nvidia sata
In-Reply-To: <a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
Message-ID: <47384352.3030801@iinet.net.au>

ne... wrote:
> On 12/11/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>> Le Lun 12 novembre 2007 11:29, ne... a ?crit :
>>
>>>> Provide us with double error or some such output...
>>>> And some HW info and take a look at
>>> AMD X2 4400+ Gigabyte GA-K8NS Ultra-939 mobo, 2x 80GB & 1x 200GB
>>> Western Digital hard drives.
>> I can't speak for the install part since I use a rolling rawhide setup
>> but this hardware should work fine once installed (I have a AMD X2
>> 4400+ + Gigabyte GA-K8N Ultra-9 mobo, maxtor drives)
> My thoughts exactly till I got the double free error. This box also has
> FC7, FC6, FC5, FC4 & FC3 installs on it. Plus openSUSE 10.1 & CentOS 5.
> Never had any problems before yesterday. My hard drives are all SATA tho...
Does a DVD install proceed ?

I've noticed that you need to put the iso on a non-lvm disk to do an 
method=hd install/upgrade. If I don't, I get similar sort of message 
{give me your driver disk}.

Any way, just some thoughts, I'm keen for issues to have solutions - and 
if the solution can't make it back into the installer - then at least 
being able to notate the smolt page with hardware bits that aren't / no 
longer work is helpful for others with the same hw.

Capturing the error even on camera, or typing it in, or using a serial 
console to another PC, could be illuminating for those who know what to 
look for.

DaveT.



From dtimms at iinet.net.au  Mon Nov 12 12:15:29 2007
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 12 Nov 2007 23:15:29 +1100
Subject: Praise for F-8 - java and azureus ?
In-Reply-To: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
Message-ID: <473843E1.4030104@iinet.net.au>

Linus Walleij wrote:
> F-8 totally kicks ass. It works like a charm on this brand new x86_64 
> SMP thing, extremely interactive during high load (CFS scheduler I 
> believe), the new IcedTea java is awesome for being done in such a 
> hurry.
So, does azureus work OK ?

I have not had success with it. Either doesn't get past start, or I 
can't get to the torrent detail screen - the tab where you can see 
downloads and completion etc.

DaveT.



From andrewparker at bigfoot.com  Mon Nov 12 12:17:32 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Mon, 12 Nov 2007 07:17:32 -0500
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <20071112124623.310b19d2@dhcp03.addix.net>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
Message-ID: <6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>

On Nov 12, 2007 6:46 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
>
> On Mon, 12 Nov 2007 12:38:59 +0100, Mark wrote:
>
> > So what do you think of it?
> > good idea? bad idea?
>
> Usually the programs installed register a list of extensions they are
> able to handle. audacious seems to miss the m3u extension, this is
> a bug. Please file in bugzilla.

Sure, thats a bug, but what if audacious wasn't installed?  How would
a user know what to install?

Would be nice if a user tried to open a file that didn't have an
application associated with it and up popped a list of applications
that could be installed.  Would be even cooler if the you could select
one to install, it installed, then opened it up for you.



From kulbirsaini at students.iiit.ac.in  Mon Nov 12 12:27:07 2007
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Mon, 12 Nov 2007 17:57:07 +0530 (IST)
Subject: Praise for F-8
In-Reply-To: <473825C7.9010805@hi.is>
References: <Pine.GSO.4.60.0711121007330.501@igloo.df.lth.se>
	<a227b70c0711120141p3d56c8al48189b0ac642597c@mail.gmail.com>
	<473825C7.9010805@hi.is>
Message-ID: <51531.172.16.34.34.1194870427.squirrel@students.iiit.ac.in>


  Fedora 8 worked like a charm on my AMD64 proc and nvidia nForce 4 mobo.
I love the extremely glossy interface right from anaconda to desktop.
Compiz just works out of the box. Remote desktop is pretty simple to
use. Looks like it was made for noobs.
  The best thing I would say is Codeina and Pulseaudio.


-------------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Linux-Blog: http://linux.saini.co.in/
-------------------------------------------------------




From jkeating at redhat.com  Mon Nov 12 12:29:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 07:29:53 -0500
Subject: Random question about Koji's reporting of completion date vs.
 finished date
In-Reply-To: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>
References: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>
Message-ID: <20071112072953.0fa70810@redhat.com>

On Sat, 10 Nov 2007 15:40:45 -0500
"Oisin Feeley" <oisin.feeley at gmail.com> wrote:

> For example, this nspluginwrapper build[1]
> reports a start/complete date of 21 Sept. 2007, but the
> buildinfo page for the package[2] displays a "finished"
> date of 09 Nov 2007 (entry for nspluginwrapper-0.9.91.5-3.fc8 
> is approximately halfway down the page currently).

Uh, the build you linked to in [1] has a date of: 	Fri, 21 Sep
2007 01:19:30 MST

And the list you linked to in [2] has an entry for
nspluginwrapper-0.9.91.5-3.fc8 that has a date of 2007-09-21 01:19:30

How are these not the same dates?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/4da0f2fb/attachment.sig>

From jkeating at redhat.com  Mon Nov 12 12:30:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 07:30:32 -0500
Subject: devhelp broken again?
In-Reply-To: <f224c6140711110924i6fcf50cbs97cb990161ecc264@mail.gmail.com>
References: <f224c6140711110910j5be83ba5p713cbc60e470bdff@mail.gmail.com>
	<f224c6140711110924i6fcf50cbs97cb990161ecc264@mail.gmail.com>
Message-ID: <20071112073032.268990a0@redhat.com>

On Sun, 11 Nov 2007 12:24:22 -0500
"Michel Salim" <michel.sylvan at gmail.com> wrote:

> that pushes yelp, devhelp, epiphany and firefox, but no corresponding
> entry for F-8. What seems to have happened is that Koji is for some
> reason already using Firefox 2.0.0.9, but does not have access to the
> matching devhelp.
> 
> Could someone push the needed packages?

Devhelp was made available last night.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/7c008ba9/attachment.sig>

From jkeating at redhat.com  Mon Nov 12 12:30:58 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 07:30:58 -0500
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
Message-ID: <20071112073058.75bfe2eb@redhat.com>

On Sun, 11 Nov 2007 12:26:30 -0500
"Dr. Diesel" <dr.diesel at gmail.com> wrote:

> The video is very slow and choppy.  Totem movie player has no problem
> with it.  Xine plays about 5 seconds, pauses for a second then
> continues.
> 
> Any thoughts?

Are you using compiz?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/83495bad/attachment.sig>

From jwboyer at gmail.com  Sat Nov 10 16:31:47 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 10 Nov 2007 10:31:47 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071110104245.6b783490@j2solutions.net>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
Message-ID: <20071110103147.0a0812d5@vader.jdub.homelinux.org>

On Sat, 10 Nov 2007 10:42:45 -0500
Jesse Keating <jkeating at j2solutions.net> wrote:

> On Sat, 10 Nov 2007 14:10:38 +0100
> Nils Philippsen <nphilipp at redhat.com> wrote:
> 
> > > a) quick operations by avoiding round-trips to a remote server if
> > > not necessary
> > > b) easy branching and merging
> > > c) atomic operations
> > > d) co-maintainers (or maintainer apprentices) wouldn't need commit
> > > access to the main repository
> > > e) ability to do embargoed stuff like security fixes before they're
> > > public  
> > 
> > f) ability to rename things, especially handy for re-worked patches in
> > our context
> 
> I don't disagree that those things are nice with DVCS.  What I question
> is the amount of times they're necessary to warrant the extra
> complexity of a DVCS thrown at every user.
> 
> And still I continue to hear just features of dvcs, but not applied to
> a workflow for our Package vcs.

I think it's because you have two classes of users.  Developers, and
packagers.

There are several people that are active developers for the packages
they maintain.  They're used to working on the code base itself,
developing patches, etc.  RPM specfiles are almost the last step in
their day-to-day dealings with a package.  These are the people that
are the major proponents of a DVCS.

Then there are the packagers.  They mostly take the upstream tarballs,
do the specfile work, and build things.  There isn't a lot of need for
multiple commits, offline working, etc.  The entire VCS setup we
currently use is geared toward packagers.

josh



From alexl at redhat.com  Mon Nov 12 12:35:20 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 12 Nov 2007 13:35:20 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
Message-ID: <1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>


On Mon, 2007-11-12 at 07:17 -0500, Andrew Parker wrote:
> On Nov 12, 2007 6:46 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> > Hi.
> >
> > On Mon, 12 Nov 2007 12:38:59 +0100, Mark wrote:
> >
> > > So what do you think of it?
> > > good idea? bad idea?
> >
> > Usually the programs installed register a list of extensions they are
> > able to handle. audacious seems to miss the m3u extension, this is
> > a bug. Please file in bugzilla.
> 
> Sure, thats a bug, but what if audacious wasn't installed?  How would
> a user know what to install?
> 
> Would be nice if a user tried to open a file that didn't have an
> application associated with it and up popped a list of applications
> that could be installed.  Would be even cooler if the you could select
> one to install, it installed, then opened it up for you.

It would be cool if we could autoextract mime handling information from
desktop files installed in /usr/share/applications and generate
"mime(application/pdf)" style rpm provides.



From jkeating at redhat.com  Mon Nov 12 12:34:57 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 07:34:57 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071110103147.0a0812d5@vader.jdub.homelinux.org>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
	<20071110103147.0a0812d5@vader.jdub.homelinux.org>
Message-ID: <20071112073457.41c485a8@redhat.com>

On Sat, 10 Nov 2007 10:31:47 -0600
Josh Boyer <jwboyer at gmail.com> wrote:

> There are several people that are active developers for the packages
> they maintain.  They're used to working on the code base itself,
> developing patches, etc.  RPM specfiles are almost the last step in
> their day-to-day dealings with a package.  These are the people that
> are the major proponents of a DVCS.
> 
> Then there are the packagers.  They mostly take the upstream tarballs,
> do the specfile work, and build things.  There isn't a lot of need for
> multiple commits, offline working, etc.  The entire VCS setup we
> currently use is geared toward packagers.

Which is mostly because it's for... packages.  Development should be
happening upstream or elsewhere.  I think that a lot of it is coming
from RHEL developers who are stuck with a package version for many
years and build up a lot of cruft around it in package VCS, yet in
Fedora we're free to move to newer upstream releases that fix problems
and such, and thus the build up around our packages should be minimal.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/bce4ef1f/attachment.sig>

From dtimms at iinet.net.au  Mon Nov 12 12:37:35 2007
From: dtimms at iinet.net.au (David Timms)
Date: Mon, 12 Nov 2007 23:37:35 +1100
Subject: "File Type" Buddy for Fedora 9?
In-Reply-To: <6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>	<20071112124623.310b19d2@dhcp03.addix.net>
	<6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>
Message-ID: <4738490F.2040406@iinet.net.au>

Mark wrote:
> 2007/11/12, Ralf Ertzinger <fedora at camperquake.de>:
>> Usually the programs installed register a list of extensions they are
>> able to handle. audacious seems to miss the m3u extension, this is
>> a bug. Please file in bugzilla.
> 
> Not the kind of reply that i was hoping to see ^_^
> i will fill a bug report.
Bug reports for both issues, and request for enhancements in general 
lead to fixes getting released. I think bug'ging it is the best way to 
go ;) Even more so for a repeatable problem, or well thought out enhancment

 > but lets take another extension. .rar
 > a "Extension Buddy" would be handy for that. (i know how to get rar
 > capability but it's just for the idea!)

I think what you mean is that given any file type we could have a 
central registry of packages that implement the file type {view, play, 
edit etc}.

Workflow:
1(a) Johnny receives from mary a thing-a-me.whatnot file
or
1(b) Mary downloads a i-cant-tell-how-to-open-this file
2. Click the file
{3. Virus scanner checks it.}
4. file "the-file" is run to determine file type {extensions mean 
nothing - I can send you a music file called scream.loudly whose actual 
type is ogg - your player and tools will act on it based on it's 
contents - not it's right most part of file-name.}
5. a list of {fedora only} packages that implement that file type are 
presented.
6. expanding the more info panel allows Mary or Johnny to get enough 
info to decide which package they would like to try.
7. Mary or Johnny click the install package button.
8. yum and friends download the package {and dependencies}, and install 
the package.
9. User is informed that the capability to "use" double-clicked file has 
been installed.
10. Click the file again - the app now opens it.

Any adjustments needed ?

Actually the db could store the "use"s eg play view edit hear modify 
convert etc, and be more informative eg the descriptions could say:
- view file.presentation
    "fast presentation viewer"
- edit
     openoffice impress

DaveT.



From andy at warmcat.com  Mon Nov 12 12:37:49 2007
From: andy at warmcat.com (Andy Green)
Date: Mon, 12 Nov 2007 12:37:49 +0000
Subject: SELinux Troubleshooter messages from upgrade from F7->F8
In-Reply-To: <3e4ec4600711120353x6025c92fx462c2ffc8107f0b7@mail.gmail.com>
References: <3e4ec4600711101123n3ca28c9va454a2566f089bb8@mail.gmail.com>
	<3e4ec4600711120353x6025c92fx462c2ffc8107f0b7@mail.gmail.com>
Message-ID: <4738491D.1040903@warmcat.com>

Somebody in the thread at some point said:

> Things seem to be working OK but there are a couple of glitches that I
> am trying to track down yet.
> 
> So here are the setroubleshoot errors that appeared in my logs for the
> complete yum upgrade:
> 
> Nov  9 02:39:19 localhost setroubleshoot:      SELinux is preventing
> /sbin/ldconfig (ldconfig_t) "write" to ldconfig (var_t).      For
> complete SELinux messages. run sealert -l
> 1594b6a8-1f16-44c9-b7ee-f5ef4621257f

I think this is a mislabelled /var/cache/ldconfig.  Check if yours is
like this

# ll /var/cache/ldconfig -Zd
drwx------  root root system_u:object_r:ldconfig_cache_t /var/cache/ldconfig

If not:

# fixfiles relabel /var/cache/ldconfig

After that

# ldconfig

will find any new libs.

> Nov  9 02:41:56 localhost setroubleshoot:      SELinux is preventing
> /sbin/restorecon (restorecon_t) "write" to pipe:[50470] (rpm_t).
> For complete SELinux messages. run sealert -l
> 6caaa2ac-84bb-4962-a78e-b10e24f8fef0
> Nov  9 02:51:46 localhost setroubleshoot:      SELinux is preventing
> /usr/sbin/nscd (nscd_t) "write" to pipe:[50470] (rpm_t).      For
> complete SELinux messages. run sealert -l
> e7ace06a-0a4b-4832-bdac-1f538535f5a3
> Nov  9 02:51:46 localhost setroubleshoot:      SELinux is preventing
> semanage (semanage_t) "write" to pipe:[50470] (rpm_t).      For
> complete SELinux messages. run sealert -l
> e2c86088-44f8-4e9b-b71c-d1ea72a2b3d3
> Nov  9 02:52:14 localhost setroubleshoot:      SELinux is preventing
> /usr/sbin/useradd (useradd_t) "read write" to faillog (var_log_t).
>  For complete SELinux messages. run sealert -l
> de30be19-d51b-482e-b112-6fa9954a70e9
> Nov  9 03:04:27 localhost setroubleshoot:      SELinux is preventing
> /usr/sbin/semodule (semanage_t) "write" to pipe:[50470] (rpm_t).
> For complete SELinux messages. run sealert -l
> e2c86088-44f8-4e9b-b71c-d1ea72a2b3d3

Dunno.

> Nov  9 03:09:36 localhost setroubleshoot:      SELinux prevented
> /sbin/setfiles from using the terminal 0.      For complete SELinux
> messages. run sealert -l 74507fc1-6b02-4285-92d9-d0123f0cea60

Dunno.

> Nov  9 03:09:42 localhost setroubleshoot: [rpc.ERROR] exception
> DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect
> to socket /var/run/dbus/system_bus_socket: Connection refused

Is dbus running?

service messagebus status

> There were multiple repetitons of each of them (particularly the
> ldconfig_t one).
> 
> My questions:
> 1) Should SELinux stay out of the way for a yum upgrade in
> enforcing/targetted mode?

Yep.

> 2) Is there a straightforward way to go back and reinstall all the
> currently installed rpms (while not in enforcing mode) so that some of
> these blocked pre-post script activities are allowed to do their
> thing? There are just too many affected packages to do this manually.

ldconfig can be straightened out just be re-running it.  The libs from
the packages were already installed okay.

> 3) Are these bugzilla-worthy?

Up to you...

You might want to force a whole filesystem relabel...

touch /.autorelabel

and reboot.  But if there are no more funnies after fixing ldconfig I
probably wouldn't bother.

-Andy



From oisin.feeley at gmail.com  Mon Nov 12 12:38:13 2007
From: oisin.feeley at gmail.com (Oisin Feeley)
Date: Mon, 12 Nov 2007 07:38:13 -0500
Subject: Random question about Koji's reporting of completion date vs.
	finished date
In-Reply-To: <20071112072953.0fa70810@redhat.com>
References: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>
	<20071112072953.0fa70810@redhat.com>
Message-ID: <e5f157b0711120438ybe43e77o5b3484d5d7cdda6d@mail.gmail.com>

On Nov 12, 2007 7:29 AM, Jesse Keating <jkeating at redhat.com> wrote:
> On Sat, 10 Nov 2007 15:40:45 -0500
> "Oisin Feeley" <oisin.feeley at gmail.com> wrote:
>
> > For example, this nspluginwrapper build[1]
> > reports a start/complete date of 21 Sept. 2007, but the
> > buildinfo page for the package[2] displays a "finished"
> > date of 09 Nov 2007 (entry for nspluginwrapper-0.9.91.5-3.fc8
> > is approximately halfway down the page currently).
>
> Uh, the build you linked to in [1] has a date of:       Fri, 21 Sep
> 2007 01:19:30 MST
>
> And the list you linked to in [2] has an entry for
> nspluginwrapper-0.9.91.5-3.fc8 that has a date of 2007-09-21 01:19:30
>
> How are these not the same dates?

Doh!  Sorry, I just read them incorrectly.  Apologies for the noise.

Oisin



From andrewparker at bigfoot.com  Mon Nov 12 12:45:02 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Mon, 12 Nov 2007 07:45:02 -0500
Subject: "File Type" Buddy for Fedora 9?
In-Reply-To: <4738490F.2040406@iinet.net.au>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>
	<4738490F.2040406@iinet.net.au>
Message-ID: <6c3f5e6c0711120445k3911b6d1w9b5c96c496354226@mail.gmail.com>

On Nov 12, 2007 7:37 AM, David Timms <dtimms at iinet.net.au> wrote:
> Mark wrote:
> > 2007/11/12, Ralf Ertzinger <fedora at camperquake.de>:
> >> Usually the programs installed register a list of extensions they are
> >> able to handle. audacious seems to miss the m3u extension, this is
> >> a bug. Please file in bugzilla.
> >
> > Not the kind of reply that i was hoping to see ^_^
> > i will fill a bug report.
> Bug reports for both issues, and request for enhancements in general
> lead to fixes getting released. I think bug'ging it is the best way to
> go ;) Even more so for a repeatable problem, or well thought out enhancment
>
>  > but lets take another extension. .rar
>  > a "Extension Buddy" would be handy for that. (i know how to get rar
>  > capability but it's just for the idea!)
>
> I think what you mean is that given any file type we could have a
> central registry of packages that implement the file type {view, play,
> edit etc}.
>
> Workflow:
> 1(a) Johnny receives from mary a thing-a-me.whatnot file
> or
> 1(b) Mary downloads a i-cant-tell-how-to-open-this file
> 2. Click the file
> {3. Virus scanner checks it.}
> 4. file "the-file" is run to determine file type {extensions mean
> nothing - I can send you a music file called scream.loudly whose actual
> type is ogg - your player and tools will act on it based on it's
> contents - not it's right most part of file-name.}
> 5. a list of {fedora only} packages that implement that file type are
> presented.
> 6. expanding the more info panel allows Mary or Johnny to get enough
> info to decide which package they would like to try.
> 7. Mary or Johnny click the install package button.
> 8. yum and friends download the package {and dependencies}, and install
> the package.
> 9. User is informed that the capability to "use" double-clicked file has
> been installed.
> 10. Click the file again - the app now opens it.
>
> Any adjustments needed ?
>

repositories (a la yum) for the database.  then files that couldn't be
opened by fedora rpms could be provided by other "repos".

> Actually the db could store the "use"s eg play view edit hear modify
> convert etc, and be more informative eg the descriptions could say:
> - view file.presentation
>     "fast presentation viewer"
> - edit
>      openoffice impress
>
> DaveT.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From harald at redhat.com  Mon Nov 12 12:50:41 2007
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 12 Nov 2007 13:50:41 +0100
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
Message-ID: <fh9i71$71e$1@ger.gmane.org>

error: %post(nspluginwrapper-0.9.91.5-12.fc8.x86_64) scriptlet failed, exit status 1


Installed: nspluginwrapper.x86_64 0:0.9.91.5-12.fc8
Complete!



From triad at df.lth.se  Mon Nov 12 12:55:41 2007
From: triad at df.lth.se (Linus Walleij)
Date: Mon, 12 Nov 2007 13:55:41 +0100 (CET)
Subject: Doxygen and multilib
In-Reply-To: <20071110143717.374fd239@ghistelwchlohm.scrye.com>
References: <Pine.GSO.4.60.0710311749580.10686@igloo.df.lth.se>
	<4728B575.40300@redhat.com>
	<d9c612bf0711041102j25b12c8dtbd21d6029ca3ac1f@mail.gmail.com>
	<d9c612bf0711041137j1eface5fm4d32b893ca7fb03e@mail.gmail.com>
	<d9c612bf0711041226p339a189ex46b19067422a02a9@mail.gmail.com>
	<d9c612bf0711041523u17a6b72csaf79334053e0339a@mail.gmail.com>
	<Pine.GSO.4.60.0711050025260.8239@igloo.df.lth.se>
	<20071110143717.374fd239@ghistelwchlohm.scrye.com>
Message-ID: <Pine.GSO.4.60.0711121355060.501@igloo.df.lth.se>

On Sat, 10 Nov 2007, Kevin Fenzi wrote:

> Does that mean we should mass rebuild all the doxygen dependent
> packages (at least in rawhide) to fix any multilib issues caused by
> this bug?

Once 1.5.3 is pushed, yes, plus remove all the kludges introduced for 
interrim solutions.

Linus



From johannbg at hi.is  Mon Nov 12 13:07:43 2007
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Mon, 12 Nov 2007 13:07:43 +0000
Subject: probs with nvidia sata
In-Reply-To: <47384352.3030801@iinet.net.au>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
	<47384352.3030801@iinet.net.au>
Message-ID: <4738501F.4070103@hi.is>

David Timms wrote:
> ne... wrote:
>> On 12/11/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>>> Le Lun 12 novembre 2007 11:29, ne... a ?crit :
>>>
>>>>> Provide us with double error or some such output...
>>>>> And some HW info and take a look at
>>>> AMD X2 4400+ Gigabyte GA-K8NS Ultra-939 mobo, 2x 80GB & 1x 200GB
>>>> Western Digital hard drives.
>>> I can't speak for the install part since I use a rolling rawhide setup
>>> but this hardware should work fine once installed (I have a AMD X2
>>> 4400+ + Gigabyte GA-K8N Ultra-9 mobo, maxtor drives)
>> My thoughts exactly till I got the double free error. This box also has
>> FC7, FC6, FC5, FC4 & FC3 installs on it. Plus openSUSE 10.1 & CentOS 5.
>> Never had any problems before yesterday. My hard drives are all SATA 
>> tho...
> Does a DVD install proceed ?
>
> I've noticed that you need to put the iso on a non-lvm disk to do an 
> method=hd install/upgrade. If I don't, I get similar sort of message 
> {give me your driver disk}.
>
> Any way, just some thoughts, I'm keen for issues to have solutions - 
> and if the solution can't make it back into the installer - then at 
> least being able to notate the smolt page with hardware bits that 
> aren't / no longer work is helpful for others with the same hw.
>
> Capturing the error even on camera, or typing it in, or using a serial 
> console to another PC, could be illuminating for those who know what 
> to look for.
>
> DaveT.
>
Could this be primary partition problem, as in exceeding number of 
primary partitions MBR can handle ( 4 ) per disk?
Does any one know of any limitation regarding this ( 
Anaconda/grub/driver(s) )

We are talking about

Disk 1 FC3,FC4,FC5,FC6 MBR Full

Disk 2 FC7,FC8, OpenSUSE 10.1, CentOS 5 MBR Full

How are you partitioning the disks?

What types of disk do you have
Which disk is it failing on, the 200GB or the 80GB ones
Is the installation path on the same disk as the one your trying to 
install it on?
Does DVD install or NFS/FTP/HTTP/PXE ( Network ) install work?

Best regards
            Johann B.



From dr.diesel at gmail.com  Mon Nov 12 13:19:34 2007
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 12 Nov 2007 07:19:34 -0600
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <20071112073058.75bfe2eb@redhat.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112073058.75bfe2eb@redhat.com>
Message-ID: <2a28d2ab0711120519p17f6178cm55901b99db0630e6@mail.gmail.com>

On Nov 12, 2007 6:30 AM, Jesse Keating <jkeating at redhat.com> wrote:
> On Sun, 11 Nov 2007 12:26:30 -0500
> "Dr. Diesel" <dr.diesel at gmail.com> wrote:
>
> > The video is very slow and choppy.  Totem movie player has no problem
> > with it.  Xine plays about 5 seconds, pauses for a second then
> > continues.
> >
> > Any thoughts?
>
> Are you using compiz?
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>

No compiz.



From etheban at yahoo.it  Mon Nov 12 13:22:04 2007
From: etheban at yahoo.it (Etheban)
Date: Mon, 12 Nov 2007 14:22:04 +0100
Subject: PCMCIA Card
Message-ID: <4738537C.2060800@yahoo.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do you have any idea how to fix the problem with the creative ZX
PCMCIA card?
(see Bug 326411 Processed: Freeze On Boot w/ Audigy PCMCIA
https://bugzilla.redhat.com/show_bug.cgi?id=326411)

With the PCMCIA Audigy 2 ZS card plugged in during startup the
computer simply freezes when reaching the UDEV startup.
The lastest working kernel version was the kernel 2.6.22.1-41.fc7. All
the kernels 2.6.23 do not work (neither on F7)
Thanks

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHOFN8oG9ksF+L4DkRAsFOAKCsjTHJdcdLIup4VafWMLRBLYF8lQCdH7d7
YUnVTyYm/Eqlz+O7+ivW/uU=
=DcDg
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/04e19675/attachment.htm>

From guhvies at gmail.com  Mon Nov 12 13:26:42 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 13:26:42 +0000
Subject: probs with nvidia sata
In-Reply-To: <47384352.3030801@iinet.net.au>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
	<47384352.3030801@iinet.net.au>
Message-ID: <a227b70c0711120526m5af432a0pfca81d07c9c40c97@mail.gmail.com>

On 12/11/2007, David Timms <dtimms at iinet.net.au> wrote:

> Does a DVD install proceed ?
Don't have any dvds lying around to burn )-:

>
> I've noticed that you need to put the iso on a non-lvm disk to do an
> method=hd install/upgrade. If I don't, I get similar sort of message
> {give me your driver disk}.
Not using LVM or even RAID.

>
> Any way, just some thoughts, I'm keen for issues to have solutions - and
> if the solution can't make it back into the installer - then at least
> being able to notate the smolt page with hardware bits that aren't / no
> longer work is helpful for others with the same hw.
>
> Capturing the error even on camera, or typing it in, or using a serial
> console to another PC, could be illuminating for those who know what to
> look for.
This will have to wait till I get home tonight. Thanks for the pointers tho.

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From johannbg at hi.is  Mon Nov 12 13:30:46 2007
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Mon, 12 Nov 2007 13:30:46 +0000
Subject: probs with nvidia sata
In-Reply-To: <4738501F.4070103@hi.is>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>	<47384352.3030801@iinet.net.au>
	<4738501F.4070103@hi.is>
Message-ID: <47385586.9030501@hi.is>

J?hann B. Gu?mundsson wrote:
> David Timms wrote:
>> ne... wrote:
>>> On 12/11/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>>>> Le Lun 12 novembre 2007 11:29, ne... a ?crit :
>>>>
>>>>>> Provide us with double error or some such output...
>>>>>> And some HW info and take a look at
>>>>> AMD X2 4400+ Gigabyte GA-K8NS Ultra-939 mobo, 2x 80GB & 1x 200GB
>>>>> Western Digital hard drives.
>>>> I can't speak for the install part since I use a rolling rawhide setup
>>>> but this hardware should work fine once installed (I have a AMD X2
>>>> 4400+ + Gigabyte GA-K8N Ultra-9 mobo, maxtor drives)
>>> My thoughts exactly till I got the double free error. This box also has
>>> FC7, FC6, FC5, FC4 & FC3 installs on it. Plus openSUSE 10.1 & CentOS 5.
>>> Never had any problems before yesterday. My hard drives are all SATA 
>>> tho...
>> Does a DVD install proceed ?
>>
>> I've noticed that you need to put the iso on a non-lvm disk to do an 
>> method=hd install/upgrade. If I don't, I get similar sort of message 
>> {give me your driver disk}.
>>
>> Any way, just some thoughts, I'm keen for issues to have solutions - 
>> and if the solution can't make it back into the installer - then at 
>> least being able to notate the smolt page with hardware bits that 
>> aren't / no longer work is helpful for others with the same hw.
>>
>> Capturing the error even on camera, or typing it in, or using a 
>> serial console to another PC, could be illuminating for those who 
>> know what to look for.
>>
>> DaveT.
>>
> Could this be primary partition problem, as in exceeding number of 
> primary partitions MBR can handle ( 4 ) per disk?
> Does any one know of any limitation regarding this ( 
> Anaconda/grub/driver(s) )
>
Forgot to add BIOS ( limitation ) as well to the list above
> We are talking about
>
> Disk 1 FC3,FC4,FC5,FC6 MBR Full
>
> Disk 2 FC7,FC8, OpenSUSE 10.1, CentOS 5 MBR Full
>
> How are you partitioning the disks?
>
> What types of disk do you have
> Which disk is it failing on, the 200GB or the 80GB ones
> Is the installation path on the same disk as the one your trying to 
> install it on?
> Does DVD install or NFS/FTP/HTTP/PXE ( Network ) install work?
>
> Best regards
>            Johann B.
>
Best regards
             Johann B.



From mschmidt at redhat.com  Mon Nov 12 13:33:10 2007
From: mschmidt at redhat.com (Michal Schmidt)
Date: Mon, 12 Nov 2007 14:33:10 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
Message-ID: <20071112143310.0be8d92d@brian.englab.brq.redhat.com>

On Sun, 11 Nov 2007 12:26:30 -0500
"Dr. Diesel" <dr.diesel at gmail.com> wrote:

> This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> relevent.
> ...
> AUDIO: 8000 Hz, 1 ch, u8, 64.0 kbit/100.00% (ratio: 8000->8000)

I remember having a problem playing a 8 kHz sampled
sound via PulseAudio.

Try commenting out the line which includes pulse-default.conf
in /etc/alsa/alsa.conf.

Michal



From guhvies at gmail.com  Mon Nov 12 13:38:15 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 13:38:15 +0000
Subject: probs with nvidia sata
In-Reply-To: <4738501F.4070103@hi.is>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
	<47384352.3030801@iinet.net.au> <4738501F.4070103@hi.is>
Message-ID: <a227b70c0711120538i189dc114lada773aaeba5e943@mail.gmail.com>

On 12/11/2007, "J?hann B. Gu?mundsson" <johannbg at hi.is> wrote:
> Could this be primary partition problem, as in exceeding number of
> primary partitions MBR can handle ( 4 ) per disk?
Not in my case.

> Does any one know of any limitation regarding this (
> Anaconda/grub/driver(s) )
>
> We are talking about
>
> Disk 1 FC3,FC4,FC5,FC6 MBR Full
>
> Disk 2 FC7,FC8, OpenSUSE 10.1, CentOS 5 MBR Full
>
> How are you partitioning the disks?
Standard four primary partitions with one of the four as extended. I
do not need to add another logical partition. I intend replacing my
FC4 install with FC8.

> What types of disk do you have
All are Western Digital SATA.

> Which disk is it failing on, the 200GB or the 80GB ones
It is not the disks that are failing. It is selecting the proper SATA driver.
In my case, both sata_sil and sata_nv fail with a double free error.

> Is the installation path on the same disk as the one your trying to
> install it on?
I never get to that stage. Besides, this has never been a problem in the past.
I always do hard drive installs when installing FC. I am still at the
ncurses stage before X starts.

> Does DVD install or NFS/FTP/HTTP/PXE ( Network ) install work?
The one machine holds all the drives so NFS/FTP/HTTP/PXE do not come into play.

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From mclasen at redhat.com  Mon Nov 12 13:51:21 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 12 Nov 2007 08:51:21 -0500
Subject: openssl097a package retirement
In-Reply-To: <3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
Message-ID: <1194875481.2894.2.camel@localhost.localdomain>


On Mon, 2007-11-12 at 16:14 +0530, Debarshi 'Rishi' Ray wrote:
> [Continuing from the fedora-maintainers list.]
> 
> On 22/08/2007, Tomas Mraz <tmraz at redhat.com> wrote:
> > If there will not be any serious objections I'll retire openssl097a
> > package in rawhide.
> >
> > It doesn't make much sense to maintain this old version of openssl in
> > Fedora.
> 
> I am packaging httrack, which has the following snippet:
> 
>       /* We are compatible with 0.9.6/7/8 and potentially above */
>       handle = dlopen("libssl.so.0.9.8", RTLD_LAZY);
>       if (handle == NULL) {
>         handle = dlopen("libssl.so.0.9.7", RTLD_LAZY);
>       }
>       if (handle == NULL) {
>         handle = dlopen("libssl.so.0.9.6", RTLD_LAZY);
>       }
>       if (handle == NULL) {
>         /* Try harder */
>         handle = dlopen("libssl.so", RTLD_LAZY);
>       }
>       if (handle == NULL) {
>         /* Try harder */
>         handle = dlopen("libssl.so.0", RTLD_LAZY);
> 
> Are libssl.so.0.9.8 and libssl.so.9.8b compatible? Can I patch the
> source to use libssl.so.9.8b?

Is there any reason not to patch the source to simply link against
libssl instead ?





From robert at marcanoonline.com  Mon Nov 12 14:07:48 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 12 Nov 2007 10:07:48 -0400
Subject: Build system using fc9 tag for Fedora 8 builds
Message-ID: <1194876468.3112.3.camel@localhost.localdomain>

just look at this, fc9 is the "dist" being used on a build for the F8
branch. This just break this line on my spec file

%if 0%{?fedora} == 8


236636 build (dist-f8-updates-candidate,
F-8:eclipse-subclipse-1_2_4-3_fc8): free -> open
(ppc2.fedora.redhat.com)
  236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): free
  236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): free ->
open (ppc4.fedora.phx.redhat.com)
  236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): open
(ppc4.fedora.phx.redhat.com) -> closed
  0 free  1 open  1 done  0 failed
  236644 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, i386): free
  236642 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc): free
  236645 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc64): free
  236643 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, x86_64): open
(xenbuilder4.fedora.phx.redhat.com)
  236642 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc): free ->
open (ppc3.fedora.redhat.com)
  236644 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, i386): free -> open (xenbuilder1.fedora.redhat.com)




From caillon at redhat.com  Mon Nov 12 14:12:43 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 12 Nov 2007 15:12:43 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071108094720.1a18ded1@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
Message-ID: <47385F5B.50401@redhat.com>

Jesse Keating wrote:
> Have you ever found yourself needing to do any of those things within
> the context of our Package VCS?

I personally, as a packager, do not care whether we stay with CVS or 
move to another "more better" system.  My packaging work flow for the 
most part is satisifed with CVS.  But also keep in mind that much of the 
current package workflow has been defined by the limitations of CVS. 
Our current faux-branching scheme was in part done because of CVS, for 
example.

All that aside, I do strongly believe that Fedora is supposed to be the 
"leading edge" distribution.  And this distinction goes beyond what 
users see into what the behind-the-scenes people see.  At least it 
should, in my opinion.  Fedora has been doing a great job in positioning 
itself to be leading the pack in terms of the tools we use, such as with 
koji, bodhi, and smolt.  They are best in class, I'd say.

Then, there's CVS.  Even if we can't agree on whether to switch to git 
vs hg vs svn vs bzr, we can all agree that CVS... well, sucks.  Not so 
leading edge.

Does this matter?  Maybe, maybe not.  Maybe the people who are looking 
for an excuse to not contribute to Fedora can use CVS as a reason for 
now.  Maybe they'd find some other reason if we moved away from CVS. 
But maybe there are people who are looking for the bleeding edge distro 
to contribute to.  CVS might be the thing that shuns them away from 
Fedora.  Maybe other distros start marketing themselves as more bleeding 
edge than Fedora because they use a VCS not from the dark ages, and 
maybe they eventually move to better tools comparable to ours.

Returning to your original question, which I'll paraphrase as "what do 
we gain by moving away from CVS?"  Not much.  A small number of users 
will take advantage of the features that the new VCS gives them.

But if we ask "what do we lose by not moving away from CVS?" then I 
think the answer is that we lose the ability to claim we are leading 
edge, and we may potentially lose more than that in the long run.

The cries might not be loud right now.  But they will get louder over 
time as CVS usage becomes more equated with the Flintstones.  And I 
believe that at some point, it can be a deciding criterion in which 
distribution people will contribute their spare time on.  People can be 
religiously petty that way, for better or for worse.



From debarshi.ray at gmail.com  Mon Nov 12 14:13:38 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 12 Nov 2007 19:43:38 +0530
Subject: openssl097a package retirement
In-Reply-To: <1194875481.2894.2.camel@localhost.localdomain>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
Message-ID: <3170f42f0711120613h35438aew2cdfeffb5e232e6f@mail.gmail.com>

> Is there any reason not to patch the source to simply link against
> libssl instead ?

If this is not compatible with libssl.so.9.8b, then would that make a
difference?

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From valent.turkovic at gmail.com  Mon Nov 12 14:13:48 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 12 Nov 2007 15:13:48 +0100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <47383B7F.5020209@iinet.net.au>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<64b14b300711120056q4daaab33pb53854ef9b976bdf@mail.gmail.com>
	<47383B7F.5020209@iinet.net.au>
Message-ID: <64b14b300711120613w7bf6b512r4dfd13cdb3dea3b0@mail.gmail.com>

On 11/12/07, David Timms <dtimms at iinet.net.au> wrote:
> Valent Turkovic wrote:
> > On 11/12/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> >> Hi,
> >>
> >> I have 2 laptops and I used the smoltSendProfile and I seem to get the
> >> same url for both laptops, ie. the later sent profile overwrites the
> >> previous one...
> >>
> >> I'm sending both profiles from same adsl line and I'm behing a NAT
> >> adsl router, so could this be an issue (same IP) ?
> >>
> >> Is this a feature or a bug?
> >>
> >> How can I send multiple laptop profiles and see them all online?
> >>
> >> Thank you very much in advance,
> >> Valent.
> >>
> >
> > This is the profile:
> > http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
> Hey Valent,
>
> I noticed that myself when I first looked at your distorted audio entry
> in bugzilla - I saw a machine with vmware graphics and vmware {amd}
> pcnet card.
> I was about to say that doesn't make sense in the bug, so I decided to
> copy an paste the uuid from the bugzilla again. I then found that it was
> showing the HP machine that matched what you had attached in the bug.
>
> 1. Did you send an entry for a vmware machine at all ?
> - if not then the "universally unique" ids might be gettting screwed and
> the smolt folks need to know quick smart.

I installed Fedora 8 on three different laptops, all F8 run on real
hardware not in VMWare or other VM solutions...

> 2. Did you copy your data between new and old machines {or vms}, perhaps
> copying the storage of the smolt UUID ?

Nope. All clean installs with new and unique usernames on that /home
partition but I think that all usernames are the same on all three
laptops, but unique to previous usernames that existed for fedora 7
with which I share /home folder.

>
> 3. {smolt devs} Perhaps the web interface is having problems - eg the
> data is correctly sent and stored, but we are actually getting a
> different record's entry sometimes when we query the smolt data ?
>
> DaveT.
>

I'll be glad to give you more feedback just jell what you need :)

Regards,
Valent.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From michael.wiktowy at gmail.com  Mon Nov 12 14:16:21 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Mon, 12 Nov 2007 09:16:21 -0500
Subject: SELinux Troubleshooter messages from upgrade from F7->F8
In-Reply-To: <4738491D.1040903@warmcat.com>
References: <3e4ec4600711101123n3ca28c9va454a2566f089bb8@mail.gmail.com>
	<3e4ec4600711120353x6025c92fx462c2ffc8107f0b7@mail.gmail.com>
	<4738491D.1040903@warmcat.com>
Message-ID: <3e4ec4600711120616g4e38805dw99b65718184bd38c@mail.gmail.com>

On Nov 12, 2007 7:37 AM, Andy Green <andy at warmcat.com> wrote:
> Somebody in the thread at some point said:
> > Nov  9 02:39:19 localhost setroubleshoot:      SELinux is preventing
> > /sbin/ldconfig (ldconfig_t) "write" to ldconfig (var_t).      For
> > complete SELinux messages. run sealert -l
> > 1594b6a8-1f16-44c9-b7ee-f5ef4621257f
>
> I think this is a mislabelled /var/cache/ldconfig.  Check if yours is
> like this
>
> # ll /var/cache/ldconfig -Zd
> drwx------  root root system_u:object_r:ldconfig_cache_t /var/cache/ldconfig
>

It matches this ... now ... I did not check right after the upgrade
though. The selinux-policy package have been updated since then so it
is possible that this could have been corrected already.

...

> > Nov  9 03:09:42 localhost setroubleshoot: [rpc.ERROR] exception
> > DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect
> > to socket /var/run/dbus/system_bus_socket: Connection refused
>
> Is dbus running?
>
> service messagebus status

dbus is running. I suspect that it had issues coming back up after
getting updated as there were a lot of system_bus_socket: Connection
refused messages scattered throughout the upgrade and they started
shortly after dbus was updated. Now my /var/log/messages is pretty
quiet so I think dbus is happy after the post-upgrade reboot.

Thank you for your comments.

/Mike



From katzj at redhat.com  Mon Nov 12 13:45:07 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 12 Nov 2007 08:45:07 -0500
Subject: rawhide report: 20071109 changes
In-Reply-To: <47355AA9.6030203@mindspring.com>
References: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>
	<20071109134826.334610c7@redhat.com> <47355AA9.6030203@mindspring.com>
Message-ID: <1194875107.17950.2.camel@localhost.localdomain>

On Sat, 2007-11-10 at 02:15 -0500, Richard Hally wrote:
> On a fresh install of F8 (default install minus the "office and productivity" 
> stuff) switching to the development repo and updating ~150 packages, I get a 
> problem going to runlevel 5 (something about "x" respawning too fast) and no 
> login screen. Runlevel 3 login and startx works.
> 
> replacing the gdm package that was in the update with the previously installed 
> gdm fixed the problem.

gdm is under (very) heavy development, although it does work at least in
some cases.  Providing a log of the failure in bugzilla is your best bet

Jeremy



From katzj at redhat.com  Mon Nov 12 13:46:06 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 12 Nov 2007 08:46:06 -0500
Subject: java-plugin not working in F8
In-Reply-To: <64b14b300711120117u31d8f149t32b70b7ec404b123@mail.gmail.com>
References: <64b14b300711090244w21eecae1r6f8ee65b5adde14f@mail.gmail.com>
	<1194607695.4630.1.camel@scrappy.miketc.com>
	<47344B46.6070604@mharris.ca>
	<64b14b300711120117u31d8f149t32b70b7ec404b123@mail.gmail.com>
Message-ID: <1194875166.17950.4.camel@localhost.localdomain>

On Mon, 2007-11-12 at 10:17 +0100, Valent Turkovic wrote:
> Just an update; I installed a fresh Fedora 8 from Gnome Live CD and by
> default java doesn't work.

We don't include the java bits on the live images.  Doing so would push
the x86 image over the CD size boundary without finding something else
(that's relatively large) to drop

Jeremy



From katzj at redhat.com  Mon Nov 12 14:02:26 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 12 Nov 2007 09:02:26 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071110103147.0a0812d5@vader.jdub.homelinux.org>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
	<20071110103147.0a0812d5@vader.jdub.homelinux.org>
Message-ID: <1194876146.17950.11.camel@localhost.localdomain>

On Sat, 2007-11-10 at 10:31 -0600, Josh Boyer wrote:
> I think it's because you have two classes of users.  Developers, and
> packagers.

I think you hit the nail _exactly_ on the head here.  We continue to
have this discussion moving around in circles but when you step back a
little bit, this starts to be more clear.

So the next question I'd end up having is how do we think about what
we're trying to enable such that we continue to make things "easy" for
the packagers while also allowing more complicated interactions for the
developer case.  

The current best I've got (which isn't really fleshed out at all, but
maybe someone with less on their plate than me is interested? :) is that
we really want to have "the central repository of spec files + patches"
like we do now[1] but that we then also want an easy way to get from
that to something more developer friendly.  I suspect that the more
developer friendly format is probably more like exploded trees with
patch series on top so that you can easily import new sources, rediff,
etc.  And then from that repo, you can have a script to get back to the
spec file + patches on top of the pristine source.

Jeremy

[1] And maybe there are convincing reasons to move that off of CVS, but
I think that we need to have a better idea of the full picture before we
can say that definitively.  And I say that as a now-relatively-rabid
"git for the win" user :-)



From katzj at redhat.com  Mon Nov 12 14:07:02 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 12 Nov 2007 09:07:02 -0500
Subject: chain build in F-8
In-Reply-To: <47381E20.2010506@poolshark.org>
References: <20071112060414.GA4257@lisas.de>
	<1194854028.19003.2.camel@tuxhugs>  <47381E20.2010506@poolshark.org>
Message-ID: <1194876422.17950.14.camel@localhost.localdomain>

On Mon, 2007-11-12 at 01:34 -0800, Denis Leroy wrote:
> I hit the same problem all the time with the gtkmm updates, which are 3 
> to 4-deep dependency chains. How could we automate this ? Having to mail 
> rel-eng for this seems particularly inefficient, and it's also a 
> regression from the plague/FC-6 days...

The plan iirc was that we get some tracking in bodhi to ensure that
people don't try to push a stable update which was built against
something which hasn't been pushed stable.  Unfortunately, the number of
people helping Luke out with things like in bodhi is not that large. :-/

Jeremy



From paul at all-the-johnsons.co.uk  Mon Nov 12 14:23:54 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Mon, 12 Nov 2007 14:23:54 +0000
Subject: mono-devel on ppc and ppc64
Message-ID: <1194877434.8099.6.camel@T7.Linux>

Hi,

I've submitted nant to koji and it fails on ppc and ppc64 when it looks
for mono-devel in mock, but not on x86 or x86_64. Is there a hiccup
somewhere or is it a problem with mock on koji not finding ppc and ppc64
for mono-devel?

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/ff8aa83b/attachment.sig>

From jkeating at redhat.com  Mon Nov 12 14:23:00 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 09:23:00 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <47385F5B.50401@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
Message-ID: <20071112092300.796fdf4c@redhat.com>

On Mon, 12 Nov 2007 15:12:43 +0100
Christopher Aillon <caillon at redhat.com> wrote:

> I personally, as a packager, do not care whether we stay with CVS or 
> move to another "more better" system.  My packaging work flow for the 
> most part is satisifed with CVS.  But also keep in mind that much of
> the current package workflow has been defined by the limitations of
> CVS. Our current faux-branching scheme was in part done because of
> CVS, for example.

I don't disagree at all, and I completely agree with the rest of your
message, which is why I'm so interested in what kind of new and amazing
workflow we might be able to find with a new VCS.  The same workflow
with a different VCS might gain you a few little nice things here and
there, not used by most people.  But if we can create a more compelling
workflow with better tools, then that's really something to talk about.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/4dce984a/attachment.sig>

From robert at marcanoonline.com  Mon Nov 12 14:25:57 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 12 Nov 2007 10:25:57 -0400
Subject: Build system using fc9 tag for Fedora 8 builds
In-Reply-To: <1194876468.3112.3.camel@localhost.localdomain>
References: <1194876468.3112.3.camel@localhost.localdomain>
Message-ID: <1194877557.3112.10.camel@localhost.localdomain>

On Mon, 2007-11-12 at 10:07 -0400, Robert Marcano wrote:
> just look at this, fc9 is the "dist" being used on a build for the F8
> branch. This just break this line on my spec file
> 
> %if 0%{?fedora} == 8
> 

something was wrong with the branching to F-8, a new higher release tag
solved the problem

> 
> 236636 build (dist-f8-updates-candidate,
> F-8:eclipse-subclipse-1_2_4-3_fc8): free -> open
> (ppc2.fedora.redhat.com)
>   236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): free
>   236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): free ->
> open (ppc4.fedora.phx.redhat.com)
>   236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): open
> (ppc4.fedora.phx.redhat.com) -> closed
>   0 free  1 open  1 done  0 failed
>   236644 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, i386): free
>   236642 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc): free
>   236645 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc64): free
>   236643 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, x86_64): open
> (xenbuilder4.fedora.phx.redhat.com)
>   236642 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc): free ->
> open (ppc3.fedora.redhat.com)
>   236644 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, i386): free -> open (xenbuilder1.fedora.redhat.com)
> 
> 



From robert at marcanoonline.com  Mon Nov 12 14:28:35 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 12 Nov 2007 10:28:35 -0400
Subject: build servers kernel release (PPC64)
Message-ID: <1194877715.3112.11.camel@localhost.localdomain>

are the build systems servers running the latest F8 kernel? I need the
fix of bug 350291 in order to be able to build eclipse-subclipse on
ppc64 machines. I am asking because the error still happens and I am not
sure if the fix did not work or the server have an outdated kernel?

Any help is appreciated



From mcepl at redhat.com  Mon Nov 12 14:25:32 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 12 Nov 2007 15:25:32 +0100
Subject: When will CVS be replaced by modern version control system?
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
Message-ID: <sb4m05xsto.ln2@hubmaier.ceplovi.cz>

On Mon, 12 Nov 2007 15:12:43 +0100, Christopher Aillon scripst:
> But also keep in mind that much of the current package workflow has
> been defined by the limitations of CVS. Our current faux-branching
> scheme was in part done because of CVS, for example.
> [...]
> Returning to your original question, which I'll paraphrase as "what do
> we gain by moving away from CVS?"  Not much.  A small number of users
> will take advantage of the features that the new VCS gives them.

I think the thing we need to loose is the box where we keep our work-
flow. So for example, could somebody explain why in the time or DVCSs we 
still have tarball-based packaging?

Mat?j



From jonathan.underwood at gmail.com  Mon Nov 12 14:32:02 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 12 Nov 2007 14:32:02 +0000
Subject: Build system using fc9 tag for Fedora 8 builds
In-Reply-To: <1194876468.3112.3.camel@localhost.localdomain>
References: <1194876468.3112.3.camel@localhost.localdomain>
Message-ID: <645d17210711120632x1ef9cefbpf49e2f4f132d6820@mail.gmail.com>

On 12/11/2007, Robert Marcano <robert at marcanoonline.com> wrote:
> just look at this, fc9 is the "dist" being used on a build for the F8
> branch. This just break this line on my spec file
>
> %if 0%{?fedora} == 8
>
>
> 236636 build (dist-f8-updates-candidate,
> F-8:eclipse-subclipse-1_2_4-3_fc8): free -> open
> (ppc2.fedora.redhat.com)
>   236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): free
>   236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): free ->
> open (ppc4.fedora.phx.redhat.com)
>   236638 buildSRPMFromCVS (F-8:eclipse-subclipse-1_2_4-3_fc8): open
> (ppc4.fedora.phx.redhat.com) -> closed
>   0 free  1 open  1 done  0 failed
>   236644 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, i386): free
>   236642 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc): free
>   236645 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc64): free
>   236643 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, x86_64): open
> (xenbuilder4.fedora.phx.redhat.com)
>   236642 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, ppc): free ->
> open (ppc3.fedora.redhat.com)
>   236644 buildArch (eclipse-subclipse-1.2.4-3.fc9.src.rpm, i386): free -> open (xenbuilder1.fedora.redhat.com)

I ran into this yesterday, and Jesse straightened me out - you need to
do a "cvs up-d"



From jwboyer at gmail.com  Mon Nov 12 14:35:42 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 12 Nov 2007 08:35:42 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <sb4m05xsto.ln2@hubmaier.ceplovi.cz>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071112083542.6be464e3@vader.jdub.homelinux.org>

On Mon, 12 Nov 2007 15:25:32 +0100
Matej Cepl <mcepl at redhat.com> wrote:

> On Mon, 12 Nov 2007 15:12:43 +0100, Christopher Aillon scripst:
> > But also keep in mind that much of the current package workflow has
> > been defined by the limitations of CVS. Our current faux-branching
> > scheme was in part done because of CVS, for example.
> > [...]
> > Returning to your original question, which I'll paraphrase as "what do
> > we gain by moving away from CVS?"  Not much.  A small number of users
> > will take advantage of the features that the new VCS gives them.
> 
> I think the thing we need to loose is the box where we keep our work-
> flow. So for example, could somebody explain why in the time or DVCSs we 
> still have tarball-based packaging?

So you can verify that you're using the upstream source as it was
released, and not some custom fork of the code base.

josh



From tcallawa at redhat.com  Mon Nov 12 14:36:00 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 12 Nov 2007 09:36:00 -0500
Subject: License review for new itext version
In-Reply-To: <645d17210711111538u4b896ec8qc9ca63b466e8976d@mail.gmail.com>
References: <46BF752E.4030500@herr-schmitt.de>
	<200710220029.30090@rineau.tsetse> <471C4CF3.7030200@hhs.nl>
	<200710231442.l9NEg36W007752@quelen.inf.utfsm.cl>
	<471DFA82.4050708@fedoraproject.org>
	<645d17210711111517l3203617dt7de87d0a976c57e2@mail.gmail.com>
	<645d17210711111523q32e2505fp9dbb5021ac44f599@mail.gmail.com>
	<645d17210711111538u4b896ec8qc9ca63b466e8976d@mail.gmail.com>
Message-ID: <1194878160.3198.0.camel@localhost.localdomain>


On Sun, 2007-11-11 at 23:38 +0000, Jonathan Underwood wrote:
> On 11/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> > On 11/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> > > What are the other of the "several" issues with the license? Could the
> > > ex-package maintainer offer a bit more explanation?
> > >
> >
> > Aha, a bit of digging leads to:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=236309
> >
> > which details the problems with itext licensing (on which pdftk
> > depends). I guess the nuclear use is a small issue compared to the
> > others :(.
> >
> 
> To continue the monologue, it seems itext upstream is now entirely
> licensed as either LGPL 2 or MPL. As such, I can't see a reason it
> can't be reinstated in Fedora.

If someone points me at a new package for itext, I'd be happy to do a
quick audit to confirm that it is OK for Fedora now.

~spot



From caillon at redhat.com  Mon Nov 12 14:38:17 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 12 Nov 2007 15:38:17 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071112083542.6be464e3@vader.jdub.homelinux.org>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>	<20071108094720.1a18ded1@redhat.com>
	<47385F5B.50401@redhat.com>	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
Message-ID: <47386559.6030202@redhat.com>

Josh Boyer wrote:
> On Mon, 12 Nov 2007 15:25:32 +0100
> Matej Cepl <mcepl at redhat.com> wrote:
> 
>> On Mon, 12 Nov 2007 15:12:43 +0100, Christopher Aillon scripst:
>> > But also keep in mind that much of the current package workflow has
>> > been defined by the limitations of CVS. Our current faux-branching
>> > scheme was in part done because of CVS, for example.
>> > [...]
>> > Returning to your original question, which I'll paraphrase as "what do
>> > we gain by moving away from CVS?"  Not much.  A small number of users
>> > will take advantage of the features that the new VCS gives them.
>> 
>> I think the thing we need to loose is the box where we keep our work-
>> flow. So for example, could somebody explain why in the time or DVCSs we 
>> still have tarball-based packaging?
> 
> So you can verify that you're using the upstream source as it was
> released, and not some custom fork of the code base.

I think Matej was implying we should point to the upstream repo and 
tagname instead of a tarball.  Then koji would checkout code from 
upstream without relying on us downloading, then subsequently uploading 
a tarball via make upload.



From jkeating at redhat.com  Mon Nov 12 14:40:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 09:40:37 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <47386559.6030202@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
	<47386559.6030202@redhat.com>
Message-ID: <20071112094037.507a153c@redhat.com>

On Mon, 12 Nov 2007 15:38:17 +0100
Christopher Aillon <caillon at redhat.com> wrote:

> I think Matej was implying we should point to the upstream repo and 
> tagname instead of a tarball.  Then koji would checkout code from 
> upstream without relying on us downloading, then subsequently
> uploading a tarball via make upload.

That might work if every single upstream were using such a mechanism,
and used proper tags in their source control for release (and didn't
just fix a few things in the tarball outside of the scm or scm tag).
It would also mean teaching koji about each and every possible scm, tag
syntax, etc...

Until the entire upstream world stops doing releases as tarballs, I
don't think it's appropriate to change how we consume releases in rpms.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/3de4aae6/attachment.sig>

From caillon at redhat.com  Mon Nov 12 14:41:42 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 12 Nov 2007 15:41:42 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071112092300.796fdf4c@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>	<20071108094720.1a18ded1@redhat.com>
	<47385F5B.50401@redhat.com> <20071112092300.796fdf4c@redhat.com>
Message-ID: <47386626.1020101@redhat.com>

Jesse Keating wrote:
> On Mon, 12 Nov 2007 15:12:43 +0100
> Christopher Aillon <caillon at redhat.com> wrote:
> 
>> I personally, as a packager, do not care whether we stay with CVS or 
>> move to another "more better" system.  My packaging work flow for the 
>> most part is satisifed with CVS.  But also keep in mind that much of
>> the current package workflow has been defined by the limitations of
>> CVS. Our current faux-branching scheme was in part done because of
>> CVS, for example.
> 
> I don't disagree at all, and I completely agree with the rest of your
> message, which is why I'm so interested in what kind of new and amazing
> workflow we might be able to find with a new VCS.  The same workflow
> with a different VCS might gain you a few little nice things here and
> there, not used by most people.  But if we can create a more compelling
> workflow with better tools, then that's really something to talk about.


Then I wonder if this is something our usability people like Bryan want 
to get involved with.  I'm not sure how to best determine the ideal 
workflow.  Doing so on a mailing list is probably the wrong approach, 
though.


PS - Apologies.  I somehow misread your post I replied to as pro-CVS, 
even though common sense should have dictated otherwise.  Shame on me 
for doubting.



From limb at jcomserv.net  Mon Nov 12 14:43:40 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 12 Nov 2007 08:43:40 -0600 (CST)
Subject: LSB init scripts - automatic start
In-Reply-To: <20071109213706.GA2098@nostromo.devel.redhat.com>
References: <200711081730.lA8HUk1G017806@cvs-int.fedora.redhat.com>
	<47349182.50800@cora.nwra.com>
	<28791.63.85.68.164.1194634199.squirrel@mail.jcomserv.net>
	<20071109213706.GA2098@nostromo.devel.redhat.com>
Message-ID: <36716.63.85.68.164.1194878620.squirrel@mail.jcomserv.net>


> Jon Ciesla (limb at jcomserv.net) said:
>> Should I alter Moodle to not start by default?  I assumed this setting
>> would mean that Moodle's service* would start on boot, not install.
>
> Correct, but it's still generally done that services don't start by
> default.

So in the LSB block, I'd want:

# Default-Start:

instead of:

# Default-Start:  2 3 4 5

correct?

> Bill
>


-- 
novus ordo absurdum



From jwboyer at gmail.com  Mon Nov 12 14:43:36 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 12 Nov 2007 08:43:36 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071112073457.41c485a8@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com>
	<1194700048.4580.39.camel@gibraltar.str.redhat.com>
	<1194700238.4580.41.camel@gibraltar.str.redhat.com>
	<20071110104245.6b783490@j2solutions.net>
	<20071110103147.0a0812d5@vader.jdub.homelinux.org>
	<20071112073457.41c485a8@redhat.com>
Message-ID: <20071112084336.11cba3fb@vader.jdub.homelinux.org>

On Mon, 12 Nov 2007 07:34:57 -0500
Jesse Keating <jkeating at redhat.com> wrote:

> On Sat, 10 Nov 2007 10:31:47 -0600
> Josh Boyer <jwboyer at gmail.com> wrote:
> 
> > There are several people that are active developers for the packages
> > they maintain.  They're used to working on the code base itself,
> > developing patches, etc.  RPM specfiles are almost the last step in
> > their day-to-day dealings with a package.  These are the people that
> > are the major proponents of a DVCS.
> > 
> > Then there are the packagers.  They mostly take the upstream tarballs,
> > do the specfile work, and build things.  There isn't a lot of need for
> > multiple commits, offline working, etc.  The entire VCS setup we
> > currently use is geared toward packagers.
> 
> Which is mostly because it's for... packages.  Development should be
> happening upstream or elsewhere.  I think that a lot of it is coming
> from RHEL developers who are stuck with a package version for many
> years and build up a lot of cruft around it in package VCS, yet in
> Fedora we're free to move to newer upstream releases that fix problems
> and such, and thus the build up around our packages should be minimal.

Agreed.

josh



From robert at marcanoonline.com  Mon Nov 12 14:48:38 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Mon, 12 Nov 2007 10:48:38 -0400
Subject: Build system using fc9 tag for Fedora 8 builds
In-Reply-To: <645d17210711120632x1ef9cefbpf49e2f4f132d6820@mail.gmail.com>
References: <1194876468.3112.3.camel@localhost.localdomain>
	<645d17210711120632x1ef9cefbpf49e2f4f132d6820@mail.gmail.com>
Message-ID: <1194878918.3112.14.camel@localhost.localdomain>

On Mon, 2007-11-12 at 14:32 +0000, Jonathan Underwood wrote:
> On 12/11/2007, Robert Marcano <robert at marcanoonline.com> wrote:
> > just look at this, fc9 is the "dist" being used on a build for the F8
> > branch. This just break this line on my spec file
> >
> > %if 0%{?fedora} == 8
> >

...


> >
> I ran into this yesterday, and Jesse straightened me out - you need to
> do a "cvs up-d"
> 

I did that, and a complete cvs checkout before trying the higher release
tag (only the later solved it)



From dominik at greysector.net  Mon Nov 12 14:54:33 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 12 Nov 2007 15:54:33 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <20071112143310.0be8d92d@brian.englab.brq.redhat.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112143310.0be8d92d@brian.englab.brq.redhat.com>
Message-ID: <20071112145433.GC10550@onizuka.greysector.net>

On Monday, 12 November 2007 at 14:33, Michal Schmidt wrote:
> On Sun, 11 Nov 2007 12:26:30 -0500
> "Dr. Diesel" <dr.diesel at gmail.com> wrote:
> 
> > This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> > relevent.
> > ...
> > AUDIO: 8000 Hz, 1 ch, u8, 64.0 kbit/100.00% (ratio: 8000->8000)
> 
> I remember having a problem playing a 8 kHz sampled
> sound via PulseAudio.
> 
> Try commenting out the line which includes pulse-default.conf
> in /etc/alsa/alsa.conf.

And try without pulseaudio, i.e. use alsa or oss directly (-ao alsa)
and make sure pulseaudio is not intercepting alsa calls.

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From laroche at redhat.com  Mon Nov 12 15:05:35 2007
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 12 Nov 2007 16:05:35 +0100
Subject: gitweb performance of summary page
In-Reply-To: <20071111105149.GA9352@dudweiler.stuttgart.redhat.com>
References: <20071102112954.GA7005@dudweiler.stuttgart.redhat.com>
	<20071111105149.GA9352@dudweiler.stuttgart.redhat.com>
Message-ID: <20071112150535.GA15179@dudweiler.stuttgart.redhat.com>

On Sun, Nov 11, 2007 at 11:51:49AM +0100, Florian La Roche wrote:
> On Fri, Nov 02, 2007 at 12:29:54PM +0100, Florian La Roche wrote:
> > Loading the summary page can still take quite some time
> > as this server is also a Fedora mirror, so the overview
> > page often needs to read in all data from disk.
> 
> 
> For the summary page gitweb calls for each project the
> external command:
>     git for-each-ref --format=%(committer) --sort=-committerdate --count=1 refs/heads
> 
> If the data is not already cached, this adds quite some time until
> the overview page is ready. While seeing the time of the last commit
> is pretty nice, it should also not be really essential, so I have
> just removed it for now. The right thing todo would be to cache this
> time somehow intelligently. Even better is to read new patches
> coming in via RSS instead of looking at the summary page.
> 
> 
> > If anyone feels like hacking on gitweb: The main summary
> > page only displays the time of last change as special info
> > on the individual projects, so if that part would not call
> > "git" as external app, then loading that page should be much
> > less of a resource problem.
> 
> 
> Resolved for me, but might wait for an even better patch.


Hello all,

if other people are interested, I've put up the changes I use for
git up to:
http://www.jur-linux.org/git/?p=git-laroche.git;a=summary

That's a few changes from Petr Baudis that are used also for
repo.or.cz and the mostly "delete owner/date for summary page"
patch from above.

regards,

Florian La Roche



From michel.sylvan at gmail.com  Mon Nov 12 15:06:41 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Mon, 12 Nov 2007 10:06:41 -0500
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <20071112145433.GC10550@onizuka.greysector.net>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112143310.0be8d92d@brian.englab.brq.redhat.com>
	<20071112145433.GC10550@onizuka.greysector.net>
Message-ID: <f224c6140711120706x640d0ba7oc5411942860e2f8e@mail.gmail.com>

On 12/11/2007, Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
> On Monday, 12 November 2007 at 14:33, Michal Schmidt wrote:
> > On Sun, 11 Nov 2007 12:26:30 -0500
> > "Dr. Diesel" <dr.diesel at gmail.com> wrote:
> >
> > > This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> > > relevent.
> > > ...
> > > AUDIO: 8000 Hz, 1 ch, u8, 64.0 kbit/100.00% (ratio: 8000->8000)
> >
> > I remember having a problem playing a 8 kHz sampled
> > sound via PulseAudio.
> >
> > Try commenting out the line which includes pulse-default.conf
> > in /etc/alsa/alsa.conf.
>
> And try without pulseaudio, i.e. use alsa or oss directly (-ao alsa)
> and make sure pulseaudio is not intercepting alsa calls.
>
If playback with OSS works fine, try running it under pulseaudio (wrap
it with padsp) and see if you get any slowdown. From my experience
with Real Player, some apps work fine under PulseAudio's OSS emulation
but cannot handle ALSA routed through PA.

-- 
Michel



From jkeating at redhat.com  Mon Nov 12 15:08:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 10:08:53 -0500
Subject: Topics for today's release engineering meeting
Message-ID: <20071112100853.561654f6@redhat.com>

http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/Agenda

Meeting info:
http://fedoraproject.org/wiki/ReleaseEngineering#head-cf6f2bdf4de1312a3a403d788e59007da14d5a79

/topic Fedora Release Engineering - Trac tickets for Fedora 9
  Discussion about our new Trac space, how the tickets should be
handled, what needs to be added, etc...

/topic Fedora Release Engineering - New development process
  Discussion about the approved new development cycle and what it will
mean for releng.

/topic Fedora Release Engineering - Goals for this development cycle
  What do we want to get done over the next few months?

/topic Fedora Release Engineering - Open Discussion

If you wish to suggest a topic for discussion, or want to show up to
talk about something, please reply to this mail with the info and I'll
add it to the agenda.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/4f30b8eb/attachment.sig>

From michel.sylvan at gmail.com  Mon Nov 12 15:13:05 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Mon, 12 Nov 2007 10:13:05 -0500
Subject: Build system using fc9 tag for Fedora 8 builds
In-Reply-To: <1194878918.3112.14.camel@localhost.localdomain>
References: <1194876468.3112.3.camel@localhost.localdomain>
	<645d17210711120632x1ef9cefbpf49e2f4f132d6820@mail.gmail.com>
	<1194878918.3112.14.camel@localhost.localdomain>
Message-ID: <f224c6140711120713x612b734dy86283f57f0bef64f@mail.gmail.com>

On 12/11/2007, Robert Marcano <robert at marcanoonline.com> wrote:
> On Mon, 2007-11-12 at 14:32 +0000, Jonathan Underwood wrote:
> > On 12/11/2007, Robert Marcano <robert at marcanoonline.com> wrote:
> > > just look at this, fc9 is the "dist" being used on a build for the F8
> > > branch. This just break this line on my spec file
> > >
> > > %if 0%{?fedora} == 8
> > >
>
> ...
>
>
> > >
> > I ran into this yesterday, and Jesse straightened me out - you need to
> > do a "cvs up-d"
> >
>
> I did that, and a complete cvs checkout before trying the higher release
> tag (only the later solved it)
>
Had a similar problem -- if the package was tagged when devel was FC8,
during the build Koji will build it as F9 (the current devel disttag).
And you cannot re-tag the F8 tree even with TAG_OPTS=-F because CVS
won't let you override across branches.

Found out belatedly, though, that koji has an option to move the
target to a different 'tag' (confusing terminology mix-up there):

        move-pkg             'Move' one or more packages between tags

Regards,

-- 
Michel Salim



From nphilipp at redhat.com  Mon Nov 12 15:16:18 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 12 Nov 2007 16:16:18 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071112094037.507a153c@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
	<47386559.6030202@redhat.com>  <20071112094037.507a153c@redhat.com>
Message-ID: <1194880579.8432.69.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-12 at 09:40 -0500, Jesse Keating wrote:
> On Mon, 12 Nov 2007 15:38:17 +0100
> Christopher Aillon <caillon at redhat.com> wrote:
> 
> > I think Matej was implying we should point to the upstream repo and 
> > tagname instead of a tarball.  Then koji would checkout code from 
> > upstream without relying on us downloading, then subsequently
> > uploading a tarball via make upload.
> 
> That might work if every single upstream were using such a mechanism,
> and used proper tags in their source control for release (and didn't
> just fix a few things in the tarball outside of the scm or scm tag).
> It would also mean teaching koji about each and every possible scm, tag
> syntax, etc...
> 
> Until the entire upstream world stops doing releases as tarballs, I
> don't think it's appropriate to change how we consume releases in rpms.

Let me hazard a guess: There will be situations where we simply don't
get by with the upstream state of things for quite a time. Are there
statistics how many Fedora packages don't patch upstream vs. the number
that do it? That'd be interesting.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From tcallawa at redhat.com  Mon Nov 12 14:51:34 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 12 Nov 2007 09:51:34 -0500
Subject: Packaging Starplot and related data files
In-Reply-To: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
Message-ID: <1194879094.3198.9.camel@localhost.localdomain>


On Mon, 2007-11-12 at 11:43 +0530, Debarshi 'Rishi' Ray wrote:
> I am packaging Starplot (http://starplot.org/) for Fedora and would
> like to discuss some license related issues.
> 
> The main Starplot program that gets built from
> http://starplot.org/downloads/starplot-0.95.4.tar.gz is licensed under
> GPLv2+. However, the Starplot data files distributed as
> datahttp://starplot.org/data/gliese3-0.95.tar.gz and
> http://starplot.org/data/yale5-0.95.tar.gz seem to be under a
> "Redistributable, no modification permitted" license.

<long explanation snipped>

This meets the "Binary Firmware" criteria:
http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware

* The files are non-executable
  * The files are not libraries. 
  * The files are standalone, not embedded in executable or library
    code. 
  * Explicit permission is given by the owner to freely redistribute
    without restrictions (this permission must be included, in
    "writing", with the files in the packaging) 
  * The files must be necessary for the functionality of open source
    code being included in Fedora.

Like you said, the modified .star files can't be distributed, but the
ADC data files are fine to package as is, under the "Redistributable, no
modification permitted". 

Can't say I'm very happy about it, but it meets the criteria. I would
much rather see them work up something similar to the license we
negotiated with the EPSG for their dataset:

http://www.epsg.org/CurrentDB.html#use

~spot



From jkeating at redhat.com  Mon Nov 12 15:24:40 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 10:24:40 -0500
Subject: Topics for today's release engineering meeting
In-Reply-To: <20071112100853.561654f6@redhat.com>
References: <20071112100853.561654f6@redhat.com>
Message-ID: <20071112102440.5456d02f@redhat.com>

On Mon, 12 Nov 2007 10:08:53 -0500
Jesse Keating <jkeating at redhat.com> wrote:

> Meeting info:
> http://fedoraproject.org/wiki/ReleaseEngineering#head-cf6f2bdf4de1312a3a403d788e59007da14d5a79

Remember that due to DST in America, this meeting is now an hour
earlier (12:00pm EST).  Something we may discuss changing in the
meeting.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/e3a48655/attachment.sig>

From alexl at redhat.com  Mon Nov 12 15:36:53 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 12 Nov 2007 16:36:53 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <1194881813.12691.21.camel@dhcp-208-188.arn.redhat.com>


On Mon, 2007-11-12 at 13:35 +0100, Alexander Larsson wrote:
> > Would be nice if a user tried to open a file that didn't have an
> > application associated with it and up popped a list of applications
> > that could be installed.  Would be even cooler if the you could select
> > one to install, it installed, then opened it up for you.
> 
> It would be cool if we could autoextract mime handling information from
> desktop files installed in /usr/share/applications and generate
> "mime(application/pdf)" style rpm provides.

If we did this then we could have the nautilus "open with other
application" dialog use yum to query for other apps that can open the
file type. In combination with PackageKit to (optionally) let users
install packages this could be pretty sweet!




From fedora at camperquake.de  Mon Nov 12 15:40:46 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 16:40:46 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <20071112164046.6e64ed0b@dhcp03.addix.net>

Hi.

On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:

> It would be cool if we could autoextract mime handling information
> from desktop files installed in /usr/share/applications and generate
> "mime(application/pdf)" style rpm provides.

YOu know, I like that idea. A lot.



From andrewparker at bigfoot.com  Mon Nov 12 15:45:01 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Mon, 12 Nov 2007 10:45:01 -0500
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194881813.12691.21.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<1194881813.12691.21.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <6c3f5e6c0711120745q202cb73es5a53907f36586352@mail.gmail.com>

On Nov 12, 2007 10:36 AM, Alexander Larsson <alexl at redhat.com> wrote:
>
> On Mon, 2007-11-12 at 13:35 +0100, Alexander Larsson wrote:
> > > Would be nice if a user tried to open a file that didn't have an
> > > application associated with it and up popped a list of applications
> > > that could be installed.  Would be even cooler if the you could select
> > > one to install, it installed, then opened it up for you.
> >
> > It would be cool if we could autoextract mime handling information from
> > desktop files installed in /usr/share/applications and generate
> > "mime(application/pdf)" style rpm provides.
>
> If we did this then we could have the nautilus "open with other
> application" dialog use yum to query for other apps that can open the
> file type. In combination with PackageKit to (optionally) let users
> install packages this could be pretty sweet!

not only that, but it would negate one of my problems with the lack of
an install everything option - that I don't know what apps can open a
file unless i've installed it

/me hoping that i haven't started that topic up again...



From alexl at redhat.com  Mon Nov 12 15:48:51 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 12 Nov 2007 16:48:51 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <20071112164046.6e64ed0b@dhcp03.addix.net>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
Message-ID: <1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>


On Mon, 2007-11-12 at 16:40 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:
> 
> > It would be cool if we could autoextract mime handling information
> > from desktop files installed in /usr/share/applications and generate
> > "mime(application/pdf)" style rpm provides.
> 
> YOu know, I like that idea. A lot.

This will figure out the provides needed:

for i in `grep -h MimeType /usr/share/applications/* | sed "s/^MimeType=//" | sed "s/;/\n/g" | sort -u`; do echo "mime($i)"; done

Someone just has to turn it into a proper rpm find-provides thing.




From tbrinkman at sbcglobal.net  Mon Nov 12 14:51:12 2007
From: tbrinkman at sbcglobal.net (Tom Brinkman)
Date: Mon, 12 Nov 2007 08:51:12 -0600
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
Message-ID: <200711120851.12346.tbrinkman@sbcglobal.net>

On Sunday 11 November 2007 11:26:30 am Dr. Diesel wrote:
> This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> relevent.  About 1/2 way down Mplayer tells me my Core 2 Duo is
> not fast enough to play a small video!  This is a 100% fresh
> install of F8 yesterday (+ all updates to date).  No problems
> with F7.  I also tried switching to ALSA as suggested by mplayer,
> but then I'm getting "Unable to find control PCM 0"
>
> The video is very slow and choppy.  Totem movie player has no
> problem with it.  Xine plays about 5 seconds, pauses for a second
> then continues.
>
> Any thoughts?

     Yeah, wrong list.  mplayer-users at mplayerhq.hu
http://www.mplayerhq.hu/design7/dload.html   at that URL there's 
simple instructions for checking out an building from current 
source.  You will be asked if the problem still occurs with current 
svn.

> [root at localhost ~]# mplayer /home/garage/Desktop/p1010008.mov
> MPlayer 1.0rc2-4.1.2 (C) 2000-2007 MPlayer Team
> CPU: Intel(R) Core(TM)2 CPU          4300  @ 1.80GHz (Family: 6,
> Model: 15, Stepping: 2)

    You're running mplayer as root?  ... bad idea.  FWIW,

MPlayer dev-SVN-r25022-4.1.2 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz (Family: 6, 
Model: 15, Stepping: 10) 

     Running F8.90 (rawhide) ... an never the problem you cite. OK, 
it's a faster duo core, but your's should be no problem.   BTW that 
was yesterday's svn.  The only time I have no sound is usin mplayer 
if FF is running an I've previously run a flash movie in FF 
(2.0.0.9).  Quit FF, an then mplayer has sound again.  I've brought 
this up on mplayer-users, including the fact that it's probly a 
(proprietary) flash caused problem.... but nobody else is seein it.
-- 
    Tom Brinkman                       Corpus Christi, Texas



From rdieter at math.unl.edu  Mon Nov 12 15:52:06 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 12 Nov 2007 09:52:06 -0600
Subject: openssl097a package retirement
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
Message-ID: <fh9sr6$kgb$1@ger.gmane.org>

Matthias Clasen wrote:

> Is there any reason not to patch the source to simply link against
> libssl instead ?

These dlopen hacks are often used for licensing compatibility (e.g. openssl
being gpl-incompatible).

-- Rex




From markg85 at gmail.com  Mon Nov 12 15:59:42 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 16:59:42 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <6e24a8e80711120759q3f6e6a3cra0f2078ca9e22de@mail.gmail.com>

2007/11/12, Alexander Larsson <alexl at redhat.com>:
>
> On Mon, 2007-11-12 at 16:40 +0100, Ralf Ertzinger wrote:
> > Hi.
> >
> > On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:
> >
> > > It would be cool if we could autoextract mime handling information
> > > from desktop files installed in /usr/share/applications and generate
> > > "mime(application/pdf)" style rpm provides.
> >
> > YOu know, I like that idea. A lot.
>
> This will figure out the provides needed:
>
> for i in `grep -h MimeType /usr/share/applications/* | sed "s/^MimeType=//" | sed "s/;/\n/g" | sort -u`; do echo "mime($i)"; done
>
> Someone just has to turn it into a proper rpm find-provides thing.

You really seem to like this idea don't you? ^_^

And a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=378061



From jamatos at fc.up.pt  Mon Nov 12 15:59:37 2007
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Mon, 12 Nov 2007 15:59:37 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <47373E51.8050604@gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<200711111722.52795.jamatos@fc.up.pt> <47373E51.8050604@gmail.com>
Message-ID: <200711121559.38383.jamatos@fc.up.pt>

On Sunday 11 November 2007 17:39:29 David Boles wrote:
> If *I* was as unhappy with Fedora as these users appear to be I would
> look elsewhere. And i would have do that a long time ago.

  There are different ways to look into these problems. There are people who 
complain and still do things, that is OK with me. What I am asking is not to 
throw the baby with the water as in a sense you seem to be doing. :-)

  Sometimes also a different stance makes wonders in terms of PR. The outer 
perception of the project is important, as important as the technical side. 
And blank statements like your in this thread do not help. Please be a little 
more patient. :-)

> What do you think Jose? Better to switch or is it just easier to complain?

There are lots of people who been doing much more than complaining. The KDE 
guys have been working hard to have a reasonable integration between KDE and 
the rest of the system. Thanks to their work I am using KDE happily. :-)

> --
> ? David

-- 
Jos? Ab?lio



From a.badger at gmail.com  Mon Nov 12 16:04:36 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 12 Nov 2007 08:04:36 -0800
Subject: build servers kernel release (PPC64)
In-Reply-To: <1194877715.3112.11.camel@localhost.localdomain>
References: <1194877715.3112.11.camel@localhost.localdomain>
Message-ID: <47387994.7030500@gmail.com>

Robert Marcano wrote:
> are the build systems servers running the latest F8 kernel? I need the
> fix of bug 350291 in order to be able to build eclipse-subclipse on
> ppc64 machines. I am asking because the error still happens and I am not
> sure if the fix did not work or the server have an outdated kernel?
> 
> Any help is appreciated
> 
The build systems are currently running FC6.  At the last infrastructure 
meeting we tentatively agreed on upgrading them about 3 weeks from now 
(on the weekend).  We also were leaning towards upgrading them to RHEL5 
at the time.  Do we need to upgrade to F8 instead?

-Toshio



From mcepl at redhat.com  Mon Nov 12 15:58:11 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 12 Nov 2007 16:58:11 +0100
Subject: When will CVS be replaced by modern version control system?
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
	<47386559.6030202@redhat.com>
Message-ID: <jp9m05xce4.ln2@hubmaier.ceplovi.cz>

On Mon, 12 Nov 2007 15:38:17 +0100, Christopher Aillon scripst:
> I think Matej was implying we should point to the upstream repo and
> tagname instead of a tarball.  Then koji would checkout code from
> upstream without relying on us downloading, then subsequently uploading
> a tarball via make upload.

yup. Sorry for being confusing.

Mat?j



From mclasen at redhat.com  Mon Nov 12 16:07:28 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 12 Nov 2007 11:07:28 -0500
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <1194883648.2894.10.camel@localhost.localdomain>


On Mon, 2007-11-12 at 16:48 +0100, Alexander Larsson wrote:
> On Mon, 2007-11-12 at 16:40 +0100, Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:
> > 
> > > It would be cool if we could autoextract mime handling information
> > > from desktop files installed in /usr/share/applications and generate
> > > "mime(application/pdf)" style rpm provides.
> > 
> > YOu know, I like that idea. A lot.
> 
> This will figure out the provides needed:
> 
> for i in `grep -h MimeType /usr/share/applications/* | sed "s/^MimeType=//" | sed "s/;/\n/g" | sort -u`; do echo "mime($i)"; done
> 
> Someone just has to turn it into a proper rpm find-provides thing.

While this may be a nice idea, it doesn't solve

a) editor vs viewer

b) inherited capabilities, ie totem can display any format gstreamer can
handle, which in turn depends on installed plugins



From dominik at greysector.net  Mon Nov 12 16:07:38 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 12 Nov 2007 17:07:38 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <f224c6140711120706x640d0ba7oc5411942860e2f8e@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112143310.0be8d92d@brian.englab.brq.redhat.com>
	<20071112145433.GC10550@onizuka.greysector.net>
	<f224c6140711120706x640d0ba7oc5411942860e2f8e@mail.gmail.com>
Message-ID: <20071112160738.GA3248@ryvius.greysector.net>

On Monday, 12 November 2007 at 16:06, Michel Salim wrote:
> On 12/11/2007, Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:
> > On Monday, 12 November 2007 at 14:33, Michal Schmidt wrote:
> > > On Sun, 11 Nov 2007 12:26:30 -0500
> > > "Dr. Diesel" <dr.diesel at gmail.com> wrote:
> > >
> > > > This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> > > > relevent.
> > > > ...
> > > > AUDIO: 8000 Hz, 1 ch, u8, 64.0 kbit/100.00% (ratio: 8000->8000)
> > >
> > > I remember having a problem playing a 8 kHz sampled
> > > sound via PulseAudio.
> > >
> > > Try commenting out the line which includes pulse-default.conf
> > > in /etc/alsa/alsa.conf.
> >
> > And try without pulseaudio, i.e. use alsa or oss directly (-ao alsa)
> > and make sure pulseaudio is not intercepting alsa calls.
> >
> If playback with OSS works fine, try running it under pulseaudio (wrap
> it with padsp) and see if you get any slowdown. From my experience
> with Real Player, some apps work fine under PulseAudio's OSS emulation
> but cannot handle ALSA routed through PA.

MPlayer has direct support for PulseAudio (-ao pulse), so there's no need
for such hacks.

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From nicolas.mailhot at laposte.net  Mon Nov 12 16:07:37 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 17:07:37 +0100 (CET)
Subject: License review for new itext version
Message-ID: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>


Le Lun 12 novembre 2007 15:36, Tom \"spot\" Callaway a ?crit :
>
> On Sun, 2007-11-11 at 23:38 +0000, Jonathan Underwood wrote:

>> To continue the monologue, it seems itext upstream is now entirely
>> licensed as either LGPL 2 or MPL. As such, I can't see a reason it
>> can't be reinstated in Fedora.
>
> If someone points me at a new package for itext, I'd be happy to do a
> quick audit to confirm that it is OK for Fedora now.

Here you go

http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/repoview/itext-0-1.3-2jpp.html

You can ask the fedora-java guys to perform the usual jpp-to-fedora
changes if needed.

Regards,

-- 
Nicolas Mailhot



From nphilipp at redhat.com  Mon Nov 12 16:11:29 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 12 Nov 2007 17:11:29 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194883648.2894.10.camel@localhost.localdomain>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
	<1194883648.2894.10.camel@localhost.localdomain>
Message-ID: <1194883889.3511.4.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-12 at 11:07 -0500, Matthias Clasen wrote:
> On Mon, 2007-11-12 at 16:48 +0100, Alexander Larsson wrote:
> > On Mon, 2007-11-12 at 16:40 +0100, Ralf Ertzinger wrote:
> > > Hi.
> > > 
> > > On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:
> > > 
> > > > It would be cool if we could autoextract mime handling information
> > > > from desktop files installed in /usr/share/applications and generate
> > > > "mime(application/pdf)" style rpm provides.
> > > 
> > > YOu know, I like that idea. A lot.
> > 
> > This will figure out the provides needed:
> > 
> > for i in `grep -h MimeType /usr/share/applications/* | sed "s/^MimeType=//" | sed "s/;/\n/g" | sort -u`; do echo "mime($i)"; done
> > 
> > Someone just has to turn it into a proper rpm find-provides thing.
> 
> While this may be a nice idea, it doesn't solve
> 
> a) editor vs viewer
> 
> b) inherited capabilities, ie totem can display any format gstreamer can
> handle, which in turn depends on installed plugins

It seems to me that the desktop file is the wrong place then to keep
that information.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nicolas.mailhot at laposte.net  Mon Nov 12 16:13:11 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 17:13:11 +0100 (CET)
Subject: When will CVS be replaced by modern version control system?
Message-ID: <2989.192.54.193.53.1194883991.squirrel@rousalka.dyndns.org>


Le Lun 12 novembre 2007 15:25, Matej Cepl a ?crit :
> On Mon, 12 Nov 2007 15:12:43 +0100, Christopher Aillon scripst:
>> But also keep in mind that much of the current package workflow has
>> been defined by the limitations of CVS. Our current faux-branching
>> scheme was in part done because of CVS, for example.
>> [...]
>> Returning to your original question, which I'll paraphrase as "what
>> do
>> we gain by moving away from CVS?"  Not much.  A small number of
>> users
>> will take advantage of the features that the new VCS gives them.
>
> I think the thing we need to loose is the box where we keep our work-
> flow. So for example, could somebody explain why in the time or DVCSs
> we
> still have tarball-based packaging?

Because that's a good auditing point. You have one fixed version state
+ patches, not a jumble where the distinction between what upstream
provided and what Fedora added is blurred.

-- 
Nicolas Mailhot



From markg85 at gmail.com  Mon Nov 12 16:14:06 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 17:14:06 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <200711121559.38383.jamatos@fc.up.pt>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>
	<200711111722.52795.jamatos@fc.up.pt> <47373E51.8050604@gmail.com>
	<200711121559.38383.jamatos@fc.up.pt>
Message-ID: <6e24a8e80711120814o1867344bs18b5076ac72d04c4@mail.gmail.com>

2007/11/12, Jos? Matos <jamatos at fc.up.pt>:
> On Sunday 11 November 2007 17:39:29 David Boles wrote:
> > If *I* was as unhappy with Fedora as these users appear to be I would
> > look elsewhere. And i would have do that a long time ago.
>
>   There are different ways to look into these problems. There are people who
> complain and still do things, that is OK with me. What I am asking is not to
> throw the baby with the water as in a sense you seem to be doing. :-)
>
>   Sometimes also a different stance makes wonders in terms of PR. The outer
> perception of the project is important, as important as the technical side.
> And blank statements like your in this thread do not help. Please be a little
> more patient. :-)
>
> > What do you think Jose? Better to switch or is it just easier to complain?
>
> There are lots of people who been doing much more than complaining. The KDE
> guys have been working hard to have a reasonable integration between KDE and
> the rest of the system. Thanks to their work I am using KDE happily. :-)
>
> > --
> > David
>
> --
> Jos? Ab?lio

I'm just brainstorming a bit.
but i fully understand that it's a nearly not possible to get this
done. i assume the redhat people have spend many hours talking about
how to get pass this driver issue and that they have put in all
possible effort to have them in fedora... O well.. i guess i just have
to install livna every time i install fedora...



From dominik at greysector.net  Mon Nov 12 16:14:36 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 12 Nov 2007 17:14:36 +0100
Subject: build servers kernel release (PPC64)
In-Reply-To: <47387994.7030500@gmail.com>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com>
Message-ID: <20071112161436.GB3248@ryvius.greysector.net>

On Monday, 12 November 2007 at 17:04, Toshio Kuratomi wrote:
> Robert Marcano wrote:
> >are the build systems servers running the latest F8 kernel? I need the
> >fix of bug 350291 in order to be able to build eclipse-subclipse on
> >ppc64 machines. I am asking because the error still happens and I am not
> >sure if the fix did not work or the server have an outdated kernel?
> >
> >Any help is appreciated
> >
> The build systems are currently running FC6.  At the last infrastructure 
> meeting we tentatively agreed on upgrading them about 3 weeks from now 
> (on the weekend).  We also were leaning towards upgrading them to RHEL5 
> at the time.  Do we need to upgrade to F8 instead?

While you're considering that, there's a bug in buildsystem's yum that
prevents anything that BuildRequires: %{_libdir}/liblapack.so from building
successfully: https://bugzilla.redhat.com/show_bug.cgi?id=349801

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From mcepl at redhat.com  Mon Nov 12 16:02:40 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 12 Nov 2007 17:02:40 +0100
Subject: When will CVS be replaced by modern version control system?
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
	<47386559.6030202@redhat.com> <20071112094037.507a153c@redhat.com>
Message-ID: <02am05xce4.ln2@hubmaier.ceplovi.cz>

On Mon, 12 Nov 2007 09:40:37 -0500, Jesse Keating scripst:
> That might work if every single upstream were using such a mechanism,
> and used proper tags in their source control for release (and didn't
> just fix a few things in the tarball outside of the scm or scm tag). It
> would also mean teaching koji about each and every possible scm, tag
> syntax, etc...
> 
> Until the entire upstream world stops doing releases as tarballs, I
> don't think it's appropriate to change how we consume releases in rpms.

I am not really sure, that it means that -- I am not saying "never ever 
use upstream tarball, ever." My idea would be that koji would get couple 
of backends and Source could be more creative. So instead of just 
"download tarball from this URL, unpack and work", it could understand 
alos URLs like git://, bzr://, hg:// (or something like that), meaning 
"clone/checkout/<whatever is the local name of getting the sources> from 
somewhere, and then build over that". And of course, one of these methods 
of getting sources would be downloading tarball.

Mat?j



From nicolas.mailhot at laposte.net  Mon Nov 12 16:17:02 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 17:17:02 +0100 (CET)
Subject: When will CVS be replaced by modern version control system?
Message-ID: <21753.192.54.193.53.1194884222.squirrel@rousalka.dyndns.org>


Le Lun 12 novembre 2007 15:38, Christopher Aillon a ?crit :

> I think Matej was implying we should point to the upstream repo and
> tagname instead of a tarball.

Please don't. Users want to know what fedora added to the tarball they
can download upstream (and check this tarball md5/sha1), not get a raw
VCS dump.

Also many upstreams perform manual changes on VCS dumps before turning
them into release archives, and you don't want to lose these changes
because they lead to strange bugs people that build from released
sources can not reproduce.

-- 
Nicolas Mailhot



From tcallawa at redhat.com  Mon Nov 12 16:16:53 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 12 Nov 2007 11:16:53 -0500
Subject: License review for new itext version
In-Reply-To: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
References: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
Message-ID: <1194884213.3198.16.camel@localhost.localdomain>


On Mon, 2007-11-12 at 17:07 +0100, Nicolas Mailhot wrote:
> Le Lun 12 novembre 2007 15:36, Tom \"spot\" Callaway a ?crit :
> >
> > On Sun, 2007-11-11 at 23:38 +0000, Jonathan Underwood wrote:
> 
> >> To continue the monologue, it seems itext upstream is now entirely
> >> licensed as either LGPL 2 or MPL. As such, I can't see a reason it
> >> can't be reinstated in Fedora.
> >
> > If someone points me at a new package for itext, I'd be happy to do a
> > quick audit to confirm that it is OK for Fedora now.
> 
> Here you go
> 
> http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/repoview/itext-0-1.3-2jpp.html

The "disparaging Sun" license is gone, but the "nuclear" clause is still
there in some of the classes.

To reiterate what I said before:

This is a use-case restriction: 
"You acknowledge that Software is not designed,licensed or intended for
use in the design, construction, operation or maintenance of any nuclear
facility."

The word "licensed" is the problem here. Acknowledging that the software
isn't designed or intended for any particular use case is fine, but when
you say that the "software is not licensed for use...", then you're
making a use case restriction.

This is still no-go for Fedora, sorry.

~spot




From jkeating at redhat.com  Mon Nov 12 16:22:55 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 11:22:55 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <02am05xce4.ln2@hubmaier.ceplovi.cz>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
	<47386559.6030202@redhat.com> <20071112094037.507a153c@redhat.com>
	<02am05xce4.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071112112255.7f8a091d@redhat.com>

On Mon, 12 Nov 2007 17:02:40 +0100
Matej Cepl <mcepl at redhat.com> wrote:

> I am not really sure, that it means that -- I am not saying "never
> ever use upstream tarball, ever." My idea would be that koji would
> get couple of backends and Source could be more creative. So instead
> of just "download tarball from this URL, unpack and work", it could
> understand alos URLs like git://, bzr://, hg:// (or something like
> that), meaning "clone/checkout/<whatever is the local name of getting
> the sources> from somewhere, and then build over that". And of
> course, one of these methods of getting sources would be downloading
> tarball.

And now your buildsystem is entirely reliant upon upstream locations
staying up, staying consistent, not being compromised, etc...
Definitely not something you want for Fedora, and certainly not
something we can even consider for RHEL.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/b93e6f01/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Nov 12 16:24:02 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 17:24:02 +0100 (CET)
Subject: When will CVS be replaced by modern version control system?
Message-ID: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>


Le Lun 12 novembre 2007 17:02, Matej Cepl a ?crit :
>  So instead of just
> "download tarball from this URL, unpack and work", it could understand
> alos URLs like git://, bzr://, hg:// (or something like that), meaning
> "clone/checkout/<whatever is the local name of getting the sources>
> from somewhere, and then build over that".

This is an auditing & QA nightmare. Today even if upstream disappears
you can easily compare the archive contained in a srpm to the one
mirrors picked up, Debian picked up, Mandriva picked up, etc. The huge
nice property or release archives is they are scarce and not a
continuum. That means everyone uses the same archives. A SCM feed is
something else altogether: suddenly you're not using the same release
as everyone else plus known patches, you're using a state others may
not have picked, and you don't get the benefits of cross-distro
testing (and annoyed upstreams because Fedora bugs are always
different from other user bugs)

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Mon Nov 12 16:30:29 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 17:30:29 +0100 (CET)
Subject: "Extension Buddy" for Fedora 9?
Message-ID: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>


Le Lun 12 novembre 2007 17:07, Matthias Clasen a ?crit :
>
> On Mon, 2007-11-12 at 16:48 +0100, Alexander Larsson wrote:

>> Someone just has to turn it into a proper rpm find-provides thing.
>
> While this may be a nice idea, it doesn't solve
>
> a) editor vs viewer

> b) inherited capabilities, ie totem can display any format gstreamer
> can handle, which in turn depends on installed plugins

Presumably this is something that should be clarified in the desktop
files too, and once the info is there the idea of scrapping it at the
rpm level will still work

-- 
Nicolas Mailhot



From paul at xelerance.com  Mon Nov 12 16:33:19 2007
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 12 Nov 2007 11:33:19 -0500 (EST)
Subject: Codec Buddy misleading.
In-Reply-To: <gjkl05x62j.ln2@hubmaier.ceplovi.cz>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<gjkl05x62j.ln2@hubmaier.ceplovi.cz>
Message-ID: <Pine.LNX.4.64.0711121126390.26997@newtla.xelerance.com>

On Mon, 12 Nov 2007, Matej Cepl wrote:

> > version that includes it. Say in a German-only repository on german
> > servers (and mirrors outside of red hat's control).
>
> Don't go there -- you are trying to do an analysis of the venue for
> litigation in the international context. That's one of the most
> complicated things you can do in the international private law. I have
> two law degrees, one from U.S. university dealing explicitly with the
> international law, and still I wouldn't be very sure what the result of
> such analysis is.

Yes I know. And I understand. And I agree. However, as I stated in th
part that you did not quote, then CodecBuddy should just not exist and
the community should find it like it has before (eg via livna).

The current solution makes RedHat's impact on Fedora US-centric. Now I
understand they don't want to risk international litigation. But the
current solution is wrong on many points:

- It gives false information to non-US users of Fedora
- It promots proprietary non-free software
- It promits non-free over free software for non-US users of Fedora

So the question comes down to: Do we tell where americans can find
workarounds for the failed patent system in the US at the expense of
mis-informing everyone else? Or do we just keep quiet and let people
find out for themselves? Or do we distinguish US and non-US users
similarly to the old days style "crypto export regulations".

> Translated into plain English -- bad idea.

So tell me your idea on how we can better inform the internationa
community about patents and codecs, without discriminating against
non-US users of Fedora. Because the current idea of pretending
international users of Fedora don't exist just before Red Hat is
an American company is worse then keeping quiet like we did pre-F8.

Paul



From paul at xelerance.com  Mon Nov 12 16:39:30 2007
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 12 Nov 2007 11:39:30 -0500 (EST)
Subject: Codec Buddy misleading.
In-Reply-To: <1194848212.2306.55.camel@cookie.hadess.net>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
Message-ID: <Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>

On Mon, 12 Nov 2007, Bastien Nocera wrote:

> > However, I am still of the opinion that non-us people shouldn't be misled
> > to buy things that they're fully entitled to from free and available
> > software, just because of the main location of Fedora's main contributor
> > (Red Hat). Which is why I think the Codec Buddy feature suggesting
> > non-free software should be removed. Americans illegally installing
> > livna rpms is not Red Hat's problem. Europeans mistakingly paying for
> > non-free software is an issue for the Fedora Community.
>
> That is utter crock. If you know about the repositories, you probably
> already have the packages installed already, or that window would remind
> you to install them. If you don't know about them, we can't actually
> point you at them.

Yes, we agree that people who know about this will ignore the new codec
buddy. Or rephrased, "informed people won't accept the misinformation
of needing to pay for codecs" (or if they are US users, will know that
they can steal them).

It is the non-informed user that is harmed by the codec buddy. It just so
happens that it only harms non-US citizens, so this solution is deemed
"not a problem" for Red Hat because they are a US company. That is the
essence of the problem here.

> The bottom line is that people who didn't know how to get playback
> software for their videos and music will now know how to, or at least
> have a way to.

So you are also in favour of not telling people about free health care,
as long as they know how to find a doctor they can pay? That's really a
non argument. Red Hat is basically ripping of non-US citizens via a
business partner.

> In fact, most of this software and the way it made it in Fedora was done
> in Britain and Spain. So I'm not buying the "martyr from Europe who
> shelled out 30 euros" story.

Obviously in cooperation and under ultimate decisions of releng and its
lawyers. So this argument also makes no sense.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155



From skvidal at fedoraproject.org  Mon Nov 12 16:39:10 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 12 Nov 2007 11:39:10 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
Message-ID: <1194885550.2025.6.camel@cutter>


On Mon, 2007-11-12 at 11:39 -0500, Paul Wouters wrote:

> So you are also in favour of not telling people about free health care,
> as long as they know how to find a doctor they can pay? That's really a
> non argument. Red Hat is basically ripping of non-US citizens via a
> business partner.

wooooooooooooooah.
not a business partner.

Fluendo is not a business partner with the fedora project.

-sv




From notting at redhat.com  Mon Nov 12 16:44:07 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 12 Nov 2007 11:44:07 -0500
Subject: LSB init scripts - automatic start
In-Reply-To: <36716.63.85.68.164.1194878620.squirrel@mail.jcomserv.net>
References: <200711081730.lA8HUk1G017806@cvs-int.fedora.redhat.com>
	<47349182.50800@cora.nwra.com>
	<28791.63.85.68.164.1194634199.squirrel@mail.jcomserv.net>
	<20071109213706.GA2098@nostromo.devel.redhat.com>
	<36716.63.85.68.164.1194878620.squirrel@mail.jcomserv.net>
Message-ID: <20071112164407.GA3261@nostromo.devel.redhat.com>

> > Correct, but it's still generally done that services don't start by
> > default.
> 
> So in the LSB block, I'd want:
> 
> # Default-Start:
> 
> instead of:
> 
> # Default-Start:  2 3 4 5
> 
> correct?

Yes.

Bill



From fedora at camperquake.de  Mon Nov 12 16:48:28 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 17:48:28 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <1194885550.2025.6.camel@cutter>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
Message-ID: <20071112174828.372637fd@dhcp03.addix.net>

Hi.

On Mon, 12 Nov 2007 11:39:10 -0500, seth vidal wrote:

> Fluendo is not a business partner with the fedora project.

So directing people to a vendor selling software is an act
of charity?



From jspaleta at gmail.com  Mon Nov 12 16:49:39 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 12 Nov 2007 07:49:39 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
Message-ID: <604aa7910711120849n34e53f84i1ff6243544c8a29e@mail.gmail.com>

On Nov 12, 2007 7:39 AM, Paul Wouters <paul at xelerance.com> wrote:
> So you are also in favour of not telling people about free health care,
> as long as they know how to find a doctor they can pay? That's really a
> non argument. Red Hat is basically ripping of non-US citizens via a
> business partner.

Let's be clear here.  There is no 'partnering' going on.  There is no
exclusivity agreement  associated with how Fedora is presenting the
information.


> Obviously in cooperation and under ultimate decisions of releng and its
> lawyers. So this argument also makes no sense.


If we had knowledge of other worldwide legal options that could be
pointed to specifically we'd have included them.  Right now is there
anything misleading at
http://fedoraproject.org/wiki/CodecBuddy ?  We state that if you are
in a location where the patents do not apply, then you have other
options. How is that misleading?

-jef



-jef



From jspaleta at gmail.com  Mon Nov 12 16:50:35 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 12 Nov 2007 07:50:35 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <20071112174828.372637fd@dhcp03.addix.net>
References: <1194613590.3255.10.camel@perihelion>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
Message-ID: <604aa7910711120850s708b5bd2j7f491091da23b013@mail.gmail.com>

On Nov 12, 2007 7:48 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> So directing people to a vendor selling software is an act
> of charity?

Would you feel better if we just populated the initial dialogs with
information about the no-cost mp3 plugin?

-jef



From skvidal at fedoraproject.org  Mon Nov 12 16:49:39 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 12 Nov 2007 11:49:39 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <20071112174828.372637fd@dhcp03.addix.net>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
Message-ID: <1194886179.2025.8.camel@cutter>


On Mon, 2007-11-12 at 17:48 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 12 Nov 2007 11:39:10 -0500, seth vidal wrote:
> 
> > Fluendo is not a business partner with the fedora project.
> 
> So directing people to a vendor selling software is an act
> of charity?


A business partner implies an agreement.

there is no such agreement. If we have any other option for worldwide
legal distribution please, offer it.

-sv




From jkeating at redhat.com  Mon Nov 12 16:52:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 11:52:37 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <20071112174828.372637fd@dhcp03.addix.net>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
Message-ID: <20071112115237.250cf5bd@redhat.com>

On Mon, 12 Nov 2007 17:48:28 +0100
Ralf Ertzinger <fedora at camperquake.de> wrote:

> On Mon, 12 Nov 2007 11:39:10 -0500, seth vidal wrote:
> 
> > Fluendo is not a business partner with the fedora project.  
> 
> So directing people to a vendor selling software is an act
> of charity?

SO far, they're the only ones offering legal codecs for a large number
of our users.  If you have more examples we can easily put them into
the codeina build.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/60a9480c/attachment.sig>

From notting at redhat.com  Mon Nov 12 16:54:06 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 12 Nov 2007 11:54:06 -0500
Subject: openssl097a package retirement
In-Reply-To: <fh9sr6$kgb$1@ger.gmane.org>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
Message-ID: <20071112165406.GC3261@nostromo.devel.redhat.com>

Rex Dieter (rdieter at math.unl.edu) said: 
> > Is there any reason not to patch the source to simply link against
> > libssl instead ?
> 
> These dlopen hacks are often used for licensing compatibility (e.g. openssl
> being gpl-incompatible).

To push any license violations on to the user instead of the distributor?
Cute. Why not just add an exception to your license?

Bill



From david at fubar.dk  Mon Nov 12 16:50:37 2007
From: david at fubar.dk (David Zeuthen)
Date: Mon, 12 Nov 2007 11:50:37 -0500
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
Message-ID: <1194886237.29655.9.camel@oneill.fubar.dk>


Hi Nicolas,

The mailer you're using right now breaks threading (in Evolution at
least) and makes it more difficult for mere mortals like myself to
follow this list. Care to reconsider using another way of contributing
to this list? Thank you for considering this request.

     David




From tmraz at redhat.com  Mon Nov 12 17:06:19 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 12 Nov 2007 18:06:19 +0100
Subject: Orphaning beecrypt
Message-ID: <1194887180.17465.31.camel@vespa.kabelta.loc>

Hi Fedora developers,

I'm orphaning beecrypt in Fedora development branch as rpm as the only
previous user of beecrypt now uses NSS for cryptography. I'll still keep
its ownership for Fedora 7 and 8 branches. If noone steps up beecrypt
will be retired from Fedora development branch.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From debarshi.ray at gmail.com  Mon Nov 12 17:07:33 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 12 Nov 2007 22:37:33 +0530
Subject: openssl097a package retirement
In-Reply-To: <20071112165406.GC3261@nostromo.devel.redhat.com>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
Message-ID: <3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>

> To push any license violations on to the user instead of the distributor?
> Cute. Why not just add an exception to your license?

I am afraid you got me wrong here. I did not use the term "compatible"
to mean license compatibility. I wanted to know whether an application
which dlopens libssl.so.0.9.8 could safely use libssl.so.0.9.8b
instead, without causing any API/ABI breakage?

Sorry for the misunderstanding.

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From ville.skytta at iki.fi  Mon Nov 12 17:09:37 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 12 Nov 2007 19:09:37 +0200
Subject: License review for new itext version
In-Reply-To: <1194884213.3198.16.camel@localhost.localdomain>
References: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
	<1194884213.3198.16.camel@localhost.localdomain>
Message-ID: <200711121909.38197.ville.skytta@iki.fi>

On Monday 12 November 2007, Tom "spot" Callaway wrote:
> On Mon, 2007-11-12 at 17:07 +0100, Nicolas Mailhot wrote:
> > Le Lun 12 novembre 2007 15:36, Tom \"spot\" Callaway a ?crit :
>
> > > If someone points me at a new package for itext, I'd be happy to do a
> > > quick audit to confirm that it is OK for Fedora now.
> >
> > Here you go
> >
> > http://mirrors.dotsrc.org/jpackage/1.7/generic/free/repodata/repoview/ite
> >xt-0-1.3-2jpp.html

That's an old version of iText.  Current upstream is 2.0.6.
http://prdownloads.sourceforge.net/itext/itext-src-2.0.6.tar.gz

> The "disparaging Sun" license is gone, but the "nuclear" clause is still
> there in some of the classes.

It's also there in 2.0.6 and upstream svn.



From notting at redhat.com  Mon Nov 12 17:15:49 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 12 Nov 2007 12:15:49 -0500
Subject: openssl097a package retirement
In-Reply-To: <3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
Message-ID: <20071112171549.GA5460@nostromo.devel.redhat.com>

Debarshi 'Rishi' Ray (debarshi.ray at gmail.com) said: 
> I am afraid you got me wrong here. I did not use the term "compatible"
> to mean license compatibility. I wanted to know whether an application
> which dlopens libssl.so.0.9.8 could safely use libssl.so.0.9.8b
> instead, without causing any API/ABI breakage?

'Not necessarily'. It's why the soname changes.

Bill



From bruno at wolff.to  Mon Nov 12 17:19:51 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 12 Nov 2007 11:19:51 -0600
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
Message-ID: <20071112171951.GB7464@wolff.to>

On Mon, Nov 12, 2007 at 12:38:59 +0100,
  Mark <markg85 at gmail.com> wrote:
> 
> A few days ago i installed Audacious on my Fedora 8 and it works fine!
> no issue with that. But now i wanted to open up a .m3u file extension
> and fedora didn't know what to do with it.. so i had to select the
> audio player for it manually (Audacious). And there are a lot more
> extensions that fedora doesn't know of. .m3u is just an example.

/etc/mime.types provides a binding between filename extensions and mime types
and /etc/mailcap provides viewing commands for mime types. Wouldn't you
want to build on this system?



From jspaleta at gmail.com  Mon Nov 12 17:22:32 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 12 Nov 2007 08:22:32 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <1194848212.2306.55.camel@cookie.hadess.net>
References: <1194613590.3255.10.camel@perihelion>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
Message-ID: <604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>

On Nov 11, 2007 9:16 PM, Bastien Nocera <bnocera at redhat.com> wrote:
> That is utter crock. If you know about the repositories, you probably
> already have the packages installed already, or that window would remind
> you to install them. If you don't know about them, we can't actually
> point you at them.

What we could use, is a technical mechanism in how codeina works that
a 3rd party repository can hook into to add additional codec offerings
via rpm packages. Once someone installs the livna-release package, it
would be great if the livna-release package could drop in the
necessary files on the filesystem so codeina would know how to request
package installation from livna.

-jef



From debarshi.ray at gmail.com  Mon Nov 12 17:34:04 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 12 Nov 2007 23:04:04 +0530
Subject: openssl097a package retirement
In-Reply-To: <20071112171549.GA5460@nostromo.devel.redhat.com>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
Message-ID: <3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>

> 'Not necessarily'. It's why the soname changes.

That is why I asked. :-)

The comments in the HTTrack code say that it should be compatible with
versions later than libssl.so.0.9.8. I have asked HTTrack upstream,
and wanted to know if the openssl packager knew something about what
might have changed or potential trouble spots. I am not familiar with
the openssl code myself.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From lkundrak at redhat.com  Mon Nov 12 17:42:36 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 12 Nov 2007 18:42:36 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
Message-ID: <1194889356.24665.3.camel@localhost.localdomain>


On Sun, 2007-11-11 at 12:26 -0500, Dr. Diesel wrote:
> This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> relevent.  About 1/2 way down Mplayer tells me my Core 2 Duo is not
> fast enough to play a small video!  This is a 100% fresh install of F8
> yesterday (+ all updates to date).  No problems with F7.  I also tried
> switching to ALSA as suggested by mplayer, but then I'm getting
> "Unable to find control PCM 0"
> 
> The video is very slow and choppy.  Totem movie player has no problem
> with it.  Xine plays about 5 seconds, pauses for a second then
> continues.

I suggest you should use Totem. :)

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From nicolas.mailhot at laposte.net  Mon Nov 12 17:47:04 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 18:47:04 +0100
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <1194886237.29655.9.camel@oneill.fubar.dk>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
Message-ID: <1194889624.27768.8.camel@rousalka.dyndns.org>


Le lundi 12 novembre 2007 ? 11:50 -0500, David Zeuthen a ?crit :
> Hi Nicolas,

Hi David,

> The mailer you're using right now breaks threading (in Evolution at
> least) and makes it more difficult for mere mortals like myself to
> follow this list.

The mailer I'm using is the version Fedora ships, and a bug has been
filed, so as soon as the Fedora maintainer fixes it the problem will go
away.

https://bugzilla.redhat.com/show_bug.cgi?id=358261

>  Care to reconsider using another way of contributing
> to this list? Thank you for considering this request.

Unfortunately my employer parano?d firewall restricts me to webmail when
at work, and I don't know of any other webmail Fedora bundles I could
install in the short term (and installing a new webmail is not so easy
either).

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/78ebd3e9/attachment.sig>

From lesmikesell at gmail.com  Mon Nov 12 17:53:39 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 12 Nov 2007 11:53:39 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>
Message-ID: <47389323.6060004@gmail.com>

Nicolas Mailhot wrote:
> Le Lun 12 novembre 2007 17:02, Matej Cepl a ?crit :
>>  So instead of just
>> "download tarball from this URL, unpack and work", it could understand
>> alos URLs like git://, bzr://, hg:// (or something like that), meaning
>> "clone/checkout/<whatever is the local name of getting the sources>
>> from somewhere, and then build over that".
> 
> This is an auditing & QA nightmare. Today even if upstream disappears
> you can easily compare the archive contained in a srpm to the one
> mirrors picked up, Debian picked up, Mandriva picked up, etc.

But not as easily as if they were tags in a common SCM.  How does the 
kernel work?  That's one thing common to all distros that already has a 
distributed SCM.

 > The huge
> nice property or release archives is they are scarce and not a
> continuum. That means everyone uses the same archives. A SCM feed is
> something else altogether: suddenly you're not using the same release
> as everyone else plus known patches, you're using a state others may
> not have picked, and you don't get the benefits of cross-distro
> testing (and annoyed upstreams because Fedora bugs are always
> different from other user bugs)

That should be a matter of appropriate tagging.  In most cases there 
would already be a direct mapping of SCM tags to tarball releases.

-- 
    Les



From limb at jcomserv.net  Mon Nov 12 17:53:14 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 12 Nov 2007 11:53:14 -0600 (CST)
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <1194889624.27768.8.camel@rousalka.dyndns.org>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
Message-ID: <21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>


>
> Le lundi 12 novembre 2007 ?  11:50 -0500, David Zeuthen a ??crit :
>> Hi Nicolas,
>
> Hi David,
>
>> The mailer you're using right now breaks threading (in Evolution at
>> least) and makes it more difficult for mere mortals like myself to
>> follow this list.
>
> The mailer I'm using is the version Fedora ships, and a bug has been
> filed, so as soon as the Fedora maintainer fixes it the problem will go
> away.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=358261
>
>>  Care to reconsider using another way of contributing
>> to this list? Thank you for considering this request.
>
> Unfortunately my employer parano??d firewall restricts me to webmail when
> at work, and I don't know of any other webmail Fedora bundles I could
> install in the short term (and installing a new webmail is not so easy
> either).

yum install roundcubemail. www.roundcube.net.  Needs a database.

> Regards,
>
> --
> Nicolas Mailhot
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From lmacken at redhat.com  Mon Nov 12 18:01:32 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 12 Nov 2007 13:01:32 -0500
Subject: [PATCH] Makefile.common: bodhi update target
Message-ID: <20071112180131.GT11043@crow.myhome.westell.com>

Attached is a patch to add an 'update' target to our common Makefile.
When executed in a branch supported by bodhi (F-{7,8}), it will drop
you into a template and then submit your update to bodhi.

Comments/suggestions welcome,

luke
-------------- next part --------------
--- Makefile.common	30 Oct 2007 18:33:33 -0000	1.80
+++ Makefile.common	12 Nov 2007 17:57:00 -0000
@@ -129,6 +129,7 @@ WGET	?= $(shell if test -f /usr/bin/wget
 CLIENT	?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET)))
 PLAGUE_CLIENT ?= $(shell which plague-client 2>/dev/null)
 BUILD_CLIENT ?= $(shell which koji 2>/dev/null)
+BODHI_CLIENT ?= $(shell which bodhi 2>/dev/null)
 
 # RPM with all the overrides in place; you can override this in your
 # .cvspkgsrc also, to use a default rpm setup
@@ -424,6 +425,17 @@ else
 build: plague
 endif
 
+bodhi: build-check $(COMMON_DIR)/branches
+	@if [ ! -x "$(BODHI_CLIENT)" ]; then echo "Must have bodhi-client installed"; exit 1; fi
+	@echo -e "# [ $(NAME)-$(VERSION)-$(RELEASE) ]\n# To abort this update, delete any uncommented lines before saving this file\n# type=[S|B|E] (S=security, B=bugfix, E=enhancement)\n# request=[T|S] (T=testing, S=stable)\n# bug=123,456\n# all other text will be considered to be part of the update notes\ntype=B" > bodhi.template
+	@if [ -z "$$EDITOR" ]; then vi bodhi.template; else $$EDITOR bodhi.template; fi
+	@$(BODHI_CLIENT) --new --release $(subst -,,$(BRANCH)) --file bodhi.template $(NAME)-$(VERSION)-$(RELEASE)
+	@rm -f bodhi.template
+
+ifneq (, $(filter F-8 F-7, $(BRANCH)))
+update: bodhi
+endif
+
 cvsurl:
 	@echo '$(CVS_URL)'
 

From berrange at redhat.com  Mon Nov 12 18:11:46 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 12 Nov 2007 18:11:46 +0000
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <20071112180131.GT11043@crow.myhome.westell.com>
References: <20071112180131.GT11043@crow.myhome.westell.com>
Message-ID: <20071112181146.GC14436@redhat.com>

On Mon, Nov 12, 2007 at 01:01:32PM -0500, Luke Macken wrote:
> Attached is a patch to add an 'update' target to our common Makefile.
> When executed in a branch supported by bodhi (F-{7,8}), it will drop
> you into a template and then submit your update to bodhi.
> 
> Comments/suggestions welcome,

Automatically fill in the BZ & CVE data based on the changelogs added to the
spec since the last pushed update. eg, some recent Xen changess with BZ
and CVE numbers..

* Wed Sep 26 2007 Chris Lalancette <clalance at redhat.com> - 3.1.0-10.fc8
- QEmu NE2000 overflow check - CVE-2007-1321
- Pygrub guest escape - CVE-2007-4993

* Mon Sep 24 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-9.fc8
- Fix generation of manual pages (rhbz #250791)
- Really fix FC-6 32-on-64 guests

I'm sure other people have various similar styles - it should be possible
to get a regex which catches the 95% common cases & pre-fills the update
template. The same could be done for the web UI too when we select a RPM
N-E-V-R in the form.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From nicolas.mailhot at laposte.net  Mon Nov 12 18:13:25 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 19:13:25 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <47389323.6060004@gmail.com>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>
	<47389323.6060004@gmail.com>
Message-ID: <1194891205.27768.22.camel@rousalka.dyndns.org>


Le lundi 12 novembre 2007 ? 11:53 -0600, Les Mikesell a ?crit :
> Nicolas Mailhot wrote:
> > Le Lun 12 novembre 2007 17:02, Matej Cepl a ?crit :
> >>  So instead of just
> >> "download tarball from this URL, unpack and work", it could understand
> >> alos URLs like git://, bzr://, hg:// (or something like that), meaning
> >> "clone/checkout/<whatever is the local name of getting the sources>
> >> from somewhere, and then build over that".
> > 
> > This is an auditing & QA nightmare. Today even if upstream disappears
> > you can easily compare the archive contained in a srpm to the one
> > mirrors picked up, Debian picked up, Mandriva picked up, etc.
> 
> But not as easily as if they were tags in a common SCM.

Read again: "if upstream disappears" you don't have a SCM reference
anymore. Also upstreams have been known to move tags and branches.

> How does the 
> kernel work?  That's one thing common to all distros that already has a 
> distributed SCM.

Distros still use tarballs to build their kernel packages and even if
they didn't the kernel is special: there are very few projects so
central we know their SCM is not going to change or disappear suddenly.

>  > The huge
> > nice property or release archives is they are scarce and not a
> > continuum. That means everyone uses the same archives. A SCM feed is
> > something else altogether: suddenly you're not using the same release
> > as everyone else plus known patches, you're using a state others may
> > not have picked, and you don't get the benefits of cross-distro
> > testing (and annoyed upstreams because Fedora bugs are always
> > different from other user bugs)
> 
> That should be a matter of appropriate tagging.

We can't even get all upstreams to agree on a common sane archive naming
and numbering and you want us to posit they'll have sane SCM tagging
conventions?

And that does not change the fact even a perfect SCM offers many more
pull points than a release archive process, so you still lose the
"everyone tests the same version" effect. And I don't even want to think
the fun people following CVE numbers would have in this scenario.

> In most cases there 
> would already be a direct mapping of SCM tags to tarball releases.

Quite the contrary, this is the exception not the rule. Most projects
have tags that approximate releases, which is good enough for
developers, but not for QA or audit trails.

Ironically Fedora cvs is one exception and that's only because koji will
only build stuff when given a tag number, and generally speaking we have
anal brutal dumb SCM procedures that force everyone to behave.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/de076deb/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Nov 12 18:15:08 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 19:15:08 +0100
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
Message-ID: <1194891308.27768.25.camel@rousalka.dyndns.org>


Le lundi 12 novembre 2007 ? 11:53 -0600, Jon Ciesla a ?crit :

> yum install roundcubemail.

Looks nice. Not too confident in a 0.1-rc2 version though :)

>  www.roundcube.net.  Needs a database.

Unfortunately that means it's not a short-term project as I've managed
to avoid databases so far.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/49fff0ff/attachment.sig>

From jonathan.underwood at gmail.com  Mon Nov 12 18:22:52 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 12 Nov 2007 18:22:52 +0000
Subject: License review for new itext version
In-Reply-To: <1194884213.3198.16.camel@localhost.localdomain>
References: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
	<1194884213.3198.16.camel@localhost.localdomain>
Message-ID: <645d17210711121022w187d78c6i46f7725b1df701e0@mail.gmail.com>

On 12/11/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
> To reiterate what I said before:
>
> This is a use-case restriction:
> "You acknowledge that Software is not designed,licensed or intended for
> use in the design, construction, operation or maintenance of any nuclear
> facility."
>
> The word "licensed" is the problem here. Acknowledging that the software
> isn't designed or intended for any particular use case is fine, but when
> you say that the "software is not licensed for use...", then you're
> making a use case restriction.
>
> This is still no-go for Fedora, sorry.

That's a real shame. I'll try contacting the itext authors to see if
anything can be done.



From markg85 at gmail.com  Mon Nov 12 18:34:19 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 19:34:19 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
Message-ID: <6e24a8e80711121034o45eea84arbc7ea75940d97798@mail.gmail.com>

> What we could use, is a technical mechanism in how codeina works that
> a 3rd party repository can hook into to add additional codec offerings
> via rpm packages. Once someone installs the livna-release package, it
> would be great if the livna-release package could drop in the
> necessary files on the filesystem so codeina would know how to request
> package installation from livna.
>
> -jef

I fully agree with that and hope that fedora is gonna put something
like that in Codeina.



From tonynelson at georgeanelson.com  Mon Nov 12 18:33:04 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Mon, 12 Nov 2007 13:33:04 -0500
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <1194891308.27768.25.camel@rousalka.dyndns.org>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
	<1194891308.27768.25.camel@rousalka.dyndns.org>
Message-ID: <p04330107c35e4c55b343@[192.168.123.162]>

At 7:15 PM +0100 11/12/07, Nicolas Mailhot wrote:
 ...
>Le lundi 12 novembre 2007 ? 11:53 -0600, Jon Ciesla a ?crit :
>
>> yum install roundcubemail.
>
>Looks nice. Not too confident in a 0.1-rc2 version though :)
>
>>  www.roundcube.net.  Needs a database.
>
>Unfortunately that means it's not a short-term project as I've managed
>to avoid databases so far.

Apparantly (I googled "site:roundcube.net/ sqlite") one can also use
sqlite, but it still might be too much of a project for your use case.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From jspaleta at gmail.com  Mon Nov 12 18:36:13 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 12 Nov 2007 09:36:13 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711121034o45eea84arbc7ea75940d97798@mail.gmail.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
	<6e24a8e80711121034o45eea84arbc7ea75940d97798@mail.gmail.com>
Message-ID: <604aa7910711121036p6663cd39y6af5eee15cb64022@mail.gmail.com>

On Nov 12, 2007 9:34 AM, Mark <markg85 at gmail.com> wrote:
> I fully agree with that and hope that fedora is gonna put something
> like that in Codeina.

How about... upstream put it in..and then Fedora or any other
distribution can make use of it?

-jef



From limb at jcomserv.net  Mon Nov 12 18:37:43 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 12 Nov 2007 12:37:43 -0600 (CST)
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <p04330107c35e4c55b343@[192.168.123.162]>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
	<1194891308.27768.25.camel@rousalka.dyndns.org>
	<p04330107c35e4c55b343@[192.168.123.162]>
Message-ID: <1421.63.85.68.164.1194892663.squirrel@mail.jcomserv.net>


> At 7:15 PM +0100 11/12/07, Nicolas Mailhot wrote:
>  ...
>>Le lundi 12 novembre 2007 ? 11:53 -0600, Jon Ciesla a ?crit :
>>
>>> yum install roundcubemail.
>>
>>Looks nice. Not too confident in a 0.1-rc2 version though :)
>>
>>>  www.roundcube.net.  Needs a database.
>>
>>Unfortunately that means it's not a short-term project as I've managed
>>to avoid databases so far.
>
> Apparantly (I googled "site:roundcube.net/ sqlite") one can also use
> sqlite, but it still might be too much of a project for your use case.

It does, but not in Fedora, because is requires the SQLite-2 extension,
which is unavailable in Fedora.

> ____________________________________________________________________
> TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
>       '                              <http://www.georgeanelson.com/>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From fedora at camperquake.de  Mon Nov 12 18:37:23 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 19:37:23 +0100
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
Message-ID: <20071112193723.6b05b1f5@lain.camperquake.de>

Hi.

On Mon, 12 Nov 2007 11:53:14 -0600 (CST), Jon Ciesla wrote

> yum install roundcubemail. www.roundcube.net.  Needs a database.

Ooooh, shiny. Thanks!



From ville.skytta at iki.fi  Mon Nov 12 18:39:03 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 12 Nov 2007 20:39:03 +0200
Subject: Orphaned: openct, opensc, pcsc-perl, pcsc-tools, libid3tag,
	gkrellm-weather
Message-ID: <200711122039.03971.ville.skytta@iki.fi>

Hello,

I haven't been really using some packages I maintain for a while, so it'd be 
better if someone who actually uses them would take over:

gkrellm-weather
libid3tag
openct
opensc
pcsc-perl
pcsc-tools

I've released ownership for these in pkgdb.



From limb at jcomserv.net  Mon Nov 12 18:41:06 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 12 Nov 2007 12:41:06 -0600 (CST)
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <20071112193723.6b05b1f5@lain.camperquake.de>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
	<20071112193723.6b05b1f5@lain.camperquake.de>
Message-ID: <5136.63.85.68.164.1194892866.squirrel@mail.jcomserv.net>


> Hi.
>
> On Mon, 12 Nov 2007 11:53:14 -0600 (CST), Jon Ciesla wrote
>
>> yum install roundcubemail. www.roundcube.net.  Needs a database.
>
> Ooooh, shiny. Thanks!

(grabs Ralf's wallet while Ralf is distracted by the shiny) :)))

Works every time. ;)

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From limb at jcomserv.net  Mon Nov 12 18:42:51 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 12 Nov 2007 12:42:51 -0600 (CST)
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <5136.63.85.68.164.1194892866.squirrel@mail.jcomserv.net>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
	<20071112193723.6b05b1f5@lain.camperquake.de>
	<5136.63.85.68.164.1194892866.squirrel@mail.jcomserv.net>
Message-ID: <7329.63.85.68.164.1194892971.squirrel@mail.jcomserv.net>


>
>> Hi.
>>
>> On Mon, 12 Nov 2007 11:53:14 -0600 (CST), Jon Ciesla wrote
>>
>>> yum install roundcubemail. www.roundcube.net.  Needs a database.
>>
>> Ooooh, shiny. Thanks!
>
> (grabs Ralf's wallet while Ralf is distracted by the shiny) :)))

(feels guilty at using AJAXy goodness for evil, gives it back)

> Works every time. ;)
>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> --
> novus ordo absurdum
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From notting at redhat.com  Mon Nov 12 18:45:27 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 12 Nov 2007 13:45:27 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
References: <6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
Message-ID: <20071112184527.GA12068@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> What we could use, is a technical mechanism in how codeina works that
> a 3rd party repository can hook into to add additional codec offerings
> via rpm packages. Once someone installs the livna-release package, it
> would be great if the livna-release package could drop in the
> necessary files on the filesystem so codeina would know how to request
> package installation from livna.

codeina works by reading /usr/share/codeina/xml/available-plugins.xml, which
lists for a particular 'bundle' (i.e., tarball):

- gstreamer element/mime type
- descriptive info
- EULA URI
- arches, sha1sum, etc.
- download link
- price, if needed

To change this list would reqiure respinning codeina. codeina, at the moment,
has no mechanism for installing RPMs or similar packages.

Bill



From markg85 at gmail.com  Mon Nov 12 18:48:36 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 19:48:36 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <604aa7910711121036p6663cd39y6af5eee15cb64022@mail.gmail.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
	<6e24a8e80711121034o45eea84arbc7ea75940d97798@mail.gmail.com>
	<604aa7910711121036p6663cd39y6af5eee15cb64022@mail.gmail.com>
Message-ID: <6e24a8e80711121048x3ac87802nc9cdeff97f5d2b01@mail.gmail.com>

2007/11/12, Jeff Spaleta <jspaleta at gmail.com>:
> On Nov 12, 2007 9:34 AM, Mark <markg85 at gmail.com> wrote:
> > I fully agree with that and hope that fedora is gonna put something
> > like that in Codeina.
>
> How about... upstream put it in..and then Fedora or any other
> distribution can make use of it?
>
> -jef

Than we would first need to find a way to make it even possible for
other packages to add codec directives to codeina. I'm currently
thinking that codeina should read the directory:
/usr/share/codeina/xml where codeina should just read all the xml
files. this can be a relative simple patch (if it's not done already..
don't know) but i don't know if it's within the pm guidelines to add
files insize the directory of another application
(/usr/share/codeina/xml).. if that's no problem that this can be in
quick. perhaps even i can make that patch..



From jspaleta at gmail.com  Mon Nov 12 18:51:12 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 12 Nov 2007 09:51:12 -0900
Subject: Codec Buddy misleading.
In-Reply-To: <20071112184527.GA12068@nostromo.devel.redhat.com>
References: <6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
	<20071112184527.GA12068@nostromo.devel.redhat.com>
Message-ID: <604aa7910711121051g49fd55ev81601de3121146@mail.gmail.com>

On Nov 12, 2007 9:45 AM, Bill Nottingham <notting at redhat.com> wrote:
> To change this list would reqiure respinning codeina. codeina, at the moment,
> has no mechanism for installing RPMs or similar packages.

Right... codeina doesn't have this now. But barring someone carrying
enough to do the work, is there a reason why codeina couldn't grow
this support? I would think the roaming horde of packagekit fans would
be all over this.. challenge. Finding a way to integrate packagekit
with what codeina does seems like an obvious "win win" to me. But I'm
a dirty American capitalist so my opinion doesn't count for much in
this discussion.  I'm just trying to inspire the Europeans to find a
technical solution which we can make use of.

-jef



From opensource at till.name  Mon Nov 12 18:57:19 2007
From: opensource at till.name (Till Maas)
Date: Mon, 12 Nov 2007 19:57:19 +0100
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <20071112180131.GT11043@crow.myhome.westell.com>
References: <20071112180131.GT11043@crow.myhome.westell.com>
Message-ID: <200711121957.31902.opensource@till.name>

On Mo November 12 2007, Luke Macken wrote:
> Attached is a patch to add an 'update' target to our common Makefile.
> When executed in a branch supported by bodhi (F-{7,8}), it will drop
> you into a template and then submit your update to bodhi.
>
> Comments/suggestions welcome,

Is there a package for the bodhi client? I cannot find one with either "yum 
whatprovides *bodhi" or "yum search bodhi".

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/7420ff8c/attachment.sig>

From opensource at till.name  Mon Nov 12 19:00:44 2007
From: opensource at till.name (Till Maas)
Date: Mon, 12 Nov 2007 20:00:44 +0100
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <20071112181146.GC14436@redhat.com>
References: <20071112180131.GT11043@crow.myhome.westell.com>
	<20071112181146.GC14436@redhat.com>
Message-ID: <200711122000.45521.opensource@till.name>

On Mo November 12 2007, Daniel P. Berrange wrote:

> Automatically fill in the BZ & CVE data based on the changelogs added to
> the spec since the last pushed update. eg, some recent Xen changess with BZ
> and CVE numbers..

You can get this with my Makefile.common addons:

http://till.fedorapeople.org/Makefile.common-addons/Makefile.common-addons.gmk

But only parsing the latest changelog entry is supported (It parses the file 
that is created with "make clog").

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/fdba5707/attachment.sig>

From opensource at till.name  Mon Nov 12 19:08:08 2007
From: opensource at till.name (Till Maas)
Date: Mon, 12 Nov 2007 20:08:08 +0100
Subject: kernel-PAE and NX (No eXecute)
Message-ID: <200711122008.08668.opensource@till.name>

Hiyas,

is still the kernel-PAE kernel needed in Fedora to use NX (No eXcute)? I read 
that the 2.6.23 kernel supports NX without the need to activate 64G memory 
support? If PAE for NX is not yet enabled in the normal kernel package, can 
we enable it and rename the -PAE package to e.g. HIGHMEM64 or similiar, to 
make it more obvious what it is useful for?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/3825e74a/attachment.sig>

From Lam at Lam.pl  Mon Nov 12 19:09:43 2007
From: Lam at Lam.pl (Leszek Matok)
Date: Mon, 12 Nov 2007 20:09:43 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194883648.2894.10.camel@localhost.localdomain>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
	<1194883648.2894.10.camel@localhost.localdomain>
Message-ID: <20071112200943.78a6bdb8@pensja.lam.pl>

Dnia 2007-11-12, o godz. 11:07:28 Matthias Clasen <mclasen at redhat.com>
napisa?(a):

> a) editor vs viewer
True.

> b) inherited capabilities, ie totem can display any format gstreamer can
> handle, which in turn depends on installed plugins
Right now Totem claims to be able to play any multimedia files even though it
really can't (because by default plugins for the most prominent formats like
DVD aren't installed). The solution here is to switch
MimeType=(...)
into
MimeTypeDir=/usr/lib/gstreamer-x.xx/mime.types.d
and let plugins put appropriate files there (also, make the rpm macro
understand the new flag). This way Nautilus (or rather some helper app) would
know (from rpmdb or better, yum's cache), which package you have to install to
be able to play a file in Totem (or any gstreamer application using my
MimeTypeDir).

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/c163db8e/attachment.sig>

From email.ahmedkamal at googlemail.com  Mon Nov 12 19:21:59 2007
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Mon, 12 Nov 2007 21:21:59 +0200
Subject: F8 fresh install, fdisk shows /dev/dm-X devices
Message-ID: <3da3b5b40711121121k3ededdc7u456aa09f007db91@mail.gmail.com>

Hi,
I just installed F8 fresh installation. The previous system (where the LVM
volume where created was FC6). After I booted into F8. "fdisk -l" returns
unusual /dev/dm-? devices. These seem to be the LVM's physical volume
partitions. Not sure why they're being picked up here! Here's the full
output

 fdisk -l

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x1a581a57

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        2019    16217586    7  HPFS/NTFS
/dev/sda2            2020        9261    58171365    f  W95 Ext'd (LBA)
/dev/sda3            9262       14561    42572250   83  Linux
/dev/sda4           14562       14593      257040   88  Linux plaintext
/dev/sda5            2020        5206    25599546    b  W95 FAT32
/dev/sda6            5207        5510     2441848+  82  Linux swap / Solaris
/dev/sda7            5511        6726     9767488+  8e  Linux LVM
/dev/sda8            6727        7942     9767488+  8e  Linux LVM
/dev/sda9            7943        9248    10490413+  8e  Linux LVM
/dev/sda10           9249        9261      104391   83  Linux

Disk /dev/dm-0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/dm-1: 9995 MB, 9995026432 bytes
255 heads, 63 sectors/track, 1215 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/dm-1 doesn't contain a valid partition table

Disk /dev/dm-2: 9986 MB, 9986637824 bytes
255 heads, 63 sectors/track, 1214 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/dm-2 doesn't contain a valid partition table
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/79dcfdea/attachment.htm>

From markg85 at gmail.com  Mon Nov 12 19:55:47 2007
From: markg85 at gmail.com (Mark)
Date: Mon, 12 Nov 2007 20:55:47 +0100
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <7329.63.85.68.164.1194892971.squirrel@mail.jcomserv.net>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
	<20071112193723.6b05b1f5@lain.camperquake.de>
	<5136.63.85.68.164.1194892866.squirrel@mail.jcomserv.net>
	<7329.63.85.68.164.1194892971.squirrel@mail.jcomserv.net>
Message-ID: <6e24a8e80711121155n1d43ce64h3f75878d5265ee1@mail.gmail.com>

Why : "Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)" it
has nothing to do with the "Extension Buddy" discussion that i
started..



From fedora at camperquake.de  Mon Nov 12 19:58:53 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 20:58:53 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
Message-ID: <20071112205853.192382ed@lain.camperquake.de>

Hi.

On Sun, 11 Nov 2007 12:26:30 -0500, Dr. Diesel wrote
> This is perhaps a Mplayer or maybe PulseAudio problem, but maybe
> relevent.  About 1/2 way down Mplayer tells me my Core 2 Duo is not
> fast enough to play a small video!  This is a 100% fresh install of F8
> yesterday (+ all updates to date).  No problems with F7.  I also tried
> switching to ALSA as suggested by mplayer, but then I'm getting
> "Unable to find control PCM 0"

If it's any help, I am seeing the same. mplayer stutters on videos
it was able to play fine two weeks ago. vlc and xine work.

No pulseaudio, no compiz, alsa audio, xv video, rawhide as of yesterday.

Maybe an mplayer bug.



From fedora at camperquake.de  Mon Nov 12 20:05:43 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Nov 2007 21:05:43 +0100
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <20071112205853.192382ed@lain.camperquake.de>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112205853.192382ed@lain.camperquake.de>
Message-ID: <20071112210543.5931c335@lain.camperquake.de>

Hi.

On Mon, 12 Nov 2007 20:58:53 +0100, Ralf Ertzinger wrote

> No pulseaudio, no compiz, alsa audio, xv video, rawhide as of
> yesterday.
> 
> Maybe an mplayer bug.

Definitely something shot in the audio department.

-ao alsa stutters
-ao oss stutters
-ao pulse does not stutter (although there is no pulse daemon running,
          thus there is no sound)
-ao null stutters
-ao none does not stutter (this is actually an invalid option, go figure)
-nosound does not stutter

Whatever I am to make of that.



From lesmikesell at gmail.com  Mon Nov 12 20:19:08 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 12 Nov 2007 14:19:08 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194891205.27768.22.camel@rousalka.dyndns.org>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>	<47389323.6060004@gmail.com>
	<1194891205.27768.22.camel@rousalka.dyndns.org>
Message-ID: <4738B53C.6070503@gmail.com>

Nicolas Mailhot wrote:
> 
>> How does the 
>> kernel work?  That's one thing common to all distros that already has a 
>> distributed SCM.
> 
> Distros still use tarballs to build their kernel packages and even if
> they didn't the kernel is special: there are very few projects so
> central we know their SCM is not going to change or disappear suddenly.

Perhaps if you started by taking advantage of the kernel's situation, 
other things might adapt to the same conventions with a distributed SCM 
that can't disappear.

>>  > The huge
>>> nice property or release archives is they are scarce and not a
>>> continuum. That means everyone uses the same archives. A SCM feed is
>>> something else altogether: suddenly you're not using the same release
>>> as everyone else plus known patches, you're using a state others may
>>> not have picked, and you don't get the benefits of cross-distro
>>> testing (and annoyed upstreams because Fedora bugs are always
>>> different from other user bugs)
>> That should be a matter of appropriate tagging.
> 
> We can't even get all upstreams to agree on a common sane archive naming
> and numbering and you want us to posit they'll have sane SCM tagging
> conventions?

First someone has to propose a convention and demonstrate the advantages 
of using it.  Whether 'all' upstreams follow or not won't matter since 
you'll have to be able to deal with a mix of old/new techniques for any 
change anyway.  If there is an advantage and any follow you've gained 
something.

> And that does not change the fact even a perfect SCM offers many more
> pull points than a release archive process, so you still lose the
> "everyone tests the same version" effect.

Errr, fedora hardly seems like the right place to be complaining about 
other people's releases not being stable...

>> In most cases there 
>> would already be a direct mapping of SCM tags to tarball releases.
> 
> Quite the contrary, this is the exception not the rule. Most projects
> have tags that approximate releases, which is good enough for
> developers, but not for QA or audit trails.

I guess I'm surprised at that.

> Ironically Fedora cvs is one exception and that's only because koji will
> only build stuff when given a tag number, and generally speaking we have
> anal brutal dumb SCM procedures that force everyone to behave.

Yes, I've always considered the ability to reference things by tag name 
only and have it give consistent results to be almost the whole point of 
using the SCM, at least on the testing/release side of things.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From nphilipp at redhat.com  Mon Nov 12 20:19:51 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 12 Nov 2007 21:19:51 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <20071112200943.78a6bdb8@pensja.lam.pl>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
	<1194883648.2894.10.camel@localhost.localdomain>
	<20071112200943.78a6bdb8@pensja.lam.pl>
Message-ID: <1194898791.7922.10.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-12 at 20:09 +0100, Leszek Matok wrote:
> Dnia 2007-11-12, o godz. 11:07:28 Matthias Clasen <mclasen at redhat.com>
> napisa?(a):
> 
> > a) editor vs viewer
> True.
> 
> > b) inherited capabilities, ie totem can display any format gstreamer can
> > handle, which in turn depends on installed plugins
> Right now Totem claims to be able to play any multimedia files even though it
> really can't (because by default plugins for the most prominent formats like
> DVD aren't installed). The solution here is to switch
> MimeType=(...)
> into
> MimeTypeDir=/usr/lib/gstreamer-x.xx/mime.types.d
> and let plugins put appropriate files there (also, make the rpm macro
> understand the new flag). This way Nautilus (or rather some helper app) would
> know (from rpmdb or better, yum's cache), which package you have to install to
> be able to play a file in Totem (or any gstreamer application using my
> MimeTypeDir).

Something along that line sounds good if we want to stay with MIME
handler definition via desktop files. Perhaps this should accept more
than one path (like $PATH) for multiple backends.

An extension of the MIME type <-> app relation to differentiate between
viewers/listeners, editors and the like would still be needed.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From loupgaroublond at gmail.com  Mon Nov 12 20:32:49 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Mon, 12 Nov 2007 15:32:49 -0500
Subject: sending multiple (different) smolt profiles
In-Reply-To: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
Message-ID: <7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>

On Nov 12, 2007 3:54 AM, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> Hi,
>
> I have 2 laptops and I used the smoltSendProfile and I seem to get the
> same url for both laptops, ie. the later sent profile overwrites the
> previous one...
>
> I'm sending both profiles from same adsl line and I'm behing a NAT
> adsl router, so could this be an issue (same IP) ?
>
> Is this a feature or a bug?
>
> How can I send multiple laptop profiles and see them all online?
>

That URL is based off your "UUID" which is generated unique to smolt.
It's found in either /etc/smolt for most distros, or
/etc/sysconfig/hw-uuid.  if you copy this file around, then of course,
it's going to look like you're using the same machine.  UUID
management in the client needs a bit of work, but if you're looking
for a new UUID in a hurry, in our mercurial repository, there's an
install script for generating UUIDs.  Fetch it, make sure the source
puts the UUID where it should go for your distro, (the script is in
python, nothing terribly difficult), and run it.

Feel free to post back if you have trouble with this, and I'll type up
a longer step by step explanation.

Cheers,
Yaakov



From jam at zoidtechnologies.com  Mon Nov 12 20:33:18 2007
From: jam at zoidtechnologies.com (jam at zoidtechnologies.com)
Date: Mon, 12 Nov 2007 15:33:18 -0500
Subject: Random question about Koji's reporting of completion date vs.
	finished date
In-Reply-To: <e5f157b0711120438ybe43e77o5b3484d5d7cdda6d@mail.gmail.com>
References: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>
	<20071112072953.0fa70810@redhat.com>
	<e5f157b0711120438ybe43e77o5b3484d5d7cdda6d@mail.gmail.com>
Message-ID: <20071112203317.GA30600@zoidtechnologies.com>

On Mon, Nov 12, 2007 at 07:38:13AM -0500, Oisin Feeley wrote:
> > Uh, the build you linked to in [1] has a date of:       Fri, 21 Sep
> > 2007 01:19:30 MST
> >
> > And the list you linked to in [2] has an entry for
> > nspluginwrapper-0.9.91.5-3.fc8 that has a date of 2007-09-21 01:19:30
> >
> > How are these not the same dates?
> 
> Doh!  Sorry, I just read them incorrectly.  Apologies for the noise.
> 
> Oisin
> 

why aren't the dates presented in the same format for the two fields? or am
I missing something?

regards,
J
-- 
http://zoidtechnologies.com/ -- software that sucks less



From jkeating at redhat.com  Mon Nov 12 20:41:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 12 Nov 2007 15:41:42 -0500
Subject: Random question about Koji's reporting of completion date vs.
 finished date
In-Reply-To: <20071112203317.GA30600@zoidtechnologies.com>
References: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>
	<20071112072953.0fa70810@redhat.com>
	<e5f157b0711120438ybe43e77o5b3484d5d7cdda6d@mail.gmail.com>
	<20071112203317.GA30600@zoidtechnologies.com>
Message-ID: <20071112154142.1ef921c5@redhat.com>

On Mon, 12 Nov 2007 15:33:18 -0500
jam at zoidtechnologies.com wrote:

> why aren't the dates presented in the same format for the two fields?
> or am I missing something?

There could be a difference in how Koji is interpreting the db value.
Not a huge bug, but something to watch out for.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/7f36ef65/attachment.sig>

From tmraz at redhat.com  Mon Nov 12 20:46:30 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 12 Nov 2007 21:46:30 +0100
Subject: openssl097a package retirement
In-Reply-To: <3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
	<3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
Message-ID: <1194900390.17465.37.camel@vespa.kabelta.loc>

On Mon, 2007-11-12 at 23:04 +0530, Debarshi 'Rishi' Ray wrote:
> > 'Not necessarily'. It's why the soname changes.
> 
> That is why I asked. :-)
> 
> The comments in the HTTrack code say that it should be compatible with
> versions later than libssl.so.0.9.8. I have asked HTTrack upstream,
> and wanted to know if the openssl packager knew something about what
> might have changed or potential trouble spots. I am not familiar with
> the openssl code myself.

I think that you can safely patch it. But I'm curious why HTTrack
dlopens it and not directly links to it.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From mikeb at redhat.com  Mon Nov 12 20:53:04 2007
From: mikeb at redhat.com (Mike Bonnet)
Date: Mon, 12 Nov 2007 15:53:04 -0500
Subject: Random question about Koji's reporting of completion date vs.
	finished date
In-Reply-To: <20071112203317.GA30600@zoidtechnologies.com>
References: <e5f157b0711101240p3645571dw4cf24069f2458c27@mail.gmail.com>
	<20071112072953.0fa70810@redhat.com>
	<e5f157b0711120438ybe43e77o5b3484d5d7cdda6d@mail.gmail.com>
	<20071112203317.GA30600@zoidtechnologies.com>
Message-ID: <1194900784.2987.4.camel@burren.boston.redhat.com>

On Mon, 2007-11-12 at 15:33 -0500, jam at zoidtechnologies.com wrote:
> On Mon, Nov 12, 2007 at 07:38:13AM -0500, Oisin Feeley wrote:
> > > Uh, the build you linked to in [1] has a date of:       Fri, 21 Sep
> > > 2007 01:19:30 MST
> > >
> > > And the list you linked to in [2] has an entry for
> > > nspluginwrapper-0.9.91.5-3.fc8 that has a date of 2007-09-21 01:19:30
> > >
> > > How are these not the same dates?
> > 
> > Doh!  Sorry, I just read them incorrectly.  Apologies for the noise.
> > 
> > Oisin
> > 
> 
> why aren't the dates presented in the same format for the two fields? or am
> I missing something?

That's intentional.  The list view uses a more compact format so you can
squeeze more information into the same screen area.




From guhvies at gmail.com  Mon Nov 12 21:11:13 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 21:11:13 +0000
Subject: probs with nvidia sata
In-Reply-To: <a227b70c0711120526m5af432a0pfca81d07c9c40c97@mail.gmail.com>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
	<47384352.3030801@iinet.net.au>
	<a227b70c0711120526m5af432a0pfca81d07c9c40c97@mail.gmail.com>
Message-ID: <a227b70c0711121311h3e610c9bncfde1b80a3b7b9f5@mail.gmail.com>

On 12/11/2007, ne... <guhvies at gmail.com> wrote:
> This will have to wait till I get home tonight. Thanks for the pointers tho.
Finally got FC8 installed. I had to burn the boot.iso and use that. On
first boot from install it is stuck on:

Trying to resume from /dev/sda2

which is a swap partition.

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From tbrinkman at sbcglobal.net  Mon Nov 12 21:21:14 2007
From: tbrinkman at sbcglobal.net (Tom Brinkman)
Date: Mon, 12 Nov 2007 15:21:14 -0600
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <20071112210543.5931c335@lain.camperquake.de>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112205853.192382ed@lain.camperquake.de>
	<20071112210543.5931c335@lain.camperquake.de>
Message-ID: <200711121521.14901.tbrinkman@sbcglobal.net>

On Monday 12 November 2007 02:05:43 pm Ralf Ertzinger wrote:
> Hi.
>
> On Mon, 12 Nov 2007 20:58:53 +0100, Ralf Ertzinger wrote
>
> > No pulseaudio, no compiz, alsa audio, xv video, rawhide as of
> > yesterday.
> >
> > Maybe an mplayer bug.
>
> Definitely something shot in the audio department.
>
> -ao alsa stutters
> -ao oss stutters
> -ao pulse does not stutter (although there is no pulse daemon
> running, thus there is no sound)
> -ao null stutters
> -ao none does not stutter (this is actually an invalid option, go
> figure) -nosound does not stutter
>
> Whatever I am to make of that.

   No problems here with mplayer. Rawhide, duo-core, an none before 
with past AMD UP (3000+), since FC-4

   Mplayer (codecs)
*  Which for good reason is not shipped by Fedora
*  Besides the OP stated a non-devel install
*  Both of the above make this a non-Fedora, an certainly not  
   a -devel ML issue

   Seems odd to me that this question is similar to one that's been 
asked recently, also involving Fedora an PA at the proper place
http://www.mplayerhq.hu/design7/mailing_lists.html

-- 
    Tom Brinkman                       Corpus Christi, Texas



From cebbert at redhat.com  Mon Nov 12 22:05:50 2007
From: cebbert at redhat.com (Chuck Ebbert)
Date: Mon, 12 Nov 2007 17:05:50 -0500
Subject: probs with nvidia sata
In-Reply-To: <a227b70c0711121311h3e610c9bncfde1b80a3b7b9f5@mail.gmail.com>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>	<47384352.3030801@iinet.net.au>	<a227b70c0711120526m5af432a0pfca81d07c9c40c97@mail.gmail.com>
	<a227b70c0711121311h3e610c9bncfde1b80a3b7b9f5@mail.gmail.com>
Message-ID: <4738CE3E.8080406@redhat.com>

On 11/12/2007 04:11 PM, ne... wrote:
> On 12/11/2007, ne... <guhvies at gmail.com> wrote:
>> This will have to wait till I get home tonight. Thanks for the pointers tho.
> Finally got FC8 installed. I had to burn the boot.iso and use that. On
> first boot from install it is stuck on:
> 
> Trying to resume from /dev/sda2
> 
> which is a swap partition.
> 

Do you have a BSD partition on any disk? Resume apparently hangs when it
sees one.



From jima at beer.tclug.org  Mon Nov 12 22:07:56 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 12 Nov 2007 16:07:56 -0600 (CST)
Subject: sending multiple (different) smolt profiles
In-Reply-To: <7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>

On Mon, 12 Nov 2007, Yaakov Nemoy wrote:
> That URL is based off your "UUID" which is generated unique to smolt.
> It's found in either /etc/smolt for most distros, or
> /etc/sysconfig/hw-uuid.  if you copy this file around, then of course,
> it's going to look like you're using the same machine.  UUID
> management in the client needs a bit of work, but if you're looking
> for a new UUID in a hurry, in our mercurial repository, there's an
> install script for generating UUIDs.  Fetch it, make sure the source
> puts the UUID where it should go for your distro, (the script is in
> python, nothing terribly difficult), and run it.

  Or you could just use uuidgen(1) from the e2fsprogs package.

      Jima



From guhvies at gmail.com  Mon Nov 12 22:10:45 2007
From: guhvies at gmail.com (ne...)
Date: Mon, 12 Nov 2007 22:10:45 +0000
Subject: probs with nvidia sata
In-Reply-To: <4738CE3E.8080406@redhat.com>
References: <59845.192.54.193.53.1194864336.squirrel@rousalka.dyndns.org>
	<a227b70c0711120256i190c427dl4ecfd9ea546fbf87@mail.gmail.com>
	<47384352.3030801@iinet.net.au>
	<a227b70c0711120526m5af432a0pfca81d07c9c40c97@mail.gmail.com>
	<a227b70c0711121311h3e610c9bncfde1b80a3b7b9f5@mail.gmail.com>
	<4738CE3E.8080406@redhat.com>
Message-ID: <a227b70c0711121410i363eb345sf4c97f970dbc4bb2@mail.gmail.com>

On 12/11/2007, Chuck Ebbert <cebbert at redhat.com> wrote:
> On 11/12/2007 04:11 PM, ne... wrote:
> > On 12/11/2007, ne... <guhvies at gmail.com> wrote:
> >> This will have to wait till I get home tonight. Thanks for the pointers tho.
> > Finally got FC8 installed. I had to burn the boot.iso and use that. On
> > first boot from install it is stuck on:
> >
> > Trying to resume from /dev/sda2
> >
> > which is a swap partition.
> >
>
> Do you have a BSD partition on any disk? Resume apparently hangs when it
> sees one.
Bummer! One of my drives is dedicated FreeBSD. Thanks. I will keep an
eye out for fixes/workarounds.

ne...
-- 
Registered Linux User # 125653 (http://counter.li.org)
Certified: 75% bastard, 42% of which is tard.
http://www.thespark.com/bastardtest
Now accepting personal mail for GMail invites.



From Michael_E_Brown at dell.com  Mon Nov 12 22:12:19 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 12 Nov 2007 16:12:19 -0600
Subject: New mock logging
In-Reply-To: <4734F17F.1030905@cora.nwra.com>
References: <4734F17F.1030905@cora.nwra.com>
Message-ID: <20071112221219.GA14640@humbolt.us.dell.com>

On Fri, Nov 09, 2007 at 04:47:11PM -0700, Orion Poplawski wrote:
> How do I get rid of the:
> 
> 2007-11-09 16:46:03,285 - util.py:194:DEBUG:
> 
> prefix that seems to have appeared with mock 0.8 (0.8.4)?  At least from 
> the build.log.  Might be useful in the other logs...

Well, the problem I ran into was that the python logging module doesnt
provide a nice way to pull handlers/formatters from the config file by
name. The relevant code is in backend.py in the _resetLogging()
function.

On line 475, I set up the formatter. I can probably figure out a way to
put the format line in the config file, but for now it is hardcoded.
--
Michael



From dominik at greysector.net  Mon Nov 12 22:25:46 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 12 Nov 2007 23:25:46 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <20071112115237.250cf5bd@redhat.com>
References: <20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
	<20071112115237.250cf5bd@redhat.com>
Message-ID: <20071112222546.GE15670@ryvius.greysector.net>

On Monday, 12 November 2007 at 17:52, Jesse Keating wrote:
> On Mon, 12 Nov 2007 17:48:28 +0100
> Ralf Ertzinger <fedora at camperquake.de> wrote:
> 
> > On Mon, 12 Nov 2007 11:39:10 -0500, seth vidal wrote:
> > 
> > > Fluendo is not a business partner with the fedora project.  
> > 
> > So directing people to a vendor selling software is an act
> > of charity?
> 
> SO far, they're the only ones offering legal codecs for a large number
> of our users.  If you have more examples we can easily put them into
> the codeina build.

I can't speak for other countries, but in Poland, using Livna is perfectly
legal AFAIK. So I wouldn't want people in Poland to have Codeina redirect
them to some US webstore to buy proprietary stuff when they can get open
software for free.

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From nicolas.mailhot at laposte.net  Mon Nov 12 22:30:46 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Nov 2007 23:30:46 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <4738B53C.6070503@gmail.com>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>
	<47389323.6060004@gmail.com>
	<1194891205.27768.22.camel@rousalka.dyndns.org>
	<4738B53C.6070503@gmail.com>
Message-ID: <1194906646.27768.64.camel@rousalka.dyndns.org>


Le lundi 12 novembre 2007 ? 14:19 -0600, Les Mikesell a ?crit :
> Nicolas Mailhot wrote:

> > Ironically Fedora cvs is one exception and that's only because koji will
> > only build stuff when given a tag number, and generally speaking we have
> > anal brutal dumb SCM procedures that force everyone to behave.
> 
> Yes, I've always considered the ability to reference things by tag name 
> only and have it give consistent results to be almost the whole point of 
> using the SCM, at least on the testing/release side of things.

Well, that's the theory, in practice what's tested is the tarball that's
given to QA (internal QA in proprietary world, internet QA for FLOSS).
Unless projects have totally automated the SCM to tarball step, and have
very strong discipline that forbids massaging the tarball in something
suitable instead of fixing stuff in the SCM then re-starting the lengthy
automated export when small stuff is broken, SCM tag is only a release
approximation.

And when projects break up, or fold, the only part remaining (that can
still be packaged years later) are the tarballs that were mirrored on
code repository sites.

What developers "test" are SCM dumps build in an environment which has
usually little in common with the one production entities like Fedora
uses. Which does not mean developer testing is useless, just what you're
used to with direct SCM access and what Fedora does at packaging time
are two different things. One workflow emphasises re-build speed at the
expense of perfect reliability or reproducibility. The other emphasises
reliability and reproducibility at the expense of speed.

You usually need some time in a support/sysadmin position managing
systems built by developers from SCM dumps (or god forbid production
systems directly re-build from developer SCM-plugged RAD IDE
environments) to appreciate the difference. The developer just wants
direct access so he can quickly inject code fixes in case of bugs. The
sysadmin wants to nail the damn thing down. It does not matter if there
are bugs as long as they're known bugs and he can organise himself so
users do not call for help in the middle of the night (when developers
sleep). The organic uncontrolled continuously evolving system developers
typically dream of is his worst nightmare.

rpm is designed to protect the sysadmin, and help him nail down
developer code dumps. It limits what's needed to be trusted from
developer systems to the bare minimum (release archive plus standalone
patches) and enforces a process where changes are evolutionary and
small. And this is good. It's a beautiful design. Much better than every
system I've seen that tried the direct SCM-to-binary approach, and where
developer happiness was achieved at the expense of everyone else in the
ecosystem.

rpm formalism is an annoyance just like unix permissions are an
annoyance. Remove them and everything quickly spins out of control.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/00547954/attachment.sig>

From bpepple at fedoraproject.org  Mon Nov 12 22:31:41 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 12 Nov 2007 17:31:41 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <20071112222546.GE15670@ryvius.greysector.net>
References: <20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
	<20071112115237.250cf5bd@redhat.com>
	<20071112222546.GE15670@ryvius.greysector.net>
Message-ID: <1194906701.21396.3.camel@nixon>

On Mon, 2007-11-12 at 23:25 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 12 November 2007 at 17:52, Jesse Keating wrote:
> > 
> > SO far, they're the only ones offering legal codecs for a large number
> > of our users.  If you have more examples we can easily put them into
> > the codeina build.
> 
> I can't speak for other countries, but in Poland, using Livna is perfectly
> legal AFAIK. So I wouldn't want people in Poland to have Codeina redirect
> them to some US webstore to buy proprietary stuff when they can get open
> software for free.

Fluendo isn't a US company.

/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/0d7634df/attachment.sig>

From alexl at users.sourceforge.net  Mon Nov 12 22:38:53 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Mon, 12 Nov 2007 15:38:53 -0700
Subject: chain build in F-8
In-Reply-To: <1194876422.17950.14.camel@localhost.localdomain> (Jeremy Katz's
	message of "Mon\, 12 Nov 2007 09\:07\:02 -0500")
References: <20071112060414.GA4257@lisas.de>
	<1194854028.19003.2.camel@tuxhugs> <47381E20.2010506@poolshark.org>
	<1194876422.17950.14.camel@localhost.localdomain>
Message-ID: <afabpj84xu.fsf@allele2.eebweb.arizona.edu>

>>>>> "JK" == Jeremy Katz  writes:

JK> On Mon, 2007-11-12 at 01:34 -0800, Denis Leroy wrote:
>> I hit the same problem all the time with the gtkmm updates, which
>> are 3 to 4-deep dependency chains. How could we automate this ?
>> Having to mail rel-eng for this seems particularly inefficient, and
>> it's also a regression from the plague/FC-6 days...

JK> The plan iirc was that we get some tracking in bodhi to ensure
JK> that people don't try to push a stable update which was built
JK> against something which hasn't been pushed stable.  

Indeed:

https://hosted.fedoraproject.org/projects/bodhi/ticket/79

JK> Unfortunately, the number of people helping Luke out with things
JK> like in bodhi is not that large. :-/

Alex



From skvidal at fedoraproject.org  Mon Nov 12 22:37:22 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 12 Nov 2007 17:37:22 -0500
Subject: Codec Buddy misleading.
In-Reply-To: <1194906701.21396.3.camel@nixon>
References: <20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
	<20071112115237.250cf5bd@redhat.com>
	<20071112222546.GE15670@ryvius.greysector.net>
	<1194906701.21396.3.camel@nixon>
Message-ID: <1194907042.2025.17.camel@cutter>


On Mon, 2007-11-12 at 17:31 -0500, Brian Pepple wrote:
> On Mon, 2007-11-12 at 23:25 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Monday, 12 November 2007 at 17:52, Jesse Keating wrote:
> > > 
> > > SO far, they're the only ones offering legal codecs for a large number
> > > of our users.  If you have more examples we can easily put them into
> > > the codeina build.
> > 
> > I can't speak for other countries, but in Poland, using Livna is perfectly
> > legal AFAIK. So I wouldn't want people in Poland to have Codeina redirect
> > them to some US webstore to buy proprietary stuff when they can get open
> > software for free.
> 
> Fluendo isn't a US company.
> 

you'll notice the prices are in euros, even.

-sv




From dominik at greysector.net  Mon Nov 12 22:42:21 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 12 Nov 2007 23:42:21 +0100
Subject: Codec Buddy misleading.
In-Reply-To: <1194907042.2025.17.camel@cutter>
References: <20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
	<1194885550.2025.6.camel@cutter>
	<20071112174828.372637fd@dhcp03.addix.net>
	<20071112115237.250cf5bd@redhat.com>
	<20071112222546.GE15670@ryvius.greysector.net>
	<1194906701.21396.3.camel@nixon> <1194907042.2025.17.camel@cutter>
Message-ID: <20071112224221.GF15670@ryvius.greysector.net>

On Monday, 12 November 2007 at 23:37, seth vidal wrote:
> 
> On Mon, 2007-11-12 at 17:31 -0500, Brian Pepple wrote:
> > On Mon, 2007-11-12 at 23:25 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > On Monday, 12 November 2007 at 17:52, Jesse Keating wrote:
> > > > 
> > > > SO far, they're the only ones offering legal codecs for a large number
> > > > of our users.  If you have more examples we can easily put them into
> > > > the codeina build.
> > > 
> > > I can't speak for other countries, but in Poland, using Livna is perfectly
> > > legal AFAIK. So I wouldn't want people in Poland to have Codeina redirect
> > > them to some US webstore to buy proprietary stuff when they can get open
> > > software for free.
> > 
> > Fluendo isn't a US company.
> 
> you'll notice the prices are in euros, even.

Granted, my mistake, but my point is still valid.

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From orion at cora.nwra.com  Mon Nov 12 22:45:28 2007
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 12 Nov 2007 15:45:28 -0700
Subject: New mock logging
In-Reply-To: <20071112221219.GA14640@humbolt.us.dell.com>
References: <4734F17F.1030905@cora.nwra.com>
	<20071112221219.GA14640@humbolt.us.dell.com>
Message-ID: <4738D788.8030400@cora.nwra.com>

Michael E Brown wrote:
> On Fri, Nov 09, 2007 at 04:47:11PM -0700, Orion Poplawski wrote:
>> How do I get rid of the:
>>
>> 2007-11-09 16:46:03,285 - util.py:194:DEBUG:
>>
>> prefix that seems to have appeared with mock 0.8 (0.8.4)?  At least from 
>> the build.log.  Might be useful in the other logs...
> 
> Well, the problem I ran into was that the python logging module doesnt
> provide a nice way to pull handlers/formatters from the config file by
> name. The relevant code is in backend.py in the _resetLogging()
> function.
> 
> On line 475, I set up the formatter. I can probably figure out a way to
> put the format line in the config file, but for now it is hardcoded.

It is nearly impossible to decipher what is going on in the builds as it 
stands.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com



From choeger at cs.tu-berlin.de  Mon Nov 12 22:51:44 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=)
Date: Mon, 12 Nov 2007 23:51:44 +0100
Subject: bug or feature (default kernel kind)
Message-ID: <4738D900.4050002@cs.tu-berlin.de>

hi,

after removing my test-xen-kernel, kernel updates behaved strangely. 
Whenever there was a new kernel the old one was selected as boot-default.
After some hints I took a look at /etc/sysconfig/kernel where the line
UPDATEDEFAULT=yes
looked perfectly normal. But
DEFAULTKERNEL=kernel-xen
was strange (and propably the source of the misbehavior).

Shouldn't that line get reset, when the last xen-kernel gets removed?

regards

christoph



From fedora-gmane.00005 at genesis-x.nildram.co.uk  Mon Nov 12 22:51:50 2007
From: fedora-gmane.00005 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner)
Date: Mon, 12 Nov 2007 22:51:50 +0000
Subject: Custom F8 builds and respins
Message-ID: <4738D906.6070300@genesis-x.nildram.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm looking into producing a custom version of Fedora 8+, and I would
appreciate some advice.

My objectives are:

. Provide a subset of the current F8 tree
. Custom compiler optimisation of that full subset of packages
. New artwork
. A hosted repo: ISOs, RPMS, SRPMs, devel, multi-arch

I'm considering using the Amazon Elastic Compute Cloud (Amazon EC2) for
building, and I already have a host for the repo, so all that remains is
the details of the infrastructure.

If I've read the Wiki correctly, what I need is:

. A Fedora 8 Xen instance on EC2
. Koji
. bodhi
. mash
. The required subset of Fedora 8 sources (TBA)
. The necessary compiler toolchains
. The necessary buildrequires

After I have a repo with all of the rebuilt packages, what would I then
use to spin the ISOs? Just Revisor? Is that the recommended method, or
is that just for end-users rather than distro maintainers?

Any advice welcome.

Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org

iD8DBQFHONkGxdcNWr9DbskRAiigAJ9Sl8Qw+kfaKVcEqNzg6jhJIdPy0wCfc1E/
VCsPoyMNR5nxDUp1eBcI2Qk=
=eILl
-----END PGP SIGNATURE-----



From Michael_E_Brown at dell.com  Mon Nov 12 23:15:04 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 12 Nov 2007 17:15:04 -0600
Subject: New mock logging
In-Reply-To: <4738D788.8030400@cora.nwra.com>
References: <4734F17F.1030905@cora.nwra.com>
	<20071112221219.GA14640@humbolt.us.dell.com>
	<4738D788.8030400@cora.nwra.com>
Message-ID: <20071112231504.GB14640@humbolt.us.dell.com>

On Mon, Nov 12, 2007 at 03:45:28PM -0700, Orion Poplawski wrote:
> Michael E Brown wrote:
> >On Fri, Nov 09, 2007 at 04:47:11PM -0700, Orion Poplawski wrote:
> >>How do I get rid of the:
> >>
> >>2007-11-09 16:46:03,285 - util.py:194:DEBUG:
> >>
> >>prefix that seems to have appeared with mock 0.8 (0.8.4)?  At least from 
> >>the build.log.  Might be useful in the other logs...
> >
> >Well, the problem I ran into was that the python logging module doesnt
> >provide a nice way to pull handlers/formatters from the config file by
> >name. The relevant code is in backend.py in the _resetLogging()
> >function.
> >
> >On line 475, I set up the formatter. I can probably figure out a way to
> >put the format line in the config file, but for now it is hardcoded.
> 
> It is nearly impossible to decipher what is going on in the builds as it 
> stands.

I've made it configurable for the next release (0.8.8), and it is
checked into the upstream git repo. I dont intend to make another
release for another week or so. If you want the new logging, please
check out git. (./configure && make rpm).

The default will be per your original request (build log is unadorned.)
--
Michael



From Michael_E_Brown at dell.com  Mon Nov 12 23:20:41 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 12 Nov 2007 17:20:41 -0600
Subject: New mock logging
In-Reply-To: <20071112231504.GB14640@humbolt.us.dell.com>
References: <4734F17F.1030905@cora.nwra.com>
	<20071112221219.GA14640@humbolt.us.dell.com>
	<4738D788.8030400@cora.nwra.com>
	<20071112231504.GB14640@humbolt.us.dell.com>
Message-ID: <20071112232041.GC14640@humbolt.us.dell.com>

On Mon, Nov 12, 2007 at 05:15:04PM -0600, Michael E Brown wrote:
> On Mon, Nov 12, 2007 at 03:45:28PM -0700, Orion Poplawski wrote:
> > Michael E Brown wrote:
> > >On Fri, Nov 09, 2007 at 04:47:11PM -0700, Orion Poplawski wrote:
> > >>How do I get rid of the:
> > >>
> > >>2007-11-09 16:46:03,285 - util.py:194:DEBUG:
> > >>
> > >>prefix that seems to have appeared with mock 0.8 (0.8.4)?  At least from 
> > >>the build.log.  Might be useful in the other logs...
> > >
> > >Well, the problem I ran into was that the python logging module doesnt
> > >provide a nice way to pull handlers/formatters from the config file by
> > >name. The relevant code is in backend.py in the _resetLogging()
> > >function.
> > >
> > >On line 475, I set up the formatter. I can probably figure out a way to
> > >put the format line in the config file, but for now it is hardcoded.
> > 
> > It is nearly impossible to decipher what is going on in the builds as it 
> > stands.
> 
> I've made it configurable for the next release (0.8.8), and it is
> checked into the upstream git repo. I dont intend to make another
> release for another week or so. If you want the new logging, please
> check out git. (./configure && make rpm).
> 
> The default will be per your original request (build log is unadorned.)

Sorry to reply to myself, but I forgot to mention the config option
names (new for 0.8.8):

$ grep fmt /etc/mock/defaults.cfg 
# config_opts['build_log_fmt_name'] = "unadorned"
# config_opts['root_log_fmt_name']  = "detailed"
# config_opts['state_log_fmt_name'] = "state"

Where 'unadorned', 'state', and 'detailed' are names of formatters from
/etc/mock/logging.ini (or whatever log config file you have specified in
config_opts['log_config_file'])
--
Michael



From lmacken at redhat.com  Mon Nov 12 23:23:15 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 12 Nov 2007 18:23:15 -0500
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <200711121957.31902.opensource@till.name>
References: <20071112180131.GT11043@crow.myhome.westell.com>
	<200711121957.31902.opensource@till.name>
Message-ID: <20071112232315.GU11043@crow.myhome.westell.com>

On Mon, Nov 12, 2007 at 07:57:19PM +0100, Till Maas wrote:
> On Mo November 12 2007, Luke Macken wrote:
> > Attached is a patch to add an 'update' target to our common Makefile.
> > When executed in a branch supported by bodhi (F-{7,8}), it will drop
> > you into a template and then submit your update to bodhi.
> >
> > Comments/suggestions welcome,
> 
> Is there a package for the bodhi client? I cannot find one with either "yum 
> whatprovides *bodhi" or "yum search bodhi".

bodhi-{client,server} will hit updates-testing tonight once this push is
complete.

luke



From lesmikesell at gmail.com  Tue Nov 13 00:08:36 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 12 Nov 2007 18:08:36 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194906646.27768.64.camel@rousalka.dyndns.org>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>	<47389323.6060004@gmail.com>	<1194891205.27768.22.camel@rousalka.dyndns.org>	<4738B53C.6070503@gmail.com>
	<1194906646.27768.64.camel@rousalka.dyndns.org>
Message-ID: <4738EB04.6090501@gmail.com>

Nicolas Mailhot wrote:
> Le lundi 12 novembre 2007 ? 14:19 -0600, Les Mikesell a ?crit :
>> Nicolas Mailhot wrote:
> 
>>> Ironically Fedora cvs is one exception and that's only because koji will
>>> only build stuff when given a tag number, and generally speaking we have
>>> anal brutal dumb SCM procedures that force everyone to behave.
>> Yes, I've always considered the ability to reference things by tag name 
>> only and have it give consistent results to be almost the whole point of 
>> using the SCM, at least on the testing/release side of things.
> 
> Well, that's the theory, in practice what's tested is the tarball that's
> given to QA (internal QA in proprietary world, internet QA for FLOSS).
> Unless projects have totally automated the SCM to tarball step, and have
> very strong discipline that forbids massaging the tarball in something
> suitable instead of fixing stuff in the SCM then re-starting the lengthy
> automated export when small stuff is broken, SCM tag is only a release
> approximation.

The key to making it work is to make the tag name the only thing that 
can pass between the developer, the QA approver and the release deployer 
so they all have to be using the same thing.  That can be arranged by 
mandate from the right person in a proprietary environment - but the 
best you'll probably do with internet development is to glue a bug 
tracker to the revision number.

> And when projects break up, or fold, the only part remaining (that can
> still be packaged years later) are the tarballs that were mirrored on
> code repository sites.

Couldn't that be equally true of distributed SCMs?

> You usually need some time in a support/sysadmin position managing
> systems built by developers from SCM dumps (or god forbid production
> systems directly re-build from developer SCM-plugged RAD IDE
> environments) to appreciate the difference.

I do know the difference - a company where I worked for years had one 
group that was religious about deployment builds being based strictly on 
tags and the SCM containing everything necessary for the build and 
another that did a lot of hand tweaking and could only do the build on 
one machine that nobody remembered how to reconstruct.  A patient QA 
dept. was the only thing that let the latter group survive.

> rpm is designed to protect the sysadmin, and help him nail down
> developer code dumps. It limits what's needed to be trusted from
> developer systems to the bare minimum (release archive plus standalone
> patches) and enforces a process where changes are evolutionary and
> small. And this is good. It's a beautiful design. Much better than every
> system I've seen that tried the direct SCM-to-binary approach, and where
> developer happiness was achieved at the expense of everyone else in the
> ecosystem.

An SCM-to-binary mechanism that only deployed QA-tagged versions should 
be indistinguishable from ones that nail released content in other ways.
You seem to be equating QA/testing with a deployment mechanism which is 
just coincidental.

> rpm formalism is an annoyance just like unix permissions are an
> annoyance. Remove them and everything quickly spins out of control.

But RPM is barely enough and only works in a forward direction.  Maybe 
the place to really take advantage of SCM features would be to let one 
manage the installed package lists as part of the OS functionality, and 
teach yum to go backwards or forwards so you would have a way to 
duplicate another machine's installed state or a prior one.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From poelstra at redhat.com  Tue Nov 13 00:24:08 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 12 Nov 2007 16:24:08 -0800
Subject: pptp-linux (pptp) on a Fedora DVD
In-Reply-To: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
References: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
Message-ID: <4738EEA8.8080503@redhat.com>

Kevac Marko wrote:
> Hello.
> 
> Here, in Russian Federation, 90% of home internet providers use PPTP
> for the internet access.
> So 80% of Fedora users from Russian Federation have same problem of
> installing and configuring pptp client. It includes very unpleasant
> "go to another box with internet connection, download rpm package, go
> back and install it".
> 
> I don't know what situation is in another countries with pptp, but i
> be very glad to see pptp client on a Fedora DVD.
> 
> So, questions are:
> 1. Why pptp package is still not there? Some license issues?
> 2. Will it be included in Fedora DVD?
> 3. How can i help?
> 

You could help by creating a feature page which focus on including the 
package and smoothing out other configuration issues.  It sounds like 
this enhancement could benefit a lot of users :)

http://fedoraproject.org/wiki/Features/Policy

If you need help with creating a feature page, please let me know.

John



From david at fubar.dk  Tue Nov 13 00:27:46 2007
From: david at fubar.dk (David Zeuthen)
Date: Mon, 12 Nov 2007 19:27:46 -0500
Subject: Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)
In-Reply-To: <6e24a8e80711121155n1d43ce64h3f75878d5265ee1@mail.gmail.com>
References: <24047.192.54.193.53.1194885029.squirrel@rousalka.dyndns.org>
	<1194886237.29655.9.camel@oneill.fubar.dk>
	<1194889624.27768.8.camel@rousalka.dyndns.org>
	<21775.63.85.68.164.1194889994.squirrel@mail.jcomserv.net>
	<20071112193723.6b05b1f5@lain.camperquake.de>
	<5136.63.85.68.164.1194892866.squirrel@mail.jcomserv.net>
	<7329.63.85.68.164.1194892971.squirrel@mail.jcomserv.net>
	<6e24a8e80711121155n1d43ce64h3f75878d5265ee1@mail.gmail.com>
Message-ID: <1194913666.29655.88.camel@oneill.fubar.dk>


On Mon, 2007-11-12 at 20:55 +0100, Mark wrote:
> Why : "Broken mailers (Was Re: "Extension Buddy" for Fedora 9?)" it
> has nothing to do with the "Extension Buddy" discussion that i
> started..

That's, uh, why I changed the Subject line which is customary when one
changes the topic of a thread or wants to focus on a particular topic in
a sub-thread. Since threading was broken already it's kinda hard to
accuse me for hijacking a thread :-)

     David

p.s. : Mark, also please keep in mind fedora-devel-list is about
"Development discussions related to Fedora" not "I've got this shiny
idea that I think is really great, someone please implement it". In
other words, you should consider posting to fedora-list instead of this
list. Thanks.




From poelstra at redhat.com  Tue Nov 13 00:31:54 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 12 Nov 2007 16:31:54 -0800
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194549299.10285.5.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>	<47334F0F.5030106@fedoraproject.org>
	<1194549299.10285.5.camel@jndwidescreen.lesbg.loc>
Message-ID: <4738F07A.500@redhat.com>

Jonathan Dieter wrote:
> On Thu, 2007-11-08 at 23:31 +0530, Rahul Sundaram wrote:
>> Jonathan Dieter wrote:
>>> Within the next five or six hours, there should be deltarpms available
>>> for upgrading from Fedora 7 to Fedora 8 using yum-presto.  More details
>>> when they become available.
>> Great. Is this planned to be default for Fedora 9?
>>
> 
> I really hope so.  The real issue is that the build system needs to be
> set up to generate the deltarpms and I don't know koji/bodhi.
> 
> The idea is that when the buildsystem is able to generate deltarpms
> (hopefully very soon), we'll start making the official repositories
> presto-enabled.  *If* we don't have any problems, we *may* then make it
> the default for Fedora 9.
> 
> Jonathan
> 

Sounds like a definite Feature worth tracking and getting some attention 
drawn to it.

http://fedoraproject.org/wiki/Features/Policy

Let me know if you help with the feature page creation.

John





From cra at WPI.EDU  Tue Nov 13 00:46:37 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 12 Nov 2007 19:46:37 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
Message-ID: <20071113004637.GY4926@angus.ind.WPI.EDU>

TFTP is often used to store firmware images and configuration files 
for embedded devices, and as a place for such devices to write crash 
dumps, log files, etc.

FHS 2.3 is silent on where to put files served up by TFTP.  Currently, 
we set the TFTP root to /tftpboot.  This seems suboptimal for a few 
reasons:

1. The root directory might be read-only on the TFTP server, so it 
isn't a good place to put the TFTP root.

2. The root directory might be too small to store lots of log files, 
huge crash dumps, etc.

3. It really makes no sense to have a separate top-level directory for 
the TFTP service.  /tftpboot is a legacy location that should be 
reconsidered.

4. tftp"boot" doesn't fit all use cases.  It isn't used exclusively 
during booting of these devices.

For many years, I've used /var/tftp as a location for storing TFTP 
data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
suggest we change the default configuration in /etc/xinetd.d/tftp to 
reflect this.

At the very least, we should update the selinux-policy to allow 
/var/tftp as an alternate location.  Interestingly, it appears that 
the current policy allows in.tftpd to read var_t, since I haven't 
fixed the contexts on my servers and it is still able to read files:

>ls -ldZ /tftpboot
drwxr-xr-x  root root system_u:object_r:tftpdir_t      /tftpboot/

>ls -ldZ /var/tftp
drwxrwsr-x  tftp tftp user_u:object_r:var_t            /var/tftp/



From dennis at ausil.us  Tue Nov 13 00:59:30 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Mon, 12 Nov 2007 18:59:30 -0600
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113004637.GY4926@angus.ind.WPI.EDU>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
Message-ID: <200711121859.32629.dennis@ausil.us>

On Monday 12 November 2007, Chuck Anderson wrote:
> TFTP is often used to store firmware images and configuration files
> for embedded devices, and as a place for such devices to write crash
> dumps, log files, etc.
>
> FHS 2.3 is silent on where to put files served up by TFTP.  Currently,
> we set the TFTP root to /tftpboot.  This seems suboptimal for a few
> reasons:
>
> 1. The root directory might be read-only on the TFTP server, so it
> isn't a good place to put the TFTP root.
90% of people use tftp-server to serve up data for network boots/install 

> 2. The root directory might be too small to store lots of log files,
> huge crash dumps, etc.

If your doing something like this your smart enough to change the location to 
an appropriate place that suits your needs

> 3. It really makes no sense to have a separate top-level directory for
> the TFTP service.  /tftpboot is a legacy location that should be
> reconsidered.
Its a common recognizable default

> 4. tftp"boot" doesn't fit all use cases.  It isn't used exclusively
> during booting of these devices.

I use tftp fortwo reasons  netbooting machines and saving switch/router 
configs.  It is not often i do use it for saving  its generally read only/

> For many years, I've used /var/tftp as a location for storing TFTP
> data.  This mirrors the use of /var/ftp and /var/www.  I therefore
> suggest we change the default configuration in /etc/xinetd.d/tftp to
> reflect this.

a more appropriate place would be /srv/tftp 



> At the very least, we should update the selinux-policy to allow
> /var/tftp as an alternate location.  Interestingly, it appears that
> the current policy allows in.tftpd to read var_t, since I haven't
file a bug :)




From pertusus at free.fr  Tue Nov 13 01:09:10 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Nov 2007 02:09:10 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113004637.GY4926@angus.ind.WPI.EDU>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
Message-ID: <20071113010910.GC2651@free.fr>

On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
> 
> For many years, I've used /var/tftp as a location for storing TFTP 
> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
> suggest we change the default configuration in /etc/xinetd.d/tftp to 
> reflect this.

FHS says:

Applications must generally not add directories to the top level of
/var. Such directories should only be added if they have some
system-wide implication, and in consultation with the FHS mailing list.

Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
for what should be in /var/lib, but it is not clearly wrong either.

--
Pat



From ndbecker2 at gmail.com  Tue Nov 13 01:15:17 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 12 Nov 2007 20:15:17 -0500
Subject: fedora.com, is this for real?
Message-ID: <fhatr5$6t6$1@ger.gmane.org>

Uh, is this for real or what?

http://www.fedora.com/



From buildsys at fedoraproject.org  Tue Nov 13 02:11:12 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Mon, 12 Nov 2007 21:11:12 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-12
Message-ID: <20071113021112.06D4615212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 12

    bcfg2-0.9.5-2.fc6
    fmio-2.0.8-10.fc6
    haproxy-1.3.12.4-1.fc6
    mksh-32-1.fc6
    nas-1.9.1-2.fc6
    nginx-0.5.33-2.fc6
    perl-PDF-API2-0.66-1.fc6
    plone-3.0.3-1.fc6
    python-biopython-1.44-2.fc6
    python-fedora-0.2.90.20-4.fc6
    python-minihallib-0.1.10-1.fc6
    wqy-bitmap-fonts-0.9.9-0.fc6


Changes in Fedora Extras 6: 


bcfg2-0.9.5-2.fc6
-----------------
* Mon Nov 12 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-2
- Fix oops.

* Mon Nov 12 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-1
- Update to 0.9.5 final.

* Mon Nov 05 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-0.5.pre7
- Commit new patches to CVS.

* Mon Nov 05 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-0.4.pre7
- Update to 0.9.5pre7

* Wed Jun 27 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.4-4
- Oops, apply right patch

* Wed Jun 27 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.4-3
- Add patch to fix YUMng problem

fmio-2.0.8-10.fc6
-----------------
* Sun Nov 11 2007 Andy Shevchenko <andy at smile.org.ua> 2.0.8-10
- do not require WindowMaker for GUI part (#222758)
- do not build drivers with direct I/O (#205721)

haproxy-1.3.12.4-1.fc6
----------------------
* Mon Nov 05 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 1.3.12.4-1
- update to 1.3.12.4

* Thu Nov 01 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 1.3.12.3-1
- update to 1.3.12.3

* Fri Sep 21 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 1.3.12.2-3
- fix init script 'reload' task

mksh-32-1.fc6
-------------
* Sat Nov 10 2007 Robert Scheck <robert at fedoraproject.org> 32-1
- Upgrade to 32
- Solved fork problems in %check (thanks to Thorsten Glaser)

nas-1.9.1-2.fc6
---------------
* Sun Nov 11 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9.1-2
- fix spec file

* Sun Nov 11 2007 Frank B?ttner  <frank-buettner at gmx.net> - 1.9.1-1
- update to 1.9.1
 - remove unneeded patches

nginx-0.5.33-2.fc6
------------------
* Mon Nov 12 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 0.5.33-2
- bump build number

* Mon Nov 12 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 0.5.33-1
- update to 0.5.33
- fixed rpmlint UTF-8 complaints.
- added --with-http_stub_status_module build option
- added --with-http_sub_module build option.
- added use of pcre-config --cflags
- specify license is BSD

perl-PDF-API2-0.66-1.fc6
------------------------
* Mon Nov 12 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.66-1
- 0.66

plone-3.0.3-1.fc6
-----------------
* Sun Nov 11 2007 Jonathan Steffan <jon a fedoraunity.org> 3.0.3-1
- Update to plone 3.0.3
- Remove hotfix 20071106 as it's included in 3.0.3

python-biopython-1.44-2.fc6
---------------------------
* Sun Oct 28 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.44-2
- Drop patch to setup.py, applied upstream

* Sun Oct 28 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.44-1
- Update to latest upstream (1.44).

* Mon Aug 27 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.43-5
- Used "MIT" as short license name as the "Biopython License
  Agreement" is the same as the CMU MIT variant.

python-fedora-0.2.90.20-4.fc6
-----------------------------
* Sat Nov 10 2007 Luke Macken <lmacken at redhat.com> - 0.2.90.20-4
- Fix SQLAlchemy requirement for FC-6

* Wed Nov 07 2007 Luke Macken <lmacken at redhat.com> - 0.2.90.20-2
- Require SQLAlchemy 0.3 for python-fedora-infrastructure

* Wed Nov 07 2007 Luke Macken <lmacken at redhat.com> - 0.2.90.20-1
- Latest upstream release

python-minihallib-0.1.10-1.fc6
------------------------------
* Sun Nov 11 2007 Andy Shevchenko <andy at smile.org.ua> 0.1.10-1
- update to the last release

wqy-bitmap-fonts-0.9.9-0.fc6
----------------------------
* Sat Nov 10 2007 Qianqian Fang <fangqq at gmail.com> 0.9.9-0
- include the complete CJK Extension A glyphs (6,582 x 4 point sizes), provide full coverage to Standard GB18030
- first round standard-compliance validation for all CJK basic characters between U4E00-U9FA5
- numerous bitmap glyph fine-tuning and corrections



From smooge at gmail.com  Tue Nov 13 02:24:01 2007
From: smooge at gmail.com (Stephen John Smoogen)
Date: Mon, 12 Nov 2007 19:24:01 -0700
Subject: fedora.com, is this for real?
In-Reply-To: <fhatr5$6t6$1@ger.gmane.org>
References: <fhatr5$6t6$1@ger.gmane.org>
Message-ID: <80d7e4090711121824q5f5900a1q515684b6e2272b88@mail.gmail.com>

On Nov 12, 2007 6:15 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> Uh, is this for real or what?
>
> http://www.fedora.com/
>

It looks like Network Solutions is back into the domain squatting again

Domain Administrator
   ATTN: FEDORA.COM
   c/o Network Solutions
   P.O. Box 447
   Herndon, VA.  20172-0447


   Domain Name: FEDORA.COM

   Administrative Contact, Technical Contact:
      Domain Administrator  r89b75bq24q at networksolutionsprivateregistration.com
      ATTN: FEDORA.COM
      c/o Network Solutions
      P.O. Box 447
      Herndon, VA 20172-0447
      570-708-8780


   Record expires on 30-Jan-2008.
   Record created on 29-Jul-2006.
   Bulk whois optout: N
   Database last updated on 12-Nov-2007 21:23:13 EST.

   Domain servers in listed order:

   A.NS.ULTSEARCH.COM           66.116.109.47
   B.NS.ULTSEARCH.COM           66.116.109.48

This listing is a Network Solutions Private Registration. Mail correspondence
to this address must be sent via USPS Express Mail(TM) or USPS Certified
Mail(R); all other mail will not be processed. Be sure to include the
registrant's domain name in the address.



Results brought to you by the GeekTools WHOIS Proxy
Server results may be copyrighted and are used with permission.
Your host (66.93.220.253) has visited 1 times today.




-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From peter at thecodergeek.com  Tue Nov 13 03:37:57 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 12 Nov 2007 19:37:57 -0800
Subject: rpms/tasks/devel .cvsignore, 1.8, 1.9 sources, 1.8, 1.9
	tasks.spec,  1.10, 1.11
In-Reply-To: <200711130319.lAD3JTNx028488@cvs-int.fedora.redhat.com>
References: <200711130319.lAD3JTNx028488@cvs-int.fedora.redhat.com>
Message-ID: <1194925077.30963.1.camel@tuxhugs>

On Mon, 2007-11-12 at 22:19 -0500, Daniel M. Young wrote:
> Modified Files:
> 	.cvsignore sources tasks.spec 
> Log Message:
> New upstream version: tasks-0.12

Don't forget to "cvs add" and commit the patch, too. Otherwise, Koji
won't be able to properly create the SRPM when when you attempt to build
it. 

Thanks.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071112/958ebb18/attachment.sig>

From sundaram at fedoraproject.org  Tue Nov 13 03:34:33 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 13 Nov 2007 09:04:33 +0530
Subject: Custom F8 builds and respins
In-Reply-To: <4738D906.6070300@genesis-x.nildram.co.uk>
References: <4738D906.6070300@genesis-x.nildram.co.uk>
Message-ID: <47391B49.4020002@fedoraproject.org>

Keith G. Robertson-Turner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm looking into producing a custom version of Fedora 8+, and I would
> appreciate some advice.
> 
> My objectives are:
> 
> . Provide a subset of the current F8 tree
> . Custom compiler optimisation of that full subset of packages

This might be a sore point for a custom spin.

> . New artwork
> . A hosted repo: ISOs, RPMS, SRPMs, devel, multi-arch
> 
> I'm considering using the Amazon Elastic Compute Cloud (Amazon EC2) for
> building, and I already have a host for the repo, so all that remains is
> the details of the infrastructure.
> 
> If I've read the Wiki correctly, what I need is:
> 
> . A Fedora 8 Xen instance on EC2
> . Koji
> . bodhi
> . mash
> . The required subset of Fedora 8 sources (TBA)
> . The necessary compiler toolchains
> . The necessary buildrequires
> 
> After I have a repo with all of the rebuilt packages, what would I then
> use to spin the ISOs? Just Revisor? Is that the recommended method, or
> is that just for end-users rather than distro maintainers?

You can use either Pungi or livecd-creator too. AFAIK, those are the 
tools recommended by the release engineering team simply because that is 
what they themselves use to produce Fedora releases. Assuming you are 
aiming for a custom spin hosted by Fedora, regardless of the tools, the 
deliverable is a kickstart file that we can run through the process. Refer

http://fedoraproject.org/wiki/Infrastructure/CustomSpins

I have a inclination about the kind of spin you are shooting for and 
more details would be nice since I might be interested in participating.

Rahul



From wtogami at redhat.com  Tue Nov 13 03:45:51 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 12 Nov 2007 22:45:51 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113010910.GC2651@free.fr>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr>
Message-ID: <47391DEF.7060508@redhat.com>

Patrice Dumas wrote:
> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
>> For many years, I've used /var/tftp as a location for storing TFTP 
>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
>> reflect this.
> 
> FHS says:
> 
> Applications must generally not add directories to the top level of
> /var. Such directories should only be added if they have some
> system-wide implication, and in consultation with the FHS mailing list.
> 
> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
> for what should be in /var/lib, but it is not clearly wrong either.
> 
> --
> Pat
> 

Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?

If so, I suppose our selinux-policy should handle both /tftpboot and 
this new location to allow for a smooth transition.

Warren Togami
wtogami at redhat.com



From mastahnke at gmail.com  Tue Nov 13 03:56:33 2007
From: mastahnke at gmail.com (Michael Stahnke)
Date: Mon, 12 Nov 2007 21:56:33 -0600
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <47391DEF.7060508@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
Message-ID: <7874d9dd0711121956k28b78f64ld0d0a8530ff58858@mail.gmail.com>

On Nov 12, 2007 9:45 PM, Warren Togami <wtogami at redhat.com> wrote:
> Patrice Dumas wrote:
> > On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
> >> For many years, I've used /var/tftp as a location for storing TFTP
> >> data.  This mirrors the use of /var/ftp and /var/www.  I therefore
> >> suggest we change the default configuration in /etc/xinetd.d/tftp to
> >> reflect this.
> >
> > FHS says:
> >
> > Applications must generally not add directories to the top level of
> > /var. Such directories should only be added if they have some
> > system-wide implication, and in consultation with the FHS mailing list.
> >
> > Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
> > for what should be in /var/lib, but it is not clearly wrong either.
> >
> > --
> > Pat
> >
>
> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
>
> If so, I suppose our selinux-policy should handle both /tftpboot and
> this new location to allow for a smooth transition.
>
> Warren Togami
> wtogami at redhat.com
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Just my opinion, but I think /srv/tftp makes sense.  /srv/* isn't
owned by any rpm packages (that I know of) so just creating top-level
directories should be ok.  I thought /srv was for serving out content.
 I think tftp serves out content.   I know some people dislike /srv
all-together, but it's seems like it's here, we should use it.

stahnma



From myfedora at richip.dhs.org  Tue Nov 13 04:20:28 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Mon, 12 Nov 2007 21:20:28 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <47391DEF.7060508@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
Message-ID: <1194927628.6083.3.camel@localhost6.localdomain6>

On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:
> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
> 
> If so, I suppose our selinux-policy should handle both /tftpboot and 
> this new location to allow for a smooth transition.

I would suggest /srv/tftpboot/. If not that, then I really can't think
of any other place. There's no lib to put in /var/lib/. /var/cache/
sounds too temporary. /var/share/? Is there such a thing?

Please, please, please rethink touching /srv/ ... even if you must
use /srv/fedora/<services> if you're afraid of namespace conflicts.
--

Richi Plana



From wtogami at redhat.com  Tue Nov 13 04:35:14 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 12 Nov 2007 23:35:14 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1194927628.6083.3.camel@localhost6.localdomain6>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>	<20071113010910.GC2651@free.fr>
	<47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
Message-ID: <47392982.4010800@redhat.com>

Richi Plana wrote:
> On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:
>> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
>>
>> If so, I suppose our selinux-policy should handle both /tftpboot and 
>> this new location to allow for a smooth transition.
> 
> I would suggest /srv/tftpboot/. If not that, then I really can't think
> of any other place. There's no lib to put in /var/lib/. /var/cache/
> sounds too temporary. /var/share/? Is there such a thing?

/var/lib/mysql contains no lib, just data.
/tftpboot contains executable code most of the time.

Warren Togami
wtogami at redhat.com



From myfedora at richip.dhs.org  Tue Nov 13 04:47:33 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Mon, 12 Nov 2007 21:47:33 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <47392982.4010800@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<47392982.4010800@redhat.com>
Message-ID: <1194929253.6083.6.camel@localhost6.localdomain6>

On Mon, 2007-11-12 at 23:35 -0500, Warren Togami wrote:
> Richi Plana wrote:
> > On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:
> >> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
> >>
> >> If so, I suppose our selinux-policy should handle both /tftpboot and 
> >> this new location to allow for a smooth transition.
> > 
> > I would suggest /srv/tftpboot/. If not that, then I really can't think
> > of any other place. There's no lib to put in /var/lib/. /var/cache/
> > sounds too temporary. /var/share/? Is there such a thing?
> 
> /var/lib/mysql contains no lib, just data.
> /tftpboot contains executable code most of the time.

Personally, I've never liked that either. I put my database
in /home/postgres/. But if Fedora decides to standardize on /srv/, I'll
revert to default. I can't wait for the time when all server data will
reside in one root subdirectory.
--

Richi Plana



From fedora-gmane.00005 at genesis-x.nildram.co.uk  Tue Nov 13 05:24:37 2007
From: fedora-gmane.00005 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner)
Date: Tue, 13 Nov 2007 05:24:37 +0000
Subject: Custom F8 builds and respins
In-Reply-To: <47391B49.4020002@fedoraproject.org>
References: <4738D906.6070300@genesis-x.nildram.co.uk>
	<47391B49.4020002@fedoraproject.org>
Message-ID: <m1pn05-ckr.ln1@sky.matrix>

Verily I say unto thee, that Rahul Sundaram spake thusly:
> Keith G. Robertson-Turner wrote:

>> . Custom compiler optimisation of that full subset of packages
> 
> This might be a sore point for a custom spin.

I'm looking at arch specific opts rather than aggressive opts, but yes
there are bound to be occasional hiccups. What doesn't build first time
will be logged and marked for review (by me or anyone else who wants to
volunteer). I'll get a minimal system at least installable and working,
then take it from there.

I'm not sure how well *rebuilding* fits in with the current respin
procedure, since I would imagine that respins are typically just
reassemblies of binary packages, but rebuilding is central to my goal,
so one way or another that's what I need to do.

>> After I have a repo with all of the rebuilt packages, what would I 
>> then use to spin the ISOs? Just Revisor? Is that the recommended 
>> method, or is that just for end-users rather than distro 
>> maintainers?
> 
> You can use either Pungi or livecd-creator too.

Ah yes, I forgot about Pungi. I've been away too long :)

> Assuming you are aiming for a custom spin hosted by Fedora, 
> regardless of the tools, the deliverable is a kickstart file that we 
> can run through the process. Refer
> 
> http://fedoraproject.org/wiki/Infrastructure/CustomSpins

I'd be quite happy for Fedora to host the finished product, but right
now I just want to get something started. I will need to study the
various infrastructure docs anyway, if I'm going to implement my own
Koji buildsystem, so hopefully I should be up to speed long before I get
to the stage where I'm submitting a spin for review.

> I have a inclination about the kind of spin you are shooting for and
> more details would be nice since I might be interested in 
> participating.

Well my initial motivation was purely selfish (aren't they always? :) ),
since I wanted an F8 system optimised for one of my servers, which is a
VIA EPIA C3 system, not currently supported at all by F8 (bug #367731).

But then it occurred to me that quite a few people probably use these
types of systems as HTPCs or Home Servers (like me), and they'd probably
appreciate a bit of optimisation (as well as just getting it to work at
all) since C3s are not especially fast (and lack certain features like
CMOV and larger caches). I don't immediately plan on providing MythTV
packages, but it's probably a mid to long term goal.

Basically I want something that a) works and b) is optimised for the C3
(and in passing, the AMD K6 family), but this could easily be expanded
into something more, like say "MythDora". We could call it "Fedora MCE",
ultimately with builds for other arch's (but get C3 working first).

If that isn't what you were expecting, then perhaps I may be able to
accommodate you anyway. What did you have in mind?

If you (or anyone else) would like to participate, then you're welcome.



From jdieter at gmail.com  Tue Nov 13 05:50:34 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Tue, 13 Nov 2007 07:50:34 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <4738F07A.500@redhat.com>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<47334F0F.5030106@fedoraproject.org>
	<1194549299.10285.5.camel@jndwidescreen.lesbg.loc>
	<4738F07A.500@redhat.com>
Message-ID: <1194933034.3122.4.camel@jndwidescreen.lesbg.loc>


On Mon, 2007-11-12 at 16:31 -0800, John Poelstra wrote:
> Jonathan Dieter wrote:
> > On Thu, 2007-11-08 at 23:31 +0530, Rahul Sundaram wrote:
> >> Great. Is this planned to be default for Fedora 9?
> >>
> > 
> > I really hope so.  The real issue is that the build system needs to be
> > set up to generate the deltarpms and I don't know koji/bodhi.
> > 
> > The idea is that when the buildsystem is able to generate deltarpms
> > (hopefully very soon), we'll start making the official repositories
> > presto-enabled.  *If* we don't have any problems, we *may* then make it
> > the default for Fedora 9.
> > 
> > Jonathan
> > 
> 
> Sounds like a definite Feature worth tracking and getting some attention 
> drawn to it.
> 
> http://fedoraproject.org/wiki/Features/Policy
> 
> Let me know if you help with the feature page creation.
> 
> John
> 

This was already an approved Feature for Fedora 8, but got stuck in the
backlog because of higher priority problems for those working on
koji/bodhi.  See http://fedoraproject.org/wiki/Releases/FeaturePresto.
It's now a proposed Feature for Fedora 9.

Thanks much for your interest.  I'm happy to have any attention drawn to
this feature.  The sooner the official repositories are presto-enabled,
the sooner I can stop maintaining the unofficial ones.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/3e9b3900/attachment.sig>

From a.badger at gmail.com  Tue Nov 13 06:23:35 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 12 Nov 2007 22:23:35 -0800
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <47391DEF.7060508@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>	<20071113010910.GC2651@free.fr>
	<47391DEF.7060508@redhat.com>
Message-ID: <473942E7.6010706@gmail.com>

Warren Togami wrote:
> Patrice Dumas wrote:
>> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
>>> For many years, I've used /var/tftp as a location for storing TFTP 
>>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
>>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
>>> reflect this.
>>
>> FHS says:
>>
>> Applications must generally not add directories to the top level of
>> /var. Such directories should only be added if they have some
>> system-wide implication, and in consultation with the FHS mailing list.
>>
>> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
>> for what should be in /var/lib, but it is not clearly wrong either.
>>
>> -- 
>> Pat
>>
> 
> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as 
> well?
> 
> If so, I suppose our selinux-policy should handle both /tftpboot and 
> this new location to allow for a smooth transition.
> 
According to the FHS this would be the desired location so if it's 
desirable to change this is where I'd put it.  Will it make integrating 
ltsp easier if the location is the same between Fedora and Ubuntu?

-Toshio



From poelstra at redhat.com  Tue Nov 13 06:30:15 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 12 Nov 2007 22:30:15 -0800
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <1194933034.3122.4.camel@jndwidescreen.lesbg.loc>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>	<47334F0F.5030106@fedoraproject.org>	<1194549299.10285.5.camel@jndwidescreen.lesbg.loc>	<4738F07A.500@redhat.com>
	<1194933034.3122.4.camel@jndwidescreen.lesbg.loc>
Message-ID: <47394477.20505@redhat.com>

Jonathan Dieter wrote:
> This was already an approved Feature for Fedora 8, but got stuck in the
> backlog because of higher priority problems for those working on
> koji/bodhi.  See http://fedoraproject.org/wiki/Releases/FeaturePresto.
> It's now a proposed Feature for Fedora 9.
> 
> Thanks much for your interest.  I'm happy to have any attention drawn to
> this feature.  The sooner the official repositories are presto-enabled,
> the sooner I can stop maintaining the unofficial ones.
> 

You are correct!  Sorry I forgot it was there.  Once the approval 
process kicks off again I'll raise it at a FESCo meeting.

Can you update the status and any other pertinent details?

Thanks,
John



From poelstra at redhat.com  Tue Nov 13 07:09:01 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 12 Nov 2007 23:09:01 -0800
Subject: Fedora Rel-Eng Meeting Recap 2007-NOV-12
Message-ID: <47394D8D.4010201@redhat.com>

Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-12

Please make corrections and clarifications to the wiki page.


== Schedule Review ==
  * http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html
  * Make sure no collisions with holidays
  * Next proposed FUDCon: January 11-13, 2008, at Red Hat HQ in Raleigh
     * http://gregdek.livejournal.com/17724.html
  * Need to have other teams review: FESCo, Docs, translation team, QA
  * Change Alpha Freeze to Jan. 15, Alpha release Jan. 24

== F9 Tasks & Targets ==
  * Fill out Trac tickets for things that need to get done
    * https://hosted.fedoraproject.org/projects/rel-eng/
  * Python scripts that can take email as input and create Trac tickets 
from them
    * use ''rel-eng at fedoraproject.org'' as Trac input.
DECISIONS:
   * continue move to Trac for task management
   * work toward turning rel-eng at fp.o into a Trac ticket gateway
   * create an invite only or otherwise moderated mailing list for 
rel-eng discussion/voting

== Ideas for Goals for F9 Release ==
   * brainstorm before next week's meeting to figure out what we want to 
do for this release outside the typical make bits show up stuff
     * send preferably by Friday so we can digest it over the weekend.
   * wwoods: http://fedoraproject.org/wiki/ReleaseEngineering/Overview
   * notting
     * signing server
     * potentially the big multilib change--i need to get some stuff 
written down for that
     * kill the buildroot overrides stuff
   * wwoods
     * bodhi depchecking!
     * PPC as the trailblazer secondary arch
   * f13
     * signing server
     * complete the s/development/rawhide/ changes.
     * post-build processing--running rpmlint and other such things.
     * jigdo support
     * dealing with rawhide late in the cycle so that we have two 
nightly trees
     * composes in Colo for F9
   * warren
     * delta rpm and presto by default
  * jeremy
     * less involvement
     * need help spinning live images

== Fedora CD Releases ==
   * The board has asked that we produce split CD media once again.
   * Release Engineering has not fully agreed, though have it would be 
possible
   * really just a matter of time and space, yes?
   * warren: can't upgrade with live images.
   * would increase number of test targets
   * affects on Release Engineering are more of the following:
     * compose time
     * validation time
     * sync time
     * disc space used

== Meeting Time ==
  * Going forward (starting with next week) we will meet at 1800 UTC 
(1300 EST)

== Fedora 8 Jigdo Data from Fedora Unity ==
  * 600 downloads of the .jigdo file
  * 400 downloads of the CD1 template
     * thus so 200 or so users did not know where to get started with 
jigdo or did not start yet.
     * thought to be useful to people that cannot do network installs
     * if we can look at what packages are on what CD and what CD other 
than 1 is most popular that might make for some interesting analysis

== IRC Transcript ==



From nicolas.mailhot at laposte.net  Tue Nov 13 07:22:00 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 13 Nov 2007 08:22:00 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <4738EB04.6090501@gmail.com>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>
	<47389323.6060004@gmail.com>
	<1194891205.27768.22.camel@rousalka.dyndns.org>
	<4738B53C.6070503@gmail.com>
	<1194906646.27768.64.camel@rousalka.dyndns.org>
	<4738EB04.6090501@gmail.com>
Message-ID: <1194938520.7995.4.camel@rousalka.dyndns.org>


Le lundi 12 novembre 2007 ? 18:08 -0600, Les Mikesell a ?crit :

> > And when projects break up, or fold, the only part remaining (that can
> > still be packaged years later) are the tarballs that were mirrored on
> > code repository sites.
> 
> Couldn't that be equally true of distributed SCMs?

You don't need a full SCM history to build an app, just a snapshot so
that's what would survive. Except unlike archives everyone would have
his own snapshot and cross-checking them would be not easy.

?
> > You usually need some time in a support/sysadmin position managing
> > systems built by developers from SCM dumps (or god forbid production
> > systems directly re-build from developer SCM-plugged RAD IDE
> > environments) to appreciate the difference.
> 
> I do know the difference - a company where I worked for years had one 
> group that was religious about deployment builds being based strictly on 
> tags and the SCM containing everything necessary for the build and 
> another that did a lot of hand tweaking and could only do the build on 
> one machine that nobody remembered how to reconstruct.  A patient QA 
> dept. was the only thing that let the latter group survive.

Then I'm surprised you assume we'd find mostly group1s on the internet
and not a huge majority of group2s.

> but the 
> best you'll probably do with internet development is to glue a bug 
> tracker to the revision number.

Ie chances to get it to work given the breadth of software we package
are slim to inexistent.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/10772be7/attachment.sig>

From dholwerda at gmail.com  Tue Nov 13 07:28:59 2007
From: dholwerda at gmail.com (Dan Holwerda)
Date: Tue, 13 Nov 2007 16:28:59 +0900
Subject: Core 2 Duo not fast enough for Mplayer?
In-Reply-To: <2a28d2ab0711120519p17f6178cm55901b99db0630e6@mail.gmail.com>
References: <2a28d2ab0711110926s3794cc83rc47c48aa8a62cdac@mail.gmail.com>
	<20071112073058.75bfe2eb@redhat.com>
	<2a28d2ab0711120519p17f6178cm55901b99db0630e6@mail.gmail.com>
Message-ID: <1194938939.14504.3.camel@laptop>

>
> > The video is very slow and choppy.  Totem movie player has no problem
> > with it.  Xine plays about 5 seconds, pauses for a second then
> > continues.
> >
> > Any thoughts?
>
> Are you using compiz?
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>

No compiz.

there is something wrong with sound - I haven't been able to track down what is causing it though.

firefox/flash likely culprits

I have to restart hal (service haldaemon restart) & pulseaudio -vv ti get sound working again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/4e57c4f9/attachment.htm>

From nicolas.mailhot at laposte.net  Tue Nov 13 07:34:12 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 13 Nov 2007 08:34:12 +0100
Subject: fedora.com, is this for real?
In-Reply-To: <80d7e4090711121824q5f5900a1q515684b6e2272b88@mail.gmail.com>
References: <fhatr5$6t6$1@ger.gmane.org>
	<80d7e4090711121824q5f5900a1q515684b6e2272b88@mail.gmail.com>
Message-ID: <1194939252.7995.8.camel@rousalka.dyndns.org>


Le lundi 12 novembre 2007 ? 19:24 -0700, Stephen John Smoogen a ?crit :
> On Nov 12, 2007 6:15 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> > Uh, is this for real or what?
> >
> > http://www.fedora.com/
> >
> 
> It looks like Network Solutions is back into the domain squatting again

The nice thing is that since it's clearly fedoraproject cybersquatting
(as evidenced by the page content) should Red Hat lawyers
challenge ?Network Solutions I don't see how they could justify before a
judge keeping the domain.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/a80017f4/attachment.sig>

From alexl at redhat.com  Tue Nov 13 07:55:34 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Tue, 13 Nov 2007 08:55:34 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194883648.2894.10.camel@localhost.localdomain>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
	<1194883648.2894.10.camel@localhost.localdomain>
Message-ID: <1194940534.12691.31.camel@dhcp-208-188.arn.redhat.com>


On Mon, 2007-11-12 at 11:07 -0500, Matthias Clasen wrote:
> On Mon, 2007-11-12 at 16:48 +0100, Alexander Larsson wrote:
> > On Mon, 2007-11-12 at 16:40 +0100, Ralf Ertzinger wrote:
> > > Hi.
> > > 
> > > On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:
> > > 
> > > > It would be cool if we could autoextract mime handling information
> > > > from desktop files installed in /usr/share/applications and generate
> > > > "mime(application/pdf)" style rpm provides.
> > > 
> > > YOu know, I like that idea. A lot.
> > 
> > This will figure out the provides needed:
> > 
> > for i in `grep -h MimeType /usr/share/applications/* | sed "s/^MimeType=//" | sed "s/;/\n/g" | sort -u`; do echo "mime($i)"; done
> > 
> > Someone just has to turn it into a proper rpm find-provides thing.
> 
> While this may be a nice idea, it doesn't solve
> 
> a) editor vs viewer

I don't see how this is a problem:

a) We already have this "issue" for normal desktop file with the open
with menus etc, and I've never heard any complaints. Generally the
description for the app is good enough.

b) editor vs viewer isn't really a good enought categorization anyway.
There are things like "savegame for game foo", "viewer with some editing
capabilities", "a runtime for apps of type foo", etc. I don't see what
we gain by adding something like this instead of just making sure
descriptions are good.


> b) inherited capabilities, ie totem can display any format gstreamer can
> handle, which in turn depends on installed plugins

This is indeed a broblem. However, its already a problem with the
current desktop files. And when we solve that (via some form of indirect
link) that solution maps to a similar solution in the rpm provides case.



From pertusus at free.fr  Tue Nov 13 08:17:17 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Nov 2007 09:17:17 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <473942E7.6010706@gmail.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473942E7.6010706@gmail.com>
Message-ID: <20071113081717.GA2574@free.fr>

On Mon, Nov 12, 2007 at 10:23:35PM -0800, Toshio Kuratomi wrote:
>>
> According to the FHS this would be the desired location so if it's 
> desirable to change this is where I'd put it.  Will it make integrating 
> ltsp easier if the location is the same between Fedora and Ubuntu?

It is not clear to me that it is the desired location. It seems to be
more for databases that are not directly set up by the user. In my
opinion the wording doesn't correspond with a location where people put
content to be served:

 This hierarchy holds state information pertaining to an application or
 the system. State information is data that programs modify while they
 run, and that pertains to one specific host. Users must never need to
 modify files in /var/lib to configure a package's operation.

 State information is generally used to preserve the condition of an
 application (or a group of inter-related applications) between
 invocations and between different instances of the same application.
 State information should generally remain valid after a reboot, should
 not be logging output, and should not be spooled data.

/srv is clearly the right location, but I agree that /var/lib/*/ is the 
best location, if /srv/ is to be untouched by the packages (and I don't
have an opinion on that point).

--
Pat



From jdieter at gmail.com  Tue Nov 13 10:11:32 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Tue, 13 Nov 2007 12:11:32 +0200
Subject: Deltarpms will be available for F7 -> F8 upgrade
In-Reply-To: <47394477.20505@redhat.com>
References: <1194535988.3737.4.camel@jndwidescreen.lesbg.loc>
	<47334F0F.5030106@fedoraproject.org>
	<1194549299.10285.5.camel@jndwidescreen.lesbg.loc>
	<4738F07A.500@redhat.com>
	<1194933034.3122.4.camel@jndwidescreen.lesbg.loc>
	<47394477.20505@redhat.com>
Message-ID: <1194948692.3122.12.camel@jndwidescreen.lesbg.loc>


On Mon, 2007-11-12 at 22:30 -0800, John Poelstra wrote:
> You are correct!  Sorry I forgot it was there.  Once the approval 
> process kicks off again I'll raise it at a FESCo meeting.
> 
> Can you update the status and any other pertinent details?

Done.  Let me know if there's anything else I need to do.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/7d6e8b87/attachment.sig>

From valent.turkovic at gmail.com  Tue Nov 13 10:12:11 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 13 Nov 2007 11:12:11 +0100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
	<Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
Message-ID: <64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>

On 11/12/07, Jima <jima at beer.tclug.org> wrote:
> On Mon, 12 Nov 2007, Yaakov Nemoy wrote:
> > That URL is based off your "UUID" which is generated unique to smolt.
> > It's found in either /etc/smolt for most distros, or
> > /etc/sysconfig/hw-uuid.  if you copy this file around, then of course,
> > it's going to look like you're using the same machine.  UUID
> > management in the client needs a bit of work, but if you're looking
> > for a new UUID in a hurry, in our mercurial repository, there's an
> > install script for generating UUIDs.  Fetch it, make sure the source
> > puts the UUID where it should go for your distro, (the script is in
> > python, nothing terribly difficult), and run it.
>
>   Or you could just use uuidgen(1) from the e2fsprogs package.
>
>       Jima

I see uuidgen generating random uuids but I user a simpler approach.

I just edited /etc/sysconfig/hw-uuid and changed one number...
We'll see if it is now a different profile...

ps. I'm able to send profile only after 10 attempts, I usually get this error:

Send this information to the Smolt server? (y/n) y
Error contacting Server: [Errno 14] HTTP Error 500: Internal error
Could not send - Exiting


or this one:

Send this information to the Smolt server? (y/n) y
Error contacting Server: [Errno 12] Timeout: <urlopen error timed out>
Could not send - Exiting



-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Tue Nov 13 10:13:14 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 13 Nov 2007 11:13:14 +0100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
Message-ID: <64b14b300711130213s48397b5cs725e7c9ee8269674@mail.gmail.com>

On 11/12/07, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> On Nov 12, 2007 3:54 AM, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> > Hi,
> >
> > I have 2 laptops and I used the smoltSendProfile and I seem to get the
> > same url for both laptops, ie. the later sent profile overwrites the
> > previous one...
> >
> > I'm sending both profiles from same adsl line and I'm behing a NAT
> > adsl router, so could this be an issue (same IP) ?
> >
> > Is this a feature or a bug?
> >
> > How can I send multiple laptop profiles and see them all online?
> >
>
> That URL is based off your "UUID" which is generated unique to smolt.
> It's found in either /etc/smolt for most distros, or
> /etc/sysconfig/hw-uuid.  if you copy this file around, then of course,
> it's going to look like you're using the same machine.  UUID
> management in the client needs a bit of work, but if you're looking
> for a new UUID in a hurry, in our mercurial repository, there's an
> install script for generating UUIDs.  Fetch it, make sure the source
> puts the UUID where it should go for your distro, (the script is in
> python, nothing terribly difficult), and run it.
>
> Feel free to post back if you have trouble with this, and I'll type up
> a longer step by step explanation.
>
> Cheers,
> Yaakov
>

I'm not moving and files around and on both laptops it is a clean
install on an empty partition.


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From alexl at redhat.com  Tue Nov 13 10:16:04 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Tue, 13 Nov 2007 11:16:04 +0100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <1194948964.27456.1.camel@dhcp-208-188.arn.redhat.com>


On Mon, 2007-11-12 at 16:48 +0100, Alexander Larsson wrote:
> On Mon, 2007-11-12 at 16:40 +0100, Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Mon, 12 Nov 2007 13:35:20 +0100, Alexander Larsson wrote:
> > 
> > > It would be cool if we could autoextract mime handling information
> > > from desktop files installed in /usr/share/applications and generate
> > > "mime(application/pdf)" style rpm provides.
> > 
> > YOu know, I like that idea. A lot.
> 
> This will figure out the provides needed:
> 
> for i in `grep -h MimeType /usr/share/applications/* | sed "s/^MimeType=//" | sed "s/;/\n/g" | sort -u`; do echo "mime($i)"; done
> 
> Someone just has to turn it into a proper rpm find-provides thing.
> 

Bah, i wrote a /usr/lib/rpm/redhat/find-provides.d/mimetypes.prov script
(attached) which i believe should work. However, it seems rpm is only
using its internal dependency checker, so this would need some actual
rpm code changes to work. 

To much work for me...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mimetypes.prov
Type: application/x-shellscript
Size: 252 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/b8753f31/attachment.bin>

From sander at vermin.nl  Tue Nov 13 10:23:40 2007
From: sander at vermin.nl (Sander Vermin)
Date: Tue, 13 Nov 2007 11:23:40 +0100
Subject: pptp-linux (pptp) on a Fedora DVD
In-Reply-To: <4738EEA8.8080503@redhat.com>
References: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
	<4738EEA8.8080503@redhat.com>
Message-ID: <47397B2C.6010805@vermin.nl>

John Poelstra schreef:
> Kevac Marko wrote:
>> Hello.
>>
>> Here, in Russian Federation, 90% of home internet providers use PPTP
>> for the internet access.
>> So 80% of Fedora users from Russian Federation have same problem of
>> installing and configuring pptp client. It includes very unpleasant
>> "go to another box with internet connection, download rpm package, go
>> back and install it".
>>
>> I don't know what situation is in another countries with pptp, but i
>> be very glad to see pptp client on a Fedora DVD.
>>
>> So, questions are:
>> 1. Why pptp package is still not there? Some license issues?
>> 2. Will it be included in Fedora DVD?
>> 3. How can i help?
>>
>
> You could help by creating a feature page which focus on including the 
> package and smoothing out other configuration issues.  It sounds like 
> this enhancement could benefit a lot of users :)
>
> http://fedoraproject.org/wiki/Features/Policy
>
> If you need help with creating a feature page, please let me know.
>
> John
>
It would be a big plus if we use NetworkManager's vpn pptp client for 
the graphical part.

Tis is available for KNetworkManager but nog for GNOME.

Regards,

Sander Vermin



From mailings at lordmorgul.net  Tue Nov 13 10:26:51 2007
From: mailings at lordmorgul.net (Andrew Farris)
Date: Tue, 13 Nov 2007 02:26:51 -0800
Subject: Codec Buddy misleading.
In-Reply-To: <7f692fec0711112054g2b042057s993dd83e2c1513b@mail.gmail.com>
References: <6e24a8e80711081824g18e4266fm8b53d94f228a10c7@mail.gmail.com>	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>	<20071109203142.GA6642@roque.1407.org>	<20071109223601.GB5480@devserv.devel.redhat.com>	<6e24a8e80711091446u76d3aaayb6fba328fdc4012c@mail.gmail.com>	<4734E6E4.3020807@fedoraproject.org>	<loom.20071109T231223-339@post.gmane.org>	<4734ED76.3050307@fedoraproject.org>	<6e24a8e80711091556t1624346axecee17eca292d872@mail.gmail.com>	<1194835043.2306.26.camel@cookie.hadess.net>
	<7f692fec0711112054g2b042057s993dd83e2c1513b@mail.gmail.com>
Message-ID: <47397BEB.4050201@lordmorgul.net>

Yaakov Nemoy wrote:
> The first patent holder that sues freedesktop.org is just going to
> look like a bad guy.
> 
> a) The press will look really bad
> 
> b) freedesktop.org does not make million dollar annual profits from
> these codecs the way Red Hat, Novell, or Mandrivia would and they
> could never hope to seek the same level of damages
> 
> c) lawyers might take this case on good will, because of the high
> profile nature, and the understanding of how open source works and is
> good for the legal industry, and one of these lawyers might bust these
> patents.
> 
> I hope these arguments are enough for people to realize that just
> because it's open source does not mean Red Hat can *afford* to use the
> software.

This comment really sums up the situation very well.  Those not familiar with
how US corporations have *for decades* practiced pro-active protection against
patent suits... read Yaakov's last line again.  Red Hat legal has to consider
not just whether its possible for suits to arise from patent infringement, but
WHO is going to be involved.  They would need to be very confident that the 'big
players' cannot end up on the other side of the codec issue against them and
even more careful about the numerous basically frivolous patent suit scalping
companies with no assets to lose and no intention of profiting from a patent by
protecting a product they actually make.  Thats not easy to guarantee.  There
are quite a number of patent suits in the US won by a company that just bought
the patent rights *in order* to go to court with them.

The fact that noone has gone after yet freedesktop.org (or any other example of
someone 'under US law' who is not being as careful as RH is) has NO BEARING on
whether its safe to assume noone will try against Red Hat.  There is no legal
standing with patents to say 'they infringed on it before us so its ok'.  The RH
legal guys are being reasonably cautious regarding codecs; they know they
*could* go right ahead and drop them in, but they also know that could cause
headaches later.



From abo at kth.se  Tue Nov 13 10:49:40 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Tue, 13 Nov 2007 11:49:40 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113081717.GA2574@free.fr>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473942E7.6010706@gmail.com>  <20071113081717.GA2574@free.fr>
Message-ID: <1194950980.31176.38.camel@home.alexander.bostrom.net>

tis 2007-11-13 klockan 09:17 +0100 skrev Patrice Dumas:
> On Mon, Nov 12, 2007 at 10:23:35PM -0800, Toshio Kuratomi wrote:

> > According to the FHS this would be the desired location so if it's 
> > desirable to change this is where I'd put it.  Will it make integrating 
> > ltsp easier if the location is the same between Fedora and Ubuntu?

> /srv is clearly the right location, but I agree that /var/lib/*/ is the 
> best location, if /srv/ is to be untouched by the packages (and I don't
> have an opinion on that point).

The current usage of /var/lib doesn't really follow FHS, but packages
touching /srv is also against the FHS, so that's not right either. I
think the best thing to do here is to violate the FHS the same way
everything else is doing and use /var/lib/tftp or stay in /tftpboot if
you're not comfortable with the former.

It would be questionable to start violating the FHS in a new and shiny
way, i.e. to use /srv/tftp. If packages are going to go into /srv there
should be a structure to it.

Btw, "lib/foo" is not about shared objects for foo, it's "here goes
things belonging to foo", regardless of if it's /var/lib or /usr/lib.
Don't be confused by "lib". Remember, this is Un*x, it's evolved, not
logical. Do you think your genes are nicely commented and using pretty
variable names? :)

/abo



From abo at kth.se  Tue Nov 13 10:55:48 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Tue, 13 Nov 2007 11:55:48 +0100
Subject: Petabytes and hierarchical storage management
In-Reply-To: <20071107155503.19d9377e@ludwig-alpha.unil.ch>
References: <20071107155503.19d9377e@ludwig-alpha.unil.ch>
Message-ID: <1194951348.31176.42.camel@home.alexander.bostrom.net>

ons 2007-11-07 klockan 15:55 +0100 skrev Christian Iseli:
> Hi folks,
> 
> Anybody here aware of open source tools to have a HSM solution in
> Fedora ?
> 
> What I'm basically after is something that
>  - mounts and behaves like a normal filesystem
>  - can manage petabytes
>  - automatically migrates files to tapes (or other fancy low cost per
> megabytes storage device), based on some policy when they are unused
> for some period of time, and loads them back the next time a process
> attempts to open those files
>  - can be exported through NFS and samba

I'd be interested in something like this, too. For me, the backend would
be a TSM system, but it's nice if there can be several different
backends.

Maybe something to hack in FUSE? fuse-python or something should be
fairly simple to use. FUSE is not re-exportable by the kernel NFS server
stuff though, you have to use a userland NFS server.

/abo



From nphilipp at redhat.com  Tue Nov 13 11:09:50 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Tue, 13 Nov 2007 12:09:50 +0100
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <4738EB04.6090501@gmail.com>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>
	<47389323.6060004@gmail.com>
	<1194891205.27768.22.camel@rousalka.dyndns.org>
	<4738B53C.6070503@gmail.com>
	<1194906646.27768.64.camel@rousalka.dyndns.org>
	<4738EB04.6090501@gmail.com>
Message-ID: <1194952190.12360.19.camel@wombat.tiptoe.de>


On Mon, 2007-11-12 at 18:08 -0600, Les Mikesell wrote:
> Nicolas Mailhot wrote:
[...]
> > And when projects break up, or fold, the only part remaining (that can
> > still be packaged years later) are the tarballs that were mirrored on
> > code repository sites.
> 
> Couldn't that be equally true of distributed SCMs?

You would have to use cryptographically secure hashes instead of
speaking tag names if you want to nail down specific revisions. That
would make very ugly, i.e not meaningful for the human eye, source URLs
in the packages. And you would have to mirror all the upstream SCMs
which I'm sure isn't a thing we would want to do. Even if we had the
hardware numbers needed for that, there would be a lot of areas where
these could be spent more worthwhile than that.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From mcepl at redhat.com  Tue Nov 13 10:10:05 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 13 Nov 2007 11:10:05 +0100
Subject: Codec Buddy misleading.
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<gjkl05x62j.ln2@hubmaier.ceplovi.cz>
	<Pine.LNX.4.64.0711121126390.26997@newtla.xelerance.com>
Message-ID: <to9o05xelb.ln2@hubmaier.ceplovi.cz>

On Mon, 12 Nov 2007 11:33:19 -0500, Paul Wouters scripst:
> So tell me your idea on how we can better inform the internationa
> community about patents and codecs, without discriminating against
> non-US users of Fedora. Because the current idea of pretending
> international users of Fedora don't exist just before Red Hat is an
> American company is worse then keeping quiet like we did pre-F8.

I am afraid that the community maintained sites like with solved 
questions for fedora (go and find the website yourself, I cannot write 
down the URL for the same reason ... etc.) are the only solution so far.

Mat?j



From buildsys at redhat.com  Tue Nov 13 11:30:22 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 13 Nov 2007 06:30:22 -0500
Subject: rawhide report: 20071113 changes
Message-ID: <200711131130.lADBUM87016824@porkchop.devel.redhat.com>

New package R-tkWidgets
	Widgets to provide user interfaces

New package asunder
	A graphical Audio CD ripper and encoder

New package ndesk-dbus-glib
	Provides glib mainloop integration for ndesk-dbus

New package perl-Class-CSV
	Class based CSV parser/writer

New package perl-Net-Packet-Target
	An object for all network related stuff


Removed package PyQt-qscintilla

Updated Packages:

Io-language-20071010-1.fc9
--------------------------
* Sun Nov 11 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 20071010-1
- New (official!) upstream release 2007-10-10
- API changed, soname bumped to libiovmall.so.1

PackageKit-0.1.3-1.fc9
----------------------
* Sat Nov 10 2007 Robin Norwood <rnorwood at redhat.com> - 0.1.3-1
- Update to latest upstream version: 0.1.3

PyQt-3.17.3-3.fc9
-----------------
* Mon Nov 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.17.3-3
- Requires: sip >= %{sip_version_used_to_build}

* Mon Nov 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.17.3-2
- -qscintilla(-devel) subpkgs
- License: GPLv2
- fix %qtversion
- don't own %_datadir/sip (sip-devel owns it)

PyQt4-4.3.1-1.fc9
-----------------
* Mon Nov 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.1-1
- PyQt-4.3.1

R-DynDoc-1.17.0-1.fc9
---------------------
* Mon Oct 08 2007 Pingou <pingoufc4 at yahoo.fr> 1.17.0-1
- Update to bioconductor 2.1

R-widgetTools-1.15.0-1.fc9
--------------------------
* Mon Oct 08 2007 Pingou <pingoufc4 at yahoo.fr> 1.15.0-1 
- Update to bioconductor 2.1

SDL_mixer-1.2.8-5.fc9
---------------------
* Mon Nov 12 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.2.8-5
- link against system libmikmod. (#355991)

TnL-071111-1.fc9
----------------
* Sun Nov 11 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 071111-1
- New upstream release 071111

anaconda-11.4-1
---------------
* Thu Nov 08 2007 Chris Lumens <clumens at redhat.com> 11.4-1
- Add nicdelay= command line option (msivak, #349521).
- Display more useful ks script error messages.
- Set re-IPL device before reboot on s390x (bhinson, Jan Glauber).
- Enable DASD formatting progress bar (Jan Glauber).
- Add memory error handling to module loading code (HARA Hiroshi).
- Add accelerator keys to the VG editor window (jgranado, #206479).
- Turn off swap and lvm earlier to avoid dmraid problems (katzj, #357401).
- Fix lang-names handling under parallel make (katzj, #358411).
- Rework VNC startup (jgranado, #264841).
- Fix help output for buildinstall (#355871).
- Pull docs from the new wiki location (katzj, #356021).
- Fix handling of XFS under livecd (katzj, #355351).
- Don't show bridged network devices (katzj, #354561).
- Fix handling of Sun disklabels (pjones).
- Add --fsprofile=, deprecate --bytes-per-inode (pjones).
- Rework exception handling dialog UI for future expansion.
- Use the right path for locking under livecd (notting, #354571).
- Add --disc-size= to splittree.py (#149234).
- Write kickstart log files to the right tree when chrooted (#338541).
- Offer to upgrade rpm platform on mismatched arch upgrades (msivak, #217132).
- Don't ask to initialize partition tables in rescue mode (msivak, #331131).
- Add CIFS tools to the rescue image (msivak).
- Fix displaying ampersands in the package progress bar (dcantrell).
- Ignore sg devices in the driveDict (katzj, #330931).
- Create the USB boot image with makebootfat (jgranado).
- Add ntfsprogs to the rescue image (jgranado, #220062).
- Fix retrying when booting off the CD and using a URL method (#330641).
- Allow users to use their own mke2fs.conf (pjones).
- Don't log critical errors if we can retry fetching (sfernand, #350251).
- Clean up usage of /tmp for device nodes (notting).
- Fix shlib dep finding in upd-instroot (Orion Poplawski, pjones).
- Fix runinst and hal-lock usage for livecd (katzj).
- Write out IPV6* variables to ifcfg-eth* correctly (dcantrell, #328931).
- Don't traceback when trying on a failed mirror (#349371).

* Mon Oct 22 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.44-1
- Fix warning about arch changes on upgrade (#222424)
- Fix phantom kernels on upgrade (#325871)
- Add some kde packages to the multilib upgrade blacklist (#339981)
- Require policycoreutils (clumens, #343861)
- Fix typo leading to traceback (clumens)
- Fix processing of ks=nfs (clumens)
- Memory freeing cleanups (pjones)

* Sun Oct 21 2007 Jeremy Katz <katzj at redhat.com> 11.3.0.43-1
- Fix closing of some fds (pjones)
- Fix ip address used in a few cases (clumens, #336761)
- Filter out non-useful networking devices from being 
  displayed (clumens, #338461)
- Fix a quoting bug with pxelinux (#248170)
- Label lost+found (pjones, #335621)
- Update udev rules to not match wmaster (notting)
- gptsync update (pjones)
- Detect invalid harddrives given to bootloader --driveorder (#33861)

at-spi-1.21.1-1.fc9
-------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 1.21.1-1
- Update to 1.21.1

bash-3.2-19.fc9
---------------
* Tue Nov 06 2007 Tomas Janousek <tjanouse at redhat.com> - 3.2-19
- fix cursor position when prompt has one invisible character (#358231)
- dropped examples/loadables/ from docs, since it wasn't possible to build them
  anyway (#174380)
- fix #286861: Wrong input confuses bash's arithmetic unit permanently
- fix #344411: $RANDOM stays the same when job executed in the background

* Fri Aug 31 2007 Pete Graner <pgraner at redhat.com> - 3.2-18
- Added bash32-021 upstream official patch
- Added bash32-025 upstream official patch
- Added bash32-024 upstream official patch
- Added bash32-023 upstream official patch
- Added bash32-022 upstream official patch

* Wed Aug 29 2007 Pete Graner <pgraner at redhat.com> - 3.2-17
- Added bash32-018 upstream official patch
- Added bash32-020 upstream official patch
- Added bash32-019 upstream official patch

bcfg2-0.9.5-2.fc9
-----------------
* Mon Nov 12 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-2
- Fix oops.

* Mon Nov 12 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-1
- Update to 0.9.5 final.

bodhi-0.4.3-1.fc9
-----------------
* Mon Nov 12 2007 Luke Macken <lmacken at redhat.com> - 0.4.3-1
- 0.4.3

* Mon Nov 12 2007 Luke Macken <lmacken at redhat.com> - 0.4.2-1
- 0.4.2

* Mon Nov 12 2007 Luke Macken <lmacken at redhat.com> - 0.4.1-1
- 0.4.1

cmake-2.4.7-4.fc9
-----------------
* Mon Nov 12 2007 Orion Poplawski <orion at cora.nwra.com> - 2.4.7-4
- No longer set CMAKE_SKIP_RPATH

contact-lookup-applet-0.16-4.fc9
--------------------------------
* Mon Nov 12 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.16-4
- Add sources patch to remove the need to set autocompletion. (Bastien Nocera)
- Add search patch to not search if ebook hasn't been opened yet.

dejagnu-1:1.4.4-11
------------------
* Mon Nov 12 2007 Petr Machata <pmachata at redhat.com> - 1:1.4.4-11
- Install info file.
- Resolves: #230652

devilspie-0.21-1.fc9
--------------------
* Mon Nov 12 2007 Sebastian Vahl <fedora at deadbabylon.de> 0.21-1
- new upstream version: 0.21

* Mon Sep 17 2007 Sebastian Vahl <fedora at deadbabylon.de> 0.20.2-5
- Fix some minor issue in manpage (#293731)

dhcp-12:3.1.0-8.fc9
-------------------
* Mon Nov 12 2007 David Cantrell <dcantrell at redhat.com> - 12:3.1.0-8
- Put dhcp.schema in /etc/openldap/schema (#330471)
- Remove manpages patch and keep modified man pages as Source files
- Improve dhclient.8 man page to list options in a style consistent
  with most other man pages on the planet
- Upgrade to latest dhcp LDAP patch, which brings in a new dhcpd-conf-to-ldap
  script, updated schema file, and other bug fixes including SSL support for
  LDAP authentication (#375711)
- Do not run dhcpd and dhcrelay services by default (#362321)

* Fri Oct 26 2007 David Cantrell <dcantrell at redhat.com> - 12:3.1.0-7
- libdhcp4client-devel requires openldap-devel

* Thu Oct 25 2007 David Cantrell <dcantrell at redhat.com> - 12:3.1.0-6
- Rename Makefile.dist to Makefile.libdhcp4client
- Spec file cleanups
- Include stdarg.h in libdhcp_control.h

eog-2.21.1-1.fc9
----------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.1-1
- Update to 2.21.1

evolution-2.21.2-1.fc9
----------------------
* Mon Nov 12 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.2-1.fc9
- Update to 2.21.2

* Tue Oct 30 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1-2.fc9
- Attempt to split the gnome-pilot stuff into a separate
  evolution-conduits subpackage (RH bug #178155).

* Mon Oct 29 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1-1.fc9
- Update to 2.21.1
- Remove redundant requirements.
- Bump EDS requirement to 2.21.1.
- Bump gtkhtml requirement to 3.17.1.
- Backup/restore plugin got moved from standard to experimental.
- Revert the per-component menu items (RH bug #222105, #241462, #293771).
- Show the switcher buttons by default (RH bug #186403).
- Alter the desktop file Name and Comment.
- Disable patch for GNOME bug #376991 for now.  It may be contributing
  to password prompting problems as described in RH bug #296671.
- Remove patch for GNOME bug #417999 (fixed upstream).
- Remove patch for GNOME bug #476040 (fixed upstream).
- Remove patch for GNOME bug #477045 (fixed upstream).

evolution-data-server-2.21.2-1.fc9
----------------------------------
* Mon Nov 12 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.2-1.fc9
- Update to 2.21.2

* Mon Oct 29 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1-1.fc9
- Update to 2.21.1
- Bump eds_base_version to 2.22.
- Remove patch for RH bug #212106 (fixed upstream).
- Remove patch for GNOME bug #417999 (fixed upstream).

* Fri Oct 26 2007 Matthew Barnes <mbarnes at redhat.com> - 1.12.1-4.fc9
- Remove the use_gtk_doc macro.
- Remove redundant requirements.
- Use the name tag where appropriate.
- Add an evolution-data-server-doc subpackage.

evolution-exchange-2.21.2-1.fc9
-------------------------------
* Mon Nov 12 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.2-1.fc9
- Update to 2.21.2

flow-tools-0.68.3-1.fc9
-----------------------
* Mon Nov 12 2007 Paul P Komkoff Jr <i at stingr.net> - 0.68.3-1
- new upstream release
- build tools as PIE
- get rid of ftpaths.h
- do not ship ftconfig.c
- do not require libft

gcalctool-5.21.2-1.fc9
----------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 5.21.2-1
- Update to 5.21.2

* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 5.21.1-1
- Update to 5.21.1

geomview-1.9.4-5.fc9
--------------------
* Mon Nov 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.9.4-5
- fix x-oogl.desktop (to not include Patterns=*). doh.

gnome-menus-2.21.2-1.fc9
------------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

gnome-packagekit-0.1.3-1.fc9
----------------------------
* Mon Nov 12 2007 Robin Norwood <rnorwood at redhat.com> - 0.1.3-1
- Update to latest upstream version: 0.1.3

* Sun Nov 11 2007 Ray Strode <rstrode at redhat.com> - 0.1.2-2
- remove --vendor "gnome" from desktop-file-install calls. It's
  deprecated and changes the latest of .desktop files.

gnome-python2-desktop-2.20.0-2.fc9
----------------------------------
* Mon Nov 12 2007 Matthew Barnes <mbarnes at redhat.com> - 2.20.0-2.fc9
- Rebuild against newer libtotem-plparser.so.

gnome-screensaver-2.20.0-10.fc9
-------------------------------
* Mon Nov 12 2007 Dan Walsh <dwalsh at redhat.com> - 2.20.0-10
- Add pam_selinux_permit to pam config so that xguest will work properly

gnome-vfs2-2.20.1-1.fc9
-----------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (fixes a dns-sd crash)

* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Rebuild against new dbus-glib

* Tue Oct 16 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-3
- Also avoid showing /var/tmp as an icon on the desktop (#335241)

gnupg2-2.0.7-4.fc9
------------------
* Mon Nov 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 2.0.7-4
- Requires: kde-filesystem (#377841)

gnuplot-4.2.2-5.fc9
-------------------
* Mon Nov 12 2007 Ivana Varekova <varekova at redhat.com> - 4.2.2-5
- fix 373941 - add provides tag

gtk2-engines-2.13.0-1.fc9
-------------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 2.13.0-1
- Update to 2.13.0

gtkhtml3-3.17.2-1.fc9
---------------------
* Mon Nov 12 2007 Matthew Barnes <mbarnes at redhat.com> - 3.17.2-1.fc9
- Update to 3.17.2

gtksourceview2-2.0.1-1.fc9
--------------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 2.0.1-1
- Update to 2.0.1

jd-1.9.7-0.3.svn1508.fc9
------------------------
* Mon Nov 12 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.svn1508
- trunk 1508

* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

* Fri Nov 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyoa.c.jp> - 1.9.7-0.2.beta071101
- 1.9.7 beta 071101

kudzu-1.2.80-1
--------------
* Mon Nov 12 2007 Bill Nottingham <notting at redhat.com> 1.2.80-1
- make wireless devices ONBOOT=no by default (#374281)

libdrm-2.4.0-0.1.fc9
--------------------
* Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 2.4.0-0.1
- libdrm-2.4.0-no-freaking-mknod.patch: Don't magically mknod the device
  file, that's what udev is for.

libgnomecanvas-2.20.1-2.fc9
---------------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> 2.20.1-2
- Readd the scrolling patch, with an extra fix for redraw problems

* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> 2.20.1-1
- Update to 2.20.1 (translation updates)

* Tue Oct 09 2007 Matthias Clasen <mclasen at redhat.com> 2.20.0-2
- Take out the scrolling patch, since it causes redraw problems (#289281)

libwnck-2.21.2-1.fc9
--------------------
* Mon Nov 12 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2
- Drop upstreamed patch

libxcb-1.1-1.fc9
----------------
* Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 1.1-1
- libxcb 1.1
link-grammar-4.2.5-1.fc9
------------------------
* Mon Nov 12 2007 Marc Maurer <uwog at uwog.net> 4.2.5-1
- New upstream version, fixes bug 371221.

linuxdoc-tools-0.9.21-12.fc9
----------------------------
* Mon Nov 12 2007 Ondrej Vasik <ovasik at redhat.com> 0.9.21-12
- versioned obsoletes were before Version definition(#376671)

loudmouth-1.2.3-4.fc9
---------------------
* Mon Nov 12 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.2.3-4
- Add reconnect-failure patch. Thanks to Robert McQueen.

mesa-7.1-0.3.fc9
----------------
* Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 7.1-0.3
- Drop xserver 1.1 source compatibility.

* Wed Nov 07 2007 Dave Airlie <airlied at redhat.com> 7.1-0.2
- fix DRI driver directory

* Thu Nov 01 2007 Adam Jackson <ajax at redhat.com> 7.1-0.1
- Fix EVR, 7.1pre > 7.1, that would have been bad.
- Fix %setup to match.

moodle-1.8.3-2.fc9
------------------
* Mon Nov 12 2007 Jon Ciesla <limb at jcomserv.net> - 1.8.3-2
- Corrected init script to prevent starting by default.

nbd-2.9.7-3.fc8
---------------

nginx-0.5.33-1.fc9
------------------
* Sun Nov 11 2007 Jeremy Hinegardner <jeremy at hinegardner.org> - 0.5.33-1
- update to 0.5.33

ogre-1.4.5-2.fc9
----------------
* Mon Nov 12 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.4.5-2
- Ogre-Samples now takes the name of which samples to run as arguments, if no
  arguments are provided, it will run all of them like it used too (bz 377011)
- Don't install a useless / broken plugins.cfg in the Samples folder,
  Ogre-Samples will generate a correct one when run (bz 377011)

oprofile-0.9.3-7.fc9
--------------------
* Mon Nov 12 2007 Will Cohen <wcohen at redhat.com> - 0.9.3-7
- Should correct missing 'test' in patch.

perl-4:5.8.8-31.fc9
-------------------
* Mon Nov 12 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-31
- fix for CVE-2007-5116

* Thu Oct 18 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 4:5.8.8-30
- patch from perl bug 24254, fix for RH bz 114271

* Tue Oct 16 2007 Robin Norwood <rnorwood at redhat.com> - 4:5.8.8-29
- Add Artistic, AUTHORS, and Changes* to %docs.
- Compress Changes* to save space.

perl-Date-Calc-5.4-4.fc9
------------------------
* Mon Nov 12 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 5.4-4
- filtered out too many provides

perl-PDF-API2-0.66-1.fc9
------------------------
* Mon Nov 12 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.66-1
- 0.66

perl-Params-Validate-0.89-1.fc9
-------------------------------
* Tue Nov 13 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.89-1
- Upstream update.

perl-Text-Quoted-2.03-1.fc9
---------------------------
* Tue Nov 13 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.03-1
- Upstream update.

pilot-link-2:0.12.2-7.fc9
-------------------------
* Mon Nov 12 2007 Alex Lancaster <alexl at users.sourceforge.net> - 2:0.12.2-7
- Perl bindings need to be compiled after libpisock is installed

* Mon Nov 12 2007 Alex Lancaster <alexl at users.sourceforge.net> - 2:0.12.2-6
- Enable Perl bindings
- Include important docs such as README.usb

python-pygments-0.9-1.fc9
-------------------------

quagga-0:0.99.9-2.fc9
---------------------
* Mon Nov 12 2007 Martin Bacovsky <mbacovsk at redhat.com> - 0.99.9-2
- resolves: #376821: ospfd init script looks for ospf6 configuration and lock file
- resolves: #376841: Usage string in ospf6d init script incorrect

rhgb-1:0.17.7-3.fc9
-------------------
* Mon Nov 12 2007 Ray Strode <rstrode at redhat.com> 0.17.7-3
- downgrade rhgb to 0.17.7 to work around some problems that 
  aren't going to be fixed for a while (if at all).

* Tue Oct 16 2007 Ray Strode <rstrode at redhat.com> 8.0.1-1
- update to 8.0.1
- fixes crasher because of misplaced unref call

* Mon Oct 15 2007 Ray Strode <rstrode at redhat.com> 8.0.0-1
- update to 8.0.0
- buffer init messages while X starts to slightly improve boot time

roxterm-1.8.0-1.fc9
-------------------
* Mon Nov 12 2007 Sebastian Vahl <fedora at deadbabylon.de> - 1.8.0-1
- new upstream version: 1.8.0

rpm-4.4.2.2-8.fc9
-----------------
* Mon Nov 12 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-8
- Use NSS instead of beecrypt for cryptography, from Tomas Mraz (#348131)
- Update build + other dependencies accordingly

* Wed Oct 24 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-7
- Use package NEVRA everywhere for rpmProblems (#349091)
- The python problem addressed in -6 was related but a different issue...

* Wed Oct 24 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-6
- Don't mess up problem pkgNEVR in python ts.check() (#349091)

schroedinger-0.9.0-1.fc9
------------------------
* Mon Nov 12 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.0-1
- Update to 0.9.0
shorewall-4.0.5-1.fc9
---------------------
* Sat Oct 27 2007 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.0.5-1
- Update to 4.0.5 which removes the need for the buildports.pl functionality

* Mon Oct 08 2007 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.0.4-2
- Add ghost files for /var/lib/shorewall/.modules and /var/lib/shorewall/.modulesdir
- Fix ownership of /var/lib/shorewall-lite

* Sun Oct 07 2007 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.0.4-1
- Initial version 4 packaging based upon upstream specs by Tom Eastep and
  version 3 spec by Robert Marcano
- Split into shorewall-common, shorewall-shell, shorewall-perl,
  shorewall-lite subpackages

sip-4.7.1-2.fc9
---------------
* Mon Nov 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 4.7.1-2
- License: Python Software Foundation License v2
- fix/cleanup some macro usage
- fix Source, Url.

spandsp-0.0.4-0.7.pre15.fc9
---------------------------
* Thu Nov 01 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.0.4-0.7.pre15
- Update to 0.0.4pre15

tasks-0.12-1.fc9
----------------
* Wed Sep 05 2007 Dan Young <dyoung at mesd.k12.or.us> - 0.12-1
- New upstream release
- Patch out SingleInstance .desktop key

telepathy-glib-0.6.1-1.fc9
--------------------------
* Mon Nov 12 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.6.1-1
- Update to 0.6.1.

telepathy-mission-control-4.49-1.fc9
------------------------------------
* Mon Nov 12 2007 Sindre Pedersen Bj??rdal <foolish at guezz.net> - 4.49-1
- Bump to latest release

telepathy-salut-0.1.7-1.fc9
---------------------------
* Mon Nov 12 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.1.7-1
- Update to 0.1.7.

tetex-3.0-45.fc9
----------------
* Thu Nov 08 2007 Jindrich Novy <jnovy at redhat.com> 3.0-45
- fix t1lib flaw CVE-2007-4033 (#352271)
- fix CVE-2007-4352 CVE-2007-5392 CVE-2007-5393, various xpdf flaws (#345121)
- remove links to buildroot from installed files
- fix BuildRoot

* Tue Oct 16 2007 Jindrich Novy <jnovy at redhat.com> 3.0-44
- xdvi won't segfault if DVI file contains character which
  is not present in font (#243630)
- enable compilation with ccache

* Thu Aug 23 2007 Jindrich Novy <jnovy at redhat.com> 3.0-43
- update License
- rebuild for BuildID

tetex-tex4ht-1.0.2007_11_07_1645-1.fc9
--------------------------------------
* Sun Nov 11 2007 Patrice Dumas <pertusus at free.fr> 1.0.2007_11_07_1645-1
- update to 1.0.2007_11_07_1645

vpnc-0.5.1-2.fc9
----------------
* Tue Nov 13 2007 Tomas Mraz <tmraz at redhat.com> - 0.5.1-2
- try to make DPD less sensitive (#345281)

xcb-proto-1.1-1.fc9
-------------------

xgrav-1.2.0-5.fc9
-----------------
* Mon Nov 12 2007 Jon Ciesla <limb at jcomserv.net> - 1.2.0-5
- Release bump to fix F-8 EVR issue.

xorg-x11-proto-devel-7.3-6.fc9
------------------------------
* Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 7.3-6
- renderproto 0.9.3

Broken deps for i386
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	ruby-gtkmozembed - 0.16.0-14.fc9.i386 requires gecko-libs = 0:1.8.1.8
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1



Broken deps for x86_64
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	ruby-gtkmozembed - 0.16.0-14.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1



Broken deps for ppc
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc requires gecko-libs = 0:1.8.1.8



Broken deps for ppc64
----------------------------------------------------------
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc64 requires gecko-libs = 0:1.8.1.8





From sb at monkey-mind.net  Tue Nov 13 11:35:33 2007
From: sb at monkey-mind.net (Steven Bakker)
Date: Tue, 13 Nov 2007 12:35:33 +0100
Subject: fedora.com, is this for real?
In-Reply-To: <1194939252.7995.8.camel@rousalka.dyndns.org>
References: <fhatr5$6t6$1@ger.gmane.org>
	<80d7e4090711121824q5f5900a1q515684b6e2272b88@mail.gmail.com>
	<1194939252.7995.8.camel@rousalka.dyndns.org>
Message-ID: <20071113123533.5d5a2e74@cluestix.noc.ams-ix.net>

On Mon, 12 Nov 2007 19:24:01 -0700 Stephen John Smoogen wrote:

> > > http://www.fedora.com/
> > >
> > 
> > It looks like Network Solutions is back into the domain squatting
> > again

Heh, for a moment I thought SiteFinder was back. ;-)

However, it looks like the domain's been registered _through_ NetSol, but
not _by_ NetSol itself (read the paragraph at the bottom of the whois
output):

  This listing is a Network Solutions Private Registration. Mail
  correspondence to this address must be sent via USPS Express Mail(TM) or
  USPS Certified Mail(R); all other mail will not be processed. Be sure to
  include the registrant's domain name in the address.

IOW, NetSol is the registrar, not the registrant.

The "fedora.com" page (and others like it) links to www.information.com
and they seem to be the folks who registered this domain (along with a
bunch of others).

On Tue, 13 Nov 2007 08:34:12 +0100 Nicolas Mailhot wrote:

> The nice thing is that since it's clearly fedoraproject cybersquatting
> (as evidenced by the page content) should Red Hat lawyers
> challenge ?Network Solutions I don't see how they could justify
> before a judge keeping the domain.

This would be quite easy to do, I imagine:

  http://www.icann.org/udrp/udrp.htm

Cheers,
Steven



From paul at city-fan.org  Tue Nov 13 11:54:06 2007
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 13 Nov 2007 11:54:06 +0000
Subject: mono-devel on ppc and ppc64
In-Reply-To: <1194877434.8099.6.camel@T7.Linux>
References: <1194877434.8099.6.camel@T7.Linux>
Message-ID: <4739905E.80706@city-fan.org>

Paul wrote:
> I've submitted nant to koji and it fails on ppc and ppc64 when it looks
> for mono-devel in mock, but not on x86 or x86_64. Is there a hiccup
> somewhere or is it a problem with mock on koji not finding ppc and ppc64
> for mono-devel?


Dunno about ppc but no mono stuff is buildable on ppc64 AFAIK.


http://bugzilla.redhat.com/238950

Paul.



From dtimms at iinet.net.au  Tue Nov 13 12:00:44 2007
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 13 Nov 2007 23:00:44 +1100
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <1194940534.12691.31.camel@dhcp-208-188.arn.redhat.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>	<20071112124623.310b19d2@dhcp03.addix.net>	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>	<20071112164046.6e64ed0b@dhcp03.addix.net>	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>	<1194883648.2894.10.camel@localhost.localdomain>
	<1194940534.12691.31.camel@dhcp-208-188.arn.redhat.com>
Message-ID: <473991EC.5050609@iinet.net.au>

Alexander Larsson wrote:
> On Mon, 2007-11-12 at 11:07 -0500, Matthias Clasen wrote:
>> On Mon, 2007-11-12 at 16:48 +0100, Alexander Larsson wrote:
...
>> b) inherited capabilities, ie totem can display any format gstreamer can
>> handle, which in turn depends on installed plugins
Does a plugin for say totem rely on totem {ie cause it to be installed} ?

Or are the gstreamer plugins application agnostic ?

eg. Give me a type fred player -> gst-plugin-fred -> any 
gstreamer-capable app {which might be already installed}.

It should also list eg xmms-plugin-fred, which is another way to allow 
playback of the file type.

DaveT.



From dtimms at iinet.net.au  Tue Nov 13 12:07:26 2007
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 13 Nov 2007 23:07:26 +1100
Subject: "File Type" Buddy for Fedora 9?
In-Reply-To: <6c3f5e6c0711120445k3911b6d1w9b5c96c496354226@mail.gmail.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>	<20071112124623.310b19d2@dhcp03.addix.net>	<6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>	<4738490F.2040406@iinet.net.au>
	<6c3f5e6c0711120445k3911b6d1w9b5c96c496354226@mail.gmail.com>
Message-ID: <4739937E.6080206@iinet.net.au>

Andrew Parker wrote:
> repositories (a la yum) for the database.  then files that couldn't be
> opened by fedora rpms could be provided by other "repos".

This would open fedora to all types of security problems because the 
fedoraproject is not able to control/vet/modify external repos - and 
hence this capability is specifically disallowed in the fedora packaging 
process.

Having the current setup where a user goes to a web site, installs a 
x-release rpm, and then needs to accepting import of the repo's signing 
key means that it is the user who needs to decide whether they can trust 
repo x {which could do _anything_ on their machine}.

DaveT.



From jonathan.underwood at gmail.com  Tue Nov 13 12:11:52 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 13 Nov 2007 12:11:52 +0000
Subject: License review for new itext version
In-Reply-To: <1194884213.3198.16.camel@localhost.localdomain>
References: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
	<1194884213.3198.16.camel@localhost.localdomain>
Message-ID: <645d17210711130411g105e3979j4a168591cce76c5e@mail.gmail.com>

On 12/11/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
> The "disparaging Sun" license is gone, but the "nuclear" clause is still
> there in some of the classes.
>
> To reiterate what I said before:
>
> This is a use-case restriction:
> "You acknowledge that Software is not designed,licensed or intended for
> use in the design, construction, operation or maintenance of any nuclear
> facility."
>
> The word "licensed" is the problem here. Acknowledging that the software
> isn't designed or intended for any particular use case is fine, but when
> you say that the "software is not licensed for use...", then you're
> making a use case restriction.
>
> This is still no-go for Fedora, sorry.

I contacted upstream, but the relicensing the relevant files is not a
possibility for them, alas (they're not the original copyright holders
- Sun is).

As an aside, I wonder if distributing itext under the LGPL while
including those files licensed with the nuclear clause is not a
contradiction and invalid.

Jonathan.



From nicolas.mailhot at laposte.net  Tue Nov 13 12:12:51 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 13 Nov 2007 13:12:51 +0100 (CET)
Subject: /tftpboot vs. /var/tftp vs. something else?
Message-ID: <64320.192.54.193.53.1194955971.squirrel@rousalka.dyndns.org>


Le Mar 13 novembre 2007 11:49, Alexander Bostr?m a ?crit :

> The current usage of /var/lib doesn't really follow FHS, but packages
> touching /srv is also against the FHS, so that's not right either. I
> think the best thing to do here is to violate the FHS the same way
> everything else is doing and use /var/lib/tftp or stay in /tftpboot if
> you're not comfortable with the former.

I'd rather violate the FHS in the least possible way by choosing the
violation that's closer to the use case intent expressed in the spec,
but my views on the subject are well known.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Tue Nov 13 12:45:44 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 13 Nov 2007 13:45:44 +0100 (CET)
Subject: License review for new itext version
Message-ID: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>


Le Mar 13 novembre 2007 13:11, Jonathan Underwood a ?crit :

> I contacted upstream, but the relicensing the relevant files is not a
> possibility for them, alas (they're not the original copyright holders
> - Sun is).

Take it with SUN - they're celebrating the first anniversary of
openjdk right now.

-- 
Nicolas Mailhot



From jonathan.underwood at gmail.com  Tue Nov 13 12:52:52 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 13 Nov 2007 12:52:52 +0000
Subject: License review for new itext version
In-Reply-To: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
Message-ID: <645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>

On 13/11/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le Mar 13 novembre 2007 13:11, Jonathan Underwood a ?crit :
>
> > I contacted upstream, but the relicensing the relevant files is not a
> > possibility for them, alas (they're not the original copyright holders
> > - Sun is).
>
> Take it with SUN - they're celebrating the first anniversary of
> openjdk right now.

Happy to - is there anyone that is the obvious contact at Sun? I am
looking now, but don't see a useful contact on the openjdk page.



From sundaram at fedoraproject.org  Tue Nov 13 12:52:52 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 13 Nov 2007 18:22:52 +0530
Subject: License review for new itext version
In-Reply-To: <645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
	<645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
Message-ID: <47399E24.7000209@fedoraproject.org>

Jonathan Underwood wrote:
> On 13/11/2007, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>> Le Mar 13 novembre 2007 13:11, Jonathan Underwood a ?crit :
>>
>>> I contacted upstream, but the relicensing the relevant files is not a
>>> possibility for them, alas (they're not the original copyright holders
>>> - Sun is).
>> Take it with SUN - they're celebrating the first anniversary of
>> openjdk right now.
> 
> Happy to - is there anyone that is the obvious contact at Sun? I am
> looking now, but don't see a useful contact on the openjdk page.

The "Chief Open Source Officer" at Sun is Simon Phipps, webmink at 
sun.com. I doubt he is the person you want but he might be able to 
redirect the message to the right contact.

Rahul



From bnocera at redhat.com  Tue Nov 13 12:59:47 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 13 Nov 2007 12:59:47 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <6e24a8e80711121048x3ac87802nc9cdeff97f5d2b01@mail.gmail.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<604aa7910711120922l2967a1cwee94d5b719dd907e@mail.gmail.com>
	<6e24a8e80711121034o45eea84arbc7ea75940d97798@mail.gmail.com>
	<604aa7910711121036p6663cd39y6af5eee15cb64022@mail.gmail.com>
	<6e24a8e80711121048x3ac87802nc9cdeff97f5d2b01@mail.gmail.com>
Message-ID: <1194958787.3140.15.camel@cookie.hadess.net>


On Mon, 2007-11-12 at 19:48 +0100, Mark wrote:
> 2007/11/12, Jeff Spaleta <jspaleta at gmail.com>:
> > On Nov 12, 2007 9:34 AM, Mark <markg85 at gmail.com> wrote:
> > > I fully agree with that and hope that fedora is gonna put something
> > > like that in Codeina.
> >
> > How about... upstream put it in..and then Fedora or any other
> > distribution can make use of it?
> >
> > -jef
> 
> Than we would first need to find a way to make it even possible for
> other packages to add codec directives to codeina. I'm currently
> thinking that codeina should read the directory:
> /usr/share/codeina/xml where codeina should just read all the xml
> files. this can be a relative simple patch (if it's not done already..
> don't know) but i don't know if it's within the pm guidelines to add
> files insize the directory of another application
> (/usr/share/codeina/xml).. if that's no problem that this can be in
> quick. perhaps even i can make that patch..

This feature is already on the plans for F9, see:
http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy#head-5cb41960b4fbc6cef1d30689f536c1c0378d3484

Instructions on how to checkout the code are at the top of the page.
I'll be glad to receive your patch.

Cheers



From skvidal at fedoraproject.org  Tue Nov 13 13:00:58 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 13 Nov 2007 08:00:58 -0500
Subject: sending multiple (different) smolt profiles
In-Reply-To: <64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
	<Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
	<64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>
Message-ID: <1194958858.2025.19.camel@cutter>


On Tue, 2007-11-13 at 11:12 +0100, Valent Turkovic wrote:

> ps. I'm able to send profile only after 10 attempts, I usually get this error:
> 
> Send this information to the Smolt server? (y/n) y
> Error contacting Server: [Errno 14] HTTP Error 500: Internal error
> Could not send - Exiting
> 
> 
> or this one:
> 
> Send this information to the Smolt server? (y/n) y
> Error contacting Server: [Errno 12] Timeout: <urlopen error timed out>
> Could not send - Exiting


that might be related to the demand still being high on all of the boxes
in the coloc. It might also be to a memory leak in smolts server side.
I've given the process a restart to see if it helps it.

-sv




From bnocera at redhat.com  Tue Nov 13 13:09:52 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 13 Nov 2007 13:09:52 +0000
Subject: Codec Buddy misleading.
In-Reply-To: <Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
References: <1194613590.3255.10.camel@perihelion>
	<20071109142607.GB6603@roque.1407.org>
	<6e24a8e80711091003rf16c0e1v98d50af28b6fa377@mail.gmail.com>
	<20071109181111.GF6603@roque.1407.org>
	<6e24a8e80711091136uf4f12f3uf4cb8e2f5943a24e@mail.gmail.com>
	<20071109203142.GA6642@roque.1407.org>
	<20071109223601.GB5480@devserv.devel.redhat.com>
	<20071109235043.GB9111@roque.1407.org>
	<20071110003156.GA11246@devserv.devel.redhat.com>
	<20071110095657.GA6631@roque.1407.org>
	<20071110132139.GC6788@devserv.devel.redhat.com>
	<Pine.LNX.4.64.0711120029110.21249@newtla.xelerance.com>
	<1194848212.2306.55.camel@cookie.hadess.net>
	<Pine.LNX.4.64.0711121134020.26997@newtla.xelerance.com>
Message-ID: <1194959392.3140.23.camel@cookie.hadess.net>


On Mon, 2007-11-12 at 11:39 -0500, Paul Wouters wrote:
> On Mon, 12 Nov 2007, Bastien Nocera wrote:
> 
> > > However, I am still of the opinion that non-us people shouldn't be misled
> > > to buy things that they're fully entitled to from free and available
> > > software, just because of the main location of Fedora's main contributor
> > > (Red Hat). Which is why I think the Codec Buddy feature suggesting
> > > non-free software should be removed. Americans illegally installing
> > > livna rpms is not Red Hat's problem. Europeans mistakingly paying for
> > > non-free software is an issue for the Fedora Community.
> >
> > That is utter crock. If you know about the repositories, you probably
> > already have the packages installed already, or that window would remind
> > you to install them. If you don't know about them, we can't actually
> > point you at them.
> 
> Yes, we agree that people who know about this will ignore the new codec
> buddy. Or rephrased, "informed people won't accept the misinformation
> of needing to pay for codecs" (or if they are US users, will know that
> they can steal them).
> 
> It is the non-informed user that is harmed by the codec buddy. It just so
> happens that it only harms non-US citizens, so this solution is deemed
> "not a problem" for Red Hat because they are a US company. That is the
> essence of the problem here.

Feel free to propose changes to the warning popup so that European users
aren't confused.

> > The bottom line is that people who didn't know how to get playback
> > software for their videos and music will now know how to, or at least
> > have a way to.
> 
> So you are also in favour of not telling people about free health care,
> as long as they know how to find a doctor they can pay? That's really a
> non argument. Red Hat is basically ripping of non-US citizens via a
> business partner.

They're not a business partner, and Red Hat isn't making any profit from
it. I would also avoid big brush-stroke comparisons as well. A 30-euro
one-off payment for a European user that can afford a computer is hardly
akin to having to pay for your healthcare.

> > In fact, most of this software and the way it made it in Fedora was done
> > in Britain and Spain. So I'm not buying the "martyr from Europe who
> > shelled out 30 euros" story.
> 
> Obviously in cooperation and under ultimate decisions of releng and its
> lawyers. So this argument also makes no sense.

Lawyers didn't come into questions, because we weren't doing anything
legally questionable, and the only people with a word into adding the
feature were FESCo, for which you can run yourself.



From bnocera at redhat.com  Tue Nov 13 13:13:42 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 13 Nov 2007 13:13:42 +0000
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
Message-ID: <1194959622.3140.26.camel@cookie.hadess.net>


On Mon, 2007-11-12 at 12:38 +0100, Mark wrote:
> Hey,
> 
> A few days ago i installed Audacious on my Fedora 8 and it works fine!
> no issue with that. But now i wanted to open up a .m3u file extension
> and fedora didn't know what to do with it.. so i had to select the
> audio player for it manually (Audacious). And there are a lot more
> extensions that fedora doesn't know of. .m3u is just an example.
> 
> Now because of this i'm wondering if it would be a good idea to have a
> "Codec Budde" for the extensions (lets call it Extension Buddy) that
> fixes extensions for files if the program than can play it is
> installed or that it shows a list of possible applications that can
> handle that extension (like Codec Buddy with the codecs) or that it
> lets you select a default application for every single extension (that
> last part is needed in linux).
> 
> So what do you think of it?
> good idea? bad idea?

Good idea, and it's already been discussed on fedora-desktop-list. See
the thread at:
https://www.redhat.com/archives/fedora-desktop-list/2007-June/msg00034.html

We're just missing implementation.



From bnocera at redhat.com  Tue Nov 13 13:17:00 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 13 Nov 2007 13:17:00 +0000
Subject: "Extension Buddy" for Fedora 9?
In-Reply-To: <20071112200943.78a6bdb8@pensja.lam.pl>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6c3f5e6c0711120417m3daac501q1f26e945edef19c0@mail.gmail.com>
	<1194870920.12691.13.camel@dhcp-208-188.arn.redhat.com>
	<20071112164046.6e64ed0b@dhcp03.addix.net>
	<1194882531.12691.25.camel@dhcp-208-188.arn.redhat.com>
	<1194883648.2894.10.camel@localhost.localdomain>
	<20071112200943.78a6bdb8@pensja.lam.pl>
Message-ID: <1194959820.3140.31.camel@cookie.hadess.net>


On Mon, 2007-11-12 at 20:09 +0100, Leszek Matok wrote:
> Dnia 2007-11-12, o godz. 11:07:28 Matthias Clasen <mclasen at redhat.com>
> napisa?(a):
> 
> > a) editor vs viewer
> True.
> 
> > b) inherited capabilities, ie totem can display any format gstreamer can
> > handle, which in turn depends on installed plugins
> Right now Totem claims to be able to play any multimedia files even though it
> really can't (because by default plugins for the most prominent formats like
> DVD aren't installed). The solution here is to switch

DVD support isn't advertised anywhere in the mime-types.

> MimeType=(...)
> into
> MimeTypeDir=/usr/lib/gstreamer-x.xx/mime.types.d
> and let plugins put appropriate files there (also, make the rpm macro
> understand the new flag). This way Nautilus (or rather some helper app) would
> know (from rpmdb or better, yum's cache), which package you have to install to
> be able to play a file in Totem (or any gstreamer application using my
> MimeTypeDir).

That fixes the problem for container formats, but not codecs, which
might or might not be supported by the installation. An example is the
default Fedora installation that can handle AVI and MKV files properly,
but can't play the MPEG-4 video or MP3 audio used in most of those.



From alan at redhat.com  Tue Nov 13 13:32:14 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 13 Nov 2007 08:32:14 -0500
Subject: fedora.com, is this for real?
In-Reply-To: <fhatr5$6t6$1@ger.gmane.org>
References: <fhatr5$6t6$1@ger.gmane.org>
Message-ID: <20071113133214.GD16446@devserv.devel.redhat.com>

On Mon, Nov 12, 2007 at 08:15:17PM -0500, Neal Becker wrote:
> Uh, is this for real or what?
> 
> http://www.fedora.com/

Historically fedora.com was nothing to do with the Fedora Project (or various
other Fedora projects). Seems someone has sold it to a domain park. That may
be very good news as it offers links and references to Fedora Linux so now
may be abusing the trademark when it wasn't in the past.

Possibly a good chance to obtain the domain either nicely or because its
now apparently misusing our marks (Fedora Linux etc) in the content.



From alan at redhat.com  Tue Nov 13 13:35:11 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 13 Nov 2007 08:35:11 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1194927628.6083.3.camel@localhost6.localdomain6>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
Message-ID: <20071113133511.GE16446@devserv.devel.redhat.com>

On Mon, Nov 12, 2007 at 09:20:28PM -0700, Richi Plana wrote:
> On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:jA
> > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?

/tftpboot is the historical tradition going back about thirty years. Why
break every script, every book and every third party management tool ?

> I would suggest /srv/tftpboot/. If not that, then I really can't think
> of any other place. There's no lib to put in /var/lib/. /var/cache/
> sounds too temporary. /var/share/? Is there such a thing?

/srv is not available to distribution vendors.

Alan



From alan at redhat.com  Tue Nov 13 13:42:39 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 13 Nov 2007 08:42:39 -0500
Subject: License review for new itext version
In-Reply-To: <645d17210711130411g105e3979j4a168591cce76c5e@mail.gmail.com>
References: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
	<1194884213.3198.16.camel@localhost.localdomain>
	<645d17210711130411g105e3979j4a168591cce76c5e@mail.gmail.com>
Message-ID: <20071113134239.GG16446@devserv.devel.redhat.com>

On Tue, Nov 13, 2007 at 12:11:52PM +0000, Jonathan Underwood wrote:
> As an aside, I wonder if distributing itext under the LGPL while
> including those files licensed with the nuclear clause is not a
> contradiction and invalid.

I would agree with that distinction unless the files are a seperate non-LGPL
work the LGPL code uses. One for Sun to fix.



From aph at redhat.com  Tue Nov 13 13:54:24 2007
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Nov 2007 13:54:24 +0000
Subject: License review for new itext version
In-Reply-To: <645d17210711121022w187d78c6i46f7725b1df701e0@mail.gmail.com>
References: <38333.192.54.193.53.1194883657.squirrel@rousalka.dyndns.org>
	<1194884213.3198.16.camel@localhost.localdomain>
	<645d17210711121022w187d78c6i46f7725b1df701e0@mail.gmail.com>
Message-ID: <18233.44176.650598.542451@zebedee.pink>

Jonathan Underwood writes:
 > On 12/11/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
 > > To reiterate what I said before:
 > >
 > > This is a use-case restriction:
 > > "You acknowledge that Software is not designed,licensed or intended for
 > > use in the design, construction, operation or maintenance of any nuclear
 > > facility."
 > >
 > > The word "licensed" is the problem here. Acknowledging that the software
 > > isn't designed or intended for any particular use case is fine, but when
 > > you say that the "software is not licensed for use...", then you're
 > > making a use case restriction.
 > >
 > > This is still no-go for Fedora, sorry.
 > 
 > That's a real shame. I'll try contacting the itext authors to see if
 > anything can be done.

In exactly which file is this clause?

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From lesmikesell at gmail.com  Tue Nov 13 13:59:37 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 13 Nov 2007 07:59:37 -0600
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <1194938520.7995.4.camel@rousalka.dyndns.org>
References: <57529.192.54.193.53.1194884642.squirrel@rousalka.dyndns.org>	<47389323.6060004@gmail.com>	<1194891205.27768.22.camel@rousalka.dyndns.org>	<4738B53C.6070503@gmail.com>	<1194906646.27768.64.camel@rousalka.dyndns.org>	<4738EB04.6090501@gmail.com>
	<1194938520.7995.4.camel@rousalka.dyndns.org>
Message-ID: <4739ADC9.4050804@gmail.com>

Nicolas Mailhot wrote:

>>> You usually need some time in a support/sysadmin position managing
>>> systems built by developers from SCM dumps (or god forbid production
>>> systems directly re-build from developer SCM-plugged RAD IDE
>>> environments) to appreciate the difference.
>> I do know the difference - a company where I worked for years had one 
>> group that was religious about deployment builds being based strictly on 
>> tags and the SCM containing everything necessary for the build and 
>> another that did a lot of hand tweaking and could only do the build on 
>> one machine that nobody remembered how to reconstruct.  A patient QA 
>> dept. was the only thing that let the latter group survive.
> 
> Then I'm surprised you assume we'd find mostly group1s on the internet
> and not a huge majority of group2s.

To be fair, the nature of the 2 products were different.  Group 1 was 
server-side and had to be able to immediately back out any problematic 
changes, and had to plan out strict deployment procedures that operators 
could follow.  Group 2 was client-side and fixed everything with yet 
another build/release, rarely looking back and with users dealing with 
the work of tracking the updates. So, I suppose I should only expect the 
  strict SCM tracking from projects where the group actually relies on 
their own work for something critical.  However, other than some time 
planning the build process around the SCM so you give it a tag and it 
builds that version and making sure all the needed tools and build 
scripts were checked in, there really was no extra overhead in group 1's 
work.

>> but the 
>> best you'll probably do with internet development is to glue a bug 
>> tracker to the revision number.
> 
> Ie chances to get it to work given the breadth of software we package
> are slim to inexistent.

What about the kernel as a starting point?  It would be particularly 
interesting if the popular distro kernels all existed as branches.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From johnp at redhat.com  Tue Nov 13 14:02:48 2007
From: johnp at redhat.com (John (J5) Palmieri)
Date: Tue, 13 Nov 2007 09:02:48 -0500
Subject: When will CVS be replaced by modern version control system?
In-Reply-To: <20071112112255.7f8a091d@redhat.com>
References: <1194532269.8249.24.camel@shaptop.om-md.eros-os.com>
	<20071108094720.1a18ded1@redhat.com> <47385F5B.50401@redhat.com>
	<sb4m05xsto.ln2@hubmaier.ceplovi.cz>
	<20071112083542.6be464e3@vader.jdub.homelinux.org>
	<47386559.6030202@redhat.com> <20071112094037.507a153c@redhat.com>
	<02am05xce4.ln2@hubmaier.ceplovi.cz>
	<20071112112255.7f8a091d@redhat.com>
Message-ID: <1194962568.1385.64.camel@localhost.localdomain>


On Mon, 2007-11-12 at 11:22 -0500, Jesse Keating wrote:
> On Mon, 12 Nov 2007 17:02:40 +0100
> Matej Cepl <mcepl at redhat.com> wrote:
> 
> > I am not really sure, that it means that -- I am not saying "never
> > ever use upstream tarball, ever." My idea would be that koji would
> > get couple of backends and Source could be more creative. So instead
> > of just "download tarball from this URL, unpack and work", it could
> > understand alos URLs like git://, bzr://, hg:// (or something like
> > that), meaning "clone/checkout/<whatever is the local name of getting
> > the sources> from somewhere, and then build over that". And of
> > course, one of these methods of getting sources would be downloading
> > tarball.
> 
> And now your buildsystem is entirely reliant upon upstream locations
> staying up, staying consistent, not being compromised, etc...
> Definitely not something you want for Fedora, and certainly not
> something we can even consider for RHEL.
> 

A better way and one of the tools I am looking into building is to have
an external client which can pull from tarball locations or any RCS tag
to build new versions of packages at the touch of a button.  This would
solve the issue of it being time consuming to simply package up new
releases.  There have been other discussing changing how we keep track
or upstream sources and in fact the X packages are now managed through a
tarred up git tree I believe.  In any case the backend isn't as
important as the frontend we give to developers to make them more
efficient.

I guess this is a good point to introduce myself and my new role to the
Fedora Infrastructure community (and those who use it).  Those who don't
know me, my name is John Palmieri though people in the development
community just call me J5.  I'm one of the D-Bus maintainers and
GtkPrint creators and have worked on Red Hat's Desktop Team as well as
being a build master and Fedora integration point for the OLPC project.

I've have recently been tasked within Red Hat to find ways to make
consumers of the infrastructure more efficient.  My previous role as the
build master for OLPC made me realize that there are huge hurdles to
contributing and maintaining various elements within Fedora.  My job is
to make it easier by working with the different groups with the Fedora
Infrastructure so that we are all on the same page as well as defining
areas which need more attention or perhaps need a project to be created
to fill in the gaps.  

Fedora is steaming ahead at an awesome pace and it gets better and
better each day.  I believe in keeping that pace of innovation going
while I work to get all of the distractions and roadblocks out of the
developer's way.  As I ease into my new role I am looking forward to
discussing ideas on the list and at the next FUDCon.

-- 
John (J5) Palmieri <johnp at redhat.com>



From pertusus at free.fr  Tue Nov 13 14:05:43 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Nov 2007 15:05:43 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1194950980.31176.38.camel@home.alexander.bostrom.net>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473942E7.6010706@gmail.com> <20071113081717.GA2574@free.fr>
	<1194950980.31176.38.camel@home.alexander.bostrom.net>
Message-ID: <20071113140543.GA2582@free.fr>

On Tue, Nov 13, 2007 at 11:49:40AM +0100, Alexander Bostr?m wrote:
> 
> Btw, "lib/foo" is not about shared objects for foo, it's "here goes
> things belonging to foo", regardless of if it's /var/lib or /usr/lib.
> Don't be confused by "lib". Remember, this is Un*x, it's evolved, not
> logical. Do you think your genes are nicely commented and using pretty
> variable names? :)

It is a bit more complicated since /usr/share/foo and /usr/lib64/foo is
also for "things belonging to foo". I never made the hypothesis that
/var/lib is for shared libs, and in fact it is not. But if you read the
FHS, srv is clearly for tftpboot stuff:

/srv contains site-specific data which is served by this system.

while /var/lib is more for local databases (like nis, rpm, locate, 
yum...). Though this may also be the best place for what is in /srv if
the convention is that the distribution does not touch /srv.

--
Pat



From jonathan.underwood at gmail.com  Tue Nov 13 14:16:22 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 13 Nov 2007 14:16:22 +0000
Subject: License review for new itext version
In-Reply-To: <47399E24.7000209@fedoraproject.org>
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
	<645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
	<47399E24.7000209@fedoraproject.org>
Message-ID: <645d17210711130616m372c569ctb2cb0f702e4998ab@mail.gmail.com>

On 13/11/2007, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> The "Chief Open Source Officer" at Sun is Simon Phipps, webmink at
> sun.com. I doubt he is the person you want but he might be able to
> redirect the message to the right contact.

Thanks, have written him an email.

Jonathan.



From jkeating at redhat.com  Tue Nov 13 14:30:30 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 13 Nov 2007 09:30:30 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113133511.GE16446@devserv.devel.redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
Message-ID: <20071113093030.6d358d2a@redhat.com>

On Tue, 13 Nov 2007 08:35:11 -0500
Alan Cox <alan at redhat.com> wrote:

> /tftpboot is the historical tradition going back about thirty years.
> Why break every script, every book and every third party management
> tool ?


So we should be like Solaris and have links to all the executables
in /etc/ right?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/b823c1b4/attachment.sig>

From alan at redhat.com  Tue Nov 13 14:43:47 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 13 Nov 2007 09:43:47 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113093030.6d358d2a@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<20071113093030.6d358d2a@redhat.com>
Message-ID: <20071113144347.GA20148@devserv.devel.redhat.com>

On Tue, Nov 13, 2007 at 09:30:30AM -0500, Jesse Keating wrote:
> So we should be like Solaris and have links to all the executables
> in /etc/ right?

We had good reasons for moving executables out of /etc. I don't see what
good reasons we have for breaking /tftpboot. Remember most tools don't care
about executable paths but use search paths. This is not true for configuration
and data



From myfedora at richip.dhs.org  Tue Nov 13 14:57:37 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 13 Nov 2007 07:57:37 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113144347.GA20148@devserv.devel.redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<20071113093030.6d358d2a@redhat.com>
	<20071113144347.GA20148@devserv.devel.redhat.com>
Message-ID: <1194965857.10599.7.camel@localhost6.localdomain6>

On Tue, 2007-11-13 at 09:43 -0500, Alan Cox wrote:
> On Tue, Nov 13, 2007 at 09:30:30AM -0500, Jesse Keating wrote:
> > So we should be like Solaris and have links to all the executables
> > in /etc/ right?
> 
> We had good reasons for moving executables out of /etc. I don't see what
> good reasons we have for breaking /tftpboot. Remember most tools don't care
> about executable paths but use search paths. This is not true for configuration
> and data

In this case, the move might not be revolutionary, but it would be good
evolution. There was no good reason for putting the files in /tftpboot/,
but reasons for moving it now could include: 1) better management of
filesystem resources, 2) ease-of-entry for new administrators (finding
all services data in one, logical subdirectory) and 3) finally getting
some semblance of reason for where files are being placed in Unix. Even
SELinux policies might benefit from a reorg.

Things are slowly starting to get better for the *nix world because
Linux wasn't resistant to change for its users' sake (rather than some
keeping the status quo for *nix gurus' comfort). We're just exploring
what could be better in this case.
--

Richi Plana



From lmacken at redhat.com  Tue Nov 13 04:49:52 2007
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 12 Nov 2007 23:49:52 -0500
Subject: bodhi-client
Message-ID: <20071113044952.GV11043@crow.myhome.westell.com>

The bodhi-client package should be making its way to an updates-testing
repository near you! (and a newer version is already queued up for tomorrow).
Not only does this command-line tool give you easier access to bodhi, but also
provides some new features to help people get more involved with testing
updates and providing useful feedback.

I wrote up some documentation on various usage examples of the tool, which can
be found on the wiki[0].  I also submitted a Makefile.common patch[1] that,
once applied, will allow you to run `make update` from your package branch.
This will drop you into a new update template, and will then submit your update
straight to bodhi.

Some noteworthy features in the bodhi-client, aside from the normal bodhi
functionality:

  ? Ability to view all updates-testing packages that you currently have
    installed on your local machine, that you *could* be testing and providing
    useful feedback for:
    ? bodhi --testable
  ? Ability to view your update candidates (this is a fairly expensive
    operation -- please use sparingly):
    ? bodhi --candidates

I also upgraded our production bodhi instance today, which pulled in a ton of
bugfixes and some new features, such as:

  ? Updates by default will now get submitted to into testing.  This can easily
    be modified when using the web form, the bodhi client, and `make update`.
  ? Thanks to the new security bug tracking policy[2], we're now tracking CVEs
    using Bugzilla, thus bodhi no longer will ask you for CVE IDs.  The less
    information that the developer has to type, the better.  Read the policy
    for more details.  Bodhi is not yet 100% compliant to the proposed changes,
    as it does not know about parent/tracking bugs, but should be soon.
  ? If you try and submit an update that is older than something already
    pending/testing, you will be prompted with a dialog that will give you the
    ability to instantly obsolete those updates.

As always, patches/questions/criticisms/comments are welcome. You can file
tickets in the usual place[3].

Happy hacking,

luke

[0]: https://hosted.fedoraproject.org/projects/bodhi/wiki/CLI
[1]: http://lmacken.fedorapeople.org/patches/Makefile.common-bodhi.patch
[2]: http://fedoraproject.org/wiki/Security/TrackingBugs
[3]: https://hosted.fedoraproject.org/projects/bodhi/newticket

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From myfedora at richip.dhs.org  Tue Nov 13 15:05:34 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 13 Nov 2007 08:05:34 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113133511.GE16446@devserv.devel.redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
Message-ID: <1194966334.10599.14.camel@localhost6.localdomain6>

On Tue, 2007-11-13 at 08:35 -0500, Alan Cox wrote:
> /srv is not available to distribution vendors.

The funny thing about this situation is that /srv/ was reserved for use
by the end-users, and as an end-user, that's exactly what I want ... but
all the default server data subdirectories are everywhere else
but /srv/. No one seems willing or knowledgeable enough to move things
to /srv/ even though they really want to (as evidenced by the number of
people clamoring for moves every now and then in the list). No
distribution makes it easy for administrators to choose a subdirectory
for their server data (by easy, I mean via the GUI tools).

These days, when I install some server package, I can usually find the
configuration information inside /etc/<servicename>/ or similar.
Supporting shared objects and libraries in /usr/lib(64)?/, data files
in /usr/share/<name>/, but the data files are all over the place.
--

Richi Plana



From cra at WPI.EDU  Tue Nov 13 15:10:59 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 13 Nov 2007 10:10:59 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113140543.GA2582@free.fr>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473942E7.6010706@gmail.com> <20071113081717.GA2574@free.fr>
	<1194950980.31176.38.camel@home.alexander.bostrom.net>
	<20071113140543.GA2582@free.fr>
Message-ID: <20071113151059.GA25455@angus.ind.WPI.EDU>

On Tue, Nov 13, 2007 at 03:05:43PM +0100, Patrice Dumas wrote:
> It is a bit more complicated since /usr/share/foo and /usr/lib64/foo is
> also for "things belonging to foo". I never made the hypothesis that
> /var/lib is for shared libs, and in fact it is not. But if you read the
> FHS, srv is clearly for tftpboot stuff:
> 
> /srv contains site-specific data which is served by this system.

It sounds like FHS needs to be updated with a specification for /srv 
that allows vendor stuff and local stuff, e.g. /srv vs. /srv/local.  
Or /srv/vendor if you don't want to mess with existing use.

We need to standardize on places to put site-specific data which is 
served by this system, for SELinux reasons among others.  /srv/ftp, 
/srv/tftp, /srv/www, all would make sense.

> while /var/lib is more for local databases (like nis, rpm, locate, 
> yum...). Though this may also be the best place for what is in /srv if
> the convention is that the distribution does not touch /srv.

I'd be okay with using /var/lib/tftp since there seems to be precedent 
for that, and it breaks FHS the "least".

My argument was mainly against /tftpboot since / might be too small or 
read-only.



From selinux at gmail.com  Tue Nov 13 15:12:08 2007
From: selinux at gmail.com (Tom London)
Date: Tue, 13 Nov 2007 07:12:08 -0800
Subject: rawhide report: 20071113 changes
In-Reply-To: <200711131130.lADBUM87016824@porkchop.devel.redhat.com>
References: <200711131130.lADBUM87016824@porkchop.devel.redhat.com>
Message-ID: <4c4ba1530711130712y175e987dxb718e5f53425ff4@mail.gmail.com>

On Nov 13, 2007 3:30 AM, Build System <buildsys at redhat.com> wrote:

> mesa-7.1-0.3.fc9
> ----------------
> * Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 7.1-0.3
> - Drop xserver 1.1 source compatibility.
>
> * Wed Nov 07 2007 Dave Airlie <airlied at redhat.com> 7.1-0.2
> - fix DRI driver directory
>
> * Thu Nov 01 2007 Adam Jackson <ajax at redhat.com> 7.1-0.1
> - Fix EVR, 7.1pre > 7.1, that would have been bad.
> - Fix %setup to match.
>

This appears to break compiz for me. Backing out 'makes it work again'.

.xsession-errors said something about not finding a manageable display.

[Thinkpad with 'intel' driver.]

tom
-- 
Tom London



From snecklifter at gmail.com  Tue Nov 13 15:14:29 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Tue, 13 Nov 2007 15:14:29 +0000
Subject: kernel-PAE and NX (No eXecute)
In-Reply-To: <200711122008.08668.opensource@till.name>
References: <200711122008.08668.opensource@till.name>
Message-ID: <364d303b0711130714h74577688yc3863ad991b615b8@mail.gmail.com>

Hello Till,

On 12/11/2007, Till Maas <opensource at till.name> wrote:
> Hiyas,
>
> is still the kernel-PAE kernel needed in Fedora to use NX (No eXcute)? I read
> that the 2.6.23 kernel supports NX without the need to activate 64G memory
> support? If PAE for NX is not yet enabled in the normal kernel package, can
> we enable it and rename the -PAE package to e.g. HIGHMEM64 or similiar, to
> make it more obvious what it is useful for?

Probably better to be asked on the fedora-kernel list. If you don't
want to subscribe I'm happy to ask on your behalf as I don't have the
answer.

Cheers
Chris


-- 
http://www.chruz.com



From cra at WPI.EDU  Tue Nov 13 15:16:41 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 13 Nov 2007 10:16:41 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1194966334.10599.14.camel@localhost6.localdomain6>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<1194966334.10599.14.camel@localhost6.localdomain6>
Message-ID: <20071113151641.GB25455@angus.ind.WPI.EDU>

On Tue, Nov 13, 2007 at 08:05:34AM -0700, Richi Plana wrote:
> On Tue, 2007-11-13 at 08:35 -0500, Alan Cox wrote:
> > /srv is not available to distribution vendors.
> 
> The funny thing about this situation is that /srv/ was reserved for use
> by the end-users, and as an end-user, that's exactly what I want ... but
> all the default server data subdirectories are everywhere else
> but /srv/. No one seems willing or knowledgeable enough to move things
> to /srv/ even though they really want to (as evidenced by the number of
> people clamoring for moves every now and then in the list). No
> distribution makes it easy for administrators to choose a subdirectory
> for their server data (by easy, I mean via the GUI tools).
> 
> These days, when I install some server package, I can usually find the
> configuration information inside /etc/<servicename>/ or similar.
> Supporting shared objects and libraries in /usr/lib(64)?/, data files
> in /usr/share/<name>/, but the data files are all over the place.

+100.  We should make it easy for users to put their data in /srv, and 
that means making it easy to change server configs and SELinux file 
contexts for /srv/wherever-the-user-wants to match the vendor data 
locations e.g. /var/www, /var/ftp, /var/lib/mysql, etc.



From rdieter at math.unl.edu  Tue Nov 13 15:31:12 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 13 Nov 2007 09:31:12 -0600
Subject: openssl097a package retirement
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
	<3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
	<1194900390.17465.37.camel@vespa.kabelta.loc>
Message-ID: <fhcg00$jul$1@ger.gmane.org>

Tomas Mraz wrote:

> But I'm curious why HTTrack
> dlopens it and not directly links to it.

HTTrack is GPL, and openssl isn't GPL-compatible.

-- Rex




From notting at redhat.com  Tue Nov 13 15:34:02 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 10:34:02 -0500
Subject: openssl097a package retirement
In-Reply-To: <fhcg00$jul$1@ger.gmane.org>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
	<3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
	<1194900390.17465.37.camel@vespa.kabelta.loc>
	<fhcg00$jul$1@ger.gmane.org>
Message-ID: <20071113153402.GA5755@nostromo.devel.redhat.com>

Rex Dieter (rdieter at math.unl.edu) said: 
> Tomas Mraz wrote:
> 
> > But I'm curious why HTTrack
> > dlopens it and not directly links to it.
> 
> HTTrack is GPL, and openssl isn't GPL-compatible.

Right, but there's nothing that says upstream can't add an exception
for OpenSSL.

Bill



From smooge at gmail.com  Tue Nov 13 15:34:10 2007
From: smooge at gmail.com (Stephen John Smoogen)
Date: Tue, 13 Nov 2007 08:34:10 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113133511.GE16446@devserv.devel.redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
Message-ID: <80d7e4090711130734u431568e4wd88e240427c0e02a@mail.gmail.com>

On Nov 13, 2007 6:35 AM, Alan Cox <alan at redhat.com> wrote:
> On Mon, Nov 12, 2007 at 09:20:28PM -0700, Richi Plana wrote:
> > On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:jA
> > > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
>
> /tftpboot is the historical tradition going back about thirty years. Why
> break every script, every book and every third party management tool ?
>

What would be the proper RFC process to go over such a change? As in
say creating a /srv/fedora/ and start populating it with data or some
such? Or say putting in a notice that we would like to move /tftpboot
to something else and please give us feedback on how we can accomplish
this with the least amount of pain, and then putting it to a proper
engineering group to vote on it?


> > I would suggest /srv/tftpboot/. If not that, then I really can't think
> > of any other place. There's no lib to put in /var/lib/. /var/cache/
> > sounds too temporary. /var/share/? Is there such a thing?
>
> /srv is not available to distribution vendors.
>
> Alan
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From mspevack at redhat.com  Tue Nov 13 15:52:13 2007
From: mspevack at redhat.com (Max Spevack)
Date: Tue, 13 Nov 2007 10:52:13 -0500 (EST)
Subject: fedora.com, is this for real?
In-Reply-To: <20071113133214.GD16446@devserv.devel.redhat.com>
References: <fhatr5$6t6$1@ger.gmane.org>
	<20071113133214.GD16446@devserv.devel.redhat.com>
Message-ID: <alpine.LFD.0.9999.0711131050510.13802@localhost.localdomain>

On Tue, 13 Nov 2007, Alan Cox wrote:

> Possibly a good chance to obtain the domain either nicely or because 
> its now apparently misusing our marks (Fedora Linux etc) in the 
> content.

I have asked the folks within Red Hat who handle all the domain stuff to 
look into what it would take to get Fedora.com

If there is anything interesting to report back, I will!

--Max



From dyoung at mesd.k12.or.us  Tue Nov 13 16:11:55 2007
From: dyoung at mesd.k12.or.us (Dan Young)
Date: Tue, 13 Nov 2007 08:11:55 -0800
Subject: rpms/tasks/devel .cvsignore, 1.8, 1.9 sources, 1.8,
	1.9 tasks.spec, 1.10, 1.11
In-Reply-To: <1194925077.30963.1.camel@tuxhugs>
References: <200711130319.lAD3JTNx028488@cvs-int.fedora.redhat.com>
	<1194925077.30963.1.camel@tuxhugs>
Message-ID: <994441ae0711130811l51f79eaam73b4622e7cd7ef5d@mail.gmail.com>

On 11/12/07, Peter Gordon <peter at thecodergeek.com> wrote:
> On Mon, 2007-11-12 at 22:19 -0500, Daniel M. Young wrote:
> > Modified Files:
> >       .cvsignore sources tasks.spec
> > Log Message:
> > New upstream version: tasks-0.12
>
> Don't forget to "cvs add" and commit the patch, too. Otherwise, Koji
> won't be able to properly create the SRPM when when you attempt to build
> it.

Yeah, caught that right after the commit. That's what I get for trying
cram the update in during the post-dinner, pre-bath Wiggles episode.

-- 
Dan Young <dyoung at mesd.k12.or.us>
Multnomah ESD - Technology Services
503-257-1562



From notting at redhat.com  Tue Nov 13 16:26:17 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 11:26:17 -0500
Subject: [PATCH] Makefile.common: define specdir
Message-ID: <20071113162617.GA20041@nostromo.devel.redhat.com>

If we set SOURCEDIR, RPMDIR, etc., we should really define _specdir too.

Anyone see any issues with this?

Bill
-------------- next part --------------
Index: Makefile.common
===================================================================
RCS file: /cvs/extras/common/Makefile.common,v
retrieving revision 1.80
diff -u -r1.80 Makefile.common
--- Makefile.common	30 Oct 2007 18:33:33 -0000	1.80
+++ Makefile.common	13 Nov 2007 16:25:16 -0000
@@ -75,9 +75,13 @@
 ifndef SOURCEDIR
 SOURCEDIR := $(shell pwd)
 endif
+ifndef SPECDIR
+SPECDIR := $(shell pwd)
+endif
 
 ifndef RPM_DEFINES
 RPM_DEFINES = --define "_sourcedir $(SOURCEDIR)" \
+		--define "_specdir $(SPECDIR)" \
 		--define "_builddir $(BUILDDIR)" \
 		--define "_srcrpmdir $(SRCRPMDIR)" \
 		--define "_rpmdir $(RPMDIR)" \

From jkeating at redhat.com  Tue Nov 13 16:28:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 13 Nov 2007 11:28:26 -0500
Subject: [PATCH] Makefile.common: define specdir
In-Reply-To: <20071113162617.GA20041@nostromo.devel.redhat.com>
References: <20071113162617.GA20041@nostromo.devel.redhat.com>
Message-ID: <20071113112826.510f0564@redhat.com>

On Tue, 13 Nov 2007 11:26:17 -0500
Bill Nottingham <notting at redhat.com> wrote:

> If we set SOURCEDIR, RPMDIR, etc., we should really define _specdir
> too.
> 
> Anyone see any issues with this?

Did you run into a problem with not specifying it?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/0efba68d/attachment.sig>

From notting at redhat.com  Tue Nov 13 16:32:00 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 11:32:00 -0500
Subject: [PATCH] Makefile.common: define specdir
In-Reply-To: <20071113112826.510f0564@redhat.com>
References: <20071113162617.GA20041@nostromo.devel.redhat.com>
	<20071113112826.510f0564@redhat.com>
Message-ID: <20071113163200.GA17742@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> Did you run into a problem with not specifying it?

If you have it defined in your local .rpmmacros and yet are doing
local builds with 'make <whateverarch>', yes, it breaks.

Bill



From dennis at ausil.us  Tue Nov 13 16:34:49 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 13 Nov 2007 10:34:49 -0600
Subject: [PATCH] Makefile.common: define specdir
In-Reply-To: <20071113162617.GA20041@nostromo.devel.redhat.com>
References: <20071113162617.GA20041@nostromo.devel.redhat.com>
Message-ID: <200711131034.54767.dennis@ausil.us>

On Tuesday 13 November 2007, Bill Nottingham wrote:
> If we set SOURCEDIR, RPMDIR, etc., we should really define _specdir too.
>
> Anyone see any issues with this?
>
> Bill


I see none and have applied your patch

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/b6a5d3c3/attachment.sig>

From nphilipp at redhat.com  Tue Nov 13 16:44:49 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Tue, 13 Nov 2007 17:44:49 +0100
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <20071112180131.GT11043@crow.myhome.westell.com>
References: <20071112180131.GT11043@crow.myhome.westell.com>
Message-ID: <1194972289.16317.10.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-12 at 13:01 -0500, Luke Macken wrote:
> Attached is a patch to add an 'update' target to our common Makefile.
> When executed in a branch supported by bodhi (F-{7,8}), it will drop
> you into a template and then submit your update to bodhi.
> 
> Comments/suggestions welcome,

There's one thing I'd rather have changed before this gets live:

"To abort this update, delete any uncommented lines before saving this
file"

"make update/bodhi" should rather write the template into 2 files
(bodhi.template, bodhi.template.unchanged?), run the editor on one of
them and only commit if both files differ and contain non-comment lines.
That way it would behave like "all VCSes known to man" (i.e. me).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From jkeating at redhat.com  Tue Nov 13 16:46:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 13 Nov 2007 11:46:41 -0500
Subject: [PATCH] Makefile.common: define specdir
In-Reply-To: <20071113163200.GA17742@nostromo.devel.redhat.com>
References: <20071113162617.GA20041@nostromo.devel.redhat.com>
	<20071113112826.510f0564@redhat.com>
	<20071113163200.GA17742@nostromo.devel.redhat.com>
Message-ID: <20071113114641.4ae447c7@redhat.com>

On Tue, 13 Nov 2007 11:32:00 -0500
Bill Nottingham <notting at redhat.com> wrote:

> If you have it defined in your local .rpmmacros and yet are doing
> local builds with 'make <whateverarch>', yes, it breaks.

Neat.  I see no problems.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/c41219c3/attachment.sig>

From rdieter at math.unl.edu  Tue Nov 13 16:57:50 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 13 Nov 2007 10:57:50 -0600
Subject: exiv2-0.16-pre1 coming to rawhide
Message-ID: <fhcl2f$89n$1@ger.gmane.org>

I'll be building a new abi-incompatible exiv2 soon (hopefully today) in
rawhide, packages in need of rebuilding afterward, include:
digikam (*)
gwenview 
kphotoalbum (*)
libkexiv2 (*)
qtpfsgui
strigi (*)
ufraw

I'll try to take care of the (*) items myself, at least.

-- Rex




From pertusus at free.fr  Tue Nov 13 17:39:10 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Nov 2007 18:39:10 +0100
Subject: a place for raw FESCo meeting logs?
Message-ID: <20071113173910.GA10619@free.fr>

Hello,

I am interested in the previous FESCo logs that are not yet summarized.
But I also don't want to bother people and force them to do summary when
they don't have time. Could it be possible to have access to the irc
log, in a raw format that don't need human intervention, before they are
summarized?

--
Pat



From tmraz at redhat.com  Tue Nov 13 17:46:40 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 13 Nov 2007 18:46:40 +0100
Subject: openssl097a package retirement
In-Reply-To: <20071113153402.GA5755@nostromo.devel.redhat.com>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
	<3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
	<1194900390.17465.37.camel@vespa.kabelta.loc>
	<fhcg00$jul$1@ger.gmane.org>
	<20071113153402.GA5755@nostromo.devel.redhat.com>
Message-ID: <1194976000.17465.70.camel@vespa.kabelta.loc>


On Tue, 2007-11-13 at 10:34 -0500, Bill Nottingham wrote:
> Rex Dieter (rdieter at math.unl.edu) said: 
> > Tomas Mraz wrote:
> > 
> > > But I'm curious why HTTrack
> > > dlopens it and not directly links to it.
> > 
> > HTTrack is GPL, and openssl isn't GPL-compatible.
> 
> Right, but there's nothing that says upstream can't add an exception
> for OpenSSL.

Or even better they should use NSS library which is LGPL/GPL/MPL
trilicensed. With the help of the nss_compat_ossl library it is really
easy task to convert application which needs just SSL support.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From bpepple at fedoraproject.org  Tue Nov 13 17:50:06 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 13 Nov 2007 12:50:06 -0500
Subject: a place for raw FESCo meeting logs?
In-Reply-To: <20071113173910.GA10619@free.fr>
References: <20071113173910.GA10619@free.fr>
Message-ID: <1194976206.5679.3.camel@nixon>

On Tue, 2007-11-13 at 18:39 +0100, Patrice Dumas wrote:
> I am interested in the previous FESCo logs that are not yet summarized.
> But I also don't want to bother people and force them to do summary when
> they don't have time. Could it be possible to have access to the irc
> log, in a raw format that don't need human intervention, before they are
> summarized?

I'm starting to keep them here: http://bpepple.fedorapeople.org/fesco/
When I get some free time, I'll move some of the earlier ones there
also.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/32af40f9/attachment.sig>

From janina at rednote.net  Tue Nov 13 17:57:43 2007
From: janina at rednote.net (Janina Sajka)
Date: Tue, 13 Nov 2007 12:57:43 -0500
Subject: Firefox 3
In-Reply-To: <6f27515e0711100728ia6fd899hf32ae5be017cfc22@mail.gmail.com>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net> <47357423.9030004@redhat.com>
	<6f27515e0711100728ia6fd899hf32ae5be017cfc22@mail.gmail.com>
Message-ID: <20071113175743.GH6342@rednote.net>

Matsuura San,

MATSUURA Takanori writes:
> Hi all,
> 
> Now I put my firefox-trunk (3.0b2pre now) package at
> http://t-matsuu.sakura.ne.jp/install-memo/fc/

I have been building from your srpms with excellent results--until very
recently. Beginning AFTER firefox-3.0a9pre-2007102116_trunk.fc7, I am
unable to rpmbuild either F-7 or F-8, including your srpm of the new FF3
Beta. I get:

error: line 1212: Dependency tokens must begin with alpha-numeric, '_' or '/': - Initial RPM release.

error: Failed to find Provides:
    File listed twice: /usr/lib64/firefox-3.0b2pre/updater.ini
    line 1212: Dependency tokens must begin with alpha-numeric, '_' or '/': - Initial RPM release.

    Failed to find Provides:
    line 1212: Dependency tokens must begin with alpha-numeric, '_' or '/': - Initial RPM release.

    Failed to find Provides:Release: 2%{?dist}spk

Since 1212 is actually the eof of the .spec, I suspect some other subtle
problem that I have not been able to identify.

PS: Thank you again for making these srpms available over the past
months. They have been very helpful.

Janina

> The package is based on firefox-2.0.0.8-2.
> It includes some adhoc artifice to success to build.
> 
> libgtkembedmoz.so and libxpcom.so is not built by default. now.
> This change may affects yelp and devhelp (and AdobeReader-8.*) packages.
> 
> Feel free to incorporate to firefox package in Fedora.
> 
> regards,
> 
> Takanori
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From j.w.r.degoede at hhs.nl  Tue Nov 13 18:03:39 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 13 Nov 2007 19:03:39 +0100
Subject: bodhi-client
In-Reply-To: <20071113044952.GV11043@crow.myhome.westell.com>
References: <20071113044952.GV11043@crow.myhome.westell.com>
Message-ID: <4739E6FB.8060503@hhs.nl>

Luke Macken wrote:
> The bodhi-client package should be making its way to an updates-testing
> repository near you! (and a newer version is already queued up for tomorrow).
> Not only does this command-line tool give you easier access to bodhi, but also
> provides some new features to help people get more involved with testing
> updates and providing useful feedback.
> 
> I wrote up some documentation on various usage examples of the tool, which can
> be found on the wiki[0].  I also submitted a Makefile.common patch[1] that,
> once applied, will allow you to run `make update` from your package branch.
> This will drop you into a new update template, and will then submit your update
> straight to bodhi.
> 
> Some noteworthy features in the bodhi-client, aside from the normal bodhi
> functionality:
> 
>   ? Ability to view all updates-testing packages that you currently have
>     installed on your local machine, that you *could* be testing and providing
>     useful feedback for:
>     ? bodhi --testable
>   ? Ability to view your update candidates (this is a fairly expensive
>     operation -- please use sparingly):
>     ? bodhi --candidates
> 
> I also upgraded our production bodhi instance today, which pulled in a ton of
> bugfixes and some new features, such as:
> 
>   ? Updates by default will now get submitted to into testing.  This can easily
>     be modified when using the web form, the bodhi client, and `make update`.
>   ? Thanks to the new security bug tracking policy[2], we're now tracking CVEs
>     using Bugzilla, thus bodhi no longer will ask you for CVE IDs.  The less
>     information that the developer has to type, the better.  Read the policy
>     for more details.  Bodhi is not yet 100% compliant to the proposed changes,
>     as it does not know about parent/tracking bugs, but should be soon.
>   ? If you try and submit an update that is older than something already
>     pending/testing, you will be prompted with a dialog that will give you the
>     ability to instantly obsolete those updates.
> 
> As always, patches/questions/criticisms/comments are welcome. You can file
> tickets in the usual place[3].
> 


As someone who has been vocal with critic in the past, let me say this is 
excellent work!

Thanks & Regards,

Hans



From pertusus at free.fr  Tue Nov 13 18:03:25 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Nov 2007 19:03:25 +0100
Subject: a place for raw FESCo meeting logs?
In-Reply-To: <1194976206.5679.3.camel@nixon>
References: <20071113173910.GA10619@free.fr> <1194976206.5679.3.camel@nixon>
Message-ID: <20071113180325.GB21094@free.fr>

On Tue, Nov 13, 2007 at 12:50:06PM -0500, Brian Pepple wrote:
> On Tue, 2007-11-13 at 18:39 +0100, Patrice Dumas wrote:
> > I am interested in the previous FESCo logs that are not yet summarized.
> > But I also don't want to bother people and force them to do summary when
> > they don't have time. Could it be possible to have access to the irc
> > log, in a raw format that don't need human intervention, before they are
> > summarized?
> 
> I'm starting to keep them here: http://bpepple.fedorapeople.org/fesco/
> When I get some free time, I'll move some of the earlier ones there
> also.

Very nice. Maybe it would be good to have a link from the top of
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings
If agreed I can do that if I have enough edit power.

--
Pat



From bpepple at fedoraproject.org  Tue Nov 13 18:14:23 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 13 Nov 2007 13:14:23 -0500
Subject: a place for raw FESCo meeting logs?
In-Reply-To: <20071113180325.GB21094@free.fr>
References: <20071113173910.GA10619@free.fr> <1194976206.5679.3.camel@nixon>
	<20071113180325.GB21094@free.fr>
Message-ID: <1194977663.5679.4.camel@nixon>

On Tue, 2007-11-13 at 19:03 +0100, Patrice Dumas wrote:
> On Tue, Nov 13, 2007 at 12:50:06PM -0500, Brian Pepple wrote:
> > On Tue, 2007-11-13 at 18:39 +0100, Patrice Dumas wrote:
> > > I am interested in the previous FESCo logs that are not yet summarized.
> > > But I also don't want to bother people and force them to do summary when
> > > they don't have time. Could it be possible to have access to the irc
> > > log, in a raw format that don't need human intervention, before they are
> > > summarized?
> > 
> > I'm starting to keep them here: http://bpepple.fedorapeople.org/fesco/
> > When I get some free time, I'll move some of the earlier ones there
> > also.
> 
> Very nice. Maybe it would be good to have a link from the top of
> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings
> If agreed I can do that if I have enough edit power.

That would be great.  Thanks.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/8e4aeb90/attachment.sig>

From andrewparker at bigfoot.com  Tue Nov 13 18:14:46 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Tue, 13 Nov 2007 13:14:46 -0500
Subject: "File Type" Buddy for Fedora 9?
In-Reply-To: <4739937E.6080206@iinet.net.au>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>
	<4738490F.2040406@iinet.net.au>
	<6c3f5e6c0711120445k3911b6d1w9b5c96c496354226@mail.gmail.com>
	<4739937E.6080206@iinet.net.au>
Message-ID: <6c3f5e6c0711131014t7fbfaa3ehaaee434578ac2c8c@mail.gmail.com>

On Nov 13, 2007 7:07 AM, David Timms <dtimms at iinet.net.au> wrote:
> Andrew Parker wrote:
> > repositories (a la yum) for the database.  then files that couldn't be
> > opened by fedora rpms could be provided by other "repos".
>
> This would open fedora to all types of security problems because the
> fedoraproject is not able to control/vet/modify external repos - and
> hence this capability is specifically disallowed in the fedora packaging
> process.
>
> Having the current setup where a user goes to a web site, installs a
> x-release rpm, and then needs to accepting import of the repo's signing
> key means that it is the user who needs to decide whether they can trust
> repo x {which could do _anything_ on their machine}.

Sorry if I wrote was misleading, I intended it to work the same as yum
repos.  i.e. as you say the user has to specifically add third party
repos themseleves.



From pertusus at free.fr  Tue Nov 13 18:25:54 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 13 Nov 2007 19:25:54 +0100
Subject: a place for raw FESCo meeting logs?
In-Reply-To: <1194977663.5679.4.camel@nixon>
References: <20071113173910.GA10619@free.fr> <1194976206.5679.3.camel@nixon>
	<20071113180325.GB21094@free.fr> <1194977663.5679.4.camel@nixon>
Message-ID: <20071113182554.GC21094@free.fr>

On Tue, Nov 13, 2007 at 01:14:23PM -0500, Brian Pepple wrote:
> On Tue, 2007-11-13 at 19:03 +0100, Patrice Dumas wrote:
> > On Tue, Nov 13, 2007 at 12:50:06PM -0500, Brian Pepple wrote:
> > > On Tue, 2007-11-13 at 18:39 +0100, Patrice Dumas wrote:
> > > > I am interested in the previous FESCo logs that are not yet summarized.
> > > > But I also don't want to bother people and force them to do summary when
> > > > they don't have time. Could it be possible to have access to the irc
> > > > log, in a raw format that don't need human intervention, before they are
> > > > summarized?
> > > 
> > > I'm starting to keep them here: http://bpepple.fedorapeople.org/fesco/
> > > When I get some free time, I'll move some of the earlier ones there
> > > also.
> > 
> > Very nice. Maybe it would be good to have a link from the top of
> > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings
> > If agreed I can do that if I have enough edit power.
> 
> That would be great.  Thanks.

You didn't left me enough time... 

But thanks!

--
Pat



From myfedora at richip.dhs.org  Tue Nov 13 18:26:31 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 13 Nov 2007 11:26:31 -0700
Subject: "File Type" Buddy for Fedora 9?
In-Reply-To: <4738490F.2040406@iinet.net.au>
References: <6e24a8e80711120338q1bc815abu3674f6343ed5e6f5@mail.gmail.com>
	<20071112124623.310b19d2@dhcp03.addix.net>
	<6e24a8e80711120412s5b59876ek5422c209020f7171@mail.gmail.com>
	<4738490F.2040406@iinet.net.au>
Message-ID: <1194978391.11756.8.camel@localhost6.localdomain6>

Here's my own take on how this could proceed:

1) User "opens" a file and the system executes xdg-open
2) The xdg system determines the file type and proceeds as usual if
there are registered handlers (ie. uses the default action or, if
right-clicked, shows possible actions including View, Edit, etc.)
3) If no associated handler is installed, goes to the "yum" system with
a query that uses the mime-type as search parameter
4) "yum" returns matching packages along with the action type it can
perform (ie. View, Edit, etc.)
5) User selects one AND has the option of installing the RPM system-wide
or local to the user's session (this is one of the reasons that I've
always had a fondness for packages using the <packagename>/(bin|lib|etc|
share) system)
6) xdg-open continues to open the file using the newly installed
application

It would be nice if the similar bits for this system could be used by
Codec Buddy.

Obviously this would involve effort between freedesktop.org as well as
package system developers. It's also yet another push for having a real
metainfo storage and querying mechanism in the packaging system.

My Can$0.02.
--

Richi Plana



From wacker at octothorp.org  Tue Nov 13 18:53:00 2007
From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209)
Date: Tue, 13 Nov 2007 11:53:00 -0700 (MST)
Subject: Firefox 3
In-Reply-To: <20071113175743.GH6342@rednote.net>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net> <47357423.9030004@redhat.com>
	<6f27515e0711100728ia6fd899hf32ae5be017cfc22@mail.gmail.com>
	<20071113175743.GH6342@rednote.net>
Message-ID: <Pine.LNX.4.64.0711131146170.32538@wb2flw.octothorp.org>

On Tue, 13 Nov 2007, Janina Sajka wrote:

> Matsuura San,
>
> MATSUURA Takanori writes:
>> Hi all,
>>
>> Now I put my firefox-trunk (3.0b2pre now) package at
>> http://t-matsuu.sakura.ne.jp/install-memo/fc/
>
> I have been building from your srpms with excellent results--until very
> recently. Beginning AFTER firefox-3.0a9pre-2007102116_trunk.fc7, I am
> unable to rpmbuild either F-7 or F-8, including your srpm of the new FF3
> Beta. I get:
>
> error: line 1212: Dependency tokens must begin with alpha-numeric, '_' or '/': - Initial RPM release.
>
> error: Failed to find Provides:
>    File listed twice: /usr/lib64/firefox-3.0b2pre/updater.ini
>    line 1212: Dependency tokens must begin with alpha-numeric, '_' or '/': - Initial RPM release.
>
>    Failed to find Provides:
>    line 1212: Dependency tokens must begin with alpha-numeric, '_' or '/': - Initial RPM release.
>
>    Failed to find Provides:Release: 2%{?dist}spk
>
> Since 1212 is actually the eof of the .spec, I suspect some other subtle
> problem that I have not been able to identify.
>
> PS: Thank you again for making these srpms available over the past
> months. They have been very helpful.
>
> Janina
>
>> The package is based on firefox-2.0.0.8-2.
>> It includes some adhoc artifice to success to build.
>>
>> libgtkembedmoz.so and libxpcom.so is not built by default. now.
>> This change may affects yelp and devhelp (and AdobeReader-8.*) packages.
>>
>> Feel free to incorporate to firefox package in Fedora.
>>
>> regards,
>


OK, I added %{mozappdir}/crashreporter to the %files list, and it 
built successfully.  Someone should probably take a look at what to do 
about the fact that the process for finding provides is presenting an 
arglist to sed that needs to be split up somehow.

           HTH.

-- 
           Bil in Denver



From tom.marble at sun.com  Tue Nov 13 18:45:14 2007
From: tom.marble at sun.com (Tom Marble)
Date: Tue, 13 Nov 2007 18:45:14 +0000 (UTC)
Subject: License review for new itext version
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
	<645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
Message-ID: <loom.20071113T180637-280@post.gmane.org>

Jonathan Underwood <jonathan.underwood <at> gmail.com> writes:
> Happy to - is there anyone that is the obvious contact at Sun? I am
> looking now, but don't see a useful contact on the openjdk page.
I'm sorry that you had trouble identifying contacts for OpenJDK
on our page:
  http://openjdk.java.net/

We have several mailing lists, blogs and a couple of IRC channels
through which we may be contacted.

In any case it would appear that the upstream source of the
files in question is not, in fact, part of the Java SE Platform
itself (i.e. not a file which is part of OpenJDK).

Hints in the iText file suggest that this is based on the JAI
(Java Advanced Imaging) tools and probably is not from a current 
release.  By pulling the source of jai-core out of CVS from
  https://jai-core.dev.java.net/
I do find a file
  (NOTE: URL BROKEN to comply to Gmane 80 character line limit, sorry)
  https://jai-core.dev.java.net/source/browse/jai-core/src/share/classes/
  com/sun/media/jai/codecimpl/TIFFLZWDecoder.java?view=markup
Which may bear some historical relationship to
  http://itext.svn.sourceforge.net/viewvc/*checkout*/itext/trunk/src/
  com/lowagie/text/pdf/LZWDecoder.java?content-type=text%2Fplain
However I would like to call to everyone's attention that the
"nuke" clause does not exist in the current version.

Alan Cox wrote:
> "ii) Licensee does not utilize the software in a manner which is
> disparaging to Sun Microsystems."
> This is incompatible with open source. (As indeed would be one which forbid 
> its use disparaging to Fedora).
Please understand that Sun has worked quite hard to contribute
a great deal of our software portfolio to open source.  Sometimes
historical licensing practices are tricky to find and fix.
In the case of the "nuke" clause our counsel has allowed us to 
drop that language.  If anyone finds other instances of this language
in current Sun open source code releases please bring them to our
attention and we will make sure they are corrected.

In this case please be aware that certain of the libraries in
question may also be under consideration for and/or undergoing
license changes (i.e. may be relicensed or multiply licensed):
  http://blogs.sun.com/tmarble/entry/itp_that_cool_java_thing

Getting code provenance tracked accurately, updating copyright notices
and insuring appropriate project licensing is difficult and important
work.  Please let us know how we might help the Fedora project in
this regard.

Respectfully,

--Tom (OpenJDK Ambassador)




From fedora at leemhuis.info  Tue Nov 13 19:12:38 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 13 Nov 2007 20:12:38 +0100
Subject: EPEL report week 45 2007
Message-ID: <4739F726.3080506@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week45

= Weekly EPEL Summary =

Week 45/2007

== Most important happenings ==

 * nothing earthshaking

== Mailing list ==

=== Noteworthy discussions ===

 * RHEL 5.1 --
https://www.redhat.com/archives/epel-devel-list/2007-November/msg00035.html

  * EPEL builders are still RHEL 5.0; moving to RHEL 5.1 now on bears
the risk that we break users of CentOS 5.0; no real outcome from the
discussion yet; more discussion needed

 * Lots of packages wanted --
https://www.redhat.com/archives/epel-devel-list/2007-November/msg00020.html
and
https://www.redhat.com/archives/epel-devel-list/2007-November/msg00024.html

  * lots of deps of bugzilla are not yet in EPEL (lots of them: perl);
lot's of packages that a 3rd party repo would need to compile
xine-lib-extras-nonfree, mplayer and similar stuff are still missing as
well; help needed;

== Meeting ==

=== Next Meeting ===

20071107 at '''18:00 UTC''' in #fedora-meeting.

Please note that it's 18:00 UTC now again after the DST switch, so the
effective meeting time should stay the same for everyone!

=== Last weeks meeting ===

==== Attendees: ====

 * [:MikeMcGrath:mmcgrath]
 * [:KevinFenzi:nirik]

==== Summary ====

 * http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove did
the last move went well?

  * nirik> | I think the last move went pretty well...  do we want to
schedule them for specific times?

  * mmcgrath> | nirik: I'd schedule a time then see if the list wants us
to change it.  It could be a while before the next move.  although,
since its just you and me, perhaps the list would be better, or just
wait till the next meeting to talk about it.

  * nirik> | yeah, I would be happy with once a month or something, then
the question is how long something needs to be in testing.

 * http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove when
to do the move in EL4?

   * nirik> | I can try and work on it I guess...  plan on perhaps next
monday?  let the f8 release suck up all the bw, etc.

 * Clamav

   *  nirik is working on it

 *  why don't the broken dep reports go to the list?

  * mmcgrath> | A) The script we use, for some reason, can take a long
time to run and B) no one's done the work.

  * mmcgrath posted to the list asking people to help so it gets posted
to the list

 * http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- how to get all the
missing rpmfusion and bugzilla deps into EPEL and the wishlist empty as
well?

  * mmcgrath> | I say, Add them to the wish list and get to contacting
each packager one by one until everything is in.

  * nirik> | I think contacting maintainers is the best way... and if
they don't answer branching, etc.

== Stats ==

=== General ===

Number of EPEL Contributors: 140

We welcome 3 new contributors: drago01 rjones varekova

=== EPEL 5 ===

Number of source packages: 738

Number of binary packages:  1435

There are 26 new Packages:

 * bodhi | A modular framework that facilitates publishing software updates
 * cdpr | Cisco Discovery Protocol Analyzer
 * Django | A high-level Python Web framework
 * func | Remote config, monitoring, and management api
 * gdl | GNU Data Language
 * gsl | The GNU Scientific Library for numerical analysis
 * gsm | Shared libraries for GSM speech compressor
 * libggz | Library for client-server games
 * libofa | Open Fingerprint Architecture library
 * libpri | An implementation of Primary Rate ISDN
 * perl-Class-Singleton | Class::Singleton Perl module
 * perl-Devel-Symdump | A Perl module for inspecting Perl's symbol table
 * perl-HTML-Tree | HTML tree handling modules for Perl
 * perl-IO-All | IO::All Perl module
 * perl-LockFile-Simple | Simple file locking scheme
 * perl-Text-Reform | Manual text wrapping and reformatting
 * perl-Tk | Perl Graphical User Interface ToolKit
 * postgis | Geographic Information Systems Extensions to PostgreSQL
 * revisor | Fedora "Spin" Graphical User Interface
 * ruby-ldap | Ruby LDAP libraries
 * spandsp | A DSP library for telephony
 * tre | POSIX compatible regexp library with approximate matching
 * unshield | Install InstallShield applications on a Pocket PC
 * wordpress | WordPress blogging software
 * wv2 | A library which allows access to Microsoft? Word files
 * zaptel | Tools and libraries for using/configuring/monitoring Zapata
telephony interfaces

=== EPEL 4 ===

Number of source packages: 442

Number of binary packages:  890

There are 8 new Packages:

 * cdpr | Cisco Discovery Protocol Analyzer
 * func | Remote config, monitoring, and management api
 * perl-LockFile-Simple | Simple file locking scheme
 * perl-Tk | Perl Graphical User Interface ToolKit
 * python-configobj | Config file reading, writing, and validation
 * ruby-ldap | Ruby LDAP libraries
 * unshield | Install InstallShield applications on a Pocket PC
 * wv2 | A library which allows access to Microsoft? Word files

----
["CategoryEPELReports"]



From j.w.r.degoede at hhs.nl  Tue Nov 13 19:17:12 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 13 Nov 2007 20:17:12 +0100
Subject: autoloading of kernel modules in the udev area ?!
Message-ID: <4739F838.7060504@hhs.nl>

Hi All,

I'm working on an i2c-tools packages as with lm_sensors-3.0.0 various i2c-tools 
have been split out into their own i2c-tools tarbal.

I'm basing my work on the i2c-tools specfile from Suse (one of the lm_sensors 
project lead works for Suse).

This specfile contains in %files:
%attr(660, root, root) %dev(c, 89, 0) /lib/udev/devices/i2c-0

This causes a /dev/i2c-0 char device to be effectively statically created. If I 
then also add the proper alias to modprobe.conf.dist, tools like i2cdump which 
need the i2c-dev kernel module loaded will automagically work.

Is this ok / the best way todo this. Also I will be adding i2c-0 to i2c-3 then, 
as there are many cases where there is more then 1 i2c bus (some motherboards 
have 2 on the board and many graphics / tv cards have i2c busses).

---

Hmm,

I just thought the same problem exists for non hardware backed devices like 
loop. Then I noticed that loop.ko is loaded, removing it and then trying a 
mount -o loop will cause mount to fail because it cannot find /dev/loop#.

Who / what is responsible for loop.ko getting loaded by default, wouldn't it be 
better to use a similar trick with a static /dev entry and module autoloading, 
this would probably save both boottime and memory.

Thanks & Regards,

Hans



From jonathan.underwood at gmail.com  Tue Nov 13 19:23:28 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 13 Nov 2007 19:23:28 +0000
Subject: License review for new itext version
In-Reply-To: <loom.20071113T180637-280@post.gmane.org>
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
	<645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
	<loom.20071113T180637-280@post.gmane.org>
Message-ID: <645d17210711131123j4bf10bbfh8a61fe8ff6f0fcdd@mail.gmail.com>

Dear Tom,

Thanks for such a rapid response to my query.

On 13/11/2007, Tom Marble <tom.marble at sun.com> wrote:
> Hints in the iText file suggest that this is based on the JAI
> (Java Advanced Imaging) tools and probably is not from a current
> release.

Indeed -- according to upstream itext developers the files in question
were derived from a 2001 version of JAI.

> By pulling the source of jai-core out of CVS from
>   https://jai-core.dev.java.net/
> I do find a file
>   (NOTE: URL BROKEN to comply to Gmane 80 character line limit, sorry)
>   https://jai-core.dev.java.net/source/browse/jai-core/src/share/classes/
>   com/sun/media/jai/codecimpl/TIFFLZWDecoder.java?view=markup
> Which may bear some historical relationship to
>   http://itext.svn.sourceforge.net/viewvc/*checkout*/itext/trunk/src/
>   com/lowagie/text/pdf/LZWDecoder.java?content-type=text%2Fplain
> However I would like to call to everyone's attention that the
> "nuke" clause does not exist in the current version.
>

That's useful information, thanks. However, it seems that jai-core
(which contains the file you point to) is dual licensed under the Java
Research License (JRL)  for non-commercial use and under the Java
Distribution License (JDL) for commercial use. As such, I don't
believe this is Free software, and so replacing the files in itext
with the current JAI files isn't an option. I might be wrong though,
and am sure someone will correct me if so.

> In the case of the "nuke" clause our counsel has allowed us to
> drop that language.  If anyone finds other instances of this language
> in current Sun open source code releases please bring them to our
> attention and we will make sure they are corrected.

With that in mind, is there any possibility of Sun relicensing the
files currently in iText so as not to include the nuke clause. For
reference the files are:

com/lowagie/text/pdf/LZWDecoder.java
com/lowagie/text/pdf/codec/TIFFField.java
com/lowagie/text/pdf/codec/TIFFConstants.java
com/lowagie/text/pdf/codec/TIFFLZWDecoder.java
com/lowagie/text/pdf/codec/PngImage.java
com/lowagie/text/pdf/codec/TIFFDirectory.java
com/lowagie/text/pdf/codec/TIFFFaxDecoder.java
com/lowagie/text/pdf/codec/BmpImage.java

>
> In this case please be aware that certain of the libraries in
> question may also be under consideration for and/or undergoing
> license changes (i.e. may be relicensed or multiply licensed):
>   http://blogs.sun.com/tmarble/entry/itp_that_cool_java_thing
>

OK, so there is a possibility that jai-core is relicensed in the
future - that is encouraging.

Best wishes,
Jonathan.



From notting at redhat.com  Tue Nov 13 19:23:58 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 14:23:58 -0500
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <4739F838.7060504@hhs.nl>
References: <4739F838.7060504@hhs.nl>
Message-ID: <20071113192358.GA7969@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> I'm basing my work on the i2c-tools specfile from Suse (one of the 
> lm_sensors project lead works for Suse).
>
> This specfile contains in %files:
> %attr(660, root, root) %dev(c, 89, 0) /lib/udev/devices/i2c-0
>
> This causes a /dev/i2c-0 char device to be effectively statically created. 
> If I then also add the proper alias to modprobe.conf.dist, tools like 
> i2cdump which need the i2c-dev kernel module loaded will automagically 
> work.
>
> Is this ok / the best way todo this. Also I will be adding i2c-0 to i2c-3 
> then, as there are many cases where there is more then 1 i2c bus (some 
> motherboards have 2 on the board and many graphics / tv cards have i2c 
> busses).

What are the modules that live behind that device?

> I just thought the same problem exists for non hardware backed devices like 
> loop. Then I noticed that loop.ko is loaded, removing it and then trying a 
> mount -o loop will cause mount to fail because it cannot find /dev/loop#.
>
> Who / what is responsible for loop.ko getting loaded by default, wouldn't 
> it be better to use a similar trick with a static /dev entry and module 
> autoloading, this would probably save both boottime and memory.

loop is created by /etc/udev/makedev.d/50-udev.nodes.

Bill



From tcallawa at redhat.com  Tue Nov 13 19:28:51 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 13 Nov 2007 14:28:51 -0500
Subject: License review for new itext version
In-Reply-To: <645d17210711131123j4bf10bbfh8a61fe8ff6f0fcdd@mail.gmail.com>
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
	<645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
	<loom.20071113T180637-280@post.gmane.org>
	<645d17210711131123j4bf10bbfh8a61fe8ff6f0fcdd@mail.gmail.com>
Message-ID: <1194982131.25279.26.camel@localhost.localdomain>


On Tue, 2007-11-13 at 19:23 +0000, Jonathan Underwood wrote:
> As such, I don't
> believe this is Free software, and so replacing the files in itext
> with the current JAI files isn't an option. I might be wrong though,
> and am sure someone will correct me if so.

You're not wrong.

~spot



From Matt_Domsch at dell.com  Tue Nov 13 19:44:51 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Tue, 13 Nov 2007 13:44:51 -0600
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <20071113192358.GA7969@nostromo.devel.redhat.com>
References: <4739F838.7060504@hhs.nl>
	<20071113192358.GA7969@nostromo.devel.redhat.com>
Message-ID: <20071113194451.GA19146@auslistsprd01.us.dell.com>

On Tue, Nov 13, 2007 at 02:23:58PM -0500, Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> > I'm basing my work on the i2c-tools specfile from Suse (one of the 
> > lm_sensors project lead works for Suse).
> >
> > This specfile contains in %files:
> > %attr(660, root, root) %dev(c, 89, 0) /lib/udev/devices/i2c-0
> >
> > This causes a /dev/i2c-0 char device to be effectively statically created. 
> > If I then also add the proper alias to modprobe.conf.dist, tools like 
> > i2cdump which need the i2c-dev kernel module loaded will automagically 
> > work.
> >
> > Is this ok / the best way todo this. Also I will be adding i2c-0 to i2c-3 
> > then, as there are many cases where there is more then 1 i2c bus (some 
> > motherboards have 2 on the board and many graphics / tv cards have i2c 
> > busses).
> 
> What are the modules that live behind that device?
> 
> > I just thought the same problem exists for non hardware backed devices like 
> > loop. Then I noticed that loop.ko is loaded, removing it and then trying a 
> > mount -o loop will cause mount to fail because it cannot find /dev/loop#.
> >
> > Who / what is responsible for loop.ko getting loaded by default, wouldn't 
> > it be better to use a similar trick with a static /dev entry and module 
> > autoloading, this would probably save both boottime and memory.
> 
> loop is created by /etc/udev/makedev.d/50-udev.nodes.

The kernel now has DMI-based module autoloading, which I implemented
for the dcdbas module a few weeks ago[1].

Can you do something similar?


[1]http://www.mail-archive.com/mm-commits at vger.kernel.org/msg28390.html

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From janina at rednote.net  Tue Nov 13 20:02:54 2007
From: janina at rednote.net (Janina Sajka)
Date: Tue, 13 Nov 2007 15:02:54 -0500
Subject: Firefox 3
In-Reply-To: <f4586a2e0711102305x6b0144cfu68f45aa139cbb3c1@mail.gmail.com>
References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com>
	<20071109163346.GG6342@rednote.net> <47357423.9030004@redhat.com>
	<f4586a2e0711102305x6b0144cfu68f45aa139cbb3c1@mail.gmail.com>
Message-ID: <20071113200254.GI6342@rednote.net>

Parag N(????????????) writes:
> Hi,
> On Nov 10, 2007 2:34 PM, Christopher Aillon <caillon at redhat.com> wrote:
> > Janina Sajka wrote:
> > >> Janina Sajka <janina at rednote.net> wrote:
> > >> >Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
> > >> >near ready for prime time, but I have a compelling reason to start using
> > >> >ff3 fairly soon and would rather install from rpm, of course.
> >
> > Stay tuned for an update in the next two weeks.  We got this working
> > last week, but there's a few things we want to clean up before it's put
> > into rawhide.  Putting it into rawhide will also mean breaking several
> > things such as epiphany, yelp, devhelp, and every other application that
> > uses gecko right now.  So there is a high cost that we want to be in a
> > position to communicate well as to the proper way to solve rather than
> > simply leave broken for people to figure it out.
>      Good News that last week mozilla developers resolved all beta1
> blocker bugs. According to their weekly meeting status, beta1 is code
> complete now. So I am waiting for Firefox 3's Beta1(M9) release. once
> its released we can think on its inclusion in rawhide.
> 

May I venture that a11y is looking for an upversioning in Gecko across
the board? As things stand, the current help system is inaccessible. The
Mozilla and Gnome Summits last month both decided to try and move
distributions toward Gecko 1.9 (at least) in order to make help more
usable through alternative interfaces. So, hopefully, the "right thing
to do" will include newer Gecko.

Janina


> Regards,
> Parag.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From ich at frank-schmitt.net  Tue Nov 13 13:21:58 2007
From: ich at frank-schmitt.net (Frank Schmitt)
Date: Tue, 13 Nov 2007 14:21:58 +0100
Subject: pptp-linux (pptp) on a Fedora DVD
References: <deade3e20711090455i3931665fw5590e2965f4b9b14@mail.gmail.com>
	<4738EEA8.8080503@redhat.com> <47397B2C.6010805@vermin.nl>
Message-ID: <m3mytiwaa1.fsf@mid.gehheimdienst.de>

Sander Vermin <sander at vermin.nl> writes:

>>> So, questions are:
>>> 1. Why pptp package is still not there? Some license issues?
>>> 2. Will it be included in Fedora DVD?
>>> 3. How can i help?
>>>
>>
>> You could help by creating a feature page which focus on including
>> the package and smoothing out other configuration issues.  It sounds
>> like this enhancement could benefit a lot of users :)
>>
>> http://fedoraproject.org/wiki/Features/Policy
>>
>> If you need help with creating a feature page, please let me know.
>>
>> John
>>
> It would be a big plus if we use NetworkManager's vpn pptp client for
> the graphical part.
>
> Tis is available for KNetworkManager but nog for GNOME.

In fact the front end is available but it doesn't work, as the back end
is excluded in NetworkManager.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.



From j.w.r.degoede at hhs.nl  Tue Nov 13 20:20:56 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 13 Nov 2007 21:20:56 +0100
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <20071113192358.GA7969@nostromo.devel.redhat.com>
References: <4739F838.7060504@hhs.nl>
	<20071113192358.GA7969@nostromo.devel.redhat.com>
Message-ID: <473A0728.3050601@hhs.nl>

Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>> I'm basing my work on the i2c-tools specfile from Suse (one of the 
>> lm_sensors project lead works for Suse).
>>
>> This specfile contains in %files:
>> %attr(660, root, root) %dev(c, 89, 0) /lib/udev/devices/i2c-0
>>
>> This causes a /dev/i2c-0 char device to be effectively statically created. 
>> If I then also add the proper alias to modprobe.conf.dist, tools like 
>> i2cdump which need the i2c-dev kernel module loaded will automagically 
>> work.
>>
>> Is this ok / the best way todo this. Also I will be adding i2c-0 to i2c-3 
>> then, as there are many cases where there is more then 1 i2c bus (some 
>> motherboards have 2 on the board and many graphics / tv cards have i2c 
>> busses).
> 
> What are the modules that live behind that device?
> 

The module / driver behind it us i2c-dev, which gives userspace access to one 
ore more i2c-busses. So the chain basically is:
-userspace app (i2cdump for example) -> i2c-dev -> i2c master driver (i2c-i801
  for example).

Notice that under normal circumstances userspace access to the i2c busses is 
not used, its main use is as a debugging / development technique.

>> I just thought the same problem exists for non hardware backed devices like 
>> loop. Then I noticed that loop.ko is loaded, removing it and then trying a 
>> mount -o loop will cause mount to fail because it cannot find /dev/loop#.
>>
>> Who / what is responsible for loop.ko getting loaded by default, wouldn't 
>> it be better to use a similar trick with a static /dev entry and module 
>> autoloading, this would probably save both boottime and memory.
> 
> loop is created by /etc/udev/makedev.d/50-udev.nodes.
> 

Hmm,

Interesting this seems to be different from adding entries under 
/lib/udev/devices, as as said on my system after dev the loop module gets 
loaded, while I assume its not used during boot. Wouldn't it be better (faster, 
less memory use) for the loop-devices to sit under /lib/udev/devices, so that 
no module gets loaded?

Regards,

Hans



From notting at redhat.com  Tue Nov 13 20:28:44 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 15:28:44 -0500
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <473A0728.3050601@hhs.nl>
References: <4739F838.7060504@hhs.nl>
	<20071113192358.GA7969@nostromo.devel.redhat.com>
	<473A0728.3050601@hhs.nl>
Message-ID: <20071113202844.GA10485@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>> What are the modules that live behind that device?
>
> The module / driver behind it us i2c-dev, which gives userspace access to 
> one ore more i2c-busses. So the chain basically is:
> -userspace app (i2cdump for example) -> i2c-dev -> i2c master driver 
> (i2c-i801
>  for example).
>
> Notice that under normal circumstances userspace access to the i2c busses 
> is not used, its main use is as a debugging / development technique.

So, i2c-i801 is automatically loaded, but i2c-dev isn't?

If it's not needed by default, I suppose the device node + kmod is one
way to do it; you could also build it statically if you really want
to. Why wouldn't i2c-dev be part of i2c-core anyway?

> Interesting this seems to be different from adding entries under 
> /lib/udev/devices, as as said on my system after dev the loop module gets 
> loaded, while I assume its not used during boot. Wouldn't it be better 
> (faster, less memory use) for the loop-devices to sit under 
> /lib/udev/devices, so that no module gets loaded?

I'm not seeing it getting loaded by default for me. Did you set up
a loop device?

Bill



From j.w.r.degoede at hhs.nl  Tue Nov 13 20:40:48 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 13 Nov 2007 21:40:48 +0100
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <20071113202844.GA10485@nostromo.devel.redhat.com>
References: <4739F838.7060504@hhs.nl>	<20071113192358.GA7969@nostromo.devel.redhat.com>	<473A0728.3050601@hhs.nl>
	<20071113202844.GA10485@nostromo.devel.redhat.com>
Message-ID: <473A0BD0.6010207@hhs.nl>

Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>>> What are the modules that live behind that device?
>> The module / driver behind it us i2c-dev, which gives userspace access to 
>> one ore more i2c-busses. So the chain basically is:
>> -userspace app (i2cdump for example) -> i2c-dev -> i2c master driver 
>> (i2c-i801
>>  for example).
>>
>> Notice that under normal circumstances userspace access to the i2c busses 
>> is not used, its main use is as a debugging / development technique.
> 
> So, i2c-i801 is automatically loaded, but i2c-dev isn't?
> 
Yes.

> If it's not needed by default, I suppose the device node + kmod is one
> way to do it

Ok, thats what I wanted to hear.

> you could also build it statically if you really want
> to.

Erm, that would be Dave J.'s call to make not mine, I'm looking for a solution 
which can be packaged here, not a local kludge.

> Why wouldn't i2c-dev be part of i2c-core anyway?
I guess because its not needed be default?

>> Interesting this seems to be different from adding entries under 
>> /lib/udev/devices, as as said on my system after dev the loop module gets 
>> loaded, while I assume its not used during boot. Wouldn't it be better 
>> (faster, less memory use) for the loop-devices to sit under 
>> /lib/udev/devices, so that no module gets loaded?
> 
> I'm not seeing it getting loaded by default for me. Did you set up
> a loop device?
> 

I just did a reboot to confirm, it gets loaded by default on my machine. Pretty 
clean F-8 install. Done from an F-8 x86_64 livecd. Updates applied, some 
packages installed, no fancy changes really, shall I bugzilla it?

Regards,

Hans



From abartlet at samba.org  Tue Nov 13 20:40:52 2007
From: abartlet at samba.org (Andrew Bartlett)
Date: Wed, 14 Nov 2007 07:40:52 +1100
Subject: openssl097a package retirement
In-Reply-To: <fhcg00$jul$1@ger.gmane.org>
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
	<3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
	<1194900390.17465.37.camel@vespa.kabelta.loc>
	<fhcg00$jul$1@ger.gmane.org>
Message-ID: <1194986452.15292.67.camel@naomi>


On Tue, 2007-11-13 at 09:31 -0600, Rex Dieter wrote:
> Tomas Mraz wrote:
> 
> > But I'm curious why HTTrack
> > dlopens it and not directly links to it.
> 
> HTTrack is GPL, and openssl isn't GPL-compatible.

This is something that needs to be fixed, regardless of dlopen().  I
don't think you can argue that dlopen() is any different to the actions
of ld-linux.so.2...

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/7b5ea524/attachment.sig>

From rdieter at math.unl.edu  Tue Nov 13 20:46:04 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 13 Nov 2007 14:46:04 -0600
Subject: openssl097a package retirement
References: <1187726092.3852.37.camel@vespa.kabelta.loc>
	<3170f42f0711120244q1810499bj1da75ea1fe0188a3@mail.gmail.com>
	<1194875481.2894.2.camel@localhost.localdomain>
	<fh9sr6$kgb$1@ger.gmane.org>
	<20071112165406.GC3261@nostromo.devel.redhat.com>
	<3170f42f0711120907w2e5acc4bidbb7279b256ddef2@mail.gmail.com>
	<20071112171549.GA5460@nostromo.devel.redhat.com>
	<3170f42f0711120934m5c7710e1n89450176056d7584@mail.gmail.com>
	<1194900390.17465.37.camel@vespa.kabelta.loc>
	<fhcg00$jul$1@ger.gmane.org> <1194986452.15292.67.camel@naomi>
Message-ID: <fhd2ec$p0t$1@ger.gmane.org>

Andrew Bartlett wrote:

> I
> don't think you can argue that dlopen() is any different to the actions
> of ld-linux.so.2...

Many projects *do* argue and believe that.

-- Rex



From notting at redhat.com  Tue Nov 13 20:56:07 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 15:56:07 -0500
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <473A0BD0.6010207@hhs.nl>
References: <4739F838.7060504@hhs.nl>
	<20071113192358.GA7969@nostromo.devel.redhat.com>
	<473A0728.3050601@hhs.nl>
	<20071113202844.GA10485@nostromo.devel.redhat.com>
	<473A0BD0.6010207@hhs.nl>
Message-ID: <20071113205607.GA21947@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> I just did a reboot to confirm, it gets loaded by default on my machine. 
> Pretty clean F-8 install. Done from an F-8 x86_64 livecd. Updates applied, 
> some packages installed, no fancy changes really, shall I bugzilla it?

Sure. Do you see it referenced any place in your udev config aside from
making the device nodes?

Bill



From alan at redhat.com  Tue Nov 13 20:57:35 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 13 Nov 2007 15:57:35 -0500
Subject: License review for new itext version
In-Reply-To: <loom.20071113T180637-280@post.gmane.org>
References: <21863.192.54.193.53.1194957944.squirrel@rousalka.dyndns.org>
	<645d17210711130452y76d577elbdb6539a76a60f84@mail.gmail.com>
	<loom.20071113T180637-280@post.gmane.org>
Message-ID: <20071113205734.GA31816@devserv.devel.redhat.com>

Thanks a lot

Alan



From j.w.r.degoede at hhs.nl  Tue Nov 13 21:05:51 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 13 Nov 2007 22:05:51 +0100
Subject: autoloading of kernel modules in the udev area ?!
In-Reply-To: <20071113205607.GA21947@nostromo.devel.redhat.com>
References: <4739F838.7060504@hhs.nl>	<20071113192358.GA7969@nostromo.devel.redhat.com>	<473A0728.3050601@hhs.nl>	<20071113202844.GA10485@nostromo.devel.redhat.com>	<473A0BD0.6010207@hhs.nl>
	<20071113205607.GA21947@nostromo.devel.redhat.com>
Message-ID: <473A11AF.1010806@hhs.nl>

Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>> I just did a reboot to confirm, it gets loaded by default on my machine. 
>> Pretty clean F-8 install. Done from an F-8 x86_64 livecd. Updates applied, 
>> some packages installed, no fancy changes really, shall I bugzilla it?
> 
> Sure. Do you see it referenced any place in your udev config aside from
> making the device nodes?
> 

Its referenced from /etc/udev/rules.d/60-persistent-storage.rules, but that 
seems harmless, anyways I'll put this in bugzilla first thing tomorrow.

Regards,

Hans




From ml at deadbabylon.de  Tue Nov 13 22:21:42 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 13 Nov 2007 23:21:42 +0100
Subject: KDE-SIG weekly report (46/2007)
Message-ID: <200711132321.49086.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 46/2007

Time: 2007-11-13 17:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-13

Meeting log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-13?action=AttachFile&do=get&target=fedora-kde-sig-2007-11-13.txt

----------------------------------------------------------------------------------

= Participants =

ArthurPemberton 
KevinKofler
LaithJuwaidah
RexDieter
SebastianVahl
PavelShevchuk 

----------------------------------------------------------------------------------

= Agenda =

* Fedora 8 is out, it's time for some review 
 * KDE-related articles about Fedora 8 
 * How good works knetworkmanager/nm-applet for the end user 
 * How good works pulseaudio in KDE for the end user 
 * Retrospect the development process F7 to F8 
* The weekly KDE4 talk 
* 1 background per hour (possibly good enough?) 
* Package QPackageKit? 
* Bugs: 
 * KDE logout doesn't work (#376331)
 * kdebase: unable to mount removable/ntfs (#378041)

= Summary =

o Fedora 8 is out, it's time for some review 
- We haven't found a KDE-related article for F8
- Pulseaudio seems to have no kde-specific issues


o The weekly KDE4 talk
- The focus atm is on kde4 dev platform + kdegames, kdeedu
- Two reviews were submitted: 
 - ggz-client-libs - Client libraries for GGZ gaming zone [1] (for kdegames)
 - kdebase-runtime - K Desktop Environment - Runtime [2]

o  1 background per hour
- Script: http://ljuwaida.fedorapeople.org/Artwork/Infinity/KDE/Wallpaper/
- Backgrounds: http://people.redhat.com/duffy/artwork/infinity-24/
- KDE doesn't support resizing the images automatically, so there is needed 
another option
- KDE doesn't support stretching images of maximal resolution 

o Package QPackageKit?
- For the moment QPackageKit seems not to be too incomplete for daily use
- Packaging should start when QPackageKit gets mature
- PavelShevchuk is about to start developing a gui for KDE4 based on 
libqpackagekit
- If packaging QPackageKit libqpackagekit and qpackagekit should be separate 
packages

o recent/active kde bugs
- KDE logout doesn't work [3]
- kdebase: unable to mount removable/ntfs [4]
- System Tray in panel shows blank areas [5]
- hidden GtkStatusIcon never reappears under KDE [6]
- kdm: xdmcp no log in [7]

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-20

----------------------------------------------------------------------------------

= Links =

[1] https://bugzilla.redhat.com/show_bug.cgi?id=370751
[2] https://bugzilla.redhat.com/show_bug.cgi?id=374531
[3] https://bugzilla.redhat.com/show_bug.cgi?id=376331
[4] https://bugzilla.redhat.com/show_bug.cgi?id=378041
[5] https://bugzilla.redhat.com/show_bug.cgi?id=380571 
[6] https://bugzilla.redhat.com/show_bug.cgi?id=214222
[7] ttps://bugzilla.redhat.com/show_bug.cgi?id=243560
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/3dfd2e32/attachment.sig>

From ajackson at redhat.com  Wed Nov 14 01:28:28 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Tue, 13 Nov 2007 20:28:28 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1194294608.15341.204.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
Message-ID: <1195003708.2292.13.camel@localhost.localdomain>

On Mon, 2007-11-05 at 15:30 -0500, Adam Jackson wrote:
> I plan to rebase the X server to git master a week from today (Monday,
> November 12), which means the changes should hit rawhide on Tuesday.

Okay, so that didn't happen.  But things are mostly built now, at least
for the big important core bits.  They should be on their way to a
mirror near you tomorrow, assuming the rawhide push goes out.

If you're not using radeon/nv/intel, expect that X will break, and that
you'll need to switch to vesa or fbdev.  If you're using an input driver
other than keyboard or mouse, expect those devices to stop working.

I'll be cleaning up the rest of the mess as we go.  Please do file bugs
about any weirdness you encounter (outside of the above known caveats).

- ajax



From tmus at tmus.dk  Wed Nov 14 01:13:47 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Tue, 13 Nov 2007 22:13:47 -0300
Subject: Improving halt package interaction...
Message-ID: <fhdi4e$7on$1@ger.gmane.org>

Hi all...

I'd like to bring up a suggestion that would make it easier for 
packagers to modify the halt process, without resorting to changing 
files owned by other packages.

Currently /etc/init.d/halt provides a hook into the halt process via an 
/sbin/halt.local file. If this file exists and is executable, it will be 
run during the halt process. This makes it possible for system 
administrators to write their own halt modifier (typically needed when 
dealing with UPSes and possibly other types of packages).

I think it would be very valuable to extend this functionality of 
/etc/init.d/halt to support a /etc/halt.d/ directory in addition to the 
halt.local script (Why is halt.local currently not located in /etc along 
with rc.local and such but in /sbin btw?). This would allow a package 
(an UPS software package as an example) to drop a halt modifier script 
in /etc/halt.d/ to take care of prepping the system for halt (rather 
that poweroff) and initiate a delayed UPS poweroff, if a mains powerloss 
condition was detected. Currently the package will have to hack either 
/sbin/halt.local, which could be difficult, or /etc/init.d/halt which 
would be just plain bad. Usually they will simply leave this out and the 
system admin will have to set it up manually, for the UPS to work properly.

The current version of the /etc/init.d/halt script (from 
initscripts-8.60-1) includes UPS handling code for the NUT UPS 
software(i think). NUT could easily be made to use the new /etc/halt.d/ 
infrastructure too, and /etc/init.d/halt could get rid of the 
non-generic UPS handling code, which IMHO should be avoided anyway...

What do you guys think about this?

/Thomas



From davej at redhat.com  Wed Nov 14 02:49:49 2007
From: davej at redhat.com (Dave Jones)
Date: Tue, 13 Nov 2007 21:49:49 -0500
Subject: kernel-PAE and NX (No eXecute)
In-Reply-To: <200711122008.08668.opensource@till.name>
References: <200711122008.08668.opensource@till.name>
Message-ID: <20071114024949.GA12899@redhat.com>

On Mon, Nov 12, 2007 at 08:08:08PM +0100, Till Maas wrote:
 > Hiyas,
 > 
 > is still the kernel-PAE kernel needed in Fedora to use NX (No eXcute)?

Yes.  The NX bit lives in the pagetables defined in the PAE format.
There's no room in the non-PAE variant, so this won't change.
It's a hardware limitation that the kernel cannot work around.

If you install the non-PAE kernel, execshield will 'emulate' NX using
segmentation hacks.

 > I read 
 > that the 2.6.23 kernel supports NX without the need to activate 64G memory 
 > support?

not true.

 > If PAE for NX is not yet enabled in the normal kernel package, can 
 > we enable it and rename the -PAE package to e.g. HIGHMEM64 or similiar, to 
 > make it more obvious what it is useful for?

I see no reason to change the existing naming

	Dave

-- 
http://www.codemonkey.org.uk



From dmc.fedora at filteredperception.org  Wed Nov 14 02:59:58 2007
From: dmc.fedora at filteredperception.org (Douglas McClendon)
Date: Tue, 13 Nov 2007 20:59:58 -0600
Subject: Improving halt package interaction...
In-Reply-To: <fhdi4e$7on$1@ger.gmane.org>
References: <fhdi4e$7on$1@ger.gmane.org>
Message-ID: <473A64AE.9090406@filteredperception.org>

Thomas M Steenholdt wrote:
> Hi all...
> 
> I'd like to bring up a suggestion that would make it easier for 
> packagers to modify the halt process, without resorting to changing 
> files owned by other packages.

...

> I think it would be very valuable to extend this functionality of 
> /etc/init.d/halt to support a /etc/halt.d/ directory in addition to the 
> halt.local script 

...

> What do you guys think about this?

I for one could immediately use this for my LiveUSB 'persistence' 
feature.  I.e. instead of booting a livecd/usb with copy-on-write rootfs 
changes going to ram, the changes go to a file on a usbstick filesystem. 
  The reason that I need* to muck with halt.local is to cleanly 
readonly-remount the usbstick fs.  (*) actually I need to do this after 
the rootfs gets readonly-remounted, which is technically the very next 
thing after the current halt.local call.  But I can envision if 
/etc/halt.d/ existed, I could do a 99(last) script, which basically 
replicates the very short amount of code that happens after the current 
halt.local call.

Unfortunately the one other thing that the feature needs to change in 
halt, is to somehow prevent the usbstick filesystem from being unmounted 
before the rootfs unmounted(/remount-ro).  Currently I do this hackishly 
by patching halt and functions (with the assumption that the protected 
filesystem is mounted on /mnt/overlayfs).  Anybody have any advice for a 
proper clean way I should submit a patch for that might be accepted?

-dmc



From mastahnke at gmail.com  Wed Nov 14 03:24:10 2007
From: mastahnke at gmail.com (Michael Stahnke)
Date: Tue, 13 Nov 2007 21:24:10 -0600
Subject: Improving halt package interaction...
In-Reply-To: <473A64AE.9090406@filteredperception.org>
References: <fhdi4e$7on$1@ger.gmane.org>
	<473A64AE.9090406@filteredperception.org>
Message-ID: <7874d9dd0711131924k52d97be2o50f7de031df18c3c@mail.gmail.com>

On Nov 13, 2007 8:59 PM, Douglas McClendon
<dmc.fedora at filteredperception.org> wrote:
> Thomas M Steenholdt wrote:
> > Hi all...
> >
> > I'd like to bring up a suggestion that would make it easier for
> > packagers to modify the halt process, without resorting to changing
> > files owned by other packages.
>
> ...
>
> > I think it would be very valuable to extend this functionality of
> > /etc/init.d/halt to support a /etc/halt.d/ directory in addition to the
> > halt.local script
>
> ...
>
> > What do you guys think about this?
>
> I for one could immediately use this for my LiveUSB 'persistence'
> feature.  I.e. instead of booting a livecd/usb with copy-on-write rootfs
> changes going to ram, the changes go to a file on a usbstick filesystem.
>   The reason that I need* to muck with halt.local is to cleanly
> readonly-remount the usbstick fs.  (*) actually I need to do this after
> the rootfs gets readonly-remounted, which is technically the very next
> thing after the current halt.local call.  But I can envision if
> /etc/halt.d/ existed, I could do a 99(last) script, which basically
> replicates the very short amount of code that happens after the current
> halt.local call.
>
> Unfortunately the one other thing that the feature needs to change in
> halt, is to somehow prevent the usbstick filesystem from being unmounted
> before the rootfs unmounted(/remount-ro).  Currently I do this hackishly
> by patching halt and functions (with the assumption that the protected
> filesystem is mounted on /mnt/overlayfs).  Anybody have any advice for a
> proper clean way I should submit a patch for that might be accepted?
>
> -dmc
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

I also like the idea.  It could send out calls to my Lights Out
Devices and monitoring.

stahnma



From notting at redhat.com  Wed Nov 14 03:44:10 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Nov 2007 22:44:10 -0500
Subject: Improving halt package interaction...
In-Reply-To: <fhdi4e$7on$1@ger.gmane.org>
References: <fhdi4e$7on$1@ger.gmane.org>
Message-ID: <20071114034410.GA19700@nostromo.devel.redhat.com>

Thomas M Steenholdt (tmus at tmus.dk) said: 
> The current version of the /etc/init.d/halt script (from 
> initscripts-8.60-1) includes UPS handling code for the NUT UPS software(i 
> think). NUT could easily be made to use the new /etc/halt.d/ infrastructure 
> too, and /etc/init.d/halt could get rid of the non-generic UPS handling 
> code, which IMHO should be avoided anyway...
>
> What do you guys think about this?

What's needed here that can't just be done with a 'normal' script
that runs in runlevel 0/6?

Bill



From lightsolphoenix at gmail.com  Wed Nov 14 05:09:15 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Wed, 14 Nov 2007 00:09:15 -0500
Subject: Package for Qt-Jambi?
Message-ID: <473A82FB.9030408@gmail.com>

Since there's currently a discussion going on around Java components due 
to IcedTea, I was wondering if anyone had considered packaging Qt-Jambi 
for Fedora.  There is a GPL version, after all, and an Eclipse plugin...

http://trolltech.com/developer/downloads/qt



From seg at haxxed.com  Wed Nov 14 05:30:20 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 13 Nov 2007 23:30:20 -0600
Subject: Fedora 8 curl breaks Second Life
Message-ID: <1195018220.32559.98.camel@localhost>

Okay, Fedora 8 breaks the Second Life client, which I have been working
on packaging for Fedora but is not yet accepted. It appears to be due to
curl switching to NSS. More info here:

https://lists.secondlife.com/pipermail/sldev/2007-November/006674.html

This means Second Life is completely broken on Fedora 8. What should I
do to get this fixed? The Second Life review bug is 233946, though the
last build posted there is way out of date. I suppose I can come up with
a new set of builds if needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/f44df536/attachment.sig>

From wtogami at redhat.com  Wed Nov 14 05:32:10 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 14 Nov 2007 00:32:10 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113151059.GA25455@angus.ind.WPI.EDU>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>	<20071113010910.GC2651@free.fr>
	<47391DEF.7060508@redhat.com>	<473942E7.6010706@gmail.com>
	<20071113081717.GA2574@free.fr>	<1194950980.31176.38.camel@home.alexander.bostrom.net>	<20071113140543.GA2582@free.fr>
	<20071113151059.GA25455@angus.ind.WPI.EDU>
Message-ID: <473A885A.1050209@redhat.com>

Chuck Anderson wrote:
> I'd be okay with using /var/lib/tftp since there seems to be precedent 
> for that, and it breaks FHS the "least".
> 
> My argument was mainly against /tftpboot since / might be too small or 
> read-only.
> 

I personally am leaning toward /var/lib/tftp for these reasons.

As nothing really stops me from just doing it, and doing so doesn't 
break other tools, I'm going forward with this path instead of /tftpboot 
for LTSP.

Requesting selinux-policy addition now.  Both old and new directories 
should be allowed by selinux for a while.

Warren Togami
wtogami at redhat.com



From peter at thecodergeek.com  Wed Nov 14 05:36:22 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 13 Nov 2007 21:36:22 -0800
Subject: rpms/915resolution/devel 965GM.patch, NONE, 1.1
	915resolution.spec,  1.11, 1.12
In-Reply-To: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
Message-ID: <1195018582.3036.2.camel@tuxhugs>

On Wed, 2007-11-14 at 00:11 -0500, Chris Weyl wrote:
> @@ -19,7 +20,7 @@
>  Source100:      README.fedora
>  
>  # for the add/remove/condrestart service stuff.
> -Requires(post):   /sbin/chkconfig
> +rEQuires(post):   /sbin/chkconfig
>  Requires(preun):  /sbin/chkconfig
>  Requires(preun):  /sbin/service
>  

Err, I'm presuming that this was unintentional? :)
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071113/1278ea5e/attachment.sig>

From opensource at till.name  Wed Nov 14 09:00:09 2007
From: opensource at till.name (Till Maas)
Date: Wed, 14 Nov 2007 10:00:09 +0100
Subject: kernel-PAE and NX (No eXecute)
In-Reply-To: <20071114024949.GA12899@redhat.com>
References: <200711122008.08668.opensource@till.name>
	<20071114024949.GA12899@redhat.com>
Message-ID: <200711141000.22431.opensource@till.name>

On Mi November 14 2007, Dave Jones wrote:
> On Mon, Nov 12, 2007 at 08:08:08PM +0100, Till Maas wrote:

>  > I read
>  > that the 2.6.23 kernel supports NX without the need to activate 64G
>  > memory support?
>
> not true.

Here is a kernel git changelog entry that says it is true:

| i386: divorce CONFIG_X86_PAE from CONFIG_HIGHMEM64G
| 
| PAE is useful for more than supporting more than 4GB RAM.  It supports
| expanded swapspace and NX executable protections.  Some users may want NX
| or expanded swapspace support without the overhead or instability of
| highmem.  For these reasons, the following patch divorces CONFIG_X86_PAE
| from CONFIG_HIGHMEM64G.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c673f1a9d994de501b674b2bb6a48bd5e912afe0

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/f1d329bf/attachment.sig>

From j.w.r.degoede at hhs.nl  Wed Nov 14 09:13:34 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 10:13:34 +0100
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <1195018220.32559.98.camel@localhost>
References: <1195018220.32559.98.camel@localhost>
Message-ID: <473ABC3E.9090603@hhs.nl>

Callum Lerwick wrote:
> Okay, Fedora 8 breaks the Second Life client, which I have been working
> on packaging for Fedora but is not yet accepted. It appears to be due to
> curl switching to NSS. More info here:
> 
> https://lists.secondlife.com/pipermail/sldev/2007-November/006674.html
> 
> This means Second Life is completely broken on Fedora 8. What should I
> do to get this fixed? The Second Life review bug is 233946, though the
> last build posted there is way out of date. I suppose I can come up with
> a new set of builds if needed.

Please update the review ticket with all the latest info. Also please finish 
the work on the needed libraries asap please.

Will a simple rebuild fix the F-8 problem? In that case I think publishing a 
set of rebuild packages is a good idea, even better would be to get things 
reviewed and build into Fedora, on the buildsys things should always build 
against the correct stuff and a rebuild is nice and easy.

I'm more then willing to help with reviewing and or other stuff.

Regards,

Hans



From valent.turkovic at gmail.com  Wed Nov 14 09:28:53 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 14 Nov 2007 10:28:53 +0100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <1194958858.2025.19.camel@cutter>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
	<Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
	<64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>
	<1194958858.2025.19.camel@cutter>
Message-ID: <64b14b300711140128n7ae30428lee0ed62e376240b6@mail.gmail.com>

On 11/13/07, seth vidal <skvidal at fedoraproject.org> wrote:
>
> On Tue, 2007-11-13 at 11:12 +0100, Valent Turkovic wrote:
>
> > ps. I'm able to send profile only after 10 attempts, I usually get this error:
> >
> > Send this information to the Smolt server? (y/n) y
> > Error contacting Server: [Errno 14] HTTP Error 500: Internal error
> > Could not send - Exiting
> >
> >
> > or this one:
> >
> > Send this information to the Smolt server? (y/n) y
> > Error contacting Server: [Errno 12] Timeout: <urlopen error timed out>
> > Could not send - Exiting
>
>
> that might be related to the demand still being high on all of the boxes
> in the coloc. It might also be to a memory leak in smolts server side.
> I've given the process a restart to see if it helps it.
>
> -sv

Yesterday I couldn't send smolt profile, and I tried for over half an
hour... today I sent it without problem the first time.

Thanks!

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From valent.turkovic at gmail.com  Wed Nov 14 09:31:01 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Wed, 14 Nov 2007 10:31:01 +0100
Subject: sending multiple (different) smolt profiles
In-Reply-To: <7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
Message-ID: <64b14b300711140131g6ccf9800i5db2688970804772@mail.gmail.com>

On 11/12/07, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> On Nov 12, 2007 3:54 AM, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> > Hi,
> >
> > I have 2 laptops and I used the smoltSendProfile and I seem to get the
> > same url for both laptops, ie. the later sent profile overwrites the
> > previous one...
> >
> > I'm sending both profiles from same adsl line and I'm behing a NAT
> > adsl router, so could this be an issue (same IP) ?
> >
> > Is this a feature or a bug?
> >
> > How can I send multiple laptop profiles and see them all online?
> >
>
> That URL is based off your "UUID" which is generated unique to smolt.
> It's found in either /etc/smolt for most distros, or
> /etc/sysconfig/hw-uuid.  if you copy this file around, then of course,
> it's going to look like you're using the same machine.  UUID
> management in the client needs a bit of work, but if you're looking
> for a new UUID in a hurry, in our mercurial repository, there's an
> install script for generating UUIDs.  Fetch it, make sure the source
> puts the UUID where it should go for your distro, (the script is in
> python, nothing terribly difficult), and run it.
>
> Feel free to post back if you have trouble with this, and I'll type up
> a longer step by step explanation.
>
> Cheers,
> Yaakov

Please look at this smoltprofile:
http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f

this was my older laptop HP Compaq nx9030, then my newer one overwrote
it with its profile (HP dv6426) and not it is some ones and completely
different laptop...

This uuid thing is broken in some way! How can this happen?

Valent,

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From seg at haxxed.com  Wed Nov 14 10:50:35 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 14 Nov 2007 04:50:35 -0600
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <473ABC3E.9090603@hhs.nl>
References: <1195018220.32559.98.camel@localhost>  <473ABC3E.9090603@hhs.nl>
Message-ID: <1195037436.32559.200.camel@localhost>

On Wed, 2007-11-14 at 10:13 +0100, Hans de Goede wrote:
> Will a simple rebuild fix the F-8 problem? In that case I think
> publishing a 
> set of rebuild packages is a good idea, even better would be to get
> things 
> reviewed and build into Fedora, on the buildsys things should always
> build 
> against the correct stuff and a rebuild is nice and easy.

No, rebuilding does not fix it. Something seems broke in the way curl
works with certificates. I don't know curl or SSL at all which is why I
could use some help. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/c1463429/attachment.sig>

From debarshi.ray at gmail.com  Wed Nov 14 11:51:26 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 14 Nov 2007 17:21:26 +0530
Subject: sending multiple (different) smolt profiles
In-Reply-To: <64b14b300711140128n7ae30428lee0ed62e376240b6@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
	<Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
	<64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>
	<1194958858.2025.19.camel@cutter>
	<64b14b300711140128n7ae30428lee0ed62e376240b6@mail.gmail.com>
Message-ID: <3170f42f0711140351s3c55e090k6623059371c6bf50@mail.gmail.com>

> Yesterday I couldn't send smolt profile, and I tried for over half an
> hour... today I sent it without problem the first time.

Same here.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From ndbecker2 at gmail.com  Wed Nov 14 12:01:47 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 14 Nov 2007 07:01:47 -0500
Subject: qct review request, no response?
Message-ID: <fheo3b$8nv$1@ger.gmane.org>

I've seen no response to:
https://bugzilla.redhat.com/show_bug.cgi?id=373621

Did I do something wrong, or is everyone busy?



From buildsys at redhat.com  Wed Nov 14 12:08:35 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 14 Nov 2007 07:08:35 -0500
Subject: rawhide report: 20071114 changes
Message-ID: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>

New package catdoc
	A program which converts Microsoft office files to plain text

New package dblatex
	DocBook to LaTeX/ConTeXt Publishing

New package monit
	Manages and monitors processes, files, directories and devices

New package telepathy-haze
	A multi-protocol Libpurple connection manager for Telepathy


Removed package SDLmm

Removed package paragui

Removed package pdftohtml

Updated Packages:

915resolution-0.5.3-3.fc9
-------------------------
* Tue Nov 13 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.5.3-3
- incorporate patch from bz #331411

NetworkManager-1:0.7.0-0.7.svn3030.fc9
--------------------------------------
* Tue Nov 13 2007 Jeremy Katz <katzj at redhat.com> - 1:0.7.0-0.7.svn3030
- sync with what was in F-8; rebuild against new dbus-glib

* Thu Nov 01 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.1.svn3030
- Fix applet crash with USB devices that don't advertise a product or vendor
    (rh #337191)

* Sat Oct 27 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.5.svn3030
- Fix crash when getting WPA secrets (rh #355041)

asc-2.0.1.0-1.fc9
-----------------
* Sun Oct 28 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 2.0.1.0-1
- New upstream version 2.0.1.0
- Use included (patched/bugfixed) paragui copy
- Use included (patched/bugfixed) SDLmm copy
baekmuk-bdf-fonts-2.2-5.fc9
---------------------------
* Wed Nov 14 2007 Jens Petersen <petersen at redhat.com> - 2.2-5
- better url
- use fontname macro

baekmuk-ttf-fonts-2.2-7.fc9
---------------------------
* Wed Nov 14 2007 Jens Petersen <petersen at redhat.com> - 2.2-7
- better url
- use fontname and fontdir macros

bouml-3.3.1-1.fc9
-----------------
* Tue Nov 13 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.3.1-1
- Version bump to 3.3.1.
- Removed Encoding from Desktop Entry.

* Sun Nov 04 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.0.2-1
- Version bump to 3.0.2. Closes Red Hat Bugzilla bug #326641.
- Introduced PHP support.
- Backported bug-fix from 3.3.

* Thu Oct 11 2007 Debarshi Ray <rishi at fedoraproject.org> - 2.32-1
- Version bump to 2.32. Closes Red Hat Bugzilla bug #303721.

byacc-1.9.20070509-1.fc9
------------------------
* Tue Nov 13 2007 Petr Machata <pmachata at redhat.com> - 1.9.20070509-1
- Update to the 20070509 release.
- Related: #225632

control-center-1:2.21.2-1.fc9
-----------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

* Tue Oct 30 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-7
- Remove useless "start esd" preference

coreutils-6.9-13.fc9
--------------------
* Tue Nov 13 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-13
- fixed bug in selinux patch which caused bad preserving
  of security context in install(#319231)

dasher-4.7.0-1.fc9
------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 4.7.0-1
- Update to 4.7.0

digikam-0.9.3-0.1.beta2.fc9
---------------------------
* Tue Nov 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.9.3-0.1.beta2
- digikam-0.9.3-beta2

dmraid-1.0.0.rc14-5.fc9
-----------------------
* Wed Nov 14 2007 Ian Kent <ikent at redhat.com> - 1.0.0.rc14-5
- Bug 379911: dmraid needs to generate UUIDs for lib device-mapper
- Bug 379951: dmraid needs to activate device-mapper mirror resynchronization error handling

empathy-0.21.2-1.fc9
--------------------
* Tue Nov 13 2007 Peter Gordon <peter at thecodergeek.com> - 0.21.2-1
- Update to new upstream release (0.21.2)
- Drop backported drag-and-drop patch (fixed upstream):
    - svn380-fix-contact-DnD.patch
- Update README.ConnectionManagers: Include Haze package note, remove Galago
  note (a feed-only connection manager isn't useful for instant messaging),
  and fix some wording.

exiv2-0.16-0.1.pre1.fc9
-----------------------
* Tue Nov 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.16-0.1.pre1
- exiv2-0.16-pre1

fontconfig-2.5.0-1.fc9
----------------------
* Tue Nov 13 2007 Behdad Esfahbod <besfahbo at redhat.com> - 2.5.0-1
- Update to 2.5.0.

* Tue Nov 06 2007 Behdad Esfahbod <besfahbo at redhat.com> - 2.4.92-1
- Update to 2.4.92.
- Mark /etc/fonts/conf.d/* as config(noreplace).
- Remove most of our conf file, all upstreamed except for
  75-blacklist-fedora.conf that I'm happily dropping.  Who has
  Hershey fonts these days...
- ln upstream'ed 25-unhint-nonlatin.conf from conf.avail in conf.d
- Add 25-no-bitmap-fedora.conf which is the tiny remaining bit
  of conf that didn't end up upstream.  Can get rid of it in the
  future, but not just yet.

* Thu Oct 25 2007 Behdad Esfahbod <besfahbo at redhat.com> - 2.4.91-1
- Update to 2.4.91.
- Add /usr/local/share/fonts to default config. (#147004)
- Don't rebuild docs, to fix multilib conflicts. (#313011)
- Remove docbook and elinks BuildRequires and stuff as we don't
  rebuild docs.

gedit-1:2.20.2-2.fc9
--------------------
* Tue Nov 13 2007 Florian La Roche <laroche at redhat.com> - 1:2.20.2-2
- define pango_version
gmime-2.2.11-1.fc9
------------------
* Tue Nov 13 2007 Matthias Clasen  <mclasen at redhat.com> 2.2.11-1
- Update to 2.2.11

gnome-applets-1:2.21.1-1.fc9
----------------------------

gnome-desktop-2.21.2-1.fc9
--------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

gnome-games-1:2.21.2-1.fc9
--------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.21.2-1
- Update to 2.21.2

gnome-panel-2.20.1-7.fc9
------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-7
- Fix a problem with the intlclock GConf schema

* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-6
- Reenable intlclock

* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-5
- Split off a libs subpackage to break a cyclic dependency
- Build without intlclock for bootstrapping purposes

gnome-power-manager-2.20.1-1.fc9
--------------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1
- Drop upstreamed patches

gnome-screensaver-2.20.0-11.fc9
-------------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-11
- Rebuild against newer libgnomekbd

gnome-system-monitor-2.21.2-1.fc9
---------------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

gnome-themes-2.21.2-1.fc9
-------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2
- Drop old Clearlooks tweaking

* Mon Oct 15 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates)

icu-3.8-3.fc9
-------------
* Tue Nov 13 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-3
- add icu.openoffice.org.patch

* Sat Oct 27 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-2
- add icu.icu6008.arm.padding.patch to fix an arm problem

* Tue Oct 02 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-1
- latest version

icu4j-0:3.6.1-1jpp.6.fc9
------------------------
* Tue Nov 13 2007 Andrew Overholt <overholt at redhat.com> 3.6.1-1jpp.6
- Bump release and change updatetimestamp patch to have DOS
  line-endings.

* Tue Nov 13 2007 Andrew Overholt <overholt at redhat.com> 3.6.1-1jpp.5
- Bump release.

* Fri Sep 28 2007 Andrew Overholt <overholt at redhat.com> 3.6.1-1jpp.4
- Update timestamp to match Eclipse 3.3.1 release.

irssi-0.8.12-3.fc9
------------------
* Sun Nov 11 2007 Marek Mahut <mmahut fedoraproject.org> - 0.8.12-3
- Enabling perl build-in support as per request in BZ#375121

* Mon Oct 08 2007 Marek Mahut <mmahut fedoraproject.org> - 0.8.12-1
- New release
- Fixes bug from BZ#239511, dropping patch

* Sun Aug 19 2007 Marek Mahut <mmahut fedoraproject.org> - 0.8.11-5
- Fixing properly irssi-support-meta-cursor-xterm.patch

jd-1.9.7-0.3.svn1515.fc9
------------------------
* Wed Nov 14 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.svn1515
- trunk 1515

* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

* Fri Nov 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyoa.c.jp> - 1.9.7-0.2.beta071101
- 1.9.7 beta 071101

kdemultimedia-6:3.5.8-8.fc8
---------------------------
* Tue Oct 30 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-8
- -libs: Requires: %name (multilib upgrades again)
- scriptlet fixes

kphotoalbum-3.0.2-7.fc9
-----------------------
* Tue Nov 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.0.2-7
- respin for exiv2-0.16

kst-1.4.0-10.fc9
----------------
* Tue Nov 13 2007 Matthew Truch <matt at truch.net> - 1.4.0-10
- Remove gsl-devel BuildRequires as gsl is GPLv3+ which is incompatable with qt.

ldns-1.2.1-4.fc9
----------------
* Tue Nov 13 2007 Paul Wouters <paul at xelerance.com> - 1.2.1-4
- Try to fix racing ln -s statements in parallel builds

* Fri Nov 09 2007 Paul Wouters <paul at xelerance.com> - 1.2.1-3
- Added patch for ldns-read-zone that does not put @. in RRDATA

* Fri Oct 19 2007 Paul Wouters <paul at xelerance.com> - 1.2.1-2
- Use install -p to work around multilib conflicts for .h files

less-409-2.fc9
--------------
* Tue Nov 13 2007 Ivana Varekova <varekova at redhat.com> - 409-2
- remove which usage (#312591)

* Mon Oct 22 2007 Ivana Varekova <varekova at redhat.com> - 409-1
- upgrade to 409
- remove useless/obsolete patches
- add autoconf buildrequires

* Mon Oct 01 2007 Ivana Varekova <varekova at redhat.com> - 406-12
- change license tag
- fix 312591 - add which dependency

libgnomecanvas-2.20.1.1-1.fc9
-----------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> 2.20.1.1-1
- Update to 2.20.1.1

libgnomekbd-2.21.1-1.fc9
------------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.1-1
- Update to 2.21.1

libgtop2-2.21.1-1.fc9
---------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.1-1
- Update top 2.21.1

libkexiv2-0.1.6-2.fc9
---------------------
* Tue Nov 13 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.1.6-2
- respin against exiv2-0.16

libthai-0.1.9-2.fc9
-------------------
* Tue Nov 13 2007 Behdad Esfahbod <besfahbo at redhat.com> 0.1.9-2
- Add libthai-0.1.9-doxygen-segfault.patch to workaround doxygen segfault

* Tue Aug 28 2007 Behdad Esfahbod <besfahbo at redhat.com> 0.1.9-1
- Update to 0.1.9
- Adjust patch

libwnck-2.21.2.1-1.fc9
----------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2.1-1
- Update to 2.21.2.1

logwatch-7.3.6-12.fc9
---------------------
* Tue Nov 13 2007 Ivana Varekova <varekova at redhat.com> 7.3.6-12
- change Print configuration (#378901)

metacity-2.21.1-1.fc9
---------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.1-1
- Update to 2.21.1

monodevelop-0.17-4.fc9
----------------------
* Tue Nov 13 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.17-4
- added R mono-data-sqlite

moreutils-0.25-1.fc9
--------------------
* Wed Nov 14 2007 Marc Bradshaw <fedora at marcbradshaw.co.uk> 0.25-1.fc9
- New upstream version

* Wed Sep 19 2007 Marc Bradshaw <fedora at marcbradshaw.co.uk> 0.24-2.fc9
- Added optional perl modules to requirements

* Tue Sep 18 2007 Marc Bradshaw <fedora at marcbradshaw.co.uk> 0.24-1.fc9
- Version update
- Fixed specfile issues

nsd-3.0.7-1.fc9
---------------
* Tue Nov 13 2007 Paul Wouters <paul at xelerance.com> - 3.0.7-1
- Updated to new version
- fix RELNOTES/README to be utf8
- Fix path to nsd.db in cron job.

* Thu Nov 08 2007 Paul Wouters <paul at xelerance.com> - 3.0.6-7
- Modified cron to only rebuild/reload when zone updates
  have been received

orca-2.21.2-1.fc9
-----------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

perl-DBI-1.601-1.fc9
--------------------
* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 1.601-1
- Update to latest CPAN version: 1.601
- Fix some issues from package review:
  - patch to change #! line in script
  - make script executable
  - fix requires and buildrequires

php-pear-MDB2-2.4.1-2.fc9
-------------------------
* Tue Nov 13 2007 Christopher Stone <chris.stone at gmail.com> 2.4.1-2
- Add LOB security patch (bz #379081)
php-pear-MDB2-Driver-mysql-1.4.1-3.fc9
--------------------------------------
* Tue Nov 13 2007 Christopher Stone <chris.stone at gmail.com> 1.4.1-3
- Add security patch (bz #379081)
python-gdata-1.0.9-1.fc9
------------------------
* Tue Nov 13 2007 - Bastien Nocera <bnocera at redhat.com> - 1.0.9-1
- Update to 1.0.9
radvd-1.0-5.fc9
---------------
* Tue Nov 13 2007 Martin Bacovsky <mbacovsk at redhat.com> - 1.0-5
- resolves #376081: The radvd init script exits without doing anything if /usr/sbin/radvd exists

revisor-2.0.5-9.fc9
-------------------
* Tue Nov 13 2007 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.0.5-9
- Minor bugfixes in packaging
- Other minor fixes

* Sat Oct 20 2007 Jonathan Steffan <jon a fedoraunity.org> 2.0.5-5
- Update spec for release

* Tue Oct 02 2007 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.0.5-3
- Bugfixes to x86_64 packageSack creation
- Bugfixes

rhythmbox-0.11.3-2.fc9
----------------------
* Tue Nov 13 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.3-2
- Add upstream patch to implement missing plugins support

ruby-gnome2-0.16.0-16.fc9
-------------------------
* Tue Nov 13 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.16.0-16
- Fix my typo in BuildRequires

* Tue Nov 13 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.16.0-15
- Rebuild against gecko-libs and gecko-devel (firefox 2.0.0.9).

shared-mime-info-0.22-5.fc9
---------------------------
* Tue Nov 13 2007 - Bastien Nocera <bnocera at redhat.com> - 0.22-5
- Remove Totem as the default music/movie player, it will be the
  default for movies, as only it handles them, and Rhythmbox can
  handle missing plugins now

sparse-0.4.1-1.fc9
------------------
* Tue Nov 13 2007 Roland McGrath <roland at redhat.com> - 0.4.1-1
- Upgrade to 0.4.1

strigi-0.5.7-2.fc9
------------------
* Tue Nov 13 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.5.7-2
- Rebuild for new exiv2

system-config-netboot-0.1.43-1.fc9
----------------------------------
* Wed Nov 07 2007 Radek Brich <rbrich at redhat.com> - 0.1.43-1
- fix bug #224139: pxeboot does not allow to set NISDOMAIN
- fix bug #222764: show IP of client in pxeboot listing
- fix bug #204015: sort IP adresses numerically (by octet)
- fix bug #221206: Markup problems on system-config-services.8
  o update man pages
  o documented new --nisdomain option for pxeboot
- fix bug #204090
- add /home to snapshot files, so non-root users can log in to diskless system
- gettextize more messages
- clean up .spec.in (merge with Fedora's .spec)
- clean up autogen.sh

telepathy-salut-0.1.8-1.fc9
---------------------------
* Tue Nov 13 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.1.8-1
- Update to 0.1.8.

tetex-3.0-46.fc9
----------------
* Tue Nov 13 2007 Jindrich Novy <jnovy at redhat.com> 3.0-46
- fix dvips -z buffer overflow with long href (#368591)
- fix insecure usage of temporary file in dviljk (#368611, #368641)

* Thu Nov 08 2007 Jindrich Novy <jnovy at redhat.com> 3.0-45
- fix t1lib flaw CVE-2007-4033 (#352271)
- fix CVE-2007-4352 CVE-2007-5392 CVE-2007-5393, various xpdf flaws (#345121)
- remove links to buildroot from installed files
- fix BuildRoot

* Tue Oct 16 2007 Jindrich Novy <jnovy at redhat.com> 3.0-44
- xdvi won't segfault if DVI file contains character which
  is not present in font (#243630)
- enable compilation with ccache

texinfo-4.11-3.fc9
------------------
* Tue Nov 13 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 4.11-3
- Fix info crashes when resizing window
- Resolves: #243971

tomboy-0.9.1-1.fc9
------------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 0.9.1-1
- Update to 0.9.1

vbetool-0.7-3.fc9
-----------------

vino-2.21.2-1.fc9
-----------------
* Tue Nov 13 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

which-2.18-1.fc9
----------------
* Tue Nov 13 2007 Than Ngo <than at redhat.com> 2.18-1
- 2.18

* Tue Nov 13 2007 Than Ngo <than at redhat.com> 2.16-10
- cleanup specfile
- get rid of dev dependency

* Mon Apr 23 2007 Than Ngo <than at redhat.com> - 2.16-9
- add missing which-2 script for csh
- cleanup specfile #226539

wpa_supplicant-1:0.5.7-16.fc9
-----------------------------
* Tue Nov 13 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-16
- Add IW_ENCODE_TEMP patch for airo driver and Dynamic WEP
- Fix error in wpa_supplicant-0.5.7-ignore-dup-ca-cert-addition.patch that
    caused the last error to not be printed
- Fix wpa_supplicant-0.5.7-ignore-dup-ca-cert-addition.patch to ignore
    duplicate cert additions for all certs and keys
- Change license to BSD due to linkage against OpenSSL since there is no
    OpenSSL exception in the GPLv2 license text that upstream ships

* Sun Oct 28 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-15
- Fix Dynamic WEP associations with mac80211-based drivers

* Sun Oct 28 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-14
- Don't error an association on duplicate CA cert additions

xorg-x11-drv-ati-6.7.195-5.fc9
------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 6.7.195-5
- Require xserver 1.4.99.1

xorg-x11-drv-dummy-0.2.0-6.fc9
------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 0.2.0-6
- Require xserver 1.4.99.1

xorg-x11-drv-fbdev-0.3.1-4.20071113.fc9
---------------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 0.3.1-5.20071113
- Update to git snapshot for pciaccess goodness.  Don't ask why a driver
  that doesn't touch PCI at all needs a PCI update.  I don't know either,
  and thinking about it makes me very sad.
- Require xserver 1.4.99.1

xorg-x11-drv-i810-2.1.99-1.fc9
------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 2.1.99-1
- xf86-video-intel 2.1.99.
- Drop the i810 driver.  Time to move on.
- Require xserver 1.4.99.1

xorg-x11-drv-keyboard-1.2.2-3.fc9
---------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 1.2.2-3
- BuildReq: xserver 1.4.99.1

xorg-x11-drv-mouse-1.2.3-3.fc9
------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 1.2.3-3
- Require xserver 1.4.99.1

xorg-x11-drv-nv-2.1.6-2.fc9
---------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 2.1.6-2
- Require new server ABI.

* Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 2.1.6-1
- xf86-video-nv 2.1.6

xorg-x11-drv-radeonhd-0.0.2-0.17.20071113git.fc9
------------------------------------------------
* Tue Nov 13 2007 Hans Ulrich Niedermann <hun at n-dimensional.de> - 0.0.2-0.17.20071113git
- New snapshot (upstream commit 6f1800ca52531f5baf3df2e65a7bbd93e4b1e637):
  - LVTMA TMDS: Add initial TMDS support for r5xx.
  - TMDS B: Add table with macro control values.
- Loosen requirements on xorg-x11-server-{Xorg,sdk} from 1.3 to 1.1 (FC6, EL5).
- Require pkgconfig for building (not in EL5 default buildroot).
- Adapt references to rhd_conntest in filesystem.
- Fix git:// URL in README.fedora.

xorg-x11-drv-vesa-1.3.0-11.20071113.fc9
---------------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 1.3.0-11.20071113
- Update to git snapshot for pciaccess goodness.
- Rip out legacy framebuffer support.

xorg-x11-drv-void-1.1.1-7.fc9
-----------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 1.1.1-7
- Require xserver 1.4.99.1

xorg-x11-proto-devel-7.3-7.fc9
------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 7.3-7
- inputproto-1.4.2-card32.patch: Make sure CARD32 is defined on lp64.

xorg-x11-server-1.4.99.1-0.10.fc9
---------------------------------
* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 1.4.99.1-0.10
- -devel Requires: pixman-devel and libpciaccess-devel.

* Mon Nov 12 2007 Adam Jackson <ajax at redhat.com> 1.4.99.1-0.8
- Fix buildrequires and other buildsystem nonsense.

* Fri Nov 02 2007 Adam Jackson <ajax at redhat.com> 1.4.99.1-0.6
- Merge a bunch of the more trivial patches upstream.
- New git snapshot containing the merged bits.
- Remove unused patches.
- Drop the XFree86 obsoletes.

xpa-2.1.8-1.fc9
---------------
* Tue Nov 13 2007 Sergio Pascual <sergiopr at fedoraproject dot org> 2.1.8-1
- New upstream source

xscreensaver-1:5.04-1.fc9
-------------------------
* Tue Nov 13 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.04-1
- Update to 5.04

Broken deps for i386
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	gwenview - 1.4.1-4.fc8.i386 requires libexiv2.so.0
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	qtpfsgui - 1.8.12-2.fc8.i386 requires libexiv2.so.0
	ufraw - 0.12-1.fc8.i386 requires libexiv2.so.0
	ufraw-gimp - 0.12-1.fc8.i386 requires libexiv2.so.0
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1



Broken deps for x86_64
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	gwenview - 1.4.1-4.fc8.x86_64 requires libexiv2.so.0()(64bit)
	gwenview - 1.4.1-4.fc8.i386 requires libexiv2.so.0
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	qtpfsgui - 1.8.12-2.fc8.x86_64 requires libexiv2.so.0()(64bit)
	ufraw - 0.12-1.fc8.x86_64 requires libexiv2.so.0()(64bit)
	ufraw-gimp - 0.12-1.fc8.x86_64 requires libexiv2.so.0()(64bit)
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1



Broken deps for ppc
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	gwenview - 1.4.1-4.fc8.ppc requires libexiv2.so.0
	gwenview - 1.4.1-4.fc8.ppc64 requires libexiv2.so.0()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	qtpfsgui - 1.8.12-2.fc8.ppc requires libexiv2.so.0
	ufraw - 0.12-1.fc8.ppc requires libexiv2.so.0
	ufraw-gimp - 0.12-1.fc8.ppc requires libexiv2.so.0



Broken deps for ppc64
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	gwenview - 1.4.1-4.fc8.ppc64 requires libexiv2.so.0()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	qtpfsgui - 1.8.12-2.fc8.ppc64 requires libexiv2.so.0()(64bit)
	ufraw - 0.12-1.fc8.ppc64 requires libexiv2.so.0()(64bit)
	ufraw-gimp - 0.12-1.fc8.ppc64 requires libexiv2.so.0()(64bit)





From tmus at tmus.dk  Wed Nov 14 12:31:29 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Wed, 14 Nov 2007 09:31:29 -0300
Subject: Improving halt package interaction...
In-Reply-To: <20071114034410.GA19700@nostromo.devel.redhat.com>
References: <fhdi4e$7on$1@ger.gmane.org>
	<20071114034410.GA19700@nostromo.devel.redhat.com>
Message-ID: <fhepr3$fer$1@ger.gmane.org>

Bill Nottingham wrote:
> 
> What's needed here that can't just be done with a 'normal' script
> that runs in runlevel 0/6?
> 

Other than what the other guys have mentioned, like perhaps making it 
possible to run scripts after ro remounting "/", a delayed UPS poweroff 
from a normal initscript is less precise, since you have no reliable 
measure of how long the system will take to power down (perhaps you're 
running large databases?). You could end up powering off the UPS outlets 
before the system is ready for it. Or specifying a long delay, the 
system might need to wait for far too long for the system to restart, 
even though power returned during the shutdown. It would be much better 
to call the UPS poweroff command as the very last thing with a 5-10 
second delay, just before the system halts, rather than having to 
specify a 5 minute delay for an initscript based solution. It's more of 
a "hook" based approach, which IMO is better for this.

/Thomas



From david at lovesunix.net  Wed Nov 14 12:33:58 2007
From: david at lovesunix.net (David Nielsen)
Date: Wed, 14 Nov 2007 13:33:58 +0100
Subject: qct review request, no response?
In-Reply-To: <fheo3b$8nv$1@ger.gmane.org>
References: <fheo3b$8nv$1@ger.gmane.org>
Message-ID: <1195043638.1725.3.camel@dawkins>


ons, 14 11 2007 kl. 07:01 -0500, skrev Neal Becker:
> I've seen no response to:
> https://bugzilla.redhat.com/show_bug.cgi?id=373621
> 
> Did I do something wrong, or is everyone busy?

Well we are short on reviewers, trading reviews normally works,
regardless I set the review request flag which you forgot.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/f59ff2de/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Nov 14 12:36:08 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 14 Nov 2007 21:36:08 +0900
Subject: qct review request, no response?
In-Reply-To: <fheo3b$8nv$1@ger.gmane.org>
References: <fheo3b$8nv$1@ger.gmane.org>
Message-ID: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>

Neal Becker wrote, at 11/14/2007 09:01 PM +9:00:
> I've seen no response to:
> https://bugzilla.redhat.com/show_bug.cgi?id=373621
> 
> Did I do something wrong, or is everyone busy?
> 

Please be patient. Currently there are about 270 review requests
which are not assigned to anybody.

Regards,
Mamoru



From lkundrak at redhat.com  Wed Nov 14 12:36:34 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 14 Nov 2007 13:36:34 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071113004637.GY4926@angus.ind.WPI.EDU>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
Message-ID: <1195043794.6884.6.camel@localhost.localdomain>

Hi,

On Mon, 2007-11-12 at 19:46 -0500, Chuck Anderson wrote:
> TFTP is often used to store firmware images and configuration files 
> for embedded devices, and as a place for such devices to write crash 
> dumps, log files, etc.
> 
> FHS 2.3 is silent on where to put files served up by TFTP.  Currently, 
> we set the TFTP root to /tftpboot.  This seems suboptimal for a few 
> reasons:
> 
> 1. The root directory might be read-only on the TFTP server, so it 
> isn't a good place to put the TFTP root.

Why? The images are usually also read only.

> 2. The root directory might be too small to store lots of log files, 
> huge crash dumps, etc.

Well, if you use it for crash dumps, there are bind mounts and links
still.

> 3. It really makes no sense to have a separate top-level directory for 
> the TFTP service.  /tftpboot is a legacy location that should be 
> reconsidered.

It does in case tftpd doesn't chroot.

> 4. tftp"boot" doesn't fit all use cases.  It isn't used exclusively 
> during booting of these devices.

And lib is not just for libraries, bin is not for binaries, but also for
executable scripts, initctl which is not a device resides in dev, and
etc doesn't keep what's left, but just the config files and startup
scripts.

I would be more happy if we kept /tftpboot. Loads of documentation
assumes it, people remember it that way. The benefits are too small to
outweight the loses.

On the other side I have no idea what does FHS say about it.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From pbrobinson at gmail.com  Wed Nov 14 12:37:23 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 14 Nov 2007 12:37:23 +0000
Subject: rawhide report: 20071114 changes
In-Reply-To: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
References: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
Message-ID: <5256d0b0711140437s7068ff94s7526d321b4b1617e@mail.gmail.com>

> xorg-x11-drv-i810-2.1.99-1.fc9
> ------------------------------
> * Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 2.1.99-1
> - xf86-video-intel 2.1.99.
> - Drop the i810 driver.  Time to move on.
> - Require xserver 1.4.99.1

With i810 driver gone.... time to rename it to xorg-x11-drv-intel too
to properly match the driver name?

> Broken deps for i386
> ----------------------------------------------------------
>         kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
>         kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE

Weren't kmod's suppose to be dropped for Fedora9?

Pete



From lkundrak at redhat.com  Wed Nov 14 12:38:58 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Wed, 14 Nov 2007 13:38:58 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <7874d9dd0711121956k28b78f64ld0d0a8530ff58858@mail.gmail.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<7874d9dd0711121956k28b78f64ld0d0a8530ff58858@mail.gmail.com>
Message-ID: <1195043938.6884.10.camel@localhost.localdomain>


On Mon, 2007-11-12 at 21:56 -0600, Michael Stahnke wrote:
> Just my opinion, but I think /srv/tftp makes sense.  /srv/* isn't
> owned by any rpm packages (that I know of) so just creating top-level
> directories should be ok.  I thought /srv was for serving out content.
>  I think tftp serves out content.   I know some people dislike /srv
> all-together, but it's seems like it's here, we should use it.

There was a thread about /srv here some time ago, find it -- I am lazy
to. IIRC the conclusion was to not let anything in distro touch /srv,
it's meant to be used only by user for his custom services.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From opensource at till.name  Wed Nov 14 12:58:44 2007
From: opensource at till.name (Till Maas)
Date: Wed, 14 Nov 2007 13:58:44 +0100
Subject: qct review request, no response?
In-Reply-To: <1195043638.1725.3.camel@dawkins>
References: <fheo3b$8nv$1@ger.gmane.org> <1195043638.1725.3.camel@dawkins>
Message-ID: <200711141358.57206.opensource@till.name>

On Mi November 14 2007, David Nielsen wrote:

> Well we are short on reviewers, trading reviews normally works,
> regardless I set the review request flag which you forgot.

The flag should only be changed by the reviewer, when you set it to "?" it 
means that you do the review of the package.

Regards,
Till

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/b2ca89da/attachment.sig>

From j.w.r.degoede at hhs.nl  Wed Nov 14 13:29:24 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 14:29:24 +0100
Subject: First experiences with new X
Message-ID: <473AF834.10409@hhs.nl>

Hi All,

Well at a first glance the new X works well on my work machine with integrated 
i810 graphics, however running OpenGL appps (not using compiz) results in a 
heavily flickering display, it looks like random black triangles are being 
displayed over the image, but that might be a completely wrong interpretation 
of what I'm seeing.

I've tried downgrading mesa-lib* to the F-8 release versions this does not help.

Regards,

Hans




From david at lovesunix.net  Wed Nov 14 13:35:10 2007
From: david at lovesunix.net (David Nielsen)
Date: Wed, 14 Nov 2007 14:35:10 +0100
Subject: qct review request, no response?
In-Reply-To: <200711141358.57206.opensource@till.name>
References: <fheo3b$8nv$1@ger.gmane.org> <1195043638.1725.3.camel@dawkins>
	<200711141358.57206.opensource@till.name>
Message-ID: <1195047311.1725.7.camel@dawkins>


ons, 14 11 2007 kl. 13:58 +0100, skrev Till Maas:
> On Mi November 14 2007, David Nielsen wrote:
> 
> > Well we are short on reviewers, trading reviews normally works,
> > regardless I set the review request flag which you forgot.
> 
> The flag should only be changed by the reviewer, when you set it to "?" it 
> means that you do the review of the package.
> 
> Regards,
> Till

Oh man, that was a bad thinko.. That'll teach me to interact with the
world before the morning coffee ritual. Many apologies.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/a33e165c/attachment.sig>

From jkeating at redhat.com  Wed Nov 14 13:41:52 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 08:41:52 -0500
Subject: Improving halt package interaction...
In-Reply-To: <fhepr3$fer$1@ger.gmane.org>
References: <fhdi4e$7on$1@ger.gmane.org>
	<20071114034410.GA19700@nostromo.devel.redhat.com>
	<fhepr3$fer$1@ger.gmane.org>
Message-ID: <20071114084152.15ce9c7b@redhat.com>

On Wed, 14 Nov 2007 09:31:29 -0300
Thomas M Steenholdt <tmus at tmus.dk> wrote:

> Other than what the other guys have mentioned, like perhaps making it 
> possible to run scripts after ro remounting "/", a delayed UPS
> poweroff from a normal initscript is less precise, since you have no
> reliable measure of how long the system will take to power down
> (perhaps you're running large databases?). You could end up powering
> off the UPS outlets before the system is ready for it. Or specifying
> a long delay, the system might need to wait for far too long for the
> system to restart, even though power returned during the shutdown. It
> would be much better to call the UPS poweroff command as the very
> last thing with a 5-10 second delay, just before the system halts,
> rather than having to specify a 5 minute delay for an initscript
> based solution. It's more of a "hook" based approach, which IMO is
> better for this.

Wouldn't you just make sure that the UPS shut down script is
scheduled /after/ the database shut down, and all other critical
services?  IE make it close to last in the shutdown schedule.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/47ec2694/attachment.sig>

From mitr at volny.cz  Wed Nov 14 13:55:42 2007
From: mitr at volny.cz (Miloslav Trmac)
Date: Wed, 14 Nov 2007 14:55:42 +0100
Subject: Improving halt package interaction...
In-Reply-To: <20071114084152.15ce9c7b@redhat.com>
References: <fhdi4e$7on$1@ger.gmane.org>	<20071114034410.GA19700@nostromo.devel.redhat.com>	<fhepr3$fer$1@ger.gmane.org>
	<20071114084152.15ce9c7b@redhat.com>
Message-ID: <473AFE5E.4070303@volny.cz>

Jesse Keating napsal(a):
> Wouldn't you just make sure that the UPS shut down script is
> scheduled /after/ the database shut down, and all other critical
> services?  IE make it close to last in the shutdown schedule.
Ideally, the system should be cleanly shut down (e.g. all file systems
unmounted) before shutting down the UPS.  Guessing how much time it will
take to unmount all file systems is non-trivial.
	Mirek



From stransky at redhat.com  Wed Nov 14 13:59:26 2007
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 14 Nov 2007 14:59:26 +0100
Subject: XULRunner in rawhide
Message-ID: <473AFF3E.1090904@redhat.com>

Hello,

there's a new package in rawhide, xulrunner
(xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
XUL application and run in by xulrunner.

So no more firefox-devel packages in rawhide, you should use
xulrunner-devel (gecko-libs == 1.9) now.

If you maintain any package what is built against gecko-libs (or
firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
pkg-config files are provided and you may add "--with-gecko=xulrunner"
directive to configure script.

As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is based
on the latest mozilla xulrunner trunk (a.k.a. Firefox 3 Alpha) so some
package may not compile with it (for instance epiphany) and we need to
fix all those errors before F9 GA...

Please contact me or Chris if you have any questions.

Ma.






From Christian.Iseli at licr.org  Wed Nov 14 14:08:49 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Wed, 14 Nov 2007 15:08:49 +0100
Subject: Fedora Package Status of Nov 14, 2007
Message-ID: <20071114150849.0192620a@ludwig-alpha.unil.ch>

Hi folks,

Now that F8 is out, it is high time I updated the PackageStatus page
again...

The thing that changed most is the high increase (+ 1000) of open bug
reports...  So I'd like to encourage any and all who feel some bug
zapping itch or urge to head to
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/OpenBugs
and do some triaging/fixing/closing as appropriate.

Cheers,
					Christian

====

Fedora Package Status of Nov 14, 2007

The full report can be found here:
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus


Owners stats:
 - 5216 packages
 - 8595 binary rpms in devel
 - 102 orphans
 - 53 packages not available in devel or release
    alexl at users dot sourceforge dot net     sqlite2
    andreas dot bierfert at lowlatency dot de  syncekonnector
    andreas at bawue dot net                   perl-HTML-CalendarMonthSimple
    bdpepple at gmail dot com                  galago-filesystem
    bdpepple at gmail dot com                  gaim-galago
    caolanm at redhat dot com                  hunspell-he
    cweyl at alumni dot drew dot edu           gaim-gaym
    davidz at redhat dot com                   gnome-device-manager
    davidz at redhat dot com                   redhat-artwork
    dbhole at redhat dot com                   dom2-core-tests
    dennis at ausil dot us                     silo
    devrim at commandprompt dot com            postgresql-pgpool-ha
    gauret at free dot fr                      qca-gnupg
    ivazqueznet at gmail dot com               purple-plugin_pack
    j dot w dot r dot degoede at hhs dot nl    cvsextras
    jafo at tummy dot com                      python-mechanoid
    jkeating at redhat dot com                 tux
    jmp at safe dot ca                         clement
    jorton at redhat dot com                   libc-client
    jorton at redhat dot com                   newt-perl
    kevin at tigcc dot ticalc dot org          kdegames3
    konradr at linux dot vnet dot ibm dot com  ibmasm
    kwizart at gmail dot com                   xorg-x11-drv-ivtv
    kwizart at gmail dot com                   ivtv-firmware
    matthias at rpmforge dot net               osslsigncode
    matthias at rpmforge dot net               gnome-themes-extras
    mmahut at redhat dot com                   smstools
    mtasaka at ioa dot s dot u-tokyo dot ac dot jp F-8
    noah at coderanger dot net                 rainbow
    noah at coderanger dot net                 python-olpcgames
    odvorace at redhat dot com                 odvorace
    odvorace at redhat dot com                 jbrassow
    oliver at linux-kernel dot at              aboot
    overholt at redhat dot com                 eclipse-nlspackager
    overholt at redhat dot com                 eclipse-sdk-nls
    paul at all-the-johnsons dot co dot uk     mysql-connector-net
    pertusus at free dot fr                    ivman
    pknirsch at redhat dot com                 freeimpi
    rdieter at math dot unl dot edu            pykdeextensions
    richard at hughsie dot com                 ohm
    rpm at greysector dot net                  libdvdnav
    ruben at rubenkerkhof dot com              csync2
    rvokal at redhat dot com                   gaim-guifications
    splinux25 at gmail dot com                 drapes
    sundaram at redhat dot com                 unrar
    tcallawa at redhat dot com                 ql23xx0-firmware
    than at redhat dot com                     kdelibs3
    tmraz at redhat dot com                    openssl097a
    twaugh at redhat dot com                   desktop-printing
    vivekl at redhat dot com                   saxon8
    vivekl at redhat dot com                   classpathx-jaxp
    wtogami at redhat dot com                  firefox-32
    yufanyufan at gmail dot com                audacious-plugins-docklet
 - 10 packages which have not yet been FE-ACCEPT'd...
   https://bugzilla.redhat.com/buglist.cgi?bug_id=222191,231861,372161
     eclipse                                  ben at bagu.org
     cyrus-imapd                              tjanouse at redhat.com
     gnome-themes-extras                      marc at mwiriadi.id.au
   https://bugzilla.redhat.com/buglist.cgi?bug_id=221717,224458,250040,250970,252049,374611,376421
     agg                                      caolanm at redhat.com
     libsilc                                  wtogami at redhat.com
     new                                      mike at flyn.org
     ivtv-firmware                            axel.thimm at atrpms.net
     asm2                                     vivekl at redhat.com
     pam_mysql                                i at stingr.net
     tla                                      debarshi.ray at gmail.com
 - 2 packages present in the development repo which have no owners entry
    audacious-docklet s390utils
 - 14 orphaned packages, yet available in devel
    cgi-util eclipse-egit gkrellm-weather libid3tag openct opensc pcsc-perl
    pcsc-tools redet redet-doc system-config-keyboard
    system-config-rootpassword tcl-thread windowlab

FE-ACCEPT packages stats:
 - 3496 accepted, closed package reviews
 - 45 accepted, closed package reviews not in repo
 - 14 accepted, closed package reviews not in owners
 - 69 accepted, open package reviews older than 4 weeks;
 - 51 accepted, open package reviews with a package already in the repo

FE-REVIEW packages stats:
 - 266 open tickets
 - 152 tickets with no activity in eight weeks
 - 30 tickets with no activity in four weeks
 - 29 closed tickets

FE-NEW packages stats:
 - 834 open tickets
 - 661 tickets with no activity in eight weeks
 - 53 tickets with no activity in four weeks

FE-NEEDSPONSOR packages stats:
 - 24 open tickets
 - 9 tickets with no activity in eight weeks
 - 3 tickets with no activity in four weeks

FE-Legal packages stats:
 - 5 open tickets
 - 2 tickets with no activity in eight weeks
 - 1 tickets with no activity in four weeks

OPEN-BUGS packages stats:
 - 9561 open tickets
 - 5740 tickets with no activity in eight weeks
 - 1105 tickets with no activity in four weeks

CVS stats:
 - 5220 packages with a devel directory
 - 3 packages with no owners entry
    glibc32 glibc64 tdma
 - 261 packages were dropped from Fedora

Maintainers stats:
 - 439 maintainers
 - 3 inactive maintainers with open bugs
 - 1 inactive maintainers

Dropped Fedora packages:
 - 79 packages were dropped since Fedora 7

Comps.xml files stats:
 -  2569 packages in comps-f9 file
 -  1210 packages missing from comps-f9 file
 -  6 packages in comps-f9 but not in repo
 -  2577 packages in comps-f8 file
 -  1183 packages missing from comps-f8 file
 -  6 packages in comps-f8 but not in repo



From alexl at users.sourceforge.net  Wed Nov 14 14:17:24 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 14 Nov 2007 07:17:24 -0700
Subject: XULRunner in rawhide
In-Reply-To: <473AFF3E.1090904@redhat.com> (Martin Stransky's message of "Wed\,
	14 Nov 2007 14\:59\:26 +0100")
References: <473AFF3E.1090904@redhat.com>
Message-ID: <kbmytg6he3.fsf@allele2.eebweb.arizona.edu>

>>>>> "MS" == Martin Stransky  writes:

MS> Hello, there's a new package in rawhide, xulrunner
MS> (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to
MS> provide gecko-libs instead of Firefox and the plan is to ship
MS> Firefox as a pure XUL application and run in by xulrunner.

MS> So no more firefox-devel packages in rawhide, you should use
MS> xulrunner-devel (gecko-libs == 1.9) now.

MS> If you maintain any package what is built against gecko-libs (or
MS> firefox-devel), please rebuild it with the xulrunner. The
MS> xulrunner-*.pc pkg-config files are provided and you may add
MS> "--with-gecko=xulrunner" directive to configure script.

MS> As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is
MS> based on the latest mozilla xulrunner trunk (a.k.a. Firefox 3
MS> Alpha) so some package may not compile with it (for instance
MS> epiphany) and we need to fix all those errors before F9 GA...

MS> Please contact me or Chris if you have any questions.

Martin,

I just tried rebuilding Miro against the new xulrunner (by bumping BR:
gecko-devel = 1.9), and I got the following build log.

http://koji.fedoraproject.org/koji/getfile?taskID=241345&name=build.log

relevant excerpt is:

Traceback (most recent call last):
  File "setup.py", line 244, in <module>
    "gtk+-2.0 glib-2.0 pygtk-2.0 %s %s" % (gtkmozembed, xpcom))
  File "setup.py", line 194, in parsePkgConfig
    output = getCommandOutput(commandLine).strip()
  File "setup.py", line 165, in getCommandOutput
    (cmd, stderr))
RuntimeError: pkg-config --cflags --libs gtk+-2.0 glib-2.0 pygtk-2.0
  xulrunner-gtkmozembed xulrunner-xpcom outputted the following error:
Package xulrunner-gtkmozembed was not found in the pkg-config search
  path.
Perhaps you should add the directory containing
  `xulrunner-gtkmozembed.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xulrunner-gtkmozembed' found

Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
package somehow?  Is there another BuildRequires I need to add?

Alex



From frank-buettner at gmx.net  Wed Nov 14 13:24:50 2007
From: frank-buettner at gmx.net (frank-buettner at gmx.net)
Date: Wed, 14 Nov 2007 14:24:50 +0100 (CET)
Subject: Package for Qt-Jambi?
In-Reply-To: <473A82FB.9030408@gmail.com>
References: <473A82FB.9030408@gmail.com>
Message-ID: <32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>

> Since there's currently a discussion going on around Java components due
> to IcedTea, I was wondering if anyone had considered packaging Qt-Jambi
> for Fedora.  There is a GPL version, after all, and an Eclipse plugin...
>
> http://trolltech.com/developer/downloads/qt
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
I have ask about it, for some weak's.
So I think nobody is working on it.
Because of less time I had to much to do, so I can't make this package and
you can do this.(When no other reports, that he is working on it)



From pertusus at free.fr  Wed Nov 14 14:26:40 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 15:26:40 +0100
Subject: setup filesystem requires and minimal system
Message-ID: <20071114142640.GB14241@free.fr>

Hello,

Looking at the dependency chains for basic packages lead me to ask some
basic questions.

Is it right for another package than basesystem to Requires setup or 
filesystem (except for versioned requires)?

What is the minimal fedora install? In my opinion basesystem, setup and 
filesystem are necessarily there. But what is necessary besides these 
3 packages? Currently basesystem is brought in by glibc which also bring
in libgcc. So it looks like glibc is also necessary. Is it really so?
And beside glibc, are the kernel, grub, sysvinit, coreutils, rpm, bash, 
pam, util-linux-ng mandatory? What else?

I guess that there is a comps group for base system (I checked, it is
the Core group), but one should not think along this comps group, but 
along a user who would want to do the minimal install (certainly in a 
chroot).

Has anybody done something similar?

--
Pat



From caillon at redhat.com  Wed Nov 14 14:30:16 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Nov 2007 15:30:16 +0100
Subject: XULRunner in rawhide
In-Reply-To: <473AFF3E.1090904@redhat.com>
References: <473AFF3E.1090904@redhat.com>
Message-ID: <473B0678.2040306@redhat.com>

Martin Stransky wrote:
> Hello,
> 
> there's a new package in rawhide, xulrunner
> (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
> gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
> XUL application and run in by xulrunner.
> 
> So no more firefox-devel packages in rawhide, you should use
> xulrunner-devel (gecko-libs == 1.9) now.
> 
> If you maintain any package what is built against gecko-libs (or
> firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
> pkg-config files are provided and you may add "--with-gecko=xulrunner"
> directive to configure script.

Actually, this is not going to work for many apps if it works at all. 
They would need some porting.  I haven't had time to write up some info 
on this yet, though.



From jdieter at gmail.com  Wed Nov 14 14:34:30 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Wed, 14 Nov 2007 16:34:30 +0200
Subject: Yum-presto SELinux bug
Message-ID: <1195050870.3103.6.camel@jndwidescreen.lesbg.loc>

I'm the developer and maintainer for yum-presto and I've been given a
bug in which yum-presto running on an F8 machine with SELinux enabled
doesn't work.  The bug is at
https://bugzilla.redhat.com/show_bug.cgi?id=375731 , and a .bz2
attachment with the error messages is at
https://bugzilla.redhat.com/attachment.cgi?id=255771 .

Basically, yum-presto uses deltarpm which uses prelink to verify that
binary files haven't changed.  It looks like SELinux doesn't want
prelink accessing sockets or rpm temp files.

So, I guess my question is, how do I fix it?

Thanks,
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/9b83bcb1/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Nov 14 14:40:09 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 14 Nov 2007 23:40:09 +0900
Subject: XULRunner in rawhide
In-Reply-To: <473AFF3E.1090904@redhat.com>
References: <473AFF3E.1090904@redhat.com>
Message-ID: <473B08C9.5090708@ioa.s.u-tokyo.ac.jp>

Hi,

Martin Stransky wrote, at 11/14/2007 10:59 PM +9:00:
> So no more firefox-devel packages in rawhide, you should use
> xulrunner-devel (gecko-libs == 1.9) now.
> 
> If you maintain any package what is built against gecko-libs (or
> firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
> pkg-config files are provided and you may add "--with-gecko=xulrunner"
> directive to configure script.
> 
> As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is based
> on the latest mozilla xulrunner trunk (a.k.a. Firefox 3 Alpha) so some
> package may not compile with it (for instance epiphany) and we need to
> fix all those errors before F9 GA...

I tried to rebuild kazehakase against xulrunner, however it failed
with complaint of many missing headers like:
----------------------------------------
In file included from kz-gecko-embed.cpp:37:
kz-mozwrapper.h:31:33: error: nsIDOMEventReceiver.h: No such file or directory
----------------------------------------
http://koji.fedoraproject.org/koji/taskinfo?taskID=241394

Are these header files supposed to be removed? If so I will
contact with upstream developer to look into latest xulrunner.

Regards,
Mamoru



From caillon at redhat.com  Wed Nov 14 14:47:35 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Nov 2007 15:47:35 +0100
Subject: XULRunner in rawhide
In-Reply-To: <473B08C9.5090708@ioa.s.u-tokyo.ac.jp>
References: <473AFF3E.1090904@redhat.com>
	<473B08C9.5090708@ioa.s.u-tokyo.ac.jp>
Message-ID: <473B0A87.3090200@redhat.com>

Mamoru Tasaka wrote:
> Hi,
> 
> Martin Stransky wrote, at 11/14/2007 10:59 PM +9:00:
>> So no more firefox-devel packages in rawhide, you should use
>> xulrunner-devel (gecko-libs == 1.9) now.
>>
>> If you maintain any package what is built against gecko-libs (or
>> firefox-devel), please rebuild it with the xulrunner. The xulrunner-*.pc
>> pkg-config files are provided and you may add "--with-gecko=xulrunner"
>> directive to configure script.
>>
>> As the name suggests, the xulrunner-1.9-0.alpha9.3.fc9 package is based
>> on the latest mozilla xulrunner trunk (a.k.a. Firefox 3 Alpha) so some
>> package may not compile with it (for instance epiphany) and we need to
>> fix all those errors before F9 GA...
> 
> I tried to rebuild kazehakase against xulrunner, however it failed
> with complaint of many missing headers like:
> ----------------------------------------
> In file included from kz-gecko-embed.cpp:37:
> kz-mozwrapper.h:31:33: error: nsIDOMEventReceiver.h: No such file or 
> directory
> ----------------------------------------
> http://koji.fedoraproject.org/koji/taskinfo?taskID=241394
> 
> Are these header files supposed to be removed? If so I will
> contact with upstream developer to look into latest xulrunner.

nsIDOMEvenReceiver was removed completely from upstream. 
https://bugzilla.mozilla.org/show_bug.cgi?id=363089

A good starting point to see if the header is still upstream is: 
http://lxr.mozilla.org/mozilla/find

Also, there will be some compilation failures due to incompatible 
changes that you may notice.



From wtogami at redhat.com  Wed Nov 14 14:48:50 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 14 Nov 2007 09:48:50 -0500
Subject: Yum-presto SELinux bug
In-Reply-To: <1195050870.3103.6.camel@jndwidescreen.lesbg.loc>
References: <1195050870.3103.6.camel@jndwidescreen.lesbg.loc>
Message-ID: <473B0AD2.9010004@redhat.com>

Jonathan Dieter wrote:
> I'm the developer and maintainer for yum-presto and I've been given a
> bug in which yum-presto running on an F8 machine with SELinux enabled
> doesn't work.  The bug is at
> https://bugzilla.redhat.com/show_bug.cgi?id=375731 , and a .bz2
> attachment with the error messages is at
> https://bugzilla.redhat.com/attachment.cgi?id=255771 .
> 
> Basically, yum-presto uses deltarpm which uses prelink to verify that
> binary files haven't changed.  It looks like SELinux doesn't want
> prelink accessing sockets or rpm temp files.
> 
> So, I guess my question is, how do I fix it?
> 

The bug above is not entirely SELinux correct?

Please file a separate bug against selinux-policy.  Dan Walsh will 
either fix up the selinux-policy or ask questions about it before doing so.

Warren Togami
wtogami at redhat.com



From tmus at tmus.dk  Wed Nov 14 14:53:24 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Wed, 14 Nov 2007 11:53:24 -0300
Subject: Improving halt package interaction...
In-Reply-To: <20071114084152.15ce9c7b@redhat.com>
References: <fhdi4e$7on$1@ger.gmane.org>	<20071114034410.GA19700@nostromo.devel.redhat.com>	<fhepr3$fer$1@ger.gmane.org>
	<20071114084152.15ce9c7b@redhat.com>
Message-ID: <fhf257$epq$1@ger.gmane.org>

Jesse Keating wrote:
> 
> Wouldn't you just make sure that the UPS shut down script is
> scheduled /after/ the database shut down, and all other critical
> services?  IE make it close to last in the shutdown schedule.
> 

It is really best to handle this as close to the actual halt as 
possible. This is the same reason why the NUT handling code has already 
been put in exactly that place in the current halt script - We just need 
to make it more generic and easier to "plug-in" package specific scripts.

Also, it seems from the feedback, that UPSes are not the only cases 
where this would prove useful. Perhaps you need to perform an operation 
after "/" has been remounted read-only, which would never be possible 
from a normal initscript.

/Thomas



From fedora at camperquake.de  Wed Nov 14 14:54:35 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 14 Nov 2007 15:54:35 +0100
Subject: rawhide report: 20071114 changes
In-Reply-To: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
References: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
Message-ID: <20071114155435.700e0f06@dhcp03.addix.net>

Hi.

On Wed, 14 Nov 2007 07:08:35 -0500, Build System wrote:

> New package catdoc
> 	A program which converts Microsoft office files to plain text

A general question regarding these reports: if the report is sent, does
that mean that the files are available (at least at d.fp.o), or just that
the buildsystem has finished building them?



From jkeating at redhat.com  Wed Nov 14 15:00:13 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 10:00:13 -0500
Subject: rawhide report: 20071114 changes
In-Reply-To: <20071114155435.700e0f06@dhcp03.addix.net>
References: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
	<20071114155435.700e0f06@dhcp03.addix.net>
Message-ID: <20071114100013.5cb19133@redhat.com>

On Wed, 14 Nov 2007 15:54:35 +0100
Ralf Ertzinger <fedora at camperquake.de> wrote:

> A general question regarding these reports: if the report is sent,
> does that mean that the files are available (at least at d.fp.o), or
> just that the buildsystem has finished building them?

It means that the bits are in flight to d.fp.o.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/53bb7888/attachment.sig>

From jkeating at redhat.com  Wed Nov 14 15:02:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 10:02:12 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <20071114142640.GB14241@free.fr>
References: <20071114142640.GB14241@free.fr>
Message-ID: <20071114100212.0a1f1ff1@redhat.com>

On Wed, 14 Nov 2007 15:26:40 +0100
Patrice Dumas <pertusus at free.fr> wrote:

> I guess that there is a comps group for base system (I checked, it is
> the Core group), but one should not think along this comps group, but 
> along a user who would want to do the minimal install (certainly in a 
> chroot).
> 
> Has anybody done something similar?

Why wouldn't you think comps group?  yum --install-root=/path/to/chroot
groupinstall 'Core'  

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/426a4edb/attachment.sig>

From j.w.r.degoede at hhs.nl  Wed Nov 14 15:05:41 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 16:05:41 +0100
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <20071114150849.0192620a@ludwig-alpha.unil.ch>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>
Message-ID: <473B0EC5.4010708@hhs.nl>

Christian Iseli wrote:
> Hi folks,
> 
> Now that F8 is out, it is high time I updated the PackageStatus page
> again...
> 

Hmm, Something is wrong:

Packages not present in the development repo:
---
j dot w dot r dot degoede at hhs dot nl    cvsextras    \
Library handling decoding of several popular sound file formats

cvsextras should be SDL_sound, as it correctly is in:
https://bugzilla.redhat.com/show_bug.cgi?id=355811

Regards,

Hans



From loupgaroublond at gmail.com  Wed Nov 14 15:07:52 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Wed, 14 Nov 2007 10:07:52 -0500
Subject: sending multiple (different) smolt profiles
In-Reply-To: <3170f42f0711140351s3c55e090k6623059371c6bf50@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
	<Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
	<64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>
	<1194958858.2025.19.camel@cutter>
	<64b14b300711140128n7ae30428lee0ed62e376240b6@mail.gmail.com>
	<3170f42f0711140351s3c55e090k6623059371c6bf50@mail.gmail.com>
Message-ID: <7f692fec0711140707y2f94dcb6h93218b51932df8ad@mail.gmail.com>

On Nov 14, 2007 6:51 AM, Debarshi 'Rishi' Ray <debarshi.ray at gmail.com> wrote:
> > Yesterday I couldn't send smolt profile, and I tried for over half an
> > hour... today I sent it without problem the first time.
>
> Same here.

Smolt's having server issues.  It unfortunately needs alot of TLC that
no one has the time for in the next few weeks.  Alot of it has to do
with the way it's run in a clustered environment, and we need to set
up a testing environment that simulates that.

Sorry for all the disappointment in smolt.  Maybe we just need a big
Under Construction sign.

Cheers,
Yaakov



From pertusus at free.fr  Wed Nov 14 15:09:23 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 16:09:23 +0100
Subject: setup filesystem requires and minimal system
In-Reply-To: <20071114100212.0a1f1ff1@redhat.com>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com>
Message-ID: <20071114150923.GD14241@free.fr>

On Wed, Nov 14, 2007 at 10:02:12AM -0500, Jesse Keating wrote:
> On Wed, 14 Nov 2007 15:26:40 +0100
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > I guess that there is a comps group for base system (I checked, it is
> > the Core group), but one should not think along this comps group, but 
> > along a user who would want to do the minimal install (certainly in a 
> > chroot).
> > 
> > Has anybody done something similar?
> 
> Why wouldn't you think comps group?  yum --install-root=/path/to/chroot
> groupinstall 'Core'  

Because I was asking about the really minimal package set. The idea is
to have an idea of what packages should be installed, whatever comps
groups are. Core is still a big package set. If you really want to stick
on comps, the question could be what would be most reduced comps group?
Would there even be glibc, sysvinit.... see my post in it?

--
Pat



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Nov 14 15:12:30 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 15 Nov 2007 00:12:30 +0900
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <473B0EC5.4010708@hhs.nl>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>
	<473B0EC5.4010708@hhs.nl>
Message-ID: <473B105E.8020904@ioa.s.u-tokyo.ac.jp>

Hans de Goede wrote, at 11/15/2007 12:05 AM +9:00:
> Christian Iseli wrote:
>> Hi folks,
>>
>> Now that F8 is out, it is high time I updated the PackageStatus page
>> again...
>>
> 
> Hmm, Something is wrong:
> 
> Packages not present in the development repo:
> ---
> j dot w dot r dot degoede at hhs dot nl    cvsextras    \
> Library handling decoding of several popular sound file formats
> 
> cvsextras should be SDL_sound, as it correctly is in:
> https://bugzilla.redhat.com/show_bug.cgi?id=355811

Also I have strange entry:

Packages not present in the development repo
--------------------------------------------
mtasaka at ioa dot s dot u-tokyo dot ac dot jp F-8 \
A Fast, Enjoyable HTML Parser for Ruby

cvs admin, would you check what is happening?
c.f.
https://bugzilla.redhat.com/show_bug.cgi?id=377631

Regards,
Mamoru




From tcallawa at redhat.com  Wed Nov 14 15:14:41 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 14 Nov 2007 10:14:41 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <20071114150923.GD14241@free.fr>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com> <20071114150923.GD14241@free.fr>
Message-ID: <1195053281.3871.1.camel@localhost.localdomain>


On Wed, 2007-11-14 at 16:09 +0100, Patrice Dumas wrote:
> On Wed, Nov 14, 2007 at 10:02:12AM -0500, Jesse Keating wrote:
> > On Wed, 14 Nov 2007 15:26:40 +0100
> > Patrice Dumas <pertusus at free.fr> wrote:
> > 
> > > I guess that there is a comps group for base system (I checked, it is
> > > the Core group), but one should not think along this comps group, but 
> > > along a user who would want to do the minimal install (certainly in a 
> > > chroot).
> > > 
> > > Has anybody done something similar?
> > 
> > Why wouldn't you think comps group?  yum --install-root=/path/to/chroot
> > groupinstall 'Core'  
> 
> Because I was asking about the really minimal package set. The idea is
> to have an idea of what packages should be installed, whatever comps
> groups are. Core is still a big package set. If you really want to stick
> on comps, the question could be what would be most reduced comps group?
> Would there even be glibc, sysvinit.... see my post in it?

You'd need a libc, some sort of init. It should be rather
straightforward, testing in a chroot, to figure out the smallest set of
Fedora packages that you can have and be functional (say, define
functional as a working network, text editor, and shell).

You can call it 'Masochist'. ;)

~spot



From katzj at redhat.com  Wed Nov 14 15:24:28 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 14 Nov 2007 10:24:28 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <1195053281.3871.1.camel@localhost.localdomain>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com> <20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
Message-ID: <1195053868.17950.72.camel@localhost.localdomain>

On Wed, 2007-11-14 at 10:14 -0500, Tom "spot" Callaway wrote:
> On Wed, 2007-11-14 at 16:09 +0100, Patrice Dumas wrote:
> > On Wed, Nov 14, 2007 at 10:02:12AM -0500, Jesse Keating wrote:
> > > On Wed, 14 Nov 2007 15:26:40 +0100
> > > Patrice Dumas <pertusus at free.fr> wrote:
> > > 
> > > > I guess that there is a comps group for base system (I checked, it is
> > > > the Core group), but one should not think along this comps group, but 
> > > > along a user who would want to do the minimal install (certainly in a 
> > > > chroot).
> > > > 
> > > > Has anybody done something similar?
> > > 
> > > Why wouldn't you think comps group?  yum --install-root=/path/to/chroot
> > > groupinstall 'Core'  
> > 
> > Because I was asking about the really minimal package set. The idea is
> > to have an idea of what packages should be installed, whatever comps
> > groups are. Core is still a big package set. If you really want to stick
> > on comps, the question could be what would be most reduced comps group?
> > Would there even be glibc, sysvinit.... see my post in it?
> 
> You'd need a libc, some sort of init. It should be rather
> straightforward, testing in a chroot, to figure out the smallest set of
> Fedora packages that you can have and be functional (say, define
> functional as a working network, text editor, and shell).
> 
> You can call it 'Masochist'. ;)

That's what the core group in comps is intended to be...  if there's
more there than that, it should be moved to Base :)

Jeremy



From pertusus at free.fr  Wed Nov 14 15:29:57 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 16:29:57 +0100
Subject: setup filesystem requires and minimal system
In-Reply-To: <1195053281.3871.1.camel@localhost.localdomain>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com>
	<20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
Message-ID: <20071114152957.GE14241@free.fr>

On Wed, Nov 14, 2007 at 10:14:41AM -0500, Tom spot Callaway wrote:
> 
> You'd need a libc, some sort of init. It should be rather
> straightforward, testing in a chroot, to figure out the smallest set of
> Fedora packages that you can have and be functional (say, define
> functional as a working network, text editor, and shell).

A text editor is certainly not needed for te Masochistic install. For
the shell it is not evident either. init could start something directly.
As for init I don't know either, isn't it possible for the kernel to
launch something else than init? Is it clearer like that?

--
Pat



From tcallawa at redhat.com  Wed Nov 14 15:28:06 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 14 Nov 2007 10:28:06 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <1195053868.17950.72.camel@localhost.localdomain>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com> <20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<1195053868.17950.72.camel@localhost.localdomain>
Message-ID: <1195054086.3871.7.camel@localhost.localdomain>


On Wed, 2007-11-14 at 10:24 -0500, Jeremy Katz wrote:

> That's what the core group in comps is intended to be...  if there's
> more there than that, it should be moved to Base :)

To be fair, I think he's talking about something that only has:

tinylibc
minit
nash

... or equally absurd replacements.

~spot



From tcallawa at redhat.com  Wed Nov 14 15:29:26 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 14 Nov 2007 10:29:26 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <20071114152957.GE14241@free.fr>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com> <20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<20071114152957.GE14241@free.fr>
Message-ID: <1195054166.3871.9.camel@localhost.localdomain>


On Wed, 2007-11-14 at 16:29 +0100, Patrice Dumas wrote:
> On Wed, Nov 14, 2007 at 10:14:41AM -0500, Tom spot Callaway wrote:
> > 
> > You'd need a libc, some sort of init. It should be rather
> > straightforward, testing in a chroot, to figure out the smallest set of
> > Fedora packages that you can have and be functional (say, define
> > functional as a working network, text editor, and shell).
> 
> A text editor is certainly not needed for te Masochistic install. For
> the shell it is not evident either. init could start something directly.
> As for init I don't know either, isn't it possible for the kernel to
> launch something else than init? Is it clearer like that?

For clarity, just assume that "init" is "whatever the kernel launches".

Not necessarily that I endorse that sort of crackrock, but I understand
what you're shooting for.

~spot



From pertusus at free.fr  Wed Nov 14 15:37:17 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 16:37:17 +0100
Subject: setup filesystem requires and minimal system
In-Reply-To: <1195054086.3871.7.camel@localhost.localdomain>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com>
	<20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<1195053868.17950.72.camel@localhost.localdomain>
	<1195054086.3871.7.camel@localhost.localdomain>
Message-ID: <20071114153717.GF14241@free.fr>

On Wed, Nov 14, 2007 at 10:28:06AM -0500, Tom spot Callaway wrote:
> 
> On Wed, 2007-11-14 at 10:24 -0500, Jeremy Katz wrote:
> 
> > That's what the core group in comps is intended to be...  if there's
> > more there than that, it should be moved to Base :)
> 
> To be fair, I think he's talking about something that only has:
> 
> tinylibc
> minit
> nash
> 
> ... or equally absurd replacements.

Not exactly. I am more interested in a dep chain that allows those who
really want minimal installs (or maybe installs with 'absurd replacements'
but it isn't something I was thinking about when doing my first mail)
to work, while still ensuring that everything that is needed is still
there. More fundamentaly it is not clear to me whether some packages
that are special, for example the kernel, glibc, util-linux, rpm... itself
are necessary or not. I don't have personnally a need for such a 
minimal fedora based install, but I ask because other may like to have 
it.

--
Pat



From tcallawa at redhat.com  Wed Nov 14 15:40:29 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 14 Nov 2007 10:40:29 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <20071114153717.GF14241@free.fr>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com> <20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<1195053868.17950.72.camel@localhost.localdomain>
	<1195054086.3871.7.camel@localhost.localdomain>
	<20071114153717.GF14241@free.fr>
Message-ID: <1195054829.3871.13.camel@localhost.localdomain>


On Wed, 2007-11-14 at 16:37 +0100, Patrice Dumas wrote:
> More fundamentaly it is not clear to me whether some packages
> that are special, for example the kernel, glibc, util-linux, rpm... itself
> are necessary or not. I don't have personnally a need for such a 
> minimal fedora based install, but I ask because other may like to have 
> it.

So, yes. You need a linux kernel to boot. You need something which
provides libc. If you want it to be Fedora, it needs to have rpm.
util-linux (or its equivalent functionality) is necessary if you want
expected UNIX functionality (like kill, mount, etc).

~spot



From michel.sylvan at gmail.com  Wed Nov 14 15:45:00 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Wed, 14 Nov 2007 10:45:00 -0500
Subject: bodhi-client
In-Reply-To: <20071113044952.GV11043@crow.myhome.westell.com>
References: <20071113044952.GV11043@crow.myhome.westell.com>
Message-ID: <f224c6140711140745j1b5549ddsc284da314aa964dd@mail.gmail.com>

On 12/11/2007, Luke Macken <lmacken at redhat.com> wrote:
> The bodhi-client package should be making its way to an updates-testing
> repository near you! (and a newer version is already queued up for tomorrow).
> Not only does this command-line tool give you easier access to bodhi, but also
> provides some new features to help people get more involved with testing
> updates and providing useful feedback.
>
Neat! I get this with both bodhi --candidates and bodhi --testable, though:

  File "/usr/bin/bodhi", line 81, in __koji_session
    config.readfp(open(join(expanduser('~'), '.koji', 'config')))
IOError: [Errno 2] No such file or directory: '/home/michel/.koji/config

This is on an F-8 clean install, that I have used Koji on, and the
backup of my previous install does not have ~/.koji either.


-- 
Michel Salim
http://hircus.jaiku.com/



From pertusus at free.fr  Wed Nov 14 15:49:43 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 16:49:43 +0100
Subject: setup filesystem requires and minimal system
In-Reply-To: <1195054829.3871.13.camel@localhost.localdomain>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com>
	<20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<1195053868.17950.72.camel@localhost.localdomain>
	<1195054086.3871.7.camel@localhost.localdomain>
	<20071114153717.GF14241@free.fr>
	<1195054829.3871.13.camel@localhost.localdomain>
Message-ID: <20071114154943.GH14241@free.fr>

On Wed, Nov 14, 2007 at 10:40:29AM -0500, Tom spot Callaway wrote:
> 
> On Wed, 2007-11-14 at 16:37 +0100, Patrice Dumas wrote:
> > More fundamentaly it is not clear to me whether some packages
> > that are special, for example the kernel, glibc, util-linux, rpm... itself
> > are necessary or not. I don't have personnally a need for such a 
> > minimal fedora based install, but I ask because other may like to have 
> > it.
> 
> So, yes. You need a linux kernel to boot. You need something which
> provides libc. If you want it to be Fedora, it needs to have rpm.
> util-linux (or its equivalent functionality) is necessary if you want
> expected UNIX functionality (like kill, mount, etc).

Maybe I should have asked first that basic question, but is it
meaningful to have a fedora install that is not meant to be booted, but
maybe in a chroot? If it is to be booted, I have a fairly good idea on
what could be needed among the regular packages (sysvinit as init, bash
as a shell, initiscripts as an init system and so on and so forth) and I
guess that the Core comps group is about that. Now something that get
booted but uses 'absurd replacements' is another issue, but it is not an
issue that bothers me today (it may on another day, though ;-).

--
Pat



From halfline at gmail.com  Wed Nov 14 15:51:31 2007
From: halfline at gmail.com (Ray Strode)
Date: Wed, 14 Nov 2007 10:51:31 -0500
Subject: big changes going into F-9
In-Reply-To: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com>
References: <45abe7d80710221318j126ff60dk46720d4a47c73b8f@mail.gmail.com>
Message-ID: <45abe7d80711140751g164dc4atae20d0d34df6f2ae@mail.gmail.com>

Hi,

I just wanted to give people another heads up that the new, unfinished
gdm is in rawhide now.  I've had a number of people ask about the
regressions.  We're working to get parity with gdm 2.20 that shipped
in F-8, but there's still a lot to do, so it will be some time before
things are fully functional.

Those not wanting to see the sausage being made, may want to stick
with the F-8 gdm until later in the development cycle.

--Ray

On Oct 22, 2007 3:18 PM, Ray Strode <halfline at gmail.com> wrote:
> Hi guys,
>
> I'm going to be building a new, unfinished gdm into the devel branch
> today.  It's going to be very different than the gdm we are shipping
> now and will need quite a bit of development before it's ready for
> F-9.
>
> It won't hit rawhide until rawhide switches over to F-9.
>
> Details about it can be found here:
>
> http://live.gnome.org/GDM/NewDesign
>
> As part, of the build process I need to upgrade dbus-glib to 0.74.
> This will require a number of package rebuilds.
>
> Anyway, just wanted to give everyone a heads up.
>
> --Ray
>



From jkeating at redhat.com  Wed Nov 14 15:58:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 10:58:24 -0500
Subject: setup filesystem requires and minimal system
In-Reply-To: <20071114154943.GH14241@free.fr>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com>
	<20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<1195053868.17950.72.camel@localhost.localdomain>
	<1195054086.3871.7.camel@localhost.localdomain>
	<20071114153717.GF14241@free.fr>
	<1195054829.3871.13.camel@localhost.localdomain>
	<20071114154943.GH14241@free.fr>
Message-ID: <20071114105824.3953cc9b@redhat.com>

On Wed, 14 Nov 2007 16:49:43 +0100
Patrice Dumas <pertusus at free.fr> wrote:

> Maybe I should have asked first that basic question, but is it
> meaningful to have a fedora install that is not meant to be booted,
> but maybe in a chroot? If it is to be booted, I have a fairly good
> idea on what could be needed among the regular packages (sysvinit as
> init, bash as a shell, initiscripts as an init system and so on and
> so forth) and I guess that the Core comps group is about that. Now
> something that get booted but uses 'absurd replacements' is another
> issue, but it is not an issue that bothers me today (it may on
> another day, though ;-).

You'll notice that kernel isn't in the core group.  Kernel is something
that gets decided upon during install, so if you're just doing a chroot
install, no kernel.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/ebb214f5/attachment.sig>

From fedora-gmane.00005 at genesis-x.nildram.co.uk  Wed Nov 14 15:51:26 2007
From: fedora-gmane.00005 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner)
Date: Wed, 14 Nov 2007 15:51:26 +0000
Subject: fedora.com, is this for real?
In-Reply-To: <alpine.LFD.0.9999.0711131050510.13802@localhost.localdomain>
References: <fhatr5$6t6$1@ger.gmane.org>	<20071113133214.GD16446@devserv.devel.redhat.com>
	<alpine.LFD.0.9999.0711131050510.13802@localhost.localdomain>
Message-ID: <v4ir05-9vl.ln1@sky.matrix>

Verily I say unto thee, that Max Spevack spake thusly:
> On Tue, 13 Nov 2007, Alan Cox wrote:

>> Possibly a good chance to obtain the domain either nicely or 
>> because its now apparently misusing our marks (Fedora Linux etc) in
>> the content.
> 
> I have asked the folks within Red Hat who handle all the domain stuff
> to look into what it would take to get Fedora.com
> 
> If there is anything interesting to report back, I will!

fedora.com -> information.com -> oversee.net:

Admin Contact
------------------------------------------------------------
Name:                        Host Master
Organization:                Oversee.net
Email:                       hostmaster at oversee.net
Address:                     515 S. Flower Street, Suite 4400
City, Province, Post Code:   Los Angeles, California, 90071
Country:                     US
Phone:                       213-408-0080
Registration provider        nameking.com
Email:                       registry-admin at nameking.com
Address:                     2202 S. Figueroa St. Suite 721
City, Province, Post Code:   Los Angeles, California, 90007
Country:                     US
Phone:                       213-220-5715

There's evidence to suggest that Oversee.net is merely a shell company
for Name King, who does the domain kiting and parking on their behalf:

http://spamlinks.net/blog/archives/2006/09/chesterton_hold.html

2202 S. Figueroa St. Suite 721 is actually "The UPS Store", so you won't
find anyone there worth talking to ( http://www.theupsstore.com ).

OTOH 515 S. Flower Street is a real address, which is an office complex;
home to quite a few lawyers, building contractors, and (ironically) the
Los Angeles Police Foundation:

http://www.lapolicefoundation.org/about.html

Name King's registered headquarters is (not coincidentally):

700 S. Flower Street
Suite 1100
Los Angeles, CA 90017

http://kepler.ss.ca.gov/corpdata/ShowAllList?QueryCorpNumber=C2684545

Oversee.net's CEO is Lawrence Ng:

http://www.oversee.net/management.php

That's probably who Red Hat's lawyers should talk to.



From dwalsh at redhat.com  Wed Nov 14 16:08:14 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 14 Nov 2007 11:08:14 -0500
Subject: SELinux Troubleshooter messages from upgrade from F7->F8
In-Reply-To: <3e4ec4600711120616g4e38805dw99b65718184bd38c@mail.gmail.com>
References: <3e4ec4600711101123n3ca28c9va454a2566f089bb8@mail.gmail.com>	<3e4ec4600711120353x6025c92fx462c2ffc8107f0b7@mail.gmail.com>	<4738491D.1040903@warmcat.com>
	<3e4ec4600711120616g4e38805dw99b65718184bd38c@mail.gmail.com>
Message-ID: <473B1D6E.4080701@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Wiktowy wrote:
> On Nov 12, 2007 7:37 AM, Andy Green <andy at warmcat.com> wrote:
>> Somebody in the thread at some point said:
>>> Nov  9 02:39:19 localhost setroubleshoot:      SELinux is preventing
>>> /sbin/ldconfig (ldconfig_t) "write" to ldconfig (var_t).      For
>>> complete SELinux messages. run sealert -l
>>> 1594b6a8-1f16-44c9-b7ee-f5ef4621257f
>> I think this is a mislabelled /var/cache/ldconfig.  Check if yours is
>> like this
>>
>> # ll /var/cache/ldconfig -Zd
>> drwx------  root root system_u:object_r:ldconfig_cache_t /var/cache/ldconfig
>>
> 
> It matches this ... now ... I did not check right after the upgrade
> though. The selinux-policy package have been updated since then so it
> is possible that this could have been corrected already.
> 
> ...
> 
>>> Nov  9 03:09:42 localhost setroubleshoot: [rpc.ERROR] exception
>>> DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect
>>> to socket /var/run/dbus/system_bus_socket: Connection refused
>> Is dbus running?
>>
>> service messagebus status
> 
> dbus is running. I suspect that it had issues coming back up after
> getting updated as there were a lot of system_bus_socket: Connection
> refused messages scattered throughout the upgrade and they started
> shortly after dbus was updated. Now my /var/log/messages is pretty
> quiet so I think dbus is happy after the post-upgrade reboot.
> 
> Thank you for your comments.
> 
> /Mike
> 
I think that upgrade was happening out of order.  For example if
ldconfig upgraded before selinux policy, then you would see failures
like you saw above.  When the selinux policy package upgraded, it would
clean up the labeling.

I guess it would be advisable to upgrade selinux-policy before doing a
generate yum upgrade.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHOx1urlYvE4MpobMRAq2AAKDC6huSETdo1jcroiYYXci0lJnsuwCffM0/
d0E52Wb2DYmLk24t/TVG3zQ=
=fx7+
-----END PGP SIGNATURE-----



From cra at WPI.EDU  Wed Nov 14 16:14:22 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 14 Nov 2007 11:14:22 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195043794.6884.6.camel@localhost.localdomain>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<1195043794.6884.6.camel@localhost.localdomain>
Message-ID: <20071114161422.GA3423@angus.ind.WPI.EDU>

On Wed, Nov 14, 2007 at 01:36:34PM +0100, Lubomir Kundrak wrote:
> > 1. The root directory might be read-only on the TFTP server, so it 
> > isn't a good place to put the TFTP root.
> 
> Why? The images are usually also read only.

Not really.  Most of my tftp directory contains read-write log files. 
Even if you do keep only images there, you wouldn't want to have to 
remount / read-write (if even possible) just to update an image for 
booting a different host.

> > 2. The root directory might be too small to store lots of log files, 
> > huge crash dumps, etc.
> 
> Well, if you use it for crash dumps, there are bind mounts and links
> still.

So we should hack around deficiencies instead of fixing it properly?  
TFTP is usually used in situations where the client device is very 
dumb.  In many cases, it cannot support configuring complete file 
paths and must store files in the TFTP root.  So, you cannot use bind 
mounts to work around it.  If tftpd chroots to its configured root 
directory, you cannot use symlinks that point outside of this root.  
Unless you have a UnionFS, you would be stuck.

> > 3. It really makes no sense to have a separate top-level directory for 
> > the TFTP service.  /tftpboot is a legacy location that should be 
> > reconsidered.
> 
> It does in case tftpd doesn't chroot.

Who would actually not chroot their TFTP daemon?

> I would be more happy if we kept /tftpboot. Loads of documentation
> assumes it, people remember it that way. The benefits are too small to
> outweight the loses.

Fedora isn't about keeping status quo "Just Because".  It is about 
innovation and constant improvement, sometimes to the detriment of 
legacy traditions. Tradition alone isn't a valid excuse for preventing 
innovation.



From stransky at redhat.com  Wed Nov 14 16:13:42 2007
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 14 Nov 2007 17:13:42 +0100
Subject: XULRunner in rawhide
In-Reply-To: <kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
References: <473AFF3E.1090904@redhat.com>
	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
Message-ID: <473B1EB6.7010003@redhat.com>

Alex Lancaster wrote:
> Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
> package somehow?  Is there another BuildRequires I need to add?
> 
> Alex

gtkmozembed is not shipped by xulrunner, we need to check what's going on...



From mdehaan at redhat.com  Wed Nov 14 16:28:37 2007
From: mdehaan at redhat.com (Michael DeHaan)
Date: Wed, 14 Nov 2007 11:28:37 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <47391DEF.7060508@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>	<20071113010910.GC2651@free.fr>
	<47391DEF.7060508@redhat.com>
Message-ID: <473B2235.8020708@redhat.com>

Warren Togami wrote:
> Patrice Dumas wrote:
>> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
>>> For many years, I've used /var/tftp as a location for storing TFTP 
>>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
>>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
>>> reflect this.
>>
>> FHS says:
>>
>> Applications must generally not add directories to the top level of
>> /var. Such directories should only be added if they have some
>> system-wide implication, and in consultation with the FHS mailing list.
>>
>> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
>> for what should be in /var/lib, but it is not clearly wrong either.
>>
>> -- 
>> Pat
>>
>
> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as 
> well?

Please, please, don't change this.

Pretty much everyone everywhere is using /tftpboot, which makes apps 
needing to mange those directories now understand
that newer versions of Fedora are "weird".

I can't see any good reason to change this that results in any sort of 
tangible benefit.



From skvidal at fedoraproject.org  Wed Nov 14 16:27:55 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Nov 2007 11:27:55 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <473B2235.8020708@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473B2235.8020708@redhat.com>
Message-ID: <1195057675.23955.68.camel@cutter>


On Wed, 2007-11-14 at 11:28 -0500, Michael DeHaan wrote:
> Warren Togami wrote:
> > Patrice Dumas wrote:
> >> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
> >>> For many years, I've used /var/tftp as a location for storing TFTP 
> >>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
> >>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
> >>> reflect this.
> >>
> >> FHS says:
> >>
> >> Applications must generally not add directories to the top level of
> >> /var. Such directories should only be added if they have some
> >> system-wide implication, and in consultation with the FHS mailing list.
> >>
> >> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
> >> for what should be in /var/lib, but it is not clearly wrong either.
> >>
> >> -- 
> >> Pat
> >>
> >
> > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as 
> > well?
> 
> Please, please, don't change this.
> 
> Pretty much everyone everywhere is using /tftpboot, which makes apps 
> needing to mange those directories now understand
> that newer versions of Fedora are "weird".
> 
> I can't see any good reason to change this that results in any sort of 
> tangible benefit.

fhs compliance :)

-sv




From tibbs at math.uh.edu  Wed Nov 14 16:35:12 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 14 Nov 2007 10:35:12 -0600
Subject: qct review request, no response?
In-Reply-To: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
Message-ID: <ufay7d0hjjz.fsf@epithumia.math.uh.edu>

>>>>> "MT" == Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> writes:

MT> Please be patient. Currently there are about 270 review requests
MT> which are not assigned to anybody.

More like 830 if you count the merge reviews (which you should since
they're competing for reviewer time too).

It's taken a herculean effort just to get the number down that far,
but if the people who are submitting the packages don't do some
reviews themselves, or we don't magically acquire several more review
nuts then it's just going to be a long wait for every package in the
queue.

The list of all pending reviews:
http://fedoraproject.org/PackageReviewStatus/NEW.html

 - J<



From berrange at redhat.com  Wed Nov 14 16:35:33 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 14 Nov 2007 16:35:33 +0000
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195057675.23955.68.camel@cutter>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473B2235.8020708@redhat.com> <1195057675.23955.68.camel@cutter>
Message-ID: <20071114163533.GG29823@redhat.com>

On Wed, Nov 14, 2007 at 11:27:55AM -0500, seth vidal wrote:
> 
> On Wed, 2007-11-14 at 11:28 -0500, Michael DeHaan wrote:
> > Warren Togami wrote:
> > > Patrice Dumas wrote:
> > >> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
> > >>> For many years, I've used /var/tftp as a location for storing TFTP 
> > >>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
> > >>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
> > >>> reflect this.
> > >>
> > >> FHS says:
> > >>
> > >> Applications must generally not add directories to the top level of
> > >> /var. Such directories should only be added if they have some
> > >> system-wide implication, and in consultation with the FHS mailing list.
> > >>
> > >> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
> > >> for what should be in /var/lib, but it is not clearly wrong either.
> > >>
> > >> -- 
> > >> Pat
> > >>
> > >
> > > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as 
> > > well?
> > 
> > Please, please, don't change this.
> > 
> > Pretty much everyone everywhere is using /tftpboot, which makes apps 
> > needing to mange those directories now understand
> > that newer versions of Fedora are "weird".
> > 
> > I can't see any good reason to change this that results in any sort of 
> > tangible benefit.
> 
> fhs compliance :)

And how about reasons which have tangible benefit. fhs is a merely a tick
box

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From mdehaan at redhat.com  Wed Nov 14 16:36:15 2007
From: mdehaan at redhat.com (Michael DeHaan)
Date: Wed, 14 Nov 2007 11:36:15 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195057675.23955.68.camel@cutter>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>	<20071113010910.GC2651@free.fr>
	<47391DEF.7060508@redhat.com>	<473B2235.8020708@redhat.com>
	<1195057675.23955.68.camel@cutter>
Message-ID: <473B23FF.4060003@redhat.com>

seth vidal wrote:
> On Wed, 2007-11-14 at 11:28 -0500, Michael DeHaan wrote:
>   
>> Warren Togami wrote:
>>     
>>> Patrice Dumas wrote:
>>>       
>>>> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
>>>>         
>>>>> For many years, I've used /var/tftp as a location for storing TFTP 
>>>>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
>>>>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
>>>>> reflect this.
>>>>>           
>>>> FHS says:
>>>>
>>>> Applications must generally not add directories to the top level of
>>>> /var. Such directories should only be added if they have some
>>>> system-wide implication, and in consultation with the FHS mailing list.
>>>>
>>>> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
>>>> for what should be in /var/lib, but it is not clearly wrong either.
>>>>
>>>> -- 
>>>> Pat
>>>>
>>>>         
>>> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as 
>>> well?
>>>       
>> Please, please, don't change this.
>>
>> Pretty much everyone everywhere is using /tftpboot, which makes apps 
>> needing to mange those directories now understand
>> that newer versions of Fedora are "weird".
>>
>> I can't see any good reason to change this that results in any sort of 
>> tangible benefit.
>>     
>
> fhs compliance :)
>
> -sv
>
>
>   
I said tangible :)  

I'm agreed with Alan here.

Things like Cobbler can adapt easily, but we'll blindside lots of 
people, break a lot of management apps, and not really achieve anything 
useful by doing it.

--Michael







From lmacken at redhat.com  Wed Nov 14 16:38:02 2007
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 14 Nov 2007 11:38:02 -0500
Subject: bodhi-client
In-Reply-To: <f224c6140711140745j1b5549ddsc284da314aa964dd@mail.gmail.com>
References: <20071113044952.GV11043@crow.myhome.westell.com>
	<f224c6140711140745j1b5549ddsc284da314aa964dd@mail.gmail.com>
Message-ID: <20071114163801.GC32058@crow.myhome.westell.com>

On Wed, Nov 14, 2007 at 10:45:00AM -0500, Michel Salim wrote:
> On 12/11/2007, Luke Macken <lmacken at redhat.com> wrote:
> > The bodhi-client package should be making its way to an updates-testing
> > repository near you! (and a newer version is already queued up for tomorrow).
> > Not only does this command-line tool give you easier access to bodhi, but also
> > provides some new features to help people get more involved with testing
> > updates and providing useful feedback.
> >
> Neat! I get this with both bodhi --candidates and bodhi --testable, though:
> 
>   File "/usr/bin/bodhi", line 81, in __koji_session
>     config.readfp(open(join(expanduser('~'), '.koji', 'config')))
> IOError: [Errno 2] No such file or directory: '/home/michel/.koji/config
> 
> This is on an F-8 clean install, that I have used Koji on, and the
> backup of my previous install does not have ~/.koji either.

Running /usr/bin/fedora-packager-setup.sh should create it for you.
Thanks for the heads up though, I'll make sure the client checks for
this.

luke



From skvidal at fedoraproject.org  Wed Nov 14 16:35:05 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Nov 2007 11:35:05 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <473B23FF.4060003@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473B2235.8020708@redhat.com> <1195057675.23955.68.camel@cutter>
	<473B23FF.4060003@redhat.com>
Message-ID: <1195058105.23955.70.camel@cutter>


On Wed, 2007-11-14 at 11:36 -0500, Michael DeHaan wrote:
> seth vidal wrote:
> > On Wed, 2007-11-14 at 11:28 -0500, Michael DeHaan wrote:
> >   
> >> Warren Togami wrote:
> >>     
> >>> Patrice Dumas wrote:
> >>>       
> >>>> On Mon, Nov 12, 2007 at 07:46:37PM -0500, Chuck Anderson wrote:
> >>>>         
> >>>>> For many years, I've used /var/tftp as a location for storing TFTP 
> >>>>> data.  This mirrors the use of /var/ftp and /var/www.  I therefore 
> >>>>> suggest we change the default configuration in /etc/xinetd.d/tftp to 
> >>>>> reflect this.
> >>>>>           
> >>>> FHS says:
> >>>>
> >>>> Applications must generally not add directories to the top level of
> >>>> /var. Such directories should only be added if they have some
> >>>> system-wide implication, and in consultation with the FHS mailing list.
> >>>>
> >>>> Another possibility could be /var/lib/tftp. tftp doesn't exactly qualify
> >>>> for what should be in /var/lib, but it is not clearly wrong either.
> >>>>
> >>>> -- 
> >>>> Pat
> >>>>
> >>>>         
> >>> Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as 
> >>> well?
> >>>       
> >> Please, please, don't change this.
> >>
> >> Pretty much everyone everywhere is using /tftpboot, which makes apps 
> >> needing to mange those directories now understand
> >> that newer versions of Fedora are "weird".
> >>
> >> I can't see any good reason to change this that results in any sort of 
> >> tangible benefit.
> >>     
> >
> > fhs compliance :)
> >
> > -sv
> >
> >
> >   
> I said tangible :)  
> 
> I'm agreed with Alan here.
> 
> Things like Cobbler can adapt easily, but we'll blindside lots of 
> people, break a lot of management apps, and not really achieve anything 
> useful by doing it.
> 

I've always hated non-compliant packages and really, really hated things
polluting / for me.

-sv




From mdehaan at redhat.com  Wed Nov 14 16:38:35 2007
From: mdehaan at redhat.com (Michael DeHaan)
Date: Wed, 14 Nov 2007 11:38:35 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071114161422.GA3423@angus.ind.WPI.EDU>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>	<1195043794.6884.6.camel@localhost.localdomain>
	<20071114161422.GA3423@angus.ind.WPI.EDU>
Message-ID: <473B248B.3040605@redhat.com>


>
> Fedora isn't about keeping status quo "Just Because".  It is about 
> innovation and constant improvement, sometimes to the detriment of 
> legacy traditions. Tradition alone isn't a valid excuse for preventing 
> innovation.
>
>   

I would hesitate to call moving a directory "innovation".




From fedora at camperquake.de  Wed Nov 14 16:46:44 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 14 Nov 2007 17:46:44 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <473B248B.3040605@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<1195043794.6884.6.camel@localhost.localdomain>
	<20071114161422.GA3423@angus.ind.WPI.EDU>
	<473B248B.3040605@redhat.com>
Message-ID: <20071114174644.565a8c1e@dhcp03.addix.net>

Hi.

On Wed, 14 Nov 2007 11:38:35 -0500, Michael DeHaan wrote:

> I would hesitate to call moving a directory "innovation".

Maybe we could patent it?



From caillon at redhat.com  Wed Nov 14 16:48:48 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Nov 2007 17:48:48 +0100
Subject: XULRunner in rawhide
In-Reply-To: <473B1EB6.7010003@redhat.com>
References: <473AFF3E.1090904@redhat.com>	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
	<473B1EB6.7010003@redhat.com>
Message-ID: <473B26F0.6090206@redhat.com>

Martin Stransky wrote:
> Alex Lancaster wrote:
>> Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
>> package somehow?  Is there another BuildRequires I need to add?
>>
>> Alex
> 
> gtkmozembed is not shipped by xulrunner, we need to check what's going 
> on...

Hm, I think this got split into a different tarball.



From cweyl at alumni.drew.edu  Wed Nov 14 16:58:44 2007
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 14 Nov 2007 08:58:44 -0800
Subject: rpms/915resolution/devel 965GM.patch, NONE,
	1.1 915resolution.spec, 1.11, 1.12
In-Reply-To: <1195018582.3036.2.camel@tuxhugs>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
	<1195018582.3036.2.camel@tuxhugs>
Message-ID: <7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>

On Nov 13, 2007 9:36 PM, Peter Gordon <peter at thecodergeek.com> wrote:
> On Wed, 2007-11-14 at 00:11 -0500, Chris Weyl wrote:
> > @@ -19,7 +20,7 @@
> >  Source100:      README.fedora
> >
> >  # for the add/remove/condrestart service stuff.
> > -Requires(post):   /sbin/chkconfig
> > +rEQuires(post):   /sbin/chkconfig
> >  Requires(preun):  /sbin/chkconfig
> >  Requires(preun):  /sbin/service
> >
>
> Err, I'm presuming that this was unintentional? :)

Yes, thanks :)

                                  -Chris

-- 
Chris Weyl
Ex astris, scientia



From darrellpf at gmail.com  Wed Nov 14 17:04:29 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 14 Nov 2007 09:04:29 -0800
Subject: Severe X breakage heads up
In-Reply-To: <1195003708.2292.13.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195003708.2292.13.camel@localhost.localdomain>
Message-ID: <f6e5806f0711140904j6809f6a9ia0fdf0dc9425a26a@mail.gmail.com>

On Nov 13, 2007 5:28 PM, Adam Jackson <ajackson at redhat.com> wrote:
> On Mon, 2007-11-05 at 15:30 -0500, Adam Jackson wrote:
> > I plan to rebase the X server to git master a week from today (Monday,
> > November 12), which means the changes should hit rawhide on Tuesday.
>
> Okay, so that didn't happen.  But things are mostly built now, at least
> for the big important core bits.  They should be on their way to a
> mirror near you tomorrow, assuming the rawhide push goes out.
>
> If you're not using radeon/nv/intel, expect that X will break, and that
> you'll need to switch to vesa or fbdev.  If you're using an input driver
> other than keyboard or mouse, expect those devices to stop working.
>
> I'll be cleaning up the rest of the mess as we go.  Please do file bugs
> about any weirdness you encounter (outside of the above known caveats).
>

Gave it a try with a laptop with an ATI R300 card. Graphics works just fine.
With the xserver from a few days ago, compiz doesn't want to start on
several machines.

Synaptics didn't load so no mouse. (Ooops, I should have read between the lines)

darrell



From debarshi.ray at gmail.com  Wed Nov 14 17:07:51 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 14 Nov 2007 22:37:51 +0530
Subject: Bluetooth on Macbook
Message-ID: <3170f42f0711140907x65bbf492rfc2718c30cf48d13@mail.gmail.com>

Bluetooth functionality seems to be broken in Fedora 7 on Intel
Macbooks (http://smolt.fedoraproject.org/show?UUID=6715696a-23ab-4352-a334-956ba0946220).
I was trying to connect to a Nokia 3110C, and even though neither the
mobile nor the laptop could discover each other initially, the steps
in http://thpinfo.com/2006/siemens-s68-linux-obexfs seemed to do the
trick.

Isn't this supposed to happen out of the box? Is this fixed in Fedora
8 or Rawhide? Should I file a bug?

This is what I had installed:
bluez-gnome-0.8-2.fc7
bluez-utils-3.9-2.fc7
bluez-libs-3.9-1.fc7
gnome-bluetooth-libs-0.9.1-1.fc7
gnome-bluetooth-0.9.1-1.fc7
obexfs-0.11-0.1.rc2.fc7
openobex-1.3-5.fc7
obexftp-0.22-0.3.rc6.fc7

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From kwizart at gmail.com  Wed Nov 14 17:12:11 2007
From: kwizart at gmail.com (KH KH)
Date: Wed, 14 Nov 2007 18:12:11 +0100
Subject: ivtv-firmware case (was: Fedora Package Status of Nov 14, 2007)
Message-ID: <e1760170711140912m4e109d02gac5066f1754e553c@mail.gmail.com>

2007/11/14, Christian Iseli <Christian.Iseli at licr.org>:
> Hi folks,
>  - 53 packages not available in devel or release
...
>     kwizart at gmail dot com                   xorg-x11-drv-ivtv
>     kwizart at gmail dot com                   ivtv-firmware
...
>  - 10 packages which have not yet been FE-ACCEPT'd...
...
>      ivtv-firmware                            axel.thimm at atrpms.net

There are "competing" review for theses,  which is still at NEED_INFO
state requested for the "primary" submitter:
https://bugzilla.redhat.com/show_bug.cgi?id=250970
This package would be acceptable if there is a reason for having it to
keep compatibility firmware location and not to keep timestamps...

Here is the review I've submitted, since I expected the submitter
wasn't interested in submitting it for Fedora... (actually he seems to
still be interested but he doesn't reply...)
https://bugzilla.redhat.com/show_bug.cgi?id=346171

There is still a problematic review with this:
https://bugzilla.redhat.com/show_bug.cgi?id=250971
As perl-Video-ivtv, perl-Video-Frequencies are not in the repository
and are known obsolete nowadays... The current state isn't acceptable
in my view... and that would be easy to fix, but there is still no
answear ...

So if any want to take over me the reviews and approve the ivtv package ?...

Nicolas (kwizart )



From notting at redhat.com  Wed Nov 14 17:11:05 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Nov 2007 12:11:05 -0500
Subject: rpms/915resolution/devel 965GM.patch, NONE, 1.1
	915resolution.spec, 1.11, 1.12
In-Reply-To: <7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
	<1195018582.3036.2.camel@tuxhugs>
	<7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>
Message-ID: <20071114171105.GA5782@nostromo.devel.redhat.com>

Chris Weyl (cweyl at alumni.drew.edu) said: 
> > Err, I'm presuming that this was unintentional? :)
> 
> Yes, thanks :)

If I may ask, what's the point of this in the devel
branch, where we don't actually use the BIOS?

Bill



From nicolas.mailhot at laposte.net  Wed Nov 14 17:24:40 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Nov 2007 18:24:40 +0100
Subject: Severe X breakage heads up
In-Reply-To: <1194294608.15341.204.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
Message-ID: <1195061080.6464.9.camel@rousalka.dyndns.org>

Some doc on how to setup input in the brave new hotplug world for
non-qwerty users would be nice.

I hereby donate my previous working xorg.conf input sections as an
exemple:

Section "InputDevice"
        Identifier  "nek4k-base"
        Driver      "evdev"
        Option      "Protocol" "evdev"
        Option      "vendor" "1118"
        Option      "product" "219"
        Option      "Phys" "*/input0"
        Option      "XkbModel" "evdev"
        Option      "XkbLayout" "fr,ru"
        Option      "XkbVariant" "oss,winkeys"
        Option      "XkbOptions"
"grp:lwin_toggle,grp_led:scroll,compose:rwin"
        Option      "CoreKeyboard"
EndSection

Section "InputDevice"
        Identifier  "nek4k-enhanced"
        Driver      "evdev"
        Option      "Protocol" "evdev"
        Option      "vendor" "1118"
        Option      "product" "219"
        Option      "Phys" "*/input1"
        Option      "SendCoreEvents"
EndSection

Section "InputDevice"
        Identifier  "track-expl"
        Driver      "evdev"
        Option      "Protocol" "evdev"
        Option      "vendor" "1118"
        Option      "product" "36"
        Option      "ZAxisMapping" "4 5"
        Option      "Buttons" "7"
        Option      "CorePointer"
EndSection

I'm sure it's complex enough that if you explain us how to express this
with the new xorg everyone on the list will manage to adapt his setup.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/a5ef3e04/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Nov 14 17:28:17 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Nov 2007 18:28:17 +0100
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071114163533.GG29823@redhat.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473B2235.8020708@redhat.com> <1195057675.23955.68.camel@cutter>
	<20071114163533.GG29823@redhat.com>
Message-ID: <1195061297.6464.13.camel@rousalka.dyndns.org>


Le mercredi 14 novembre 2007 ? 16:35 +0000, Daniel P. Berrange a ?crit :
> On Wed, Nov 14, 2007 at 11:27:55AM -0500, seth vidal wrote:

> > fhs compliance :)
> 
> And how about reasons which have tangible benefit. fhs is a merely a tick
> box

FHS means you have a properly sorted filesystem, which is nicer for new
setups, allows making parts of the filesystem RO safely, simplifies
backup policies, etc

So it's very tangible, even if you're currently more comfortable with
the mess you grew up with.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/ffd154a1/attachment.sig>

From rcritten at redhat.com  Wed Nov 14 17:33:12 2007
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 14 Nov 2007 12:33:12 -0500
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <1195037436.32559.200.camel@localhost>
References: <1195018220.32559.98.camel@localhost> <473ABC3E.9090603@hhs.nl>
	<1195037436.32559.200.camel@localhost>
Message-ID: <473B3158.80703@redhat.com>

Callum Lerwick wrote:
> On Wed, 2007-11-14 at 10:13 +0100, Hans de Goede wrote:
>> Will a simple rebuild fix the F-8 problem? In that case I think
>> publishing a 
>> set of rebuild packages is a good idea, even better would be to get
>> things 
>> reviewed and build into Fedora, on the buildsys things should always
>> build 
>> against the correct stuff and a rebuild is nice and easy.
> 
> No, rebuilding does not fix it. Something seems broke in the way curl
> works with certificates. I don't know curl or SSL at all which is why I
> could use some help. :)
> 

I'll take a look at it when I get a chance (I suspect it will take a 
while to build this considering the src.rpm is 29MB). Do I need to do 
anything special to test this (e.g. get an account)?

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/15cfa917/attachment.bin>

From kwizart at gmail.com  Wed Nov 14 17:41:55 2007
From: kwizart at gmail.com (KH KH)
Date: Wed, 14 Nov 2007 18:41:55 +0100
Subject: linux1394 and f8
In-Reply-To: <4734ABB8.10205@redhat.com>
References: <47288307.7060306@nostar.net>
	<1193844283.10224.7.camel@localhost6.localdomain6>
	<20071101044647.GA16429@puariko.nirvana> <4734ABB8.10205@redhat.com>
Message-ID: <e1760170711140941t77508e20xaba75e1d81f96a3d@mail.gmail.com>

2007/11/9, Jarod Wilson <jwilson at redhat.com>:
> Axel Thimm wrote:
> > On Wed, Oct 31, 2007 at 09:24:43AM -0600, Richi Plana wrote:
> >> On Wed, 2007-10-31 at 09:28 -0400, Doug McLain wrote:
> >>> I am running 7.92, and I see that the new firewire stack is in place.
> >>> There is a page at the linux1394 wiki that suggests that kernel
> >>> packagers build the old stack into the kernel for the time being:
> >>>
> >>> http://wiki.linux1394.org/JujuMigration
> >>>
> >>> Any chance of this happenign for Fedora 8?
> [...]
> > Alternatively Fedora could ship a kernel with both modules and
> > blacklist the old ones. So users would just need to adjust the
> > blacklisting config and I would have less work to do :)
>
> Yeah, in retrospect, we probably should have built both stacks and just
> blacklisted the old one by default, and provided userspace bits
> (basically just libraw1394) that could operate with both stacks...

As Fedora Core 6 still have the old ieee1394 stack this wouldn't hurt
that much to have regression with firewire since users could still
have it work with FC6... But when it will be EOL, then we might
provide a fall back so users can still uses firewire...

Of course it would be better to have libraw1394 compatible with both stacks.

Until then, I was thinking of having a compat-libraw1394 (in
/usr/lib/compat-libraw1394) that would work with the old stack without
replacing the libraw1394 package:
here is a SRPM:
http://kwizart.free.fr/fedora/testing/8/SRPMS/compat-libraw1394-1.3.0-1.kwizart.fc8.src.rpm
The problem with this method is that libdc1394-1 needs
compat-libraw1394 to work. And it can only work with ieee1394 stack.
Then it leads to have the related plugin in userland app to be split
as an optional package (when possible).. I expect that the new
libraw1394 would avoid this...(as moving userland apps to libdc1394-2
seems harder...)

Does having both stacks into the kernel (ieee1394 and juju) would be possible ?
( I still miss the eth1394 module... )

Nicolas (kwizart)

Ps: I've made a quick howto but untranslated (from french), anyway the
method is explained within the packages...
http://kwizart.free.fr/blog/index.php?58-couche-compatibilite-ieee1394-pour-fedora-8


> That said, we're reasonably close to having ohci 1.0 controllers playing
> nice w/the new stack. I just got back from lunch, diving back into the
> code now, actually. :)
>
> --
> Jarod Wilson
> jwilson at redhat.com
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From alan at redhat.com  Wed Nov 14 17:43:56 2007
From: alan at redhat.com (Alan Cox)
Date: Wed, 14 Nov 2007 12:43:56 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195061297.6464.13.camel@rousalka.dyndns.org>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<473B2235.8020708@redhat.com> <1195057675.23955.68.camel@cutter>
	<20071114163533.GG29823@redhat.com>
	<1195061297.6464.13.camel@rousalka.dyndns.org>
Message-ID: <20071114174356.GA9233@devserv.devel.redhat.com>

On Wed, Nov 14, 2007 at 06:28:17PM +0100, Nicolas Mailhot wrote:
> > > fhs compliance :)
> > 
> > And how about reasons which have tangible benefit. fhs is a merely a tick
> > box
> 
> FHS means you have a properly sorted filesystem, which is nicer for new
> setups, allows making parts of the filesystem RO safely, simplifies
> backup policies, etc

I'd rather be compatible with the real world. FHS started out trying to
describe and slightly refine practice, then it got taken over by people
with no experience which is why stuff like /srv got included.

> So it's very tangible, even if you're currently more comfortable with
> the mess you grew up with.

I grew up with BSD, SYSV and SunOS so most of FHS is the "best of"
for those. Then people broke it..



From fedora at leemhuis.info  Wed Nov 14 17:44:56 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 14 Nov 2007 18:44:56 +0100
Subject: Review queue/FESCo after the merge (was: Re: qct review request,
 no response?)
In-Reply-To: <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
Message-ID: <473B3418.9020207@leemhuis.info>

CCing fedora-advisory-board

On 14.11.2007 13:36, Mamoru Tasaka wrote:
> Neal Becker wrote, at 11/14/2007 09:01 PM +9:00:
>> I've seen no response to:
>> https://bugzilla.redhat.com/show_bug.cgi?id=373621
>> Did I do something wrong, or is everyone busy?
> Please be patient. Currently there are about 270 review requests
> which are not assigned to anybody.

And 1108 open reviews in total (including lots of merge reviews (?))
according to
http://fedoraproject.org/wiki/PackageMaintainers/InProgressReviewRequests

which redirects to
https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&component=Package+Review&query_format=advanced&bug_status=ASSIGNED&bug_status=FAILS_QA&bug_status=MODIFIED&bug_status=NEEDINFO&bug_status=NEW&bug_status=ON_DEV&bug_status=ON_QA&bug_status=PASSES_QA&bug_status=POST&bug_status=RELEASE_PENDING&bug_status=VERIFIED&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=fedora-review%2B&f
ield0-1-0=bug_id&type0-1-0=notregexp&value0-1-0=%5E163776%24&field0-2-0=bug_id&type0-2-0=notregexp&value0-2-0=%5E163778%24&field0-3-0=bug_id&type0-3-0=notregexp&value0-3-0=%5E163779%24&field0-4-0=bug_id&type0-4-0=notregexp&value0-4-0=%5E177841%24

Some of them are quite old. And the list of course doesn't include those
bugs that got closed as the packager lost interest over time.


I think we have a problem here. I'm actually wondering what FESCo (and
the Board) thinks about that.


Or, to look at the big picture: During the Extras days FESCo would have
taken care of something like that months ago. IIRC FESCo constantly
tried to improve the workflow for reviewers and packagers to make their
life easier, Extras better and everyone happy. And there were new
sponsors nominated and accepted every few weeks to make sure the number
of sponsors grows in parallel with the number of packagers/packages..

Both things seem to get lost during the merge(?). FESCo got lots of new
things to take care of. It seems to me most of the things it took care
of in the past fell of the table and nobody really takes care of them
anymore these days.


Or, let's say it different way: In the Extras-days FESCo made sure
contributers stayed happy while we grew. These days FESCo mainly makes
sure we get a distribution out every 6 months.

Is this what we wanted when we designed the current governing model? I
don't think so.

Is it bad? Yes, I think it is, that's why I wrote this mail.

Why do you think it's bad? Because I more and more often hear in private
that contributers are unhappy. I also got the impression that people are
more and more unwilling to participate in discussions and on lists. And
there are no new leaders emerging in FESCo/packaging-land (the low
number of people that volunteered during the FESCo election is one
reasons for this opinion; or look at FPC -- according to the wiki the
same people since one year; there is also next-to no interest by
non-committee-members in participating in the meetings).

What do you suggest? I'm not sure; some random ideas: Get barriers out
of the way. Maybe redefine the governing model again and merge FESCo and
the Board. Lower the importances of the committees -- make them
coordinate and not dominate. Make reviewing easier and help people with
exchanging reviews while making sure we get new sponsors. Move over to a
slightly more wiki-style approach for the packages and make sure
contributers are happy.

Cu
knurd

(?) -- can't remember, but wasn't it a unwritten (or even written?) goal
to get all Core packages reviewed by F8?

(?) -- does anybody know how many new sponsors we got since F7?



From caillon at redhat.com  Wed Nov 14 17:54:04 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Nov 2007 18:54:04 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B3418.9020207@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info>
Message-ID: <473B363C.9030808@redhat.com>

Thorsten Leemhuis wrote:
> And 1108 open reviews in total (including lots of merge reviews (?))
> according to
> http://fedoraproject.org/wiki/PackageMaintainers/InProgressReviewRequests
> 
> which redirects to
> https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&component=Package+Review&query_format=advanced&bug_status=ASSIGNED&bug_status=FAILS_QA&bug_status=MODIFIED&bug_status=NEEDINFO&bug_status=NEW&bug_status=ON_DEV&bug_status=ON_QA&bug_status=PASSES_QA&bug_status=POST&bug_status=RELEASE_PENDING&bug_status=VERIFIED&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=notsubstring&value0-0-0=fedora-review%2B
&f
> ield0-1-0=bug_id&type0-1-0=notregexp&value0-1-0=%5E163776%24&field0-2-0=bug_id&type0-2-0=notregexp&value0-2-0=%5E163778%24&field0-3-0=bug_id&type0-3-0=notregexp&value0-3-0=%5E163779%24&field0-4-0=bug_id&type0-4-0=notregexp&value0-4-0=%5E177841%24
> 
> Some of them are quite old. And the list of course doesn't include those
> bugs that got closed as the packager lost interest over time.
> 
> 
> I think we have a problem here. I'm actually wondering what FESCo (and
> the Board) thinks about that.

Thanks for the mail, Thorsten.  I've actually been thinking about this 
pretty recently.

We have a problem, I agree.  It's a problem I'm happy to have in a way 
because it means we're growing fast.

Part of the problem is the review process itself.  It encompasses 
several pages, many of the items are duplicated, etc.  It's just unruly. 
  And the more packaging guidelines we have, the worse it will get.  I 
tried doing a few package reviews again recently and it annoyed me to no 
end to have to do this.  And I understand the benefits here of doing the 
reviews.

I think the ideal way to fix this is to have a web app that people 
submit packages to for review.  This web app will build the SRPM in 
koji, can check the md5sum of the tarball vs upstream, can run rpmlint, 
make sure the various specfile tags are in the right format, etc etc etc 
-- as many things that we can automate in the review process we should 
automate.  Once it passes the robot review, it auto files the bugzilla 
ticket with a link to the review, and then a human can worry about 
looking at the few things (s)he needs to.  This will greatly improve the 
process for everyone IMO.

Now I just need to convince someone to do this work :)



From notting at redhat.com  Wed Nov 14 18:08:49 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Nov 2007 13:08:49 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1195061080.6464.9.camel@rousalka.dyndns.org>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195061080.6464.9.camel@rousalka.dyndns.org>
Message-ID: <20071114180849.GA8811@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> Some doc on how to setup input in the brave new hotplug world for
> non-qwerty users would be nice.
> 
> I hereby donate my previous working xorg.conf input sections as an
> exemple:

evdev isn't there yet.

Bill



From jspaleta at gmail.com  Wed Nov 14 18:15:52 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 14 Nov 2007 09:15:52 -0900
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B363C.9030808@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B363C.9030808@redhat.com>
Message-ID: <604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>

On Nov 14, 2007 8:54 AM, Christopher Aillon <caillon at redhat.com> wrote:
> I think the ideal way to fix this is to have a web app that people
> submit packages to for review.  This web app will build the SRPM in
> koji, can check the md5sum of the tarball vs upstream, can run rpmlint,
> make sure the various specfile tags are in the right format, etc etc etc
> -- as many things that we can automate in the review process we should
> automate.

the checksumming automation is going to become increasingly
problematic as more maintainers look to pull things from upstream code
management repositories instead of 'released' tarballs. If we could
have a standard way to automate the direct from the git's mouth
situations that would be a big win. A push button way of re-building
and rpmlinting in a scratch area of koji would be nice for
submissions.  I spend way to much time waiting for things to rebuild
locally thanks to the speed of my home dsl.  If I could easily fire
off a koji scratch build with rpmlint support as part of the review
process while at work, then look at the results at home, that would
save me some amount of time.

> Now I just need to convince someone to do this work :)

All I can offer is a bottle of North Pole hot sauce in trade for
working automation code.

-jef



From pertusus at free.fr  Wed Nov 14 18:22:56 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 19:22:56 +0100
Subject: Review queue/FESCo after the merge (was: Re: qct review
	request, no response?)
In-Reply-To: <473B3418.9020207@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info>
Message-ID: <20071114182256.GK14241@free.fr>

On Wed, Nov 14, 2007 at 06:44:56PM +0100, Thorsten Leemhuis wrote:
> CCing fedora-advisory-board
> 
> Some of them are quite old. And the list of course doesn't include those
> bugs that got closed as the packager lost interest over time.

I am not sure that these numbers make much sense. Because the merge
review are special for a number of reason. Many redhat people were
completly ignorant about guidelines at the beginning of merge reviews
and in my experience their skills and motivation are often below those
of the extras packagers that take similar responsibilities. Also those
redhat people cannot really review packages for those same reasons, and 
I think that it wouldn't be a good idea in many case. Another reason is
that some packages from former core are very complex. So in my opinion 
merge reviews should really be apart. Also this is an historical
accident, merge reviews once done won't need to be redone.

More important is how new packages are being processed. It is possible
that fedora isn't scaling well, the fact that there hasn't been any new
sponsor in months is quite annoying. It also seems to me that the main
reviewers are always the same people and that new reviewers are not
many.

> Why do you think it's bad? Because I more and more often hear in private
> that contributers are unhappy. I also got the impression that people are
> more and more unwilling to participate in discussions and on lists. And
> there are no new leaders emerging in FESCo/packaging-land (the low
> number of people that volunteered during the FESCo election is one
> reasons for this opinion; or look at FPC -- according to the wiki the
> same people since one year; there is also next-to no interest by
> non-committee-members in participating in the meetings).

I am also worried by the fact that the wiki is always lagging behind, 
this is something that should especially be followed by FESCo, even 
though it is a wiki.

But I am not sure that te number of reviews pending is something FESCo
can do a lot about.

--
Pat



From j.w.r.degoede at hhs.nl  Wed Nov 14 18:34:16 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 19:34:16 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B3418.9020207@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info>
Message-ID: <473B3FA8.70106@hhs.nl>

Thorsten Leemhuis wrote:
> And 1108 open reviews in total (including lots of merge reviews (?))
<snip>
> 
> I think we have a problem here. I'm actually wondering what FESCo (and
> the Board) thinks about that.
> 

Thanks for this Thorsten, I think we as a community needed this kick in the 
behind, I say we as a community, because I think its unfair to solely blame 
FESCo, as you write further down your mail, there is currently little community 
involvement in the governing of Fedora, no contributers other the the members 
attending FESCo meetings, etc. I think there are 3 reasons for this:
1) Time, time can only be spent once, and if I can choose to do something which
    gives a tangible result versus joining some discussion, I choose the former.
2) Governing, atleast in my book, is not one of the most fun tasks
3) In the extras days I had the feeling of having some control over what FESCo
    does, today I feel that certain groups within Fedora (*cough* release
    engineering *cough*) are indepent islands, not that these groups are not
    doing great work, but they don't seem controlled in any democratic way.

1 and 2 are not factors which can be controlled by Fedora, 3 however can. I 
believe its important to fix 3, as that will make joining the government of 
Fedora much more appealing.

> or look at FPC -- according to the wiki the same people since one year

Funny that you mention it, I have been thinking about joining the FPC for a 
while now, so if there is a position there I'm available. I don't think I've to 
prove my packagingskills / knowledge and given my aversion to bureaucracy I'll 
be sure to keep the guidelines mean, lean and streamlined.

Regards,

Hans



From bpepple at fedoraproject.org  Wed Nov 14 18:35:43 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 14 Nov 2007 13:35:43 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
Message-ID: <1195065343.1858.5.camel@nixon>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic Misc - Feature Process -
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00003.html - poelcat 

/topic MISC - PPC Secondary Arch? -
https://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00078.html - f13, dwmw2 

/topic FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all 

/topic Status Update: Compat Policy
http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy

/topic Status Update: FESCo Proposal Template - f13

/topic FESCo meeting -- Free discussion around Fedora

You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, since we have a pretty full schedule).  You can also
propose topics in the meeting while it is in the "Free discussion around
Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/308e0860/attachment.sig>

From rcritten at redhat.com  Wed Nov 14 18:51:19 2007
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 14 Nov 2007 13:51:19 -0500
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <473B3158.80703@redhat.com>
References: <1195018220.32559.98.camel@localhost>
	<473ABC3E.9090603@hhs.nl>	<1195037436.32559.200.camel@localhost>
	<473B3158.80703@redhat.com>
Message-ID: <473B43A7.4020105@redhat.com>

Rob Crittenden wrote:
> Callum Lerwick wrote:
>> On Wed, 2007-11-14 at 10:13 +0100, Hans de Goede wrote:
>>> Will a simple rebuild fix the F-8 problem? In that case I think
>>> publishing a set of rebuild packages is a good idea, even better 
>>> would be to get
>>> things reviewed and build into Fedora, on the buildsys things should 
>>> always
>>> build against the correct stuff and a rebuild is nice and easy.
>>
>> No, rebuilding does not fix it. Something seems broke in the way curl
>> works with certificates. I don't know curl or SSL at all which is why I
>> could use some help. :)
>>
> 
> I'll take a look at it when I get a chance (I suspect it will take a 
> while to build this considering the src.rpm is 29MB). Do I need to do 
> anything special to test this (e.g. get an account)?
> 
> rob

I can't actuallly get far enough to do the auth because the Second Life 
client is out-of-date.

Another option is to try the argument -no-verify-ssl-cert.

rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/c855428a/attachment.bin>

From jwboyer at gmail.com  Wed Nov 14 19:10:12 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Nov 2007 13:10:12 -0600
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B3FA8.70106@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
Message-ID: <20071114131012.6b86c447@weaponx>

On Wed, 14 Nov 2007 19:34:16 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> 3) In the extras days I had the feeling of having some control over what FESCo
>     does, today I feel that certain groups within Fedora (*cough* release
>     engineering *cough*) are indepent islands, not that these groups are not
>     doing great work, but they don't seem controlled in any democratic way.
> 
> 1 and 2 are not factors which can be controlled by Fedora, 3 however can. I 
> believe its important to fix 3, as that will make joining the government of 
> Fedora much more appealing.

Could you elaborate on what you see the problems being?  And possible
solutions?

josh



From ajackson at redhat.com  Wed Nov 14 19:51:22 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 14 Nov 2007 14:51:22 -0500
Subject: rpms/915resolution/devel 965GM.patch, NONE, 1.1
	915resolution.spec, 1.11, 1.12
In-Reply-To: <20071114171105.GA5782@nostromo.devel.redhat.com>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
	<1195018582.3036.2.camel@tuxhugs>
	<7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>
	<20071114171105.GA5782@nostromo.devel.redhat.com>
Message-ID: <1195069882.2292.26.camel@localhost.localdomain>

On Wed, 2007-11-14 at 12:11 -0500, Bill Nottingham wrote:
> Chris Weyl (cweyl at alumni.drew.edu) said: 
> > > Err, I'm presuming that this was unintentional? :)
> > 
> > Yes, thanks :)
> 
> If I may ask, what's the point of this in the devel
> branch, where we don't actually use the BIOS?

Seriously.  F9 won't have the i810 driver anymore.  915resolution can
die now.

- ajax



From caillon at redhat.com  Wed Nov 14 19:32:06 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 14 Nov 2007 20:32:06 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
Message-ID: <473B4D36.8070904@redhat.com>

Jeff Spaleta wrote:
> the checksumming automation is going to become increasingly
> problematic as more maintainers look to pull things from upstream code
> management repositories instead of 'released' tarballs.

Then we can leave that part out.  There's a lot we can and should automate.

* Is the BR tag one of the 3 approved versions?
* Is the License tag valid?  (this does not mean someone shouldn't 
verify the license matches the source, we could maybe automate that too 
but it's probably harder)
* Does the %install section start with a clean BR?
* Make sure packages aren't using PreReq
* Make sure it builds in mock
* Check the spec's encoding
* Make sure that use of %{buildroot} vs $RPM_BUILD_ROOT is consistent
* Make sure that there are no cases of Requires(pre,post)
* Make sure %files doesn't reference %{_datadir}/locale/*
* Check for an appropriate %clean section

etc.

Automating this stuff will let reviewers focus on a smaller set of 
issues.  Which means less chance of forgetting something, and more time 
for them to review more packages.

But another thing we can do is go through the Review Guidelines[1] and 
remove all the duplicate items.  For example, it says:

- MUST: The package must meet the Packaging Guidelines[2].

The Packaging Guidelines say:
* You should go through the Packaging/NamingGuidelines to ensure that 
your package is named appropriately.
* You should review the Packaging/LicensingGuidelines to ensure that 
your package is licensed appropriately.

Guess what the next two items in the Review Guidelines are?

If you keep reading, you'll see a lot more duplicate items (%{buildroot} 
vs $RPM_BUILD_ROOT, %clean section, etc).  Having duplicated info during 
the review process slows down the reviewer.  We should make sure there 
is one concise page that has the review process.  Flipping back and 
forth is error prone, and just adds a layer of complexity.  You're 
already flipping between a page and a spec file.  Flipping around to 
other pages is just pain.

[1] http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
[2] http://fedoraproject.org/wiki/Packaging/Guidelines



From j.w.r.degoede at hhs.nl  Wed Nov 14 19:45:05 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 20:45:05 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B4D36.8070904@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com>
Message-ID: <473B5041.6080202@hhs.nl>

Christopher Aillon wrote:
> * Make sure that there are no cases of Requires(pre,post)
Erm, why isn't the use of those perfectly "legal"

Regards,

Hans



From tibbs at math.uh.edu  Wed Nov 14 19:44:11 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 14 Nov 2007 13:44:11 -0600
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B4D36.8070904@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com>
Message-ID: <ufa1waseho4.fsf@epithumia.math.uh.edu>

>>>>> "CA" == Christopher Aillon <caillon at redhat.com> writes:

CA> Then we can leave that part out.  There's a lot we can and should
CA> automate.

[...]

Actually all of the relevant tests should get into rpmlint, and then
we can just run rpmlint.

 - J<



From d.jacobfeuerborn at conversis.de  Wed Nov 14 19:47:08 2007
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Wed, 14 Nov 2007 20:47:08 +0100
Subject: XULRunner in rawhide
In-Reply-To: <473AFF3E.1090904@redhat.com>
References: <473AFF3E.1090904@redhat.com>
Message-ID: <473B50BC.7030504@conversis.de>

Martin Stransky wrote:
> Hello,
> 
> there's a new package in rawhide, xulrunner
> (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
> gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
> XUL application and run in by xulrunner.

Is this really going to work? The Mozilla guys made it clear that they 
don't want to make Firefox depend on xulrunner as that would limit their 
ability to push the envelope with firefox. If Fedora wants to make that 
move wouldn't that eventually require a fork?

http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/

Regards,
   Dennis



From martin.sourada at seznam.cz  Wed Nov 14 17:58:59 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Wed, 14 Nov 2007 18:58:59 +0100
Subject: How to use mozjs from xulrunner?
Message-ID: <1195063139.2769.39.camel@pc-notebook.kolej.mff.cuni.cz>

Hi,

I attempted to optimise the gxine package, which uses JS library, for
xulrunner, as I though it might be better to use xulrunner's mozjs,
rather than libjs as xulrunner is already needed for it's mozplugin, so
I have locally built a copy with xulrunner's mozjs used and I got this
error when I try to run the application: 

gxine: error while loading shared libraries: libmozjs.so: cannot open
shared object file: No such file or directory. 

So I reverted back to libjs until it is fixed.

I also tried latest hg snapshot, which dropped support for libjs
altogether, with the same result.

One thing that fixes the issue is making a symlink in /usr/lib
to /usr/lib/xurunner-$version$/mozjs.so

What could be wrong? I also noticed that there are problems with mozjs
header files where the xulrunner-js.pc file directs to 'stable' subdir
of xulrunner includes, while the mozjs is in 'js' subdir.

I have xulrunner-devel-1.9-0.alpha9.2.fc9 installed in my otherwise F8
box.

Thanks,
Martin



From walters at redhat.com  Wed Nov 14 20:00:44 2007
From: walters at redhat.com (Colin Walters)
Date: Wed, 14 Nov 2007 15:00:44 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <ufa1waseho4.fsf@epithumia.math.uh.edu>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp> <473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com> <ufa1waseho4.fsf@epithumia.math.uh.edu>
Message-ID: <1195070444.9613.5.camel@space-ghost.verbum.private>


On Wed, 2007-11-14 at 13:44 -0600, Jason L Tibbitts III wrote:
> >>>>> "CA" == Christopher Aillon <caillon at redhat.com> writes:
> 
> CA> Then we can leave that part out.  There's a lot we can and should
> CA> automate.
> 
> [...]
> 
> Actually all of the relevant tests should get into rpmlint, and then
> we can just run rpmlint.

rpmlint probably shouldn't be doing the "build in mock" test at least,
but I think you have the right idea in that if we have these kinds of
tests, it makes sense to have them as part of a continuous process (i.e.
run them every time spec changes) rather than just the first time we add
some software.




From nicolas.mailhot at laposte.net  Wed Nov 14 20:02:20 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Nov 2007 21:02:20 +0100
Subject: Severe X breakage heads up
In-Reply-To: <20071114180849.GA8811@nostromo.devel.redhat.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195061080.6464.9.camel@rousalka.dyndns.org>
	<20071114180849.GA8811@nostromo.devel.redhat.com>
Message-ID: <1195070540.7660.2.camel@rousalka.dyndns.org>


Le mercredi 14 novembre 2007 ? 13:08 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > Some doc on how to setup input in the brave new hotplug world for
> > non-qwerty users would be nice.
> > 
> > I hereby donate my previous working xorg.conf input sections as an
> > exemple:
> 
> evdev isn't there yet.

The problem is not evdev, it was working in F8, the problem is how the
new rawhide xorg moves all the input bits out of xorg.conf and there's
no documentation I know of on the new input hotplug configuration.

(also the new stuff uses evdev by default but let me repeat that's not
the problem ? this part works)

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/871d0950/attachment.sig>

From stransky at redhat.com  Wed Nov 14 20:09:07 2007
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 14 Nov 2007 21:09:07 +0100
Subject: How to use mozjs from xulrunner?
In-Reply-To: <1195063139.2769.39.camel@pc-notebook.kolej.mff.cuni.cz>
References: <1195063139.2769.39.camel@pc-notebook.kolej.mff.cuni.cz>
Message-ID: <473B55E3.6030401@redhat.com>

This problem is usually solved by rpath linker parameter in gecko-libs 
packages. Please file a bug against xulrunner (or firefox), it should be 
fixed somehow...

Martin Sourada wrote:
> Hi,
> 
> I attempted to optimise the gxine package, which uses JS library, for
> xulrunner, as I though it might be better to use xulrunner's mozjs,
> rather than libjs as xulrunner is already needed for it's mozplugin, so
> I have locally built a copy with xulrunner's mozjs used and I got this
> error when I try to run the application: 
> 
> gxine: error while loading shared libraries: libmozjs.so: cannot open
> shared object file: No such file or directory. 
> 
> So I reverted back to libjs until it is fixed.
> 
> I also tried latest hg snapshot, which dropped support for libjs
> altogether, with the same result.
> 
> One thing that fixes the issue is making a symlink in /usr/lib
> to /usr/lib/xurunner-$version$/mozjs.so
> 
> What could be wrong? I also noticed that there are problems with mozjs
> header files where the xulrunner-js.pc file directs to 'stable' subdir
> of xulrunner includes, while the mozjs is in 'js' subdir.
> 
> I have xulrunner-devel-1.9-0.alpha9.2.fc9 installed in my otherwise F8
> box.
> 
> Thanks,
> Martin
> 



From braden at endoframe.com  Wed Nov 14 20:10:50 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Wed, 14 Nov 2007 15:10:50 -0500
Subject: How to use mozjs from xulrunner?
In-Reply-To: <1195063139.2769.39.camel@pc-notebook.kolej.mff.cuni.cz>
References: <1195063139.2769.39.camel@pc-notebook.kolej.mff.cuni.cz>
Message-ID: <473B564A.3030109@endoframe.com>

Martin Sourada wrote:
> Hi,
> 
> I attempted to optimise the gxine package, which uses JS library, for
> xulrunner, as I though it might be better to use xulrunner's mozjs,
> rather than libjs as xulrunner is already needed for it's mozplugin, so
> I have locally built a copy with xulrunner's mozjs used and I got this
> error when I try to run the application: 
> 
> gxine: error while loading shared libraries: libmozjs.so: cannot open
> shared object file: No such file or directory.

openvrml-xembed solves this by adding an rpath to where libmozjs.so lives.

Another alternative is a driver script that sets LD_RUN_PATH appropriately.

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From pertusus at free.fr  Wed Nov 14 20:11:56 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 21:11:56 +0100
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <1195065343.1858.5.camel@nixon>
References: <1195065343.1858.5.camel@nixon>
Message-ID: <20071114201155.GM14241@free.fr>

On Wed, Nov 14, 2007 at 01:35:43PM -0500, Brian Pepple wrote:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
> in #fedora-meeting on irc.freenode.org:
> 
> /topic FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all 

Please don't rush people to close reviews, but to act to comments 
instead. And in any case reviews may take time, it is better than lose 
on quality in my opinion.

> You want something to be discussed? Send a note to the list in reply to
> this mail and I'll add it to the schedule (I can't promise we will get
> to it tomorrow, since we have a pretty full schedule).  You can also

While trying to do minimal installs in a chroot I noticed some unowned
directories created sometimes on the fly, and also because setup doesn't
depend on filesystem. However, it is not clear that it is an interesting
setting, and knowing the lack of will of some maintainers to fix their 
package for such corner case, I would like to know if FESCo wants this
to be investigated and fixed, if there is no FESCo blessing there is
chances that there will be exhausting discussions.

--
Pat



From j.w.r.degoede at hhs.nl  Wed Nov 14 20:16:36 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 21:16:36 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114131012.6b86c447@weaponx>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl> <20071114131012.6b86c447@weaponx>
Message-ID: <473B57A4.7010705@hhs.nl>

Josh Boyer wrote:
> On Wed, 14 Nov 2007 19:34:16 +0100
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> 3) In the extras days I had the feeling of having some control over what FESCo
>>     does, today I feel that certain groups within Fedora (*cough* release
>>     engineering *cough*) are indepent islands, not that these groups are not
>>     doing great work, but they don't seem controlled in any democratic way.
>>
>> 1 and 2 are not factors which can be controlled by Fedora, 3 however can. I 
>> believe its important to fix 3, as that will make joining the government of 
>> Fedora much more appealing.
> 
> Could you elaborate on what you see the problems being?  And possible
> solutions?
> 

Some less spoonfeeding of decisions and more discussion in public instead of 
presenting pre-cooked proposals the entire circle of power already agrees on, 
would help greatly here.

Look at it this way, Fedora is all about Freedom, but since the merger the 
Freedom for contributers (esp. packagers) has been greatly reduced. Take the 
new release engineering proposals for example, I have some ideas about this, 
but the entire release engineering crowd had already precooked there ideas and 
unanimously disagreed with mine, or atleast that is how I perceived this.

Most typically of all this I guess is this alinea: This will probably be my 
last mail in this thread, as I see no use in continuing this dicussion, why?
Because I no longer believe that discussions like this will cause any changes.

Regards,

Hans



From notting at redhat.com  Wed Nov 14 20:20:19 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Nov 2007 15:20:19 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B5041.6080202@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com> <473B5041.6080202@hhs.nl>
Message-ID: <20071114202019.GA5162@nostromo.devel.redhat.com>

Hans de Goede (j.w.r.degoede at hhs.nl) said: 
> Christopher Aillon wrote:
>> * Make sure that there are no cases of Requires(pre,post)
> Erm, why isn't the use of those perfectly "legal"

As I understand it, Requires(pre) is OK, Requires(post) is OK,
Requires(pre,post) is not.

Bill



From j.w.r.degoede at hhs.nl  Wed Nov 14 20:34:10 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 21:34:10 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114202019.GA5162@nostromo.devel.redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>	<473B4D36.8070904@redhat.com>
	<473B5041.6080202@hhs.nl>
	<20071114202019.GA5162@nostromo.devel.redhat.com>
Message-ID: <473B5BC2.1070708@hhs.nl>

Bill Nottingham wrote:
> Hans de Goede (j.w.r.degoede at hhs.nl) said: 
>> Christopher Aillon wrote:
>>> * Make sure that there are no cases of Requires(pre,post)
>> Erm, why isn't the use of those perfectly "legal"
> 
> As I understand it, Requires(pre) is OK, Requires(post) is OK,
> Requires(pre,post) is not.
> 

Ah,

Yes I actually knew that, but I didn't read it that way, oops.

Regards,

Hans



From lmacken at redhat.com  Wed Nov 14 20:57:35 2007
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 14 Nov 2007 15:57:35 -0500
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <20071112180131.GT11043@crow.myhome.westell.com>
References: <20071112180131.GT11043@crow.myhome.westell.com>
Message-ID: <20071114205735.GE32058@crow.myhome.westell.com>

Attached is my first attempt at a patch that should hopefully address all of the
concerns that were mentioned.  This Makefile target now can handle:

    - auto-populating all bugs listed in the last changelog entry.
    - aborting if the template (excluding comments) does not differ from
      the original

I also noticed that Till's Makefile grabs only 1 bugzilla # per line, even if
multiple are listed.  The attached patch can handle multiple bugs per line.

luke
-------------- next part --------------
--- Makefile.common	13 Nov 2007 16:34:28 -0000	1.81
+++ Makefile.common	14 Nov 2007 20:55:28 -0000
@@ -133,6 +133,7 @@ WGET	?= $(shell if test -f /usr/bin/wget
 CLIENT	?= $(if $(CURL),$(CURL),$(if $(WGET),$(WGET)))
 PLAGUE_CLIENT ?= $(shell which plague-client 2>/dev/null)
 BUILD_CLIENT ?= $(shell which koji 2>/dev/null)
+BODHI_CLIENT ?= $(shell which bodhi 2>/dev/null)
 
 # RPM with all the overrides in place; you can override this in your
 # .cvspkgsrc also, to use a default rpm setup
@@ -428,6 +429,21 @@ else
 build: plague
 endif
 
+
+bodhi: build-check $(COMMON_DIR)/branches clog
+	@if [ ! -x "$(BODHI_CLIENT)" ]; then echo "Must have bodhi-client installed"; exit 1; fi
+	@echo -e "# [ $(NAME)-$(VERSION)-$(RELEASE) ]\n# type=[S|B|E] (S=security, B=bugfix, E=enhancement)\n# request=[T|S] (T=testing, S=stable)\n# bug=123,456\n# all other text will be considered to be part of the update notes\ntype=" > bodhi.template
+	@grep '#' clog | xargs -n1 | sed -n -e 's,^#\([0-9]*\)$$,\1,p' | xargs | tr ' ' ',' > $(NAME).bugs
+	@if [ `cat $(NAME).bugs` ]; then echo "bug=`cat $(NAME).bugs`" >> bodhi.template; fi
+	@sed -e '/^#/d' < bodhi.template > bodhi.template.orig
+	@if [ -z "$$EDITOR" ]; then vi bodhi.template; else $$EDITOR bodhi.template; fi
+	@if [ -n "`sed -e '/^#/d' < bodhi.template | diff bodhi.template.orig -`" ]; then $(BODHI_CLIENT) --new --release $(subst -,,$(BRANCH)) --file bodhi.template $(NAME)-$(VERSION)-$(RELEASE); else echo "Bodhi update aborted!"; fi
+	@rm -f bodhi.template{,.orig} $(NAME).bugs clog
+
+ifneq (, $(filter F-8 F-7, $(BRANCH)))
+update: bodhi
+endif
+
 cvsurl:
 	@echo '$(CVS_URL)'
 

From ville.skytta at iki.fi  Wed Nov 14 21:10:08 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 14 Nov 2007 23:10:08 +0200
Subject: Improving halt package interaction...
In-Reply-To: <20071114034410.GA19700@nostromo.devel.redhat.com>
References: <fhdi4e$7on$1@ger.gmane.org>
	<20071114034410.GA19700@nostromo.devel.redhat.com>
Message-ID: <200711142310.08807.ville.skytta@iki.fi>

On Wednesday 14 November 2007, Bill Nottingham wrote:
> Thomas M Steenholdt (tmus at tmus.dk) said:
> > The current version of the /etc/init.d/halt script (from
> > initscripts-8.60-1) includes UPS handling code for the NUT UPS software(i
> > think). NUT could easily be made to use the new /etc/halt.d/
> > infrastructure too, and /etc/init.d/halt could get rid of the non-generic
> > UPS handling code, which IMHO should be avoided anyway...
> >
> > What do you guys think about this?

+1.  Actually, I thought I had RFE'd this in Bugzilla some time ago but can't 
find it now.

> What's needed here that can't just be done with a 'normal' script
> that runs in runlevel 0/6?

I don't know about the above, but my use case is setting the ACPI wakeup time 
to /proc/acpi/alarm (an essential feature for eg. PVR boxes to have them wake 
up on time for the next timed recording).  /etc/init.d/halt runs hwclock 
which as a side effect clears the wakeup time, so it needs to be set after 
hwclock.



From fedora at leemhuis.info  Wed Nov 14 21:22:55 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 14 Nov 2007 22:22:55 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B363C.9030808@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>
Message-ID: <473B672F.5070008@leemhuis.info>

On 14.11.2007 18:54, Christopher Aillon wrote:
> Thorsten Leemhuis wrote:
> 
> We have a problem, I agree.  It's a problem I'm happy to have in a way 
> because it means we're growing fast.

Fast yes, but not that much faster as Core and Extras moved one year ago
afaics.

> Part of the problem is the review process itself. 

+1 ; the "merge-review" idea IMHO was and still is a to big target as well.

> It encompasses 
> several pages, many of the items are duplicated, etc.  It's just unruly.

+1

>   And the more packaging guidelines we have, the worse it will get. 

I think it is time to split some things into "this you must know" and
"this is written down here so you can look it up if you act in a
specific area and need guidance"

> [...]
> I think the ideal way to fix this is to have a web app that people 
> submit packages to for review.  This web app will build the SRPM in 
> koji, can check the md5sum of the tarball vs upstream, can run rpmlint, 
> make sure the various specfile tags are in the right format, etc etc etc 
> -- as many things that we can automate in the review process we should 
> automate.

Not sure if we need a "web app" for it:

 * Scratch builds are possible in koji already, but not that much
advertised.

 * "md5sum of the tarball vs upstream" -- why do we have this test at
all? A packager that wants to get malicious code into Fedora can easily
do that after the initial import by uploading a new source package into
the look-aside cache during the next update; chances are very small that
somebody will recheck the file.  On the other hand: If we want this
check then is has to be done at least partly by a human during review,
as he needs to check if the download location is a sane one and not the
packagers homepage. A simple script (which should be in a pacakge
fedora-reviewertools or something) can automate the rest for the reviewer.

 * rpmlint -- yes, of course; but the packager should do it already when
he uploads the package

 * "make sure the various specfile tags are in the right format" ->
should likely be done by rpmlint?

On the other hand having some kind of place that runs rpmlint and md5sum
checks after each package build in koji would be a really nice thing to
have.

Cu
knurd



From ville.skytta at iki.fi  Wed Nov 14 21:24:46 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 14 Nov 2007 23:24:46 +0200
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B3FA8.70106@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>
Message-ID: <200711142324.46859.ville.skytta@iki.fi>

On Wednesday 14 November 2007, Hans de Goede wrote:
> Thorsten Leemhuis wrote:
>
> > or look at FPC -- according to the wiki the same people since one year
>
> Funny that you mention it, I have been thinking about joining the FPC for a
> while now, so if there is a position there I'm available.

We discussed rotating/adding FPC positions a few weeks ago, see 
http://fedoraproject.org/wiki/Packaging/Minutes20071016

Not sure if a mail asking for general interest in joining the FPC was ever 
sent out though, if it was, I missed it.

> I don't think 
> I've to prove my packagingskills / knowledge and given my aversion to
> bureaucracy I'll be sure to keep the guidelines mean, lean and streamlined.

I think it would be great to have you (as well as other fresh blood) on board.



From fedora at leemhuis.info  Wed Nov 14 21:26:13 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 14 Nov 2007 22:26:13 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <ufa1waseho4.fsf@epithumia.math.uh.edu>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>	<473B4D36.8070904@redhat.com>
	<ufa1waseho4.fsf@epithumia.math.uh.edu>
Message-ID: <473B67F5.3060702@leemhuis.info>



On 14.11.2007 20:44, Jason L Tibbitts III wrote:
>>>>>> "CA" == Christopher Aillon <caillon at redhat.com> writes:
> 
> CA> Then we can leave that part out.  There's a lot we can and should
> CA> automate.
> [...]
> Actually all of the relevant tests should get into rpmlint, and then
> we can just run rpmlint.

+1 (maybe with a --without-fedora cmd line parm to disable
fedora-specific checks? or do we simply ignore that usage scenario?)

CU
knurd



From a.badger at gmail.com  Wed Nov 14 21:32:02 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 14 Nov 2007 13:32:02 -0800
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B4D36.8070904@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com>
Message-ID: <473B6952.20605@gmail.com>

Good idea.  Reorganized for larger issues at the top and implementation 
notes at the bottom.

Christopher Aillon wrote:

> Automating this stuff will let reviewers focus on a smaller set of 
> issues.  Which means less chance of forgetting something, and more time 
> for them to review more packages.
> 
Absolutely a goal to shoot for.

> But another thing we can do is go through the Review Guidelines[1] and 
> remove all the duplicate items.  For example, it says:
> 
> - MUST: The package must meet the Packaging Guidelines[2].
> 
> The Packaging Guidelines say:
> * You should go through the Packaging/NamingGuidelines to ensure that 
> your package is named appropriately.
> * You should review the Packaging/LicensingGuidelines to ensure that 
> your package is licensed appropriately.
> 
> Guess what the next two items in the Review Guidelines are?
> 
Actually, at some point the FPC made an effort to merge the 
ReviewGuidelines and the PackagingGuidelines so that the two were 
different views on the same thing.  One is a checklist of problems to 
check.  The other gives reasoning and notes exceptions to those rules.

So the real issues are:
1) this has to be made clear on ReviewGuidelines
2) the two lists have to be checked to make sure they both are complete 
at this point
3) the two lists have to be kept in sync.

[From a previous email]
 > This web app will build the SRPM in koji, can check the md5sum of the
 > tarball vs upstream
 >
At one time we wanted to make sure that packages went through review 
before being built in the buildsystem.  This was to protect the 
buildsystem from malicious packages trying to compromise it.  However, I 
think koji's ability to scratch build an arbitrary SRPM does an end-run 
around this requirement anyway....

= Implementation Details =

When checking the md5sums automatically, we have to make sure that the 
human understands they still need to verify that tarballs are being 
downloaded from a canonical upstream location.  And the human will have 
to verify that things match upstream when the upstream source is a 
source control tree as well.

 > * Is the License tag valid?  (this does not mean someone shouldn't
 > verify the license matches the source, we could maybe automate that too
 > but it's probably harder)
Right.  So we'll need human interaction to supplement the automation here.

 > * Check the spec's encoding
This also needs human supplementing.  We can check that the spec file is 
ASCii but how are we to tell that the non-ASCii characters in there are 
UTF-8 without a human looking at the context?

-Toshio



From tcallawa at redhat.com  Wed Nov 14 21:33:28 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 14 Nov 2007 16:33:28 -0500
Subject: Fedora Packaging Committee (Was: Re: Review queue/FESCo after the
	merge)
In-Reply-To: <200711142324.46859.ville.skytta@iki.fi>
References: <fheo3b$8nv$1@ger.gmane.org> <473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>  <200711142324.46859.ville.skytta@iki.fi>
Message-ID: <1195076008.3871.36.camel@localhost.localdomain>


On Wed, 2007-11-14 at 23:24 +0200, Ville Skytt? wrote:
> On Wednesday 14 November 2007, Hans de Goede wrote:
> > Thorsten Leemhuis wrote:
> >
> > > or look at FPC -- according to the wiki the same people since one year
> >
> > Funny that you mention it, I have been thinking about joining the FPC for a
> > while now, so if there is a position there I'm available.
> 
> We discussed rotating/adding FPC positions a few weeks ago, see 
> http://fedoraproject.org/wiki/Packaging/Minutes20071016
> 
> Not sure if a mail asking for general interest in joining the FPC was ever 
> sent out though, if it was, I missed it.

It was not, but now it will be!

Are you interested in helping to shape the Fedora Packaging Guidelines?

Well, of course not. Only someone truly insan... wait, what? You said
yes? Are you feeling well? Sit down for a moment.

Seriously, we're looking for well qualified and motivated volunteers to
help us make the hard decisions on how Fedora packages should be made.
If you're interested, please drop me an email off list. Must be a Fedora
contributor with CVS access.

Thanks,

~spot



From jkeating at redhat.com  Wed Nov 14 21:34:47 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 16:34:47 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B57A4.7010705@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
	<20071114131012.6b86c447@weaponx> <473B57A4.7010705@hhs.nl>
Message-ID: <20071114163447.4e86a75e@redhat.com>

On Wed, 14 Nov 2007 21:16:36 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Look at it this way, Fedora is all about Freedom, but since the
> merger the Freedom for contributers (esp. packagers) has been greatly
> reduced. Take the new release engineering proposals for example, I
> have some ideas about this, but the entire release engineering crowd
> had already precooked there ideas and unanimously disagreed with
> mine, or atleast that is how I perceived this.
> 
> Most typically of all this I guess is this alinea: This will probably
> be my last mail in this thread, as I see no use in continuing this
> dicussion, why? Because I no longer believe that discussions like
> this will cause any changes.

Wow, I am somewhat blindsided by this.

I created the proposal after talking to some people and posted it out
on the net for review, long before even the rel-eng group voted on it.
I asked for all kinds of feed back, multiple times.  I had to get the
releng group to agree to it, and FESCo an opportunity to agree to it.
There was discussion on list and changes made.  What more were you
looking for?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/78dfb919/attachment.sig>

From jkeating at redhat.com  Wed Nov 14 21:40:46 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 16:40:46 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <1195065343.1858.5.camel@nixon>
References: <1195065343.1858.5.camel@nixon>
Message-ID: <20071114164046.22dbcd96@redhat.com>

On Wed, 14 Nov 2007 13:35:43 -0500
Brian Pepple <bpepple at fedoraproject.org> wrote:

> You want something to be discussed? Send a note to the list in reply
> to this mail and I'll add it to the schedule (I can't promise we will
> get to it tomorrow, since we have a pretty full schedule).  You can
> also propose topics in the meeting while it is in the "Free
> discussion around Fedora" phase.

Some topics...

Drop orphans from F8< at some point during F9

Use Matt Domsch's "doesn't rebuild" bugs as AWOL detection, mark as orphaned at some point in F9, drop in F9+

Do more frequent conflicts testing, with bugs filed, and use AWOL
detection from above.

Approval of proposed F9 Schedule

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/b69853fa/attachment.sig>

From fedora at leemhuis.info  Wed Nov 14 21:43:28 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 14 Nov 2007 22:43:28 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114182256.GK14241@free.fr>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<20071114182256.GK14241@free.fr>
Message-ID: <473B6C00.3030402@leemhuis.info>

On 14.11.2007 19:22, Patrice Dumas wrote:
> On Wed, Nov 14, 2007 at 06:44:56PM +0100, Thorsten Leemhuis wrote:
>> CCing fedora-advisory-board
>> Some of them are quite old. And the list of course doesn't include those
>> bugs that got closed as the packager lost interest over time.
> I am not sure that these numbers make much sense. Because the merge
> review are special for a number of reason.

Sure they are -- but with the current rate we'll finish them by Fedora
12. By then we likely should already have start a re-review of the
oldest packages to see what cruft made it into them over the years since
review.

Which brings me to my "slightly more wiki style approach" -- currently I
now and then see some errors in spec files (even in my own). I often
ignore most them which I locate in other peoples packages because
preparing a patch, submitting it via bugzilla is a to much work for
small fixes. Simply submitting them to CVS would be way easier.

That's why I think experienced packagers and/or a review group should be
allowed to do such changes directly in CVS -- devel branch only and not
in the four weeks right before a release is scheduled of course. That
group with some hand-made scripts could even grep for common errors in
the devel branch and simply just fix then with a sed call within some
minutes. Currently it would require lots of mails, new bugs and
contributer poking, because modifying other peoples packages in
Fedora-land is frowned upon.

That way we could improve package quality throughout the distro. And
even things that slipped through review would get fixed.

>  [...]
>> Why do you think it's bad? Because I more and more often hear in private
>> that contributers are unhappy. I also got the impression that people are
>> more and more unwilling to participate in discussions and on lists. And
>> there are no new leaders emerging in FESCo/packaging-land (the low
>> number of people that volunteered during the FESCo election is one
>> reasons for this opinion; or look at FPC -- according to the wiki the
>> same people since one year; there is also next-to no interest by
>> non-committee-members in participating in the meetings).
> 
> I am also worried by the fact that the wiki is always lagging behind, 
> this is something that should especially be followed by FESCo, even 
> though it is a wiki.

Yeah, maintaining the wiki is a boring job :-/ Sometimes I think that a
owner per wiki-page might be a good idea -- he could roughly oversee
changes, coordinate them and now and them just look at each page with
his "is it sill up2date"-glasses.

> But I am not sure that te number of reviews pending is something FESCo
> can do a lot about.

Well, I think FESCo should watch it and look where changes in hte
process are needed to keep everything working.

CU
knurd



From a.badger at gmail.com  Wed Nov 14 21:44:42 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 14 Nov 2007 13:44:42 -0800
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B672F.5070008@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B363C.9030808@redhat.com>
	<473B672F.5070008@leemhuis.info>
Message-ID: <473B6C4A.1070009@gmail.com>

Thorsten Leemhuis wrote:
> On 14.11.2007 18:54, Christopher Aillon wrote:
>> It encompasses 
>> several pages, many of the items are duplicated, etc.  It's just unruly.
> 
> +1
> 
>>   And the more packaging guidelines we have, the worse it will get. 
> 
> I think it is time to split some things into "this you must know" and
> "this is written down here so you can look it up if you act in a
> specific area and need guidance"
> 
It's definitely time to organize and split the review guidelines.

Packages should not violate the rules but there are many rules that only 
apply to a subset of packages.  It's not a small task, though.  The 
categories have to be intuitive enough so that if I'm reviewing a python 
web application I know to look in:

General Guidelines
Python Apps
Web Applications
Daemons

(To some extent we already have to do this.  There are, for instance, 
pages for language specific guidelines already.)

-Toshio



From johannbg at hi.is  Wed Nov 14 21:51:18 2007
From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=)
Date: Wed, 14 Nov 2007 21:51:18 -0000 (GMT)
Subject: System-Config-Firewall, Bluetooth,CodecBuddy,
 System-Config-Selinux and an BB/Nanny
Message-ID: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>

First of all thanks to all the sponsors/developers/testers/maintainers/
people contributing/work on/in creating Fedora..

I manage to gather a couple of people/"lab rats" with little
to none technical skills at the price of beer,wine and food last weekend.
I had couple of computers and my "toys" on a table for them to play with.
( mp3 player cameras etc.. and yes they all worked with Fedora but they
did not know that, age group 30 to 50 both genders )controlled enviroment.

They installed and used Werewolf and I got to watch them do that ;) ...
What came out of this other than an great party afterwards was....

So let's skip the usually things we all know are great...

System-config-firewall this was the first time that
my human technical challenge lab rats could use it with
comfort and ease and could grasp when I explained how to use
it.

2 RFE came out of this torrent ports were missing from the hasable list
and 1 user was wondering if there was some stats app about how many
"virus/attacks" he avoided ( block/drop packages ) his question
comes from those anti virus apps I suppose...
Will file that when I have time..

And I believe that this deserves the N1 place in "on the hood"
from noob user perspective changes in FC8..

The second place goes to CodecBuddy people did mind
paying for media codecs as long as they could play their media
but they did mind have to register instead
of getting to pay instantly/now/paypal button but then
again its fluendo problem losing money out the window..

In the third place from noob user perspective "on the hood"
Bluetooth, Why third? because all those lab rats knew or some
didnt know that their phone had bluetooth and all those noob users
had never used it nor turned it on ofcourse I tested them and and yes they
all worked..

System-config-Selinux notifier wtf for the noob...
I triggered an selinux alert and shtf and here we are at impass
Even if we make the "notice" more userfriendly, we cant have
*next* ( which they wanted ) button to solve it because we dont
want the user to allow something that should not be allowed
( and yes these users would press the next button to make it go away )
I gave this a great deal of thought and came up with nothing
just that this will always be a problem.
( no we dont want users to disable this with disable me button,
because whats the point having it if everybody disable it. )

Now I was asked if there was available Bigbrother/Nanny software
that could protect/monitor their children computer usage
from all the harm and danger the internet can bring?

Anything anyone?

Does Redhat have this covered before rolling out Redhat-Desktop

Something that can ease the mind of parents?

Best Regards
          Johann B.

Ps. Somebody might wanna update the wiki page to mention
    Werewolf as current maintainded release, and take out Zod
    ( http://fedoraproject.org/wiki/Releases )



From jwboyer at gmail.com  Wed Nov 14 21:51:59 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Nov 2007 15:51:59 -0600
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <20071114164046.22dbcd96@redhat.com>
References: <1195065343.1858.5.camel@nixon>
	<20071114164046.22dbcd96@redhat.com>
Message-ID: <20071114155159.0b5d49b9@weaponx>

On Wed, 14 Nov 2007 16:40:46 -0500
Jesse Keating <jkeating at redhat.com> wrote:

> On Wed, 14 Nov 2007 13:35:43 -0500
> Brian Pepple <bpepple at fedoraproject.org> wrote:
> 
> > You want something to be discussed? Send a note to the list in reply
> > to this mail and I'll add it to the schedule (I can't promise we will
> > get to it tomorrow, since we have a pretty full schedule).  You can
> > also propose topics in the meeting while it is in the "Free
> > discussion around Fedora" phase.
> 
> Some topics...
> 
> Drop orphans from F8< at some point during F9
> 
> Use Matt Domsch's "doesn't rebuild" bugs as AWOL detection, mark as orphaned at some point in F9, drop in F9+

Matt, can you provide your rebuild scripts somewhere?

josh



From poelstra at redhat.com  Wed Nov 14 21:53:11 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 14 Nov 2007 13:53:11 -0800
Subject: Bugzilla Versions :: Request for Community & FESCo review
Message-ID: <473B6E47.7090004@redhat.com>

The Fedora QA team voted today to simply the displayed Fedora Versions in Bugzilla.  We would like a vote by FESCo on 2007-11-15 to proceed with the changes outlined below.  

These changes should reduce confusion and help us to simply our bug tracking efforts while complementing the new release process (no test releases).  

There will NOT be separate versions for "alpha" and "beta" as there has been little value derived from tracking bugs in the past by test release.


Proposed changes are as follows:

1) Leave the "product name of "Fedora" the same.

2) Change the version of "devel" to "rawhide" to be consistent with new naming convention

3) Normalize the existing version numbers to be numerical values only, with the exception of rawhide. Adding "F" or "FC" before the version number is redundant.  We already have "Fedora" as the product. The new valid versions will be:
     rawhide
     1
     2
     3
     4
     5
     6
     7
     8

4) We will follow this versioning scheme for all releases going forward until FESCo determines that other changes are needed.

5) Bugs previously opened against test releases will also be merged into the released version.  For example:

             \ 
    FC6Test1  \
    FC6Test2   | ===> 6
    FC6Test3  /
    FC6      /
            
6) Bonus points if we can disable the ability to file new bugs against releases that are no longer supported, for example, FC(1..5).



From jwboyer at gmail.com  Wed Nov 14 21:55:13 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Nov 2007 15:55:13 -0600
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B57A4.7010705@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
	<20071114131012.6b86c447@weaponx> <473B57A4.7010705@hhs.nl>
Message-ID: <20071114155513.2f16cfd7@weaponx>

On Wed, 14 Nov 2007 21:16:36 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Josh Boyer wrote:
> > On Wed, 14 Nov 2007 19:34:16 +0100
> > Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> > 
> >> 3) In the extras days I had the feeling of having some control over what FESCo
> >>     does, today I feel that certain groups within Fedora (*cough* release
> >>     engineering *cough*) are indepent islands, not that these groups are not
> >>     doing great work, but they don't seem controlled in any democratic way.
> >>
> >> 1 and 2 are not factors which can be controlled by Fedora, 3 however can. I 
> >> believe its important to fix 3, as that will make joining the government of 
> >> Fedora much more appealing.
> > 
> > Could you elaborate on what you see the problems being?  And possible
> > solutions?
> > 
> 
> Some less spoonfeeding of decisions and more discussion in public instead of 
> presenting pre-cooked proposals the entire circle of power already agrees on, 
> would help greatly here.
> 
> Look at it this way, Fedora is all about Freedom, but since the merger the 
> Freedom for contributers (esp. packagers) has been greatly reduced. Take the 
> new release engineering proposals for example, I have some ideas about this, 
> but the entire release engineering crowd had already precooked there ideas and 
> unanimously disagreed with mine, or atleast that is how I perceived this.

Perhaps I missed this thread somewhere.  Can you point me at it?  As
far as I know, all of the Rel-Eng proposals were drafted by Jesse,
posted on fedora-devel for discussion, and then approved by rel-eng and
then FESCo.

> Most typically of all this I guess is this alinea: This will probably be my 
> last mail in this thread, as I see no use in continuing this dicussion, why?
> Because I no longer believe that discussions like this will cause any changes.

I hope that isn't the case.  I'm genuinely interested in what you're
trying to point out.

josh



From poelstra at redhat.com  Wed Nov 14 21:56:10 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 14 Nov 2007 13:56:10 -0800
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <1195065343.1858.5.camel@nixon>
References: <1195065343.1858.5.camel@nixon>
Message-ID: <473B6EFA.1050001@redhat.com>

Brian Pepple said the following on 11/14/2007 10:35 AM Pacific Time:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
> in #fedora-meeting on irc.freenode.org:
> 
> /topic Misc - Feature Process -
> https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00003.html - poelcat 
> 
> /topic MISC - PPC Secondary Arch? -
> https://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00078.html - f13, dwmw2 
> 
> /topic FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all 
> 
> /topic Status Update: Compat Policy
> http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy
> 
> /topic Status Update: FESCo Proposal Template - f13
> 
> /topic FESCo meeting -- Free discussion around Fedora
> 
> You want something to be discussed? Send a note to the list in reply to
> this mail and I'll add it to the schedule (I can't promise we will get
> to it tomorrow, since we have a pretty full schedule).  You can also
> propose topics in the meeting while it is in the "Free discussion around
> Fedora" phase.

Would also like to discuss the minor changes proposed to bugzilla:
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01161.html

Thanks,
John



From j.w.r.degoede at hhs.nl  Wed Nov 14 21:59:02 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 22:59:02 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114163447.4e86a75e@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>	<20071114131012.6b86c447@weaponx>
	<473B57A4.7010705@hhs.nl> <20071114163447.4e86a75e@redhat.com>
Message-ID: <473B6FA6.2060607@hhs.nl>

Jesse Keating wrote:
> On Wed, 14 Nov 2007 21:16:36 +0100
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Look at it this way, Fedora is all about Freedom, but since the
>> merger the Freedom for contributers (esp. packagers) has been greatly
>> reduced. Take the new release engineering proposals for example, I
>> have some ideas about this, but the entire release engineering crowd
>> had already precooked there ideas and unanimously disagreed with
>> mine, or atleast that is how I perceived this.
>>
>> Most typically of all this I guess is this alinea: This will probably
>> be my last mail in this thread, as I see no use in continuing this
>> dicussion, why? Because I no longer believe that discussions like
>> this will cause any changes.
> 
> Wow, I am somewhat blindsided by this.
> 
> I created the proposal after talking to some people and posted it out
> on the net for review, long before even the rel-eng group voted on it.
> I asked for all kinds of feed back, multiple times.  I had to get the
> releng group to agree to it, and FESCo an opportunity to agree to it.
> There was discussion on list and changes made.  What more were you
> looking for?

Being listened too? Please understand that this is just an example, the problem 
is I entered the discussion, quickly got the idea things were pretty much set 
in stone already, and left the discussion again.

With the big problem here being not rel-eng nor the rel-eng process, but me 
getting the feeling that investing time in decision making discussions is 
useless, as:
1) Things are already pretty much pre-cooked, when you say: "I created the
    proposal after talking to some people". I read "I created the
    proposal after talking to most of rel-eng". Don't get me wrong this is a
    logical thing todo, but if proposals get pre-cooked this way and I disagree
    I get to argue with rel-eng as a whole / as a block, since you already have
    reached a consensus on how things should be done, and even though there may
    have been different opinions in the past, everyone has now adjusted his
    opinion to the consensus (which is a normal thing todo for any human).

2) Because of 1) mainly I guess I do no get the feeling that people are
    actually listening to me.

Regards,

Hans



From fedora at leemhuis.info  Wed Nov 14 21:58:27 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 14 Nov 2007 22:58:27 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114163447.4e86a75e@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>	<20071114131012.6b86c447@weaponx>
	<473B57A4.7010705@hhs.nl> <20071114163447.4e86a75e@redhat.com>
Message-ID: <473B6F83.3000404@leemhuis.info>

On 14.11.2007 22:34, Jesse Keating wrote:
> On Wed, 14 Nov 2007 21:16:36 +0100
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Look at it this way, Fedora is all about Freedom, but since the
>> merger the Freedom for contributers (esp. packagers) has been greatly
>> reduced. Take the new release engineering proposals for example, I
>> have some ideas about this, but the entire release engineering crowd
>> had already precooked there ideas and unanimously disagreed with
>> mine, or atleast that is how I perceived this.
>>
>> Most typically of all this I guess is this alinea: This will probably
>> be my last mail in this thread, as I see no use in continuing this
>> dicussion, why? Because I no longer believe that discussions like
>> this will cause any changes.
> 
> Wow, I am somewhat blindsided by this.
> 
> I created the proposal after talking to some people and posted it out
> on the net for review, long before even the rel-eng group voted on it.
> I asked for all kinds of feed back, multiple times.  I had to get the
> releng group to agree to it, and FESCo an opportunity to agree to it.
> There was discussion on list and changes made.  What more were you
> looking for?

The "Request for Comments: Proposed changes to Fedora development cycle"
for example got posted on "Date: Tue, 16 Oct 2007 10:24:48 -0400" here
https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01206.html

You received feedback from some people, including from Hans, Me and some
others. On "# Date: Fri, 26 Oct 2007 13:52:34 -0400" you in
https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02295.html

announced "Potential changes to Fedora development cycle" with the
words: "The release engineering team as put together a proposed set of
development cycle changes [1] that could affect Fedora 9 development.
This proposed set of changes has been reviewed on fedora-devel-list and
other lists for a period of time and input has been incorporated as
best it could. Now it's coming time for FESCo to vote on adopting the
new development cycle."

I looked in the wiki what actually got changed between the two points of
time; that's afaics from
http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal?action=info

this diff:
http://fedoraproject.org/wiki/ReleaseEngineering/DevelopmentChangesProposal?action=diff&rev2=11&rev1=4

I'd call that some clarifications in the text to make the proposal more
clear. But sorry, I would not call that "input has been incorporated as
best it could."

CU
knurd



From nicolas.mailhot at laposte.net  Wed Nov 14 22:02:17 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Nov 2007 23:02:17 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B6952.20605@gmail.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com>  <473B6952.20605@gmail.com>
Message-ID: <1195077737.8923.1.camel@rousalka.dyndns.org>


Le mercredi 14 novembre 2007 ? 13:32 -0800, Toshio Kuratomi a ?crit :

>  > * Check the spec's encoding
> This also needs human supplementing.  We can check that the spec file is 
> ASCii but how are we to tell that the non-ASCii characters in there are 
> UTF-8 without a human looking at the context?

Many of the legacy 8-bit encoding have common codepoints forbidden in
UTF-8. That's detectable

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/e4bb8209/attachment.sig>

From jkeating at redhat.com  Wed Nov 14 22:01:50 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 17:01:50 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B6FA6.2060607@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
	<20071114131012.6b86c447@weaponx> <473B57A4.7010705@hhs.nl>
	<20071114163447.4e86a75e@redhat.com> <473B6FA6.2060607@hhs.nl>
Message-ID: <20071114170150.0fc7b19d@redhat.com>

On Wed, 14 Nov 2007 22:59:02 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> With the big problem here being not rel-eng nor the rel-eng process,
> but me getting the feeling that investing time in decision making
> discussions is useless, as:
> 1) Things are already pretty much pre-cooked, when you say: "I
> created the proposal after talking to some people". I read "I created
> the proposal after talking to most of rel-eng". Don't get me wrong
> this is a logical thing todo, but if proposals get pre-cooked this
> way and I disagree I get to argue with rel-eng as a whole / as a
> block, since you already have reached a consensus on how things
> should be done, and even though there may have been different
> opinions in the past, everyone has now adjusted his opinion to the
> consensus (which is a normal thing todo for any human).
> 
> 2) Because of 1) mainly I guess I do no get the feeling that people
> are actually listening to me.

No, the people I talked to were mostly packagers, not other rel-eng
people.  I didn't really talk to other rel-eng people until I had the
wiki page up.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/6d64a0c5/attachment.sig>

From dennis at ausil.us  Wed Nov 14 22:07:50 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Wed, 14 Nov 2007 16:07:50 -0600
Subject: build servers kernel release (PPC64)
In-Reply-To: <47387994.7030500@gmail.com>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com>
Message-ID: <200711141607.50983.dennis@ausil.us>

On Monday 12 November 2007, Toshio Kuratomi wrote:
> Robert Marcano wrote:
> > are the build systems servers running the latest F8 kernel? I need the
> > fix of bug 350291 in order to be able to build eclipse-subclipse on
> > ppc64 machines. I am asking because the error still happens and I am not
> > sure if the fix did not work or the server have an outdated kernel?
> >
> > Any help is appreciated
>
> The build systems are currently running FC6.  At the last infrastructure
> meeting we tentatively agreed on upgrading them about 3 weeks from now
> (on the weekend).  We also were leaning towards upgrading them to RHEL5
> at the time.  Do we need to upgrade to F8 instead?
>
> -Toshio

David Woodhouse built a kernel update for FC-6  that I put on the ppc builders 
today that fixes the bug you have referenced.  Please try your build now.  We 
will need to make sure that this gets fixed for RHEL5 also


Dennis



From poelstra at redhat.com  Wed Nov 14 22:15:14 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 14 Nov 2007 14:15:14 -0800
Subject: bugzilla front page wrong (was System-Config-Firewall)
In-Reply-To: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
Message-ID: <473B7372.40008@redhat.com>

J?hann B. Gu?mundsson said the following on 11/14/2007 01:51 PM Pacific Time:

> Ps. Somebody might wanna update the wiki page to mention
>     Werewolf as current maintainded release, and take out Zod
>     ( http://fedoraproject.org/wiki/Releases )
> 

Bugzilla front page too :)

https://bugzilla.redhat.com/

Fedora 7 Now Available

The Fedora Project is pleased to announce the release of Fedora 7 (Moonshine). For a summary of what is new and improved see the Fedora 7 Release Summary.

Not sure which team takes care of this.

John



From fedora at leemhuis.info  Wed Nov 14 22:18:12 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 14 Nov 2007 23:18:12 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B3FA8.70106@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>
Message-ID: <473B7424.3060407@leemhuis.info>

On 14.11.2007 19:34, Hans de Goede wrote:
> Thorsten Leemhuis wrote:
>> And 1108 open reviews in total (including lots of merge reviews (?))
> <snip>
>> I think we have a problem here. I'm actually wondering what FESCo (and
>> the Board) thinks about that.
> Thanks for this Thorsten, I think we as a community needed this kick in the 
> behind, I say we as a community, because I think its unfair to solely blame 
> FESCo, as you write further down your mail, there is currently little community 
> involvement in the governing of Fedora, no contributers other the the members 
> attending FESCo meetings, etc.

Well, the involvement from non-FESCo members in meetings was a lot
better (but still far from perfect) a year ago afaics.

I actually hit the point many months ago where said "okay, I tried to do
lots of stuff without being in FESCo or the Board; but it is way to hard
and I'm wasting my time here". Main reason for that: I posted proposals
to the list, got comments and integrated them into my proposal; some
FESCo members didn't participate in the list discussions but in the
meeting to vote on the porposal those suddenly said "I don't like part
X". So I went back to the drawing board, list discsusion to hear in the
next FESCo meeting just another FESCo member say "I don't like part Y".
I went thought that loop multiple times and that was just frustrating,
so I'm ATM a bit unwilling to do more stuff in Fedora-government land
again before this isn't getting fixed.

With getting fixed I'm not sure how to get that fixed exactly; maybe
work work more towards a Meritocracy-like way and lessen the influence
of the committees we have?


Cu
knurd



From j.w.r.degoede at hhs.nl  Wed Nov 14 22:23:03 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 23:23:03 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114155513.2f16cfd7@weaponx>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>	<20071114131012.6b86c447@weaponx>
	<473B57A4.7010705@hhs.nl> <20071114155513.2f16cfd7@weaponx>
Message-ID: <473B7547.7050806@hhs.nl>

Josh Boyer wrote:
> On Wed, 14 Nov 2007 21:16:36 +0100
> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
>> Josh Boyer wrote:
>>> On Wed, 14 Nov 2007 19:34:16 +0100
>>> Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>>>
>>>> 3) In the extras days I had the feeling of having some control over what FESCo
>>>>     does, today I feel that certain groups within Fedora (*cough* release
>>>>     engineering *cough*) are indepent islands, not that these groups are not
>>>>     doing great work, but they don't seem controlled in any democratic way.
>>>>
>>>> 1 and 2 are not factors which can be controlled by Fedora, 3 however can. I 
>>>> believe its important to fix 3, as that will make joining the government of 
>>>> Fedora much more appealing.
>>> Could you elaborate on what you see the problems being?  And possible
>>> solutions?
>>>
>> Some less spoonfeeding of decisions and more discussion in public instead of 
>> presenting pre-cooked proposals the entire circle of power already agrees on, 
>> would help greatly here.
>>
>> Look at it this way, Fedora is all about Freedom, but since the merger the 
>> Freedom for contributers (esp. packagers) has been greatly reduced. Take the 
>> new release engineering proposals for example, I have some ideas about this, 
>> but the entire release engineering crowd had already precooked there ideas and 
>> unanimously disagreed with mine, or atleast that is how I perceived this.
> 
> Perhaps I missed this thread somewhere.  Can you point me at it?  As
> far as I know, all of the Rel-Eng proposals were drafted by Jesse,
> posted on fedora-devel for discussion, and then approved by rel-eng and
> then FESCo.
> 
>> Most typically of all this I guess is this alinea: This will probably be my 
>> last mail in this thread, as I see no use in continuing this dicussion, why?
>> Because I no longer believe that discussions like this will cause any changes.
> 
> I hope that isn't the case.  I'm genuinely interested in what you're
> trying to point out.
> 

Please see my reply to Jesse's post and also Thorstens reply,

Regards,

Hans



From pertusus at free.fr  Wed Nov 14 22:21:03 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 23:21:03 +0100
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <1195065343.1858.5.camel@nixon>
References: <1195065343.1858.5.camel@nixon>
Message-ID: <20071114222103.GP14241@free.fr>

On Wed, Nov 14, 2007 at 01:35:43PM -0500, Brian Pepple wrote:
> Hi,
> 
> You want something to be discussed? Send a note to the list in reply to
> this mail and I'll add it to the schedule (I can't promise we will get
> to it tomorrow, since we have a pretty full schedule).  You can also
> propose topics in the meeting while it is in the "Free discussion around
> Fedora" phase.

Also, please automate the mailings of multiarch conflicts, it is hard to
test for people without biarch computers.

--
Pat



From dkl at redhat.com  Wed Nov 14 22:22:42 2007
From: dkl at redhat.com (Dave Lawrence)
Date: Wed, 14 Nov 2007 17:22:42 -0500
Subject: bugzilla front page wrong (was System-Config-Firewall)
In-Reply-To: <473B7372.40008@redhat.com>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
	<473B7372.40008@redhat.com>
Message-ID: <473B7532.7030405@redhat.com>

Will be in the next Bugzilla update. Sorry we dropped the ball on this one.

Dave


John Poelstra wrote:
> J?hann B. Gu?mundsson said the following on 11/14/2007 01:51 PM 
> Pacific Time:
>
>> Ps. Somebody might wanna update the wiki page to mention
>>     Werewolf as current maintainded release, and take out Zod
>>     ( http://fedoraproject.org/wiki/Releases )
>>
>
> Bugzilla front page too :)
>
> https://bugzilla.redhat.com/
>
> Fedora 7 Now Available
>
> The Fedora Project is pleased to announce the release of Fedora 7 
> (Moonshine). For a summary of what is new and improved see the Fedora 
> 7 Release Summary.
>
> Not sure which team takes care of this.
>
> John
>

-- 
David Lawrence, RHCE  dkl at redhat.com
------------------------------------
Red Hat, Inc.    Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606




From jkeating at redhat.com  Wed Nov 14 22:24:26 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 17:24:26 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B6F83.3000404@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
	<20071114131012.6b86c447@weaponx> <473B57A4.7010705@hhs.nl>
	<20071114163447.4e86a75e@redhat.com>
	<473B6F83.3000404@leemhuis.info>
Message-ID: <20071114172426.1aa2725b@redhat.com>

On Wed, 14 Nov 2007 22:58:27 +0100
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> You received feedback from some people, including from Hans, Me and
> some others. On "# Date: Fri, 26 Oct 2007 13:52:34 -0400" you in
> https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02295.html

The crux of Hans' complaint as I understand it is that there is an
actual freeze, at all.  That there would ever be a time where a build
done doesn't automatically go into a release.  And I'm sorry, but I
just can't possibly imagine doing any kind of release with any sort of
quality if there wasn't some sort of freeze.  I fought with QA for the
shortest freezes possible for a reasonable release cycle, and that's
what we have in the proposed changes/schedules.  Your QA team would
like even longer freezes.  I'd like you to find any other distribution
that doesn't do some sort of a freeze for a release.

And I took a lot of your input and incorporated it into the proposal,
like weekly snapshots, and discussion of at some point being able to
compose two trees, the pre-release tree and the next rawhide each
night.  Likely can't do that for F9, but looking into the future.  Then
it digressed into arguing about freeze times, and while I appreciate
your opinions, I also have to rely upon my experience of actually doing
the releases and knowing how much time we need with limited tree
changes.  I think there is one clarification that needs to be made, you
at one point asked:

F9 hypothetical schedule: Final Development freeze is 20080408 -- thus
all updates after that point that are *not* release-critical gets tagged
as "updates candidate" afaics (at least that's how I understand it from
the description; please tell me if I got something wrong). Thus
non-critical stuff doesn't make it into the tree for 23 days (release is
scheduled for 20080501).

I should note that during that time we're taking more things in that
just 'release-critical' updates.  We're taking (with review) reasonable
bugfixes.  It's the opportunity for all the groups to look at what
we're proposing as the final package set and look for bugs that should
be fixed.  Once we create the first Release Candidate, that's the point
when we're only taking in release critical fixes.

I should note that even /with/ our review, a few builds slipped in that
broke things pretty badly for the release.  A late rhgb build caused a
lot of boot hangs.  A late selinux-policy build broke selinux.  The
rhpxl build we did late to fix graphical boot broke ps3.  There were a
few more too.  These are all examples why not having review and not
being very critical about every change going into a release can have
very nasty results.

I'd be more than happy to continue discussing why the proposal is the
way it is.  We didn't just pull numbers out of our butts because we
felt like it, there are very real reasons and experiences that have led
us to want a slow down to changes being introduced to the tree, along
with a reasonable enough amount of time to actually create release
candidate trees and validate them before throwing them at the mirrors,
and giving the mirrors enough time to sync up for the release.  Your QA
team wants enough time to sufficiently test the proposed bits for
release without adding new builds to the mix and invalidating tests.

My entire motivation has been to find ways to accomplish the slow down
for the release tree while providing outlets for builds to continue
(and even be tested!).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/ddf0038a/attachment.sig>

From j.w.r.degoede at hhs.nl  Wed Nov 14 22:35:11 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 23:35:11 +0100
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
Message-ID: <473B781F.7040809@hhs.nl>

Hi All,

As outlined here:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers

I would like to declare the xfig maintainer AWOL and take over xfig, does 
anyone know a better way then email to contact Than?

I've been trying to get this bug (with known and included fix) fixed for ages, 
yet it is still present in F-8 (and rawhide):
https://bugzilla.redhat.com/show_bug.cgi?id=201992

Notice that this bug was filed on 2006-08-10 and a fix was known on 2006-11-17, 
  after this I've tried to contact Than once more on 2007-08-17 and 2007-11-04, 
and now a last attempt at 2007-11-14

Regards,

Hans



From j.w.r.degoede at hhs.nl  Wed Nov 14 22:41:37 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 23:41:37 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114172426.1aa2725b@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>	<20071114131012.6b86c447@weaponx>
	<473B57A4.7010705@hhs.nl>	<20071114163447.4e86a75e@redhat.com>	<473B6F83.3000404@leemhuis.info>
	<20071114172426.1aa2725b@redhat.com>
Message-ID: <473B79A1.4000607@hhs.nl>

Jesse Keating wrote:
> On Wed, 14 Nov 2007 22:58:27 +0100
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
>> You received feedback from some people, including from Hans, Me and
>> some others. On "# Date: Fri, 26 Oct 2007 13:52:34 -0400" you in
>> https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02295.html
> 
> The crux of Hans' complaint as I understand it is that there is an
> actual freeze, at all.  That there would ever be a time where a build
> done doesn't automatically go into a release.  And I'm sorry, but I
> just can't possibly imagine doing any kind of release with any sort of
> quality if there wasn't some sort of freeze.  I fought with QA for the
> shortest freezes possible for a reasonable release cycle, and that's
> what we have in the proposed changes/schedules.  Your QA team would
> like even longer freezes.  I'd like you to find any other distribution
> that doesn't do some sort of a freeze for a release.
> 

No the crux of my complaint is there is no way to get packages past the freeze 
(not the last hard one, but the earlier one) without having to go the human ( = 
slow, cumbersome) interaction path.

I understand you don't want builds in the just branched F-x to go into the 
release automatically at this point, for people who may not be fully aware of 
the freeze, but whats wrong with a:
"make build-and-put-it-in-the-collection-despite-the-freeze" make target, so 
that if a maintainer believes this is imporant and save enough to go into the 
release (and he clearly knows about the freeze otherwise he would be just doing 
"make build") can do so without having to jump through hoops?

Regards,

Hans



From jcm at redhat.com  Wed Nov 14 22:41:43 2007
From: jcm at redhat.com (Jon Masters)
Date: Wed, 14 Nov 2007 17:41:43 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <200711121859.32629.dennis@ausil.us>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<200711121859.32629.dennis@ausil.us>
Message-ID: <1195080103.32241.47.camel@perihelion>

On Mon, 2007-11-12 at 18:59 -0600, Dennis Gilmore wrote:

> > 3. It really makes no sense to have a separate top-level directory for
> > the TFTP service.  /tftpboot is a legacy location that should be
> > reconsidered.
> Its a common recognizable default

It's been like that for so long, and it seems unintrusive, I think it
should stay there.

Jon.




From jakub at redhat.com  Wed Nov 14 22:44:30 2007
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 14 Nov 2007 17:44:30 -0500
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
In-Reply-To: <473B781F.7040809@hhs.nl>
References: <473B781F.7040809@hhs.nl>
Message-ID: <20071114224430.GP5451@devserv.devel.redhat.com>

On Wed, Nov 14, 2007 at 11:35:11PM +0100, Hans de Goede wrote:
> As outlined here:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers
> 
> I would like to declare the xfig maintainer AWOL and take over xfig, does 
> anyone know a better way then email to contact Than?
> 
> I've been trying to get this bug (with known and included fix) fixed for 
> ages, yet it is still present in F-8 (and rawhide):
> https://bugzilla.redhat.com/show_bug.cgi?id=201992
> 
> Notice that this bug was filed on 2006-08-10 and a fix was known on 
> 2006-11-17, after this I've tried to contact Than once more on 2007-08-17 
>  and 2007-11-04, and now a last attempt at 2007-11-14

Adding -fno-strict-aliasing without finding out what is the problem
and really fixing the aliasing violation (or in the rare case this
turns out to be a compiler bug coming up with small self-contained
testcase that proves it) is not fixing a bug, merely working around it.

	Jakub



From j.w.r.degoede at hhs.nl  Wed Nov 14 22:49:17 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 14 Nov 2007 23:49:17 +0100
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
In-Reply-To: <20071114224430.GP5451@devserv.devel.redhat.com>
References: <473B781F.7040809@hhs.nl>
	<20071114224430.GP5451@devserv.devel.redhat.com>
Message-ID: <473B7B6D.80501@hhs.nl>

Jakub Jelinek wrote:
> On Wed, Nov 14, 2007 at 11:35:11PM +0100, Hans de Goede wrote:
>> As outlined here:
>> http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers
>>
>> I would like to declare the xfig maintainer AWOL and take over xfig, does 
>> anyone know a better way then email to contact Than?
>>
>> I've been trying to get this bug (with known and included fix) fixed for 
>> ages, yet it is still present in F-8 (and rawhide):
>> https://bugzilla.redhat.com/show_bug.cgi?id=201992
>>
>> Notice that this bug was filed on 2006-08-10 and a fix was known on 
>> 2006-11-17, after this I've tried to contact Than once more on 2007-08-17 
>>  and 2007-11-04, and now a last attempt at 2007-11-14
> 
> Adding -fno-strict-aliasing without finding out what is the problem
> and really fixing the aliasing violation (or in the rare case this
> turns out to be a compiler bug coming up with small self-contained
> testcase that proves it) is not fixing a bug, merely working around it.
> 

Agree,

But it beats a crashing app by a large margin, more over the problem is not 
specifically the bug not being fixed, it is there being no response at all.

Regards,

Hans



From ajackson at redhat.com  Wed Nov 14 23:28:59 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 14 Nov 2007 18:28:59 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1195070540.7660.2.camel@rousalka.dyndns.org>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195061080.6464.9.camel@rousalka.dyndns.org>
	<20071114180849.GA8811@nostromo.devel.redhat.com>
	<1195070540.7660.2.camel@rousalka.dyndns.org>
Message-ID: <1195082939.2292.28.camel@localhost.localdomain>

On Wed, 2007-11-14 at 21:02 +0100, Nicolas Mailhot wrote:
> Le mercredi 14 novembre 2007 ? 13:08 -0500, Bill Nottingham a ?crit :
> > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > Some doc on how to setup input in the brave new hotplug world for
> > > non-qwerty users would be nice.
> > > 
> > > I hereby donate my previous working xorg.conf input sections as an
> > > exemple:
> > 
> > evdev isn't there yet.
> 
> The problem is not evdev, it was working in F8, the problem is how the
> new rawhide xorg moves all the input bits out of xorg.conf and there's
> no documentation I know of on the new input hotplug configuration.

Why yes, that is a problem.

It's also not something I've looked into at all yet.  I would be
thrilled to have contributions in this area, if you're looking for a
project.

- ajax



From jonathan at jonmasters.org  Wed Nov 14 22:52:50 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Wed, 14 Nov 2007 17:52:50 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <80d7e4090711130734u431568e4wd88e240427c0e02a@mail.gmail.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<80d7e4090711130734u431568e4wd88e240427c0e02a@mail.gmail.com>
Message-ID: <1195080770.32241.54.camel@perihelion>

On Tue, 2007-11-13 at 08:34 -0700, Stephen John Smoogen wrote:
> On Nov 13, 2007 6:35 AM, Alan Cox <alan at redhat.com> wrote:
> > On Mon, Nov 12, 2007 at 09:20:28PM -0700, Richi Plana wrote:
> > > On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:jA
> > > > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?

> > /tftpboot is the historical tradition going back about thirty years. Why
> > break every script, every book and every third party management tool ?

> What would be the proper RFC process to go over such a change? As in
> say creating a /srv/fedora/ and start populating it with data or some
> such?

Don't take this personally, but that is absolutely the worst single idea
I have heard so far in this thread. So now we go from saying "ah, let's
move /tftpboot because it's the in thing to move stuff" to "hey! We can
make everything fedora-centric so sysadmins need to relearn everything".

Woooo! :-)

> Or say putting in a notice that we would like to move /tftpboot
> to something else and please give us feedback on how we can accomplish
> this with the least amount of pain, and then putting it to a proper
> engineering group to vote on it?

I vote for just not moving it. It's been around many times the lifetime
of FHS and other "standards", that themselves were based upon what
existed at their inception. If anything these "standards" should be
updated with occasional exceptions, based upon years of reality.

Yeah, I know, this is a very conservative attitude for a change. I guess
we could just throw out the Linux kernel because it's also based on "30
year old technology", but it seems to work well for most of us.

Jon.




From pertusus at free.fr  Wed Nov 14 22:56:34 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Nov 2007 23:56:34 +0100
Subject: setup filesystem requires and minimal system
In-Reply-To: <1195054166.3871.9.camel@localhost.localdomain>
References: <20071114142640.GB14241@free.fr>
	<20071114100212.0a1f1ff1@redhat.com>
	<20071114150923.GD14241@free.fr>
	<1195053281.3871.1.camel@localhost.localdomain>
	<20071114152957.GE14241@free.fr>
	<1195054166.3871.9.camel@localhost.localdomain>
Message-ID: <20071114225634.GQ14241@free.fr>

On Wed, Nov 14, 2007 at 10:29:26AM -0500, Tom spot Callaway wrote:
> 
> Not necessarily that I endorse that sort of crackrock, but I understand
> what you're shooting for.

Since I didn't got that many answers here, I just did some tests and it
works quite well the way it is in fact. Using glibc for basesystem is a
good idea because bash will bring it in and almost everything brings
bash (or /bin/sh) in. So only some particular packages (noarch, no
interpreter) can be installed without filesystem (I also found some very
strange lack of dependency on libc!!!). This leads to a rather long list
on my computer nevertheless, with, for example

man-pages-2.67-1.fc9
mailcap-2.1.25-1.fc8
busybox
ipw2200-firmware-3.0-9
rootfiles-8.1-1.1.1
words-3.0-12.fc7
termcap
control-center-filesystem-2.20.1-6.fc9
emacs-el-22.1-8.fc9

and many doc packages.

So point is that the lack of dependency on the filesystem package cannot
really be overcome.

--
Pat



From pertusus at free.fr  Wed Nov 14 23:07:15 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 15 Nov 2007 00:07:15 +0100
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <1195065343.1858.5.camel@nixon>
References: <1195065343.1858.5.camel@nixon>
Message-ID: <20071114230715.GR14241@free.fr>

On Wed, Nov 14, 2007 at 01:35:43PM -0500, Brian Pepple wrote:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
> in #fedora-meeting on irc.freenode.org:

Another thing a bit personal, but I am the acpi package maintainer, and
I get many unrelated bugs that are related with the acpi subsystem as a
whole. This was, in the past, the meaning of the acpi component. These
bugs are then forgotten. Could please fesco put somebody in CC that can
triage those bugs?

I tried to whine now and then about that issue but there still hasn't be
a right solution.

--
Pat



From seg at haxxed.com  Wed Nov 14 23:06:10 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 14 Nov 2007 17:06:10 -0600
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <473B43A7.4020105@redhat.com>
References: <1195018220.32559.98.camel@localhost> <473ABC3E.9090603@hhs.nl>
	<1195037436.32559.200.camel@localhost> <473B3158.80703@redhat.com>
	<473B43A7.4020105@redhat.com>
Message-ID: <1195081571.32559.219.camel@localhost>

On Wed, 2007-11-14 at 13:51 -0500, Rob Crittenden wrote:
> Rob Crittenden wrote:
> I can't actuallly get far enough to do the auth because the Second Life 
> client is out-of-date.

You should be able to bypass this by using the flag --channel "Second
Life Open Source [Fedora]"

Otherwise I'm going to have to get a new package out...

> Another option is to try the argument -no-verify-ssl-cert.

To Second Life? Doesn't work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/e44d5349/attachment.sig>

From cra at WPI.EDU  Wed Nov 14 23:10:53 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 14 Nov 2007 18:10:53 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195080103.32241.47.camel@perihelion>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<200711121859.32629.dennis@ausil.us>
	<1195080103.32241.47.camel@perihelion>
Message-ID: <20071114231053.GI4926@angus.ind.WPI.EDU>

On Wed, Nov 14, 2007 at 05:41:43PM -0500, Jon Masters wrote:
> > > 3. It really makes no sense to have a separate top-level directory for
> > > the TFTP service.  /tftpboot is a legacy location that should be
> > > reconsidered.
> > Its a common recognizable default
> 
> It's been like that for so long, and it seems unintrusive, I think it
> should stay there.

It only seems unintrusive because you haven't run into any of the 
issues I presented.  I've moved the files to /var/tftp for years to 
get around the limitations of the / filesystem.



From notting at redhat.com  Wed Nov 14 23:13:01 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Nov 2007 18:13:01 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <20071114230715.GR14241@free.fr>
References: <1195065343.1858.5.camel@nixon> <20071114230715.GR14241@free.fr>
Message-ID: <20071114231301.GA20007@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> Another thing a bit personal, but I am the acpi package maintainer, and
> I get many unrelated bugs that are related with the acpi subsystem as a
> whole. This was, in the past, the meaning of the acpi component. These
> bugs are then forgotten. Could please fesco put somebody in CC that can
> triage those bugs?

The simple solution is to just reassign to the kernel, in pretty much
all cases.

Bill



From mclasen at redhat.com  Wed Nov 14 23:13:24 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 14 Nov 2007 18:13:24 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B79A1.4000607@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>	<20071114131012.6b86c447@weaponx>
	<473B57A4.7010705@hhs.nl>	<20071114163447.4e86a75e@redhat.com>
	<473B6F83.3000404@leemhuis.info> <20071114172426.1aa2725b@redhat.com>
	<473B79A1.4000607@hhs.nl>
Message-ID: <1195082004.5083.9.camel@localhost.localdomain>


On Wed, 2007-11-14 at 23:41 +0100, Hans de Goede wrote:

> 
> No the crux of my complaint is there is no way to get packages past the freeze 
> (not the last hard one, but the earlier one) without having to go the human ( = 
> slow, cumbersome) interaction path.

I have done a fair amount of bug-fixing during the freezes and asked for
them to be let through, and while it is a little bit of overhead to
write a three-line email that explains what bug I fixed, what the nature
of the fix is and that I believe it is harmless and worthwhile, I cannot
agree that the process is overly bureaucratic or cumbersome. 

The manual process of writing down a short note why your build should
get in despite the freeze achieves exactly what it is intended to
achieve: it slows down the churn in the tree.

?If we just make this a self-service, use-your-best-judgment make
target, people will always err on the side of getting their stuff in.

Matthias  



From Christian.Iseli at licr.org  Wed Nov 14 23:18:01 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Thu, 15 Nov 2007 00:18:01 +0100
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <473B0EC5.4010708@hhs.nl>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>
	<473B0EC5.4010708@hhs.nl>
Message-ID: <20071115001801.1a39988c@ludwig-alpha.unil.ch>

On Wed, 14 Nov 2007 16:05:41 +0100, Hans de Goede wrote:
> Hmm, Something is wrong:
> 
> Packages not present in the development repo:
> ---
> j dot w dot r dot degoede at hhs dot nl    cvsextras    \
> Library handling decoding of several popular sound file formats
> 
> cvsextras should be SDL_sound, as it correctly is in:
> https://bugzilla.redhat.com/show_bug.cgi?id=355811

Yup, something looks wrong in the pkgdb...

Try:
wget -O bzo.txt "https://admin.fedoraproject.org/pkgdb/acls/bugzilla?tg_format=plain"

and then:
chris: grep cvsextras bzo.txt
Fedora|cvsextras|Library handling decoding of several popular sound file formats|jwrdegoede||
chris: grep SDL_sound bzo.txt
Fedora|SDL_sound|Library handling decoding of several popular sound file formats|jwrdegoede||

					Christian



From Christian.Iseli at licr.org  Wed Nov 14 23:20:01 2007
From: Christian.Iseli at licr.org (Christian Iseli)
Date: Thu, 15 Nov 2007 00:20:01 +0100
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <473B105E.8020904@ioa.s.u-tokyo.ac.jp>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>
	<473B0EC5.4010708@hhs.nl> <473B105E.8020904@ioa.s.u-tokyo.ac.jp>
Message-ID: <20071115002001.509c5bf0@ludwig-alpha.unil.ch>

On Thu, 15 Nov 2007 00:12:30 +0900, Mamoru Tasaka wrote:
> Also I have strange entry:
> 
> Packages not present in the development repo
> --------------------------------------------
> mtasaka at ioa dot s dot u-tokyo dot ac dot jp F-8 \
> A Fast, Enjoyable HTML Parser for Ruby
> 
> cvs admin, would you check what is happening?
> c.f.
> https://bugzilla.redhat.com/show_bug.cgi?id=377631

Looks like some problem in the pkgdb:

wget -O bzo.txt "https://admin.fedoraproject.org/pkgdb/acls/bugzilla?tg_format=plain"

grep F-8 bzo.txt
Fedora|F-8|A Fast, Enjoyable HTML Parser for Ruby|mtasaka||

					Christian



From pertusus at free.fr  Wed Nov 14 23:20:02 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 15 Nov 2007 00:20:02 +0100
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <20071114231301.GA20007@nostromo.devel.redhat.com>
References: <1195065343.1858.5.camel@nixon> <20071114230715.GR14241@free.fr>
	<20071114231301.GA20007@nostromo.devel.redhat.com>
Message-ID: <20071114232002.GS14241@free.fr>

On Wed, Nov 14, 2007 at 06:13:01PM -0500, Bill Nottingham wrote:
> Patrice Dumas (pertusus at free.fr) said: 
> > Another thing a bit personal, but I am the acpi package maintainer, and
> > I get many unrelated bugs that are related with the acpi subsystem as a
> > whole. This was, in the past, the meaning of the acpi component. These
> > bugs are then forgotten. Could please fesco put somebody in CC that can
> > triage those bugs?
> 
> The simple solution is to just reassign to the kernel, in pretty much
> all cases.

I proposed that to the kernel maintainer (well I proposed them to be in
initial CC), but they refused.

--
Pat



From smooge at gmail.com  Wed Nov 14 23:20:33 2007
From: smooge at gmail.com (Stephen John Smoogen)
Date: Wed, 14 Nov 2007 16:20:33 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195080770.32241.54.camel@perihelion>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<80d7e4090711130734u431568e4wd88e240427c0e02a@mail.gmail.com>
	<1195080770.32241.54.camel@perihelion>
Message-ID: <80d7e4090711141520r6d82713bi71a0ec000ef032ef@mail.gmail.com>

On Nov 14, 2007 3:52 PM, Jon Masters <jonathan at jonmasters.org> wrote:
> On Tue, 2007-11-13 at 08:34 -0700, Stephen John Smoogen wrote:
> > On Nov 13, 2007 6:35 AM, Alan Cox <alan at redhat.com> wrote:
> > > On Mon, Nov 12, 2007 at 09:20:28PM -0700, Richi Plana wrote:
> > > > On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:jA
> > > > > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
>
> > > /tftpboot is the historical tradition going back about thirty years. Why
> > > break every script, every book and every third party management tool ?
>
> > What would be the proper RFC process to go over such a change? As in
> > say creating a /srv/fedora/ and start populating it with data or some
> > such?
>
> Don't take this personally, but that is absolutely the worst single idea
> I have heard so far in this thread. So now we go from saying "ah, let's
> move /tftpboot because it's the in thing to move stuff" to "hey! We can
> make everything fedora-centric so sysadmins need to relearn everything".
>
> Woooo! :-)
>

You missed the first part of the sentance. What would be the proper
RFC process for doing something. It doesnt mean that the suggestion is
a good one.. just that instead of some packager doing willynilly what
they want.. how should they approach the problem that gets a proper
technical engineering response.


> > Or say putting in a notice that we would like to move /tftpboot
> > to something else and please give us feedback on how we can accomplish
> > this with the least amount of pain, and then putting it to a proper
> > engineering group to vote on it?
>
> I vote for just not moving it. It's been around many times the lifetime
> of FHS and other "standards", that themselves were based upon what
> existed at their inception. If anything these "standards" should be
> updated with occasional exceptions, based upon years of reality.
>
> Yeah, I know, this is a very conservative attitude for a change. I guess
> we could just throw out the Linux kernel because it's also based on "30
> year old technology", but it seems to work well for most of us.
>

I would probably vote for the same thing. However, there needs to be a
process for making changes or innovations and getting them advertised
in a way that meets the communities needs.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"



From bpepple at fedoraproject.org  Wed Nov 14 23:22:50 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 14 Nov 2007 18:22:50 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <20071114164046.22dbcd96@redhat.com>
References: <1195065343.1858.5.camel@nixon>
	<20071114164046.22dbcd96@redhat.com>
Message-ID: <1195082570.13667.0.camel@kennedy>

On Wed, 2007-11-14 at 16:40 -0500, Jesse Keating wrote:
> Some topics...
> 
> Drop orphans from F8< at some point during F9
> 
> Use Matt Domsch's "doesn't rebuild" bugs as AWOL detection, mark as orphaned at some point in F9, drop in F9+
> 
> Do more frequent conflicts testing, with bugs filed, and use AWOL
> detection from above.
> 
> Approval of proposed F9 Schedule

I'll go ahead and add these.

/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/a01ef36e/attachment.sig>

From jkeating at redhat.com  Wed Nov 14 23:27:38 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Nov 2007 18:27:38 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B79A1.4000607@hhs.nl>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
	<20071114131012.6b86c447@weaponx> <473B57A4.7010705@hhs.nl>
	<20071114163447.4e86a75e@redhat.com>
	<473B6F83.3000404@leemhuis.info>
	<20071114172426.1aa2725b@redhat.com> <473B79A1.4000607@hhs.nl>
Message-ID: <20071114182738.194fca14@redhat.com>

On Wed, 14 Nov 2007 23:41:37 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> No the crux of my complaint is there is no way to get packages past
> the freeze (not the last hard one, but the earlier one) without
> having to go the human ( = slow, cumbersome) interaction path.
> 
> I understand you don't want builds in the just branched F-x to go
> into the release automatically at this point, for people who may not
> be fully aware of the freeze, but whats wrong with a:
> "make build-and-put-it-in-the-collection-despite-the-freeze" make
> target, so that if a maintainer believes this is imporant and save
> enough to go into the release (and he clearly knows about the freeze
> otherwise he would be just doing "make build") can do so without
> having to jump through hoops?

Such a target could open up $EDITOR and allow you to drop some lines
about why you think it's worth putting it in.

But here's something you don't seem to have considered.  You're
supposed to have already tested the build before you request it.  This
means you've seen the build complete, you've installed it somewhere,
you've made sure that what you're trying to fix is actually fixed, and
you've made some assurances that no regressions were introduced.  Kind
of hard to do all of that before you build the package.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/736b886d/attachment.sig>

From marc at mwiriadi.id.au  Wed Nov 14 23:29:15 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Thu, 15 Nov 2007 08:29:15 +0900
Subject: bugzilla front page wrong (was System-Config-Firewall)
In-Reply-To: <473B7372.40008@redhat.com>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
	<473B7372.40008@redhat.com>
Message-ID: <1195082955.1416.6.camel@localhost.localdomain>


On Wed, 2007-11-14 at 14:15 -0800, John Poelstra wrote:
> J?hann B. Gu?mundsson said the following on 11/14/2007 01:51 PM Pacific Time:
> 
> > Ps. Somebody might wanna update the wiki page to mention
> >     Werewolf as current maintainded release, and take out Zod
> >     ( http://fedoraproject.org/wiki/Releases )
> > 

It's been fixed thanks for the heads up.

Cheers,

Marc



From akropel1 at rochester.rr.com  Wed Nov 14 23:33:13 2007
From: akropel1 at rochester.rr.com (Adam Kropelin)
Date: Wed, 14 Nov 2007 18:33:13 -0500
Subject: Improving halt package interaction...
In-Reply-To: <fhdi4e$7on$1@ger.gmane.org>
References: <fhdi4e$7on$1@ger.gmane.org>
Message-ID: <20071114233313.GB27713@mail.kroptech.com>

On Tue, Nov 13, 2007 at 10:13:47PM -0300, Thomas M Steenholdt wrote:
> Hi all...
> 
> I'd like to bring up a suggestion that would make it easier for 
> packagers to modify the halt process, without resorting to changing 
> files owned by other packages.
> 
> [...]
> 
> What do you guys think about this?

I'd be happy to use this feature in Apcupsd. At the moment the best
option we have is to 'sed' our own scripty bits into the system halt
scripts, which is a very impolite thing for a package to do. (As a
result, some of our RPMs require the user to manually insert the 
shutdown code, which in addition to being an annoyance, tends to cause
users to simply skip that step.)

If we had a directory into which our packages could drop a prioritized 
script to be run after mountpoints are made r/o, I believe we'd be able
to completely meet the expectations of our users and be a well-behaved
package at the same time.

--Adam



From akropel1 at rochester.rr.com  Wed Nov 14 23:35:21 2007
From: akropel1 at rochester.rr.com (Adam Kropelin)
Date: Wed, 14 Nov 2007 18:35:21 -0500
Subject: Improving halt package interaction...
In-Reply-To: <473AFE5E.4070303@volny.cz>
References: <fhdi4e$7on$1@ger.gmane.org>
	<20071114034410.GA19700@nostromo.devel.redhat.com>
	<fhepr3$fer$1@ger.gmane.org> <20071114084152.15ce9c7b@redhat.com>
	<473AFE5E.4070303@volny.cz>
Message-ID: <20071114233521.GC27713@mail.kroptech.com>

On Wed, Nov 14, 2007 at 02:55:42PM +0100, Miloslav Trmac wrote:
> Jesse Keating napsal(a):
> > Wouldn't you just make sure that the UPS shut down script is
> > scheduled /after/ the database shut down, and all other critical
> > services?  IE make it close to last in the shutdown schedule.
>
> Ideally, the system should be cleanly shut down (e.g. all file systems
> unmounted) before shutting down the UPS.  Guessing how much time it will
> take to unmount all file systems is non-trivial.
> 	Mirek

Exactly. This isn't an area where you want to guess; the risk is just
too high. The whole purpose of monitoring your UPS to enable a clean
system shutdown is out the window if you then power off the UPS with
your mountpoints still r/w.

--Adam



From bpepple at fedoraproject.org  Wed Nov 14 23:39:21 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 14 Nov 2007 18:39:21 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <20071114222103.GP14241@free.fr>
References: <1195065343.1858.5.camel@nixon> <20071114222103.GP14241@free.fr>
Message-ID: <1195083561.13667.3.camel@kennedy>

On Wed, 2007-11-14 at 23:21 +0100, Patrice Dumas wrote:
> 
> Also, please automate the mailings of multiarch conflicts, it is hard to
> test for people without biarch computers.

I've added it to the schedule to discuss.

/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/1613f12f/attachment.sig>

From yabraham2 at gmail.com  Wed Nov 14 23:41:47 2007
From: yabraham2 at gmail.com (yonas Abraham)
Date: Wed, 14 Nov 2007 18:41:47 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1195003708.2292.13.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195003708.2292.13.camel@localhost.localdomain>
Message-ID: <47324ed80711141541m59876d5ak389935417e0262f5@mail.gmail.com>

On Nov 13, 2007 8:28 PM, Adam Jackson <ajackson at redhat.com> wrote:
> On Mon, 2007-11-05 at 15:30 -0500, Adam Jackson wrote:
> > I plan to rebase the X server to git master a week from today (Monday,
> > November 12), which means the changes should hit rawhide on Tuesday.
>
> Okay, so that didn't happen.  But things are mostly built now, at least
> for the big important core bits.  They should be on their way to a
> mirror near you tomorrow, assuming the rawhide push goes out.
>
> If you're not using radeon/nv/intel, expect that X will break, and that
> you'll need to switch to vesa or fbdev.  If you're using an input driver
> other than keyboard or mouse, expect those devices to stop working.
>
> I'll be cleaning up the rest of the mess as we go.  Please do file bugs
> about any weirdness you encounter (outside of the above known caveats).
>


I did update my Rahwid system, aftder reboot, no more X.

here is the last from /var/log/Xorg.0.log


        ABI class: X.Org XInput driver, version 2.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
        i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
        E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
        965GM, 965GME/GLE, G33, Q35, Q33
(II) Primary Device is: PCI 00 at 00:02:0
(EE) No devices detected.

Fatal server error:
no screens found



I have xorg-x11-server-common-1.4.99.1-0.10.fc9

/yonas



From caillon at redhat.com  Wed Nov 14 23:41:58 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 15 Nov 2007 00:41:58 +0100
Subject: XULRunner in rawhide
In-Reply-To: <473B50BC.7030504@conversis.de>
References: <473AFF3E.1090904@redhat.com> <473B50BC.7030504@conversis.de>
Message-ID: <473B87C6.20605@redhat.com>

Dennis Jacobfeuerborn wrote:
> Martin Stransky wrote:
>> Hello,
>>
>> there's a new package in rawhide, xulrunner
>> (xulrunner-1.9-0.alpha9.3.fc9). This package is supposed to provide
>> gecko-libs instead of Firefox and the plan is to ship Firefox as a pure
>> XUL application and run in by xulrunner.
> 
> Is this really going to work? The Mozilla guys made it clear that they 
> don't want to make Firefox depend on xulrunner as that would limit their 
> ability to push the envelope with firefox. If Fedora wants to make that 
> move wouldn't that eventually require a fork?
> 
> http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/

Um, did you read the article?  Specifically the "What are we doing?" 
opening text and the third bullet point underneath it?



From myfedora at richip.dhs.org  Wed Nov 14 23:45:56 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 14 Nov 2007 16:45:56 -0700
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <1195080770.32241.54.camel@perihelion>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<80d7e4090711130734u431568e4wd88e240427c0e02a@mail.gmail.com>
	<1195080770.32241.54.camel@perihelion>
Message-ID: <1195083956.32077.17.camel@localhost6.localdomain6>

On Wed, 2007-11-14 at 17:52 -0500, Jon Masters wrote:
> I vote for just not moving it. It's been around many times the lifetime
> of FHS and other "standards", that themselves were based upon what
> existed at their inception. If anything these "standards" should be
> updated with occasional exceptions, based upon years of reality.

As a systems administrator, I hate it when things get changed because it
means more work for me. But I wouldn't even begrudge this move because
it solves the bigger problem of "Gee, I need to install a new data
server, but wheretf should I go to place my data
files?! /var/lib/mysql? /var/www/html? /tftpboot? /var/lib/samba?" If
it's going to be /var/lib/, then at the very least put that in the
documentation somewhere. Because, currently, this is what I have
in /var/lib/:

alternatives
cs
dhclient
dovecot
hsqldb
mlocate
nfs
random-seed
samba
setroubleshoot
texmf
webalizer
asterisk
dav
dhcpd
games
logrotate.status
mock
ntp
rpcbind
scrollkeeper
spamassassin
tomcat5
xkb
bluetooth
dbus
dhcpv6
hal
misc
multipath
php
rpm
sepolgen
stateless
tor
yum

and I'm not sure what's supposed to be in them nor how the packages were
split with that and /etc/<package> or /usr/share/<package>

> Yeah, I know, this is a very conservative attitude for a change. I guess
> we could just throw out the Linux kernel because it's also based on "30
> year old technology", but it seems to work well for most of us.

Could we please stop using inaccurate analogies? Asking that we throw
out the Linux kernel is like asking to throw out tftp-server and not at
all like moving data subdirectories. If you must bring in the kernel,
then it would be akin to changing /proc semantics or adding /dev/shm
(which has already happened).

One of the reasons why there has to be a ton of books on Unix system
administration is precisely because a lot of things in the past could
only be gleaned by going through tons of documentation. Believe me, I
can see the stark contrast between then and now ... specifically when it
comes to service configuration. Before I had to trundle through loads of
docs just to find config files. Now it's an easy guess with checking
"rpm -ql <package>" for /etc/ files.

Shared objects files also seem to have come under standardization with
most of the native elf shared objects going into /usr/lib(64)/.

It's a little bit different for server data files, though. Mail spool,
proxy caches, etc. have gotten a little tamer, but there's always room
for improvement.
--

Richi Plana



From michel.sylvan at gmail.com  Thu Nov 15 00:06:55 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Wed, 14 Nov 2007 19:06:55 -0500
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
In-Reply-To: <473B781F.7040809@hhs.nl>
References: <473B781F.7040809@hhs.nl>
Message-ID: <f224c6140711141606n5e1b3373j570ffb08aa06bbcb@mail.gmail.com>

On 14/11/2007, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> Hi All,
>
> As outlined here:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers
>
> I would like to declare the xfig maintainer AWOL and take over xfig, does
> anyone know a better way then email to contact Than?
>
Weird -- Than is still a Red Hat employee, right? Is he working from
an office, or telecommuting? We could probably make use of a backup
contact mechanism for Red Hat employees.


-- 
Michel Salim
http://hircus.jaiku.com/



From s.adam at diffingo.com  Thu Nov 15 00:32:45 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Wed, 14 Nov 2007 19:32:45 -0500
Subject: Claiming gnofract4d
Message-ID: <1195086765.24726.6.camel@Diffingo.localdomain>

Hello,

gnofact4d was orphaned a while ago, and I'd like to take ownership of
it. I've already made the required changes in Package DB and I've
submitted a new SRPM for review since the last change was over a year
ago. The new review requests can be found in bz#383621.

Thanks,
Stewart



From ndbecker2 at gmail.com  Thu Nov 15 00:47:17 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 14 Nov 2007 19:47:17 -0500
Subject: noarch-python-in-64bit-path (rpmlint)
Message-ID: <fhg4um$dap$1@ger.gmane.org>

What should I do about this?

qct-mercurial.noarch: E:
noarch-python-in-64bit-path /usr/lib64/python2.5/site-packages/hgext/qct.pyc

I think qct.py needs to go there, because that's where mercurial is going to
look.  As we discussed before, our multi-arch python is somewhat broken,
because you cannot have both /usr/lib/python/.../some_package
and /usr/lib64/python/.../some_package.  It will only search one of those
locations.  So we cannot have both arch and nonarch site-packages/hgext -
unless maybe I'm misunderstanding something?

So, my thought is that this rpmlint error is just ignorable?



From katzj at redhat.com  Thu Nov 15 01:30:52 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 14 Nov 2007 20:30:52 -0500
Subject: noarch-python-in-64bit-path (rpmlint)
In-Reply-To: <fhg4um$dap$1@ger.gmane.org>
References: <fhg4um$dap$1@ger.gmane.org>
Message-ID: <473BA14C.9010707@redhat.com>

Neal Becker wrote:
> What should I do about this?
> 
> qct-mercurial.noarch: E:
> noarch-python-in-64bit-path /usr/lib64/python2.5/site-packages/hgext/qct.pyc
> 
> I think qct.py needs to go there, because that's where mercurial is going to
> look.  As we discussed before, our multi-arch python is somewhat broken,
> because you cannot have both /usr/lib/python/.../some_package
> and /usr/lib64/python/.../some_package.  It will only search one of those
> locations.  So we cannot have both arch and nonarch site-packages/hgext -
> unless maybe I'm misunderstanding something?

If it needs to be in the arch-specific path, the package needs to be 
built for the native arch and not noarch

Jeremy



From michael.wiktowy at gmail.com  Thu Nov 15 01:45:05 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Wed, 14 Nov 2007 20:45:05 -0500
Subject: SELinux Troubleshooter messages from upgrade from F7->F8
In-Reply-To: <473B1D6E.4080701@redhat.com>
References: <3e4ec4600711101123n3ca28c9va454a2566f089bb8@mail.gmail.com>
	<3e4ec4600711120353x6025c92fx462c2ffc8107f0b7@mail.gmail.com>
	<4738491D.1040903@warmcat.com>
	<3e4ec4600711120616g4e38805dw99b65718184bd38c@mail.gmail.com>
	<473B1D6E.4080701@redhat.com>
Message-ID: <3e4ec4600711141745j3381df3fq7e369e90088ba135@mail.gmail.com>

On Nov 14, 2007 11:08 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> Michael Wiktowy wrote:
> > On Nov 12, 2007 7:37 AM, Andy Green <andy at warmcat.com> wrote:
> >> # ll /var/cache/ldconfig -Zd
> >> drwx------  root root system_u:object_r:ldconfig_cache_t /var/cache/ldconfig
> > It matches this ... now ... I did not check right after the upgrade
> > though. The selinux-policy package have been updated since then so it
> > is possible that this could have been corrected already.
> I think that upgrade was happening out of order.  For example if
> ldconfig upgraded before selinux policy, then you would see failures
> like you saw above.  When the selinux policy package upgraded, it would
> clean up the labeling.
>
> I guess it would be advisable to upgrade selinux-policy before doing a
> generate yum upgrade.

Should that be something that yum does or something particular to an
upgrade and should just be a noted in the wiki?
Are you ever going to have stuff in the post install scripts of
selinux-policy that must be completed before other packages can get
updates cleanly?
I suppose the kernel gets special treatment by yum so there is some
precident for particular important packages.

/Mike



From sundaram at fedoraproject.org  Thu Nov 15 01:44:47 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Nov 2007 07:14:47 +0530
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <1195065343.1858.5.camel@nixon>
References: <1195065343.1858.5.camel@nixon>
Message-ID: <473BA48F.8050106@fedoraproject.org>

Brian Pepple wrote:
> Hi,
> 
> Please find below the list of topics that are likely to come up in the
> next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
> in #fedora-meeting on irc.freenode.org:
> 
> /topic Misc - Feature Process -
> https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00003.html - poelcat 

Is there going to be a explicit call for new proposals for Fedora 9 
release preferably to fedora-devel-announce list and fedora-devel list too?

Was FESCo mailing list archive being opened discussed? What's the 
decision on that?

Rahul



From sundaram at fedoraproject.org  Thu Nov 15 02:33:22 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Nov 2007 08:03:22 +0530
Subject: is there GUI tools to change partition label?
In-Reply-To: <472ABD93.1010509@gmail.com>
References: <472ABD93.1010509@gmail.com>
Message-ID: <473BAFF2.40000@fedoraproject.org>

Ken YANG wrote:
> 
> hi all,
> 
> 
> we know e2label can change partition label, but
> i found gparted can not change partition label.
> 
> are there some GUI tools to change partition label?

Probably a RFE for fwfstab.

Rahul



From jwboyer at gmail.com  Thu Nov 15 02:42:23 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Nov 2007 20:42:23 -0600
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <473BA48F.8050106@fedoraproject.org>
References: <1195065343.1858.5.camel@nixon>
	<473BA48F.8050106@fedoraproject.org>
Message-ID: <20071114204223.5c7fe98c@vader.jdub.homelinux.org>

On Thu, 15 Nov 2007 07:14:47 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> Was FESCo mailing list archive being opened discussed? What's the 
> decision on that?

It was discussed.  The decision was to leave it closed.

josh



From sundaram at fedoraproject.org  Thu Nov 15 02:42:18 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Nov 2007 08:12:18 +0530
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <20071114204223.5c7fe98c@vader.jdub.homelinux.org>
References: <1195065343.1858.5.camel@nixon>	<473BA48F.8050106@fedoraproject.org>
	<20071114204223.5c7fe98c@vader.jdub.homelinux.org>
Message-ID: <473BB20A.5000000@fedoraproject.org>

Josh Boyer wrote:
> On Thu, 15 Nov 2007 07:14:47 +0530
> Rahul Sundaram  wrote:
> 
>> Was FESCo mailing list archive being opened discussed? What's the 
>> decision on that?
> 
> It was discussed.  The decision was to leave it closed.

Why?

Rahul



From bbbush.yuan at gmail.com  Thu Nov 15 02:56:03 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Thu, 15 Nov 2007 10:56:03 +0800
Subject: rawhide report: 20071114 changes
In-Reply-To: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
References: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
Message-ID: <76e72f800711141856h57322c6flf487d4383743a631@mail.gmail.com>

a little bug in compiz-manager

[yuan at mstar ~]$ grep intel_drv\.so /var/log/Xorg.0.log
(II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so

 58 # For detecting what driver is in use, the + is for one or more /'s
 59 XORG_DRIVER_PATH="/usr/$ARCH_LIB/xorg/modules//drivers/+"


[yuan at mstar ~]$ rpm -q compiz-manager
compiz-manager-0.6.0-3.fc9
[yuan at mstar ~]$ rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.4.99.1-0.10.fc9



-- 
bbbush ^_^



From katzj at redhat.com  Thu Nov 15 02:57:36 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 14 Nov 2007 21:57:36 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <473BB20A.5000000@fedoraproject.org>
References: <1195065343.1858.5.camel@nixon>	<473BA48F.8050106@fedoraproject.org>	<20071114204223.5c7fe98c@vader.jdub.homelinux.org>
	<473BB20A.5000000@fedoraproject.org>
Message-ID: <473BB5A0.7030904@redhat.com>

Rahul Sundaram wrote:
> Josh Boyer wrote:
>> On Thu, 15 Nov 2007 07:14:47 +0530
>> Rahul Sundaram  wrote:
>>> Was FESCo mailing list archive being opened discussed? What's the 
>>> decision on that?
>>
>> It was discussed.  The decision was to leave it closed.
> 
> Why?

Because people have sent things to the list with the expectation that 
it's not a public list.  Opening up the archives therefore exposes those 
mails to the world against the expectations of the people who sent mail.

Jeremy



From sundaram at fedoraproject.org  Thu Nov 15 02:59:08 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Nov 2007 08:29:08 +0530
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <473BB5A0.7030904@redhat.com>
References: <1195065343.1858.5.camel@nixon>	<473BA48F.8050106@fedoraproject.org>	<20071114204223.5c7fe98c@vader.jdub.homelinux.org>	<473BB20A.5000000@fedoraproject.org>
	<473BB5A0.7030904@redhat.com>
Message-ID: <473BB5FC.4040108@fedoraproject.org>

Jeremy Katz wrote:
> Rahul Sundaram wrote:
>> Josh Boyer wrote:
>>> On Thu, 15 Nov 2007 07:14:47 +0530
>>> Rahul Sundaram  wrote:
>>>> Was FESCo mailing list archive being opened discussed? What's the 
>>>> decision on that?
>>>
>>> It was discussed.  The decision was to leave it closed.
>>
>> Why?
> 
> Because people have sent things to the list with the expectation that 
> it's not a public list.  Opening up the archives therefore exposes those 
> mails to the world against the expectations of the people who sent mail.

I did not ask for the archives in the past to be opened up but for it to 
be open from now on. The list itself seems to be hidden as I can't find 
it and it isn't listed anywhere that I am aware of.

Rahul



From katzj at redhat.com  Thu Nov 15 03:18:27 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 14 Nov 2007 22:18:27 -0500
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <473BB5FC.4040108@fedoraproject.org>
References: <1195065343.1858.5.camel@nixon>	<473BA48F.8050106@fedoraproject.org>	<20071114204223.5c7fe98c@vader.jdub.homelinux.org>	<473BB20A.5000000@fedoraproject.org>	<473BB5A0.7030904@redhat.com>
	<473BB5FC.4040108@fedoraproject.org>
Message-ID: <473BBA83.9040706@redhat.com>

Rahul Sundaram wrote:
> Jeremy Katz wrote:
>> Rahul Sundaram wrote:
>>> Josh Boyer wrote:
>>>> On Thu, 15 Nov 2007 07:14:47 +0530
>>>> Rahul Sundaram  wrote:
>>>>> Was FESCo mailing list archive being opened discussed? What's the 
>>>>> decision on that?
>>>>
>>>> It was discussed.  The decision was to leave it closed
>>>
>>> Why?
>>
>> Because people have sent things to the list with the expectation that 
>> it's not a public list.  Opening up the archives therefore exposes 
>> those mails to the world against the expectations of the people who 
>> sent mail.
> 
> I did not ask for the archives in the past to be opened up but for it to 
> be open from now on. The list itself seems to be hidden as I can't find 
> it and it isn't listed anywhere that I am aware of.

Opening them up from now on would basically require either
a) nuking the archives that already exist (which may or may not be doable)
b) creating a whole new list

It's just not worth the pain when the only things the list is really 
used for are regrets about missing the meeting and wiki watch on the 
schedule page

Jeremy



From cweyl at alumni.drew.edu  Thu Nov 15 03:26:09 2007
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 14 Nov 2007 19:26:09 -0800
Subject: rpms/915resolution/devel 965GM.patch, NONE,
	1.1 915resolution.spec, 1.11, 1.12
In-Reply-To: <1195069882.2292.26.camel@localhost.localdomain>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
	<1195018582.3036.2.camel@tuxhugs>
	<7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>
	<20071114171105.GA5782@nostromo.devel.redhat.com>
	<1195069882.2292.26.camel@localhost.localdomain>
Message-ID: <7dd7ab490711141926m2af3fad4j41c3543d1f7efb08@mail.gmail.com>

On Nov 14, 2007 11:51 AM, Adam Jackson <ajackson at redhat.com> wrote:
> On Wed, 2007-11-14 at 12:11 -0500, Bill Nottingham wrote:
> > Chris Weyl (cweyl at alumni.drew.edu) said:
> > > > Err, I'm presuming that this was unintentional? :)
> > >
> > > Yes, thanks :)
> >
> > If I may ask, what's the point of this in the devel
> > branch, where we don't actually use the BIOS?
>
> Seriously.  F9 won't have the i810 driver anymore.  915resolution can
> die now.

I suspect there will be few people happier than I when that finally
happens.  However, this was also supposed to happen for FC-6, so I
trust you won't object too much when want to see it first :)

                               -Chris
-- 
Chris Weyl
Ex astris, scientia



From dakingun at gmail.com  Thu Nov 15 03:30:51 2007
From: dakingun at gmail.com (Deji Akingunola)
Date: Wed, 14 Nov 2007 22:30:51 -0500
Subject: New firefox-2.0.0.9 in F7/F8/Rawhide
In-Reply-To: <47305027.3030904@redhat.com>
References: <47305027.3030904@redhat.com>
Message-ID: <b80014de0711141930s21bd75fga9b82588d2ac908@mail.gmail.com>

On Nov 6, 2007 6:29 AM, Martin Stransky <stransky at redhat.com> wrote:
> There's a new firefox 2.0.0.9 (gecko-libs 1.8.1.9) in Fedora build
> roots. Please rebuild your packages.
>
Packages built against firefox 2.0.0.9 (e.g. gnomesword) are starting
to get into F-8 stable updates, but this version of firefox itself is
not available there, causing the app to fail at runtime. I wonder if
I'd missed any coordinated effort to get it and its dependencies
pushed at the same time.
Please get it into the updates repo as soon as you can. Thanks

Deji



From katzj at redhat.com  Thu Nov 15 03:32:25 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 14 Nov 2007 22:32:25 -0500
Subject: rpms/915resolution/devel 965GM.patch, NONE,
 1.1 915resolution.spec, 1.11, 1.12
In-Reply-To: <7dd7ab490711141926m2af3fad4j41c3543d1f7efb08@mail.gmail.com>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>	<1195018582.3036.2.camel@tuxhugs>	<7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>	<20071114171105.GA5782@nostromo.devel.redhat.com>	<1195069882.2292.26.camel@localhost.localdomain>
	<7dd7ab490711141926m2af3fad4j41c3543d1f7efb08@mail.gmail.com>
Message-ID: <473BBDC9.9000800@redhat.com>

Chris Weyl wrote:
> On Nov 14, 2007 11:51 AM, Adam Jackson <ajackson at redhat.com> wrote:
>> On Wed, 2007-11-14 at 12:11 -0500, Bill Nottingham wrote:
>>> Chris Weyl (cweyl at alumni.drew.edu) said:
>>>>> Err, I'm presuming that this was unintentional? :)
>>>> Yes, thanks :)
>>> If I may ask, what's the point of this in the devel
>>> branch, where we don't actually use the BIOS?
>> Seriously.  F9 won't have the i810 driver anymore.  915resolution can
>> die now.
> 
> I suspect there will be few people happier than I when that finally
> happens.  However, this was also supposed to happen for FC-6, so I
> trust you won't object too much when want to see it first :)

The driver was there in FC6 and F7, just not enabled by default except 
for known working chips.  With F8, most Intel hardware should be 
defaulted to the modesetting driver.  And as of rawhide today, the i810 
driver is gone, gone, gone :)

* Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 2.1.99-1
- xf86-video-intel 2.1.99.
- Drop the i810 driver.  Time to move on.
- Require xserver 1.4.99.1

Jeremy



From cweyl at alumni.drew.edu  Thu Nov 15 03:44:00 2007
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 14 Nov 2007 19:44:00 -0800
Subject: rpms/915resolution/devel 965GM.patch, NONE,
	1.1 915resolution.spec, 1.11, 1.12
In-Reply-To: <473BBDC9.9000800@redhat.com>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
	<1195018582.3036.2.camel@tuxhugs>
	<7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>
	<20071114171105.GA5782@nostromo.devel.redhat.com>
	<1195069882.2292.26.camel@localhost.localdomain>
	<7dd7ab490711141926m2af3fad4j41c3543d1f7efb08@mail.gmail.com>
	<473BBDC9.9000800@redhat.com>
Message-ID: <7dd7ab490711141944p644dba7fva070d9ad2cd306c2@mail.gmail.com>

On Nov 14, 2007 7:32 PM, Jeremy Katz <katzj at redhat.com> wrote:
>
> Chris Weyl wrote:
> > On Nov 14, 2007 11:51 AM, Adam Jackson <ajackson at redhat.com> wrote:
> >> On Wed, 2007-11-14 at 12:11 -0500, Bill Nottingham wrote:
> >>> Chris Weyl (cweyl at alumni.drew.edu) said:
> >>>>> Err, I'm presuming that this was unintentional? :)
> >>>> Yes, thanks :)
> >>> If I may ask, what's the point of this in the devel
> >>> branch, where we don't actually use the BIOS?
> >> Seriously.  F9 won't have the i810 driver anymore.  915resolution can
> >> die now.
> >
> > I suspect there will be few people happier than I when that finally
> > happens.  However, this was also supposed to happen for FC-6, so I
> > trust you won't object too much when want to see it first :)
>
> The driver was there in FC6 and F7, just not enabled by default except
> for known working chips.  With F8, most Intel hardware should be
> defaulted to the modesetting driver.  And as of rawhide today, the i810
> driver is gone, gone, gone :)
>
> * Tue Nov 13 2007 Adam Jackson <ajax at redhat.com> 2.1.99-1
> - xf86-video-intel 2.1.99.
> - Drop the i810 driver.  Time to move on.
> - Require xserver 1.4.99.1

I'm sold!  What's the latest (heh) procedure for taking a package out
back and shooting it?

                           -Chris
-- 
Chris Weyl
Ex astris, scientia



From kevin at scrye.com  Thu Nov 15 03:53:44 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 14 Nov 2007 20:53:44 -0700
Subject: rpms/915resolution/devel 965GM.patch, NONE, 1.1
 915resolution.spec, 1.11, 1.12
In-Reply-To: <7dd7ab490711141944p644dba7fva070d9ad2cd306c2@mail.gmail.com>
References: <200711140511.lAE5Bo7a011937@cvs-int.fedora.redhat.com>
	<1195018582.3036.2.camel@tuxhugs>
	<7dd7ab490711140858x2776519ao61385d3181fde765@mail.gmail.com>
	<20071114171105.GA5782@nostromo.devel.redhat.com>
	<1195069882.2292.26.camel@localhost.localdomain>
	<7dd7ab490711141926m2af3fad4j41c3543d1f7efb08@mail.gmail.com>
	<473BBDC9.9000800@redhat.com>
	<7dd7ab490711141944p644dba7fva070d9ad2cd306c2@mail.gmail.com>
Message-ID: <20071114205344.1dfd5603@ghistelwchlohm.scrye.com>

On Wed, 14 Nov 2007 19:44:00 -0800
cweyl at alumni.drew.edu ("Chris Weyl") wrote:

> I'm sold!  What's the latest (heh) procedure for taking a package out
> back and shooting it?

http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife

>                            -Chris

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071114/62ce366b/attachment.sig>

From mharris at mharris.ca  Thu Nov 15 04:29:38 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Wed, 14 Nov 2007 23:29:38 -0500
Subject: Bugzilla Versions :: Request for Community & FESCo review
In-Reply-To: <473B6E47.7090004@redhat.com>
References: <473B6E47.7090004@redhat.com>
Message-ID: <473BCB32.2050804@mharris.ca>

John Poelstra wrote:
> The Fedora QA team voted today to simply the displayed Fedora Versions 
> in Bugzilla.  We would like a vote by FESCo on 2007-11-15 to proceed 
> with the changes outlined below. 
> These changes should reduce confusion and help us to simply our bug 
> tracking efforts while complementing the new release process (no test 
> releases).

s/simply/simplify/g

> 2) Change the version of "devel" to "rawhide" to be consistent with new 
> naming convention

Aha, so 'rawhide' makes it's grand comeback now in official capacity!  ;o)

>            6) Bonus points if we can disable the ability to file new 
> bugs against releases that are no longer supported, for example, FC(1..5).

That could have negative side effects.  People file bug reports against 
old releases which may well still be bugs in currently supported 
releases.  By removing the older release versions from bugzilla so that 
people can't file bug reports against them, it could simply create 
additional confusion/frustration for users.

They might decide to file their bug anyway, but pick a newer version 
number because the version they are looking for isn't there, and they 
may or may not state "I couldn't find Fedora 5 in the list, so I chose 8 
instead."

It might be better to allow filing bugs for releases released in the 
last 'n' years, where n is chosen in such a way that it doesn't upset 
large numbers of existing users of EOL releases in such a way that they 
go running for Ubuntu/Debian/etc.

If incoming bugs for EOL'd products are a major problem, it is probably 
worth exploring other options to solve the core problem that it creates 
rather than just blindly removing the version numbers from bugzilla, 
which could be seen as sweeping the problem under the carpet. ;o)


-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From s.adam at diffingo.com  Thu Nov 15 04:26:55 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Wed, 14 Nov 2007 23:26:55 -0500
Subject: is there GUI tools to change partition label?
In-Reply-To: <473BAFF2.40000@fedoraproject.org>
References: <472ABD93.1010509@gmail.com>  <473BAFF2.40000@fedoraproject.org>
Message-ID: <1195100815.6853.0.camel@Diffingo.localdomain>


On Thu, 2007-11-15 at 08:03 +0530, Rahul Sundaram wrote:
> Ken YANG wrote:
> > 
> > hi all,
> > 
> > 
> > we know e2label can change partition label, but
> > i found gparted can not change partition label.
> > 
> > are there some GUI tools to change partition label?
> 
> Probably a RFE for fwfstab.
> 
> Rahul
Hi,

That's a really good idea! I'll make a note to add that when I get the
time.

Regards,
Stewart




From jonathan at jonmasters.org  Thu Nov 15 07:41:35 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 15 Nov 2007 02:41:35 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <20071114231053.GI4926@angus.ind.WPI.EDU>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<200711121859.32629.dennis@ausil.us>
	<1195080103.32241.47.camel@perihelion>
	<20071114231053.GI4926@angus.ind.WPI.EDU>
Message-ID: <1195112496.32241.117.camel@perihelion>

On Wed, 2007-11-14 at 18:10 -0500, Chuck Anderson wrote:
> On Wed, Nov 14, 2007 at 05:41:43PM -0500, Jon Masters wrote:
> > > > 3. It really makes no sense to have a separate top-level directory for
> > > > the TFTP service.  /tftpboot is a legacy location that should be
> > > > reconsidered.
> > > Its a common recognizable default
> > 
> > It's been like that for so long, and it seems unintrusive, I think it
> > should stay there.
> 
> It only seems unintrusive because you haven't run into any of the 
> issues I presented.  I've moved the files to /var/tftp for years to 
> get around the limitations of the / filesystem.

Yup, that's right, because I didn't used to build embedded devices for a
living, so clearly I wouldn't understand...

Anyway. I read your email, and I actually understood it, but I still
don't think the *default* should be changed. It's just a configuration
value, and it is possible to change it if you really find a need to. I
am not saying you haven't experienced problems with the default on some
systems, with a read only root or any number of other factors.

Jon.




From jonathan at jonmasters.org  Thu Nov 15 07:43:02 2007
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 15 Nov 2007 02:43:02 -0500
Subject: /tftpboot vs. /var/tftp vs. something else?
In-Reply-To: <80d7e4090711141520r6d82713bi71a0ec000ef032ef@mail.gmail.com>
References: <20071113004637.GY4926@angus.ind.WPI.EDU>
	<20071113010910.GC2651@free.fr> <47391DEF.7060508@redhat.com>
	<1194927628.6083.3.camel@localhost6.localdomain6>
	<20071113133511.GE16446@devserv.devel.redhat.com>
	<80d7e4090711130734u431568e4wd88e240427c0e02a@mail.gmail.com>
	<1195080770.32241.54.camel@perihelion>
	<80d7e4090711141520r6d82713bi71a0ec000ef032ef@mail.gmail.com>
Message-ID: <1195112582.32241.120.camel@perihelion>


On Wed, 2007-11-14 at 16:20 -0700, Stephen John Smoogen wrote:
> On Nov 14, 2007 3:52 PM, Jon Masters <jonathan at jonmasters.org> wrote:
> > On Tue, 2007-11-13 at 08:34 -0700, Stephen John Smoogen wrote:
> > > On Nov 13, 2007 6:35 AM, Alan Cox <alan at redhat.com> wrote:
> > > > On Mon, Nov 12, 2007 at 09:20:28PM -0700, Richi Plana wrote:
> > > > > On Mon, 2007-11-12 at 22:45 -0500, Warren Togami wrote:jA
> > > > > > Edubuntu is using /var/lib/tftp as their tftpdir.  Should we use it as well?
> >
> > > > /tftpboot is the historical tradition going back about thirty years. Why
> > > > break every script, every book and every third party management tool ?
> >
> > > What would be the proper RFC process to go over such a change? As in
> > > say creating a /srv/fedora/ and start populating it with data or some
> > > such?
> >
> > Don't take this personally, but that is absolutely the worst single idea
> > I have heard so far in this thread. So now we go from saying "ah, let's
> > move /tftpboot because it's the in thing to move stuff" to "hey! We can
> > make everything fedora-centric so sysadmins need to relearn everything".
> >
> > Woooo! :-)
> >
> 
> You missed the first part of the sentance. What would be the proper
> RFC process for doing something. It doesnt mean that the suggestion is
> a good one.. just that instead of some packager doing willynilly what
> they want.. how should they approach the problem that gets a proper
> technical engineering response.

Ah. I read into that *too* much. I parsed it as "and I want to do this".
But I'm actually /completely/ in favor of having a well defined RFC
process for additions to FHS, and I admit that I don't know what that is
in this case. By all means, let's have the discussion :-)

Jon.




From lordmorgul at gmail.com  Thu Nov 15 07:53:03 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Wed, 14 Nov 2007 23:53:03 -0800
Subject: kernel RPMs dependency on removing prior kernel?
Message-ID: <473BFADF.5080808@gmail.com>

Is the following kernel RPM behavior really necessary?  Yum repeatedly attempts
to remove at least one kernel whenever a kernel is updated or installed, and
fails if it cannot do so...  Removing a kernel to keep things a little cleaner
with kernel updates is not so bad, but continuing when it cannot do that is what
I'd want it to do (not fail).  I want these installed kernels, and I want them
staying right where they are, with the nvidia modules as well (these kernels all
have a buggy behavior with my usb drive and I'm keeping them to go back and test
if it gets resolved later).

Why cannot the RPM continue if removing a kernel fails?  And why is it
attempting to remove my NEWEST other kernel (the currently running/working one)?
 Wouldn't it be best to have the currently running kernel stay where it is with
an update or install irregardless of whether another prior kernel had been removed?

I never want a kernel rpm installing itself to remove my running kernel, so why
would this (2.6.23.1-42) dependency even get listed?

22:35:38  |root:1| |13 files:69M@~| |0 jobs|
 - yum install kernel.i686
 Loading "refresh-updatesd" plugin
 fedora                    100% |=========================| 2.1 kB    00:00
 livna-development         100% |=========================| 2.1 kB    00:00
 updates-testing           100% |=========================| 2.3 kB    00:00
 livna                     100% |=========================| 2.1 kB    00:00
 updates                   100% |=========================| 2.3 kB    00:00
 Setting up Install Process
 Parsing package install arguments
 Package kernel - 2.6.23.1-42.fc8.i686 is already installed.
 Resolving Dependencies
 --> Running transaction check
 --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
kmod-nvidia-2.6.23.1-42.fc8
 ---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
 --> Finished Dependency Resolution
 --> Running transaction check
 ---> Package kernel.i686 0:2.6.23.1-41.fc8 set to be erased
 --> Processing Dependency: kernel-i686 = 2.6.23.1-41.fc8 for package:
kmod-nvidia-2.6.23.1-41.fc8
 ---> Package kernel.i686 0:2.6.23-6.fc8 set to be erased
 --> Processing Dependency: kernel-i686 = 2.6.23-6.fc8 for package:
kmod-nvidia-2.6.23-6.fc8
 --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
kmod-nvidia-2.6.23.1-42.fc8
 ---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be installed
 ---> Package kernel.i686 0:2.6.23.1-37.fc8 set to be erased
 --> Processing Dependency: kernel-i686 = 2.6.23.1-37.fc8 for package:
kmod-nvidia-2.6.23.1-37.fc8
 --> Running transaction check
 ---> Package kmod-nvidia-2.6.23-6.fc8.i686 0:100.14.19-8.lvn8 set to be erased
 --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
kmod-nvidia-2.6.23.1-42.fc8
 ---> Package kmod-nvidia-2.6.23.1-37.fc8.i686 0:100.14.19-14.lvn8 set to be erased
 ---> Package kmod-nvidia-2.6.23.1-41.fc8.i686 0:100.14.19-15.lvn8 set to be erased
 --> Finished Dependency Resolution
 Error: Missing Dependency: kernel-i686 = 2.6.23.1-42.fc8 is needed by package
kmod-nvidia-2.6.23.1-42.fc8

22:32:47  |root:1| |13 files:69M@~| |0 jobs|
 - cat /proc/version
 Linux version 2.6.23.1-42.fc8 (kojibuilder at xenbuilder4.fedora.phx.redhat.com)
(gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Tue Oct 30 13:55:12 EDT 2007

 22:35:25  |root:1| |13 files:69M@~| |0 jobs|
  - rpm -q kernel
  kernel-2.6.23-6.fc8
  kernel-2.6.23.1-37.fc8
  kernel-2.6.23.1-41.fc8
  kernel-2.6.23.1-42.fc8

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From j.w.r.degoede at hhs.nl  Thu Nov 15 08:00:43 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 15 Nov 2007 09:00:43 +0100
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <20071115001801.1a39988c@ludwig-alpha.unil.ch>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>	<473B0EC5.4010708@hhs.nl>
	<20071115001801.1a39988c@ludwig-alpha.unil.ch>
Message-ID: <473BFCAB.4040600@hhs.nl>

Christian Iseli wrote:
> On Wed, 14 Nov 2007 16:05:41 +0100, Hans de Goede wrote:
>> Hmm, Something is wrong:
>>
>> Packages not present in the development repo:
>> ---
>> j dot w dot r dot degoede at hhs dot nl    cvsextras    \
>> Library handling decoding of several popular sound file formats
>>
>> cvsextras should be SDL_sound, as it correctly is in:
>> https://bugzilla.redhat.com/show_bug.cgi?id=355811
> 
> Yup, something looks wrong in the pkgdb...
> 
> Try:
> wget -O bzo.txt "https://admin.fedoraproject.org/pkgdb/acls/bugzilla?tg_format=plain"
> 
> and then:
> chris: grep cvsextras bzo.txt
> Fedora|cvsextras|Library handling decoding of several popular sound file formats|jwrdegoede||
> chris: grep SDL_sound bzo.txt
> Fedora|SDL_sound|Library handling decoding of several popular sound file formats|jwrdegoede||
> 

Ok,

Who do I contact about this?

Regards,

Hans




From jcm at redhat.com  Thu Nov 15 08:05:21 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 15 Nov 2007 03:05:21 -0500
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473BFADF.5080808@gmail.com>
References: <473BFADF.5080808@gmail.com>
Message-ID: <1195113922.32241.140.camel@perihelion>


On Wed, 2007-11-14 at 23:53 -0800, Andrew Farris wrote:
> Is the following kernel RPM behavior really necessary?  Yum repeatedly attempts
> to remove at least one kernel whenever a kernel is updated or installed, and
> fails if it cannot do so...  Removing a kernel to keep things a little cleaner
> with kernel updates is not so bad, but continuing when it cannot do that is what
> I'd want it to do (not fail).  I want these installed kernels, and I want them
> staying right where they are, with the nvidia modules as well (these kernels all
> have a buggy behavior with my usb drive and I'm keeping them to go back and test
> if it gets resolved later).

Have you seen/used the installonlyn yum plugin's configuration options?

Jon.




From sundaram at fedoraproject.org  Thu Nov 15 08:06:45 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Nov 2007 13:36:45 +0530
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <473BFCAB.4040600@hhs.nl>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>	<473B0EC5.4010708@hhs.nl>	<20071115001801.1a39988c@ludwig-alpha.unil.ch>
	<473BFCAB.4040600@hhs.nl>
Message-ID: <473BFE15.709@fedoraproject.org>

Hans de Goede wrote:
> Christian Iseli wrote:

>>
>> and then:
>> chris: grep cvsextras bzo.txt
>> Fedora|cvsextras|Library handling decoding of several popular sound 
>> file formats|jwrdegoede||
>> chris: grep SDL_sound bzo.txt
>> Fedora|SDL_sound|Library handling decoding of several popular sound 
>> file formats|jwrdegoede||
>>
> 
> Ok,
> 
> Who do I contact about this?

File a ticket in

https://hosted.fedoraproject.org/projects/packagedb/

Rahul



From jspaleta at gmail.com  Thu Nov 15 08:26:40 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 14 Nov 2007 23:26:40 -0900
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473BFADF.5080808@gmail.com>
References: <473BFADF.5080808@gmail.com>
Message-ID: <604aa7910711150026x3d64e979g5310f9468ac2786@mail.gmail.com>

On Nov 14, 2007 10:53 PM, Andrew Farris <lordmorgul at gmail.com> wrote:
> Is the following kernel RPM behavior really necessary?
Simple answer... By default yum is configured to keep exactly 2
kernels installed. You can disable that by editting yum.conf.

Why is it erroring out instead of removing the nvidia kmod?  No
idea... i should be telling you it will remove the dependent kmod as
well. I would need to poke at the rpmdb depchains of an affected
system to get a clear picture as to why its failing.  This works as
expect on the F7 system with nvidia kmods that I have. Haven't moved
that system to F8 yet so I can't comment on the behavior on an F8
system.

-jef



From j.w.r.degoede at hhs.nl  Thu Nov 15 08:29:25 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 15 Nov 2007 09:29:25 +0100
Subject: Fedora Package Status of Nov 14, 2007
In-Reply-To: <473BFE15.709@fedoraproject.org>
References: <20071114150849.0192620a@ludwig-alpha.unil.ch>	<473B0EC5.4010708@hhs.nl>	<20071115001801.1a39988c@ludwig-alpha.unil.ch>	<473BFCAB.4040600@hhs.nl>
	<473BFE15.709@fedoraproject.org>
Message-ID: <473C0365.20805@hhs.nl>

Rahul Sundaram wrote:
> Hans de Goede wrote:
>> Christian Iseli wrote:
> 
>>>
>>> and then:
>>> chris: grep cvsextras bzo.txt
>>> Fedora|cvsextras|Library handling decoding of several popular sound 
>>> file formats|jwrdegoede||
>>> chris: grep SDL_sound bzo.txt
>>> Fedora|SDL_sound|Library handling decoding of several popular sound 
>>> file formats|jwrdegoede||
>>>
>>
>> Ok,
>>
>> Who do I contact about this?
> 
> File a ticket in
> 
> https://hosted.fedoraproject.org/projects/packagedb/
> 

Thanks,

Ticket created:
https://hosted.fedoraproject.org/projects/packagedb/ticket/103

Regards,

Hans




From caillon at redhat.com  Thu Nov 15 08:28:45 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 15 Nov 2007 09:28:45 +0100
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <1195113922.32241.140.camel@perihelion>
References: <473BFADF.5080808@gmail.com>
	<1195113922.32241.140.camel@perihelion>
Message-ID: <473C033D.9030809@redhat.com>

Jon Masters wrote:
> On Wed, 2007-11-14 at 23:53 -0800, Andrew Farris wrote:
>> Is the following kernel RPM behavior really necessary?  Yum repeatedly attempts
>> to remove at least one kernel whenever a kernel is updated or installed, and
>> fails if it cannot do so...  Removing a kernel to keep things a little cleaner
>> with kernel updates is not so bad, but continuing when it cannot do that is what
>> I'd want it to do (not fail).  I want these installed kernels, and I want them
>> staying right where they are, with the nvidia modules as well (these kernels all
>> have a buggy behavior with my usb drive and I'm keeping them to go back and test
>> if it gets resolved later).
> 
> Have you seen/used the installonlyn yum plugin's configuration options?

It's no longer a plugin.  The functionality has been merged into yum 
proper.  See the manual for yum.conf for details.



From rc040203 at freenet.de  Thu Nov 15 08:44:13 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 15 Nov 2007 09:44:13 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B7424.3060407@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl>  <473B7424.3060407@leemhuis.info>
Message-ID: <1195116253.28534.147.camel@mccallum.corsepiu.local>


On Wed, 2007-11-14 at 23:18 +0100, Thorsten Leemhuis wrote:
> On 14.11.2007 19:34, Hans de Goede wrote:
> > Thorsten Leemhuis wrote:
> >> And 1108 open reviews in total (including lots of merge reviews (?))
> > <snip>
> >> I think we have a problem here. I'm actually wondering what FESCo (and
> >> the Board) thinks about that.
> > Thanks for this Thorsten, I think we as a community needed this kick in the 
> > behind, I say we as a community, because I think its unfair to solely blame 
> > FESCo, as you write further down your mail, there is currently little community 
> > involvement in the governing of Fedora, no contributers other the the members 
> > attending FESCo meetings, etc.
> 
> Well, the involvement from non-FESCo members in meetings was a lot
> better (but still far from perfect) a year ago afaics.
Right, and there are several reasons why it is so.

Primary reason is: FPC has lost importance.

- The fundamental problems have been resolved. Most issues popping up
these days either are exotic special cases, corner-cases or attempts on
over-engineering details ("implementing bureaucracy").

- FPC decisions are being ignored by packagers. 
Also, thanks to ACLs and Fedora policies, FPC has no means to enforce
its decisions, even in cases where things are non-arguably wrong, there
is no means to intervene/enforce the guidelines.

- Being a member of FPC is not a pleasant task.
You are "sitting between all chairs", being shot at from all sides.

> I actually hit the point many months ago where said "okay, I tried to do
> lots of stuff without being in FESCo or the Board; but it is way to hard
> and I'm wasting my time here". Main reason for that: I posted proposals
> to the list, got comments and integrated them into my proposal; some
> FESCo members didn't participate in the list discussions but in the
> meeting to vote on the porposal those suddenly said "I don't like part
> X". So I went back to the drawing board, list discsusion to hear in the
> next FESCo meeting just another FESCo member say "I don't like part Y".
Very nicely put. 

It corresponds to why I have become fatalistic and widely reduced my
involvement into Fedora: "THEM are wanting it, THEM are pushing us
volunteers around".

But that's a general Fedora issue and not actually related to FPC.

> I went thought that loop multiple times and that was just frustrating,
> so I'm ATM a bit unwilling to do more stuff in Fedora-government land
> again before this isn't getting fixed.
> 
> With getting fixed I'm not sure how to get that fixed exactly; maybe
> work work more towards a Meritocracy-like way and lessen the influence
> of the committees we have?
What are you aiming at? FPC already is permanently being ignored, it's
influence already is weak.

Ralf





From jspaleta at gmail.com  Thu Nov 15 08:56:17 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 14 Nov 2007 23:56:17 -0900
Subject: XULRunner in rawhide
In-Reply-To: <473B87C6.20605@redhat.com>
References: <473AFF3E.1090904@redhat.com> <473B50BC.7030504@conversis.de>
	<473B87C6.20605@redhat.com>
Message-ID: <604aa7910711150056h4f6db45dk454fe0aef0417cfa@mail.gmail.com>

On Nov 14, 2007 2:41 PM, Christopher Aillon <caillon at redhat.com> wrote:
> Um, did you read the article?  Specifically the "What are we doing?"
> opening text and the third bullet point underneath it?


firefox as shipped in Fedora, isn't what I'm most concerned about.
I'm pretty confident that for firefox in Fedora has a roadmap on how
handle the maintenance burden of a firefox package that diverges from
upstream development over the course of a Fedora release cycle.

What I am really concerned about is the other gecko lib based
applications we have.  xulrunner is a clear win for these applications
but only if the upstream developers for these applications are ready
to make use of xulrunner. We've been talking about xulrunner since F8
testing started.  I would have hoped that the maintainers for
applications that depend on gecko-libs would know by now if the
upstream projects are ready to support xulrunner.

So it really comes down to this. Out of the applications that depend
on gecko-libs in fedora right now, other than firefox, which of those
applications are xulrunner-ready?  And out of the ones that are not,
is upstream development actively working on making their app work with
xulrunner?

Worst case scenario is that we are going to get into a situation with
some of these apps where the upstream development does not support
xulrunner and it will be up to our package maintainers to try to make
it work and end up in over their heads keeping up with patches as app
updates are issued.  As a project we need to know about this sort of
potential problem as early in the development cycle as possible.

-jef"if I had a hammer, I'd hammer in DOOOOOOOM"spaleta



From singularitaet at gmx.net  Thu Nov 15 09:00:45 2007
From: singularitaet at gmx.net (Stefan Grosse)
Date: Thu, 15 Nov 2007 10:00:45 +0100
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473BFADF.5080808@gmail.com>
References: <473BFADF.5080808@gmail.com>
Message-ID: <473C0ABD.2090906@gmx.net>

-------- Original Message  --------
Subject: kernel RPMs dependency on removing prior kernel?
From: Andrew Farris <lordmorgul at gmail.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 15.11.2007 08:53
>  ---> Package kmod-nvidia-2.6.23-6.fc8.i686 0:100.14.19-8.lvn8 set to be erased
>  --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
> kmod-nvidia-2.6.23.1-42.fc8
>  ---> Package kmod-nvidia-2.6.23.1-37.fc8.i686 0:100.14.19-14.lvn8 set to be erased
>  ---> Package kmod-nvidia-2.6.23.1-41.fc8.i686 0:100.14.19-15.lvn8 set to be erased
>  --> Finished Dependency Resolution
>  Error: Missing Dependency: kernel-i686 = 2.6.23.1-42.fc8 is needed by package
> kmod-nvidia-2.6.23.1-42.fc8
>
>   

This seems to be an already reported bug related to kmods. You find a
workaround here:
http://thorstenl.blogspot.com/2007/11/problems-updating-kernels-and-kmods.html

Stefan
-=-=-
... Adapt or perish, now as ever, is Nature's inexorable imperative.
(H.G. Wells)



From jcm at redhat.com  Thu Nov 15 09:04:20 2007
From: jcm at redhat.com (Jon Masters)
Date: Thu, 15 Nov 2007 04:04:20 -0500
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473C033D.9030809@redhat.com>
References: <473BFADF.5080808@gmail.com>
	<1195113922.32241.140.camel@perihelion> <473C033D.9030809@redhat.com>
Message-ID: <1195117460.32241.142.camel@perihelion>


On Thu, 2007-11-15 at 09:28 +0100, Christopher Aillon wrote:
> Jon Masters wrote:
> > On Wed, 2007-11-14 at 23:53 -0800, Andrew Farris wrote:
> >> Is the following kernel RPM behavior really necessary?  Yum repeatedly attempts
> >> to remove at least one kernel whenever a kernel is updated or installed, and
> >> fails if it cannot do so...  Removing a kernel to keep things a little cleaner
> >> with kernel updates is not so bad, but continuing when it cannot do that is what
> >> I'd want it to do (not fail).  I want these installed kernels, and I want them
> >> staying right where they are, with the nvidia modules as well (these kernels all
> >> have a buggy behavior with my usb drive and I'm keeping them to go back and test
> >> if it gets resolved later).
> > 
> > Have you seen/used the installonlyn yum plugin's configuration options?
> 
> It's no longer a plugin.  The functionality has been merged into yum 
> proper.  See the manual for yum.conf for details.

Ah yes, I need to move with the times :-)

Jon.




From lordmorgul at gmail.com  Thu Nov 15 09:09:09 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Thu, 15 Nov 2007 01:09:09 -0800
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <604aa7910711150026x3d64e979g5310f9468ac2786@mail.gmail.com>
References: <473BFADF.5080808@gmail.com>
	<604aa7910711150026x3d64e979g5310f9468ac2786@mail.gmail.com>
Message-ID: <473C0CB5.8010601@gmail.com>

Jeff Spaleta wrote:
> On Nov 14, 2007 10:53 PM, Andrew Farris <lordmorgul at gmail.com> wrote:
>> Is the following kernel RPM behavior really necessary?
> Simple answer... By default yum is configured to keep exactly 2
> kernels installed. You can disable that by editting yum.conf.
> 
> Why is it erroring out instead of removing the nvidia kmod?  No
> idea... i should be telling you it will remove the dependent kmod as
> well. I would need to poke at the rpmdb depchains of an affected
> system to get a clear picture as to why its failing.  This works as
> expect on the F7 system with nvidia kmods that I have. Haven't moved
> that system to F8 yet so I can't comment on the behavior on an F8
> system.
> 
> -jef
> 

I should have mentioned having tried to make that work... but the simple answer
doesn't seem to.  The problem is I've had installonly_limit set to 5, to 0, to
10... and it always still fails (see this below).

I've tried the old plugin configuration as well.  Although I can change the
number of kernels it tries to get rid of... it still tries to remove my running
kernel!  I've manually set installonlypkgs=kernel, but without that (defaults)
it does the same thing.  I could not get it to install the kernel...

So taking a clue from your kmod comment I removed it, and now yum behaved
correctly, so the presence of the kmod-nvidia package is preventing the kernel
install from happening even though it was not going to remove the 1-42 kernel.

The installonlyn code may be parsing dependencies and failing the process even
though its not actually going to remove the kernel when the time comes.
Removing my video driver is also not good!

Could this be a package issue with the kmod-nvidia rpm or do you vote yum's
behavior?


 - yum install kernel-2.6.23.1-49.fc8
 fedora                    100% |=========================| 2.1 kB    00:00
 livna-development         100% |=========================| 2.1 kB    00:00
 updates-testing           100% |=========================| 2.3 kB    00:00
 livna                     100% |=========================| 2.1 kB    00:00
 updates                   100% |=========================| 2.3 kB    00:00
 Setting up Install Process
 Parsing package install arguments
 Resolving Dependencies
 --> Running transaction check
 --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
kmod-nvidia-2.6.23.1-42.fc8
 ---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
 --> Finished Dependency Resolution
 Error: Missing Dependency: kernel-i686 = 2.6.23.1-42.fc8 is needed by package
kmod-nvidia-2.6.23.1-42.fc8

  - cat /etc/yum.conf
  [main]
  cachedir=/var/cache/yum
  keepcache=0
  debuglevel=2
  logfile=/var/log/yum.log
  exactarch=1
  obsoletes=1
  gpgcheck=1
  plugins=1
  metadata_expire=1800
  installonly_limit=10
  installonlypkgs=kernel

 - rpm -e --nodeps kmod-nvidia-2.6.23.1-42.fc8

 - yum install kernel-2.6.23.1-49.fc8
  Loading "refresh-updatesd" plugin
  Setting up Install Process
  Parsing package install arguments
  Resolving Dependencies
  nnnnnnnnnnnnnnnnnnnnnnnnnnnnn
  --nn Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
  --> Finished Dependency Resolution

  Dependencies Resolved

  nnnnnnnnnnnnnnnnnnnnnnnnnnnnn===============================================n
   Package                 Arch       Version          Repository        Size
   =============================================================================
   Installing:
    nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn1-49.fc8  updates            16 M

    Transaction Summary
    =============================================================================
    Install      1 Package(s)
    Update       0 Package(s)
    Remove       0 Package(s)

Totan download size: 16 M
Is this ok [y/N]: y

 - rpm -q kernel
 kernel-2.6.23-6.fc8
 kernel-2.6.23.1-37.fc8
 kernel-2.6.23.1-41.fc8
 kernel-2.6.23.1-42.fc8
 kernel-2.6.23.1-49.fc8



-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From ian at stams.strath.ac.uk  Thu Nov 15 09:11:45 2007
From: ian at stams.strath.ac.uk (ian at stams.strath.ac.uk)
Date: Thu, 15 Nov 2007 09:11:45 +0000
Subject: F8: Where is am-utils ?
Message-ID: <20071115091145.468ybmweo88owgck@www.stams.strath.ac.uk>


Dear All

IIRC am-utils was in F8test3, but it's not in F8 release.

Anyone know what happened to it ?

Many thanks

Ian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




From lordmorgul at gmail.com  Thu Nov 15 09:17:39 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Thu, 15 Nov 2007 01:17:39 -0800
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473C0ABD.2090906@gmx.net>
References: <473BFADF.5080808@gmail.com> <473C0ABD.2090906@gmx.net>
Message-ID: <473C0EB3.5090209@gmail.com>

> This seems to be an already reported bug related to kmods. You find a
> workaround here:
> http://thorstenl.blogspot.com/2007/11/problems-updating-kernels-and-kmods.html
> 
> Stefan
> -=-=-
> ... Adapt or perish, now as ever, is Nature's inexorable imperative.
> (H.G. Wells)
> 

Thanks I totally missed that bug when I looked since I wasn't really thinking it
was the kmod's fault.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From pmatilai at laiskiainen.org  Thu Nov 15 09:43:40 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 15 Nov 2007 11:43:40 +0200 (EET)
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071114202019.GA5162@nostromo.devel.redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com> <473B5041.6080202@hhs.nl>
	<20071114202019.GA5162@nostromo.devel.redhat.com>
Message-ID: <alpine.DEB.0.9999.0711151140320.21362@gotcha.dreamhost.com>

On Wed, 14 Nov 2007, Bill Nottingham wrote:

> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>> Christopher Aillon wrote:
>>> * Make sure that there are no cases of Requires(pre,post)
>> Erm, why isn't the use of those perfectly "legal"
>
> As I understand it, Requires(pre) is OK, Requires(post) is OK,
> Requires(pre,post) is not.

IIRC that's supposed to work these days (FC >= 6, RHEL >= 5). If not, file 
a bug...

 	- Panu -



From nphilipp at redhat.com  Thu Nov 15 10:09:42 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 15 Nov 2007 11:09:42 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B6952.20605@gmail.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com>  <473B6952.20605@gmail.com>
Message-ID: <1195121382.29786.15.camel@wombat.tiptoe.de>

On Wed, 2007-11-14 at 13:32 -0800, Toshio Kuratomi wrote:
> Actually, at some point the FPC made an effort to merge the 
> ReviewGuidelines and the PackagingGuidelines so that the two were 
> different views on the same thing.  One is a checklist of problems to 
> check.  The other gives reasoning and notes exceptions to those rules.

I think this is unnecessary redundancy. Couldn't there be one document
("PackagingReviewCookBook") that uses phrases like "<X> MUST be <Y>
unless <some exception>"? That would serve both packagers and reviewers
and would link to other pages containing the reasons if needed.

>  > * Check the spec's encoding
> This also needs human supplementing.  We can check that the spec file is 
> ASCii but how are we to tell that the non-ASCii characters in there are 
> UTF-8 without a human looking at the context?

The "file" command can determine that with reasonable probability as
differently encoded files contain byte sequences not valid in UTF-8.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nicolas.mailhot at laposte.net  Thu Nov 15 10:33:45 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Nov 2007 11:33:45 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195121382.29786.15.camel@wombat.tiptoe.de>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>
	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>
	<473B4D36.8070904@redhat.com>  <473B6952.20605@gmail.com>
	<1195121382.29786.15.camel@wombat.tiptoe.de>
Message-ID: <1195122825.3047.18.camel@rousalka.dyndns.org>


Le jeudi 15 novembre 2007 ? 11:09 +0100, Nils Philippsen a ?crit :
> On Wed, 2007-11-14 at 13:32 -0800, Toshio Kuratomi wrote:
> > Actually, at some point the FPC made an effort to merge the 
> > ReviewGuidelines and the PackagingGuidelines so that the two were 
> > different views on the same thing.  One is a checklist of problems to 
> > check.  The other gives reasoning and notes exceptions to those rules.
> 
> I think this is unnecessary redundancy. Couldn't there be one document
> ("PackagingReviewCookBook") that uses phrases like "<X> MUST be <Y>
> unless <some exception>"? That would serve both packagers and reviewers
> and would link to other pages containing the reasons if needed.

If we want to maintain two different views a table with a "reviewer" and
"packager" columns would make sure the two views are always in sync. I
used this kind of dual-view trick for the Fonts SIG guidelines I hope
FPC will approve next week (if it will have recovered from DST changes)

http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/SpecTemplate
?
(my dual view is "spec directives" and "comments" but it could have been
"packager" and "reviewer" too)

-- 
Nicolas Mailhot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/dc7654cc/attachment.sig>

From snecklifter at gmail.com  Thu Nov 15 10:53:27 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Thu, 15 Nov 2007 10:53:27 +0000
Subject: F8: Where is am-utils ?
In-Reply-To: <20071115091145.468ybmweo88owgck@www.stams.strath.ac.uk>
References: <20071115091145.468ybmweo88owgck@www.stams.strath.ac.uk>
Message-ID: <364d303b0711150253r5ce28f5bga7c05af4ff4735e8@mail.gmail.com>

On 15/11/2007, ian at stams.strath.ac.uk <ian at stams.strath.ac.uk> wrote:
>
> Dear All
>
> IIRC am-utils was in F8test3, but it's not in F8 release.
>
> Anyone know what happened to it ?

I've got it.

$ yum list *am-utils*
Available Packages
am-utils.i386                            5:6.1.5-6.fc7          fedora

Did you mean it wasn't on the DVD?

-- 
http://www.chruz.com



From kevin.kofler at chello.at  Thu Nov 15 11:16:27 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 15 Nov 2007 11:16:27 +0000 (UTC)
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
References: <473B781F.7040809@hhs.nl>
Message-ID: <loom.20071115T111230-428@post.gmane.org>

Than can be a bit hard to contact indeed, speaking from experience here... I 
think he is way overworked, so he has a hard time keeping up with work items 
like Bugzilla entries or comaintainership requests.

He is usually idling on #fedora-kde, though unfortunately marked away (or just 
not there) more often than not.

        Kevin Kofler



From nicolas.mailhot at laposte.net  Thu Nov 15 11:34:53 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Nov 2007 12:34:53 +0100 (CET)
Subject: Severe X breakage heads up
Message-ID: <26494.192.54.193.53.1195126493.squirrel@rousalka.dyndns.org>

Hi all,

As discussed on the xorg list it seems the new experimental xorg
packages are missing a build dep on hal and dbus.

The new input hotplug system requires them to work :)

Regards,

-- 
Nicolas Mailhot



From caillon at redhat.com  Thu Nov 15 11:41:55 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 15 Nov 2007 12:41:55 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <alpine.DEB.0.9999.0711151140320.21362@gotcha.dreamhost.com>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>	<473B4D36.8070904@redhat.com>
	<473B5041.6080202@hhs.nl>	<20071114202019.GA5162@nostromo.devel.redhat.com>
	<alpine.DEB.0.9999.0711151140320.21362@gotcha.dreamhost.com>
Message-ID: <473C3083.5070602@redhat.com>

On 11/15/2007 10:43 AM, Panu Matilainen wrote:
> On Wed, 14 Nov 2007, Bill Nottingham wrote:
> 
>> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>>> Christopher Aillon wrote:
>>>> * Make sure that there are no cases of Requires(pre,post)
>>> Erm, why isn't the use of those perfectly "legal"
>>
>> As I understand it, Requires(pre) is OK, Requires(post) is OK,
>> Requires(pre,post) is not.
> 
> IIRC that's supposed to work these days (FC >= 6, RHEL >= 5). If not, 
> file a bug...

Then we should consider updating our guidelines.  This brings up a good 
point, too.  If a given package guideline exists to work around bugs 
like this in the future, the guideline really must reference the bug # 
so it can be easier to revisit at a future date.



From caillon at redhat.com  Thu Nov 15 11:44:09 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 15 Nov 2007 12:44:09 +0100
Subject: XULRunner in rawhide
In-Reply-To: <604aa7910711150056h4f6db45dk454fe0aef0417cfa@mail.gmail.com>
References: <473AFF3E.1090904@redhat.com>
	<473B50BC.7030504@conversis.de>	<473B87C6.20605@redhat.com>
	<604aa7910711150056h4f6db45dk454fe0aef0417cfa@mail.gmail.com>
Message-ID: <473C3109.9010507@redhat.com>

On 11/15/2007 09:56 AM, Jeff Spaleta wrote:
> On Nov 14, 2007 2:41 PM, Christopher Aillon <caillon at redhat.com> wrote:
>> Um, did you read the article?  Specifically the "What are we doing?"
>> opening text and the third bullet point underneath it?
> 
> 
> firefox as shipped in Fedora, isn't what I'm most concerned about.
> I'm pretty confident that for firefox in Fedora has a roadmap on how
> handle the maintenance burden of a firefox package that diverges from
> upstream development over the course of a Fedora release cycle.
> 
> What I am really concerned about is the other gecko lib based
> applications we have.  xulrunner is a clear win for these applications
> but only if the upstream developers for these applications are ready
> to make use of xulrunner. We've been talking about xulrunner since F8
> testing started.  I would have hoped that the maintainers for
> applications that depend on gecko-libs would know by now if the
> upstream projects are ready to support xulrunner.

Most of them ought to be using gtkmozembed which should not be that 
affected by the xulrunner changes too much.



From buildsys at fedoraproject.org  Thu Nov 15 12:35:53 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu, 15 Nov 2007 07:35:53 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-15
Message-ID: <20071115123553.3EE0415212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 8

    calcurse-1.9-1.fc6
    moodle-1.8.3-1.fc6
    php-pear-MDB2-2.4.1-2.fc6
    php-pear-MDB2-Driver-mysql-1.4.1-3.fc6
    python-fedora-0.2.90.20-5.fc6
    roundcubemail-0.1-0.8rc2.1.fc6
    sparse-0.4.1-1.fc6
    xmoto-0.3.4-1.fc6


Changes in Fedora Extras 6: 


calcurse-1.9-1.fc6
------------------
* Thu Oct 25 2007 Jon Ciesla <limb at jcomserv.net> 1.9-1
- Update to 1.9.
- License tag correction.

moodle-1.8.3-1.fc6
------------------
* Thu Oct 25 2007 Jon Ciesla <limb at jcomserv.net> - 1.8.3-1
- Update to 1.8.3.
- Fix init script for LSB BZ 246986.
- Updated language packs to 25 October 2007 versions.
- Added Armenian, Macedonian.

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> - 1.8.2-2
- License tag correction.

php-pear-MDB2-2.4.1-2.fc6
-------------------------
* Tue Nov 13 2007 Christopher Stone <chris.stone at gmail.com> 2.4.1-2
- Add LOB security patch (bz #379081)

php-pear-MDB2-Driver-mysql-1.4.1-3.fc6
--------------------------------------
* Tue Nov 13 2007 Christopher Stone <chris.stone at gmail.com> 1.4.1-3
- Add security patch (bz #379081)

python-fedora-0.2.90.20-5.fc6
-----------------------------
* Wed Nov 14 2007 Luke Macken <lmacken at redhat.com> - 0.2.90.20-5
- Handle our SQLAlchemy requirement differently for Fedora 8+, until
  TurboGears can use SQLAlchemy >= 0.4

roundcubemail-0.1-0.8rc2.1.fc6
------------------------------
* Fri Oct 26 2007 Jon Ciesla <limb at jcomserv.net> = 0.1-0.8rc2
- Upgrade to 0.1-rc2

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> = 0.1-0.7rc1.1
- License tag correction.

sparse-0.4.1-1.fc6
------------------
* Tue Nov 13 2007 Roland McGrath <roland at redhat.com> - 0.4.1-1
- Upgrade to 0.4.1

xmoto-0.3.4-1.fc6
-----------------
* Thu Oct 25 2007 Jon Ciesla <limb at jcomserv.net> 0.3.4-1
- Bumped to 0.3.4.



From t.matsuu at gmail.com  Thu Nov 15 13:06:02 2007
From: t.matsuu at gmail.com (MATSUURA Takanori)
Date: Thu, 15 Nov 2007 22:06:02 +0900
Subject: kernel RPMs dependency on removing prior kernel?
Message-ID: <6f27515e0711150506m6dae5984u30aca598b355af4d@mail.gmail.com>

Hi Andrew,

See
https://bugzilla.redhat.com/show_bug.cgi?id=330711


Date: Wed, 14 Nov 2007 23:53:03 -0800
From: Andrew Farris <lordmorgul at gmail.com>
Subject: kernel RPMs dependency on removing prior kernel?
Message-ID: <473BFADF.5080808 at gmail.com>

> Is the following kernel RPM behavior really necessary?



From ian at stams.strath.ac.uk  Thu Nov 15 13:22:48 2007
From: ian at stams.strath.ac.uk (Ian Thurlbeck)
Date: Thu, 15 Nov 2007 13:22:48 +0000
Subject: F8: Where is am-utils ?
In-Reply-To: <364d303b0711150253r5ce28f5bga7c05af4ff4735e8@mail.gmail.com>
References: <20071115091145.468ybmweo88owgck@www.stams.strath.ac.uk>
	<364d303b0711150253r5ce28f5bga7c05af4ff4735e8@mail.gmail.com>
Message-ID: <473C4828.7060700@stams.strath.ac.uk>

Christopher Brown wrote:
> On 15/11/2007, ian at stams.strath.ac.uk <ian at stams.strath.ac.uk> wrote:
>> Dear All
>>
>> IIRC am-utils was in F8test3, but it's not in F8 release.
>>
>> Anyone know what happened to it ?
> 
> I've got it.
> 
> $ yum list *am-utils*
> Available Packages
> am-utils.i386                            5:6.1.5-6.fc7          fedora
> 
> Did you mean it wasn't on the DVD?
> 

I had orignally installed off an F8 DVD, then I configured yum to look
at a local mirror copy of the standard F8 directory:

download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/

However, this does not contain am-utils (fair enough!) but also
doesn't contain thunderbird ?

I have re-done the local mirror from:

download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/

And that seems to have everything I normally expect!

Cheers

Ian
-- 
Ian Thurlbeck                http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK,  G1 1XH
Tel: +44 (0)141 548 3667           Fax: +44 (0)141 552 2079



From valent.turkovic at gmail.com  Thu Nov 15 14:31:44 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 15 Nov 2007 15:31:44 +0100
Subject: flickr favorites screensaver?
Message-ID: <64b14b300711150631g5eb17457i951b47ce8d5ef10e@mail.gmail.com>

Does anybody know any existing project for gnome ie. some screensaver
that downloads my favorite flickr pictures and slideshows them?

I would like to contribute and donate to such a project...

Thank you.

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From ajackson at redhat.com  Thu Nov 15 15:11:10 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 15 Nov 2007 10:11:10 -0500
Subject: Severe X breakage heads up
In-Reply-To: <47324ed80711141541m59876d5ak389935417e0262f5@mail.gmail.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195003708.2292.13.camel@localhost.localdomain>
	<47324ed80711141541m59876d5ak389935417e0262f5@mail.gmail.com>
Message-ID: <1195139470.2292.30.camel@localhost.localdomain>

On Wed, 2007-11-14 at 18:41 -0500, yonas Abraham wrote:

> I did update my Rahwid system, aftder reboot, no more X.
> 
> here is the last from /var/log/Xorg.0.log
> 
>         ABI class: X.Org XInput driver, version 2.0
> (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
>         i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
>         E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
>         965GM, 965GME/GLE, G33, Q35, Q33
> (II) Primary Device is: PCI 00 at 00:02:0
> (EE) No devices detected.
> 
> Fatal server error:
> no screens found

lspci?

- ajax



From chris.stone at gmail.com  Thu Nov 15 14:37:10 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 15 Nov 2007 06:37:10 -0800
Subject: Dependency Check on F-8 Upgrade Painfully Slow
Message-ID: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>

The "Checking Dependencies in selected installation" section of the
install I let run over night and it still had not finished.  After
about 10+ hours of disk grinding I just gave up and rebooted into
Fedora 7.  I only have 2200 packages.  Not a good first impression.  I
find it very hard to believe that upgrades were not tested, so perhaps
it is a unique situation for me.  However this dependency check part
has always been slow, is it still using python?  Is this related to
bug #360291?



From lmacken at redhat.com  Thu Nov 15 14:49:29 2007
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 15 Nov 2007 09:49:29 -0500
Subject: [PATCH] Makefile.common: bodhi update target
In-Reply-To: <20071114205735.GE32058@crow.myhome.westell.com>
References: <20071112180131.GT11043@crow.myhome.westell.com>
	<20071114205735.GE32058@crow.myhome.westell.com>
Message-ID: <20071115144929.GI32058@crow.myhome.westell.com>

On Wed, Nov 14, 2007 at 03:57:35PM -0500, Luke Macken wrote:
> Attached is my first attempt at a patch that should hopefully address all of the
> concerns that were mentioned.  This Makefile target now can handle:
> 
>     - auto-populating all bugs listed in the last changelog entry.
>     - aborting if the template (excluding comments) does not differ from
>       the original
> 
> I also noticed that Till's Makefile grabs only 1 bugzilla # per line, even if
> multiple are listed.  The attached patch can handle multiple bugs per line.

A less-ugly patch can be found here:
http://lmacken.fedorapeople.org/patches/Makefile.common-bodhi.patch

luke



From nphilipp at redhat.com  Thu Nov 15 14:59:22 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 15 Nov 2007 15:59:22 +0100
Subject: F8: Where is am-utils ?
In-Reply-To: <473C4828.7060700@stams.strath.ac.uk>
References: <20071115091145.468ybmweo88owgck@www.stams.strath.ac.uk>
	<364d303b0711150253r5ce28f5bga7c05af4ff4735e8@mail.gmail.com>
	<473C4828.7060700@stams.strath.ac.uk>
Message-ID: <1195138762.3533.1.camel@gibraltar.str.redhat.com>


On Thu, 2007-11-15 at 13:22 +0000, Ian Thurlbeck wrote:

> I have re-done the local mirror from:
> 
> download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/
> 
> And that seems to have everything I normally expect!

"Fedora" is more or less (only) what's on the installation media.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From chris.stone at gmail.com  Thu Nov 15 15:01:53 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 15 Nov 2007 07:01:53 -0800
Subject: x86_64 F8 DVD SHA1SUM File Not Signed
Message-ID: <d9c612bf0711150701t2b652300t596c80e11f453e14@mail.gmail.com>

The torrent at torrent.fedoraproject.org for the x86_64 F8 DVD has an
unsigned SHA1SUM file.



From pertusus at free.fr  Thu Nov 15 15:20:41 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 15 Nov 2007 16:20:41 +0100
Subject: rpms/gnuplot/devel gnuplot.spec,1.53,1.54
In-Reply-To: <200711151440.lAFEe7nV027729@cvs-int.fedora.redhat.com>
References: <200711151440.lAFEe7nV027729@cvs-int.fedora.redhat.com>
Message-ID: <20071115152041.GH2601@free.fr>

On Thu, Nov 15, 2007 at 09:40:07AM -0500, Ivana Varekova wrote:
> Author: varekova
> 
>  Requires: emacs >= %{emacs_version}
>  Provides: gnuplot-emacs
> +Obsoletes: gnuplot-emacs

It is better to have versioned obsoletes and provides for old packages.
There was something in the wiki with more detailled information, but 
I cannot find where it is.

--
Pat



From jkeating at redhat.com  Thu Nov 15 15:25:52 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 10:25:52 -0500
Subject: x86_64 F8 DVD SHA1SUM File Not Signed
In-Reply-To: <d9c612bf0711150701t2b652300t596c80e11f453e14@mail.gmail.com>
References: <d9c612bf0711150701t2b652300t596c80e11f453e14@mail.gmail.com>
Message-ID: <20071115102552.7357c8e6@redhat.com>

On Thu, 15 Nov 2007 07:01:53 -0800
"Christopher Stone" <chris.stone at gmail.com> wrote:

> The torrent at torrent.fedoraproject.org for the x86_64 F8 DVD has an
> unsigned SHA1SUM file.

My mistake.  Somehow the unsigned version got in instead of the signed
version.  However replacing it would mean regenerating the torrent and
wreaking some havoc.  I think it would be best to just leave it as it
is, since a signed version can be viewed to verify.

http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/x86_64/iso/SHA1SUM

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/667fd3e2/attachment.sig>

From yabraham2 at gmail.com  Thu Nov 15 15:38:26 2007
From: yabraham2 at gmail.com (yonas Abraham)
Date: Thu, 15 Nov 2007 10:38:26 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1195139470.2292.30.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195003708.2292.13.camel@localhost.localdomain>
	<47324ed80711141541m59876d5ak389935417e0262f5@mail.gmail.com>
	<1195139470.2292.30.camel@localhost.localdomain>
Message-ID: <47324ed80711150738n371d66bemd45ad1a8783c47e4@mail.gmail.com>

On 11/15/07, Adam Jackson <ajackson at redhat.com> wrote:
> On Wed, 2007-11-14 at 18:41 -0500, yonas Abraham wrote:
>
> > I did update my Rahwid system, aftder reboot, no more X.
> >
> > here is the last from /var/log/Xorg.0.log
> >
> >         ABI class: X.Org XInput driver, version 2.0
> > (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
> >         i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
> >         E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, 965G, 965Q, 946GZ,
> >         965GM, 965GME/GLE, G33, Q35, Q33
> > (II) Primary Device is: PCI 00 at 00:02:0
> > (EE) No devices detected.
> >
> > Fatal server error:
> > no screens found
>
> lspci?

[yonas at siempc ~]$ /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory
Controller Hub (rev 04)
00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI
Express Root Port (rev 04)
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL
Integrated Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation 82915G Integrated
Graphics Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation
82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC
Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 03)
03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video
and Audio Decoder (rev 05)
03:01.0 Multimedia controller: Pinnacle Systems Inc. AV/DV Studio Capture Card
03:01.1 FireWire (IEEE 1394): Pinnacle Systems Inc. Unknown device 0015
03:08.0 Ethernet controller: Intel Corporation 82562ET/EZ/GT/GZ -
PRO/100 VE (LOM) Ethernet Controller (rev 03)



From skvidal at fedoraproject.org  Thu Nov 15 15:37:01 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Nov 2007 10:37:01 -0500
Subject: Dependency Check on F-8 Upgrade Painfully Slow
In-Reply-To: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
References: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
Message-ID: <1195141021.23955.90.camel@cutter>


On Thu, 2007-11-15 at 06:37 -0800, Christopher Stone wrote:
> The "Checking Dependencies in selected installation" section of the
> install I let run over night and it still had not finished.  After
> about 10+ hours of disk grinding I just gave up and rebooted into
> Fedora 7.  I only have 2200 packages.  Not a good first impression.  I
> find it very hard to believe that upgrades were not tested, so perhaps
> it is a unique situation for me.  However this dependency check part
> has always been slow, is it still using python?  Is this related to
> bug #360291?

You're doing the upgrade by anaconda?

-sv




From chris.stone at gmail.com  Thu Nov 15 15:50:27 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 15 Nov 2007 07:50:27 -0800
Subject: Dependency Check on F-8 Upgrade Painfully Slow
In-Reply-To: <1195141021.23955.90.camel@cutter>
References: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
	<1195141021.23955.90.camel@cutter>
Message-ID: <d9c612bf0711150750y565611b3wdfece04e49cafbe7@mail.gmail.com>

On Nov 15, 2007 7:37 AM, seth vidal <skvidal at fedoraproject.org> wrote:
>
>
> On Thu, 2007-11-15 at 06:37 -0800, Christopher Stone wrote:
> > The "Checking Dependencies in selected installation" section of the
> > install I let run over night and it still had not finished.  After
> > about 10+ hours of disk grinding I just gave up and rebooted into
> > Fedora 7.  I only have 2200 packages.  Not a good first impression.  I
> > find it very hard to believe that upgrades were not tested, so perhaps
> > it is a unique situation for me.  However this dependency check part
> > has always been slow, is it still using python?  Is this related to
> > bug #360291?
>
> You're doing the upgrade by anaconda?

Anna who? I'm just doing a DVD upgrade, someone pointed me to a bug:

https://bugzilla.redhat.com/show_bug.cgi?id=372011

Seems to be a common bug, but I have no idea how to apply or test this fix.



From skvidal at fedoraproject.org  Thu Nov 15 15:57:32 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Nov 2007 10:57:32 -0500
Subject: Dependency Check on F-8 Upgrade Painfully Slow
In-Reply-To: <d9c612bf0711150750y565611b3wdfece04e49cafbe7@mail.gmail.com>
References: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
	<1195141021.23955.90.camel@cutter>
	<d9c612bf0711150750y565611b3wdfece04e49cafbe7@mail.gmail.com>
Message-ID: <1195142252.23955.92.camel@cutter>


On Thu, 2007-11-15 at 07:50 -0800, Christopher Stone wrote:
> On Nov 15, 2007 7:37 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> >
> >
> > On Thu, 2007-11-15 at 06:37 -0800, Christopher Stone wrote:
> > > The "Checking Dependencies in selected installation" section of the
> > > install I let run over night and it still had not finished.  After
> > > about 10+ hours of disk grinding I just gave up and rebooted into
> > > Fedora 7.  I only have 2200 packages.  Not a good first impression.  I
> > > find it very hard to believe that upgrades were not tested, so perhaps
> > > it is a unique situation for me.  However this dependency check part
> > > has always been slow, is it still using python?  Is this related to
> > > bug #360291?
> >
> > You're doing the upgrade by anaconda?
> 
> Anna who? I'm just doing a DVD upgrade, someone pointed me to a bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=372011
> 
> Seems to be a common bug, but I have no idea how to apply or test this fix.

Okay so you're booting from the dvd and upgrading? Is the progress bar
getting stuck at 26%?

-sv




From galibert at pobox.com  Thu Nov 15 16:01:24 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 15 Nov 2007 17:01:24 +0100
Subject: F8 is getting *really* sysadmin-hostile
Message-ID: <20071115160124.GA40056@dspnet.fr.eu.org>

Bug #134886 is still there since fedora core 3 times.  It means that
NetworkManager will happily shutdown the interfaces, ignore any
settings you've put in anaconda and wipe out /etc/resolv.conf if you
happen not to use dhcp.  Like in a lab, where desktops and servers
tend not to wander around so much and dhcp is used only for laptops.

Fedora 8 adds another level to the fun:

- NetworkManager is started at gdm time.  Which means that your
  anaconda settings are ignored (and the DNS settings *erased*) as soon
  as the login interface appears.

- service network restart doesn't work, because NM detects it and
  stomps all over it

- you can't just chkconfig NM out.  It looks like it's started by
  gnome itself, or maybe hal, so one has to study their "my wheel is
  better than your wheel" startup configuration.  Or maybe not.  Dunno
  really.

- if you try to yum remove it, you lose evolution,
  krb5-auth-dialog, libpurple, nautilus-sendto and pidgin.

- once you rpm -e --nodeps it, you find out that the "network" service
  is not on by default either (liveCD install)

I find the idea of having to do a pair of rpm -e in kickstart kinda
demented.  Is there a saner answer?

  OG.



From chris.stone at gmail.com  Thu Nov 15 16:08:54 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 15 Nov 2007 08:08:54 -0800
Subject: Dependency Check on F-8 Upgrade Painfully Slow
In-Reply-To: <1195142252.23955.92.camel@cutter>
References: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
	<1195141021.23955.90.camel@cutter>
	<d9c612bf0711150750y565611b3wdfece04e49cafbe7@mail.gmail.com>
	<1195142252.23955.92.camel@cutter>
Message-ID: <d9c612bf0711150808j11e97353x3bed4503a3e4aea6@mail.gmail.com>

On Nov 15, 2007 7:57 AM, seth vidal <skvidal at fedoraproject.org> wrote:
>
>
> On Thu, 2007-11-15 at 07:50 -0800, Christopher Stone wrote:
> > On Nov 15, 2007 7:37 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> > >
> > >
> > > On Thu, 2007-11-15 at 06:37 -0800, Christopher Stone wrote:
> > > > The "Checking Dependencies in selected installation" section of the
> > > > install I let run over night and it still had not finished.  After
> > > > about 10+ hours of disk grinding I just gave up and rebooted into
> > > > Fedora 7.  I only have 2200 packages.  Not a good first impression.  I
> > > > find it very hard to believe that upgrades were not tested, so perhaps
> > > > it is a unique situation for me.  However this dependency check part
> > > > has always been slow, is it still using python?  Is this related to
> > > > bug #360291?
> > >
> > > You're doing the upgrade by anaconda?
> >
> > Anna who? I'm just doing a DVD upgrade, someone pointed me to a bug:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=372011
> >
> > Seems to be a common bug, but I have no idea how to apply or test this fix.
>
> Okay so you're booting from the dvd and upgrading? Is the progress bar
> getting stuck at 26%?

No, actually I do not recall seeing a percentage.  After what I would
estimate the progress bar at about 40% I went to sleep and let it run
overnight.  In the morning the progress bar was all the way to the end
except for perhaps one pixel, so I let it run for another hour, but
nothing changed and my disk drive was constantly spinning.  So I had
to get ready for the day and just rebooted back into F7 at that point.



From mark.bidewell at alumni.clemson.edu  Thu Nov 15 16:17:02 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Thu, 15 Nov 2007 11:17:02 -0500
Subject: Dependency Check on F-8 Upgrade Painfully Slow
In-Reply-To: <d9c612bf0711150808j11e97353x3bed4503a3e4aea6@mail.gmail.com>
References: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
	<1195141021.23955.90.camel@cutter>
	<d9c612bf0711150750y565611b3wdfece04e49cafbe7@mail.gmail.com>
	<1195142252.23955.92.camel@cutter>
	<d9c612bf0711150808j11e97353x3bed4503a3e4aea6@mail.gmail.com>
Message-ID: <bfdeacfa0711150817i3491e1b4qa2b6021f2045da1d@mail.gmail.com>

I don't know if this is related but yum-updatesd and pup in F7/F8 tend to
take forever (if ever) on check dependencies as well.  I know this is not a
repo issue as doing yum update does not exhibit this behavior.

I have taken to disabling yum-updatesd and just using yum.

Mark Bidewell


On 11/15/07, Christopher Stone <chris.stone at gmail.com> wrote:
>
> On Nov 15, 2007 7:57 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> >
> >
> > On Thu, 2007-11-15 at 07:50 -0800, Christopher Stone wrote:
> > > On Nov 15, 2007 7:37 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> > > >
> > > >
> > > > On Thu, 2007-11-15 at 06:37 -0800, Christopher Stone wrote:
> > > > > The "Checking Dependencies in selected installation" section of
> the
> > > > > install I let run over night and it still had not finished.  After
> > > > > about 10+ hours of disk grinding I just gave up and rebooted into
> > > > > Fedora 7.  I only have 2200 packages.  Not a good first
> impression.  I
> > > > > find it very hard to believe that upgrades were not tested, so
> perhaps
> > > > > it is a unique situation for me.  However this dependency check
> part
> > > > > has always been slow, is it still using python?  Is this related
> to
> > > > > bug #360291?
> > > >
> > > > You're doing the upgrade by anaconda?
> > >
> > > Anna who? I'm just doing a DVD upgrade, someone pointed me to a bug:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=372011
> > >
> > > Seems to be a common bug, but I have no idea how to apply or test this
> fix.
> >
> > Okay so you're booting from the dvd and upgrading? Is the progress bar
> > getting stuck at 26%?
>
> No, actually I do not recall seeing a percentage.  After what I would
> estimate the progress bar at about 40% I went to sleep and let it run
> overnight.  In the morning the progress bar was all the way to the end
> except for perhaps one pixel, so I let it run for another hour, but
> nothing changed and my disk drive was constantly spinning.  So I had
> to get ready for the day and just rebooted back into F7 at that point.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/5e1553d4/attachment.htm>

From cra at WPI.EDU  Thu Nov 15 16:22:32 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 15 Nov 2007 11:22:32 -0500
Subject: Dependency Check on F-8 Upgrade Painfully Slow
In-Reply-To: <bfdeacfa0711150817i3491e1b4qa2b6021f2045da1d@mail.gmail.com>
References: <d9c612bf0711150637k79acd3dajf43af13ab317b35@mail.gmail.com>
	<1195141021.23955.90.camel@cutter>
	<d9c612bf0711150750y565611b3wdfece04e49cafbe7@mail.gmail.com>
	<1195142252.23955.92.camel@cutter>
	<d9c612bf0711150808j11e97353x3bed4503a3e4aea6@mail.gmail.com>
	<bfdeacfa0711150817i3491e1b4qa2b6021f2045da1d@mail.gmail.com>
Message-ID: <20071115162232.GC25455@angus.ind.WPI.EDU>

On Thu, Nov 15, 2007 at 11:17:02AM -0500, Mark Bidewell wrote:
> I don't know if this is related but yum-updatesd and pup in F7/F8 tend to
> take forever (if ever) on check dependencies as well.  I know this is not a
> repo issue as doing yum update does not exhibit this behavior.
> 
> I have taken to disabling yum-updatesd and just using yum.

I've noticed that as well.  yum-updatesd would be there churning in 
the background for what seemed like forever.  If I kill it and just 
yum "yum update" it goes much faster.

Does the background yum-updatesd intentionally download very slowly so 
it doesn't take up the whole pipe?



From bnocera at redhat.com  Thu Nov 15 16:23:16 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 15 Nov 2007 16:23:16 +0000
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115160124.GA40056@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
Message-ID: <1195143796.3140.110.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 17:01 +0100, Olivier Galibert wrote:
> Bug #134886 is still there since fedora core 3 times.  It means that
> NetworkManager will happily shutdown the interfaces, ignore any
> settings you've put in anaconda and wipe out /etc/resolv.conf if you
> happen not to use dhcp.  Like in a lab, where desktops and servers
> tend not to wander around so much and dhcp is used only for laptops.

Just disable NetworkManager in your kickstart file.

> - you can't just chkconfig NM out.  It looks like it's started by
>   gnome itself, or maybe hal, so one has to study their "my wheel is
>   better than your wheel" startup configuration.  Or maybe not.  Dunno
>   really.

Yes you can. My machine isn't running NetworkManager, and has a network.
And it's definitely installed.

> - if you try to yum remove it, you lose evolution,
>   krb5-auth-dialog, libpurple, nautilus-sendto and pidgin.

nautilus-sendto certainly doesn't require it. Probably
evolution-data-server requiring it.

> - once you rpm -e --nodeps it, you find out that the "network" service
>   is not on by default either (liveCD install)
> 
> I find the idea of having to do a pair of rpm -e in kickstart kinda
> demented.  Is there a saner answer?

A live CD install on servers? You're walking all over your use cases :)



From louisg00 at bellsouth.net  Thu Nov 15 16:25:15 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Thu, 15 Nov 2007 11:25:15 -0500
Subject: readahead in F8/rawhide
Message-ID: <1195143915.3896.3.camel@tiger>

Did readahead get removed from the default install of F8?

-Thanks



From robert at marcanoonline.com  Thu Nov 15 16:25:44 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 15 Nov 2007 12:25:44 -0400
Subject: build servers kernel release (PPC64)
In-Reply-To: <200711141607.50983.dennis@ausil.us>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com>  <200711141607.50983.dennis@ausil.us>
Message-ID: <1195143945.3132.3.camel@localhost.localdomain>

On Wed, 2007-11-14 at 16:07 -0600, Dennis Gilmore wrote:
> On Monday 12 November 2007, Toshio Kuratomi wrote:
> > Robert Marcano wrote:
> > > are the build systems servers running the latest F8 kernel? I need the
> > > fix of bug 350291 in order to be able to build eclipse-subclipse on
> > > ppc64 machines. I am asking because the error still happens and I am not
> > > sure if the fix did not work or the server have an outdated kernel?
> > >
> > > Any help is appreciated
> >
> > The build systems are currently running FC6.  At the last infrastructure
> > meeting we tentatively agreed on upgrading them about 3 weeks from now
> > (on the weekend).  We also were leaning towards upgrading them to RHEL5
> > at the time.  Do we need to upgrade to F8 instead?
> >
> > -Toshio
> 
> David Woodhouse built a kernel update for FC-6  that I put on the ppc builders 
> today that fixes the bug you have referenced.  Please try your build now.  We 
> will need to make sure that this gets fixed for RHEL5 also
> 

Tried it, but now the error is triggered on x86_64 architecture, It
looks like it is not the correct fix, the ppc64 architecture has no time
to build (it was canceled). I will try modifying the spec file to only
build ppc64


> 
> Dennis
> 



From bnocera at redhat.com  Thu Nov 15 16:32:02 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 15 Nov 2007 16:32:02 +0000
Subject: flickr favorites screensaver?
In-Reply-To: <64b14b300711150631g5eb17457i951b47ce8d5ef10e@mail.gmail.com>
References: <64b14b300711150631g5eb17457i951b47ce8d5ef10e@mail.gmail.com>
Message-ID: <1195144322.3140.115.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 15:31 +0100, Valent Turkovic wrote:
> Does anybody know any existing project for gnome ie. some screensaver
> that downloads my favorite flickr pictures and slideshows them?
> 
> I would like to contribute and donate to such a project...

A nice screensaver based on clutter (see toys/fluttr in their SVN) would
be a nice thing to add, although the initial configuration (allowing
fluttr to access your photos) is a bit of a pain.



From jkeating at redhat.com  Thu Nov 15 16:32:17 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 11:32:17 -0500
Subject: build servers kernel release (PPC64)
In-Reply-To: <1195143945.3132.3.camel@localhost.localdomain>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com> <200711141607.50983.dennis@ausil.us>
	<1195143945.3132.3.camel@localhost.localdomain>
Message-ID: <20071115113217.6d023954@redhat.com>

On Thu, 15 Nov 2007 12:25:44 -0400
Robert Marcano <robert at marcanoonline.com> wrote:

> Tried it, but now the error is triggered on x86_64 architecture, It
> looks like it is not the correct fix, the ppc64 architecture has no
> time to build (it was canceled). I will try modifying the spec file
> to only build ppc64

You could just do a scratch build targetting ppc64.  koji build
--scratch dist-f9 --arch-override ppc64 foo.src.rpm

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/abf4f4c5/attachment.sig>

From snecklifter at gmail.com  Thu Nov 15 16:39:11 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Thu, 15 Nov 2007 16:39:11 +0000
Subject: readahead in F8/rawhide
In-Reply-To: <1195143915.3896.3.camel@tiger>
References: <1195143915.3896.3.camel@tiger>
Message-ID: <364d303b0711150839j7e1e7451y791ff4ebae5b5005@mail.gmail.com>

On 15/11/2007, Louis E Garcia II <louisg00 at bellsouth.net> wrote:
> Did readahead get removed from the default install of F8?

I believe so. Please read the archives...

Cheers
Chris

-- 
http://www.chruz.com



From snecklifter at gmail.com  Thu Nov 15 16:47:25 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Thu, 15 Nov 2007 16:47:25 +0000
Subject: sending multiple (different) smolt profiles
In-Reply-To: <7f692fec0711140707y2f94dcb6h93218b51932df8ad@mail.gmail.com>
References: <64b14b300711120054o1b0fd5bfg2b33ed9eff0d5db9@mail.gmail.com>
	<7f692fec0711121232u78ecbc4bh2e10ad0f24f5fcc0@mail.gmail.com>
	<Pine.LNX.4.64.0711121607000.4486@beer.tclug.org>
	<64b14b300711130212g390fcf61yf319417393e27ca3@mail.gmail.com>
	<1194958858.2025.19.camel@cutter>
	<64b14b300711140128n7ae30428lee0ed62e376240b6@mail.gmail.com>
	<3170f42f0711140351s3c55e090k6623059371c6bf50@mail.gmail.com>
	<7f692fec0711140707y2f94dcb6h93218b51932df8ad@mail.gmail.com>
Message-ID: <364d303b0711150847o238986acp88c9341d3c6da7b4@mail.gmail.com>

On 14/11/2007, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> On Nov 14, 2007 6:51 AM, Debarshi 'Rishi' Ray <debarshi.ray at gmail.com> wrote:
> > > Yesterday I couldn't send smolt profile, and I tried for over half an
> > > hour... today I sent it without problem the first time.
> >
> > Same here.
>
> Smolt's having server issues.  It unfortunately needs alot of TLC that
> no one has the time for in the next few weeks.  Alot of it has to do
> with the way it's run in a clustered environment, and we need to set
> up a testing environment that simulates that.
>
> Sorry for all the disappointment in smolt.  Maybe we just need a big
> Under Construction sign.

No disappointment here - worked fine for me every time so far.

Cheers
Chris

-- 
http://www.chruz.com



From jspaleta at gmail.com  Thu Nov 15 16:50:54 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 15 Nov 2007 07:50:54 -0900
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115160124.GA40056@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
Message-ID: <604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>

On Nov 15, 2007 7:01 AM, Olivier Galibert <galibert at pobox.com> wrote:
> - once you rpm -e --nodeps it, you find out that the "network" service
>   is not on by default either (liveCD install)

Perhaps we need to either make it even more clear what the usage case
for the desktop livecd actually is.  I thought it was clear.  Or
perhaps there is a compelling need for a server livecd that uses the
legacy network stack by default.  Either way, the desktop livecd we
are offering for F8 isn't intended to be the basis for situations for
all networking scenarios.  That is why we continue to include the
legacy network stack and why the legacy network stack is used by
default on the traditional dvd install.

I'm sort of confused by your statements concerning the inability to
turn NetworkManager off without having to remove the rpm.

There is a initscript for NetworkManager on your system is there not?

/sbin/service NetworkManager status
should tell you if its running.

/sbin/chkconfig --list NetworkManager
should tell you in which runlevels its configured to start on boot.

In any event you should be able to turn off the NetworkManager
initscript and enable the legacy network initscript if its not already
running. None of this sysadmin activity requires uninstalling rpms.


-jef"Spends quite a large amount of time in buildings containing rooms
that could be called 'labs' where most of the computers are immobile
and yet the network admins use a consistent dhcp scheme with mac
addressing  to register each and every computer on the network unless
there is a demonstrated need for a static ip in which case you can
request one. NetworkManager works just fine for 'lab' workstations
here."spaleta



From ml at deadbabylon.de  Thu Nov 15 16:52:27 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Thu, 15 Nov 2007 17:52:27 +0100
Subject: rawhide report: 20071114 changes
In-Reply-To: <76e72f800711141856h57322c6flf487d4383743a631@mail.gmail.com>
References: <200711141208.lAEC8ZDl016393@porkchop.devel.redhat.com>
	<76e72f800711141856h57322c6flf487d4383743a631@mail.gmail.com>
Message-ID: <200711151752.37554.ml@deadbabylon.de>

Am Do 15.November 2007 schrieb Yuan Yijun:
> a little bug in compiz-manager
>
> [yuan at mstar ~]$ grep intel_drv\.so /var/log/Xorg.0.log
> (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
>
>  58 # For detecting what driver is in use, the + is for one or more /'s
>  59 XORG_DRIVER_PATH="/usr/$ARCH_LIB/xorg/modules//drivers/+"

Thx. Fixed this. 
http://koji.fedoraproject.org/koji/taskinfo?taskID=243230

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/89fea4f9/attachment.sig>

From jamatos at fc.up.pt  Thu Nov 15 17:03:58 2007
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Thu, 15 Nov 2007 17:03:58 +0000
Subject: Severe X breakage heads up
In-Reply-To: <1195003708.2292.13.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195003708.2292.13.camel@localhost.localdomain>
Message-ID: <200711151704.00187.jamatos@fc.up.pt>

On Wednesday 14 November 2007 01:28:28 Adam Jackson wrote:
> I'll be cleaning up the rest of the mess as we go. ?Please do file bugs
> about any weirdness you encounter (outside of the above known caveats).

  In my case the driver sis was not present, so I have reset to vesa according 
to your advice.

  Vesa does not work because my monitor warns "Attention, Out of range, 
H:89.6KHz V:59.7Hz". To regain the control of the screen I have to kill X.

  I have removed the horizontal and vertical ranges from the configuration 
file to allow DDC probing and the result is the same.

  Attached I send the log and lspci output.

This is the same monitor that I have filled a bugzilla recently because it did 
not allowed anymore the 1280*1024 resolution that used to allow until some 
weeks ago.
https://bugzilla.redhat.com/show_bug.cgi?id=353641

> - ajax

-- 
Jos? Ab?lio
-------------- next part --------------
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] (rev 36)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:06.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 47561 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/508a45ca/attachment.bin>

From myfedora at richip.dhs.org  Thu Nov 15 17:14:47 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 15 Nov 2007 10:14:47 -0700
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473C0ABD.2090906@gmx.net>
References: <473BFADF.5080808@gmail.com> <473C0ABD.2090906@gmx.net>
Message-ID: <1195146887.12554.5.camel@localhost6.localdomain6>

On Thu, 2007-11-15 at 10:00 +0100, Stefan Grosse wrote:
> -------- Original Message  --------
> Subject: kernel RPMs dependency on removing prior kernel?
> From: Andrew Farris <lordmorgul at gmail.com>
> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
> Date: 15.11.2007 08:53
> >  ---> Package kmod-nvidia-2.6.23-6.fc8.i686 0:100.14.19-8.lvn8 set to be erased
> >  --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
> > kmod-nvidia-2.6.23.1-42.fc8
> >  ---> Package kmod-nvidia-2.6.23.1-37.fc8.i686 0:100.14.19-14.lvn8 set to be erased
> >  ---> Package kmod-nvidia-2.6.23.1-41.fc8.i686 0:100.14.19-15.lvn8 set to be erased
> >  --> Finished Dependency Resolution
> >  Error: Missing Dependency: kernel-i686 = 2.6.23.1-42.fc8 is needed by package
> > kmod-nvidia-2.6.23.1-42.fc8
> >
> >   
> 
> This seems to be an already reported bug related to kmods. You find a
> workaround here:
> http://thorstenl.blogspot.com/2007/11/problems-updating-kernels-and-kmods.html

The workaround I tend to use is:

# yumdownloader kernel kernel-devel # only do kernel-devel if it's
actually installed
# rpm -ivh kernel-<newversion> kernel-devel-<newversion>
# yum update
# yum remove kernel-<oldestversion> # optional

This seems to pull in the updated kmods assuming the updated kmods are
being pulled in by a "suite" package that is also updated. It also keeps
the old kmods in case I want to fall back to an older kernel.
--

Richi Plana



From fedora at leemhuis.info  Thu Nov 15 17:24:28 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 15 Nov 2007 18:24:28 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473C3083.5070602@redhat.com>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>	<473B4D36.8070904@redhat.com>	<473B5041.6080202@hhs.nl>	<20071114202019.GA5162@nostromo.devel.redhat.com>	<alpine.DEB.0.9999.0711151140320.21362@gotcha.dreamhost.com>
	<473C3083.5070602@redhat.com>
Message-ID: <473C80CC.3070306@leemhuis.info>



On 15.11.2007 12:41, Christopher Aillon wrote:
> On 11/15/2007 10:43 AM, Panu Matilainen wrote:
>> On Wed, 14 Nov 2007, Bill Nottingham wrote:
>>
>>> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>>>> Christopher Aillon wrote:
>>>>> * Make sure that there are no cases of Requires(pre,post)
>>>> Erm, why isn't the use of those perfectly "legal"
>>> As I understand it, Requires(pre) is OK, Requires(post) is OK,
>>> Requires(pre,post) is not.
>> IIRC that's supposed to work these days (FC >= 6, RHEL >= 5). If not, 
>> file a bug...
> Then we should consider updating our guidelines.  This brings up a good 
> point, too.  If a given package guideline exists to work around bugs 
> like this in the future, the guideline really must reference the bug # 
> so it can be easier to revisit at a future date.

Agreed, albeit I'm not sure if the exact bug # is needed -- the
information "need in FC > foo and RHEL > bar" is the important one. And
maintaining that properly is more important due to EPEL, as we'll still
have to deal with EPEL for EL4 for some years.

CU
knurd



From poelstra at redhat.com  Thu Nov 15 17:30:00 2007
From: poelstra at redhat.com (John Poelstra)
Date: Thu, 15 Nov 2007 09:30:00 -0800
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115160124.GA40056@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
Message-ID: <473C8218.6090801@redhat.com>

Olivier Galibert said the following on 11/15/2007 08:01 AM Pacific Time:
> Bug #134886 is still there since fedora core 3 times.  It means that
> NetworkManager will happily shutdown the interfaces, ignore any
> settings you've put in anaconda and wipe out /etc/resolv.conf if you
> happen not to use dhcp.  Like in a lab, where desktops and servers
> tend not to wander around so much and dhcp is used only for laptops.
> 
> Fedora 8 adds another level to the fun:
> 
> - NetworkManager is started at gdm time.  Which means that your
>   anaconda settings are ignored (and the DNS settings *erased*) as soon
>   as the login interface appears.
> 
> - service network restart doesn't work, because NM detects it and
>   stomps all over it

first:
service NetworkManager stop

> - you can't just chkconfig NM out.  It looks like it's started by
>   gnome itself, or maybe hal, so one has to study their "my wheel is
>   better than your wheel" startup configuration.  Or maybe not.  Dunno
>   really.

chkconfig --del NetworkManager

> - if you try to yum remove it, you lose evolution,
>   krb5-auth-dialog, libpurple, nautilus-sendto and pidgin.
> 

I've been thinking the same thing...you also lose liferea and pidgin which seems totally silly too!

Which component(s) should a bug be filed against?

# yum remove NetworkManager

<cut>

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Removing:
 NetworkManager          x86_64     1:0.7.0-0.5.svn3030.fc8  installed         2.2 M
 NetworkManager          i386       1:0.7.0-0.5.svn3030.fc8  installed         2.2 M
Removing for dependencies:
 NetworkManager-glib     i386       1:0.7.0-0.5.svn3030.fc8  installed          98 k
 NetworkManager-glib     x86_64     1:0.7.0-0.5.svn3030.fc8  installed         103 k
 NetworkManager-gnome    x86_64     1:0.7.0-0.5.svn3030.fc8  installed         524 k
 NetworkManager-openvpn  i386       1:0.7.0-2.svn3047.fc8  installed         477 k
 NetworkManager-openvpn  x86_64     1:0.7.0-2.svn3047.fc8  installed         487 k
 NetworkManager-vpnc     x86_64     1:0.7.0-0.4.svn3030.fc8  installed         318 k
 NetworkManager-vpnc     i386       1:0.7.0-0.4.svn3030.fc8  installed         307 k
 libpurple               x86_64     2.2.2-1.fc8      installed          18 M
 liferea                 x86_64     1.2.23-5.fc8     installed         1.9 M
 nautilus-sendto         x86_64     0.12-3.fc8       installed         276 k
 pidgin                  x86_64     2.2.2-1.fc8      installed         2.2 M

Transaction Summary
=============================================================================
Install      0 Package(s)         
Update       0 Package(s)         
Remove      13 Package(s)         

Is this ok [y/N]: 




From ville.skytta at iki.fi  Thu Nov 15 17:30:28 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 15 Nov 2007 19:30:28 +0200
Subject: Review queue/FESCo after the merge
In-Reply-To: <473B67F5.3060702@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>
	<ufa1waseho4.fsf@epithumia.math.uh.edu>
	<473B67F5.3060702@leemhuis.info>
Message-ID: <200711151930.29044.ville.skytta@iki.fi>

On Wednesday 14 November 2007, Thorsten Leemhuis wrote:
> On 14.11.2007 20:44, Jason L Tibbitts III wrote:
>
> > Actually all of the relevant tests should get into rpmlint, and then
> > we can just run rpmlint.
>
> +1 (maybe with a --without-fedora cmd line parm to disable
> fedora-specific checks? or do we simply ignore that usage scenario?)

Better to tweak rpmlint's config to be as good as we can get it.  If the 
generic config doesn't become good enough so that it could be used to 
automatically fail builds, we can always use a separate config file 
(rpmlint -f) and try tweaking that.



From jkeating at redhat.com  Thu Nov 15 17:33:52 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 12:33:52 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C8218.6090801@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com>
Message-ID: <20071115123352.5140bb71@redhat.com>

On Thu, 15 Nov 2007 09:30:00 -0800
John Poelstra <poelstra at redhat.com> wrote:

> I've been thinking the same thing...you also lose liferea and pidgin
> which seems totally silly too!
> 
> Which component(s) should a bug be filed against?

You lose those because they have the capability of responding to
NetworkManager connection/disconnection events so that they can do the
right thing.  It would appear that they link to NetworkManager-glib,
and thus if you remove -glib you lose them.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/507ade0b/attachment.sig>

From jkeating at redhat.com  Thu Nov 15 17:34:50 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 12:34:50 -0500
Subject: Need an owner (and upstream?) for system-config-bind
Message-ID: <20071115123450.00bd5742@redhat.com>

system-config-bind is assigned to me right now, and I'm certainly not
going to do anything with it.  This needs not only a maintainer to own
it, but I think it also needs an upstream developer.

Any takers?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/378e93a2/attachment.sig>

From robert at marcanoonline.com  Thu Nov 15 17:36:12 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 15 Nov 2007 13:36:12 -0400
Subject: build servers kernel release (PPC64)
In-Reply-To: <20071115113217.6d023954@redhat.com>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com> <200711141607.50983.dennis@ausil.us>
	<1195143945.3132.3.camel@localhost.localdomain>
	<20071115113217.6d023954@redhat.com>
Message-ID: <1195148172.3132.6.camel@localhost.localdomain>

On Thu, 2007-11-15 at 11:32 -0500, Jesse Keating wrote:
> On Thu, 15 Nov 2007 12:25:44 -0400
> Robert Marcano <robert at marcanoonline.com> wrote:
> 
> > Tried it, but now the error is triggered on x86_64 architecture, It
> > looks like it is not the correct fix, the ppc64 architecture has no
> > time to build (it was canceled). I will try modifying the spec file
> > to only build ppc64
> 
> You could just do a scratch build targetting ppc64.  koji build
> --scratch dist-f9 --arch-override ppc64 foo.src.rpm

Thanks.. new trick learned. Bad news the error is the same on PPC64. It
is rare because i was able to build for x86_64 for F-8

http://koji.fedoraproject.org/koji/getfile?taskID=243268&name=build.log




From jkeating at redhat.com  Thu Nov 15 17:39:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 12:39:41 -0500
Subject: build servers kernel release (PPC64)
In-Reply-To: <1195148172.3132.6.camel@localhost.localdomain>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com> <200711141607.50983.dennis@ausil.us>
	<1195143945.3132.3.camel@localhost.localdomain>
	<20071115113217.6d023954@redhat.com>
	<1195148172.3132.6.camel@localhost.localdomain>
Message-ID: <20071115123941.665c996b@redhat.com>

On Thu, 15 Nov 2007 13:36:12 -0400
Robert Marcano <robert at marcanoonline.com> wrote:

> Thanks.. new trick learned. Bad news the error is the same on PPC64.
> It is rare because i was able to build for x86_64 for F-8
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=243268&name=build.log

Uh, is this trying to fire up a gui window and do something during
build?  There is no X on the builders....

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/89b26a70/attachment.sig>

From fedora at leemhuis.info  Thu Nov 15 17:44:41 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 15 Nov 2007 18:44:41 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195116253.28534.147.camel@mccallum.corsepiu.local>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B3FA8.70106@hhs.nl>
	<473B7424.3060407@leemhuis.info>
	<1195116253.28534.147.camel@mccallum.corsepiu.local>
Message-ID: <473C8589.2010109@leemhuis.info>

On 15.11.2007 09:44, Ralf Corsepius wrote:
> On Wed, 2007-11-14 at 23:18 +0100, Thorsten Leemhuis wrote:
> [...]
>> With getting fixed I'm not sure how to get that fixed exactly; maybe
>> work work more towards a Meritocracy-like way and lessen the influence
>> of the committees we have?
> What are you aiming at? [...]

If somebody (member of a committee or not) wants to do something let him
announce his plans and let him simply realize it if nobody yells loudly
(nobody could be an individual or a coordinating committee like FESCo or
FPC).

Example: take a look at the problem that I raised in
https://www.redhat.com/archives/fedora-packaging/2007-September/msg00060.html

The solution I proposed wasn't the best one (see later in the
discussion). But it could be a better solution for older releases; and
the proper solution for the problem was found in that thread as well.

I would have adjusted that the guidelines myself -- but that it not
wanted afaics and even prevented by ACLs in the Packaging/ space in the
wiki.

Thus I have to wait for the FPC to take care of it. Which it didn't do
until now. Sure, I could have tried harder -- but I wasn't much more
interested in dealing with the bureaucracy, so I ignored it. Which is
exatly the problem in Fedora-land: we have to much buerogracy and most
contributors don't want to deal with it, thus they leave the work to the
committee#s instead of helping them to do their work)

Similar problem (also not earth-shaking and a corner-case as well), also
still unfixed:
https://www.redhat.com/archives/fedora-packaging/2007-August/msg00092.html

Cu
knurd



From stransky at redhat.com  Thu Nov 15 17:45:09 2007
From: stransky at redhat.com (Martin Stransky)
Date: Thu, 15 Nov 2007 18:45:09 +0100
Subject: XULRunner in rawhide
In-Reply-To: <kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
References: <473AFF3E.1090904@redhat.com>
	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
Message-ID: <473C85A5.9020100@redhat.com>

Alex Lancaster wrote:
> Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
> package somehow?  Is there another BuildRequires I need to add?

First and experimental xulrunner-gtkmozembed is in 
rawhide/xulrunner-1.9-0.alpha9.5.fc9 now. I don't have any proper 
test-case (galeon doesn't compile because of some other problems) so it 
can fail but please test it...




From chris.stone at gmail.com  Thu Nov 15 17:46:21 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Thu, 15 Nov 2007 09:46:21 -0800
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115123352.5140bb71@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com> <20071115123352.5140bb71@redhat.com>
Message-ID: <d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>

On Nov 15, 2007 9:33 AM, Jesse Keating <jkeating at redhat.com> wrote:
> On Thu, 15 Nov 2007 09:30:00 -0800
> John Poelstra <poelstra at redhat.com> wrote:
>
> > I've been thinking the same thing...you also lose liferea and pidgin
> > which seems totally silly too!
> >
> > Which component(s) should a bug be filed against?
>
> You lose those because they have the capability of responding to
> NetworkManager connection/disconnection events so that they can do the
> right thing.  It would appear that they link to NetworkManager-glib,
> and thus if you remove -glib you lose them.

So I guess we need a pidgin-NM or something so pidgin can be installed
without NetworkManager.  I'm sure that there are hundreds of cases
like this in Fedora, and probably the #1 gripe among Fedora users
right now.  Modifying every package to split out every optional
component is a lot of work, but should be done.  I think an effort to
do this is key towards making Fedora a base distribution for all other
distributions.  The idea that you should install all optional
components for every package you install is good on paper but not in
practice, especially for making spins and custom distros.



From jreiser at BitWagon.com  Thu Nov 15 17:48:33 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Thu, 15 Nov 2007 09:48:33 -0800
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195143796.3140.110.camel@cookie.hadess.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
Message-ID: <473C8671.8040200@BitWagon.com>

> A live CD install on servers? You're walking all over your use cases :)

Does the live CD install istelf have a prominent advisory "Avoid using
LiveCD for these cases [see http://... for explanation]" ?

This may be fallout from "Fedora Project does not distribute CD images."
Physical media are comforting to administrators (changing the bits is
easy to detect and prevent), many servers lack DVD, creating a local repo
can be a hassle, install from network drive is not widely understood
(and when it doesn't work it is hard to figure out how to fix.)

-- 



From fedora at leemhuis.info  Thu Nov 15 17:48:50 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 15 Nov 2007 18:48:50 +0100
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <1195146887.12554.5.camel@localhost6.localdomain6>
References: <473BFADF.5080808@gmail.com> <473C0ABD.2090906@gmx.net>
	<1195146887.12554.5.camel@localhost6.localdomain6>
Message-ID: <473C8682.1020108@leemhuis.info>



On 15.11.2007 18:14, Richi Plana wrote:
> On Thu, 2007-11-15 at 10:00 +0100, Stefan Grosse wrote:
>> -------- Original Message  --------
>> Subject: kernel RPMs dependency on removing prior kernel?
>> From: Andrew Farris <lordmorgul at gmail.com>
>> To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
>> Date: 15.11.2007 08:53
>>>  ---> Package kmod-nvidia-2.6.23-6.fc8.i686 0:100.14.19-8.lvn8 set to be erased
>>>  --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
>>> kmod-nvidia-2.6.23.1-42.fc8
>>>  ---> Package kmod-nvidia-2.6.23.1-37.fc8.i686 0:100.14.19-14.lvn8 set to be erased
>>>  ---> Package kmod-nvidia-2.6.23.1-41.fc8.i686 0:100.14.19-15.lvn8 set to be erased
>>>  --> Finished Dependency Resolution
>>>  Error: Missing Dependency: kernel-i686 = 2.6.23.1-42.fc8 is needed by package
>>> kmod-nvidia-2.6.23.1-42.fc8
>>>
>>>   
>> This seems to be an already reported bug related to kmods. You find a
>> workaround here:
>> http://thorstenl.blogspot.com/2007/11/problems-updating-kernels-and-kmods.html
> 
> The workaround I tend to use is:
> 
> # yumdownloader kernel kernel-devel # only do kernel-devel if it's
> actually installed
> # rpm -ivh kernel-<newversion> kernel-devel-<newversion>
> # yum update
> # yum remove kernel-<oldestversion> # optional
> 
> This seems to pull in the updated kmods assuming the updated kmods are
> being pulled in by a "suite" package that is also updated. It also keeps
> the old kmods in case I want to fall back to an older kernel.

There is even a easier workaround mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=374711#c1
---
To escape this problem:
# yum install kernel-2.6.23.1-49.fc8
# yum update
---

But I didn't try yet it it really works.

CU
knurd




From dan at danny.cz  Thu Nov 15 18:01:04 2007
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 15 Nov 2007 19:01:04 +0100
Subject: build servers kernel release (PPC64)
In-Reply-To: <20071115123941.665c996b@redhat.com>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com> <200711141607.50983.dennis@ausil.us>
	<1195143945.3132.3.camel@localhost.localdomain>
	<20071115113217.6d023954@redhat.com>
	<1195148172.3132.6.camel@localhost.localdomain>
	<20071115123941.665c996b@redhat.com>
Message-ID: <1195149664.3180.2.camel@eagle.danny.cz>


Jesse Keating p??e v ?t 15. 11. 2007 v 12:39 -0500:
> On Thu, 15 Nov 2007 13:36:12 -0400
> Robert Marcano <robert at marcanoonline.com> wrote:
> 
> > Thanks.. new trick learned. Bad news the error is the same on PPC64.
> > It is rare because i was able to build for x86_64 for F-8
> > 
> > http://koji.fedoraproject.org/koji/getfile?taskID=243268&name=build.log
> 
> Uh, is this trying to fire up a gui window and do something during
> build?  There is no X on the builders....

Spot did some magic to use X on the builders for tinyerp. For details
see the spec file at
http://cvs.fedoraproject.org/viewcvs/rpms/tinyerp/devel/


		Dan




From ericsbinaryworld at gmail.com  Thu Nov 15 18:09:24 2007
From: ericsbinaryworld at gmail.com (Eric Mesa)
Date: Thu, 15 Nov 2007 13:09:24 -0500
Subject: flickr favorites screensaver?
In-Reply-To: <1195144322.3140.115.camel@cookie.hadess.net>
References: <64b14b300711150631g5eb17457i951b47ce8d5ef10e@mail.gmail.com>
	<1195144322.3140.115.camel@cookie.hadess.net>
Message-ID: <582715960711151009u7348d963l47176eb65f811dd0@mail.gmail.com>

there's one in Gdesklets...you can probably use that code to create a
screensaver or desktop changer or whatever it is you want.

On Nov 15, 2007 11:32 AM, Bastien Nocera <bnocera at redhat.com> wrote:
>
> On Thu, 2007-11-15 at 15:31 +0100, Valent Turkovic wrote:
> > Does anybody know any existing project for gnome ie. some screensaver
> > that downloads my favorite flickr pictures and slideshows them?
> >
> > I would like to contribute and donate to such a project...
>
> A nice screensaver based on clutter (see toys/fluttr in their SVN) would
> be a nice thing to add, although the initial configuration (allowing
> fluttr to access your photos) is a bit of a pain.
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Eric Mesa
http://www.ericsbinaryworld.com
http://server.ericsbinaryworld.com
"Do not worry about those things that are outside of your circle of
influence.  For since they are outside of your power to control them
it is simply a waste of time and energy to dwell on them.  Instead,
turn your attention to those things that you can control and grow your
influence in those areas and you will see the effects begin to trickle
out to those items that were previously out of your power to
influence." ? Eric Mesa inspired by Covey's 7 Habits of Highly
Effective People



From galibert at pobox.com  Thu Nov 15 18:10:35 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 15 Nov 2007 19:10:35 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C8671.8040200@BitWagon.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
Message-ID: <20071115181035.GA60438@dspnet.fr.eu.org>

On Thu, Nov 15, 2007 at 09:48:33AM -0800, John Reiser wrote:
> > A live CD install on servers? You're walking all over your use cases :)
> 
> Does the live CD install istelf have a prominent advisory "Avoid using
> LiveCD for these cases [see http://... for explanation]" ?
> 
> This may be fallout from "Fedora Project does not distribute CD images."
> Physical media are comforting to administrators (changing the bits is
> easy to detect and prevent), many servers lack DVD, creating a local repo
> can be a hassle, install from network drive is not widely understood
> (and when it doesn't work it is hard to figure out how to fix.)

Actually it was a fallout of "the livecd fits and boots from my 2G usb
key, the dvd doesn't".  I didn't realize the livecd was supposed to be
laptop-only.

Creating a local repo with any local changes requires having a machine
with f8 installed already so that you can run createrepo.

  OG.



From robert at marcanoonline.com  Thu Nov 15 18:22:35 2007
From: robert at marcanoonline.com (Robert Marcano)
Date: Thu, 15 Nov 2007 14:22:35 -0400
Subject: build servers kernel release (PPC64)
In-Reply-To: <20071115123941.665c996b@redhat.com>
References: <1194877715.3112.11.camel@localhost.localdomain>
	<47387994.7030500@gmail.com> <200711141607.50983.dennis@ausil.us>
	<1195143945.3132.3.camel@localhost.localdomain>
	<20071115113217.6d023954@redhat.com>
	<1195148172.3132.6.camel@localhost.localdomain>
	<20071115123941.665c996b@redhat.com>
Message-ID: <1195150955.3132.16.camel@localhost.localdomain>

On Thu, 2007-11-15 at 12:39 -0500, Jesse Keating wrote:
> On Thu, 15 Nov 2007 13:36:12 -0400
> Robert Marcano <robert at marcanoonline.com> wrote:
> 
> > Thanks.. new trick learned. Bad news the error is the same on PPC64.
> > It is rare because i was able to build for x86_64 for F-8
> > 
> > http://koji.fedoraproject.org/koji/getfile?taskID=243268&name=build.log
> 
> Uh, is this trying to fire up a gui window and do something during
> build?  There is no X on the builders....

It always has called eclipse in non gui mode to run the
org.eclipse.ant.core.antRunner Eclipse application. It builds perfectly
on i386, and the error does not looks like an X11 problem, it is a
segmentation fault. First i thought it was some kind of gcj+classpath
bug, but now that it fails on x86_64 looks more generic the problem (If
i am right icedtea is the default jvm on x84_64 too)



From notting at redhat.com  Thu Nov 15 18:30:05 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 15 Nov 2007 13:30:05 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com> <20071115123352.5140bb71@redhat.com>
	<d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
Message-ID: <20071115183005.GB27155@nostromo.devel.redhat.com>

Christopher Stone (chris.stone at gmail.com) said: 
> So I guess we need a pidgin-NM or something so pidgin can be installed
> without NetworkManager.  I'm sure that there are hundreds of cases
> like this in Fedora, and probably the #1 gripe among Fedora users
> right now.  Modifying every package to split out every optional
> component is a lot of work, but should be done.  I think an effort to
> do this is key towards making Fedora a base distribution for all other
> distributions.  The idea that you should install all optional
> components for every package you install is good on paper but not in
> practice, especially for making spins and custom distros.

Why? It's a 100k library dependency, and it doesn't actually *start*
NM to have the dependency. At what point do you ask for pidgin-ssl?

Bill



From galibert at pobox.com  Thu Nov 15 18:32:44 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 15 Nov 2007 19:32:44 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
Message-ID: <20071115183244.GB60438@dspnet.fr.eu.org>

On Thu, Nov 15, 2007 at 07:50:54AM -0900, Jeff Spaleta wrote:
> On Nov 15, 2007 7:01 AM, Olivier Galibert <galibert at pobox.com> wrote:
> > - once you rpm -e --nodeps it, you find out that the "network" service
> >   is not on by default either (liveCD install)
> 
> Perhaps we need to either make it even more clear what the usage case
> for the desktop livecd actually is.  I thought it was clear.  Or
> perhaps there is a compelling need for a server livecd that uses the
> legacy network stack by default.

Well, I would never have guessed that static IPs required specific
massaging and legacy network support.  Especially since it's a very
visible option of the installer in a mandatory dialog window.

At least if a message was added saying "any changes to this network
dialog will be ignored", you could get some free advertising on the
Daily WTF.


> Either way, the desktop livecd we
> are offering for F8 isn't intended to be the basis for situations for
> all networking scenarios.  That is why we continue to include the
> legacy network stack and why the legacy network stack is used by
> default on the traditional dvd install.
> 
> I'm sort of confused by your statements concerning the inability to
> turn NetworkManager off without having to remove the rpm.

I can only say I must have been confused too.  I looked for it in
chkconfig --list and managed to miss it.  Having it in chkconfig is
infinitely more sane.  My blood pressure just reduced by an order of
magnitude.


> In any event you should be able to turn off the NetworkManager
> initscript and enable the legacy network initscript if its not already
> running. None of this sysadmin activity requires uninstalling rpms.

Yup.  Having the standard install ignore and ever partially destroy
configurations the installer itself proposed to set is plain rude
though.



> -jef"Spends quite a large amount of time in buildings containing rooms
> that could be called 'labs' where most of the computers are immobile
> and yet the network admins use a consistent dhcp scheme with mac
> addressing  to register each and every computer on the network unless
> there is a demonstrated need for a static ip in which case you can
> request one. NetworkManager works just fine for 'lab' workstations
> here."spaleta

What's the point, though, unless you're in a setup where 90%+ of the
computers change every year[1]?

  OG.

[1] Known as "University" among other possibilities



From katzj at redhat.com  Thu Nov 15 18:42:40 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 15 Nov 2007 13:42:40 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115183244.GB60438@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
Message-ID: <1195152160.25986.5.camel@erebor.boston.redhat.com>

On Thu, 2007-11-15 at 19:32 +0100, Olivier Galibert wrote:
> On Thu, Nov 15, 2007 at 07:50:54AM -0900, Jeff Spaleta wrote:
> > On Nov 15, 2007 7:01 AM, Olivier Galibert <galibert at pobox.com> wrote:
> > > - once you rpm -e --nodeps it, you find out that the "network" service
> > >   is not on by default either (liveCD install)
> > 
> > Perhaps we need to either make it even more clear what the usage case
> > for the desktop livecd actually is.  I thought it was clear.  Or
> > perhaps there is a compelling need for a server livecd that uses the
> > legacy network stack by default.
> 
> Well, I would never have guessed that static IPs required specific
> massaging and legacy network support.  Especially since it's a very
> visible option of the installer in a mandatory dialog window.
> 
> At least if a message was added saying "any changes to this network
> dialog will be ignored", you could get some free advertising on the
> Daily WTF.

The problem is that we were supposed to have the magical new world of
NetworkManager goodness (and thus, consistency in network setup between
the live images and the rest of the distro) and when we had to freeze
strings for translations, it wasn't clear that we weren't going to get
there :(

For Fedora 9, we're shooting for having those bits again, but if we
don't have them well in advance of the translation freeze, we'll do
_something_ to make this experience better in the installer.  Because I
fully agree that it sucks :/

Jeremy



From jkeating at redhat.com  Thu Nov 15 18:44:17 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 13:44:17 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115183244.GB60438@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
Message-ID: <20071115134417.49b562a0@redhat.com>

On Thu, 15 Nov 2007 19:32:44 +0100
Olivier Galibert <galibert at pobox.com> wrote:

> What's the point, though, unless you're in a setup where 90%+ of the
> computers change every year[1]?

Because client creation is much easier if you just tell it to DHCP
rather than spending time to punch in technobabble numbers each time.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/38073638/attachment.sig>

From myfedora at richip.dhs.org  Thu Nov 15 18:49:26 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 15 Nov 2007 11:49:26 -0700
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <473C8682.1020108@leemhuis.info>
References: <473BFADF.5080808@gmail.com> <473C0ABD.2090906@gmx.net>
	<1195146887.12554.5.camel@localhost6.localdomain6>
	<473C8682.1020108@leemhuis.info>
Message-ID: <1195152566.15739.11.camel@localhost6.localdomain6>

On Thu, 2007-11-15 at 18:48 +0100, Thorsten Leemhuis wrote:
> 
> On 15.11.2007 18:14, Richi Plana wrote:
> > The workaround I tend to use is:
> > 
> > # yumdownloader kernel kernel-devel # only do kernel-devel if it's
> > actually installed
> > # rpm -ivh kernel-<newversion> kernel-devel-<newversion>
> > # yum update
> > # yum remove kernel-<oldestversion> # optional
> > 
> > This seems to pull in the updated kmods assuming the updated kmods are
> > being pulled in by a "suite" package that is also updated. It also keeps
> > the old kmods in case I want to fall back to an older kernel.
> 
> There is even a easier workaround mentioned in
> https://bugzilla.redhat.com/show_bug.cgi?id=374711#c1
> ---
> To escape this problem:
> # yum install kernel-2.6.23.1-49.fc8
> # yum update

Well, if that works, that should might help the yum developers in
tracking down where the logic error is. Can someone verify this? And
would a "yum install kernel" not work just as well (since yum logic
would glean the latest version automatically)?
--

Richi Plana



From jspaleta at gmail.com  Thu Nov 15 18:52:03 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 15 Nov 2007 09:52:03 -0900
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115183244.GB60438@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
Message-ID: <604aa7910711151052kba8864ek27628a9202a93b7a@mail.gmail.com>

On Nov 15, 2007 9:32 AM, Olivier Galibert <galibert at pobox.com> wrote:
> What's the point, though, unless you're in a setup where 90%+ of the
> computers change every year[1]?

the point... network hygiene and accountability.. to make it harder
for an unknown malicious person to connect an unknown computer into a
live network wall jack somewhere in your building and become a member
of that network segment with equal access to network data that
registered computers have.   If you require everyone to centrally
register and bind ips to mac addresses, then you make it much easier
to hold specific human beings accountable when the computers
registered to their names start acting maliciously.

-jef"Corporate and international governmental agency espionage is
awesome!"spaleta



From lesmikesell at gmail.com  Thu Nov 15 18:59:20 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 15 Nov 2007 12:59:20 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115181035.GA60438@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<1195143796.3140.110.camel@cookie.hadess.net>	<473C8671.8040200@BitWagon.com>
	<20071115181035.GA60438@dspnet.fr.eu.org>
Message-ID: <473C9708.3090307@gmail.com>

Olivier Galibert wrote:
> On Thu, Nov 15, 2007 at 09:48:33AM -0800, John Reiser wrote:
>>> A live CD install on servers? You're walking all over your use cases :)
>> Does the live CD install istelf have a prominent advisory "Avoid using
>> LiveCD for these cases [see http://... for explanation]" ?
>>
>> This may be fallout from "Fedora Project does not distribute CD images."
>> Physical media are comforting to administrators (changing the bits is
>> easy to detect and prevent), many servers lack DVD, creating a local repo
>> can be a hassle, install from network drive is not widely understood
>> (and when it doesn't work it is hard to figure out how to fix.)
> 
> Actually it was a fallout of "the livecd fits and boots from my 2G usb
> key, the dvd doesn't".  I didn't realize the livecd was supposed to be
> laptop-only.
> 
> Creating a local repo with any local changes requires having a machine
> with f8 installed already so that you can run createrepo.

Did anyone establish whether or not you can do an NFS install by 
pointing at a directory containing the dvd iso image like you used to be 
able to do with the set of cd images?  I thought I saw a message saying 
that no longer worked, which sounds pretty sysadmin-hostile too.  What's 
the right way to download one copy somewhere and install several 
machines from that image?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From katzj at redhat.com  Thu Nov 15 18:58:58 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 15 Nov 2007 13:58:58 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C9708.3090307@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
	<20071115181035.GA60438@dspnet.fr.eu.org>
	<473C9708.3090307@gmail.com>
Message-ID: <1195153138.25986.7.camel@erebor.boston.redhat.com>

On Thu, 2007-11-15 at 12:59 -0600, Les Mikesell wrote:
> Did anyone establish whether or not you can do an NFS install by 
> pointing at a directory containing the dvd iso image like you used to be 
> able to do with the set of cd images?  I thought I saw a message saying 
> that no longer worked, which sounds pretty sysadmin-hostile too.  What's 
> the right way to download one copy somewhere and install several 
> machines from that image?

It should still work AFAIK

Jeremy



From cmadams at hiwaay.net  Thu Nov 15 19:01:41 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 15 Nov 2007 13:01:41 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C8218.6090801@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com>
Message-ID: <20071115190141.GE1281632@hiwaay.net>

Once upon a time, John Poelstra <poelstra at redhat.com> said:
> chkconfig --del NetworkManager

This will not have the desired effect.  _Never_ use "chkconfig --del"
manually (unless you are manually uninstalling non-RPM-packaged
software).

You want "chkconfig NetworkManager off".

The problem with using --del is that it removes all references to
NetworkManager in the rc?.d directories.  The next time there is an
update to the NetworkManager RPM, it will run "chkconfig --add", which
will reset it to the default (which is to start on boot).  If you
instead turn it off, chkconfig will see it as already installed and do
nothing.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From lesmikesell at gmail.com  Thu Nov 15 19:04:58 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 15 Nov 2007 13:04:58 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115134417.49b562a0@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
Message-ID: <473C985A.8010202@gmail.com>

Jesse Keating wrote:
> On Thu, 15 Nov 2007 19:32:44 +0100
> Olivier Galibert <galibert at pobox.com> wrote:
> 
>> What's the point, though, unless you're in a setup where 90%+ of the
>> computers change every year[1]?
> 
> Because client creation is much easier if you just tell it to DHCP
> rather than spending time to punch in technobabble numbers each time.

What good are clients without servers?  And what are you supposed to do 
with all of the server-side software that comes with fedora if you don't 
have a static IP?

-- 
   Les Mikesell
    lesmikesell at gmail.com



From tmz at pobox.com  Thu Nov 15 19:07:13 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Thu, 15 Nov 2007 14:07:13 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C9708.3090307@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
	<20071115181035.GA60438@dspnet.fr.eu.org>
	<473C9708.3090307@gmail.com>
Message-ID: <20071115190713.GA320@psilocybe.teonanacatl.org>

Les Mikesell wrote:
> Did anyone establish whether or not you can do an NFS install by
> pointing at a directory containing the dvd iso image like you used
> to be able to do with the set of cd images?

Yes, this works.  I did it as recently as yesterday.

> I thought I saw a message saying that no longer worked, which sounds
> pretty sysadmin-hostile too.

Don't believe everything you read. :)

> What's the right way to download one copy somewhere and install
> several machines from that image?

That's a trick question.  There's more than one right way to do this.
You can use kickstart, you can use pxeboot, you could look at cobbler,
and varying combinations of these, plus others I'm not thinking of at
the moment.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I believe in the noble, aristocratic art of doing absolutely nothing.
And someday, I hope to be in a position where I can do even less.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/39271c94/attachment.sig>

From jkeating at redhat.com  Thu Nov 15 19:08:52 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 14:08:52 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C985A.8010202@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com> <473C985A.8010202@gmail.com>
Message-ID: <20071115140852.654ca31a@redhat.com>

On Thu, 15 Nov 2007 13:04:58 -0600
Les Mikesell <lesmikesell at gmail.com> wrote:

> What good are clients without servers?  And what are you supposed to
> do with all of the server-side software that comes with fedora if you
> don't have a static IP?

That's not what the OP was talking about.  Please stop taking every
posting of "dhcp would be good for this case" as "DO AWAY WITH ALL
STATIC IPS!!!"

But also realize that DHCP can be used as an automated method of
applying a static IP to a host.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/3d0163a6/attachment.sig>

From ianburrell at gmail.com  Thu Nov 15 19:11:18 2007
From: ianburrell at gmail.com (Ian Burrell)
Date: Thu, 15 Nov 2007 11:11:18 -0800
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115160124.GA40056@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
Message-ID: <d91f09cd0711151111i36ecdf25t6a2cb27eb8872ebe@mail.gmail.com>

On Nov 15, 2007 8:01 AM, Olivier Galibert <galibert at pobox.com> wrote:
> Bug #134886 is still there since fedora core 3 times.  It means that
> NetworkManager will happily shutdown the interfaces, ignore any
> settings you've put in anaconda and wipe out /etc/resolv.conf if you
> happen not to use dhcp.  Like in a lab, where desktops and servers
> tend not to wander around so much and dhcp is used only for laptops.
>

It seems to me that wiping out resolv.conf is the worst part.  It
destroys the static configuration.  I think the DHCP client should not
overwrite the existing /etc/resolv.conf but move it to a backup.  And
restore the previous version when it stops.

 - Ian



From galibert at pobox.com  Thu Nov 15 19:11:31 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 15 Nov 2007 20:11:31 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195143796.3140.110.camel@cookie.hadess.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
Message-ID: <20071115191131.GC60438@dspnet.fr.eu.org>

On Thu, Nov 15, 2007 at 04:23:16PM +0000, Bastien Nocera wrote:
> 
> On Thu, 2007-11-15 at 17:01 +0100, Olivier Galibert wrote:
> > Bug #134886 is still there since fedora core 3 times.  It means that
> > NetworkManager will happily shutdown the interfaces, ignore any
> > settings you've put in anaconda and wipe out /etc/resolv.conf if you
> > happen not to use dhcp.  Like in a lab, where desktops and servers
> > tend not to wander around so much and dhcp is used only for laptops.
> 
> Just disable NetworkManager in your kickstart file.

When you just try a livecd, and want to be able to used a couple of
tools from it to make the full install in the first place (createrepo
in particular)?  You realize you cannot even use a static ip when
running the livecd, right?  NM shoots any configuration you try to
make through the standard GUI tool that's in the system menu.


> A live CD install on servers? You're walking all over your use cases :)

static ip != server.  The desktop/server distinction is silly at best,
too.  I have mediawiki/apache running on my laptop - it's what I like
writing my notes into.  And I ssh *into* it on a regular basis.

  OG.




From jspaleta at gmail.com  Thu Nov 15 19:11:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 15 Nov 2007 10:11:58 -0900
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C985A.8010202@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com> <473C985A.8010202@gmail.com>
Message-ID: <604aa7910711151111t7ccd0ea4vfe35684763651aac@mail.gmail.com>

On Nov 15, 2007 10:04 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> What good are clients without servers?  And what are you supposed to do
> with all of the server-side software that comes with fedora if you don't
> have a static IP?

The dhcp server here at work uses MAC address binding to give me the
same exact address every time my machine comes back online.  When my
'servers' are disconnected from the network noone else gets to reuse
that ip address and I always get the same address. It works quite
nicely.

Hell, my home router appliance lets me set up 'quasi-static' ip
addresses on the local network using mac address binding and hand them
out to computers via dhcp.  People show up with laptops, they get a
dhcp address from outside that quasi-static pool.. and at no point
does anyone on my network need to type in an ip address or network
mask.  Services work, because the dhcp servers I rely on are managed
intellegently enough to make this a non-issue.

-jef



From nicolas.mailhot at laposte.net  Thu Nov 15 19:15:37 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Nov 2007 20:15:37 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C985A.8010202@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>  <473C985A.8010202@gmail.com>
Message-ID: <1195154137.7532.2.camel@rousalka.dyndns.org>


Le jeudi 15 novembre 2007 ? 13:04 -0600, Les Mikesell a ?crit :
> Jesse Keating wrote:
> > On Thu, 15 Nov 2007 19:32:44 +0100
> > Olivier Galibert <galibert at pobox.com> wrote:
> > 
> >> What's the point, though, unless you're in a setup where 90%+ of the
> >> computers change every year[1]?
> > 
> > Because client creation is much easier if you just tell it to DHCP
> > rather than spending time to punch in technobabble numbers each time.
> 
> What good are clients without servers?  And what are you supposed to do 
> with all of the server-side software that comes with fedora if you don't 
> have a static IP?

Any decent dhcp server will let you assign static ips to specific
systems, including servers. There is no reason to hardcode the ip on the
system itself.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/42e0caca/attachment.sig>

From galibert at pobox.com  Thu Nov 15 19:18:51 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 15 Nov 2007 20:18:51 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115134417.49b562a0@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
Message-ID: <20071115191851.GD60438@dspnet.fr.eu.org>

On Thu, Nov 15, 2007 at 01:44:17PM -0500, Jesse Keating wrote:
> On Thu, 15 Nov 2007 19:32:44 +0100
> Olivier Galibert <galibert at pobox.com> wrote:
> 
> > What's the point, though, unless you're in a setup where 90%+ of the
> > computers change every year[1]?
> 
> Because client creation is much easier if you just tell it to DHCP
> rather than spending time to punch in technobabble numbers each time.

Huh?  You get the mac address how?  Looks to me like you're trading
the need to type a simple IP address with a much larger complexity on
the server side, whatever you do.

  OG.



From myfedora at richip.dhs.org  Thu Nov 15 19:18:51 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 15 Nov 2007 12:18:51 -0700
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com> <20071115123352.5140bb71@redhat.com>
	<d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
Message-ID: <1195154331.17111.12.camel@localhost6.localdomain6>

On Thu, 2007-11-15 at 09:46 -0800, Christopher Stone wrote:
> On Nov 15, 2007 9:33 AM, Jesse Keating <jkeating at redhat.com> wrote:
> > On Thu, 15 Nov 2007 09:30:00 -0800
> > John Poelstra <poelstra at redhat.com> wrote:
> >
> > > I've been thinking the same thing...you also lose liferea and pidgin
> > > which seems totally silly too!
> > >
> > > Which component(s) should a bug be filed against?
> >
> > You lose those because they have the capability of responding to
> > NetworkManager connection/disconnection events so that they can do the
> > right thing.  It would appear that they link to NetworkManager-glib,
> > and thus if you remove -glib you lose them.
> 
> So I guess we need a pidgin-NM or something so pidgin can be installed
> without NetworkManager.  I'm sure that there are hundreds of cases
> like this in Fedora, and probably the #1 gripe among Fedora users
> right now.  Modifying every package to split out every optional
> component is a lot of work, but should be done.  I think an effort to
> do this is key towards making Fedora a base distribution for all other
> distributions.  The idea that you should install all optional
> components for every package you install is good on paper but not in
> practice, especially for making spins and custom distros.

I would suggest going back to the pidgin developers and seeing if the
NM-capability can't be separated into a run-time loadable shared object
(module) if it isn't already. That way that can be packaged separately
like any other pidgin module.
--

Richi Plana



From pemboa at gmail.com  Thu Nov 15 19:25:07 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 15 Nov 2007 13:25:07 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115191851.GD60438@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
	<20071115191851.GD60438@dspnet.fr.eu.org>
Message-ID: <16de708d0711151125r2ca46006i8ec35b5680deba51@mail.gmail.com>

On Nov 15, 2007 1:18 PM, Olivier Galibert <galibert at pobox.com> wrote:
> On Thu, Nov 15, 2007 at 01:44:17PM -0500, Jesse Keating wrote:
> > On Thu, 15 Nov 2007 19:32:44 +0100
> > Olivier Galibert <galibert at pobox.com> wrote:
> >
> > > What's the point, though, unless you're in a setup where 90%+ of the
> > > computers change every year[1]?
> >
> > Because client creation is much easier if you just tell it to DHCP
> > rather than spending time to punch in technobabble numbers each time.
>
> Huh?  You get the mac address how?  Looks to me like you're trading
> the need to type a simple IP address with a much larger complexity on
> the server side, whatever you do.

ifconfig gives mac addresses last i checked. One just makes a note of
the mac addresses of their serves, attach the same ip to the mac
address everytime, and then everything can be run on dynamic IPs.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From jkeating at redhat.com  Thu Nov 15 19:31:52 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 14:31:52 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115191131.GC60438@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<20071115191131.GC60438@dspnet.fr.eu.org>
Message-ID: <20071115143152.4170c48f@redhat.com>

On Thu, 15 Nov 2007 20:11:31 +0100
Olivier Galibert <galibert at pobox.com> wrote:

> static ip != server.  The desktop/server distinction is silly at best,
> too.  I have mediawiki/apache running on my laptop - it's what I like
> writing my notes into.  And I ssh *into* it on a regular basis.

And none of that means you can't use DHCP to deliver your
configuration, be it static, or pulled from a dynamic pool.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/56d192d6/attachment.sig>

From debarshi.ray at gmail.com  Thu Nov 15 19:37:56 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Fri, 16 Nov 2007 01:07:56 +0530
Subject: Claiming gnofract4d
In-Reply-To: <1195086765.24726.6.camel@Diffingo.localdomain>
References: <1195086765.24726.6.camel@Diffingo.localdomain>
Message-ID: <3170f42f0711151137rb9019b8ld1f97f1427532a87@mail.gmail.com>

> gnofact4d was orphaned a while ago, and I'd like to take ownership of
> it. I've already made the required changes in Package DB

So why is it still listed under
https://admin.fedoraproject.org/pkgdb/users/packages/orphan ?

I thought this PackageDB bug was already fixed.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From lesmikesell at gmail.com  Thu Nov 15 19:39:53 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 15 Nov 2007 13:39:53 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115140852.654ca31a@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>	<20071115183244.GB60438@dspnet.fr.eu.org>	<20071115134417.49b562a0@redhat.com>
	<473C985A.8010202@gmail.com> <20071115140852.654ca31a@redhat.com>
Message-ID: <473CA089.4010007@gmail.com>

Jesse Keating wrote:
> On Thu, 15 Nov 2007 13:04:58 -0600
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
>> What good are clients without servers?  And what are you supposed to
>> do with all of the server-side software that comes with fedora if you
>> don't have a static IP?
> 
> That's not what the OP was talking about.  Please stop taking every
> posting of "dhcp would be good for this case" as "DO AWAY WITH ALL
> STATIC IPS!!!"

I thought this thread was about static IPs not working at all in certain 
install scenarios - and someone else was suggesting the right solution 
was "don't use static IP's".

> But also realize that DHCP can be used as an automated method of
> applying a static IP to a host.

I'd call that shifting the work to someone else, not actually automating it.

-- 
   Les Mikesell
    lesmikesell at gmail.com





From lordmorgul at gmail.com  Thu Nov 15 19:40:08 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Thu, 15 Nov 2007 11:40:08 -0800
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <1195152566.15739.11.camel@localhost6.localdomain6>
References: <473BFADF.5080808@gmail.com>
	<473C0ABD.2090906@gmx.net>	<1195146887.12554.5.camel@localhost6.localdomain6>	<473C8682.1020108@leemhuis.info>
	<1195152566.15739.11.camel@localhost6.localdomain6>
Message-ID: <473CA098.2030304@gmail.com>

Richi Plana wrote:
> On Thu, 2007-11-15 at 18:48 +0100, Thorsten Leemhuis wrote:
>> On 15.11.2007 18:14, Richi Plana wrote:
>>> The workaround I tend to use is:
>>>
>>> # yumdownloader kernel kernel-devel # only do kernel-devel if it's
>>> actually installed
>>> # rpm -ivh kernel-<newversion> kernel-devel-<newversion>
>>> # yum update
>>> # yum remove kernel-<oldestversion> # optional
>>>
>>> This seems to pull in the updated kmods assuming the updated kmods are
>>> being pulled in by a "suite" package that is also updated. It also keeps
>>> the old kmods in case I want to fall back to an older kernel.
>> There is even a easier workaround mentioned in
>> https://bugzilla.redhat.com/show_bug.cgi?id=374711#c1
>> ---
>> To escape this problem:
>> # yum install kernel-2.6.23.1-49.fc8
>> # yum update
> 
> Well, if that works, that should might help the yum developers in
> tracking down where the logic error is. Can someone verify this? And
> would a "yum install kernel" not work just as well (since yum logic
> would glean the latest version automatically)?

I'm sorry for the noise about this issue, but it doesnt seem to be that simple.

The above does not work.  The issue is that yum tries to solve the dependencies
for the kmod-nvidia package AS IF it were going to remove the last kernel during
an update with installonlyn behavior... it fails because it is deciding the
kmod-nvidia package needs the kernel (correct) but in reality yum is not going
to remove the kernel that the kmod-nvidia package depends on.

Removing the kmod package lets the install work as one of my last emails shows,
it fails first, I remove the kmod-nvidia package, and it then works.  The 1-42
kernel is not removed, so there is no reason this should fail in the first attempt.


- yum install kernel-2.6.23.1-49.fc8
 fedora                    100% |=========================| 2.1 kB    00:00
 livna-development         100% |=========================| 2.1 kB    00:00
 updates-testing           100% |=========================| 2.3 kB    00:00
 livna                     100% |=========================| 2.1 kB    00:00
 updates                   100% |=========================| 2.3 kB    00:00
 Setting up Install Process
 Parsing package install arguments
 Resolving Dependencies
 --> Running transaction check
 --> Processing Dependency: kernel-i686 = 2.6.23.1-42.fc8 for package:
kmod-nvidia-2.6.23.1-42.fc8
 ---> Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
 --> Finished Dependency Resolution
 Error: Missing Dependency: kernel-i686 = 2.6.23.1-42.fc8 is needed by package
kmod-nvidia-2.6.23.1-42.fc8

 - rpm -e --nodeps kmod-nvidia-2.6.23.1-42.fc8

- yum install kernel-2.6.23.1-49.fc8
 Loading "refresh-updatesd" plugin
  Setting up Install Process
  Parsing package install arguments
  Resolving Dependencies
  -- Package kernel.i686 0:2.6.23.1-49.fc8 set to be updated
  --> Finished Dependency Resolution

  Dependencies Resolved
...

 - rpm -q kernel
 kernel-2.6.23-6.fc8
 kernel-2.6.23.1-37.fc8
 kernel-2.6.23.1-41.fc8
 kernel-2.6.23.1-42.fc8
 kernel-2.6.23.1-49.fc8

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From lesmikesell at gmail.com  Thu Nov 15 19:44:31 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 15 Nov 2007 13:44:31 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <16de708d0711151125r2ca46006i8ec35b5680deba51@mail.gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>	<20071115183244.GB60438@dspnet.fr.eu.org>	<20071115134417.49b562a0@redhat.com>	<20071115191851.GD60438@dspnet.fr.eu.org>
	<16de708d0711151125r2ca46006i8ec35b5680deba51@mail.gmail.com>
Message-ID: <473CA19F.2060708@gmail.com>

Arthur Pemberton wrote:

>>>
>>>> What's the point, though, unless you're in a setup where 90%+ of the
>>>> computers change every year[1]?
>>> Because client creation is much easier if you just tell it to DHCP
>>> rather than spending time to punch in technobabble numbers each time.
>> Huh?  You get the mac address how?  Looks to me like you're trading
>> the need to type a simple IP address with a much larger complexity on
>> the server side, whatever you do.
> 
> ifconfig gives mac addresses last i checked. One just makes a note of
> the mac addresses of their serves, attach the same ip to the mac
> address everytime, and then everything can be run on dynamic IPs.

That's not a horrible idea, but not really simpler than assigning the IP 
directly - and it gets a little weird when you start copying vmware 
images around in ways that make them want to make up new mac addresses.

There's also a problem where you have multiple nics and need to assign 
some non-default static routes to one or more.  I don't think there is a 
way to do that with dhcp.

-- 
  Les Mikesell
    lesmikesell at gmail.com



From dcbw at redhat.com  Thu Nov 15 19:40:40 2007
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 15 Nov 2007 14:40:40 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195154331.17111.12.camel@localhost6.localdomain6>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com> <20071115123352.5140bb71@redhat.com>
	<d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
	<1195154331.17111.12.camel@localhost6.localdomain6>
Message-ID: <1195155640.15950.12.camel@localhost.localdomain>

On Thu, 2007-11-15 at 12:18 -0700, Richi Plana wrote:
> On Thu, 2007-11-15 at 09:46 -0800, Christopher Stone wrote:
> > On Nov 15, 2007 9:33 AM, Jesse Keating <jkeating at redhat.com> wrote:
> > > On Thu, 15 Nov 2007 09:30:00 -0800
> > > John Poelstra <poelstra at redhat.com> wrote:
> > >
> > > > I've been thinking the same thing...you also lose liferea and pidgin
> > > > which seems totally silly too!
> > > >
> > > > Which component(s) should a bug be filed against?
> > >
> > > You lose those because they have the capability of responding to
> > > NetworkManager connection/disconnection events so that they can do the
> > > right thing.  It would appear that they link to NetworkManager-glib,
> > > and thus if you remove -glib you lose them.
> > 
> > So I guess we need a pidgin-NM or something so pidgin can be installed
> > without NetworkManager.  I'm sure that there are hundreds of cases
> > like this in Fedora, and probably the #1 gripe among Fedora users
> > right now.  Modifying every package to split out every optional
> > component is a lot of work, but should be done.  I think an effort to
> > do this is key towards making Fedora a base distribution for all other
> > distributions.  The idea that you should install all optional
> > components for every package you install is good on paper but not in
> > practice, especially for making spins and custom distros.
> 
> I would suggest going back to the pidgin developers and seeing if the
> NM-capability can't be separated into a run-time loadable shared object
> (module) if it isn't already. That way that can be packaged separately
> like any other pidgin module.

You don't have to use libnm-glib at all; it's pretty simple to use
straight D-Bus to do what needs to be done.

Dan



From ajackson at redhat.com  Thu Nov 15 20:26:18 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 15 Nov 2007 15:26:18 -0500
Subject: Severe X breakage heads up
In-Reply-To: <200711151704.00187.jamatos@fc.up.pt>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<1195003708.2292.13.camel@localhost.localdomain>
	<200711151704.00187.jamatos@fc.up.pt>
Message-ID: <1195158378.2292.35.camel@localhost.localdomain>

On Thu, 2007-11-15 at 17:03 +0000, Jos? Matos wrote:
> On Wednesday 14 November 2007 01:28:28 Adam Jackson wrote:
> > I'll be cleaning up the rest of the mess as we go.  Please do file bugs
> > about any weirdness you encounter (outside of the above known caveats).
> 
>   In my case the driver sis was not present, so I have reset to vesa according 
> to your advice.
> 
>   Vesa does not work because my monitor warns "Attention, Out of range, 
> H:89.6KHz V:59.7Hz". To regain the control of the screen I have to kill X.
> 
>   I have removed the horizontal and vertical ranges from the configuration 
> file to allow DDC probing and the result is the same.
> 
>   Attached I send the log and lspci output.
> 
> This is the same monitor that I have filled a bugzilla recently because it did 
> not allowed anymore the 1280*1024 resolution that used to allow until some 
> weeks ago.
> https://bugzilla.redhat.com/show_bug.cgi?id=353641

Yeah, I remember that one.  I think I know what the fix should be for
that situation now, just need to write it.

- ajax



From lesmikesell at gmail.com  Thu Nov 15 19:52:17 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 15 Nov 2007 13:52:17 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115143152.4170c48f@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<1195143796.3140.110.camel@cookie.hadess.net>	<20071115191131.GC60438@dspnet.fr.eu.org>
	<20071115143152.4170c48f@redhat.com>
Message-ID: <473CA371.1060808@gmail.com>

Jesse Keating wrote:

>> static ip != server.  The desktop/server distinction is silly at best,
>> too.  I have mediawiki/apache running on my laptop - it's what I like
>> writing my notes into.  And I ssh *into* it on a regular basis.
> 
> And none of that means you can't use DHCP to deliver your
> configuration, be it static, or pulled from a dynamic pool.

The fact that you _can_ use some outside mechanism to handle IP 
assignments doesn't really excuse an OS from making it reasonably 
convenient to do it locally.

On the other hand, in spite of my grousing about assignments during 
installs, what I almost always do in practice is let a new machine take 
a dhcp address as I load it, making a note of it so I can connect 
remotely to finish up and do updates, then set the static address only 
when it is actually ready to provide the service(s) expected at that 
address.

-- 
   Les Mikesell
     lesmikesell at gmail.com



From debarshi.ray at gmail.com  Thu Nov 15 20:05:22 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Fri, 16 Nov 2007 01:35:22 +0530
Subject: Taking over redet
Message-ID: <3170f42f0711151205q2eadc60uce4bab0281125b6b@mail.gmail.com>

https://admin.fedoraproject.org/pkgdb/packages/name/redet

I would like to take over redet. I have already made the changes in
PackageDB reagrding that. However I am not interested in the EPEL
branches, so they are still going to be without a owner.

Hope it is fine with all of you.

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From jspaleta at gmail.com  Thu Nov 15 20:13:22 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 15 Nov 2007 11:13:22 -0900
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473CA371.1060808@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<20071115191131.GC60438@dspnet.fr.eu.org>
	<20071115143152.4170c48f@redhat.com> <473CA371.1060808@gmail.com>
Message-ID: <604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>

On Nov 15, 2007 10:52 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> The fact that you _can_ use some outside mechanism to handle IP
> assignments doesn't really excuse an OS from making it reasonably
> convenient to do it locally.
Caveats abound:

the frustration only affects the livecds we ship. it does not affect
the anaconda based installer on the traditional dvd image.  If there
was an expectation that people who use the livecd as install targets
for machines with static ips, I don't remember that coming up at any
point in the F7 or F8 testing cycle. There was more than enough time
for someone,anyone to make the case and develop a livecd spin that
used the legacy stack by default instead of NM for use as a live media
target for static ip situations. I don't remember anyone bringing this
up in the context of livecd spin target usage leading up to F8.

I think there very well maybe a valid usage case here for a legacy
network stack using live image as a useful install target for static
ip networks. But its almost too late for a discussion about it to
matter much since NM should have static ip support by F9 and be the
default stack for all installable images.. whether live or not.

-jef



From ville.skytta at iki.fi  Thu Nov 15 20:14:12 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 15 Nov 2007 22:14:12 +0200
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473CA19F.2060708@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<16de708d0711151125r2ca46006i8ec35b5680deba51@mail.gmail.com>
	<473CA19F.2060708@gmail.com>
Message-ID: <200711152214.12421.ville.skytta@iki.fi>

On Thursday 15 November 2007, Les Mikesell wrote:
> Arthur Pemberton wrote:

> > ifconfig gives mac addresses last i checked. One just makes a note of
> > the mac addresses of their serves, attach the same ip to the mac
> > address everytime, and then everything can be run on dynamic IPs.
>
> That's not a horrible idea, but not really simpler than assigning the IP
> directly

It's not only the IP.  There are DNS servers, gateways, WINS servers, NTP 
servers and whatnot that can be conveniently managed in one place on the DHCP 
server.



From dominik at greysector.net  Thu Nov 15 20:20:16 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 15 Nov 2007 21:20:16 +0100
Subject: libdvdread soname bump heads up
Message-ID: <20071115202015.GA11437@ryvius.greysector.net>

Libdvdnav-4.1.1 (which builds libdvdread, too) is hitting rawhide.
And only rawhide for now.

Libdvdread and libdvdnav development has been taken over by a new
upstream (one of MPlayer developers). The current release contains
libdvdread.so.4 instead of libdvdread.so.3 in old 0.9.x series.

Affected packages: dvdauthor, k3b, lsdvd and python-kaa-metadata.
Please rebuild and check if they still work properly. I'm not expecting
any problems.

The old libdvdread will be marked as dead.package shortly.

Regards,
R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From fedora at leemhuis.info  Thu Nov 15 20:23:35 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 15 Nov 2007 21:23:35 +0100
Subject: kernel RPMs dependency on removing prior kernel?
In-Reply-To: <1195152566.15739.11.camel@localhost6.localdomain6>
References: <473BFADF.5080808@gmail.com>
	<473C0ABD.2090906@gmx.net>	<1195146887.12554.5.camel@localhost6.localdomain6>	<473C8682.1020108@leemhuis.info>
	<1195152566.15739.11.camel@localhost6.localdomain6>
Message-ID: <473CAAC7.8080802@leemhuis.info>



On 15.11.2007 19:49, Richi Plana wrote:
> On Thu, 2007-11-15 at 18:48 +0100, Thorsten Leemhuis wrote:
>> On 15.11.2007 18:14, Richi Plana wrote:
> [...]
> Well, if that works, that should might help the yum developers in
> tracking down where the logic error is.

About one month ago the likely cause was mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=330711#c3
already:

---
okay I think I know what's going on. We're adding the kernel as an
update when it is really an install. The old kernel is being added as
'being updated' so the depsolver is looking at it like it needs to be
removed.

I'm looking into it a bit deeper but I'm pretty sure that's the case.
---

>From looking closer at
https://bugzilla.redhat.com/attachment.cgi?id=226441
it seems this is correct:

First it sees the new kernel and marks it as "updated"

> ---> Package kernel.x86_64 0:2.6.23-6.fc8 set to be updated
> Checking deps for kernel.x86_64 0-2.6.23-6.fc8 - u

Then it checks the deps for the new kmods from the repo and those that
remain installed for the old kernel:

> kmod-ntfs-2.6.23-0.224.rc9.git6.fc8 requires: kernel-x86_64 = 2.6.23-0.224.rc9.git6.fc8
> --> Processing Dependency: kernel-x86_64 = 2.6.23-0.224.rc9.git6.fc8 for package: kmod-ntfs-2.6.23-0.224.rc9.git6.fc8
> Needed Require is not a package name. Looking up: kernel-x86_64 = 2.6.23-0.224.rc9.git6.fc8

This if course fails, as yum at this points thinks the old kernel is
going to be removed during update:

> Potential Provider: kernel.x86_64 0:2.6.23-0.224.rc9.git6.fc8
> Mode is u for provider of kernel-x86_64 = 2.6.23-0.224.rc9.git6.fc8: kernel.x86_64 0:2.6.23-0.224.rc9.git6.fc8
> Mode for pkg providing kernel-x86_64 = 2.6.23-0.224.rc9.git6.fc8: u
> Cannot find an update path for dep for: kernel-x86_64 = 2.6.23-0.224.rc9.git6.fc8
> Searching pkgSack for dep: kernel-x86_64

Only right before the end the new kernel is marked as to be installed
(and not updated):

> kernel - 2.6.23-6.fc8.x86_64 converted to install

This is (afaics with my limited skills) the problem -- this convert
needs to happen way earlier or the deps need to be rechecked after this
convert.

CU
knurd



From lesmikesell at gmail.com  Thu Nov 15 20:25:20 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 15 Nov 2007 14:25:20 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <200711152214.12421.ville.skytta@iki.fi>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<16de708d0711151125r2ca46006i8ec35b5680deba51@mail.gmail.com>	<473CA19F.2060708@gmail.com>
	<200711152214.12421.ville.skytta@iki.fi>
Message-ID: <473CAB30.9000201@gmail.com>

Ville Skytt? wrote:
> On Thursday 15 November 2007, Les Mikesell wrote:
>> Arthur Pemberton wrote:
> 
>>> ifconfig gives mac addresses last i checked. One just makes a note of
>>> the mac addresses of their serves, attach the same ip to the mac
>>> address everytime, and then everything can be run on dynamic IPs.
>> That's not a horrible idea, but not really simpler than assigning the IP
>> directly
> 
> It's not only the IP.  There are DNS servers, gateways, WINS servers, NTP 
> servers and whatnot that can be conveniently managed in one place on the DHCP 
> server.

And routes, which DHCP can't handle, other than the default.

-- 
   Les Mikesell
    lesmikesell at gmail.com




From pemboa at gmail.com  Thu Nov 15 20:28:56 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 15 Nov 2007 14:28:56 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473CA19F.2060708@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
	<20071115191851.GD60438@dspnet.fr.eu.org>
	<16de708d0711151125r2ca46006i8ec35b5680deba51@mail.gmail.com>
	<473CA19F.2060708@gmail.com>
Message-ID: <16de708d0711151228j4ec3a212q4766f7a2d7c42236@mail.gmail.com>

On Nov 15, 2007 1:44 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> Arthur Pemberton wrote:
>
> >>>
> >>>> What's the point, though, unless you're in a setup where 90%+ of the
> >>>> computers change every year[1]?
> >>> Because client creation is much easier if you just tell it to DHCP
> >>> rather than spending time to punch in technobabble numbers each time.
> >> Huh?  You get the mac address how?  Looks to me like you're trading
> >> the need to type a simple IP address with a much larger complexity on
> >> the server side, whatever you do.
> >
> > ifconfig gives mac addresses last i checked. One just makes a note of
> > the mac addresses of their serves, attach the same ip to the mac
> > address everytime, and then everything can be run on dynamic IPs.
>
> That's not a horrible idea, but not really simpler than assigning the IP
> directly - and it gets a little weird when you start copying vmware
> images around in ways that make them want to make up new mac addresses.


Fair enough. Although for non vm situations, i think it's easier.


> There's also a problem where you have multiple nics and need to assign
> some non-default static routes to one or more.  I don't think there is a
> way to do that with dhcp.

Just to be clear, I was just providing a suggestion to _one_ of the problems.

Last time I checked, I hated NetworkManager, not sure how good/bad it is in F8

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From dwalsh at redhat.com  Thu Nov 15 20:48:18 2007
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Thu, 15 Nov 2007 15:48:18 -0500
Subject: System-Config-Firewall, Bluetooth, CodecBuddy,
 System-Config-Selinux and an BB/Nanny
In-Reply-To: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
Message-ID: <473CB092.8070100@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J?hann B. Gu?mundsson wrote:
> First of all thanks to all the sponsors/developers/testers/maintainers/
> people contributing/work on/in creating Fedora..
> 
> I manage to gather a couple of people/"lab rats" with little
> to none technical skills at the price of beer,wine and food last weekend.
> I had couple of computers and my "toys" on a table for them to play with.
> ( mp3 player cameras etc.. and yes they all worked with Fedora but they
> did not know that, age group 30 to 50 both genders )controlled enviroment.
> 
> They installed and used Werewolf and I got to watch them do that ;) ...
> What came out of this other than an great party afterwards was....
> 
> So let's skip the usually things we all know are great...
> 
> System-config-firewall this was the first time that
> my human technical challenge lab rats could use it with
> comfort and ease and could grasp when I explained how to use
> it.
> 
> 2 RFE came out of this torrent ports were missing from the hasable list
> and 1 user was wondering if there was some stats app about how many
> "virus/attacks" he avoided ( block/drop packages ) his question
> comes from those anti virus apps I suppose...
> Will file that when I have time..
> 
> And I believe that this deserves the N1 place in "on the hood"
> from noob user perspective changes in FC8..
> 
> The second place goes to CodecBuddy people did mind
> paying for media codecs as long as they could play their media
> but they did mind have to register instead
> of getting to pay instantly/now/paypal button but then
> again its fluendo problem losing money out the window..
> 
> In the third place from noob user perspective "on the hood"
> Bluetooth, Why third? because all those lab rats knew or some
> didnt know that their phone had bluetooth and all those noob users
> had never used it nor turned it on ofcourse I tested them and and yes they
> all worked..
> 
> System-config-Selinux notifier wtf for the noob...
> I triggered an selinux alert and shtf and here we are at impass
> Even if we make the "notice" more userfriendly, we cant have
> *next* ( which they wanted ) button to solve it because we dont
> want the user to allow something that should not be allowed
> ( and yes these users would press the next button to make it go away )
> I gave this a great deal of thought and came up with nothing
> just that this will always be a problem.
> ( no we dont want users to disable this with disable me button,
> because whats the point having it if everybody disable it. )
> 
> Now I was asked if there was available Bigbrother/Nanny software
> that could protect/monitor their children computer usage
> from all the harm and danger the internet can bring?
> 
> Anything anyone?
> 
> Does Redhat have this covered before rolling out Redhat-Desktop
> 
> Something that can ease the mind of parents?
> 
> Best Regards
>           Johann B.
> 
Did you install and run setroubleshoot?

The goal of this package is to be the "nanny"

> Ps. Somebody might wanna update the wiki page to mention
>     Werewolf as current maintainded release, and take out Zod
>     ( http://fedoraproject.org/wiki/Releases )
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHPLCSrlYvE4MpobMRAjQOAJ0fnWO627WZQiSQ31lccpZCHWDkAwCgrfPN
r0X3kO/MyOzKEIWGH/GAVUk=
=dTH9
-----END PGP SIGNATURE-----



From valent.turkovic at gmail.com  Thu Nov 15 20:50:17 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 15 Nov 2007 21:50:17 +0100
Subject: are you (fedora devels) using fluendo codecs?
Message-ID: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>

Look at this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=355291

Have any redhat and fedora devels actually used fluendo codecs? I
can't believe that I'm only one noticing this bugs...

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From rdieter at math.unl.edu  Thu Nov 15 20:55:54 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 15 Nov 2007 14:55:54 -0600
Subject: are you (fedora devels) using fluendo codecs?
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
Message-ID: <fhibor$h18$1@ger.gmane.org>

Valent Turkovic wrote:

> Look at this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=355291
> Have any redhat and fedora devels actually used fluendo codecs?

Strictly speaking, these are fluendo's problems, not fedora's.

-- Rex 




From braden at endoframe.com  Thu Nov 15 21:00:56 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Thu, 15 Nov 2007 16:00:56 -0500
Subject: libGLU missing on x86_64 build machine?
Message-ID: <473CB388.3060507@endoframe.com>

I got this configure failure on x86_64 when attempting to build openvrml:

   checking for OpenGL library... -lGL
   checking for OpenGL Utility library... no
   configure: error: the OpenGL Utility library (libGLU) is required for
   the GL renderer

Did I catch the machine at a bad time, or is something else going on here?

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From myfedora at richip.dhs.org  Thu Nov 15 21:12:02 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 15 Nov 2007 14:12:02 -0700
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <fhibor$h18$1@ger.gmane.org>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
Message-ID: <1195161122.18227.3.camel@localhost6.localdomain6>

On Thu, 2007-11-15 at 14:55 -0600, Rex Dieter wrote:
> Valent Turkovic wrote:
> 
> > Look at this bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=355291
> > Have any redhat and fedora devels actually used fluendo codecs?
> 
> Strictly speaking, these are fluendo's problems, not fedora's.

Strictly speaking, these are Fedora's users' problems.

Valent, you've been keeping tabs on developments with this issue. Could
you summarize what suggestions have been made to solve it and who made
these suggestions? Just the positive feedback, if you please.
--

Richi Plana



From jhrozek at redhat.com  Thu Nov 15 21:16:41 2007
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Thu, 15 Nov 2007 22:16:41 +0100
Subject: Bugzilla Versions :: Request for Community & FESCo review
In-Reply-To: <473B6E47.7090004@redhat.com>
References: <473B6E47.7090004@redhat.com>
Message-ID: <200711152216.42286.jhrozek@redhat.com>

On Wednesday 14 November 2007 10:53:11 pm John Poelstra wrote:
> 6) Bonus points if we can disable the ability to file new bugs against
> releases that are no longer supported, for example, FC(1..5).

What about providing a canned response saying that "We no longer support 
Fedora X, can you please try to reproduce the bug in a recent Fedora 
release?" and setting the state to NEEDINFO [1], instead of banning users 
from entering such a bug?

Jakub

[1] I don't know if it can be done in an automated way, this is just an 
idea :-)



From jkeating at redhat.com  Thu Nov 15 21:22:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 16:22:14 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195161122.18227.3.camel@localhost6.localdomain6>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
Message-ID: <20071115162214.35cd3807@redhat.com>

On Thu, 15 Nov 2007 14:12:02 -0700
Richi Plana <myfedora at richip.dhs.org> wrote:

> Valent, you've been keeping tabs on developments with this issue.
> Could you summarize what suggestions have been made to solve it and
> who made these suggestions? Just the positive feedback, if you please.

Fluendo could use a non-closed source compiler (I suggest gcc) so that
the binaries could be made to not need execmem.

Fedora could modify the policy to allow for execmem from these files
(not sure what the side effects of that are, nor how far reaching this
would be given that the codecs are used in gstreamer).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/008b129f/attachment.sig>

From braden at endoframe.com  Thu Nov 15 21:25:06 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Thu, 15 Nov 2007 16:25:06 -0500
Subject: libGLU missing on x86_64 build machine?
In-Reply-To: <473CB388.3060507@endoframe.com>
References: <473CB388.3060507@endoframe.com>
Message-ID: <473CB932.3010907@endoframe.com>

Braden McDaniel wrote:
> I got this configure failure on x86_64 when attempting to build openvrml:
> 
>   checking for OpenGL library... -lGL
>   checking for OpenGL Utility library... no
>   configure: error: the OpenGL Utility library (libGLU) is required for
>   the GL renderer
> 
> Did I catch the machine at a bad time, or is something else going on here?

Looks to be SELinux related and should be fixed soon (thanks spot).

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>



From dennis at ausil.us  Thu Nov 15 21:26:11 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Thu, 15 Nov 2007 15:26:11 -0600
Subject: libGLU missing on x86_64 build machine?
In-Reply-To: <473CB388.3060507@endoframe.com>
References: <473CB388.3060507@endoframe.com>
Message-ID: <200711151526.21760.dennis@ausil.us>

On Thursday 15 November 2007, Braden McDaniel wrote:
> I got this configure failure on x86_64 when attempting to build openvrml:
>
>    checking for OpenGL library... -lGL
>    checking for OpenGL Utility library... no
>    configure: error: the OpenGL Utility library (libGLU) is required for
>    the GL renderer
>
> Did I catch the machine at a bad time, or is something else going on here?
>
> --
> Braden McDaniel                      e-mail: <braden at endoframe.com>
> <http://endoframe.com>               Jabber: <braden at jabber.org>

the minimal build root that is created each build only includes the specified 
minimal packages and packages you build requires.   It sounds like you are 
missing a build requires.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/c7bfecdd/attachment.sig>

From lemenkov at gmail.com  Thu Nov 15 21:39:13 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Fri, 16 Nov 2007 00:39:13 +0300
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
Message-ID: <adf480660711151339n3f4ccff9k185378cd552444d5@mail.gmail.com>

2007/11/15, Valent Turkovic <valent.turkovic at gmail.com>:
> Look at this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=355291
>
> Have any redhat and fedora devels actually used fluendo codecs? I

Actually very few if any - there is no reason to use these BLOBs if
you are living in civilized society. Some testers or programmers or
citizens of US - maybe they use them sometimes.

-- 
With best regards!



From jamatos at fc.up.pt  Thu Nov 15 21:43:26 2007
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Thu, 15 Nov 2007 21:43:26 +0000
Subject: Severe X breakage heads up
In-Reply-To: <1195158378.2292.35.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<200711151704.00187.jamatos@fc.up.pt>
	<1195158378.2292.35.camel@localhost.localdomain>
Message-ID: <200711152143.27290.jamatos@fc.up.pt>

On Thursday 15 November 2007 20:26:18 Adam Jackson wrote:
> Yeah, I remember that one. ?I think I know what the fix should be for
> that situation now, just need to write it.

  OK. Thanks. :-)

> - ajax

-- 
Jos? Ab?lio



From david at lovesunix.net  Thu Nov 15 21:56:03 2007
From: david at lovesunix.net (David Nielsen)
Date: Thu, 15 Nov 2007 22:56:03 +0100
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
Message-ID: <1195163763.2797.25.camel@dawkins>


tor, 15 11 2007 kl. 21:50 +0100, skrev Valent Turkovic:
> Look at this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=355291
> 
> Have any redhat and fedora devels actually used fluendo codecs? I
> can't believe that I'm only one noticing this bugs...

I as a beta tester for Fluendo I employ them but I have SELinux in
permissive mode currently also I am not certain of the versions I have
installed are the same as those sold in the store - I suspect they are
debug builds so comparing them might be hard. I'll switch them out with
the official ones later for Fedora testing.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/456295e8/attachment.sig>

From bernie at codewiz.org  Thu Nov 15 22:07:33 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Thu, 15 Nov 2007 17:07:33 -0500
Subject: Severe X breakage heads up
In-Reply-To: <1195082939.2292.28.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>	<1195061080.6464.9.camel@rousalka.dyndns.org>	<20071114180849.GA8811@nostromo.devel.redhat.com>	<1195070540.7660.2.camel@rousalka.dyndns.org>
	<1195082939.2292.28.camel@localhost.localdomain>
Message-ID: <473CC325.6000105@codewiz.org>

Adam Jackson wrote:

> It's also not something I've looked into at all yet.  I would be
> thrilled to have contributions in this area, if you're looking for a
> project.

What's missing?

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From tdiehl at rogueind.com  Thu Nov 15 22:14:24 2007
From: tdiehl at rogueind.com (Tom Diehl)
Date: Thu, 15 Nov 2007 17:14:24 -0500 (EST)
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195154137.7532.2.camel@rousalka.dyndns.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com> <473C985A.8010202@gmail.com>
	<1195154137.7532.2.camel@rousalka.dyndns.org>
Message-ID: <Pine.LNX.4.64.0711151712190.11735@tigger.tntechs.com>

On Thu, 15 Nov 2007 20:15:37, Nicolas Mailhot wrote:

> Le jeudi 15 novembre 2007 ??? 13:04 -0600, Les Mikesell a ???crit :
> > Jesse Keating wrote:
> > > On Thu, 15 Nov 2007 19:32:44 +0100
> > > Olivier Galibert <galibert at pobox.com> wrote:
> > >
> > >> What's the point, though, unless you're in a setup where 90%+ of the
> > >> computers change every year[1]?
> > >
> > > Because client creation is much easier if you just tell it to DHCP
> > > rather than spending time to punch in technobabble numbers each time.
> >
> > What good are clients without servers?  And what are you supposed to do
> > with all of the server-side software that comes with fedora if you don't
> > have a static IP?
> 
> Any decent dhcp server will let you assign static ips to specific
> systems, including servers. There is no reason to hardcode the ip on the
> system itself.

Just to be pedantic, how does the machine running the dhcp server software
get an ip address if you do not hard code it? :-)

Regards,

-- 
Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com

From s.adam at diffingo.com  Thu Nov 15 22:17:23 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Thu, 15 Nov 2007 17:17:23 -0500
Subject: Claiming gnofract4d
In-Reply-To: <3170f42f0711151137rb9019b8ld1f97f1427532a87@mail.gmail.com>
References: <1195086765.24726.6.camel@Diffingo.localdomain>
	<3170f42f0711151137rb9019b8ld1f97f1427532a87@mail.gmail.com>
Message-ID: <1195165043.9674.3.camel@Diffingo.localdomain>

On Fri, 2007-11-16 at 01:07 +0530, Debarshi 'Rishi' Ray wrote:
> 
> So why is it still listed under
> https://admin.fedoraproject.org/pkgdb/users/packages/orphan?
> 
> I thought this PackageDB bug was already fixed.
> 
> Cheers,
> Debarshi
> -- 
> GPG key ID: 63D4A5A7
> Key server: pgp.mit.edu
It could be because I only the claimed devel/ branch - Should I be
claiming all (even EOL'd) branches?

Stewart



From johannbg at hi.is  Thu Nov 15 22:24:37 2007
From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=)
Date: Thu, 15 Nov 2007 22:24:37 -0000 (GMT)
Subject: System-Config-Firewall, Bluetooth, etc...
In-Reply-To: <473CB092.8070100@redhat.com>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
	<473CB092.8070100@redhat.com>
Message-ID: <29736.88.149.97.225.1195165477.squirrel@webmail.hi.is>

>>
>> System-config-Selinux notifier wtf for the noob...
>> I triggered an selinux alert and shtf and here we are at impass
>> Even if we make the "notice" more userfriendly, we cant have
>> *next* ( which they wanted ) button to solve it because we dont
>> want the user to allow something that should not be allowed
>> ( and yes these users would press the next button to make it go away )
>> I gave this a great deal of thought and came up with nothing
>> just that this will always be a problem.
>> ( no we dont want users to disable this with disable me button,
>> because whats the point having it if everybody disable it. )
>>
>> Now I was asked if there was available Bigbrother/Nanny software
>> that could protect/monitor their children computer usage
>> from all the harm and danger the internet can bring?
>>
>> Anything anyone?
>>
>> Does Redhat have this covered before rolling out Redhat-Desktop
>>
>> Something that can ease the mind of parents?
>>
>> Best Regards
>>           Johann B.
>>
> Did you install and run setroubleshoot?
>
> The goal of this package is to be the "nanny"
>

Well if setroubleshoot can prevent a kid to search
for adult sites and other xxx and drug/suicidal related websites
and prevents it from downloading illegal media content
via torrent and can report to the parent if the kid tries
to do so or provide with parents with the kids daily computer activity
report, and could enable or disable internet connection
on certain times for the kids user account ( between 20:00 to 22:00 )
the do tell im eager to learn about the hidden features of setroubleshoot :)

Given the how the noob user reacted to selinux alerts "how do I make this
go away?" followed by "ok now you showed me how to make it go away, what
does this all mean?" which I could not get them to understand, followed by
"how do I know if my computer got "infected" or "compromised?" with no
better answer from me other than you dont!" followed by is not then best
if i just turn this of since I dont understand what the "system" is
warning me about?

As I said we are at impass between selinux and the noob user...

Best regard.
         Johann B.



From jwboyer at gmail.com  Thu Nov 15 22:45:51 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 15 Nov 2007 16:45:51 -0600
Subject: Plan for tomorrows (20071114) FESCO meeting
In-Reply-To: <473BBA83.9040706@redhat.com>
References: <1195065343.1858.5.camel@nixon>
	<473BA48F.8050106@fedoraproject.org>
	<20071114204223.5c7fe98c@vader.jdub.homelinux.org>
	<473BB20A.5000000@fedoraproject.org> <473BB5A0.7030904@redhat.com>
	<473BB5FC.4040108@fedoraproject.org> <473BBA83.9040706@redhat.com>
Message-ID: <20071115164551.6ada7f9c@vader.jdub.homelinux.org>

On Wed, 14 Nov 2007 22:18:27 -0500
Jeremy Katz <katzj at redhat.com> wrote:

> Rahul Sundaram wrote:
> > Jeremy Katz wrote:
> >> Rahul Sundaram wrote:
> >>> Josh Boyer wrote:
> >>>> On Thu, 15 Nov 2007 07:14:47 +0530
> >>>> Rahul Sundaram  wrote:
> >>>>> Was FESCo mailing list archive being opened discussed? What's the 
> >>>>> decision on that?
> >>>>
> >>>> It was discussed.  The decision was to leave it closed
> >>>
> >>> Why?
> >>
> >> Because people have sent things to the list with the expectation that 
> >> it's not a public list.  Opening up the archives therefore exposes 
> >> those mails to the world against the expectations of the people who 
> >> sent mail.
> > 
> > I did not ask for the archives in the past to be opened up but for it to 
> > be open from now on. The list itself seems to be hidden as I can't find 
> > it and it isn't listed anywhere that I am aware of.
> 
> Opening them up from now on would basically require either
> a) nuking the archives that already exist (which may or may not be doable)
> b) creating a whole new list
> 
> It's just not worth the pain when the only things the list is really 
> used for are regrets about missing the meeting and wiki watch on the 
> schedule page

We could always kill the list and use private email too if we require
it.  I don't care either way personally.

josh



From a.badger at gmail.com  Thu Nov 15 22:55:14 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 15 Nov 2007 14:55:14 -0800
Subject: Claiming gnofract4d
In-Reply-To: <1195165043.9674.3.camel@Diffingo.localdomain>
References: <1195086765.24726.6.camel@Diffingo.localdomain>	<3170f42f0711151137rb9019b8ld1f97f1427532a87@mail.gmail.com>
	<1195165043.9674.3.camel@Diffingo.localdomain>
Message-ID: <473CCE52.4080004@gmail.com>

Stewart Adam wrote:
> On Fri, 2007-11-16 at 01:07 +0530, Debarshi 'Rishi' Ray wrote:
>> So why is it still listed under
>> https://admin.fedoraproject.org/pkgdb/users/packages/orphan?
>>
>> I thought this PackageDB bug was already fixed.

> It could be because I only the claimed devel/ branch - Should I be
> claiming all (even EOL'd) branches?
> 
Not EOL branches but you do have to claim all Active branches.  If you 
claim FC6 it should stop being orphaned.  Alternately, you can wait and 
let it disappear from the orphan list when FC6 is marked EOL.

-Toshio



From jam at zoidtechnologies.com  Thu Nov 15 23:04:22 2007
From: jam at zoidtechnologies.com (jam at zoidtechnologies.com)
Date: Thu, 15 Nov 2007 18:04:22 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115134417.49b562a0@redhat.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
Message-ID: <20071115230422.GJ30600@zoidtechnologies.com>

On Thu, Nov 15, 2007 at 01:44:17PM -0500, Jesse Keating wrote:
> 
> Because client creation is much easier if you just tell it to DHCP
> rather than spending time to punch in technobabble numbers each time.
> 

when I worked for a university and was doing the "resnet" network (residence
hall connectivity) we used DHCP for everything, including any machines that
had to have a static address.

> -- 
> Jesse Keating
> Fedora -- All my bits are free, are yours?


regards,
two-eff-jeff
-- 
http://zoidtechnologies.com/ -- software that sucks less



From lkundrak at redhat.com  Thu Nov 15 23:13:44 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Fri, 16 Nov 2007 00:13:44 +0100
Subject: Volunteers for fixing and/or maintaning Tomcat
Message-ID: <1195168424.29805.16.camel@localhost.localdomain>

Hi,

Our tomcat5 packages are still without fixes for several security flaws
(CVE-2007-5461, CVE-2007-2450, CVE-2007-2449) for too long and as days
pass I am getting more and more worried about it.

I am not able to persuade the maintainer to fix the issues (the patches
are available thoug, in RHEL packages). I attempted to contact him via
mail and offered him help with the updates, but he seems uninterested.

Is there anyone who would volunteer to fix and maintain tomcat?

To formally satisfy [1], in case it will be needed, here are some random
bug links: [2] [3] [4].

[1] http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers
[2] https://bugzilla.redhat.com/show_bug.cgi?id=244810
[3] https://bugzilla.redhat.com/show_bug.cgi?id=334511
[4] https://bugzilla.redhat.com/show_bug.cgi?id=244810

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From myfedora at richip.dhs.org  Thu Nov 15 23:22:22 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 15 Nov 2007 16:22:22 -0700
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195155640.15950.12.camel@localhost.localdomain>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com> <20071115123352.5140bb71@redhat.com>
	<d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
	<1195154331.17111.12.camel@localhost6.localdomain6>
	<1195155640.15950.12.camel@localhost.localdomain>
Message-ID: <1195168942.19571.4.camel@localhost6.localdomain6>

On Thu, 2007-11-15 at 14:40 -0500, Dan Williams wrote:
> You don't have to use libnm-glib at all; it's pretty simple to use
> straight D-Bus to do what needs to be done.

So what's libnm-glib? A library of convenience functions that allows one
to use NM via D-Bus? If so, does it depend on the rest of
NetworkManager? Perhaps that library can be separated and made a
dependency of pidgin.

If the scenario I painted above is correct, then it would make sense for
people to use those convenience functions to avoid having to rewrite the
same code over and over again (assuming the functions themselves are a
certain order of magnitude simpler than the functions they wrap). It
might add to the complexity of packaging but simplify programming.
Getting into the realm of no right and wrong ... just which one will
prove the smart choice further into the future.
--

Richi Plana



From myfedora at richip.dhs.org  Thu Nov 15 23:33:37 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 15 Nov 2007 16:33:37 -0700
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071115162214.35cd3807@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
Message-ID: <1195169617.19571.14.camel@localhost6.localdomain6>

On Thu, 2007-11-15 at 16:22 -0500, Jesse Keating wrote:
> On Thu, 15 Nov 2007 14:12:02 -0700
> Richi Plana <myfedora at richip.dhs.org> wrote:
> 
> > Valent, you've been keeping tabs on developments with this issue.
> > Could you summarize what suggestions have been made to solve it and
> > who made these suggestions? Just the positive feedback, if you please.
> 
> Fluendo could use a non-closed source compiler (I suggest gcc) so that
> the binaries could be made to not need execmem.

Hmm ... I remember reading somewhere that Fluendo was looking into this.
If so, ball's in their court. In fact ... yes, there's a link on the
Fedora bugzilla pointing to Fluendo's bug report. Last Fluendo reply was
from Christian on 06/07/07 16:35:08. If they could get back a timeframe,
then Fedora could decide whether a near-term, temporary fix should be
implemented:

> Fedora could modify the policy to allow for execmem from these files
> (not sure what the side effects of that are, nor how far reaching this
> would be given that the codecs are used in gstreamer).

It should be noted that for Fedora advocacy's or PR sake, I've already
read one article that slams Fedora for (among other things) a faulty
Codec Buddy. Again, it's a matter of perception.

Constructive criticisms only, please.
--

Richi Plana



From devrim at CommandPrompt.com  Thu Nov 15 23:34:38 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Thu, 15 Nov 2007 15:34:38 -0800
Subject: Volunteers for fixing and/or maintaning Tomcat
In-Reply-To: <1195168424.29805.16.camel@localhost.localdomain>
References: <1195168424.29805.16.camel@localhost.localdomain>
Message-ID: <1195169678.32233.1.camel@localhost.localdomain>

Hi,


On Fri, 2007-11-16 at 00:13 +0100, Lubomir Kundrak wrote:
> Our tomcat5 packages are still without fixes for several security
> flaws (CVE-2007-5461, CVE-2007-2450, CVE-2007-2449) for too long and
> as days pass I am getting more and more worried about it.
> 
> I am not able to persuade the maintainer to fix the issues (the
> patches are available thoug, in RHEL packages). I attempted to contact
> him via mail and offered him help with the updates, but he seems
> uninterested.

Oh :(

> Is there anyone who would volunteer to fix and maintain tomcat?

I can take it. I'm not following Tomcat project very closely, but at
least I can apply the patches, I can improve packaging (if needed), etc.
-- and if someone grants me access , I can push the package for build
later today.

I can also keep it up2date in the future.

Regards,
-- 
Devrim G?ND?Z , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/31fa6557/attachment.sig>

From triad at df.lth.se  Thu Nov 15 23:51:20 2007
From: triad at df.lth.se (Linus Walleij)
Date: Fri, 16 Nov 2007 00:51:20 +0100 (CET)
Subject: Push packages from diverse maintainers
Message-ID: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>

So these kind of things are usually done from inside Red Hat I think. 
Basically:

* I maintain libmtp and gnomad2

* Aurelien maintains Amarok

* We need to rebuild libmtp, then gnomad2 and Amarok to pick up the new
   .soversion of libmtp.

So how do we *best* coordinate this? I have tagged everything for libmtp 
and gnomad2 in the F-8 branch, and requested that Aurelien build them and 
Amarok at the same time and then push all three. See:
https://bugzilla.redhat.com/show_bug.cgi?id=359401

We did this before, on "you build that then I will quickly build this" 
with some breakage as a result (this clearly only works if you're on the 
same geographical location as the person pushing things to testing/updates 
or we will have "race conditions"), but how do we do it *properly* in 
order to build push all three packages simultaneously to testing and then 
to updates?

Q: Does the new permissions system hinder Aurelien from building my
    packages, unless explicitly granted rights? (That'd suck.)

Q: Can Aurelien push my packages if I build them myself? (Looks like he
    can't.)

Q: Is some third person supposed to interfere?

This is the kind of thing I think would be brilliant to solve in Bodhi, 
some elegant way.

Linus



From mclasen at redhat.com  Fri Nov 16 00:15:58 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 15 Nov 2007 19:15:58 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195168942.19571.4.camel@localhost6.localdomain6>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<473C8218.6090801@redhat.com> <20071115123352.5140bb71@redhat.com>
	<d9c612bf0711150946t3ac68913mc35568f28a012737@mail.gmail.com>
	<1195154331.17111.12.camel@localhost6.localdomain6>
	<1195155640.15950.12.camel@localhost.localdomain>
	<1195168942.19571.4.camel@localhost6.localdomain6>
Message-ID: <1195172158.3516.16.camel@localhost.localdomain>


On Thu, 2007-11-15 at 16:22 -0700, Richi Plana wrote:
> On Thu, 2007-11-15 at 14:40 -0500, Dan Williams wrote:
> > You don't have to use libnm-glib at all; it's pretty simple to use
> > straight D-Bus to do what needs to be done.
> 
> So what's libnm-glib? A library of convenience functions that allows one
> to use NM via D-Bus? If so, does it depend on the rest of
> NetworkManager? Perhaps that library can be separated and made a
> dependency of pidgin.
> 
> If the scenario I painted above is correct, then it would make sense for
> people to use those convenience functions to avoid having to rewrite the
> same code over and over again (assuming the functions themselves are a
> certain order of magnitude simpler than the functions they wrap). It
> might add to the complexity of packaging but simplify programming.
> Getting into the realm of no right and wrong ... just which one will
> prove the smart choice further into the future.


libnm_glib is contained in NetworkManager-glib. Unfortunately, the -glib
package seems to pull in the main NetworkManager package by way of the
libnm-util.so dependency. 

I also notice that libnm-util.so is contained in both NetworkManager and
NetworkManager-devel. 

Maybe we need to split libnm-util.so off into a NetworkManager-libs
package ?



From ivazqueznet at gmail.com  Fri Nov 16 00:19:05 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 15 Nov 2007 19:19:05 -0500
Subject: Push packages from diverse maintainers
In-Reply-To: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
Message-ID: <1195172345.3461.1.camel@ignacio.lan>

On Fri, 2007-11-16 at 00:51 +0100, Linus Walleij wrote:
> So these kind of things are usually done from inside Red Hat I think. 
> Basically:
> 
> * I maintain libmtp and gnomad2
> 
> * Aurelien maintains Amarok
> 
> * We need to rebuild libmtp, then gnomad2 and Amarok to pick up the new
>    .soversion of libmtp.
> 
> So how do we *best* coordinate this?

https://hosted.fedoraproject.org/projects/bodhi/ticket/79

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/282ab47a/attachment.sig>

From jdennis at redhat.com  Fri Nov 16 00:40:13 2007
From: jdennis at redhat.com (John Dennis)
Date: Thu, 15 Nov 2007 19:40:13 -0500
Subject: check-rpaths, libtool, dlopen, loadable modules
Message-ID: <473CE6ED.2040502@redhat.com>

I have a package which builds loadable modules intended to be loaded by
dlopen and it's being rejected on x86_64 because check-rpaths is
complaining it's finding a RPATH in the loadable modules .so file. This
is for F8.

The check-rpaths error is:
ERROR 0001: file '/usr/lib64/foo.so' contains a standard
rpath '/usr/lib64' in [/usr/lib64]

The package uses libtool and when it links the loadable module it
invokes libtool like this (abbreviated for clarity)

libtool --mode=link -module -export-dynamic -rpath $(libdir)

There are several things I confused about now that I've really tried to
diagnose the problem.

* on i386 RPATH is not embedded in the .so, but on x86_64 it is, why?

I think that libtool does not add a RPATH directive when it sees that
--rpath libdir is the same as the standard library directory. This is
why I think RPATH is not embedded in the .so on i386 but it is on x86_64
because libdir ends up being /usr/lib64, not /usr/lib

* if I remove the -rpath $(libdir) then libtool --mode=install fails
because it can't find the modules .lai file (what's a .lai?), when
-rpath is present the .lai files are produced and everybody's happy.

* I don't think the rpath is necessary for the loadable modules to work
since they are installed in a standard library directory (/usr/lib). I'm
not sure if this also holds true for multilib arches. Yes/No?

* I tried most of the recommendations for removing rpath in the
packaging guidelines, but it didn't help, in part because passing -rapth
to libtool is hardcoded in the Makefiles (but only for the loadable
modules), but as I noted above removing it causes libtool --mode=install
to fail.

* It almost seems like libtool insists on using rpath for loadable
modules because it fails if you don't use it. Is rpath mandatory for 
loadable modules?

Thanks in advance for any help. I've been kinda beating my head against
the wall, also I don't have a x86_64 to work on.


-- 
John Dennis <jdennis at redhat.com>



From mclasen at redhat.com  Fri Nov 16 00:51:55 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 15 Nov 2007 19:51:55 -0500
Subject: check-rpaths, libtool, dlopen, loadable modules
In-Reply-To: <473CE6ED.2040502@redhat.com>
References: <473CE6ED.2040502@redhat.com>
Message-ID: <1195174315.3516.20.camel@localhost.localdomain>


On Thu, 2007-11-15 at 19:40 -0500, John Dennis wrote:

> 
> Thanks in advance for any help. I've been kinda beating my head against
> the wall, also I don't have a x86_64 to work on.

No, rpath is not necessary for dlopened modules - all the modules below
/usr/lib/gtk-2.0/ work fine without it. 

But if your modules are just modules and not used as shared libraries,
they should not be in /usr/lib, but rather somewhere below
%{_libdir}/%{name}.


Matthias



From tmus at tmus.dk  Fri Nov 16 00:55:36 2007
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Thu, 15 Nov 2007 21:55:36 -0300
Subject: Improving halt package interaction...
In-Reply-To: <fhdi4e$7on$1@ger.gmane.org>
References: <fhdi4e$7on$1@ger.gmane.org>
Message-ID: <fhipqa$ehl$1@ger.gmane.org>

Thomas M Steenholdt wrote:
> Hi all...
> 
> I'd like to bring up a suggestion that would make it easier for 
> packagers to modify the halt process, without resorting to changing 
> files owned by other packages.
> 
> Currently /etc/init.d/halt provides a hook into the halt process via an 
> /sbin/halt.local file. If this file exists and is executable, it will be 
> run during the halt process. This makes it possible for system 
> administrators to write their own halt modifier (typically needed when 
> dealing with UPSes and possibly other types of packages).
> 
> I think it would be very valuable to extend this functionality of 
> /etc/init.d/halt to support a /etc/halt.d/ directory in addition to the 
> halt.local script (Why is halt.local currently not located in /etc along 
> with rc.local and such but in /sbin btw?). This would allow a package 
> (an UPS software package as an example) to drop a halt modifier script 
> in /etc/halt.d/ to take care of prepping the system for halt (rather 
> that poweroff) and initiate a delayed UPS poweroff, if a mains powerloss 
> condition was detected. Currently the package will have to hack either 
> /sbin/halt.local, which could be difficult, or /etc/init.d/halt which 
> would be just plain bad. Usually they will simply leave this out and the 
> system admin will have to set it up manually, for the UPS to work properly.
> 
> The current version of the /etc/init.d/halt script (from 
> initscripts-8.60-1) includes UPS handling code for the NUT UPS 
> software(i think). NUT could easily be made to use the new /etc/halt.d/ 
> infrastructure too, and /etc/init.d/halt could get rid of the 
> non-generic UPS handling code, which IMHO should be avoided anyway...
> 
> What do you guys think about this?
> 
> /Thomas
> 

I've created a bug to make it easier to track. If this could be of 
interest, I'd be happy to supply an appropriate patch.

https://bugzilla.redhat.com/show_bug.cgi?id=386071

/Thomas



From bnocera at redhat.com  Fri Nov 16 01:14:17 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 01:14:17 +0000
Subject: System-Config-Firewall, Bluetooth, etc...
In-Reply-To: <29736.88.149.97.225.1195165477.squirrel@webmail.hi.is>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
	<473CB092.8070100@redhat.com>
	<29736.88.149.97.225.1195165477.squirrel@webmail.hi.is>
Message-ID: <1195175657.10878.11.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 22:24 +0000, J?hann B. Gu?mundsson wrote:
<snip>
> Given the how the noob user reacted to selinux alerts "how do I make this
> go away?" followed by "ok now you showed me how to make it go away, what
> does this all mean?" which I could not get them to understand, followed by
> "how do I know if my computer got "infected" or "compromised?" with no
> better answer from me other than you dont!" followed by is not then best
> if i just turn this of since I dont understand what the "system" is
> warning me about?

I think that whole paragraph is one sentence. I didn't get any of that.



From kevin.kofler at chello.at  Fri Nov 16 01:18:59 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Nov 2007 01:18:59 +0000 (UTC)
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
References: <473B781F.7040809@hhs.nl>
Message-ID: <loom.20071116T011704-40@post.gmane.org>

I see Than has both included your workaround and approved commit access for you 
now, so I think this issue can be considered resolved.

        Kevin Kofler



From bnocera at redhat.com  Fri Nov 16 01:20:57 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 01:20:57 +0000
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071115162214.35cd3807@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
Message-ID: <1195176057.10878.18.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 16:22 -0500, Jesse Keating wrote:
> On Thu, 15 Nov 2007 14:12:02 -0700
> Richi Plana <myfedora at richip.dhs.org> wrote:
> 
> > Valent, you've been keeping tabs on developments with this issue.
> > Could you summarize what suggestions have been made to solve it and
> > who made these suggestions? Just the positive feedback, if you please.
> 
> Fluendo could use a non-closed source compiler (I suggest gcc) so that
> the binaries could be made to not need execmem.

I'm trying to find a way to show you're talking rubbish without being
insulting, but I'm failing. The problem isn't the compiler, but the
libraries used, in this case Intel's IPP library. It provides
convenience functions for optimised decoding of a number of codecs, and
various other optimised decoding routines.

Fluendo doesn't have access to the IPP library sources, so we're waiting
for Intel to fix this. I'm not holding my breath.

> Fedora could modify the policy to allow for execmem from these files
> (not sure what the side effects of that are, nor how far reaching this
> would be given that the codecs are used in gstreamer).

Which is what Dan did for the system-wide plugins. See the bug Valent
mentioned earlier in the thread.



From halfline at gmail.com  Fri Nov 16 01:24:37 2007
From: halfline at gmail.com (Ray Strode)
Date: Thu, 15 Nov 2007 20:24:37 -0500
Subject: check-rpaths, libtool, dlopen, loadable modules
In-Reply-To: <473CE6ED.2040502@redhat.com>
References: <473CE6ED.2040502@redhat.com>
Message-ID: <45abe7d80711151724v3039b8e6i11564c02f5d05070@mail.gmail.com>

Hi,

On Nov 15, 2007 7:40 PM, John Dennis <jdennis at redhat.com> wrote:
> I have a package which builds loadable modules intended to be loaded by
> dlopen and it's being rejected on x86_64 because check-rpaths is
> complaining it's finding a RPATH in the loadable modules .so file. This
> is for F8.
Old versions of libtool have a bug where they don't consider
/usr/lib64 to be a system library directory.  If the upstream tarball
was dist'd on an older platform that could be why.

You could try blowing away the libtool shipped with the package,
running autoreconf and libtoolize --force to get the F8 libtool.

--Ray



From bnocera at redhat.com  Fri Nov 16 01:27:45 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 01:27:45 +0000
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473C8671.8040200@BitWagon.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
Message-ID: <1195176465.10878.23.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 09:48 -0800, John Reiser wrote:
> > A live CD install on servers? You're walking all over your use cases :)
> 
> Does the live CD install istelf have a prominent advisory "Avoid using
> LiveCD for these cases [see http://... for explanation]" ?

There are multiple versions of the LiveCDs, but you don't mention which
one you used. The one specifically targetted at servers doesn't run
NetworkManager by default IIRC.

> This may be fallout from "Fedora Project does not distribute CD images."
> Physical media are comforting to administrators (changing the bits is
> easy to detect and prevent), many servers lack DVD, creating a local repo
> can be a hassle, install from network drive is not widely understood
> (and when it doesn't work it is hard to figure out how to fix.)

A CD and a network is all that's needed to install servers, without the
need to setup a staging network with tftp boot. I'm pretty sure that's
all explained in the Installation Guide.



From seg at haxxed.com  Fri Nov 16 01:45:30 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 15 Nov 2007 19:45:30 -0600
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <1195081571.32559.219.camel@localhost>
References: <1195018220.32559.98.camel@localhost> <473ABC3E.9090603@hhs.nl>
	<1195037436.32559.200.camel@localhost> <473B3158.80703@redhat.com>
	<473B43A7.4020105@redhat.com>  <1195081571.32559.219.camel@localhost>
Message-ID: <1195177530.24564.3.camel@localhost>

On Wed, 2007-11-14 at 17:06 -0600, Callum Lerwick wrote:
> Otherwise I'm going to have to get a new package out...

Up to date package linked on the review ticket. :)

https://bugzilla.redhat.com/show_bug.cgi?id=233946
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/0aac384e/attachment.sig>

From johannbg at hi.is  Fri Nov 16 01:50:43 2007
From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=)
Date: Fri, 16 Nov 2007 01:50:43 -0000 (GMT)
Subject: System-Config-Firewall, Bluetooth, etc...
In-Reply-To: <1195175657.10878.11.camel@cookie.hadess.net>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
	<473CB092.8070100@redhat.com>
	<29736.88.149.97.225.1195165477.squirrel@webmail.hi.is>
	<1195175657.10878.11.camel@cookie.hadess.net>
Message-ID: <29926.88.149.97.225.1195177843.squirrel@webmail.hi.is>

>
> On Thu, 2007-11-15 at 22:24 +0000, J?hann B. Gu?mundsson wrote:
> <snip>
>> Given the how the noob user reacted to selinux alerts "how do I make
>> this
>> go away?" followed by "ok now you showed me how to make it go away, what
>> does this all mean?" which I could not get them to understand, followed
>> by
>> "how do I know if my computer got "infected" or "compromised?" with no
>> better answer from me other than you dont!" followed by is not then best
>> if i just turn this of since I dont understand what the "system" is
>> warning me about?
>
> I think that whole paragraph is one sentence. I didn't get any of that.
>

Yes yes.. I see it now :)

If only English where my native language
or maybe not..

Not that my bad English solves the problem ahead..

Any who im out of ideas regarding this issue..

Yes the alerts could be much more noob userfriendly..

Putting a *next/allow/fix* button beats the purpose of using selinux
because the user would always push *next/allow/fix*
hence it could just as well be disabled now..

Does any one know how Redhat-Desktop support module is going to be..

1000 people on phone support *hint* *hint*...

Take 2...

Given how the noob user reacted to selinux alerts..

"How do I make this go away?"

Followed by..

"Ok now you showed me how to make it go away, what does all this mean?"..

Which I could not get them to understand...

Followed by..

"how do I know if my computer got "infected" or "compromised?"

With no better answer from me other than you dont!

followed by...

Is not then best if i just turn his off since I dont understand what the
"system" is warning me about?

Best regards..
         Johann B.



From darth_linux at ameritech.net  Fri Nov 16 01:56:46 2007
From: darth_linux at ameritech.net (eah)
Date: Thu, 15 Nov 2007 20:56:46 -0500
Subject: F8, b43 and radio button for BCM4318
Message-ID: <200711152056.46958.darth_linux@ameritech.net>

Hi all, 

I have the BCM4318 wlan0. b43 driver picks it up after following instructions 
using  broadcom-wl-4.80.53.0.tar.bz2. It does not active the card's radio (my 
little blue light stays dark to say it like an end user) . dmesg 
reports "ADDRCONF(NETDEV_UP): wlan0: link is not ready"

What do I need to do to get that working? 

This is the farthest I've ever gotten using the stock driver, so kudos to all 
involved in that. 



thanks, 

Eric Hartwell 



From pemboa at gmail.com  Fri Nov 16 02:01:00 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 15 Nov 2007 20:01:00 -0600
Subject: System-Config-Firewall, Bluetooth, etc...
In-Reply-To: <29736.88.149.97.225.1195165477.squirrel@webmail.hi.is>
References: <23677.88.149.97.225.1195077078.squirrel@webmail.hi.is>
	<473CB092.8070100@redhat.com>
	<29736.88.149.97.225.1195165477.squirrel@webmail.hi.is>
Message-ID: <16de708d0711151801l18b2ef65n607f1018f81251b@mail.gmail.com>

On Nov 15, 2007 4:24 PM, J?hann B. Gu?mundsson <johannbg at hi.is> wrote:
> >>
> >> System-config-Selinux notifier wtf for the noob...
> >> I triggered an selinux alert and shtf and here we are at impass
> >> Even if we make the "notice" more userfriendly, we cant have
> >> *next* ( which they wanted ) button to solve it because we dont
> >> want the user to allow something that should not be allowed
> >> ( and yes these users would press the next button to make it go away )
> >> I gave this a great deal of thought and came up with nothing
> >> just that this will always be a problem.
> >> ( no we dont want users to disable this with disable me button,
> >> because whats the point having it if everybody disable it. )
> >>
> >> Now I was asked if there was available Bigbrother/Nanny software
> >> that could protect/monitor their children computer usage
> >> from all the harm and danger the internet can bring?


What you want to do is take all outgoing traffic and send it through
Squid, and filter it there.

There are currently n presetup packages of this as far as I know.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From jreiser at BitWagon.com  Fri Nov 16 02:37:15 2007
From: jreiser at BitWagon.com (John Reiser)
Date: Thu, 15 Nov 2007 18:37:15 -0800
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195176465.10878.23.camel@cookie.hadess.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<1195143796.3140.110.camel@cookie.hadess.net>	<473C8671.8040200@BitWagon.com>
	<1195176465.10878.23.camel@cookie.hadess.net>
Message-ID: <473D025B.7070103@BitWagon.com>

Bastien Nocera wrote:
> A CD and a network is all that's needed to install servers, without the
> need to setup a staging network with tftp boot. I'm pretty sure that's
> all explained in the Installation Guide.

No.  If there is more than one server to be installed, and you want
to download any piece only once, then you need some storage
and a way to access it during each install.

-- 



From darth_linux at ameritech.net  Fri Nov 16 03:27:28 2007
From: darth_linux at ameritech.net (eah)
Date: Thu, 15 Nov 2007 22:27:28 -0500
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <200711152056.46958.darth_linux@ameritech.net>
References: <200711152056.46958.darth_linux@ameritech.net>
Message-ID: <200711152227.29179.darth_linux@ameritech.net>

On Thursday 15 November 2007 20:56:46 pm eah wrote:
> Hi all,
>
> I have the BCM4318 wlan0. b43 driver picks it up after following
> instructions using  broadcom-wl-4.80.53.0.tar.bz2. It does not active the
> card's radio (my little blue light stays dark to say it like an end user) .
> dmesg
> reports "ADDRCONF(NETDEV_UP): wlan0: link is not ready"
>
> What do I need to do to get that working?
>
> This is the farthest I've ever gotten using the stock driver, so kudos to
> all involved in that.
>
>
>
> thanks,
>
> Eric Hartwell

btw: i'm running x86_64 and i'm pretty sure the firmware was for the 32-bit 
version. 

thanks, 

Eric 



From devrim at CommandPrompt.com  Fri Nov 16 03:47:48 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Thu, 15 Nov 2007 19:47:48 -0800
Subject: Volunteers for fixing and/or maintaning Tomcat
In-Reply-To: <1195168424.29805.16.camel@localhost.localdomain>
References: <1195168424.29805.16.camel@localhost.localdomain>
Message-ID: <1195184868.32233.26.camel@localhost.localdomain>

Hi again,

On Fri, 2007-11-16 at 00:13 +0100, Lubomir Kundrak wrote:

> Is there anyone who would volunteer to fix and maintain tomcat?

I pushed tomcat5-5.5.25 to -devel with 2 new patches:

http://koji.fedoraproject.org/koji/taskinfo?taskID=244210

5.5.25 already fixes some of the security issues. I will wait until
tomorrow morning, and will push it to F-7 and F-8, too.

I will be happy if someone can confirm that this package closes all
CVE's.

Regards,
-- 
Devrim G?ND?Z , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/e3915eeb/attachment.sig>

From jkeating at redhat.com  Fri Nov 16 04:54:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Nov 2007 23:54:45 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195176057.10878.18.camel@cookie.hadess.net>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
Message-ID: <20071115235445.4e2f6b51@redhat.com>

On Fri, 16 Nov 2007 01:20:57 +0000
Bastien Nocera <bnocera at redhat.com> wrote:

> > Fluendo could use a non-closed source compiler (I suggest gcc) so
> > that the binaries could be made to not need execmem.  
> 
> I'm trying to find a way to show you're talking rubbish without being
> insulting, but I'm failing. The problem isn't the compiler, but the
> libraries used, in this case Intel's IPP library. It provides
> convenience functions for optimised decoding of a number of codecs,
> and various other optimised decoding routines.
> 
> Fluendo doesn't have access to the IPP library sources, so we're
> waiting for Intel to fix this. I'm not holding my breath.

Ok, fine, s/compiler/library/.  Are you really going to tell me that
it's impossible to build the mp3 library (and others) without using
closed source software?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/128b11a6/attachment.sig>

From trever.adams at gmail.com  Fri Nov 16 05:41:34 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Thu, 15 Nov 2007 22:41:34 -0700
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <200711152227.29179.darth_linux@ameritech.net>
References: <200711152056.46958.darth_linux@ameritech.net>
	<200711152227.29179.darth_linux@ameritech.net>
Message-ID: <1195191694.3147.4.camel@aragorn>

The firmware is identical between the 32-bit and 64-bit drivers. Make
sure you are using the "approved/supported" firmware. There are only a
few versions. If it extracts with the right extraction tool, it is
supported.

Trever

> btw: i'm running x86_64 and i'm pretty sure the firmware was for the 32-bit 
> version. 
> 
> thanks, 
> 
> Eric 
> 
--
"Honor isn't about making the right choices. It's about dealing with the
consequences." -- Midori Koto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/4e495beb/attachment.sig>

From j.w.r.degoede at hhs.nl  Fri Nov 16 06:56:16 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 16 Nov 2007 07:56:16 +0100
Subject: Third contact attempt for AWOL? xfig maintainer: Ngo Than
In-Reply-To: <loom.20071116T011704-40@post.gmane.org>
References: <473B781F.7040809@hhs.nl> <loom.20071116T011704-40@post.gmane.org>
Message-ID: <473D3F10.5030104@hhs.nl>

Kevin Kofler wrote:
> I see Than has both included your workaround and approved commit access for you 
> now, so I think this issue can be considered resolved.
> 


Correct.

Regards,

Hans



From trever.adams at gmail.com  Fri Nov 16 06:56:51 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Thu, 15 Nov 2007 23:56:51 -0700
Subject: Suggestions for F9
Message-ID: <1195196211.3144.1.camel@aragorn>

I have been looking at Fedora to see what functionality it provides or,
more importantly, doesn't which is useful to me at home and that I think
business would like. I have provided a list of functionality (by
programs which I think would best fit it) below. This is a list meant
for Fedora 9.

Thunderbird Enigmail 
What:
A program which adds gnupg and
s/mime support to Thunderbird
Where:
http://enigmail.mozdev.org/
Why:
This would greatly help people who
want to use the same mail program in
Windows/Linux or who think Evolution
does a horrible job (such as full
imap support). The 64 bit compiled
version for Linux is only available
via the website, not the add-ons
functionality, it is usually behind,
so an RPM would be great.

Changes Needed:
Unknown


Thunderbird Lightning
What:
A program which adds gnupg and
s/mime support to Thunderbird
Where:
http://www.mozilla.org/projects/calendar/lightning/
Why:
This would greatly help people who
want to use the same mail program in
Windows/Linux or who think Evolution
does a horrible job (such as full
imap support). No 64 bit precompiled
version is available, so an RPM
would be great. This finishes out
helping Thunderbird fully replace
Evolution and supports CalDAV. 
Changes Needed:
Unknown


Darwin Calendar Server
What:
A full CalDAV server which can be
integrated with multiple
authentication/group information
schemes including Active Directory
(via Samba for us).

Where:
http://trac.macosforge.org/projects/calendarserver
Why:
A calendar server really is a must.
Since there is the open standard of
CalDAV this should be supported.
This particular server seems further
along in development than most. It
seems to be well designed and
developed. Additionally, this is the
one used by OS X. Why not reduce
efforts and standardize? This is a
good compliment to Thunderbird
Lightning plugin. 
Changes Needed:
Probably a few patches to Python
Twister, but not many and may not be
required long as efforts to sync up
are in progress.


Pykota
What:
A program which does accounting and
quotas for printers
Where:
http://www.pykota.com/
Why:
It is good to be able to know who is
printing and how much, possibly
restricting this. I am using this at
home and know business who use Linux
(server and/or desktop) who would
love this.
Changes Needed:
      * A use pykota option in
        system-config-printers for
        each printer. This option
        should not appear for cups
        auto-configured printers as
        the accounting should be
        done on the print server.
      * Possibly a button which will
        open the pykota config for
        the printer in
        system-config-printers.
      * Add GhostPCL package
        (http://www.artifex.com/downloads/), now under GPL 2
 

Please, let me know if I need to add these somewhere to be considered.

These are the major changes I think Fedora needs.

Thank you,
Trever Adams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/ee1c7046/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071115/ee1c7046/attachment.sig>

From j.w.r.degoede at hhs.nl  Fri Nov 16 07:01:40 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 16 Nov 2007 08:01:40 +0100
Subject: check-rpaths, libtool, dlopen, loadable modules
In-Reply-To: <45abe7d80711151724v3039b8e6i11564c02f5d05070@mail.gmail.com>
References: <473CE6ED.2040502@redhat.com>
	<45abe7d80711151724v3039b8e6i11564c02f5d05070@mail.gmail.com>
Message-ID: <473D4054.7090504@hhs.nl>

Ray Strode wrote:
> Hi,
> 
> On Nov 15, 2007 7:40 PM, John Dennis <jdennis at redhat.com> wrote:
>> I have a package which builds loadable modules intended to be loaded by
>> dlopen and it's being rejected on x86_64 because check-rpaths is
>> complaining it's finding a RPATH in the loadable modules .so file. This
>> is for F8.
> Old versions of libtool have a bug where they don't consider
> /usr/lib64 to be a system library directory.  If the upstream tarball
> was dist'd on an older platform that could be why.
> 
> You could try blowing away the libtool shipped with the package,
> running autoreconf and libtoolize --force to get the F8 libtool.
> 

The package containing / using an older libtool is indeed probably the 
problem, using autoreconf and libtoolize --force, is not the solution I 
would advice though, esp. when the package is using older stuff as then 
this often will fail. In my experience the autoxxx stuff is best "left 
alone" (see the recent breaking of packages with the new intltool for 
packages which re autoconf-ed, but did not re-auto inittioolized for 
example).

The better way to fix this is to add the following two lines to your 
specfile after %configure:
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' 
libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

As documented here:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-7cea8c7aa96400a4687e843156354476434ff883

Regards,

Hans



From lightsolphoenix at gmail.com  Fri Nov 16 07:14:04 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Fri, 16 Nov 2007 02:14:04 -0500
Subject: Package for Qt-Jambi?
In-Reply-To: <32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>
References: <473A82FB.9030408@gmail.com>
	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>
Message-ID: <473D433C.7040502@gmail.com>

I tried to build an RPM for Qt-Jambi, but I've collided with what I can 
only call a very shortsighted decision that I'm hoping is fixed within 
the next few versions of it.

It appears that Qt-Jambi requires a little extra from QTDIR than most Qt 
programs; that is, besides needing the tools like qmake and such in 
$QTDIR/bin, Qt-Jambi expects to find the program headers in 
$QTDIR/include, and starts to throw ClassNotFound errors if it doesn't 
find them.  Apparently, this is intentional, though it makes the 
Qt-Jambi source completely incompatible with the general setup of Qt in 
MOST Linux distributions.  Probably easier for the Windows users, though.

At any rate, it appears that Qt-Jambi will be unbuildable until the 
source is updated to allow other locations for the headers...



From kms at passback.co.uk  Fri Nov 16 07:53:46 2007
From: kms at passback.co.uk (Keith Sharp)
Date: Fri, 16 Nov 2007 07:53:46 +0000
Subject: Suggestions for F9
In-Reply-To: <1195196211.3144.1.camel@aragorn>
References: <1195196211.3144.1.camel@aragorn>
Message-ID: <1195199626.24749.93.camel@animal.passback.co.uk>

On Thu, 2007-11-15 at 23:56 -0700, Trever L. Adams wrote:

> Darwin Calendar Server
> What:
> A full CalDAV server which can be
> integrated with multiple
> authentication/group information
> schemes including Active Directory
> (via Samba for us).
> 
> 
> Where:
> http://trac.macosforge.org/projects/calendarserver
> Why:
> A calendar server really is a must.
> Since there is the open standard of
> CalDAV this should be supported.
> This particular server seems
> further along in development than
> most. It seems to be well designed
> and developed. Additionally, this
> is the one used by OS X. Why not
> reduce efforts and standardize?
> This is a good compliment to
> Thunderbird Lightning plugin. 
> Changes Needed:
> Probably a few patches to Python
> Twister, but not many and may not
> be required long as efforts to sync
> up are in progress.

I agree that a CalDAV compliant calendaring server would be a great
addition to Fedora, but is the Darwin Calendar Server the best one to
focus attention on?  As far as I am aware there are at least three other
servers we could consider:

	http://www.bedework.org/bedework/
	http://chandlerproject.org/
	http://rscds.sourceforge.net/

I am not following development of any of these, so I cannot comment on
which would be best for Fedora, but it would be worth doing a review
before focusing on one implementation.

Keith.



From j.w.r.degoede at hhs.nl  Fri Nov 16 08:05:26 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 16 Nov 2007 09:05:26 +0100
Subject: Suggestions for F9
In-Reply-To: <1195196211.3144.1.camel@aragorn>
References: <1195196211.3144.1.camel@aragorn>
Message-ID: <473D4F46.8080100@hhs.nl>

Trever L. Adams wrote:
> I have been looking at Fedora to see what functionality it provides or, 
> more importantly, doesn't which is useful to me at home and that I think 
> business would like. I have provided a list of functionality (by 
> programs which I think would best fit it) below. This is a list meant 
> for Fedora 9.
> 
> Thunderbird Enigmail
> What: 	A program which adds gnupg and s/mime support to Thunderbird
> Where: 	http://enigmail.mozdev.org/
> Why: 	This would greatly help people who want to use the same mail 
> program in Windows/Linux or who think Evolution does a horrible job 
> (such as full imap support). The 64 bit compiled version for Linux is 
> only available via the website, not the add-ons functionality, it is 
> usually behind, so an RPM would be great.
> 
> Changes Needed: 	Unknown
> 
> 
> Thunderbird Lightning
> What: 	A program which adds gnupg and s/mime support to Thunderbird
> Where: 	http://www.mozilla.org/projects/calendar/lightning/
> Why: 	This would greatly help people who want to use the same mail 
> program in Windows/Linux or who think Evolution does a horrible job 
> (such as full imap support). No 64 bit precompiled version is available, 
> so an RPM would be great. This finishes out helping Thunderbird fully 
> replace Evolution and supports CalDAV.
> Changes Needed: 	Unknown
> 
> 
> Darwin Calendar Server
> What: 	A full CalDAV server which can be integrated with multiple 
> authentication/group information schemes including Active Directory (via 
> Samba for us).
> 
> Where: 	http://trac.macosforge.org/projects/calendarserver
> Why: 	A calendar server really is a must. Since there is the open 
> standard of CalDAV this should be supported. This particular server 
> seems further along in development than most. It seems to be well 
> designed and developed. Additionally, this is the one used by OS X. Why 
> not reduce efforts and standardize? This is a good compliment to 
> Thunderbird Lightning plugin.
> Changes Needed: 	Probably a few patches to Python Twister, but not many 
> and may not be required long as efforts to sync up are in progress.
> 
> 
> Pykota
> What: 	A program which does accounting and quotas for printers
> Where: 	http://www.pykota.com/
> Why: 	It is good to be able to know who is printing and how much, 
> possibly restricting this. I am using this at home and know business who 
> use Linux (server and/or desktop) who would love this.
> Changes Needed: 	
> 
>     * A use pykota option in system-config-printers for each printer.
>       This option should not appear for cups auto-configured printers as
>       the accounting should be done on the print server.
>     * Possibly a button which will open the pykota config for the
>       printer in system-config-printers.
>     * Add GhostPCL package (http://www.artifex.com/downloads/), now
>       under GPL 2 
> 
>  
> 
> Please, let me know if I need to add these somewhere to be considered.
> 
> These are the major changes I think Fedora needs.
> 
> Thank you,
> Trever Adams
> 


Trever,

Thanks for this, I think those are good suggestions. However most Fedora 
developers are already carying a pretty full workload as is. Have you 
considered becoming a contributer yourself? I'm more then willing to guide you 
on your initial steps, note I'm both an experienced packager and an experienced 
(certified even) teacher.

Regards,

Hans



From lightsolphoenix at gmail.com  Fri Nov 16 08:17:21 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Fri, 16 Nov 2007 03:17:21 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<1195143796.3140.110.camel@cookie.hadess.net>	<20071115191131.GC60438@dspnet.fr.eu.org>	<20071115143152.4170c48f@redhat.com>
	<473CA371.1060808@gmail.com>
	<604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>
Message-ID: <473D5211.2040906@gmail.com>

Jeff Spaleta wrote:
> I think there very well maybe a valid usage case here for a legacy
> network stack using live image as a useful install target for static
> ip networks. But its almost too late for a discussion about it to
> matter much since NM should have static ip support by F9 and be the
> default stack for all installable images.. whether live or not.
>
> -jef
>   
I hope by then all the kinks have been worked out.  I STILL can't use NM 
to do networking, due to various problematic bugs in it.  Even when it 
was working, I still had to start up the legacy networking system first, 
due to a pretty serious cyclical dependency; NetworkManager depends on 
DBus, which depends on being able to get userids.  If you're using an 
LDAP server, though... the result is NetworkManager needs DBus, which 
needs LDAP, which needs NetworkManager.  The result?  The system freezes 
at the first service in the cycle.



From abo at kth.se  Fri Nov 16 08:58:29 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Fri, 16 Nov 2007 09:58:29 +0100
Subject: Static DHCP
In-Reply-To: <473CA089.4010007@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com> <473C985A.8010202@gmail.com>
	<20071115140852.654ca31a@redhat.com>  <473CA089.4010007@gmail.com>
Message-ID: <1195203509.618.31.camel@home.alexander.bostrom.net>

tor 2007-11-15 klockan 13:39 -0600 skrev Les Mikesell:

> I'd call that shifting the work to someone else, not actually
> automating it. 

It's usually a good idea to have a central registry of which computer
has which IP addresses, with MAC address info. Once you have that it's
easy to also generate a dhcpd.conf from that info to assign static IP:s.

This also means you can reinstall the computer and it'll automatically
get the right IP address. Or move it to a different network without
reconfiguring the computer.

And since the DHCP server doesn't need to keep any state when assigning
IPs that way you can have as many DHCP servers as you like without
caring about syncronizing them, so single point of failure isn't a big
problem. (If you want to have a pool as well, for unknown clients, you
of course need to either have one pool per server or make the servers
talk to each other.)

/abo



From oliver at linux-kernel.at  Fri Nov 16 09:26:39 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Fri, 16 Nov 2007 10:26:39 +0100
Subject: Volunteers for fixing and/or maintaning Tomcat
In-Reply-To: <1195168424.29805.16.camel@localhost.localdomain>
References: <1195168424.29805.16.camel@localhost.localdomain>
Message-ID: <473D624F.1020101@linux-kernel.at>

On 11/16/2007 12:13 AM, Lubomir Kundrak wrote:
> Our tomcat5 packages are still without fixes for several security flaws
> (CVE-2007-5461, CVE-2007-2450, CVE-2007-2449) for too long and as days
> pass I am getting more and more worried about it.
> 
> I am not able to persuade the maintainer to fix the issues (the patches
> are available thoug, in RHEL packages). I attempted to contact him via
> mail and offered him help with the updates, but he seems uninterested.
> 
> Is there anyone who would volunteer to fix and maintain tomcat?
> 
> To formally satisfy [1], in case it will be needed, here are some random
> bug links: [2] [3] [4].
> 
> [1] http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=244810

This is just the blocker bug.

> [3] https://bugzilla.redhat.com/show_bug.cgi?id=334511

OK. This needs to be fixed. Dunno if there's a patch...

> [4] https://bugzilla.redhat.com/show_bug.cgi?id=244810

* CVE-2007-1358
* CVE-2007-2449
* CVE-2007-2450

are (regarding to http://tomcat.apache.org/security-5.html) fixed in
5.5.25 and we have packaged 5.5.25. So this bug is obsolete.


my 2 cent. :-)

-of



From alexl at users.sourceforge.net  Fri Nov 16 09:39:51 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 16 Nov 2007 02:39:51 -0700
Subject: XULRunner in rawhide
In-Reply-To: <473C85A5.9020100@redhat.com> (Martin Stransky's message of "Thu\,
	15 Nov 2007 18\:45\:09 +0100")
References: <473AFF3E.1090904@redhat.com>
	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
	<473C85A5.9020100@redhat.com>
Message-ID: <ld4uattp4.fsf@allele2.eebweb.arizona.edu>

>>>>> "MS" == Martin Stransky  writes:

MS> Alex Lancaster wrote:
>> Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
>> package somehow?  Is there another BuildRequires I need to add?

MS> First and experimental xulrunner-gtkmozembed is in
MS> rawhide/xulrunner-1.9-0.alpha9.5.fc9 now. I don't have any proper
MS> test-case (galeon doesn't compile because of some other problems)
MS> so it can fail but please test it...

Thanks, Martin: this goes further than last time, I don't get the
"Package xulrunner-gtkmozembed was not found in the pkg-config search
path." error messages any more, but I now get a new error:

Traceback (most recent call last):
  File "setup.py", line 262, in <module>
    raise ValueError("Can't find mozilla include base directory")
ValueError: Can't find mozilla include base directory

Full log here:

http://koji.fedoraproject.org/koji/getfile?taskID=244635&name=build.log

Any more ideas?

Alex



From stransky at redhat.com  Fri Nov 16 09:48:16 2007
From: stransky at redhat.com (Martin Stransky)
Date: Fri, 16 Nov 2007 10:48:16 +0100
Subject: XULRunner in rawhide
In-Reply-To: <ld4uattp4.fsf@allele2.eebweb.arizona.edu>
References: <473AFF3E.1090904@redhat.com>	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>	<473C85A5.9020100@redhat.com>
	<ld4uattp4.fsf@allele2.eebweb.arizona.edu>
Message-ID: <473D6760.4050609@redhat.com>

Alex Lancaster wrote:
> Traceback (most recent call last):
>   File "setup.py", line 262, in <module>
>     raise ValueError("Can't find mozilla include base directory")
> ValueError: Can't find mozilla include base directory
> 
> Full log here:
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=244635&name=build.log

I'll check it locally, looks like some misconfiguration...



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov 16 09:55:39 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 16 Nov 2007 10:55:39 +0100
Subject: Package for Qt-Jambi?
In-Reply-To: <473D433C.7040502@gmail.com>
References: <473A82FB.9030408@gmail.com>
	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>
	<473D433C.7040502@gmail.com>
Message-ID: <20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 16 Nov 2007 02:14:04 -0500, Kelly Miller wrote:

> I tried to build an RPM for Qt-Jambi, but I've collided with what I can 
> only call a very shortsighted decision that I'm hoping is fixed within 
> the next few versions of it.
> 
> It appears that Qt-Jambi requires a little extra from QTDIR than most Qt 
> programs; that is, besides needing the tools like qmake and such in 
> $QTDIR/bin, Qt-Jambi expects to find the program headers in 
> $QTDIR/include, and starts to throw ClassNotFound errors if it doesn't 
> find them.  Apparently, this is intentional, though it makes the 
> Qt-Jambi source completely incompatible with the general setup of Qt in 
> MOST Linux distributions.  Probably easier for the Windows users, though.
> 
> At any rate, it appears that Qt-Jambi will be unbuildable until the 
> source is updated to allow other locations for the headers...

Unbuildable? In %build, you could set up your own local QTDIR and link
from it to the original $QTDIR/$QTLIB locations.



From bnocera at redhat.com  Fri Nov 16 11:46:00 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 11:46:00 +0000
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473D025B.7070103@BitWagon.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
	<1195176465.10878.23.camel@cookie.hadess.net>
	<473D025B.7070103@BitWagon.com>
Message-ID: <1195213560.10878.31.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 18:37 -0800, John Reiser wrote:
> Bastien Nocera wrote:
> > A CD and a network is all that's needed to install servers, without the
> > need to setup a staging network with tftp boot. I'm pretty sure that's
> > all explained in the Installation Guide.
> 
> No.  If there is more than one server to be installed, and you want
> to download any piece only once, then you need some storage
> and a way to access it during each install.

Eg. the machine on which you downloaded and installed the LiveCD files
in the first place? Or one of the already installed servers, or even a
removable hard drive.

You don't need a DVD drive to do an install, and using a Desktop LiveCD
to do server installs and then blaming it being inappropriate for
servers shows a lack of realism and/or imagination.



From ndbecker2 at gmail.com  Fri Nov 16 11:55:53 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 16 Nov 2007 06:55:53 -0500
Subject: noarch-python-in-64bit-path (rpmlint)
References: <fhg4um$dap$1@ger.gmane.org> <473BA14C.9010707@redhat.com>
Message-ID: <fhk0g9$heo$1@ger.gmane.org>

Jeremy Katz wrote:

> Neal Becker wrote:
>> What should I do about this?
>> 
>> qct-mercurial.noarch: E:
>> noarch-python-in-64bit-path
>> /usr/lib64/python2.5/site-packages/hgext/qct.pyc
>> 
>> I think qct.py needs to go there, because that's where mercurial is going
>> to
>> look.  As we discussed before, our multi-arch python is somewhat broken,
>> because you cannot have both /usr/lib/python/.../some_package
>> and /usr/lib64/python/.../some_package.  It will only search one of those
>> locations.  So we cannot have both arch and nonarch site-packages/hgext -
>> unless maybe I'm misunderstanding something?
> 
> If it needs to be in the arch-specific path, the package needs to be
> built for the native arch and not noarch
> 
> Jeremy
> 

So qct will build 2 packages, a no-arch qct and an arch qct-mercurial, is
that correct?

Can anyone point me to an example of an rpm spec file that does this, I'm
not sure of the syntax?



From valent.turkovic at gmail.com  Fri Nov 16 12:01:59 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 16 Nov 2007 13:01:59 +0100
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195161122.18227.3.camel@localhost6.localdomain6>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
Message-ID: <64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>

On 11/15/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> On Thu, 2007-11-15 at 14:55 -0600, Rex Dieter wrote:
> > Valent Turkovic wrote:
> >
> > > Look at this bug:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=355291
> > > Have any redhat and fedora devels actually used fluendo codecs?
> >
> > Strictly speaking, these are fluendo's problems, not fedora's.
>
> Strictly speaking, these are Fedora's users' problems.
>
> Valent, you've been keeping tabs on developments with this issue. Could
> you summarize what suggestions have been made to solve it and who made
> these suggestions? Just the positive feedback, if you please.
> --
>
> Richi Plana

Sorry if my post was a bit negative, I'll try to keep it more positive.

I have talked with fluendo devels and they also said what was also
said here that it is a intel library issue that they are waiting intel
to fix.

>From my point of view if fedora has a feature that it advertises then
that feature should work with default settings.

For fedora 8 selinux default setting is enforcing which prevents
fluendo codecs form working, from my point of view I looks like it is
a bug in fedora (I know it is not).

Do you need some more specific feedback from me?

Valent



-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From fedora at camperquake.de  Fri Nov 16 12:09:55 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 16 Nov 2007 13:09:55 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473D5211.2040906@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<20071115191131.GC60438@dspnet.fr.eu.org>
	<20071115143152.4170c48f@redhat.com> <473CA371.1060808@gmail.com>
	<604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>
	<473D5211.2040906@gmail.com>
Message-ID: <20071116130955.159f9c1b@dhcp03.addix.net>

Hi.

On Fri, 16 Nov 2007 03:17:21 -0500, Kelly Miller wrote:

> I hope by then all the kinks have been worked out.  I STILL can't use
> NM to do networking, due to various problematic bugs in it.  Even
> when it was working, I still had to start up the legacy networking
> system first, due to a pretty serious cyclical dependency;
> NetworkManager depends on DBus, which depends on being able to get
> userids.  If you're using an LDAP server, though... the result is
> NetworkManager needs DBus, which needs LDAP, which needs
> NetworkManager.  The result?  The system freezes at the first service
> in the cycle.

There is a neat option I learned some time ago:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus

This (should) make ldap ignore these users (which exist locally,
unless you manually removed them)



From fedora at leemhuis.info  Fri Nov 16 12:11:49 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 16 Nov 2007 13:11:49 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473C8589.2010109@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B3FA8.70106@hhs.nl>
	<473B7424.3060407@leemhuis.info>
	<1195116253.28534.147.camel@mccallum.corsepiu.local>
	<473C8589.2010109@leemhuis.info>
Message-ID: <473D8905.40702@leemhuis.info>

On 15.11.2007 18:44, Thorsten Leemhuis wrote:
> On 15.11.2007 09:44, Ralf Corsepius wrote:
>> On Wed, 2007-11-14 at 23:18 +0100, Thorsten Leemhuis wrote:
>> [...]
>
> Similar problem (also not earth-shaking and a corner-case as well), also
> still unfixed:
> https://www.redhat.com/archives/fedora-packaging/2007-August/msg00092.html

Spot, thx for fixing this:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev2=14&rev1=13

Cu
knurd



From paul at city-fan.org  Fri Nov 16 12:12:01 2007
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 16 Nov 2007 12:12:01 +0000
Subject: noarch-python-in-64bit-path (rpmlint)
In-Reply-To: <fhk0g9$heo$1@ger.gmane.org>
References: <fhg4um$dap$1@ger.gmane.org> <473BA14C.9010707@redhat.com>
	<fhk0g9$heo$1@ger.gmane.org>
Message-ID: <473D8911.1070308@city-fan.org>

Neal Becker wrote:
> Jeremy Katz wrote:
> 
>> Neal Becker wrote:
>>> What should I do about this?
>>>
>>> qct-mercurial.noarch: E:
>>> noarch-python-in-64bit-path
>>> /usr/lib64/python2.5/site-packages/hgext/qct.pyc
>>>
>>> I think qct.py needs to go there, because that's where mercurial is going
>>> to
>>> look.  As we discussed before, our multi-arch python is somewhat broken,
>>> because you cannot have both /usr/lib/python/.../some_package
>>> and /usr/lib64/python/.../some_package.  It will only search one of those
>>> locations.  So we cannot have both arch and nonarch site-packages/hgext -
>>> unless maybe I'm misunderstanding something?
>> If it needs to be in the arch-specific path, the package needs to be
>> built for the native arch and not noarch
>>
>> Jeremy
>>
> 
> So qct will build 2 packages, a no-arch qct and an arch qct-mercurial, is
> that correct?
> 
> Can anyone point me to an example of an rpm spec file that does this, I'm
> not sure of the syntax?

Just build the whole lot as arch packages; all of the python-twisted-* 
stack (which is mostly noarch) is built as arch-specific packages for 
this reason.

Paul.



From valent.turkovic at gmail.com  Fri Nov 16 12:16:57 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 16 Nov 2007 13:16:57 +0100
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
Message-ID: <64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>

On 11/16/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> On 11/15/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> > On Thu, 2007-11-15 at 14:55 -0600, Rex Dieter wrote:
> > > Valent Turkovic wrote:
> > >
> > > > Look at this bug:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=355291
> > > > Have any redhat and fedora devels actually used fluendo codecs?
> > >
> > > Strictly speaking, these are fluendo's problems, not fedora's.
> >
> > Strictly speaking, these are Fedora's users' problems.
> >
> > Valent, you've been keeping tabs on developments with this issue. Could
> > you summarize what suggestions have been made to solve it and who made
> > these suggestions? Just the positive feedback, if you please.
> > --
> >
> > Richi Plana
>
> Sorry if my post was a bit negative, I'll try to keep it more positive.
>
> I have talked with fluendo devels and they also said what was also
> said here that it is a intel library issue that they are waiting intel
> to fix.
>
> From my point of view if fedora has a feature that it advertises then
> that feature should work with default settings.
>
> For fedora 8 selinux default setting is enforcing which prevents
> fluendo codecs form working, from my point of view I looks like it is
> a bug in fedora (I know it is not).
>
> Do you need some more specific feedback from me?
>
> Valent


/rant/
Why doesn't redhat or fedora buy one set of codecs so you can test
them yourself? I don't get it... I don't mind helping but it is beyond
my logic that fedora 8 claims that has fluendo codecs working with
fedora 8 but nobody has actually used the codecs to confirm it :)
/end rant/

Valent.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From fedora at leemhuis.info  Fri Nov 16 12:17:42 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 16 Nov 2007 13:17:42 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473D8905.40702@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B3FA8.70106@hhs.nl>
	<473B7424.3060407@leemhuis.info>
	<1195116253.28534.147.camel@mccallum.corsepiu.local>
	<473C8589.2010109@leemhuis.info> <473D8905.40702@leemhuis.info>
Message-ID: <473D8A66.5090207@leemhuis.info>



On 16.11.2007 13:11, Thorsten Leemhuis wrote:
> On 15.11.2007 18:44, Thorsten Leemhuis wrote:
>> On 15.11.2007 09:44, Ralf Corsepius wrote:
>>> On Wed, 2007-11-14 at 23:18 +0100, Thorsten Leemhuis wrote:
>>> [...]
>> Similar problem (also not earth-shaking and a corner-case as well), also
>> still unfixed:
>> https://www.redhat.com/archives/fedora-packaging/2007-August/msg00092.html
> 
> Spot, thx for fixing this:
> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev2=14&rev1=13

Ohh, and I just noticed: the gconf issue was fixed also some weeks ago
-- I just missed it, sorry for the noise.

But that just change my comment much -- I still think if someone is
interested in fixing/improving something in Fedora-land it should be
much easier than it is now. Then people would again do something on
their own instead of relying and waiting for committees to do that work.

CU
knurd



From jkeating at redhat.com  Fri Nov 16 12:26:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Nov 2007 07:26:12 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
Message-ID: <20071116072612.67f129b0@redhat.com>

On Fri, 16 Nov 2007 13:16:57 +0100
"Valent Turkovic" <valent.turkovic at gmail.com> wrote:

> /rant/
> Why doesn't redhat or fedora buy one set of codecs so you can test
> them yourself? I don't get it... I don't mind helping but it is beyond
> my logic that fedora 8 claims that has fluendo codecs working with
> fedora 8 but nobody has actually used the codecs to confirm it :)
> /end rant/

We claim to be able to direct you at legal places that offer codecs for
download, and /they/ claim it works on Fedora 8.  We're not doing
continued integration testing with their codecs, we're just continuing
to make and improve Fedora releases.  It's unfortunate that their
offerings didn't work, that certainly puts them in a bad light.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/fb6c675b/attachment.sig>

From snecklifter at gmail.com  Fri Nov 16 12:28:32 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Fri, 16 Nov 2007 12:28:32 +0000
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
Message-ID: <364d303b0711160428o6c8e096bj5bb66ec3b07ad52@mail.gmail.com>

On 16/11/2007, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> On 11/16/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> > On 11/15/07, Richi Plana <myfedora at richip.dhs.org> wrote:
> > > On Thu, 2007-11-15 at 14:55 -0600, Rex Dieter wrote:
> > > > Valent Turkovic wrote:
> > > >
> > > > > Look at this bug:
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=355291
> > > > > Have any redhat and fedora devels actually used fluendo codecs?
> > > >
> > > > Strictly speaking, these are fluendo's problems, not fedora's.
> > >
> > > Strictly speaking, these are Fedora's users' problems.
> > >
> > > Valent, you've been keeping tabs on developments with this issue. Could
> > > you summarize what suggestions have been made to solve it and who made
> > > these suggestions? Just the positive feedback, if you please.
> > > --
> > >
> > > Richi Plana
> >
> > Sorry if my post was a bit negative, I'll try to keep it more positive.
> >
> > I have talked with fluendo devels and they also said what was also
> > said here that it is a intel library issue that they are waiting intel
> > to fix.
> >
> > From my point of view if fedora has a feature that it advertises then
> > that feature should work with default settings.
> >
> > For fedora 8 selinux default setting is enforcing which prevents
> > fluendo codecs form working, from my point of view I looks like it is
> > a bug in fedora (I know it is not).
> >
> > Do you need some more specific feedback from me?
> >
> > Valent
>
>
> /rant/
> Why doesn't redhat or fedora buy one set of codecs so you can test
> them yourself? I don't get it... I don't mind helping but it is beyond
> my logic that fedora 8 claims that has fluendo codecs working with
> fedora 8 but nobody has actually used the codecs to confirm it :)
> /end rant/

<sigh>

Because some people believe in a world that does not revolve around
proprietary codecs. "Be the change you want to see in the world" and
all that.

Anyway, the codecs work with selinux in permissive or disabled or
after labelling so the claim is not untrue.

Cheers
Chris

-- 
http://www.chruz.com



From caillon at redhat.com  Fri Nov 16 12:40:31 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 16 Nov 2007 13:40:31 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <473C80CC.3070306@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B363C.9030808@redhat.com>	<604aa7910711141015ya2a111eu79ad5ae24dcd0a54@mail.gmail.com>	<473B4D36.8070904@redhat.com>	<473B5041.6080202@hhs.nl>	<20071114202019.GA5162@nostromo.devel.redhat.com>	<alpine.DEB.0.9999.0711151140320.21362@gotcha.dreamhost.com>	<473C3083.5070602@redhat.com>
	<473C80CC.3070306@leemhuis.info>
Message-ID: <473D8FBF.4070809@redhat.com>

On 11/15/2007 06:24 PM, Thorsten Leemhuis wrote:
> 
> On 15.11.2007 12:41, Christopher Aillon wrote:

>> Then we should consider updating our guidelines.  This brings up a good 
>> point, too.  If a given package guideline exists to work around bugs 
>> like this in the future, the guideline really must reference the bug # 
>> so it can be easier to revisit at a future date.
> 
> Agreed, albeit I'm not sure if the exact bug # is needed -- the
> information "need in FC > foo and RHEL > bar" is the important one. And
> maintaining that properly is more important due to EPEL, as we'll still
> have to deal with EPEL for EL4 for some years.

Well for bugs that aren't yet fixed, we need the number.  And a 
reference to the guideline from the bug.



From yabraham2 at gmail.com  Fri Nov 16 12:46:32 2007
From: yabraham2 at gmail.com (yonas Abraham)
Date: Fri, 16 Nov 2007 07:46:32 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071116072612.67f129b0@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com>
Message-ID: <47324ed80711160446u2e0ce888wcdd446aacb7c7e12@mail.gmail.com>

On Nov 16, 2007 7:26 AM, Jesse Keating <jkeating at redhat.com> wrote:
> On Fri, 16 Nov 2007 13:16:57 +0100
> "Valent Turkovic" <valent.turkovic at gmail.com> wrote:
>
> > /rant/
> > Why doesn't redhat or fedora buy one set of codecs so you can test
> > them yourself? I don't get it... I don't mind helping but it is beyond
> > my logic that fedora 8 claims that has fluendo codecs working with
> > fedora 8 but nobody has actually used the codecs to confirm it :)
> > /end rant/
>
> We claim to be able to direct you at legal places that offer codecs for
> download, and /they/ claim it works on Fedora 8.  We're not doing
> continued integration testing with their codecs, we're just continuing
> to make and improve Fedora releases.  It's unfortunate that their
> offerings didn't work, that certainly puts them in a bad light.

I was always wondered about such problem. I have seen several
proprietary apps fail to run on selinux enforcing mode. Is it possible
for a third party to install a supplementary package to fix/modify the
selinux policy file so that their apps work? some thing like the
conf.d in apache or yum.repo.d in yum  that those apps throw their
configuration file on install time and remove it when it is uninstall
ed very easily?

/yonas



From bnocera at redhat.com  Fri Nov 16 12:47:58 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 12:47:58 +0000
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071115235445.4e2f6b51@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
Message-ID: <1195217278.10878.32.camel@cookie.hadess.net>


On Thu, 2007-11-15 at 23:54 -0500, Jesse Keating wrote:
> On Fri, 16 Nov 2007 01:20:57 +0000
> Bastien Nocera <bnocera at redhat.com> wrote:
> 
> > > Fluendo could use a non-closed source compiler (I suggest gcc) so
> > > that the binaries could be made to not need execmem.  
> > 
> > I'm trying to find a way to show you're talking rubbish without being
> > insulting, but I'm failing. The problem isn't the compiler, but the
> > libraries used, in this case Intel's IPP library. It provides
> > convenience functions for optimised decoding of a number of codecs,
> > and various other optimised decoding routines.
> > 
> > Fluendo doesn't have access to the IPP library sources, so we're
> > waiting for Intel to fix this. I'm not holding my breath.
> 
> Ok, fine, s/compiler/library/.  Are you really going to tell me that
> it's impossible to build the mp3 library (and others) without using
> closed source software?

It is extremely incovenient, as you need to reimplement, and reoptimise
large portions of code.



From ivazqueznet at gmail.com  Fri Nov 16 13:25:29 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 16 Nov 2007 08:25:29 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <47324ed80711160446u2e0ce888wcdd446aacb7c7e12@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com>
	<47324ed80711160446u2e0ce888wcdd446aacb7c7e12@mail.gmail.com>
Message-ID: <1195219529.26074.0.camel@ignacio.lan>

On Fri, 2007-11-16 at 07:46 -0500, yonas Abraham wrote:
> I was always wondered about such problem. I have seen several
> proprietary apps fail to run on selinux enforcing mode. Is it possible
> for a third party to install a supplementary package to fix/modify the
> selinux policy file so that their apps work? some thing like the
> conf.d in apache or yum.repo.d in yum  that those apps throw their
> configuration file on install time and remove it when it is uninstall
> ed very easily?

It is.

http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/fc587298/attachment.sig>

From laroche at redhat.com  Fri Nov 16 13:29:54 2007
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 16 Nov 2007 14:29:54 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071115160124.GA40056@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
Message-ID: <20071116132954.GA14352@dudweiler.stuttgart.redhat.com>

On Thu, Nov 15, 2007 at 05:01:24PM +0100, Olivier Galibert wrote:
> Bug #134886 is still there since fedora core 3 times.  It means that
> NetworkManager will happily shutdown the interfaces, ignore any
> settings you've put in anaconda and wipe out /etc/resolv.conf if you
> happen not to use dhcp.  Like in a lab, where desktops and servers
> tend not to wander around so much and dhcp is used only for laptops.

I use "chattr +i /etc/resolv.conf" on many machines with good success,
but know this does not work for all.

regards,

Florian La Roche



From nicolas.mailhot at laposte.net  Fri Nov 16 13:30:03 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Nov 2007 14:30:03 +0100 (CET)
Subject: Review queue/FESCo after the merge
Message-ID: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>


Le Ven 16 novembre 2007 13:11, Thorsten Leemhuis a ?crit :
> On 15.11.2007 18:44, Thorsten Leemhuis wrote:
>> On 15.11.2007 09:44, Ralf Corsepius wrote:
>>> On Wed, 2007-11-14 at 23:18 +0100, Thorsten Leemhuis wrote:
>>> [...]
>>
>> Similar problem (also not earth-shaking and a corner-case as well),
>> also
>> still unfixed:
>> https://www.redhat.com/archives/fedora-packaging/2007-August/msg00092.html
>
> Spot, thx for fixing this:
> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev2=14&rev1=13

If guideline changes are being done this way I wonder why I created a
Fonts SIG, spent days writing fonts packaging guidelines, and
submitted them to FPC (that was supposed to review them for this week
session). It seems following procedures is a lot of work just to be
sidelined by the first person that does not want to bother with them
and posts on fedora-devel.

For the record:
1. I disagreed with this change when it was first posted on fedora-devel.
2. I still disagree with this change
3. I actually maintain font packages (just in case some people still
think that's relevant to comment on associated guidelines)
4. The associated scriplet barfed once in years of use by many
packages (and not even on a stable release but during a rawhide
update!), because of actual packaging bugs in one package. I don't
think one transaction error in years is such a huge price to pay to
keep our packages sane
5. If someone had bothered reading the guidelines submitted to FPC
he'd have seen they only refresh fc-cache on the font directory owned
by a particular package and that only if fontconfig is installed. So a
problem package will only screw itself now.
6. when this error happens you'll better fail the transaction and
reinstall the package. Silently accepting the transaction means you
get fontconfig users complaining the font package that apparently
installed successfully does not work in their fontconfig app (just
lost ~ 1 hour debugging such a case yesterday).

-- 
Nicolas Mailhot



From darth_linux at ameritech.net  Fri Nov 16 13:38:47 2007
From: darth_linux at ameritech.net (eah)
Date: Fri, 16 Nov 2007 08:38:47 -0500
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <1195191694.3147.4.camel@aragorn>
References: <200711152056.46958.darth_linux@ameritech.net>
	<200711152227.29179.darth_linux@ameritech.net>
	<1195191694.3147.4.camel@aragorn>
Message-ID: <200711160838.48206.darth_linux@ameritech.net>

On Friday 16 November 2007 00:41:34 am Trever L. Adams wrote:
> The firmware is identical between the 32-bit and 64-bit drivers. Make
> sure you are using the "approved/supported" firmware. There are only a
> few versions. If it extracts with the right extraction tool, it is
> supported.
>
> Trever
>
> > btw: i'm running x86_64 and i'm pretty sure the firmware was for the
> > 32-bit version.
> >
> > thanks,
> >
> > Eric
>
> --
> "Honor isn't about making the right choices. It's about dealing with the
> consequences." -- Midori Koto

what/where are the approved versions? I used 
http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2 for the 
firmware. I regressed to ndiswrapper and everything works fine using the 
firmware that came from the laptop's driver. 

b43 is getting there. All involved: keep up the good work!  
 
thanks, 

eah 



From SteveD at redhat.com  Fri Nov 16 13:49:57 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Fri, 16 Nov 2007 08:49:57 -0500
Subject: Install hang on a Dell PowerEdge SC1430 
Message-ID: <473DA005.4060406@RedHat.com>

Are there known issues with F8 (and F7) being
installed on PowerEdges? Booting from DVD (and CDs)
I get the following three lines than nothing...

    Loading Vmlinuz........
    Loading initrd.img.....
    Read.

This happens with both x86 and x86_64 installs 
from DVD of either F8 or F7. I also tried burning
the boot.iso from the DVD to a CD and boot from
that with the same results.

Being this is pretty broken, I'm hoping this is a known
problem and there is some type of workaround.

tia,

steved.



From pertusus at free.fr  Fri Nov 16 14:14:59 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 16 Nov 2007 15:14:59 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
Message-ID: <20071116141459.GC3682@free.fr>

On Fri, Nov 16, 2007 at 02:30:03PM +0100, Nicolas Mailhot wrote:
> 
> If guideline changes are being done this way I wonder why I created a
> Fonts SIG, spent days writing fonts packaging guidelines, and
> submitted them to FPC (that was supposed to review them for this week
> session). It seems following procedures is a lot of work just to be
> sidelined by the first person that does not want to bother with them
> and posts on fedora-devel.

I agree that the procedures regarding packaging guidelines changes
should be followed. And bypassing them that way is not right. However I
also think that packagers can also not follow guidelines when they have
reasons to disagree and wait for someone to challenge their position and
bring the issue on the devel list, then to FESCo.

--
Pat



From tcallawa at redhat.com  Fri Nov 16 14:18:13 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 16 Nov 2007 09:18:13 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
Message-ID: <1195222693.3238.11.camel@localhost.localdomain>


On Fri, 2007-11-16 at 14:30 +0100, Nicolas Mailhot wrote:

> For the record:
> 1. I disagreed with this change when it was first posted on fedora-devel.
> 2. I still disagree with this change
> 3. I actually maintain font packages (just in case some people still
> think that's relevant to comment on associated guidelines)
> 4. The associated scriplet barfed once in years of use by many
> packages (and not even on a stable release but during a rawhide
> update!), because of actual packaging bugs in one package. I don't
> think one transaction error in years is such a huge price to pay to
> keep our packages sane

While I understand what you're saying, we adopted the policy that %post
should never ever fail, because it has the potential to really destroy a
large transaction. It was an accidental omission on that specific
section, which is why I corrected it. In fact, I thought I had already
done it a while ago, but had forgotten to.

I have read your font guideline drafts, and I think they are rather
good. We simply just don't want any scriptlets to fail, no matter how
unlikely or contained the failure may be.

Please don't take it personally. :)

~spot



From rc040203 at freenet.de  Fri Nov 16 14:25:16 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 16 Nov 2007 15:25:16 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
Message-ID: <1195223116.28534.188.camel@mccallum.corsepiu.local>


On Fri, 2007-11-16 at 14:30 +0100, Nicolas Mailhot wrote:
> If guideline changes are being done this way I wonder why I created a
> Fonts SIG, spent days writing fonts packaging guidelines, and
> submitted them to FPC (that was supposed to review them for this week
> session).
FWIW: This week's meeting failed due to mis-communications related to
the DST-time switch in the US (one wiki page said 16:00UTC, another one
said 17:00UTC).

Ralf

PS: Your mailer still tears threads apart.
 




From gilboad at gmail.com  Fri Nov 16 14:35:40 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Fri, 16 Nov 2007 16:35:40 +0200
Subject: compat-stdc++ deprecated in F8?
Message-ID: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>

Hello all,

Were compat-stdc++ (and the rest of the compat-* libs group) packages
deprecated in F8?
If so, it's there any chance they'll be resurrected?
If not - did anyone attempt to rebuild the F7 compat-stdc++ SRPMs under
F8/rawhide? Any known issues?

- Gilboa
P.S. I need the compat-stdc++ (+dependencies) for UT2004. I assume that
other closed source applications/games will also require this package.




From erik at vanpienbroek.nl  Fri Nov 16 14:37:09 2007
From: erik at vanpienbroek.nl (Erik van Pienbroek)
Date: Fri, 16 Nov 2007 15:37:09 +0100
Subject: XULRunner in rawhide
In-Reply-To: <473C85A5.9020100@redhat.com>
References: <473AFF3E.1090904@redhat.com>
	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
	<473C85A5.9020100@redhat.com>
Message-ID: <1195223829.22911.3.camel@alguno>


Op donderdag 15-11-2007 om 18:45 uur [tijdzone +0100], schreef Martin Stransky:
> Alex Lancaster wrote:
> > Is 'xulrunner-gtkmozembed' supposed to be provided by the xulrunner
> > package somehow?  Is there another BuildRequires I need to add?
> 
> First and experimental xulrunner-gtkmozembed is in 
> rawhide/xulrunner-1.9-0.alpha9.5.fc9 now. I don't have any proper 
> test-case (galeon doesn't compile because of some other problems) so it 
> can fail but please test it...

I've just installed the latest xulrunner package from koji, but the
compilation of my gtkmozembed based program fails due to a missing file:

$ pkg-config --libs xulrunner-gtkmozembed
-L/usr/lib/xulrunner-1.9a9pre -lxpcomglue_s -lxul -lxpcom -lplds4 -lplc4
-lnspr4 -lpthread -ldl  

$ find /usr/lib/xulrunner-1.9a9pre -name xpcomglue*
<no results>

The library xpcomglue_s doesn't exist yet in the xulrunner{,-devel}
package.

Regards,

Erik van Pienbroek




From jkeating at redhat.com  Fri Nov 16 14:37:49 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Nov 2007 09:37:49 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195217278.10878.32.camel@cookie.hadess.net>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
Message-ID: <20071116093749.387f3782@redhat.com>

On Fri, 16 Nov 2007 12:47:58 +0000
Bastien Nocera <bnocera at redhat.com> wrote:

> > Ok, fine, s/compiler/library/.  Are you really going to tell me that
> > it's impossible to build the mp3 library (and others) without using
> > closed source software?  
> 
> It is extremely incovenient, as you need to reimplement, and
> reoptimise large portions of code.

Yeah, this makes me like our involvement with Fluendo even more...

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/998de34e/attachment.sig>

From tcallawa at redhat.com  Fri Nov 16 14:39:01 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 16 Nov 2007 09:39:01 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195217278.10878.32.camel@cookie.hadess.net>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
Message-ID: <1195223941.3238.20.camel@localhost.localdomain>


On Fri, 2007-11-16 at 12:47 +0000, Bastien Nocera wrote:
> On Thu, 2007-11-15 at 23:54 -0500, Jesse Keating wrote:
> > On Fri, 16 Nov 2007 01:20:57 +0000
> > Bastien Nocera <bnocera at redhat.com> wrote:
> > 
> > > > Fluendo could use a non-closed source compiler (I suggest gcc) so
> > > > that the binaries could be made to not need execmem.  
> > > 
> > > I'm trying to find a way to show you're talking rubbish without being
> > > insulting, but I'm failing. The problem isn't the compiler, but the
> > > libraries used, in this case Intel's IPP library. It provides
> > > convenience functions for optimised decoding of a number of codecs,
> > > and various other optimised decoding routines.
> > > 
> > > Fluendo doesn't have access to the IPP library sources, so we're
> > > waiting for Intel to fix this. I'm not holding my breath.
> > 
> > Ok, fine, s/compiler/library/.  Are you really going to tell me that
> > it's impossible to build the mp3 library (and others) without using
> > closed source software?
> 
> It is extremely incovenient, as you need to reimplement, and reoptimise
> large portions of code.

Seriously, how optimized does the mp3 codec need to be? I used to play
mp3s on a Windows 3.1 box with 128 MB of memory. RPM Fusion is full of
players using gcc, and I've yet to run into a place where I needed to
optimize beyond -O2 with gcc.

~spot



From paul at city-fan.org  Fri Nov 16 14:42:31 2007
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 16 Nov 2007 14:42:31 +0000
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
Message-ID: <473DAC57.1030909@city-fan.org>

Gilboa Davara wrote:
> Hello all,
> 
> Were compat-stdc++ (and the rest of the compat-* libs group) packages
> deprecated in F8?
> If so, it's there any chance they'll be resurrected?
> If not - did anyone attempt to rebuild the F7 compat-stdc++ SRPMs under
> F8/rawhide? Any known issues?
> 
> - Gilboa
> P.S. I need the compat-stdc++ (+dependencies) for UT2004. I assume that
> other closed source applications/games will also require this package.

Perhaps you're trying the wrong package name?

# yum install compat-libstdc++\*
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package compat-libstdc++-33.i386 0:3.2.3-62 set to be updated
---> Package compat-libstdc++-296.i386 0:2.96-139 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
  Package                 Arch       Version          Repository 
Size
=============================================================================
Installing:
  compat-libstdc++-296    i386       2.96-139         fedora 
  91 k
  compat-libstdc++-33     i386       3.2.3-62         fedora 
230 k

Transaction Summary
=============================================================================
Install      2 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 321 k
Is this ok [y/N]: n
Exiting on user Command
Complete!
#



I can never remember the right name to use either, so I usually ask yum 
for the required soname instead:

# yum install libstdc++.so.5
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package compat-libstdc++-33.i386 0:3.2.3-62 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
  Package                 Arch       Version          Repository 
Size
=============================================================================
Installing:
  compat-libstdc++-33     i386       3.2.3-62         fedora 
230 k

Transaction Summary
=============================================================================
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 230 k
Is this ok [y/N]: n
Exiting on user Command
Complete!
#

Paul.



From abo at kth.se  Fri Nov 16 14:52:35 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Fri, 16 Nov 2007 15:52:35 +0100
Subject: LDAP and the dbus user
In-Reply-To: <20071116130955.159f9c1b@dhcp03.addix.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<20071115191131.GC60438@dspnet.fr.eu.org>
	<20071115143152.4170c48f@redhat.com> <473CA371.1060808@gmail.com>
	<604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>
	<473D5211.2040906@gmail.com> <20071116130955.159f9c1b@dhcp03.addix.net>
Message-ID: <1195224756.618.36.camel@home.alexander.bostrom.net>

fre 2007-11-16 klockan 13:09 +0100 skrev Ralf Ertzinger:
> On Fri, 16 Nov 2007 03:17:21 -0500, Kelly Miller wrote:

> > the result is
> > NetworkManager needs DBus, which needs LDAP, which needs
> > NetworkManager.  The result?  The system freezes at the first service
> > in the cycle.
> 
> There is a neat option I learned some time ago:
> 
> nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
> 
> This (should) make ldap ignore these users (which exist locally,
> unless you manually removed them)

Oh yes... Is the correct solution here to make this the default?

/abo



From notting at redhat.com  Fri Nov 16 14:52:55 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Nov 2007 09:52:55 -0500
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
Message-ID: <20071116145255.GB29805@nostromo.devel.redhat.com>

Gilboa Davara (gilboad at gmail.com) said: 
> Were compat-stdc++ (and the rest of the compat-* libs group) packages
> deprecated in F8?

No, they're still there (compat-libstdc++-33, compat-libstdc++-296). They
are almost certainly not on the live CDs or Fedora spins, but they're
in the repo if you need them.

Bill



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov 16 14:52:44 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 16 Nov 2007 15:52:44 +0100
Subject: FLAC 1.2.x may need rebuilds
Message-ID: <20071116155244.d64400c8.mschwendt.tmp0701.nospam@arcor.de>

The Fedora 8 upgrade from FLAC 1.1.4 to 1.2.0 has broken FLAC file import
in Audacity. A simple rebuild of Audacity fixes it.

All packagers with a dependency on libFLAC* are advised to check whether
they also need to rebuild their packages.

flac 1.2.1-1 : Tue Sep 18 2007
flac 1.2.0-1 : Tue Sep 11 2007

[...]

Fedora 7 most likely is affected, too, due to a FLAC security update
from 1.1.4 to 1.2.1:

flac 1.2.1-1 : Wed Oct 17 2007



From caillon at redhat.com  Fri Nov 16 14:56:05 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 16 Nov 2007 15:56:05 +0100
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071116072612.67f129b0@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>	<fhibor$h18$1@ger.gmane.org>	<1195161122.18227.3.camel@localhost6.localdomain6>	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com>
Message-ID: <473DAF85.9000305@redhat.com>

On 11/16/2007 01:26 PM, Jesse Keating wrote:
> On Fri, 16 Nov 2007 13:16:57 +0100
> "Valent Turkovic" <valent.turkovic at gmail.com> wrote:
> 
>> /rant/
>> Why doesn't redhat or fedora buy one set of codecs so you can test
>> them yourself? I don't get it... I don't mind helping but it is beyond
>> my logic that fedora 8 claims that has fluendo codecs working with
>> fedora 8 but nobody has actually used the codecs to confirm it :)
>> /end rant/
> 
> We claim to be able to direct you at legal places that offer codecs for
> download, and /they/ claim it works on Fedora 8.  We're not doing
> continued integration testing with their codecs, we're just continuing
> to make and improve Fedora releases.  It's unfortunate that their
> offerings didn't work, that certainly puts them in a bad light.

If Fluendo were to ever start taking our users' money and then run 
without giving them anything to download, we'd immediately stop linking 
to them.

If our users are getting an equivalent experience, shouldn't we consider 
temporarily removing our link to them until they fix the issue?  I 
understand it's not completely their fault and am sympathetic to their 
plight, but for us to ignore the problem is counter to the reason why we 
are linking directly to a web page we control.



From abo at kth.se  Fri Nov 16 15:00:13 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Fri, 16 Nov 2007 16:00:13 +0100
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195223941.3238.20.camel@localhost.localdomain>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
	<1195223941.3238.20.camel@localhost.localdomain>
Message-ID: <1195225213.618.43.camel@home.alexander.bostrom.net>

fre 2007-11-16 klockan 09:39 -0500 skrev Tom "spot" Callaway:

> Seriously, how optimized does the mp3 codec need to be? I used to play
> mp3s on a Windows 3.1 box with 128 MB of memory. RPM Fusion is full of
> players using gcc, and I've yet to run into a place where I needed to
> optimize beyond -O2 with gcc.

It's not just MP3, though. I've been stuck on an P3 laptop for a while
(the fast computer is in the closet). On such a machine faster codecs
can really make a difference.

/abo



From jima at beer.tclug.org  Fri Nov 16 15:01:33 2007
From: jima at beer.tclug.org (Jima)
Date: Fri, 16 Nov 2007 09:01:33 -0600 (CST)
Subject: Static DHCP
In-Reply-To: <1195203509.618.31.camel@home.alexander.bostrom.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
	<473C985A.8010202@gmail.com> <20071115140852.654ca31a@redhat.com> 
	<473CA089.4010007@gmail.com>
	<1195203509.618.31.camel@home.alexander.bostrom.net>
Message-ID: <Pine.LNX.4.64.0711160851590.4486@beer.tclug.org>

On Fri, 16 Nov 2007, Alexander Bostr?m wrote:
> It's usually a good idea to have a central registry of which computer
> has which IP addresses, with MAC address info. Once you have that it's
> easy to also generate a dhcpd.conf from that info to assign static IP:s.

  And heck, dnsmasq is even easier to set up for that.  You can just 
populate /etc/hosts and /etc/ethers (as per their specifications), and 
dnsmasq will use that for static DHCP assignments.  I.e.:

/etc/hosts
192.168.1.5	blue
192.168.1.6	green
192.168.1.7	red
192.168.1.8	brown

/etc/ethers
00:11:22:00:00:aa	blue
00:11:22:00:00:bb	green
00:11:22:00:00:cc	red
00:11:22:00:00:dd	brown

  Make sure "read-ethers" is uncommented in dnsmasq.conf, and you're set. 
(Okay, there are a couple other configuration changes required before 
dnsmasq will DTRT, but that's true of ISC's dhcpd, too.)
  I even have a script that takes a file with the format:

mac	ip	hostname

  and spits out the appropriate /etc/hosts and /etc/ethers. :-)

  FWIW, I manage ~20 networks with static DHCP, many of which have machines 
roaming to and fro.

      Jima

(fedora dnsmasq maintainer and advocate)

From tcallawa at redhat.com  Fri Nov 16 15:03:58 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 16 Nov 2007 10:03:58 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473D8A66.5090207@leemhuis.info>
References: <fheo3b$8nv$1@ger.gmane.org>
	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>
	<473B3FA8.70106@hhs.nl> <473B7424.3060407@leemhuis.info>
	<1195116253.28534.147.camel@mccallum.corsepiu.local>
	<473C8589.2010109@leemhuis.info> <473D8905.40702@leemhuis.info>
	<473D8A66.5090207@leemhuis.info>
Message-ID: <1195225438.3238.40.camel@localhost.localdomain>


On Fri, 2007-11-16 at 13:17 +0100, Thorsten Leemhuis wrote:

> But that just change my comment much -- I still think if someone is
> interested in fixing/improving something in Fedora-land it should be
> much easier than it is now. Then people would again do something on
> their own instead of relying and waiting for committees to do that work.

My intent in shaping the Packaging Guidelines the way that they are is
not to make life difficult for contributors, but rather, to ensure
consistency.

Often, the FPC members disagree on the correct guidelines to implement.
If we were to open the Guidelines and make them editable to all, we
would see wiki wars on contentious issues, people adding their own rules
and corner cases, and possibly contradicting guidelines.

The FPC has a documented process (which is almost never followed) on how
to make a change to anything under Packaging/ (or to propose new
Guidelines):

http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146

Sending a change request to the mailing list doesn't scale, as it gets
lost in the shuffle. Every single meeting, I open:

http://fedoraproject.org/wiki/Packaging/GuidelinesTodo

(which embeds the DraftsTodo page), and I put all the new draft/change
requests in front of the FPC.

We try to do this as efficiently as possible. We are ALWAYS open to new
drafts and changes. We may not always approve them, but we will discuss
just about anything. We're also open to process improvements, and we're
actively seeking new members to serve on the FPC.

Thorsten, this is certainly not intended as a criticism for you, as I
continue to have great admiration for the work that you do in the Fedora
community, but rather, a call to action for specific improvements that
we can make to streamline the bureaucracy. :)

Thanks,

~spot



From marc at mwiriadi.id.au  Fri Nov 16 15:08:05 2007
From: marc at mwiriadi.id.au (Marc Wiriadisastra)
Date: Sat, 17 Nov 2007 00:08:05 +0900 (WST)
Subject: Documentation
Message-ID: <45115.202.72.163.232.1195225685.squirrel@www.mwiriadi.id.au>

Hey all,

Just wanted your thoughts on something relating to documentation.  I had a
read of
http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac
relating specifically to the documentation aspect.  Basically I was
looking at  packaging Diveintopython.

http://www.diveintopython.org/index.html

There is no clear guideline except for will it improve the user
experience.  To me thats fairly ambiguous as to what is considered
improving the user experience.  It's probably worded that way specifically
for a reason to not limit what goes in.

>From my point of view this extends further for when the docs project get
the admin and desktop user guides completed obviously I would assume they
would be packaged.  If thats not the case then please correct me.

The other thing I did notice is that in the groups there is a
documentation section so the question is what constitutes improving the
user experience?

Cheers,

Marc



From jkeating at redhat.com  Fri Nov 16 15:10:54 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Nov 2007 10:10:54 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <473DAF85.9000305@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com> <473DAF85.9000305@redhat.com>
Message-ID: <20071116101054.5de68ce9@redhat.com>

On Fri, 16 Nov 2007 15:56:05 +0100
Christopher Aillon <caillon at redhat.com> wrote:

> If our users are getting an equivalent experience, shouldn't we
> consider temporarily removing our link to them until they fix the
> issue?  I understand it's not completely their fault and am
> sympathetic to their plight, but for us to ignore the problem is
> counter to the reason why we are linking directly to a web page we
> control.

Somebody needs to own this issue, and either drive the SELinux change
to allow these codecs to work, or remove fluendo from the codeina set
(leaving nothing...), or add an additional window or something that
tells people how to work around the selinux issue.

Any volunteers?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/735c34fd/attachment.sig>

From dhollis at davehollis.com  Fri Nov 16 15:12:50 2007
From: dhollis at davehollis.com (David Hollis)
Date: Fri, 16 Nov 2007 15:12:50 +0000
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <Pine.LNX.4.64.0711151712190.11735@tigger.tntechs.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>	<20071115134417.49b562a0@redhat.com>
	<473C985A.8010202@gmail.com>	<1195154137.7532.2.camel@rousalka.dyndns.org>
	<Pine.LNX.4.64.0711151712190.11735@tigger.tntechs.com>
Message-ID: <1195225970.3726.2.camel@dhollis-lnx.sunera.com>


On Thu, 2007-11-15 at 17:14 -0500, Tom Diehl wrote:
> Just to be pedantic, how does the machine running the dhcp server
> software
> get an ip address if you do not hard code it? :-)

Actually, this works fine on Linux.  I use it for some of my systems at
other offices that provide RIS services for rebuilding laptops with our
corporate image.  The system itself pulls an IP via DHCP off the local
WAP gateway device, but then runs a DHCP server of its own (on the same
subnet) to send out the requisite PXE booting information for clients
when they are booted that way.  Doesn't conflict, things work, it's
actually quite nice.


-- 
David Hollis <dhollis at davehollis.com>



From sundaram at fedoraproject.org  Fri Nov 16 15:12:26 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Nov 2007 20:42:26 +0530
Subject: Documentation
In-Reply-To: <45115.202.72.163.232.1195225685.squirrel@www.mwiriadi.id.au>
References: <45115.202.72.163.232.1195225685.squirrel@www.mwiriadi.id.au>
Message-ID: <473DB35A.4090008@fedoraproject.org>

Marc Wiriadisastra wrote:

>>From my point of view this extends further for when the docs project get
> the admin and desktop user guides completed obviously I would assume they
> would be packaged.  If thats not the case then please correct me.

That was the intention but it hasn't been done yet. Volunteers welcome.

Rahul



From mclasen at redhat.com  Fri Nov 16 15:18:09 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 16 Nov 2007 10:18:09 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195222693.3238.11.camel@localhost.localdomain>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
Message-ID: <1195226289.3002.4.camel@localhost.localdomain>


On Fri, 2007-11-16 at 09:18 -0500, Tom "spot" Callaway wrote:
> On Fri, 2007-11-16 at 14:30 +0100, Nicolas Mailhot wrote:
> 
> > For the record:
> > 1. I disagreed with this change when it was first posted on fedora-devel.
> > 2. I still disagree with this change
> > 3. I actually maintain font packages (just in case some people still
> > think that's relevant to comment on associated guidelines)
> > 4. The associated scriplet barfed once in years of use by many
> > packages (and not even on a stable release but during a rawhide
> > update!), because of actual packaging bugs in one package. I don't
> > think one transaction error in years is such a huge price to pay to
> > keep our packages sane
> 
> While I understand what you're saying, we adopted the policy that %post
> should never ever fail, because it has the potential to really destroy a
> large transaction. It was an accidental omission on that specific
> section, which is why I corrected it. In fact, I thought I had already
> done it a while ago, but had forgotten to.
> 
> I have read your font guideline drafts, and I think they are rather
> good. We simply just don't want any scriptlets to fail, no matter how
> unlikely or contained the failure may be.
> 
> Please don't take it personally. :)
> 

Of course, the correct way to have scriptlets that don't fail is to
write them in a way that doesn't fails, not the swipe the failure under
the carpet...



From mclasen at redhat.com  Fri Nov 16 15:20:56 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 16 Nov 2007 10:20:56 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071116093749.387f3782@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
	<20071116093749.387f3782@redhat.com>
Message-ID: <1195226456.3002.7.camel@localhost.localdomain>


On Fri, 2007-11-16 at 09:37 -0500, Jesse Keating wrote:
> On Fri, 16 Nov 2007 12:47:58 +0000
> Bastien Nocera <bnocera at redhat.com> wrote:
> 
> > > Ok, fine, s/compiler/library/.  Are you really going to tell me that
> > > it's impossible to build the mp3 library (and others) without using
> > > closed source software?  
> > 
> > It is extremely incovenient, as you need to reimplement, and
> > reoptimise large portions of code.
> 
> Yeah, this makes me like our involvement with Fluendo even more...

I'm running rawhide and have sealert pop up annoying bubbles every
second. Is there any reason to pick particularly on Fluendo here, when
the rest of the distribution works just as well (== not very well) with
selinux ?



From pertusus at free.fr  Fri Nov 16 15:25:43 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 16 Nov 2007 16:25:43 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195225438.3238.40.camel@localhost.localdomain>
References: <fheo3b$8nv$1@ger.gmane.org> <473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>
	<473B3418.9020207@leemhuis.info> <473B3FA8.70106@hhs.nl>
	<473B7424.3060407@leemhuis.info>
	<1195116253.28534.147.camel@mccallum.corsepiu.local>
	<473C8589.2010109@leemhuis.info> <473D8905.40702@leemhuis.info>
	<473D8A66.5090207@leemhuis.info>
	<1195225438.3238.40.camel@localhost.localdomain>
Message-ID: <20071116152543.GD3682@free.fr>

On Fri, Nov 16, 2007 at 10:03:58AM -0500, Tom spot Callaway wrote:
> 
> The FPC has a documented process (which is almost never followed) on how

I am external to the FPC, but I follow these issues and it seems to me
that this process is often followed -- maybe not to the letter, but to
the intent. For little changes a mail may suffice (I remember I refused
to make a draft for the tetex -> tex prefix change), but as far as I
remember, there has always been a vote.

> We try to do this as efficiently as possible. We are ALWAYS open to new
> drafts and changes. We may not always approve them, but we will discuss
> just about anything. 

I can testify that it is true, since everytime I proposed something
informally or formally it was nicely discussed and processed. Sometimes
it takes long because one has to have a discussion, then FPC votes, then
FESCo ratifies, but I doubt this may be better without sucking too much
commitee members time.

> We're also open to process improvements, and we're
> actively seeking new members to serve on the FPC.
> 
> Thorsten, this is certainly not intended as a criticism for you, as I
> continue to have great admiration for the work that you do in the Fedora
> community, but rather, a call to action for specific improvements that
> we can make to streamline the bureaucracy. :)

I am not a bureaucracy lover and it seems to me that the FPC is doing a
good work. We really need bureaucracy for the guideline changes. And
maybe I am disgressing here, but I also think that sometimes some
bureaucracy helps shaping processes such that the process themselves are
less bureaucratic. For example if there had been a commitee composed of
users looking at the rel-eng policy changes, maybe there won't have been
so much heavy processes accepted (this is gradually becoming better 
but at some point it was unbearable). Otherwise said bureaucratic
control over the processes themselves may help avoiding bureaucratic 
processes.

--
Pat



From tcallawa at redhat.com  Fri Nov 16 15:24:37 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 16 Nov 2007 10:24:37 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195226289.3002.4.camel@localhost.localdomain>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
Message-ID: <1195226677.3238.45.camel@localhost.localdomain>


On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:

> Of course, the correct way to have scriptlets that don't fail is to
> write them in a way that doesn't fails, not the swipe the failure under
> the carpet...

Yes, but fixing every possible application which could ever be put in a
scriplet to never, ever, ever fail, even in the cases when failure is
acceptable (and shouldn't kill the transaction) is a little beyond the
mandate of the FPC. ;)

~spot



From tmraz at redhat.com  Fri Nov 16 15:33:03 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 16 Nov 2007 16:33:03 +0100
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195226456.3002.7.camel@localhost.localdomain>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
	<20071116093749.387f3782@redhat.com>
	<1195226456.3002.7.camel@localhost.localdomain>
Message-ID: <1195227183.5377.24.camel@vespa.kabelta.loc>


On Fri, 2007-11-16 at 10:20 -0500, Matthias Clasen wrote:
> On Fri, 2007-11-16 at 09:37 -0500, Jesse Keating wrote:
> > On Fri, 16 Nov 2007 12:47:58 +0000
> > Bastien Nocera <bnocera at redhat.com> wrote:
> > 
> > > > Ok, fine, s/compiler/library/.  Are you really going to tell me that
> > > > it's impossible to build the mp3 library (and others) without using
> > > > closed source software?  
> > > 
> > > It is extremely incovenient, as you need to reimplement, and
> > > reoptimise large portions of code.
> > 
> > Yeah, this makes me like our involvement with Fluendo even more...
> 
> I'm running rawhide and have sealert pop up annoying bubbles every
> second. Is there any reason to pick particularly on Fluendo here, when
> the rest of the distribution works just as well (== not very well) with
> selinux ?
I'm running updated Fedora 8 and don't have sealert pop up pretty much
anything these days. Rawhide might be different - unstable, development
you know.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From mclasen at redhat.com  Fri Nov 16 15:33:41 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 16 Nov 2007 10:33:41 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195226677.3238.45.camel@localhost.localdomain>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
Message-ID: <1195227221.3002.9.camel@localhost.localdomain>


On Fri, 2007-11-16 at 10:24 -0500, Tom "spot" Callaway wrote:
> On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
> 
> > Of course, the correct way to have scriptlets that don't fail is to
> > write them in a way that doesn't fails, not the swipe the failure under
> > the carpet...
> 
> Yes, but fixing every possible application which could ever be put in a
> scriplet to never, ever, ever fail, even in the cases when failure is
> acceptable (and shouldn't kill the transaction) is a little beyond the
> mandate of the FPC. ;)
> 

If scriptlet are not allowed to ever, ever, fail, then just make rpm
ignore the exit code of scriptlets.



From snecklifter at gmail.com  Fri Nov 16 15:35:41 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Fri, 16 Nov 2007 15:35:41 +0000
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195226456.3002.7.camel@localhost.localdomain>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
	<20071116093749.387f3782@redhat.com>
	<1195226456.3002.7.camel@localhost.localdomain>
Message-ID: <364d303b0711160735q2cf1442ew9cadda1fcb24e221@mail.gmail.com>

On 16/11/2007, Matthias Clasen <mclasen at redhat.com> wrote:
>
> On Fri, 2007-11-16 at 09:37 -0500, Jesse Keating wrote:
> > On Fri, 16 Nov 2007 12:47:58 +0000
> > Bastien Nocera <bnocera at redhat.com> wrote:
> >
> > > > Ok, fine, s/compiler/library/.  Are you really going to tell me that
> > > > it's impossible to build the mp3 library (and others) without using
> > > > closed source software?
> > >
> > > It is extremely incovenient, as you need to reimplement, and
> > > reoptimise large portions of code.
> >
> > Yeah, this makes me like our involvement with Fluendo even more...
>
> I'm running rawhide and have sealert pop up annoying bubbles every
> second. Is there any reason to pick particularly on Fluendo here, when
> the rest of the distribution works just as well (== not very well) with
> selinux ?

Only because doing so would let the thread degenerate into another
SELinux-bashing festival and there have been enough of those.

Cheers
Chris

-- 
http://www.chruz.com



From tcallawa at redhat.com  Fri Nov 16 15:36:11 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 16 Nov 2007 10:36:11 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195227221.3002.9.camel@localhost.localdomain>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
Message-ID: <1195227371.3238.47.camel@localhost.localdomain>


On Fri, 2007-11-16 at 10:33 -0500, Matthias Clasen wrote:
> On Fri, 2007-11-16 at 10:24 -0500, Tom "spot" Callaway wrote:
> > On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
> > 
> > > Of course, the correct way to have scriptlets that don't fail is to
> > > write them in a way that doesn't fails, not the swipe the failure under
> > > the carpet...
> > 
> > Yes, but fixing every possible application which could ever be put in a
> > scriplet to never, ever, ever fail, even in the cases when failure is
> > acceptable (and shouldn't kill the transaction) is a little beyond the
> > mandate of the FPC. ;)
> > 
> 
> If scriptlet are not allowed to ever, ever, fail, then just make rpm
> ignore the exit code of scriptlets.

Again, code changes are outside of the FPC mandate. Feel like patching
rpm? :)

~spot



From notting at redhat.com  Fri Nov 16 15:41:49 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Nov 2007 10:41:49 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195227221.3002.9.camel@localhost.localdomain>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
Message-ID: <20071116154149.GC422@nostromo.devel.redhat.com>

Matthias Clasen (mclasen at redhat.com) said: 
> > Yes, but fixing every possible application which could ever be put in a
> > scriplet to never, ever, ever fail, even in the cases when failure is
> > acceptable (and shouldn't kill the transaction) is a little beyond the
> > mandate of the FPC. ;)
> 
> If scriptlet are not allowed to ever, ever, fail, then just make rpm
> ignore the exit code of scriptlets.

scriptlets should be allowed to fail when the failure is catastrophic
enough. What that is, I'm not sure.

Bill



From ndbecker2 at gmail.com  Fri Nov 16 15:46:21 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 16 Nov 2007 10:46:21 -0500
Subject: noarch-python-in-64bit-path (rpmlint)
References: <fhg4um$dap$1@ger.gmane.org> <473BA14C.9010707@redhat.com>
	<fhk0g9$heo$1@ger.gmane.org> <473D8911.1070308@city-fan.org>
Message-ID: <fhke0d$1ep$1@ger.gmane.org>

Paul Howarth wrote:

> Neal Becker wrote:
>> Jeremy Katz wrote:
>> 
>>> Neal Becker wrote:
>>>> What should I do about this?
>>>>
>>>> qct-mercurial.noarch: E:
>>>> noarch-python-in-64bit-path
>>>> /usr/lib64/python2.5/site-packages/hgext/qct.pyc
>>>>
>>>> I think qct.py needs to go there, because that's where mercurial is
>>>> going to
>>>> look.  As we discussed before, our multi-arch python is somewhat
>>>> broken, because you cannot have both /usr/lib/python/.../some_package
>>>> and /usr/lib64/python/.../some_package.  It will only search one of
>>>> those
>>>> locations.  So we cannot have both arch and nonarch site-packages/hgext
>>>> - unless maybe I'm misunderstanding something?
>>> If it needs to be in the arch-specific path, the package needs to be
>>> built for the native arch and not noarch
>>>
>>> Jeremy
>>>
>> 
>> So qct will build 2 packages, a no-arch qct and an arch qct-mercurial, is
>> that correct?
>> 
>> Can anyone point me to an example of an rpm spec file that does this, I'm
>> not sure of the syntax?
> 
> Just build the whole lot as arch packages; all of the python-twisted-*
> stack (which is mostly noarch) is built as arch-specific packages for
> this reason.
> 
> Paul.
> 
This will trigger:
rpmlint RPM/RPMS/x86_64/qct-1.5-4.fc8.x86_64.rpm 
qct.x86_64: E: no-binary

I believe this is ignorable?



From linville at redhat.com  Fri Nov 16 15:48:29 2007
From: linville at redhat.com (John W. Linville)
Date: Fri, 16 Nov 2007 10:48:29 -0500
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <200711152056.46958.darth_linux@ameritech.net>
References: <200711152056.46958.darth_linux@ameritech.net>
Message-ID: <20071116154828.GA11383@redhat.com>

On Thu, Nov 15, 2007 at 08:56:46PM -0500, eah wrote:

> I have the BCM4318 wlan0. b43 driver picks it up after following instructions 
> using  broadcom-wl-4.80.53.0.tar.bz2. It does not active the card's radio (my 
> little blue light stays dark to say it like an end user) . dmesg 
> reports "ADDRCONF(NETDEV_UP): wlan0: link is not ready"

To answer your later question, this is the right firmware.  I am
presuming that you extracted the firmware already.
 
> What do I need to do to get that working? 
> 
> This is the farthest I've ever gotten using the stock driver, so kudos to all 
> involved in that. 

Are these your only indications?  Did you actually try to activate
the card using NetworkManager, wpa_supplicant, or iwconfig?

Regarding the "little blue light", did you try pushing the RF kill
button?  Sometimes they are a software-controlled toggle rather than
an actual physical switch.  (Note: don't bother with this without
trying NetworkManger, et al. first...)

John
-- 
John W. Linville
linville at redhat.com



From paul at city-fan.org  Fri Nov 16 15:54:35 2007
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 16 Nov 2007 15:54:35 +0000
Subject: noarch-python-in-64bit-path (rpmlint)
In-Reply-To: <fhke0d$1ep$1@ger.gmane.org>
References: <fhg4um$dap$1@ger.gmane.org>
	<473BA14C.9010707@redhat.com>	<fhk0g9$heo$1@ger.gmane.org>
	<473D8911.1070308@city-fan.org> <fhke0d$1ep$1@ger.gmane.org>
Message-ID: <473DBD3B.7070707@city-fan.org>

Neal Becker wrote:
> Paul Howarth wrote:
> 
>> Neal Becker wrote:
>>> Jeremy Katz wrote:
>>>
>>>> Neal Becker wrote:
>>>>> What should I do about this?
>>>>>
>>>>> qct-mercurial.noarch: E:
>>>>> noarch-python-in-64bit-path
>>>>> /usr/lib64/python2.5/site-packages/hgext/qct.pyc
>>>>>
>>>>> I think qct.py needs to go there, because that's where mercurial is
>>>>> going to
>>>>> look.  As we discussed before, our multi-arch python is somewhat
>>>>> broken, because you cannot have both /usr/lib/python/.../some_package
>>>>> and /usr/lib64/python/.../some_package.  It will only search one of
>>>>> those
>>>>> locations.  So we cannot have both arch and nonarch site-packages/hgext
>>>>> - unless maybe I'm misunderstanding something?
>>>> If it needs to be in the arch-specific path, the package needs to be
>>>> built for the native arch and not noarch
>>>>
>>>> Jeremy
>>>>
>>> So qct will build 2 packages, a no-arch qct and an arch qct-mercurial, is
>>> that correct?
>>>
>>> Can anyone point me to an example of an rpm spec file that does this, I'm
>>> not sure of the syntax?
>> Just build the whole lot as arch packages; all of the python-twisted-*
>> stack (which is mostly noarch) is built as arch-specific packages for
>> this reason.
>>
>> Paul.
>>
> This will trigger:
> rpmlint RPM/RPMS/x86_64/qct-1.5-4.fc8.x86_64.rpm 
> qct.x86_64: E: no-binary
> 
> I believe this is ignorable?

Yes, 'cause there's a good reason for it in this case.


Paul.



From kanarip at kanarip.com  Fri Nov 16 16:02:07 2007
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Fri, 16 Nov 2007 17:02:07 +0100
Subject: Static DHCP
In-Reply-To: <Pine.LNX.4.64.0711160851590.4486@beer.tclug.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<20071115134417.49b562a0@redhat.com>
	<473C985A.8010202@gmail.com> <20071115140852.654ca31a@redhat.com>
	<473CA089.4010007@gmail.com>
	<1195203509.618.31.camel@home.alexander.bostrom.net>
	<Pine.LNX.4.64.0711160851590.4486@beer.tclug.org>
Message-ID: <473DBEFF.60202@kanarip.com>

On Fri, 16 Nov 2007, Alexander Bostr?m wrote:
> It's usually a good idea to have a central registry of which computer
> has which IP addresses, with MAC address info. Once you have that it's
> easy to also generate a dhcpd.conf from that info to assign static IP:s.
> 

FWIW dhcpd can use an LDAP backend. Not sure why anyone would need to 
generate anything ;-)

Kind regards,

Jeroen van Meeuwen
-kanarip



From mrtom at fedoraproject.org  Fri Nov 16 16:23:24 2007
From: mrtom at fedoraproject.org (Thomas Canniot)
Date: Fri, 16 Nov 2007 17:23:24 +0100
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <200711152056.46958.darth_linux@ameritech.net>
References: <200711152056.46958.darth_linux@ameritech.net>
Message-ID: <20071116172324.66edad6c@fedoraproject.org>

Le Thu, 15 Nov 2007 20:56:46 -0500,
eah <darth_linux at ameritech.net> a ?crit :

> Hi all, 
> 
> I have the BCM4318 wlan0. b43 driver picks it up after following
> instructions using  broadcom-wl-4.80.53.0.tar.bz2. It does not active
> the card's radio (my little blue light stays dark to say it like an
> end user) . dmesg reports "ADDRCONF(NETDEV_UP): wlan0: link is not
> ready"
> 
> What do I need to do to get that working? 
> 
> This is the farthest I've ever gotten using the stock driver, so
> kudos to all involved in that. 
> 
> 
> 
> thanks, 
> 
> Eric Hartwell 
> 

Not exactly the same problem here. HP NX 6125 laptop with bcm4318.
Using the same drivers and firmware and it works. Only the blue light
is not turned on anymore. Too bad, I loved this blue :)


Thomas 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/6e56ff18/attachment.sig>

From Michael_E_Brown at dell.com  Fri Nov 16 16:26:15 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Fri, 16 Nov 2007 10:26:15 -0600
Subject: Install hang on a Dell PowerEdge SC1430
In-Reply-To: <473DA005.4060406@RedHat.com>
References: <473DA005.4060406@RedHat.com>
Message-ID: <20071116162614.GA26528@humbolt.us.dell.com>

On Fri, Nov 16, 2007 at 08:49:57AM -0500, Steve Dickson wrote:
> Are there known issues with F8 (and F7) being
> installed on PowerEdges? Booting from DVD (and CDs)
> I get the following three lines than nothing...
> 
>     Loading Vmlinuz........
>     Loading initrd.img.....
>     Read.

Yes, there was a known issue with F7, but I *thought* we had gotten this
fixed for F8. There is a kernel cmdline workaround for it on F7, might
be the same problem for F8. Add "edd=skipmbr" to the boot options.
--
Michael

> 
> This happens with both x86 and x86_64 installs 
> from DVD of either F8 or F7. I also tried burning
> the boot.iso from the DVD to a CD and boot from
> that with the same results.
> 
> Being this is pretty broken, I'm hoping this is a known
> problem and there is some type of workaround.
> 
> tia,
> 
> steved.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From mrtom at fedoraproject.org  Fri Nov 16 16:27:43 2007
From: mrtom at fedoraproject.org (Thomas Canniot)
Date: Fri, 16 Nov 2007 17:27:43 +0100
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <20071116154828.GA11383@redhat.com>
References: <200711152056.46958.darth_linux@ameritech.net>
	<20071116154828.GA11383@redhat.com>
Message-ID: <20071116172743.0b6cc172@fedoraproject.org>

Le Fri, 16 Nov 2007 10:48:29 -0500,
"John W. Linville" <linville at redhat.com> a ?crit :

> On Thu, Nov 15, 2007 at 08:56:46PM -0500, eah wrote:
> 
> > I have the BCM4318 wlan0. b43 driver picks it up after following
> > instructions using  broadcom-wl-4.80.53.0.tar.bz2. It does not
> > active the card's radio (my little blue light stays dark to say it
> > like an end user) . dmesg reports "ADDRCONF(NETDEV_UP): wlan0: link
> > is not ready"
> 
> To answer your later question, this is the right firmware.  I am
> presuming that you extracted the firmware already.
>  
> > What do I need to do to get that working? 
> > 
> > This is the farthest I've ever gotten using the stock driver, so
> > kudos to all involved in that. 
> 
> Are these your only indications?  Did you actually try to activate
> the card using NetworkManager, wpa_supplicant, or iwconfig?
> 
> Regarding the "little blue light", did you try pushing the RF kill
> button?  Sometimes they are a software-controlled toggle rather than
> an actual physical switch.  (Note: don't bother with this without
> trying NetworkManger, et al. first...)
> 
> John

Actually, on my HP NX6125, the mute light is not lighted on as well
when the sound is muted.
Maybe all this buttons are linked.

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/9fdb0919/attachment.sig>

From myfedora at richip.dhs.org  Fri Nov 16 16:34:13 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 16 Nov 2007 09:34:13 -0700
Subject: Yum Arch Kernel Problem
Message-ID: <1195230853.27523.9.camel@localhost6.localdomain6>

Hi,

I have a GenuineIntel Processor (cpu family 6, model 11) with
kernel-2.6.23.1-42.i686 installed. Whenever I try to do anything with
the kernel (ie. install the latest kernel -49), yum insists on
installing the i586 version of the old kernel.

Now, I'm not an expert on CPU architectures, but I thought the Intel
Pentium(R) III was an i686. Am I wrong? If not, what could have caused
this and how do I fix it? yum bug?
--

Richi Plana



From jima at beer.tclug.org  Fri Nov 16 16:42:15 2007
From: jima at beer.tclug.org (Jima)
Date: Fri, 16 Nov 2007 10:42:15 -0600 (CST)
Subject: Yum Arch Kernel Problem
In-Reply-To: <1195230853.27523.9.camel@localhost6.localdomain6>
References: <1195230853.27523.9.camel@localhost6.localdomain6>
Message-ID: <Pine.LNX.4.64.0711161041170.4486@beer.tclug.org>

On Fri, 16 Nov 2007, Richi Plana wrote:
> Now, I'm not an expert on CPU architectures, but I thought the Intel
> Pentium(R) III was an i686. Am I wrong? If not, what could have caused
> this and how do I fix it? yum bug?

  It is i686.  (The Pentium Pro was the first i686 Intel processor, from 
memory.)  Odd.  What's /etc/rpm/platform say?

      Jima



From oliver at linux-kernel.at  Fri Nov 16 17:00:00 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Fri, 16 Nov 2007 18:00:00 +0100
Subject: rpms/tomcat5/F-7 tomcat5-5.5-acceptlangheader.patch, NONE, 1.1
 tomcat5-5.5-http11-build.patch, 1.3, 1.4 tomcat5-5.5-webdav.patch,
 NONE, 
 1.1 .cvsignore, 1.12,	1.13 sources, 1.10, 1.11 tomcat5.spec, 1.99, 1.100
In-Reply-To: <200711161643.lAGGh5Cw011062@cvs-int.fedora.redhat.com>
References: <200711161643.lAGGh5Cw011062@cvs-int.fedora.redhat.com>
Message-ID: <473DCC90.4030109@linux-kernel.at>

Devrim G?ND?Z (devrim) schrieb:
> Author: devrim
> 
> Update of /cvs/extras/rpms/tomcat5/F-7
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv11029

[ ... ]

So the problem with tomcat was in F7... I was looking at devel branch -
quite sure about tomcat5 being the same version in f9/f8 and f7.

[oliver at pils tomcat5]$ grep Version: *.spec; grep spec CVS/Entries
Version: 5.5.25
/tomcat5.spec/1.102/Fri Nov 16 09:13:52 2007/-ko/


I should have asked koji:

[oliver at pils tomcat5]$ koji latest-pkg f8-final tomcat5
Build                          Tag                   Built by
-----------------------------  --------------------  ----------------
tomcat5-5.5.23-9jpp.4.fc8      f8-final              vivekl
[oliver at pils tomcat5]$ koji latest-pkg dist-f9 tomcat5
Build                          Tag                   Built by
-----------------------------  --------------------  ----------------
tomcat5-5.5.25-1jpp.1.fc9      dist-f9               devrim


-of



From benny+usenet at amorsen.dk  Fri Nov 16 17:20:11 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Fri, 16 Nov 2007 18:20:11 +0100
Subject: F8 is getting *really* sysadmin-hostile
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<604aa7910711150850y4e65e50fxcb6e1f5b5ea409d6@mail.gmail.com>
	<20071115183244.GB60438@dspnet.fr.eu.org>
	<604aa7910711151052kba8864ek27628a9202a93b7a@mail.gmail.com>
Message-ID: <m3d4ua6ras.fsf@ursa.amorsen.dk>

>>>>> "JS" == Jeff Spaleta <jspaleta at gmail.com> writes:

JS> the point... network hygiene and accountability.. to make it
JS> harder for an unknown malicious person to connect an unknown
JS> computer into a live network wall jack somewhere in your building
JS> and become a member of that network segment with equal access to
JS> network data that registered computers have.

On that note, many switches can be configured to keep the port closed
for non-DHCP traffic until a DHCP lease is acquired. That solves the
"just assign a static IP"-attack. For the "just steal someone's
MAC-address"-attack, you need 802.1x. Does NetworkManager handle
802.1x on wired interfaces?


/Benny





From SteveD at redhat.com  Fri Nov 16 17:40:43 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Fri, 16 Nov 2007 12:40:43 -0500
Subject: Install hang on a Dell PowerEdge SC1430
In-Reply-To: <20071116162614.GA26528@humbolt.us.dell.com>
References: <473DA005.4060406@RedHat.com>
	<20071116162614.GA26528@humbolt.us.dell.com>
Message-ID: <473DD61B.4060906@RedHat.com>



Michael E Brown wrote:
> On Fri, Nov 16, 2007 at 08:49:57AM -0500, Steve Dickson wrote:
>> Are there known issues with F8 (and F7) being
>> installed on PowerEdges? Booting from DVD (and CDs)
>> I get the following three lines than nothing...
>>
>>     Loading Vmlinuz........
>>     Loading initrd.img.....
>>     Read.
> 
> Yes, there was a known issue with F7, but I *thought* we had gotten this
> fixed for F8. There is a kernel cmdline workaround for it on F7, might
> be the same problem for F8. Add "edd=skipmbr" to the boot options.
That didn't help... thanks though....

I've updated the BIOS so I'm running the latest. Is there anything
else I can added to the boot command that would give me a clue
as to what the problem is? I'm willing to spend some time on it
but three lines of output is a bit tough... :-\

steved.



From SteveD at redhat.com  Fri Nov 16 17:46:58 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Fri, 16 Nov 2007 12:46:58 -0500
Subject: Install hang on a Dell PowerEdge SC1430
In-Reply-To: <473DD61B.4060906@RedHat.com>
References: <473DA005.4060406@RedHat.com>	<20071116162614.GA26528@humbolt.us.dell.com>
	<473DD61B.4060906@RedHat.com>
Message-ID: <473DD792.50901@RedHat.com>



Steve Dickson wrote:
> 
> Michael E Brown wrote:
>> On Fri, Nov 16, 2007 at 08:49:57AM -0500, Steve Dickson wrote:
>>> Are there known issues with F8 (and F7) being
>>> installed on PowerEdges? Booting from DVD (and CDs)
>>> I get the following three lines than nothing...
>>>
>>>     Loading Vmlinuz........
>>>     Loading initrd.img.....
>>>     Read.
>> Yes, there was a known issue with F7, but I *thought* we had gotten this
>> fixed for F8. There is a kernel cmdline workaround for it on F7, might
>> be the same problem for F8. Add "edd=skipmbr" to the boot options.
> That didn't help... thanks though....
Nix this! You said 'edd' NOT 'ebb' grrr... if I could only type...

This indeed fixed this problem so the problem is still in F8.

thanks much!

steved.
 



From silfreed at silfreed.net  Fri Nov 16 17:50:55 2007
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Fri, 16 Nov 2007 12:50:55 -0500
Subject: Yum Arch Kernel Problem
In-Reply-To: <Pine.LNX.4.64.0711161041170.4486@beer.tclug.org>
References: <1195230853.27523.9.camel@localhost6.localdomain6>
	<Pine.LNX.4.64.0711161041170.4486@beer.tclug.org>
Message-ID: <200711161250.55509.silfreed@silfreed.net>

On Friday 16 November 2007, Jima wrote:
> > Now, I'm not an expert on CPU architectures, but I thought the Intel
> > Pentium(R) III was an i686. Am I wrong? If not, what could have caused
> > this and how do I fix it? yum bug?
>
> ? It is i686. ?(The Pentium Pro was the first i686 Intel processor, from
> memory.) ?Odd. ?What's /etc/rpm/platform say?

I had this problem as well, but I didn't report it because I thought it might 
have been a kmod interaction problem.

$ cat /etc/rpm/platform
athlon-redhat-linux

$ uname -a
Linux htpc.home.silfreed.net 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 
2007 i686 athlon i386 GNU/Linux

I worked around it by installing the kernel-2.6.23.1-49.fc8.i686 individually 
(through yum).  The correct kmods were pulled in and I haven't had the i586 
kernel pop up again yet.

-Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/2d7a9548/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Nov 16 18:34:59 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Nov 2007 19:34:59 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071116154149.GC422@nostromo.devel.redhat.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<20071116154149.GC422@nostromo.devel.redhat.com>
Message-ID: <1195238099.8238.9.camel@rousalka.dyndns.org>


Le vendredi 16 novembre 2007 ? 10:41 -0500, Bill Nottingham a ?crit :
> Matthias Clasen (mclasen at redhat.com) said: 
> > > Yes, but fixing every possible application which could ever be put in a
> > > scriplet to never, ever, ever fail, even in the cases when failure is
> > > acceptable (and shouldn't kill the transaction) is a little beyond the
> > > mandate of the FPC. ;)
> > 
> > If scriptlet are not allowed to ever, ever, fail, then just make rpm
> > ignore the exit code of scriptlets.
> 
> scriptlets should be allowed to fail when the failure is catastrophic
> enough. What that is, I'm not sure.

scriptlets should be allowed to fail when the benefits of failing
(fixing packages) outweigh the cost of failure (killing transactions for
lots of users). Since so far the only documented failure was in rawhide
(at a time I doubt rawhide was perfectly installable anyway) I question
the need to hide this particular failure.

If official policy was to never fail in scriplets, that should be fixed
at the rpm or yum level. FPC may not be in the business of mandating
code changes generally but refusing to touch our own packaging tools and
embarking instead on an exhausting crusade to catch manually every
single error output in our scriptlets is such an utter waste of packager
time I hope no one ever mandates it in an official way. Software is
there to help people not the other way around.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/d3dc918e/attachment.sig>

From notting at redhat.com  Fri Nov 16 18:36:42 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Nov 2007 13:36:42 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195238099.8238.9.camel@rousalka.dyndns.org>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<20071116154149.GC422@nostromo.devel.redhat.com>
	<1195238099.8238.9.camel@rousalka.dyndns.org>
Message-ID: <20071116183642.GA13435@nostromo.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > scriptlets should be allowed to fail when the failure is catastrophic
> > enough. What that is, I'm not sure.
> 
> scriptlets should be allowed to fail when the benefits of failing
> (fixing packages) outweigh the cost of failure (killing transactions for
> lots of users). Since so far the only documented failure was in rawhide
> (at a time I doubt rawhide was perfectly installable anyway) I question
> the need to hide this particular failure.

Not all scriptlets abort the transaction anyways, as I recall. %post
certainly doesn't. So, maybe it should just be %pre shouldn't fail.

Bill




From bnocera at redhat.com  Fri Nov 16 18:47:56 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 18:47:56 +0000
Subject: FLAC 1.2.x may need rebuilds
In-Reply-To: <20071116155244.d64400c8.mschwendt.tmp0701.nospam@arcor.de>
References: <20071116155244.d64400c8.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1195238876.10878.43.camel@cookie.hadess.net>


On Fri, 2007-11-16 at 15:52 +0100, Michael Schwendt wrote:
> The Fedora 8 upgrade from FLAC 1.1.4 to 1.2.0 has broken FLAC file import
> in Audacity. A simple rebuild of Audacity fixes it.
> 
> All packagers with a dependency on libFLAC* are advised to check whether
> they also need to rebuild their packages.

I blame FLAC and their non-existent checks. They probably broke ABI
without upping the soname.

FYI, a number of people mentioned that FLAC was working fine for them
with the security errata installed, so I'd rather not force anyone to do
recompiles for the sake of it.

If specific packages need recompiling, I'm willing to do them, but I'd
rather not have to touch working packages.



From email.ahmedkamal at googlemail.com  Fri Nov 16 18:52:56 2007
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Fri, 16 Nov 2007 20:52:56 +0200
Subject: pulseaudio CPU usage and process name
Message-ID: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>

Hi,
I'm enjoying the wonders of pulse audio. However, on my centrino
2.0Ghzlaptop, when idle, almost always pulse audio is the most CPU
intensive task
running, even when I am not playing any audio! It consumes around 6% of CPU
competing with firefox! This seems a bit too much to me ?
Also, any idea why the process name appears in top as "exe" rather than
pulseaudio!
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/979540a4/attachment.htm>

From fedora at leemhuis.info  Fri Nov 16 18:54:23 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 16 Nov 2007 19:54:23 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195225438.3238.40.camel@localhost.localdomain>
References: <fheo3b$8nv$1@ger.gmane.org>	<473AEBB8.6050602@ioa.s.u-tokyo.ac.jp>	<473B3418.9020207@leemhuis.info>	<473B3FA8.70106@hhs.nl>
	<473B7424.3060407@leemhuis.info>	<1195116253.28534.147.camel@mccallum.corsepiu.local>	<473C8589.2010109@leemhuis.info>
	<473D8905.40702@leemhuis.info>	<473D8A66.5090207@leemhuis.info>
	<1195225438.3238.40.camel@localhost.localdomain>
Message-ID: <473DE75F.1020409@leemhuis.info>

On 16.11.2007 16:03, Tom "spot" Callaway wrote:
> On Fri, 2007-11-16 at 13:17 +0100, Thorsten Leemhuis wrote:
> 
>> But that just change my comment much -- I still think if someone is
>> interested in fixing/improving something in Fedora-land it should be
>> much easier than it is now. Then people would again do something on
>> their own instead of relying and waiting for committees to do that work.
> My intent 

Reminder: Please note that I'm talking about Fedora in general -- I (and
it seems others as well) got the impression that people lost interest in
participating in FESCo or FPC and the example I gave was just a example
that coincidentally was in the FPC space.

> in shaping the Packaging Guidelines the way that they are is
> not to make life difficult for contributors, but rather, to ensure
> consistency.

I know your intentions are good and the packaging guidelines improved a
lot thanks to your and the FPCs work. Thanks for that Spot.

But nevertheless: I think it's to hard for contributers that want to see
something changed in the packaging guidelines to (help) realizing those
changes. Contributing to FESCo, FPC or other Committees needs to get
easier again, then I'm optimistic that people will contribute more
again, like they did a year ago.

> Often, the FPC members disagree on the correct guidelines to implement.
> If we were to open the Guidelines and make them editable to all, we
> would see wiki wars on contentious issues, people adding their own rules
> and corner cases, and possibly contradicting guidelines.

I suspect people that started and work on wikipedia heard and hear
similar stuff each day -- nevertheless wikipedia works.

IOW: yes, now and then there will be wiki wars. We have to live with
that and exactly for such issues we need committees for that work out a
compromise.

But the ACLs also prevent lots of improvements, and that's why I think
they are bad.

Example: take a look at the old Fedora Package Maintainers Policies
policies at http://fedoraproject.org/wiki/PackageMaintainers/Policy
They are not secured by ACLs and it works fine. Nobody touched them
normally -- and if he is being careful. Like for example AlexLancaster,
who in the past days did some small improvements to some of the pages;
for example:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages?action=info

> The FPC has a documented process (which is almost never followed) on how
> to make a change to anything under Packaging/ (or to propose new
> Guidelines):

Yeah, but I got the impression that something like this it's a to high
hurdle already.

> [...] 
> Thorsten, this is certainly not intended as a criticism for you, as I
> continue to have great admiration for the work that you do in the Fedora
> community, but rather, a call to action for specific improvements that
> we can make to streamline the bureaucracy. :)

I have no solutions, just some ideas; I gave some of them already, but
the main one is likely the motto EPEL has these days: "Power to the
people with no delay." aka "make Steering Committees (and beeing in
them) a lot less unimportant".

Something similar would IMHO be nice for other areas of Fedora as well.
Which would mean remove the hurdles (like ACLs in the Packging/ area)
and let people simply do stuff -- in the open of course, so everyone
knows what happens. Only if some task or decision is controversial and
no agreement can be found on the list or on IRC activate a flexible
committee that has to make sure a agreement is found. Flexible like:
don't let a elected group decide that might not have that much of an
interest in a topic; instead let those decide that drove the thing that
discssed, those that participated in discussing it *and* 5 - 13 people
that were most active in this work area in the past months.

Cu
knurd



From pmatilai at laiskiainen.org  Fri Nov 16 18:57:38 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 16 Nov 2007 20:57:38 +0200 (EET)
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071116154149.GC422@nostromo.devel.redhat.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<20071116154149.GC422@nostromo.devel.redhat.com>
Message-ID: <alpine.DEB.0.9999.0711162025440.22634@gotcha.dreamhost.com>

On Fri, 16 Nov 2007, Bill Nottingham wrote:

> Matthias Clasen (mclasen at redhat.com) said:
>>> Yes, but fixing every possible application which could ever be put in a
>>> scriplet to never, ever, ever fail, even in the cases when failure is
>>> acceptable (and shouldn't kill the transaction) is a little beyond the
>>> mandate of the FPC. ;)
>>
>> If scriptlet are not allowed to ever, ever, fail, then just make rpm
>> ignore the exit code of scriptlets.
>
> scriptlets should be allowed to fail when the failure is catastrophic
> enough. What that is, I'm not sure.

Agreed on principle but... The rpm transaction is not unlike a derailed 
train - a few red lights from failing scriptlets ain't going to stop it 
from wrecking everything that happens to be on its way until it simply 
runs out of speed. So the problem is: what exactly is a scriptlet 
intentionally failing going to do? It wont stop the transaction anyway...

For the vast majority of cases it'd be far far more useful just to 
ignore the status but log the failures to permanent storage (and notify 
user at end of transaction). Leaving duplicates behind on upgrades like it 
now does is hardly useful behavior to anybody.

Then of course there are packages (typically commercial) that attempt to 
prevent installation by non-zero exit from %pre if some conditions aren't 
met, but that's totally broken to begin with because it wont prevent the 
rest of the transaction from running...

 	- Panu -



From fedora at leemhuis.info  Fri Nov 16 19:07:11 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 16 Nov 2007 20:07:11 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195227371.3238.47.camel@localhost.localdomain>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>	<1195222693.3238.11.camel@localhost.localdomain>	<1195226289.3002.4.camel@localhost.localdomain>	<1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
Message-ID: <473DEA5F.30201@leemhuis.info>

On 16.11.2007 16:36, Tom "spot" Callaway wrote:
> On Fri, 2007-11-16 at 10:33 -0500, Matthias Clasen wrote:
>> On Fri, 2007-11-16 at 10:24 -0500, Tom "spot" Callaway wrote:
>>> On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
>>>
>>>> Of course, the correct way to have scriptlets that don't fail is to
>>>> write them in a way that doesn't fails, not the swipe the failure under
>>>> the carpet...
>>> Yes, but fixing every possible application which could ever be put in a
>>> scriplet to never, ever, ever fail, even in the cases when failure is
>>> acceptable (and shouldn't kill the transaction) is a little beyond the
>>> mandate of the FPC. ;)
>> If scriptlet are not allowed to ever, ever, fail, then just make rpm
>> ignore the exit code of scriptlets.
> Again, code changes are outside of the FPC mandate. Feel like patching
> rpm? :)

BTW, this touches another problem where Fedora needs to improve: we have
no group that realizes adjustments done to the packaging guidelines in
the packages. Take *for example* the scriptlet change in
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev2=14&rev1=13

Is just a corner case, but a good example.

With grep, sed, cvs diff and some small adjustments by hand this change
could also be done quickly in CVS for all effected packages. I could
start now and will likely finished the task for all packages in devel
within less then 30 minutes. But nobody does that, as modifying packages
that are owned by other people is frowned upon in Fedora land.

Such changes therefor often take years to get realized in practice. Is
that what we want?

CU
knurd



From myfedora at richip.dhs.org  Fri Nov 16 19:09:31 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 16 Nov 2007 12:09:31 -0700
Subject: Yum Arch Kernel Problem
In-Reply-To: <Pine.LNX.4.64.0711161041170.4486@beer.tclug.org>
References: <1195230853.27523.9.camel@localhost6.localdomain6>
	<Pine.LNX.4.64.0711161041170.4486@beer.tclug.org>
Message-ID: <1195240171.30209.0.camel@localhost6.localdomain6>

On Fri, 2007-11-16 at 10:42 -0600, Jima wrote:
> On Fri, 16 Nov 2007, Richi Plana wrote:
> > Now, I'm not an expert on CPU architectures, but I thought the Intel
> > Pentium(R) III was an i686. Am I wrong? If not, what could have caused
> > this and how do I fix it? yum bug?
> 
>   It is i686.  (The Pentium Pro was the first i686 Intel processor, from 
> memory.)  Odd.  What's /etc/rpm/platform say?

That's what I thought. Anyway,

/etc/rpm/platform: 
i686-redhat-linux
--

Richi Plana



From bnocera at redhat.com  Fri Nov 16 19:13:25 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 16 Nov 2007 19:13:25 +0000
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <1195223941.3238.20.camel@localhost.localdomain>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
	<1195223941.3238.20.camel@localhost.localdomain>
Message-ID: <1195240405.10878.51.camel@cookie.hadess.net>


On Fri, 2007-11-16 at 09:39 -0500, Tom "spot" Callaway wrote:
<snip>
> Seriously, how optimized does the mp3 codec need to be? I used to play
> mp3s on a Windows 3.1 box with 128 MB of memory. RPM Fusion is full of
> players using gcc, and I've yet to run into a place where I needed to
> optimize beyond -O2 with gcc.

99% of those players use the same backend library (libmad), and even
though they're compiled with low optimisations, most of libmad has
MMX/SSE/Altivec/etc. optimisations. That's optimisations.

And we're certainly not talking only about MP3. Try playing back an HD
Windows Media Video stream with a C-only decoder...



From skvidal at fedoraproject.org  Fri Nov 16 19:16:47 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 16 Nov 2007 14:16:47 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <alpine.DEB.0.9999.0711162025440.22634@gotcha.dreamhost.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<20071116154149.GC422@nostromo.devel.redhat.com>
	<alpine.DEB.0.9999.0711162025440.22634@gotcha.dreamhost.com>
Message-ID: <1195240607.24228.37.camel@cutter>


On Fri, 2007-11-16 at 20:57 +0200, Panu Matilainen wrote:
> On Fri, 16 Nov 2007, Bill Nottingham wrote:
> 
> > Matthias Clasen (mclasen at redhat.com) said:
> >>> Yes, but fixing every possible application which could ever be put in a
> >>> scriplet to never, ever, ever fail, even in the cases when failure is
> >>> acceptable (and shouldn't kill the transaction) is a little beyond the
> >>> mandate of the FPC. ;)
> >>
> >> If scriptlet are not allowed to ever, ever, fail, then just make rpm
> >> ignore the exit code of scriptlets.
> >
> > scriptlets should be allowed to fail when the failure is catastrophic
> > enough. What that is, I'm not sure.
> 
> Agreed on principle but... The rpm transaction is not unlike a derailed 
> train - a few red lights from failing scriptlets ain't going to stop it 
> from wrecking everything that happens to be on its way until it simply 
> runs out of speed. So the problem is: what exactly is a scriptlet 
> intentionally failing going to do? It wont stop the transaction anyway...
> 
> For the vast majority of cases it'd be far far more useful just to 
> ignore the status but log the failures to permanent storage (and notify 
> user at end of transaction). Leaving duplicates behind on upgrades like it 
> now does is hardly useful behavior to anybody.
> 

+1

It confuses people and makes them come and ask me questions.

-sv




From mzerqung at 0pointer.de  Fri Nov 16 19:21:48 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 16 Nov 2007 20:21:48 +0100
Subject: pulseaudio CPU usage and process name
In-Reply-To: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
References: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
Message-ID: <20071116192148.GA17455@tango.0pointer.de>

On Fri, 16.11.07 20:52, Ahmed Kamal (email.ahmedkamal at googlemail.com) wrote:

Hi!

> Hi, I'm enjoying the wonders of pulse audio. However, on my centrino
> 2.0Ghzlaptop, when idle, almost always pulse audio is the most CPU
> intensive task running, even when I am not playing any audio! It
> consumes around 6% of CPU competing with firefox! This seems a bit
> too much to me ?  Also, any idea why the process name appears in top
> as "exe" rather than pulseaudio!  Regards

The process name issue has been fixed already, but I haven't uploaded
a new version of PA into Rawhide yet. Also note that this issue is
alrady listed in rhbz as #345761.

PA closes all devices when idle for more than 1s. Then, CPU
consumption goes to 0%.

Now, there is a certain piece of software which happens to be
horrendously broken and is called "Macromedia Flash". I would guess
that you are using it, aren't you? Now, Flash never closes any
playback streams until you terminate your browser. Due to that PA
never considers the device idle and thus never closes the audio device
and continues to write audio data to it.

Due the closed source nature of Flash this issue is only fixable with
exceptionally ugly hacks in PA or libflashsupport.so, which I am not
willing to do.

If PA consumes 6% CPU this is probably because resampling is needed to
output audio on your device. Resampling is usually the only CPU
intensive code that is run in PA. While traditionally resampling is
done in the various media players if you use PA it is done in
PA. Hence the CPU load will appear as if it was PA's fault, but we
just moved the resampling work from the app to PA, that's all.

Please terminate your browser, and pause/stop all media players and check
the CPU load then.

(Some codepaths in PA are not optimized as much as they could of
course, but from the little information you posted I guessed what I
wrote above. If you feel that my guess is not correct, then please
open a bug in rhbz)

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From pmatilai at laiskiainen.org  Fri Nov 16 19:24:19 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 16 Nov 2007 21:24:19 +0200 (EET)
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071116183642.GA13435@nostromo.devel.redhat.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<20071116154149.GC422@nostromo.devel.redhat.com>
	<1195238099.8238.9.camel@rousalka.dyndns.org>
	<20071116183642.GA13435@nostromo.devel.redhat.com>
Message-ID: <alpine.DEB.0.9999.0711162121390.22634@gotcha.dreamhost.com>

On Fri, 16 Nov 2007, Bill Nottingham wrote:

> Nicolas Mailhot (nicolas.mailhot at laposte.net) said:
>>> scriptlets should be allowed to fail when the failure is catastrophic
>>> enough. What that is, I'm not sure.
>>
>> scriptlets should be allowed to fail when the benefits of failing
>> (fixing packages) outweigh the cost of failure (killing transactions for
>> lots of users). Since so far the only documented failure was in rawhide
>> (at a time I doubt rawhide was perfectly installable anyway) I question
>> the need to hide this particular failure.
>
> Not all scriptlets abort the transaction anyways, as I recall. %post
> certainly doesn't. So, maybe it should just be %pre shouldn't fail.

No scriptlet will abort the transaction, just the package with failing 
scriptlet will have its install/upgrade/remove will be aborted.

"We brake for nobody" ;)

 	- Panu -



From ville.skytta at iki.fi  Fri Nov 16 19:34:03 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 16 Nov 2007 21:34:03 +0200
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473CAB30.9000201@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<200711152214.12421.ville.skytta@iki.fi>
	<473CAB30.9000201@gmail.com>
Message-ID: <200711162134.03571.ville.skytta@iki.fi>

On Thursday 15 November 2007, Les Mikesell wrote:
> Ville Skytt? wrote:
> > It's not only the IP.  There are DNS servers, gateways, WINS servers, NTP
> > servers and whatnot that can be conveniently managed in one place on the
> > DHCP server.
>
> And routes, which DHCP can't handle, other than the default.

I'm not sure if I parse the above sentence correctly, but isn't that what the 
static-routes DHCP option is for (man dhcp-options)?  I don't use it 
currently, but IIRC I did in the past.



From email.ahmedkamal at googlemail.com  Fri Nov 16 19:57:16 2007
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Fri, 16 Nov 2007 21:57:16 +0200
Subject: pulseaudio CPU usage and process name
In-Reply-To: <20071116192148.GA17455@tango.0pointer.de>
References: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
	<20071116192148.GA17455@tango.0pointer.de>
Message-ID: <3da3b5b40711161157m62cb3fbfwb8910db0567668c8@mail.gmail.com>

Hi,
Thanks for the reply. I can confirm terminating firefox brought CPU usage of
pulseaudio down to 0% in top. Also, playing an mp3 through amarok, brought
CPU usage back to 6%. So it seems any playback brings the CPU usage up by
that much!
My sound card is Intel ICH6 chipset ALC861. Is resampling required ? Is it
possible to play at the card's native sample rate to gain back the CPU
cycles, since I almost always have the browser open with Flash in it :/

Regards

On Nov 16, 2007 9:21 PM, Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Fri, 16.11.07 20:52, Ahmed Kamal (email.ahmedkamal at googlemail.com)
> wrote:
>
> Hi!
>
> > Hi, I'm enjoying the wonders of pulse audio. However, on my centrino
> > 2.0Ghzlaptop, when idle, almost always pulse audio is the most CPU
> > intensive task running, even when I am not playing any audio! It
> > consumes around 6% of CPU competing with firefox! This seems a bit
> > too much to me ?  Also, any idea why the process name appears in top
> > as "exe" rather than pulseaudio!  Regards
>
> The process name issue has been fixed already, but I haven't uploaded
> a new version of PA into Rawhide yet. Also note that this issue is
> alrady listed in rhbz as #345761.
>
> PA closes all devices when idle for more than 1s. Then, CPU
> consumption goes to 0%.
>
> Now, there is a certain piece of software which happens to be
> horrendously broken and is called "Macromedia Flash". I would guess
> that you are using it, aren't you? Now, Flash never closes any
> playback streams until you terminate your browser. Due to that PA
> never considers the device idle and thus never closes the audio device
> and continues to write audio data to it.
>
> Due the closed source nature of Flash this issue is only fixable with
> exceptionally ugly hacks in PA or libflashsupport.so, which I am not
> willing to do.
>
> If PA consumes 6% CPU this is probably because resampling is needed to
> output audio on your device. Resampling is usually the only CPU
> intensive code that is run in PA. While traditionally resampling is
> done in the various media players if you use PA it is done in
> PA. Hence the CPU load will appear as if it was PA's fault, but we
> just moved the resampling work from the app to PA, that's all.
>
> Please terminate your browser, and pause/stop all media players and check
> the CPU load then.
>
> (Some codepaths in PA are not optimized as much as they could of
> course, but from the little information you posted I guessed what I
> wrote above. If you feel that my guess is not correct, then please
> open a bug in rhbz)
>
> Thanks,
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/bfa8b9fd/attachment.htm>

From myfedora at richip.dhs.org  Fri Nov 16 19:57:17 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 16 Nov 2007 12:57:17 -0700
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071116093749.387f3782@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<20071115162214.35cd3807@redhat.com>
	<1195176057.10878.18.camel@cookie.hadess.net>
	<20071115235445.4e2f6b51@redhat.com>
	<1195217278.10878.32.camel@cookie.hadess.net>
	<20071116093749.387f3782@redhat.com>
Message-ID: <1195243037.30209.6.camel@localhost6.localdomain6>

On Fri, 2007-11-16 at 09:37 -0500, Jesse Keating wrote:
> On Fri, 16 Nov 2007 12:47:58 +0000
> Bastien Nocera <bnocera at redhat.com> wrote:
> 
> > > Ok, fine, s/compiler/library/.  Are you really going to tell me that
> > > it's impossible to build the mp3 library (and others) without using
> > > closed source software?  
> > 
> > It is extremely incovenient, as you need to reimplement, and
> > reoptimise large portions of code.
> 
> Yeah, this makes me like our involvement with Fluendo even more...

Come on, people. Fluendo have constraints just like Fedora and Red Hat
have theirs. How about we concentrate on what we can do to make things
work instead of what we can't? Above all, let's not take things
personally (even though for some, it's their personal time and not their
professional time that they're contributing here).

Fluendo: any timeframe on a fix?
--

Richi Plana



From lesmikesell at gmail.com  Fri Nov 16 20:01:57 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 16 Nov 2007 14:01:57 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <200711162134.03571.ville.skytta@iki.fi>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<200711152214.12421.ville.skytta@iki.fi>	<473CAB30.9000201@gmail.com>
	<200711162134.03571.ville.skytta@iki.fi>
Message-ID: <473DF735.4080100@gmail.com>

Ville Skytt? wrote:
> On Thursday 15 November 2007, Les Mikesell wrote:
>> Ville Skytt? wrote:
>>> It's not only the IP.  There are DNS servers, gateways, WINS servers, NTP
>>> servers and whatnot that can be conveniently managed in one place on the
>>> DHCP server.
>> And routes, which DHCP can't handle, other than the default.
> 
> I'm not sure if I parse the above sentence correctly, but isn't that what the 
> static-routes DHCP option is for (man dhcp-options)?  I don't use it 
> currently, but IIRC I did in the past.

And in man dhcp-options you find:
  "...this option is virtually useless, and is not implemented by any
   of the popular DHCP clients, for example the Microsoft DHCP client."

-- 
    Les Mikesell
     lesmikesell at gmail.com



From jspaleta at gmail.com  Fri Nov 16 20:12:51 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 16 Nov 2007 11:12:51 -0900
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071116101054.5de68ce9@redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com> <473DAF85.9000305@redhat.com>
	<20071116101054.5de68ce9@redhat.com>
Message-ID: <604aa7910711161212y3faa26caic515fd6d03da6ce6@mail.gmail.com>

On Nov 16, 2007 6:10 AM, Jesse Keating <jkeating at redhat.com> wrote:
> Somebody needs to own this issue, and either drive the SELinux change
> to allow these codecs to work, or remove fluendo from the codeina set
> (leaving nothing...),

Do we have the option of leaving nothing with an explanation that once
there is a fix the fluendo offerings will be re-enabled?

-jef



From nicolas.mailhot at laposte.net  Fri Nov 16 20:12:57 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Nov 2007 21:12:57 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <473DF735.4080100@gmail.com>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<200711152214.12421.ville.skytta@iki.fi>	<473CAB30.9000201@gmail.com>
	<200711162134.03571.ville.skytta@iki.fi> <473DF735.4080100@gmail.com>
Message-ID: <1195243977.12707.2.camel@rousalka.dyndns.org>


Le vendredi 16 novembre 2007 ? 14:01 -0600, Les Mikesell a ?crit :

> And in man dhcp-options you find:
>   "...this option is virtually useless, and is not implemented by any
>    of the popular DHCP clients, for example the Microsoft DHCP client."

/me wonders how the Microsoft DHCP client is going to help you set up a
Linux system in any case.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/8826158f/attachment.sig>

From notting at redhat.com  Fri Nov 16 20:19:47 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Nov 2007 15:19:47 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <604aa7910711161212y3faa26caic515fd6d03da6ce6@mail.gmail.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com> <473DAF85.9000305@redhat.com>
	<20071116101054.5de68ce9@redhat.com>
	<604aa7910711161212y3faa26caic515fd6d03da6ce6@mail.gmail.com>
Message-ID: <20071116201947.GB19614@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> > Somebody needs to own this issue, and either drive the SELinux change
> > to allow these codecs to work, or remove fluendo from the codeina set
> > (leaving nothing...),
> 
> Do we have the option of leaving nothing with an explanation that once
> there is a fix the fluendo offerings will be re-enabled?

Not really. Again, I don't see the issue here, it's no more broken
than sshd was in F8 gold, or X or gdm is in rawhide.

Bill



From lightsolphoenix at gmail.com  Fri Nov 16 20:23:06 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Fri, 16 Nov 2007 15:23:06 -0500
Subject: Package for Qt-Jambi?
In-Reply-To: <20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>
References: <473A82FB.9030408@gmail.com>	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>	<473D433C.7040502@gmail.com>
	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <473DFC2A.2070609@gmail.com>

Michael Schwendt wrote:
> Unbuildable? In %build, you could set up your own local QTDIR and link
> from it to the original $QTDIR/$QTLIB locations.
>   
Actually, I did before I even tried to build it.  The problem which 
comes up here is not that I can override QTDIR, but that Fedora (and 
AFAIK, every other Linux distro) doesn't keep the Qt headers in 
$QTDIR/include .  This only makes sense, as headers are supposed to go 
into /usr/include or /include, depending on importance.  However, the 
build process looks for headers in $QTDIR/include at some point, and 
despite extensive searching, I can't seem to locate exactly where.  As a 
result, the only other option is to create a symbolic link from 
/usr/include to $QTDIR/include, but that requires root access to run the 
rpmbuild, and uh, I'm not so sure that's a fantastic idea...



From jkeating at redhat.com  Fri Nov 16 20:27:22 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Nov 2007 15:27:22 -0500
Subject: are you (fedora devels) using fluendo codecs?
In-Reply-To: <20071116201947.GB19614@nostromo.devel.redhat.com>
References: <64b14b300711151250j627c922ci88cb47008f98eabd@mail.gmail.com>
	<fhibor$h18$1@ger.gmane.org>
	<1195161122.18227.3.camel@localhost6.localdomain6>
	<64b14b300711160401j4cfcf79esbbf2d4db26ad6250@mail.gmail.com>
	<64b14b300711160416h1bb719efkb6f8d3bd8455fe8@mail.gmail.com>
	<20071116072612.67f129b0@redhat.com> <473DAF85.9000305@redhat.com>
	<20071116101054.5de68ce9@redhat.com>
	<604aa7910711161212y3faa26caic515fd6d03da6ce6@mail.gmail.com>
	<20071116201947.GB19614@nostromo.devel.redhat.com>
Message-ID: <20071116152722.35e3f300@redhat.com>

On Fri, 16 Nov 2007 15:19:47 -0500
Bill Nottingham <notting at redhat.com> wrote:

> Not really. Again, I don't see the issue here, it's no more broken
> than sshd was in F8 gold

sshd is only "broken" if A) you install from live image, and B) you do
a 'service sshd start' vs calling it from init.d or letting it start at
boot IIRC.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/dd26197b/attachment.sig>

From lesmikesell at gmail.com  Fri Nov 16 20:35:24 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Fri, 16 Nov 2007 14:35:24 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195243977.12707.2.camel@rousalka.dyndns.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<200711152214.12421.ville.skytta@iki.fi>	<473CAB30.9000201@gmail.com>	<200711162134.03571.ville.skytta@iki.fi>
	<473DF735.4080100@gmail.com>
	<1195243977.12707.2.camel@rousalka.dyndns.org>
Message-ID: <473DFF0C.3030203@gmail.com>

Nicolas Mailhot wrote:
> Le vendredi 16 novembre 2007 ? 14:01 -0600, Les Mikesell a ?crit :
> 
>> And in man dhcp-options you find:
>>   "...this option is virtually useless, and is not implemented by any
>>    of the popular DHCP clients, for example the Microsoft DHCP client."
> 
> /me wonders how the Microsoft DHCP client is going to help you set up a
> Linux system in any case.

DHCP is a protocol, not something OS related.  If clients don't observe 
it, serving it doesn't make much sense.  And there's a reason they don't 
- the option does not permit a subnet mask.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From limb at jcomserv.net  Fri Nov 16 20:39:48 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 16 Nov 2007 14:39:48 -0600 (CST)
Subject: Need an owner (and upstream?) for system-config-bind
In-Reply-To: <20071115123450.00bd5742@redhat.com>
References: <20071115123450.00bd5742@redhat.com>
Message-ID: <21666.63.85.68.164.1195245588.squirrel@mail.jcomserv.net>


> system-config-bind is assigned to me right now, and I'm certainly not
> going to do anything with it.  This needs not only a maintainer to own
> it, but I think it also needs an upstream developer.
>
> Any takers?

I'd be willing to take a look.  What would be involved?  Is there a
maintenance wishlist for it currently?

> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
novus ordo absurdum



From j.w.r.degoede at hhs.nl  Fri Nov 16 21:01:09 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 16 Nov 2007 22:01:09 +0100
Subject: Font issues (mkfontdir & friends not getting run) with F-8
Message-ID: <473E0515.4070706@hhs.nl>

Hi,

On both my F-8 x86_64 live-dvd installation and my (clean) F-8 i386 install dvd 
installation, not all scriptlets for font-packages have properly run.

Taking /etc/X11/fontpath.d/fonts-default (urw-fonts) as example:
-On the x86_64 live dvd install, only fonts.scale is present, iow
  mkfontdir and fc-cache have not been run, even though they are in the
  scripts:
[hans at localhost ~]$ rpm -q --scripts urw-fonts
urw-fonts-2.4-1.fc8.noarch
postinstall scriptlet (using /bin/sh):
{
    umask 133
    mkfontscale /usr/share/fonts/default/Type1 || :
    `which mkfontdir` /usr/share/fonts/default/Type1 || :
    fc-cache /usr/share/fonts
} &> /dev/null || :

-On the i386 dvd install, nothing was run, so not only mkfontdir and
  fc-cache were not run, but also mkfontscale has not been run

The strange thing is fontconfig is actually required, so atleast the fc-cache 
file should have been created.

As for the other two not being created, well that is to be expected if the 
necessary packages are not added to any Requires.

Why are these files generated on install anyways, I understand this used to be 
usefull back in the days when multiple packages would install files under one 
dir, but isn't it so that most font dirs now only contain fonts from one package?

Note that this is not isolated to urw-fonts, ghostscript-fonts for example has 
the same problem.

Regards,

Hans



From galibert at pobox.com  Fri Nov 16 21:06:56 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Fri, 16 Nov 2007 22:06:56 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195213560.10878.31.camel@cookie.hadess.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
	<1195176465.10878.23.camel@cookie.hadess.net>
	<473D025B.7070103@BitWagon.com>
	<1195213560.10878.31.camel@cookie.hadess.net>
Message-ID: <20071116210656.GA56533@dspnet.fr.eu.org>

On Fri, Nov 16, 2007 at 11:46:00AM +0000, Bastien Nocera wrote:
> You don't need a DVD drive to do an install, and using a Desktop LiveCD
> to do server installs and then blaming it being inappropriate for
> servers shows a lack of realism and/or imagination.

Two points:
- static ip does not mean server
- Fedora-8-Live-x86_64.iso does not say "Desktop" in any shape or form

  OG.



From pemboa at gmail.com  Fri Nov 16 21:12:55 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Fri, 16 Nov 2007 15:12:55 -0600
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071116210656.GA56533@dspnet.fr.eu.org>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<473C8671.8040200@BitWagon.com>
	<1195176465.10878.23.camel@cookie.hadess.net>
	<473D025B.7070103@BitWagon.com>
	<1195213560.10878.31.camel@cookie.hadess.net>
	<20071116210656.GA56533@dspnet.fr.eu.org>
Message-ID: <16de708d0711161312m621fdea3sd7b0a4f87deefb4a@mail.gmail.com>

On Nov 16, 2007 3:06 PM, Olivier Galibert <galibert at pobox.com> wrote:
> On Fri, Nov 16, 2007 at 11:46:00AM +0000, Bastien Nocera wrote:
> > You don't need a DVD drive to do an install, and using a Desktop LiveCD
> > to do server installs and then blaming it being inappropriate for
> > servers shows a lack of realism and/or imagination.
>
> Two points:
> - static ip does not mean server
> - Fedora-8-Live-x86_64.iso does not say "Desktop" in any shape or form

It doesn't say Gnome either... not sure how much credence you want to
give the file names.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From walters at redhat.com  Fri Nov 16 21:15:27 2007
From: walters at redhat.com (Colin Walters)
Date: Fri, 16 Nov 2007 16:15:27 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <473DEA5F.30201@leemhuis.info>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
Message-ID: <1195247727.29478.6.camel@space-ghost.verbum.private>


On Fri, 2007-11-16 at 20:07 +0100, Thorsten Leemhuis wrote:

> With grep, sed, cvs diff and some small adjustments by hand this change
> could also be done quickly in CVS for all effected packages. I could
> start now and will likely finished the task for all packages in devel
> within less then 30 minutes. But nobody does that, as modifying packages
> that are owned by other people is frowned upon in Fedora land.
> 
> Such changes therefor often take years to get realized in practice. Is
> that what we want?

No; automating these kinds of things is exactly where Fedora should be
going.  

I think we very much want a model based on peer review, collective
ownership and automation, not personal fiefdoms and manual integer
increments in text files.

IMO, if you have the script, post it, get some feedback, then just do
it.





From mzerqung at 0pointer.de  Fri Nov 16 21:22:43 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Fri, 16 Nov 2007 22:22:43 +0100
Subject: pulseaudio CPU usage and process name
In-Reply-To: <3da3b5b40711161157m62cb3fbfwb8910db0567668c8@mail.gmail.com>
References: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
	<20071116192148.GA17455@tango.0pointer.de>
	<3da3b5b40711161157m62cb3fbfwb8910db0567668c8@mail.gmail.com>
Message-ID: <20071116212243.GA27498@tango.0pointer.de>

On Fri, 16.11.07 21:57, Ahmed Kamal (email.ahmedkamal at googlemail.com) wrote:

> Hi,
> Thanks for the reply. I can confirm terminating firefox brought CPU usage of
> pulseaudio down to 0% in top. Also, playing an mp3 through amarok, brought
> CPU usage back to 6%. So it seems any playback brings the CPU usage up by
> that much!
> My sound card is Intel ICH6 chipset ALC861. Is resampling required ? Is it
> possible to play at the card's native sample rate to gain back the CPU
> cycles, since I almost always have the browser open with Flash in it :/

Flash is fixed to 44100 Hz. Apparently your card is fixed to 48000
Hz (you can check by running "pacmd" and typing "list-sinks"). So, in
effect resampling is *required* to take place. There's no way around
it. 

I wouldn't really think about this much. Don't forget, if PA wouldn't
do the resampling the player (or libasound) would need to do it. So
it's just a shuffling of which process does which job that make PA eat
6% CPU.

If you feel that the resampling takes to much CPU, than you're welcome
to sit down and add some real MMX/SSE support to the speex resampler,
which is the one we're using. ;-)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From walters at redhat.com  Fri Nov 16 21:27:50 2007
From: walters at redhat.com (Colin Walters)
Date: Fri, 16 Nov 2007 16:27:50 -0500
Subject: LDAP and the dbus user
In-Reply-To: <1195224756.618.36.camel@home.alexander.bostrom.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<20071115191131.GC60438@dspnet.fr.eu.org>
	<20071115143152.4170c48f@redhat.com> <473CA371.1060808@gmail.com>
	<604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>
	<473D5211.2040906@gmail.com> <20071116130955.159f9c1b@dhcp03.addix.net>
	<1195224756.618.36.camel@home.alexander.bostrom.net>
Message-ID: <1195248470.29478.10.camel@space-ghost.verbum.private>


On Fri, 2007-11-16 at 15:52 +0100, Alexander Bostr?m wrote:
> fre 2007-11-16 klockan 13:09 +0100 skrev Ralf Ertzinger:
> > On Fri, 16 Nov 2007 03:17:21 -0500, Kelly Miller wrote:
> 
> > > the result is
> > > NetworkManager needs DBus, which needs LDAP, which needs
> > > NetworkManager.  The result?  The system freezes at the first service
> > > in the cycle.
> > 
> > There is a neat option I learned some time ago:
> > 
> > nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
> > 
> > This (should) make ldap ignore these users (which exist locally,
> > unless you manually removed them)
> 
> Oh yes... Is the correct solution here to make this the default?

Yes; actually I think the right thing is to to always look up locally
any uid which is less than 500, because Fedora reserves those for the
operating system.  Can't find a reference at the moment, but if someone
does, add it to: http://fedoraproject.org/wiki/Packaging/UsersAndGroups




From rdieter at math.unl.edu  Fri Nov 16 21:20:21 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 16 Nov 2007 15:20:21 -0600
Subject: Package for Qt-Jambi?
References: <473A82FB.9030408@gmail.com>	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>	<473D433C.7040502@gmail.com>
	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>
	<473DFC2A.2070609@gmail.com>
Message-ID: <fhl1k9$7tr$1@ger.gmane.org>

Kelly Miller wrote:

>  As a
> result, the only other option is to create a symbolic link from
> /usr/include to $QTDIR/include, but that requires root access to run the
> rpmbuild, and uh, I'm not so sure that's a fantastic idea...

I'm open to the idea of adding such compat-symlinks to qt4 packaging
(provided that packages don't actually try to install anything there).

-- Rex




From hhoffman at ip-solutions.net  Fri Nov 16 21:31:59 2007
From: hhoffman at ip-solutions.net (Harry Hoffman)
Date: Fri, 16 Nov 2007 16:31:59 -0500
Subject: LDAP and the dbus user
In-Reply-To: <1195248470.29478.10.camel@space-ghost.verbum.private>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<1195143796.3140.110.camel@cookie.hadess.net>	<20071115191131.GC60438@dspnet.fr.eu.org>	<20071115143152.4170c48f@redhat.com>
	<473CA371.1060808@gmail.com>	<604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>	<473D5211.2040906@gmail.com>
	<20071116130955.159f9c1b@dhcp03.addix.net>	<1195224756.618.36.camel@home.alexander.bostrom.net>
	<1195248470.29478.10.camel@space-ghost.verbum.private>
Message-ID: <473E0C4F.7030100@ip-solutions.net>

It's referenced in /etc/login.defs and the manpage for useradd

HTH,
Harry

Colin Walters wrote:
> On Fri, 2007-11-16 at 15:52 +0100, Alexander Bostr?m wrote:
>> fre 2007-11-16 klockan 13:09 +0100 skrev Ralf Ertzinger:
>>> On Fri, 16 Nov 2007 03:17:21 -0500, Kelly Miller wrote:
>>>> the result is
>>>> NetworkManager needs DBus, which needs LDAP, which needs
>>>> NetworkManager.  The result?  The system freezes at the first service
>>>> in the cycle.
>>> There is a neat option I learned some time ago:
>>>
>>> nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
>>>
>>> This (should) make ldap ignore these users (which exist locally,
>>> unless you manually removed them)
>> Oh yes... Is the correct solution here to make this the default?
> 
> Yes; actually I think the right thing is to to always look up locally
> any uid which is less than 500, because Fedora reserves those for the
> operating system.  Can't find a reference at the moment, but if someone
> does, add it to: http://fedoraproject.org/wiki/Packaging/UsersAndGroups
> 
> 



From triad at df.lth.se  Fri Nov 16 21:38:58 2007
From: triad at df.lth.se (Linus Walleij)
Date: Fri, 16 Nov 2007 22:38:58 +0100 (CET)
Subject: Push packages from diverse maintainers
In-Reply-To: <1195172345.3461.1.camel@ignacio.lan>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
	<1195172345.3461.1.camel@ignacio.lan>
Message-ID: <Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>

On Thu, 15 Nov 2007, Ignacio Vazquez-Abrams wrote:

>> So how do we *best* coordinate this?
>
> https://hosted.fedoraproject.org/projects/bodhi/ticket/79

Yeah OK, so blocking updates which breaks deps is a good idea. But will 
this cause a catch 22-situation where I cannot push libmtp because if I 
do, I break Amarok, and I cannot push Amarok too, because it is maintained 
by Aurelien and I'm not allowed to push that.

This leads to a situation where a maintainer of a lib has to co-maintain 
every package that is dependent on that lib, in order to be able to push 
updates properly.

So to make things perfect, maintainers of packages that other packages 
depend on should have their status escalated so that they can build and 
push all dependent packages if need be. OR (and this may be easier) have a 
mechanism to notify som dependency-engineer with access to everything to 
do builds and pushes for her/him.

Linus



From j.w.r.degoede at hhs.nl  Fri Nov 16 21:51:20 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 16 Nov 2007 22:51:20 +0100
Subject: Push packages from diverse maintainers
In-Reply-To: <Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>	<1195172345.3461.1.camel@ignacio.lan>
	<Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
Message-ID: <473E10D8.6000402@hhs.nl>

Linus Walleij wrote:
> On Thu, 15 Nov 2007, Ignacio Vazquez-Abrams wrote:
> 
>>> So how do we *best* coordinate this?
>>
>> https://hosted.fedoraproject.org/projects/bodhi/ticket/79
> 
> Yeah OK, so blocking updates which breaks deps is a good idea. But will 
> this cause a catch 22-situation where I cannot push libmtp because if I 
> do, I break Amarok, and I cannot push Amarok too, because it is 
> maintained by Aurelien and I'm not allowed to push that.
> 
> This leads to a situation where a maintainer of a lib has to co-maintain 
> every package that is dependent on that lib, in order to be able to push 
> updates properly.
> 
> So to make things perfect, maintainers of packages that other packages 
> depend on should have their status escalated so that they can build and 
> push all dependent packages if need be. OR (and this may be easier) have 
> a mechanism to notify som dependency-engineer with access to everything 
> to do builds and pushes for her/him.
> 

Or, do not do soname / ABI breaking updates in a stable release?

Regards,

Hans



From nicolas.mailhot at laposte.net  Fri Nov 16 21:59:59 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Nov 2007 22:59:59 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
Message-ID: <1195250399.3177.2.camel@rousalka.dyndns.org>

Forwarding to the right list (not that the two example package follow
the provisional guidelines on the fontconfig front, and I don't care
much about the core font side myself)


-------- Message transf?r? --------
De: Hans de Goede <j.w.r.degoede at hhs.nl>

Hi

On both my F-8 x86_64 live-dvd installation and my (clean) F-8 i386 install dvd 
installation, not all scriptlets for font-packages have properly run.

Taking /etc/X11/fontpath.d/fonts-default (urw-fonts) as example:
-On the x86_64 live dvd install, only fonts.scale is present, iow
  mkfontdir and fc-cache have not been run, even though they are in the
  scripts:
[hans at localhost ~]$ rpm -q --scripts urw-fonts
urw-fonts-2.4-1.fc8.noarch
postinstall scriptlet (using /bin/sh):
{
    umask 133
    mkfontscale /usr/share/fonts/default/Type1 || :
    `which mkfontdir` /usr/share/fonts/default/Type1 || :
    fc-cache /usr/share/fonts
} &> /dev/null || :

-On the i386 dvd install, nothing was run, so not only mkfontdir and
  fc-cache were not run, but also mkfontscale has not been run

The strange thing is fontconfig is actually required, so atleast the fc-cache 
file should have been created.

As for the other two not being created, well that is to be expected if the 
necessary packages are not added to any Requires.

Why are these files generated on install anyways, I understand this used to be 
usefull back in the days when multiple packages would install files under one 
dir, but isn't it so that most font dirs now only contain fonts from one package?

Note that this is not isolated to urw-fonts, ghostscript-fonts for example has 
the same problem.

Regards,

Hans

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/6711003f/attachment.sig>

From nicolas.mailhot at laposte.net  Fri Nov 16 22:06:27 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 16 Nov 2007 23:06:27 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071116183642.GA13435@nostromo.devel.redhat.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<20071116154149.GC422@nostromo.devel.redhat.com>
	<1195238099.8238.9.camel@rousalka.dyndns.org>
	<20071116183642.GA13435@nostromo.devel.redhat.com>
Message-ID: <1195250787.3177.6.camel@rousalka.dyndns.org>


Le vendredi 16 novembre 2007 ? 13:36 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > > scriptlets should be allowed to fail when the failure is catastrophic
> > > enough. What that is, I'm not sure.
> > 
> > scriptlets should be allowed to fail when the benefits of failing
> > (fixing packages) outweigh the cost of failure (killing transactions for
> > lots of users). Since so far the only documented failure was in rawhide
> > (at a time I doubt rawhide was perfectly installable anyway) I question
> > the need to hide this particular failure.
> 
> Not all scriptlets abort the transaction anyways, as I recall. %post
> certainly doesn't. So, maybe it should just be %pre shouldn't fail.

Well if this particular error never hit stable and never stayed long in
rawhide that's because the failure is immediate the first time someone
actually installs a faulty package, and "fixing" the scriptlet only
increases the probability a problem package will hit stable

Please keep this a brownpaper bag error.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/d6e673c4/attachment.sig>

From lightsolphoenix at gmail.com  Fri Nov 16 22:31:38 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Fri, 16 Nov 2007 17:31:38 -0500
Subject: Package for Qt-Jambi?
In-Reply-To: <fhl1k9$7tr$1@ger.gmane.org>
References: <473A82FB.9030408@gmail.com>	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>	<473D433C.7040502@gmail.com>	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>	<473DFC2A.2070609@gmail.com>
	<fhl1k9$7tr$1@ger.gmane.org>
Message-ID: <473E1A4A.9040903@gmail.com>

Rex Dieter wrote:
> I'm open to the idea of adding such compat-symlinks to qt4 packaging
> (provided that packages don't actually try to install anything there).
>
> -- Rex
>   
It doesn't appear that the system installs anything there, but I haven't 
managed to get all the way through compilation and installation yet.  
The guide suggests that once Qt-Jambi is compiled, it simply sits all in 
one directory and only needs to know where the Qt and Java libraries are.

However, the reason I posted stating it's probably better to wait is 
because this is flagged as a bug by the Trolltech guys, so at some point 
in the future the system won't have this dependency.  I found it on the 
mailing list when I went looking for the source of the bugs and possible 
fixes.



From lightsolphoenix at gmail.com  Fri Nov 16 22:36:18 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Fri, 16 Nov 2007 17:36:18 -0500
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071116130955.159f9c1b@dhcp03.addix.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>	<1195143796.3140.110.camel@cookie.hadess.net>	<20071115191131.GC60438@dspnet.fr.eu.org>	<20071115143152.4170c48f@redhat.com>
	<473CA371.1060808@gmail.com>	<604aa7910711151213o511f2832q928e51e14310ce92@mail.gmail.com>	<473D5211.2040906@gmail.com>
	<20071116130955.159f9c1b@dhcp03.addix.net>
Message-ID: <473E1B62.8050403@gmail.com>

Ralf Ertzinger wrote:
> There is a neat option I learned some time ago:
> nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
>
> This (should) make ldap ignore these users (which exist locally,
> unless you manually removed them)
>   
I knew there was a way of somehow doing this, because openSUSE does it 
by default.  However, even if I could get the system to start up 
properly here, I'd still run into a big problem; NetworkManager 
currently seems to have trouble with specific static IP entries.  Which 
I believe was the point at the beginning, wasn't it?



From ivazqueznet at gmail.com  Fri Nov 16 22:40:51 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 16 Nov 2007 17:40:51 -0500
Subject: Push packages from diverse maintainers
In-Reply-To: <Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
	<1195172345.3461.1.camel@ignacio.lan>
	<Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
Message-ID: <1195252851.26074.7.camel@ignacio.lan>

On Fri, 2007-11-16 at 22:38 +0100, Linus Walleij wrote:
> On Thu, 15 Nov 2007, Ignacio Vazquez-Abrams wrote:
> 
> >> So how do we *best* coordinate this?
> >
> > https://hosted.fedoraproject.org/projects/bodhi/ticket/79
> 
> Yeah OK, so blocking updates which breaks deps is a good idea. But
> will 
> this cause a catch 22-situation where I cannot push libmtp because if
> I 
> do, I break Amarok, and I cannot push Amarok too, because it is
> maintained 
> by Aurelien and I'm not allowed to push that.

It could place the packages into an intermediate state where it will
wait for all of them to be ready to be pushed, and then once they're all
waiting, it pushes them all at once.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/725195d9/attachment.sig>

From seg at haxxed.com  Fri Nov 16 22:58:23 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 16 Nov 2007 16:58:23 -0600
Subject: pulseaudio CPU usage and process name
In-Reply-To: <20071116212243.GA27498@tango.0pointer.de>
References: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
	<20071116192148.GA17455@tango.0pointer.de>
	<3da3b5b40711161157m62cb3fbfwb8910db0567668c8@mail.gmail.com>
	<20071116212243.GA27498@tango.0pointer.de>
Message-ID: <1195253906.24564.10.camel@localhost>

On Fri, 2007-11-16 at 22:22 +0100, Lennart Poettering wrote:
> If you feel that the resampling takes to much CPU, than you're welcome
> to sit down and add some real MMX/SSE support to the speex resampler,
> which is the one we're using. ;-)

Not SRC a.k.a libsamplerate? It would be really nice if everyone could
just use one resampler, so that resampling could just be done right, and
done fast, once. Why did speex do their own resampler?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/00044815/attachment.sig>

From gilboad at gmail.com  Fri Nov 16 23:20:33 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 17 Nov 2007 01:20:33 +0200
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <473DAC57.1030909@city-fan.org>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
	<473DAC57.1030909@city-fan.org>
Message-ID: <1195255233.14709.22.camel@gilboa-home-dev.localdomain>


On Fri, 2007-11-16 at 14:42 +0000, Paul Howarth wrote:
> Gilboa Davara wrote:
> > Hello all,
> > 
> > Were compat-stdc++ (and the rest of the compat-* libs group) packages
> > deprecated in F8?
> > If so, it's there any chance they'll be resurrected?
> > If not - did anyone attempt to rebuild the F7 compat-stdc++ SRPMs under
> > F8/rawhide? Any known issues?
> > 
> > - Gilboa
> > P.S. I need the compat-stdc++ (+dependencies) for UT2004. I assume that
> > other closed source applications/games will also require this package.
> 
> Perhaps you're trying the wrong package name?

Hit by what-looks-like a yumex search bug.

- Gilboa



From gilboad at gmail.com  Fri Nov 16 23:20:36 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 17 Nov 2007 01:20:36 +0200
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <20071116145255.GB29805@nostromo.devel.redhat.com>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
	<20071116145255.GB29805@nostromo.devel.redhat.com>
Message-ID: <1195255236.14709.25.camel@gilboa-home-dev.localdomain>


On Fri, 2007-11-16 at 09:52 -0500, Bill Nottingham wrote:
> Gilboa Davara (gilboad at gmail.com) said: 
> > Were compat-stdc++ (and the rest of the compat-* libs group) packages
> > deprecated in F8?
> 
> No, they're still there (compat-libstdc++-33, compat-libstdc++-296). They
> are almost certainly not on the live CDs or Fedora spins, but they're
> in the repo if you need them.
> 
> Bill
> 

OK Thanks.
I seem to have stumbled upon a weird bug in yumex.
Type stdc in the search windows and you get compat-stdc++-296 and 33.
Type stdc++ in the search window and you get nothing.

Reported as [1].

- Gilboa
[1] https://bugzilla.redhat.com/show_bug.cgi?id=387871




From mzerqung at 0pointer.de  Fri Nov 16 23:39:10 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sat, 17 Nov 2007 00:39:10 +0100
Subject: pulseaudio CPU usage and process name
In-Reply-To: <1195253906.24564.10.camel@localhost>
References: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
	<20071116192148.GA17455@tango.0pointer.de>
	<3da3b5b40711161157m62cb3fbfwb8910db0567668c8@mail.gmail.com>
	<20071116212243.GA27498@tango.0pointer.de>
	<1195253906.24564.10.camel@localhost>
Message-ID: <20071116233910.GA3133@tango.0pointer.de>

On Fri, 16.11.07 16:58, Callum Lerwick (seg at haxxed.com) wrote:

> On Fri, 2007-11-16 at 22:22 +0100, Lennart Poettering wrote:
> > If you feel that the resampling takes to much CPU, than you're welcome
> > to sit down and add some real MMX/SSE support to the speex resampler,
> > which is the one we're using. ;-)
> 
> Not SRC a.k.a libsamplerate? It would be really nice if everyone could
> just use one resampler, so that resampling could just be done right, and
> done fast, once. Why did speex do their own resampler?

You can change the resampler PA uses by changing the "resample-method"
config option in PA's daemon.conf. We support SRC, the speex
resampler, the ffmpeg resampler and a "trivial" resampler. 

Different resamplers have different properties. The advantage of SRC
is the superb quality, the disadvantages are that it is float-only and
GPL'ed, and thus not really useful on embedded systems and when you
want to load proprietary modules into PA (note that PA is fully
LGPL-licensed, but if you link it against SRC the daemon is
practically "down"graded to GPL).

The good about the Speex resampler is that it can do both float and
integer resampling, that it is BSD-licensed and it is a bit faster
than SRC. 

We chose to make the speex resampler the default. If you prefer the
extra quality of SRC, then you are free to reconfigure
daemon.conf. But trust me, you CPU load is not going to decrease if
you do that ;-).

BTW, if you don't care about the quality of the resampling you can
configure PA to use the "trivial" or "speex-0" resampler. They use
considerably less CPU -- at the cost of quality.

The GPL'dness of SRC is the single reason why SRC never gained that
much of an adoption on systems like gst or alsa.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From davej at redhat.com  Sat Nov 17 01:47:08 2007
From: davej at redhat.com (Dave Jones)
Date: Fri, 16 Nov 2007 20:47:08 -0500
Subject: kernel-PAE and NX (No eXecute)
In-Reply-To: <200711141000.22431.opensource@till.name>
References: <200711122008.08668.opensource@till.name>
	<20071114024949.GA12899@redhat.com>
	<200711141000.22431.opensource@till.name>
Message-ID: <20071117014708.GB30401@redhat.com>

On Wed, Nov 14, 2007 at 10:00:09AM +0100, Till Maas wrote:
 > On Mi November 14 2007, Dave Jones wrote:
 > > On Mon, Nov 12, 2007 at 08:08:08PM +0100, Till Maas wrote:
 > 
 > >  > I read
 > >  > that the 2.6.23 kernel supports NX without the need to activate 64G
 > >  > memory support?
 > >
 > > not true.
 > 
 > Here is a kernel git changelog entry that says it is true:
 > 
 > | i386: divorce CONFIG_X86_PAE from CONFIG_HIGHMEM64G
 > | 
 > | PAE is useful for more than supporting more than 4GB RAM.  It supports
 > | expanded swapspace and NX executable protections.  Some users may want NX
 > | or expanded swapspace support without the overhead or instability of
 > | highmem.  For these reasons, the following patch divorces CONFIG_X86_PAE
 > | from CONFIG_HIGHMEM64G.
 > 
 > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c673f1a9d994de501b674b2bb6a48bd5e912afe0

That's a really terrible exaggerated changelog entry.
The 'overhead' is still there because you need to use 3-level 64bit pagetables.
As for 'instability', well if there are bugs, how about we fix them?
(crazy idea I know, it'll never catch on).

So all this really buys you is the inability to use memory past 4G
if present.  For people with <4G, it's no different. They still
need PAE enabled to use NX.

	Dave

-- 
http://www.codemonkey.org.uk



From rcritten at redhat.com  Sat Nov 17 01:56:50 2007
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 16 Nov 2007 20:56:50 -0500
Subject: Fedora 8 curl breaks Second Life
In-Reply-To: <1195177530.24564.3.camel@localhost>
References: <1195018220.32559.98.camel@localhost>
	<473ABC3E.9090603@hhs.nl>	<1195037436.32559.200.camel@localhost>
	<473B3158.80703@redhat.com>	<473B43A7.4020105@redhat.com>
	<1195081571.32559.219.camel@localhost>
	<1195177530.24564.3.camel@localhost>
Message-ID: <473E4A62.1030403@redhat.com>

Callum Lerwick wrote:
> On Wed, 2007-11-14 at 17:06 -0600, Callum Lerwick wrote:
>> Otherwise I'm going to have to get a new package out...
> 
> Up to date package linked on the review ticket. :)
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=233946
> 

Bug and fix at: https://bugzilla.redhat.com/show_bug.cgi?id=387991

It was a one-line fix. The SSL use flag on the socket wasn't being set 
when opened non-blocking.

I'm not the curl maintainer so you'll have to wait until he gets a 
chance to check it out but you'll find a pointer to a srpm in the bug if 
you want to give it a try.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071116/bc3c1ba5/attachment.bin>

From alexl at users.sourceforge.net  Sat Nov 17 02:09:26 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 16 Nov 2007 19:09:26 -0700
Subject: Push packages from diverse maintainers
In-Reply-To: <473E10D8.6000402@hhs.nl> (Hans de Goede's message of "Fri\,
	16 Nov 2007 22\:51\:20 +0100")
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
	<1195172345.3461.1.camel@ignacio.lan>
	<Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
	<473E10D8.6000402@hhs.nl>
Message-ID: <ky1waptyg9.fsf@allele2.eebweb.arizona.edu>

>>>>> "HdG" == Hans de Goede  writes:

> Linus Walleij wrote:

[...]

>> So to make things perfect, maintainers of packages that other
>> packages depend on should have their status escalated so that they
>> can build and push all dependent packages if need be. OR (and this
>> may be easier) have a mechanism to notify som dependency-engineer
>> with access to everything to do builds and pushes for her/him.
>> 

HdG> Or, do not do soname / ABI breaking updates in a stable release?

Not always an option.  Witness the recent firefox 2.0.0.8/2.0.0.9
update snafus, this is exactly the cases I was targeting when I filed
the ticket on bodhi.  Each firefox security update bumps ABI whether
we want it to or not (although this is an indirect result of
suboptimal design on the part of the gecko maintainers not to have a
stable gecko-libs that is designed to be externally used).

Alex



From poelstra at redhat.com  Sat Nov 17 04:01:27 2007
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 16 Nov 2007 20:01:27 -0800
Subject: Fedora 9 Bug Day-v0.1 :: Monday, November 19, 2007
Message-ID: <473E6797.9050208@redhat.com>

Greetings,

This is an invitation to all community members to join us for our first 
"Bug Day" of the Fedora 9 release cycle!  Fedora 8 is hardly a week old 
and as is always the case--people around the world are reporting 
problems they encounter to make Fedora better.  Help make Fedora 9 a 
great release by joining us to review the outstanding bugs against Fedora.

We will meet on freenode in the #fedora-qa channel from 0:00 UTC to 
23:59 UTC, on Monday, November 19, 2007.  Join as for as little or as 
much as you can in your local timezone.  Lurkers are always welcome too.

What happens at a "Bug Day" you ask?  We review and triage as many open 
bugs as we can by helping them along to their next state--ideally fixed 
or closed :-)

You don't have to be a Fedora guru or hold a PhD in reading stack 
traces--in most cases you do not even have to run a program or attempt 
to reproduce the reported issue.  It is nice if you can, however often 
the most value able service you can provide is your eyes--reading the 
contents of a bug to see if enough information is present for the 
package owner (developer) to take the next step.  Sometimes that means 
requesting that the reporter attempt to reproduce the bug against the 
latest version or provide more information.  By doing this you can help 
package owners focus their time on the bugs that matter.

And if you are not sure what to do we can help you on IRC.

Some helpful links from the wiki for getting started are:
http://fedoraproject.org/wiki/TriagingGuidelines
http://fedoraproject.org/wiki/BugZappers
http://fedoraproject.org/wiki/KernelBugTriage

This is the first time I've organized a bug day (proposed two days ago 
at Wednesday's QA meeting) and I don't believe we have had one in a 
while.  It is possible some of the wiki pages about triaging bugs need 
updating or clarifying so if we use part of Monday to work on that it 
will be time well spent as it better prepares us for future bug days.

And don't forget you don't have to wait for an official Bug Day to 
triage bugs--they don't mind being triaged by anyone at any time :)

See you Monday,

John
aka "poelcat"

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From stickster at gmail.com  Sat Nov 17 05:56:30 2007
From: stickster at gmail.com (Paul W. Frields)
Date: Sat, 17 Nov 2007 00:56:30 -0500
Subject: Documentation
In-Reply-To: <45115.202.72.163.232.1195225685.squirrel@www.mwiriadi.id.au>
References: <45115.202.72.163.232.1195225685.squirrel@www.mwiriadi.id.au>
Message-ID: <1195278990.15039.1.camel@localhost.localdomain>

On Sat, 2007-11-17 at 00:08 +0900, Marc Wiriadisastra wrote:
> Hey all,
> 
> Just wanted your thoughts on something relating to documentation.  I had a
> read of
> http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac
> relating specifically to the documentation aspect.  Basically I was
> looking at  packaging Diveintopython.
> 
> http://www.diveintopython.org/index.html
> 
> There is no clear guideline except for will it improve the user
> experience.  To me thats fairly ambiguous as to what is considered
> improving the user experience.  It's probably worded that way specifically
> for a reason to not limit what goes in.

The guidelines specifically state in the examples following that
documentation is permissible.

I thought about packaging this myself and never got around to it.  If
you decide to do this, let me know.  If you decide *not* to do this,
please also let me know. :-)

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
           Fedora Project: http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/1347b516/attachment.sig>

From j.w.r.degoede at hhs.nl  Sat Nov 17 07:36:17 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 17 Nov 2007 08:36:17 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <1195251486.24535.46.camel@home.behdad.org>
References: <1195250399.3177.2.camel@rousalka.dyndns.org>
	<1195251486.24535.46.camel@home.behdad.org>
Message-ID: <473E99F1.7090907@hhs.nl>

Behdad Esfahbod wrote:
> On Fri, 2007-11-16 at 22:59 +0100, Nicolas Mailhot wrote:
>> Forwarding to the right list (not that the two example package follow
>> the provisional guidelines on the fontconfig front, and I don't care
>> much about the core font side myself)
>>
>>
>> -------- Message transf?r? --------
>> De: Hans de Goede <j.w.r.degoede at hhs.nl>
>>
>> Hi
>>
>> On both my F-8 x86_64 live-dvd installation and my (clean) F-8 i386 install dvd 
>> installation, not all scriptlets for font-packages have properly run.
>>
>> Taking /etc/X11/fontpath.d/fonts-default (urw-fonts) as example:
>> -On the x86_64 live dvd install, only fonts.scale is present, iow
>>   mkfontdir and fc-cache have not been run, even though they are in the
>>   scripts:
>> [hans at localhost ~]$ rpm -q --scripts urw-fonts
>> urw-fonts-2.4-1.fc8.noarch
>> postinstall scriptlet (using /bin/sh):
>> {
>>     umask 133
>>     mkfontscale /usr/share/fonts/default/Type1 || :
>>     `which mkfontdir` /usr/share/fonts/default/Type1 || :
>>     fc-cache /usr/share/fonts
>> } &> /dev/null || :
>>
>> -On the i386 dvd install, nothing was run, so not only mkfontdir and
>>   fc-cache were not run, but also mkfontscale has not been run
>>
>> The strange thing is fontconfig is actually required, so atleast the fc-cache 
>> file should have been created.
> 
> Fontconfig doesn't store cache files in the directory anymore.  They go
> in /var/cache/fontconfig.  That's been the case for a while.
> 

Ah, then the packages also should no longer ghost fc-cache in the fonts dir.

> 
>> As for the other two not being created, well that is to be expected if the 
>> necessary packages are not added to any Requires.
>>
>> Why are these files generated on install anyways, I understand this used to be 
>> usefull back in the days when multiple packages would install files under one 
>> dir, but isn't it so that most font dirs now only contain fonts from one package?
> 
> I don't understand.  When are you suggesting they should be generated?
> 

At package buildtime, and then simply include them in the package 
instead of %ghost them and generate them with scriptlets.

Regards,

Hans



From jfrieben at gmx.de  Sat Nov 17 09:50:05 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Sat, 17 Nov 2007 10:50:05 +0100
Subject: New subpackage xfig-Xaw3d
Message-ID: <20071117095005.128480@gmx.net>

As of build #24591, the "xfig" package has been split up into "xfig-common", a plain "xfig" package built against the "Xaw" widget library and a new "xfig-Xaw3d" package which is built against the "Xaw3d" widget set.
Many other distros moved to using "Xaw3d" in the past, and it's good news to have this in "Fedora" now, too. However, it appears suboptimal to me that there now exist 2 packages which provide the same functionality only differing by the underlying widget library. I'd prefer dropping "xfig-Xaw3d" and "xfig" being built by default against "Xaw3d" which is already required by the new "xdvi" package of "tetex" successor "texlive" scheduled for inclusion into the next release. This would avoid clutter and unnecessary confusion.
-- 
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger



From pertusus at free.fr  Sat Nov 17 10:19:53 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Nov 2007 11:19:53 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117095005.128480@gmx.net>
References: <20071117095005.128480@gmx.net>
Message-ID: <20071117101952.GA2571@free.fr>

On Sat, Nov 17, 2007 at 10:50:05AM +0100, Joachim Frieben wrote:
> As of build #24591, the "xfig" package has been split up into "xfig-common", a plain "xfig" package built against the "Xaw" widget library and a new "xfig-Xaw3d" package which is built against the "Xaw3d" widget set.
> Many other distros moved to using "Xaw3d" in the past, and it's good news to have this in "Fedora" now, too. However, it appears suboptimal to me that there now exist 2 packages which provide the same functionality only differing by the underlying widget library. I'd prefer dropping "xfig-Xaw3d" and "xfig" being built by default against "Xaw3d" which is already required by the new "xdvi" package of "tetex" successor "texlive" scheduled for inclusion into the next release. This would avoid clutter and unnecessary confusion.

This kind of choice is best left to the package maintainer.

--
Pat



From jonathan.underwood at gmail.com  Sat Nov 17 10:24:26 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sat, 17 Nov 2007 10:24:26 +0000
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117101952.GA2571@free.fr>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
Message-ID: <645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>

On 17/11/2007, Patrice Dumas <pertusus at free.fr> wrote:
> On Sat, Nov 17, 2007 at 10:50:05AM +0100, Joachim Frieben wrote:
> > As of build #24591, the "xfig" package has been split up into "xfig-common", a plain "xfig" package built against the "Xaw" widget library and a new "xfig-Xaw3d" package which is built against the "Xaw3d" widget set.
> > Many other distros moved to using "Xaw3d" in the past, and it's good news to have this in "Fedora" now, too. However, it appears suboptimal to me that there now exist 2 packages which provide the same functionality only differing by the underlying widget library. I'd prefer dropping "xfig-Xaw3d" and "xfig" being built by default against "Xaw3d" which is already required by the new "xdvi" package of "tetex" successor "texlive" scheduled for inclusion into the next release. This would avoid clutter and unnecessary confusion.
>
> This kind of choice is best left to the package maintainer.
>

IMO It would be better if the xfig package was the one built against
Xaw3D, and there was an optional xfig-Xaw package though, for the
older widget kit.
> --
> Pat
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From promac at gmail.com  Sat Nov 17 10:35:10 2007
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sat, 17 Nov 2007 08:35:10 -0200
Subject: Pulseaudio problems
Message-ID: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>

Hi,

I am trying to adapt myself to pulseaudio (F8 x86_64).

I had to change /etc/security/console.perms.d/50-default.perms
so I can use another X screen (:1) without being root, and  without using
pulse.
Otherwise, I hear no sound using mplayer (this is how I send a movie to an
ordinary TV).

After testing several applications, this is what I got so far
trying to use pulseaudio with plugins (not using alsa generic plugin):

MythTV: NO sound at all (therefore, pulse can not be a global default for
me)
mplayer (patched): OK
mplayerplug-in: OK
rhythmbox: OK
amarok: OK
xmms: OK
audacious 1.4: OK with ESD (stutters a lot with its own pulse plugin).
mpd 0.13: NO sound (it has the plugin, though).
ampache (flash player): OK
xine: NO. Sound disappears after a few seconds.
vlc: NO plugin available.

Also, after an interval of time of maybe 10 to 20 min I hear a fast hiccup
using amarock. I mean, the sound vanishes (but it is very fast), and it will
happen
again 10 min later, and so on...

I also noticed that using

arecord -D hw:0.0 -d 0 -f S16_LE -c2 -r48000 | aplay -D pulse &

for capturing from line in.

I have two sound cards:

[cascavel:~/SRPMS/vlc]   more /proc/asound/cards

 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0x92300000 irq 22
 1 [VirMIDI        ]: VirMIDI - VirMIDI
                      Virtual MIDI Card 1
 2 [Bt878          ]: Bt87x - Brooktree Bt878
                      Brooktree Bt878 at 0x92000000, irq 18
 3 [CMI8738        ]: CMI8738-MC6 - C-Media CMI8738
                      C-Media CMI8738 (model 55) at 0x1000, irq 21

The good part, is that I can switch between sound cards very easily and
switch users and resume what I was playing before in gnome.

Sorry if I am writing to the wrong list, but I think this kind of
information
can be useful for the developers.

Thank you.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/1adc5295/attachment.htm>

From j.w.r.degoede at hhs.nl  Sat Nov 17 10:37:37 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 17 Nov 2007 11:37:37 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
Message-ID: <473EC471.2040603@hhs.nl>

Jonathan Underwood wrote:
> On 17/11/2007, Patrice Dumas <pertusus at free.fr> wrote:
>> On Sat, Nov 17, 2007 at 10:50:05AM +0100, Joachim Frieben wrote:
>>> As of build #24591, the "xfig" package has been split up into "xfig-common", a plain "xfig" package built against the "Xaw" widget library and a new "xfig-Xaw3d" package which is built against the "Xaw3d" widget set.
>>> Many other distros moved to using "Xaw3d" in the past, and it's good news to have this in "Fedora" now, too. However, it appears suboptimal to me that there now exist 2 packages which provide the same functionality only differing by the underlying widget library. I'd prefer dropping "xfig-Xaw3d" and "xfig" being built by default against "Xaw3d" which is already required by the new "xdvi" package of "tetex" successor "texlive" scheduled for inclusion into the next release. This would avoid clutter and unnecessary confusion.
>> This kind of choice is best left to the package maintainer.
>>
> 
> IMO It would be better if the xfig package was the one built against
> Xaw3D, and there was an optional xfig-Xaw package though, for the
> older widget kit.

That can be done. As of recently I'm a co-maintainer of xfig, and I'm the one 
who introduced the xfig-Xaw3d package, all 3 options:
-Xaw3d only build
-both, Xaw3d the default
-both, Xaw the default

Are fine with me, I did things as they are now as xfig had a lot of bugs open 
against them, so the latest release, besides adding an Xaw3d package also fixes 
a lot of bugs, thus its being pushed as an update for F-7 and F-8 too. And I 
didn't want this update to cause a widget set change, going from the principle 
of least surprise. But I can easily switch the default to Xaw3d for rawhide if 
people prefer that, or even make the rawhide package an Xaw3d only build.

Regards,

Hans



From pertusus at free.fr  Sat Nov 17 10:46:51 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Nov 2007 11:46:51 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <473EC471.2040603@hhs.nl>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl>
Message-ID: <20071117104651.GB2571@free.fr>

On Sat, Nov 17, 2007 at 11:37:37AM +0100, Hans de Goede wrote:
>
> That can be done. As of recently I'm a co-maintainer of xfig, and I'm the 
> one who introduced the xfig-Xaw3d package, all 3 options:
> -Xaw3d only build
> -both, Xaw3d the default
> -both, Xaw the default
>
> Are fine with me, I did things as they are now as xfig had a lot of bugs 
> open against them, so the latest release, besides adding an Xaw3d package 
> also fixes a lot of bugs, thus its being pushed as an update for F-7 and 
> F-8 too. And I didn't want this update to cause a widget set change, going 
> from the principle of least surprise. But I can easily switch the default 
> to Xaw3d for rawhide if people prefer that, or even make the rawhide 
> package an Xaw3d only build.

I personnally would prefer 
-both, Xaw3d the default
to be able to use the Xaw interface if there are issues with Xaw3d,
while having the Xaw3d as default to be tested.

--
Pat



From jonathan.underwood at gmail.com  Sat Nov 17 11:15:30 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sat, 17 Nov 2007 11:15:30 +0000
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117104651.GB2571@free.fr>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl> <20071117104651.GB2571@free.fr>
Message-ID: <645d17210711170315h7aac2e22na642225537e225b7@mail.gmail.com>

On 17/11/2007, Patrice Dumas <pertusus at free.fr> wrote:
> I personnally would prefer
> -both, Xaw3d the default
> to be able to use the Xaw interface if there are issues with Xaw3d,
> while having the Xaw3d as default to be tested.

Seems reasonable to me.



From mschwendt.tmp0701.nospam at arcor.de  Sat Nov 17 12:16:42 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sat, 17 Nov 2007 13:16:42 +0100
Subject: Package for Qt-Jambi?
In-Reply-To: <473DFC2A.2070609@gmail.com>
References: <473A82FB.9030408@gmail.com>
	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>
	<473D433C.7040502@gmail.com>
	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>
	<473DFC2A.2070609@gmail.com>
Message-ID: <20071117131642.3a81a1aa.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 16 Nov 2007 15:23:06 -0500, Kelly Miller wrote:

> Michael Schwendt wrote:
> > Unbuildable? In %build, you could set up your own local QTDIR and link
> > from it to the original $QTDIR/$QTLIB locations.
> >   
> Actually, I did before I even tried to build it.  The problem which 
> comes up here is not that I can override QTDIR, but that Fedora (and 
> AFAIK, every other Linux distro) doesn't keep the Qt headers in 
> $QTDIR/include .  This only makes sense, as headers are supposed to go 
> into /usr/include or /include, depending on importance.  However, the 
> build process looks for headers in $QTDIR/include at some point, and 
> despite extensive searching, I can't seem to locate exactly where.  As a 
> result, the only other option is to create a symbolic link from 
> /usr/include to $QTDIR/include, but that requires root access to run the 
> rpmbuild, and uh, I'm not so sure that's a fantastic idea...

If you control the value of $QTDIR, you also control what $QTDIR/include
contains (or points to). I still don't understand where you need root
access when you would point $QTDIR to $(pwd)/foo or a other place
below $RPM_BUILD_DIR.

It looks like Mandriva build it without such tricks, but they do install
manually:
http://rpm.pbone.net/index.php3/stat/26/dist/17/size/19258906/name/qtjambi-4.3.1-5mdv2008.0.src.rpm



From jfrieben at gmx.de  Sat Nov 17 12:46:38 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Sat, 17 Nov 2007 13:46:38 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117104651.GB2571@free.fr>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl> <20071117104651.GB2571@free.fr>
Message-ID: <20071117124638.148990@gmx.net>

> I personnally would prefer 
> -both, Xaw3d the default
> to be able to use the Xaw interface if there are issues with Xaw3d,
> while having the Xaw3d as default to be tested.
> 
> --
> Pat

Not consistent with the procedure in other cases like e.g. "xdvi" and "tetex-xdvi" which do use "Xaw3d" by default, and where an alternative "Xaw" build doesn't exist either. Wouldn't they be afflicted by hypothetical "Xaw3d" issues, too?
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer



From pertusus at free.fr  Sat Nov 17 14:23:31 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Nov 2007 15:23:31 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117124638.148990@gmx.net>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl> <20071117104651.GB2571@free.fr>
	<20071117124638.148990@gmx.net>
Message-ID: <20071117142331.GA2572@free.fr>

On Sat, Nov 17, 2007 at 01:46:38PM +0100, Joachim Frieben wrote:
> > I personnally would prefer 
> > -both, Xaw3d the default
> > to be able to use the Xaw interface if there are issues with Xaw3d,
> > while having the Xaw3d as default to be tested.
> > 
> > --
> > Pat
> 
> Not consistent with the procedure in other cases like e.g. "xdvi" and "tetex-xdvi" which do use "Xaw3d" by default, and where an alternative "Xaw" build doesn't exist either. Wouldn't they be afflicted by hypothetical "Xaw3d" issues, too?

Who knows. It is always better to have a fallback known to work.
Moreover xfig is different from xdvi.

--
Pat



From jamatos at fc.up.pt  Sat Nov 17 14:37:23 2007
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Sat, 17 Nov 2007 14:37:23 +0000
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117142331.GA2572@free.fr>
References: <20071117095005.128480@gmx.net> <20071117124638.148990@gmx.net>
	<20071117142331.GA2572@free.fr>
Message-ID: <200711171437.25638.jamatos@fc.up.pt>

On Saturday 17 November 2007 14:23:31 Patrice Dumas wrote:
> Who knows. It is always better to have a fallback known to work.
> Moreover xfig is different from xdvi.

  If xdvi fails there is always kdvi (or okular for kde4), if xfig fails well 
you can always change the file by hand. ;-)

> --
> Pat

-- 
Jos? Ab?lio



From laroche at redhat.com  Sat Nov 17 15:37:26 2007
From: laroche at redhat.com (Florian La Roche)
Date: Sat, 17 Nov 2007 16:37:26 +0100
Subject: packaging files via symlinks
Message-ID: <20071117153726.GA11512@dudweiler.stuttgart.redhat.com>

Hello all,

I've added a check to pyrpm to detect the cases where
a symlink to a directory is used within a directory name
to package files into a rpm. The patch for this is at:
http://www.jur-linux.org/git/?p=cvs-pyrpm.git;a=commitdiff;h=3cfefdc1496c0ee6b0ca925430af7d45f8531ece
Let me know if you can speed this test further up and know
further python or algorithm improvements.

We knew such a symlink was often used to package e.g. /etc/init.d/<service>,
but running this on Fedora-devel shows that also other
packages are affected:

symlink /etc/init.d from chkconfig-1.3.37-1.i386.rpm is used as directory name in conmux-0.0-6.493svn.fc7.noarch.rpm aiccu-2007.01.15-3.fc8.i386.rpm tomcat5-5.5.23-9jpp.4.fc8.i386.rpm cobbler-0.6.3-2.fc9.noarch.rpm func-0.13-3.fc9.noarch.rpm zabbix-agent-1.4.2-3.fc8.i386.rpm varnish-1.1.1-3.fc8.i386.rpm jetty-5.1.12-1jpp.7.fc8.i386.rpm dkms-2.0.17.5-1.fc8.noarch.rpm ldirectord-2.1.2-2.fc8.i386.rpm monotone-server-0.37-3.fc9.i386.rpm dircproxy-1.2.0-0.6beta2.fc8.i386.rpm fuse-2.7.0-8.fc8.i386.rpm wifiroamd-1.12-1.fc8.noarch.rpm conman-0.1.9.2-7.fc7.i386.rpm sqlgrey-1.7.5-1.fc7.noarch.rpm edac-utils-0.9-7.fc8.i386.rpm zabbix-1.4.2-3.fc8.i386.rpm cyphesis-0.5.13-2.fc8.i386.rpm heartbeat-2.1.2-2.fc8.i386.rpm
symlink /usr/lib/tcl8.4 from tcl-8.4.15-5.fc8.i386.rpm is used as directory name in tkdnd-1.0a2-9.fc8.i386.rpm amsn-0.96-7.fc7.i386.rpm tbcload-1.4-5.20061030cvs.fc8.i386.rpm
symlink /usr/share/pharosc/alliance/makevbe/ssxlib013 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/rgalib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/ssxlib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/sxlib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/vgalib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/vsclib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/vxlib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/pharosc/alliance/vbe/wsclib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
symlink /usr/share/sgml/docbook/xsl-stylesheets from docbook-style-xsl-1.73.2-4.fc9.noarch.rpm is used as directory name in docbook-style-xsl-1.73.2-4.fc9.noarch.rpm dblatex-0.2.7-16.fc9.noarch.rpm

I'll add a bugzilla report for tkdnd, amsn, tbcload,
pharosc, docbook-style-xsl, dblatex if noone are already filed.

regards,

Florian La Roche



From pertusus at free.fr  Sat Nov 17 15:51:36 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Nov 2007 16:51:36 +0100
Subject: packaging files via symlinks
In-Reply-To: <20071117153726.GA11512@dudweiler.stuttgart.redhat.com>
References: <20071117153726.GA11512@dudweiler.stuttgart.redhat.com>
Message-ID: <20071117155136.GB2572@free.fr>

On Sat, Nov 17, 2007 at 04:37:26PM +0100, Florian La Roche wrote:
> Hello all,
> 
> but running this on Fedora-devel shows that also other
> packages are affected:
> 
> symlink /usr/share/sgml/docbook/xsl-stylesheets from docbook-style-xsl-1.73.2-4.fc9.noarch.rpm is used as directory name in docbook-style-xsl-1.73.2-4.fc9.noarch.rpm dblatex-0.2.7-16.fc9.noarch.rpm
> 
> I'll add a bugzilla report for tkdnd, amsn, tbcload,
> pharosc, docbook-style-xsl, dblatex if noone are already filed.

I am interested in dblatex, and I don't see what is wrong with using the
symlink as a directory. Indeed, 
/usr/share/sgml/docbook/xsl-stylesheets-1.73.2-4.fc9
may be the right directory to use, but it xsl-stylesheets version
dependent. Does it mean that the version dependency is hidden by using
the symlink, but that it will break upon docbook-style-xsl update?

In that case I guess that the right thing to do is to have
/usr/share/sgml/docbook/xsl-stylesheets be a directory.

--
Pat



From frank-buettner at gmx.net  Sat Nov 17 15:58:49 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sat, 17 Nov 2007 16:58:49 +0100
Subject: qwtplot3d-qt4 and gsl
Message-ID: <473F0FB9.2020705@gmx.net>

Hello,

when will be this packages available at the EPEL 4 repo??
I need this for my package.

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/efec94ff/attachment.bin>

From fedora at camperquake.de  Sat Nov 17 16:11:56 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 17 Nov 2007 17:11:56 +0100
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <1195255236.14709.25.camel@gilboa-home-dev.localdomain>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
	<20071116145255.GB29805@nostromo.devel.redhat.com>
	<1195255236.14709.25.camel@gilboa-home-dev.localdomain>
Message-ID: <20071117171156.440fa23e@lain.camperquake.de>

Hi.

On Sat, 17 Nov 2007 01:20:36 +0200, Gilboa Davara wrote

> OK Thanks.
> I seem to have stumbled upon a weird bug in yumex.
> Type stdc in the search windows and you get compat-stdc++-296 and 33.
> Type stdc++ in the search window and you get nothing.

Does 'stdc\+\+' work?



From chitlesh.goorah at gmail.com  Sat Nov 17 16:13:48 2007
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sat, 17 Nov 2007 17:13:48 +0100
Subject: qwtplot3d-qt4 and gsl
In-Reply-To: <473F0FB9.2020705@gmx.net>
References: <473F0FB9.2020705@gmx.net>
Message-ID: <50baabb30711170813h154b9f84x3b566555835c7a3e@mail.gmail.com>

On Nov 17, 2007 4:58 PM, Frank B?ttner wrote:
> Hello,
>
> when will be this packages available at the EPEL 4 repo??
> I need this for my package.

Well last month, I told you that you have my green light to be the
co-maintainer of qwtplot3d for EPEL .

chitlesh



From gilboad at gmail.com  Sat Nov 17 17:04:54 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 17 Nov 2007 19:04:54 +0200
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <20071117171156.440fa23e@lain.camperquake.de>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
	<20071116145255.GB29805@nostromo.devel.redhat.com>
	<1195255236.14709.25.camel@gilboa-home-dev.localdomain>
	<20071117171156.440fa23e@lain.camperquake.de>
Message-ID: <1195319094.18748.0.camel@gilboa-home-dev.localdomain>


On Sat, 2007-11-17 at 17:11 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Sat, 17 Nov 2007 01:20:36 +0200, Gilboa Davara wrote
> 
> > OK Thanks.
> > I seem to have stumbled upon a weird bug in yumex.
> > Type stdc in the search windows and you get compat-stdc++-296 and 33.
> > Type stdc++ in the search window and you get nothing.
> 
> Does 'stdc\+\+' work?
> 

Nope. Nada.

- Gilboa



From gilboad at gmail.com  Sat Nov 17 17:06:02 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sat, 17 Nov 2007 19:06:02 +0200
Subject: compat-stdc++ deprecated in F8?
In-Reply-To: <1195319094.18748.0.camel@gilboa-home-dev.localdomain>
References: <1195223740.5676.4.camel@gilboa-home-dev.localdomain>
	<20071116145255.GB29805@nostromo.devel.redhat.com>
	<1195255236.14709.25.camel@gilboa-home-dev.localdomain>
	<20071117171156.440fa23e@lain.camperquake.de>
	<1195319094.18748.0.camel@gilboa-home-dev.localdomain>
Message-ID: <1195319162.18748.2.camel@gilboa-home-dev.localdomain>


On Sat, 2007-11-17 at 19:04 +0200, Gilboa Davara wrote:
> On Sat, 2007-11-17 at 17:11 +0100, Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Sat, 17 Nov 2007 01:20:36 +0200, Gilboa Davara wrote
> > 
> > > OK Thanks.
> > > I seem to have stumbled upon a weird bug in yumex.
> > > Type stdc in the search windows and you get compat-stdc++-296 and 33.
> > > Type stdc++ in the search window and you get nothing.
> > 
> > Does 'stdc\+\+' work?
> > 
> 
> Nope. Nada.
> 
> - Gilboa

P.S. It doesn't look like Yumex has regex support. Already tried that :)

- Gilboa



From wtogami at redhat.com  Sat Nov 17 17:19:04 2007
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 17 Nov 2007 12:19:04 -0500
Subject: Moodle package dependencies
Message-ID: <473F2288.7080405@redhat.com>

Hi Jon,

http://pastebot.ltsp.org/362
These are Ubuntu's plans to split up the Moodle package in order to make 
it easier to maintain, especially for security updates.  Apparently 
moodle ships entire other upstream projects within their distribution. 
How are we in Fedora with using our own distro packages for this 
functionality?

Warren Togami
wtogami at redhat.com



From buildsys at fedoraproject.org  Sat Nov 17 17:51:24 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Sat, 17 Nov 2007 12:51:24 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-17
Message-ID: <20071117175124.4C31415212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 5

    aspell-sk-2.00-3.fc6
    hyperestraier-1.4.11-1.fc6
    jd-1.9.7-0.4.rc071115.fc6
    qdbm-1.8.77-1.fc6
    xscreensaver-5.04-1.fc6


Changes in Fedora Extras 6: 


aspell-sk-2.00-3.fc6
--------------------
* Thu Nov 01 2007 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 2.00-3
- update upstream
- updated license to upstream
- inspired by aspell-en (used aspellversion macro)

hyperestraier-1.4.11-1.fc6
--------------------------
* Sat Nov 17 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.11-1
- 1.4.11

* Wed Aug 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.10-2.dist.2
- Mass rebuild (buildID or binutils issue)

* Fri Aug 03 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.10-2.dist.1
- License update

* Sat Jun 16 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.10-2
- Fix java directory

jd-1.9.7-0.4.rc071115.fc6
-------------------------
* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

qdbm-1.8.77-1.fc6
-----------------
* Sat Nov 17 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.77-1
- 1.8.77

xscreensaver-5.04-1.fc6
-----------------------
* Tue Nov 13 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.04-1
- Update to 5.04



From lightsolphoenix at gmail.com  Sat Nov 17 17:55:16 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Sat, 17 Nov 2007 12:55:16 -0500
Subject: Package for Qt-Jambi?
In-Reply-To: <20071117131642.3a81a1aa.mschwendt.tmp0701.nospam@arcor.de>
References: <473A82FB.9030408@gmail.com>	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>	<473D433C.7040502@gmail.com>	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>	<473DFC2A.2070609@gmail.com>
	<20071117131642.3a81a1aa.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <473F2B04.3070907@gmail.com>

Michael Schwendt wrote:
> If you control the value of $QTDIR, you also control what $QTDIR/include
> contains (or points to). I still don't understand where you need root
> access when you would point $QTDIR to $(pwd)/foo or a other place
> below $RPM_BUILD_DIR
Because in order for the system to compile at all, $QTDIR HAS to point 
at /usr/lib/qt4.  Otherwise the system will incorrectly find the Qt3 
versions of the Qt tools (qmake, etc.) and error out.  However, there is 
no link from /usr/lib/qt4/include to /usr/include, so the system can't 
find the headers.  The system, as I said before, is set up on the 
assumption that everything related to Qt is installed in one folder.  
This is normal if you download the source directly from Trolltech's 
website and compile it yourself, but not if you install it via package 
because of the FHS.  Hence my comment that this is catering to the 
Windows users (because they'd be in this situation 100% of the time, 
whereas Mac/Linux/Solaris/BSD users would not).



From jfrieben at gmx.de  Sat Nov 17 18:32:09 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Sat, 17 Nov 2007 19:32:09 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117142331.GA2572@free.fr>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl> <20071117104651.GB2571@free.fr>
	<20071117124638.148990@gmx.net> <20071117142331.GA2572@free.fr>
Message-ID: <20071117183209.106320@gmx.net>

> Who knows. It is always better to have a fallback known to work.
> Moreover xfig is different from xdvi.
> 
> --
> Pat

In order to reconcile "safety first" and technical progress one should consider sticking to Xaw build for F8 and F7 and adopting a single Xaw3d build for F9/rawhide.
Other distros have been using Xaw3d [which must have been around for more than a decade now] as standard widget library for xfig for a while already without any particular problems.
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail



From kevin.kofler at chello.at  Sat Nov 17 18:52:01 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 17 Nov 2007 18:52:01 +0000 (UTC)
Subject: New subpackage xfig-Xaw3d
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl>
Message-ID: <loom.20071117T184826-364@post.gmane.org>

Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
> That can be done. As of recently I'm a co-maintainer of xfig, and I'm the one 
> who introduced the xfig-Xaw3d package, all 3 options:
> -Xaw3d only build
> -both, Xaw3d the default
> -both, Xaw the default
> 
> Are fine with me, I did things as they are now as xfig had a lot of bugs open 
> against them, so the latest release, besides adding an Xaw3d package also
> fixes a lot of bugs, thus its being pushed as an update for F-7 and F-8 too.
> And I didn't want this update to cause a widget set change, going from the
> principle of least surprise. But I can easily switch the default to Xaw3d for
> rawhide if people prefer that, or even make the rawhide package an Xaw3d only
> build.

I'd just switch to Xaw3d (only) for all branches. I don't think having 2 
versions built against different versions of the toolkit makes sense, and Xaw3d 
is clearly the better-looking one (looks only 10 years old rather than 
20 ;-) ).

        Kevin Kofler



From j.w.r.degoede at hhs.nl  Sat Nov 17 18:55:22 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 17 Nov 2007 19:55:22 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117183209.106320@gmx.net>
References: <20071117095005.128480@gmx.net>
	<20071117101952.GA2571@free.fr>	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>	<473EC471.2040603@hhs.nl>
	<20071117104651.GB2571@free.fr>	<20071117124638.148990@gmx.net>
	<20071117142331.GA2572@free.fr> <20071117183209.106320@gmx.net>
Message-ID: <473F391A.8010202@hhs.nl>

Joachim Frieben wrote:
>> Who knows. It is always better to have a fallback known to work.
>> Moreover xfig is different from xdvi.
>>
>> --
>> Pat
> 
> In order to reconcile "safety first" and technical progress one should consider sticking to Xaw build for F8 and F7 and adopting a single Xaw3d build for F9/rawhide.
> Other distros have been using Xaw3d [which must have been around for more than a decade now] as standard widget library for xfig for a while already without any particular problems.


Okay,

I've enough input now, both with Xaw3d the default for rawhide and newer it 
will be.

If anyone disagrees he is free to ask Than to become xfig co-maintainer and 
make whatever changes he/she pleases once he/she is co-maintainer.

Regards,

Hans



From triad at df.lth.se  Sat Nov 17 21:23:45 2007
From: triad at df.lth.se (Linus Walleij)
Date: Sat, 17 Nov 2007 22:23:45 +0100 (CET)
Subject: Push packages from diverse maintainers
In-Reply-To: <473E10D8.6000402@hhs.nl>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
	<1195172345.3461.1.camel@ignacio.lan>
	<Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
	<473E10D8.6000402@hhs.nl>
Message-ID: <Pine.GSO.4.60.0711172219001.12920@igloo.df.lth.se>

On Fri, 16 Nov 2007, Hans de Goede wrote:

> Or, do not do soname / ABI breaking updates in a stable release?

Of course, and would do, unless the damn users were filing bugzilla 
tickets on me all the time. The update is already done in devel.

There is no clear policy here, user wants her hardware (Creative ZEN) to 
work with current F-8, can I just close that as "won't fix", wait for F-9 
or build from source?

(And no, since I am not doing this for a living I have no time to 
backport it, not that it'd be a good idea.)

Linus



From triad at df.lth.se  Sat Nov 17 21:25:19 2007
From: triad at df.lth.se (Linus Walleij)
Date: Sat, 17 Nov 2007 22:25:19 +0100 (CET)
Subject: Push packages from diverse maintainers
In-Reply-To: <1195252851.26074.7.camel@ignacio.lan>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>
	<1195172345.3461.1.camel@ignacio.lan>
	<Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>
	<1195252851.26074.7.camel@ignacio.lan>
Message-ID: <Pine.GSO.4.60.0711172224170.12920@igloo.df.lth.se>

On Fri, 16 Nov 2007, Ignacio Vazquez-Abrams wrote:

> It could place the packages into an intermediate state where it will
> wait for all of them to be ready to be pushed, and then once they're all
> waiting, it pushes them all at once.

Good idea, I'm dying to see that in Bodhi! :-)

Perhaps we could put some of this discussion into that ticket.

Linus



From j.w.r.degoede at hhs.nl  Sat Nov 17 21:42:04 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 17 Nov 2007 22:42:04 +0100
Subject: Push packages from diverse maintainers
In-Reply-To: <Pine.GSO.4.60.0711172219001.12920@igloo.df.lth.se>
References: <Pine.GSO.4.60.0711160040070.27949@igloo.df.lth.se>	<1195172345.3461.1.camel@ignacio.lan>	<Pine.GSO.4.60.0711162231310.16489@igloo.df.lth.se>	<473E10D8.6000402@hhs.nl>
	<Pine.GSO.4.60.0711172219001.12920@igloo.df.lth.se>
Message-ID: <473F602C.6060909@hhs.nl>

Linus Walleij wrote:
> On Fri, 16 Nov 2007, Hans de Goede wrote:
> 
>> Or, do not do soname / ABI breaking updates in a stable release?
> 
> Of course, and would do, unless the damn users were filing bugzilla 
> tickets on me all the time. The update is already done in devel.
> 
> There is no clear policy here, user wants her hardware (Creative ZEN) to 
> work with current F-8, can I just close that as "won't fix", wait for 
> F-9 or build from source?
> 

Erm, well that makes this a special case then, in that case I say go for the 
soname breakage.

Regards,

Hans



From matt at truch.net  Sat Nov 17 21:42:00 2007
From: matt at truch.net (Matthew D Truch)
Date: Sat, 17 Nov 2007 16:42:00 -0500
Subject: kst and automake/autoconf/etc issue.
Message-ID: <20071117214200.GC3111@truch.net>

Greetings,

I'd like to package up the newest version of kst (1.5.0), but it seems
that the kst developers didn't quite generate the tarball correctly and
during build it needs automake/autoconf packages installed to compile
(unlike previous versions).  The kst devels aren't too interested in
helping resolve this.  Should I go the lazy route and add the
autoconf/automake BR to the spec so it'll build, or should I attempt to
generate a patch which fixes things.  I'm a complete N00b when it comes
to automake/autoconf, so if you know your way around such systems, I'd
love your help/advice.  

Thanks.


PS - The kst webpage is at:
http://kst.kde.org/
along with the most recent tarball:
http://mirrors.ibiblio.org/pub/mirrors/kde/stable/apps/KDE3.x/scientific/kst-1.5.0.tar.gz

-- 
"Duct Tape is like the Force.  It has a dark side, a light side, and holds the universe together."
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt at truch.net
http://matt.truch.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/c4df4641/attachment.sig>

From lightsolphoenix at gmail.com  Sat Nov 17 22:25:49 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Sat, 17 Nov 2007 17:25:49 -0500
Subject: kst and automake/autoconf/etc issue.
In-Reply-To: <20071117214200.GC3111@truch.net>
References: <20071117214200.GC3111@truch.net>
Message-ID: <473F6A6D.3050909@gmail.com>

Matthew D Truch wrote:
> Greetings,
>
> I'd like to package up the newest version of kst (1.5.0), but it seems
> that the kst developers didn't quite generate the tarball correctly and
> during build it needs automake/autoconf packages installed to compile
> (unlike previous versions).  The kst devels aren't too interested in
> helping resolve this.  Should I go the lazy route and add the
> autoconf/automake BR to the spec so it'll build, or should I attempt to
> generate a patch which fixes things.  I'm a complete N00b when it comes
> to automake/autoconf, so if you know your way around such systems, I'd
> love your help/advice.  
>
> Thanks.
>
>
> PS - The kst webpage is at:
> http://kst.kde.org/
> along with the most recent tarball:
> http://mirrors.ibiblio.org/pub/mirrors/kde/stable/apps/KDE3.x/scientific/kst-1.5.0.tar.gz
>   
I've come across tarballs like that.  All you really have to do is put
autoreconf
before the call to %configure, and then add autoconf and automake as 
dependencies.  Crappy, yeah, but if you have to generate the 
dependencies you don't have much of a choice.



From tmz at pobox.com  Sat Nov 17 22:56:24 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 17 Nov 2007 17:56:24 -0500
Subject: rpms/kdenetwork/F-8 kdenetwork.spec,1.108,1.109
In-Reply-To: <200711172247.lAHMlPP5025721@cvs-int.fedora.redhat.com>
References: <200711172247.lAHMlPP5025721@cvs-int.fedora.redhat.com>
Message-ID: <20071117225624.GG320@psilocybe.teonanacatl.org>

Hi Rex,

Rex Dieter wrote:
> %changelog
> +* Sat Nov 16 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-8
     ^^^^^^^^^^
> * Sat Nov 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 7:3.5.8-7
    ^^^^^^^^^^

Can I get a copy of your calendar?  I could use two Saturdays per
week.  Also, my calendar says Saturday is Nov 17, so if you wouldn't
mind sharing your time machine too, that'd be just awesome. ;-)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Profanity is the inevitable linguistic crutch of the inarticulate
motherfucker.
    -- Bruce Sherrod

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/d8d7e485/attachment.sig>

From bpepple at fedoraproject.org  Sat Nov 17 23:51:12 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Sat, 17 Nov 2007 18:51:12 -0500
Subject: FESCo Meeting Summary for 2007-11-15
Message-ID: <1195343472.6315.3.camel@kennedy>

= Members Present =
      * Brian Pepple (bpepple) 
      * Jason Tibbitts (tibbs) 
      * Jesse Keating (f13) 
      * Dennis Gilmore (dgilmore) 
      * Bill Nottingham (notting) 
      * Warren Togami (warren) 
      * Jeremy Katz (jeremy) 
      * Christopher Aillon (caillon) 
      * David Woodhouse (dwmw2) 
      * Christian Iseli (c4chris) 
      * Kevin Fenzi (nirik) 

= Absent =
      * Tom Callaway (spot) 
      * Josh Boyer (jwb) 

= Other Participants =
      * John Poelstra (poelcat) 
      * Will Woods (wwoods) 
      * Matthias Clasen (mclasen) 

= Summary =
== Feature Process ==
      * Long discussion on fixing parts of the Feature Process based on
        F8 experience. Quick & dirty summary (for more details, please
        refer to the irc log): 
        
              * Worked on clarifying definition of 'feature' some more. 
              * Frequency of feature page updates. 1) update is required
                before Beta release. 2) updates are preferred before
                Alpha release. 3) *after* Beta release, updates are
                required every 2 weeks 
              * Features need to be at 100% completion by the release
                schedules final freeze. Sometimes that may entail
                adjusting the feature page to reflect whats going to be
                in the release. 

== Proposed F9 Schedule ==
      * FESCo approved the schedule for F9 proposed by the Release
        Engineering Team.
        http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html 
        

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2007-11-15.html

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/e13b3f43/attachment.sig>

From darth_linux at ameritech.net  Sat Nov 17 02:41:26 2007
From: darth_linux at ameritech.net (eah)
Date: Fri, 16 Nov 2007 21:41:26 -0500
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <20071116154828.GA11383@redhat.com>
References: <200711152056.46958.darth_linux@ameritech.net>
	<20071116154828.GA11383@redhat.com>
Message-ID: <200711162141.27244.darth_linux@ameritech.net>

On Friday 16 November 2007 10:48:29 am John W. Linville wrote:
> On Thu, Nov 15, 2007 at 08:56:46PM -0500, eah wrote:
> > I have the BCM4318 wlan0. b43 driver picks it up after following
> > instructions using  broadcom-wl-4.80.53.0.tar.bz2. It does not active the
> > card's radio (my little blue light stays dark to say it like an end user)
> > . dmesg reports "ADDRCONF(NETDEV_UP): wlan0: link is not ready"
>
> To answer your later question, this is the right firmware.  I am
> presuming that you extracted the firmware already.
>
> > What do I need to do to get that working?
> >
> > This is the farthest I've ever gotten using the stock driver, so kudos to
> > all involved in that.
>
> Are these your only indications?  Did you actually try to activate
> the card using NetworkManager, wpa_supplicant, or iwconfig?
>
I tried iwconfig and could only get essid set. nick would not set neither 
would wlan0 find an access point.

> Regarding the "little blue light", did you try pushing the RF kill
> button?  Sometimes they are a software-controlled toggle rather than
> an actual physical switch.  (Note: don't bother with this without
> trying NetworkManger, et al. first...)

I tried pushing the button because I know it sometimes needs to trigger an 
event, but no joy. 

>
> John
> --
> John W. Linville
> linville at redhat.com




From rhlists at bellsouth.net  Sun Nov 18 01:08:01 2007
From: rhlists at bellsouth.net (Bob)
Date: Sat, 17 Nov 2007 20:08:01 -0500
Subject: Need help reporting a bug on Bugzilla
In-Reply-To: <1195343472.6315.3.camel@kennedy>
References: <1195343472.6315.3.camel@kennedy>
Message-ID: <1195348081.4800.7.camel@J4RDV21>

I plugged my camera (Cannon PowerShot A630) into the USB port as I have
done in the past with no problems.  This time though I got an error
after my camera was successfully recognized.  At the Import Photos
screen the following error shows.

"An error occurred in the io-library ('Could not claim the USB device'):
Could not claim interface 0 (Operation not permitted). Make sure no
other program or kernel module (such as sdc2xx, stv680, spca50x) is
using the device and you have read/write access to the device."

I would like to report it on Bugzilla but I really wasn't sure what
component to select....

P.S.  Seems to be just the camera as I plugged the SD card from the
camera into a USB adapter and was able to pull the images off with no
problems.  I am also not having any issue with my USB sticks either.
Seems to be just an issue with the camera although as I said, I have not
had problems with it in the past...

Thanks

Bob



From dwmw2 at infradead.org  Sun Nov 18 01:30:01 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 17 Nov 2007 20:30:01 -0500
Subject: Need help reporting a bug on Bugzilla
In-Reply-To: <1195348081.4800.7.camel@J4RDV21>
References: <1195343472.6315.3.camel@kennedy> <1195348081.4800.7.camel@J4RDV21>
Message-ID: <1195349401.3220.19.camel@shinybook.infradead.org>

On Sat, 2007-11-17 at 20:08 -0500, Bob wrote:
> I plugged my camera (Cannon PowerShot A630) into the USB port as I have
> done in the past with no problems. 

Please could you explain how this message is relevant to the FESCo
meeting summary, to which you replied?

-- 
dwmw2



From mschwendt.tmp0701.nospam at arcor.de  Sun Nov 18 01:47:53 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 18 Nov 2007 02:47:53 +0100
Subject: Package for Qt-Jambi?
In-Reply-To: <473F2B04.3070907@gmail.com>
References: <473A82FB.9030408@gmail.com>
	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>
	<473D433C.7040502@gmail.com>
	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>
	<473DFC2A.2070609@gmail.com>
	<20071117131642.3a81a1aa.mschwendt.tmp0701.nospam@arcor.de>
	<473F2B04.3070907@gmail.com>
Message-ID: <20071118024753.bf05ba49.mschwendt.tmp0701.nospam@arcor.de>

On Sat, 17 Nov 2007 12:55:16 -0500, Kelly Miller wrote:

> Michael Schwendt wrote:
> > If you control the value of $QTDIR, you also control what $QTDIR/include
> > contains (or points to). I still don't understand where you need root
> > access when you would point $QTDIR to $(pwd)/foo or a other place
> > below $RPM_BUILD_DIR
> Because in order for the system to compile at all, $QTDIR HAS to point 
> at /usr/lib/qt4. 

Why?

> Otherwise the system will incorrectly find the Qt3 
> versions of the Qt tools (qmake, etc.) and error out.

Why? When you redirect QTDIR, why would it do that?

$ rpm -qa 'qt*devel'
qt4-devel-4.3.2-1.fc8

> However, there is 
> no link from /usr/lib/qt4/include to /usr/include, so the system can't 
> find the headers. 

QTDIR is an environment variable, which does not need to point to
/usr/lib/qt4. You can point $QTDIR/include to /usr/include. See below.

> The system, as I said before, is set up on the 
> assumption that everything related to Qt is installed in one folder.  
> This is normal if you download the source directly from Trolltech's 
> website and compile it yourself, but not if you install it via package 
> because of the FHS.  Hence my comment that this is catering to the 
> Windows users (because they'd be in this situation 100% of the time, 
> whereas Mac/Linux/Solaris/BSD users would not).

mkdir $(pwd)/QTDIR
ln -s /usr/include $(pwd)/QTDIR/include
ln -s /usr/lib $(pwd)/QTDIR/lib
ln -s /usr/lib/qt4/bin $(pwd)/QTDIR/bin
export QTDIR=$(pwd)/QTDIR
export JAVADIR=/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0
cd generator
qmake-qt4 
make
./generator
cd -
qtmake-qt4 -r
make
...

At that point I've interrupted the build, but it certainly had started
building hundreds of C++ files using Qt 4 with compiler args that
looked fine.



From alan at redhat.com  Sun Nov 18 01:59:18 2007
From: alan at redhat.com (Alan Cox)
Date: Sat, 17 Nov 2007 20:59:18 -0500
Subject: Need help reporting a bug on Bugzilla
In-Reply-To: <1195348081.4800.7.camel@J4RDV21>
References: <1195343472.6315.3.camel@kennedy> <1195348081.4800.7.camel@J4RDV21>
Message-ID: <20071118015918.GA17272@devserv.devel.redhat.com>

On Sat, Nov 17, 2007 at 08:08:01PM -0500, Bob wrote:
> I would like to report it on Bugzilla but I really wasn't sure what
> component to select....

Guess - a good start would be whichever tools "Import photos" button you
were pressing. Don't worry if you guess wrong, the chances are the owner
will reassign it - and sometimes bugs go for quite a wander until we figure
out the root cause



From marcelo.gobelli at gmail.com  Sun Nov 18 02:36:05 2007
From: marcelo.gobelli at gmail.com (marcelo gobelli)
Date: Sat, 17 Nov 2007 18:36:05 -0800
Subject: information
Message-ID: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>

how can I get involved with the fedora project. I would like to help but I
did not know how. any ideas?
thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/8020b913/attachment.htm>

From braden at endoframe.com  Sun Nov 18 02:46:33 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Sat, 17 Nov 2007 21:46:33 -0500
Subject: i386 packages installed for x86_64
Message-ID: <1195353993.15304.3.camel@hinge.endoframe.net>

Is it appropriate to file bugs for cases of (apparently unnecessary)
i386 packages that are installed by default as part of an x86_64
installation of Fedora 8?

If so, do these generally go against anaconda or the particular package?

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From mauricio at projetofedora.org  Sun Nov 18 02:49:52 2007
From: mauricio at projetofedora.org (Mauricio Pretto)
Date: Sun, 18 Nov 2007 00:49:52 -0200
Subject: i386 packages installed for x86_64
In-Reply-To: <1195353993.15304.3.camel@hinge.endoframe.net>
References: <1195353993.15304.3.camel@hinge.endoframe.net>
Message-ID: <473FA850.8050807@projetofedora.org>

Most of these packages are installed for compatibility .
Can you list the ones you think are unnecessary ?

Pretto
http://fedoraproject.org/wiki/MauricioPretto



Braden McDaniel wrote:
> Is it appropriate to file bugs for cases of (apparently unnecessary)
> i386 packages that are installed by default as part of an x86_64
> installation of Fedora 8?
> 
> If so, do these generally go against anaconda or the particular package?
> 



From rhlists at bellsouth.net  Sun Nov 18 03:00:02 2007
From: rhlists at bellsouth.net (Bob)
Date: Sat, 17 Nov 2007 22:00:02 -0500
Subject: Need help reporting a bug on Bugzilla
In-Reply-To: <20071118015918.GA17272@devserv.devel.redhat.com>
References: <1195343472.6315.3.camel@kennedy> <1195348081.4800.7.camel@J4RDV21>
	<20071118015918.GA17272@devserv.devel.redhat.com>
Message-ID: <1195354802.4800.10.camel@J4RDV21>

On Sat, 2007-11-17 at 20:59 -0500, Alan Cox wrote:
> On Sat, Nov 17, 2007 at 08:08:01PM -0500, Bob wrote:
> > I would like to report it on Bugzilla but I really wasn't sure what
> > component to select....
> 
> Guess - a good start would be whichever tools "Import photos" button you
> were pressing. Don't worry if you guess wrong, the chances are the owner
> will reassign it - and sometimes bugs go for quite a wander until we figure
> out the root cause
> 

Thanks Alan, I went ahead and reported it under gthumb as that is where
the Import Photos dialog comes from.

Thanks again..

Bob



From tibbs at math.uh.edu  Sun Nov 18 03:32:38 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 17 Nov 2007 21:32:38 -0600
Subject: information
In-Reply-To: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
Message-ID: <ufak5ogi5yh.fsf@epithumia.math.uh.edu>

>>>>> "mg" == marcelo gobelli <marcelo.gobelli at gmail.com> writes:

mg> how can I get involved with the fedora project. I would like to
mg> help but I did not know how. any ideas?

Well, it helps to know what you'd like to do.  But you can get some
really good information just by going to the project's web page
http://fedoraproject.org and clicking the "Join Fedora" link.

 - J<



From loganjerry at gmail.com  Sun Nov 18 05:30:27 2007
From: loganjerry at gmail.com (Jerry James)
Date: Sat, 17 Nov 2007 22:30:27 -0700
Subject: Pulseaudio problems
In-Reply-To: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
Message-ID: <870180fe0711172130n138e5c5ftab6f9a3c0011632d@mail.gmail.com>

On Nov 17, 2007 3:35 AM, Paulo Cavalcanti <promac at gmail.com> wrote:

> Sorry if I am writing to the wrong list, but I think this kind of
> information
> can be useful for the developers.
>

While we're at it, here's a couple more.  When I play music with audacious
and then also play Freeciv, when Freeciv should make the sound of gunfire,
it instead makes a hair-raising screech.  Both applications sound fine when
used separately.  Using them together worked with F7.

Also, XEmacs now crashes any time it tries to make a sound:
https://bugzilla.redhat.com/show_bug.cgi?id=378851

As I noted in the bug report, that may be my fault somehow, but if so, I
don't know how.  My code is checking the return value of
snd_pcm_hw_params(), so if something is wrong, it ought to return a negative
number, not crash the whole application.

[james at localhost ~]$ cat /proc/asound/cards
 0 [ICH5           ]: ICH4 - Intel ICH5
                      Intel ICH5 with ALC655 at irq 21

-- 
Jerry James
http://loganjerry.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071117/3e454a29/attachment.htm>

From rc040203 at freenet.de  Sun Nov 18 05:34:18 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Sun, 18 Nov 2007 06:34:18 +0100
Subject: New subpackage xfig-Xaw3d
In-Reply-To: <20071117183209.106320@gmx.net>
References: <20071117095005.128480@gmx.net> <20071117101952.GA2571@free.fr>
	<645d17210711170224p71ae955bn4aa6c6fd5326ec7@mail.gmail.com>
	<473EC471.2040603@hhs.nl> <20071117104651.GB2571@free.fr>
	<20071117124638.148990@gmx.net> <20071117142331.GA2572@free.fr>
	<20071117183209.106320@gmx.net>
Message-ID: <1195364058.28534.199.camel@mccallum.corsepiu.local>


On Sat, 2007-11-17 at 19:32 +0100, Joachim Frieben wrote:
> > Who knows. It is always better to have a fallback known to work.
> > Moreover xfig is different from xdvi.

> Other distros have been using Xaw3d [which must have been around for
> more than a decade now] 
True, but ...

> as standard widget library for xfig for a while already without any
> particular problems.
... this isn't entirely true.

In the past, xfig had exposed quite a couple of compatibility issues
between Xaw3d and Xaw, but ...

... it's been a while since then and xfig and Xaw3d both might have been
improved ... I don't know.

So, IMHO, somebody better should check if these "other distros" have
Xaw3D related patches applied to Xaw3D and/or xfig. IIRC, in the past at
least SuSE had.

Ralf





From lightsolphoenix at gmail.com  Sun Nov 18 06:11:00 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Sun, 18 Nov 2007 01:11:00 -0500
Subject: Package for Qt-Jambi?
In-Reply-To: <20071118024753.bf05ba49.mschwendt.tmp0701.nospam@arcor.de>
References: <473A82FB.9030408@gmail.com>	<32730.195.126.18.254.1195046690.squirrel@www.franks-netz.dyndns.org>	<473D433C.7040502@gmail.com>	<20071116105539.a424c8b5.mschwendt.tmp0701.nospam@arcor.de>	<473DFC2A.2070609@gmail.com>	<20071117131642.3a81a1aa.mschwendt.tmp0701.nospam@arcor.de>	<473F2B04.3070907@gmail.com>
	<20071118024753.bf05ba49.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <473FD774.7050402@gmail.com>

Michael Schwendt wrote:
> mkdir $(pwd)/QTDIR
> ln -s /usr/include $(pwd)/QTDIR/include
> ln -s /usr/lib $(pwd)/QTDIR/lib
> ln -s /usr/lib/qt4/bin $(pwd)/QTDIR/bin
> export QTDIR=$(pwd)/QTDIR
> export JAVADIR=/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0
> cd generator
> qmake-qt4 
> make
> ./generator
> cd -
> qtmake-qt4 -r
> make
> ..
Yep, that did it.  However, it still doesn't finish (the Java compiler 
errors out); when I searched, I found that the openSUSE packagers are 
having the exact same problem, which is apparently a conflict between Qt 
4.3.2 and Qt-Jambi 4.3.2.  I don't know if I can find the error, though.

Note that the Mandriva package uses 4.3.1...



From gilboad at gmail.com  Sun Nov 18 06:46:07 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 18 Nov 2007 08:46:07 +0200
Subject: Wine 0.9.49?
Message-ID: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>

Hello all,

Upstream contains a crucial D3D fix that I need.
Any idea when it's gonna get built?
(I'd build it myself, but I don't have an i386 machine handy and i386 on
x86_64 build - at least AFAIK, is broken)

- Gilboa



From michel.sylvan at gmail.com  Sun Nov 18 06:58:50 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Sun, 18 Nov 2007 01:58:50 -0500
Subject: Wine 0.9.49?
In-Reply-To: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
Message-ID: <f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>

On 18/11/2007, Gilboa Davara <gilboad at gmail.com> wrote:
> Hello all,
>
> (I'd build it myself, but I don't have an i386 machine handy and i386 on
> x86_64 build - at least AFAIK, is broken)
>
You can try a koji scratch build, if you are a Fedora contributor?

koji build --scratch dist-f8 filename.src.rpm

You might have to 'setarch i386' to create the .src.rpm though, and
perhaps delete /etc/rpm/platform

-- 
Michel Salim
http://hircus.jaiku.com/



From sdl.web at gmail.com  Sun Nov 18 07:41:21 2007
From: sdl.web at gmail.com (Leo)
Date: Sun, 18 Nov 2007 07:41:21 +0000
Subject: [pm] Resume hooks not run
Message-ID: <m3wssghufy.fsf@cam.ac.uk>

Hi there,

We I leave my computer inactive until it goes into suspension, the wake
up from the suspension usually fails i.e. it hangs. I have to shut down
the computer by holding the power button. This is tested in a Dell 700m
Laptop.

You can see from the file pm-suspend.log after one of such a failure
that there was no resume hooks being run.

,----[ pm-suspend.log ]
| Sun Nov 18 00:19:57 GMT 2007: running suspend hooks.
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/00clear =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/01grub =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /etc/pm/sleep.d/02hardisk =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/05led =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/10NetworkManager =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/20video =====
| kernel.acpi_video_flags = 0
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/49bluetooth =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/50modules =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/55battery =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/60sysfont =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/65alsa =====
| ===== Sun Nov 18 00:19:59 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/90clock =====
| ===== Sun Nov 18 00:20:00 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/94cpufreq =====
| ===== Sun Nov 18 00:20:00 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/95led =====
| ===== Sun Nov 18 00:20:00 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/99video =====
| Sun Nov 18 00:20:00 GMT 2007: done running suspend hooks.
`----

BTW,

suspension by selecting "suspend" in the battery drop down menu or
logout dialog can resume properly.

Is there any difference between manually selecting "suspend" and
automatically "suspend" when inactive?

They seem behave differently for no reason.

HTH,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/



From gilboad at gmail.com  Sun Nov 18 08:47:10 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 18 Nov 2007 10:47:10 +0200
Subject: Wine 0.9.49?
In-Reply-To: <f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
Message-ID: <1195375630.29118.7.camel@gilboa-home-dev.localdomain>


On Sun, 2007-11-18 at 01:58 -0500, Michel Salim wrote:
> On 18/11/2007, Gilboa Davara <gilboad at gmail.com> wrote:
> > Hello all,
> >
> > (I'd build it myself, but I don't have an i386 machine handy and i386 on
> > x86_64 build - at least AFAIK, is broken)
> >
> You can try a koji scratch build, if you are a Fedora contributor?
> 
> koji build --scratch dist-f8 filename.src.rpm
> You might have to 'setarch i386' to create the .src.rpm though, and
> perhaps delete /etc/rpm/platform


I'm bandwidth limited.
Using koji/mock to build wine will most likely take ~10 hours :(

- Gilboa





From dwmw2 at infradead.org  Sun Nov 18 11:05:57 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 18 Nov 2007 06:05:57 -0500
Subject: i386 packages installed for x86_64
In-Reply-To: <473FA850.8050807@projetofedora.org>
References: <1195353993.15304.3.camel@hinge.endoframe.net>
	<473FA850.8050807@projetofedora.org>
Message-ID: <1195383957.3220.30.camel@shinybook.infradead.org>


Please don't top-post. I've corrected it this time...

On Sun, 2007-11-18 at 00:49 -0200, Mauricio Pretto wrote:
> Braden McDaniel wrote:
> > Is it appropriate to file bugs for cases of (apparently unnecessary)
> > i386 packages that are installed by default as part of an x86_64
> > installation of Fedora 8?
> > 
> > If so, do these generally go against anaconda or the particular package?

The bug already exists, as one of the deps of the multilib tracker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=235756

> Most of these packages are installed for compatibility .

That makes no sense. RPM dependencies exist to ensure that we install
libraries as and when they're actually required. What on earth is the
point in installing these libraries in advance?

Should we unconditionally install every single available library package
for x86_64, and claim that it is "for compatibility"?

> Can you list the ones you think are unnecessary ?

All of them are unnecessary, except the ones which are directly pulled
in as dependencies for an i386.rpm which the user explicitly chooses to
install.

-- 
dwmw2




From jonathan.underwood at gmail.com  Sun Nov 18 11:31:56 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 18 Nov 2007 11:31:56 +0000
Subject: Time skew of packaged files
Message-ID: <645d17210711180331p1c0804fbpeac0a15e045ec8e@mail.gmail.com>

Hi,

I am seeing a problem regarding the way the file mtime seems to be set
when building packages in the build system. Specifically, I am seeing
this problem when building the emacs-vm package, where the building
process compiles Emacs lisp (*.el) files to compiled elisp files
(*.elc). The uncompiled files are packaged in a sub-package
emacs-vm-el, and the byte compiled files, which should be newer than
their uncompiled counterparts, are packaged in emacs-vm. Installing
both emacs-vm and emacs-vm-el packages, I see:

$ ls -l --full-time /usr/share/emacs/site-lisp/vm/vm-version*
-rw-r--r-- 1 root root 5732 2007-10-13 00:44:39.000000000 +0100
/usr/share/emacs/site-lisp/vm/vm-version.el
-rw-r--r-- 1 root root 5559 2007-10-13 00:44:38.000000000 +0100
/usr/share/emacs/site-lisp/vm/vm-version.elc

See how the byte compiled file, which should be newer, has an older
mtime than the uncompiled file? This is causing Emacs to ignore the
byte compiled files.

Am I doing something dumb when building the packages, or is there a
buildsystem problem?

Thanks,
Jonathan



From eric.tanguy at univ-nantes.fr  Sun Nov 18 11:41:11 2007
From: eric.tanguy at univ-nantes.fr (Tanguy Eric)
Date: Sun, 18 Nov 2007 12:41:11 +0100
Subject: Package maintenance
Message-ID: <1195386071.2845.4.camel@bureau.maison>

I'm the maintainer of ushare (UPnP (TM) A/V Media Server) which use
libupnp. A new version (1.1) will be out soon and this version use a new
lib http://libdlna.geexbox.org/ which need ffmpeg-devel.ffmpeg is part
of livna repo because it is not free i guess. So i will have to port
libdlna and ushare to livna because it use a non free package ?
Thanks

Eric




From lordmorgul at gmail.com  Sun Nov 18 11:44:41 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Sun, 18 Nov 2007 03:44:41 -0800
Subject: Time skew of packaged files
In-Reply-To: <645d17210711180331p1c0804fbpeac0a15e045ec8e@mail.gmail.com>
References: <645d17210711180331p1c0804fbpeac0a15e045ec8e@mail.gmail.com>
Message-ID: <474025A9.3090802@gmail.com>

Jonathan Underwood wrote:
> See how the byte compiled file, which should be newer, has an older
> mtime than the uncompiled file? This is causing Emacs to ignore the
> byte compiled files.

Is the spec file including the compiled file before the uncompiled file?
Copying the files to temp during the build may be whats causing that time issue.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From lkundrak at redhat.com  Sun Nov 18 11:50:56 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 18 Nov 2007 12:50:56 +0100
Subject: Package maintenance
In-Reply-To: <1195386071.2845.4.camel@bureau.maison>
References: <1195386071.2845.4.camel@bureau.maison>
Message-ID: <1195386656.29805.50.camel@localhost.localdomain>


On Sun, 2007-11-18 at 12:41 +0100, Tanguy Eric wrote:
> I'm the maintainer of ushare (UPnP (TM) A/V Media Server) which use
> libupnp. A new version (1.1) will be out soon and this version use a new
> lib http://libdlna.geexbox.org/ which need ffmpeg-devel.ffmpeg is part
> of livna repo because it is not free i guess. So i will have to port
> libdlna and ushare to livna because it use a non free package ?

Your guess is right. You can either attempt to maintian the older
package without the dependency on patent enucmbered software, or modify
the new package not to depend on it.

If you want to provide the newer version with ffmpeg support, I guess
the rpmfusion project will accept it.

Regards,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lkundrak at redhat.com  Sun Nov 18 11:55:08 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 18 Nov 2007 12:55:08 +0100
Subject: Pulseaudio problems
In-Reply-To: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
Message-ID: <1195386909.29805.53.camel@localhost.localdomain>


On Sat, 2007-11-17 at 08:35 -0200, Paulo Cavalcanti wrote:
> Hi,
> 
> I am trying to adapt myself to pulseaudio (F8 x86_64).
> 
> I had to change /etc/security/console.perms.d/50-default.perms
> so I can use another X screen (:1) without being root, and  without
> using pulse.
> Otherwise, I hear no sound using mplayer (this is how I send a movie
> to an ordinary TV).
> 
> After testing several applications, this is what I got so far 
> trying to use pulseaudio with plugins (not using alsa generic
> plugin): 
> 
> MythTV: NO sound at all (therefore, pulse can not be a global default
> for me) 
> mplayer (patched): OK
> mplayerplug-in: OK
> rhythmbox: OK
> amarok: OK
> xmms: OK
> audacious 1.4: OK with ESD (stutters a lot with its own pulse plugin).
> mpd 0.13: NO sound (it has the plugin, though).
> ampache (flash player): OK 
> xine: NO. Sound disappears after a few seconds. 
> vlc: NO plugin available.
> 
> Also, after an interval of time of maybe 10 to 20 min I hear a fast
> hiccup
> using amarock. I mean, the sound vanishes (but it is very fast), and
> it will happen
> again 10 min later, and so on... 
> 
> I also noticed that using 
> 
> arecord -D hw:0.0 -d 0 -f S16_LE -c2 -r48000 | aplay -D pulse &
> 
> for capturing from line in.
> 
> I have two sound cards:
> 
> [cascavel:~/SRPMS/vlc]   more /proc/asound/cards 
> 
>  0 [Intel          ]: HDA-Intel - HDA Intel
>                       HDA Intel at 0x92300000 irq 22
>  1 [VirMIDI        ]: VirMIDI - VirMIDI
>                       Virtual MIDI Card 1
>  2 [Bt878          ]: Bt87x - Brooktree Bt878 
>                       Brooktree Bt878 at 0x92000000, irq 18
>  3 [CMI8738        ]: CMI8738-MC6 - C-Media CMI8738
>                       C-Media CMI8738 (model 55) at 0x1000, irq 21
> 
> The good part, is that I can switch between sound cards very easily
> and 
> switch users and resume what I was playing before in gnome.
> 
> Sorry if I am writing to the wrong list, but I think this kind of
> information
> can be useful for the developers.

Bugzilla [1] will definitel be a more appropriate place than a mailing
list. Please file a bug report there.

[1] http://bugzilla.redhat.com/

Thanks,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From debarshi.ray at gmail.com  Sun Nov 18 12:02:44 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 18 Nov 2007 17:32:44 +0530
Subject: Wine 0.9.49?
In-Reply-To: <1195375630.29118.7.camel@gilboa-home-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
Message-ID: <3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>

> I'm bandwidth limited.
> Using koji/mock to build wine will most likely take ~10 hours :(

I can understand that with Mock, but why would Koji be a problem? You
only need to upload the src.rpm you want to build. You don't need to
download the dependencies.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From kwizart at gmail.com  Sun Nov 18 12:15:31 2007
From: kwizart at gmail.com (KH KH)
Date: Sun, 18 Nov 2007 13:15:31 +0100
Subject: Package maintenance
In-Reply-To: <1195386071.2845.4.camel@bureau.maison>
References: <1195386071.2845.4.camel@bureau.maison>
Message-ID: <e1760170711180415j404d6ec2v9b0a308e709eaa0a@mail.gmail.com>

2007/11/18, Tanguy Eric <eric.tanguy at univ-nantes.fr>:
> I'm the maintainer of ushare (UPnP (TM) A/V Media Server) which use
> libupnp. A new version (1.1) will be out soon and this version use a new
> lib http://libdlna.geexbox.org/ which need ffmpeg-devel.ffmpeg is part
> of livna repo because it is not free i guess. So i will have to port
> libdlna and ushare to livna because it use a non free package ?
ffmpeg is patent encumbered but it is free software... So it will be
available in the free section of RPM Fusion...
If this new package is optional from ushare then you might need to
provide it with as a plugin for ushare somehow...

Please join http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-developers
And we will see how to prevent replacing ushare package..

Nicolas (kwizart )

> Thanks
>
> Eric
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From trever.adams at gmail.com  Sun Nov 18 12:33:29 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Sun, 18 Nov 2007 05:33:29 -0700
Subject: Suggestions for F9
In-Reply-To: <1195199626.24749.93.camel@animal.passback.co.uk>
References: <1195196211.3144.1.camel@aragorn>
	<1195199626.24749.93.camel@animal.passback.co.uk>
Message-ID: <1195389209.3154.1.camel@aragorn>


On Fri, 2007-11-16 at 07:53 +0000, Keith Sharp wrote:

> I agree that a CalDAV compliant calendaring server would be a great
> addition to Fedora, but is the Darwin Calendar Server the best one to
> focus attention on?  As far as I am aware there are at least three other
> servers we could consider:
> 
> 	http://www.bedework.org/bedework/
> 	http://chandlerproject.org/
> 	http://rscds.sourceforge.net/
> 
> I am not following development of any of these, so I cannot comment on
> which would be best for Fedora, but it would be worth doing a review
> before focusing on one implementation.
> 
> Keith.
> 

Keith,

I had seen these before. I do not think I want chandler or rscds. The
later doesn't fully implement the protocol yet. It may never do so.
Chandler seems much too heavy.

Bedework may be a win. It may actually be better than Darwin Calendar
(which is what I suggested).

Anyone have any ideas on which would be best?

Trever

--
"Life is what happens to you when you're busy making other plans." --
John Lennon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/d35e9f87/attachment.sig>

From trever.adams at gmail.com  Sun Nov 18 12:34:45 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Sun, 18 Nov 2007 05:34:45 -0700
Subject: Suggestions for F9
In-Reply-To: <473D4F46.8080100@hhs.nl>
References: <1195196211.3144.1.camel@aragorn>  <473D4F46.8080100@hhs.nl>
Message-ID: <1195389285.3154.4.camel@aragorn>


On Fri, 2007-11-16 at 09:05 +0100, Hans de Goede wrote:
> Trever,
> 
> Thanks for this, I think those are good suggestions. However most Fedora 
> developers are already carying a pretty full workload as is. Have you 
> considered becoming a contributer yourself? I'm more then willing to guide you 
> on your initial steps, note I'm both an experienced packager and an experienced 
> (certified even) teacher.
> 
> Regards,
> 
> Hans
> 

I think I may be interested in this. Can you give me a few more days
(possibly until December 1, 2007) to think this through and make sure I
have what it takes? I stink with CVS. I am a decent programmer, but I
haven't learned CVS and am trying to learn git.

Thanks,
Trever
--
"Honor isn't about making the right choices. It's about dealing with the
consequences." -- Midori Koto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/4c4578f9/attachment.sig>

From jonathan.underwood at gmail.com  Sun Nov 18 12:44:10 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 18 Nov 2007 12:44:10 +0000
Subject: Time skew of packaged files
In-Reply-To: <474025A9.3090802@gmail.com>
References: <645d17210711180331p1c0804fbpeac0a15e045ec8e@mail.gmail.com>
	<474025A9.3090802@gmail.com>
Message-ID: <645d17210711180444k4151c4b3ma4b4d7255ac474b9@mail.gmail.com>

On 18/11/2007, Andrew Farris <lordmorgul at gmail.com> wrote:
> Jonathan Underwood wrote:
> > See how the byte compiled file, which should be newer, has an older
> > mtime than the uncompiled file? This is causing Emacs to ignore the
> > byte compiled files.
>
> Is the spec file including the compiled file before the uncompiled file?

Hm. By "including", do you mean "appearing in a %files section"? If
so, then yes, in the spec file the %files section for emacs-vm appears
above that for emacs-vm-el. But if this is what determines the file
mtimes, I think that's misguided (and undocumented afaik)  behaviour.

> Copying the files to temp during the build may be whats causing that time issue.
>

Perhaps so. Naively, what I would've expected to happen is that, for
any package and subpackages, all the file mtimes are set to be the
same.

J.
> --
> Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
>    gpg 0xC99B1DF3 at pgp.mit.edu
>
> No one now has, and no one will ever again get, the big picture. - Daniel Geer
> ----                                                                       ----
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From gajownik at gmail.com  Sun Nov 18 12:49:56 2007
From: gajownik at gmail.com (Dawid Gajownik)
Date: Sun, 18 Nov 2007 13:49:56 +0100
Subject: python-abi and gajim
Message-ID: <474034F4.6060306@gmail.com>

Hi!
	problem with python-abi and koji was previously discussed on this list 
[1]. Unfortunately, I cannot get rid of "Requires: python-abi" from the 
spec file, because RPM does not automatically add this dependency. It 
happens only with gajim package. May someone suggest me how to fix it, 
please?

http://koji.fedoraproject.org/koji/taskinfo?taskID=246566
http://koji.fedoraproject.org/koji/getfile?taskID=246570&name=root.log

Packages can be found here: http://gajownik.fedorapeople.org/gajim/

[1] 
http://www.redhat.com/archives/fedora-devel-list/2007-August/msg00500.html

Regards,
	Dawid
-- 

   ^_*



From kwizart at gmail.com  Sun Nov 18 12:54:46 2007
From: kwizart at gmail.com (KH KH)
Date: Sun, 18 Nov 2007 13:54:46 +0100
Subject: Pulseaudio problems
In-Reply-To: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
Message-ID: <e1760170711180454r4fde7ff3ic8601127dacad80d@mail.gmail.com>

2007/11/17, Paulo Cavalcanti <promac at gmail.com>:
> Hi,
>
> I am trying to adapt myself to pulseaudio (F8 x86_64).
>
> I had to change
> /etc/security/console.perms.d/50-default.perms
> so I can use another X screen (:1) without being root, and  without using
> pulse.
>  Otherwise, I hear no sound using mplayer (this is how I send a movie to an
> ordinary TV).
>
> After testing several applications, this is what I got so far
> trying to use pulseaudio with plugins (not using alsa generic plugin):
>
> MythTV: NO sound at all (therefore, pulse can not be a global default for
> me)
> mplayer (patched): OK
> mplayerplug-in: OK
> rhythmbox: OK
> amarok: OK
> xmms: OK
> audacious 1.4: OK with ESD (stutters a lot with its own pulse plugin).
> mpd 0.13: NO sound (it has the plugin, though).
> ampache (flash player): OK
> xine: NO. Sound disappears after a few seconds.
> vlc: NO plugin available.
vlc can uses the ESoundD plugins (if compiled in) - the livna version
has it, and raised it to be tried by default with Fedora 8... But...,
some users reported crackles noises when used with PA see livna bug
#1711...
This tweak seems to solve the problem: (need to confirm: works for me)
http://www.pulseaudio.org/wiki/PerfectSetup#ESOUNDApplications
Add this to your .bashrc:
if [ ! -e /tmp/.esd-${UID} ]; then
        ln -fs /tmp/.esd /tmp/.esd-${UID}
fi

Nicolas (kwizart )


Solution consist to add this lines to your .bashrc : (seen
if [ ! -e /tmp/.esd-${UID} ]; then
        ln -s /tmp/.esd /tmp/.esd-${UID}
fi

That

>
> Also, after an interval of time of maybe 10 to 20 min I hear a fast hiccup
> using amarock. I mean, the sound vanishes (but it is very fast), and it will
> happen
> again 10 min later, and so on...
>
> I also noticed that using
>
> arecord -D hw:0.0 -d 0 -f S16_LE -c2 -r48000 | aplay -D pulse &
>
> for capturing from line in.
>
> I have two sound cards:
>
> [cascavel:~/SRPMS/vlc]   more /proc/asound/cards
>
>  0 [Intel          ]: HDA-Intel - HDA Intel
>                       HDA Intel at 0x92300000 irq 22
>  1 [VirMIDI        ]: VirMIDI - VirMIDI
>                       Virtual MIDI Card 1
>  2 [Bt878          ]: Bt87x - Brooktree Bt878
>                       Brooktree Bt878 at 0x92000000, irq 18
>  3 [CMI8738        ]: CMI8738-MC6 - C-Media CMI8738
>                       C-Media CMI8738 (model 55) at 0x1000, irq 21
>
> The good part, is that I can switch between sound cards very easily and
> switch users and resume what I was playing before in gnome.
>
> Sorry if I am writing to the wrong list, but I think this kind of
> information
> can be useful for the developers.
>
> Thank you.
>
>  --
> Paulo Roma Cavalcanti
> LCG - UFRJ
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From ville.skytta at iki.fi  Sun Nov 18 13:55:45 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 18 Nov 2007 15:55:45 +0200
Subject: python-abi and gajim
In-Reply-To: <474034F4.6060306@gmail.com>
References: <474034F4.6060306@gmail.com>
Message-ID: <200711181555.45525.ville.skytta@iki.fi>

On Sunday 18 November 2007, Dawid Gajownik wrote:
> Hi!
> 	problem with python-abi and koji was previously discussed on this list
> [1]. Unfortunately, I cannot get rid of "Requires: python-abi" from the
> spec file, because RPM does not automatically add this dependency.

Why is it needed?  gajim doesn't install any files into /usr/lib*/pythonX.Y 
dirs (which is what python-abi = X.Y and python(abi) = X.Y are about) so 
plain "Requires: python" should suffice.



From fedora at leemhuis.info  Sun Nov 18 14:11:00 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 18 Nov 2007 15:11:00 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195247727.29478.6.camel@space-ghost.verbum.private>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>	<1195222693.3238.11.camel@localhost.localdomain>	<1195226289.3002.4.camel@localhost.localdomain>	<1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
Message-ID: <474047F4.5000508@leemhuis.info>

On 16.11.2007 22:15, Colin Walters wrote:
> On Fri, 2007-11-16 at 20:07 +0100, Thorsten Leemhuis wrote:
> 
>> With grep, sed, cvs diff and some small adjustments by hand this change
>> could also be done quickly in CVS for all effected packages. I could
>> start now and will likely finished the task for all packages in devel
>> within less then 30 minutes. But nobody does that, as modifying packages
>> that are owned by other people is frowned upon in Fedora land.
>> Such changes therefor often take years to get realized in practice. Is
>> that what we want?
> No; automating these kinds of things is exactly where Fedora should be
> going.  

Well, I had no script (besides the bumpspecfile one found at
http://cvs.fedora.redhat.com/viewcvs/rebuild-scripts/bumpspecfile.py?root=fedora&view=markup
) and thus did most of it manually, as writing a script for this sort of
one-time change is likely not worth the trouble.

Results from my work:
http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls.diff

@FESCo: so what do do with this? Commit and don't build? The package
owners should see the commit diff and spot errors if I did any.

> I think we very much want a model based on peer review, collective
> ownership and automation, not personal fiefdoms and manual integer
> increments in text files.

+1, ecpecially to "collective ownership and automation"

> [...]

CU
knurd



From gilboad at gmail.com  Sun Nov 18 14:15:49 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 18 Nov 2007 16:15:49 +0200
Subject: Wine 0.9.49?
In-Reply-To: <3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
Message-ID: <1195395349.29118.18.camel@gilboa-home-dev.localdomain>


On Sun, 2007-11-18 at 17:32 +0530, Debarshi 'Rishi' Ray wrote:
> > I'm bandwidth limited.
> > Using koji/mock to build wine will most likely take ~10 hours :(
> 
> I can understand that with Mock, but why would Koji be a problem? You
> only need to upload the src.rpm you want to build. You don't need to
> download the dependencies.
> 
> Cheers,
> Debarshi
> -- 
> GPG key ID: 63D4A5A7
> Key server: pgp.mit.edu
> 

... I assume you mean koji client, right?
I may be wrong... but wouldn't this mean that I'm using fedora servers
as my build-sys? (As I normally do with the packages that I maintain?)

- Gilboa






From gajownik at gmail.com  Sun Nov 18 14:29:02 2007
From: gajownik at gmail.com (Dawid Gajownik)
Date: Sun, 18 Nov 2007 15:29:02 +0100
Subject: python-abi and gajim
In-Reply-To: <200711181555.45525.ville.skytta@iki.fi>
References: <474034F4.6060306@gmail.com>
	<200711181555.45525.ville.skytta@iki.fi>
Message-ID: <47404C2E.1080005@gmail.com>

Dnia 11/18/2007 02:56 PM, U?ytkownik Ville Skytt? napisa?:
> Why is it needed?  gajim doesn't install any files into /usr/lib*/pythonX.Y 
> dirs (which is what python-abi = X.Y and python(abi) = X.Y are about) so 
> plain "Requires: python" should suffice.

Without python-abi thing you can install rpm for F8 on FC-6 system and 
you'll get this kind of errors:

/usr/share/gajim/src/dialogs.py:31: RuntimeWarning: Python C API version 
mismatch for module gtkspell: This Python has API version 1012, module 
gtkspell has version 1013.
   import gtkspell

Regards,
	Dawid

-- 

   ^_*




From debarshi.ray at gmail.com  Sun Nov 18 14:34:16 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 18 Nov 2007 20:04:16 +0530
Subject: Wine 0.9.49?
In-Reply-To: <1195395349.29118.18.camel@gilboa-home-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
Message-ID: <3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>

> but wouldn't this mean that I'm using fedora servers
> as my build-sys? (As I normally do with the packages that I maintain?)

Yes.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From jkeating at redhat.com  Sun Nov 18 14:45:06 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 18 Nov 2007 09:45:06 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <474047F4.5000508@leemhuis.info>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>
Message-ID: <20071118094506.5216b37d@redhat.com>

On Sun, 18 Nov 2007 15:11:00 +0100
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> Results from my work:
> http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls.diff
> 
> @FESCo: so what do do with this? Commit and don't build? The package
> owners should see the commit diff and spot errors if I did any.

I have no problem with that, so long as the Fonts SIG is happy with the
change.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/8f802e2f/attachment.sig>

From buildsys at redhat.com  Sun Nov 18 15:14:41 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 18 Nov 2007 10:14:41 -0500
Subject: rawhide report: 20071118 changes
Message-ID: <200711181514.lAIFEfsZ030342@porkchop.devel.redhat.com>

New package fxload
	A helper program to download firmware into FX and FX2 EZ-USB devices

New package gnome-theme-curvylooks
	A modern Clearlooks theme using a Bluecurve-like color scheme

New package python-cerealizer
	Secure pickle-like module

New package ruby-imagesize
	Measure image size code by Pure Ruby

New package starplot
	3-dimensional perspective star map viewer

New package swfdec
	Flash animation rendering library


 
Updated Packages:

control-center-1:2.21.2-2.fc9
-----------------------------
* Sun Nov 18 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-2
- Spec file cleanups

curl-7.17.1-1.fc9
-----------------
* Sat Nov 17 2007 Jindrich Novy <jnovy at redhat.com> 7.17.1-1
- update to curl 7.17.1
- include patch to enable SSL usage in NSS when a socket is opened
  nonblocking, thanks to Rob Crittenden (rcritten at redhat.com)

* Wed Oct 24 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-10
- correctly provide/obsolete curl-devel (#130251)

* Wed Oct 24 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-9
- create libcurl and libcurl-devel subpackages (#130251)

echo-icon-theme-0.3.1-1.fc9
---------------------------
* Sat Nov 17 2007 Martin Sourada <martin.sourada> - 0.3.1-1
- add missing requires
- new version
 - fixes rhbz #333231
 - adds new icons

gnome-applet-sensors-1.8.1-5.fc9
--------------------------------
* Mon Nov 12 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.8.1-5
- Patch and rebuild for new lm_sensors-3.0.0

gnome-do-0.0.2-2.fc9
--------------------

hicolor-icon-theme-0.10-4
-------------------------
* Sun Nov 18 2007 Matthias Clasen <mclasen at redhat.com> - 0.10-4
- Correct the license
- Include COPYING
- Add full source url

* Tue Aug 07 2007 Matthias Clasen <mclasen at redhat.com> - 0.10-3
- Update the license field

hyperestraier-1.4.11-1.fc9
--------------------------
* Sat Nov 17 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.11-1
- 1.4.11

icon-naming-utils-0.8.6-2.fc9
-----------------------------
* Sun Nov 18 2007 Matthias Clasen <mclasen at redhat.com> - 0.8.6-2
- Use a standard group to placate rpmlint

ipe-6.0-0.22.pre28.fc9
----------------------
* Sat Nov 17 2007 Laurent Rineau <laurent.rineau__fedora at normalesup.org> - 6.0-0.22.pre28.fc9
- Make ipe use xdg-open (from package xdg-utils), instead of htmlview.

* Mon Sep 17 2007 Laurent Rineau <laurent.rineau__fedora at normalesup.org> - 6.0-0.21.pre28.fc9
- New upstream patch.

* Mon Aug 27 2007 Laurent Rineau <laurent.rineau__fedora at normalesup.org> - 6.0-0.20.pre28.fc9
- Change the URL, in Source0.

jd-1.9.7-0.4.svn1528.fc9
------------------------
* Sat Nov 17 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.svn1528
- svn 1528

* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

kdebase-6:3.5.8-8.fc9
---------------------
* Sat Nov 17 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-8
- disable lm_sensors f9+ for now (new lm_sensors api-incompat)

* Wed Oct 31 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 6:3.5.8-6
- apply GDM socket path patch only on F8+

ksensors-0.7.3-14.fc9
---------------------
* Sun Nov 11 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.7.3-14
- Patch for and Rebuild against lm_sensors-3.0.0

* Sun Nov 11 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.7.3-13
- Fix reading of min and max tresholds from libsensors

lm_sensors-3.0.0-0.1.rc3.fc9
----------------------------
* Sat Nov 10 2007 Hans de Goede <j.w.r.degoede at hhs.nl> - 3.0.0-0.1.rc3
- New upstream release 3.0.0-rc3
- Remove eeprommer sub-package as eeprommer (and the other i2c-tools)
  have moved to the new i2c-tools package

perl-Class-MOP-0.45-1.fc9
-------------------------
* Sat Nov 17 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.45-1
- update to 0.45
- adapt to Module::Install style

qdbm-1.8.77-1.fc9
-----------------
* Sat Nov 17 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.77-1
- 1.8.77

rhythmbox-0.11.3-4.fc9
----------------------
* Sat Nov 17 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.3-4
- Better DAAP fix (#382351)

tla-1.3.5-2.fc9
---------------

wmx-6pl1-16.fc9
---------------
* Sat Nov 17 2007 Gabriel Somlo <somlo at cmu.edu> 6pl1-16
- rebuild

wqy-bitmap-fonts-0.9.9-1.fc9
----------------------------
* Sat Nov 17 2007 Qianqian Fang <fangqq at gmail.com> 0.9.9-1
- avoid using Latin glyphs from this font in monospace environment such as in consoles

xchat-gnome-0.18-6.fc9
----------------------
* Sat Nov 17 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.18-6
- Add patch to fix away/back command.

xfig-3.2.5-6.fc9
----------------
* Sat Nov 17 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 3.2.5-6
- Put the Xaw3d version in the main xfig package, put the plain Xaw version
  in a -plain subpackage

yum-presto-0.4.3-1.fc9
----------------------
* Sat Nov 17 2007 Jonathan Dieter <jdieter at gmail.com> - 0.4.3-1
- Fix README so it is now accurate for 0.4.x
- Fix a small bug that caused AVC denials when SELinux is enabled

Broken deps for i386
----------------------------------------------------------
	gkrellm - 2.3.0-4.fc8.i386 requires libsensors.so.3
	gkrellm-daemon - 2.3.0-4.fc8.i386 requires libsensors.so.3
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	net-snmp - 1:5.4.1-5.fc9.i386 requires libsensors.so.3
	net-snmp-libs - 1:5.4.1-5.fc9.i386 requires libsensors.so.3
	poker3d-data - 1.1.36-3.fc9.noarch requires poker3d >= 0:1.1.36
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3



Broken deps for x86_64
----------------------------------------------------------
	gkrellm - 2.3.0-4.fc8.x86_64 requires libsensors.so.3()(64bit)
	gkrellm-daemon - 2.3.0-4.fc8.x86_64 requires libsensors.so.3()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	net-snmp - 1:5.4.1-5.fc9.x86_64 requires libsensors.so.3()(64bit)
	net-snmp-libs - 1:5.4.1-5.fc9.x86_64 requires libsensors.so.3()(64bit)
	net-snmp-libs - 1:5.4.1-5.fc9.i386 requires libsensors.so.3
	poker3d-data - 1.1.36-3.fc9.noarch requires poker3d >= 0:1.1.36
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	boo - 0.7.6.2237-12.fc7.ppc requires mono(NAnt.Core) = 0:0.85.2478.0
	boo - 0.7.6.2237-12.fc7.ppc requires mono(NAnt.DotNetTasks) = 0:0.85.2478.0
	gkrellm - 2.3.0-4.fc8.ppc requires libsensors.so.3
	gkrellm-daemon - 2.3.0-4.fc8.ppc requires libsensors.so.3
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	net-snmp - 1:5.4.1-5.fc9.ppc requires libsensors.so.3
	net-snmp-libs - 1:5.4.1-5.fc9.ppc requires libsensors.so.3
	net-snmp-libs - 1:5.4.1-5.fc9.ppc64 requires libsensors.so.3()(64bit)
	poker3d-data - 1.1.36-3.fc9.noarch requires poker3d >= 0:1.1.36
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3



Broken deps for ppc64
----------------------------------------------------------
	gkrellm - 2.3.0-4.fc8.ppc64 requires libsensors.so.3()(64bit)
	gkrellm-daemon - 2.3.0-4.fc8.ppc64 requires libsensors.so.3()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	net-snmp - 1:5.4.1-5.fc9.ppc64 requires libsensors.so.3()(64bit)
	net-snmp-libs - 1:5.4.1-5.fc9.ppc64 requires libsensors.so.3()(64bit)
	poker3d-data - 1.1.36-3.fc9.noarch requires poker3d >= 0:1.1.36
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)





From gilboad at gmail.com  Sun Nov 18 15:31:05 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 18 Nov 2007 17:31:05 +0200
Subject: Wine 0.9.49?
In-Reply-To: <3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
Message-ID: <1195399865.29118.22.camel@gilboa-home-dev.localdomain>

On Sun, 2007-11-18 at 20:04 +0530, Debarshi 'Rishi' Ray wrote:
> > but wouldn't this mean that I'm using fedora servers
> > as my build-sys? (As I normally do with the packages that I maintain?)
> 
> Yes.
> 

Doesn't look like an idea solution...
I doubt the Fedora's konji servers were designed to serve as "free"
build servers.

I should really take the time to learn how to set proper caching w/
mock. But thus far, I didn't really have the time to do so.

- Gilboa



From dan at danny.cz  Sun Nov 18 15:51:50 2007
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sun, 18 Nov 2007 16:51:50 +0100
Subject: Wine 0.9.49?
In-Reply-To: <1195399865.29118.22.camel@gilboa-home-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
	<1195399865.29118.22.camel@gilboa-home-dev.localdomain>
Message-ID: <1195401110.3245.5.camel@eagle.danny.cz>


Gilboa Davara p??e v Ne 18. 11. 2007 v 17:31 +0200:
> On Sun, 2007-11-18 at 20:04 +0530, Debarshi 'Rishi' Ray wrote:
> > > but wouldn't this mean that I'm using fedora servers
> > > as my build-sys? (As I normally do with the packages that I maintain?)
> > 
> > Yes.
> > 
> 
> Doesn't look like an idea solution...
> I doubt the Fedora's konji servers were designed to serve as "free"
> build servers.
> 

They are not free, but for package maintainer it is possible to use the
"scratch" build method for testing etc. The created packages are deleted
after some time.

> I should really take the time to learn how to set proper caching w/
> mock. But thus far, I didn't really have the time to do so.
> 

My internet connection is limited to, so I have used
http://fedoraproject.org/wiki/PackageMaintainers/MockTricks to setup a
squid cache for mock. It really works :-)


		Dan




From ville.skytta at iki.fi  Sun Nov 18 16:53:03 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 18 Nov 2007 18:53:03 +0200
Subject: python-abi and gajim
In-Reply-To: <47404C2E.1080005@gmail.com>
References: <474034F4.6060306@gmail.com>
	<200711181555.45525.ville.skytta@iki.fi>
	<47404C2E.1080005@gmail.com>
Message-ID: <200711181853.03475.ville.skytta@iki.fi>

On Sunday 18 November 2007, Dawid Gajownik wrote:
> Dnia 11/18/2007 02:56 PM, U?ytkownik Ville Skytt? napisa?:
> > Why is it needed?  gajim doesn't install any files into
> > /usr/lib*/pythonX.Y dirs (which is what python-abi = X.Y and python(abi)
> > = X.Y are about) so plain "Requires: python" should suffice.
>
> Without python-abi thing you can install rpm for F8 on FC-6 system and
> you'll get this kind of errors:
>
> /usr/share/gajim/src/dialogs.py:31: RuntimeWarning: Python C API version
> mismatch for module gtkspell: This Python has API version 1012, module
> gtkspell has version 1013.
>    import gtkspell

One way around that could be to install into the versioned python 
site-packages dirs (/usr/lib*/pythonX.Y/site-packages) instead of gajim's 
private ones, that way the automatic python(abi) stuff should work too.



From jonathan.roberts.uk at googlemail.com  Sun Nov 18 16:57:55 2007
From: jonathan.roberts.uk at googlemail.com (Jonathan Roberts)
Date: Sun, 18 Nov 2007 16:57:55 +0000
Subject: Non-verbose/grapchical shutdown
In-Reply-To: <200711181853.03475.ville.skytta@iki.fi>
References: <474034F4.6060306@gmail.com>
	<200711181555.45525.ville.skytta@iki.fi> <47404C2E.1080005@gmail.com>
	<200711181853.03475.ville.skytta@iki.fi>
Message-ID: <1195405075.2691.5.camel@localhost.localdomain>

Hi,

I asked on this list a while ago if it was possible to have a
non-verbose or graphical shutdown and a few people seemed
interested...wondered if anybody had thought of taking it any further?

Best wishes,

Jon



From Michael_E_Brown at dell.com  Sun Nov 18 17:07:32 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Sun, 18 Nov 2007 11:07:32 -0600
Subject: Wine 0.9.49?
In-Reply-To: <1195399865.29118.22.camel@gilboa-home-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
	<1195399865.29118.22.camel@gilboa-home-dev.localdomain>
Message-ID: <20071118170731.GB6174@humbolt.us.dell.com>

On Sun, Nov 18, 2007 at 05:31:05PM +0200, Gilboa Davara wrote:
> On Sun, 2007-11-18 at 20:04 +0530, Debarshi 'Rishi' Ray wrote:
> > > but wouldn't this mean that I'm using fedora servers
> > > as my build-sys? (As I normally do with the packages that I maintain?)
> > 
> > Yes.
> > 
> 
> Doesn't look like an idea solution...
> I doubt the Fedora's konji servers were designed to serve as "free"
> build servers.
> 
> I should really take the time to learn how to set proper caching w/
> mock. But thus far, I didn't really have the time to do so.

Mock 0.8.x is set up to cache automatically. It caches the downloaded
RPMs as well as your buildroot. No additional configuration necessary.

For your situation, you probably should set the timeout on the
downloaded yum packages much higher. It defaults to re-download pkgs
after 30 days, you can safely set that to be higher.
--
Michael



From gajownik at gmail.com  Sun Nov 18 17:06:09 2007
From: gajownik at gmail.com (Dawid Gajownik)
Date: Sun, 18 Nov 2007 18:06:09 +0100
Subject: python-abi and gajim
In-Reply-To: <200711181853.03475.ville.skytta@iki.fi>
References: <474034F4.6060306@gmail.com>	<200711181555.45525.ville.skytta@iki.fi>	<47404C2E.1080005@gmail.com>
	<200711181853.03475.ville.skytta@iki.fi>
Message-ID: <47407101.5070607@gmail.com>

Dnia 11/18/2007 05:53 PM, U?ytkownik Ville Skytt? napisa?:
> One way around that could be to install into the versioned python 
> site-packages dirs (/usr/lib*/pythonX.Y/site-packages) instead of gajim's 
> private ones, that way the automatic python(abi) stuff should work too.

Thanks, I'll try to fix it.

Regards,
	Dawid

-- 

   ^_*




From Michael_E_Brown at dell.com  Sun Nov 18 17:10:29 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Sun, 18 Nov 2007 11:10:29 -0600
Subject: Wine 0.9.49?
In-Reply-To: <1195401110.3245.5.camel@eagle.danny.cz>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
	<1195399865.29118.22.camel@gilboa-home-dev.localdomain>
	<1195401110.3245.5.camel@eagle.danny.cz>
Message-ID: <20071118171029.GC6174@humbolt.us.dell.com>

On Sun, Nov 18, 2007 at 04:51:50PM +0100, Dan Hor?k wrote:
> My internet connection is limited to, so I have used
> http://fedoraproject.org/wiki/PackageMaintainers/MockTricks to setup a
> squid cache for mock. It really works :-)

You might want to take a look at the mock 0.8.x yum caching. With the
yum cache, it is likely that you would not need the squid cache anymore.
The only thing that is re-downloaded is the yum metadata, if it changes.
This is enabled by default, and you can safely set the timeout on it to
be as high as you like.

--
Michael



From braden at endoframe.com  Sun Nov 18 17:16:52 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 18 Nov 2007 12:16:52 -0500
Subject: i386 packages installed for x86_64
In-Reply-To: <473FA850.8050807@projetofedora.org>
References: <1195353993.15304.3.camel@hinge.endoframe.net>
	<473FA850.8050807@projetofedora.org>
Message-ID: <1195406212.15304.7.camel@hinge.endoframe.net>

On Sun, 2007-11-18 at 00:49 -0200, Mauricio Pretto wrote:
> Most of these packages are installed for compatibility .

With what?

> Can you list the ones you think are unnecessary ?

        evolution
        evolution-data-server
        python
        rhythmbox
        boost
        subversion
        hpijs
        gphoto2
        gnome-media
        SDL
        metacity
        gnome-desktop
        graphviz
        nautilus-cd-burner
        planner
        gstreamer
        
Not a complete list, I'm sure.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From braden at endoframe.com  Sun Nov 18 17:18:17 2007
From: braden at endoframe.com (Braden McDaniel)
Date: Sun, 18 Nov 2007 12:18:17 -0500
Subject: i386 packages installed for x86_64
In-Reply-To: <1195383957.3220.30.camel@shinybook.infradead.org>
References: <1195353993.15304.3.camel@hinge.endoframe.net>
	<473FA850.8050807@projetofedora.org>
	<1195383957.3220.30.camel@shinybook.infradead.org>
Message-ID: <1195406297.15304.9.camel@hinge.endoframe.net>


On Sun, 2007-11-18 at 06:05 -0500, David Woodhouse wrote:
> Please don't top-post. I've corrected it this time...
> 
> On Sun, 2007-11-18 at 00:49 -0200, Mauricio Pretto wrote:
> > Braden McDaniel wrote:
> > > Is it appropriate to file bugs for cases of (apparently unnecessary)
> > > i386 packages that are installed by default as part of an x86_64
> > > installation of Fedora 8?
> > > 
> > > If so, do these generally go against anaconda or the particular package?
> 
> The bug already exists, as one of the deps of the multilib tracker bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=235756

Thank you.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>




From myfedora at richip.dhs.org  Sun Nov 18 17:31:40 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sun, 18 Nov 2007 10:31:40 -0700
Subject: i386 packages installed for x86_64
In-Reply-To: <1195383957.3220.30.camel@shinybook.infradead.org>
References: <1195353993.15304.3.camel@hinge.endoframe.net>
	<473FA850.8050807@projetofedora.org>
	<1195383957.3220.30.camel@shinybook.infradead.org>
Message-ID: <1195407100.25313.8.camel@localhost6.localdomain6>

On Sun, 2007-11-18 at 06:05 -0500, David Woodhouse wrote:
> Please don't top-post. I've corrected it this time...
> 
> On Sun, 2007-11-18 at 00:49 -0200, Mauricio Pretto wrote:
> > Braden McDaniel wrote:
> > > Is it appropriate to file bugs for cases of (apparently unnecessary)
> > > i386 packages that are installed by default as part of an x86_64
> > > installation of Fedora 8?
> > > 
> > > If so, do these generally go against anaconda or the particular package?
> 
> The bug already exists, as one of the deps of the multilib tracker bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=235756
> 
> > Most of these packages are installed for compatibility .
> 
> That makes no sense. RPM dependencies exist to ensure that we install
> libraries as and when they're actually required. What on earth is the
> point in installing these libraries in advance?

+1. Truth be told, some of the native x86_64 packages are questionable.
Adding their i386 equivalent just compounds to the problem 4-fold. This
has been discussed several times. I'm not sure what the near- and
long-term resolutions are for this issue, but it would be nice to get
something out there that we can refer future posts like this to.

Personally, I do a "yum remove *.i386" and let yum add the i386
libraries I need compatibility for (nspluginwrapper for flash and glibc
for my Brother printer's drivers). It's a waste of bandwidth,
electricity, time, etc. and I'm not sure what it serves to accomplish,
particularly since yum does automatic installations of i386 libs if
noobie user happens to install i386 apps via the user-friendly GUI.
--

Richi Plana




From jonathan.underwood at gmail.com  Sun Nov 18 17:49:54 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 18 Nov 2007 17:49:54 +0000
Subject: Time skew of packaged files
In-Reply-To: <645d17210711180444k4151c4b3ma4b4d7255ac474b9@mail.gmail.com>
References: <645d17210711180331p1c0804fbpeac0a15e045ec8e@mail.gmail.com>
	<474025A9.3090802@gmail.com>
	<645d17210711180444k4151c4b3ma4b4d7255ac474b9@mail.gmail.com>
Message-ID: <645d17210711180949g737213c6p2e3cd985b549b44@mail.gmail.com>

On 18/11/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> On 18/11/2007, Andrew Farris <lordmorgul at gmail.com> wrote:
> > Copying the files to temp during the build may be whats causing that time issue.


Aha this was it actually (although replacing temp with buildroot fo
course) - what I was doing wrong is forgetting a -p when using
install/cp to manually copy the source elisp source files.

Thanks to Andrew and Tibbs for the advice on this.

Jonathan.



From eric.tanguy at univ-nantes.fr  Sun Nov 18 18:19:38 2007
From: eric.tanguy at univ-nantes.fr (Tanguy Eric)
Date: Sun, 18 Nov 2007 19:19:38 +0100
Subject: koji chain build
Message-ID: <1195409978.2887.19.camel@bureau.maison>

For the first time i use make chain-build the task seems to be on
(247220). The first package (libupnp) is built but the system seems
stalled in waitrepo state. What does it mean ? When the sytem will pass
to the next package ?

Thanks

Eric



From eric.tanguy at univ-nantes.fr  Sun Nov 18 19:01:08 2007
From: eric.tanguy at univ-nantes.fr (Tanguy Eric)
Date: Sun, 18 Nov 2007 20:01:08 +0100
Subject: koji chain build
In-Reply-To: <1195409978.2887.19.camel@bureau.maison>
References: <1195409978.2887.19.camel@bureau.maison>
Message-ID: <1195412468.2887.22.camel@bureau.maison>


Le dimanche 18 novembre 2007 ? 19:19 +0100, Tanguy Eric a ?crit :
> For the first time i use make chain-build the task seems to be on
> (247220). The first package (libupnp) is built but the system seems
> stalled in waitrepo state. What does it mean ? When the sytem will pass
> to the next package ?
> 
> Thanks
> 
> Eric
> 
OK it seems to work for devel but i have problems with F-7 and F-8. When
i try to make chain-build CHAIN='libupnp' the system answer : 
Packages in destination tag dist-f8-updates-candidate are not inherited
by build tag dist-f8-build
Target dist-f8-updates-candidate is not usable for a chain-build
make: *** [chain-build] Erreur 1

I'm not sure to understand where the problem come from.

Any help ?

Eric




From rdieter at math.unl.edu  Sun Nov 18 19:15:00 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 18 Nov 2007 13:15:00 -0600
Subject: koji chain build
References: <1195409978.2887.19.camel@bureau.maison>
Message-ID: <fhq31n$gc0$1@ger.gmane.org>

Tanguy Eric wrote:

> For the first time i use make chain-build the task seems to be on
> (247220). The first package (libupnp) is built but the system seems
> stalled in waitrepo state. What does it mean ? When the sytem will pass
> to the next package ?

the "wait" is the regeneration of the repo + your newly built package.  Be
patient, and the next pkg will eventually build.

-- Rex



From rdieter at math.unl.edu  Sun Nov 18 19:26:41 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 18 Nov 2007 13:26:41 -0600
Subject: koji chain build
References: <1195409978.2887.19.camel@bureau.maison>
	<1195412468.2887.22.camel@bureau.maison>
Message-ID: <fhq3nk$tq9$1@ger.gmane.org>

Tanguy Eric wrote:

> 
> Le dimanche 18 novembre 2007 ? 19:19 +0100, Tanguy Eric a ?crit :
>> For the first time i use make chain-build the task seems to be on
>> (247220). The first package (libupnp) is built but the system seems
>> stalled in waitrepo state. What does it mean ? When the sytem will pass
>> to the next package ?
>> 
>> Thanks
>> 
>> Eric
>> 
> OK it seems to work for devel but i have problems with F-7 and F-8. When
> i try to make chain-build CHAIN='libupnp' the system answer :
> Packages in destination tag dist-f8-updates-candidate are not inherited
> by build tag dist-f8-build
> Target dist-f8-updates-candidate is not usable for a chain-build
> make: *** [chain-build] Erreur 1
> 
> I'm not sure to understand where the problem come from.
> 
> Any help ?

chain-build works only for devel branch.  Previous (released) branches
require rel-eng intervention to add packages to the buildroot.

-- Rex




From eric.tanguy at univ-nantes.fr  Sun Nov 18 19:37:38 2007
From: eric.tanguy at univ-nantes.fr (Tanguy Eric)
Date: Sun, 18 Nov 2007 20:37:38 +0100
Subject: koji chain build
In-Reply-To: <fhq3nk$tq9$1@ger.gmane.org>
References: <1195409978.2887.19.camel@bureau.maison>
	<1195412468.2887.22.camel@bureau.maison> <fhq3nk$tq9$1@ger.gmane.org>
Message-ID: <1195414658.2887.25.camel@bureau.maison>


Le dimanche 18 novembre 2007 ? 13:26 -0600, Rex Dieter a ?crit :
> Tanguy Eric wrote:
> 
> > 
> > Le dimanche 18 novembre 2007 ? 19:19 +0100, Tanguy Eric a ?crit :
> >> For the first time i use make chain-build the task seems to be on
> >> (247220). The first package (libupnp) is built but the system seems
> >> stalled in waitrepo state. What does it mean ? When the sytem will pass
> >> to the next package ?
> >> 
> >> Thanks
> >> 
> >> Eric
> >> 
> > OK it seems to work for devel but i have problems with F-7 and F-8. When
> > i try to make chain-build CHAIN='libupnp' the system answer :
> > Packages in destination tag dist-f8-updates-candidate are not inherited
> > by build tag dist-f8-build
> > Target dist-f8-updates-candidate is not usable for a chain-build
> > make: *** [chain-build] Erreur 1
> > 
> > I'm not sure to understand where the problem come from.
> > 
> > Any help ?
> 
> chain-build works only for devel branch.  Previous (released) branches
> require rel-eng intervention to add packages to the buildroot.
> 
> -- Rex
> 
> 
Ok thanks.
Do you know how to know the packages which depends on library (using
yum ?)
It will be helpfull for me to send a mail to maintainers to rebuild
their packages against the new lib.
Thanks

Eric




From nicolas.mailhot at laposte.net  Sun Nov 18 20:43:05 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 18 Nov 2007 21:43:05 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071118094506.5216b37d@redhat.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info> <20071118094506.5216b37d@redhat.com>
Message-ID: <1195418585.26830.18.camel@rousalka.dyndns.org>


Le dimanche 18 novembre 2007 ? 09:45 -0500, Jesse Keating a ?crit :
> On Sun, 18 Nov 2007 15:11:00 +0100
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
> > Results from my work:
> > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls.diff
> > 
> > @FESCo: so what do do with this? Commit and don't build? The package
> > owners should see the commit diff and spot errors if I did any.
> 
> I have no problem with that, so long as the Fonts SIG is happy with the
> change.

I stated when I started the SIG I didn't want the glorious leader
position, so I won't pretend I speak for it, and I'll only object for
the three affected packages I maintain or co-maintain.

If this change is to be done I'll insist his author explain and defend
it on the SIG list, then write a formal FPC proposal, and get this
proposal approved all the way up.

This is a "fix"? in search of a problem?, and while I've been known to
make gratuitous changes to make a point too?, I've limited myself to my
own packages, and I'll appreciate the same restraint in my fellow
Fedorans.

I don't mind people touching my packages, but only if there are actual
problems to fix.

Regards,

? That can actually increase the probability bad packages make it
through QA

? One documented failure in rawhide does not count, if we shot
everything that ever went wrong in rawhide little would be left

? Yes I'm a bastard too.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/b15d474d/attachment.sig>

From andreas.bierfert at lowlatency.de  Sun Nov 18 21:44:25 2007
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Sun, 18 Nov 2007 22:44:25 +0100
Subject: Wine 0.9.49?
In-Reply-To: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
Message-ID: <20071118224425.3b888a72@alkaid.a.lan>

On Sun, 18 Nov 2007 08:46:07 +0200
Gilboa Davara <gilboad at gmail.com> wrote:

> Hello all,
> 
> Upstream contains a crucial D3D fix that I need.
> Any idea when it's gonna get built?
> (I'd build it myself, but I don't have an i386 machine handy and i386 on
> x86_64 build - at least AFAIK, is broken)
> 
> - Gilboa
> 

I am nearly done with testing here so once I get my mock set up right for f8 (am
I the only one missing the buildsys-build stuff for f8?) I will do a mock test
build and then it should hit testing soon. Sorry for the delay.

- Andreas

-- 
Andreas Bierfert, B.Sc.        | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/7134e54c/attachment.sig>

From tmz at pobox.com  Sun Nov 18 21:53:02 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 18 Nov 2007 16:53:02 -0500
Subject: koji chain build
In-Reply-To: <1195414658.2887.25.camel@bureau.maison>
References: <1195409978.2887.19.camel@bureau.maison>
	<1195412468.2887.22.camel@bureau.maison>
	<fhq3nk$tq9$1@ger.gmane.org>
	<1195414658.2887.25.camel@bureau.maison>
Message-ID: <20071118215302.GH320@psilocybe.teonanacatl.org>

Tanguy Eric wrote:
> Do you know how to know the packages which depends on library (using
> yum ?)
> It will be helpfull for me to send a mail to maintainers to rebuild
> their packages against the new lib.
> Thanks

Use something like this:

repoquery --whatrequires package_name libname.so.X

You want to use both the package name as well as what the package
provides.  You could even use the output of rpm --provides as the
input to repoquery.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose I were a member of Congress, and suppose I were an idiot. But,
I repeat myself.
    -- Mark Twain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/9ac8953e/attachment.sig>

From opensource at till.name  Sun Nov 18 21:53:15 2007
From: opensource at till.name (Till Maas)
Date: Sun, 18 Nov 2007 22:53:15 +0100
Subject: Wine 0.9.49?
In-Reply-To: <20071118224425.3b888a72@alkaid.a.lan>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<20071118224425.3b888a72@alkaid.a.lan>
Message-ID: <200711182253.29285.opensource@till.name>

On So November 18 2007, Andreas Bierfert wrote:

> f8 (am I the only one missing the buildsys-build stuff for f8?) I will do a

Yes, I am happy that it is away finally. The information of buildsys-build is 
now in the f8 repo comps file. With 
config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build'
in the mock config file, this information will be used.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/4c02802b/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Sun Nov 18 21:59:50 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Sun, 18 Nov 2007 22:59:50 +0100
Subject: Wine 0.9.49?
In-Reply-To: <200711182253.29285.opensource@till.name>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<20071118224425.3b888a72@alkaid.a.lan>
	<200711182253.29285.opensource@till.name>
Message-ID: <20071118225950.a91cadba.mschwendt.tmp0701.nospam@arcor.de>

On Sun, 18 Nov 2007 22:53:15 +0100, Till Maas wrote:

> On So November 18 2007, Andreas Bierfert wrote:
> 
> > f8 (am I the only one missing the buildsys-build stuff for f8?) I will do a
> 
> Yes, I am happy that it is away finally. The information of buildsys-build is 
> now in the f8 repo comps file. With 
> config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build'
> in the mock config file, this information will be used.

And if you set up a local F8 mirror, be sure to tell createrepo the
name of comps xml file.



From tmz at pobox.com  Sun Nov 18 22:02:41 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 18 Nov 2007 17:02:41 -0500
Subject: Wine 0.9.49?
In-Reply-To: <20071118171029.GC6174@humbolt.us.dell.com>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
	<1195399865.29118.22.camel@gilboa-home-dev.localdomain>
	<1195401110.3245.5.camel@eagle.danny.cz>
	<20071118171029.GC6174@humbolt.us.dell.com>
Message-ID: <20071118220241.GI320@psilocybe.teonanacatl.org>

Michael E Brown wrote:
> You might want to take a look at the mock 0.8.x yum caching. With
> the yum cache, it is likely that you would not need the squid cache
> anymore.  The only thing that is re-downloaded is the yum metadata,
> if it changes.  This is enabled by default, and you can safely set
> the timeout on it to be as high as you like.

For those of us with a local mirror on the LAN, is it enough to simply
set config_opts['plugin_conf']['yum_cache_enable'] = False in the mock
defaults.cfg to disable the yum cache?

Also, is there a proper way to clear the cache, or is it fine to just
rm /var/lib/mock/cache/*/yum_cache ?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I like this 'God'; he's so deliciously evil.
    -- Stewie Griffin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/31c5038b/attachment.sig>

From ville.skytta at iki.fi  Sun Nov 18 22:05:19 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 19 Nov 2007 00:05:19 +0200
Subject: koji chain build
In-Reply-To: <20071118215302.GH320@psilocybe.teonanacatl.org>
References: <1195409978.2887.19.camel@bureau.maison>
	<1195414658.2887.25.camel@bureau.maison>
	<20071118215302.GH320@psilocybe.teonanacatl.org>
Message-ID: <200711190005.19817.ville.skytta@iki.fi>

On Sunday 18 November 2007, Todd Zullinger wrote:
> Tanguy Eric wrote:
> > Do you know how to know the packages which depends on library (using
> > yum ?)
> > It will be helpfull for me to send a mail to maintainers to rebuild
> > their packages against the new lib.
> > Thanks
>
> Use something like this:
>
> repoquery --whatrequires package_name libname.so.X
>
> You want to use both the package name as well as what the package
> provides.  You could even use the output of rpm --provides as the
> input to repoquery.

Easier and faster way: repoquery --whatrequires --alldeps package_name



From louisg00 at bellsouth.net  Sun Nov 18 22:35:23 2007
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Sun, 18 Nov 2007 17:35:23 -0500
Subject: Any experience with bluetooth keyboard and mice
Message-ID: <1195425323.17403.3.camel@tiger>

Looking at Dell's desktop with bluetooth keyboard and mouse. I'm not
sure about the maturity level of bluetooth in F8. Will the installer and
gnome desktop work?

-Thanks



From tmz at pobox.com  Sun Nov 18 23:33:59 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Sun, 18 Nov 2007 18:33:59 -0500
Subject: koji chain build
In-Reply-To: <200711190005.19817.ville.skytta@iki.fi>
References: <1195409978.2887.19.camel@bureau.maison>
	<1195414658.2887.25.camel@bureau.maison>
	<20071118215302.GH320@psilocybe.teonanacatl.org>
	<200711190005.19817.ville.skytta@iki.fi>
Message-ID: <20071118233359.GJ320@psilocybe.teonanacatl.org>

Ville Skytt? wrote:
> Easier and faster way: repoquery --whatrequires --alldeps package_name

Nice.  Thanks Ville!

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hard work never killed anybody, but why take a chance?
    -- Charlie McCarthy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/22f833ec/attachment.sig>

From jkeating at redhat.com  Sun Nov 18 23:55:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 18 Nov 2007 18:55:14 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195418585.26830.18.camel@rousalka.dyndns.org>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>
	<1195222693.3238.11.camel@localhost.localdomain>
	<1195226289.3002.4.camel@localhost.localdomain>
	<1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>
	<20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
Message-ID: <20071118185514.6cfa560a@redhat.com>

On Sun, 18 Nov 2007 21:43:05 +0100
Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

> I stated when I started the SIG I didn't want the glorious leader
> position, so I won't pretend I speak for it, and I'll only object for
> the three affected packages I maintain or co-maintain.
> 
> If this change is to be done I'll insist his author explain and defend
> it on the SIG list, then write a formal FPC proposal, and get this
> proposal approved all the way up.
> 
> This is a "fix"? in search of a problem?, and while I've been known to
> make gratuitous changes to make a point too?, I've limited myself to
> my own packages, and I'll appreciate the same restraint in my fellow
> Fedorans.

So it would seem we're /not/ in agreement on this point.  Thorsten, are
you trying to fix a real problem, or just trying to ensure everything
follows a guideline regarding exit failures in %post scriptlets?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/c699b84f/attachment.sig>

From michel.sylvan at gmail.com  Mon Nov 19 02:10:08 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Sun, 18 Nov 2007 21:10:08 -0500
Subject: Suggestions for F9
In-Reply-To: <1195389209.3154.1.camel@aragorn>
References: <1195196211.3144.1.camel@aragorn>
	<1195199626.24749.93.camel@animal.passback.co.uk>
	<1195389209.3154.1.camel@aragorn>
Message-ID: <f224c6140711181810n1387b0b4l9643530af6af7d42@mail.gmail.com>

On 18/11/2007, Trever L. Adams <trever.adams at gmail.com> wrote:

> I had seen these before. I do not think I want chandler or rscds. The
> later doesn't fully implement the protocol yet. It may never do so.
> Chandler seems much too heavy.

ObOT: Chandler is the subject of a rather fascinating (but bleak) book
on software engineering, "Dreaming In Code". I tried out the latest
Chandler release not long after I got the book, and it was still ..
not very stable. Things might have improved since then, though.

-- 
Michel Salim
http://hircus.jaiku.com/



From fedora at leemhuis.info  Mon Nov 19 05:56:22 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 06:56:22 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071118185514.6cfa560a@redhat.com>
References: <12225.192.54.193.53.1195219803.squirrel@rousalka.dyndns.org>	<1195222693.3238.11.camel@localhost.localdomain>	<1195226289.3002.4.camel@localhost.localdomain>	<1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com>
Message-ID: <47412586.4020502@leemhuis.info>

On 19.11.2007 00:55, Jesse Keating wrote:
> On Sun, 18 Nov 2007 21:43:05 +0100
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
>> I stated when I started the SIG I didn't want the glorious leader
>> position, so I won't pretend I speak for it, and I'll only object for
>> the three affected packages I maintain or co-maintain.
>> If this change is to be done I'll insist his author explain and defend
>> it on the SIG list, then write a formal FPC proposal, and get this
>> proposal approved all the way up.
>> This is a "fix"? in search of a problem?, and while I've been known to
>> make gratuitous changes to make a point too?, I've limited myself to
>> my own packages, and I'll appreciate the same restraint in my fellow
>> Fedorans.
> So it would seem we're /not/ in agreement on this point.

Nothing new -- I leave that debate to Nicolas and the Font-SIG together
with you and the other members of the FPC, as I don't care much about it.

>  Thorsten, are you trying to fix a real problem,

Well, I run into problems once due to the wrong exit code. That was
likely a corner case, but there are likely other corner cases with lead
to the rule spot mentioned ("script should not exit with non-zero exit
code"), which IMHO is a good one.

> or just trying to ensure everything
> follows a guideline regarding exit failures in %post scriptlets?

I just want to raise the point that FPC creates or modifies rules that
are often not really (or very slowly) being realized in existing the
packages.

Someone in a lot cases (like this one) could just realize many of the
changes in the Packaging Guidelines directly in CVS for all effected
packages. I think we should do that way more often and get away from the
mantra "this is my package and nobody else is allowed to touch it" --
that's why I took this particular issue as example to just show how it
could be done. Now I expect from FESCo advice for this particular
example as well as the general concept where one persons realizes
changes in all effected packages directly in CVS.

CU
knurd



From marcelo.gobelli at gmail.com  Mon Nov 19 06:24:37 2007
From: marcelo.gobelli at gmail.com (marcelo gobelli)
Date: Sun, 18 Nov 2007 22:24:37 -0800
Subject: information
In-Reply-To: <ufak5ogi5yh.fsf@epithumia.math.uh.edu>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
	<ufak5ogi5yh.fsf@epithumia.math.uh.edu>
Message-ID: <72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>

OS developer. what's next? thanks

On 17 Nov 2007 21:32:38 -0600, Jason L Tibbitts III <tibbs at math.uh.edu>
wrote:
>
> >>>>> "mg" == marcelo gobelli <marcelo.gobelli at gmail.com> writes:
>
> mg> how can I get involved with the fedora project. I would like to
> mg> help but I did not know how. any ideas?
>
> Well, it helps to know what you'd like to do.  But you can get some
> really good information just by going to the project's web page
> http://fedoraproject.org and clicking the "Join Fedora" link.
>
> - J<
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071118/6fad746d/attachment.htm>

From j.w.r.degoede at hhs.nl  Mon Nov 19 06:47:13 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 19 Nov 2007 07:47:13 +0100
Subject: Suggestions for F9
In-Reply-To: <1195196211.3144.1.camel@aragorn>
References: <1195196211.3144.1.camel@aragorn>
Message-ID: <47413171.7090206@hhs.nl>

Trever L. Adams wrote:
 > On Fri, 2007-11-16 at 09:05 +0100, Hans de Goede wrote:
 > > Trever,
 > >
 > > Thanks for this, I think those are good suggestions. However most 
Fedora
 > > developers are already carying a pretty full workload as is. Have you
 > > considered becoming a contributer yourself? I'm more then willing 
to guide you
 > > on your initial steps, note I'm both an experienced packager and an 
experienced
 > > (certified even) teacher.
 > >
 > > Regards,
 > >
 > > Hans
 >
 >
 > I think I may be interested in this. Can you give me a few more days
 > (possibly until December 1, 2007) to think this through and make sure I
 > have what it takes?

Sure new contributers are welcome the whole year round :)

 > I stink with CVS. I am a decent programmer, but I
 > haven't learned CVS and am trying to learn git.


Well, you don't need to be a CVS guru, you only need to know about 5 cvs 
commands (co, commit, update, rm, add).

Regards,

Hans



From pemboa at gmail.com  Mon Nov 19 07:18:39 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 19 Nov 2007 01:18:39 -0600
Subject: System-config Reworking Proposal
Message-ID: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>

I have expressed my ideas[1] to add and rework some of the
functionality of the system-config tools with the hope of making them
a bit more innovative and useful.

Please comment on the idea.

I am personally interested in pursuing the implementation in Python.

[1] http://fedoraproject.org/wiki/SystemConfig/ProposalVConsole

Arthur Pemberton

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From trever.adams at gmail.com  Mon Nov 19 09:31:45 2007
From: trever.adams at gmail.com (Trever L. Adams)
Date: Mon, 19 Nov 2007 02:31:45 -0700
Subject: Suggestions for F9
In-Reply-To: <f224c6140711181810n1387b0b4l9643530af6af7d42@mail.gmail.com>
References: <1195196211.3144.1.camel@aragorn>
	<1195199626.24749.93.camel@animal.passback.co.uk>
	<1195389209.3154.1.camel@aragorn>
	<f224c6140711181810n1387b0b4l9643530af6af7d42@mail.gmail.com>
Message-ID: <1195464705.3124.1.camel@aragorn>

On Sun, 2007-11-18 at 21:10 -0500, Michel Salim wrote:

> ObOT: Chandler is the subject of a rather fascinating (but bleak) book
> on software engineering, "Dreaming In Code". I tried out the latest
> Chandler release not long after I got the book, and it was still ..
> not very stable. Things might have improved since then, though.
> 
> -- 
> Michel Salim
> http://hircus.jaiku.com/
> 

Well, I have done some more reading. Unless people disagree, if I can
submit the packages I want. I think that www.bedework.org/bedework is
the one to use.

Trever
--
"SMOG: Evidence of lack of faith. It is the result of needing to see
what you breath." -- Harl Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/b23ddc50/attachment.sig>

From pertusus at free.fr  Mon Nov 19 09:55:58 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Nov 2007 10:55:58 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <47412586.4020502@leemhuis.info>
References: <1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>
	<20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com>
	<47412586.4020502@leemhuis.info>
Message-ID: <20071119095558.GC2584@free.fr>

On Mon, Nov 19, 2007 at 06:56:22AM +0100, Thorsten Leemhuis wrote:
> 
> Someone in a lot cases (like this one) could just realize many of the
> changes in the Packaging Guidelines directly in CVS for all effected
> packages. I think we should do that way more often and get away from the
> mantra "this is my package and nobody else is allowed to touch it" --
> that's why I took this particular issue as example to just show how it
> could be done. Now I expect from FESCo advice for this particular
> example as well as the general concept where one persons realizes
> changes in all effected packages directly in CVS.

I fully agree, but it is already explicitely permitted in
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

All is needed is a set of scripts and maybe FESCo taking a lead. One
occasion I see would be the mass rebuild of packages that depend on
doxygen after the 'non reproducible anchors bug' is fixed -- that is
doxygen is updated to latest version.

--
Pat



From bnocera at redhat.com  Mon Nov 19 10:10:43 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 19 Nov 2007 10:10:43 +0000
Subject: Any experience with bluetooth keyboard and mice
In-Reply-To: <1195425323.17403.3.camel@tiger>
References: <1195425323.17403.3.camel@tiger>
Message-ID: <1195467043.10878.102.camel@cookie.hadess.net>


On Sun, 2007-11-18 at 17:35 -0500, Louis E Garcia II wrote:
> Looking at Dell's desktop with bluetooth keyboard and mouse. I'm not
> sure about the maturity level of bluetooth in F8. Will the installer and
> gnome desktop work?

No, and yes, respectively. Note that you'll need at least a mouse to be
able to log in and setup the keyboard and mouse.



From michael.wiktowy at gmail.com  Mon Nov 19 10:31:05 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Mon, 19 Nov 2007 05:31:05 -0500
Subject: Smolt database is broken
Message-ID: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>

I just submitted my profile a few days ago and immediately tried to
retrieve it and got some other machine that didn't match my config. So
I submitted it again and things looked a bit more reasonable. Today I
checked it again and the vast majority of it has changed.

So there is some massive database corruption going on AFAICT. Did I
miss a message somewhere indicating this?

ref my machine:
http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f

/Mike



From akahl at iconmobile.com  Mon Nov 19 10:32:04 2007
From: akahl at iconmobile.com (Alexander Kahl)
Date: Mon, 19 Nov 2007 11:32:04 +0100
Subject: Help Request: Signal 4 crash (illegal instruction)
Message-ID: <1195468324.3444.18.camel@dev31.iconmobile.de>

Hi,

does anyone have experience with signal 4 (illegal instruction) crashes?
I've got a bug report (#375201)[1] for libzzub and was able to track it
down to the point the crash occurs in the original source code but
cannot determine what's wrong with the machine code. This could even be
a g++ bug and I would like to report this to the right upstream, if
applicable.

Regards,
Alex

[1] https://bugzilla.redhat.com/show_bug.cgi?id=375201
-- 
alexander kahl _ developer

iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany
phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256
akahl at iconmobile.com _ www.iconmobile.com

local court charlottenburg _ hrb 88308
managing directors _ thomas fellger | stefan kirschke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/598854ac/attachment.sig>

From lemenkov at gmail.com  Mon Nov 19 10:37:10 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Mon, 19 Nov 2007 13:37:10 +0300
Subject: Any experience with bluetooth keyboard and mice
In-Reply-To: <1195425323.17403.3.camel@tiger>
References: <1195425323.17403.3.camel@tiger>
Message-ID: <adf480660711190237n7a47473eh54bc4a62e87d9d9e@mail.gmail.com>

2007/11/19, Louis E Garcia II <louisg00 at bellsouth.net>:
> Looking at Dell's desktop with bluetooth keyboard and mouse. I'm not
> sure about the maturity level of bluetooth in F8. Will the installer and
> gnome desktop work?

I attached Apple Mighty Mouse w/o problems. I added one string into
/etc/rc.d/rc.local

# start mouse
hidd -c <mac-addr of my mouse>

where <mac-addr of my mouse> I collected using
hcitool scan

That's all. No need to gnome-bluez or other GUI stuff
-- 
With best regards!



From twaugh at redhat.com  Mon Nov 19 11:12:59 2007
From: twaugh at redhat.com (Tim Waugh)
Date: Mon, 19 Nov 2007 11:12:59 +0000
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
Message-ID: <1195470779.7213.12.camel@cyberelk.elk>

On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> Please comment on the idea.

I'd like to know whether you are considering system-config-printer to be
part of this scheme.  CUPS configuration is quite different from other
configuration tools, and a method based on altering configuration files
would be a big regression.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/0c847ae1/attachment.sig>

From buildsys at redhat.com  Mon Nov 19 11:44:59 2007
From: buildsys at redhat.com (Build System)
Date: Mon, 19 Nov 2007 06:44:59 -0500
Subject: rawhide report: 20071119 changes
Message-ID: <200711191144.lAJBixcD031764@porkchop.devel.redhat.com>

New package debootstrap
	Bootstrap a basic Debian GNU/Linux system

New package perl-Getopt-Euclid
	Executable Uniform Command-Line Interface Descriptions

New package qct
	Multi-vcs GUI commit tool

New package swfdec-mozilla
	Mozilla/Gecko player Flash plugin using swfdec


Removed package 915resolution

Updated Packages:

Inventor-2.1.5-30.fc9.1
-----------------------
* Mon Nov 19 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.1.5-30.1
- Add hard-coded deps on font files (BZ 388761).
- Switch to using liberation-fonts instead of dejavu-fonts.

asa-1.2-4.fc9
-------------
* Sun Nov 18 2007 Patrice Dumas <pertusus at free.fr> - 1.2-4
- keep timestamps
- correct license tag
bakery-2.4.2-1.fc9
------------------
* Mon Nov 19 2007 Denis Leroy <denis at poolshark.org> - 2.4.2-1
- Update to upstream 2.4.2

bodhi-0.4.5-2.fc9
-----------------
* Sun Nov 18 2007 Luke Macken <lmacken at redhat.com> - 0.4.5-2
- Add python-genshi to BuildRequires

* Sat Nov 17 2007 Luke Macken <lmacken at redhat.com> - 0.4.5-1
- 0.4.5

boo-0.8.0.2730-3.fc9
--------------------
* Sat Nov 17 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.8.0-2730-3
- Added exclusivearch

* Sun Nov 11 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.8.0-2730-2
- large bump
- removed fc5 and fc6 bit6
- removed MS update builds from default build
- fixed problem with the boo.pc file

* Sun Feb 18 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> 0.7.6-2237-13
- fix for correct libdir in bin scripts

cvs2svn-2.0.1-1.fc9
-------------------
* Sun Nov 18 2007 Konstantin Ryabitsev <icon at fedoraproject.org> - 2.0.1-1
- Upstream 2.0.1

dar-2.3.6-2.fc9
---------------
* Sun Nov 18 2007 Chris Petersen <rpm at forevermore.net>                  2.3.6-2
- failed "make tag"

* Sun Nov 18 2007 Chris Petersen <rpm at forevermore.net>                  2.3.6-1
- Update to 2.3.6

* Tue Aug 28 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 2.3.4-2
- Rebuild for selinux ppc32 issue.

dbus-glib-0.74-2.fc9
--------------------
* Sun Nov 18 2007 Dan Williams <dcbw at redhat.com> - 0.74-2
- Actually apply the patch for fdo #12505

emacs-vm-8.0.5.504-2.fc9
------------------------
* Sun Nov 18 2007 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 8.0.5.504-2
- Add -p option to install when copying source elisp files into buildroot to
  preserve mtimes (BZ #389081)

extrema-4.2.10-3.fc9
--------------------

flashrom-0-0.5.20071118svn2967.fc9
----------------------------------
* Sun Nov 18 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.5.20071118svn2967
- svn ver. 2967 (support for Intel 440MX systems, Fujitsu MBM29F400TC, 
  AMD Geode CS5536)

freenx-0.7.1-1.fc9
------------------
* Sat Nov 17 2007 Jon Ciesla <limb at jcomserv.net> - 0.7.1-1
- Update to 0.7.1, many bugfixes.

fwbackups-1.43.1-6.fc9
----------------------
* Sun Nov 18 2007 Stewart Adam <s.adam at diffingo.com> 1.43.1-6
- BR: libxml2

* Sun Nov 18 2007 Stewart Adam <s.adam at diffingo.com> 1.43.1-5
- Remove scrollkeeper scriptlets; Only need that for .omf files
- Add patch to fix RestoreSetName traceback on startup

* Sat Sep 01 2007 Stewart Adam <s.adam at diffingo.com> 1.43.1-5
- Add BR python-devel

gconf-editor-2.20.0-2.fc9
-------------------------
* Sun Nov 18 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Correct license field
- Minor spec file cleanups

gkrellm-2.3.0-5.fc9
-------------------
* Wed Oct 24 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 2.3.0-5
- Add support for lm_sensors-3.0.0

* Wed Sep 05 2007 Ville Skytt?? <ville.skytta at iki.fi> - 2.3.0-4
- Rewrite gkrellmd init script: better LSB compliance, hddtemp
  interoperability, avoidance of X error messages, general cleanup.

* Tue Sep 04 2007 Ville Skytt?? <ville.skytta at iki.fi> - 2.3.0-3
- Fix gnutls detection/build and use it instead of openssl.
- Sync user and group creation with current Fedora guidelines.

gmediaserver-0.13.0-1.fc9
-------------------------
* Sun Nov 18 2007 Karol Trzcionka <karlikt at gmail.com> - 0.13.0-1
- Update to v0.13.0

gnu-smalltalk-2.3.6-7.fc9
-------------------------
* Sun Nov 18 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.3.6-7
- Fix broken Changelog

* Thu Oct 25 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.3.6-6
- Add upstream multilib patch

* Wed Oct 24 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.3.6-4
- Another try to fix the multilib issue

gtk-doc-1.9-1.fc9
-----------------
* Sun Nov 18 2007 Matthias Clasen <mclasen at redhat.com> - 1.9-1
- Update to 1.9

* Tue Aug 07 2007 Matthias Clasen <mclasen at redhat.com> - 1.8-3
- Update the license field

kst-1.5.0-1.fc9
---------------
* Sun Nov 18 2007 Matthew Truch <matt at truch.net> - 1.5.0-1
- Update to kst 1.5.0 [primarily] bugfix release
- Remove patch to fix open() call; fix was pushed upstream.
- Add autoreconf (and associated BR) as 1.5.0 tarball requires such.

libesmtp-1.0.4-4.fc9
--------------------
* Sun Nov 18 2007 Patrice Dumas <pertusus at free.fr> - 1.0.4-4
- use --disable-static

libflaim-4.9.989-16.fc9
-----------------------
* Sun Nov 18 2007 Christopher Brown <snecklifter at gmail.com> - 4.9.989-16
- include and move libflaim.a

libupnp-1.6.1-1.fc9
-------------------
* Sun Nov 18 2007 Eric Tanguy <eric.tanguy at univ-nantes.fr> - 1.6.1-1
- Update to version 1.6.1

* Wed Aug 29 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 1.6.0-2
- Rebuild for selinux ppc32 issue.

* Wed Jun 13 2007 Eric Tanguy <eric.tanguy at univ-nantes.fr> - 1.6.0-1
- Update to version 1.6.0

man-pages-es-1.55-1.fc9
-----------------------
* Mon Nov 19 2007 Ding-Yi Chen <dchen at redhat.com> - 1.55-1
- [Bug 388391] New: fileconflicts with other packages
- Remove mc.1.gz, as it conflicts with mc-4.6.1a-49.20070604cvs.fc8.i386.rpm
- Remove newgrp.1.gz, as it conflicts with shadow-utils-4.0.18.1-18.fc8.i386.rpm

metacity-2.21.2-1.fc9
---------------------
* Sun Nov 18 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.2-1
- Update to 2.21.2

poker3d-1.1.36-7.fc9
--------------------
* Sun Nov 18 2007 Christopher Stone <chris.stone at gmail.com> 1.1.36-7
- Add python-simplejson to Requires
revisor-2.0.5-10.fc9
--------------------
* Mon Nov 19 2007 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.0.5-10
- Catch a Bob Jensen Corner Case
- Minor bugfixes in packaging
- Other minor fixes

* Sat Oct 20 2007 Jonathan Steffan <jon a fedoraunity.org> 2.0.5-5
- Update spec for release

* Tue Oct 02 2007 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.0.5-3
- Bugfixes to x86_64 packageSack creation
- Bugfixes

superiotool-0-0.6.20071118svn2975.fc9
-------------------------------------
* Sun Nov 18 2007 Peter Lemenkov <lemenkov at gmail.com> 0.6.20071118svn2975
- svn ver. 2975 (support for SMSC LPC47N227, NSC PC8374L, Winbond W83977TF,
  Winbond W83977AF, Winbond W83697SF, NSC PC87360, SMSC FDC37N958FR)
- drop patch1

system-config-language-1.2.14-1.fc9
-----------------------------------
* Mon Nov 19 2007 Lingning Zhang <lizhang at redhat.com> - 1.2.14
- fix bug386731.

uncrustify-0.41-1.fc9
---------------------
* Sun Nov 18 2007 Neal Becker <ndbecker2 at gmail.com> - 0.41-1
- Update to 0.41

ushare-1.0-4.fc9
----------------
* Sun Nov 18 2007 Eric Tanguy <eric.tanguy at univ-nantes.fr> - 1.0-4
- Rebuild for new libupnp.

vdr-skins-20061119-4
--------------------
* Sun Nov 18 2007 Ville Skytt?? <ville.skytta at iki.fi> - 20061119-4
- Adjust font paths for dejavu-lgc-fonts 2.21+ (#388891).

* Fri Aug 10 2007 Ville Skytt?? <ville.skytta at iki.fi> - 20061119-3
- Use DejaVu LGC fonts instead of Bitstream Vera.
- License: GPL+

* Mon Apr 23 2007 Ville Skytt?? <ville.skytta at iki.fi> - 20061119-2
- Relocate themes to /var/lib/vdr/themes, drop disttag (#216355).
- Drop file based dependency on /usr/share/vdr/text2skin.
- Fix sttng-blue source URL.

wine-docs-0.9.49-1.fc9
----------------------
* Mon Nov 19 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.49-1
- version upgrade

Broken deps for i386
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	net-snmp - 1:5.4.1-5.fc9.i386 requires libsensors.so.3
	net-snmp-libs - 1:5.4.1-5.fc9.i386 requires libsensors.so.3
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3



Broken deps for x86_64
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	net-snmp - 1:5.4.1-5.fc9.x86_64 requires libsensors.so.3()(64bit)
	net-snmp-libs - 1:5.4.1-5.fc9.x86_64 requires libsensors.so.3()(64bit)
	net-snmp-libs - 1:5.4.1-5.fc9.i386 requires libsensors.so.3
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo
	net-snmp - 1:5.4.1-5.fc9.ppc requires libsensors.so.3
	net-snmp-libs - 1:5.4.1-5.fc9.ppc requires libsensors.so.3
	net-snmp-libs - 1:5.4.1-5.fc9.ppc64 requires libsensors.so.3()(64bit)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3



Broken deps for ppc64
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	net-snmp - 1:5.4.1-5.fc9.ppc64 requires libsensors.so.3()(64bit)
	net-snmp-libs - 1:5.4.1-5.fc9.ppc64 requires libsensors.so.3()(64bit)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)





From lkundrak at redhat.com  Mon Nov 19 13:07:13 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 19 Nov 2007 14:07:13 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
Message-ID: <1195477633.7218.21.camel@localhost.localdomain>

Hi,

On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> I have expressed my ideas[1] to add and rework some of the
> functionality of the system-config tools with the hope of making them
> a bit more innovative and useful.
> 
> Please comment on the idea.

> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
> 
>     * transparently handle local or remote console (via ssh)
>           o allow configuration of remote services

this is possible now:
ssh -X my.server system-config-httpd

>           o possible allow for OS independent usage (example: system-config-httpd could be used from Windows XP)

You can do the very same thing from Windows XP.

>           o allow for those who prefer not to run server tools with a X server installed to make use of the system-config tools 

None of the system-config-* tools depends on X server except for
system-config-display.

>     * allows for centrally logging system-config actions (audit trail)
>     * standardize routines/functionality commonly used by system-config tools 

These seem to be a good ideas to me.

Regards,
-- 
Lubomir Kundrak (Red Hat Security Response Team)



From jan.kratochvil at redhat.com  Mon Nov 19 13:24:42 2007
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Mon, 19 Nov 2007 14:24:42 +0100
Subject: Optional packages for the build-time testsuite runs?
Message-ID: <20071119132442.GA14216@host0.dyn.jankratochvil.net>

Hi all,

GDB package has its own large testsuite which is being run automatically from
.spec %check during the build to easily find any possible regressions.

This testsuite automatically detects existence of some other packages
(gcc-gfortran gcc-java gcc-objc gcc-gnat) to run its optional parts to test
these specific langauges GDB support.

These exotic languages/rpms (gcc-gfortran gcc-java gcc-objc gcc-gnat) may not
be commonly installed on the target systems where one may just want to
`rpmbuild --rebuild' the .src.rpm for various reasons (such as using newer GDB
in an older Fedora system).

Listing gcc-gfortran/gcc-java/gcc-objc/gcc-gnat into BuildRequires (now since
gdb-6.7.1-4.fc9) just for the testsuite purposes brings:
  pro) It enables the testsuite to run in Koji/mock.
  con) It creates a burden for the users just rebuilding the rpm on their Fedora.

Isn't there a way to do some?
	%if %{mock}
	BuildRequires: gcc-gfortran gcc-java gcc-objc gcc-gnat
	%endif
Tried
	%if 0%{?dist:1}
but %dist is defined even for simple --rebuild by the redhat-rpm-config rpm.


Thanks for hints,
Jan



From fedora at leemhuis.info  Mon Nov 19 13:24:42 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 14:24:42 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <1195477633.7218.21.camel@localhost.localdomain>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
Message-ID: <47418E9A.9040603@leemhuis.info>

On 19.11.2007 14:07, Lubomir Kundrak wrote:
> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
>>     * transparently handle local or remote console (via ssh)
>>           o allow configuration of remote services
> this is possible now:
> ssh -X my.server system-config-httpd

Wile at it: For me as heavy sudo user it does not work properly:
https://bugzilla.redhat.com/show_bug.cgi?id=142648
https://bugzilla.redhat.com/show_bug.cgi?id=164671

CU
knurd



From nphilipp at redhat.com  Mon Nov 19 13:49:59 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 19 Nov 2007 14:49:59 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <1195470779.7213.12.camel@cyberelk.elk>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
Message-ID: <1195480199.14998.21.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-19 at 11:12 +0000, Tim Waugh wrote:
> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> > Please comment on the idea.
> 
> I'd like to know whether you are considering system-config-printer to be
> part of this scheme.  CUPS configuration is quite different from other
> configuration tools, and a method based on altering configuration files
> would be a big regression.

For my tools (-date, -nfs, -samba, -services, -users), just being able
to edit files is also not sufficient. Often these tools don't edit files
themselves but use e.g. chkconfig or libuser, partly it isn't even known
whether local files are changed or some objects in an LDAP directory.

In my eyes, we first need to get UI, logic and privileged operations
cleanly separated. Then we can think about additional stuff like logging
of operations (would be put between UI and logic) or move stuff from
using usermode to PolicyKit.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From rdieter at math.unl.edu  Mon Nov 19 13:54:20 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 19 Nov 2007 07:54:20 -0600
Subject: ggz reviews approved, comaintainers welcome
Message-ID: <fhs4ic$mt2$1@ger.gmane.org>

The first batch of ggz-related reviews have been approved,
libggz: http://bugzilla.redhat.com/370741
ggz-client-libs: http://bugzilla.redhat.com/370751 (pending cvsadmin)

comaintainers welcome.

-- Rex



From mclasen at redhat.com  Mon Nov 19 14:01:24 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 19 Nov 2007 09:01:24 -0500
Subject: ggz reviews approved, comaintainers welcome
In-Reply-To: <fhs4ic$mt2$1@ger.gmane.org>
References: <fhs4ic$mt2$1@ger.gmane.org>
Message-ID: <1195480884.6241.6.camel@localhost.localdomain>


On Mon, 2007-11-19 at 07:54 -0600, Rex Dieter wrote:
> The first batch of ggz-related reviews have been approved,
> libggz: http://bugzilla.redhat.com/370741
> ggz-client-libs: http://bugzilla.redhat.com/370751 (pending cvsadmin)
> 
> comaintainers welcome.
> 

I'm not volunteering for comaintainership, but I wondered if you 
plan to package other parts of ggz apart from libggz itself ? 
gnome-games seems to need at least ggzdmod.

Matthias



From fedora at leemhuis.info  Mon Nov 19 14:06:07 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 15:06:07 +0100
Subject: working with gnome project/other distros together on system tools
 (was: Re: System-config Reworking Proposal)
In-Reply-To: <1195480199.14998.21.camel@gibraltar.str.redhat.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
Message-ID: <4741984F.30006@leemhuis.info>

On 19.11.2007 14:49, Nils Philippsen wrote:
> On Mon, 2007-11-19 at 11:12 +0000, Tim Waugh wrote:
>> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>>> Please comment on the idea.
>> I'd like to know whether you are considering system-config-printer to be
>> part of this scheme.  CUPS configuration is quite different from other
>> configuration tools, and a method based on altering configuration files
>> would be a big regression.
> In my eyes, we first need to get UI, logic and privileged operations
> cleanly separated. Then we can think about additional stuff like logging
> of operations (would be put between UI and logic) or move stuff from
> using usermode to PolicyKit.

Just wondering: Why don't we work towards getting some sane config tools
(seperated in UI, logic, ...) close to Gnome (and KDE, should there be
interest)? Sure, that way other distros will benefit from out work as
well, but on the other hand having stuff as de-facto part of Gnome and
used by other distros afaics lead to better tools and a better user
experience, which overall leads to a better "Linux".

Take gnome-power-manager as example -- until not that long ago each
distro had there own black- and whitelists for the workarounds that make
suspend simply work. That worked not to bad, but not perfectly and much
man-hours were wasted as each distro had to maintain their own lists.
Now we have gnome-power-manager as common upstream, which gets used by
Fedora, OpenSuse, Ubuntu and some others -- all those help getting the
data improved which really improved the situation a lot afaics, as
everyone benefits from the work.

PackageKit seems to be the next area where lots of distributions did
their own thing for a long time and now work together. I'm really
wondering how long it will take until PackageKit and its tools will
replace pup and pirut. So maybe both tools that were developed not that
long ago might vanish and become history over the next two years.

CU
knurd



From gilboad at gmail.com  Mon Nov 19 14:16:32 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 19 Nov 2007 16:16:32 +0200
Subject: Wine 0.9.49?
In-Reply-To: <20071118224425.3b888a72@alkaid.a.lan>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<20071118224425.3b888a72@alkaid.a.lan>
Message-ID: <1195481792.8410.4.camel@gilboa-work-dev.localdomain>


On Sun, 2007-11-18 at 22:44 +0100, Andreas Bierfert wrote:
> On Sun, 18 Nov 2007 08:46:07 +0200
> Gilboa Davara <gilboad at gmail.com> wrote:
> 
> > Hello all,
> > 
> > Upstream contains a crucial D3D fix that I need.
> > Any idea when it's gonna get built?
> > (I'd build it myself, but I don't have an i386 machine handy and i386 on
> > x86_64 build - at least AFAIK, is broken)
> > 
> > - Gilboa
> > 
> 
> I am nearly done with testing here so once I get my mock set up right for f8 (am
> I the only one missing the buildsys-build stuff for f8?) I will do a mock test
> build and then it should hit testing soon. Sorry for the delay.
> 
> - Andreas

Looking forward for it.

Thanks,
- Gilboa



From gary at mlbassoc.com  Mon Nov 19 14:24:37 2007
From: gary at mlbassoc.com (Gary Thomas)
Date: Mon, 19 Nov 2007 07:24:37 -0700
Subject: Severe X breakage heads up
In-Reply-To: <1194294608.15341.204.camel@localhost.localdomain>
References: <1194294608.15341.204.camel@localhost.localdomain>
Message-ID: <47419CA5.9050204@mlbassoc.com>

Adam Jackson wrote:
> I plan to rebase the X server to git master a week from today (Monday,
> November 12), which means the changes should hit rawhide on Tuesday.
>   
I'm interested in getting a few drivers going that haven't made it to
rawhide yet.  In particular, 'via'
and 'mga'.  What's the best process for helping out with this?  Is is
straight forward to just grab
the latest driver from GIT and build a new/improved RPM?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



From rc040203 at freenet.de  Mon Nov 19 14:42:04 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 19 Nov 2007 15:42:04 +0100
Subject: Optional packages for the build-time testsuite runs?
In-Reply-To: <20071119132442.GA14216@host0.dyn.jankratochvil.net>
References: <20071119132442.GA14216@host0.dyn.jankratochvil.net>
Message-ID: <1195483324.28534.239.camel@mccallum.corsepiu.local>


On Mon, 2007-11-19 at 14:24 +0100, Jan Kratochvil wrote:
> Hi all,
> 
> GDB package has its own large testsuite which is being run automatically from
> .spec %check during the build to easily find any possible regressions.
> 
> This testsuite automatically detects existence of some other packages
> (gcc-gfortran gcc-java gcc-objc gcc-gnat) to run its optional parts to test
> these specific langauges GDB support.
> 
> These exotic languages/rpms (gcc-gfortran gcc-java gcc-objc gcc-gnat) may not
> be commonly installed on the target systems where one may just want to
> `rpmbuild --rebuild' the .src.rpm for various reasons (such as using newer GDB
> in an older Fedora system).
> 
> Listing gcc-gfortran/gcc-java/gcc-objc/gcc-gnat into BuildRequires (now since
> gdb-6.7.1-4.fc9) just for the testsuite purposes brings:
>   pro) It enables the testsuite to run in Koji/mock.
>   con) It creates a burden for the users just rebuilding the rpm on their Fedora.
> 
> Isn't there a way to do some?
> 	%if %{mock}
> 	BuildRequires: gcc-gfortran gcc-java gcc-objc gcc-gnat
> 	%endif
> Tried
> 	%if 0%{?dist:1}
> but %dist is defined even for simple --rebuild by the redhat-rpm-config rpm.
What I have done in similar situations [1] is applying rpm's
--with/--without in combination with koji scratch builds and local
builds.

I.e. I am using %{?_with_XXX} and friends inside of specs, such that you
can specify them on rpmbuild's command-line for manual local builds. 

For chrooted "non-production/test-builds" (e.g. koji scratch-builts) I
edit the spec (adding %define _with_XXX <something> to the top of the
spec).

A better approach probably would be to have way to pass
rpmbuild-parameters to koji/mock for scratch builds. 

Ralf


[1] In my case primarily testsuites which require network access (N/A in
mock) and/or packages which are not part of Fedora.




From rdieter at math.unl.edu  Mon Nov 19 15:06:38 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 19 Nov 2007 09:06:38 -0600
Subject: ggz reviews approved, comaintainers welcome
References: <fhs4ic$mt2$1@ger.gmane.org>
	<1195480884.6241.6.camel@localhost.localdomain>
Message-ID: <fhs8pu$71f$1@ger.gmane.org>

Matthias Clasen wrote:

> On Mon, 2007-11-19 at 07:54 -0600, Rex Dieter wrote:
>> The first batch of ggz-related reviews have been approved,
>> libggz: http://bugzilla.redhat.com/370741
>> ggz-client-libs: http://bugzilla.redhat.com/370751 (pending cvsadmin)

> ... I wondered if you
> plan to package other parts of ggz apart from libggz itself ?
> gnome-games seems to need at least ggzdmod.

no plans, atm.

My primary motivation was these are the minimal deps needed for kdegames(4).

-- Rex




From varekova at redhat.com  Mon Nov 19 15:09:16 2007
From: varekova at redhat.com (Ivana Varekova)
Date: Mon, 19 Nov 2007 16:09:16 +0100
Subject: gd static library
Message-ID: <4741A71C.2030200@redhat.com>

Hello,
is there any package which uses gd static library libgd.a? I want to 
remove it from gd-devel subpackage but I'm not sure whether there is no 
package using it.
Thanks.
Ivana Varekova



From lkundrak at redhat.com  Mon Nov 19 15:12:14 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 19 Nov 2007 16:12:14 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <47418E9A.9040603@leemhuis.info>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
	<47418E9A.9040603@leemhuis.info>
Message-ID: <1195485134.7218.23.camel@localhost.localdomain>


On Mon, 2007-11-19 at 14:24 +0100, Thorsten Leemhuis wrote:
> On 19.11.2007 14:07, Lubomir Kundrak wrote:
> > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> >> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
> >>     * transparently handle local or remote console (via ssh)
> >>           o allow configuration of remote services
> > this is possible now:
> > ssh -X my.server system-config-httpd
> 
> Wile at it: For me as heavy sudo user it does not work properly:
> https://bugzilla.redhat.com/show_bug.cgi?id=142648
> https://bugzilla.redhat.com/show_bug.cgi?id=164671

It can be fixed easily by dumping sudo.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From ajackson at redhat.com  Mon Nov 19 15:47:29 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 19 Nov 2007 10:47:29 -0500
Subject: Severe X breakage heads up
In-Reply-To: <47419CA5.9050204@mlbassoc.com>
References: <1194294608.15341.204.camel@localhost.localdomain>
	<47419CA5.9050204@mlbassoc.com>
Message-ID: <1195487249.2292.40.camel@localhost.localdomain>

On Mon, 2007-11-19 at 07:24 -0700, Gary Thomas wrote:
> Adam Jackson wrote:
> > I plan to rebase the X server to git master a week from today (Monday,
> > November 12), which means the changes should hit rawhide on Tuesday.
> >   
> I'm interested in getting a few drivers going that haven't made it to
> rawhide yet.  In particular, 'via'
> and 'mga'.  What's the best process for helping out with this?  Is is
> straight forward to just grab
> the latest driver from GIT and build a new/improved RPM?

Grab the newest driver from git, update the buildreqs in the specfile to
be xorg-x11-server-devel >= 1.4.99.1, and try to build it.  If it works,
awesome.  If not, the driver probably needs to be ported to
libpciaccess.

There's a rough howto for porting on the Xorg wiki:

http://xorg.freedesktop.org/wiki/PciReworkHowto

It's mostly mechanical, but there are some bits that may require actual
understanding of PCI.  If you port a driver and get it working, either
send me the patch or post it to xorg at lists.freedesktop.org and we'll get
it merged.

- ajax



From rc040203 at freenet.de  Mon Nov 19 15:15:10 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 19 Nov 2007 16:15:10 +0100
Subject: gd static library
In-Reply-To: <4741A71C.2030200@redhat.com>
References: <4741A71C.2030200@redhat.com>
Message-ID: <1195485310.28534.243.camel@mccallum.corsepiu.local>


On Mon, 2007-11-19 at 16:09 +0100, Ivana Varekova wrote:
> Hello,
> is there any package which uses gd static library libgd.a? I want to 
> remove it from gd-devel subpackage but I'm not sure whether there is no 
> package using it.
If unsure, simply move the static libs to a *-static subpackage.

Ralf




From sundaram at fedoraproject.org  Mon Nov 19 15:10:16 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 19 Nov 2007 20:40:16 +0530
Subject: System-config Reworking Proposal
In-Reply-To: <1195485134.7218.23.camel@localhost.localdomain>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>	<1195477633.7218.21.camel@localhost.localdomain>	<47418E9A.9040603@leemhuis.info>
	<1195485134.7218.23.camel@localhost.localdomain>
Message-ID: <4741A758.6040201@fedoraproject.org>

Lubomir Kundrak wrote:
> On Mon, 2007-11-19 at 14:24 +0100, Thorsten Leemhuis wrote:
>> On 19.11.2007 14:07, Lubomir Kundrak wrote:
>>> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>>>> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
>>>>     * transparently handle local or remote console (via ssh)
>>>>           o allow configuration of remote services
>>> this is possible now:
>>> ssh -X my.server system-config-httpd
>> Wile at it: For me as heavy sudo user it does not work properly:
>> https://bugzilla.redhat.com/show_bug.cgi?id=142648
>> https://bugzilla.redhat.com/show_bug.cgi?id=164671
> 
> It can be fixed easily by dumping sudo.

What? Why would we be dumping sudo?

Rahul



From tmz at pobox.com  Mon Nov 19 15:30:36 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Mon, 19 Nov 2007 10:30:36 -0500
Subject: comps comps-el4.xml.in, 1.8, 1.9 comps-el5.xml.in, 1.9, 1.10
	comps-f7.xml.in, 1.273, 1.274 comps-f8.xml.in, 1.177, 1.178
	comps-f9.xml.in, 1.185, 1.186 comps-fe6.xml.in, 1.380, 1.381
In-Reply-To: <200711191509.lAJF9rUh020987@cvs-int.fedora.redhat.com>
References: <200711191509.lAJF9rUh020987@cvs-int.fedora.redhat.com>
Message-ID: <20071119153036.GM320@psilocybe.teonanacatl.org>

Dennis Gilmore wrote:
> +    <id>fedora-packager</id>
> +    <_name>Fedora Packager</_name>
> +    <_description>Tools and Utilities needed by a Fedora Packager</_description>
> +    <default>false</default>
> +    <uservisible>true</uservisible>
> +    <packagelist>
> +      <packagereq type="mandatory">mock</packagereq>
> +      <packagereq type="mandatory">koji</packagereq>
> +      <packagereq type="mandatory">bodhi-client</packagereq>
> +      <packagereq type="mandatory">plague-client</packagereq>
> +      <packagereq type="mandatory">rpm-build</packagereq>
> +      <packagereq type="mandatory">rpmdevtools</packagereq>
> +      <packagereq type="mandatory">cvs</packagereq>
> +      <packagereq type="mandatory">mercurial</packagereq>
> +      <packagereq type="mandatory">git</packagereq>
> +      <packagereq type="mandatory">bzr</packagereq>
> +      <packagereq type="mandatory">mock</packagereq>
> +    </packagelist>
> +  </group>
> +  <group>

Is there any reason why mock is listed twice in the comps changes?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Religion. A daughter of Hope and Fear, explaining to Ignorance the
nature of the Unknowable.
    -- Ambrose Bierce, The Enlarged Devil's Dictionary, 1906

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/6a6a8d84/attachment.sig>

From sgrubb at redhat.com  Mon Nov 19 15:33:59 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 19 Nov 2007 10:33:59 -0500
Subject: System-config Reworking Proposal
In-Reply-To: <4741A758.6040201@fedoraproject.org>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195485134.7218.23.camel@localhost.localdomain>
	<4741A758.6040201@fedoraproject.org>
Message-ID: <200711191034.00189.sgrubb@redhat.com>

On Monday 19 November 2007 10:10:16 am Rahul Sundaram wrote:
> > It can be fixed easily by dumping sudo.
>
> What? Why would we be dumping sudo?

We won't be. Its not his decision to make.

-Steve



From dennis at ausil.us  Mon Nov 19 15:36:00 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Mon, 19 Nov 2007 09:36:00 -0600
Subject: comps comps-el4.xml.in, 1.8, 1.9 comps-el5.xml.in, 1.9,
	1.10 comps-f7.xml.in, 1.273, 1.274 comps-f8.xml.in, 1.177,
	1.178 comps-f9.xml.in, 1.185, 1.186 comps-fe6.xml.in, 1.380, 1.381
In-Reply-To: <20071119153036.GM320@psilocybe.teonanacatl.org>
References: <200711191509.lAJF9rUh020987@cvs-int.fedora.redhat.com>
	<20071119153036.GM320@psilocybe.teonanacatl.org>
Message-ID: <200711190936.00788.dennis@ausil.us>

On Monday 19 November 2007, Todd Zullinger wrote:
> Dennis Gilmore wrote:
> > +    <id>fedora-packager</id>
> > +    <_name>Fedora Packager</_name>
> > +    <_description>Tools and Utilities needed by a Fedora
> > Packager</_description> +    <default>false</default>
> > +    <uservisible>true</uservisible>
> > +    <packagelist>
> > +      <packagereq type="mandatory">mock</packagereq>
> > +      <packagereq type="mandatory">koji</packagereq>
> > +      <packagereq type="mandatory">bodhi-client</packagereq>
> > +      <packagereq type="mandatory">plague-client</packagereq>
> > +      <packagereq type="mandatory">rpm-build</packagereq>
> > +      <packagereq type="mandatory">rpmdevtools</packagereq>
> > +      <packagereq type="mandatory">cvs</packagereq>
> > +      <packagereq type="mandatory">mercurial</packagereq>
> > +      <packagereq type="mandatory">git</packagereq>
> > +      <packagereq type="mandatory">bzr</packagereq>
> > +      <packagereq type="mandatory">mock</packagereq>
> > +    </packagelist>
> > +  </group>
> > +  <group>
>
> Is there any reason why mock is listed twice in the comps changes?

i messed up 
will correct now

Thanks for noticing



From nphilipp at redhat.com  Mon Nov 19 15:37:52 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 19 Nov 2007 16:37:52 +0100
Subject: working with gnome project/other distros together on system
	tools (was: Re: System-config Reworking Proposal)
In-Reply-To: <4741984F.30006@leemhuis.info>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
	<4741984F.30006@leemhuis.info>
Message-ID: <1195486672.14998.39.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:

> Just wondering: Why don't we work towards getting some sane config tools
> (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> interest)? Sure, that way other distros will benefit from out work as
> well, but on the other hand having stuff as de-facto part of Gnome and
> used by other distros afaics lead to better tools and a better user
> experience, which overall leads to a better "Linux".

AFAIK, some stuff, e.g. date and time setting via the time applet,
creating users, is already worked on for GNOME. Whether these will cover
all aspects (e.g. also server specific stuff), I don't know. Whether
these should cover non-desktop aspects at all can also be disputed ;-).

Certainly, once UI and logic of the existing tools are sufficiently
separated the logic could be used from applets/tools more tightly
integrated into the desktop environment of choice if there's the need.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Mon Nov 19 15:39:25 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 19 Nov 2007 16:39:25 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <200711191034.00189.sgrubb@redhat.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195485134.7218.23.camel@localhost.localdomain>
	<4741A758.6040201@fedoraproject.org>
	<200711191034.00189.sgrubb@redhat.com>
Message-ID: <1195486765.14998.42.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-19 at 10:33 -0500, Steve Grubb wrote:
> On Monday 19 November 2007 10:10:16 am Rahul Sundaram wrote:
> > > It can be fixed easily by dumping sudo.
> >
> > What? Why would we be dumping sudo?
> 
> We won't be. Its not his decision to make.

As all security people he may be a little bit adverse to stuff carrying
around a setuid bit ;-). </ObNotFriday>

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From michael.wiktowy at gmail.com  Mon Nov 19 15:43:46 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Mon, 19 Nov 2007 10:43:46 -0500
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
Message-ID: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>

Hi,

It seems recently one of my two onboard NICs has decided to not
remember its MAC address between reboots. Since I just updated the
BIOS firmware, I suspect that as the culprit but I also upgraded to
Fedora 8 about the same time so it may be to blame. I don't know.

Windows 2000 reports a MAC of 00:00:00:00:00:00 and won't start that
interface at all. When I boot Fedora 8, NetworkManager seems to assign
a seemingly randomly chosen MAC and generates an ethX interface for it
... everytime ... a different ethX entry. So needless to say, there
are a lot of scripts starting to accumulate in my
/etc/sysconfig/networking directory. Looking at the NIC register dump
using 'ethtool -d <device>, a MAC can be assigned using 'ifconfig
<device> hw ether <MAC>' but it just gets reset on the next reboot.

Is there a way for NetworkManager (or traditional network tools) to
identify these NICs (other than the non-persistent MAC) so that the
NIC can have a constant MAC assigned to it? Is there a way for me to
stop NetworkManager from keeping old non-existent NIC configs in the
ifcfg-ethx.bak files?

FYI:
It is a ASUS A7N8X Deluxe motherboard with two onboard NICs (the other
NIC seems to work just fine).

[root at localhost ~]# lspci
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different
version?) (rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio
Processing Unit (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97
Audio Controler (MCP) (rev a1)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev a3)
00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire
(IEEE 1394) Controller (rev a3)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112
[SATALink/SATARaid] Serial ATA Controller (rev 02)
02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated
Fast Ethernet Controller [Tornado] (rev 40)
03:00.0 VGA compatible controller: ATI Technologies Inc R430 [Radeon
X800 XL] (PCIe)
03:00.1 Display controller: ATI Technologies Inc R430 [Radeon X800 XL]
(PCIe) (Secondary)


/Mike



From kwizart at gmail.com  Mon Nov 19 15:52:19 2007
From: kwizart at gmail.com (KH KH)
Date: Mon, 19 Nov 2007 16:52:19 +0100
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
Message-ID: <e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>

2007/11/19, Michael Wiktowy <michael.wiktowy at gmail.com>:
> Hi,
>
> It seems recently one of my two onboard NICs has decided to not
> remember its MAC address between reboots. Since I just updated the
> BIOS firmware, I suspect that as the culprit but I also upgraded to
> Fedora 8 about the same time so it may be to blame. I don't know.
When you update the bios, the tool accept a parameter for the mac
address.. Each time you flash the bios, you need to give the mac
address for the integrated ethernet (usually written on the top of the
mainboard ), so it can be hardcoded into the bios...

Nicolas (kwizart)



From fedora at camperquake.de  Mon Nov 19 15:53:38 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 19 Nov 2007 16:53:38 +0100
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
Message-ID: <20071119165338.03dfd1a0@dhcp03.addix.net>

Hi.

On Mon, 19 Nov 2007 16:52:19 +0100, KH KH wrote:

> When you update the bios, the tool accept a parameter for the mac
> address.. Each time you flash the bios, you need to give the mac
> address for the integrated ethernet (usually written on the top of the
> mainboard ), so it can be hardcoded into the bios...

I have updated some BIOSes in my time, but I never had to do that.



From jos at xos.nl  Mon Nov 19 15:58:14 2007
From: jos at xos.nl (Jos Vos)
Date: Mon, 19 Nov 2007 16:58:14 +0100
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <20071119165338.03dfd1a0@dhcp03.addix.net>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<20071119165338.03dfd1a0@dhcp03.addix.net>
Message-ID: <20071119155814.GA26453@jasmine.xos.nl>

On Mon, Nov 19, 2007 at 04:53:38PM +0100, Ralf Ertzinger wrote:

> I have updated some BIOSes in my time, but I never had to do that.

No, and I've even never heard that story.

Usually, when MAC addresses become 00:00..., your NIC has a serious
problem.  I've had that in a few cases, all after a power dip IIRC,
and I had to replace them.

--   
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From johannbg at hi.is  Mon Nov 19 15:58:43 2007
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Mon, 19 Nov 2007 15:58:43 +0000
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <20071119165338.03dfd1a0@dhcp03.addix.net>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<20071119165338.03dfd1a0@dhcp03.addix.net>
Message-ID: <4741B2B3.8080903@hi.is>

Ralf Ertzinger wrote:
> Hi.
>
> On Mon, 19 Nov 2007 16:52:19 +0100, KH KH wrote:
>
>   
>> When you update the bios, the tool accept a parameter for the mac
>> address.. Each time you flash the bios, you need to give the mac
>> address for the integrated ethernet (usually written on the top of the
>> mainboard ), so it can be hardcoded into the bios...
>>     
>
> I have updated some BIOSes in my time, but I never had to do that.
>
>   
Me neither...

Could you provide HW info
so other can keep this at the back of their heads :)

Best regards
           Johann B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 365 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/2709b966/attachment.vcf>

From Michael_E_Brown at dell.com  Mon Nov 19 16:03:51 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 19 Nov 2007 10:03:51 -0600
Subject: Wine 0.9.49?
In-Reply-To: <20071118220241.GI320@psilocybe.teonanacatl.org>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<f224c6140711172258n5ed1a0edo56a2472a81b8d70a@mail.gmail.com>
	<1195375630.29118.7.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180402u13e20be9w1984527d4d347240@mail.gmail.com>
	<1195395349.29118.18.camel@gilboa-home-dev.localdomain>
	<3170f42f0711180634g2b8ba766m2fca04d19dd4445f@mail.gmail.com>
	<1195399865.29118.22.camel@gilboa-home-dev.localdomain>
	<1195401110.3245.5.camel@eagle.danny.cz>
	<20071118171029.GC6174@humbolt.us.dell.com>
	<20071118220241.GI320@psilocybe.teonanacatl.org>
Message-ID: <20071119160350.GA23478@humbolt.us.dell.com>

On Sun, Nov 18, 2007 at 05:02:41PM -0500, Todd Zullinger wrote:
> Michael E Brown wrote:
> > You might want to take a look at the mock 0.8.x yum caching. With
> > the yum cache, it is likely that you would not need the squid cache
> > anymore.  The only thing that is re-downloaded is the yum metadata,
> > if it changes.  This is enabled by default, and you can safely set
> > the timeout on it to be as high as you like.
> 
> For those of us with a local mirror on the LAN, is it enough to simply
> set config_opts['plugin_conf']['yum_cache_enable'] = False in the mock
> defaults.cfg to disable the yum cache?

Correct.

> Also, is there a proper way to clear the cache, or is it fine to just
> rm /var/lib/mock/cache/*/yum_cache ?

Yes. You probably have to do that as root.

--
Michael



From si at siancu.net  Mon Nov 19 16:09:33 2007
From: si at siancu.net (Stelian Iancu)
Date: Mon, 19 Nov 2007 17:09:33 +0100
Subject: Any experience with bluetooth keyboard and mice
In-Reply-To: <1195467043.10878.102.camel@cookie.hadess.net>
References: <1195425323.17403.3.camel@tiger>
	<1195467043.10878.102.camel@cookie.hadess.net>
Message-ID: <d9ab550e0711190809k74f5d4e7y5397a11218146874@mail.gmail.com>

On 11/19/07, Bastien Nocera <bnocera at redhat.com> wrote:
>
> On Sun, 2007-11-18 at 17:35 -0500, Louis E Garcia II wrote:
> > Looking at Dell's desktop with bluetooth keyboard and mouse. I'm not
> > sure about the maturity level of bluetooth in F8. Will the installer and
> > gnome desktop work?
>
> No, and yes, respectively. Note that you'll need at least a mouse to be
> able to log in and setup the keyboard and mouse.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Are there any plans to implement out-of-the box support for bluetooth
keyboards and mice in Fedora starting from the installer and all the
way through the OS?

S.



From nicolas.mailhot at laposte.net  Mon Nov 19 16:14:39 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 19 Nov 2007 17:14:39 +0100 (CET)
Subject: comps comps-el4.xml.in, 1.8, 1.9 comps-el5.xml.in, 1.9,
 1.10 comps-f7.xml.in, 1.273, 1.274 comps-f8.xml.in, 1.177,
 1.178 comps-f9.xml.in, 1.185, 1.186 comps-fe6.xml.in, 1.380, 1.381
Message-ID: <2443.192.54.193.53.1195488879.squirrel@rousalka.dyndns.org>


Le Lun 19 novembre 2007 16:30, Todd Zullinger a ?crit :

> Is there any reason why mock is listed twice in the comps changes?

Because whoever did the change forgot to run the xslt sanity checker
referenced on
http://fedoraproject.org/wiki/PackageMaintainers/CompsXml

Regards,

-- 
Nicolas Mailhot



From pertusus at free.fr  Mon Nov 19 16:15:29 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Nov 2007 17:15:29 +0100
Subject: gd static library
In-Reply-To: <4741A71C.2030200@redhat.com>
References: <4741A71C.2030200@redhat.com>
Message-ID: <20071119161529.GA25574@free.fr>

On Mon, Nov 19, 2007 at 04:09:16PM +0100, Ivana Varekova wrote:
> Hello,
> is there any package which uses gd static library libgd.a? I want to remove 

No package in fedora should link against libgd.a. It may be useful 
for in-house code that produces images, for example, and want to be 
portable, see for example the controversial text I put here:
http://fedoraproject.org/wiki/PatriceDumas

In my opinion you could remove the static lib, and you should add it 
back in a -static subpackage if somebody asks for it. Or just put it in
a static subpackage right now.

--
Pat



From pemboa at gmail.com  Mon Nov 19 16:21:32 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 19 Nov 2007 10:21:32 -0600
Subject: System-config Reworking Proposal
In-Reply-To: <1195470779.7213.12.camel@cyberelk.elk>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
Message-ID: <16de708d0711190821j11c42b24lea102de11292e91e@mail.gmail.com>

On Nov 19, 2007 5:12 AM, Tim Waugh <twaugh at redhat.com> wrote:
> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> > Please comment on the idea.
>
> I'd like to know whether you are considering system-config-printer to be
> part of this scheme.  CUPS configuration is quite different from other
> configuration tools, and a method based on altering configuration files
> would be a big regression.


I'm not familiar with how system-config-printer works, if it uses port
631, then no I didn't consider yet at all. And I'm definetly not
considering it going through text configs first - that was just the
most obvious target so I considered it first.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From fedora at leemhuis.info  Mon Nov 19 16:23:05 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 17:23:05 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071119095558.GC2584@free.fr>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>
	<20071119095558.GC2584@free.fr>
Message-ID: <4741B869.9040508@leemhuis.info>

On 19.11.2007 10:55, Patrice Dumas wrote:
> On Mon, Nov 19, 2007 at 06:56:22AM +0100, Thorsten Leemhuis wrote:
>> Someone in a lot cases (like this one) could just realize many of the
>> changes in the Packaging Guidelines directly in CVS for all effected
>> packages. I think we should do that way more often and get away from the
>> mantra "this is my package and nobody else is allowed to touch it" --
>> that's why I took this particular issue as example to just show how it
>> could be done. Now I expect from FESCo advice for this particular
>> example as well as the general concept where one persons realizes
>> changes in all effected packages directly in CVS.
> I fully agree, but it is already explicitely permitted in
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages

Well, I actually wrote most of it, but reality and documentation are two
different things afaics, thus...

> All is needed is a set of scripts and maybe FESCo taking a lead. 

...FESCo really is the one that needs to take a lead and say "we want
that". Especially because some of the packages might be protected by
ACLs, which creates further problems.

> One
> occasion I see would be the mass rebuild of packages that depend on
> doxygen after the 'non reproducible anchors bug' is fixed -- that is
> doxygen is updated to latest version.

Firefox IMHO is the way better example -- I fail to understand why we
didn't create a script that rebuilds all packages that depend on it once
it's build and in the buildroot. Yes,

 * that could delay the firefox push by one hour or a bit more -- small
problem, but not a big one, as stuff often gets delayed by other things
as well (the ones with access to the keys being asleep for example)

 * some packages might not compile with the new firefox (but most likely
will)

but that's way better then a broken repo, as a new firefox in the repo
is not much of a help if it won't get installed on the systems by yum,
as most will have yelp or other stuff installed that needs the exact
version of firefox it was build against.

Actually creating such a script was the plan early this year when I
still was FESCo chair, but seems the person that wanted to take care of
it forgot about it in the merge noise (no wonder with all those changes,
so I don't blame him).

CU
knurd



From pemboa at gmail.com  Mon Nov 19 16:27:44 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 19 Nov 2007 10:27:44 -0600
Subject: System-config Reworking Proposal
In-Reply-To: <1195477633.7218.21.camel@localhost.localdomain>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
Message-ID: <16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>

On Nov 19, 2007 7:07 AM, Lubomir Kundrak <lkundrak at redhat.com> wrote:
> Hi,
>
> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> > I have expressed my ideas[1] to add and rework some of the
> > functionality of the system-config tools with the hope of making them
> > a bit more innovative and useful.
> >
> > Please comment on the idea.
>
> > Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
> >
> >     * transparently handle local or remote console (via ssh)
> >           o allow configuration of remote services
>
> this is possible now:
> ssh -X my.server system-config-httpd

One question: I know about this method, but have never tried it myself
- doesn't it require an xserver on the host?

One comment: The crowd that really love the system-config tools would
like prefer not to be doing x forwarding via SSH


> >           o possible allow for OS independent usage (example: system-config-httpd could be used from Windows XP)
>
> You can do the very same thing from Windows XP.

I was thinking more in terms of the user just running system-config-*
on Fedora|Windows|* and just enter in a host and passkey|user+pass and
make changes to the target system

> >           o allow for those who prefer not to run server tools with a X server installed to make use of the system-config tools
>
> None of the system-config-* tools depends on X server except for
> system-config-display.

True, but you do generally need a GUI to make use of the GUI system-config tools

> >     * allows for centrally logging system-config actions (audit trail)
> >     * standardize routines/functionality commonly used by system-config tools
>
> These seem to be a good ideas to me.
>
> Regards,
> --
> Lubomir Kundrak (Red Hat Security Response Team)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From pemboa at gmail.com  Mon Nov 19 16:29:06 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 19 Nov 2007 10:29:06 -0600
Subject: System-config Reworking Proposal
In-Reply-To: <47418E9A.9040603@leemhuis.info>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
	<47418E9A.9040603@leemhuis.info>
Message-ID: <16de708d0711190829h35ccf3ddj2a4aec67be878b00@mail.gmail.com>

On Nov 19, 2007 7:24 AM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 19.11.2007 14:07, Lubomir Kundrak wrote:
> > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> >> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
> >>     * transparently handle local or remote console (via ssh)
> >>           o allow configuration of remote services
> > this is possible now:
> > ssh -X my.server system-config-httpd
>
> Wile at it: For me as heavy sudo user it does not work properly:
> https://bugzilla.redhat.com/show_bug.cgi?id=142648
> https://bugzilla.redhat.com/show_bug.cgi?id=164671


Wel the idea was that the virtual console would be able to execute (or
not as the case might be) through sudo if that is what the system used


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From pemboa at gmail.com  Mon Nov 19 16:33:36 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 19 Nov 2007 10:33:36 -0600
Subject: System-config Reworking Proposal
In-Reply-To: <1195480199.14998.21.camel@gibraltar.str.redhat.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
Message-ID: <16de708d0711190833x799febb8h95c0ea11b429b481@mail.gmail.com>

On Nov 19, 2007 7:49 AM, Nils Philippsen <nphilipp at redhat.com> wrote:
> For my tools (-date, -nfs, -samba, -services, -users), just being able
> to edit files is also not sufficient. Often these tools don't edit files
> themselves but use e.g. chkconfig or libuser, partly it isn't even known
> whether local files are changed or some objects in an LDAP directory.

Well I was considering that the doCommand, doCommandWait to take care
of that. Am I underestimating that need?

> In my eyes, we first need to get UI, logic and privileged operations
> cleanly separated. Then we can think about additional stuff like logging
> of operations (would be put between UI and logic) or move stuff from
> using usermode to PolicyKit.

Seems like something that can be in parallel as part of the reworking.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From sgrubb at redhat.com  Mon Nov 19 16:35:11 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 19 Nov 2007 11:35:11 -0500
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711190829h35ccf3ddj2a4aec67be878b00@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<47418E9A.9040603@leemhuis.info>
	<16de708d0711190829h35ccf3ddj2a4aec67be878b00@mail.gmail.com>
Message-ID: <200711191135.11606.sgrubb@redhat.com>

On Monday 19 November 2007 11:29:06 am Arthur Pemberton wrote:
> > Wile at it: For me as heavy sudo user it does not work properly:
> > https://bugzilla.redhat.com/show_bug.cgi?id=142648
> > https://bugzilla.redhat.com/show_bug.cgi?id=164671
>
> Wel the idea was that the virtual console would be able to execute (or
> not as the case might be) through sudo if that is what the system used

The above mentioned bz is against RHEL4. Sudo in F7/8 has env_keep with 
XAUTHORITY in the default config.  So, I think F9 sudo+system-config should 
work correctly.

-Steve



From mclasen at redhat.com  Mon Nov 19 16:46:00 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 19 Nov 2007 11:46:00 -0500
Subject: working with gnome project/other distros together on system
	tools (was: Re: System-config Reworking Proposal)
In-Reply-To: <1195486672.14998.39.camel@gibraltar.str.redhat.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
	<4741984F.30006@leemhuis.info>
	<1195486672.14998.39.camel@gibraltar.str.redhat.com>
Message-ID: <1195490761.19352.11.camel@localhost.localdomain>


On Mon, 2007-11-19 at 16:37 +0100, Nils Philippsen wrote:
> On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
> 
> > Just wondering: Why don't we work towards getting some sane config tools
> > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> > interest)? Sure, that way other distros will benefit from out work as
> > well, but on the other hand having stuff as de-facto part of Gnome and
> > used by other distros afaics lead to better tools and a better user
> > experience, which overall leads to a better "Linux".
> 
> AFAIK, some stuff, e.g. date and time setting via the time applet,
> creating users, is already worked on for GNOME. Whether these will cover
> all aspects (e.g. also server specific stuff), I don't know. Whether
> these should cover non-desktop aspects at all can also be disputed ;-).
> 
> Certainly, once UI and logic of the existing tools are sufficiently
> separated the logic could be used from applets/tools more tightly
> integrated into the desktop environment of choice if there's the need.

Might be worthwhile to point out that there is prior art in this area
with gnome-system-tools. They already have the ui/mechanism split and
are moving towards adopting PolicyKit. The traditional complaint about
them has been that they have no distro adoption, but I recently learned
that probably at least Debian/Ubuntu, Gentoo and FreeBSD are using them
nowadays.

There are admittedly a few warts:
- the backends used to be written in perl (not sure if that is still the
case)
- they follow the kitchen-sink approach of keeping everything in a
single system-tools-backends package 

If we are talking about cross-distro collaboration for traditional
system-config tools, that may be the leading contender. 

What we in the desktop team want to push a little further in F9 is to
move some system configuration tasks into the regular tools where that
makes sense. An early example of that is the time+timezone setting
inside the clock applet, other examples to follow will be a "Use these
settings system-wide" button for the power management preferences and
some other areas where it makes sense. Access to this will be controlled
via PolicyKit as well.


Matthias




From gilboad at gmail.com  Mon Nov 19 16:46:54 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Mon, 19 Nov 2007 18:46:54 +0200
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
Message-ID: <1195490814.8410.8.camel@gilboa-work-dev.localdomain>


On Mon, 2007-11-19 at 16:52 +0100, KH KH wrote:
> 2007/11/19, Michael Wiktowy <michael.wiktowy at gmail.com>:
> > Hi,
> >
> > It seems recently one of my two onboard NICs has decided to not
> > remember its MAC address between reboots. Since I just updated the
> > BIOS firmware, I suspect that as the culprit but I also upgraded to
> > Fedora 8 about the same time so it may be to blame. I don't know.
> When you update the bios, the tool accept a parameter for the mac
> address.. Each time you flash the bios, you need to give the mac
> address for the integrated ethernet (usually written on the top of the
> mainboard ), so it can be hardcoded into the bios...
> 
> Nicolas (kwizart)
> 

I've updated my share of BIOS... Large share.
Never seen a BIOS upgrade that erases the MAC address.

Most likely the on-board NIC has been fried.

P.S. AFAIR you manually set the MAC address by adding "MACADDR=00:..."
to /etc/sysconfig/network-scripts/ifcfg-ethX

- Gilboa



From rc040203 at freenet.de  Mon Nov 19 16:49:44 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 19 Nov 2007 17:49:44 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <4741B869.9040508@leemhuis.info>
References: <1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>
	<20071119095558.GC2584@free.fr>  <4741B869.9040508@leemhuis.info>
Message-ID: <1195490984.28534.253.camel@mccallum.corsepiu.local>


On Mon, 2007-11-19 at 17:23 +0100, Thorsten Leemhuis wrote:
> On 19.11.2007 10:55, Patrice Dumas wrote:
> > On Mon, Nov 19, 2007 at 06:56:22AM +0100, Thorsten Leemhuis wrote:
> >> Someone in a lot cases (like this one) could just realize many of the
> >> changes in the Packaging Guidelines directly in CVS for all effected
> >> packages. I think we should do that way more often and get away from the
> >> mantra "this is my package and nobody else is allowed to touch it" --
> >> that's why I took this particular issue as example to just show how it
> >> could be done. Now I expect from FESCo advice for this particular
> >> example as well as the general concept where one persons realizes
> >> changes in all effected packages directly in CVS.
> > I fully agree, but it is already explicitely permitted in
> > http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
> 
> Well, I actually wrote most of it, but reality and documentation are two
> different things afaics, thus...
> 
> > All is needed is a set of scripts and maybe FESCo taking a lead. 
> 
> ...FESCo really is the one that needs to take a lead and say "we want
> that". Especially because some of the packages might be protected by
> ACLs, which creates further problems.
You are taking the words right out of my mouth.

> > One
> > occasion I see would be the mass rebuild of packages that depend on
> > doxygen after the 'non reproducible anchors bug' is fixed -- that is
> > doxygen is updated to latest version.
Right. I am wonder when this update willl happen ;)

> Firefox IMHO is the way better example 
Other examples:

* The perl base package split so far has not been reflected to quite a
number of perl packages being shipped (Probably because of their
maintainers having lost interest in Fedora).

* The FPG wants to split out static libs and to discontinue them
whenever possible. Several packagers still ship static libs as part of
their devel packages and ignore corresponding requests.

...

Technically, changes related to these topics are close to trivial (and
partially scriptable) for an "experienced user". The "normal" BZ'em, nag
maintainer and launch AWOL-process if necessary is much more effort and
(at least to me) too inconvenient on most occasions (ie. unless
inevitable for technical reasons).

Ralf




From jkeating at redhat.com  Mon Nov 19 16:49:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 11:49:42 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <4741B869.9040508@leemhuis.info>
References: <1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>
	<20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com>
	<47412586.4020502@leemhuis.info> <20071119095558.GC2584@free.fr>
	<4741B869.9040508@leemhuis.info>
Message-ID: <20071119114942.697bc4b0@redhat.com>

On Mon, 19 Nov 2007 17:23:05 +0100
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> Firefox IMHO is the way better example -- I fail to understand why we
> didn't create a script that rebuilds all packages that depend on it
> once it's build and in the buildroot. Yes,

Again, it takes /somebody/ to write it.  FESCo can say all they want "I
want this to happen", but until somebody sits down and cranks out a
script, it's just not going to happen.

Instead many of us are working toward a situation where this one-off
won't be necessary.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/78e1ef19/attachment.sig>

From bruno at wolff.to  Mon Nov 19 16:26:01 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 19 Nov 2007 10:26:01 -0600
Subject: System-config Reworking Proposal
In-Reply-To: <1195477633.7218.21.camel@localhost.localdomain>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
Message-ID: <20071119162601.GA23528@wolff.to>

On Mon, Nov 19, 2007 at 14:07:13 +0100,
  Lubomir Kundrak <lkundrak at redhat.com> wrote:
> 
> None of the system-config-* tools depends on X server except for
> system-config-display.

You can actually use system-config-display without X running if you use
a --set- option. I had need of this after upgrading to F8 to get a base
xorg.conf file I could work with, as I am not comfortable writing one from
scratch and X didn't work without one because it used an invalid mode.



From denis at poolshark.org  Mon Nov 19 16:52:11 2007
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 19 Nov 2007 17:52:11 +0100
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <1195490814.8410.8.camel@gilboa-work-dev.localdomain>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<1195490814.8410.8.camel@gilboa-work-dev.localdomain>
Message-ID: <4741BF3B.1010807@poolshark.org>

Gilboa Davara wrote:
> On Mon, 2007-11-19 at 16:52 +0100, KH KH wrote:
>> 2007/11/19, Michael Wiktowy <michael.wiktowy at gmail.com>:
>>> Hi,
>>>
>>> It seems recently one of my two onboard NICs has decided to not
>>> remember its MAC address between reboots. Since I just updated the
>>> BIOS firmware, I suspect that as the culprit but I also upgraded to
>>> Fedora 8 about the same time so it may be to blame. I don't know.
>> When you update the bios, the tool accept a parameter for the mac
>> address.. Each time you flash the bios, you need to give the mac
>> address for the integrated ethernet (usually written on the top of the
>> mainboard ), so it can be hardcoded into the bios...
>>
>> Nicolas (kwizart)
>>
> 
> I've updated my share of BIOS... Large share.
> Never seen a BIOS upgrade that erases the MAC address.
> 
> Most likely the on-board NIC has been fried.

typically the MAC address is programmed into an on-board eeprom 
connected to the NIC. That's probably what's fried (or simply erased).



From nphilipp at redhat.com  Mon Nov 19 16:55:12 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 19 Nov 2007 17:55:12 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711190833x799febb8h95c0ea11b429b481@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
	<16de708d0711190833x799febb8h95c0ea11b429b481@mail.gmail.com>
Message-ID: <1195491312.14998.47.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-19 at 10:33 -0600, Arthur Pemberton wrote:
> On Nov 19, 2007 7:49 AM, Nils Philippsen <nphilipp at redhat.com> wrote:
> > For my tools (-date, -nfs, -samba, -services, -users), just being able
> > to edit files is also not sufficient. Often these tools don't edit files
> > themselves but use e.g. chkconfig or libuser, partly it isn't even known
> > whether local files are changed or some objects in an LDAP directory.
> 
> Well I was considering that the doCommand, doCommandWait to take care
> of that. Am I underestimating that need?

That would work for chkconfig, but not libuser. I won't resort to
calling luser{add,mod,del} ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From Michael_E_Brown at dell.com  Mon Nov 19 16:57:08 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 19 Nov 2007 10:57:08 -0600
Subject: Optional packages for the build-time testsuite runs?
In-Reply-To: <1195483324.28534.239.camel@mccallum.corsepiu.local>
References: <20071119132442.GA14216@host0.dyn.jankratochvil.net>
	<1195483324.28534.239.camel@mccallum.corsepiu.local>
Message-ID: <20071119165707.GB23478@humbolt.us.dell.com>

On Mon, Nov 19, 2007 at 03:42:04PM +0100, Ralf Corsepius wrote:
> 
> On Mon, 2007-11-19 at 14:24 +0100, Jan Kratochvil wrote:
> > Hi all,
> > 
> > GDB package has its own large testsuite which is being run automatically from
> > .spec %check during the build to easily find any possible regressions.
> > 
> > This testsuite automatically detects existence of some other packages
> > (gcc-gfortran gcc-java gcc-objc gcc-gnat) to run its optional parts to test
> > these specific langauges GDB support.
> > 
> > These exotic languages/rpms (gcc-gfortran gcc-java gcc-objc gcc-gnat) may not
> > be commonly installed on the target systems where one may just want to
> > `rpmbuild --rebuild' the .src.rpm for various reasons (such as using newer GDB
> > in an older Fedora system).
> > 
> > Listing gcc-gfortran/gcc-java/gcc-objc/gcc-gnat into BuildRequires (now since
> > gdb-6.7.1-4.fc9) just for the testsuite purposes brings:
> >   pro) It enables the testsuite to run in Koji/mock.
> >   con) It creates a burden for the users just rebuilding the rpm on their Fedora.
> > 
> > Isn't there a way to do some?
> > 	%if %{mock}
> > 	BuildRequires: gcc-gfortran gcc-java gcc-objc gcc-gnat
> > 	%endif
> > Tried
> > 	%if 0%{?dist:1}
> > but %dist is defined even for simple --rebuild by the redhat-rpm-config rpm.
> What I have done in similar situations [1] is applying rpm's
> --with/--without in combination with koji scratch builds and local
> builds.
> 
> I.e. I am using %{?_with_XXX} and friends inside of specs, such that you
> can specify them on rpmbuild's command-line for manual local builds. 
> 
> For chrooted "non-production/test-builds" (e.g. koji scratch-builts) I
> edit the spec (adding %define _with_XXX <something> to the top of the
> spec).
> 
> A better approach probably would be to have way to pass
> rpmbuild-parameters to koji/mock for scratch builds. 

Two ideas:

1) Use the 'more_buildreqs' mock config:

config_opts['more_buildreqs']['srpm_name-version-release'] =
'dependency list'

2) Use a RPM macro defined in mock to enable this:

config_opts['macros']['%_exhaustive_testsuite'] = "1"

--
Michael



From overholt at redhat.com  Mon Nov 19 16:55:01 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Mon, 19 Nov 2007 11:55:01 -0500
Subject: Volunteers for fixing and/or maintaning Tomcat
In-Reply-To: <1195184868.32233.26.camel@localhost.localdomain>
References: <1195168424.29805.16.camel@localhost.localdomain>
	<1195184868.32233.26.camel@localhost.localdomain>
Message-ID: <1195491301.20121.4.camel@tophat.yyz.redhat.com>

Hi,

On Thu, 2007-11-15 at 19:47 -0800, Devrim G?ND?Z wrote:
> 
> On Fri, 2007-11-16 at 00:13 +0100, Lubomir Kundrak wrote:
> 
> > Is there anyone who would volunteer to fix and maintain tomcat?
> 
> I pushed tomcat5-5.5.25 to -devel with 2 new patches:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=244210
> 
> 5.5.25 already fixes some of the security issues. I will wait until
> tomorrow morning, and will push it to F-7 and F-8, too.

I didn't read fedora-devel since last week and just noticed this.  Does
this affect eclipse which requires tomcat5?

Thanks,

Andrew



From tcallawa at redhat.com  Mon Nov 19 16:57:28 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 19 Nov 2007 11:57:28 -0500
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195490984.28534.253.camel@mccallum.corsepiu.local>
References: <1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>
	<20071119095558.GC2584@free.fr>  <4741B869.9040508@leemhuis.info>
	<1195490984.28534.253.camel@mccallum.corsepiu.local>
Message-ID: <1195491448.3849.22.camel@localhost.localdomain>


On Mon, 2007-11-19 at 17:49 +0100, Ralf Corsepius wrote:
> * The perl base package split so far has not been reflected to quite a
> number of perl packages being shipped (Probably because of their
> maintainers having lost interest in Fedora).

To be fair, I fixed most of these a few weeks ago.

~spot



From sgrubb at redhat.com  Mon Nov 19 17:01:37 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 19 Nov 2007 12:01:37 -0500
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
	<16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
Message-ID: <200711191201.37903.sgrubb@redhat.com>

Hi,

I kind of missed the beginning of this thread...too many things going on, but 
this needs some discussion in my opinion.

> ? ? * allows for centrally logging system-config actions (audit trail)

The audit trail we are currently maintaining is set in the audit system. 
Whatever anyone designs needs to work correctly with the audit system since 
it will be watching a lot of the config files. When someone is remotely 
configuring a machine, the loginuid will need to be set correctly for the 
remote user. Libaudit also has logging functions (with Python bindings) that 
ensures all the important information is recorded in the audit trail. Besides 
creating an audit trail, you also need a way to search for information in the 
audit trail. The audit system already has the needed reporting tools and is 
getting new GUI based tools in F9.

Thanks,
-Steve



From rjones at redhat.com  Mon Nov 19 17:04:19 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 19 Nov 2007 17:04:19 +0000
Subject: RPM groups
Message-ID: <4741C213.6080308@redhat.com>

I can't find any documentation on the RPM "Group:" field, what it should 
contain, and whether Fedora has a policy on these (even a list of them 
would be a good start).

Also on the same subject, are these related to the groups printed by 
"yum grouplist" and the groups shown by PUP by any chance?  And if they 
are related, how?

Can someone help me out?

Thanks,

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/a76251d5/attachment.bin>

From Michael_E_Brown at dell.com  Mon Nov 19 17:09:48 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Mon, 19 Nov 2007 11:09:48 -0600
Subject: Optional packages for the build-time testsuite runs?
In-Reply-To: <1195483324.28534.239.camel@mccallum.corsepiu.local>
References: <20071119132442.GA14216@host0.dyn.jankratochvil.net>
	<1195483324.28534.239.camel@mccallum.corsepiu.local>
Message-ID: <20071119170948.GC23478@humbolt.us.dell.com>

On Mon, Nov 19, 2007 at 03:42:04PM +0100, Ralf Corsepius wrote:
> 
> On Mon, 2007-11-19 at 14:24 +0100, Jan Kratochvil wrote:
> > Hi all,
> > 
> > GDB package has its own large testsuite which is being run automatically from
> > .spec %check during the build to easily find any possible regressions.
> > 
> > This testsuite automatically detects existence of some other packages
> > (gcc-gfortran gcc-java gcc-objc gcc-gnat) to run its optional parts to test
> > these specific langauges GDB support.
> > 
> > These exotic languages/rpms (gcc-gfortran gcc-java gcc-objc gcc-gnat) may not
> > be commonly installed on the target systems where one may just want to
> > `rpmbuild --rebuild' the .src.rpm for various reasons (such as using newer GDB
> > in an older Fedora system).
> > 
> > Listing gcc-gfortran/gcc-java/gcc-objc/gcc-gnat into BuildRequires (now since
> > gdb-6.7.1-4.fc9) just for the testsuite purposes brings:
> >   pro) It enables the testsuite to run in Koji/mock.
> >   con) It creates a burden for the users just rebuilding the rpm on their Fedora.
> > 
> > Isn't there a way to do some?
> > 	%if %{mock}
> > 	BuildRequires: gcc-gfortran gcc-java gcc-objc gcc-gnat
> > 	%endif
> > Tried
> > 	%if 0%{?dist:1}
> > but %dist is defined even for simple --rebuild by the redhat-rpm-config rpm.
> What I have done in similar situations [1] is applying rpm's
> --with/--without in combination with koji scratch builds and local
> builds.
> 
> I.e. I am using %{?_with_XXX} and friends inside of specs, such that you
> can specify them on rpmbuild's command-line for manual local builds. 
> 
> For chrooted "non-production/test-builds" (e.g. koji scratch-builts) I
> edit the spec (adding %define _with_XXX <something> to the top of the
> spec).
> 
> A better approach probably would be to have way to pass
> rpmbuild-parameters to koji/mock for scratch builds. 

Another idea that came up on #fedora-devel:

Have a 'is_production' variable at the top of the spec which defaults to
'on', and let people do --without-production, or some such.

--
Michael



From david at fubar.dk  Mon Nov 19 17:16:48 2007
From: david at fubar.dk (David Zeuthen)
Date: Mon, 19 Nov 2007 12:16:48 -0500
Subject: System-config Reworking Proposal
In-Reply-To: <200711191201.37903.sgrubb@redhat.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
	<16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
	<200711191201.37903.sgrubb@redhat.com>
Message-ID: <1195492608.5442.76.camel@oneill.fubar.dk>


On Mon, 2007-11-19 at 12:01 -0500, Steve Grubb wrote:
> The audit system already has the needed reporting tools and is 
> getting new GUI based tools in F9.

Haven't seen a feature page for this yet; do you have on handy? I guess
without knowing how it works my only comment at this point would be that
we want to avoid writing X11 applications that run as root.

       David




From michael.wiktowy at gmail.com  Mon Nov 19 17:20:52 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Mon, 19 Nov 2007 12:20:52 -0500
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <4741BF3B.1010807@poolshark.org>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<1195490814.8410.8.camel@gilboa-work-dev.localdomain>
	<4741BF3B.1010807@poolshark.org>
Message-ID: <3e4ec4600711190920p1c0d5482t24fd2ee8361d9aae@mail.gmail.com>

On Nov 19, 2007 11:52 AM, Denis Leroy <denis at poolshark.org> wrote:
> Gilboa Davara wrote:
> typically the MAC address is programmed into an on-board eeprom
> connected to the NIC. That's probably what's fried (or simply erased).

I have never seen a BIOS update clear the MAC either ... that is why I
am surprised at this.
I do have a second NIC that is on the mobo that works fine so I have a
work-around.

Oddly enough, the forgetful NIC does seem to work properly once Fedora
boots up. The issue is that I can't rely on MAC address identification
to allow my router to assign the same address (and forward ports to
it) using DHCP since NetworkManager is picking a random MAC and slowly
incrementing the ethX device every boot. The secondary issue is that
it is making a mess in my /etc/sysconfig/networking/ directory by not
clearing out old entries.

The only indication I get that it is getting cleared is that Windows
reports it as having a MAC of 00:00:00:00:00:00.

I was just wondering if there was another way to address a NIC (PCI
ID?) to be able to assign it a consistent MAC on each boot.

/Mike



From bernie at codewiz.org  Mon Nov 19 17:20:34 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Mon, 19 Nov 2007 12:20:34 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071109112208.GA12660@xi.wantstofly.org>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>	<20071109095230.GB2871@petra.dvoda.cz>
	<20071109112208.GA12660@xi.wantstofly.org>
Message-ID: <4741C5E2.4090609@codewiz.org>

On 11/09/07 06:22, Lennert Buytenhek wrote:

>   Note that in a distributed VCS, the OLPC-2 specific stuff wouldn't
>   have to live on the main Fedora VCS server, and could very easily
>   live on a separate box.  (Whether this is desirable for the OLPC-2
>   stuff or not is a separate issue, I'm just saying that it is easily
>   possible in a DVCS.)  (And whether the result can still be called
>   Fedora or not is also a separate issue.)

I think we (as OLPC) could really benefit from a truly
distributed development infrastructure.

The CVS to git migration is only part of the problem.  We'd need
a local Koji installation that could "inherit" braches from
koji.fedoraproject.org.  And maybe also local installations of
pkgdb and Bohdi...

It would be really cool if the whole toolset for a full
"distro assembly line" was easy enough to setup locally.

For my daily development, I often felt the need for a personal
fork of OLPC-2 where I can experiment with my custom packages.
An example of a project that required it was upgrading to
Xorg 1.4, which involves a dozen of updated packages and
some config updates.

We already have a modified version of pilgrim, plus some
build machinery that generates hourly builds from several
streams:

  http://xs-dev.laptop.org/~cscott/olpc/streams/

We're currently limited to dropping customized binary RPMs
in a directory.  What's missing is the same level of support
in the preceding stages of the build system.

My impression is that setting up a local koji server on
workstation machines is way too complicated.  What an
individual developer would need is the same ability to
build packates, but without the added complexity xmlrpc,
multiuser, clustering and web interface.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From loganjerry at gmail.com  Mon Nov 19 17:23:56 2007
From: loganjerry at gmail.com (Jerry James)
Date: Mon, 19 Nov 2007 10:23:56 -0700
Subject: RPM groups
In-Reply-To: <4741C213.6080308@redhat.com>
References: <4741C213.6080308@redhat.com>
Message-ID: <870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>

On Nov 19, 2007 10:04 AM, Richard W.M. Jones <rjones at redhat.com> wrote:

> I can't find any documentation on the RPM "Group:" field, what it should
> contain, and whether Fedora has a policy on these (even a list of them
> would be a good start).


Look in /usr/share/doc/rpm-{version number}/GROUPS for a list.  I remember
seeing a wiki page that listed all group names in actual use, but I can't
find it now.

There are quite a few packages in the Development/Libraries/Java group.  Why
isn't that group in the list?
-- 
Jerry James
http://loganjerry.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/df49b48d/attachment.htm>

From sgrubb at redhat.com  Mon Nov 19 17:23:57 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 19 Nov 2007 12:23:57 -0500
Subject: System-config Reworking Proposal
In-Reply-To: <1195492608.5442.76.camel@oneill.fubar.dk>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<200711191201.37903.sgrubb@redhat.com>
	<1195492608.5442.76.camel@oneill.fubar.dk>
Message-ID: <200711191223.58203.sgrubb@redhat.com>

On Monday 19 November 2007 12:16:48 pm David Zeuthen wrote:
> > The audit system already has the needed reporting tools and is
> > getting new GUI based tools in F9.
>
> Haven't seen a feature page for this yet; do you have on handy?

Nope. Not everything we do has been big enough to be called a feature.

> I guess without knowing how it works my only comment at this point would be
> that we want to avoid writing X11 applications that run as root.

Agreed.

-Steve



From david at fubar.dk  Mon Nov 19 17:28:28 2007
From: david at fubar.dk (David Zeuthen)
Date: Mon, 19 Nov 2007 12:28:28 -0500
Subject: working with gnome project/other distros together on system
	tools (was: Re: System-config Reworking Proposal)
In-Reply-To: <4741984F.30006@leemhuis.info>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
	<4741984F.30006@leemhuis.info>
Message-ID: <1195493308.5442.88.camel@oneill.fubar.dk>


On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
> Just wondering: Why don't we work towards getting some sane config tools
> (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> interest)? Sure, that way other distros will benefit from out work as
> well, but on the other hand having stuff as de-facto part of Gnome and
> used by other distros afaics lead to better tools and a better user
> experience, which overall leads to a better "Linux".

This is actually what we've been working on in the RH/Fedora desktop
team for quite some time. The mantra here, as you point out, is both
"upstream", proper separation of the user interface and the mechanism,
access control and, ideally, integration with directory services such as
the Fedora Directory Server.

Actually for home/consumer desktop use, there is not much need for any
of the system-config-* tools any more; for example for F9, intlclock
will replace system-config-date and S?ren's work on xrandr UI will
probably be able to replace most of system-config-display. The former,
at least, is getting merged into upstream GNOME as we speak. The latter,
I believe, will be proposed for GNOME as well. S?ren?

As for server use... e.g. s-c-httpd and friends I'm not sure. I've
always found it rather odd to use an UI for this in the first place but
I do acknowledge that some of our users find this useful. It's
definitely something that is on the check-list of many system
administrators especially those from the Windows world.

In my opinion, the most important thing to fix with our remaining
system-config-* tools is to get upstream buy-in (ideally merge it into
GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
mechanism and use things like PolicyKit for access control. Notably, Tim
is doing a pretty good job here with s-c-printer; that's why Ubuntu got
the best printing support on the planet :-) [1]

      David

[1] : I'm being sarcastic because space boy doesn't always give credit
where credit is due. Sources have told me that someone is working on
"fixing" this problem though




From rda at rincon.com  Mon Nov 19 17:35:13 2007
From: rda at rincon.com (Bob Arendt)
Date: Mon, 19 Nov 2007 10:35:13 -0700
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <3e4ec4600711190920p1c0d5482t24fd2ee8361d9aae@mail.gmail.com>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>	<1195490814.8410.8.camel@gilboa-work-dev.localdomain>	<4741BF3B.1010807@poolshark.org>
	<3e4ec4600711190920p1c0d5482t24fd2ee8361d9aae@mail.gmail.com>
Message-ID: <4741C951.5020108@rincon.com>

Michael Wiktowy wrote:
> Oddly enough, the forgetful NIC does seem to work properly once Fedora
> boots up. The issue is that I can't rely on MAC address identification
> to allow my router to assign the same address (and forward ports to
> it) using DHCP since NetworkManager is picking a random MAC and slowly
> incrementing the ethX device every boot. The secondary issue is that
> it is making a mess in my /etc/sysconfig/networking/ directory by not
> clearing out old entries.
> 
> The only indication I get that it is getting cleared is that Windows
> reports it as having a MAC of 00:00:00:00:00:00.
> 
> I was just wondering if there was another way to address a NIC (PCI
> ID?) to be able to assign it a consistent MAC on each boot.
> 
> /Mike
> 
This happened once to one of our many HP dl380's.  Just one.
And it booted with 0's ~70% of the time.  But otherwise worked.

Add to /etc/sysconfig/network-scripts/ifcfg-eth0
MACADDR="1a:2b:3c:4d:5e:6f"

Assuming it's eth0, and substitute your real MAC address.
If the interface can be programmed at runtime, this should do it.

-Bob



From bpepple at fedoraproject.org  Mon Nov 19 17:41:08 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 19 Nov 2007 12:41:08 -0500
Subject: FESCo meeting today at 20:00 UTC!
Message-ID: <1195494068.6281.5.camel@nixon>

Hi,

With the holidays this week, we've decided to have the FESCo meeting
today at 20:00 UTC #fedora-meeting on irc.freenode.org.  Sorry about the
late notice!

Planned schedule:

/topic MISC - Minor changes to bugzilla
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01161.html - poelcat 

/topic MISC - Deadline to drop kmods - f13 

/topic MISC - PPC Secondary Arch? -
https://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00078.html - f13, dwmw2 

/topic MISC - Drop orphans from F8< at some point during F9 - f13 

/topic MISC - Using Matt Domsch's "doesn't rebuild" bugs as AWOL
detection, mark as orphaned at some point in F9, drop in F9+ 

/topic MISC - Do more frequent conflicts testing, with bugs filed, and
use AWOL detection 

/topic MISC - automate the mailings of multiarch conflicts, it is hard
to test for people without biarch computers - from Patrice Dumas 

/topic FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all 

/topic Status Update: Compat Policy
http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy

/topic Status Update: FESCo Proposal Template - f13

/topic FESCo meeting -- Free discussion around Fedora

You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, since we have a pretty full schedule).  You can also
propose topics in the meeting while it is in the "Free discussion around
Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/88de77fe/attachment.sig>

From myfedora at richip.dhs.org  Mon Nov 19 17:41:25 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Mon, 19 Nov 2007 10:41:25 -0700
Subject: Review queue/FESCo after the merge
In-Reply-To: <20071119114942.697bc4b0@redhat.com>
References: <1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info> <20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com> <47412586.4020502@leemhuis.info>
	<20071119095558.GC2584@free.fr> <4741B869.9040508@leemhuis.info>
	<20071119114942.697bc4b0@redhat.com>
Message-ID: <1195494085.22563.27.camel@localhost6.localdomain6>

On Mon, 2007-11-19 at 11:49 -0500, Jesse Keating wrote:
> On Mon, 19 Nov 2007 17:23:05 +0100
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
> > Firefox IMHO is the way better example -- I fail to understand why we
> > didn't create a script that rebuilds all packages that depend on it
> > once it's build and in the buildroot. Yes,
> 
> Again, it takes /somebody/ to write it.  FESCo can say all they want "I
> want this to happen", but until somebody sits down and cranks out a
> script, it's just not going to happen.

Actually, if I were to imagine things ... if FESCo actually said "I want
this to happen" and takes the necessary management roles to get things
started (ie. a wiki discussion page, a mailing list thread, an ad-hoc
committee, etc.), I imagine a lot of people would be happy. But it's
important for FESCo to actually say it because then it becomes an
official Fedora-sanctioned project and people would know they're not
wasting their time. Also, I don't think people expect FESCo to actually
do the work, but at least do the managerial task of organizing people
willing to work.

If volunteers don't turn up, then FESCo's done all they can.

> Instead many of us are working toward a situation where this one-off
> won't be necessary.

I doubt it's a one-off thing and avoiding situations like it isn't
always desired.
--

Richi Plana



From jkeating at redhat.com  Mon Nov 19 17:44:20 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 12:44:20 -0500
Subject: RPM groups
In-Reply-To: <870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>
References: <4741C213.6080308@redhat.com>
	<870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>
Message-ID: <20071119124420.6a8969e6@redhat.com>

On Mon, 19 Nov 2007 10:23:56 -0700
"Jerry James" <loganjerry at gmail.com> wrote:

> Look in /usr/share/doc/rpm-{version number}/GROUPS for a list.  I
> remember seeing a wiki page that listed all group names in actual
> use, but I can't find it now.
> 
> There are quite a few packages in the Development/Libraries/Java
> group.  Why isn't that group in the list?

The FPC has mostly ignored the Groups tag.  It's not used by yum, and
thus all the tools based upon yum (pirut, anaconda, pungi, repoview,
etc...)  We strongly feel that grouping and tagging belongs outside of
the package itself (so that other people can group them as necessary
without rebuilding them, etc...) and thus we focus on having
appropriate grouping in comps, our current external grouping tool.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/7426961a/attachment.sig>

From jkeating at redhat.com  Mon Nov 19 17:45:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 12:45:32 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <4741C5E2.4090609@codewiz.org>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>
	<20071109095230.GB2871@petra.dvoda.cz>
	<20071109112208.GA12660@xi.wantstofly.org>
	<4741C5E2.4090609@codewiz.org>
Message-ID: <20071119124532.0731f106@redhat.com>

On Mon, 19 Nov 2007 12:20:34 -0500
Bernardo Innocenti <bernie at codewiz.org> wrote:

> We already have a modified version of pilgrim, plus some
> build machinery that generates hourly builds from several
> streams:
> 
>   http://xs-dev.laptop.org/~cscott/olpc/streams/
> 
> We're currently limited to dropping customized binary RPMs
> in a directory.  What's missing is the same level of support
> in the preceding stages of the build system.
> 
> My impression is that setting up a local koji server on
> workstation machines is way too complicated.  What an
> individual developer would need is the same ability to
> build packates, but without the added complexity xmlrpc,
> multiuser, clustering and web interface.

Could this not be accomplished with my koper idea?
http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/b2905ecb/attachment.sig>

From andreas.bierfert at lowlatency.de  Mon Nov 19 17:48:06 2007
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Mon, 19 Nov 2007 18:48:06 +0100
Subject: Wine 0.9.49?
In-Reply-To: <1195481792.8410.4.camel@gilboa-work-dev.localdomain>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<20071118224425.3b888a72@alkaid.a.lan>
	<1195481792.8410.4.camel@gilboa-work-dev.localdomain>
Message-ID: <20071119184806.168363ab@alkaid.a.lan>

On Mon, 19 Nov 2007 16:16:32 +0200
Gilboa Davara <gilboad at gmail.com> wrote:

> Looking forward for it.

F-{7,8} builds should hit testing with the next push.

Regards,
Andreas

-- 
Andreas Bierfert, B.Sc.        | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/496001ff/attachment.sig>

From fedora at leemhuis.info  Mon Nov 19 17:52:12 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 18:52:12 +0100
Subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo after
 the merge)
In-Reply-To: <20071119114942.697bc4b0@redhat.com>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>
	<20071119095558.GC2584@free.fr>	<4741B869.9040508@leemhuis.info>
	<20071119114942.697bc4b0@redhat.com>
Message-ID: <4741CD4C.1080601@leemhuis.info>

On 19.11.2007 17:49, Jesse Keating wrote:
> On Mon, 19 Nov 2007 17:23:05 +0100
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
>> Firefox IMHO is the way better example -- I fail to understand why we
>> didn't create a script that rebuilds all packages that depend on it
>> once it's build and in the buildroot. Yes,
> 
> Again, it takes /somebody/ to write it.

We often say that in Fedora-land -- the result afaics often is: we scare
people away with it.

Sure, there is of course somebody needed, but sorry, especially FESCo
members instead of "Again, it takes /somebody/ to write it." should say
something like "yeah, this could be a solution; is somebody in our
friendly community willing to realize it?" or "yeah, nice idea, but
instead we should do .... to solve the problem is a even better way"

For more complicated tasks there is of course more needed. But just
requesting "do something" won't change anything most of the time --
especially for more comlicated tasks FESCo should say "yeah, we want
something like that; this is how it could look like ..." and guide
people. Then people can be sure than the solution they work out (which
could take many workhours of even days) is at least roughly what FESCo
wants.

>  FESCo can say all they want "I
> want this to happen", but until somebody sits down and cranks out a
> script, it's just not going to happen.

Come on, if our leaders are not able to do such a simple thing like this
own their own or find somebody do do it then there really is something
wrong in Fedora-land.

It's really not that hard, even I with my very limited programming
skills (aka "knurd the package monkey") I can do what's needed in just a
few minutes:

/me wanders of to create such a "script"

/me downloads
http://cvs.fedora.redhat.com/viewcvs/rebuild-scripts/bumpspecfile.py?root=fedora&view=markup

/me adjusts changelog comment

/me copy-and pastes list from
http://fedoraproject.org/wiki/WillWoods/Drafts/FirefoxUpdates
(one could create such a list with manually as well; "repoquery
--whatrequires --alldeps 'firefox = 2.0.0.9' 'gecko-libs = 1.8.1.9'" or
something like that would be a good start)

/me removes the newlines and created a quick loop in bash

Here is your "script":
---
for package in blam chmsee devhelp epiphany epiphany-extensions firefox
galeon gnome-python2-extras gnome-web-photo gtkmozembedmm kazehakase
liferea Miro openvrml ruby-gnome2 yelp; do
	pushd ${package}
	bumpspecfile.py *.spec
	make tag build
	popd
done
---

Find bumpspecfile.py attached. Run it in a full cvs checkout once the
new firefox is in the repo; if you don't have one add a "cvs co
${package}" at the right place and adjust the pushd call.

Before above works one needs to adjust some of the spec files so none
hard-code the gecko-* or firefox-* versions -- or instead use the same
format everywhere witch can be adjusted with a simple sed call. I can't
do that, something like that is unwanted in Fedora-land (see earlier in
this thread). If FESCo gives me the permission I'm of course
volunteering to do it.

Have fun.

CU
knurd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bumpspecfile.py
Type: text/x-python
Size: 3962 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/bcbd8d93/attachment.py>

From rjones at redhat.com  Mon Nov 19 17:57:35 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 19 Nov 2007 17:57:35 +0000
Subject: yum groups (was: Re: RPM groups)
In-Reply-To: <20071119124420.6a8969e6@redhat.com>
References: <4741C213.6080308@redhat.com>	<870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>
	<20071119124420.6a8969e6@redhat.com>
Message-ID: <4741CE8F.10907@redhat.com>

Jesse Keating wrote:
> On Mon, 19 Nov 2007 10:23:56 -0700
> "Jerry James" <loganjerry at gmail.com> wrote:
> 
>> Look in /usr/share/doc/rpm-{version number}/GROUPS for a list.  I
>> remember seeing a wiki page that listed all group names in actual
>> use, but I can't find it now.
>>
>> There are quite a few packages in the Development/Libraries/Java
>> group.  Why isn't that group in the list?
> 
> The FPC has mostly ignored the Groups tag.  It's not used by yum, and
> thus all the tools based upon yum (pirut, anaconda, pungi, repoview,
> etc...)  We strongly feel that grouping and tagging belongs outside of
> the package itself (so that other people can group them as necessary
> without rebuilding them, etc...) and thus we focus on having
> appropriate grouping in comps, our current external grouping tool.

OK.  Someone asked me to put virt-top in the Base System / 
Virtualization group (in pup) [1].  This is what prompted the original 
question, because I don't know how to do this.

It seems like the groups listed by "yum grouplist" are similar to the 
ones in pup (but not hierarchical).  Meanwhile the groups listed in 
/usr/share/doc/rpm-*/GROUPS are completely different.

Reading around this it seems like the yumgroups.xml file in the 
repository controls this (although the Fedora repos don't seem to have 
this file -- perhaps it's been renamed?).  So I guess my question is 
what controls what packages are in what groups?

Rich.

[1] 
http://redhat.download.fedoraproject.org/pub/fedora/linux/releases/8/Fedora/i386/os/repoview/virtualization.group.html

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/a6c78ade/attachment.bin>

From mattdm at mattdm.org  Mon Nov 19 18:00:36 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 19 Nov 2007 13:00:36 -0500
Subject: RPM groups
In-Reply-To: <20071119124420.6a8969e6@redhat.com>
References: <4741C213.6080308@redhat.com>
	<870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>
	<20071119124420.6a8969e6@redhat.com>
Message-ID: <20071119180036.GA2364@jadzia.bu.edu>

On Mon, Nov 19, 2007 at 12:44:20PM -0500, Jesse Keating wrote:
> The FPC has mostly ignored the Groups tag.  It's not used by yum, and
> thus all the tools based upon yum (pirut, anaconda, pungi, repoview,
> etc...)  We strongly feel that grouping and tagging belongs outside of
> the package itself (so that other people can group them as necessary
> without rebuilding them, etc...) and thus we focus on having
> appropriate grouping in comps, our current external grouping tool.

I'd really like to see a slow path to removing the tag completely from
Fedora use.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From fedora at leemhuis.info  Mon Nov 19 18:04:02 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 19:04:02 +0100
Subject: EPEL report week 46 2007
Message-ID: <4741D012.20104@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week46

= Weekly EPEL Summary =

Week 46/2007

== Most important happenings ==

 * [:RobMyers: Rob Myers] (_blah_) is working towards getting all
bugzilla deps into EPEL, which resulted in a huge number of new perl
packages in EPEL5-testing during the past week. Thx for your great work
Rob, it's much appreciated!

== Mailing list ==

=== Noteworthy discussions ===

Nothing earth-shaking.

== Meeting ==

=== Next Meeting ===

20071107 at '''18:00 UTC''' in #fedora-meeting.

Please note that it's 18:00 UTC now again after the DST switch, so the
effective meeting time should stay the same for everyone! And a second
reminder: we currently meet only every second week (the ones with a odd
week number)!

=== Last weeks meeting ===

Was a week with an even number, thus no meeting.

== Stats ==

=== General ===

Number of EPEL Contributors: 141

We welcome 1 new contributors: nbecker

=== EPEL 5 ===

Number of source packages: 800

Number of binary packages:  1497

There are 61 new Packages:

 * catdoc | A program which converts Microsoft office files to plain text
 * dblatex | DocBook to LaTeX/ConTeXt Publishing
 * perl-AppConfig | Perl module for reading configuration files
 * perl-B-Keywords | Lists of reserved barewords and symbol names
 * perl-Class-Inspector | Get information about a class and its structure
 * perl-Config-Tiny | Perl module for reading and writing .ini style
configuration files
 * perl-Data-OptList | Parse and validate simple name/value option pairs
 * perl-Devel-Cycle | Find memory cycles in objects
 * perl-Email-Address | RFC 2822 Address Parsing and Creation
 * perl-Email-MessageID | Generate world unique message-ids
 * perl-Email-MIME-Attachment-Stripper | Strip the attachments from a
mail message
 * perl-Email-MIME-ContentType | Parse a MIME Content-Type Header
 * perl-Email-MIME | Easy MIME message parsing
 * perl-Email-MIME-Encodings | Unified interface to MIME encoding and
decoding
 * perl-Email-MIME-Modifier | Modify Email::MIME Objects Easily
 * perl-Email-Simple | Simple parsing of RFC2822 message format and headers
 * perl-File-Find-Rule | Perl module implementing an alternative
interface to File::Find
 * perl-File-HomeDir | Get the home directory for yourself or other users
 * perl-File-Remove | Convenience module for removing files and directories
 * perl-File-Which | Portable implementation of the 'which' utility
 * perl-Font-AFM | Perl interface to Adobe Font Metrics files
 * perl-FreezeThaw | Convert Perl structures to strings and back
 * perl-GDGraph3d | 3D graph generation package for Perl
 * perl-Hook-LexWrap | Lexically scoped subroutine wrappers
 * perl-HTML-Format | HTML formatter modules
 * perl-Image-Base | Base class for loading, manipulating and saving
images in Perl
 * perl-Image-Info | Image meta information extraction module for Perl
 * perl-Image-Size | Determine the size of images in several common
formats in Perl
 * perl-Image-Xbm | Load, create, manipulate and save xbm image files in
Perl
 * perl-Image-Xpm | Load, create, manipulate and save xpm image files in
Perl
 * perl-List-MoreUtils | Provide the stuff missing in List::Util
 * perl-Mail-Transport-Dbx | Parse Outlook Express mailboxes
 * perl-MLDBM | Store multi-level hash structure in single level tied hash
 * perl-Module-Pluggable | Automatically give your module the ability to
have plugins
 * perl-Number-Compare | Perl module for numeric comparisons
 * perl-Package-Generator | Generate new packages quickly and easily
 * perl-PadWalker | Play with other peoples' lexical variables
 * perl-Params-Util | Simple standalone param-checking functions
 * perl-Params-Validate | Params-Validate Perl module
 * perl-Perl-Critic | Critique Perl source code for best-practices
 * perl-Pod-Coverage | Checks if the documentation of a module is
comprehensive
 * perl-Pod-Spell | A formatter for spellchecking Pod
 * perl-PPI | Parse, Analyze and Manipulate Perl
 * perl-Return-Value | Polymorphic Return Values
 * perl-String-Format | Sprintf-like string formatting capabilities with
arbitrary format definitions
 * perl-Sub-Exporter | Sophisticated exporter for custom-built routines
 * perl-Sub-Install | Install subroutines into packages easily
 * perl-Test-ClassAPI | Provides basic first-pass API testing for large
class trees
 * perl-Test-Differences | Test strings and data structures and show
differences if not ok
 * perl-Test-Manifest | Test case module for Perl
 * perl-Test-Memory-Cycle | Check for memory leaks and circular memory
references
 * perl-Test-Object | Thoroughly testing objects via registered handlers
 * perl-Test-Perl-Critic | Use Perl::Critic in test programs
 * perl-Test-Spelling | Check for spelling errors in POD files
 * perl-Test-SubCalls | Track the number of times subs are called
 * perl-Test-Taint | Tools to test taintedness
 * perl-TeX-Hyphen | Hyphenate words using TeX's patterns
 * perl-Text-Glob | Perl module to match globbing patterns against text
 * perl-Time-Piece | Time objects from localtime and gmtime
 * python-pp | Parallel execution of python on smp
 * python-which | Small which replacement that can be used as a Python
module

=== EPEL 4 ===

Number of source packages: 443

Number of binary packages:  891

There are 1 new Packages:

 * catdoc | A program which converts Microsoft office files to plain text

----
["CategoryEPELReports"]



From jkeating at redhat.com  Mon Nov 19 18:02:15 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 13:02:15 -0500
Subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo
 after the merge)
In-Reply-To: <4741CD4C.1080601@leemhuis.info>
References: <1195226677.3238.45.camel@localhost.localdomain>
	<1195227221.3002.9.camel@localhost.localdomain>
	<1195227371.3238.47.camel@localhost.localdomain>
	<473DEA5F.30201@leemhuis.info>
	<1195247727.29478.6.camel@space-ghost.verbum.private>
	<474047F4.5000508@leemhuis.info>
	<20071118094506.5216b37d@redhat.com>
	<1195418585.26830.18.camel@rousalka.dyndns.org>
	<20071118185514.6cfa560a@redhat.com>
	<47412586.4020502@leemhuis.info> <20071119095558.GC2584@free.fr>
	<4741B869.9040508@leemhuis.info>
	<20071119114942.697bc4b0@redhat.com>
	<4741CD4C.1080601@leemhuis.info>
Message-ID: <20071119130215.220c71e5@redhat.com>

On Mon, 19 Nov 2007 18:52:12 +0100
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> /me removes the newlines and created a quick loop in bash
> 
> Here is your "script":
> ---
> for package in blam chmsee devhelp epiphany epiphany-extensions
> firefox galeon gnome-python2-extras gnome-web-photo gtkmozembedmm
> kazehakase liferea Miro openvrml ruby-gnome2 yelp; do
> 	pushd ${package}
> 	bumpspecfile.py *.spec
> 	make tag build
> 	popd
> done

So this is great and all, but it's FF specific, where we're moving to
xulrunner anyway.  Time is better spent getting these things to support
xul.

Not that this script isn't handy at all.  In fact, I think we (as
Fedora) need to appoint somebody or some "body" (like a SIG) to oversee
the entire gecko stack both now and in the future to ensure that
updates are coordinated.  Just building is only one part of the puzzle,
they all have to get pushed out at the same time and into the same
repos.

I don't have the time or energy to own this problem space.  I can tell
you from my perspective where the problems are, and take a look at
proposed solutions.  Your script may indeed prove very handy to those
that are going to own this problem space, especially if it were tied
into the makefile changes Luke made for auto-filing bodhi push requests.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/4e2bc7e6/attachment.sig>

From fedora at leemhuis.info  Mon Nov 19 18:08:47 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 19 Nov 2007 19:08:47 +0100
Subject: working with gnome project/other distros together on
	system	tools
In-Reply-To: <1195493308.5442.88.camel@oneill.fubar.dk>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>	<1195470779.7213.12.camel@cyberelk.elk>	<1195480199.14998.21.camel@gibraltar.str.redhat.com>	<4741984F.30006@leemhuis.info>
	<1195493308.5442.88.camel@oneill.fubar.dk>
Message-ID: <4741D12F.9090002@leemhuis.info>

On 19.11.2007 18:28, David Zeuthen wrote:
> On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
>> Just wondering: Why don't we work towards getting some sane config tools
>> (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
>> interest)? Sure, that way other distros will benefit from out work as
>> well, but on the other hand having stuff as de-facto part of Gnome and
>> used by other distros afaics lead to better tools and a better user
>> experience, which overall leads to a better "Linux".
> This is actually what we've been working on in the RH/Fedora desktop
> team for quite some time. The mantra here, as you point out, is both
> "upstream", proper separation of the user interface and the mechanism,
> access control and, ideally, integration with directory services such as
> the Fedora Directory Server.

Thx for this (and your work), and yeah, I was aware of that -- but from
the current discussion around the system-config-tools on this list I got
the impression that other people in Fedora-land work towards a different
direction.

> [...]
> In my opinion, the most important thing to fix with our remaining
> system-config-* tools is to get upstream buy-in (ideally merge it into
> GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
> mechanism and use things like PolicyKit for access control. Notably, Tim
> is doing a pretty good job here with s-c-printer; that's why Ubuntu got
> the best printing support on the planet :-) [1]

+1, especially for the s-c-printer part

Cu
knurd



From jkeating at redhat.com  Mon Nov 19 18:35:48 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 13:35:48 -0500
Subject: yum groups (was: Re: RPM groups)
In-Reply-To: <4741CE8F.10907@redhat.com>
References: <4741C213.6080308@redhat.com>
	<870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>
	<20071119124420.6a8969e6@redhat.com> <4741CE8F.10907@redhat.com>
Message-ID: <20071119133548.5356769a@redhat.com>

On Mon, 19 Nov 2007 17:57:35 +0000
"Richard W.M. Jones" <rjones at redhat.com> wrote:

> Reading around this it seems like the yumgroups.xml file in the 
> repository controls this (although the Fedora repos don't seem to
> have this file -- perhaps it's been renamed?).  So I guess my
> question is what controls what packages are in what groups?

Comps.


http://fedoraproject.org/wiki/PackageMaintainers/CompsXml
-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/efb77e20/attachment.sig>

From ville.skytta at iki.fi  Mon Nov 19 18:46:01 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 19 Nov 2007 20:46:01 +0200
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <1195494068.6281.5.camel@nixon>
References: <1195494068.6281.5.camel@nixon>
Message-ID: <200711192046.01963.ville.skytta@iki.fi>

On Monday 19 November 2007, Brian Pepple wrote:

> /topic MISC - Deadline to drop kmods - f13

Please discuss whether packages that more or less depend on some kmods can 
still be included even if the kmods themselves are dropped.

Use case: em8300-* stuff isn't that useful without the em8300 kmods, but 
without em8300-devel some packages that gracefully fall back to not using 
em8300 hardware if the kmods/devices are not available won't build support 
for those devices in at all.  If that support would be built in, users of 
that hardware could get support for it just by building the kmods locally, 
without having to build also the em8300 utilities and devel packages nor 
those packages that have build time optional dependencies to em8300-devel.

>From my POV in this particular case, I'd be inclined to let em8300 (the 
non-kmod package) stay in Fedora because of the above, and also because it's 
actually possible that the em8300 modules get beaten into a shape where they 
can be included in upstream or Fedora kernels by F9 or F10 time.



From katzj at redhat.com  Mon Nov 19 18:47:46 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 19 Nov 2007 13:47:46 -0500
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <200711192046.01963.ville.skytta@iki.fi>
References: <1195494068.6281.5.camel@nixon>
	<200711192046.01963.ville.skytta@iki.fi>
Message-ID: <1195498066.6320.15.camel@localhost.localdomain>

On Mon, 2007-11-19 at 20:46 +0200, Ville Skytt? wrote:
> >From my POV in this particular case, I'd be inclined to let em8300 (the 
> non-kmod package) stay in Fedora because of the above, and also because it's 
> actually possible that the em8300 modules get beaten into a shape where they 
> can be included in upstream or Fedora kernels by F9 or F10 time.

This sounds very reasonable to me, FWIW.  

Jeremy



From jkeating at redhat.com  Mon Nov 19 18:52:04 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 13:52:04 -0500
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <1195498066.6320.15.camel@localhost.localdomain>
References: <1195494068.6281.5.camel@nixon>
	<200711192046.01963.ville.skytta@iki.fi>
	<1195498066.6320.15.camel@localhost.localdomain>
Message-ID: <20071119135204.0acc97ec@redhat.com>

On Mon, 19 Nov 2007 13:47:46 -0500
Jeremy Katz <katzj at redhat.com> wrote:

> On Mon, 2007-11-19 at 20:46 +0200, Ville Skytt? wrote:
> > >From my POV in this particular case, I'd be inclined to let em8300
> > >(the 
> > non-kmod package) stay in Fedora because of the above, and also
> > because it's actually possible that the em8300 modules get beaten
> > into a shape where they can be included in upstream or Fedora
> > kernels by F9 or F10 time.
> 
> This sounds very reasonable to me, FWIW.  
> 
> Jeremy
> 


Me too.  As long as it won't lead to broken deps, I'm OK with it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/4949026f/attachment.sig>

From pertusus at free.fr  Mon Nov 19 19:07:14 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Nov 2007 20:07:14 +0100
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <1195494068.6281.5.camel@nixon>
References: <1195494068.6281.5.camel@nixon>
Message-ID: <20071119190714.GB29715@free.fr>

On Mon, Nov 19, 2007 at 12:41:08PM -0500, Brian Pepple wrote:
> Hi,
> 
> With the holidays this week, we've decided to have the FESCo meeting
> today at 20:00 UTC #fedora-meeting on irc.freenode.org.  Sorry about the
> late notice!

* I still have my acpi component in bugzilla issue...

* And I think it could be nice to have somebody knowledgable in packagedb
  to add something in the wiki, especially a page that can be reached from
  the main page, with some explanation and links to where packagedb is
  used.

* Also unless I'm wrong bodhi command line interface now exists, it would
  be nice to have its usage explained in the wiki, maybe in
http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo
  still by somebody who knows about the subject.

--
Pat



From buildsys at fedoraproject.org  Mon Nov 19 19:19:02 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Mon, 19 Nov 2007 14:19:02 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-19
Message-ID: <20071119191903.03EB415212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 5

    flashrom-0-0.5.20071118svn2967.fc6
    Inventor-2.1.5-29.fc6.1
    lshw-B.02.12.01-1.fc6
    sdparm-1.02-1.fc6
    superiotool-0-0.7.20071118svn2975.fc6


Changes in Fedora Extras 6: 


flashrom-0-0.5.20071118svn2967.fc6
----------------------------------
* Sun Nov 18 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.5.20071118svn2967
- svn ver. 2967 (support for Intel 440MX systems, Fujitsu MBM29F400TC, 
  AMD Geode CS5536)

Inventor-2.1.5-29.fc6.1
-----------------------
* Mon Nov 19 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.1.5-29.1
- Add hard-coded deps on font files (BZ 388761).
- Switch to using liberation-fonts instead of dejavu-fonts.

* Fri Aug 17 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.1.5-29
- Update license tag.

* Thu Jun 21 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.1.5-28
- ExcludeArch: ppc64 (BZ: 245192).

* Thu Jun 21 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.1.5-27
- Add *-27.patch.
- Remove _ia64 grep (Incorporated into *-27.diff).
- Add powerpc64 hack.

* Wed Mar 14 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.1.5-26
- Use dejavu-fonts as fonts.
- Attempt to fix BZ 232017.

* Tue Feb 13 2007 Ralf Cors?pius <rc040203 at freenet.de> - 2.1.5-25
- Specfile fixes.

lshw-B.02.12.01-1.fc6
---------------------
* Mon Nov 05 2007 Terje Rosten <terjeros at phys.ntnu.no> - B.02.12.01-1
- B.02.12.01
- Replace trademark icons

sdparm-1.02-1.fc6
-----------------
* Mon Nov 05 2007 Terje Rosten <terje.rosten at ntnu.no> - 1.02-1
- 1.02

* Tue Aug 28 2007 Terje Rosten <terje.rosten at ntnu.no> - 1.01-3
- Rebuild

* Mon May 21 2007 Terje Rosten <terje.rosten at ntnu.no> - 1.01-2
- Tag problem

* Mon May 21 2007 Terje Rosten <terje.rosten at ntnu.no> - 1.01-1
- New upstream release: 1.01

superiotool-0-0.7.20071118svn2975.fc6
-------------------------------------
* Mon Nov 19 2007 Peter Lemenkov <lemenkov at gmail.com> 0.7.20071118svn2975
- Fixed man-page installation

* Sun Nov 18 2007 Peter Lemenkov <lemenkov at gmail.com> 0.6.20071118svn2975
- svn ver. 2975 (support for SMSC LPC47N227, NSC PC8374L, Winbond W83977TF,
  Winbond W83977AF, Winbond W83697SF, NSC PC87360, SMSC FDC37N958FR)
- drop patch1



From jkeating at redhat.com  Mon Nov 19 19:26:37 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Nov 2007 14:26:37 -0500
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <1195494068.6281.5.camel@nixon>
References: <1195494068.6281.5.camel@nixon>
Message-ID: <20071119142637.2154ab37@redhat.com>

On Mon, 19 Nov 2007 12:41:08 -0500
Brian Pepple <bpepple at fedoraproject.org> wrote:

> Hi,
> 
> With the holidays this week, we've decided to have the FESCo meeting
> today at 20:00 UTC #fedora-meeting on irc.freenode.org.  Sorry about
> the late notice!

CRAP!  My wife's flight is getting in much earlier than anticipated,
and I will not be able to attend the meeting as I has originally
planned :/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/d03aae8d/attachment.sig>

From jcm at redhat.com  Mon Nov 19 19:33:36 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 19 Nov 2007 14:33:36 -0500
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <20071119155814.GA26453@jasmine.xos.nl>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<20071119165338.03dfd1a0@dhcp03.addix.net>
	<20071119155814.GA26453@jasmine.xos.nl>
Message-ID: <1195500816.11545.63.camel@jcmlaptop>

On Mon, 2007-11-19 at 16:58 +0100, Jos Vos wrote:
> On Mon, Nov 19, 2007 at 04:53:38PM +0100, Ralf Ertzinger wrote:
> 
> > I have updated some BIOSes in my time, but I never had to do that.
> 
> No, and I've even never heard that story.
> 
> Usually, when MAC addresses become 00:00..., your NIC has a serious
> problem.  I've had that in a few cases, all after a power dip IIRC,
> and I had to replace them.

The response to the original poster about giving a specified MAC was
obviously assuming that the original poster was reflashing the BIOS *on
the NIC*. This is unlikely, but it is quite command for NICs to come up
with a NULL MAC if their internal flash is blown away/not updated
properly. This is highly unlikely to be the case here, however.

My suspicion is that the original mail was simply about updating the
main system BIOS, not the additional flash chip, and that something is
very wrong with the card - is it on board, or an adapter?

Jon.




From jcm at redhat.com  Mon Nov 19 19:35:21 2007
From: jcm at redhat.com (Jon Masters)
Date: Mon, 19 Nov 2007 14:35:21 -0500
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <4741BF3B.1010807@poolshark.org>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<1195490814.8410.8.camel@gilboa-work-dev.localdomain>
	<4741BF3B.1010807@poolshark.org>
Message-ID: <1195500921.11545.66.camel@jcmlaptop>

On Mon, 2007-11-19 at 17:52 +0100, Denis Leroy wrote:
> Gilboa Davara wrote:
> > On Mon, 2007-11-19 at 16:52 +0100, KH KH wrote:
> >> 2007/11/19, Michael Wiktowy <michael.wiktowy at gmail.com>:
> >>> Hi,
> >>>
> >>> It seems recently one of my two onboard NICs has decided to not
> >>> remember its MAC address between reboots. Since I just updated the
> >>> BIOS firmware, I suspect that as the culprit but I also upgraded to
> >>> Fedora 8 about the same time so it may be to blame. I don't know.
> >> When you update the bios, the tool accept a parameter for the mac
> >> address.. Each time you flash the bios, you need to give the mac
> >> address for the integrated ethernet (usually written on the top of the
> >> mainboard ), so it can be hardcoded into the bios...
> >>
> >> Nicolas (kwizart)
> >>
> > 
> > I've updated my share of BIOS... Large share.
> > Never seen a BIOS upgrade that erases the MAC address.
> > 
> > Most likely the on-board NIC has been fried.
> 
> typically the MAC address is programmed into an on-board eeprom 
> connected to the NIC. That's probably what's fried (or simply erased).

Oops. Someone already made my point :-)

Well, yeah, and it is possible to recover from this if that is what has
happened - but you'll need a tool from the vendor in order to flash it.
I say flash, when really they are still mostly serial EEPROMs.

Jon.




From notting at redhat.com  Mon Nov 19 19:37:44 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Nov 2007 14:37:44 -0500
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <200711192046.01963.ville.skytta@iki.fi>
References: <1195494068.6281.5.camel@nixon>
	<200711192046.01963.ville.skytta@iki.fi>
Message-ID: <20071119193744.GA22346@nostromo.devel.redhat.com>

Ville Skytt? (ville.skytta at iki.fi) said: 
> >From my POV in this particular case, I'd be inclined to let em8300 (the 
> non-kmod package) stay in Fedora because of the above, and also because it's 
> actually possible that the em8300 modules get beaten into a shape where they 
> can be included in upstream or Fedora kernels by F9 or F10 time.

Don't we have vserver-using packages in Fedora that can't work without
rebuilding the kernel?

Bill



From janina at rednote.net  Mon Nov 19 17:49:54 2007
From: janina at rednote.net (Janina Sajka)
Date: Mon, 19 Nov 2007 12:49:54 -0500
Subject: Inaccessible Post-GDM But Pre-Desktop Dialogs
In-Reply-To: <20071109150349.GF6342@rednote.net>
References: <20071105162134.GD6342@rednote.net>
	<1194281489.31380.8.camel@localhost.localdomain>
	<20071109150349.GF6342@rednote.net>
Message-ID: <20071119174954.GJ6342@rednote.net>

Janina Sajka writes:
> Jeremy Katz writes:
> > On Mon, 2007-11-05 at 11:21 -0500, Janina Sajka wrote:
> > > There is at least one potential dialog that breaks accessibility after a
> > > user logs in, but before Orca (or Gok) loads. I became aware of this one
> > > demonstrating Orca in Italian to a CompSci professor at a recont F/OSS
> > > symposium in Florence.
> > > 
> > > The dialog we came across advises of available updates. It does not talk
> > > (in my case). So, it's an accessibility show-stopper.
> > > 
> > > Generically speaking, all such potential pop-ups need to be vetted for
> > > accessibility. What about the one that says: "you're not connected to
> > > the Internet," for instance?
> > 
> > They're actually from the same source.  The problem here is that things
> > in the notification area (puplet, nm-applet, etc) are all started by
> > gnome-session as is the panel, orca, etc.  If one of the notification
> > area applets wants to show a notification bubble, they just do a
> > libnotify call.  But there's no way to ensure that the panel is up (and
> > thus that their icon is actually visible) much less if other things like
> > a11y technologies are running.
> > 
> > We really need a way to serialize some of this.  Unfortunately, that'll
> > end up coming at the cost of a (slightly) slower login time
> > 
> So, it sounds like the proper fix is upstream in Gnome development? But,
> what's the short term work around for the Fedora 8 user? Right now it's a
> crap shoot whether one can access the desktop with Orca, or not.
> Clearly, it may often be possible to go run a 'yum update,' but it won't
> always be possible to do that.
> 
Answering my own question--perhaps--

Is the correct workaround disabling Update Notification under
System/Preferences/Sessions?

Janina



From jlb17 at duke.edu  Mon Nov 19 20:30:01 2007
From: jlb17 at duke.edu (Joshua Baker-LePain)
Date: Mon, 19 Nov 2007 15:30:01 -0500 (EST)
Subject: Slow performance writing to NetApp filer
Message-ID: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>

I just submitted <https://bugzilla.redhat.com/show_bug.cgi?id=391021> 
regarding an odd issue we're having.  Fedora (both 7 and 8) have horribly 
slow performance when writing to our NetApp FAS3020 filer.  I've tested on 
2 sets of hardware (i386 and x86_64, with tg3 and e1000 NICs).  No matter 
what I try, it won't go faster than ~5MB/s.  The same hardware running 
CentOS-5 gets ~50MB/s.  Performance is just fine pointing the Fedora boxes 
at a Panasas filer.

Has anybody else run into this?  It seems a rather odd bug to me.

-- 
Joshua Baker-LePain
QB3 Shared Cluster Sysadmin
UCSF



From wtogami at redhat.com  Mon Nov 19 20:34:56 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 15:34:56 -0500
Subject: Slow performance writing to NetApp filer
In-Reply-To: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>
References: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>
Message-ID: <4741F370.7090408@redhat.com>

Joshua Baker-LePain wrote:
> I just submitted <https://bugzilla.redhat.com/show_bug.cgi?id=391021> 
> regarding an odd issue we're having.  Fedora (both 7 and 8) have 
> horribly slow performance when writing to our NetApp FAS3020 filer.  
> I've tested on 2 sets of hardware (i386 and x86_64, with tg3 and e1000 
> NICs).  No matter what I try, it won't go faster than ~5MB/s.  The same 
> hardware running CentOS-5 gets ~50MB/s.  Performance is just fine 
> pointing the Fedora boxes at a Panasas filer.
> 
> Has anybody else run into this?  It seems a rather odd bug to me.
> 

NFSv3?  NFSv4?  iSCSI?

Have you tried all three?

Warren Togami
wtogami at redhat.com



From kevin at scrye.com  Mon Nov 19 20:37:21 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Mon, 19 Nov 2007 13:37:21 -0700
Subject: orphaning dbh
Message-ID: <20071119133721.6d33e756@ghistelwchlohm.scrye.com>

I am going to orphan the 'dbh' package. 

"Disk based hash library". 

It was used long ago by Xfce, but no longer is. There are newer
versions upstream and it could use more love than I'm willing to give
it. There are currently no other packages using it in fedora and no
bugs filed against it. 

Feel free to take it over if you want it...

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/a07e6937/attachment.sig>

From debarshi.ray at gmail.com  Mon Nov 19 21:02:07 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 20 Nov 2007 02:32:07 +0530
Subject: Bumping Anjuta version
Message-ID: <3170f42f0711191302j2e12e4f0qe4b73f2ca5ce2c62@mail.gmail.com>

Can the anjuta-2.2.0 and anjuta-gdl-0.7.3 packages be bumped to their
recent upstream versions? The latest upstream versions are 2.2.2 and
0.7.7 respectively.

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From lkundrak at redhat.com  Mon Nov 19 21:39:54 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 19 Nov 2007 22:39:54 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <4741A758.6040201@fedoraproject.org>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
	<47418E9A.9040603@leemhuis.info>
	<1195485134.7218.23.camel@localhost.localdomain>
	<4741A758.6040201@fedoraproject.org>
Message-ID: <1195508394.3568.16.camel@localhost.localdomain>


On Mon, 2007-11-19 at 20:40 +0530, Rahul Sundaram wrote:
> Lubomir Kundrak wrote:
> > On Mon, 2007-11-19 at 14:24 +0100, Thorsten Leemhuis wrote:
> >> On 19.11.2007 14:07, Lubomir Kundrak wrote:
> >>> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> >>>> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
> >>>>     * transparently handle local or remote console (via ssh)
> >>>>           o allow configuration of remote services
> >>> this is possible now:
> >>> ssh -X my.server system-config-httpd
> >> Wile at it: For me as heavy sudo user it does not work properly:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=142648
> >> https://bugzilla.redhat.com/show_bug.cgi?id=164671
> > 
> > It can be fixed easily by dumping sudo.
> 
> What? Why would we be dumping sudo?

I'm not saying we are. It was just a good friendly advise. Other
question would be -- why use it? Only use that can't be replaced by
other existing (and better) tools is to give untrusted users access to
privileged tools that weren't designed in security with mind.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lkundrak at redhat.com  Mon Nov 19 21:42:55 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 19 Nov 2007 22:42:55 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195477633.7218.21.camel@localhost.localdomain>
	<16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
Message-ID: <1195508575.3568.20.camel@localhost.localdomain>


On Mon, 2007-11-19 at 10:27 -0600, Arthur Pemberton wrote:
> On Nov 19, 2007 7:07 AM, Lubomir Kundrak <lkundrak at redhat.com> wrote:
> > Hi,
> >
> > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> > > I have expressed my ideas[1] to add and rework some of the
> > > functionality of the system-config tools with the hope of making them
> > > a bit more innovative and useful.
> > >
> > > Please comment on the idea.
> >
> > > Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
> > >
> > >     * transparently handle local or remote console (via ssh)
> > >           o allow configuration of remote services
> >
> > this is possible now:
> > ssh -X my.server system-config-httpd
> 
> One question: I know about this method, but have never tried it myself
> - doesn't it require an xserver on the host?

It does not. Why would it?

> One comment: The crowd that really love the system-config tools would
> like prefer not to be doing x forwarding via SSH

Why? Wasn't it the reason why X forwarding was born? Well, he can do
that without the forwarding, by just setting DISPLAY, with no obvious
benefits :)

> > >           o possible allow for OS independent usage (example: system-config-httpd could be used from Windows XP)
> >
> > You can do the very same thing from Windows XP.
> 
> I was thinking more in terms of the user just running system-config-*
> on Fedora|Windows|* and just enter in a host and passkey|user+pass and
> make changes to the target system

Well, it needs some fixes in Windows upstream. Until it happens,
cygwin/X is comfortable enough.

> > >           o allow for those who prefer not to run server tools with a X server installed to make use of the system-config tools
> >
> > None of the system-config-* tools depends on X server except for
> > system-config-display.
> 
> True, but you do generally need a GUI to make use of the GUI system-config tools

Will the proposed changes make me use the tools without a graphical
interface? Is the proposal about providing a TUI for each tool?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lkundrak at redhat.com  Mon Nov 19 21:46:06 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Mon, 19 Nov 2007 22:46:06 +0100
Subject: Volunteers for fixing and/or maintaning Tomcat
In-Reply-To: <1195491301.20121.4.camel@tophat.yyz.redhat.com>
References: <1195168424.29805.16.camel@localhost.localdomain>
	<1195184868.32233.26.camel@localhost.localdomain>
	<1195491301.20121.4.camel@tophat.yyz.redhat.com>
Message-ID: <1195508766.3568.22.camel@localhost.localdomain>


On Mon, 2007-11-19 at 11:55 -0500, Andrew Overholt wrote:
> Hi,
> 
> On Thu, 2007-11-15 at 19:47 -0800, Devrim G?ND?Z wrote:
> > 
> > On Fri, 2007-11-16 at 00:13 +0100, Lubomir Kundrak wrote:
> > 
> > > Is there anyone who would volunteer to fix and maintain tomcat?
> > 
> > I pushed tomcat5-5.5.25 to -devel with 2 new patches:
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=244210
> > 
> > 5.5.25 already fixes some of the security issues. I will wait until
> > tomorrow morning, and will push it to F-7 and F-8, too.
> 
> I didn't read fedora-devel since last week and just noticed this.  Does
> this affect eclipse which requires tomcat5?

I guess not.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From rich at phekda.gotadsl.co.uk  Mon Nov 19 21:48:27 2007
From: rich at phekda.gotadsl.co.uk (Richard Dawe)
Date: Mon, 19 Nov 2007 21:48:27 +0000
Subject: i386 packages missing from the F8 x86_64 repo
Message-ID: <474204AB.6020005@phekda.gotadsl.co.uk>

Hello.

I did a "yum upgrade" from F7 to F8 on my x86_64 box. Some of the
dependencies appeared to be missing from the x86_64 release directory:

http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/x86_64/os/Packages/

Specifically, I had to download these from the i386 release directory:

* dbus
* cyrus-sasl

Note that the x86_64 release directory includes i386 builds of
dbus-devel and cyrus-sasl-devel.

Some other packages are also affected by this problem (dirac), some
others not (dclib, distcache).

Thanks, Rich =]

-- 
Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ]

"Whatever you can do, or dream you can, begin it. Boldness has
genius, power, and magic in it." -- Johann Wolfgang von Goethe



From a.badger at gmail.com  Mon Nov 19 21:55:24 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Mon, 19 Nov 2007 13:55:24 -0800
Subject: PackageDB Documentation (was Re: FESCo meeting today at 20:00 UTC!)
In-Reply-To: <20071119190714.GB29715@free.fr>
References: <1195494068.6281.5.camel@nixon> <20071119190714.GB29715@free.fr>
Message-ID: <4742064C.6080104@gmail.com>

Patrice Dumas wrote:
>
> * And I think it could be nice to have somebody knowledgable in packagedb
>   to add something in the wiki, especially a page that can be reached from
>   the main page, with some explanation and links to where packagedb is
>   used.
> 
I've started a page here:
   http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb

Please send questions that I can answer to fill this page with useful 
information.  I'll be adding some of the things that I think will help 
people but having specific questions can show what I'm missing.

-Toshio



From jlb17 at duke.edu  Mon Nov 19 21:56:37 2007
From: jlb17 at duke.edu (Joshua Baker-LePain)
Date: Mon, 19 Nov 2007 16:56:37 -0500 (EST)
Subject: Slow performance writing to NetApp filer
In-Reply-To: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>
References: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>
Message-ID: <alpine.LRH.0.99999.0711191650400.30514@hogwarts.egr.duke.edu>

On Mon, 19 Nov 2007 at 3:30pm, Joshua Baker-LePain wrote

> I just submitted <https://bugzilla.redhat.com/show_bug.cgi?id=391021> 
> regarding an odd issue we're having.  Fedora (both 7 and 8) have horribly 
> slow performance when writing to our NetApp FAS3020 filer.  I've tested on 2 
> sets of hardware (i386 and x86_64, with tg3 and e1000 NICs).  No matter what 
> I try, it won't go faster than ~5MB/s.  The same hardware running CentOS-5 
> gets ~50MB/s.  Performance is just fine pointing the Fedora boxes at a 
> Panasas filer.
>
> Has anybody else run into this?  It seems a rather odd bug to me.

In response to Warren's email (which I saw in the list archives as I 
forgot to mention that I'm subscribed to the digest only) all testing was 
done using NFSv3 only.  I tried without any mount options, and also with 
explicit 32K block sizes.

-- 
Joshua Baker-LePain
QB3 Shared Cluster Sysadmin
UCSF



From kloczek at zie.pg.gda.pl  Mon Nov 19 22:13:32 2007
From: kloczek at zie.pg.gda.pl (=?UTF-8?Q?K=C5=82oczko?= Tomasz)
Date: Mon, 19 Nov 2007 23:13:32 +0100
Subject: trashed display raster fonts in gnome-terminal
Message-ID: <1195510413.4412.16.camel@dhcppc0>


After today upgrade to devel resources I observe trashing display fonts
in gnome-terminal whet it is used with Fixed o MiscFixed (raster) fonts.
during intensive terminal based work using not saleable fonts in
terminal is very importand for me (and probably not only for me).
Evrything works correctly when I switch to system fixed font
(scaleable).

Test case:
- pull down local menu in gnome-terinal and choose change current
  profile
- in profile dialog box dissable using systyem fixed font and switch
  to using font for example MiscFixed 13.

After close profile dialog box shell prompt will be trashed. After reset
command temporary all is back to correct behavior but after run anything
(mc or even ls command) all is trashed again.

Anyone can confirm this effect ? (for fill BR)

kloczek



From wtogami at redhat.com  Mon Nov 19 22:17:36 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 17:17:36 -0500
Subject: RFC: Package Review VCS
Message-ID: <47420B80.9070001@redhat.com>

Below is just an idea.  Please add your suggestions to refine this idea.

Proposal: Package Review VCS
============================
* /cvs/pkgreview has the same structure as /cvs/pkgs.   "make build" 
does koji build --scratch --background.  If the submitter isn't a Fedora 
packager yet, then the reviewer can import and build on their behalf 
after doing some basic sanity checks like:
    - does the package build locally?
    - does the package contain trojans?

* Faster and easier collaboration on new packages is enabled, meaning 
lower turnaround time during the review process.  After the initial 
.src.rpm URL, subsequent reviews can instead be done from a VCS 
checkout.  If the package contributor is already a packager, then a 
package review may begin directly from VCS.

* Changes that happen during the review process are tracked and not 
lost.  When the package review is approved, the CVS history is copied 
into /cvs/pkgs.

* We could control VCS write access to /pkgs/pkgreview with a different 
FAS group that is easy to obtain.  (i.e. any existing Fedora Packager 
can approve your access to pkgreviewrepo).  This allows new contributors 
to easily collaborate and add reviewer suggested changes.  The reviewer 
can then more conveniently review the changes and start another scratch 
build on behalf of the submitter.

* This allows a sort of "Level 0 Packager" entry-level access, where we 
provide a safe and easy way for new contributors to be eased onboard 
with a simpler subset of tools to work with.

Example Workflow
================
1) New contributor submits package review.
2)
	a) Reviewer takes review, imports .src.rpm into CVS, starts scratch build.
	b) Reviewer makes suggestions to improve the package.
	c) Reviewer grants pkgreviewrepo permission to contributor.
3) Contributor commits suggested changes to /cvs/pkgsreview, asks 
reviewer to check it again in the review ticket.
4) After review is approved and contributor is sponsored:
	a) Contributor requests fedora-cvs.
	b) CVS admin: Set pkgdb and koji bits.
	c) CVS admin: Copy history from /cvs/reviewpkg to /cvs/pkgs.
	d) CVS admin: Copy appropriate files in lookaside cache.

Other Minor Notes
=================
1) /cvs/pkgreview has its own separate lookaside binary cache, in order 
to reduce the amount of garbage that lives forever in the actual cache. 
  Appropriate files are copied over to /cvs/pkgs's cache when the 
package is approved.
2) /cvs/pkgreview allows global commit access to anybody in the 
pkgreviewrepo or packager groups.
3) pkgreviewrepo may allow a new contributor to commit, but we currently 
cannot allow this to build due to resource constraints and security 
concerns.  We may allow builds at a later date when we get more 
dedicated resources for review/scratch builders, isolated from our main 
builders.
4) Perhaps later we should consider an unofficial pkgreview yum repo. 
The reason for this, is to allow building a review package against 
another package also currently under review.  This would probably depend 
on resources/isolation needed for #3.

Thoughts?

Warren Togami
wtogami at redhat.com



From mclasen at redhat.com  Mon Nov 19 22:19:22 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 19 Nov 2007 17:19:22 -0500
Subject: trashed display raster fonts in gnome-terminal
In-Reply-To: <1195510413.4412.16.camel@dhcppc0>
References: <1195510413.4412.16.camel@dhcppc0>
Message-ID: <1195510762.26642.4.camel@localhost.localdomain>


On Mon, 2007-11-19 at 23:13 +0100, K?oczko Tomasz wrote:
> After today upgrade to devel resources I observe trashing display fonts
> in gnome-terminal whet it is used with Fixed o MiscFixed (raster) fonts.
> during intensive terminal based work using not saleable fonts in
> terminal is very importand for me (and probably not only for me).
> Evrything works correctly when I switch to system fixed font
> (scaleable).
> 
> Test case:
> - pull down local menu in gnome-terinal and choose change current
>   profile
> - in profile dialog box dissable using systyem fixed font and switch
>   to using font for example MiscFixed 13.
> 
> After close profile dialog box shell prompt will be trashed. After reset
> command temporary all is back to correct behavior but after run anything
> (mc or even ls command) all is trashed again.
> 
> Anyone can confirm this effect ? (for fill BR)

Like this ?

https://bugzilla.redhat.com/show_bug.cgi?id=384631




From pertusus at free.fr  Mon Nov 19 22:22:13 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Nov 2007 23:22:13 +0100
Subject: PackageDB Documentation (was Re: FESCo meeting today at 20:00
	UTC!)
In-Reply-To: <4742064C.6080104@gmail.com>
References: <1195494068.6281.5.camel@nixon> <20071119190714.GB29715@free.fr>
	<4742064C.6080104@gmail.com>
Message-ID: <20071119222213.GA2656@free.fr>

On Mon, Nov 19, 2007 at 01:55:24PM -0800, Toshio Kuratomi wrote:
> Patrice Dumas wrote:
>>
>> * And I think it could be nice to have somebody knowledgable in packagedb
>>   to add something in the wiki, especially a page that can be reached from
>>   the main page, with some explanation and links to where packagedb is
>>   used.
>>
> I've started a page here:
>   http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb
>
> Please send questions that I can answer to fill this page with useful 
> information.  I'll be adding some of the things that I think will help 
> people but having specific questions can show what I'm missing.

Looks good. I think that it would be nice to have the response to
'how do I see the package foo informations', 'by looking at 
https://admin.fedoraproject.org/pkgdb/packages/name/foo'.

There should be something about orphan packages, it can simply be a link
to http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages

Also maybe the answer to 'How can I add an entry in the Packagedb, for
me or a co-maintainer' with simply a redirection to 
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#head-529da50ad0b5cf0bedb9fdf47569c76657d79a7b

--
Pat



From kloczek at zie.pg.gda.pl  Mon Nov 19 22:24:34 2007
From: kloczek at zie.pg.gda.pl (=?UTF-8?Q?K=C5=82oczko?= Tomasz)
Date: Mon, 19 Nov 2007 23:24:34 +0100
Subject: trashed display raster fonts in gnome-terminal
In-Reply-To: <1195510762.26642.4.camel@localhost.localdomain>
References: <1195510413.4412.16.camel@dhcppc0>
	<1195510762.26642.4.camel@localhost.localdomain>
Message-ID: <1195511074.4412.22.camel@dhcppc0>


Dnia 19-11-2007, pon o godzinie 17:19 -0500, Matthias Clasen pisze:
> > Anyone can confirm this effect ? (for fill BR)
> 
> Like this ?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=384631

I observe the same effect as in first attachment (random noise).
For example just runned gnome-terminal with fixed font have trashed
(with simillar looking noise) shell prompt.

kloczek



From tcallawa at redhat.com  Mon Nov 19 22:29:15 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 19 Nov 2007 17:29:15 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <47420B80.9070001@redhat.com>
References: <47420B80.9070001@redhat.com>
Message-ID: <1195511355.27963.1.camel@localhost.localdomain>


On Mon, 2007-11-19 at 17:17 -0500, Warren Togami wrote:
> Below is just an idea.  Please add your suggestions to refine this idea.

We need to consider the legal implications of "hosting" content that we
shouldn't. Not that any Fedora contributor would consciously push
something that violates any laws or legal guidelines, but people aren't
always diligent in checking these items pre-review.

~spot



From wtogami at redhat.com  Mon Nov 19 22:38:38 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 17:38:38 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <1195511355.27963.1.camel@localhost.localdomain>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
Message-ID: <4742106E.50305@redhat.com>

Tom "spot" Callaway wrote:
> On Mon, 2007-11-19 at 17:17 -0500, Warren Togami wrote:
>> Below is just an idea.  Please add your suggestions to refine this idea.
> 
> We need to consider the legal implications of "hosting" content that we
> shouldn't. Not that any Fedora contributor would consciously push
> something that violates any laws or legal guidelines, but people aren't
> always diligent in checking these items pre-review.
> 
> ~spot
> 

I am hoping it will be OK if we have a standardized process for complete 
removal of things deemed to be not suitable for legal reasons.

Will you take point on verifying this is OK with legal?

Warren Togami
wtogami at redhat.com



From tcallawa at redhat.com  Mon Nov 19 22:42:52 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 19 Nov 2007 17:42:52 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <4742106E.50305@redhat.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
Message-ID: <1195512172.27963.3.camel@localhost.localdomain>


On Mon, 2007-11-19 at 17:38 -0500, Warren Togami wrote:
> Tom "spot" Callaway wrote:
> > On Mon, 2007-11-19 at 17:17 -0500, Warren Togami wrote:
> >> Below is just an idea.  Please add your suggestions to refine this idea.
> > 
> > We need to consider the legal implications of "hosting" content that we
> > shouldn't. Not that any Fedora contributor would consciously push
> > something that violates any laws or legal guidelines, but people aren't
> > always diligent in checking these items pre-review.
> > 
> > ~spot
> > 
> 
> I am hoping it will be OK if we have a standardized process for complete 
> removal of things deemed to be not suitable for legal reasons.

Document the standardized process for complete removal of things deemed
not to be suitable and I'll let you know. :)

~spot



From wtogami at redhat.com  Mon Nov 19 22:58:08 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 17:58:08 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <1195512172.27963.3.camel@localhost.localdomain>
References: <47420B80.9070001@redhat.com>	<1195511355.27963.1.camel@localhost.localdomain>	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
Message-ID: <47421500.2040807@redhat.com>

Tom "spot" Callaway wrote:
> On Mon, 2007-11-19 at 17:38 -0500, Warren Togami wrote:
>> Tom "spot" Callaway wrote:
>>> On Mon, 2007-11-19 at 17:17 -0500, Warren Togami wrote:
>>>> Below is just an idea.  Please add your suggestions to refine this idea.
>>> We need to consider the legal implications of "hosting" content that we
>>> shouldn't. Not that any Fedora contributor would consciously push
>>> something that violates any laws or legal guidelines, but people aren't
>>> always diligent in checking these items pre-review.
>>>
>>> ~spot
>>>
>> I am hoping it will be OK if we have a standardized process for complete 
>> removal of things deemed to be not suitable for legal reasons.
> 
> Document the standardized process for complete removal of things deemed
> not to be suitable and I'll let you know. :)
> 
> ~spot
> 

If the package reviewer identifies code uploaded to the CVS or lookaside 
binary cache not suitable for legal reasons, they are to set the 
fedora-cvs flag and request removal.  Fedora CVS admins will handle 
removals promptly.

Risk Mitigating Factor:
New contributors have no CVS commit access to /cvs/pkgreview at all 
until a reviewer gives them access.  The reviewer should know better 
than to allow something with legal problems into the CVS repo or to 
grant someone access to upload such code.  So in practice, this removal 
plan is likely to be needed rarely if ever.

Warren Togami
wtogami at redhat.com



From tcallawa at redhat.com  Mon Nov 19 22:57:47 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 19 Nov 2007 17:57:47 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <47421500.2040807@redhat.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com>
Message-ID: <1195513067.27963.5.camel@localhost.localdomain>


On Mon, 2007-11-19 at 17:58 -0500, Warren Togami wrote:

> If the package reviewer identifies code uploaded to the CVS or lookaside 
> binary cache not suitable for legal reasons, they are to set the 
> fedora-cvs flag and request removal.  Fedora CVS admins will handle 
> removals promptly.
> 
> Risk Mitigating Factor:
> New contributors have no CVS commit access to /cvs/pkgreview at all 
> until a reviewer gives them access.  The reviewer should know better 
> than to allow something with legal problems into the CVS repo or to 
> grant someone access to upload such code.  So in practice, this removal 
> plan is likely to be needed rarely if ever.

Works for me. :)

Thanks,

~spot



From wtogami at redhat.com  Mon Nov 19 23:24:37 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 18:24:37 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
Message-ID: <47421B35.4080006@redhat.com>

Fedora Engineering Steering Committee is considering removal of packages
from rawhide who have been without owners since prior to Fedora 8
sometime after the next FESCO meeting on November 29th.  The Fedora
Project routinely removes unmaintained packages from future
distributions in order to responsibly scale the growth of maintenance
burden with developer resources available within the project.

http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
Packages listed on this page are scheduled for removal unless an
existing Fedora maintainer claims ownership.

http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
A Fedora package developer may use their Fedora Account in PackageDB to
claim ownership of an orphaned package.

Removal of an orphaned package entails "blocking" it in the buildsystem
so it does not appear in the rawhide repository, and files in CVS of the
"devel" branch being replaced with an empty "dead.package" file.  At a
later date if a Fedora package developer wishes to revive a dead package
they may do so by claiming ownership in pkgdb then requesting the koji
block to be removed.  It is however a bit easier if ownership is claimed
prior to orphan removal, so please claim packages now if possible.

IMPORTANT NOTE: These removals do not effect prior releases, including
and up to Fedora 8.

Please send any questions to fedora-devel-list.

Thank you,
Warren Togami
wtogami at redhat.com

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From bpepple at fedoraproject.org  Mon Nov 19 23:34:31 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 19 Nov 2007 18:34:31 -0500
Subject: FESCo Meeting Summary for 2007-11-19
Message-ID: <1195515271.13194.4.camel@nixon>

= Members Present =
      * Brian Pepple (bpepple) 
      * Jason Tibbitts (tibbs) 
      * Dennis Gilmore (dgilmore) 
      * Bill Nottingham (notting) 
      * Tom Callaway (spot) 
      * Warren Togami (warren) 
      * Jeremy Katz (jeremy) 
      * David Woodhouse (dwmw2) 
      * Christian Iseli (c4chris) 
      * Josh Boyer (jwb) 
      * Kevin Fenzi (nirik) 

= Members Absent =
      * Christopher Aillon (caillon) 
      * Jesse Keating (f13) 

= Summary =
== Bugzilla Changes ==
      * FESCo approved the proposal from the QA team to simplify the
        displayed Fedora versions in bugzilla. For more details please
        refer to:
        https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01161.html 
        
      * Votes 
              * For: warren, tibbs, notting, bpepple, c4chris, jwb,
                nirik, dwmw2, dgilmore 
              * Against: None 
              * Abstain: spot, jeremy 

= Deadline to drop kmods =
      * FESCo approved a proposal to drop kmods immediately in Rawhide,
        since they will not be allowed in F9. Packages that depend on
        kmods will remain in Fedora because it's possible that the
        modules will get beaten into a shape, and included in upstream
        or Fedora kernels by F9 time.
 
      * Votes 
              * For: bpepple, jwb, dwmw2, warren, nirik, jeremy, tibbs,
                dgilmore, notting, c4chris 
              * Against: None 
              * Abstain: spot 

= PPC in F9+ =
      * FESCo approved a proposal for the build system bits to remain
        the same, but the QA & Release Engineering processed will be
        done by the PPC team. 
        
      * Votes 
              * For: dgilmore, c4chris, bpepple, jeremy, tibbs, nirik,
                warren, spot, dwmw2, notting 
              * Against: None 
              * Abstain: jwb 

= Dropping orphaned packages from F8 =
      * Discussed when packages orphaned packages from F8 will be
        dropped from Rawhide. warren will get a list of orphaned
        packages, and FESCo will vote on this next week. 

= Using mdomsch's rebuild scripts to find AWOL contributors =
      * Long discussion on possible solutions on finding AWOL
        contributors. For more details, please refer to the IRC log. 

= Misc =
      * tibbs brought up the use of scratch builds in the review
        process. For more details, please refer to the IRC log. 

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2007-11-19.html


Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/284aad29/attachment.sig>

From ben.lewis at benl.co.uk  Tue Nov 20 00:03:35 2007
From: ben.lewis at benl.co.uk (Benjamin Lewis)
Date: Tue, 20 Nov 2007 00:03:35 +0000
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <200711200003.41622.ben.lewis@benl.co.uk>

On Monday 19 November 2007 11:24:37 pm Warren Togami wrote:
> Fedora Engineering Steering Committee is considering removal of packages
> from rawhide who have been without owners since prior to Fedora 8
> sometime after the next FESCO meeting on November 29th.  The Fedora
> Project routinely removes unmaintained packages from future
> distributions in order to responsibly scale the growth of maintenance
> burden with developer resources available within the project.
>
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.

I do hope system-config-keyboard and rootpassword are not going to disappear, 
since they are listed on that page...



-- 

Benjamin Lewis
Fedora Ambassador
ben.lewis at benl.co.uk

-----------------------------------------------------------------------
http://benl.co.uk./                                 PGP Key: 0x647E480C

"In cases of major discrepancy, it is always reality that got it wrong"
                                                        -- RFC 1118
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/a42a65e1/attachment.sig>

From mzerqung at 0pointer.de  Tue Nov 20 00:17:11 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 20 Nov 2007 01:17:11 +0100
Subject: Pulseaudio problems
In-Reply-To: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
Message-ID: <20071120001711.GB21778@tango.0pointer.de>

On Sat, 17.11.07 08:35, Paulo Cavalcanti (promac at gmail.com) wrote:

> Hi,
> 
> I am trying to adapt myself to pulseaudio (F8 x86_64).
> 
> I had to change /etc/security/console.perms.d/50-default.perms
> so I can use another X screen (:1) without being root, and  without using
> pulse.

Hmm? I don't really understand what you edited in that file and what
you achieved with this?

BTW: It is a feature, not a bug that PA pauses playback when you
switch to a different session.

> Otherwise, I hear no sound using mplayer (this is how I send a movie to an
> ordinary TV).
> 
> After testing several applications, this is what I got so far
> trying to use pulseaudio with plugins (not using alsa generic plugin):
> 
> MythTV: NO sound at all (therefore, pulse can not be a global default for
> me)

Yes, MythTV is borken. Not only on PA. It assumes that mmap() is
available on all devices. Which is a bogus assumption. The PA plugin
for ALSA cannot do mmap. And many others cannot do this either
(i.e. the surround modes of EMU10K sound cards).

I think they now commited a fix for this to their VCS, but I am not
sure about the latest status of this, since I don't use this software
myself.

If you like to experiment you can use the ALSA mmap_emul plugin on top
of the pulse plugin. This emulates mmap on top of a non-mmap-capable
plugin for ALSA. YMMV. 

> audacious 1.4: OK with ESD (stutters a lot with its own pulse
> plugin).

Have you filed a bug to the audacious people on that? My PA plugin for
XMMS works fine. Apparently they broke it when they took it and ported
it to Audacious.

> vlc: NO plugin available.

I'd assume that this one works fine with our plugin for ALSA.

> Also, after an interval of time of maybe 10 to 20 min I hear a fast hiccup
> using amarock. I mean, the sound vanishes (but it is very fast), and it will
> happen
> again 10 min later, and so on...

Yes, I will have another look on the whole Xine situation.

> I also noticed that using
> 
> arecord -D hw:0.0 -d 0 -f S16_LE -c2 -r48000 | aplay -D pulse &
> 
> for capturing from line in.

Hmm? what did you notice?

> Sorry if I am writing to the wrong list, but I think this kind of
> information can be useful for the developers.

Actually it is quite useful. Thanks a lot.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From mzerqung at 0pointer.de  Tue Nov 20 00:33:34 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 20 Nov 2007 01:33:34 +0100
Subject: Pulseaudio problems
In-Reply-To: <870180fe0711172130n138e5c5ftab6f9a3c0011632d@mail.gmail.com>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
	<870180fe0711172130n138e5c5ftab6f9a3c0011632d@mail.gmail.com>
Message-ID: <20071120003333.GC21778@tango.0pointer.de>

On Sat, 17.11.07 22:30, Jerry James (loganjerry at gmail.com) wrote:

> On Nov 17, 2007 3:35 AM, Paulo Cavalcanti <promac at gmail.com> wrote:
> 
> > Sorry if I am writing to the wrong list, but I think this kind of
> > information
> > can be useful for the developers.
> >
> 
> While we're at it, here's a couple more.  When I play music with audacious
> and then also play Freeciv, when Freeciv should make the sound of gunfire,
> it instead makes a hair-raising screech.  Both applications sound fine when
> used separately.  Using them together worked with F7.

What audio API is this "freeciv" thing using?

> Also, XEmacs now crashes any time it tries to make a sound:
> https://bugzilla.redhat.com/show_bug.cgi?id=378851

The "ioplug" code in ALSA, which our PA plugin for ALSA is based on is
unfortunately not the most mature code in existence. It has been
around for a while, but we're now the first ones to actually use it
beyond basic testing.

You're probably encountering this bug:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From jan.kratochvil at redhat.com  Tue Nov 20 00:39:46 2007
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Tue, 20 Nov 2007 01:39:46 +0100
Subject: Optional packages for the build-time testsuite runs?
In-Reply-To: <20071119165707.GB23478@humbolt.us.dell.com>
References: <20071119132442.GA14216@host0.dyn.jankratochvil.net>
	<1195483324.28534.239.camel@mccallum.corsepiu.local>
	<20071119165707.GB23478@humbolt.us.dell.com>
Message-ID: <20071120003946.GA28609@host0.dyn.jankratochvil.net>

On Mon, 19 Nov 2007 17:57:08 +0100, Michael E Brown wrote:
> On Mon, Nov 19, 2007 at 03:42:04PM +0100, Ralf Corsepius wrote:
...
> > For chrooted "non-production/test-builds" (e.g. koji scratch-builts) I
> > edit the spec (adding %define _with_XXX <something> to the top of the
> > spec).

I do not like any hand-editing requirement, I was looking for a transparent
solution.

...
> 1) Use the 'more_buildreqs' mock config:
> 
> config_opts['more_buildreqs']['srpm_name-version-release'] =
> 'dependency list'

This would put the GDB-specific stuff (dependency list) into the mock package...


> 2) Use a RPM macro defined in mock to enable this:
> 
> config_opts['macros']['%_exhaustive_testsuite'] = "1"

Nice idea.  While it could be made clean by introducing such general macro
there so far I tried (going to commit it) a GDB-only automatic detection by:
	%if "%{_topdir}" == "/builddir/build"
	BuildRequires: gcc-xyzzy
	%endif

%_topdir is already being set by mock (and thus koji) to such value by default.
It can get updated later if someone introduces some "%XYZtestsuite" macro.


Thanks,
Jan



From mzerqung at 0pointer.de  Tue Nov 20 00:40:18 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 20 Nov 2007 01:40:18 +0100
Subject: Pulseaudio problems
In-Reply-To: <e1760170711180454r4fde7ff3ic8601127dacad80d@mail.gmail.com>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
	<e1760170711180454r4fde7ff3ic8601127dacad80d@mail.gmail.com>
Message-ID: <20071120004018.GD21778@tango.0pointer.de>

On Sun, 18.11.07 13:54, KH KH (kwizart at gmail.com) wrote:

> vlc can uses the ESoundD plugins (if compiled in) - the livna version
> has it, and raised it to be tried by default with Fedora 8... But...,
> some users reported crackles noises when used with PA see livna bug
> #1711...
> This tweak seems to solve the problem: (need to confirm: works for me)
> http://www.pulseaudio.org/wiki/PerfectSetup#ESOUNDApplications
> Add this to your .bashrc:
> if [ ! -e /tmp/.esd-${UID} ]; then
>         ln -fs /tmp/.esd /tmp/.esd-${UID}
> fi
> 
> Nicolas (kwizart )
> 
> 
> Solution consist to add this lines to your .bashrc : (seen
> if [ ! -e /tmp/.esd-${UID} ]; then
>         ln -s /tmp/.esd /tmp/.esd-${UID}
> fi
> 
> That

Uhh? Hacks like this certainly have no influence on "crackling" noises
or anything like this. If you have esd/libesd packages installed that are
at least 1:0.2.38-3 then this hack is certainly not necessary.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From eswierk at arastra.com  Tue Nov 20 02:19:02 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Mon, 19 Nov 2007 18:19:02 -0800
Subject: ApacheMirror.py for a site-local Fedora mirror
Message-ID: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>

Having tired of babysitting the rsync cron job that was keeping my
local Fedora mirror up-to-date, I tried the caching proxy approach
suggested at http://fedoraproject.org/wiki/Infrastructure/Mirroring/SiteLocalMirrors
for a few weeks. This, too, was unsatisfactory--I still want some
control over the mirrored content and the ability to pre-populate the
cache from a DVD ISO acquired via bittorrent when a new version of
Fedora is released.

ApacheMirror.py is a mod_python request handler that behaves like a
caching proxy, except it maps the URL path of a cached document
directly to a local directory rather than hashing the URL, this
preserving the mirror directory structure.

Just drop ApacheMirror.py into /usr/lib/python*/site-packages, set
your preferred upstream server and point it at a local directory on a
nice big disk, and forget it:

<VirtualHost *:80>
   ServerName mirrors.sample.com
   ServerName mirrors
   DocumentRoot /mirrors

   SetHandler mod_python
   PythonHandler ApacheMirror
   PythonDebug on
   PythonOption ApacheMirror.upstream http://download.fedora.redhat.com
</VirtualHost>

The implementation is by no means bulletproof--consider this release
0.1--but it's worked well enough to serve local yum needs for the past
few days.

If there's interest, I could package up the script into an srpm (which
seems overkill for 50 lines of Python) or submit it as a patch to some
existing package.

--Ed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ApacheMirror.py
Type: application/octet-stream
Size: 4135 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/66b80b83/attachment.obj>

From peter at thecodergeek.com  Tue Nov 20 02:33:20 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 19 Nov 2007 18:33:20 -0800
Subject: RPM Build Options (--with foo/--without bar, etc.) [Was: Re:
	Optional packages for the build-time testsuite runs?]
In-Reply-To: <1195483324.28534.239.camel@mccallum.corsepiu.local>
References: <20071119132442.GA14216@host0.dyn.jankratochvil.net>
	<1195483324.28534.239.camel@mccallum.corsepiu.local>
Message-ID: <1195526000.2967.16.camel@tuxhugs>

On Mon, 2007-11-19 at 15:42 +0100, Ralf Corsepius wrote:
> What I have done in similar situations [1] is applying rpm's
> --with/--without in combination with koji scratch builds and local
> builds.
> 
> I.e. I am using %{?_with_XXX} and friends inside of specs, such that you
> can specify them on rpmbuild's command-line for manual local builds. 

This is what I ended up doing for the startup-notification support in
Openbox a long time ago. (It was disabled by default at upstream's
request, but a simple "--with startup_notification" to rpmbuild would
have enabled it). If you intend to go about this path, I recommend using
the %bcond_with and %bcond_without macros. The encapsulate the
%{?_with_foo} stuff and make it just a little bit simpler. :)
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/0603363e/attachment.sig>

From jwboyer at gmail.com  Tue Nov 20 02:40:55 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 19 Nov 2007 20:40:55 -0600
Subject: RFC: Package Review VCS
In-Reply-To: <47420B80.9070001@redhat.com>
References: <47420B80.9070001@redhat.com>
Message-ID: <20071119204055.00c6b399@vader.jdub.homelinux.org>

On Mon, 19 Nov 2007 17:17:36 -0500
Warren Togami <wtogami at redhat.com> wrote:

> Below is just an idea.  Please add your suggestions to refine this idea.
> 
> Proposal: Package Review VCS
> ============================
> * /cvs/pkgreview has the same structure as /cvs/pkgs.   "make build" 
> does koji build --scratch --background.  If the submitter isn't a Fedora 
> packager yet, then the reviewer can import and build on their behalf 
> after doing some basic sanity checks like:
>     - does the package build locally?
>     - does the package contain trojans?


> 
> Thoughts?

The idea behind this is nice.  Using CVS to do it will suck.  Also, I'm
not sure it buys you a ton over keeping track of changes in the
specfile during review, which should already be done anyway.

josh



From skvidal at fedoraproject.org  Tue Nov 20 02:38:20 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 19 Nov 2007 21:38:20 -0500
Subject: RPM groups
In-Reply-To: <20071119180036.GA2364@jadzia.bu.edu>
References: <4741C213.6080308@redhat.com>
	<870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>
	<20071119124420.6a8969e6@redhat.com>
	<20071119180036.GA2364@jadzia.bu.edu>
Message-ID: <1195526300.30278.4.camel@cutter>


On Mon, 2007-11-19 at 13:00 -0500, Matthew Miller wrote:
> On Mon, Nov 19, 2007 at 12:44:20PM -0500, Jesse Keating wrote:
> > The FPC has mostly ignored the Groups tag.  It's not used by yum, and
> > thus all the tools based upon yum (pirut, anaconda, pungi, repoview,
> > etc...)  We strongly feel that grouping and tagging belongs outside of
> > the package itself (so that other people can group them as necessary
> > without rebuilding them, etc...) and thus we focus on having
> > appropriate grouping in comps, our current external grouping tool.
> 
> I'd really like to see a slow path to removing the tag completely from
> Fedora use.
> 
Matt,
 Dish this over to rpm-maint at rpm.org so those nice folks can debate it.

-sv






From 440volt.tux at gmail.com  Tue Nov 20 03:16:02 2007
From: 440volt.tux at gmail.com (subhodip biswas)
Date: Tue, 20 Nov 2007 08:46:02 +0530
Subject: orphaning dbh
In-Reply-To: <20071119133721.6d33e756@ghistelwchlohm.scrye.com>
References: <20071119133721.6d33e756@ghistelwchlohm.scrye.com>
Message-ID: <539333cb0711191916rf746ab7m74549fa356783340@mail.gmail.com>

On Nov 20, 2007 2:07 AM, Kevin Fenzi <kevin at scrye.com> wrote:
> I am going to orphan the 'dbh' package.
>
> "Disk based hash library".
>
> It was used long ago by Xfce, but no longer is. There are newer
> versions upstream and it could use more love than I'm willing to give
> it. There are currently no other packages using it in fedora and no
> bugs filed against it.
>
> Feel free to take it over if you want it...
>
> kevin
>

If anybody has not taken it already i will be taking it


-- 
Regards
Subhodip Biswas

GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas



From wtogami at redhat.com  Tue Nov 20 03:19:43 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 22:19:43 -0500
Subject: InstantMirror Proposal Re: ApacheMirror.py for a site-local Fedora
 mirror
In-Reply-To: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>
Message-ID: <4742524F.2010705@redhat.com>

Ed Swierk wrote:
> Having tired of babysitting the rsync cron job that was keeping my
> local Fedora mirror up-to-date, I tried the caching proxy approach
> suggested at http://fedoraproject.org/wiki/Infrastructure/Mirroring/SiteLocalMirrors
> for a few weeks. This, too, was unsatisfactory--I still want some
> control over the mirrored content and the ability to pre-populate the
> cache from a DVD ISO acquired via bittorrent when a new version of
> Fedora is released.
> 
> ApacheMirror.py is a mod_python request handler that behaves like a
> caching proxy, except it maps the URL path of a cached document
> directly to a local directory rather than hashing the URL, this
> preserving the mirror directory structure.
> 
> Just drop ApacheMirror.py into /usr/lib/python*/site-packages, set
> your preferred upstream server and point it at a local directory on a
> nice big disk, and forget it:
> 
> <VirtualHost *:80>
>    ServerName mirrors.sample.com
>    ServerName mirrors
>    DocumentRoot /mirrors
> 
>    SetHandler mod_python
>    PythonHandler ApacheMirror
>    PythonDebug on
>    PythonOption ApacheMirror.upstream http://download.fedora.redhat.com
> </VirtualHost>
> 
> The implementation is by no means bulletproof--consider this release
> 0.1--but it's worked well enough to serve local yum needs for the past
> few days.
> 
> If there's interest, I could package up the script into an srpm (which
> seems overkill for 50 lines of Python) or submit it as a patch to some
> existing package.
> 
> --Ed
> 

Excellent, I was hoping for something like this!  I had played a bit 
with both squid and varnish, but neither were fully satisfactory because 
they can't easily store your cache in the original directory structure 
without writing your own backend storage engine.

http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/RequestingNewProject
Could you please create an "upstream" project for it at 
hosted.fedoraproject.org?  I think there are a number of improvements 
that can be made.

I didn't read deeply into your code yet, but I imagine that it needs 
improvement to handle unique synchronization and expiration issues that 
yum repos and rawhide install trees create when file contents change 
without changing filenames.

Perhaps a separate, asynchronous daemon can monitor upstream (via HTTP 
or whatever) for repomd.xml changes.  It should then parse the 
repomd.xml so it knows when to expire the repodata/* files.  Then it 
should parse the .xml files in repodata/ to compare it to local storage, 
and intelligently expire the packages if any changed (as happens during 
signing).  It can then know exactly which files to delete from the local 
cache because they are no longer in the upstream.  This daemon interacts 
with ApacheMirror.py only in deleting files from the local directories, 
effectively expiring the cache.  Very simple.

That daemon could be configured to handle intelligent expiry of various 
parts of the mirror tree in different ways.  For example:
- development (rawhide) repo changes at least once per day.  It also 
contains install images (boot.iso, bootdisk.img, stage2, etc.) that need 
to be expired every time the tree changes.  (We might need to add a 
hashes file to the mirror tree to allow the tool to monitor these changes.)
- Released distros never change, so don't need to monitor their 
repomd.xml for changes.

Please create an upstream project at hosted.fedoraproject.org and let's 
get started on this!  Here you get to choose an project name for your 
new "upstream" project.  I personally would choose something like really 
obvious like InstantMirror... but you get to choose.

The default definitions for mirroring download.fedoraproject.org could 
be included in a Fedora/EPEL package that requires ApacheMirror.py and 
the monitor/expiry daemon.  That way a sysadmin who wants to create an 
instant Fedora mirror need only install that package and enable it in 
/etc/httpd/conf.d/.  yum update handles pulling in updates for tree 
changes (repo locations, how often to poll for repomd.xml changes, etc.)

Example:
yum install InstantMirror-fedora
vim /etc/httpd/conf.d/InstantMirror-fedora.conf
#(enable stuff)
service httpd restart
# http://fedora.localdomain.com
Instant Fedora mirror!

InstantMirror-fedora.noarch.rpm    : instant Fedora mirror
InstantMirror-centos.noarch.rpm    : instant CentOS mirror
InstantMirror-rpmfusion.noarch.rpm : instant RPMFusion mirror
InstantMirror-foo.noarch.rpm       : instant Foo mirror

Warren Togami
wtogami at redhat.com

p.s.
The same code could be used to create a public static-repos mirror. 
static-repos changes many times per hour, probe for changes every 2 
minutes.  We need a few permanent public mirrors of this so people stop 
hitting the koji server directly.  Any public mirror interested in 
hosting this?

p.p.s.
Another idea before I forget about it:
Later add configurable fallbacks to a different upstream if 
download.fp.org is down.  mirrors.kernel.org might be a good alternative 
for default, for example.



From wtogami at redhat.com  Tue Nov 20 03:39:08 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 19 Nov 2007 22:39:08 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <20071119204055.00c6b399@vader.jdub.homelinux.org>
References: <47420B80.9070001@redhat.com>
	<20071119204055.00c6b399@vader.jdub.homelinux.org>
Message-ID: <474256DC.2030801@redhat.com>

Josh Boyer wrote:
> 
> The idea behind this is nice.  Using CVS to do it will suck.  

What about it exactly?
Using CVS as a tool again when we should be using a more modern VCS?

I suppose we could use a different VCS tool here in order to open up 
experimentation of new tools in a non-critical area.  This however would 
have the detriment of losing an opportunity for newbie training, for new 
contributors to become familiar with our strange CVS structure and 
"make" commands in a safe environment.

(OTOH, this would be a great opportunity to show people bzr's awesome 
checkout --lightweight feature.  bzr allows the user to use bzr as 
either a distributed VCS like git, or in the traditional 
checkin-directly-upstream mode like CVS.  bzr is very user friendly, 
fast and flexible.  But then the above detriment...)

> Also, I'm not sure it buys you a ton over keeping track of changes in the
> specfile during review, which should already be done anyway.
> 
> josh
> 

While most spec changes during a review will be boring, it is sometimes 
worthwhile to keep them in history.  A more interesting thing this 
enables may be during pre-review, where it can act as a playpen/staging 
ground for rapid packaging and testing.  Imagine this:

1) Existing Fedora packager begins work on a new package.
2) cvs-import.sh in /cvs/pkgreview, existin Fedora packager can create 
whatever they want, whenever they want.
3) They might ask other people to help in packaging.  *Real* quick 
centralized place to point other people to ask for help.
4) *Real* quick build testing on all archs directly from your 
work-in-progress.

I call that enabling.

I suppose we could make using /cvs/pkgreview optional for package 
reviews.  And Merge Review could use /cvs/pkgs instead.  But I can't 
imagine why anybody would prefer the hassle of spinning new .src.rpm's 
and uploading them to a web accessible URL several times instead of 
simply using a VCS.

Warren Togami
wtogami at redhat.com



From kewley at gps.caltech.edu  Tue Nov 20 04:13:45 2007
From: kewley at gps.caltech.edu (David Kewley)
Date: Mon, 19 Nov 2007 18:13:45 -1000
Subject: Smolt database is broken
In-Reply-To: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
Message-ID: <200711191813.45675.kewley@gps.caltech.edu>

On Monday 19 November 2007, Michael Wiktowy wrote:
> I just submitted my profile a few days ago and immediately tried to
> retrieve it and got some other machine that didn't match my config. So
> I submitted it again and things looked a bit more reasonable. Today I
> checked it again and the vast majority of it has changed.
>
> So there is some massive database corruption going on AFAICT. Did I
> miss a message somewhere indicating this?

I noticed something similar many months ago, where my machine's entry didn't 
even have the right architecture.  As I recall, I emailed the Smolt 
maintainer, and he said it was probably a problem with the client-side UUID 
generation not being random enough.  As a result, multiple machines could 
get the same UUID and so write to the same server database entry.  That's 
the last I heard about it.

David



From seg at haxxed.com  Tue Nov 20 04:13:54 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 19 Nov 2007 22:13:54 -0600
Subject: pulseaudio CPU usage and process name
In-Reply-To: <20071116233910.GA3133@tango.0pointer.de>
References: <3da3b5b40711161052l61bd1919n3dda89af05dc0865@mail.gmail.com>
	<20071116192148.GA17455@tango.0pointer.de>
	<3da3b5b40711161157m62cb3fbfwb8910db0567668c8@mail.gmail.com>
	<20071116212243.GA27498@tango.0pointer.de>
	<1195253906.24564.10.camel@localhost>
	<20071116233910.GA3133@tango.0pointer.de>
Message-ID: <1195532034.20933.58.camel@localhost>


On Sat, 2007-11-17 at 00:39 +0100, Lennart Poettering wrote:
> Different resamplers have different properties. The advantage of SRC
> is the superb quality, the disadvantages are that it is float-only and
> GPL'ed, and thus not really useful on embedded systems and when you
> want to load proprietary modules into PA (note that PA is fully
> LGPL-licensed, but if you link it against SRC the daemon is
> practically "down"graded to GPL).
> 
> The good about the Speex resampler is that it can do both float and
> integer resampling, that it is BSD-licensed and it is a bit faster
> than SRC.

Hmmm I see. int-float-int conversion would not be fast. :)

Jackd is float only so I suppose that's why SRC is popular there.

> We chose to make the speex resampler the default. If you prefer the
> extra quality of SRC, then you are free to reconfigure
> daemon.conf. But trust me, you CPU load is not going to decrease if
> you do that ;-).

I just want my music to be listenable. Which seems to require at minimum
a sinc interpolator. Which it looks like speex is using. Hmmm.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/28ec39d8/attachment.sig>

From debarshi.ray at gmail.com  Tue Nov 20 04:17:20 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Tue, 20 Nov 2007 09:47:20 +0530
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <3170f42f0711192017y7343c73as83f0b194e9dd7a6c@mail.gmail.com>

> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.

I have taken redet-doc. I missed it while taking over redet.

What about system-config-keyboard? Is it being replaced by something
else and deprecated these days? If not I can take it too.

Thanks,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From loupgaroublond at gmail.com  Tue Nov 20 04:32:03 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Mon, 19 Nov 2007 23:32:03 -0500
Subject: Smolt database is broken
In-Reply-To: <200711191813.45675.kewley@gps.caltech.edu>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
Message-ID: <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>

On Nov 19, 2007 11:13 PM, David Kewley <kewley at gps.caltech.edu> wrote:
> I noticed something similar many months ago, where my machine's entry didn't
> even have the right architecture.  As I recall, I emailed the Smolt
> maintainer, and he said it was probably a problem with the client-side UUID
> generation not being random enough.  As a result, multiple machines could
> get the same UUID and so write to the same server database entry.  That's
> the last I heard about it.

That is in fact a possibility.  It uses the output from
/proc/sys/kernel/random/uuid to work.  Is there a flaw with this
method that we know nothing about?  Should we use another?

-Yaakov



From mmcgrath at redhat.com  Tue Nov 20 04:47:20 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Mon, 19 Nov 2007 22:47:20 -0600
Subject: Smolt database is broken
In-Reply-To: <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
Message-ID: <474266D8.5020606@redhat.com>

Yaakov Nemoy wrote:
> On Nov 19, 2007 11:13 PM, David Kewley <kewley at gps.caltech.edu> wrote:
>   
>> I noticed something similar many months ago, where my machine's entry didn't
>> even have the right architecture.  As I recall, I emailed the Smolt
>> maintainer, and he said it was probably a problem with the client-side UUID
>> generation not being random enough.  As a result, multiple machines could
>> get the same UUID and so write to the same server database entry.  That's
>> the last I heard about it.
>>     
>
> That is in fact a possibility.  It uses the output from
> /proc/sys/kernel/random/uuid to work.  Is there a flaw with this
> method that we know nothing about?  Should we use another?
>   

Its funny (not that I'm laughing) but there seems to be a handful of 
UUID's that come up more often then others.  two or three of them quite 
a bit more often.  It might be worth it to black list those UUID's and 
have the client re-generate if one of those UUID's comes up.  If there 
is a problem with /proc/sys/kernel/random/uuid not being random enough 
though this might not actually correct anything.  Can anyone confirm?

    -Mike



From loganjerry at gmail.com  Tue Nov 20 05:06:42 2007
From: loganjerry at gmail.com (Jerry James)
Date: Mon, 19 Nov 2007 22:06:42 -0700
Subject: Pulseaudio problems
In-Reply-To: <20071120003333.GC21778@tango.0pointer.de>
References: <68720af30711170235r57d8baa8g74630f7621761a8a@mail.gmail.com>
	<870180fe0711172130n138e5c5ftab6f9a3c0011632d@mail.gmail.com>
	<20071120003333.GC21778@tango.0pointer.de>
Message-ID: <870180fe0711192106m3829ce3kd54277fbb5555f80@mail.gmail.com>

On Nov 19, 2007 5:33 PM, Lennart Poettering <mzerqung at 0pointer.de> wrote:

> What audio API is this "freeciv" thing using?


It has three APIs it can use: ALSA, SDL, and esd.  I had it set to ALSA
during the pre-F8 days.  I'll try one of the other two and see if the
problem goes away.


> The "ioplug" code in ALSA, which our PA plugin for ALSA is based on is
> unfortunately not the most mature code in existence. It has been
> around for a while, but we're now the first ones to actually use it
> beyond basic testing.
>
> You're probably encountering this bug:
>
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601
>

Yes, that bug mentions the same assertion failure.  Thanks for the pointer.
-- 
Jerry James
http://loganjerry.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071119/44afb3a8/attachment.htm>

From bernie at codewiz.org  Tue Nov 20 05:12:29 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Tue, 20 Nov 2007 00:12:29 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <20071119124532.0731f106@redhat.com>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>	<20071109095230.GB2871@petra.dvoda.cz>	<20071109112208.GA12660@xi.wantstofly.org>	<4741C5E2.4090609@codewiz.org>
	<20071119124532.0731f106@redhat.com>
Message-ID: <47426CBD.1090800@codewiz.org>

Jesse Keating wrote:
> On Mon, 19 Nov 2007 12:20:34 -0500
> Bernardo Innocenti <bernie at codewiz.org> wrote:
>
>> My impression is that setting up a local koji server on
>> workstation machines is way too complicated.  What an
>> individual developer would need is the same ability to
>> build packates, but without the added complexity xmlrpc,
>> multiuser, clustering and web interface.
> 
> Could this not be accomplished with my koper idea?
> http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos

Indeed, I like it very much!  It's maybe not as versatile
as what I had in mind, but it has a higher features/complexity
ratio.  Is anyone working on implementing it?

To make this development model feasable, I think we should also
speedup uploading srpms to koji, which is needed for scratch
builds.  Uploading the kernel srpm takes around 20-30 minutes.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From lightsolphoenix at gmail.com  Tue Nov 20 06:08:17 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Tue, 20 Nov 2007 01:08:17 -0500
Subject: NetworkManager - Why Doesn't nm-applet have a way of using WPA-PSK?
Message-ID: <474279D1.7060709@gmail.com>

I can't seem to set WPA-PSK in nm-applet like I can in knetworkmanager.  
And believe me, I looked.  Hard.

For a while, I thought NetworkManager couldn't do WPA-PSK at all, but I 
found it easily in knetworkmanager.  And since the current setup (Fedora 
8) doesn't have it yet, I'd consider this a big big problem...



From jdieter at gmail.com  Tue Nov 20 06:14:53 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Tue, 20 Nov 2007 08:14:53 +0200
Subject: NetworkManager - Why Doesn't nm-applet have a way of using
	WPA-PSK?
In-Reply-To: <474279D1.7060709@gmail.com>
References: <474279D1.7060709@gmail.com>
Message-ID: <1195539293.3640.8.camel@jndwidescreen.lesbg.loc>

On Tue, 2007-11-20 at 01:08 -0500, Kelly Miller wrote:
> I can't seem to set WPA-PSK in nm-applet like I can in knetworkmanager.  
> And believe me, I looked.  Hard.
> 
> For a while, I thought NetworkManager couldn't do WPA-PSK at all, but I 
> found it easily in knetworkmanager.  And since the current setup (Fedora 
> 8) doesn't have it yet, I'd consider this a big big problem...
> 

I have no problems connecting to a AP with running WPA-PSK using F8.  It
automatically detected the encryption and asked for a passphrase (which
it then automagically stored in gnome-keyring).

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/54ba54a1/attachment.sig>

From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 20 06:31:27 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 20 Nov 2007 07:31:27 +0100
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <20071120073127.3fb29173.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 19 Nov 2007 18:24:37 -0500, Warren Togami wrote:

> Fedora Engineering Steering Committee is considering removal of packages
> from rawhide who have been without owners since prior to Fedora 8
> sometime after the next FESCO meeting on November 29th.  The Fedora
> Project routinely removes unmaintained packages from future
> distributions in order to responsibly scale the growth of maintenance
> burden with developer resources available within the project.
> 
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.
> 
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> A Fedora package developer may use their Fedora Account in PackageDB to
> claim ownership of an orphaned package.

Hmmm, several packages build with  libid3tag  and it hasn't seen an
upstream release for several years, so surely we can co-maintain it
as a team:

audacity
gnomad2
muine
gtkpod
imlib2-id3tag-loader

gstreamer-plugins-ugly (Livna)
mpd (Livna)
vlc (Livna)
vdr-mp3 (Livna)
mpg321 (Livna)
madplay (Livna)



From lordmorgul at gmail.com  Tue Nov 20 06:53:19 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Mon, 19 Nov 2007 22:53:19 -0800
Subject: NetworkManager - Why Doesn't nm-applet have a way of
	using	WPA-PSK?
In-Reply-To: <1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
Message-ID: <4742845F.8030606@gmail.com>

Jonathan Dieter wrote:
> On Tue, 2007-11-20 at 01:08 -0500, Kelly Miller wrote:
>> I can't seem to set WPA-PSK in nm-applet like I can in knetworkmanager.  
>> And believe me, I looked.  Hard.
>>
>> For a while, I thought NetworkManager couldn't do WPA-PSK at all, but I 
>> found it easily in knetworkmanager.  And since the current setup (Fedora 
>> 8) doesn't have it yet, I'd consider this a big big problem...
>>
> 
> I have no problems connecting to a AP with running WPA-PSK using F8.  It
> automatically detected the encryption and asked for a passphrase (which
> it then automagically stored in gnome-keyring).
> 
> Jonathan

Was your access point configured to only allow this option?  Sounds like the OP
is wanting to FORCE the use of WPA-PSK (i.e. access point will allow it), not
just have NM make the choice automatically.  The access point may be setup to
allow several security options.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From jfrieben at gmx.de  Tue Nov 20 06:57:03 2007
From: jfrieben at gmx.de (Joachim Frieben)
Date: Tue, 20 Nov 2007 07:57:03 +0100
Subject: trashed display raster fonts in gnome-terminal
In-Reply-To: <1195510413.4412.16.camel@dhcppc0>
References: <1195510413.4412.16.camel@dhcppc0>
Message-ID: <20071120065703.48600@gmx.net>

> After today upgrade to devel resources I observe trashing display fonts
> in gnome-terminal whet it is used with Fixed o MiscFixed (raster) fonts.
> during intensive terminal based work using not saleable fonts in
> terminal is very importand for me (and probably not only for me).
> Evrything works correctly when I switch to system fixed font
> (scaleable).

I had encountered this issue after the latest big X server update, too. It disappeared after restarting the system [X].
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer



From tmz at pobox.com  Tue Nov 20 07:04:06 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 20 Nov 2007 02:04:06 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <20071120073127.3fb29173.mschwendt.tmp0701.nospam@arcor.de>
References: <47421B35.4080006@redhat.com>
	<20071120073127.3fb29173.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071120070406.GA2967@psilocybe.teonanacatl.org>

Michael Schwendt wrote:
> Hmmm, several packages build with  libid3tag  and it hasn't seen an
> upstream release for several years, so surely we can co-maintain it
> as a team:

That'd be great.  I meant to pipe up when I saw Ville's initial
message about orphaning libid3tag, since gtkpod uses it.  I added
myself as a maintainer for the F-7, F-8, and devel branches after
Warren's mail.  But the more eyes and hands on things, the lighter the
load.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I visualize a time when we will be to robots what dogs are to humans,
and I'm rooting for the machines.
    -- Claude Shannon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/23852b67/attachment.sig>

From lightsolphoenix at gmail.com  Tue Nov 20 07:26:27 2007
From: lightsolphoenix at gmail.com (Kelly Miller)
Date: Tue, 20 Nov 2007 02:26:27 -0500
Subject: NetworkManager - Why Doesn't nm-applet have a way
	of	using	WPA-PSK?
In-Reply-To: <4742845F.8030606@gmail.com>
References: <474279D1.7060709@gmail.com>	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com>
Message-ID: <47428C23.6030507@gmail.com>

Andrew Farris wrote:
> Was your access point configured to only allow this option?  Sounds like the OP
> is wanting to FORCE the use of WPA-PSK (i.e. access point will allow it), not
> just have NM make the choice automatically.  The access point may be setup to
> allow several security options.
>   
Yes, I have to force it, because up until today the system was using 
WEP.  However, I found out through experimentation that my wireless 
network was acting horribly flaky, and I managed to track it to the WEP 
key itself (when I removed the security, everything worked fine).  So I 
switched the access point to use WPA-PSK, as a better option than 
leaving it wide open.  But NetworkManager was still insisting it used 
WEP, so I was trying to force it to switch.  nm-applet allows manually 
selecting WEP and a few other options, but not WPA-PSK with a specific 
encryption cipher.



From fedora at leemhuis.info  Tue Nov 20 07:56:20 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 20 Nov 2007 08:56:20 +0100
Subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo
 after the merge)
In-Reply-To: <20071119130215.220c71e5@redhat.com>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>
	<20071119095558.GC2584@free.fr>	<4741B869.9040508@leemhuis.info>	<20071119114942.697bc4b0@redhat.com>	<4741CD4C.1080601@leemhuis.info>
	<20071119130215.220c71e5@redhat.com>
Message-ID: <47429324.3070308@leemhuis.info>



On 19.11.2007 19:02, Jesse Keating wrote:
> On Mon, 19 Nov 2007 18:52:12 +0100
> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
>> /me removes the newlines and created a quick loop in bash
>> Here is your "script":
>> ---
>> for package in blam chmsee devhelp epiphany epiphany-extensions
>> firefox galeon gnome-python2-extras gnome-web-photo gtkmozembedmm
>> kazehakase liferea Miro openvrml ruby-gnome2 yelp; do
>> 	pushd ${package}
>> 	bumpspecfile.py *.spec
>> 	make tag build
>> 	popd
>> done
> So this is great and all, but it's FF specific, where we're moving to
> xulrunner anyway.  Time is better spent getting these things to support
> xul.

F8 will still be around for about 12 months, which IMHO is more then
enough a reason to warrant one or two of work. Especially as it safes
the maintainers of the packages some work, so in the end less work for
everybody.

BTW, does xulrunner properly and for real solve the problem? The current
rawhide package just as firefox has a path with a version number in it
(/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
packages taht depend on a particular xulrunner version. Or is there some
abstraction somewhere to make sure packages don't depend on a particular
version of xulrunner?

> Not that this script isn't handy at all.  In fact, I think we (as
> Fedora) need to appoint somebody or some "body" (like a SIG) to oversee
> the entire gecko stack both now and in the future to ensure that
> updates are coordinated.

Maybe, yes, but I tend a bit to the "who broke something should at least
do minimal efforts to get it fixed". IOW: the one that rebuilds firefox
should ask rel-eng to put it into the buildroot and call the script once
it really exists.

>  Just building is only one part of the puzzle,
> they all have to get pushed out at the same time and into the same
> repos.

With the new bodhi command line interface this shouldn't be to hard afaics.

> I don't have the time or energy to own this problem space.

I'd be willing to create the script properly and modify the packages if
I can do it directly in CVS (after a public review of course) if FESCO
backs the effort.

> [...]

CU
knurd



From fedora at leemhuis.info  Tue Nov 20 08:01:41 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 20 Nov 2007 09:01:41 +0100
Subject: Review queue/FESCo after the merge
In-Reply-To: <1195490984.28534.253.camel@mccallum.corsepiu.local>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>	<20071119095558.GC2584@free.fr>
	<4741B869.9040508@leemhuis.info>
	<1195490984.28534.253.camel@mccallum.corsepiu.local>
Message-ID: <47429465.9070008@leemhuis.info>

On 19.11.2007 17:49, Ralf Corsepius wrote:
> [...]
> Technically, changes related to these topics are close to trivial (and
> partially scriptable) for an "experienced user". The "normal" BZ'em, nag
> maintainer and launch AWOL-process if necessary is much more effort and
> (at least to me) too inconvenient on most occasions (ie. unless
> inevitable for technical reasons).

And it seem the overhead is to big for others as well (including me).

We need to get rid of the overhead -- it seems to become more and more a
problem afaics as known problems (most small, others medium sized) don't
get fixed.

Cu
knurd



From denis at poolshark.org  Tue Nov 20 08:25:47 2007
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 20 Nov 2007 09:25:47 +0100
Subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo
 after the merge)
In-Reply-To: <47429324.3070308@leemhuis.info>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>	<20071119095558.GC2584@free.fr>	<4741B869.9040508@leemhuis.info>	<20071119114942.697bc4b0@redhat.com>	<4741CD4C.1080601@leemhuis.info>	<20071119130215.220c71e5@redhat.com>
	<47429324.3070308@leemhuis.info>
Message-ID: <47429A0B.1050906@poolshark.org>

Thorsten Leemhuis wrote:
> 
> On 19.11.2007 19:02, Jesse Keating wrote:
>> On Mon, 19 Nov 2007 18:52:12 +0100
>> Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>>
>>> /me removes the newlines and created a quick loop in bash
>>> Here is your "script":
>>> ---
>>> for package in blam chmsee devhelp epiphany epiphany-extensions
>>> firefox galeon gnome-python2-extras gnome-web-photo gtkmozembedmm
>>> kazehakase liferea Miro openvrml ruby-gnome2 yelp; do
>>> 	pushd ${package}
>>> 	bumpspecfile.py *.spec
>>> 	make tag build
>>> 	popd
>>> done
>> So this is great and all, but it's FF specific, where we're moving to
>> xulrunner anyway.  Time is better spent getting these things to support
>> xul.
> 
> F8 will still be around for about 12 months, which IMHO is more then
> enough a reason to warrant one or two of work. Especially as it safes
> the maintainers of the packages some work, so in the end less work for
> everybody.
> 
> BTW, does xulrunner properly and for real solve the problem? The current
> rawhide package just as firefox has a path with a version number in it
> (/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
> packages taht depend on a particular xulrunner version. Or is there some
> abstraction somewhere to make sure packages don't depend on a particular
> version of xulrunner?

I also don't understand. I thought the whole point of having xulrunner 
was precisely so we can package it properly using a more classic dynamic 
libraries versioning scheme...

-d



From andy at smile.org.ua  Tue Nov 20 08:58:42 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Tue, 20 Nov 2007 10:58:42 +0200
Subject: UniConvertor: is it possible to include to Fedora?
Message-ID: <20071120085842.GA9545@serv.smile.org.ua>

Hi!

I'd like to add UniConvertor[1] to the Fedora.
However I think the legal issues are may present.
Who could comment that code? 

Possible, I wrote to the wrong list?

[1] 
Project page: http://sk1project.org/modules.php?name=Products&product=uniconvertor
Prepared package: ftp://toaster.asplinux.com.ua/pub/people/andy/extras/uniconvertor-1.0.0-1.fc7.src.rpm

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From j.w.r.degoede at hhs.nl  Tue Nov 20 09:00:20 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 10:00:20 +0100
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <20071120070406.GA2967@psilocybe.teonanacatl.org>
References: <47421B35.4080006@redhat.com>	<20071120073127.3fb29173.mschwendt.tmp0701.nospam@arcor.de>
	<20071120070406.GA2967@psilocybe.teonanacatl.org>
Message-ID: <4742A224.4010807@hhs.nl>

Todd Zullinger wrote:
> Michael Schwendt wrote:
>> Hmmm, several packages build with  libid3tag  and it hasn't seen an
>> upstream release for several years, so surely we can co-maintain it
>> as a team:
> 
> That'd be great.  I meant to pipe up when I saw Ville's initial
> message about orphaning libid3tag, since gtkpod uses it.  I added
> myself as a maintainer for the F-7, F-8, and devel branches after
> Warren's mail.  But the more eyes and hands on things, the lighter the
> load.
> 

Good,

I maintain 2 packages who depend on libid3tag too, so I've just 
requested the necessary rights for co-maintainer ship.

Regards,

Hans



From nicolas.mailhot at laposte.net  Tue Nov 20 09:18:28 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 20 Nov 2007 10:18:28 +0100 (CET)
Subject: UniConvertor: is it possible to include to Fedora?
Message-ID: <50024.192.54.193.53.1195550308.squirrel@rousalka.dyndns.org>


Le Mar 20 novembre 2007 09:58, Andy Shevchenko a ?crit :
> Hi!
>
> I'd like to add UniConvertor[1] to the Fedora.
> However I think the legal issues are may present.

If you have any doubt on legal aspects, ask fedora-legal

http://fedoraproject.org/wiki/Legal

Regards,

-- 
Nicolas Mailhot



From j.w.r.degoede at hhs.nl  Tue Nov 20 09:02:11 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 10:02:11 +0100
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <4742A293.8060509@hhs.nl>

Warren Togami wrote:
> Fedora Engineering Steering Committee is considering removal of packages
> from rawhide who have been without owners since prior to Fedora 8
> sometime after the next FESCO meeting on November 29th.  The Fedora
> Project routinely removes unmaintained packages from future
> distributions in order to responsibly scale the growth of maintenance
> burden with developer resources available within the project.
> 
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.
> 
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> A Fedora package developer may use their Fedora Account in PackageDB to
> claim ownership of an orphaned package.
> 
> Removal of an orphaned package entails "blocking" it in the buildsystem
> so it does not appear in the rawhide repository, and files in CVS of the
> "devel" branch being replaced with an empty "dead.package" file.  At a
> later date if a Fedora package developer wishes to revive a dead package
> they may do so by claiming ownership in pkgdb then requesting the koji
> block to be removed.  It is however a bit easier if ownership is claimed
> prior to orphan removal, so please claim packages now if possible.
> 

Hmm,

I see openct, opencs and pcsc-tools listed, didn't we go through a lot 
of effort during FC-6 / F-7 to get smartcard support integrated, isn't 
this need to support certain cards / features then?

I'm planning to start working with smartcards sometime soon, and I think 
I will need these, but I'm not sure.

Regards,

Hans



From j.w.r.degoede at hhs.nl  Tue Nov 20 09:32:39 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 10:32:39 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <1195508396.25781.17.camel@home.behdad.org>
References: <1195250399.3177.2.camel@rousalka.dyndns.org>	
	<1195251486.24535.46.camel@home.behdad.org>
	<473E99F1.7090907@hhs.nl>
	<1195508396.25781.17.camel@home.behdad.org>
Message-ID: <4742A9B7.3040509@hhs.nl>

Behdad Esfahbod wrote:
> On Sat, 2007-11-17 at 08:36 +0100, Hans de Goede wrote:
>> Behdad Esfahbod wrote:
> [snip] 
>>> Fontconfig doesn't store cache files in the directory anymore.  They go
>>> in /var/cache/fontconfig.  That's been the case for a while.
>> Ah, then the packages also should no longer ghost fc-cache in the fonts dir.
> 
> No, they shouldn't.
> 

[hans at localhost ~]$ rpm -ql urw-fonts
urw-fonts-2.4-1.fc8.noarch
/etc/X11/fontpath.d/fonts-default
/usr/share/doc/urw-fonts-2.4
/usr/share/doc/urw-fonts-2.4/COPYING
/usr/share/doc/urw-fonts-2.4/README
/usr/share/doc/urw-fonts-2.4/README.tweaks
/usr/share/fonts/default
/usr/share/fonts/default/Type1
/usr/share/fonts/default/Type1/a010013l.afm
/usr/share/fonts/default/Type1/a010013l.pfb
/usr/share/fonts/default/Type1/a010015l.afm
<snip>
/usr/share/fonts/default/Type1/d050000l.pfb
/usr/share/fonts/default/Type1/encodings.dir
/usr/share/fonts/default/Type1/fonts.cache-1
/usr/share/fonts/default/Type1/fonts.dir
/usr/share/fonts/default/Type1/fonts.scale
/usr/share/fonts/default/Type1/n019003l.afm
/usr/share/fonts/default/Type1/n019003l.pfb
<snip>

Well atleast urw-fonts still does. I know bugzilla, but I would first
rather see some solution for the fonts.scale and fonts.dir files too,
before checking all font packages and filing bugs.

>>>> As for the other two not being created, well that is to be expected if the 
>>>> necessary packages are not added to any Requires.
>>>>
>>>> Why are these files generated on install anyways, I understand this used to be 
>>>> usefull back in the days when multiple packages would install files under one 
>>>> dir, but isn't it so that most font dirs now only contain fonts from one package?
>>> I don't understand.  When are you suggesting they should be generated? 
>> At package buildtime, and then simply include them in the package 
>> instead of %ghost them and generate them with scriptlets.
> 
> Interesting.  Never thought about it like that.  However, there are a
> few reason why that's not going to work:
> 
>   - fc-cache (and similar tools I assume) don't handle DESTDIR.  You
> sure can force them to do it, but it needs considerable effort on the
> packagers side.
> 
>   - fontconfig cache format/version changes over time.  Mostly in a
> compatible way, but still making old caches useless.  This happened with
> the recent 2.5 for example.
> 
>   - Kind of rewording of the previous item:  We're trying to make font
> packages not depend on fontconfig.  Would be kinda weird to install a
> fontconfig cache file without checking fontconfig version.
> 
> I don't think cache updates are hassle enough to try to fix them right
> now.
>

Sorry, the above are all very valid, but I didn't mean the fontconfig
files, I meant the fonts.scale and fonts.dir files.


> Obsolete core-protocol fonts are out of my expertise/interest so I leave
> that to others.
> 

Too bad, as that is the real problem, urw-fonts (for example) requires
fontconfig, so the scriptlets for updating the fontconfig cache should
work, however the scriptlets for generating fonts.dir and fonts.scale
needed by older apps (like xfig, which I co-maintain now and resolving
an xfig bug got me to investigate this) do not have the necessary
requires an therefor don't work, for example on the F8 i386 live CD
there only is a fonts.scale and not a fonts.dir for urw-fonts causing
xfig (and other) breakage.

Now I can go and file a bug against urw-fonts, but for example
ghostscript-fonts has exact the same problem. So I'm trying to find /
discuss a solution here on the list instead of filing bugs and having to
discuss this separately for every package.

So are there any reasons not to generate fonts.scale and fonts.dir (and
I guess also encodings.dir) at build time and include them in the font
package?

This assumes all font files in a dir come from one package, because this
clearly wont work if multiple packages install fonts into the same dir.
Are there any known cases of multiple font packages installing fonts
into the same dir in current Fedora?

Regards,

Hans



From mtasaka at ioa.s.u-tokyo.ac.jp  Tue Nov 20 09:43:55 2007
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Tue, 20 Nov 2007 18:43:55 +0900
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <4742A9B7.3040509@hhs.nl>
References: <1195250399.3177.2.camel@rousalka.dyndns.org>		<1195251486.24535.46.camel@home.behdad.org>	<473E99F1.7090907@hhs.nl>	<1195508396.25781.17.camel@home.behdad.org>
	<4742A9B7.3040509@hhs.nl>
Message-ID: <4742AC5B.6070001@ioa.s.u-tokyo.ac.jp>

Well, I have not read the whole thread of this, however:

Hans de Goede wrote, at 11/20/2007 06:32 PM +9:00:
> So are there any reasons not to generate fonts.scale and fonts.dir (and
> I guess also encodings.dir) at build time and include them in the font
> package?

I thought we are already doing this...

e.g. from:
http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/fonts-japanese/fonts-japanese.spec

-------------------------------------------------------------
# Create fonts.scale and fonts.dir
/usr/bin/mkfontdir $RPM_BUILD_ROOT%{bmpfontdir}
# for dummy
touch $RPM_BUILD_ROOT%{basefontdir}/fonts.cache-1
touch $RPM_BUILD_ROOT%{bmpfontdir}/fonts.cache-1
touch $RPM_BUILD_ROOT%{bmpfontdir}/encodings.dir
--------------------------------------------------------------

Regards,
Mamoru



From nphilipp at redhat.com  Tue Nov 20 09:47:16 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Tue, 20 Nov 2007 10:47:16 +0100
Subject: working with gnome project/other distros together on system
	tools (was: Re: System-config Reworking Proposal)
In-Reply-To: <1195493308.5442.88.camel@oneill.fubar.dk>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
	<4741984F.30006@leemhuis.info>
	<1195493308.5442.88.camel@oneill.fubar.dk>
Message-ID: <1195552036.29355.19.camel@wombat.tiptoe.de>


On Mon, 2007-11-19 at 12:28 -0500, David Zeuthen wrote:
> On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
> > Just wondering: Why don't we work towards getting some sane config tools
> > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> > interest)? Sure, that way other distros will benefit from out work as
> > well, but on the other hand having stuff as de-facto part of Gnome and
> > used by other distros afaics lead to better tools and a better user
> > experience, which overall leads to a better "Linux".
> 
> This is actually what we've been working on in the RH/Fedora desktop
> team for quite some time. The mantra here, as you point out, is both
> "upstream", proper separation of the user interface and the mechanism,
> access control and, ideally, integration with directory services such as
> the Fedora Directory Server.
> 
> Actually for home/consumer desktop use, there is not much need for any
> of the system-config-* tools any more; for example for F9, intlclock
> will replace system-config-date

... as the tool that is launched when you click on your (GNOME) panel
clock -> "Adjust Date & Time". I don't see s-c-date going away anytime
soon (as the maintainer I'm a bit biased), at least as long as the DE
specific tools are full replacements.

>  and S?ren's work on xrandr UI will
> probably be able to replace most of system-config-display. The former,
> at least, is getting merged into upstream GNOME as we speak. The latter,
> I believe, will be proposed for GNOME as well. S?ren?
> 
> As for server use... e.g. s-c-httpd and friends I'm not sure. I've
> always found it rather odd to use an UI for this in the first place but
> I do acknowledge that some of our users find this useful. It's
> definitely something that is on the check-list of many system
> administrators especially those from the Windows world.
> 
> In my opinion, the most important thing to fix with our remaining
> system-config-* tools is to get upstream buy-in (ideally merge it into
> GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
> mechanism and use things like PolicyKit for access control. Notably, Tim
> is doing a pretty good job here with s-c-printer; that's why Ubuntu got
> the best printing support on the planet :-) [1]

Well, the idea of "whatever upstream" is most appealing to me as that
can as well be us ;-). Mind that as configuration tools aren't only
interesting to desktop users we should be careful under which umbrella
(if one) we put them. I'm with you as far as UI <-> logic <-> privileged
ops separation is concerned.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nicolas.mailhot at laposte.net  Tue Nov 20 09:50:55 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 20 Nov 2007 10:50:55 +0100 (CET)
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with 
 F-8]
Message-ID: <63540.192.54.193.53.1195552255.squirrel@rousalka.dyndns.org>


Le Mar 20 novembre 2007 10:32, Hans de Goede a ?crit :

>> Obsolete core-protocol fonts are out of my expertise/interest so I
>> leave that to others.
>>
>
> Too bad, as that is the real problem,

Core fonts are basically under-maintained with few people willing to
invest the time to make them sort-of work. If you have an interest in
them you can drive this work on the fonts SIG list because otherwise
you may wait a long time for someone else to do it.

Or you can decide like a lot of people it's not worth it and upstreams
that refuse to change can find themselves other packagers.

Regards,

-- 
Nicolas Mailhot



From andy at smile.org.ua  Tue Nov 20 09:55:04 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Tue, 20 Nov 2007 11:55:04 +0200
Subject: UniConvertor: is it possible to include to Fedora?
In-Reply-To: <50024.192.54.193.53.1195550308.squirrel@rousalka.dyndns.org>
References: <50024.192.54.193.53.1195550308.squirrel@rousalka.dyndns.org>
Message-ID: <20071120095504.GC9545@serv.smile.org.ua>

Hi Nicolas Mailhot!

 On Tue, Nov 20, 2007 at 10:18:28AM +0100, Nicolas Mailhot wrote next:

> > I'd like to add UniConvertor[1] to the Fedora.
> > However I think the legal issues are may present.
> If you have any doubt on legal aspects, ask fedora-legal
> http://fedoraproject.org/wiki/Legal
Thanks. I forwarded message there.

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From j.w.r.degoede at hhs.nl  Tue Nov 20 10:23:47 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 11:23:47 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <4742AC5B.6070001@ioa.s.u-tokyo.ac.jp>
References: <1195250399.3177.2.camel@rousalka.dyndns.org>		<1195251486.24535.46.camel@home.behdad.org>	<473E99F1.7090907@hhs.nl>	<1195508396.25781.17.camel@home.behdad.org>	<4742A9B7.3040509@hhs.nl>
	<4742AC5B.6070001@ioa.s.u-tokyo.ac.jp>
Message-ID: <4742B5B3.3020708@hhs.nl>

Mamoru Tasaka wrote:
> Well, I have not read the whole thread of this, however:
> 
> Hans de Goede wrote, at 11/20/2007 06:32 PM +9:00:
>> So are there any reasons not to generate fonts.scale and fonts.dir (and
>> I guess also encodings.dir) at build time and include them in the font
>> package?
> 
> I thought we are already doing this...
> 
> e.g. from:
> http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/fonts-japanese/fonts-japanese.spec 
> 
> 
> -------------------------------------------------------------
> # Create fonts.scale and fonts.dir
> /usr/bin/mkfontdir $RPM_BUILD_ROOT%{bmpfontdir}
> # for dummy
> touch $RPM_BUILD_ROOT%{basefontdir}/fonts.cache-1
> touch $RPM_BUILD_ROOT%{bmpfontdir}/fonts.cache-1
> touch $RPM_BUILD_ROOT%{bmpfontdir}/encodings.dir
> --------------------------------------------------------------
> 

Ah, so some are, however some are not, for example urw-fonts and 
ghostscript-fonts are still generating fonts.dir and fonts.scale using 
scriptlets, and since they do not have the proper requires for these scriptlets 
this does not work, resulting in applications wanting to use urw-fonts through 
the core fonts system failing.

I would be happy to file bugs against this, but first I would like to see some 
guidelines about howto handle the core fonts files, as I see it there are 2 
options:
-generate fonts.dir and fonts.scale at buildtime (preferred)
-generate them using scriptlets, and then the package MUST have
  the necessary requires for these scripts

Regards,

Hans



From j.w.r.degoede at hhs.nl  Tue Nov 20 10:25:43 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 11:25:43 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <63540.192.54.193.53.1195552255.squirrel@rousalka.dyndns.org>
References: <63540.192.54.193.53.1195552255.squirrel@rousalka.dyndns.org>
Message-ID: <4742B627.3000003@hhs.nl>

Nicolas Mailhot wrote:
> Le Mar 20 novembre 2007 10:32, Hans de Goede a ?crit :
> 
>>> Obsolete core-protocol fonts are out of my expertise/interest so I
>>> leave that to others.
>>>
>> Too bad, as that is the real problem,
> 
> Core fonts are basically under-maintained with few people willing to
> invest the time to make them sort-of work. If you have an interest in
> them you can drive this work on the fonts SIG list because otherwise
> you may wait a long time for someone else to do it.
> 

Isn't the solution for this problem (missing fonts.dir / fonts.scale) as simple 
as adding a single guideline that font packages which add a symlink under 
/etc/X11/fontpath.d MUST ship a pre-generated fonts.dir and fonts.scale, and no 
try to generate these using scriptlets?

Regards,

Hans



From promac at gmail.com  Tue Nov 20 10:32:25 2007
From: promac at gmail.com (Paulo Cavalcanti)
Date: Tue, 20 Nov 2007 08:32:25 -0200
Subject: Pulseaudio problems
Message-ID: <68720af30711200232v233c5ff8g10e04fa2315c228a@mail.gmail.com>

> Hi,

>
> I am trying to adapt myself to pulseaudio (F8 x86_64).
>
> I had to change /etc/security/console.perms.d/50-default.perms
> so I can use another X screen (:1) without being root, and  without using
> pulse.

>> Hmm? I don't really understand what you edited in that file and what
>> you achieved with this?

This is how I send mplayer output to my TV:

/usr/bin/xinit /usr/bin/xterm -ut -e $HOME/bin/$PROG \
             $MOVIE -- /usr/bin/X :1 -layout TV &

With F8, I get not sound at all, unless I execute the above command as root.
Then I created an audio group for myself and added to
/etc/security/console.perms.d/50-default.perms:

# roma
<sound>=/dev/dsp* /dev/audio* /dev/midi* \
        /dev/mixer* /dev/sequencer* \
        /dev/sound/* /dev/beep \
        /dev/snd/* /dev/adsp*

.....

# roma
<console> 0660 <sound>       0660 root.audio

This allows me to get sound without being root (even logged in
remotely in a console).


>> BTW: It is a feature, not a bug that PA pauses playback when you
>> switch to a different session.

I know that, and a like it very much.

> audacious 1.4: OK with ESD (stutters a lot with its own pulse
> plugin).

>> Have you filed a bug to the audacious people on that? My PA plugin for
>> XMMS works fine. Apparently they broke it when they took it and ported
>> it to Audacious.

Yes. It works for xmms. I tried to contact the audacious team via IRC,
and they said: "roma, I really do not care"

I tried, yesterday, the latest version, 1.4.2, and got the same result.


> vlc: NO plugin available.

>> I'd assume that this one works fine with our plugin for ALSA.

Yes. But it also works fine with ESD.

>> Yes, I will have another look on the whole Xine situation.

xine and gxine do not work with pulse plugin (the connection is lost after a few
seconds), but totem does (it is based on xine, right?). What is the difference?

I use a self compiled version of xine and gxine with all of the codecs
enabled, and
I have no problem using them with the ESD plugin. Pulseaudio works
just fine this way.

> I also noticed that using
>
> arecord -D hw:0.0 -d 0 -f S16_LE -c2 -r48000 | aplay -D pulse &
>
> for capturing from line in.

>> Hmm? what did you notice?

There is a slight hiccup (missing of sound) from time to time.
It is very fast,and it does not seem to be related to the amount of
processing on my computer: Core 2 duo, 2.1GHz, 2GB ram, x86_64, F8

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/dc7dce76/attachment.htm>

From nicolas.mailhot at laposte.net  Tue Nov 20 10:55:05 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 20 Nov 2007 11:55:05 +0100 (CET)
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with 
 F-8]
Message-ID: <38743.192.54.193.53.1195556105.squirrel@rousalka.dyndns.org>


Le Mar 20 novembre 2007 11:25, Hans de Goede a ?crit :

> Isn't the solution for this problem (missing fonts.dir / fonts.scale)
> as simple
> as adding a single guideline that font packages which add a symlink
> under
> /etc/X11/fontpath.d MUST ship a pre-generated fonts.dir and
> fonts.scale, and no
> try to generate these using scriptlets?

IIRC pre-shipping these files caused other problems, but I doubt there
is enough core fonts expertise left to identify them easily (I vaguely
remember mkfontdir output was dependant on local hardware resolution
or xorg version). The people who knew core fonts innards dropped it
like radioactive material as soon as fontconfig was available.

Whatever solution you choose forcing installation of core fonts
backend by the main font package is a no-go for modern fonts (TTF/OTF,
maybe Type 1 too). You can split the core font scriptlet parts in a
subpackage, or ship pre-generated files, as long as you do not impact
the vast majority of users who have no need for core fonts.

-- 
Nicolas Mailhot



From mcepl at redhat.com  Tue Nov 20 11:29:25 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Tue, 20 Nov 2007 12:29:25 +0100
Subject: Bumping Anjuta version
References: <3170f42f0711191302j2e12e4f0qe4b73f2ca5ce2c62@mail.gmail.com>
Message-ID: <l1ta15xbs6.ln2@hubmaier.ceplovi.cz>

On Tue, 20 Nov 2007 02:32:07 +0530, Debarshi 'Rishi' Ray scripst:
> Can the anjuta-2.2.0 and anjuta-gdl-0.7.3 packages be bumped to their
> recent upstream versions? The latest upstream versions are 2.2.2 and
> 0.7.7 respectively.

Yes, and if you are in cvsextras group, then according to https://
admin.fedoraproject.org/pkgdb/packages/name/anjuta you can do it. :-)

Mat?j

-- 
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
The politician attempts to remedy the evil by increasing the very
thing that caused the evil in the first place: legal plunder.
    -- Frederick Bastiat



From michael.wiktowy at gmail.com  Tue Nov 20 11:36:33 2007
From: michael.wiktowy at gmail.com (Michael Wiktowy)
Date: Tue, 20 Nov 2007 06:36:33 -0500
Subject: Behaviour when ethernet MAC is 00:00:00:00:00:00 ?
In-Reply-To: <1195500816.11545.63.camel@jcmlaptop>
References: <3e4ec4600711190743w2f288e76o5138824ff951f654@mail.gmail.com>
	<e1760170711190752y7807a67aia0e41b628e768644@mail.gmail.com>
	<20071119165338.03dfd1a0@dhcp03.addix.net>
	<20071119155814.GA26453@jasmine.xos.nl>
	<1195500816.11545.63.camel@jcmlaptop>
Message-ID: <3e4ec4600711200336o760be097yfac55df1e8b9524d@mail.gmail.com>

On Nov 19, 2007 2:33 PM, Jon Masters <jcm at redhat.com> wrote:
> My suspicion is that the original mail was simply about updating the
> main system BIOS, not the additional flash chip, and that something is
> very wrong with the card - is it on board, or an adapter?

I updated the mainboard BIOS firmware. But the two NICs are integrated
on the mainboard so it is possible that they share some firmware
space. I don't see any other issues manifesting themselves on that
system though.

/Mike



From alan at redhat.com  Tue Nov 20 11:52:03 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 20 Nov 2007 06:52:03 -0500
Subject: Smolt database is broken
In-Reply-To: <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
Message-ID: <20071120115203.GA3361@devserv.devel.redhat.com>

On Mon, Nov 19, 2007 at 11:32:03PM -0500, Yaakov Nemoy wrote:
> That is in fact a possibility.  It uses the output from
> /proc/sys/kernel/random/uuid to work.  Is there a flaw with this
> method that we know nothing about?  Should we use another?

Well libuuid is the other alternative. I'm a bit concerned about reports
the kernel uuid generator isn't as random as it should be. I'd like to know
more - such as what uuids come up a lot and chase that further.

Alan



From jwboyer at gmail.com  Tue Nov 20 11:59:58 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 05:59:58 -0600
Subject: RFC: Package Review VCS
In-Reply-To: <474256DC.2030801@redhat.com>
References: <47420B80.9070001@redhat.com>
	<20071119204055.00c6b399@vader.jdub.homelinux.org>
	<474256DC.2030801@redhat.com>
Message-ID: <20071120055958.5d3cdcbd@vader.jdub.homelinux.org>

On Mon, 19 Nov 2007 22:39:08 -0500
Warren Togami <wtogami at redhat.com> wrote:

> Josh Boyer wrote:
> > 
> > The idea behind this is nice.  Using CVS to do it will suck.  
> 
> What about it exactly?
> Using CVS as a tool again when we should be using a more modern VCS?

Yes.  The fact that you manually have to copy the history, which isn't
all that important anyway, from one repo to another sucks and adds one
more barrier before the package is in.

> > Also, I'm not sure it buys you a ton over keeping track of changes in the
> > specfile during review, which should already be done anyway.
> > 
> > josh
> > 
> 
> While most spec changes during a review will be boring, it is sometimes 
> worthwhile to keep them in history.  A more interesting thing this 
> enables may be during pre-review, where it can act as a playpen/staging 
> ground for rapid packaging and testing.  Imagine this:
> 
> 1) Existing Fedora packager begins work on a new package.
> 2) cvs-import.sh in /cvs/pkgreview, existin Fedora packager can create 
> whatever they want, whenever they want.
> 3) They might ask other people to help in packaging.  *Real* quick 
> centralized place to point other people to ask for help.

Help how?  One of the reason for reviews is to see how responsive and
adaptive the packager is.  Others can make suggestions, but shouldn't
be making changes.  That should rest squarely on the packagers
shoulders alone.

> 4) *Real* quick build testing on all archs directly from your 
> work-in-progress.
> 
> I call that enabling.
> 
> I suppose we could make using /cvs/pkgreview optional for package 
> reviews.  And Merge Review could use /cvs/pkgs instead.  But I can't 
> imagine why anybody would prefer the hassle of spinning new .src.rpm's 
> and uploading them to a web accessible URL several times instead of 
> simply using a VCS.

I don't particularly care about whether it exists or not.  I just think
that:

1) Changes during review should be reflected in the spec file, and
2) That history isn't all that important and doesn't need to be
manually copied in repo files to the official package VCS.

josh



From galibert at pobox.com  Tue Nov 20 12:02:48 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 13:02:48 +0100
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <1195143796.3140.110.camel@cookie.hadess.net>
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
Message-ID: <20071120120248.GA4596@dspnet.fr.eu.org>

On Thu, Nov 15, 2007 at 04:23:16PM +0000, Bastien Nocera wrote:
> 
> On Thu, 2007-11-15 at 17:01 +0100, Olivier Galibert wrote:
> > Bug #134886 is still there since fedora core 3 times.  It means that
> > NetworkManager will happily shutdown the interfaces, ignore any
> > settings you've put in anaconda and wipe out /etc/resolv.conf if you
> > happen not to use dhcp.  Like in a lab, where desktops and servers
> > tend not to wander around so much and dhcp is used only for laptops.
> 
> Just disable NetworkManager in your kickstart file.

You may be interested to know that you can not use a non-predefined
static ip address if you use kickstart.  Loader2 has dhcp mandatory is
you use a kickstart file with no ip address given in it.

net.c:781:
    /* If the user provided any of the following boot paramters, skip
     * prompting for network configuration information:
     *     ip=<val> ipv6=<val>
     *     noipv4 noipv6
     *     ip=<val> noipv6
     *     ipv6=<val> noipv4
     * we also skip this form for anyone doing a kickstart install
     */

"This form" is the one to select between dhcp and manual.

Why the hate?

  OG.



From j.w.r.degoede at hhs.nl  Tue Nov 20 12:11:12 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 13:11:12 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <38743.192.54.193.53.1195556105.squirrel@rousalka.dyndns.org>
References: <38743.192.54.193.53.1195556105.squirrel@rousalka.dyndns.org>
Message-ID: <4742CEE0.7020703@hhs.nl>

Nicolas Mailhot wrote:
> Le Mar 20 novembre 2007 11:25, Hans de Goede a ?crit :
> 
>> Isn't the solution for this problem (missing fonts.dir / fonts.scale)
>> as simple
>> as adding a single guideline that font packages which add a symlink
>> under
>> /etc/X11/fontpath.d MUST ship a pre-generated fonts.dir and
>> fonts.scale, and no
>> try to generate these using scriptlets?
> 
> IIRC pre-shipping these files caused other problems, but I doubt there
> is enough core fonts expertise left to identify them easily (I vaguely
> remember mkfontdir output was dependant on local hardware resolution
> or xorg version). The people who knew core fonts innards dropped it
> like radioactive material as soon as fontconfig was available.
> 
> Whatever solution you choose forcing installation of core fonts
> backend by the main font package is a no-go for modern fonts (TTF/OTF,
> maybe Type 1 too).

What do you mean with the "core fonts backend"?

> You can split the core font scriptlet parts in a
> subpackage, or ship pre-generated files, as long as you do not impact
> the vast majority of users who have no need for core fonts.
> 

Yes, assuming that with the "core fonts backend" you mean mkfontdir & friends, 
then I agree, having a dependency on these is not a good plan, so I see 2 options:
1) Use pregenerated files (I just checked there contents and I see nothing
    different from how they looked in the XFree86 3.x days, so I do not believe
    these are xorg version / arch / dpi dependent). This is the prefered option.
2) The gtk-update-icon-cache way, so conditionally run mkfontdir and friends
    from scripts, if installed. And on installation of mkfontdir, run it for all
    dirs under /etc/X11/fontpath.d

I believe 1 si greatly preferred if we all agree on this I'll try to write 
something for the guidelines about this.

Regards,

Hans



From christoph.wickert at nurfuerspam.de  Tue Nov 20 12:12:17 2007
From: christoph.wickert at nurfuerspam.de (Christoph Wickert)
Date: Tue, 20 Nov 2007 13:12:17 +0100
Subject: Broken dependencies: xfce4-sensors-plugin
In-Reply-To: <200711200954.lAK9sEGt001694@releng1.fedora.phx.redhat.com>
References: <200711200954.lAK9sEGt001694@releng1.fedora.phx.redhat.com>
Message-ID: <1195560737.3525.23.camel@wicktop.localdomain>

Am Dienstag, den 20.11.2007, 02:54 -0700 schrieb
buildsys at fedoraproject.org:
> 
> xfce4-sensors-plugin has broken dependencies in the development tree:
> On ppc:
> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3
> On x86_64:
> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)
> On i386:
> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3
> On ppc64:
> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)
> Please resolve this as soon as possible.

This is because development has switched to lm_sensors 3.0.0 RC1. I
tried to rebuild the package but it won't build with the new lm_sensors
API. I informed upstream about it and they told me

> I guess, I'll ignore their changes for a few months. API breaking in
> libs is always ugly (although it is a very ugly API). And I am not
> willing to introduce #ifdefs for them.

What am I supposed to do in a case like this? Can we temporarily remove
the package from the development repo?

Christoph




From buildsys at redhat.com  Tue Nov 20 12:29:01 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 20 Nov 2007 07:29:01 -0500
Subject: rawhide report: 20071120 changes
Message-ID: <200711201229.lAKCT17T010396@porkchop.devel.redhat.com>

New package AcetoneISO
	CD/DVD Image Manipulator

New package emacs-common-ess
	Emacs Speaks Statistics add-on package for Emacs

New package ggz-client-libs
	Client libraries for GGZ gaming zone

New package ikarus
	An incremental optimizing compiler for R6RS Scheme

New package kdebase-runtime
	K Desktop Environment - Runtime

New package libmowgli
	An algorithm framework

New package ruby-marc
	Ruby library for MARC catalog

New package rubygem-zoom
	Ruby binding to ZOOM

New package sysusage
	System monitoring based on perl, rrdtool, and sysstat


 
Updated Packages:

NetworkManager-1:0.7.0-0.6.5.svn3096.fc9
----------------------------------------
* Mon Nov 19 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.5.svn3096
- Fix crash and potential infinite nag dialog loop when ignoring CA certificates

* Mon Nov 19 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.4.svn3096
- Fix crash when ignoring CA certificate for EAP-TLS, EAP-TTLS, and EAP-PEAP

* Mon Nov 19 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.3.svn3096
- Fix connections when picking a WPA Enterprise AP from the menu
- Fix issue where applet would provide multiple same connections to NM

alexandria-0.6.2-0.2.b2.fc9
---------------------------
* Tue Nov 13 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.6.2-0.2.b2
- Add more requires of ruby modules to support more function

apt-0.5.15lorg3.93-4.fc9
------------------------
* Mon Nov 19 2007 Panu Matilainen <pmatilai at redhat.com> 0.5.15lorg3.93-4
- Fix assert failure when repomd.xml isn't available locally (#389361)

bind-32:9.5.0-18.a7.fc9
-----------------------
* Mon Nov 19 2007 Adam Tkac <atkac redhat com> 32:9.5.0-18.a7
- removed statement from initscript which passes -D to named

dnssec-tools-1.3-4.fc9
----------------------
* Mon Nov 19 2007 Wes Hardaker <wjhns174 at hardakers.net> - 1.3-4
- Bogus release bump to fix fedora tag issue

* Mon Nov 19 2007 Wes Hardaker <wjhns174 at hardakers.net> - 1.3-3
- dnsval.conf syntax fix

* Mon Nov 19 2007 Wes Hardaker <wjhns174 at hardakers.net> - 1.3-2
- New dnssec-tools.org dnskey

emacs-22.1.50-1.fc9
-------------------
* Mon Nov 19 2007 Chip Coldwell <coldwell at redhat.com> 22.1.50-1
- pulled sources from GNU CVS

* Mon Nov 19 2007 Chip Coldwell <coldwell at redhat.com> 22.1-9
- fixup alternatives mess (bz239745, bz246540)

* Tue Nov 06 2007 Chip Coldwell <coldwell at redhat.com> 22.1-8
- fix insufficient safe-mode checks (Resolves: bz367601)

epiphany-2.20.1-5.fc9
---------------------
* Mon Nov 19 2007 Martin Stransky <stransky at redhat.com> - 2.20.1-5
- Updated wrapper patch

* Sat Nov 10 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-4
- Rebuild against newer gecko

* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-3
- Rebuild against new dbus-glib

firstboot-1.90-1.fc9
--------------------

freenx-0.7.1-2.fc9
------------------
* Mon Nov 19 2007 Jon Ciesla <limb at jcomserv.net> - 0.7.1-2
- Added logrotate, BZ 379761.

* Mon Nov 19 2007 Jon Ciesla <limb at jcomserv.net> - 0.7.1-1
- Update to 0.7.1, many bugfixes, BZ 364751, 373771.

* Sun Sep 23 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.7.0-2
- Do not try to set up KDE_PRINTRC if ENABLE_KDE_CUPS is not 1, deal better
  with errors when it is (#290351).

galeon-2.0.3-15.fc9
-------------------
* Mon Nov 19 2007 Martin Stransky <stransky at redhat.com> - 2.0.3-15
- Added support for wrapped plugins

gd-2.0.35-3.fc9
---------------
* Mon Nov 19 2007 Ivana Varekova <varekova at redhat.com> 2.0.35-3
- spec file cleanup

* Mon Nov 19 2007 Ivana Varekova <varekova at redhat.com> 2.0.35-2
- fix gdlib.pc file

* Tue Sep 18 2007 Ivana Varekova <varekova at redhat.com> 2.0.35-1
- update to 2.0.35

gdesklets-calendar-0.51-2.fc9
-----------------------------
* Mon Nov 19 2007 Tyler Owen <tyler.l.owen at gmail.com> - 0.51-2
- Bumping a rev to fix cvs tagging for devel
gdm-1:2.21.2-0.2007.11.19.2.fc9
-------------------------------
* Mon Nov 19 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.19.2
- move homedir to /var/lib/gdm

* Mon Nov 19 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.19.1
- Update to today's snapshot

* Thu Nov 15 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.14.2
- don't source /etc/profile at startup

glom-1.6.4-1.fc9
----------------
* Mon Nov 19 2007 Denis Leroy <denis at poolshark.org> - 1.6.4-1
- Update to upstream 1.6.4, many bug fixes

gmediaserver-0.13.0-2.fc9
-------------------------
* Mon Nov 19 2007 Karol Trzcionka <karlikt at gmail.com> - 0.13.0-2
- Rebuild with new libupnp (v1.6.1)

gscan2pdf-0.9.19-1.fc9
----------------------
* Mon Nov 19 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.19-1
- v 0.9.19

initng-0.6.10.2-1.fc9
---------------------
* Mon Nov 19 2007 Daniel Malmgren <dm at mensa.se> 0.6.10.2-1
- New upstreams version
- Raised initng-ifiles requirement. Not quite sure we work with 0.1.2 any longer

* Sat Oct 27 2007 Rudolf Kastl <che666 at gmail.com> 0.6.10.1-3
- Add selinux patch so initng also boots when it is disabled (thanks to Dragoran)

* Wed Aug 15 2007 Daniel Malmgren <dm at mensa.se> 0.6.10.1-2
- Added patch to fix compilation with glibc >= 2.6.90 (thanks to Dragoran)

jd-1.9.7-0.4.svn1535.fc9
------------------------
* Mon Nov 19 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.svn1535
- svn 1535

* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

kde-filesystem-4-1.fc9
----------------------
* Mon Nov 19 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4-1
- Version: 4
- %cmake_kde4: add -DCMAKE_SKIP_RPATH:BOOL=ON
- Requires: redhat-rpm-config (for proper rpm macro defs)
  (hmm... may need a new -devel pkg somewhere)

kdebase4-3.96.0-4.fc9
---------------------
* Mon Nov 19 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.96.0-4
- don't list libkdeinit4_*.so, we remove all of them as conflicts

* Mon Nov 19 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.96.0-3
- remove new directory/files %{_kde4_datadir}/templates (conflict with KDE 3)

* Mon Nov 19 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 3.96.0-2
- (re)add %{_kde4_iconsdir}/oxygen/*/*/* to file list

kernel-2.6.24-0.39.rc3.git1.fc9
-------------------------------
* Sun Nov 18 2007 Kyle McMartin <kmcmartin at redhat.com>
- 2.6.24-rc3-git1

kile-2.0-1.fc9
--------------
* Mon Nov 19 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 2.0-1
- kile-2.0

libetpan-0.52-2.fc9
-------------------
* Mon Nov 19 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.52-2
- bump

* Wed Aug 22 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.52-1
- version upgrade

mash-0.2.10-1.fc9
-----------------
* Mon Nov 19 2007 Bill Nottingham <notting at redhat.com> 0.2.10-1
- handle non Packages/ repositories better (#350391)

mcs-0.6.0-3.fc9
---------------
* Mon Nov 19 2007 Ralf Ertzinger <ralf at skytale.net> 0.6.0-3
- Fix incorrect SONAME for library
- Add libmowgli build requires
mock-0.8.8-1.fc9
----------------
* Mon Nov 19 2007 Michael Brown <mebrown at michaels-house.net> - 0.8.8-1
- make it run correctly when called by the 'root' user
- internal_setarch: optionally run 'setarch' internally. This
  eliminates the need to run "setarch i386 mock ..." when building on
  target_arch != build_arch. This is turned on by default. Limitations:
  must have 'ctypes' python module available, which is only available
  by default in python 2.5, or as an extension module in <= 2.4.
  If the 'ctypes' module is not available, this feature will be
  disabled and you must manually run 'setarch'.
- Does not run 'clean' action for 'shell', 'chroot', 'install', or
  'installdeps' (docs updated)
- fix build for top_builddir != top_srcdir
- fix 'installdeps' so that it works with both rpms/srpms
- missing device file /dev/ptmx was causing 'expect' command to always
  fail. Affected any SRPM build that used 'expect'.
- hard spec file dep on python >= 2.4 due to python syntax changes.
- resultdir can now contain python-string substitutions for any
  variable in the chroot config.
- add 'dist' variable to all chroot config files so that it is
  available for resultdir substitutions.
- give good error message when logging.ini cannot be found.
- change default logging format to remove verbosity from build.log.
- make logging format configurable from defaults.cfg or chroot cfg.
- less verbose state.log format

namazu-2.0.17-3.fc9
-------------------
* Tue Nov 20 2007 Akira TAGOH <tagoh at redhat.com> - 2.0.17-3
- Get rid of -L at libdir@ from nmz-config because it's a standard library
  directory. (#342641)

* Mon Nov 19 2007 Akira TAGOH <tagoh at redhat.com>
- Clean up spec file. (#383521)
- Separate the shared library to namazu-libs package.

* Thu Aug 23 2007 Akira TAGOH <tagoh at redhat.com> - 2.0.17-2
- Rebuild

nautilus-sendto-0.12-5.fc9
--------------------------
* Mon Nov 19 2007 Matthias Clasen <mclasen at redhat.com> - 0.12-5
- Fix the pidgin plugin to work with libpurple (#389121)

net-snmp-1:5.4.1-6.fc9
----------------------
* Wed Nov 14 2007 Jan Safranek <jsafranek at redhat.com> 5.4.1-6
- add support of lm_sensors v3
- added procps to build dependencies (#380321)
- removed beecrypt from dependencies
- fixed crash on reading xen interfaces (#386611)

perl-Algorithm-Dependency-1.104-1.fc9
-------------------------------------
* Tue Nov 20 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.104-1
- Upstream update.

perl-Carp-Clan-5.9-4.fc9
------------------------
* Mon Nov 19 2007 Robin Norwood <rnorwood at redhat.com> - 5.9-4
- Add BR: perl-Object-Deadly now that it is included in Fedora

perl-Class-Autouse-1.29-1.fc9
-----------------------------
* Tue Nov 20 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.29-1
- Upstream update.

perl-Class-Inspector-1.18-1.fc9
-------------------------------
* Tue Nov 20 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.18-1
- Upstream update.

perl-File-Remove-0.39-1.fc9
---------------------------
* Tue Nov 20 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.39-1
- Upstream update.

perl-Inline-0.44-18.fc9
-----------------------
* Mon Nov 19 2007 Robin Norwood <rnorwood at redhat.com> - 0.44-18
- Add BR: perl(Inline::Files)
perl-Params-Util-0.31-1.fc9
---------------------------
* Mon Nov 19 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.31-1
- Upstream update.

perl-Tree-Simple-1.18-1.fc9
---------------------------
* Mon Nov 19 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.18-1
- Upstream bugfix.
pirut-1.3.26-1.fc9
------------------
* Mon Nov 19 2007 Jeremy Katz <katzj at redhat.com> - 1.3.26-1
- Translation updates
- Don't traceback on doubleclick (Christian Anthon, #336791)
- Update metadata fixes (lmacken)
- Fix error case when you cancel quitting (#359201)
- Have puplet notify of reboots in the "updates applied" case (Ray Strode)
- Fix a media-related traceback (#373101)
- More aggressive exception handling (#379981, #357811)
- A few cleanups in the repo editor (#388051, #374171)
- Fix traceback with single package installer and some plugins (#375221)
- Fix weird search related crash (#389801, #388631)

* Wed Oct 17 2007 Jeremy Katz <katzj at redhat.com> - 1.3.25-1
- Fix handling of bad repo edits so that you're not stuck (#334501)
- Take into account updated urls with repo editor
- system-install-packages only needs repos to be available if we have
  to depsolve

* Thu Oct 11 2007 Jeremy Katz <katzj at redhat.com> - 1.3.24-1
- Improve handling of login before NM brings the network up
- Don't escape all characters in descriptions (#325891)
- Don't traceback if hal isn't running (#325901)
- Translation updates

plplot-5.8.0-1.fc9
------------------
* Mon Nov 19 2007 - Orion Poplawski <orion at cora.nwra.com> - 5.8.0-1
- Update to 5.8.0

policycoreutils-2.0.31-20.fc9
-----------------------------
* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-20
- Don't show error on missing policy.xml

* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-19
- GUI Enhancements
  - Fix cgi generation
  - Use more patterns

* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-18
- Remove codec hacking, which seems to be fixed in python

pyparted-1.8.9-3.fc9
--------------------
* Mon Nov 19 2007 Jeremy Katz <katzj at redhat.com> - 1.8.9-3
- Add support for exact constraints

python-exif-1.0.5-1.fc9
-----------------------
* Mon Nov 19 2007 Terje Rosten <terjeros at phys.ntnu.no> - 1.0.5-1
- 1.0.5
python-iniparse-0.2.2-2.fc9
---------------------------
* Mon Nov 19 2007 Tim Lauridsen <timlau at fedoraproject.org> - 0.2.2-2
- Added upstream patch to fix problems with empty ini files.

rsyslog-1.19.10-1.fc9
---------------------
* Mon Nov 19 2007 Peter Vrabec <pvrabec at redhat.com> 1.19.10-1
- new upstream release

superiotool-0-0.7.20071118svn2975.fc9
-------------------------------------
* Mon Nov 19 2007 Peter Lemenkov <lemenkov at gmail.com> 0.7.20071118svn2975
- Fixed man-page installation

sysreport-1.4.4-1
-----------------
* Mon Nov 19 2007 Than Ngo <than at redhat.com> - 1.4.4-1
- Resolves: bz220509, don't load iptables modules arbitrarily
- Resolves: bz141325, use lvmdump to gather lvm2 information

* Sat Jul 07 2007 Than Ngo <than at redhat.com> - 1.4.3-13.el5
- Resolves: bz#218524, sysctl is using deprecated syscall net.ipv6.neigh.lo.base_reachable_time

* Wed Mar 28 2007 Than Ngo <than at redhat.com> - 1.4.3-12.el5
- Resolves: #223744, sysreport preserve file attributes
- Resolves: #232920, doesn't touch sysrq-trigger by default
- Resolves: #239380, sysreport does not include /etc/lvm

tog-pegasus-2:2.7.0-1.fc9
-------------------------
* Mon Nov 19 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 2.7.0-1
- Update to upstream version 2.7.0
- Unhide some cmpi classes, package cmpi C++ headers
- Fix multiarch conflicts
  Resolves: #343311
- Add libcmpiCppImpl.so (symlink to libcmpiCppImpl.so.1)
  Resolves: #366871

warzone2100-2.0.8-0.1.rc1.fc9
-----------------------------
* Mon Nov 19 2007 Karol Trzcionka <karlikt at gmail.com> - 2.0.8-0.1.rc1
- Update to v2.0.8_rc1

xorg-x11-fonts-7.2-4.fc9
------------------------
* Mon Nov 19 2007 Kristian H??gsberg <krh at redhat.com> - 7.2-4
- Quote percentage signs in symlinking bash-magic (#390171).

xulrunner-1.9-0.alpha9.6.fc9
----------------------------
* Mon Nov 19 2007 Martin Stransky <stransky at redhat.com> 1.9-0.alpha9.6
- packed all gecko libraries (#389391)

yumex-2.0.3-2.fc9
-----------------
* Mon Nov 19 2007 Tim Lauridsen <tla at rasmil.dk> - 2.0.3-2
- fixed missing '\\n' in fr.po

* Mon Nov 19 2007 Tim Lauridsen <tla at rasmil.dk> - 2.0.3-1
- Release 2.0.3

Broken deps for i386
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	namazu - 2.0.17-3.fc9.i386 requires perl(time.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(util.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(var.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(document.pl)
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3



Broken deps for x86_64
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	namazu - 2.0.17-3.fc9.x86_64 requires perl(time.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(util.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(var.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(document.pl)
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo
	namazu - 2.0.17-3.fc9.ppc requires perl(time.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(util.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(var.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(document.pl)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3



Broken deps for ppc64
----------------------------------------------------------
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	namazu - 2.0.17-3.fc9.ppc64 requires perl(time.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(util.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(var.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(document.pl)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)





From jonathan.underwood at gmail.com  Tue Nov 20 12:33:20 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Tue, 20 Nov 2007 12:33:20 +0000
Subject: NetworkManager - Why Doesn't nm-applet have a way of using
	WPA-PSK?
In-Reply-To: <47428C23.6030507@gmail.com>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
Message-ID: <645d17210711200433t474e9400ue290b5be2a4428f5@mail.gmail.com>

On 20/11/2007, Kelly Miller <lightsolphoenix at gmail.com> wrote:
> Andrew Farris wrote:
> > Was your access point configured to only allow this option?  Sounds like the OP
> > is wanting to FORCE the use of WPA-PSK (i.e. access point will allow it), not
> > just have NM make the choice automatically.  The access point may be setup to
> > allow several security options.
> >
> Yes, I have to force it, because up until today the system was using
> WEP.  However, I found out through experimentation that my wireless
> network was acting horribly flaky, and I managed to track it to the WEP
> key itself (when I removed the security, everything worked fine).  So I
> switched the access point to use WPA-PSK, as a better option than
> leaving it wide open.  But NetworkManager was still insisting it used
> WEP, so I was trying to force it to switch.  nm-applet allows manually
> selecting WEP and a few other options, but not WPA-PSK with a specific
> encryption cipher.

I did exactly what you did too - i.e. switched an AP from WEP to
WPA-PSK. Because NM had previously associated with the AP with WEP, it
considers the AP with WPA-PSK as a different AP, and so there is a
second entry in the list of wireless networks corresponding to the
same AP. I guess there is no logic in NM currently to cope with an AP
changing security settings.



From caillon at redhat.com  Tue Nov 20 12:49:15 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 13:49:15 +0100
Subject: semi-automatic firefox rebuilds
In-Reply-To: <47429324.3070308@leemhuis.info>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>	<20071119095558.GC2584@free.fr>	<4741B869.9040508@leemhuis.info>	<20071119114942.697bc4b0@redhat.com>	<4741CD4C.1080601@leemhuis.info>	<20071119130215.220c71e5@redhat.com>
	<47429324.3070308@leemhuis.info>
Message-ID: <4742D7CB.6050605@redhat.com>

On 11/20/2007 08:56 AM, Thorsten Leemhuis wrote:

> BTW, does xulrunner properly and for real solve the problem? The current
> rawhide package just as firefox has a path with a version number in it
> (/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
> packages taht depend on a particular xulrunner version. Or is there some
> abstraction somewhere to make sure packages don't depend on a particular
> version of xulrunner?

Don't expect what's in rawhide right now to be what's in F9.  We're 
still working hard on getting things done right.  This is on the list. 
Even so, until the final release is made, xulrunner is still in a 
pre-release stage and ABI is not yet guaranteed.



From nicolas.mailhot at laposte.net  Tue Nov 20 12:51:30 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 20 Nov 2007 13:51:30 +0100 (CET)
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with 
 F-8]
Message-ID: <50080.192.54.193.53.1195563090.squirrel@rousalka.dyndns.org>


Le Mar 20 novembre 2007 13:11, Hans de Goede a ?crit :
> Nicolas Mailhot wrote:

>> Whatever solution you choose forcing installation of core fonts
>> backend by the main font package is a no-go for modern fonts
>> (TTF/OTF,
>> maybe Type 1 too).
>
> What do you mean with the "core fonts backend"?

Fonts accessed through the original X core protocol. Official
X11/XFree86/Xorg name of what you are writing about.

(http://keithp.com/~keithp/talks/xtc2001/paper/)

>> You can split the core font scriptlet parts in a
>> subpackage, or ship pre-generated files, as long as you do not
>> impact
>> the vast majority of users who have no need for core fonts.
>>
>
> Yes, assuming that with the "core fonts backend" you mean mkfontdir &
> friends,
> then I agree, having a dependency on these is not a good plan, so I
> see 2 options:
> 1) Use pregenerated files (I just checked there contents and I see
> nothing
>     different from how they looked in the XFree86 3.x days, so I do
> not believe
>     these are xorg version / arch / dpi dependent). This is the
> prefered option.

This was changed to scriptlets in the time we still had people caring
about core fonts so I wouldn't assume there were no technical reason
for the change. But I actively don't care whether core fonts work or
not so if you believe this will work and are ready to shoulder the
resulting QA you're free to go this way.

> 2) The gtk-update-icon-cache way, so conditionally run mkfontdir and
> friends
>     from scripts, if installed. And on installation of mkfontdir, run
> it for all
>     dirs under /etc/X11/fontpath.d
>
> I believe 1 si greatly preferred

We chose 2 for fontconfig, but if you do the work you call the shots,
as long as you conform to
http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy

Regards,

-- 
Nicolas Mailhot



From jkeating at redhat.com  Tue Nov 20 12:52:02 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 07:52:02 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <47421500.2040807@redhat.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com>
Message-ID: <20071120075202.78de1855@redhat.com>

On Mon, 19 Nov 2007 17:58:08 -0500
Warren Togami <wtogami at redhat.com> wrote:

> Risk Mitigating Factor:
> New contributors have no CVS commit access to /cvs/pkgreview at all 
> until a reviewer gives them access.  The reviewer should know better 
> than to allow something with legal problems into the CVS repo or to 
> grant someone access to upload such code.  So in practice, this
> removal plan is likely to be needed rarely if ever.

If it's only for existing contributors, why can't they just use their
fedorapeople space with git or hg or whatever?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/bf199831/attachment.sig>

From fedora at leemhuis.info  Tue Nov 20 12:58:33 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 20 Nov 2007 13:58:33 +0100
Subject: semi-automatic firefox rebuilds
In-Reply-To: <4742D7CB.6050605@redhat.com>
References: <1195226677.3238.45.camel@localhost.localdomain>	<1195227221.3002.9.camel@localhost.localdomain>	<1195227371.3238.47.camel@localhost.localdomain>	<473DEA5F.30201@leemhuis.info>	<1195247727.29478.6.camel@space-ghost.verbum.private>	<474047F4.5000508@leemhuis.info>	<20071118094506.5216b37d@redhat.com>	<1195418585.26830.18.camel@rousalka.dyndns.org>	<20071118185514.6cfa560a@redhat.com>	<47412586.4020502@leemhuis.info>	<20071119095558.GC2584@free.fr>	<4741B869.9040508@leemhuis.info>	<20071119114942.697bc4b0@redhat.com>	<4741CD4C.1080601@leemhuis.info>	<20071119130215.220c71e5@redhat.com>	<47429324.3070308@leemhuis.info>
	<4742D7CB.6050605@redhat.com>
Message-ID: <4742D9F9.1060802@leemhuis.info>



On 20.11.2007 13:49, Christopher Aillon wrote:
> On 11/20/2007 08:56 AM, Thorsten Leemhuis wrote:
> 
>> BTW, does xulrunner properly and for real solve the problem? The current
>> rawhide package just as firefox has a path with a version number in it
>> (/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
>> packages taht depend on a particular xulrunner version. Or is there some
>> abstraction somewhere to make sure packages don't depend on a particular
>> version of xulrunner?
> Don't expect what's in rawhide right now to be what's in F9.  We're 
> still working hard on getting things done right.  This is on the list. 
> Even so, until the final release is made, xulrunner is still in a 
> pre-release stage and ABI is not yet guaranteed.

k, thx for the clarification, as it looked a bit odd in its current state.

CU
knurd



From jkeating at redhat.com  Tue Nov 20 12:57:59 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 07:57:59 -0500
Subject: When will be CVS replaced by modern version control system?
In-Reply-To: <47426CBD.1090800@codewiz.org>
References: <23385.192.54.193.53.1194598924.squirrel@rousalka.dyndns.org>
	<20071109095230.GB2871@petra.dvoda.cz>
	<20071109112208.GA12660@xi.wantstofly.org>
	<4741C5E2.4090609@codewiz.org> <20071119124532.0731f106@redhat.com>
	<47426CBD.1090800@codewiz.org>
Message-ID: <20071120075759.56ebb31f@redhat.com>

On Tue, 20 Nov 2007 00:12:29 -0500
Bernardo Innocenti <bernie at codewiz.org> wrote:

> Indeed, I like it very much!  It's maybe not as versatile
> as what I had in mind, but it has a higher features/complexity
> ratio.  Is anyone working on implementing it?

Not actively.  It's something I'd like to see done, but I haven't the
time immediately to work on it.  I have to get the signing server done
first :/

> 
> To make this development model feasable, I think we should also
> speedup uploading srpms to koji, which is needed for scratch
> builds.  Uploading the kernel srpm takes around 20-30 minutes.

That's unfortunately a function of bandwidth.  However we could at some
point have a shell server near the buildsystem that could be used to
generate the kernel src.rpm and upload it over local bandwidth.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/2b84fec0/attachment.sig>

From j.w.r.degoede at hhs.nl  Tue Nov 20 13:03:19 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 14:03:19 +0100
Subject: Broken dependencies: xfce4-sensors-plugin
In-Reply-To: <1195560737.3525.23.camel@wicktop.localdomain>
References: <200711200954.lAK9sEGt001694@releng1.fedora.phx.redhat.com>
	<1195560737.3525.23.camel@wicktop.localdomain>
Message-ID: <4742DB17.20404@hhs.nl>

Christoph Wickert wrote:
> Am Dienstag, den 20.11.2007, 02:54 -0700 schrieb
> buildsys at fedoraproject.org:
>> xfce4-sensors-plugin has broken dependencies in the development tree:
>> On ppc:
>> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3
>> On x86_64:
>> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)
>> On i386:
>> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3
>> On ppc64:
>> 	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)
>> Please resolve this as soon as possible.
> 
> This is because development has switched to lm_sensors 3.0.0 RC1.

As announced more then once.

> I tried to rebuild the package but it won't build with the new lm_sensors
> API.

Correct, as was explained in the announcement

> I informed upstream about it and they told me
> 
>> I guess, I'll ignore their changes for a few months. API breaking in
>> libs is always ugly (although it is a very ugly API). And I am not
>> willing to introduce #ifdefs for them.
> 

Indeed the original API was ugly, and worse broken in several aspects, hence 
the API change, however the lm_sensors-2.10.x series will be maintained for 
atleast a few more months for less fast moving distro's and for kernel-2.4 
users. So upstream eventually will have to move to using ifdef's as both API's 
will coexist for quite a large period of time.

 > What am I supposed to do in a case like this? Can we temporarily remove
 > the package from the development repo?
 >

As stated in the announcement I'm more then willing to help write a patch for 
this, I've already patched several other apps and it isn't that hard. I'll make 
the patch suitable for upstream (IOW use the proper ifdef's so the old code 
keeps working, and upstream's coding style) then its up to you to send it upstream.

I'm rather busy atm though, so I'll put this on my todo list but it may take a 
week or more.

Regards,

Hans



From jwboyer at gmail.com  Tue Nov 20 13:04:54 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 07:04:54 -0600
Subject: RFC: Package Review VCS
In-Reply-To: <20071120075202.78de1855@redhat.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com> <20071120075202.78de1855@redhat.com>
Message-ID: <20071120070454.7263353b@weaponx>

On Tue, 20 Nov 2007 07:52:02 -0500
Jesse Keating <jkeating at redhat.com> wrote:

> On Mon, 19 Nov 2007 17:58:08 -0500
> Warren Togami <wtogami at redhat.com> wrote:
> 
> > Risk Mitigating Factor:
> > New contributors have no CVS commit access to /cvs/pkgreview at all 
> > until a reviewer gives them access.  The reviewer should know better 
> > than to allow something with legal problems into the CVS repo or to 
> > grant someone access to upload such code.  So in practice, this
> > removal plan is likely to be needed rarely if ever.
> 
> If it's only for existing contributors, why can't they just use their
> fedorapeople space with git or hg or whatever?

+1.

btw, do we have instructions somewhere for setting up git/hg repos on
fedorapeople?

josh



From jkeating at redhat.com  Tue Nov 20 13:15:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 08:15:41 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <20071120070454.7263353b@weaponx>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com> <20071120075202.78de1855@redhat.com>
	<20071120070454.7263353b@weaponx>
Message-ID: <20071120081541.0045b805@redhat.com>

On Tue, 20 Nov 2007 07:04:54 -0600
Josh Boyer <jwboyer at gmail.com> wrote:

> +1.
> 
> btw, do we have instructions somewhere for setting up git/hg repos on
> fedorapeople?

Hrm, probably not, but we should.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/821ff5cf/attachment.sig>

From caillon at redhat.com  Tue Nov 20 13:26:02 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 14:26:02 +0100
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <1195494068.6281.5.camel@nixon>
References: <1195494068.6281.5.camel@nixon>
Message-ID: <4742E06A.3090901@redhat.com>

On Mon, 19 Nov 2007 18:41 +0100, Brian Pepple wrote:

> With the holidays this week, we've decided to have the FESCo meeting
> today at 20:00 UTC #fedora-meeting on irc.freenode.org.  Sorry about the
> late notice!

While I was unable to attend at this time anyway, I am very much annoyed 
at the lack of notice from a global perspective.  It is not unreasonable 
for someone to make a 9pm meeting.  It *is* unreasonable to expect 
someone to be reading mail during dinner hours to find out about it. 
The reason that the meeting was rescheduled was because of a U.S. 
specific holiday, and in the process, made it very difficult for 
non-Americans that wanted to attend to do so.  We didn't push back 
because we deemed the topics of enough importance.  Which underscores 
the importance for giving people fair chances at showing.  Do we 
seriously need to institute a policy for a minimum amount of notice with 
meeting schedule changes?  Or can we start thinking like a global 
distribution?

/rant



From caillon at redhat.com  Tue Nov 20 13:30:37 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 14:30:37 +0100
Subject: NetworkManager - Why Doesn't nm-applet have a
	way	of	using	WPA-PSK?
In-Reply-To: <47428C23.6030507@gmail.com>
References: <474279D1.7060709@gmail.com>	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>	<4742845F.8030606@gmail.com>
	<47428C23.6030507@gmail.com>
Message-ID: <4742E17D.5070906@redhat.com>

On 11/20/2007 08:26 AM, Kelly Miller wrote:
> Andrew Farris wrote:
>> Was your access point configured to only allow this option?  Sounds 
>> like the OP
>> is wanting to FORCE the use of WPA-PSK (i.e. access point will allow 
>> it), not
>> just have NM make the choice automatically.  The access point may be 
>> setup to
>> allow several security options.
>>   
> Yes, I have to force it, because up until today the system was using 
> WEP.  However, I found out through experimentation that my wireless 
> network was acting horribly flaky, and I managed to track it to the WEP 
> key itself (when I removed the security, everything worked fine).  So I 
> switched the access point to use WPA-PSK, as a better option than 
> leaving it wide open.  But NetworkManager was still insisting it used 
> WEP, so I was trying to force it to switch.  nm-applet allows manually 
> selecting WEP and a few other options, but not WPA-PSK with a specific 
> encryption cipher.

What really should be happening is NM should notice there is a 
new/different encryption scheme and offer to let you enter it.  You 
shouldn't have to force it.  If this is not happening, file a bug.



From jkeating at redhat.com  Tue Nov 20 13:32:28 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 08:32:28 -0500
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <4742E06A.3090901@redhat.com>
References: <1195494068.6281.5.camel@nixon>
	<4742E06A.3090901@redhat.com>
Message-ID: <20071120083228.1bbcebf8@redhat.com>

On Tue, 20 Nov 2007 14:26:02 +0100
Christopher Aillon <caillon at redhat.com> wrote:

> While I was unable to attend at this time anyway, I am very much
> annoyed at the lack of notice from a global perspective.  It is not
> unreasonable for someone to make a 9pm meeting.  It *is* unreasonable
> to expect someone to be reading mail during dinner hours to find out
> about it. The reason that the meeting was rescheduled was because of
> a U.S. specific holiday, and in the process, made it very difficult
> for non-Americans that wanted to attend to do so.  We didn't push
> back because we deemed the topics of enough importance.  Which
> underscores the importance for giving people fair chances at
> showing.  Do we seriously need to institute a policy for a minimum
> amount of notice with meeting schedule changes?  Or can we start
> thinking like a global distribution?

There was a poll site set up for who could make what meeting times.  A
time was picked that had the most people available marked, and those
people were specifically contacted again to make sure they could make
it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/7b7ec624/attachment.sig>

From caillon at redhat.com  Tue Nov 20 13:36:01 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 14:36:01 +0100
Subject: Smolt database is broken
In-Reply-To: <20071120115203.GA3361@devserv.devel.redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>	<200711191813.45675.kewley@gps.caltech.edu>	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
Message-ID: <4742E2C1.1010006@redhat.com>

On 11/20/2007 12:52 PM, Alan Cox wrote:
> On Mon, Nov 19, 2007 at 11:32:03PM -0500, Yaakov Nemoy wrote:
>> That is in fact a possibility.  It uses the output from
>> /proc/sys/kernel/random/uuid to work.  Is there a flaw with this
>> method that we know nothing about?  Should we use another?
> 
> Well libuuid is the other alternative. I'm a bit concerned about reports
> the kernel uuid generator isn't as random as it should be. I'd like to know
> more - such as what uuids come up a lot and chase that further.

I agree we should track this down in the kernel.  But even so, it is 
theoretically possible for the same UUID to come up multiple times. 
Shouldn't we be generating UUIDs on the smolt server itself and letting 
the client know what the UUID is, to better protect against duplicates?



From jkeating at redhat.com  Tue Nov 20 13:33:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 08:33:34 -0500
Subject: NetworkManager - Why Doesn't nm-applet have a way	of	using
 WPA-PSK?
In-Reply-To: <4742E17D.5070906@redhat.com>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com>
Message-ID: <20071120083334.5b50b956@redhat.com>

On Tue, 20 Nov 2007 14:30:37 +0100
Christopher Aillon <caillon at redhat.com> wrote:

> What really should be happening is NM should notice there is a 
> new/different encryption scheme and offer to let you enter it.  You 
> shouldn't have to force it.  If this is not happening, file a bug.

After talking to Dan, often it is impossible to tell.  All we can do is
fail to associate with the old method, and then popup a box to allow
you to pick a different auth method.  If all the auth methods aren't
available in that popup, /that/ would be a bug.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/1323cee2/attachment.sig>

From j.w.r.degoede at hhs.nl  Tue Nov 20 13:37:06 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 14:37:06 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <50080.192.54.193.53.1195563090.squirrel@rousalka.dyndns.org>
References: <50080.192.54.193.53.1195563090.squirrel@rousalka.dyndns.org>
Message-ID: <4742E302.50000@hhs.nl>

Nicolas Mailhot wrote:
> Le Mar 20 novembre 2007 13:11, Hans de Goede a ?crit :
>> Nicolas Mailhot wrote:
> 
>>> Whatever solution you choose forcing installation of core fonts
>>> backend by the main font package is a no-go for modern fonts
>>> (TTF/OTF,
>>> maybe Type 1 too).
>> What do you mean with the "core fonts backend"?
> 
> Fonts accessed through the original X core protocol. Official
> X11/XFree86/Xorg name of what you are writing about.
> 
> (http://keithp.com/~keithp/talks/xtc2001/paper/)
> 
>>> You can split the core font scriptlet parts in a
>>> subpackage, or ship pre-generated files, as long as you do not
>>> impact
>>> the vast majority of users who have no need for core fonts.
>>>
>> Yes, assuming that with the "core fonts backend" you mean mkfontdir &
>> friends,
>> then I agree, having a dependency on these is not a good plan, so I
>> see 2 options:
>> 1) Use pregenerated files (I just checked there contents and I see
>> nothing
>>     different from how they looked in the XFree86 3.x days, so I do
>> not believe
>>     these are xorg version / arch / dpi dependent). This is the
>> prefered option.
> 
> This was changed to scriptlets in the time we still had people caring
> about core fonts so I wouldn't assume there were no technical reason
> for the change. But I actively don't care whether core fonts work or
> not so if you believe this will work and are ready to shoulder the
> resulting QA you're free to go this way.
> 

I believe the technical reason was the split from a monolithic X to many small 
packages, and this caused multiple font packages that installe fonts into one 
dir, thats a scheme (multiple packages installing fonts into the same dir) 
which will not work with pre generated fonts.scale and fonts.dir files, other 
then that I see no reason why this could not work.

And if we include pre-generated fonts.scale / fonts.dir files in all fonts 
packages which install a symlink under /etc/X11/fonpath.d, and 2 packages turn 
out to share a dir we will get a fileconflict and find out soon enough.

Also please understand that I'm not trying to necessarily change things here 
esp. not for the sake of changing, I'm trying to fix things because currently, 
due to using scriptlets without deps, quite a few font packages which install a 
symlink under /etc/X11/fonpath.d do not have a fonts.dir / fonts.scale at all, 
as they were installed before mkfontdir was, and there scripts thus failed.

Regards,

Hans



From rjones at redhat.com  Tue Nov 20 13:36:23 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 20 Nov 2007 13:36:23 +0000
Subject: yum groups
In-Reply-To: <20071119133548.5356769a@redhat.com>
References: <4741C213.6080308@redhat.com>	<870180fe0711190923h4cff30d2k7c15e89b40a53c96@mail.gmail.com>	<20071119124420.6a8969e6@redhat.com>
	<4741CE8F.10907@redhat.com> <20071119133548.5356769a@redhat.com>
Message-ID: <4742E2D7.1070302@redhat.com>

Jesse Keating wrote:
> On Mon, 19 Nov 2007 17:57:35 +0000
> "Richard W.M. Jones" <rjones at redhat.com> wrote:
> 
>> Reading around this it seems like the yumgroups.xml file in the 
>> repository controls this (although the Fedora repos don't seem to
>> have this file -- perhaps it's been renamed?).  So I guess my
>> question is what controls what packages are in what groups?
> 
> Comps.
> 
> 
> http://fedoraproject.org/wiki/PackageMaintainers/CompsXml

Ah ha, thank you!

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/5deaee50/attachment.bin>

From sundaram at fedoraproject.org  Tue Nov 20 13:39:42 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 20 Nov 2007 19:09:42 +0530
Subject: System-config Reworking Proposal
In-Reply-To: <1195508394.3568.16.camel@localhost.localdomain>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>	<1195477633.7218.21.camel@localhost.localdomain>	<47418E9A.9040603@leemhuis.info>	<1195485134.7218.23.camel@localhost.localdomain>	<4741A758.6040201@fedoraproject.org>
	<1195508394.3568.16.camel@localhost.localdomain>
Message-ID: <4742E39E.6070102@fedoraproject.org>

Lubomir Kundrak wrote:

> I'm not saying we are. It was just a good friendly advise. Other
> question would be -- why use it? Only use that can't be replaced by
> other existing (and better) tools is to give untrusted users access to
> privileged tools that weren't designed in security with mind.

If it was advise, it didn't sound quite like it. There are several 
hundreds of thousands of users using sudo regularly. Our tools should 
work with them regardless of whatever imperfections you perceive with 
using sudo. Having said that, if you have better alternatives to 
suggest, then it would make it a more complete advise.

Rahul



From omar at linux.vnet.ibm.com  Tue Nov 20 13:44:44 2007
From: omar at linux.vnet.ibm.com (Mohammed Omar)
Date: Tue, 20 Nov 2007 19:14:44 +0530
Subject: Fedora Core testing
Message-ID: <1195566284.8287.8.camel@omar>

Hi all,

I do Fedora Core testing as a part of Community Distro test at IBM .
Basic idea is to find bugs at early stages of Distro release on  X and P
series hardware. Initially I started fedora testing on Power box and
later will test on Xseries.I would like to share the releases of FC8
tested,Hardware used, test suites executed and no. of bugs found.

Covered Releases:
----------------

Releases: Date: status:
FC8test1 07 Aug 2007 finished
FC8test2 13 Sept 2007 finished
FC8test3 04 Oct 2007 finished
FC8GA 08 Nov 2007      currently testing

Test suites used for testing above releases 
--------------------------------------------

Installation/Upgradation testing
NFS/HTTP/FTP/local installations.
Smoke testing includes LTP
Stress testing
Core kernel and regression testing 
Memory stress
FS stress testing etc,.


Hardware Used for fedora core testing:
---------------------------------------
PPC64 : P520, P55 , JS21 , P630b 
i386:  X445       [ Used for network tests ]
X86_64:  X3400    [ Used for network tests ]


Total no. of Bugs Found: 11 ,  closed: 3
----------------------------------------
Listing some of the bugs here...

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239658
https://bugzilla.redhat.com/show_bug.cgi?id=268241
https://bugzilla.redhat.com/show_bug.cgi?id=353021

Most of the bugs closed internally. Basically I do concentrate on system
testing to find more bugs in kernel.

New Features tested: 
--------------------
EXT4 fs tested with fs stress, NFS ,SAMBA.
I am also looking to test Kdump on Fedora.

I would like to invite Fedora users and testers to join in testing
fedora effectively.

--Thanks
Omar M,



From caillon at redhat.com  Tue Nov 20 13:50:09 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 14:50:09 +0100
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <20071120083228.1bbcebf8@redhat.com>
References: <1195494068.6281.5.camel@nixon>	<4742E06A.3090901@redhat.com>
	<20071120083228.1bbcebf8@redhat.com>
Message-ID: <4742E611.5070403@redhat.com>

On 11/20/2007 02:32 PM, Jesse Keating wrote:
> On Tue, 20 Nov 2007 14:26:02 +0100
> Christopher Aillon <caillon at redhat.com> wrote:
> 
>> While I was unable to attend at this time anyway, I am very much
>> annoyed at the lack of notice from a global perspective.  It is not
>> unreasonable for someone to make a 9pm meeting.  It *is* unreasonable
>> to expect someone to be reading mail during dinner hours to find out
>> about it. The reason that the meeting was rescheduled was because of
>> a U.S. specific holiday, and in the process, made it very difficult
>> for non-Americans that wanted to attend to do so.  We didn't push
>> back because we deemed the topics of enough importance.  Which
>> underscores the importance for giving people fair chances at
>> showing.  Do we seriously need to institute a policy for a minimum
>> amount of notice with meeting schedule changes?  Or can we start
>> thinking like a global distribution?
> 
> There was a poll site set up for who could make what meeting times.  A
> time was picked that had the most people available marked, and those
> people were specifically contacted again to make sure they could make
> it.

Yes, I participated in the poll.  But there is a reason why we have the 
meeting in a public forum.  Not everyone who cares is one of the 13 
FESCo members.

Also, _all_ FESCo members should have been contacted in case plans 
changed.  Reading the lists, it appears yours did and were not able to 
make it when you originally said you would.  Mine could have in theory 
as well, but since I did not initially say I was available, I did not 
receive a direct notice, and I am equally not happy about that.  :-)



From P at draigBrady.com  Tue Nov 20 13:51:07 2007
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Tue, 20 Nov 2007 13:51:07 +0000
Subject: NetworkManager - Why Doesn't nm-applet have
	a	way	of	using	WPA-PSK?
In-Reply-To: <4742E17D.5070906@redhat.com>
References: <474279D1.7060709@gmail.com>	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>	<4742845F.8030606@gmail.com>	<47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com>
Message-ID: <4742E64B.1030404@draigBrady.com>

Christopher Aillon wrote:
> What really should be happening is NM should notice there is a
> new/different encryption scheme and offer to let you enter it.  You
> shouldn't have to force it.  If this is not happening, file a bug.

Is there a way to clear NM's state.
I'm having serious issues with NM after a F7 to F8 upgrade,
and would like to clear state to see if it helps,
and before I start filing a plethora of bugs.

P?draig.



From buc at odusz.so-cdu.ru  Tue Nov 20 13:56:47 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Tue, 20 Nov 2007 16:56:47 +0300
Subject: InstantMirror Proposal Re: ApacheMirror.py for a site-local
 Fedora mirror
In-Reply-To: <4742524F.2010705@redhat.com>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>
	<4742524F.2010705@redhat.com>
Message-ID: <4742E79F.1040900@odu.neva.ru>

Warren Togami wrote:

> Perhaps a separate, asynchronous daemon can monitor upstream (via HTTP 
> or whatever) for repomd.xml changes.  It should then parse the 
> repomd.xml so it knows when to expire the repodata/* files.  Then it 
> should parse the .xml files in repodata/ to compare it to local 
> storage, and intelligently expire the packages if any changed (as 
> happens during signing).  It can then know exactly which files to 
> delete from the local cache because they are no longer in the upstream.  

I have thought about something similar already.

Perhaps I'll speak about something different. :)

I've created a simple yum plugin, "yum-justdb". With an alternate "root" 
(--installroot=DIR) and "keepcache=1", it allows to "install", "update", 
"remove" etc. packages "virtually" -- i.e. against a special separate 
rpm database. By this way, all transactions are performed (all 
dependency checking, obsoleting etc.), and the downloaded packages can 
be simple obtained by the yum cache (then moved to a local repository by 
shell scripts etc.)

I've written some shell script which utilize all the tasks needed to 
maintain a local "partial repo" (a subset of the original 
Fedora+Livna+others repos, with all dependencies resolved). Now I'm 
testing it.

The "rpm" command always has "--root DIR" and "--justdb" options, but 
YUM currently has "--installroot=DIR" only, hence the additional 
yum-justdb plugin is needed. But by design, YUM already has an option 
"tsflags" (and the correspond yum-tsflags plugin in yum-utils). 
Unfortunately, "tsflags" supports only subset of possible rpm 
transaction flags, and "justdb" is not supported yet.

I've already proposed the simple patch for "justdb": 
https://lists.dulug.duke.edu/pipermail/yum/2007-November/010310.html
but it seems nobody hear me.

I do not want to publish my script until I will be clear whether I 
should publish an extra yum plugin as well, or just refer to the latest 
yum release with "tsflags=justdb" support. Just because the extra plugin 
will be unneeded then, and I have to retrain users from "yum --justdb" 
to "yum --tsflags=justdb" .

If anyone can promote the adding of 'justdb' support to yum, it could be 
nice. Then we can start to work further.


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From caillon at redhat.com  Tue Nov 20 14:04:36 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 15:04:36 +0100
Subject: NetworkManager - Why Doesn't nm-applet
	have	a	way	of	using	WPA-PSK?
In-Reply-To: <4742E64B.1030404@draigBrady.com>
References: <474279D1.7060709@gmail.com>	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>	<4742845F.8030606@gmail.com>	<47428C23.6030507@gmail.com>	<4742E17D.5070906@redhat.com>
	<4742E64B.1030404@draigBrady.com>
Message-ID: <4742E974.1030603@redhat.com>

On 11/20/2007 02:51 PM, P?draig Brady wrote:
> Christopher Aillon wrote:
>> What really should be happening is NM should notice there is a
>> new/different encryption scheme and offer to let you enter it.  You
>> shouldn't have to force it.  If this is not happening, file a bug.
> 
> Is there a way to clear NM's state.
> I'm having serious issues with NM after a F7 to F8 upgrade,
> and would like to clear state to see if it helps,
> and before I start filing a plethora of bugs.

gconftool-2 --recursive-unset /system/networking

ought to wipe it.  Might want to make sure the applet and/or service are 
not running, though.



From caillon at redhat.com  Tue Nov 20 14:05:16 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 15:05:16 +0100
Subject: NetworkManager - Why Doesn't nm-applet have a way	of	using
	WPA-PSK?
In-Reply-To: <20071120083334.5b50b956@redhat.com>
References: <474279D1.7060709@gmail.com>	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>	<4742845F.8030606@gmail.com>
	<47428C23.6030507@gmail.com>	<4742E17D.5070906@redhat.com>
	<20071120083334.5b50b956@redhat.com>
Message-ID: <4742E99C.6020500@redhat.com>

On 11/20/2007 02:33 PM, Jesse Keating wrote:
> On Tue, 20 Nov 2007 14:30:37 +0100
> Christopher Aillon <caillon at redhat.com> wrote:
> 
>> What really should be happening is NM should notice there is a 
>> new/different encryption scheme and offer to let you enter it.  You 
>> shouldn't have to force it.  If this is not happening, file a bug.
> 
> After talking to Dan, often it is impossible to tell.  All we can do is
> fail to associate with the old method, and then popup a box to allow
> you to pick a different auth method.  If all the auth methods aren't
> available in that popup, /that/ would be a bug.

OK.



From galibert at pobox.com  Tue Nov 20 14:05:50 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 15:05:50 +0100
Subject: WTF?  Inaccessible bug reports?
Message-ID: <20071120140550.GA20367@dspnet.fr.eu.org>

  You are not authorized to access bug #260621.

Right.  Black-on-red too, somebody has seen too many crappy hollywood
movies.  Surprised it doesn't blink.

So I'm trying to find out why David Cantrell decided to make my life
hell on 2007-09-04 by disabling any possibility of static ip when
using kickstart and the changelog refers to bug #260621 which I'm
somehow not allowed to see.

So I am supposed to guess why the hell such a change was made how?
That would be the first step to try to provide a solution acceptable
by everybody.

  OG.



From jwboyer at gmail.com  Tue Nov 20 14:17:01 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 08:17:01 -0600
Subject: Fedora Core testing
In-Reply-To: <1195566284.8287.8.camel@omar>
References: <1195566284.8287.8.camel@omar>
Message-ID: <20071120081701.0337028b@weaponx>

On Tue, 20 Nov 2007 19:14:44 +0530
Mohammed Omar <omar at linux.vnet.ibm.com> wrote:

> Hi all,
> 
> I do Fedora Core testing as a part of Community Distro test at IBM .
> Basic idea is to find bugs at early stages of Distro release on  X and P
> series hardware. Initially I started fedora testing on Power box and
> later will test on Xseries.I would like to share the releases of FC8
> tested,Hardware used, test suites executed and no. of bugs found.

Great.  More QA is always welcome!

> Listing some of the bugs here...
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239658

That is actually an F7 bug... does it still happen in F8?

> New Features tested: 
> --------------------
> EXT4 fs tested with fs stress, NFS ,SAMBA.

EXT4 isn't included in the Fedora kernels for F8.  Testing it is of
course good in the long run, but it's not testing the Fedora kernel at
that point.

(By the way, there is no more "Core" in the name.  It's just Fedora
now.)

josh



From jwboyer at gmail.com  Tue Nov 20 14:19:53 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 08:19:53 -0600
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <4742E611.5070403@redhat.com>
References: <1195494068.6281.5.camel@nixon> <4742E06A.3090901@redhat.com>
	<20071120083228.1bbcebf8@redhat.com> <4742E611.5070403@redhat.com>
Message-ID: <20071120081953.0b9933a2@weaponx>

On Tue, 20 Nov 2007 14:50:09 +0100
Christopher Aillon <caillon at redhat.com> wrote:
> 
> Also, _all_ FESCo members should have been contacted in case plans 
> changed.  Reading the lists, it appears yours did and were not able to 
> make it when you originally said you would.  Mine could have in theory 
> as well, but since I did not initially say I was available, I did not 
> receive a direct notice, and I am equally not happy about that.  :-)

Ok, that's fair.  We'll try to make sure it doesn't happen again.

If you have comments on the actual discussions that took place
yesterday, feel free to send those out too.

josh



From jwboyer at gmail.com  Tue Nov 20 14:26:47 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 08:26:47 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120140550.GA20367@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
Message-ID: <20071120082647.137221b6@weaponx>

On Tue, 20 Nov 2007 15:05:50 +0100
Olivier Galibert <galibert at pobox.com> wrote:

>   You are not authorized to access bug #260621.
> 
> Right.  Black-on-red too, somebody has seen too many crappy hollywood
> movies.  Surprised it doesn't blink.
> 
> So I'm trying to find out why David Cantrell decided to make my life
> hell on 2007-09-04 by disabling any possibility of static ip when
> using kickstart and the changelog refers to bug #260621 which I'm
> somehow not allowed to see.
> 
> So I am supposed to guess why the hell such a change was made how?
> That would be the first step to try to provide a solution acceptable
> by everybody.

Perhaps you should calm down a bit.  Flying off the handle before
asking if the bug permissions can be changed or an explanation is
provided is probably not going to be very productive.

josh



From wtogami at redhat.com  Tue Nov 20 14:32:24 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Nov 2007 09:32:24 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <20071120055958.5d3cdcbd@vader.jdub.homelinux.org>
References: <47420B80.9070001@redhat.com>	<20071119204055.00c6b399@vader.jdub.homelinux.org>	<474256DC.2030801@redhat.com>
	<20071120055958.5d3cdcbd@vader.jdub.homelinux.org>
Message-ID: <4742EFF8.50909@redhat.com>

Josh Boyer wrote:
>> Josh Boyer wrote:
>>> The idea behind this is nice.  Using CVS to do it will suck.  
>> What about it exactly?
>> Using CVS as a tool again when we should be using a more modern VCS?
> 
> Yes.  The fact that you manually have to copy the history, which isn't
> all that important anyway, from one repo to another sucks and adds one
> more barrier before the package is in.

It isn't "one more barrier".  The amount of work needed to copy the 
history over is roughly equal to the current CVS admin procedure when 
scripted.  If the amount of work is roughly equal, then where is the 
drawback especially when it is not required to use it?

Warren Togami
wtogami at redhat.com



From wtogami at redhat.com  Tue Nov 20 14:35:45 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Nov 2007 09:35:45 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <20071120075202.78de1855@redhat.com>
References: <47420B80.9070001@redhat.com>	<1195511355.27963.1.camel@localhost.localdomain>	<4742106E.50305@redhat.com>	<1195512172.27963.3.camel@localhost.localdomain>	<47421500.2040807@redhat.com>
	<20071120075202.78de1855@redhat.com>
Message-ID: <4742F0C1.1050902@redhat.com>

Jesse Keating wrote:
> On Mon, 19 Nov 2007 17:58:08 -0500
> Warren Togami <wtogami at redhat.com> wrote:
> 
>> Risk Mitigating Factor:
>> New contributors have no CVS commit access to /cvs/pkgreview at all 
>> until a reviewer gives them access.  The reviewer should know better 
>> than to allow something with legal problems into the CVS repo or to 
>> grant someone access to upload such code.  So in practice, this
>> removal plan is likely to be needed rarely if ever.
> 
> If it's only for existing contributors, why can't they just use their
> fedorapeople space with git or hg or whatever?
> 
> 

It isn't just for existing contributors.  It has potential benefits to 
aid the workflow of existing contributors (central location and same 
tools as post-review).  The other key benefit would be for new 
contributors who use the tools for the first time.  It would be great to 
provide them a very similar work area to how they will be maintaining 
their package after the review.

Warren Togami
wtogami at redhat.com



From linville at redhat.com  Tue Nov 20 14:46:15 2007
From: linville at redhat.com (John W. Linville)
Date: Tue, 20 Nov 2007 09:46:15 -0500
Subject: F8, b43 and radio button for BCM4318
In-Reply-To: <200711162141.27244.darth_linux@ameritech.net>
References: <200711152056.46958.darth_linux@ameritech.net>
	<20071116154828.GA11383@redhat.com>
	<200711162141.27244.darth_linux@ameritech.net>
Message-ID: <20071120144614.GA13316@redhat.com>

On Fri, Nov 16, 2007 at 09:41:26PM -0500, eah wrote:

> I tried iwconfig and could only get essid set. nick would not set neither 
> would wlan0 find an access point.

What is the output of "iwlist wlan0 scan"?  Please also include the
output of "iwconfig wlan0".

Thanks,

John
-- 
John W. Linville
linville at redhat.com



From dennis at ausil.us  Tue Nov 20 14:47:56 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 20 Nov 2007 08:47:56 -0600
Subject: Fedora Core testing
In-Reply-To: <1195566284.8287.8.camel@omar>
References: <1195566284.8287.8.camel@omar>
Message-ID: <200711200848.03429.dennis@ausil.us>

On Tuesday 20 November 2007, Mohammed Omar wrote:
> Hi all,
>
> I do Fedora Core testing as a part of Community Distro test at IBM .
> Basic idea is to find bugs at early stages of Distro release on  X and P
> series hardware. Initially I started fedora testing on Power box and
> later will test on Xseries.I would like to share the releases of FC8
> tested,Hardware used, test suites executed and no. of bugs found.
For one  there is no longer a "Fedora Core"  there is just "Fedora"   its just 
F8 

> Covered Releases:
> ----------------
>
> Releases: Date: status:
> FC8test1 07 Aug 2007 finished
> FC8test2 13 Sept 2007 finished
> FC8test3 04 Oct 2007 finished
> FC8GA 08 Nov 2007      currently testing
>
> Test suites used for testing above releases
> --------------------------------------------
>
> Installation/Upgradation testing
> NFS/HTTP/FTP/local installations.
> Smoke testing includes LTP
> Stress testing
> Core kernel and regression testing
> Memory stress
> FS stress testing etc,.
sounds very intresting 

>
> Hardware Used for fedora core testing:
> ---------------------------------------
> PPC64 : P520, P55 , JS21 , P630b
> i386:  X445       [ Used for network tests ]
> X86_64:  X3400    [ Used for network tests ]
>
>
> Total no. of Bugs Found: 11 ,  closed: 3
> ----------------------------------------
> Listing some of the bugs here...
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239658
> https://bugzilla.redhat.com/show_bug.cgi?id=268241
> https://bugzilla.redhat.com/show_bug.cgi?id=353021

perhaps you could have a tracker bug to keep track of all the bugs you find  
so they can all be easily referenced

> Most of the bugs closed internally. Basically I do concentrate on system
> testing to find more bugs in kernel.
>
> New Features tested:
> --------------------
> EXT4 fs tested with fs stress, NFS ,SAMBA.
> I am also looking to test Kdump on Fedora.

Cool :)

> I would like to invite Fedora users and testers to join in testing
> fedora effectively.

how do you propose to achieve this goal?
do you have a test matrix you follow?   do you have resources that you could 
give people access to help with testing?  

It sounds like a great goal.  you should probably work with Will Woods to help 
with his QA efforts.  you should also speak with David Woodhouse about ppc 
specific QA testing.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/13dd4feb/attachment.sig>

From dennis at ausil.us  Tue Nov 20 14:49:56 2007
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 20 Nov 2007 08:49:56 -0600
Subject: FESCo meeting today at 20:00 UTC!
In-Reply-To: <20071120083228.1bbcebf8@redhat.com>
References: <1195494068.6281.5.camel@nixon> <4742E06A.3090901@redhat.com>
	<20071120083228.1bbcebf8@redhat.com>
Message-ID: <200711200849.56821.dennis@ausil.us>

On Tuesday 20 November 2007, Jesse Keating wrote:
> On Tue, 20 Nov 2007 14:26:02 +0100
>
> Christopher Aillon <caillon at redhat.com> wrote:
> > While I was unable to attend at this time anyway, I am very much
> > annoyed at the lack of notice from a global perspective.  It is not
> > unreasonable for someone to make a 9pm meeting.  It *is* unreasonable
> > to expect someone to be reading mail during dinner hours to find out
> > about it. The reason that the meeting was rescheduled was because of
> > a U.S. specific holiday, and in the process, made it very difficult
> > for non-Americans that wanted to attend to do so.  We didn't push
> > back because we deemed the topics of enough importance.  Which
> > underscores the importance for giving people fair chances at
> > showing.  Do we seriously need to institute a policy for a minimum
> > amount of notice with meeting schedule changes?  Or can we start
> > thinking like a global distribution?
>
> There was a poll site set up for who could make what meeting times.  A
> time was picked that had the most people available marked, and those
> people were specifically contacted again to make sure they could make
> it.

I was not contacted to make sure i could make it.  the first i heard was the 
posting a few hours before.  

Dennis



From galibert at pobox.com  Tue Nov 20 14:51:20 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 15:51:20 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120082647.137221b6@weaponx>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
Message-ID: <20071120145119.GA26405@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 08:26:47AM -0600, Josh Boyer wrote:
> Perhaps you should calm down a bit.  Flying off the handle before
> asking if the bug permissions can be changed or an explanation is
> provided is probably not going to be very productive.

Well, sorry.  Fedora becomes worse for my use with each release I try,
and I'm starting to get really annoyed at that, because it used to be
so much better.

  OG.



From pertusus at free.fr  Tue Nov 20 14:53:49 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 20 Nov 2007 15:53:49 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120145119.GA26405@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
Message-ID: <20071120145349.GB2558@free.fr>

On Tue, Nov 20, 2007 at 03:51:20PM +0100, Olivier Galibert wrote:
> 
> Well, sorry.  Fedora becomes worse for my use with each release I try,
> and I'm starting to get really annoyed at that, because it used to be
> so much better.

Inaccessible bugs are there since a long time (and therefore annoying 
since a long time, too ;-).

--
Pat



From jkeating at redhat.com  Tue Nov 20 14:55:51 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 09:55:51 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <4742F0C1.1050902@redhat.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com> <20071120075202.78de1855@redhat.com>
	<4742F0C1.1050902@redhat.com>
Message-ID: <20071120095551.57305902@redhat.com>

On Tue, 20 Nov 2007 09:35:45 -0500
Warren Togami <wtogami at redhat.com> wrote:

> It isn't just for existing contributors.  It has potential benefits
> to aid the workflow of existing contributors (central location and
> same tools as post-review).  The other key benefit would be for new 
> contributors who use the tools for the first time.  It would be great
> to provide them a very similar work area to how they will be
> maintaining their package after the review.

But you said earlier it would be for existing contributors...

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/de85371a/attachment.sig>

From berrange at redhat.com  Tue Nov 20 15:03:47 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 20 Nov 2007 15:03:47 +0000
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120140550.GA20367@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
Message-ID: <20071120150347.GA31236@redhat.com>

On Tue, Nov 20, 2007 at 03:05:50PM +0100, Olivier Galibert wrote:
>   You are not authorized to access bug #260621.
> 
> Right.  Black-on-red too, somebody has seen too many crappy hollywood
> movies.  Surprised it doesn't blink.

Some bugs are restricted because they have security implications which
are under embargo, or they are RHEL bugs with customer or partner
data in them which can't be made public due to obvious confidentiality 
requirements.

> So I'm trying to find out why David Cantrell decided to make my life
> hell on 2007-09-04 by disabling any possibility of static ip when
> using kickstart and the changelog refers to bug #260621 which I'm
> somehow not allowed to see.
> 
> So I am supposed to guess why the hell such a change was made how?

Perhaps you could be polite and simply ask on this list why the particular
RPM change was made, rather than ranting about being unable to view a BZ.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From galibert at pobox.com  Tue Nov 20 15:17:51 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 16:17:51 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120150347.GA31236@redhat.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120150347.GA31236@redhat.com>
Message-ID: <20071120151751.GA30509@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 03:03:47PM +0000, Daniel P. Berrange wrote:
> On Tue, Nov 20, 2007 at 03:05:50PM +0100, Olivier Galibert wrote:
> >   You are not authorized to access bug #260621.
> > 
> > Right.  Black-on-red too, somebody has seen too many crappy hollywood
> > movies.  Surprised it doesn't blink.
> 
> Some bugs are restricted because they have security implications which
> are under embargo, or they are RHEL bugs with customer or partner
> data in them which can't be made public due to obvious confidentiality 
> requirements.

Sure.  Just don't use the bugid as the only explanation of the reason
of a change.  That's, well, common sense.

  OG.



From sandeen at redhat.com  Tue Nov 20 15:23:48 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 20 Nov 2007 09:23:48 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120082647.137221b6@weaponx>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
Message-ID: <4742FC04.7000402@redhat.com>

Josh Boyer wrote:
> On Tue, 20 Nov 2007 15:05:50 +0100
> Olivier Galibert <galibert at pobox.com> wrote:
> 
>>   You are not authorized to access bug #260621.
>>
>> Right.  Black-on-red too, somebody has seen too many crappy hollywood
>> movies.  Surprised it doesn't blink.
>>
>> So I'm trying to find out why David Cantrell decided to make my life
>> hell on 2007-09-04 by disabling any possibility of static ip when
>> using kickstart and the changelog refers to bug #260621 which I'm
>> somehow not allowed to see.
>>
>> So I am supposed to guess why the hell such a change was made how?
>> That would be the first step to try to provide a solution acceptable
>> by everybody.
> 
> Perhaps you should calm down a bit.  Flying off the handle before
> asking if the bug permissions can be changed or an explanation is
> provided is probably not going to be very productive.

I have to agree, though, that there are too many private bugs in the rh
bugzilla.  Some are necessary but too many things default to "private"
IMHO.  Sometimes people just choose wrong flags, though, so yeah, it's
worth asking for a change and not assuming that it was malicious :)  I
do understand your frustration.

-Eric



From jkeating at redhat.com  Tue Nov 20 15:23:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 10:23:34 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120145349.GB2558@free.fr>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr>
Message-ID: <20071120102334.6dfc4150@redhat.com>

On Tue, 20 Nov 2007 15:53:49 +0100
Patrice Dumas <pertusus at free.fr> wrote:

> Inaccessible bugs are there since a long time (and therefore annoying 
> since a long time, too ;-).

Silly security issues, sensitive partner information, sensitive
unreleased product information, etc...  There are real reasons for some
things to be closed off.  It's semi-unfortunate that we share so much
code around these things that a sensitive non-public issue can have
effect on the massively public Fedora.

However the benefits of sharing the bugzilla install far far outweigh
these periodic issues.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/74e7137e/attachment.sig>

From pertusus at free.fr  Tue Nov 20 15:28:29 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 20 Nov 2007 16:28:29 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120102334.6dfc4150@redhat.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr>
	<20071120102334.6dfc4150@redhat.com>
Message-ID: <20071120152829.GD2558@free.fr>

On Tue, Nov 20, 2007 at 10:23:34AM -0500, Jesse Keating wrote:
> On Tue, 20 Nov 2007 15:53:49 +0100
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > Inaccessible bugs are there since a long time (and therefore annoying 
> > since a long time, too ;-).
> 
> Silly security issues, sensitive partner information, sensitive
> unreleased product information, etc...  There are real reasons for some
> things to be closed off.  It's semi-unfortunate that we share so much
> code around these things that a sensitive non-public issue can have
> effect on the massively public Fedora.
> 
> However the benefits of sharing the bugzilla install far far outweigh
> these periodic issues.

I understand very well that there can be sensitive infos, but when these
bugs appear in changelogs or in reference to other bugs, it is very
annoying. I am not saying that things should change. I, for example have
stopped worrying about those isues, I already have enough things to do.

--
Pat



From clumens at redhat.com  Tue Nov 20 15:37:25 2007
From: clumens at redhat.com (Chris Lumens)
Date: Tue, 20 Nov 2007 10:37:25 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120140550.GA20367@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
Message-ID: <20071120153725.GC6864@localhost.localdomain>

> So I'm trying to find out why David Cantrell decided to make my life
> hell on 2007-09-04 by disabling any possibility of static ip when
> using kickstart and the changelog refers to bug #260621 which I'm
> somehow not allowed to see.

Nobody decided to make your life hell.  Software is complicated,
especially the loader, and fixes sometimes have unintended side
effects.

The bug in question fixed a problem where anaconda would stop at the
network configuration screen regardless of what command line arguments
are specified.

> So I am supposed to guess why the hell such a change was made how?
> That would be the first step to try to provide a solution acceptable
> by everybody.

I'd do it like this, given a checkout of the anaconda source:  First I'd
do git log and look for the bug number since we're good about putting
the bug numbers in the changelogs.  Then I'd get the sha1sum from there
(it's e727238ded39f839b8230e0fef25825815336a68 by the way) and do a git
show with that to see exactly what changed.

- Chris



From jkeating at redhat.com  Tue Nov 20 15:35:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 10:35:32 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120152829.GD2558@free.fr>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr>
	<20071120102334.6dfc4150@redhat.com>
	<20071120152829.GD2558@free.fr>
Message-ID: <20071120103532.6dfcc8c6@redhat.com>

On Tue, 20 Nov 2007 16:28:29 +0100
Patrice Dumas <pertusus at free.fr> wrote:

> I understand very well that there can be sensitive infos, but when
> these bugs appear in changelogs or in reference to other bugs, it is
> very annoying. I am not saying that things should change. I, for
> example have stopped worrying about those isues, I already have
> enough things to do.

Right.  Often times it's hard for us to know what is or isn't seen by
all, bugzilla just doesn't make that an easy to see thing.

I don't disagree that this should be avoided, I'm just saying that
mistakes happen and the tools don't exactly help.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/5b469e24/attachment.sig>

From SteveD at redhat.com  Tue Nov 20 15:50:11 2007
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Nov 2007 10:50:11 -0500
Subject: Slow performance writing to NetApp filer
In-Reply-To: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>
References: <alpine.LRH.0.99999.0711191510100.30514@hogwarts.egr.duke.edu>
Message-ID: <47430233.2090400@RedHat.com>



Joshua Baker-LePain wrote:
> I just submitted <https://bugzilla.redhat.com/show_bug.cgi?id=391021>
> regarding an odd issue we're having.  Fedora (both 7 and 8) have
> horribly slow performance when writing to our NetApp FAS3020 filer. 
> I've tested on 2 sets of hardware (i386 and x86_64, with tg3 and e1000
> NICs).  No matter what I try, it won't go faster than ~5MB/s.  The same
> hardware running CentOS-5 gets ~50MB/s.  Performance is just fine
> pointing the Fedora boxes at a Panasas filer.
hmm... Would it be possible to post (in the bz) a bzip2 binary network
trace? Something similar to 
    tshark -w /tmp/bz391021 -i <eth?> host <server>
    bzip2 /tmp/bz391021

> 
> Has anybody else run into this?  It seems a rather odd bug to me.
No and Yes this seems very odd since we test all the
time against Netapp filers...

steved.
 



From katzj at redhat.com  Tue Nov 20 15:55:00 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 20 Nov 2007 10:55:00 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120153725.GC6864@localhost.localdomain>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120153725.GC6864@localhost.localdomain>
Message-ID: <1195574100.4552.23.camel@localhost.localdomain>

On Tue, 2007-11-20 at 10:37 -0500, Chris Lumens wrote:
> > So I'm trying to find out why David Cantrell decided to make my life
> > hell on 2007-09-04 by disabling any possibility of static ip when
> > using kickstart and the changelog refers to bug #260621 which I'm
> > somehow not allowed to see.
> 
> Nobody decided to make your life hell.  Software is complicated,
> especially the loader, and fixes sometimes have unintended side
> effects.
> 
> The bug in question fixed a problem where anaconda would stop at the
> network configuration screen regardless of what command line arguments
> are specified.

Also, it was returning to the behavior which has always been present.

If you're getting your kickstart config over the network (ks=http or
whatnot) and not specifying the IP to use on the command line, DHCP is
used.  This has been the documented behavior since the beginning of
time[1].  If you want a static IP, you have to specify it on the command
line.  That said, I could see an argument for having ip=ask or the like
to be prompted for the information even though it'll make that code even
more painful than it already is.

Jeremy

[1] At least, as long as I can remember.  And since I remember adding
the support for specifying static IPs with kickstart ... :-)



From overholt at redhat.com  Tue Nov 20 15:53:48 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Tue, 20 Nov 2007 10:53:48 -0500
Subject: Volunteers for fixing and/or maintaning Tomcat
In-Reply-To: <1195508766.3568.22.camel@localhost.localdomain>
References: <1195168424.29805.16.camel@localhost.localdomain>
	<1195184868.32233.26.camel@localhost.localdomain>
	<1195491301.20121.4.camel@tophat.yyz.redhat.com>
	<1195508766.3568.22.camel@localhost.localdomain>
Message-ID: <20071120155348.GA25326@redhat.com>

* Lubomir Kundrak <lkundrak at redhat.com> [2007-11-19 16:46]:
> > 
> > I didn't read fedora-devel since last week and just noticed this.  Does
> > this affect eclipse which requires tomcat5?
> 
> I guess not.

Was it tried?

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/3f05a987/attachment.sig>

From overholt at redhat.com  Tue Nov 20 16:00:27 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Tue, 20 Nov 2007 11:00:27 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <20071120160026.GB25326@redhat.com>

* Warren Togami <wtogami at redhat.com> [2007-11-19 18:27]:
> Fedora Engineering Steering Committee is considering removal of packages
> from rawhide who have been without owners since prior to Fedora 8
> [...]
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt

Some information on eclipse-emf:

I don't have the time to update EMF to match the major re-organization
that was done upstream between June 2006 and June 2007.  I think it will
require multiple SRPMs now.  Nothing we currently have in Fedora
requires it, but lots of things do, and it would be nice to have if
someone wants to take it over.  I can offer some guidance.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/e3f197a4/attachment.sig>

From tcallawa at redhat.com  Tue Nov 20 16:01:28 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 20 Nov 2007 11:01:28 -0500
Subject: AWOL: jpo
Message-ID: <1195574488.27963.27.camel@localhost.localdomain>

It seems that Jose Pedro Oliveira (aka jpo) is not coming back to
Fedora. He has 28 open bug tickets, most of them in the new state, and
he has not touched any of his packages or bugzilla since June.

I'm initiating the AWOL process so that we can work on finding new homes
for all of his many packages, and start bugfixing them.

Here's the buglist:
https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&emailassigned_to1=1&emailtype1=exact&email1=jpo%40di.uminho.pt

I think that all reasonable attempts to contact the maintainer have been
made, I emailed him several months ago to try and get a response and got
none.

If he does not respond to this email in a week, I'll take over all of
his packages (temporarily) and post to fedora-devel that they're all up
for grabs.

Thanks,

~spot



From gilboad at gmail.com  Tue Nov 20 16:12:55 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Tue, 20 Nov 2007 18:12:55 +0200
Subject: Wine 0.9.49?
In-Reply-To: <20071119184806.168363ab@alkaid.a.lan>
References: <1195368367.18748.5.camel@gilboa-home-dev.localdomain>
	<20071118224425.3b888a72@alkaid.a.lan>
	<1195481792.8410.4.camel@gilboa-work-dev.localdomain>
	<20071119184806.168363ab@alkaid.a.lan>
Message-ID: <1195575175.21607.9.camel@gilboa-work-dev.localdomain>


On Mon, 2007-11-19 at 18:48 +0100, Andreas Bierfert wrote:
> On Mon, 19 Nov 2007 16:16:32 +0200
> Gilboa Davara <gilboad at gmail.com> wrote:
> 
> > Looking forward for it.
> 
> F-{7,8} builds should hit testing with the next push.
> 
> Regards,
> Andreas

Yey! :)

- Gilboa



From notting at redhat.com  Tue Nov 20 16:14:18 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 11:14:18 -0500
Subject: trashed display raster fonts in gnome-terminal
In-Reply-To: <1195510413.4412.16.camel@dhcppc0>
References: <1195510413.4412.16.camel@dhcppc0>
Message-ID: <20071120161418.GB18619@nostromo.devel.redhat.com>

K?oczko Tomasz (kloczek at zie.pg.gda.pl) said: 
> Anyone can confirm this effect ? (for fill BR)

https://bugs.freedesktop.org/show_bug.cgi?id=13224

Bill



From galibert at pobox.com  Tue Nov 20 16:17:19 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 17:17:19 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120153725.GC6864@localhost.localdomain>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120153725.GC6864@localhost.localdomain>
Message-ID: <20071120161719.GA40258@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 10:37:25AM -0500, Chris Lumens wrote:
> > So I'm trying to find out why David Cantrell decided to make my life
> > hell on 2007-09-04 by disabling any possibility of static ip when
> > using kickstart and the changelog refers to bug #260621 which I'm
> > somehow not allowed to see.
> 
> Nobody decided to make your life hell.  Software is complicated,
> especially the loader, and fixes sometimes have unintended side
> effects.
> 
> The bug in question fixed a problem where anaconda would stop at the
> network configuration screen regardless of what command line arguments
> are specified.

By forcing dhcp whatever appears or not in the kickstart file?  David
needs more sleep.  OTOH, so do I.

You can understand that the intent was somewhat unclear.


> > So I am supposed to guess why the hell such a change was made how?
> > That would be the first step to try to provide a solution acceptable
> > by everybody.
> 
> I'd do it like this, given a checkout of the anaconda source:  First I'd
> do git log and look for the bug number since we're good about putting
> the bug numbers in the changelogs.  Then I'd get the sha1sum from there
> (it's e727238ded39f839b8230e0fef25825815336a68 by the way) and do a git
> show with that to see exactly what changed.

Which won't tell me *why*, only *what*.  I already know what was done,
where do you think I got the exact date and bugid from?  What I was
missing is the *intent*.

  OG.



From dcbw at redhat.com  Tue Nov 20 16:15:20 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 20 Nov 2007 11:15:20 -0500
Subject: NetworkManager - Why Doesn't nm-applet have a way	of	using
	WPA-PSK?
In-Reply-To: <4742E99C.6020500@redhat.com>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <20071120083334.5b50b956@redhat.com>
	<4742E99C.6020500@redhat.com>
Message-ID: <1195575321.3389.12.camel@localhost.localdomain>

On Tue, 2007-11-20 at 15:05 +0100, Christopher Aillon wrote:
> On 11/20/2007 02:33 PM, Jesse Keating wrote:
> > On Tue, 20 Nov 2007 14:30:37 +0100
> > Christopher Aillon <caillon at redhat.com> wrote:
> > 
> >> What really should be happening is NM should notice there is a 
> >> new/different encryption scheme and offer to let you enter it.  You 
> >> shouldn't have to force it.  If this is not happening, file a bug.
> > 
> > After talking to Dan, often it is impossible to tell.  All we can do is
> > fail to associate with the old method, and then popup a box to allow
> > you to pick a different auth method.  If all the auth methods aren't
> > available in that popup, /that/ would be a bug.

Jesse's only partially right, actually... He's talking about WEP auth
modes, which cannot be distinguished.  With WPA though, the AP
broadcasts and Information Element telling what capabilities it supports
(thankfully somebody had a clue).  So we can tell between WEP and
not-WEP [1].

When connecting to an AP that's changed properties, the APs current
properties should override the properties of the stored connection
details.  If they don't, it's a bug.  But it's also true that changing
the capabilities on the fly isn't as well tested as connecting to them
in the first place, mainly because people connect to APs much more often
than they switch their APs settings.  So I call bug.

Dan


[1] though we cannot tell when Enterprise class APs support _both_ WEP
and WPA at the same time, but the user only wants to use WEP or only has
a WEP-capable card.  Some APs only broadcast the WPA-TKIP capability but
accept WEP connections as well as a backwards compat measure.



From dcbw at redhat.com  Tue Nov 20 16:16:06 2007
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 20 Nov 2007 11:16:06 -0500
Subject: NetworkManager - Why Doesn't nm-applet
	have	a	way	of	using	WPA-PSK?
In-Reply-To: <4742E974.1030603@redhat.com>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com>	<47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <4742E64B.1030404@draigBrady.com>
	<4742E974.1030603@redhat.com>
Message-ID: <1195575366.3389.14.camel@localhost.localdomain>

On Tue, 2007-11-20 at 15:04 +0100, Christopher Aillon wrote:
> On 11/20/2007 02:51 PM, P?draig Brady wrote:
> > Christopher Aillon wrote:
> >> What really should be happening is NM should notice there is a
> >> new/different encryption scheme and offer to let you enter it.  You
> >> shouldn't have to force it.  If this is not happening, file a bug.
> > 
> > Is there a way to clear NM's state.
> > I'm having serious issues with NM after a F7 to F8 upgrade,
> > and would like to clear state to see if it helps,
> > and before I start filing a plethora of bugs.
> 
> gconftool-2 --recursive-unset /system/networking
> 
> ought to wipe it.  Might want to make sure the applet and/or service are 
> not running, though.

It should recognize the change and it will kill your current connection,
because you just wiped it out.

Dan




From bnocera at redhat.com  Tue Nov 20 16:20:49 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Tue, 20 Nov 2007 16:20:49 +0000
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120103532.6dfcc8c6@redhat.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr> <20071120102334.6dfc4150@redhat.com>
	<20071120152829.GD2558@free.fr>  <20071120103532.6dfcc8c6@redhat.com>
Message-ID: <1195575649.10878.205.camel@cookie.hadess.net>


On Tue, 2007-11-20 at 10:35 -0500, Jesse Keating wrote:
> On Tue, 20 Nov 2007 16:28:29 +0100
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > I understand very well that there can be sensitive infos, but when
> > these bugs appear in changelogs or in reference to other bugs, it is
> > very annoying. I am not saying that things should change. I, for
> > example have stopped worrying about those isues, I already have
> > enough things to do.
> 
> Right.  Often times it's hard for us to know what is or isn't seen by
> all, bugzilla just doesn't make that an easy to see thing.
> 
> I don't disagree that this should be avoided, I'm just saying that
> mistakes happen and the tools don't exactly help.

Jesse, if you'd be so kind to mention that to the people from the
Software Engineering Group, the internal support tools don't help there.

I've been barking up that tree for more than 3 years, didn't seem to get
much more movement than "you're right"...



From galibert at pobox.com  Tue Nov 20 16:20:47 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 17:20:47 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <1195574100.4552.23.camel@localhost.localdomain>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120153725.GC6864@localhost.localdomain>
	<1195574100.4552.23.camel@localhost.localdomain>
Message-ID: <20071120162047.GB40258@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 10:55:00AM -0500, Jeremy Katz wrote:
> Also, it was returning to the behavior which has always been present.

My fedora 5 boot/install usb stick disagrees.


> If you're getting your kickstart config over the network (ks=http or
> whatnot) and not specifying the IP to use on the command line, DHCP is
> used.  This has been the documented behavior since the beginning of
> time[1].  If you want a static IP, you have to specify it on the command
> line.  That said, I could see an argument for having ip=ask or the like
> to be prompted for the information even though it'll make that code even
> more painful than it already is.

And if you're *not* getting the ks config over the network?

Is dhcp a fedora requirement now?

  OG.



From mmahut at fedoraproject.org  Tue Nov 20 16:21:55 2007
From: mmahut at fedoraproject.org (Marek Mahut)
Date: Tue, 20 Nov 2007 17:21:55 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120151751.GA30509@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120150347.GA31236@redhat.com>
	<20071120151751.GA30509@dspnet.fr.eu.org>
Message-ID: <474309A3.9040304@fedoraproject.org>

Olivier Galibert wrote:
> On Tue, Nov 20, 2007 at 03:03:47PM +0000, Daniel P. Berrange wrote:
>> On Tue, Nov 20, 2007 at 03:05:50PM +0100, Olivier Galibert wrote:
>>>   You are not authorized to access bug #260621.
>>>
>>> Right.  Black-on-red too, somebody has seen too many crappy hollywood
>>> movies.  Surprised it doesn't blink.
>> Some bugs are restricted because they have security implications which
>> are under embargo, or they are RHEL bugs with customer or partner
>> data in them which can't be made public due to obvious confidentiality 
>> requirements.
> 
> Sure.  Just don't use the bugid as the only explanation of the reason
> of a change.  That's, well, common sense.

#260621 is not Fedora bug at all. Where did you found the number for
reference? In anaconda commit?

>   OG.
> 

-- 
Marek Mahut                           http://www.fedoraproject.org/
Fedora Project                              http://www.jamendo.com/



From eswierk at arastra.com  Tue Nov 20 16:21:49 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Tue, 20 Nov 2007 08:21:49 -0800
Subject: InstantMirror Proposal Re: ApacheMirror.py for a site-local
	Fedora mirror
In-Reply-To: <4742524F.2010705@redhat.com>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>
	<4742524F.2010705@redhat.com>
Message-ID: <e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>

On 11/19/07, Warren Togami <wtogami at redhat.com> wrote:
> http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/RequestingNewProject
> Could you please create an "upstream" project for it at
> hosted.fedoraproject.org?  I think there are a number of improvements
> that can be made.

Done. I like the name InstantMirror.

> I didn't read deeply into your code yet, but I imagine that it needs
> improvement to handle unique synchronization and expiration issues that
> yum repos and rawhide install trees create when file contents change
> without changing filenames.

If a requested file already exists in the local mirror, the handler
compares the Last-Modified time of the upstream file with the local
file, and downloads the file if the upstream version is newer. I'm not
familiar with rawhide, but this seems to work okay for the updates
repos where metadata files are frequently regenerated. It doesn't
remove files that no longer exist upstream, of course.

> Perhaps a separate, asynchronous daemon can monitor upstream (via HTTP
> or whatever) for repomd.xml changes.  It should then parse the
> repomd.xml so it knows when to expire the repodata/* files.  Then it
> should parse the .xml files in repodata/ to compare it to local storage,
> and intelligently expire the packages if any changed (as happens during
> signing).  It can then know exactly which files to delete from the local
> cache because they are no longer in the upstream.  This daemon interacts
> with ApacheMirror.py only in deleting files from the local directories,
> effectively expiring the cache.  Very simple.
>
> That daemon could be configured to handle intelligent expiry of various
> parts of the mirror tree in different ways.  For example:
> - development (rawhide) repo changes at least once per day.  It also
> contains install images (boot.iso, bootdisk.img, stage2, etc.) that need
> to be expired every time the tree changes.  (We might need to add a
> hashes file to the mirror tree to allow the tool to monitor these changes.)
> - Released distros never change, so don't need to monitor their
> repomd.xml for changes.

An even simpler approach is to have the daemon iterate through every
local file, checking whether the file exists upstream and deleting the
local copy if it doesn't. This requres no repodata parsing, but
flooding the upstream server with HEAD requests might be considered
unfriendly.

> The default definitions for mirroring download.fedoraproject.org could
> be included in a Fedora/EPEL package that requires ApacheMirror.py and
> the monitor/expiry daemon.  That way a sysadmin who wants to create an
> instant Fedora mirror need only install that package and enable it in
> /etc/httpd/conf.d/.  yum update handles pulling in updates for tree
> changes (repo locations, how often to poll for repomd.xml changes, etc.)
>
> Example:
> yum install InstantMirror-fedora
> vim /etc/httpd/conf.d/InstantMirror-fedora.conf
> #(enable stuff)
> service httpd restart
> # http://fedora.localdomain.com
> Instant Fedora mirror!
>
> InstantMirror-fedora.noarch.rpm    : instant Fedora mirror
> InstantMirror-centos.noarch.rpm    : instant CentOS mirror
> InstantMirror-rpmfusion.noarch.rpm : instant RPMFusion mirror
> InstantMirror-foo.noarch.rpm       : instant Foo mirror

Sounds good.

> p.p.s.
> Another idea before I forget about it:
> Later add configurable fallbacks to a different upstream if
> download.fp.org is down.  mirrors.kernel.org might be a good alternative
> for default, for example.

Yes, it would be easy to configure a list of upstream servers instead
of a single one, and hit them either in priority order or randomly.

--Ed



From jkeating at redhat.com  Tue Nov 20 16:24:10 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 11:24:10 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <1195575649.10878.205.camel@cookie.hadess.net>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr>
	<20071120102334.6dfc4150@redhat.com>
	<20071120152829.GD2558@free.fr>
	<20071120103532.6dfcc8c6@redhat.com>
	<1195575649.10878.205.camel@cookie.hadess.net>
Message-ID: <20071120112410.0b1e775d@redhat.com>

On Tue, 20 Nov 2007 16:20:49 +0000
Bastien Nocera <bnocera at redhat.com> wrote:

> Jesse, if you'd be so kind to mention that to the people from the
> Software Engineering Group, the internal support tools don't help
> there.
> 
> I've been barking up that tree for more than 3 years, didn't seem to
> get much more movement than "you're right"...

Well, the problem is I don't have good suggestions on how to fix it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/32c1c1e1/attachment.sig>

From tcallawa at redhat.com  Tue Nov 20 16:25:07 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 20 Nov 2007 11:25:07 -0500
Subject: [Fedora-legal-list] UniConvertor: is it possible to include to
	Fedora?
In-Reply-To: <20071120085842.GA9545@serv.smile.org.ua>
References: <20071120085842.GA9545@serv.smile.org.ua>
Message-ID: <1195575907.27963.28.camel@localhost.localdomain>


On Tue, 2007-11-20 at 10:58 +0200, Andy Shevchenko wrote:
> Hi!
> 
> I'd like to add UniConvertor[1] to the Fedora.
> However I think the legal issues are may present.
> Who could comment that code? 
> 
> Possible, I wrote to the wrong list?
> 
> [1] 
> Project page: http://sk1project.org/modules.php?name=Products&product=uniconvertor
> Prepared package: ftp://toaster.asplinux.com.ua/pub/people/andy/extras/uniconvertor-1.0.0-1.fc7.src.rpm

This is fine, but the proper license tag is:

License: LGPLv2+ and GPLv2+ and MIT

~spot



From galibert at pobox.com  Tue Nov 20 16:28:00 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 17:28:00 +0100
Subject: File conflicts, how do they work at that point?
Message-ID: <20071120162800.GC40258@dspnet.fr.eu.org>

Transaction Check Error:
  file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8

Now that's a beautiful error message :-) Probably one is x86_64 and
the other i386.

What are the rules for file conflicts now?  I thought they didn't
exist anymore since multilib makes them more than annoying, and you
couldn't even install both glibcs, but it looks like they can still
appear somehow...

  OG.



From notting at redhat.com  Tue Nov 20 16:29:42 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 11:29:42 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <20071120162942.GD18619@nostromo.devel.redhat.com>

Warren Togami (wtogami at redhat.com) said: 
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.

FWIW, the following other packages have dependencies on these packages:

Package libid3tag
gtkpod-0:0.99.10-1.fc8.x86_64
libid3tag-0:0.15.1b-4.fc8.x86_64
audacity-0:1.3.2-17.fc9.x86_64
imlib2-id3tag-loader-0:1.4.0-4.fc9.x86_64
gnomad2-0:2.9.0-2.fc9.x86_64
muine-0:0.8.8-3.fc8.x86_64
audacity-0:1.3.2-17.fc8.x86_64
muine-0:0.8.8-3.fc9.x86_64
libid3tag-devel-0:0.15.1b-4.fc8.x86_64
libid3tag-0:0.15.1b-4.fc8.i386
libid3tag-devel-0:0.15.1b-4.fc8.i386

Package openct
openct-0:0.6.14-3.fc8.i386
openct-devel-0:0.6.14-3.fc8.i386
opensc-0:0.11.4-1.fc8.i386
opensc-0:0.11.4-1.fc8.x86_64
openct-devel-0:0.6.14-3.fc8.x86_64
openct-0:0.6.14-3.fc8.x86_64
pcsc-lite-openct-0:0.6.14-3.fc8.x86_64

Package opensc
opensc-0:0.11.4-1.fc8.x86_64
opensc-0:0.11.4-1.fc8.i386
opensc-devel-0:0.11.4-1.fc8.i386
mozilla-opensc-signer-0:0.11.4-1.fc8.x86_64
opensc-devel-0:0.11.4-1.fc8.x86_64

Package pcsc-perl
pcsc-perl-0:1.4.6-2.fc8.x86_64
pcsc-tools-0:1.4.10-1.fc8.x86_64

Package python-musicbrainz2
listen-0:0.5-15.fc7.1.x86_64
picard-0:0.9.0-0.4.beta1.fc9.x86_64

Package system-config-keyboard
anaconda-0:11.4.0.1-1.x86_64
system-config-keyboard-0:1.2.11-3.fc8.noarch

Bill



From galibert at pobox.com  Tue Nov 20 16:29:51 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 17:29:51 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <474309A3.9040304@fedoraproject.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120150347.GA31236@redhat.com>
	<20071120151751.GA30509@dspnet.fr.eu.org>
	<474309A3.9040304@fedoraproject.org>
Message-ID: <20071120162951.GD40258@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 05:21:55PM +0100, Marek Mahut wrote:
> #260621 is not Fedora bug at all. Where did you found the number for
> reference? In anaconda commit?

Yep.

commit e727238ded39f839b8230e0fef25825815336a68
Author: David Cantrell <dcantrell at redhat.com>
Date:   Tue Sep 4 18:17:33 2007 +0000

            * loader2/loader.c (doLoaderMain): In STEP_IFACE, if we are doing
            a kickstart install, flag it. Init ipv4method and ipv6method (#260621).
            * loader2/loader.h: Add LOADER_FLAGS_IS_KICKSTART and
            FL_IS_KICKSTART() (#260621).
            * loader2/net.c (configureTCPIP): Set skipForm to 1 if kickstart
            flag is set (#260621).

diff --git a/ChangeLog b/ChangeLog
index d688e95..58c1d02 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -8,6 +8,13 @@
 	* iw/network_gui.py (NetworkWindow.setupDevices): Do not assume we
 	have HWADDR or DESC when generating tooltip.
 
+	* loader2/loader.c (doLoaderMain): In STEP_IFACE, if we are doing
+	a kickstart install, flag it. Init ipv4method and ipv6method (#260621).
+	* loader2/loader.h: Add LOADER_FLAGS_IS_KICKSTART and
+	FL_IS_KICKSTART() (#260621).
+	* loader2/net.c (configureTCPIP): Set skipForm to 1 if kickstart
+	flag is set (#260621).
+
 2007-09-04  Chris Lumens  <clumens at redhat.com>
 
 	* backend.py (AnacondaBackend.writePackagesKS, writeConfiguration):
diff --git a/loader2/loader.c b/loader2/loader.c
index 5d7107e..7291066 100644
--- a/loader2/loader.c
+++ b/loader2/loader.c
@@ -1128,6 +1128,11 @@ static char *doLoaderMain(char * location,
             /* fall through to interface selection */
         case STEP_IFACE:
             logMessage(INFO, "going to pick interface");
+
+            /* skip configureTCPIP() screen for kickstart (#260621) */
+            if (loaderData->ksFile)
+                flags |= LOADER_FLAGS_IS_KICKSTART;
+
             loaderData->ipinfo_set = 0;
             loaderData->ipv6info_set = 0;
 
diff --git a/loader2/loader.h b/loader2/loader.h
index 7ab83bb..ecc7a23 100644
--- a/loader2/loader.h
+++ b/loader2/loader.h
@@ -45,6 +45,7 @@
 #define LOADER_FLAGS_NOIPV6             (((uint64_t) 1) << 32)
 #define LOADER_FLAGS_IP_PARAM           (((uint64_t) 1) << 33)
 #define LOADER_FLAGS_IPV6_PARAM         (((uint64_t) 1) << 34)
+#define LOADER_FLAGS_IS_KICKSTART       (((uint64_t) 1) << 35)
 
 #define FL_TESTING(a)            ((a) & LOADER_FLAGS_TESTING)
 #define FL_EXPERT(a)             ((a) & LOADER_FLAGS_EXPERT)
@@ -85,6 +86,7 @@
 #define FL_NOIPV6(a)             ((a) & LOADER_FLAGS_NOIPV6)
 #define FL_IP_PARAM(a)           ((a) & LOADER_FLAGS_IP_PARAM)
 #define FL_IPV6_PARAM(a)         ((a) & LOADER_FLAGS_IPV6_PARAM)
+#define FL_IS_KICKSTART(a)       ((a) & LOADER_FLAGS_IS_KICKSTART)
 
 void startNewt(void);
 void stopNewt(void);
diff --git a/loader2/net.c b/loader2/net.c
index 720b54c..60e0cfb 100644
--- a/loader2/net.c
+++ b/loader2/net.c
@@ -701,6 +701,9 @@ int configureTCPIP(char * device, struct networkDeviceConfig * cfg,
     newtComponent ipv4Checkbox, ipv6Checkbox, v4Method[2], v6Method[3];
     newtGrid grid, checkgrid, buttons;
 
+    newCfg->ipv4method = -1;
+    newCfg->ipv6method = -1;
+
     /* UI WINDOW 1: ask for ipv4 choice, ipv6 choice, and conf methods */
 
     /* IPv4 checkbox */
@@ -777,12 +780,15 @@ int configureTCPIP(char * device, struct networkDeviceConfig * cfg,
      *     noipv4 noipv6
      *     ip=<val> noipv6
      *     ipv6=<val> noipv4
+     * we also skip this form for anyone doing a kickstart install
      */
     if ((FL_IP_PARAM(flags) && FL_IPV6_PARAM(flags)) ||
         (FL_IP_PARAM(flags) && FL_NOIPV6(flags)) ||
         (FL_IPV6_PARAM(flags) && FL_NOIPV4(flags)) ||
-        (FL_NOIPV4(flags) && FL_NOIPV6(flags))) {
+        (FL_NOIPV4(flags) && FL_NOIPV6(flags)) ||
+        (FL_IS_KICKSTART(flags))) {
         skipForm = 1;
+        newtPopWindow();
     }
 
     /* run the form */



From j.w.r.degoede at hhs.nl  Tue Nov 20 16:33:49 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 17:33:49 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120162800.GC40258@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
Message-ID: <47430C6D.4030208@hhs.nl>

Olivier Galibert wrote:
> Transaction Check Error:
>   file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
> 
> Now that's a beautiful error message :-) Probably one is x86_64 and
> the other i386.
> 
> What are the rules for file conflicts now?  I thought they didn't
> exist anymore since multilib makes them more than annoying, and you
> couldn't even install both glibcs, but it looks like they can still
> appear somehow...
>
They do not exist for elf binaries, for other files, the files must be 
identical for both x86_64 and i386, my guess: smcs is a shell script?

Regards,

Hans



From fedora at leemhuis.info  Tue Nov 20 16:35:13 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 20 Nov 2007 17:35:13 +0100
Subject: Fedora Core testing
In-Reply-To: <1195566284.8287.8.camel@omar>
References: <1195566284.8287.8.camel@omar>
Message-ID: <47430CC1.2080901@leemhuis.info>



On 20.11.2007 14:44, Mohammed Omar wrote:
> [...]
> Test suites used for testing above releases 
> --------------------------------------------
> 
> Installation/Upgradation testing
> NFS/HTTP/FTP/local installations.
> Smoke testing includes LTP
> Stress testing
> Core kernel and regression testing 
> Memory stress
> FS stress testing etc,.
> [...]

I some weeks ago created a package kcbench for Fedora, which compiles a
kernel to measure the build time or test system stability. Maybe it can
be useful for your work. If you need any additional features kcbench
just let me know or send patches ;-)

Cu
knurd



From j.w.r.degoede at hhs.nl  Tue Nov 20 16:34:41 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 17:34:41 +0100
Subject: AWOL: jpo
In-Reply-To: <1195574488.27963.27.camel@localhost.localdomain>
References: <1195574488.27963.27.camel@localhost.localdomain>
Message-ID: <47430CA1.1030407@hhs.nl>

Tom "spot" Callaway wrote:
> It seems that Jose Pedro Oliveira (aka jpo) is not coming back to
> Fedora. He has 28 open bug tickets, most of them in the new state, and
> he has not touched any of his packages or bugzilla since June.
>

<ugh>, I hope he resurfaces.

Regards,

Hans



From caillon at redhat.com  Tue Nov 20 16:37:16 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 20 Nov 2007 17:37:16 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120162800.GC40258@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
Message-ID: <47430D3C.8080101@redhat.com>

On 11/20/2007 05:28 PM, Olivier Galibert wrote:
> Transaction Check Error:
>   file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
> 
> Now that's a beautiful error message :-) Probably one is x86_64 and
> the other i386.

The content of the file is a shell script which has a reference to 
/usr/lib64 on my 64bit box, so yes they are different and would conflict 
if both installed.

Were you installing something which is bringing down the 32 bit version 
for you?



From galibert at pobox.com  Tue Nov 20 16:43:48 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 17:43:48 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120162800.GC40258@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
Message-ID: <20071120164348.GA44996@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 05:28:00PM +0100, Olivier Galibert wrote:
> Transaction Check Error:
>   file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
> 
> Now that's a beautiful error message :-) Probably one is x86_64 and
> the other i386.
> 
> What are the rules for file conflicts now?  I thought they didn't
> exist anymore since multilib makes them more than annoying, and you
> couldn't even install both glibcs, but it looks like they can still
> appear somehow...

Ok, now it's getting interesting:

[root at m42 ~]# rpm -Uvh /vol/corpora/system/fc8-64/Packages/mono-core-1.2.5.1-3.fc8.i386.rpm 
Preparing...                ########################################### [100%]
        file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
[root at m42 ~]# rpm -e --nodeps mono-core
[root at m42 ~]# rpm -Uvh /vol/corpora/system/fc8-64/Packages/mono-core-1.2.5.1-3.fc8.*.rpm 
Preparing...                ########################################### [100%]
   1:mono-core              ########################################### [ 50%]
   2:mono-core              ########################################### [100%]

Ouch.  That's a killer.

  OG.



From notting at redhat.com  Tue Nov 20 16:46:30 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 11:46:30 -0500
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120164348.GA44996@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<20071120164348.GA44996@dspnet.fr.eu.org>
Message-ID: <20071120164630.GA23695@nostromo.devel.redhat.com>

Olivier Galibert (galibert at pobox.com) said: 
> Ok, now it's getting interesting:
> 
> [root at m42 ~]# rpm -Uvh /vol/corpora/system/fc8-64/Packages/mono-core-1.2.5.1-3.fc8.i386.rpm 
> Preparing...                ########################################### [100%]
>         file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
> [root at m42 ~]# rpm -e --nodeps mono-core
> [root at m42 ~]# rpm -Uvh /vol/corpora/system/fc8-64/Packages/mono-core-1.2.5.1-3.fc8.*.rpm 
> Preparing...                ########################################### [100%]
>    1:mono-core              ########################################### [ 50%]
>    2:mono-core              ########################################### [100%]
> 
> Ouch.  That's a killer.

https://bugzilla.redhat.com/show_bug.cgi?id=190209

Bill



From galibert at pobox.com  Tue Nov 20 16:54:13 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 17:54:13 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <47430D3C.8080101@redhat.com>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<47430D3C.8080101@redhat.com>
Message-ID: <20071120165413.GB44996@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 05:37:16PM +0100, Christopher Aillon wrote:
> On 11/20/2007 05:28 PM, Olivier Galibert wrote:
> >Transaction Check Error:
> >  file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts 
> >  with file from package mono-core-1.2.5.1-3.fc8
> >
> >Now that's a beautiful error message :-) Probably one is x86_64 and
> >the other i386.
> 
> The content of the file is a shell script which has a reference to 
> /usr/lib64 on my 64bit box, so yes they are different and would conflict 
> if both installed.
>
> Were you installing something which is bringing down the 32 bit version 
> for you?

Yes, '*', from a repository which contents are 99% from the dvd image,
only up to date, and with things like "tcsh" added.

  OG.



From galibert at pobox.com  Tue Nov 20 17:00:05 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 18:00:05 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120164630.GA23695@nostromo.devel.redhat.com>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<20071120164348.GA44996@dspnet.fr.eu.org>
	<20071120164630.GA23695@nostromo.devel.redhat.com>
Message-ID: <20071120170005.GC44996@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 11:46:30AM -0500, Bill Nottingham wrote:
> Olivier Galibert (galibert at pobox.com) said: 
> > Ok, now it's getting interesting:
> > 
> > [root at m42 ~]# rpm -Uvh /vol/corpora/system/fc8-64/Packages/mono-core-1.2.5.1-3.fc8.i386.rpm 
> > Preparing...                ########################################### [100%]
> >         file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
> > [root at m42 ~]# rpm -e --nodeps mono-core
> > [root at m42 ~]# rpm -Uvh /vol/corpora/system/fc8-64/Packages/mono-core-1.2.5.1-3.fc8.*.rpm 
> > Preparing...                ########################################### [100%]
> >    1:mono-core              ########################################### [ 50%]
> >    2:mono-core              ########################################### [100%]
> > 
> > Ouch.  That's a killer.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=190209

Somehow, that make me wonder why people file bugs in bugzilla.  That's
the second 1y+ old known bug I've been hitting in less than a week.

  OG.



From snecklifter at gmail.com  Tue Nov 20 17:02:10 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Tue, 20 Nov 2007 17:02:10 +0000
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071120112410.0b1e775d@redhat.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr> <20071120102334.6dfc4150@redhat.com>
	<20071120152829.GD2558@free.fr> <20071120103532.6dfcc8c6@redhat.com>
	<1195575649.10878.205.camel@cookie.hadess.net>
	<20071120112410.0b1e775d@redhat.com>
Message-ID: <364d303b0711200902n7b058bd1lb6c704eab723bee2@mail.gmail.com>

On 20/11/2007, Jesse Keating <jkeating at redhat.com> wrote:
> On Tue, 20 Nov 2007 16:20:49 +0000
> Bastien Nocera <bnocera at redhat.com> wrote:
>
> > Jesse, if you'd be so kind to mention that to the people from the
> > Software Engineering Group, the internal support tools don't help
> > there.
> >
> > I've been barking up that tree for more than 3 years, didn't seem to
> > get much more movement than "you're right"...
>
> Well, the problem is I don't have good suggestions on how to fix it.

As a start, could someone who handles the bz installation possibly
change the "You are not authorized..." to include the reasons Daniel
named earlier, namely:

"Some bugs are restricted because they have security implications which
are under embargo, or they are RHEL bugs with customer or partner
data in them which can't be made public due to obvious confidentiality
requirements."

as I have to agree the Big Red Message is a bit ... stark.

No, I realise this won't resolve the issue at hand but would be
appreciated by others who may come across this in future.

Cheers
Chris

-- 
http://www.chruz.com



From mzerqung at 0pointer.de  Tue Nov 20 17:08:53 2007
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 20 Nov 2007 18:08:53 +0100
Subject: Pulseaudio problems
In-Reply-To: <68720af30711200232v233c5ff8g10e04fa2315c228a@mail.gmail.com>
References: <68720af30711200232v233c5ff8g10e04fa2315c228a@mail.gmail.com>
Message-ID: <20071120170853.GA31815@tango.0pointer.de>

On Tue, 20.11.07 08:32, Paulo Cavalcanti (promac at gmail.com) wrote:

> >> Hmm? I don't really understand what you edited in that file and what
> >> you achieved with this?
> 
> This is how I send mplayer output to my TV:
> 
> /usr/bin/xinit /usr/bin/xterm -ut -e $HOME/bin/$PROG \
>              $MOVIE -- /usr/bin/X :1 -layout TV &
> 
> With F8, I get not sound at all, unless I execute the above command as root.
> Then I created an audio group for myself and added to
> /etc/security/console.perms.d/50-default.perms:
> 
> # roma
> <sound>=/dev/dsp* /dev/audio* /dev/midi* \
>         /dev/mixer* /dev/sequencer* \
>         /dev/sound/* /dev/beep \
>         /dev/snd/* /dev/adsp*

In F8 permissions to the audio devices are no longer managed by
pam_console, but by HAL. You apparently start MPlayer on a new
virtual terminal. If you want PA to work on that new terminal you of
course have to start it much the same way as you now start the X
server on it.

> >> Yes, I will have another look on the whole Xine situation.
> 
> xine and gxine do not work with pulse plugin (the connection is lost
> after a few
> seconds), but totem does (it is based on xine, right?). What is the
> difference?

Totem uses GStreamer by default, last time I checked. And GST is
supported very well by PA.

> > arecord -D hw:0.0 -d 0 -f S16_LE -c2 -r48000 | aplay -D pulse &
> >
> > for capturing from line in.
> 
> >> Hmm? what did you notice?
> 
> There is a slight hiccup (missing of sound) from time to time.
> It is very fast,and it does not seem to be related to the amount of
> processing on my computer: Core 2 duo, 2.1GHz, 2GB ram, x86_64, F8

Hmm? so "hw:0.0" seems not to be controlled by PA? What is controlled
by PA then? If you connect two different audio devices like this via a
pipe than you will very likely get hiccups eventually. Different sound
cards have different quartzes with small deviations in the
frequency. This, while "hw:0,0" and the pulse output might be in sync
at the beginning they start to deviate more and more the longer they
play. And eventually you get an "hiccup" when the deviation becomes
too large and either the buffers overran or underran.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From galibert at pobox.com  Tue Nov 20 17:11:28 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 18:11:28 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <47430C6D.4030208@hhs.nl>
References: <20071120162800.GC40258@dspnet.fr.eu.org> <47430C6D.4030208@hhs.nl>
Message-ID: <20071120171128.GA49293@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 05:33:49PM +0100, Hans de Goede wrote:
> They do not exist for elf binaries, for other files, the files must be 
> identical for both x86_64 and i386, my guess: smcs is a shell script?

Looks so.

So you can't check a repository for consistency without decompressing
the payload in almost every rpm?

  OG.



From limb at jcomserv.net  Tue Nov 20 17:15:16 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 20 Nov 2007 11:15:16 -0600 (CST)
Subject: Moodle package dependencies
In-Reply-To: <473F2288.7080405@redhat.com>
References: <473F2288.7080405@redhat.com>
Message-ID: <1256.63.85.68.164.1195578916.squirrel@mail.jcomserv.net>


> Hi Jon,
>
> http://pastebot.ltsp.org/362
> These are Ubuntu's plans to split up the Moodle package in order to make
> it easier to maintain, especially for security updates.  Apparently
> moodle ships entire other upstream projects within their distribution.
> How are we in Fedora with using our own distro packages for this
> functionality?

If the versions work out, I see no reason not to do this.  I'll get
started soon, definitely a good thing to do by F9.

> Warren Togami
> wtogami at redhat.com
>


-- 
novus ordo absurdum



From tmz at pobox.com  Tue Nov 20 17:29:29 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 20 Nov 2007 12:29:29 -0500
Subject: libgpod soname bump coming to rawhide
Message-ID: <20071120172929.GB2967@psilocybe.teonanacatl.org>

libgpod 0.6.0 was released a week or so ago.  This release supports
the newer iPod models (iPhone, iTouch, Classics, and "Fat" Nanos).
I'd like to push this into rawhide tomorrow and let it get some
testing.  I'll rebuild amarok, gtkpod, kipi-plugins, and rhythmbox at
the same time.

This is definitely something I think warrants an update for F-8 and
F-7 after stewing in rawhide for a week or so.  The version in F-7 was
already getting old before this latest release.  Coupled with the
support for a lot of new hardware, I believe it is a compelling and
worthwhile update even on the stable dists.

While the library soname has been bumped, the changes are not very
invasive and none of the apps using libgpod need more than a
recompile.  Gtkpod is by far the most serious tester of the lib and
it's current release (0.99.10) doesn't even need any changes to work
with the update libgpod.  I've compile and runtime tested amarok,
kipi-plugins, and rhythmbox as well and all of them WORKFORME.

What I'd love some testing with is newer iPod models.  There will be a
README.SysInfo file in the updated package that details some steps to
take to get things working with those newer iPods.  There's also some
HAL integration that is intended to automate much of this for users.
Finding out just how well that all works and fixing any bugs there
before pushing it to the stable dists would be excellent.  That way
Fedora can have very good iPod support for all those folks picking up
new toys in the coming months. :)

The alternative is to tell users that they'll have to wait until
spring to support iPod models that have been out since last spring and
(and will have been supported in other distros for many months by that
point).

Are there any objections to this plan?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INDECISION is the key to FLEXIBILITY. Succeed in spite of management.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/5cee24fd/attachment.sig>

From tmz at pobox.com  Tue Nov 20 17:43:17 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 20 Nov 2007 12:43:17 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <4742A224.4010807@hhs.nl>
References: <47421B35.4080006@redhat.com>
	<20071120073127.3fb29173.mschwendt.tmp0701.nospam@arcor.de>
	<20071120070406.GA2967@psilocybe.teonanacatl.org>
	<4742A224.4010807@hhs.nl>
Message-ID: <20071120174316.GC2967@psilocybe.teonanacatl.org>

Hans de Goede wrote:
> I maintain 2 packages who depend on libid3tag too, so I've just
> requested the necessary rights for co-maintainer ship.

Thanks Hans.  I think I approved everything properly.  If you also
want approveacl privs, just say so.  I don't want to be a choke point
on adding anyone else.

I'm glad to have a more proficient coder helping too.  I know the ID3
spec fairly well and could fix things if needed, but you'll surely be
able to do so with more speed and grace than I could. ;)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the triangles were to make a God they would give him three sides.
    -- Montesquieu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/65352dd4/attachment.sig>

From ville.skytta at iki.fi  Tue Nov 20 17:50:09 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 20 Nov 2007 19:50:09 +0200
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <200711201950.10864.ville.skytta@iki.fi>

On Tuesday 20 November 2007, Warren Togami wrote:
> Fedora Engineering Steering Committee is considering removal of packages
> from rawhide who have been without owners since prior to Fedora 8
> sometime after the next FESCO meeting on November 29th.  The Fedora
> Project routinely removes unmaintained packages from future
> distributions in order to responsibly scale the growth of maintenance
> burden with developer resources available within the project.
>
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.

The following packages were orphaned by me *after* the F8 release specifically 
because I thought that'd help them from being garbage collected almost 
immediately (yes, from devel), so something is inconsistent with the two 
paragraphs above.

gkrellm-weather, libid3tag, openct, opensc, pcsc-perl, pcsc-tools

Also, as far as I know, the cdiff package has already been orphaned and pruned 
from the repos since FE-4.  It should not be brought back, colordiff replaces 
it.



From katzj at redhat.com  Tue Nov 20 17:54:04 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 20 Nov 2007 12:54:04 -0500
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120171128.GA49293@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<47430C6D.4030208@hhs.nl>  <20071120171128.GA49293@dspnet.fr.eu.org>
Message-ID: <1195581244.4552.29.camel@localhost.localdomain>

On Tue, 2007-11-20 at 18:11 +0100, Olivier Galibert wrote:
> On Tue, Nov 20, 2007 at 05:33:49PM +0100, Hans de Goede wrote:
> > They do not exist for elf binaries, for other files, the files must be 
> > identical for both x86_64 and i386, my guess: smcs is a shell script?
> 
> Looks so.
> 
> So you can't check a repository for consistency without decompressing
> the payload in almost every rpm?

You can do it purely from the headers as the headers contain all of the
needed data.  See http://katzj.fedorapeople.org/multilib-cmp.py

Jeremy



From ville.skytta at iki.fi  Tue Nov 20 17:56:14 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 20 Nov 2007 19:56:14 +0200
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <4742A293.8060509@hhs.nl>
References: <47421B35.4080006@redhat.com> <4742A293.8060509@hhs.nl>
Message-ID: <200711201956.14528.ville.skytta@iki.fi>

On Tuesday 20 November 2007, Hans de Goede wrote:

> I see openct, opencs and pcsc-tools listed, didn't we go through a lot
> of effort during FC-6 / F-7 to get smartcard support integrated, isn't
> this need to support certain cards / features then?

Yes.  I'm sure there's quite a bit of end user demand for these packages - 
I've had the intention to check every now and then if someone has claimed 
ownership and if not, ask around on the opensc-devel list if some potential 
maintainers would be lurking there.



From tmz at pobox.com  Tue Nov 20 17:59:16 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 20 Nov 2007 12:59:16 -0500
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120170005.GC44996@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<20071120164348.GA44996@dspnet.fr.eu.org>
	<20071120164630.GA23695@nostromo.devel.redhat.com>
	<20071120170005.GC44996@dspnet.fr.eu.org>
Message-ID: <20071120175916.GE2967@psilocybe.teonanacatl.org>

Olivier Galibert wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=190209
> 
> Somehow, that make me wonder why people file bugs in bugzilla.
> That's the second 1y+ old known bug I've been hitting in less than a
> week.

Not all bugs are simple, several line patches.  It often takes a while
to define the proper solution and then implement it.  I would like to
believe that many people filing bugs realize this.

You must know that most people don't yum install '*' and as such,
don't run into some of these issues, right? :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Foxes prefer rabbits with short claws.
    -- Nadja Adolf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/7dc765eb/attachment.sig>

From jkeating at redhat.com  Tue Nov 20 17:58:43 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 12:58:43 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <200711201950.10864.ville.skytta@iki.fi>
References: <47421B35.4080006@redhat.com>
	<200711201950.10864.ville.skytta@iki.fi>
Message-ID: <20071120125843.0bb9025c@redhat.com>

On Tue, 20 Nov 2007 19:50:09 +0200
Ville Skytt? <ville.skytta at iki.fi> wrote:

> The following packages were orphaned by me *after* the F8 release
> specifically because I thought that'd help them from being garbage
> collected almost immediately (yes, from devel), so something is
> inconsistent with the two paragraphs above.
> 
> gkrellm-weather, libid3tag, openct, opensc, pcsc-perl, pcsc-tools
> 
> Also, as far as I know, the cdiff package has already been orphaned
> and pruned from the repos since FE-4.  It should not be brought back,
> colordiff replaces 

There is a difference between orphaning or end of lifeing.  Orphans
need a timeout before they can be tossed.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/c240f77e/attachment.sig>

From tspauld98 at yahoo.com  Tue Nov 20 18:03:36 2007
From: tspauld98 at yahoo.com (Timothy Spaulding)
Date: Tue, 20 Nov 2007 10:03:36 -0800 (PST)
Subject: AWOL: jpo
In-Reply-To: <47430CA1.1030407@hhs.nl>
Message-ID: <851272.31889.qm@web60523.mail.yahoo.com>

Me too...   Good luck finding a new Perl maintainer...  :)  He/she sits right next to the Assembler programmer.  :)

Hans de Goede <j.w.r.degoede at hhs.nl> wrote: Tom "spot" Callaway wrote:
> It seems that Jose Pedro Oliveira (aka jpo) is not coming back to
> Fedora. He has 28 open bug tickets, most of them in the new state, and
> he has not touched any of his packages or bugzilla since June.
>

, I hope he resurfaces.

Regards,

Hans

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/f9d4da11/attachment.htm>

From myfedora at richip.dhs.org  Tue Nov 20 18:41:25 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Tue, 20 Nov 2007 11:41:25 -0700
Subject: AWOL: jpo
In-Reply-To: <851272.31889.qm@web60523.mail.yahoo.com>
References: <851272.31889.qm@web60523.mail.yahoo.com>
Message-ID: <1195584085.2465.8.camel@localhost6.localdomain6>

On Tue, 2007-11-20 at 10:03 -0800, Timothy Spaulding wrote:
> Me too...   Good luck finding a new Perl maintainer...  :)  He/she
> sits right next to the Assembler programmer.  :)

<wistful-musing off-topic="true">
As much as I love Perl and I prefer it over all existing scripting
languages I'm familiar with, it's hard to get excited about its future
since the developers are extremely quiet about it. My only hope now is
that other scripting languages pick up the little things that make
developing in Perl a joy so that I and many others like me can move on.

*sigh*
</wistful-musing>
--

Richi Plana



From loupgaroublond at gmail.com  Tue Nov 20 18:45:52 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Tue, 20 Nov 2007 13:45:52 -0500
Subject: Smolt database is broken
In-Reply-To: <4742E2C1.1010006@redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<4742E2C1.1010006@redhat.com>
Message-ID: <7f692fec0711201045h7eda18efq27d392b389c3ddf4@mail.gmail.com>

On 11/20/07, Christopher Aillon <caillon at redhat.com> wrote:
> I agree we should track this down in the kernel.  But even so, it is
> theoretically possible for the same UUID to come up multiple times.
> Shouldn't we be generating UUIDs on the smolt server itself and letting
> the client know what the UUID is, to better protect against duplicates?

I would rather have proper UUID generation.  Such a feature, while
technically more correct, would be slightly harder to make sure the
server can handle both the old and new method.

Besides, if we focus our efforts on proper UUID generation, then other
projects will benefit as well.

-Yaakov



From bdwheele at indiana.edu  Tue Nov 20 18:48:06 2007
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Tue, 20 Nov 2007 13:48:06 -0500
Subject: AWOL: jpo
In-Reply-To: <1195584085.2465.8.camel@localhost6.localdomain6>
References: <851272.31889.qm@web60523.mail.yahoo.com>
	<1195584085.2465.8.camel@localhost6.localdomain6>
Message-ID: <1195584486.20585.22.camel@nibbler.dlib.indiana.edu>


On Tue, 2007-11-20 at 11:41 -0700, Richi Plana wrote:
> On Tue, 2007-11-20 at 10:03 -0800, Timothy Spaulding wrote:
> > Me too...   Good luck finding a new Perl maintainer...  :)  He/she
> > sits right next to the Assembler programmer.  :)
> 
> <wistful-musing off-topic="true">
> As much as I love Perl and I prefer it over all existing scripting
> languages I'm familiar with, it's hard to get excited about its future
> since the developers are extremely quiet about it. My only hope now is
> that other scripting languages pick up the little things that make
> developing in Perl a joy so that I and many others like me can move on.
> 
> *sigh*
> </wistful-musing>

Hear, hear!  

Perl6 is probably one of the finest examples of "second system effect"
I've ever come across...which is really sad since they kept pointing out
that they were trying very hard to avoid the SSE.

Brian



From galibert at pobox.com  Tue Nov 20 18:52:49 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 19:52:49 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120175916.GE2967@psilocybe.teonanacatl.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<20071120164348.GA44996@dspnet.fr.eu.org>
	<20071120164630.GA23695@nostromo.devel.redhat.com>
	<20071120170005.GC44996@dspnet.fr.eu.org>
	<20071120175916.GE2967@psilocybe.teonanacatl.org>
Message-ID: <20071120185249.GB51420@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 12:59:16PM -0500, Todd Zullinger wrote:
> You must know that most people don't yum install '*' and as such,
> don't run into some of these issues, right? :)

Most people don't use fedora at home, and as such don't care about yum
at all.  A lot I know did, years ago.  They went to Gentoo, Ubuntu or
OSX since.

Incidentally, how would you install everything needed to able to
recompile anaconda in one yum command?

Oh, joy, f8 just shot its own partition.  Looks like I have to
reinstall and hope it doesn't do it again.

  OG.



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 20 19:01:09 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 20 Nov 2007 20:01:09 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120185249.GB51420@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<20071120164348.GA44996@dspnet.fr.eu.org>
	<20071120164630.GA23695@nostromo.devel.redhat.com>
	<20071120170005.GC44996@dspnet.fr.eu.org>
	<20071120175916.GE2967@psilocybe.teonanacatl.org>
	<20071120185249.GB51420@dspnet.fr.eu.org>
Message-ID: <20071120200109.882f35f1.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 20 Nov 2007 19:52:49 +0100, Olivier Galibert wrote:

> Incidentally, how would you install everything needed to able to
> recompile anaconda in one yum command?

e.g. with yum-builddep

$ man yum-builddep

$ rpm -qf $(which yum-builddep)
yum-utils-1.1.8-1.fc8



From notting at redhat.com  Tue Nov 20 19:02:04 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 14:02:04 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
Message-ID: <20071120190204.GA32542@nostromo.devel.redhat.com>

Normally, post-release, we bump the version of fedora-release and switch
it to use rawhide by default.

However, by doing this, we change the 'releasever' variable used by yum
to 8.90 (or whatever). This means that doing things like:

yum --disablerepo=development --enablerepo=fedora

will not work without editing the config files.

What I propose is that instead of changing the package version, we just
change the release. Something like 'fedora-release-8-5.rawhide', or similar.

Bill



From skvidal at fedoraproject.org  Tue Nov 20 18:58:54 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 20 Nov 2007 13:58:54 -0500
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120185249.GB51420@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<20071120164348.GA44996@dspnet.fr.eu.org>
	<20071120164630.GA23695@nostromo.devel.redhat.com>
	<20071120170005.GC44996@dspnet.fr.eu.org>
	<20071120175916.GE2967@psilocybe.teonanacatl.org>
	<20071120185249.GB51420@dspnet.fr.eu.org>
Message-ID: <1195585134.30278.28.camel@cutter>


On Tue, 2007-11-20 at 19:52 +0100, Olivier Galibert wrote:
> On Tue, Nov 20, 2007 at 12:59:16PM -0500, Todd Zullinger wrote:
> > You must know that most people don't yum install '*' and as such,
> > don't run into some of these issues, right? :)
> 
> Most people don't use fedora at home, and as such don't care about yum
> at all.  A lot I know did, years ago.  They went to Gentoo, Ubuntu or
> OSX since.
> 
> Incidentally, how would you install everything needed to able to
> recompile anaconda in one yum command?
> 

you can do this with mock, which uses yum.

-sv




From tonynelson at georgeanelson.com  Tue Nov 20 19:06:17 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Tue, 20 Nov 2007 14:06:17 -0500
Subject: Smolt database is broken
In-Reply-To: <7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
Message-ID: <p04330101c368cac56cb8@[192.168.123.162]>

At 11:32 PM -0500 11/19/07, Yaakov Nemoy wrote:
>On Nov 19, 2007 11:13 PM, David Kewley <kewley at gps.caltech.edu> wrote:
>> I noticed something similar many months ago, where my machine's entry didn't
>> even have the right architecture.  As I recall, I emailed the Smolt
>> maintainer, and he said it was probably a problem with the client-side UUID
>> generation not being random enough.  As a result, multiple machines could
>> get the same UUID and so write to the same server database entry.  That's
>> the last I heard about it.
>
>That is in fact a possibility.  It uses the output from
>/proc/sys/kernel/random/uuid to work.  Is there a flaw with this
>method that we know nothing about?  Should we use another?

I don't /know/ anything about this, but if the UUID is generated early on,
there may not have been much entropy made yet.  I see that /dev/random
blocks until it thinks it has enough entropy, while /dev/urandome does not,
but I don't know what /proc/sys/kernel/random/* does, though
/proc/sys/kernel/random/entropy_avail should be informative.  `while : ; do
cat /proc/sys/kernel/random/{uuid,entropy_avail} ; done` depletes
entropy_avail of about 256 bits each time, but it never gets to 0, and a
uuid is always returned.  This might be bad, or it might represent
obtaining enough entropy before returning.  I can check harder (measure
times, look for dups) on request.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From ville.skytta at iki.fi  Tue Nov 20 19:09:09 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Tue, 20 Nov 2007 21:09:09 +0200
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <20071120125843.0bb9025c@redhat.com>
References: <47421B35.4080006@redhat.com>
	<200711201950.10864.ville.skytta@iki.fi>
	<20071120125843.0bb9025c@redhat.com>
Message-ID: <200711202109.10412.ville.skytta@iki.fi>

On Tuesday 20 November 2007, Jesse Keating wrote:
> On Tue, 20 Nov 2007 19:50:09 +0200
>
> Ville Skytt? <ville.skytta at iki.fi> wrote:
> > The following packages were orphaned by me *after* the F8 release
> > specifically because I thought that'd help them from being garbage
> > collected almost immediately (yes, from devel), so something is
> > inconsistent with the two paragraphs above.
> >
> > gkrellm-weather, libid3tag, openct, opensc, pcsc-perl, pcsc-tools
> >
> > Also, as far as I know, the cdiff package has already been orphaned
> > and pruned from the repos since FE-4.  It should not be brought back,
> > colordiff replaces
>
> There is a difference between orphaning or end of lifeing.  Orphans
> need a timeout before they can be tossed.

Hm, sure, I understand that, but could you clarify which of the cases above 
(1st: 6 listed packages or 2nd: cdiff) you're replying to?  I'm having 
problems inferring the context.

To clarify: cdiff was just a side note.  What I wanted to point out that 
Warren's message said "removal of packages from rawhide who have been without 
owners since prior to Fedora 8", but the listed packages included several 
packages that had owners until _after_ Fedora 8, so someone could be 
interested in verifying that the list indeed includes packages that it was 
intended to include.  I don't care that deeply, I did orphan those packages 
anyway...



From jkeating at redhat.com  Tue Nov 20 19:06:17 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 14:06:17 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120190204.GA32542@nostromo.devel.redhat.com>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
Message-ID: <20071120140617.6a3bd1c1@redhat.com>

On Tue, 20 Nov 2007 14:02:04 -0500
Bill Nottingham <notting at redhat.com> wrote:

> Normally, post-release, we bump the version of fedora-release and
> switch it to use rawhide by default.
> 
> However, by doing this, we change the 'releasever' variable used by
> yum to 8.90 (or whatever). This means that doing things like:
> 
> yum --disablerepo=development --enablerepo=fedora
> 
> will not work without editing the config files.
> 
> What I propose is that instead of changing the package version, we
> just change the release. Something like 'fedora-release-8-5.rawhide',
> or similar.

I somewhat question picking up packages from the previous release once
you've gotten to the point of your fedora-release package bumped,
especially from a bug reproducing pov, but....

I see no real problem with this.  In the past, the fedora-release
version number lined up (albiet oddly) with the test release numbers.
Since we're not doing numbered test-releases anymore, we could
certainly go to:  fedora-release-8-6.alpha; fedora-release-8-7.beta;
fedora-release-9-1.preview; fedora-release-9-2

We could change the content that is seen at boot time for the Fedora
version to list the "Beta" or "Alpha" or "Preview" without changing the
base package version, until we want to make the switch to the next
version (and make use of mirrormanager redirects for early adopters).

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/02637ce3/attachment.sig>

From notting at redhat.com  Tue Nov 20 19:11:25 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 14:11:25 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120140617.6a3bd1c1@redhat.com>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
Message-ID: <20071120191125.GA1021@nostromo.devel.redhat.com>

Jesse Keating (jkeating at redhat.com) said: 
> > What I propose is that instead of changing the package version, we
> > just change the release. Something like 'fedora-release-8-5.rawhide',
> > or similar.
> 
> I somewhat question picking up packages from the previous release once
> you've gotten to the point of your fedora-release package bumped,
> especially from a bug reproducing pov, but....

yum upgrade

'oops, got the broken gdm'

rpm -e --nodeps gdm

yum --disablerepo=development --enablerepo=fedora install gdm

... fixed!

Bill



From notting at redhat.com  Tue Nov 20 19:12:34 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 14:12:34 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <200711202109.10412.ville.skytta@iki.fi>
References: <47421B35.4080006@redhat.com>
	<200711201950.10864.ville.skytta@iki.fi>
	<20071120125843.0bb9025c@redhat.com>
	<200711202109.10412.ville.skytta@iki.fi>
Message-ID: <20071120191234.GA1109@nostromo.devel.redhat.com>

Ville Skytt? (ville.skytta at iki.fi) said: 
> To clarify: cdiff was just a side note.  What I wanted to point out that 
> Warren's message said "removal of packages from rawhide who have been without 
> owners since prior to Fedora 8", but the listed packages included several 
> packages that had owners until _after_ Fedora 8, so someone could be 
> interested in verifying that the list indeed includes packages that it was 
> intended to include.  I don't care that deeply, I did orphan those packages 
> anyway...

I think the issue is that the time of orphaning is hard to determine in an
automated way, so he didn't.

Bill



From jkeating at redhat.com  Tue Nov 20 19:10:58 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Nov 2007 14:10:58 -0500
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <200711202109.10412.ville.skytta@iki.fi>
References: <47421B35.4080006@redhat.com>
	<200711201950.10864.ville.skytta@iki.fi>
	<20071120125843.0bb9025c@redhat.com>
	<200711202109.10412.ville.skytta@iki.fi>
Message-ID: <20071120141058.6a9bcfdc@redhat.com>

On Tue, 20 Nov 2007 21:09:09 +0200
Ville Skytt? <ville.skytta at iki.fi> wrote:

> To clarify: cdiff was just a side note.  What I wanted to point out
> that Warren's message said "removal of packages from rawhide who have
> been without owners since prior to Fedora 8", but the listed packages
> included several packages that had owners until _after_ Fedora 8, so
> someone could be interested in verifying that the list indeed
> includes packages that it was intended to include.  I don't care that
> deeply, I did orphan those packages anyway...

I see what you're saying.  Yes, the list generation seems to need more
logic.  Warren, how did you generate the list?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/a2eae3ad/attachment.sig>

From buildsys at fedoraproject.org  Tue Nov 20 19:16:59 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Tue, 20 Nov 2007 14:16:59 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-20
Message-ID: <20071120191659.9B78115212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 4

    alsa-tools-1.0.14-2.fc6
    cacti-0.8.7a-1.fc6
    listen-0.5-14.fc6
    phpMyAdmin-2.11.2.1-1.fc6


Changes in Fedora Extras 6: 


alsa-tools-1.0.14-2.fc6
-----------------------
* Sun Oct 28 2007 Tim Jackson <rpm at timj.co.uk> - 1.0.14-2
- Don't build -firmware subpackage again; licensing problems with 
  alsa-firmware are delaying and there is a circular dep
- Remove bogus "echomixer" from -firmware subpackage

* Sat Aug 18 2007 Tim Jackson <rpm at timj.co.uk> - 1.0.14-1
- Update to upstream 1.0.14
- Add icon for envy24control
- Build echomixer
- Enable -firmware subpackage by default, ready for firmware hitting
  Fedora soon

cacti-0.8.7a-1.fc6
------------------
* Tue Nov 20 2007 Mike McGrath <mmcgrath at redhat.com> - 0.8.7a-1
- Upstream released new version
- Fixes for bug #391691 - CVE-2007-6035

listen-0.5-14.fc6
-----------------
* Tue Nov 20 2007 Ha?kel Gu?mar <karlthered at gmail.com> 0.5-14
- add python-tunepimp dependency

phpMyAdmin-2.11.2.1-1.fc6
-------------------------
* Tue Nov 20 2007 Mike McGrath <mmcgrath at redhat.com> 2.11.2.1-1
- Upstream released new version



From galibert at pobox.com  Tue Nov 20 19:17:02 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 20:17:02 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <1195581244.4552.29.camel@localhost.localdomain>
References: <20071120162800.GC40258@dspnet.fr.eu.org> <47430C6D.4030208@hhs.nl>
	<20071120171128.GA49293@dspnet.fr.eu.org>
	<1195581244.4552.29.camel@localhost.localdomain>
Message-ID: <20071120191702.GA66858@dspnet.fr.eu.org>

On Tue, Nov 20, 2007 at 12:54:04PM -0500, Jeremy Katz wrote:
> On Tue, 2007-11-20 at 18:11 +0100, Olivier Galibert wrote:
> > On Tue, Nov 20, 2007 at 05:33:49PM +0100, Hans de Goede wrote:
> > > They do not exist for elf binaries, for other files, the files must be 
> > > identical for both x86_64 and i386, my guess: smcs is a shell script?
> > 
> > Looks so.
> > 
> > So you can't check a repository for consistency without decompressing
> > the payload in almost every rpm?
> 
> You can do it purely from the headers as the headers contain all of the
> needed data.  See http://katzj.fedorapeople.org/multilib-cmp.py

Oh, I see, RPMTAG_FILECOLORS actually gives file types[1].  The RPM
guys should lay off the quantum physics.  Thanks.

  OG.

[1] It's a bitmap?  What the...?



From skvidal at fedoraproject.org  Tue Nov 20 19:20:21 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 20 Nov 2007 14:20:21 -0500
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120191702.GA66858@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<47430C6D.4030208@hhs.nl> <20071120171128.GA49293@dspnet.fr.eu.org>
	<1195581244.4552.29.camel@localhost.localdomain>
	<20071120191702.GA66858@dspnet.fr.eu.org>
Message-ID: <1195586422.30278.30.camel@cutter>


On Tue, 2007-11-20 at 20:17 +0100, Olivier Galibert wrote:
> On Tue, Nov 20, 2007 at 12:54:04PM -0500, Jeremy Katz wrote:
> > On Tue, 2007-11-20 at 18:11 +0100, Olivier Galibert wrote:
> > > On Tue, Nov 20, 2007 at 05:33:49PM +0100, Hans de Goede wrote:
> > > > They do not exist for elf binaries, for other files, the files must be 
> > > > identical for both x86_64 and i386, my guess: smcs is a shell script?
> > > 
> > > Looks so.
> > > 
> > > So you can't check a repository for consistency without decompressing
> > > the payload in almost every rpm?
> > 
> > You can do it purely from the headers as the headers contain all of the
> > needed data.  See http://katzj.fedorapeople.org/multilib-cmp.py
> 
> Oh, I see, RPMTAG_FILECOLORS actually gives file types[1].  The RPM
> guys should lay off the quantum physics.  Thanks.
> 
>   OG.
> 
> [1] It's a bitmap?  What the...?

If you play the bitmap backward it says something about satan.
-sv




From mmcgrath at redhat.com  Tue Nov 20 19:25:47 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 20 Nov 2007 13:25:47 -0600
Subject: Smolt database is broken
In-Reply-To: <20071120115203.GA3361@devserv.devel.redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>	<200711191813.45675.kewley@gps.caltech.edu>	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
Message-ID: <474334BB.1080002@redhat.com>

Alan Cox wrote:
> On Mon, Nov 19, 2007 at 11:32:03PM -0500, Yaakov Nemoy wrote:
>   
>> That is in fact a possibility.  It uses the output from
>> /proc/sys/kernel/random/uuid to work.  Is there a flaw with this
>> method that we know nothing about?  Should we use another?
>>     
>
> Well libuuid is the other alternative. I'm a bit concerned about reports
> the kernel uuid generator isn't as random as it should be. I'd like to know
> more - such as what uuids come up a lot and chase that further.
>   

Here's the top 5:

    266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
    336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a
    402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
    884 06e84493-e024-44b1-9b32-32d78af04039
    931 e2b67e1d-e325-4740-b938-795addb45280


The left number is times this month someone has submitted a profile with 
that UUID.  If we take the last one as an example has come from over 800 
IP's in the last 20 days.  It seems very unlikely that one person would 
find his way to 800 different IP's this month.  Let me know if you'd 
like more.

    -Mike



From jwboyer at gmail.com  Tue Nov 20 19:28:53 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 13:28:53 -0600
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120191125.GA1021@nostromo.devel.redhat.com>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
Message-ID: <20071120132853.274138ea@weaponx>

On Tue, 20 Nov 2007 14:11:25 -0500
Bill Nottingham <notting at redhat.com> wrote:

> Jesse Keating (jkeating at redhat.com) said: 
> > > What I propose is that instead of changing the package version, we
> > > just change the release. Something like 'fedora-release-8-5.rawhide',
> > > or similar.
> > 
> > I somewhat question picking up packages from the previous release once
> > you've gotten to the point of your fedora-release package bumped,
> > especially from a bug reproducing pov, but....
> 
> yum upgrade
> 
> 'oops, got the broken gdm'
> 
> rpm -e --nodeps gdm
> 
> yum --disablerepo=development --enablerepo=fedora install gdm
> 
> ... fixed!

yum upgrade

'oops, got the broken gdm'

download the RPM for the older version

rpm -Uvh --oldpackage <oldversion>

... fixed!

josh



From j.w.r.degoede at hhs.nl  Tue Nov 20 19:30:34 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 20 Nov 2007 20:30:34 +0100
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <4742A293.8060509@hhs.nl>
References: <47421B35.4080006@redhat.com> <4742A293.8060509@hhs.nl>
Message-ID: <474335DA.5000000@hhs.nl>

Hans de Goede wrote:
> Warren Togami wrote:
>> Fedora Engineering Steering Committee is considering removal of packages
>> from rawhide who have been without owners since prior to Fedora 8
>> sometime after the next FESCO meeting on November 29th.  The Fedora
>> Project routinely removes unmaintained packages from future
>> distributions in order to responsibly scale the growth of maintenance
>> burden with developer resources available within the project.
>>
>> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
>> Packages listed on this page are scheduled for removal unless an
>> existing Fedora maintainer claims ownership.
>>
>> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
>> A Fedora package developer may use their Fedora Account in PackageDB to
>> claim ownership of an orphaned package.
>>
>> Removal of an orphaned package entails "blocking" it in the buildsystem
>> so it does not appear in the rawhide repository, and files in CVS of the
>> "devel" branch being replaced with an empty "dead.package" file.  At a
>> later date if a Fedora package developer wishes to revive a dead package
>> they may do so by claiming ownership in pkgdb then requesting the koji
>> block to be removed.  It is however a bit easier if ownership is claimed
>> prior to orphan removal, so please claim packages now if possible.
>>
> 
> Hmm,
> 
> I see openct, opencs and pcsc-tools listed, didn't we go through a lot 
> of effort during FC-6 / F-7 to get smartcard support integrated, isn't 
> this need to support certain cards / features then?
> 
> I'm planning to start working with smartcards sometime soon, and I think 
> I will need these, but I'm not sure.
> 

Ok,

I've taken ownership of openct, opensc, pcsc-perl and pcsc-tools for now, as I 
plan to become a user of them in the near future, and I would hate tro seem 
them goaway.

co-maintainers much appreciated. Ville, perhaps you are willing to stay 
involved as co-maintainer?

Regards,

Hans




From notting at redhat.com  Tue Nov 20 19:31:53 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 14:31:53 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120132853.274138ea@weaponx>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
Message-ID: <20071120193153.GA2221@nostromo.devel.redhat.com>

Josh Boyer (jwboyer at gmail.com) said: 
> yum upgrade
> 
> 'oops, got the broken gdm'
> 
> download the RPM for the older version
> 
> rpm -Uvh --oldpackage <oldversion>
> 
> ... fixed!

That requires going to another repo/web page/irc client/source of information
to figure out and download whatever that version is.

Bill



From jwboyer at gmail.com  Tue Nov 20 19:47:45 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 20 Nov 2007 13:47:45 -0600
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120193153.GA2221@nostromo.devel.redhat.com>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
Message-ID: <20071120134745.611a36c4@weaponx>

On Tue, 20 Nov 2007 14:31:53 -0500
Bill Nottingham <notting at redhat.com> wrote:

> Josh Boyer (jwboyer at gmail.com) said: 
> > yum upgrade
> > 
> > 'oops, got the broken gdm'
> > 
> > download the RPM for the older version
> > 
> > rpm -Uvh --oldpackage <oldversion>
> > 
> > ... fixed!
> 
> That requires going to another repo/web page/irc client/source of information
> to figure out and download whatever that version is.

You can use koji's downloadbuild (or whatever it's called) without too
much trouble.  This is rawhide after all.  Not for the faint of heart.

josh



From notting at redhat.com  Tue Nov 20 19:50:30 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 14:50:30 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120134745.611a36c4@weaponx>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
Message-ID: <20071120195030.GA3431@nostromo.devel.redhat.com>

Josh Boyer (jwboyer at gmail.com) said: 
> > That requires going to another repo/web page/irc client/source of information
> > to figure out and download whatever that version is.
> 
> You can use koji's downloadbuild (or whatever it's called) without too
> much trouble.  This is rawhide after all.  Not for the faint of heart.

Right, but you still have to know *what the old version is*. And that
would still work for my proposal - what I don't understand is why we'd
be wedded to the current practice of shipping intentionally broken repo
files.

Bill



From katzj at redhat.com  Tue Nov 20 19:55:08 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 20 Nov 2007 14:55:08 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120195030.GA3431@nostromo.devel.redhat.com>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
	<20071120195030.GA3431@nostromo.devel.redhat.com>
Message-ID: <1195588508.4552.33.camel@localhost.localdomain>

On Tue, 2007-11-20 at 14:50 -0500, Bill Nottingham wrote:
> Josh Boyer (jwboyer at gmail.com) said: 
> > > That requires going to another repo/web page/irc client/source of information
> > > to figure out and download whatever that version is.
> > 
> > You can use koji's downloadbuild (or whatever it's called) without too
> > much trouble.  This is rawhide after all.  Not for the faint of heart.
> 
> Right, but you still have to know *what the old version is*. And that
> would still work for my proposal - what I don't understand is why we'd
> be wedded to the current practice of shipping intentionally broken repo
> files.

I'd go an alternate route -- let's instead have the mirrorlists redirect
to rawhide for versions like 8.90, etc and get rid of the separate
development repository.  If you want to jump versions, change your
fedora-release.  This then gives us some nice consistency 

Jeremy



From david at fubar.dk  Tue Nov 20 19:55:58 2007
From: david at fubar.dk (David Zeuthen)
Date: Tue, 20 Nov 2007 14:55:58 -0500
Subject: working with gnome project/other distros together on system
	tools (was: Re: System-config Reworking Proposal)
In-Reply-To: <1195552036.29355.19.camel@wombat.tiptoe.de>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>
	<1195470779.7213.12.camel@cyberelk.elk>
	<1195480199.14998.21.camel@gibraltar.str.redhat.com>
	<4741984F.30006@leemhuis.info>
	<1195493308.5442.88.camel@oneill.fubar.dk>
	<1195552036.29355.19.camel@wombat.tiptoe.de>
Message-ID: <1195588558.7652.15.camel@oneill.fubar.dk>


On Tue, 2007-11-20 at 10:47 +0100, Nils Philippsen wrote:
> > Actually for home/consumer desktop use, there is not much need for any
> > of the system-config-* tools any more; for example for F9, intlclock
> > will replace system-config-date
> 
> ... as the tool that is launched when you click on your (GNOME) panel
> clock -> "Adjust Date & Time". I don't see s-c-date going away anytime
> soon (as the maintainer I'm a bit biased), at least as long as the DE
> specific tools are full replacements.

I'm pretty sure that Rawhide intlclock launches code shipped with
intlclock when you press "Adjust Date and Time". If it doesn't that's a
bug. FWIW, this is what it looks like

 http://people.freedesktop.org/~david/intlclock-change-time.png

Yes, this is in contrast to previous Fedora releases where s-c-d was
used.

> Well, the idea of "whatever upstream" is most appealing to me as that
> can as well be us ;-). 

Certainly. Keep in mind that Red Hat / Fedora are already upstream for a
lot of important key projects

 http://fedoraproject.org/wiki/RedHatContributions

So.. the key to participating in upstream projects is just that..
participating. Integrating features into where it makes sense; e.g. for
GNOME the clock applet and NetworkManager for the NTP bits.

Ideally the mechanism used by intlclock is independent of the UI
(intlclock will probably switch to fd.o system tools [1]) so it's easy
for people from KDE, XFCE, etc. to write their own UI shells. And, heck,
why the hell not a TUI version too. All using the same mechanism. All
benefiting from a huge pool of contributors across the free software OS
landscape; not just Linux, also OpenSolaris.

Which is, and sorry if this comes across as a flame, in contrast to
having a stand-alone monolith e.g. system-config-date.

[1] : Formerly (and sorta kinda still) known as gnome system tools

> Mind that as configuration tools aren't only
> interesting to desktop users we should be careful under which umbrella
> (if one) we put them. 

It's not like anyone suggesting that s-c-d is going away. The change
here is that it's not likely to be in the default desktop install.
People can still install it and build spins around it and so forth.

> I'm with you as far as UI <-> logic <-> privileged
> ops separation is concerned.

Sounds good.

       David




From notting at redhat.com  Tue Nov 20 20:01:33 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 15:01:33 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <1195588508.4552.33.camel@localhost.localdomain>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
	<20071120195030.GA3431@nostromo.devel.redhat.com>
	<1195588508.4552.33.camel@localhost.localdomain>
Message-ID: <20071120200133.GA3651@nostromo.devel.redhat.com>

Jeremy Katz (katzj at redhat.com) said: 
> On Tue, 2007-11-20 at 14:50 -0500, Bill Nottingham wrote:
> > Josh Boyer (jwboyer at gmail.com) said: 
> > > > That requires going to another repo/web page/irc client/source of information
> > > > to figure out and download whatever that version is.
> > > 
> > > You can use koji's downloadbuild (or whatever it's called) without too
> > > much trouble.  This is rawhide after all.  Not for the faint of heart.
> > 
> > Right, but you still have to know *what the old version is*. And that
> > would still work for my proposal - what I don't understand is why we'd
> > be wedded to the current practice of shipping intentionally broken repo
> > files.
> 
> I'd go an alternate route -- let's instead have the mirrorlists redirect
> to rawhide for versions like 8.90, etc and get rid of the separate
> development repository.  If you want to jump versions, change your
> fedora-release.  This then gives us some nice consistency 

Then how do you switch to rawhide from a regular install?

Bill



From tibbs at math.uh.edu  Tue Nov 20 20:02:25 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 20 Nov 2007 14:02:25 -0600
Subject: Summary of the 2007-11-20 Packaging Committee meeting
Message-ID: <ufasl304re6.fsf@epithumia.math.uh.edu>

Meeting minutes and full logs of the packaging committee meeting which
occurred on 2007-11-20 are online:

http://fedoraproject.org/wiki/Packaging/Minutes
http://fedoraproject.org/wiki/Packaging/Minutes20071120

Executive summary:

No new guidelines this week.

Issues pending FESCO ratification:
 * Policy for font packages:
 * http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy
  * Accepted (with changes) (5-0)
  * Voting for: spot rdieter abadger1999 scop tibbs
  * Abstaining: racor
  * Some notes:
   * There are components of the proposal which go beyond packaging
     policy and are not considered by FPC.  This includes the
     CompsPolicy document and sections of the draft relating to
     grouping or comps.  These should be discussed by FESCo.
   * http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate
     was approved as part of this proposal with the caveat that the
     scriptlets be prevented from failing.

Misc business:
 * Three volunteers expressed interest in joining the committee; spot
   will poll the membership and we'll decide whether to expand the
   committee or rotate through some members on-list.
 * Next meeting will be December 4th at 17:00UTC.

 - J<



From lordmorgul at gmail.com  Tue Nov 20 20:05:31 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Tue, 20 Nov 2007 12:05:31 -0800
Subject: NetworkManager - Why Doesn't
	nm-applet	have	a	way	of	using	WPA-PSK?
In-Reply-To: <4742E974.1030603@redhat.com>
References: <474279D1.7060709@gmail.com>	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>	<4742845F.8030606@gmail.com>	<47428C23.6030507@gmail.com>	<4742E17D.5070906@redhat.com>	<4742E64B.1030404@draigBrady.com>
	<4742E974.1030603@redhat.com>
Message-ID: <47433E0B.2000907@gmail.com>

Christopher Aillon wrote:
> On 11/20/2007 02:51 PM, P?draig Brady wrote:
>> Christopher Aillon wrote:
>>> What really should be happening is NM should notice there is a
>>> new/different encryption scheme and offer to let you enter it.  You
>>> shouldn't have to force it.  If this is not happening, file a bug.
>>
>> Is there a way to clear NM's state.
>> I'm having serious issues with NM after a F7 to F8 upgrade,
>> and would like to clear state to see if it helps,
>> and before I start filing a plethora of bugs.
> 
> gconftool-2 --recursive-unset /system/networking
> 
> ought to wipe it.  Might want to make sure the applet and/or service are
> not running, though.

Wouldn't it be a good idea to provide this type of NM full state reset from the
applet itself?  To the casual user the only thing visible IS the applet, and
when its not working the applet should provide a possible answer.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From katzj at redhat.com  Tue Nov 20 20:08:22 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 20 Nov 2007 15:08:22 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120200133.GA3651@nostromo.devel.redhat.com>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
	<20071120195030.GA3431@nostromo.devel.redhat.com>
	<1195588508.4552.33.camel@localhost.localdomain>
	<20071120200133.GA3651@nostromo.devel.redhat.com>
Message-ID: <1195589302.4552.40.camel@localhost.localdomain>

On Tue, 2007-11-20 at 15:01 -0500, Bill Nottingham wrote:
> Jeremy Katz (katzj at redhat.com) said: 
> > On Tue, 2007-11-20 at 14:50 -0500, Bill Nottingham wrote:
> > > Josh Boyer (jwboyer at gmail.com) said: 
> > > > > That requires going to another repo/web page/irc client/source of information
> > > > > to figure out and download whatever that version is.
> > > > 
> > > > You can use koji's downloadbuild (or whatever it's called) without too
> > > > much trouble.  This is rawhide after all.  Not for the faint of heart.
> > > 
> > > Right, but you still have to know *what the old version is*. And that
> > > would still work for my proposal - what I don't understand is why we'd
> > > be wedded to the current practice of shipping intentionally broken repo
> > > files.
> > 
> > I'd go an alternate route -- let's instead have the mirrorlists redirect
> > to rawhide for versions like 8.90, etc and get rid of the separate
> > development repository.  If you want to jump versions, change your
> > fedora-release.  This then gives us some nice consistency 
> 
> Then how do you switch to rawhide from a regular install?

>From the nice and unwritten page which links you to the current rawhide
fedora-release package.  

Realistically, you probably want the simple stupid plugin to allow you
to set the release version if you go this route.  But at the same time,
I don't think that the route of switching streams often is really a case
that you optimize for.

The current situation makes things a bit confusing to a user who *isn't*
interested in tracking development because they have out of the box the
following repo choices
  [ X ] Fedora
  [ X ] Fedora Updates
  [   ] Fedora Updates-Testing
  [   ] Fedora Development
not to mention source and debuginfo (which I'm tempted to just filter
from the UI, although it'd be nice if I didn't have to do so based on
just the repoid)

Jeremy



From loupgaroublond at gmail.com  Tue Nov 20 20:14:25 2007
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Tue, 20 Nov 2007 15:14:25 -0500
Subject: NetworkManager - Why Doesn't nm-applet have a way of using
	WPA-PSK?
In-Reply-To: <47433E0B.2000907@gmail.com>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <4742E64B.1030404@draigBrady.com>
	<4742E974.1030603@redhat.com> <47433E0B.2000907@gmail.com>
Message-ID: <7f692fec0711201214r5f970333q948a4f224f4bbd96@mail.gmail.com>

On 11/20/07, Andrew Farris <lordmorgul at gmail.com> wrote:
> Christopher Aillon wrote:
> >
> > gconftool-2 --recursive-unset /system/networking
> >
>
> Wouldn't it be a good idea to provide this type of NM full state reset from the
> applet itself?  To the casual user the only thing visible IS the applet, and
> when its not working the applet should provide a possible answer.

I would rather be able to delete specific networks from nm-applet, as
knetworkmanager has.  A handy dandy 'clear all' button in that same
dialog would be helpful too.  I know the NM people have been throwing
around a few ideas though.

-Yaakov



From notting at redhat.com  Tue Nov 20 20:14:55 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Nov 2007 15:14:55 -0500
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <1195589302.4552.40.camel@localhost.localdomain>
References: <20071120190204.GA32542@nostromo.devel.redhat.com>
	<20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
	<20071120195030.GA3431@nostromo.devel.redhat.com>
	<1195588508.4552.33.camel@localhost.localdomain>
	<20071120200133.GA3651@nostromo.devel.redhat.com>
	<1195589302.4552.40.camel@localhost.localdomain>
Message-ID: <20071120201455.GB3651@nostromo.devel.redhat.com>

Jeremy Katz (katzj at redhat.com) said: 
> Realistically, you probably want the simple stupid plugin to allow you
> to set the release version if you go this route.  But at the same time,
> I don't think that the route of switching streams often is really a case
> that you optimize for.

Moreover, if you do the $releasever redirect hack, someone who has
updates/updates-testing either gets errors or the same repo three times.

Bill



From jspaleta at gmail.com  Tue Nov 20 20:15:19 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 20 Nov 2007 11:15:19 -0900
Subject: NetworkManager - Why Doesn't nm-applet have a way of using
	WPA-PSK?
In-Reply-To: <47433E0B.2000907@gmail.com>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <4742E64B.1030404@draigBrady.com>
	<4742E974.1030603@redhat.com> <47433E0B.2000907@gmail.com>
Message-ID: <604aa7910711201215q42645a35x44da7ac86998f6f3@mail.gmail.com>

On Nov 20, 2007 11:05 AM, Andrew Farris <lordmorgul at gmail.com> wrote:
> Wouldn't it be a good idea to provide this type of NM full state reset from the
> applet itself?  To the casual user the only thing visible IS the applet, and
> when its not working the applet should provide a possible answer.

Icon: Toilet Bowl
Context Menu Entry Text : Flush Networks
Tooltip: Press here to obliterate all cached information concerning
previously used wireless networks

-jef"Can we get pulseaudio to make the flushing sound that gets played
when you use this menu item to bounce back and forth between your
quadraphonic speakers such that the sound spins around you
counter-clockwise if you are in the northern hemisphere and clockwise
if you are in the souther hemisphere?"spaleta



From pertusus at free.fr  Tue Nov 20 20:14:33 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 20 Nov 2007 21:14:33 +0100
Subject: AWOL: jpo
In-Reply-To: <1195574488.27963.27.camel@localhost.localdomain>
References: <1195574488.27963.27.camel@localhost.localdomain>
Message-ID: <20071120201433.GC2573@free.fr>

On Tue, Nov 20, 2007 at 11:01:28AM -0500, Tom spot Callaway wrote:
> It seems that Jose Pedro Oliveira (aka jpo) is not coming back to
> Fedora. 

That's really unfortunate, I hope he'll come back at some point.

--
Pat



From triad at df.lth.se  Tue Nov 20 20:50:32 2007
From: triad at df.lth.se (Linus Walleij)
Date: Tue, 20 Nov 2007 21:50:32 +0100 (CET)
Subject: libgpod soname bump coming to rawhide
In-Reply-To: <20071120172929.GB2967@psilocybe.teonanacatl.org>
References: <20071120172929.GB2967@psilocybe.teonanacatl.org>
Message-ID: <Pine.GSO.4.60.0711202146001.10992@igloo.df.lth.se>

On Tue, 20 Nov 2007, Todd Zullinger wrote:

> This is definitely something I think warrants an update for F-8 and
> F-7 after stewing in rawhide for a week or so.

I agree. Please, this time (as we're rebuilding Amarok) let's sync it with 
the imminent update of libmtp soname found in 
https://bugzilla.redhat.com/show_bug.cgi?id=359401
if you have a BZ ticket for libgpod then reference this to the libmtp 
update please.

> While the library soname has been bumped, the changes are not very
> invasive and none of the apps using libgpod need more than a
> recompile.

libmtp is the same. Just recompile.

> The alternative is to tell users that they'll have to wait until
> spring to support iPod models that have been out since last spring and
> (and will have been supported in other distros for many months by that
> point).

No no no.... as mentioned for libmtp we WANT to support the latest and 
greatest hardware. It is worth soname breakage.

> Are there any objections to this plan?

Nope.

Linus



From lkundrak at redhat.com  Tue Nov 20 20:56:29 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 20 Nov 2007 21:56:29 +0100
Subject: Smolt database is broken
In-Reply-To: <7f692fec0711201045h7eda18efq27d392b389c3ddf4@mail.gmail.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<4742E2C1.1010006@redhat.com>
	<7f692fec0711201045h7eda18efq27d392b389c3ddf4@mail.gmail.com>
Message-ID: <1195592189.3568.100.camel@localhost.localdomain>


On Tue, 2007-11-20 at 13:45 -0500, Yaakov Nemoy wrote:
> On 11/20/07, Christopher Aillon <caillon at redhat.com> wrote:
> > I agree we should track this down in the kernel.  But even so, it is
> > theoretically possible for the same UUID to come up multiple times.
> > Shouldn't we be generating UUIDs on the smolt server itself and letting
> > the client know what the UUID is, to better protect against duplicates?
> 
> I would rather have proper UUID generation.  Such a feature, while
> technically more correct, would be slightly harder to make sure the
> server can handle both the old and new method.
> 
> Besides, if we focus our efforts on proper UUID generation, then other
> projects will benefit as well.

But in smolt we also track what versions of kernel do people use. Or we
don't want to track installations with older kernels?

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From alan at redhat.com  Tue Nov 20 21:04:17 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 20 Nov 2007 16:04:17 -0500
Subject: Smolt database is broken
In-Reply-To: <474334BB.1080002@redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<474334BB.1080002@redhat.com>
Message-ID: <20071120210417.GA29466@devserv.devel.redhat.com>

On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath wrote:
> Here's the top 5:
> 
>    266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
>    336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a
>    402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
>    884 06e84493-e024-44b1-9b32-32d78af04039
>    931 e2b67e1d-e325-4740-b938-795addb45280
> 
> 
> The left number is times this month someone has submitted a profile with 
> that UUID.  If we take the last one as an example has come from over 800 
> IP's in the last 20 days.  It seems very unlikely that one person would 
> find his way to 800 different IP's this month.  Let me know if you'd 
> like more.

We shouldn't have any duplicates if its properly random. I don't know how
relevant the actual values are myself because random numbers is "hard maths"
and I'm not a mathematician. I've raised it however but since its turkey
genoiciding season in the USA it might be a bit slow




From katzj at redhat.com  Tue Nov 20 21:08:38 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 20 Nov 2007 16:08:38 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <364d303b0711200902n7b058bd1lb6c704eab723bee2@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr> <20071120102334.6dfc4150@redhat.com>
	<20071120152829.GD2558@free.fr> <20071120103532.6dfcc8c6@redhat.com>
	<1195575649.10878.205.camel@cookie.hadess.net>
	<20071120112410.0b1e775d@redhat.com>
	<364d303b0711200902n7b058bd1lb6c704eab723bee2@mail.gmail.com>
Message-ID: <1195592918.4552.55.camel@localhost.localdomain>

On Tue, 2007-11-20 at 17:02 +0000, Christopher Brown wrote:
> as I have to agree the Big Red Message is a bit ... stark.
> 
> No, I realise this won't resolve the issue at hand but would be
> appreciated by others who may come across this in future.

Thanks for the suggestion -- I've forwarded it along to those who run
the bugzilla installation and they're working on improving the wording
and look of this case.

Jeremy



From jspaleta at gmail.com  Tue Nov 20 21:29:05 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 20 Nov 2007 12:29:05 -0900
Subject: libgpod soname bump coming to rawhide
In-Reply-To: <20071120172929.GB2967@psilocybe.teonanacatl.org>
References: <20071120172929.GB2967@psilocybe.teonanacatl.org>
Message-ID: <604aa7910711201329p57535fa6u14f0acf30e0996f5@mail.gmail.com>

On Nov 20, 2007 8:29 AM, Todd Zullinger <tmz at pobox.com> wrote:
> libgpod 0.6.0 was released a week or so ago.  This release supports
> the newer iPod models (iPhone, iTouch, Classics, and "Fat" Nanos).
> I'd like to push this into rawhide tomorrow and let it get some
> testing.  I'll rebuild amarok, gtkpod, kipi-plugins, and rhythmbox at
> the same time.

You are rebuilding python-gpod as well right?

-jef



From warren at togami.com  Tue Nov 20 21:33:44 2007
From: warren at togami.com (Warren Togami)
Date: Tue, 20 Nov 2007 16:33:44 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <20071120095551.57305902@redhat.com>
References: <47420B80.9070001@redhat.com>	<1195511355.27963.1.camel@localhost.localdomain>	<4742106E.50305@redhat.com>	<1195512172.27963.3.camel@localhost.localdomain>	<47421500.2040807@redhat.com>
	<20071120075202.78de1855@redhat.com>	<4742F0C1.1050902@redhat.com>
	<20071120095551.57305902@redhat.com>
Message-ID: <474352B8.1050609@togami.com>

Jesse Keating wrote:
> On Tue, 20 Nov 2007 09:35:45 -0500
> Warren Togami <wtogami at redhat.com> wrote:
> 
>> It isn't just for existing contributors.  It has potential benefits
>> to aid the workflow of existing contributors (central location and
>> same tools as post-review).  The other key benefit would be for new 
>> contributors who use the tools for the first time.  It would be great
>> to provide them a very similar work area to how they will be
>> maintaining their package after the review.
> 
> But you said earlier it would be for existing contributors...
> 
> 

You did not read the initial mail carefully.

Warren Togami
wtogami at redhat.com



From wtogami at redhat.com  Tue Nov 20 21:40:24 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Nov 2007 16:40:24 -0500
Subject: InstantMirror Proposal Re: ApacheMirror.py for a
 site-local	Fedora mirror
In-Reply-To: <e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>	<4742524F.2010705@redhat.com>
	<e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>
Message-ID: <47435448.3060001@redhat.com>

Ed Swierk wrote:
> 
>> I didn't read deeply into your code yet, but I imagine that it needs
>> improvement to handle unique synchronization and expiration issues that
>> yum repos and rawhide install trees create when file contents change
>> without changing filenames.
> 
> If a requested file already exists in the local mirror, the handler
> compares the Last-Modified time of the upstream file with the local
> file, and downloads the file if the upstream version is newer. I'm not
> familiar with rawhide, but this seems to work okay for the updates
> repos where metadata files are frequently regenerated. It doesn't
> remove files that no longer exist upstream, of course.

Ah, this works great as an initial implementation.  We can at least have 
something that works before we make it more efficient (and less 
unfriendly in hitting the upstream server too many times).

> 
>> That daemon could be configured to handle intelligent expiry of various
>> parts of the mirror tree in different ways.  For example:
>> - development (rawhide) repo changes at least once per day.  It also
>> contains install images (boot.iso, bootdisk.img, stage2, etc.) that need
>> to be expired every time the tree changes.  (We might need to add a
>> hashes file to the mirror tree to allow the tool to monitor these changes.)
>> - Released distros never change, so don't need to monitor their
>> repomd.xml for changes.
> 
> An even simpler approach is to have the daemon iterate through every
> local file, checking whether the file exists upstream and deleting the
> local copy if it doesn't. This requres no repodata parsing, but
> flooding the upstream server with HEAD requests might be considered
> unfriendly.

Why don't we implement the unfriendly approach first because we can get 
that out quickly.  That way people can have something to run while we 
work on the proper version that substantially reduces the number of hits 
to the upstream server.

Warren Togami
wtogami at redhat.com



From jeff at ocjtech.us  Tue Nov 20 21:57:45 2007
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Tue, 20 Nov 2007 15:57:45 -0600
Subject: InstantMirror Proposal Re: ApacheMirror.py for a site-local
	Fedora mirror
In-Reply-To: <e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>
	<4742524F.2010705@redhat.com>
	<e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>
Message-ID: <935ead450711201357k7467fdd4y6e3de3041bce4e51@mail.gmail.com>

On 11/20/07, Ed Swierk <eswierk at arastra.com> wrote:
>
> > Later add configurable fallbacks to a different upstream if
> > download.fp.org is down.  mirrors.kernel.org might be a good alternative
> > for default, for example.
>
> Yes, it would be easy to configure a list of upstream servers instead
> of a single one, and hit them either in priority order or randomly.

Why not use the mirrorlist? E.g.:

http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=i386

Jeff



From simonb at thoughtpolice.co.uk  Tue Nov 20 22:01:42 2007
From: simonb at thoughtpolice.co.uk (Simon B)
Date: Tue, 20 Nov 2007 23:01:42 +0100
Subject: Orphaning package: fdupes
Message-ID: <1195596102.2785.12.camel@sb-home>

Hello,

fdupes is a program that identifies and optionally deletes duplicate
files. It's a nice program, but due to other commitments I am orphaning
it.

Hopefully someone else can look after it :)

Simon



From ssorce at redhat.com  Tue Nov 20 22:20:17 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 20 Nov 2007 22:20:17 +0000
Subject: Smolt database is broken
In-Reply-To: <20071120210417.GA29466@devserv.devel.redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<474334BB.1080002@redhat.com>
	<20071120210417.GA29466@devserv.devel.redhat.com>
Message-ID: <1195597217.2587.115.camel@localhost.localdomain>

On Tue, 2007-11-20 at 16:04 -0500, Alan Cox wrote:
> On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath wrote:
> > Here's the top 5:
> > 
> >    266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
> >    336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a
> >    402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
> >    884 06e84493-e024-44b1-9b32-32d78af04039
> >    931 e2b67e1d-e325-4740-b938-795addb45280
> > 
> > 
> > The left number is times this month someone has submitted a profile with 
> > that UUID.  If we take the last one as an example has come from over 800 
> > IP's in the last 20 days.  It seems very unlikely that one person would 
> > find his way to 800 different IP's this month.  Let me know if you'd 
> > like more.
> 
> We shouldn't have any duplicates if its properly random. I don't know how
> relevant the actual values are myself because random numbers is "hard maths"
> and I'm not a mathematician. I've raised it however but since its turkey
> genoiciding season in the USA it might be a bit slow

Is rfc4122 being used ?
http://www.ietf.org/rfc/rfc4122.txt

-- 
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |



From ssorce at redhat.com  Tue Nov 20 22:20:17 2007
From: ssorce at redhat.com (Simo Sorce)
Date: Tue, 20 Nov 2007 22:20:17 +0000
Subject: Smolt database is broken
In-Reply-To: <20071120210417.GA29466@devserv.devel.redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<474334BB.1080002@redhat.com>
	<20071120210417.GA29466@devserv.devel.redhat.com>
Message-ID: <1195597217.2587.115.camel@localhost.localdomain>

On Tue, 2007-11-20 at 16:04 -0500, Alan Cox wrote:
> On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath wrote:
> > Here's the top 5:
> > 
> >    266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
> >    336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a
> >    402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
> >    884 06e84493-e024-44b1-9b32-32d78af04039
> >    931 e2b67e1d-e325-4740-b938-795addb45280
> > 
> > 
> > The left number is times this month someone has submitted a profile with 
> > that UUID.  If we take the last one as an example has come from over 800 
> > IP's in the last 20 days.  It seems very unlikely that one person would 
> > find his way to 800 different IP's this month.  Let me know if you'd 
> > like more.
> 
> We shouldn't have any duplicates if its properly random. I don't know how
> relevant the actual values are myself because random numbers is "hard maths"
> and I'm not a mathematician. I've raised it however but since its turkey
> genoiciding season in the USA it might be a bit slow

Is rfc4122 being used ?
http://www.ietf.org/rfc/rfc4122.txt

-- 
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |



From jon at fedoraunity.org  Tue Nov 20 22:31:46 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Tue, 20 Nov 2007 15:31:46 -0700
Subject: InstantMirror Proposal Re: ApacheMirror.py for a
 site-local	Fedora mirror
In-Reply-To: <935ead450711201357k7467fdd4y6e3de3041bce4e51@mail.gmail.com>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>	<4742524F.2010705@redhat.com>	<e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>
	<935ead450711201357k7467fdd4y6e3de3041bce4e51@mail.gmail.com>
Message-ID: <47436052.70400@fedoraunity.org>

Fedora Unity currently has a hack of a solution using a modified Yam. I
like the idea of an instant mirror that doesn't have to be pre-synced
but there are some use cases where having the full mirror local is useful.

http://damaestro.us/Members/jon/repo_sync-0.2-1.src.rpm

It still needs a lot of work. We (Fedora Unity) were planning on adding
a hosted projected called 'reflector'. Maybe these two efforts should
join forces?


-- 
Jonathan Steffan
daMaestro
Fedora Unity - http://fedoraunity.org/
GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59



From jon at fedoraunity.org  Tue Nov 20 22:33:52 2007
From: jon at fedoraunity.org (Jonathan Steffan)
Date: Tue, 20 Nov 2007 15:33:52 -0700
Subject: InstantMirror Proposal Re: ApacheMirror.py for a
 site-local	Fedora mirror
In-Reply-To: <47436052.70400@fedoraunity.org>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>	<4742524F.2010705@redhat.com>	<e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>	<935ead450711201357k7467fdd4y6e3de3041bce4e51@mail.gmail.com>
	<47436052.70400@fedoraunity.org>
Message-ID: <474360D0.5050104@fedoraunity.org>

Jonathan Steffan wrote:
> Fedora Unity currently has a hack of a solution using a modified Yam. I
> like the idea of an instant mirror that doesn't have to be pre-synced
> but there are some use cases where having the full mirror local is useful.
> 
> http://damaestro.us/Members/jon/repo_sync-0.2-1.src.rpm
> 
> It still needs a lot of work. We (Fedora Unity) were planning on adding
> a hosted projected called 'reflector'. Maybe these two efforts should
> join forces?
> 
> 

Example Configs:
http://damaestro.us/Members/jon/configs.tar.gz


-- 
Jonathan Steffan
daMaestro
Fedora Unity - http://fedoraunity.org/
GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59



From alan at redhat.com  Tue Nov 20 22:35:42 2007
From: alan at redhat.com (Alan Cox)
Date: Tue, 20 Nov 2007 17:35:42 -0500
Subject: Smolt database is broken
In-Reply-To: <1195597217.2587.115.camel@localhost.localdomain>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<474334BB.1080002@redhat.com>
	<20071120210417.GA29466@devserv.devel.redhat.com>
	<1195597217.2587.115.camel@localhost.localdomain>
Message-ID: <20071120223542.GA2659@devserv.devel.redhat.com>

On Tue, Nov 20, 2007 at 10:20:17PM +0000, Simo Sorce wrote:
> Is rfc4122 being used ?
> http://www.ietf.org/rfc/rfc4122.txt

Yes - for randomly generated.



From wtogami at redhat.com  Tue Nov 20 22:57:25 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Nov 2007 17:57:25 -0500
Subject: InstantMirror Proposal Re: ApacheMirror.py for a
 site-local	Fedora mirror
In-Reply-To: <47436052.70400@fedoraunity.org>
References: <e6c711510711191819j5eee657fmad25e8cc621ede4c@mail.gmail.com>	<4742524F.2010705@redhat.com>	<e6c711510711200821ie2808cfyccfc4ac15b54ba56@mail.gmail.com>	<935ead450711201357k7467fdd4y6e3de3041bce4e51@mail.gmail.com>
	<47436052.70400@fedoraunity.org>
Message-ID: <47436655.9040304@redhat.com>

Jonathan Steffan wrote:
> Fedora Unity currently has a hack of a solution using a modified Yam. I
> like the idea of an instant mirror that doesn't have to be pre-synced
> but there are some use cases where having the full mirror local is useful.
> 
> http://damaestro.us/Members/jon/repo_sync-0.2-1.src.rpm
> 
> It still needs a lot of work. We (Fedora Unity) were planning on adding
> a hosted projected called 'reflector'. Maybe these two efforts should
> join forces?
> 
> 

I took a quick look at your code.  It seems that you have yet another 
implementation of an rsync wrapper that everyone seems to write for to 
manage their own mirror server.  It would be good to make this into a 
proper upstream project and to have people collaborate on it.  This 
however is an entirely different use-case than the proposed 
InstantMirror project.

You would use reflector to populate a traditional mirror, while 
InstantMirror operates as a proxy cache mirror.  I suppose the two could 
optionally work together to pre-populate the InstantMirror cache 
directories, but these are two distinctly different projects.

Warren Togami
wtogami at redhat.com



From besfahbo at redhat.com  Tue Nov 20 23:27:46 2007
From: besfahbo at redhat.com (Behdad Esfahbod)
Date: Tue, 20 Nov 2007 18:27:46 -0500
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
	F-8]
In-Reply-To: <4742CEE0.7020703@hhs.nl>
References: <38743.192.54.193.53.1195556105.squirrel@rousalka.dyndns.org>
	<4742CEE0.7020703@hhs.nl>
Message-ID: <1195601266.14617.5.camel@home.behdad.org>

On Tue, 2007-11-20 at 13:11 +0100, Hans de Goede wrote:
> 
> 2) The gtk-update-icon-cache way, so conditionally run mkfontdir and friends
>     from scripts, if installed. And on installation of mkfontdir, run it for all
>     dirs under /etc/X11/fontpath.d

This is what we do for fontconfig caches too.  From DejaVu:


%post
if [ -x %{_bindir}/fc-cache ]; then
  %{_bindir}/fc-cache %{fontdir}
fi


%postun
if [ "$1" = "0" ]; then
  if [ -x %{_bindir}/fc-cache ]; then
    %{_bindir}/fc-cache %{fontdir}
  fi
fi


%post experimental
if [ -x %{_bindir}/fc-cache ]; then
  %{_bindir}/fc-cache %{fontdir}
fi


%postun experimental
if [ "$1" = "0" ]; then
  if [ -x %{_bindir}/fc-cache ]; then
    %{_bindir}/fc-cache %{fontdir}
  fi
fi


%post -n %{fontname}-lgc-fonts
if [ -x %{_bindir}/fc-cache ]; then
  %{_bindir}/fc-cache %{fontdir}
fi


%postun -n %{fontname}-lgc-fonts
if [ "$1" = "0" ]; then
  if [ -x %{_bindir}/fc-cache ]; then
    %{_bindir}/fc-cache %{fontdir}
  fi
fi



Just go ahead and add similar bits for X core protocol fonts to the font
SIG spec template (after passing through Nicolas that is), but make it
clear that no new packages should add those bits.  Only fonts that used
to have them should now do it like this.

And all font packages should be cleans of ghost font-cache.1 files, yes.

-- 
behdad
http://behdad.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/9327497d/attachment.sig>

From Michael_E_Brown at dell.com  Tue Nov 20 23:28:40 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Tue, 20 Nov 2007 17:28:40 -0600
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120201455.GB3651@nostromo.devel.redhat.com>
References: <20071120140617.6a3bd1c1@redhat.com>
	<20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
	<20071120195030.GA3431@nostromo.devel.redhat.com>
	<1195588508.4552.33.camel@localhost.localdomain>
	<20071120200133.GA3651@nostromo.devel.redhat.com>
	<1195589302.4552.40.camel@localhost.localdomain>
	<20071120201455.GB3651@nostromo.devel.redhat.com>
Message-ID: <20071120232840.GN16195@humbolt.us.dell.com>

On Tue, Nov 20, 2007 at 03:14:55PM -0500, Bill Nottingham wrote:
> Jeremy Katz (katzj at redhat.com) said: 
> > Realistically, you probably want the simple stupid plugin to allow you
> > to set the release version if you go this route.  But at the same time,
> > I don't think that the route of switching streams often is really a case
> > that you optimize for.
> 
> Moreover, if you do the $releasever redirect hack, someone who has
> updates/updates-testing either gets errors or the same repo three times.

Actually, I dont understand why we dont have a "repo=stable", and
"repo=rawhide". Mirrormanager can be trivially extended to let you flip
'stable' repo to the next release a predefined amount of time after that
release.

Then people who always want latest stable will automatically be upgraded
to the next ver when it comes out, while people who want to stay on a specific
release can say "repo=fedora-$releasever"

For rawhide, make releasever=9 and have mirrormanager redirect it to
rawhide.

So, we have (defaults):

rpm name: fedora-release-9-1.prerelease.noarch.rpm
fedora.repo:              repo=stable, enabled=0
fedora-development.repo:  repo=rawhide, enabled=1

rpm name: fedora-release-9-1.noarch.rpm
fedora.repo:              repo=stable, enabled=1
fedora-development.repo:  repo=rawhide, enabled=0

People who want to track rawhide use --enablerepo. People who want to
lock down to a specific release can s/stable/fedora-$releasever/. 

Or, alternatively, lock it down to a specific release by default, but
let people change it to 'stable' if they want.
--
Michael



From caillon at redhat.com  Tue Nov 20 23:33:16 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 21 Nov 2007 00:33:16 +0100
Subject: FESCo Meeting Summary for 2007-11-19
In-Reply-To: <1195515271.13194.4.camel@nixon>
References: <1195515271.13194.4.camel@nixon>
Message-ID: <47436EBC.6020709@redhat.com>

On 11/20/2007 12:34 AM, Brian Pepple wrote:

> = Summary =

> = PPC in F9+ =
>       * FESCo approved a proposal for the build system bits to remain
>         the same, but the QA & Release Engineering processed will be
>         done by the PPC team. 
>         
>       * Votes 
>               * For: dgilmore, c4chris, bpepple, jeremy, tibbs, nirik,
>                 warren, spot, dwmw2, notting 
>               * Against: None 
>               * Abstain: jwb 

For the record, I'm also for this.


> 
> = Using mdomsch's rebuild scripts to find AWOL contributors =
>       * Long discussion on possible solutions on finding AWOL
>         contributors. For more details, please refer to the IRC log. 

Honestly, I feel the term "AWOL" seems somewhat inappropriate to use for 
volunteer contributors... "MIA" might be better, though "non-responsive" 
seems most accurate.  :-)



From paul at all-the-johnsons.co.uk  Tue Nov 20 23:46:54 2007
From: paul at all-the-johnsons.co.uk (Paul)
Date: Tue, 20 Nov 2007 23:46:54 +0000
Subject: Mono on ppc and ppc64`1
Message-ID: <1195602414.5092.19.camel@T7.Linux>

Hi,

Does anyone have a list of problems why mono fails to build on these
platforms? I've a number of packages which fail because of mono problems
on the architecture.

TTFN

Paul
-- 
Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/7bc30ec5/attachment.sig>

From bnocera at redhat.com  Wed Nov 21 00:01:36 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 21 Nov 2007 00:01:36 +0000
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120112410.0b1e775d@redhat.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<20071120145349.GB2558@free.fr> <20071120102334.6dfc4150@redhat.com>
	<20071120152829.GD2558@free.fr> <20071120103532.6dfcc8c6@redhat.com>
	<1195575649.10878.205.camel@cookie.hadess.net>
	<20071120112410.0b1e775d@redhat.com>
Message-ID: <1195603296.10878.229.camel@cookie.hadess.net>


On Tue, 2007-11-20 at 11:24 -0500, Jesse Keating wrote:
> On Tue, 20 Nov 2007 16:20:49 +0000
> Bastien Nocera <bnocera at redhat.com> wrote:
> 
> > Jesse, if you'd be so kind to mention that to the people from the
> > Software Engineering Group, the internal support tools don't help
> > there.
> > 
> > I've been barking up that tree for more than 3 years, didn't seem to
> > get much more movement than "you're right"...
> 
> Well, the problem is I don't have good suggestions on how to fix it.

I'll take the suggestions off-list, they're not that interesting for
people who don't know the internal tools :)



From ml at deadbabylon.de  Wed Nov 21 00:30:24 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Wed, 21 Nov 2007 01:30:24 +0100
Subject: KDE-SIG weekly report (47/2007)
Message-ID: <200711210130.28346.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
 to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 47/2007

Time: 2007-11-20 16:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-20

Meeting log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-20?action=AttachFile&do=get&target=fedora-kde-sig-2007-11-20.txt

----------------------------------------------------------------------------------

= Participants =

- RexDieter 
- KevinKofler 
- ThanNgo 
- SebastianVahl 
- ArthurPemberton
- MaryEllenFoster

----------------------------------------------------------------------------------

= Agenda =

* The weekly talk about KDE4 
 * Preparations for KDE4: Initial Builds 
 * Needed but not yet included BuildRequires (eg. libzip, decibel) 
 * Preparations of kdelibs3, kdebase3 
 * Planning of inclusion in Rawhide 
 * Informations for Package Maintainers (BR: kdelibs -> kdelibs3, building 
packages for KDE4)

= Summary = 

o Preparations for KDE4:Initial Builds: 
- The KDE4 Development Platform was updated to 3.96.0 
- SebastianVahl has worked on KDE 4 full desktop packages (KDE 4 as default 
and kdebase-workspace packaged). [1] This packages doesn't exist in rawhide, 
yet. 
- New kdeartwork-icons contains crystalsvg-icon-theme. We'll need to verify if 
it's complete and usuable for KDE3 applications as a fallback. Otherwise 
we'll need to ship the KDE3 version instead. 

o Preparations of kdelibs3, kdebase3: 
- Initial version of non-conflicting kdelibs3 is done, version for kdebase3 
will be prepared. 
- both versions needs to be re-checked if removed files still really conflict. 

o Needed but not yet included BuildRequires: 
- libzip (dependency of kdeutils) will be submitted for review 
- decibel (optional dependency for kdenetwork) isn't packaged yet 
- Tapioca-Qt (for decibel) isn't packaged yet 
- tpctl (optional dependency of kdeutils) isn't packaged yet 

o Planning of inclusion in Rawhide: 
- kdebase-workspace as a new package needs to be reviewed 
- the other packages won't need a formal review 
- kdelibs(4), kdebase(4), kdebase-runtime, kdebase-workspace and kdelibs3, 
kdebase3 needs to be updated in rawhide in a short timeframe 
- Dec 1-7 was choosen as a window of the inclusion in rawhide 
- We'll need to send out a notice to the mailing lists that KDE may be 
unstable 
- package maintainers also needs to be informed about the changed build 
requires 
- RexDieter will prepare this announcements

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-27

----------------------------------------------------------------------------------

= Links =

[1] http://fedoraproject.org/wiki/SIGs/KDE/KDE4Status
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/8b5679b1/attachment.sig>

From wart at kobold.org  Wed Nov 21 01:25:20 2007
From: wart at kobold.org (Michael Thomas)
Date: Tue, 20 Nov 2007 17:25:20 -0800
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <47421B35.4080006@redhat.com>
References: <47421B35.4080006@redhat.com>
Message-ID: <47438900.4000308@kobold.org>

Warren Togami wrote:
> Fedora Engineering Steering Committee is considering removal of packages
> from rawhide who have been without owners since prior to Fedora 8
> sometime after the next FESCO meeting on November 29th.  The Fedora
> Project routinely removes unmaintained packages from future
> distributions in order to responsibly scale the growth of maintenance
> burden with developer resources available within the project.
> 
> http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
> Packages listed on this page are scheduled for removal unless an
> existing Fedora maintainer claims ownership.
[...]

I already claimed tcl-thread when the previous owner announced it was
being orphaned, but never got around to changing the ownership.  Doing
so now...

--Wart



From alexl at users.sourceforge.net  Wed Nov 21 01:31:06 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Tue, 20 Nov 2007 18:31:06 -0700
Subject: XULRunner in rawhide
In-Reply-To: <473D6760.4050609@redhat.com> (Martin Stransky's message of "Fri\,
	16 Nov 2007 10\:48\:16 +0100")
References: <473AFF3E.1090904@redhat.com>
	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
	<473C85A5.9020100@redhat.com>
	<ld4uattp4.fsf@allele2.eebweb.arizona.edu>
	<473D6760.4050609@redhat.com>
Message-ID: <afoddoo04l.fsf@allele2.eebweb.arizona.edu>

>>>>> "MS" == Martin Stransky  writes:

MS> Alex Lancaster wrote:
>> Traceback (most recent call last): File "setup.py", line 262, in
>> <module> raise ValueError("Can't find mozilla include base
>> directory") ValueError: Can't find mozilla include base directory
>> 
>> Full log here:
>> 
>> http://koji.fedoraproject.org/koji/getfile?taskID=244635&name=build.log

MS> I'll check it locally, looks like some misconfiguration...

Martin,

I retried with the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9
thinking that maybe the new xulrunner would fix this but I get the
same thing:

http://koji.fedoraproject.org/koji/getfile?taskID=252253&name=build.log

here's the task:

http://koji.fedoraproject.org/koji/taskinfo?taskID=252253

Alex



From debarshi.ray at gmail.com  Wed Nov 21 02:30:48 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 21 Nov 2007 08:00:48 +0530
Subject: Orphaning package: fdupes
In-Reply-To: <1195596102.2785.12.camel@sb-home>
References: <1195596102.2785.12.camel@sb-home>
Message-ID: <3170f42f0711201830k10bdce37v176e20fab958f90d@mail.gmail.com>

Looks interesting. I will take it.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From poelstra at redhat.com  Wed Nov 21 05:45:42 2007
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 20 Nov 2007 21:45:42 -0800
Subject: Fedora Rel-Eng Meeting Recap 2007-NOV-19
Message-ID: <4743C606.2030605@redhat.com>


Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19

Please make corrections and clarifications to the wiki page.

== Topics Discussed ==
  * Releasing Fedora 9 on CD--up to the Fedora Board to decide what they 
want
  * Enabling Jigdo
    * http://fedoraproject.org/wiki/Features/JigdoRelease
    * create and host templates outside of Fedora for now
    * if in time there is enough demand, possibly add to compose process

== IRC Transcript== 




From wtogami at redhat.com  Wed Nov 21 05:53:19 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 21 Nov 2007 00:53:19 -0500
Subject: InstantMirror initial source repo
Message-ID: <4743C7CF.4000904@redhat.com>

bzr branch http://fedorapeople.org/~wtogami/temp/InstantMirror/
It will be located here until the official hosted repository is created.

cd InstantMirror
./mkdist --force
rpmbuild -ta /tmp/InstantMirror-0.1.tar.bz2
rpm -ivh /path/to/InstantMirror-0.1.noarch.rpm
vim /etc/httpd/conf.d/InstantMirror.conf
service httpd restart (will probably fail due to SELinux denial)

Unfortunately, I discovered that the ApacheMirror.py (renamed 
InstantMirror.py in this repo) has a critical bug that makes it unusable 
in current form.  From the TODO file:

BUGS TO FIX TO MAKE IT ACTUALLY WORK
- wget --server-response http://PATH/TO/LARGE/FILE
   It constantly redirects over and over again rather than waiting.
   FILE.tmp never gets larger than 8192 or 16384 bytes.
- We MUST find a way so the client can begin downloading the file while 
the mirror downloads the file.  Any other reverse proxy server would 
allow this.  This might be difficult to implement (perhaps impossible 
with mod_python?) but this might be the only sane way to fix the 
previous problem.
- Even if apache:apache owns DocumentRoot, SELinux denies by default.
   Need sane solution.

Warren Togami
wtogami at redhat.com



From j.w.r.degoede at hhs.nl  Wed Nov 21 06:20:01 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 21 Nov 2007 07:20:01 +0100
Subject: [Fwd: Font issues (mkfontdir & friends not getting run) with
 F-8]
In-Reply-To: <1195601266.14617.5.camel@home.behdad.org>
References: <38743.192.54.193.53.1195556105.squirrel@rousalka.dyndns.org>	<4742CEE0.7020703@hhs.nl>
	<1195601266.14617.5.camel@home.behdad.org>
Message-ID: <4743CE11.1010806@hhs.nl>

Behdad Esfahbod wrote:
> On Tue, 2007-11-20 at 13:11 +0100, Hans de Goede wrote:
>> 2) The gtk-update-icon-cache way, so conditionally run mkfontdir and friends
>>     from scripts, if installed. And on installation of mkfontdir, run it for all
>>     dirs under /etc/X11/fontpath.d
> 
> This is what we do for fontconfig caches too.  From DejaVu:
> 
> 
> %post
> if [ -x %{_bindir}/fc-cache ]; then
>   %{_bindir}/fc-cache %{fontdir}
> fi
> 
> 
> %postun
> if [ "$1" = "0" ]; then
>   if [ -x %{_bindir}/fc-cache ]; then
>     %{_bindir}/fc-cache %{fontdir}
>   fi
> fi
> 
> 
> %post experimental
> if [ -x %{_bindir}/fc-cache ]; then
>   %{_bindir}/fc-cache %{fontdir}
> fi
> 
> 
> %postun experimental
> if [ "$1" = "0" ]; then
>   if [ -x %{_bindir}/fc-cache ]; then
>     %{_bindir}/fc-cache %{fontdir}
>   fi
> fi
> 
> 
> %post -n %{fontname}-lgc-fonts
> if [ -x %{_bindir}/fc-cache ]; then
>   %{_bindir}/fc-cache %{fontdir}
> fi
> 
> 
> %postun -n %{fontname}-lgc-fonts
> if [ "$1" = "0" ]; then
>   if [ -x %{_bindir}/fc-cache ]; then
>     %{_bindir}/fc-cache %{fontdir}
>   fi
> fi
> 
> 
> 
> Just go ahead and add similar bits for X core protocol fonts to the font
> SIG spec template (after passing through Nicolas that is), but make it
> clear that no new packages should add those bits.  Only fonts that used
> to have them should now do it like this.
> 

Thats possible, but then the mkfontdir packages needs a post to run 
mkfontdir on all dirs under /etc/X11/fontpath.d upon install, as it may 
be installed later then some fonts, and core fonts using apps / libs 
need to require mkfontdir. So IMHO just carrying pre generated fonts.dir 
and fonts.scale files in the affected font packages is much better, but 
according to some this _may_ have issues, but no one knows what issues 
it seems and I cannot think of any issues.


> And all font packages should be cleans of ghost font-cache.1 files, yes.
> 

That I fully agree on.

Regards,

Hans



From eswierk at arastra.com  Wed Nov 21 07:23:49 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Tue, 20 Nov 2007 23:23:49 -0800
Subject: InstantMirror initial source repo
In-Reply-To: <4743C7CF.4000904@redhat.com>
References: <4743C7CF.4000904@redhat.com>
Message-ID: <e6c711510711202323s1b8bbbc2rdbd7d95906bbff58@mail.gmail.com>

On 11/20/07, Warren Togami <wtogami at redhat.com> wrote:
> BUGS TO FIX TO MAKE IT ACTUALLY WORK
> - wget --server-response http://PATH/TO/LARGE/FILE
>   It constantly redirects over and over again rather than waiting.
>   FILE.tmp never gets larger than 8192 or 16384 bytes.

Hmm, my setup doesn't do that. What upstream server are you using, and
which release of Fedora? I am running it on an FC6 machine, using
http://linux.nssl.noaa.gov .

> - We MUST find a way so the client can begin downloading the file while
> the mirror downloads the file.  Any other reverse proxy server would
> allow this.  This might be difficult to implement (perhaps impossible
> with mod_python?) but this might be the only sane way to fix the
> previous problem.

I don't think this has anything to do with the problem above. This
would be a nice enhancement, though. It does complicate the
implementation, especially to handle byte range requests properly.

> - Even if apache:apache owns DocumentRoot, SELinux denies by default.
>   Need sane solution.

I haven't yet tested on a machine with SELinux enabled.

I've attached an updated version of ApacheMirror.py with a redirection
bug fixed; previously it omitted the http://server part of the URL,
confusing some clients like Anaconda. I don't expect this to fix the
problem you're seeing, though.

--Ed
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ApacheMirror.py
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071120/a5d566c0/attachment.ksh>

From pmatilai at laiskiainen.org  Wed Nov 21 08:37:29 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 21 Nov 2007 10:37:29 +0200 (EET)
Subject: File conflicts, how do they work at that point?
In-Reply-To: <20071120162800.GC40258@dspnet.fr.eu.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
Message-ID: <alpine.DEB.0.9999.0711211029430.32062@gotcha.dreamhost.com>

On Tue, 20 Nov 2007, Olivier Galibert wrote:

> Transaction Check Error:
>  file /usr/bin/smcs from install of mono-core-1.2.5.1-3.fc8 conflicts with file from package mono-core-1.2.5.1-3.fc8
>
> Now that's a beautiful error message :-) Probably one is x86_64 and
> the other i386.

Yeah, an ancient bug... just been fixed in F8 to show the arch too for all 
problems.

> What are the rules for file conflicts now?  I thought they didn't
> exist anymore since multilib makes them more than annoying, and you
> couldn't even install both glibcs, but it looks like they can still
> appear somehow...

The rules haven't changed since the introduction of multilib (rpm 4.0 days 
or so): on multilib systems conflicts on files of same color are swallowed 
when the conflicting packages are installed in the same transaction, but 
when installed in separate transactions conflicts are raised.

Yes it's confusing and inconsistent behavior which I *really* want to get 
rid of. It's just that this is not a simple matter of "fixing rpm" - our 
package set is full of conflicting files. The package set needs fixing, 
otherwise you'll have a very much uninstallable x86_64 (and to slightly 
lesser effect ppc) tree.

 	- Panu -



From sundaram at fedoraproject.org  Wed Nov 21 08:36:04 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Nov 2007 14:06:04 +0530
Subject: File conflicts, how do they work at that point?
In-Reply-To: <alpine.DEB.0.9999.0711211029430.32062@gotcha.dreamhost.com>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<alpine.DEB.0.9999.0711211029430.32062@gotcha.dreamhost.com>
Message-ID: <4743EDF4.4090106@fedoraproject.org>

Panu Matilainen wrote:

> 
> Yes it's confusing and inconsistent behavior which I *really* want to 
> get rid of. It's just that this is not a simple matter of "fixing rpm" - 
> our package set is full of conflicting files. The package set needs 
> fixing, otherwise you'll have a very much uninstallable x86_64 (and to 
> slightly lesser effect ppc) tree.

Wouldn't fixing rpm early in the development cycle encourage more 
packages to get fixed faster?

Rahul



From pmatilai at laiskiainen.org  Wed Nov 21 08:49:26 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 21 Nov 2007 10:49:26 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
Message-ID: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>


To put it shortly, I going to switch the default rpm queryformat to 
include package architecture (ie what you get now with
rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or 
so.

This is something that should've been done several releases ago really, 
but since it presumably breaks all sorts of scripts people have it's 
gotten delayed and delayed... The next major rpm.org release changes the 
default anyway, this is just an initial step to see what breaks.

If you know the change would break some of the buildsystem / other 
critical Fedora infrastructure, please holler NOW! I can delay the change 
a bit to allow critical pieces to be fixed first, but F9 *will* have the 
new queryformat so better prepare for it...

Fixing any scripts that absolutely rely on the old default is trivial: 
just them use explicit --qf "%{name}-%{version}-%{release}"

 	- Panu -



From pmatilai at laiskiainen.org  Wed Nov 21 08:57:32 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Wed, 21 Nov 2007 10:57:32 +0200 (EET)
Subject: File conflicts, how do they work at that point?
In-Reply-To: <4743EDF4.4090106@fedoraproject.org>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<alpine.DEB.0.9999.0711211029430.32062@gotcha.dreamhost.com>
	<4743EDF4.4090106@fedoraproject.org>
Message-ID: <alpine.DEB.0.9999.0711211049390.32062@gotcha.dreamhost.com>

On Wed, 21 Nov 2007, Rahul Sundaram wrote:

> Panu Matilainen wrote:
>
>> 
>> Yes it's confusing and inconsistent behavior which I *really* want to get 
>> rid of. It's just that this is not a simple matter of "fixing rpm" - our 
>> package set is full of conflicting files. The package set needs fixing, 
>> otherwise you'll have a very much uninstallable x86_64 (and to slightly 
>> lesser effect ppc) tree.
>
> Wouldn't fixing rpm early in the development cycle encourage more packages to 
> get fixed faster?

That's the very reason bug #190209 is being dusted off at the moment :)

 	- Panu -



From pertusus at free.fr  Wed Nov 21 09:54:38 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 21 Nov 2007 10:54:38 +0100
Subject: rpms/namazu/devel filter-requires-namazu.sh, 1.2, 1.3
	namazu.spec, 1.10, 1.11
In-Reply-To: <200711210642.lAL6g6ae029939@cvs-int.fedora.redhat.com>
References: <200711210642.lAL6g6ae029939@cvs-int.fedora.redhat.com>
Message-ID: <20071121095438.GE2573@free.fr>

On Wed, Nov 21, 2007 at 01:42:06AM -0500, Akira Tagoh wrote:
> Author: tagoh
> 
> -%define __find_requires %{SOURCE1}
> +%define __perl_requires %{SOURCE1}

You should certainly redefine __perl_requires and __perl_provides to
avoid bogus Provides and Requires.

Currently namazu cannot be updated:

Error: Missing Dependency: perl(time.pl) is needed by package namazu
Error: Missing Dependency: perl(util.pl) is needed by package namazu
Error: Missing Dependency: perl(document.pl) is needed by package namazu
Error: Missing Dependency: perl(nmzidx.pl) is needed by package namazu
Error: Missing Dependency: perl(var.pl) is needed by package namazu
Error: Missing Dependency: perl(conf.pl) is needed by package namazu


--
Pat



From ivazqueznet at gmail.com  Wed Nov 21 10:26:47 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 21 Nov 2007 05:26:47 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
Message-ID: <1195640807.24136.3.camel@ignacio.lan>

On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> To put it shortly, I going to switch the default rpm queryformat to 
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or 
> so.

+1000000000000000000000000

> Fixing any scripts that absolutely rely on the old default is trivial: 
> just them use explicit --qf "%{name}-%{version}-%{release}"

Or better yet, fix your script to use and parse a more explicit
queryformat.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/3dbeabec/attachment.sig>

From caillon at redhat.com  Wed Nov 21 10:29:26 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 21 Nov 2007 11:29:26 +0100
Subject: XULRunner in rawhide
In-Reply-To: <afoddoo04l.fsf@allele2.eebweb.arizona.edu>
References: <473AFF3E.1090904@redhat.com>	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>	<473C85A5.9020100@redhat.com>	<ld4uattp4.fsf@allele2.eebweb.arizona.edu>	<473D6760.4050609@redhat.com>
	<afoddoo04l.fsf@allele2.eebweb.arizona.edu>
Message-ID: <47440886.9000204@redhat.com>

On 11/21/2007 02:31 AM, Alex Lancaster wrote:
> Martin,
> 
> I retried with the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9
> thinking that maybe the new xulrunner would fix this but I get the
> same thing:
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=252253&name=build.log
> 
> here's the task:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=252253

Can you file a bug so we can better track this?



From bnocera at redhat.com  Wed Nov 21 10:51:48 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 21 Nov 2007 10:51:48 +0000
Subject: libgpod soname bump coming to rawhide
In-Reply-To: <Pine.GSO.4.60.0711202146001.10992@igloo.df.lth.se>
References: <20071120172929.GB2967@psilocybe.teonanacatl.org>
	<Pine.GSO.4.60.0711202146001.10992@igloo.df.lth.se>
Message-ID: <1195642308.10878.273.camel@cookie.hadess.net>


On Tue, 2007-11-20 at 21:50 +0100, Linus Walleij wrote:
> On Tue, 20 Nov 2007, Todd Zullinger wrote:
> 
> > This is definitely something I think warrants an update for F-8 and
> > F-7 after stewing in rawhide for a week or so.
> 
> I agree. Please, this time (as we're rebuilding Amarok) let's sync it with 
> the imminent update of libmtp soname found in 
> https://bugzilla.redhat.com/show_bug.cgi?id=359401
> if you have a BZ ticket for libgpod then reference this to the libmtp 
> update please.

Rhythmbox will need a rebuild for the new libmtp as well (only just in
rawhide...).



From j.w.r.degoede at hhs.nl  Wed Nov 21 10:55:36 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 21 Nov 2007 11:55:36 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
Message-ID: <47440EA8.5060500@hhs.nl>

Panu Matilainen wrote:
> 
> To put it shortly, I going to switch the default rpm queryformat to 
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or so.
> 
> This is something that should've been done several releases ago really, 
> but since it presumably breaks all sorts of scripts people have it's 
> gotten delayed and delayed... The next major rpm.org release changes the 
> default anyway, this is just an initial step to see what breaks.
> 
> If you know the change would break some of the buildsystem / other 
> critical Fedora infrastructure, please holler NOW! I can delay the 
> change a bit to allow critical pieces to be fixed first, but F9 *will* 
> have the new queryformat so better prepare for it...
> 
> Fixing any scripts that absolutely rely on the old default is trivial: 
> just them use explicit --qf "%{name}-%{version}-%{release}"
> 

Excellent then I can finally remove my rpm alias adding that as query format 
from my .bashrc :)

Regards,

Hans




From snecklifter at gmail.com  Wed Nov 21 11:10:38 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 21 Nov 2007 11:10:38 +0000
Subject: RFC: Package Review VCS
In-Reply-To: <20071120070454.7263353b@weaponx>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com> <20071120075202.78de1855@redhat.com>
	<20071120070454.7263353b@weaponx>
Message-ID: <364d303b0711210310y7d1ba995l44e9f1f1516471ca@mail.gmail.com>

On 20/11/2007, Josh Boyer <jwboyer at gmail.com> wrote:
> On Tue, 20 Nov 2007 07:52:02 -0500
> Jesse Keating <jkeating at redhat.com> wrote:
>
> > On Mon, 19 Nov 2007 17:58:08 -0500
> > Warren Togami <wtogami at redhat.com> wrote:
> >
> > > Risk Mitigating Factor:
> > > New contributors have no CVS commit access to /cvs/pkgreview at all
> > > until a reviewer gives them access.  The reviewer should know better
> > > than to allow something with legal problems into the CVS repo or to
> > > grant someone access to upload such code.  So in practice, this
> > > removal plan is likely to be needed rarely if ever.
> >
> > If it's only for existing contributors, why can't they just use their
> > fedorapeople space with git or hg or whatever?
>
> +1.
>
> btw, do we have instructions somewhere for setting up git/hg repos on
> fedorapeople?

I thought the space was limited to 100MB on fedorapeople? I'm only
submitting a few packages for review and have already hit the ceiling
on this a few times so I'm all for it but this limitation might need a
bit of a rethink.

Cheers
Chris

-- 
http://www.chruz.com



From buildsys at redhat.com  Wed Nov 21 11:44:42 2007
From: buildsys at redhat.com (Build System)
Date: Wed, 21 Nov 2007 06:44:42 -0500
Subject: rawhide report: 20071121 changes
Message-ID: <200711211144.lALBigdZ010419@porkchop.devel.redhat.com>

New package R-abind
	Combine multi-dimensional arrays

New package R-acepack
	ACE and AVAS methods for choosing regression transformations

New package fuseiso
	FUSE support for ISO filesystem images

New package i2c-tools
	A heterogeneous set of I2C tools for Linux

New package jgoodies-looks
	Free high-fidelity Windows and multi-platform appearance

New package libgnomedbmm
	C++ interface for libgnomedb


 
Updated Packages:

asciidoc-8.2.5-1.fc9
--------------------
* Tue Nov 20 2007 Florian La Roche <laroche at redhat.com>
- new upstream version 8.2.5

audacious-1.4.2-2.fc9
---------------------
* Mon Nov 19 2007 Ralf Ertzinger <ralf at skytale.net> 1.4.2-2
- Update to 1.4.2

* Tue Aug 28 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 1.3.2-3
- Rebuild for selinux ppc32 issue.

* Sat Aug 25 2007 Ralf Ertzinger <ralf at skytale.net> 1.3.2-2
- Clarify License: tag

autofs-1:5.0.2-18
-----------------
* Tue Nov 20 2007 Ian Kent <ikent at redhat.com> - 5.0.2-18
- fix schema selection in LDAP schema discovery.
- check for "*" when looking up wildcard in LDAP.
- fix couple of edge case parse fails of timeout option.
- add SEARCH_BASE configuration option.
- add random selection as a master map entry option.
- re-read config on HUP signal.
- add LDAP_URI, LDAP_TIMEOUT and LDAP_NETWORK_TIMEOUT configuration options.
- fix deadlock in submount mount module.
- fix lack of ferror() checking when reading files.
- fix typo in autofs(5) man page.
- fix map entry expansion when undefined macro is present.
- remove unused export validation code.
- add dynamic logging (adapted from v4 patch from Jeff Moyer).
- fix recursive loopback mounts (Matthias Koenig).
- add map re-load to verbose logging.
- fix handling of LDAP base dns with spaces.
- handle MTAB_NOTUPDATED status return from mount.
- when default master map, auto.master, is used also check for auto_master.
- update negative mount timeout handling.
- fix large group handling (Ryan Thomas).
- fix for dynamic logging breaking non-sasl build (Guillaume Rousse).
- eliminate NULL proc ping for singleton host or local mounts.

bodhi-0.4.6-1.fc9
-----------------
* Tue Nov 20 2007 Luke Macken <lmacken at redhat.com> - 0.4.6-1
- 0.4.6

cacti-0.8.7a-1.fc9
------------------
* Tue Nov 20 2007 Mike McGrath <mmcgrath at redhat.com> - 0.8.7a-1
- Upstream released new version
- Fixes for bug #391691 - CVE-2007-6035

ctrlproxy-3.0.3-1.fc9
---------------------
* Sun Nov 18 2007 Josh Boyer <jwboyer at jdub.homelinux.org> 3.0.3-1
- Update to latest upstream

ddd-3.3.11-17.fc9
-----------------
* Tue Nov 20 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 3.3.11-17
- use xdg-utils to open html pages

dfu-programmer-0.4.4-1.fc9
--------------------------
* Mon Nov 19 2007 Weston Schmidt <weston_schmidt at alumni.purdue.edu> - 0.4.4-1
- added reset command
- added udev rules and permissions

digikam-0.9.3-0.2.beta3.fc9
---------------------------
* Tue Nov 20 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.9.3-0.2.beta3
- digikam-0.9.3-beta3

dmraid-1.0.0.rc14-6.fc9
-----------------------
* Wed Nov 21 2007 Ian Kent <ikent at redhat.com> - 1.0.0.rc14-6
- Bug 379911: dmraid needs to generate UUIDs for lib device-mapper
  - add "DMRAID-" prefix to dmraid UUID string.

dvd+rw-tools-7.0-8.fc9
----------------------
* Tue Nov 20 2007 Harald Hoyer <harald at redhat.com> - 7.0-8
- added a patch to fix a reload problem on some drives, 
  after a successful burn

firstboot-1.90-2.fc9
--------------------

gd-2.0.35-4.fc9
---------------
* Tue Nov 20 2007 Ivana Varekova <varekova at redhat.com> 2.0.35-4
- remove static library

* Mon Nov 19 2007 Ivana Varekova <varekova at redhat.com> 2.0.35-3
- spec file cleanup

* Mon Nov 19 2007 Ivana Varekova <varekova at redhat.com> 2.0.35-2
- fix gdlib.pc file

gdesklets-0.36-0.2.beta.fc9
---------------------------
* Thu Nov 15 2007 Luya Tshimbalanga <luya_tfz at thefinalzone.com> - 0.36.0-2.beta
- New beta release
- Removed patch

gdm-1:2.21.2-0.2007.11.20.2.fc9
-------------------------------
* Tue Nov 20 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.20.2
- Drop dont run profile patch since dwalsh changed /usr/sbin/gdm label

* Tue Nov 20 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.20.1
- Update to today's snapshot

* Mon Nov 19 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.2-0.2007.11.19.3
- fix permissions on homedir

icecream-0.8.0-4.20071101svn.fc9
--------------------------------
* Tue Nov 20 2007 Michal Schmidt <mschmidt at redhat.com> - 0.8.0-4.20071101svn
- Add a SELinux policy for iceccd
- Initscripts as sources instead of patches in the .spec file
- Don't touch /var/log/iceccd in the initscript. Let iceccd create it.
jd-1.9.7-0.4.svn1538.fc9
------------------------
* Tue Nov 20 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.svn1538
- svn 1538

* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

kakasi-2.3.4-25.fc9
-------------------
* Tue Nov 20 2007 Akira TAGOH <tagoh at redhat.com> - 2.3.4-25
- Clean up spec file.
- Get rid of -L%libdir% from kakasi-config because it's a standard library
  directory. (#341691)
- Separate the shread library to kakasi-libs package.

kdelibs4-3.96.0-4.fc9
---------------------
* Tue Nov 20 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.0-4
- Requires: kdebase-runtime oxygen-icon-theme (where available)

* Mon Nov 19 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.0-3
- Requires: dbus-x11 (#390851)

* Mon Nov 19 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.0-2
- -devel: (Build)Requires: libXcomposite-devel libXdamage-devel
   libxkbfile-devel libXpm-devel libXScrnSaver-devel libXtst-devel
   libXv-devel libXxf86misc-devel
- devel: Requires: strigi-devel >= 0.5.7
- (Build)Requires: kde-filesystem >= 4

kdesvn-0.14.1-1.fc9
-------------------
* Mon Nov 19 2007 - Orion Poplawski <orion at cora.nwra.com> - 0.14.1-1
- Update to 0.14.1
- Link libsvnqt.so with --as-needed
- Add patch to fix bug #388821 (dangling symlinks)

kernel-xen-2.6-2.6.21.7-2890.fc9
--------------------------------
* Mon Nov 19 2007 Eduardo Habkost <ehabkost at redhat.com>
- Re-add xen-hypervisor-abi provides. It was lost on the spec resync
  (problem detected on updates-testing)

* Wed Nov 14 2007 Eduardo Habkost <ehabkost at redhat.com>
- Update HV to official 3.1.0

* Mon Oct 29 2007 Eduardo Habkost <ehabkost at redhat.com>
- Pulled spec file from non-xen kernel
  - Enabled -debuginfo packages (bug #336351)

kvm-53-1.fc9
------------
* Tue Nov 20 2007 Jeremy Katz <katzj at redhat.com> - 53-1
- update to kvm-53

libzzub-0.2.3-10.fc9
--------------------
* Tue Nov 20 2007 Alexander Kahl <akahl at iconmobile.com> - 0.2.3-10
- updated buildfix patch to drop explicit sse optimizations
- removed JOBS option again since scons supports -j build option

listen-0.5-16.fc9
-----------------
* Tue Nov 20 2007 Ha??kel Gu??mar <karlthered at gmail.com> 0.5-16
- add python-tunepimp dependency

mock-0.8.9-1.fc9
----------------
* Tue Nov 20 2007 Michael Brown <mebrown at michaels-house.net> - 0.8.9-1
- Fixes so that mock will run cleanly on RHEL5
- Add glib-devel.i386, glib2-devel.i386 to yum exclude list as it breaks
  builds.
- Add backwards-compatibility code for old-style 'automatically assume rebuild'
  convention
- automake symlink accidentally included in tarball rather than file
  (py-compile)
- update manpage

ntfs-3g-2:1.1120-1.fc9
----------------------
* Tue Nov 20 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1120-1
- bump to 1.1120

ocaml-libvirt-0.3.3.4-1.fc9
---------------------------
* Tue Nov 20 2007 Richard W.M. Jones <rjones at redhat.com> - 0.3.3.4-1
- New upstream release 0.3.3.4.
- Upstream website is now http://libvirt.org/ocaml/

* Fri Oct 19 2007 Richard W.M. Jones <rjones at redhat.com> - 0.3.3.0-2
- Mistake: BR is ocaml-calendar-devel.

* Fri Oct 19 2007 Richard W.M. Jones <rjones at redhat.com> - 0.3.3.0-1
- New upstream release 0.3.3.0.
- Added support for virt-df, but disabled it by default.
- +BR ocaml-calendar.

openssh-4.7p1-4.fc9
-------------------
* Tue Nov 20 2007 Tomas Mraz <tmraz at redhat.com> - 4.7p1-4
- do not copy /etc/localtime into the chroot as it is not
  necessary anymore (#193184)
- call setkeycreatecon when selinux context is established
- test for NULL privk when freeing key (#391871) - patch by
  Pierre Ossman

pciutils-2.2.9-1.fc9
--------------------
* Tue Nov 20 2007 Harald Hoyer <harald at redhat.com> - 2.2.9-1
- version 2.2.9
- added package config file (rhbz#389451)

perl-HTML-Table-2.07-0.b2.fc9
-----------------------------
* Tue Nov 20 2007 Orion Poplawski <orion at cora.nwra.com> 2.07-0.b2
- Update to 2.07-b2

php-pear-PHP-CompatInfo-1.5.1-2.fc9
-----------------------------------
* Tue Nov 20 2007 Remi Collet <Fedora at FamilleCollet.com> 1.5.1-2
- fix BR (pear >= 1.5.4)

* Tue Nov 20 2007 Remi Collet <Fedora at FamilleCollet.com> 1.5.1-1
- upgrade to 1.5.1
- fix licence + del file

phpMyAdmin-2.11.2.1-1.fc9
-------------------------
* Tue Nov 20 2007 Mike McGrath <mmcgrath at redhat.com> 2.11.2.1-1
- Upstream released new version

pykickstart-1.22-1.fc9
----------------------
* Tue Nov 20 2007 Chris Lumens <clumens at redhat.com> 1.22-1
- Don't process or write out vnc --enabled (jlaska AT redhat DOT com).
- Fix a traceback in the clearpart command.

sdljava-0.9.1-6.fc9
-------------------
* Tue Nov 20 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.9.1-6
- Adjust font symlinks in sdljava-demo package for fontfile name changes in
  dejavu-fonts (bz 388861)

sepostgresql-8.2.5-1.66.fc9
---------------------------
* Wed Nov 21 2007 <kaigai at kaigai.gr.jp> - 8.2.5-1.66
- Add a policy module hotfix for labeled networking

smolt-1.0-1.fc9
---------------
* Tue Nov 20 2007 Mike McGrath <mmcgrath at redhat.com> 1.0-1
- Upstream released new version

tetex-3.0-48.fc9
----------------
* Tue Nov 20 2007 Jindrich Novy <jnovy at redhat.com> 3.0-48
- update japanese font paths (#392221), thanks to MATSUURA Takanori
- don't touch .base files

* Fri Nov 16 2007 Jindrich Novy <jnovy at redhat.com> 3.0-47
- temporarily disable check-buildroot so that we don't get
  broken fmt files after buildroot references removal (#325311)

* Tue Nov 13 2007 Jindrich Novy <jnovy at redhat.com> 3.0-46
- fix dvips -z buffer overflow with long href (#368591)
- fix insecure usage of temporary file in dviljk (#368611, #368641)

wavbreaker-0.9-1.fc9
--------------------
* Tue Nov 20 2007 Homer <dmaley at nc.rr.com> 0.9-1
- move to latest upstream release

which-2.18-2.fc9
----------------
* Tue Nov 20 2007 Than Ngo <than at redhat.com> 2.18-2
- cleanup specfile

wireshark-0.99.7-0.pre1.fc9
---------------------------
* Tue Nov 20 2007 Radek Vokal <rvokal at redhat.com> 0.99.7-0.pre1
- upgrade to 0.99.7 pre-release

xmms-speex-0.9.1-12
-------------------
* Tue Nov 20 2007 Matthias Saou <http://freshrpms.net/> 0.9.1-12
- Remove URL field (upstream is dead) and absolute source URL (#359591).

xulrunner-1.9-0.beta1.1.fc9
---------------------------
* Tue Nov 20 2007 Martin Stransky <stransky at redhat.com> 1.9-0.beta1.1
- update to beta 1

Broken deps for i386
----------------------------------------------------------
	audacious - 1.4.2-2.fc9.i386 requires audacious-plugins >= 0:1.4.0
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	audacious-plugin-fc - 0.2-3.i386 requires libaudacious.so.5
	conky - 1.4.8-1.fc9.i386 requires libaudacious.so.5
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	gxine - 0.5.11-11.fc9.i386 requires gecko-libs = 0:1.9a9pre
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	namazu - 2.0.17-3.fc9.i386 requires perl(time.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(util.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(var.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.i386 requires perl(document.pl)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3



Broken deps for x86_64
----------------------------------------------------------
	audacious - 1.4.2-2.fc9.x86_64 requires audacious-plugins >= 0:1.4.0
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	audacious-plugin-fc - 0.2-3.x86_64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.x86_64 requires libaudacious.so.5()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	gxine - 0.5.11-11.fc9.x86_64 requires gecko-libs = 0:1.9a9pre
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	namazu - 2.0.17-3.fc9.x86_64 requires perl(time.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(util.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(var.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.x86_64 requires perl(document.pl)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	audacious - 1.4.2-2.fc9.ppc requires audacious-plugins >= 0:1.4.0
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	audacious-plugin-fc - 0.2-3.ppc requires libaudacious.so.5
	conky - 1.4.8-1.fc9.ppc requires libaudacious.so.5
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	gxine - 0.5.11-11.fc9.ppc requires gecko-libs = 0:1.9a9pre
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo
	namazu - 2.0.17-3.fc9.ppc requires perl(time.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(util.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(var.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.ppc requires perl(document.pl)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3



Broken deps for ppc64
----------------------------------------------------------
	audacious - 1.4.2-2.fc9.ppc64 requires audacious-plugins >= 0:1.4.0
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	audacious-plugin-fc - 0.2-3.ppc64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.ppc64 requires libaudacious.so.5()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	gxine - 0.5.11-11.fc9.ppc64 requires gecko-libs = 0:1.9a9pre
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	namazu - 2.0.17-3.fc9.ppc64 requires perl(time.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(conf.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(util.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(var.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(nmzidx.pl)
	namazu - 2.0.17-3.fc9.ppc64 requires perl(document.pl)
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)





From denis at poolshark.org  Wed Nov 21 11:47:02 2007
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 21 Nov 2007 12:47:02 +0100
Subject: system-config-printer trouble
Message-ID: <47441AB6.6030106@poolshark.org>

I'm having all sorts of issues running system-config-printer. Sometimes 
i get caught in an endless apply dialog loop. Sometime I get a 
mysterious "Password required" for my own password on localhost (no 
passwords actually seems to work). Lately when I press 'print test page' 
I get a core dump:

Nov 21 12:41:09 jupiler kernel: python[22202]: segfault at 00000007 eip 
00736bc8 esp bfa1e83c error 4


I was surprised to see so few BZs entries for F8 system-config-printer. 
Before I start filing away, is anyone else having trouble with it ?

-denis



From alexl at users.sourceforge.net  Wed Nov 21 12:15:49 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 21 Nov 2007 05:15:49 -0700
Subject: XULRunner in rawhide
In-Reply-To: <47440886.9000204@redhat.com> (Christopher Aillon's message of
	"Wed\, 21 Nov 2007 11\:29\:26 +0100")
References: <473AFF3E.1090904@redhat.com>
	<kbmytg6he3.fsf@allele2.eebweb.arizona.edu>
	<473C85A5.9020100@redhat.com>
	<ld4uattp4.fsf@allele2.eebweb.arizona.edu>
	<473D6760.4050609@redhat.com>
	<afoddoo04l.fsf@allele2.eebweb.arizona.edu>
	<47440886.9000204@redhat.com>
Message-ID: <o6hcjfokui.fsf@allele2.eebweb.arizona.edu>

>>>>> "CA" == Christopher Aillon  writes:

>> On 11/21/2007 02:31 AM, Alex Lancaster wrote:
>> Martin,
>> 
>> I retried with the latest xulrunner in rawhide: 1.9-0.beta1.1.fc9
>> thinking that maybe the new xulrunner would fix this but I get the
>> same thing:
>> 
>> http://koji.fedoraproject.org/koji/getfile?taskID=252253&name=build.log
>> 
>> here's the task:
>> 
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=252253

CA> Can you file a bug so we can better track this?

Already done:

https://bugzilla.redhat.com/show_bug.cgi?id=393521

Alex



From jkeating at redhat.com  Wed Nov 21 13:26:49 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Nov 2007 08:26:49 -0500
Subject: RFC: Package Review VCS
In-Reply-To: <364d303b0711210310y7d1ba995l44e9f1f1516471ca@mail.gmail.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com> <20071120075202.78de1855@redhat.com>
	<20071120070454.7263353b@weaponx>
	<364d303b0711210310y7d1ba995l44e9f1f1516471ca@mail.gmail.com>
Message-ID: <20071121082649.52a57450@redhat.com>

On Wed, 21 Nov 2007 11:10:38 +0000
"Christopher Brown" <snecklifter at gmail.com> wrote:

> I thought the space was limited to 100MB on fedorapeople? I'm only
> submitting a few packages for review and have already hit the ceiling
> on this a few times so I'm all for it but this limitation might need a
> bit of a rethink.

Are you doing them all at once, or are you taking care of purning your
content after a review is complete?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/b21e145b/attachment.sig>

From omar at linux.vnet.ibm.com  Wed Nov 21 13:44:13 2007
From: omar at linux.vnet.ibm.com (Mohammed Omar)
Date: Wed, 21 Nov 2007 19:14:13 +0530
Subject: Fedora Core testing
In-Reply-To: <200711200848.03429.dennis@ausil.us>
References: <1195566284.8287.8.camel@omar> <200711200848.03429.dennis@ausil.us>
Message-ID: <1195652653.10113.1.camel@omar>

On Tue, 2007-11-20 at 08:47 -0600, Dennis Gilmore wrote: 
> On Tuesday 20 November 2007, Mohammed Omar wrote:
> > Hi all,
> >
> > I do Fedora Core testing as a part of Community Distro test at IBM .
> > Basic idea is to find bugs at early stages of Distro release on  X and P
> > series hardware. Initially I started fedora testing on Power box and
> > later will test on Xseries.I would like to share the releases of FC8
> > tested,Hardware used, test suites executed and no. of bugs found.
> For one  there is no longer a "Fedora Core"  there is just "Fedora"   its just 
> F8 
Thanks for your info. 
> 
> > Covered Releases:
> > ----------------
> >
> > Releases: Date: status:
> > FC8test1 07 Aug 2007 finished
> > FC8test2 13 Sept 2007 finished
> > FC8test3 04 Oct 2007 finished
> > FC8GA 08 Nov 2007      currently testing
> >
> > Test suites used for testing above releases
> > --------------------------------------------
> >
> > Installation/Upgradation testing
> > NFS/HTTP/FTP/local installations.
> > Smoke testing includes LTP
> > Stress testing
> > Core kernel and regression testing
> > Memory stress
> > FS stress testing etc,.
> sounds very intresting 
> 
> >
> > Hardware Used for fedora core testing:
> > ---------------------------------------
> > PPC64 : P520, P55 , JS21 , P630b
> > i386:  X445       [ Used for network tests ]
> > X86_64:  X3400    [ Used for network tests ]
> >
> >
> > Total no. of Bugs Found: 11 ,  closed: 3
> > ----------------------------------------
> > Listing some of the bugs here...
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239658
> > https://bugzilla.redhat.com/show_bug.cgi?id=268241
> > https://bugzilla.redhat.com/show_bug.cgi?id=353021
> 
> perhaps you could have a tracker bug to keep track of all the bugs you find  
> so they can all be easily referenced

Ofcourse, generally i raise bugs in IBM bugzilla and that will be
mirrored out to the community(Redhat bugzilla). I have given some of the
links which mirrored to Redhat bugzilla as IBM bugzilla cannot be
accessed outside.

> > Most of the bugs closed internally. Basically I do concentrate on system
> > testing to find more bugs in kernel.
> >
> > New Features tested:
> > --------------------
> > EXT4 fs tested with fs stress, NFS ,SAMBA.
> > I am also looking to test Kdump on Fedora.
> 
> Cool :)
> 
> > I would like to invite Fedora users and testers to join in testing
> > fedora effectively.
> 
> how do you propose to achieve this goal?
> do you have a test matrix you follow?   do you have resources that you could 
> give people access to help with testing?
We have our own test plan for Fedora Testing. 
  
> 
> It sounds like a great goal.  you should probably work with Will Woods to help 
> with his QA efforts.  you should also speak with David Woodhouse about ppc 
> specific QA testing.
Thanks for your quick reply and valuable suggestions . Definitely, I am looking into this. 

--thanks
omar



From laroche at redhat.com  Wed Nov 21 13:50:47 2007
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 21 Nov 2007 14:50:47 +0100
Subject: packaging files via symlinks
In-Reply-To: <20071117153726.GA11512@dudweiler.stuttgart.redhat.com>
References: <20071117153726.GA11512@dudweiler.stuttgart.redhat.com>
Message-ID: <20071121135047.GA11948@dudweiler.stuttgart.redhat.com>

Hello all,

Update on the results:

On Sat, Nov 17, 2007 at 04:37:26PM +0100, Florian La Roche wrote:
> Hello all,
> 
> I've added a check to pyrpm to detect the cases where
> a symlink to a directory is used within a directory name
> to package files into a rpm. The patch for this is at:
> http://www.jur-linux.org/git/?p=cvs-pyrpm.git;a=commitdiff;h=3cfefdc1496c0ee6b0ca925430af7d45f8531ece
> Let me know if you can speed this test further up and know
> further python or algorithm improvements.
> 
> We knew such a symlink was often used to package e.g. /etc/init.d/<service>,
> but running this on Fedora-devel shows that also other
> packages are affected:
> 
> symlink /etc/init.d from chkconfig-1.3.37-1.i386.rpm is used as directory name in conmux-0.0-6.493svn.fc7.noarch.rpm aiccu-2007.01.15-3.fc8.i386.rpm tomcat5-5.5.23-9jpp.4.fc8.i386.rpm cobbler-0.6.3-2.fc9.noarch.rpm func-0.13-3.fc9.noarch.rpm zabbix-agent-1.4.2-3.fc8.i386.rpm varnish-1.1.1-3.fc8.i386.rpm jetty-5.1.12-1jpp.7.fc8.i386.rpm dkms-2.0.17.5-1.fc8.noarch.rpm ldirectord-2.1.2-2.fc8.i386.rpm monotone-server-0.37-3.fc9.i386.rpm dircproxy-1.2.0-0.6beta2.fc8.i386.rpm fuse-2.7.0-8.fc8.i386.rpm wifiroamd-1.12-1.fc8.noarch.rpm conman-0.1.9.2-7.fc7.i386.rpm sqlgrey-1.7.5-1.fc7.noarch.rpm edac-utils-0.9-7.fc8.i386.rpm zabbix-1.4.2-3.fc8.i386.rpm cyphesis-0.5.13-2.fc8.i386.rpm heartbeat-2.1.2-2.fc8.i386.rpm

Not sure we want to fix all of these, maybe FESCO wants to decide this first.

> symlink /usr/lib/tcl8.4 from tcl-8.4.15-5.fc8.i386.rpm is used as directory name in tkdnd-1.0a2-9.fc8.i386.rpm amsn-0.96-7.fc7.i386.rpm tbcload-1.4-5.20061030cvs.fc8.i386.rpm

This is going to get fixed with tcl8.5.

> symlink /usr/share/pharosc/alliance/makevbe/ssxlib013 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/rgalib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/ssxlib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/sxlib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/vgalib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/vsclib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/vxlib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm
> symlink /usr/share/pharosc/alliance/vbe/wsclib013_0 from pharosc-alliance-8.3-1.fc8.noarch.rpm is used as directory name in pharosc-alliance-devel-8.3-1.fc8.noarch.rpm

Only affects one package.

> symlink /usr/share/sgml/docbook/xsl-stylesheets from docbook-style-xsl-1.73.2-4.fc9.noarch.rpm is used as directory name in docbook-style-xsl-1.73.2-4.fc9.noarch.rpm dblatex-0.2.7-16.fc9.noarch.rpm

docbook-style-xsl could drop the versioned directory.


regards,

Florian La Roche


> 
> I'll add a bugzilla report for tkdnd, amsn, tbcload,
> pharosc, docbook-style-xsl, dblatex if noone are already filed.
> 
> regards,
> 
> Florian La Roche
> 



From twaugh at redhat.com  Wed Nov 21 13:56:45 2007
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 21 Nov 2007 13:56:45 +0000
Subject: system-config-printer trouble
In-Reply-To: <47441AB6.6030106@poolshark.org>
References: <47441AB6.6030106@poolshark.org>
Message-ID: <1195653405.3636.11.camel@cyberelk.elk>

On Wed, 2007-11-21 at 12:47 +0100, Denis Leroy wrote:
> I'm having all sorts of issues running system-config-printer. Sometimes 
> i get caught in an endless apply dialog loop. Sometime I get a 
> mysterious "Password required" for my own password on localhost (no 
> passwords actually seems to work). Lately when I press 'print test page' 
> I get a core dump:
> 
> Nov 21 12:41:09 jupiler kernel: python[22202]: segfault at 00000007 eip 
> 00736bc8 esp bfa1e83c error 4

It sounds like you are using the version from updates-testing, and the
bug you describe has been filed:

  https://bugzilla.redhat.com/show_bug.cgi?id=390431#c4

> I was surprised to see so few BZs entries for F8 system-config-printer. 
> Before I start filing away, is anyone else having trouble with it ?

Please try 0.7.74.6-2.fc8 (or else revert to the latest non-testing
version, 0.7.74.4).

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/bc7e6b69/attachment.sig>

From adam at batkin.net  Wed Nov 21 14:25:47 2007
From: adam at batkin.net (Adam Batkin)
Date: Wed, 21 Nov 2007 14:25:47 +0000
Subject: X Idle Time reporting is wrong
Message-ID: <47443FEB.7010807@batkin.net>

For the past few years I have noticed that my idle times as reported by gaim (err, pidgin) 
have been wrong. So I did some investigation and wrote a small program that calls X's 
XScreenSaverQueryInfo() in a loop once a second and generates some statistics (it's the 
same function called by pidgin). So just to clear one thing up, this problem is definitely 
not with pidgin, it is with the underlying X11 API.

XScreenSaverQueryInfo() fills in an XScreenSaverInfo structure with (among others) field 
"idle" which according to the man page: "specifies the number of milliseconds since the 
last input was received from the user on any of the input devices".

So, here is a summary of my results (plus or minus 1 second) of running the program while 
not touching the computer:
- For 11 minutes, the idle time slowly increases properly
- Then suddenly it drops back down to 0 (or by the function gets called, just a few 
milliseconds)
- The idle time then increases again for 59 minutes
- Then drops back to 0
- The idle time increases for another 23 minutes 18 seconds (weird)
- Then drops to 0
- The idle time climbs normally for a few hours until I bother to start touching the 
computer again

So X became "un-idle" at 11 minutes, 70 minutes (11+59) and approx. 93 minutes (11+59+23)

11 and 59 are special numbers: I specifically set my screensaver to go on at 11 minutes 
and the monitor to power off after 59 (though I have no idea what happens after another 23 
minutes). If I set the screensaver/poweroff times to different numbers, they will be 
reflected in the results of XScreenSaverQueryInfo()

I have tested this with multiple computers, all with different hardware. Here are the 
similarities:
- All are running KDE
- All are running Fedora (though I have had this problem for years, since, say RedHat 7.3 
or 9)
- All have nvidia video cards (though different models)
- All have LCD monitors

All of the systems have had fresh installs over the years and the problem persists.

I haven't done as much testing with Gnome, but I did a quick check and after 60 minutes it 
becomes un-idle, then stays idle (which is weird because I set the screensaver time to 
something like 7 minutes, and monitor poweroff to 57)

Thoughts? Should I try to work with the upstream freedesktop/xorg folks?

-Adam Batkin



From snecklifter at gmail.com  Wed Nov 21 14:29:27 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 21 Nov 2007 14:29:27 +0000
Subject: RFC: Package Review VCS
In-Reply-To: <20071121082649.52a57450@redhat.com>
References: <47420B80.9070001@redhat.com>
	<1195511355.27963.1.camel@localhost.localdomain>
	<4742106E.50305@redhat.com>
	<1195512172.27963.3.camel@localhost.localdomain>
	<47421500.2040807@redhat.com> <20071120075202.78de1855@redhat.com>
	<20071120070454.7263353b@weaponx>
	<364d303b0711210310y7d1ba995l44e9f1f1516471ca@mail.gmail.com>
	<20071121082649.52a57450@redhat.com>
Message-ID: <364d303b0711210629i7453f41dp50fd534061f3f188@mail.gmail.com>

On 21/11/2007, Jesse Keating <jkeating at redhat.com> wrote:
> On Wed, 21 Nov 2007 11:10:38 +0000
> "Christopher Brown" <snecklifter at gmail.com> wrote:
>
> > I thought the space was limited to 100MB on fedorapeople? I'm only
> > submitting a few packages for review and have already hit the ceiling
> > on this a few times so I'm all for it but this limitation might need a
> > bit of a rethink.
>
> Are you doing them all at once, or are you taking care of purning your
> content after a review is complete?

I'm pruning after a review sure but even a couple of packages with
sources take up the room. Its no major as I have other hosting - would
just like to keep my fedora stuff more in fedora space and something
to consider if we're going to start git repos on them.

Cheers
Chris

-- 
http://www.chruz.com



From triad at df.lth.se  Wed Nov 21 14:42:50 2007
From: triad at df.lth.se (Linus Walleij)
Date: Wed, 21 Nov 2007 15:42:50 +0100 (CET)
Subject: libgpod soname bump coming to rawhide
In-Reply-To: <1195642308.10878.273.camel@cookie.hadess.net>
References: <20071120172929.GB2967@psilocybe.teonanacatl.org>
	<Pine.GSO.4.60.0711202146001.10992@igloo.df.lth.se>
	<1195642308.10878.273.camel@cookie.hadess.net>
Message-ID: <Pine.GSO.4.60.0711211542120.15539@igloo.df.lth.se>

On Wed, 21 Nov 2007, Bastien Nocera wrote:

> Rhythmbox will need a rebuild for the new libmtp as well (only just in
> rawhide...).

That's already done, I just brutally broke the deps in Rawhide as is 
custom :-)

Linus



From galibert at pobox.com  Tue Nov 20 18:41:33 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Tue, 20 Nov 2007 19:41:33 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <1195578414.3568.58.camel@localhost.localdomain>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
Message-ID: <20071120184133.GA51420@dspnet.fr.eu.org>

[Sent it personally instead of to the list by mistake]

On Tue, Nov 20, 2007 at 06:06:54PM +0100, Lubomir Kundrak wrote:
> 
> On Tue, 2007-11-20 at 15:51 +0100, Olivier Galibert wrote:
> > On Tue, Nov 20, 2007 at 08:26:47AM -0600, Josh Boyer wrote:
> > > Perhaps you should calm down a bit.  Flying off the handle before
> > > asking if the bug permissions can be changed or an explanation is
> > > provided is probably not going to be very productive.
> > 
> > Well, sorry.  Fedora becomes worse for my use with each release I try,
> > and I'm starting to get really annoyed at that, because it used to be
> > so much better.
> 
> May I ask what's "your use"?

My use is a team in a lab with 100-200 machines, about 30 of them
physically on people's desktops, about 80 in two oscar clusters.  Some
of the people could do system administration, some couldn't, most
don't want to anyway.

Since I ended up as sysadmin-by-default, I need a distribution which I
can install and update with a minimum amount of fussing, and where the
installation has pretty much everything the users are going to need.

At fedora core 3 times, things were reasonably nice.  You could do an
everything install, test it for a while to see what was missing and/or
broken, put the packages and the additionally needed ones in a local
network repository and go.  And you would be ok for two years.

At fedora core 5 times, Everything was lost.  Thankfully it is still
in kickstart, but it makes the initial testing phase more annoying.
Way more problematic is the support time which went down to one year.

At fedora 7 time, Core was mostly lost.  There is still the list of
package on the DVD as a guideline though, but there isn't a separate
updates directory you can easily merge in anymore.  To the point that
I didn't find the time to do the new installation before 8 was out.

Now we're at 8 and I want to try to move to it, but static ip support
is fucked, and the list of packages on the DVD doesn't even have tcsh,
which 50% of the people here use.  Installing from the DVD by checking
all 3 options at the top level doesn't even give you make or gcc,
which is kind of annoying when the reason for installing interactively
in the first place is to have everything needed to hack on anaconda to
fix the static ip issue.  An yum install '*' conflicts all the way due
to the multilib crap.

And that's before anybody has even started to *use* the distribution.

Fedora makes me think of E.R., at times.  In the first seasons the
show was about the hospital, and found its public.  Then they seem to
have decided try to extend its viewership by adding a lot on
interpersonal relationships to the point of forgetting the hospital
part.  The old public left, not having what they wanted anymore, and
the potential new one stayed with Gray's Anatomy, which does
relationships much better.  And the viewership is crashing down.

Fedora was originally nice for people coming from an Unix background,
where 50% of the windows on the screen are xterms.  It seems to have
collectively decided that it should instead cater to the Windows kind
of people, to the detriment of the Unix ones.  A default installation
does not have a compiler.  Everything looking slightly technical is
hidden as much as possible.  Easily understandable and editable text
configuration files are routinely replaced by an obfuscated xml-based
registry[1] with automatically generated GUIs from hell[2].  Basic
things like static ips and routes are considered legacy and their
support totally untested and/or considered unimportant.  And
significantly every comparison is done with Ubuntu, the epitome of the
windowsian-come-here distributions, and never with Debian or Gentoo.

Keep cranking up the pain, guys, and fedora will definitively makes
its place in the "master of none" category.

It's kinda sad that people who do such a good job upstream end up
building such a crappier-over-time distribution from it.

  OG.

[1] gconf I'm looking at you

[2] The only thing worse than a GUI designed by a computer scientist
    is a GUI automatically generated from a format description.



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From snecklifter at gmail.com  Wed Nov 21 15:24:38 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 21 Nov 2007 15:24:38 +0000
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <364d303b0711210724q17912993occ60d678c5f3cad6@mail.gmail.com>

Hello Olivier!

On 20/11/2007, Olivier Galibert <galibert at pobox.com> wrote:
> [Sent it personally instead of to the list by mistake]

See, people make mistakes!

> On Tue, Nov 20, 2007 at 06:06:54PM +0100, Lubomir Kundrak wrote:
> >
> > On Tue, 2007-11-20 at 15:51 +0100, Olivier Galibert wrote:
> > > On Tue, Nov 20, 2007 at 08:26:47AM -0600, Josh Boyer wrote:
> > > > Perhaps you should calm down a bit.  Flying off the handle before
> > > > asking if the bug permissions can be changed or an explanation is
> > > > provided is probably not going to be very productive.
> > >
> > > Well, sorry.  Fedora becomes worse for my use with each release I try,
> > > and I'm starting to get really annoyed at that, because it used to be
> > > so much better.
> >
> > May I ask what's "your use"?
>
> My use is a team in a lab with 100-200 machines, about 30 of them
> physically on people's desktops, about 80 in two oscar clusters.  Some
> of the people could do system administration, some couldn't, most
> don't want to anyway.

I don't blame them with this kind of attitude hanging around.

> Since I ended up as sysadmin-by-default, I need a distribution which I
> can install and update with a minimum amount of fussing, and where the
> installation has pretty much everything the users are going to need.

Dude, you're using Fedora? Seriously, I love it but I wouldn't deploy
it large scale. Thats what RHEL or CentOS is for.

> At fedora core 3 times, things were reasonably nice.  You could do an
> everything install, test it for a while to see what was missing and/or
> broken, put the packages and the additionally needed ones in a local
> network repository and go.  And you would be ok for two years.

See above.

> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

See above.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

See above.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

You are insance if you think a "yum install *" will work. Section 8.
Certifiable. As for tcsh that is what kickstart is for as well as make
and gcc.

> And that's before anybody has even started to *use* the distribution.
>
> Fedora makes me think of E.R., at times.  In the first seasons the
> show was about the hospital, and found its public.  Then they seem to
> have decided try to extend its viewership by adding a lot on
> interpersonal relationships to the point of forgetting the hospital
> part.  The old public left, not having what they wanted anymore, and
> the potential new one stayed with Gray's Anatomy, which does
> relationships much better.  And the viewership is crashing down.

And you're the patient with hypochondria.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation
> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.
>
> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Keep on bitching and being rude on devel and I'll use my coffee break
to write these helpful replies.

> It's kinda sad that people who do such a good job upstream end up
> building such a crappier-over-time distribution from it.

Gee thanks, I'm searching for things you've done to help but am scratching.


> [1] gconf I'm looking at you

and I bet its _scared_...

> [2] The only thing worse than a GUI designed by a computer scientist
>     is a GUI automatically generated from a format description.

Fair enough. Scrap those silly GUI's and lets start again. But no
pesky computer scientists this time!

Cheers
Chris

-- 
http://www.chruz.com



From walters at redhat.com  Wed Nov 21 15:41:03 2007
From: walters at redhat.com (Colin Walters)
Date: Wed, 21 Nov 2007 10:41:03 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <1195659663.7424.22.camel@space-ghost.verbum.private>


On Tue, 2007-11-20 at 19:41 +0100, Olivier Galibert wrote:

> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.

Can you explain why you want to actually install all software?  Wouldn't
it be easier to maintain a list of things you do care about?

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use. 

That sounds like a bug.  If we're shipping 4 gigs of stuff, no reason
not to include tiny things like this.

>  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,

The goal of the Fedora Developer spin is to be an excellent environment
out of the box specifically for this.

> It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation
> does not have a compiler. 

The default Live CD does is indeed moving this way.  Because it's crazy
for people who don't need that stuff to download an entire DVD of
compilers and development headers.  

However - you have two options if you're a developer.  First, download
the developer spin from the start.  Second, use pirut to check the
Development Tools group.  

There is also a third option - write your own kickstart file defining
exactly what you want, and use it to install.

> Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant. 

The design was that if you don't have NetworkManager enabled, the system
should have functioned exactly as it has for years.  If it didn't, that
was a bug.  There is ongoing work on a unified network system.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

I don't know about that - Fedora seems to be doing pretty well actually
at shipping a nice "default desktop" out of the box experience on the
Live CD, while still having the thing I used to love about Debian which
was the comprehensive package set (not-quite-mainstream programming
language environments like OCaml, etc.).




From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From buc at odusz.so-cdu.ru  Wed Nov 21 15:43:37 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Wed, 21 Nov 2007 18:43:37 +0300
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120082647.137221b6@weaponx>	<20071120145119.GA26405@dspnet.fr.eu.org>	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <47445229.3060202@odu.neva.ru>

Olivier Galibert wrote:

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.

Yep, it seems a  tendency...

A lot of new people have appeared in the Linux world last years, and 
actually most of them are "coming from the Windows background". The 
first computer which they saw in their life was a Windows desktop. 
Moreover, some of them continue to use Windows desktop, even when works 
for Linux...

Thus it is obvious that they are trying to adopt a "free system" (Linux) 
to their habits. Unfortunately, it is Windows habits, not UNIX...

Perhaps it could be a good idea to provide a "spifit-of-UNIX" Fedora 
spin. Actually, all the packages are (still) present in the common 
"Everything" repository. But I don't know, how many "ancient UNIX users" 
remain in Fedora world. I am. You are. Who else?..

>   A default installation does not have a compiler. 

The default installation (in the modern world) is for "default user". 
The default user want games, office, Internet and xxx. He does not want 
a compiler. He even does not know what is compiler at all.

>  Everything looking slightly technical is hidden as much as possible. 

I hope no more hidden than a text file, or "easy dumpable" (aka .db 
files). Even if it is an xml file, it is easy editable (by vi) from me.

>  Easily understandable and editable text configuration files are routinely replaced 

It is a cost for complexity.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.
>   

It seems a task for people as you and I to provide a "traditional UNIX" 
additional style for Fedora. Remember, a lot of people even do not know 
what is UNIX at all. They never worked under it.

OTOH, If you remember UNIX, it mean that you are 35-45 years old. 
Usually, such people are "in the middle of career", and are busy by 
their work for employer. It is often too difficult to find a time for 
Linux...

> It's kinda sad that people who do such a good job upstream end up
> building such a crappier-over-time distribution from it.
>   

It is a reason why repositories of additional packages (freshmeat, 
atrpms, now rpmfusion) had been appeared.


Regards,
Dmitry Butskoy
            Red Hat Certified Engineer 805007668229091
            http://www.fedoraproject.org/wiki/DmitryButskoy



From benny+usenet at amorsen.dk  Wed Nov 21 15:46:08 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 21 Nov 2007 16:46:08 +0100
Subject: NetworkManager - Why Doesn't nm-applet have a way	of	using
	WPA-PSK?
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <20071120083334.5b50b956@redhat.com>
	<4742E99C.6020500@redhat.com>
	<1195575321.3389.12.camel@localhost.localdomain>
Message-ID: <m3bq9nwqin.fsf@ursa.amorsen.dk>

>>>>> "DW" == Dan Williams <dcbw at redhat.com> writes:

DW> When connecting to an AP that's changed properties, the APs
DW> current properties should override the properties of the
DW> stored connection details. If they don't, it's a bug. But it's
DW> also true that changing the capabilities on the fly isn't as
DW> well tested as connecting to them in the first place, mainly
DW> because people connect to APs much more often than they switch
DW> their APs settings. So I call bug.

The workaround is to select "connect to different wireless network" in
the applet-menu. Then type in the network SSID, and pick the right
encryption.

Not as smart as if NetworkManager detected the encryption switch on
its own, of course, but not a horrible workaround either.


/Benny




From benny+usenet at amorsen.dk  Wed Nov 21 15:49:46 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Wed, 21 Nov 2007 16:49:46 +0100
Subject: NetworkManager - Why Doesn't nm-applet have a way of using
	WPA-PSK?
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <4742E64B.1030404@draigBrady.com>
	<4742E974.1030603@redhat.com> <47433E0B.2000907@gmail.com>
	<604aa7910711201215q42645a35x44da7ac86998f6f3@mail.gmail.com>
Message-ID: <m37ikbwqcl.fsf@ursa.amorsen.dk>

>>>>> "JS" == Jeff Spaleta <jspaleta at gmail.com> writes:

JS> -jef"Can we get pulseaudio to make the flushing sound that gets
JS> played when you use this menu item to bounce back and forth
JS> between your quadraphonic speakers such that the sound spins
JS> around you counter-clockwise if you are in the northern hemisphere
JS> and clockwise if you are in the souther hemisphere?"spaleta

http://www.gi.alaska.edu/ScienceForum/ASF5/523.html

The clockwise/anti-clockwise thing is only visible under carefully
controlled conditions. I.e. not in your average toilet bowl.


/Benny




From snecklifter at gmail.com  Wed Nov 21 15:52:25 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 21 Nov 2007 15:52:25 +0000
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <47445229.3060202@odu.neva.ru>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<47445229.3060202@odu.neva.ru>
Message-ID: <364d303b0711210752n193ced6eqaf99e777fa03be6a@mail.gmail.com>

On 21/11/2007, Dmitry Butskoy <buc at odusz.so-cdu.ru> wrote:
> Olivier Galibert wrote:
>
> > Fedora was originally nice for people coming from an Unix background,
> > where 50% of the windows on the screen are xterms.  It seems to have
> > collectively decided that it should instead cater to the Windows kind
> > of people, to the detriment of the Unix ones.
>
> Yep, it seems a  tendency...
>
> A lot of new people have appeared in the Linux world last years, and
> actually most of them are "coming from the Windows background". The
> first computer which they saw in their life was a Windows desktop.
> Moreover, some of them continue to use Windows desktop, even when works
> for Linux...
>
> Thus it is obvious that they are trying to adopt a "free system" (Linux)
> to their habits. Unfortunately, it is Windows habits, not UNIX...
>
> Perhaps it could be a good idea to provide a "spifit-of-UNIX" Fedora
> spin. Actually, all the packages are (still) present in the common
> "Everything" repository.

and if you want an "Everything" Spin:

http://fedoraunity.org/news-archives/fedora-8-everything-spin-released

Cheers
Chris

-- 
http://www.chruz.com



From tomek at crocom.com.pl  Wed Nov 21 15:54:05 2007
From: tomek at crocom.com.pl (Tomasz Torcz)
Date: Wed, 21 Nov 2007 16:54:05 +0100
Subject: NetworkManager - Why Doesn't nm-applet have a way	of	using
	WPA-PSK?
In-Reply-To: <1195575321.3389.12.camel@localhost.localdomain>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <20071120083334.5b50b956@redhat.com>
	<4742E99C.6020500@redhat.com>
	<1195575321.3389.12.camel@localhost.localdomain>
Message-ID: <1195660446.24597.30.camel@s1.crocom.com.pl>


Dnia 20-11-2007, wto o godzinie 11:15 -0500, Dan Williams pisze:
> When connecting to an AP that's changed properties, the APs current
> properties should override the properties of the stored connection
> details.  If they don't, it's a bug.  But it's also true that changing
> the capabilities on the fly isn't as well tested as connecting to them
> in the first place, mainly because people connect to APs much more often
> than they switch their APs settings.  So I call bug.

 Yes, that's really annoying. Every three months when I change WPA-PSK
password on my AP, I have to dive into gconf and remove my network from
it. If I don'tn NM never asks for new password.


-- 
Tomasz Torcz



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From dwmw2 at infradead.org  Wed Nov 21 16:19:45 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 21 Nov 2007 11:19:45 -0500
Subject: Fedora Core testing
In-Reply-To: <1195652653.10113.1.camel@omar>
References: <1195566284.8287.8.camel@omar>
	<200711200848.03429.dennis@ausil.us>  <1195652653.10113.1.camel@omar>
Message-ID: <1195661985.20963.159.camel@shinybook.infradead.org>

On Wed, 2007-11-21 at 19:14 +0530, Mohammed Omar wrote:
> Ofcourse, generally i raise bugs in IBM bugzilla and that will be
> mirrored out to the community(Redhat bugzilla).

Although I know you are encouraged to do it that way for RHEL bugs, for
Fedora it is the opposite -- please try to file bugs in Fedora bugzilla
directly.

Also, it would be very useful if we could get you to help us with
testing in _advance_ of the releases. Especially on PowerPC as we
approach Fedora 9, we would like more people to be testing rawhide as we
prepare to make the Alpha/Beta/etc. releases. 

-- 
dwmw2



From wtogami at redhat.com  Wed Nov 21 16:35:55 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 21 Nov 2007 11:35:55 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <e6c711510711202323s1b8bbbc2rdbd7d95906bbff58@mail.gmail.com>
References: <4743C7CF.4000904@redhat.com>
	<e6c711510711202323s1b8bbbc2rdbd7d95906bbff58@mail.gmail.com>
Message-ID: <47445E6B.3010605@redhat.com>

Ed Swierk wrote:
> On 11/20/07, Warren Togami <wtogami at redhat.com> wrote:
>> BUGS TO FIX TO MAKE IT ACTUALLY WORK
>> - wget --server-response http://PATH/TO/LARGE/FILE
>>   It constantly redirects over and over again rather than waiting.
>>   FILE.tmp never gets larger than 8192 or 16384 bytes.
> 
> Hmm, my setup doesn't do that. What upstream server are you using, and
> which release of Fedora? I am running it on an FC6 machine, using
> http://linux.nssl.noaa.gov .

Fedora 8 with http://download.fedora.redhat.com

> 
>> - We MUST find a way so the client can begin downloading the file while
>> the mirror downloads the file.  Any other reverse proxy server would
>> allow this.  This might be difficult to implement (perhaps impossible
>> with mod_python?) but this might be the only sane way to fix the
>> previous problem.
> 
> I don't think this has anything to do with the problem above. This
> would be a nice enhancement, though. It does complicate the
> implementation, especially to handle byte range requests properly.

It does complicate the implementation, but unfortunately this will be a 
completely necessary feature.

> 
>> - Even if apache:apache owns DocumentRoot, SELinux denies by default.
>>   Need sane solution.
> 
> I haven't yet tested on a machine with SELinux enabled.
> 
> I've attached an updated version of ApacheMirror.py with a redirection
> bug fixed; previously it omitted the http://server part of the URL,
> confusing some clients like Anaconda. I don't expect this to fix the
> problem you're seeing, though.
> 
> --Ed
> 

Did you checkout the initial repo?

Warren



From jameshubbard at gmail.com  Wed Nov 21 16:35:44 2007
From: jameshubbard at gmail.com (James Hubbard)
Date: Wed, 21 Nov 2007 11:35:44 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195659663.7424.22.camel@space-ghost.verbum.private>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
Message-ID: <f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>

On Nov 21, 2007 10:41 AM, Colin Walters <walters at redhat.com> wrote:
> On Tue, 2007-11-20 at 19:41 +0100, Olivier Galibert wrote:
>
> > At fedora core 5 times, Everything was lost.  Thankfully it is still
> > in kickstart, but it makes the initial testing phase more annoying.
>
> Can you explain why you want to actually install all software?  Wouldn't
> it be easier to maintain a list of things you do care about?

There are 80 machines in a cluster.  He has 30 boxes sitting on desks.
 There are potentially another 90 machines.  It sounds like a mixed
use environment in a location like a school.  He might know what
applications he wants, but it's doubtful that he can anticipate all of
the needs of his users.  It's easier to just install everything and
let them use what they want.  It minimizes the number of calls that he
has to field from his users requesting that something be installed.

The other issue is changing package names.  I don't know how stable
the names have been especially for the more obscure software. It looks
like there have not been many name changes to the packages from one
release to the next.  How about from 2 or 3 releases previously? It's
another area where time would have to be expended to check the names
of the packages on the list.

I personally don't like to install everything.  I know developers who
like to install all so they don't have to go track down packages later
when they need them.  This is especially true when you're in an
environment where you don't have high speed Internet access all of the
time.

An example of this is when FC5 came out I had to figure out which
packages were needed to compile a piece of software.  I knew that
openmotif was needed.  I addition to that xorg-xbitmaps and libXp were
needed.  It took a while before I was able to find everything that was
needed.  It was  PITA.

Carrying the original DVD doesn't work either.  What if something on
the DVD is needed but can't be installed because another package has
been updated and causes a conflict?

Some people have mentioned using RHEL 5.  I don't use it because it
doesn't have most of the things that I want.  If it does have
something I need, it's usually too out of date.  I understand the
reason why it is this way so you don't have to explain its purpose.

I know of at least 3 people that have or are in the process of moving
from Fedora to Ubuntu because their perception is that it "just
works".   This is related to the video card, wireless, and codecs for
web use.  Yes, I know why Fedora can't include these.

You probably don't care, but I just upgraded from FC6 to F7 so that my
wireless would work.  Why not F8?  When I read the emails that Sun's
JVM wouldn't work on F8, I stopped considering it due to my dependence
on a couple of Java apps.  I couldn't spend the time tracking down
bugs related to an incomplete runtime environment.  I know that it's
not anyone's fault on the list, but that's just the way that it is.

Just  my $0.01 for what it's worth.

-- 
James Hubbard
http://soweva.blogspot.com



From jspaleta at gmail.com  Wed Nov 21 16:45:18 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 07:45:18 -0900
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <364d303b0711210724q17912993occ60d678c5f3cad6@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<364d303b0711210724q17912993occ60d678c5f3cad6@mail.gmail.com>
Message-ID: <604aa7910711210845y597a7f66jf17c1063707b2fda@mail.gmail.com>

On Nov 21, 2007 6:24 AM, Christopher Brown <snecklifter at gmail.com> wrote:
> Fair enough. Scrap those silly GUI's and lets start again. But no
> pesky computer scientists this time!

I've seen gui's designed and built by research physicists. Please,
pretty please, let's keep a few computer scientists and interaction
designers in the mix.  I don't want to feel that level of pain when
doing things like online banking.

-jef



From walters at redhat.com  Wed Nov 21 17:02:09 2007
From: walters at redhat.com (Colin Walters)
Date: Wed, 21 Nov 2007 12:02:09 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
Message-ID: <1195664529.7424.29.camel@space-ghost.verbum.private>


On Wed, 2007-11-21 at 11:35 -0500, James Hubbard wrote:

> There are 80 machines in a cluster.  He has 30 boxes sitting on desks.
>  There are potentially another 90 machines.  It sounds like a mixed
> use environment in a location like a school.  He might know what
> applications he wants, but it's doubtful that he can anticipate all of
> the needs of his users.  It's easier to just install everything and
> let them use what they want.  It minimizes the number of calls that he
> has to field from his users requesting that something be installed.

What this says to me is that we need to make it a more seamless
experience for if you don't find something in the main menu, to get it
installed.  We have the "Add/Remove Software" link but unfortunately
it's based on packages which aren't the same thing as applications.
There is work going on around this which might land in the Fedora 9
timeframe.

> I personally don't like to install everything.  I know developers who
> like to install all so they don't have to go track down packages later
> when they need them.  

Right, we should also make it trivial to cache whatever RPMs you want in
the yum cache.  That's not the same thing as having them installed.




From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From jspaleta at gmail.com  Wed Nov 21 17:03:44 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 08:03:44 -0900
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195659663.7424.22.camel@space-ghost.verbum.private>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
Message-ID: <604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>

On Nov 21, 2007 6:41 AM, Colin Walters <walters at redhat.com> wrote:
> There is also a third option - write your own kickstart file defining
> exactly what you want, and use it to install.

I'd like to see if we as a project can extend this option, so that we
can archive and make a gallery of contributed kickstart files for
people to use for niche usage cases.  Perhaps then Olivier could work
with other niche admins who want to beat Fedora into submission to
create a suitable baseline kickstart for his usage case.

We certainly can't keep resulting spins for everyone's pet kickstart
file. But if people submitted them we could perhaps run automated
tests against registered kickstart files leading up to a release to
help the kickstart sheperds  discover kickstart file breakage in a
timely manner prior to release.

More specifically, it might be instructional to think about how we
could better serve a multiple system install mixed use case as drastic
as Olivier's.  Without re-hashing any of his particular grievances. If
anyone of us were going to attempt to do a 50-100 machine Fedora
install for mixed usage, what would we do to make it go smoothly? And
out of those things, what could Fedora project do to help make it
easier.  Off the top of my head, would it be useful if Fedora has a
project released a spin which was designed to help an admin create a
local fedora mirror for use with local machines?

-jef"giggles at all the tcsh users he works with"spaleta



From tmz at pobox.com  Wed Nov 21 17:05:48 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 21 Nov 2007 12:05:48 -0500
Subject: libgpod soname bump coming to rawhide
In-Reply-To: <604aa7910711201329p57535fa6u14f0acf30e0996f5@mail.gmail.com>
References: <20071120172929.GB2967@psilocybe.teonanacatl.org>
	<604aa7910711201329p57535fa6u14f0acf30e0996f5@mail.gmail.com>
Message-ID: <20071121170548.GG2967@psilocybe.teonanacatl.org>

Jeff Spaleta wrote:
> You are rebuilding python-gpod as well right?

Yep, python-gpod is built as part of libgpod now.  There aren't many
(if any) changes that should be noticeable python-gpod using apps, so
nothing should break.

Of course, you probably know better than to have blind faith in such
statements and to give gpodder a little testing to verify.  :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Teach a man to make fire, and he will be warm for a day.  Set a man on
fire, and he will be warm for the rest of his life.
    -- John A. Hrastar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/a0800e48/attachment.sig>

From skvidal at fedoraproject.org  Wed Nov 21 17:01:45 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 21 Nov 2007 12:01:45 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195664529.7424.29.camel@space-ghost.verbum.private>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
Message-ID: <1195664505.2291.0.camel@cutter>


On Wed, 2007-11-21 at 12:02 -0500, Colin Walters wrote:
> On Wed, 2007-11-21 at 11:35 -0500, James Hubbard wrote:
> 
> > There are 80 machines in a cluster.  He has 30 boxes sitting on desks.
> >  There are potentially another 90 machines.  It sounds like a mixed
> > use environment in a location like a school.  He might know what
> > applications he wants, but it's doubtful that he can anticipate all of
> > the needs of his users.  It's easier to just install everything and
> > let them use what they want.  It minimizes the number of calls that he
> > has to field from his users requesting that something be installed.
> 
> What this says to me is that we need to make it a more seamless
> experience for if you don't find something in the main menu, to get it
> installed.  We have the "Add/Remove Software" link but unfortunately
> it's based on packages which aren't the same thing as applications.
> There is work going on around this which might land in the Fedora 9
> timeframe.
> 
> > I personally don't like to install everything.  I know developers who
> > like to install all so they don't have to go track down packages later
> > when they need them.  
> 
> Right, we should also make it trivial to cache whatever RPMs you want in
> the yum cache.  That's not the same thing as having them installed.

1. I thought this was what warren was working on w/instant mirror
2. you can create a 'this is my cache' with repotrack, too.
3. if you don't want to purge your local cache just set keeplocal=1 in
your yum.conf

-sv




From dcbw at redhat.com  Wed Nov 21 17:03:30 2007
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 21 Nov 2007 12:03:30 -0500
Subject: NetworkManager - Why Doesn't nm-applet have a way	of	using
	WPA-PSK?
In-Reply-To: <1195660446.24597.30.camel@s1.crocom.com.pl>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <20071120083334.5b50b956@redhat.com>
	<4742E99C.6020500@redhat.com>
	<1195575321.3389.12.camel@localhost.localdomain>
	<1195660446.24597.30.camel@s1.crocom.com.pl>
Message-ID: <1195664610.4877.5.camel@localhost.localdomain>

On Wed, 2007-11-21 at 16:54 +0100, Tomasz Torcz wrote:
> Dnia 20-11-2007, wto o godzinie 11:15 -0500, Dan Williams pisze:
> > When connecting to an AP that's changed properties, the APs current
> > properties should override the properties of the stored connection
> > details.  If they don't, it's a bug.  But it's also true that changing
> > the capabilities on the fly isn't as well tested as connecting to them
> > in the first place, mainly because people connect to APs much more often
> > than they switch their APs settings.  So I call bug.
> 
>  Yes, that's really annoying. Every three months when I change WPA-PSK
> password on my AP, I have to dive into gconf and remove my network from
> it. If I don'tn NM never asks for new password.

F7 or F8?  There's some known bugs with 0.6.x that cause it never to ask
for a new password when a WEP key changes, probably the same thing for
WPA too.

Dan




From tmz at pobox.com  Wed Nov 21 17:08:27 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 21 Nov 2007 12:08:27 -0500
Subject: libgpod soname bump coming to rawhide
In-Reply-To: <Pine.GSO.4.60.0711202146001.10992@igloo.df.lth.se>
References: <20071120172929.GB2967@psilocybe.teonanacatl.org>
	<Pine.GSO.4.60.0711202146001.10992@igloo.df.lth.se>
Message-ID: <20071121170827.GH2967@psilocybe.teonanacatl.org>

Linus Walleij wrote:
> I agree. Please, this time (as we're rebuilding Amarok) let's sync
> it with the imminent update of libmtp soname found in
> https://bugzilla.redhat.com/show_bug.cgi?id=359401 if you have a BZ
> ticket for libgpod then reference this to the libmtp update please.

Okay.  Assuming all goes well in rawhide, I'll coordinate with you so
we can get all the updates done smoothly.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fleas can be taught nearly anything that a Congressman can.
    -- Mark Twain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/4ed7d0e9/attachment.sig>

From marcelo.gobelli at gmail.com  Wed Nov 21 17:12:45 2007
From: marcelo.gobelli at gmail.com (marcelo gobelli)
Date: Wed, 21 Nov 2007 09:12:45 -0800
Subject: information
In-Reply-To: <72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
	<ufak5ogi5yh.fsf@epithumia.math.uh.edu>
	<72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>
Message-ID: <72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>

jason,
i sent an email to will woods at redhat but I have not heard from him. I
think I could help with testing.
marcelo


On 11/18/07, marcelo gobelli <marcelo.gobelli at gmail.com> wrote:
>
> OS developer. what's next? thanks
>
> On 17 Nov 2007 21:32:38 -0600, Jason L Tibbitts III <tibbs at math.uh.edu>
> wrote:
> >
> > >>>>> "mg" == marcelo gobelli <marcelo.gobelli at gmail.com > writes:
> >
> > mg> how can I get involved with the fedora project. I would like to
> > mg> help but I did not know how. any ideas?
> >
> > Well, it helps to know what you'd like to do.  But you can get some
> > really good information just by going to the project's web page
> > http://fedoraproject.org and clicking the "Join Fedora" link.
> >
> > - J<
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/d26e1971/attachment.htm>

From cjdahlin at ncsu.edu  Wed Nov 21 17:32:36 2007
From: cjdahlin at ncsu.edu (Casey Dahlin)
Date: Wed, 21 Nov 2007 12:32:36 -0500
Subject: AWOL: jpo
In-Reply-To: <1195584085.2465.8.camel@localhost6.localdomain6>
References: <851272.31889.qm@web60523.mail.yahoo.com>
	<1195584085.2465.8.camel@localhost6.localdomain6>
Message-ID: <47446BB4.5030804@ncsu.edu>

Richi Plana wrote:
> On Tue, 2007-11-20 at 10:03 -0800, Timothy Spaulding wrote:
>   
>> Me too...   Good luck finding a new Perl maintainer...  :)  He/she
>> sits right next to the Assembler programmer.  :)
>>     
>
> <wistful-musing off-topic="true">
> As much as I love Perl and I prefer it over all existing scripting
> languages I'm familiar with, it's hard to get excited about its future
> since the developers are extremely quiet about it. My only hope now is
> that other scripting languages pick up the little things that make
> developing in Perl a joy so that I and many others like me can move on.
>
> *sigh*
> </wistful-musing>
> --
>
> Richi Plana
>
>   
<certain-to-start-massive-flame>
Have you tried ruby?
</certain-to-start-massive-flame>



From roopesh.majeti at gmail.com  Wed Nov 21 17:41:58 2007
From: roopesh.majeti at gmail.com (roopesh majeti)
Date: Wed, 21 Nov 2007 23:11:58 +0530
Subject: information
In-Reply-To: <72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
	<ufak5ogi5yh.fsf@epithumia.math.uh.edu>
	<72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>
	<72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>
Message-ID: <599059470711210941q2c0c78dfscd3e74b911d7ab47@mail.gmail.com>

Just wanna add myself to the request list. I want to contribute too my
services to fedora dev/testing.
Please let me also know whatz the next steps.



On 11/21/07, marcelo gobelli <marcelo.gobelli at gmail.com> wrote:
>
> jason,
> i sent an email to will woods at redhat but I have not heard from him. I
> think I could help with testing.
> marcelo
>
>
>  On 11/18/07, marcelo gobelli <marcelo.gobelli at gmail.com> wrote:
> >
> > OS developer. what's next? thanks
> >
> > On 17 Nov 2007 21:32:38 -0600, Jason L Tibbitts III < tibbs at math.uh.edu>
> > wrote:
> > >
> > > >>>>> "mg" == marcelo gobelli < marcelo.gobelli at gmail.com > writes:
> > >
> > > mg> how can I get involved with the fedora project. I would like to
> > > mg> help but I did not know how. any ideas?
> > >
> > > Well, it helps to know what you'd like to do.  But you can get some
> > > really good information just by going to the project's web page
> > > http://fedoraproject.org and clicking the "Join Fedora" link.
> > >
> > > - J<
> > >
> > > --
> > > fedora-devel-list mailing list
> > > fedora-devel-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> > >
> >
> >
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/0406bae7/attachment.htm>

From jspaleta at gmail.com  Wed Nov 21 17:42:15 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 08:42:15 -0900
Subject: NetworkManager - Why Doesn't nm-applet have a way of using
	WPA-PSK?
In-Reply-To: <m37ikbwqcl.fsf@ursa.amorsen.dk>
References: <474279D1.7060709@gmail.com>
	<1195539293.3640.8.camel@jndwidescreen.lesbg.loc>
	<4742845F.8030606@gmail.com> <47428C23.6030507@gmail.com>
	<4742E17D.5070906@redhat.com> <4742E64B.1030404@draigBrady.com>
	<4742E974.1030603@redhat.com> <47433E0B.2000907@gmail.com>
	<604aa7910711201215q42645a35x44da7ac86998f6f3@mail.gmail.com>
	<m37ikbwqcl.fsf@ursa.amorsen.dk>
Message-ID: <604aa7910711210942k3617f381r21e75fb3c813c074@mail.gmail.com>

On Nov 21, 2007 6:49 AM, Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> http://www.gi.alaska.edu/ScienceForum/ASF5/523.html
> The clockwise/anti-clockwise thing is only visible under carefully
> controlled conditions. I.e. not in your average toilet bowl.

Are you suggesting that a fedora install with NM and pulseaudio is an
average toilet bowl?

-jef"Oh sweet irony!  Being quoted a url from the institute where I
work, to refute my absurd request, bravo"spaleta



From snecklifter at gmail.com  Wed Nov 21 17:59:49 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 21 Nov 2007 17:59:49 +0000
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
Message-ID: <364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>

On 21/11/2007, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Nov 21, 2007 6:41 AM, Colin Walters <walters at redhat.com> wrote:
> > There is also a third option - write your own kickstart file defining
> > exactly what you want, and use it to install.
>
> I'd like to see if we as a project can extend this option, so that we
> can archive and make a gallery of contributed kickstart files for
> people to use for niche usage cases.  Perhaps then Olivier could work
> with other niche admins who want to beat Fedora into submission to
> create a suitable baseline kickstart for his usage case.
>
> We certainly can't keep resulting spins for everyone's pet kickstart
> file. But if people submitted them we could perhaps run automated
> tests against registered kickstart files leading up to a release to
> help the kickstart sheperds  discover kickstart file breakage in a
> timely manner prior to release.
>
> More specifically, it might be instructional to think about how we
> could better serve a multiple system install mixed use case as drastic
> as Olivier's.  Without re-hashing any of his particular grievances. If
> anyone of us were going to attempt to do a 50-100 machine Fedora
> install for mixed usage, what would we do to make it go smoothly? And
> out of those things, what could Fedora project do to help make it
> easier.  Off the top of my head, would it be useful if Fedora has a
> project released a spin which was designed to help an admin create a
> local fedora mirror for use with local machines?

Maybe I'm missing something but I thought this is what tools like
pungi and such were created for.

If that is the consideration though spins.f.o would be the place I
imagine for hosting this if custom kickstarts were really what you
wanted - hell, you could even have a custom kickstart file repository,
specify it by name at install and off it goes...?

If it were me though for 50 + installs I'd cook up a spin and deploy.

Cheers
Chris

-- 
http://www.chruz.com



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From jima at beer.tclug.org  Wed Nov 21 18:04:33 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 21 Nov 2007 12:04:33 -0600 (CST)
Subject: Smolt database is broken
In-Reply-To: <474334BB.1080002@redhat.com>
References: <3e4ec4600711190231j510729a6i94a018b5041582e8@mail.gmail.com>
	<200711191813.45675.kewley@gps.caltech.edu>
	<7f692fec0711192032g5263f7fclf3a09654c3508424@mail.gmail.com>
	<20071120115203.GA3361@devserv.devel.redhat.com>
	<474334BB.1080002@redhat.com>
Message-ID: <Pine.LNX.4.64.0711211157150.17671@beer.tclug.org>

On Tue, 20 Nov 2007, Mike McGrath wrote:
> If we take the last one as an example has come from over 800 IP's in the 
> last 20 days.  It seems very unlikely that one person would find his way 
> to 800 different IP's this month.

  I've got a WRT54GL running OpenWRT on a DSL line with PPPoE auth, and it 
appears to hop IPs as many as 3-4 times a day.  Alas, that only gets up to 
about 90 IPs a month at most.  (So far this month, it's changed 49 times. 
Geez.)  So while not the extreme number you speak of, it is a little 
ridiculous. :-)

      Jima



From snecklifter at gmail.com  Wed Nov 21 18:07:44 2007
From: snecklifter at gmail.com (Christopher Brown)
Date: Wed, 21 Nov 2007 18:07:44 +0000
Subject: information
In-Reply-To: <72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
	<ufak5ogi5yh.fsf@epithumia.math.uh.edu>
	<72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>
	<72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>
Message-ID: <364d303b0711211007k2677005as460e93e3eefe0ab8@mail.gmail.com>

On 21/11/2007, marcelo gobelli <marcelo.gobelli at gmail.com> wrote:
> jason,
> i sent an email to will woods at redhat but I have not heard from him. I
> think I could help with testing.
> marcelo

Can you be more specific with what you'd like to do? I guess you have seen:

http://fedoraproject.org/wiki/FedoraTesting

I find working through bugs in bugzilla to be quite rewarding.

http://fedoraproject.org/wiki/BugZappers

What languages are you familiar with? What is your background? Don't
be afraid to speak up., although I would highly recommend using
(subscribing) to the fedora-test-list which is dedicated to testing
releases.

Cheers
Chris

-- 
http://www.chruz.com



From jspaleta at gmail.com  Wed Nov 21 18:11:44 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 09:11:44 -0900
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
	<364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>
Message-ID: <604aa7910711211011n4cb83702t8a10fb990eff825b@mail.gmail.com>

On Nov 21, 2007 8:59 AM, Christopher Brown <snecklifter at gmail.com> wrote:
> Maybe I'm missing something but I thought this is what tools like
> pungi and such were created for.

Right we've got the baseline tools. What I saying is perhaps F9 is
when we extend how we use those tools as a service for our userbase
who are maintaining kickstart files for themselves. Can we let people
submit kickstart files and as part of F9 testing run those kickstart
files against our compose tools looking for breakage, missing packages
or new conflicts?  We don't actually compose a spin for all submitted
kickstart files, but can we test to see if all those submitted
kickstart files will compose and report back to the authors so they
can fix it?

-jef



From eswierk at arastra.com  Wed Nov 21 18:14:39 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Wed, 21 Nov 2007 10:14:39 -0800
Subject: InstantMirror initial source repo
In-Reply-To: <47445E6B.3010605@redhat.com>
References: <4743C7CF.4000904@redhat.com>
	<e6c711510711202323s1b8bbbc2rdbd7d95906bbff58@mail.gmail.com>
	<47445E6B.3010605@redhat.com>
Message-ID: <e6c711510711211014y52efa605x5d227d58d2697640@mail.gmail.com>

On 11/21/07, Warren Togami <wtogami at redhat.com> wrote:
> Did you checkout the initial repo?

I did, and just implemented a workaround for the problem you found
with wget on F8.

--Ed



From jima at beer.tclug.org  Wed Nov 21 18:25:13 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 21 Nov 2007 12:25:13 -0600 (CST)
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <1195659663.7424.22.camel@space-ghost.verbum.private>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
Message-ID: <Pine.LNX.4.64.0711211222310.17671@beer.tclug.org>

On Wed, 21 Nov 2007, Colin Walters wrote:
> On Tue, 2007-11-20 at 19:41 +0100, Olivier Galibert wrote:
>> It seems to have
>> collectively decided that it should instead cater to the Windows kind
>> of people, to the detriment of the Unix ones.  A default installation
>> does not have a compiler.
>
> The default Live CD does is indeed moving this way.  Because it's crazy
> for people who don't need that stuff to download an entire DVD of
> compilers and development headers.
>
> However - you have two options if you're a developer.  First, download
> the developer spin from the start.  Second, use pirut to check the
> Development Tools group.

Third, pull that stuff in via kickstart to begin with.

Fourth, `yum groupinstall "Development Tools"` -- can be done via 
clusterssh or such.

  Not saying you're wrong, Colin -- you're actually more right than you 
might have thought. ;-)

      Jima



From galibert at pobox.com  Wed Nov 21 18:49:08 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 21 Nov 2007 19:49:08 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195664529.7424.29.camel@space-ghost.verbum.private>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
Message-ID: <20071121184908.GA38223@dspnet.fr.eu.org>

On Wed, Nov 21, 2007 at 12:02:09PM -0500, Colin Walters wrote:
> What this says to me is that we need to make it a more seamless
> experience for if you don't find something in the main menu, to get it
> installed.  We have the "Add/Remove Software" link but unfortunately
> it's based on packages which aren't the same thing as applications.
> There is work going on around this which might land in the Fedora 9
> timeframe.

You're thinking laptop again.  An add/remove software link is not
going to replicate the installation on all the machines that
particular person uses.  The desktops have a tendency to be X
terminals on steroids, and the real work is done on computers in racks
one or two stairs up[1].

  OG.

[1] Yes, we have the main server room on {US 3rd|EU 2nd} floor.  Yes,
    I know.



From jspaleta at gmail.com  Wed Nov 21 18:52:31 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 09:52:31 -0900
Subject: File conflicts, how do they work at that point?
In-Reply-To: <alpine.DEB.0.9999.0711211049390.32062@gotcha.dreamhost.com>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<alpine.DEB.0.9999.0711211029430.32062@gotcha.dreamhost.com>
	<4743EDF4.4090106@fedoraproject.org>
	<alpine.DEB.0.9999.0711211049390.32062@gotcha.dreamhost.com>
Message-ID: <604aa7910711211052k31da331bpb89a8f8d47d49acf@mail.gmail.com>

On Nov 20, 2007 11:57 PM, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> That's the very reason bug #190209 is being dusted off at the moment :)

Can you hit the big red battle station's button a couple of days
before a build with this change lands in rawhide?  We'll need to try
to gather a 64bit multilib response team and probably have a dedicated
tracker bug for file conflicts that get unearthed due to this change.

-jef



From nicolas.mailhot at laposte.net  Wed Nov 21 18:55:01 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 21 Nov 2007 19:55:01 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
	<364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>
Message-ID: <1195671301.16333.11.camel@rousalka.dyndns.org>


Le mercredi 21 novembre 2007 ? 17:59 +0000, Christopher Brown a ?crit :

> If it were me though for 50 + installs I'd cook up a spin and deploy.

If it were me for 50+ mixed installs I'd just setup a fedora everything
mirror and create a set of kickstarts corresponding to my needs.

And I'd probably curse Fedora developers for designing a system where
comps groups are an all-or-nothing thing, and you can not define a set
of profiles that reuse common elements.

(You can of course fork the same root comps, that's how spins work, and
then you get comps sync maintenance nightmare)

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/a2016965/attachment.sig>

From tmz at pobox.com  Wed Nov 21 19:02:09 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 21 Nov 2007 14:02:09 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <4743C7CF.4000904@redhat.com>
References: <4743C7CF.4000904@redhat.com>
Message-ID: <20071121190209.GI2967@psilocybe.teonanacatl.org>

Warren Togami wrote:
> - Even if apache:apache owns DocumentRoot, SELinux denies by default.
>  Need sane solution.

Is this just a matter of setting the right file context?  Something
like:

semanage fcontext -a -t httpd_sys_content_t "/InstantMirrorPath(/.*)?"

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If age imparted wisdom, there wouldn't be any old fools.
    -- Claudia Young

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/cc3ad08d/attachment.sig>

From galibert at pobox.com  Wed Nov 21 19:02:46 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 21 Nov 2007 20:02:46 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121151510.GA21330@wolff.to>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
Message-ID: <20071121190246.GB38223@dspnet.fr.eu.org>

On Wed, Nov 21, 2007 at 09:15:10AM -0600, Bruno Wolff III wrote:
> I still run Fedora 5 on one machine because of a kernel bug. It works well
> for me.

Oh yes, it was definitively a very good release.  It's still the #1
here.  Too bad it has issues with nfs (race conditions in autofs4,
fixed in 5) and the kernel is getting too old for current hardware.


> The "everything" repository exists and I use a local copy of it to do
> yum upgrades. Having core and extras combined seems to be a much nicer
> approach than what was done previously. The Unity people have even put
> out a multiDVD "Everything" spin.

A "everything" repository is something different.  "Core" was a bunch
of packages you could all install together without conflicts and you
ended up with something rather nice.  Then extras allowed you to add
what your specific needs required.

The current DVD package list, which is supposed to replace Core from
what was said, does not install as-is (conflict between generic-logos
and fedora-logos, conflicts everywhere with multilib).  I don't know
about the "nice" part yet, I've yet to be able to install it
completely.


> I use static IP addresses and don't have a problem with that. I don't use
> NM though. There are some advanced things I do using iproute2 in rc.local,
> but the plain stuff can be done with system-config-network.

You can't do a kickstart install with a static IP.  It's just a bug,
though, not by design.


> Well, there is definitely pain involved with Fedora. That's best helped by
> having some people volunteer to try rawhide to catch issues early.

All these issues are at installation time and as such don't really
show up in rawhide.

  OG.



From jspaleta at gmail.com  Wed Nov 21 19:03:34 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 10:03:34 -0900
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071121184908.GA38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
Message-ID: <604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>

On Nov 21, 2007 9:49 AM, Olivier Galibert <galibert at pobox.com> wrote:
> You're thinking laptop again.  An add/remove software link is not
> going to replicate the installation on all the machines that
> particular person uses.  The desktops have a tendency to be X
> terminals on steroids, and the real work is done on computers in racks
> one or two stairs up[1].

Question... can you dedicate one machine to run a local service that
helps you keep track of the packages installed across multiple
machines?
As in when someone acting as a local administrator on a desktop
installs something via Add/remove would you be willing to run a
central service that 'sees' those additional packages and adds that to
a aggregate list or database that you can then use to install the same
software on other machines which should have it?

Would that give you the sort of control you are looking for?
Individuals control their own desktop software and then new software
additions can propogate through to additional machines through a
central aggregate service which keeps track of who is installing what
on their desktops.

-jef



From jkeating at redhat.com  Wed Nov 21 19:08:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Nov 2007 14:08:24 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195671301.16333.11.camel@rousalka.dyndns.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
	<364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>
	<1195671301.16333.11.camel@rousalka.dyndns.org>
Message-ID: <20071121140824.02cd5e21@redhat.com>

On Wed, 21 Nov 2007 19:55:01 +0100
Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

> And I'd probably curse Fedora developers for designing a system where
> comps groups are an all-or-nothing thing, and you can not define a set
> of profiles that reuse common elements.
> 
> (You can of course fork the same root comps, that's how spins work,
> and then you get comps sync maintenance nightmare)


What are you talking about?  Exactly one comps is used for all the
spins.  We use a manifest in a kickstart file to select which groups,
packages, or excludes to use against that comps and the Everything repo
to decide what goes into a spin.  You can even specify if you want just
the mandatory, mandatory + defaults, or even mandatory + all optional
packages.

Hell you can even break out the individual packages and list just a few
mandatory for a group and that group option will still show up, you'll
only get what's available in the repo for that group.

So please, maybe I misunderstood you, but how is comps all-or-nothing?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/a2941b6c/attachment.sig>

From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From galibert at pobox.com  Wed Nov 21 19:30:02 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Wed, 21 Nov 2007 20:30:02 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <47445229.3060202@odu.neva.ru>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<47445229.3060202@odu.neva.ru>
Message-ID: <20071121193002.GC38223@dspnet.fr.eu.org>

On Wed, Nov 21, 2007 at 06:43:37PM +0300, Dmitry Butskoy wrote:
> Olivier Galibert wrote:
> >  A default installation does not have a compiler. 
> 
> The default installation (in the modern world) is for "default user". 
> The default user want games, office, Internet and xxx. He does not want 
> a compiler. He even does not know what is compiler at all.

Are you so sure of that?  The people around me that could possibly be
contented with that won't change the OS that came with their computer
anyway.  One the the gripes against Windows of the others is that
there is nothing you can do with a standard install.

And, frankly, have you seen the price of a gigabyte recently in the
western world?  Some people here seem to consider me insane because I
want to install a 10-15G system instead of 2.5G.  Meanwhile, there are
friggin' mp3 players with 160G of space, and my home computer has 800G
and will go to 2T with the next upgrade.

Even more than an office suite, the default install should have a
comprehensive backup suite.  Not sure such a beast exists in open
source though.


> OTOH, If you remember UNIX, it mean that you are 35-45 years old. 

I'm 36, good guess.  OTOH I've seen a linguist of 28 fall in love with
the Unix way because it's *way* more efficient when you want to handle
a decent amount of data.  She now has mysql on her laptop.


> Usually, such people are "in the middle of career", and are busy by 
> their work for employer. It is often too difficult to find a time for 
> Linux...

Tell me about it.

  OG.



From jima at beer.tclug.org  Wed Nov 21 19:30:46 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 21 Nov 2007 13:30:46 -0600 (CST)
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071121184908.GA38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
Message-ID: <Pine.LNX.4.64.0711211329540.17671@beer.tclug.org>

On Wed, 21 Nov 2007, Olivier Galibert wrote:
> [1] Yes, we have the main server room on {US 3rd|EU 2nd} floor.  Yes,
>    I know.

  That's not "bad design," that's "inherent flood protection." ;-)

      Jima



From tonynelson at georgeanelson.com  Wed Nov 21 19:44:32 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Wed, 21 Nov 2007 14:44:32 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <4743C7CF.4000904@redhat.com>
References: <4743C7CF.4000904@redhat.com>
Message-ID: <p04330103c36a0d4bbcb4@[192.168.123.162]>

At 12:53 AM -0500 11/21/07, Warren Togami wrote:
>bzr branch http://fedorapeople.org/~wtogami/temp/InstantMirror/
>It will be located here until the official hosted repository is created.
>
>cd InstantMirror
>./mkdist --force
>rpmbuild -ta /tmp/InstantMirror-0.1.tar.bz2
>rpm -ivh /path/to/InstantMirror-0.1.noarch.rpm
>vim /etc/httpd/conf.d/InstantMirror.conf
>service httpd restart (will probably fail due to SELinux denial)
>
>Unfortunately, I discovered that the ApacheMirror.py (renamed
>InstantMirror.py in this repo) has a critical bug that makes it unusable
>in current form.  From the TODO file:
>
>BUGS TO FIX TO MAKE IT ACTUALLY WORK
>- wget --server-response http://PATH/TO/LARGE/FILE
>   It constantly redirects over and over again rather than waiting.
>   FILE.tmp never gets larger than 8192 or 16384 bytes.
>- We MUST find a way so the client can begin downloading the file while
>the mirror downloads the file.  Any other reverse proxy server would
>allow this.  This might be difficult to implement (perhaps impossible
>with mod_python?) but this might be the only sane way to fix the
>previous problem.

I'm new to mod_python, but it is documented to be able to do /anything/
that could be a response from Apache.  If the handler were to fetch the
data itself it could write a local file and also return the data to the
client, by calling urlopen() and then read(), write(), and req.write()
repeatedly.  I don't know if the reads and writes will overlap.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From nicolas.mailhot at laposte.net  Wed Nov 21 19:58:06 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 21 Nov 2007 20:58:06 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071121140824.02cd5e21@redhat.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
	<364d303b0711210959o1d76f80fu7ab175772b37f0b1@mail.gmail.com>
	<1195671301.16333.11.camel@rousalka.dyndns.org>
	<20071121140824.02cd5e21@redhat.com>
Message-ID: <1195675086.16863.33.camel@rousalka.dyndns.org>


Le mercredi 21 novembre 2007 ? 14:08 -0500, Jesse Keating a ?crit :
> On Wed, 21 Nov 2007 19:55:01 +0100
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> > And I'd probably curse Fedora developers for designing a system where
> > comps groups are an all-or-nothing thing, and you can not define a set
> > of profiles that reuse common elements.

> What are you talking about?

When you manage that order of systems you need a careful balancing act
between customisation and standardisation (less and you just use
upstream settings or manually customised configs, more and rigid control
over hardware variations and software configurations wins over
customisations - you just reimage systems when change is needed, and buy
runs of hardware instead of taking whatever's available cheapest each
time you need a new system)

Basically, you start from a common core of package groups then define
variations/profiles.

Profile A is groups 1 2 3 with a b c added to group 2. Hide group 4.
Profile B is groups 1 3 4 with d added to group 3 . Hide group 2.
Profile C is group 5 composed of group 1 + group 4. Hide the rest.

etc.

Systems can be reaffected from one profile to another. When that happens
you need a quick way to tell a system "from now on use profile foo.
Install the mandatory bits you lack in this profile, remove the bits not
available in this profile, and only show this profile groups/packages in
package tools"

Profiles are typically close enough that given the number of your
systems a full reimage or new kickstart install is not worth it.

Currently kickstart allows this kind of flexibility at install time, but
it has no notion of tweaking groups, and once the system is installed
package tools just use the same groups for every system that points to
the same repo. If you want to hide stuff or tweak groups you need to
manually created separate repositories. 

Which is not nice, as what you really want is a single repo (not
different spin repos) with different views/profiles, and the ability to
change the profile a system uses without doing a full reinstall, or
writing custom scripts to do it.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/6e04f9d1/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Nov 21 20:01:15 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 21 Nov 2007 21:01:15 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121193002.GC38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<47445229.3060202@odu.neva.ru>
	<20071121193002.GC38223@dspnet.fr.eu.org>
Message-ID: <1195675275.16863.37.camel@rousalka.dyndns.org>


Le mercredi 21 novembre 2007 ? 20:30 +0100, Olivier Galibert a ?crit :

> Are you so sure of that?  The people around me that could possibly be
> contented with that won't change the OS that came with their computer
> anyway.  One the the gripes against Windows of the others is that
> there is nothing you can do with a standard install.

In any org that pays support or helpdesk, installing stuff people don't
really need is just asking for support calls on it.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/2154e076/attachment.sig>

From eswierk at arastra.com  Wed Nov 21 20:09:52 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Wed, 21 Nov 2007 12:09:52 -0800
Subject: InstantMirror initial source repo
In-Reply-To: <p04330103c36a0d4bbcb4@192.168.123.162>
References: <4743C7CF.4000904@redhat.com>
	<p04330103c36a0d4bbcb4@192.168.123.162>
Message-ID: <e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>

On 11/21/07, Tony Nelson <tonynelson at georgeanelson.com> wrote:
> I'm new to mod_python, but it is documented to be able to do /anything/
> that could be a response from Apache.  If the handler were to fetch the
> data itself it could write a local file and also return the data to the
> client, by calling urlopen() and then read(), write(), and req.write()
> repeatedly.  I don't know if the reads and writes will overlap.

I just implemented this in InstantMirror. The complication I feared
was handling byte range requests properly. But I don't handle them at
all (i.e. they get treated as full file requests), and yum/urllib
doesn't complain.

--Ed



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From terje.rosten at ntnu.no  Wed Nov 21 20:55:18 2007
From: terje.rosten at ntnu.no (Terje Rosten)
Date: Wed, 21 Nov 2007 21:55:18 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <yojfxyze2tl.fsf@bird.phys.ntnu.no>

* Olivier Galibert
| 
| Keep cranking up the pain, guys, and fedora will definitively makes
| its place in the "master of none" category.
| 
| It's kinda sad that people who do such a good job upstream end up
| building such a crappier-over-time distribution from it.


Hi Olivier, imho Fedora 8 is most easy Fedora to install and customize,
however you *have* to work with the tools, not against them.

Using DVD install and

$ yum install \*

are not to working with the tools.

Why is Fedora 8 install easy?

 * lots to packages (almost all "normal" pkgs are included)
 * easy to create homemade repos (createrepo)
 * very simple to create custom comps.xml (createrepo -g)
 * support for additional repos in kickstart (url keyword)
   - can add updates, freshrpms and custom repo during install
 * much faster depsolver code (thansk yum people!)
 * very good hardware auto detection

Old, however very nice features:

 * http support in kickstart, this is a killer! [1]

What could be better?

 * bug free installer :-)
 * installable Everything spin (without isos, will be fixed in F-9, I hope)


 - Terje


[1]: Combine apache with mod_rewrite with e.g. php to create kickstart
files *on the fly*:

Boot host with boot.iso (or from grub) go to text modus and write:
linux ks=http://webserver/ks/<hostname>

This URL is a redirect to http://webserver/ks/ks.php?hostname=<hostname>
the php script has all needed information about <hostname>: network
settings, auth info, passwd, packages, additional repos etc.

Now add cfengine or similar to do post install configuration you should
be set.











 












From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From tibbs at math.uh.edu  Wed Nov 21 21:08:28 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 21 Nov 2007 15:08:28 -0600
Subject: Debuginfo packages for Java
Message-ID: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>

I'm having problems reviewing a package for some software written in
Java.  The problem is that the debuginfo package is generated without
any source.  find-debuginfo.sh prints out the following:

extracting debug info from /var/tmp/writer2latex-0.5-buildroot/usr/lib64/gcj/writer2latex/writer2latex-0.5.jar.so
cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex-0.5.jar.1.jar: Cannot stat: No such file or directory
cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex/Application.java: Cannot stat: No such file or directory
cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex/api/BatchConverter.java: Cannot stat: No such file or directory

Needless to say, the source isn't actually buried under
writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex.

Some time ago I reviewed some Java-using packages and the issue was
fixable with by making a symlink; see, for example, the ganymed-ssh2
package, which has:

# Link source files to fix -debuginfo generation.
rm -f ch
ln -s src/ch

but this method no longer works and in fact that ganymed-ssh2
debuginfo package currently includes no source.  Even if I cook up a
directory structure and symlinks so that
writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex exists and
holds all of the files cpio is complaining about, they still don't
make it into the debuginfo package.

So I'm at a loss.  We really need folks who understand java to come up
with guidelines and procedures that would answer the kinds of
questions which come up when reviewing Java-using packages.  There are
a number of them in the review queue but nobody understands how to
review them.  And it really wouldn't if someone documented just how
debuginfo generation works.

The review ticket in question is
  https://bugzilla.redhat.com/show_bug.cgi?id=386661

The ganymed-ssh2 ticket where I first tackled this:
  https://bugzilla.redhat.com/show_bug.cgi?id=191014
which includes some comments about debuginfo generation being busted
for Java.

 - J<



From myfedora at richip.dhs.org  Wed Nov 21 21:20:07 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 21 Nov 2007 14:20:07 -0700
Subject: mock Missing Dependencies
Message-ID: <1195680007.24132.4.camel@localhost6.localdomain6>

Hi,

I'm trying to packages software that requires the glib2-devel package
for building. Unfortunately, mock keeps exiting and complaining that yum
can't satisfy certain missing dependencies:

Error: Command(/usr/bin/yum
--installroot /var/lib/mock/fedora-8-x86_64/root install ccache
'intltool' 'python-devel' 'libglade2-devel' 'autoconf'
'libgnomeui-devel' 'gettext-devel' 'glib2' 'glib2-devel') failed.
Output:
Error: Missing Dependency: libgthread-2.0.so.0 is needed by package
glib2-devel
Error: Missing Dependency: libgobject-2.0.so.0 is needed by package
glib2-devel
Error: Missing Dependency: libgmodule-2.0.so.0 is needed by package
glib2-devel
Error: Missing Dependency: libglib-2.0.so.0 is needed by package
glib2-devel

I've forced mock to try to install the glib2 package via the src.rpm,
but it's still not finding it.

It's hard to say whether I should file a bug against mock or yum since
yum, on a non-mock chroot'd system, finds the dependency readily.

Help.
--

Richi Plana



From tonynelson at georgeanelson.com  Wed Nov 21 21:27:56 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Wed, 21 Nov 2007 16:27:56 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>
References: <4743C7CF.4000904@redhat.com>
	<p04330103c36a0d4bbcb4@192.168.123.162>
	<e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>
Message-ID: <p04330109c36a506181c5@[192.168.123.162]>

At 12:09 PM -0800 11/21/07, Ed Swierk wrote:
>On 11/21/07, Tony Nelson <tonynelson at georgeanelson.com> wrote:
>> I'm new to mod_python, but it is documented to be able to do /anything/
>> that could be a response from Apache.  If the handler were to fetch the
>> data itself it could write a local file and also return the data to the
>> client, by calling urlopen() and then read(), write(), and req.write()
>> repeatedly.  I don't know if the reads and writes will overlap.
>
>I just implemented this in InstantMirror.

Way to go!

>The complication I feared
>was handling byte range requests properly. But I don't handle them at
>all (i.e. they get treated as full file requests), and yum/urllib
>doesn't complain.

Hmm.  I expect that will affect resuming downloads.  Hopefully somebody who
knows more about serving httpd will speak up.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From katzj at redhat.com  Wed Nov 21 21:29:10 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 21 Nov 2007 16:29:10 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <yojfxyze2tl.fsf@bird.phys.ntnu.no>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<yojfxyze2tl.fsf@bird.phys.ntnu.no>
Message-ID: <1195680550.4552.117.camel@localhost.localdomain>

On Wed, 2007-11-21 at 21:55 +0100, Terje Rosten wrote:
> * installable Everything spin (without isos, will be fixed in F-9, I
> hope)

You should be able to use the (now somewhat misnamed, on the list of
things for F9 to rename and rebrand it) rescue CD and then point at the
Everything tree as your install source.

Jeremy



From jspaleta at gmail.com  Wed Nov 21 21:32:38 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 12:32:38 -0900
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195680550.4552.117.camel@localhost.localdomain>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<yojfxyze2tl.fsf@bird.phys.ntnu.no>
	<1195680550.4552.117.camel@localhost.localdomain>
Message-ID: <604aa7910711211332g16aedb21m8d73162062536e5e@mail.gmail.com>

On Nov 21, 2007 12:29 PM, Jeremy Katz <katzj at redhat.com> wrote:
> You should be able to use the (now somewhat misnamed, on the list of
> things for F9 to rename and rebrand it) rescue CD and then point at the
> Everything tree as your install source.

what are you gonna call it now? Fedora PocketKnife? Fedora InstallKit?

-jef"Or is it PocketGnife?"spaleta



From pertusus at free.fr  Wed Nov 21 21:41:03 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 21 Nov 2007 22:41:03 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
Message-ID: <20071121214103.GB2636@free.fr>

On Wed, Nov 21, 2007 at 11:35:44AM -0500, James Hubbard wrote:
> 
> Some people have mentioned using RHEL 5.  I don't use it because it
> doesn't have most of the things that I want.  If it does have
> something I need, it's usually too out of date.  I understand the
> reason why it is this way so you don't have to explain its purpose.

You could be interested in EPEL (or  other 3rd party repos) for better
completeness. I think that the number of fedora packages in EPEL will
increase in the future, up to coverage for most of the packages. It
doesn't solve the up to date stuff, but fedora is here for that.

> You probably don't care, but I just upgraded from FC6 to F7 so that my
> wireless would work.  Why not F8?  When I read the emails that Sun's
> JVM wouldn't work on F8, I stopped considering it due to my dependence
> on a couple of Java apps.  I couldn't spend the time tracking down
> bugs related to an incomplete runtime environment.  I know that it's
> not anyone's fault on the list, but that's just the way that it is.

I am not a java expert but isn't the sun jvm now part of fedora?

--
Pat



From terje.rosten at ntnu.no  Wed Nov 21 21:51:13 2007
From: terje.rosten at ntnu.no (Terje Rosten)
Date: Wed, 21 Nov 2007 22:51:13 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <1195680550.4552.117.camel@localhost.localdomain>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<yojfxyze2tl.fsf@bird.phys.ntnu.no>
	<1195680550.4552.117.camel@localhost.localdomain>
Message-ID: <yoj1waje08e.fsf@bird.phys.ntnu.no>

* Jeremy Katz
| 
| You should be able to use the (now somewhat misnamed, on the list of
| things for F9 to rename and rebrand it) rescue CD and then point at the
| Everything tree as your install source.

A-ha! 

However I start the install from grub (one more cdrom saved :-) and then
I need the images/ directory. 

(In fact, all I need to do is to cp the images/ dir from Fedora spin to
Everything spin.)


 - Terje



From pertusus at free.fr  Wed Nov 21 21:56:50 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 21 Nov 2007 22:56:50 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <47445229.3060202@odu.neva.ru>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<47445229.3060202@odu.neva.ru>
Message-ID: <20071121215650.GC2636@free.fr>

On Wed, Nov 21, 2007 at 06:43:37PM +0300, Dmitry Butskoy wrote:
> Olivier Galibert wrote:
>
>> Fedora was originally nice for people coming from an Unix background,
>> where 50% of the windows on the screen are xterms.  It seems to have
>> collectively decided that it should instead cater to the Windows kind
>> of people, to the detriment of the Unix ones.
>
> Perhaps it could be a good idea to provide a "spifit-of-UNIX" Fedora spin. 
> Actually, all the packages are (still) present in the common "Everything" 
> repository. But I don't know, how many "ancient UNIX users" remain in 
> Fedora world. I am. You are. Who else?..

I am. And this issue was already discussed (at least the desktop 
part):
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00208.html

> It seems a task for people as you and I to provide a "traditional UNIX" 
> additional style for Fedora. Remember, a lot of people even do not know 
> what is UNIX at all. They never worked under it.

It depends what you call 'traditional UNIX', but some design concepts
are being forgotten in any case (look at the 
udev/dbus/hal/gnome-power-management stack), be it for good or bad.
And in my opinion the life of the traditional UNIX user on linux 
will increasingly be a struggle for survival given that the big desktop 
are the one with more time in hand in linux now. Now, old style
UNIX users don't need a lot to live, so the struggle may not be that 
painful, but these days are certainly over when linux was ruled by
simplicity and text files.

--
Pat



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From ivazqueznet at gmail.com  Wed Nov 21 22:32:33 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 21 Nov 2007 17:32:33 -0500
Subject: mock Missing Dependencies
In-Reply-To: <1195680007.24132.4.camel@localhost6.localdomain6>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
Message-ID: <1195684353.24136.6.camel@ignacio.lan>

On Wed, 2007-11-21 at 14:20 -0700, Richi Plana wrote:
> I'm trying to packages software that requires the glib2-devel package
> for building. Unfortunately, mock keeps exiting and complaining that yum
> can't satisfy certain missing dependencies:
> 
> Error: Command(/usr/bin/yum
> --installroot /var/lib/mock/fedora-8-x86_64/root install ccache
> 'intltool' 'python-devel' 'libglade2-devel' 'autoconf'
> 'libgnomeui-devel' 'gettext-devel' 'glib2' 'glib2-devel') failed.
> Output:
> Error: Missing Dependency: libgthread-2.0.so.0 is needed by package
> glib2-devel

You're using mock on a x86_64 system against a multilib repo. You need
to exclude all i386 packages except glibc.i?86 from the main repo:

exclude=[A-Za-fh-z]*.i*86 g[a-km-z]*.i?86 glib[^c]*.i?86 glib.i?86

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/19e2fed7/attachment.sig>

From rhally at mindspring.com  Wed Nov 21 22:55:36 2007
From: rhally at mindspring.com (Richard Hally)
Date: Wed, 21 Nov 2007 17:55:36 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121151510.GA21330@wolff.to>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120082647.137221b6@weaponx>	<20071120145119.GA26405@dspnet.fr.eu.org>	<1195578414.3568.58.camel@localhost.localdomain>	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
Message-ID: <4744B768.301@mindspring.com>

Bruno Wolff III wrote:
> On Tue, Nov 20, 2007 at 19:41:33 +0100,
>   Olivier Galibert <galibert at pobox.com> wrote:
>> At fedora core 5 times, Everything was lost.  Thankfully it is still
>> in kickstart, but it makes the initial testing phase more annoying.
>> Way more problematic is the support time which went down to one year.
> 
> I still run Fedora 5 on one machine because of a kernel bug. It works well
> for me.
> 
>> At fedora 7 time, Core was mostly lost.  There is still the list of
>> package on the DVD as a guideline though, but there isn't a separate
>> updates directory you can easily merge in anymore.  To the point that
>> I didn't find the time to do the new installation before 8 was out.
> 
> The "everything" repository exists and I use a local copy of it to do
> yum upgrades. Having core and extras combined seems to be a much nicer
> approach than what was done previously. The Unity people have even put
> out a multiDVD "Everything" spin.
> 
>> Now we're at 8 and I want to try to move to it, but static ip support
>> is fucked, and the list of packages on the DVD doesn't even have tcsh,
>> which 50% of the people here use.  Installing from the DVD by checking
>> all 3 options at the top level doesn't even give you make or gcc,
>> which is kind of annoying when the reason for installing interactively
>> in the first place is to have everything needed to hack on anaconda to
>> fix the static ip issue.  An yum install '*' conflicts all the way due
>> to the multilib crap.
> 
> I use static IP addresses and don't have a problem with that. I don't use
> NM though. There are some advanced things I do using iproute2 in rc.local,
> but the plain stuff can be done with system-config-network.
> 
>> Fedora was originally nice for people coming from an Unix background,
>> where 50% of the windows on the screen are xterms.  It seems to have
>> collectively decided that it should instead cater to the Windows kind
>> of people, to the detriment of the Unix ones.  A default installation
> 
> I don't see that.
> 
>> does not have a compiler.  Everything looking slightly technical is
>> hidden as much as possible.  Easily understandable and editable text
>> configuration files are routinely replaced by an obfuscated xml-based
>> registry[1] with automatically generated GUIs from hell[2].  Basic
>> things like static ips and routes are considered legacy and their
>> support totally untested and/or considered unimportant.  And
>> significantly every comparison is done with Ubuntu, the epitome of the
>> windowsian-come-here distributions, and never with Debian or Gentoo.
> 
> When I see people asking for Fedora to be more like Ubuntu, I typically
> see a response that we aren't going there.
> 
>> Keep cranking up the pain, guys, and fedora will definitively makes
>> its place in the "master of none" category.
> 
> Well, there is definitely pain involved with Fedora. That's best helped by
> having some people volunteer to try rawhide to catch issues early.
> 
Bruno, It looks like there is a problem with your mailer. I have received 9 
copies of this message!
There is also one with 2:15pm time that I have received 6 times. All the other 
messages from other people are ok.

Richard



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From galibert at pobox.com  Thu Nov 22 00:27:54 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 22 Nov 2007 01:27:54 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
Message-ID: <20071122002754.GA75436@dspnet.fr.eu.org>

On Wed, Nov 21, 2007 at 10:03:34AM -0900, Jeff Spaleta wrote:
> Question... can you dedicate one machine to run a local service that
> helps you keep track of the packages installed across multiple
> machines?
> As in when someone acting as a local administrator on a desktop
> installs something via Add/remove would you be willing to run a
> central service that 'sees' those additional packages and adds that to
> a aggregate list or database that you can then use to install the same
> software on other machines which should have it?

That's an interesting concept.  Orthogonal to what we're talking
about, but still interesting.


> Would that give you the sort of control you are looking for?
> Individuals control their own desktop software and then new software
> additions can propogate through to additional machines through a
> central aggregate service which keeps track of who is installing what
> on their desktops.

Just FYI, it's not about control, it's about convenience.  About 3/4
of the users have the root passwords (it's a research lab in computer
science after all).  They tend to ask me to install things instead of
doing it themselves because:
- it doesn't happen often

- half of the time, it's so specialized it's not packaged (praat,
  specific modules of R...)

- they know I'll ensure it's installed on all the machines they tend
  to use, including the clusters if necessary, and there is a good
  chance it will be added to all future installations

It's only bearable on my side if the "it doesn't happen often" holds.
I'm not sure why so many people here think users should spend half
their time installing software they're missing.  Disk is cheap, time
isn't.

  OG.



From myfedora at richip.dhs.org  Thu Nov 22 00:30:55 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 21 Nov 2007 17:30:55 -0700
Subject: mock Missing Dependencies
In-Reply-To: <1195684353.24136.6.camel@ignacio.lan>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
Message-ID: <1195691455.27886.5.camel@localhost6.localdomain6>

On Wed, 2007-11-21 at 17:32 -0500, Ignacio Vazquez-Abrams wrote:
> On Wed, 2007-11-21 at 14:20 -0700, Richi Plana wrote:
> > I'm trying to packages software that requires the glib2-devel package
> > for building. Unfortunately, mock keeps exiting and complaining that yum
> > can't satisfy certain missing dependencies:
> > 
> > Error: Command(/usr/bin/yum
> > --installroot /var/lib/mock/fedora-8-x86_64/root install ccache
> > 'intltool' 'python-devel' 'libglade2-devel' 'autoconf'
> > 'libgnomeui-devel' 'gettext-devel' 'glib2' 'glib2-devel') failed.
> > Output:
> > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package
> > glib2-devel
> 
> You're using mock on a x86_64 system against a multilib repo. You need
> to exclude all i386 packages except glibc.i?86 from the main repo:
> 
> exclude=[A-Za-fh-z]*.i*86 g[a-km-z]*.i?86 glib[^c]*.i?86 glib.i?86

Which .repo files should I edit? The hosts? Do I need to invalidate the
cache? Better yet, is this covered on the wiki somewhere?

(I tried changing the host's fedora.repo and fedora-updates.repo and
added those exclusions, but that didn't work. I looked at the root and
they contained .repo files which don't seem like they came from my local
copies (I've edited my local repos)).
--

Richi Plana



From jkeating at redhat.com  Thu Nov 22 00:33:33 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Nov 2007 19:33:33 -0500
Subject: mock Missing Dependencies
In-Reply-To: <1195691455.27886.5.camel@localhost6.localdomain6>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
	<1195691455.27886.5.camel@localhost6.localdomain6>
Message-ID: <20071121193333.20c35511@redhat.com>

On Wed, 21 Nov 2007 17:30:55 -0700
Richi Plana <myfedora at richip.dhs.org> wrote:

> Which .repo files should I edit? The hosts? Do I need to invalidate
> the cache? Better yet, is this covered on the wiki somewhere?

You need to update the config file for the target in /etc/mock/

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/af8ec37f/attachment.sig>

From andrewparker at bigfoot.com  Thu Nov 22 00:36:18 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Wed, 21 Nov 2007 19:36:18 -0500
Subject: mock Missing Dependencies
In-Reply-To: <1195691455.27886.5.camel@localhost6.localdomain6>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
	<1195691455.27886.5.camel@localhost6.localdomain6>
Message-ID: <6c3f5e6c0711211636o6ee71b7ega76f4cbb857e6b51@mail.gmail.com>

On Nov 21, 2007 7:30 PM, Richi Plana <myfedora at richip.dhs.org> wrote:
> On Wed, 2007-11-21 at 17:32 -0500, Ignacio Vazquez-Abrams wrote:
> > On Wed, 2007-11-21 at 14:20 -0700, Richi Plana wrote:
> > > I'm trying to packages software that requires the glib2-devel package
> > > for building. Unfortunately, mock keeps exiting and complaining that yum
> > > can't satisfy certain missing dependencies:
> > >
> > > Error: Command(/usr/bin/yum
> > > --installroot /var/lib/mock/fedora-8-x86_64/root install ccache
> > > 'intltool' 'python-devel' 'libglade2-devel' 'autoconf'
> > > 'libgnomeui-devel' 'gettext-devel' 'glib2' 'glib2-devel') failed.
> > > Output:
> > > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package
> > > glib2-devel
> >
> > You're using mock on a x86_64 system against a multilib repo. You need
> > to exclude all i386 packages except glibc.i?86 from the main repo:
> >
> > exclude=[A-Za-fh-z]*.i*86 g[a-km-z]*.i?86 glib[^c]*.i?86 glib.i?86
>
> Which .repo files should I edit? The hosts? Do I need to invalidate the
> cache? Better yet, is this covered on the wiki somewhere?
>
> (I tried changing the host's fedora.repo and fedora-updates.repo and
> added those exclusions, but that didn't work. I looked at the root and
> they contained .repo files which don't seem like they came from my local
> copies (I've edited my local repos)).

mock repos are configured in /etc/mock.  there should be a .cfg file
corresponding to the "-r" option you use when you run mock.



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From wtogami at redhat.com  Thu Nov 22 00:53:04 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 21 Nov 2007 19:53:04 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <p04330109c36a506181c5@[192.168.123.162]>
References: <4743C7CF.4000904@redhat.com>	<p04330103c36a0d4bbcb4@192.168.123.162>	<e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>
	<p04330109c36a506181c5@[192.168.123.162]>
Message-ID: <4744D2F0.9030005@redhat.com>

Tony Nelson wrote:
> At 12:09 PM -0800 11/21/07, Ed Swierk wrote:
>> On 11/21/07, Tony Nelson <tonynelson at georgeanelson.com> wrote:
>>> I'm new to mod_python, but it is documented to be able to do /anything/
>>> that could be a response from Apache.  If the handler were to fetch the
>>> data itself it could write a local file and also return the data to the
>>> client, by calling urlopen() and then read(), write(), and req.write()
>>> repeatedly.  I don't know if the reads and writes will overlap.
>> I just implemented this in InstantMirror.
> 
> Way to go!
> 
>> The complication I feared
>> was handling byte range requests properly. But I don't handle them at
>> all (i.e. they get treated as full file requests), and yum/urllib
>> doesn't complain.
> 
> Hmm.  I expect that will affect resuming downloads.  Hopefully somebody who
> knows more about serving httpd will speak up.

What currently happens if one instance of InstantMirror.py is 
downloading file FOO, and during that download a second client requests 
the same file?

Warren Togami
wtogami at redhat.com



From eswierk at arastra.com  Thu Nov 22 00:56:00 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Wed, 21 Nov 2007 16:56:00 -0800
Subject: InstantMirror initial source repo
In-Reply-To: <4744D2F0.9030005@redhat.com>
References: <4743C7CF.4000904@redhat.com>
	<p04330103c36a0d4bbcb4@192.168.123.162>
	<e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>
	<p04330109c36a506181c5@192.168.123.162> <4744D2F0.9030005@redhat.com>
Message-ID: <e6c711510711211656y41a68cfdha74f3b9c39541bba@mail.gmail.com>

On 11/21/07, Warren Togami <wtogami at redhat.com> wrote:
> What currently happens if one instance of InstantMirror.py is
> downloading file FOO, and during that download a second client requests
> the same file?

Probably something unpleasant for the first client. Easy fix is to
change .tmp to a random value; this should go in the TODO.

--Ed



From jspaleta at gmail.com  Thu Nov 22 01:04:50 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Nov 2007 16:04:50 -0900
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071122002754.GA75436@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
Message-ID: <604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>

On Nov 21, 2007 3:27 PM, Olivier Galibert <galibert at pobox.com> wrote:
> That's an interesting concept.  Orthogonal to what we're talking
> about, but still interesting.

I'm not sure its orthogonal.. tangential perhaps.

> I'm not sure why so many people here think users should spend half
> their time installing software they're missing.

Because for other, established, usage cases that have seen significant
discussion, having a lot of stuff you don't need installed has costs
in terms of security and bandwidth consumption when doing things like
updates.  What you are doing is firmly outside of the usage cases for
which any coherent plan has been even described let along attempted to
be implemented as part of this project.  A subproject to make
everything or nearly everything installs work from a kickstart file or
from a specialally designed spin doesn't sound like something that
could not be done as part of F9   release prep. But there has to be
people willing to drive this forward. Are you one of these people?
You clearly care about the issue, but are you prepared to step up and
chart a course to see improvement in a family of usage cases that
matter to you?


> Disk is cheap, time isn't.
This statement goes against the fundamental axioms by which graduate
students come into being.
You just need more graduate students.

-jef"is anyone working on a Fedora spin meant for cluster usage already?"spaleta



From wolfy at nobugconsulting.ro  Thu Nov 22 01:18:34 2007
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Thu, 22 Nov 2007 03:18:34 +0200
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120082647.137221b6@weaponx>	<20071120145119.GA26405@dspnet.fr.eu.org>	<1195578414.3568.58.camel@localhost.localdomain>	<20071120184133.GA51420@dspnet.fr.eu.org>	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
Message-ID: <4744D8EA.9000603@nobugconsulting.ro>

On 11/21/2007 07:03 PM, Jeff Spaleta wrote:
> On Nov 21, 2007 6:41 AM, Colin Walters <walters at redhat.com> wrote:
>   
>> There is also a third option - write your own kickstart file defining
>> exactly what you want, and use it to install.
>>     
>
> I'd like to see if we as a project can extend this option, so that we
> can archive and make a gallery of contributed kickstart files for
> people to use for niche usage cases.  Perhaps then Olivier could work
> with other niche admins who want to beat Fedora into submission to
> create a suitable baseline kickstart for his usage case.
In addition to that I'd like to see a 
http://GenerateYourOwnKickstartFileHere.fedoraproject.org with something 
similar to system-config-kickstart running on the server and generating 
on the fly kickstart images for those who have no idea how a kickstart 
file looks like but know that using one would save their time [1]. A 
tool which would know the more esoteric options similar to those 
described at http://wiki.centos.org/TipsAndTricks/KickStart [2]

    manuel

[1] and for whom using s-c-k is not an option because they are running 
an OS where this tool is not available
[2] yes, well hidden behind a "Don't blame me if you shoot yourself in 
both feet" button



From myfedora at richip.dhs.org  Thu Nov 22 01:19:43 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 21 Nov 2007 18:19:43 -0700
Subject: mock Missing Dependencies
In-Reply-To: <6c3f5e6c0711211636o6ee71b7ega76f4cbb857e6b51@mail.gmail.com>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
	<1195691455.27886.5.camel@localhost6.localdomain6>
	<6c3f5e6c0711211636o6ee71b7ega76f4cbb857e6b51@mail.gmail.com>
Message-ID: <1195694383.27886.18.camel@localhost6.localdomain6>

On Wed, 2007-11-21 at 19:36 -0500, Andrew Parker wrote:
> On Nov 21, 2007 7:30 PM, Richi Plana <myfedora at richip.dhs.org> wrote:
> > On Wed, 2007-11-21 at 17:32 -0500, Ignacio Vazquez-Abrams wrote:
> > > On Wed, 2007-11-21 at 14:20 -0700, Richi Plana wrote:
> > > > I'm trying to packages software that requires the glib2-devel package
> > > > for building. Unfortunately, mock keeps exiting and complaining that yum
> > > > can't satisfy certain missing dependencies:
> > > >
> > > > Error: Command(/usr/bin/yum
> > > > --installroot /var/lib/mock/fedora-8-x86_64/root install ccache
> > > > 'intltool' 'python-devel' 'libglade2-devel' 'autoconf'
> > > > 'libgnomeui-devel' 'gettext-devel' 'glib2' 'glib2-devel') failed.
> > > > Output:
> > > > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package
> > > > glib2-devel
> > >
> > > You're using mock on a x86_64 system against a multilib repo. You need
> > > to exclude all i386 packages except glibc.i?86 from the main repo:
> > >
> > > exclude=[A-Za-fh-z]*.i*86 g[a-km-z]*.i?86 glib[^c]*.i?86 glib.i?86
> >
> > Which .repo files should I edit? The hosts? Do I need to invalidate the
> > cache? Better yet, is this covered on the wiki somewhere?
> >
> > (I tried changing the host's fedora.repo and fedora-updates.repo and
> > added those exclusions, but that didn't work. I looked at the root and
> > they contained .repo files which don't seem like they came from my local
> > copies (I've edited my local repos)).
> 
> mock repos are configured in /etc/mock.  there should be a .cfg file
> corresponding to the "-r" option you use when you run mock.

Thanks.

After editing the fedora.8.x86_64.cfg file, I discovered this line:

exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86
g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86

Now, I'm not sure if yum uses wildcard globbing or regular expressions.
>From the above, it seems to be a combination of both. If it's pure
regexp, shouldn't it be something more like:

exclude=[^g].*\.i.?86 g[^l].*\.i.?86 gl[^i].*\.i.?86 gli[^b].*\.i.?86
glib[^c].*\.i.?86

?

At any rate, any more ideas?
--

Richi Plana



From wtogami at redhat.com  Thu Nov 22 01:40:12 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 21 Nov 2007 20:40:12 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <e6c711510711211656y41a68cfdha74f3b9c39541bba@mail.gmail.com>
References: <4743C7CF.4000904@redhat.com>	<p04330103c36a0d4bbcb4@192.168.123.162>	<e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>	<p04330109c36a506181c5@192.168.123.162>
	<4744D2F0.9030005@redhat.com>
	<e6c711510711211656y41a68cfdha74f3b9c39541bba@mail.gmail.com>
Message-ID: <4744DDFC.4040001@redhat.com>

Ed Swierk wrote:
> On 11/21/07, Warren Togami <wtogami at redhat.com> wrote:
>> What currently happens if one instance of InstantMirror.py is
>> downloading file FOO, and during that download a second client requests
>> the same file?
> 
> Probably something unpleasant for the first client. Easy fix is to
> change .tmp to a random value; this should go in the TODO.
> 
> --Ed
> 

This means the server will keep downloading that file multiple times 
until the file download is complete, then new client requests that come 
in after that point use the cached version?

Perhaps we should look into how squid or varnish handle this scenario. 
There is probably a well-understood way of handling this that they 
figured out.

Warren



From eswierk at arastra.com  Thu Nov 22 01:49:17 2007
From: eswierk at arastra.com (Ed Swierk)
Date: Wed, 21 Nov 2007 17:49:17 -0800
Subject: InstantMirror initial source repo
In-Reply-To: <4744DDFC.4040001@redhat.com>
References: <4743C7CF.4000904@redhat.com>
	<p04330103c36a0d4bbcb4@192.168.123.162>
	<e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>
	<p04330109c36a506181c5@192.168.123.162> <4744D2F0.9030005@redhat.com>
	<e6c711510711211656y41a68cfdha74f3b9c39541bba@mail.gmail.com>
	<4744DDFC.4040001@redhat.com>
Message-ID: <e6c711510711211749w7ec33644x375a53d8b00aeb80@mail.gmail.com>

On 11/21/07, Warren Togami <wtogami at redhat.com> wrote:
> This means the server will keep downloading that file multiple times
> until the file download is complete, then new client requests that come
> in after that point use the cached version?

Yes. We could try to get fancy and have later requests wait on the one
already underway, but it's not clear how you tell the difference
between a file that's still being downloaded and a turd left behind by
an aborted request.

--Ed



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From ivazqueznet at gmail.com  Thu Nov 22 02:49:16 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 21 Nov 2007 21:49:16 -0500
Subject: yum matching (was: Re: mock Missing Dependencies)
In-Reply-To: <1195694383.27886.18.camel@localhost6.localdomain6>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
	<1195691455.27886.5.camel@localhost6.localdomain6>
	<6c3f5e6c0711211636o6ee71b7ega76f4cbb857e6b51@mail.gmail.com>
	<1195694383.27886.18.camel@localhost6.localdomain6>
Message-ID: <1195699756.24136.10.camel@ignacio.lan>

On Wed, 2007-11-21 at 18:19 -0700, Richi Plana wrote:
> Now, I'm not sure if yum uses wildcard globbing or regular expressions.
> >From the above, it seems to be a combination of both. If it's pure
> regexp, shouldn't it be something more like:

Actually, I messed up. It should use globs, therefore [!...] is correct,
not [^...].

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071121/f52a38be/attachment.sig>

From otto_rey at yahoo.com.ar  Thu Nov 22 03:29:42 2007
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Wed, 21 Nov 2007 19:29:42 -0800 (PST)
Subject: Support TV on Fedora - Proposal for Fedora 9
Message-ID: <385453.83318.qm@web52410.mail.re2.yahoo.com>

Fedora should have a good support of TV cards. I have a LifeView FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV working. I try almost everything (i am developer).
For home users, Fedora 9 TV support should by something like this: "Install this crappy package and you are zapping" :D

Sorry for my english.





      Compart? video en la ventana de tus mensajes (y tambi?n tus fotos de Flickr). 
Us? el nuevo Yahoo! Messenger versi?n Beta. http://ar.beta.messenger.yahoo.com/



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From myfedora at richip.dhs.org  Thu Nov 22 04:38:14 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 21 Nov 2007 21:38:14 -0700
Subject: yum matching (was: Re: mock Missing Dependencies)
In-Reply-To: <1195699756.24136.10.camel@ignacio.lan>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
	<1195691455.27886.5.camel@localhost6.localdomain6>
	<6c3f5e6c0711211636o6ee71b7ega76f4cbb857e6b51@mail.gmail.com>
	<1195694383.27886.18.camel@localhost6.localdomain6>
	<1195699756.24136.10.camel@ignacio.lan>
Message-ID: <1195706294.30091.4.camel@localhost6.localdomain6>

On Wed, 2007-11-21 at 21:49 -0500, Ignacio Vazquez-Abrams wrote:
> On Wed, 2007-11-21 at 18:19 -0700, Richi Plana wrote:
> > Now, I'm not sure if yum uses wildcard globbing or regular expressions.
> > >From the above, it seems to be a combination of both. If it's pure
> > regexp, shouldn't it be something more like:
> 
> Actually, I messed up. It should use globs, therefore [!...] is correct,
> not [^...].

Oddly enough, with stock mock configuration, the following didn't work:

exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86
g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86

I've since applied my own and I've been able to mock build properly now:

exclude=[!g]*.i?86 g[!l]*.i?86 gl[!i]*.i?86 gli[!b]*.i?86 glib[!c]*.i?86
glib.i?86

Should I file a bug against mock? Or am I the only one who the stock cfg
doesn't work for?
--

Richi Plana



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From tibbs at math.uh.edu  Thu Nov 22 05:18:21 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 21 Nov 2007 23:18:21 -0600
Subject: javadoc scriptlets
Message-ID: <ufak5oax3he.fsf@epithumia.math.uh.edu>

I'm having trouble understanding why many Java-using packages have the
following scriptlets:

%post javadoc
%__rm -f %{_javadocdir}/%{name}
%__ln_s %{name}-%{version} %{_javadocdir}/%{name}

%postun javadoc
if [ $1 -eq 0 ]; then
  %__rm -f %{_javadocdir}/%{name}
fi

So at install time it makes a symlink to a directory installed by the
javadoc package, and at uninstall time it removes it.

Some packages don't seem to %ghost the link, which seems to be a
problem.  But a more burning question is why isn't the link just part
of the package?

I was grepping through some specs and I found this from the (now
retired) jogl package:

* Sat Sep  3 2005 Anthony Green <green at redhat.com> - 0:1.1.1-7
- Removed %ghost for javadoc, and remove javadoc post scriptlet,
  as per ville.skytta at iki.fi's suggestion.

But I don't know what the basis for that was, and I don't see anything
relevant in bugzilla.  Perhaps Ville can remember that far back.

Does anyone know the rationale for this?

 - J<



From Michael_E_Brown at dell.com  Thu Nov 22 05:20:12 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Wed, 21 Nov 2007 23:20:12 -0600
Subject: yum matching (was: Re: mock Missing Dependencies)
In-Reply-To: <1195706294.30091.4.camel@localhost6.localdomain6>
References: <1195680007.24132.4.camel@localhost6.localdomain6>
	<1195684353.24136.6.camel@ignacio.lan>
	<1195691455.27886.5.camel@localhost6.localdomain6>
	<6c3f5e6c0711211636o6ee71b7ega76f4cbb857e6b51@mail.gmail.com>
	<1195694383.27886.18.camel@localhost6.localdomain6>
	<1195699756.24136.10.camel@ignacio.lan>
	<1195706294.30091.4.camel@localhost6.localdomain6>
Message-ID: <20071122052011.GD23478@humbolt.us.dell.com>

On Wed, Nov 21, 2007 at 09:38:14PM -0700, Richi Plana wrote:
> On Wed, 2007-11-21 at 21:49 -0500, Ignacio Vazquez-Abrams wrote:
> > On Wed, 2007-11-21 at 18:19 -0700, Richi Plana wrote:
> > > Now, I'm not sure if yum uses wildcard globbing or regular expressions.
> > > >From the above, it seems to be a combination of both. If it's pure
> > > regexp, shouldn't it be something more like:
> > 
> > Actually, I messed up. It should use globs, therefore [!...] is correct,
> > not [^...].
> 
> Oddly enough, with stock mock configuration, the following didn't work:
> 
> exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86
> g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86
> 
> I've since applied my own and I've been able to mock build properly now:
> 
> exclude=[!g]*.i?86 g[!l]*.i?86 gl[!i]*.i?86 gli[!b]*.i?86 glib[!c]*.i?86
> glib.i?86
> 
> Should I file a bug against mock? Or am I the only one who the stock cfg
> doesn't work for?

mock 0.8.9 has was released yesterday with this fix. It is in rawhide
and -testing repos for F7/F8.

Yes, I am *that* good. I went _back_in_time_ and fixed this problem
before you had it. :)

Now, if only people used the -testing repos...
--
Michael



From wtogami at redhat.com  Thu Nov 22 06:03:03 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 22 Nov 2007 01:03:03 -0500
Subject: InstantMirror initial source repo
In-Reply-To: <e6c711510711211749w7ec33644x375a53d8b00aeb80@mail.gmail.com>
References: <4743C7CF.4000904@redhat.com>	<p04330103c36a0d4bbcb4@192.168.123.162>	<e6c711510711211209y52f0f63dtaba34025cace55eb@mail.gmail.com>	<p04330109c36a506181c5@192.168.123.162>
	<4744D2F0.9030005@redhat.com>	<e6c711510711211656y41a68cfdha74f3b9c39541bba@mail.gmail.com>	<4744DDFC.4040001@redhat.com>
	<e6c711510711211749w7ec33644x375a53d8b00aeb80@mail.gmail.com>
Message-ID: <47451B97.301@redhat.com>

Ed Swierk wrote:
> On 11/21/07, Warren Togami <wtogami at redhat.com> wrote:
>> This means the server will keep downloading that file multiple times
>> until the file download is complete, then new client requests that come
>> in after that point use the cached version?
> 
> Yes. We could try to get fancy and have later requests wait on the one
> already underway, but it's not clear how you tell the difference
> between a file that's still being downloaded and a turd left behind by
> an aborted request.
> 
> --Ed
> 

There may be different approaches we can take to achieve what we need, 
but I am afraid we may have to think about metadata on the side (outside 
of the mirror tree), and possibly tracking these concurrent demands 
within the separate daemon.  Unless we intend for InstantMirror to be 
more than just a small office mirror (which would be very handy for many 
people), we will need to eventually solve this problem.

In any case, great work getting this far so quickly! =)

Warren Togami
wtogami at redhat.com



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From j.w.r.degoede at hhs.nl  Thu Nov 22 06:33:15 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 22 Nov 2007 07:33:15 +0100
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <385453.83318.qm@web52410.mail.re2.yahoo.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
Message-ID: <474522AB.2030209@hhs.nl>

Otto Rey wrote:
> Fedora should have a good support of TV cards. I have a LifeView FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV working. I try almost everything (i am developer).
> For home users, Fedora 9 TV support should by something like this: "Install this crappy package and you are zapping" :D
> 

Sounds like a worthwhile goal, where possible without patent problems, 
are you willing to invest the time to make this happen?

Regards,

Hans



From wtogami at redhat.com  Thu Nov 22 07:00:09 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 22 Nov 2007 02:00:09 -0500
Subject: InstantMirror-0.2 Release
Message-ID: <474528F9.7080907@redhat.com>

http://fedorapeople.org/~wtogami/temp/InstantMirror-release/InstantMirror-0.2-0.fc8.noarch.rpm
http://fedorapeople.org/~wtogami/temp/InstantMirror-release/InstantMirror-0.2-0.fc8.src.rpm
http://fedorapeople.org/~wtogami/temp/InstantMirror-release/InstantMirror-0.2.tar.bz2
bzr branch http://fedorapeople.org/~wtogami/temp/InstantMirror/

Thanks to Ed Swierk's quick hacking, this theoretically is the first 
somewhat working version of InstantMirror.  See the TODO file for bug 
warnings and the SELinux workaround.

We still don't have a hosted.fp.org project setup yet so the above is 
only the temporary location.  Until we have that permanent project 
setup, please report bugs and make suggestions for improvement here in 
this thread.

Warren Togami
wtogami at redhat.com



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From nicolas.mailhot at laposte.net  Thu Nov 22 07:35:07 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Nov 2007 08:35:07 +0100
Subject: javadoc scriptlets
In-Reply-To: <ufak5oax3he.fsf@epithumia.math.uh.edu>
References: <ufak5oax3he.fsf@epithumia.math.uh.edu>
Message-ID: <1195716907.21601.1.camel@rousalka.dyndns.org>


Le mercredi 21 novembre 2007 ? 23:18 -0600, Jason L Tibbitts III a
?crit :

> * Sat Sep  3 2005 Anthony Green <green at redhat.com> - 0:1.1.1-7
> - Removed %ghost for javadoc, and remove javadoc post scriptlet,
>   as per ville.skytta at iki.fi's suggestion.
> 
> But I don't know what the basis for that was, and I don't see anything
> relevant in bugzilla.  Perhaps Ville can remember that far back.
> 
> Does anyone know the rationale for this?

Ask Ville. He's the javadoc man.

(also why are you posting all those java-related questions there instead
on fedora-java or jpackage-discuss? That's where the java packagers
dwell)

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/35772072/attachment.sig>

From pemboa at gmail.com  Thu Nov 22 07:53:44 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Thu, 22 Nov 2007 01:53:44 -0600
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <385453.83318.qm@web52410.mail.re2.yahoo.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
Message-ID: <16de708d0711212353p2592489fv419d7b386046bf3e@mail.gmail.com>

On Nov 21, 2007 9:29 PM, Otto Rey <otto_rey at yahoo.com.ar> wrote:
> Fedora should have a good support of TV cards. I have a LifeView FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV working. I try almost everything (i am developer).
> For home users, Fedora 9 TV support should by something like this: "Install this crappy package and you are zapping" :D
>
> Sorry for my english.

The general idea (I think) is "Install a Hauppauge card" they
generally work plug and play.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )



From michel.sylvan at gmail.com  Thu Nov 22 08:02:32 2007
From: michel.sylvan at gmail.com (Michel Salim)
Date: Thu, 22 Nov 2007 03:02:32 -0500
Subject: AWOL: jpo
In-Reply-To: <1195574488.27963.27.camel@localhost.localdomain>
References: <1195574488.27963.27.camel@localhost.localdomain>
Message-ID: <f224c6140711220002t2c682ccck51b90f11b35141e@mail.gmail.com>

On 20/11/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
> It seems that Jose Pedro Oliveira (aka jpo) is not coming back to
> Fedora. He has 28 open bug tickets, most of them in the new state, and
> he has not touched any of his packages or bugzilla since June.
>
> I'm initiating the AWOL process so that we can work on finding new homes
> for all of his many packages, and start bugfixing them.
>

Hopefully he will come back, but otherwise, I'd like to take over pdfjoin.

Regards,

-- 
Michel Salim
http://hircus.jaiku.com/



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From oliver at linux-kernel.at  Thu Nov 22 09:46:26 2007
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 22 Nov 2007 10:46:26 +0100
Subject: Contacts to FSF to resolve license issue!?
In-Reply-To: <4730C4C9.2090707@linux-kernel.at>
References: <4730C4C9.2090707@linux-kernel.at>
Message-ID: <47454FF2.3060304@linux-kernel.at>

ping!

On 11/06/2007 08:47 PM, Oliver Falk wrote:
> Hi!
> 
> A few days ago, I stumbled across the freshmeat announcement of
> nodemon/growler [0]. Both are NASA projects under NOSA 1.3 license.
> While in the first moment I thought, NOSA is free, FSF page list this
> license (at least in version 1.3) as non-free. After reading the
> description, I was clear for me why it is non-free. [1]
> 
> However, I contacted Mr. Bryan Green (author of nodemon/growler) and
> asked him if there's a chance to release the software under a *really
> free* license or if there's a chance to get a new version of NOSA (eg
> 1.4), that actually is FSF compliant and therefor software can be
> included into Fedora.
> 
> But it seems, NASA already tried to get in touch with FSF to solve the
> issue, but FSF wasn't very cooperative (no offense!).
> 
> I'd be glad, if someone has good contacts to FSF and we can bring
> together NASA and FSF, to solve that issue. Not only for nodemon/growler
>  to make it into Fedora, but also to make the world just another bit
> *more* free! I know of some people, who'll be smiling about this
> sentence... :-) Don't you?
> 
> -of
> 
> [0] http://people.nas.nasa.gov/~bgreen/nodemon/
>     http://people.nas.nasa.gov/~bgreen/growler/
> [1] http://www.fsf.org/licensing/licenses/; Search for NASA.
> 


-- 
Oliver Falk
UNIX/Linux Systems Engineer
Mail: oliver at linux-kernel.at
Phone: +43 (664) 838 59 25



From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From harald at redhat.com  Thu Nov 22 10:47:34 2007
From: harald at redhat.com (Harald Hoyer)
Date: Thu, 22 Nov 2007 11:47:34 +0100
Subject: System-config Reworking Proposal
In-Reply-To: <16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
References: <16de708d0711182318w8f1c2b9x70a4bc0c2f983f34@mail.gmail.com>	<1195477633.7218.21.camel@localhost.localdomain>
	<16de708d0711190827h29744548x4275bdb1b1d693d8@mail.gmail.com>
Message-ID: <fi3mo7$5fs$1@ger.gmane.org>

Arthur Pemberton wrote:
> On Nov 19, 2007 7:07 AM, Lubomir Kundrak <lkundrak at redhat.com> wrote:
>> Hi,
>>
>> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>>> I have expressed my ideas[1] to add and rework some of the
>>> functionality of the system-config tools with the hope of making them
>>> a bit more innovative and useful.
>>>
>>> Please comment on the idea.
>>> Rework (not a total rewrite) system-config tools use a common virtual console which abstracts away local and remote console usage. Anticipated benefits:
>>>
>>>     * transparently handle local or remote console (via ssh)
>>>           o allow configuration of remote services
>> this is possible now:
>> ssh -X my.server system-config-httpd
> 
> One question: I know about this method, but have never tried it myself
> - doesn't it require an xserver on the host?
> 
> One comment: The crowd that really love the system-config tools would
> like prefer not to be doing x forwarding via SSH
> 
> 
>>>           o possible allow for OS independent usage (example: system-config-httpd could be used from Windows XP)
>> You can do the very same thing from Windows XP.
> 
> I was thinking more in terms of the user just running system-config-*
> on Fedora|Windows|* and just enter in a host and passkey|user+pass and
> make changes to the target system
> 
>>>           o allow for those who prefer not to run server tools with a X server installed to make use of the system-config tools
>> None of the system-config-* tools depends on X server except for
>> system-config-display.
> 
> True, but you do generally need a GUI to make use of the GUI system-config tools

not true.. GUI, TUI, CMD

/usr/sbin/system-config-network
/usr/sbin/system-config-network-cmd
/usr/sbin/system-config-network-tui



From bruno at wolff.to  Wed Nov 21 19:21:09 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 13:21:09 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071121190246.GB38223@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<20071121190246.GB38223@dspnet.fr.eu.org>
Message-ID: <20071121192109.GA17988@wolff.to>

On Wed, Nov 21, 2007 at 20:02:46 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> All these issues are at installation time and as such don't really
> show up in rawhide.

This kind of thing does show up if you do practice installs.
I did a number of these for F7 and discovered (and someone fixed) some libata
issues before F7 was released.

People are also needed to do practice upgrades. I don't usually do much of
that since it tends to be even more work than practice installs.



From simon.andrews at bbsrc.ac.uk  Thu Nov 22 11:44:24 2007
From: simon.andrews at bbsrc.ac.uk (Simon Andrews)
Date: Thu, 22 Nov 2007 11:44:24 +0000
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <1195664529.7424.29.camel@space-ghost.verbum.private>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120082647.137221b6@weaponx>	<20071120145119.GA26405@dspnet.fr.eu.org>	<1195578414.3568.58.camel@localhost.localdomain>	<20071120184133.GA51420@dspnet.fr.eu.org>	<1195659663.7424.22.camel@space-ghost.verbum.private>	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
Message-ID: <fi3q2o$jpr$1@ger.gmane.org>

Colin Walters wrote:
> On Wed, 2007-11-21 at 11:35 -0500, James Hubbard wrote:
> 
> What this says to me is that we need to make it a more seamless
> experience for if you don't find something in the main menu, to get it
> installed.  We have the "Add/Remove Software" link but unfortunately
> it's based on packages which aren't the same thing as applications.
> There is work going on around this which might land in the Fedora 9
> timeframe.

I've thought for a while that it might be interesting to have a sort of 
'shadow' menu which would be a complete list of everything which could 
be installed to show up in the application menu.  This could then be 
used to link to the software installer so that the user would simply 
select the application they want to use from the shadow menu and it 
would then be installed and would appear in the real menu.

Building the shadow menu should be possible by looking for .desktop 
files (or whatever it is which defines menu entries) in rpm packages.

Simon.



From ngompa13 at gmail.com  Thu Nov 22 11:58:28 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 22 Nov 2007 05:58:28 -0600
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <16de708d0711212353p2592489fv419d7b386046bf3e@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<16de708d0711212353p2592489fv419d7b386046bf3e@mail.gmail.com>
Message-ID: <8278b1b0711220358j47e313ach3ffed3920084291a@mail.gmail.com>

With Elisa in the repository, this might actually be possible. Xorg has had
the ATI Theater 200 chip support for quite some time AFAIK, and the Theater
200 chip is used in ATI eHomeWonder and ATI TV Wonder 200 PCI. Both of these
cards are quite popular with PC manufacturers. Also, the ATI All-in-Wonder
2006 AGP Edition uses the Theater 200 chip, along with a Radeon 9600
graphics module, which I believe is supported currently with 3D and compiz
stuff. Since Elisa uses GStreamer, and since it might be necessary for MPEG2
support, we can refer to fluendo (not the most ideal solution, but meh) for
the MPEG2 decoder packs for TV to work.

On Nov 22, 2007 1:53 AM, Arthur Pemberton <pemboa at gmail.com> wrote:

> On Nov 21, 2007 9:29 PM, Otto Rey <otto_rey at yahoo.com.ar> wrote:
> > Fedora should have a good support of TV cards. I have a LifeView
> FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV
> working. I try almost everything (i am developer).
> > For home users, Fedora 9 TV support should by something like this:
> "Install this crappy package and you are zapping" :D
> >
> > Sorry for my english.
>
> The general idea (I think) is "Install a Hauppauge card" they
> generally work plug and play.
>
> --
> Fedora 7 : sipping some of that moonshine
> ( www.pembo13.com )
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/4754d3f4/attachment.htm>

From dominik at greysector.net  Thu Nov 22 12:20:39 2007
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 22 Nov 2007 13:20:39 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122122039.GA2828@ryvius.greysector.net>

On Wednesday, 21 November 2007 at 23:55, Richard Hally wrote:
> Bruno Wolff III wrote:
[...]
> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

Confirmed here as well.

R.

-- 
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From buildsys at redhat.com  Thu Nov 22 12:30:10 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 22 Nov 2007 07:30:10 -0500
Subject: rawhide report: 20071122 changes
Message-ID: <200711221230.lAMCUAYR030149@porkchop.devel.redhat.com>

New package esorex
	EsoRex is the European Southern Observatory Recipe Execution Tool

New package gnofract4d
	Gnofract 4D is a Gnome-based program to draw fractals

New package perl-File-Find-Rule-Perl
	Common rules for searching for Perl things

New package perl-Perl-MinimumVersion
	Find a minimum required version of perl for Perl code

New package php-pear-pake
	PHP5 project builder system

New package php-pear-phing
	A project build system based on Apache Ant


 
Updated Packages:

AcetoneISO-6.7-3.fc9
--------------------

amarok-1.4.7-11.fc9
-------------------
* Wed Nov 21 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.4.7-11
- dynamic mode floods playlist ... (kde #148317)

* Wed Nov 21 2007 Todd Zullinger <tmz at pobox.com> 1.4.7-10
- rebuild for libgpod-0.6.0

* Tue Nov 20 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.4.7-9
- cosmetics (cleanup/sort BR's mostly)
- omit "for KDE" from summary/description
- make gst support toggled by macro (disabled by default)

audacious-plugin-fc-0.2-5
-------------------------
* Wed Nov 21 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 0.2-5
- patch for new API
- rebuilt for SONAME changes in Audacious 1.4.x

audacious-plugins-1.4.1-1.fc9
-----------------------------
* Mon Nov 19 2007 Ralf Ertzinger <ralf at skytale.net> 1.4.1-1
- Update to 1.4.1

bouml-doc-3.0-1.fc9
-------------------
* Wed Nov 21 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.0-1
- Version bump to 3.0.

bsd-games-2.17-22.fc9
---------------------
* Tue Nov 20 2007 Wart <wart at kobold.org> 2.17-22
- Create setgid groups as system groups (BZ# 389191)

claws-mail-3.1.0-1.fc9
----------------------
* Mon Nov 19 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.1.0-1
- version upgrade

curl-7.17.1-2.fc9
-----------------
* Wed Nov 21 2007 Jindrich Novy <jnovy at redhat.com> 7.17.1-2
- update description to contain complete supported servers list (#393861)

* Sat Nov 17 2007 Jindrich Novy <jnovy at redhat.com> 7.17.1-1
- update to curl 7.17.1
- include patch to enable SSL usage in NSS when a socket is opened
  nonblocking, thanks to Rob Crittenden (rcritten at redhat.com)

* Wed Oct 24 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-10
- correctly provide/obsolete curl-devel (#130251)

em8300-0.16.3-2.fc9
-------------------
* Wed Nov 21 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.16.3-2
- Drop dependency on em8300-kmod.

gparted-0.3.3-14.fc9
--------------------
* Thu Nov 22 2007 Deji Akingunola <dakingun at gmail.com> - 0.3.3-14
- Fix to detect full path to device/partition pathname (Bug #395071)

gtkpod-0.99.10-2.fc9
--------------------
* Wed Nov 21 2007 Todd Zullinger <tmz at pobox.com> - 0.99.10-2
- rebuild for libgpod-0.6.0
- apply upstream patch to fix smart playlist play time bug
- Requires: which (used in some of the provided scripts)

gtkterm-0.99.5-7.fc9
--------------------
* Wed Nov 21 2007 Dan Horak <dan[at]danny.cz> 0.99.5-7
- fix buffer usage (bz 394891)

gxine-0.5.11-12.fc9
-------------------
* Wed Nov 21 2007 Martin Sourada <martin.sourada at seznam.cz> - 0.5.11-12
- --rpath hack hopefully no longer needed
- build against new xulrunner
- fix path for xulrunner to use %{libdir}

ice-3.2.1-13.fc9
----------------
* Tue Nov 20 2007 Mary Ellen Foster <mefoster at gmail.com> 3.2.1-13
- Enable the IceGrid GUI
- Fix a problem with Python on 64-bit systems (bz #392751)
- Incorporate one more Mono patch from ZeroC

* Tue Oct 30 2007 Mary Ellen Foster <mefoster at gmail.com> 3.2.1-12
- Put the slice2java classes into a .jar file instead of as bare classes
- Incorporate all Ice 3.2.1 patches from ZeroC
- Fix templates path in icegridregistry.conf

* Fri Sep 07 2007 Mary Ellen Foster <mefoster at gmail.com> 3.2.1-11
- Also add Obsoletes: for the old zeroc names
- Fix bad date in changelog

ikarus-0.0.1-4.fc9
------------------
* Wed Nov 21 2007 Michel Salim <michel.sylvan at gmail.com> 0.0.1-4
- Remove excludearch line comments
jwhois-4.0-4.fc9
----------------
* Tue Nov 20 2007 Lubomir Kundrak <lkundak at redhat.com> - 4.0-4
- Fix connections to IPv4 servers

k3b-0:1.0.4-3.fc9
-----------------
* Wed Nov 21 2007 Adam Tkac <atkac redhat com> - 0:1.0.4-3
- rebuild against new libdvdread

kdeedu-3.96.0-3.fc9
-------------------
* Wed Nov 21 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.0-3
- Obsoletes/Provides: marble (#394011)

kernel-2.6.24-0.41.rc3.git1.fc9
-------------------------------
* Wed Nov 21 2007 John W. Linville <linville at redhat.com>
- Resync wireless bits from upstream

* Wed Nov 21 2007 David Woodhouse <dwmw2 at redhat.com>
- Fix <linux/kd.h> in userspace.

* Sun Nov 18 2007 Kyle McMartin <kmcmartin at redhat.com>
- 2.6.24-rc3-git1

kipi-plugins-0.1.5-0.1.beta1.fc9
--------------------------------
* Wed Nov 21 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.1.5-0.1.beta1
- kipi-plugins-0.1.5-beta1
- cleanup %description

* Wed Nov 21 2007 Todd Zullinger <tmz at pobox.com> 0.1.4-5
- rebuild against libgpod-0.6.0

ktorrent-2.2.4-1.fc9
--------------------
* Wed Nov 21 2007 Roland Wolters <wolters.liste at gmx.net> - 2.2.4-1
- bugfix update to version 2.2.4

less-415-1.fc9
--------------
* Wed Nov 21 2007 Zdenek Prikryl <zprikryl at redhat.com> - 415-1
- Update to 415

* Tue Nov 13 2007 Ivana Varekova <varekova at redhat.com> - 409-2
- remove which usage (#312591)

* Mon Oct 22 2007 Ivana Varekova <varekova at redhat.com> - 409-1
- upgrade to 409
- remove useless/obsolete patches
- add autoconf buildrequires

libgpod-0.6.0-1.fc9
-------------------
* Wed Nov 21 2007 Todd Zullinger <tmz at pobox.com> - 0.6.0-1
- update to 0.6.0
- apply a few upstream patches that just missed the release

liferea-1.4.8-1.fc9
-------------------
* Wed Nov 21 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.4.8-1
- Update to 1.4.8.
- fixes LD_LIBRARY_PATH security bug. CVE-2006-4791 (#393311)

namazu-2.0.17-4.fc9
-------------------
* Wed Nov 21 2007 Akira TAGOH <tagoh at redhat.com> - 2.0.17-4
- Set the own script to __perl_requires.

phpMyAdmin-2.11.2.2-1.fc9
-------------------------
* Wed Nov 21 2007 Robert Scheck <robert at fedoraproject.org> 2.11.2.2-1
- Upstream released 2.11.2.2 (#393771)

qt-qsa-1.1.5-3.fc9
------------------
* Thu Nov 22 2007 Julian Sikorski <belegdol[at]gmail[dot]com> - 1.1.5-3
- Fixed multiarch conflicts (RH #343031)

rhythmbox-0.11.3-5.fc9
----------------------
* Wed Nov 21 2007 Todd Zullinger <tmz at pobox.com> - 0.11.3-5
- Rebuild against libgpod-0.6.0

rubygem-zoom-0.4.1-2.fc9
------------------------
* Wed Nov 21 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.1-2
- 0.4.1
- Also update URL

sgml-common-0.6.3-22.fc9
------------------------
* Thu Nov 15 2007 Ondrej Vasik <ovasik at redhat.com> 0.6.3-22
- Merge Review(226415)
- changed: License Tag, using RPM macros instead of hardcoded
  dirs, summary ended with dot, added URL, removed CHANGES
  file as obsolete, preserved timestamps and some other cosmetic 
  changes
- no longer shipping old automake tarball, fixed issue with man8_DATA,
  BuildRequire:Automake,Autoconf again(see MergeReview discussion)

speedcrunch-0.9-1.fc9
---------------------
* Thu Nov 22 2007 Roland Wolters <wolters.liste at gmx.net> - 0.9-1
- update to version 0.9 including a new math engine and inverse hyperbolic
  functions

straw-0.27-12.fc9
-----------------
* Wed Nov 21 2007 Alex Lancaster <alexlan at fedoraproject.org> - 0.27-12
- Resolve Conflict with python-adns

system-config-firewall-1.0.11-1.fc9
-----------------------------------
* Wed Nov 21 2007 Thomas Woerner <twoerner at redhat.com> 1.0.11-1
- fixed crash on startup for network device aliases (rhbz#384891)
  thanks to Loran Freval for the patch
- added port entry max length in other ports dialog (rhbz#385931)
- added version number to about dialog (rhbz#387891)
- improved some english texts (rhbz#383741)
  thanks to Paul W. Frields for the initial patch
- code cleanup with start speedup
- do not allow to add custm rules for ipv6:nat
- also translate parser error messages

system-config-rootpassword-1.99.0-1.fc9
---------------------------------------
* Wed Nov 21 2007 Lubomir Kundrak <lkundrak at redhat.com - 1.99.0-1
- Bump version

* Tue Nov 20 2007 Lubomir Kundrak <lkundrak at redhat.com - 1.1.10-5
- Major SPEC file cleanup (#226467)

xkeyboard-config-1.1-5.20071120cvs.fc9
--------------------------------------
* Mon Nov 19 2007 Bernardo Innocenti <bernie at codewiz.org> 1.1-5.20071119cvs
- Upgrade xkeyboard-config snapshot to cvs20071119
- Add olpc-xkeyboard-config-af.patch
- Add olpc-xkeyboard-config-kz-group.patch
- Add olpc-xkeyboard-config-ng-group.patch
- Add olpc-xkeyboard-config-ng-h.patch
- Remove olpc-xkeyboard-config-ara-fixes.patch (integrated upstream)
- Remove olpc-xkeyboard-config-br-accents.patch (integrated upstream)
- Remove olpc-xkeyboard-config-es-accents.patch (integrated upstream)
- Remove olpc-xkeyboard-config-us-typo.patch (integrated upstream)

* Sat Oct 27 2007 Bernardo Innocenti <bernie at codewiz.org> 1.1-5.20071009cvs
- Add olpc-xkeyboard-config-ara-fixes.patch
- Add olpc-xkeyboard-config-br-accents.patch
- Add olpc-xkeyboard-config-es-accents.patch
- Add olpc-xkeyboard-config-us-typo.patch

* Tue Oct 09 2007 Bernardo Innocenti <bernie at codewiz.org> - 1.1-4.20071009cvs
- Upgrade xkeyboard-config snapshot to cvs20071009

Broken deps for i386
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	conky - 1.4.8-1.fc9.i386 requires libaudacious.so.5
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3



Broken deps for x86_64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.x86_64 requires libaudacious.so.5()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	conky - 1.4.8-1.fc9.ppc requires libaudacious.so.5
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3



Broken deps for ppc64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.ppc64 requires libaudacious.so.5()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)





From bruno at wolff.to  Wed Nov 21 15:15:10 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 21 Nov 2007 09:15:10 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071121151510.GA21330@wolff.to>

On Tue, Nov 20, 2007 at 19:41:33 +0100,
  Olivier Galibert <galibert at pobox.com> wrote:
> 
> At fedora core 5 times, Everything was lost.  Thankfully it is still
> in kickstart, but it makes the initial testing phase more annoying.
> Way more problematic is the support time which went down to one year.

I still run Fedora 5 on one machine because of a kernel bug. It works well
for me.

> At fedora 7 time, Core was mostly lost.  There is still the list of
> package on the DVD as a guideline though, but there isn't a separate
> updates directory you can easily merge in anymore.  To the point that
> I didn't find the time to do the new installation before 8 was out.

The "everything" repository exists and I use a local copy of it to do
yum upgrades. Having core and extras combined seems to be a much nicer
approach than what was done previously. The Unity people have even put
out a multiDVD "Everything" spin.

> Now we're at 8 and I want to try to move to it, but static ip support
> is fucked, and the list of packages on the DVD doesn't even have tcsh,
> which 50% of the people here use.  Installing from the DVD by checking
> all 3 options at the top level doesn't even give you make or gcc,
> which is kind of annoying when the reason for installing interactively
> in the first place is to have everything needed to hack on anaconda to
> fix the static ip issue.  An yum install '*' conflicts all the way due
> to the multilib crap.

I use static IP addresses and don't have a problem with that. I don't use
NM though. There are some advanced things I do using iproute2 in rc.local,
but the plain stuff can be done with system-config-network.

> Fedora was originally nice for people coming from an Unix background,
> where 50% of the windows on the screen are xterms.  It seems to have
> collectively decided that it should instead cater to the Windows kind
> of people, to the detriment of the Unix ones.  A default installation

I don't see that.

> does not have a compiler.  Everything looking slightly technical is
> hidden as much as possible.  Easily understandable and editable text
> configuration files are routinely replaced by an obfuscated xml-based
> registry[1] with automatically generated GUIs from hell[2].  Basic
> things like static ips and routes are considered legacy and their
> support totally untested and/or considered unimportant.  And
> significantly every comparison is done with Ubuntu, the epitome of the
> windowsian-come-here distributions, and never with Debian or Gentoo.

When I see people asking for Fedora to be more like Ubuntu, I typically
see a response that we aren't going there.

> Keep cranking up the pain, guys, and fedora will definitively makes
> its place in the "master of none" category.

Well, there is definitely pain involved with Fedora. That's best helped by
having some people volunteer to try rawhide to catch issues early.



From galibert at pobox.com  Thu Nov 22 13:26:24 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 22 Nov 2007 14:26:24 +0100
Subject: File conflicts, how do they work at that point?
In-Reply-To: <alpine.DEB.0.9999.0711211049390.32062@gotcha.dreamhost.com>
References: <20071120162800.GC40258@dspnet.fr.eu.org>
	<alpine.DEB.0.9999.0711211029430.32062@gotcha.dreamhost.com>
	<4743EDF4.4090106@fedoraproject.org>
	<alpine.DEB.0.9999.0711211049390.32062@gotcha.dreamhost.com>
Message-ID: <20071122132624.GA76845@dspnet.fr.eu.org>

On Wed, Nov 21, 2007 at 10:57:32AM +0200, Panu Matilainen wrote:
> On Wed, 21 Nov 2007, Rahul Sundaram wrote:
> 
> >Panu Matilainen wrote:
> >
> >>
> >>Yes it's confusing and inconsistent behavior which I *really* want to get 
> >>rid of. It's just that this is not a simple matter of "fixing rpm" - our 
> >>package set is full of conflicting files. The package set needs fixing, 
> >>otherwise you'll have a very much uninstallable x86_64 (and to slightly 
> >>lesser effect ppc) tree.
> >
> >Wouldn't fixing rpm early in the development cycle encourage more packages 
> >to get fixed faster?
> 
> That's the very reason bug #190209 is being dusted off at the moment :)

What are the rules you want to have?
1- always conflict
2- conflict if contents different
3- conflict if contents different and color identical
4- conflict if contents different and color not RPMFC_ELF*
5- something else

Current rule in incremental installations is 3, right?

  OG.



From varekova at redhat.com  Thu Nov 22 13:39:51 2007
From: varekova at redhat.com (Ivana Varekova)
Date: Thu, 22 Nov 2007 14:39:51 +0100
Subject: Pilot-link updated to 0.12.3
Message-ID: <474586A7.1050107@redhat.com>

Hello,
I just update pilot-link to 0.12.3, there were bigger changes so 
packages which depends on pilot-link should be rebuild.
Affected packages:

claws-mail   
evolution
gnome-pilot
gnome-pilot-conduits
jpilot
kdepim
libmal
libopensync-plugin-palm

Thanks.
Ivana Varekova



From bruno at wolff.to  Thu Nov 22 13:50:15 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 07:50:15 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122135015.GA17942@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am seeing them too, but wasn't sure if other people were. I suspect
network congestion causing the connection to be dropped after the message
was accepted but before it was aknowleged. I saw a few other messages
in that thread duplicated as well on my end.
I'll take a look to see if it is still queued on my end and get rid of it
if it is.



From pp at ee.oulu.fi  Thu Nov 22 13:52:21 2007
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Thu, 22 Nov 2007 15:52:21 +0200
Subject: Large Fedora deployments (was: Re: WTF? Inaccessible bug reports?)
In-Reply-To: <20071120184133.GA51420@dspnet.fr.eu.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
Message-ID: <20071122135221.GA15086@ee.oulu.fi>

On Tue, Nov 20, 2007 at 07:41:33PM +0100, Olivier Galibert wrote:
> [Sent it personally instead of to the list by mistake]
> 
> On Tue, Nov 20, 2007 at 06:06:54PM +0100, Lubomir Kundrak wrote:
> > 
> > On Tue, 2007-11-20 at 15:51 +0100, Olivier Galibert wrote:
> > > On Tue, Nov 20, 2007 at 08:26:47AM -0600, Josh Boyer wrote:
> > > > Perhaps you should calm down a bit.  Flying off the handle before
> > > > asking if the bug permissions can be changed or an explanation is
> > > > provided is probably not going to be very productive.
> > > 
> > > Well, sorry.  Fedora becomes worse for my use with each release I try,
> > > and I'm starting to get really annoyed at that, because it used to be
> > > so much better.
> > 
> > May I ask what's "your use"?
> 
> My use is a team in a lab with 100-200 machines, about 30 of them
> physically on people's desktops, about 80 in two oscar clusters.  Some
> of the people could do system administration, some couldn't, most
> don't want to anyway.
> 
> Since I ended up as sysadmin-by-default, I need a distribution which I
> can install and update with a minimum amount of fussing, and where the
> installation has pretty much everything the users are going to need.
We're in a somewhat similar situation here. I think how things might
work well is having one box where "anyone" could install packages from
specified RPM repos. After everyone is happy with that one box,
the package list from that machine gets put into ks.conf and also synced to
all machines after being reviewed by the admins.
 
This could then be repeated every time someone needs their favourite editor
etc. added to the default install. Preferably with no extra privileges required
to use yum&graphical versions (PackageKit?)

Currently it's * from the DVD + some custom packages from Everything/livna.
I install my laptop manually since even the * from DVD is so bloated :/

Or maybe what's needed is a "everything a scientific desktop user might ever
want" spin. KDE/ooffice i18n files for obscure languages are probably the
most annoying extra payload * gives. And also those enterprise management 
thingies that I can't even figure out what they actually do, but there's
some mystery daemon started on boot by default nevertheless.

YMMV :P

-- 
Pekka Pietikainen
 



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From pingoufc4 at yahoo.fr  Thu Nov 22 14:22:30 2007
From: pingoufc4 at yahoo.fr (pingou)
Date: Thu, 22 Nov 2007 15:22:30 +0100
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071122141340.GA2857@wolff.to>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120082647.137221b6@weaponx>	<20071120145119.GA26405@dspnet.fr.eu.org>	<1195578414.3568.58.camel@localhost.localdomain>	<20071120184133.GA51420@dspnet.fr.eu.org>	<20071121151510.GA21330@wolff.to>
	<4744B768.301@mindspring.com> <20071122141340.GA2857@wolff.to>
Message-ID: <474590A6.5060103@yahoo.fr>

Bruno Wolff III wrote:
> On Wed, Nov 21, 2007 at 17:55:36 -0500,
>   Richard Hally <rhally at mindspring.com> wrote:
> 
>> Bruno, It looks like there is a problem with your mailer. I have received 9 
>> copies of this message!
>> There is also one with 2:15pm time that I have received 6 times. All the 
>> other messages from other people are ok.
> 
> I am not sure why this happened. I did find about a 1/2 dozen messages
> queued for redhat and removed them from the queue and restarted the
> MTA.
> 
Confirmed, I received already this message 3 time :)

Regards
~pingou

	

	
		
___________________________________________________________________________ 
Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.
http://fr.mail.yahoo.com



From sundaram at fedoraproject.org  Thu Nov 22 14:23:12 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 22 Nov 2007 19:53:12 +0530
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <4744D8EA.9000603@nobugconsulting.ro>
References: <20071120140550.GA20367@dspnet.fr.eu.org>	<20071120082647.137221b6@weaponx>	<20071120145119.GA26405@dspnet.fr.eu.org>	<1195578414.3568.58.camel@localhost.localdomain>	<20071120184133.GA51420@dspnet.fr.eu.org>	<1195659663.7424.22.camel@space-ghost.verbum.private>	<604aa7910711210903h1056e4aah56139628c9e36d22@mail.gmail.com>
	<4744D8EA.9000603@nobugconsulting.ro>
Message-ID: <474590D0.4020905@fedoraproject.org>

Manuel Wolfshant wrote:
> On 11/21/2007 07:03 PM, Jeff Spaleta wrote:
>> On Nov 21, 2007 6:41 AM, Colin Walters <walters at redhat.com> wrote:
>>  
>>> There is also a third option - write your own kickstart file defining
>>> exactly what you want, and use it to install.
>>>     
>>
>> I'd like to see if we as a project can extend this option, so that we
>> can archive and make a gallery of contributed kickstart files for
>> people to use for niche usage cases.  Perhaps then Olivier could work
>> with other niche admins who want to beat Fedora into submission to
>> create a suitable baseline kickstart for his usage case.
> In addition to that I'd like to see a 
> http://GenerateYourOwnKickstartFileHere.fedoraproject.org with something 
> similar to system-config-kickstart running on the server and generating 
> on the fly kickstart images for those who have no idea how a kickstart 
> file looks like but know that using one would save their time [1]. A 
> tool which would know the more esoteric options similar to those 
> described at http://wiki.centos.org/TipsAndTricks/KickStart [2]

Check out

https://hosted.fedoraproject.org/projects/wevisor/

Rahul



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From jsafrane at redhat.com  Thu Nov 22 15:59:12 2007
From: jsafrane at redhat.com (Jan Safranek)
Date: Thu, 22 Nov 2007 16:59:12 +0100
Subject: Heads up: openldap rebase for Fedora/devel
Message-ID: <4745A750.4080904@redhat.com>

Upstream recently released new minor (2.4.x) version of OpenLDAP
package: http://www.openldap.org/software/release/announce.html

You can see there list of changes. From development point of view I did 
not notice any difference, the API should be the same as in previous 
version.

I'd like to update openldap in devel to the new version. Many packages 
depend on openldap, so I will provide compat-openldap package, which 
will provide 2.3.x libraries and no recompilation of any component would 
be required.

I'd like to to ask all maintainers of components, which depend on 
openldap (see appendix), to test following simple cases:

1. the component works with compat-openldap, which provides 'old' 2.3.x
libraries

2. the component is compilable with new openldap-devel-2.4.6

3. the recompiled component works with new openldap-2.4.6 (and with
2.4.6 and 2.3.39 server)

I roughly tested all these scenarios with nss_ldap without any problems,
including the recompilation.

2.4.6 release is prepared in CVS. You can find binaries (as yum
repository) at
http://people.redhat.com/jsafrane/openldap-2.4-preview/$arch.

I would like to build and release openldap-2.4.6 at the beginning of
December - does it sound realistically to test at least the first point
until then? I do not expect any problem, but I want to be sure that new
openldap does not break anything when I release it. Feel free to propose
better plan.

Thanks,

Jan


Appendix: list of packages, depending on openldap:
am-utils
anjuta
apr-util
compat-openldap
cyrus-sasl-ldap
dbmail
dbmail-auth-ldap
evolution
evolution-connector
GConf2
kdebase
kdepimlibs
kdesvn
krb5-server-ldap
libapreq2
libsmbclient
libuser
mod_authz_ldap
mod_revocator
nfs-utils-lib
nss_ldap
opal
openpbx
postfix
pwlib
python-ldap
samba-common
seahorse
sendmail
subversion
wine-ldap



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From wtogami at redhat.com  Thu Nov 22 16:16:02 2007
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 22 Nov 2007 11:16:02 -0500
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <4745A750.4080904@redhat.com>
References: <4745A750.4080904@redhat.com>
Message-ID: <4745AB42.8050206@redhat.com>

Jan Safranek wrote:
> Upstream recently released new minor (2.4.x) version of OpenLDAP
> package: http://www.openldap.org/software/release/announce.html
> 
> You can see there list of changes. From development point of view I did 
> not notice any difference, the API should be the same as in previous 
> version.
> 
> I'd like to update openldap in devel to the new version. Many packages 
> depend on openldap, so I will provide compat-openldap package, which 
> will provide 2.3.x libraries and no recompilation of any component would 
> be required.

Why provide compat-openldap if the API's are the same, as you say?

The reason we occasionally provide an old compat version is when too 
many apps don't BUILD against the new version of the library.  It is an 
anti-goal in Fedora to keep a compat-* library entirely for the sake of 
avoiding rebuilds.

If most apps build fine against the new openldap, please do not provide 
a compat-openldap package.  If there is huge API breakage then we need 
to discuss the possibility of a compat-* package.

http://fedoraproject.org/wiki/Releases/9/Schedule
You are being far too cautious about breaking things in rawhide, 
especially this far before the Alpha1 development freeze.

Please build yourself the new openldap locally in mock, and test for 
yourself whether every package rebuilds cleanly against the new version 
within mock.  It is good enough if *most* other rawhide packages are 
easily rebuildable against the new openldap at the time it is upgraded 
in rawhide.  Work with the owners of the dependent packages to prepare 
for rawhide inclusion and to be sure all packages are rebuilt against it 
after it completes.

If the dependent package rebuild testing shows few problems, go ahead 
with upgrading the version even before December.  The sooner during this 
rawhide cycle the better, to stabilize before Alpha1.

Warren Togami
wtogami at redhat.com



From tibbs at math.uh.edu  Thu Nov 22 16:18:27 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 22 Nov 2007 10:18:27 -0600
Subject: javadoc scriptlets
In-Reply-To: <1195716907.21601.1.camel@rousalka.dyndns.org>
References: <ufak5oax3he.fsf@epithumia.math.uh.edu>
	<1195716907.21601.1.camel@rousalka.dyndns.org>
Message-ID: <ufazlx6uucs.fsf@epithumia.math.uh.edu>

>>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:

NM> (also why are you posting all those java-related questions there
NM> instead on fedora-java or jpackage-discuss? That's where the java
NM> packagers dwell)

Well, only two questions, and I am not a member of either of those
lists and honestly I really don't want to join any more lists.  If
there's nobody that knows java here who can answer basic questions
then we have a rather significant disconnect, I'd think.

 - J<



From ivazqueznet at gmail.com  Thu Nov 22 16:19:42 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 22 Nov 2007 11:19:42 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <16de708d0711212353p2592489fv419d7b386046bf3e@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<16de708d0711212353p2592489fv419d7b386046bf3e@mail.gmail.com>
Message-ID: <1195748382.24136.13.camel@ignacio.lan>

On Thu, 2007-11-22 at 01:53 -0600, Arthur Pemberton wrote:
> On Nov 21, 2007 9:29 PM, Otto Rey <otto_rey at yahoo.com.ar> wrote:
> > Fedora should have a good support of TV cards. I have a LifeView FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV working. I try almost everything (i am developer).
> > For home users, Fedora 9 TV support should by something like this: "Install this crappy package and you are zapping" :D
> >
> > Sorry for my english.
> 
> The general idea (I think) is "Install a Hauppauge card" they
> generally work plug and play.

Not all of them, trust me. The PVR-150 is most definitely NOT
plug-and-play in Fedora.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/8e866f75/attachment.sig>

From ivazqueznet at gmail.com  Thu Nov 22 16:20:58 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 22 Nov 2007 11:20:58 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <8278b1b0711220358j47e313ach3ffed3920084291a@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<16de708d0711212353p2592489fv419d7b386046bf3e@mail.gmail.com>
	<8278b1b0711220358j47e313ach3ffed3920084291a@mail.gmail.com>
Message-ID: <1195748458.24136.15.camel@ignacio.lan>

On Thu, 2007-11-22 at 05:58 -0600, King InuYasha wrote:
> With Elisa in the repository, this might actually be possible. Xorg
> has had the ATI Theater 200 chip support for quite some time AFAIK,
> and the Theater 200 chip is used in ATI eHomeWonder and ATI TV Wonder
> 200 PCI. Both of these cards are quite popular with PC manufacturers.
> Also, the ATI All-in-Wonder 2006 AGP Edition uses the Theater 200
> chip, along with a Radeon 9600 graphics module, which I believe is
> supported currently with 3D and compiz stuff. Since Elisa uses
> GStreamer, and since it might be necessary for MPEG2 support, we can
> refer to fluendo (not the most ideal solution, but meh) for the MPEG2
> decoder packs for TV to work. 

elisa's analog TV support is extremely primitive, and limited only to
ivtv cards, and not currently working.

https://code.fluendo.com/elisa/trac/ticket/246

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/c1d33a48/attachment.sig>

From galibert at pobox.com  Thu Nov 22 16:21:35 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 22 Nov 2007 17:21:35 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
References: <20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
	<604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
Message-ID: <20071122162135.GB76845@dspnet.fr.eu.org>

On Wed, Nov 21, 2007 at 04:04:50PM -0900, Jeff Spaleta wrote:
> Because for other, established, usage cases that have seen significant
> discussion, having a lot of stuff you don't need installed has costs
> in terms of security and bandwidth consumption when doing things like
> updates.

Hmmm.  Not much of what is in there is servers or reuires any kind of
priviledges though.  As for bandwidth, that's rather cheap too as long
as it's not upload.  I understand it can be an issue for mirrors
though.


> What you are doing is firmly outside of the usage cases for
> which any coherent plan has been even described let along attempted to
> be implemented as part of this project.  A subproject to make
> everything or nearly everything installs work from a kickstart file or
> from a specialally designed spin doesn't sound like something that
> could not be done as part of F9   release prep. But there has to be
> people willing to drive this forward. Are you one of these people?
> You clearly care about the issue, but are you prepared to step up and
> chart a course to see improvement in a family of usage cases that
> matter to you?

Well, I need Core back.  Not Core as in "my package is holier than
yours", that we can do without, but core as in "all these packages
work well together, can all be installed together, and you will be
able to do mostly anything with them".  Jesse Keating told last june
on the list, after yet another of my bitchings, that the "Fedora"
spin, aka the packages on the DVD, were supposed to replace that.  The
F8 release shows it's not the case anymore.

I'm not sure how technically and socially a core-like package
selection could be organized.  Any experience in that area?


> > Disk is cheap, time isn't.
> This statement goes against the fundamental axioms by which graduate
> students come into being.
> You just need more graduate students.

Actually, graduates students are getting expensive in this part of the
planet.  Science is not that interesting anymore as a studies, it
seems.


> -jef"is anyone working on a Fedora spin meant for cluster usage already?"spaleta

Oscar does.  It kinda sucks though, because they forgot that disk is
cheap, and you can't predict what is going to be used on the cluster.
Sometimes the job includes command-line php scripts.  Sometimes the
end stages include some scripted rendering though TeX or gnuplot.
Things like that.  So instead of using their spin I just slightly
patch my standard "everything goes" one.

  OG.



From ville.skytta at iki.fi  Thu Nov 22 16:29:03 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 22 Nov 2007 18:29:03 +0200
Subject: javadoc scriptlets
In-Reply-To: <1195716907.21601.1.camel@rousalka.dyndns.org>
References: <ufak5oax3he.fsf@epithumia.math.uh.edu>
	<1195716907.21601.1.camel@rousalka.dyndns.org>
Message-ID: <200711221829.04437.ville.skytta@iki.fi>

On Thursday 22 November 2007, Nicolas Mailhot wrote:
> Le mercredi 21 novembre 2007 ? 23:18 -0600, Jason L Tibbitts III a
>
> ?crit :
> > * Sat Sep  3 2005 Anthony Green <green at redhat.com> - 0:1.1.1-7
> > - Removed %ghost for javadoc, and remove javadoc post scriptlet,
> >   as per ville.skytta at iki.fi's suggestion.
> >
> > But I don't know what the basis for that was, and I don't see anything
> > relevant in bugzilla.  Perhaps Ville can remember that far back.
> >
> > Does anyone know the rationale for this?
>
> Ask Ville. He's the javadoc man.

As far as I'm concerned, there's exactly one hard requirement for javadoc 
installs: unversioned dir (or at least a symlink).  This is for 
bookmarkability (browsers, IDEs), easy crosslinking of javadocs at package 
build time, and not having the links break when crosslinked javadoc packages 
are updated.

The intention of the original JPackage javadoc scriptlets was that one could 
install multiple versions of some javadoc package in parallel.  That'd be 
kind of cool.  But it's too tricky to get right for my taste.  The current 
scriptlets are an halfway there attempt to do it, but they're already quite 
ugly and suffer from two problems: 1) the unversioned symlink will point to 
the javadoc package which was installed last, not the latest version, which 
IMO isn't useful, and 2) they fail with read-only %_netsharedpath /usr/share 
setups.

Those are fixable by adding some more ugliness to the scriptlets (possibly 
much more to get 1) taken care of), but because we don't actually ship 
multiple versions of javadoc packages (they get pruned just like other old 
package versions) or when we do, we ship them in packages with 
different %{name}, I think the sane approach is to just forget about the 
symlink games, install to unversioned %{_javadocdir}/%{name} and be done with 
it.

For the same reason, my NSHO is is that packages shipping jars 
in /usr/share/java should just drop their jars unversioned there and not 
bother with symlinks.  I'm pretty sure that the symlinks between different 
versions of a package would and do actually conflict in the vast majority of 
cases without some "%verify(not link)" magic which is currently very rare 
AFAIK.  So the symlinkage and versioning is pretty much useless cruft 
nowadays, and because nobody appears to be complaining about the inability to 
install multiple versions in parallel, it should be dropped.

> (also why are you posting all those java-related questions there instead
> on fedora-java or jpackage-discuss? That's where the java packagers
> dwell)

FWIW, I'm not reading those, but then again I'm not an active Java packager 
these days anyway.



From jkeating at redhat.com  Thu Nov 22 16:30:45 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Nov 2007 11:30:45 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071122162135.GB76845@dspnet.fr.eu.org>
References: <20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
	<604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
	<20071122162135.GB76845@dspnet.fr.eu.org>
Message-ID: <20071122113045.0977d9d0@redhat.com>

On Thu, 22 Nov 2007 17:21:35 +0100
Olivier Galibert <galibert at pobox.com> wrote:

> Well, I need Core back.  Not Core as in "my package is holier than
> yours", that we can do without, but core as in "all these packages
> work well together, can all be installed together, and you will be
> able to do mostly anything with them".  Jesse Keating told last june
> on the list, after yet another of my bitchings, that the "Fedora"
> spin, aka the packages on the DVD, were supposed to replace that.  The
> F8 release shows it's not the case anymore.
> 
> I'm not sure how technically and socially a core-like package
> selection could be organized.  Any experience in that area?

A "core" is as good as the people testing it can make it.  Modulo the
multilib conflicts which is a problem of it's own, what issues do you
have?  I'm open for more discussion on what all should land on the DVD,
note /discussion/, not demands.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/524199f5/attachment.sig>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From galibert at pobox.com  Thu Nov 22 17:02:53 2007
From: galibert at pobox.com (Olivier Galibert)
Date: Thu, 22 Nov 2007 18:02:53 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071122113045.0977d9d0@redhat.com>
References: <20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
	<604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
	<20071122162135.GB76845@dspnet.fr.eu.org>
	<20071122113045.0977d9d0@redhat.com>
Message-ID: <20071122170253.GA2266@dspnet.fr.eu.org>

On Thu, Nov 22, 2007 at 11:30:45AM -0500, Jesse Keating wrote:
> A "core" is as good as the people testing it can make it.  Modulo the
> multilib conflicts which is a problem of it's own, what issues do you
> have?  I'm open for more discussion on what all should land on the DVD,
> note /discussion/, not demands.

Well, the multilib conflicts is the #1 problem.  If we ignore that and
you tell me the dvd is still seens as the core replacement, I'm in
practice happy with that.  There is a conflict between generic-logos
and fedora-logos, and I consider the lack of tcsh a simple mistake.
Minor, all of that.

  OG.



From nicolas.mailhot at laposte.net  Thu Nov 22 17:38:27 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Nov 2007 18:38:27 +0100
Subject: javadoc scriptlets
In-Reply-To: <ufazlx6uucs.fsf@epithumia.math.uh.edu>
References: <ufak5oax3he.fsf@epithumia.math.uh.edu>
	<1195716907.21601.1.camel@rousalka.dyndns.org>
	<ufazlx6uucs.fsf@epithumia.math.uh.edu>
Message-ID: <1195753107.21601.25.camel@rousalka.dyndns.org>


Le jeudi 22 novembre 2007 ? 10:18 -0600, Jason L Tibbitts III a ?crit :
> >>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:
> 
> NM> (also why are you posting all those java-related questions there
> NM> instead on fedora-java or jpackage-discuss? That's where the java
> NM> packagers dwell)
> 
> Well, only two questions, and I am not a member of either of those
> lists and honestly I really don't want to join any more lists.  If
> there's nobody that knows java here who can answer basic questions
> then we have a rather significant disconnect, I'd think.

Java packaging is full of not-basic stuff, and active java packagers
that know the latest quirks typically do not have the time to follow
fedora-devel. You'll only find former packagers like Ville and me there.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/49d400b8/attachment.sig>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From skvidal at fedoraproject.org  Thu Nov 22 18:15:10 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 22 Nov 2007 13:15:10 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <20071122141340.GA2857@wolff.to>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<4744B768.301@mindspring.com>  <20071122141340.GA2857@wolff.to>
Message-ID: <1195755310.24466.4.camel@cutter>


On Thu, 2007-11-22 at 08:13 -0600, Bruno Wolff III wrote:
> On Wed, Nov 21, 2007 at 17:55:36 -0500,
>   Richard Hally <rhally at mindspring.com> wrote:
> 
> > Bruno, It looks like there is a problem with your mailer. I have received 9 
> > copies of this message!
> > There is also one with 2:15pm time that I have received 6 times. All the 
> > other messages from other people are ok.
> 
> I am not sure why this happened. I did find about a 1/2 dozen messages
> queued for redhat and removed them from the queue and restarted the
> MTA.

It's still happening. I've gotten this message 5 times so far.

-sv




From frank-buettner at gmx.net  Thu Nov 22 18:35:26 2007
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Thu, 22 Nov 2007 19:35:26 +0100
Subject: amavisd-new/clamav and EPEL
Message-ID: <4745CBEE.80908@gmx.net>

Hello,

can the amavisd-new and clamav package build for EPEL??
This is really missing.

Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/b415f749/attachment.bin>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From myfedora at richip.dhs.org  Thu Nov 22 20:35:22 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 22 Nov 2007 13:35:22 -0700
Subject: libglade2 Problem: Can't Find Symbols
Message-ID: <1195763722.22396.7.camel@localhost6.localdomain6>

Hi,

This isn't strictly speaking a fedora-devel subject, but I'm hoping a
fellow packager or Fedora programming gurus can help.

I'm trying to package GPass 0.5.1 for Fedora. The package I have builds
fine on both Fedora 7 and F8, but on F8, I keep getting libglade
warnings like:

(gpass:23491): libglade-WARNING **: could not find signal handler
'gpass_authentication_on_response'.

It seems libglade can't find the signal handler functions in F8.

On F7, I have:

libglade2-2.6.0-3.fc7
binutils-2.17.50.0.12-4.x86_64
gcc-4.1.2-27.fc7.x86_64

On F8, I have:

libglade2-2.6.2-3.fc8.x86_64
binutils-2.17.50.0.18-1.x86_64
gcc-4.1.2-33.x86_64

Upstream's website is unresponsive right now.

Any ideas?
--

Richi Plana



From peter at thecodergeek.com  Thu Nov 22 21:04:26 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 22 Nov 2007 13:04:26 -0800
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <1195755310.24466.4.camel@cutter>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to>
	<4744B768.301@mindspring.com>  <20071122141340.GA2857@wolff.to>
	<1195755310.24466.4.camel@cutter>
Message-ID: <1195765466.4166.5.camel@tuxhugs>

On Thu, 2007-11-22 at 13:15 -0500, seth vidal wrote:
> It's still happening. I've gotten this message 5 times so far.

Confirmed here, too. I've been getting anywhere from 5 to 9 copies of
every message Bruno sends to the lists.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/64ce7ee8/attachment.sig>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From mclasen at redhat.com  Thu Nov 22 21:45:28 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 22 Nov 2007 16:45:28 -0500
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195763722.22396.7.camel@localhost6.localdomain6>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
Message-ID: <1195767928.12987.1.camel@localhost.localdomain>


On Thu, 2007-11-22 at 13:35 -0700, Richi Plana wrote:
> Hi,
> 
> This isn't strictly speaking a fedora-devel subject, but I'm hoping a
> fellow packager or Fedora programming gurus can help.
> 

You are probably missing -Wl,--export-dynamic when compiling your app.



From seg at haxxed.com  Thu Nov 22 23:00:47 2007
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 22 Nov 2007 17:00:47 -0600
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
Message-ID: <1195772447.14235.0.camel@localhost>


On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> To put it shortly, I going to switch the default rpm queryformat to 
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or 
> so.

Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/6af94501/attachment.sig>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From bnocera at redhat.com  Fri Nov 23 00:07:53 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 23 Nov 2007 00:07:53 +0000
Subject: amavisd-new/clamav and EPEL
In-Reply-To: <4745CBEE.80908@gmx.net>
References: <4745CBEE.80908@gmx.net>
Message-ID: <1195776473.10878.404.camel@cookie.hadess.net>


On Thu, 2007-11-22 at 19:35 +0100, Frank B?ttner wrote:
> Hello,
> 
> can the amavisd-new and clamav package build for EPEL??
> This is really missing.

Filing bugs is the way to ask for those, depending on the good-will of
the maintainers. I'm sure they'd be happy to let someone maintain those
branches though.



From bnocera at redhat.com  Fri Nov 23 00:13:32 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 23 Nov 2007 00:13:32 +0000
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <385453.83318.qm@web52410.mail.re2.yahoo.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
Message-ID: <1195776812.10878.411.camel@cookie.hadess.net>


On Wed, 2007-11-21 at 19:29 -0800, Otto Rey wrote:
> Fedora should have a good support of TV cards. I have a LifeView
> FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV
> working. I try almost everything (i am developer).
> For home users, Fedora 9 TV support should by something like this:
> "Install this crappy package and you are zapping" :D

The problem is two-fold:
- kernel drivers
- user-land support

For kernel drivers, not much that can be done, other than hoping that
somebody writes the driver for a specific type of card (unless you want
to write the driver yourself). For a number of cards, you'll need a
firmware. Anybody interested in driving that? Could people involved in
helping get the wireless firmwares give some guidance?

As for user-space, realistically, we'd only be able to support analog
tuners. Most digital tuners use MPEG-2 or MPEG-4, and we can't ship
decoders for those codecs in Fedora...

Anyway, I'm pretty sure your problem is with the kernel driver, and not
knowing what the problems are severely limit our ability to help.

Cheers



From kevin at scrye.com  Fri Nov 23 00:17:31 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Thu, 22 Nov 2007 17:17:31 -0700
Subject: amavisd-new/clamav and EPEL
In-Reply-To: <1195776473.10878.404.camel@cookie.hadess.net>
References: <4745CBEE.80908@gmx.net>
	<1195776473.10878.404.camel@cookie.hadess.net>
Message-ID: <20071122171731.02475ac8@ghistelwchlohm.scrye.com>

On Fri, 23 Nov 2007 00:07:53 +0000
bnocera at redhat.com (Bastien Nocera) wrote:

> 
> On Thu, 2007-11-22 at 19:35 +0100, Frank B?ttner wrote:
> > Hello,
> > 
> > can the amavisd-new and clamav package build for EPEL??
> > This is really missing.
> 
> Filing bugs is the way to ask for those, depending on the good-will of
> the maintainers. I'm sure they'd be happy to let someone maintain
> those branches though.

Not sure on amavisd-new, but I just filed a review request for a clamav
version for EPEL: 

https://bugzilla.redhat.com/show_bug.cgi?id=396171

I'd like to get this reviewed and epel updated. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/3502a48c/attachment.sig>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From myfedora at richip.dhs.org  Fri Nov 23 03:15:55 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 22 Nov 2007 20:15:55 -0700
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195767928.12987.1.camel@localhost.localdomain>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
Message-ID: <1195787755.23238.11.camel@localhost6.localdomain6>

On Thu, 2007-11-22 at 16:45 -0500, Matthias Clasen wrote:
> On Thu, 2007-11-22 at 13:35 -0700, Richi Plana wrote:
> > Hi,
> > 
> > This isn't strictly speaking a fedora-devel subject, but I'm hoping a
> > fellow packager or Fedora programming gurus can help.

> You are probably missing -Wl,--export-dynamic when compiling your app.

In that case, I've a bit of a problem here and I'm not sure what the
right solution is (or which module to file a bug report against if it is
a bug).

Apparently, the pkg-config file for libglade2 (libglade-2.0.pc) doesn't
include compiler-to-linker options to export symbols
(-Wl,--export-dynamic). In fact, most applications which rely on
libglade2 have been using other means of getting those symbols in. (in
F7, it was through gmodule-2.0.pc (which got pulled in because the app
uses libgnomeui-2.0.pc -> libgnome-2.0.pc -> libbonobo-2.0.pc).
Unfortunately in F8, libgnomeui-2.0.pc eventually ends up pulling
gmodule-no-export-2.0.pc, which, as the name implies, doesn't do symbol
exporting.

Either other app developers are adding additional libraries that they
know needs to be added for libglade2 ... or everyone's just been plain
lucky so far.

As much as it feels to me like libglade-2.0.pc should have the export
options (since apps using libglade2 almost always need it), I'm no
expert and would defer to the community who's done more Gnome2
programming than I.

Thoughts?
--

Richi Plana



From mclasen at redhat.com  Fri Nov 23 03:25:37 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 22 Nov 2007 22:25:37 -0500
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195787755.23238.11.camel@localhost6.localdomain6>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
Message-ID: <1195788337.23526.2.camel@localhost.localdomain>


On Thu, 2007-11-22 at 20:15 -0700, Richi Plana wrote:
> On Thu, 2007-11-22 at 16:45 -0500, Matthias Clasen wrote:
> > On Thu, 2007-11-22 at 13:35 -0700, Richi Plana wrote:
> > > Hi,
> > > 
> > > This isn't strictly speaking a fedora-devel subject, but I'm hoping a
> > > fellow packager or Fedora programming gurus can help.
> 
> > You are probably missing -Wl,--export-dynamic when compiling your app.
> 
> In that case, I've a bit of a problem here and I'm not sure what the
> right solution is (or which module to file a bug report against if it is
> a bug).
> 
> Apparently, the pkg-config file for libglade2 (libglade-2.0.pc) doesn't
> include compiler-to-linker options to export symbols
> (-Wl,--export-dynamic). In fact, most applications which rely on
> libglade2 have been using other means of getting those symbols in. (in
> F7, it was through gmodule-2.0.pc (which got pulled in because the app
> uses libgnomeui-2.0.pc -> libgnome-2.0.pc -> libbonobo-2.0.pc).
> Unfortunately in F8, libgnomeui-2.0.pc eventually ends up pulling
> gmodule-no-export-2.0.pc, which, as the name implies, doesn't do symbol
> exporting.
> 
> Either other app developers are adding additional libraries that they
> know needs to be added for libglade2 ... or everyone's just been plain
> lucky so far.
> 
> As much as it feels to me like libglade-2.0.pc should have the export
> options (since apps using libglade2 almost always need it), I'm no
> expert and would defer to the community who's done more Gnome2
> programming than I.

The --export-dynamic is only needed if the libglade-using application
making use of the signal-autoconnection feature. I have no statistics
about this, but I've seen a fair number of glade files which don't use
it. The easiest way out is to add gmodule-export-2.0 to the list of
requires pkg-config modules for your application.



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From myfedora at richip.dhs.org  Fri Nov 23 03:49:43 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 22 Nov 2007 20:49:43 -0700
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195788337.23526.2.camel@localhost.localdomain>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
Message-ID: <1195789783.23238.14.camel@localhost6.localdomain6>

On Thu, 2007-11-22 at 22:25 -0500, Matthias Clasen wrote:
> On Thu, 2007-11-22 at 20:15 -0700, Richi Plana wrote:
> > On Thu, 2007-11-22 at 16:45 -0500, Matthias Clasen wrote:
> > > On Thu, 2007-11-22 at 13:35 -0700, Richi Plana wrote:
> > > > Hi,
> > > > 
> > > > This isn't strictly speaking a fedora-devel subject, but I'm hoping a
> > > > fellow packager or Fedora programming gurus can help.
> > 
> > > You are probably missing -Wl,--export-dynamic when compiling your app.
> > 
> > In that case, I've a bit of a problem here and I'm not sure what the
> > right solution is (or which module to file a bug report against if it is
> > a bug).
> > 
> > Apparently, the pkg-config file for libglade2 (libglade-2.0.pc) doesn't
> > include compiler-to-linker options to export symbols
> > (-Wl,--export-dynamic). In fact, most applications which rely on
> > libglade2 have been using other means of getting those symbols in. (in
> > F7, it was through gmodule-2.0.pc (which got pulled in because the app
> > uses libgnomeui-2.0.pc -> libgnome-2.0.pc -> libbonobo-2.0.pc).
> > Unfortunately in F8, libgnomeui-2.0.pc eventually ends up pulling
> > gmodule-no-export-2.0.pc, which, as the name implies, doesn't do symbol
> > exporting.
> > 
> > Either other app developers are adding additional libraries that they
> > know needs to be added for libglade2 ... or everyone's just been plain
> > lucky so far.
> > 
> > As much as it feels to me like libglade-2.0.pc should have the export
> > options (since apps using libglade2 almost always need it), I'm no
> > expert and would defer to the community who's done more Gnome2
> > programming than I.
> 
> The --export-dynamic is only needed if the libglade-using application
> making use of the signal-autoconnection feature. I have no statistics
> about this, but I've seen a fair number of glade files which don't use
> it. The easiest way out is to add gmodule-export-2.0 to the list of
> requires pkg-config modules for your application.

Thanks. Almost done. How would that requirement best be put in a
package? As far as I can tell, the package uses autotools.
--

Richi Plana



From mclasen at redhat.com  Fri Nov 23 05:29:24 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 23 Nov 2007 00:29:24 -0500
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195789783.23238.14.camel@localhost6.localdomain6>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
Message-ID: <1195795764.23526.5.camel@localhost.localdomain>


On Thu, 2007-11-22 at 20:49 -0700, Richi Plana wrote:

> Thanks. Almost done. How would that requirement best be put in a
> package? As far as I can tell, the package uses autotools.

I would patch configure.in and run autoreconf. 
Some people hate that and want you to carry a patch against 
configure instead. 





From rc040203 at freenet.de  Fri Nov 23 05:37:38 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 23 Nov 2007 06:37:38 +0100
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195795764.23526.5.camel@localhost.localdomain>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
Message-ID: <1195796258.12310.20.camel@mccallum.corsepiu.local>


On Fri, 2007-11-23 at 00:29 -0500, Matthias Clasen wrote:
> On Thu, 2007-11-22 at 20:49 -0700, Richi Plana wrote:
> 
> > Thanks. Almost done. How would that requirement best be put in a
> > package? As far as I can tell, the package uses autotools.
> 
> I would patch configure.in and run autoreconf. 
> Some people hate that and want you to carry a patch against 
> configure instead. 
Yes, because running the autotools during a built makes the built
non-deterministic.

Ralf




From mclasen at redhat.com  Fri Nov 23 05:45:21 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 23 Nov 2007 00:45:21 -0500
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195796258.12310.20.camel@mccallum.corsepiu.local>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
	<1195796258.12310.20.camel@mccallum.corsepiu.local>
Message-ID: <1195796721.23526.8.camel@localhost.localdomain>


On Fri, 2007-11-23 at 06:37 +0100, Ralf Corsepius wrote:
> On Fri, 2007-11-23 at 00:29 -0500, Matthias Clasen wrote:
> > On Thu, 2007-11-22 at 20:49 -0700, Richi Plana wrote:
> > 
> > > Thanks. Almost done. How would that requirement best be put in a
> > > package? As far as I can tell, the package uses autotools.
> > 
> > I would patch configure.in and run autoreconf. 
> > Some people hate that and want you to carry a patch against 
> > configure instead. 
> Yes, because running the autotools during a built makes the built
> non-deterministic.

That is about as true as saying that using the shell during the build 
makes the build non-deterministic.



From rc040203 at freenet.de  Fri Nov 23 05:54:45 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 23 Nov 2007 06:54:45 +0100
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195796721.23526.8.camel@localhost.localdomain>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
	<1195796258.12310.20.camel@mccallum.corsepiu.local>
	<1195796721.23526.8.camel@localhost.localdomain>
Message-ID: <1195797285.12310.22.camel@mccallum.corsepiu.local>


On Fri, 2007-11-23 at 00:45 -0500, Matthias Clasen wrote:
> On Fri, 2007-11-23 at 06:37 +0100, Ralf Corsepius wrote:
> > On Fri, 2007-11-23 at 00:29 -0500, Matthias Clasen wrote:
> > > On Thu, 2007-11-22 at 20:49 -0700, Richi Plana wrote:
> > > 
> > > > Thanks. Almost done. How would that requirement best be put in a
> > > > package? As far as I can tell, the package uses autotools.
> > > 
> > > I would patch configure.in and run autoreconf. 
> > > Some people hate that and want you to carry a patch against 
> > > configure instead. 
> > Yes, because running the autotools during a built makes the built
> > non-deterministic.
> 
> That is about as true as saying that using the shell during the build 
> makes the build non-deterministic.
Rubbish - Running the autotools modifies a package's source code.

Ralf




From peter at thecodergeek.com  Fri Nov 23 06:03:55 2007
From: peter at thecodergeek.com (Peter Gordon)
Date: Thu, 22 Nov 2007 22:03:55 -0800
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195797285.12310.22.camel@mccallum.corsepiu.local>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
	<1195796258.12310.20.camel@mccallum.corsepiu.local>
	<1195796721.23526.8.camel@localhost.localdomain>
	<1195797285.12310.22.camel@mccallum.corsepiu.local>
Message-ID: <1195797835.2113.1.camel@tuxhugs>

On Fri, 2007-11-23 at 06:54 +0100, Ralf Corsepius wrote:
> Rubbish - Running the autotools modifies a package's source code.

Incorrect. Invoking autotools modifies the package's build scripts, not
source code. There is a significant difference.
-- 
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
  DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071122/65f1f7ae/attachment.sig>

From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From rc040203 at freenet.de  Fri Nov 23 06:22:34 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 23 Nov 2007 07:22:34 +0100
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <1195797835.2113.1.camel@tuxhugs>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
	<1195796258.12310.20.camel@mccallum.corsepiu.local>
	<1195796721.23526.8.camel@localhost.localdomain>
	<1195797285.12310.22.camel@mccallum.corsepiu.local>
	<1195797835.2113.1.camel@tuxhugs>
Message-ID: <1195798954.12310.30.camel@mccallum.corsepiu.local>


On Thu, 2007-11-22 at 22:03 -0800, Peter Gordon wrote:
> On Fri, 2007-11-23 at 06:54 +0100, Ralf Corsepius wrote:
> > Rubbish - Running the autotools modifies a package's source code.
> 
> Incorrect. Invoking autotools modifies the package's build scripts, not
> source code. There is a significant difference.

With all due respect, you could not be much wronger.

auto* generated files are not supposed to be dynamically modified nor
are they designed to be dynamically modified.

That's the reason why they are part of source tarballs.

>From a practical aspect: 

Running incompatibles version of the  autotools during builds can break
a package. 

Esp. GNOME and GTK packages are famous suffer from such defects, because
many of do not comply to modern auto* tool's standards.


Ralf




From mauricio at projetofedora.org  Fri Nov 23 06:54:45 2007
From: mauricio at projetofedora.org (Mauricio Pretto)
Date: Fri, 23 Nov 2007 07:54:45 +0100
Subject: Contacts to FSF to resolve license issue!?
In-Reply-To: <47454FF2.3060304@linux-kernel.at>
References: <4730C4C9.2090707@linux-kernel.at>
	<47454FF2.3060304@linux-kernel.at>
Message-ID: <47467935.9050105@projetofedora.org>

Oliver Falk wrote:
> ping!
> 
> On 11/06/2007 08:47 PM, Oliver Falk wrote:
>> Hi!
>>
>> A few days ago, I stumbled across the freshmeat announcement of
>> nodemon/growler [0]. Both are NASA projects under NOSA 1.3 license.
>> While in the first moment I thought, NOSA is free, FSF page list this
>> license (at least in version 1.3) as non-free. After reading the
>> description, I was clear for me why it is non-free. [1]
>>
>> However, I contacted Mr. Bryan Green (author of nodemon/growler) and
>> asked him if there's a chance to release the software under a *really
>> free* license or if there's a chance to get a new version of NOSA (eg
>> 1.4), that actually is FSF compliant and therefor software can be
>> included into Fedora.
>>
>> But it seems, NASA already tried to get in touch with FSF to solve the
>> issue, but FSF wasn't very cooperative (no offense!).
>>
>> I'd be glad, if someone has good contacts to FSF and we can bring
>> together NASA and FSF, to solve that issue. Not only for nodemon/growler
>>  to make it into Fedora, but also to make the world just another bit
>> *more* free! I know of some people, who'll be smiling about this
>> sentence... :-) Don't you?
>>
>> -of
>>
>> [0] http://people.nas.nasa.gov/~bgreen/nodemon/
>>     http://people.nas.nasa.gov/~bgreen/growler/
>> [1] http://www.fsf.org/licensing/licenses/; Search for NASA.
>>
> 
> 
Hi Oliver,
    Can you check the website http://www.fsfe.org/
    I'm friend of Georg he is the founder of fsf europe, very friendly
guy, i think he may be able to help us.
    If you can't get in touch with him, let me know and i will go
directly to him, ok?

Regards

-- 
Pretto
http://fedoraproject.org/wiki/MauricioPretto



From tgl at redhat.com  Fri Nov 23 06:55:20 2007
From: tgl at redhat.com (Tom Lane)
Date: Fri, 23 Nov 2007 01:55:20 -0500
Subject: libglade2 Problem: Can't Find Symbols 
In-Reply-To: <1195798954.12310.30.camel@mccallum.corsepiu.local> 
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
	<1195796258.12310.20.camel@mccallum.corsepiu.local>
	<1195796721.23526.8.camel@localhost.localdomain>
	<1195797285.12310.22.camel@mccallum.corsepiu.local>
	<1195797835.2113.1.camel@tuxhugs>
	<1195798954.12310.30.camel@mccallum.corsepiu.local>
Message-ID: <23381.1195800920@sss.pgh.pa.us>

Ralf Corsepius <rc040203 at freenet.de> writes:
> On Thu, 2007-11-22 at 22:03 -0800, Peter Gordon wrote:
>> Incorrect. Invoking autotools modifies the package's build scripts, not
>> source code. There is a significant difference.

> With all due respect, you could not be much wronger.

> auto* generated files are not supposed to be dynamically modified nor
> are they designed to be dynamically modified.
> That's the reason why they are part of source tarballs.

No, the reason why they are part of source tarballs is that
traditionally tarball-makers haven't wanted to assume that users will
have autotools installed.

> From a practical aspect: 
> Running incompatibles version of the  autotools during builds can break
> a package. 

Certainly true.  On the other hand, *not* rebuilding the scripts can
also break a package, particularly with respect to libtool, IME.

It's a case-by-case issue, and so I see any sort of generalized
opinionating about it as fundamentally misguided.  I do a forced
automake/libtoolize/autoconf for some of my packages, and not others.

			regards, tom lane



From ville.skytta at iki.fi  Fri Nov 23 07:24:20 2007
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Fri, 23 Nov 2007 09:24:20 +0200
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <1195776812.10878.411.camel@cookie.hadess.net>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1195776812.10878.411.camel@cookie.hadess.net>
Message-ID: <200711230924.20520.ville.skytta@iki.fi>

On Friday 23 November 2007, Bastien Nocera wrote:

> As for user-space, realistically, we'd only be able to support analog
> tuners. Most digital tuners use MPEG-2 or MPEG-4, and we can't ship
> decoders for those codecs in Fedora...

Some of those cards have hardware MPEG decoders and require no software MPEG 
support.



From lsof at nodata.co.uk  Fri Nov 23 07:28:34 2007
From: lsof at nodata.co.uk (nodata)
Date: Fri, 23 Nov 2007 08:28:34 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1195772447.14235.0.camel@localhost>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
Message-ID: <1195802914.2831.7.camel@sb-home>


Am Donnerstag, den 22.11.2007, 17:00 -0600 schrieb Callum Lerwick:
> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> > To put it shortly, I going to switch the default rpm queryformat to 
> > include package architecture (ie what you get now with
> > rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or 
> > so.
> 
> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

That would encourage the use of epochs.



From dwmw2 at infradead.org  Fri Nov 23 08:27:06 2007
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 23 Nov 2007 08:27:06 +0000
Subject: Mono on ppc and ppc64`1
In-Reply-To: <1195602414.5092.19.camel@T7.Linux>
References: <1195602414.5092.19.camel@T7.Linux>
Message-ID: <1195806426.25590.21.camel@pmac.infradead.org>


On Tue, 2007-11-20 at 23:46 +0000, Paul wrote:
> Does anyone have a list of problems why mono fails to build on these
> platforms? I've a number of packages which fail because of mono
> problems on the architecture.

See the FE-ExcludeArch-ppc{,64} trackers:

https://bugzilla.redhat.com/showdependencytree.cgi?hide_resolved=1&id=FE-ExcludeArch-ppc
https://bugzilla.redhat.com/showdependencytree.cgi?hide_resolved=1&id=FE-ExcludeArch-ppc64

Because we use mostly 32-bit userspace on PPC64 hardware, the 64-bit one
is a relatively low priority. We keep the 32-bit tracker fairly much
empty though.

Please could you give the bug numbers for the problems you're seeing?

-- 
dwmw2



From nphilipp at redhat.com  Fri Nov 23 08:59:28 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 23 Nov 2007 09:59:28 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1195802914.2831.7.camel@sb-home>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost> <1195802914.2831.7.camel@sb-home>
Message-ID: <1195808368.27429.15.camel@wombat.tiptoe.de>


On Fri, 2007-11-23 at 08:28 +0100, nodata wrote:
> Am Donnerstag, den 22.11.2007, 17:00 -0600 schrieb Callum Lerwick:
> > On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> > > To put it shortly, I going to switch the default rpm queryformat to 
> > > include package architecture (ie what you get now with
> > > rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or 
> > > so.
> > 
> > Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> That would encourage the use of epochs.

I don't think so -- "Look, this package has an epoch, I'll add that to
my package too"? Hardly. If I'm interested in the version of a package,
I'm interested in the epoch, too, if there's one. IMO, the only reason
against listing the epoch here is that RPM itself doesn't understand it
when specifying packages:

nils at wombat:~> rpm -q gimp-2:2.4.1-1.fc8.x86_64
package gimp-2:2.4.1-1.fc8.x86_64 is not installed
nils at wombat:~> rpm -q gimp-2.4.1-1.fc8.x86_64
gimp-2.4.1-1.fc8

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From bruno at wolff.to  Thu Nov 22 14:13:40 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 22 Nov 2007 08:13:40 -0600
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <4744B768.301@mindspring.com>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<20071121151510.GA21330@wolff.to> <4744B768.301@mindspring.com>
Message-ID: <20071122141340.GA2857@wolff.to>

On Wed, Nov 21, 2007 at 17:55:36 -0500,
  Richard Hally <rhally at mindspring.com> wrote:

> Bruno, It looks like there is a problem with your mailer. I have received 9 
> copies of this message!
> There is also one with 2:15pm time that I have received 6 times. All the 
> other messages from other people are ok.

I am not sure why this happened. I did find about a 1/2 dozen messages
queued for redhat and removed them from the queue and restarted the
MTA.



From jsafrane at redhat.com  Fri Nov 23 09:16:41 2007
From: jsafrane at redhat.com (Jan Safranek)
Date: Fri, 23 Nov 2007 10:16:41 +0100
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <4745AB42.8050206@redhat.com>
References: <4745A750.4080904@redhat.com> <4745AB42.8050206@redhat.com>
Message-ID: <47469A79.1000607@redhat.com>

Warren Togami wrote:
> If most apps build fine against the new openldap, please do not provide 
> a compat-openldap package.  If there is huge API breakage then we need 
> to discuss the possibility of a compat-* package.

The old compat- package providing 2.2.x libraries survived from FC5 to 
F8, I just wanted to continue with the tradition :). I will remove it 
when everything works with openldap-2.4.

> http://fedoraproject.org/wiki/Releases/9/Schedule
> You are being far too cautious about breaking things in rawhide, 
> especially this far before the Alpha1 development freeze.
 >
> Please build yourself the new openldap locally in mock, and test for 
> yourself whether every package rebuilds cleanly against the new version 
> within mock.

Compilation of big desktop things like kdebase and evolution is 
something I want to avoid on my machine, even in mock. That's why I 
asked appropriate maintainers to do so. Unfortunately koji does not 
provide chain-build with --scratch option :(.

> If the dependent package rebuild testing shows few problems, go ahead 
> with upgrading the version even before December.  The sooner during this 
> rawhide cycle the better, to stabilize before Alpha1.

Of course, I will release it as soon as I am sure I do not seriously 
break anything.

Jan



From nicolas.mailhot at laposte.net  Fri Nov 23 09:32:17 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 23 Nov 2007 10:32:17 +0100 (CET)
Subject: Heads up: openldap rebase for Fedora/devel
Message-ID: <32140.192.54.193.53.1195810337.squirrel@rousalka.dyndns.org>


Le Ven 23 novembre 2007 10:16, Jan Safranek a ?crit :
> Warren Togami wrote:
>> If most apps build fine against the new openldap, please do not
>> provide
>> a compat-openldap package.  If there is huge API breakage then we
>> need
>> to discuss the possibility of a compat-* package.
>
> The old compat- package providing 2.2.x libraries survived from FC5 to
> F8, I just wanted to continue with the tradition :).

Just shows compat packages need an explicit EOL date or we'll carry
them forever (some upstreams won't even look at the new version while
the compat package is available)

-- 
Nicolas Mailhot



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov 23 09:34:45 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 23 Nov 2007 10:34:45 +0100
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <4745A750.4080904@redhat.com>
References: <4745A750.4080904@redhat.com>
Message-ID: <20071123103445.fcb00ed9.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 22 Nov 2007 16:59:12 +0100, Jan Safranek wrote:

> Appendix: list of packages, depending on openldap:
> am-utils
> anjuta
> apr-util
> compat-openldap
> cyrus-sasl-ldap
> dbmail
> dbmail-auth-ldap
> evolution
> evolution-connector
> GConf2
> kdebase
> kdepimlibs
> kdesvn
> krb5-server-ldap
> libapreq2
> libsmbclient
> libuser
> mod_authz_ldap
> mod_revocator
> nfs-utils-lib
> nss_ldap
> opal
> openpbx
> postfix
> pwlib
> python-ldap
> samba-common
> seahorse
> sendmail
> subversion
> wine-ldap

This list is very incomplete.  How did you create it?



From jsafrane at redhat.com  Fri Nov 23 09:52:30 2007
From: jsafrane at redhat.com (Jan Safranek)
Date: Fri, 23 Nov 2007 10:52:30 +0100
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <20071123103445.fcb00ed9.mschwendt.tmp0701.nospam@arcor.de>
References: <4745A750.4080904@redhat.com>
	<20071123103445.fcb00ed9.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <4746A2DE.6050904@redhat.com>

Michael Schwendt wrote:
> On Thu, 22 Nov 2007 16:59:12 +0100, Jan Safranek wrote:
> 
>> Appendix: list of packages, depending on openldap:
> 
> This list is very incomplete.  How did you create it?

(
   repoquery --whatrequires openldap;
   repoquery --whatrequires libldap_r-2.3.so.0;
   repoquery --whatrequires libldap-2.3.so.0;
   repoquery --whatrequires liblber-2.3.so.0
) | sed 's/-[0-9].*//' | sort | uniq

Now I see I created it on Fedora 7 instead rawhide, sorry. Does 
following list sound better?

alpine
am-utils
anjuta
apr-util
autofs
bind-sdb
callweaver
callweaver-alsa
callweaver-bluetooth
callweaver-capi
callweaver-jabber
callweaver-javascript
callweaver-ldap
callweaver-misdn
callweaver-mysql
callweaver-odbc
callweaver-ogi
callweaver-postgresql
callweaver-zaptel
claws-mail
compat-openldap
cups
cyrus-imapd
cyrus-sasl
cyrus-sasl-ldap
dbmail
dbmail-auth-ldap
dbmail-mysql
dbmail-pgsql
dhcp
dirmngr
dovecot
evolution
evolution-exchange
exim
freeradius
GConf2
gnupg
gnupg2
gq
httpd
httpd-tools
jabberd
kdebase
kdepimlibs
kdesvn
krb5-server-ldap
ldapvi
libacl-devel
libapreq2
libgda-ldap
libsmbclient
libuser
lighttpd
mod_authz_ldap
mod_perl
mod_revocator
nagios-plugins-ldap
nfs-utils
nfs-utils-lib
nss_ldap
opal
openldap
openldap-clients
openldap-debuginfo
openldap-devel
openldap-servers
pdns-backend-ldap
php-ldap
postfix
proftpd-ldap
pure-ftpd
pwlib
python-ldap
rapidsvn
ruby-ldap
samba
samba-client
samba-common
samba-swat
seahorse
sendmail
squid
squidGuard
ss5
subcommander
subversion
sudo
sylpheed
wine-ldap
zabbix
zabbix-agent



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov 23 10:02:48 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 23 Nov 2007 11:02:48 +0100
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <4746A2DE.6050904@redhat.com>
References: <4745A750.4080904@redhat.com>
	<20071123103445.fcb00ed9.mschwendt.tmp0701.nospam@arcor.de>
	<4746A2DE.6050904@redhat.com>
Message-ID: <20071123110248.7f9207d0.mschwendt.tmp0701.nospam@arcor.de>

On Fri, 23 Nov 2007 10:52:30 +0100, Jan Safranek wrote:

> Michael Schwendt wrote:
> > On Thu, 22 Nov 2007 16:59:12 +0100, Jan Safranek wrote:
> > 
> >> Appendix: list of packages, depending on openldap:
> > 
> > This list is very incomplete.  How did you create it?
> 
> (
>    repoquery --whatrequires openldap;
>    repoquery --whatrequires libldap_r-2.3.so.0;
>    repoquery --whatrequires libldap-2.3.so.0;
>    repoquery --whatrequires liblber-2.3.so.0
> ) | sed 's/-[0-9].*//' | sort | uniq
> 
> Now I see I created it on Fedora 7 instead rawhide, sorry.

Whether F7, F8 or rawhide, shouldn't matter. The differences
aren't that huge. Even the sonames are the same on F7.

> Does following list sound better?

Yes, thrice as long and looks much more plausible.



From sb at monkey-mind.net  Fri Nov 23 10:04:24 2007
From: sb at monkey-mind.net (Steven Bakker)
Date: Fri, 23 Nov 2007 11:04:24 +0100
Subject: AWOL: jpo
In-Reply-To: <1195584085.2465.8.camel@localhost6.localdomain6>
References: <851272.31889.qm@web60523.mail.yahoo.com>
	<1195584085.2465.8.camel@localhost6.localdomain6>
Message-ID: <20071123110424.7bf53019@cluestix.noc.ams-ix.net>

On Tue, 20 Nov 2007 11:41:25 -0700 Richi Plana wrote:

> As much as I love Perl and I prefer it over all existing scripting
> languages I'm familiar with, it's hard to get excited about its future
> since the developers are extremely quiet about it.

They're probably quiet about it because they prefer coding over talking :-)

Perl 5.10-RC1 has been unleashed recently[1], full of nice new
features[2], borrowing some from (the still-vaporware) Perl6 (named
capture buffers!).

[1] http://search.cpan.org/~rgarcia/perl-5.10.0-RC1/
[2] http://www.slideshare.net/rjbs/perl-510-for-people-who-arent-totally-insane

-- Steven



From rc040203 at freenet.de  Fri Nov 23 07:39:33 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 23 Nov 2007 08:39:33 +0100
Subject: libglade2 Problem: Can't Find Symbols
In-Reply-To: <23381.1195800920@sss.pgh.pa.us>
References: <1195763722.22396.7.camel@localhost6.localdomain6>
	<1195767928.12987.1.camel@localhost.localdomain>
	<1195787755.23238.11.camel@localhost6.localdomain6>
	<1195788337.23526.2.camel@localhost.localdomain>
	<1195789783.23238.14.camel@localhost6.localdomain6>
	<1195795764.23526.5.camel@localhost.localdomain>
	<1195796258.12310.20.camel@mccallum.corsepiu.local>
	<1195796721.23526.8.camel@localhost.localdomain>
	<1195797285.12310.22.camel@mccallum.corsepiu.local>
	<1195797835.2113.1.camel@tuxhugs>
	<1195798954.12310.30.camel@mccallum.corsepiu.local>
	<23381.1195800920@sss.pgh.pa.us>
Message-ID: <1195803573.12310.42.camel@mccallum.corsepiu.local>


On Fri, 2007-11-23 at 01:55 -0500, Tom Lane wrote:
> Ralf Corsepius <rc040203 at freenet.de> writes:
> > On Thu, 2007-11-22 at 22:03 -0800, Peter Gordon wrote:
> >> Incorrect. Invoking autotools modifies the package's build scripts, not
> >> source code. There is a significant difference.
> 
> > With all due respect, you could not be much wronger.
> 
> > auto* generated files are not supposed to be dynamically modified nor
> > are they designed to be dynamically modified.
> > That's the reason why they are part of source tarballs.
> 
> No, the reason why they are part of source tarballs is that
> traditionally tarball-makers haven't wanted to assume that users will
> have autotools installed.

Right, that's one aspect. It's one aspect why they are treated as
generated SOURCES.

> > From a practical aspect: 
> > Running incompatibles version of the  autotools during builds can break
> > a package. 
> 
> Certainly true.  On the other hand, *not* rebuilding the scripts can
> also break a package, particularly with respect to libtool, IME.
Libtool is a special case, because RH ships a hacked libtool to work
around an issue (multilibs) upstream so far has not been able to fix.

> It's a case-by-case issue, and so I see any sort of generalized
> opinionating about it as fundamentally misguided. 
Wrong. Read the Fine Manual, read the GNU Coding Standards.

>  I do a forced
> automake/libtoolize/autoconf for some of my packages, and not others.
Your mistake. You are unnecessarily imposing risks to your packages.

Ralf






From bnocera at redhat.com  Fri Nov 23 10:56:10 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 23 Nov 2007 10:56:10 +0000
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <200711230924.20520.ville.skytta@iki.fi>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1195776812.10878.411.camel@cookie.hadess.net>
	<200711230924.20520.ville.skytta@iki.fi>
Message-ID: <1195815370.10878.420.camel@cookie.hadess.net>


On Fri, 2007-11-23 at 09:24 +0200, Ville Skytt? wrote:
> On Friday 23 November 2007, Bastien Nocera wrote:
> 
> > As for user-space, realistically, we'd only be able to support analog
> > tuners. Most digital tuners use MPEG-2 or MPEG-4, and we can't ship
> > decoders for those codecs in Fedora...
> 
> Some of those cards have hardware MPEG decoders and require no software MPEG 
> support.

Any examples? And which kernel sub-system might these cards be using?



From caillon at redhat.com  Fri Nov 23 11:08:53 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 23 Nov 2007 12:08:53 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1195808368.27429.15.camel@wombat.tiptoe.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>	<1195772447.14235.0.camel@localhost>
	<1195802914.2831.7.camel@sb-home>
	<1195808368.27429.15.camel@wombat.tiptoe.de>
Message-ID: <4746B4C5.5020509@redhat.com>

On 11/23/2007 09:59 AM, Nils Philippsen wrote:
> I don't think so -- "Look, this package has an epoch, I'll add that to
> my package too"? Hardly. 

We have cases of packagers doing that in the past.



From ngompa13 at gmail.com  Fri Nov 23 11:17:42 2007
From: ngompa13 at gmail.com (King InuYasha)
Date: Fri, 23 Nov 2007 05:17:42 -0600
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <1195815370.10878.420.camel@cookie.hadess.net>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1195776812.10878.411.camel@cookie.hadess.net>
	<200711230924.20520.ville.skytta@iki.fi>
	<1195815370.10878.420.camel@cookie.hadess.net>
Message-ID: <8278b1b0711230317p7e2fdb1ai20a027ad04de0f05@mail.gmail.com>

ATI Theater 200 apparently is one.

http://ati.amd.com/products/theater200/features.html



On Nov 23, 2007 4:56 AM, Bastien Nocera <bnocera at redhat.com> wrote:

>
> On Fri, 2007-11-23 at 09:24 +0200, Ville Skytt? wrote:
> > On Friday 23 November 2007, Bastien Nocera wrote:
> >
> > > As for user-space, realistically, we'd only be able to support analog
> > > tuners. Most digital tuners use MPEG-2 or MPEG-4, and we can't ship
> > > decoders for those codecs in Fedora...
> >
> > Some of those cards have hardware MPEG decoders and require no software
> MPEG
> > support.
>
> Any examples? And which kernel sub-system might these cards be using?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071123/2dc52583/attachment.htm>

From nicolas.mailhot at laposte.net  Fri Nov 23 12:06:46 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 23 Nov 2007 13:06:46 +0100 (CET)
Subject: Support TV on Fedora - Proposal for Fedora 9
Message-ID: <51992.192.54.193.53.1195819606.squirrel@rousalka.dyndns.org>


Le Ven 23 novembre 2007 11:56, Bastien Nocera a ?crit :
>
> On Fri, 2007-11-23 at 09:24 +0200, Ville Skytt? wrote:

>> Some of those cards have hardware MPEG decoders and require no
>> software MPEG
>> support.
>
> Any examples? And which kernel sub-system might these cards be using?

hauppauge pvr300 cards


-- 
Nicolas Mailhot



From Matt_Domsch at dell.com  Fri Nov 23 12:43:30 2007
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri, 23 Nov 2007 06:43:30 -0600
Subject: RFC: changing versioning of fedora-release in rawhide
In-Reply-To: <20071120232840.GN16195@humbolt.us.dell.com>
References: <20071120191125.GA1021@nostromo.devel.redhat.com>
	<20071120132853.274138ea@weaponx>
	<20071120193153.GA2221@nostromo.devel.redhat.com>
	<20071120134745.611a36c4@weaponx>
	<20071120195030.GA3431@nostromo.devel.redhat.com>
	<1195588508.4552.33.camel@localhost.localdomain>
	<20071120200133.GA3651@nostromo.devel.redhat.com>
	<1195589302.4552.40.camel@localhost.localdomain>
	<20071120201455.GB3651@nostromo.devel.redhat.com>
	<20071120232840.GN16195@humbolt.us.dell.com>
Message-ID: <20071123124330.GA27457@auslistsprd01.us.dell.com>

On Tue, Nov 20, 2007 at 05:28:40PM -0600, Michael E Brown wrote:
> On Tue, Nov 20, 2007 at 03:14:55PM -0500, Bill Nottingham wrote:
> > Jeremy Katz (katzj at redhat.com) said: 
> > > Realistically, you probably want the simple stupid plugin to allow you
> > > to set the release version if you go this route.  But at the same time,
> > > I don't think that the route of switching streams often is really a case
> > > that you optimize for.
> > 
> > Moreover, if you do the $releasever redirect hack, someone who has
> > updates/updates-testing either gets errors or the same repo three times.
> 
> Actually, I dont understand why we dont have a "repo=stable", and
> "repo=rawhide". Mirrormanager can be trivially extended to let you flip
> 'stable' repo to the next release a predefined amount of time after that
> release.
> 
> Then people who always want latest stable will automatically be upgraded
> to the next ver when it comes out, while people who want to stay on a specific
> release can say "repo=fedora-$releasever"

MM can already do this, however, the reason the YUM Upgrade SIG exists
is because upgrading from one stable release to the next automatially
isn't a trivial operation yet.  Let's give them a chance to develop a
painless automatic upgrade experience and we can enable this
functionality at that time.

> For rawhide, make releasever=9 and have mirrormanager redirect it to
> rawhide.
> 
> So, we have (defaults):
> 
> rpm name: fedora-release-9-1.prerelease.noarch.rpm
> fedora.repo:              repo=stable, enabled=0
> fedora-development.repo:  repo=rawhide, enabled=1
> 
> rpm name: fedora-release-9-1.noarch.rpm
> fedora.repo:              repo=stable, enabled=1
> fedora-development.repo:  repo=rawhide, enabled=0
> 
> People who want to track rawhide use --enablerepo. People who want to
> lock down to a specific release can s/stable/fedora-$releasever/. 
> 
> Or, alternatively, lock it down to a specific release by default, but
> let people change it to 'stable' if they want.

This is what I would expect.

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From buildsys at redhat.com  Fri Nov 23 12:52:17 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 23 Nov 2007 07:52:17 -0500
Subject: rawhide report: 20071123 changes
Message-ID: <200711231252.lANCqHQb032449@porkchop.devel.redhat.com>

New package libzip
	C library for reading, creating, and modifying zip archives

New package osmo
	Personal organizer

New package perl-Test-MinimumVersion
	Check whether your code requires a newer perl

New package swfdec-gnome
	Programs to integrate Flash into the GNOME desktop


 
Updated Packages:

PyQt4-4.3.1-3.fc9
-----------------
* Thu Nov 22 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.1-3
- dbus support (#395741)

amanda-2.5.2p1-9.fc9
--------------------
* Thu Nov 22 2007 Radek Brich <rbrich at redhat.com> 2.5.2.p1-9
- Change default amanda user name to 'amandabackup' (#124510).
  This should not break upgrades as config files are checked for
  old user name and updated.
- Add some explaining comments to .amandahosts (#153749)

audacious-plugins-1.4.1-3.fc9
-----------------------------
* Thu Nov 22 2007 Ralf Ertzinger <ralf at skytale.net> 1.4.1-3
- Fix some locking issues in the neon (HTTP/HTTPS stream) plugin

blam-1.8.3-11.fc9
-----------------
* Thu Nov 22 2007 Peter Gordon <peter at thecodergeek.com> - 1.8.3-11
- Fix CVE-2005-4790 (bug 252294).

busybox-1:1.8.1-1.fc9
---------------------
* Wed Nov 21 2007 Ivana Varekova <varekova at redhat.com> - 1:1.8.1-1
- update to 1.8.1

claws-mail-plugins-3.1.0-1.fc9
------------------------------
* Wed Nov 21 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 3.1.0-1
- version upgrade

devhelp-0.16.1-4.fc9
--------------------
* Thu Nov 22 2007 Martin Stransky <stransky at redhat.com> - 0.16.1-4.fc9
- Rebuild against xulrunner

docbook-utils-0.6.14-13.fc9
---------------------------
* Thu Nov 22 2007 Ondrej Vasik <ovasik at redhat.com> 0.6.14-13
- fix of w3m params while converting to txt

gimp-2:2.4.2-1.fc9
------------------
* Thu Nov 22 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.2-1
- version 2.4.2

  Changes in GIMP 2.4.2
  =====================

  - removed broken and useless HSV Graph script (bug #491311)
  - update the histogram when a color correction tool is cancelled (bug #493639)
  - fixed a crash with certain plug-in or script descriptions (bug #492718)
  - corrected a tooltip (bug #495564)
  - fixed a crash when GIMP is run without any modules (bug #495863)
  - fixed error handling in the TIFF plug-in
  - fixed a problem with Sample points
  - fixed a crash when merging layers in indexed image (bug #495990)
  - update the histogram when painting (bug #494049)
  - fixed another problem with merge operations on indexed images (bug #496437)
  - fixed crash in TIFF plug-in when saving indexed images (bug #497103)
  - changed defaults so that a system monitor profile is only used when the
    user explicitely enabled this feature (bug #496890)
  - fixed endless loop when running equalize on transparent areas (bug #497291)
  - fixed heap corruption in GimpColorScale widget that caused a crash in the
    Compose plug-in (bug #399484)
  - fixed use of background color in Particle Trace script (bug #498282)
  - set the image menu insensitive when there's no image opened (bug #498511)
  - translation updates (ca, et, it, lt, pt, pt_BR, sr, sv)

* Wed Oct 31 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.1-1
- version 2.4.1

  Changes in GIMP 2.4.1
  =====================

  - fixed a minor display rendering problem
  - improved the workaround for broken graphics card drivers (bug #421466)
  - fixed a crash with broken scripts and plug-ins (bug #490055)
  - fixed potential syntax error in configure script (bug #490068)
  - fixed parsing of floating point numbers in Script-Fu (bug #490198)
  - fixed potential crash when converting an indexed image to RGB (bug #490048)
  - update the histogram while doing color corrections (bug #490182)
  - fixed another crash with broken plug-ins (bug #490617).
  - translation updates

* Mon Oct 29 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-4
- use either htmlview or xdg-open in documentation instead of firefox (#355801)

gtkmozembedmm-1.4.2.cvs20060817-16.fc9
--------------------------------------
* Thu Nov 22 2007 Martin Stransky <stransky at redhat.com> - 1.4.2.cvs20060817-16
- rebuild against gecko-libs 1.9 (xulrunner)

jakarta-commons-dbcp-0:1.2.1-10jpp.3.fc9
----------------------------------------
* Thu Nov 22 2007 Deepak Bhole <dbhole at redhat.com> 0:1.2.1-10jpp.3
- Fix dangling symlink. bz#388801

jakarta-commons-logging-0:1.0.4-6jpp.5.fc9
------------------------------------------
* Tue Nov 06 2007 Stepan Kasal <skasal at redhat.com> - 1.0.4-6jpp.5
- fix typo in description

jd-1.9.7-1.fc9
--------------
* Thu Nov 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-1
- 1.9.7

* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.3.beta071109
- 1.9.7 beta 071109

jpilot-0.99.9-4.fc9
-------------------
* Thu Nov 22 2007 Ivana Varekova <varekova at redhat.com> - 0.99.9-4
- rebuilt

kdepim-6:3.5.8-6.svn20071013.ent.fc9
------------------------------------
* Thu Nov 22 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 6:3.5.8-6.20071013.ent
- rebuild for new pilot-link

* Tue Nov 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-5.20071013.ent
- compacting mbox shows empty folder (kde#146967, rh#352391)

* Fri Oct 26 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4.20071013.ent
- -libs: Obsoletes: %name ... to help out multilib upgrades

libdvdnav-4.1.1-3.fc9
---------------------
* Thu Nov 22 2007 Dominik Mierzejewski <rpm[AT]greysector.net> 4.1.1-3
- fix build with internal libdvdread

* Wed Nov 21 2007 Dominik Mierzejewski <rpm[AT]greysector.net> 4.1.1-2
- use upstream non-autotools buildsystem
- build with external libdvdread for older releases
- fix version.h
- fix soname
- fix lib paths on 64bit

libmtp-0.2.4-1.fc9
------------------
* Thu Nov 22 2007 Linus Walleij <triad at df.lth.se> 0.2.4-1
- New upstream release.

logwatch-7.3.6-13.fc9
---------------------
* Thu Nov 22 2007 Ivana Varekova <varekova at redhat.com> 7.3.6-13
- fix pam_unix script output (#389311)

man-pages-2.68-1.fc9
--------------------
* Thu Nov 22 2007 Ivana Varekova <varekova at redhat.com> - 2.68-1
- update to 2.68

* Mon Oct 22 2007 Ivana Varekova <varekova at redhat.com> - 2.67-1
- update to 2.67

* Tue Oct 09 2007 Ivana Varekova <varekova at redhat.com> - 2.66-1
- update to 2.66
- add proc man-page patch

man-pages-cs-0.17.20070905-1.fc9
--------------------------------
* Thu Nov 22 2007 Ivana Varekova <varekova at redhat.com> - 0.17.20070905-1
- update to 0.17.20070905
- patch to build in RPM_BUILD_ROOT (thanks Milan Kerslager)

maniadrive-1.2-5.fc9
--------------------
* Thu Nov 22 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.2-5
- Fix raydium subpackage description (bz 395261)
openoffice.org-1:2.3.1-9.3.fc9
------------------------------
* Thu Nov 22 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.1-9.3
- Resolves: rhbz#247634 add openoffice.org-2.3.1.ooo82911.sd.insertbackground.patch (jnavrati)
- Resolves: rhbz#386371 add workspace.sw8u10bf02.patch (caolanm)
- add openoffice.org-2.3.1.83876.unopkg.avoida11y.patch to avoid unopkg
  crapping out on first run with a11y enabled and no X (caolanm)
- add openoffice.org-2.3.1.ooo83877.sal.allowsoftlinkdelete.patch to allow
  sal to delete softlinks (caolanm)
- add openoffice.org-2.3.1.ooo83878.unopkg.enablelinking.patch to enable
  linking to unpacked extensions already on the fs when registering (caolanm)
==> makes extension rpm packaging non-wasteful and safe

perl-File-BaseDir-0.03-1.fc9
----------------------------
* Thu Nov 22 2007 Patrice Dumas <pertusus at free.fr> 0.03-1
- update to 0.03 (#396071)
php-pear-HTML-QuickForm-3.2.10-1.fc9
------------------------------------
* Thu Nov 22 2007 Christopher Stone <chris.stone at gmail.com> 3.2.10-1
- Upstream sync

php-pear-HTTP-Request-1.4.2-1.fc9
---------------------------------

php-pear-Numbers-Roman-1.0.2-2.fc9
----------------------------------

pilot-link-2:0.12.3-1.fc9
-------------------------
* Thu Nov 22 2007 Ivana Varekova <varekova at redhat.com> - 2:0.12.3-1
- update to 0.12.3
- remove static libraries

poppler-0.6.2-1.fc9
-------------------
* Thu Nov 22 2007 Matthias Clasen at redhat.com> - 0.6.2-1
- Update to 0.6.2

sendmail-8.14.2-1.fc9
---------------------
* Thu Nov 22 2007 Thomas Woerner <twoerner at redhat.com> 8.14.2-1
- new version 8.14.2

serpentine-0.9-2.fc9
--------------------
* Thu Nov 22 2007 Sindre Pedersen Bj??rdal <foolish at guezz.net> - 0.9-1
- New release
- Add missing PyXML dependency
- Update License tag
- Update Homepage link

* Sat Dec 23 2006 Jason L Tibbitts III <tibbs at math.uh.edu> - 0.7-6.fc9
- Rebuild with Python 2.5

* Mon Sep 11 2006 Sindre Pedersen Bj??rdal <foolish[AT]guezz.net> - 0.7-5
- Add missing perl-XML-Parser dependency to fix build

sgml-common-0.6.3-23.fc9
------------------------
* Thu Nov 22 2007 Ondrej Vasik <ovasik at redhat.com> 0.6.3-23
- Another MergeReview improvements(provided by Patrice Dumas)
- copy Automake-1.4 files instead of rerunning autotools,
- better preserving timestamps, better handling of documentation
- improved XML-common description

smolt-1.0-2.fc9
---------------
* Thu Nov 22 2007 Mike McGrath <mmcgrath at redhat.com> 1.0-2
- Installed scanner - #395901

system-config-date-1.9.17-1.fc9
-------------------------------
* Thu Nov 22 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.17-1
- some doc changes

* Wed Nov 21 2007 Nils Philippsen <nphilipp at redhat.com>
- migrate documentation to yelp/DocBook XML
- add docs translation rules

* Wed Oct 31 2007 Nils Philippsen <nphilipp at redhat.com>
- mention XEN/virtualization issues if hwclock fails (#357311)

system-config-printer-0.7.78-1.fc9
----------------------------------
* Thu Nov 22 2007 Tim Waugh <twaugh at redhat.com> 0.7.78-1
- pycups: Fix job-sheets-default attribute.
- Updated pycups to 1.9.31.
- 0.7.78.

* Wed Nov 21 2007 Tim Waugh <twaugh at redhat.com>
- Applied patch to pycups to avoid reading uninitialised
  memory (bug #390431).

* Mon Nov 19 2007 Tim Waugh <twaugh at redhat.com>
- Updated pycups to 1.9.30.

telepathy-haze-0.1.4-1.fc9
--------------------------
* Thu Nov 22 2007 Peter Gordon <peter at thecodergeek.com> - 0.1.4-1
- Update to new upstream build-fix release (0.1.4).
- Add Yahoo! IM support to the mission-control profiles, with default
  login/server information taken from Pidgin/Finch.

vim-2:7.1.159-1.fc9
-------------------
* Thu Nov 22 2007 Karsten Hopp <karsten at redhat.com> 7.1.159-1
- patchlevel 159
- vim-enhanced requires which for vimtutor (#395371)

wine-0.9.49-1.fc9
-----------------
* Tue Nov 13 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.49-1
- version upgrade

yelp-2.20.0-8.fc9
-----------------
* Thu Nov 22 2007 Martin Stransky <stransky at redhat.com> - 2.20.0-8
- rebuild against xulrunner

Broken deps for i386
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	conky - 1.4.8-1.fc9.i386 requires libaudacious.so.5
	evolution-conduits - 2.21.2-1.fc9.i386 requires libpisync.so.0
	gnome-pilot - 2.0.15-10.fc8.i386 requires libpisync.so.0
	gnome-pilot-conduits - 2.0.15-4.fc8.i386 requires libpisync.so.0
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.i386 requires libsensors.so.3



Broken deps for x86_64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.x86_64 requires libaudacious.so.5()(64bit)
	evolution-conduits - 2.21.2-1.fc9.x86_64 requires libpisync.so.0()(64bit)
	gnome-pilot - 2.0.15-10.fc8.i386 requires libpisync.so.0
	gnome-pilot - 2.0.15-10.fc8.x86_64 requires libpisync.so.0()(64bit)
	gnome-pilot-conduits - 2.0.15-4.fc8.x86_64 requires libpisync.so.0()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.x86_64 requires libsensors.so.3()(64bit)



Broken deps for ppc
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	conky - 1.4.8-1.fc9.ppc requires libaudacious.so.5
	evolution-conduits - 2.21.2-1.fc9.ppc requires libpisync.so.0
	gnome-pilot - 2.0.15-10.fc8.ppc64 requires libpisync.so.0()(64bit)
	gnome-pilot - 2.0.15-10.fc8.ppc requires libpisync.so.0
	gnome-pilot-conduits - 2.0.15-4.fc8.ppc requires libpisync.so.0
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc requires libsensors.so.3



Broken deps for ppc64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.ppc64 requires libaudacious.so.5()(64bit)
	evolution-conduits - 2.21.2-1.fc9.ppc64 requires libpisync.so.0()(64bit)
	gnome-pilot - 2.0.15-10.fc8.ppc64 requires libpisync.so.0()(64bit)
	gnome-pilot-conduits - 2.0.15-4.fc8.ppc64 requires libpisync.so.0()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	xfce4-sensors-plugin - 0.10.99.2-1.fc9.ppc64 requires libsensors.so.3()(64bit)





From jkeating at redhat.com  Fri Nov 23 14:53:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Nov 2007 09:53:24 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071122170253.GA2266@dspnet.fr.eu.org>
References: <20071120184133.GA51420@dspnet.fr.eu.org>
	<1195659663.7424.22.camel@space-ghost.verbum.private>
	<f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
	<604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
	<20071122162135.GB76845@dspnet.fr.eu.org>
	<20071122113045.0977d9d0@redhat.com>
	<20071122170253.GA2266@dspnet.fr.eu.org>
Message-ID: <20071123095324.0e960c46@redhat.com>

On Thu, 22 Nov 2007 18:02:53 +0100
Olivier Galibert <galibert at pobox.com> wrote:

> Well, the multilib conflicts is the #1 problem.  If we ignore that and
> you tell me the dvd is still seens as the core replacement, I'm in
> practice happy with that.  There is a conflict between generic-logos
> and fedora-logos,

That needs to be fixed in some way.


> and I consider the lack of tcsh a simple mistake.
> Minor, all of that.

tcsh isn't all that popular of a shell for the general masses.   Most
don't ever change their shell.  Although it is relatively small and I
will probably include it for F9.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071123/16e99a83/attachment.sig>

From mharris at mharris.ca  Fri Nov 23 15:04:20 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Fri, 23 Nov 2007 10:04:20 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
Message-ID: <4746EBF4.7040304@mharris.ca>

Panu Matilainen wrote:
> 
> To put it shortly, I going to switch the default rpm queryformat to 
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or so.
> 
> This is something that should've been done several releases ago really, 
> but since it presumably breaks all sorts of scripts people have it's 
> gotten delayed and delayed... The next major rpm.org release changes the 
> default anyway, this is just an initial step to see what breaks.
> 
> If you know the change would break some of the buildsystem / other 
> critical Fedora infrastructure, please holler NOW! I can delay the 
> change a bit to allow critical pieces to be fixed first, but F9 *will* 
> have the new queryformat so better prepare for it...
> 
> Fixing any scripts that absolutely rely on the old default is trivial: 
> just them use explicit --qf "%{name}-%{version}-%{release}"

My faith in the Flying Spaghetti Monster has paid off.  My prayers have 
finally been answered!



-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From nicolas.mailhot at laposte.net  Fri Nov 23 15:04:32 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 23 Nov 2007 16:04:32 +0100 (CET)
Subject: WTF? Inaccessible bug reports?
Message-ID: <56456.192.54.193.53.1195830272.squirrel@rousalka.dyndns.org>


Le Ven 23 novembre 2007 15:53, Jesse Keating a ?crit :
> On Thu, 22 Nov 2007 18:02:53 +0100
> Olivier Galibert <galibert at pobox.com> wrote:
>
>> Well, the multilib conflicts is the #1 problem.  If we ignore that
>> and
>> you tell me the dvd is still seens as the core replacement, I'm in
>> practice happy with that.  There is a conflict between generic-logos
>> and fedora-logos,
>
> That needs to be fixed in some way.

We should not ship generic-logos in our official spins at all

-- 
Nicolas Mailhot



From pknirsch at redhat.com  Fri Nov 23 15:37:15 2007
From: pknirsch at redhat.com (Phil Knirsch)
Date: Fri, 23 Nov 2007 16:37:15 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <4746EBF4.7040304@mharris.ca>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<4746EBF4.7040304@mharris.ca>
Message-ID: <4746F3AB.6030901@redhat.com>

Mike A. Harris wrote:
> Panu Matilainen wrote:
>>
>> To put it shortly, I going to switch the default rpm queryformat to 
>> include package architecture (ie what you get now with
>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days 
>> or so.
>>
>> This is something that should've been done several releases ago 
>> really, but since it presumably breaks all sorts of scripts people 
>> have it's gotten delayed and delayed... The next major rpm.org release 
>> changes the default anyway, this is just an initial step to see what 
>> breaks.
>>
>> If you know the change would break some of the buildsystem / other 
>> critical Fedora infrastructure, please holler NOW! I can delay the 
>> change a bit to allow critical pieces to be fixed first, but F9 *will* 
>> have the new queryformat so better prepare for it...
>>
>> Fixing any scripts that absolutely rely on the old default is trivial: 
>> just them use explicit --qf "%{name}-%{version}-%{release}"
> 
> My faith in the Flying Spaghetti Monster has paid off.  My prayers have 
> finally been answered!
> 

/me sends Mike a stack of Diet Coke for his Spaghetti.

And to topic: +1!!one!eleven!1!!!

Read ya, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Team Lead Core Services      | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.



From buildsys at fedoraproject.org  Fri Nov 23 16:04:39 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Fri, 23 Nov 2007 11:04:39 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-23
Message-ID: <20071123160439.D1A1515212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 9

    gtkterm-0.99.5-5.fc6
    jd-1.9.7-1.fc6
    kmenu-gnome-0.6.9-2.fc6
    php-pear-HTML-QuickForm-3.2.10-1.fc6
    php-pear-HTTP-Request-1.4.2-1.fc6
    php-pear-Numbers-Roman-1.0.2-2.fc6
    phpMyAdmin-2.11.2.2-1.fc6
    smolt-1.0-1.fc6
    xtide-2.9.4-3.fc6


Changes in Fedora Extras 6: 


gtkterm-0.99.5-5.fc6
--------------------
* Wed Nov 21 2007 Dan Horak <dan[at]danny.cz> 0.99.5-5
- fix buffer usage (bz 394891)

jd-1.9.7-1.fc6
--------------
* Thu Nov 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-1
- 1.9.7

kmenu-gnome-0.6.9-2.fc6
-----------------------
* Wed Nov 21 2007 Chitlesh Goorah <chitlesh at fedoraproject.org>- 0.6.9-2
- new upstream release

* Sat Nov 03 2007 Ariszlo <ariszlo at gmail.com> - 0.6.9-1
- release 0.6.9
- Replaced fc5-hide-bug196275.menu with fedora-administration.menu
- Replaced remove-system-administration.patch with fedora-administration.patch
- Moved GParted, Live Install and all Server Settings into Administration
- Replaced icon-office.png with redhat-office.png
- Removed printer.png -> gnome-dev-printer.png symlinks

* Wed Sep 12 2007 Chitlesh Goorah <chitlesh at fedoraproject.org>- 0.6.8-2
- new upstream release

* Wed Sep 12 2007 Ariszlo <ariszlo at gmail.com> - 0.6.8-1
- release 0.6.8
- Added include categories to fc5-hide-bug196275.menu
- Added remove-system-administration.patch

php-pear-HTML-QuickForm-3.2.10-1.fc6
------------------------------------
* Thu Nov 22 2007 Christopher Stone <chris.stone at gmail.com> 3.2.10-1
- Upstream sync

php-pear-HTTP-Request-1.4.2-1.fc6
---------------------------------
* Thu Nov 22 2007 Christopher Stone <chris.stone at gmail.com> 1.4.2-1
- Upstream sync

php-pear-Numbers-Roman-1.0.2-2.fc6
----------------------------------
* Thu Nov 22 2007 Christopher Stone <chris.stone at gmail.com> 1.0.2-2
- Add new tests to %files

* Thu Nov 22 2007 Christopher Stone <chris.stone at gmail.com> 1.0.2-1
- Upstream sync

phpMyAdmin-2.11.2.2-1.fc6
-------------------------
* Wed Nov 21 2007 Robert Scheck <robert at fedoraproject.org> 2.11.2.2-1
- Upstream released 2.11.2.2 (#393771)

smolt-1.0-1.fc6
---------------
* Tue Nov 20 2007 Mike McGrath <mmcgrath at redhat.com> 1.0-1
- Upstream released new version

xtide-2.9.4-3.fc6
-----------------
* Fri Nov 23 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.9.4-3
- Update harmonics data to 20071122.



From caolanm at redhat.com  Fri Nov 23 17:47:23 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Fri, 23 Nov 2007 17:47:23 +0000
Subject: hypenation rules in openoffice.org
Message-ID: <1195840043.5226.109.camel@Jehannum>

I'll be splitting out next week from OOo the "hyphenation dictionaries",
i.e. ?hyphenation rules as to where best to break a word if it doesn't
fit in the remaining space in a line. That way they can be independently
updated, and perhaps more importantly as a side effect this will allow
other ones to be packaged and just "dropped in" and auto-detected so as
to get proper hyphenation support for languages where hyphenation rules
exist but are not part of vanilla OOo, e.g. swedish, slovak etc. 

So I'll have about 11 very small and very similar packages to get
reviewed, it'd make sense if the same person reviewed the lot so as to
not have to revisit old ground each time, like we did for the spellcheck
dictionaries. Any volunteer ?

C.



From debarshi.ray at gmail.com  Fri Nov 23 17:48:54 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Fri, 23 Nov 2007 23:18:54 +0530
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071123095324.0e960c46@redhat.com>
References: <20071120184133.GA51420@dspnet.fr.eu.org>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
	<604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
	<20071122162135.GB76845@dspnet.fr.eu.org>
	<20071122113045.0977d9d0@redhat.com>
	<20071122170253.GA2266@dspnet.fr.eu.org>
	<20071123095324.0e960c46@redhat.com>
Message-ID: <3170f42f0711230948o2e051af3tf78f332105e21ceb@mail.gmail.com>

>> and I consider the lack of tcsh a simple mistake.
>> Minor, all of that.

> tcsh isn't all that popular of a shell for the general masses.   Most
> don't ever change their shell.  Although it is relatively small and I
> will probably include it for F9.

Some of the EDA vendors exclusively use tcsh. It should atleast be
there in the Fedora Electronic Lab Spin.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From pertusus at free.fr  Fri Nov 23 18:37:18 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 23 Nov 2007 19:37:18 +0100
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071123095324.0e960c46@redhat.com>
References: <f3ddc6d30711210835w6cf47f95s11e73122ae8d808b@mail.gmail.com>
	<1195664529.7424.29.camel@space-ghost.verbum.private>
	<20071121184908.GA38223@dspnet.fr.eu.org>
	<604aa7910711211103y2e7ed5b6qa0e9e5c113db7891@mail.gmail.com>
	<20071122002754.GA75436@dspnet.fr.eu.org>
	<604aa7910711211704g3f0bf1cemdc70ff98c9954e6e@mail.gmail.com>
	<20071122162135.GB76845@dspnet.fr.eu.org>
	<20071122113045.0977d9d0@redhat.com>
	<20071122170253.GA2266@dspnet.fr.eu.org>
	<20071123095324.0e960c46@redhat.com>
Message-ID: <20071123183718.GC2865@free.fr>

On Fri, Nov 23, 2007 at 09:53:24AM -0500, Jesse Keating wrote:
> 
> tcsh isn't all that popular of a shell for the general masses.   Most
> don't ever change their shell.  Although it is relatively small and I
> will probably include it for F9.

It is still quite popular in labs.

--
Pat



From myfedora at richip.dhs.org  Fri Nov 23 18:55:52 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 23 Nov 2007 11:55:52 -0700
Subject: joe
Message-ID: <1195844152.12419.8.camel@localhost6.localdomain6>

Hi,

Is there any way to get joe (Joe's own Editor) back onto the Fedora
image? It's the only text editor I'm comfortable with using. (Laugh it
up.) It's really small and I need an editor during installs to edit
config files (including yum .repo files).
--

Richi Plana



From myfedora at richip.dhs.org  Fri Nov 23 19:41:38 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 23 Nov 2007 12:41:38 -0700
Subject: RFE: rpmlint
Message-ID: <1195846898.12419.32.camel@localhost6.localdomain6>

Hi,

As a first-time Package Maintainer, I've come to realize what a great
tool rpmlint is. Even after reading the Package Maintainers Guideline, I
found rpmlint helpful in reminding me of things I've read but just
forgotten (and, *abashedly*, let me know of things I skipped over). Best
of all, most of the "info" it provided told me what the problem was, and
some of the info even told me what to do about it.

The enhancement I'm making a request of is to actually improve that
latter part: the informing the PM what to do with regards to an error.
Rpmlint is in a great position to know details of user's error. What
would be nice is if there was a main database of Errors and Warnings as
well as ways to fix it.

It would be nice if rpmlint (via the -i option) could provide more
information about fixing the problem. It could also have URL at the
bottom with a link to a wiki which could contain more information (in
case it's too long to add to the docs), and the wiki could have user
contributed notes at the bottom (a'la http://docs.php.net/manual/en/).
There could be one error or warning per page.

Example output:

$ rpmlint -i package-<version>.<arch>.rpm
package.<arch>: W: incoherent-version-in-changelog 0.99.7-1.fc7
1.0-1.fc7
The last entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.

Read more at
http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors#head-361831a4bde352cd7587024823d9a3a40464d225



+----------+         +------+
| Database |  <----> | Wiki |
+==========+         +------+
| Errors   |
|   Fixes  |         +---------+
| Warnings |  -----> | rpmlint |
|   Fixes  |         +---------+
+----------+

Currently, there are 2 pages on the Wiki
(http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors and
http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues ) but they
hasn't kept up with rpmlint and is incomplete. It also has some nice
nuggets that's missing from rpmlint.

This may not mean much to seasoned packagers, but wannabes are going to
find this golden.

If that's too complicated, how about an update of the
CommonRpmlintErrors page, at the least? ;)
--

Richi Plana



From martin at marquesminen.com.ar  Fri Nov 23 20:35:34 2007
From: martin at marquesminen.com.ar (Martin Marques)
Date: Fri, 23 Nov 2007 17:35:34 -0300
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <20071123170139.629e9b64.blueser@gmail.com>
References: <20071123170139.629e9b64.blueser@gmail.com>
Message-ID: <47473996.7030002@marquesminen.com.ar>

I'm adding the fedora-devel-list as I think this should be discussed there.

Andre Costa escribi?:
> Hi folks,
> 
> bug #372011 [https://bugzilla.redhat.com/show_bug.cgi?id=372011] is
> hosting a heated debate about anaconda & F8, how this dreadful bug has
> been hurting F8 reputation and so on (I'm one of the poor souls that
> have been affected by it -- and have been saved by patched .img
> provided by Jeremy Katz
> [http://katzj.fedorapeople.org/updates-f8-yumloop.img]).

It has hurted very much I must say.

> One thing that's clear is that anaconda QA missed some key spots, and
> also that we (users) didn't help much on the process, allowing the bugs
> to remain hidden until the version was officially released, which led to
> a lot of stress among users and developers.

The problem is that most users don't have time and resources to test
twice a year a new release. 6 months for development+beta testing+RC
testing is just too little. IMHO.

Also, what kind of QA does Fedora have today? I'm not throwing mud at
anyone, it's just that I don't have the slightest idea! (As Lucy used to
say in the Peanuts Gang). There should be a list of things that have to
be tested, and for each one of them, testers should report on the output
of the test. Some items are more critical then others, and so should
have more test reports.

Just some ideas that just cracked out of my head. :-D

> I would really like to participate more during the beta stage of new
> Fedora versions. However, as I stated on Comment #97
> [https://bugzilla.redhat.com/show_bug.cgi?id=372011#c97] I can't really
> install beta versions on my system at home, I use it daily, including
> for work.

This is exactly what I stated before: you don't have the resources.

> But, AFAICS the other aspects of the installation process are pretty
> much stable and independent from the current installation (language
> selection, keyboard selection etc.), and the critical step for an
> upgrade is dependency solving / package selection.
> 
> So, what if the developers provided early access to this particular
> part of anaconda only? I mean, in read-only mode, it would just gather
> information about the packages currently installed and confirm if it
> would be able to handle an upgrade on a "real" installation scenario?
> It could for instance stop right after depsolve and show some
> statistics.

Well, nobody could ensure that the beta anaconda will not bite your
disk. It is pre-beta.

> Believe me, if I was sure that I could test anaconda in read-only mode I
> would gladly do it, at any step before the official release. Chances
> are that test coverage would improve considerably, and no installation
> would be touched during this process.
> 
> Does this make any sense to anyone? Would this help? Is it already
> possible somehow?

What I do see as something Fedora Project should do is whats commented
in comment #104
[https://bugzilla.redhat.com/show_bug.cgi?id=372011#c104] about
information on the web page of how to collaborate with the project.

What would be a hugh plus for the project.



From overholt at redhat.com  Fri Nov 23 20:51:09 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Fri, 23 Nov 2007 15:51:09 -0500
Subject: javadoc scriptlets
In-Reply-To: <ufak5oax3he.fsf@epithumia.math.uh.edu>
References: <ufak5oax3he.fsf@epithumia.math.uh.edu>
Message-ID: <20071123205109.GB478@redhat.com>

* Jason L Tibbitts III <tibbs at math.uh.edu> [2007-11-22 00:19]:
> I'm having trouble understanding why many Java-using packages have the
> following scriptlets:
> 
> %post javadoc
> %__rm -f %{_javadocdir}/%{name}
> %__ln_s %{name}-%{version} %{_javadocdir}/%{name}
> 
> %postun javadoc
> if [ $1 -eq 0 ]; then
>   %__rm -f %{_javadocdir}/%{name}
> fi

This is/was a JPackage-ism IIRC.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071123/fdb2ebf4/attachment.sig>

From marcelo.gobelli at gmail.com  Fri Nov 23 21:19:00 2007
From: marcelo.gobelli at gmail.com (marcelo gobelli)
Date: Fri, 23 Nov 2007 13:19:00 -0800
Subject: information
In-Reply-To: <364d303b0711211007k2677005as460e93e3eefe0ab8@mail.gmail.com>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>
	<ufak5ogi5yh.fsf@epithumia.math.uh.edu>
	<72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>
	<72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>
	<364d303b0711211007k2677005as460e93e3eefe0ab8@mail.gmail.com>
Message-ID: <72fee6e40711231319x295eb113uc9eeb20476a111c0@mail.gmail.com>

chris,
thanks for the response. I am familiar with C and java. I work full-time as
a desktop support analyst. I would like to participate in one of the testing
meetings so I can have a better idea of what is required from volunteers.
when is the next one?
marcelo


On 11/21/07, Christopher Brown <snecklifter at gmail.com> wrote:
>
> On 21/11/2007, marcelo gobelli <marcelo.gobelli at gmail.com> wrote:
> > jason,
> > i sent an email to will woods at redhat but I have not heard from him. I
> > think I could help with testing.
> > marcelo
>
> Can you be more specific with what you'd like to do? I guess you have
> seen:
>
> http://fedoraproject.org/wiki/FedoraTesting
>
> I find working through bugs in bugzilla to be quite rewarding.
>
> http://fedoraproject.org/wiki/BugZappers
>
> What languages are you familiar with? What is your background? Don't
> be afraid to speak up., although I would highly recommend using
> (subscribing) to the fedora-test-list which is dedicated to testing
> releases.
>
> Cheers
> Chris
>
> --
> http://www.chruz.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071123/16e57472/attachment.htm>

From ville.skytta at iki.fi  Fri Nov 23 21:22:50 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 23 Nov 2007 23:22:50 +0200
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <1195815370.10878.420.camel@cookie.hadess.net>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<200711230924.20520.ville.skytta@iki.fi>
	<1195815370.10878.420.camel@cookie.hadess.net>
Message-ID: <200711232322.51210.ville.skytta@iki.fi>

On Friday 23 November 2007, Bastien Nocera wrote:
> On Fri, 2007-11-23 at 09:24 +0200, Ville Skytt? wrote:
> > On Friday 23 November 2007, Bastien Nocera wrote:
> > > As for user-space, realistically, we'd only be able to support analog
> > > tuners. Most digital tuners use MPEG-2 or MPEG-4, and we can't ship
> > > decoders for those codecs in Fedora...
> >
> > Some of those cards have hardware MPEG decoders and require no software
> > MPEG support.
>
> Any examples?

"Full Featured" or "Premium" DVB cards from Hauppauge and Technotrend.



From tibbs at math.uh.edu  Fri Nov 23 23:31:03 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 23 Nov 2007 17:31:03 -0600
Subject: javadoc scriptlets
In-Reply-To: <20071123205109.GB478@redhat.com>
References: <ufak5oax3he.fsf@epithumia.math.uh.edu>
	<20071123205109.GB478@redhat.com>
Message-ID: <ufa63zstu88.fsf@epithumia.math.uh.edu>

>>>>> "AO" == Andrew Overholt <overholt at redhat.com> writes:

AO> This is/was a JPackage-ism IIRC.

Well, according to some, jpackage-isms are fedora-isms, and we have no
Java guidelines which say anything to the contrary.

Please, if you understand Java, help us come up with some guidelines.
Or can I at least ping you directly with questions?  This and the
debuginfo issue are keeping me from even looking at other Java-using
packages in the review queue, but I'm sure I would find other issues
if I started looking.

 - J<



From tibbs at math.uh.edu  Fri Nov 23 23:35:24 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 23 Nov 2007 17:35:24 -0600
Subject: hypenation rules in openoffice.org
In-Reply-To: <1195840043.5226.109.camel@Jehannum>
References: <1195840043.5226.109.camel@Jehannum>
Message-ID: <ufazlx4sfgj.fsf@epithumia.math.uh.edu>

>>>>> "CM" == Caolan McNamara <caolanm at redhat.com> writes:

CM> So I'll have about 11 very small and very similar packages to get
CM> reviewed,

Well, one thing to do would be to post one review ticket and work on
that and then post the rest with the benefit of the feedback from the
first review.

If these are Java packages then it would also be good if we had
someone with knowledge of Java onboard to help with questions that
crop up arising from Java packaging issues.

 - J<



From otto_rey at yahoo.com.ar  Sat Nov 24 00:44:32 2007
From: otto_rey at yahoo.com.ar (Otto Rey)
Date: Fri, 23 Nov 2007 16:44:32 -0800 (PST)
Subject: joe
Message-ID: <963715.30329.qm@web52407.mail.re2.yahoo.com>

Did you try nano ? This one comes as default in all Fedora Spin's

----- Mensaje original ----
De: Richi Plana <myfedora at richip.dhs.org>
Para: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Enviado: viernes 23 de noviembre de 2007, 15:55:52
Asunto: joe

Hi,

Is there any way to get joe (Joe's own Editor) back onto the Fedora
image? It's the only text editor I'm comfortable with using. (Laugh it
up.) It's really small and I need an editor during installs to edit
config files (including yum .repo files).
--

Richi Plana

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list





      Los referentes m?s importantes en compra/ venta de autos se juntaron:
Demotores y Yahoo!
Ahora comprar o vender tu auto es m?s f?cil. Vist? ar.autos.yahoo.com/



From skvidal at fedoraproject.org  Sat Nov 24 00:56:09 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 23 Nov 2007 19:56:09 -0500
Subject: joe
In-Reply-To: <1195844152.12419.8.camel@localhost6.localdomain6>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
Message-ID: <1195865769.5026.1.camel@cutter>


On Fri, 2007-11-23 at 11:55 -0700, Richi Plana wrote:
> Hi,
> 
> Is there any way to get joe (Joe's own Editor) back onto the Fedora
> image? It's the only text editor I'm comfortable with using. (Laugh it
> up.) It's really small and I need an editor during installs to edit
> config files (including yum .repo files).

joe is in the distro now. Or do you mean on the livecd?

i use joe for a lot of things.
-sv




From jkeating at redhat.com  Sat Nov 24 01:03:33 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Nov 2007 20:03:33 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <56456.192.54.193.53.1195830272.squirrel@rousalka.dyndns.org>
References: <56456.192.54.193.53.1195830272.squirrel@rousalka.dyndns.org>
Message-ID: <20071123200333.32033eef@redhat.com>

On Fri, 23 Nov 2007 16:04:32 +0100 (CET)
"Nicolas Mailhot" <nicolas.mailhot at laposte.net> wrote:

> We should not ship generic-logos in our official spins at all

It's being pulled in because it has the same provides as the official
logos.  Because the compose tool can't make assumptions about the
transaction set at install time, we have to pull in all possible dep
resolvers into the image, and then let install time package set
determine the best resolver for that particular install.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071123/79b10f51/attachment.sig>

From myfedora at richip.dhs.org  Sat Nov 24 02:08:17 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 23 Nov 2007 19:08:17 -0700
Subject: joe
In-Reply-To: <1195865769.5026.1.camel@cutter>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
Message-ID: <1195870097.14939.4.camel@localhost6.localdomain6>

On Fri, 2007-11-23 at 19:56 -0500, seth vidal wrote:
> On Fri, 2007-11-23 at 11:55 -0700, Richi Plana wrote:
> > Hi,
> > 
> > Is there any way to get joe (Joe's own Editor) back onto the Fedora
> > image? It's the only text editor I'm comfortable with using. (Laugh it
> > up.) It's really small and I need an editor during installs to edit
> > config files (including yum .repo files).
> 
> joe is in the distro now. Or do you mean on the livecd?

It's not on the DVD image. I usually need a text editor before I can
even connect to the network (edit yum .repo). At least I could find the
joe-* packages inside the Packages/ subdirectory.

I suppose I could temporarily use nano (the cursor controls are similar
enough to joe, emacs, bash, etc., but Joe's other commands are similar
to ... and don't laugh ... WordStar), but if I could get joe on the DVD,
I'd be a happy camper.
--

Richi Plana



From panemade at gmail.com  Sat Nov 24 04:54:21 2007
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Sat, 24 Nov 2007 10:24:21 +0530
Subject: RFE: rpmlint
In-Reply-To: <1195846898.12419.32.camel@localhost6.localdomain6>
References: <1195846898.12419.32.camel@localhost6.localdomain6>
Message-ID: <f4586a2e0711232054h53f95ee5m3bbd94ad6e558ce2@mail.gmail.com>

Hi,
On Nov 24, 2007 1:11 AM, Richi Plana <myfedora at richip.dhs.org> wrote:
> Hi,
>
> As a first-time Package Maintainer, I've come to realize what a great
> tool rpmlint is. Even after reading the Package Maintainers Guideline, I
> found rpmlint helpful in reminding me of things I've read but just
> forgotten (and, *abashedly*, let me know of things I skipped over). Best
> of all, most of the "info" it provided told me what the problem was, and
> some of the info even told me what to do about it.
>
> The enhancement I'm making a request of is to actually improve that
> latter part: the informing the PM what to do with regards to an error.
> Rpmlint is in a great position to know details of user's error. What
> would be nice is if there was a main database of Errors and Warnings as
> well as ways to fix it.
>
> It would be nice if rpmlint (via the -i option) could provide more
> information about fixing the problem. It could also have URL at the
> bottom with a link to a wiki which could contain more information (in
> case it's too long to add to the docs), and the wiki could have user
> contributed notes at the bottom (a'la http://docs.php.net/manual/en/).
> There could be one error or warning per page.
>
> Example output:
>
> $ rpmlint -i package-<version>.<arch>.rpm
> package.<arch>: W: incoherent-version-in-changelog 0.99.7-1.fc7
> 1.0-1.fc7
> The last entry in %changelog contains a version identifier that is not
> coherent with the epoch:version-release tuple of the package.
>
> Read more at
> http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors#head-361831a4bde352cd7587024823d9a3a40464d225
>
>
>
> +----------+         +------+
> | Database |  <----> | Wiki |
> +==========+         +------+
> | Errors   |
> |   Fixes  |         +---------+
> | Warnings |  -----> | rpmlint |
> |   Fixes  |         +---------+
> +----------+
>
> Currently, there are 2 pages on the Wiki
> (http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors and
> http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues ) but they
> hasn't kept up with rpmlint and is incomplete. It also has some nice
> nuggets that's missing from rpmlint.
>
> This may not mean much to seasoned packagers, but wannabes are going to
> find this golden.
>
> If that's too complicated, how about an update of the
> CommonRpmlintErrors page, at the least? ;)

 When I started with Fedora Project and started reviewing package I
was in need of common rpmlint messages listed on some page for easy
look back to them for how to solve them and ask packager/submitter to
fix those rpmlint messages.
  Later on as I got used to with reviewing packages and rpmlint output
I left updating that page. But If you want some more messages and
their fixes should be listed there then I will do that.

Regards,
Parag.



From sundaram at fedoraproject.org  Sat Nov 24 06:06:24 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 24 Nov 2007 11:36:24 +0530
Subject: information
In-Reply-To: <72fee6e40711231319x295eb113uc9eeb20476a111c0@mail.gmail.com>
References: <72fee6e40711171836r6fa57edepaf3c5c882b91b0ec@mail.gmail.com>	<ufak5ogi5yh.fsf@epithumia.math.uh.edu>	<72fee6e40711182224s2351a000g634dff1ecc5b5bf4@mail.gmail.com>	<72fee6e40711210912q7f73488alfb2a55b547f06567@mail.gmail.com>	<364d303b0711211007k2677005as460e93e3eefe0ab8@mail.gmail.com>
	<72fee6e40711231319x295eb113uc9eeb20476a111c0@mail.gmail.com>
Message-ID: <4747BF60.6030504@fedoraproject.org>

marcelo gobelli wrote:
> chris,
> thanks for the response. I am familiar with C and java. I work full-time 
> as a desktop support analyst. I would like to participate in one of the 
> testing meetings so I can have a better idea of what is required from 
> volunteers. when is the next one?
> marcelo

http://fedoraproject.org/wiki/QA/Meetings

Rahul



From sundaram at fedoraproject.org  Sat Nov 24 06:17:16 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 24 Nov 2007 11:47:16 +0530
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <20071123200333.32033eef@redhat.com>
References: <56456.192.54.193.53.1195830272.squirrel@rousalka.dyndns.org>
	<20071123200333.32033eef@redhat.com>
Message-ID: <4747C1EC.6090404@fedoraproject.org>

Jesse Keating wrote:
> On Fri, 23 Nov 2007 16:04:32 +0100 (CET)
> "Nicolas Mailhot" <nicolas.mailhot at laposte.net> wrote:
> 
>> We should not ship generic-logos in our official spins at all
> 
> It's being pulled in because it has the same provides as the official
> logos.  Because the compose tool can't make assumptions about the
> transaction set at install time, we have to pull in all possible dep
> resolvers into the image, and then let install time package set
> determine the best resolver for that particular install.

Can't you blacklist specific packages?

Rahul



From dtimms at iinet.net.au  Sat Nov 24 08:14:58 2007
From: dtimms at iinet.net.au (David Timms)
Date: Sat, 24 Nov 2007 19:14:58 +1100
Subject: Support TV - Proposal for F9 - enhanced DVB capabilities
In-Reply-To: <385453.83318.qm@web52410.mail.re2.yahoo.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
Message-ID: <4747DD82.20703@iinet.net.au>

Otto Rey wrote:
> Fedora should have a good support of TV cards.

Some areas interesting to me:

1. auto detect / load of drivers:
I would be great if the bootup process would detect that the user has a 
dvb tuner card and load the driver(s) without intervention {even once}.

Currently I can # modprobe dvb_bt8xx   to get the kernel driver loaded.
This can be manually inserted into /etc/modprobe.conf , but with the 
hal/udev packages, I assume it is possible for the detection of the card 
on the pci bus during bootup to be the trigger to cause the module to be 
loaded.

If so, possibly what is needed is suitable pciid -> driver mapping for a 
wider range of multimedia / tv devices.

This would go a fair way in making it simpler for people to get dtv 
going on their machines. Although, a user would still need to find 
non-fedora packages for actual playback of dvb streams.

2. DVB tuning:
Another area where improvements can be made is in the initial setup / 
channel scan for DVB cards {maybe analog as well?}. Currently, it is a 
task to find appropriate info, then to run some carrier detecting 
program, and then have it detect the demodulation and decoding types, 
and lastly convert this to a useable list of available DVB channels.

There also seems to be no standard location for the generated 
channels.conf file, and hence needing to making multiple copies of it 
available for various DVB playback applications {xine, mplayer}, in user 
.app directories. Having a standard app build a channels.conf for the 
users location, and placing it in a standard location means that 
downstream users of the file {tzap, xine, mplayer can be modified to 
expect a channels.conf in that location, but still allow over-ride with 
appropriate parameters if required.

3. DVB recording packages:
AFAIK, a package that can record {not playback} a DVB stream would meet 
F guidelines. In fact it can be as simple as using tzap {dvb-apps} and 
cat to record dvb programs.

Perhaps a split-up mythtv package that can record analog and digital 
content, but optionally playback mpeg streams {live, recorded, delayed} 
only if non Fedora parts are installed would be possible. This could 
also help to support both analog capture cards and digital cards with 
built-in mpeg decoders out of the box in a great TV app.

I have no idea if that is possible, ie if there are compile options, 
etc. However, it can be installed as a backend only - where no playback 
occurs on the scheduled program recording machine, and a frontend 
machine connects to select times/programs for record.

Cheers,

David Timms.



From pmatilai at laiskiainen.org  Sat Nov 24 08:16:25 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 24 Nov 2007 10:16:25 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1195808368.27429.15.camel@wombat.tiptoe.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<1195802914.2831.7.camel@sb-home>
	<1195808368.27429.15.camel@wombat.tiptoe.de>
Message-ID: <alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>

On Fri, 23 Nov 2007, Nils Philippsen wrote:
>
> On Fri, 2007-11-23 at 08:28 +0100, nodata wrote:
>> Am Donnerstag, den 22.11.2007, 17:00 -0600 schrieb Callum Lerwick:
>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>> include package architecture (ie what you get now with
>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
>>>> so.
>>>
>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>> That would encourage the use of epochs.

Hardly. It would however stop the ages old pretense of epochs being some 
mysterious invisible evil people are afraid to talk aloud of. It would 
also largely stop the "look I found a bug in rpm: it thinks foo-1.2 is 
newer than foo-2.0" reports/questions.

To go that route I think the default file name should also be changed to 
include epoch if present. Would probably break another big bunch of 
scripts people have, but relying on filename for rpm name and version 
information is very broken to begin with anyway (and easily fixed)

The ugly part is that it makes parsing harder as you have to account for 
the possibility of epoch being or not being there always, but OTOH you can 
always pick your own queryformat if you don't want to deal with it.

> I don't think so -- "Look, this package has an epoch, I'll add that to
> my package too"? Hardly. If I'm interested in the version of a package,
> I'm interested in the epoch, too, if there's one. IMO, the only reason
> against listing the epoch here is that RPM itself doesn't understand it
> when specifying packages:
>
> nils at wombat:~> rpm -q gimp-2:2.4.1-1.fc8.x86_64
> package gimp-2:2.4.1-1.fc8.x86_64 is not installed
> nils at wombat:~> rpm -q gimp-2.4.1-1.fc8.x86_64
> gimp-2.4.1-1.fc8

That can be fix.

 	- Panu -



From sundaram at fedoraproject.org  Sat Nov 24 08:48:02 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 24 Nov 2007 14:18:02 +0530
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>	<1195772447.14235.0.camel@localhost>	<1195802914.2831.7.camel@sb-home>	<1195808368.27429.15.camel@wombat.tiptoe.de>
	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>
Message-ID: <4747E542.2030408@fedoraproject.org>

Panu Matilainen wrote:

> 
> The ugly part is that it makes parsing harder as you have to account for 
> the possibility of epoch being or not being there always, but OTOH you 
> can always pick your own queryformat if you don't want to deal with it.

Can't you unconditionally have a epoch number listed all the time? 0 if 
there is no epoch for that package.

Rahul



From pertusus at free.fr  Sat Nov 24 09:16:16 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 24 Nov 2007 10:16:16 +0100
Subject: RFE: rpmlint
In-Reply-To: <f4586a2e0711232054h53f95ee5m3bbd94ad6e558ce2@mail.gmail.com>
References: <1195846898.12419.32.camel@localhost6.localdomain6>
	<f4586a2e0711232054h53f95ee5m3bbd94ad6e558ce2@mail.gmail.com>
Message-ID: <20071124091616.GA2577@free.fr>

On Sat, Nov 24, 2007 at 10:24:21AM +0530, Parag N(????) wrote:
> Hi,

> > (http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors and
> > http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues ) but they
> 
>  When I started with Fedora Project and started reviewing package I
> was in need of common rpmlint messages listed on some page for easy
> look back to them for how to solve them and ask packager/submitter to
> fix those rpmlint messages.
>   Later on as I got used to with reviewing packages and rpmlint output
> I left updating that page. But If you want some more messages and
> their fixes should be listed there then I will do that.

Parag, could you please merge your page with the
http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues
page?

--
Pat



From pmatilai at laiskiainen.org  Sat Nov 24 09:46:36 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 24 Nov 2007 11:46:36 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <4747E542.2030408@fedoraproject.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<1195802914.2831.7.camel@sb-home>
	<1195808368.27429.15.camel@wombat.tiptoe.de>
	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>
	<4747E542.2030408@fedoraproject.org>
Message-ID: <alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>

On Sat, 24 Nov 2007, Rahul Sundaram wrote:

> Panu Matilainen wrote:
>
>> 
>> The ugly part is that it makes parsing harder as you have to account for 
>> the possibility of epoch being or not being there always, but OTOH you can 
>> always pick your own queryformat if you don't want to deal with it.
>
> Can't you unconditionally have a epoch number listed all the time? 0 if there 
> is no epoch for that package.

Obviously you CAN, but do you REALLY want to?

 	- Panu -



From fedora at leemhuis.info  Sat Nov 24 10:23:16 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 24 Nov 2007 11:23:16 +0100
Subject: repotags and rpm default queryformat  (was: Re: Changing the rpm
 default queryformat to include arch)
In-Reply-To: <alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>	<1195772447.14235.0.camel@localhost>	<1195802914.2831.7.camel@sb-home>	<1195808368.27429.15.camel@wombat.tiptoe.de>	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>	<4747E542.2030408@fedoraproject.org>
	<alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
Message-ID: <4747FB94.30509@leemhuis.info>

On 24.11.2007 10:46, Panu Matilainen wrote:
> On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> 
>> Panu Matilainen wrote:
>>> The ugly part is that it makes parsing harder as you have to account for 
>>> the possibility of epoch being or not being there always, but OTOH you can 
>>> always pick your own queryformat if you don't want to deal with it.
>> Can't you unconditionally have a epoch number listed all the time? 0 if there 
>> is no epoch for that package.
> Obviously you CAN, but do you REALLY want to?

While at discussing rpm's default queryformat -- should we get the
information where a packages comes from integrated *somewhere* (maybe no
"rpm -q") in the output from rpm or yum as well to finally solve the old
"repotags are useful" vs. "repotags are evil" debate?

CU
knurd



From drago01 at gmail.com  Sat Nov 24 11:24:29 2007
From: drago01 at gmail.com (drago01)
Date: Sat, 24 Nov 2007 12:24:29 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
Message-ID: <474809ED.3020404@gmail.com>

Panu Matilainen wrote:
>
> To put it shortly, I going to switch the default rpm queryformat to 
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days 
> or so.
+1000 !



From caolanm at redhat.com  Sat Nov 24 11:41:24 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Sat, 24 Nov 2007 11:41:24 +0000
Subject: hypenation rules in openoffice.org
In-Reply-To: <ufazlx4sfgj.fsf@epithumia.math.uh.edu>
References: <1195840043.5226.109.camel@Jehannum>
	<ufazlx4sfgj.fsf@epithumia.math.uh.edu>
Message-ID: <1195904484.5226.237.camel@Jehannum>


On Fri, 2007-11-23 at 17:35 -0600, Jason L Tibbitts III wrote:
> If these are Java packages then it would also be good if we had
> someone with knowledge of Java onboard to help with questions that
> crop up arising from Java packaging issues.

No java involved.

C.



From buildsys at redhat.com  Sat Nov 24 12:53:29 2007
From: buildsys at redhat.com (Build System)
Date: Sat, 24 Nov 2007 07:53:29 -0500
Subject: rawhide report: 20071124 changes
Message-ID: <200711241253.lAOCrTbB018485@porkchop.devel.redhat.com>

New package batik
	Scalable Vector Graphics for Java

New package bmpx
	Beep Media Player eXperimental

New package hyphen
	A text hyphenation library

New package nautilus-share
	Easy sharing folder via Samba (CIFS protocol)

New package python-enum
	Robust enumerated type support in Python

New package uniconvertor
	Universal vector graphics translator

New package xmlgraphics-commons
	XML Graphics Commons


 
Updated Packages:

PyKDE-3.16.0-9.fc9
------------------
* Fri Nov 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.16.0-9
- sip-4.7 patch (#396441)

acpid-1.0.6-4.fc9
-----------------
* Fri Nov 23 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-4.fc9
- Removed old logrotate file
- Fixed socket leak (#394431)
- Fixed dumping useless info to log (#389581)

coreutils-6.9-14.fc9
--------------------
* Fri Nov 23 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-14
- fixed bug in handling YYYYMMDD date format with relative
  signed offset(#377821)

eclipse-1:3.3.1.1-10.fc9
------------------------
* Fri Nov 23 2007 Andrew Overholt <overholt at redhat.com> 3.3.1.1-10
- Move eclipse.ini for real.

* Fri Nov 23 2007 Andrew Overholt <overholt at redhat.com> 3.3.1.1-9
- Move eclipse.ini in %files section.

* Thu Nov 22 2007 Andrew Overholt <overholt at redhat.com> 3.3.1.1-8
- Re-enable gcj_support.

evolution-2.21.2-2.fc9
----------------------
* Fri Nov 23 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.2-2.fc9
- Rebuild against newer libpisync.so.
gdb-6.7.1-5.fc9
---------------
* Sat Nov 24 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.7.1-5
- Reduce the excessive gcc-* packages dependencies outside of mock/koji.

gdesklets-0.36-0.3.beta.fc9
---------------------------
* Fri Nov 23 2007 Luya Tshimbalanga <luya_tfz at thefinalzone.com> - 0.36.0-3.beta
- Changed url adress
- Added patch for dialog
ghc-6.8.1-2.fc9
---------------
* Fri Nov 23 2007 Bryan O'Sullivan <bos at serpentine.com> - 6.8.1-2
- Exclude alpha

ghostscript-8.61-1.fc9
----------------------
* Fri Nov 23 2007 Tim Waugh <twaugh at redhat.com> 8.61-1
- 8.61.

* Tue Oct 23 2007 Tim Waugh <twaugh at redhat.com> 8.60-5
- Applied patch from upstream to fix CVE-2007-2721 (bug #346511).

* Tue Oct 09 2007 Tim Waugh <twaugh at redhat.com> 8.60-4
- Marked localized man pages as %lang (bug #322321).

gnome-pilot-2.0.15-11.fc9
-------------------------
* Fri Nov 23 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-11.fc9
- Rebuld against newer libpisync.so.

* Wed Oct 03 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-10.fc8
- Remove the GConf schemas in preun, not postun (RH bug #246776).

* Wed Sep 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.0.15-9
- Fix the build with new intltool

gnome-pilot-conduits-2.0.15-5.fc9
---------------------------------
* Fri Nov 23 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-5.fc9
- Rebuild against newer libpisync.so.

gnome-web-photo-0.3-7.fc9
-------------------------
* Fri Nov 23 2007 - Bastien Nocera <bnocera at redhat.com> - 0.3-7
- Rebuilding against xulrunner will require a lot of porting,
  disable for now

* Fri Nov 16 2007 - Bastien Nocera <bnocera at redhat.com> - 0.3-6
- Try to rebuild with xulrunner

gtk2hs-0.9.12.1-6.fc9
---------------------
* Fri Nov 23 2007 Bryan O'Sullivan <bos at serpentine.com> - 0.9.12.1-6
* Exclude alpha

* Fri Nov 09 2007 Bryan O'Sullivan <bos at serpentine.com> - 0.9.12.1-5
* Bump revision number

hunspell-ee-0.20030606-2.fc9
----------------------------
* Fri Nov 23 2007 Caolan McNamara <caolanm at redhat.com> - 0.20030606-2
- package hyphenation rules
hunspell-hr-1:0.20040608-2.fc9
------------------------------

kmenu-gnome-0.6.9-2.fc9
-----------------------
* Wed Nov 21 2007 Chitlesh Goorah <chitlesh at fedoraproject.org>- 0.6.9-2
- new upstream release

* Sat Nov 03 2007 Ariszlo <ariszlo at gmail.com> - 0.6.9-1
- release 0.6.9
- Replaced fc5-hide-bug196275.menu with fedora-administration.menu
- Replaced remove-system-administration.patch with fedora-administration.patch
- Moved GParted, Live Install and all Server Settings into Administration
- Replaced icon-office.png with redhat-office.png
- Removed printer.png -> gnome-dev-printer.png symlinks

less-416-1.fc9
--------------
* Fri Nov 23 2007 Zdenek Prikryl <zprikryl at redhat.com> - 416-1
- Update to 416
- Fixed SIGABORT caused by UTF-8 related bug
- Resolves #395591

* Wed Nov 21 2007 Zdenek Prikryl <zprikryl at redhat.com> - 415-1
- Update to 415

* Tue Nov 13 2007 Ivana Varekova <varekova at redhat.com> - 409-2
- remove which usage (#312591)

mail-notification-4.1-5.fc9
---------------------------
* Fri Nov 23 2007 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 4.1-5
- Rebuild against evo 2.21

mutt-5:1.5.17-2.fc9
-------------------
* Fri Nov 23 2007 Miroslav Lichvar <mlichvar at redhat.com> 5:1.5.17-2
- don't ignore $from in batch send mode (#392861)
- check Maildir for not being NULL when expanding '='-paths
- prevent mailto parsing buffer overflow by ignoring too long header
- use strtok_r() to parse mailto: links, not strtok()
- update UPDATING

nspluginwrapper-0.9.91.5-13.fc9
-------------------------------
* Fri Nov 23 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-13
- rebuilt against xulrunner

* Tue Nov 06 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-12
- more fixes from review by security standards team

* Wed Oct 31 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-11
- added fixes from review by security standards team

pam_ssh-1.92-3.fc9
------------------
* Thu Nov 15 2007 Martin Ebourne <martin at zepler.org> - 1.92-3
- Added SELinux policy module

system-config-rootpassword-1.99.2-1.fc9
---------------------------------------
* Wed Nov 21 2007 Lubomir Kundrak <lkundrak at redhat.com - 1.99.2-1
- New versions, with two new translations and more correct desktop file
- pygtk2 is actually not needed, s-c-r happily runs in text mode

telepathy-glib-0.7.0-1.fc9
--------------------------
* Fri Nov 23 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.7.0-1
- Update to 0.7.0.
- Drop unstable-static subpackage.
- Bump min. versions of dbus-devel & dbus-glib-devel.

tog-pegasus-2:2.7.0-2.fc9
-------------------------
* Fri Nov 23 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 2:2.7.0-2
- Fix OpenPegasus SRPM fails to build Test RPM 
  Resolves: #391961

* Mon Nov 19 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 2:2.7.0-1
- Update to upstream version 2.7.0
- Unhide some cmpi classes, package cmpi C++ headers
- Fix multiarch conflicts
  Resolves: #343311
- Add libcmpiCppImpl.so (symlink to libcmpiCppImpl.so.1)
  Resolves: #366871

* Tue Oct 09 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 2:2.6.1-2
- Fix files permissions
  Resolves: #200906

vinagre-0.3-3.fc9
-----------------
* Fri Nov 23 2007 - Bastien Nocera <bnocera at redhat.com> - 0.3-3
- Fix crasher when passing broken options on the command-line (#394671)
wxMaxima-0.7.3a-1.fc9
---------------------
* Fri Nov 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.7.3a-1
- wxMaxima-0.7.3a

* Wed Oct 17 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.7.3-4.1
- inline plotting of wxMaxima doesn't work in f7 (#339161)

xfce4-cpugraph-plugin-0.4.0-1.fc9
---------------------------------
* Sat Nov 24 2007 Christoph Wickert <fedora christoph-wickert de> - 0.4.0-1
- Update to 0.4.0
- Remove asneeded patch, fixed upstream
- drop --disable-static

xfce4-notes-plugin-1.6.0-1.fc9
------------------------------
* Sat Nov 24 2007 Christoph Wickert <fedora christoph-wickert de> - 1.6.0-1
- Update to 1.6.0

xfce4-sensors-plugin-0.10.99.2-2.fc9
------------------------------------
* Mon Nov 19 2007 Christoph Wickert <fedora christoph-wickert de> - 0.10.99.2-2
- Add Hans de Goede's patch for lm_sensors-3.0.0-RC1

* Wed Nov 07 2007 Christoph Wickert <fedora christoph-wickert de> - 0.10.99.2-1
- Update to 0.10.99.2

* Sat Oct 27 2007 Christoph Wickert <fedora christoph-wickert de> - 0.10.99.1-1
- Update to 0.10.99.1
- Require hddtemp because it is supported now

xsane-0.995-1.fc9
-----------------
* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> - 0.995-1
- version 0.995
- remove obsolete gimp2.0, medium-definitions, showeulaonce patches

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com>
- explicitely enable building the gimp plugin in configure call
- reorder spec file sections

xtide-2.9.4-3.fc9
-----------------
* Fri Nov 23 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.9.4-3
- Update harmonics data to 20071122.

zlib-1.2.3-16.fc9
-----------------
* Fri Nov 23 2007 Ivana Varekova <varekova at redhat.com> - 1.2.3-16
- remove minizip headers to minizip-devel
- spec file cleanup
- fix minizip.pc file

Broken deps for i386
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	conky - 1.4.8-1.fc9.i386 requires libaudacious.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	telepathy-idle - 0.1.1-3.fc8.i386 requires telepathy-glib-unstable-static >= 0:0.5.9



Broken deps for x86_64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.x86_64 requires libaudacious.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	telepathy-idle - 0.1.1-3.fc8.x86_64 requires telepathy-glib-unstable-static >= 0:0.5.9



Broken deps for ppc
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	conky - 1.4.8-1.fc9.ppc requires libaudacious.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo
	telepathy-idle - 0.1.1-3.fc8.ppc requires telepathy-glib-unstable-static >= 0:0.5.9



Broken deps for ppc64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.ppc64 requires libaudacious.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	telepathy-idle - 0.1.1-3.fc8.ppc64 requires telepathy-glib-unstable-static >= 0:0.5.9





From tcallawa at redhat.com  Sat Nov 24 13:44:22 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sat, 24 Nov 2007 08:44:22 -0500
Subject: RFE: rpmlint
In-Reply-To: <20071124091616.GA2577@free.fr>
References: <1195846898.12419.32.camel@localhost6.localdomain6>
	<f4586a2e0711232054h53f95ee5m3bbd94ad6e558ce2@mail.gmail.com>
	<20071124091616.GA2577@free.fr>
Message-ID: <1195911862.6663.27.camel@localhost.localdomain>


On Sat, 2007-11-24 at 10:16 +0100, Patrice Dumas wrote:
> On Sat, Nov 24, 2007 at 10:24:21AM +0530, Parag N(????) wrote:
> > Hi,
> 
> > > (http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors and
> > > http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues ) but they
> > 
> >  When I started with Fedora Project and started reviewing package I
> > was in need of common rpmlint messages listed on some page for easy
> > look back to them for how to solve them and ask packager/submitter to
> > fix those rpmlint messages.
> >   Later on as I got used to with reviewing packages and rpmlint output
> > I left updating that page. But If you want some more messages and
> > their fixes should be listed there then I will do that.
> 
> Parag, could you please merge your page with the
> http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues
> page?

I don't think he can, because he doesn't have ACL access to anything
below Packaging/... We should probably move that page to:

http://fedoraproject.org/wiki/PackageMaintainers/CommonRpmlintIssues/

~spot



From panemade at gmail.com  Sat Nov 24 14:08:07 2007
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Sat, 24 Nov 2007 19:38:07 +0530
Subject: RFE: rpmlint
In-Reply-To: <1195911862.6663.27.camel@localhost.localdomain>
References: <1195846898.12419.32.camel@localhost6.localdomain6>
	<f4586a2e0711232054h53f95ee5m3bbd94ad6e558ce2@mail.gmail.com>
	<20071124091616.GA2577@free.fr>
	<1195911862.6663.27.camel@localhost.localdomain>
Message-ID: <f4586a2e0711240608k20dcb228w590d6e446c0f40f6@mail.gmail.com>

Hi,

On Nov 24, 2007 7:14 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
>
> On Sat, 2007-11-24 at 10:16 +0100, Patrice Dumas wrote:
> > On Sat, Nov 24, 2007 at 10:24:21AM +0530, Parag N(????) wrote:
> > > Hi,
> >
> > > > (http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors and
> > > > http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues ) but they
> > >
> > >  When I started with Fedora Project and started reviewing package I
> > > was in need of common rpmlint messages listed on some page for easy
> > > look back to them for how to solve them and ask packager/submitter to
> > > fix those rpmlint messages.
> > >   Later on as I got used to with reviewing packages and rpmlint output
> > > I left updating that page. But If you want some more messages and
> > > their fixes should be listed there then I will do that.
> >
> > Parag, could you please merge your page with the
> > http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues
> > page?
>
> I don't think he can, because he doesn't have ACL access to anything
> below Packaging/... We should probably move that page to:
>
> http://fedoraproject.org/wiki/PackageMaintainers/CommonRpmlintIssues/
     I will be happy spot, if you will do that.
Regards,
Parag.



From tcallawa at redhat.com  Sat Nov 24 14:28:15 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sat, 24 Nov 2007 09:28:15 -0500
Subject: RFE: rpmlint
In-Reply-To: <f4586a2e0711240608k20dcb228w590d6e446c0f40f6@mail.gmail.com>
References: <1195846898.12419.32.camel@localhost6.localdomain6>
	<f4586a2e0711232054h53f95ee5m3bbd94ad6e558ce2@mail.gmail.com>
	<20071124091616.GA2577@free.fr>
	<1195911862.6663.27.camel@localhost.localdomain>
	<f4586a2e0711240608k20dcb228w590d6e446c0f40f6@mail.gmail.com>
Message-ID: <1195914495.6663.29.camel@localhost.localdomain>


On Sat, 2007-11-24 at 19:38 +0530, Parag N(????) wrote:
> Hi,
> 
> On Nov 24, 2007 7:14 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
> >
> > On Sat, 2007-11-24 at 10:16 +0100, Patrice Dumas wrote:
> > > On Sat, Nov 24, 2007 at 10:24:21AM +0530, Parag N(????) wrote:
> > > > Hi,
> > >
> > > > > (http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors and
> > > > > http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues ) but they
> > > >
> > > >  When I started with Fedora Project and started reviewing package I
> > > > was in need of common rpmlint messages listed on some page for easy
> > > > look back to them for how to solve them and ask packager/submitter to
> > > > fix those rpmlint messages.
> > > >   Later on as I got used to with reviewing packages and rpmlint output
> > > > I left updating that page. But If you want some more messages and
> > > > their fixes should be listed there then I will do that.
> > >
> > > Parag, could you please merge your page with the
> > > http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues
> > > page?
> >
> > I don't think he can, because he doesn't have ACL access to anything
> > below Packaging/... We should probably move that page to:
> >
> > http://fedoraproject.org/wiki/PackageMaintainers/CommonRpmlintIssues/
>      I will be happy spot, if you will do that.

All done.

~spot



From fedora at camperquake.de  Sat Nov 24 15:29:07 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 24 Nov 2007 16:29:07 +0100
Subject: Key event weirdness with xterm/claws-mail
Message-ID: <20071124162907.6a7b9626@lain.camperquake.de>

Hi.

I just notices something quite strange on my rawhide system. All of
the following is in a gnome session (started via startx):

I have a claws-mail instance in the background, and an xterm in the foreground
xterm has focus, and shows a man-page.
If I scroll in the man page (using the cursor keys) less scrolls, naturally.
However, if my mouse cursor is outside the xterm window (but inside the
inactive claws-mail window), the selection bar in my mailbox _also_ scrolls.

Looks like both windows get the key events.

Single press key events just reach the xterm window. claws just starts
scrolling starts when the automatic key repetition kicks in.

Judging from the less scrolling speed every other key event does not
reach xterm, but claws instead.

Any ideas what would cause this, and how to debug what is going on?



From jkeating at redhat.com  Sat Nov 24 17:01:04 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 24 Nov 2007 12:01:04 -0500
Subject: WTF? Inaccessible bug reports?
In-Reply-To: <4747C1EC.6090404@fedoraproject.org>
References: <56456.192.54.193.53.1195830272.squirrel@rousalka.dyndns.org>
	<20071123200333.32033eef@redhat.com>
	<4747C1EC.6090404@fedoraproject.org>
Message-ID: <20071124120104.7287cdb9@redhat.com>

On Sat, 24 Nov 2007 11:47:16 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> Can't you blacklist specific packages?

kickstart syntax allows you to exclude packages from repos.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071124/d04c961e/attachment.sig>

From mattdm at mattdm.org  Sat Nov 24 18:02:17 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 24 Nov 2007 13:02:17 -0500
Subject: joe
In-Reply-To: <1195870097.14939.4.camel@localhost6.localdomain6>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
	<1195870097.14939.4.camel@localhost6.localdomain6>
Message-ID: <20071124180217.GA19358@jadzia.bu.edu>

On Fri, Nov 23, 2007 at 07:08:17PM -0700, Richi Plana wrote:
> It's not on the DVD image. I usually need a text editor before I can
> even connect to the network (edit yum .repo). At least I could find the

It's worthwhile to learn enough vi to suit this purpose. (It's actually an
excellent config-file editor.) That's pretty much guaranteed to *always* be
there.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From Lam at Lam.pl  Sat Nov 24 18:40:11 2007
From: Lam at Lam.pl (Leszek Matok)
Date: Sat, 24 Nov 2007 19:40:11 +0100
Subject: joe
In-Reply-To: <20071124180217.GA19358@jadzia.bu.edu>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
	<1195870097.14939.4.camel@localhost6.localdomain6>
	<20071124180217.GA19358@jadzia.bu.edu>
Message-ID: <20071124194011.3caa2f78@pensja.lam.pl>

Dnia 2007-11-24, o godz. 13:02:17 Matthew Miller <mattdm at mattdm.org>
napisa?(a):
 
> It's worthwhile to learn enough vi to suit this purpose. (It's actually an
> excellent config-file editor.)
I know vi much past the point when I was able to edit fedora.repo or
ifcfg-eth0. I still think it's a sick editor and use it only when I have to
(like no network to get joe from). I wouldn't recommend learning vi to anyone
who doesn't already know it.

And yes, I'm from the joe (and tcsh) front. But I don't cry for lack of normal
editor on the DVD for people who mess up their Xorg config - they have nano,
which is an excellent choice for newbies (especially if they knew pico). If
there's no place for joe - that's alright. I manage.

Lam
PS. I don't mean to start any editor war, but that's been torturing me for
ages - can vi or sed search and replace a string containing a newline? (joe
does this and I know two vi users using joe only for it, after I told them
about it). I'm really courious, you can reply me privately if you know the
answer :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071124/8ef1eb31/attachment.sig>

From martin.sourada at seznam.cz  Sat Nov 24 20:54:36 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Sat, 24 Nov 2007 21:54:36 +0100
Subject: Firefox sets wrong encoding to directory listings?
Message-ID: <1195937676.5828.12.camel@pc-notebook>

Hi,

not sure if this is the right list, but I set up a http server for some
local network (so it is not accessible from outside) and would like to
have all the content in UTF-8 (I also use some non ISO-8859-1 characters
in file names), so I set up a HEADER.xhtml that is prepended to
directory listings (and the same file is included at the beginning of
the other pages) with this encoding settings:

<?xml version="1.0" encoding="UTF-8"?>
...
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<meta http-equiv="content-type" content="application/xhtml+xml;
charset=UTF-8"/>

So, I would suppose that browser detects the character encoding right
and selects UTF-8. However, while this is true for ordinal pages, for
directory listings it always selects ISO-8859-1. I also went through the
apache configuration files and tried both using AddDefaultCharset UTF-8
and not using it with the same result.

As you might noticed, I thought at first that this is a server issue,
but I just tried it in ELinks and it works as expected. So, where the
problem lies? I have problems with it when using epiphany or firefox.
Should I file a bug against firefox?

Thanks,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071124/0ad8cab5/attachment.sig>

From myfedora at richip.dhs.org  Sat Nov 24 21:10:06 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sat, 24 Nov 2007 14:10:06 -0700
Subject: joe
In-Reply-To: <20071124180217.GA19358@jadzia.bu.edu>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
	<1195870097.14939.4.camel@localhost6.localdomain6>
	<20071124180217.GA19358@jadzia.bu.edu>
Message-ID: <1195938606.19700.7.camel@localhost6.localdomain6>

On Sat, 2007-11-24 at 13:02 -0500, Matthew Miller wrote:
> On Fri, Nov 23, 2007 at 07:08:17PM -0700, Richi Plana wrote:
> > It's not on the DVD image. I usually need a text editor before I can
> > even connect to the network (edit yum .repo). At least I could find the
> 
> It's worthwhile to learn enough vi to suit this purpose. (It's actually an
> excellent config-file editor.) That's pretty much guaranteed to *always* be
> there.

Please, let's not let this thread become a text-editor thread. I'm sure
vi is an excellent editor, but I don't want to get distracted from the
process of getting joe onto the DVD.

Since you mentioned vi, I would say that I learned how to use it back in
the 90's and fall back onto it when other text editors like joe, pico,
emacs and nano aren't available. I just prefer the key combinations for
cursor control, block operations, file operations, window operations,
etc. of joe. Obviously cursor operations is what I do most often. That's
why I even set eclipse to use Emacs keybindings. Fortunately, bash
already uses similar combinations.
--

Richi Plana



From lsof at nodata.co.uk  Sat Nov 24 21:13:37 2007
From: lsof at nodata.co.uk (nodata)
Date: Sat, 24 Nov 2007 22:13:37 +0100
Subject: joe
In-Reply-To: <1195938606.19700.7.camel@localhost6.localdomain6>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
	<1195870097.14939.4.camel@localhost6.localdomain6>
	<20071124180217.GA19358@jadzia.bu.edu>
	<1195938606.19700.7.camel@localhost6.localdomain6>
Message-ID: <1195938817.7896.0.camel@sb-home>

Am Samstag, den 24.11.2007, 14:10 -0700 schrieb Richi Plana:
> On Sat, 2007-11-24 at 13:02 -0500, Matthew Miller wrote:
> > On Fri, Nov 23, 2007 at 07:08:17PM -0700, Richi Plana wrote:
> > > It's not on the DVD image. I usually need a text editor before I can
> > > even connect to the network (edit yum .repo). At least I could find the
> > 
> > It's worthwhile to learn enough vi to suit this purpose. (It's actually an
> > excellent config-file editor.) That's pretty much guaranteed to *always* be
> > there.
> 
> Please, let's not let this thread become a text-editor thread. 

Then file a bug.

If you don't want to use the text editor which is everywhere - which is vi - and you think that joe not being where you want it is a bug, bugzilla needs to know.



From myfedora at richip.dhs.org  Sat Nov 24 21:20:23 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Sat, 24 Nov 2007 14:20:23 -0700
Subject: joe
In-Reply-To: <1195938817.7896.0.camel@sb-home>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
	<1195870097.14939.4.camel@localhost6.localdomain6>
	<20071124180217.GA19358@jadzia.bu.edu>
	<1195938606.19700.7.camel@localhost6.localdomain6>
	<1195938817.7896.0.camel@sb-home>
Message-ID: <1195939223.19700.9.camel@localhost6.localdomain6>

On Sat, 2007-11-24 at 22:13 +0100, nodata wrote:
> Am Samstag, den 24.11.2007, 14:10 -0700 schrieb Richi Plana:
> > On Sat, 2007-11-24 at 13:02 -0500, Matthew Miller wrote:
> > > On Fri, Nov 23, 2007 at 07:08:17PM -0700, Richi Plana wrote:
> > > > It's not on the DVD image. I usually need a text editor before I can
> > > > even connect to the network (edit yum .repo). At least I could find the
> > > 
> > > It's worthwhile to learn enough vi to suit this purpose. (It's actually an
> > > excellent config-file editor.) That's pretty much guaranteed to *always* be
> > > there.
> > 
> > Please, let's not let this thread become a text-editor thread. 
> 
> Then file a bug.
> 
> <snipped> you think that joe not being where you want it is a bug, bugzilla needs to know.

Thanks. What component should that be filed against?
--

Richi Plana



From lsof at nodata.co.uk  Sat Nov 24 21:29:53 2007
From: lsof at nodata.co.uk (nodata)
Date: Sat, 24 Nov 2007 22:29:53 +0100
Subject: joe
In-Reply-To: <1195939223.19700.9.camel@localhost6.localdomain6>
References: <1195844152.12419.8.camel@localhost6.localdomain6>
	<1195865769.5026.1.camel@cutter>
	<1195870097.14939.4.camel@localhost6.localdomain6>
	<20071124180217.GA19358@jadzia.bu.edu>
	<1195938606.19700.7.camel@localhost6.localdomain6>
	<1195938817.7896.0.camel@sb-home>
	<1195939223.19700.9.camel@localhost6.localdomain6>
Message-ID: <1195939793.7896.3.camel@sb-home>


Am Samstag, den 24.11.2007, 14:20 -0700 schrieb Richi Plana:
> On Sat, 2007-11-24 at 22:13 +0100, nodata wrote:
> > Am Samstag, den 24.11.2007, 14:10 -0700 schrieb Richi Plana:
> > > On Sat, 2007-11-24 at 13:02 -0500, Matthew Miller wrote:
> > > > On Fri, Nov 23, 2007 at 07:08:17PM -0700, Richi Plana wrote:
> > > > > It's not on the DVD image. I usually need a text editor before I can
> > > > > even connect to the network (edit yum .repo). At least I could find the
> > > > 
> > > > It's worthwhile to learn enough vi to suit this purpose. (It's actually an
> > > > excellent config-file editor.) That's pretty much guaranteed to *always* be
> > > > there.
> > > 
> > > Please, let's not let this thread become a text-editor thread. 
> > 
> > Then file a bug.
> > 
> > <snipped> you think that joe not being where you want it is a bug, bugzilla needs to know.
> 
> Thanks. What component should that be filed against?
> --
> 
> Richi Plana
> 

Try LiveCD. If it's wrong, someone will move it.



From caillon at redhat.com  Sat Nov 24 23:02:02 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Sun, 25 Nov 2007 00:02:02 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <1195937676.5828.12.camel@pc-notebook>
References: <1195937676.5828.12.camel@pc-notebook>
Message-ID: <4748AD6A.5000804@redhat.com>

On 11/24/2007 09:54 PM, Martin Sourada wrote:
> Hi,
> 
> not sure if this is the right list, but I set up a http server for some
> local network (so it is not accessible from outside) and would like to
> have all the content in UTF-8 (I also use some non ISO-8859-1 characters
> in file names), so I set up a HEADER.xhtml that is prepended to
> directory listings (and the same file is included at the beginning of
> the other pages) with this encoding settings:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> ...
> <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
> <meta http-equiv="content-type" content="application/xhtml+xml;
> charset=UTF-8"/>
> 
> So, I would suppose that browser detects the character encoding right
> and selects UTF-8. However, while this is true for ordinal pages, for
> directory listings it always selects ISO-8859-1. I also went through the
> apache configuration files and tried both using AddDefaultCharset UTF-8
> and not using it with the same result.
> 
> As you might noticed, I thought at first that this is a server issue,
> but I just tried it in ELinks and it works as expected. So, where the
> problem lies? I have problems with it when using epiphany or firefox.
> Should I file a bug against firefox?

The server supplied headers will always win.  My guess is that Apache is 
sending Content-Type: text/html.  Which means your meta tags (why are 
you sending two of them!?!) will have no effect.  And since the document 
is text/html and being processed as such, your <?xml?> declaration also 
has no effect.



From caillon at redhat.com  Sat Nov 24 23:14:46 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Sun, 25 Nov 2007 00:14:46 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <4748AD6A.5000804@redhat.com>
References: <1195937676.5828.12.camel@pc-notebook>
	<4748AD6A.5000804@redhat.com>
Message-ID: <4748B066.8000304@redhat.com>

On 11/25/2007 12:02 AM, Christopher Aillon wrote:
> On 11/24/2007 09:54 PM, Martin Sourada wrote:
>> Hi,
>>
>> not sure if this is the right list, but I set up a http server for some
>> local network (so it is not accessible from outside) and would like to
>> have all the content in UTF-8 (I also use some non ISO-8859-1 characters
>> in file names), so I set up a HEADER.xhtml that is prepended to
>> directory listings (and the same file is included at the beginning of
>> the other pages) with this encoding settings:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> ...
>> <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
>> <meta http-equiv="content-type" content="application/xhtml+xml;
>> charset=UTF-8"/>
>>
>> So, I would suppose that browser detects the character encoding right
>> and selects UTF-8. However, while this is true for ordinal pages, for
>> directory listings it always selects ISO-8859-1. I also went through the
>> apache configuration files and tried both using AddDefaultCharset UTF-8
>> and not using it with the same result.
>>
>> As you might noticed, I thought at first that this is a server issue,
>> but I just tried it in ELinks and it works as expected. So, where the
>> problem lies? I have problems with it when using epiphany or firefox.
>> Should I file a bug against firefox?
> 
> The server supplied headers will always win.  My guess is that Apache is 
> sending Content-Type: text/html.  Which means your meta tags (why are 
> you sending two of them!?!) will have no effect.  And since the document 
> is text/html and being processed as such, your <?xml?> declaration also 
> has no effect.
> 

See also https://bugzilla.mozilla.org/show_bug.cgi?id=214952



From ianburrell at gmail.com  Sun Nov 25 00:17:41 2007
From: ianburrell at gmail.com (Ian Burrell)
Date: Sat, 24 Nov 2007 16:17:41 -0800
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <47440EA8.5060500@hhs.nl>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<47440EA8.5060500@hhs.nl>
Message-ID: <d91f09cd0711241617m2af956fcu18969f8872e5d0ba@mail.gmail.com>

On Nov 21, 2007 2:55 AM, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>
> Excellent then I can finally remove my rpm alias adding that as query format
> from my .bashrc :)
>

You don't need a bash alias.  You can set the default format in the
.rpmmacros file:

%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}

 -  Ian



From martin.sourada at seznam.cz  Sun Nov 25 10:12:58 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Sun, 25 Nov 2007 11:12:58 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <4748AD6A.5000804@redhat.com>
References: <1195937676.5828.12.camel@pc-notebook>
	<4748AD6A.5000804@redhat.com>
Message-ID: <1195985578.5828.24.camel@pc-notebook>

On Sun, 2007-11-25 at 00:02 +0100, Christopher Aillon wrote:
> The server supplied headers will always win.  My guess is that Apache is 
I have specifically set in /etc/httpd/conf/httpd.conf this directive

AddDefaultCharset UTF-8

> sending Content-Type: text/html.  Which means your meta tags (why are 
> you sending two of them!?!) will have no effect.  And since the document 
The first one is for xml, the second one is for text/html and the last
one is for application/xhtml+xml

> is text/html and being processed as such, your <?xml?> declaration also 
> has no effect.
> 

So, as far as I understand, Apache should be sending it with UTF-8
encoding as .html file (as opposed to e.g. index.xhtml, but I
tried .html as well) and Firefox should either detect the character
settings correctly or use the setting in metatags.

Here are the differences between various files which I discovered via
Page Info in Firefox:

File             Type                    Encoding
----------------------------------------------------
index.xhtml      application/xhtml+xml   UTF-8
index.html       text/html               UTF-8
dir. listing     text/html               ISO-8859-1

So, once again the basic question. Where is the problem? Do I need to
add some additional directive to Apache configuration to force it to use
UTF-8 encoding for directory listings or is it Firefox or Apache bug?

Thanks,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071125/f466fcbc/attachment.sig>

From che666 at gmail.com  Sun Nov 25 11:35:14 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Sun, 25 Nov 2007 12:35:14 +0100
Subject: NetworkManager-umts
Message-ID: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>

Hello!

Actually after beeing asked to bring the topic to the wiki:

http://fedoraproject.org/wiki/Features/NetworkManager-umts#preview

Feel free to add more informations and ideas to the entry.

kind regards,
Rudolf Kastl



From buildsys at redhat.com  Sun Nov 25 12:10:56 2007
From: buildsys at redhat.com (Build System)
Date: Sun, 25 Nov 2007 07:10:56 -0500
Subject: rawhide report: 20071125 changes
Message-ID: <200711251210.lAPCAusD031339@porkchop.devel.redhat.com>

New package libident
	New LibIdent C library


 
Updated Packages:

PyKDE-3.16.0-11.fc9
-------------------
* Sat Nov 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.16.0-11
- (Build)Requires: s/kdelibs/kdelibs3/, s/kdebase/kdebase3/

abcm2ps-5.6.1-2.fc9
-------------------
* Sat Nov 24 2007 Gerard Milmeister <gemi at bluewin.ch> - 5.6.1-1
- new release 5.6.1

atlascpp-0.6.1-1.fc9
--------------------
* Sat Nov 24 2007 Wart <wart at kobold.org> 0.6.1-1
- Update to 0.6.1
- Better download URL

chmsee-1.0.0-1.31.fc9
---------------------

clisp-2.43-3.fc9
----------------
* Sat Nov 24 2007 Gerard Milmeister <gemi at bluewin.ch> - 2.43-1
- new release 2.43

* Tue Oct 16 2007 Gerard Milmeister <gemi at bluewin.ch> - 2.42-1
- new release 2.42

* Fri May 04 2007 David Woodhouse <dwmw2 at infradead.org> - 2.41-6
- Revert to overriding stack limit in specfile

cups-pdf-2.4.6-4.fc9
--------------------
* Sat Nov 24 2007 Remi Collet <Fedora at FamilleCollet.com> 2.4.6-4
- add cups-pdf-desktop.patch to work with xdg prefs

cyphesis-0.5.14-1.fc9
---------------------
* Sat Nov 03 2007 Wart <wart at kobold.org> 0.5.14-1
- Update to 0.5.14

deluge-0.5.6.96-1.fc9
---------------------
* Sat Nov 24 2007 Peter Gordon <peter at thecodergeek.com> - 0.5.6.96-1
- Update to new upstream release candidate (0.5.7 RC2)
- Drop plugin error patch (fixed upstream):
  - plugin-not-found-OK.patch

* Sat Nov 24 2007 Peter Gordon <peter at thecodergeek.com> - 0.5.6.95-1
- Update to new upstream release candidate (0.5.7 RC)
- Update Source0 url
- Add upstream patch to prevent dying if plugin in prefs.state is not found on
  the filesystem:
  + plugin-not-found-OK.patch

freeciv-2.1.0-2.fc9
-------------------
* Sat Nov 24 2007 Brian Pepple <bpepple at fedoraproject.org> - 2.1.0-2
- Add patch to fix buffer overflow. (#397531)

* Sun Oct 28 2007 Brian Pepple <bpepple at fedoraproject.org> - 2.1.0-1
- Update to 2.1.0.
- Update urls.
- Update aifill & open patches.
- Remove old freeciv pixmap.
- Remove desktop patch.

gdesklets-calendar-0.52-1.fc9
-----------------------------
* Sat Nov 24 2007 Tyler Owen <tyler.l.owen at gmail.com> - 0.52-1
- Updated to 0.52

glib2-2.14.4-1.fc9
------------------
* Sat Nov 24 2007 Matthias Clasen <mclasen at redhat.com> - 2.14.4-1
- Update to 2.14.4

gnome-python2-2.20.1-1.fc9
--------------------------
* Sat Nov 24 2007 Matthew Barnes <mbarnes at redhat.com> - 2.20.1-1.fc9
- Update to 2.20.1

* Sun Sep 16 2007 Matthew Barnes <mbarnes at redhat.com> - 2.20.0-1.fc8
- Update to 2.20.0

* Wed Aug 29 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 2.19.2-3
- Rebuild for selinux ppc32 issue.

kernel-2.6.24-0.42.rc3.git1.fc9
-------------------------------
* Sat Nov 24 2007 David Woodhouse <dwmw2 at redhat.com>
- Fix fec_mpc52xx Ethernet driver to use the right skbs

* Wed Nov 21 2007 John W. Linville <linville at redhat.com>
- Resync wireless bits from upstream

* Wed Nov 21 2007 David Woodhouse <dwmw2 at redhat.com>
- Fix <linux/kd.h> in userspace.

kphotoalbum-3.1.0-1.fc9
-----------------------
* Sat Nov 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.1.0-1
- kphotoalbum-3.1.0

libtelepathy-0.3.1-2.fc9
------------------------
* Sat Nov 24 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.3.1-2
- Add BR on python.

* Fri Nov 23 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.3.1-1
- Update to 0.3.1.
- Add min. version needed for dbus & dbus-glib.
- Add BR on telepathy-glib-devel.

lm_sensors-3.0.0-1.fc9
----------------------
* Sat Nov 24 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 3.0.0-1
- New upstream release 3.0.0 (final)

lybniz-1.3.1-1.fc9
------------------
* Sat Nov 24 2007 Stewart Adam <s.adam at diffingo.com> 1.3.1-1
- Update to version 1.3.1

monit-4.10.1-4.fc9
------------------
* Sat Nov 24 2007 Stewart Adam <s.adam at diffingo.com> 4.10.1-4
- Substitute RPM macros for their real values in monit.conf (#397671)

namazu-2.0.17-5.fc9
-------------------
* Sun Nov 25 2007 Akira TAGOH <tagoh at redhat.com> - 2.0.17-5
- Move namazu.cgi from /var/www/cgi-bin to /usr/lib/namazu/ (#383521)

php-pecl-phar-1.2.3-2.fc9
-------------------------
* Sat Nov 24 2007 Remi Collet <Fedora at FamilleCollet.com> 1.2.3-2
- phar-make.patch back

* Fri Nov 23 2007 Remi Collet <Fedora at FamilleCollet.com> 1.2.3-1
- update to 1.2.3

psi-0.11-3.fc9
--------------
* Sat Nov 24 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.11-3
- Require qca-gnupg for GnuPG support

sear-0.6.3-6.fc9
----------------
* Sat Nov 24 2007 Wart <wart at kobold.org> 0.6.3-6
- Better .desktop file categories

shorewall-4.0.6-1.fc9
---------------------
* Sat Nov 24 2007 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.0.6-1
- Update to 4.0.6 plus patch-perl-4.0.6-1.diff upstream errata

starplot-0.95.4-3.fc9
---------------------

telepathy-idle-0.1.2-1.fc9
--------------------------
* Sat Nov 24 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.1.2-1
- Update to 0.1.2.
- Add BR for telepathy-glib-devel, libxslt, & python.

tkcvs-8.1-1.fc9
---------------
* Sat Nov 24 2007 Gerard Milmeister <gemi at bluewin.ch> - 8.1-1
- new release 8.1

wxGlade-0.6.1-1.fc9
-------------------
* Sat Nov 24 2007 ZC Miao <hellwolf.misty at gmail.com> - 0.6.1-1
- update to 0.6.1
- remove docs path patch, add a docs symlink instead

xmoto-edit-0.2.4-11.fc9
-----------------------
* Sat Nov 24 2007 Jon Ciesla <limb at jcomserv.net> 0.2.4-11
- Man page 404, fixed, will address upstream. BZ 389951.

Broken deps for i386
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	conky - 1.4.8-1.fc9.i386 requires libaudacious.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE



Broken deps for x86_64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.x86_64 requires libaudacious.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8



Broken deps for ppc
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	conky - 1.4.8-1.fc9.ppc requires libaudacious.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	monodevelop - 0.17-4.fc9.ppc requires boo



Broken deps for ppc64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.ppc64 requires libaudacious.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump





From fedora at leemhuis.info  Sun Nov 25 12:29:08 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 25 Nov 2007 13:29:08 +0100
Subject: EPEL report week 47 2007
Message-ID: <47496A94.20106@leemhuis.info>

http://fedoraproject.org/wiki/EPEL/Reports/Week47

= Weekly EPEL Summary =

Week 47/2007 

== Most important happenings ==

 * reminder: the EPEL meetings (and of course the mailing lists) are open to everyone; if you want to help EPEL by changing or improving something come join us, your voice will be heard; and if it comes to votings you opinion and your vote will count as well, even if you are not in the EPEL Steering Committee or in the SIG!

 *  [:KarstenWade:quaid]  writes in https://www.redhat.com/archives/epel-devel-list/2007-November/msg00111.html :

 {{{
We've done a fair job of attracting Fedora packagers to EPEL.

Now we need to get all the other audiences to get involved, as package
users, packagers, testers, and general community members:

* General end-users
* Academia and scientific users
* Software and hardware vendors
* General corporate users

I'll take the lead on this task, but boy do I need help and ideas.

Can we cook up a list of requirements or goals, so we can take some
ideas to f-marketing-l to discuss publicity etc.?
[...]
}}}

== Mailing list ==

=== Noteworthy discussions ===

 * Lot's of discussion about shipping mock 0.8.9 for EPEL-5 in https://www.redhat.com/archives/epel-devel-list/2007-November/msg00078.html, which in between resulted in it being shipped

== Meeting ==

=== Next Meeting ===

20071205 at 18:00 UTC in #fedora-meeting. (ten days from now)

=== Last weeks meeting ===

Log:

https://www.redhat.com/archives/epel-devel-list/2007-November/msg00121.html

Attendees:

 * [:DennisGilmore:dgilmore] 
 * [:ThorstenLeemhuis:knurd] 
 * [:MikeMcGrath:mmcgrath] 
 * [:KevinFenzi:nirik] 
 * [:KarstenWade:quaid] 
 * [:ManuelWolfshant:wolfy] 

Summary:

 * http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove testing stable move for EL4? -- nirik 

  * nirik> | I pulled a local mirror of the epel4 stuff, but I haven't tested yet... ; sorry for delaying. ;( 

  * nirik will try to do it over the weekend; knurd will help if needed

  * knurd> | I wondered if we normally should send a mail to the maintainer of the effected packages?  then they get a chance to say "don't push foo, because it has serious bugs" ;
  nirik> | perhaps a list of what would be pushed on the list and then a day or two for someone to say they don't want to push? 

  * We'll consider something like the above for the future; but for this EPEL4 push we just continue 

 * http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma 

  * skipped; feedback from people what they want sill wanted (mailing list or directly on the task page in the wiki, which is linked from the schedule)

 * http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- RHEL 5.1 (and 4.6) for the builders? 

  * we'll do it once centos 4.6/5.1 is out?; dgilmore will prepare it over the next few days. Many thanks for your help dgilmore!

 *  Free discussion around EPEL 

 * nirik> | FYI, I _still_ don't have my clamav rpm ready, but again I hope to work on it this weekend/holiday 

 * knurd> | are we happy with the state of EPEL?  
 mmcgrath> | we've been using it in Fedora since before it was official :)  its been great. 
 nirik> | yeah, I think so... lots of nice new branches in the last weeks... all the bugzilla perl rpms...  
 knurd> | I'd had hoped more people would become active with EPEL administrativa ; e.g. more people in the meetings 

 * quaid> | I don't mind remaining involved, but I'm feeling a bit like dead wood :) ... my skillz were most at use early on in putting people and processes together ; so, what I was wondering is if there is a need to refresh my seat  with someone new?  
 nirik> | well, we don't have many people at all interested it seems like right now...  
 quaid> | nirik: I don't mind keeping the body count up and keeping an eye on things; just don't want to be in the way of someone else ; 
 nirik> | if you are interested in stepping down, perhaps you could work on firing up more interested people to attend meetings first. ;) 

== Stats == 
 
=== General === 
 
Number of EPEL Contributors: 141 
 
=== EPEL 5 === 
 
Number of source packages: 819 
 
Number of binary packages:  1516  
 
There are 16 new Packages: 
 
 * debootstrap | Bootstrap a basic Debian GNU/Linux system 
 * ikarus | An incremental optimizing compiler for R6RS Scheme 
 * perl-DateTime | Date and time objects 
 * perl-DateTime-Format-Mail | Convert between DateTime and RFC2822/822 formats 
 * perl-DateTime-Format-W3CDTF | Parse and format W3CDTF datetime strings 
 * perl-Email-Abstract | Unified interface to mail representations 
 * perl-Email-Date | Find and format date headers 
 * perl-Email-Reply | Reply to an email message 
 * perl-Email-Send | Module for sending email 
 * perl-Mail-Box | Manage a mailbox, a folder with messages 
 * perl-Template-Toolkit | Template processing system 
 * perl-Test-Output | Utilities to test STDOUT and STDERR messages 
 * perl-Text-Autoformat | Automatic text wrapping and reformatting 
 * perl-XML-RSS | Perl module for managing RDF Site Summary (RSS) files 
 * qiv | Quick Image Viewer 
 * smstools | Tools to send and receive short messages through GSM modems or mobile phones 
 
=== EPEL 4 === 
 
Number of source packages: 447 
 
Number of binary packages:  895  
 
There are 3 new Packages: 
 
 * debootstrap | Bootstrap a basic Debian GNU/Linux system 
 * qiv | Quick Image Viewer 
 * smstools | Tools to send and receive short messages through GSM modems or mobile phones 
 
---- 
["CategoryEPELReports"]  



From gilboad at gmail.com  Sun Nov 25 13:15:09 2007
From: gilboad at gmail.com (Gilboa Davara)
Date: Sun, 25 Nov 2007 15:15:09 +0200
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <47440EA8.5060500@hhs.nl>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<47440EA8.5060500@hhs.nl>
Message-ID: <1195996509.20391.11.camel@gilboa-work-dev.localdomain>


On Wed, 2007-11-21 at 11:55 +0100, Hans de Goede wrote:
> Panu Matilainen wrote:
> > 
> > To put it shortly, I going to switch the default rpm queryformat to 
> > include package architecture (ie what you get now with
> > rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or so.
> > 
> > This is something that should've been done several releases ago really, 
> > but since it presumably breaks all sorts of scripts people have it's 
> > gotten delayed and delayed... The next major rpm.org release changes the 
> > default anyway, this is just an initial step to see what breaks.
> > 
> > If you know the change would break some of the buildsystem / other 
> > critical Fedora infrastructure, please holler NOW! I can delay the 
> > change a bit to allow critical pieces to be fixed first, but F9 *will* 
> > have the new queryformat so better prepare for it...
> > 
> > Fixing any scripts that absolutely rely on the old default is trivial: 
> > just them use explicit --qf "%{name}-%{version}-%{release}"
> > 
> 
> Excellent then I can finally remove my rpm alias adding that as query format 
> from my .bashrc :)
> 
> Regards,
> 
> Hans
> 
> 

No need to.
Just add %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
To your .rpmmacros.

- Gilboa



From lemenkov at gmail.com  Sun Nov 25 15:34:51 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 25 Nov 2007 18:34:51 +0300
Subject: New dependency in Fedora 8 - metacity
Message-ID: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>

Hello All!
After upgrading from F7 to F8 I found that someone imposes his own
evil wil on me and I was forced to install another bunch of useless
software - namely metacity and nodoka-metacity-theme. I am a user of
good old FVWM and don't understand why I can't remove metacity
completely (as I could do in F7).

-- 
With best regards!



From martin.sourada at seznam.cz  Sun Nov 25 15:54:36 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Sun, 25 Nov 2007 16:54:36 +0100
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
Message-ID: <1196006076.5828.30.camel@pc-notebook>

On Sun, 2007-11-25 at 16:34 +0100, Peter Lemenkov wrote:
> Hello All!
> After upgrading from F7 to F8 I found that someone imposes his own
> evil wil on me and I was forced to install another bunch of useless
> software - namely metacity and nodoka-metacity-theme. I am a user of
> good old FVWM and don't understand why I can't remove metacity
> completely (as I could do in F7).
> 
> -- 
> With best regards!
> 

I wonder... 

rpm -q --whatrequires nodoka-metacity-theme
nodoka-theme-gnome-0.3.2-2.fc8
fedora-gnome-theme-8.0.0-1.fc8
  these two are OK
metacity-2.20.0-3.fc8
  is this OK?

rpm -q --whatrequires metacity
nodoka-metacity-theme-0.3.2-2.fc8
  this is OK
system-config-display-1.0.51-4.fc8
firstboot-1.4.39-1.fc8
  imho these two should not require metacity
compiz-gnome-0.6.2-3.fc8
metacity-devel-2.20.0-3.fc8
  these two are OK

So we have there three somewhat questionable dependences on metacity or
nodoka-metacity-theme. Which one of these causes the problem for you?

Thanks,
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071125/23593ee3/attachment.sig>

From lemenkov at gmail.com  Sun Nov 25 16:21:18 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 25 Nov 2007 19:21:18 +0300
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196006076.5828.30.camel@pc-notebook>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
Message-ID: <adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>

2007/11/25, Martin Sourada <martin.sourada at seznam.cz>:


> So we have there three somewhat questionable dependences on metacity or
> nodoka-metacity-theme. Which one of these causes the problem for you?

I just want to remove metacity because it's not required for my system
-  nodoka-metacity-theme prevents me from removing metacity so I want
to remove it too but this one is tolerable. It costs only some
kilobytes in comparison with 11 megabytes of
*simple* *window manager, metacity.



-- 
With best regards!



From martin.sourada at seznam.cz  Sun Nov 25 16:32:20 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Sun, 25 Nov 2007 17:32:20 +0100
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
Message-ID: <1196008340.5828.35.camel@pc-notebook>

On Sun, 2007-11-25 at 17:21 +0100, Peter Lemenkov wrote:
> 2007/11/25, Martin Sourada <martin.sourada at seznam.cz>:
> 
> 
> > So we have there three somewhat questionable dependences on metacity or
> > nodoka-metacity-theme. Which one of these causes the problem for you?
> 
> I just want to remove metacity because it's not required for my system
> -  nodoka-metacity-theme prevents me from removing metacity so I want
> to remove it too but this one is tolerable. It costs only some
> kilobytes in comparison with 11 megabytes of
> *simple* *window manager, metacity.
> 
> 
>
> -- 
> With best regards!
> 

As far as I understand your problem, nodoka-metacity-theme is Fedora 8
default theme for metacity, so it needs metacity to be installed, but if
you do not want to use metacity it should be save to remove. It will
remove fedora-gnome-theme as well, but this dependency also OK. When you
do "yum remove metacity" which package appears in the list of packages
to remove that you don't want to remove?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071125/c3a0581b/attachment.sig>

From debarshi.ray at gmail.com  Sun Nov 25 16:57:47 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Sun, 25 Nov 2007 22:27:47 +0530
Subject: Packaging Starplot and related data files
In-Reply-To: <1194879094.3198.9.camel@localhost.localdomain>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
	<1194879094.3198.9.camel@localhost.localdomain>
Message-ID: <3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>

> Like you said, the modified .star files can't be distributed, but the
> ADC data files are fine to package as is, under the "Redistributable, no
> modification permitted".

Does this mean I can have a package whose spec file generates the
.star file from the catalog, so that installing starplot-gliese3
directly provides the .star file? (I think 'no'.)

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From lemenkov at gmail.com  Sun Nov 25 17:07:31 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 25 Nov 2007 20:07:31 +0300
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196008340.5828.35.camel@pc-notebook>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
	<1196008340.5828.35.camel@pc-notebook>
Message-ID: <adf480660711250907n7c91972i2e11b4fe4847b613@mail.gmail.com>

2007/11/25, Martin Sourada <martin.sourada at seznam.cz>:

> As far as I understand your problem, nodoka-metacity-theme is Fedora 8
> default theme for metacity, so it needs metacity to be installed, but if
> you do not want to use metacity it should be save to remove. It will
> remove fedora-gnome-theme as well, but this dependency also OK. When you
> do "yum remove metacity" which package appears in the list of packages
> to remove that you don't want to remove?

Take a look - metacity indirectly required for a number of useful packages:

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Removing:
 metacity                ppc        2.20.0-3.fc8     installed          10 M
Removing for dependencies:
 ImageMagick             ppc        6.3.5.9-1.fc8    installed          13 M
 PolicyKit-gnome         ppc        0.6-1.fc8        installed          77 k
 bluez-gnome             ppc        0.14-8.fc8       installed         283 k
 bluez-utils             ppc        3.20-4.fc8       installed         1.5 M
 evince                  ppc        2.20.1-1.fc8     installed         3.4 M
 evolution-data-server   ppc        1.12.1-2.fc8     installed          11 M
 fast-user-switch-applet  ppc        2.20.0-1.fc8     installed         1.7 M
 fedora-gnome-theme      noarch     8.0.0-1.fc8      installed          18 k
 firefox                 ppc        2.0.0.9-1.fc8    installed          41 M
 fvwm                    ppc        2.5.23-3.fc8     installed         6.8 M
 gimp                    ppc        2:2.4.1-1.fc8    installed          38 M
 gnome-desktop           ppc        2.20.1-2.fc8     installed         2.4 M
 gnome-mount             ppc        0.7-1.fc8        installed         508 k
 gnome-panel             ppc        2.20.1-2.fc8     installed          11 M
 gnome-vfs2              ppc        2.20.1-1.fc8     installed         4.1 M
 gnome-vfs2-devel        ppc        2.20.1-1.fc8     installed         1.9 M
 gnome-vfs2-obexftp      ppc        0.4-2.fc8        installed         143 k
 gtkhtml2                ppc        2.11.1-2.fc8     installed         552 k
 gutenprint-plugin       ppc        5.0.1-5.fc8      installed          21 k
 libbonoboui             ppc        2.20.0-1.fc8     installed         1.2 M
 libbonoboui-devel       ppc        2.20.0-1.fc8     installed         1.0 M
 libcroco-devel          ppc        0.6.1-3.fc8      installed         110 k
 libgnome                ppc        2.20.1-2.fc8     installed         3.7 M
 libgnome-devel          ppc        2.20.1-2.fc8     installed         537 k
 libgnomeui              ppc        2.20.1.1-1.fc8   installed         3.4 M
 libgnomeui-devel        ppc        2.20.1.1-1.fc8   installed         2.4 M
 librsvg2                ppc        2.18.2-2.fc8     installed         394 k
 librsvg2-devel          ppc        2.18.2-2.fc8     installed          92 k
 nautilus-extensions     ppc        2.20.0-6.fc8     installed          44 k
 nodoka-metacity-theme   noarch     0.3.2-2.fc8      installed          38 k
 nodoka-theme-gnome      noarch     0.3.2-2.fc8      installed          19 k

Transaction Summary
=============================================================================
Install      0 Package(s)
Update       0 Package(s)
Remove      32 Package(s)

Is this ok [y/N]:

The issue will be resoilved if we could remove metacity and related
stuff (nodoka-metacity-theme) wo touching other packages. I propose to
remove from nodoka-theme-gnome and from fedora-gnome-theme dependency
 on nodoka-metacity-theme.
-- 
With best regards!



From lkundrak at redhat.com  Sun Nov 25 17:39:06 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Sun, 25 Nov 2007 18:39:06 +0100
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <adf480660711250907n7c91972i2e11b4fe4847b613@mail.gmail.com>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
	<1196008340.5828.35.camel@pc-notebook>
	<adf480660711250907n7c91972i2e11b4fe4847b613@mail.gmail.com>
Message-ID: <1196012346.3568.154.camel@localhost.localdomain>


On Sun, 2007-11-25 at 20:07 +0300, Peter Lemenkov wrote:
> 2007/11/25, Martin Sourada <martin.sourada at seznam.cz>:
> 
> > As far as I understand your problem, nodoka-metacity-theme is Fedora 8
> > default theme for metacity, so it needs metacity to be installed, but if
> > you do not want to use metacity it should be save to remove. It will
> > remove fedora-gnome-theme as well, but this dependency also OK. When you
> > do "yum remove metacity" which package appears in the list of packages
> > to remove that you don't want to remove?
> 
> Take a look - metacity indirectly required for a number of useful packages:

...

Please raise a debug level, yum -d5 should be fine, so that we can see
what casued which package to be added to the list of packages to be
removed.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From lemenkov at gmail.com  Sun Nov 25 17:47:08 2007
From: lemenkov at gmail.com (Peter Lemenkov)
Date: Sun, 25 Nov 2007 20:47:08 +0300
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196012346.3568.154.camel@localhost.localdomain>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
	<1196008340.5828.35.camel@pc-notebook>
	<adf480660711250907n7c91972i2e11b4fe4847b613@mail.gmail.com>
	<1196012346.3568.154.camel@localhost.localdomain>
Message-ID: <adf480660711250947g6dfc4138o177faf606ca3ab24@mail.gmail.com>

2007/11/25, Lubomir Kundrak <lkundrak at redhat.com>:
> > Take a look - metacity indirectly required for a number of useful packages:

> Please raise a debug level, yum -d5 should be fine, so that we can see
> what casued which package to be added to the list of packages to be
> removed.

Here it is.
http://peter.fedorapeople.org/yum_metacity.log

nodoka-theme-gnome requires: nodoka-metacity-theme
fedora-gnome-theme requires: nodoka-metacity-theme

-- 
With best regards!



From lsof at nodata.co.uk  Sun Nov 25 17:56:01 2007
From: lsof at nodata.co.uk (nodata)
Date: Sun, 25 Nov 2007 18:56:01 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <1195985578.5828.24.camel@pc-notebook>
References: <1195937676.5828.12.camel@pc-notebook>
	<4748AD6A.5000804@redhat.com>  <1195985578.5828.24.camel@pc-notebook>
Message-ID: <1196013361.2719.19.camel@sb-home>


Am Sonntag, den 25.11.2007, 11:12 +0100 schrieb Martin Sourada:
> On Sun, 2007-11-25 at 00:02 +0100, Christopher Aillon wrote:
> > The server supplied headers will always win.  My guess is that Apache is 
> I have specifically set in /etc/httpd/conf/httpd.conf this directive
> 
> AddDefaultCharset UTF-8
> 
> > sending Content-Type: text/html.  Which means your meta tags (why are 
> > you sending two of them!?!) will have no effect.  And since the document 
> The first one is for xml, the second one is for text/html and the last
> one is for application/xhtml+xml
> 
> > is text/html and being processed as such, your <?xml?> declaration also 
> > has no effect.
> > 
> 
> So, as far as I understand, Apache should be sending it with UTF-8
> encoding as .html file (as opposed to e.g. index.xhtml, but I
> tried .html as well) and Firefox should either detect the character
> settings correctly or use the setting in metatags.
> 
> Here are the differences between various files which I discovered via
> Page Info in Firefox:
> 
> File             Type                    Encoding
> ----------------------------------------------------
> index.xhtml      application/xhtml+xml   UTF-8
> index.html       text/html               UTF-8
> dir. listing     text/html               ISO-8859-1
> 
> So, once again the basic question. Where is the problem? Do I need to
> add some additional directive to Apache configuration to force it to use
> UTF-8 encoding for directory listings or is it Firefox or Apache bug?
> 
> Thanks,
> Martin
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

What character set does your filesystem use?

What does Apache display if you create a file with a Japanese filename?
Copy and paste from yahoo.jp to test.



From lsof at nodata.co.uk  Sun Nov 25 17:56:01 2007
From: lsof at nodata.co.uk (nodata)
Date: Sun, 25 Nov 2007 18:56:01 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <1195985578.5828.24.camel@pc-notebook>
References: <1195937676.5828.12.camel@pc-notebook>
	<4748AD6A.5000804@redhat.com>  <1195985578.5828.24.camel@pc-notebook>
Message-ID: <1196013361.2719.19.camel@sb-home>


Am Sonntag, den 25.11.2007, 11:12 +0100 schrieb Martin Sourada:
> On Sun, 2007-11-25 at 00:02 +0100, Christopher Aillon wrote:
> > The server supplied headers will always win.  My guess is that Apache is 
> I have specifically set in /etc/httpd/conf/httpd.conf this directive
> 
> AddDefaultCharset UTF-8
> 
> > sending Content-Type: text/html.  Which means your meta tags (why are 
> > you sending two of them!?!) will have no effect.  And since the document 
> The first one is for xml, the second one is for text/html and the last
> one is for application/xhtml+xml
> 
> > is text/html and being processed as such, your <?xml?> declaration also 
> > has no effect.
> > 
> 
> So, as far as I understand, Apache should be sending it with UTF-8
> encoding as .html file (as opposed to e.g. index.xhtml, but I
> tried .html as well) and Firefox should either detect the character
> settings correctly or use the setting in metatags.
> 
> Here are the differences between various files which I discovered via
> Page Info in Firefox:
> 
> File             Type                    Encoding
> ----------------------------------------------------
> index.xhtml      application/xhtml+xml   UTF-8
> index.html       text/html               UTF-8
> dir. listing     text/html               ISO-8859-1
> 
> So, once again the basic question. Where is the problem? Do I need to
> add some additional directive to Apache configuration to force it to use
> UTF-8 encoding for directory listings or is it Firefox or Apache bug?
> 
> Thanks,
> Martin
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

What character set does your filesystem use?

What does Apache display if you create a file with a Japanese filename?
Copy and paste from yahoo.jp to test.



From pertusus at free.fr  Sun Nov 25 18:08:26 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 25 Nov 2007 19:08:26 +0100
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196008340.5828.35.camel@pc-notebook>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
	<1196008340.5828.35.camel@pc-notebook>
Message-ID: <20071125180826.GA2597@free.fr>

On Sun, Nov 25, 2007 at 05:32:20PM +0100, Martin Sourada wrote:
> > 
> 
> As far as I understand your problem, nodoka-metacity-theme is Fedora 8
> default theme for metacity, so it needs metacity to be installed, but if

I don't think so. A theme shouldn't require the window manager, it is the
other way around. Especially when it is used by a lot of other things.

I have filled
https://bugzilla.redhat.com/show_bug.cgi?id=398521

--
Pat



From tcallawa at redhat.com  Sun Nov 25 18:40:06 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 25 Nov 2007 13:40:06 -0500
Subject: Packaging Starplot and related data files
In-Reply-To: <3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
	<1194879094.3198.9.camel@localhost.localdomain>
	<3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>
Message-ID: <1196016006.15604.5.camel@localhost.localdomain>


On Sun, 2007-11-25 at 22:27 +0530, Debarshi 'Rishi' Ray wrote:
> > Like you said, the modified .star files can't be distributed, but the
> > ADC data files are fine to package as is, under the "Redistributable, no
> > modification permitted".
> 
> Does this mean I can have a package whose spec file generates the
> .star file from the catalog, so that installing starplot-gliese3
> directly provides the .star file? (I think 'no'.)

No, because we'd be distributing the .star files in that scenario.

~spot



From j.w.r.degoede at hhs.nl  Sun Nov 25 18:45:27 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 25 Nov 2007 19:45:27 +0100
Subject: Packaging Starplot and related data files
In-Reply-To: <1196016006.15604.5.camel@localhost.localdomain>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>	<1194879094.3198.9.camel@localhost.localdomain>	<3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>
	<1196016006.15604.5.camel@localhost.localdomain>
Message-ID: <4749C2C7.3050000@hhs.nl>

Tom "spot" Callaway wrote:
> On Sun, 2007-11-25 at 22:27 +0530, Debarshi 'Rishi' Ray wrote:
>>> Like you said, the modified .star files can't be distributed, but the
>>> ADC data files are fine to package as is, under the "Redistributable, no
>>> modification permitted".
>> Does this mean I can have a package whose spec file generates the
>> .star file from the catalog, so that installing starplot-gliese3
>> directly provides the .star file? (I think 'no'.)
> 
> No, because we'd be distributing the .star files in that scenario.
> 

What about a %post generating them under /var/lib ? I know this ain't pretty 
but I think it would solve the license issue.

Regards,

Hans



From tcallawa at redhat.com  Sun Nov 25 18:47:06 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 25 Nov 2007 13:47:06 -0500
Subject: Packaging Starplot and related data files
In-Reply-To: <4749C2C7.3050000@hhs.nl>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
	<1194879094.3198.9.camel@localhost.localdomain>
	<3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>
	<1196016006.15604.5.camel@localhost.localdomain>
	<4749C2C7.3050000@hhs.nl>
Message-ID: <1196016426.15604.8.camel@localhost.localdomain>


On Sun, 2007-11-25 at 19:45 +0100, Hans de Goede wrote:
> Tom "spot" Callaway wrote:
> > On Sun, 2007-11-25 at 22:27 +0530, Debarshi 'Rishi' Ray wrote:
> >>> Like you said, the modified .star files can't be distributed, but the
> >>> ADC data files are fine to package as is, under the "Redistributable, no
> >>> modification permitted".
> >> Does this mean I can have a package whose spec file generates the
> >> .star file from the catalog, so that installing starplot-gliese3
> >> directly provides the .star file? (I think 'no'.)
> > 
> > No, because we'd be distributing the .star files in that scenario.
> > 
> 
> What about a %post generating them under /var/lib ? I know this ain't pretty 
> but I think it would solve the license issue.

Hmm, normally I'm against this, but if they were ghosted in the %files,
the package would "own" them, and we wouldn't actually be distributing
them.

~spot



From j.w.r.degoede at hhs.nl  Sun Nov 25 19:11:38 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sun, 25 Nov 2007 20:11:38 +0100
Subject: Packaging Starplot and related data files
In-Reply-To: <1196016426.15604.8.camel@localhost.localdomain>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>	<1194879094.3198.9.camel@localhost.localdomain>	<3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>	<1196016006.15604.5.camel@localhost.localdomain>	<4749C2C7.3050000@hhs.nl>
	<1196016426.15604.8.camel@localhost.localdomain>
Message-ID: <4749C8EA.9080601@hhs.nl>

Tom "spot" Callaway wrote:
> On Sun, 2007-11-25 at 19:45 +0100, Hans de Goede wrote:
>> Tom "spot" Callaway wrote:
>>> On Sun, 2007-11-25 at 22:27 +0530, Debarshi 'Rishi' Ray wrote:
>>>>> Like you said, the modified .star files can't be distributed, but the
>>>>> ADC data files are fine to package as is, under the "Redistributable, no
>>>>> modification permitted".
>>>> Does this mean I can have a package whose spec file generates the
>>>> .star file from the catalog, so that installing starplot-gliese3
>>>> directly provides the .star file? (I think 'no'.)
>>> No, because we'd be distributing the .star files in that scenario.
>>>
>> What about a %post generating them under /var/lib ? I know this ain't pretty 
>> but I think it would solve the license issue.
> 
> Hmm, normally I'm against this, but if they were ghosted in the %files,
> the package would "own" them, and we wouldn't actually be distributing
> them.

I've done a little more research and I strongly believe that install time 
conversion is the answer. The data files in the format which we may distribute 
are not modified in essence. starplot comes with a conversion program to change 
them to its own format, I guess this is done once by a seperate conversion 
program and not on the fly when loading for performance reasons, so the 
converted files could be seen as cache files.

Regards,

Hans



From tcallawa at redhat.com  Sun Nov 25 19:16:59 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 25 Nov 2007 14:16:59 -0500
Subject: Packaging Starplot and related data files
In-Reply-To: <4749C8EA.9080601@hhs.nl>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
	<1194879094.3198.9.camel@localhost.localdomain>
	<3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>
	<1196016006.15604.5.camel@localhost.localdomain>	<4749C2C7.3050000@hhs.nl>
	<1196016426.15604.8.camel@localhost.localdomain>
	<4749C8EA.9080601@hhs.nl>
Message-ID: <1196018219.15604.10.camel@localhost.localdomain>


On Sun, 2007-11-25 at 20:11 +0100, Hans de Goede wrote:
> Tom "spot" Callaway wrote:
> > On Sun, 2007-11-25 at 19:45 +0100, Hans de Goede wrote:
> >> Tom "spot" Callaway wrote:
> >>> On Sun, 2007-11-25 at 22:27 +0530, Debarshi 'Rishi' Ray wrote:
> >>>>> Like you said, the modified .star files can't be distributed, but the
> >>>>> ADC data files are fine to package as is, under the "Redistributable, no
> >>>>> modification permitted".
> >>>> Does this mean I can have a package whose spec file generates the
> >>>> .star file from the catalog, so that installing starplot-gliese3
> >>>> directly provides the .star file? (I think 'no'.)
> >>> No, because we'd be distributing the .star files in that scenario.
> >>>
> >> What about a %post generating them under /var/lib ? I know this ain't pretty 
> >> but I think it would solve the license issue.
> > 
> > Hmm, normally I'm against this, but if they were ghosted in the %files,
> > the package would "own" them, and we wouldn't actually be distributing
> > them.
> 
> I've done a little more research and I strongly believe that install time 
> conversion is the answer. The data files in the format which we may distribute 
> are not modified in essence. starplot comes with a conversion program to change 
> them to its own format, I guess this is done once by a seperate conversion 
> program and not on the fly when loading for performance reasons, so the 
> converted files could be seen as cache files.

As long as we're not distributing the .star files, and the files are
owned by the package (and thus, removed upon uninstall), I'm ok with it.

~spot



From the.masch at gmail.com  Sun Nov 25 20:10:30 2007
From: the.masch at gmail.com (masch)
Date: Sun, 25 Nov 2007 15:10:30 -0500
Subject: Replacement gksudo
Message-ID: <93d66b780711251210h57a68422vd593eb5b6172d72b@mail.gmail.com>

Hi!
Can i use gksudo or another utility for ask root password in script?


Salu2..



From lsof at nodata.co.uk  Sun Nov 25 21:06:50 2007
From: lsof at nodata.co.uk (nodata)
Date: Sun, 25 Nov 2007 22:06:50 +0100
Subject: Replacement gksudo
In-Reply-To: <93d66b780711251210h57a68422vd593eb5b6172d72b@mail.gmail.com>
References: <93d66b780711251210h57a68422vd593eb5b6172d72b@mail.gmail.com>
Message-ID: <1196024810.2719.21.camel@sb-home>

Am Sonntag, den 25.11.2007, 15:10 -0500 schrieb masch:
> Hi!
> Can i use gksudo or another utility for ask root password in script?
> 
> 
> Salu2..
> 

Normally for scripts, you want keychain or perhaps ssh-agent, but that
won't prompt. Might fit your needs though.



From lsof at nodata.co.uk  Sun Nov 25 21:25:47 2007
From: lsof at nodata.co.uk (nodata)
Date: Sun, 25 Nov 2007 22:25:47 +0100
Subject: Replacement gksudo
In-Reply-To: <1196024810.2719.21.camel@sb-home>
References: <93d66b780711251210h57a68422vd593eb5b6172d72b@mail.gmail.com>
	<1196024810.2719.21.camel@sb-home>
Message-ID: <1196025947.11062.1.camel@sb-home>

Am Sonntag, den 25.11.2007, 22:06 +0100 schrieb nodata:
> Am Sonntag, den 25.11.2007, 15:10 -0500 schrieb masch:
> > Hi!
> > Can i use gksudo or another utility for ask root password in script?
> > 
> > 
> > Salu2..
> > 
> 
> Normally for scripts, you want keychain or perhaps ssh-agent, but that
> won't prompt. Might fit your needs though.
> 

Ack actually you will need to fiddle around with pam for this to work,
so best to ignore my answer.



From Martin.Sourada at seznam.cz  Sun Nov 25 22:09:00 2007
From: Martin.Sourada at seznam.cz (=?us-ascii?Q?Martin=20Sourada?=)
Date: Sun, 25 Nov 2007 23:09:00 +0100 (CET)
Subject: Firefox sets wrong encoding to directory listings?
Message-ID: <2446.3009-22798-1331156943-1196028540@seznam.cz>

On Sun, 2007-11-25 at 18:56 +0100, nodata wrote:
> What character set does your filesystem use?
> 
Should be UTF-8. It's ext3 on LVM with no special settings.

> What does Apache display if you create a file with a Japanese filename?
> Copy and paste from yahoo.jp to test.
> 

No need to copy and paste, I use scim for Japanese input ;-)

I created a file named "?" [kaze; wind]. When I try to access it with
firefox via vsftpd it has both wrong encoding and is inaccessible (the
link is both wrongly displayed and wrongly used, but when I manually 
write the character into location bar the file can be opened), when I 
access it with firefox via httpd (Apache) it is only wrongly displayed 
but works ok. If I manually set the encoding in firefox to UTF-8 the 
name is fixed both when accessed via vsftpd (which fixes the link as 
well) and via httpd. Just in case you are interested, the wrong string 
looks like "???".

Looks like both vsftpd and httpd (Apache) are not very UTF-8 friendly :-(

Thanks,
Martin



From lordmorgul at gmail.com  Sun Nov 25 22:45:48 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Sun, 25 Nov 2007 14:45:48 -0800
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <20071125180826.GA2597@free.fr>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>	<1196006076.5828.30.camel@pc-notebook>	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>	<1196008340.5828.35.camel@pc-notebook>
	<20071125180826.GA2597@free.fr>
Message-ID: <4749FB1C.2000301@gmail.com>

Patrice Dumas wrote:
> On Sun, Nov 25, 2007 at 05:32:20PM +0100, Martin Sourada wrote:
>> As far as I understand your problem, nodoka-metacity-theme is Fedora 8
>> default theme for metacity, so it needs metacity to be installed, but if
> 
> I don't think so. A theme shouldn't require the window manager, it is the
> other way around. Especially when it is used by a lot of other things.
> 
> I have filled
> https://bugzilla.redhat.com/show_bug.cgi?id=398521

The window manager is useful without that particular theme if it has an
alternative to default to.  If that particular theme is useful only to that
window manager, then the theme *should* require the window manager.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From pertusus at free.fr  Sun Nov 25 23:01:57 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 26 Nov 2007 00:01:57 +0100
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <4749FB1C.2000301@gmail.com>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<adf480660711250821r2ce45d27s910bf8b8dbab59dd@mail.gmail.com>
	<1196008340.5828.35.camel@pc-notebook>
	<20071125180826.GA2597@free.fr> <4749FB1C.2000301@gmail.com>
Message-ID: <20071125230156.GA3554@free.fr>

On Sun, Nov 25, 2007 at 02:45:48PM -0800, Andrew Farris wrote:
> Patrice Dumas wrote:
> > On Sun, Nov 25, 2007 at 05:32:20PM +0100, Martin Sourada wrote:
> >> As far as I understand your problem, nodoka-metacity-theme is Fedora 8
> >> default theme for metacity, so it needs metacity to be installed, but if
> > 
> > I don't think so. A theme shouldn't require the window manager, it is the
> > other way around. Especially when it is used by a lot of other things.
> > 
> > I have filled
> > https://bugzilla.redhat.com/show_bug.cgi?id=398521
> 
> The window manager is useful without that particular theme if it has an
> alternative to default to.  If that particular theme is useful only to that
> window manager, then the theme *should* require the window manager.

In that case it is also useful to other things since the fedora theme
and a gnome theme depend on it.

--
Pat



From bbbush.yuan at gmail.com  Mon Nov 26 00:56:59 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Mon, 26 Nov 2007 08:56:59 +0800
Subject: How to package an xulrunner application? Like chatzilla.
Message-ID: <76e72f800711251656u2531568k7f1ced7724926605@mail.gmail.com>

Hi,

How to package an xulrunner application? Like chatzilla and xulexplorer.

Thanks!


-- 
bbbush ^_^



From aoliva at redhat.com  Mon Nov 26 01:11:41 2007
From: aoliva at redhat.com (Alexandre Oliva)
Date: Sun, 25 Nov 2007 23:11:41 -0200
Subject: F8 is getting *really* sysadmin-hostile
In-Reply-To: <20071120120248.GA4596@dspnet.fr.eu.org> (Olivier Galibert's
	message of "Tue\, 20 Nov 2007 13\:02\:48 +0100")
References: <20071115160124.GA40056@dspnet.fr.eu.org>
	<1195143796.3140.110.camel@cookie.hadess.net>
	<20071120120248.GA4596@dspnet.fr.eu.org>
Message-ID: <orprxxizea.fsf@oliva.athome.lsd.ic.unicamp.br>

On Nov 20, 2007, Olivier Galibert <galibert at pobox.com> wrote:

> You may be interested to know that you can not use a non-predefined
> static ip address if you use kickstart.  Loader2 has dhcp mandatory is
> you use a kickstart file with no ip address given in it.

Actually, it's worse than that.  It uses dhcp *even if* there's a
fixed IP configuration in both the kickstart file and the boot command
line.  Caused me a lot of trouble when I tried to kickstart-install my
home dhcp server :-(

https://bugzilla.redhat.com/show_bug.cgi?id=374271

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From pferpaddy at hotmail.com  Mon Nov 26 02:03:20 2007
From: pferpaddy at hotmail.com (patrick quinn)
Date: Mon, 26 Nov 2007 02:03:20 +0000
Subject: PROJECT BLACKHAT
Message-ID: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>


hello team fedora
me and my team are curentuly working on a reactos (http://www.reactos.org) based os called blackhat which is open source and 100% free.blackhats party piece is its ability to run not only win32 but linux applications nativily.blackhat plays host to the latest open source and gnu software and environments .it will ultimately use the gnome interface as the default gui and have xgl alike abilites.i was wondering if you would be willing to put your name to this project amd give you very minor help and in exchange you will have permenant ad space at the top of are webpage and other fedora promotions troughout the os (eg in the welcome center).we will not ask anything of significance from you just giving blackhat some of that unmistakeable fedora charm.i personally am a huge fan of your os and hence the reason we have come to you.we would really aprecieate a reply be it negitive or positive
seasons greetings
team blackhat
 
_________________________________________________________________
Get the next generation of Windows Live services now!
http://get.live.com



From tcallawa at redhat.com  Mon Nov 26 02:42:24 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sun, 25 Nov 2007 21:42:24 -0500
Subject: PROJECT BLACKHAT
In-Reply-To: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
References: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
Message-ID: <1196044944.15604.16.camel@localhost.localdomain>


On Mon, 2007-11-26 at 02:03 +0000, patrick quinn wrote:
> hello team fedora
> me and my team are curentuly working on a reactos (http://www.reactos.org) based os called blackhat which is open source and 100% free.blackhats party piece is its ability to run not only win32 but linux applications nativily.blackhat plays host to the latest open source and gnu software and environments .it will ultimately use the gnome interface as the default gui and have xgl alike abilites.i was wondering if you would be willing to put your name to this project amd give you very minor help and in exchange you will have permenant ad space at the top of are webpage and other fedora promotions troughout the os (eg in the welcome center).we will not ask anything of significance from you just giving blackhat some of that unmistakeable fedora charm.i personally am a huge fan of your os and hence the reason we have come to you.we would really aprecieate a reply be it negitive or positive
> seasons greetings
> team blackhat

Patrick,

At this time, we only permit use of the Fedora trademark when the "spin"
is composed entirely from Fedora packages. As your OS is not based on
Fedora, it would not qualify.

Best of luck to you,

~spot



From kagesenshi.87 at gmail.com  Mon Nov 26 05:04:52 2007
From: kagesenshi.87 at gmail.com (Hikaru Amano)
Date: Mon, 26 Nov 2007 13:04:52 +0800
Subject: PROJECT BLACKHAT
In-Reply-To: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
References: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
Message-ID: <c44298520711252104r69ac2cbaj97d8ed21866c97b@mail.gmail.com>

On Nov 26, 2007 10:03 AM, patrick quinn <pferpaddy at hotmail.com> wrote:
>
>
> hello team fedora
> me and my team are curentuly working on a reactos (http://www.reactos.org) based
> os called blackhat which is open source and 100% free.blackhats party piece is its
> ability to run not only win32 but linux applications nativily.blackhat plays host to the
> latest open source and gnu software and environments .it will ultimately use the
> gnome interface as the default gui and have xgl alike abilites.i was wondering if you
> would be willing to put your name to this project amd give you very minor help and in
> exchange you will have permenant ad space at the top of are webpage and other
> fedora promotions troughout the os (eg in the welcome center).we will not ask
> anything of significance from you just giving blackhat some of that unmistakeable
> fedora charm.i personally am a huge fan of your os and hence the reason we have

by charm .. what did you mean?

> come to you.we would really aprecieate a reply be it negitive or positive
> seasons greetings
> team blackhat
>
> _________________________________________________________________
> Get the next generation of Windows Live services now!
> http://get.live.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331



From debarshi.ray at gmail.com  Mon Nov 26 06:50:34 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Mon, 26 Nov 2007 12:20:34 +0530
Subject: Packaging Starplot and related data files
In-Reply-To: <4749C8EA.9080601@hhs.nl>
References: <3170f42f0711112213l6bab5b39lb0b517c90496774d@mail.gmail.com>
	<1194879094.3198.9.camel@localhost.localdomain>
	<3170f42f0711250857r2ac6a592ydd0b8fe16f470a36@mail.gmail.com>
	<1196016006.15604.5.camel@localhost.localdomain>
	<4749C2C7.3050000@hhs.nl>
	<1196016426.15604.8.camel@localhost.localdomain>
	<4749C8EA.9080601@hhs.nl>
Message-ID: <3170f42f0711252250y58a3d1fdt93d856e7cf5f294c@mail.gmail.com>

> The data files in the format which we may distribute
> are not modified in essence. starplot comes with a conversion program to change
> them to its own format, I guess this is done once by a seperate conversion
> program and not on the fly when loading for performance reasons, so the
> converted files could be seen as cache files.

You are right, Hans. To avoid distributing the *.star files, because
they are modifications of the original catalog data files, StarPlot
generates them during installation using:

$ starpkg . --dest /usr/share/starplot

starpkg is basically a wrapper shell script invoking starconvert.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From bbbush.yuan at gmail.com  Mon Nov 26 07:36:52 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Mon, 26 Nov 2007 15:36:52 +0800
Subject: How to comment on a rawhide package?
Message-ID: <76e72f800711252336u76c7673ep4a8f23e5401d8179@mail.gmail.com>

Like in bodhi. :D

-- 
bbbush ^_^



From pertusus at free.fr  Mon Nov 26 08:39:41 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 26 Nov 2007 09:39:41 +0100
Subject: How to comment on a rawhide package?
In-Reply-To: <76e72f800711252336u76c7673ep4a8f23e5401d8179@mail.gmail.com>
References: <76e72f800711252336u76c7673ep4a8f23e5401d8179@mail.gmail.com>
Message-ID: <20071126083941.GB2673@free.fr>

On Mon, Nov 26, 2007 at 03:36:52PM +0800, Yuan Yijun wrote:
> Like in bodhi. :D

I'd say send a mail to the devel mailing list, or file a bug, since the
package has already hit the computers.

--
Pat



From fedora at camperquake.de  Mon Nov 26 08:47:39 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Nov 2007 09:47:39 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <2446.3009-22798-1331156943-1196028540@seznam.cz>
References: <2446.3009-22798-1331156943-1196028540@seznam.cz>
Message-ID: <20071126094739.71b6636e@dhcp03.addix.net>

Hi.

On Sun, 25 Nov 2007 23:09:00 +0100 (CET), Martin Sourada wrote:

> Looks like both vsftpd and httpd (Apache) are not very UTF-8
> friendly :-(

httpd and vsftpd do not care about UTF-8 when displaying files,
they just read the filename from the disk and push it to the
client. It's up to the client to interpret the data.
HTTP has the ability to send a charset with the data, while FTP
has not.

Using "HEAD <yoururl>" you can easily inspect the header information
sent by your HTTP server and look if it sets the charset information
correnctly. HEAD is part of the perl-libwww-perl package.



From aph at redhat.com  Mon Nov 26 09:44:15 2007
From: aph at redhat.com (Andrew Haley)
Date: Mon, 26 Nov 2007 09:44:15 +0000
Subject: Debuginfo packages for Java
In-Reply-To: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>
References: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>
Message-ID: <18250.38255.20218.93495@zebedee.pink>

Jason L Tibbitts III writes:
 > I'm having problems reviewing a package for some software written in
 > Java.  The problem is that the debuginfo package is generated without
 > any source.  find-debuginfo.sh prints out the following:
 > 
 > extracting debug info from /var/tmp/writer2latex-0.5-buildroot/usr/lib64/gcj/writer2latex/writer2latex-0.5.jar.so
 > cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex-0.5.jar.1.jar: Cannot stat: No such file or directory
 > cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex/Application.java: Cannot stat: No such file or directory
 > cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex/api/BatchConverter.java: Cannot stat: No such file or directory
 > 
 > Needless to say, the source isn't actually buried under
 > writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex.
 > 
 > Some time ago I reviewed some Java-using packages and the issue was
 > fixable with by making a symlink; see, for example, the ganymed-ssh2
 > package, which has:
 > 
 > # Link source files to fix -debuginfo generation.
 > rm -f ch
 > ln -s src/ch
 > 
 > but this method no longer works and in fact that ganymed-ssh2
 > debuginfo package currently includes no source.  Even if I cook up a
 > directory structure and symlinks so that
 > writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex exists and
 > holds all of the files cpio is complaining about, they still don't
 > make it into the debuginfo package.
 > 
 > So I'm at a loss.  We really need folks who understand java to come up
 > with guidelines and procedures that would answer the kinds of
 > questions which come up when reviewing Java-using packages.  There are
 > a number of them in the review queue but nobody understands how to
 > review them.  And it really wouldn't if someone documented just how
 > debuginfo generation works.
 > 
 > The review ticket in question is
 >   https://bugzilla.redhat.com/show_bug.cgi?id=386661
 > 
 > The ganymed-ssh2 ticket where I first tackled this:
 >   https://bugzilla.redhat.com/show_bug.cgi?id=191014
 > which includes some comments about debuginfo generation being busted
 > for Java.

I might be able to sort this out.  That ought only to be possible if
the package is built wrongly, perhaps with debug=off whan compiling.

I'll try to fix it sometime today.  Ping me if I don't reply.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From martin.sourada at seznam.cz  Mon Nov 26 09:56:02 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Mon, 26 Nov 2007 10:56:02 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <20071126094739.71b6636e@dhcp03.addix.net>
References: <2446.3009-22798-1331156943-1196028540@seznam.cz>
	<20071126094739.71b6636e@dhcp03.addix.net>
Message-ID: <1196070962.3048.17.camel@pc-notebook.kolej.mff.cuni.cz>


On Mon, 2007-11-26 at 09:47 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Sun, 25 Nov 2007 23:09:00 +0100 (CET), Martin Sourada wrote:
> 
> > Looks like both vsftpd and httpd (Apache) are not very UTF-8
> > friendly :-(
> 
> httpd and vsftpd do not care about UTF-8 when displaying files,
> they just read the filename from the disk and push it to the
> client. It's up to the client to interpret the data.
> HTTP has the ability to send a charset with the data, while FTP
> has not.
> 
Didn't know that. Then I wonder, why clients defaults to ISO-8859-1,
while most of the today's filesystems use UTF-8...

> Using "HEAD <yoururl>" you can easily inspect the header information
> sent by your HTTP server and look if it sets the charset information
> correnctly. HEAD is part of the perl-libwww-perl package.
> 

Thanks. The result is not what I'd like.


HEAD 127.0.0.1
200 OK
Connection: close
Date: Mon, 26 Nov 2007 09:52:12 GMT
Accept-Ranges: bytes
Server: Apache/2.2.6 (Fedora)
Content-Type: text/html; charset=UTF-8
Client-Date: Mon, 26 Nov 2007 09:52:12 GMT
Client-Peer: 127.0.0.1:80
Client-Response-Num: 1

HEAD 127.0.0.1/ftp/pub
200 OK
Connection: close
Date: Mon, 26 Nov 2007 09:52:04 GMT
Server: Apache/2.2.6 (Fedora)
Content-Type: text/html;charset=ISO-8859-1
Client-Date: Mon, 26 Nov 2007 09:52:04 GMT
Client-Peer: 127.0.0.1:80
Client-Response-Num: 1

In root there is index.xhtml which is normally displayed by default,
in /ftp/pub there is no html file, only folders, so normally it is
displayed as folder listing.

Thanks,
Martin



From valent.turkovic at gmail.com  Mon Nov 26 10:13:57 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 26 Nov 2007 11:13:57 +0100
Subject: exchange email in fedora 8
Message-ID: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>

https://bugzilla.redhat.com/show_bug.cgi?id=296671
With latest updates I still see this bug.

I work at an ISP company and we use Exchange for our email servers
(unfortunately) and I have used Fedora Core 6 as my work desktop for
over a year or so.
I would like to update my system (ie. clean install) to Fedora 8 but I
need 100% working exchange email client.
This is a really big issues with anybody who needs an up to date linux
desktop because this bug currently prevents me from migrating to new
Fedora 8!

Can you please suggest some way I can use exchange on fedora 8 and so
that GAL works? Some beta version of your evolution packages? Maybe
some older versions of evolution?

Thank you,
Valent Turkovic.

-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From paul at all-the-johnsons.co.uk  Mon Nov 26 11:32:03 2007
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Mon, 26 Nov 2007 11:32:03 +0000
Subject: Disabling readahead
Message-ID: <20071126113203.M96422@all-the-johnsons.co.uk>

Hi,

I have readahead currently running on my test rig (x86_64, rawhide), but it's
currently giving me all sorts of problems, so much so that the box is pretty
unusable (random hangs abound and hugely varied times to getting the desktop
to boot - I've tried to file BZ reports, but the machine dies before I can).

I've read that readahead is currently broken in rawhide. Normally, my machine
boots directly to runlevel 5. Can I alter on the kernel boot line for it jump
to level 3? I can then disable the readahead service.

TIA

TTFN

Paul

P.S. This is holding up getting mono-1.2.6 and other packages into rawhide.

--
Get your free @ukpost.com account now
http://www.ukpost.com/



From mschmidt at redhat.com  Mon Nov 26 11:49:58 2007
From: mschmidt at redhat.com (Michal Schmidt)
Date: Mon, 26 Nov 2007 12:49:58 +0100
Subject: Disabling readahead
In-Reply-To: <20071126113203.M96422@all-the-johnsons.co.uk>
References: <20071126113203.M96422@all-the-johnsons.co.uk>
Message-ID: <20071126124958.6cb2a549@brian.englab.brq.redhat.com>

On Mon, 26 Nov 2007 11:32:03 +0000
"Paul F. Johnson" <paul at all-the-johnsons.co.uk> wrote:

> I've read that readahead is currently broken in rawhide. Normally, my
> machine boots directly to runlevel 5. Can I alter on the kernel boot
> line for it jump to level 3? I can then disable the readahead service.

Just append the digit 3 to the boot command line.

Michal



From akahl at iconmobile.com  Mon Nov 26 11:49:00 2007
From: akahl at iconmobile.com (Alexander Kahl)
Date: Mon, 26 Nov 2007 12:49:00 +0100
Subject: Disabling readahead
In-Reply-To: <20071126113203.M96422@all-the-johnsons.co.uk>
References: <20071126113203.M96422@all-the-johnsons.co.uk>
Message-ID: <1196077740.13601.23.camel@dev31.iconmobile.de>

Hi Paul,

you could also enter interactive mode during boot by pressing "I" after
the corresponding message is displayed (before the graphical boot) and
opt not to start readahead.

Regards
Alex

On Mon, 2007-11-26 at 11:32 +0000, Paul F. Johnson wrote:
> Hi,
> 
> I have readahead currently running on my test rig (x86_64, rawhide), but it's
> currently giving me all sorts of problems, so much so that the box is pretty
> unusable (random hangs abound and hugely varied times to getting the desktop
> to boot - I've tried to file BZ reports, but the machine dies before I can).
> 
> I've read that readahead is currently broken in rawhide. Normally, my machine
> boots directly to runlevel 5. Can I alter on the kernel boot line for it jump
> to level 3? I can then disable the readahead service.
> 
> TIA
> 
> TTFN
> 
> Paul
> 
> P.S. This is holding up getting mono-1.2.6 and other packages into rawhide.
> 
> --
> Get your free @ukpost.com account now
> http://www.ukpost.com/
> 
-- 
alexander kahl _ developer

iconmobile GmbH _ methfesselstr. 30-36 _ 10965 berlin _ germany
phone +49 30 886633 212 _ fax +49 30 886633 150 _ mobile +49 178 8279256
akahl at iconmobile.com _ www.iconmobile.com

local court charlottenburg _ hrb 88308
managing directors _ thomas fellger | stefan kirschke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/36e4052c/attachment.sig>

From buc at odusz.so-cdu.ru  Mon Nov 26 12:12:00 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 26 Nov 2007 15:12:00 +0300
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <47473996.7030002@marquesminen.com.ar>
References: <20071123170139.629e9b64.blueser@gmail.com>
	<47473996.7030002@marquesminen.com.ar>
Message-ID: <474AB810.5070305@odu.neva.ru>

Martin Marques wrote:
>> One thing that's clear is that anaconda QA missed some key spots, and
>> also that we (users) didn't help much on the process, allowing the bugs
>> to remain hidden until the version was officially released, which led to
>> a lot of stress among users and developers.
>>     
>
> The problem is that most users don't have time and resources to test
> twice a year a new release. 6 months for development+beta testing+RC
> testing is just too little. 
>   

It seems that someone in a marketing department assumed that people will 
be frightened by 6 month cycle and will *buy* more stable distribution 
kit (RHEL) instead. The people were actually frightened. What they are 
using now? Yep, CentOS and friends. Free of charge. And free of 
necessity to test new release *at all*  </sarcasm>

Fortunately, recently the policy was changed -- now EOL for a N release 
is 1 month after (N+2) time. Thus you can test a new release just 1 time 
per year.

Just my 2 cent.


Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy





From benny+usenet at amorsen.dk  Mon Nov 26 12:12:33 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Mon, 26 Nov 2007 13:12:33 +0100
Subject: Firefox sets wrong encoding to directory listings?
References: <2446.3009-22798-1331156943-1196028540@seznam.cz>
	<20071126094739.71b6636e@dhcp03.addix.net>
	<1196070962.3048.17.camel@pc-notebook.kolej.mff.cuni.cz>
Message-ID: <m3prxx8atq.fsf@ursa.amorsen.dk>

>>>>> "MS" == Martin Sourada <martin.sourada at seznam.cz> writes:

MS> Didn't know that. Then I wonder, why clients defaults to
MS> ISO-8859-1, while most of the today's filesystems use UTF-8...

HTTP clients generally do as they are told (except for IE, but that's
another rant). Apache tells them ISO-8859-1 in your case, so that's
what they display.

Have you tried IndexOptions Charset=UTF-8?


/Benny




From sundaram at fedoraproject.org  Mon Nov 26 12:08:55 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Nov 2007 17:38:55 +0530
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>	<1195772447.14235.0.camel@localhost>	<1195802914.2831.7.camel@sb-home>	<1195808368.27429.15.camel@wombat.tiptoe.de>	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>	<4747E542.2030408@fedoraproject.org>
	<alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
Message-ID: <474AB757.2050808@fedoraproject.org>

Panu Matilainen wrote:
> On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> 
>> Panu Matilainen wrote:
>>
>>>
>>> The ugly part is that it makes parsing harder as you have to account 
>>> for the possibility of epoch being or not being there always, but 
>>> OTOH you can always pick your own queryformat if you don't want to 
>>> deal with it.
>>
>> Can't you unconditionally have a epoch number listed all the time? 0 
>> if there is no epoch for that package.
> 
> Obviously you CAN, but do you REALLY want to?

Personally, yes. I would like to see epoch listed always so that we get 
a consistent format for other scripts to parse.

Rahul



From sundaram at fedoraproject.org  Mon Nov 26 12:12:30 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Nov 2007 17:42:30 +0530
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AB810.5070305@odu.neva.ru>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>
	<474AB810.5070305@odu.neva.ru>
Message-ID: <474AB82E.3060303@fedoraproject.org>

Dmitry Butskoy wrote:
> Martin Marques wrote:
>>> One thing that's clear is that anaconda QA missed some key spots, and
>>> also that we (users) didn't help much on the process, allowing the bugs
>>> to remain hidden until the version was officially released, which led to
>>> a lot of stress among users and developers.
>>>     
>>
>> The problem is that most users don't have time and resources to test
>> twice a year a new release. 6 months for development+beta testing+RC
>> testing is just too little.   
> 
> It seems that someone in a marketing department assumed that people will 
> be frightened by 6 month cycle and will *buy* more stable distribution 
> kit (RHEL) instead. 

Nope. Red Hat Linux itself followed a similar release schedule so this 
has nothing to do with Fedora/RHEL splut. Besides you can't explain 
various other distribution that have a 6 month release cycle this way. 
Answer lies in rest of the upstream software including GNOME which 
follow this release schedule and user demands for those software which 
are usually too intrusive to include as updates in a general release.

Rahul



From sundaram at fedoraproject.org  Mon Nov 26 12:12:50 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Nov 2007 17:42:50 +0530
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AB810.5070305@odu.neva.ru>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>
	<474AB810.5070305@odu.neva.ru>
Message-ID: <474AB842.7060100@fedoraproject.org>

Dmitry Butskoy wrote:
> Martin Marques wrote:
>>> One thing that's clear is that anaconda QA missed some key spots, and
>>> also that we (users) didn't help much on the process, allowing the bugs
>>> to remain hidden until the version was officially released, which led to
>>> a lot of stress among users and developers.
>>>     
>>
>> The problem is that most users don't have time and resources to test
>> twice a year a new release. 6 months for development+beta testing+RC
>> testing is just too little.   
> 
> It seems that someone in a marketing department assumed that people will 
> be frightened by 6 month cycle and will *buy* more stable distribution 
> kit (RHEL) instead. 

Red Hat Linux itself followed a similar release schedule so this has 
nothing to do with Fedora/RHEL split. Besides you can't explain various 
other distribution that have a 6 month release cycle this way. Answer 
lies in rest of the upstream software including GNOME which follow this 
release schedule and user demands for those software which are usually 
too intrusive to include as updates in a general release.

Rahul



From buc at odusz.so-cdu.ru  Mon Nov 26 12:20:33 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 26 Nov 2007 15:20:33 +0300
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
In-Reply-To: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
Message-ID: <474ABA11.3090305@odu.neva.ru>

[snip]

>  Requires: openssh-clients
> +Requires: policycoreutils
>  BuildRequires: pam-devel, openssh-clients, openssl-devel

[snip]

> +
> +%post
> +semodule -i %{_datadir}/selinux/packages/%{name}/%{name}.pp || :
> +
> +%postun
> +if [ "$1" -eq "0" ]; then
> +  semodule -r %{module} || :
> +fi
>   

AFAIK a lot of people just do not use SELinux and even prefer to remove 
its packages. It seems to me that a hard requirement of 
"policycoreutils" is not a good thing here.

Maybe just check in %post and %postun whether the "semodule" binary is 
present (i.e., "[ -x /usr/sbin/semodule ] && ....")?  Or use %triggerin 
for policycoreutils...

How another packages deal with similar things?


Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy



From caillon at redhat.com  Mon Nov 26 12:39:55 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 26 Nov 2007 13:39:55 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <1196070962.3048.17.camel@pc-notebook.kolej.mff.cuni.cz>
References: <2446.3009-22798-1331156943-1196028540@seznam.cz>	<20071126094739.71b6636e@dhcp03.addix.net>
	<1196070962.3048.17.camel@pc-notebook.kolej.mff.cuni.cz>
Message-ID: <474ABE9B.1010909@redhat.com>

On 11/26/2007 10:56 AM, Martin Sourada wrote:
> HEAD 127.0.0.1
> 200 OK
> Connection: close
> Date: Mon, 26 Nov 2007 09:52:12 GMT
> Accept-Ranges: bytes
> Server: Apache/2.2.6 (Fedora)
> Content-Type: text/html; charset=UTF-8
> Client-Date: Mon, 26 Nov 2007 09:52:12 GMT
> Client-Peer: 127.0.0.1:80
> Client-Response-Num: 1
> 
> HEAD 127.0.0.1/ftp/pub
> 200 OK
> Connection: close
> Date: Mon, 26 Nov 2007 09:52:04 GMT
> Server: Apache/2.2.6 (Fedora)
> Content-Type: text/html;charset=ISO-8859-1

                           ^^^^^^^^^^^^^^^^^^
There's your problem.  Get Apache to stop sending that, and send UTF-8 
there instead and you'll be fine.  This is a server configuration issue, 
not a Firefox issue.

> Client-Date: Mon, 26 Nov 2007 09:52:04 GMT
> Client-Peer: 127.0.0.1:80
> Client-Response-Num: 1
> 
> In root there is index.xhtml which is normally displayed by default,
> in /ftp/pub there is no html file, only folders, so normally it is
> displayed as folder listing.
> 
> Thanks,
> Martin
> 



From buc at odusz.so-cdu.ru  Mon Nov 26 12:56:37 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 26 Nov 2007 15:56:37 +0300
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AB82E.3060303@fedoraproject.org>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>	<474AB810.5070305@odu.neva.ru>
	<474AB82E.3060303@fedoraproject.org>
Message-ID: <474AC285.7070602@odu.neva.ru>

Rahul Sundaram wrote:
> Dmitry Butskoy wrote:
>> Martin Marques wrote:
>>>> One thing that's clear is that anaconda QA missed some key spots, and
>>>> also that we (users) didn't help much on the process, allowing the 
>>>> bugs
>>>> to remain hidden until the version was officially released, which 
>>>> led to
>>>> a lot of stress among users and developers.
>>>>     
>>>
>>> The problem is that most users don't have time and resources to test
>>> twice a year a new release. 6 months for development+beta testing+RC
>>> testing is just too little.   
>>
>> It seems that someone in a marketing department assumed that people 
>> will be frightened by 6 month cycle and will *buy* more stable 
>> distribution kit (RHEL) instead. 
>
> Nope. Red Hat Linux itself followed a similar release schedule so this 
> has nothing to do with Fedora/RHEL splut.

Not exactly. Old releases of Red Hat Linux was supported much more time 
rather than Fedora now.

> Besides you can't explain various other distribution that have a 6 
> month release cycle this way. 

Yep, I can't :)

> Answer lies in rest of the upstream software including GNOME which 
> follow this release schedule 

BTW, what else significant besides GNOME?

> and user demands for those software which are usually too intrusive to 
> include as updates in a general release.
>

But it seems intrusive anyway, because the user is compelled to switch 
to the new release fast enough...


Dmitry



From nphilipp at redhat.com  Mon Nov 26 13:08:51 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 26 Nov 2007 14:08:51 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <474AB757.2050808@fedoraproject.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>	<1195802914.2831.7.camel@sb-home>
	<1195808368.27429.15.camel@wombat.tiptoe.de>
	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>
	<4747E542.2030408@fedoraproject.org>
	<alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
	<474AB757.2050808@fedoraproject.org>
Message-ID: <1196082531.7817.7.camel@gibraltar.str.redhat.com>


On Mon, 2007-11-26 at 17:38 +0530, Rahul Sundaram wrote:
> Panu Matilainen wrote:
> > On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> > 
> >> Panu Matilainen wrote:
> >>
> >>>
> >>> The ugly part is that it makes parsing harder as you have to account 
> >>> for the possibility of epoch being or not being there always, but 
> >>> OTOH you can always pick your own queryformat if you don't want to 
> >>> deal with it.
> >>
> >> Can't you unconditionally have a epoch number listed all the time? 0 
> >> if there is no epoch for that package.
> > 
> > Obviously you CAN, but do you REALLY want to?
> 
> Personally, yes. I would like to see epoch listed always so that we get 
> a consistent format for other scripts to parse.

Scripts can always use "--qf ...". I'd argue that people who use rpm
interactively in most cases don't want to see the epoch prefixed if
there is none. And there is none:

nils at gibraltar:~> rpm -q --qf '%{n}-%{epoch}:%{v}-%{r}.%{arch}\n' initscripts
initscripts-(none):8.60-1.x86_64

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From pertusus at free.fr  Mon Nov 26 13:38:43 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 26 Nov 2007 14:38:43 +0100
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
In-Reply-To: <474ABA11.3090305@odu.neva.ru>
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
	<474ABA11.3090305@odu.neva.ru>
Message-ID: <20071126133842.GB2631@free.fr>

On Mon, Nov 26, 2007 at 03:20:33PM +0300, Dmitry Butskoy wrote:
> [snip]
>
>> +%post
>> +semodule -i %{_datadir}/selinux/packages/%{name}/%{name}.pp || :
>> +
>> +%postun
>> +if [ "$1" -eq "0" ]; then
>> +  semodule -r %{module} || :
>> +fi
>>   
>
> AFAIK a lot of people just do not use SELinux and even prefer to remove its 
> packages. It seems to me that a hard requirement of "policycoreutils" is 
> not a good thing here.
>
> Maybe just check in %post and %postun whether the "semodule" binary is 
> present (i.e., "[ -x /usr/sbin/semodule ] && ....")?  Or use %triggerin for 
> policycoreutils...

%triggerin should really be avoided. What would be nice would be to
have something similar with icons post scripts. But it isn't obvious
that selinux can do all the modules handling at any point.

In any case selinux handling should be in
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
done by selinux people with the packaging commitee control.

Certainly a task for FESCo to drive such guideline.
I'll try to remember it for the next meeting.

--
Pat



From mharris at mharris.ca  Mon Nov 26 13:40:53 2007
From: mharris at mharris.ca (Mike A. Harris)
Date: Mon, 26 Nov 2007 08:40:53 -0500
Subject: PROJECT BLACKHAT
In-Reply-To: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
References: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
Message-ID: <474ACCE5.60508@mharris.ca>

patrick quinn wrote:
> hello team fedora
> me and my team are curentuly working on a reactos (http://www.reactos.org)
 > based os called blackhat which is open source and 100% free.blackhats
 > party piece is its ability to run not only win32 but linux applications
 > nativily.blackhat plays host to the latest open source and gnu software
 > and environments .it will ultimately use the gnome interface as the
 > default gui and have xgl alike abilites.i was wondering if you would
 > be willing to put your name to this project amd give you very minor
 > help and in exchange you will have permenant ad space at the top of
 > are webpage and other fedora promotions troughout the os (eg in the
 > welcome center).we will not ask anything of significance from you
 > just giving blackhat some of that unmistakeable fedora charm.i
 > personally am a huge fan of your os and hence the reason we have come
 > to you.we would really aprecieate a reply be it negitive or positive
> seasons greetings
> team blackhat

Hi there,

This is an interesting looking project.  It's been quite a number of
years since I checked up on the progress of the ReactOS project, but
nice to see it's still active.

IANAL, but one rather important thing which your project may not be 
aware of, is that under trademark law, one must be careful not only to 
avoid infringing directly upon a trademark, but also to avoid using what 
the law calls "confusingly similar" terms as well.  As an example, if an 
entrepreneur tried to open a new restaurant chain with the name "Burger 
Queen" or "Sausage King", the law would probably find these terms to be 
"confusingly similar" to "Burger King" and the owner of the Burger King 
trademark would have to defend their trademark by sending a legal notice 
of trademark contention (or whatever the correct legal term is).

Trademark law is pretty much "defend it or lose it" and so trademark 
owners who are aware of mark violations, or usage of confusingly similar 
marks don't have much choice but to defend their marks or risk losing them.

Red Hat has put up their trademark guidelines document to provide 
guidance on appropriate use of Red Hat's trademarks, as well as 
providing some general trademark related information to help ensure that 
others do not intentionally or unintentionally violate Red Hat's 
trademarks or use confusingly similar terms.

I highly recommend reading the Red Hat Trademark guidelines, which can 
be found at:  http://www.redhat.com/about/companyprofile/trademark

Here is a direct link to the PDF document:
http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf

Have a look at page 3, section C, which covers plays on words, and 
"confusingly similar terms" which may cause confusion in the 
marketplace.  Here is an excerpt:

	C. ?Plays On Words? And Other Actions That May Cause
	 Confusion Are Also Prohibited
	...
	Some examples of prohibited uses include, but
	are not limited to, ?Red Cap? Linux, ?Sombrero Rojo?
	(?Red Hat? translated into Spanish) Linux, ?Redd Hatte?
	Linux, ?RH? Linux, and ?Green Hat? Linux.



Since "Green Hat" is directly refered to in the Red Hat trademark 
guidelines as being one example of a confusingly similar mark which 
would be prohibited.  I think it would be safe to also assume that 
"Black Hat", "blackhat" or more generically "$any_color 
$any_type_of_hat" would equally be considered to be prohibited.

My suggestion, would be to change the name and totally avoid any 
possible chance of potentially stepping on trademark related issues.

You could still keep a similar theme of "$color $something", just don't 
use "Red" or "Hat" or any other word that means "hat" or is a type of 
hat, and you're probably ok.  In the past, there have been "Blue Sky 
Linux", "Green Frog Linux", "Yellowdog Linux", "Black Flag Linux", "Pink 
Tie Linux", and "White Box Linux" that I'm aware of, and probably a 
number of others as well.  As far as I recall those names were all ok, 
although as I said above, IANAL.  ;o)

Here are some ideas:

"Black React"
"Black Reaction"
"Black Force"
"Black Ham"

I've no idea if any of those suggestions would be considered confusingly 
similar either of course, so if you use one of them and get legal papers 
in your mailbox, don't blame me!  ;o)   If in doubt though, it is best 
to directly consult with an intellectual property attourney.

Anyhow, since I've seen these sort of trademark issues arise in the 
past, and sometimes people end up getting upset.  I thought I would give 
a heads up before people print out any company letterheads with names on 
them which might be considered to be in conflict with Red Hat's marks.

Hope this helps.



P.S.  Don't hate the players...  hate the game...  ;o)


-- 
Mike A. Harris

Come and join us on the #fedora8 IRC help forum on irc.freenode.net



From jima at beer.tclug.org  Mon Nov 26 13:51:24 2007
From: jima at beer.tclug.org (Jima)
Date: Mon, 26 Nov 2007 07:51:24 -0600 (CST)
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <yoj1waje08e.fsf@bird.phys.ntnu.no>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<yojfxyze2tl.fsf@bird.phys.ntnu.no>
	<1195680550.4552.117.camel@localhost.localdomain>
	<yoj1waje08e.fsf@bird.phys.ntnu.no>
Message-ID: <Pine.LNX.4.64.0711260749050.17671@beer.tclug.org>

On Wed, 21 Nov 2007, Terje Rosten wrote:
> However I start the install from grub (one more cdrom saved :-) and then
> I need the images/ directory.
>
> (In fact, all I need to do is to cp the images/ dir from Fedora spin to
> Everything spin.)

  Sigh.  This is the first thing I do after rsyncing the Everything/ tree 
to my local mirror.
  RelEng, is there any way we could get images/ under Everything/, too? 
(Moving forward, that is -- I'm not requesting it be retroactive.)  With 
hardlinks the space shouldn't matter, right?
  Thanks in advance for the consideration either way. :-)

      Jima



From buc at odusz.so-cdu.ru  Mon Nov 26 13:54:31 2007
From: buc at odusz.so-cdu.ru (Dmitry Butskoy)
Date: Mon, 26 Nov 2007 16:54:31 +0300
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
In-Reply-To: <20071126133842.GB2631@free.fr>
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>	<474ABA11.3090305@odu.neva.ru>
	<20071126133842.GB2631@free.fr>
Message-ID: <474AD017.7050808@odu.neva.ru>

Patrice Dumas wrote:
> On Mon, Nov 26, 2007 at 03:20:33PM +0300, Dmitry Butskoy wrote:
>>
>> Maybe just check in %post and %postun whether the "semodule" binary is 
>> present (i.e., "[ -x /usr/sbin/semodule ] && ....")?  Or use %triggerin for 
>> policycoreutils...
>>     
>
> %triggerin should really be avoided.

But if the user will decide to use SELinux (install all needed packages) 
later? Then it should re-install pam_ssh to activate its policies...


Dmitry



From rdieter at math.unl.edu  Mon Nov 26 14:08:02 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Mon, 26 Nov 2007 08:08:02 -0600
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
	<474ABA11.3090305@odu.neva.ru> <20071126133842.GB2631@free.fr>
Message-ID: <fiek02$vrr$1@ger.gmane.org>

Patrice Dumas wrote:

> On Mon, Nov 26, 2007 at 03:20:33PM +0300, Dmitry Butskoy wrote:
>> [snip]
>>
>>> +%post
>>> +semodule -i %{_datadir}/selinux/packages/%{name}/%{name}.pp || :
>>> +
>>> +%postun
>>> +if [ "$1" -eq "0" ]; then
>>> +  semodule -r %{module} || :
>>> +fi
>>>   
>>
>> AFAIK a lot of people just do not use SELinux and even prefer to remove
>> its packages. It seems to me that a hard requirement of "policycoreutils"
>> is not a good thing here.

other than a few MB's, it's mostly harmless.  *shrug*.

>> Maybe just check in %post and %postun whether the "semodule" binary is
>> present (i.e., "[ -x /usr/sbin/semodule ] && ....")?  Or use %triggerin
>> for policycoreutils...
> 
> %triggerin should really be avoided.

Why? it would appear that it would work to satisfy the requirements here.

-- Rex




From skvidal at fedoraproject.org  Mon Nov 26 14:04:40 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Nov 2007 09:04:40 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <474AB757.2050808@fedoraproject.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>	<1195802914.2831.7.camel@sb-home>
	<1195808368.27429.15.camel@wombat.tiptoe.de>
	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>
	<4747E542.2030408@fedoraproject.org>
	<alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
	<474AB757.2050808@fedoraproject.org>
Message-ID: <1196085880.15420.0.camel@cutter>


On Mon, 2007-11-26 at 17:38 +0530, Rahul Sundaram wrote:
> Panu Matilainen wrote:
> > On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> > 
> >> Panu Matilainen wrote:
> >>
> >>>
> >>> The ugly part is that it makes parsing harder as you have to account 
> >>> for the possibility of epoch being or not being there always, but 
> >>> OTOH you can always pick your own queryformat if you don't want to 
> >>> deal with it.
> >>
> >> Can't you unconditionally have a epoch number listed all the time? 0 
> >> if there is no epoch for that package.
> > 
> > Obviously you CAN, but do you REALLY want to?
> 
> Personally, yes. I would like to see epoch listed always so that we get 
> a consistent format for other scripts to parse.

-1 showing the epoch looks ridiculous since in most cases it'll be a 0.

Yum has done this for a long time, actually:

foo-1.1-1.noarch
1:bar-1.1-1.noarch

foo has none or a 0 epoch
bar has an epoch of 1

-sv






From berrange at redhat.com  Mon Nov 26 14:16:51 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 26 Nov 2007 14:16:51 +0000
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <474AB757.2050808@fedoraproject.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<1195802914.2831.7.camel@sb-home>
	<1195808368.27429.15.camel@wombat.tiptoe.de>
	<alpine.DEB.0.9999.0711240825380.24678@gotcha.dreamhost.com>
	<4747E542.2030408@fedoraproject.org>
	<alpine.DEB.0.9999.0711241144530.24678@gotcha.dreamhost.com>
	<474AB757.2050808@fedoraproject.org>
Message-ID: <20071126141651.GP31847@redhat.com>

On Mon, Nov 26, 2007 at 05:38:55PM +0530, Rahul Sundaram wrote:
> Panu Matilainen wrote:
> >On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> >
> >>Panu Matilainen wrote:
> >>
> >>>
> >>>The ugly part is that it makes parsing harder as you have to account 
> >>>for the possibility of epoch being or not being there always, but 
> >>>OTOH you can always pick your own queryformat if you don't want to 
> >>>deal with it.
> >>
> >>Can't you unconditionally have a epoch number listed all the time? 0 
> >>if there is no epoch for that package.
> >
> >Obviously you CAN, but do you REALLY want to?
> 
> Personally, yes. I would like to see epoch listed always so that we get 
> a consistent format for other scripts to parse.

Which would assume those scripts only ever run on Fedora 9 or later. 

Any script which wants consistency *HAS* to use an explicit --qf if it wants
to also work on older Fedora, or pretty much any other RPM distro. There's
nothing we can do about this, because its just historical baggage. So 
making a change to add Epoch won't help consistency - it'll make it worse,
and it'll also potentially break exisiting scripts not expecting an
Epoch by default.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From buildsys at redhat.com  Fri Nov  9 17:40:13 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 09 Nov 2007 17:40:13 -0000
Subject: rawhide report: 20071109 changes
Message-ID: <200711091740.lA9HeA1C011598@porkchop.devel.redhat.com>

New package Democracy
	Democracy Player

New package PackageKit
	System daemon that is a DBUS abstraction layer for package management

New package PySolFC
	A collection of solitare card games

New package PySolFC-cardsets
	Various cardsets for PySolFC

New package PySolFC-music
	Music for PySolFC

New package SDL_sound
	Library handling decoding of several popular sound file formats

New package awn-extras-applets
	Extras applets for avant window navigator

New package babl
	A dynamic, any to any, pixel format conversion library

New package bibexport
	Extract entries from BibTeX and .aux files

New package bodhi
	A modular framework that facilitates publishing software updates

New package ccsm
	Plugin and configuration tool - Compiz Fusion Project

New package cdpr
	Cisco Discovery Protocol Analyzer

New package clonekeen
	"Commander Keen: Invasion of the Vorticons" clone

New package compizconfig-backend-gconf
	GConf backend for compizconfig

New package compizconfig-backend-kconfig
	kconfig backend for compizconfig

New package conntrack-tools
	Tools to manipulate netfilter connection tracking table

New package docker
	KDE and GNOME2 system tray replacement docking application

New package edsadmin
	An LDAP server administration tool

New package extrema
	Extrema is a powerful visualization and data analysis tool

New package fprobe-ulog
	NetFlow probe

New package freeipmi
	FreeIPMI

New package func
	Remote config, monitoring, and management api

New package gegl
	A graph based image processing framework

New package gnome-applet-tvn24
	Scrolled RSS aggregator for the polish TVN24 channel

New package gnome-devel-docs
	GNOME developer documentation

New package gnome-packagekit
	GNOME PackageKit Client

New package gnome-scan
	Gnome solution for scanning in the desktop on top of libsane

New package gst-inspector
	An introspection data viewer for the GStreamer multimedia framework

New package gt5
	A diff-capable 'du-browser'

New package icecream
	Distributed compiler

New package inchi
	The IUPAC International Chemical Identifier library

New package iotop
	Top like utility for I/O

New package jgoodies-forms
	Framework to lay out and implement elegant Swing panels in Java

New package koules
	Action game with multiplayer, network and sound support

New package kreetingkard
	Japanese greeting card writing software for KDE

New package kreetingkard_templates
	Template files for KreetingKard

New package libewf
	Library for the Expert Witness Compression Format (EWF)

New package libggz
	Library for client-server games

New package libmikmod
	A MOD music file player library

New package libnemesi
	RTSP/RTP client library

New package libvoikko
	Voikko is a library for spellcheckers and hyphenators

New package malaga
	A programming language for automatic language analysis

New package malaga-suomi-voikko
	A description of Finnish morphology written in Malaga (Voikko edition)

New package ndesk-dbus
	Managed C# implementation of DBus

New package netembryo
	Network abstraction library

New package pam_mysql
	PAM module for auth UNIX users using MySQL data base

New package paperkey
	An OpenPGP key archiver

New package perl-Business-ISBN
	Perl module to work with International Standard Book Numbers

New package perl-Business-ISBN-Data
	The data pack for Business::ISBN

New package perl-DBI-Dumper
	Dump data from a DBI datasource to file

New package perl-SQL-Translator
	Manipulate structured data definitions (SQL and more)

New package perl-Template-Alloy
	Templating tool supporting multiple markup formats

New package phasex
	PHASEX -- Phase Harmonic Advanced Synthesis EXperiment

New package php-channel-symfony
	Adds symfony project channel to PEAR

New package python-flup
	Random assortment of WSGI servers for python

New package python-gdata
	A Python module for accessing online Google services

New package python-which
	Small which replacement that can be used as a Python module

New package qca-ossl
	OpenSSL plugin for the Qt Cryptographic Architecture v2

New package qca2
	Qt Cryptographic Architecture

New package qlandkarte
	A tool to visualize maps and other GPS information for Garmin devices

New package qt-recordmydesktop
	KDE Desktop session recorder with audio and video

New package qtiplot
	Data Analysis and Scientific Plotting

New package ruby-hpricot
	A Fast, Enjoyable HTML Parser for Ruby

New package ruby-ldap
	Ruby LDAP libraries

New package ruby-mechanize
	A handy web browsing ruby object

New package ruby-rpm
	Ruby bindings for RPM

New package safekeep
	The SafeKeep backup system

New package stix-fonts
	STIX scientific and engineering fonts

New package tcputils
	Utilities for TCP programming in shell-scripts

New package tkimg
	More Image Formats for Tk

New package upslug2
	Firmware update utility for the nslu2

New package wqy-zenhei-fonts
	WenQuanYi Zen Hei CJK Font

New package wyrd
	A ncurses frontend for the calendar application remind

New package xgrav
	A simple physics simulation for a large number of particles

New package xorg-x11-drv-openchrome
	Xorg X11 openchrome video driver

New package xorg-x11-drv-radeonhd
	Xorg X11 radeonhd driver for AMD GPG r5xx/r6xx Chipsets

New package xulrunner
	XUL Runtime for Gecko Applications


Removed package dejavu-lgc-fonts

Removed package qt4-qsa

Updated Packages:

CGAL-3.3.1-8.fc9
----------------
* Mon Nov 05 2007 Laurent Rineau <laurent.rineau__fedora at normalesup.org> - 3.3.1-8.fc9
- Add Requires: mpfr-devel for CGAL-devel.

* Mon Oct 22 2007 Laurent Rineau <laurent.rineau__fedora at normalesup.org> - 3.3.1-6.fc9
- fix /etc/profile.d/cgal.*

* Sun Oct 21 2007 Laurent Rineau <laurent.rineau__fedora at normalesup.org> - 3.3.1-3.fc9
- gawk and coreutils are not required in BR (see exceptions list)
- fix multilib issues (bug #340821):
  - rename %{_datadir}/CGAL/cgal.mk to %{_datadir}/CGAL/cgal-%{_arch}.mk
  - remove the arch-specific comment from %{_includedir}/CGAL/compiler_config.h

Canna-3.7p3-22.fc9
------------------
* Tue Oct 30 2007 Akira TAGOH <tagoh at redhat.com> - 3.7p3-22
- Remove the dead link.

ClanLib-0.8.0-7.fc9
-------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.8.0-7
- Fix multilib conflicts in generated Reference documentation (bz 340851)

* Fri Aug 03 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.8.0-6
- Update License tag for new Licensing Guidelines compliance

* Tue Jun 19 2007 Matthias Saou <http://freshrpms.net/> 0.8.0-5
- Rebuild against SDL_gfx 2.0.16.

ClanLib06-0.6.5-9.fc9
---------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.6.5-9
- Explictily disable directfb support, so that it doesn't accidentally get
  build on system which have directfb installed
- Fix multilib conflict in the Reference documentation (bz 340861)

ConsoleKit-0.2.3-2.fc9
----------------------
* Mon Oct 22 2007 Matthias Clasen  <mclasen at redhat.com> - 0.2.3-2
- Rebuild against new dbus-glib

Django-0.96.1-1.fc9
-------------------
* Thu Nov 01 2007 Michel Salim <michel.sylvan at gmail.com> 0.96.1-1
- i18n security update: CVE-2007-5712, bz#357051
GConf2-2.20.1-2.fc9
-------------------
* Sat Nov 03 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Add a location for system-wide settings

KoboDeluxe-0.4.1-1.fc9
----------------------
* Wed Oct 31 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.4.1-1
- New upstream release 0.4.1
- Drop integrated patches

Miro-0.9.9.1-6.fc9
------------------
* Thu Nov 01 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.9.9.1-6
- Update patch with workaround suggested on:
  http://bugzilla.pculture.org/show_bug.cgi?id=8579

* Wed Oct 31 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.9.9.1-5
- Add setup.py patch to ignore call to svn.

* Tue Oct 30 2007 Alex Lancaster <alexl at users.sourceforge.net> 0.9.9.1-3
- Add BuildRequires: libXv-devel
- Drop dbus patch

NetworkManager-1:0.7.0-0.4.svn2983.fc9
--------------------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 1:0.7.0-0.4.svn2983
- Rebuild against new dbus-glib

* Tue Oct 16 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2983
- Add rfkill functionality
- Fix applet crash when choosing wired networks from the menu

* Wed Oct 10 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.3.svn2970
- Fix segfault with deferred connections
- Fix default username with vpnc VPN plugin
- Hidden SSID fixes

ORBit-1:0.5.17-22.fc9
---------------------

OpenEXR-1.6.0-4.fc9
-------------------
* Mon Oct 15 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-4
- -libs: %post/%postun -p /sbin/ldconfig

* Fri Oct 12 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.6.0-2
- openexr-1.6.0

* Mon Sep 17 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.4.0a-6
- libs: -Requires: %name

OpenSceneGraph-2.2.0-2.fc9
--------------------------
* Fri Nov 02 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.2.0-2
- Add qt.

* Thu Nov 01 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.2.0-1
- Upstream upgrade.
- Reflect Source0-URL having changed once again.
- Reflect upstream packaging changes to spec.

* Sat Oct 20 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.0-8
- Reflect Source0-URL having changed.

PolicyKit-gnome-0.6-2.fc9
-------------------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 0.6-2
- Rebuild against new dbus-glib

* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.6-1.fc9
- Update to latest upstream release

* Tue Sep 25 2007 David Zeuthen <davidz at redhat.com> - 0.6-0.git20070925.fc9
- Update to git snapshot

PyQt-3.17.3-1.fc9
-----------------
* Mon Oct 22 2007 Than Ngo <than at redhat.com> - 3.17.3-1
- 3.17.3

PyQt4-4.2-8.fc9
---------------

QuantLib-0.8.1-4.fc9
--------------------

R-2.6.0-3.fc9.1
---------------
* Tue Oct 30 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3.1
- fix missing perl requires

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3
- fix multilib conflicts (bz 343061)

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-2
- add R CMD javareconf to post (bz 354541)
- don't pickup bogus perl provides (bz 356071)
- use xdg-open, drop requires for firefox/evince (bz 351841)

Ri-li-2.0.1-1.fc9
-----------------

SDL-1.2.12-3.fc9
----------------
* Tue Nov 06 2007 Thomas Woerner <twoerner at redhat.com> 1.2.12-3
- fixed latest multiarch conflicts: dropped libdir from sdl-config completely
  (rhbz#343141)

* Tue Aug 28 2007 Thomas Woerner <twoerner at redhat.com> 1.2.12-2
- use uname -m in multilib patch instead of arch

* Mon Aug 27 2007 Thomas Woerner <twoerner at redhat.com> 1.2.12-1
- new version 1.2.12
  fixes TEXTRELs (rhbz#179407)
- added arm support (rhbz#245411)
  Thanks to Lennert Buytenhek for the patch
- added alpha support (rhbz#246463)
  Thanks to Oliver Falk for the patch
- disabled yasm for SDL (rhbz#234823)
  Thanks to Nikolay Ulyanitsky for the patch

SDLmm-0.1.8-6.fc9
-----------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.1.8-6
- Fix sdlmm-config multilib conflict (bz 343151)

SILLY-0.1.0-4.fc9
-----------------
* Sun Oct 28 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.1.0-4
- Multiarch fixes (BZ 343181)
TeXmacs-1.0.6.12-2.fc9
----------------------
* Mon Nov 05 2007 Gerard Milmeister <gemi at bluewin.ch> - 1.0.6.12-1
- new release 1.0.6.12
- split off devel package

TurboGears-1.0.3.2-6.fc9
------------------------
* Sat Oct 27 2007 Luke Macken <lmacken at redhat.com> 1.0.3.2-6
- Remove python-TestGears requirement, as this functionality
  has been replaced by nose.

Zim-0.21-1.fc9
--------------
* Wed Oct 03 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.21-1
- update to 0.21
- add contrib/, TRepository.PL to doc
- update license tag: GPL -> GPL+
- add a requires on scrot, for the InsertScreenshot plugin

* Wed May 30 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.19-2
- add a require on Gtk2::TrayIcon; not picked up automatically
- some BR refactoring given perl splittage

abcm2ps-5.6.0-1.fc9
-------------------
* Sat Nov 03 2007 Gerard Milmeister <gemi at bluewin.ch> - 5.6.0-1
- new release 5.6.0

acl-2.2.45-2.fc9
----------------
* Wed Nov 07 2007 Jiri Moskovcak <jmoskovc at redhat.com> 2.2.45-2
- Fixed setfacl exitcodes
- Resolves: #368451

* Wed Oct 31 2007 Jiri Moskovcak <jmoskovc at redhat.com> - 2.2.45-1
- New version
- dropped walk patch

acpid-1.0.6-3.fc9
-----------------
* Tue Oct 23 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-3.fc9
- Silent initscript
- Resolves: #345611

* Wed Sep 26 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-2.fc8
- Fixed leak of a file descriptor
- Resolves: #304761

* Tue Aug 07 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.0.6-1.fc8
- Updated to version 1.0.6

alexandria-0.6.2-0.1.b2.fc9
---------------------------
* Sun Nov 04 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.6.2-0.1.b2
- And try 0.6.2 beta 2
alleggl-0.4.2-2.fc9
-------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.4.2-2
- Some cleanups to the multilib doxygen documentation bugfix

* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.4.2-1
- Upstream has renamed rc1 to final, so drop the .rc1 from the release field
- Fix multilib conflicts in doxygen documentation (bz 340611)

alpine-0.9999-4.fc9
-------------------
* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org. 0.9999-4
- omit sample pine.conf, instead use %ghost to preserve existing pine.conf's

* Wed Oct 24 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.9999-3
- include stock pine.conf, pine.conf.fixed

alsa-lib-1.0.15-1.fc9
---------------------

alsa-utils-1.0.15-1.fc9
-----------------------

amqp-0:1.0-1
------------
* Wed Aug 01 2007 Nuno Santos  <nsantos at redhat.com> - 1.0-1
- Include multiple versions of the spec; bump release
anthy-9100d-1.fc9
-----------------
* Mon Oct 29 2007 Akira TAGOH <tagoh at redhat.com> - 9100d-1
- New upstream release.
- anthy-enable-dict-gtankan.patch: removed. no need to be applied anymore.

apmd-1:3.2.2-6
--------------
* Wed Nov 07 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1:3.2.2-6
- Update apmscript to use pccardctl (#192942)
- Update init script to comply with LSB standard (#237771)
- Fixed starting of anacron after resume (#83770)
- Fixed X_LOCK (#127318)
- Included laptopmode script (#91878)
- Fixed restarting network (#357381)

aqbanking-2.3.2-3.fc9
---------------------
* Tue Oct 30 2007 Bill Nottingham <notting at redhat.com> - 2.3.2-3
- fix multilib conflicts (#340671)

archivemail-0.7.1-1.fc9
-----------------------
* Thu Nov 08 2007 Jon Ciesla <limb at jcomserv.net> 0.7.1-1
- Update to 0.7.1.
- Updated test_archivemail.patch for new version.
- Removed fpname and imap patches, fixed by upstream.

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> 0.7.0-7
- License tag correction.

asciidoc-8.2.3-1.fc9
--------------------
* Mon Oct 22 2007 Florian La Roche <laroche at redhat.com> - 8.2.3-1
- new upstream version 8.2.3

aspell-af-50:0.50-8.fc9
-----------------------
* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com> - 50:0.50-8
- fix a typo in the summary line
- Resolves: #239216

attr-2.4.39-1.fc9
-----------------
* Wed Oct 31 2007 Zdenek Prikryl <zprikryl at redhat.com> 2.4.39-1
- New version 2.4.39
- Resolves #284121

* Tue Oct 30 2007 Zdenek Prikryl <zprikryl at redhat.com> 2.4.38-2
- Removed explicit Requires(post + postun)
- Resolves #225290

autoconf-2.61-10.fc9
--------------------
* Mon Oct 29 2007 Stepan Kasal <skasal at redhat.com> 2.61-10
- require m4 >= 1.4.7
- Resolves: #236073

* Wed Aug 08 2007 Karsten Hopp <karsten at redhat.com> 2.61-9
- update license tag

* Tue Feb 27 2007 Karsten Hopp <karsten at redhat.com> 2.61-8
- own %{_datadir}/emacs/ (#225296)

automake-1.10-7
---------------
* Mon Oct 29 2007 Stepan Kasal <skasal at redhat.com> 1.10-7
- keep amhello-1.0.tar.gz in the installed documentation

* Thu Aug 09 2007 Karsten Hopp <karsten at redhat.com> 1.10-6
- update license tag
- add Debian man pages for aclocal and automake (#246087)

* Tue Feb 20 2007 Karsten Hopp <karsten at redhat.com> 1.10-5
- fix some rpmlint warnings

avant-window-navigator-0.2.1-2.fc9
----------------------------------
* Sun Nov 04 2007 Sindre Pedersen Bj??rdal <foolish[AT]guezz.net> - 0.2.1-2
- New Release

* Sun Oct 21 2007 Huang Peng <phuang at redhat.com> - 0.2-1
- Update to 0.2

azureus-2.5.0.4-4.fc9
---------------------
* Thu Oct 25 2007 Ben Konrath <bkonrath at redhat.com> - 2.5.0.4-4
- Use swt.jar instead of swt-gtk-3.3.jar in wrapper script.

basket-1.0.2-3.fc9
------------------
* Sat Oct 27 2007 Aurelien Bompard <abompard at fedoraproject.org> 1.0.2-3
- fix kontact plugin for kdepim-enterprise (bug 354771)

bcfg2-0.9.5-0.5.pre7.fc9
------------------------
* Mon Nov 05 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-0.5.pre7
- Commit new patches to CVS.

* Mon Nov 05 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.9.5-0.4.pre7
- Update to 0.9.5pre7

bigboard-0.5.26-1.fc9
---------------------

bind-32:9.5.0-16.a6.fc9
-----------------------

blktrace-0.0-0.6.20071010202719git.fc9
--------------------------------------
* Wed Oct 24 2007 Eric Sandeen <sandeen at redhat.com> - 0.0-0.6.20071010202719git
- Add libaio-devel to BuildRequires

* Wed Oct 24 2007 Eric Sandeen <sandeen at redhat.com> - 0.0-0.5.20071010202719git
- New upstream version

blt-2.4-18.fc9
--------------
* Mon Nov 05 2007 Sergio Pascual <sergiopr at fedoraproject.org> 2.4-18
- Providing file in /etc/ld.so.conf.d (bug #333081)

* Mon Oct 22 2007 Marek Mahut <mmahut fedoraproject.org> 2.4-17
- Providing devel package as per request in BZ#249812

* Thu Feb 08 2007 Jean-Luc Fontaine <jfontain at free.fr> 2.4-15.z
- require tk < 8.5

bluez-gnome-0.14-9.fc9
----------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.14-9
- Rebuild against new dbus-glib

bluez-libs-3.22-1.fc9
---------------------
* Fri Oct 26 2007 - Bastien Nocera <bnocera at redhat.com> - 3.22-1
- Update to 3.22

bluez-utils-3.22-6.fc9
----------------------
* Sun Oct 28 2007 Jeremy Katz <katzj at redhat.com> - 3.22-6
- fix scriptlet errors (#354531)

* Fri Oct 26 2007 - Bastien Nocera <bnocera at redhat.com> 3.22-5
- Update to bluez-utils 3.22
- Remove alsa-lib dep for the alsa sub-package, pulled in by
  library deps

* Fri Oct 26 2007 - Bastien Nocera <bnocera at redhat.com> 3.20-5
- Remove unneeded gstreamer dependency in the gstreamer sub-package

boolstuff-0.1.11-2.fc9
----------------------

bootchart-0.9-6.fc9
-------------------
* Mon Oct 29 2007 Adam Jackson <ajax at redhat.com> 0.9-6
- Don't remove bootchart from grub.conf on upgrade. (#349101)

booty-0.92-1.fc9
----------------
* Mon Oct 29 2007 Chris Lumens <clumens at redhat.com> 0.92-1
- Honor the bootloader --timeout= kickstart option.

boswars-2.4.1-3.fc9
-------------------

bouml-3.0.2-1.fc9
-----------------
* Sun Nov 04 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.0.2-1
- Version bump to 3.0.2. Closes Red Hat Bugzilla bug #326641.
- Introduced PHP support.
- Backported bug-fix from 3.3.

* Thu Oct 11 2007 Debarshi Ray <rishi at fedoraproject.org> - 2.32-1
- Version bump to 2.32. Closes Red Hat Bugzilla bug #303721.

* Wed Oct 03 2007 Debarshi Ray <rishi at fedoraproject.org> - 2.31.3-1
- Version bump to 2.31.3. Closes Red Hat Bugzilla bug #292541.

bug-buddy-1:2.20.1-1.fc9
------------------------

bugzilla-3.0.2-2.fc9
--------------------
* Fri Oct 26 2007 John Berninger <john at ncphotography dot com> - 3.0.2-2
- fix issue with AlowOverride Options

* Mon Oct 22 2007 John Berninger <john at ncphotography dot com> - 3.0.2-1
- updates to requires and httpd conf for BZ's 279961, 295861, 339531

busybox-1:1.7.3-1.fc9
---------------------
* Tue Nov 06 2007 Ivana Varekova <varekova at redhat.com> - 1:1.7.3-1
- update to 1.7.3 
- remove --gc-sections from static build Makefile

* Thu Nov 01 2007 Ivana Varekova <varekova at redhat.com> - 1:1.7.2-4
- fix 359371 - problem with grep output

* Wed Oct 31 2007 Ivana Varekova <varekova at redhat.com> - 1:1.7.2-3
- fix another sed problem (forgotten fflush - #356111)

cacti-0.8.7-2.fc9
-----------------
* Sat Oct 13 2007 Mike McGrath <mmcgrath at redhat.com> - 0.8.7-2
- Upstream released new version
- No longer need to patch for /etc/cacti/*

* Fri Sep 14 2007 Mike McGrath <mmcgrath at redhat.com> - 0.8.6j-8
- Fix for CVE-2007-3112 bz#243592

* Sat Sep 08 2007 Mike McGrath <mmcgrath at redhat.com> - 0.8.6j-6
- rebuild

cairo-1.5.2-1.fc9
-----------------
* Wed Oct 31 2007 Behdad Esfahbod <besfahbo at redhat.com> 1.5.2-1
- Update to 1.5.2
- Switch to external pixman.

* Wed Aug 22 2007 Adam Jackson <ajax at redhat.com> - 1.4.10-2
- Rebuild for PPC toolchain bug

* Wed Jun 27 2007 Carl Worth <cworth at redhat.com> 1.4.10-1
- Update to 1.4.10

calcurse-1.9-1.fc9
------------------

centerim-1:4.22.1.20071022-1.fc9
--------------------------------
* Thu Oct 25 2007 Lubomir Kundrak <lkundrak at redhat.com> - 1:4.22.1.20071022-1
- New upstream tarball, functionally equivalent to previous revision of the pkg

* Tue Oct 23 2007 Lubomir Kundrak <lkundrak at redhat.com> - 1:4.22.1.20071003-4
- lkundrak's dumb, dumb, dumb and he .... up the versioning, bumping epoch
- Merging the upstream git snapshot:
- Our fixes upstreamed
- Fix for MSN NOT messages handling
- Fixed french translation

cernlib-2006-20.fc9
-------------------
* Tue Oct 30 2007 Patrice Dumas <pertusus at free.fr> 2006-20
- don't use the same spec for epel4
- always ship the packages with compiler suffix. This is needed for 
  proper upgrade path as soon as such a package has been ever shipped
- fix timestamps

cernlib-g77-2006-20.fc9
-----------------------
* Tue Oct 30 2007 Patrice Dumas <pertusus at free.fr> 2006-20
- don't use the same spec for epel4
- always ship the packages with compiler suffix. This is needed for 
  proper upgrade path as soon as such a package has been ever shipped
- fix timestamps

charis-fonts-4.100-5.fc9
------------------------
* Sat Nov 03 2007 <nicolas.mailhot at laposte.net>
??? 4.100-5
??? Sync with guidelines
??? fix config file misplacement

* Thu Nov 01 2007 <nicolas.mailhot at laposte.net>
??? 4.100-4
??? Sync with guidelines
??? new fontconfig aliasing syntax

chmsee-1.0.0-1.26.fc9
---------------------
* Wed Oct 24 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.26
- build for firefox-2.0.0.8

* Sat Aug 11 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-1.23
- update to 1.0.0
- build for firefox-2.0.0.6
- update License field to GPLv2

* Sat Jul 21 2007 bbbush <bbbush.yuan at gmail.com> - 1.0.0-0.22.beta2
- fix desktop file

cksfv-1.3.12-2.fc9
------------------
* Sat Oct 27 2007 Christohper Stone <chris.stone at gmail.com> 1.3.12-2
- Fix rpmlint issues

clamav-0.91.2-3.fc9
-------------------

climm-0.6.1-1.fc9
-----------------
* Mon Oct 22 2007 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 0.6.1-1
- Update to upstream
- Removed glibc patch (fix included upstream)

clucene-0.9.20-2.fc9
--------------------
* Tue Aug 21 2007 Deji Akingunola <dakingun at gmail.com> - 0.9.20-2
- Fix multiarch conflicts (BZ #340891)
- Bypass 'make check' for ppc64, its failing two tests there

* Tue Aug 21 2007 Deji Akingunola <dakingun at gmail.com> - 0.9.20-1
- Update to version 0.9.20

* Sat Aug 11 2007 Deji Akingunola <dakingun at gmail.com> - 0.9.19-1
- Latest release update

cobbler-0.6.3-2.fc9
-------------------
* Wed Nov 07 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.3-2
- Upstream changes (see CHANGELOG)
- now packaging javascript file(s) seperately for WUI
- backup state files on upgrade 
- cobbler sync now has pre/post triggers, so package those dirs/files
- WebUI now has .htaccess file
- removed yum-utils as a requirement

codeina-0.10.1-6.fc9
--------------------
* Wed Nov 07 2007 Matthias Clasen <mclasen at redhat.com> - 0.10.1-6
- Add a missing dependency

colordiff-1.0.7-2.fc9
---------------------
* Tue Nov 06 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.0.7-2
- Upstream brown paper bag 1.0.7 re-release.

* Tue Nov 06 2007 Ville Skytt?? <ville.skytta at iki.fi> - 1.0.7-1
- 1.0.7.

compat-wxGTK26-2.6.4-1
----------------------
* Wed Nov 07 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.6.4-1
- Update to 2.6.4.

* Sun Oct 21 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.6.3-9
- Patch the wx-2.6-config script and move the common files to /usr/lib.
  This shall fix the multiarch conflict in compat-wxGTK26-devel (#340931).

compiz-0.6.2-4.fc9
------------------
* Tue Nov 06 2007 Stepan Kasal <skasal at redhat.com> - 0.6.2-4
- Fix a typo in description of the main package.
- All descriptions should end with a dot (unlike the summary line)
compiz-bcop-0.6.0-1.fc9
-----------------------

compiz-fusion-0.6.0-5.fc9
-------------------------

compiz-fusion-extras-0.6.0-1.fc9
--------------------------------

compiz-manager-0.6.0-3.fc9
--------------------------

compizconfig-python-0.6.0-1.fc9
-------------------------------

conduit-0.3.4-2.fc9
-------------------
* Tue Oct 30 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.3.4-2
- add missing Req: dbus-python, pygtk2

* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.3.4-1
- v 0.3.4
- another fix for bz #255221 and also #315991, conflict with tomboy < xxx
- gmail icon issue automatically resolved in 0.3.4; bz #248503
- added missing Req: PyXML (bz #332311)
- remove pygoocanvas-api-0.9.patch; no longer needed

conky-1.4.8-1.fc9
-----------------
* Sun Oct 21 2007 Miroslav Lichvar <mlichvar at redhat.com> - 1.4.8-1
- Update to 1.4.8
- Enable mpd, rss and wireless support
- Update license tag

control-center-1:2.20.1-6.fc9
-----------------------------
* Wed Oct 24 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-6
- Fix the orca command in the default applications capplet (#351471)

* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-5
- Rebuild against new dbus-glib

* Fri Oct 19 2007 - Ray Strode <rstrode at redhat.com> - 2.20.1-4
- Update libxklavier buildreq (bug 339731)

coreutils-6.9-12.fc9
--------------------
* Fri Nov 02 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-12
- added some upstream supported dircolors TERMs(#239266)
- fixed du output for unaccesible dirs(#250089)
- a bit of upstream tunning for symlinks

* Tue Oct 30 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-11
- allow cp -a to rewrite file on different filesystem(#219900)
  (based on upstream patch)

* Mon Oct 29 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-10
- modified coreutils-i18n.patch because of sort -R in
  a non C locales(fix by Andreas Schwab) (#249315)

cpio-2.9-5.fc9
--------------
* Thu Nov 01 2007 Radek Brich <rbrich at redhat.com> 2.9-5
- upstream patch for CVE-2007-4476 (stack crashing in safer_name_suffix)

cppunit-1.12.0-3.fc9
--------------------

crm114-0-0.6.20070810.fc9
-------------------------
* Sat Oct 27 2007 Dominik Mierzejewski <rpm at greysector.net> 0-0.6.20070810
- updated to 20070810 "BlameTheSegfault"
- dropped obsolete patch

crontabs-1.10-19.fc9
--------------------
* Mon Oct 22 2007 Marcela Maslanova <mmaslano at redhat.com> 1.10-19
- run-parts log also end of each job (patch from J. Kamens)
- Resolves: rhbz#303081

cryptix-0:3.2.0-9jpp.2
----------------------
* Wed Oct 04 2006 Matt Wringe <mwringe at redhat.com> 3.2.0-9jpp.2
- Apply patch (from Oliver Falk) to allow for building on a 1.5 jdk
  (Bug #318181)

crypto-utils-2.3-6
------------------
* Tue Oct 30 2007 Joe Orton <jorton at redhat.com> 2.3-6
- genkey: wording fix

* Wed Oct 24 2007 Joe Orton <jorton at redhat.com> 2.3-5
- genkey: skip the CA selection dialog; the CA-specific 
  instructions are all out-of-date
- man page updates, add man page for keyrand

ctapi-cyberjack-3.0.5-1.fc9
---------------------------
* Sat Oct 20 2007 Frank B??ttner <frank-buettner at gmx.net> - 3.0.5-1
- update to 3.0.5
 - fix project URL
 - fix license

cups-1:1.3.4-2.fc9
------------------
* Wed Nov 07 2007 Tim Waugh <twaugh at redhat.com> 1:1.3.4-2
- Applied patch to fix CVE-2007-4045 (bug #250161).
- Applied patch to fix CVE-2007-4352, CVE-2007-5392 and
  CVE-2007-5393 (bug #345101).

* Thu Nov 01 2007 Tim Waugh <twaugh at redhat.com> 1:1.3.4-1
- 1.3.4 (bug #361681).

curl-7.16.4-10.fc9
------------------
* Wed Oct 24 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-10
- correctly provide/obsolete curl-devel (#130251)

* Wed Oct 24 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-9
- create libcurl and libcurl-devel subpackages (#130251)

* Thu Oct 11 2007 Jindrich Novy <jnovy at redhat.com> 7.16.4-8
- list features correctly when curl is compiled against NSS (#316191)

cyrus-sasl-2.1.22-9.fc9
-----------------------
* Wed Nov 07 2007 Steve Conklin <sconklin at redhat.com> - 2.1.22-9
- Fixed a typo in the spec file

* Wed Nov 07 2007 Steve Conklin <sconklin at redhat.com> - 2.1.22-8
- Removed srp plugin source and added dist to NVR

dash-0.5.4-2.fc9
----------------

dbmail-2.2.7-1.fc9
------------------
* Wed Oct 31 2007 Bernard Johnson <bjohnson at symetrix.com> - 2.2.7-1
- 2.2.7-1
- removed unused thread references patch
- removed unused hup patch
- removed unused gmime segv patch
- license clarification
- dbmail: Initscript Review (bz #246901)

dbus-glib-0.74-1.fc9
--------------------
* Mon Oct 22 2007 Ray Strode <rstrode at redhat.com> - 0.74-1
- Update to 0.74

dbus-python-0.82.0-3.fc9
------------------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 0.82.0-3
- Rebuild against new dbus-glib

dejavu-fonts-2.21-1.fc9
-----------------------
* Sun Oct 28 2007 <nicolas.mailhot at laposte.net>
??? 2.21-1
??? 2.21 final

* Sat Oct 27 2007 <nicolas.mailhot at laposte.net>
??? 2.21-0.4.20071027svn2023
??? Fedora fontconfig files dropped (merged upstream)

* Thu Oct 25 2007 <nicolas.mailhot at laposte.net>
??? 2.21-0.3.20071025svn2022
 ??? Makefile patch dropped (merged upstream)
 ??? add -f to fc-cache calls
 ??? completely align LGC and FULL fontconfig rules
 ??? remove / from directory macros

deluge-0.5.6.2-1.fc9
--------------------
* Wed Oct 31 2007 Peter Gordon <peter at thecodergeek.com> - 0.5.6.2-1
- Update to new upstream bug-fix release (0.5.6.2)

* Tue Oct 30 2007 Peter Gordon <peter at thecodergeek.com> - 0.5.6.1-1
- Update to new upstream bug-fix release (0.5.6.1)
- Drop use-mt-boost build script patch (fixed upstream):
  - use-mt-boost.patch

* Sat Oct 27 2007 Peter Gordon <peter at thecodergeek.com> - 0.5.6-1
- Update to new upstream release (0.5.6)

devhelp-0.16.1-2.fc9
--------------------
* Thu Nov 01 2007 Matthew Barnes <mbarnes at redhat.com> - 0.16.1-2.fc9
- Rebuild against gecko-libs 1.8.1.8.

* Sat Oct 06 2007 Matthew Barnes <mbarnes at redhat.com> - 0.16.1-1.fc8
- Update to 0.16.1

* Tue Sep 11 2007 Matthew Barnes <mbarnes at redhat.com> - 0.16-1.fc8
- Update to 0.16

dhcp-12:3.1.0-7.fc9
-------------------
* Fri Oct 26 2007 David Cantrell <dcantrell at redhat.com> - 12:3.1.0-7
- libdhcp4client-devel requires openldap-devel

* Thu Oct 25 2007 David Cantrell <dcantrell at redhat.com> - 12:3.1.0-6
- Rename Makefile.dist to Makefile.libdhcp4client
- Spec file cleanups
- Include stdarg.h in libdhcp_control.h

* Thu Oct 25 2007 David Cantrell <dcantrell at redhat.com> - 12:3.1.0-5
- Remove chkconfig usage for ypbind in dhclient-script (#351211)
- Combine dhcp-static and dhcp-devel packages since there are no shared
  libraries offered
- Remove Requires: openldap-devel on dhcp-devel and libdhcp4client-devel
- Make libdhcp4client-devel require dhcp-devel (for libdhcp_control.h)
- Do not make dhcp-devel require the dhcp package, those are independent

dhcpv6-0.99.0-1.fc9
-------------------
* Thu Nov 08 2007 David Cantrell <dcantrell at redhat.com> - 0.99.0-1
- Upgraded to new upstream version, dhcpv6-0.99.0

* Wed Oct 24 2007 David Cantrell <dcantrell at redhat.com> - 0.10-52
- Remove DHCPv6.Cflags variable from libdhcp6client.pc
- Install dhcpv6 headers for libdhcp6client to /usr/include/dhcp6client
- Remove the libdhcp_control.h header file
- Extract full files from libdhcp6client patch and store as Sources
- Require dhcp-devel >= 12:3.1.0 for libdhcp_control.h

dialog-1.1-3.20071028.fc9
-------------------------
* Mon Nov 05 2007 Miroslav Lichvar <mlichvar at redhat.com> - 1.1-3.20071028
- update to 1.1-20071028
- fix multilib conflicts (#341001)
- use shared library, drop static
- merge review fixes (#225693)

* Fri Aug 17 2007 Harald Hoyer <harald at redhat.com> - 1.1-2.20070704
- changed license to LGPLv2

* Thu Jul 05 2007 Harald Hoyer <harald at redhat.com> - 1.1-1.20070704
- version 1.1-20070704

diffutils-2.8.1-19.fc9
----------------------
* Tue Nov 06 2007 Tim Waugh <twaugh at redhat.com> 2.8.1-19
- Rebuilt.

* Tue Nov 06 2007 Tim Waugh <twaugh at redhat.com> 2.8.1-18
- Fixed multibyte speed improvement patch (bug #363831).

dmidecode-1:2.9-1.27.1.fc9
--------------------------
* Mon Oct 22 2007 Prarit Bhargava <prarit at redhat.com> - 1:2.9
- rebuild with version 2.9

dmraid-1.0.0.rc14-4.fc9
-----------------------
* Mon Oct 22 2007 Ian Kent <ikent at redhat.com> - 1.0.0.rc14-4
- Fix SEGV on "dmraid -r -E" (bz 236891).

* Wed Apr 18 2007 Peter Jones <pjones at redhat.com> - 1.0.0.rc14-3
- Fix jmicron name parsing (#219058)

* Mon Feb 05 2007 Alasdair Kergon <agk at redhat.com> - 1.0.0.rc14-2
- Add build dependency on new device-mapper-devel package.
- Add dependency on device-mapper.
- Add post and postun ldconfig.
- Update BuildRoot and Summary.

docbook-dtds-1.0-34.fc9
-----------------------
* Tue Oct 23 2007 Ondrej Vasik <ovasik at redhat.com> - 1.0-34
- corrected most of rpmlint issues
- (PreReq, tab/spaces , wrong permissions on some files,
-  wrong file end encoding of txt files, non config files
-  in /etc, some requires issues, versioned provides and
-  obsoletes, fixed license tag)

* Fri Oct 19 2007 Ondrej Vasik <ovasik at redhat.com> - 1.0-33
- fixed wrong attributes for docs(#326581)

* Mon Oct 01 2007 Ondrej Vasik <ovasik at redhat.com> - 1.0-32
- DocBook 4.5 SGML and XML.(#312941)
- added dist tag

docbook-simple-1.1-3.fc9
------------------------
* Mon Nov 05 2007 Ondrej Vasik <ovasik at redhat.com> - 1.1-3
- merge review(#225701)
- spec modified to follow guidelines

* Wed Oct 24 2007 Ondrej Vasik <ovasik at redhat.com> - 1.1-2
- rpmlint check
- /etc/ files marked as config, fixed bad requirements
- cosmetic cleanup of spec file

docbook-slides-3.4.0-2.fc9
--------------------------
* Wed Oct 24 2007 Ondrej Vasik <ovasik at redhat.com> - 3.4.0-2
- rpmlint check
- fixed wrong requirements, some cosmetic changes
- /etc/ files marked as config

docbook-style-dsssl-1.79-5.fc9
------------------------------
* Mon Nov 05 2007 Ondrej Vasik <ovasik at redhat.com> - 1.79-5
- rpmlint cleanup
- fixed summary, dist tag, license tag, cosmetic spec cleanup

docbook-style-xsl-1.73.2-4.fc9
------------------------------
* Tue Nov 06 2007 Ondrej Vasik <ovasik at redhat.com> 1.73.2-4
- Merge review(#225704)
- spec file modified to follow guidelines

* Wed Oct 24 2007 Ondrej Vasik <ovasik at redhat.com> 1.73.2-3
- rpmlint check
- fixed License Tag, Requires and some cosmetic issues

docbook-utils-0.6.14-12.fc9
---------------------------
* Mon Nov 05 2007 Ondrej Vasik <ovasik at redhat.com> 0.6.14-12
- Merge Review(#225705)
- corrected some other packaging guidelines issues

* Thu Nov 01 2007 Ondrej Vasik <ovasik at redhat.com> 0.6.14-11
- rpmlint check
- fixed: dist tag, summary ended with dot, license tag,
  versioned provides/obsoletes + some cosmetic changes

dovecot-1:1.0.7-2.fc9
---------------------
* Mon Nov 05 2007 Tomas Janousek <tjanouse at redhat.com> - 1:1.0.7-2
- update to latest upstream stable (1.0.7)
- added the wibnind patch (#286351)

driftnet-0.1.6-15.20040426cvs.fc9
---------------------------------
* Sun Oct 21 2007 Paul Wouters <paul at xelerance.com> - 0.1.6-15.20040426cvs
- Fixed endian patch

* Sun Oct 21 2007 Paul Wouters <paul at xelerance.com> - 0.1.6-13.20040426cvs
- Commented out a g_free(template) that broke tmpdir. I don't
  understand why though. Since template is never used again.
  This is https://bugzilla.redhat.com/show_bug.cgi?id=201412

dvdisaster-0.70.4-3.fc9
-----------------------
* Tue Nov 06 2007 Dmitry Butskoy <Dmitry at Butskoy.name> - 0.70.4-3
- Add xdg-open patch (by Ville Skytta, #365401)

* Tue Aug 28 2007 Dmitry Butskoy <Dmitry at Butskoy.name>
- Correct Source0 url

* Thu Aug 16 2007 Dmitry Butskoy <Dmitry at Butskoy.name>
- Change License tag to GPLv2+

dvgrab-3.0-2.fc9
----------------

ebtables-2.0.8-4.fc9
--------------------
* Sun Oct 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.0.8-4
- bump to 2.0.8-2 from upstream
- keep _libdir/ebtables, even though upstream just moved away from it.

eclipse-phpeclipse-1.1.8-17.fc9
-------------------------------
* Sat Oct 20 2007 Brandon Holbrook <fedora at theholbrooks.org> 1.1.8-17
- Reference php5 instead of php4 in httpd.conf [bug 314831]

ed2k_hash-0.4.0-5.fc9
---------------------
* Wed Oct 24 2007 Dominik Mierzejewski <rpm at greysector.net> 0.4.0-5
- fix hash miscalculation on 64bit (bug #255321)
- fix compilation warnings

egoboo-2.4.4b-1.fc9
-------------------
* Mon Oct 29 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 2.4.4b-1
- New upstream release 2.4.4b

egoboo-data-2.4.4b-1.fc9
------------------------

eiciel-0.9.5-1.fc9
------------------
* Thu Oct 25 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.9.5-1
- update to 0.9.5

* Tue Aug 21 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.9.4-2
- bump

ekg2-0.1.1-1.fc9
----------------
* Wed Oct 24 2007 Dominik Mierzejewski <rpm at greysector.net> 0.1.1-1
- updated to 0.1.1 (really fixes bug 278181)
- move docs charset conversion and copying around to prep

emacs-22.1-8.fc9
----------------
* Tue Nov 06 2007 Chip Coldwell <coldwell at redhat.com> 22.1-8
- fix insufficient safe-mode checks (Resolves: bz367601)

* Thu Nov 01 2007 Chip Coldwell <coldwell at redhat.com> 22.1-7
- Update rpm-spec-mode to the current upstream, drop compat patch (bz306841)

* Wed Oct 24 2007 Jeremy Katz <katzj at redhat.com> - 22.1-6
- Update rpm-spec-mode to the current upstream (#306841)

empathy-0.14-5.fc9
------------------
* Fri Oct 19 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-5
- Backport upstream patch to fixes crashes when using drag-and-drop of a
  contact from the buddy list to the current conversation window to initiate a
  conversation:
    + svn380-fix-contact-DnD.patch 
- Resolves: GNOME bug 483168 (crash in Empathy Instant Messenger: I had
  dragged a contact ...)

* Tue Oct 16 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-4
- Depend on Salut and Gabble to enable XMPP by default. Otherwise, Empathy
  is essentially useless due to the need to install an external connection
  manager. Also, add a README.ConnectionManagers to the installed
  documentation which lists other possibilities.
- Resolves: bug 308871 (Make empathy dependent at least on telepathy-gabble)
  and bug 334221 (Default empathy install is useless).

* Wed Oct 10 2007 Peter Gordon <peter at thecodergeek.com> - 0.14-3
- Enable VoIP support for those brave enough to test/break/debug it (F9+
  only). Though it is functional, it is still deemed rather unstable by
  upstream. Use it at your own risk. :)

environment-modules-3.2.6-1.fc9
-------------------------------
* Fri Nov 02 2007 - Orion Poplawski <orion at cora.nwra.com> - 3.2.6-1
- Update to 3.2.6

eog-2.20.1-2.fc9
----------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Rebuild against new dbus-glib

epiphany-2.20.1-3.fc9
---------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-3
- Rebuild against new dbus-glib

* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Add patch to allow epiphany to use the plugins wrapped by
  nspluginwrapper (#334751)

* Tue Oct 16 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1

esound-1:0.2.38-6.fc9
---------------------

evince-2.20.1-2.fc9
-------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Rebuild against new dbus-glib

evolution-2.21.1-2.fc9
----------------------
* Tue Oct 30 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.1-2.fc9
- Attempt to split the gnome-pilot stuff into a separate
  evolution-conduits subpackage (RH bug #178155).

* Mon Oct 29 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1-1.fc9
- Update to 2.21.1
- Remove redundant requirements.
- Bump EDS requirement to 2.21.1.
- Bump gtkhtml requirement to 3.17.1.
- Backup/restore plugin got moved from standard to experimental.
- Revert the per-component menu items (RH bug #222105, #241462, #293771).
- Show the switcher buttons by default (RH bug #186403).
- Alter the desktop file Name and Comment.
- Disable patch for GNOME bug #376991 for now.  It may be contributing
  to password prompting problems as described in RH bug #296671.
- Remove patch for GNOME bug #417999 (fixed upstream).
- Remove patch for GNOME bug #476040 (fixed upstream).
- Remove patch for GNOME bug #477045 (fixed upstream).

* Mon Oct 15 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.1-2.fc8
- Fix a broken zoom icon.

evolution-data-server-2.21.1-1.fc9
----------------------------------
* Mon Oct 29 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1.1-fc9
- Update to 2.21.1
- Bump eds_base_version to 2.22.
- Remove patch for RH bug #212106 (fixed upstream).
- Remove patch for GNOME bug #417999 (fixed upstream).

* Fri Oct 26 2007 Matthew Barnes <mbarnes at redhat.com> - 1.12.1-4.fc9
- Remove the use_gtk_doc macro.
- Remove redundant requirements.
- Use the name tag where appropriate.
- Add an evolution-data-server-doc subpackage.

* Thu Oct 18 2007 Matthew Barnes <mbarnes at redhat.com> - 1.12.1-3.fc9
- Porting a couple patches over from RHEL5:
- Add patch for RH bug #212106 (address book error on fresh install).
- Add patch for RH bug #215702 (bad search filter for LDAP address books).

evolution-exchange-2.21.1-2.fc9
-------------------------------
* Sun Nov 04 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1-2.fc9
- Remove obsolete patches.

* Mon Oct 29 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.1-1.fc9
- Update to 2.21.1
- Remove redundant requirements.
- Bump evo_version and eds_version to 2.21.1.

evolution-remove-duplicates-0.0.3-2.fc9
---------------------------------------
* Fri Nov 02 2007 Matthew Barnes <mbarnes at redhat.com> - 0.0.3-2.fc9
- Rebuild for Evolution 2.22.

evolution-sharp-0.15.1-1.fc9
----------------------------
* Wed Oct 31 2007 Matthew Barnes <mbarnes at redhat.com> - 0.15.1-1.fc9
- Update to 0.15.1

exaile-0.2.11-2.fc9
-------------------
* Tue Nov 06 2007 Deji Akingunola <dakingun at gmail.com> - 0.2.11-2
- Rebuild for firefox-2.0.0.9

* Mon Oct 22 2007 Deji Akingunola <dakingun at gmail.com> - 0.2.11-1
- New release

fedora-ds-base-1.1.0-2.0.fc9
----------------------------
* Wed Nov 07 2007 Rich Megginson <rmeggins at redhat.com> - 1.1.0-2.0
- This is the beta2 release
- new file added to package - /etc/sysconfig/dirsrv - for setting
- daemon environment as is usual in other linux daemons

fedora-logos-8.0.2-1.fc9
------------------------

fedora-release-8.90-3
---------------------
* Wed Oct 10 2007 Jesse Keating <jkeating at redhat.com> - 8.90-3
- Bump for cvs oopsie

* Wed Oct 10 2007 Jesse Keating <jkeating at redhat.com> - 8.90-2
- Add the gpg info to the devel repo

* Wed Oct 03 2007 Jesse Keating <jkeating at redhat.com> - 8.90-1
- First build for Fedora 9 development.

fedora-release-notes-8.90-1
---------------------------
* Mon Oct 22 2007 Paul W. Frields <stickster at gmail.com> - 8.90-1
- Update for F-9 development branch

* Mon Oct 22 2007 Paul W. Frields <stickster at gmail.com> - 8.0.0-1
- Update for final release

* Wed Sep 26 2007 Bill Nottingham <notting at redhat.com> - 7.92-2
- fix symlinking (#306781)
- set license tag -> Open Publication

festival-1.96-2.fc9
-------------------
* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com>1.96-2
- fix a typo in a summary and in festival-1.96-nitech-proclaimvoice.patch
- Resolves: #239216

firefox-2.0.0.9-1.fc9
---------------------
* Mon Nov 05 2007 Martin Stransky <stransky at redhat.com> 2.0.0.9-1
- updated to the latest upstream

* Wed Oct 31 2007 Martin Stransky <stransky at redhat.com> 2.0.0.8-3
- added mozilla-plugin-config to startup script

firstboot-1.4.39-1.fc9
----------------------

fish-1.22.3-5.fc9
-----------------
* Wed Oct 31 2007 Oliver Falk <oliver at linux-kernel.at>	- 1.22.3-5
- Fix glibc's open check, by providing mode, instead of working
  around...

* Wed Oct 31 2007 Oliver Falk <oliver at linux-kernel.at>	- 1.22.3-4
- Update URL; Fixes bz#359451

flashrom-0-0.4.20071028svn2897.fc9
----------------------------------
* Sun Oct 28 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.4.20071028svn2897
- typo fix

* Sun Oct 28 2007 Peter Lemenkov <lemenkov at gmail.com> 0-0.3.20071028svn2897
- svn ver. 2897 (support for Gigabyte M61P-S3 SPI m/b, Am29LV040B chip)
- flashrom executable now sits in sbindir since it's administrator's tool

flow-tools-0.68.2-1.fc9
-----------------------
* Sat Nov 03 2007 Paul P Komkoff Jr <i at stingr.net> - 0.68.2-1
- New upstream release

* Thu Sep 13 2007 Orion Poplawski <orion at cora.nwra.com> - 0.68.1-2
- Add user and init scripts

fontconfig-2.4.92-1.fc9
-----------------------
* Thu Oct 25 2007 Behdad Esfahbod <besfahbo at redhat.com> - 2.4.92-1
- Update to 2.4.92.
- Mark /etc/fonts/conf.d/* as config(noreplace).
- Remove most of our conf file, all upstreamed except for
  75-blacklist-fedora.conf that I'm happily dropping.  Who has
  Hershey fonts these days...
- ln upstream'ed 25-unhint-nonlatin.conf from conf.avail in conf.d
- Add 25-no-bitmap-fedora.conf which is the tiny remaining bit
  of conf that didn't end up upstream.  Can get rid of it in the
  future, but not just yet.

* Thu Oct 25 2007 Behdad Esfahbod <besfahbo at redhat.com> - 2.4.91-1
- Update to 2.4.91.
- Add /usr/local/share/fonts to default config. (#147004)
- Don't rebuild docs, to fix multilib conflicts. (#313011)
- Remove docbook and elinks BuildRequires and stuff as we don't
  rebuild docs.

fontforge-20071002-1.fc9
------------------------
* Sun Oct 21 2007 Nicolas Mailhot <nicolas.mailhot at laposte.net>
??? 20071002-1
??? quick & dirty version bump to start working on F9 font packages

frotz-2.43-6.fc9
----------------
* Wed Oct 31 2007 Chris Grau <chris at chrisgrau.com> 2.43-6
- Fixed license tag.

ftp-0.17-43.fc9
---------------
* Mon Oct 22 2007 Marcela Maslanova <mmaslano at redhat.com> - 0.17-43
- feature: for cmd size is switching to TYPE_I automatized
- bug: ftp leaks socket fds when it fails to open a file (#315241)
- rhbz#306191

fwfstab-0.02-2.fc9
------------------
* Sun Oct 21 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.02-2
- Add pyparted and kudzu requires

* Thu Oct 18 2007 Stewart Adam <s.adam AT diffingo DOT com> 0.02-1
- Update to version 0.02
- Drop X-Fedora from .desktop file
- Why do I define the fedora version and never use it?

ganglia-3.0.5-2.fc9
-------------------
* Wed Oct 24 2007 Jarod Wilson <jwilson at redhat.com> 3.0.5-2
- Reorg packages to fix multilib conflicts (#341201)

gawk-3.1.5-16.fc9
-----------------
* Wed Oct 31 2007 Stepan Kasal <skasal at redhat.com> - 3.1.5-16
- Add gawk-3.1.5-quote-sticky.patch
- Resolves: #299551
- Add gawk-3.1.5-test-lc_num1.patch, a test for that bug.
- BuldRequire autoconf and automake, for the test patch.
- Add coment explaining why bison is buildrequired.
- Remove BuildRequire: flex.

gchempaint-0.8.4-1.fc9
----------------------
* Tue Oct 30 2007 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.8.4-1
- Updated to 0.8.4

gcompris-8.4.2-1.fc9
--------------------
* Wed Oct 31 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 8.4.2-1
- New upstream bugfix release 8.4.2

gdb-6.7.1-3.fc9
---------------
* Sun Nov 04 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.7.1-3
- Fix `errno' resolving on recent glibc with broken DW_AT_MIPS_linkage_name.
- Imported new test for 6.7 PPC hiding of call-volatile parameter register.

* Sat Nov 03 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.7.1-2
- Backport `Breakpoints at multiple locations' patch primarily for C++.

* Thu Nov 01 2007 Jan Kratochvil <jan.kratochvil at redhat.com> - 6.7.1-1
- Upgrade to GDB 6.7.1.  Drop redundant patches, forward-port remaining ones.

gdl-0.9-0.pre6.fc9
------------------
* Thu Nov 01 2007 - Orion Poplawski <orion at cora.nwra.com> - 0.9-0.pre6
- Update to 0.9pre6

gdm-1:2.21.1-0.2007.10.30.1.fc9
-------------------------------
* Tue Oct 30 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.1-0.2007.10.30.1
- Update to today's snapshot

* Tue Oct 23 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.1-0.2007.10.23.1
- Update to today's snapshot

* Mon Oct 22 2007 Ray Strode <rstrode at redhat.com> - 1:2.21.1-0.2007.10.22.1
- Add a snapshot gdm trunk, totally different unfinished ui...

genius-1.0.0-2.fc9
------------------
* Wed Nov 07 2007 Gerard Milmeister <gemi at bluewin.ch> - 1.0.0-2
- added buildreq mpfr-devel

* Wed Oct 24 2007 Gerard Milmeister <gemi at bluewin.ch> - 1.0.0-1
- new release 1.0.0

ghc-6.8.1-1.fc9
---------------
* Sun Nov 04 2007 Michel Salim <michel.sylvan at gmail.com> - 6.8.1-1
- Update to 6.8.1

* Sat Sep 29 2007 Bryan O'Sullivan <bos at serpentine.com> - 6.8.0.20070928-2
- add happy to BuildRequires

* Sat Sep 29 2007 Bryan O'Sullivan <bos at serpentine.com> - 6.8.0.20070928-1
- prepare for GHC 6.8.1 by building a release candidate snapshot

ghostscript-8.60-5.fc9
----------------------

gimp-2:2.4.1-1.fc9
------------------
* Wed Oct 31 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.1-1
- version 2.4.1

  Changes in GIMP 2.4.1
  =====================

  - fixed a minor display rendering problem
  - improved the workaround for broken graphics card drivers (bug #421466)
  - fixed a crash with broken scripts and plug-ins (bug #490055)
  - fixed potential syntax error in configure script (bug #490068)
  - fixed parsing of floating point numbers in Script-Fu (bug #490198)
  - fixed potential crash when converting an indexed image to RGB (bug #490048)
  - update the histogram while doing color corrections (bug #490182)
  - fixed another crash with broken plug-ins (bug #490617).
  - translation updates

* Mon Oct 29 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-4
- use either htmlview or xdg-open in documentation instead of firefox (#355801)

* Thu Oct 25 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-3
- add epoch to obsoletes

git-1.5.3.4-2.fc9
-----------------
* Wed Oct 24 2007 Lubomir Kundrak <lkundrak at redhat.com> 1.5.3.4-2
- git-Perl requires Error package

glib-java-0.2.6-11.fc9
----------------------
* Tue Nov 06 2007 Stepan Kasal <skasal at redhat.com> - 0.2.6-11
- -devel should require pkgconfig
- remove the dances with %{java_pkg_prefix} and name_base
- cosmetic change to the descriptions
- add dash to the jar name (between name and version)
- Resolves: #192881

* Mon Apr 23 2007 Stepan Kasal <skasal at redhat.com> - 0.2.6-10
- Move /usr/include/glib-java/jg_jnu.h to devel.

* Fri Apr 20 2007 Stepan Kasal <skasal at redhat.com> - 0.2.6-9
- Adhere to packaging guidelines.
- Resolves: #225807
- Make sure we will notice when the project starts using the NEWS file.

glib2-2.14.3-1.fc9
------------------
* Wed Nov 07 2007 Matthias Clasen <mclasen at redhat.com> - 2.14.3-1
- Update to 2.14.3, including a new version of PCRE that
  fixes several vulnerabilities

glpi-0.70-0.3.rc2.fc9
---------------------
* Thu Nov 01 2007 Remi Collet <Fedora at FamilleCollet.com> - 0.70-0.3.rc2
- correct source
gnash-0.8.1-6.fc9
-----------------
* Sat Oct 27 2007 Patrice Dumas <pertusus at free.fr> 0.8.1-6
- add patch from Martin Stransky to fix wrapped plugin #281061

gnokii-0.6.20-1.fc9
-------------------
* Thu Nov 01 2007 - Bastien Nocera <bnocera at redhat.com> - 0.6.20-1
- Update to 0.6.20

gnomad2-2.9.0-2.fc9
-------------------
* Wed Oct 31 2007 Linus Walleij <triad at df.lth.se> 2.9.0-2
- Pick up new dependency on libmtp.so.7.

gnome-applet-music-2.2.1-1.fc9
------------------------------
* Mon Oct 29 2007 Peter Gordon <peter at thecodergeek.com> - 2.2.1-1
- Update to new upstream bugfix release (2.2.1)

gnome-applets-1:2.20.0-10.fc9
-----------------------------
* Mon Oct 29 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0-10
- Fix a number of problems in the weather applet

* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0-9
- Rebuild against new dbus-glib

* Sun Oct 21 2007 Matthias Clasen <mclasen at redhat.com> - 1:2.20.0-8
- Update weather info when going online

gnome-bluetooth-0.9.1-4.fc9
---------------------------
* Mon Oct 22 2007 - Ondrej Vasik <ovasik at redhat.com> - 0.9.1-4
- marked gnome-obex-server.schemas as config file
- changed upstream URL

gnome-chemistry-utils-0.8.4-1.fc9
---------------------------------
* Tue Oct 30 2007 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.8.4-1
- Updated to 0.8.4

gnome-launch-box-0.4-5.fc9
--------------------------

gnome-libs-1:1.4.2-7.fc9
------------------------
* Mon Oct 29 2007 Paul Howarth <paul at city-fan.org> 1:1.4.2-7
- Fix buffer overflow in popthelp (#354911)

gnome-media-2.20.1-7.fc9
------------------------
* Mon Oct 22 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-7
- Fix spurious '%' in the scriplets, spotted by Yanko Kaneti
  <yaneti at declera.com>

* Wed Oct 17 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-6
- Show the "Front" track by default (#335121)

* Wed Oct 10 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-5
- Install the mixer's schema file (#186791)

gnome-mount-0.7-2.fc9
---------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.7-2
- Rebuild against new dbus-glib

* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 0.7-1.fc9
- Update to latest upstream release

* Fri Aug 31 2007 David Zeuthen <davidz at redhat.com> - 0.7-0.svn20070831.fc9
- New SVN snapshot

gnome-panel-2.20.1-4.fc9
------------------------
* Mon Oct 29 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-4
- Intlclock: make default units work correctly

* Sun Oct 28 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-3
- Intlclock: add weather preferences, show temperature in panel

* Sat Oct 20 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Fix some issues with the offset display in the intlclock

gnome-password-generator-1.5-2.fc9
----------------------------------

gnome-phone-manager-0.30-1.fc9
------------------------------

gnome-power-manager-2.20.0-7.fc9
--------------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-7
- Rebuild against new dbus-glib

gnome-python2-extras-2.19.1-9.fc9
---------------------------------
* Thu Oct 25 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-9.fc9
- Require gecko-libs instead of firefox (RH bug #352111).

* Wed Oct 24 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-8.fc9
- Rebuild against firefox 2.0.0.8.

* Fri Oct 05 2007 Matthew Barnes <mbarnes at redhat.com> - 2.19.1-7.fc8
- Use ifarch instead of ExcludeArch to skip building the gdl subpackage
  on ppc64.  ExcludeArch affects the whole spec.

gnome-screensaver-2.20.0-9.fc9.1
--------------------------------

gnome-session-2.20.1-2.fc9
--------------------------
* Tue Oct 30 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.1-2
- Enable sound by default, without looking at the prefs

gnome-vfs2-2.20.0-4.fc9
-----------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Rebuild against new dbus-glib

* Tue Oct 16 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-3
- Also avoid showing /var/tmp as an icon on the desktop (#335241)

* Mon Oct 15 2007 David Zeuthen <davidz at redhat.com> - 2.20.0-2
- Don't show /var/log/audit on the desktop (#333041)

gnome-volume-manager-2.17.0-10.fc9
----------------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.17.0-10
- Rebuild against new dbus-glib

* Fri Oct 05 2007 - Bastien Nocera <bnocera at redhat.com> - 2.17.0-9
- Change the default CD player to rhythmbox (#278331)

gnome-web-photo-0.3-5.fc9
-------------------------
* Thu Oct 25 2007 - Bastien Nocera <bnocera at redhat.com> - 0.3-5
- Rebuild for new Gecko, tighten dependencies

gnomesword-2.3.1-2.fc9
----------------------
* Tue Nov 06 2007 Deji Akingunola <dakingun at gmail.com> - 2.3.1-2
- Rebuild for firefox-2.0.0.9

* Mon Nov 05 2007 Deji Akingunola <dakingun at gmail.com> - 2.3.1
- Update to version 2.3.1

gnotime-2.2.3-1.fc9
-------------------
* Fri Oct 26 2007 Toshio Kuratomi <toshio at fedoraproject.org> - 2.2.3-1
- Upstream bugfix release.

gnu-smalltalk-2.3.6-6.fc9
-------------------------
* Thu Oct 25 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.3-4-6
- Add upstream multilib patch

* Wed Oct 24 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.3.6-4
- Another try to fix the multilib issue

* Mon Oct 22 2007 Jochen Schmitt <Jochen herr-schmitt de> 2.3.6-3
- Create new subpackage to solve mulitlib issue (#341341)

gnuplot-4.2.2-4.fc9
-------------------
* Tue Nov 06 2007 Ivana Varekova <varekova at redhat.com> - 4.2.2-4
- fix webify.pl permissions
- add eg7.eps to documentation

* Thu Nov 01 2007 Ivana Varekova <varekova at redhat.com> - 4.2.2-3
- add emacs buildrequires
- add emacs-* macros
- remove useless iconv

* Thu Oct 25 2007 Ivana Varekova <varekova at redhat.com> - 4.2.2-2
- rename emacs subpackage, split intwo two parts
- add font directories
- clean spec file

gparted-0.3.3-13.fc9
--------------------

gpodder-0.10.1-1.fc9
--------------------
* Tue Oct 30 2007 Jef Spaleta <jspaleta at gmail.com> 0.10.1-1
- New Upstream version
- Channel list selection/update bugfixes
- Really load channel metadata
- See upstream website for full release notes

gputils-0.13.5-1.fc9
--------------------
* Sun Oct 28 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.13.5-1
- New upstream version
  - Patches to improve man pages formatting
  - Use macros for rm and make

gscan2pdf-0.9.17-2.fc9
----------------------
* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.17-2
- license clarification

* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.9.17-1
- v 0.9.17

gsl-1.10-9.fc9
--------------
* Thu Nov 01 2007 Ivana Varekova <varekova at redhat.com> - 1.10-9
- source file change
- spec cleanup

* Thu Nov 01 2007 Ivana Varekova <varekova at redhat.com> - 1.10-8
- fix man-pages directories

* Tue Oct 30 2007 Ivana Varekova <varekova at redhat.com> - 1.10-7
- add man pages

gtk-nodoka-engine-0.6-5.fc9
---------------------------

gtk-recordmydesktop-0.3.6-1.fc9.1
---------------------------------
* Sun Oct 21 2007 Sindre Pedersen Bj??rdal <foolish[AT]guezz.net> - 0.3.6-1
- New version
- Update URL

gtk2-2.12.1-5.fc9
-----------------

gtk2hs-0.9.12.1-4.fc9
---------------------
* Wed Nov 07 2007 Bryan O'Sullivan <bos at serpentine.com> - 0.9.12.1-4
* Revert to 0.9.12 spec file

* Thu Aug 16 2007 Jens Petersen <petersen at redhat.com>
- update License field

* Fri Jul 27 2007 Bryan O'Sullivan <bos at serpentine.com> - 0.9.12-1
- update to 0.9.12 release

gtkhtml3-3.17.1-1.fc9
---------------------
* Mon Oct 29 2007 Matthew Barnes <mbarnes at redhat.com> - 3.17.1-1.fc9
- Update to 3.17.1
- Remove patch for GNOME bug #443850 (fixed upstream).

gtkterm-0.99.5-6.fc9
--------------------
* Wed Nov 07 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.99.5-6
- Add patch adding a scrollback-buffer (configurable through gtktermrc)
  by Dan Horak (bz 369491)

gtranslator-1.1.7-7.fc9
-----------------------
* Tue Oct 23 2007 Sindre Pedersen Bjordal <foolish at guezz.net> - 1.1.7-7
- Add patch to fix scrollkeeper configure issue

* Tue Oct 02 2007 Sindre Pedersen Bjordal <foolish at guezz.net> - 1.1.7-5
- Add missing dependency on which

* Mon Sep 24 2007 Jesse Keating <jkeating at redhat.com> - 1.1.7-4
- Bump release for upgrade path

gts-0.7.6-8.fc9
---------------
* Sun Oct 21 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.7.6-8
- Address BZ 341431:
  - Rework gts-config.
  - Rework gts.pc.
  - Regenerate gts-0.7.6-pkg_config.diff.

guile-5:1.8.3-1.fc9
-------------------
* Mon Oct 22 2007 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.8.3-1
- update to 1.8.3

* Wed Aug 22 2007 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.8.2-2
- update license tag
- redirect guile output in triggerin script

* Tue Jul 17 2007 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.8.2-1
- update to 1.8.2
- remove dot from -devel summary, convert goops.info to UTF-8

hal-0.5.10-2.fc9
----------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.5.10-2
- Rebuild against new dbus-glib
hal-info-20071030-1.fc9
-----------------------
* Tue Oct 30 2007 David Zeuthen <davidz at redhat.com> - 20071030-1.fc9
- Update to latest upstream release

* Thu Oct 11 2007 David Zeuthen <davidz at redhat.com> - 20071011-1.fc9
- Update to latest upstream release

* Tue Sep 25 2007 David Zeuthen <davidz at redhat.com> - 20070925-1.fc9
- Update to latest release.

hardinfo-0.4.2.3-1.fc9
----------------------
* Sun Nov 04 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.4.2.3-1
- Update to new upstream version
- Drop obsolete patches

hdf-4.2r2-4.fc9
---------------
* Mon Oct 29 2007 Patrice Dumas <pertusus at free.fr> 4.2r2-4
- install the netcdf.h file that describes the netcdf2 hdf enabled
  API

* Mon Oct 29 2007 Patrice Dumas <pertusus at free.fr> 4.2r2-3
- ship hdf enabled nc* utils as hnc*
- add --disable-netcdf that replaces HAVE_NETCDF
- keep include files timestamps, and have the same accross arches
- fix multiarch difference in include files (#341491)

* Wed Oct 17 2007 Patrice Dumas <pertusus at free.fr> 4.2r2-2
- update to 4.2r2

hedgewars-0.9.0-4.fc9
---------------------
* Mon Sep 10 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.9.0-4
- Remove ExcludeArch ppc64, freepascal is available on ppc64 now (bz 284401)
hexedit-1.2.12-7.fc9
--------------------
* Thu Nov 01 2007 Jiri Moskovcak <jmoskovc at redhat.com> - 1.2.12-7
- spec file cleanup

horde-3.1.5-1.fc9
-----------------
* Sat Oct 20 2007 Brandon Holbrook <fedora at theholbrooks.org> 3.1.5-1
- Update to 3.1.5

hotwire-0.600-1.fc9
-------------------
* Wed Nov 07 2007 Colin Walters <walters at redhat.com> - 0.600-1
- new upstream

hplip-2.7.10-1.fc9
------------------
* Mon Oct 22 2007 Tim Waugh <twaugh at redhat.com> 2.7.10-1
- 2.7.10.

* Fri Oct 12 2007 Tim Waugh <twaugh at redhat.com> 2.7.9-3
- Applied patch to fix remnants of CVE-2007-5208 (bug #329111).

* Tue Oct 09 2007 Tim Waugh <twaugh at redhat.com> 2.7.9-2
- Use raw instead of 1284.4 communication for LJ4000 series (bug #249191).
- Build requires openssl-devel.

hugin-0.6.1-11.fc9
------------------
* Mon Nov 05 2007 Bruno Postle <bruno at postle.net> 0.6.1-11
- fix for CVE-2007-5200 hugin unsafe temporary file usage
- bug #332401; bug #362851; bug #362861; bug #362871

hunspell-1.2.1-1.fc9
--------------------
* Mon Nov 05 2007 Caolan McNamara <caolanm at redhat.com> - 1.2.1-1
- latest version
hunspell-ga-4.3-1.fc9
---------------------
* Mon Nov 05 2007 Caolan McNamara <caolanm at redhat.com> - 4.3-1
- latest version
hunspell-hu-1.2.2-1.fc9
-----------------------
* Mon Nov 05 2007 Caolan McNamara <caolanm at redhat.com> - 1.2.2-1
- latest version

hunspell-pt-0.20071101-1.fc9
----------------------------
* Mon Nov 05 2007 Caolan McNamara <caolanm at redhat.com> - 0.20071101-1
- latest version

hwdata-0.207-2.fc9
------------------

ice-3.2.1-12.fc9
----------------
* Tue Oct 30 2007 Mary Ellen Foster <mefoster at gmail.com> 3.2.1-12
- Put the slice2java classes into a .jar file instead of as bare classes
- Incorporate all Ice 3.2.1 patches from ZeroC
- Fix templates path in icegridregistry.conf

* Fri Sep 07 2007 Mary Ellen Foster <mefoster at gmail.com> 3.2.1-11
- Also add Obsoletes: for the old zeroc names
- Fix bad date in changelog

* Wed Aug 29 2007 Mary Ellen Foster <mefoster at gmail.com> 3.2.1-9
- Add "with exceptions" to license tag
- Minor typo corrections in README.Fedora
- Move ruby sitearch files out of an "Ice/" subdirectory so that they're
  actually useful

icon-slicer-0.3-9.fc9
---------------------
* Mon Oct 22 2007 Adam Jackson <ajax at redhat.com> 0.3-9
- BuildRequires: popt-devel

icu-3.8-2.fc9
-------------
* Sat Oct 27 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-2
- add icu.icu6008.arm.padding.patch to fix an arm problem

* Tue Oct 02 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-1
- latest version

* Mon Sep 03 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-0.2.d02
- next release candidate

id3lib-3.8.3-18.fc9
-------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 3.8.3-18
- Fix multilib api documentation conflict (bz 341551)

ilmbase-1.0.0-3.fc9
-------------------

imlib2-1.4.0-4.fc9
------------------
* Tue Oct 23 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.4.0-4
- Fix building on ia64 (bz 349171)

imp-4.1.5-1.fc9
---------------
* Sat Oct 20 2007 Brandon Holbrook <fedora at theholbrooks.org> 4.1.5-1
- Upgraded to 4.1.5

ingo-1.1.4-1.fc9
----------------
* Sat Oct 20 2007 Brandon Holbrook <fedora at theholbrooks.org> 1.1.4-1
- Upgraded to 1.1.4

initng-0.6.10.1-3.fc9
---------------------
* Sat Oct 27 2007 Rudolf Kastl <che666 at gmail.com> 0.6.10.1-3
- Add selinux patch so initng also boots when it is disabled (thanks to Dragoran)

initng-ifiles-0.1.4-4.fc9
-------------------------
* Mon Oct 29 2007 Rudolf Kastl <che666 at gmail.com> 0.1.4-4
- Fixed another typo in the svn backport
- Changed rpcbind need to virtual/net/lo in svn backport
- Fixed thinko in dbus.ii

* Sun Oct 28 2007 Rudolf Kastl <che666 at gmail.com> 0.1.4-3
- Fixed paths for alot binaries to avoid buildreqs and make 
  everything boot actually
- Fixed the patch for udev to stop the hangs on boot
- Turned on verbosity when building

iperf-2.0.2-4.fc9
-----------------
* Sat Oct 27 2007 Gabriel Somlo <somlo at cmu.edu> 2.0.2-4
- replace usleep with sched_yield to avoid hogging CPU (bugzilla #355211)
iproute-2.6.23-1.fc9
--------------------
* Wed Oct 31 2007 Marcela Maslanova <mmaslano at redhat.com> - 2.6.23-1
- new version from upstrem 2.3.23

* Tue Oct 23 2007 Marcela Maslanova <mmaslano at redhat.com> - 2.6.22-5
- move files from /usr/lib/tc to /usr/share/tc
- remove listing files twice

* Thu Aug 30 2007 Marcela Maslanova <mmaslano at redhat.com> - 2.6.22-3
- package review #225903

iptables-1.3.8-6.fc9
--------------------
* Mon Nov 05 2007 Thomas Woerner <twoerner at redhat.com> 1.3.8-6
- fixed leaked file descriptor before fork/exec (rhbz#312191)
- blacklisting is not working, use "install X /bin/(true|false)" test instead
- return private exit code 150 for disabled ipv6 support
- use script name for output messages

iptraf-3.0.1-1.fc9
------------------
* Fri Nov 02 2007 Marcela Maslanova <mmaslano at redhat.com> - 3.0.1-1
- upgrade iptraf-3.0.1

irqbalance-2:0.55-7.fc9
-----------------------
* Thu Nov 01 2007 Neil Horman <nhorman at redhat.com> - 2:0.55-7
- Update to properly hadndle pid files (bz 355231)

jack-audio-connection-kit-0.103.0-5.fc9
---------------------------------------
* Sat Oct 20 2007 Andy Shevchenko <andy at smile.org.ua> 0.103.0-5
- fix timestamps to avoid multiarch conflicts (#341621)

jd-1.9.7-0.2.svn1488.fc9
------------------------
* Fri Nov 09 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.2.svn1488
- svn 1488

* Fri Nov 02 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyoa.c.jp> - 1.9.7-0.2.beta071101
- 1.9.7 beta 071101

k3b-0:1.0.4-2.fc9
-----------------
* Mon Nov 05 2007 Rex Dieter <rdieter[AT]fedorproject.org> - 0:1.0.4-2
- k3b-1.0.4
- omit -devel subpkg (f9+), fixes multiarch conflicts (#341651)

kasumi-2.3-1.fc9
----------------
* Wed Oct 31 2007 Akira TAGOH <tagoh at redhat.com> - 2.3-1
- New upstream release.
- kasumi-2.2-fix-dict-breakage.patch: removed.

kazehakase-0.5.0-1.fc9.1
------------------------
* Tue Nov 06 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.5.0-1.dist.1
- Rebuild against new gecko engine
- Switch to use gecko virtual dependency (bug 352091)

* Mon Oct 29 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.5.0-1
- 0.5.0

kdebase4-3.94.0-2.fc9
---------------------

kdebluetooth-1.0-0.37.beta8.fc9
-------------------------------
* Thu Nov 08 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-37.beta8
- Missing BR: automake, autoconf.

* Thu Nov 08 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-36.beta8
- Move BRs to main package to fix mock breakage.

* Wed Nov 07 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-35.beta8
- Fix multi-lib conflicts (#341731).

kdeedu-3.95.0-4.fc9
-------------------
* Wed Nov 07 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.95.0-4
- ExcludeArch: ppc ppc64 (#370771)

* Wed Nov 07 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.95.0-2
- Obsoletes/Provides: kalgebra

* Mon Nov 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 3.95.0-1
- kdeedu-3.95 (kde-4-beta4)

kdelibs4-3.95.0-2.fc9
---------------------
* Tue Nov 06 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.0-2
- fix parallel_devel patch (typo in KDE4_KPARTS_LIBRARY)

* Sun Nov 04 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.0-1
- kde-3.95.0 (kde4 dev platform rc1)

kdemultimedia-6:3.5.8-7.fc9
---------------------------
* Sat Oct 27 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 6:3.5.8-7
- fix typo in dependency

* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-6
- -libs: Obsoletes: %name ... to help out multilib upgrades
- -extras-libs: Obsoletes %name-extras ... likewise

* Thu Oct 25 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-5
- -extras-libs: (re)include libnoatun*.la

kdepimlibs-3.95.0-1.fc9
-----------------------
* Mon Nov 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.95.0-1
- kde-3.95.0 (kde4 dev platform rc1)

kdetv-0.8.9-7.fc9
-----------------
* Sat Oct 27 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.8.9-7
- Multiarch fixes (BZ 341781)

* Wed Aug 22 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.8.9-6
- Release bump for F8 mass rebuild
- Further license clarifications

* Sun Aug 12 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.8.9-5
- Updated license field due to new guidelines
- Fixed .desktop categories

kdiff3-0.9.92-10.fc9
--------------------
* Wed Nov 07 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.92-10
- Update desktop-file-install as suggest by Rex

* Wed Nov 07 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.92-8
- Use desktop-file-install for kdiff3plugin.desktop

* Tue Nov 06 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.92-7
- Update to 0.9.92
- Add /usr/share/applnk/.hidden/kdiff3plugin.desktop

kdmtheme-1.2.1-1.fc9
--------------------
* Sat Oct 27 2007 Chitlesh Goorah <chitlesh at fedoraproject.org> - 1.2.1-1
- New upstream release

kernel-xen-2.6-2.6.21.7-2886.fc9
--------------------------------
* Mon Oct 22 2007 Dave Jones <davej at redhat.com>
- 2.6.23-git17

* Thu Oct 18 2007 John W. Linville <linville at redhat.com>
- Latest wireless updates from upstream
- Update rt2x00 to 2.0.11
- Convert some wireless drivers to use round_jiffies_relative

* Wed Oct 17 2007 Dave Jones <davej at redhat.com>
- 2.6.23-git12

kio_sword-0.3-4.fc9
-------------------

klamav-0.41.1-6.fc9
-------------------
* Wed Nov 07 2007 Andy Shevchenko <andy at smile.org.ua> 0.41.1-6
- do not build internal sqlite
- set special echo mode for password field (#362061)

knm_new-fonts-1.1-3.fc9
-----------------------

koan-0.6.3-3.fc9
----------------
* Wed Nov 07 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.3-3
- Release bump to appease the build system.

* Wed Nov 07 2007 Michael DeHaan <mdehaan at redhat.com> - 0.6.3-2
- Upstream changes (see CHANGELOG)

kpowersave-0.7.3-1.fc9
----------------------
* Fri Oct 05 2007 Dennis Gilmore <dennis at ausil.us> - 0.7.3-1
- update to 0.7.3 final

krb5-1.6.3-1.fc9
----------------
* Tue Oct 23 2007 Nalin Dahyabhai <nalin at redhat.com> 1.6.3-1
- update to 1.6.3, dropping now-integrated patches for CVE-2007-3999
  and CVE-2007-4000 (the new pkinit module is built conditionally and goes
  into the -pkinit-openssl package, at least for now, to make a buildreq
  loop with openssl avoidable)

* Wed Oct 17 2007 Nalin Dahyabhai <nalin at redhat.com> 1.6.2-10
- make proper use of pam_loginuid and pam_selinux in rshd and ftpd

* Fri Oct 12 2007 Nalin Dahyabhai <nalin at redhat.com>
- make krb5.conf %verify(not md5 size mtime) in addition to
  %config(noreplace), like /etc/nsswitch.conf (#329811)

krb5-auth-dialog-0.7-6.fc9
--------------------------
* Thu Nov 01 2007 Matthias Clasen <mclasen at redhat.com> - 0.7-6
- Fix the Comment field in the desktop file (#344351)

kronolith-2.1.6-1.fc9
---------------------
* Sat Oct 20 2007 Brandon Holbrook <fedora at theholbrooks.org> 2.1.6-1
- Upgraded to 2.1.6

ksh-20071105-1.fc9
------------------
* Wed Nov 07 2007 Tomas Smetana <tsmetana at redhat.com> 20071105-1
- new upstream version

* Wed Aug 22 2007 Tomas Smetana <tsmetana at redhat.com> 20070628-1.1
- rebuild

* Thu Jul 12 2007 Tomas Smetana <tsmetana at redhat.com> 20070628-1
- new upstream version
- fix unaligned access messages (Related: #219420)

kvm-51-1.fc9
------------
* Wed Nov 07 2007 Jeremy Katz <katzj at redhat.com> - 51-1
- update to kvm-51

* Tue Nov 06 2007 Jeremy Katz <katzj at redhat.com> - 50-1
- update to kvm-50, drop all the patches that have gone upstream

less-409-1.fc9
--------------
* Mon Oct 22 2007 Ivana Varekova <varekova at redhat.com> - 409-1
- upgrade to 409
- remove useless/obsolete patches
- add autoconf buildrequires

lesstif-0.95.0-22.fc9
---------------------
* Sun Oct 21 2007 Patrice Dumas <pertusus at free.fr> 0.95.0-22
- add freetype libs in motif-config

* Sun Oct 21 2007 Patrice Dumas <pertusus at free.fr> 0.95.0-21.1
- remove libdir reference in motif-config, should fix multiarch conflict
  (#341841)

lib3ds-1.3.0-1.fc9
------------------
* Sat Nov 03 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.3.0-1
- Cleanup spec.
- Add post/postun.
- Re-add 3ds2m for fedora < 9.
- Abandon *-static for fedora >= 9.

* Fri Nov 02 2007 Xavier Lamien <lxtnow[at]gmail.com> - 1.3.0
- Updated Release.

* Sun Oct 21 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.2.0-13
- Address BZ 341851:
  - Add lib3ds.pc.
  - Rework lib3ds-config to using lib3ds.pc.
  - Add lib3ds-1.2.0-pkgconfig.diff

libapreq2-2.09-0.rc2.11.fc9
---------------------------
* Fri Oct 26 2007 Bojan Smojver <bojan at rexursive.com> - 2.09-0.rc2.11
- err on the side of caution and include more in LIBS

* Tue Oct 23 2007 Bojan Smojver <bojan at rexursive.com> - 2.09-0.rc2.10
- retag for rebuild

* Tue Oct 23 2007 Bojan Smojver <bojan at rexursive.com> - 2.09-0.rc2.9
- only use pkg-config for --ldflags in apreq2-config (closer, but not perfect)

libcddb-1.3.0-3.fc9
-------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.3.0-3
- Fix multilib conflict in version.h (bz 341971)

libcompizconfig-0.6.0-3.fc9
---------------------------

libdap-3.7.8-3.fc9
------------------
* Sun Oct 21 2007 Patrice Dumas <pertusus at free.fr> 3.7.8-3
- remove reference to libdir in dap-config

libdbi-0.8.2-3.fc9
------------------
* Tue Oct 30 2007 Tom Lane <tgl at redhat.com> 0.8.2-3
- Fix package's selection of CFLAGS to include RPM_OPT_FLAGS
Resolves: #330681

libdbi-drivers-0.8.2-1.3.fc9
----------------------------
* Tue Oct 30 2007 Tom Lane <tgl at redhat.com> 0.8.2-1.3
- Fix package's selection of CFLAGS to include RPM_OPT_FLAGS
Resolves: #330691

libdhcp-1.99.0-1.fc9
--------------------
* Fri Oct 26 2007 David Cantrell <dcantrell at redhat.com> - 1.99.0-1
- Upgrade to libdhcp-1.99.0

* Tue Oct 23 2007 David Cantrell <dcantrell at redhat.com> - 1.27-4
- Patch include paths for isc_dhcp headers
- Require newer dhcp packages

libdrm-2.4.0-0.fc9
------------------
* Thu Nov 01 2007 Dave Airlie <airlied at redhat.com> - 2.4.0-0
- Import a snapshot of what will be 2.4 upstream

libedit-2.10-3.20070831cvs.fc9
------------------------------

libgda-1:3.0.1-5.fc9
--------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1:3.0.1-5
- Rebuild to fix untranslated strings on x86_64 in
  /usr/share/libgda-3.0/sqlite_specs_drop_index.xml
  which caused multilib problems (bz 342101)

* Fri Aug 17 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1:3.0.1-4
- Fix building on ppc64 again (patch configure not configure.in, now we are
  no longer running autoconf)

* Wed Aug 15 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1:3.0.1-3
- Enable microsoft access (mdb) support now that mdbtools is in Fedora
- Enable xBase (dBase, Clipper, FoxPro) support, it seems that xbase has been
  available for quite a while now
- Switch from using mysqlclient10 to using mysql-libs for the msql provider

libglade-1:0.17-20.fc9
----------------------
* Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:0.17-20
- clarify license as LGPL version 2 or later
- remove bundled libintl (GPL) in %prep to be absolutely sure that it isn't
  used
- patch libglade-config to generate cflags/libs values at runtime instead of
  build-time and hence be multiarch compatible (#342131); we can get away with
  this because the entire (legacy) library stack is stable and isn't going to
  change in any significant way
- enumerate more of the %files list to narrow scope of wildcards
- re-encode ChangeLog as UTF-8
- preserve timestamps for files copied from source to installed package

* Mon Oct 02 2006 Paul Howarth <paul at city-fan.org> 1:0.17-19
- add new buildreq libtool and use the system libtool instead of the bundled
  one to avoid /usr/lib64 rpaths
- add patch to fix non-weak-symbols issues in libglade-gnome.so
- include epoch in versioned gnome-libs-devel dependencies

* Sat Aug 26 2006 Paul Howarth <paul at city-fan.org> 1:0.17-18
- include epoch in versioned libxml-devel dependencies

libgnomecups-0.2.2-12.fc9
-------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.2.2-12
- Rebuild against new dbus-glib

libgnomedb-1:3.0.0-4.fc9
------------------------
* Mon Aug 13 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1:3.0.0-4
- Don't rebuild the documentation to avoid multilib conflicts (bz 342141)

libgnomekbd-2.20.0-2.fc9
------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Rebuild against new dbus-glib

libipoddevice-0.5.3-4.fc9
-------------------------
* Mon Oct 22 2007 Matthias Clasen  <mclasen at redhat.com> - 0.5.3-4
- Rebuild against new dbus-glib

* Fri Aug 24 2007 Adam Jackson <ajax at redhat.com> - 0.5.3-3
- Rebuild for build ID

* Mon Aug 13 2007 Christopher Aillon <caillon at redhat.com> 0.5.3-2
- Update the license tag

libmcrypt-2.5.8-4.fc9
---------------------

libmtp-0.2.3-1.fc9
------------------
* Thu Oct 25 2007 Linus Walleij <triad at df.lth.se> 0.2.3-1
- New upstream release.
- New soname libmtp.so.7 so all apps using libmtp have to
  be recompiled, have fun.
- If it works out we'll try to reserve a spot to backport
  this fixed version to F8 and F7 in a controlled manner.

* Wed Oct 24 2007 Linus Walleij <triad at df.lth.se> 0.2.2-2
- Flat out KILL the Doxygen HTML docs to resolve multiarch conflicts.
  Either upstream (that's me!) needs to work around the HTML files being 
  different each time OR Doxygen must stop generating anchors that
  hash the system time, creating different files with each generation.
  Pre-generating the docs is deemed silly. (Someone will disagree.)

libnc-dap-3.7.0-8.fc9
---------------------
* Sun Oct 21 2007 Patrice Dumas <pertusus at free.fr> 3.7.0-8
- remove reference to libdir in ncdap-config, should fix multilib conflict
  (#342251)

libnjb-2.2.6-2.fc9
------------------
* Wed Oct 24 2007 Linus Walleij <triad at df.lth.se> 2.2.6-2
- Flat out KILL the Doxygen HTML docs to resolve multiarch conflicts.
  Either upstream (that's me!) needs to work around the HTML files being 
  different each time OR Doxygen must stop generating anchors that
  hash the system time, creating different files with each generation.
  Pre-generating the docs is deemed silly. (Someone will disagree.)

libnotify-0.4.4-9.fc9
---------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.4.4-9
- Rebuild against new dbus-glib

libogg-2:1.1.3-6.fc9
--------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> - 2:1.1.3-6
- Don't install Makefile's as %doc, avoiding a multilib conflict (bz 342281)

libpcap-14:0.9.8-1.fc9
----------------------
* Wed Oct 24 2007 Miroslav Lichvar <mlichvar at redhat.com> 14:0.9.8-1
- update to 0.9.8

libpciaccess-0.9.1-2.20071031.fc9
---------------------------------
* Wed Oct 31 2007 Kristian H??gsberg <krh at redhat.com> 0.9.1-2.20071031
- New snapshot, git revision e392082abb5696c8837224da86cc0af4f21d7010.
- Pick up new .so file.

libpfm-3.2-0.071017.1.fc9
-------------------------
* Wed Oct 24 2007 Will Cohen <wcohen at redhat.com> - 3.2-0.071017.1
- Update to libpfm-3.2-071017.

libpri-1.4.2-1.fc9
------------------
* Thu Nov 01 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.4.2-1
- Update to 1.4.2

libraw1394-1.3.0-2.fc9
----------------------
* Fri Oct 19 2007 Jarod Wilson <jwilson at redhat.com> - 1.3.0-2
- Fix the 'double free' crash on shutdown (#328011)

* Thu Oct 18 2007 Jarod Wilson <jwilson at redhat.com> - 1.3.0-1
- libraw1394 v1.3.0

* Wed Aug 29 2007 Fedora Release Engineering <rel-eng at fedoraproject dot org> - 1.2.1-10
- Rebuild for selinux ppc32 issue.

libselinux-2.0.40-1.fc9
-----------------------
* Tue Nov 06 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.40-1
- Upgrade to upstream
	* Merged refactored AVC netlink code from Eamon Walsh.
	* Merged new X label namespaces from Eamon Walsh.
	* Bux fix and minor refactoring in string representation code.

libsemanage-2.0.14-1.fc9
------------------------
* Tue Nov 06 2007 Dan Walsh <dwalsh at redhat.com> - 2.0.14-1
- Upgrade to latest from NSA
	* Call rmdir() rather than remove() on directory removal so that errno isn't polluted from Stephen Smalley.
	* Allow handle_unknown in base to be overridden by semanage.conf from Stephen Smalley.

libsepol-2.0.14-1.fc9
---------------------
* Tue Nov 06 2007 Dan Walsh <dwalsh at redhat.com> 2.0.14-1
- Upgrade to latest from NSA
	* Reject self aliasing at link time from Stephen Smalley.
	* Allow handle_unknown in base to be overridden by semanage.conf from Stephen Smalley.
	* Fixed bug in require checking from Stephen Smalley.
	* Added user hierarchy checking from Todd Miller.

libsidplay-1.36.57-15
---------------------
* Sat Oct 20 2007 Michael Schwendt <mschwendt[AT]users.sf.net> 1.36.57-15
- Move the i386-specific configure options into a __i386__ patch.
  This shall fix the multiarch conflict in libsidplay-devel (#342371).

libsieve-2.2.6-2.fc9
--------------------
* Fri Oct 26 2007 Bernard Johnson <bjohnson at symetrix.com> - 2.2.6-2
- add missing BR: flex, bison
- remove repotag

* Fri Oct 26 2007 Bernard Johnson <bjohnson at symetrix.com> - 2.2.6-1
- 2.2.6
- license clarification

libsoup-2.2.103-1.fc9
---------------------

libtelepathy-0.2.0-1.fc9
------------------------
* Mon Oct 01 2007 Matej Cepl <mcepl at redhat.com> - 0.2.0-1
- New upstream version.

libtheora-0:1.0beta2-2.fc9
--------------------------

libtirpc-0.1.7-13.fc9
---------------------
* Thu Oct 25 2007 Steve Dickson  <steved at redhat.com> 0.1.7-13
- Added a check for the ARM arch (bz 351071)

libusb-0.1.12-11.fc9
--------------------
* Tue Nov 06 2007 Jindrich Novy <jnovy at redhat.com> 0.1.12-11
- fix multilib conflict in manual.ps (#342461)
- drop useless BR: gawk

libuser-0.56.6-1.fc9
--------------------
* Thu Oct 25 2007 Miloslav Trma?? <mitr at redhat.com> - 0.56.6-1
- Set SELinux file contexts when creating home directories, preserve them when
  moving home directories
  Resolves: #351201

* Thu Oct 11 2007 Miloslav Trma?? <mitr at redhat.com> - 0.56.5-1
- Work around spurious error messages when run against the Fedora Directory
  server
- Fix error reporting when creating home directories and creating/removing mail
  spool files
  Resolves: #318121

* Wed Sep 05 2007 Miloslav Trma?? <mitr at redhat.com> - 0.56.4-3
- s/popt/popt-devel/ in BuildRequires
  Resolves: #277541

libvorbis-1:1.2.0-2.fc9
-----------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> - 1:1.2.0-2
- Don't include Makefile's in %doc, avoiding a multilib conflict (bz 342481)

libvte-java-0.12.1-10.fc9
-------------------------
* Tue Nov 06 2007 Stepan Kasal <skasal at redhat.com> - 0.12.1-10
- -devel should require pkgconfig
- remove the residuum from %{java_pkg_prefix} and name_base
- cosmetic change to the descriptions
- add dash to the jar name (between name and version)
- Resolves: #232934

* Tue Apr 03 2007 Stepan Kasal <skasal at redhat.com> - 0.12.1-9
- Fix permissions for libvte-java-alias.patch; because of CVS limitations,
  the patch has to be renamed, say to libvte-java-alias2.patch 
- Adhere to packaging guidelines.
- Resolves: #226057
- Make sure we will notice when the project starts using the NEWS file.

* Tue Mar 06 2007 Stepan Kasal <skasal at redhat.com> - 0.12.1-8
- Rename the gcjh -> gjavah patch.

libwnck-2.20.1-3.fc9
--------------------

libxml-1:1.8.17-18.fc9
----------------------
* Fri Oct 26 2007 Paul Howarth <paul at city-fan.org> 1:1.8.17-18
- fix multiarch conflict in xml-config (#342501)
- preserve timestamps for files copied from source to installed package
- re-encode ChangeLog as UTF-8

* Thu Aug 30 2007 Paul Howarth <paul at city-fan.org> 1:1.8.17-17
- rebuild for BuildID inclusion
  (http://fedoraproject.org/wiki/Releases/FeatureBuildId)

* Fri Aug 17 2007 Paul Howarth <paul at city-fan.org> 1:1.8.17-16
- add mode to fix call to open() with O_CREAT and only 2 args
- unexpand tabs in spec
- update license tag

libzzub-0.2.3-9.fc9
-------------------
* Thu Oct 25 2007 Alexander Kahl <akahl at iconmobile.com> - 0.2.3-9
- fixed multiarch conflict

liferea-1.4.6-4.fc9
-------------------
* Tue Nov 06 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.4.6-4
- Rebuild for new gecko libs.

* Fri Nov 02 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.4.6-3
- Update gecko version needed.

* Fri Nov 02 2007 Brian Pepple <bpepple at fedoraproject.org> - 1.4.6-2
- Update Fedora feed patch.

linuxdoc-tools-0.9.21-11.fc9
----------------------------
* Fri Oct 26 2007 Ondrej Vasik <ovasik at redhat.com> 0.9.21-11
- rpmlint check
- fixed some cosmetic things, versioned provides and License tag

liquidwar-5.6.4-1.fc9
---------------------
* Mon Oct 22 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 5.6.4-1
- New upstream release 5.6.4

logwatch-7.3.6-11.fc9
---------------------
* Tue Nov 06 2007 Ivana Varekova <varekova at redhat.com> 7.3.6-11
- Resolves: #361921
  fix clamav-milter service

* Tue Oct 30 2007 Ivana Varekova <varekova at redhat.com> 7.3.6-10
- add perl requirement (#356481)

lshw-B.02.12.01-1.fc9
---------------------
* Mon Nov 05 2007 Terje Rosten <terjeros at phys.ntnu.no> - B.02.12.01-1
- B.02.12.01
- Replace trademark icons

lua-5.1.2-3.fc9
---------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 5.1.2-3
- Also use lib64 instead of lib on ia64 and sparc64

* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 5.1.2-2
- Fix multilib condlict in luaconf.h (bz 342561)

lzma-4.32.2-2.fc9
-----------------
* Sat Oct 27 2007 Per Patrice Bouchand <patrice.bouchand.fedora<at>gmail.com> 4.32.2-2
- Forgot to upload new sources, bumping...

* Sat Oct 27 2007 Per Patrice Bouchand <patrice.bouchand.fedora<at>gmail.com> 4.32.2-1
- 'make tag' problems, bumping...

* Sat Oct 27 2007 Per Patrice Bouchand <patrice.bouchand.fedora<at>gmail.com> 4.32.2-0
- Switch to version 4.32.2

m2crypto-0.18.2-1
-----------------
* Fri Oct 26 2007 Miloslav Trma?? <mitr at redhat.com> - 0.18.2-1
- Update to m2crypto-0.18.2
- Remove BuildRequires: unzip

mailgraph-1.14-1.fc9
--------------------
* Tue Oct 30 2007 Bernard Johnson <bjohnson at symetrix.com> - 1.14-1
- v 1.14
- fix broken URLs (bz #251280)
- selinux policy fu (bz #243302)
- Mailgraph needs AddHandler cgi-script .cgi (bz #289021)
- Make initscript LSB compliant (bz #246977)

mailman-3:2.1.9-8.fc9
---------------------
* Tue Oct 16 2007 Tomas Smetana <tsmetana at redhat.com> - 3:2.1.9-8
- fix #333011 - withlist crashes with NameError
- fix #350461 - init script prevents proper SELinux domain transitions
- fix #303061 - broken multipart mail headers

man-pages-2.67-1.fc9
--------------------
* Mon Oct 22 2007 Ivana Varekova <vraekova at redhat.com> - 2.67-1
- update to 2.67

* Tue Oct 09 2007 Ivana Varekova <vaerkova at redhat.com> - 2.66-1
- update to 2.66
- add proc man-page patch

* Tue Sep 18 2007 Ivana Varekova <varekova at redhat.com> - 2.65-1
- update to 2.65

man-pages-es-1.55-0.fc9
-----------------------
* Wed Oct 31 2007 Ding-Yi Chen <dchen at redhat.com> - 1.55
- Add Spanish summaries and descriptions

man-pages-it-2.65-0
-------------------
* Mon Oct 22 2007 Ding-Yi Chen <dchen at redhat.com> - 2.65-0
- [Bug 335931] man-pages-it package is 6 years old

* Wed Oct 10 2007 Ding-Yi Chen <dchen at redhat.com> - 0.3.0-18
- [Bug 236116] Unsupported programs in man-pages-it
- remove celibacy.1 and sex.6

* Wed Jul 12 2006 Jesse Keating <jkeating at redhat.com> - 0.3.0-17.1.gz
- rebuild

man-pages-ja-20071015-1.fc9
---------------------------
* Mon Oct 29 2007 Akira TAGOH <tagoh at redhat.com> - 20071015-1
- updates to 20071015.

maxima-5.13.0-8.fc9
-------------------
* Sat Nov 03 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 5.13.0-8
- rebuild against sbcl-1.0.11

mcabber-0.9.4-1.fc9
-------------------
* Sun Oct 28 2007 Michael Fleming <mfleming+rpm at enlartenment.com> - 0.9.4-1
- New upstream release
- Use GnuTLS in place of OpenSSL
- Enable OTR (Off The Record) support.

mcstrans-0.2.7-1.fc9
--------------------
* Tue Oct 30 2007 Steve Conklin <sconklin at redhat.com> - 0.2.7-1
- Folded current patches into tarball

* Thu Oct 25 2007 Steve Conklin <sconklin at redhat.com> - 0.2.6-3
- Fixed a compile problem with max_categories

* Thu Oct 25 2007 Steve Conklin <sconklin at redhat.com> - 0.2.6-2
- Fixed some init script errors

mecab-0.96-2.fc9.1
------------------
* Thu Oct 25 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-2
- License fix

* Wed Aug 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-1.dist.2
- Mass rebuild (buildID or binutils issue)

* Fri Aug 03 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-1.dist.1
- License update

mecab-java-0.96-3.fc9.4
-----------------------
* Fri Oct 26 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-3
- License fix

memtest86+-1.70-4.fc9
---------------------

mercurial-0.9.5-2.fc9
---------------------
* Tue Oct 23 2007 <ndbecker2 at gmail.com> - 0.9.5-2
- Bump tag to fix confusion

* Mon Oct 15 2007 Neal Becker <ndbecker2 at gmail.com> - 0.9.5-1
- Sync with spec file from mercurial

mew-5.2.51-1.fc9
----------------
* Wed Oct 31 2007 Akira TAGOH <tagoh at redhat.com> - 5.2.51-1
- New upstream release.

mhash-0.9.9-4
-------------
* Tue Oct 23 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 0.9.9-4
- Remove AC_CHECK_SIZEOF definitions from mhash_config.h
  since stdint.h is used. Add a guard after running configure.
  This shall fix the multiarch conflict in mhash-devel (#342601).

mikmod-3.2.2-5.fc9
------------------
* Thu Oct 25 2007 Jindrich Novy <jnovy at redhat.com> 3.2.2-5
- remove useless configure option

* Wed Sep 19 2007 Jindrich Novy <jnovy at redhat.com> 3.2.2-4
- don't hardcode buildroot library paths to binaries/libs
- preserve timestamps
- link against libmikmod, remove mikmod-devel
- remove all libmikmod stuff, it's now packaged separately

* Thu Aug 23 2007 Jindrich Novy <jnovy at redhat.com> 3.2.2-3
- update License
- rebuild for BuildID

mirage-0.9-1.fc9
----------------
* Fri Oct 19 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.9-1
- 0.9

mock-0.8.7-1.fc9
----------------
* Mon Oct 22 2007 Michael Brown <mebrown at michaels-house.net> - 0.8.4-1
- fix reported 'bad owner/group' from rpm in some configurations.

* Mon Oct 22 2007 Michael Brown <mebrown at michaels-house.net> - 0.8.3-1
- BZ# 336361 -- cannot su - mockbuild
- BZ# 326561 -- update manpage
- BZ# 235141 -- error with immutable bit

* Sat Oct 20 2007 Michael Brown <mebrown at michaels-house.net> - 0.8.0-1
- huge number of changes upstream
- convert to setuid wrapper instead of old setuid helper
- lots of bugfixes and improvements
- /var/cache/yum now saved and bind-mounted
- ccache integration
- rootcache improvements (formerly called autocache)

mono-1.2.5.1-3.fc9
------------------
* Wed Nov 07 2007 Alexander Larsson <alexl at redhat.com> - 1.2.5.1-3
- Fix overflow in Mono.Math.BigInteger class (#367551)
  CVE-2007-5197

* Fri Oct 05 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 1.2.5.1-1
- bump
- added new parts (mono-linker, resgen and mono-cecil)

* Sat Apr 21 2007 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 1.2.4-1
- update from 1.2.3

monotone-0.37-3.fc9
-------------------
* Sat Oct 27 2007 Roland McGrath <roland at redhat.com> - 0.37-3
- Updated for 0.37 release.
- Prevent destroying old passphrase file with 'service monotone genkey'.
- Put LSB standard comments in monotone.init for monotone-server subpackage.

moodle-1.8.3-1.fc9
------------------
* Thu Oct 25 2007 Jon Ciesla <limb at jcomserv.net> - 1.8.3-1
- Update to 1.8.3.
- Fix init script for LSB BZ 246986.
- Updated language packs to 25 October 2007 versions.
- Added Armenian, Macedonian.

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> - 1.8.2-2
- License tag correction.

muine-0.8.8-3.fc9
-----------------
* Sun Oct 21 2007 Sindre Pedersen Bj??rdal <foolish at guezz.net> - 0.8.8-1
- New release
- Removed obsolete patches

mutt-5:1.5.17-1.fc9
-------------------
* Fri Nov 02 2007 Miroslav Lichvar <mlichvar at redhat.com> 5:1.5.17-1
- update to 1.5.17

nagios-plugins-1.4.8-8.fc9
--------------------------
* Fri Oct 26 2007 Mike McGrath <mmcgrath at redhat.com> 1.4.8-8
- Fix for Bug 348731 and CVE-2007-5623
naim-0.11.8.3.1-5.fc9
---------------------
* Sat Oct 27 2007 Luke Macken <lmacken at redhat.com> 0.11.8.3.1-5
- Fix broken Source0

nas-1.9a-3.fc9
--------------
* Fri Nov 02 2007 Frank B??ttner  <frank-buettner at gmx.net> - 1.9a-3
- add better patch for #247468

* Fri Nov 02 2007 Frank B??ttner  <frank-buettner at gmx.net> - 1.9a-2
- add patch to fix #247468

* Sun Oct 28 2007 Frank B??ttner  <frank-buettner at gmx.net> - 1.9a-1
- update to 1.9a to fix #245712

nautilus-2.20.0-6.fc9
---------------------
* Tue Oct 30 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-6
- Fix audio preview command-line to use decodebin so playbin doesn't
  pop up a window for videos detected as audio

* Tue Oct 16 2007 - Bastien Nocera <bnocera at redhat.com> - 2.20.0-5
- Add patch from upstream to get audio preview working again
  (#332251)

* Wed Oct 03 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Move /usr/lib/nautilus/extensions-1.0 to the extensions package

nautilus-cd-burner-2.20.0-2.fc9
-------------------------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Rebuild against new dbus-glib

nautilus-sendto-0.12-4.fc9
--------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.12-4
- Rebuild against new dbus-glib

nazghul-0.6.0-1.fc9
-------------------
* Mon Nov 05 2007 Jason L Tibbitts III <tibbs at math.uh.edu> - 0.6.0-1
- Update to 0.6.0.

nbd-2.9.7-4.fc9
---------------
* Wed Nov 07 2007 Warren Togami <wtogami at redhat.com> 2.9.7-4
- include nbd-client i386 in x86-64 RPM because initrd images need it
ncpfs-2.2.6-9.fc9
-----------------
* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com> - 2.2.6-9
- fix a typo in the summary line
- Resolves: #239216

nedit-5.5-15.fc9
----------------
* Tue Oct 30 2007 Jindrich Novy <jnovy at redhat.com> 5.5-15
- make mouse wheel scrolling compatible with lesstif (#354591)

* Mon Oct 29 2007 Jindrich Novy <jnovy at redhat.com> 5.5-14
- don't use /bin/csh but /bin/sh as default shell (#355441)

* Fri Oct 26 2007 Jindrich Novy <jnovy at redhat.com> 5.5-13
- spec cleanup

net-snmp-1:5.4.1-5.fc9
----------------------
* Thu Oct 25 2007 Jan Safranek <jsafranek at redhat.com> 5.4.1-5
- move mib2c-update from net-snmp-utils to net-snmp-perl, where
  mib2c is located
- add tkmib to net-snmp-gui package (#167933)

netgen-1.3.7-13.fc9
-------------------
* Sun Oct 21 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 1.3.7-13
- added coreutils and gtk as requires: #339771

netpbm-10.35.32-2.fc9
---------------------
* Fri Nov 02 2007 Jindrich Novy <jnovy at redhat.com> 10.35.32-2
- remove man pages that lacks corresponding binaries (#220739)

* Thu Oct 18 2007 Jindrich Novy <jnovy at redhat.com> 10.35.32-1
- remove .svn directories from tarball to reduce its size
- update fixes rhbz#337181 and likely others

* Thu Oct 18 2007 MATSUURA Takanori <t.matsuu at gmail.com> 10.35.32-0
- update to 10.35.32 from svn tree
- create man pages from userguide HTML files

nexuiz-2.3-3.fc9
----------------
* Wed Oct 24 2007 Jon Ciesla <limb at jcomserv.net> - 2.3-3
- Add support for opengl-games-utils.
- Dropped X-Fedora from .desktop install.

nfs4-acl-tools-0.3.2-1.fc9
--------------------------
* Fri Oct 26 2007 Steve Dickson <steved at redhat.com> - 0.3.2-1
- Updated to latest upstream version 0.3.2

notification-daemon-0.3.7-7.fc9
-------------------------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 0.3.7-7
- Rebuild against new dbus-glib

nsd-3.0.6-6.fc9
---------------
* Wed Nov 07 2007 Paul Wouters <paul at xelerance.com> - 3.0.6-6
- Added hourly cron job to do various maintenance tasks
- Added nsd rebuild to create the proper nsd.db file on startup
- Added nsd patch on shutdown to ensure zonefiles are up to date

nspluginwrapper-0.9.91.5-10.fc9
-------------------------------
* Wed Oct 24 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-10
- added glib2 to Requires (#349861)

* Wed Oct 24 2007 Martin Stransky <stransky at redhat.com> 0.9.91.5-9
- Updated config utility - removes dangling symlinks and
  wrapped plugins

nspr-4.6.99.2-1.fc9
-------------------
* Wed Nov 07 2007 Kai Engert <kengert at redhat.com> - 4.6.99-1
- NSPR 4.7 alpha

nss-3.11.99.2-1.fc9
-------------------
* Wed Nov 07 2007 Kai Engert <kengert at redhat.com> - 3.11.99.2-1
- NSS 3.12 alpha 2

ntfs-3g-2:1.1104-1.fc9
----------------------
* Thu Nov 08 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:1.1104-1
- bump to 1.1104

ntp-4.2.4p4-1.fc9
-----------------
* Fri Oct 26 2007 Miroslav Lichvar <mlichvar at redhat.com> 4.2.4p4-1
- update to 4.2.4p4
- fix default NTP version for outgoing packets in ntpdate man page
  (#245408)
- replace BSD with advertising code in ntpdc and ntpq

ocaml-lablgtk-2.10.0-1.fc9
--------------------------
* Wed Nov 07 2007 Richard W.M. Jones <rjones at redhat.com> - 2.10.0-1
- New upstream release 2.10.0.
- Fix path to Camlp4Parsers in 'make doc' rule.

octave-6:2.9.16-1.fc9
---------------------
* Mon Nov 05 2007 Quentin Spencer <qspencer at users.sf.net> 2.9.16-1
- Update to 2.9.16, remove old patch.
- Update licencse from GPLv2+ to GPLv3+.
- Detection of glpk no longer needs special CPPFLAGS.

octave-forge-20071014-3.fc9
---------------------------
* Wed Nov 07 2007 Quentin Spencer <qspencer at users.sf.net> 20071014-3
- Add new patch to listen.cc for compatibility with octave-2.9.16

offlineimap-5.99.4-1.fc9
------------------------
* Sun Oct 21 2007 Till Maas <opensource till name> - 5.99.4-1
- update to new version

online-desktop-0.2.22-1.fc9
---------------------------

opencdk-0.6.5-1.fc9
-------------------
* Tue Oct 30 2007 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.6.5-1
- updated to 0.6.5

openldap-2.3.39-1.fc9
---------------------
* Mon Nov 05 2007 Jan Safranek <jsafranek at redhat.com> 2.3.39-1.fc9
- new upstream release

* Tue Oct 23 2007 Jan Safranek <jsafranek at redhat.com> 2.3.38-4.fc9
- fixed multilib issues - all platform independent files have the
  same content now (#342791)

* Thu Oct 04 2007 Jan Safranek <jsafranek at redhat.com> 2.3.38-3.fc9
- BDB downgraded back to 4.4.20 because 4.6.18 is not supported by 
  openldap (#314821)

openvrml-0.16.6-6.fc9
---------------------

opyum-0.0.3-1.fc9
-----------------

pam-0.99.8.1-11.fc9
-------------------
* Wed Nov 07 2007 Tomas Mraz <tmraz at redhat.com> 0.99.8.1-11
- add substack support

* Tue Sep 25 2007 Tomas Mraz <tmraz at redhat.com> 0.99.8.1-10
- update db4 to 4.6.19 (#274661)

* Fri Sep 21 2007 Tomas Mraz <tmraz at redhat.com> 0.99.8.1-9
- do not preserve contexts when copying skel and other namespace.init
  fixes (#298941)
- do not free memory sent to putenv (#231698)

pango-1.19.0-1.fc9
------------------
* Wed Oct 31 2007 Behdad Esfahbod <besfahbo at redhat.com> - 1.19.0-1
- Update to 1.19.0

paragui-1.0.4-6.fc9
-------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.0.4-6
- Fix paragui-config multilib conflict (bz 342831)

parted-1.8.6-12.fc9
-------------------
* Mon Nov 05 2007 David Cantrell <dcantrell at redhat.com> - 1.8.6-12
- Add KNOWN ISSUES section to parted(8) man page explaining that we cannot
  currently do ext3 resizing inside parted (#367101)
- Update the xvd patch to include 'xvd' in the string table that parted
  uses when printing device types (#366971)
- Do not install the linux.h or gnu.h headers

* Tue Oct 30 2007 David Cantrell <dcantrell at redhat.com> - 1.8.6-11
- Do not install fdasd.h and vtoc.h header files

perl-CGI-Ex-2.21-1.fc9
----------------------
* Mon Nov 05 2007 Chris Weyl <cweyl at alumni.drew.edu> 2.21-1
- update to 2.21
- license tag: GPL -> GPL+

perl-CPANPLUS-Dist-Build-0.05-3.fc9
-----------------------------------

perl-Carp-Clan-5.9-3.fc9
------------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 5.9-3
- Fix BuildRequires
- Various specfile cleanups

perl-Catalyst-Action-RenderView-0.07-1.fc9
------------------------------------------
* Sun Oct 21 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.07-1
- update to 0.07
- update license tag: GPL -> GPL+
- switch build invocations due to switchover to Module::Install
perl-Class-C3-0.19-1.fc9
------------------------
* Wed Oct 10 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.19-1
- update to 0.19

perl-Compress-Raw-Zlib-2.005-4.fc9
----------------------------------
* Tue Oct 23 2007 Robin Norwood <rnorwood at redhat.com> - 2.005-4
- Fix license tag
- Remove BR: perl

perl-Compress-Zlib-2.005-3.fc9
------------------------------
* Tue Oct 23 2007 Robin Norwood <rnorwood at redhat.com> - 2.005-3
- Remove BR: perl

perl-Config-Any-0.08-1.fc9
--------------------------
* Tue Oct 23 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.08-1
- update to 0.08
- license tag update: GPL -> GPL+
- Module::Build -> Module::Install

perl-Crypt-SSLeay-0.57-3.fc9
----------------------------
* Sat Oct 27 2007 Robin Norwood <rnorwood at redhat.com> - 0.57-3
- Remove unnecessary BR: pkgconfig

* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 0.57-2
- Fix buildroot per package review
- Resolves: bz#226248

* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 0.57-1
- Update to latest upstream version.
- Remove old patch (patch applied to upstream)
- Several fixes for package review:
- Fixed BuildRequires (added Test::Pod and LWP::UserAgent)
- Apply patch to avoid prompting for input when building Makefile
- Fix defattr line
- Resolves: bz#226248

perl-DBD-Mock-1.36-1.fc9
------------------------
* Tue Oct 23 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.36-1
- update to 1.36
- license tag: GPL -> GPL+
perl-DBD-MySQL-4.005-4.fc9
--------------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 4.005-4
- Fix utf-8 rpmlint warning

* Tue Oct 23 2007 Robin Norwood <rnorwood at redhat.com> - 4.005-3
- Use fixperms macro
- Remove BR: perl

perl-DBD-Pg-1.49-6.fc9
----------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 1.49-6
- Apply changes from package review.
- Resolves: bz#226252

perl-DBIx-DBSchema-0.35-1.fc9
-----------------------------
* Wed Oct 31 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.35-1
- Upstream update.

perl-Data-Alias-1.07-1.fc9
--------------------------
* Mon Nov 05 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.07-1
- update to 1.07

perl-Data-Visitor-0.09-1.fc9
----------------------------

perl-Date-Calc-5.4-3.fc9
------------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 5.4-3
- various specfile fixes

perl-File-MMagic-1.27-4.fc9
---------------------------
* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 1.27-4
- Remove BR: perl for package review
- Resolves: bz#226257

perl-File-NCopy-0.35-3.fc9
--------------------------
* Wed Oct 24 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.35-3
- Add BR: perl(Test::Pod).

* Wed Oct 24 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.35-2
- Add BR: perl(Test::More).

* Sun Oct 21 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.35-1
- Upstream update.
- Reflect Source-URL having changed.

perl-Frontier-RPC-0.07b4-3.fc9
------------------------------
* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 0.07b4-3
- Various fixes from package review:
- Remove BR: perl
- Use dist tag in release
- Resolves: bz#226258

perl-Gnome2-GConf-1.044-1.fc9
-----------------------------
* Tue Oct 23 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.044-1
- update to 1.044
- add t/ to doc

* Tue Aug 21 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.043-2
- bump

perl-Gnome2-VFS-1.080-1.fc9
---------------------------
* Tue Oct 23 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.080-1
- update to 1.080
perl-Gtk2-Notify-0.04-1.fc9
---------------------------
* Mon Nov 05 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.04-1
- update to 0.04

perl-IO-Socket-SSL-1.12-1.fc9
-----------------------------
* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 1.12-1
- Update to latest upstream version: 1.12
- Fix license tag
- Add BuildRequires for ExtUtils::MakeMaker and Test::Simple
- Fix package review issues:
- Source URL
- Resolves: bz#226264

perl-IO-String-1.08-3.fc9
-------------------------
* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 1.08-3
- Fix various package review issues:
- Remove BR: perl
- Remove "|| :" from check section
- Add dist tag
- Fix Source URL
- Fix old changelog entries
- Resolves: bz#226265

* Tue Oct 16 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.08-2
- correct license tag
- add BR: perl(ExtUtils::MakeMaker)

* Wed Jul 12 2006 Jesse Keating <jkeating at redhat.com> - 1.08-1.2
- rebuild

perl-IO-Zlib-1.07-2.fc9
-----------------------
* Tue Oct 23 2007 Robin Norwood <rnorwood at redhat.com> - 1.07-2
- Remove BR: perl
- Minor specfile cleanups

perl-Image-ExifTool-7.00-1.fc9
------------------------------

perl-Inline-0.44-17.fc9
-----------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 0.44-17
- Various fixes from package review

perl-JSON-XS-1.52-1.fc9
-----------------------
* Wed Oct 17 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.52-1
- update to 1.52
- license tag update: GPL -> GPL+

perl-Moose-0.26-1.fc9
---------------------
* Sun Oct 14 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.26-1
- udpate to 0.26
perl-MooseX-Params-Validate-0.03-1.fc9
--------------------------------------
* Mon Oct 22 2007 Chris Weyl <cweyl at alumni.drew.edu> 0.03-1
- update to 0.03
- license tag update: GPL -> GPL+
- add t/ to doc
perl-Net-DNS-0.61-2.fc9
-----------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 0.61-2
- Update license tag
- Convert Changes to utf-8
perl-Net-SSLeay-1.30-6.fc9
--------------------------
* Tue Nov 06 2007 Stepan Kasal <skasal at redhat.com> - 1.30-6
- fix a typo in description

perl-PDF-API2-0.65-1.fc9
------------------------
* Sun Oct 28 2007 Bernard Johnson <bjohnson at symetrix.com> - 0.65-1
- 0.65

perl-Params-Util-0.30-1.fc9
---------------------------
* Tue Oct 30 2007 Ralf Cors??pius <rc040203 at freenet.de> - 0.30-1
- Upstream update.

perl-RPM2-0.67-3.fc9
--------------------
* Fri Oct 26 2007 Lubomir Kundrak <lkundrak at redhat.com> - 0.67-3
- Fix reading of non-32bit int tag values
- Correct the License tag

perl-SGMLSpm-1.03ii-16.4.fc9
----------------------------
* Fri Oct 26 2007 Ondrej Vasik <ovasik at redhat.com> - 1.03ii-16.4
- added base documentation
- fixed indents

* Mon Oct 22 2007 Ondrej Vasik <ovasik at redhat.com> - 1.03ii-16.3
- added dist tag
- License to GPL+
- spec file cleanup (all things from merge review by pnemade #226278)

* Wed Jul 12 2006 Jesse Keating <jkeating at redhat.com> - 1.03ii-16.2.1
- rebuild

perl-Set-IntSpan-1.13-1.fc9
---------------------------
* Tue Oct 30 2007 Ralf Cors??pius <rc040203 at freenet.de>  - 1.13.1
- Upstream update.

perl-TermReadKey-2.30-3.fc9
---------------------------
* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 2.30-3
- fix various issues from package review:
- remove extra || : from %check
- add dist tag to release
- remove BR: perl
- fix tabs and spacing

perl-Text-Iconv-1.7-1.fc9
-------------------------
* Wed Nov 07 2007 Marcela Maslanova <mmaslano at redhat.com> - 1.7-1
- upgrade on 1.7
- Resolves: rhbz#331011

perl-URI-1.35-4.fc9
-------------------
* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 1.35-4
- Fix various package review issues:
- Remove redundant BR: perl
- remove "|| :" from %check
- move requires filter into spec file
- remove tabs and fix spacing

perl-XML-Dumper-0.81-3.fc9
--------------------------
* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 0.81-3
- fix various issues from package review:
- remove || : from %check
- remove tabs and fix spacing
- fix encoding for README file

perl-XML-LibXML-1.65-1.fc9
--------------------------
* Wed Oct 24 2007 Robin Norwood <rnorwood at redhat.com> - 1.65-1
- Update to latest CPAN release: 1.65
- patch0 no longer needed
- various spec file cleanups

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.62001-2.3
- fix stupid test

* Wed Oct 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.62001-2.2
- add BR: perl(Test::More)

perl-XML-LibXML-Common-0.13-10.fc9
----------------------------------
* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 0.13-10
- Various fixes from package review:
- Remove useless BR: perl
- Use dist tag in release
- Remove "|| :" from check section
- Fix source URL
- Remove tabs and clean up spacing
- Also improve package description with text from the README

perl-XML-Parser-2.34-10.fc9
---------------------------
* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 2.34-10
- Add dist tag to release field
- Fix previous changelog

* Tue Oct 23 2007 Robin Norwood <rnorwood at redhat.com> - 2.34-9
- Remove BR: perl
- fix utf-8 rpmlint warning

perl-XML-Simple-2.18-1.fc9
--------------------------
* Thu Oct 25 2007 Robin Norwood <rnorwood at redhat.com> - 2.18-1
- Update to latest upstream version.

* Tue Oct 23 2007 Robin Norwood <rnorwood at redhat.com> - 2.17-2
- Remove BR: perl

perl-libwww-perl-5.808-4.fc9
----------------------------
* Fri Oct 26 2007 Robin Norwood <rnorwood at redhat.com> - 5.808-4
- Fix various issues from package review:
- Fix tabs and spacing
- Remove unneeded BR: perl
- convert non-utf-8 files to utf-8
- Resolves: bz#226268

perl-mecab-0.96-2.fc9.1
-----------------------
* Fri Oct 26 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-2
- License fix

pfmon-3.2-0.071017.3.fc9
------------------------
* Fri Oct 26 2007 Will Cohen <wcohen at redhat.com> - 3.2-0.071017.3
- Correct BuildRequires, should be elfutils-libelf-devel-static.

* Fri Oct 26 2007 Will Cohen <wcohen at redhat.com> - 3.2-0.071017.2
- Correct BuildRequires.

* Wed Oct 24 2007 Will Cohen <wcohen at redhat.com> - 3.2-0.071017.1
- Update to pfmon-3.2-071017.

php-channel-phing-1.0.0-5.fc9
-----------------------------
* Tue Oct 30 2007 Alexander Kahl <akahl at iconmobile.com> - 1.0.0-5
- exchanged correct channel.xml

php-pecl-memcache-2.2.1-1.fc9
-----------------------------

phpMyAdmin-2.11.2-1.fc9
-----------------------
* Mon Oct 29 2007 Mike McGrath <mmcgrath at redhat.com> 2.11.2-1
* upstream released new version

* Mon Oct 22 2007 Mike McGrath <mmcgrath at redhat.com> 2.11.1.2-1
* upstream released new version

physfs-1.0.1-7.fc9
------------------

pidgin-2.2.2-1.fc9
------------------

piklab-0.15.0-1.fc9
-------------------
* Mon Oct 22 2007 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 0.15.0-1
- New upstream version
  - Update %patch2

pikloops-0.2.5-1.fc9
--------------------

pinball-0.3.1-10.fc9
--------------------
* Sun Oct 21 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.3.1-10
- Drop the bogus -devel package (also fixing the multilib conficts caused by
  it, bz 342881)

pingus-0.7.2-1.fc9
------------------

pinot-0.76-7.fc9
----------------
* Tue Oct 30 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.76-7
- Rebuild against xapian 1.0.4

* Sun Oct 21 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.76-6
- Readd openssl buildrequires

* Sun Oct 21 2007 Adel Gadllah <adel.gadllah at gmail.com> 0.76-5
- Rediff openssl patch

pitivi-0.11.0-1.fc9
-------------------
* Tue Oct 16 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.0-1
- Update to 0.11.0

pixman-0.9.6-3.fc9
------------------
* Wed Oct 31 2007 Behdad Esfahbod <besfahbo at redhat.com> 0.9.6-3
- Third time's the charm.

* Wed Oct 31 2007 Behdad Esfahbod <besfahbo at redhat.com> 0.9.6-2
- Second try.

* Wed Oct 31 2007 Behdad Esfahbod <besfahbo at redhat.com> 0.9.6-1
- Update to 0.9.6 release.

planner-0.14.2-10.fc9
---------------------
* Sat Oct 20 2007 Caolan McNamara <caolanm at redhat.com> - 0.14.2-10
- Resolves: rhbz#342891 multiarch conflicts in planner

poker-network-1.2.0-3.fc9
-------------------------
* Sun Oct 21 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-3
- Remove devel subpackage and move to poker2d

poker2d-1.2.0-3.fc9
-------------------
* Mon Oct 22 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-3
- Fix up BuildRequires

* Sun Oct 21 2007 Christopher Stone <chris.stone at gmail.com> 1.2.0-2
- Move pkgconfig file into this spec since it is arch specific
- Add patch to properly handle libexec

policycoreutils-2.0.31-13.fc9
-----------------------------
* Mon Nov 05 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-13
- Remove -v from restorecon in fixfiles

* Mon Nov 05 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-12
- Fix filter and search capabilities, add wait cursor

* Fri Nov 02 2007 Dan Walsh <dwalsh at redhat.com> 2.0.31-11
- Translate booleans via policy.xml
- Allow booleans to be set via semanage

postfix-2:2.4.5-3.fc9
---------------------
* Wed Nov 07 2007 Thomas Woerner <twoerner at redhat.com> 2:2.4.5-3
- fixed multilib conflict for makedefs.out: rename to makedefs.out-ppc
  (rhbz#342941)
- enabled mysql support

postgresql-odbc-08.02.0500-1.fc9
--------------------------------
* Fri Nov 02 2007 Tom Lane <tgl at redhat.com> 08.02.0500-1
- Update to version 08.02.0500

postgresql-pgpool-II-1.3-1.fc9
------------------------------
* Tue Oct 23 2007 Devrim Gunduz <devrim at CommandPrompt.com> 1.3-1
- Update to 1.3

ppc64-utils-0.12-3.fc9
----------------------

psi-0.11-1.fc9
--------------
* Wed Oct 17 2007 Aurelien Bompard <abompard at fedoraproject.org> 0.11-1
- version 0.11

* Wed Aug 30 2006 Aurelien Bompard <abompard at fedoraproject.org> 0.10-5
- rebuild

* Thu Apr 13 2006 Aurelien Bompard <gauret[AT]free.fr> 0.10-4
- update translations for CS, DE, ET and VI

pth-2.0.7-5
-----------
* Sun Oct 21 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.0.7-5
- Patch pth-config.
  This shall fix the multiarch conflict in pth-devel (#342961).
  It must not return -I/usr/include and -L/usr/{lib,lib64} either,
  since these are default search paths already.
- Replace the config.status CFLAGS sed expr with a patch.

pwlib-1.10.10-3.fc9
-------------------
* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com> - 1.10.10-3
- fix a typo in summary
- Resolves: #239216

pygobject2-2.14.0-2.fc9
-----------------------
* Fri Oct 26 2007 Matthew Barnes <mbarnes at redhat.com> - 2.14.0-2.fc9
- Remove redundant requirements.
- Use name tag where appropriate.

pygtk2-2.12.0-3.fc9
-------------------
* Fri Oct 26 2007 Matthew Barnes <mbarnes at redhat.com> - 2.12.0-3.fc8
- Add subpackage pygtk2-doc to avoid multilib conflicts.

pygtksourceview-2.0.0-2.fc9
---------------------------
* Fri Oct 26 2007 Matthew Barnes <mbarnes at redhat.com> - 2.0.0-2.fc9
- Add subpackage pygtksourceview-doc (bug #342991).

pykickstart-1.21-1.fc9
----------------------
* Tue Nov 06 2007 Chris Lumens <clumens at redhat.com> 1.21-1
- Save script line numbers for debugging.
- More internal cleanups.

* Wed Oct 31 2007 Chris Lumens <clumens at redhat.com> 1.20-1
- Pull wiki docs from the new location.
- Fix error messages for options that have been removed after having been
  previously deprecated.
- zerombr no longer takes any arguments.
- %packages --ignoredeps --resolvedeps have been removed.
- firewall --high --medium have been removed.
- vnc --connect has been removed.
- xconfig options from monitor have now been removed.
- --bytes-per-inode has been marked as deprecated.
- Fix typos.
- Add --fsprofile option to disk commands (pjones).
- Add F9 support (pjones).
- Lots of internal fixes (clumens, pjones).

* Tue Oct 23 2007 Chris Lumens <clumens at redhat.com> 1.19-1
- Fix a traceback on the cdrom method.

python-biopython-1.44-2.fc9
---------------------------
* Sun Oct 28 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.44-2
- Drop patch to setup.py, applied upstream

* Sun Oct 28 2007 Alex Lancaster <alexl at users.sourceforge.net> 1.44-1
- Update to latest upstream (1.44).

python-cherrypy-2.2.1-7.fc9
---------------------------
* Sat Nov 03 2007 Luke Macken <lmacken at redhat.com> 2.2.1-7
- Apply backported fix from http://www.cherrypy.org/changeset/1766
  to improve CherryPy's SIGSTOP/SIGCONT handling (Bug #364911).
  Thanks to Nils Philippsen for the patch.

python-fedora-0.2.90.20-3.fc9
-----------------------------
* Wed Nov 07 2007 Luke Macken <lmacken at redhat.com> - 0.2.90.20-2
- Require SQLAlchemy 0.3 for python-fedora-infrastructure

* Wed Nov 07 2007 Luke Macken <lmacken at redhat.com> - 0.2.90.20-1
- Latest upstream release

python-html2text-2.29-1.1
-------------------------
* Fri Nov 02 2007 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 2.29-1
- update to 2.29

python-lxml-1.3.5-1.fc9
-----------------------
* Mon Oct 22 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.3.5-1
- Update to 1.3.5.

* Thu Aug 30 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.3.4-1
- Update to 1.3.4.

python-mecab-0.96-2.fc9.1
-------------------------
* Fri Oct 26 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-2
- License fix

python-myghty-1.1-5.fc9
-----------------------
* Sat Oct 27 2007 Luke Macken <lmacken at redhat.com> 1.1-5
- Fix broken Source0

python-qpid-0.2-1
-----------------

python-ruledispatch-0.5a0-0.8.svnr2306.fc9
------------------------------------------
* Sat Oct 27 2007 Luke Macken <lmacken at redhat.com> 0.5a0-0.7.svn2305
- Fix broken URL and Source0

python-simplejson-1.7.3-2.fc9
-----------------------------
* Wed Oct 24 2007 Luke Macken <lmacken at redhat.com> - 1.7.3-2
- Include the LICENSE.txt

python-telepathy-0.14.0-2.fc9
-----------------------------
* Thu Nov 01 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.14.0-2
- Add examples to docs.

* Sat Oct 13 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.14.0-1
- Update to 0.14.0.

* Sun Aug 05 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.13.13-2
- Update license tag.

python-turbocheetah-0.9.5-9.fc9
-------------------------------
* Fri Oct 26 2007 Luke Macken <lmacken at redhat.com> - 0.9.5-9
- Fix broken URL (#353951)

q-7.8-1.fc9
-----------
* Wed Oct 24 2007 Gerard Milmeister <gemi at bluewin.ch> - 7.8-1
- new version 7.8

* Thu Feb 15 2007 Gerard Milmeister <gemi at bluewin.ch> - 7.6-2
- use ncurses instead of termcap

* Sun Jan 07 2007 Gerard Milmeister <gemi at bluewin.ch> - 7.6-1
- new version 7.6

qdbm-1.8.76-1.fc9
-----------------
* Sun Nov 04 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.8.76-1
- 1.8.76

qt-1:3.3.8-10.fc9
-----------------
* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com> - 3.3.8-10
- rh#239216, fix a typo in qt-config description

* Thu Oct 04 2007 Than Ngo <than at redhat.com> - 3.3.8-9
- rh#309091, qt should provide %{qtdir}/plugins/styles
- rh#276521, qt-copy patches 0079, 0080, 0082 and 0084

* Mon Sep 17 2007 Than Ngo <than at redhat.com> - 3.3.8-8
- CVE-2007-4137

qt4-4.3.2-5.fc9
---------------
* Mon Oct 22 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.2-5
- -optimized-qmake

* Fri Oct 19 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.2-4
- slowdown with 4.3.2 (#334281)

* Tue Oct 16 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 4.3.2-2
- create/own %_qt4_plugindir/styles

qt4-theme-quarticurve-0.0-0.8.beta5.fc9
---------------------------------------
* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.8.beta5
- Fix setup command (forgot to update directory name).

* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.7.beta5
- Don't own %{qtplugindir}/styles, now owned by qt4.

* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 0.0-0.6.beta5
- Update to beta 5:
  - Force selection color to always active (as in Qt/KDE 3)
  - Dock widgets now look much closer to the Qt 3 theme
  - Draw frames around status bar sections (as in Qt 3)

queuegraph-1.1-2.fc9
--------------------

rarian-0.6.0-2.fc9
------------------
* Tue Nov 06 2007 Matthew Barnes <mbarnes at redhat.com> - 0.6.0-2
- Own /usr/share/help (RH bug #363311).

readline-5.2-8.fc9
------------------
* Mon Nov 05 2007 Miroslav Lichvar <mlichvar at redhat.com> 5.2-8
- fix cursor position when prompt has one invisible character (#358231)
- merge review fixes (#226361)
- fix source URL

recordmydesktop-0.3.6-1.fc9
---------------------------
* Sun Oct 21 2007 Sindre Pedersen Bj??rdal <foolish[AT]guezz.net> - 0.3.6-1
- New version
- Update URL

repoview-0.6.1-2.fc9
--------------------
* Thu Oct 25 2007 Seth Vidal <skvidal at fedoraproject.org> - 0.6.1-2
- add fedora repoview templates

revisor-2.0.5-5.fc9
-------------------
* Sat Oct 20 2007 Jonathan Steffan <jon a fedoraunity.org> 2.0.5-5
- Update spec for release

* Tue Oct 02 2007 Jeroen van Meeuwen <kanarip a fedoraunity.org> 2.0.5-3
- Bugfixes to x86_64 packageSack creation
- Bugfixes

rhythmbox-0.11.2-11.fc9
-----------------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 0.11.2-11
- Rebuild against new dbus-glib

* Thu Oct 11 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.2-10
- Add patch to avoid Rhythmbox escaping the primary text in notifications
  as per the spec (#242260)

* Wed Oct 10 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.2-9
- Add the plugin to handle MTP devices (#264541)

rkward-0.4.8-2.fc9
------------------
* Mon Oct 22 2007 Pingou <pingoufc4 at yahoo.fr> 0.4.8-2
- Problem in CVS

* Mon Oct 22 2007 Pingou <pingoufc4 at yahoo.fr> 0.4.8-1
- Update to 0.4.8 and R 2.6

roundcubemail-0.1-0.8rc2.1.fc9
------------------------------
* Fri Oct 26 2007 Jon Ciesla <limb at jcomserv.net> = 0.1-0.8rc2
- Upgrade to 0.1-rc2

* Thu Aug 16 2007 Jon Ciesla <limb at jcomserv.net> = 0.1-0.7rc1.1
- License tag correction.

rpm-4.4.2.2-7.fc9
-----------------
* Wed Oct 24 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-7
- Use package NEVRA everywhere for rpmProblems (#349091)
- The python problem addressed in -6 was related but a different issue...

* Wed Oct 24 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-6
- Don't mess up problem pkgNEVR in python ts.check() (#349091)

* Mon Oct 22 2007 Panu Matilainen <pmatilai at redhat.com> 4.4.2.2-5
- add missing popt-devel dependency to rpm-devel

rsh-0.17-45.fc9
---------------
* Sat Oct 20 2007 Steve Grubb <sgrubb at redhat.com> 0.17-45
- update for audit

rss-glx-0.8.1.p-17.fc9
----------------------
* Mon Nov 05 2007 Nils Philippsen <nphilipp at redhat.com> 0.8.1.p-17
- make screensavers show up in screensaver preferences again (#365991)

* Tue Oct 30 2007 Nils Philippsen <nphilipp at redhat.com> 0.8.1.p-16
- don't show screensaver hacks in main menu (#357451)

rsync-3.0.0-0.pre4.fc9
----------------------
* Sat Oct 27 2007 Simo Sorce <ssorce at redhat.com> 3.0.0-0.pre4.fc9
- Fourth prerelease

* Mon Oct 15 2007 Simo Sorce <ssorce at redhat.com> 3.0.0-0.pre2.1.fc9
- Add support for IPv6 by default with xinetd

* Fri Oct 12 2007 Simo Sorce <ssorce at redhat.com> 3.0.0-0.pre2.fc9
- Second prerelease

ruby-1.8.6.111-1.fc9
--------------------
* Mon Oct 29 2007 Akira TAGOH <tagoh at redhat.com> - 1.8.6.111-1
- New upstream release.
- ruby-1.8.6.111-CVE-2007-5162.patch: Update a bit with backporting the changes
   at trunk to enable the fix without any modifications on the users' scripts.
   Note that Net::HTTP#enable_post_connection_check isn't available anymore.
   If you want to disable this post-check, you should give OpenSSL::SSL::VERIFY_NONE
   to Net::HTTP#verify_mode= instead of.

* Mon Oct 15 2007 Akira TAGOH <tagoh at redhat.com> - 1.8.6.110-2
- Enable pthread support for ppc too. (#201452)
- Fix unexpected dependencies appears in ruby-libs. (#253325)

* Wed Oct 10 2007 Akira TAGOH <tagoh at redhat.com> - 1.8.6.110-1
- New upstream release.
  - ruby-r12567.patch: removed.
- ruby-1.8.6-CVE-2007-5162.patch: security fix for Net::HTTP that is
  insufficient verification of SSL certificate.

ruby-RMagick-2.0.0-0.3.beta5.fc9
--------------------------------

ruby-gnome2-0.16.0-14.fc9
-------------------------

ruby-mecab-0.96-2.fc9.1
-----------------------
* Fri Oct 26 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.96-2
- License fix

rxvt-2.7.10-14.fc9
------------------
* Wed Nov 07 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.7.10-14
- use utempter instead of wtmp/utmp (#214130)

rxvt-unicode-8.4-1.fc9
----------------------
* Sun Oct 28 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 8.4-1
- version upgrade

sane-backends-1.0.18-18.fc9
---------------------------
* Wed Nov 07 2007 Nils Philippsen <nphilipp at redhat.com> - 1.0.18-18
- move backend .so files out of -devel into main package (#209389)

sbcl-1.0.11-1.fc9
-----------------
* Wed Oct 31 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.11-1
- sbcl-1.0.11

scim-array-0.0.2-2.fc9
----------------------
* Wed Oct 31 2007 Ding-Yi Chen <dchen at redhat.com> - 0.0.2-1
- Correct URL

scorched3d-41.1-1.fc9
---------------------
* Tue Nov 06 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 41.1-1
- New upstream release 41.1

sdparm-1.02-1.fc9
-----------------
* Mon Nov 05 2007 Terje Rosten <terje.rosten at ntnu.no> - 1.02-1
- 1.02

seamonkey-1.1.6-2.fc9
---------------------
* Mon Nov 05 2007 Kai Engert <kengert at redhat.com> - 1.1.6-2
- SeaMonkey 1.1.6

* Fri Oct 19 2007 Kai Engert <kengert at redhat.com> - 1.1.5-2
- SeaMonkey 1.1.5

seedit-2.2.0-1.fc9
------------------
* Tue Oct 30 2007 Yuichi Nakamura <ynakam at hitachisoft.jp> 2.2.0-1
- Version 2.2.0, works on F8.
- Removed libsepol from requires and buildrequires.
- In uninstall time, unneeded rules are removed from audit.rules.

sepostgresql-8.2.5-1.51.fc9
---------------------------
* Thu Nov 01 2007 <kaigai at kaigai.gr.jp> - 8.2.5-1.51
- Re-organize repository to prepare to branch 8.3.x based tree.
  (no differences from 8.2.5-1.33)

sg3_utils-1.25-1.fc9
--------------------
* Mon Oct 22 2007 Phil Knirsch <pknirsch at redhat.com> - 1.25-1
- Fixed URLs
- Updated to sg3_utils-1.25

shapelib-1.2.10-15.20060304cvs
------------------------------
* Sun Oct 21 2007 Shawn McCann <mccann0011 at hotmail.com> - 1.2.10-15.20060304cvs
- Fix for bug 339931

shared-mime-info-0.22-4.fc9
---------------------------
* Mon Nov 05 2007 - Bastien Nocera <bnocera at redhat.com> - 0.22-4
- Make Totem the default for the mime-types it handles (#366101)

sip-4.7.1-1.fc9
---------------
* Mon Oct 22 2007 Than Ngo <than at redhat.com> - 4.7.1-1
- 4.7.1

* Mon Oct 01 2007 Than Ngo <than at redhat.com> - 4.6-3
- fix rh#289321, sipconfig.py includes wrong py_lib_dir, thanks to Rex Dieter

* Thu Aug 30 2007 Than Ngo <than at redhat.com> - 4.6-2.fc7
- typo in description

slang-2.1.3-1.fc9
-----------------
* Mon Nov 05 2007 Miroslav Lichvar <mlichvar at redhat.com> - 2.1.3-1
- update to 2.1.3

slrn-0.9.8.1pl1-5.20070716cvs.fc9
---------------------------------
* Fri Nov 02 2007 Miroslav Lichvar <mlichvar at redhat.com> 0.9.8.1pl1-5.20070716cvs
- drop asearch patch (#363781)

smart-0.52-51.fc9
-----------------
* Wed Oct 24 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.52-51
- Re-remove dropped and no longer needed autofs5 patch.

* Sun Oct 07 2007 Axel Thimm <Axel.Thimm at ATrpms.net> - 0.52-50
- Update to 0.52.
- Fix pam stack type detection.

smartmontools-1:5.37-8.2.fc9
----------------------------
* Wed Oct 31 2007 Tomas Smetana <tsmetana at redhat.com> - 1:5.37-8.2
- rebuild (one more error in autogen.sh)

* Wed Oct 31 2007 Tomas Smetana <tsmetana at redhat.com> - 1:5.37-8.1
- fix build with new automake

* Wed Oct 31 2007 Tomas Smetana <tsmetana at redhat.com> - 1:5.37-8
- fix #359561 - typo in smartd-conf.py causes smartd to skip all disks

smolt-0.9.9.2-1.fc9
-------------------
* Thu Oct 25 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9.2-1
- Upstream released new version

* Tue Oct 23 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9.1-4
- Upstream released new version

* Thu Oct 18 2007 Mike McGrath <mmcgrath at redhat.com> 0.9.9-2
- Fixed /etc/smolt/ ownership issue

sonata-1.3-1.fc9
----------------
* Tue Oct 30 2007 Micha?? Bentkowski <mr.ecik at gmail.com> - 1.3-1
- One three

soprano-1.95.0-3.fc9
--------------------
* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 1.95.0-3
- BR clucene-core-devel >= 0.9.20-2 to make sure we get a fixed package

* Fri Oct 26 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> 1.95.0-2
- drop findclucene patch, fixed in clucene-0.9.20-2

sox-14.0.0-1.fc9
----------------
* Mon Oct 29 2007 Jiri Moskovcak <jmoskovc at redhat.com> - 14.0.0-1
- New version 14.0.0
- Thanks to Chris Bagwell <chris at cnpbagwell dot com> for initial changes to spec file

spandsp-0.0.4-0.6.pre11.fc9
---------------------------
* Thu Nov 01 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.0.4-0.6.pre11
- Try and fix multilib problems with generated API docs.

* Fri Oct 26 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.0.4-0.5.pre11
- Update to 0.0.4pre11

sparse-0.4-2.fc9
----------------
* Thu Nov 01 2007 Roland McGrath <roland at redhat.com> - 0.4-2
- Upgrade to 0.4
- Install man pages, c2xml.
- Run make check in rpmbuild.

squid-7:2.6.STABLE16-3.fc9
--------------------------
* Wed Oct 31 2007 Martin Bacovsky <mbacovsk at redhat.com> - 7:2.6.STABLE16-3
- arp-acl was enabled

* Tue Sep 25 2007 Martin Bacovsky <mbacovsk at redhat.com> - 7:2.6.STABLE16-2
- our fd_config patch was replaced by upstream's version 
- Source1 (FAQ.sgml) points to local source (upstream's moved to wiki)

* Fri Sep 14 2007 Martin Bacovsky <mbacovsk at redhat.com> - 7:2.6.STABLE16-1
- upgrade to latest upstream 2.6.STABLE16

ssmtp-2.61-11.5.fc9.1
---------------------
* Wed Oct 24 2007 lonely wolf <wolfy at nobugconsulting.ro> 2.61-11.5.1
- adds back /usr/sbin/sendmail provides, rpmbuild by default does not add it

* Wed Oct 24 2007 lonely wolf <wolfy at nobugconsulting.ro> 2.61-11.5
- fixes https://bugzilla.redhat.com/show_bug.cgi?id=235594 by removing MTA
  and smtpdaemon provides, as the packages which required those were fixed

stardict-3.0.1-1.fc9
--------------------
* Thu Nov 08 2007 Hu Zheng <zhu at redhat.com> - 3.0.1-1
- Update to upstream.
stellarium-0.9.0-6.fc9
----------------------
* Tue Oct 23 2007 Will Woods <wwoods at redhat.com> 0.9.0-6
- Fix opengl-game-wrapper.sh usage

strigi-0.5.7-1.fc9
------------------
* Tue Oct 30 2007 Deji Akingunola <dakingun at gmail.com> - 0.5.7-1
- Update to 0.5.7 release
- Fix multilibs conflict (Bug #343221, patch by Kevin Kofler)

* Sun Sep 09 2007 Deji Akingunola <dakingun at gmail.com> - 0.5.5-2
- Rebuild for BuildID changes

* Sat Aug 11 2007 Deji Akingunola <dakingun at gmail.com> - 0.5.5-1
- Update to 0.5.5 release

supertux-0.3.0-3.fc9
--------------------
* Fri Oct 19 2007 Nils Philippsen <nphilipp at redhat.com> 0.3.0-3
- use opengl-games-wrapper.sh from Fedora 7 on (#335701)

* Fri Oct 19 2007 Nils Philippsen <nphilipp at redhat.com> 0.3.0-2
- use opengl-games-wrapper.sh from Fedora 8 on (#335701)

* Tue Feb 13 2007 Steven Pritchard <steve at kspei.com> 0.3.0-1
- Update to 0.3.0.
- Update URL.
- Drop compile fix patch.
- BR: physfs-devel, openal-devel, libvorbis-devel.
- BR: gettext, flex, bison, jam.
- Build uses jam instead of make now.
- Update doc list.
- Minor spec cleanup.

sword-1.5.10-1.fc9
------------------
* Mon Nov 05 2007 Deji Akingunola <dakingun at gmail.com> - 1.5.10-1
- Update to version 1.5.10

sylpheed-2.4.7-2
----------------
* Fri Nov 02 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.7-2
- Patch a memory leak and glib critical warning in LDAP syldap.c.

synce-gnomevfs-0.9.0-6.fc9
--------------------------

sysstat-8.0.2-2.fc9
-------------------
* Thu Nov 08 2007 Ivana Varekova <varekova at redhat.com> - 8.0.2-2
- change license tag
- remove sysstat.crond source (add -d)
- remove obsolete sysconfig file
- spec file cleanup

* Mon Nov 05 2007 Ivana Varekova <varekova at redhat.com> - 8.0.2-1
- update 8.0.2
- spec file cleanup

* Wed Oct 24 2007 Ivana Varekova <varekova at redhat.com> - 8.0.1-2
- remove useless patches

system-config-date-1.9.15-1.fc9
-------------------------------
* Tue Oct 23 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.15-1
- cope with comments in /etc/ntp/step-tickers (#333881)

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.14-1
- avoid traceback when neither xdg-open nor htmlview is found

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com> 1.9.13-1
- change hicolor-icon-theme requirement to be "uncolored" (without
  "(post)"/"(postun)")
- use full path to call gtk-update-icon-cache
- don't let gtk-update-icon-cache fail scriptlets
- use "make %{?_smp_mflags}"
- remove "ExclusiveOS: Linux"
- remove obsolete no.po translation file
- use "%defattr(-,root,root,-)"
- add release tags to changelog versions to appease rpmlint

system-config-firewall-1.0.9-1.fc9
----------------------------------
* Mon Nov 05 2007 Thomas Woerner <twoerner at redhat.com> 1.0.9-1
- do not report configuration failed if ipv6 is disabled (rhbz#355561)
- print messages if lokkit failed
- lokkit be more verbose on restarting ipXtables in verbose mode

* Fri Oct 26 2007 Thomas Woerner <twoerner at redhat.com> 1.0.8-2
- lokkit: write new config with nostart option (rhbz#353961)
- translation fixes for de, it, nb, sr at latin

* Mon Oct 01 2007 Thomas Woerner <twoerner at redhat.com> 1.0.8-1
- use extension match for protocols (rhbz#229879)
- use ipv6-icmp instead of icmpv6 (rhbz#291001)
- use ':' in tui as port/proto delimiter for other ports (rhbz#292171)
- some translation fixes

system-config-kickstart-2.7.13-1.fc9
------------------------------------
* Tue Oct 23 2007 Chris Lumens <clumens at redhat.com> 2.7.13-1
- Fix a traceback when importing yum (#337161).
- Remove obsolete translation (#332501).
- Rework bootloader UI to make it easier to add other arches.

system-config-language-1.2.13-1.fc9
-----------------------------------
* Mon Oct 22 2007 Lingning Zhang <lizhang at redhat.com> - 1.2.13
- fix bug332361.

system-config-printer-0.7.77-1.fc9
----------------------------------
* Tue Oct 30 2007 Tim Waugh <twaugh at redhat.com> 0.7.77-1
- 0.7.77:
  - Tooltips for the button bar buttons (bug #335601).

* Mon Oct 15 2007 Tim Waugh <twaugh at redhat.com> 0.7.76-1
- 0.7.76.

* Thu Oct 04 2007 Tim Waugh <twaugh at redhat.com> 0.7.75-1
- 0.7.75.

system-config-vsftpd-0.4.5-3.fc9
--------------------------------
* Tue Oct 30 2007 Maros Barabas <mbarabas at redhat.com> - 0.4.5-3
- rebuild for rawhide

* Thu Oct 25 2007 Maros Barabas <mbarabas at redhat.com> - 0.4.5-2
-  fix problems with parsing file names with spaces in Transfer log

tailor-0.9.29-1.fc9
-------------------
* Thu Oct 25 2007 Dan Horak <dan[at]danny.cz> 0.9.29-1
- update to upstream version 0.9.29 (fixes #349711)

tar-2:1.17-4.fc9
----------------
* Tue Oct 23 2007 Radek Brich <rbrich at redhat.com> 2:1.17-4
- upstream patch for CVE-2007-4476
  (tar stack crashing in safer_name_suffix)

taxipilot-0.9.2-3.fc9
---------------------
* Mon Oct 22 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.9.2-3
- Put our own private lib in a subdir of /usr/lib so that we no longer become
  multilib (bz 343261)

tcpdump-14:3.9.8-1.fc9
----------------------
* Wed Oct 24 2007 Miroslav Lichvar <mlichvar at redhat.com> - 14:3.9.8-1
- update to 3.9.8
- don't use gethostbyaddr
- fix default user in man page

tcpreplay-3.2.3-1.fc9
---------------------
* Fri Nov 02 2007 Bojan Smojver <bojan at rexursive com> - 3.2.3-1
- bump up to 3.2.3
- drop compilation fix patch, now upstream

* Thu Nov 01 2007 Bojan Smojver <bojan at rexursive com> - 3.2.2-2
- fix compilation

* Thu Nov 01 2007 Bojan Smojver <bojan at rexursive com> - 3.2.2-1
- bump up to 3.2.2

telepathy-gabble-0.6.1-1.fc9
----------------------------
* Wed Nov 07 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.6.1-1
- Update to 0.6.1.

telepathy-salut-0.1.6-1.fc9
---------------------------
* Wed Nov 07 2007 Brian Pepple <bpepple at fedoraproject.org> - 0.1.6-1
- Update to 0.1.6.
- Add man page.
- Bump min version of telepathy-glib-devel needed.

texinfo-4.11-2.fc9
------------------
* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com> - 4.11-2
- fix a typo in texinfo-tex summary
- Resolves: #239216

thinkfinger-0.3-7.fc9
---------------------
* Mon Oct 29 2007 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.3-7
- New README.Fedora, thanks to Jon Fautley (RH #356281)

tinyerp-4.2.0-1.fc9
-------------------
* Wed Oct 31 2007 Dan Horak <dan[at]danny.cz> 4.2.0-1
- update to upstream version 4.2.0
- add Requires for scriptlets
- update init script (#247074)
- spec file cleanup, remove support for FC <= 4

toped-0.8.6-1.fc9
-----------------
* Fri Oct 12 2007 Chitlesh Goorah <chitlesh at fedoraproject.org> - 0.8.6-1
- New upstream release

tor-0.1.2.18-1.fc9
------------------
* Tue Oct 30 2007 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.1.2.18-1
- updated to 0.1.2.18

totem-2.21.1-1.fc9
------------------
* Wed Oct 31 2007 - Bastien Nocera <bnocera at redhat.com> - 2.21.1-1
- Update to 2.21.1

* Wed Oct 24 2007 - Bastien Nocera <bnocera at redhat.com> - 2.21.0-3
- Add python BRs so we have Python support for the YouTube plugin

* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.21.0-2
- Rebuild against new dbus-glib

transmission-0.92-1.fc9
-----------------------
* Tue Nov 06 2007 Denis Leroy <denis at poolshark.org> - 0.92-1
- Update to upstream 0.92, important bug fixes

* Sat Nov 03 2007 Denis Leroy <denis at poolshark.org> - 0.91-1
- Update to upstream 0.91
- Removal of -gtk suffix
- Obsoleting manpath patch

turba-2.1.5-1.fc9
-----------------
* Sat Oct 20 2007 Brandon Holbrook <fedora at theholbrooks.org> 2.1.5-1
- Upgraded to 2.1.5

tzdata-2007i-1.fc9
------------------
* Mon Nov 05 2007 Petr Machata <pmachata at redhat.com> - 2007i-1
- Upstream 2007i
  - Syria DST will take place at Midnight between Thursday and Friday.
  - Cuba will end DST on the last Sunday of October.
- Update tst-timezone.c from glibc CVS

udunits-1.12.4-12.fc9
---------------------

uncrustify-0.40-2.fc9
---------------------
* Tue Nov 06 2007 Neal Becker <ndbecker2 at gmail.com> - 0.40-2
- Increase release tag to satisfy cvs
- Bump tag
units-1.87-1.fc9
----------------
* Wed Oct 31 2007 Zdenek Prikryl <zprikryl at redhat.com> - 1.87-1
- New version 1.87

util-linux-ng-2.13-4.fc9
------------------------
* Wed Oct 31 2007 Karel Zak <kzak at redhat.com> 2.13-4
- fix #354791 - blockdev command calls the blkpg ioctl with a wrong data structure

vavoom-1.25-1.fc9
-----------------
* Tue Oct 09 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.25-1
- New upstream release 1.25

* Sat Sep 15 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.24-4
- Don't build with libmad support even if libmad happens to be on the system

vdr-ttxtsubs-0.0.5-2.fc9
------------------------

vinagre-0.3-2.fc9
-----------------

vino-2.20.1-2.fc9
-----------------
* Tue Oct 23 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-2
- Rebuild against new dbus-glib

vips-7.12.5-3.fc9
-----------------
* Tue Oct 23 2007 Adam Goode <adam at spicenitz.org> - 7.12.5-3
- Eliminate build differences in version.h to work on multiarch

vixie-cron-4:4.3-2.fc9
----------------------
* Mon Oct 29 2007 Marcela Maslanova <mmaslano at redhat.com> - 4:4.3-2
- rebuild with correct source file
- 247228: cron jobs fail semi-randomly if sendmail incapacitated
- 226529: Merge Review: vixie-cron (use bcond macros)

vnc-4.1.2-23.fc9
----------------
* Tue Oct 23 2007 Adam Tkac <atkac redhat com> 4.1.2-23
- disabled Composite extension (#242280, #339811)

* Mon Sep 24 2007 Adam Tkac <atkac redhat com> 4.1.2-22
- obsoleted vnc-s390.patch
- build with --disable-xorg

* Wed Aug 22 2007 Adam Tkac <atkac redhat com> 4.1.2-21
- rebuild (BuildID feature)
- GPLv2 license

vte-0.16.9-2.fc9
----------------
* Tue Nov 06 2007 Behdad Esfahbod <besfahbo at redhat.com> 0.16.9-2
- Package /usr/bin/vte in devel package
- Add docs to devel package

vym-1.10.0-1.fc9
----------------
* Thu Oct 18 2007 Jon Ciesla <limb at jcomserv.net> - 1.10.0-1
- Upgrade to 1.10.0.
- Applied several patches from Till Maas, which he sent upstream.
- Dropped findlang, as it doesn't work with Vym.

wine-0.9.48-1.fc9
-----------------
* Fri Oct 26 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.48-1
- version upgrade

* Sat Oct 13 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.47-1
- version upgrade

* Sun Oct 07 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.46-1
- version upgrade

wine-docs-0.9.48-1.fc9
----------------------
* Sat Oct 27 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.9.48-1
- version upgrade

wise2-2.2.0-3.fc9
-----------------

wordpress-2.3.1-1.fc9
---------------------
* Tue Oct 30 2007 Adrian Reber <adrian at lisas.de> - 2.3.1-1
- updated to 2.3.1 (bz 357731, wordpress XSS issue)

* Mon Oct 15 2007 Adrian Reber <adrian at lisas.de> - 2.3-1
- updated to 2.3
- disabled wordpress-core-update

wpa_supplicant-1:0.5.7-11.fc9
-----------------------------
* Sat Oct 20 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-11
- Add BLOB support to the D-Bus interface
- Fix D-Bus interface permissions so that only root can use the wpa_supplicant
    D-Bus interface

* Tue Oct 09 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-10
- Don't segfault with dbus control interface enabled and invalid network
    interface (rh #310531)

* Tue Sep 25 2007 Dan Williams <dcbw at redhat.com> - 0.5.7-9
- Always allow explicit wireless scans triggered from a control interface

wvdial-1.60-3.fc9
-----------------

xapian-bindings-1.0.4-1.fc9
---------------------------
* Tue Oct 30 2007 Adel Gadllah <adel.gadllah at gmail.com> 1.0.4-1
- Update to 1.0.4

xapian-core-1.0.4-1.fc9
-----------------------
* Tue Oct 30 2007 Adel Gadllah <adel.gadllah at gmail.com> 1.0.4-1
- Update to 1.0.4

* Thu Oct 25 2007 Adel Gadllah <adel.gadllah at gmail.com> 1.0.2-7
- Fix up multilib patch

xbase-2.0.0-8.fc9
-----------------
* Tue Oct 30 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.0.0-8
- fix multilib conflicts

xcircuit-3.4.27-1.fc9
---------------------
* Sun Oct 21 2007 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 3.4.27-1
- new upstream release
- added coreutils and gtk as requires: #339771

xen-3.1.0-13.fc9
----------------
* Fri Oct 26 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-13.fc9
- Fixed xenbaked tmpfile flaw (CVE-2007-3919)

* Wed Oct 10 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-12.fc8
- Pull in QEMU BIOS boot menu patch from KVM package
- Fix QEMU patch for locating x509 certificates based on command line args
- Add XenD config options for TLS x509 certificate setup

* Wed Sep 26 2007 Daniel P. Berrange <berrange at redhat.com> - 3.1.0-11.fc8
- Fixed rtl8139 checksum calculation for Vista (rhbz #308201)

xfce4-fsguard-plugin-0.4.0-1.fc9
--------------------------------
* Thu Nov 08 2007 Christoph Wickert <fedora christoph-wickert de> - 0.4.0-1
- Update to 0.4.0

xfce4-places-plugin-1.0.0-1.fc9
-------------------------------
* Wed Nov 07 2007 Christoph Wickert <fedora christoph-wickert de> - 0.0.10-1
- Update to 0.0.10

xfce4-sensors-plugin-0.10.99.2-1.fc9
------------------------------------
* Wed Nov 07 2007 Christoph Wickert <fedora christoph-wickert de> - 0.1.99.2-1
- Update to 0.10.99.2

* Sat Oct 27 2007 Christoph Wickert <fedora christoph-wickert de> - 0.1.99.1-1
- Update to 0.10.99.1
- Require hddtemp because it is supported now

xmoto-0.3.4-1.fc9
-----------------
* Thu Oct 25 2007 Jon Ciesla <limb at jcomserv.net> 0.3.4-1
- Bumped to 0.3.4.

xorg-x11-drv-ati-6.7.195-4.fc9
------------------------------
* Thu Nov 08 2007 Adam Jackson <ajax at redhat.com> 6.7.195-4
- radeon-6.7.195-faster-ddc.patch: Speed up X startup by assuming the
  monitor doesn't need a dead chicken waved over it to get DDC.

xorg-x11-proto-devel-7.3-4.fc9
------------------------------
* Thu Oct 25 2007 Kristian H??gsberg <krh at redhat.com> 7.3-4
- Pull in new glproto to get proto structs for GLX_SGIX_pbuffer.

xscreensaver-1:5.03-14.fc9
--------------------------
* Thu Nov 01 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.03-14
- Patch from upstream to fix screen depth problem (also "really"
  fix bug 336331).

xsri-1:2.1.0-13.fc9
-------------------
* Mon Oct 22 2007 Adam Jackson <ajax at redhat.com> 1:2.1.0-13
- BuildRequires: popt-devel

xsupplicant-1.2.8-4.fc9.4
-------------------------
* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.2.8-4.4
- fix it again!

yap-5.1.1-8.fc9
---------------
* Sat Oct 20 2007 Gerard Milmeister <gemi at bluewin.ch> - 5.1.1-8
- fix library path for 64-bit platforms

yelp-2.20.0-4.fc9
-----------------
* Sun Nov 04 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-4
- Fix a crash when loading the rarian docs

* Thu Nov 01 2007 Matthew Barnes <mbarnes at redhat.com> - 2.20.0-3
- Rebuild against gecko-libs 1.8.1.8.

* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-2
- Rebuild against new dbus-glib

zaptel-1.4.6-1.fc9
------------------
* Thu Nov 01 2007 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.4.6-1
- Update to 1.4.6
- Apply patch to fix AST-2007-024

zenity-2.20.0-3.fc9
-------------------
* Mon Oct 22 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.0-3
- Rebuild against new dbus-glib

zip-2.31-4.fc9
--------------
* Mon Nov 05 2007 Ivana Varekova <varekova at redhat.com> - 2.31-4
- fix "zip does not honor umask setting when creating archives"
- fix "zip segfaults by attempt to archive big file"
- spec file cleanup

zzuf-0.10-1.fc9
---------------
* Sat Nov 03 2007 Ville Skytt?? <ville.skytta at iki.fi> - 0.10-1
- 0.10.

Broken deps for i386
----------------------------------------------------------
	Democracy - 0.9.5.1-11.fc8.i386 requires firefox = 0:2.0.0.5
	Democracy - 0.9.5.1-11.fc8.i386 requires libboost_python.so.2
	Miro - 0.9.9.1-6.fc9.i386 requires gecko-libs = 0:1.8.1.8
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.i386 requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.i386 requires libmtp.so.6
	anaconda - 11.3.0.50-2.i386 requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.i386 requires libdhcp.so.1
	anaconda - 11.3.0.50-2.i386 requires libdhcp6client-0.10.so.0
	bibletime - 1.6.4-2.fc8.i386 requires libsword-1.5.9.so
	blam - 1.8.3-9.fc8.i386 requires gecko-libs = 0:1.8.1.8
	brasero - 0.6.1-1.fc8.i386 requires libtotem-plparser.so.7
	chmsee - 1.0.0-1.26.fc9.i386 requires firefox = 0:2.0.0.8
	devhelp - 0.16.1-2.fc9.i386 requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.i386 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.i386 requires gecko-libs = 0:1.8.1.8
	galeon - 2.0.3-13.fc8.i386 requires gecko-libs = 0:1.8.1.8
	gnome-python2-gtkmozembed - 2.19.1-9.fc9.i386 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.i386 requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.i386 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	libdhcp - 1.99.0-1.fc9.i386 requires libdhcp6client-0.10.so.0
	mkinitrd - 6.0.19-4.fc8.i386 requires libdhcp4client-3.0.6.so.0
	mkinitrd - 6.0.19-4.fc8.i386 requires libdhcp.so.1
	mkinitrd - 6.0.19-4.fc8.i386 requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc8.i386 requires libdhcp4client-3.0.6.so.0
	nash - 6.0.19-4.fc8.i386 requires libdhcp.so.1
	nash - 6.0.19-4.fc8.i386 requires libdhcp6client-0.10.so.0
	openoffice.org-core - 1:2.3.0-6.6.fc8.i386 requires libhunspell-1.1.so.0
	openvrml-devel - 0.16.6-6.fc9.i386 requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.i386 requires firefox = 0:2.0.0.8
	osgal - 1:0.6.1-1.fc8.i386 requires libosgManipulator.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgTerrain.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgViewer.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgParticle.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgDB.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgFX.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgSim.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgUtil.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgGA.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgText.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libOpenThreads.so.7
	osgal - 1:0.6.1-1.fc8.i386 requires libosg.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgManipulator.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgTerrain.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgViewer.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgUtil.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgParticle.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgDB.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgFX.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgSim.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgGA.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgText.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libOpenThreads.so.7
	osgcal - 0.1.46-2.fc8.i386 requires libosg.so.11
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	plplot-octave - 5.7.4-4.fc8.i386 requires octave(api) = 0:api-v27
	postfix-pflogsumm - 2:2.4.5-3.fc9.i386 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.i386 requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.i386 requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.i386 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.i386 requires xen-hypervisor-abi = 0:3.1
	yelp - 2.20.0-4.fc9.i386 requires gecko-libs = 0:1.8.1.8



Broken deps for x86_64
----------------------------------------------------------
	Democracy - 0.9.5.1-11.fc8.x86_64 requires libboost_python.so.2()(64bit)
	Democracy - 0.9.5.1-11.fc8.x86_64 requires firefox = 0:2.0.0.5
	Miro - 0.9.9.1-6.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.i386 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.x86_64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.x86_64 requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.x86_64 requires libmtp.so.6()(64bit)
	amarok - 1.4.7-7.fc8.i386 requires libmtp.so.6
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.x86_64 requires libdhcp4client-3.0.6.so.0()(64bit)
	bibletime - 1.6.4-2.fc8.x86_64 requires libsword-1.5.9.so()(64bit)
	blam - 1.8.3-9.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	brasero - 0.6.1-1.fc8.x86_64 requires libtotem-plparser.so.7()(64bit)
	chmsee - 1.0.0-1.26.fc9.x86_64 requires firefox = 0:2.0.0.8
	devhelp - 0.16.1-2.fc9.i386 requires gecko-libs = 0:1.8.1.8
	devhelp - 0.16.1-2.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.x86_64 requires gecko-devel = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.i386 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	galeon - 2.0.3-13.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-gtkmozembed - 2.19.1-9.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.x86_64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.x86_64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.i386 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.i386 requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.x86_64 requires libkdeprint_management.so.5()(64bit)
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	libdhcp - 1.99.0-1.fc9.i386 requires libdhcp6client-0.10.so.0
	libdhcp - 1.99.0-1.fc9.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	mkinitrd - 6.0.19-4.fc8.x86_64 requires libdhcp.so.1()(64bit)
	mkinitrd - 6.0.19-4.fc8.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	mkinitrd - 6.0.19-4.fc8.x86_64 requires libdhcp4client-3.0.6.so.0()(64bit)
	nash - 6.0.19-4.fc8.x86_64 requires libdhcp.so.1()(64bit)
	nash - 6.0.19-4.fc8.x86_64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc8.x86_64 requires libdhcp4client-3.0.6.so.0()(64bit)
	nash - 6.0.19-4.fc8.i386 requires libdhcp4client-3.0.6.so.0
	nash - 6.0.19-4.fc8.i386 requires libdhcp.so.1
	nash - 6.0.19-4.fc8.i386 requires libdhcp6client-0.10.so.0
	openoffice.org-core - 1:2.3.0-6.6.fc8.x86_64 requires libhunspell-1.1.so.0()(64bit)
	openvrml-devel - 0.16.6-6.fc9.i386 requires firefox-devel = 0:2.0.0.8
	openvrml-devel - 0.16.6-6.fc9.x86_64 requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.x86_64 requires firefox = 0:2.0.0.8
	osgal - 1:0.6.1-1.fc8.i386 requires libosgManipulator.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgTerrain.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgViewer.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgParticle.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgDB.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgFX.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgSim.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgUtil.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgGA.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libosgText.so.11
	osgal - 1:0.6.1-1.fc8.i386 requires libOpenThreads.so.7
	osgal - 1:0.6.1-1.fc8.i386 requires libosg.so.11
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgManipulator.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgDB.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgTerrain.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgViewer.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgSim.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgUtil.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosg.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgGA.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgText.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgParticle.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libOpenThreads.so.7()(64bit)
	osgal - 1:0.6.1-1.fc8.x86_64 requires libosgFX.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgManipulator.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgTerrain.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgDB.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgViewer.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgSim.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgUtil.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosg.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgGA.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgText.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgParticle.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libOpenThreads.so.7()(64bit)
	osgcal - 0.1.46-2.fc8.x86_64 requires libosgFX.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.i386 requires libosgManipulator.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgTerrain.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgViewer.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgUtil.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgParticle.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgDB.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgFX.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgSim.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgGA.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libosgText.so.11
	osgcal - 0.1.46-2.fc8.i386 requires libOpenThreads.so.7
	osgcal - 0.1.46-2.fc8.i386 requires libosg.so.11
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	plplot-octave - 5.7.4-4.fc8.x86_64 requires octave(api) = 0:api-v27
	postfix-pflogsumm - 2:2.4.5-3.fc9.x86_64 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.x86_64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.x86_64 requires libtotem-plparser.so.9()(64bit)
	rhythmbox - 0.11.2-11.fc9.i386 requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.i386 requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.x86_64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	xen - 3.1.0-13.fc9.x86_64 requires xen-hypervisor-abi = 0:3.1
	yelp - 2.20.0-4.fc9.x86_64 requires gecko-libs = 0:1.8.1.8



Broken deps for ppc
----------------------------------------------------------
	Democracy - 0.9.5.1-11.fc8.ppc requires firefox = 0:2.0.0.5
	Democracy - 0.9.5.1-11.fc8.ppc requires libboost_python.so.2
	Miro - 0.9.9.1-6.fc9.ppc requires gecko-libs = 0:1.8.1.8
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.ppc requires libmtp.so.6
	amarok - 1.4.7-7.fc8.ppc64 requires libmtp.so.6()(64bit)
	anaconda - 11.3.0.50-2.ppc requires libdhcp4client-3.0.6.so.0
	anaconda - 11.3.0.50-2.ppc requires libdhcp.so.1
	anaconda - 11.3.0.50-2.ppc requires libdhcp6client-0.10.so.0
	bibletime - 1.6.4-2.fc8.ppc requires libsword-1.5.9.so
	blam - 1.8.3-9.fc8.ppc requires gecko-libs = 0:1.8.1.8
	brasero - 0.6.1-1.fc8.ppc requires libtotem-plparser.so.7
	chmsee - 1.0.0-1.26.fc9.ppc requires firefox = 0:2.0.0.8
	devhelp - 0.16.1-2.fc9.ppc requires gecko-libs = 0:1.8.1.8
	devhelp - 0.16.1-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.ppc requires gecko-devel = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.ppc64 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.ppc requires gecko-libs = 0:1.8.1.8
	galeon - 2.0.3-13.fc8.ppc requires gecko-libs = 0:1.8.1.8
	gnome-python2-gtkmozembed - 2.19.1-9.fc9.ppc requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.ppc requires libtotem-plparser.so.7
	gnome-web-photo - 0.3-5.fc9.ppc requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.ppc requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint.so.5
	kdebase4 - 3.94.0-2.fc9.ppc requires libkdeprint_management.so.5
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	libdhcp - 1.99.0-1.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	libdhcp - 1.99.0-1.fc9.ppc requires libdhcp6client-0.10.so.0
	mkinitrd - 6.0.19-4.fc8.ppc requires libdhcp4client-3.0.6.so.0
	mkinitrd - 6.0.19-4.fc8.ppc requires libdhcp.so.1
	mkinitrd - 6.0.19-4.fc8.ppc requires libdhcp6client-0.10.so.0
	nash - 6.0.19-4.fc8.ppc64 requires libdhcp.so.1()(64bit)
	nash - 6.0.19-4.fc8.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc8.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	nash - 6.0.19-4.fc8.ppc requires libdhcp4client-3.0.6.so.0
	nash - 6.0.19-4.fc8.ppc requires libdhcp.so.1
	nash - 6.0.19-4.fc8.ppc requires libdhcp6client-0.10.so.0
	openoffice.org-core - 1:2.3.0-6.6.fc8.ppc requires libhunspell-1.1.so.0
	openvrml-devel - 0.16.6-6.fc9.ppc64 requires firefox-devel = 0:2.0.0.8
	openvrml-devel - 0.16.6-6.fc9.ppc requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.ppc requires firefox = 0:2.0.0.8
	osgal - 1:0.6.1-1.fc8.ppc requires libosgManipulator.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgTerrain.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgViewer.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgParticle.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgDB.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgFX.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgSim.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgUtil.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgGA.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libosgText.so.11
	osgal - 1:0.6.1-1.fc8.ppc requires libOpenThreads.so.7
	osgal - 1:0.6.1-1.fc8.ppc requires libosg.so.11
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgManipulator.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgTerrain.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgDB.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgViewer.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgSim.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgUtil.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosg.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgGA.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgText.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgParticle.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libOpenThreads.so.7()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgFX.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgManipulator.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgTerrain.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgDB.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgViewer.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgSim.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgUtil.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosg.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgGA.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgText.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgParticle.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libOpenThreads.so.7()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgFX.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc requires libosgManipulator.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgTerrain.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgViewer.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgUtil.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgParticle.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgDB.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgFX.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgSim.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgGA.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libosgText.so.11
	osgcal - 0.1.46-2.fc8.ppc requires libOpenThreads.so.7
	osgcal - 0.1.46-2.fc8.ppc requires libosg.so.11
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	plplot-octave - 5.7.4-4.fc8.ppc requires octave(api) = 0:api-v27
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libtotem-plparser.so.9()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc requires libtotem-plparser.so.9
	rhythmbox - 0.11.2-11.fc9.ppc requires libmtp.so.6
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	yelp - 2.20.0-4.fc9.ppc requires gecko-libs = 0:1.8.1.8



Broken deps for ppc64
----------------------------------------------------------
	Democracy - 0.9.5.1-11.fc8.ppc64 requires libboost_python.so.2()(64bit)
	Democracy - 0.9.5.1-11.fc8.ppc64 requires firefox = 0:2.0.0.5
	Miro - 0.9.9.1-6.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	NetworkManager-openvpn - 1:0.7.0-2.svn3047.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	NetworkManager-vpnc - 1:0.7.0-0.4.svn3030.fc8.ppc64 requires NetworkManager >= 1:0.7.0-0.4.svn3030
	PyQt-qscintilla - 3.17.1-3.fc8.ppc64 requires PyQt = 0:3.17.1
	amarok - 1.4.7-7.fc8.ppc64 requires libmtp.so.6()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp.so.1()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	anaconda - 11.3.0.50-2.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	bibletime - 1.6.4-2.fc8.ppc64 requires libsword-1.5.9.so()(64bit)
	brasero - 0.6.1-1.fc8.ppc64 requires libtotem-plparser.so.7()(64bit)
	chmsee - 1.0.0-1.26.fc9.ppc64 requires firefox = 0:2.0.0.8
	devhelp - 0.16.1-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	epiphany - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.6
	epiphany-devel - 2.20.1-3.fc9.ppc64 requires gecko-devel = 0:1.8.1.6
	epiphany-extensions - 2.20.1-2.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	galeon - 2.0.3-13.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-gtkmozembed - 2.19.1-9.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	gnome-python2-totem - 2.20.0-1.fc8.ppc64 requires libtotem-plparser.so.7()(64bit)
	gnome-web-photo - 0.3-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	gtkmozembedmm - 1.4.2.cvs20060817-15.fc8.ppc64 requires gecko-libs = 0:1.8.1.8
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint.so.5()(64bit)
	kdebase4 - 3.94.0-2.fc9.ppc64 requires libkdeprint_management.so.5()(64bit)
	libdhcp - 1.99.0-1.fc9.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	mkinitrd - 6.0.19-4.fc8.ppc64 requires libdhcp.so.1()(64bit)
	mkinitrd - 6.0.19-4.fc8.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	mkinitrd - 6.0.19-4.fc8.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	nash - 6.0.19-4.fc8.ppc64 requires libdhcp.so.1()(64bit)
	nash - 6.0.19-4.fc8.ppc64 requires libdhcp6client-0.10.so.0()(64bit)
	nash - 6.0.19-4.fc8.ppc64 requires libdhcp4client-3.0.6.so.0()(64bit)
	openoffice.org-core - 1:2.3.0-6.6.fc8.ppc64 requires libhunspell-1.1.so.0()(64bit)
	openvrml-devel - 0.16.6-6.fc9.ppc64 requires firefox-devel = 0:2.0.0.8
	openvrml-xembed - 0.16.6-6.fc9.ppc64 requires firefox = 0:2.0.0.8
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgManipulator.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgTerrain.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgDB.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgViewer.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgSim.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgUtil.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosg.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgGA.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgText.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgParticle.so.11()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libOpenThreads.so.7()(64bit)
	osgal - 1:0.6.1-1.fc8.ppc64 requires libosgFX.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgManipulator.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgTerrain.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgDB.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgViewer.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgSim.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgUtil.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosg.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgGA.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgText.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgParticle.so.11()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libOpenThreads.so.7()(64bit)
	osgcal - 0.1.46-2.fc8.ppc64 requires libosgFX.so.11()(64bit)
	perl-Spreadsheet-WriteExcel - 2.18-1.fc8.noarch requires perl(Date::Calc)
	plplot-octave - 5.7.4-4.fc8.ppc64 requires octave(api) = 0:api-v27
	postfix-pflogsumm - 2:2.4.5-3.fc9.ppc64 requires perl(Date::Calc)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libmtp.so.6()(64bit)
	rhythmbox - 0.11.2-11.fc9.ppc64 requires libtotem-plparser.so.9()(64bit)
	ruby-gtkmozembed - 0.16.0-14.fc9.ppc64 requires gecko-libs = 0:1.8.1.8
	sqlgrey - 1.7.5-1.fc7.noarch requires perl(Date::Calc)
	swatch - 3.2.1-1.fc8.1.noarch requires perl(Date::Calc)
	yelp - 2.20.0-4.fc9.ppc64 requires gecko-libs = 0:1.8.1.8





From jkeating at redhat.com  Mon Nov 26 14:30:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Nov 2007 09:30:42 -0500
Subject: WTF?  Inaccessible bug reports?
In-Reply-To: <Pine.LNX.4.64.0711260749050.17671@beer.tclug.org>
References: <20071120140550.GA20367@dspnet.fr.eu.org>
	<20071120082647.137221b6@weaponx>
	<20071120145119.GA26405@dspnet.fr.eu.org>
	<1195578414.3568.58.camel@localhost.localdomain>
	<20071120184133.GA51420@dspnet.fr.eu.org>
	<yojfxyze2tl.fsf@bird.phys.ntnu.no>
	<1195680550.4552.117.camel@localhost.localdomain>
	<yoj1waje08e.fsf@bird.phys.ntnu.no>
	<Pine.LNX.4.64.0711260749050.17671@beer.tclug.org>
Message-ID: <20071126093042.56d7c7f6@redhat.com>

On Mon, 26 Nov 2007 07:51:24 -0600 (CST)
Jima <jima at beer.tclug.org> wrote:

>   Sigh.  This is the first thing I do after rsyncing the Everything/
> tree to my local mirror.
>   RelEng, is there any way we could get images/ under Everything/,
> too? (Moving forward, that is -- I'm not requesting it be
> retroactive.)  With hardlinks the space shouldn't matter, right?
>   Thanks in advance for the consideration either way. :-)

Is it really that hard to add another repo line to your kickstart
file?  I'd rather not shuffle those files around if possible.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/3fa1b6cd/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov 26 14:30:21 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Nov 2007 20:00:21 +0530
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AC285.7070602@odu.neva.ru>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>	<474AB810.5070305@odu.neva.ru>	<474AB82E.3060303@fedoraproject.org>
	<474AC285.7070602@odu.neva.ru>
Message-ID: <474AD87D.7040801@fedoraproject.org>

Dmitry Butskoy wrote:
> 
> Not exactly. Old releases of Red Hat Linux was supported much more time 
> rather than Fedora now.

Release cycle is different from updates cycle and IIRC the last couple 
of releases of Red Hat Linux wasn't supported much longer. Anyway the 
point is that ~ 6 month release cycle was adopted from Red Hat Linux.

>> Answer lies in rest of the upstream software including GNOME which 
>> follow this release schedule 
> 
> BTW, what else significant besides GNOME?

Time based releases? Openoffice.org, Xorg, Linux kernel ...

> But it seems intrusive anyway, because the user is compelled to switch 
> to the new release fast enough...

You know it is going to a major decision compared to updates for a 
existing release. That visibility is important I think. There are other 
distributions that have been following a rolling release model. Source 
based: Gentoo.. Otherwise: Arch and a few others.

Rahul



From jkeating at redhat.com  Mon Nov 26 14:33:53 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Nov 2007 09:33:53 -0500
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AB82E.3060303@fedoraproject.org>
References: <20071123170139.629e9b64.blueser@gmail.com>
	<47473996.7030002@marquesminen.com.ar>
	<474AB810.5070305@odu.neva.ru> <474AB82E.3060303@fedoraproject.org>
Message-ID: <20071126093353.4c5cd77a@redhat.com>

On Mon, 26 Nov 2007 17:42:30 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> Answer lies in rest of the upstream software including GNOME which 
> follow this release schedule

From what I've been told, GNOME got into the habbit of a 6 month cycle
because they wanted to be included in the next Red Hat Linux release,
which had a 6 month cycle....

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/d881ba6c/attachment.sig>

From sundaram at fedoraproject.org  Mon Nov 26 14:40:27 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Nov 2007 20:10:27 +0530
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <20071126093353.4c5cd77a@redhat.com>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>	<474AB810.5070305@odu.neva.ru>
	<474AB82E.3060303@fedoraproject.org>
	<20071126093353.4c5cd77a@redhat.com>
Message-ID: <474ADADB.8040409@fedoraproject.org>

Jesse Keating wrote:
> On Mon, 26 Nov 2007 17:42:30 +0530
> Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> 
>> Answer lies in rest of the upstream software including GNOME which 
>> follow this release schedule
> 
> From what I've been told, GNOME got into the habbit of a 6 month cycle
> because they wanted to be included in the next Red Hat Linux release,
> which had a 6 month cycle....

Kind of. Havoc mentioned what happened at

http://osdir.com/ml/redhat.fedora.advisory-board/2006-12/msg00093.html

Rahul



From martin.sourada at seznam.cz  Mon Nov 26 14:44:02 2007
From: martin.sourada at seznam.cz (Martin Sourada)
Date: Mon, 26 Nov 2007 15:44:02 +0100
Subject: Firefox sets wrong encoding to directory listings?
In-Reply-To: <m3prxx8atq.fsf@ursa.amorsen.dk>
References: <2446.3009-22798-1331156943-1196028540@seznam.cz>
	<20071126094739.71b6636e@dhcp03.addix.net>
	<1196070962.3048.17.camel@pc-notebook.kolej.mff.cuni.cz>
	<m3prxx8atq.fsf@ursa.amorsen.dk>
Message-ID: <1196088242.3048.21.camel@pc-notebook.kolej.mff.cuni.cz>

On Mon, 2007-11-26 at 13:12 +0100, Benny Amorsen wrote:
> >>>>> "MS" == Martin Sourada <martin.sourada at seznam.cz> writes:
> 
> MS> Didn't know that. Then I wonder, why clients defaults to
> MS> ISO-8859-1, while most of the today's filesystems use UTF-8...
> 
> HTTP clients generally do as they are told (except for IE, but that's
> another rant). Apache tells them ISO-8859-1 in your case, so that's
> what they display.
> 
Well, I was talking rather about ftp clients in this very paragraph.

> Have you tried IndexOptions Charset=UTF-8?
> 
Thanks, that fixes the problem :)

> 
> /Benny
> 
> 

Martin



From tcallawa at redhat.com  Mon Nov 26 14:51:34 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 26 Nov 2007 09:51:34 -0500
Subject: [Long] Do we need a font SIG ?
In-Reply-To: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org>
References: <6148.192.54.193.51.1189770715.squirrel@rousalka.dyndns.org>
Message-ID: <1196088694.15604.29.camel@localhost.localdomain>


On Fri, 2007-09-14 at 13:51 +0200, Nicolas Mailhot wrote:
> 7. The font situation is bad enough we have a font exception to our
> FLOSS rules
> http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac
> [for example we ship Luxi even though its licensing forbids
> modification, making it non-free
> http://www.xfree86.org/current/LICENSE11.html]

Open a bug report. Let's start the process of having it removed in F9.

> 8. There are efforts to drain the font licensing swamp and promote
> FLOSS fonts (http://unifont.org/go_for_ofl/), they are aligned with
> Fedora general objectives yet Fedora has totally ignored them so far
> (cf Liberation licensing choices)

Keep in mind that Liberation licensing was a Red Hat, Inc decision, not
a Fedora decision. 

Also, we haven't totally ignored the OFL, since it is listed as the
"preferred" font license on the Fedora licensing page:
http://fedoraproject.org/wiki/Licensing/Fonts

~spot



From mmahut at fedoraproject.org  Mon Nov 26 14:52:19 2007
From: mmahut at fedoraproject.org (Marek Mahut)
Date: Mon, 26 Nov 2007 15:52:19 +0100
Subject: Fedora Astronomy SIG (Was: Re: Fedora Astronomy spin)
In-Reply-To: <4736DDA3.6070101@fedoraproject.org>
References: <4736DDA3.6070101@fedoraproject.org>
Message-ID: <474ADDA3.7070802@fedoraproject.org>

Hello all,

Let me introduce you Fedora Astronomy SIG. We're a group of people
interested to improve support for astronomers and astrophysicists on Fedora.

   http://fedoraproject.org/wiki/SIGs/Astronomy

Feel free to join!

Marek Mahut wrote:
> Hello Fedora developers,
> 
> I want to build a Fedora spin for astronomers and astrophysicists. In
> first place, I've proposed it as Feature, but now that already 3 people
> want to help this project, I think about special Astronomy SIG which
> will be responsible for this spin and other astronomy packages. The
> second argument for this is that fesco isn't sure if spins should be
> considered as features.
> 
>    http://fedoraproject.org/wiki/Features/FedoraAstronomy
> 
> If you are interested to join and help us, please add your name to the
> wiki under section "interested people".
> 
>    Thank you!
> 


-- 
Marek Mahut                           http://www.fedoraproject.org/
Fedora Project                              http://www.jamendo.com/



From jwboyer at gmail.com  Mon Nov 26 14:54:05 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 26 Nov 2007 08:54:05 -0600
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AD87D.7040801@fedoraproject.org>
References: <20071123170139.629e9b64.blueser@gmail.com>
	<47473996.7030002@marquesminen.com.ar>
	<474AB810.5070305@odu.neva.ru> <474AB82E.3060303@fedoraproject.org>
	<474AC285.7070602@odu.neva.ru> <474AD87D.7040801@fedoraproject.org>
Message-ID: <20071126085405.6ea5547f@weaponx>

On Mon, 26 Nov 2007 20:00:21 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> Dmitry Butskoy wrote:
> > 
> > Not exactly. Old releases of Red Hat Linux was supported much more time 
> > rather than Fedora now.
> 
> Release cycle is different from updates cycle and IIRC the last couple 
> of releases of Red Hat Linux wasn't supported much longer. Anyway the 
> point is that ~ 6 month release cycle was adopted from Red Hat Linux.
> 
> >> Answer lies in rest of the upstream software including GNOME which 
> >> follow this release schedule 
> > 
> > BTW, what else significant besides GNOME?
> 
> Time based releases? Openoffice.org, Xorg, Linux kernel ...

The kernel doesn't exactly have a time based release.  It's fairly
predictable as to when the next one will happen, but it doesn't follow
an explicit timeline.

josh



From ajackson at redhat.com  Mon Nov 26 15:33:39 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 26 Nov 2007 10:33:39 -0500
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196006076.5828.30.camel@pc-notebook>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
Message-ID: <1196091219.22277.12.camel@localhost.localdomain>

On Sun, 2007-11-25 at 16:54 +0100, Martin Sourada wrote:

> system-config-display-1.0.51-4.fc8
> firstboot-1.4.39-1.fc8
>   imho these two should not require metacity

s-c-d requires metacity because it requires a window manager for the
case where it launches its own X server, and metacity is the standard
gtk window manager.  Likewise, firstboot modules may create their own X
windows, and you need a window manager around to get the focus right.

We could depend on gnome-wm instead, but that isn't likely to make
anyone happier than just requiring metacity.  Or we could require miniwm
from anaconda, which isn't actually a terrible idea, but you'd have to
change the anaconda packaging first because you probably don't want to
drag in all of anaconda at runtime.

- ajax



From nicolas.mailhot at laposte.net  Mon Nov 26 15:09:05 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 26 Nov 2007 16:09:05 +0100 (CET)
Subject: [Long] Do we need a font SIG ?
Message-ID: <17874.192.54.193.53.1196089745.squirrel@rousalka.dyndns.org>


Le Lun 26 novembre 2007 15:51, Tom \"spot\" Callaway a ?crit :
>
> On Fri, 2007-09-14 at 13:51 +0200, Nicolas Mailhot wrote:
>> 7. The font situation is bad enough we have a font exception to our
>> FLOSS rules
>> http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac
>> [for example we ship Luxi even though its licensing forbids
>> modification, making it non-free
>> http://www.xfree86.org/current/LICENSE11.html]
>
> Open a bug report. Let's start the process of having it removed in F9.

https://bugzilla.redhat.com/show_bug.cgi?id=317641

>> 8. There are efforts to drain the font licensing swamp and promote
>> FLOSS fonts (http://unifont.org/go_for_ofl/), they are aligned with
>> Fedora general objectives yet Fedora has totally ignored them so far
>> (cf Liberation licensing choices)
>
> Keep in mind that Liberation licensing was a Red Hat, Inc decision,
> not
> a Fedora decision.
>
> Also, we haven't totally ignored the OFL, since it is listed as the
> "preferred" font license on the Fedora licensing page:
> http://fedoraproject.org/wiki/Licensing/Fonts

Wasn't the case when I wrote this :p

Many thanks,

-- 
Nicolas Mailhot



From sandeen at redhat.com  Mon Nov 26 15:17:33 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Mon, 26 Nov 2007 09:17:33 -0600
Subject: Disabling readahead
In-Reply-To: <20071126113203.M96422@all-the-johnsons.co.uk>
References: <20071126113203.M96422@all-the-johnsons.co.uk>
Message-ID: <474AE38D.30406@redhat.com>

Paul F. Johnson wrote:
> Hi,
> 
> I have readahead currently running on my test rig (x86_64, rawhide), but it's
> currently giving me all sorts of problems, so much so that the box is pretty
> unusable (random hangs abound and hugely varied times to getting the desktop
> to boot - I've tried to file BZ reports, but the machine dies before I can).
>
> I've read that readahead is currently broken in rawhide. Normally, my machine
> boots directly to runlevel 5. Can I alter on the kernel boot line for it jump
> to level 3? I can then disable the readahead service.


I'd honestly be surprised if the readahead scripts are the culprit - how
did you identify readahead as the problem?  The "brokenness" is really
mostly about inefficiency, as far as I know.

...but anyway, just boot into single-user mode (append "single" to the
boot commandline) or use interactive mode as others have suggested, to
chkconfig it off.

-Eric



From katzj at redhat.com  Mon Nov 26 15:18:18 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 26 Nov 2007 10:18:18 -0500
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196091219.22277.12.camel@localhost.localdomain>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<1196091219.22277.12.camel@localhost.localdomain>
Message-ID: <1196090298.3328.31.camel@localhost.localdomain>

On Mon, 2007-11-26 at 10:33 -0500, Adam Jackson wrote:
> We could depend on gnome-wm instead, but that isn't likely to make
> anyone happier than just requiring metacity.  Or we could require miniwm
> from anaconda, which isn't actually a terrible idea, but you'd have to
> change the anaconda packaging first because you probably don't want to
> drag in all of anaconda at runtime.

Only if someone else is willing to own mini-wm :-)  It has some ...
"interesting" focus behaviors from time to time.  With only one app
running, the effect is minimized but they still pop up from time to time
and lead to some fun.

Jeremy



From katzj at redhat.com  Mon Nov 26 15:27:30 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 26 Nov 2007 10:27:30 -0500
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
In-Reply-To: <474AD017.7050808@odu.neva.ru>
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
	<474ABA11.3090305@odu.neva.ru> <20071126133842.GB2631@free.fr>
	<474AD017.7050808@odu.neva.ru>
Message-ID: <1196090850.3328.36.camel@localhost.localdomain>

On Mon, 2007-11-26 at 16:54 +0300, Dmitry Butskoy wrote:
> Patrice Dumas wrote:
> > On Mon, Nov 26, 2007 at 03:20:33PM +0300, Dmitry Butskoy wrote:
> >>
> >> Maybe just check in %post and %postun whether the "semodule" binary is 
> >> present (i.e., "[ -x /usr/sbin/semodule ] && ....")?  Or use %triggerin for 
> >> policycoreutils...
> >>     
> >
> > %triggerin should really be avoided.
> 
> But if the user will decide to use SELinux (install all needed packages) 
> later? Then it should re-install pam_ssh to activate its policies...

This is one of the (many) reasons why it's currently better to get
policy into the main selinux-policy package rather than trying to do
hacks to carry policy in the package.

It'd be really nice if we could get to where policy was able to be
cleanly carried within packages :-/

Jeremy



From mschwendt.tmp0701.nospam at arcor.de  Mon Nov 26 15:42:02 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 26 Nov 2007 16:42:02 +0100
Subject: PROJECT BLACKHAT
In-Reply-To: <474ACCE5.60508@mharris.ca>
References: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>
	<474ACCE5.60508@mharris.ca>
Message-ID: <20071126164202.f2942a86.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 26 Nov 2007 08:40:53 -0500, Mike A. Harris wrote:

> You could still keep a similar theme of "$color $something", just don't 
> use "Red" or "Hat" or any other word that means "hat" or is a type of 
> hat, and you're probably ok.  In the past, there have been "Blue Sky 
> Linux", "Green Frog Linux", "Yellowdog Linux", "Black Flag Linux", "Pink 
> Tie Linux", and "White Box Linux" that I'm aware of, and probably a 
> number of others as well.  As far as I recall those names were all ok, 
> although as I said above, IANAL.  ;o)

"Red Flag Linux" is available, too. ;)

http://www.redflag-linux.com/eindex.html



From ajackson at redhat.com  Mon Nov 26 16:16:15 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 26 Nov 2007 11:16:15 -0500
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196090298.3328.31.camel@localhost.localdomain>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<1196091219.22277.12.camel@localhost.localdomain>
	<1196090298.3328.31.camel@localhost.localdomain>
Message-ID: <1196093775.22277.23.camel@localhost.localdomain>

On Mon, 2007-11-26 at 10:18 -0500, Jeremy Katz wrote:
> On Mon, 2007-11-26 at 10:33 -0500, Adam Jackson wrote:
> > We could depend on gnome-wm instead, but that isn't likely to make
> > anyone happier than just requiring metacity.  Or we could require miniwm
> > from anaconda, which isn't actually a terrible idea, but you'd have to
> > change the anaconda packaging first because you probably don't want to
> > drag in all of anaconda at runtime.
> 
> Only if someone else is willing to own mini-wm :-)  It has some ...
> "interesting" focus behaviors from time to time.  With only one app
> running, the effect is minimized but they still pop up from time to time
> and lead to some fun.

I don't have strong feelings one way or the other.  If it were up to me
metacity would simply be non-optional for Fedora.

But if you wanted to subpackage mini-wm and fix firstboot, I'd fix s-c-d
and occasionally look at the bugs for the subpackage.  And I'm happy to
tell people that it's not a real wm.

- ajax



From ncorrare at fedoraproject.org  Mon Nov 26 15:50:38 2007
From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello)
Date: Mon, 26 Nov 2007 12:50:38 -0300
Subject: PROJECT BLACKHAT
In-Reply-To: <20071126164202.f2942a86.mschwendt.tmp0701.nospam@arcor.de>
References: <BAY111-W22656D83464F3E44C643A2A6750@phx.gbl>	<474ACCE5.60508@mharris.ca>
	<20071126164202.f2942a86.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <474AEB4E.6060306@fedoraproject.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Once someone called me asking for support on a computer they've bought
with Red Flag, (I do work at Red Hat).
Michael Schwendt wrote:
> On Mon, 26 Nov 2007 08:40:53 -0500, Mike A. Harris wrote:
> 
>> You could still keep a similar theme of "$color $something", just don't 
>> use "Red" or "Hat" or any other word that means "hat" or is a type of 
>> hat, and you're probably ok.  In the past, there have been "Blue Sky 
>> Linux", "Green Frog Linux", "Yellowdog Linux", "Black Flag Linux", "Pink 
>> Tie Linux", and "White Box Linux" that I'm aware of, and probably a 
>> number of others as well.  As far as I recall those names were all ok, 
>> although as I said above, IANAL.  ;o)
> 
> "Red Flag Linux" is available, too. ;)
> 
> http://www.redflag-linux.com/eindex.html
> 


- --
- - --
Nicolas A. Corrarello
Fedora Ambassador Argentina 	   c: +54 (911) 5182-2245
		                   e: ncorrare at fedoraproject.org
GPG Key: DFC893EE                  h:
fedoraproject.org/wiki/NicolasCorrarello/
GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B  7F8C E145 B2F9 DFC8 93EE
Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHSutO4UWy+d/Ik+4RAr4TAJ9KY1gU5PkC1W7pt0fToex+bjokaACggdFr
JEGf/aDWX+yFATOGyE11Acs=
=O3UC
-----END PGP SIGNATURE-----



From martin at marquesminen.com.ar  Mon Nov 26 15:58:08 2007
From: martin at marquesminen.com.ar (Martin Marques)
Date: Mon, 26 Nov 2007 12:58:08 -0300
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <20071126093353.4c5cd77a@redhat.com>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>	<474AB810.5070305@odu.neva.ru>
	<474AB82E.3060303@fedoraproject.org>
	<20071126093353.4c5cd77a@redhat.com>
Message-ID: <474AED10.3050203@marquesminen.com.ar>

Jesse Keating escribi?:
> On Mon, 26 Nov 2007 17:42:30 +0530
> Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> 
>> Answer lies in rest of the upstream software including GNOME which 
>> follow this release schedule
> 
> From what I've been told, GNOME got into the habbit of a 6 month cycle
> because they wanted to be included in the next Red Hat Linux release,
> which had a 6 month cycle....

Hey, which one is the egg? ;-)



From martin at marquesminen.com.ar  Mon Nov 26 16:00:31 2007
From: martin at marquesminen.com.ar (Martin Marques)
Date: Mon, 26 Nov 2007 13:00:31 -0300
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <20071126085405.6ea5547f@weaponx>
References: <20071123170139.629e9b64.blueser@gmail.com>	<47473996.7030002@marquesminen.com.ar>	<474AB810.5070305@odu.neva.ru>
	<474AB82E.3060303@fedoraproject.org>	<474AC285.7070602@odu.neva.ru>
	<474AD87D.7040801@fedoraproject.org>
	<20071126085405.6ea5547f@weaponx>
Message-ID: <474AED9F.3030901@marquesminen.com.ar>

Josh Boyer escribi?:
> 
> The kernel doesn't exactly have a time based release.  It's fairly
> predictable as to when the next one will happen, but it doesn't follow
> an explicit timeline.

Also, Fedora includes different kernel version is the same release, so 
releases of Fedora are not because of kernel releases.



From dcbw at redhat.com  Mon Nov 26 15:58:20 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Nov 2007 10:58:20 -0500
Subject: NetworkManager-umts
In-Reply-To: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
Message-ID: <1196092700.4202.40.camel@localhost.localdomain>

On Sun, 2007-11-25 at 12:35 +0100, Rudolf Kastl wrote:
> Hello!
> 
> Actually after beeing asked to bring the topic to the wiki:
> 
> http://fedoraproject.org/wiki/Features/NetworkManager-umts#preview
> 
> Feel free to add more informations and ideas to the entry.

Will do; Tambet Ingo is about to land the basic serial and cellular
broadband support in SVN, hopefully this week.  It's GSM/UMTS only right
now, but it looks like that code is easily tweaked to handle CDMA
broadband cards as well since they are vastly simpler to interact with
than GSM cards.

Dan




From che666 at gmail.com  Mon Nov 26 16:19:29 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 26 Nov 2007 16:19:29 +0000
Subject: NetworkManager-umts
In-Reply-To: <1196092700.4202.40.camel@localhost.localdomain>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
Message-ID: <e99d27470711260819i4dbe52cwe93546fdecbd01af@mail.gmail.com>

On Nov 26, 2007 3:58 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Sun, 2007-11-25 at 12:35 +0100, Rudolf Kastl wrote:
> > Hello!
> >
> > Actually after beeing asked to bring the topic to the wiki:
> >
> > http://fedoraproject.org/wiki/Features/NetworkManager-umts#preview
> >
> > Feel free to add more informations and ideas to the entry.
>
> Will do; Tambet Ingo is about to land the basic serial and cellular
> broadband support in SVN, hopefully this week.  It's GSM/UMTS only right
> now, but it looks like that code is easily tweaked to handle CDMA
> broadband cards as well since they are vastly simpler to interact with
> than GSM cards.

Awesome!

kind regards,
Rudolf Kastl

p.s. offering testing helping documenting and translations to german
etc... just drop me a mail ;)
>
> Dan
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jon.nettleton at gmail.com  Mon Nov 26 16:39:49 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Mon, 26 Nov 2007 11:39:49 -0500
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196093775.22277.23.camel@localhost.localdomain>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<1196091219.22277.12.camel@localhost.localdomain>
	<1196090298.3328.31.camel@localhost.localdomain>
	<1196093775.22277.23.camel@localhost.localdomain>
Message-ID: <1196095189.2471.2.camel@birkoff.charles.net>

On Mon, 2007-11-26 at 11:16 -0500, Adam Jackson wrote:
> On Mon, 2007-11-26 at 10:18 -0500, Jeremy Katz wrote:
> > On Mon, 2007-11-26 at 10:33 -0500, Adam Jackson wrote:
> > > We could depend on gnome-wm instead, but that isn't likely to make
> > > anyone happier than just requiring metacity.  Or we could require miniwm
> > > from anaconda, which isn't actually a terrible idea, but you'd have to
> > > change the anaconda packaging first because you probably don't want to
> > > drag in all of anaconda at runtime.
> > 
> > Only if someone else is willing to own mini-wm :-)  It has some ...
> > "interesting" focus behaviors from time to time.  With only one app
> > running, the effect is minimized but they still pop up from time to time
> > and lead to some fun.
> 
> I don't have strong feelings one way or the other.  If it were up to me
> metacity would simply be non-optional for Fedora.
> 
> But if you wanted to subpackage mini-wm and fix firstboot, I'd fix s-c-d
> and occasionally look at the bugs for the subpackage.  And I'm happy to
> tell people that it's not a real wm.

Why not use matchbox-window-manager?  It is already in koji for use in
olpc and works great for full-screen single windows.

Jon



From bruno at wolff.to  Mon Nov 26 17:13:34 2007
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 26 Nov 2007 11:13:34 -0600
Subject: Bug #372011 (or: how we could help with anaconda beta tests)
In-Reply-To: <474AED9F.3030901@marquesminen.com.ar>
References: <20071123170139.629e9b64.blueser@gmail.com>
	<47473996.7030002@marquesminen.com.ar>
	<474AB810.5070305@odu.neva.ru> <474AB82E.3060303@fedoraproject.org>
	<474AC285.7070602@odu.neva.ru> <474AD87D.7040801@fedoraproject.org>
	<20071126085405.6ea5547f@weaponx>
	<474AED9F.3030901@marquesminen.com.ar>
Message-ID: <20071126171334.GB11264@wolff.to>

On Mon, Nov 26, 2007 at 13:00:31 -0300,
  Martin Marques <martin at marquesminen.com.ar> wrote:
> Josh Boyer escribi?:
> >
> >The kernel doesn't exactly have a time based release.  It's fairly
> >predictable as to when the next one will happen, but it doesn't follow
> >an explicit timeline.
> 
> Also, Fedora includes different kernel version is the same release, so 
> releases of Fedora are not because of kernel releases.

That isn't exactly true. For example the libata change was held off until
a new release of Fedora.



From aph at redhat.com  Mon Nov 26 17:27:21 2007
From: aph at redhat.com (Andrew Haley)
Date: Mon, 26 Nov 2007 17:27:21 +0000
Subject: Debuginfo packages for Java
In-Reply-To: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>
References: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>
Message-ID: <18251.505.97087.501361@zebedee.pink>

Jason L Tibbitts III writes:
 > I'm having problems reviewing a package for some software written in
 > Java.  The problem is that the debuginfo package is generated without
 > any source.  find-debuginfo.sh prints out the following:
 > 
 > extracting debug info from /var/tmp/writer2latex-0.5-buildroot/usr/lib64/gcj/writer2latex/writer2latex-0.5.jar.so
 > cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex-0.5.jar.1.jar: Cannot stat: No such file or directory
 > cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex/Application.java: Cannot stat: No such file or directory
 > cpio: writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex/writer2latex/api/BatchConverter.java: Cannot stat: No such file or directory
 > 
 > Needless to say, the source isn't actually buried under
 > writer2latex05/aot-compile-rpm/usr/lib64/gcj/writer2latex.

The fix is to change /usr/lib/python2.5/site-packages/aotcompile.py,
which doesn't put the right pathnames into the object files.

I've attached a patch.  gbenson, please look this over.  This is my
first ever Python hack, so You Have Been Warned.  Input about my
(doubtless execrable) Python style welcome.

I have tested this patch on writer2latex, and I can debug it:


(gdb) b 'writer2latex.Application.main(java.lang.String[])void'
Function "writer2latex.Application.main(java.lang.String[])void" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

(gdb) r -jar /usr/share/java/writer2latex.jar
Starting program: /usr/bin/gij -jar /usr/share/java/writer2latex.jar

...

Breakpoint 1, writer2latex.Application.main(java.lang.String[])void (
    args=@2aaaaaafcf40)
    at /usr/src/debug/writer2latex05/source/writer2latex/Application.java:110
110                 Application app = new Application();
(gdb) n
111                 app.parseCommandLine(args);
(gdb) s
writer2latex.Application.parseCommandLine(java.lang.String[])void (
    this=@2aaaaf891e60, sArgs=@2aaaaaafcf40)
    at /usr/src/debug/writer2latex05/source/writer2latex/Application.java:466
466                 if (sArg.startsWith("-")) { // found an option
(gdb) 
471                     else if ("-xhtml+mathml+xsl".equals(sArg)) { sTargetMIME = MIMETypes.XHTML_MATHML_XSL; }
(gdb) 
466                 if (sArg.startsWith("-")) { // found an option
(gdb) 
471                     else if ("-xhtml+mathml+xsl".equals(sArg)) { sTargetMIME = MIMETypes.XHTML_MATHML_XSL; }
(gdb) 
464             while (i<sArgs.length) {
(gdb) 
506             if (sSource==null) {
(gdb) 


Andrew.


--- aotcompile.py	2006-09-07 22:59:16.000000000 +0100
+++ aotcompile.py.new	2007-11-26 16:57:28.000000000 +0000
@@ -21,6 +21,7 @@
 import sys
 import cStringIO as StringIO
 import zipfile
+import tempfile
 
 PATHS = {"make":   "/usr/bin/make",
          "gcj":    "/usr/bin/gcj",
@@ -85,6 +86,9 @@
         self.ldflags = copy.copy(LDFLAGS)
         self.makeflags = copy.copy(MAKEFLAGS)
         self.exclusions = []
+        self.filenames = tempfile.mkstemp()
+        self.gcjflags += ["-fsource-filename=" + self.filenames[1]]
+        os.system("/usr/bin/find `pwd` -type f > " + self.filenames[1])
 
     def compile(self):
         """Search srcdir for classes and jarfiles, then generate
@@ -104,6 +108,7 @@
             os.unlink(MAKEFILE)
         finally:
             os.chdir(oldcwd)
+            os.unlink(self.filenames[1])
 
     def getJobList(self):
         """Return all jarfiles and class collections in srcdir."""

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From ajackson at redhat.com  Mon Nov 26 18:00:52 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Mon, 26 Nov 2007 13:00:52 -0500
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196095189.2471.2.camel@birkoff.charles.net>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<1196091219.22277.12.camel@localhost.localdomain>
	<1196090298.3328.31.camel@localhost.localdomain>
	<1196093775.22277.23.camel@localhost.localdomain>
	<1196095189.2471.2.camel@birkoff.charles.net>
Message-ID: <1196100052.22277.27.camel@localhost.localdomain>

On Mon, 2007-11-26 at 11:39 -0500, Jon Nettleton wrote:
> On Mon, 2007-11-26 at 11:16 -0500, Adam Jackson wrote:
> > On Mon, 2007-11-26 at 10:18 -0500, Jeremy Katz wrote:
> > > On Mon, 2007-11-26 at 10:33 -0500, Adam Jackson wrote:
> > > > We could depend on gnome-wm instead, but that isn't likely to make
> > > > anyone happier than just requiring metacity.  Or we could require miniwm
> > > > from anaconda, which isn't actually a terrible idea, but you'd have to
> > > > change the anaconda packaging first because you probably don't want to
> > > > drag in all of anaconda at runtime.
> > > 
> > > Only if someone else is willing to own mini-wm :-)  It has some ...
> > > "interesting" focus behaviors from time to time.  With only one app
> > > running, the effect is minimized but they still pop up from time to time
> > > and lead to some fun.
> > 
> > I don't have strong feelings one way or the other.  If it were up to me
> > metacity would simply be non-optional for Fedora.
> > 
> > But if you wanted to subpackage mini-wm and fix firstboot, I'd fix s-c-d
> > and occasionally look at the bugs for the subpackage.  And I'm happy to
> > tell people that it's not a real wm.
> 
> Why not use matchbox-window-manager?  It is already in koji for use in
> olpc and works great for full-screen single windows.

It seems to not exist in the F-8 or devel branches in cvs?  Weird.  (It
exists, there's just no specfile.)

If we do that I'd prefer to see matchbox used in anaconda as well and
mini-wm destroyed entirely.  The fewer window managers the better, and
the less code in anaconda proper the better.

- ajax



From jon.nettleton at gmail.com  Mon Nov 26 17:47:41 2007
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Mon, 26 Nov 2007 12:47:41 -0500
Subject: New dependency in Fedora 8 - metacity
In-Reply-To: <1196100052.22277.27.camel@localhost.localdomain>
References: <adf480660711250734v6c215444x2fa79940aca65a19@mail.gmail.com>
	<1196006076.5828.30.camel@pc-notebook>
	<1196091219.22277.12.camel@localhost.localdomain>
	<1196090298.3328.31.camel@localhost.localdomain>
	<1196093775.22277.23.camel@localhost.localdomain>
	<1196095189.2471.2.camel@birkoff.charles.net>
	<1196100052.22277.27.camel@localhost.localdomain>
Message-ID: <1196099261.2471.8.camel@birkoff.charles.net>

On Mon, 2007-11-26 at 13:00 -0500, Adam Jackson wrote:
> On Mon, 2007-11-26 at 11:39 -0500, Jon Nettleton wrote:
> > On Mon, 2007-11-26 at 11:16 -0500, Adam Jackson wrote:
> > > On Mon, 2007-11-26 at 10:18 -0500, Jeremy Katz wrote:
> > > > On Mon, 2007-11-26 at 10:33 -0500, Adam Jackson wrote:
> > > > > We could depend on gnome-wm instead, but that isn't likely to make
> > > > > anyone happier than just requiring metacity.  Or we could require miniwm
> > > > > from anaconda, which isn't actually a terrible idea, but you'd have to
> > > > > change the anaconda packaging first because you probably don't want to
> > > > > drag in all of anaconda at runtime.
> > > > 
> > > > Only if someone else is willing to own mini-wm :-)  It has some ...
> > > > "interesting" focus behaviors from time to time.  With only one app
> > > > running, the effect is minimized but they still pop up from time to time
> > > > and lead to some fun.
> > > 
> > > I don't have strong feelings one way or the other.  If it were up to me
> > > metacity would simply be non-optional for Fedora.
> > > 
> > > But if you wanted to subpackage mini-wm and fix firstboot, I'd fix s-c-d
> > > and occasionally look at the bugs for the subpackage.  And I'm happy to
> > > tell people that it's not a real wm.
> > 
> > Why not use matchbox-window-manager?  It is already in koji for use in
> > olpc and works great for full-screen single windows.
> 
> It seems to not exist in the F-8 or devel branches in cvs?  Weird.  (It
> exists, there's just no specfile.)
> 
> If we do that I'd prefer to see matchbox used in anaconda as well and
> mini-wm destroyed entirely.  The fewer window managers the better, and
> the less code in anaconda proper the better.
> 

That all sounds perfect to me.  

Matchbox-Window-Manager

* for installs and standalone X apps. I also have a Fedora Tablet spin I
put together for a client's Samsung Q1 that uses this ;-)  

Metacity

* maybe with new non OpenGL composite support back in it?

Compiz-Fusion

*For people that like to play with their windows instead of doing work.

KDE???  I have no idea.

Jon



From janina at rednote.net  Mon Nov 26 18:02:00 2007
From: janina at rednote.net (Janina Sajka)
Date: Mon, 26 Nov 2007 13:02:00 -0500
Subject: Low-Vision Fonts GPL'd--Can we consider for F-9?
Message-ID: <20071126180200.GI22661@rednote.net>

This is a heads up and RFE. PerhapsGnome is the appropriate path to
introduce this specialized font--but perhaps F-9 might simply want to
take it up directly?

Fedora has actually been a good Linux choice for low-vision users. Blue
Curve provided good readibility and contrast. However, the font referred
to below takes support of people with impaired vision considerably
further, so it's great to see this major blindness agency releasing
their work under GPL.

ere's the forwarded message ..

Peter Korn writes:
> Hi gang,
> 
> I just received word (see attached) that the Tiresias family of fonts, 
> designed by the Royal National Institute for the Blind for clarity and 
> ease of recognition by folks with vision impairments are now available 
> under GPL v3.  The family includes fonts recommended and tested for use 
> in signage, print, television, and computer use (the latter is "PCFont" 
> - see http://www.tiresias.org/fonts/pcfont/about_pc.htm for details). 
> 
> I would like to recommend we consider redistributing these fonts with 
> GNOME (or at least link to them so that UNIX distros that include GNOME 
> might become aware of and potentially include this font).
> 
> 
> Regards,
> 
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.

> From: "Carter, Katherine" <Katherine.Carter at rnib.org.uk>
> 
> Dear Colleague, 
> 
> Free downloads are now available for the Tiresias fonts (LPFont, PCFont,
> InfoFont, SignFont, KeyFont) from
> www.tiresias.org/fonts/fonts_download.htm
> 
> Work has continued on extending the list of standards which relate to
> accessibility of information and communication technology systems and on
> linking them to the committee responsible for each standard. Also, we
> now have a quarterly report on the current status of standards under
> development. The standards section is at www.tiresias.org/standards/
> 
> New and updated Guidelines
> Transport - Now covers air, rail, road and sea. This can be found at
> www.tiresias.org/guidelines/transport/
> 
> e-Voting - Now includes a new section on current voting practices for
> people with disabilities. This can found at
> www.tiresias.org/guidelines/e_voting.htm
> 
> Household appliances - This new guideline can be found at
> www.tiresias.org/guidelines/household_appliances.htm
> 
> Accessible tourism - These guidelines have been extensively revised and
> extended and can be found at
> www.tiresias.org/guidelines/accessible_tourism/
> 
> The website has been modified to make it easier to navigate with
> features such as "breadcrumbs". What else would make it easier for you
> to use?
> 
> Regards,
> 
> Dr John Gill OBE FIET
> Chief Scientist
> 
> Scientific Research Unit
> RNIB
> 105 Judd Street
> London
> WC1H 9NE
> 
> Tel +44 20 7391 2244
> 
> Web: www.tiresias.org 
> 
> 
> -- 
> DISCLAIMER:
> 
> NOTICE: The information contained in this email and any attachments is 
> confidential and may be privileged.  If you are not the intended 
> recipient you should not use, disclose, distribute or copy any of the 
> content of it or of any attachment; you are requested to notify the 
> sender immediately of your receipt of the email and then to delete it 
> and any attachments from your system.
> 
> RNIB endeavours to ensure that emails and any attachments generated by
> its staff are free from viruses or other contaminants.  However, it 
> cannot accept any responsibility for any  such which are transmitted.
> We therefore recommend you scan all attachments.
> 
> Please note that the statements and views expressed in this email and 
> any attachments are those of the author and do not necessarily represent
> those of RNIB.
> 
> RNIB Registered Charity Number: 226227
> 
> Website: http://www.rnib.org.uk
> 
> 
> 
> This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel at gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel


-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina at a11y.org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina at a11y.org	
Linux Foundation		http://a11y.org



From notting at redhat.com  Mon Nov 26 18:07:46 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Nov 2007 13:07:46 -0500
Subject: Support TV - Proposal for F9 - enhanced DVB capabilities
In-Reply-To: <4747DD82.20703@iinet.net.au>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<4747DD82.20703@iinet.net.au>
Message-ID: <20071126180746.GA15244@nostromo.devel.redhat.com>

David Timms (dtimms at iinet.net.au) said: 
> 1. auto detect / load of drivers:
> I would be great if the bootup process would detect that the user has a dvb 
> tuner card and load the driver(s) without intervention {even once}.
>
> Currently I can # modprobe dvb_bt8xx   to get the kernel driver loaded.
> This can be manually inserted into /etc/modprobe.conf , but with the 
> hal/udev packages, I assume it is possible for the detection of the card on 
> the pci bus during bootup to be the trigger to cause the module to be 
> loaded.

Assuming the driver is correctly written, it should happen automatically.
Failure to automatically load for any PCI/USB device is a driver bug.

Bill



From katzj at redhat.com  Mon Nov 26 18:22:27 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Mon, 26 Nov 2007 13:22:27 -0500
Subject: Reminder: Get Early Testing of Features
Message-ID: <1196101347.15904.5.camel@localhost.localdomain>

While it's still early, just a reminder that if you're working on a
feature for Fedora 9 and you are to a point at which you feel the
feature is "testable" and will give you useful feedback, please contact
rel-eng so that we can arrange to get a test spin[1] created and
advertised.  Note that this doesn't at all need to be "complete", but
you'll need to be able to describe what's changed and what sort of
testing feedback you're looking for.

Requests to rel-eng at fedoraproject.org and we'll go from there

Jeremy

[1] Probably a live image unless there's a reason why that isn't
sufficient for your testing needs.

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From poelstra at redhat.com  Mon Nov 26 18:02:31 2007
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 26 Nov 2007 10:02:31 -0800
Subject: Fedora Feature Process Rolls On
Message-ID: <474B0A37.1010803@redhat.com>

As we head into the third week since the release of Fedora 8 lots of great Fedora 9 features are already being proposed.  See http://fedoraproject.org/wiki/CategoryProposedFedora9

Starting at this week's FESCo meeting (Thursday, 2007-11-29) we will start the first round of feature reviews.  New features will be reviewed accepted until Feature Freeze (Tuesday, 2008-03-04).

FESCo met on 2007-11-15 to review the Feature process and make some minor changes
o The updated process is here: http://fedoraproject.org/wiki/Features/Policy
o All the discussion related to the changes is here: http://bpepple.fedorapeople.org/fesco/FESCo-2007-11-15.html
o Details of the changes made to the policy page from this discussion are below along with minor changes I added for clarity.

John


Changelog for http://fedoraproject.org/wiki/Features/Policy

o Substitute use of "Approved Feature" with "Accepted Feature"
  --As mclasen and f13 pointed out, we want to be in the business of 'accepting' new features into the release--not 'approving' them.
o Reduced Feature Page update requirements. The new requirements are:
 1. Updated at: 
    a. Alpha freeze
    b. Beta freeze
    c. every two weeks after beta freeze until ''final development'' freeze
 2. At final development freeze all feature pages should be at 100% completion, and if necessary, the feature page adjusted to reflect everything completed. 

o Clarified first qualification of a feature to read "consistent with the goals and policies of Fedora while within the laws governing the corporate entity sponsoring Fedora--Red Hat."

o Major vs. Major features--Enhancements
  --Discussion centered around tracking improvements in Fedora that are not captured in a feature page.  Instead of distinguishing between "major" and "minor" I have referred to undocumented features (not to be confused with bugs) as "enhancements" as suggested by someone in the meeting.
  --Enhancements will be added and reported in the Release Summary

o Clarified section on dropping features that are not complete
  --All features must be complete or in a testable state by "feature freeze"
  --Added guidance as to what "testable" means

o Mailing list usage
  --Reminders to developers about upcoming feature deadlines will be sent to fedora-devel-announce at redhat.com
  --Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on fedora-devel-list at redhat.com 

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From linville at redhat.com  Mon Nov 26 18:47:55 2007
From: linville at redhat.com (John W. Linville)
Date: Mon, 26 Nov 2007 13:47:55 -0500
Subject: NetworkManager-umts
In-Reply-To: <1196092700.4202.40.camel@localhost.localdomain>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
Message-ID: <20071126184755.GF5532@redhat.com>

On Mon, Nov 26, 2007 at 10:58:20AM -0500, Dan Williams wrote:

> now, but it looks like that code is easily tweaked to handle CDMA
> broadband cards as well since they are vastly simpler to interact with
> than GSM cards.

Really?  I thought they all just looked like modems?  No?

I use Verizon, so I've only dealt with the CDMA stuff on my phone
(over bluetooth and USB).  I have looked at the GSM howtos and I
thought they were basically the same.  I guess I do recall a few odd
AT commands that they needed...

Oh, well...just curious!

John
-- 
John W. Linville
linville at redhat.com



From tcallawa at redhat.com  Mon Nov 26 18:55:49 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 26 Nov 2007 13:55:49 -0500
Subject: Low-Vision Fonts GPL'd--Can we consider for F-9?
In-Reply-To: <20071126180200.GI22661@rednote.net>
References: <20071126180200.GI22661@rednote.net>
Message-ID: <1196103349.23626.4.camel@localhost.localdomain>


On Mon, 2007-11-26 at 13:02 -0500, Janina Sajka wrote:
> This is a heads up and RFE. PerhapsGnome is the appropriate path to
> introduce this specialized font--but perhaps F-9 might simply want to
> take it up directly?

Sure, why not? If gnome picks it up, we can always have it obsolete
this.

https://bugzilla.redhat.com/show_bug.cgi?id=399881

~spot




From nicolas.mailhot at laposte.net  Mon Nov 26 19:20:53 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 26 Nov 2007 20:20:53 +0100
Subject: Low-Vision Fonts GPL'd--Can we consider for F-9?
In-Reply-To: <1196103349.23626.4.camel@localhost.localdomain>
References: <20071126180200.GI22661@rednote.net>
	<1196103349.23626.4.camel@localhost.localdomain>
Message-ID: <1196104853.10740.4.camel@rousalka.dyndns.org>

Please CC the fonts list on fonts stuff

Le lundi 26 novembre 2007 ? 13:55 -0500, Tom "spot" Callaway a ?crit :
> On Mon, 2007-11-26 at 13:02 -0500, Janina Sajka wrote:
> > This is a heads up and RFE. PerhapsGnome is the appropriate path to
> > introduce this specialized font--but perhaps F-9 might simply want to
> > take it up directly?
> 
> Sure, why not? If gnome picks it up, we can always have it obsolete
> this.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=399881

Some quick comments (I'm knee-deep in my own packaging right now)
? upstream forgot the font embedding GPL exception. Not a blocker but
users will complain
? I'm not too fond of multisource spec files, separate packages are
usually more flexible and easier to maintain

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/e2d16038/attachment.sig>

From dcbw at redhat.com  Mon Nov 26 19:41:45 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Nov 2007 14:41:45 -0500
Subject: NetworkManager-umts
In-Reply-To: <20071126184755.GF5532@redhat.com>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
Message-ID: <1196106105.9720.3.camel@localhost.localdomain>

On Mon, 2007-11-26 at 13:47 -0500, John W. Linville wrote:
> On Mon, Nov 26, 2007 at 10:58:20AM -0500, Dan Williams wrote:
> 
> > now, but it looks like that code is easily tweaked to handle CDMA
> > broadband cards as well since they are vastly simpler to interact with
> > than GSM cards.
> 
> Really?  I thought they all just looked like modems?  No?
> 
> I use Verizon, so I've only dealt with the CDMA stuff on my phone
> (over bluetooth and USB).  I have looked at the GSM howtos and I
> thought they were basically the same.  I guess I do recall a few odd
> AT commands that they needed...
> 
> Oh, well...just curious!

It's basically AT commands that differ.  GSM has a standard for the AT
commands that is implemented (mostly) the same for all the GSM cards.
CDMA card's don't appear to be as standardized.

CDMA cards are much simpler to control though; since you don't need to
pick a network (roaming is controlled through whitelists called PRLs),
the dialup number is usually the same (#777, ie #PPP), and you usually
don't need a username and password (dummy values work fine since the
network authenticates you based on MEID or ESN, not user/pass).  You
also don't need to select what band you want to use since they
automatically pick the best available connectivity (whereas with GSM you
can sometimes pick between GSM/GPRS/EDGE and UMTS/HSPA).

Dan




From mr.ecik at gmail.com  Mon Nov 26 19:50:46 2007
From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=)
Date: Mon, 26 Nov 2007 20:50:46 +0100
Subject: Should "yum install" be case sensitive?
Message-ID: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>

Hi!
Recently, a funny thing happened on Polish Fedora forum. Some users
were talking about Miro but rest of them weren't able even to install
that... After some time it turned out that they tried to type "yum
install miro" instead of "yum install Miro".
So my question is the same as in the topic: should "yum install" be
case sensitive?
I haven't checked but I'm quite sure (correct me if I'm wrong) that
there are no packages in repo whose names differ in letter size.
What's more: "yum list" command is case insensitive and there's
nothing wrong with it, is there? I know that you can say that these
users I wrote about in the beginning should have used "yum list" first
and then they would have found out why things went wrong but it makes
a need to type more and more commands.
"yum install" gives a summary what packages are going to be installed
so if a user wanted to run "Foo", but not "foo" she/he could break the
installation.
Besides, pressing SHIFT key could be painful ;-)
So my proposal is to make "yum install" (and probably "yum update" as
well) case insensitive.
Just think about it :)

Regards.

-- 
Micha? Bentkowski
mr.ecik at gmail.com



From fedora at camperquake.de  Mon Nov 26 19:51:11 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Nov 2007 20:51:11 +0100
Subject: NetworkManager-umts
In-Reply-To: <1196106105.9720.3.camel@localhost.localdomain>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
Message-ID: <20071126205111.3a19be68@lain.camperquake.de>

Hi.

On Mon, 26 Nov 2007 14:41:45 -0500, Dan Williams wrote
> network authenticates you based on MEID or ESN, not user/pass).  You
> also don't need to select what band you want to use since they
> automatically pick the best available connectivity (whereas with GSM
> you can sometimes pick between GSM/GPRS/EDGE and UMTS/HSPA).

For the GSM/UMTS connections I have used this is quite similar (Germany,
T-Mobile network). The number you dial is *99#, username/password does
not matter.



From lordmorgul at gmail.com  Mon Nov 26 19:56:58 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Mon, 26 Nov 2007 11:56:58 -0800
Subject: Killing maintainers
In-Reply-To: <f224c6140709061402l63166813o2f1827a2b75e8e0b@mail.gmail.com>
References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com>	<20070905173132.655bc3ae@mentok.boston.redhat.com>
	<f224c6140709061402l63166813o2f1827a2b75e8e0b@mail.gmail.com>
Message-ID: <474B250A.1040509@gmail.com>

Michel Salim wrote:
> On 05/09/07, Jesse Keating <jkeating at redhat.com> wrote:
>> On Wed, 5 Sep 2007 22:26:24 +0100
>> "Jonathan Underwood" <jonathan.underwood at gmail.com> wrote:
>>
>>> What is the quickest way of getting this done? Which of the myriad
>>> committees does this need to go through?
>> I will be pushing this through FESCo tomorrow.
>>
> If the mailing list software allows the use of +FOO suffix, an
> alternative to mailing list proliferation is to have a main
> -devel-list (like now), with major subcategories suffixed at the end?
> 
> People can then filter and prioritize their list messages accordingly.
> 
> Cheers,
> 

A good point, but there are also 'topics' supported by mailman.  There are
currently no topics defined for any of the redhat lists I'm aware of, but they
could be.  The user interface (once logged in) allows everyone subscribed to
choose which topics to receive mailings and which to ignore, and that would
accomplish the goal and reduce the mail traffic on both ends.

If enough people really want to get rid of things like update announcements
coming in on one list, I would think creating a subtopic for the list might be a
good solution.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From ndbecker2 at gmail.com  Mon Nov 26 19:56:52 2007
From: ndbecker2 at gmail.com (Neal Becker)
Date: Mon, 26 Nov 2007 14:56:52 -0500
Subject: Anyone packaging gnu source-highlight?
Message-ID: <fif8e4$ho2$1@ger.gmane.org>

yum search doesn't show anything, anyone doing this or want to?
http://www.gnu.org/software/src-highlite/



From jkeating at redhat.com  Mon Nov 26 19:55:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Nov 2007 14:55:34 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
Message-ID: <20071126145534.7df4d8d3@redhat.com>

On Mon, 26 Nov 2007 20:50:46 +0100
"Micha? Bentkowski" <mr.ecik at gmail.com> wrote:

> Hi!
> Recently, a funny thing happened on Polish Fedora forum. Some users
> were talking about Miro but rest of them weren't able even to install
> that... After some time it turned out that they tried to type "yum
> install miro" instead of "yum install Miro".
> So my question is the same as in the topic: should "yum install" be
> case sensitive?
> I haven't checked but I'm quite sure (correct me if I'm wrong) that
> there are no packages in repo whose names differ in letter size.
> What's more: "yum list" command is case insensitive and there's
> nothing wrong with it, is there? I know that you can say that these
> users I wrote about in the beginning should have used "yum list" first
> and then they would have found out why things went wrong but it makes
> a need to type more and more commands.
> "yum install" gives a summary what packages are going to be installed
> so if a user wanted to run "Foo", but not "foo" she/he could break the
> installation.
> Besides, pressing SHIFT key could be painful ;-)
> So my proposal is to make "yum install" (and probably "yum update" as
> well) case insensitive.
> Just think about it :)

Search is case insensitive, list is a search.  However packages are
case sensitive.  While we don't /currently/ have a Miro and a miro, the
rpm database would allow for it, thus install/removal actions need to
be case sensitive.  We could try for some brutal packaging policy that
demands all package names be in lower case, but I doubt that would fly
very far.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/fce623c0/attachment.sig>

From jkeating at redhat.com  Mon Nov 26 19:56:51 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Nov 2007 14:56:51 -0500
Subject: Killing maintainers
In-Reply-To: <474B250A.1040509@gmail.com>
References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com>
	<20070905173132.655bc3ae@mentok.boston.redhat.com>
	<f224c6140709061402l63166813o2f1827a2b75e8e0b@mail.gmail.com>
	<474B250A.1040509@gmail.com>
Message-ID: <20071126145651.7527971a@redhat.com>

On Mon, 26 Nov 2007 11:56:58 -0800
Andrew Farris <lordmorgul at gmail.com> wrote:

> A good point, but there are also 'topics' supported by mailman.
> There are currently no topics defined for any of the redhat lists I'm
> aware of, but they could be.  The user interface (once logged in)
> allows everyone subscribed to choose which topics to receive mailings
> and which to ignore, and that would accomplish the goal and reduce
> the mail traffic on both ends.
> 
> If enough people really want to get rid of things like update
> announcements coming in on one list, I would think creating a
> subtopic for the list might be a good solution.

fedora-package-announce uses topics for each fedora release, so people
can choose to only get announcements about the release they are using.
Off and on I was working on a regex that would work to add a topic for
the test releases as well, but I haven't got that done yet.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/46943398/attachment.sig>

From fedora at camperquake.de  Mon Nov 26 20:03:13 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Nov 2007 21:03:13 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126145534.7df4d8d3@redhat.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
Message-ID: <20071126210313.28ca9ca2@lain.camperquake.de>

Hi.

On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote

> Search is case insensitive, list is a search.  However packages are
> case sensitive.  While we don't /currently/ have a Miro and a miro,
> the rpm database would allow for it, thus install/removal actions
> need to be case sensitive.

How about "try case sensitive first, and insensitive if the first does
not turn up anything"?



From lordmorgul at gmail.com  Mon Nov 26 20:10:35 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Mon, 26 Nov 2007 12:10:35 -0800
Subject: Should "yum install" be case sensitive?
In-Reply-To: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
Message-ID: <474B283B.5080603@gmail.com>

Micha? Bentkowski wrote:
> Hi!
> Recently, a funny thing happened on Polish Fedora forum. Some users
> were talking about Miro but rest of them weren't able even to install
> that... After some time it turned out that they tried to type "yum
> install miro" instead of "yum install Miro".
> So my question is the same as in the topic: should "yum install" be
> case sensitive?
> I haven't checked but I'm quite sure (correct me if I'm wrong) that
> there are no packages in repo whose names differ in letter size.
> What's more: "yum list" command is case insensitive and there's
> nothing wrong with it, is there? I know that you can say that these
> users I wrote about in the beginning should have used "yum list" first
> and then they would have found out why things went wrong but it makes
> a need to type more and more commands.
> "yum install" gives a summary what packages are going to be installed
> so if a user wanted to run "Foo", but not "foo" she/he could break the
> installation.
> Besides, pressing SHIFT key could be painful ;-)
> So my proposal is to make "yum install" (and probably "yum update" as
> well) case insensitive.
> Just think about it :)
> 
> Regards.

I would suggest that if this is done it would be extremely important to force
all package names to lower case.  Typing 'yum install foo' with a case
insensitive yum and getting both Foo and foo would be a broken situation.  Lets
assume they each bring in different dependencies... how do you choose one and
not the other?  With multiple repositories you cannot assume this won't happen.

I have wished package maintainers would just go with lower case for a long
time... directory listings of packages end up with essentially two separate
alphabetical listings (all upper case names first).  The mixture of case in perl
package names is especially annoying.

(but watch out for the panic as we go suggesting something so redmondish as not
respecting a file's case!)

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From skvidal at fedoraproject.org  Mon Nov 26 20:06:14 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Nov 2007 15:06:14 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126210313.28ca9ca2@lain.camperquake.de>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
Message-ID: <1196107574.15420.51.camel@cutter>


On Mon, 2007-11-26 at 21:03 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
> 
> > Search is case insensitive, list is a search.  However packages are
> > case sensitive.  While we don't /currently/ have a Miro and a miro,
> > the rpm database would allow for it, thus install/removal actions
> > need to be case sensitive.
> 
> How about "try case sensitive first, and insensitive if the first does
> not turn up anything"?

yes, b/c we love it so much when computer programs try to think for us.

-sv




From notting at redhat.com  Mon Nov 26 20:17:12 2007
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Nov 2007 15:17:12 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196107574.15420.51.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
Message-ID: <20071126201712.GA24375@nostromo.devel.redhat.com>

seth vidal (skvidal at fedoraproject.org) said: 
> yes, b/c we love it so much when computer programs try to think for us.

Why does yum keep responding to every command with "KILL ALL HUMANS"?

Bill



From lordmorgul at gmail.com  Mon Nov 26 20:19:46 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Mon, 26 Nov 2007 12:19:46 -0800
Subject: Killing maintainers
In-Reply-To: <20071126145651.7527971a@redhat.com>
References: <645d17210709051426i27aa589dt96240c3fed4139c6@mail.gmail.com>	<20070905173132.655bc3ae@mentok.boston.redhat.com>	<f224c6140709061402l63166813o2f1827a2b75e8e0b@mail.gmail.com>	<474B250A.1040509@gmail.com>
	<20071126145651.7527971a@redhat.com>
Message-ID: <474B2A62.9010300@gmail.com>

Jesse Keating wrote:
> On Mon, 26 Nov 2007 11:56:58 -0800
> Andrew Farris <lordmorgul at gmail.com> wrote:
> 
>> A good point, but there are also 'topics' supported by mailman.
>> There are currently no topics defined for any of the redhat lists I'm
>> aware of, but they could be.  The user interface (once logged in)
>> allows everyone subscribed to choose which topics to receive mailings
>> and which to ignore, and that would accomplish the goal and reduce
>> the mail traffic on both ends.
>>
>> If enough people really want to get rid of things like update
>> announcements coming in on one list, I would think creating a
>> subtopic for the list might be a good solution.
> 
> fedora-package-announce uses topics for each fedora release, so people
> can choose to only get announcements about the release they are using.
> Off and on I was working on a regex that would work to add a topic for
> the test releases as well, but I haven't got that done yet.

Ah ok good to hear thats an alternative looked into.  I do think the
'updates at fedoraproject.org' package announces to fedora-test-list is a good
subtopic candidate, unless those are actually going to get moved.  Without
getting too complex all those package announcements together might be one big
'on/off' rather than choosing which related test releases to receive on that list.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From skvidal at fedoraproject.org  Mon Nov 26 20:15:06 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Nov 2007 15:15:06 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126201712.GA24375@nostromo.devel.redhat.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<20071126201712.GA24375@nostromo.devel.redhat.com>
Message-ID: <1196108106.15420.53.camel@cutter>


On Mon, 2007-11-26 at 15:17 -0500, Bill Nottingham wrote:
> seth vidal (skvidal at fedoraproject.org) said: 
> > yes, b/c we love it so much when computer programs try to think for us.
> 
> Why does yum keep responding to every command with "KILL ALL HUMANS"?
> 

b/c yum is always asked to implement a 'do what I mean' mode.

-sv




From sundaram at fedoraproject.org  Mon Nov 26 20:19:12 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Nov 2007 01:49:12 +0530
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196107574.15420.51.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
Message-ID: <474B2A40.7030800@fedoraproject.org>

seth vidal wrote:
> On Mon, 2007-11-26 at 21:03 +0100, Ralf Ertzinger wrote:
>> Hi.
>>
>> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
>>
>>> Search is case insensitive, list is a search.  However packages are
>>> case sensitive.  While we don't /currently/ have a Miro and a miro,
>>> the rpm database would allow for it, thus install/removal actions
>>> need to be case sensitive.
>> How about "try case sensitive first, and insensitive if the first does
>> not turn up anything"?
> 
> yes, b/c we love it so much when computer programs try to think for us.

They already do in a lot of occasions anyway. Is there a real reason not 
to do this? I always hated finding out that some package have 
capitalizations for no obvious reasons. MySQL or mysql or Mysql... Being 
able to just type yum install mysql without having to worry about the 
specifics would be nice.

Rahul



From skvidal at fedoraproject.org  Mon Nov 26 20:27:50 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Nov 2007 15:27:50 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B2A40.7030800@fedoraproject.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
Message-ID: <1196108870.15420.55.camel@cutter>


On Tue, 2007-11-27 at 01:49 +0530, Rahul Sundaram wrote:
> seth vidal wrote:
> > On Mon, 2007-11-26 at 21:03 +0100, Ralf Ertzinger wrote:
> >> Hi.
> >>
> >> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
> >>
> >>> Search is case insensitive, list is a search.  However packages are
> >>> case sensitive.  While we don't /currently/ have a Miro and a miro,
> >>> the rpm database would allow for it, thus install/removal actions
> >>> need to be case sensitive.
> >> How about "try case sensitive first, and insensitive if the first does
> >> not turn up anything"?
> > 
> > yes, b/c we love it so much when computer programs try to think for us.
> 
> They already do in a lot of occasions anyway. Is there a real reason not 
> to do this? I always hated finding out that some package have 
> capitalizations for no obvious reasons. MySQL or mysql or Mysql... Being 
> able to just type yum install mysql without having to worry about the 
> specifics would be nice.

yes, b/c it is a really bad idea.

much like having: rm -rf foo actually be case insensitive.

-sv




From j.w.r.degoede at hhs.nl  Mon Nov 26 20:35:40 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Mon, 26 Nov 2007 21:35:40 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B2A40.7030800@fedoraproject.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
Message-ID: <474B2E1C.5010107@hhs.nl>

Rahul Sundaram wrote:
> seth vidal wrote:
>> On Mon, 2007-11-26 at 21:03 +0100, Ralf Ertzinger wrote:
>>> Hi.
>>>
>>> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
>>>
>>>> Search is case insensitive, list is a search.  However packages are
>>>> case sensitive.  While we don't /currently/ have a Miro and a miro,
>>>> the rpm database would allow for it, thus install/removal actions
>>>> need to be case sensitive.
>>> How about "try case sensitive first, and insensitive if the first does
>>> not turn up anything"?
>>
>> yes, b/c we love it so much when computer programs try to think for us.
> 
> They already do in a lot of occasions anyway. Is there a real reason not 
> to do this? I always hated finding out that some package have 
> capitalizations for no obvious reasons. MySQL or mysql or Mysql... Being 
> able to just type yum install mysql without having to worry about the 
> specifics would be nice.
> 

Good plan! And while we are at it we should make yum remove case sensitive too, 
people will get really confused if "yum install StrANgECaps" works but "yum 
remove StrANgECaps" won't, so for consistency we really should make yum remove 
case insensitive too.

Regards,

Hans



From jkeating at redhat.com  Mon Nov 26 20:37:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Nov 2007 15:37:14 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B2E1C.5010107@hhs.nl>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org> <474B2E1C.5010107@hhs.nl>
Message-ID: <20071126153714.4ff0464e@redhat.com>

On Mon, 26 Nov 2007 21:35:40 +0100
Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Good plan! And while we are at it we should make yum remove case
> sensitive too, people will get really confused if "yum install
> StrANgECaps" works but "yum remove StrANgECaps" won't, so for
> consistency we really should make yum remove case insensitive too.

Or instead we make policy that any package that has WiErDCasIng have a
Provides: nameinlower.  Of course this will bloat the metadata somewhat.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/62bca852/attachment.sig>

From fedora at camperquake.de  Mon Nov 26 20:41:44 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Nov 2007 21:41:44 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196107574.15420.51.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
Message-ID: <20071126214144.76e979df@lain.camperquake.de>

Hi.

On Mon, 26 Nov 2007 15:06:14 -0500, seth vidal wrote

> yes, b/c we love it so much when computer programs try to think for
> us.

You know, that was kind of the idea of the whole enterprise.



From sundaram at fedoraproject.org  Mon Nov 26 20:40:02 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Nov 2007 02:10:02 +0530
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196108870.15420.55.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
Message-ID: <474B2F22.7020102@fedoraproject.org>

seth vidal wrote:
> On Tue, 2007-11-27 at 01:49 +0530, Rahul Sundaram wrote:
>> seth vidal wrote:
>>> On Mon, 2007-11-26 at 21:03 +0100, Ralf Ertzinger wrote:
>>>> Hi.
>>>>
>>>> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
>>>>
>>>>> Search is case insensitive, list is a search.  However packages are
>>>>> case sensitive.  While we don't /currently/ have a Miro and a miro,
>>>>> the rpm database would allow for it, thus install/removal actions
>>>>> need to be case sensitive.
>>>> How about "try case sensitive first, and insensitive if the first does
>>>> not turn up anything"?
>>> yes, b/c we love it so much when computer programs try to think for us.
>> They already do in a lot of occasions anyway. Is there a real reason not 
>> to do this? I always hated finding out that some package have 
>> capitalizations for no obvious reasons. MySQL or mysql or Mysql... Being 
>> able to just type yum install mysql without having to worry about the 
>> specifics would be nice.
> 
> yes, b/c it is a really bad idea.
> 
> much like having: rm -rf foo actually be case insensitive.

I understood you think it is a bad idea but if yum already checks first 
to see if there is a perfect match and then does a more fuzzy search, I 
don't see a problem with it. There are people who do yum -y remove foo 
and then blame yum. I think your rm -rf example is similar.

There is a real need to solve the problem that OP talks about. It has 
bitten me more than once including precisely the example cited: Miro. I 
am not sure what would be the best solution though. Debian does it by 
enforcing lower case on all their packages IIRC.

Rahul



From fedora at camperquake.de  Mon Nov 26 20:48:19 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Nov 2007 21:48:19 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196108870.15420.55.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
Message-ID: <20071126214819.52465ae3@lain.camperquake.de>

Hi.

On Mon, 26 Nov 2007 15:27:50 -0500, seth vidal wrote

> yes, b/c it is a really bad idea.
> 
> much like having: rm -rf foo actually be case insensitive.

Bonus points for argumentation. Find counterexample and postulate
generality.

Oh, and that above is dependant on the underlying file system.



From adrian at lisas.de  Mon Nov 26 20:51:40 2007
From: adrian at lisas.de (Adrian Reber)
Date: Mon, 26 Nov 2007 21:51:40 +0100
Subject: Anyone packaging gnu source-highlight?
In-Reply-To: <fif8e4$ho2$1@ger.gmane.org>
References: <fif8e4$ho2$1@ger.gmane.org>
Message-ID: <20071126205140.GA18928@lisas.de>

On Mon, Nov 26, 2007 at 02:56:52PM -0500, Neal Becker wrote:
> yum search doesn't show anything, anyone doing this or want to?
> http://www.gnu.org/software/src-highlite/

$ yum list source-highlight 
Available Packages
source-highlight.i386                    2.7-1.fc8              fedora

		Adrian



From lesmikesell at gmail.com  Mon Nov 26 21:03:52 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Mon, 26 Nov 2007 15:03:52 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126214819.52465ae3@lain.camperquake.de>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>
	<20071126214819.52465ae3@lain.camperquake.de>
Message-ID: <474B34B8.9020602@gmail.com>

Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 26 Nov 2007 15:27:50 -0500, seth vidal wrote
> 
>> yes, b/c it is a really bad idea.
>>
>> much like having: rm -rf foo actually be case insensitive.
> 
> Bonus points for argumentation. Find counterexample and postulate
> generality.

This would make yum as confusing to use as a Mac.  Oh wait...

-- 
   Les Mikesell
    lesmikesell at gmail.com



From mr.ecik at gmail.com  Mon Nov 26 21:04:21 2007
From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=)
Date: Mon, 26 Nov 2007 22:04:21 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126145534.7df4d8d3@redhat.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
Message-ID: <668bb39a0711261304w461a7294hf0878816ccb88fbf@mail.gmail.com>

So I have another idea. I still believe that just making installing in
yum case insensitive would be a good idea, but we can make something
like "yum suggestions". Example:

# yum install perl-TExt-CharWidth
No package perl-TExt-CharWidth available.
(didn't you mean perl-Text-CharWidth?)

Yum wouldn't install a package itself, but just suggest to an user
that "sorry man, you made a mistake". That should make everybody happy
and shouldn't be difficult to implement too.
And we could add a new option to yum.conf file: "sensitiveness=1". Can
be changed to "=1" if anybody like.


2007/11/26, Jesse Keating <jkeating at redhat.com>:
> On Mon, 26 Nov 2007 20:50:46 +0100
> "Micha? Bentkowski" <mr.ecik at gmail.com> wrote:
>
> > Hi!
> > Recently, a funny thing happened on Polish Fedora forum. Some users
> > were talking about Miro but rest of them weren't able even to install
> > that... After some time it turned out that they tried to type "yum
> > install miro" instead of "yum install Miro".
> > So my question is the same as in the topic: should "yum install" be
> > case sensitive?
> > I haven't checked but I'm quite sure (correct me if I'm wrong) that
> > there are no packages in repo whose names differ in letter size.
> > What's more: "yum list" command is case insensitive and there's
> > nothing wrong with it, is there? I know that you can say that these
> > users I wrote about in the beginning should have used "yum list" first
> > and then they would have found out why things went wrong but it makes
> > a need to type more and more commands.
> > "yum install" gives a summary what packages are going to be installed
> > so if a user wanted to run "Foo", but not "foo" she/he could break the
> > installation.
> > Besides, pressing SHIFT key could be painful ;-)
> > So my proposal is to make "yum install" (and probably "yum update" as
> > well) case insensitive.
> > Just think about it :)
>
> Search is case insensitive, list is a search.  However packages are
> case sensitive.  While we don't /currently/ have a Miro and a miro, the
> rpm database would allow for it, thus install/removal actions need to
> be case sensitive.  We could try for some brutal packaging policy that
> demands all package names be in lower case, but I doubt that would fly
> very far.
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>


-- 
Micha? Bentkowski
mr.ecik at gmail.com



From jwboyer at gmail.com  Mon Nov 26 21:05:22 2007
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 26 Nov 2007 15:05:22 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B2F22.7020102@fedoraproject.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
Message-ID: <20071126150522.4c80734e@weaponx>

On Tue, 27 Nov 2007 02:10:02 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> seth vidal wrote:
> > On Tue, 2007-11-27 at 01:49 +0530, Rahul Sundaram wrote:
> >> seth vidal wrote:
> >>> On Mon, 2007-11-26 at 21:03 +0100, Ralf Ertzinger wrote:
> >>>> Hi.
> >>>>
> >>>> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
> >>>>
> >>>>> Search is case insensitive, list is a search.  However packages are
> >>>>> case sensitive.  While we don't /currently/ have a Miro and a miro,
> >>>>> the rpm database would allow for it, thus install/removal actions
> >>>>> need to be case sensitive.
> >>>> How about "try case sensitive first, and insensitive if the first does
> >>>> not turn up anything"?
> >>> yes, b/c we love it so much when computer programs try to think for us.
> >> They already do in a lot of occasions anyway. Is there a real reason not 
> >> to do this? I always hated finding out that some package have 
> >> capitalizations for no obvious reasons. MySQL or mysql or Mysql... Being 
> >> able to just type yum install mysql without having to worry about the 
> >> specifics would be nice.
> > 
> > yes, b/c it is a really bad idea.
> > 
> > much like having: rm -rf foo actually be case insensitive.
> 
> I understood you think it is a bad idea but if yum already checks first 
> to see if there is a perfect match and then does a more fuzzy search, I 
> don't see a problem with it. There are people who do yum -y remove foo 
> and then blame yum. I think your rm -rf example is similar.

Here's the problem with it:  Seth thinks it's a bad idea.  He's the
upstream for yum.

josh

p.s. I think it's a bad idea too for what it's worth.



From work.eric at gmail.com  Mon Nov 26 21:10:39 2007
From: work.eric at gmail.com (Eric Work)
Date: Mon, 26 Nov 2007 13:10:39 -0800
Subject: Two Problems
Message-ID: <474B364F.3020901@gmail.com>

Hey Everyone,

I have two problems with my package: gtkdatabox

1. After updating the package source and spec file for gtkdatabox for 
FC-5 and FC-6 and attempting a build, I realized that the pango version 
available in those releases is too old.  Upstream only mentioned a 
dependency on gtk+ 2.8 not pango 1.16.  I will inform upstream also but 
how should I resolve this.  The question is how should I revert back to 
an older version of the package?

2. The other problem is that gtkdatabox is unable to build on x86_64 do 
to some problem with -fPIC even though it's being used when the source 
files are compile.  I was able to compile the source on my 64-bit Ubuntu 
machine with no problems.  Maybe a problem with autotools?  The koji 
taskID is: 259807.

Thanks in advance for the help.

-Eric



From dcbw at redhat.com  Mon Nov 26 21:15:43 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Nov 2007 16:15:43 -0500
Subject: NetworkManager-umts
In-Reply-To: <20071126205111.3a19be68@lain.camperquake.de>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
Message-ID: <1196111743.31082.0.camel@localhost.localdomain>

On Mon, 2007-11-26 at 20:51 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 26 Nov 2007 14:41:45 -0500, Dan Williams wrote
> > network authenticates you based on MEID or ESN, not user/pass).  You
> > also don't need to select what band you want to use since they
> > automatically pick the best available connectivity (whereas with GSM
> > you can sometimes pick between GSM/GPRS/EDGE and UMTS/HSPA).
> 
> For the GSM/UMTS connections I have used this is quite similar (Germany,
> T-Mobile network). The number you dial is *99#, username/password does
> not matter.

You at least need an APN though, right?

Dan




From fedora at camperquake.de  Mon Nov 26 21:25:52 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 26 Nov 2007 22:25:52 +0100
Subject: NetworkManager-umts
In-Reply-To: <1196111743.31082.0.camel@localhost.localdomain>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
Message-ID: <20071126222552.20bc9e65@lain.camperquake.de>

Hi.

On Mon, 26 Nov 2007 16:15:43 -0500, Dan Williams wrote

> You at least need an APN though, right?

A what?



From mschwendt.tmp0701.nospam at arcor.de  Mon Nov 26 21:33:19 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Mon, 26 Nov 2007 22:33:19 +0100
Subject: Two Problems
In-Reply-To: <474B364F.3020901@gmail.com>
References: <474B364F.3020901@gmail.com>
Message-ID: <20071126223319.7956f8c0.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 26 Nov 2007 13:10:39 -0800, Eric Work wrote:

> Hey Everyone,
> 
> I have two problems with my package: gtkdatabox
> 
> 1. After updating the package source and spec file for gtkdatabox for 
> FC-5 and FC-6 and attempting a build, I realized that the pango version 
> available in those releases is too old.  Upstream only mentioned a 
> dependency on gtk+ 2.8 not pango 1.16.  I will inform upstream also but 
> how should I resolve this.  The question is how should I revert back to 
> an older version of the package?

If it built fine in the buildsys, we can delete the build from the
needsign repo and don't push it. In CVS, however, you can simply revert to
the files from the previous package release. Look at something like "cvs
log gtkdatabox.spec" for the tags you've applied before, check out the
older package with a given tag and commit the files to CVS HEAD again.

> 2. The other problem is that gtkdatabox is unable to build on x86_64 do 
> to some problem with -fPIC even though it's being used when the source 
> files are compile.  I was able to compile the source on my 64-bit Ubuntu 
> machine with no problems.  Maybe a problem with autotools?  The koji 
> taskID is: 259807.

There are suspicious compiler warnings in the build log, too. Since I
cannot give it a try on x86_64 myself, it might be worthwhile to fix the
warnings first.

http://koji.fedoraproject.org/koji/getfile?taskID=259814&name=build.log



From sundaram at fedoraproject.org  Mon Nov 26 21:27:44 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Nov 2007 02:57:44 +0530
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126150522.4c80734e@weaponx>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>
	<20071126150522.4c80734e@weaponx>
Message-ID: <474B3A50.2090807@fedoraproject.org>

Josh Boyer wrote:

> 
> Here's the problem with it:  Seth thinks it's a bad idea.  He's the
> upstream for yum.

This sounds like "because I said so". There needs to be more substantial 
arguments beyond gut feelings involved here. If you think something is a 
bad idea, it would be good to explain why in a bit more detail if only 
because it forces you to think about it a bit or try and offer some 
suggestions to solve the problem in another way.

Rahul



From dcbw at redhat.com  Mon Nov 26 21:52:13 2007
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Nov 2007 16:52:13 -0500
Subject: NetworkManager-umts
In-Reply-To: <20071126222552.20bc9e65@lain.camperquake.de>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
Message-ID: <1196113933.31082.11.camel@localhost.localdomain>

On Mon, 2007-11-26 at 22:25 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Mon, 26 Nov 2007 16:15:43 -0500, Dan Williams wrote
> 
> > You at least need an APN though, right?
> 
> A what?

http://en.wikipedia.org/wiki/Access_Point_Name

Definitely needed for GPRS/EDGE, not sure if it's needed for UMTS but I
think it may be, depending on your provider.  In any case, when your
card falls back to GPRS/EDGE coverage you'll need it.

Dan




From skvidal at fedoraproject.org  Mon Nov 26 22:00:17 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Nov 2007 17:00:17 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B2F22.7020102@fedoraproject.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter> <474B2F22.7020102@fedoraproject.org>
Message-ID: <1196114417.15420.60.camel@cutter>


On Tue, 2007-11-27 at 02:10 +0530, Rahul Sundaram wrote:

> I understood you think it is a bad idea but if yum already checks first 
> to see if there is a perfect match and then does a more fuzzy search, I 
> don't see a problem with it. There are people who do yum -y remove foo 
> and then blame yum. I think your rm -rf example is similar.
> 
> There is a real need to solve the problem that OP talks about. It has 
> bitten me more than once including precisely the example cited: Miro. I 
> am not sure what would be the best solution though. Debian does it by 
> enforcing lower case on all their packages IIRC.

Yes and that is what we should do - enforce lower case on all packages.

Policy problems should be handled in policy, not by adding crack to
software.

-sv




From tcallawa at redhat.com  Mon Nov 26 22:07:24 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 26 Nov 2007 17:07:24 -0500
Subject: Two Problems
In-Reply-To: <474B364F.3020901@gmail.com>
References: <474B364F.3020901@gmail.com>
Message-ID: <1196114844.3229.6.camel@localhost.localdomain>


On Mon, 2007-11-26 at 13:10 -0800, Eric Work wrote:

> 2. The other problem is that gtkdatabox is unable to build on x86_64 do 
> to some problem with -fPIC even though it's being used when the source 
> files are compile.  I was able to compile the source on my 64-bit Ubuntu 
> machine with no problems.  Maybe a problem with autotools?  The koji 
> taskID is: 259807.

No, its a problem with the gtkdatabox source. Ubuntu might not have
caught it because G_GNUC_INTERNAL isn't defined in their toolchain (just
guessing). The gtk_databox_marshal_VOID__POINTER_POINTER has the
G_GNUC_INTERNAL attribute on it in the .h file, but not in the .c file,
thus the confusion at link time.

I've attached two patches, one to fix the x86_64 compile error, and the
other to make gtkdatabox use the Fedora optflags. And as a bonus, I've
attached a new spec file which not only applies these patches, it also
fixes the license tag to be in compliance with the Fedora licensing
policy.

But Wait! There's more!

...

Actually, no. That's it.

hth,

~spot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtkdatabox-0.8.0.1-compilefix.patch
Type: text/x-patch
Size: 723 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/f5f53f70/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtkdatabox-0.8.0.1-userpmoptflags.patch
Type: text/x-patch
Size: 1768 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/f5f53f70/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtkdatabox.spec
Type: text/x-rpm-spec
Size: 2431 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/f5f53f70/attachment-0002.bin>

From skvidal at fedoraproject.org  Mon Nov 26 22:01:29 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Nov 2007 17:01:29 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B3A50.2090807@fedoraproject.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>
	<20071126150522.4c80734e@weaponx> <474B3A50.2090807@fedoraproject.org>
Message-ID: <1196114489.15420.62.camel@cutter>


On Tue, 2007-11-27 at 02:57 +0530, Rahul Sundaram wrote:
> Josh Boyer wrote:
> 
> > 
> > Here's the problem with it:  Seth thinks it's a bad idea.  He's the
> > upstream for yum.
> 
> This sounds like "because I said so". There needs to be more substantial 
> arguments beyond gut feelings involved here. If you think something is a 
> bad idea, it would be good to explain why in a bit more detail if only 
> because it forces you to think about it a bit or try and offer some 
> suggestions to solve the problem in another way.

I already explained why. You do not play 'do what I mean' games with
software that can nuke your whole box or destroy all your data.


-sv




From the.masch at gmail.com  Mon Nov 26 22:30:32 2007
From: the.masch at gmail.com (masch)
Date: Mon, 26 Nov 2007 17:30:32 -0500
Subject: Tv Card
Message-ID: <93d66b780711261430v60ee59d5qa73ecada929526c8@mail.gmail.com>

Hi!
I want to use an TV card in Fedora, I'm from Argentina and my TV
signal  is PAL-N, What card do you recommend do it?

Salu2..



From david at fubar.dk  Mon Nov 26 22:40:58 2007
From: david at fubar.dk (David Zeuthen)
Date: Mon, 26 Nov 2007 17:40:58 -0500
Subject: Tv Card
In-Reply-To: <93d66b780711261430v60ee59d5qa73ecada929526c8@mail.gmail.com>
References: <93d66b780711261430v60ee59d5qa73ecada929526c8@mail.gmail.com>
Message-ID: <1196116858.29259.0.camel@oneill.fubar.dk>


On Mon, 2007-11-26 at 17:30 -0500, masch wrote:
> Hi!
> I want to use an TV card in Fedora, I'm from Argentina and my TV
> signal  is PAL-N, What card do you recommend do it?

http://fedoraproject.org/wiki/PostIsOffTopic

Thanks,
David




From lsof at nodata.co.uk  Mon Nov 26 22:49:15 2007
From: lsof at nodata.co.uk (nodata)
Date: Mon, 26 Nov 2007 23:49:15 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126210313.28ca9ca2@lain.camperquake.de>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
Message-ID: <1196117355.2739.6.camel@sb-home>


Am Montag, den 26.11.2007, 21:03 +0100 schrieb Ralf Ertzinger:
> Hi.
> 
> On Mon, 26 Nov 2007 14:55:34 -0500, Jesse Keating wrote
> 
> > Search is case insensitive, list is a search.  However packages are
> > case sensitive.  While we don't /currently/ have a Miro and a miro,
> > the rpm database would allow for it, thus install/removal actions
> > need to be case sensitive.
> 
> How about "try case sensitive first, and insensitive if the first does
> not turn up anything"?
> 

How about: human learns that yum/unix/linux is case sensitive, doesn't
make mistake again.



From che666 at gmail.com  Mon Nov 26 23:01:48 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 26 Nov 2007 23:01:48 +0000
Subject: NetworkManager-umts
In-Reply-To: <1196113933.31082.11.camel@localhost.localdomain>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
Message-ID: <e99d27470711261501j17727cacs22d5bad57f24c38b@mail.gmail.com>

On Nov 26, 2007 9:52 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Mon, 2007-11-26 at 22:25 +0100, Ralf Ertzinger wrote:
> > Hi.
> >
> > On Mon, 26 Nov 2007 16:15:43 -0500, Dan Williams wrote
> >
> > > You at least need an APN though, right?
> >
> > A what?
>
> http://en.wikipedia.org/wiki/Access_Point_Name
>
> Definitely needed for GPRS/EDGE, not sure if it's needed for UMTS but I
> think it may be, depending on your provider.  In any case, when your
> card falls back to GPRS/EDGE coverage you'll need it.
>
> Dan
>

apn is mandatory for umts (atleast for the providers i tried yet)

kind regards,
Rudolf Kastl
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From opensource at till.name  Mon Nov 26 23:22:43 2007
From: opensource at till.name (Till Maas)
Date: Tue, 27 Nov 2007 00:22:43 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196114489.15420.62.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<474B3A50.2090807@fedoraproject.org> <1196114489.15420.62.camel@cutter>
Message-ID: <200711270022.48458.opensource@till.name>

On Mo November 26 2007, seth vidal wrote:

> I already explained why. You do not play 'do what I mean' games with
> software that can nuke your whole box or destroy all your data.

How about making it case unsensitive only when assume-yes (or -y) is not set? 
This way the use is always asked whether he really wants this? Or make yum 
suggest other packages that are available but differ in case, e.g. printing a 
message like "foo is not available, but there is a package Foo".

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/13496f8e/attachment.sig>

From jspaleta at gmail.com  Mon Nov 26 23:33:41 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 26 Nov 2007 14:33:41 -0900
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196114417.15420.60.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
Message-ID: <604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>

On Nov 26, 2007 1:00 PM, seth vidal <skvidal at fedoraproject.org> wrote:
> Yes and that is what we should do - enforce lower case on all packages.
>
> Policy problems should be handled in policy, not by adding crack to
> software.


I think your right, I think we get into less trouble long term by
making this a policy fix instead of a psuedo technical fix.  Unless we
can make a commitment all the way down the stack into the rpmdb to be
case insensitive for all package name operations, then we shouldn't
plaster over it by making yum install/remove case insensitive.

And besides, moving to all lowercase for package names mean that I can
finally navigate the bugzilla component pulldown menu reliably :->

Or turning the question on its head, is there anyone working on making
the syntax of yum searches more expressive so that I could do things
like requesting a case sensitive search?

-jef



From docs-list at fedoralinks.org  Mon Nov 26 23:27:45 2007
From: docs-list at fedoralinks.org (Robert 'Bob' Jensen)
Date: Mon, 26 Nov 2007 17:27:45 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <200711270022.48458.opensource@till.name>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<474B3A50.2090807@fedoraproject.org>
	<1196114489.15420.62.camel@cutter>
	<200711270022.48458.opensource@till.name>
Message-ID: <474B5671.20604@fedoralinks.org>

Till Maas wrote:
> On Mo November 26 2007, seth vidal wrote:
> 
>> I already explained why. You do not play 'do what I mean' games with
>> software that can nuke your whole box or destroy all your data.
> 
> How about making it case unsensitive only when assume-yes (or -y) is not set? 
> This way the use is always asked whether he really wants this? Or make yum 
> suggest other packages that are available but differ in case, e.g. printing a 
> message like "foo is not available, but there is a package Foo".
> 
> Regards,
> Till
> 

And people complain that yum is slow now... I can't see this speeding 
things up.

Robert 'Bob' Jensen
http://fedoraproject.org/wiki/BobJensen
Fedora Unity Project
http://fedoraunity.org/
KC0WYC
http://fedoraproject.org/wiki/SIGs/AmateurRadio



From wtogami at redhat.com  Tue Nov 27 01:38:26 2007
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 26 Nov 2007 20:38:26 -0500
Subject: SDL pulseaudio workaround hack
Message-ID: <474B7512.3080408@redhat.com>

* Tue Oct 30 2007 Warren Togami <wtogami at redhat.com> - 1.2.8-4
- SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio directly
   avoids applications from locking up. (#358341)

At the last minute before F-8's release I added this ugly hack to 
SDL_mixer to force SDL to use esd for sound instead of the default ALSA. 
  This change was made because it would at least allow sound on popular 
games like wesnoth to work, and make the Fedora Games spin not 
dead-on-arrival.

Unfortunately, this had the side-effect that we knew at the time of 
disabling SDL sound if you have pulseaudio disabled or removed.

I should have thought of this earlier, but the /etc/profile.d/* scripts 
that set the environment variable commanding SDL to use esd could have 
been conditional.  Still not perfect, but better to tide us over until 
Lennart implements native pulseaudio for SDL that he promised to do 
before F9.

The following changes should improve our workaround.  I am uncertain if 
the .csh version needs a matching unset for nonomatch or does it happen 
automatically?

Should we push this in a SDL_mixer update?

Warren Togami
wtogami at redhat.com

cvs diff: Diffing .
Index: SDL_pulseaudio_hack.csh
===================================================================
RCS file: /cvs/pkgs/rpms/SDL_mixer/devel/SDL_pulseaudio_hack.csh,v
retrieving revision 1.1
diff -u -p -r1.1 SDL_pulseaudio_hack.csh
--- SDL_pulseaudio_hack.csh     31 Oct 2007 14:39:10 -0000      1.1
+++ SDL_pulseaudio_hack.csh     27 Nov 2007 01:33:43 -0000
@@ -1,2 +1,4 @@
  # Temporary hack until SDL directly supports pulseaudio
-setenv SDL_AUDIODRIVER esd
+# If alsa-plugins-pulseaudio is installed, force SDL to output sound to esd
+set nonomatch
+if ( -e /usr/lib*/alsa-lib/libasound_module_pcm_pulse.so ) setenv 
SDL_AUDIODRIVER esd
Index: SDL_pulseaudio_hack.sh
===================================================================
RCS file: /cvs/pkgs/rpms/SDL_mixer/devel/SDL_pulseaudio_hack.sh,v
retrieving revision 1.1
diff -u -p -r1.1 SDL_pulseaudio_hack.sh
--- SDL_pulseaudio_hack.sh      31 Oct 2007 14:39:10 -0000      1.1
+++ SDL_pulseaudio_hack.sh      27 Nov 2007 01:33:43 -0000
@@ -1,2 +1,3 @@
  # Temporary hack until SDL directly supports pulseaudio
-export SDL_AUDIODRIVER=esd
+# If alsa-plugins-pulseaudio is installed, force SDL to output sound to esd
+[ -e /usr/lib*/alsa-lib/libasound_module_pcm_pulse.so ] && export 
SDL_AUDIODRIVER=esd



From davej at redhat.com  Tue Nov 27 01:45:05 2007
From: davej at redhat.com (Dave Jones)
Date: Mon, 26 Nov 2007 20:45:05 -0500
Subject: Disabling readahead
In-Reply-To: <474AE38D.30406@redhat.com>
References: <20071126113203.M96422@all-the-johnsons.co.uk>
	<474AE38D.30406@redhat.com>
Message-ID: <20071127014505.GA28407@redhat.com>

On Mon, Nov 26, 2007 at 09:17:33AM -0600, Eric Sandeen wrote:
 > Paul F. Johnson wrote:
 > > Hi,
 > > 
 > > I have readahead currently running on my test rig (x86_64, rawhide), but it's
 > > currently giving me all sorts of problems, so much so that the box is pretty
 > > unusable (random hangs abound and hugely varied times to getting the desktop
 > > to boot - I've tried to file BZ reports, but the machine dies before I can).
 > >
 > > I've read that readahead is currently broken in rawhide. Normally, my machine
 > > boots directly to runlevel 5. Can I alter on the kernel boot line for it jump
 > > to level 3? I can then disable the readahead service.
 > 
 > 
 > I'd honestly be surprised if the readahead scripts are the culprit - how
 > did you identify readahead as the problem?  The "brokenness" is really
 > mostly about inefficiency, as far as I know.

Agreed. If you see a hang with it enabled, it's a sign of a bigger problem elsewhere.

	Dave

-- 
http://www.codemonkey.org.uk



From work.eric at gmail.com  Tue Nov 27 01:44:57 2007
From: work.eric at gmail.com (Eric Work)
Date: Mon, 26 Nov 2007 17:44:57 -0800
Subject: Two Problems
In-Reply-To: <20071126232327.24DB373375@hormel.redhat.com>
References: <20071126232327.24DB373375@hormel.redhat.com>
Message-ID: <474B7699.10600@gmail.com>

Michael Schwendt & Tom "spot" Callaway,

>> 1. After updating the package source and spec file for gtkdatabox for 
>> FC-5 and FC-6 and attempting a build, I realized that the pango version 
>> available in those releases is too old.  Upstream only mentioned a 
>> dependency on gtk+ 2.8 not pango 1.16.  I will inform upstream also but 
>> how should I resolve this.  The question is how should I revert back to 
>> an older version of the package?
> 
> If it built fine in the buildsys, we can delete the build from the
> needsign repo and don't push it. In CVS, however, you can simply revert to
> the files from the previous package release. Look at something like "cvs
> log gtkdatabox.spec" for the tags you've applied before, check out the
> older package with a given tag and commit the files to CVS HEAD again.

Michael, The build did not succeed so that made things a little simpler. 
  I did as you suggested and updated CVS HEAD with the older version. 
That was a pretty simple fix.  I also noticed that running "make build" 
in any branch prior to FC-6 fails.  I'm guessing this is expected.

>> > 2. The other problem is that gtkdatabox is unable to build on x86_64 do 
>> > to some problem with -fPIC even though it's being used when the source 
>> > files are compile.  I was able to compile the source on my 64-bit Ubuntu 
>> > machine with no problems.  Maybe a problem with autotools?  The koji 
>> > taskID is: 259807.
> 
> No, its a problem with the gtkdatabox source. Ubuntu might not have
> caught it because G_GNUC_INTERNAL isn't defined in their toolchain (just
> guessing). The gtk_databox_marshal_VOID__POINTER_POINTER has the
> G_GNUC_INTERNAL attribute on it in the .h file, but not in the .c file,
> thus the confusion at link time.
> 
> I've attached two patches, one to fix the x86_64 compile error, and the
> other to make gtkdatabox use the Fedora optflags. And as a bonus, I've
> attached a new spec file which not only applies these patches, it also
> fixes the license tag to be in compliance with the Fedora licensing
> policy.

Tom, thanks for all your work the package now builds on all archs.  I 
have submitted the compiler patch upstream.  When I get a new version 
back from upstream (which should be soon) I'll push the update to F-7 
and F-8.

-Eric



From james.antill at redhat.com  Tue Nov 27 01:52:39 2007
From: james.antill at redhat.com (James Antill)
Date: Mon, 26 Nov 2007 20:52:39 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter> <474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>
Message-ID: <1196128360.1275.6.camel@code.and.org>


On Mon, 2007-11-26 at 14:33 -0900, Jeff Spaleta wrote:

> Or turning the question on its head, is there anyone working on making
> the syntax of yum searches more expressive so that I could do things
> like requesting a case sensitive search?

 As seth already pointed out, the main innocuous commands are already
case insensitive. So search, list etc.

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/0a05abf2/attachment.sig>

From fkautz at pseudocode.cc  Tue Nov 27 01:58:07 2007
From: fkautz at pseudocode.cc (Kautz, Frederick)
Date: Mon, 26 Nov 2007 20:58:07 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071126214819.52465ae3@lain.camperquake.de>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com><20071126145534.7df4d8d3@redhat.com><20071126210313.28ca9ca2@lain.camperquake.de><1196107574.15420.51.camel@cutter><474B2A40.7030800@fedoraproject.org><1196108870.15420.55.camel@cutter>
	<20071126214819.52465ae3@lain.camperquake.de>
Message-ID: <98CE1F4E10689F4EB043AC6AECB753E0713122@ntxbeus19.exchange.xchg>

>Hi.
>
>On Mon, 26 Nov 2007 15:27:50 -0500, seth vidal wrote
>
>> yes, b/c it is a really bad idea.
>> 
>> much like having: rm -rf foo actually be case insensitive.
>
>Bonus points for argumentation. Find counterexample and postulate
>generality.
>
>Oh, and that above is dependant on the underlying file system.

Not that we are worrying about cygwin... but it turns out that
$ touch TEST
$ rm test

The file TEST is removed. rm has everything to do with the underlying
filesystem.

My thought on this topic is... if yum is asked to install mysql and the
package name is actually MySQL... it should make a suggestion like:

Could not find package 'mysql'. Would you like to install package
'MySQL' instead? [y/N]

Perhaps someone could come up with a better wording for it. I do not
think this approach would add much time to yum. Perhaps someone with
more knowledge on the implementation of yum could confirm this.



From cra at WPI.EDU  Tue Nov 27 02:24:48 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Mon, 26 Nov 2007 21:24:48 -0500
Subject: alpha/beta software in Fedora 8?
Message-ID: <20071127022448.GB24257@angus.ind.WPI.EDU>

Fedora 8 shipped with an BIND 9.5.0a6, recently updated to 9.5.0a7.  
The release announcement for BIND says:

BIND 9.5.0a7 is a alpha release for BIND 9.5.0.

	This is a technology preview of new functionality to be be
	released in BIND 9.5.0.  New APIs are not yet frozen.

Is this an appropriate release to be putting in a stable Fedora 
release?  I've encounted a segfault in this version, which I've 
reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=400461

I'm concerned about the policies which allow unstable software in 
stable Fedora releases.  Is it considered acceptable/encouraged to 
have alpha versions of software in the stable release?  Is there any 
policy?

Thanks.



From tcallawa at redhat.com  Tue Nov 27 02:29:55 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Mon, 26 Nov 2007 21:29:55 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127022448.GB24257@angus.ind.WPI.EDU>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
Message-ID: <1196130595.3229.20.camel@localhost.localdomain>


On Mon, 2007-11-26 at 21:24 -0500, Chuck Anderson wrote:

> I'm concerned about the policies which allow unstable software in 
> stable Fedora releases.  Is it considered acceptable/encouraged to 
> have alpha versions of software in the stable release?  Is there any 
> policy?

There is no policy, its up to the individual maintainer to use their
best judgement as to what should be included.

~spot



From kevin.kofler at chello.at  Tue Nov 27 02:31:49 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 27 Nov 2007 02:31:49 +0000 (UTC)
Subject: Heads up: openldap rebase for Fedora/devel
References: <32140.192.54.193.53.1195810337.squirrel@rousalka.dyndns.org>
Message-ID: <loom.20071127T022251-95@post.gmane.org>

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> Just shows compat packages need an explicit EOL date or we'll carry
> them forever (some upstreams won't even look at the new version while
> the compat package is available)

On the other hand, removing compat packages which are still needed by important 
packages just because some arbitrary EOL date set much in advance has been 
reached is not a good idea either. Sure, I don't like compat packages either 
and I'm much in favor of porting apps to the new library versions whenever 
possible, even in Fedora-specific patches. But on the other hand, some compat 
packages really _need_ to be there for a very long time ("forever"), such as 
gtk+ (v1) (hopefully that will be obsolete soon, but with imlib (v1) depending 
on it for some strange reason and parts of KDE in turn depending on imlib, I 
don't see that happening right now) or kdelibs3 (KDE 4 has major changes from 
KDE 3, probably even more than KDE 2 and GTK+/GNOME 2 had from their respective 
v1, and definitely a lot more than from KDE 2 to 3). It really all depends on:
* how many changes the new version has (i.e. how easy it is to port 
applications (or other libraries) written for the old version),
* whether there is someone willing to maintain the compat library,
* how many applications use the old library, and how important they are (also 
to some extent whether someone is maintaining the old applications in Fedora),
* how many of these have been ported at the time the compat library is supposed 
to be dropped (which also depends on the previous factors to some extent),
* how easy it is to get the old and new versions of the library to coexist 
(something which was the determining factor against a compat-python),
so there is no easy answer there.

        Kevin Kofler



From jspaleta at gmail.com  Tue Nov 27 03:39:03 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 26 Nov 2007 18:39:03 -0900
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196128360.1275.6.camel@code.and.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>
	<1196128360.1275.6.camel@code.and.org>
Message-ID: <604aa7910711261939j3d78ee57v306dd0af861fb30d@mail.gmail.com>

On Nov 26, 2007 4:52 PM, James Antill <james.antill at redhat.com> wrote:
>  As seth already pointed out, the main innocuous commands are already
> case insensitive. So search, list etc.

You missed by point... is anyone working on extending the search
capabilities so that a user could choose to issue case sensitive
searches among other more extensive search logic like and/or logic for
multiple search terms and things of that nature.

-jef



From james.antill at redhat.com  Tue Nov 27 03:52:50 2007
From: james.antill at redhat.com (James Antill)
Date: Mon, 26 Nov 2007 22:52:50 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <604aa7910711261939j3d78ee57v306dd0af861fb30d@mail.gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter> <474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>
	<1196128360.1275.6.camel@code.and.org>
	<604aa7910711261939j3d78ee57v306dd0af861fb30d@mail.gmail.com>
Message-ID: <1196135570.1275.14.camel@code.and.org>


On Mon, 2007-11-26 at 18:39 -0900, Jeff Spaleta wrote:
> On Nov 26, 2007 4:52 PM, James Antill <james.antill at redhat.com> wrote:
> >  As seth already pointed out, the main innocuous commands are already
> > case insensitive. So search, list etc.
> 
> You missed by point... is anyone working on extending the search
> capabilities so that a user could choose to issue case sensitive
> searches among other more extensive search logic like and/or logic for
> multiple search terms and things of that nature.

 Ahh, I see what you mean, for some reason I read your query as asking
for case insensitive search.

 The 3.2.8 version will come with case sensitive highlighting of search
terms[1], and yum already searches for multiple terms if you give them
(as does yum list).
 But, no, noone is thinking about extending the yum search command
atm. ... although the yum python module has a well defined API for
search.

[1] Although this is mainly an implementation detail that re.escape()
and re.sub() don't allow case insensitive operation, I can't see that
being fixed ... and so could be regarded as a feature :).

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/9fdc195b/attachment.sig>

From rhmercer at yahoo.com  Tue Nov 27 04:23:17 2007
From: rhmercer at yahoo.com (Robert Mercer)
Date: Mon, 26 Nov 2007 20:23:17 -0800 (PST)
Subject: (no subject)
Message-ID: <975931.23050.qm@web81108.mail.mud.yahoo.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071126/f4da6f0b/attachment.htm>

From opensource at till.name  Tue Nov 27 08:32:51 2007
From: opensource at till.name (Till Maas)
Date: Tue, 27 Nov 2007 09:32:51 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474B5671.20604@fedoralinks.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<200711270022.48458.opensource@till.name>
	<474B5671.20604@fedoralinks.org>
Message-ID: <200711270933.00984.opensource@till.name>

On Di November 27 2007, Robert 'Bob' Jensen wrote:
> Till Maas wrote:

> > How about making it case unsensitive only when assume-yes (or -y) is not
> > set? This way the use is always asked whether he really wants this? Or
> > make yum suggest other packages that are available but differ in case,
> > e.g. printing a message like "foo is not available, but there is a
> > package Foo".

> And people complain that yum is slow now... I can't see this speeding
> things up.

This is faster than having to restart yum two more times, once to search for 
the real case and once to install it.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/f9ad4f16/attachment.sig>

From fedora at camperquake.de  Tue Nov 27 08:36:18 2007
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 27 Nov 2007 09:36:18 +0100
Subject: NetworkManager-umts
In-Reply-To: <1196113933.31082.11.camel@localhost.localdomain>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
Message-ID: <20071127093618.111aea34@dhcp03.addix.net>

Hi.

On Mon, 26 Nov 2007 16:52:13 -0500, Dan Williams wrote:

> http://en.wikipedia.org/wiki/Access_Point_Name
> 
> Definitely needed for GPRS/EDGE, not sure if it's needed for UMTS but
> I think it may be, depending on your provider.  In any case, when your
> card falls back to GPRS/EDGE coverage you'll need it.

Hm. For UMTS connections I did not need that, all I set up the connection
via s-c-n, and just entered the number to be dialled, username and password.

I'll see if I can force the phone into GPRS somewhere.



From skvidal at fedoraproject.org  Tue Nov 27 08:37:41 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 27 Nov 2007 03:37:41 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <200711270933.00984.opensource@till.name>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<200711270022.48458.opensource@till.name>
	<474B5671.20604@fedoralinks.org>
	<200711270933.00984.opensource@till.name>
Message-ID: <1196152661.15420.94.camel@cutter>


On Tue, 2007-11-27 at 09:32 +0100, Till Maas wrote:
> On Di November 27 2007, Robert 'Bob' Jensen wrote:
> > Till Maas wrote:
> 
> > > How about making it case unsensitive only when assume-yes (or -y) is not
> > > set? This way the use is always asked whether he really wants this? Or
> > > make yum suggest other packages that are available but differ in case,
> > > e.g. printing a message like "foo is not available, but there is a
> > > package Foo".
> 
> > And people complain that yum is slow now... I can't see this speeding
> > things up.
> 
> This is faster than having to restart yum two more times, once to search for 
> the real case and once to install it.
> 

then don't start it twice:
yum shell
> search blah
> install BlaH
> run

that's it.

-sv






From che666 at gmail.com  Tue Nov 27 09:11:01 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 27 Nov 2007 09:11:01 +0000
Subject: NetworkManager-umts
In-Reply-To: <20071127093618.111aea34@dhcp03.addix.net>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
	<20071127093618.111aea34@dhcp03.addix.net>
Message-ID: <e99d27470711270111q2dadd4c1j236cba9c812cfb91@mail.gmail.com>

On Nov 27, 2007 8:36 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
>
> On Mon, 26 Nov 2007 16:52:13 -0500, Dan Williams wrote:
>
> > http://en.wikipedia.org/wiki/Access_Point_Name
> >
> > Definitely needed for GPRS/EDGE, not sure if it's needed for UMTS but
> > I think it may be, depending on your provider.  In any case, when your
> > card falls back to GPRS/EDGE coverage you'll need it.
>
> Hm. For UMTS connections I did not need that, all I set up the connection
> via s-c-n, and just entered the number to be dialled, username and password.
>
> I'll see if I can force the phone into GPRS somewhere.

maybe there is a fallback somewhere, but definitely one usually needs
an apn for umts connections.

kind regards,
Rudolf Kastl

>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From pmatilai at laiskiainen.org  Tue Nov 27 10:13:37 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 12:13:37 +0200 (EET)
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196114417.15420.60.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org> <1196114417.15420.60.camel@cutter>
Message-ID: <alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>

On Mon, 26 Nov 2007, seth vidal wrote:
>
> On Tue, 2007-11-27 at 02:10 +0530, Rahul Sundaram wrote:
>
>> I understood you think it is a bad idea but if yum already checks first
>> to see if there is a perfect match and then does a more fuzzy search, I
>> don't see a problem with it. There are people who do yum -y remove foo
>> and then blame yum. I think your rm -rf example is similar.
>>
>> There is a real need to solve the problem that OP talks about. It has
>> bitten me more than once including precisely the example cited: Miro. I
>> am not sure what would be the best solution though. Debian does it by
>> enforcing lower case on all their packages IIRC.
>
> Yes and that is what we should do - enforce lower case on all packages.
>
> Policy problems should be handled in policy, not by adding crack to
> software.

Amen. I hate typing WeIRdPaCKageNaMEs as much as the next guy, but 
depsolvers guess package names is not a good idea. Someboy wants it bad 
enough, it should be easy enough to write yum-didyoumean plugin that does 
elaborate guesswork and offers near matches "Did you mean foo?" ala 
Google.

Can we finally have the lower case on package names policy? 
Pretty please?

 	- Panu -



From gbenson at redhat.com  Tue Nov 27 10:54:47 2007
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 27 Nov 2007 10:54:47 +0000
Subject: Debuginfo packages for Java
In-Reply-To: <18251.505.97087.501361@zebedee.pink>
References: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>
	<18251.505.97087.501361@zebedee.pink>
Message-ID: <20071127105447.GB3917@redhat.com>

Andrew Haley wrote:
> Jason L Tibbitts III writes:
> > I'm having problems reviewing a package for some software written
> > in Java.  The problem is that the debuginfo package is generated
> > without any source.
> 
> The fix is to change /usr/lib/python2.5/site-packages/aotcompile.py,
> which doesn't put the right pathnames into the object files.
> 
> I've attached a patch.  gbenson, please look this over.  This is
> my first ever Python hack, so You Have Been Warned.  Input about
> my (doubtless execrable) Python style welcome.

I'd prefer to see this in aot-compile-rpm rather than aotcompile.py,
my reason being that it relies on the fact that the sources are in the
current directory which is true for rpm builds but not necessarily so
otherwise.  Something like the attached?

Cheers,
Gary

PS I don't read fedora-devel-list so please Cc me.
-------------- next part --------------
--- aot-compile-rpm.orig	2007-10-12 09:05:38.000000000 +0100
+++ aot-compile-rpm	2007-11-27 10:41:44.000000000 +0000
@@ -28,6 +28,17 @@
         raise aotcompile.Error, "%s: unexpected output" % cmd
     return dir
 
+def writeSourceList(srcdir, dstpath):
+    def visit(fp, dir, items):
+        for item in items:
+            path = os.path.join(dir, item)
+            if os.path.isfile(path):
+                print >>fp, path
+    dstdir = os.path.dirname(dstpath)
+    if not os.path.isdir(dstdir):
+        os.makedirs(dstdir)
+    os.path.walk(srcdir, visit, open(dstpath, "w"))
+
 def copy(srcdir, dstdir, suffix):
     srcdir = os.path.join(srcdir, suffix.lstrip(os.sep))
     dstdir = os.path.join(dstdir, suffix.lstrip(os.sep))
@@ -72,6 +83,10 @@
             os.path.basename(sys.argv[0]))
         sys.exit(1)
 
+    sourcelist = os.path.join(tmpdir, "sources.list")
+    writeSourceList(os.getcwd(), sourcelist)
+    compiler.gcjflags.append("-fsource-filename=" + sourcelist)
+
     compiler.compile()
     copy(tmpdir, srcdir, dstdir)
 

From pmatilai at laiskiainen.org  Tue Nov 27 11:10:15 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 13:10:15 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1195772447.14235.0.camel@localhost>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
Message-ID: <alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>

On Thu, 22 Nov 2007, Callum Lerwick wrote:

>
> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>> To put it shortly, I going to switch the default rpm queryformat to
>> include package architecture (ie what you get now with
>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
>> so.
>
> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)

FWIW, upstream rpm.org now uses this as the default queryformat and 
supports it in queries etc:
[pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
gimp-2:2.4.1-1.fc8.x86_64

The epoch is the most significant factor in version comparison, might as 
well show it...

 	- Panu -



From benny+usenet at amorsen.dk  Tue Nov 27 11:17:57 2007
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 27 Nov 2007 12:17:57 +0100
Subject: Should "yum install" be case sensitive?
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<20071126214819.52465ae3@lain.camperquake.de>
	<98CE1F4E10689F4EB043AC6AECB753E0713122@ntxbeus19.exchange.xchg>
Message-ID: <m3lk8khr8a.fsf@ursa.amorsen.dk>

>>>>> "KF" == Kautz, Frederick <fkautz at pseudocode.cc> writes:

KF> Not that we are worrying about cygwin... but it turns out that
KF> $ touch TEST $ rm test

KF> The file TEST is removed. rm has everything to do with the
KF> underlying filesystem.

KF> My thought on this topic is... if yum is asked to install
KF> mysql and the package name is actually MySQL... it should make
KF> a suggestion like:

KF> Could not find package 'mysql'. Would you like to install
KF> package 'MySQL' instead? [y/N]

More annoying user interaction. yum is already horrible that way. And
yum -y isn't the answer, because that lets yum go crazy without
considering any consequences.

If yum install foo on an x86_64 installed exactly foo.x86_64 if no
dependencies were needed, that would be perfect. Otherwise it should
just fail and spit out a list of needed dependencies. Then the user
can run it with something like yum install --withdependencies foo, and
it would do the right thing without asking questions. Again, if it
needed to upgrade something, it would fail and give a list of what it
needed.

Unix command line software does what it's told or fails. It doesn't
ask for permission.


/Benny

(Yes I hate the rm -i thing too. mv should fail when asked to
overwrite though.)



From rc040203 at freenet.de  Tue Nov 27 11:24:18 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 27 Nov 2007 12:24:18 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
Message-ID: <1196162658.12310.463.camel@mccallum.corsepiu.local>


On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> On Thu, 22 Nov 2007, Callum Lerwick wrote:
> 
> >
> > On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> >> To put it shortly, I going to switch the default rpm queryformat to
> >> include package architecture (ie what you get now with
> >> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
> >> so.
> >
> > Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> 
> FWIW, upstream rpm.org now uses this as the default queryformat and 
> supports it in queries etc:
> [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> gimp-2:2.4.1-1.fc8.x86_64
-1 

> The epoch is the most significant factor in version comparison, might as 
> well show it...
with this queryformat people now will start bitching on why they can't
find a file of this name - the same applies to "all small letters file
names".

Ralf




From aph at redhat.com  Tue Nov 27 11:27:18 2007
From: aph at redhat.com (Andrew Haley)
Date: Tue, 27 Nov 2007 11:27:18 +0000
Subject: Debuginfo packages for Java
In-Reply-To: <20071127105447.GB3917@redhat.com>
References: <ufahcjfxq5v.fsf@epithumia.math.uh.edu>
	<18251.505.97087.501361@zebedee.pink>
	<20071127105447.GB3917@redhat.com>
Message-ID: <18251.65302.391558.698821@zebedee.pink>

Gary Benson writes:
 > Andrew Haley wrote:
 > > Jason L Tibbitts III writes:
 > > > I'm having problems reviewing a package for some software written
 > > > in Java.  The problem is that the debuginfo package is generated
 > > > without any source.
 > > 
 > > The fix is to change /usr/lib/python2.5/site-packages/aotcompile.py,
 > > which doesn't put the right pathnames into the object files.
 > > 
 > > I've attached a patch.  gbenson, please look this over.  This is
 > > my first ever Python hack, so You Have Been Warned.  Input about
 > > my (doubtless execrable) Python style welcome.
 > 
 > I'd prefer to see this in aot-compile-rpm rather than aotcompile.py,
 > my reason being that it relies on the fact that the sources are in the
 > current directory which is true for rpm builds but not necessarily so
 > otherwise.  Something like the attached?

That works just as well as my patch for the RPM case, but is still
broken for non-RPM builds.  However, I will go along with this if it's
the only way to get the fix in.  We must stop generating bad debuginfo
for gcj-compiled packages.

Andrew.


 > 
 > Cheers,
 > Gary
 > 
 > PS I don't read fedora-devel-list so please Cc me.
 > --- aot-compile-rpm.orig	2007-10-12 09:05:38.000000000 +0100
 > +++ aot-compile-rpm	2007-11-27 10:41:44.000000000 +0000
 > @@ -28,6 +28,17 @@
 >          raise aotcompile.Error, "%s: unexpected output" % cmd
 >      return dir
 >  
 > +def writeSourceList(srcdir, dstpath):
 > +    def visit(fp, dir, items):
 > +        for item in items:
 > +            path = os.path.join(dir, item)
 > +            if os.path.isfile(path):
 > +                print >>fp, path
 > +    dstdir = os.path.dirname(dstpath)
 > +    if not os.path.isdir(dstdir):
 > +        os.makedirs(dstdir)
 > +    os.path.walk(srcdir, visit, open(dstpath, "w"))
 > +
 >  def copy(srcdir, dstdir, suffix):
 >      srcdir = os.path.join(srcdir, suffix.lstrip(os.sep))
 >      dstdir = os.path.join(dstdir, suffix.lstrip(os.sep))
 > @@ -72,6 +83,10 @@
 >              os.path.basename(sys.argv[0]))
 >          sys.exit(1)
 >  
 > +    sourcelist = os.path.join(tmpdir, "sources.list")
 > +    writeSourceList(os.getcwd(), sourcelist)
 > +    compiler.gcjflags.append("-fsource-filename=" + sourcelist)
 > +
 >      compiler.compile()
 >      copy(tmpdir, srcdir, dstdir)
 >  

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From pmatilai at laiskiainen.org  Tue Nov 27 11:30:19 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 13:30:19 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196162658.12310.463.camel@mccallum.corsepiu.local>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
Message-ID: <alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>

On Tue, 27 Nov 2007, Ralf Corsepius wrote:

>
> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>>
>>>
>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>> include package architecture (ie what you get now with
>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
>>>> so.
>>>
>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>>
>> FWIW, upstream rpm.org now uses this as the default queryformat and
>> supports it in queries etc:
>> [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>> gimp-2:2.4.1-1.fc8.x86_64
> -1
>
>> The epoch is the most significant factor in version comparison, might as
>> well show it...
> with this queryformat people now will start bitching on why they can't
> find a file of this name - the same applies to "all small letters file
> names".

I'm changing the default filename too to match this, for this very reason.

 	- Panu -



From mschmidt at redhat.com  Tue Nov 27 11:45:03 2007
From: mschmidt at redhat.com (Michal Schmidt)
Date: Tue, 27 Nov 2007 12:45:03 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196135570.1275.14.camel@code.and.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>
	<1196128360.1275.6.camel@code.and.org>
	<604aa7910711261939j3d78ee57v306dd0af861fb30d@mail.gmail.com>
	<1196135570.1275.14.camel@code.and.org>
Message-ID: <20071127124503.1bb9618b@brian.englab.brq.redhat.com>

On Mon, 26 Nov 2007 22:52:50 -0500
James Antill <james.antill at redhat.com> wrote:

>  The 3.2.8 version will come with case sensitive highlighting of
> search terms[1], and yum already searches for multiple terms if you
> give them (as does yum list).

Yes, but it searches for term1 OR term2. More often than not I'd
prefer AND.

Michal



From rc040203 at freenet.de  Tue Nov 27 11:45:52 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 27 Nov 2007 12:45:52 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
Message-ID: <1196163952.12310.485.camel@mccallum.corsepiu.local>


On Tue, 2007-11-27 at 13:30 +0200, Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> 
> >
> > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> >> On Thu, 22 Nov 2007, Callum Lerwick wrote:
> >>
> >>>
> >>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> >>>> To put it shortly, I going to switch the default rpm queryformat to
> >>>> include package architecture (ie what you get now with
> >>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
> >>>> so.
> >>>
> >>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> >>
> >> FWIW, upstream rpm.org now uses this as the default queryformat and
> >> supports it in queries etc:
> >> [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> >> gimp-2:2.4.1-1.fc8.x86_64
> > -1
> >
> >> The epoch is the most significant factor in version comparison, might as
> >> well show it...
> > with this queryformat people now will start bitching on why they can't
> > find a file of this name - the same applies to "all small letters file
> > names".
> 
> I'm changing the default filename too to match this, for this very reason.

Pardon, but now you are going too far - You have driven things into
absurdity.

Ralf





From rwwyatt01 at gmail.com  Tue Nov 27 11:52:18 2007
From: rwwyatt01 at gmail.com (Randy Wyatt)
Date: Tue, 27 Nov 2007 03:52:18 -0800
Subject: NetworkManager-umts
In-Reply-To: <e99d27470711270111q2dadd4c1j236cba9c812cfb91@mail.gmail.com>
References: <e99d27470711250335m1e337de2n9e316c41a0e0e101@mail.gmail.com>
	<1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
	<20071127093618.111aea34@dhcp03.addix.net>
	<e99d27470711270111q2dadd4c1j236cba9c812cfb91@mail.gmail.com>
Message-ID: <34e52d0c0711270352o5795dc11s2a89ae93ea5b3bd9@mail.gmail.com>

On Nov 27, 2007 1:11 AM, Rudolf Kastl <che666 at gmail.com> wrote:

> On Nov 27, 2007 8:36 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> > Hi.
> >
> > On Mon, 26 Nov 2007 16:52:13 -0500, Dan Williams wrote:
> >
> > > http://en.wikipedia.org/wiki/Access_Point_Name
> > >
> > > Definitely needed for GPRS/EDGE, not sure if it's needed for UMTS but
> > > I think it may be, depending on your provider.  In any case, when your
> > > card falls back to GPRS/EDGE coverage you'll need it.
> >
> > Hm. For UMTS connections I did not need that, all I set up the
> connection
> > via s-c-n, and just entered the number to be dialled, username and
> password.
> >
> > I'll see if I can force the phone into GPRS somewhere.
>
> maybe there is a fallback somewhere, but definitely one usually needs
> an apn for umts connections.
>
> kind regards,
> Rudolf Kastl
>
> It depends on the network setup and whether the mobile operator has
implemented wildcard APN.  also since some APN's are verified against Radius
such as those used by Police,  the user name and password can be very
important.  If there are questions about this, I am happy to help.  I work
for a wireless data card manufacturer..

Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/adbadfda/attachment.htm>

From dtimms at iinet.net.au  Tue Nov 27 12:00:24 2007
From: dtimms at iinet.net.au (David Timms)
Date: Tue, 27 Nov 2007 23:00:24 +1100
Subject: Support TV - Proposal for F9 - enhanced DVB capabilities
In-Reply-To: <20071126180746.GA15244@nostromo.devel.redhat.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>	<4747DD82.20703@iinet.net.au>
	<20071126180746.GA15244@nostromo.devel.redhat.com>
Message-ID: <474C06D8.6000207@iinet.net.au>

Bill Nottingham wrote:
> David Timms (dtimms at iinet.net.au) said: 
>> 1. auto detect / load of drivers:
>> I would be great if the bootup process would detect that the user has a dvb 
>> tuner card and load the driver(s) without intervention {even once}.
>>
>> Currently I can # modprobe dvb_bt8xx   to get the kernel driver loaded.
>> This can be manually inserted into /etc/modprobe.conf , but with the 
>> hal/udev packages, I assume it is possible for the detection of the card on 
>> the pci bus during bootup to be the trigger to cause the module to be 
>> loaded.
> 
> Assuming the driver is correctly written, it should happen automatically.
> Failure to automatically load for any PCI/USB device is a driver bug.

Bill: After trying to sort through udev|hal to undestand what should or 
could happen, I noticed your reply; since it is a PCI device then it 
should just work already.

Certainly, the /dev/ nodes seem to be created according to the default 
udev rules, but only on manual driver modprobe.

Looking further I notice that > modinfo dvb_bt8xx lists:
filename: 
/lib/modules/2.6.23.1-21.fc7/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko
license:        GPL
author:         Florian Schirmer <jolt at tuxbox.org>
description:    Bt8xx based DVB adapter driver
depends:        bttv,bt878,i2c-core,dvb-core
vermagic:       2.6.23.1-21.fc7 SMP mod_unload 686 4KSTACKS
parm:           debug:Turn on/off debugging (default:off). (int)

Whereas for a network driver > modinfo tulip:
filename: 
/lib/modules/2.6.23.1-21.fc7/kernel/drivers/net/tulip/tulip.ko
version:        1.1.15
license:        GPL
description:    Digital 21*4* Tulip ethernet driver
author:         The Linux Kernel Team
srcversion:     54B741F794FD4612A7C5AFD
alias:          pci:v00001414d00000002sv*sd*bc*sc*i*
alias:          pci:v000014EAd0000AB08sv*sd*bc*sc*i*
alias:          pci:v000010B7d00009300sv*sd*bc*sc*i*
alias:          pci:v000017B3d0000AB08sv*sd*bc*sc*i*
alias:          pci:v00001737d0000AB08sv*sd*bc*sc*i*
...

Is it simply that these alias definitions need to be added to the 
driver; I might be able to do that myself ?

And that whenever newer boards are released using chip X that the driver 
for that chip needs to have a new alias added ?

Or is this issue more complex - and hence best to bugzilla it ? {where ?}

Is there other reasons that may have caused the driver author to not try 
to autoload - eg timing or ordering issues ?

DaveT.



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 27 12:30:03 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 27 Nov 2007 13:30:03 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
Message-ID: <20071127133003.6f32805c.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 27 Nov 2007 12:13:37 +0200 (EET), Panu Matilainen wrote:

> Can we finally have the lower case on package names policy? 
> Pretty please?

I remember we've discussed that long ago. Who remembers the details?



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 27 12:34:27 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 27 Nov 2007 13:34:27 +0100
Subject: Two Problems
In-Reply-To: <474B7699.10600@gmail.com>
References: <20071126232327.24DB373375@hormel.redhat.com>
	<474B7699.10600@gmail.com>
Message-ID: <20071127133427.d8faac2a.mschwendt.tmp0701.nospam@arcor.de>

On Mon, 26 Nov 2007 17:44:57 -0800, Eric Work wrote:

> Michael Schwendt & Tom "spot" Callaway,
> 
> >> 1. After updating the package source and spec file for gtkdatabox for 
> >> FC-5 and FC-6 and attempting a build, I realized that the pango version 
> >> available in those releases is too old.  Upstream only mentioned a 
> >> dependency on gtk+ 2.8 not pango 1.16.  I will inform upstream also but 
> >> how should I resolve this.  The question is how should I revert back to 
> >> an older version of the package?
> > 
> > If it built fine in the buildsys, we can delete the build from the
> > needsign repo and don't push it. In CVS, however, you can simply revert to
> > the files from the previous package release. Look at something like "cvs
> > log gtkdatabox.spec" for the tags you've applied before, check out the
> > older package with a given tag and commit the files to CVS HEAD again.
> 
> Michael, The build did not succeed so that made things a little simpler. 
>   I did as you suggested and updated CVS HEAD with the older version. 
> That was a pretty simple fix.  I also noticed that running "make build" 
> in any branch prior to FC-6 fails.  I'm guessing this is expected.

Yes, FC-5 and older have reached end-of-life. FC-6 will reach EOL
in early December.



From opensource at till.name  Tue Nov 27 12:43:25 2007
From: opensource at till.name (Till Maas)
Date: Tue, 27 Nov 2007 13:43:25 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196152661.15420.94.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<200711270933.00984.opensource@till.name>
	<1196152661.15420.94.camel@cutter>
Message-ID: <200711271343.30461.opensource@till.name>

On Di November 27 2007, seth vidal wrote:

> then don't start it twice:
> yum shell
>
> > search blah
> > install BlaH
> > run
>
> that's it.

Ah, this looks usefull. Is it possible to use --skip-broken update 
or --security update in yum shell?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/e991da89/attachment.sig>

From pmatilai at laiskiainen.org  Tue Nov 27 12:44:22 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 14:44:22 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196163952.12310.485.camel@mccallum.corsepiu.local>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<1196163952.12310.485.camel@mccallum.corsepiu.local>
Message-ID: <alpine.DEB.0.9999.0711271435170.14586@gotcha.dreamhost.com>

On Tue, 27 Nov 2007, Ralf Corsepius wrote:

>
> On Tue, 2007-11-27 at 13:30 +0200, Panu Matilainen wrote:
>> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
>>
>>>
>>> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>>>> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>>>>
>>>>>
>>>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>>>> include package architecture (ie what you get now with
>>>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
>>>>>> so.
>>>>>
>>>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>>>>
>>>> FWIW, upstream rpm.org now uses this as the default queryformat and
>>>> supports it in queries etc:
>>>> [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>>>> gimp-2:2.4.1-1.fc8.x86_64
>>> -1
>>>
>>>> The epoch is the most significant factor in version comparison, might as
>>>> well show it...
>>> with this queryformat people now will start bitching on why they can't
>>> find a file of this name - the same applies to "all small letters file
>>> names".
>>
>> I'm changing the default filename too to match this, for this very reason.
>
> Pardon, but now you are going too far - You have driven things into
> absurdity.

IMO the biggest absurdity here is the traditional behavior of hiding the 
epoch. Why should rpm try to [*] hide the most significant factor in it's 
version comparison?

[*] The epoch "leaks out" in failed dependency errors, forcing you to 
figure out what the heck this X: is and how to query it out of 
packages/rpmdb.

 	- Panu -



From laurent.rineau__fedora at normalesup.org  Tue Nov 27 12:51:31 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Tue, 27 Nov 2007 13:51:31 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
Message-ID: <200711271351.31664@rineau.tsetse>

On Tuesday 27 November 2007 12:30:19 Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> >> gimp-2:2.4.1-1.fc8.x86_64
> >
> > -1
> >
> >> The epoch is the most significant factor in version comparison, might as
> >> well show it...
> >
> > with this queryformat people now will start bitching on why they can't
> > find a file of this name - the same applies to "all small letters file
> > names".
>
> I'm changing the default filename too to match this, for this very reason.

Please no. Do not use ":" in filenames. It will prevent a simple backup to a 
FAT filesystem.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 27 12:53:57 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 27 Nov 2007 13:53:57 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196162658.12310.463.camel@mccallum.corsepiu.local>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
Message-ID: <20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 27 Nov 2007 12:24:18 +0100, Ralf Corsepius wrote:

> 
> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> > On Thu, 22 Nov 2007, Callum Lerwick wrote:
> > 
> > >
> > > On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> > >> To put it shortly, I going to switch the default rpm queryformat to
> > >> include package architecture (ie what you get now with
> > >> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
> > >> so.
> > >
> > > Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> > 
> > FWIW, upstream rpm.org now uses this as the default queryformat and 
> > supports it in queries etc:
> > [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> > gimp-2:2.4.1-1.fc8.x86_64
> -1 

Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
so please don't make it explicit in file names. This only pours gasoline
into the fire. RPM dependency hell is back, stronger than ever.

> > The epoch is the most significant factor in version comparison, might as 
> > well show it...
> with this queryformat people now will start bitching on why they can't
> find a file of this name - the same applies to "all small letters file
> names".

This is half-baked so far and only adds a lot of confusion.

-- 
[1] Requires: foo > 4.0   and foo-1:0.9-1.fc8.noarch.rpm is sufficient.



From jnovy at redhat.com  Tue Nov 27 12:59:14 2007
From: jnovy at redhat.com (Jindrich Novy)
Date: Tue, 27 Nov 2007 13:59:14 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <200711271351.31664@rineau.tsetse>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
Message-ID: <20071127125913.GA2888@dhcp-lab-186.brq.redhat.com>

On Tue, Nov 27, 2007 at 01:51:31PM +0100, Laurent Rineau wrote:
> On Tuesday 27 November 2007 12:30:19 Panu Matilainen wrote:
> > On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> > > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> > >> gimp-2:2.4.1-1.fc8.x86_64
> > >
> > > -1
> > >
> > >> The epoch is the most significant factor in version comparison, might as
> > >> well show it...
> > >
> > > with this queryformat people now will start bitching on why they can't
> > > find a file of this name - the same applies to "all small letters file
> > > names".
> >
> > I'm changing the default filename too to match this, for this very reason.
> 
> Please no. Do not use ":" in filenames. It will prevent a simple backup to a 
> FAT filesystem.
> 

This is not a valid reason. Epoch is essential for dependency
resolution/comparison so that it belongs to filename IMNSHO.
You can tar the rpms to an archive so that you can use FAT fs
for backup.

+1 for epoch in filename/default query format.

Jindrich

-- 
Jindrich Novy <jnovy at redhat.com>   http://people.redhat.com/jnovy/



From abo at kth.se  Tue Nov 27 13:06:37 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Tue, 27 Nov 2007 14:06:37 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
Message-ID: <1196168797.9005.48.camel@home.alexander.bostrom.net>

m?n 2007-11-26 klockan 20:50 +0100 skrev Micha? Bentkowski:
> So my proposal is to make "yum install" (and probably "yum update" as
> well) case insensitive. 

Isn't this best left to the GUI tools (pirut, PackageKit, whatever)?

In those tools it's natural to search for a package and then click on
the result and install it. This is the equivalent of "search miro;
install Miro" in yum shell, but with a GUI that actually encourages the
use of the search functionality.

/abo



From j.w.r.degoede at hhs.nl  Tue Nov 27 13:16:58 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 27 Nov 2007 14:16:58 +0100
Subject: Review swappies
Message-ID: <474C18CA.6060504@hhs.nl>

Hi All,

Below is a list of packages of mine awaiting review, anyone interested in 
swapping a review for a packages of his?

  * bolzplatz2006 - Slam Soccer 2006 is a funny football game in 3D-comic-style
    https://bugzilla.redhat.com/show_bug.cgi?id=283721

  * urbanterror - FPS best be described as a Hollywood tactical shooter
    https://bugzilla.redhat.com/show_bug.cgi?id=385771

  * amoebax - Action-Puzzle Game
    https://bugzilla.redhat.com/show_bug.cgi?id=398591

  * pioneers - Turnbased board strategy game (colonize an island
    https://bugzilla.redhat.com/show_bug.cgi?id=400911


Thanks & Regards,

Hans



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 27 13:25:09 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 27 Nov 2007 14:25:09 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127125913.GA2888@dhcp-lab-186.brq.redhat.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<20071127125913.GA2888@dhcp-lab-186.brq.redhat.com>
Message-ID: <20071127142509.e6138c62.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 27 Nov 2007 13:59:14 +0100, Jindrich Novy wrote:

> Epoch is essential for dependency
> resolution/comparison so that it belongs to filename IMNSHO.

Other package details [such as Capabilities, virtual packages, but also
Requires, Conflicts, Obsoletes] are essential, too, but need not pollute
the file name either. Nowadays we have tools to do the resolving.



From nicolas.mailhot at laposte.net  Tue Nov 27 13:25:39 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Nov 2007 14:25:39 +0100 (CET)
Subject: Changing the rpm default queryformat to include arch
Message-ID: <7453.192.54.193.53.1196169939.squirrel@rousalka.dyndns.org>


Le Mar 27 novembre 2007 13:59, Jindrich Novy a ?crit :
> On Tue, Nov 27, 2007 at 01:51:31PM +0100, Laurent Rineau wrote:

>> Please no. Do not use ":" in filenames. It will prevent a simple
>> backup to a
>> FAT filesystem.
>>
>
> This is not a valid reason.

It's a valid reason for not using : as separator.
It's not a valid reason to continue the hidden magic epoch policy.

Regards,

-- 
Nicolas Mailhot



From pp at ee.oulu.fi  Tue Nov 27 13:27:42 2007
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Tue, 27 Nov 2007 15:27:42 +0200
Subject: NetworkManager-umts
In-Reply-To: <34e52d0c0711270352o5795dc11s2a89ae93ea5b3bd9@mail.gmail.com>
References: <1196092700.4202.40.camel@localhost.localdomain>
	<20071126184755.GF5532@redhat.com>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
	<20071127093618.111aea34@dhcp03.addix.net>
	<e99d27470711270111q2dadd4c1j236cba9c812cfb91@mail.gmail.com>
	<34e52d0c0711270352o5795dc11s2a89ae93ea5b3bd9@mail.gmail.com>
Message-ID: <20071127132742.GA27731@ee.oulu.fi>

On Tue, Nov 27, 2007 at 03:52:18AM -0800, Randy Wyatt wrote:
>    It depends on the network setup and whether the mobile operator has
>    implemented wildcard APN.  also since some APN's are verified against
>    Radius such as those used by Police,  the user name and password can be
>    very important.  If there are questions about this, I am happy to help.  I
>    work for a wireless data card manufacturer..
Also you can set the default APN in the phone, typically. 

Favourite failure mode of GPRS not working in Linux btw, having a 10.x.x.x
network on eth0, pppd wants to use 10.6.6.6 as the remote end (doesn't
really matter what it is) -> fail, and very hard to figure
out why it doesn't work.

And pppd might need noaccomp etc.

My point, an "advanced" tab for configuring the thing is unfortunately
necessary even if atdt*99*# usually works.

-- 
Pekka Pietikainen



From che666 at gmail.com  Tue Nov 27 13:30:18 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 27 Nov 2007 13:30:18 +0000
Subject: Should "yum install" be case sensitive?
In-Reply-To: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
Message-ID: <e99d27470711270530g67f1a3cdm750ce860f982c333@mail.gmail.com>

On Nov 26, 2007 7:50 PM, Micha? Bentkowski <mr.ecik at gmail.com> wrote:
> Hi!
> Recently, a funny thing happened on Polish Fedora forum. Some users
> were talking about Miro but rest of them weren't able even to install
> that... After some time it turned out that they tried to type "yum
> install miro" instead of "yum install Miro".
> So my question is the same as in the topic: should "yum install" be
> case sensitive?
> I haven't checked but I'm quite sure (correct me if I'm wrong) that
> there are no packages in repo whose names differ in letter size.
> What's more: "yum list" command is case insensitive and there's
> nothing wrong with it, is there? I know that you can say that these
> users I wrote about in the beginning should have used "yum list" first
> and then they would have found out why things went wrong but it makes
> a need to type more and more commands.
> "yum install" gives a summary what packages are going to be installed
> so if a user wanted to run "Foo", but not "foo" she/he could break the
> installation.
> Besides, pressing SHIFT key could be painful ;-)
> So my proposal is to make "yum install" (and probably "yum update" as
> well) case insensitive.
> Just think about it :)

quite funny that this mixed and upper case package name discussion
flames up again. if you look hard on the net you will find a few
emails on various lists of mine pointing out the usability drawbacks
of the upper/mixed case situation like 5 years ago.

kind regards,
Rudolf Kastl

p.s. i share your view ;)

>
> Regards.
>
> --
> Micha? Bentkowski
> mr.ecik at gmail.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From rwwyatt01 at gmail.com  Tue Nov 27 13:36:57 2007
From: rwwyatt01 at gmail.com (Randy Wyatt)
Date: Tue, 27 Nov 2007 05:36:57 -0800
Subject: NetworkManager-umts
In-Reply-To: <20071127132742.GA27731@ee.oulu.fi>
References: <1196092700.4202.40.camel@localhost.localdomain>
	<1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
	<20071127093618.111aea34@dhcp03.addix.net>
	<e99d27470711270111q2dadd4c1j236cba9c812cfb91@mail.gmail.com>
	<34e52d0c0711270352o5795dc11s2a89ae93ea5b3bd9@mail.gmail.com>
	<20071127132742.GA27731@ee.oulu.fi>
Message-ID: <34e52d0c0711270536j7caf72aak743d1bc3338fc2ce@mail.gmail.com>

.
> Also you can set the default APN in the phone, typically.


Yes,  as specified in 27.007 for GSM/UMTS cards, the command to do so is
AT+CGDCONT=cid,"PDPtype","APN name"

cid can range from 1 to 16 on most cards.

>
>
> Favourite failure mode of GPRS not working in Linux btw, having a 10.x.x.x
> network on eth0, pppd wants to use 10.6.6.6 as the remote end (doesn't
> really matter what it is) -> fail, and very hard to figure
> out why it doesn't work.


Does your network support WINS/NetBIOS ?  I have seen this problem with
10.11.12.13 and 10.11.12.14 being hardcoded in Qualcomm based chipsets,  and
this is an NV item that can be changed .

>
>
> And pppd might need noaccomp etc.
>
> My point, an "advanced" tab for configuring the thing is unfortunately
> necessary even if atdt*99*# usually works.
>
> --
> Pekka Pietikainen
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/fcde0bbf/attachment.htm>

From lesmikesell at gmail.com  Tue Nov 27 13:48:36 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 27 Nov 2007 07:48:36 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
Message-ID: <474C2034.8050000@gmail.com>

Panu Matilainen wrote:
> On Mon, 26 Nov 2007, seth vidal wrote:
>>
>> On Tue, 2007-11-27 at 02:10 +0530, Rahul Sundaram wrote:
>>
>>> I understood you think it is a bad idea but if yum already checks first
>>> to see if there is a perfect match and then does a more fuzzy search, I
>>> don't see a problem with it. There are people who do yum -y remove foo
>>> and then blame yum. I think your rm -rf example is similar.
>>>
>>> There is a real need to solve the problem that OP talks about. It has
>>> bitten me more than once including precisely the example cited: Miro. I
>>> am not sure what would be the best solution though. Debian does it by
>>> enforcing lower case on all their packages IIRC.
>>
>> Yes and that is what we should do - enforce lower case on all packages.
>>
>> Policy problems should be handled in policy, not by adding crack to
>> software.
> 
> Amen. I hate typing WeIRdPaCKageNaMEs as much as the next guy, but 
> depsolvers guess package names is not a good idea. Someboy wants it bad 
> enough, it should be easy enough to write yum-didyoumean plugin that 
> does elaborate guesswork and offers near matches "Did you mean foo?" ala 
> Google.
> 
> Can we finally have the lower case on package names policy? Pretty please?

Kind of late in the game to ask for that without providing a means to 
keep working as the change is implemented by each packager separately, 
isn't it?  The existing dependencies aren't going to all be fixed on the 
same day.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From skvidal at fedoraproject.org  Tue Nov 27 13:56:07 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 27 Nov 2007 08:56:07 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071127124503.1bb9618b@brian.englab.brq.redhat.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter> <474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<604aa7910711261533i1618525coa66e32bd8ce506ab@mail.gmail.com>
	<1196128360.1275.6.camel@code.and.org>
	<604aa7910711261939j3d78ee57v306dd0af861fb30d@mail.gmail.com>
	<1196135570.1275.14.camel@code.and.org>
	<20071127124503.1bb9618b@brian.englab.brq.redhat.com>
Message-ID: <1196171767.15420.100.camel@cutter>


On Tue, 2007-11-27 at 12:45 +0100, Michal Schmidt wrote:
> On Mon, 26 Nov 2007 22:52:50 -0500
> James Antill <james.antill at redhat.com> wrote:
> 
> >  The 3.2.8 version will come with case sensitive highlighting of
> > search terms[1], and yum already searches for multiple terms if you
> > give them (as does yum list).
> 
> Yes, but it searches for term1 OR term2. More often than not I'd
> prefer AND.

actually, it doesn't.

yum search foo bar baz

will do:

return all packages matching all 3
return all packages matching any 2
return all packages matching 1

in that order.

-sv




From skvidal at fedoraproject.org  Tue Nov 27 13:56:42 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 27 Nov 2007 08:56:42 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <200711271343.30461.opensource@till.name>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<200711270933.00984.opensource@till.name>
	<1196152661.15420.94.camel@cutter>
	<200711271343.30461.opensource@till.name>
Message-ID: <1196171802.15420.102.camel@cutter>


On Tue, 2007-11-27 at 13:43 +0100, Till Maas wrote:
> On Di November 27 2007, seth vidal wrote:
> 
> > then don't start it twice:
> > yum shell
> >
> > > search blah
> > > install BlaH
> > > run
> >
> > that's it.
> 
> Ah, this looks usefull. Is it possible to use --skip-broken update 
> or --security update in yum shell?
> 

just pass the options on the command line beforehand
yum --skip-broken --security shell

-sv




From paul at all-the-johnsons.co.uk  Tue Nov 27 13:58:39 2007
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Tue, 27 Nov 2007 13:58:39 +0000
Subject: Backing up a nearly dead HDD
Message-ID: <20071127135839.M32436@all-the-johnsons.co.uk>

Hi,

It looks like my problem with readahead isn't readahead!

The drive which has my home directories seems to have a problem. If I log in
as root (please don't bitslap me yet!), and from the command line look at the
home directories, I can see paul, becki, richard and lost+found which is fine
as they're supposed to be there.

If I then try to look at the contents of /home/paul, it takes ages and the
hard drive makes funny noises, so I'm thinking it's at the end of it's life
more or less.

fsck shows some bits and pieces, but essentially, it's not picking up any
problems.

Is there a way I can copy everything from one drive to another and keep the
permissions from a dodgy drive to a working one? cp -ar seems an option, but
it takes a while!

TTFN

Paul

--
Get your free @ukpost.com account now
http://www.ukpost.com/



From aph at redhat.com  Tue Nov 27 14:11:42 2007
From: aph at redhat.com (Andrew Haley)
Date: Tue, 27 Nov 2007 14:11:42 +0000
Subject: Backing up a nearly dead HDD
In-Reply-To: <20071127135839.M32436@all-the-johnsons.co.uk>
References: <20071127135839.M32436@all-the-johnsons.co.uk>
Message-ID: <18252.9630.44711.661364@zebedee.pink>

Paul F. Johnson writes:
 > Hi,
 > 
 > It looks like my problem with readahead isn't readahead!
 > 
 > The drive which has my home directories seems to have a problem. If I log in
 > as root (please don't bitslap me yet!), and from the command line look at the
 > home directories, I can see paul, becki, richard and lost+found which is fine
 > as they're supposed to be there.
 > 
 > If I then try to look at the contents of /home/paul, it takes ages and the
 > hard drive makes funny noises, so I'm thinking it's at the end of it's life
 > more or less.
 > 
 > fsck shows some bits and pieces, but essentially, it's not picking up any
 > problems.
 > 
 > Is there a way I can copy everything from one drive to another and keep the
 > permissions from a dodgy drive to a working one? cp -ar seems an option, but
 > it takes a while!

The traditional fast way is "dump -f - | restore -f -" [*] but I'm not
sure dump handles extended attributes correctly.

Andrew.

[*] The drive should NOT be mounted R/W.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903



From tcallawa at redhat.com  Tue Nov 27 14:20:33 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 27 Nov 2007 09:20:33 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <1196173233.3229.34.camel@localhost.localdomain>


On Tue, 2007-11-27 at 13:53 +0100, Michael Schwendt wrote:
> On Tue, 27 Nov 2007 12:24:18 +0100, Ralf Corsepius wrote:
> 
> > 
> > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> > > On Thu, 22 Nov 2007, Callum Lerwick wrote:
> > > 
> > > >
> > > > On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> > > >> To put it shortly, I going to switch the default rpm queryformat to
> > > >> include package architecture (ie what you get now with
> > > >> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
> > > >> so.
> > > >
> > > > Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> > > 
> > > FWIW, upstream rpm.org now uses this as the default queryformat and 
> > > supports it in queries etc:
> > > [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> > > gimp-2:2.4.1-1.fc8.x86_64
> > -1 
> 
> Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
> so please don't make it explicit in file names. This only pours gasoline
> into the fire. RPM dependency hell is back, stronger than ever.

For what its worth, I agree. Epoch in the file name is a bad idea.

~spot



From sundaram at fedoraproject.org  Tue Nov 27 14:21:04 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Nov 2007 19:51:04 +0530
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474C2034.8050000@gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>	<1196114417.15420.60.camel@cutter>	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<474C2034.8050000@gmail.com>
Message-ID: <474C27D0.5020400@fedoraproject.org>

Les Mikesell wrote:

> 
> Kind of late in the game to ask for that without providing a means to 
> keep working as the change is implemented by each packager separately, 
> isn't it?  The existing dependencies aren't going to all be fixed on the 
> same day.

The method was already provided earlier in this thread. Just add a 
additional provides with all lowercase in between the transition period.

Rahul



From paskalis at di.uoa.gr  Tue Nov 27 14:40:54 2007
From: paskalis at di.uoa.gr (Sarantis Paskalis)
Date: Tue, 27 Nov 2007 16:40:54 +0200
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071127133003.6f32805c.mschwendt.tmp0701.nospam@arcor.de>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<20071127133003.6f32805c.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071127144054.GA27740@gallagher.di.uoa.gr>

On Tue, Nov 27, 2007 at 01:30:03PM +0100, Michael Schwendt wrote:
> On Tue, 27 Nov 2007 12:13:37 +0200 (EET), Panu Matilainen wrote:
> 
> > Can we finally have the lower case on package names policy? 
> > Pretty please?
> 
> I remember we've discussed that long ago. Who remembers the details?

http://www.redhat.com/archives/fedora-maintainers/2006-December/msg00110.html

with a link to the relevant section of the IRC log.  The bottom line 
seemed to be that it needed more discussion.

-- Sarantis



From Michael_E_Brown at dell.com  Tue Nov 27 14:46:29 2007
From: Michael_E_Brown at dell.com (Michael E Brown)
Date: Tue, 27 Nov 2007 08:46:29 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474C27D0.5020400@fedoraproject.org>
References: <20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<474C2034.8050000@gmail.com> <474C27D0.5020400@fedoraproject.org>
Message-ID: <20071127144629.GA14671@humbolt.us.dell.com>

On Tue, Nov 27, 2007 at 07:51:04PM +0530, Rahul Sundaram wrote:
> Les Mikesell wrote:
> 
> >
> >Kind of late in the game to ask for that without providing a means to 
> >keep working as the change is implemented by each packager separately, 
> >isn't it?  The existing dependencies aren't going to all be fixed on the 
> >same day.
> 
> The method was already provided earlier in this thread. Just add a 
> additional provides with all lowercase in between the transition period.

Better: change rpm name to lower-case and use a provides: tag for the
old mixed-case name.

You can also do a repoquery to find all packages that require: the old
name and switch them over.
--
Michael



From pmatilai at laiskiainen.org  Tue Nov 27 14:59:59 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 16:59:59 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196173233.3229.34.camel@localhost.localdomain>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
Message-ID: <alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>

On Tue, 27 Nov 2007, Tom \spot\ Callaway wrote:
>
> On Tue, 2007-11-27 at 13:53 +0100, Michael Schwendt wrote:
>> On Tue, 27 Nov 2007 12:24:18 +0100, Ralf Corsepius wrote:
>>
>>>
>>> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>>>> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>>>>
>>>>>
>>>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>>>> include package architecture (ie what you get now with
>>>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
>>>>>> so.
>>>>>
>>>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>>>>
>>>> FWIW, upstream rpm.org now uses this as the default queryformat and
>>>> supports it in queries etc:
>>>> [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>>>> gimp-2:2.4.1-1.fc8.x86_64
>>> -1
>>
>> Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
>> so please don't make it explicit in file names. This only pours gasoline
>> into the fire. RPM dependency hell is back, stronger than ever.
>
> For what its worth, I agree. Epoch in the file name is a bad idea.

Why do you think it's bad - because of the ':' used as separator, or 
"just because" (epochs are evil and all that)?

Currently you can store different versions and releases of a package 
within a directory without them clashing - why is it ok for packages with 
different epochs to clash in that situation?

 	- Panu -



From valent.turkovic at gmail.com  Tue Nov 27 15:01:01 2007
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Tue, 27 Nov 2007 16:01:01 +0100
Subject: exchange email in fedora 8
In-Reply-To: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
References: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
Message-ID: <64b14b300711270701u6ddec7beu54450e4487511420@mail.gmail.com>

How common is exchange on corporate desktops? Is fedora targeting
corporate desktops?

On 11/26/07, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=296671
> With latest updates I still see this bug.
>
> I work at an ISP company and we use Exchange for our email servers
> (unfortunately) and I have used Fedora Core 6 as my work desktop for
> over a year or so.
> I would like to update my system (ie. clean install) to Fedora 8 but I
> need 100% working exchange email client.
> This is a really big issues with anybody who needs an up to date linux
> desktop because this bug currently prevents me from migrating to new
> Fedora 8!
>
> Can you please suggest some way I can use exchange on fedora 8 and so
> that GAL works? Some beta version of your evolution packages? Maybe
> some older versions of evolution?
>
> Thank you,
> Valent Turkovic.
>
> --
> http://kernelreloaded.blog385.com/
> linux, blog, anime, spirituality, windsurf, wireless
> registered as user #367004 with the Linux Counter, http://counter.li.org.
> ICQ: 2125241, Skype: valent.turkovic
>


-- 
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic



From pbrobinson at gmail.com  Tue Nov 27 15:07:48 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 27 Nov 2007 15:07:48 +0000
Subject: exchange email in fedora 8
In-Reply-To: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
References: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
Message-ID: <5256d0b0711270707p723a8513i31529d9693f6ea90@mail.gmail.com>

> https://bugzilla.redhat.com/show_bug.cgi?id=296671
> With latest updates I still see this bug.
>
> I work at an ISP company and we use Exchange for our email servers
> (unfortunately) and I have used Fedora Core 6 as my work desktop for
> over a year or so.
> I would like to update my system (ie. clean install) to Fedora 8 but I
> need 100% working exchange email client.
> This is a really big issues with anybody who needs an up to date linux
> desktop because this bug currently prevents me from migrating to new
> Fedora 8!
>
> Can you please suggest some way I can use exchange on fedora 8 and so
> that GAL works? Some beta version of your evolution packages? Maybe
> some older versions of evolution?

I'm not seeing any issues with GAL on Fedora8 talking to Exchange
2003. Its the first time in the 3 years that I've been extensively
using Evolution as an Exchange client that the GAL has worked somewhat
reliably. Just about every previous release it would randomly crash
after 2-3 lookups. Don't get me wrong its not perfect yet, but where
as I use to get a 3-4 crashes a day at best and on some releases I
would just outright not configure the GAL lookups at all so it would
be slightly stable, this release in GNOME 2.20 seems a lot better than
any previous ones that I've seen.

Regards,
Peter



From pbrobinson at gmail.com  Tue Nov 27 15:08:31 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 27 Nov 2007 15:08:31 +0000
Subject: exchange email in fedora 8
In-Reply-To: <64b14b300711270701u6ddec7beu54450e4487511420@mail.gmail.com>
References: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
	<64b14b300711270701u6ddec7beu54450e4487511420@mail.gmail.com>
Message-ID: <5256d0b0711270708h2d3f0c84lb81481cd43c95965@mail.gmail.com>

> How common is exchange on corporate desktops? Is fedora targeting
> corporate desktops?

Exchange is extremely common in the corporate world.

Peter



From tcallawa at redhat.com  Tue Nov 27 15:09:51 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 27 Nov 2007 10:09:51 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
Message-ID: <1196176191.3229.43.camel@localhost.localdomain>


On Tue, 2007-11-27 at 16:59 +0200, Panu Matilainen wrote:

> > For what its worth, I agree. Epoch in the file name is a bad idea.
> 
> Why do you think it's bad - because of the ':' used as separator, or 
> "just because" (epochs are evil and all that)?
> 
> Currently you can store different versions and releases of a package 
> within a directory without them clashing - why is it ok for packages with 
> different epochs to clash in that situation?

Well, using : as a separator seems like a bad idea, but I really don't
want to encourage epoch use. Its a last resort hack to fix a broken
package when there is no other way to ensure safe upgrades. If new
packagers start seeing it show up in a far more visible way, people will
think that they need to use it by default.

~spot




From jameshubbard at gmail.com  Tue Nov 27 15:16:13 2007
From: jameshubbard at gmail.com (James Hubbard)
Date: Tue, 27 Nov 2007 10:16:13 -0500
Subject: exchange email in fedora 8
In-Reply-To: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
References: <64b14b300711260213s612029few7bd0c557fd36959f@mail.gmail.com>
Message-ID: <f3ddc6d30711270716n220347fm463ad803e269afdb@mail.gmail.com>

On Nov 26, 2007 5:13 AM, Valent Turkovic <valent.turkovic at gmail.com> wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=296671
> With latest updates I still see this bug.
>
> I work at an ISP company and we use Exchange for our email servers
> (unfortunately) and I have used Fedora Core 6 as my work desktop for
> over a year or so.
> I would like to update my system (ie. clean install) to Fedora 8 but I
> need 100% working exchange email client.
> This is a really big issues with anybody who needs an up to date linux
> desktop because this bug currently prevents me from migrating to new
> Fedora 8!

I've used evolution with the exchange connector on FC6 and F7.  I
don't use the gloabl address list because I've never gotten it to
work.  If you need the address list your best bet is to export the
list in a format that can be imported into the evolution contacts
manager.  Yes it's a pain to do that.

As to your other question, yes it's very common.  I would equate it to
a cold that you can't get rid of. I'm just being negative, because I
have to use it with the exchange connector.  No chance for IMAP or
other stuff.



From pmatilai at laiskiainen.org  Tue Nov 27 15:19:15 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 17:19:15 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196176191.3229.43.camel@localhost.localdomain>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<1196176191.3229.43.camel@localhost.localdomain>
Message-ID: <alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>

On Tue, 27 Nov 2007, Tom \spot\ Callaway wrote:
> On Tue, 2007-11-27 at 16:59 +0200, Panu Matilainen wrote:
>
>>> For what its worth, I agree. Epoch in the file name is a bad idea.
>>
>> Why do you think it's bad - because of the ':' used as separator, or
>> "just because" (epochs are evil and all that)?
>>
>> Currently you can store different versions and releases of a package
>> within a directory without them clashing - why is it ok for packages with
>> different epochs to clash in that situation?
>
> Well, using : as a separator seems like a bad idea, but I really don't
> want to encourage epoch use. Its a last resort hack to fix a broken
> package when there is no other way to ensure safe upgrades. If new
> packagers start seeing it show up in a far more visible way, people will
> think that they need to use it by default.

If limiting visibility of the epochs is the argument, then why is it ok 
for end user tools such as pirut (not to mention yum itself and all 
related tools) to show them?

 	- Panu -



From cra at WPI.EDU  Tue Nov 27 15:24:36 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 27 Nov 2007 10:24:36 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<1196176191.3229.43.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
Message-ID: <20071127152436.GH25455@angus.ind.WPI.EDU>

On Tue, Nov 27, 2007 at 05:19:15PM +0200, Panu Matilainen wrote:
> >Well, using : as a separator seems like a bad idea, but I really don't
> >want to encourage epoch use. Its a last resort hack to fix a broken
> >package when there is no other way to ensure safe upgrades. If new
> >packagers start seeing it show up in a far more visible way, people will
> >think that they need to use it by default.
> 
> If limiting visibility of the epochs is the argument, then why is it ok 
> for end user tools such as pirut (not to mention yum itself and all 
> related tools) to show them?

I agree.  If limiting epoch visibility is the argument, we should be 
showing them in the low-level tools (rpm, yum) but not the high-level 
tools (pirut, pup).  Not that I agree that we should be limiting their 
visibility at all.



From atkac at redhat.com  Tue Nov 27 15:25:35 2007
From: atkac at redhat.com (Adam Tkac)
Date: Tue, 27 Nov 2007 16:25:35 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127022448.GB24257@angus.ind.WPI.EDU>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
Message-ID: <20071127152535.GA7102@traged.englab.brq.redhat.com>

On Mon, Nov 26, 2007 at 09:24:48PM -0500, Chuck Anderson wrote:
> Fedora 8 shipped with an BIND 9.5.0a6, recently updated to 9.5.0a7.  
> The release announcement for BIND says:
> 
> BIND 9.5.0a7 is a alpha release for BIND 9.5.0.
> 
> 	This is a technology preview of new functionality to be be
> 	released in BIND 9.5.0.  New APIs are not yet frozen.
> 
> Is this an appropriate release to be putting in a stable Fedora 
> release?  I've encounted a segfault in this version, which I've 
> reported here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=400461
> 
> I'm concerned about the policies which allow unstable software in 
> stable Fedora releases.  Is it considered acceptable/encouraged to 
> have alpha versions of software in the stable release?  Is there any 
> policy?
> 
> Thanks.

I've put this software to F8 because it has nice new features. Some
bugs is tax for them. Additionally I don't think that users use newest
Fedora on important servers and 9.5 will come into beta stage very
soon.

Adam

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From pp at ee.oulu.fi  Tue Nov 27 15:28:25 2007
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Tue, 27 Nov 2007 17:28:25 +0200
Subject: NetworkManager-umts
In-Reply-To: <34e52d0c0711270536j7caf72aak743d1bc3338fc2ce@mail.gmail.com>
References: <1196106105.9720.3.camel@localhost.localdomain>
	<20071126205111.3a19be68@lain.camperquake.de>
	<1196111743.31082.0.camel@localhost.localdomain>
	<20071126222552.20bc9e65@lain.camperquake.de>
	<1196113933.31082.11.camel@localhost.localdomain>
	<20071127093618.111aea34@dhcp03.addix.net>
	<e99d27470711270111q2dadd4c1j236cba9c812cfb91@mail.gmail.com>
	<34e52d0c0711270352o5795dc11s2a89ae93ea5b3bd9@mail.gmail.com>
	<20071127132742.GA27731@ee.oulu.fi>
	<34e52d0c0711270536j7caf72aak743d1bc3338fc2ce@mail.gmail.com>
Message-ID: <20071127152825.GA16885@ee.oulu.fi>

On Tue, Nov 27, 2007 at 05:36:57AM -0800, Randy Wyatt wrote:
>      .
>      Also you can set the default APN in the phone, typically.
> 
>    Yes,  as specified in 27.007 for GSM/UMTS cards, the command to do so is
>    AT+CGDCONT=cid,"PDPtype","APN name"
Or go Settings/Connection/GPRS/Access point and type it in :P
(on Nokia Series 60). Great when you're only given the option 
to change the phone number you want to dial into by your OS.

>    Does your network support WINS/NetBIOS ?  I have seen this problem with
>    [2]10.11.12.13 and [3]10.11.12.14 being hardcoded in Qualcomm based
>    chipsets,  and this is an NV item that can be changed .
I hope not on the provider end :P  But you never know. I think
the fix was just giving " :1.2.3.4  " or whatnot on the pppd command line,
and that makes it force the remote end to be 1.2.3.4. The address only 
gets in the routing table so it doesn't really matter what gets used.

-- 
Pekka Pietikainen



From herrold at owlriver.com  Tue Nov 27 15:28:52 2007
From: herrold at owlriver.com (R P Herrold)
Date: Tue, 27 Nov 2007 10:28:52 -0500 (EST)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<1196176191.3229.43.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
Message-ID: <alpine.LRH.0.99999.0711271025250.4548@arj.bjyevire.pbz>

On Tue, 27 Nov 2007, Panu Matilainen wrote:

> If limiting visibility of the epochs is the argument, then why is it ok for 
> end user tools such as pirut (not to mention yum itself and all related 
> tools) to show them?

gui tools != *nix pipeline tools -- if this is an unknown 
distinction, we are all doomed.

Epoch, like or not, has a checkered history; Arch is even 
stinkier with multilib.

Change the silly default macro if one wishes, but be prepared 
to support explaining why it is different for many years to 
come.

Heavens, we still see questions about the rpm -ba -> rpmbuild 
transition, 5 years later.

-- Russ Herrold



From rwwyatt01 at gmail.com  Tue Nov 27 15:34:20 2007
From: rwwyatt01 at gmail.com (Randy Wyatt)
Date: Tue, 27 Nov 2007 07:34:20 -0800
Subject: Backing up a nearly dead HDD
In-Reply-To: <18252.9630.44711.661364@zebedee.pink>
References: <20071127135839.M32436@all-the-johnsons.co.uk>
	<18252.9630.44711.661364@zebedee.pink>
Message-ID: <34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>

Have you used smartmon tools ?  These actually give me the best results for
determining the number of errors encountered by a drive.

>
>  >
>  > Is there a way I can copy everything from one drive to another and keep
> the
>  > permissions from a dodgy drive to a working one? cp -ar seems an
> option, but
>  > it takes a while!
>
> The traditional fast way is "dump -f - | restore -f -" [*] but I'm not
> sure dump handles extended attributes correctly.
>
> Andrew.



Why not use dd?  if you are replacing a drive with a similar drive, dd is
perfect.

>
>
> [*] The drive should NOT be mounted R/W.
>
> --
> Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
> Berkshire, SL4 1TE, UK
> Registered in England and Wales No. 3798903
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/673363f6/attachment.htm>

From pp at ee.oulu.fi  Tue Nov 27 15:36:52 2007
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Tue, 27 Nov 2007 17:36:52 +0200
Subject: Backing up a nearly dead HDD
In-Reply-To: <18252.9630.44711.661364@zebedee.pink>
References: <20071127135839.M32436@all-the-johnsons.co.uk>
	<18252.9630.44711.661364@zebedee.pink>
Message-ID: <20071127153652.GB16885@ee.oulu.fi>

On Tue, Nov 27, 2007 at 02:11:42PM +0000, Andrew Haley wrote:
>  > Is there a way I can copy everything from one drive to another and keep the
>  > permissions from a dodgy drive to a working one? cp -ar seems an option, but
>  > it takes a while!
> 
> The traditional fast way is "dump -f - | restore -f -" [*] but I'm not
> sure dump handles extended attributes correctly.
> 
I had a broken drive once too, and I used LVM2 to migrate to a new drive.
First I added a new drive with enough space to the volume group, removed the
broken one from it and it (slowly) managed to move every block it could 
to the new drive.

Then I ran fsck -y on it, and after a long time most of the data was still
there.

Not too long afterwards I got 3 500GB drives and had my very own 1 TB 
RAID5 at home.

Anything that works at the filesystem level (tar, cp) seems to be pretty
painful with broken harddrives since they take very long to finally raise
their hands up and move on.

I think there's a "don't try too hard" version of dd that's intended for
broken media, you could also do a byte-to-byte copy with that (vs. LVM2) and
fsck afterwards.

-- 
Pekka Pietikainen



From belegdol at gmail.com  Tue Nov 27 15:32:39 2007
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 27 Nov 2007 16:32:39 +0100
Subject: Orphaning thinkfinger
Message-ID: <474C3897.2060406@gmail.com>

Hello there,

I am hereby dropping maintenance of thinkfinger. There are currently 3
bugs currently opened against it (#343271, #394181 and #356921), one of
which is multiarch conflict due to doxygen weirdness, second one if
fedora-specific and eventually the last one is claimed to be
fedora-specific by upstream (this was questioned by is left without
answer so far).
I am dropping the package since upstream does not seem to be very
responsive most of the time, and due to my lack of coding skills I can't
fix the bugs myself. I'll release the pkgdb ownership later today.

Regards,
Julian



From jdieter at gmail.com  Tue Nov 27 15:43:12 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Tue, 27 Nov 2007 17:43:12 +0200
Subject: Backing up a nearly dead HDD
In-Reply-To: <34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
References: <20071127135839.M32436@all-the-johnsons.co.uk>
	<18252.9630.44711.661364@zebedee.pink>
	<34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
Message-ID: <1196178192.4145.1.camel@jndwidescreen.lesbg.loc>

On Tue, 2007-11-27 at 07:34 -0800, Randy Wyatt wrote:

>          >
>          > Is there a way I can copy everything from one drive to
>         another and keep the
>          > permissions from a dodgy drive to a working one? cp -ar
>         seems an option, but
>          > it takes a while! 
>         
>         
>         The traditional fast way is "dump -f - | restore -f -" [*] but
>         I'm not
>         sure dump handles extended attributes correctly.
>         
>         Andrew.
> 
> 
> Why not use dd?  if you are replacing a drive with a similar drive, dd
> is perfect. 

I'd suggest dd_rescue.  When it hits a bad sector, it lowers its block
size and retries, thus (hopefully) retrieving more data.

Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/5f6cf687/attachment.sig>

From P at draigBrady.com  Tue Nov 27 15:41:29 2007
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Tue, 27 Nov 2007 15:41:29 +0000
Subject: Backing up a nearly dead HDD
In-Reply-To: <34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
References: <20071127135839.M32436@all-the-johnsons.co.uk>	<18252.9630.44711.661364@zebedee.pink>
	<34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
Message-ID: <474C3AA9.4080401@draigBrady.com>

Randy Wyatt wrote:
> Why not use dd?  if you are replacing a drive with a similar drive, dd
> is perfect.

dd is not great when used with a failing drive.
Try ddrescue instead.

P?draig.



From jima at beer.tclug.org  Tue Nov 27 15:46:17 2007
From: jima at beer.tclug.org (Jima)
Date: Tue, 27 Nov 2007 09:46:17 -0600 (CST)
Subject: Backing up a nearly dead HDD
In-Reply-To: <34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
References: <20071127135839.M32436@all-the-johnsons.co.uk>
	<18252.9630.44711.661364@zebedee.pink>
	<34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0711270936490.17671@beer.tclug.org>

On Tue, 27 Nov 2007, Randy Wyatt wrote:
> Have you used smartmon tools ?  These actually give me the best results for
> determining the number of errors encountered by a drive.

  Closing the barn door after the cows have gotten run over by a semi, but 
yes, a good idea. :-)

> Why not use dd?  if you are replacing a drive with a similar drive, dd is
> perfect.

  dd tends to not work well on iffy media.  I'd advocate using dd_rescue 
rather than dd; it handles errors better.

  I usually use the freezer trick on dying drives.  Basically, you put the 
drive in a plastic zippered storage bag (i.e., Ziploc), and put it in the 
freezer.  Wait until it's pretty well cold, then pull it, plug it in, and 
try and get the data off ASAP.  (I don't understand the finer 
thermodynamics of it, but I believe it has something to do with the cold 
contracting metal parts, or compensating for heat-related issues. 
Something.)  I usually use rsync (if it's ext3) or dd_rescue (if it's 
NTFS/FAT, or I otherwise need a bit-by-bit copy) to get the bits off.
  Use at your own risk, your mileage may vary.  It's worked for me (quite a 
few times), maybe it'll work for you.

  Good luck!

      Jima



From caillon at redhat.com  Tue Nov 27 15:50:42 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 27 Nov 2007 16:50:42 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>	<1195772447.14235.0.camel@localhost>	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>	<1196162658.12310.463.camel@mccallum.corsepiu.local>	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>	<1196173233.3229.34.camel@localhost.localdomain>	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>	<1196176191.3229.43.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
Message-ID: <474C3CD2.8000700@redhat.com>

On 11/27/2007 04:19 PM, Panu Matilainen wrote:
> If limiting visibility of the epochs is the argument, then why is it ok 
> for end user tools such as pirut (not to mention yum itself and all 
> related tools) to show them?

PackageKit doesn't.



From jima at beer.tclug.org  Tue Nov 27 15:52:17 2007
From: jima at beer.tclug.org (Jima)
Date: Tue, 27 Nov 2007 09:52:17 -0600 (CST)
Subject: Backing up a nearly dead HDD
In-Reply-To: <474C3AA9.4080401@draigBrady.com>
References: <20071127135839.M32436@all-the-johnsons.co.uk>
	<18252.9630.44711.661364@zebedee.pink>
	<34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>
	<474C3AA9.4080401@draigBrady.com>
Message-ID: <Pine.LNX.4.64.0711270948420.17671@beer.tclug.org>

On Tue, 27 Nov 2007, P?draig Brady wrote:
> Randy Wyatt wrote:
>> Why not use dd?  if you are replacing a drive with a similar drive, dd
>> is perfect.
>
> dd is not great when used with a failing drive.
> Try ddrescue instead.

  s/dd/dd_/ -- contrary to logic, ddrescue and dd_rescue are, in fact, 
different projects, and it appears we only have dd_rescue in Fedora. 
(Interestingly enough, they both seem to be currently maintained, and 
ddrescue was actually last updated 11 days ago.  Huh.)

      Jima

From a.badger at gmail.com  Tue Nov 27 15:57:18 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 27 Nov 2007 07:57:18 -0800
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127152535.GA7102@traged.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
Message-ID: <474C3E5E.7060900@gmail.com>

Adam Tkac wrote:
 > I've put this software to F8 because it has nice new features. Some
 > bugs is tax for them.

 > 9.5 will come into beta stage very soon.

These two are quite valid reasons that you as maintainer are the person 
best qualified to make a decision about.  Thank you for providing them!

> I don't think that users use newest
> Fedora on important servers

This one, however, is not a reason to use in making these decisions. 
People may want to use the newest Fedora on their important servers and 
if so, we want them to be able to.  This is something we should strive 
for consciously even if subconsciously we decide to let another feature 
slip in ;-)

-Toshio



From cra at WPI.EDU  Tue Nov 27 16:03:02 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 27 Nov 2007 11:03:02 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127152535.GA7102@traged.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
Message-ID: <20071127160302.GI25455@angus.ind.WPI.EDU>

On Tue, Nov 27, 2007 at 04:25:35PM +0100, Adam Tkac wrote:
> I've put this software to F8 because it has nice new features. Some
> bugs is tax for them. Additionally I don't think that users use newest
> Fedora on important servers and 9.5 will come into beta stage very
> soon.

I use the newest Fedora on important servers.  They were running FC6 
before, and the EOL is approaching soon.  I'd rather upgrade once to 
F8 now rather than F7 now and then again to F8 when F9 is released.  I 
guess that was a bad decision on my part, but I've never had major 
problems on servers with the latest Fedora before.  I've been testing 
F8 as Rawhide for a while now, so I thought it was ready for my 
servers.  Unfortunately, I didn't test BIND--slap my wrist for that 
one.  Of course, who knows if I would have encountered this problem in 
a test server--it may be related to the load one puts on the server 
that would never have been seen in a test environment.

I don't mind beta software and release candidates of software in a 
stable Fedora release--heck lots of software stays in that phase for a 
long long time (ISC dhcpd for example).  But alpha software I think is 
pushing it a bit too far.  This is just my opinion, and I will work 
around whatever problems I cause for myself by using the latest Fedora 
on my important servers, but the lack of a policy on this makes it 
hard for sysadmins to choose correctly.  Now it seems that the choice 
should be "always run the previous Fedora release because the newest 
one might introduce new software that is considered alpha quality by 
upstream".

It is a fine line to walk on stability vs. new features.  Fedora is 
about being on the leading edge, sure.  But bleeding edge should be 
reserved for Rawhide and Test releases.  Especially for software as 
important as BIND and DHCP.



From caillon at redhat.com  Tue Nov 27 16:03:05 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 27 Nov 2007 17:03:05 +0100
Subject: Orphaning thinkfinger
In-Reply-To: <474C3897.2060406@gmail.com>
References: <474C3897.2060406@gmail.com>
Message-ID: <474C3FB9.9000204@redhat.com>

On 11/27/2007 04:32 PM, Julian Sikorski wrote:
> Hello there,
> 
> I am hereby dropping maintenance of thinkfinger. There are currently 3
> bugs currently opened against it (#343271, #394181 and #356921), one of
> which is multiarch conflict due to doxygen weirdness, second one if
> fedora-specific and eventually the last one is claimed to be
> fedora-specific by upstream (this was questioned by is left without
> answer so far).
> I am dropping the package since upstream does not seem to be very
> responsive most of the time, and due to my lack of coding skills I can't
> fix the bugs myself. I'll release the pkgdb ownership later today.

I'll take it for now.



From atkac at redhat.com  Tue Nov 27 16:04:36 2007
From: atkac at redhat.com (Adam Tkac)
Date: Tue, 27 Nov 2007 17:04:36 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474C3E5E.7060900@gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<474C3E5E.7060900@gmail.com>
Message-ID: <20071127160436.GA8321@traged.englab.brq.redhat.com>

On Tue, Nov 27, 2007 at 07:57:18AM -0800, Toshio Kuratomi wrote:
> Adam Tkac wrote:
> > I've put this software to F8 because it has nice new features. Some
> > bugs is tax for them.
>
> > 9.5 will come into beta stage very soon.
>
> These two are quite valid reasons that you as maintainer are the person 
> best qualified to make a decision about.  Thank you for providing them!
>
>> I don't think that users use newest
>> Fedora on important servers
>
> This one, however, is not a reason to use in making these decisions. People 
> may want to use the newest Fedora on their important servers and if so, we 
> want them to be able to.  This is something we should strive for 
> consciously even if subconsciously we decide to let another feature slip in 
> ;-)

Generally you have to choose between stability and features. And I've
chosen features in this case...

Adam

>
> -Toshio
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 27 16:05:17 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 27 Nov 2007 17:05:17 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071127144054.GA27740@gallagher.di.uoa.gr>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<20071127133003.6f32805c.mschwendt.tmp0701.nospam@arcor.de>
	<20071127144054.GA27740@gallagher.di.uoa.gr>
Message-ID: <20071127170517.e5c84864.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 27 Nov 2007 16:40:54 +0200, Sarantis Paskalis wrote:

> On Tue, Nov 27, 2007 at 01:30:03PM +0100, Michael Schwendt wrote:
> > On Tue, 27 Nov 2007 12:13:37 +0200 (EET), Panu Matilainen wrote:
> > 
> > > Can we finally have the lower case on package names policy? 
> > > Pretty please?
> > 
> > I remember we've discussed that long ago. Who remembers the details?
> 
> http://www.redhat.com/archives/fedora-maintainers/2006-December/msg00110.html
> 
> with a link to the relevant section of the IRC log.  The bottom line 
> seemed to be that it needed more discussion.

Hmmm...
I thought about a time even longer ago. Either around fedora.us or
when revisiting existing guidelines for Fedora Extras 3.



From belegdol at gmail.com  Tue Nov 27 16:07:13 2007
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 27 Nov 2007 17:07:13 +0100
Subject: Orphaning thinkfinger
In-Reply-To: <474C3FB9.9000204@redhat.com>
References: <474C3897.2060406@gmail.com> <474C3FB9.9000204@redhat.com>
Message-ID: <474C40B1.3020908@gmail.com>

Christopher Aillon pisze:
> On 11/27/2007 04:32 PM, Julian Sikorski wrote:
>> Hello there,
>>
>> I am hereby dropping maintenance of thinkfinger. There are currently 3
>> bugs currently opened against it (#343271, #394181 and #356921), one of
>> which is multiarch conflict due to doxygen weirdness, second one if
>> fedora-specific and eventually the last one is claimed to be
>> fedora-specific by upstream (this was questioned by is left without
>> answer so far).
>> I am dropping the package since upstream does not seem to be very
>> responsive most of the time, and due to my lack of coding skills I can't
>> fix the bugs myself. I'll release the pkgdb ownership later today.
> 
> I'll take it for now.
> 
Thanks,
Julian



From mschwendt.tmp0701.nospam at arcor.de  Tue Nov 27 16:12:38 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Tue, 27 Nov 2007 17:12:38 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
Message-ID: <20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>

On Tue, 27 Nov 2007 16:59:59 +0200 (EET), Panu Matilainen wrote:

> >>>> FWIW, upstream rpm.org now uses this as the default queryformat and
> >>>> supports it in queries etc:
> >>>> [pmatilai at localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> >>>> gimp-2:2.4.1-1.fc8.x86_64
> >>> -1
> >>
> >> Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
> >> so please don't make it explicit in file names. This only pours gasoline
> >> into the fire. RPM dependency hell is back, stronger than ever.
> >
> > For what its worth, I agree. Epoch in the file name is a bad idea.
> 
> Why do you think it's bad - because of the ':' used as separator, or 
> "just because" (epochs are evil and all that)?
> 
> Currently you can store different versions and releases of a package 
> within a directory without them clashing - why is it ok for packages with 
> different epochs to clash in that situation?

Because no packager should ever bump %epoch without bumping %release.
Rule of thumb: New build => new release.

And yes, if %version changes, you update (i.e. reset) %release, too,
usually.



From david at lovesunix.net  Tue Nov 27 16:16:17 2007
From: david at lovesunix.net (David Nielsen)
Date: Tue, 27 Nov 2007 17:16:17 +0100
Subject: Orphaning thinkfinger
In-Reply-To: <474C3897.2060406@gmail.com>
References: <474C3897.2060406@gmail.com>
Message-ID: <1196180177.3068.5.camel@dawkins>


tir, 27 11 2007 kl. 16:32 +0100, skrev Julian Sikorski:
> Hello there,
> 
> I am hereby dropping maintenance of thinkfinger. There are currently 3
> bugs currently opened against it (#343271, #394181 and #356921), one of
> which is multiarch conflict due to doxygen weirdness, second one if
> fedora-specific and eventually the last one is claimed to be
> fedora-specific by upstream (this was questioned by is left without
> answer so far).
> I am dropping the package since upstream does not seem to be very
> responsive most of the time, and due to my lack of coding skills I can't
> fix the bugs myself. I'll release the pkgdb ownership later today.

I thought thinkfinger was largely going to be replaced by Daniel Drakes
libfprint.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt underskrevet brevdel
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/e40bc026/attachment.sig>

From belegdol at gmail.com  Tue Nov 27 16:17:40 2007
From: belegdol at gmail.com (Julian Sikorski)
Date: Tue, 27 Nov 2007 17:17:40 +0100
Subject: Orphaning thinkfinger
In-Reply-To: <1196180177.3068.5.camel@dawkins>
References: <474C3897.2060406@gmail.com> <1196180177.3068.5.camel@dawkins>
Message-ID: <474C4324.8080304@gmail.com>

David Nielsen pisze:
> tir, 27 11 2007 kl. 16:32 +0100, skrev Julian Sikorski:
>> Hello there,
>>
>> I am hereby dropping maintenance of thinkfinger. There are currently 3
>> bugs currently opened against it (#343271, #394181 and #356921), one of
>> which is multiarch conflict due to doxygen weirdness, second one if
>> fedora-specific and eventually the last one is claimed to be
>> fedora-specific by upstream (this was questioned by is left without
>> answer so far).
>> I am dropping the package since upstream does not seem to be very
>> responsive most of the time, and due to my lack of coding skills I can't
>> fix the bugs myself. I'll release the pkgdb ownership later today.
> 
> I thought thinkfinger was largely going to be replaced by Daniel Drakes
> libfprint.
> 
> - David
> 
Yes, it is going to be.



From P at draigBrady.com  Tue Nov 27 16:23:44 2007
From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Tue, 27 Nov 2007 16:23:44 +0000
Subject: Backing up a nearly dead HDD
In-Reply-To: <Pine.LNX.4.64.0711270948420.17671@beer.tclug.org>
References: <20071127135839.M32436@all-the-johnsons.co.uk>	<18252.9630.44711.661364@zebedee.pink>	<34e52d0c0711270734n1d2d658bl92c3f76d865d1b6b@mail.gmail.com>	<474C3AA9.4080401@draigBrady.com>
	<Pine.LNX.4.64.0711270948420.17671@beer.tclug.org>
Message-ID: <474C4490.1000807@draigBrady.com>

Jima wrote:
> On Tue, 27 Nov 2007, P?draig Brady wrote:
>> Randy Wyatt wrote:
>>> Why not use dd?  if you are replacing a drive with a similar drive, dd
>>> is perfect.
>>
>> dd is not great when used with a failing drive.
>> Try ddrescue instead.
> 
>  s/dd/dd_/ -- contrary to logic, ddrescue and dd_rescue are, in fact,
> different projects, and it appears we only have dd_rescue in Fedora.
> (Interestingly enough, they both seem to be currently maintained, and
> ddrescue was actually last updated 11 days ago.  Huh.)

FFS.

Antonio can you enlighten us on why you chose this confusing name?
Could you merge with the original project to alleviate confusion in the future?
What does ddrescue do differently to dd_rescue?
Couldn't we merge this functionality into dd anyway?

P?draig.





From atkac at redhat.com  Tue Nov 27 16:27:19 2007
From: atkac at redhat.com (Adam Tkac)
Date: Tue, 27 Nov 2007 17:27:19 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127160302.GI25455@angus.ind.WPI.EDU>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071127160302.GI25455@angus.ind.WPI.EDU>
Message-ID: <20071127162719.GA8756@traged.englab.brq.redhat.com>

On Tue, Nov 27, 2007 at 11:03:02AM -0500, Chuck Anderson wrote:
> On Tue, Nov 27, 2007 at 04:25:35PM +0100, Adam Tkac wrote:
> > I've put this software to F8 because it has nice new features. Some
> > bugs is tax for them. Additionally I don't think that users use newest
> > Fedora on important servers and 9.5 will come into beta stage very
> > soon.
> 
> I use the newest Fedora on important servers.  They were running FC6 
> before, and the EOL is approaching soon.  I'd rather upgrade once to 
> F8 now rather than F7 now and then again to F8 when F9 is released.  I 
> guess that was a bad decision on my part, but I've never had major 
> problems on servers with the latest Fedora before.  I've been testing 
> F8 as Rawhide for a while now, so I thought it was ready for my 
> servers.  Unfortunately, I didn't test BIND--slap my wrist for that 
> one.  Of course, who knows if I would have encountered this problem in 
> a test server--it may be related to the load one puts on the server 
> that would never have been seen in a test environment.

I'm using 9.5 on my machine long time and I didn't found discussed
problem (#400461)

> I don't mind beta software and release candidates of software in a 
> stable Fedora release--heck lots of software stays in that phase for a 
> long long time (ISC dhcpd for example).  But alpha software I think is 
> pushing it a bit too far.  This is just my opinion, and I will work 
> around whatever problems I cause for myself by using the latest Fedora 
> on my important servers, but the lack of a policy on this makes it 
> hard for sysadmins to choose correctly.  Now it seems that the choice 
> should be "always run the previous Fedora release because the newest 
> one might introduce new software that is considered alpha quality by 
> upstream".

As I wrote above BIND will come to beta very soon. And your bug is
first more important issue that I've got reported since F8 final.

> 
> It is a fine line to walk on stability vs. new features.  Fedora is 
> about being on the leading edge, sure.  But bleeding edge should be 
> reserved for Rawhide and Test releases.  Especially for software as 
> important as BIND and DHCP.
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From mclasen at redhat.com  Tue Nov 27 16:28:57 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 27 Nov 2007 11:28:57 -0500
Subject: Orphaning thinkfinger
In-Reply-To: <474C4324.8080304@gmail.com>
References: <474C3897.2060406@gmail.com> <1196180177.3068.5.camel@dawkins>
	<474C4324.8080304@gmail.com>
Message-ID: <1196180937.3547.2.camel@localhost.localdomain>


On Tue, 2007-11-27 at 17:17 +0100, Julian Sikorski wrote:
> David Nielsen pisze:
> > tir, 27 11 2007 kl. 16:32 +0100, skrev Julian Sikorski:
> >> Hello there,
> >>
> >> I am hereby dropping maintenance of thinkfinger. There are currently 3
> >> bugs currently opened against it (#343271, #394181 and #356921), one of
> >> which is multiarch conflict due to doxygen weirdness, second one if
> >> fedora-specific and eventually the last one is claimed to be
> >> fedora-specific by upstream (this was questioned by is left without
> >> answer so far).
> >> I am dropping the package since upstream does not seem to be very
> >> responsive most of the time, and due to my lack of coding skills I can't
> >> fix the bugs myself. I'll release the pkgdb ownership later today.
> > 
> > I thought thinkfinger was largely going to be replaced by Daniel Drakes
> > libfprint.
> > 
> > - David
> > 
> Yes, it is going to be.
> 

But we still need a maintainer for f7 and f8...



From jkeating at redhat.com  Tue Nov 27 16:29:14 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Nov 2007 11:29:14 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <20071127112914.264fa595@redhat.com>

On Tue, 27 Nov 2007 17:12:38 +0100
Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:

> Because no packager should ever bump %epoch without bumping %release.
> Rule of thumb: New build => new release.

In fact, koji enforces this.  Koji stores builds based on n-v-r, not
n-e-v-r, so if you only just bump epoch, koji will give you an error.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/de100df9/attachment.sig>

From lkundrak at redhat.com  Tue Nov 27 16:37:47 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 27 Nov 2007 17:37:47 +0100
Subject: Review swappies
In-Reply-To: <474C18CA.6060504@hhs.nl>
References: <474C18CA.6060504@hhs.nl>
Message-ID: <1196181467.26555.55.camel@localhost.localdomain>


On Tue, 2007-11-27 at 14:16 +0100, Hans de Goede wrote:
> Hi All,
> 
> Below is a list of packages of mine awaiting review, anyone interested in 
> swapping a review for a packages of his?

I recommend swapping package reviews with Hans to everyone. There are
not many people who make such perfect and impressive packages as Hans!

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From caillon at redhat.com  Tue Nov 27 16:43:11 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Tue, 27 Nov 2007 17:43:11 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196130595.3229.20.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
Message-ID: <474C491F.2030204@redhat.com>

On 11/27/2007 03:29 AM, Tom "spot" Callaway wrote:
> On Mon, 2007-11-26 at 21:24 -0500, Chuck Anderson wrote:
> 
>> I'm concerned about the policies which allow unstable software in 
>> stable Fedora releases.  Is it considered acceptable/encouraged to 
>> have alpha versions of software in the stable release?  Is there any 
>> policy?
> 
> There is no policy, its up to the individual maintainer to use their
> best judgement as to what should be included.

It's hard to make judgements without having any criteria to judge upon. 
  We don't need to have a strict policy, but I think it would be useful 
to have some loose guidelines.



From lesmikesell at gmail.com  Tue Nov 27 16:51:26 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 27 Nov 2007 10:51:26 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474C27D0.5020400@fedoraproject.org>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>	<1196114417.15420.60.camel@cutter>	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>	<474C2034.8050000@gmail.com>
	<474C27D0.5020400@fedoraproject.org>
Message-ID: <474C4B0E.8070304@gmail.com>

Rahul Sundaram wrote:
> Les Mikesell wrote:
> 
>>
>> Kind of late in the game to ask for that without providing a means to 
>> keep working as the change is implemented by each packager separately, 
>> isn't it?  The existing dependencies aren't going to all be fixed on 
>> the same day.
> 
> The method was already provided earlier in this thread. Just add a 
> additional provides with all lowercase in between the transition period.

And the advantage of distributing all this work and making it be done in 
a certain order over just forcing case insensitivity would be?

--
   Les Mikesell
     lesmikesell at gmail.com



From sundaram at fedoraproject.org  Tue Nov 27 16:51:04 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Nov 2007 22:21:04 +0530
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474C4B0E.8070304@gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>	<1196114417.15420.60.camel@cutter>	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>	<474C2034.8050000@gmail.com>	<474C27D0.5020400@fedoraproject.org>
	<474C4B0E.8070304@gmail.com>
Message-ID: <474C4AF8.5090809@fedoraproject.org>

Les Mikesell wrote:
> Rahul Sundaram wrote:
>> Les Mikesell wrote:
>>
>>>
>>> Kind of late in the game to ask for that without providing a means to 
>>> keep working as the change is implemented by each packager 
>>> separately, isn't it?  The existing dependencies aren't going to all 
>>> be fixed on the same day.
>>
>> The method was already provided earlier in this thread. Just add a 
>> additional provides with all lowercase in between the transition period.
> 
> And the advantage of distributing all this work and making it be done in 
> a certain order over just forcing case insensitivity would be?

Forcing case insensitivity in what? The packages or yum? Seth Vidal 
already explained his view point that case insensitivity should be 
decided as policy within Fedora packaging guidelines and I have given 
you one example of how to transition over if that decision is made since 
you asked whether it is too late to do so.

Rahul



From jkeating at redhat.com  Tue Nov 27 16:55:08 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Nov 2007 11:55:08 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474C4B0E.8070304@gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<474C2034.8050000@gmail.com> <474C27D0.5020400@fedoraproject.org>
	<474C4B0E.8070304@gmail.com>
Message-ID: <20071127115508.3da14863@redhat.com>

On Tue, 27 Nov 2007 10:51:26 -0600
Les Mikesell <lesmikesell at gmail.com> wrote:

> And the advantage of distributing all this work and making it be done
> in a certain order over just forcing case insensitivity would be?

If you care about things being found with lower case, the best way to
accomplish that is to make everything lower case.  Otherwise you're
going to have differences in yum, vs rpm, vs ls, vs http, vs....

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/d9c6a218/attachment.sig>

From lesmikesell at gmail.com  Tue Nov 27 17:13:07 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Tue, 27 Nov 2007 11:13:07 -0600
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071127115508.3da14863@redhat.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>	<20071126145534.7df4d8d3@redhat.com>	<20071126210313.28ca9ca2@lain.camperquake.de>	<1196107574.15420.51.camel@cutter>	<474B2A40.7030800@fedoraproject.org>	<1196108870.15420.55.camel@cutter>	<474B2F22.7020102@fedoraproject.org>	<1196114417.15420.60.camel@cutter>	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>	<474C2034.8050000@gmail.com>
	<474C27D0.5020400@fedoraproject.org>	<474C4B0E.8070304@gmail.com>
	<20071127115508.3da14863@redhat.com>
Message-ID: <474C5023.80303@gmail.com>

Jesse Keating wrote:
> On Tue, 27 Nov 2007 10:51:26 -0600
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
>> And the advantage of distributing all this work and making it be done
>> in a certain order over just forcing case insensitivity would be?
> 
> If you care about things being found with lower case, the best way to
> accomplish that is to make everything lower case.  Otherwise you're
> going to have differences in yum, vs rpm, vs ls, vs http, vs....

Agreed, but that's clearly not the case and this isn't a new concept.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From jkeating at redhat.com  Tue Nov 27 17:15:40 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Nov 2007 12:15:40 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <474C5023.80303@gmail.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<474C2034.8050000@gmail.com> <474C27D0.5020400@fedoraproject.org>
	<474C4B0E.8070304@gmail.com> <20071127115508.3da14863@redhat.com>
	<474C5023.80303@gmail.com>
Message-ID: <20071127121540.02a79c78@redhat.com>

On Tue, 27 Nov 2007 11:13:07 -0600
Les Mikesell <lesmikesell at gmail.com> wrote:

> Agreed, but that's clearly not the case and this isn't a new concept.

"what" is not the case?  And "what" isn't a new concept?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/25b63193/attachment.sig>

From notting at redhat.com  Tue Nov 27 17:23:15 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 27 Nov 2007 12:23:15 -0500
Subject: Support TV - Proposal for F9 - enhanced DVB capabilities
In-Reply-To: <474C06D8.6000207@iinet.net.au>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<4747DD82.20703@iinet.net.au>
	<20071126180746.GA15244@nostromo.devel.redhat.com>
	<474C06D8.6000207@iinet.net.au>
Message-ID: <20071127172315.GA14296@nostromo.devel.redhat.com>

David Timms (dtimms at iinet.net.au) said: 
> Looking further I notice that > modinfo dvb_bt8xx lists:
> filename: 
> /lib/modules/2.6.23.1-21.fc7/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko
> license:        GPL
> author:         Florian Schirmer <jolt at tuxbox.org>
> description:    Bt8xx based DVB adapter driver
> depends:        bttv,bt878,i2c-core,dvb-core
> vermagic:       2.6.23.1-21.fc7 SMP mod_unload 686 4KSTACKS
> parm:           debug:Turn on/off debugging (default:off). (int)
>
> Whereas for a network driver > modinfo tulip:
> filename: /lib/modules/2.6.23.1-21.fc7/kernel/drivers/net/tulip/tulip.ko
> version:        1.1.15
> license:        GPL
> description:    Digital 21*4* Tulip ethernet driver
> author:         The Linux Kernel Team
> srcversion:     54B741F794FD4612A7C5AFD
> alias:          pci:v00001414d00000002sv*sd*bc*sc*i*
> alias:          pci:v000014EAd0000AB08sv*sd*bc*sc*i*
> alias:          pci:v000010B7d00009300sv*sd*bc*sc*i*
> alias:          pci:v000017B3d0000AB08sv*sd*bc*sc*i*
> alias:          pci:v00001737d0000AB08sv*sd*bc*sc*i*
> ...
>
> Is it simply that these alias definitions need to be added to the driver; I 
> might be able to do that myself ?

Yes.

> And that whenever newer boards are released using chip X that the driver 
> for that chip needs to have a new alias added ?

Yes.

Bill



From lkundrak at redhat.com  Tue Nov 27 17:31:28 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 27 Nov 2007 18:31:28 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <200711271351.31664@rineau.tsetse>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
Message-ID: <1196184688.26555.63.camel@localhost.localdomain>


On Tue, 2007-11-27 at 13:51 +0100, Laurent Rineau wrote:
> On Tuesday 27 November 2007 12:30:19 Panu Matilainen wrote:
> > On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> > > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> > >> gimp-2:2.4.1-1.fc8.x86_64
> > >
> > > -1
> > >
> > >> The epoch is the most significant factor in version comparison, might as
> > >> well show it...
> > >
> > > with this queryformat people now will start bitching on why they can't
> > > find a file of this name - the same applies to "all small letters file
> > > names".
> >
> > I'm changing the default filename too to match this, for this very reason.
> 
> Please no. Do not use ":" in filenames. It will prevent a simple backup to a 
> FAT filesystem.

I was going to argue that this is about as bogus argument as saying that
we should limit rpm filenames to 8.3. Now I realize that some people,
mostly those without their Fedora boxes connected to Internet,
occassionaly have to download packages on Windows machines in thier
schools, etc.

What's the status of ':' support in windows? Is it possible to use those
characters on NTFS? The file name if a package is not important, unless
you let rpm satisfy dependencies, does it? What happens when you attempt
to download a file with a colon in name in Windows -- does it replace it
with some other character?

If only a dash for chosen as an epoch separator instead of a colon...

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From notting at redhat.com  Tue Nov 27 17:31:41 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 27 Nov 2007 12:31:41 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
Message-ID: <20071127173141.GB14296@nostromo.devel.redhat.com>

Panu Matilainen (pmatilai at laiskiainen.org) said: 
> Why do you think it's bad - because of the ':' used as separator, or "just 
> because" (epochs are evil and all that)?

It uses a valid release character as a separator between epoch and
release, making parsing without reading the header more 'interesting',
without knowing which version of RPM created the file.

Bill



From a.badger at gmail.com  Tue Nov 27 17:36:17 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 27 Nov 2007 09:36:17 -0800
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127160436.GA8321@traged.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127152535.GA7102@traged.englab.brq.redhat.com>	<474C3E5E.7060900@gmail.com>
	<20071127160436.GA8321@traged.englab.brq.redhat.com>
Message-ID: <474C5591.40003@gmail.com>

Adam Tkac wrote:
> On Tue, Nov 27, 2007 at 07:57:18AM -0800, Toshio Kuratomi wrote:
>> Adam Tkac wrote:
>>> I've put this software to F8 because it has nice new features. Some
>>> bugs is tax for them.
>>> 9.5 will come into beta stage very soon.
>> These two are quite valid reasons that you as maintainer are the person 
>> best qualified to make a decision about.  Thank you for providing them!
>>
>>> I don't think that users use newest
>>> Fedora on important servers
>> This one, however, is not a reason to use in making these decisions. People 
>> may want to use the newest Fedora on their important servers and if so, we 
>> want them to be able to.  This is something we should strive for 
>> consciously even if subconsciously we decide to let another feature slip in 
>> ;-)
> 
> Generally you have to choose between stability and features. And I've
> chosen features in this case...
> 
Excellent.  As stated before, you, the maintainer are best qualified to 
judge how stable this release is and whether the perception of it being 
an "alpha release" or the new features it brings are more important. 
Your testing of the new version and not getting any significant bug 
reports before F8 release are valid reasons to believe the package is 
stable enough for Fedora.

I just want to stress that we're working hard to keep people from 
thinking of Fedora as "a beta release of RHEL".  As part of that "I 
don't think that users use newest Fedora on important servers" is *not* 
a reason we want to promote for making decisions on whether a particular 
upstream version is stable enough to go into a Fedora release.

Thank you for understanding the subtle distinction here,
-Toshio



From jima at beer.tclug.org  Tue Nov 27 17:45:10 2007
From: jima at beer.tclug.org (Jima)
Date: Tue, 27 Nov 2007 11:45:10 -0600 (CST)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196184688.26555.63.camel@localhost.localdomain>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>

On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
> What's the status of ':' support in windows? Is it possible to use those
> characters on NTFS? The file name if a package is not important, unless
> you let rpm satisfy dependencies, does it? What happens when you attempt
> to download a file with a colon in name in Windows -- does it replace it
> with some other character?

  Actually, I tried naming something with a : on someone's XP box yesterday 
(totally unrelated to this), and it wouldn't let me.  I didn't check, but 
I can only imagine it was using NTFS (fairly new machine).

> If only a dash for chosen as an epoch separator instead of a colon...

  Oh, *that'll* make it more readable. ;-)

      Jima



From nicolas.mailhot at laposte.net  Tue Nov 27 17:58:04 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Nov 2007 18:58:04 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196184688.26555.63.camel@localhost.localdomain>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
Message-ID: <1196186284.13764.2.camel@rousalka.dyndns.org>


Le mardi 27 novembre 2007 ? 18:31 +0100, Lubomir Kundrak a ?crit :

> What's the status of ':' support in windows?

It's a forbidden character. Windows won't let you use it and refuse
files with : inside.

There are many other possible separators, though so blocking on : is
stupid.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/13fdd5dd/attachment.sig>

From florin at andrei.myip.org  Tue Nov 27 18:02:11 2007
From: florin at andrei.myip.org (Florin Andrei)
Date: Tue, 27 Nov 2007 10:02:11 -0800
Subject: mounting removable media never seems to work
Message-ID: <474C5BA3.2070702@andrei.myip.org>

Mounting USB sticks, DVDs, CDs, etc - this works flawlessly with other 
distributions I've tried (Ubuntu), but with Fedora it's something that 
seems to stop working randomly, whenever the packages update to jour 
changes something in the system.

I've a F7 system, fully updated, and now when I insert a USB stick, I 
get the HAL error "permission denied: not in active session".

This is annoying because it's something that's supposed to just work. It 
does work in Ubuntu. Heck, it works fine in XP. But not in Fedora. 
Moreover, it's not a new thing. Previous releases of Fedora used to 
display this same problem, which never seems to be solved completely.

It's like "removable media? who cares whether it works properly or not?" 
Come one, people, wake up.

-- 
Florin Andrei

http://florin.myip.org/



From laurent.rineau__fedora at normalesup.org  Tue Nov 27 18:02:11 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Tue, 27 Nov 2007 19:02:11 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196184688.26555.63.camel@localhost.localdomain>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
Message-ID: <200711271902.11321@rineau.tsetse>

On Tuesday 27 November 2007 18:31:28 Lubomir Kundrak wrote:
> On Tue, 2007-11-27 at 13:51 +0100, Laurent Rineau wrote:
> > Please no. Do not use ":" in filenames. It will prevent a simple backup
> > to a FAT filesystem.
>
> I was going to argue that this is about as bogus argument as saying that
> we should limit rpm filenames to 8.3.

8.3 is a pre-FAT32 limitation. Since Windows?XP, everybody uses FAT32 instead 
of the old FAT (even Windows?95 can read and write to FAT32).

> What's the status of ':' support in windows? Is it possible to use those
> characters on NTFS?

NTFS allows the use of ":" (only the null character and "/" is disallowed. 
However, the Win32 API does not permit the use of ":".

> The file name if a package is not important, unless 
> you let rpm satisfy dependencies, does it? What happens when you attempt
> to download a file with a colon in name in Windows -- does it replace it
> with some other character?

I do not know.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From lkundrak at redhat.com  Tue Nov 27 18:04:57 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Tue, 27 Nov 2007 19:04:57 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
Message-ID: <1196186697.26555.67.camel@localhost.localdomain>


On Tue, 2007-11-27 at 11:45 -0600, Jima wrote:
> On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
> > What's the status of ':' support in windows? Is it possible to use those
> > characters on NTFS? The file name if a package is not important, unless
> > you let rpm satisfy dependencies, does it? What happens when you attempt
> > to download a file with a colon in name in Windows -- does it replace it
> > with some other character?
> 
>   Actually, I tried naming something with a : on someone's XP box yesterday 
> (totally unrelated to this), and it wouldn't let me.  I didn't check, but 
> I can only imagine it was using NTFS (fairly new machine).
> 
> > If only a dash for chosen as an epoch separator instead of a colon...
> 
>   Oh, *that'll* make it more readable. ;-)

Jima, are we talking about readability? Well, then we should exchange
names like orange-devel-0.3-5.cvs20051118.fc8.x86_64.rpm for "Orange
Development Package" and so on. Can you see how nice would they look on
a desktop? ;)

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From jspaleta at gmail.com  Tue Nov 27 18:25:54 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 09:25:54 -0900
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<1196176191.3229.43.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
Message-ID: <604aa7910711271025q2e110e5fh5a90397f1354b269@mail.gmail.com>

On Nov 27, 2007 6:19 AM, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> If limiting visibility of the epochs is the argument, then why is it ok
> for end user tools such as pirut (not to mention yum itself and all
> related tools) to show them?

Putting the epoch into the filename output as the second most
significant piece of information will be more disruptive to shell
scriptable interactions than tacking on the arch at the end.  Putting
the information into an interactive interface that people do not
commonly rely on in a scripted way is far less disruptive.

I'm not going to judge whether or not its worth doing, but I'm telling
you right now that there will a large need for a re-education program
concerning the epoch information if it goes in. We'll need you to blog
about it preemptively and possibly provide some information in the
form of a feature item, such as how to revert this change for legacy
needs, information that documentation writers can reformat and
distribute as needed.

Also it would be instructive to know if such a change is planned to be
propagated forward into the next RHEL release.

Please consider something other than the colon character as a
separator so we don't disrupt the ability to backup rpm package files
into fat filesystems.  There are a lot of external enclosures out
there with big disks with fat filesystems being used for backups in
small IT situations (home office, personal use and things of that
nature.)  Making a filenaming change which disrupts the ability to
backup the files seems an unnecessary complication.

-jef



From wtogami at redhat.com  Tue Nov 27 18:28:52 2007
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 27 Nov 2007 13:28:52 -0500
Subject: mounting removable media never seems to work
In-Reply-To: <474C5BA3.2070702@andrei.myip.org>
References: <474C5BA3.2070702@andrei.myip.org>
Message-ID: <474C61E4.6030309@redhat.com>

Florin Andrei wrote:
> Mounting USB sticks, DVDs, CDs, etc - this works flawlessly with other 
> distributions I've tried (Ubuntu), but with Fedora it's something that 
> seems to stop working randomly, whenever the packages update to jour 
> changes something in the system.
> 
> I've a F7 system, fully updated, and now when I insert a USB stick, I 
> get the HAL error "permission denied: not in active session".
> 
> This is annoying because it's something that's supposed to just work. It 
> does work in Ubuntu. Heck, it works fine in XP. But not in Fedora. 
> Moreover, it's not a new thing. Previous releases of Fedora used to 
> display this same problem, which never seems to be solved completely.
> 
> It's like "removable media? who cares whether it works properly or not?" 
> Come one, people, wake up.
> 

USB sticks and most CD's and DVD's work flawlessly for me on every 
release of Fedora including F8.

I did run into some data DVD's that mounted without issue on Windows XP 
but utterly failed on Linux.

Some DVD's succeeded in mounting with "mount" commands manually as root, 
but failed to mount automatically by whatever GNOME uses.

Warren Togami
wtogami at redhat.com



From sandeen at redhat.com  Tue Nov 27 18:32:22 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Tue, 27 Nov 2007 12:32:22 -0600
Subject: mounting removable media never seems to work
In-Reply-To: <474C61E4.6030309@redhat.com>
References: <474C5BA3.2070702@andrei.myip.org> <474C61E4.6030309@redhat.com>
Message-ID: <474C62B6.4010403@redhat.com>

Warren Togami wrote:

> I did run into some data DVD's that mounted without issue on Windows XP 
> but utterly failed on Linux.

Were they burned on Vista?  Could be:
[Bug 313551] Vista burned UDF volumes won't mount

I'm leaning toward it actually being an invalid format.

-Eric



From jima at beer.tclug.org  Tue Nov 27 18:32:21 2007
From: jima at beer.tclug.org (Jima)
Date: Tue, 27 Nov 2007 12:32:21 -0600 (CST)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196186697.26555.67.camel@localhost.localdomain>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
	<1196186697.26555.67.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>

On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
> Jima, are we talking about readability? Well, then we should exchange
> names like orange-devel-0.3-5.cvs20051118.fc8.x86_64.rpm for "Orange
> Development Package" and so on. Can you see how nice would they look on
> a desktop? ;)

  I wasn't dismissing your suggestion out of hand.  (Sorry, I should have 
been clearer.)  I'd advocate for a different separator if possible, though 
(_ maybe?).  - is a bit heavily used, appearing in the %name (as many as 5 
times!), and as a separator between %name, %version, and %release. 
Occasionally, with numbers in %name, it can take a moment to tell where 
%name ends and %version begins. :-)
  Fortunately, the really unreadable RPM filenames I have an issue with 
aren't in Fedora.

      Jima



From jspaleta at gmail.com  Tue Nov 27 18:34:58 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 09:34:58 -0900
Subject: mounting removable media never seems to work
In-Reply-To: <474C5BA3.2070702@andrei.myip.org>
References: <474C5BA3.2070702@andrei.myip.org>
Message-ID: <604aa7910711271034y7415ea89qd1ed6b0f90eacd06@mail.gmail.com>

On Nov 27, 2007 9:02 AM, Florin Andrei <florin at andrei.myip.org> wrote:
> Mounting USB sticks, DVDs, CDs, etc - this works flawlessly with other
> distributions I've tried (Ubuntu), but with Fedora it's something that
> seems to stop working randomly, whenever the packages update to jour
> changes something in the system.
>
> I've a F7 system, fully updated, and now when I insert a USB stick, I
> get the HAL error "permission denied: not in active session".
>
> This is annoying because it's something that's supposed to just work. It
> does work in Ubuntu. Heck, it works fine in XP. But not in Fedora.
> Moreover, it's not a new thing. Previous releases of Fedora used to
> display this same problem, which never seems to be solved completely.
>
> It's like "removable media? who cares whether it works properly or not?"
> Come one, people, wake up.


I was not experiencing any problem with usb-storage on my F7 system as
of last week.   Nor was my wife on her nearly default F7 configuration
including selinux set to enforcing. Nor have we experienced it on the
problem after installing F8 on the same hardware.

Difficult to know based on the information you have if this is a
configuration hiccup on your system or something widespread that I was
lucky enough to avoid on multiple systems.

-jef



From david at fubar.dk  Tue Nov 27 18:38:20 2007
From: david at fubar.dk (David Zeuthen)
Date: Tue, 27 Nov 2007 13:38:20 -0500
Subject: mounting removable media never seems to work
In-Reply-To: <474C5BA3.2070702@andrei.myip.org>
References: <474C5BA3.2070702@andrei.myip.org>
Message-ID: <1196188700.29259.18.camel@oneill.fubar.dk>


On Tue, 2007-11-27 at 10:02 -0800, Florin Andrei wrote:
> Mounting USB sticks, DVDs, CDs, etc - this works flawlessly with other 
> distributions I've tried (Ubuntu), but with Fedora it's something that 
> seems to stop working randomly, whenever the packages update to jour 
> changes something in the system.
> 
> I've a F7 system, fully updated, and now when I insert a USB stick, I 
> get the HAL error "permission denied: not in active session".

This typically happens if the user thinks he's smarter than the
developers and does things like disable the ConsoleKit service. Closed
at least 10 bugs on that account just for F8. Annoying. Also happens, if
the user is running SELinux in enforcing mode and some labels got
screwed up. Check AVC messages etc.

Btw, your post it off-topic; please don't abuse fedora-devel list for
these things:

http://fedoraproject.org/wiki/PostIsOffTopic

Thanks,
David




From skvidal at fedoraproject.org  Tue Nov 27 18:33:51 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 27 Nov 2007 13:33:51 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
	<1196186697.26555.67.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>
Message-ID: <1196188431.15420.123.camel@cutter>


On Tue, 2007-11-27 at 12:32 -0600, Jima wrote:
> On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
> > Jima, are we talking about readability? Well, then we should exchange
> > names like orange-devel-0.3-5.cvs20051118.fc8.x86_64.rpm for "Orange
> > Development Package" and so on. Can you see how nice would they look on
> > a desktop? ;)
> 
>   I wasn't dismissing your suggestion out of hand.  (Sorry, I should have 
> been clearer.)  I'd advocate for a different separator if possible, though 
> (_ maybe?).  - is a bit heavily used, appearing in the %name (as many as 5 
> times!), and as a separator between %name, %version, and %release. 
> Occasionally, with numbers in %name, it can take a moment to tell where 
> %name ends and %version begins. :-)

Yah - you have to read backward from left to right to parse an rpm
filename into the subcomponents.

here are the steps:
- get rid of .rpm
- read backward until a '.' - that's the arch
- read backward until the next '-' - that's the release
- read backward until the next '-' - that's the version
- read backward until you hit a ':' (if there is one) - that's the name
- read backward until the beginning of the string - that's the epoch

That let's you parse a filename like:

epoch:name-ver-rel.arch.rpm

and it handles -'s in names

if you wanted
name-epoch:ver-rel.arch.rpm you'd just have to make sure that : is
banished from ver and rel and always included.

-sv





From jspaleta at gmail.com  Tue Nov 27 18:44:20 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 09:44:20 -0900
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
	<1196186697.26555.67.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>
Message-ID: <604aa7910711271044u5fd651al275c5c0239ff1bf2@mail.gmail.com>

On Nov 27, 2007 9:32 AM, Jima <jima at beer.tclug.org> wrote:
>   I wasn't dismissing your suggestion out of hand.  (Sorry, I should have
> been clearer.)  I'd advocate for a different separator if possible, though
> (_ maybe?).  - is a bit heavily used, appearing in the %name (as many as 5
> times!), and as a separator between %name, %version, and %release.
> Occasionally, with numbers in %name, it can take a moment to tell where
> %name ends and %version begins. :-)
>   Fortunately, the really unreadable RPM filenames I have an issue with
> aren't in Fedora.

Honestly since - is overused already, its not going to hurt legibility
anymore by reusing it again.  If we were going to enforce legibility
we would have a specific character designated as a field separator and
forbid it to be used in any tag field.

Doesn't the extended ascii character set include a smiley face up in
the table near the end? We could use that.. or maybe we could use the
ascii 1/2 character as the field seperator

-jef"name(ascii:204)epoch(ascii:199)version(ascii:197)release(ascii:182)arch(ascii:236)"spaleta



From packages at amiga-hardware.com  Tue Nov 27 18:56:20 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Tue, 27 Nov 2007 18:56:20 +0000
Subject: mounting removable media never seems to work
In-Reply-To: <474C5BA3.2070702@andrei.myip.org>
References: <474C5BA3.2070702@andrei.myip.org>
Message-ID: <474C6854.5070203@amiga-hardware.com>

Florin Andrei wrote:
> Mounting USB sticks, DVDs, CDs, etc - this works flawlessly with other 
> distributions I've tried (Ubuntu), but with Fedora it's something that 
> seems to stop working randomly, whenever the packages update to jour 
> changes something in the system.
> 
> I've a F7 system, fully updated, and now when I insert a USB stick, I 
> get the HAL error "permission denied: not in active session".

This used to happen to me on F7, around the arrival of ConsoleKit. I 
traced it down to ConsoleKit dying everytime I logged in and a check 
with the init script would say "pid file exists but subsystem dead" or 
words to that effect. It could be a similar situation in your case or 
perhaps you don't even have ConsoleKit running. I never managed to track 
down why ConsoleKit was dying, despite enabling debugging everywhere 
that I thought was useful. The machine has since been flattened an F8 
installed and thankfully the problem hasn't returned.


-- 
Ian Chapman.



From rdieter at math.unl.edu  Tue Nov 27 18:57:21 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Tue, 27 Nov 2007 12:57:21 -0600
Subject: kde-4.0(rc1) hitting rawhide Dec 1-7
Message-ID: <474C6891.2090007@math.unl.edu>

(I sent this to fedora-devel-announce earlier this morning, but didn't 
see any copy land in fedora-devel, so here ya go).

Now that the KDE 4.0 RC1 is available (and development churn has
slowed), the KDE SIG will be working towards incorporating as much of
kde-4.0 (rc1) into rawhide the week of Dec 1-7.  The gory outline of
making all of this work are detailed on
http://fedoraproject.org/wiki/Releases/FeatureKDE4

The challenge will be replacing the current kde3-based
desktop with a kde4-based one, while at the same time still providing a
kde3 development platform (ie, so one can still build/run kde3
applications).

This announcement serves two primary purposes:
1.  Serve notice to expect kde-related borkage the week of Dec 1-7.

2.  Inform kde(3)-based package maintainers that spec-files that
currently include constructs like:
BuildRequires: kdelibs-devel
BuildRequires: kdebase-devel
will need to be updated to
BuildRequires: kdelibs3-devel
BuildRequires: kdebase3-devel
instead.  These kde*3 virtual Provides are in place now (in all F7+ 
branches, and without Epoch's
too, btw), so there's no need to wait to make this change.

Likewise, kde4-based applications can/should include constructs like
BuildRequires: kdelibs4-devel
(avoiding references to just kdelibs-devel which can be ambiguous).

-- Rex



From nathanael at gnat.ca  Tue Nov 27 18:14:50 2007
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Tue, 27 Nov 2007 11:14:50 -0700
Subject: mounting removable media never seems to work
In-Reply-To: <474C5BA3.2070702@andrei.myip.org>
References: <474C5BA3.2070702@andrei.myip.org>
Message-ID: <474C5E9A.1060204@gnat.ca>

Florin Andrei wrote:
> Mounting USB sticks, DVDs, CDs, etc - this works flawlessly with other 
> distributions I've tried (Ubuntu), but with Fedora it's something that 
> seems to stop working randomly, whenever the packages update to jour 
> changes something in the system.
> 
> I've a F7 system, fully updated, and now when I insert a USB stick, I 
> get the HAL error "permission denied: not in active session".
> 
> This is annoying because it's something that's supposed to just work. It 
> does work in Ubuntu. Heck, it works fine in XP. But not in Fedora. 
> Moreover, it's not a new thing. Previous releases of Fedora used to 
> display this same problem, which never seems to be solved completely.
> 
> It's like "removable media? who cares whether it works properly or not?" 
> Come one, people, wake up.

Odd, its been working flawlessly for me since F5-F8. I've never even 
seen that message above. Do you know what the cause is? Or just that 
message?



From mls at suse.de  Tue Nov 27 19:17:31 2007
From: mls at suse.de (Michael Schroeder)
Date: Tue, 27 Nov 2007 20:17:31 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
Message-ID: <20071127191731.GA23056@suse.de>

On Tue, Nov 27, 2007 at 01:30:19PM +0200, Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> >with this queryformat people now will start bitching on why they can't
> >find a file of this name - the same applies to "all small letters file
> >names".
> 
> I'm changing the default filename too to match this, for this very reason.

Hmm, this makes bash completion a bit akward as $COMP_WORDBREAKS
contains a ':'. I.e., foo-3:2<TAB> doesn't complete the rpm name
any longer.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From tmz at pobox.com  Tue Nov 27 19:19:02 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 27 Nov 2007 14:19:02 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <604aa7910711271025q2e110e5fh5a90397f1354b269@mail.gmail.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<1196176191.3229.43.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
	<604aa7910711271025q2e110e5fh5a90397f1354b269@mail.gmail.com>
Message-ID: <20071127191902.GR8224@psilocybe.teonanacatl.org>

Jeff Spaleta wrote:
> Putting the epoch into the filename output as the second most
> significant piece of information will be more disruptive to shell
> scriptable interactions than tacking on the arch at the end.
> Putting the information into an interactive interface that people do
> not commonly rely on in a scripted way is far less disruptive.

Anyone that's parsing rpm output in a script should have been using
the --qf option a long time ago to ensure that they get the output
they want, really.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Women should be obscene and not heard.
    -- Groucho Marx

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/7501928e/attachment.sig>

From ville.skytta at iki.fi  Tue Nov 27 19:20:36 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 27 Nov 2007 21:20:36 +0200
Subject: Support TV - Proposal for F9 - enhanced DVB capabilities
In-Reply-To: <4747DD82.20703@iinet.net.au>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<4747DD82.20703@iinet.net.au>
Message-ID: <200711272120.36479.ville.skytta@iki.fi>

On Saturday 24 November 2007, David Timms wrote:

> 3. DVB recording packages:
> AFAIK, a package that can record {not playback} a DVB stream would meet
> F guidelines. In fact it can be as simple as using tzap {dvb-apps} and
> cat to record dvb programs.
>
> Perhaps a split-up mythtv package that can record analog and digital
> content, but optionally playback mpeg streams {live, recorded, delayed}
> only if non Fedora parts are installed would be possible. This could
> also help to support both analog capture cards and digital cards with
> built-in mpeg decoders out of the box in a great TV app.

vdr which is already in Fedora should be able to do all that.  I haven't 
tested running it without an MPEG capable output device, but I suppose it 
will require some manual tweaking (channels.conf, remote controller 
keybindings) and isn't very user friendly in that sense.  But once it's 
running, for example vdradmin-am can be used to control it if its OSD is not 
available.



From nicolas.mailhot at laposte.net  Tue Nov 27 19:26:43 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Nov 2007 20:26:43 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <604aa7910711271044u5fd651al275c5c0239ff1bf2@mail.gmail.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
	<1196186697.26555.67.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>
	<604aa7910711271044u5fd651al275c5c0239ff1bf2@mail.gmail.com>
Message-ID: <1196191603.14753.0.camel@rousalka.dyndns.org>


Le mardi 27 novembre 2007 ? 09:44 -0900, Jeff Spaleta a ?crit :

> Doesn't the extended ascii character set include a smiley face up in
> the table near the end? We could use that.. or maybe we could use the
> ascii 1/2 character as the field seperator
> 
> -jef"name(ascii:204)epoch(ascii:199)version(ascii:197)release(ascii:182)arch(ascii:236)"spaleta

Official Fedora encoding is UTF-8, and ascii>127 makes no sense

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/d6e8f85b/attachment.sig>

From jspaleta at gmail.com  Tue Nov 27 19:39:10 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 10:39:10 -0900
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127191902.GR8224@psilocybe.teonanacatl.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<1196176191.3229.43.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>
	<604aa7910711271025q2e110e5fh5a90397f1354b269@mail.gmail.com>
	<20071127191902.GR8224@psilocybe.teonanacatl.org>
Message-ID: <604aa7910711271139lfe8e8dflcd166b913972972a@mail.gmail.com>

On Nov 27, 2007 10:19 AM, Todd Zullinger <tmz at pobox.com> wrote:
> Anyone that's parsing rpm output in a script should have been using
> the --qf option a long time ago to ensure that they get the output
> they want, really.

The --qf option even for uninstall package files sitting on a
filesystem which may or may not be mounted on an operating system with
rpm available but is accessible via the network for rpm using system
to pull from?

We can should ourselves until we are blue in the face and tsk tsk
people for not using the qf mechanism appropriately with scripted rpm
queries... but we'll still need to make a polite effort to re-educate
the people who are relying on the default structure of string.

I'm not saying this as an argument against doing it. I'm saying when
you do it, it will be relatively more painful to add a new epoch field
internal to the string than tacking on information at the end of the
querystring AND the package filename.  We should make a vocal
preemptive effort to get the word out before this lands in a release
to take the edge off the disgruntled bloodlust for making a change.
There is discussion in this thread about changing the filename as well
as the rpmdb querystring to be self-consistent in terms of displaying
the epoch. Any scripting against package  filenames will be disrupted
by a new epoch field and I think that deserves some effort to raise
awareness sooner rather than later.

-jef



From pmatilai at laiskiainen.org  Tue Nov 27 19:44:21 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 21:44:21 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127173141.GB14296@nostromo.devel.redhat.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127173141.GB14296@nostromo.devel.redhat.com>
Message-ID: <alpine.DEB.0.9999.0711272138040.24678@gotcha.dreamhost.com>

On Tue, 27 Nov 2007, Bill Nottingham wrote:

> Panu Matilainen (pmatilai at laiskiainen.org) said:
>> Why do you think it's bad - because of the ':' used as separator, or "just
>> because" (epochs are evil and all that)?
>
> It uses a valid release character as a separator between epoch and
> release,

Mm.. urgh, rpm actually accepts ':' in both version and release strings.

> making parsing without reading the header more 'interesting',
> without knowing which version of RPM created the file.

Make that "without knowing what kind of configuration was this RPM created 
with" or "without knowing if 'mv' was used after package creation. 
Remember, the filename has zero guarantee to have any resemblance on the 
package contents. The output filename is configurable already, has 
"always" been, so the n-v-r.arch.rpm format is just a defacto standard.

 	- Panu -



From jspaleta at gmail.com  Tue Nov 27 19:39:50 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 10:39:50 -0900
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196191603.14753.0.camel@rousalka.dyndns.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271142570.17671@beer.tclug.org>
	<1196186697.26555.67.camel@localhost.localdomain>
	<Pine.LNX.4.64.0711271213440.17671@beer.tclug.org>
	<604aa7910711271044u5fd651al275c5c0239ff1bf2@mail.gmail.com>
	<1196191603.14753.0.camel@rousalka.dyndns.org>
Message-ID: <604aa7910711271139j64a672bdt918ca8da9f5a7dab@mail.gmail.com>

On Nov 27, 2007 10:26 AM, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> Official Fedora encoding is UTF-8, and ascii>127 makes no sense

Oh my signatures are suppose to make sense!?!  Man I'll have to
re-think my whole worldview.

-jef"space for rent"spaleta



From jburgess777 at googlemail.com  Tue Nov 27 19:47:42 2007
From: jburgess777 at googlemail.com (Jon Burgess)
Date: Tue, 27 Nov 2007 19:47:42 +0000
Subject: Support TV - Proposal for F9 - enhanced DVB capabilities
In-Reply-To: <200711272120.36479.ville.skytta@iki.fi>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<4747DD82.20703@iinet.net.au> <200711272120.36479.ville.skytta@iki.fi>
Message-ID: <1196192862.2672.54.camel@localhost.localdomain>


On Tue, 2007-11-27 at 21:20 +0200, Ville Skytt? wrote:
> On Saturday 24 November 2007, David Timms wrote:
> 
> > 3. DVB recording packages:
> > AFAIK, a package that can record {not playback} a DVB stream would meet
> > F guidelines. In fact it can be as simple as using tzap {dvb-apps} and
> > cat to record dvb programs.
> >
> > Perhaps a split-up mythtv package that can record analog and digital
> > content, but optionally playback mpeg streams {live, recorded, delayed}
> > only if non Fedora parts are installed would be possible. This could
> > also help to support both analog capture cards and digital cards with
> > built-in mpeg decoders out of the box in a great TV app.
> 
> vdr which is already in Fedora should be able to do all that.  I haven't 
> tested running it without an MPEG capable output device, but I suppose it 
> will require some manual tweaking (channels.conf, remote controller 
> keybindings) and isn't very user friendly in that sense.  But once it's 
> running, for example vdradmin-am can be used to control it if its OSD is not 
> available.
> 

This is exactly what I've been doing for the past few months. I'm using
xine for playback of the 001.vdr files. I miss the vdr-xine integration
but can still use the shell to delete old recordings.

I've had VDR setup for a few years with a DXR3 card so configuration was
done already. It would be tricky to setup from scratch like this.

	Jon




From ml at deadbabylon.de  Tue Nov 27 19:52:24 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Tue, 27 Nov 2007 20:52:24 +0100
Subject: KDE-SIG weekly report (48/2007)
Message-ID: <200711272052.34275.ml@deadbabylon.de>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 48/2007

Time: 2007-11-27 16:00 UTC

Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-27

Meeting log: 
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-27?action=AttachFile&do=get&target=fedora-kde-sig-2007-11-27.txt

----------------------------------------------------------------------------------

= Participants =

- KevinKofler
- LaithJuwaidah
- RexDieter
- SebastianVahl

----------------------------------------------------------------------------------

= Agenda =

* The weekly KDE4 talk: 
 - Preparations for the KDE4 week in rawhide 
* recent Bugs 

= Summary =

o KDE 4: 
- A message about the arrival of KDE4 in rawhide was sent out to 
fedora-devel-announce-list and will be sent to fedora-devel-list 
- KDE-3.96.1: kdelibs4, kdepimlibs, kdebase-runtime, kdegames and kdeedu are 
building for rawhide 
- RexDieter will have a look at the review of kdebase-workspace 

o recent Bugs: 
- KDE update creates three blank icons in systray (#380071) was re-opened and 
re-assigned against gtk2 [1]
- unable to mount removable/ntfs (#378041) is at NEEDINFO [2]

o Open discussion: 
- having an utility to manage autostarted applications would be nice 
- bluez-gnome and system-config-printer applets should not be visible inside 
KDE (OnlyShowIn=GNOME)

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-12-04

----------------------------------------------------------------------------------

= Links =

[1] https://bugzilla.redhat.com/show_bug.cgi?id=38007
[2] https://bugzilla.redhat.com/show_bug.cgi?id=378041
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/4506969d/attachment.sig>

From buildsys at fedoraproject.org  Tue Nov 27 19:56:37 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Tue, 27 Nov 2007 14:56:37 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-27
Message-ID: <20071127195637.5759B15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 3

    asylum-0.2.3-1.fc6
NEW extrema-4.2.10-3.fc6 : Extrema is a powerful visualization and data analysis tool
    php-pecl-xdebug-2.0.2-1.fc6


Changes in Fedora Extras 6: 


asylum-0.2.3-1.fc6
------------------
* Sun Nov 25 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.2.3-1
- Upgrade to 0.2.3
- Removed asylum-0.2.2-fixsound.patch - fixed upstream

extrema-4.2.10-3.fc6
--------------------
* Sun Nov 18 2007 Terje Rosten <terje.rosten at ntnu.no> - 4.2.10-3
- Add req. on help subpackage

* Sun Nov 04 2007 Terje Rosten <terje.rosten at ntnu.no> - 4.2.10-2
- Fix license
- Change convert buildreq to ImageMagick
- Move to Graphics menu

* Sat Nov 03 2007 Terje Rosten <terje.rosten at ntnu.no> - 4.2.10-1
- Initial package

php-pecl-xdebug-2.0.2-1.fc6
---------------------------
* Sun Nov 25 2007 Christopher Stone <chris.stone at gmail.com> 2.0.2-1
- Upstream sync



From tcallawa at redhat.com  Tue Nov 27 20:02:24 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 27 Nov 2007 15:02:24 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474C491F.2030204@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
Message-ID: <1196193744.3229.54.camel@localhost.localdomain>


On Tue, 2007-11-27 at 17:43 +0100, Christopher Aillon wrote:
> On 11/27/2007 03:29 AM, Tom "spot" Callaway wrote:
> > On Mon, 2007-11-26 at 21:24 -0500, Chuck Anderson wrote:
> > 
> >> I'm concerned about the policies which allow unstable software in 
> >> stable Fedora releases.  Is it considered acceptable/encouraged to 
> >> have alpha versions of software in the stable release?  Is there any 
> >> policy?
> > 
> > There is no policy, its up to the individual maintainer to use their
> > best judgement as to what should be included.
> 
> It's hard to make judgements without having any criteria to judge upon. 
>   We don't need to have a strict policy, but I think it would be useful 
> to have some loose guidelines.

Such as? Open to suggestions here.

~spot



From notting at redhat.com  Tue Nov 27 20:15:48 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 27 Nov 2007 15:15:48 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711272138040.24678@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127173141.GB14296@nostromo.devel.redhat.com>
	<alpine.DEB.0.9999.0711272138040.24678@gotcha.dreamhost.com>
Message-ID: <20071127201548.GB25818@nostromo.devel.redhat.com>

Panu Matilainen (pmatilai at laiskiainen.org) said: 
>> It uses a valid release character as a separator between epoch and
>> release,
>
> Mm.. urgh, rpm actually accepts ':' in both version and release strings.

And '\0', and ?, and ?, and...

>> making parsing without reading the header more 'interesting',
>> without knowing which version of RPM created the file.
>
> Make that "without knowing what kind of configuration was this RPM created 
> with" or "without knowing if 'mv' was used after package creation. 
> Remember, the filename has zero guarantee to have any resemblance on the 
> package contents. The output filename is configurable already, has "always" 
> been, so the n-v-r.arch.rpm format is just a defacto standard.

Sure, but just because it's a de facto rather than de jure standard doesn't
make it any better of an idea to change it.

Bill



From pmatilai at laiskiainen.org  Tue Nov 27 20:34:31 2007
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Nov 2007 22:34:31 +0200 (EET)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127191731.GA23056@suse.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<20071127191731.GA23056@suse.de>
Message-ID: <alpine.DEB.0.9999.0711272216570.24678@gotcha.dreamhost.com>

On Tue, 27 Nov 2007, Michael Schroeder wrote:

> On Tue, Nov 27, 2007 at 01:30:19PM +0200, Panu Matilainen wrote:
>> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
>>> with this queryformat people now will start bitching on why they can't
>>> find a file of this name - the same applies to "all small letters file
>>> names".
>>
>> I'm changing the default filename too to match this, for this very reason.
>
> Hmm, this makes bash completion a bit akward as $COMP_WORDBREAKS
> contains a ':'. I.e., foo-3:2<TAB> doesn't complete the rpm name
> any longer.

Right, that's fairly nasty, and also I think the first practical "this 
breaks" example instead of "somebodys hypotethical script somewhere" cases 
(which without doubt do exist). Backing up to filesystem X where ':' is 
illegal doesn't really count as reason though, as ':' is a valid character 
in rpm otherwise anyway.

The point of the excercise (in rpm.org HEAD) was largely to see what would 
really break but I think I've seen enough already. So back to plan A) 
which was
- add arch to default queryformat
- add popt-alias for legacy nvr queryformat 
- add popt-alias for nevra queryformat to make accessing the "hidden"
   epoch info saner than a mile-long queryformat strings

I guess that's enough excitement for one-time change in the world of RPM,
and now off to revert the changes, mark for revisiting in ten years...

At least this was a fairly entertaining day on fedora-devel ;)

 	- Panu -




From mls at suse.de  Tue Nov 27 20:40:17 2007
From: mls at suse.de (Michael Schroeder)
Date: Tue, 27 Nov 2007 21:40:17 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <alpine.DEB.0.9999.0711272216570.24678@gotcha.dreamhost.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<alpine.DEB.0.9999.0711271329270.14586@gotcha.dreamhost.com>
	<20071127191731.GA23056@suse.de>
	<alpine.DEB.0.9999.0711272216570.24678@gotcha.dreamhost.com>
Message-ID: <20071127204017.GA23365@suse.de>

On Tue, Nov 27, 2007 at 10:34:31PM +0200, Panu Matilainen wrote:
> Right, that's fairly nasty, and also I think the first practical "this 
> breaks" example instead of "somebodys hypotethical script somewhere" cases 
> (which without doubt do exist).

If you want some other example where things might break:

$ scp foo-2:1-1.noarch.rpm someotherhost:/tmp
ssh: foo-2: Name or service not known

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From ihok at hotmail.com  Tue Nov 27 21:02:03 2007
From: ihok at hotmail.com (Jack Tanner)
Date: Tue, 27 Nov 2007 21:02:03 +0000 (UTC)
Subject: RSSOwl status?
Message-ID: <loom.20071127T205641-266@post.gmane.org>

As far as I can tell by googling around, RSSOwl 1.x got dropped at some 
point because it depended on iText, which had licensing issues. RSSOwl 2.x, 
which is not yet out, will dispense with iText, and we can have it back then.

In the meantime, RSSOwl 2.x is up to Milestone 6, and iText's homepage 
talks about a dual LGPL/MPL license. It'd be nice if we could could we have 
RSSOwl in some form now. Either 2M6 or 1.2 with the (seemingly kosher) iText 
would be great.



From ivazqueznet at gmail.com  Tue Nov 27 20:52:49 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 27 Nov 2007 15:52:49 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <385453.83318.qm@web52410.mail.re2.yahoo.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
Message-ID: <1196196769.3414.6.camel@ignacio.lan>

On Wed, 2007-11-21 at 19:29 -0800, Otto Rey wrote:
> Fedora should have a good support of TV cards. I have a LifeView
> FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV
> working. I try almost everything (i am developer).
> For home users, Fedora 9 TV support should by something like this:
> "Install this crappy package and you are zapping" :D

After a marathon coding/testing session with fursund[1] in #elisa, the
ivtv plugin[2] for elisa is now mostly working. It needs ivtv-utils[3]
(which I will package shortly) and elisa 0.3.2.

[1] http://dlai.jafu.dk/
[2] http://dlai.jafu.dk/wp-content/ivtvplugin.zip
[3] http://www.ivtvdriver.org/index.php/Download

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/2ad893c9/attachment.sig>

From atkac at redhat.com  Tue Nov 27 21:24:19 2007
From: atkac at redhat.com (Adam Tkac)
Date: Tue, 27 Nov 2007 22:24:19 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474C5591.40003@gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<474C3E5E.7060900@gmail.com>
	<20071127160436.GA8321@traged.englab.brq.redhat.com>
	<474C5591.40003@gmail.com>
Message-ID: <20071127212419.GA3246@traged.englab.brq.redhat.com>

On Tue, Nov 27, 2007 at 09:36:17AM -0800, Toshio Kuratomi wrote:
> Adam Tkac wrote:
>> On Tue, Nov 27, 2007 at 07:57:18AM -0800, Toshio Kuratomi wrote:
>>> Adam Tkac wrote:
>>>> I've put this software to F8 because it has nice new features. Some
>>>> bugs is tax for them.
>>>> 9.5 will come into beta stage very soon.
>>> These two are quite valid reasons that you as maintainer are the person 
>>> best qualified to make a decision about.  Thank you for providing them!
>>>
>>>> I don't think that users use newest
>>>> Fedora on important servers
>>> This one, however, is not a reason to use in making these decisions. 
>>> People may want to use the newest Fedora on their important servers and 
>>> if so, we want them to be able to.  This is something we should strive 
>>> for consciously even if subconsciously we decide to let another feature 
>>> slip in ;-)
>>
>> Generally you have to choose between stability and features. And I've
>> chosen features in this case...
>>
> Excellent.  As stated before, you, the maintainer are best qualified to 
> judge how stable this release is and whether the perception of it being an 
> "alpha release" or the new features it brings are more important. Your 
> testing of the new version and not getting any significant bug reports 
> before F8 release are valid reasons to believe the package is stable enough 
> for Fedora.
>
> I just want to stress that we're working hard to keep people from thinking 
> of Fedora as "a beta release of RHEL".  As part of that "I don't think that 
> users use newest Fedora on important servers" is *not* a reason we want to 
> promote for making decisions on whether a particular upstream version is 
> stable enough to go into a Fedora release.

Definitely. I've never said Fedora is testing ground for RHEL. I want
point that Fedora has new features and new features mean bugs so you
cannot expect such stability like RHEL. And I also believe all
maintainers put new releases into Fedora because they have good reasons
(not only because "release exists" :) )

Adam

>
> Thank you for understanding the subtle distinction here,
> -Toshio
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From lists at ebourne.me.uk  Tue Nov 27 21:27:25 2007
From: lists at ebourne.me.uk (Martin Ebourne)
Date: Tue, 27 Nov 2007 21:27:25 +0000 (UTC)
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
	<474ABA11.3090305@odu.neva.ru> <20071126133842.GB2631@free.fr>
	<474AD017.7050808@odu.neva.ru>
	<1196090850.3328.36.camel@localhost.localdomain>
Message-ID: <pan.2007.11.27.21.27.25@ebourne.me.uk>

On Mon, 26 Nov 2007 10:27:30 -0500, Jeremy Katz wrote:
> On Mon, 2007-11-26 at 16:54 +0300, Dmitry Butskoy wrote:
>> But if the user will decide to use SELinux (install all needed
>> packages) later? Then it should re-install pam_ssh to activate its
>> policies...
> 
> This is one of the (many) reasons why it's currently better to get
> policy into the main selinux-policy package rather than trying to do
> hacks to carry policy in the package.

This is bad. It's clearly not workable to have all policy in the one 
centrally maintained cathedral-like package. It's important to be allow 
packages to have their own specific policy and we should be trying to fix 
anything that prevents this.

In this case for instance it is necessary to grant pam extra permissions 
which are not needed except for pam_ssh. Of course, good security policy 
is always to give least permissions and that is being violated here for 
everyone who doesn't use pam_ssh.

In the absence of an ability for selinux to know if pam_ssh is configured 
then at least having the policy in the module would only activate it if 
pam_ssh was installed.

Cheers,

Martin.



From tcallawa at redhat.com  Tue Nov 27 21:46:33 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 27 Nov 2007 16:46:33 -0500
Subject: AWOL: jpo
In-Reply-To: <1195574488.27963.27.camel@localhost.localdomain>
References: <1195574488.27963.27.camel@localhost.localdomain>
Message-ID: <1196199993.3054.2.camel@localhost.localdomain>


On Tue, 2007-11-20 at 11:01 -0500, Tom "spot" Callaway wrote:

> If he does not respond to this email in a week, I'll take over all of
> his packages (temporarily) and post to fedora-devel that they're all up
> for grabs.

In accordance with the AWOL policy, I've now declared jpo AWOL. Many of
his packages have already been claimed by the perl-SIG, but there are
some packages available (I currently own them, but will happily pass
them on to a more motivated maintainer):

  * asymptote -- Descriptive vector graphics language
      * eventlog -- Syslog-ng v2 support library
      * libcgi -- CGI easy as C
      * libsmi -- A library to access SMI MIB information
      * nagios-plugins-snmp-disk-proc -- Nagios SNMP plugins to monitor
        remote disk and processes
      * srecord -- Manipulate EPROM load files
      * swatch -- Tool for actively monitoring log files
      * syslog-ng -- Syslog replacement daemon
      * tetex-bytefield -- Create illustrations for network protocol
        specifications
      * tetex-perltex -- Define LaTeX macros in terms of Perl code

Thanks to all those who volunteered to maintain/comaintain his other
packages.

~spot



From ville.skytta at iki.fi  Tue Nov 27 21:56:23 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 27 Nov 2007 23:56:23 +0200
Subject: Fedora Orphaned Package Removal: November 29th 2007
In-Reply-To: <474335DA.5000000@hhs.nl>
References: <47421B35.4080006@redhat.com> <4742A293.8060509@hhs.nl>
	<474335DA.5000000@hhs.nl>
Message-ID: <200711272356.24133.ville.skytta@iki.fi>

On Tuesday 20 November 2007, Hans de Goede wrote:

> I've taken ownership of openct, opensc, pcsc-perl and pcsc-tools for now,
> as I plan to become a user of them in the near future, and I would hate tro
> seem them goaway.
>
> co-maintainers much appreciated. Ville, perhaps you are willing to stay
> involved as co-maintainer?

Why not until other co-maintainers emerge, but please keep in mind that I'm 
only occasionally playing around with these packages these days, not 
seriously using them.  Permissions requested for F-8+ in pkgdb.



From lsof at nodata.co.uk  Tue Nov 27 22:03:49 2007
From: lsof at nodata.co.uk (nodata)
Date: Tue, 27 Nov 2007 23:03:49 +0100
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071127115508.3da14863@redhat.com>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter> <474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<474C2034.8050000@gmail.com> <474C27D0.5020400@fedoraproject.org>
	<474C4B0E.8070304@gmail.com>  <20071127115508.3da14863@redhat.com>
Message-ID: <1196201029.2912.3.camel@sb-home>


Am Dienstag, den 27.11.2007, 11:55 -0500 schrieb Jesse Keating:
> On Tue, 27 Nov 2007 10:51:26 -0600
> Les Mikesell <lesmikesell at gmail.com> wrote:
> 
> > And the advantage of distributing all this work and making it be done
> > in a certain order over just forcing case insensitivity would be?
> 
> If you care about things being found with lower case, the best way to
> accomplish that is to make everything lower case.  Otherwise you're
> going to have differences in yum, vs rpm, vs ls, vs http, vs....
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

But search is already case insensitive.

When is this useful? When the user is guessing package names?



From sgrubb at redhat.com  Tue Nov 27 22:05:54 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Tue, 27 Nov 2007 17:05:54 -0500
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
In-Reply-To: <pan.2007.11.27.21.27.25@ebourne.me.uk>
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
	<1196090850.3328.36.camel@localhost.localdomain>
	<pan.2007.11.27.21.27.25@ebourne.me.uk>
Message-ID: <200711271705.55330.sgrubb@redhat.com>

On Tuesday 27 November 2007 16:27:25 Martin Ebourne wrote:
> In the absence of an ability for selinux to know if pam_ssh is configured
> then at least having the policy in the module would only activate it if
> pam_ssh was installed.

This is why we have selinux booleans. Its to swing permissions in and out 
depending on what's installed.

-Steve



From kwizart at gmail.com  Tue Nov 27 22:06:35 2007
From: kwizart at gmail.com (KH KH)
Date: Tue, 27 Nov 2007 23:06:35 +0100
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <1196196769.3414.6.camel@ignacio.lan>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
Message-ID: <e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>

2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Wed, 2007-11-21 at 19:29 -0800, Otto Rey wrote:
> > Fedora should have a good support of TV cards. I have a LifeView
> > FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV
> > working. I try almost everything (i am developer).
> > For home users, Fedora 9 TV support should by something like this:
> > "Install this crappy package and you are zapping" :D
>
> After a marathon coding/testing session with fursund[1] in #elisa, the
> ivtv plugin[2] for elisa is now mostly working. It needs ivtv-utils[3]
> (which I will package shortly) and elisa 0.3.2.
Unfortunately the ivtv-utils are now deprecated with >=2.6.23 kernels
http://lists-archives.org/video4linux/19986-cx88-ivtv-emulation-hvr-1300.html
Iv'e closed the ivtv bug that were submitted:
https://bugzilla.redhat.com/show_bug.cgi?id=348911
https://bugzilla.redhat.com/show_bug.cgi?id=250971
ivtv-firmware and xorg-x11-drv-ivtv have been approved but still were
not imported because of "competing" review request... (my website is
offline for the next 24hours)

Nicolas (kwizart)

>
> [1] http://dlai.jafu.dk/
> [2] http://dlai.jafu.dk/wp-content/ivtvplugin.zip
> [3] http://www.ivtvdriver.org/index.php/Download
>
> --
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
>
> PLEASE don't CC me; I'm already subscribed
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From skvidal at fedoraproject.org  Tue Nov 27 22:03:40 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 27 Nov 2007 17:03:40 -0500
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196201029.2912.3.camel@sb-home>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<20071126145534.7df4d8d3@redhat.com>
	<20071126210313.28ca9ca2@lain.camperquake.de>
	<1196107574.15420.51.camel@cutter> <474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter> <474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<474C2034.8050000@gmail.com> <474C27D0.5020400@fedoraproject.org>
	<474C4B0E.8070304@gmail.com>  <20071127115508.3da14863@redhat.com>
	<1196201029.2912.3.camel@sb-home>
Message-ID: <1196201020.15420.161.camel@cutter>


On Tue, 2007-11-27 at 23:03 +0100, nodata wrote:
> Am Dienstag, den 27.11.2007, 11:55 -0500 schrieb Jesse Keating:
> > On Tue, 27 Nov 2007 10:51:26 -0600
> > Les Mikesell <lesmikesell at gmail.com> wrote:
> > 
> > > And the advantage of distributing all this work and making it be done
> > > in a certain order over just forcing case insensitivity would be?
> > 
> > If you care about things being found with lower case, the best way to
> > accomplish that is to make everything lower case.  Otherwise you're
> > going to have differences in yum, vs rpm, vs ls, vs http, vs....
> > 
> > -- 
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> But search is already case insensitive.
> 
> When is this useful? When the user is guessing package names?

list is case insensitive so if the person knows the name but not the
case they can find it.
search is also case insensitive but it doesn't just match against
package nevra like list does.

And neither of those commands modify things on your system.

thats why we can be looser with the input we accept.

-sv






From lists at ebourne.me.uk  Tue Nov 27 22:12:22 2007
From: lists at ebourne.me.uk (Martin Ebourne)
Date: Tue, 27 Nov 2007 22:12:22 +0000 (UTC)
Subject: rpms/pam_ssh/F-8 pam_ssh.te,NONE,1.1 pam_ssh.spec,1.13,1.14
References: <200711232350.lANNoQTc017952@cvs-int.fedora.redhat.com>
	<1196090850.3328.36.camel@localhost.localdomain>
	<pan.2007.11.27.21.27.25@ebourne.me.uk>
	<200711271705.55330.sgrubb@redhat.com>
Message-ID: <pan.2007.11.27.22.12.22@ebourne.me.uk>

On Tue, 27 Nov 2007 17:05:54 -0500, Steve Grubb wrote:
> On Tuesday 27 November 2007 16:27:25 Martin Ebourne wrote:
>> In the absence of an ability for selinux to know if pam_ssh is
>> configured then at least having the policy in the module would only
>> activate it if pam_ssh was installed.
> 
> This is why we have selinux booleans. Its to swing permissions in and
> out depending on what's installed.

Booleans should be for policy decisions the administrator needs to make. 
(eg. allow users to run servers that listen on tcp ports)

Having a boolean to enable use of a package you've already installed is 
the wrong use.

Cheers,

Martin.



From ivazqueznet at gmail.com  Tue Nov 27 22:16:35 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 27 Nov 2007 17:16:35 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
Message-ID: <1196201795.3414.7.camel@ignacio.lan>

On Tue, 2007-11-27 at 23:06 +0100, KH KH wrote:
> 2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > After a marathon coding/testing session with fursund in #elisa, the
> > ivtv plugin for elisa is now mostly working. It needs ivtv-utils
> > (which I will package shortly) and elisa 0.3.2.
> Unfortunately the ivtv-utils are now deprecated with >=2.6.23 kernels
> http://lists-archives.org/video4linux/19986-cx88-ivtv-emulation-hvr-1300.html

So then what replacement do they suggest?

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/d44ef298/attachment.sig>

From tcallawa at redhat.com  Tue Nov 27 22:21:49 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 27 Nov 2007 17:21:49 -0500
Subject: AWOL: jpo
In-Reply-To: <f224c6140711220002t2c682ccck51b90f11b35141e@mail.gmail.com>
References: <1195574488.27963.27.camel@localhost.localdomain>
	<f224c6140711220002t2c682ccck51b90f11b35141e@mail.gmail.com>
Message-ID: <1196202109.3054.31.camel@localhost.localdomain>


On Thu, 2007-11-22 at 03:02 -0500, Michel Salim wrote:
> On 20/11/2007, Tom spot Callaway <tcallawa at redhat.com> wrote:
> > It seems that Jose Pedro Oliveira (aka jpo) is not coming back to
> > Fedora. He has 28 open bug tickets, most of them in the new state, and
> > he has not touched any of his packages or bugzilla since June.
> >
> > I'm initiating the AWOL process so that we can work on finding new homes
> > for all of his many packages, and start bugfixing them.
> >
> 
> Hopefully he will come back, but otherwise, I'd like to take over pdfjoin.

pdfjam is now yours for F-7, F-8, and devel.

~spot



From andrewparker at bigfoot.com  Tue Nov 27 22:33:56 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Tue, 27 Nov 2007 17:33:56 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
Message-ID: <6c3f5e6c0711271433p2cd98c32q2104a82fe2255615@mail.gmail.com>

On Nov 27, 2007 5:06 PM, KH KH <kwizart at gmail.com> wrote:
> 2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > On Wed, 2007-11-21 at 19:29 -0800, Otto Rey wrote:
> > > Fedora should have a good support of TV cards. I have a LifeView
> > > FlyVideo 98 and Fedora 8 with MythTV (and others) and I can't get TV
> > > working. I try almost everything (i am developer).
> > > For home users, Fedora 9 TV support should by something like this:
> > > "Install this crappy package and you are zapping" :D
> >
> > After a marathon coding/testing session with fursund[1] in #elisa, the
> > ivtv plugin[2] for elisa is now mostly working. It needs ivtv-utils[3]
> > (which I will package shortly) and elisa 0.3.2.
> Unfortunately the ivtv-utils are now deprecated with >=2.6.23 kernels
> http://lists-archives.org/video4linux/19986-cx88-ivtv-emulation-hvr-1300.html
> Iv'e closed the ivtv bug that were submitted:
> https://bugzilla.redhat.com/show_bug.cgi?id=348911
> https://bugzilla.redhat.com/show_bug.cgi?id=250971
> ivtv-firmware and xorg-x11-drv-ivtv have been approved but still were
> not imported because of "competing" review request... (my website is
> offline for the next 24hours)
>
> Nicolas (kwizart)
>

I don't think that's quite true.  The driver is now part of the
kernel, but you still need to install the firmware and the userland
tools such as ivtvctl.

http://ivtvdriver.org/index.php/Howto#Download_and_install

> >
> > [1] http://dlai.jafu.dk/
> > [2] http://dlai.jafu.dk/wp-content/ivtvplugin.zip
> > [3] http://www.ivtvdriver.org/index.php/Download
> >
> > --



From kwizart at gmail.com  Tue Nov 27 22:39:01 2007
From: kwizart at gmail.com (KH KH)
Date: Tue, 27 Nov 2007 23:39:01 +0100
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <1196201795.3414.7.camel@ignacio.lan>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
	<1196201795.3414.7.camel@ignacio.lan>
Message-ID: <e1760170711271439m54dc688fpd86076764b511c87@mail.gmail.com>

2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> On Tue, 2007-11-27 at 23:06 +0100, KH KH wrote:
> > 2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > > After a marathon coding/testing session with fursund in #elisa, the
> > > ivtv plugin for elisa is now mostly working. It needs ivtv-utils
> > > (which I will package shortly) and elisa 0.3.2.
> > Unfortunately the ivtv-utils are now deprecated with >=2.6.23 kernels
> > http://lists-archives.org/video4linux/19986-cx88-ivtv-emulation-hvr-1300.html
>
> So then what replacement do they suggest?

Following the post:, see here:
http://lists-archives.org/video4linux/19992-cx88-ivtv-emulation-hvr-1300.html

> --
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
>
> PLEASE don't CC me; I'm already subscribed
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>



From markg85 at gmail.com  Tue Nov 27 22:41:13 2007
From: markg85 at gmail.com (Mark)
Date: Tue, 27 Nov 2007 23:41:13 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127152535.GA7102@traged.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
Message-ID: <6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>

2007/11/27, Adam Tkac <atkac at redhat.com>:
> On Mon, Nov 26, 2007 at 09:24:48PM -0500, Chuck Anderson wrote:
> > Fedora 8 shipped with an BIND 9.5.0a6, recently updated to 9.5.0a7.
> > The release announcement for BIND says:
> >
> > BIND 9.5.0a7 is a alpha release for BIND 9.5.0.
> >
> >       This is a technology preview of new functionality to be be
> >       released in BIND 9.5.0.  New APIs are not yet frozen.
> >
> > Is this an appropriate release to be putting in a stable Fedora
> > release?  I've encounted a segfault in this version, which I've
> > reported here:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=400461
> >
> > I'm concerned about the policies which allow unstable software in
> > stable Fedora releases.  Is it considered acceptable/encouraged to
> > have alpha versions of software in the stable release?  Is there any
> > policy?
> >
> > Thanks.
>
> I've put this software to F8 because it has nice new features. Some
> bugs is tax for them. Additionally I don't think that users use newest
> Fedora on important servers and 9.5 will come into beta stage very
> soon.
>
> Adam
>
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> --
> Adam Tkac, Red Hat, Inc.

Hey,

I understand why you choose to include it but i don't really like it.
If i run a server i want to have the latest _stable_ releases and
certainly no alpha (BIND) beta or even a build (NetworkManager)! now i
can imagine that desktop applications that aren't in a final release
can get pushed in Fedora because it simply has some nice additions
that you don't want your users to miss. But BIND is a vital part of a
server (DNS Server) so i think you shouldn't include beta's or even
alpha's of that in final releases of Fedora.

And you say:
> Fedora has new features and new features mean bugs so you
> cannot expect such stability like RHEL.

Oke i understand that. BUT the fact that you do push a vital server
component that is in alpha in Fedora does imply that you are testing
it on fedora for RHEL! (which in term keeps your other statement
standing).

Fedora is used for servers (which you as a redhat employee probably
know) but in the mean time it's purpose is mainly a desktop OS. I
would say that:
 - All server components like Sendmail, DNS, Apache, MySQL, PostgreSQL
etc.. should stay up to date with there latest _stable_ release (no
alpha's, beta's or rc's)
 - All desktop related applications can probably be less tight.. I
don't see a problem there for alpha's, beta's or rc's.. as long as the
applications itself don't crash and just work.

That's just my point of view as a fedora desktop and (previously) server user.



From ivazqueznet at gmail.com  Tue Nov 27 22:49:32 2007
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 27 Nov 2007 17:49:32 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <e1760170711271439m54dc688fpd86076764b511c87@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
	<1196201795.3414.7.camel@ignacio.lan>
	<e1760170711271439m54dc688fpd86076764b511c87@mail.gmail.com>
Message-ID: <1196203772.3414.9.camel@ignacio.lan>

On Tue, 2007-11-27 at 23:39 +0100, KH KH wrote:
> 2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > On Tue, 2007-11-27 at 23:06 +0100, KH KH wrote:
> > > 2007/11/27, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>:
> > > > After a marathon coding/testing session with fursund in #elisa, the
> > > > ivtv plugin for elisa is now mostly working. It needs ivtv-utils
> > > > (which I will package shortly) and elisa 0.3.2.
> > > Unfortunately the ivtv-utils are now deprecated with >=2.6.23 kernels
> > > http://lists-archives.org/video4linux/19986-cx88-ivtv-emulation-hvr-1300.html
> >
> > So then what replacement do they suggest?
> 
> Following the post:, see here:
> http://lists-archives.org/video4linux/19992-cx88-ivtv-emulation-hvr-1300.html

Feel free to let me know when they've merged ivtv-tune's channel
selection options into v4l2-ctl. Until then I'll stick to the sane
option.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/ca1e7d2a/attachment.sig>

From jspaleta at gmail.com  Tue Nov 27 23:07:39 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 14:07:39 -0900
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
Message-ID: <604aa7910711271507y75d855ecp721d26b5a6191f26@mail.gmail.com>

On Nov 27, 2007 1:41 PM, Mark <markg85 at gmail.com> wrote:
>  - All desktop related applications can probably be less tight.. I
> don't see a problem there for alpha's, beta's or rc's.. as long as the
> applications itself don't crash and just work.

I think a concept of how capable the maintainer is to address bugs as
downstream patches needs to be factored in as well.  And how early in
the process in the testing process the pre-release versions showed up
into the testing tree.

We've had dbus in fedora for a few releases now.. well before its api
was nailed down and considered stable.. haven't we?  It's not a
critical server service.. nor is it a desktop application itself..but
it does critically affect the desktop experience since multiple
desktop components rely on dbus.

In the future it might be beneficial to raise a big stink about
pre-release stuff which is being considered in the release as we march
through the testing process.  If a maintainer feels comfortable
releasing an alpha component or application then we need to make sure
that we have a reasonable way for testers to see it coming down the
pipe and have an opportunity to beat the snot out of that component as
part of Fedora testing.  I don't think its unreasonable to give
testers a heads up about pre-release stuff so they can prioritize how
they spend time testing before a Fedora release.


-jef



From s.adam at diffingo.com  Tue Nov 27 23:31:23 2007
From: s.adam at diffingo.com (Stewart Adam)
Date: Tue, 27 Nov 2007 18:31:23 -0500
Subject: Disable RPM's autoprovide function
Message-ID: <1196206283.23372.7.camel@Diffingo.localdomain>

Hi,

A bug report at Livna (#1741) pointed out that the
xorg-x11-drv-nvidia-libs-32bit package is pulled in over mesa-libGL.i386
when the 32-bit library "libGL.so.1" is required on x86_64 (in the
user's case, it was while installing wine). libGL.so.1 is automatically
provided because of the scripts that RPM runs at the end of a build - Is
there some way to override this or disable it so that libGL.so.1 is only
provided by mesa-libGL?

Thanks,
Stewart



From che666 at gmail.com  Tue Nov 27 23:41:20 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 27 Nov 2007 23:41:20 +0000
Subject: Should "yum install" be case sensitive?
In-Reply-To: <20071127170517.e5c84864.mschwendt.tmp0701.nospam@arcor.de>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<1196107574.15420.51.camel@cutter>
	<474B2A40.7030800@fedoraproject.org>
	<1196108870.15420.55.camel@cutter>
	<474B2F22.7020102@fedoraproject.org>
	<1196114417.15420.60.camel@cutter>
	<alpine.DEB.0.9999.0711271207350.14586@gotcha.dreamhost.com>
	<20071127133003.6f32805c.mschwendt.tmp0701.nospam@arcor.de>
	<20071127144054.GA27740@gallagher.di.uoa.gr>
	<20071127170517.e5c84864.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <e99d27470711271541n765c2dffp27bb9980eccb0321@mail.gmail.com>

On Nov 27, 2007 4:05 PM, Michael Schwendt
<mschwendt.tmp0701.nospam at arcor.de> wrote:
> On Tue, 27 Nov 2007 16:40:54 +0200, Sarantis Paskalis wrote:
>
> > On Tue, Nov 27, 2007 at 01:30:03PM +0100, Michael Schwendt wrote:
> > > On Tue, 27 Nov 2007 12:13:37 +0200 (EET), Panu Matilainen wrote:
> > >
> > > > Can we finally have the lower case on package names policy?
> > > > Pretty please?
> > >
> > > I remember we've discussed that long ago. Who remembers the details?
> >
> > http://www.redhat.com/archives/fedora-maintainers/2006-December/msg00110.html
> >
> > with a link to the relevant section of the IRC log.  The bottom line
> > seemed to be that it needed more discussion.
>
> Hmmm...
> I thought about a time even longer ago. Either around fedora.us or
> when revisiting existing guidelines for Fedora Extras 3.

see my comment above... :D

>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From bbbush.yuan at gmail.com  Wed Nov 28 01:22:02 2007
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Wed, 28 Nov 2007 09:22:02 +0800
Subject: Should "yum install" be case sensitive?
In-Reply-To: <1196152661.15420.94.camel@cutter>
References: <668bb39a0711261150xdf9e023p808b5b141dd8bb47@mail.gmail.com>
	<200711270022.48458.opensource@till.name>
	<474B5671.20604@fedoralinks.org>
	<200711270933.00984.opensource@till.name>
	<1196152661.15420.94.camel@cutter>
Message-ID: <76e72f800711271722s37418863nebd772f82c26e049@mail.gmail.com>

2007/11/27, seth vidal <skvidal at fedoraproject.org>:
>
> >
> > This is faster than having to restart yum two more times, once to search for
> > the real case and once to install it.
> >
>
> then don't start it twice:
> yum shell
> > search blah
> > install BlaH
> > run
>

Is it becoming slower if using bash-completion? I think it can handle
case well. And in PackageKit 1.4 release-notes it says "New features:
- Install the bash completion file so it works by default (Richard
Hughes)". see http://hughsient.livejournal.com/48043.html



-- 
bbbush ^_^



From lordmorgul at gmail.com  Wed Nov 28 02:06:31 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Tue, 27 Nov 2007 18:06:31 -0800
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <604aa7910711271139lfe8e8dflcd166b913972972a@mail.gmail.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>	<1196162658.12310.463.camel@mccallum.corsepiu.local>	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>	<1196173233.3229.34.camel@localhost.localdomain>	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>	<1196176191.3229.43.camel@localhost.localdomain>	<alpine.DEB.0.9999.0711271712180.14586@gotcha.dreamhost.com>	<604aa7910711271025q2e110e5fh5a90397f1354b269@mail.gmail.com>	<20071127191902.GR8224@psilocybe.teonanacatl.org>
	<604aa7910711271139lfe8e8dflcd166b913972972a@mail.gmail.com>
Message-ID: <474CCD27.90009@gmail.com>

Jeff Spaleta wrote:
> I'm not saying this as an argument against doing it. I'm saying when
> you do it, it will be relatively more painful to add a new epoch field
> internal to the string than tacking on information at the end of the
> querystring AND the package filename.  We should make a vocal
> preemptive effort to get the word out before this lands in a release
> to take the edge off the disgruntled bloodlust for making a change.
> There is discussion in this thread about changing the filename as well
> as the rpmdb querystring to be self-consistent in terms of displaying
> the epoch. Any scripting against package  filenames will be disrupted
> by a new epoch field and I think that deserves some effort to raise
> awareness sooner rather than later.
> 
> -jef

This is an incredibly important point for everyone to stand back and think
through... the people this kind of 'small and relatively innocuous' change
effects are NOT all reading this list and commenting.  They are the people who
have no idea the change is coming, and won't notice until to their amazement its
breaking their previously working custom scripts in their own little lab
environment, etc.

'How much can an epoch in filenames hurt'?  Thats hard to say.  What does it
solve?  Nothing that everyone isn't already used to dealing with.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From packages at amiga-hardware.com  Wed Nov 28 02:07:45 2007
From: packages at amiga-hardware.com (Ian Chapman)
Date: Wed, 28 Nov 2007 02:07:45 +0000
Subject: Disable RPM's autoprovide function
In-Reply-To: <1196206283.23372.7.camel@Diffingo.localdomain>
References: <1196206283.23372.7.camel@Diffingo.localdomain>
Message-ID: <474CCD71.8050601@amiga-hardware.com>

Stewart Adam wrote:

> libGL.so.1 is automatically
> provided because of the scripts that RPM runs at the end of a build - Is
> there some way to override this or disable it so that libGL.so.1 is only
> provided by mesa-libGL?

There's some examples here for filtering dependencies, albeit for perl, 
it may be possible to adapt it or figure out something similar for sonames

http://fedoraproject.org/wiki/Packaging/Perl

There's also

AutoReqProv: no

which can be used to disable automatic dependency processing entirely 
but obviously any necessary dependencies would need to be specified 
manually. This is the 'sledgehammer  to crack a nut approach' I guess.


-- 
Ian Chapman.



From silfreed at silfreed.net  Wed Nov 28 02:40:49 2007
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Tue, 27 Nov 2007 21:40:49 -0500
Subject: AWOL: jpo
In-Reply-To: <1196199993.3054.2.camel@localhost.localdomain>
References: <1195574488.27963.27.camel@localhost.localdomain>
	<1196199993.3054.2.camel@localhost.localdomain>
Message-ID: <200711272140.50310.silfreed@silfreed.net>

On Tuesday 27 November 2007, Tom "spot" Callaway wrote:
> ? ? ? * eventlog -- Syslog-ng v2 support library
> ? ? ? * syslog-ng -- Syslog replacement daemon

I'll take these two if others aren't interested.

-Doug



From notting at redhat.com  Wed Nov 28 03:58:07 2007
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 27 Nov 2007 22:58:07 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071127152535.GA7102@traged.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
Message-ID: <20071128035807.GA3718@nostromo.devel.redhat.com>

Adam Tkac (atkac at redhat.com) said: 
> I've put this software to F8 because it has nice new features.

Really? Are our users clamoring for features *in bind* so much that we
should push an *alpha* version to released updates?

Heck, if so, let's just push all of GNOME 2.21 and xorg-1.4.99 into
F8 updates too.

If we want to get testing on it, and it's going into beta soon, put
it in rawhide. Maybe put it in updates-testing. Don't push it into
updates-stable; wait for an actual release for that.

Bill



From ob.system at gmail.com  Wed Nov 28 04:16:20 2007
From: ob.system at gmail.com (Oscar Victorio Calixto Bacho)
Date: Tue, 27 Nov 2007 22:16:20 -0600
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128035807.GA3718@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
Message-ID: <6a28481b0711272016o1816e5b3xf37b02a0226469e1@mail.gmail.com>

2007/11/27, Bill Nottingham <notting at redhat.com>:
>
> Adam Tkac (atkac at redhat.com) said:
> > I've put this software to F8 because it has nice new features.
>
> Really? Are our users clamoring for features *in bind* so much that we
> should push an *alpha* version to released updates?
>
> Heck, if so, let's just push all of GNOME 2.21 and xorg-1.4.99 into
> F8 updates too.
>
> If we want to get testing on it, and it's going into beta soon, put
> it in rawhide. Maybe put it in updates-testing. Don't push it into
> updates-stable; wait for an actual release for that.
>
> Bill
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Bill answer is true.

this must been use polity.


Oscar

XanKha
Linux De La Costa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071127/81b1bd74/attachment.htm>

From buildsys at redhat.com  Wed Nov 28 04:28:14 2007
From: buildsys at redhat.com (Build System)
Date: Tue, 27 Nov 2007 23:28:14 -0500
Subject: rawhide report: 20071127 changes
Message-ID: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>

New package R-rlecuyer
	R interface to RNG with multiple streams

New package accrete
	Accrete is a physical simulation of solar system planet formation

New package adanaxisgpl
	Action game in four spatial dimensions

New package gfs-artemisia-fonts
	GFS Artemisia fonts

New package gfs-bodoni-fonts
	GFS Bodoni fonts

New package gfs-didot-classic-fonts
	GFS Didot Classic Greek font

New package gfs-neohellenic-fonts
	GFS Neohellenic fonts

New package glade3
	User Interface Designer for GTK+ and GNOME

New package hyphen-da
	Danish hyphenation rules

New package hyphen-de
	German hyphenation rules

New package hyphen-hu
	Hungarian hyphenation rules

New package hyphen-it
	Italian hyphenation rules

New package hyphen-lt
	Lithuanian hyphenation rules

New package hyphen-nl
	Dutch hyphenation rules

New package hyphen-pl
	Polish hyphenation rules

New package hyphen-ru
	Russian hyphenation rules

New package hyphen-sl
	Slovenian hyphenation rules

New package libnids
	Implementation of an E-component of Network Intrusion Detection System

New package lrzip
	Compression program optimised for large files

New package osslsigncode
	Tool for Authenticode signing of EXE/CAB files

New package perl-MooseX-AttributeHelpers
	Extended Moose attribute interfaces

New package perl-Scope-Guard
	Lexically scoped resource management

New package siril
	Siril is an astronomical image processing software for Linux

New package xalan-c
	Xalan XSLT processor for C

New package zaf
	South Africa hyphenation rules


Removed package ksudoku

Updated Packages:

AcetoneISO-6.7-4.fc9
--------------------
* Mon Nov 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 6.7-4
- Requires: kdewebdev
NetworkManager-1:0.7.0-0.6.6.svn3109.fc9
----------------------------------------
* Mon Nov 26 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.6.svn3109
- Fix device descriptions shown in applet menu

* Mon Nov 26 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.5.svn3109
- Fix crash when deactivating VPN connections

* Mon Nov 19 2007 Dan Williams <dcbw at redhat.com> - 1:0.7.0-0.6.5.svn3096
- Fix crash and potential infinite nag dialog loop when ignoring CA certificates

R-2.6.1-1.fc9
-------------
* Mon Nov 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.1-1
- bump to 2.6.1

* Tue Oct 30 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3.1
- fix missing perl requires

* Mon Oct 29 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.6.0-3
- fix multilib conflicts (bz 343061)

apr-1.2.12-1.fc9
----------------
* Mon Nov 26 2007 Bojan Smojver <bojan at rexursive.com> 1.2.12-1
- bump up to 1.2.12
- add dist
- remove a comment from apr-1.2.7-psprintfpi.patch (applied upstream)

apr-util-1.2.12-1.fc9
---------------------
* Tue Nov 27 2007 Jesse Keating <jkeating at redhat.com> - 1.2.12-1
- bump up to 1.2.12
- drop MySQL DBD driver, shipped upstream
- adjust various patches to apply
- rework tests in %check (1.2.x got tests from trunk)

createrepo-0.4.11-1.fc9
-----------------------
* Mon Nov 26 2007 Luke Macken <lmacken at redhat.com> - 0.4.11-1
- Update to 0.4.11
- Include COPYING file and change License to GPLv2

docbook-dtds-1.0-35.fc9
-----------------------
* Mon Nov 26 2007 Ondrej Vasik <ovasik at redhat.com> - 1.0-35
- fixed bug causing typo in spec file(#397651)

doxygen-1:1.5.3-1.fc9
---------------------
* Fri Aug 10 2007 Than Ngo <than at redhat.com> - 1:1.5.3-1
- 1.5.3

evince-2.20.2-1.fc9
-------------------
* Tue Nov 27 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.2-1
- Update to 2.20.2

* Mon Nov 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-5
- Fix a problem in the tiff patch
- Turn off the dvi backend for now, since the tetex kpathsea 
  gives linker errors on x86_64

* Sat Nov 17 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-4
- Enable the dvi and djvu backends

file-roller-2.20.2-1.fc9
------------------------
* Mon Nov 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.2-1
- Update to 2.20.2 (translation updates)

foremost-1.5.2-1.fc9
--------------------
* Mon Nov 26 2007 Paul W. Frields <stickster at gmail.com> - 1.5.2-1
- Update to 1.5.2 on foremost.sf.net

gail-1.20.2-1.fc9
-----------------
* Mon Nov 26 2007 Matthias Clasen <mclasen at redhat.com> - 1.20.2-1
- Update to 1.20.2

gcin-1.3.7.1-1.fc9
------------------
* Tue Nov 27 2007 Chung-Yen Chang <candyz0416 at gmail.com> - 1.3.7.1-1
- update to 1.3.7.1

gcstar-1.3.0-1.fc9
------------------
* Mon Nov 26 2007 Tian <tian at c-sait.net> - 1.3.0-1
- New upstream version

gnome-keyring-2.20.2-1.fc9
--------------------------
* Mon Nov 26 2007 Matthias Clasen  <mclasen at redhat.com> - 2.20.2-1
- Update to 2.20.2

gnome-python2-extras-2.19.1-11.fc9
----------------------------------
* Mon Nov 26 2007 Martin Stransky <stransky at redhat.com> - 2.19.1-11.fc9
- Rebuild against gecko-libs 1.9 (xulrunner)

gnome-vfs2-obexftp-0.4-5.fc9
----------------------------
* Mon Nov 26 2007 - Bastien Nocera <bnocera at redhat.com> - 0.4-5
- And yet another go at (#345581)

* Mon Nov 26 2007 - Bastien Nocera <bnocera at redhat.com> - 0.4-4
- Another go at fixing (#345581)

gtk2-2.12.2-1.fc9
-----------------
* Mon Nov 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.2-1
- Update to 2.12.2

* Sun Nov 04 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-6
- Include the /usr/lib/gtk-2.0/2.10.0/filesystems directory

* Thu Oct 25 2007 Matthias Clasen <mclasen at redhat.com> - 2.12.1-5
- Fix a bug that prevents GtkBuilder-using apps (like totem)
  to run in some locales (like Turkish) (#348631)

gtkdatabox-0.8.0.1-2.fc9
------------------------
* Mon Nov 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.8.0.1-2
- fix license tag
- use rpm optflags

* Mon Nov 26 2007 Eric Work <work.eric at gmail.com> 0.8.0.1-1
- new upstream version

gtksourceview2-2.0.2-1.fc9
--------------------------
* Mon Nov 26 2007 Matthias Clasen <mclasen at redhat.com> - 2.0.2-1
- Update to 2.0.2

kdeutils-6:3.5.8-5.fc9
----------------------
* Mon Nov 26 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-5
- -extras: Requires: pm-utils (used by klaptopdaemon)

* Mon Nov 26 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 6:3.5.8-4
- include kregexpeditor in %description (#399281)

kernel-2.6.24-0.43.rc3.git1.fc9
-------------------------------
* Mon Nov 26 2007 David Woodhouse <dwmw2 at redhat.com>
- Build libertas wireless driver
- Include flash translation layers in modules.block list

* Sat Nov 24 2007 David Woodhouse <dwmw2 at redhat.com>
- Fix fec_mpc52xx Ethernet driver to use the right skbs

* Wed Nov 21 2007 John W. Linville <linville at redhat.com>
- Resync wireless bits from upstream

libsmbios-0.13.13-1.fc9
-----------------------
* Mon Nov 26 2007 Michael Brown <mebrown at michaels-house.net> - 0.13.13-1
- Fix for compiling with recent gcc (from Danny Kukawa @ suse)
- fix for lsb issues - moved binaries to /usr/sbin/ because they require admin
  privs to run. Made one backwards-compat symlink to work with existing HAL
  which expects current location.

libsoup-2.2.104-1.fc9
---------------------
* Mon Nov 26 2007 Matthew Barnes <mbarnes at redhat.com> - 2.2.104-1
- Update to 2.2.104

licq-1.3.4-8.fc9
----------------
* Mon Nov 26 2007 Jiri Moskovcak <jmoskovc at redhat.com> 1.3.4-8
- fixed sigsegv when new user requested authorization
- Resolves: #389731

* Tue Oct 02 2007 Jiri Moskovcak <jmoskovc at redhat.com> 1.3.4-7
- spec file clean-up removed htmlview from dependencies
- fixed problem with lupdate

* Tue Feb 27 2007 Peter Vrabec <pvrabec at redhat.com> 1.3.4-6
- build

lsdvd-0.16-6.fc9
----------------
* Mon Nov 26 2007 Matthias Saou <http://freshrpms.net/> 0.16-6
- Rebuild against new libdvdread.

lua-5.1.2-4.fc9
---------------
* Mon Nov 26 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 5.1.2-4
- Fix libdir in lua.pc being /usr/lib on x86_64 (bz 399101)

mock-0.8.10-1.fc9
-----------------
* Mon Nov 26 2007 Michael Brown <mebrown at michaels-house.net> - 0.8.10-1
- fix 'shell' command
- fix a couple different selinux avc denial messages (didnt affect functionality)

netpbm-10.35.34-1.fc9
---------------------
* Mon Nov 26 2007 Jindrich Novy <jnovy at redhat.com> 10.35.34-1
- update to 10.35.34
- sync security patch and fix typos

openoffice.org-dict-cs_CZ-20060303-7.fc9
----------------------------------------
* Mon Nov 26 2007 Tomas Mraz <tmraz at redhat.com> - 20060303-7
- add obsoletes openoffice.org-dict-cs_CZ

* Mon Nov 26 2007 Caolan McNamara <caolanm at redhat.com> - 20060303-6
- Resolves: rhbz#398361 move hyphenation rules into hyphen dir where OOo will now autodetect them

perl-JSON-1.15-1.fc9
--------------------
* Mon Nov 26 2007 Chris Weyl <cweyl at alumni.drew.edu> 1.15-1
- update to 1.15

php-eaccelerator-1:0.9.5.2-1.fc9
--------------------------------
* Mon Nov 26 2007 Matthias Saou <http://freshrpms.net/> 1:0.9.5.2-1
- Update to 0.9.5.2.

pidgin-2.3.0-1.fc9
------------------
* Mon Nov 26 2007 Stu Tomlinson <stu at nosnilmot.com> - 2.3.0-1
- 2.3.0

pirut-1.3.27-1.fc9
------------------
* Mon Nov 26 2007 Jeremy Katz <katzj at redhat.com> - 1.3.27-1
- Avoid a case where we could install with broken deps (#397161)
- Don't focus reboot by default (#395061)

python-TurboMail-2.1-1.fc9
--------------------------
* Mon Nov 26 2007 Luke Macken <lmacken at redhat.com> 2.1-1
- Update to 2.1

qt-1:3.3.8-11.fc9
-----------------
* Mon Nov 26 2007 Than Ngo <than at redhat.com> 3.3.8-11
- add Provides: qt3 = %version-%release

* Wed Nov 07 2007 Stepan Kasal <skasal at redhat.com> - 3.3.8-10
- rh#239216, fix a typo in qt-config description

* Thu Oct 04 2007 Than Ngo <than at redhat.com> - 3.3.8-9
- rh#309091, qt should provide %{qtdir}/plugins/styles
- rh#276521, qt-copy patches 0079, 0080, 0082 and 0084

rarian-0.7.0-1.fc9
------------------
* Mon Nov 26 2007 Matthew Barnes <mbarnes at redhat.com> - 0.7.0-1
- Update to 0.7.0

rpy-1.0-0.5.RC3.fc9
-------------------
* Mon Nov 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0-0.5.RC3
- really rebuild against R 2.6.1
- versioned buildrequires for R

* Mon Nov 26 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0-0.4.RC3
- rebuild against R 2.6.1

sbcl-1.0.12-1.fc9
-----------------
* Mon Nov 26 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.12-1
- sbcl-1.0.12

selinux-policy-3.1.2-1.fc9
--------------------------
* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 3.1.2-1
- Merge with upstream
- Allow xsever to read hwdata_t
- Allow login programs to setkeycreate

* Sat Nov 10 2007 Dan Walsh <dwalsh at redhat.com> 3.1.1-1
- Update to upstream

* Mon Oct 22 2007 Dan Walsh <dwalsh at redhat.com> 3.1.0-1
- Update to upstream

synaptic-0.57.2-14.fc9
----------------------
* Mon Nov 26 2007 Panu Matilainen <pmatilai at redhat.com> - 0.57.2-14
- remove unnecessary extra desktop categories (#283921)
- rebuild (#389371)

trac-git-plugin-0.0.1-4.20070705svn1536.fc9
-------------------------------------------
* Mon Nov 26 2007 Jesse Keating <jkeating at redhat.com> - 0.0.1-4.20070705svn1536
- Add a patch to prevent tracebacks when using this plugin
which-2.18-3.fc9
----------------
* Mon Nov 26 2007 Karsten Hopp <karsten at redhat.com> 2.18-3
- add dir entry for info page

wireshark-0.99.7-0.pre2.fc9
---------------------------
* Mon Nov 26 2007 Radek Vokal <rvokal at redhat.com> 0.99.7-0.pre2
- switch to libsmi from net-snmp
- disable ADNS due to its lack of Ipv6 support
- 0.99.7 prerelease 2

x86info-1:1.21-1.29.fc9
-----------------------
* Mon Nov 26 2007 Dave Jones <davej at redhat.com>
- Update to new upstream 1.21

xulrunner-1.9-0.beta1.2.fc9
---------------------------
* Mon Nov 26 2007 Martin Stransky <stransky at redhat.com> 1.9-0.beta1.2
- added xulrunner/js include dir to xulrunner-js

yafray-0.0.9-5.fc9
------------------
* Mon Oct 15 2007 kwizart < kwizart at gmail.com > - 0.0.9-5
- Fix: yafray libs are dlopened

zenity-2.20.1-1.fc9
-------------------
* Tue Nov 27 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.1-1
- Update to 2.20.1 (translation updates)

Broken deps for i386
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	conky - 1.4.8-1.fc9.i386 requires libaudacious.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	maxima-runtime-sbcl - 5.13.0-8.fc9.i386 requires sbcl = 0:1.0.11



Broken deps for x86_64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.x86_64 requires libaudacious.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	maxima-runtime-sbcl - 5.13.0-8.fc9.x86_64 requires sbcl = 0:1.0.11



Broken deps for ppc
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	conky - 1.4.8-1.fc9.ppc requires libaudacious.so.5
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	maxima-runtime-sbcl - 5.13.0-8.fc9.ppc requires sbcl = 0:1.0.11
	monodevelop - 0.17-4.fc9.ppc requires boo



Broken deps for ppc64
----------------------------------------------------------
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	conky - 1.4.8-1.fc9.ppc64 requires libaudacious.so.5()(64bit)
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump





From jspaleta at gmail.com  Wed Nov 28 04:32:14 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Nov 2007 19:32:14 -0900
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128035807.GA3718@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
Message-ID: <604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>

On Nov 27, 2007 6:58 PM, Bill Nottingham <notting at redhat.com> wrote:
> Adam Tkac (atkac at redhat.com) said:
> > I've put this software to F8 because it has nice new features.
>
> Really? Are our users clamoring for features *in bind* so much that we
> should push an *alpha* version to released updates?

Uhm i dont think this started with the latest update... i think the
version released in f8 was also a pre-release.

-jef



From rc040203 at freenet.de  Wed Nov 28 05:14:20 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Nov 2007 06:14:20 +0100
Subject: rawhide report: 20071127 changes
In-Reply-To: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
Message-ID: <1196226860.12310.613.camel@mccallum.corsepiu.local>


On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:

> doxygen-1:1.5.3-1.fc9
> ---------------------
> * Fri Aug 10 2007 Than Ngo <than at redhat.com> - 1:1.5.3-1
> - 1.5.3

Does this version fix the "anchor issue" which so far has been breaking
multilibs?

Ralf




From notting at redhat.com  Wed Nov 28 05:30:10 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 28 Nov 2007 00:30:10 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>
Message-ID: <20071128053010.GA10110@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> > Really? Are our users clamoring for features *in bind* so much that we
> > should push an *alpha* version to released updates?
> 
> Uhm i dont think this started with the latest update... i think the
> version released in f8 was also a pre-release.

I stand correct. I still don't feel it's appropriate for a released
tree when in the alpha state - after all, the current supported release
of bind was made in July - that's not that long ago.

Bill



From cmadams at hiwaay.net  Wed Nov 28 05:31:50 2007
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 27 Nov 2007 23:31:50 -0600
Subject: Disable RPM's autoprovide function
In-Reply-To: <1196206283.23372.7.camel@Diffingo.localdomain>
References: <1196206283.23372.7.camel@Diffingo.localdomain>
Message-ID: <20071128053150.GA536799@hiwaay.net>

Once upon a time, Stewart Adam <s.adam at diffingo.com> said:
> A bug report at Livna (#1741) pointed out that the
> xorg-x11-drv-nvidia-libs-32bit package is pulled in over mesa-libGL.i386
> when the 32-bit library "libGL.so.1" is required on x86_64 (in the
> user's case, it was while installing wine). libGL.so.1 is automatically
> provided because of the scripts that RPM runs at the end of a build - Is
> there some way to override this or disable it so that libGL.so.1 is only
> provided by mesa-libGL?

This comes up with perl modules regularly (as someone else has pointed
to the hack used there).

Why does RPM (well, the scripts used in rpm-build) look in non-standard
directories?  Shouldn't libraries only be automatically "provided" if
they are in standard library directories, perl modules should only be
"provided" if they are in standard perl directories, etc.?

This would complicate automatic requires for these packages.  E.g. a
perl app that has a private module Foo::Bar would automatically get a
requires perl(Foo::Bar), but maybe the process could be something like:

(a) find standard directory provides
(b) find non-standard directory provides
(c) find all requires
(d) auto-filter (b) from (c)

There'd need to be a way for packages to add directories to the standard
list in a spec file (for packages that have their own library
directories but add them to /etc/ld.so.conf.d for example), and maybe
take -rpath info into consideration for libraries (and use lib "blah" in
perl, and so on for other auto-req-prov things).

Maybe at least rpmlint could warn about possible problems.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From rc040203 at freenet.de  Wed Nov 28 05:44:10 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Nov 2007 06:44:10 +0100
Subject: Disable RPM's autoprovide function
In-Reply-To: <20071128053150.GA536799@hiwaay.net>
References: <1196206283.23372.7.camel@Diffingo.localdomain>
	<20071128053150.GA536799@hiwaay.net>
Message-ID: <1196228650.12310.632.camel@mccallum.corsepiu.local>


On Tue, 2007-11-27 at 23:31 -0600, Chris Adams wrote:
> Once upon a time, Stewart Adam <s.adam at diffingo.com> said:
> > A bug report at Livna (#1741) pointed out that the
> > xorg-x11-drv-nvidia-libs-32bit package is pulled in over mesa-libGL.i386
> > when the 32-bit library "libGL.so.1" is required on x86_64 (in the
> > user's case, it was while installing wine). libGL.so.1 is automatically
> > provided because of the scripts that RPM runs at the end of a build - Is
> > there some way to override this or disable it so that libGL.so.1 is only
> > provided by mesa-libGL?
> 
> This comes up with perl modules regularly (as someone else has pointed
> to the hack used there).
Right. IMO, rpm's procedure to extract perl autoprovides on "*.so"'s is
"simply broken/wrong".

> Why does RPM (well, the scripts used in rpm-build) look in non-standard
> directories?  Shouldn't libraries only be automatically "provided" if
> they are in standard library directories, perl modules should only be
> "provided" if they are in standard perl directories, etc.?
Wrt. perl's *.so, IMO definitely yes. 

Wrt. to general libs, I am inclined to agree, too. But there are some
corner-cases, people felt rpm's current way is the "right thing" (e.g.
packages manipulating ld.so.conf or supplying /etc/ld.so.conf.d/*).

Ralf





From tibbs at math.uh.edu  Wed Nov 28 05:56:16 2007
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 27 Nov 2007 23:56:16 -0600
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196193744.3229.54.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
Message-ID: <ufahcj6vrpb.fsf@epithumia.math.uh.edu>

>>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:

TC> Such as? Open to suggestions here.

We had
http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
which was never finished; the only thing in there is "Maintain
stability for users".  I honestly don't see how you can be much more
specific without introducing needless bureaucracy.  After all, the
alpha releases of some projects are more stable then the full releases
of others.

 - J<



From Lam at Lam.pl  Wed Nov 28 06:18:57 2007
From: Lam at Lam.pl (Leszek Matok)
Date: Wed, 28 Nov 2007 07:18:57 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <200711271902.11321@rineau.tsetse>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<200711271351.31664@rineau.tsetse>
	<1196184688.26555.63.camel@localhost.localdomain>
	<200711271902.11321@rineau.tsetse>
Message-ID: <20071128071857.2a643904@pensja.lam.pl>

Dnia 2007-11-27, o godz. 19:02:11 Laurent Rineau
<laurent.rineau__fedora at normalesup.org> napisa?(a):

> 8.3 is a pre-FAT32 limitation. Since Windows?XP, everybody uses FAT32
> instead of the old FAT (even Windows?95 can read and write to FAT32).
You're confusing FAT32 with VFAT.

Lam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/5260e496/attachment.sig>

From caillon at redhat.com  Wed Nov 28 06:33:48 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 28 Nov 2007 07:33:48 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <ufahcj6vrpb.fsf@epithumia.math.uh.edu>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
Message-ID: <474D0BCC.5010800@redhat.com>

On 11/28/2007 06:56 AM, Jason L Tibbitts III wrote:
>>>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
> 
> TC> Such as? Open to suggestions here.
> 
> We had
> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
> which was never finished; the only thing in there is "Maintain
> stability for users".  I honestly don't see how you can be much more
> specific without introducing needless bureaucracy.  After all, the
> alpha releases of some projects are more stable then the full releases
> of others.

This seems pretty much perfect, actually.  What does it need in order to 
be "finished"?



From nicolas.mailhot at laposte.net  Wed Nov 28 07:18:13 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 28 Nov 2007 08:18:13 +0100
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <6c3f5e6c0711271433p2cd98c32q2104a82fe2255615@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
	<6c3f5e6c0711271433p2cd98c32q2104a82fe2255615@mail.gmail.com>
Message-ID: <1196234293.8588.0.camel@rousalka.dyndns.org>


Le mardi 27 novembre 2007 ? 17:33 -0500, Andrew Parker a ?crit :
> On Nov 27, 2007 5:06 PM, KH KH <kwizart at gmail.com> wrote:

> > ivtv-firmware and xorg-x11-drv-ivtv have been approved but still were
> > not imported because of "competing" review request... (my website is
> > offline for the next 24hours)

> I don't think that's quite true.  The driver is now part of the
> kernel, but you still need to install the firmware and the userland
> tools such as ivtvctl.

Read again the last bit of Nicolas's post.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/7a24cd31/attachment.sig>

From laurent.rineau__fedora at normalesup.org  Wed Nov 28 08:48:26 2007
From: laurent.rineau__fedora at normalesup.org (Laurent Rineau)
Date: Wed, 28 Nov 2007 09:48:26 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071128071857.2a643904@pensja.lam.pl>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<200711271902.11321@rineau.tsetse>
	<20071128071857.2a643904@pensja.lam.pl>
Message-ID: <200711280948.26798@rineau.tsetse>

On Wednesday 28 November 2007 07:18:57 Leszek Matok wrote:
> Dnia 2007-11-27, o godz. 19:02:11 Laurent Rineau
>
> <laurent.rineau__fedora at normalesup.org> napisa?(a):
> > 8.3 is a pre-FAT32 limitation. Since Windows?XP, everybody uses FAT32
> > instead of the old FAT (even Windows?95 can read and write to FAT32).
>
> You're confusing FAT32 with VFAT.

I have simplified, intentionally.

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau



From ch.nolte at noltec.org  Wed Nov 28 08:56:15 2007
From: ch.nolte at noltec.org (Christian Nolte)
Date: Wed, 28 Nov 2007 09:56:15 +0100
Subject: SDL pulseaudio workaround hack
In-Reply-To: <474B7512.3080408@redhat.com>
References: <474B7512.3080408@redhat.com>
Message-ID: <474D2D2F.5030308@noltec.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Warren Togami schrieb:
> * Tue Oct 30 2007 Warren Togami <wtogami at redhat.com> - 1.2.8-4
> - SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio directly
>   avoids applications from locking up. (#358341)
> 
> At the last minute before F-8's release I added this ugly hack to
> SDL_mixer to force SDL to use esd for sound instead of the default ALSA.
>  This change was made because it would at least allow sound on popular
> games like wesnoth to work, and make the Fedora Games spin not
> dead-on-arrival.
> 
> Unfortunately, this had the side-effect that we knew at the time of
> disabling SDL sound if you have pulseaudio disabled or removed.
> 
> I should have thought of this earlier, but the /etc/profile.d/* scripts
> that set the environment variable commanding SDL to use esd could have
> been conditional.  Still not perfect, but better to tide us over until
> Lennart implements native pulseaudio for SDL that he promised to do
> before F9.
> 
> The following changes should improve our workaround.  I am uncertain if
> the .csh version needs a matching unset for nonomatch or does it happen
> automatically?
> 
> Should we push this in a SDL_mixer update?

Please consider putting the workaround in the SDL-Package as not every
program which uses SDL has a dependency on SDL_mixer. See BUG #343911.

Best regards!
Christian

- --
For more than 4 generations the IT Professionals were the guardians
of quality and stability in software. Before the dark times.
Before Microsoft...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHTS0uCNjA0nfhW7wRAsw0AKDM2gTZe/OR/olXzgBJt28yBcEDjwCeNo9u
NAfgeVwaZX2pbawbtt61D0U=
=IeOD
-----END PGP SIGNATURE-----



From sander at hoentjen.eu  Wed Nov 28 08:57:49 2007
From: sander at hoentjen.eu (Sander Hoentjen)
Date: Wed, 28 Nov 2007 09:57:49 +0100
Subject: rawhide report: 20071127 changes
In-Reply-To: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
Message-ID: <1196240269.1109.10.camel@peecee.hoentjen.eu>

On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> New package zaf
>         South Africa hyphenation rules

Is it intentional that this one is not called hyphen-zaf?

Sander



From paul at all-the-johnsons.co.uk  Wed Nov 28 09:09:38 2007
From: paul at all-the-johnsons.co.uk (Paul F. Johnson)
Date: Wed, 28 Nov 2007 09:09:38 +0000
Subject: Orphaning packages
Message-ID: <20071128090938.M51926@all-the-johnsons.co.uk>

Hi,

Just to let you know that other than the mono packages I currently maintain,
I'm going to have to drop the other packages I have down for me.

For ease, if it's a mono or mono-related package (such as mono-develop,
libgdiplus, db4o etc), I'll maintain it. Anything else is dropped. I'll update
the wiki and the owners lists as soon as I can.

Basically, it's the old problem of time....

TTFN

Paul

--
Get your free @ukpost.com account now
http://www.ukpost.com/



From pat at ge3k.net  Wed Nov 28 09:38:46 2007
From: pat at ge3k.net (Patrick Ohearn)
Date: Wed, 28 Nov 2007 19:38:46 +1000
Subject: rawhide report: 20071127 changes
In-Reply-To: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
Message-ID: <1196242726.7360.0.camel@asmodeus.localdomain>


On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> New package R-rlecuyer
> 	R interface to RNG with multiple streams
> 
Is there a web interface for checking different versions in different
repos, say like packages.gentoo.org and packages.debian.org?
-- 
Email: pat at ge3k.net
Jabber: pat at ge3k.net
Site: http://ge3k.net
PGP Key: 66A612C6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/d65eaccc/attachment.sig>

From debarshi.ray at gmail.com  Wed Nov 28 09:43:28 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Wed, 28 Nov 2007 15:13:28 +0530
Subject: Orphaning packages
In-Reply-To: <20071128090938.M51926@all-the-johnsons.co.uk>
References: <20071128090938.M51926@all-the-johnsons.co.uk>
Message-ID: <3170f42f0711280143x41c62729scff8e295ec772c3c@mail.gmail.com>

Can I take over anjuta and anjuta-gdl? I was anyway planning to bump
them and ask for co-maintainership.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From panemade at gmail.com  Wed Nov 28 09:48:33 2007
From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=)
Date: Wed, 28 Nov 2007 15:18:33 +0530
Subject: rawhide report: 20071127 changes
In-Reply-To: <1196242726.7360.0.camel@asmodeus.localdomain>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196242726.7360.0.camel@asmodeus.localdomain>
Message-ID: <f4586a2e0711280148q89211c5wf9df98dc03470952@mail.gmail.com>

On Nov 28, 2007 3:08 PM, Patrick Ohearn <pat at ge3k.net> wrote:
>
> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> > New package R-rlecuyer
> >       R interface to RNG with multiple streams
> >
> Is there a web interface for checking different versions in different
> repos, say like packages.gentoo.org and packages.debian.org?

   Have you seen https://admin.fedoraproject.org/pkgdb/ ?
Regards,
Parag.



From rjones at redhat.com  Wed Nov 28 10:20:14 2007
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 28 Nov 2007 10:20:14 +0000
Subject: rawhide report: 20071127 changes
In-Reply-To: <f4586a2e0711280148q89211c5wf9df98dc03470952@mail.gmail.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>	<1196242726.7360.0.camel@asmodeus.localdomain>
	<f4586a2e0711280148q89211c5wf9df98dc03470952@mail.gmail.com>
Message-ID: <474D40DE.6080404@redhat.com>

Parag N(????) wrote:
> On Nov 28, 2007 3:08 PM, Patrick Ohearn <pat at ge3k.net> wrote:
>> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
>>> New package R-rlecuyer
>>>       R interface to RNG with multiple streams
>>>
>> Is there a web interface for checking different versions in different
>> repos, say like packages.gentoo.org and packages.debian.org?
> 
>    Have you seen https://admin.fedoraproject.org/pkgdb/ ?

Yes.  It's very slow, and crucially it seems to lack a search interface 
so you have to page (slowly) through the list of packages.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/61fd7ce8/attachment.bin>

From atkac at redhat.com  Wed Nov 28 10:24:29 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 11:24:29 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
Message-ID: <20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>

On Tue, Nov 27, 2007 at 11:41:13PM +0100, Mark wrote:
> 
> Hey,
> 
> I understand why you choose to include it but i don't really like it.
> If i run a server i want to have the latest _stable_ releases and
> certainly no alpha (BIND) beta or even a build (NetworkManager)! now i
> can imagine that desktop applications that aren't in a final release
> can get pushed in Fedora because it simply has some nice additions
> that you don't want your users to miss. But BIND is a vital part of a
> server (DNS Server) so i think you shouldn't include beta's or even
> alpha's of that in final releases of Fedora.
> 
> And you say:
> > Fedora has new features and new features mean bugs so you
> > cannot expect such stability like RHEL.
> 
> Oke i understand that. BUT the fact that you do push a vital server
> component that is in alpha in Fedora does imply that you are testing
> it on fedora for RHEL! (which in term keeps your other statement
> standing).
> 
> Fedora is used for servers (which you as a redhat employee probably
> know) but in the mean time it's purpose is mainly a desktop OS. I
> would say that:
>  - All server components like Sendmail, DNS, Apache, MySQL, PostgreSQL
> etc.. should stay up to date with there latest _stable_ release (no
> alpha's, beta's or rc's)
>  - All desktop related applications can probably be less tight.. I
> don't see a problem there for alpha's, beta's or rc's.. as long as the
> applications itself don't crash and just work.
> 
> That's just my point of view as a fedora desktop and (previously) server user.

>From BIND changelog:
* Tue Jun 19 2007 Adam Tkac <atkac redhat com> 31:9.5.0a5-1

It means BIND lives in rawhide/F8 about five months and I have
reported only one more serious issue (#400461, that is why this thread
was started). I believe that "a" word appended to version feels people
with dread but I have to say not in this case. I'm ready to downgrade
F8 BIND to latest stable but I can't see any argument why. One bug?
Because it is alpha? These are not arguments whose could controvert my
opinion that it was good decision put 9.5 to F8

Adam

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From tmz at pobox.com  Wed Nov 28 10:28:44 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 28 Nov 2007 05:28:44 -0500
Subject: rawhide report: 20071127 changes
In-Reply-To: <1196226860.12310.613.camel@mccallum.corsepiu.local>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196226860.12310.613.camel@mccallum.corsepiu.local>
Message-ID: <20071128102843.GS8224@psilocybe.teonanacatl.org>

Ralf Corsepius wrote:
> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> 
>> doxygen-1:1.5.3-1.fc9
>> ---------------------
>> * Fri Aug 10 2007 Than Ngo <than at redhat.com> - 1:1.5.3-1
>> - 1.5.3
> 
> Does this version fix the "anchor issue" which so far has been
> breaking multilibs?

That's the hope.  Check https://bugzilla.redhat.com/349361 

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When we remember we are all mad, the mysteries of life disappear and
life stands explained.
    -- Mark Twain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/3e0814ce/attachment.sig>

From atkac at redhat.com  Wed Nov 28 10:30:32 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 11:30:32 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128053010.GA10110@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>
	<20071128053010.GA10110@nostromo.devel.redhat.com>
Message-ID: <20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 12:30:10AM -0500, Bill Nottingham wrote:
> Jeff Spaleta (jspaleta at gmail.com) said: 
> > > Really? Are our users clamoring for features *in bind* so much that we
> > > should push an *alpha* version to released updates?
> > 
> > Uhm i dont think this started with the latest update... i think the
> > version released in f8 was also a pre-release.
> 
> I stand correct. I still don't feel it's appropriate for a released
> tree when in the alpha state - after all, the current supported release
> of bind was made in July - that's not that long ago.
> 
> Bill

As I wrote above I disagree with you that put alpha (which will come
to beta really soon) to F8 is bad decision "because it is alpha". I
tested it and I didn't find any issues. That's why I decided put 9.5
to F8.

Adam

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From pertusus at free.fr  Wed Nov 28 10:31:18 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 28 Nov 2007 11:31:18 +0100
Subject: rawhide report: 20071127 changes
In-Reply-To: <474D40DE.6080404@redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196242726.7360.0.camel@asmodeus.localdomain>
	<f4586a2e0711280148q89211c5wf9df98dc03470952@mail.gmail.com>
	<474D40DE.6080404@redhat.com>
Message-ID: <20071128103118.GA2805@free.fr>

On Wed, Nov 28, 2007 at 10:20:14AM +0000, Richard W.M. Jones wrote:
> Parag N(????) wrote:
>> On Nov 28, 2007 3:08 PM, Patrick Ohearn <pat at ge3k.net> wrote:
>>> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
>>>> New package R-rlecuyer
>>>>       R interface to RNG with multiple streams
>>>>
>>> Is there a web interface for checking different versions in different
>>> repos, say like packages.gentoo.org and packages.debian.org?
>>
>>    Have you seen https://admin.fedoraproject.org/pkgdb/ ?
>
> Yes.  It's very slow, and crucially it seems to lack a search interface so 
> you have to page (slowly) through the list of packages.

In any case it is not an interface for packages. Once there was
repoview, but it seems that it isn't provided anymore. koji has also an
interface for packages, but it is more build/developper oriented and 
too complicated for a package browsing tool in my opinion.

--
Pat



From laroche at redhat.com  Wed Nov 28 10:33:19 2007
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 28 Nov 2007 11:33:19 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
Message-ID: <20071128103319.GA4853@dudweiler.stuttgart.redhat.com>

> >From BIND changelog:
> * Tue Jun 19 2007 Adam Tkac <atkac redhat com> 31:9.5.0a5-1
> 
> It means BIND lives in rawhide/F8 about five months and I have
> reported only one more serious issue (#400461, that is why this thread
> was started). I believe that "a" word appended to version feels people
> with dread but I have to say not in this case. I'm ready to downgrade
> F8 BIND to latest stable but I can't see any argument why. One bug?
> Because it is alpha? These are not arguments whose could controvert my
> opinion that it was good decision put 9.5 to F8


Hello Adam,

I think an alpha release might be ok if we need to move forward
for certain features, but we should try hard to stay on a stable
release. So if that is possible, a released version makes much more
sense.

regards,

Florian La Roche



From tmraz at redhat.com  Wed Nov 28 10:37:03 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 28 Nov 2007 11:37:03 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
Message-ID: <1196246223.23384.52.camel@vespa.kabelta.loc>


On Wed, 2007-11-28 at 11:24 +0100, Adam Tkac wrote:
> On Tue, Nov 27, 2007 at 11:41:13PM +0100, Mark wrote:
> > 
> > Hey,
> > 
> > I understand why you choose to include it but i don't really like it.
> > If i run a server i want to have the latest _stable_ releases and
> > certainly no alpha (BIND) beta or even a build (NetworkManager)! now i
> > can imagine that desktop applications that aren't in a final release
> > can get pushed in Fedora because it simply has some nice additions
> > that you don't want your users to miss. But BIND is a vital part of a
> > server (DNS Server) so i think you shouldn't include beta's or even
> > alpha's of that in final releases of Fedora.
> > 
> > And you say:
> > > Fedora has new features and new features mean bugs so you
> > > cannot expect such stability like RHEL.
> > 
> > Oke i understand that. BUT the fact that you do push a vital server
> > component that is in alpha in Fedora does imply that you are testing
> > it on fedora for RHEL! (which in term keeps your other statement
> > standing).
> > 
> > Fedora is used for servers (which you as a redhat employee probably
> > know) but in the mean time it's purpose is mainly a desktop OS. I
> > would say that:
> >  - All server components like Sendmail, DNS, Apache, MySQL, PostgreSQL
> > etc.. should stay up to date with there latest _stable_ release (no
> > alpha's, beta's or rc's)
> >  - All desktop related applications can probably be less tight.. I
> > don't see a problem there for alpha's, beta's or rc's.. as long as the
> > applications itself don't crash and just work.
> > 
> > That's just my point of view as a fedora desktop and (previously) server user.
> 
> >From BIND changelog:
> * Tue Jun 19 2007 Adam Tkac <atkac redhat com> 31:9.5.0a5-1
> 
> It means BIND lives in rawhide/F8 about five months and I have
> reported only one more serious issue (#400461, that is why this thread
> was started). I believe that "a" word appended to version feels people
> with dread but I have to say not in this case. I'm ready to downgrade
> F8 BIND to latest stable but I can't see any argument why. One bug?
> Because it is alpha? These are not arguments whose could controvert my
> opinion that it was good decision put 9.5 to F8

I have to agree with you. The "alpha" name in version mostly doesn't
mean much. If you really tested it thoroughly I don't think you should
be blamed. Because otherwise nobody could allow for example Evolution
into the distro as it sometimes eats e-mails in my configuration (the
bug is reported upstream for a long time and no fix is ahead).

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From mschwendt.tmp0701.nospam at arcor.de  Wed Nov 28 10:41:11 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 28 Nov 2007 11:41:11 +0100
Subject: Disable RPM's autoprovide function
In-Reply-To: <474CCD71.8050601@amiga-hardware.com>
References: <1196206283.23372.7.camel@Diffingo.localdomain>
	<474CCD71.8050601@amiga-hardware.com>
Message-ID: <20071128114111.acc9ebdb.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 28 Nov 2007 02:07:45 +0000, Ian Chapman wrote:

> Stewart Adam wrote:
> 
> > libGL.so.1 is automatically
> > provided because of the scripts that RPM runs at the end of a build - Is
> > there some way to override this or disable it so that libGL.so.1 is only
> > provided by mesa-libGL?
> 
> There's some examples here for filtering dependencies, albeit for perl, 
> it may be possible to adapt it or figure out something similar for sonames
> 
> http://fedoraproject.org/wiki/Packaging/Perl
> 
> There's also
> 
> AutoReqProv: no
> 
> which can be used to disable automatic dependency processing entirely 
> but obviously any necessary dependencies would need to be specified 
> manually. This is the 'sledgehammer  to crack a nut approach' I guess.

http://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies



From nphilipp at redhat.com  Wed Nov 28 10:43:47 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Wed, 28 Nov 2007 11:43:47 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071127112914.264fa595@redhat.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
Message-ID: <1196246627.27991.17.camel@wombat.tiptoe.de>


On Tue, 2007-11-27 at 11:29 -0500, Jesse Keating wrote:
> On Tue, 27 Nov 2007 17:12:38 +0100
> Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> 
> > Because no packager should ever bump %epoch without bumping %release.
> > Rule of thumb: New build => new release.
> 
> In fact, koji enforces this.  Koji stores builds based on n-v-r, not
> n-e-v-r, so if you only just bump epoch, koji will give you an error.

Psst. That isn't something I would tout as a feature ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From stransky at redhat.com  Wed Nov 28 11:05:12 2007
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 28 Nov 2007 12:05:12 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127152535.GA7102@traged.englab.brq.redhat.com>	<20071128035807.GA3718@nostromo.devel.redhat.com>	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>	<20071128053010.GA10110@nostromo.devel.redhat.com>
	<20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>
Message-ID: <474D4B68.7010909@redhat.com>

Adam Tkac wrote:
> As I wrote above I disagree with you that put alpha (which will come
> to beta really soon) to F8 is bad decision "because it is alpha". I
> tested it and I didn't find any issues. That's why I decided put 9.5
> to F8.
> 
> Adam

Is a former bind maintainer I have to support Adam here. In my opinion 
it depends what package is taken and it's really a big difference 
between a huge project (like gnome/gcc) and relative small one like bind.

Bind alpha/beta versions are periodically more stable than other 
**stable** projects.

Anyway, do you know what rules have upstreams of all our packages? What 
is a stable version in one can be an alpha for others. We can hardly 
make strict general rules if reliable and balanced measure is missing.

Martin



From rc040203 at freenet.de  Wed Nov 28 11:07:19 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Nov 2007 12:07:19 +0100
Subject: rawhide report: 20071127 changes
In-Reply-To: <20071128102843.GS8224@psilocybe.teonanacatl.org>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196226860.12310.613.camel@mccallum.corsepiu.local>
	<20071128102843.GS8224@psilocybe.teonanacatl.org>
Message-ID: <1196248039.12310.710.camel@mccallum.corsepiu.local>


On Wed, 2007-11-28 at 05:28 -0500, Todd Zullinger wrote:
> Ralf Corsepius wrote:
> > On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> > 
> >> doxygen-1:1.5.3-1.fc9
> >> ---------------------
> >> * Fri Aug 10 2007 Than Ngo <than at redhat.com> - 1:1.5.3-1
> >> - 1.5.3
> > 
> > Does this version fix the "anchor issue" which so far has been
> > breaking multilibs?
> 
> That's the hope.  Check https://bugzilla.redhat.com/349361 
I know, several of my packages suffer from this issue and I would have
liked to know if this doxygen is supposed to fix it, before I going to
invest time myself ;)

Ralf




From jkeating at redhat.com  Wed Nov 28 11:47:18 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 06:47:18 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196246627.27991.17.camel@wombat.tiptoe.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
	<1196246627.27991.17.camel@wombat.tiptoe.de>
Message-ID: <20071128064718.31c0c40c@redhat.com>

On Wed, 28 Nov 2007 11:43:47 +0100
Nils Philippsen <nphilipp at redhat.com> wrote:

> > In fact, koji enforces this.  Koji stores builds based on n-v-r, not
> > n-e-v-r, so if you only just bump epoch, koji will give you an
> > error.  
> 
> Psst. That isn't something I would tout as a feature ;-).

It is.  This was a very intentional design item.  We wanted to make
sure that when a maintainer bumped epoch, they /had/ to bump something
else of nvr with it.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/fa11fda6/attachment.sig>

From kevin.kofler at chello.at  Wed Nov 28 11:49:23 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Nov 2007 11:49:23 +0000 (UTC)
Subject: Orphaning packages
References: <20071128090938.M51926@all-the-johnsons.co.uk>
Message-ID: <loom.20071128T114759-191@post.gmane.org>

Paul F. Johnson <paul <at> all-the-johnsons.co.uk> writes:
> Just to let you know that other than the mono packages I currently maintain,
> I'm going to have to drop the other packages I have down for me.
> 
> For ease, if it's a mono or mono-related package (such as mono-develop,
> libgdiplus, db4o etc), I'll maintain it. Anything else is dropped. I'll
> update the wiki and the owners lists as soon as I can.

I'll take z88dk.

        Kevin Kofler



From tcallawa at redhat.com  Wed Nov 28 12:46:53 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Nov 2007 07:46:53 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474D0BCC.5010800@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
Message-ID: <1196254013.3054.58.camel@localhost.localdomain>


On Wed, 2007-11-28 at 07:33 +0100, Christopher Aillon wrote:
> On 11/28/2007 06:56 AM, Jason L Tibbitts III wrote:
> >>>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
> > 
> > TC> Such as? Open to suggestions here.
> > 
> > We had
> > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
> > which was never finished; the only thing in there is "Maintain
> > stability for users".  I honestly don't see how you can be much more
> > specific without introducing needless bureaucracy.  After all, the
> > alpha releases of some projects are more stable then the full releases
> > of others.
> 
> This seems pretty much perfect, actually.  What does it need in order to 
> be "finished"?

Well, I'm not sure how it can be considered perfect when it does not
begin to address the "alpha/beta" issue that you think is resolvable
with packaging policy.

FWIW, I agree with Tibbs, since we have no way of determining how stable
package releases are without trusting the maintainer.

~spot



From jkeating at redhat.com  Wed Nov 28 12:55:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 07:55:34 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196254013.3054.58.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
Message-ID: <20071128075534.716563b5@redhat.com>

On Wed, 28 Nov 2007 07:46:53 -0500
"Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:

> Well, I'm not sure how it can be considered perfect when it does not
> begin to address the "alpha/beta" issue that you think is resolvable
> with packaging policy.

"In general, it is preferred if maintainers avoid releasing "alpha" or
"beta" builds of packages into Fedora (both Rawhide and released
updates).  However a package maintainer has the right to use their own
discretion regarding this issue and may provide whatever (s)he sees fit
for the user base.  Things to consider include the amount of testing an
alpha or beta release has seen, the timeline to turn said alpha or beta
into a stable release, the feature sets provided, or the bugs fixed.
There may be other factors at play as well, which is why the person
best suited to make such a decision is the package maintainer in
question."

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/9f152012/attachment.sig>

From sgrubb at redhat.com  Wed Nov 28 13:48:24 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 28 Nov 2007 08:48:24 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128075534.716563b5@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
Message-ID: <200711280848.24953.sgrubb@redhat.com>

On Wednesday 28 November 2007 07:55:34 Jesse Keating wrote:
> "In general, it is preferred if maintainers avoid releasing "alpha" or
> "beta" builds of packages into Fedora (both Rawhide and released
> updates).

How about unreleased cvs snapshots? kdepim in F7 failed to work after a recent 
upgrade (and had been working fine) and my problem was only solved by 
upgrading to F8 which had a more recent cvs snapshot that is still buggy but 
usable. Rolling back did not work. The only support I got by the Fedora 
maintainer was telling me to report it upstream. Upstream does not support it 
because its a cvs snapshot and not a released version.

What do we do about that? This is the current status of kdepim in both F7 & 8.

-Steve



From opensource at till.name  Wed Nov 28 14:19:30 2007
From: opensource at till.name (Till Maas)
Date: Wed, 28 Nov 2007 15:19:30 +0100
Subject: Orphaning packages
In-Reply-To: <20071128090938.M51926@all-the-johnsons.co.uk>
References: <20071128090938.M51926@all-the-johnsons.co.uk>
Message-ID: <200711281519.39167.opensource@till.name>

On Mi November 28 2007, Paul F. Johnson wrote:

> For ease, if it's a mono or mono-related package (such as mono-develop,
> libgdiplus, db4o etc), I'll maintain it. Anything else is dropped. I'll
> update the wiki and the owners lists as soon as I can.

You have to use the package db to release ownership:

https://admin.fedoraproject.org/pkgdb/users/packages/pfj

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/b94c5be0/attachment.sig>

From tcallawa at redhat.com  Wed Nov 28 14:22:16 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Nov 2007 09:22:16 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711280848.24953.sgrubb@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
Message-ID: <1196259736.3054.60.camel@localhost.localdomain>


On Wed, 2007-11-28 at 08:48 -0500, Steve Grubb wrote:
> On Wednesday 28 November 2007 07:55:34 Jesse Keating wrote:
> > "In general, it is preferred if maintainers avoid releasing "alpha" or
> > "beta" builds of packages into Fedora (both Rawhide and released
> > updates).
> 
> How about unreleased cvs snapshots? 

Not just that, we should pull out cdparanoia, as it has been in alpha
since 2001. :P

~spot



From jkeating at redhat.com  Wed Nov 28 14:28:34 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 09:28:34 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711280848.24953.sgrubb@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
Message-ID: <20071128092834.46014249@redhat.com>

On Wed, 28 Nov 2007 08:48:24 -0500
Steve Grubb <sgrubb at redhat.com> wrote:

> How about unreleased cvs snapshots? kdepim in F7 failed to work after
> a recent upgrade (and had been working fine) and my problem was only
> solved by upgrading to F8 which had a more recent cvs snapshot that
> is still buggy but usable. Rolling back did not work. The only
> support I got by the Fedora maintainer was telling me to report it
> upstream. Upstream does not support it because its a cvs snapshot and
> not a released version.
> 
> What do we do about that? This is the current status of kdepim in
> both F7 & 8.

This again falls under the Maintainer's discretion.  They can choose to
backport a specific fix as a patch, or pick up a CVS snapshot and run
with it, in order to fix the bug(s) in question.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/df27196e/attachment.sig>

From jkeating at redhat.com  Wed Nov 28 14:29:19 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 09:29:19 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196259736.3054.60.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<1196259736.3054.60.camel@localhost.localdomain>
Message-ID: <20071128092919.34ef79ff@redhat.com>

On Wed, 28 Nov 2007 09:22:16 -0500
"Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:

> Not just that, we should pull out cdparanoia, as it has been in alpha
> since 2001. :P

Again, it's a general statement not a blanket policy.  The maintainer
has the right to contradict the general statement when it makes
reasonable sense to.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/adb42240/attachment.sig>

From tcallawa at redhat.com  Wed Nov 28 14:34:23 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Nov 2007 09:34:23 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128092834.46014249@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
Message-ID: <1196260463.3054.64.camel@localhost.localdomain>


On Wed, 2007-11-28 at 09:28 -0500, Jesse Keating wrote:
> On Wed, 28 Nov 2007 08:48:24 -0500
> Steve Grubb <sgrubb at redhat.com> wrote:
> 
> > How about unreleased cvs snapshots? kdepim in F7 failed to work after
> > a recent upgrade (and had been working fine) and my problem was only
> > solved by upgrading to F8 which had a more recent cvs snapshot that
> > is still buggy but usable. Rolling back did not work. The only
> > support I got by the Fedora maintainer was telling me to report it
> > upstream. Upstream does not support it because its a cvs snapshot and
> > not a released version.
> > 
> > What do we do about that? This is the current status of kdepim in
> > both F7 & 8.
> 
> This again falls under the Maintainer's discretion.  They can choose to
> backport a specific fix as a patch, or pick up a CVS snapshot and run
> with it, in order to fix the bug(s) in question.

So, basically, the policy is "Let the maintainer use their discretion".
Which Adam did, in the specific bind case.

~spot



From caillon at redhat.com  Wed Nov 28 14:33:47 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 28 Nov 2007 15:33:47 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196254013.3054.58.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
Message-ID: <474D7C4B.7080405@redhat.com>

On 11/28/2007 01:46 PM, Tom "spot" Callaway wrote:
> On Wed, 2007-11-28 at 07:33 +0100, Christopher Aillon wrote:
>> On 11/28/2007 06:56 AM, Jason L Tibbitts III wrote:
>>>>>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
>>> TC> Such as? Open to suggestions here.
>>>
>>> We had
>>> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
>>> which was never finished; the only thing in there is "Maintain
>>> stability for users".  I honestly don't see how you can be much more
>>> specific without introducing needless bureaucracy.  After all, the
>>> alpha releases of some projects are more stable then the full releases
>>> of others.
>> This seems pretty much perfect, actually.  What does it need in order to 
>> be "finished"?
> 
> Well, I'm not sure how it can be considered perfect when it does not
> begin to address the "alpha/beta" issue that you think is resolvable
> with packaging policy.
> 
> FWIW, I agree with Tibbs, since we have no way of determining how stable
> package releases are without trusting the maintainer.

I never said that we should resolve the alpha/beta issue.  I said we 
should have some form of (loose) criteria for maintainers in release 
branches.  "It must maintain stability" is a good criterion item.  Else, 
maintainers could just go breaking stuff and say "well, I thought Fedora 
was supposed to be bleeding edge - nobody told me I couldn't break stuff 
in a release".

It also serves as a great fallback policy in the unlikely case we 
(FESCo? RelEng?) ever find ourselves in the case where we need to decide 
to (nudge the maintainer to) revert a change because it breaks too many 
people.



From atkac at redhat.com  Wed Nov 28 14:36:11 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 15:36:11 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128092834.46014249@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
Message-ID: <20071128143611.GA3578@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 09:28:34AM -0500, Jesse Keating wrote:
> On Wed, 28 Nov 2007 08:48:24 -0500
> Steve Grubb <sgrubb at redhat.com> wrote:
> 
> > How about unreleased cvs snapshots? kdepim in F7 failed to work after
> > a recent upgrade (and had been working fine) and my problem was only
> > solved by upgrading to F8 which had a more recent cvs snapshot that
> > is still buggy but usable. Rolling back did not work. The only
> > support I got by the Fedora maintainer was telling me to report it
> > upstream. Upstream does not support it because its a cvs snapshot and
> > not a released version.
> > 
> > What do we do about that? This is the current status of kdepim in
> > both F7 & 8.
> 
> This again falls under the Maintainer's discretion.  They can choose to
> backport a specific fix as a patch, or pick up a CVS snapshot and run
> with it, in order to fix the bug(s) in question.
> 
> -- 
> Jesse Keating
> Fedora -- All my bits are free, are yours?

Yes, We should educate maintainers instead bind their hands with some
policy or restriction.

Adam

> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From rdieter at math.unl.edu  Wed Nov 28 14:38:45 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 28 Nov 2007 08:38:45 -0600
Subject: alpha/beta software in Fedora 8?
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
Message-ID: <fijuhr$20o$1@ger.gmane.org>

Steve Grubb wrote:

> Upstream does not
> support it because its a cvs snapshot and not a released version.

Did they *really* say that the kdepim-enterprise branch isn't supported?  If
so, I'd like to know who said that, so I can go whack 'em with a
clue-stick.

-- Rex



From jkeating at redhat.com  Wed Nov 28 14:38:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 09:38:12 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196260463.3054.64.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<1196260463.3054.64.camel@localhost.localdomain>
Message-ID: <20071128093812.51022c3c@redhat.com>

On Wed, 28 Nov 2007 09:34:23 -0500
"Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:

> So, basically, the policy is "Let the maintainer use their
> discretion". Which Adam did, in the specific bind case.

That is correct.  I'm not faulting Adam here at all.  However what
Chris and others are asking for is a general guideline to help
maintainers use their best judgment and that's what I attempted to
provide.  We're providing some criteria for which the maintainer to
base their judgment on.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/8c815a01/attachment.sig>

From caillon at redhat.com  Wed Nov 28 14:40:52 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 28 Nov 2007 15:40:52 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127152535.GA7102@traged.englab.brq.redhat.com>	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
Message-ID: <474D7DF4.5020508@redhat.com>

On 11/28/2007 11:24 AM, Adam Tkac wrote:
>>From BIND changelog:
> * Tue Jun 19 2007 Adam Tkac <atkac redhat com> 31:9.5.0a5-1


On a separate unrelated note, please do not append "a" to the RPM 
Version field for alphas.  As far as RPM is concerned "9.5.0a5" > 
"9.5.0" which means you have to keep changing the epoch [31!  wow :-(] 
The correct way is to have a 0.a. or similar in the Release field.

This is documented in the packaging guidelines: 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages



From jkeating at redhat.com  Wed Nov 28 14:38:50 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 09:38:50 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128143611.GA3578@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<20071128143611.GA3578@evileye.atkac.englab.brq.redhat.com>
Message-ID: <20071128093850.50c1e363@redhat.com>

On Wed, 28 Nov 2007 15:36:11 +0100
Adam Tkac <atkac at redhat.com> wrote:

> Yes, We should educate maintainers instead bind their hands with some
> policy or restriction.

Please explain to me how what I posted as "policy" would be binding
anybody's hands?

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/db679b80/attachment.sig>

From caillon at redhat.com  Wed Nov 28 14:45:31 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 28 Nov 2007 15:45:31 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128075534.716563b5@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>	<474D0BCC.5010800@redhat.com>	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
Message-ID: <474D7F0B.6060207@redhat.com>

On 11/28/2007 01:55 PM, Jesse Keating wrote:
> On Wed, 28 Nov 2007 07:46:53 -0500
> "Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:
> 
>> Well, I'm not sure how it can be considered perfect when it does not
>> begin to address the "alpha/beta" issue that you think is resolvable
>> with packaging policy.
> 
> "In general, it is preferred if maintainers avoid releasing "alpha" or
> "beta" builds of packages into Fedora (both Rawhide and released
> updates).  However a package maintainer has the right to use their own
> discretion regarding this issue and may provide whatever (s)he sees fit
> for the user base.  Things to consider include the amount of testing an
> alpha or beta release has seen, the timeline to turn said alpha or beta
> into a stable release, the feature sets provided, or the bugs fixed.
> There may be other factors at play as well, which is why the person
> best suited to make such a decision is the package maintainer in
> question."

This would also work.  Just so a maintainer can figure out what general 
path they should be following in a release.  /me likes.



From atkac at redhat.com  Wed Nov 28 14:48:26 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 15:48:26 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128093850.50c1e363@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<20071128143611.GA3578@evileye.atkac.englab.brq.redhat.com>
	<20071128093850.50c1e363@redhat.com>
Message-ID: <20071128144826.GA8522@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 09:38:50AM -0500, Jesse Keating wrote:
> On Wed, 28 Nov 2007 15:36:11 +0100
> Adam Tkac <atkac at redhat.com> wrote:
> 
> > Yes, We should educate maintainers instead bind their hands with some
> > policy or restriction.
> 
> Please explain to me how what I posted as "policy" would be binding
> anybody's hands?
> 

Your policy doesn't binding anybody. I want point that policy like
"packages a b and c have to be always stable, not alpha/beta/rc" will
be really bad

-- 
Adam Tkac, Red Hat, Inc.



From skvidal at fedoraproject.org  Wed Nov 28 14:42:50 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 28 Nov 2007 09:42:50 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474D7DF4.5020508@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<474D7DF4.5020508@redhat.com>
Message-ID: <1196260970.15420.200.camel@cutter>


On Wed, 2007-11-28 at 15:40 +0100, Christopher Aillon wrote:
> On 11/28/2007 11:24 AM, Adam Tkac wrote:
> >>From BIND changelog:
> > * Tue Jun 19 2007 Adam Tkac <atkac redhat com> 31:9.5.0a5-1
> 
> 
> On a separate unrelated note, please do not append "a" to the RPM 
> Version field for alphas.  As far as RPM is concerned "9.5.0a5" > 
> "9.5.0" which means you have to keep changing the epoch [31!  wow :-(] 
> The correct way is to have a 0.a. or similar in the Release field.

To be fair  - bind's epoch getting to be 31 is the fault of a previous
"maintainer" of the package.

-sv





From atkac at redhat.com  Wed Nov 28 14:50:57 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 15:50:57 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474D7DF4.5020508@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<474D7DF4.5020508@redhat.com>
Message-ID: <20071128145057.GB8522@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 03:40:52PM +0100, Christopher Aillon wrote:
> On 11/28/2007 11:24 AM, Adam Tkac wrote:
>>> From BIND changelog:
>> * Tue Jun 19 2007 Adam Tkac <atkac redhat com> 31:9.5.0a5-1
>
>
> On a separate unrelated note, please do not append "a" to the RPM Version 
> field for alphas.  As far as RPM is concerned "9.5.0a5" > "9.5.0" which 
> means you have to keep changing the epoch [31!  wow :-(] The correct way is 
> to have a 0.a. or similar in the Release field.
>
> This is documented in the packaging guidelines: 
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages
>

That package was released before I read policy :) Now all is quite
correct (9.5.0-18.a7)

-- 
Adam Tkac, Red Hat, Inc.



From rdieter at math.unl.edu  Wed Nov 28 14:52:30 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 28 Nov 2007 08:52:30 -0600
Subject: alpha/beta software in Fedora 8?
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<20071128143611.GA3578@evileye.atkac.englab.brq.redhat.com>
	<20071128093850.50c1e363@redhat.com>
	<20071128144826.GA8522@evileye.atkac.englab.brq.redhat.com>
Message-ID: <fijvbl$5pa$1@ger.gmane.org>

Adam Tkac wrote:

> I want point that policy like
> "packages a b and c have to be always stable, not alpha/beta/rc" will
> be really bad

Good, because no one is suggesting that. :)

-- Rex




From pp at ee.oulu.fi  Wed Nov 28 14:56:25 2007
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Wed, 28 Nov 2007 16:56:25 +0200
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474D7C4B.7080405@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<474D7C4B.7080405@redhat.com>
Message-ID: <20071128145625.GA1753@ee.oulu.fi>

On Wed, Nov 28, 2007 at 03:33:47PM +0100, Christopher Aillon wrote:
> >Well, I'm not sure how it can be considered perfect when it does not
> >begin to address the "alpha/beta" issue that you think is resolvable
> >with packaging policy.
> >
> >FWIW, I agree with Tibbs, since we have no way of determining how stable
> >package releases are without trusting the maintainer.
> 
> I never said that we should resolve the alpha/beta issue.  I said we 
> should have some form of (loose) criteria for maintainers in release 
> branches.  "It must maintain stability" is a good criterion item.  Else, 
> maintainers could just go breaking stuff and say "well, I thought Fedora 
> was supposed to be bleeding edge - nobody told me I couldn't break stuff 
> in a release".
> 
> It also serves as a great fallback policy in the unlikely case we 
> (FESCo? RelEng?) ever find ourselves in the case where we need to decide 
> to (nudge the maintainer to) revert a change because it breaks too many 
> people.
It would appear there is a lack of "Why is this version being shipped"
documentation as well. If it's a Major Feature (like KDE4) it'll get tracked
and discussed, but otherwise if there's a good reason for shipping something
older (e.g. newest version introduces dependency hell) or newer (CVS snapshot
fixes critical issues) than the latest "stable" there's often no way of
figuring out other than asking the maintainer, who usually will have a good
answer.

Maybe have something like this in pkgdb?

-- 
Pekka Pietikainen



From notting at redhat.com  Wed Nov 28 15:27:52 2007
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 28 Nov 2007 10:27:52 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474D4B68.7010909@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>
	<20071128053010.GA10110@nostromo.devel.redhat.com>
	<20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>
	<474D4B68.7010909@redhat.com>
Message-ID: <20071128152752.GA7297@nostromo.devel.redhat.com>

Martin Stransky (stransky at redhat.com) said: 
> Adam Tkac wrote:
>> As I wrote above I disagree with you that put alpha (which will come
>> to beta really soon) to F8 is bad decision "because it is alpha". I
>> tested it and I didn't find any issues. That's why I decided put 9.5
>> to F8.
>> Adam
>
> Is a former bind maintainer I have to support Adam here. In my opinion it 
> depends what package is taken and it's really a big difference between a 
> huge project (like gnome/gcc) and relative small one like bind.
>
> Bind alpha/beta versions are periodically more stable than other **stable** 
> projects.

It's not about comparing to other projects. Different kernel releases are
all stable, and have wildly divergent bug sets.

The issue is providing a reasonably stable usable platform - realistically,
if ISC wanted people running a version of bind in production, wouldn't they
*tag it as stable and release it*?  By shipping it in a release, we're
essentially saying we know better than upstream what's appropriate for users.
Do we?

Bill



From nphilipp at redhat.com  Wed Nov 28 15:28:59 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Wed, 28 Nov 2007 16:28:59 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071128064718.31c0c40c@redhat.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
	<1196246627.27991.17.camel@wombat.tiptoe.de>
	<20071128064718.31c0c40c@redhat.com>
Message-ID: <1196263739.19874.6.camel@gibraltar.str.redhat.com>


On Wed, 2007-11-28 at 06:47 -0500, Jesse Keating wrote:
> On Wed, 28 Nov 2007 11:43:47 +0100
> Nils Philippsen <nphilipp at redhat.com> wrote:
> 
> > > In fact, koji enforces this.  Koji stores builds based on n-v-r, not
> > > n-e-v-r, so if you only just bump epoch, koji will give you an
> > > error.  
> > 
> > Psst. That isn't something I would tout as a feature ;-).
> 
> It is.  This was a very intentional design item.  We wanted to make
> sure that when a maintainer bumped epoch, they /had/ to bump something
> else of nvr with it.

Well, that probably works for situations where the epoch was a result of
sloppy packaging. If an epoch is needed because upstream "rebases"
versions (or upstream is "rebased" -- due to a forked project or
whatever), it's going to be much fun for the maintainer if/when the
versions clash with the old numberspace.

What is the reasoning for needing to bump something else beside the
epoch? As far as I'm concerned, epoch is the most significant part of
the "combined version" of a package -- isn't that the case?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From bpepple at fedoraproject.org  Wed Nov 28 15:30:49 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 28 Nov 2007 10:30:49 -0500
Subject: Maintainers Responsibility (was alpha/beta software in Fedora 8)
In-Reply-To: <474D0BCC.5010800@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
Message-ID: <1196263849.10086.2.camel@nixon>

On Wed, 2007-11-28 at 07:33 +0100, Christopher Aillon wrote:
> On 11/28/2007 06:56 AM, Jason L Tibbitts III wrote:
> > 
> > We had
> > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
> > which was never finished; the only thing in there is "Maintain
> > stability for users".  I honestly don't see how you can be much more
> > specific without introducing needless bureaucracy.  After all, the
> > alpha releases of some projects are more stable then the full releases
> > of others.
> 
> This seems pretty much perfect, actually.  What does it need in order to 
> be "finished"?

Really it's just looking for some feedback from the mailing lists.  I
started an e-mail on it before the holiday, just haven't had time to
send it yet.

/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/80a82dc7/attachment.sig>

From jkeating at redhat.com  Wed Nov 28 15:33:41 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 10:33:41 -0500
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196263739.19874.6.camel@gibraltar.str.redhat.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
	<1196246627.27991.17.camel@wombat.tiptoe.de>
	<20071128064718.31c0c40c@redhat.com>
	<1196263739.19874.6.camel@gibraltar.str.redhat.com>
Message-ID: <20071128103341.76852e55@redhat.com>

On Wed, 28 Nov 2007 16:28:59 +0100
Nils Philippsen <nphilipp at redhat.com> wrote:

> Well, that probably works for situations where the epoch was a result
> of sloppy packaging. If an epoch is needed because upstream "rebases"
> versions (or upstream is "rebased" -- due to a forked project or
> whatever), it's going to be much fun for the maintainer if/when the
> versions clash with the old numberspace.
> 
> What is the reasoning for needing to bump something else beside the
> epoch? As far as I'm concerned, epoch is the most significant part of
> the "combined version" of a package -- isn't that the case?

The most basic example, if you just bump epoch and nothing else, the
resultant file name is no different than the previous file name.  You
can't store the two builds in the same directory, and it's quite
confusing.

There are more, but flip it on it's head.  Why would you ever /only/
bump the epoch and not also bump at least the release number?  Release
is something we as a vendor control, which is our added numbering on
top of upstream's numbering.  You wouldn't have to change version, just
release.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/8adae032/attachment.sig>

From myfedora at richip.dhs.org  Wed Nov 28 15:51:29 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Wed, 28 Nov 2007 08:51:29 -0700
Subject: Maintainers Responsibility (was alpha/beta software in Fedora	8)
In-Reply-To: <1196263849.10086.2.camel@nixon>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196263849.10086.2.camel@nixon>
Message-ID: <1196265089.29968.2.camel@localhost6.localdomain6>

On Wed, 2007-11-28 at 10:30 -0500, Brian Pepple wrote:
> On Wed, 2007-11-28 at 07:33 +0100, Christopher Aillon wrote:
> > On 11/28/2007 06:56 AM, Jason L Tibbitts III wrote:
> > > 
> > > We had
> > > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
> > > which was never finished; the only thing in there is "Maintain
> > > stability for users".  I honestly don't see how you can be much more
> > > specific without introducing needless bureaucracy.  After all, the
> > > alpha releases of some projects are more stable then the full releases
> > > of others.
> > 
> > This seems pretty much perfect, actually.  What does it need in order to 
> > be "finished"?
> 
> Really it's just looking for some feedback from the mailing lists.  I
> started an e-mail on it before the holiday, just haven't had time to
> send it yet.

How about adding scope of potential damage? The greater the damage to
the end-user, the more careful the maintainer should be at choosing.
Seriously, if it were some alpha desktop app that might, at its
likeliest, cause the loss of sound, then fine. But if it's a DNS server
that could poison the network or, at best, result in people within the
network to lose connectivity (specially since the developers themselves
have stated that it is not for production purposes and I'd like to think
of Fedora RELEASES as production), then they should be pickier.
--

Richi Plana



From atkac at redhat.com  Wed Nov 28 16:07:43 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 17:07:43 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128152752.GA7297@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>
	<20071128053010.GA10110@nostromo.devel.redhat.com>
	<20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>
	<474D4B68.7010909@redhat.com>
	<20071128152752.GA7297@nostromo.devel.redhat.com>
Message-ID: <20071128160743.GA10022@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 10:27:52AM -0500, Bill Nottingham wrote:
> Martin Stransky (stransky at redhat.com) said: 
> > Adam Tkac wrote:
> >> As I wrote above I disagree with you that put alpha (which will come
> >> to beta really soon) to F8 is bad decision "because it is alpha". I
> >> tested it and I didn't find any issues. That's why I decided put 9.5
> >> to F8.
> >> Adam
> >
> > Is a former bind maintainer I have to support Adam here. In my opinion it 
> > depends what package is taken and it's really a big difference between a 
> > huge project (like gnome/gcc) and relative small one like bind.
> >
> > Bind alpha/beta versions are periodically more stable than other **stable** 
> > projects.
> 
> It's not about comparing to other projects. Different kernel releases are
> all stable, and have wildly divergent bug sets.
> 
> The issue is providing a reasonably stable usable platform - realistically,
> if ISC wanted people running a version of bind in production, wouldn't they
> *tag it as stable and release it*?  By shipping it in a release, we're
> essentially saying we know better than upstream what's appropriate for users.
> Do we?
> 
> Bill

Stable release means stability is guaranted by ISC. And if stability
isn't guaranted it doesn't mean unstability. It means that you could
have problems. And I don't have problems for five months so this is
good reason that F8 bind is relative stable.

Adam

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Adam Tkac, Red Hat, Inc.



From ajackson at redhat.com  Wed Nov 28 16:44:20 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 28 Nov 2007 11:44:20 -0500
Subject: Driver transition: via -> openchrome
Message-ID: <1196268260.22277.48.camel@localhost.localdomain>

Just a heads-up:

The via driver in Xorg is pretty much dead.  Therefore, rawhide will be
switching to openchrome.  xorg-x11-drivers now Requires openchrome on
x86 and amd64 machines, and the openchrome package (once it builds
again) will both provide and obsolete the via package, and munge your
config file (if present) to change the driver name appropriately.  Also,
X will load the new driver if started without a config file.

Shouldn't break anything, but if it does, as always, bugzilla is
standing by and ready to take your call.

- ajax



From j.w.r.degoede at hhs.nl  Wed Nov 28 16:16:35 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 28 Nov 2007 17:16:35 +0100
Subject: AWOL: jpo
In-Reply-To: <1196199993.3054.2.camel@localhost.localdomain>
References: <1195574488.27963.27.camel@localhost.localdomain>
	<1196199993.3054.2.camel@localhost.localdomain>
Message-ID: <474D9463.7050107@hhs.nl>

Tom "spot" Callaway wrote:
> On Tue, 2007-11-20 at 11:01 -0500, Tom "spot" Callaway wrote:
> 
>> If he does not respond to this email in a week, I'll take over all of
>> his packages (temporarily) and post to fedora-devel that they're all up
>> for grabs.
> 
> In accordance with the AWOL policy, I've now declared jpo AWOL. Many of
> his packages have already been claimed by the perl-SIG, but there are
> some packages available (I currently own them, but will happily pass
> them on to a more motivated maintainer):
> 
>   * asymptote -- Descriptive vector graphics language
>       * eventlog -- Syslog-ng v2 support library
>       * libcgi -- CGI easy as C
>       * libsmi -- A library to access SMI MIB information
>       * nagios-plugins-snmp-disk-proc -- Nagios SNMP plugins to monitor
>         remote disk and processes
>       * srecord -- Manipulate EPROM load files
>       * swatch -- Tool for actively monitoring log files
>       * syslog-ng -- Syslog replacement daemon
>       * tetex-bytefield -- Create illustrations for network protocol
>         specifications
>       * tetex-perltex -- Define LaTeX macros in terms of Perl code
> 
> Thanks to all those who volunteered to maintain/comaintain his other
> packages.
> 

I don't mind taking the srecord package.

Regards,

Hans




From bpepple at fedoraproject.org  Wed Nov 28 16:16:53 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 28 Nov 2007 11:16:53 -0500
Subject: Plan for tomorrows (20071129) FESCO meeting
Message-ID: <1196266613.10086.18.camel@nixon>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic FESCo meeting -- Any objection to this week's report from FPC at
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01850.html

/topic MISC - Fonts Comps Policy -
http://fedoraproject.org/wiki/PackagingDrafts/FontsComps - Nicolas
Mailhot 

/topic MISC - Drop orphans from F8< at some point during F9 - f13 

/topic MISC - Using Matt Domsch's "doesn't rebuild" bugs as AWOL
detection, mark as orphaned at some point in F9, drop in F9+ 

/topic MISC - Do more frequent conflicts testing, with bugs filed, and
use AWOL detection 

/topic MISC - automate the mailings of multiarch conflicts, it is hard
to test for people without biarch computers - from Patrice Dumas 

/topic FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all 

/topic FESCO-Meeting -- Features -
http://fedoraproject.org/wiki/Releases/9/FeatureList -- all 

/topic Status Update: Compat Policy
http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy

/topic Status Update: FESCo Proposal Template - f13

/topic FESCo meeting -- Free discussion around Fedora

You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, since we have a pretty full schedule).  You can also
propose topics in the meeting while it is in the "Free discussion around
Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/aa8d5ebd/attachment.sig>

From mclasen at redhat.com  Wed Nov 28 16:31:11 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 28 Nov 2007 11:31:11 -0500
Subject: Maintainers Responsibility (was alpha/beta software in Fedora	8)
In-Reply-To: <1196265089.29968.2.camel@localhost6.localdomain6>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196263849.10086.2.camel@nixon>
	<1196265089.29968.2.camel@localhost6.localdomain6>
Message-ID: <1196267471.2889.6.camel@localhost.localdomain>


On Wed, 2007-11-28 at 08:51 -0700, Richi Plana wrote:
> On Wed, 2007-11-28 at 10:30 -0500, Brian Pepple wrote:
> > On Wed, 2007-11-28 at 07:33 +0100, Christopher Aillon wrote:
> > > On 11/28/2007 06:56 AM, Jason L Tibbitts III wrote:
> > > > 
> > > > We had
> > > > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
> > > > which was never finished; the only thing in there is "Maintain
> > > > stability for users".  I honestly don't see how you can be much more
> > > > specific without introducing needless bureaucracy.  After all, the
> > > > alpha releases of some projects are more stable then the full releases
> > > > of others.
> > > 
> > > This seems pretty much perfect, actually.  What does it need in order to 
> > > be "finished"?
> > 
> > Really it's just looking for some feedback from the mailing lists.  I
> > started an e-mail on it before the holiday, just haven't had time to
> > send it yet.
> 
> How about adding scope of potential damage? The greater the damage to
> the end-user, the more careful the maintainer should be at choosing.
> Seriously, if it were some alpha desktop app that might, at its
> likeliest, cause the loss of sound, then fine. But if it's a DNS server
> that could poison the network or, at best, result in people within the
> network to lose connectivity (specially since the developers themselves
> have stated that it is not for production purposes and I'd like to think
> of Fedora RELEASES as production), then they should be pickier.

The importance of individual packages is pretty dependent on the use
case. For most users of a Fedora desktop, it is probably far more
disastrous if the email client or web browser crashes, than if some dns
server the haven't installed has some bugs.



From sgrubb at redhat.com  Wed Nov 28 16:33:19 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 28 Nov 2007 11:33:19 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <fijuhr$20o$1@ger.gmane.org>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com> <fijuhr$20o$1@ger.gmane.org>
Message-ID: <200711281133.19824.sgrubb@redhat.com>

On Wednesday 28 November 2007 09:38:45 Rex Dieter wrote:
> Steve Grubb wrote:
> > Upstream does not support it because its a cvs snapshot and not a released
> > version. 
>
> Did they *really* say that the kdepim-enterprise branch isn't supported? 

No one answered my bug report on the upstream mail list. I'll ask a more 
direct question to them if you tell me where this tarball comes from:

kdepim-enterprise-svn20070926.tar.bz2

In the specfile, I see  Source0: 
ftp://ftp.kde.org/pub/kde/stable/%{version}/src/%{name}-%{version}.tar.bz2

which that file is not there. Then there is this:

Source0: kdepim-enterprise-svn%{ent_date}.tar.bz2

URL: http://www.kde.org  is not helpful in tracking down where this file came 
from.

-Steve



From jkeating at redhat.com  Wed Nov 28 16:41:15 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 11:41:15 -0500
Subject: Estimating the size of an iso based on a directory tree in python
Message-ID: <20071128114115.60b970d2@redhat.com>

Does anybody know of examples on how to do this?  This is for pungi, so
that you can just provide the desired iso size and it will make as many
necessary to hold your tree.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/0aad554e/attachment.sig>

From sgrubb at redhat.com  Wed Nov 28 16:44:52 2007
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 28 Nov 2007 11:44:52 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128092834.46014249@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
Message-ID: <200711281144.53210.sgrubb@redhat.com>

On Wednesday 28 November 2007 09:28:34 Jesse Keating wrote:
> > What do we do about that? This is the current status of kdepim in
> > both F7 & 8.
>
> This again falls under the Maintainer's discretion. ?They can choose to
> backport a specific fix as a patch,

Which is what I would have done had it been my package.

> or pick up a CVS snapshot and run with it, in order to fix the bug(s) in
> question.

This should not be allowed in a stable distribution for a critical package 
like a working email client. I lost all email capability and had to move to 
new machine and not have access to any emails I previously sent or had stored 
as drafts and lost my contacts list. This impacted my work at Red Hat.

-Steve



From atkac at redhat.com  Wed Nov 28 16:45:17 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 17:45:17 +0100
Subject: Maintainers Responsibility (was alpha/beta software in Fedora 8)
In-Reply-To: <1196267471.2889.6.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com> <1196263849.10086.2.camel@nixon>
	<1196265089.29968.2.camel@localhost6.localdomain6>
	<1196267471.2889.6.camel@localhost.localdomain>
Message-ID: <20071128164517.GA10472@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 11:31:11AM -0500, Matthias Clasen wrote:
> 
> 
> The importance of individual packages is pretty dependent on the use
> case. For most users of a Fedora desktop, it is probably far more
> disastrous if the email client or web browser crashes, than if some dns
> server the haven't installed has some bugs.
> 

Without DNS server noone who uses it could browse pages or fetch mails
(or you know IP of your mailserver?) :) I agree that We have to update
server packages more carefully than desktop applications.

Adam

-- 
Adam Tkac, Red Hat, Inc.



From tonynelson at georgeanelson.com  Wed Nov 28 16:46:08 2007
From: tonynelson at georgeanelson.com (Tony Nelson)
Date: Wed, 28 Nov 2007 11:46:08 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128075534.716563b5@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>	<474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
Message-ID: <p04330102c37343c36e1e@[192.168.123.162]>

At 7:55 AM -0500 11/28/07, Jesse Keating wrote:
 ...
>"In general, it is preferred if maintainers avoid releasing "alpha" or
>"beta" builds of packages into Fedora (both Rawhide and released
>updates)

"if stable releases are available on a usable schedule"

>.  However a package maintainer has the right to use their own
>discretion regarding this issue and may provide whatever (s)he sees fit
>for the user base.  Things to consider include the amount of testing an
>alpha or beta release has seen, the timeline to turn said alpha or beta
>into a stable release,

"how dependent the rest of the system is on the package,"

> the feature sets provided, or the bugs fixed.
>There may be other factors at play as well, which is why the person
>best suited to make such a decision is the package maintainer in
>question."

Breaking, say, f-spot would irritate some people (but not me).  Breaking
emacs would irritate more (still not me).  Breaking X is very irritating,
and is currently being handled with great care.  Breaking, say, name
resolution is also very irritating -- even for people who aren't using X.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>



From rdieter at math.unl.edu  Wed Nov 28 16:47:20 2007
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 28 Nov 2007 10:47:20 -0600
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711281133.19824.sgrubb@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com> <fijuhr$20o$1@ger.gmane.org>
	<200711281133.19824.sgrubb@redhat.com>
Message-ID: <474D9B98.6010100@math.unl.edu>

Steve Grubb wrote:
> On Wednesday 28 November 2007 09:38:45 Rex Dieter wrote:
>> Steve Grubb wrote:
>>> Upstream does not support it because its a cvs snapshot and not a released
>>> version. 
>> Did they *really* say that the kdepim-enterprise branch isn't supported? 
> 
> No one answered my bug report on the upstream mail list. I'll ask a more 
> direct question to them if you tell me where this tarball comes from:
> 
> kdepim-enterprise-svn20070926.tar.bz2

Included in cvs is a script to pull a current snapshot from kde's svn repo:
http://cvs.fedoraproject.org/viewcvs/devel/kdepim/kdepim-enterprise-svn_checkout.sh

My bad for not including this as a Source in the spec-file (I'll rectify 
that soon).

-- Rex



From ddmbox2 at yahoo.co.uk  Wed Nov 28 15:58:39 2007
From: ddmbox2 at yahoo.co.uk (dexter)
Date: Wed, 28 Nov 2007 15:58:39 +0000
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474C5591.40003@gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127160436.GA8321@traged.englab.brq.redhat.com>
	<474C5591.40003@gmail.com>
Message-ID: <200711281558.40421.ddmbox2@yahoo.co.uk>

On Tue November 27 2007 17:36:17 Toshio Kuratomi wrote:
> I just want to stress that we're working hard to keep people from
> thinking of Fedora as "a beta release of RHEL".

Education starts at home, here's a paragraph from mspevac 7 nov from the 
announce list.
"""
Fedora's development priorities tend to come in cycles.  If you think 
back to the Fedora Core 6 release cycle, you will remember that a 
significant portion of the engineering goals for that release were 
driven by the knowledge that Fedora Core 6 would be the upstream for Red 
Hat Enterprise Linux 5.  Everyone knew going in that Fedora Core 6 would 
be more "corporate" than "community". And that was ok, because we also 
knew that once Red Hat Enterprise Linux 5 was released, the Fedora 
Project would be able to spend its next several releases focused on its 
community-related priorities.  Fedora 9 will probably start to see the 
pendulum swing back in the other direction, as Red Hat Enterprise Linux 
6 starts to materialize on the horizon.
"""
Hmm sounds like beta to me.


...dex




From andy at smile.org.ua  Wed Nov 28 17:02:15 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Wed, 28 Nov 2007 19:02:15 +0200
Subject: Estimating the size of an iso based on a directory tree in
	python
In-Reply-To: <20071128114115.60b970d2@redhat.com>
References: <20071128114115.60b970d2@redhat.com>
Message-ID: <20071128170214.GC28759@serv.smile.org.ua>

Hi Jesse Keating!

 On Wed, Nov 28, 2007 at 11:41:15AM -0500, Jesse Keating wrote next:

> Does anybody know of examples on how to do this?  This is for pungi, so
> that you can just provide the desired iso size and it will make as many
> necessary to hold your tree.

Just add -print-size to the genisoimage call before real making image.

guess_size_in_blks = ... os.popen("genisoimage ...")

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From thomas.swan at gmail.com  Wed Nov 28 17:09:57 2007
From: thomas.swan at gmail.com (Thomas Swan)
Date: Wed, 28 Nov 2007 11:09:57 -0600
Subject: Fedora 8 installation crash
Message-ID: <abb19e6c0711280909j5ed14a58v9d8d0aa474b50ab@mail.gmail.com>

I don't think this is just you.  When trying to install F8 on an HP laptop
(in text mode)

loader received SIGSEGV! Backtrace:
[0x804a030]
[0x110420]
[0x81a3f42]
[0x805b750]
[0x805c153]
[0x804b207]
[0x8175004]
0x8048151]

Installing  in graphical mode yields the following error messages:
*** glibc detected *** /sbin/loader: munmap_chunk(): invalid pointer:
0x0850c810
=== Backgrace: ===
[0x81a4083]
[0x805b750]
[0x805c153]
[0x804b207]
[0x8175004]
[0x8048151]
======= Memory map =======
00110000-00111000 r-xp 001110000 00:00 0 [vdso]
08048000-0828e000 r-xp 00000000 00:01 36 /sbin/loader
0828e000-08299000 rw-p 00245000 00:01 36 /sbin/loader
08299000-082d3000 rw-p 08299000 00:00 0
0849b000-08589000 rw-p 0849b000 00:00 0
b7f36000-b7f39000 rw-p b7f36000 00:00 0
bfedb000-bfef0000 rw-p bffea000 00:00 0
loader received a SIGABRT!  Backtrace:
[0x804a030]
[0x110420]
[0x81e7f80]
[0x8182a30]
[0x819930b]
[0x81a4003]
[0x805b750]
[0x805c153]
[0x804b207]
[0x8175004]
[0x8048151]
install exited abnormally [1/1]

This exact same problem happens when installing from known good media on
both USB DVD drives and the local dvd drive.
I am using the Fedora-8-i386-DVD.iso.  Memtest has been run on this system
and there are no memory errors.

This doesn't seem to be isolated.  <
http://www.nabble.com/F8-Installation-Issue---Second-Try-tf4806216.html#a13750126
>


-- 
The early bird may get the worm, but the it's the second mouse that gets the
cheese.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/64e62d43/attachment.htm>

From sundaram at fedoraproject.org  Wed Nov 28 17:09:29 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Nov 2007 22:39:29 +0530
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711281558.40421.ddmbox2@yahoo.co.uk>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127160436.GA8321@traged.englab.brq.redhat.com>	<474C5591.40003@gmail.com>
	<200711281558.40421.ddmbox2@yahoo.co.uk>
Message-ID: <474DA0C9.2010809@fedoraproject.org>

dexter wrote:
> On Tue November 27 2007 17:36:17 Toshio Kuratomi wrote:
>> I just want to stress that we're working hard to keep people from
>> thinking of Fedora as "a beta release of RHEL".
> 
> Education starts at home, here's a paragraph from mspevac 7 nov from the 
> announce list.
> """
> Fedora's development priorities tend to come in cycles.  If you think 
> back to the Fedora Core 6 release cycle, you will remember that a 
> significant portion of the engineering goals for that release were 
> driven by the knowledge that Fedora Core 6 would be the upstream for Red 
> Hat Enterprise Linux 5.  Everyone knew going in that Fedora Core 6 would 
> be more "corporate" than "community". And that was ok, because we also 
> knew that once Red Hat Enterprise Linux 5 was released, the Fedora 
> Project would be able to spend its next several releases focused on its 
> community-related priorities.  Fedora 9 will probably start to see the 
> pendulum swing back in the other direction, as Red Hat Enterprise Linux 
> 6 starts to materialize on the horizon.
> """
> Hmm sounds like beta to me.

Ear damage probably.

Rahul



From a.badger at gmail.com  Wed Nov 28 17:31:03 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 28 Nov 2007 09:31:03 -0800
Subject: rawhide report: 20071127 changes
In-Reply-To: <1196242726.7360.0.camel@asmodeus.localdomain>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196242726.7360.0.camel@asmodeus.localdomain>
Message-ID: <474DA5D7.6010700@gmail.com>

Patrick Ohearn wrote:
> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
>> New package R-rlecuyer
>> 	R interface to RNG with multiple streams
>>
> Is there a web interface for checking different versions in different
> repos, say like packages.gentoo.org and packages.debian.org?
> 
You're looking for repoview:
 
http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/i386/os/repoview/

note that skvidal recently got repoview working again so there might be 
some rough edges.  Letting us know what those are on IRC (#fedora-admin) 
or in a ticket 
https://hosted.fedoraproject.org/projects/fedora-infrastructure/

will help iron those out.

-Toshio



From kevin at scrye.com  Wed Nov 28 17:34:43 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 28 Nov 2007 10:34:43 -0700
Subject: rawhide report: 20071127 changes
In-Reply-To: <1196240269.1109.10.camel@peecee.hoentjen.eu>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196240269.1109.10.camel@peecee.hoentjen.eu>
Message-ID: <20071128103443.1a31d22e@ghistelwchlohm.scrye.com>

On Wed, 28 Nov 2007 09:57:49 +0100
sander at hoentjen.eu (Sander Hoentjen) wrote:

> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> > New package zaf
> >         South Africa hyphenation rules
> 
> Is it intentional that this one is not called hyphen-zaf?

yeah, I wondered about that as well, but the upstream package is
clearly called 'zaf' for whatever reason. Possibly due to it handling
several languages, but not a single locale... 

> 
> Sander
> 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/2dcc2fd3/attachment.sig>

From jkeating at redhat.com  Wed Nov 28 17:34:54 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 12:34:54 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711281144.53210.sgrubb@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<200711281144.53210.sgrubb@redhat.com>
Message-ID: <20071128123454.41045106@redhat.com>

On Wed, 28 Nov 2007 11:44:52 -0500
Steve Grubb <sgrubb at redhat.com> wrote:

> This should not be allowed in a stable distribution for a critical
> package like a working email client. I lost all email capability and
> had to move to new machine and not have access to any emails I
> previously sent or had stored as drafts and lost my contacts list.
> This impacted my work at Red Hat.

The same thing can happen with "stable" releases too.  It's up to the
maintainer and other folks to test updates when they're in
updates-testing to catch this kind of thing, regardless if it's
"alpha", "snapshot", "backport", or just "stable".  Often times the scm
snapshot is nothing more than the patch added, so the effect of
backporting would be the same as taking a snapshot.  It's not our place
to bind maintainers to one method or another, they have to be allowed
to make reasonable decisions.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/ac7e7da8/attachment.sig>

From jkeating at redhat.com  Wed Nov 28 17:36:49 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 12:36:49 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711281558.40421.ddmbox2@yahoo.co.uk>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127160436.GA8321@traged.englab.brq.redhat.com>
	<474C5591.40003@gmail.com> <200711281558.40421.ddmbox2@yahoo.co.uk>
Message-ID: <20071128123649.45651fd9@redhat.com>

On Wed, 28 Nov 2007 15:58:39 +0000
dexter <ddmbox2 at yahoo.co.uk> wrote:

> Hmm sounds like beta to me.

That's your interpretation.  Just because the features are Enterprise
focused doesn't mean they're automatically beta.  It just means that
the focus is more on Enterprise needs, which are often customer driven.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/c551b61e/attachment.sig>

From jkeating at redhat.com  Wed Nov 28 17:37:31 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 12:37:31 -0500
Subject: Estimating the size of an iso based on a directory tree in
 python
In-Reply-To: <20071128170214.GC28759@serv.smile.org.ua>
References: <20071128114115.60b970d2@redhat.com>
	<20071128170214.GC28759@serv.smile.org.ua>
Message-ID: <20071128123731.19b1f0b0@redhat.com>

On Wed, 28 Nov 2007 19:02:15 +0200
Andy Shevchenko <andy at smile.org.ua> wrote:

> Just add -print-size to the genisoimage call before real making image.
> 
> guess_size_in_blks = ... os.popen("genisoimage ...")

While I don't wish to resort to system calls, I guess this would work.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/bb28c40c/attachment.sig>

From jkeating at redhat.com  Wed Nov 28 17:39:24 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 12:39:24 -0500
Subject: Outage of all Phoenix based systems
Message-ID: <20071128123924.1f9e1d84@redhat.com>

Many of our systems just experienced a service blip due to a router
restart.  We are currently working to bring services back online.
These services include but are not limited to; koji, bodhi, dist-cvs,
hosted.fedoraproject.org, mirrormanager, wiki, transifex, and more.

I will send another notice when services are back in order.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/3175650e/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From walters at redhat.com  Wed Nov 28 17:30:21 2007
From: walters at redhat.com (Colin Walters)
Date: Wed, 28 Nov 2007 12:30:21 -0500
Subject: Estimating the size of an iso based on a directory tree in
	python
In-Reply-To: <20071128170214.GC28759@serv.smile.org.ua>
References: <20071128114115.60b970d2@redhat.com>
	<20071128170214.GC28759@serv.smile.org.ua>
Message-ID: <1196271021.7710.2.camel@space-ghost.verbum.private>


On Wed, 2007-11-28 at 19:02 +0200, Andy Shevchenko wrote:

> guess_size_in_blks = ... os.popen("genisoimage ...")

[Random python bits]

Use subprocess instead to avoid going through /bin/sh which is almost
never desirable:

http://docs.python.org/lib/node539.html




From jima at beer.tclug.org  Wed Nov 28 17:49:37 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 28 Nov 2007 11:49:37 -0600 (CST)
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128145057.GB8522@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<474D7DF4.5020508@redhat.com>
	<20071128145057.GB8522@evileye.atkac.englab.brq.redhat.com>
Message-ID: <Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>

On Wed, 28 Nov 2007, Adam Tkac wrote:
> On Wed, Nov 28, 2007 at 03:40:52PM +0100, Christopher Aillon wrote:
>> On a separate unrelated note, please do not append "a" to the RPM Version
>> field for alphas.  As far as RPM is concerned "9.5.0a5" > "9.5.0" which
>> means you have to keep changing the epoch [31!  wow :-(] The correct way is
>> to have a 0.a. or similar in the Release field.
>>
>> This is documented in the packaging guidelines:
>> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages
>
> That package was released before I read policy :) Now all is quite
> correct (9.5.0-18.a7)

  I was going to go off on you for using 8.5.0a5 in the %version, but then 
I checked what was actually on my nameserver and saw you didn't flub that 
up. :-)
  However, a minor point to note in the future is that it really ought to 
be 9.5.0-0.18.a7, as per:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a

  ...but I'll let you get by with a light slap on the wrist. ;-)

      Jima



From jima at beer.tclug.org  Wed Nov 28 17:52:02 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 28 Nov 2007 11:52:02 -0600 (CST)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <20071128103341.76852e55@redhat.com>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
	<1196246627.27991.17.camel@wombat.tiptoe.de>
	<20071128064718.31c0c40c@redhat.com>
	<1196263739.19874.6.camel@gibraltar.str.redhat.com>
	<20071128103341.76852e55@redhat.com>
Message-ID: <Pine.LNX.4.64.0711281151170.17671@beer.tclug.org>

On Wed, 28 Nov 2007, Jesse Keating wrote:
> Nils Philippsen <nphilipp at redhat.com> wrote:
>> What is the reasoning for needing to bump something else beside the
>> epoch? As far as I'm concerned, epoch is the most significant part of
>> the "combined version" of a package -- isn't that the case?
>
> The most basic example, if you just bump epoch and nothing else, the
> resultant file name is no different than the previous file name.  You
> can't store the two builds in the same directory, and it's quite
> confusing.

  More importantly, wouldn't the CVS tag be the same, too?  That's a big 
show-stopper.

      Jima



From devrim at CommandPrompt.com  Wed Nov 28 17:54:47 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Wed, 28 Nov 2007 09:54:47 -0800
Subject: rpms/postfix/devel postfix.spec,1.60,1.61
In-Reply-To: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
References: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
Message-ID: <1196272487.31546.11.camel@localhost.localdomain>

Hi,

On Wed, 2007-11-28 at 12:22 -0500, Thomas Woerner wrote:
> Modified Files:
>         postfix.spec 
> Log Message:
> - made the MYSQL and PGSQL defines overloadable as build argument

Why do we enable MySQL support, but disable PostgreSQL support? I think
we should either set MySQL to 0, or make both 1, or move database
supports under seperate RPMs, like postfix-pgsql and postfix-mysql.

 ( /me hides his signature. ;) )

Regards,
-- 
Devrim G?ND?Z , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/b080ebf3/attachment.sig>

From jspaleta at gmail.com  Wed Nov 28 18:01:53 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 28 Nov 2007 09:01:53 -0900
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<474D7DF4.5020508@redhat.com>
	<20071128145057.GB8522@evileye.atkac.englab.brq.redhat.com>
	<Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
Message-ID: <604aa7910711281001r4a483e11t86d95de78f5c2667@mail.gmail.com>

On Nov 28, 2007 8:49 AM, Jima <jima at beer.tclug.org> wrote:
>   ...but I'll let you get by with a light slap on the wrist. ;-)

a light slap... with a chainsaw.

-jef"its ice carving season"spaleta



From lesmikesell at gmail.com  Wed Nov 28 18:06:23 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Wed, 28 Nov 2007 12:06:23 -0600
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128123649.45651fd9@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127160436.GA8321@traged.englab.brq.redhat.com>	<474C5591.40003@gmail.com>
	<200711281558.40421.ddmbox2@yahoo.co.uk>
	<20071128123649.45651fd9@redhat.com>
Message-ID: <474DAE1F.9000403@gmail.com>

Jesse Keating wrote:
> 
>> Hmm sounds like beta to me.
> 
> That's your interpretation.  Just because the features are Enterprise
> focused doesn't mean they're automatically beta. 

My interpretation has aways been that this is the point where it becomes 
  'less beta'.

> It just means that
> the focus is more on Enterprise needs, which are often customer driven.

Like wanting things that have already been well tested and are known to 
work reliably...  But without the 'more beta' phases, where would they 
come from?   The problem with actually running fedora is you are forced 
to install the 'more beta' versions like it or not, as support ends for 
the last 'less beta' cycle  - or go completely without updates which is 
probably not a good idea.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From kevin at scrye.com  Wed Nov 28 18:04:08 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 28 Nov 2007 11:04:08 -0700
Subject: rpms/postfix/devel postfix.spec,1.60,1.61
In-Reply-To: <1196272487.31546.11.camel@localhost.localdomain>
References: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
	<1196272487.31546.11.camel@localhost.localdomain>
Message-ID: <20071128110408.075bcb2a@ghistelwchlohm.scrye.com>

On Wed, 28 Nov 2007 09:54:47 -0800
devrim at CommandPrompt.com (Devrim G?ND?Z) wrote:

> Hi,
> 
> On Wed, 2007-11-28 at 12:22 -0500, Thomas Woerner wrote:
> > Modified Files:
> >         postfix.spec 
> > Log Message:
> > - made the MYSQL and PGSQL defines overloadable as build argument
> 
> Why do we enable MySQL support, but disable PostgreSQL support? I
> think we should either set MySQL to 0, or make both 1, or move
> database supports under seperate RPMs, like postfix-pgsql and
> postfix-mysql.

I would really like postgresql support too... but it's not an easy
problem. Upstream doesn't support loading them on the fly, so if it's
enabled it means installing postfix pulls in mysql and posgresql. :(

>  ( /me hides his signature. ;) )
> 
> Regards,

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/fc628ca3/attachment.sig>

From atkac at redhat.com  Wed Nov 28 18:06:41 2007
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 28 Nov 2007 19:06:41 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<474D7DF4.5020508@redhat.com>
	<20071128145057.GB8522@evileye.atkac.englab.brq.redhat.com>
	<Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
Message-ID: <20071128180641.GA14275@evileye.atkac.englab.brq.redhat.com>

On Wed, Nov 28, 2007 at 11:49:37AM -0600, Jima wrote:
> On Wed, 28 Nov 2007, Adam Tkac wrote:
>> On Wed, Nov 28, 2007 at 03:40:52PM +0100, Christopher Aillon wrote:
>>> On a separate unrelated note, please do not append "a" to the RPM Version
>>> field for alphas.  As far as RPM is concerned "9.5.0a5" > "9.5.0" which
>>> means you have to keep changing the epoch [31!  wow :-(] The correct way is
>>> to have a 0.a. or similar in the Release field.
>>>
>>> This is documented in the packaging guidelines:
>>> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages
>>
>> That package was released before I read policy :) Now all is quite
>> correct (9.5.0-18.a7)
>
>  I was going to go off on you for using 8.5.0a5 in the %version, but then I 
> checked what was actually on my nameserver and saw you didn't flub that up. 
> :-)
>  However, a minor point to note in the future is that it really ought to be 
> 9.5.0-0.18.a7, as per:
>
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a
>
>  ...but I'll let you get by with a light slap on the wrist. ;-)
>
>      Jima

It means raise epoch. And it could be danger because epoch could be
int8_t type (not sure :) ) and it could cause overflow when We hit
epoch 128 :)

Adam

-- 
Adam Tkac, Red Hat, Inc.



From jkeating at redhat.com  Wed Nov 28 18:03:11 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Nov 2007 13:03:11 -0500
Subject: Outage of all Phoenix based systems
In-Reply-To: <20071128123924.1f9e1d84@redhat.com>
References: <20071128123924.1f9e1d84@redhat.com>
Message-ID: <20071128130311.7d3ef890@redhat.com>

On Wed, 28 Nov 2007 12:39:24 -0500
Jesse Keating <jkeating at redhat.com> wrote:

> I will send another notice when services are back in order.

The outage is over.  All services should be operational again.  Please
let us know (either by replying to this on fedora-devel-list, or
pinging us on IRC on freenode, #fedora-admin).  Thanks!

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/ce0c0a68/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From sundaram at fedoraproject.org  Wed Nov 28 18:10:39 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Nov 2007 23:40:39 +0530
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474DAE1F.9000403@gmail.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127160436.GA8321@traged.englab.brq.redhat.com>	<474C5591.40003@gmail.com>	<200711281558.40421.ddmbox2@yahoo.co.uk>	<20071128123649.45651fd9@redhat.com>
	<474DAE1F.9000403@gmail.com>
Message-ID: <474DAF1F.5060807@fedoraproject.org>

Les Mikesell wrote:

> Like wanting things that have already been well tested and are known to 
> work reliably...  But without the 'more beta' phases, where would they 
> come from?  

RHEL has a long beta cycle of its own after getting forked from Fedora 
and usually ends up finding and fixing a set of issues which Fedora 
users are not very likely to report or care about including IBM 
mainframes, SAN storage and things like that.

Rahul



From jima at beer.tclug.org  Wed Nov 28 18:18:56 2007
From: jima at beer.tclug.org (Jima)
Date: Wed, 28 Nov 2007 12:18:56 -0600 (CST)
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128180641.GA14275@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>
	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<474D7DF4.5020508@redhat.com>
	<20071128145057.GB8522@evileye.atkac.englab.brq.redhat.com>
	<Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
	<20071128180641.GA14275@evileye.atkac.englab.brq.redhat.com>
Message-ID: <Pine.LNX.4.64.0711281217550.17671@beer.tclug.org>

On Wed, 28 Nov 2007, Adam Tkac wrote:
> It means raise epoch. And it could be danger because epoch could be
> int8_t type (not sure :) ) and it could cause overflow when We hit
> epoch 128 :)

  Sorry, I didn't mean "do this now," I meant "please do this in the 
future."  What's done is done; this isn't important enough to warrant an 
epoch. :-)

      Jima



From devrim at CommandPrompt.com  Wed Nov 28 18:19:13 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Wed, 28 Nov 2007 10:19:13 -0800
Subject: rpms/postfix/devel postfix.spec,1.60,1.61
In-Reply-To: <20071128110408.075bcb2a@ghistelwchlohm.scrye.com>
References: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
	<1196272487.31546.11.camel@localhost.localdomain>
	<20071128110408.075bcb2a@ghistelwchlohm.scrye.com>
Message-ID: <1196273953.31546.21.camel@localhost.localdomain>

Hi,

On Wed, 2007-11-28 at 11:04 -0700, Kevin Fenzi wrote:
> Upstream doesn't support loading them on the fly, so if it's
> enabled it means installing postfix pulls in mysql and posgresql. :(

Ok, so why don't we do it the Debian way: Compile postfix with both
PostgreSQL and MySQL support, and then provice dict_pgsql.so with
postfix-pgsql rpm (or same for -mysql package):

# dpkg -L postfix-pgsql
/.
/usr
/usr/lib
/usr/lib/postfix
/usr/lib/postfix/dict_pgsql.so
/usr/share
/usr/share/doc
/usr/share/doc/postfix-pgsql
/usr/share/doc/postfix-pgsql/README.Debian
/usr/share/doc/postfix-pgsql/copyright
/usr/share/doc/postfix-pgsql/changelog.Debian.gz

Regards,
-- 
Devrim G?ND?Z , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/230b1b73/attachment.sig>

From jdieter at gmail.com  Wed Nov 28 18:39:38 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Wed, 28 Nov 2007 20:39:38 +0200
Subject: Driver transition: via -> openchrome
In-Reply-To: <1196268260.22277.48.camel@localhost.localdomain>
References: <1196268260.22277.48.camel@localhost.localdomain>
Message-ID: <1196275179.4145.11.camel@jndwidescreen.lesbg.loc>

On Wed, 2007-11-28 at 11:44 -0500, Adam Jackson wrote:
> Just a heads-up:
> 
> The via driver in Xorg is pretty much dead.  Therefore, rawhide will be
> switching to openchrome.  xorg-x11-drivers now Requires openchrome on
> x86 and amd64 machines, and the openchrome package (once it builds
> again) will both provide and obsolete the via package, and munge your
> config file (if present) to change the driver name appropriately.  Also,
> X will load the new driver if started without a config file.
> 
> Shouldn't break anything, but if it does, as always, bugzilla is
> standing by and ready to take your call.
> 

Will this improve the chances of AIGLX support with VIA's?  I only ask
because we've just switched over to Fedora from Windows at our school
and one of the main things that appeals to the students is compiz.
Right now I've got it working correctly on our three or four-year-old
nVidia cards and brand new Intel cards, but our two or three year old
VIA cards aren't supported.

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/0e622ca3/attachment.sig>

From ville.skytta at iki.fi  Wed Nov 28 18:45:33 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 28 Nov 2007 20:45:33 +0200
Subject: Disable RPM's autoprovide function
In-Reply-To: <474CCD71.8050601@amiga-hardware.com>
References: <1196206283.23372.7.camel@Diffingo.localdomain>
	<474CCD71.8050601@amiga-hardware.com>
Message-ID: <200711282045.34650.ville.skytta@iki.fi>

On Wednesday 28 November 2007, Ian Chapman wrote:

> AutoReqProv: no
>
> which can be used to disable automatic dependency processing entirely
> but obviously any necessary dependencies would need to be specified
> manually.

If you're only interested in disabling automatic requires or provides, not 
both, there's "AutoReq: no" and "AutoProv: no".



From ddmbox2 at yahoo.co.uk  Wed Nov 28 18:46:27 2007
From: ddmbox2 at yahoo.co.uk (dexter)
Date: Wed, 28 Nov 2007 18:46:27 +0000
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128123649.45651fd9@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711281558.40421.ddmbox2@yahoo.co.uk>
	<20071128123649.45651fd9@redhat.com>
Message-ID: <200711281846.27901.ddmbox2@yahoo.co.uk>

On Wed November 28 2007 17:36:49 Jesse Keating wrote:
> Just because the features are Enterprise
> focused doesn't mean they're automatically beta.
true  
> It just means that 
> the focus is more on Enterprise needs, which are often customer driven.
But when your mission is to focus on Enterprise(rhel) customers just before 
they release it's not hard to see why people are saying fedora is beta for 
rhel. I personally don't see how you'll drop this tag when you have a couple 
of "Comunity focused" then a "Corporate focused" cycle.

...dex


 



From caolanm at redhat.com  Wed Nov 28 18:51:20 2007
From: caolanm at redhat.com (Caolan McNamara)
Date: Wed, 28 Nov 2007 18:51:20 +0000
Subject: rawhide report: 20071127 changes
In-Reply-To: <20071128103443.1a31d22e@ghistelwchlohm.scrye.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196240269.1109.10.camel@peecee.hoentjen.eu>
	<20071128103443.1a31d22e@ghistelwchlohm.scrye.com>
Message-ID: <1196275880.5226.912.camel@Jehannum>


On Wed, 2007-11-28 at 10:34 -0700, Kevin Fenzi wrote:
> On Wed, 28 Nov 2007 09:57:49 +0100
> sander at hoentjen.eu (Sander Hoentjen) wrote:
> 
> > On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
> > > New package zaf
> > >         South Africa hyphenation rules
> > 
> > Is it intentional that this one is not called hyphen-zaf?
> 
> yeah, I wondered about that as well, but the upstream package is
> clearly called 'zaf' for whatever reason. Possibly due to it handling
> several languages, but not a single locale... 

Yeah, Zuid-Africa -> zaf (I assume), http://zaf.sourceforge.net/ A South
African translation group.

C.



From tmz at pobox.com  Wed Nov 28 18:55:25 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 28 Nov 2007 13:55:25 -0500
Subject: rawhide report: 20071127 changes
In-Reply-To: <1196248039.12310.710.camel@mccallum.corsepiu.local>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196226860.12310.613.camel@mccallum.corsepiu.local>
	<20071128102843.GS8224@psilocybe.teonanacatl.org>
	<1196248039.12310.710.camel@mccallum.corsepiu.local>
Message-ID: <20071128185525.GU8224@psilocybe.teonanacatl.org>

Ralf Corsepius wrote:
> I know, several of my packages suffer from this issue and I would
> have liked to know if this doxygen is supposed to fix it, before I
> going to invest time myself ;)

Well, I did a scratch build of one of Patrice's affected packages
with the doxygen update and the problem is not there.  Chris Stone
reported earlier that his builds with doxygen 1.5.3 also did not
exhibit the problem.

I think it's seems likely enough that 1.5.3 does fix the anchor
problem to make it worth kicking off at least a scratch build of one
of your affected packages to verify.  If it doesn't work, comment in
the bug so we'll know to keep looking for a fix. :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Be it our wealth, our jobs, or even our homes; nothing is safe while
the legislature is in session.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/4e5c66a6/attachment.sig>

From ville.skytta at iki.fi  Wed Nov 28 18:59:44 2007
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 28 Nov 2007 20:59:44 +0200
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128180641.GA14275@evileye.atkac.englab.brq.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
	<20071128180641.GA14275@evileye.atkac.englab.brq.redhat.com>
Message-ID: <200711282059.45044.ville.skytta@iki.fi>

On Wednesday 28 November 2007, Adam Tkac wrote:

> And it could be danger because epoch could be
> int8_t type (not sure :) ) and it could cause overflow when We hit
> epoch 128 :)

No worries.  Sun's JDK rpms have had their epoch set to 2000 ever since they 
started distributing them as rpms as far as I know :]



From katzj at redhat.com  Wed Nov 28 19:00:09 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 28 Nov 2007 14:00:09 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711281846.27901.ddmbox2@yahoo.co.uk>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711281558.40421.ddmbox2@yahoo.co.uk>
	<20071128123649.45651fd9@redhat.com>
	<200711281846.27901.ddmbox2@yahoo.co.uk>
Message-ID: <1196276409.1392.9.camel@localhost.localdomain>

On Wed, 2007-11-28 at 18:46 +0000, dexter wrote:
> On Wed November 28 2007 17:36:49 Jesse Keating wrote:
> > Just because the features are Enterprise
> > focused doesn't mean they're automatically beta.
> true  
> > It just means that 
> > the focus is more on Enterprise needs, which are often customer driven.
> But when your mission is to focus on Enterprise(rhel) customers just before 
> they release it's not hard to see why people are saying fedora is beta for 
> rhel. I personally don't see how you'll drop this tag when you have a couple 
> of "Comunity focused" then a "Corporate focused" cycle.

The difference is what _types_ of things are being worked on.  ie, I
don't think that there are a huge number of Fedora/community users out
there clamoring for iSCSI support at install-time[1], but it was
something that mattered for enterprise customers -- thus, it was one of
the things that got a bit of my time in the FC6 cycle.  Alternately, a
lot of the work for the livecds, installing from the livecds, etc
weren't things that matter for enterprise customers but are very import
for Fedora.  And that's where a lot of my time has been for F7 and F8.  

But that said, the features being done for the enterprise case _are_
relevant and interesting to some of the community and so benefit
everyone.

Jeremy

[1] And the fact that it's been at least partially broken for most of
the F7 and F8 cycles (with some late fixups) without anyone noticing
helps to support this claim :-)



From kevin at scrye.com  Wed Nov 28 19:01:27 2007
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 28 Nov 2007 12:01:27 -0700
Subject: rpms/postfix/devel postfix.spec,1.60,1.61
In-Reply-To: <1196273953.31546.21.camel@localhost.localdomain>
References: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
	<1196272487.31546.11.camel@localhost.localdomain>
	<20071128110408.075bcb2a@ghistelwchlohm.scrye.com>
	<1196273953.31546.21.camel@localhost.localdomain>
Message-ID: <20071128120127.234c223d@ghistelwchlohm.scrye.com>

On Wed, 28 Nov 2007 10:19:13 -0800
devrim at CommandPrompt.com (Devrim G?ND?Z) wrote:

> Hi,
> 
> On Wed, 2007-11-28 at 11:04 -0700, Kevin Fenzi wrote:
> > Upstream doesn't support loading them on the fly, so if it's
> > enabled it means installing postfix pulls in mysql and posgresql. :(
> 
> Ok, so why don't we do it the Debian way: Compile postfix with both
> PostgreSQL and MySQL support, and then provice dict_pgsql.so with
> postfix-pgsql rpm (or same for -mysql package):
> 
> # dpkg -L postfix-pgsql
> /.
> /usr
> /usr/lib
> /usr/lib/postfix
> /usr/lib/postfix/dict_pgsql.so
> /usr/share
> /usr/share/doc
> /usr/share/doc/postfix-pgsql
> /usr/share/doc/postfix-pgsql/README.Debian
> /usr/share/doc/postfix-pgsql/copyright
> /usr/share/doc/postfix-pgsql/changelog.Debian.gz

Unfortunately, debian uses a local patch to provide dynamic loading of
postgresql support, which according to our postfix maintainer is buggy
and also doesn't work on all the platforms fedora supports. ;( 

See the merge review ticket for more info: 
https://bugzilla.redhat.com/show_bug.cgi?id=226307

> Regards,

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/7325ae74/attachment.sig>

From stransky at redhat.com  Wed Nov 28 19:15:15 2007
From: stransky at redhat.com (Martin Stransky)
Date: Wed, 28 Nov 2007 20:15:15 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128152752.GA7297@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127152535.GA7102@traged.englab.brq.redhat.com>	<20071128035807.GA3718@nostromo.devel.redhat.com>	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>	<20071128053010.GA10110@nostromo.devel.redhat.com>	<20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>	<474D4B68.7010909@redhat.com>
	<20071128152752.GA7297@nostromo.devel.redhat.com>
Message-ID: <474DBE43.5020501@redhat.com>

Bill Nottingham wrote:
> The issue is providing a reasonably stable usable platform - realistically,
> if ISC wanted people running a version of bind in production, wouldn't they
> *tag it as stable and release it*?  By shipping it in a release, we're
> essentially saying we know better than upstream what's appropriate for users.
> Do we?

This is *exactly* what I mean. Maintainer should know how things *really 
are*, not just blindly repeat what upstream officially says. Red Hat 
doesn't have to pay maintainers if it needs only robots who just pick up 
the latest stable version and package it w/o any thinking.

Maintainers have right to don't release the latest stable version if 
they think it's not ready yet, right? So why they can't release a 
pre-stable version if they think it's ready? (and when it doesn't break 
any upstream rules, of course).

Martin

P.S.: ISC is quite paranoid about releasing "stable" versions because it 
has customers who pay for ISC software and use it in critical 
environment. So in this case I think we can be quite relaxed.



From fedora at leemhuis.info  Wed Nov 28 19:19:56 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 28 Nov 2007 20:19:56 +0100
Subject: FYI: mail-notification switches to GPLv3
Message-ID: <474DBF5C.3050109@leemhuis.info>

FYI, mail-notification switches to GPLv3 for version 5.0-rc1, which I
just submitted for building in rawhide. There are afaik no packages that
link against mail-notification, so this shouldn't create trouble for
anyone afaics.

CU
knurd



From fedora at leemhuis.info  Wed Nov 28 19:27:22 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 28 Nov 2007 20:27:22 +0100
Subject: FYI: mail-notification switches to GPLv3
In-Reply-To: <474DBF5C.3050109@leemhuis.info>
References: <474DBF5C.3050109@leemhuis.info>
Message-ID: <474DC11A.7090001@leemhuis.info>



On 28.11.2007 20:19, Thorsten Leemhuis wrote:
> FYI, mail-notification switches to GPLv3 for version 5.0-rc1, which I
> just submitted for building in rawhide. There are afaik no packages that
> link against mail-notification, so this shouldn't create trouble for
> anyone afaics.

Forgot: is the "Please publicize any license changes to your packages"
rule from
https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01096.html

written down properly in the wiki somewhere? I wasn't sure anymore if we
had this rule and count not find it in the wiki where I looked for it.
Then I found it more by accident via the FWN, which is better then
nothing, but well, not really a official document.

Cu
knurd



From tcallawa at redhat.com  Wed Nov 28 19:33:54 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Nov 2007 14:33:54 -0500
Subject: FYI: mail-notification switches to GPLv3
In-Reply-To: <474DC11A.7090001@leemhuis.info>
References: <474DBF5C.3050109@leemhuis.info> <474DC11A.7090001@leemhuis.info>
Message-ID: <1196278435.27540.5.camel@localhost.localdomain>


On Wed, 2007-11-28 at 20:27 +0100, Thorsten Leemhuis wrote:
> 
> On 28.11.2007 20:19, Thorsten Leemhuis wrote:
> > FYI, mail-notification switches to GPLv3 for version 5.0-rc1, which I
> > just submitted for building in rawhide. There are afaik no packages that
> > link against mail-notification, so this shouldn't create trouble for
> > anyone afaics.
> 
> Forgot: is the "Please publicize any license changes to your packages"
> rule from
> https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01096.html
> 
> written down properly in the wiki somewhere? I wasn't sure anymore if we
> had this rule and count not find it in the wiki where I looked for it.
> Then I found it more by accident via the FWN, which is better then
> nothing, but well, not really a official document.

I don't think so. Its not really a packaging guideline, I suppose I
could add it to Licensing.

~spot



From darrellpf at gmail.com  Wed Nov 28 19:38:52 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 28 Nov 2007 11:38:52 -0800
Subject: rawhide report: 20071127 changes
In-Reply-To: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
Message-ID: <f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>

>selinux-policy-3.1.2-1.fc9
>--------------------------
>* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 3.1.2-1
>- Merge with upstream
>- Allow xsever to read hwdata_t
>- Allow login programs to setkeycreate

Yum updates are hanging at updating selinux-policy-targeted

Looks like "semodule -b base.pp -i awaitstats.pp ... " is just sitting waiting

This has happened on 3 different systems. I think all have selinux off.

darrell



From mschwendt.tmp0701.nospam at arcor.de  Wed Nov 28 19:39:23 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Wed, 28 Nov 2007 20:39:23 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <200711282059.45044.ville.skytta@iki.fi>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<Pine.LNX.4.64.0711281146350.17671@beer.tclug.org>
	<20071128180641.GA14275@evileye.atkac.englab.brq.redhat.com>
	<200711282059.45044.ville.skytta@iki.fi>
Message-ID: <20071128203923.a94e6ae9.mschwendt.tmp0701.nospam@arcor.de>

On Wed, 28 Nov 2007 20:59:44 +0200, Ville Skytt? wrote:

> On Wednesday 28 November 2007, Adam Tkac wrote:
> 
> > And it could be danger because epoch could be
> > int8_t type (not sure :) ) and it could cause overflow when We hit
> > epoch 128 :)
> 
> No worries.  Sun's JDK rpms have had their epoch set to 2000 ever since they 
> started distributing them as rpms as far as I know :]

HylaFax used to do something similar to

  Serial: %{date +%%G%%m%%d}

;o)



From williams at redhat.com  Wed Nov 28 19:41:43 2007
From: williams at redhat.com (Clark Williams)
Date: Wed, 28 Nov 2007 13:41:43 -0600
Subject: rawhide report: 20071127 changes
In-Reply-To: <f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
Message-ID: <474DC477.9020102@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

darrell pfeifer wrote:
>> selinux-policy-3.1.2-1.fc9
>> --------------------------
>> * Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 3.1.2-1
>> - Merge with upstream
>> - Allow xsever to read hwdata_t
>> - Allow login programs to setkeycreate
> 
> Yum updates are hanging at updating selinux-policy-targeted
> 
> Looks like "semodule -b base.pp -i awaitstats.pp ... " is just sitting waiting
> 
> This has happened on 3 different systems. I think all have selinux off.
> 
> darrell
> 

Mine hung with SELINUX=permissive

Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHTcR3Hyuj/+TTEp0RAo0nAKCcSdHL5pgVmq5Ra9BpfnYSaEquQwCg5Chk
9Pm936NAA49xpDCLEeaB6kE=
=FnlW
-----END PGP SIGNATURE-----



From thomas.swan at gmail.com  Wed Nov 28 19:42:02 2007
From: thomas.swan at gmail.com (Thomas Swan)
Date: Wed, 28 Nov 2007 13:42:02 -0600
Subject: Fedora 8 installation crash
In-Reply-To: <abb19e6c0711280909j5ed14a58v9d8d0aa474b50ab@mail.gmail.com>
References: <abb19e6c0711280909j5ed14a58v9d8d0aa474b50ab@mail.gmail.com>
Message-ID: <abb19e6c0711281142p192aeb56ycceff7215d3c83d0@mail.gmail.com>

This error happens when starting the installation process after the media
check screen (skip).  The installer cannot validate the media (validated on
two other computers) either locally or using USB DVD drives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/b1f8d0ed/attachment.htm>

From devrim at CommandPrompt.com  Wed Nov 28 19:42:00 2007
From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=)
Date: Wed, 28 Nov 2007 11:42:00 -0800
Subject: rpms/postfix/devel postfix.spec,1.60,1.61
In-Reply-To: <20071128110408.075bcb2a@ghistelwchlohm.scrye.com>
References: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
	<1196272487.31546.11.camel@localhost.localdomain>
	<20071128110408.075bcb2a@ghistelwchlohm.scrye.com>
Message-ID: <1196278920.31546.31.camel@localhost.localdomain>

Hi,

On Wed, 2007-11-28 at 11:04 -0700, Kevin Fenzi wrote:

> I would really like postgresql support too... but it's not an easy
> problem. Upstream doesn't support loading them on the fly, so if it's
> enabled it means installing postfix pulls in mysql and posgresql. :(

Currently Postfix RPMs does not require MySQL to install postfix:

https://devrim.privatepaste.com/ada5Up30HE

Either this is a packaging error, or intentional. If it is intentional,
I think we can add PostgreSQL support.

/me is a PostgreSQL advocate ;)
Regards,
-- 
Devrim G?ND?Z , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/eb08ea4d/attachment.sig>

From berrange at redhat.com  Wed Nov 28 19:43:32 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 28 Nov 2007 19:43:32 +0000
Subject: rawhide report: 20071127 changes
In-Reply-To: <f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
Message-ID: <20071128194332.GF7379@redhat.com>

On Wed, Nov 28, 2007 at 11:38:52AM -0800, darrell pfeifer wrote:
> >selinux-policy-3.1.2-1.fc9
> >--------------------------
> >* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 3.1.2-1
> >- Merge with upstream
> >- Allow xsever to read hwdata_t
> >- Allow login programs to setkeycreate
> 
> Yum updates are hanging at updating selinux-policy-targeted
> 
> Looks like "semodule -b base.pp -i awaitstats.pp ... " is just sitting waiting
> 
> This has happened on 3 different systems. I think all have selinux off.

I had this happen too.

I strace'd semodule & it was blocking on a write() call to a pipe connected
to the parent process. So I killed semodule, and now the parent (the /bin/sh
process for the %post script) blocked on writing to its parent  (yum). So
I killed that too, and now yum blocked writing too. Finally I Ctrl-C'd
yum, and it spewed a bunch of warning messages to stderr, which clearly
came from semodule.

So, two issues - semodule should redirect all its output to /dev/null in
the %post script, and  yum should make sure it consumes both stdout/err
from any scripts it runs so they don't block.

Unfortunately, I lost the strace logs before I could file a BZ report and
my other machines are fine with the update.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From opensource at till.name  Wed Nov 28 19:44:08 2007
From: opensource at till.name (Till Maas)
Date: Wed, 28 Nov 2007 20:44:08 +0100
Subject: FYI: mail-notification switches to GPLv3
In-Reply-To: <1196278435.27540.5.camel@localhost.localdomain>
References: <474DBF5C.3050109@leemhuis.info> <474DC11A.7090001@leemhuis.info>
	<1196278435.27540.5.camel@localhost.localdomain>
Message-ID: <200711282044.15572.opensource@till.name>

On Mi November 28 2007, Tom "spot" Callaway wrote:

> I don't think so. Its not really a packaging guideline, I suppose I
> could add it to Licensing.

Iirc there is somewhere a page that describes the steps needed to update a 
package, but I cannot find it currently. There it would fit best imho.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/8ed4c2a1/attachment.sig>

From sundaram at fedoraproject.org  Wed Nov 28 19:44:20 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Nov 2007 01:14:20 +0530
Subject: FYI: mail-notification switches to GPLv3
In-Reply-To: <200711282044.15572.opensource@till.name>
References: <474DBF5C.3050109@leemhuis.info>
	<474DC11A.7090001@leemhuis.info>	<1196278435.27540.5.camel@localhost.localdomain>
	<200711282044.15572.opensource@till.name>
Message-ID: <474DC514.8000507@fedoraproject.org>

Till Maas wrote:
> On Mi November 28 2007, Tom "spot" Callaway wrote:
> 
>> I don't think so. Its not really a packaging guideline, I suppose I
>> could add it to Licensing.
> 
> Iirc there is somewhere a page that describes the steps needed to update a 
> package, but I cannot find it currently. There it would fit best imho.

You are talking about

http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo

Rahul



From choeger at cs.tu-berlin.de  Wed Nov 28 19:59:31 2007
From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=)
Date: Wed, 28 Nov 2007 20:59:31 +0100
Subject: Why does eclipse-platform depend on tomcat?
Message-ID: <474DC8A3.3010100@cs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

just wondering why eclipse should need an application server...

regards

chrsitoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHTciihMBO4cVSGS8RAi7eAKC4dy6fKffNvue67yQ2mVSnW4lb2QCgl5o+
l/0A0qtBB2wCAMDKqn6Emsc=
=QmOv
-----END PGP SIGNATURE-----



From tmz at pobox.com  Wed Nov 28 20:22:57 2007
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 28 Nov 2007 15:22:57 -0500
Subject: rpms/postfix/devel postfix.spec,1.60,1.61
In-Reply-To: <1196278920.31546.31.camel@localhost.localdomain>
References: <200711281722.lASHMwSP025599@cvs-int.fedora.redhat.com>
	<1196272487.31546.11.camel@localhost.localdomain>
	<20071128110408.075bcb2a@ghistelwchlohm.scrye.com>
	<1196278920.31546.31.camel@localhost.localdomain>
Message-ID: <20071128202257.GV8224@psilocybe.teonanacatl.org>

Devrim G?ND?Z wrote:
> On Wed, 2007-11-28 at 11:04 -0700, Kevin Fenzi wrote:
> 
>> I would really like postgresql support too... but it's not an easy
>> problem. Upstream doesn't support loading them on the fly, so if
>> it's enabled it means installing postfix pulls in mysql and
>> posgresql. :(
> 
> Currently Postfix RPMs does not require MySQL to install postfix:
> 
> https://devrim.privatepaste.com/ada5Up30HE
> 
> Either this is a packaging error, or intentional. If it is
> intentional, I think we can add PostgreSQL support.

The postfix spec in cvs contains this:

%if %{MYSQL}
Requires: mysql-libs
BuildRequires: mysql-devel
%endif

The 2.4.5-2.fc8 package doesn't have mysql or postgres enabled, so it
shouldn't require either.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Between two evils, I always pick the one I never tried before.
    -- Mae West

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/402f1122/attachment.sig>

From katzj at redhat.com  Wed Nov 28 20:23:51 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 28 Nov 2007 15:23:51 -0500
Subject: rawhide report: 20071127 changes
In-Reply-To: <f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
Message-ID: <1196281432.1392.36.camel@localhost.localdomain>

On Wed, 2007-11-28 at 11:38 -0800, darrell pfeifer wrote:
> >selinux-policy-3.1.2-1.fc9
> >--------------------------
> >* Mon Nov 19 2007 Dan Walsh <dwalsh at redhat.com> 3.1.2-1
> >- Merge with upstream
> >- Allow xsever to read hwdata_t
> >- Allow login programs to setkeycreate
> 
> Yum updates are hanging at updating selinux-policy-targeted
> 
> Looks like "semodule -b base.pp -i awaitstats.pp ... " is just sitting waiting
> 
> This has happened on 3 different systems. I think all have selinux off.

If you look at ls -l /proc/<pid of yum>/fd and then cat the output of
the file which is a pipe, you'll work around this (see bug 368271).  I
thought we had already pushed this fix out, but apparently I'm half
asleep and we never did.  Will hopefully get built later today

Jeremy



From katzj at redhat.com  Wed Nov 28 20:25:34 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 28 Nov 2007 15:25:34 -0500
Subject: rawhide report: 20071127 changes
In-Reply-To: <20071128194332.GF7379@redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<f6e5806f0711281138s4a194047x7efc31f2b2968bcd@mail.gmail.com>
	<20071128194332.GF7379@redhat.com>
Message-ID: <1196281534.1392.38.camel@localhost.localdomain>

On Wed, 2007-11-28 at 19:43 +0000, Daniel P. Berrange wrote:
> So, two issues - semodule should redirect all its output to /dev/null in
> the %post script, 

It depends -- some error output (like this specific case where it really
is unexpected) is probably fine to keep doing as otherwise it's going to
fail just as much, only silently.

> and  yum should make sure it consumes both stdout/err
> from any scripts it runs so they don't block.

Yeah, as my other mail said -- we tracked this down a couple of weeks
ago but then never did a build

Jeremy



From pmachata at redhat.com  Wed Nov 28 20:33:31 2007
From: pmachata at redhat.com (Petr Machata)
Date: Wed, 28 Nov 2007 21:33:31 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora 8?]
In-Reply-To: <200711281133.19824.sgrubb@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>
	<fijuhr$20o$1@ger.gmane.org> <200711281133.19824.sgrubb@redhat.com>
Message-ID: <474DD09B.8040907@redhat.com>

Steve Grubb wrote:
> kdepim-enterprise-svn20070926.tar.bz2

As a side note, I always wondered why to use date in the release tag of
package, whose sources come from non-cvs versioning system.  For svn, in
my opinion, it would make more sense to use the tree revision number;
for git, similarly, sha1 id of the tree.

Could the guideline [1] wording be adjusted to point packagers towards
those less ambiguous identifiers?  Or maybe the intention of the release
tag is not so much to be truly non-ambiguous about the actual origin of
the sources, as rather to give a rough idea when was the commit done?

[1]
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease

> 
> -Steve
> 

Thanks,
PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/99d546e2/attachment.sig>

From tcallawa at redhat.com  Wed Nov 28 20:35:34 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Nov 2007 15:35:34 -0500
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in
	Fedora 8?]
In-Reply-To: <474DD09B.8040907@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com> <fijuhr$20o$1@ger.gmane.org>
	<200711281133.19824.sgrubb@redhat.com>  <474DD09B.8040907@redhat.com>
Message-ID: <1196282134.27540.11.camel@localhost.localdomain>


On Wed, 2007-11-28 at 21:33 +0100, Petr Machata wrote:
> Steve Grubb wrote:
> > kdepim-enterprise-svn20070926.tar.bz2
> 
> As a side note, I always wondered why to use date in the release tag of
> package, whose sources come from non-cvs versioning system.  For svn, in
> my opinion, it would make more sense to use the tree revision number;
> for git, similarly, sha1 id of the tree.
> 
> Could the guideline [1] wording be adjusted to point packagers towards
> those less ambiguous identifiers?  Or maybe the intention of the release
> tag is not so much to be truly non-ambiguous about the actual origin of
> the sources, as rather to give a rough idea when was the commit done?

Look down one item on the same page:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#SnapshotPackages

We explicitly say that tree revision numbers can be used in addition to
the date, but we do want to keep the date in there.

~spot



From pmachata at redhat.com  Wed Nov 28 20:52:37 2007
From: pmachata at redhat.com (Petr Machata)
Date: Wed, 28 Nov 2007 21:52:37 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in	Fedora
 8?]
In-Reply-To: <1196282134.27540.11.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>
	<fijuhr$20o$1@ger.gmane.org>	<200711281133.19824.sgrubb@redhat.com>
	<474DD09B.8040907@redhat.com>
	<1196282134.27540.11.camel@localhost.localdomain>
Message-ID: <474DD515.2090000@redhat.com>

Tom "spot" Callaway wrote:
> We explicitly say that tree revision numbers can be used in addition to
> the date, but we do want to keep the date in there.

Thanks, thats fine with me.  I admit I've just checked the examples and
blindly assumed that the wording stayed the same.

> 
> ~spot
> 

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/6bcf992d/attachment.sig>

From ajackson at redhat.com  Wed Nov 28 21:37:16 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Wed, 28 Nov 2007 16:37:16 -0500
Subject: Driver transition: via -> openchrome
In-Reply-To: <1196275179.4145.11.camel@jndwidescreen.lesbg.loc>
References: <1196268260.22277.48.camel@localhost.localdomain>
	<1196275179.4145.11.camel@jndwidescreen.lesbg.loc>
Message-ID: <1196285836.22277.55.camel@localhost.localdomain>

On Wed, 2007-11-28 at 20:39 +0200, Jonathan Dieter wrote:
> Will this improve the chances of AIGLX support with VIA's?  I only ask
> because we've just switched over to Fedora from Windows at our school
> and one of the main things that appeals to the students is compiz.
> Right now I've got it working correctly on our three or four-year-old
> nVidia cards and brand new Intel cards, but our two or three year old
> VIA cards aren't supported.

It certainly won't hurt.  This is just changing the 2D driver, the 3D
driver remains the same, but since the new 2D driver will run on more
cards, the 3D driver may do so as well.

One thing to note about AIGLX support on via hardware is that compiz
currently requires non-power-of-two texture support from the driver, and
the via DRI driver does not expose that functionality yet.  I'm not even
sure all via chips _have_ that feature in silicon.  AIGLX on its own is
just fast indirect GL; it's necessary for compiz, but not sufficient.

- ajax



From overholt at redhat.com  Wed Nov 28 21:07:40 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 28 Nov 2007 16:07:40 -0500
Subject: Why does eclipse-platform depend on tomcat?
In-Reply-To: <474DC8A3.3010100@cs.tu-berlin.de>
References: <474DC8A3.3010100@cs.tu-berlin.de>
Message-ID: <20071128210740.GB16346@redhat.com>

* Christoph H?ger <choeger at cs.tu-berlin.de> [2007-11-28 15:00]:
> 
> just wondering why eclipse should need an application server...

It's used for the help system.  Technically in 3.3.x, jetty is used, but
I didn't want to deviate from upstream's SDK by not keeping tomcat in
there (plus, there may be 3rd part plugins that depend upon it and I
didn't want them to work with an upstream download and not with our
RPMs).  FWIW, I dont' think it'll be in 3.4.  Also note that the help
system is actually broken and I've got a fix coming as part of the
3.3.1.1 update.  It's in rawhide now.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/a4f9b12f/attachment.sig>

From overholt at redhat.com  Wed Nov 28 21:08:59 2007
From: overholt at redhat.com (Andrew Overholt)
Date: Wed, 28 Nov 2007 16:08:59 -0500
Subject: RSSOwl status?
In-Reply-To: <loom.20071127T205641-266@post.gmane.org>
References: <loom.20071127T205641-266@post.gmane.org>
Message-ID: <20071128210859.GC16346@redhat.com>

* Jack Tanner <ihok at hotmail.com> [2007-11-27 16:08]:
> 
> In the meantime, RSSOwl 2.x is up to Milestone 6, and iText's homepage
> talks about a dual LGPL/MPL license. It'd be nice if we could could we
> have RSSOwl in some form now. Either 2M6 or 1.2 with the (seemingly
> kosher) iText would be great.

I can help you with packaging of this if you like.  I can't commit to
taking it on myself, but I'd love to have it back.  I can talk to the
authors and see if they think shipping 2.0M6 would be okay.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/9e2d1059/attachment.sig>

From jonathan.underwood at gmail.com  Wed Nov 28 21:16:21 2007
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 28 Nov 2007 21:16:21 +0000
Subject: RSSOwl status?
In-Reply-To: <loom.20071127T205641-266@post.gmane.org>
References: <loom.20071127T205641-266@post.gmane.org>
Message-ID: <645d17210711281316u77cb3a17gfaa14a6e5297d454@mail.gmail.com>

On 27/11/2007, Jack Tanner <ihok at hotmail.com> wrote:
> As far as I can tell by googling around, RSSOwl 1.x got dropped at some
> point because it depended on iText, which had licensing issues. RSSOwl 2.x,
> which is not yet out, will dispense with iText, and we can have it back then.
>
> In the meantime, RSSOwl 2.x is up to Milestone 6, and iText's homepage
> talks about a dual LGPL/MPL license. It'd be nice if we could could we have
> RSSOwl in some form now. Either 2M6 or 1.2 with the (seemingly kosher) iText
> would be great.

iText is still not useable in Fedora - see the recent discussions on
this mailing list.



From lmacken at redhat.com  Wed Nov 28 18:30:48 2007
From: lmacken at redhat.com (Luke Macken)
Date: Wed, 28 Nov 2007 13:30:48 -0500
Subject: updates-testing notification changes
Message-ID: <20071128183048.GA4765@crow.redhat.com>

As decided during last weeks QA meeting[0], bodhi will no longer spam
fedora-test-list with updates-testing notifications.

Bodhi now has RSS feeds that support querying updates using any combination
of release, status, or type:

    https://admin.fedoraproject.org/updates/rss/rss2.0?status={pending,testing,stable}&release={F8,F7}&type={security,bugfix,enhancement}

If you want to see a list of updates-testing packages that you have
installed on your local system, install the bodhi-client[1] package and run
`bodhi --testable`.  From here, your testing feedback is encouraged and
will help ensure that we don't push any broken packages out to our users.

I also added support for anonymous access and feedback, so discussions about
test updates can now be held inside of bodhi.  At the moment, anonymous
feedback is able to effect an updates karma.  This is subject to
changing in the future, so if anyone notices this feature getting
abused, please let me know.

        http://bodhi.fedoraproject.org

luke

[0]: http://fedoraproject.org/wiki/QA/Meetings/20071114
[1]: https://hosted.fedoraproject.org/projects/bodhi/wiki/CLI

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From wwoods at redhat.com  Wed Nov 28 21:47:50 2007
From: wwoods at redhat.com (Will Woods)
Date: Wed, 28 Nov 2007 16:47:50 -0500
Subject: Bugzilla 'version' changes for Fedora this Friday!
Message-ID: <1196286470.8146.3.camel@metroid.rdu.redhat.com>

Hi folks!

To help make Bugzilla easier to use and understand, we're going to make
two changes to the 'version' field:

1) Stop using the fNtestX versions, and
2) Rename "devel" to "rawhide".

We're doing this because of two facts about Fedora development:
First, test releases are just rawhide snapshots, so they shouldn't be
tracked as their own special versions. Second, everyone calls the
development tree "Rawhide", so Bugzilla should reflect that.

So here's what's happening. This Friday, all bugs filed against Test
versions of Fedora will be moved to the corresponding final release -
for example, fc6test2 bugs will be moved to fc6. The testX versions will
then be removed from the version list in Bugzilla. Finally we'll rename
"devel" to "rawhide". 

NOTE: this MAY BREAK scripts or links that used "devel". If you have any
such scripts, make sure you update them as soon as possible!

Thanks!

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071128/41f9964e/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From andrewparker at bigfoot.com  Wed Nov 28 22:03:04 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Wed, 28 Nov 2007 17:03:04 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <1196234293.8588.0.camel@rousalka.dyndns.org>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
	<6c3f5e6c0711271433p2cd98c32q2104a82fe2255615@mail.gmail.com>
	<1196234293.8588.0.camel@rousalka.dyndns.org>
Message-ID: <6c3f5e6c0711281403v36a07f2dga0d48072a0c460be@mail.gmail.com>

On Nov 28, 2007 2:18 AM, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
>
> Le mardi 27 novembre 2007 ? 17:33 -0500, Andrew Parker a ?crit :
> > On Nov 27, 2007 5:06 PM, KH KH <kwizart at gmail.com> wrote:
>
> > > ivtv-firmware and xorg-x11-drv-ivtv have been approved but still were
> > > not imported because of "competing" review request... (my website is
> > > offline for the next 24hours)
>
> > I don't think that's quite true.  The driver is now part of the
> > kernel, but you still need to install the firmware and the userland
> > tools such as ivtvctl.
>
> Read again the last bit of Nicolas's post.

Eh?  Your other post?  I don't see what you're referring to.

I have a PVR-150, and had to install the firmware before the kernel
will recognise the card properly.  Without the userland tools you can
tell it which input source and audio source to use either.  They may
be deprecated, but I'm not aware of an alternative (please enlighten
me if there is one)

If you check the livna repo, they provide both the firware and the
userland tools (which is just a partial build of the IVTV download for
kernels >= 2.6.22)



From poelstra at redhat.com  Wed Nov 28 22:12:28 2007
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 28 Nov 2007 14:12:28 -0800
Subject: Changes to Fedora 9 Feature Page
Message-ID: <474DE7CC.8000605@redhat.com>

re: http://fedoraproject.org/wiki/Releases/9/FeatureList

Greetings from Featureland,

In anticipation of tomorrow's FESCo meeting, the feature dashboard http://fedoraproject.org/wiki/Features/Dashboard
is up and running again for Fedora 9.  Here you'll find the status of all the features targeted for Fedora 9.  I have also contacted each of the feature owners individually as needed.

During the lead up to Fedora 8 GA, the Fedora 9 feature list page: http://fedoraproject.org/wiki/Releases/9/FeatureList#proposed became somewhat of a white-board for ideas people had for Fedora 9.  After tomorrow's FESCo meeting I will clear this page out to correctly reflect features that have a wiki page in CategoryProposedFedora9 and are being formally targeted for Fedora 9.

Thank you,
John

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From cra at WPI.EDU  Wed Nov 28 23:13:50 2007
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 28 Nov 2007 18:13:50 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474DBE43.5020501@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127152535.GA7102@traged.englab.brq.redhat.com>
	<20071128035807.GA3718@nostromo.devel.redhat.com>
	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>
	<20071128053010.GA10110@nostromo.devel.redhat.com>
	<20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>
	<474D4B68.7010909@redhat.com>
	<20071128152752.GA7297@nostromo.devel.redhat.com>
	<474DBE43.5020501@redhat.com>
Message-ID: <20071128231350.GG24257@angus.ind.WPI.EDU>

On Wed, Nov 28, 2007 at 08:15:15PM +0100, Martin Stransky wrote:
> P.S.: ISC is quite paranoid about releasing "stable" versions bacause it 
> has customers who pay for ISC software and use it in critical environment. 
> So in this case I think we can be quite relaxed.

But doesn't ISC also need a period of releases where they can go hog 
wild with changes, new features, etc. and not worry about stability as 
much?  Isn't that period of time usually called "Alpha"?  It's like 
Rawhide--the software in there may be stable, but it doesn't have to 
be, and often isn't at the beginning of a new release cycle.

It's all about perception.  I wouldn't put Rawhide on my production 
servers, and I don't expect something that upstream calls "Alpha" to 
be on my production servers either.



From darrellpf at gmail.com  Wed Nov 28 23:31:53 2007
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 28 Nov 2007 15:31:53 -0800
Subject: rawhide report: 20071127 changes
In-Reply-To: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
Message-ID: <f6e5806f0711281531u413584cy127f767a6af0899a@mail.gmail.com>

>kernel-2.6.24-0.43.rc3.git1.fc9
>-------------------------------
>* Mon Nov 26 2007 David Woodhouse <dwmw2 at redhat.com>
>- Build libertas wireless driver
>- Include flash translation layers in modules.block list

On my Dell Inspiron 9300 laptop boot fails just after the fbcon messages.

2.6.24-0.42.rc3.git1.fc9 works.

I haven't had a chance to try this kernel on other machines.



From chris.stone at gmail.com  Thu Nov 29 01:31:39 2007
From: chris.stone at gmail.com (Christopher Stone)
Date: Wed, 28 Nov 2007 17:31:39 -0800
Subject: Review swappies
In-Reply-To: <1196181467.26555.55.camel@localhost.localdomain>
References: <474C18CA.6060504@hhs.nl>
	<1196181467.26555.55.camel@localhost.localdomain>
Message-ID: <d9c612bf0711281731g784e6533t3d892b389ca18560@mail.gmail.com>

On Nov 27, 2007 8:37 AM, Lubomir Kundrak <lkundrak at redhat.com> wrote:
>
> On Tue, 2007-11-27 at 14:16 +0100, Hans de Goede wrote:
> > Hi All,
> >
> > Below is a list of packages of mine awaiting review, anyone interested in
> > swapping a review for a packages of his?
>
> I recommend swapping package reviews with Hans to everyone. There are
> not many people who make such perfect and impressive packages as Hans!

I always manage to find a bug with his packages ;-)



From alexl at users.sourceforge.net  Thu Nov 29 02:21:20 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 28 Nov 2007 19:21:20 -0700
Subject: repoview + PackageDB (was Re: rawhide report: 20071127 changes)
In-Reply-To: <474DA5D7.6010700@gmail.com> (Toshio Kuratomi's message of "Wed\,
	28 Nov 2007 09\:31\:03 -0800")
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196242726.7360.0.camel@asmodeus.localdomain>
	<474DA5D7.6010700@gmail.com>
Message-ID: <c263zl6bbz.fsf_-_@allele2.eebweb.arizona.edu>

>>>>> "TK" == Toshio Kuratomi  writes:

TK> Patrick Ohearn wrote:
>> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
>> New package R-rlecuyer
>>> R interface to RNG with multiple streams
>>> 
>> Is there a web interface for checking different versions in
>> different repos, say like packages.gentoo.org and
>> packages.debian.org?
>> 
TK> You're looking for repoview:

TK> http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/i386/os/repoview/

Unfortunately repoview shows only a fraction of the information that
packages.debian.org and doesn't unify them nearly as well as
packages.debian.org does.

I think that PackageDB should ultimately become the equivalent kind of
"portal", because we have a proliferation of sites where various
package information is kept (bodhi, packagedb, koji, repoview) and it
would be nice to tie them in all together into a single package
"portal" the way Debian/Ubuntu does with all information about the
package in one location and fold the repoview stuff into it. You could
still keep the koji, bodhi web interfaces as they are, but have
PackageDB querying them and displaying all the latest information in
one place for each package.  PackageDB has started this with the new
bugzilla interface, which is nice.

I have some notes on this here:

https://hosted.fedoraproject.org/projects/packagedb/ticket/79#comment:1

Toshio made some notes on how they might be implemented there too.

TK> note that skvidal recently got repoview working again so there
TK> might be some rough edges.  Letting us know what those are on IRC
TK> (#fedora-admin) or in a ticket
TK> https://hosted.fedoraproject.org/projects/fedora-infrastructure/

Alex



From rc040203 at freenet.de  Thu Nov 29 02:23:55 2007
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 29 Nov 2007 03:23:55 +0100
Subject: rawhide report: 20071127 changes
In-Reply-To: <20071128185525.GU8224@psilocybe.teonanacatl.org>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196226860.12310.613.camel@mccallum.corsepiu.local>
	<20071128102843.GS8224@psilocybe.teonanacatl.org>
	<1196248039.12310.710.camel@mccallum.corsepiu.local>
	<20071128185525.GU8224@psilocybe.teonanacatl.org>
Message-ID: <1196303035.12310.801.camel@mccallum.corsepiu.local>


On Wed, 2007-11-28 at 13:55 -0500, Todd Zullinger wrote:
> Ralf Corsepius wrote:
> > I know, several of my packages suffer from this issue and I would
> > have liked to know if this doxygen is supposed to fix it, before I
> > going to invest time myself ;)
> 
> Well, I did a scratch build of one of Patrice's affected packages
> with the doxygen update and the problem is not there.  Chris Stone
> reported earlier that his builds with doxygen 1.5.3 also did not
> exhibit the problem.
Meanwhile, after having rebuilt a couple of my packages, I can confirm
this observation. It seems to solve this issue for my packages, too.

> I think it's seems likely enough that 1.5.3 does fix the anchor
> problem to make it worth kicking off at least a scratch build of one
> of your affected packages to verify.  If it doesn't work, comment in
> the bug so we'll know to keep looking for a fix. :)
I think 1.5.3 is worth to be pushed to FC-8 and FC-7 such that the
anchor problem gradually gets fixed there, too.

Ralf





From mike at miketc.com  Thu Nov 29 05:12:38 2007
From: mike at miketc.com (Mike Chambers)
Date: Wed, 28 Nov 2007 23:12:38 -0600
Subject: Bugzilla 'version' changes for Fedora this Friday!
In-Reply-To: <1196286470.8146.3.camel@metroid.rdu.redhat.com>
References: <1196286470.8146.3.camel@metroid.rdu.redhat.com>
Message-ID: <1196313158.8042.11.camel@scrappy.miketc.com>


On Wed, 2007-11-28 at 16:47 -0500, Will Woods wrote:
> So here's what's happening. This Friday, all bugs filed against Test
> versions of Fedora will be moved to the corresponding final release -
> for example, fc6test2 bugs will be moved to fc6. The testX versions
> will
> then be removed from the version list in Bugzilla. Finally we'll
> rename
> "devel" to "rawhide". 

Moving everything and the renaming is fine as is, to get things up to
date.  Not that I don't want to see things changed, just issues I
thought of.  But how will it work during testing?  As in, you have FX
Beta and you file bugs against rawhide?  And during testing, alpha,
beta, testing, rc, whatever they all go against rawhide, and the bugs
stay against rawhide between testing releases?  That may work fine, but
what about once the testing goes gold?  Do all bugs between last
official release that were filed against rawhide, get moved to the
final?

FX Development begins..

--->Alpha - bugs filed against rawhide?
---->Test - bugs filed against rawhide?
----->Beta- bugs filed against rawhide?
------>RC - bugs filed against rawhide?
------->Gold - Bugs moved from rawhide to FX?

In other words, no bugs should exist against rawhide, except during
development cycle between official releases?

-- 
Mike Chambers
Madisonville, KY

"The best lil town on Earth!"



From g at socallinuxexpo.org  Thu Nov 29 05:42:19 2007
From: g at socallinuxexpo.org (Gareth J. Greenaway)
Date: Wed, 28 Nov 2007 21:42:19 -0800
Subject: So Cal Linux Expo Calls For Papers close Friday!
Message-ID: <20071128214219.fca351cc.g@socallinuxexpo.org>

The Calls for Paper for the So Cal Linux Expo, and its Friday special 
sessions, Women in Open Source, Demonstrating Open Source Software 
Health Care Solutions, and Open Source Software in Education, close 
Friday 11/30.

If you're contemplating submitting a paper for any of these session, 
don't delay - there are only a few speaker slots left.

-- 
Gareth J. Greenaway <g at socallinuxexpo.org>
Voice - 877-831-2569 x130
Southern California Linux Expo 
http://www.socallinuxexpo.org



From fedora at leemhuis.info  Thu Nov 29 05:49:04 2007
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 29 Nov 2007 06:49:04 +0100
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <6c3f5e6c0711281403v36a07f2dga0d48072a0c460be@mail.gmail.com>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>	<1196196769.3414.6.camel@ignacio.lan>	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>	<6c3f5e6c0711271433p2cd98c32q2104a82fe2255615@mail.gmail.com>	<1196234293.8588.0.camel@rousalka.dyndns.org>
	<6c3f5e6c0711281403v36a07f2dga0d48072a0c460be@mail.gmail.com>
Message-ID: <474E52D0.3010104@leemhuis.info>

On 28.11.2007 23:03, Andrew Parker wrote:
> On Nov 28, 2007 2:18 AM, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
>> Le mardi 27 novembre 2007 ? 17:33 -0500, Andrew Parker a ?crit :
>>> On Nov 27, 2007 5:06 PM, KH KH <kwizart at gmail.com> wrote:
>>>> ivtv-firmware and xorg-x11-drv-ivtv have been approved but
>>>> still were not imported because of "competing" review
>>>> request... (my website is offline for the next 24hours)
>>> I don't think that's quite true.  The driver is now part of the 
>>> kernel, but you still need to install the firmware and the
>>> userland tools such as ivtvctl.
>> Read again the last bit of Nicolas's post.
> Eh?  Your other post?  I don't see what you're referring to.

KH KH is also a "Nicolas's", so he afaics referred to:

>>>> ivtv-firmware and xorg-x11-drv-ivtv have been approved but
>>>> still were not imported because of "competing" review
>>>> request... (my website is offline for the next 24hours)

HTH

> If you check the livna repo, they provide both the firware and the 
> userland tools (which is just a partial build of the IVTV download
> for kernels >= 2.6.22)

That would be news to me and I likely would know ;-)

But Atrpms ships it afaik.

CU
knurd



From nicu_fedora at nicubunu.ro  Thu Nov 29 06:34:53 2007
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 29 Nov 2007 08:34:53 +0200
Subject: [Fwd: [Inkscape-user] Fedora Package Maintainer]
In-Reply-To: <474DB005.1040509@gmail.com>
References: <474DB005.1040509@gmail.com>
Message-ID: <474E5D8D.6040400@nicubunu.ro>

Michael Beckwith wrote:
> Found this interesting and something that one of us could perhaps 
> partake in?

Michael, you should have forwarded this to the devel not art list.

/me grumpy about not being able to install Inkscape autopackaged nightly 
builds due to bad library requirements since F8 and not even able to 
submit a bug report after they changed the tracker from sf.net to Launchpad.

> ------------------------------------------------------------------------
> 
> Subject:
> [Inkscape-user] Fedora Package Maintainer
> 
> 
> Hello,
> 
> Denis Leroy e-mail me off list and mentioned that he's no longer
> interested in maintaining the Fedora package of Inkscape.  If there is
> any other Fedora packagers that are willing to pick it up, that'd be
> great.  I'm not sure of other Fedora lists that this should be posted
> to, but if people could forward it to those that would be great.
> 
> 	Thanks,
> 		Ted

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro



From michael.d.beckwith at gmail.com  Thu Nov 29 06:51:24 2007
From: michael.d.beckwith at gmail.com (Michael Beckwith)
Date: Thu, 29 Nov 2007 00:51:24 -0600
Subject: [Fwd: [Inkscape-user] Fedora Package Maintainer]
Message-ID: <474E616C.1050407@gmail.com>

It was suggested to me to forward this to the Devel list, so here it is.

-- 
~Michael
http://ridleytx.structed.net (for now)
http://michaelbox.net (eventually) 

-------------- next part --------------
An embedded message was scrubbed...
From: Ted Gould <ted at gould.cx>
Subject: [Inkscape-user] Fedora Package Maintainer
Date: Wed, 28 Nov 2007 09:48:55 -0800
Size: 5072
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/c3a227a4/attachment.eml>

From nicolas.mailhot at laposte.net  Thu Nov 29 08:27:25 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Nov 2007 09:27:25 +0100 (CET)
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in 
 Fedora 8?]
Message-ID: <17043.192.54.193.53.1196324845.squirrel@rousalka.dyndns.org>


Le Mer 28 novembre 2007 21:33, Petr Machata a ?crit :
> Steve Grubb wrote:
>> kdepim-enterprise-svn20070926.tar.bz2
>
> As a side note, I always wondered why to use date in the release tag
> of
> package, whose sources come from non-cvs versioning system.  For svn,
> in
> my opinion, it would make more sense to use the tree revision number;
> for git, similarly, sha1 id of the tree.

For git that would not be a number but for svn any shuffling upstream
does in its VCS can result in revision number changes, so relying on
them to identify sources is a big no-go.

-- 
Nicolas Mailhot



From nphilipp at redhat.com  Thu Nov 29 08:43:03 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 29 Nov 2007 09:43:03 +0100
Subject: Maintainers Responsibility (was alpha/beta software in Fedora	8)
In-Reply-To: <1196267471.2889.6.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196263849.10086.2.camel@nixon>
	<1196265089.29968.2.camel@localhost6.localdomain6>
	<1196267471.2889.6.camel@localhost.localdomain>
Message-ID: <1196325783.13689.12.camel@wombat.tiptoe.de>


On Wed, 2007-11-28 at 11:31 -0500, Matthias Clasen wrote:

> The importance of individual packages is pretty dependent on the use
> case. For most users of a Fedora desktop, it is probably far more
> disastrous if the email client or web browser crashes, than if some dns
> server the haven't installed has some bugs.

This assumes that Fedora is "just" a desktop, while it is much more --
the desktop is "just" a part of it. A significant one, surely, but a
part. From my POV, Adam was okay to put in that version of bind because
he tested it and found no problems, and most definitely not because the
bind package is somehow less important than say the gnome-panel.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Thu Nov 29 08:48:08 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 29 Nov 2007 09:48:08 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474DA0C9.2010809@fedoraproject.org>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<20071127160436.GA8321@traged.englab.brq.redhat.com>
	<474C5591.40003@gmail.com> <200711281558.40421.ddmbox2@yahoo.co.uk>
	<474DA0C9.2010809@fedoraproject.org>
Message-ID: <1196326088.13689.16.camel@wombat.tiptoe.de>


On Wed, 2007-11-28 at 22:39 +0530, Rahul Sundaram wrote:
> dexter wrote:
[...]
> > Hmm sounds like beta to me.
> 
> Ear damage probably.

Rahul, I don't think deriding people for their opinion or how they
interpret things helps in any way.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Thu Nov 29 08:53:27 2007
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 29 Nov 2007 09:53:27 +0100
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <Pine.LNX.4.64.0711281151170.17671@beer.tclug.org>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
	<1196246627.27991.17.camel@wombat.tiptoe.de>
	<20071128064718.31c0c40c@redhat.com>
	<1196263739.19874.6.camel@gibraltar.str.redhat.com>
	<20071128103341.76852e55@redhat.com>
	<Pine.LNX.4.64.0711281151170.17671@beer.tclug.org>
Message-ID: <1196326407.13689.19.camel@wombat.tiptoe.de>


On Wed, 2007-11-28 at 11:52 -0600, Jima wrote:
> On Wed, 28 Nov 2007, Jesse Keating wrote:
> > Nils Philippsen <nphilipp at redhat.com> wrote:
> >> What is the reasoning for needing to bump something else beside the
> >> epoch? As far as I'm concerned, epoch is the most significant part of
> >> the "combined version" of a package -- isn't that the case?
> >
> > The most basic example, if you just bump epoch and nothing else, the
> > resultant file name is no different than the previous file name.  You
> > can't store the two builds in the same directory, and it's quite
> > confusing.
> 
>   More importantly, wouldn't the CVS tag be the same, too?  That's a big 
> show-stopper.

I'd rather buy Jesse's filename argument -- (CVS) tags can be changed,
as can tagging schemes.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nicolas.mailhot at laposte.net  Thu Nov 29 09:12:52 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Nov 2007 10:12:52 +0100 (CET)
Subject: Core fonts packaging guidelines writer WANTED
Message-ID: <60213.192.54.193.53.1196327572.squirrel@rousalka.dyndns.org>

Hi,

As most of you know server-side fonts accessed through the core X11
protocol (aka core fonts) were superceded by client-side
(fontconfig...) fonts in the past years.

We've finally acknowledged this fact in Fedora 8 by removing xfs and
the brutal check that killed user X sessions if more fonts were
misconfigured (the dreaded "can not find font 'fixed'"). IIRC this was
an OLPC request and I fully support this decision.

As a result the burden of keeping core fonts working moved from the
distribution as a whole to the group of people maintaining and using
the small group of legacy applications that still use them.

It seems this change was not integrated properly and several core font
packages slipped in Fedora 8 in a broken state without anyone noticing
(not through evil intent, just because the affected packages are old
and
crufty and the people that stridently defend core fonts use were
doing something else). For the calendar-impaired, that was before the
Fonts SIG started its activities.

To fix this situation, I call for one or several core font users to
rise to the occasion:

A. Please join the fonts SIG
http://fedoraproject.org/wiki/SIGs/Fonts

B. Please write well-though core fonts packaging guidelines consistent
with the objectives of people already doing fonts work for other font
backends. That means in particular not having core font utilities
dependencies in font packages
http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy#no-handler-deps

Several possible technical solutions have already been posted on the
list, such as:
1. pre-generating fonts.* files at %build time or
2. duplicating the solution used for the fontconfig backend. That means:
  a. dynamically generating  fonts.* files in conditionnal scriptlets
(if core font tools are present on system), and
  b. have one package responsible for walking the configured core font
directories and re-generating fonts.* files when installed, and make
core font apps depend on it (so things still work if a core font
using app is installed after fonts packages are)

There may be other solutions, it's up to the core fonts community to
choose one.

Do not fall in the facility of brutaly making font packages depend on
mkfontdir, as a lot of font packages are not exposed only via the core
X11 protocol and most of their users do not want the core font stack
installed. (OLPC is such a group).

C. Please discuss your guidelines on the Fonts SIG list and among core
fonts users so we have consensus. Then get your guidelines
officialised

D. Please audit all the existing core fonts packages and make them
conform to the resulting core font guidelines, so we don't get
accidental breakage like right now

Anyone stepping in to do this will have my complete support, and I
hope the one of the whole distribution.

Otherwise Jens has indicated he may end up writing core fonts
packaging guidelines, but frankly given the level of abuse we've seen
from core font users lately I'd understand if he passed. And in the
end core fonts users would be better served by guidelines written by
less busy people who actually use the core fonts backend.

This will be my last statement on the subject. Thank you for your
attention.

-- 
Nicolas Mailhot


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/893dc2c5/attachment.htm>

From mcepl at redhat.com  Thu Nov 29 09:19:55 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 29 Nov 2007 10:19:55 +0100
Subject: alpha/beta software in Fedora 8?
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<1196260463.3054.64.camel@localhost.localdomain>
	<20071128093812.51022c3c@redhat.com>
Message-ID: <rqc225x3p6.ln2@hubmaier.ceplovi.cz>

On Wed, 28 Nov 2007 09:38:12 -0500, Jesse Keating scripst:
> However what Chris and others are asking for is a general guideline to
> help maintainers use their best judgment and that's what I attempted to
> provide. We're providing some criteria for which the maintainer to base
> their judgment on.

OK, but please don't call it "policy" (which implicates at least for this 
former lawyer a set of binding rules), but something like "Some hints on 
finding out whether the upstream relase is good enough for Fedora". I am 
afraid, that policy-wise we cannot make any better rule for maintainers 
than "Don't be stupid" or something of this sort.

Mat?j

-- 
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
Of course I'm respectable. I'm old. Politicians, ugly buildings,
and whores all get respectable if they last long enough.
      --John Huston in "Chinatown."



From mcepl at redhat.com  Thu Nov 29 09:23:07 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 29 Nov 2007 10:23:07 +0100
Subject: alpha/beta software in Fedora 8?
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com> <474D7F0B.6060207@redhat.com>
Message-ID: <r0d225x3p6.ln2@hubmaier.ceplovi.cz>

On Wed, 28 Nov 2007 15:45:31 +0100, Christopher Aillon scripst:

> On 11/28/2007 01:55 PM, Jesse Keating wrote:
>> On Wed, 28 Nov 2007 07:46:53 -0500
>> "Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:
>> 
>>> Well, I'm not sure how it can be considered perfect when it does not
>>> begin to address the "alpha/beta" issue that you think is resolvable
>>> with packaging policy.
>> 
>> "In general, it is preferred if maintainers avoid releasing "alpha" or
>> "beta" builds of packages into Fedora (both Rawhide and released
>> updates).  However a package maintainer has the right to use their own
>> discretion regarding this issue and may provide whatever (s)he sees fit
>> for the user base.  Things to consider include the amount of testing an
>> alpha or beta release has seen, the timeline to turn said alpha or beta
>> into a stable release, the feature sets provided, or the bugs fixed.
>> There may be other factors at play as well, which is why the person
>> best suited to make such a decision is the package maintainer in
>> question."
> 
> This would also work.  Just so a maintainer can figure out what general
> path they should be following in a release.  /me likes.

I think this is the way to hell -- we will be writing long and longer 
legalese which won't mean much more than "Don't be stupid and test your 
packages". If there is need for some hints how to find out whether the 
upstream release (or non-release) is good enough for Fedora, than let's 
make HOWTO or something like that, but please don't try to write rules 
about something which cannot be codified.

Mat?j

-- 
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
As a rule of thumb, the more qualifiers there are before the name
of a country, the more corrupt the rulers. A country called The
Socialist People's Democratic Republic of X is probably the last
place in the world you'd want to live.
    -- Paul Graham discussing (not only) Nigerian spam
       (http://www.paulgraham.com/spam.html)



From pmachata at redhat.com  Thu Nov 29 10:06:44 2007
From: pmachata at redhat.com (Petr Machata)
Date: Thu, 29 Nov 2007 11:06:44 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <17043.192.54.193.53.1196324845.squirrel@rousalka.dyndns.org>
References: <17043.192.54.193.53.1196324845.squirrel@rousalka.dyndns.org>
Message-ID: <474E8F34.6070904@redhat.com>

Nicolas Mailhot wrote:
> For git that would not be a number but for svn any shuffling upstream
> does in its VCS can result in revision number changes, so relying on
> them to identify sources is a big no-go.

So you are telling that I could get two different source trees by
checking out some given revision X from svn at two different times?

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/b9ad53fd/attachment.sig>

From caillon at redhat.com  Thu Nov 29 10:12:37 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 29 Nov 2007 11:12:37 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <r0d225x3p6.ln2@hubmaier.ceplovi.cz>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>	<1196254013.3054.58.camel@localhost.localdomain>	<20071128075534.716563b5@redhat.com>
	<474D7F0B.6060207@redhat.com> <r0d225x3p6.ln2@hubmaier.ceplovi.cz>
Message-ID: <474E9095.7000209@redhat.com>

On 11/29/2007 10:23 AM, Matej Cepl wrote:
> On Wed, 28 Nov 2007 15:45:31 +0100, Christopher Aillon scripst:
> 
>> On 11/28/2007 01:55 PM, Jesse Keating wrote:
>>> On Wed, 28 Nov 2007 07:46:53 -0500
>>> "Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:
>>>
>>>> Well, I'm not sure how it can be considered perfect when it does not
>>>> begin to address the "alpha/beta" issue that you think is resolvable
>>>> with packaging policy.
>>> "In general, it is preferred if maintainers avoid releasing "alpha" or
>>> "beta" builds of packages into Fedora (both Rawhide and released
>>> updates).  However a package maintainer has the right to use their own
>>> discretion regarding this issue and may provide whatever (s)he sees fit
>>> for the user base.  Things to consider include the amount of testing an
>>> alpha or beta release has seen, the timeline to turn said alpha or beta
>>> into a stable release, the feature sets provided, or the bugs fixed.
>>> There may be other factors at play as well, which is why the person
>>> best suited to make such a decision is the package maintainer in
>>> question."
>> This would also work.  Just so a maintainer can figure out what general
>> path they should be following in a release.  /me likes.
> 
> I think this is the way to hell -- we will be writing long and longer 
> legalese which won't mean much more than "Don't be stupid and test your 
> packages".


If we want to empower maintainers to be able to MAKE (good) decisions, 
we MUST give them some guidelines.  Making decisions is the reason WHY 
we have maintainers.  Else, we could just script blindly following 
upstream.  And THAT would be real hell.

This is not trying to BIND[*] maintainers to anything.  This is trying 
to EDUCATE as to what sorts of things they should be looking for so they 
are able to execute their judgements.  Call it guidelines, suggestions, 
hints, policy, whatever.  That's all pedantry.  But if we are able to 
give maintainers some help on making more decisions, it will be more 
rewarding for the maintainer and everyone involved.

[*] Pun not really intended, noticed on second reading of it.



From j.w.r.degoede at hhs.nl  Thu Nov 29 10:09:41 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 29 Nov 2007 11:09:41 +0100
Subject: Core fonts packaging guidelines writer WANTED
In-Reply-To: <60213.192.54.193.53.1196327572.squirrel@rousalka.dyndns.org>
References: <60213.192.54.193.53.1196327572.squirrel@rousalka.dyndns.org>
Message-ID: <474E8FE5.4050702@hhs.nl>

Nicolas Mailhot wrote:
> Hi,
> 
> As most of you know server-side fonts accessed through the core X11
> protocol (aka core fonts) were superceded by client-side
> (fontconfig...) fonts in the past years.
> 
> We've finally acknowledged this fact in Fedora 8 by removing xfs and
> the brutal check that killed user X sessions if more fonts were
> misconfigured (the dreaded "can not find font 'fixed'"). IIRC this was
> an OLPC request and I fully support this decision.
> 
> As a result the burden of keeping core fonts working moved from the
> distribution as a whole to the group of people maintaining and using
> the small group of legacy applications that still use them.
> 
> It seems this change was not integrated properly and several core font
> packages slipped in Fedora 8 in a broken state without anyone noticing
> (not through evil intent, just because the affected packages are old
> and
> crufty and the people that stridently defend core fonts use were
> doing something else). For the calendar-impaired, that was before the
> Fonts SIG started its activities.
> 
> To fix this situation, I call for one or several core font users to
> rise to the occasion:
> 
> A. Please join the fonts SIG
> http://fedoraproject.org/wiki/SIGs/Fonts
> 
> B. Please write well-though core fonts packaging guidelines consistent
> with the objectives of people already doing fonts work for other font
> backends. That means in particular not having core font utilities
> dependencies in font packages
> http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy#no-handler-deps
> 
> Several possible technical solutions have already been posted on the
> list, such as:
> 1. pre-generating fonts.* files at %build time or
> 2. duplicating the solution used for the fontconfig backend. That means:
>   a. dynamically generating  fonts.* files in conditionnal scriptlets
> (if core font tools are present on system), and
>   b. have one package responsible for walking the configured core font
> directories and re-generating fonts.* files when installed, and make
> core font apps depend on it (so things still work if a core font
> using app is installed after fonts packages are)
> 
> There may be other solutions, it's up to the core fonts community to
> choose one.
> 
> Do not fall in the facility of brutaly making font packages depend on
> mkfontdir, as a lot of font packages are not exposed only via the core
> X11 protocol and most of their users do not want the core font stack
> installed. (OLPC is such a group).
> 

And here is the problem, when you write "the level of abuse we've seen
from core font users lately" below, I guess you mean mainly me, and I apologize 
as I indeed have wrongly blamed the font SIG for the current breakage.

However the above alinea starting at "Do not fall ..." is simply not 
acceptable, there are 2 and only 2 options here:
1) Leave core font packages as they are, as that has worked well for years, and
    thus have them depend upon mkfontdir and mkfontscale
2) Come up with something new that will not break things, and has the desired
    removal of dependencies upon mkfontdir / mkfontscale

It seems that some people want to see 2, but want someone else to do the work 
for 2, that is simply not acceptable. If someone wants 2 to happen, then its up 
to that person to write new guidelines and drive the effort to make the 
necessary changes.

Just saying that things must change because someone wants that and then looking 
at other people to do the actual work will not work, that is what all the fuzz 
is about, about some people wanting to see this changed and then shoving / 
pushing the work of those changes to the plate of some other people, who are 
quite happy with the current state of affairs.

> C. Please discuss your guidelines on the Fonts SIG list and among core
> fonts users so we have consensus. Then get your guidelines
> officialised
> 
> D. Please audit all the existing core fonts packages and make them
> conform to the resulting core font guidelines, so we don't get
> accidental breakage like right now
> 
> Anyone stepping in to do this will have my complete support, and I
> hope the one of the whole distribution.
> 

And here is the problem again, if some people want to see things changed 
(mainly see the requires upon mkfontdir / mkfontscale removed) then those 
people should be willing to do the work and stop looking for "Anyone stepping 
in to do this". I for one refuse to be that anyone and I will keep complaining 
loudly when things are changed in a way that causes regressions for core font 
users.

> Otherwise Jens has indicated he may end up writing core fonts
> packaging guidelines, but frankly given the level of abuse we've seen
> from core font users lately I'd understand if he passed. And in the
> end core fonts users would be better served by guidelines written by
> less busy people who actually use the core fonts backend.
> 

I think having the work being done by someone who actually want to see things 
changed, and thus is motivated to do the work is an excellent idea. I know as 
little about core fonts as most, all I know is some apps I use use them and I 
don't want to see them broken.

Regards,

Hans



From atkac at redhat.com  Thu Nov 29 10:42:13 2007
From: atkac at redhat.com (Adam Tkac)
Date: Thu, 29 Nov 2007 11:42:13 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <474E9095.7000209@redhat.com>
References: <1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com> <474D7F0B.6060207@redhat.com>
	<r0d225x3p6.ln2@hubmaier.ceplovi.cz> <474E9095.7000209@redhat.com>
Message-ID: <20071129104213.GA26822@evileye.atkac.englab.brq.redhat.com>

On Thu, Nov 29, 2007 at 11:12:37AM +0100, Christopher Aillon wrote:
>
> If we want to empower maintainers to be able to MAKE (good) decisions, we 
> MUST give them some guidelines.  Making decisions is the reason WHY we have 
> maintainers.  Else, we could just script blindly following upstream.  And 
> THAT would be real hell.

First We have to tell to maintainers of crucial packages that their
packages are crucial (may be funny I'm saying that :) ). This is far
more better than writting guidelines. Of course guidelines is good but
I think it's impossible use same guidelines on desktop field and
server field.

Adam

-- 
Adam Tkac, Red Hat, Inc.



From jonathan.roberts.uk at googlemail.com  Thu Nov 29 10:41:45 2007
From: jonathan.roberts.uk at googlemail.com (Jonathan Roberts)
Date: Thu, 29 Nov 2007 10:41:45 +0000
Subject: [Fwd: [Inkscape-user] Fedora Package Maintainer]
Message-ID: <1196332905.2732.4.camel@localhost.localdomain>

On Nov 28, 2007 9:14 AM, Michael Beckwith <michael d beckwith gmail com>
wrote:
>> Denis Leroy e-mail me off list and mentioned that he's no longer
>> interested in maintaining the Fedora package of Inkscape.  If there is
>> any other Fedora packagers that are willing to pick it up, that'd be
>> great.  I'm not sure of other Fedora lists that this should be posted
>> to, but if people could forward it to those that would be great.
>
>
>okay this definitely is not "a good thing"{tm}.  But I'm looking over
>what I'm maintaining now and there's no way I can commit to
>maintaining this one. I can't imagine inkscape not being maintained,
>but I can't be the one to do it.
>
>-jef

I'm guessing Inkscape would be a difficult package for your first one to learn on? 
If anybody thought this was a reasonable goal, I think I'd be happy to learn and maintain it...

And if so, if somebody could point me in the direction of some resources that would be
cool :D

Best wishes,

Jon






From simon.andrews at bbsrc.ac.uk  Thu Nov 29 10:55:56 2007
From: simon.andrews at bbsrc.ac.uk (Simon Andrews)
Date: Thu, 29 Nov 2007 10:55:56 +0000
Subject: mounting removable media never seems to work
In-Reply-To: <474C61E4.6030309@redhat.com>
References: <474C5BA3.2070702@andrei.myip.org> <474C61E4.6030309@redhat.com>
Message-ID: <fim5qp$t35$1@ger.gmane.org>

Warren Togami wrote:
> I did run into some data DVD's that mounted without issue on Windows XP 
> but utterly failed on Linux.

I had the same thing with UDF formatted CDs.  Worked fine on windows and 
would mount manually under linux, but gnome-mount wasn't having any of it.

https://bugzilla.redhat.com/show_bug.cgi?id=217862

I haven't been back to this issue since FC6 but I'd be very dissapointed 
if it was still present in F8.

Simon.



From mcepl at redhat.com  Thu Nov 29 11:07:27 2007
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 29 Nov 2007 12:07:27 +0100
Subject: alpha/beta software in Fedora 8?
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com> <474D7F0B.6060207@redhat.com>
	<r0d225x3p6.ln2@hubmaier.ceplovi.cz> <474E9095.7000209@redhat.com>
Message-ID: <f4j225x3p6.ln2@hubmaier.ceplovi.cz>

On Thu, 29 Nov 2007 11:12:37 +0100, Christopher Aillon scripst:
> Call it guidelines, suggestions, hints, policy, whatever.  That's all
> pedantry.

Yes, it is pedantry (what did you expect from me?), but it has some real 
life consequences -- Tom's long boring paragraph which no sane maintainer 
will ever read (I am afraid) is one example of trying to be too 
legalistic IMHO.

For hints text, something like this would be enough (again IMHO, and 
IAAL):

Maintainers should strongly avoid releasing "alpha" or "beta" builds of 
packages into Fedora (both Rawhide and especially into released 
distributions). If you think you need to do so, please, test thoroughly 
and write in the changelog the reasons why you did so (if possible with 
the timeline stable release could be expected).

or something of this kind.

Mat?j

-- 
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
When you're happy that cut and paste actually works I think it's
a sign you've been using X-Windows for too long.
   -- from /. discussion on poor integration between KDE and
      GNOME



From caillon at redhat.com  Thu Nov 29 11:29:56 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 29 Nov 2007 12:29:56 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <f4j225x3p6.ln2@hubmaier.ceplovi.cz>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>	<1196254013.3054.58.camel@localhost.localdomain>	<20071128075534.716563b5@redhat.com>
	<474D7F0B.6060207@redhat.com>	<r0d225x3p6.ln2@hubmaier.ceplovi.cz>
	<474E9095.7000209@redhat.com> <f4j225x3p6.ln2@hubmaier.ceplovi.cz>
Message-ID: <474EA2B4.50100@redhat.com>

On 11/29/2007 12:07 PM, Matej Cepl wrote:
> Maintainers should strongly avoid releasing "alpha" or "beta" builds of 
> packages into Fedora (both Rawhide and especially into released 
> distributions). If you think you need to do so, please, test thoroughly 
> and write in the changelog the reasons why you did so (if possible with 
> the timeline stable release could be expected).

Except this is much more restrictive.  I'm not trying to tell people 
what to do.  I'm more trying to answer the question:  "I'm not sure if I 
should bump package foo to x.y.z or not.  How do I decide?"  And you 
left out the IMHO important part that it is the maintainer's best 
judgement call in the end.  NOT a mandate.



From bnocera at redhat.com  Thu Nov 29 11:52:13 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 29 Nov 2007 11:52:13 +0000
Subject: Maintainers Responsibility (was alpha/beta software in Fedora	8)
In-Reply-To: <1196325783.13689.12.camel@wombat.tiptoe.de>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196263849.10086.2.camel@nixon>
	<1196265089.29968.2.camel@localhost6.localdomain6>
	<1196267471.2889.6.camel@localhost.localdomain>
	<1196325783.13689.12.camel@wombat.tiptoe.de>
Message-ID: <1196337133.3227.49.camel@cookie.hadess.net>


On Thu, 2007-11-29 at 09:43 +0100, Nils Philippsen wrote:
> On Wed, 2007-11-28 at 11:31 -0500, Matthias Clasen wrote:
> 
> > The importance of individual packages is pretty dependent on the use
> > case. For most users of a Fedora desktop, it is probably far more
> > disastrous if the email client or web browser crashes, than if some dns
> > server the haven't installed has some bugs.
> 
> This assumes that Fedora is "just" a desktop, while it is much more --
> the desktop is "just" a part of it. A significant one, surely, but a
> part. From my POV, Adam was okay to put in that version of bind because
> he tested it and found no problems, and most definitely not because the
> bind package is somehow less important than say the gnome-panel.

Read Matthias' reply again. He made no such assumption, you did: "For
most users of a Fedora desktop [...]"



From jkeating at redhat.com  Thu Nov 29 11:57:42 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Nov 2007 06:57:42 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <rqc225x3p6.ln2@hubmaier.ceplovi.cz>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
	<20071128092834.46014249@redhat.com>
	<1196260463.3054.64.camel@localhost.localdomain>
	<20071128093812.51022c3c@redhat.com>
	<rqc225x3p6.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071129065742.59b6bc13@redhat.com>

On Thu, 29 Nov 2007 10:19:55 +0100
Matej Cepl <mcepl at redhat.com> wrote:

> OK, but please don't call it "policy" (which implicates at least for
> this former lawyer a set of binding rules), but something like "Some
> hints on finding out whether the upstream relase is good enough for
> Fedora". I am afraid, that policy-wise we cannot make any better rule
> for maintainers than "Don't be stupid" or something of this sort.

I'm not really interested in playing word games.  If you must, call it
a Guideline to match our Packaging Guidelines.  I don't want there to
be 10 different terms for these things in our wiki.  So far we have
policy and guideline.  Pick one of those to file this under, I don't
care which.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/e278a85e/attachment.sig>

From jkeating at redhat.com  Thu Nov 29 12:01:13 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Nov 2007 07:01:13 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <f4j225x3p6.ln2@hubmaier.ceplovi.cz>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com> <474D7F0B.6060207@redhat.com>
	<r0d225x3p6.ln2@hubmaier.ceplovi.cz> <474E9095.7000209@redhat.com>
	<f4j225x3p6.ln2@hubmaier.ceplovi.cz>
Message-ID: <20071129070113.5952bc57@redhat.com>

On Thu, 29 Nov 2007 12:07:27 +0100
Matej Cepl <mcepl at redhat.com> wrote:

> Yes, it is pedantry (what did you expect from me?), but it has some
> real life consequences -- Tom's long boring paragraph which no sane
> maintainer will ever read (I am afraid) is one example of trying to
> be too legalistic IMHO.


Please don't speak for our maintainer base like this.  I know plenty of
"sane" maintainers who would gladly read a few paragraphs regarding
what the project would like to see in general followed for updating
packages.  We far too often fall into the trap of thinking that we're
overwhelming maintainers when in reality we're often so terse that they
have no earthly idea what we want and just go along and do whatever.

Lets give our maintainers a bit more credit and provide them some
breadcrumbs to follow.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/d6000f27/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Nov 29 12:08:46 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Nov 2007 13:08:46 +0100 (CET)
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in 
 Fedora 8?]
Message-ID: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>


Le Jeu 29 novembre 2007 11:06, Petr Machata a ?crit :
> Nicolas Mailhot wrote:
>> For git that would not be a number but for svn any shuffling
>> upstream
>> does in its VCS can result in revision number changes, so relying on
>> them to identify sources is a big no-go.
>
> So you are telling that I could get two different source trees by
> checking out some given revision X from svn at two different times?

I'm saying that srpms have a long live, and that with svn if you
request revision $number 5 years later if upstream has re-done its svn
in the meanwhile what you'll get is not what you got 5 years before.

-- 
Nicolas Mailhot



From tcallawa at redhat.com  Thu Nov 29 12:37:54 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 29 Nov 2007 07:37:54 -0500
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <f4j225x3p6.ln2@hubmaier.ceplovi.cz>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196130595.3229.20.camel@localhost.localdomain>
	<474C491F.2030204@redhat.com>
	<1196193744.3229.54.camel@localhost.localdomain>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com> <474D7F0B.6060207@redhat.com>
	<r0d225x3p6.ln2@hubmaier.ceplovi.cz> <474E9095.7000209@redhat.com>
	<f4j225x3p6.ln2@hubmaier.ceplovi.cz>
Message-ID: <1196339874.19501.26.camel@localhost.localdomain>


On Thu, 2007-11-29 at 12:07 +0100, Matej Cepl wrote:
> On Thu, 29 Nov 2007 11:12:37 +0100, Christopher Aillon scripst:
> > Call it guidelines, suggestions, hints, policy, whatever.  That's all
> > pedantry.
> 
> Yes, it is pedantry (what did you expect from me?), but it has some real 
> life consequences -- Tom's long boring paragraph which no sane maintainer 
> will ever read (I am afraid) is one example of trying to be too 
> legalistic IMHO.

Whoa. Not my paragraph. I've no interest in writing guidelines that boil
down to "don't be stupid, use common sense".

~spot



From pmachata at redhat.com  Thu Nov 29 12:47:16 2007
From: pmachata at redhat.com (Petr Machata)
Date: Thu, 29 Nov 2007 13:47:16 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>
References: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>
Message-ID: <474EB4D4.2040300@redhat.com>

Nicolas Mailhot wrote:
> I'm saying that srpms have a long live, and that with svn if you
> request revision $number 5 years later if upstream has re-done its svn
> in the meanwhile what you'll get is not what you got 5 years before.

Agreed.  By then the upstream could disappear, migrate to whatever hip
vc system there is in five years, etc.  And maybe I fail to see the
intent behind using the date in release tag of vcs-checkouted package.
Perhaps it's just an arbitrary identifier.  But if the intent is
anything close to making a life easier for whoever reconstructs the
srpm, using the release number makes more sense than the date alone.

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/5dcc1087/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Nov 29 12:54:31 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Nov 2007 13:54:31 +0100 (CET)
Subject: Core fonts packaging guidelines writer WANTED
Message-ID: <5567.192.54.193.53.1196340871.squirrel@rousalka.dyndns.org>


Le Jeu 29 novembre 2007 11:09, Hans de Goede a ?crit :
> Nicolas Mailhot wrote:

> And here is the problem, when you write "the level of abuse we've seen
> from core font users lately" below, I guess you mean mainly me, and I
> apologize as I indeed have wrongly blamed the font SIG for the current
> breakage.

My aim was not to blame anyone, and while particularly excessive your
reaction is fairly representative of the core font community so far.
(ignore changes, let things rot, blame others when they finish
breaking, and expect them to do the maintenance work in your stead).

> However the above alinea starting at "Do not fall ..." is simply not
> acceptable, there are 2 and only 2 options here:
> 1) Leave core font packages as they are, as that has worked well for
> years,

It hasn't worked well, the difference is that the magic fairies that
kept them working finaly left after numerous warnings enough was
enough, leaving the people who claimed there was no problem handle the
whole core fonts mess (since no one else used them anymore).

Like every other component of the distribution core fonts need
maintenance to keep working. The environment changes, if you want to
freeze it just install a Fedora 1 to 7 system. One of the changes is a
large group of users, OLPC, (that do actual work for the distro future
unlike frozen-in-time legacy apps) requested making core fonts
optional. Another is xfs was dumped. Yet another is the xorg version
we use changed, and the new version does not register core font
directories the same way. There are others I'm probably forgetting
now.

As a result leaving things as they are is not an option. Install
pre-fedora 8 core font packages in Fedora 8 and you'll see how well
they work in a current environment.

Do you really want me to comment on your choice of (quoting) "the new
guidelines are broken in that they do not offer a solution to the
problem this creates, so I say ignore them until this bug in the
guidelines gets fixed."?

(in other words intentionaly push the one solution you know conflicts
so someone else gets to document and fix the stuff your minority is
using)

Well I don't want to waste more time on this, my mail was addressed to
people who are actually willing to do some work to restore core fonts
to a maintained state. Please stand up. You'll get all the help the
Fonts SIG can extend to help you make your beloved legacy apps work.

I apologise to the lists for the flame spillovers.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Thu Nov 29 12:57:28 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Nov 2007 13:57:28 +0100 (CET)
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in 
 Fedora 8?]
Message-ID: <25039.192.54.193.53.1196341048.squirrel@rousalka.dyndns.org>


Le Jeu 29 novembre 2007 13:47, Petr Machata a ?crit :
> Nicolas Mailhot wrote:
>> I'm saying that srpms have a long live, and that with svn if you
>> request revision $number 5 years later if upstream has re-done its
>> svn
>> in the meanwhile what you'll get is not what you got 5 years before.
>
> Agreed.  By then the upstream could disappear, migrate to whatever hip
> vc system there is in five years, etc.

The problem with svn is that the breakage is insidious, since the same
release numbers will be reused in the new tree without any special
warning. So explicit date is needed to disambiguate svn versions.

Regards,

-- 
Nicolas Mailhot



From jsafrane at redhat.com  Thu Nov 29 13:03:06 2007
From: jsafrane at redhat.com (Jan Safranek)
Date: Thu, 29 Nov 2007 14:03:06 +0100
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <4745A750.4080904@redhat.com>
References: <4745A750.4080904@redhat.com>
Message-ID: <474EB88A.5010307@redhat.com>

Jan Safranek wrote:
> I'd like to update openldap in devel to the new version. Many packages 
> depend on openldap, so I will provide compat-openldap package, which 
> will provide 2.3.x libraries and no recompilation of any component would 
> be required.
> 
> I'd like to to ask all maintainers of components, which depend on 
> openldap (see appendix), to test following simple cases:
> 
> 1. the component works with compat-openldap, which provides 'old' 2.3.x
> libraries
...

I did not get any overwhelming response, actually only Terje Rosten 
responded that he tested his packages (thanks!). I internally tried to 
recompile all packages depending on openldap:

- most of the packages compiled OK
- callweaver, cyrus-sasl, kdesvn and subcommander were not compilable 
because of other changes in rawhide (bugs filled)
- only wine did not compile because two functions were renamed in new 
openldap (again, bug filled)

So I decided to release the openldap on Monday (2007-12-05), without any 
compat- package. I will explicitly send email to every maintainer of 
dependent package when the compilation finishes and new opendlap is in 
buildroot.

Jan



From nicolas.mailhot at laposte.net  Thu Nov 29 13:05:58 2007
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Nov 2007 14:05:58 +0100 (CET)
Subject: Core fonts packaging guidelines writer WANTED
Message-ID: <15861.192.54.193.53.1196341558.squirrel@rousalka.dyndns.org>


Le Jeu 29 novembre 2007 11:09, Hans de Goede a ?crit :

> And here is the problem again, if some people want to see things
> changed (mainly see the requires upon mkfontdir / mkfontscale removed)

To restore historical accuracy the broken package had no mkfontdir
dependencies through no particular action of mine, you proposed to add
them, and when I pointed out this would conflict with the work I'm
doing and that there were other solutions (that you already knew of)
you went in full-blown "screw the SIG if I break things hard enough it
will do the work my apps need" mode.

[again apologies for the flame spileage I hoped answers would be
limited to contructuve proposals]

-- 
Nicolas Mailhot



From limb at jcomserv.net  Thu Nov 29 13:18:08 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 29 Nov 2007 07:18:08 -0600 (CST)
Subject: Orphaning packages
Message-ID: <47494.63.85.68.164.1196342288.squirrel@mail.jcomserv.net>


> Hi,
>
> Just to let you know that other than the mono packages I currently
> maintain,
> I'm going to have to drop the other packages I have down for me.
>
> For ease, if it's a mono or mono-related package (such as mono-develop,
> libgdiplus, db4o etc), I'll maintain it. Anything else is dropped. I'll
> update
> the wiki and the owners lists as soon as I can.
>
> Basically, it's the old problem of time....

I'll take genchemlab and gonvert.

> TTFN
>
> Paul
>
> --
> Get your free @ukpost.com account now
> http://www.ukpost.com/
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From denis at poolshark.org  Thu Nov 29 13:28:11 2007
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 29 Nov 2007 14:28:11 +0100
Subject: [Fwd: [Inkscape-user] Fedora Package Maintainer]
In-Reply-To: <1196332905.2732.4.camel@localhost.localdomain>
References: <1196332905.2732.4.camel@localhost.localdomain>
Message-ID: <474EBE6B.4040400@poolshark.org>

I'll stay on as maintainer (or co-maintainer) at least until after the 
0.46 release, unless someone wants to take it over now. After 0.46 I'll 
orphan it. People interested in helping should be familiar with C++, and 
be ok with creating an account on launchpad :-)

Nicu, here's a SRPM from the latest svn snapshot. You'll need to compile 
this patched poppler RPM as well 
(https://bugzilla.redhat.com/show_bug.cgi?id=403211) :

http://www.poolshark.org/src/poppler-0.6-3.fc8.src.rpm
http://www.poolshark.org/src/inkscape-0.46-0.svn16571.fc8.src.rpm

-denis



From tmraz at redhat.com  Thu Nov 29 13:40:20 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 29 Nov 2007 14:40:20 +0100
Subject: Heads up: openssl and gnutls rebase in rawhide
Message-ID: <1196343620.3047.21.camel@vespa.kabelta.loc>

I have decided to complete the dependency breakage which will be caused
by the openldap update because many packages which depend on openldap
libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild
cycles I will do openssl and gnutls rebase in sync. There should not be
any API changes so simple rebuild will be sufficient.

I'm still undecided whether we should have a compat package for openssl
in Fedora so if you know any 3rd party software which will be broken by
the openssl libraries SONAME change and which is actively used on
current Fedoras, please let me know.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From lesmikesell at gmail.com  Thu Nov 29 13:42:08 2007
From: lesmikesell at gmail.com (Les Mikesell)
Date: Thu, 29 Nov 2007 07:42:08 -0600
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <25039.192.54.193.53.1196341048.squirrel@rousalka.dyndns.org>
References: <25039.192.54.193.53.1196341048.squirrel@rousalka.dyndns.org>
Message-ID: <474EC1B0.4070608@gmail.com>

Nicolas Mailhot wrote:
> Le Jeu 29 novembre 2007 13:47, Petr Machata a ?crit :
>> Nicolas Mailhot wrote:
>>> I'm saying that srpms have a long live, and that with svn if you
>>> request revision $number 5 years later if upstream has re-done its
>>> svn
>>> in the meanwhile what you'll get is not what you got 5 years before.
>> Agreed.  By then the upstream could disappear, migrate to whatever hip
>> vc system there is in five years, etc.
> 
> The problem with svn is that the breakage is insidious, since the same
> release numbers will be reused in the new tree without any special
> warning. So explicit date is needed to disambiguate svn versions.

I'm not sure if dates work if you've merged repositories with dump/load 
or converted cvs projects and loaded them separately.  Explicit tags 
should be reliable, though, if you tag everything that is released.

-- 
   Les Mikesell
    lesmikesell at gmail.com



From berrange at redhat.com  Thu Nov 29 13:45:51 2007
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 29 Nov 2007 13:45:51 +0000
Subject: Heads up: openssl and gnutls rebase in rawhide
In-Reply-To: <1196343620.3047.21.camel@vespa.kabelta.loc>
References: <1196343620.3047.21.camel@vespa.kabelta.loc>
Message-ID: <20071129134551.GA21587@redhat.com>

On Thu, Nov 29, 2007 at 02:40:20PM +0100, Tomas Mraz wrote:
> I have decided to complete the dependency breakage which will be caused
> by the openldap update because many packages which depend on openldap
> libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild
> cycles I will do openssl and gnutls rebase in sync. There should not be
> any API changes so simple rebuild will be sufficient.

Will there be an ABI / SONAME change for gnutls which /mandates/ a rebuild
of apps using it, or is it merely a suggested rebuild for sanity checks ?

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 



From pertusus at free.fr  Thu Nov 29 14:07:55 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 29 Nov 2007 15:07:55 +0100
Subject: Heads up: openssl and gnutls rebase in rawhide
In-Reply-To: <1196343620.3047.21.camel@vespa.kabelta.loc>
References: <1196343620.3047.21.camel@vespa.kabelta.loc>
Message-ID: <20071129140755.GC3154@free.fr>

On Thu, Nov 29, 2007 at 02:40:20PM +0100, Tomas Mraz wrote:
> I have decided to complete the dependency breakage which will be caused
> by the openldap update because many packages which depend on openldap
> libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild
> cycles I will do openssl and gnutls rebase in sync. There should not be
> any API changes so simple rebuild will be sufficient.

You mean there are ABI changes and no API changes?

--
Pat



From andy at smile.org.ua  Thu Nov 29 14:20:07 2007
From: andy at smile.org.ua (Andy Shevchenko)
Date: Thu, 29 Nov 2007 16:20:07 +0200
Subject: rpms/gnokii/F-8 gnokii.spec,1.19,1.20
In-Reply-To: <200711291348.lATDm2iP004168@cvs-int.fedora.redhat.com>
References: <200711291348.lATDm2iP004168@cvs-int.fedora.redhat.com>
Message-ID: <20071129142007.GA32513@serv.smile.org.ua>

Hi Bastien Nocera!

 On Thu, Nov 29, 2007 at 08:48:02AM -0500, Bastien Nocera wrote next:

> And again

> --- gnokii.spec	29 Nov 2007 12:50:02 -0000	1.19
> +++ gnokii.spec	29 Nov 2007 13:47:30 -0000	1.20
> @@ -138,7 +138,7 @@
>    xmandir=%{_mandir}/man1 docdir=/__docinst
>  
>  mv $RPM_BUILD_ROOT/__docinst .
> -rm __docinst/{README-MacOSX,README-WIN32,packaging-howto,ChangeLog,COPYING,COPYRIGHT,TODO,MAINTAINERS}
> +rm __docinst/{README-MacOSX,README-WIN32,ChangeLog,COPYING,COPYRIGHT,TODO,MAINTAINERS}
Why did you not use rm -f ?

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From mclasen at redhat.com  Thu Nov 29 14:39:15 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 29 Nov 2007 09:39:15 -0500
Subject: rpms/gnokii/F-8 gnokii.spec,1.19,1.20
In-Reply-To: <20071129142007.GA32513@serv.smile.org.ua>
References: <200711291348.lATDm2iP004168@cvs-int.fedora.redhat.com>
	<20071129142007.GA32513@serv.smile.org.ua>
Message-ID: <1196347155.3028.0.camel@localhost.localdomain>


On Thu, 2007-11-29 at 16:20 +0200, Andy Shevchenko wrote:
> Hi Bastien Nocera!
> 
>  On Thu, Nov 29, 2007 at 08:48:02AM -0500, Bastien Nocera wrote next:
> 
> > And again
> 
> > --- gnokii.spec	29 Nov 2007 12:50:02 -0000	1.19
> > +++ gnokii.spec	29 Nov 2007 13:47:30 -0000	1.20
> > @@ -138,7 +138,7 @@
> >    xmandir=%{_mandir}/man1 docdir=/__docinst
> >  
> >  mv $RPM_BUILD_ROOT/__docinst .
> > -rm __docinst/{README-MacOSX,README-WIN32,packaging-howto,ChangeLog,COPYING,COPYRIGHT,TODO,MAINTAINERS}
> > +rm __docinst/{README-MacOSX,README-WIN32,ChangeLog,COPYING,COPYRIGHT,TODO,MAINTAINERS}
> Why did you not use rm -f ?

If you use -f, the rm call will not fail, thus the cruft will likely
stay in your spec file forever, even if it is not needed anymore.

It is a bit like using excessive wildcards in your file list...



From jkeating at redhat.com  Thu Nov 29 14:37:32 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Nov 2007 09:37:32 -0500
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in
 Fedora 8?]
In-Reply-To: <474EC1B0.4070608@gmail.com>
References: <25039.192.54.193.53.1196341048.squirrel@rousalka.dyndns.org>
	<474EC1B0.4070608@gmail.com>
Message-ID: <20071129093732.7d655617@redhat.com>

On Thu, 29 Nov 2007 07:42:08 -0600
Les Mikesell <lesmikesell at gmail.com> wrote:

> I'm not sure if dates work if you've merged repositories with
> dump/load or converted cvs projects and loaded them separately.
> Explicit tags should be reliable, though, if you tag everything that
> is released.

It's not necessarily about the dates working as an ability to go back
and verify, but the dates show when said snapshot was taken and can
give clue as to why the current snapshot with the same rev number
doesn't match.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071129/405a1061/attachment.sig>

From limb at jcomserv.net  Thu Nov 29 14:56:06 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 29 Nov 2007 08:56:06 -0600 (CST)
Subject: Moodle package dependencies
Message-ID: <9766.63.85.68.164.1196348166.squirrel@mail.jcomserv.net>


>
>> Hi Jon,
>>
>> http://pastebot.ltsp.org/362
>> These are Ubuntu's plans to split up the Moodle package in order to make
>> it easier to maintain, especially for security updates.  Apparently
>> moodle ships entire other upstream projects within their distribution.
>> How are we in Fedora with using our own distro packages for this
>> functionality?
>
> If the versions work out, I see no reason not to do this.  I'll get
> started soon, definitely a good thing to do by F9.

The above is 404 now and is not in the Wayback machine.  Anyone got a copy
somewhere, or can point me in the right direction?

>> Warren Togami
>> wtogami at redhat.com
>>
>
>
> --
> novus ordo absurdum
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From laroche at redhat.com  Thu Nov 29 15:03:32 2007
From: laroche at redhat.com (Florian La Roche)
Date: Thu, 29 Nov 2007 16:03:32 +0100
Subject: [Rpm-metadata] createrepo 0.4.11
In-Reply-To: <1196258229.15420.196.camel@cutter>
References: <1196146117.15420.81.camel@cutter>
	<20071128132520.GA10754@dudweiler.stuttgart.redhat.com>
	<1196257161.15420.188.camel@cutter>
	<20071128135447.GA11876@dudweiler.stuttgart.redhat.com>
	<1196258229.15420.196.camel@cutter>
Message-ID: <20071129150332.GA10862@dudweiler.stuttgart.redhat.com>

On Wed, Nov 28, 2007 at 08:57:09AM -0500, seth vidal wrote:
> 
> On Wed, 2007-11-28 at 14:54 +0100, Florian La Roche wrote:
> > On Wed, Nov 28, 2007 at 08:39:21AM -0500, seth vidal wrote:
> > > 
> > > On Wed, 2007-11-28 at 14:25 +0100, Florian La Roche wrote:
> > > 
> > > > 
> > > > Hello Seth,
> > > > 
> > > > below is a patch to sort the output, otherwise createrepo
> > > > depends on the order of the local filesystem and how rpms
> > > > are stored there.
> > > 
> > > Why does the order matter? Doesn't this just take more time to do the
> > > sort?
> > 
> > It makes the metadata predictable and not dependent on the fs of the
> > server. 
> 
> Again, how does the predictability of order the filelists and deps/reqs
> are put into the metadata impact the functionality?


Hello Seth,

This is about stability of the data. Currently you cannot easily
run createrepo and quickly check the output against the existing data.


> 
> > The additional time should not matter at all here.
> 
> There are as many as 11000 pkgs in some of the repositories we create.
> How does it NOT matter if it takes extra time to sort each of them?


I am not aware of such limits for python .sort(). 11000 is not a huge
amount of data compared to other computations done in createrepo.

regards,

Florian La Roche


> 
> -sv
> 
> 
> _______________________________________________
> Rpm-metadata mailing list
> Rpm-metadata at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-metadata



From limb at jcomserv.net  Thu Nov 29 15:04:34 2007
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 29 Nov 2007 09:04:34 -0600 (CST)
Subject: Orphaning packages
Message-ID: <18129.63.85.68.164.1196348674.squirrel@mail.jcomserv.net>


>
>> Hi,
>>
>> Just to let you know that other than the mono packages I currently
>> maintain,
>> I'm going to have to drop the other packages I have down for me.
>>
>> For ease, if it's a mono or mono-related package (such as mono-develop,
>> libgdiplus, db4o etc), I'll maintain it. Anything else is dropped. I'll
>> update
>> the wiki and the owners lists as soon as I can.
>>
>> Basically, it's the old problem of time....
>
> I'll take genchemlab and gonvert.

Which you'll need to orphan in pkgdb, BTW.  In case you forgot.  I know I
would. :)

>> TTFN
>>
>> Paul
>>
>> --
>> Get your free @ukpost.com account now
>> http://www.ukpost.com/
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> --
> novus ordo absurdum
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
novus ordo absurdum



From skvidal at fedoraproject.org  Thu Nov 29 15:03:04 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 29 Nov 2007 10:03:04 -0500
Subject: [Rpm-metadata] createrepo 0.4.11
In-Reply-To: <20071129150332.GA10862@dudweiler.stuttgart.redhat.com>
References: <1196146117.15420.81.camel@cutter>
	<20071128132520.GA10754@dudweiler.stuttgart.redhat.com>
	<1196257161.15420.188.camel@cutter>
	<20071128135447.GA11876@dudweiler.stuttgart.redhat.com>
	<1196258229.15420.196.camel@cutter>
	<20071129150332.GA10862@dudweiler.stuttgart.redhat.com>
Message-ID: <1196348584.15420.247.camel@cutter>


On Thu, 2007-11-29 at 16:03 +0100, Florian La Roche wrote:
> On Wed, Nov 28, 2007 at 08:57:09AM -0500, seth vidal wrote:
> > 
> > On Wed, 2007-11-28 at 14:54 +0100, Florian La Roche wrote:
> > > On Wed, Nov 28, 2007 at 08:39:21AM -0500, seth vidal wrote:
> > > > 
> > > > On Wed, 2007-11-28 at 14:25 +0100, Florian La Roche wrote:
> > > > 
> > > > > 
> > > > > Hello Seth,
> > > > > 
> > > > > below is a patch to sort the output, otherwise createrepo
> > > > > depends on the order of the local filesystem and how rpms
> > > > > are stored there.
> > > > 
> > > > Why does the order matter? Doesn't this just take more time to do the
> > > > sort?
> > > 
> > > It makes the metadata predictable and not dependent on the fs of the
> > > server. 
> > 
> > Again, how does the predictability of order the filelists and deps/reqs
> > are put into the metadata impact the functionality?
> 
> 
> Hello Seth,
> 
> This is about stability of the data. Currently you cannot easily
> run createrepo and quickly check the output against the existing data.

yes, you can - use the metadata diff tool in createrepo's source -
dmd.py

> 
> > 
> > > The additional time should not matter at all here.
> > 
> > There are as many as 11000 pkgs in some of the repositories we create.
> > How does it NOT matter if it takes extra time to sort each of them?
> 
> 
> I am not aware of such limits for python .sort(). 11000 is not a huge
> amount of data compared to other computations done in createrepo.
> 

except that your code has us sorting all the files in each of the 11000
pkgs.

also - why  did you cc fedora-devel on this thread?

-sv




From debarshi.ray at gmail.com  Thu Nov 29 15:17:10 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 29 Nov 2007 20:47:10 +0530
Subject: Heads up: openssl and gnutls rebase in rawhide
In-Reply-To: <1196343620.3047.21.camel@vespa.kabelta.loc>
References: <1196343620.3047.21.camel@vespa.kabelta.loc>
Message-ID: <3170f42f0711290717x14f4f300ob8dac4f662d654d1@mail.gmail.com>

> I'm still undecided whether we should have a compat package for openssl
> in Fedora so if you know any 3rd party software which will be broken by
> the openssl libraries SONAME change and which is actively used on
> current Fedoras, please let me know.

httrack, present in F-7, F-8 and devel, dlopens libssl.so.0.9.8b and
has 'Requires: openssl = 0.9.8b'.

Happy hacking,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From tmraz at redhat.com  Thu Nov 29 15:19:23 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 29 Nov 2007 16:19:23 +0100
Subject: Heads up: openssl and gnutls rebase in rawhide
In-Reply-To: <20071129134551.GA21587@redhat.com>
References: <1196343620.3047.21.camel@vespa.kabelta.loc>
	<20071129134551.GA21587@redhat.com>
Message-ID: <1196349563.3047.26.camel@vespa.kabelta.loc>


On Thu, 2007-11-29 at 13:45 +0000, Daniel P. Berrange wrote:
> On Thu, Nov 29, 2007 at 02:40:20PM +0100, Tomas Mraz wrote:
> > I have decided to complete the dependency breakage which will be caused
> > by the openldap update because many packages which depend on openldap
> > libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild
> > cycles I will do openssl and gnutls rebase in sync. There should not be
> > any API changes so simple rebuild will be sufficient.
> 
> Will there be an ABI / SONAME change for gnutls which /mandates/ a rebuild
> of apps using it, or is it merely a suggested rebuild for sanity checks ?
I have expected there will be some ABI breakage but actually after
recompiling it and looking at the headers there are only additions so
there is no urgent need to rebuild packages depending just on gnutls.
There are of course some API changes - additions and using type aliases,
but they should break compilation of existing apps.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From tmraz at redhat.com  Thu Nov 29 15:21:08 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 29 Nov 2007 16:21:08 +0100
Subject: Heads up: openssl and gnutls rebase in rawhide
In-Reply-To: <20071129140755.GC3154@free.fr>
References: <1196343620.3047.21.camel@vespa.kabelta.loc>
	<20071129140755.GC3154@free.fr>
Message-ID: <1196349668.3047.29.camel@vespa.kabelta.loc>


On Thu, 2007-11-29 at 15:07 +0100, Patrice Dumas wrote:
> On Thu, Nov 29, 2007 at 02:40:20PM +0100, Tomas Mraz wrote:
> > I have decided to complete the dependency breakage which will be caused
> > by the openldap update because many packages which depend on openldap
> > libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild
> > cycles I will do openssl and gnutls rebase in sync. There should not be
> > any API changes so simple rebuild will be sufficient.
> 
> You mean there are ABI changes and no API changes?
For GNUTLS see my other mail. For OpenSSL - there are ABI changes -
structure sizes changes mostly and there are of course some API changes,
mostly additions, some constification etc. But they shouldn't break
compilation of existing apps of course.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From laroche at redhat.com  Thu Nov 29 15:32:03 2007
From: laroche at redhat.com (Florian La Roche)
Date: Thu, 29 Nov 2007 16:32:03 +0100
Subject: [Rpm-metadata] createrepo 0.4.11
In-Reply-To: <1196348584.15420.247.camel@cutter>
References: <1196146117.15420.81.camel@cutter>
	<20071128132520.GA10754@dudweiler.stuttgart.redhat.com>
	<1196257161.15420.188.camel@cutter>
	<20071128135447.GA11876@dudweiler.stuttgart.redhat.com>
	<1196258229.15420.196.camel@cutter>
	<20071129150332.GA10862@dudweiler.stuttgart.redhat.com>
	<1196348584.15420.247.camel@cutter>
Message-ID: <20071129153203.GA11777@dudweiler.stuttgart.redhat.com>

On Thu, Nov 29, 2007 at 10:03:04AM -0500, seth vidal wrote:
> 
> On Thu, 2007-11-29 at 16:03 +0100, Florian La Roche wrote:
> > On Wed, Nov 28, 2007 at 08:57:09AM -0500, seth vidal wrote:
> > > 
> > > On Wed, 2007-11-28 at 14:54 +0100, Florian La Roche wrote:
> > > > On Wed, Nov 28, 2007 at 08:39:21AM -0500, seth vidal wrote:
> > > > > 
> > > > > On Wed, 2007-11-28 at 14:25 +0100, Florian La Roche wrote:
> > > > > 
> > > > > > 
> > > > > > Hello Seth,
> > > > > > 
> > > > > > below is a patch to sort the output, otherwise createrepo
> > > > > > depends on the order of the local filesystem and how rpms
> > > > > > are stored there.
> > > > > 
> > > > > Why does the order matter? Doesn't this just take more time to do the
> > > > > sort?
> > > > 
> > > > It makes the metadata predictable and not dependent on the fs of the
> > > > server. 
> > > 
> > > Again, how does the predictability of order the filelists and deps/reqs
> > > are put into the metadata impact the functionality?
> > 
> > 
> > Hello Seth,
> > 
> > This is about stability of the data. Currently you cannot easily
> > run createrepo and quickly check the output against the existing data.
> 
> yes, you can - use the metadata diff tool in createrepo's source -
> dmd.py


Hello Seth,

dmd.py is nice, this wasn't part of earlier releases. I still think
putting this into the format you write out to disk is a plus.


> 
> > 
> > > 
> > > > The additional time should not matter at all here.
> > > 
> > > There are as many as 11000 pkgs in some of the repositories we create.
> > > How does it NOT matter if it takes extra time to sort each of them?
> > 
> > 
> > I am not aware of such limits for python .sort(). 11000 is not a huge
> > amount of data compared to other computations done in createrepo.
> > 
> 
> except that your code has us sorting all the files in each of the 11000
> pkgs.


Same data stability problem as above with filename sorting, to not
depend on python ordering.


> 
> also - why  did you cc fedora-devel on this thread?


To open up the discussion, not sure how many people are on
rpm-metadata.

regards,

Florian La Roche



From jima at beer.tclug.org  Thu Nov 29 15:38:00 2007
From: jima at beer.tclug.org (Jima)
Date: Thu, 29 Nov 2007 09:38:00 -0600 (CST)
Subject: Changing the rpm default queryformat to include arch
In-Reply-To: <1196326407.13689.19.camel@wombat.tiptoe.de>
References: <alpine.DEB.0.9999.0711211037460.32062@gotcha.dreamhost.com>
	<1195772447.14235.0.camel@localhost>
	<alpine.DEB.0.9999.0711271301080.14586@gotcha.dreamhost.com>
	<1196162658.12310.463.camel@mccallum.corsepiu.local>
	<20071127135357.960d2cde.mschwendt.tmp0701.nospam@arcor.de>
	<1196173233.3229.34.camel@localhost.localdomain>
	<alpine.DEB.0.9999.0711271650380.14586@gotcha.dreamhost.com>
	<20071127171238.8d67e45f.mschwendt.tmp0701.nospam@arcor.de>
	<20071127112914.264fa595@redhat.com>
	<1196246627.27991.17.camel@wombat.tiptoe.de>
	<20071128064718.31c0c40c@redhat.com>
	<1196263739.19874.6.camel@gibraltar.str.redhat.com>
	<20071128103341.76852e55@redhat.com>
	<Pine.LNX.4.64.0711281151170.17671@beer.tclug.org>
	<1196326407.13689.19.camel@wombat.tiptoe.de>
Message-ID: <Pine.LNX.4.64.0711290936200.17671@beer.tclug.org>

On Thu, 29 Nov 2007, Nils Philippsen wrote:
> On Wed, 2007-11-28 at 11:52 -0600, Jima wrote:
>> On Wed, 28 Nov 2007, Jesse Keating wrote:
>>> The most basic example, if you just bump epoch and nothing else, the
>>> resultant file name is no different than the previous file name.  You
>>> can't store the two builds in the same directory, and it's quite
>>> confusing.
>>
>>   More importantly, wouldn't the CVS tag be the same, too?  That's a big
>> show-stopper.
>
> I'd rather buy Jesse's filename argument -- (CVS) tags can be changed,
> as can tagging schemes.

  IIRC, you can't re-use a CVS tag once Koji's interacted with it, but in 
regard to changing the tagging _scheme_, yes, that could be done.

      Jima



From tmraz at redhat.com  Thu Nov 29 15:41:06 2007
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 29 Nov 2007 16:41:06 +0100
Subject: Heads up: openssl and gnutls rebase in rawhide
In-Reply-To: <3170f42f0711290717x14f4f300ob8dac4f662d654d1@mail.gmail.com>
References: <1196343620.3047.21.camel@vespa.kabelta.loc>
	<3170f42f0711290717x14f4f300ob8dac4f662d654d1@mail.gmail.com>
Message-ID: <1196350866.3047.32.camel@vespa.kabelta.loc>

On Thu, 2007-11-29 at 20:47 +0530, Debarshi 'Rishi' Ray wrote:
> > I'm still undecided whether we should have a compat package for openssl
> > in Fedora so if you know any 3rd party software which will be broken by
> > the openssl libraries SONAME change and which is actively used on
> > current Fedoras, please let me know.
> 
> httrack, present in F-7, F-8 and devel, dlopens libssl.so.0.9.8b and
> has 'Requires: openssl = 0.9.8b'.

That's not 3rd party software and so this can be easily patched in
fedora build of httrack.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From myfedora at richip.dhs.org  Thu Nov 29 15:47:27 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Thu, 29 Nov 2007 08:47:27 -0700
Subject: [Rpm-metadata] createrepo 0.4.11
In-Reply-To: <20071129153203.GA11777@dudweiler.stuttgart.redhat.com>
References: <1196146117.15420.81.camel@cutter>
	<20071128132520.GA10754@dudweiler.stuttgart.redhat.com>
	<1196257161.15420.188.camel@cutter>
	<20071128135447.GA11876@dudweiler.stuttgart.redhat.com>
	<1196258229.15420.196.camel@cutter>
	<20071129150332.GA10862@dudweiler.stuttgart.redhat.com>
	<1196348584.15420.247.camel@cutter>
	<20071129153203.GA11777@dudweiler.stuttgart.redhat.com>
Message-ID: <1196351247.7098.4.camel@localhost6.localdomain6>

On Thu, 2007-11-29 at 16:32 +0100, Florian La Roche wrote:
> On Thu, Nov 29, 2007 at 10:03:04AM -0500, seth vidal wrote:
> > 
> > On Thu, 2007-11-29 at 16:03 +0100, Florian La Roche wrote:
> > > On Wed, Nov 28, 2007 at 08:57:09AM -0500, seth vidal wrote:
> > > > 
> > > > On Wed, 2007-11-28 at 14:54 +0100, Florian La Roche wrote:
> > > > > On Wed, Nov 28, 2007 at 08:39:21AM -0500, seth vidal wrote:
> > > > > > 
> > > > > > On Wed, 2007-11-28 at 14:25 +0100, Florian La Roche wrote:
> > > > > > 
> > > > > > > 
> > > > > > > Hello Seth,
> > > > > > > 
> > > > > > > below is a patch to sort the output, otherwise createrepo
> > > > > > > depends on the order of the local filesystem and how rpms
> > > > > > > are stored there.
> > > > > > 
> > > > > > Why does the order matter? Doesn't this just take more time to do the
> > > > > > sort?
> > > > > 
> > > > > It makes the metadata predictable and not dependent on the fs of the
> > > > > server. 
> > > > 
> > > > Again, how does the predictability of order the filelists and deps/reqs
> > > > are put into the metadata impact the functionality?
> > > 
> > > 
> > > Hello Seth,
> > > 
> > > This is about stability of the data. Currently you cannot easily
> > > run createrepo and quickly check the output against the existing data.
> > 
> > yes, you can - use the metadata diff tool in createrepo's source -
> > dmd.py
> 
> 
> Hello Seth,
> 
> dmd.py is nice, this wasn't part of earlier releases. I still think
> putting this into the format you write out to disk is a plus.

Please, if it's not absolutely necessary nor does the eventual savings
in time, energy or security fallout outweigh the effort, let's not do
it. I don't mind sorting once if it means n-fold savings down the line.
Otherwise, we're just wasting time AND energy. Those CPU cycles
(potentially hundreds of them) do translate to something.

There are reasons for ordered and unordered lists. Kindly just argue for
the "plus" side if you can.
--

Richi Plana



From mschwendt.tmp0701.nospam at arcor.de  Thu Nov 29 15:52:15 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Thu, 29 Nov 2007 16:52:15 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in
 Fedora 8?]
In-Reply-To: <474EB4D4.2040300@redhat.com>
References: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>
	<474EB4D4.2040300@redhat.com>
Message-ID: <20071129165215.ab36369f.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 29 Nov 2007 13:47:16 +0100, Petr Machata wrote:

> Nicolas Mailhot wrote:
> > I'm saying that srpms have a long live, and that with svn if you
> > request revision $number 5 years later if upstream has re-done its svn
> > in the meanwhile what you'll get is not what you got 5 years before.
> 
> Agreed.  By then the upstream could disappear, migrate to whatever hip
> vc system there is in five years, etc.  And maybe I fail to see the
> intent behind using the date in release tag of vcs-checkouted package.
> Perhaps it's just an arbitrary identifier.  But if the intent is
> anything close to making a life easier for whoever reconstructs the
> srpm, using the release number makes more sense than the date alone.

The instructions on how to check out the source from cvs/svn/whatever
should be put into comments in the spec file. Don't attempt at squeezing
svn revisions (and silimar identifiers) into the package file name.

Originally, the date in the file name has been used as (1) information
about the age of a packaged post/pre-release _snapshot_ and (2) as the
least-significant portion of %release (the newer date of a newer checkout
would make the built package an upgrade without the need to bump %release
elsewhere).

If todays policies say you must add a date and SCM id like YYYYMMDDcvs,
they ought to be revisited. ;)



From a.badger at gmail.com  Thu Nov 29 15:56:13 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Nov 2007 07:56:13 -0800
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <474EB4D4.2040300@redhat.com>
References: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>
	<474EB4D4.2040300@redhat.com>
Message-ID: <474EE11D.3010608@gmail.com>

Petr Machata wrote:
> And maybe I fail to see the
> intent behind using the date in release tag of vcs-checkouted package.
> Perhaps it's just an arbitrary identifier.  But if the intent is
> anything close to making a life easier for whoever reconstructs the
> srpm, using the release number makes more sense than the date alone.
> 
After much discussion of exactly this point, the Packaging Committee 
decided that the date/revision id in release tag is not for 
reconstructing the srpm.  It's for consumers of the rpm to have a better 
idea of what they're getting.  For all vcs's a date is good for this as 
it tells the user they're getting a snapshot from a certain date.  For 
svn, and distributed vcs's that have an incrementing release number on a 
canonical branch the release number can be useful for those that are 
following upstream.  For vcs's that have only hash based ids there's 
really no reason to have the hash in the rpm release tag.

The need to identify how to reconstruct the srpm is still in place. 
However, instead of placing that information in the release tag, it 
should be either a comment or script in the source rpm as noted here:
 
http://fedoraproject.org/wiki/Packaging/SourceURL#head-615f6271efb394ab340a93a6cf030f2d08cf0d49

-Toshio



From buildsys at redhat.com  Thu Nov 29 15:57:14 2007
From: buildsys at redhat.com (Build System)
Date: Thu, 29 Nov 2007 10:57:14 -0500
Subject: rawhide report: 20071129 changes
Message-ID: <200711291557.lATFvE3g010336@porkchop.devel.redhat.com>

New package alienarena
	3D Deathmatch game

New package alienarena-data
	Data files for Alien Arena 2007

New package kdegames3
	K Desktop Environment - Games

New package ovaldi
	Reference implementation of the OVAL interpreter

New package tcpflow
	Network traffic recorder

New package teg
	Turn based strategy game


 
Updated Packages:

Coin2-2.5.0-3.fc9
-----------------
* Thu Nov 29 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.5.0-3
- Rebuild with doxygen-1.5.3-1 (BZ 343601).

OpenSceneGraph-2.2.0-3.fc9
--------------------------
* Wed Nov 28 2007 Ralf Cors??pius <rc040203 at freenet.de> - 2.2.0-3
- Re-add apivers.
- Rebuild against doxygen-1.5.3-1 (BZ 343591).

SoQt-1.4.1-7.fc9
----------------
* Thu Nov 29 2007 Ralf Cors??pius <rc040203 at freenet.de> - 1.4.1-7
- Rebuild against Coin-2.5.0.
- Rebuild with doxygen-1.5.3-1 (BZ 343211).

anaconda-11.4.0.3-1
-------------------
* Wed Nov 28 2007 Chris Lumens <clumens at redhat.com> 11.4.0.3-1
- Fix the build by no longer including broken kernel headers (katzj).
- Fix tracebacks when printing disk errors (#403501).
- Fix tracebacks in displaying the text mode exception dialog (#403381).

* Wed Nov 28 2007 Chris Lumens <clumens at redhat.com> 11.4.0.2-1
- Include libuser support libraries.
- Include nss libraries so rpm works again (#396851).
- Fix a traceback starting vnc mode.
- Make --excludedocs work again (#401651).
- Probe for USB on more busses (dwmw2, #401821).
- Add linear.ko to the modules available for rescue mode (#151742).
- Update implantisomd5 usage to give correct option name (#364611).
- Start removing unneeded install method code.
- Run %post scripts on upgrade (#392201).
- Correct nicdelay patch (msivak, #349521).
- Only run media check if we're installing off the CD (#362561).
- Fix display of package names in non-English text installs (#376231).
- Import isys (katzj, #390141).
- Fully handle pae kernel (katzj, #388231).
- Add initial support for encrypted block devices (dlehman).
- Strip out the wiki markup from docs (Paul Frields, #387341).
- Update Romanian keyboard layout and console font (#386751).

apr-api-docs-1.2.12-1.fc9
-------------------------
* Wed Nov 28 2007 Bojan Smojver <bojan at rexursive.com> 1.2.12-1
- Align with latest apr/apr-util

beecrypt-4.1.2-14
-----------------
* Wed Nov 28 2007 Dennis Gilmore <dennis at ausil.us> - 4.1.2-14
- add patch so sparc64 gets lib64

blam-1.8.3-13.fc9
-----------------
* Tue Nov 27 2007 Martin Stransky <stransky at redhat.com> - 1.8.3-13
- rebuild agains XUL Runner (gecko-libs 1.9)

* Tue Nov 27 2007 Christopher Aillon <caillon at redhat.com> - 1.8.3-12
- Rebuild against newer gecko

boolstuff-0.1.11-3.fc9
----------------------
* Wed Nov 28 2007 Patrice Dumas <pertusus at free.fr> 0.1.11-3
- rebuild for newer doxygen that creates reproducible anchors
centerim-1:4.22.1.20071124-2.fc9
--------------------------------
* Wed Nov 28 2007 Lubomir Kundrak <lkundrak at redhat.com> - 1:4.22.1.20071124-2
- Synchronized with GIT to fix the ICQ client side contacts problems (#402301)

doxygen-1:1.5.4-1.fc9
---------------------
* Wed Nov 28 2007 Than Ngo <than at redhat.com> 1.5.4-1
- 1.5.4

eclipse-rpm-editor-0.2.0-2.fc9
------------------------------
* Wed Nov 28 2007 fons <fons at xp2000.leafamily.org> 0.2.0-2
- Add support for URPM tool and cancel support to RpmPackageBuildProposalsJob. 
- Fix Bug #207207

fdupes-1.40-10.fc9
------------------

galeon-2.0.3-16.fc9
-------------------
* Wed Nov 28 2007 Denis Leroy <denis at poolshark.org> - 2.0.3-16
- Rebuild with gecko 1.8.1.10

ghostscript-8.61-3.fc9
----------------------
* Wed Nov 28 2007 Tim Waugh <twaugh at redhat.com> 8.61-3
- No longer need runlibfileifexists.
- Use runlibfile in cidfmap.

* Wed Nov 28 2007 Tim Waugh <twaugh at redhat.com> 8.61-2
- Add /usr/share/fonts to fontpath (bug #402551).
- Restore cidfmap-switching bits, except for FAPIcidfmap which is no
  longer used.
- Add runlibfileifexists to gs_init.ps.
- Build with --disable-compile-inits (bug #402501).

* Fri Nov 23 2007 Tim Waugh <twaugh at redhat.com> 8.61-1
- 8.61.

gimp-2:2.4.2-2.fc9
------------------
* Wed Nov 28 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.2-2
- fix typo to build internal print plugin from F8 onwards (#401931)

* Thu Nov 22 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.2-1
- version 2.4.2

  Changes in GIMP 2.4.2
  =====================

  - removed broken and useless HSV Graph script (bug #491311)
  - update the histogram when a color correction tool is cancelled (bug #493639)
  - fixed a crash with certain plug-in or script descriptions (bug #492718)
  - corrected a tooltip (bug #495564)
  - fixed a crash when GIMP is run without any modules (bug #495863)
  - fixed error handling in the TIFF plug-in
  - fixed a problem with Sample points
  - fixed a crash when merging layers in indexed image (bug #495990)
  - update the histogram when painting (bug #494049)
  - fixed another problem with merge operations on indexed images (bug #496437)
  - fixed crash in TIFF plug-in when saving indexed images (bug #497103)
  - changed defaults so that a system monitor profile is only used when the
    user explicitely enabled this feature (bug #496890)
  - fixed endless loop when running equalize on transparent areas (bug #497291)
  - fixed heap corruption in GimpColorScale widget that caused a crash in the
    Compose plug-in (bug #399484)
  - fixed use of background color in Particle Trace script (bug #498282)
  - set the image menu insensitive when there's no image opened (bug #498511)
  - translation updates (ca, et, it, lt, pt, pt_BR, sr, sv)

* Wed Oct 31 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.1-1
- version 2.4.1

  Changes in GIMP 2.4.1
  =====================

  - fixed a minor display rendering problem
  - improved the workaround for broken graphics card drivers (bug #421466)
  - fixed a crash with broken scripts and plug-ins (bug #490055)
  - fixed potential syntax error in configure script (bug #490068)
  - fixed parsing of floating point numbers in Script-Fu (bug #490198)
  - fixed potential crash when converting an indexed image to RGB (bug #490048)
  - update the histogram while doing color corrections (bug #490182)
  - fixed another crash with broken plug-ins (bug #490617).
  - translation updates

gnome-web-photo-0.3-8.fc9
-------------------------
* Tue Nov 27 2007 Christopher Aillon <caillon at redhat.com> - 0.3-8
- Rebuild against newer gecko

grsync-0.6.1-1.fc9
------------------
* Wed Nov 28 2007 Sebastian Vahl <fedora at deadbabylon.de> - 0.6.1-1
- New upstream version: 0.6.1

htdig-3:3.2.0b6-13.fc9
----------------------
* Wed Nov 28 2007 Adam Tkac <atkac redhat com> 3:3.2.0b6-13
- CVE-2007-6110

hunspell-da-1.7.17-1.fc9
------------------------
* Wed Nov 28 2007 Caolan McNamara <caolanm at redhat.com> - 1.7.17-1
- latest version

icu-3.8-4.fc9
-------------
* Wed Nov 28 2007 Caolan McNamara <caolanm at redhat.com> - 3.8-4
- Resolves: ooo#83991 Malayalam "Kartika" font fix

imlib-1:1.9.15-5.fc9
--------------------
* Wed Nov 28 2007 Adam Jackson <ajax at redhat.com> 1:1.9.15-5
- imlib-1.9.15-check-for-shm-pixmaps.patch: MIT-SHM pixmaps are optional,
  so check that they exist before using them. (#357241)

jd-1.9.8-0.1.svn1558.fc9
------------------------
* Wed Nov 28 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.8-0.1.svn1558
- svn 1558

* Thu Nov 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-1
- 1.9.7

* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

jwhois-4.0-5.fc9
----------------
* Wed Nov 28 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 4.0-5
- Merge review: add _smp_mflag, remove RPM_BUILD_ROOT test in istall
  and clean, remove Obsoletes:, fix use of % in changelog
  Resolves: #225955

* Tue Nov 20 2007 Lubomir Kundrak <lkundrak at redhat.com> - 4.0-4
- Fix connections to IPv4 servers

* Tue Oct 09 2007 Vitezslav Crhonek <vcrhonek at redhat.com> - 4.0-3
- Fix localized man pages not marked with %lang (patch by Ville
  Skytt?? <ville.skytta at iki.fi>)

kernel-2.6.24-0.55.rc3.git3.fc9
-------------------------------
* Thu Nov 29 2007 Dave Airlie <airlied at linux.ie>
- update drm-mm-git.patch to fix 64-bit truncation

* Thu Nov 29 2007 Dave Airlie <airlied at linux.ie>
- update drm-mm-git.patch to enable sysfs udev device creation (#401961)

* Wed Nov 28 2007 Kyle McMartin <kmcmartin at redhat.com>
- Update linux-2.6-debug-acpi-os-write-port.patch for changes to
  drivers/acpi/osl.c

libvoikko-1.6-0.3.rc3.fc9
-------------------------
* Wed Nov 28 2007 - Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> 1.6-0.3.rc3
- Upstream released a new release candidate

* Wed Nov 28 2007 - Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> 1.6-0.2.rc2
- Upstream released a new release candidate

libwvstreams-4.4.1-2.fc9
------------------------
* Wed Nov 28 2007 Ondrej Vasik <ovasik at redhat.com> - 4.4.1-2
- no use of obsolete sa_restorer(#402531- by Oliver Falk)

* Mon Oct 22 2007 Ondrej Vasik <ovasik at redhat.com> - 4.4.1-1
- version 4.4.1

mail-notification-5.0-0.1.rc1.fc9
---------------------------------
* Wed Nov 28 2007 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 5.0-0.1.rc1
- Update to 5.0-rc1
- drop patches now upstream
- update gconf scripts

nut-2.2.0-6.fc9
---------------
* Wed Nov 28 2007 Tomas Smetana <tsmetana at redhat.com> 2.2.0-6
- fix forgotten bug in init script
- do not hardcode the uucp group in udev patch

* Tue Nov 27 2007 Tomas Smetana <tsmetana at redhat.com> 2.2.0-5
- fix udev rules and hal information files
- fix init script

* Wed Sep 19 2007 Tomas Smetana <tsmetana at redhat.com> 2.2.0-4
- fix manpages encodings
- run ldconfig after client (un)install
- fix HAL support

octave-6:2.9.17-1.fc9
---------------------
* Wed Nov 28 2007 Quentin Spencer <qspencer at users.sf.net> 2.9.17-1
- Update to 2.9.17 and update octave_api.

openbabel-2.1.1-2.fc9
---------------------
* Wed Nov 28 2007 Dominik Mierzejewski <rpm at greysector.net> 2.1.1-2
- build against external inchi

paman-0.9.4-1.fc9
-----------------
* Wed Nov 28 2007 Julian Sikorski <belegdol[at]gmail[dot]com> 0.9.4-1
- Update to 0.9.4
- Adjust License tag

paprefs-0.9.6-1.fc9
-------------------
* Wed Nov 28 2007 Julian Sikorski <belegdol[at]gmail[dot]com> 0.9.6-1
- Update to 0.9.6

pavucontrol-0.9.5-1.fc9
-----------------------
* Wed Nov 28 2007 Julian Sikorski <belegdol[at]gmail[dot]com> 0.9.5-1
- Update to 0.9.5

pavumeter-0.9.3-1.fc9
---------------------
* Wed Nov 28 2007 Julian Sikorski <belegdol[at]gmail[dot]com> 0.9.3-1
- Update to 0.9.3
- Adjust License tag

perl-Alien-wxWidgets-0.32-1.fc9
-------------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.32-1
- Update to 0.32

perl-AppConfig-1.66-1.fc9
-------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.66-1
- bump to 1.66

perl-CGI-Simple-1.103-2.fc9
---------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.103-2
- BR Test::More

* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 1.103-1
- bump to 1.103

perl-Cairo-1.044-1.fc9.1
------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.044-1
- 1.044

perl-Class-DBI-3.0.17-1.fc9
---------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 3.0.17-1
- bump to 3.0.17

* Fri Aug 24 2007 Tom "spot" Callaway <tcallawa at redhat.com> 3.0.16-2
- license fix

* Wed Jan 17 2007 Tom "spot" Callaway <tcallawa at redhat.com> 3.0.16-1
- bump to 3.0.16

perl-Clone-0.28-1.fc9
---------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 0.28-1
- bump to 0.28

perl-Data-Compare-0.17-1.fc9
----------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.17-1
- 0.17

perl-Devel-Cover-0.63-1.fc9
---------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.63-1
- 0.63

perl-Digest-MD4-1.5-4.fc9
-------------------------
* Wed Nov 28 2007 Paul Howarth <paul at city-fan.org> - 1.5-4
- cosmetic spec changes for new maintainer's preferences
- fix argument order for find with -depth
- add buildreqs db4-devel and gdbm-devel for alignment optimization

perl-Email-Abstract-2.134-1.fc9
-------------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.134-1
- 2.134

perl-Email-MIME-1.861-1.fc9
---------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.861-1
- bump to 1.861
perl-Email-MIME-Modifier-1.442-1.fc9
------------------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.442-1
- bump to 1.442

perl-Email-Send-2.192-1.fc9
---------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.192-1
- bump to 2.192
perl-Email-Simple-2.003-1.fc9
-----------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 2.003-1
- bump to 2.003

* Fri Mar 23 2007 Jose Pedro Oliveira <jpo at di.uminho.pt> - 1.999-1
- Update to 1.999.

* Sat Feb 10 2007 Jose Pedro Oliveira <jpo at di.uminho.pt> - 1.998-1
- Update to 1.998.

perl-Email-Simple-Creator-1.423-1.fc9
-------------------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 1.423-1
- 1.423

perl-IO-Socket-SSL-1.12-2.fc9
-----------------------------
* Wed Nov 28 2007 Paul Howarth <paul at city-fan.org> - 1.12-2
- Cosmetic spec changes suiting new maintainer's preferences

perl-Net-SSLeay-1.32-1.fc9
--------------------------
* Wed Nov 28 2007 Paul Howarth <paul at city-fan.org> - 1.32-1
- update to 1.32, incorporate new upstream URLs
- cosmetic spec changes suiting new maintainer's preferences
- fix argument order for find with -depth
- remove patch for CVE-2005-0106, fixed upstream in 1.30 (#191351)
  (http://rt.cpan.org/Public/Bug/Display.html?id=19218)
- remove test patch, no longer needed
- re-encode Credits as UTF-8
- include TODO as %doc
- add buildreqs perl(Array::Compare), perl(MIME::Base64), perl(Sub::Uplevel),
  perl(Test::Exception), perl(Test::NoWarnings), perl(Test::Pod),
  perl(Test::Warn), perl(Tree::DAG_Node)
- add patch needed to disable testsuite non-interactively
- run test suite but disable external tests by default; external tests can be
  enabled by using rpmbuild --with externaltests
- add patch to change hosts connected to in external tests

perl-Spreadsheet-WriteExcel-2.20-1.fc9
--------------------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2.20-1
- 2.20

perl-Wx-0.80-1.fc9
------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> - 0.80-1
- bump to 0.80

perl-version-2:0.74-1.fc9
-------------------------
* Wed Nov 28 2007 Tom "spot" Callaway <tcallawa at redhat.com> 2:0.74-1
- hate, hate, hate perl numbering. Bumping to 0.74, epoch to 2.

postfix-2:2.4.6-1.fc9
---------------------
* Wed Nov 28 2007 Thomas Woerner <twoerner at redhat.com> 2:2.4.6-1
- new verison 2.4.6
- added virtual server(smtp) provide (rhbz#380631)
- enabling IPv6 support (rhbz#197105)
- made the MYSQL and PGSQL defines overloadable as build argument

python-telepathy-0.14.0-3.fc9
-----------------------------
* Wed Nov 28 2007 Mat??j Cepl <mcepl at redhat.com> 0.14.0-3
- Add examples/README missing from the upstream tarball (examples doesn't
  make much sense without that).
- Fix bloody TABs into spaces so that rpmlint is silent.

reciteword-0.8.4-2.fc9
----------------------
* Thu Nov 29 2007 Hu Zheng <zhu at redhat.com> - 0.8.4-2
- Update to upstream.

rhythmbox-0.11.3-6.fc9
----------------------
* Thu Nov 29 2007 - Bastien Nocera <bnocera at redhat.com> - 0.11.3-6
- Remove stupid return that caused Podcasts never to be updated
  (see http://bugzilla.gnome.org/show_bug.cgi?id=500325)

scim-python-0.1.5-2.fc9
-----------------------
* Thu Nov 29 2007 Huang Peng <shawn.p.huang at gmail.com> - 0.1.5-2
- Add python-enchant in BuildRequires to fix build error.

* Thu Nov 29 2007 Huang Peng <shawn.p.huang at gmail.com> - 0.1.5-1
- Update to 0.1.5.

selinux-policy-3.1.2-2.fc9
--------------------------
* Wed Nov 28 2007 Dan Walsh <dwalsh at redhat.com> 3.1.2-2
- Remove user specific crond_t

setools-3.3.2-1.fc9
-------------------
* Wed Nov 28 2007 Chris Pebenito <cpebenito at tresys.com> 3.3.2-1.fc9
- Update for 3.3.2.

subcommander-1.2.2-8.fc9
------------------------
* Wed Nov 28 2007 Jochen Schmitt <Jochen herr-schmitt de> 1.2.2-8
- Fix build issues on rawhide (#399621)

* Mon Nov 26 2007 Jochen Schmitt <Jochen herr-schmitt de> 1.2.2-8
- Setting QTDIR (#399621)

tiquit-2.5-1.fc9
----------------
* Wed Nov 28 2007 Jon Ciesla <limb at jcomserv.net> - 2.5-1
- New upstream, fixes missing field bug.

vala-0.1.5-1.fc9
----------------
* Tue Nov 27 2007 Michel Salim <michel.sylvan at gmail.com> - 0.1.5-1
- Update to 0.1.5

xmlto-0.0.19-1.fc9
------------------
* Wed Nov 28 2007 Ondrej Vasik <ovasik at redhat.com> - 0.0.19-1
- new version 0.0.19
- added dist tag

xorg-x11-drv-radeonhd-0.0.4-0.2.20071129git.fc9
-----------------------------------------------
* Thu Nov 29 2007 Hans Ulrich Niedermann <hun at n-dimensional.de> - 0.0.4-0.2.20071129git
- New snapshot (upstream commit 8b1b8bfb21d2d86780cb4e02abc813578daa24bd):
  - RandR 1.2 support with hotplugging of monitors.
  - R600 LVDS: RS690M, M72, M74 and M76 devices.
  - Fixed "white screen" bug.
  - Numerous fixes and new support for features.
- Preserve source file timestamps where possible.

xorg-x11-server-utils-7.3-2.fc9
-------------------------------
* Thu Nov 29 2007 Dave Airlie <airlied at redhat.com> 7.3-2
- xrandr-1.2.2-reset-other-outputs-using-best-crtc.patch
- xrandr-1.2.2-verify-crtc-against-prev-config.patch
- Patches from upstream to fix some bug in xrandr app

yaboot-1.3.13-8.fc9
-------------------
* Wed Nov 28 2007 David Woodhouse <dwmw2 at redhat.com> - 1.3.13-8
- Correct default config file location on Efika
- Disable new USB bindings in efika.forth for now

yum-3.2.7-2.fc9
---------------
* Wed Nov 28 2007 Seth Vidal <skvidal at fedoraproject.org> - 3.2.7-2
- fix for lots of output in transaction hanging the transaction

* Fri Oct 12 2007 Seth Vidal <skvidal at fedoraproject.org> - 3.2.7-1
- 3.2.7
- remove all merged patches

* Thu Oct 11 2007 Jeremy Katz <katzj at redhat.com> - 3.2.6-5
- fix corner case obsoletes depsolving bug

Broken deps for i386
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.i386 requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	bmpx-extension - 0.40.13-4.fc9.i386 requires firefox = 0:2.0.0.9
	epiphany - 2.20.1-5.fc9.i386 requires gecko-libs = 0:1.8.1.9
	epiphany-devel - 2.20.1-5.fc9.i386 requires gecko-devel = 0:1.8.1.9
	epiphany-extensions - 2.20.1-2.fc9.i386 requires gecko-libs = 0:1.8.1.9
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8
	kmod-em8300-PAE - 0.16.3-6.2.6.23.1_42.fc8.i686 requires kernel-i686 = 0:2.6.23.1-42.fc8PAE
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8
	kmod-sysprof-PAE - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.i686 requires kernel-i686 = 0:2.6.23-0.142.rc3.git10.fc8PAE
	liferea - 1.4.8-1.fc9.i386 requires gecko-libs = 0:1.8.1.9
	octave-forge - 20071014-3.fc9.i386 requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.i386 requires perl(Wx::Wx_Exp)
	plplot-octave - 5.8.0-1.fc9.i386 requires octave(api) = 0:api-v28
	ruby-gtkmozembed - 0.16.0-16.fc9.i386 requires gecko-libs = 0:1.8.1.9



Broken deps for x86_64
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	bmpx-extension - 0.40.13-4.fc9.x86_64 requires firefox = 0:2.0.0.9
	epiphany - 2.20.1-5.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	epiphany-devel - 2.20.1-5.fc9.x86_64 requires gecko-devel = 0:1.8.1.9
	epiphany-devel - 2.20.1-5.fc9.i386 requires gecko-devel = 0:1.8.1.9
	epiphany-extensions - 2.20.1-2.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23.1-42.fc8
	kmod-sysprof - 1.0.8-1.2.6.23_0.142.rc3.git10.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.142.rc3.git10.fc8
	liferea - 1.4.8-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	octave-forge - 20071014-3.fc9.x86_64 requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.x86_64 requires perl(Wx::Wx_Exp)
	plplot-octave - 5.8.0-1.fc9.x86_64 requires octave(api) = 0:api-v28
	ruby-gtkmozembed - 0.16.0-16.fc9.x86_64 requires gecko-libs = 0:1.8.1.9



Broken deps for ppc
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.ppc requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	bmpx-extension - 0.40.13-4.fc9.ppc requires firefox = 0:2.0.0.9
	epiphany - 2.20.1-5.fc9.ppc requires gecko-libs = 0:1.8.1.9
	epiphany-devel - 2.20.1-5.fc9.ppc64 requires gecko-devel = 0:1.8.1.9
	epiphany-devel - 2.20.1-5.fc9.ppc requires gecko-devel = 0:1.8.1.9
	epiphany-extensions - 2.20.1-2.fc9.ppc requires gecko-libs = 0:1.8.1.9
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8
	kmod-em8300-smp - 0.16.3-6.2.6.23.1_42.fc8.ppc requires kernel-ppc = 0:2.6.23.1-42.fc8smp
	liferea - 1.4.8-1.fc9.ppc requires gecko-libs = 0:1.8.1.9
	monodevelop - 0.17-4.fc9.ppc requires boo
	octave-forge - 20071014-3.fc9.ppc requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.ppc requires perl(Wx::Wx_Exp)
	plplot-octave - 5.8.0-1.fc9.ppc requires octave(api) = 0:api-v28
	ruby-gtkmozembed - 0.16.0-16.fc9.ppc requires gecko-libs = 0:1.8.1.9



Broken deps for ppc64
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	bmpx-extension - 0.40.13-4.fc9.ppc64 requires firefox = 0:2.0.0.9
	epiphany - 2.20.1-5.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	epiphany-devel - 2.20.1-5.fc9.ppc64 requires gecko-devel = 0:1.8.1.9
	epiphany-extensions - 2.20.1-2.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	kmod-em8300 - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8
	kmod-em8300-kdump - 0.16.3-6.2.6.23.1_42.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23.1-42.fc8kdump
	liferea - 1.4.8-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	octave-forge - 20071014-3.fc9.ppc64 requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.ppc64 requires perl(Wx::Wx_Exp)
	plplot-octave - 5.8.0-1.fc9.ppc64 requires octave(api) = 0:api-v28
	ruby-gtkmozembed - 0.16.0-16.fc9.ppc64 requires gecko-libs = 0:1.8.1.9





From debarshi.ray at gmail.com  Thu Nov 29 16:03:44 2007
From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray)
Date: Thu, 29 Nov 2007 21:33:44 +0530
Subject: rawhide report: 20071129 changes
In-Reply-To: <200711291557.lATFvE3g010336@porkchop.devel.redhat.com>
References: <200711291557.lATFvE3g010336@porkchop.devel.redhat.com>
Message-ID: <3170f42f0711290803g73c53b05gff482c4c81a57502@mail.gmail.com>

> fdupes-1.40-10.fc9
> ------------------

Where did the %changelog entry go? I did have:

* Thu Nov 29 2007 Debarshi Ray <rishi at fedoraproject.org> - 1.40-10
- Release bumped to overcome spurious build.

* Sun Nov 25 2007 Debarshi Ray <rishi at fedoraproject.org> - 1.40-9
- Initial build. Imported SPEC from Rawhide.
- Fixed Makefile to use DESTDIR correctly.
- Fixed sources to include string.h.

Cheers,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu



From a.badger at gmail.com  Thu Nov 29 16:22:56 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Nov 2007 08:22:56 -0800
Subject: Maintainers Responsibility (was alpha/beta software in Fedora 8)
In-Reply-To: <1196337133.3227.49.camel@cookie.hadess.net>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>
	<474D0BCC.5010800@redhat.com>	<1196263849.10086.2.camel@nixon>	<1196265089.29968.2.camel@localhost6.localdomain6>	<1196267471.2889.6.camel@localhost.localdomain>	<1196325783.13689.12.camel@wombat.tiptoe.de>
	<1196337133.3227.49.camel@cookie.hadess.net>
Message-ID: <474EE760.80701@gmail.com>

Bastien Nocera wrote:
> On Thu, 2007-11-29 at 09:43 +0100, Nils Philippsen wrote:
>> On Wed, 2007-11-28 at 11:31 -0500, Matthias Clasen wrote:
>>
>>> The importance of individual packages is pretty dependent on the use
>>> case. For most users of a Fedora desktop, it is probably far more
>>> disastrous if the email client or web browser crashes, than if some dns
>>> server the haven't installed has some bugs.
>> This assumes that Fedora is "just" a desktop, while it is much more --
>> the desktop is "just" a part of it. A significant one, surely, but a
>> part. From my POV, Adam was okay to put in that version of bind because
>> he tested it and found no problems, and most definitely not because the
>> bind package is somehow less important than say the gnome-panel.
> 
> Read Matthias' reply again. He made no such assumption, you did: "For
> most users of a Fedora desktop [...]"
> 
It really depends... If DNS crashes and Fedora is the DNS server for 
your subnet your end users might not be able to get to any network sites 
whereas if your email client crashes, well at least you have a browser 
for web mail.

On the flip side, If DNS has a few bugs that only hit in obscure cases, 
how is that any more or less disastrous than if evolution only has a few 
bugs that only hit in obscure cases?

So my real issue is with the naivete of the post Matthias was replying 
to -- trying to judge importance of a bug based on whether the app is 
for the "desktop" vs "server" is a false dichotomy.  You have to judge 
based on what happens when the bug occurs, how it is provoked, how many 
users (rather than computers) are affected when the bug occurs, etc. 
"desktop" and "server" might help you determine these answers but it 
isn't an answer in and of itself.

-Toshio



From bnocera at redhat.com  Thu Nov 29 16:24:31 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 29 Nov 2007 16:24:31 +0000
Subject: gnokii breakage
Message-ID: <1196353471.3227.67.camel@cookie.hadess.net>

Heya,

gnokii breakage ahead in F8 and rawhide. I uploaded 0.6.22 which fixes a
number of crashes and related bugs compared to the versions we were
using.

Cheers



From pbrobinson at gmail.com  Thu Nov 29 16:28:49 2007
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 29 Nov 2007 16:28:49 +0000
Subject: gnokii breakage
In-Reply-To: <1196353471.3227.67.camel@cookie.hadess.net>
References: <1196353471.3227.67.camel@cookie.hadess.net>
Message-ID: <5256d0b0711290828x2a05a296g4a3ba718cfdc177e@mail.gmail.com>

> Heya,
>
> gnokii breakage ahead in F8 and rawhide. I uploaded 0.6.22 which fixes a
> number of crashes and related bugs compared to the versions we were
> using.

Does that fix the hard lockup that i was seeing when using
gnome-phone-manager 0.40 with my Nokia? I was finding after the update
from 0.30 it just completely locked up what seemed like the machine
(couldn't switch to VT or ctrl+alt+bkspc X). No unfortunately I never
got around to logging a bug as I sort of just stopped using it as it
was toasting my phone battery too.

Peter



From markg85 at gmail.com  Thu Nov 29 18:49:33 2007
From: markg85 at gmail.com (Mark)
Date: Thu, 29 Nov 2007 19:49:33 +0100
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196339874.19501.26.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<ufahcj6vrpb.fsf@epithumia.math.uh.edu> <474D0BCC.5010800@redhat.com>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com> <474D7F0B.6060207@redhat.com>
	<r0d225x3p6.ln2@hubmaier.ceplovi.cz> <474E9095.7000209@redhat.com>
	<f4j225x3p6.ln2@hubmaier.ceplovi.cz>
	<1196339874.19501.26.camel@localhost.localdomain>
Message-ID: <6e24a8e80711291049h6ac89877qffec51d4c46cc4a0@mail.gmail.com>

It seems to get a redhat hangout here ^_^

About this stuff here.. about 50(?) posts ago someone of redhad said
that it's not appropriate for a stable tree to include (possible)
unstable alhpa/beta/rc software.

Can't we just let it with that..
Don't make it a policy! just a suggested guideline?

Also its said that a maintainer is free in his choice to include such
software. that is a lot of power for a maintainer (?) which is fine
with me but in the case of pushing up software that isn't in final and
could be vital for fedora it might be handy that a redhat person looks
at it before pushing it up.



From mls at suse.de  Thu Nov 29 19:14:42 2007
From: mls at suse.de (Michael Schroeder)
Date: Thu, 29 Nov 2007 20:14:42 +0100
Subject: [Rpm-metadata] createrepo 0.4.11
In-Reply-To: <20071129150332.GA10862@dudweiler.stuttgart.redhat.com>
References: <1196146117.15420.81.camel@cutter>
	<20071128132520.GA10754@dudweiler.stuttgart.redhat.com>
	<1196257161.15420.188.camel@cutter>
	<20071128135447.GA11876@dudweiler.stuttgart.redhat.com>
	<1196258229.15420.196.camel@cutter>
	<20071129150332.GA10862@dudweiler.stuttgart.redhat.com>
Message-ID: <20071129191442.GA10200@suse.de>

On Thu, Nov 29, 2007 at 04:03:32PM +0100, Florian La Roche wrote:
> On Wed, Nov 28, 2007 at 08:57:09AM -0500, seth vidal wrote:
> > Again, how does the predictability of order the filelists and deps/reqs
> > are put into the metadata impact the functionality?

> This is about stability of the data. Currently you cannot easily
> run createrepo and quickly check the output against the existing data.

Another thing that speaks for sorting is that an xdelta between two
versions would be smaller (for compressed files you need
'gzip --rsyncable'). Makes rsyncing to mirrors a bit faster.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From buildsys at fedoraproject.org  Thu Nov 29 19:32:58 2007
From: buildsys at fedoraproject.org (buildsys at fedoraproject.org)
Date: Thu, 29 Nov 2007 14:32:58 -0500 (EST)
Subject: Fedora Extras Package Build Report 2007-11-29
Message-ID: <20071129193258.E6B1D15212D@buildsys.fedoraproject.org>


Packages built and released for Fedora Extras 6: 6

    asylum-0.2.3-2.fc6
    centerim-20071003-3.fc6.1
    gcin-1.3.7.1-1.fc6
(!) gpgme-1.1.4-1.fc6 : INVALID rebuild, not published!
    hyperestraier-1.4.12-1.fc6
    imlib-1.9.15-5.fc6


Changes in Fedora Extras 6: 


asylum-0.2.3-2.fc6
------------------
* Tue Nov 27 2007 Ian Chapman <packages[AT]amiga-hardware.com> 0.2.3-2
- Enable ppc/ppc64 build. Endian issues seem resolved (BZ 319541)

centerim-20071003-3.fc6.1
-------------------------
* Wed Nov 28 2007 Lubomir Kundrak <lkundrak at redhat.com> - 20071003-3.1
- Attempt to fix problems with states of server-side contacts (#402301)

* Tue Oct 23 2007 Lubomir Kundrak <lkundrak at redhat.com> - 20071003-3
- Thanks to St?phane Bisinger, MSN works

gcin-1.3.7.1-1.fc6
------------------
* Thu Nov 29 2007 Chung-Yen Chang <candyz0416 at gmail.com> - 1.3.7.1-1
- update license field to LGPLv2
- add im-chooser to require
- update to 1.3.7.1

gpgme-1.1.4-1.fc6
-----------------
* Mon Mar 05 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.1.4-1
- gpgme-1.1.4

hyperestraier-1.4.12-1.fc6
--------------------------
* Thu Nov 29 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.12-1
- 1.4.12

imlib-1.9.15-5.fc6
------------------
* Wed Nov 28 2007 Adam Jackson <ajax at redhat.com> 1:1.9.15-5
- imlib-1.9.15-check-for-shm-pixmaps.patch: MIT-SHM pixmaps are optional,
  so check that they exist before using them. (#357241)

* Thu Aug 09 2007 Paul Howarth <paul at city-fan.org> 1:1.9.15-4
- re-clarify license as GNU Lesser General Public License v2 or later (LGPLv2+)

* Wed Aug 08 2007 Paul Howarth <paul at city-fan.org> 1:1.9.15-3
- redesign of enlightenment.org website removed imlib page, so URL changed
  to enlightenment.sourceforge.net where the original website lived (#251278)
- clarify license as GNU Lesser General Public License v2 or later (LGPL+)



From a.badger at gmail.com  Thu Nov 29 19:49:35 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Nov 2007 11:49:35 -0800
Subject: repoview + PackageDB (was Re: rawhide report: 20071127 changes)
In-Reply-To: <c263zl6bbz.fsf_-_@allele2.eebweb.arizona.edu>
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>	<1196242726.7360.0.camel@asmodeus.localdomain>	<474DA5D7.6010700@gmail.com>
	<c263zl6bbz.fsf_-_@allele2.eebweb.arizona.edu>
Message-ID: <474F17CF.7000104@gmail.com>

Alex Lancaster wrote:
>>>>>> "TK" == Toshio Kuratomi  writes:
> 
> TK> Patrick Ohearn wrote:
>>> On Tue, 2007-11-27 at 23:28 -0500, Build System wrote:
>>> New package R-rlecuyer
>>>> R interface to RNG with multiple streams
>>>>
>>> Is there a web interface for checking different versions in
>>> different repos, say like packages.gentoo.org and
>>> packages.debian.org?
>>>
> TK> You're looking for repoview:
> 
> TK> http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/i386/os/repoview/
> 
> Unfortunately repoview shows only a fraction of the information that
> packages.debian.org and doesn't unify them nearly as well as
> packages.debian.org does.
> 
Most of the packages.debian.org information lives in the repodata, 
though.  So displaying the information in repoview seems like the 
logical thing to do.

Things that repoview can't do:
   * Create the links between repositories (present in x86_64, x86, but 
not ppc)
   * List the maintainer
   * search

Everything else on packages.debian.org looks like it could  be done from 
repoview.

> I think that PackageDB should ultimately become the equivalent kind of
> "portal", because we have a proliferation of sites where various
> package information is kept (bodhi, packagedb, koji, repoview) and it
> would be nice to tie them in all together into a single package
> "portal" the way Debian/Ubuntu does with all information about the
> package in one location and fold the repoview stuff into it. You could
> still keep the koji, bodhi web interfaces as they are, but have
> PackageDB querying them and displaying all the latest information in
> one place for each package.  PackageDB has started this with the new
> bugzilla interface, which is nice.
> 
I go back and forth on just what the packagedb should be providing. 
repoview has two advantages over the packagedb:

1) repoview is nice because it is static data.  Therefore it is 
lightweight to operate and canbe distributed to our mirrors.

2) repoview is updated when the repositories are updated from the 
databases in the repository.  Therefore it is just an extension of the 
canonical data about what packages a user is going to be using.  This is 
especially important when thinking about subpackages, which the 
packagedb doesn't know about.

OTOH, some things need to operate dynamically (search and ratings, for 
instance) and some things are not present in the repo information 
(maintainers, bodhi ratings, scratch builds, etc).

The ideal situation for the packagedb is to let repoview handle the 
things its good at as much as possible while doing the things that 
repoview can't do easily.  For the end user, the ideal is to have a 
seamless experience so they see themselves navigating amongst different 
places on the Fedora Site rather than different sites within Fedora. 
Figuring out how to balance these two is what makes the situation 
interesting.

> I have some notes on this here:
> 
> https://hosted.fedoraproject.org/projects/packagedb/ticket/79#comment:1
> 
Yep -- anyone else interested in this, please join in -- I can help get 
someone set up with a test instance if there are coders interested in 
adding this information.

-Toshio



From notting at redhat.com  Thu Nov 29 20:29:59 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 29 Nov 2007 15:29:59 -0500
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in
	Fedora 8?]
In-Reply-To: <474DD09B.8040907@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com> <fijuhr$20o$1@ger.gmane.org>
	<200711281133.19824.sgrubb@redhat.com>
	<474DD09B.8040907@redhat.com>
Message-ID: <20071129202959.GA9414@nostromo.devel.redhat.com>

Petr Machata (pmachata at redhat.com) said: 
> Steve Grubb wrote:
> > kdepim-enterprise-svn20070926.tar.bz2
> 
> As a side note, I always wondered why to use date in the release tag of
> package, whose sources come from non-cvs versioning system.  For svn, in
> my opinion, it would make more sense to use the tree revision number;
> for git, similarly, sha1 id of the tree.

Well, git<date> sorts sanely. git<sha1> does not. Comments in the spec
(or similar) might help with this.

Bill



From andrewparker at bigfoot.com  Thu Nov 29 21:11:17 2007
From: andrewparker at bigfoot.com (Andrew Parker)
Date: Thu, 29 Nov 2007 16:11:17 -0500
Subject: Support TV on Fedora - Proposal for Fedora 9
In-Reply-To: <474E52D0.3010104@leemhuis.info>
References: <385453.83318.qm@web52410.mail.re2.yahoo.com>
	<1196196769.3414.6.camel@ignacio.lan>
	<e1760170711271406m6372066kff31d78d76d46c08@mail.gmail.com>
	<6c3f5e6c0711271433p2cd98c32q2104a82fe2255615@mail.gmail.com>
	<1196234293.8588.0.camel@rousalka.dyndns.org>
	<6c3f5e6c0711281403v36a07f2dga0d48072a0c460be@mail.gmail.com>
	<474E52D0.3010104@leemhuis.info>
Message-ID: <6c3f5e6c0711291311h1db54ffbqec4c36efd76ac2f8@mail.gmail.com>

On Nov 29, 2007 12:49 AM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 28.11.2007 23:03, Andrew Parker wrote:
> > On Nov 28, 2007 2:18 AM, Nicolas Mailhot
> > <nicolas.mailhot at laposte.net> wrote:
> >> Le mardi 27 novembre 2007 ? 17:33 -0500, Andrew Parker a ?crit :
> >>> On Nov 27, 2007 5:06 PM, KH KH <kwizart at gmail.com> wrote:
> >>>> ivtv-firmware and xorg-x11-drv-ivtv have been approved but
> >>>> still were not imported because of "competing" review
> >>>> request... (my website is offline for the next 24hours)
> >>> I don't think that's quite true.  The driver is now part of the
> >>> kernel, but you still need to install the firmware and the
> >>> userland tools such as ivtvctl.
> >> Read again the last bit of Nicolas's post.
> > Eh?  Your other post?  I don't see what you're referring to.
>
> KH KH is also a "Nicolas's", so he afaics referred to:

ah yes, of course.

>
> >>>> ivtv-firmware and xorg-x11-drv-ivtv have been approved but
> >>>> still were not imported because of "competing" review
> >>>> request... (my website is offline for the next 24hours)
>
> HTH
>
> > If you check the livna repo, they provide both the firware and the
> > userland tools (which is just a partial build of the IVTV download
> > for kernels >= 2.6.22)
>
> That would be news to me and I likely would know ;-)
>
> But Atrpms ships it afaik.

indeed, atrpms is what i was thinking of, my mistake.



From alexl at users.sourceforge.net  Thu Nov 29 22:09:00 2007
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Thu, 29 Nov 2007 15:09:00 -0700
Subject: repoview + PackageDB
In-Reply-To: <474F17CF.7000104@gmail.com> (Toshio Kuratomi's message of "Thu\,
	29 Nov 2007 11\:49\:35 -0800")
References: <200711280428.lAS4SEUM015370@porkchop.devel.redhat.com>
	<1196242726.7360.0.camel@asmodeus.localdomain>
	<474DA5D7.6010700@gmail.com>
	<c263zl6bbz.fsf_-_@allele2.eebweb.arizona.edu>
	<474F17CF.7000104@gmail.com>
Message-ID: <rgd4ts4scj.fsf@allele2.eebweb.arizona.edu>

>>>>> "TK" == Toshio Kuratomi  writes:

[...]

TK> Most of the packages.debian.org information lives in the repodata,
TK> though.  So displaying the information in repoview seems like the
TK> logical thing to do.

TK> Things that repoview can't do: * Create the links between
TK> repositories (present in x86_64, x86, but not ppc) * List the
TK> maintainer * search

TK> Everything else on packages.debian.org looks like it could be done
TK> from repoview.

The problem with repoview view is that there's no way to search or
list for packages across branches, in packages.debian.org you can
search for "say" bioperl:

http://packages.debian.org/search?keywords=bioperl&searchon=names&suite=all&section=all

and get a list of the versions of packages in each branch.  Also each
package has a source page here:

http://packages.qa.debian.org/b/bioperl.html

To my mind, this could live in PackageDB with the current version
underneath each branch in:

https://admin.fedoraproject.org/pkgdb/packages/name/perl-bioperl

It would say something like:

Collection   Owner   QA Contact  Status   Current version  Testing version

Fedora devel alexlan             Approved 1.5.2_102-8.fc7  N/A

Another thing missing from repoview is the list of dependent packages,
see, e.g.,

http://packages.debian.org/stable/science/bioperl

[...]

TK> I go back and forth on just what the packagedb should be
TK> providing. repoview has two advantages over the packagedb:

TK> 1) repoview is nice because it is static data.  Therefore it is
TK> lightweight to operate and canbe distributed to our mirrors.

TK> 2) repoview is updated when the repositories are updated from the
TK> databases in the repository.  Therefore it is just an extension of
TK> the canonical data about what packages a user is going to be
TK> using.  This is especially important when thinking about
TK> subpackages, which the packagedb doesn't know about.

TK> OTOH, some things need to operate dynamically (search and ratings,
TK> for instance) and some things are not present in the repo
TK> information (maintainers, bodhi ratings, scratch builds, etc).

TK> The ideal situation for the packagedb is to let repoview handle
TK> the things its good at as much as possible while doing the things
TK> that repoview can't do easily.  For the end user, the ideal is to
TK> have a seamless experience so they see themselves navigating
TK> amongst different places on the Fedora Site rather than different
TK> sites within Fedora. Figuring out how to balance these two is what
TK> makes the situation interesting.

Yes, what really matters is not exactly where the data is but how it
is presented to the users, if PackageDB is a seamless experience for
both users of Fedora as well as package maintainers, then it doesn't
really matter where the data is (but it should *feel* like a single
site).

Alex



From dimi at lattica.com  Thu Nov 29 22:34:59 2007
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 29 Nov 2007 17:34:59 -0500
Subject: Bootup speed for F8
Message-ID: <1196375699.3036.9.camel@dimi.lattica.com>

Hi folks,

I've currently upgraded to F8, congrats!

Just thought of sharing a data-point for startup speed
(measured from GRUB, so excluding all the BIOS stuff):
  * to graphical init: 30s
  * to login prompt: 1m8s
  * after login, to responsive state: 14s

That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
With the BIOS thrown in, it takes over 2minutes to be able to get
into the box.

That's rather slow, no?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From ajackson at redhat.com  Thu Nov 29 23:09:40 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Thu, 29 Nov 2007 18:09:40 -0500
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <1196377780.22277.57.camel@localhost.localdomain>

On Thu, 2007-11-29 at 17:34 -0500, Dimi Paun wrote:
> Hi folks,
> 
> I've currently upgraded to F8, congrats!
> 
> Just thought of sharing a data-point for startup speed
> (measured from GRUB, so excluding all the BIOS stuff):
>   * to graphical init: 30s
>   * to login prompt: 1m8s
>   * after login, to responsive state: 14s
> 
> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> With the BIOS thrown in, it takes over 2minutes to be able to get
> into the box.
> 
> That's rather slow, no?

It is!  Have you installed bootchart to see what's taking so much time?

- ajax



From gary at mlbassoc.com  Thu Nov 29 22:40:23 2007
From: gary at mlbassoc.com (Gary Thomas)
Date: Thu, 29 Nov 2007 15:40:23 -0700
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <474F3FD7.3010607@mlbassoc.com>

Dimi Paun wrote:
> Hi folks,
> 
> I've currently upgraded to F8, congrats!
> 
> Just thought of sharing a data-point for startup speed
> (measured from GRUB, so excluding all the BIOS stuff):
>   * to graphical init: 30s
>   * to login prompt: 1m8s
>   * after login, to responsive state: 14s
> 
> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> With the BIOS thrown in, it takes over 2minutes to be able to get
> into the box.
> 
> That's rather slow, no?
> 

Try upgrading to the latest kernel and remeasure.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



From sandeen at redhat.com  Thu Nov 29 22:44:16 2007
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 29 Nov 2007 16:44:16 -0600
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <474F40C0.6050102@redhat.com>

Dimi Paun wrote:
> Hi folks,
> 
> I've currently upgraded to F8, congrats!
> 
> Just thought of sharing a data-point for startup speed
> (measured from GRUB, so excluding all the BIOS stuff):
>   * to graphical init: 30s
>   * to login prompt: 1m8s
>   * after login, to responsive state: 14s
> 
> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> With the BIOS thrown in, it takes over 2minutes to be able to get
> into the box.
> 
> That's rather slow, no?
> 

Readahead was not installed by default in F8 because it appeared to be
doing more harm than good, without careful custom configuration.  But,
you could try installing the readahead scripts, and see if it changes
things.

Or, if you already have readahead installed due to the upgrade,
chkconfig it off and see how that goes.  :)

-Eric



From lkundrak at redhat.com  Thu Nov 29 22:47:03 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Thu, 29 Nov 2007 23:47:03 +0100
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <1196376423.8889.2.camel@localhost.localdomain>


On Thu, 2007-11-29 at 17:34 -0500, Dimi Paun wrote:
> Hi folks,
> 
> I've currently upgraded to F8, congrats!
> 
> Just thought of sharing a data-point for startup speed
> (measured from GRUB, so excluding all the BIOS stuff):
>   * to graphical init: 30s
>   * to login prompt: 1m8s
>   * after login, to responsive state: 14s
> 
> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> With the BIOS thrown in, it takes over 2minutes to be able to get
> into the box.
> 
> That's rather slow, no?

You forgot to attach the patch to fix that.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From kulbirsaini at students.iiit.ac.in  Thu Nov 29 23:04:38 2007
From: kulbirsaini at students.iiit.ac.in (Kulbir Saini)
Date: Fri, 30 Nov 2007 04:34:38 +0530 (IST)
Subject: Bootup speed for F8
In-Reply-To: <474F40C0.6050102@redhat.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<474F40C0.6050102@redhat.com>
Message-ID: <Pine.LNX.4.64.0711300434100.9622@localhost.localdomain>

On Thu, 29 Nov 2007, Eric Sandeen wrote:

> Dimi Paun wrote:
>> Hi folks,
>>
>> I've currently upgraded to F8, congrats!
>>
>> Just thought of sharing a data-point for startup speed
>> (measured from GRUB, so excluding all the BIOS stuff):
>>   * to graphical init: 30s
>>   * to login prompt: 1m8s
>>   * after login, to responsive state: 14s
>>
>> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>> With the BIOS thrown in, it takes over 2minutes to be able to get
>> into the box.
>>
>> That's rather slow, no?
>>

    Try disabling service that you think you'll never use. Also don't start 
network (and yum-updatesd also) at startup and delay it by putting 
'service network start &' in /etc/rc.local. Because you can't use network 
unless you login.

    My Fedora 8 takes 50seconds from Grub to login screen (I mean time from 
pressing enter in grub screen to the time when login screen appears and i 
can login) on AMD64 3000+ (solo core) and 1GB RAM :)


-------------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Institute: http://www.iiit.ac.in/
My Linux-Blog: http://linux.saini.co.in/
My Web-Blog: http://life.saini.co.in/
-------------------------------------------------------




From bnocera at redhat.com  Fri Nov 30 01:04:12 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 30 Nov 2007 01:04:12 +0000
Subject: rpms/gnokii/F-8 gnokii.spec,1.19,1.20
In-Reply-To: <1196347155.3028.0.camel@localhost.localdomain>
References: <200711291348.lATDm2iP004168@cvs-int.fedora.redhat.com>
	<20071129142007.GA32513@serv.smile.org.ua>
	<1196347155.3028.0.camel@localhost.localdomain>
Message-ID: <1196384652.3227.129.camel@cookie.hadess.net>


On Thu, 2007-11-29 at 09:39 -0500, Matthias Clasen wrote:
> On Thu, 2007-11-29 at 16:20 +0200, Andy Shevchenko wrote:
> > Hi Bastien Nocera!
> > 
> >  On Thu, Nov 29, 2007 at 08:48:02AM -0500, Bastien Nocera wrote next:
> > 
> > > And again
> > 
> > > --- gnokii.spec	29 Nov 2007 12:50:02 -0000	1.19
> > > +++ gnokii.spec	29 Nov 2007 13:47:30 -0000	1.20
> > > @@ -138,7 +138,7 @@
> > >    xmandir=%{_mandir}/man1 docdir=/__docinst
> > >  
> > >  mv $RPM_BUILD_ROOT/__docinst .
> > > -rm __docinst/{README-MacOSX,README-WIN32,packaging-howto,ChangeLog,COPYING,COPYRIGHT,TODO,MAINTAINERS}
> > > +rm __docinst/{README-MacOSX,README-WIN32,ChangeLog,COPYING,COPYRIGHT,TODO,MAINTAINERS}
> > Why did you not use rm -f ?

I actually did in devel.

> If you use -f, the rm call will not fail, thus the cruft will likely
> stay in your spec file forever, even if it is not needed anymore.
> 
> It is a bit like using excessive wildcards in your file list...

Yep. Hopefully, I'll be able to clean this mess up with the next version
of gnokii, once it's all nicely automake-ified.

Cheers



From bnocera at redhat.com  Fri Nov 30 01:05:32 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 30 Nov 2007 01:05:32 +0000
Subject: gnokii breakage
In-Reply-To: <5256d0b0711290828x2a05a296g4a3ba718cfdc177e@mail.gmail.com>
References: <1196353471.3227.67.camel@cookie.hadess.net>
	<5256d0b0711290828x2a05a296g4a3ba718cfdc177e@mail.gmail.com>
Message-ID: <1196384732.3227.131.camel@cookie.hadess.net>


On Thu, 2007-11-29 at 16:28 +0000, Peter Robinson wrote:
> > Heya,
> >
> > gnokii breakage ahead in F8 and rawhide. I uploaded 0.6.22 which fixes a
> > number of crashes and related bugs compared to the versions we were
> > using.
> 
> Does that fix the hard lockup that i was seeing when using
> gnome-phone-manager 0.40 with my Nokia? I was finding after the update
> from 0.30 it just completely locked up what seemed like the machine
> (couldn't switch to VT or ctrl+alt+bkspc X). No unfortunately I never
> got around to logging a bug as I sort of just stopped using it as it
> was toasting my phone battery too.

Hard lockup? File a bug, that looks like your kernel is toasting as
well :)



From markg85 at gmail.com  Fri Nov 30 08:34:09 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 30 Nov 2007 09:34:09 +0100
Subject: Extreme memory usage for gnome-panel related apps
Message-ID: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com>

// begin note

i posted this in the fedora-list first but wasn't getting reply's that
are discussing what i say below. And for the memory (in the text
below).. Using it all up doesn't mean that it's used good. See it like
your a rich guy. you can spend it all at once or just go easy on it. i
would like to go for the latter one. + send to the gnome desktop devel
list

// end note


Hey,

i was just looking through the system monitor to see how my memory
usage was doing and that gave me a impressive (negative way) result.
I've made a screenshot [1] of it and edited it a little. The color
that i added in mean:

- darkred : extreme memory usage for..?? nothing?
- red : gnome-panel related things (applets mostly)
- orange : first applet UNDER one MB.

Now if you take a look at the image you see that my current gnome
session is taking up:
4.9 MB (gnome-panel)
3.5 MB (mixer_applet2)
3.0 MB (wnck-applet)
2.3 MB (nm-applet)
1.2 MB (notification-area-applet)
1.1 MB (gnome-volume-manager)
0.7 MB (bluetooth-applet)

Totals to: 17.7 MB
That is only the gnome-panel stuff with it's applets. if you are gonna
take into account the stuff that is needed to run the applets (like
python) than it will likely use a lot more but since those a can be
used with other applications as well i will leave that out of it.

Now there are still 3 more left in the list i highlighted.
1. Nautilus
Oke.. this one is bothering me. at the time that i shot the screenshot
nautilus was not open (at least not the file browser) and than it's
taking up that much memory! that's just overkill!

2. gnome-settings-daemon
Why does this need to run? what's the purpose of it? If it's just
running for other programs to grab gnome settings (wild guess) than
it's using up way to much RAM anyway. otherwise it has to go.

3. puplet
Someone said this was efficient in Fedora 8.. doesn't look like it. (8 MB).

Now the notebook i'm typing this on has 1GB om memory and runs Fedora
fine so if i look at it that way than the ram usage is fine. but keep
in mind the people with less memory (256 or 512 MB's) they are gonna
get a hard time with this fedora. My total memory usage at the time of
this writing is: 432.00 MB (with GIMP on.. if that's closed than it's
"just" 400 MB).

What i'm trying to say here is that those gnome-panel applets are
taking up way to much memory regardless of the memory you can afford
or have in your computer. It should just be as fast and small as
possible with all the needed functions. 3.5 MB for the mixer applet
(which doesn't even support pulseaudio streams and is really basic!)
is just overkill (btw it's taking up 4.6 MB now). Perhaps all those
applets need to be checked on memory usage? or a completely new
gnome-panel + applets that just take up a few MB in total (instead of
17.7). Gnome and Fedora are currently looking fine the way they are.
so perhaps it's time to stop spending time on features for a while (2
releases? till Fedora 10?) and start spending all time/money/efforts
on performance  memory usage and usability.

And again for the memory. Having much doesn't need that it needs to
use much! slow pc's with less memory should be able to run fedora
right? Simple example. imagine that a slow 500 MHz pc with 512MB
memory wants to run Fedora + compizfusion + Gimp. Now at this moment
he must drop compiz or gimp. if that panel stuff was just using normal
amounts of memory he would have been able to use all 3 (just a
example!!)

So.. is something gonna change with this memory abuse?

[1] http://img504.imageshack.us/img504/6821/screenshotsystemmonitoryh4.png



From markg85 at gmail.com  Fri Nov 30 08:58:29 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 30 Nov 2007 09:58:29 +0100
Subject: Bootup speed for F8
In-Reply-To: <Pine.LNX.4.64.0711300434100.9622@localhost.localdomain>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<474F40C0.6050102@redhat.com>
	<Pine.LNX.4.64.0711300434100.9622@localhost.localdomain>
Message-ID: <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com>

Here is my bootchart [1]. It's was with the normal fedora setup but
with apache and mysql added.

In my bootchart i see something i rather don't see.. about 7 seconds
nothing in the begin. and the overall speed seems about half of what
could be reached... so if that was optimized:

50 sec - 7 (pure nothing) = 43 seconds.
43 / 2 (it it would use the max in reads and cpu) = 21.5 seconds which
is a decent boot time.

If that's ever gonna happen (don't think so in the near future) than
you still have to add about 10 seconds in the begin (bios, grub and
kernel boot) and about another 10 seconds for gnome to be completely
loaded.

Total time at this moment:
70 seconds

If it was optimized it could be:
42.5 seconds (but that's under perfect conditions)

2007/11/30, Kulbir Saini <kulbirsaini at students.iiit.ac.in>:
> On Thu, 29 Nov 2007, Eric Sandeen wrote:
>
> > Dimi Paun wrote:
> >> Hi folks,
> >>
> >> I've currently upgraded to F8, congrats!
> >>
> >> Just thought of sharing a data-point for startup speed
> >> (measured from GRUB, so excluding all the BIOS stuff):
> >>   * to graphical init: 30s
> >>   * to login prompt: 1m8s
> >>   * after login, to responsive state: 14s
> >>
> >> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> >> With the BIOS thrown in, it takes over 2minutes to be able to get
> >> into the box.
> >>
> >> That's rather slow, no?
> >>
>
>     Try disabling service that you think you'll never use. Also don't start
> network (and yum-updatesd also) at startup and delay it by putting
> 'service network start &' in /etc/rc.local. Because you can't use network
> unless you login.
>
>     My Fedora 8 takes 50seconds from Grub to login screen (I mean time from
> pressing enter in grub screen to the time when login screen appears and i
> can login) on AMD64 3000+ (solo core) and 1GB RAM :)
>
>
> -------------------------------------------------------
> Thank you,
> Kulbir Saini,
> Computer Science and Engineering,
> International Institute of Information Technology,
> Hyderbad, India - 500032.
>
> My Home-Page: http://saini.co.in/
> My Institute: http://www.iiit.ac.in/
> My Linux-Blog: http://linux.saini.co.in/
> My Web-Blog: http://life.saini.co.in/
> -------------------------------------------------------
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From markg85 at gmail.com  Fri Nov 30 09:00:00 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 30 Nov 2007 10:00:00 +0100
Subject: Bootup speed for F8
In-Reply-To: <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<474F40C0.6050102@redhat.com>
	<Pine.LNX.4.64.0711300434100.9622@localhost.localdomain>
	<6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com>
Message-ID: <6e24a8e80711300100i4b8960a6y54284382d9506931@mail.gmail.com>

2007/11/30, Mark <markg85 at gmail.com>:
> Here is my bootchart [1]. It's was with the normal fedora setup but
> with apache and mysql added.

And here is the image (pressed "send" to fast):
[1] http://img530.imageshack.us/img530/6483/bootchartsw0.png



From pmachata at redhat.com  Fri Nov 30 09:25:01 2007
From: pmachata at redhat.com (Petr Machata)
Date: Fri, 30 Nov 2007 10:25:01 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in	Fedora
 8?]
In-Reply-To: <20071129202959.GA9414@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>
	<fijuhr$20o$1@ger.gmane.org>	<200711281133.19824.sgrubb@redhat.com>	<474DD09B.8040907@redhat.com>
	<20071129202959.GA9414@nostromo.devel.redhat.com>
Message-ID: <474FD6ED.8080203@redhat.com>

Bill Nottingham wrote:
> Petr Machata (pmachata at redhat.com) said: 
>> Steve Grubb wrote:
>>> kdepim-enterprise-svn20070926.tar.bz2
>> As a side note, I always wondered why to use date in the release tag of
>> package, whose sources come from non-cvs versioning system.  For svn, in
>> my opinion, it would make more sense to use the tree revision number;
>> for git, similarly, sha1 id of the tree.
> 
> Well, git<date> sorts sanely. git<sha1> does not. Comments in the spec
> (or similar) might help with this.

It doesn't have to sort sanely. The release tag is composed from "base"
and "date" parts, where "base" is bumped each time the "date" (or other
identifier) changes.  The "base" part gives you the sorting.

> Bill

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071130/4ca83919/attachment.sig>

From pmachata at redhat.com  Fri Nov 30 09:25:24 2007
From: pmachata at redhat.com (Petr Machata)
Date: Fri, 30 Nov 2007 10:25:24 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <474EE11D.3010608@gmail.com>
References: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>	<474EB4D4.2040300@redhat.com>
	<474EE11D.3010608@gmail.com>
Message-ID: <474FD704.6000106@redhat.com>

Toshio Kuratomi wrote:
> Petr Machata wrote:
>> And maybe I fail to see the
>> intent behind using the date in release tag of vcs-checkouted package.
>> Perhaps it's just an arbitrary identifier.  But if the intent is
>> anything close to making a life easier for whoever reconstructs the
>> srpm, using the release number makes more sense than the date alone.
>>
> After much discussion of exactly this point, the Packaging Committee
> decided that the date/revision id in release tag is not for
> reconstructing the srpm.  It's for consumers of the rpm to have a better
> idea of what they're getting.  For all vcs's a date is good for this as
> it tells the user they're getting a snapshot from a certain date.  For
> svn, and distributed vcs's that have an incrementing release number on a
> canonical branch the release number can be useful for those that are
> following upstream.  For vcs's that have only hash based ids there's
> really no reason to have the hash in the rpm release tag.

Thanks for clarification, that makes sense.  Interestingly enough, and
quite contrary to your argument, naming guidelines allow the release ID
or partial hash to be appended to the date portion of the release tag.

> -Toshio

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071130/ca6c34c1/attachment.sig>

From pmachata at redhat.com  Fri Nov 30 09:31:16 2007
From: pmachata at redhat.com (Petr Machata)
Date: Fri, 30 Nov 2007 10:31:16 +0100
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <20071129165215.ab36369f.mschwendt.tmp0701.nospam@arcor.de>
References: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>	<474EB4D4.2040300@redhat.com>
	<20071129165215.ab36369f.mschwendt.tmp0701.nospam@arcor.de>
Message-ID: <474FD864.5030008@redhat.com>

Michael Schwendt wrote:
> On Thu, 29 Nov 2007 13:47:16 +0100, Petr Machata wrote:
>> Agreed.  By then the upstream could disappear, migrate to whatever hip
>> vc system there is in five years, etc.  And maybe I fail to see the
>> intent behind using the date in release tag of vcs-checkouted package.
>> Perhaps it's just an arbitrary identifier.  But if the intent is
>> anything close to making a life easier for whoever reconstructs the
>> srpm, using the release number makes more sense than the date alone.
> 
> The instructions on how to check out the source from cvs/svn/whatever
> should be put into comments in the spec file. Don't attempt at squeezing
> svn revisions (and silimar identifiers) into the package file name.

Again, that depends on what's the intent behind placing the date into
release tag.  From Toshio's mail I know what's the rationale behind
using the date, so I can agree with you at this point.

> Originally, the date in the file name has been used as (1) information
> about the age of a packaged post/pre-release _snapshot_ and (2) as the
> least-significant portion of %release (the newer date of a newer checkout
> would make the built package an upgrade without the need to bump %release
> elsewhere).

Currently, you have to bump "base" release tag in addition to changing
the date portion.

> If todays policies say you must add a date and SCM id like YYYYMMDDcvs,
> they ought to be revisited. ;)

Yes, snapshot packages should, under the naming guideline, contain the
date and the string "cvs".  And, as has been pointed out to me, it's
even allowed to append tree release or (part of) git tree ID to that string.

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071130/48fc6fef/attachment.sig>

From che666 at gmail.com  Fri Nov 30 09:30:31 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 30 Nov 2007 09:30:31 +0000
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>

Personally i am working on straightening out initng which is part of
the repos and with selinux disabled (there is a bug in current initng
regarding selinux so dont use it if you want selinux enabled until the
next fix shows up) from start if init to gdm in 15 seconds with
NetworkManager and all that stuff enabled.
I guess with a bit more hacking and optimising you could go close to 10 seconds.

kind regards,
Rudolf Kastl

On Nov 29, 2007 10:34 PM, Dimi Paun <dimi at lattica.com> wrote:
> Hi folks,
>
> I've currently upgraded to F8, congrats!
>
> Just thought of sharing a data-point for startup speed
> (measured from GRUB, so excluding all the BIOS stuff):
>   * to graphical init: 30s
>   * to login prompt: 1m8s
>   * after login, to responsive state: 14s
>
> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> With the BIOS thrown in, it takes over 2minutes to be able to get
> into the box.
>
> That's rather slow, no?
>
> --
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From che666 at gmail.com  Fri Nov 30 09:30:31 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 30 Nov 2007 09:30:31 +0000
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>

Personally i am working on straightening out initng which is part of
the repos and with selinux disabled (there is a bug in current initng
regarding selinux so dont use it if you want selinux enabled until the
next fix shows up) from start if init to gdm in 15 seconds with
NetworkManager and all that stuff enabled.
I guess with a bit more hacking and optimising you could go close to 10 seconds.

kind regards,
Rudolf Kastl

On Nov 29, 2007 10:34 PM, Dimi Paun <dimi at lattica.com> wrote:
> Hi folks,
>
> I've currently upgraded to F8, congrats!
>
> Just thought of sharing a data-point for startup speed
> (measured from GRUB, so excluding all the BIOS stuff):
>   * to graphical init: 30s
>   * to login prompt: 1m8s
>   * after login, to responsive state: 14s
>
> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> With the BIOS thrown in, it takes over 2minutes to be able to get
> into the box.
>
> That's rather slow, no?
>
> --
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From markg85 at gmail.com  Fri Nov 30 09:48:01 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 30 Nov 2007 10:48:01 +0100
Subject: Bootup speed for F8
In-Reply-To: <e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
Message-ID: <6e24a8e80711300148qbe1400m116374b0be66546a@mail.gmail.com>

2007/11/30, Rudolf Kastl <che666 at gmail.com>:
> Personally i am working on straightening out initng which is part of
> the repos and with selinux disabled (there is a bug in current initng
> regarding selinux so dont use it if you want selinux enabled until the
> next fix shows up) from start if init to gdm in 15 seconds with
> NetworkManager and all that stuff enabled.
> I guess with a bit more hacking and optimising you could go close to 10 seconds.

That's a real speed boost!
and how fast was your boot without nintng? (just init)
Or better.. could you post yout init bootchart and your initng
bootchart? would be interesting to see.



From lordmorgul at gmail.com  Fri Nov 30 09:51:03 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Fri, 30 Nov 2007 01:51:03 -0800
Subject: Extreme memory usage for gnome-panel related apps
In-Reply-To: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com>
References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com>
Message-ID: <474FDD07.4070804@gmail.com>

Mark wrote:
> Now the notebook i'm typing this on has 1GB om memory and runs Fedora
> fine so if i look at it that way than the ram usage is fine. but keep
> in mind the people with less memory (256 or 512 MB's) they are gonna
> get a hard time with this fedora. My total memory usage at the time of
> this writing is: 432.00 MB (with GIMP on.. if that's closed than it's
> "just" 400 MB).

My P4 desktop system is currently showing 880Mb of memory 'in use' with 140Mb or
so free... and its doing nothing but playing mp3s from rhythmbox.  That actually
doesn't tell you much however, since its been running for a week and most of
that memory isn't actually being 'used' atm.  The machine has 144k of the 2Gb
swap 'in use'.  This is a good thing, nothing should be swapped if it doesn't
need to be.

> What i'm trying to say here is that those gnome-panel applets are
> taking up way to much memory regardless of the memory you can afford
> or have in your computer. It should just be as fast and small as
> possible with all the needed functions.

Yes, but who defines what are the needed functions and how much memory those
require?  Its not always simple choice to immediately release all memory used by
a program that isn't critical right now... I do not want clock cycles spent
recalculating things an application should have just stored for awhile.

> Gnome and Fedora are currently looking fine the way they are.
> so perhaps it's time to stop spending time on features for a while (2
> releases? till Fedora 10?) and start spending all time/money/efforts
> on performance  memory usage and usability.

These are mostly upstream issues for Fedora.  The tradeoffs of newer features
versus higher performance tweaking is always difficult, especially when the
people doing the programming have to do both... new features are usually more
fun to deal with.

Usability is at odds against performance and memory usage for the most part.
Having things preloaded, cached, etc, increases usability and overall polish.
When popping open a help window for instance, the faster it shows up the better
for the user.  If memory is used for some of the libraries it may depend on, so
it opens faster, that memory may seem wasted until you save the 2-3s waiting for
a window.

I don't mean to sound argumentative, but keep this in mind: working without X
uses less memory, but your memory isn't useful to you unless something
meaningful is being written on its bits... in a very extreme sense thats relevant.

> And again for the memory. Having much doesn't need that it needs to
> use much! slow pc's with less memory should be able to run fedora
> right? Simple example. imagine that a slow 500 MHz pc with 512MB
> memory wants to run Fedora + compizfusion + Gimp. Now at this moment
> he must drop compiz or gimp. if that panel stuff was just using normal
> amounts of memory he would have been able to use all 3 (just a
> example!!)

My HP Ipaq won't run compizfusion either... and development of fusion (and its
memory needs) shouldn't be held back by that.  A 500Mhz machine is clearly out
of the hardware target specs for 3d accelerated fusion.  While your main point
(reduce memory usage if possible!) is good, keep in mind that 12 year old
machines do NOT have to run the newest OS goodies 'well'.

I'm pretty sure a 500Mhz machine will perform adequately well with Fedora 8
running a light window manager such as blackbox, perhaps even XFCE4, but Gnome2
is asking too much IMO.

Also, looking at your system monitor window as is you're not getting a very
clear picture of what is going on with your memory just from that 'Memory'
column (maybe you already know this).  Add the other columns, especially shared,
resident, and virtual memory.  Look at the memory map (right click), sort by the
various columns, and you'll see that much of the memory shown as used is from
loaded libraries and caching (in the case of nautilus especially).  The 'bloat'
in a programs memory is going to show up as private memory not associated with a
file; there is where the program is storing most of own 'stuff'.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From lordmorgul at gmail.com  Fri Nov 30 10:28:00 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Fri, 30 Nov 2007 02:28:00 -0800
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <1196246223.23384.52.camel@vespa.kabelta.loc>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127152535.GA7102@traged.englab.brq.redhat.com>	<6e24a8e80711271441wfedb316gaa5d8c046420c509@mail.gmail.com>	<20071128102429.GB11004@evileye.atkac.englab.brq.redhat.com>
	<1196246223.23384.52.camel@vespa.kabelta.loc>
Message-ID: <474FE5B0.5070201@gmail.com>

Tomas Mraz wrote:
> I have to agree with you. The "alpha" name in version mostly doesn't
> mean much. If you really tested it thoroughly I don't think you should
> be blamed. Because otherwise nobody could allow for example Evolution
> into the distro as it sometimes eats e-mails in my configuration (the
> bug is reported upstream for a long time and no fix is ahead).

Haha.. a classic case in point.  Evolution has had reported/unfixed bugs with
'rampant unchecked memory consumption' for many years, and it does cause crashes
and data loss.  The simple fact is many people need its features in an
enterprise environment, so 'stable' as the releases are not they must be used.

A bug showing up in an alpha BIND is (though unfortunate) really just a bug
showing up in BIND; the alphaness may have had nothing to do with it.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From lordmorgul at gmail.com  Fri Nov 30 10:47:45 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Fri, 30 Nov 2007 02:47:45 -0800
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128231350.GG24257@angus.ind.WPI.EDU>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<20071127152535.GA7102@traged.englab.brq.redhat.com>	<20071128035807.GA3718@nostromo.devel.redhat.com>	<604aa7910711272032sc1703edh9fb76b1168dd94d0@mail.gmail.com>	<20071128053010.GA10110@nostromo.devel.redhat.com>	<20071128103032.GC11004@evileye.atkac.englab.brq.redhat.com>	<474D4B68.7010909@redhat.com>	<20071128152752.GA7297@nostromo.devel.redhat.com>	<474DBE43.5020501@redhat.com>
	<20071128231350.GG24257@angus.ind.WPI.EDU>
Message-ID: <474FEA51.40405@gmail.com>

Chuck Anderson wrote:
> But doesn't ISC also need a period of releases where they can go hog 
> wild with changes, new features, etc. and not worry about stability as 
> much?  Isn't that period of time usually called "Alpha"?

Maybe.. and maybe not.  Most OSS projects don't even tag something alpha unless
they actually expect someone OTHER THAN DEVELOPERS to compile, install, test,
and use it (its just a cvs snapshot before that).  Alpha can mean anything, or
nothing, and often does; to assume the term 'alpha' being present means you must
discount the maintainer's expertise with the software would be very shallow.

> It's like 
> Rawhide--the software in there may be stable, but it doesn't have to 
> be, and often isn't at the beginning of a new release cycle.

Yes, sure but its also not supposed to be completely bleeding and fleshy code a
developer uploaded to his cvs the night before with his eyes bloodshot and
forehead on the desk even in the 'period of hog wild changes'.

> It's all about perception.  I wouldn't put Rawhide on my production 
> servers, and I don't expect something that upstream calls "Alpha" to 
> be on my production servers either.

This is nice, but it almost sounds like 'I want the newest release for the
distro but I want it rock f-ing solid'.  F8 released less than a month ago with
many updates and bugs fixed since; I wouldn't have installed it on a production
system so soon, 'alpha' in a package name or not.  I can understand wanting to
go to F8 rather than F7, but really within a month of release?

Its not all about perception; its also much about expectation.  Bugs should be
expected, even with finely tuned and polished software... and even when upstream
thinks its stable.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From lordmorgul at gmail.com  Fri Nov 30 10:51:14 2007
From: lordmorgul at gmail.com (Andrew Farris)
Date: Fri, 30 Nov 2007 02:51:14 -0800
Subject: alpha/beta software in Fedora 8?
In-Reply-To: <20071128145625.GA1753@ee.oulu.fi>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<1196130595.3229.20.camel@localhost.localdomain>	<474C491F.2030204@redhat.com>	<1196193744.3229.54.camel@localhost.localdomain>	<ufahcj6vrpb.fsf@epithumia.math.uh.edu>	<474D0BCC.5010800@redhat.com>	<1196254013.3054.58.camel@localhost.localdomain>	<474D7C4B.7080405@redhat.com>
	<20071128145625.GA1753@ee.oulu.fi>
Message-ID: <474FEB22.3050109@gmail.com>

Pekka Pietikainen wrote:
> It would appear there is a lack of "Why is this version being shipped"
> documentation as well. If it's a Major Feature (like KDE4) it'll get tracked
> and discussed, but otherwise if there's a good reason for shipping something
> older (e.g. newest version introduces dependency hell) or newer (CVS snapshot
> fixes critical issues) than the latest "stable" there's often no way of
> figuring out other than asking the maintainer, who usually will have a good
> answer.
> 
> Maybe have something like this in pkgdb?

A method of documenting a regression due to major breakage might not be well
setup, but any 'cvs snapshot newer' reasons can be easily just added to the
changelog.

-- 
Andrew Farris <lordmorgul at gmail.com> <ajfarris at gmail.com>
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----



From lkundrak at redhat.com  Fri Nov 30 11:05:27 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Fri, 30 Nov 2007 12:05:27 +0100
Subject: Extreme memory usage for gnome-panel related apps
In-Reply-To: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com>
References: <6e24a8e80711300034kc167693l51b7b5c23fa38114@mail.gmail.com>
Message-ID: <1196420727.14073.11.camel@localhost.localdomain>


On Fri, 2007-11-30 at 09:34 +0100, Mark wrote:

> i was just looking through the system monitor to see how my memory
> usage was doing and that gave me a impressive (negative way) result.
> I've made a screenshot [1] of it and edited it a little. The color
> that i added in mean:
> 
> - darkred : extreme memory usage for..?? nothing?
> - red : gnome-panel related things (applets mostly)
> - orange : first applet UNDER one MB.
> 
> Now if you take a look at the image you see that my current gnome
> session is taking up:
> 4.9 MB (gnome-panel)
> 3.5 MB (mixer_applet2)
> 3.0 MB (wnck-applet)
> 2.3 MB (nm-applet)
> 1.2 MB (notification-area-applet)
> 1.1 MB (gnome-volume-manager)
> 0.7 MB (bluetooth-applet)

I was kind of worried about the default choice of applets for a
different reason -- they seem to slow Gnome startup very much. Did
anyone notice, that Fedora 8 Gnome startup takes roughly two times
longer than Fedora 6 one? On the other side I just took it as a fact of
life, and disabled things that I don't use like bluetooth or tomboy in
my kickstarts. All in all, the same thing applies for services.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From che666 at gmail.com  Fri Nov 30 11:54:46 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 30 Nov 2007 11:54:46 +0000
Subject: Bootup speed for F8
In-Reply-To: <6e24a8e80711300148qbe1400m116374b0be66546a@mail.gmail.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
	<6e24a8e80711300148qbe1400m116374b0be66546a@mail.gmail.com>
Message-ID: <e99d27470711300354r56be99c2ue443c58f19456a2a@mail.gmail.com>

On Nov 30, 2007 9:48 AM, Mark <markg85 at gmail.com> wrote:
> 2007/11/30, Rudolf Kastl <che666 at gmail.com>:
> > Personally i am working on straightening out initng which is part of
> > the repos and with selinux disabled (there is a bug in current initng
> > regarding selinux so dont use it if you want selinux enabled until the
> > next fix shows up) from start if init to gdm in 15 seconds with
> > NetworkManager and all that stuff enabled.
> > I guess with a bit more hacking and optimising you could go close to 10 seconds.
>
> That's a real speed boost!
> and how fast was your boot without nintng? (just init)
> Or better.. could you post yout init bootchart and your initng
> bootchart? would be interesting to see.

i surely can do that. of course bootchart also slows down everything.
if i get around to it i might do that within the next week and try
with a comparable setup to show the differences.

kind regards,
Rudolf Kastl

>
> --
>
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jdieter at gmail.com  Fri Nov 30 12:09:02 2007
From: jdieter at gmail.com (Jonathan Dieter)
Date: Fri, 30 Nov 2007 14:09:02 +0200
Subject: Bootup speed for F8
In-Reply-To: <e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
Message-ID: <1196424542.3486.2.camel@jndwidescreen.lesbg.loc>

On Fri, 2007-11-30 at 09:30 +0000, Rudolf Kastl wrote:
> Personally i am working on straightening out initng which is part of
> the repos and with selinux disabled (there is a bug in current initng
> regarding selinux so dont use it if you want selinux enabled until the
> next fix shows up) from start if init to gdm in 15 seconds with
> NetworkManager and all that stuff enabled.
> I guess with a bit more hacking and optimising you could go close to 10 seconds.
> 
I just gave initng a shot, and, while it started up my system extremely
fast, I noticed a number of failure messages on the screen and when I
logged in, I noticed that my CPU Frequency applet said that my CPU
wasn't capable of scaling (it's a laptop with a Core Duo processor and
three different levels of scaling).

Do you want bug reports or does it need a bit more work before it can
replace normal init?

Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071130/dc12cfa9/attachment.sig>

From che666 at gmail.com  Fri Nov 30 12:32:09 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 30 Nov 2007 12:32:09 +0000
Subject: Bootup speed for F8
In-Reply-To: <1196424542.3486.2.camel@jndwidescreen.lesbg.loc>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
	<1196424542.3486.2.camel@jndwidescreen.lesbg.loc>
Message-ID: <e99d27470711300432y423308f3kaa016a2f88125c98@mail.gmail.com>

On Nov 30, 2007 12:09 PM, Jonathan Dieter <jdieter at gmail.com> wrote:
> On Fri, 2007-11-30 at 09:30 +0000, Rudolf Kastl wrote:
> > Personally i am working on straightening out initng which is part of
> > the repos and with selinux disabled (there is a bug in current initng
> > regarding selinux so dont use it if you want selinux enabled until the
> > next fix shows up) from start if init to gdm in 15 seconds with
> > NetworkManager and all that stuff enabled.
> > I guess with a bit more hacking and optimising you could go close to 10 seconds.
> >
> I just gave initng a shot, and, while it started up my system extremely
> fast, I noticed a number of failure messages on the screen and when I
> logged in, I noticed that my CPU Frequency applet said that my CPU
> wasn't capable of scaling (it's a laptop with a Core Duo processor and
> three different levels of scaling).

the cpuspeed script has to be fixed. actually as a workaround you can
just use the following wrapper:

#!/sbin/itype
# This is a i file, used by initng parsed by install_service

# NAME:
# DESCRIPTION:
# WWW:

service service/cpuspeed {
        need = system/bootmisc;
        use = system/modules system/coldplug;
        exec start = /etc/init.d/cpuspeed start;
        exec stop = /etc/init.d/cpuspeed stop;
}

put the above script into:

/etc/initng/service/cpuspeed.i

of course that is just a workaround :D

>
> Do you want bug reports or does it need a bit more work before it can
> replace normal init?

That is a pretty much known problem and if i am not too wrong i even
filed it into fedora bugzilla. If you encounter something and dont
find a report for it yet please report it as many people have the
chance then to attach a fix for it.

Of course there is still alot of work to do to smooth things out. What
should work now is getting the system to boot in any case. There is
also lots of things to improve in the base system to make things go
smoother. e.g. you will see that NetworkManager will fail upon bootup.
That is because dbus daemon needs 5 seconds when it has been started
until the service is available. The above numbers i gave for boottime
include having a sleep 5 in the NetworkManager startup script (hacky
workaround that needs a fix with dbus).

It is definitely not ready for real end user consumption because
things have to be checked and improved all over the place but with
more people contributing actually that could get done rather fast in
my eyes. It is just alot work if only a few people with not much spare
time fix things here and there as time permits, so every small bit of
help and patch is a nice thing to have.

Yes the bootup time is very fast but i think to get broader acceptance
more stuff has to be fixed. Actually the new version of it in the pipe
is supposed to be able to take dbus events to get things started up
and uses posix compliant startup scripts (note that the upcoming
scripts are automatically generated from the ifiles it uses now so it
makes sense to just fix the current stable release). The svn scripts
also allow the addition of new events like beeing able to add status
scripts/routines and configcheck etc.

kind regards,
Rudolf Kastl


>
> Jonathan
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From lkundrak at redhat.com  Fri Nov 30 12:43:14 2007
From: lkundrak at redhat.com (Lubomir Kundrak)
Date: Fri, 30 Nov 2007 13:43:14 +0100
Subject: WIP VCS branch [Ad: Package Review VCS]
Message-ID: <1196426595.14073.26.camel@localhost.localdomain>

Hi,

Warren's brilliant idea of a separate VCS for package reviews reminds me
of how the NetBSD/pkgsrc projects does this kind of things. They keep a
repository named pkgsrc-wip, which is basically a repository open for
anyone (with an account). It is where packages that are not
complete/finished/reviewed are.

One of its uses is package review -- new packagers just add their
packages here, ask for help on a dedicated list and when they feel the
package is finished, they ask for a review. This is how they learn to
package. It also encourages cooperation during packaging.

Other use is that packagers keep packages that are not finished in some
way. This is what we don't have and might be a nice thing to have:

Let's say a package is in alpha state, without a clear idea when would
it be relased and in very unfinished state. Considering that
devel/rawhide is place for things that are expected to be stable at the
time of release, it's not a good home for such packages. Currently
packagers just keep those packages in their private repositories.
Examples are KDE4, xulrunner, GRUB 2, etc. I think it would be
definitely better to have them in Fedora hosted VCS.

-- 
Lubomir Kundrak (Red Hat Security Response Team)



From j.w.r.degoede at hhs.nl  Fri Nov 30 13:31:26 2007
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 30 Nov 2007 14:31:26 +0100
Subject: WIP VCS branch [Ad: Package Review VCS]
In-Reply-To: <1196426595.14073.26.camel@localhost.localdomain>
References: <1196426595.14073.26.camel@localhost.localdomain>
Message-ID: <475010AE.6040503@hhs.nl>

Lubomir Kundrak wrote:
> Hi,
> 
> Warren's brilliant idea of a separate VCS for package reviews reminds me
> of how the NetBSD/pkgsrc projects does this kind of things. They keep a
> repository named pkgsrc-wip, which is basically a repository open for
> anyone (with an account). It is where packages that are not
> complete/finished/reviewed are.
> 
> One of its uses is package review -- new packagers just add their
> packages here, ask for help on a dedicated list and when they feel the
> package is finished, they ask for a review. This is how they learn to
> package. It also encourages cooperation during packaging.
> 
> Other use is that packagers keep packages that are not finished in some
> way. This is what we don't have and might be a nice thing to have:
> 
> Let's say a package is in alpha state, without a clear idea when would
> it be relased and in very unfinished state. Considering that
> devel/rawhide is place for things that are expected to be stable at the
> time of release, it's not a good home for such packages. Cur
Hermans, V.H.F. wrote:
>  
rently
> packagers just keep those packages in their private repositories.
> Examples are KDE4, xulrunner, GRUB 2, etc. I think it would be
> definitely better to have them in Fedora hosted VCS.
> 

Such a wip VCS sounds like a good plan, I know I would use it a lot, 
currently I actually have a dir called wip in my fedora dir, with under 
that a dir per package I'm packaging.

Having this would also make it easy to sync changes between
  multiple computers while working on them.

Regards,

Hans



From mschwendt.tmp0701.nospam at arcor.de  Fri Nov 30 13:57:47 2007
From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt)
Date: Fri, 30 Nov 2007 14:57:47 +0100
Subject: Heads up: openldap rebase for Fedora/devel
In-Reply-To: <474EB88A.5010307@redhat.com>
References: <4745A750.4080904@redhat.com>
	<474EB88A.5010307@redhat.com>
Message-ID: <20071130145747.e718e06c.mschwendt.tmp0701.nospam@arcor.de>

On Thu, 29 Nov 2007 14:03:06 +0100, Jan Safranek wrote:

> Jan Safranek wrote:
> > I'd like to update openldap in devel to the new version. Many packages 
> > depend on openldap, so I will provide compat-openldap package, which 
> > will provide 2.3.x libraries and no recompilation of any component would 
> > be required.
> > 
> > I'd like to to ask all maintainers of components, which depend on 
> > openldap (see appendix), to test following simple cases:
> > 
> > 1. the component works with compat-openldap, which provides 'old' 2.3.x
> > libraries
> ...
> 
> I did not get any overwhelming response, actually only Terje Rosten 
> responded that he tested his packages (thanks!). I internally tried to 
> recompile all packages depending on openldap:

Sorry. I couldn't find the time and motivation to test Sylpheed with
any new openldap in rawhide yet. Usually when I can't "yum update" due
to broken deps or conflicts, I'm annoyed and return to a working
installation. This morning I've tried to update rawhide once more,
but after having to remove liferea and mplayer* due to broken deps
and after downloading 394 pkgs it failed like this:

Transaction Check Error:
  file /etc/gre.d/gre.conf conflicts between attempted installs of xulrunner-1.9-0.beta1.3.fc9.i386 and firefox-2.0.0.10-1.fc9.i386



From buildsys at redhat.com  Fri Nov 30 14:08:22 2007
From: buildsys at redhat.com (Build System)
Date: Fri, 30 Nov 2007 09:08:22 -0500
Subject: rawhide report: 20071130 changes
Message-ID: <200711301408.lAUE8Ma3000912@porkchop.devel.redhat.com>

New package gnome-device-manager
	Graphical Device Manager Application

New package goocanvasmm
	C++ interface for goocanvas

New package rubygem-actionmailer
	Service layer for easy email delivery and testing

New package rubygem-actionpack
	Web-flow and rendering framework putting the VC in MVC

New package rubygem-actionwebservice
	Web service support for Action Pack

New package rubygem-activerecord
	Implements the ActiveRecord pattern for ORM

New package rubygem-activesupport
	Support and utility classes used by the Rails framework

New package rubygem-rails
	Web-application framework


Removed package sysprof-kmod

Removed package em8300-kmod

Updated Packages:

BackupPC-3.1.0-1.fc9
--------------------
* Thu Nov 29 2007 Johan Cwiklinski <johan AT x-tnd DOT be> 3.1.0-1
- New upstream version
- Added samba-client as a dependency
- Added readme.fedora
- Changed CGI admin path in default config file

* Fri Sep 21 2007 Johan Cwiklinski <johan AT x-tnd DOT be> 3.0.0-3
- Fixed SELinux policy module

* Wed Sep 12 2007 Johan Cwiklinski <johan AT x-tnd DOT be> 3.0.0-2
- Added SELinux policy module

amarok-1.4.7-12.fc9
-------------------
* Thu Nov 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.4.7-12
- --with-mp4v2 (rh#346011)
- fix asf/wma support (rh#346011,kde#151733)

* Wed Nov 21 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.4.7-11
- dynamic mode floods playlist ... (kde #148317)

* Wed Nov 21 2007 Todd Zullinger <tmz at pobox.com> 1.4.7-10
- rebuild for libgpod-0.6.0

anaconda-11.4.0.4-1
-------------------
* Thu Nov 29 2007 Jeremy Katz <katzj at redhat.com> - 11.4.0.4-1
- Initial support for partition and LV resizing.  VERY EXPERIMENTAL!
- Commit partitioning changes to disk earlier
- Add start of ext4 support
- Fix some tracebacks
- Add support back for alpha (Oliver Falk)

autodownloader-0.2.0-5.fc9
--------------------------
* Thu Nov 29 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 0.2.0-5
- Apply patch from Ivo Manca fixing the downloading of files with an
  unknown size, thanks!
beecrypt-4.1.2-15
-----------------
* Thu Nov 29 2007 Dennis Gilmore <dennis at ausil.us> - 4.1.2-15
- update sparc64 patch

bmpx-0.40.13-6.fc9
------------------
* Thu Nov 29 2007 Alexander Kahl <akahl at iconmobile.com> - 0.40.13-6
- added patch for gtk_check_version on gtk2-2.2.12

* Thu Nov 29 2007 Alexander Kahl <akahl at iconmobile.com> - 0.40.13-5
- bump for firefox 2.0.0.10

bouml-3.3.3-1.fc9
-----------------
* Thu Nov 29 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.3.3-1
- Version bump to 3.3.3. Closes Red Hat Bugzilla bug #398811.
- Fixed usage of _remove_encoding to prevent failure on Fedora 7.

* Sun Nov 25 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.3.1-2
- Removed Encoding from Desktop Entry for all distributions, except Fedora 7.

* Tue Nov 13 2007 Debarshi Ray <rishi at fedoraproject.org> - 3.3.1-1
- Version bump to 3.3.1.
- Removed Encoding from Desktop Entry.

coreutils-6.9-15.fc9
--------------------
* Thu Nov 29 2007 Ondrej Vasik <ovasik at redhat.com> - 6.9-15
- completed fix of wrong colored broken symlinks in ls(#404511)

cups-pdf-2.4.6-5.fc9
--------------------
* Thu Nov 29 2007 Remi Collet <Fedora at FamilleCollet.com> 2.4.6-5
- update default conf: use ${DESKTOP}

docbook-style-xsl-1.73.2-5.fc9
------------------------------
* Tue Nov 27 2007 Ondrej Vasik <ovasik at redhat.com> 1.73.2-5
- convert all html files in doc to UTF-8 in prep
  (latest rpmlint gives warnings)
- no longer using release in style-xsl dir(#389231)

ecryptfs-utils-30-1.fc9
-----------------------
* Thu Nov 29 2007 Karsten Hopp <karsten at redhat.com> 30-1
- build version 30

* Fri Oct 05 2007 Mike Halcrow <mhalcrow at us.ibm.com> - 30-0
- Bump to version 30. Several bugfixes. Key modules are overhauled
  with a more sane API.

epiphany-2.20.2-1.fc9
---------------------
* Tue Nov 27 2007 Matthias Clasen <mclasen at redhat.com> - 2.20.2-1
- Update to 2.20.2

* Tue Nov 27 2007 Christopher Aillon <caillon at redhat.com> - 2.20.1-6
- Rebuild against newer gecko

* Mon Nov 19 2007 Martin Stransky <stransky at redhat.com> - 2.20.1-5
- Updated wrapper patch

epiphany-extensions-2.20.1-3.fc9
--------------------------------
* Tue Nov 27 2007 Christopher Aillon <caillon at redhat.com> - 2.20.1-2
- Rebuild against newer gecko

evolution-2.21.2-3.fc9
----------------------
* Thu Nov 29 2007 Matthew Barnes <mbarnes at redhat.com> - 2.21.2-3.fc9
- Add patch for GNOME bug #499920 (invalid #include).
exaile-0.2.11.1-1.fc9
---------------------
* Thu Nov 29 2007 Deji Akingunola <dakingun at gmail.com> - 0.2.11.1-1
- Update to 0.2.11.1 that removes bogus cruft from 0.2.11 source tarball
- Rebuild for firefox-2.0.0.10

freeciv-2.1.1-1.fc9
-------------------
* Thu Nov 29 2007 Brian Pepple <bpepple at fedoraproject.org> - 2.1.1-1
- Update to 2.1.1.
- Drop buffer overflow patch. fixed upstream.
- Drop open file patch. fixed upstream.

freeradius-1.1.7-3.3.ipa.fc9
----------------------------
* Sat Nov 10 2007 <jdennis at redhat.com> - 1.1.7-3.3.ipa
- add support in rlm_ldap for reading clients from ldap
- fix TLS parameter controling if a cert which fails to validate
  will be accepted (i.e. self-signed),
  rlm_ldap config parameter=tls_require_cert
  ldap LDAP_OPT_X_TLS_REQUIRE_CERT parameter was being passed to
  ldap_set_option() when it should have been ldap_int_tls_config()

* Sat Nov 03 2007 <jdennis at redhat.com> - 1.1.7-3.2.ipa
- add support in rlm_ldap for SASL/GSSAPI binds to the LDAP server

gnokii-0.6.22-1.fc9
-------------------
* Thu Nov 29 2007 - Bastien Nocera <bnocera at redhat.com> - 0.6.22-1
- Update to 0.6.22

gnome-applet-sensors-1.8.2-1.fc9
--------------------------------
* Mon Nov 19 2007 Hans de Goede <j.w.r.degoede at hhs.nl> 1.8.2-1
- New upstream release 1.8.2 (bz 403921)
- Drop upstream sensors-applet-1.8.1-get-min-max-from-libsensors.patch

gnomesword-2.3.1-3.fc9
----------------------
* Thu Nov 29 2007 Deji Akingunola <dakingun at gmail.com> - 2.3.1-3
- Rebuild for firefox-2.0.0.10

gpodder-0.10.2-1.fc9
--------------------
* Thu Nov 29 2007 Jef Spaleta <jspaleta at gmail.com> 0.10.2-1
- New Upstream version
- A mixed bag of bugfixes and enhancements
- See upstream release notes for full details

hyperestraier-1.4.12-1.fc9
--------------------------
* Thu Nov 29 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.4.12-1
- 1.4.12

hyphen-it-0.20071127-2.fc9
--------------------------

icecream-0.8.0-6.20071101svn.fc9
--------------------------------
* Thu Nov 29 2007 Michal Schmidt <mschmidt at redhat.com> - 0.8.0-6.20071101svn
- Rewritten the profile scripts to make icecream work together with ccache.

jd-1.9.8-0.1.svn1563.fc9
------------------------
* Thu Nov 29 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.8-0.1.svn1563
- svn 1563

* Thu Nov 22 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-1
- 1.9.7

* Thu Nov 15 2007 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.9.7-0.4.rc071105
- 1.9.7 rc 071115

kdebase-runtime-3.96.2-1.fc9
----------------------------
* Thu Nov 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.2-1
- kde-3.96.2

kdeedu-3.96.2-1.fc9
-------------------
* Thu Nov 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.2-1
- kde-3.96.2

kdegames-6:3.96.2-1.fc9
-----------------------
* Thu Nov 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.2-1
- kde-3.96.2

kdegames3-3.5.8-2.fc9
---------------------
* Thu Nov 29 2007 Kevin Kofler <Kevin at tigcc.ticalc.org> - 3.5.8-2
- clarify Summary

kdelibs4-3.96.2-1.fc9
---------------------
* Thu Nov 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.92.2-1
- kde-3.96.2

kdepimlibs-3.96.2-1.fc9
-----------------------
* Thu Nov 29 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 3.96.2-1
- kde-3.96.2

kernel-2.6.24-0.57.rc3.git4.fc9
-------------------------------
* Thu Nov 29 2007 Dave Jones <davej at redhat.com>
- 2.6.24-rc3-git4

* Thu Nov 29 2007 John W. Linville <linville at redhat.com>
- Resync wireless bits headed for 2.6.25

* Thu Nov 29 2007 Dave Airlie <airlied at linux.ie>
- update drm-mm-git.patch to fix 64-bit truncation

ldns-1.2.2-1.fc9
----------------
* Thu Nov 29 2007 Paul Wouters <paul at xelerance.com> - 1.2.2-1
- Upgraded to 1.2.2. Removed no longer needed race workaround

liferea-1.4.8-2.fc9
-------------------
* Tue Nov 27 2007 Christopher Aillon <caillon at redhat.com> - 1.4.8-2
- Rebuild against newer gecko

nagios-2.10-5.fc9
-----------------
* Thu Nov 29 2007 Mike McGrath <mmcgrath at redhat.com> 2.10-5
- Upstream released 2.10
- Renamed cfg-sample configs to just .cfg
- Added BR of perl-devel, libjpeg-devel, libpng-devel

* Wed Sep 26 2007 Mike McGrath <mmcgrath at redhat.com> 2.9-5
- rebuild for koji test

* Sat Sep 08 2007 Mike McGrath <mmcgrath at redhat.com> 2.9-4
- rebuild

namazu-2.0.17-6.fc9
-------------------
* Thu Nov 29 2007 Akira TAGOH <tagoh at redhat.com> - 2.0.17-6
- Correct a timestamp for nmz-config.
- Add "replase" to %config.
- Move %post and %postun to -libs.

nut-2.2.0-6.1.fc9
-----------------
* Thu Nov 29 2007 Tomas Smetana <tsmetana at redhat.com> 2.2.0-6.1
- init script update, fix a typo

* Wed Nov 28 2007 Tomas Smetana <tsmetana at redhat.com> 2.2.0-6
- fix forgotten bug in init script
- do not hardcode the uucp group in udev patch

* Tue Nov 27 2007 Tomas Smetana <tsmetana at redhat.com> 2.2.0-5
- fix udev rules and hal information files
- fix init script

openoffice.org-1:2.3.1-9.4.fc9
------------------------------
* Sat Nov 24 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.1-9.4
- Resolves: rhbz#384391 add openoffice.org-2.3.1.ooo83930.sw.flushanchors.patch
- split out libhyphen and hyphenators
- add openoffice.org-2.3.1.ooo84001.slideshow.gccisaprick.patch coz gcc hates us
- drop openoffice.org-2.3.1.83876.unopkg.avoida11y.patch coz upstream won't do it

* Thu Nov 22 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.1-9.3
- Resolves: rhbz#247634 add openoffice.org-2.3.1.ooo82911.sd.insertbackground.patch (jnavrati)
- Resolves: rhbz#386371 add workspace.sw8u10bf02.patch (caolanm)
- add openoffice.org-2.3.1.83876.unopkg.avoida11y.patch to avoid unopkg
  crapping out on first run with a11y enabled and no X (caolanm)
- add openoffice.org-2.3.1.ooo83877.sal.allowsoftlinkdelete.patch to allow
  sal to delete softlinks (caolanm)
- add openoffice.org-2.3.1.ooo83878.unopkg.enablelinking.patch to enable
  linking to unpacked extensions already on the fs when registering (caolanm)
==> makes extension rpm packaging non-wasteful and safe

* Thu Nov 15 2007 Caolan McNamara <caolanm at redhat.com> - 1:2.3.1-9.2
- move from firefox to xulrunner

pam-0.99.8.1-12.fc9
-------------------
* Thu Nov 29 2007 Tomas Mraz <tmraz at redhat.com> 0.99.8.1-12
- add pam_tty_audit module (#244352) - written by Miloslav Trma??

plplot-5.8.0-2.fc9
------------------
* Thu Nov 29 2007 - Orion Poplawski <orion at cora.nwra.com> - 5.8.0-2
- Rebuild for new octave api

poppler-0.6.2-2.fc9
-------------------
* Wed Nov 28 2007 Matthias Clasen <mclasen at redhat.com> - 0.6.2-2
- package xpdf headers in poppler-devel (Jindrich Novy)
- Fix qt3 detection (Denis Leroy)

* Thu Nov 22 2007 Matthias Clasen <mclasen at redhat.com> - 0.6.2-1
- Update to 0.6.2

* Thu Oct 11 2007 Rex Dieter <rdieter[AT]fedoraproject.org> - 0.6-2
- include qt4 wrapper

pulseaudio-0.9.8-4.fc9
----------------------
* Thu Nov 29 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.8-4
- add missing dependency on pulseaudio-utils for pulseaudio-module-x11

* Thu Nov 29 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.8-3
- Create ~/.pulse/ if not existant

* Thu Nov 29 2007 Lennart Poettering <lpoetter at redhat.com> 0.9.8-2
- Add missing dependency on jack-audio-connection-kit-devel

pyflowtools-0.3.2-1.fc9
-----------------------
* Thu Nov 29 2007 Paul P. Komkoff Jr <i at stingr.net> - 0.3.2-1
- new upstream version

python-pygments-0.9-2.fc9
-------------------------
* Thu Nov 29 2007 Steve 'Ashcrow' Milner <me at stevemilner.org> - 0.9-2
- Added python-setuptools as a Requires per bz#403601.
python-telepathy-0.14.0-4.fc9
-----------------------------
* Thu Nov 29 2007 Matej Cepl <mcepl at redhat.com> 0.14.0-4
- apparently some part of setup.py decided that everything in examples/
  directory, which doesn't have .py extension should be executable.

redet-8.23-3.fc9
----------------

rsyslog-1.19.11-1.fc9
---------------------
* Thu Nov 29 2007 Peter Vrabec <pvrabec at redhat.com> 1.19.11-1
- new upstream release
- add conflicts (#400671)

ruby-activerecord-1.15.6-1.fc9
------------------------------
* Thu Nov 29 2007 David Lutterkort <dlutter at redhat.com> - 1.15.6-1
- New version

ruby-activesupport-1.4.4-1.fc9
------------------------------
* Thu Nov 29 2007 David Lutterkort <dlutter at redhat.com> - 1.4.4-1
- New version

shadow-utils-2:4.0.18.1-20.fc9
------------------------------
* Thu Nov 29 2007 Peter Vrabec <pvrabec at redhat.com> 2:4.0.18.1-20
- do not create mail spool entries for system accounts (#402351)

* Thu Oct 18 2007 Peter Vrabec <pvrabec at redhat.com> 2:4.0.18.1-19
- fix timestamps when moving home dirs to another file system (#278571)

sinjdoc-0.5-5.fc9
-----------------
* Thu Nov 29 2007 Thomas Fitzsimmons <fitzsim at redhat.com> - 0.5-5
- Fix URL field.
- Fix Source0 field.
- Own sinjdoc gcj directory.
- Resolves: rhbz#246367

swig-1.3.33-1.fc9
-----------------
* Thu Nov 29 2007 Adam Tkac <atkac redhat com> 1.3.33-1
- 1.3.33
- removed swig-arch.patch because upstream will never accept
  it ("swig is not low-level")

transmission-0.94-1.fc9
-----------------------
* Thu Nov 29 2007 Denis Leroy <denis at poolshark.org> - 0.94-1
- Update to upstream 0.94

uniconvertor-1.0.0-5.fc9
------------------------
* Thu Nov 29 2007 Andy Shevchenko <andy at smile.org.ua> 1.0.0-5
- fix conflict with netatalk: rename uniconv to uniconvertor (#405011)

xorg-x11-drv-radeonhd-1.0.0-0.1.20071130git.fc9
-----------------------------------------------
* Fri Nov 30 2007 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.0.0-0.1.20071130git
- New snapshot (upstream commit 9fe776edf44c40d06e0059878df4f37391409c66 aka 1.0.0)
  - Significantly improve README and radeonhd(4) man page.
  - Add a number of connector table workarounds.
  - Several messages fixed or toned down.

xsane-0.995-2.fc9
-----------------
* Thu Nov 29 2007 Nils Philippsen <nphilipp at redhat.com> - 0.995-2
- make EULA, license dialogs be viewable on 800x600 displays

* Fri Nov 23 2007 Nils Philippsen <nphilipp at redhat.com> - 0.995-1
- version 0.995
- remove obsolete gimp2.0, medium-definitions, showeulaonce patches

* Mon Oct 15 2007 Nils Philippsen <nphilipp at redhat.com>
- explicitely enable building the gimp plugin in configure call
- reorder spec file sections

Broken deps for i386
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.i386 requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.i386 requires libaudacious.so.5
	octave-forge - 20071014-3.fc9.i386 requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.i386 requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.i386 requires perl(Wx::Wx_Exp)
	ruby-gtkmozembed - 0.16.0-16.fc9.i386 requires gecko-libs = 0:1.8.1.9
	sysprof - 1.0.8-2.fc8.i386 requires kmod-sysprof >= 0:1.0.8



Broken deps for x86_64
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.x86_64 requires libaudacious.so.5()(64bit)
	octave-forge - 20071014-3.fc9.x86_64 requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.x86_64 requires perl(Wx::Wx_Exp)
	ruby-gtkmozembed - 0.16.0-16.fc9.x86_64 requires gecko-libs = 0:1.8.1.9
	sysprof - 1.0.8-2.fc8.x86_64 requires kmod-sysprof >= 0:1.0.8



Broken deps for ppc
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.ppc requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.ppc requires libaudacious.so.5
	monodevelop - 0.17-4.fc9.ppc requires boo
	octave-forge - 20071014-3.fc9.ppc requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.ppc requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.ppc requires perl(Wx::Wx_Exp)
	ruby-gtkmozembed - 0.16.0-16.fc9.ppc requires gecko-libs = 0:1.8.1.9



Broken deps for ppc64
----------------------------------------------------------
	Miro - 0.9.9.9-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	audacious-docklet - 0.1.1-2.fc7.ppc64 requires libaudacious.so.5()(64bit)
	octave-forge - 20071014-3.fc9.ppc64 requires octave(api) = 0:api-v28
	openvrml-xembed - 0.16.7-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.9
	perl-Wx - 0.80-1.fc9.ppc64 requires perl(Wx::Wx_Exp)
	ruby-gtkmozembed - 0.16.0-16.fc9.ppc64 requires gecko-libs = 0:1.8.1.9





From che666 at gmail.com  Fri Nov 30 14:08:01 2007
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 30 Nov 2007 14:08:01 +0000
Subject: Bootup speed for F8
In-Reply-To: <e99d27470711300432y423308f3kaa016a2f88125c98@mail.gmail.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<e99d27470711300130p3d1f6732h9fe358cdd5e16c74@mail.gmail.com>
	<1196424542.3486.2.camel@jndwidescreen.lesbg.loc>
	<e99d27470711300432y423308f3kaa016a2f88125c98@mail.gmail.com>
Message-ID: <e99d27470711300608r482f416dtcc3e83554200626d@mail.gmail.com>

On Nov 30, 2007 12:32 PM, Rudolf Kastl <che666 at gmail.com> wrote:
> On Nov 30, 2007 12:09 PM, Jonathan Dieter <jdieter at gmail.com> wrote:
> > On Fri, 2007-11-30 at 09:30 +0000, Rudolf Kastl wrote:
> > > Personally i am working on straightening out initng which is part of
> > > the repos and with selinux disabled (there is a bug in current initng
> > > regarding selinux so dont use it if you want selinux enabled until the
> > > next fix shows up) from start if init to gdm in 15 seconds with
> > > NetworkManager and all that stuff enabled.
> > > I guess with a bit more hacking and optimising you could go close to 10 seconds.
> > >
> > I just gave initng a shot, and, while it started up my system extremely
> > fast, I noticed a number of failure messages on the screen and when I
> > logged in, I noticed that my CPU Frequency applet said that my CPU
> > wasn't capable of scaling (it's a laptop with a Core Duo processor and
> > three different levels of scaling).
>
> the cpuspeed script has to be fixed. actually as a workaround you can
> just use the following wrapper:
>
> #!/sbin/itype
> # This is a i file, used by initng parsed by install_service
>
> # NAME:
> # DESCRIPTION:
> # WWW:
>
> service service/cpuspeed {
>         need = system/bootmisc;
>         use = system/modules system/coldplug;
>         exec start = /etc/init.d/cpuspeed start;
>         exec stop = /etc/init.d/cpuspeed stop;
> }
>
> put the above script into:
>
> /etc/initng/service/cpuspeed.i
>
> of course that is just a workaround :D
>
> >
> > Do you want bug reports or does it need a bit more work before it can
> > replace normal init?
>
> That is a pretty much known problem and if i am not too wrong i even
> filed it into fedora bugzilla. If you encounter something and dont
> find a report for it yet please report it as many people have the
> chance then to attach a fix for it.
>
> Of course there is still alot of work to do to smooth things out. What
> should work now is getting the system to boot in any case. There is
> also lots of things to improve in the base system to make things go
> smoother. e.g. you will see that NetworkManager will fail upon bootup.
> That is because dbus daemon needs 5 seconds when it has been started
> until the service is available. The above numbers i gave for boottime
> include having a sleep 5 in the NetworkManager startup script (hacky
> workaround that needs a fix with dbus).
>
> It is definitely not ready for real end user consumption because
> things have to be checked and improved all over the place but with
> more people contributing actually that could get done rather fast in
> my eyes. It is just alot work if only a few people with not much spare
> time fix things here and there as time permits, so every small bit of
> help and patch is a nice thing to have.
>
> Yes the bootup time is very fast but i think to get broader acceptance
> more stuff has to be fixed. Actually the new version of it in the pipe
> is supposed to be able to take dbus events to get things started up
> and uses posix compliant startup scripts (note that the upcoming
> scripts are automatically generated from the ifiles it uses now so it
> makes sense to just fix the current stable release). The svn scripts
> also allow the addition of new events like beeing able to add status
> scripts/routines and configcheck etc.
>
> kind regards,
> Rudolf Kastl
>
>
> >
> > Jonathan
>
> >
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
>

as for the cpuspeed workaround... you also have to exchange the
service used for it in the runlevel file.
/etc/initng/runlevel/default.runlevel

kind regards,
Rudolf Kastl



From tcallawa at redhat.com  Fri Nov 30 14:23:46 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Nov 2007 09:23:46 -0500
Subject: DJB's software components
Message-ID: <1196432626.9238.1.camel@localhost.localdomain>

Recently, most (all?) of Dan Bernstein's software was relicensed into
the public domain.

Please hold off on packaging and submitting these packages for review
into Fedora, pending legal advice as to whether he can actually do that
or not, under US law.

Thanks,

~spot



From kevin.kofler at chello.at  Fri Nov 30 15:35:57 2007
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Nov 2007 15:35:57 +0000 (UTC)
Subject: alpha/beta software in Fedora 8?
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<1196254013.3054.58.camel@localhost.localdomain>
	<20071128075534.716563b5@redhat.com>
	<200711280848.24953.sgrubb@redhat.com>
Message-ID: <loom.20071130T151441-356@post.gmane.org>

Steve Grubb <sgrubb <at> redhat.com> writes:
> How about unreleased cvs snapshots? kdepim in F7 failed to work after a
> recent upgrade (and had been working fine) and my problem was only solved by
> upgrading to F8 which had a more recent cvs snapshot that is still buggy but

I'll sched some light on the situation of kdepim:

Basically, the problem is that the last really stable release of kdepim, 
especially KMail, was 3.5.6. When we upgraded KDE to 3.5.7, we were hit by 2 
serious regressions in KMail IMAP filtering, which made IMAP filters 
essentially unusable (one of them broke automatic filtering and one manual 
filtering). The bugs were reported upstream, but nobody knew how to fix 
automatic filtering in 3.5.7. This situation persisted for weeks. At that point 
other distributions (at least openSUSE and Kubuntu, probably more) started 
shipping kdepim from the enterprise branch, so we tried that, and found in our 
testing that it fixed the KMail IMAP regressions. However, nobody upstream knew 
how to backport whatever made it work in the enterprise branch to the regular 
3.5 branch, nor did we. So, given how many complaints we got about those IMAP 
regressions (complaints of the "you broke my KMail" type, which weren't 
unreasonable given what happened), we decided to rush the enterprise branch 
update as an F7 update so this gets finally fixed, as no other fix was in 
sight. (We considered reverting kdepim to 3.5.6, but there were other changes 
in 3.5.7 we didn't want to revert, e.g. in KitchenSync.) A few people tried the 
kdepim enterprise build before we pushed it to F7 stable updates, none of them 
reported any problems, the only reports we got about it was that it fixed the 
IMAP regressions.

The current situation is now that:
* the newer snapshot which fixes your problems will be pushed to Fedora 7 
updates (or already was? Which snapshot fixed your problems? F7 currently has 
20071013, an update to a 20071129 snapshot is being prepared) and
* the enterprise branch is planned to be merged into the regular KDE 3.5 kdepim 
branch before KDE 3.5.9, in other words, KDE 3.5.9 will ship with 
kdepim-enterprise.

> usable. Rolling back did not work. The only support I got by the Fedora 
> maintainer was telling me to report it upstream. Upstream does not support it 
> because its a cvs snapshot and not a released version.

Upstream really should support it because 1. it's scheduled to be merged into 
the next release and 2. it's being shipped by several distros.

> What do we do about that?

We wait for KDE 3.5.9, where this problem should just go away. For now, we'll 
keep pushing newer snapshots if they're needed to fix bugs.

        Kevin Kofler



From notting at redhat.com  Fri Nov 30 16:18:46 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Nov 2007 11:18:46 -0500
Subject: Bootup speed for F8
In-Reply-To: <6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<474F40C0.6050102@redhat.com>
	<Pine.LNX.4.64.0711300434100.9622@localhost.localdomain>
	<6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com>
Message-ID: <20071130161846.GA6497@nostromo.devel.redhat.com>

Mark (markg85 at gmail.com) said: 
> Here is my bootchart [1]. It's was with the normal fedora setup but
> with apache and mysql added.
> 
> In my bootchart i see something i rather don't see.. about 7 seconds
> nothing in the begin. and the overall speed seems about half of what
> could be reached... so if that was optimized:
> 
> 50 sec - 7 (pure nothing) = 43 seconds.

So, that seven seconds could be two things:

1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right

Beyond that, the two big gaps I see are when X starts - we're working
on helping fix this.

Bill



From jkeating at redhat.com  Fri Nov 30 16:22:35 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Nov 2007 11:22:35 -0500
Subject: Please, make lftp orphaned!!!
In-Reply-To: <20070914195135.GD2511@free.fr>
References: <200709141829.07383.alain.portal@free.fr>
	<20070914195135.GD2511@free.fr>
Message-ID: <20071130112235.5586d084@redhat.com>

On Fri, 14 Sep 2007 21:51:35 +0200
Patrice Dumas <pertusus at free.fr> wrote:

> I contacted the maintainer, as per the AWOL procedure. We'll see.

Has there been progress on this?  We'd like to see the package orphaned
so that somebody could pick it up.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071130/9934a30d/attachment.sig>

From tcallawa at redhat.com  Fri Nov 30 16:28:01 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Nov 2007 11:28:01 -0500
Subject: [Fedora-legal-list] DJB's software components
In-Reply-To: <1196432626.9238.1.camel@localhost.localdomain>
References: <1196432626.9238.1.camel@localhost.localdomain>
Message-ID: <1196440081.9238.7.camel@localhost.localdomain>


On Fri, 2007-11-30 at 09:23 -0500, Tom "spot" Callaway wrote:
> Recently, most (all?) of Dan Bernstein's software was relicensed into
> the public domain.
> 
> Please hold off on packaging and submitting these packages for review
> into Fedora, pending legal advice as to whether he can actually do that
> or not, under US law.

And the answer is that we are fine to pick these up. Hold lifted.

~spot



From clydekunkel7734 at cox.net  Fri Nov 30 16:10:50 2007
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Fri, 30 Nov 2007 11:10:50 -0500
Subject: rawhide report: 20071130 changes
In-Reply-To: <200711301408.lAUE8Ma3000912@porkchop.devel.redhat.com>
References: <200711301408.lAUE8Ma3000912@porkchop.devel.redhat.com>
Message-ID: <4750360A.9020806@cox.net>

Build System wrote:
> 
> kernel-2.6.24-0.57.rc3.git4.fc9
> -------------------------------
> * Thu Nov 29 2007 Dave Jones <davej at redhat.com>
> - 2.6.24-rc3-git4
> 
> * Thu Nov 29 2007 John W. Linville <linville at redhat.com>
> - Resync wireless bits headed for 2.6.25
> 
> * Thu Nov 29 2007 Dave Airlie <airlied at linux.ie>
> - update drm-mm-git.patch to fix 64-bit truncation
> > 
> 

Still won't boot on x86 system, since 2.6.24-0.42.rc3.git1.fc9

BZ 403671.  Maybe 402061 is related.

-- 
Regards,

Old Fart
(my reply-to address is "munged" to defeat spambots)



From ajackson at redhat.com  Fri Nov 30 17:57:45 2007
From: ajackson at redhat.com (Adam Jackson)
Date: Fri, 30 Nov 2007 12:57:45 -0500
Subject: Bootup speed for F8
In-Reply-To: <20071130161846.GA6497@nostromo.devel.redhat.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<474F40C0.6050102@redhat.com>
	<Pine.LNX.4.64.0711300434100.9622@localhost.localdomain>
	<6e24a8e80711300058p47d509fdk2ea0930155165d44@mail.gmail.com>
	<20071130161846.GA6497@nostromo.devel.redhat.com>
Message-ID: <1196445465.22277.60.camel@localhost.localdomain>


On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote:
> Mark (markg85 at gmail.com) said: 
> > Here is my bootchart [1]. It's was with the normal fedora setup but
> > with apache and mysql added.
> > 
> > In my bootchart i see something i rather don't see.. about 7 seconds
> > nothing in the begin. and the overall speed seems about half of what
> > could be reached... so if that was optimized:
> > 
> > 50 sec - 7 (pure nothing) = 43 seconds.
> 
> So, that seven seconds could be two things:
> 
> 1) bootchart weirdness (as it's from when bootchart starts)
> 2) hotplug issues with a driver in the initrd not initializing right
> 
> Beyond that, the two big gaps I see are when X starts - we're working
> on helping fix this.

I hit most of the low-hanging fruit for X startup performance already in
rawhide.  The rest is... harder.

- ajax



From martin at marquesminen.com.ar  Fri Nov 30 18:57:07 2007
From: martin at marquesminen.com.ar (Martin Marques)
Date: Fri, 30 Nov 2007 15:57:07 -0300
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in	Fedora
 8?]
In-Reply-To: <20071129202959.GA9414@nostromo.devel.redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>
	<fijuhr$20o$1@ger.gmane.org>	<200711281133.19824.sgrubb@redhat.com>	<474DD09B.8040907@redhat.com>
	<20071129202959.GA9414@nostromo.devel.redhat.com>
Message-ID: <47505D03.7020202@marquesminen.com.ar>

Bill Nottingham escribi?:
> Petr Machata (pmachata at redhat.com) said: 
>> Steve Grubb wrote:
>>> kdepim-enterprise-svn20070926.tar.bz2
>> As a side note, I always wondered why to use date in the release tag of
>> package, whose sources come from non-cvs versioning system.  For svn, in
>> my opinion, it would make more sense to use the tree revision number;
>> for git, similarly, sha1 id of the tree.
> 
> Well, git<date> sorts sanely. git<sha1> does not. Comments in the spec
> (or similar) might help with this.

git<date> from where? Remember that git is distributed and unless you 
have a centralized copy git<date> can have more then one copy.

IMHO, I've seen many cvs<date>, svn<date>, etc. that it'a when there 
isn't a real version numbering (or patches come from svn, cvs, hg, git, 
instead of new tarballs).



From jkeating at redhat.com  Fri Nov 30 19:08:12 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Nov 2007 14:08:12 -0500
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in
 Fedora 8?]
In-Reply-To: <47505D03.7020202@marquesminen.com.ar>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com> <fijuhr$20o$1@ger.gmane.org>
	<200711281133.19824.sgrubb@redhat.com>
	<474DD09B.8040907@redhat.com>
	<20071129202959.GA9414@nostromo.devel.redhat.com>
	<47505D03.7020202@marquesminen.com.ar>
Message-ID: <20071130140812.4199df15@redhat.com>

On Fri, 30 Nov 2007 15:57:07 -0300
Martin Marques <martin at marquesminen.com.ar> wrote:

> git<date> from where? Remember that git is distributed and unless you 
> have a centralized copy git<date> can have more then one copy.
> 
> IMHO, I've seen many cvs<date>, svn<date>, etc. that it'a when there 
> isn't a real version numbering (or patches come from svn, cvs, hg,
> git, instead of new tarballs).

Wrong directions.  <date><scm>

Please read the guideline.
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#SnapshotPackages

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071130/bba18b21/attachment.sig>

From pertusus at free.fr  Fri Nov 30 19:33:35 2007
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Nov 2007 20:33:35 +0100
Subject: Please, make lftp orphaned!!!
In-Reply-To: <20071130112235.5586d084@redhat.com>
References: <200709141829.07383.alain.portal@free.fr>
	<20070914195135.GD2511@free.fr>
	<20071130112235.5586d084@redhat.com>
Message-ID: <20071130193335.GA2836@free.fr>

On Fri, Nov 30, 2007 at 11:22:35AM -0500, Jesse Keating wrote:
> On Fri, 14 Sep 2007 21:51:35 +0200
> Patrice Dumas <pertusus at free.fr> wrote:
> 
> > I contacted the maintainer, as per the AWOL procedure. We'll see.
> 
> Has there been progress on this?  We'd like to see the package orphaned
> so that somebody could pick it up.

The maintainer finally responded and did the most urgent stuff. So he
isn't AWOL. If I recall well, however there is another maintainer now.

--
Pat



From martin at marquesminen.com.ar  Fri Nov 30 19:37:58 2007
From: martin at marquesminen.com.ar (Martin Marques)
Date: Fri, 30 Nov 2007 16:37:58 -0300
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <20071130140812.4199df15@redhat.com>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>
	<fijuhr$20o$1@ger.gmane.org>	<200711281133.19824.sgrubb@redhat.com>	<474DD09B.8040907@redhat.com>	<20071129202959.GA9414@nostromo.devel.redhat.com>	<47505D03.7020202@marquesminen.com.ar>
	<20071130140812.4199df15@redhat.com>
Message-ID: <47506696.40108@marquesminen.com.ar>

Jesse Keating escribi?:
> On Fri, 30 Nov 2007 15:57:07 -0300
> Martin Marques <martin at marquesminen.com.ar> wrote:
> 
>> git<date> from where? Remember that git is distributed and unless you 
>> have a centralized copy git<date> can have more then one copy.
>>
>> IMHO, I've seen many cvs<date>, svn<date>, etc. that it'a when there 
>> isn't a real version numbering (or patches come from svn, cvs, hg,
>> git, instead of new tarballs).
> 
> Wrong directions.  <date><scm>

OK, why not <date><scm><sha1-hash>

The hash lets you identify the git or hg version uniquely.

With cvs or svn there wouldn't be any hash.



From tcallawa at redhat.com  Fri Nov 30 19:40:17 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Nov 2007 14:40:17 -0500
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in
	Fedora 8?]
In-Reply-To: <47506696.40108@marquesminen.com.ar>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>
	<200711280848.24953.sgrubb@redhat.com> <fijuhr$20o$1@ger.gmane.org>
	<200711281133.19824.sgrubb@redhat.com>	<474DD09B.8040907@redhat.com>
	<20071129202959.GA9414@nostromo.devel.redhat.com>
	<47505D03.7020202@marquesminen.com.ar>
	<20071130140812.4199df15@redhat.com>
	<47506696.40108@marquesminen.com.ar>
Message-ID: <1196451617.3432.1.camel@localhost.localdomain>


On Fri, 2007-11-30 at 16:37 -0300, Martin Marques wrote:
> Jesse Keating escribi?:
> > On Fri, 30 Nov 2007 15:57:07 -0300
> > Martin Marques <martin at marquesminen.com.ar> wrote:
> > 
> >> git<date> from where? Remember that git is distributed and unless you 
> >> have a centralized copy git<date> can have more then one copy.
> >>
> >> IMHO, I've seen many cvs<date>, svn<date>, etc. that it'a when there 
> >> isn't a real version numbering (or patches come from svn, cvs, hg,
> >> git, instead of new tarballs).
> > 
> > Wrong directions.  <date><scm>
> 
> OK, why not <date><scm><sha1-hash>
> 
> The hash lets you identify the git or hg version uniquely.
> 
> With cvs or svn there wouldn't be any hash.

This is exactly what the guidelines say. Is anyone reading them? :P

~spot



From martin at marquesminen.com.ar  Fri Nov 30 19:51:07 2007
From: martin at marquesminen.com.ar (Martin Marques)
Date: Fri, 30 Nov 2007 16:51:07 -0300
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in	Fedora
 8?]
In-Reply-To: <1196451617.3432.1.camel@localhost.localdomain>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>
	<fijuhr$20o$1@ger.gmane.org>	<200711281133.19824.sgrubb@redhat.com>	<474DD09B.8040907@redhat.com>	<20071129202959.GA9414@nostromo.devel.redhat.com>	<47505D03.7020202@marquesminen.com.ar>	<20071130140812.4199df15@redhat.com>	<47506696.40108@marquesminen.com.ar>
	<1196451617.3432.1.camel@localhost.localdomain>
Message-ID: <475069AB.9060805@marquesminen.com.ar>

Tom "spot" Callaway escribi?:
> On Fri, 2007-11-30 at 16:37 -0300, Martin Marques wrote:
>> OK, why not <date><scm><sha1-hash>
>>
>> The hash lets you identify the git or hg version uniquely.
>>
>> With cvs or svn there wouldn't be any hash.
> 
> This is exactly what the guidelines say. Is anyone reading them? :P

Sorry Tom. Must be the weekend that's starting, and the beer I had with 
my lunch. :-)



From loganjerry at gmail.com  Fri Nov 30 20:19:27 2007
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 30 Nov 2007 13:19:27 -0700
Subject: First-time mock user
Message-ID: <870180fe0711301219k399683cbo60308e83faed7508@mail.gmail.com>

I'm trying to use mock for the first time in order to do a package
review.  I've hit a few snags that I thought I should point out on
this list.  Let me know what I can do to help resolve them.

First, the SHOULD item on this page:
  http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
that refers to mock should probably link to this page:
  http://fedoraproject.org/wiki/PackageMaintainers/MockTricks
I have edit rights on the wiki, so if nobody objects I can make that
change.  As it was, I had to hunt for information on how to use mock.

So I read the MockTricks page and the mock man page.  MockTricks tells
me to use '-r <config>' to select a config file.  The mock man page
says that if you don't select one, you get whatever
/etc/mock/default.cfg links to.  That's great, except that there is no
such link as /etc/mock/default.cfg after installing mock.  Should
there be?  If not, the text on the MockTricks page should perhaps be
expanded a bit to note this and explain why not.

Next I created the "build" user as described on the MockTricks page.
Then I did "su - build", just like it says to do.  It wants a
password.  The null password doesn't work.  My password doesn't work.
Fortunately, I am root on my box, so I can "su -" and then "su -
build", but what is supposed to work here?

I also noted that MockTricks says to do "mock rebuild <SRPM>", but the
mock man page says that usage is deprecated.  It's supposed to be
"mock --rebuild <SRPM>" now.

So I kicked off the mock build ... and setroubleshoot pops up to tell
me about AVC denials.  These are NOT the SELinux problems described on
the MockTricks page.  I got the following:

1) /usr/sbin/groupadd (groupadd_t) cannot "write" to /dev/null (var_lib_t).
2) /usr/sbin/groupadd (groupadd_t) cannot "ioctl" to /dev/null (var_lib_t).
3) /usr/sbin/useradd (useradd_t) cannot "ioctl" to /dev/null (var_lib_t).
4) /usr/sbin/useradd (useradd_t) cannot "read write" to (var_log_t).
5) /usr/sbin/useradd (useradd_t) cannot "write" to /dev/null (var_lib_t).

I just updated to selinux-policy-3.0.8-58.fc8 shortly before
installing and running mock.  Are these failures expected?  If so,
MockTricks should warn me about them.  If not, against what do I file
a bug?

So the mock build failed.  I expected that, since I was pretty sure I
had identified a missing BuildRequires.  I went to the log files to
verify that my guess was right, and found that build.log is empty.
OK, so I'll try root.log.  No sign of a missing BuildRequires there;
but I do see some scary looking stuff:

2007-11-30 12:35:46,634 - DEBUG util.py, Line: 234:  tar:
./usr/lib/locale/locale-archive: file changed as we read it
2007-11-30 12:35:46,638 - DEBUG trace_decorator.py, Line: 27:
EXCEPTION: Command(tar czf
/var/lib/mock/cache/fedora-8-x86_64/root_cache/cache.tar.gz -C
/var/lib/mock/fedora-8-x86_64/root .) failed. See logs for output.
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/mock/trace_decorator.py",
line 24, in trace
    result = f(*args, **kw)
  File "/usr/lib/python2.5/site-packages/mock/util.py", line 260, in do
    raise mock.exception.Error, "Command(%s) failed. See logs for
output." % command
Error: Command(tar czf
/var/lib/mock/cache/fedora-8-x86_64/root_cache/cache.tar.gz -C
/var/lib/mock/fedora-8-x86_64/root .) failed. See logs for output.
2007-11-30 12:35:46,648 - DEBUG trace_decorator.py, Line: 30:  LEAVE
do --> EXCEPTION RAISED

[repeats several times with the word after "LEAVE" changing each time]

When I try that tar command myself, I get this:

[build at localhost ~]$ tar czf
/var/lib/mock/cache/fedora-8-x86_64/root_cache/cache.tar.gz -C
/var/lib/mock/fedora-8-x86_64/root .
tar: ./root: Cannot open: Permission denied
tar: ./sbin/unix_update: Cannot open: Permission denied
tar: ./lib64/dbus-1/dbus-daemon-launch-helper: Cannot open: Permission denied
tar: ./usr/sbin/groupmod: Cannot open: Permission denied
tar: ./usr/sbin/groupdel: Cannot open: Permission denied
tar: ./usr/sbin/userdel: Cannot open: Permission denied
tar: ./usr/sbin/groupadd: Cannot open: Permission denied
tar: ./usr/sbin/tzdata-update: Cannot open: Permission denied
tar: ./usr/sbin/groupmems: Cannot open: Permission denied
tar: ./usr/sbin/build-locale-archive: Cannot open: Permission denied
tar: ./usr/sbin/usermod: Cannot open: Permission denied
tar: ./usr/sbin/useradd: Cannot open: Permission denied
tar: ./usr/sbin/glibc_post_upgrade.x86_64: Cannot open: Permission denied
tar: ./usr/libexec/pt_chown: Cannot open: Permission denied
tar: ./usr/bin/chfn: Cannot open: Permission denied
tar: ./usr/bin/chsh: Cannot open: Permission denied
tar: ./etc/securetty: Cannot open: Permission denied
tar: ./etc/.pwd.lock: Cannot open: Permission denied
tar: ./etc/security/opasswd: Cannot open: Permission denied
tar: ./etc/group-: Cannot open: Permission denied
tar: ./etc/libaudit.conf: Cannot open: Permission denied
tar: ./etc/default/useradd: Cannot open: Permission denied
tar: ./etc/passwd-: Cannot open: Permission denied
tar: ./var/log/maillog: Cannot open: Permission denied
tar: ./var/log/secure: Cannot open: Permission denied
tar: ./var/log/tallylog: Cannot open: Permission denied
tar: ./var/log/btmp: Cannot open: Permission denied
tar: ./var/log/spooler: Cannot open: Permission denied
tar: ./var/log/faillog: Cannot open: Permission denied
tar: ./var/log/messages: Cannot open: Permission denied
tar: ./var/cache/ldconfig: Cannot open: Permission denied
tar: ./var/spool/mail/vcsa: Cannot open: Permission denied
tar: ./var/spool/mail/dbus: Cannot open: Permission denied
tar: ./var/spool/mail/rpm: Cannot open: Permission denied
tar: Error exit delayed from previous errors

Sure enough, the root directory has 0750 permissions and is owned by
root:root, so my build:mock user cannot read it.  Likewise with the
other directories on that list.  How is this supposed to work?

I hope we can work together to make this less confusing and
frustrating for the next mock newbie.  Regards,
-- 
Jerry James
http://loganjerry.googlepages.com/



From tcallawa at redhat.com  Fri Nov 30 20:33:10 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Nov 2007 15:33:10 -0500
Subject: First-time mock user
In-Reply-To: <870180fe0711301219k399683cbo60308e83faed7508@mail.gmail.com>
References: <870180fe0711301219k399683cbo60308e83faed7508@mail.gmail.com>
Message-ID: <1196454790.3432.19.camel@localhost.localdomain>


On Fri, 2007-11-30 at 13:19 -0700, Jerry James wrote:
> I'm trying to use mock for the first time in order to do a package
> review.  I've hit a few snags that I thought I should point out on
> this list.  Let me know what I can do to help resolve them.
> 
> First, the SHOULD item on this page:
>   http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
> that refers to mock should probably link to this page:
>   http://fedoraproject.org/wiki/PackageMaintainers/MockTricks
> I have edit rights on the wiki, so if nobody objects I can make that
> change.  As it was, I had to hunt for information on how to use mock.

Unfortunately, the Packaging/ tree is ACL restricted, so you can't make
that change. However, I agree that it is a worthy addition, so I've made
it. :)

~spot



From jcm at redhat.com  Fri Nov 30 20:36:14 2007
From: jcm at redhat.com (Jon Masters)
Date: Fri, 30 Nov 2007 15:36:14 -0500
Subject: Bootup speed for F8
In-Reply-To: <1196375699.3036.9.camel@dimi.lattica.com>
References: <1196375699.3036.9.camel@dimi.lattica.com>
Message-ID: <1196454974.3415.160.camel@jcmlaptop>

Yo,

Just to chime in here...one of the guys tells me he has a patch to
module-init-tools that shaves about a second or so off boot. I'm ok with
taking this kind of stuff, and encourage it! But I don't think modprobe
is really where we're spending all of our time on boot.

Jon.




From a.badger at gmail.com  Fri Nov 30 20:40:16 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 30 Nov 2007 12:40:16 -0800
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in	Fedora
 8?]
In-Reply-To: <47505D03.7020202@marquesminen.com.ar>
References: <20071127022448.GB24257@angus.ind.WPI.EDU>	<200711280848.24953.sgrubb@redhat.com>	<fijuhr$20o$1@ger.gmane.org>	<200711281133.19824.sgrubb@redhat.com>	<474DD09B.8040907@redhat.com>	<20071129202959.GA9414@nostromo.devel.redhat.com>
	<47505D03.7020202@marquesminen.com.ar>
Message-ID: <47507530.4040404@gmail.com>

Martin Marques wrote:
> Bill Nottingham escribi?:
>> Petr Machata (pmachata at redhat.com) said:
>>> Steve Grubb wrote:
>>>> kdepim-enterprise-svn20070926.tar.bz2
>>> As a side note, I always wondered why to use date in the release tag of
>>> package, whose sources come from non-cvs versioning system.  For svn, in
>>> my opinion, it would make more sense to use the tree revision number;
>>> for git, similarly, sha1 id of the tree.
>>
>> Well, git<date> sorts sanely. git<sha1> does not. Comments in the spec
>> (or similar) might help with this.
> 
> git<date> from where? Remember that git is distributed and unless you 
> have a centralized copy git<date> can have more then one copy.
> 
This actually is a reasonable point but you might not like the answer 
:-).  Git is distributed but that doesn't mean we should be pulling from 
any git tree.  It doesn't even mean that we should be pulling from 
several different git trees.  In almost all cases there should be one 
upstream git tree that upstream either designates as canonical or one 
that we decide it would be sane to pull from for a reasonable amount of 
time (with reasonable amount purposely left vague so maintainers have 
leeway here.)

Once again, though, the information in the release field after the 
mandatory integer at the beginning is for the end user to indicate the 
age of the upstream pull.  Git hashes and other ids that aren't either 
well known to end users or have some bearing on age (incrementing 
integers show some idea of age, a checksum does not) don't fit this 
criteria.  They belong in the spec file as part of a comment on how to 
checkout the sources but are of limited use in the release tag itself.

-Toshio



From mmcgrath at redhat.com  Fri Nov 30 20:53:43 2007
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 30 Nov 2007 14:53:43 -0600
Subject: Build Failures November 30 2007
Message-ID: <47507857.7060304@redhat.com>

If you experienced build failures today with:

Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/dist-f9-build-84928-10845/root install buildsys-build
Error: Missing Dependency: kernel-headers >= 2.2.1 is needed by package glibc-headers
Error: Missing Dependency: kernel-headers is needed by package glibc-headers


Please re-submit the build.


    -Mike



From markg85 at gmail.com  Fri Nov 30 20:57:52 2007
From: markg85 at gmail.com (Mark)
Date: Fri, 30 Nov 2007 21:57:52 +0100
Subject: Bootup speed for F8
In-Reply-To: <1196454974.3415.160.camel@jcmlaptop>
References: <1196375699.3036.9.camel@dimi.lattica.com>
	<1196454974.3415.160.camel@jcmlaptop>
Message-ID: <6e24a8e80711301257y33d0f54bi7863744dd532e2e4@mail.gmail.com>

2007/11/30, Jon Masters <jcm at redhat.com>:
> Yo,
>
> Just to chime in here...one of the guys tells me he has a patch to
> module-init-tools that shaves about a second or so off boot. I'm ok with
> taking this kind of stuff, and encourage it! But I don't think modprobe
> is really where we're spending all of our time on boot.
>
> Jon.

Most time seems to be in kernel booting, udev and x starting (+gdm)

@Adam Jackson
can you make that patched X version available in Fedora 8 as a
unstable package? or just somewhere that it doesn't get in the
official repository? i would like to give it a spin (without
installing rawhide if possible)



From a.badger at gmail.com  Fri Nov 30 21:05:39 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 30 Nov 2007 13:05:39 -0800
Subject: Versioning svn checkouts [Was: Re: alpha/beta software in Fedora
 8?]
In-Reply-To: <474FD704.6000106@redhat.com>
References: <23521.192.54.193.53.1196338126.squirrel@rousalka.dyndns.org>	<474EB4D4.2040300@redhat.com>	<474EE11D.3010608@gmail.com>
	<474FD704.6000106@redhat.com>
Message-ID: <47507B23.3060500@gmail.com>

Petr Machata wrote:

> Thanks for clarification, that makes sense.  Interestingly enough, and
> quite contrary to your argument, naming guidelines allow the release ID
> or partial hash to be appended to the date portion of the release tag.
> 
Yes, maintainers wanted to add a hash there despite having the 
information in the spec file.  Since svn is allowed to put the release 
id in that space (since it can be used to establish an age) FPC decided 
that allowing the partial hash was a reasonable compromise.

-Toshio



From myfedora at richip.dhs.org  Fri Nov 30 21:16:38 2007
From: myfedora at richip.dhs.org (Richi Plana)
Date: Fri, 30 Nov 2007 14:16:38 -0700
Subject: Development Docs (Rhythmbox, in particular)
Message-ID: <1196457398.17157.16.camel@localhost6.localdomain6>

Hi,

Now that we have a Developer spin, perhaps package maintainers can give
some thought to packaging development docs as well. Rhythmbox,
specifically, deletes all the gtk-doc files. Perhaps now we can package
them in rhythmbox-devel-doc or something as well as sample plugin code?
Things that developers would find useful.
--

Richi Plana



From bernie at codewiz.org  Fri Nov 30 23:44:41 2007
From: bernie at codewiz.org (Bernardo Innocenti)
Date: Fri, 30 Nov 2007 18:44:41 -0500
Subject: kde-4.0(rc1) hitting rawhide Dec 1-7
In-Reply-To: <474C6891.2090007@math.unl.edu>
References: <474C6891.2090007@math.unl.edu>
Message-ID: <4750A069.7040401@codewiz.org>

Rex Dieter wrote:

> Now that the KDE 4.0 RC1 is available (and development churn has
> slowed), the KDE SIG will be working towards incorporating as much of
> kde-4.0 (rc1) into rawhide the week of Dec 1-7.  The gory outline of
> making all of this work are detailed on
> http://fedoraproject.org/wiki/Releases/FeatureKDE4

Sweet!


> The challenge will be replacing the current kde3-based
> desktop with a kde4-based one, while at the same time still providing a
> kde3 development platform (ie, so one can still build/run kde3
> applications).

Projecting the current stability of KDE4 ahead, it seems more
cautious to leave the two parallel installable for some time.

I've always been an early adopter, but this time I don't feel
like switching so soon.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/



From tcallawa at redhat.com  Fri Nov 30 20:28:55 2007
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Nov 2007 15:28:55 -0500
Subject: [ANNOUNCE] Aurora SPARC Linux Build 2.99 (Beta 2 for 3.0)
Message-ID: <1196454535.3432.18.camel@localhost.localdomain>

The Aurora SPARC Linux project is proud to finally drag Build 2.99 
kicking and screaming into the light.

Took us long enough, huh? Beta 1 was in April. Barring some sort of miracle,
Aurora 3.0 will be the last sparc32 supporting release. So, if you're still
clinging to your sparc32 systems, please test this beta out. After 3.0, 
we're not even going to think about sparc32 (unless well bribed).

This is a BETA release, for what will become 3.0. In fact, we're going to 
give this release a short period of time to uncover any really nasty bugs,
and then we're going to call it 3.0.

Here are some of the key features in this release:

- Fedora Core 6 based tree of packages (some things are newer)
- Support for Niagara hardware (Sun T1000, T2000)
- gcc-4.1.1
- gnome 2.16
- KDE 3.5.5
- kernel 2.6.23.1 (with patches!)
- Full support for LVM at installtime (no more crashes!)

Like all BETAs, this one has some bugs. Here are the ones we know about:

- Installs on sparc32 hardware usually work, but they're very touchy.
If you're installing to a sparc32 system, use text mode. If it fails to find
the cdrom, try: linux expert text
- Smartd seems to make systems using the esp.ko SCSI driver very very
unhappy. If your system is esp based, we highly recommend that you
disable the smartd service in single-user before fully booting after
install.
- cpuspeed seems to hardlock some sparc64 systems (the V120 is an
example). Again, if your system locks up at cpuspeed, we suggest that
you disable the cpuspeed service in single-user mode.
- Parted was doing incorrect things in previous Aurora releases. This is
the source of the odd cylinder-head error messages that have popped up
in the past. Sometimes these error messages are harmless, sometimes they
are not. Either way, you can get rid of them by booting to rescue mode,
then, at the shell prompt, run:

dd if=/dev/zero of=/dev/$DRIVE bs=1M count=1

Where $DRIVE is your harddrive, likely sda or hda.

Then, reinstall. The errors will vanish (for good!). Be aware that
running this command will wipe out all the data and partitions on that
disk.

- E10000 systems are not yet supported. :/
- Most IDE based SPARC systems need to boot with ide=nodma.
Specifically, Ultra 5/10 and Sun Blade 100s need this for sure.
- Systems that boot off qlogic attached disks are not supported, because 
there is no working firmware loader in anaconda, and the qlogic driver 
needs firmware.
- The graphical installer on some sparc32 systems doesn't enable the mouse.
Post installation, the mouse works fine in X.
- We haven't spun the security updates into this yet. We'll do this before 
3.0 final.
- Upgrades from 2.98 might not work. We found more errors in how we were
handling partitions at installtime, and unfortunately, the best way to fix
them is to destroy the partition tables entirely and reinstall from scratch.

If you find other bugs, please report them at
http://bugzilla.auroralinux.org/

If you install 2.99 on a system, success or fail, we wanna know! Please
take a moment and add your system to the table on our wiki:
http://wiki.auroralinux.net/wiki/Build2.99TestMatrix

You can download the files from our primary location:
ftp://ibiblio.org/pub/linux/distributions/aurora/build-2.99
http://distro.ibiblio.org/pub/linux/distributions/aurora/build-2.99

The mirror sites should pick it up in a few hours/days, depending on
whether they still remember that we exist. :)

Many thanks to the folks in #aurora on freenode for their help in
getting this release out.

~spot

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce