Re: [HALL-MONITORED] Update threads are now hall-monitored

[Hans de Goede]

Hi,

On 03/03/2010 10:30 PM, Doug Ledford wrote:
> On 03/03/2010 02:27 PM, Tom "spot" Callaway wrote:
>> Okay. This has gone on long enough. The signal is gone from the
>> following threads:
>
> The signal is not entirely gone, although it is getting weaker.
>
>> * FESCo wants to ban direct stable pushes in Bodhi (urgent call forfeedback)
>> * Worthless updates
>> * Refining the update queues/process
>>
>> Accordingly, I'm marking those threads as Hall-Monitored. Please stop
>> posting in them. If you have a concrete suggestion on how to improve
>> Fedora updates, please write it in a wiki page, open a FESCo trac
>> ticket, and they will consider it.
>
> The problem is that having a concrete suggestion of how to improve
> fedora updates requires knowing whether we want a more stable update
> cycle or a more semi-rolling update style.  It would be easy for us to
> carte blanch hand down an edict on this, but that would also be wrong.
> This is a community driven distribution, and by my count the number of
> people that stood up in favor of semi-rolling updates was not that
> different from the number of people that stood up for stable updates (I
> have something like 4 for semi-rolling and 6 for stable, but many people
> didn't make their preferences perfectly clear, and this count is from my
> admittedly worthless memory of those that were explicit in their desires).
>

I think the whole "stable update cycle" versus "semi-rolling update style" is
too black and white. For core packages / major desktop packages clearly a
"stable update cycle" is the right thing to do.

But for packages which are more nice packages, the right thing to do may vary.
What for example for a package which is not only added recently to Fedora,
but came into existence recently in general. There might be some new
upstream releases there which are not bugfix only but still very good to
have (think pre-alpha -> alpha -> beta steps).

Another example against having a hardcoded "stable update cycle" is multiplayer
games. In quite a few online gaming communities, most of the community moves
over to the latest release once it is sanctioned stable by upstream. If
the client <-> server version need to be in sync (which they often do because
they need the exact same maps), then this means that our "stable" version
in F-released might become worthless pretty quickly as there are no or very
little "stable" version servers available to play on.

Also some upstreams do much much better QA then others, or are in general
not as fast moving as others. In these cases it might make sense to do
a "semi-rolling update style" for these packages, even if the upstream
releases are not purely bugfix releases.

So I think in the end this should preferably be left to the maintainer. And if
FESco decides that a "stable update cycle" is what we want, can they *please*
make this a not one size does not fits all policy. I would like to see a split
somewhere, say included in standard  install,
versus the rest. With less strict checks at the *tool* level for the rest ?

The idea here is that the policy prescribes a "stable update cycle", but leaves
room for maintainers to make exceptions when they believe they have good reasons
to do so, and that the tools (bodhi, autoqa) allow for maintainers for
packages outside the "core" group to override the tool, without needing FESco
/ rel-eng permission first.

Regards,

Hans
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Worthless updates

[Jaroslav Reznik]

On Wednesday 03 March 2010 20:14:16 Peter Jones wrote:
> On 03/03/2010 01:17 PM, Kevin Kofler wrote:
> > Mathieu Bridon wrote:
> >> In the end, I think the question is not about giving users what users
> >> want (be it frequent updates or stalled releases), but giving users
> >> what we see as a better deal for them.
> > 
> > I think wanting to decide for your users is a really arrogant attitude.
> 
> But that's exactly what you do with rebases during a stable release.

Most users wants it (at least active users - who tell us what they want) and 
even most users use Fedora because of it!

Jaroslav
-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Till Maas]

On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:

> Great script here's a small set of changes to have easy-karma use yum as a 
> module 
> instead of via subprocess.
> 
> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch

Thank you, I will integrate it later today, when I set up a git repo. Is
there a way to restrict the yum results using the time the packages were
installed?

> if I get a chance I'll see if I can figure out how to use the bodhi module 
> at the end so it doesn't have to use any subprocess calls at all.

This is pretty straight forward, I will do this later today, too.

Regards
Till


pgpdc26Tt0Hjk.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Richard Hughes]

On 3 March 2010 21:45, Tom "spot" Callaway  wrote:
> Here are the list of changes to the Fedora Packaging Guidelines:

I've done some updates, and now rpmlint reports:

argyllcms.spec: W: no-cleaning-of-buildroot %install
argyllcms.spec: W: no-buildroot-tag

Does rpmlint need an update?

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Problem with openoffice yum update

[Quentin Armitage]

I cannot do a yum update of openoffice on F-13 RC4 with the
updates-testing repo enabled. There seems to be an inconsistency around
the dep checking, with it wanting both the old and new versions of
openoffice.org-langpack-en. It is attempting to update from version
3.2.0-12.8.fc13.i686 to 3.2.0-12.9.fc13.i686.

I'm happy to report this in bugzilla, but I'm not sure what I should
report it against.

Below is the output of the yum update.

Quentin Armitage

[r...@delilah Downloads]# yum update openoffice-core
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_GB to language list
Setting up Update Process
No Match for argument: openoffice-core
No package openoffice-core available.
No Packages marked for Update
[r...@delilah Downloads]# yum update openoffice.org
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_GB to language list
Setting up Update Process
No Match for argument: openoffice.org
No package openoffice.org available.
No Packages marked for Update
[r...@delilah Downloads]# yum update openoffice.org-core
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_GB to language list
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-brand-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-math-core-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-writer-core-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-impress-core-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-graphicfilter-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-xsltfilter-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-langpack-en-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-draw-core-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-core = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-calc-core-3.2.0-12.8.fc13.i686
---> Package openoffice.org-core.i686 1:3.2.0-12.9.fc13 set to be
updated
--> Processing Dependency: openoffice.org-opensymbol-fonts =
1:3.2.0-12.9.fc13 for package:
1:openoffice.org-core-3.2.0-12.9.fc13.i686
--> Processing Dependency: openoffice.org-ure = 1:3.2.0-12.9.fc13 for
package: 1:openoffice.org-core-3.2.0-12.9.fc13.i686
--> Running transaction check
--> Processing Dependency: openoffice.org-brand = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-writer-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-brand = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-math-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-brand = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-calc-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-brand = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-impress-3.2.0-12.8.fc13.i686
--> Processing Dependency: openoffice.org-brand = 1:3.2.0-12.8.fc13 for
package: 1:openoffice.org-draw-3.2.0-12.8.fc13.i686
---> Package openoffice.org-brand.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-calc-core.i686 1:3.2.0-12.9.fc13 set to be
updated
--> Processing Dependency: openoffice.org-draw-core = 1:3.2.0-12.8.fc13
for package: 1:openoffice.org-pdfimport-3.2.0-12.8.fc13.i686
---> Package openoffice.org-draw-core.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-graphicfilter.i686 1:3.2.0-12.9.fc13 set to
be updated
--> Processing Dependency: openoffice.org-impress-core =
1:3.2.0-12.8.fc13 for package:
1:openoffice.org-presenter-screen-3.2.0-12.8.fc13.i686
---> Package openoffice.org-impress-core.i686 1:3.2.0-12.9.fc13 set to
be updated
---> Package openoffice.org-langpack-en.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-math-core.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-opensymbol-fonts.noarch 1:3.2.0-12.9.fc13
set to be updated
---> Package openoffice.org-ure.i686 1:3.2.0-12.9.fc13 set to be updated
---> Package openoffice.org-writer-core.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-xsltfilter.i686 1:3.2.0-12.9.fc13 set to be
updated
--> Running transaction check
---> Package openoffice.org-calc.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-draw.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-impress.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-math.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-pdfimport.i686 1:3.2.0-12.9.fc13 set to be
updated
---> Package openoffice.org-presenter-screen.i686 1:3.2.0-12.9.fc13 set

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Kalev Lember]

On 03/04/2010 12:07 PM, Richard Hughes wrote:
> On 3 March 2010 21:45, Tom "spot" Callaway  wrote:
>> Here are the list of changes to the Fedora Packaging Guidelines:
>
> I've done some updates, and now rpmlint reports:
>
> argyllcms.spec: W: no-cleaning-of-buildroot %install
> argyllcms.spec: W: no-buildroot-tag
>
> Does rpmlint need an update?

Also, should rpmdev-newspec templates get an update to not include 
buildroot tag?

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem with openoffice yum update

[Frank Murphy]

On 04/03/10 10:17, Quentin Armitage wrote:
> I cannot do a yum update of openoffice on F-13 RC4 with the
> updates-testing repo enabled. There seems to be an inconsistency around
> the dep checking, with it wanting both the old and new versions of
> openoffice.org-langpack-en. It is attempting to update from version
> 3.2.0-12.8.fc13.i686 to 3.2.0-12.9.fc13.i686.
>
> I'm happy to report this in bugzilla, but I'm not sure what I should
> report it against.
>
--snipped--

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

-- 
Regards,

Frank Murphy
UTF_8 Encoded
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem with openoffice yum update

[Kalev Lember]

On 03/04/2010 12:17 PM, Quentin Armitage wrote:
> I cannot do a yum update of openoffice on F-13 RC4 with the
> updates-testing repo enabled. There seems to be an inconsistency around
> the dep checking, with it wanting both the old and new versions of
> openoffice.org-langpack-en. It is attempting to update from version
> 3.2.0-12.8.fc13.i686 to 3.2.0-12.9.fc13.i686.

I have recently experienced various upgrade problems which were fixed by 
cleaning yum metadata. Apparently there's "metadata_expire=7d" set in 
F-13 fedora.repo, but not in fedora-updates-testing repo. That makes yum 
skip metadata refreshes in one repo, whereas the other one gets updated.

Maybe your problem can also be solved by "yum clean metadata"?

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Rahul Sundaram]

On 03/04/2010 03:37 PM, Richard Hughes wrote:
> On 3 March 2010 21:45, Tom "spot" Callaway  wrote:
>   
>> Here are the list of changes to the Fedora Packaging Guidelines:
>> 
> I've done some updates, and now rpmlint reports:
>
> argyllcms.spec: W: no-cleaning-of-buildroot %install
> argyllcms.spec: W: no-buildroot-tag
>
> Does rpmlint need an update?
>   

It was flagged as an error for a long time and I filed a bug report and
it was downgraded to warning and I believe it is still misleading and
only really applies to EPEL and not to Fedora anymore and the template
and http://fedoraproject.org/wiki/Packaging/ReviewGuidelines should be
updated as well

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem with openoffice yum update

[Quentin Armitage]

On Thu, 2010-03-04 at 10:26 +, Frank Murphy wrote:
> On 04/03/10 10:17, Quentin Armitage wrote:
> > I cannot do a yum update of openoffice on F-13 RC4 with the
> > updates-testing repo enabled. There seems to be an inconsistency around
> > the dep checking, with it wanting both the old and new versions of
> > openoffice.org-langpack-en. It is attempting to update from version
> > 3.2.0-12.8.fc13.i686 to 3.2.0-12.9.fc13.i686.
> >
> > I'm happy to report this in bugzilla, but I'm not sure what I should
> > report it against.
> >
> --snipped--
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=569352 ?
> 
Many thanks for this - should have found it myself.

yum update --disableplugin=langpacks woks fine.

BTW, yum clean metadata didn't make any difference. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Enrico Scholz]

Paul Wouters  writes:

>>> Upstream reports a logging bug.
>>
>> ??? You and Noa Resare were the only one who reported the non-logging as
>> a bug and some posts ago you said that you are not upstream.  So, why do
>> you think that upstream reported a logging bug?
>
> I pointed you to http://bugs.noreply.org/flyspray/index.php?do=details&id=1133
> which is the upstream bug tracker, 

That's the wrong place to report Fedora issues. Information in this
tracker are outdated too.


> and I told you those bugs were filed in a joined session with 5
> tor developers at GSoC. 

When you have such insider contacts, why are you communicating in such a
perfidious way ("I understand your logging reasons" in [1] vs. your
offenses in this thread) instead of using your contacts to close the
bugs in the other bugtracker?


> No. your %post may not output anything. 

%post can give out something; e.g. '%post failed' which would happen
here due to the redhat-lsb bug.  I just give out a more useful message
than '%post failed' which helps people to identify the problem.


> It's a bug in tor. You're just pissing over the endusers with your
> fight over init systems.  If you cared about the users of the tor
> package, you would work around 

I workaround the redhat-lsb bug.



Enrico

Footnotes: 
[1]  https://bugzilla.redhat.com/show_bug.cgi?id=532373#c8

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

Ironically it happened again, just now when these FESCO threads
are still warm.

My desktop gui processes leak enough mem that I need to restart
couple times a week or system will run out of memory. Today
I started with updating the F11 with yum. During the update,
I noticed that it's pulling in the kde-4.4.0, scary. Then reboot.

Now when I logged in, noticed that desktop has really changed
quite a bit, some visual stuff even fixed.

Then I tried to start kmail to start working. It starts, asks
passwords, whines something about Akonadi which i don't use and
then crashes/exists.

kmail(4465)/kio (KIOConnection) 
KIO::ConnectionServer::listenForRemote: Listening on 
"local:/tmp/ksocket-tuju/kmailRj4465.slave-socket"
kmail(4465)/libakonadi Akonadi::Control::Private::exec: Could not start/stop 
Akonadi!
kmail(4465) main: Unable to start Akonadi server, exit application 
kmail(4465)/kdecore (KConfigSkeleton) 
KCoreConfigSkeleton::writeConfig:
(gdb)

This is exactly kind off stuff I don't have time now to solve,
since I need to work. If such upgrade would have been put to
next coming release, I could have upgraded when I have time,
some weekend - it would not interrupted my working and ruin my
day.

For all those who say that "latest stuff is the reason why
I use Fedora!!!1", there is rawhide for you.

For a lot of people, this kind of breakage is exactly the reason not 
to switch from windows/mac to Fedora.

Yes, I'm writing this with Alpine... handling pdf attachments and
doing invoicing with it is going to be fun.

KDE SIG, you need to re-think that proposal again.


Tuju

--
Ajatteleva ihminen tarvitsee unta.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Juha Tuomala wrote:
> Then I tried to start kmail to start working. It starts, asks
> passwords, whines something about Akonadi which i don't use and
> then crashes/exists.

Not to mention that kaddressbook which contains all my business
contacts, is broken too:

   http://tuju.fi/fedora/11/kab-20100304.png

looks like that some icons are also missing, but hard to judge
as it wont start properly to interact with user.


Tuju

--
Ajatteleva ihminen tarvitsee unta.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Rahul Sundaram]

On 03/04/2010 05:13 PM, Juha Tuomala wrote:
> This is exactly kind off stuff I don't have time now to solve,
> since I need to work. If such upgrade would have been put to
> next coming release, I could have upgraded when I have time,
> some weekend - it would not interrupted my working and ruin my
> day.
>   

Yes and it does happen now and then that updates like these cause end
users some pain and while some users love to tinker and play with new
features others see it as a hindrance even if it is purely enhancement
with no regressions because even UI changes cause disruption in workflow
setting aside all the possibility of regressions and I dont believe that
Fedora has the right balance between innovation and stability (not
merely robustness but any change for that matter) at the moment  (CentOS
is far removed and rawhide is far too bleeding edge)

Whether it would be a separate backports repo or merely some more
conservativeness in our update stream needs to be discussed and the
current discussion has brought up very polarised opinions and at this
point it would be useful to discuss detailed proposals than continuously
repeating the same points in a circle

For your specific case please file bug reports

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Jaroslav Reznik]

On Thursday 04 March 2010 13:05:36 Juha Tuomala wrote:
> On Thu, 4 Mar 2010, Juha Tuomala wrote:
> > Then I tried to start kmail to start working. It starts, asks
> > passwords, whines something about Akonadi which i don't use and
> > then crashes/exists.
> 
> Not to mention that kaddressbook which contains all my business
> contacts, is broken too:
> 
>http://tuju.fi/fedora/11/kab-20100304.png
> 
> looks like that some icons are also missing, but hard to judge
> as it wont start properly to interact with user.

That's the problem of not running Akonadi - it's central PIM part of KDE. 
Could you try to run it manually and paste log/output somewhere?

akonadictl start

Thanks

> 
> Tuju
> 
> --
> Ajatteleva ihminen tarvitsee unta.

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Jaroslav Reznik]

On Thursday 04 March 2010 13:13:18 Rahul Sundaram wrote:
> On 03/04/2010 05:13 PM, Juha Tuomala wrote:
> > This is exactly kind off stuff I don't have time now to solve,
> > since I need to work. If such upgrade would have been put to
> > next coming release, I could have upgraded when I have time,
> > some weekend - it would not interrupted my working and ruin my
> > day.
> 
> Yes and it does happen now and then that updates like these cause end
> users some pain and while some users love to tinker and play with new
> features others see it as a hindrance even if it is purely enhancement
> with no regressions because even UI changes cause disruption in workflow
> setting aside all the possibility of regressions and I dont believe that
> Fedora has the right balance between innovation and stability (not
> merely robustness but any change for that matter) at the moment  (CentOS
> is far removed and rawhide is far too bleeding edge)
> 
> Whether it would be a separate backports repo or merely some more
> conservativeness in our update stream needs to be discussed and the
> current discussion has brought up very polarised opinions and at this
> point it would be useful to discuss detailed proposals than continuously
> repeating the same points in a circle
> 
> For your specific case please file bug reports

We (some KDE SIG people) are currently working on so called stability proposal 
[1]. That means one bigger update per release as KDE schedules are not in sync 
with Fedora releases. So this means - Fn release of Fedora is getting updates 
and users will get fresh software (rawhide is not an option), Fn-1 is 
considered as stable, without any "mayor" updates but it's still quite fresh 
so users don't have (are not forced) to switch to brand new release, probably 
breaking more than just update. 

One of reasons we can be now much more conservative is that KDE is now in very 
good shape and few releases ago we couldn't let users with for example 4.0, 
4.1 releases. Now it's not so important to do big steps as changes are not so 
visible

FKDESCo is going to vote probably on next meeting, Tuesday 09 14:00 UTC. So 
please, Fedora KDE users - comment these changes! We're working for you! 
CC'ing k...@lists.fpo.

[1] https://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
 
Jaroslav

> Rahul

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Kevin Kofler]

Enrico Scholz wrote:
> %post can give out something; e.g. '%post failed' which would happen
> here due to the redhat-lsb bug.  I just give out a more useful message
> than '%post failed' which helps people to identify the problem.

%post MUST *NEVER* FAIL!!!

The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything, and 
that it just plain MUST NOT fail.

The fact that redhat-lsb is buggy is also only relevant because you're using 
the LSB stuff instead of using plain initscripts as REQUIRED by our 
guidelines. You MUST use plain initscripts, not -lsb, -upstart or -bikeshed. 
And those initscripts belong directly in the package, not some subpackage

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Seth Vidal]

On Thu, 4 Mar 2010, Till Maas wrote:

> On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
>
>> Great script here's a small set of changes to have easy-karma use yum as a 
>> module
>> instead of via subprocess.
>>
>> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
>
> Thank you, I will integrate it later today, when I set up a git repo. Is
> there a way to restrict the yum results using the time the packages were
> installed?

I can't query based on it - but it's easy for comparison purposes to look 
up the installed time from the package object.

the value is pkg_obj.installtime

it'll return the time in seconds

>> if I get a chance I'll see if I can figure out how to use the bodhi module
>> at the end so it doesn't have to use any subprocess calls at all.
>
> This is pretty straight forward, I will do this later today, too.

great.
-sv

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
>>http://tuju.fi/fedora/11/kab-20100304.png
>>
>> looks like that some icons are also missing, but hard to judge
>> as it wont start properly to interact with user.
>
> That's the problem of not running Akonadi - it's central PIM part of KDE.

The funny part is that Akonadi is still very much a work in 
progress. I've tried to get it working many times without success.
That's the reason majority still uses those plain resources.

Few days back I asked Rex, 'Do you use Akonadi, or know anyone who 
does?' - He repiled that he doesn't. (please correct me if I'm 
wrong). I've asked quite many others too, which say that they don't 
use it. It's unmature. It would be interesting to know, how many
KDE SIG members actually use it? :)

I've talked to one who works for living with KDE PIM stuff, with 
Akonadi people and he says that they are very unsatisfied to its
backends and it's still evolving a lot. They are actually moving
from mysqld to http://virtuoso.openlinksw.com/ (already used in 
nepomuk, so KDE drags two RDMBS to desktop atm - funny.)

I get that this is now being pushed down the throat at KDE side and 
they probably think that it might get better with wider testing base 
and thus they make the code depend hard on it. Fine, and they did it 
in their *feature release* since even they don't think that it's 
insane to enforce people in the middle of their workweek to become 
betatesters of some unfinished project.

If we only could get KDE SIG to start thinking like their upstream
have intended them to think, lot of people wouldn't be in this mess 
right now.


Tuju

--
Ajatteleva ihminen tarvitsee unta.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Kevin Kofler]

James Laska wrote:
> Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> review determine whether the Fedora 13 Alpha release criteria [1] have
> been met.  The team agreed that the Alpha criteria have been met, and to
> proceed with releasing F-13-Alpha-RC4.

Oh, because a KDE live image which can't be updated without resorting to the 
command line is obviously ready for release, and because 
there was clearly no way a RC5 could have been spun in 
the several days between the availability of the updated kpackagekit build 
(to match the PackageKit snapshot used in RC4) and this meeting.

On one hand we have people complaining about the quality of updates, on the 
other hand we're happily releasing crap we know is broken.

But of course the GNOME spin "works" (for some definition of "works", they 
also have a PackageKit issue which was declared not a blocker – 
https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also 
affects KPackageKit, by the way –, and they fail pretty much all the tests 
for beta or release quality, which I think the KDE spin would actually pass, 
given that this is the same 4.4.0 we pushed as F11 and F12 updates and works 
fine there, though I didn't bother testing this as clearly nobody cares 
about the KDE spin test results anyway), so nobody cares.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Build F-13 collection packages for all language translators

[Kevin Kofler]

Noriko Mizumoto wrote:
> This is kind reminder asking you to rebuild your package with latest
> translation. Localization team has been translating for updated and/or
> newly added strings since the String is frozen (2010-02-09). To allow
> translators to review and correct their latest translation in UI, this
> is essential. This is different from 'Rebuild all translated packages
> for Beta', this is added entry since Fedora 12 [1].

Please note that the packages now also need to go through Bodhi to actually 
be in F13.

This is due to the No Frozen Rawhide changes which your workflow doesn't 
seem to be adjusted for.

> "Build F-13 collection packages for all language translators" is
> expected between 2010-03-03 to 2010-03-05. Please make sure your build
> is completed by 2010-03-05, so that a live image to be composed on
> 2010-03-05.

Are you going to also pull packages from testing? Or should the translation 
updates be pushed directly to stable? Otherwise there's no way they can be 
in your compose in only 2 days.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Enrico Scholz]

Kevin Kofler  writes:

>> %post can give out something; e.g. '%post failed' which would happen
>> here due to the redhat-lsb bug.  I just give out a more useful message
>> than '%post failed' which helps people to identify the problem.
>
> %post MUST *NEVER* FAIL!!!

that's why it executes a workaround until redhat-lsb is fixed


> The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything

this means only output like license agreements, but not diagnostic
output on stderr


Enrico
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20100304 changes

[Rawhide Report]

Compose started at Thu Mar  4 08:15:15 UTC 2010

Broken deps for i386
--
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5
emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0
emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0
emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0
emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0
emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0
emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0
enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0
epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0
epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0
evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1
ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0
ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0
ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0
ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0
ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0
ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0
ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0
ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0
ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0
ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0
ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0
ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0
ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0
gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
mrpt-apps-0.8.0-0.2.20100102svn1398.fc13.i686 requires libhighgui.so.4
mrpt-apps-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcv.so.4
mrpt-apps-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcxcore.so.4
mrpt-core-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcxcore.so.4
mrpt-core-0.8.0-0.2.20100102svn1398.fc13.i686 requires libhighgui.so.4
mrpt-core-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcv.so.4
openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2
openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2
paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0
qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 
0:0.5.819819-4.fc13
   

File File-DirCompare-0.6.tar.gz uploaded to lookaside cache by eseyman

[Emmanuel Seyman]

A file has been added to the lookaside cache for perl-File-DirCompare:

75b150e32d5d9bd120e32c7e2ee01125  File-DirCompare-0.6.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rpms/perl-File-DirCompare/devel .cvsignore, 1.2, 1.3 perl-File-DirCompare.spec, 1.1, 1.2 sources, 1.2, 1.3

[Emmanuel Seyman]

Author: eseyman

Update of /cvs/pkgs/rpms/perl-File-DirCompare/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4060

Modified Files:
.cvsignore perl-File-DirCompare.spec sources 
Log Message:
Update to 0.6


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-File-DirCompare/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore  4 Mar 2010 00:12:16 -   1.2
+++ .cvsignore  4 Mar 2010 13:34:39 -   1.3
@@ -1 +1 @@
-File-DirCompare-0.5.tar.gz
+File-DirCompare-0.6.tar.gz


Index: perl-File-DirCompare.spec
===
RCS file: /cvs/pkgs/rpms/perl-File-DirCompare/devel/perl-File-DirCompare.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-File-DirCompare.spec   4 Mar 2010 00:12:17 -   1.1
+++ perl-File-DirCompare.spec   4 Mar 2010 13:34:40 -   1.2
@@ -1,5 +1,5 @@
 Name:   perl-File-DirCompare
-Version:0.5
+Version:0.6
 Release:1%{?dist}
 Summary:Perl module to compare two directories using callbacks
 License:GPL+ or Artistic
@@ -50,5 +50,8 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Mar 04 2010 Emmanuel Seyman  0.6-1
+- Update to 0.6.
+
 * Mon Mar 01 2010 Emmanuel Seyman  0.5-1
 - Specfile autogenerated by cpanspec 1.78.


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-File-DirCompare/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 4 Mar 2010 00:12:17 -   1.2
+++ sources 4 Mar 2010 13:34:40 -   1.3
@@ -1 +1 @@
-56ea28d4a362d7b78f26ba7a3fa8b920  File-DirCompare-0.5.tar.gz
+75b150e32d5d9bd120e32c7e2ee01125  File-DirCompare-0.6.tar.gz

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Kevin Kofler]

Kevin Fenzi wrote:
> Perhaps this could be added into fedora-packager?

Well, it's useful also for testers (or even just users) who are not 
packagers, so I'm not sure that's the best place.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Panu Matilainen]

On Thu, 4 Mar 2010, Kevin Kofler wrote:

> Enrico Scholz wrote:
>> %post can give out something; e.g. '%post failed' which would happen
>> here due to the redhat-lsb bug.  I just give out a more useful message
>> than '%post failed' which helps people to identify the problem.
>
> %post MUST *NEVER* FAIL!!!
>
> The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything, and
> that it just plain MUST NOT fail.

In the meanwhile, since Fedora 10 rpm doesn't leave duplicates around if 
%post or %postun fails. So it's not as big a deal as it used to be.

- Panu -
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Richard Hughes]

On 4 March 2010 13:17, Kevin Kofler  wrote:
> But of course the GNOME spin "works" (for some definition of "works", they
> also have a PackageKit issue which was declared not a blocker –

For the record, it is a yum-langpacks issue.

If you're running an up to date gnome-packagekit you get a nice
message telling you so.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Juha Tuomala wrote:
> My desktop gui processes leak enough mem that I need to restart
> couple times a week or system will run out of memory. Today
> I started with updating the F11 with yum. During the update,
> I noticed that it's pulling in the kde-4.4.0, scary. Then reboot.
[snip] 
> KDE SIG, you need to re-think that proposal again.

You mean the KDE stability proposal? As this is F11, i.e. "previous stable", 
KDE 4.4 would actually not have been pushed to F11 under that proposal.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Seth Vidal]

On Thu, 4 Mar 2010, Richard Hughes wrote:


On 4 March 2010 13:17, Kevin Kofler  wrote:

But of course the GNOME spin "works" (for some definition of "works", they
also have a PackageKit issue which was declared not a blocker –


For the record, it is a yum-langpacks issue.

If you're running an up to date gnome-packagekit you get a nice
message telling you so.


And there is a patch in upstream yum that let's skip-broken work around 
that problem.


I'm glad to put another yum out with this patch in it for f13 but I asked 
yesterday at the go/nogo meeting and was asked to wait until the alpha was 
out.


I'm happy to do so whenever, though.

-sv
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Rahul Sundaram wrote:
> Whether it would be a separate backports repo or merely some more
> conservativeness in our update stream

FWIW, for stuff like KDE, if we don't allow new feature upgrades even in the 
current stable release nor support an official backports repo, an unofficial 
one will no doubt spring up, or an existing unofficial repo will pick up 
that role (for KDE, kde-redhat stable would probably be revived, currently 
it's mostly empty for Fedora as the kind of stuff which would be in there is 
usually just pushed as official Fedora updates).

I would argue having this within Fedora infrastructure would be better as it 
would prevent proliferation of third-party repos replacing Fedora packages 
and the resulting compatibility issues (see e.g. the chaos we're having for 
RHEL with third-party repositories replacing official packages with newer 
versions and the resulting dependency hell) and as it would also provide a 
place for new versions of less commonly-used applications.

That said, IMHO the best solution is still to have this stuff in the 
official updates. But it's true that the kind of issues some users are 
having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't 
shown up during testing or it would have been considered a blocker.

But I think having yet another thread about update policies will be frowned 
upon by the moderators. Instead, let's please think about repairing this 
breakage now that it happened, i.e. get bug reports filed etc.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Till Maas]

On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:

> Great script here's a small set of changes to have easy-karma use yum as a 
> module 
> instead of via subprocess.
> 
> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch

There is now a git repo and your patch is included:
http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=summary

Regards
Till


pgp91dNDmVRfL.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Kevin Kofler wrote:
> You mean the KDE stability proposal? As this is F11, i.e. "previous stable",
> KDE 4.4 would actually not have been pushed to F11 under that proposal.

How i read it, you would still push *one* feature release in the 
middle of stable release lifespan, right?

How that's going to solve anything as upstream *intentionally* pushes
stuff into it to break things? Even they don't expect you to do what 
you do.


Tuju

--
Ajatteleva ihminen tarvitsee unta.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Kevin Kofler]

Enrico Scholz wrote:

> Kevin Kofler  writes:
>> The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything
> 
> this means only output like license agreements, but not diagnostic
> output on stderr

No, diagnostic output is also not allowed, especially not when the failure 
is not going to be relevant anyway because your scriptlet already works 
around it, that's why our scriptlet snippets often have >/dev/null 
2>/dev/null for commands known to sometimes be noisy.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Tom "spot" Callaway]

On 03/04/2010 05:21 AM, Kalev Lember wrote:
> On 03/04/2010 12:07 PM, Richard Hughes wrote:
>> On 3 March 2010 21:45, Tom "spot" Callaway  wrote:
>>> Here are the list of changes to the Fedora Packaging Guidelines:
>>
>> I've done some updates, and now rpmlint reports:
>>
>> argyllcms.spec: W: no-cleaning-of-buildroot %install
>> argyllcms.spec: W: no-buildroot-tag
>>
>> Does rpmlint need an update?
> 
> Also, should rpmdev-newspec templates get an update to not include 
> buildroot tag?

Yes, and yes, IMHO.

~spot
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HALL-MONITORED] Update threads are now hall-monitored

[Chris Adams]

Once upon a time, Hans de Goede  said:
> I think the whole "stable update cycle" versus "semi-rolling update style" is
> too black and white. For core packages / major desktop packages clearly a
> "stable update cycle" is the right thing to do.

Well, but reading this thread, it obviously isn't "clearly [...] the
right thing to do."  I think it is, and you think it is, but that is an
opinion and many don't share it.

> But for packages which are more nice packages, the right thing to do may vary.
> What for example for a package which is not only added recently to Fedora,
> but came into existence recently in general. There might be some new
> upstream releases there which are not bugfix only but still very good to
> have (think pre-alpha -> alpha -> beta steps).

I do think that more people should work like how GNOME, Firefox, and
some other things have been handled in the past, where the upstream
release cycle doesn't quite match Fedora's.  There have been a few cases
where an RC or late beta has been put into Fedora during release
testing, when the final upstream release is not scheduled to be released
until around or just after the next Fedora release.  As soon as the
"gold" bits come down from upstream (and they can be tested!), they get
pushed as an early update for Fedora.

For example, OpenSSH is working towards the release of 5.4p1.  I would
like to see a snapshot in F13 for testing ASAP, so it can get wider
testing.  Now, it is likely that OpenSSH 5.4p1 will ship long before
F13, but even if it didn't, I think it would be safe to ship a snapshot
and push 5.4p1 as soon as it is released.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Enrico Scholz]

Kevin Kofler  writes:

>>> The mandatory (MUST) guideline is that %post MUST NOT OUTPUT anything
>> 
>> this means only output like license agreements, but not diagnostic
>> output on stderr
>
> No, diagnostic output is also not allowed, 

from where do you have this information?


> especially not when the failure is not going to be relevant anyway
> because your scriptlet already works around it, that's why our
> scriptlet snippets often have >/dev/null
> 2>/dev/null for commands known to sometimes be noisy.

install_initd is not known to be noisy


Enrico
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Math-Pari-2.01080604.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-Math-Pari:

27f5999671fe2a29cfd2e8c8a1f9308e  Math-Pari-2.01080604.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Juha Tuomala wrote:
> The funny part is that Akonadi is still very much a work in
> progress. I've tried to get it working many times without success.
> That's the reason majority still uses those plain resources.

Uh, Akonadi is now always used for contacts as of KDE 4.4.

> Few days back I asked Rex, 'Do you use Akonadi, or know anyone who
> does?' - He repiled that he doesn't. (please correct me if I'm
> wrong). I've asked quite many others too, which say that they don't
> use it. It's unmature. It would be interesting to know, how many
> KDE SIG members actually use it? :)

Uh, all of us who use kdepim apps now use it for contacts. We don't use it 
for anything else, but that's part of upstream's Akonadi migration plan. In 
4.5, all PIM data will be in Akonadi. Akonadi-based versions of all the PIM 
apps have already been merged into KDE's SVN trunk.

> I've talked to one who works for living with KDE PIM stuff, with
> Akonadi people and he says that they are very unsatisfied to its
> backends and it's still evolving a lot. They are actually moving
> from mysqld to http://virtuoso.openlinksw.com/ (already used in
> nepomuk, so KDE drags two RDMBS to desktop atm - funny.)

Virtuoso is actually not a traditional RDBMS. It's a semantic (RDF/SparQL) 
database built on top of a relational (SQL) core. As the relational part is 
there anyway, they also allow you to access it directly, so Virtuoso can 
also be used as an RDBMS, and this is what Akonadi is planning to do, so 
they can share the database server with Nepomuk, which uses Virtuoso for its 
RDF functionality. But even if the default changes, the MySQL backend is not 
going away, it will be needed at least to convert existing data from 4.4.

> I get that this is now being pushed down the throat at KDE side and
> they probably think that it might get better with wider testing base
> and thus they make the code depend hard on it. Fine, and they did it
> in their *feature release* since even they don't think that it's
> insane to enforce people in the middle of their workweek to become
> betatesters of some unfinished project.
> 
> If we only could get KDE SIG to start thinking like their upstream
> have intended them to think, lot of people wouldn't be in this mess
> right now.

Upstream has no policy about what kind of releases are to be provided as 
updates, this is a distribution decision.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Rahul Sundaram]

On 03/04/2010 07:27 PM, Kevin Kofler wrote:
>
> That said, IMHO the best solution is still to have this stuff in the 
> official updates. But it's true that the kind of issues some users are 
> having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't 
> shown up during testing or it would have been considered a blocker.
>   

The whole point is that you will invariably find such breakage when
pushing updates like this *after* the release and this is precisely why
there are huge discussions on this topic and sooner you realize that no
matter how careful you are you only increase the risks by doing such
updates mid-release the better off we are towards a reasonable level of
compromise

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Kevin Kofler wrote:
> current stable release nor support an official backports repo, an unofficial
> one will no doubt spring up, or an existing unofficial repo will pick up
> that role (for KDE, kde-redhat stable would probably be revived, currently
> it's mostly empty for Fedora as the kind of stuff which would be in there is
> usually just pushed as official Fedora updates).

Go ahead, make that to your kde-hardcore-followers-repo. In my 
understanding, that's what it has been for past years already 
anyway.

> I would argue having this within Fedora infrastructure would be better as it
> would prevent proliferation of third-party repos replacing Fedora packages
> and the resulting compatibility issues (see e.g. the chaos we're having for
> RHEL with third-party repositories replacing official packages with newer
> versions and the resulting dependency hell) and as it would also provide a
> place for new versions of less commonly-used applications.

So the thing is that KDE SIG wants to prevent any other activity and 
keep the strings in own hands. That's why nobody can't enjoy the 
upstream's intended stability in bugfix releases and plan major 
upgrades.

If someone wants to fork, whatever, let them do it. That's why 
Fedora moves to the git, to make it easier.


> That said, IMHO the best solution is still to have this stuff in the
> official updates. But it's true that the kind of issues some users are
> having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't
> shown up during testing or it would have been considered a blocker.

What you've just proved could have been enough for some companies 
trying to run Fedora on their employees desktops and they probably 
think that they've seen enough. TCO is rising too high when you 
cannot do sane stable release updates.

In other words, SIG's current policy is doing more harm than good 
for Fedora.

> But I think having yet another thread about update policies will be frowned
> upon by the moderators. Instead, let's please think about repairing this
> breakage now that it happened, i.e. get bug reports filed etc.

Yes, let's fix the bug instead the policy that caused it in the 
first place, sigh.


Tuju

--
Ajatteleva ihminen tarvitsee unta.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Juha Tuomala wrote:
> How that's going to solve anything as upstream *intentionally* pushes
> stuff into it to break things?

Nobody intentionally BREAKS things. Upstream KDE releases are supposed to be 
backwards compatible, data migration is something which is taken care of. 
For example, Nepomuk will migrate your data from the Redland (or Sesame2) 
backend used in older KDE releases to Virtuoso which is now the default as 
of 4.4. Akonadi also automatically migrates your contacts to the new format.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Panu Matilainen]

On Thu, 4 Mar 2010, Tom \spot\ Callaway wrote:

> On 03/04/2010 05:21 AM, Kalev Lember wrote:
>> On 03/04/2010 12:07 PM, Richard Hughes wrote:
>>> On 3 March 2010 21:45, Tom "spot" Callaway  wrote:
 Here are the list of changes to the Fedora Packaging Guidelines:
>>>
>>> I've done some updates, and now rpmlint reports:
>>>
>>> argyllcms.spec: W: no-cleaning-of-buildroot %install
>>> argyllcms.spec: W: no-buildroot-tag
>>>
>>> Does rpmlint need an update?
>>
>> Also, should rpmdev-newspec templates get an update to not include
>> buildroot tag?
>
> Yes, and yes, IMHO.

Speaking of these... what about getting rid of %clean too? Automatic 
%clean is only added in F >= 13 currently, but the patch is small and 
could be easily backported to F11-12 too (I mean, a 7-line patch couldn't 
possibly break anything right? Har-de-har...)

- Panu -
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Jaroslav Reznik]

On Thursday 04 March 2010 15:01:29 Juha Tuomala wrote:
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
> > You mean the KDE stability proposal? As this is F11, i.e. "previous
> > stable", KDE 4.4 would actually not have been pushed to F11 under that
> > proposal.
> 
> How i read it, you would still push *one* feature release in the
> middle of stable release lifespan, right?
> 
> How that's going to solve anything as upstream *intentionally* pushes
> stuff into it to break things? Even they don't expect you to do what
> you do.

People who wants stability would be in time of this push to Fn still running 
Fn-1. Only people who wants new features would be running Fn. There's no sense 
to have two frozen releases out there! We can just support one for 12 
months...

I personally think that update every 6 months breaks much more stuff so letting 
users to stays as much time with older but still supported releases is what we 
really want.  
> 
> Tuju
> 
> --
> Ajatteleva ihminen tarvitsee unta.

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Thomas Janssen]

On Thu, Mar 4, 2010 at 3:30 PM, Juha Tuomala  wrote:
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> current stable release nor support an official backports repo, an unofficial
>> one will no doubt spring up, or an existing unofficial repo will pick up
>> that role (for KDE, kde-redhat stable would probably be revived, currently
>> it's mostly empty for Fedora as the kind of stuff which would be in there is
>> usually just pushed as official Fedora updates).
>
> Go ahead, make that to your kde-hardcore-followers-repo. In my
> understanding, that's what it has been for past years already
> anyway.

There's no need to continued attack the KDE SIG. You're not a first
time linuxer. If you're that scared as you said in your OP, then you
should use yum to exclude that stuff. If you dont know how: man yum ;
man yum.conf

But of course, you couldn't then bash others.

-- 
LG Thomas

Dubium sapientiae initium
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Tom "spot" Callaway]

On 03/04/2010 09:35 AM, Panu Matilainen wrote:
> Speaking of these... what about getting rid of %clean too? Automatic 
> %clean is only added in F >= 13 currently, but the patch is small and 
> could be easily backported to F11-12 too (I mean, a 7-line patch couldn't 
> possibly break anything right? Har-de-har...)

You should really talk to the Fedora RPM package maintainer about adding
that. *cough* ;)

~spot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Mike McGrath]

On Thu, 4 Mar 2010, Thomas Janssen wrote:

> On Thu, Mar 4, 2010 at 3:30 PM, Juha Tuomala  wrote:
> > On Thu, 4 Mar 2010, Kevin Kofler wrote:
> >> current stable release nor support an official backports repo, an 
> >> unofficial
> >> one will no doubt spring up, or an existing unofficial repo will pick up
> >> that role (for KDE, kde-redhat stable would probably be revived, currently
> >> it's mostly empty for Fedora as the kind of stuff which would be in there 
> >> is
> >> usually just pushed as official Fedora updates).
> >
> > Go ahead, make that to your kde-hardcore-followers-repo. In my
> > understanding, that's what it has been for past years already
> > anyway.
>
> There's no need to continued attack the KDE SIG. You're not a first
> time linuxer. If you're that scared as you said in your OP, then you
> should use yum to exclude that stuff. If you dont know how: man yum ;
> man yum.conf
>
> But of course, you couldn't then bash others.
>

Alternatively, the KDE SIG could stop ignoring the problems that were
caused this week by the updates they released.  Even an "I'm sorry I broke
your desktop" would go a long way.  The update the busted my desktop
happened on a pretty vanilla install, I suspect lots of users experienced
issues.

-Mike
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpms/perl-Math-Pari/devel .cvsignore, 1.13, 1.14 perl-Math-Pari.spec, 1.23, 1.24 sources, 1.13, 1.14

[Paul Howarth]

Author: pghmcfc

Update of /cvs/pkgs/rpms/perl-Math-Pari/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15962

Modified Files:
.cvsignore perl-Math-Pari.spec sources 
Log Message:
Update to 2.01080604


Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Math-Pari/devel/.cvsignore,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- .cvsignore  11 Dec 2009 09:37:42 -  1.13
+++ .cvsignore  4 Mar 2010 14:46:47 -   1.14
@@ -1,2 +1,2 @@
-Math-Pari-2.01080603.tar.gz
+Math-Pari-2.01080604.tar.gz
 pari-2.3.4.tar.gz


Index: perl-Math-Pari.spec
===
RCS file: /cvs/pkgs/rpms/perl-Math-Pari/devel/perl-Math-Pari.spec,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -p -r1.23 -r1.24
--- perl-Math-Pari.spec 11 Dec 2009 09:37:42 -  1.23
+++ perl-Math-Pari.spec 4 Mar 2010 14:46:47 -   1.24
@@ -10,12 +10,12 @@
 %global pari_version   2.3.4
 %global pari_int_version %(echo %{pari_version} | %{__perl} -pi -e 
's/(\\d+)\\.(\\d+)\\.(\\d+)/sprintf("%d%03d%03d",$1,$2,$3)/e')
 
-%global extraversion   03
+%global extraversion   04
 
 Summary:   Perl interface to PARI
 Name:  perl-Math-Pari
 Version:   2.010806
-Release:   3%{?dist}
+Release:   4%{?dist}
 License:   GPL+ or Artistic
 Group: Development/Libraries
 Url:   http://search.cpan.org/dist/Math-Pari/
@@ -89,6 +89,9 @@ as Perl functions, and (almost) seamless
 %exclude %{_mandir}/man3/Math::libPARI.dumb.3pm*
 
 %changelog
+* Thu Mar  4 2010 Paul Howarth  - 2.010806-4
+- Update to 2.01080604 (see Changes for details)
+
 * Fri Dec 11 2009 Paul Howarth  - 2.010806-3
 - Update to 2.01080603 (see Changes for details)
 


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Math-Pari/devel/sources,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- sources 11 Dec 2009 09:37:42 -  1.13
+++ sources 4 Mar 2010 14:46:48 -   1.14
@@ -1,2 +1,2 @@
-e5f970b7a351f671e0641fa8266ce770  Math-Pari-2.01080603.tar.gz
+27f5999671fe2a29cfd2e8c8a1f9308e  Math-Pari-2.01080604.tar.gz
 35c896266e4257793387ba22d5d76078  pari-2.3.4.tar.gz

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Harmless KDE feature upgrades - yeah right

[Jaroslav Reznik]

On Thursday 04 March 2010 15:30:43 Juha Tuomala wrote:
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
> > current stable release nor support an official backports repo, an
> > unofficial one will no doubt spring up, or an existing unofficial repo
> > will pick up that role (for KDE, kde-redhat stable would probably be
> > revived, currently it's mostly empty for Fedora as the kind of stuff
> > which would be in there is usually just pushed as official Fedora
> > updates).
> 
> Go ahead, make that to your kde-hardcore-followers-repo. In my
> understanding, that's what it has been for past years already
> anyway.

Third party repos are highway to hell unfortunately. Ask former OpenSuse users 
:( Of course - it's one of solutions. 

> > I would argue having this within Fedora infrastructure would be better as
> > it would prevent proliferation of third-party repos replacing Fedora
> > packages and the resulting compatibility issues (see e.g. the chaos
> > we're having for RHEL with third-party repositories replacing official
> > packages with newer versions and the resulting dependency hell) and as
> > it would also provide a place for new versions of less commonly-used
> > applications.
> 
> So the thing is that KDE SIG wants to prevent any other activity and
> keep the strings in own hands. That's why nobody can't enjoy the
> upstream's intended stability in bugfix releases and plan major
> upgrades.
> 
> If someone wants to fork, whatever, let them do it. That's why
> Fedora moves to the git, to make it easier.
> 
> > That said, IMHO the best solution is still to have this stuff in the
> > official updates. But it's true that the kind of issues some users are
> > having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't
> > shown up during testing or it would have been considered a blocker.
> 
> What you've just proved could have been enough for some companies
> trying to run Fedora on their employees desktops and they probably
> think that they've seen enough. TCO is rising too high when you
> cannot do sane stable release updates.

Fedora is not for companies - with one year of lifetime it's not very well 
suited for any long-term deployment. Use Cent OS - it's not I don't want to 
see Fedora there, it's just reality. And Cent OS is just older and more stable 
Fedora...
  
> In other words, SIG's current policy is doing more harm than good
> for Fedora.
> 
> > But I think having yet another thread about update policies will be
> > frowned upon by the moderators. Instead, let's please think about
> > repairing this breakage now that it happened, i.e. get bug reports filed
> > etc.
> 
> Yes, let's fix the bug instead the policy that caused it in the
> first place, sigh.
> 
> 
> Tuju
> 
> --
> Ajatteleva ihminen tarvitsee unta.

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

duplicate f13 package announcements

[M A Young]

I don't know if this has already been raised but I notice on the 
package-annou...@lists.fedoraproject.org list that several Fedora 13 
packages keep getting announced, for example, by checking the archives I 
see that fedora-release-13-0.6 has been announced 6 times in March and a 
further 7 times in February. I suspect there is a glitch in the package 
management system somewhere.

Michael Young
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bz532373, was Re: tor dependency insanity.

[Paul Wouters]

On Thu, 4 Mar 2010, Enrico Scholz wrote:

[ two year tor insanity ]

It's been two years. I'm done with this discussion. I'm not spending more
time on the "tor-enrico" pacakge.

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: duplicate f13 package announcements

[Jon Ciesla]

M A Young wrote:
> I don't know if this has already been raised but I notice on the 
> package-annou...@lists.fedoraproject.org list that several Fedora 13 
> packages keep getting announced, for example, by checking the archives I 
> see that fedora-release-13-0.6 has been announced 6 times in March and a 
> further 7 times in February. I suspect there is a glitch in the package 
> management system somewhere.
>
>   Michael Young
>   
It's happening for 3 F12 packages as well.  I mentioned it in a ticket 
for another issue:

https://fedorahosted.org/rel-eng/ticket/2328

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Thomas Janssen]

On Thu, Mar 4, 2010 at 3:45 PM, Mike McGrath  wrote:
> On Thu, 4 Mar 2010, Thomas Janssen wrote:
>
>> On Thu, Mar 4, 2010 at 3:30 PM, Juha Tuomala  wrote:
>> > On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> >> current stable release nor support an official backports repo, an 
>> >> unofficial
>> >> one will no doubt spring up, or an existing unofficial repo will pick up
>> >> that role (for KDE, kde-redhat stable would probably be revived, currently
>> >> it's mostly empty for Fedora as the kind of stuff which would be in there 
>> >> is
>> >> usually just pushed as official Fedora updates).
>> >
>> > Go ahead, make that to your kde-hardcore-followers-repo. In my
>> > understanding, that's what it has been for past years already
>> > anyway.
>>
>> There's no need to continued attack the KDE SIG. You're not a first
>> time linuxer. If you're that scared as you said in your OP, then you
>> should use yum to exclude that stuff. If you dont know how: man yum ;
>> man yum.conf
>>
>> But of course, you couldn't then bash others.
>>
>
> Alternatively, the KDE SIG could stop ignoring the problems that were
> caused this week by the updates they released.  Even an "I'm sorry I broke
> your desktop" would go a long way.  The update the busted my desktop
> happened on a pretty vanilla install, I suspect lots of users experienced
> issues.

You're absolutely right here. And it gets discussed heavily.
I just get slowly sick of all that bashing around. Doesn't matter
which way. The KDE SIG needs a bit time to discuss and decide what
exactly will be done (for sure the right thing to prevent that kind of
breakage). Though systematic annoying pestering will not help at all.

I think the point is already very clear and work (thoughts,
discussion) on it is in progress.

Maybe i should send a mail and ask if it's possible to stop attacking
others. I start to get agressive myself, and i dont like that.

-- 
LG Thomas

Dubium sapientiae initium
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Thomas Janssen]

On Thu, Mar 4, 2010 at 3:46 PM, Jaroslav Reznik  wrote:
> On Thursday 04 March 2010 15:30:43 Juha Tuomala wrote:
>> On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> > current stable release nor support an official backports repo, an
>> > unofficial one will no doubt spring up, or an existing unofficial repo
>> > will pick up that role (for KDE, kde-redhat stable would probably be
>> > revived, currently it's mostly empty for Fedora as the kind of stuff
>> > which would be in there is usually just pushed as official Fedora
>> > updates).
>>
>> Go ahead, make that to your kde-hardcore-followers-repo. In my
>> understanding, that's what it has been for past years already
>> anyway.
>
> Third party repos are highway to hell unfortunately. Ask former OpenSuse users
> :( Of course - it's one of solutions.

Yes (former/still some installations, openSUSE user here), third party
repos can be a hell. They are definitely not for beginners or
i-dont-care users.

-- 
LG Thomas

Dubium sapientiae initium
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Jaroslav Reznik]

On Thursday 04 March 2010 15:58:32 Thomas Janssen wrote:
> On Thu, Mar 4, 2010 at 3:46 PM, Jaroslav Reznik  wrote:
> > On Thursday 04 March 2010 15:30:43 Juha Tuomala wrote:
> >> On Thu, 4 Mar 2010, Kevin Kofler wrote:
> >> > current stable release nor support an official backports repo, an
> >> > unofficial one will no doubt spring up, or an existing unofficial repo
> >> > will pick up that role (for KDE, kde-redhat stable would probably be
> >> > revived, currently it's mostly empty for Fedora as the kind of stuff
> >> > which would be in there is usually just pushed as official Fedora
> >> > updates).
> >> 
> >> Go ahead, make that to your kde-hardcore-followers-repo. In my
> >> understanding, that's what it has been for past years already
> >> anyway.
> > 
> > Third party repos are highway to hell unfortunately. Ask former OpenSuse
> > users
> > 
> > :( Of course - it's one of solutions.
> 
> Yes (former/still some installations, openSUSE user here), third party
> repos can be a hell. They are definitely not for beginners or
> i-dont-care users.

These repos are not intended for beginners/i-dont-care users but it's hell 
even for advanced users - it just screw system... Even I try not to mess with 
RPM fussion but it's still needed :(

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: duplicate f13 package announcements

[Josh Boyer]

On Thu, Mar 04, 2010 at 08:54:28AM -0600, Jon Ciesla wrote:
>M A Young wrote:
>> I don't know if this has already been raised but I notice on the 
>> package-annou...@lists.fedoraproject.org list that several Fedora 13 
>> packages keep getting announced, for example, by checking the archives I 
>> see that fedora-release-13-0.6 has been announced 6 times in March and a 
>> further 7 times in February. I suspect there is a glitch in the package 
>> management system somewhere.
>>
>>  Michael Young
>>   
>It's happening for 3 F12 packages as well.  I mentioned it in a ticket 
>for another issue:
>
>https://fedorahosted.org/rel-eng/ticket/2328

Bodhi bug.  Hopefully being fixed today.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
>> Go ahead, make that to your kde-hardcore-followers-repo. In my
>> understanding, that's what it has been for past years already
>> anyway.
>
> Third party repos are highway to hell unfortunately.

Quite interesting statement from the KDE SIG who runs that third 
party repo.

> Fedora is not for companies -

Even accepting the release cycle and official release policies?

I'd concentrate defining *what* the Fedora is, and sticking on it.
Let the consumers decide does it suit them or not.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Modification of passsync DLL

[Soeren Malchow]

Dear all,

i hope this is the right place.

I am looking for a developer who can create personalized modifications to the 
passsync DLL, specifically we need to have a function that matches the password 
complexity against the DS ( and another LDAP ) and then reports back whether 
the complexity is sufficient.

We would pay for the implementation, i would also be happy about a referral to 
someone who can do that.

The developer ( or company ) should be located in germany if possible, or at 
least in europe.


Best Regards,

Soeren Malchow
CIO

Phone:+49 40 806008 120
Mobile:   +49 171 5525102
Email:soeren.malc...@mcon.net
Web: www.mcon.net

MCon Germany GmbH
Neuer Pferdemarkt 1
20359 Hamburg
Germany


Berlin • Hamburg • Karlsruhe • Koeln • Muenchen
Traderegister HRB 110600 Local Court Mannheim | VAT-Id. No.: DE235236333 | Tax 
No.: 35 007 055033
Managing Partner: Dirk Meissner, Guenther Kreuzpaintner, Soeren Malchow

Member of MCon Group
Austria • China • Czech Republic • France • Germany • Japan • Malaysia • Russia 
• South Korea • Switzerland • UK • USA



This e-mail may contain confidential and/ or privileged information. If you are 
not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorized copying, disclosure
or distribution of the material contained in this e-mail is strictly prohibited.
Please consider the environment before printing this e-mail




--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Juha Tuomala wrote:
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> I would argue having this within Fedora infrastructure would be better as
>> it would prevent proliferation of third-party repos replacing Fedora
>> packages and the resulting compatibility issues (see e.g. the chaos we're
>> having for RHEL with third-party repositories replacing official packages
>> with newer versions and the resulting dependency hell) and as it would
>> also provide a place for new versions of less commonly-used applications.
> 
> So the thing is that KDE SIG wants to prevent any other activity and
> keep the strings in own hands.

Huh? What I was saying is that it's not a good idea if you have:
* kde-redhat replacing Fedora's Qt and KDE packages with newer stable 
versions
* repo X replacing Fedora's kernel packages with newer stable versions
* repo Y replacing Fedora's some-library packages with newer stable versions
* repo Z replacing Fedora's some-application packages with newer stable 
versions
etc., and users who want to be up to date having all these repos enabled, 
when the repository maintainers didn't test them together (or they did, in 
which case the people who're trying to enable only, say, repo Y, are the 
ones getting screwed).

Having one central backports (or just updates as now) repository prevents 
those compatibility issues.

> That's why nobody can't enjoy the upstream's intended stability in bugfix
> releases and plan major upgrades.

You keep saying that, yet you have provided no evidence of such a stance 
from upstream. KDE upstream actually has no policy on what versions should 
be pushed as updates in what distros, it's a distro decision!

> If someone wants to fork, whatever, let them do it. That's why Fedora
> moves to the git, to make it easier.

The issue is not forking the specfiles, it's mixing the repos and the 
resulting dependency hell.

>> That said, IMHO the best solution is still to have this stuff in the
>> official updates. But it's true that the kind of issues some users are
>> having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't
>> shown up during testing or it would have been considered a blocker.
> 
> What you've just proved could have been enough for some companies
> trying to run Fedora on their employees desktops and they probably
> think that they've seen enough. TCO is rising too high when you
> cannot do sane stable release updates.

Who says they would have seen that issue at all? You're the first one to 
report this particular issue.

> In other words, SIG's current policy is doing more harm than good
> for Fedora.

Not necessarily. There has also been some very positive feedback for the KDE 
4.4 updates, and some people are using Fedora BECAUSE such updates get 
pushed.

>> But I think having yet another thread about update policies will be
>> frowned upon by the moderators. Instead, let's please think about
>> repairing this breakage now that it happened, i.e. get bug reports filed
>> etc.
> 
> Yes, let's fix the bug instead the policy that caused it in the
> first place, sigh.

It's too late to undo the update now, it already got pushed (reverting would 
break a lot more things, KDE does not support downgrades).

So the only productive thing to do now is to fix the bug. Complaining about 
it serves nobody.

So please provide the details required to actually FIX the bug! I.e. file a 
bug report and provide the output of "akonadictl start" Rex asked for.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
> will pick up that role (for KDE, kde-redhat stable would probably be
> revived, currently it's mostly empty for Fedora as the kind of stuff
> which would be in there is usually just pushed as official Fedora
> updates).

 Go ahead, make that to your kde-hardcore-followers-repo. In my
 understanding, that's what it has been for past years already
 anyway.
>>>
>>> Third party repos are highway to hell unfortunately. Ask former OpenSuse
>>> users
>
> These repos are not intended for beginners/i-dont-care users but it's hell
> even for advanced users - it just screw system... Even I try not to mess with
> RPM fussion but it's still needed :(

You're being overdramatic here. It's the same repo that is being 
used to test latest KDE stuff right now before it goes to rawhide 
and to the releases. It's built by same people who make actual 
releases. It's KDE team's repo, it's Rex's old repo/project before
KDE got proper status in Fedora.

How you could use its problems (that apparently don't even exist) as 
an argument and reason to cause problems for people who just want to 
use those kde bugfix releases in old, stable Fedora release?


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Seth Vidal]

On Thu, 4 Mar 2010, Till Maas wrote:

> On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
>
>> Great script here's a small set of changes to have easy-karma use yum as a 
>> module
>> instead of via subprocess.
>>
>> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
>
> There is now a git repo and your patch is included:
> http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=summary
>

Till,
  you got a set of things you want to work on there? If there's a TODO I'll 
see if I can take care of some of them for you.

-sv

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Bill Nottingham]

Till Maas (opensou...@till.name) said: 
> A less ugly script can now be found here:
> http://till.fedorapeople.org/tmp/easy-karma.py
> Improvements:
> - display update details, e.g. bugs and notes
> - use src.rpm to find matching update
> - skip updates that have already been commented
> 
> With this giving karma is so simple, that there is no excuse for not
> doing so. I'll add an git repo and clean it up more the next days.

I haven't had a chance to play with this yet, but just from
reading the description - thanks for doing this, this is great.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Kevin Kofler wrote:
> Upstream has no policy about what kind of releases are to be provided as
> updates, this is a distribution decision.

They add features to own releases just for that reason, so 
downstreams and users could avoid such mess that has just happened.

If you don't understand that, you're part of the problem.


On Thu, 4 Mar 2010, Kevin Kofler wrote:
> Nobody intentionally BREAKS things. Upstream KDE releases are 
> supposed to be backwards compatible,

See, you used word 'supposed'. You've been around enough to know 
that reality is something else what you keep so passionately talking 
about.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [389-devel] Modification of passsync DLL

[Rich Megginson]

Soeren Malchow wrote:
> Dear all,
>
> i hope this is the right place.
>
> I am looking for a developer who can create personalized modifications 
> to the passsync DLL, specifically we need to have a function that 
> matches the password complexity against the DS ( and another LDAP ) 
> and then reports back whether the complexity is sufficient.
The 389 DS already reports back a CONSTRAINT VIOLATION if the password 
does not meet the 389 DS password syntax/complexity checking.  Is it 
that you want to implement the same checking inside the passsync dll?
>
> We would pay for the implementation, i would also be happy about a 
> referral to someone who can do that.
>
> The developer ( or company ) should be located in germany if possible, 
> or at least in europe.
>
>
> Best Regards,
>
> *Soeren Malchow*
> CIO
>
> *Phone:*+49 40 806008 120  
> *Mobile:*   +49 171 5525102
> *Email:*soeren.malc...@mcon.net 
> *Web: *www.mcon.net  
>
> *MCon Germany GmbH *
> Neuer Pferdemarkt 1
> 20359 Hamburg
> Germany
>
>
> Berlin • Hamburg • Karlsruhe • Koeln • Muenchen
> Traderegister HRB 110600 Local Court Mannheim | VAT-Id. No.: DE235236333 | 
> Tax No.: 35 007 055033
> Managing Partner: Dirk Meissner, Guenther Kreuzpaintner, Soeren Malchow
>  
> *Member of MCon Group
> *Austria • China • Czech Republic • France • Germany • Japan • 
> Malaysia • Russia • South Korea • Switzerland • UK • USA
>   
>  
>  
> This e-mail may contain confidential and/ or privileged information. 
> If you are not the intended recipient (or have received 
> this e-mail in error) please notify the sender immediately and destroy 
> this e-mail. Any unauthorized copying, disclosure 
> or distribution of the material contained in this e-mail is strictly 
> prohibited.
> Please consider the environment before printing this e-mail
>  
>
>
>
> 
>
> --
> 389-devel mailing list
> 389-de...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Harmless KDE feature upgrades - yeah right

[Rex Dieter]

Juha Tuomala wrote:

> 
> 
> 
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> You mean the KDE stability proposal? As this is F11, i.e. "previous
>> stable", KDE 4.4 would actually not have been pushed to F11 under that
>> proposal.
> 
> How i read it, you would still push *one* feature release in the
> middle of stable release lifespan, right?

clarification:  at *most* one.  that means zero is an option too.

-- Rex


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Juha Tuomala]

On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> That's why nobody can't enjoy the upstream's intended stability in bugfix
>> releases and plan major upgrades.
>
> You keep saying that, yet you have provided no evidence of such a stance
> from upstream. KDE upstream actually has no policy on what versions should
> be pushed as updates in what distros, it's a distro decision!

a) how users are supposed to consume those bugfix releases only,
when you push feature release in the middle of working week?

b) why those different releases exist in the first place, if there is no
intention to differentiate them?

That is, there wouldn't be need for third release number,
we coul just have kde-4.28 now.

Speaking of distro decision, you mean that when FESCO decides this 
to stop, KDE SIG will stop it too. That's good.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [389-devel] Modification of passsync DLL

[Soeren Malchow]

Dear Rich,

the Problem is, that there is a second SSO system involved that also needs to 
be checked, and we were thinking that we can utilize the passsync DLL as well 
for that.

the logic for checking the other system is already available and only needs to 
be implemented into the 64bit ready passsync sll

cheers
soeren

On Mar 4, 2010, at 4:38 PM, Rich Megginson wrote:

Soeren Malchow wrote:
Dear all,

i hope this is the right place.

I am looking for a developer who can create personalized modifications
to the passsync DLL, specifically we need to have a function that
matches the password complexity against the DS ( and another LDAP )
and then reports back whether the complexity is sufficient.
The 389 DS already reports back a CONSTRAINT VIOLATION if the password
does not meet the 389 DS password syntax/complexity checking.  Is it
that you want to implement the same checking inside the passsync dll?

We would pay for the implementation, i would also be happy about a
referral to someone who can do that.

The developer ( or company ) should be located in germany if possible,
or at least in europe.


Best Regards,

*Soeren Malchow*
CIO

*Phone:*+49 40 806008 120
*Mobile:*   +49 171 5525102
*Email:*soeren.malc...@mcon.net 

*Web: *www.mcon.net 

*MCon Germany GmbH *
Neuer Pferdemarkt 1
20359 Hamburg
Germany


Berlin • Hamburg • Karlsruhe • Koeln • Muenchen
Traderegister HRB 110600 Local Court Mannheim | VAT-Id. No.: DE235236333 | Tax 
No.: 35 007 055033
Managing Partner: Dirk Meissner, Guenther Kreuzpaintner, Soeren Malchow

*Member of MCon Group
*Austria • China • Czech Republic • France • Germany • Japan •
Malaysia • Russia • South Korea • Switzerland • UK • USA



This e-mail may contain confidential and/ or privileged information.
If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy
this e-mail. Any unauthorized copying, disclosure
or distribution of the material contained in this e-mail is strictly
prohibited.
Please consider the environment before printing this e-mail






--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: usb_modeswitch by default

[Dan Williams]

On Thu, 2010-03-04 at 08:05 +1000, Peter Hutterer wrote:
> On Wed, Mar 03, 2010 at 09:27:47PM +0100, drago01 wrote:
> > On Wed, Mar 3, 2010 at 9:20 PM, Rahul Sundaram  wrote:
> > > Hi
> > >
> > > Increasingly a number of broadband connections require usb_modeswitch to
> > > connect online
> > >
> > > http://who-t.blogspot.com/2010/03/vodafone-australia-mobile-broadband-and.html
> > >
> > > Any opposition to adding this to the base group?
> > 
> > Well we could/should just make modemmanager to require it.
> 
> We should wait until Bug 563503 is resolved. Version 1.1.0 has the udev
> rules for plug-and-play magic, earlier versions still need to be invoked
> manually. That's on top of the new device support 1.1.0 offers (including
> the one that prompted me to write the post above).

Honestly we should just build 1.1.0 for F11+.

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to make things better(tm)

[Rex Dieter]

Mike McGrath wrote:

> Alternatively, the KDE SIG could stop ignoring the problems that were
> caused this week by the updates they released.  Even an "I'm sorry I broke
> your desktop" would go a long way.  The update the busted my desktop
> happened on a pretty vanilla install, I suspect lots of users experienced
> issues.

To be clear, no one is ignoring anything.  (What a silly thing to say?... 
well, maybe not so silly... means there's a bad pr/perception problem. :( )

Like most any group making hard decisions, the KDE SIG bases them on the 
best information available.  Fact is, we extensively tested this new version 
for over a month, and every serious issue/blocker that was reported or 
identified was addressed prior to releasing this. 

Unfortunately, it seems there were more problems than what we were aware of 
when the decision was made to do the 4.4.0 (stable) update.  Yeah, that 
sucks.

So here we are in a bit of a pickle, with many unhappy folks.  Brain dump on 
"how to make things better(tm)" (or for you glass half-empty folks, "how to 
make things suck less(tm)"):

1.  Improve communication.  Seems there's a bit of disconnected between kde 
sig plans/intentions and the expectations of some significant portion of 
other fedora contributors and user-base.  Also, continue to work toward 
making constructive feedback the obvious and expected norm.  Clearly define 
what this is, and it's intrinsic high value.  imo, folks like to know that 
they are being heard, and to feel that their constructive participation 
yields positive results.

(dunno about everyone else, but this, to me, seems to be the biggest 
"problem" at hand)

2.  better and more testing.  Work more to tap into ongoing fedora 
qa/testing efforts.

3.  adjust plans/policy wrt kde upgrades.
 a. implement kde stability proposal as is (to limit 4.x type upgrades to at 
most one per fedora release)

 b. simply do new 4.x versions only for fn+1?  pros: less chance to disrupt 
current installations.  cons:  pushes off the problems to users upgrading to 
fn+1.

 c.  defer any sig decisions, wait for fedora-wide fesco policy/guideline



99. profit.


-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Till Maas]

On Thu, Mar 04, 2010 at 10:26:17AM -0500, Seth Vidal wrote:
> 
> 
> On Thu, 4 Mar 2010, Till Maas wrote:
> 
> > On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
> >
> >> Great script here's a small set of changes to have easy-karma use yum as a 
> >> module
> >> instead of via subprocess.
> >>
> >> http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
> >
> > There is now a git repo and your patch is included:
> > http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=summary

>   you got a set of things you want to work on there? If there's a TODO I'll 
> see if I can take care of some of them for you.

Thanks, but for my personal use I do not miss anything currently, except
that it could be faster. But this only hits me, because I am running it
a lot to test it. But if you want, you can start creating a spec, so it
can be packaged. Another obvious TODO is to get bodhi_update_str()
included in the bodhi client in fedora-python.

But I have a simple question, is this save to do?
options.releasever = my.conf.yumvar["releasever"]

Regards
Till


pgpBLsJkItCum.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to make things better(tm)

[Mike McGrath]

On Thu, 4 Mar 2010, Rex Dieter wrote:

> Mike McGrath wrote:
>
> > Alternatively, the KDE SIG could stop ignoring the problems that were
> > caused this week by the updates they released.  Even an "I'm sorry I broke
> > your desktop" would go a long way.  The update the busted my desktop
> > happened on a pretty vanilla install, I suspect lots of users experienced
> > issues.
>
> To be clear, no one is ignoring anything.  (What a silly thing to say?...
> well, maybe not so silly... means there's a bad pr/perception problem. :( )
>

Well, so far all I've heard is that pushing the update was the right thing
to do.  In fact, it was so the right thing to do that I have yet to see
acknolwedgement that had any downsides at all, thus why I used the term
"ignore".

> Like most any group making hard decisions, the KDE SIG bases them on the
> best information available.  Fact is, we extensively tested this new version
> for over a month, and every serious issue/blocker that was reported or
> identified was addressed prior to releasing this.
>
> Unfortunately, it seems there were more problems than what we were aware of
> when the decision was made to do the 4.4.0 (stable) update.  Yeah, that
> sucks.
>

So here's a question.  I'm just going to throw it out there.  Since, as
with this update, it's impossible to know all of the problems that will
come up when pushing a release out, why not just wait 2 months so everyone
does it when they upgrade to F13?  That way, I have a reason to upgrade to
F13, and F12 doesn't get a reputation for breaking stuff in the middle of
a work week?

None of us know what we don't know, that's why some of us like to be
conservative.  Especially since KDE is currently the main thing I use that
puts bread on my table at night.  I know that's dramatic, but I was late
to a meeting Tuesday because daily updates that would normally have taken
20 minutes or less, took well over an hour because I had things to fix.

The KDE sig has said there's people that only use Fedora because it is
kept super up to date.  What is the KDE sig doing to get the actual
metrics of what people that would prefer a stable release vs the bleeding
edge?

> 1.  Improve communication.  Seems there's a bit of disconnected between kde
> sig plans/intentions and the expectations of some significant portion of
> other fedora contributors and user-base.  Also, continue to work toward
> making constructive feedback the obvious and expected norm.  Clearly define
> what this is, and it's intrinsic high value.  imo, folks like to know that
> they are being heard, and to feel that their constructive participation
> yields positive results.
>
> (dunno about everyone else, but this, to me, seems to be the biggest
> "problem" at hand)
>

By "Improve communication" I'd say do an actual study to see what your
users want then publish those results.  The communication side of things
here needs y'all to listen as well not just talk at us.

> 2.  better and more testing.  Work more to tap into ongoing fedora
> qa/testing efforts.
>
> 3.  adjust plans/policy wrt kde upgrades.
>  a. implement kde stability proposal as is (to limit 4.x type upgrades to at
> most one per fedora release)
>
>  b. simply do new 4.x versions only for fn+1?  pros: less chance to disrupt
> current installations.  cons:  pushes off the problems to users upgrading to
> fn+1.
>
>  c.  defer any sig decisions, wait for fedora-wide fesco policy/guideline
>

I'm hoping for this as well, if we're supposed to be tracking upstream as
closely as possible, I'll certainly do it though my preference would be
for more stable releases.  Not knowing is really eating away at me.

-Mike
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Orion Poplawski]

On 03/04/2010 07:18 AM, Rahul Sundaram wrote:
> On 03/04/2010 07:27 PM, Kevin Kofler wrote:
>>
>> That said, IMHO the best solution is still to have this stuff in the
>> official updates. But it's true that the kind of issues some users are
>> having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't
>> shown up during testing or it would have been considered a blocker.
>>
>
> The whole point is that you will invariably find such breakage when
> pushing updates like this *after* the release and this is precisely why
> there are huge discussions on this topic and sooner you realize that no
> matter how careful you are you only increase the risks by doing such
> updates mid-release the better off we are towards a reasonable level of
> compromise
>
> Rahul

Kevin/KDE SIG -

I would also like you to consider that simply changing the behavior of a 
system, while not technically a bug or regression, can be frustrating to 
a lot of users (I have reports of different looking panels, different 
task bar graphics behavior).  Especially to sysadmins like myself who 
manage multiple users' systems and have to deal with and explain to the 
users all of the changes that happen.  It is much easier for me to say - 
when is a good time to upgrade to Fn? and the user can prepare for 
changes and time it to not coincide with other deadlines, etc.

And please, just assume like Rahul says that there *will* be 
bugs/regressions that aren't found in testing for major updates like 
this, and take that into consideration.

I'm sure some (most?) of my frustration needs to be directed with KDE 
upstream and their cavalier attitude towards preserving settings and 
data during updates, but I also really don't want to have to deal with 
this any more than I have to.

(Off to track down changes in XRANDR behavior with 4.4.0 )

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Seth Vidal]

On Thu, 4 Mar 2010, Till Maas wrote:

> On Thu, Mar 04, 2010 at 10:26:17AM -0500, Seth Vidal wrote:
>>
>>
>> On Thu, 4 Mar 2010, Till Maas wrote:
>>
>>> On Thu, Mar 04, 2010 at 01:23:30AM -0500, Seth Vidal wrote:
>>>
 Great script here's a small set of changes to have easy-karma use yum as a 
 module
 instead of via subprocess.

 http://skvidal.fedorapeople.org/misc/easy-karma-yum.patch
>>>
>>> There is now a git repo and your patch is included:
>>> http://fedorapeople.org/gitweb?p=till/public_git/fedora-easy-karma.git;a=summary
>
>>   you got a set of things you want to work on there? If there's a TODO I'll
>> see if I can take care of some of them for you.
>
> Thanks, but for my personal use I do not miss anything currently, except
> that it could be faster. But this only hits me, because I am running it
> a lot to test it. But if you want, you can start creating a spec, so it
> can be packaged. Another obvious TODO is to get bodhi_update_str()
> included in the bodhi client in fedora-python.

Where is the module 'fedora_cert' packaged? I can't seem to find it.


> But I have a simple question, is this save to do?
> options.releasever = my.conf.yumvar["releasever"]

yes. it is. I actually just finished putting that in so RELEASE didn't 
need to be defined. :)

-sv

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Till Maas]

On Wed, Mar 03, 2010 at 09:36:53PM -0800, Adam Williamson wrote:

> small nit: if a single update has, say, three packages in it, the script
> presents it for your feedback three times.

This is fixed in the current git release.

Regards
Till


pgp1JcxH9MT6j.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-13 Branched report: 20100304 changes

[Branched Report]

Compose started at Thu Mar  4 09:15:19 UTC 2010

Broken deps for i386
--
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
doodle-0.6.7-5.fc12.i686 requires libextractor.so.1
easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5
edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0
gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12
koan-2.0.3.1-1.fc13.noarch requires mkinitrd
libvirt-qpid-0.2.17-3.fc12.i686 requires qpidc >= 0:0.5.790661
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
matahari-0.0.4-7.fc13.i686 requires qpidc >= 0:0.5.819819
ovaldi-5.5.25-2.fc13.i686 requires libxerces-c.so.28
ovirt-server-0.100-4.fc12.noarch requires qpidd
ovirt-server-0.100-4.fc12.noarch requires qpidc
php-facedetect-1.0.0-4.fc13.i686 requires libhighgui.so.2.0
php-facedetect-1.0.0-4.fc13.i686 requires libcvaux.so.2.0
php-facedetect-1.0.0-4.fc13.i686 requires libcv.so.2.0
php-facedetect-1.0.0-4.fc13.i686 requires libcxcore.so.2.0
player-3.0.1-5.fc13.i686 requires libml.so.2.0
player-3.0.1-5.fc13.i686 requires libhighgui.so.2.0
player-3.0.1-5.fc13.i686 requires libcxcore.so.2.0
player-3.0.1-5.fc13.i686 requires libcv.so.2.0
player-3.0.1-5.fc13.i686 requires libcvaux.so.2.0
qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 
0:0.5.819819-4.fc13
qpidc-server-ssl-0.5.819819-4.fc13.i686 requires qpidc-client-ssl = 
0:0.5.819819-4.fc13
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2



Broken deps for x86_64
--
blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit)
doodle-0.6.7-5.fc12.i686 requires libextractor.so.1
doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit)
easystroke-0.5.2-1.fc13.x86_64 requires 
libboost_serialization-mt.so.5()(64bit)
edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0
edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit)
gnome-python2-totem-2.29.1-4.fc13.x86_64 requires 
libtotem-plparser.so.12()(64bit)
koan-2.0.3.1-1.fc13.noarch requires mkinitrd
libvirt-qpid-0.2.17-3.fc12.x86_64 requires qpidc >= 0:0.5.790661
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit)
matahari-0.0.4-7.fc13.x86_64 requires qpidc >= 0:0.5.819819
ovaldi-5.5.25-2.fc13.x86_64 requires libxerces-c.so.28()(64bit)
ovirt-server-0.100-4.fc12.noarch requires qpidd
ovirt-server-0.100-4.fc12.noarch requires qpidc
php-facedetect-1.0.0-4.fc13.x86_64 requires libcv.so.2.0()(64bit)
php-facedetect-1.0.0-4.fc13.x86_64 requires libcxcore.so.2.0()(64bit)
php-facedetect-1.0.0-4.fc13.x86_64 requires libcvaux.so.2.0()(64bit)
php-facedetect-1.0.0-4.fc13.x86_64 requires libhighgui.so.2.0()(64bit)
player-3.0.1-5.fc13.i686 requires libml.so.2.0
player-3.0.1-5.fc13.i686 requires libhighgui.so.2.0
player-3.0.1-5.fc13.i686 requires libcxcore.so.2.0
player-3.0.1-5.fc13.i686 requires libcv.so.2.0
player-3.0.1-5.fc13.i686 requires libcvaux.so.2.0
player-3.0.1-5.fc13.x86_64 requires libcvaux.so.2.0()(64bit)
player-3.0.1-5.fc13.x86_64 requires libcv.so.2.0()(64bit)
player-3.0.1-5.fc13.x86_64 requires libml.so.2.0()(64bit)
player-3.0.1-5.fc13.x86_64 requires libcxcore.so.2.0()(64bit)
player-3.0.1-5.fc13.x86_64 requires libhighgui.so.2.0()(64bit)
qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qmf-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 
0:0.5.819819-4.fc13
qpidc-server-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel 
= 0:0.5.819819-4.fc13
qpidc-server-rdma-0.5.819819-4.fc13.x86_64 requires qpidc-client-rdma = 
0:0.5.819819-4.fc13
qpidc-server-ssl-0.5.819819-4.fc13.x86_64 requires qpidc-client-ssl = 
0:0.5.819819-4.fc13
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2



New package netsniff-ng
A high performance network sniffer for packet inspection
New package rubygem-thin
A thin and fast web server
Updated Packages:

antlr3-3.2-3.fc13
-
* Tue Mar 02 2010 Miloš Jakubíček  - 3.2-3
- Rebuilt in non-bootstrap mode.

* Sun Jan 31 2010 Milos Jakubicek  - 3.2-2
- Build the doxygen documentation for the C target in a C-docs subpack

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Till Maas]

On Thu, Mar 04, 2010 at 02:40:38PM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Perhaps this could be added into fedora-packager?
> 
> Well, it's useful also for testers (or even just users) who are not 
> packagers, so I'm not sure that's the best place.

I am more in favor of packaging by its own, to make it easy to update
it, but it could be added to the fedora-packager comps group, iirc there
is one.

Regards
Till


pgpdQ5ZecnP5E.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Jaroslav Reznik]

On Thursday 04 March 2010 17:33:20 Orion Poplawski wrote:
> On 03/04/2010 07:18 AM, Rahul Sundaram wrote:
> > On 03/04/2010 07:27 PM, Kevin Kofler wrote:
> >> That said, IMHO the best solution is still to have this stuff in the
> >> official updates. But it's true that the kind of issues some users are
> >> having with KDE 4.4 are unfortunate. This particular Akonadi issue
> >> hasn't shown up during testing or it would have been considered a
> >> blocker.
> > 
> > The whole point is that you will invariably find such breakage when
> > pushing updates like this *after* the release and this is precisely why
> > there are huge discussions on this topic and sooner you realize that no
> > matter how careful you are you only increase the risks by doing such
> > updates mid-release the better off we are towards a reasonable level of
> > compromise
> > 
> > Rahul
> 
> Kevin/KDE SIG -
> 
> I would also like you to consider that simply changing the behavior of a
> system, while not technically a bug or regression, can be frustrating to
> a lot of users (I have reports of different looking panels, different
> task bar graphics behavior).  Especially to sysadmins like myself who
> manage multiple users' systems and have to deal with and explain to the
> users all of the changes that happen.  It is much easier for me to say -
> when is a good time to upgrade to Fn? and the user can prepare for
> changes and time it to not coincide with other deadlines, etc.
> 
> And please, just assume like Rahul says that there *will* be
> bugs/regressions that aren't found in testing for major updates like
> this, and take that into consideration.
> 
> I'm sure some (most?) of my frustration needs to be directed with KDE
> upstream and their cavalier attitude towards preserving settings and
> data during updates, but I also really don't want to have to deal with
> this any more than I have to.

That's the problem - it's just postponed to upgrade from update - you can 
choose one hell from 1. break update, 2. break upgrade. None of this should 
happen. 

> (Off to track down changes in XRANDR behavior with 4.4.0 )

-- 
Jaroslav Řezník 
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc.   http://cz.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Mike McGrath wrote:
> Alternatively, the KDE SIG could stop ignoring the problems that were
> caused this week by the updates they released.  Even an "I'm sorry I broke
> your desktop" would go a long way.  The update the busted my desktop
> happened on a pretty vanilla install, I suspect lots of users experienced
> issues.

Of course we're sorry for the issues caused by our update, and we're doing 
what we can to resolve them as quickly as possible. (For example, we will be 
pushing a kde-settings update to enable Nepomuk by default so that scary 
Akonadi warning goes away. Hopefully that won't cause more chaos, crossing 
fingers. The resource-eating Strigi file indexing will stay disabled by 
default in F11 and F12, of course.)

It's just that it's a more productive use of everyone's time to help fixing 
the issues instead of complaining about what's already done.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: usb_modeswitch by default

[Pete Zaitcev]

On Thu, 04 Mar 2010 01:50:21 +0530
Rahul Sundaram  wrote:

(adding linux-usb to cc:, see below)

> Increasingly a number of broadband connections require usb_modeswitch to
> connect online
> 
> http://who-t.blogspot.com/2010/03/vodafone-australia-mobile-broadband-and.html
> 
> Any opposition to adding this to the base group?

I am strongly opposed. IMHO, using usb_modeswitch is not necessary, and
we should not package its version 1.0.0 or any other version.

The root of the problem here is that someone thought it was a good idea
to make the kernel chase Huawei IDs. But it's not. Even if the linux-next
were taking the IDs as Huawei pops them, without any lag, the distro
kernels simply have no chance to keep up.

Here is the log from Peter's blog:

usb 1-2: new high speed USB device using ehci_hcd and address 6
usb 1-2: New USB device found, idVendor=12d1, idProduct=1520
usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
usb 1-2: Product: HUAWEI Mobile
usb 1-2: Manufacturer: HUAWEI Technology

So, the 0x1520. The 2.6.33 ends with 0x143f. No woder Peter resorts to
usb_modeswitch! And what's the downside for him? My ulcers?

We ought to put a quirk in usb-storage that deals with Huawei in a particular
way. I don't see how screenfuls of garbage in unusual_devs.h is any better
than special-casing in usb_stor_acquire_resources.

If we do not do that, users will continue using usb_modeswitch, and then
all the kernel code that deals with Huawei now amounts to useless waste.

-- Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provide more testing feedback (was: Re: Refining the update queues/process)

[Till Maas]

On Thu, Mar 04, 2010 at 11:34:20AM -0500, Seth Vidal wrote:

> Where is the module 'fedora_cert' packaged? I can't seem to find it.

It is in fedora-packager-0.4.0-1.fc12 from updates-testing.

Regards
Till


pgp7Sganx4A6n.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Kevin Kofler]

Juha Tuomala wrote:
> a) how users are supposed to consume those bugfix releases only,
> when you push feature release in the middle of working week?

What bugfix releases would we be supposed to push? There are no further 
4.3.x releases.

> b) why those different releases exist in the first place, if there is no
> intention to differentiate them?

Because they are needed due to KDE's own development method and schedule? 
That doesn't imply any assumption about what distros package.

And in fact I'd even argue KDE upstream expects users to be using 4.4.x now, 
not 4.3.x, or they'd continue supporting 4.3.x with bugfix releases.

> Speaking of distro decision, you mean that when FESCO decides this
> to stop, KDE SIG will stop it too. That's good.

If FESCo forces us to stop, what else could we do? We're part of Fedora and 
as such we do, and have to, follow Fedora policies. But I'm strongly opposed 
to such a distrowide policy.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Mike McGrath]

On Thu, 4 Mar 2010, Kevin Kofler wrote:

> Mike McGrath wrote:
> > Alternatively, the KDE SIG could stop ignoring the problems that were
> > caused this week by the updates they released.  Even an "I'm sorry I broke
> > your desktop" would go a long way.  The update the busted my desktop
> > happened on a pretty vanilla install, I suspect lots of users experienced
> > issues.
>
> Of course we're sorry for the issues caused by our update, and we're doing
> what we can to resolve them as quickly as possible. (For example, we will be
> pushing a kde-settings update to enable Nepomuk by default so that scary
> Akonadi warning goes away. Hopefully that won't cause more chaos, crossing
> fingers. The resource-eating Strigi file indexing will stay disabled by
> default in F11 and F12, of course.)
>
> It's just that it's a more productive use of everyone's time to help fixing
> the issues instead of complaining about what's already done.
>

Sorry, i guess I wasn't being as clear as I could have been.

I'm not complaining about what's already done.

I'm complaining because it is going to happen again.  I just feel the
issues that have come up could not be spelled out better then they have
and I think the KDE sig has learned no lessons at all from it.

-Mike
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: usb_modeswitch by default

[Dan Williams]

On Thu, 2010-03-04 at 09:44 -0700, Pete Zaitcev wrote:
> On Thu, 04 Mar 2010 01:50:21 +0530
> Rahul Sundaram  wrote:
> 
> (adding linux-usb to cc:, see below)
> 
> > Increasingly a number of broadband connections require usb_modeswitch to
> > connect online
> > 
> > http://who-t.blogspot.com/2010/03/vodafone-australia-mobile-broadband-and.html
> > 
> > Any opposition to adding this to the base group?
> 
> I am strongly opposed. IMHO, using usb_modeswitch is not necessary, and
> we should not package its version 1.0.0 or any other version.
> 
> The root of the problem here is that someone thought it was a good idea
> to make the kernel chase Huawei IDs. But it's not. Even if the linux-next
> were taking the IDs as Huawei pops them, without any lag, the distro
> kernels simply have no chance to keep up.

Yeah, that's a dead-end.  usb_modeswitch is better here since it can be
update much more frequently.

> Here is the log from Peter's blog:
> 
> usb 1-2: new high speed USB device using ehci_hcd and address 6
> usb 1-2: New USB device found, idVendor=12d1, idProduct=1520
> usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
> usb 1-2: Product: HUAWEI Mobile
> usb 1-2: Manufacturer: HUAWEI Technology
> 
> So, the 0x1520. The 2.6.33 ends with 0x143f. No woder Peter resorts to
> usb_modeswitch! And what's the downside for him? My ulcers?
> 
> We ought to put a quirk in usb-storage that deals with Huawei in a particular
> way. I don't see how screenfuls of garbage in unusual_devs.h is any better
> than special-casing in usb_stor_acquire_resources.
> 
> If we do not do that, users will continue using usb_modeswitch, and then
> all the kernel code that deals with Huawei now amounts to useless waste.

The problem is that there are a ton more devices that need modeswitching
than just Huawei, and upstream USB developers are refusing to take
patches that add more devices to the kernel modeswitching code because
they assert it should be done in userspace.  Thus, usb_modeswitch is the
only thing that can handle *all* modems that need modeswitching these
days.  Honestly we should just stop adding new Huawei IDs to
unusual_devs, and just use usb_modeswitch.

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10

[Ville Skyttä]

On Thursday 04 March 2010, Tom "spot" Callaway wrote:
> On 03/04/2010 05:21 AM, Kalev Lember wrote:
> > On 03/04/2010 12:07 PM, Richard Hughes wrote:
> >> On 3 March 2010 21:45, Tom "spot" Callaway  wrote:
> >>> Here are the list of changes to the Fedora Packaging Guidelines:
> >> I've done some updates, and now rpmlint reports:
> >> 
> >> argyllcms.spec: W: no-cleaning-of-buildroot %install
> >> argyllcms.spec: W: no-buildroot-tag
> >> 
> >> Does rpmlint need an update?
> > 
> > Also, should rpmdev-newspec templates get an update to not include
> > buildroot tag?
> 
> Yes, and yes, IMHO.

https://bugzilla.redhat.com/show_bug.cgi?id=519061
https://bugzilla.redhat.com/show_bug.cgi?id=537430
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Rahul Sundaram]

On 03/04/2010 10:08 PM, Jaroslav Reznik wrote:
>
> That's the problem - it's just postponed to upgrade from update - you can 
> choose one hell from 1. break update, 2. break upgrade. None of this should 
> happen. 
>   

It has already happened and it will happen again and again and no amount
of idealistic wishes is going to change that and by postponing
disruptive changes to a new release time you make things more manageable
for users

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to make things better(tm)

[John5342]

On Thu, Mar 4, 2010 at 16:20, Rex Dieter  wrote:
> Mike McGrath wrote:
>
>> Alternatively, the KDE SIG could stop ignoring the problems that were
>> caused this week by the updates they released.  Even an "I'm sorry I broke
>> your desktop" would go a long way.  The update the busted my desktop
>> happened on a pretty vanilla install, I suspect lots of users experienced
>> issues.
>
> To be clear, no one is ignoring anything.  (What a silly thing to say?...
> well, maybe not so silly... means there's a bad pr/perception problem. :( )
>
> Like most any group making hard decisions, the KDE SIG bases them on the
> best information available.  Fact is, we extensively tested this new version
> for over a month, and every serious issue/blocker that was reported or
> identified was addressed prior to releasing this.
>
> Unfortunately, it seems there were more problems than what we were aware of
> when the decision was made to do the 4.4.0 (stable) update.  Yeah, that
> sucks.

Yes there is the odd regression and i have been bitten by the odd one
over time myself but in the vast majority of cases i have had no
regressions at all by the time the updates hit stable. If i wanted an
absolutely rock solid distribution and desktop there are plenty of
other choices out there but i have personally found the improvements
with each update to far out weigh the very occasional regressions and
bugs (that mostly includes the betas and rcs from kde-redhat too).
Keep up the great work.

> So here we are in a bit of a pickle, with many unhappy folks.  Brain dump on
> "how to make things better(tm)" (or for you glass half-empty folks, "how to
> make things suck less(tm)"):
>
> 1.  Improve communication.  Seems there's a bit of disconnected between kde
> sig plans/intentions and the expectations of some significant portion of
> other fedora contributors and user-base.  Also, continue to work toward
> making constructive feedback the obvious and expected norm.  Clearly define
> what this is, and it's intrinsic high value.  imo, folks like to know that
> they are being heard, and to feel that their constructive participation
> yields positive results.
>
> (dunno about everyone else, but this, to me, seems to be the biggest
> "problem" at hand)

A simple way to encourage constructive input from users on both the
state of play and providing more bug reports might be to regularly
(perhaps even daily as soon as a significant update comes along) to
post a list of all the bugs that are reported against the updates
(both blockers and not). That might encourage people to report bugs,
give people an idea of what kind of problems to expect during testing,
feedback from users about what they consider blockers and what not,
give users an idea about how close things are to being released. All
of this information would then be useful for during the meetings to
decide if the updates really are ready in the eyes of the end users.

> 2.  better and more testing.  Work more to tap into ongoing fedora
> qa/testing efforts.

That can never hurt although i would say the testing provided by users
of kde-redhat already provides more useful feedback than the qa team
probably has the resources for.

> 3.  adjust plans/policy wrt kde upgrades.
>  a. implement kde stability proposal as is (to limit 4.x type upgrades to at
> most one per fedora release)

If you do one update like that per release than you may as well do the rest.

>  b. simply do new 4.x versions only for fn+1?  pros: less chance to disrupt
> current installations.  cons:  pushes off the problems to users upgrading to
> fn+1.

I generally keep up to date with the latest release but i would say a
better balance might be just to implement everything in the next
release and kde-redhat as is currently done. Then in the latest
release and just perhaps leave the updates for the most stable release
in testing just a bit longer to make extra sure regressions are fixed
as best as possible.

>  c.  defer any sig decisions, wait for fedora-wide fesco policy/guideline

In my opinion most of fesco has lost it's mind even contemplating the
recent suggestions. Please don't destroy one of Fedora's greatest
strengths for the sake of some morons who want Fedora to be RedHat
with a different colored hat... I am getting fed up of Fedora's latest
identity crisis and if the KDE SIG just turns into a sheep then that
would be the last straw for me.

> 
>
> 99. profit.
>
>
> -- Rex
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to make things better(tm)

[Rahul Sundaram]

On 03/04/2010 11:28 PM, John5342 wrote:
>
> In my opinion most of fesco has lost it's mind even contemplating the
> recent suggestions. Please don't destroy one of Fedora's greatest
> strengths for the sake of some morons who want Fedora to be RedHat
> with a different colored hat... I am getting fed up of Fedora's latest
> identity crisis and if the KDE SIG just turns into a sheep then that
> would be the last straw for me.
>   

While it is alright to criticize positions it is not acceptable to
engage in name calling and please refrain from doing so

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpms/perl-IPTables-ChainMgr/devel perl-IPTables-ChainMgr.spec, 1.6, 1.7

[Miloslav Trmac]

Author: mitr

Update of /cvs/pkgs/rpms/perl-IPTables-ChainMgr/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17158

Modified Files:
perl-IPTables-ChainMgr.spec 
Log Message:
- Drop no longer required references to BuildRoot



Index: perl-IPTables-ChainMgr.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-IPTables-ChainMgr/devel/perl-IPTables-ChainMgr.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-IPTables-ChainMgr.spec 26 Jul 2009 08:46:40 -  1.6
+++ perl-IPTables-ChainMgr.spec 4 Mar 2010 18:23:39 -   1.7
@@ -7,7 +7,6 @@ Group:  Development/Libraries
 URL:http://www.cipherdyne.org/modules/
 Source0:
http://www.cipherdyne.org/modules/IPTables-ChainMgr-%{version}.tar.bz2
 Source1:
http://www.cipherdyne.org/modules/IPTables-ChainMgr-%{version}.tar.bz2.asc
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(IPTables::Parse), perl(Net::IPv4Addr)
@@ -31,8 +30,6 @@ binary instead of having to compile agai
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -53,6 +50,8 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+- Drop no longer required references to BuildRoot
+
 * Sun Jul 26 2009 Fedora Release Engineering  
- 0.9-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
 

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rpms/perl-IPTables-Parse/devel perl-IPTables-Parse.spec,1.6,1.7

[Miloslav Trmac]

Author: mitr

Update of /cvs/pkgs/rpms/perl-IPTables-Parse/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17256

Modified Files:
perl-IPTables-Parse.spec 
Log Message:
Drop no longer required references to BuildRoot



Index: perl-IPTables-Parse.spec
===
RCS file: /cvs/pkgs/rpms/perl-IPTables-Parse/devel/perl-IPTables-Parse.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-IPTables-Parse.spec7 Dec 2009 09:57:05 -   1.6
+++ perl-IPTables-Parse.spec4 Mar 2010 18:24:11 -   1.7
@@ -7,7 +7,6 @@ Group:  Development/Libraries
 URL:http://www.cipherdyne.org/modules/
 Source0:
http://www.cipherdyne.org/modules/IPTables-Parse-%{version}.tar.bz2
 Source1:
http://www.cipherdyne.org/modules/IPTables-Parse-%{version}.tar.bz2.asc
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -28,8 +27,6 @@ rules exist.
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -50,6 +47,8 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+- Drop no longer required references to BuildRoot
+
 * Mon Dec  7 2009 Stepan Kasal  - 0.7-5
 - rebuild against perl 5.10.1
 

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rpms/perl-Net-Ping-External/devel perl-Net-Ping-External.spec, 1.4, 1.5

[Miloslav Trmac]

Author: mitr

Update of /cvs/pkgs/rpms/perl-Net-Ping-External/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17413

Modified Files:
perl-Net-Ping-External.spec 
Log Message:
Drop no longer required references to BuildRoot



Index: perl-Net-Ping-External.spec
===
RCS file: 
/cvs/pkgs/rpms/perl-Net-Ping-External/devel/perl-Net-Ping-External.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Net-Ping-External.spec 7 Dec 2009 19:16:37 -   1.4
+++ perl-Net-Ping-External.spec 4 Mar 2010 18:25:11 -   1.5
@@ -6,7 +6,6 @@ License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Net-Ping-External/
 Source0:
http://www.cpan.org/modules/by-module/Net/Net-Ping-External-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -27,8 +26,6 @@ probably provide more accurate results t
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -53,6 +50,8 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+- Drop no longer required references to BuildRoot
+
 * Mon Dec  7 2009 Stepan Kasal  - 0.12-4
 - rebuild against perl 5.10.1
 

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rpms/perl-Net-RawIP/devel perl-Net-RawIP.spec,1.5,1.6

[Miloslav Trmac]

Author: mitr

Update of /cvs/pkgs/rpms/perl-Net-RawIP/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19442

Modified Files:
perl-Net-RawIP.spec 
Log Message:
* Thu Mar  4 2010 Miloslav Trmač  - 0.25-4
- Filter out bogus Provides: RawIP.so
- Drop no longer required references to BuildRoot



Index: perl-Net-RawIP.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-RawIP/devel/perl-Net-RawIP.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-Net-RawIP.spec 26 Jul 2009 13:44:48 -  1.5
+++ perl-Net-RawIP.spec 4 Mar 2010 18:40:31 -   1.6
@@ -1,22 +1,24 @@
 Name:   perl-Net-RawIP
 Version:0.25
-Release:3
+Release:4%{?dist}
 Summary:Perl extension for manipulating raw ip packets using libpcap
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Net-RawIP/
 Source0:
http://www.cpan.org/modules/by-module/Net/Net-RawIP-%{version}.tar.gz
 Patch0: Net-RawIP-0.23-format.patch
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker), libpcap-devel,
 BuildRequires:  perl(Proc::ProcessTable), perl(Test::Perl::Critic)
 BuildRequires:  perl(Test::Pod), perl(Test::Pod::Coverage)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
+%filter_provides_in %{perl_vendorarch}/auto/Net/RawIP/RawIP.so
+%filter_setup
+
 %description
 This package provides a class object which can be used for creating,
 manipulating and sending raw ip packets with optional features for
-manipulating ethernet headers.
+manipulating Ethernet headers.
 
 %prep
 %setup -q -n Net-RawIP-%{version}
@@ -27,8 +29,6 @@ manipulating ethernet headers.
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -54,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Mar  4 2010 Miloslav Trmač  - 0.25-4
+- Filter out bogus Provides: RawIP.so
+- Drop no longer required references to BuildRoot
+
 * Sun Jul 26 2009 Fedora Release Engineering  
- 0.25-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
 

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Harmless KDE feature upgrades - yeah right

[Przemek Klosowski]

On 03/04/2010 10:15 AM, Kevin Kofler wrote:
>> >  In other words, SIG's current policy is doing more harm than good
>> >  for Fedora.
> Not necessarily. There has also been some very positive feedback for the KDE
> 4.4 updates, and some people are using Fedora BECAUSE such updates get
> pushed.
>

I agree with Kevin that timely software upgrades in Fedora are a GOOD 
thing. The problem is not updates---it's the QA. It just should not 
happen that updates fail to even start up out of the box. I recognize 
that sometimes the problem is caused by the specific system 
configuration, but I have first-hand examples where the app was just 
plain broken. The dilemma of course is what to do in such case: 
currently it's either shipping the app or taking it out of the distro.

Perhaps there should be a RPM property that flagged apps with known 
major bugs, so that the end users could chose between

- always updating everything and dealing with breakage later
- updating only security fixes
- updating only security fixes and 'no-known-defects' apps

Such choice would be a global user-settable system setting, I presume.
Perhaps there could be a separate setting per package group, because it 
would make sense to want the latest versions of engineering apps, while 
leaving email and desktop enough alone.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Adam Williamson]

On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> James Laska wrote:
> > Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> > review determine whether the Fedora 13 Alpha release criteria [1] have
> > been met.  The team agreed that the Alpha criteria have been met, and to
> > proceed with releasing F-13-Alpha-RC4.
> 
> Oh, because a KDE live image which can't be updated without resorting to the 
> command line is obviously ready for release, and because 
> there was clearly no way a RC5 could have been spun in 
> the several days between the availability of the updated kpackagekit build 
> (to match the PackageKit snapshot used in RC4) and this meeting.

I did explicitly explain to you and the other desktop SIGs at the start
of the F13 cycle that, because we just hadn't had time to discuss all
the thorny implications of the question, the desktop criteria would be
considered only with regards to the default desktop. Which is GNOME.

The desktop criteria and validation tests did not exist before F13. It's
extremely unlikely we would ever have blocked any previous Alpha release
because graphical updating failed in *any* desktop. This reflects a
tightening of our release quality standards, not a loosening. In future
I'd like to have all the major desktops (KDE, XFCE, LXDE) considered as
well as just GNOME, but doing so in F13 would have been premature.

I would have liked to do a respin of the KDE live image with the new
kpackagekit, and we did have a brief discussion with releng about that
at the initial go/no-go meeting, but we kind of dropped the ball in the
next few days on that, for which I'm sorry. It wasn't intentional.

> On one hand we have people complaining about the quality of updates, on the 
> other hand we're happily releasing crap we know is broken.

It's an *alpha*. 'Crap we know is broken' is more or less the definition
of alphas. =)

> But of course the GNOME spin "works" (for some definition of "works", they 
> also have a PackageKit issue which was declared not a blocker – 
> https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also 
> affects KPackageKit, by the way –, 

Yeah, it probably does. It's been declared not-blocker because it's
ultimately caused by the langpacks plugin, so there's an acceptable
workaround - uninstall that - which is documented on the CommonBugs
page. Also, it will only happen in a case where there's dependency
problems, so when the available F13 update set is actually *coherent*,
it won't fail.

> and they fail pretty much all the tests 
> for beta or release quality, which I think the KDE spin would actually pass, 

Yup. We don't block Alpha release if it fails the criteria for Beta or
Final. That's the pre-release process working. =) If you look at the
linked bug reports, most of the failures are fairly minor. For instance,
one test 'fails' because if you open System Tools - CD/DVD Creator, drag
in some files and hit 'burn', it crashes nautilus instead of running
Brasero. You can easily run Brasero directly and burn a disc, though.
I'd hope you'd agree that's a perfectly acceptable level of
functionality for an *Alpha* release.

> given that this is the same 4.4.0 we pushed as F11 and F12 updates and works 
> fine there, though I didn't bother testing this as clearly nobody cares 
> about the KDE spin test results anyway), so nobody cares.

I'd hope it would be obvious I *do* care, since I took the trouble to go
around to you and the LXDE and XFCE SIGs and ask if you'd have time to
kindly help fill in the results tables. By the same token, as explained
above, I *did* explain that we're unfortunately not considering the
results as binding on the release schedule for F13. However, having the
results is very useful for us all to know where the release stands, for
us to document significant issues in CommonBugs (I'll document the KDE
update issue there), and to establish the process for future releases
where hopefully it can become binding. Also, if any of the non-default
desktops had been known to be really horribly broken - as in, 'the damn
thing won't start up', or something - we would have considered making
that an Alpha blocker.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Adam Williamson]

On Thu, 2010-03-04 at 14:57 +0100, Kevin Kofler wrote:
> Rahul Sundaram wrote:
> > Whether it would be a separate backports repo or merely some more
> > conservativeness in our update stream
> 
> FWIW, for stuff like KDE, if we don't allow new feature upgrades even in the 
> current stable release nor support an official backports repo, an unofficial 
> one will no doubt spring up

yup, this is very likely. One reason Mandriva's backports repository was
initiated was because, when MDV allowed only conservative updates and
had no official facility for adventurous updates, a forest of
third-party repos offering new versions of things sprung up. Obviously
this led to confusion for people doing user support ('wait, exactly
*whose* KDE 4.3 packages were you running again?') and all sorts of fun
with incompatibilities between the third party repos.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to make things better(tm)

[Kevin Kofler]

John5342 wrote:
> A simple way to encourage constructive input from users on both the
> state of play and providing more bug reports might be to regularly
> (perhaps even daily as soon as a significant update comes along) to
> post a list of all the bugs that are reported against the updates
> (both blockers and not). That might encourage people to report bugs,
> give people an idea of what kind of problems to expect during testing,
> feedback from users about what they consider blockers and what not,
> give users an idea about how close things are to being released. All
> of this information would then be useful for during the meetings to
> decide if the updates really are ready in the eyes of the end users.

We're already doing that (for the big updates like 4.4; we found it not 
needed for the bugfix-only point releases), it's called a "tracker bug", see 
e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=kde-4.4
https://bugzilla.redhat.com/showdependencytree.cgi?id=533921&hide_resolved=0

> In my opinion most of fesco has lost it's mind even contemplating the
> recent suggestions. Please don't destroy one of Fedora's greatest
> strengths for the sake of some morons who want Fedora to be RedHat
> with a different colored hat... I am getting fed up of Fedora's latest
> identity crisis and if the KDE SIG just turns into a sheep then that
> would be the last straw for me.

Let me be clear: while it is not my intention at all to be a "sheep" and 
while I'm strongly opposing that sort of policies, if FESCo were to mandate 
that all Fedora updates may only be to bugfix releases (or worse, that new 
upstream versions are not allowed in updates at all), KDE SIG would not be 
in a position to do something else (in the official Fedora updates; of 
course, kde-redhat is a different story and kde-redhat stable might carry 
the updates Fedora doesn't want anymore). Ignoring the policy would not be a 
workable solution, it could lead to the updates getting rejected or other 
sanctions and it'd also confuse users (e.g. "Why is 4.4.0 in the updates, 
the policy says such updates are not allowed?"). So the only thing we can do 
is to try to prevent such a policy from being passed in the first place.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Harmless KDE feature upgrades - yeah right

[Petrus de Calguarium]

Jaroslav Reznik wrote:

>  So please, Fedora KDE users - comment
>  these changes!

I prefer to get the releases as KDE releases 
them, instead of having to wait... and wait... 
and wait...

I scanned the Stability Proposal document that 
had been linked. Here is what I think:

As I had expected, breaking up the monolithic 
packages into individual packages is a whole lot 
of unnecessary work. Better to provide releases 
as they occur, than to waste time unnecessarily 
breaking down the monolithic packages. To what 
end and benefit? Who, nowadays, doesn't have at 
least one hard drive of at least 80-100GB, likely 
more (I have 3 drives, 2x300GB and1x200GB, the 
latter an old pata that will eventually get 
phased out, and I actually use only about 80GB 
for my own archives! That's a lot of space to 
spare).

I think it is unnecessary to provide the latest 
releases for any releases except the current and 
rawhide. If people don't bother to upgrade to the 
current release, then they obviously don't care 
to run a cutting edge system, so there is no 
point in providing it at the expense of a whole 
lot of work. It only takes an evening to download 
a live cd, install it, and do some rudimentary 
configurations. The rest can be achieved as one 
actually uses the system, so there is no excuse 
for not running the latest release. Considering 
that a lot of the work is done by volunteers (or 
are you, all you redhat/fedora people?), this is 
a fabulous system all for free and not even money 
can purchase anything better.

Yes, it is true that KDE 4 has matured immensely 
and it truly is difficult to notice all of the 
improvements and bug fixes. Nevertheless, I 
personally do enjoy finding the occasional 
irritating quirk disappear after a yum update.

Definitely, old releases should receive only the 
necessary bug fixes, not new features. This is a 
terrible waste of manpower.

Fedora advertises and distinguishes itself from 
other distros by being cutting edge. This is what 
I expect (although I would not likely jump ship, 
were the aforementioned changes implemented), as 
there is no other distro offering cutting edge 
and stability and quality, as fedora does.

To save man-hours, it might be better to scrap 
kde-redhat and just stick to updates and updates-
testing. I would enable updates-testing (and 
sometimes I even pull something off koji 
manually), but many would stick to the safer 
route of just enabling updates.

It is a waste of time for a cutting edge distro 
to support old versions.

I can say, that aside from a very rare scare for 
a night, I have had no reason not to be ecstatic 
about this distro and the benefits of running it. 
No other distro offers what fedora offers.

The musings of an avid fedora user.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Toshio Kuratomi]

On Thu, Mar 04, 2010 at 10:47:28AM -0800, Adam Williamson wrote:
> On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > On one hand we have people complaining about the quality of updates, on the 
> > other hand we're happily releasing crap we know is broken.
> 
> It's an *alpha*. 'Crap we know is broken' is more or less the definition
> of alphas. =)
> 
Just a clarification point:

http://fedoraproject.org/wiki/Alpha_Freeze_Policy
#  At Alpha Milestone, all packages should testable and feature
  complete--whether they are "official features" of the release or not 

So broken, yes.  But the extent of breakage is important.  Breakage that
results in core components being untestable would seem to be blockers under
the current policy -- the result of discussing them would be whether to get
an update into the Alpha Release, revert the broken package, or simply ship
with the untestable piece documented and remember to add more extensive
testing for that at a later point in the cycle.

(Pointing out since F-12 cycle we had people confused about what was
expected of the Alpha release).

-Toshio


pgptLTSdmxykO.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[James Laska]

On Thu, 2010-03-04 at 10:47 -0800, Adam Williamson wrote:
> On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > James Laska wrote:
> > > Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> > > review determine whether the Fedora 13 Alpha release criteria [1] have
> > > been met.  The team agreed that the Alpha criteria have been met, and to
> > > proceed with releasing F-13-Alpha-RC4.
> > 
> > Oh, because a KDE live image which can't be updated without resorting to 
> > the 
> > command line is obviously ready for release, and because 
> > there was clearly no way a RC5 could have been spun in 
> > the several days between the availability of the updated kpackagekit build 
> > (to match the PackageKit snapshot used in RC4) and this meeting.
> 
> I did explicitly explain to you and the other desktop SIGs at the start
> of the F13 cycle that, because we just hadn't had time to discuss all
> the thorny implications of the question, the desktop criteria would be
> considered only with regards to the default desktop. Which is GNOME.
> 
> The desktop criteria and validation tests did not exist before F13. It's
> extremely unlikely we would ever have blocked any previous Alpha release
> because graphical updating failed in *any* desktop. This reflects a
> tightening of our release quality standards, not a loosening. In future
> I'd like to have all the major desktops (KDE, XFCE, LXDE) considered as
> well as just GNOME, but doing so in F13 would have been premature.
> 
> I would have liked to do a respin of the KDE live image with the new
> kpackagekit, and we did have a brief discussion with releng about that
> at the initial go/no-go meeting, but we kind of dropped the ball in the
> next few days on that, for which I'm sorry. It wasn't intentional.
> 
> > On one hand we have people complaining about the quality of updates, on the 
> > other hand we're happily releasing crap we know is broken.
> 
> It's an *alpha*. 'Crap we know is broken' is more or less the definition
> of alphas. =)
> 
> > But of course the GNOME spin "works" (for some definition of "works", they 
> > also have a PackageKit issue which was declared not a blocker – 
> > https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also 
> > affects KPackageKit, by the way –, 
> 
> Yeah, it probably does. It's been declared not-blocker because it's
> ultimately caused by the langpacks plugin, so there's an acceptable
> workaround - uninstall that - which is documented on the CommonBugs
> page. Also, it will only happen in a case where there's dependency
> problems, so when the available F13 update set is actually *coherent*,
> it won't fail.
> 
> > and they fail pretty much all the tests 
> > for beta or release quality, which I think the KDE spin would actually 
> > pass, 
> 
> Yup. We don't block Alpha release if it fails the criteria for Beta or
> Final. That's the pre-release process working. =) If you look at the
> linked bug reports, most of the failures are fairly minor. For instance,
> one test 'fails' because if you open System Tools - CD/DVD Creator, drag
> in some files and hit 'burn', it crashes nautilus instead of running
> Brasero. You can easily run Brasero directly and burn a disc, though.
> I'd hope you'd agree that's a perfectly acceptable level of
> functionality for an *Alpha* release.
> 
> > given that this is the same 4.4.0 we pushed as F11 and F12 updates and 
> > works 
> > fine there, though I didn't bother testing this as clearly nobody cares 
> > about the KDE spin test results anyway), so nobody cares.
> 
> I'd hope it would be obvious I *do* care, since I took the trouble to go
> around to you and the LXDE and XFCE SIGs and ask if you'd have time to
> kindly help fill in the results tables. By the same token, as explained
> above, I *did* explain that we're unfortunately not considering the
> results as binding on the release schedule for F13. However, having the
> results is very useful for us all to know where the release stands, for
> us to document significant issues in CommonBugs (I'll document the KDE
> update issue there), and to establish the process for future releases
> where hopefully it can become binding. Also, if any of the non-default
> desktops had been known to be really horribly broken - as in, 'the damn
> thing won't start up', or something - we would have considered making
> that an Alpha blocker.

To re-emphasize a point Adam made above, users of other desktop
environments are strongly encouraged to participate in community test
runs during release milestones.  As it stands, we have one test result
[1] from the a desktop environment other than GNOME.

While it was explained that the release criteria do not pertain to all
desktop environments for Fedora 13, it would really help to have a more
complete picture of how the criteria might apply to other desktop
environments.  Without the data, it makes deciding whether to extend the
release criteria to these environmen

Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Adam Williamson]

On Thu, 2010-03-04 at 14:22 -0500, Toshio Kuratomi wrote:
> On Thu, Mar 04, 2010 at 10:47:28AM -0800, Adam Williamson wrote:
> > On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > > On one hand we have people complaining about the quality of updates, on 
> > > the 
> > > other hand we're happily releasing crap we know is broken.
> > 
> > It's an *alpha*. 'Crap we know is broken' is more or less the definition
> > of alphas. =)
> > 
> Just a clarification point:
> 
> http://fedoraproject.org/wiki/Alpha_Freeze_Policy
> #  At Alpha Milestone, all packages should testable and feature
>   complete--whether they are "official features" of the release or not 
> 
> So broken, yes.  But the extent of breakage is important.  Breakage that
> results in core components being untestable would seem to be blockers under
> the current policy -- the result of discussing them would be whether to get
> an update into the Alpha Release, revert the broken package, or simply ship
> with the untestable piece documented and remember to add more extensive
> testing for that at a later point in the cycle.
> 
> (Pointing out since F-12 cycle we had people confused about what was
> expected of the Alpha release).

We have various different definitions of the Alpha, it seems. The
working definition that QA / rel-eng have always worked on when deciding
whether to ship it is, broadly, 'can you install it, boot it, get a
network connection, and install updates'. That's what the current Alpha
release criteria and validation tests aim to explicitly codify and
verify.

I'm not particularly sold on the definition in the freeze policy, and
honestly I suspect it's been honored much more in the breach than in the
observance. I'd be very surprised if all planned features of a given
release have ever been fully 'testable' in our Alpha releases. Frankly,
that seems like an unrealistic goal given the timescales we work with,
depending what definition of 'testable' you want to take (there's a huge
amount of wiggle room in that word).

I'd say our practical take on it is that the freeze policy definition
means the maintainers should basically have the major chunks of code
that they're aiming to ship in place by Alpha, but if there's a bug
making it not possible to really use some of them in practice - but that
bug doesn't stop the basic 'install Alpha, get updates' procedure from
working - we're not going to hold the release for that.

To give a practical example, if 'KDE X.Y with shiny new IM client' is
listed as a feature for the Alpha, we'd say the freeze policy requires
the new IM client should actually be present in the Alpha package set.
But we wouldn't say the release should be blocked if there's a bug which
causes it to fail to launch, even though this arguably makes it 'not
testable'. The theory is that there's no point holding the Alpha release
to fix something we can fix equally well in post-Alpha updates, since
there's no net benefit to anyone. But we should probably discuss this in
more detail.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: usb_modeswitch by default

[Pete Zaitcev]

On Thu, 04 Mar 2010 09:00:12 -0800
Dan Williams  wrote:

> The problem is that there are a ton more devices that need modeswitching
> than just Huawei, and upstream USB developers are refusing to take
> patches that add more devices to the kernel modeswitching code because
> they assert it should be done in userspace.  Thus, usb_modeswitch is the
> only thing that can handle *all* modems that need modeswitching these
> days.  Honestly we should just stop adding new Huawei IDs to
> unusual_devs, and just use usb_modeswitch.

Who are these mysterious kernel developers? You don't happen to have
any e-mail saved?

If Greg Kroah rules that we should promote usb_modeswitch, then fine,
let's do that, and drop all Huawei nonsense from kernel. But I haven't
heard anything like that so far. In fact, the party line was exactly
the opposite: eradicate usb_modeswitch.

-- Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel