Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 12:52 AM, James Antill wrote: > On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote: >> My point is that there are plenty of users who want the current updates or >> even more updates. > > "Citation needed" > Just a few out of so many: https://bugzilla.redhat.com/show_bug.cgi?id=529433 https://bugzilla.redhat.com/show_bug.cgi?id=562645 https://bugzilla.rpmfusion.org/show_bug.cgi?id=1066 https://bugzilla.redhat.com/show_bug.cgi?id=457480 http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-January/016353.html Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 6:12 AM, Adam Williamson wrote: > this is a *terrible* idea. We may see users as a 'resource', but they > don't see themselves this way. We should not interrupt their usage of > their computer to try and exploit them to our ends. What if it was an opt-in scheme? Users would consent to receive a limited number of contacts about their current packages and for their trouble would get streamlined access to potential fixes. I think there's enough in that for the opt-in scheme to be marketed successfully, because although some people would see the interactions as annoying, others would welcome the chance to participate. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
2010/2/27 James Antill : > And how many silently cursed the 100s of MBs you forced on them? How > much did the above people appreciate the firehose more than having to > fix one bad update. > F12 is 3 months old and has ~8GB of updates for x86_64, but the > firehose has pumped out 18GB of packages (and that's not including > testing). F11 is 9, is ~12GB but has pumped out 36GB+ (I'm not sure I > have full package stats. from F11 GA). How many users want that? Hell, > how many developers not on rawhide want that? > > But, again, as has been pointed out to you many times now ... the > current proposal is a tiny speed bump in that horrendous amount of > updates. Surprise. We have thousands of packagers (koji knows 1288), we have tens of thousands of packages (17851 available packages in yum), and now you are surprised that yields to a 'firehose' and a 'horrendous' amount of package updates? Instead of being thankful many packagers doing a lot of work, you are trying to slow them down by a 'tiny' speed bump. 'Hell' yeah. Wording is all. I for one, like getting upstream updates fast. If there's potential for breakage (api changes, configuration file format changes, and the like) it would be nice if was warned, or better, it should be opt-in. But that fits perfectly with the rules we have already for stable releases. So again, what's the point here? People fearing the distribution 'doesn't scale'? Whatever that means. Big numbers are not something to worry about. You know, we live in the Petascale era ;) - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 03:11:50AM +0100, Kevin Kofler wrote: > Till Maas wrote: > > I do not remember that I ever wanted to downgrade something except that I > > am still missing kpdf/kprinter, but both went away in a distribution > > upgrade. > > kprinter is still available in the kdebase3 package. (Of course, it's still > the same old KDE 3 stuff, but it's expected to work as well as it always > did.) Ah, that's useful. > For KPDF, it has been replaced by Okular which is a perfectly fine > replacement for me. Is there any specific KPDF feature you're missing in > Okular? Yes, the printing from okular, e.g. this bug report: https://bugs.kde.org/show_bug.cgi?id=181290 Basically I miss every difference in the UI behaviour between kprinter and the printing dialog in okular. E.g. the dialog does not remember to always show the options and it is not possible to save the several complex options that I want to use, e.g. how many pages per sheet, how to duplex, etc. This made me already create a lot of wasted prints. Regards Till pgpeN7OPGhwUA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 12:52:53AM -0500, James Antill wrote: > On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote: > > , those users have very few choices > > And, again, you are wrong. > Rawhide and Debian unstable are both the obvious choices, Gentoo is > still used by some I think. A little more work with a little more > stability then gives you Debian testing and now moving to the latest > Fedora pre-releases. > Yes, those options are less stable than Fedora release should be ... > but you appear to be trying to move Fedora release down to that level > rather than help move them up. > I've known people who want exactly what you seem to profess to want and > use one of the above options. Why don't you? People who want to have Rawhide already could use it, so it is pretty unreasonable to assume that they want the same for Fedora. E.g. there are updates that certainly should happen only in Rawhide, e.g. if they require manual intervention. Afaik this is required regularly for postgres updates, because the format of the database files changes. Regards Till pgpgVy4ojHtlD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 26 February 2010 19:25, Kevin Kofler wrote: [..] > Well, as I wrote, the packager should have tested the package he's pushing > out, of course! Especially for a new package, it's the only way to know it > works. Something that doesn't work at all has no business being pushed to > anywhere, even testing. And yes, checking that the dependencies are all in > Fedora is definitely a good idea, too. (But automated depchecks would solve > that problem once and for all.) > About new package point, what about the negative impact of newly pushed package on distribution as a whole if it breaks to launch or crashes in some event(produced in some essential functionality) and was missed by packager/reviewer (2 people) ? I am in favour of letting this decision made by testing team (folks who contribute for testing in update-testing) based on package importance and availability of contributors. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 26 February 2010 19:58, Orcan Ogetbil wrote: > On Fri, Feb 26, 2010 at 9:24 AM, Michael Schwendt wrote: >> On Fri, 26 Feb 2010 08:26:59 -0500, Orcan wrote: >> >>> Another annoying issue is updates with no explanations. There is a >>> "Notes" field in bodhi that many people just ignore for an unknown >>> reason. Any update with less than a specified number of characters >>> (~40) in the Notes should also be banned. >> >> Nonsense. Such arbitrary rules will only drive off packagers. The field in >> an update request may be empty because the list of bugzilla tickets is >> sufficient and because the package %changelog adds further details. >> > > If those were sufficient, blank Notes wouldn't be annoying, right? But > it is annoying. Hence my proposal. > Fixing some upper limit is obviously not the way to go, but recommending to sum up what this update is for and any useful information is expected from packager. It would make life easy for testers. Making life easier for packagers does not seem to be a valid argument to me. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 08:25 AM, Adam Williamson wrote: > On Sat, 2010-02-27 at 02:09 -0500, Paul Wouters wrote: > >> On Fri, 26 Feb 2010, Adam Williamson wrote: >> >> >>> On Sat, 2010-02-27 at 06:03 +0100, Ralf Corsepius wrote: >>> >>> 2) Recent dnssec-conf updates all did receive several -1, nevertheless these updates were pushed. >>> This is indeed a problem. Obviously, relying on the judgment of >>> maintainers isn't working. >>> >> The karma arrived before it as pushed? I don't think it did. I don't know, I voted -1 at a time it previous votes had accumulated to +2. >> The 1.21-8 >> release fixed the 1.21-7 release of also checking the "very old" config >> file location. >> > Still installing this *-1.21-8 release immediately brought down my local bind. To me, this qualifies as "what ever you did, was insufficient". > Sorry, I was replying in haste. I should've made clear that I was > talking more in general, and don't have any specific direct knowledge of > the dnssec case. I know of multiple cases where updates have been pushed > hastily, but I don't have any direct knowledge of the dnssec case > specifically and wouldn't want to cast any aspersions in anyone's > direction there. > Well, to voting is an inadequate means for judging a package's quality, because bugs showing in individual cases are not co-related to "works for many" - It's a fundamental flaw of the system. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Broken deps in Upgrade from 12 to 13
On Sat, 27 Feb 2010 01:26:22 +0100, Christian wrote:
> Hi,
>
> On 02/21/2010 02:15 AM, Michael Schwendt wrote:
> >Upgrade from 12+updates to 13+updates+testing
> > ==
> [...]
> > Broken packages in fedora-12-x86_64:
> >
> > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires
> > mono(MonoDevelop.Debugger) = 0:2.1.0.0
> > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires
> > mono(MonoDevelop.Core) = 0:2.1.0.0
> > monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires
> > mono(MonoDevelop.AspNet) = 0:2.1.0.0
>
> This may be caused by the fact that monodevelop-debugger-mdb used
> "ExclusiveArch: %ix86" in F12 and
> "ExclusiveArch: %ix86 x86_64 ia64 armv4l sparcv9 alpha s390 s390x" in
> F13 and the devel branch.
No, because then the F13 build would update the F12 build. Above you can
see a package .fc12.i686 in the fedora-12-x86_64 repo, however.
> What would be the appropriate fix here?
Self-obsoletes or an arch-specific %{?_isa} base pkg dep.
It depends on how these Mono packages are supposed to work.
$ rpmls -p monodevelop-debugger-mdb-devel-2.2.1-1.fc13.i686.rpm
-rw-r--r-- /usr/lib/pkgconfig/mono.debugging.backend.mdb.pc
It contains only a pkg-config file and hence doesn't have any automatic
arch-specific dependency on the base package. monodevelop-devel also contains
only pkg-config files.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On Fri, Feb 26, 2010 at 03:54:02PM -0700, Kevin Fenzi wrote: > b. Given a, I would say people should stop posting to this thread. If > you have a better updates policy in mind, perhaps you could draft up a > proposal for what you think it should be? Or wait for a real proposal > to comment on? Since AutoQA is supposed to to behaviour testing of packages eventually, how about a policy that says: A stable update to Fedora must pass all AutoQA tests. Then the granularity of stability can be adjusted by adding tests to AutoQA. And I hope that only reasonable tests will be added to AutoQA, e.g. a test that just ensures that a packages stays at version X would not be one. But if it ensures that e.g. "yum-builddep foo.src.rpm" installs all build deps of foo, it would be a useful test. > - I think educating our maintainers to be more carefull or get more > testing feedback has not worked so far, nor is it likely to moving > forward. We simply seem to lack the communications channel to do so. If the maintainer receive more testing feedback, they probably won't ignore it. > - I think perhaps a more lifecycle like thing could help our users know > what to expect. Currently, they don't. They could get a major version > bump at any time, in a older "stable" release. I have talked to users > who are are f11 still because they think it will be "most stable" but > then are dismayed with how many updates they get. Pushing less updates to F(current-1) is probably something many maintainers can live with. But I have also heard of people using F(current-1) and feeling like secondary users, because they did not get the updates that F(current) got. > - Perhaps we could look at ways to make rawhide more day to day > friendly. I think the autoqa stuff might help here. If those people > that needed the very newest version of everything could use rawhide, > perhaps we could target the stable releases more to those that want > them. There will always be updates in Rawhide that are not meant to be consumed directly or without manual intervention. Regards Till pgpnh11xlZwK9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 05:28:26PM -0800, Adam Williamson wrote:
> On Fri, 2010-02-26 at 19:53 +0100, Till Maas wrote:
> > On Fri, Feb 26, 2010 at 10:01:56AM -0800, Jesse Keating wrote:
> > > On Fri, 2010-02-26 at 18:56 +0100, Till Maas wrote:
> > > >
> > > > Something I am dreaming about is to have some infrastructure to
> > > > automatically test packages, so mabye they could build that first and
> > > > then write tests for packages.
> > >
> > > The AutoQA project is in full swing, developing just that, a framework
> > > to test packages in an automated fashion.
> >
> > Ah, that's great. I thought it was only supposed to test packages
> > metadata etc, but not the behaviour of programs inside them. Is it
> > already possible to write a test that installs each packages that
> > contains a binary and ensures that it does not segfault when it is
> > called without arguments or with -h,--help,-? ideally for different
> > locales?
>
> In addition to Jesse's reply, AutoQA is a framework for tests. You can
> theoretically run almost any type of test through AutoQA. Essentially
> it's just a little machine for running a bunch of arbitrary commands at
> specified times, and saving the results somewhere. It's by nature very
> flexible, and there's not a lot of restrictions on what the tests you
> can run within the AutoQA framework actually *do*.
Ok, maybe the question should be then: How much does AutoQA support me
writing these tests? E.g. this test is pretty simple, but afaics there
is no easy support for the common tasks that are needed to run the test,
but not really part of the test, e.g. installing the package or setting
up a machine.
The Writeing AutoQA Tests wiki page[0] says:
| I'll say it again: Write the test first. The tests don't require
| anything from autotest or autoqa. You should have a working test before
| you even start thinking about AutoQA
But this is not really supportive, because if I want to test a packages,
I need a framework that creates the initial environment, e.g. a system
of the Fedora version to be tested with the package installed and there
needs to be a way to interact with the programs.
Or is this really a test I can easily integrate into AutoQA currently?
Say we start without locales and commandline arguments, then the test
would be:
Input: Package to be tested as ${PACKAGE}
for binary in $(rpm -ql ${PACKAGE} | grep bin); do ${binary} 2>&1 | grep
"Segmentation fault" && echo "test failed" ; done
Regards
Till
[0] https://fedoraproject.org/wiki/Writing_AutoQA_Tests
pgpfJzvG9ajdN.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Okular printing (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Till Maas wrote: > Yes, the printing from okular, e.g. this bug report: > https://bugs.kde.org/show_bug.cgi?id=181290 Hmmm, that's an interesting one… > Basically I miss every difference in the UI behaviour between kprinter > and the printing dialog in okular. E.g. the dialog does not remember to > always show the options and it is not possible to save the several > complex options that I want to use, e.g. how many pages per sheet, how > to duplex, etc. This made me already create a lot of wasted prints. For saving options, you can now set the printer defaults at CUPS level, Qt will pick them up now (we fixed that in our KDE 4.4 update set). That said, I'm not sure Okular supports all of them due to the FilePrinter hack it's using. But this is kinda OT for this list and we have strayed far far away from the original subject of this thread. If you want to discuss this further, please use the fedora-kde list. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Orion Poplawski wrote: > I certainly can't see the need for it to appear in F11 (isn't the fact > that someone hasn't bothered upgrading to F12 indication that they are > looking for a little stability?). We're evaluating the option of not doing the updates for the oldstable [1] releases. We can see the rationale: * people who haven't upgraded to the current stable might indeed also not want a newer KDE, * updates for the oldstable release also tend to get much fewer testing, * people can always upgrade to the current stable release to get the current KDE, * it limits the big KDE upgrades to 1/release instead of 2/release as now, but it also has drawbacks: * it means we have to maintain 2 separate KDE sets, or even 3 when we import prereleases of the next KDE into Rawhide, instead of the current 1 or 2, * there's the issue of bugfixes: - not all bugfixes are backported to the stable branch upstream, sometimes they can't be backported upstream because they require e.g. a new Qt, because they add translatable strings or for whatever reason, - upstream stops releasing 4.n.x bugfix releases as they release 4.n+1.0, => therefore, upgrading to 4.n+1 is the easiest way, and sometimes the only practical one, to get those bugfixes. We'd be stuck with either bugs no longer getting fixed or us having to massively backport bugfixes, which I'm not convinced we have the manpower for (I don't think any distro has, really; those distros which don't do upgrades backport only select few bugfixes, sometimes only security fixes). The question is: is this a price we want to pay? I always feel bad for leaving issues unsolved, but of course introducing new issues is also not a nice thing to do. ;-) Personally, I'm not convinced that not upgrading is a good idea (e.g. I used F9 until EOL and 4.2 was really great there, then I went to F10 and used that until its EOL with 4.3 and that also worked great), but this option IS being evaluated in KDE SIG. [1] Yes, I'm stealing Debian terminology here. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Chris Adams wrote: > IMHO you're developing the wrong distro. It is statements like yours > that contribute to the "Fedora is a rolling beta" perception (and I > don't think that's a good perception to have). If you want to target > rawhide with rolling releases of KDE, have fun. Once a release is out > the door, try not to just throw a new kitchen sink in for the hell of > it. Some people actually LIKE rolling releases, indeed some distros use completely rolling releases (e.g. Arch Linux). We are currently somewhere inbetween (partly release-based, partly rolling), and IMHO this compromise is working great. We get the advantages from a rolling release model, but with a lot less surprise breakage as in a true rolling model because disruptive changes like libata go only into new releases. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: > And, again, you are wrong. > Rawhide and Debian unstable are both the obvious choices, Gentoo is > still used by some I think. A little more work with a little more > stability then gives you Debian testing and now moving to the latest > Fedora pre-releases. > Yes, those options are less stable than Fedora release should be ... > but you appear to be trying to move Fedora release down to that level > rather than help move them up. > I've known people who want exactly what you seem to profess to want and > use one of the above options. Why don't you? Because that comes with some types of disruptive changes which we do not perform in releases and which I do not advocate performing in releases. Rolling releases like Rawhide, Debian unstable, Gentoo etc. have no set points to do disruptive changes. So e.g. you wake up in the morning and your system no longer boots because your kernel upgrade from yesterday enabled libata and you had hd* hardcoded in some place. (Yes, I know that particular change is now a done deal, but there will definitely be similar changes in the future.) As I have explained several times, AIUI, a stable release MUST NOT get upgrades which "break things", e.g.: * require manual adjustment to config files, databases etc., * break support for existing user data (documents, configuration, savegames etc.), * knowingly introduce regressions, * remove features, * radically change the UI (but I don't think minor changes like a menu entry moving to a different place are a serious issue), * bump the soname of a core library on which dozens of packages depend (but I don't personally see a grouped update with a soname change and a rebuild of ALL packages using that library as a problem as long as it's only for a few packages), * change the API of a library in a way that existing applications using it fail to rebuild and cannot easily be fixed (in fact soname bumps MUST be accompanied by rebuilds of everything affected) etc. (and I think we all agree there. But that's why Rawhide is not the answer!), but IMHO (and there opinions differ), it SHOULD get upgrades which: * fix bugs, even if they're not critical or security, * introduce features in a non-disruptive, backwards-compatible way (e.g. there's now a new menu entry which does something cool, at worst that new menu entry might not work perfectly, but it shouldn't affect anything else). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Orion Poplawski wrote: > There is plenty of room for something in between your vision of Fedora > and CentOS. But that room is filled by other distros, such as Ubuntu. Why do we need to be another Ubuntu? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Ralf Corsepius wrote: > Again, one key to providing good quality packages is "not let bugs hit > your users". > > In many cases this means, "pushing upstream updates" because upstream > has fixed some known bugs, Fedora users haven't reported yet. > > It would be utterly silly and grossly negligent to demand package > maintainers to only provide updates on "bugs having hit Fedora users". Right. It's not because a bug is not in our Bugzilla that it won't affect our users. If upstream fixes a bug, there must have been a bug in the first place, and only in rare occasions it doesn't affect Fedora, usually it does. > Users typically are interested in seeing "their bugs" fixed and are > testing their use-cases, but are not "testers in general". > > I.e. they typically will pickup patches or packages and try them in > their use-cases, but they will not regularily pull the "testing repos". Indeed, only few people systematically use updates-testing. If it were suitable for general consumption, it would be called "stable". :-) So once again we're in violent agreement. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Oh, and by the way: Orion Poplawski wrote: > There is plenty of room for something in between your vision of Fedora > and CentOS. There is plenty of room for something in between your vision of Fedora and Rawhide. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Rakesh Pandit wrote: > About new package point, what about the negative impact of newly > pushed package on distribution as a whole if it breaks to launch or > crashes in some event(produced in some essential functionality) and > was missed by packager/reviewer (2 people) ? It won't automatically break anybody's existing system. It may break things for people installing it, but those people are installing the package for a reason, and it's generally better to have a package which MAY be broken (but probably works just fine) than not to have it at all. Now OK, pushing out something that doesn't work at all is a bad idea, but normally a new package which gets pushed was tested by at least 1 or 2 people (the submitter and/or the reviewer). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Paul W. Frields wrote: > How'd it happen? I commented directly in the Bugzilla bugs with the > link and told the subscribers to the bugs that the package would not > be issued until some of them tested it and posted feedback to tell me > their bugs were fixed. I see why you're doing it, but still, this is essentially blackmailing users, I'm not sure it's a good plan to follow. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Chris Adams wrote: > Once upon a time, Bruno Wolff III said: >> P.S. I don't use enablerepo. I'll yum install a local copy of the rpm and >> see what it needs if it doesn't install successfully. > > That seems like extra and unnecessary work. You doesn't do anything > without telling you, so "yum --enablrepo=\*testing update foo" is going > to tell you more about what dependencies are needed than "yum > localinstall foo.rpm". But the localinstall is actually less dangerous. Let's say you want to update package X from Rawhide. The new version of X now uses a library Y which is available in both the stable release and Rawhide. Using enablerepo will pull in the Rawhide version of Y, which may drag in more Rawhide stuff. The localinstall will use the release version of Y. This also applies to updates-testing, but to a lesser extent. On the other hand, X might not be tested with the old version of Y. So there are drawbacks to everything. Selective updates are necessarily unreliable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Friday 26 February 2010, Till Maas wrote: > On Fri, Feb 26, 2010 at 01:12:53PM -0500, James Antill wrote: > > On Fri, 2010-02-26 at 17:14 +0100, Till Maas wrote: > > > Also repoquery returns F12 results but accepts --releasever: > > > $ repoquery --releasever=rawhide --repoid=fedora kernel > > > kernel-0:2.6.31.5-127.fc12.x86_64 > > > > Yes, it's a 3.2.26+ feature. It's likely that F12 will get a yum update > > eventually ... and you can get a 3.2.26+ yum from rawhide now. So for > > ideas about changing how rawhide works, that's not a big requirement is > > it? > > Yes, it is not a big requirement. Nevertheless I can wonder why it does > not work in repoquery, even though it is in the --help output. It did not work with yum 3.2.26 installed either. Fixed in git now (should work with yum >= 3.2.24 installed). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Sat, Feb 27, 2010 at 03:00:39PM +0200, Ville Skyttä wrote: > On Friday 26 February 2010, Till Maas wrote: > > On Fri, Feb 26, 2010 at 01:12:53PM -0500, James Antill wrote: > > > On Fri, 2010-02-26 at 17:14 +0100, Till Maas wrote: > > > > > Also repoquery returns F12 results but accepts --releasever: > > > > $ repoquery --releasever=rawhide --repoid=fedora kernel > > > > kernel-0:2.6.31.5-127.fc12.x86_64 > > > > > > Yes, it's a 3.2.26+ feature. It's likely that F12 will get a yum update > > > eventually ... and you can get a 3.2.26+ yum from rawhide now. So for > > > ideas about changing how rawhide works, that's not a big requirement is > > > it? > > > > Yes, it is not a big requirement. Nevertheless I can wonder why it does > > not work in repoquery, even though it is in the --help output. > > It did not work with yum 3.2.26 installed either. Fixed in git now (should > work with yum >= 3.2.24 installed). \o/ Thank you, with this patch it works in F12: http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=f0bee60c3fc81325e547d0f8bf42591368d18ee4 Regards Till pgplWrDVeZ2qo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Saturday 27 February 2010, Kevin Kofler wrote: > Rakesh Pandit wrote: > > About new package point, what about the negative impact of newly > > pushed package on distribution as a whole if it breaks to launch or > > crashes in some event(produced in some essential functionality) and > > was missed by packager/reviewer (2 people) ? > > It won't automatically break anybody's existing system. It may break things > for people installing it, but those people are installing the package for a > reason, [...] That "reason" could be a bad Obsoletes in the new package. And even the new Name and Provides from the new package may result in it being pulled in along with other updates to satisfy dependencies without being explicitly asked for. When either of these happens, it in my opinion qualifies as the new package being installed automatically, and because there are several ways new installed packages can break existing systems, the combined results is that it is very much possible for newly introduced packages to "automatically break existing systems". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
Till Maas wrote: > Pushing less updates to F(current-1) is probably something many > maintainers can live with. But I have also heard of people using > F(current-1) and feeling like secondary users, because they did not get > the updates that F(current) got. Yes. IMHO the old stable release deserves the same level of support as the current one. As long as it's supported, it should get updates. People may not be ready for the disruptive changes in the current stable release, that doesn't mean they don't want to continue receiving the non-disruptive updates! (So I'm also not a fan of the suggestion to only push KDE upgrades to the current stable release and not the previous stable one.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 08:45:11PM -0700, Orion Poplawski wrote: > >> > > Those people should use a more conservative distribution. Try CentOS maybe. > > Frequent updates are an integral part of the Fedora experience. > > > There is plenty of room for something in between your vision of Fedora > and CentOS. I strongly disagree that frequent updates are an integral > part of the Fedora experience. I don't think that the point here is the stability of the distribution. I am very in favor of a stable distro, and on that point, I think that I side more with you than with Kevin K. But, in my opinion, having a policy that renders pushing to stable harder is not a good move, at least for many packages, since for those packages there is no real test done in updates-testing, and they are specialized packages so that there little chance of attracting more testers. Having such a policy for critical packages or packages with a large user base, and so a large number of testers, why not, but I don't think that it should be a general policy. At least I know that for the packages I maintained (and you now maintain a fair share of those packages ;-), such a policy would have been very unproductive. In fact, I think that I would be in favor of selecting a set of important packages that would have specific procedures for update, but not for all fedora packages. Good candidates would be rpm, kernel, yum, hal, X, gnome libraries, gtk, kde libraries for the packages that are critical. openoffice, firefox, the gnome and kde desktops, fluxbox would certainly qualify as huge userbase software that may also have more requirements on updates testing since they are likely to attract users. But definitly not the packages with low userbase (for example, most of the scientific related packages, dockapps, xdm...). -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Ville Skyttä wrote: > That "reason" could be a bad Obsoletes in the new package. That's why I said "new packages that don't replace anything" in my original message. If they Obsolete something else, then they're not really new packages. > And even the new Name and Provides from the new package may result in it > being pulled in along with other updates to satisfy dependencies without > being explicitly asked for. Well, true, new packages which Provide some common virtual Provides like bluez-dbus-pin-helper also need the same scrutiny as upgrades to explicit packages. That's not the common case though, and it happening due to Name alone is very unlikely (it would mean something else Provides that name and a third package depends on it by name). > When either of these happens, it in my opinion qualifies as the new > package being installed automatically, and because there are several ways > new installed packages can break existing systems, the combined results is > that it is very much possible for newly introduced packages to > "automatically break existing systems". New packages which don't Obsolete existing packages or Provide existing provided names cannot cause any of the above. (They may technically trigger broken triggers, but it's extremely unlikely that an existing package has a trigger on something not previously in Fedora. If it's an outright malicious trigger, like "delete everything if somebody installs package foo", then we have a much bigger problem than update stability!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 02:08 AM, Kevin Kofler wrote: > Matthew Garrett wrote: >> At the point where you have a reported bug, you have a tester. > > Not necessarily. Sadly, there are people who report bugs and then don't read > their bugmail, ever. :-( Also does not apply to * sporadic bugs. * non-deterministic bugs (c.f. pulseaudio) * bugs caused by cross-effects of other packages (c.f. dbus, kernel-bugs' impact on applications) * users, who start to modify their use-case, because they desparately are searching for an escape (c.f. dnssec-conf) => No easy reproducer/tester, anymore. * bugs being closed as "FIXED UPSTREAM/FIXED RAWHIDE" - This kind of "resolution" means a bug is not being fixed in the distro. It means the maintainer is refusing to fix a bug a reporter is facing. Reporters will learn their lessons and leave this kind of maintainers alone. Less patient reporters will leave Fedora alone. * maintainers not responding in timely manners. In this case a system's setup (e.g. set of installed packages) might have changed sufficiently a reporter is not able to reproduce a bug. In extreme cases, the reporter might not even recall a report he issued. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
opencv 2.0.0 soname change
Branches affected: F-13 and devel Since OpenCV has deleted few weeks ago the autotools based build system, we will switch to cmake : https://code.ros.org/trac/opencv/changeset/2528 The main issue is that the two build system set two different sonames (2.0.0 for cmake, 4.0.0 for autotools). OpenCV 2.0 is present in Fedora since F-13 (which has not been released) and OpenCV folks have settled the issue by ditching autotools based build system. https://code.ros.org/trac/opencv/ticket/5 This allows us to follow more closely upstream (which i hope will be more careful about soname issue) and should avoid us soname issue in stable release. It must be fixed before F-13 release. packages concerned: frei0r-plugins kipi-plugins mrpt-apps mrpt-core php-facedetect player (maintainers were already add to the CC list) If you're concerned, please add yourself to the following ticket #569005 and tell us when your package has been rebuilt. https://bugzilla.redhat.com/show_bug.cgi?id=569005 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100226 changes
On Fri, Feb 26, 2010 at 02:04:20PM +, Rawhide Report wrote: > Broken deps for i386 > -- > geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0 > Broken deps for x86_64 > -- > geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0 > geglmm-0.1.0-3.fc13.x86_64 requires libgegl-0.0.so.0()(64bit) I pushed a rebuild of geglmm to rawhide that should fix these broken deps: http://koji.fedoraproject.org/koji/buildinfo?buildID=158923 Dodji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On 26 February 2010 22:54, Kevin Fenzi wrote: > - If stable pushes were more restricted, perhaps that would get us more > testing? If someone required a newer version and could easier > install/test from updates-testing and provide feedback, don't we all > win? Perhaps we could have PackageKit/yum say "you have the latest > stable version of foo, but foo-2.0 is in updates-testing, would you > like to test it and provide feedback? I had PK code to do that, but the check for updates took way too long, as the updates-testing repo had to be enabled, the primaries downloaded (and maybe the file lists too), updates resolved and then disabled again, in ADDITION to the normal updates check. The package manager is just too slow to get PackageKit data to make such a thing work without making the user wait an extra 30 seconds. If we could speed up the dep checking and downloading, I agree it would be better for usability, and the exposure of updates-testing generally. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: opencv 2.0.0 soname change
On 27 February 2010 20:24, Haïkel Guémar wrote: > Branches affected: F-13 and devel > > > Since OpenCV has deleted few weeks ago the autotools based build system, > we will switch to cmake : > https://code.ros.org/trac/opencv/changeset/2528 > [..] Are you kidding ? No *communication* :( At this stage we never wanted an update for any reason, nor extra work for lot of other folks. Alas I had some more time at hand. -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Kevin Kofler wrote: > Chris Adams wrote: > > IMHO you're developing the wrong distro. It is statements like yours > > that contribute to the "Fedora is a rolling beta" perception (and I > > don't think that's a good perception to have). If you want to target > > rawhide with rolling releases of KDE, have fun. Once a release is out > > the door, try not to just throw a new kitchen sink in for the hell of > > it. > > Some people actually LIKE rolling releases, indeed some distros use > completely rolling releases (e.g. Arch Linux). We are currently somewhere > inbetween (partly release-based, partly rolling), and IMHO this compromise > is working great. We get the advantages from a rolling release model, but > with a lot less surprise breakage as in a true rolling model because > disruptive changes like libata go only into new releases. > If only we had some sort of rolling release, that tracked as closely with upstream as possible, where the users of said release understood they were drinking from the firehose. Meanwhile, along side that release we could have periodic stable releases that don't move so quickly. That way you get what you want and I get what I want. Oh wait! That's the world we live in today. Next time a user tells you "I want a newer X" tell them "Upgrade to rawhide". -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Mike McGrath wrote: > On Sat, 27 Feb 2010, Kevin Kofler wrote: > > > Chris Adams wrote: > > > IMHO you're developing the wrong distro. It is statements like yours > > > that contribute to the "Fedora is a rolling beta" perception (and I > > > don't think that's a good perception to have). If you want to target > > > rawhide with rolling releases of KDE, have fun. Once a release is out > > > the door, try not to just throw a new kitchen sink in for the hell of > > > it. > > > > Some people actually LIKE rolling releases, indeed some distros use > > completely rolling releases (e.g. Arch Linux). We are currently somewhere > > inbetween (partly release-based, partly rolling), and IMHO this compromise > > is working great. We get the advantages from a rolling release model, but > > with a lot less surprise breakage as in a true rolling model because > > disruptive changes like libata go only into new releases. > > > > If only we had some sort of rolling release, that tracked as closely with > upstream as possible, where the users of said release understood they were > drinking from the firehose. Meanwhile, along side that release we could > have periodic stable releases that don't move so quickly. That way you get > what you want and I get what I want. Oh wait! That's the world we live > in today. Next time a user tells you "I want a newer X" tell them > "Upgrade to rawhide". > Or to put it another way, why aren't you doing this and telling others to do this? If someone is on F11 still, why do you think they want the latest and greatest software? If they did, they'd upgrade to f12. And further still, why wouldn't they be running rawhide? The rolling update release exists. Why force rolling updates on people that haven't chosen to run rawhide? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 09:44:11AM -0600, Mike McGrath wrote: > On Sat, 27 Feb 2010, Mike McGrath wrote: > > > On Sat, 27 Feb 2010, Kevin Kofler wrote: > > > > > Chris Adams wrote: > > > > IMHO you're developing the wrong distro. It is statements like yours > > > > that contribute to the "Fedora is a rolling beta" perception (and I > > > > don't think that's a good perception to have). If you want to target > > > > rawhide with rolling releases of KDE, have fun. Once a release is out > > > > the door, try not to just throw a new kitchen sink in for the hell of > > > > it. > > > > > > Some people actually LIKE rolling releases, indeed some distros use > > > completely rolling releases (e.g. Arch Linux). We are currently somewhere > > > inbetween (partly release-based, partly rolling), and IMHO this compromise > > > is working great. We get the advantages from a rolling release model, but > > > with a lot less surprise breakage as in a true rolling model because > > > disruptive changes like libata go only into new releases. > > > > > > > If only we had some sort of rolling release, that tracked as closely with > > upstream as possible, where the users of said release understood they were > > drinking from the firehose. Meanwhile, along side that release we could > > have periodic stable releases that don't move so quickly. That way you get > > what you want and I get what I want. Oh wait! That's the world we live > > in today. Next time a user tells you "I want a newer X" tell them > > "Upgrade to rawhide". > > > > > > Or to put it another way, why aren't you doing this and telling others to > do this? If someone is on F11 still, why do you think they want the > latest and greatest software? If they did, they'd upgrade to f12. And > further still, why wouldn't they be running rawhide? The rolling update > release exists. Why force rolling updates on people that haven't chosen > to run rawhide? Did you read what he wrote? I feel tempted to just copy the paragraph Kevin wrote again, because it already answers your question: Rawhide is not partly rolling as Fedora is. And a typical reason not to upgrade from F(current-1) to F(current) is because the major updates may make systems unusable, e.g. X not working anymore. But this does not mean that the same person does not want bugfixes for e.g. yum-builddep installing build dependencies again. Regards Till pgpL2CZg2MOO7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 02:55:41PM +0100, Kevin Kofler wrote: > > New packages which don't Obsolete existing packages or Provide existing > provided names cannot cause any of the above. (They may technically trigger Special care should be given to the auto-generated Provides. I remember a package of mine that messed up the buildroot because of a perl auto-generated provides that happened because my package had a private copy of a perl module... Anyway, I don't think that new packages are very relevant to the issue, because * they can sit in testing for some time, they are new package, it is not as if they fix something * the review is already a thorough review of the 'update', so when errors happen, they are, in my opinion, more a failure of the review than of the update system. Of course, dependencies of updated packages that must enter rapidly because the update of the dependent package is important should certainly require more scrutiny. I remember vaguely that a new package that entered as a dependency of an updated package caused issues in the past. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 08:45 +, Camilo Mesias wrote: > On Sat, Feb 27, 2010 at 6:12 AM, Adam Williamson wrote: > > this is a *terrible* idea. We may see users as a 'resource', but they > > don't see themselves this way. We should not interrupt their usage of > > their computer to try and exploit them to our ends. > > What if it was an opt-in scheme? Users would consent to receive a > limited number of contacts about their current packages and for their > trouble would get streamlined access to potential fixes. > > I think there's enough in that for the opt-in scheme to be marketed > successfully, because although some people would see the interactions > as annoying, others would welcome the chance to participate. Yup, anything making it easier for people who actively choose to participate in testing to actually do the testing and provide their feedback would be fantastic. -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 10:57 +0100, Ralf Corsepius wrote: > > Sorry, I was replying in haste. I should've made clear that I was > > talking more in general, and don't have any specific direct knowledge of > > the dnssec case. I know of multiple cases where updates have been pushed > > hastily, but I don't have any direct knowledge of the dnssec case > > specifically and wouldn't want to cast any aspersions in anyone's > > direction there. > > > Well, to voting is an inadequate means for judging a package's quality, > because bugs showing in individual cases are not co-related to "works > for many" - It's a fundamental flaw of the system. Yeah, it's not perfect: there are cases where we have, say, a complex kernel update which works fine for most people but causes a significant regression for some particular bit of hardware. We wouldn't want to put that update out, but it's easy for it to get five +1s before someone with the specific bit of hardware comes by and gives it a -1...and even then, +4 looks good if you're not reading the feedback too carefully. So yeah, I agree it's not a perfect system - detailed suggestions for improving it would be welcome, I'm sure. I don't think 'not perfect' is the same as 'useless', though. I think it's pretty easy to make a case that Bodhi has had a significant positive impact on the overall quality of the updates that have fully utilized it. It rarely makes things *worse* :) -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 03:13 AM, Orcan Ogetbil wrote: > On Sat, Feb 27, 2010 at 12:52 AM, James Antill wrote: >> On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote: >>> My point is that there are plenty of users who want the current updates or >>> even more updates. >> >> "Citation needed" >> > > Just a few out of so many: > https://bugzilla.redhat.com/show_bug.cgi?id=529433 > https://bugzilla.redhat.com/show_bug.cgi?id=562645 > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1066 > https://bugzilla.redhat.com/show_bug.cgi?id=457480 > http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-January/016353.html > > Orcan I do want updates. Kernel updates, for example, are very important - they carry many improvements - not just drivers but functionality as well. The ones that are less obvious are the bugs that happen rarely but that can be nasty (an occasional file system glitch for example). The rare-but-nasty bug fixes will seldom have user demand - but nonetheless once identified and fixed should be shared. These kind of non-user-demand driven fixes should not be ignored in any noone-is-asking so dont release approach. [speaking of which where on earth is 2.6.32.9 ] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 11:41 +0100, Till Maas wrote:
> Ok, maybe the question should be then: How much does AutoQA support me
> writing these tests? E.g. this test is pretty simple, but afaics there
> is no easy support for the common tasks that are needed to run the test,
> but not really part of the test, e.g. installing the package or setting
> up a machine.
>
> The Writeing AutoQA Tests wiki page[0] says:
> | I'll say it again: Write the test first. The tests don't require
> | anything from autotest or autoqa. You should have a working test before
> | you even start thinking about AutoQA
>
> But this is not really supportive, because if I want to test a packages,
> I need a framework that creates the initial environment, e.g. a system
> of the Fedora version to be tested with the package installed and there
> needs to be a way to interact with the programs.
>
> Or is this really a test I can easily integrate into AutoQA currently?
> Say we start without locales and commandline arguments, then the test
> would be:
>
> Input: Package to be tested as ${PACKAGE}
> for binary in $(rpm -ql ${PACKAGE} | grep bin); do ${binary} 2>&1 | grep
> "Segmentation fault" && echo "test failed" ; done
It'd probably be best to ask on the autoqa-devel mailing list - you'll
get Will and Kamil there, who know far more in detail than I do :)
--
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
rawhide report: 20100227 changes
Compose started at Sat Feb 27 08:15:15 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 e_dbus-0.5.0.050-3.fc12.i686 requires libevas.so.0 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 ecore-0.9.9.050-7.fc12.i686 requires libevas.so.0 edje-0.9.9.050-6.fc12.i686 requires libevas.so.0 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 gnucash-2.3.10-1.fc13.i686 requires libgoffice-0.8.so.7 koan-2.0.3.1-1.fc13.noarch requires mkinitrd linphone-2.1.1-4.fc12.i686 requires libortp.so.7 mpi4py-docs-1.2-7.fc14.noarch requires mpi4py = 0:1.2-7.fc14 nip2-7.20.7-2.fc13.i686 requires libgoffice-0.8.so.7 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 system-config-kdump-2.0.3-2.fc14.noarch requires bitmap-fixed-fonts 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) e_dbus-0.5.0.050-3.fc12.i686 requires libevas.so.0 e_dbus-0.5.0.050-3.fc12.x86_64 requires libevas.so.0()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) ecore-0.9.9.050-7.fc12.i686 requires libevas.so.0 ecore-0.9.9.050-7.fc12.x86_64 requires libevas.so.0()(64bit) edje-0.9.9.050-6.fc12.i686 requires libevas.so.0 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) edje-0.9.9.050-6.fc12.x86_64 requires libevas.so.0()(64bit) emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.x86_64 requires libevas.so.0()(64bit) enlightenment-0.16.999.050-5.fc12.x86_64 requires libevas.so.0()(64bit) epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.x86_64 requires libevas.so.0()(64bit) epsilon-xine-0.3.0.012-9.fc12.x86_64 requires libevas.so.0()(64bit) ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.x86_64 requires libevas.so.0()(64bit) ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.x86_64 requires libevas.so.0()(64bit) frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 frepple-0.7.1-1.fc13.x86_64 requires libxerces-c.so.28()(64bit) geglmm-0.1.0-3.fc13.i686 requires libgegl-0.0.so.0 geglmm-0.1.0-3.fc13.x86_64 requires libgegl-0.0.so.0()(64bit) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) gnucash-2.3.10-1.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) koan-2.0.3.1-1.fc13.noarch requires mkinitrd linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) mpi4py-docs-1.2-7.fc14.noarch requires mpi4py = 0:1.2-7.fc14 nip2-7.20.7-2.fc13.x86_64 requires libgoffice-0.8.so.7()(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 system-config-kdump-2.0.3-2.fc14.noarch requires bitmap-fixed-fonts zikula-module-menutree-2.2-1.fc13
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 11:27 AM, Adam Williamson wrote: > On Sat, 2010-02-27 at 10:57 +0100, Ralf Corsepius wrote: > > Yeah, it's not perfect: there are cases where we have, say, a complex > kernel update which works fine for most people but causes a significant > regression for some particular bit of hardware. We wouldn't want to put > that update out, but it's easy for it to get five +1s before someone > with the specific bit of hardware comes by and gives it a -1...and even > then, +4 looks good if you're not reading the feedback too carefully. > And of course the opposite - where some strong views on a minor non-stopper might hold things back even tho more careful thought may lead one to release and do minor fixups later. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill writes: > [...] > Probably the saddest thing about this giant flamewar you've started is > [...] For what it's worth, I have seen no lack of courtesy from Kevin Kofler in this thread, so the accusation of "flamewarism" would be more appropriately directed to those who have not kept *their* calm. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 10:38 AM, Mike McGrath wrote: > in today. Next time a user tells you "I want a newer X" tell them > "Upgrade to rawhide". > > -Mike In my opinion rawhide is NOT a rolling release at all. Please stop telling people to use rawhide as a rolling release. it isnt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Till Maas wrote: > On Sat, Feb 27, 2010 at 09:44:11AM -0600, Mike McGrath wrote: > > On Sat, 27 Feb 2010, Mike McGrath wrote: > > > > > On Sat, 27 Feb 2010, Kevin Kofler wrote: > > > > > > > Chris Adams wrote: > > > > > IMHO you're developing the wrong distro. It is statements like yours > > > > > that contribute to the "Fedora is a rolling beta" perception (and I > > > > > don't think that's a good perception to have). If you want to target > > > > > rawhide with rolling releases of KDE, have fun. Once a release is out > > > > > the door, try not to just throw a new kitchen sink in for the hell of > > > > > it. > > > > > > > > Some people actually LIKE rolling releases, indeed some distros use > > > > completely rolling releases (e.g. Arch Linux). We are currently > > > > somewhere > > > > inbetween (partly release-based, partly rolling), and IMHO this > > > > compromise > > > > is working great. We get the advantages from a rolling release model, > > > > but > > > > with a lot less surprise breakage as in a true rolling model because > > > > disruptive changes like libata go only into new releases. > > > > > > > > > > If only we had some sort of rolling release, that tracked as closely with > > > upstream as possible, where the users of said release understood they were > > > drinking from the firehose. Meanwhile, along side that release we could > > > have periodic stable releases that don't move so quickly. That way you > > > get > > > what you want and I get what I want. Oh wait! That's the world we live > > > in today. Next time a user tells you "I want a newer X" tell them > > > "Upgrade to rawhide". > > > > > > > > > > > Or to put it another way, why aren't you doing this and telling others to > > do this? If someone is on F11 still, why do you think they want the > > latest and greatest software? If they did, they'd upgrade to f12. And > > further still, why wouldn't they be running rawhide? The rolling update > > release exists. Why force rolling updates on people that haven't chosen > > to run rawhide? > > Did you read what he wrote? I feel tempted to just copy the paragraph > Kevin wrote again, because it already answers your question: Rawhide is > not partly rolling as Fedora is. > And a typical reason not to upgrade from F(current-1) to F(current) is > because the major updates may make systems unusable, e.g. X not working > anymore. But this does not mean that the same person does not want > bugfixes for e.g. yum-builddep installing build dependencies again. > Then lets fix that. Rolling updating everything isn't the answer to any problem. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Mail Lists wrote: > On 02/27/2010 10:38 AM, Mike McGrath wrote: > > > in today. Next time a user tells you "I want a newer X" tell them > > "Upgrade to rawhide". > > > > -Mike > > > > In my opinion rawhide is NOT a rolling release at all. Please stop > telling people to use rawhide as a rolling release. it isnt. > Then lets make it that. We own it right? We can make it whatever we want. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 13:26 +0100, Kevin Kofler wrote: > Oh, and by the way: > > Orion Poplawski wrote: > > There is plenty of room for something in between your vision of Fedora > > and CentOS. > > There is plenty of room for something in between your vision of Fedora > and Rawhide. :-) To quote something I just sent to someone off-list...I know I've said this before, but I think this really isn't a resolvable argument, as both sides have merit. There are those who want stable updates, and those who want lots of new stuff, and lots of people who are kinda in the middle (they mostly want a stable system, but will go nuts if they can't get the newest version of Firefox or whatever). The problem is that there are indeed lots of visions, and none of them is the 'true correct one'. Given that, you can't possibly satisfy everyone with a single update track. (Yeah, I know technically we have three tracks, but the separation between them really isn't sufficiently enforced in the tools or documentation or policies). Kevin's argument that we should just consider our audience to be the people who are happy to take everything and stuff the others does have some merit, actually, but seems a bit restrictive to me. I honestly prefer the MDV model of two update streams, simply because I was there before it was implemented and then after it was implemented, and I saw that it genuinely improved things for users and even for packagers. It seems like extra work for packagers, but in the end it kinda takes the pressure off: you only *have* to ship the important fixes to /updates, /backports is optional, and /backports users are good about knowing that sometimes what they find there will be broken or have new bugs or whatever, and tend to know the drill about not getting too upset and reporting them to you to be fixed. And they know they can easily fall back to what's in /updates if they find /backports to be broken; it gives them an escape route. -- 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: opencv 2.0.0 soname change
Le 27/02/2010 16:28, Rakesh Pandit a écrit : > On 27 February 2010 20:24, Haïkel Guémar wrote: >> Branches affected: F-13 and devel >> >> >> Since OpenCV has deleted few weeks ago the autotools based build system, >> we will switch to cmake : >> https://code.ros.org/trac/opencv/changeset/2528 >> > [..] > > Are you kidding ? No *communication* :( At this stage we never wanted > an update for any reason, nor extra work for lot of other folks. Alas > I had some more time at hand. > Did you receive my previous email thursday following the last discussion about OpenCV 2.0 ? (Nicolas and Karel were CC'ed too) I'm sorry if you didn't get it. :( I was waiting OpenCV folks decision about the soname issue, hoping that they stick to a saner soname policy. But then i was busy with job interviews. I've just moved in and started my new job this week. Anyway, since OpenCV brutally removed autotools support from svn [1], we have no other choice than moving to cmake. As OpenCV 2 has never been shipped into a stable release, pushing the change now will avoid us struggling with soname issues later in stable releases (unless upstream decides to break stuff again). OpenCV 1.x was nothing more than a glorified "beta" (if not alpha) for Intel, OpenCV 2.x is expected to be a little more stable. By itself, the move to cmake is no problem: it's well maintained (issues with sse are fixed for instance), the libdir patch was done, and no problems with chrooted builds. If I could, i would have rebuilt myself the packages to avoid that annoyance to fellow maintainers. H. [1] it was supposed to be maintained at least during the whole 2.0.x branch life. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Till Maas wrote: > On Sat, Feb 27, 2010 at 09:44:11AM -0600, Mike McGrath wrote: > > On Sat, 27 Feb 2010, Mike McGrath wrote: > > > > > On Sat, 27 Feb 2010, Kevin Kofler wrote: > > > > > > > Chris Adams wrote: > > > > > IMHO you're developing the wrong distro. It is statements like yours > > > > > that contribute to the "Fedora is a rolling beta" perception (and I > > > > > don't think that's a good perception to have). If you want to target > > > > > rawhide with rolling releases of KDE, have fun. Once a release is out > > > > > the door, try not to just throw a new kitchen sink in for the hell of > > > > > it. > > > > > > > > Some people actually LIKE rolling releases, indeed some distros use > > > > completely rolling releases (e.g. Arch Linux). We are currently > > > > somewhere > > > > inbetween (partly release-based, partly rolling), and IMHO this > > > > compromise > > > > is working great. We get the advantages from a rolling release model, > > > > but > > > > with a lot less surprise breakage as in a true rolling model because > > > > disruptive changes like libata go only into new releases. > > > > > > > > > > If only we had some sort of rolling release, that tracked as closely with > > > upstream as possible, where the users of said release understood they were > > > drinking from the firehose. Meanwhile, along side that release we could > > > have periodic stable releases that don't move so quickly. That way you > > > get > > > what you want and I get what I want. Oh wait! That's the world we live > > > in today. Next time a user tells you "I want a newer X" tell them > > > "Upgrade to rawhide". > > > > > > > > > > > Or to put it another way, why aren't you doing this and telling others to > > do this? If someone is on F11 still, why do you think they want the > > latest and greatest software? If they did, they'd upgrade to f12. And > > further still, why wouldn't they be running rawhide? The rolling update > > release exists. Why force rolling updates on people that haven't chosen > > to run rawhide? > > Did you read what he wrote? I feel tempted to just copy the paragraph > Kevin wrote again, because it already answers your question: Rawhide is > not partly rolling as Fedora is. > And a typical reason not to upgrade from F(current-1) to F(current) is > because the major updates may make systems unusable, e.g. X not working > anymore. But this does not mean that the same person does not want > bugfixes for e.g. yum-builddep installing build dependencies again. > This doesn't make sense. They either update at the end of a release or the begining or middle, still, they have to update or live with an unsupported system. It's not like you can not upgrade to F current for very long. So instead of choosing when to make their system unstable, parts of it become unstable throught the release without any coordination. I wake up, go to work, suddenly I've got a different version of KDE then I had yesterday. And you guys think that makes me think more highly of Fedora and not less? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Saturday 27 February 2010, Kevin Kofler wrote: > If they Obsolete something else, then they're not really new packages. I that's the blanket generalization I read it as, I don't agree with it, but meh. > Well, true, new packages which Provide some common virtual Provides like > bluez-dbus-pin-helper also need the same scrutiny as upgrades to explicit > packages. That's not the common case though, [...] Common or not, it is one occurrence of what I wanted to point out as you have more than once in this thread made a broad claim that new packages just can't/won't break existing setups, and still make in a slightly less broad form below. > New packages which don't Obsolete existing packages or Provide existing > provided names cannot cause any of the above. Those "provided names" also include the package's Name, and all files shipped in the package, or more generally, anything that other packages or mechanisms (e.g. package groups) can have a dependency on so that it gets pulled in without explicitly asked. Whether the "provided name" is existing or not is irrelevant, a dependency on it can spring to life any time, including at a time when it causes the package containing the name to be installed without being explicitly asked. And FWIW, if you think outside of the Fedora box, that set is (perhaps not strictly, but practically) infinite, and I suppose there is no active ongoing effort/process to check all of these even within Fedora. Anyway in my opinion it is not really relevant to this discussion whether new packages may end up being installed without explicitly being asked for. I think it's better to just treat and push them like other updates, be it through testing or directly to stable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 04:30 PM, Mail Lists wrote: an > > > I do want updates. Kernel updates, for example, are very important - > they carry many improvements - not just drivers but functionality as > well. The ones that are less obvious are the bugs that happen rarely but > that can be nasty (an occasional file system glitch for example). > As as enduser. I would agree with this. On the everyday boxes there is FedoraN + F13\Rawhide Kernel(s). > The rare-but-nasty bug fixes will seldom have user demand - but > nonetheless once identified and fixed should be shared. Bug fixes would also be applied. > > These kind of non-user-demand driven fixes should not be ignored in any > noone-is-asking so dont release approach. > If it's not broken, don't fix it. Thats what the F13/Rawhide boxes are for. -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 2/27/2010 5:05 AM, Kevin Kofler wrote: > Orion Poplawski wrote: > >> There is plenty of room for something in between your vision of Fedora >> and CentOS. >> > But that room is filled by other distros, such as Ubuntu. Why do we need to > be another Ubuntu? > It's not filled by Ubuntu, because Ubuntu is not Fedora. Fedora has the vision that is the most in line with mine, except for the frequent update, which so far I have been willing to put up with. But frequent updates is *not* why I've thrown my hat in with Fedora (sorry :). - Orion -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: opencv 2.0.0 soname change
Bad timing ===> unicap package (required by opencv) splitting for F-11+ Current unicap has been splitted into 3 new packages libunicap, libucil and libunicapgtk, no warnings, no meta-package provided for compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=567109 https://bugzilla.redhat.com/show_bug.cgi?id=567111 https://bugzilla.redhat.com/show_bug.cgi?id=567110 The update will be postponed until new packages are pushed into repositories. At first sight (ldd), we only need libunicap and libucil. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why online recovery in pgpool is disabled?
Hi, Is there any particular reason why online recovery is disabled in F11 pgpool-II? Online recovery is a very important feature (fundamental, must have) and I have to build pgpool-II just to enable it. Can't it be enabled in spec? Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 11:30:52 -0500, Mail Lists wrote: > > [speaking of which where on earth is 2.6.32.9 ] http://koji.fedoraproject.org/koji/buildinfo?buildID=158902 And if you want the latest 2.6.33 build: http://koji.fedoraproject.org/koji/buildinfo?buildID=158529 There is also a prerelease version of 2.6.34: http://koji.fedoraproject.org/koji/buildinfo?buildID=158825 I am using 2.6.33 now and will probably track 2.6.34 on at least some machines once I see that the squashfs/lzma stuff get pulled from linux-next into Linus' tree. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 12:33 PM, Bruno Wolff III wrote: > On Sat, Feb 27, 2010 at 11:30:52 -0500, > Mail Lists wrote: >> >> [speaking of which where on earth is 2.6.32.9 ] > > http://koji.fedoraproject.org/koji/buildinfo?buildID=158902 > > And if you want the latest 2.6.33 build: > http://koji.fedoraproject.org/koji/buildinfo?buildID=158529 > > There is also a prerelease version of 2.6.34: > http://koji.fedoraproject.org/koji/buildinfo?buildID=158825 > > I am using 2.6.33 now and will probably track 2.6.34 on at least some > machines once I see that the squashfs/lzma stuff get pulled from linux-next > into Linus' tree. Thanks. Are there any toolsets (dracut, grubby, or other system tools) that need to be updated to move from .33 fc12 to either .33 or .34 out of f13 ? gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 12:33 PM, Bruno Wolff III wrote: > On Sat, Feb 27, 2010 at 11:30:52 -0500, > Mail Lists wrote: >> >> [speaking of which where on earth is 2.6.32.9 ] > > http://koji.fedoraproject.org/koji/buildinfo?buildID=158902 Thank you .. but I really meant where are as far as updates-testing or updates is concerned. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I can not import the browser cert, please help.
Hello, i can not import the browser-cert from fedora in to mozilla. Mozilla says that it can not be imported for unknown reasons. Can somebody help me? regards, Dirk -- Gottschalk IT + Internet UG (haftungsbeschränkt) Klüsenborn 9 52156 Monschau (Kalterherberg) Tel.: +49 2472 8026049 Fax.: +49 2742 8025879 Internet: http://www.it-internet-service.de Registergericht: Amtsgericht Aachen Registernummer: HRB 15368 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: opencv 2.0.0 soname change
2010/2/27 Rakesh Pandit > On 27 February 2010 20:24, Haïkel Guémar wrote: > > Branches affected: F-13 and devel > > > > > > Since OpenCV has deleted few weeks ago the autotools based build system, > > we will switch to cmake : > > https://code.ros.org/trac/opencv/changeset/2528 > > > [..] > > Are you kidding ? No *communication* :( At this stage we never wanted > an update for any reason, nor extra work for lot of other folks. Alas > I had some more time at hand. > As Karl explained I Think It worth to have a reliable SO version. We are doing this adjustement in F-13/devel only, and there is no API/ABI involved. Once that said, I would have preferred to have a buildsys override to be set for F-13, so packagers of the above packages could have submitted the F-13 rebuilt along with F-14's one. Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 Alpha RC4 install note(s)
Noticed that the partitioning menu changed some and can be confusing, esp if doing a dual boot (win 7 and Fedora). A couple things I ran into, and not sure if bugs or just *how it works* Setup - 2 HD's, both sata, one has Windows and other has Fedora. 1 - During selection, chose just the HD (check marked) that I was gonna install onto, and that went fine. Cept, when got to the installing boot loader, it only gave me that hd choice of where to install boot loader and not the other which is the actual first drive (first selected to boot in bios). So the install went on, and when boot after it was finished, it wouldn't boot. 2 - During 2nd install, this time I chose both hd's to work on, the windows hd as storage (mounted only) device and the other as the install target. Install proceeded, but again the driver order didn't default to correct order as previous installs so grub not installed correctly again. 3 - During 3rd install, same as #2, cept this time I changed the drive order to Windows being 1st. Install proceeded as normal, and this time it booted, and all is well. Oh, and that default=0 option in grub.conf that is used can be confusion. When it booted and instead of grub menu/option, it just sat there with a cursor for few seconds (10 or so maybe, tad longer), then finally went to fedora logo screen during boot. So if not gonna change grub back to default few seconds, then there needs to be a heck of a lot smoother transition from bios/computer boot to linux booting (hope that made sense) and a lot less waiting. Or at least a small fedora logo or something to kill that few second wait or something. Oh, and the font (on the menus during install) sucks LOL. Doesn't look no where near as big or as dark or something compared to the last few versions. -- Mike Chambers Madisonville, KY "Best lil town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 12:51:06 -0500, Mail Lists wrote: > > Thanks. Are there any toolsets (dracut, grubby, or other system tools) > that need to be updated to move from .33 fc12 to either .33 or .34 out > of f13 ? I don't know. I didn't try 2.6.33 on any f12 systems before I updated to f13. I was running the various 2.6.32 kernels on f12 without a problem. The only area that I think might be of concern is graphics related packages. Nouveau especially has a new kernel interface. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 12:52:18 -0500, Mail Lists wrote: > On 02/27/2010 12:33 PM, Bruno Wolff III wrote: > > On Sat, Feb 27, 2010 at 11:30:52 -0500, > > Mail Lists wrote: > >> > >> [speaking of which where on earth is 2.6.32.9 ] > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=158902 > > Thank you .. but I really meant where are as far as updates-testing or > updates is concerned. Why wouldn't you want try the koji version if you were willing to try an updates-testing version? If it doesn't work for you, you boot the previous kernel, pretty much the same as when there is a bad test version. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 27/02/10 17:51, Mail Lists wrote: --snipped-- > > >Thanks. Are there any toolsets (dracut, grubby, or other system tools) > that need to be updated to move from .33 fc12 to either .33 or .34 out > of f13 ? > > gene iirc linux-firmware replaces kernel-firmware, some plymouth stuff. Do a yum --enablerepo=rawhide update kernel check that they are indeed "fc13" and see what it tries to pull in. If you don't like waht you see type in "n" -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: opencv 2.0.0 soname change
On 28 February 2010 00:04, Karel Klic wrote: > Dne 27.2.2010 17:41, Haïkel Guémar napsal(a): >> >> Le 27/02/2010 16:28, Rakesh Pandit a écrit : >>> >>> Are you kidding ? No *communication* :( At this stage we never wanted >>> an update for any reason, nor extra work for lot of other folks. Alas >>> I had some more time at hand. >> >> Did you receive my previous email thursday following the last discussion >> about OpenCV 2.0 ? (Nicolas and Karel were CC'ed too) >> I'm sorry if you didn't get it. :( > > This is my failure. I sent the email about OpenCV in F-12 to > rpan...@fedoraproject.org, the email returned back, so I resent it to Rakesh > separately (to rak...@fedoraproject.org). Haïkel probably responded to that > email with the wrong e-mail address. > I'm sorry for that. > > The CMake change looks great, thanks for doing it! I'll test the package > within the next few days. > Added devel back to CC. Nice. Ok, no problem, was not even sure that others have already been discussing, so pinged everyone. I investigated a bit upstream and changes seem logical to me now. But as Nicoles pointed out we could have preferred to have a buildsys override to be set. But it is anyway ok, as we have sometime(but very less though) for checking and all folks (contributor maintainers) are aware of it being introduced. Just wanted to make sure that we all are on same page and discussion was done. :) Cheers, -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On Fri, Feb 26, 2010 at 11:54 PM, Kevin Fenzi wrote: > I'm putting my thoughts here... but this is again one of those threads > that has about 500 forks and people nit picking back and forth, so I am > never sure where to do a general reply. ;) There has been a draft a while ago which did not result into much discussion .. http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience Which looks pretty sane to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 01:23 PM, Bruno Wolff III wrote: > Why wouldn't you want try the koji version if you were willing to try an > updates-testing version? If it doesn't work for you, you boot the previous > kernel, pretty much the same as when there is a bad test version. Me ? I am running koji version no problem at all. But this thread (as a reminder) is about the update process ... So was really kinda asking - hey - in the spriti of the update process - is 2.6.32.9 moving to testing and/or stable - or not. And can we learn anything from this oh so mosy important package! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: opencv 2.0.0 soname change
No problem :) I'm not familiar with buildroot overrides (it requires rel-eng agreement, right ?), besides the unicap recent split has been thrown into the mix. Should we ask them to be include into the override request ? H. > > Added devel back to CC. > > Nice. > > Ok, no problem, was not even sure that others have already been > discussing, so pinged everyone. I investigated a bit upstream and > changes seem logical to me now. But as Nicoles pointed out we could > have preferred to have a buildsys override to be set. > > But it is anyway ok, as we have sometime(but very less though) for > checking and all folks (contributor maintainers) > are aware of it being introduced. Just wanted to make sure that we all > are on same page and discussion was done. :) > > Cheers, > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 26 Feb 2010 16:45:36 -0500, Bill wrote: > > > To phrase a strawman differently: > > > > > > "No update is pushed to users without verification and testing from > > > entities > > > other than the packager." > > > > No, thanks. The "popular"/"high profile" packages will get their usual > > rushed +1 votes in bodhi (from people who even download from koji without > > waiting for an entire package set to be published in a repo - from people > > who regularly vote +1 even when something is clearly broken). And > > less-popular packages will suffer. > > Again, that's just a "testing isn't working as well as we want right > now, so let's just not bother with it at all because it might > incovenience me" response. Not at all. Go and take a look at how I've used testing/stable pushes before. I just fear that I will be degraded to a package monkey, who must obey more and more rules - arbitrary rules - just to please an updates system OR the people who love needless bureaucracy (such as updates-testing for F13 development, IMO). When I submit an update request, I want to be done with it, so I can move on and focus on more important stuff. I don't care whether any integrated package sanity checks are run on the submitted packages, or whether it takes a day or several days for a push to happen. If something is wrong with the package and a person or tool reports it to me, fine, I'll take a look. Provided that it's no silly rules like Notes field is empty (even if bugzilla ticket links are present and %changelog contains good entries), a missing link to an online ChangeLog, enforced delays before something may be marked stable, or mandatory positive karma from testers. > If that's the sort of defeatist attitude people really want to take, > it's sad. Sad? It's sad if one cannot earn more trust and retain the freedom to make the most out of existing tools and infrastructure. Some of the off-topic parts of this thread are unbelievable. > > > Consider it a second eye. > > > > If there is a volunteer tester, who also takes responsibility when not > > noticing regression caused by an update, fine. If there is no volunteer, > > who will lend the update submitter a second eye? Either there are > > resources or there aren't. > > I said entities above. Could be testers. Could be releng. Could be a > battery of autoQA tests. Three times "Could". Let's talk about it when you know something definite, please, but before it will become another hurdle. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I can not import the browser cert, please help.
On Sat, Feb 27, 2010 at 1:00 PM, Dirk Gottschalk wrote: > Hello, > > i can not import the browser-cert from fedora in to mozilla. > Mozilla says that it can not be imported for unknown reasons. > > Can somebody help me? Disable the torbutton add-on. No kidding. failing that, try pk12util -i certfilename.p12 -d ~/.mozilla/firefox/randomcrap.default/ (replace cerfilename and randomcrap with the actual values). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 10:45:49AM -0600, Mike McGrath wrote: > On Sat, 27 Feb 2010, Till Maas wrote: > > Did you read what he wrote? I feel tempted to just copy the paragraph > > Kevin wrote again, because it already answers your question: Rawhide is > > not partly rolling as Fedora is. > > And a typical reason not to upgrade from F(current-1) to F(current) is > > because the major updates may make systems unusable, e.g. X not working > > anymore. But this does not mean that the same person does not want > > bugfixes for e.g. yum-builddep installing build dependencies again. > > > > This doesn't make sense. They either update at the end of a release or > the begining or middle, still, they have to update or live with an > unsupported system. It's not like you can not upgrade to F current for > very long. It allows to fix the bug in F(current) for 7 months until the user needs to upgrade from F(current-1). And then he could also skip one release and have a higher chance of the bug being fixed. Nevertheless, this is just a description of the situation. I like it more to have bugs fixed in F(current) at the cost of not fixing that much bugs in F(current-1) to keep it stable. > So instead of choosing when to make their system unstable, parts of it > become unstable throught the release without any coordination. I wake up, > go to work, suddenly I've got a different version of KDE then I had > yesterday. And you guys think that makes me think more highly of Fedora > and not less? Afaik the KDE updates work very well and I know a fanatic KDE user who cannot expect to wait for the next KDE update, because he knows of bugs that are fixed in it. Usually he does not even need to report them, because they are already in the KDE upstream bug tracker. So this "release becoming unstable" is imho a little exaggerated, because nobody is proposing to track unstable upstream releases/upstream SCM with updates. Regards Till pgpnuX77seRAX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100227 changes
Compose started at Sat Feb 27 09:15:11 UTC 2010 Broken deps for i386 -- balsa-2.4.6-3.fc13.i686 requires libgmime-2.4.so.2 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 frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 fusecompress-2.6-3.fc12.i686 requires libboost_serialization-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_system-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_program_options-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_filesystem-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_iostreams-mt.so.5 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 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 -- balsa-2.4.6-3.fc13.x86_64 requires libgmime-2.4.so.2()(64bit) 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) frepple-0.7.1-1.fc13.i686 requires libxerces-c.so.28 frepple-0.7.1-1.fc13.x86_64 requires libxerces-c.so.28()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_system-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_program_options-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_iostreams-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_filesystem-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_serialization-mt.so.5()(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 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 gqradio Skinned radio tuner New package roboptim-trajectory The RobOptim trajectory C++ library Removed package libpfm Removed package pfmon Updated Packages: Mayavi-3.3.0-1.fc13 --- * Sun Jan 31 2010 Rakesh Pandit 3.3.0-1 - Updated to 3.2.0 ggz-gtk-client-0.99.5-1.fc13 * Wed Feb 17 2010 Thomas Janssen 0.99.5-1 - New upstream snapshot gnome-desktop-2.29.91-1.fc13 kacst-fonts-2.0-6.fc13 -- * Thu Feb 25 2010 Pravin Satpute - 2.0-6 - added .conf file for each subpackage - resolves bug 567608 qtcurve-gtk2-1.1.0-1.fc13 - * Tue Feb 23 2010 Thomas Janssen 1.1.0-1 - New upstream source 1.1.0 qtc
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 08:43:58PM +0100, Till Maas wrote: > I like it more to have bugs fixed > in F(current) at the cost of not fixing that much bugs in F(current-1) > to keep it stable. This should read as "to have more bugs fixed in F(current)" (even at the cost of maybe introduce regressions). Regards Till pgp9W9nGzjj2k.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why online recovery in pgpool is disabled?
On Sat, Feb 27, 2010 at 06:26:53PM +0100, Michał Piotrowski wrote: > Hi, > > Is there any particular reason why online recovery is disabled in F11 > pgpool-II? > > Online recovery is a very important feature (fundamental, must have) > and I have to build pgpool-II just to enable it. Can't it be enabled > in spec? > Could you please file a bug at bugzilla.redhat.com to make sure trhe maintainer sees the request? https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=postgresql-pgpool-II -Toshio pgp92FGsJQD2h.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Splitting of unicap into libunicap, libucil and libunicapgtk
Hello folks, the upstream of unicap splitted the unicap package into libunicap, libucil and libunicapgtk. On run-time they're 100% compatible with unicap, but only all three new packages together replace the previous unicap package. Thus none of libunicap, libucil ands libunicapgtk has a provides for unicap and all obsolete unicap. On build-time, you've to decide/figure out, which of the new packages are needed. Note that libunicapgtk depends on libucil and libucil depends on libunicap (these dependencies are build and run-time). Right now, there are still buildroot overrides on EL-5 and F-11+ that new builds of packages depending on former unicap can be fired easily with the new dependencies. Greetings, Robert -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why online recovery in pgpool is disabled?
2010/2/27 Toshio Kuratomi : > Could you please file a bug at bugzilla.redhat.com to make sure trhe > maintainer sees the request? Done https://bugzilla.redhat.com/show_bug.cgi?id=569058 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why online recovery in pgpool is disabled?
W dniu 27 lutego 2010 21:51 użytkownik Michał Piotrowski napisał: > 2010/2/27 Toshio Kuratomi : >> Could you please file a bug at bugzilla.redhat.com to make sure trhe >> maintainer sees the request? > > Done > https://bugzilla.redhat.com/show_bug.cgi?id=569058 > BTW. I've got one i686 which needs pgpool-recovery.so. When I try to build package on x86_64 I get this rpmbuild -bb --clean --target i686 rpmbuild/SPECS/postgresql-pgpo ol-II.spec Budowanie dla platform: i686 Budowanie dla i686 Wykonywanie(%prep): /bin/sh -e /var/tmp/rpm-tmp.cPPG89 + umask 022 + cd /root/rpmbuild/BUILD + cd /root/rpmbuild/BUILD + rm -rf pgpool-II-2.3.1 + /usr/bin/gzip -dc /root/rpmbuild/SOURCES/pgpool-II-2.3.1.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd pgpool-II-2.3.1 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #1 (pgpool.conf.sample.patch):' Patch #1 (pgpool.conf.sample.patch): + /bin/cat /root/rpmbuild/SOURCES/pgpool.conf.sample.patch + /usr/bin/patch -s -p0 --fuzz=0 + exit 0 Wykonywanie(%build): /bin/sh -e /var/tmp/rpm-tmp.b5wI5f + umask 022 + cd /root/rpmbuild/BUILD + cd pgpool-II-2.3.1 + CFLAGS='-O2 -g -march=i686' + export CFLAGS + CXXFLAGS='-O2 -g -march=i686' + export CXXFLAGS + FFLAGS='-O2 -g -march=i686' + export FFLAGS + ./configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu - -target=i686-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --b indir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --incl udedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir= /var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pgsql-includedir=/usr/include/pgsql --with-pgsql-lib=/usr/lib/pgsql --di sable-static --with-pam --disable-rpath --sysconfdir=/etc/pgpool-II/ checking for x86_64-unknown-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. config.log doesn't say anything useful prefix='/usr' program_transform_name='s,x,x,' sbindir='/usr/sbin' sharedstatedir='/var/lib' sysconfdir='/etc/pgpool-II/' target_alias='i686-redhat-linux' ## --- ## ## confdefs.h. ## ## --- ## #define PACKAGE_BUGREPORT "" #define PACKAGE_NAME "" #define PACKAGE_STRING "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" configure: exit 77 Build for x86_64 went fine. Any hints? Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 20:18 +0100, Michael Schwendt wrote: > Three times "Could". Let's talk about it when you know something definite, > please, but before it will become another hurdle. That's ironic - given that that's exactly what the people defending this proposal wanted to do, while it's someone who's opposed to the proposal who decided to start a premature argument about it. -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Adam Williamson wrote: > On Sat, 2010-02-27 at 20:18 +0100, Michael Schwendt wrote: > > > Three times "Could". Let's talk about it when you know something definite, > > please, but before it will become another hurdle. > > That's ironic - given that that's exactly what the people defending this > proposal wanted to do, while it's someone who's opposed to the proposal > who decided to start a premature argument about it. > Did the proposal actually get written yet? Where can I see it? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010 13:17:43 -0800, Adam wrote: > On Sat, 2010-02-27 at 20:18 +0100, Michael Schwendt wrote: > > > Three times "Could". Let's talk about it when you know something definite, > > please, but before it will become another hurdle. > > That's ironic - given that that's exactly what the people defending this > proposal wanted to do, while it's someone who's opposed to the proposal > who decided to start a premature argument about it. Then let's see this thread as the updates-testing push of a proposal FESCo might have given its blessing to, if this thread had not been started. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Till Maas wrote: > On Sat, Feb 27, 2010 at 10:45:49AM -0600, Mike McGrath wrote: > > On Sat, 27 Feb 2010, Till Maas wrote: > > > > Did you read what he wrote? I feel tempted to just copy the paragraph > > > Kevin wrote again, because it already answers your question: Rawhide is > > > not partly rolling as Fedora is. > > > And a typical reason not to upgrade from F(current-1) to F(current) is > > > because the major updates may make systems unusable, e.g. X not working > > > anymore. But this does not mean that the same person does not want > > > bugfixes for e.g. yum-builddep installing build dependencies again. > > > > > > > This doesn't make sense. They either update at the end of a release or > > the begining or middle, still, they have to update or live with an > > unsupported system. It's not like you can not upgrade to F current for > > very long. > > It allows to fix the bug in F(current) for 7 months until the user needs > to upgrade from F(current-1). And then he could also skip one release > and have a higher chance of the bug being fixed. Nevertheless, this is > just a description of the situation. I like it more to have bugs fixed > in F(current) at the cost of not fixing that much bugs in F(current-1) > to keep it stable. > > > So instead of choosing when to make their system unstable, parts of it > > become unstable throught the release without any coordination. I wake up, > > go to work, suddenly I've got a different version of KDE then I had > > yesterday. And you guys think that makes me think more highly of Fedora > > and not less? > > Afaik the KDE updates work very well and I know a fanatic KDE user who > cannot expect to wait for the next KDE update, because he knows of bugs > that are fixed in it. Usually he does not even need to report them, > because they are already in the KDE upstream bug tracker. So this > "release becoming unstable" is imho a little exaggerated, because nobody > is proposing to track unstable upstream releases/upstream SCM with > updates. > I'm sure that guy loves it. Me? I don't like not being able to predict what my desktop looks like tomorrow. Just so I'm clear, if we had implemented what you are proposing... Fedora 11, Fedora 12, Fedora 13 branched and rawhide would all be identical right now as far as package version numbers go? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Till Maas wrote: > On Sat, Feb 27, 2010 at 10:45:49AM -0600, Mike McGrath wrote: > > On Sat, 27 Feb 2010, Till Maas wrote: > > > > Did you read what he wrote? I feel tempted to just copy the paragraph > > > Kevin wrote again, because it already answers your question: Rawhide is > > > not partly rolling as Fedora is. > > > And a typical reason not to upgrade from F(current-1) to F(current) is > > > because the major updates may make systems unusable, e.g. X not working > > > anymore. But this does not mean that the same person does not want > > > bugfixes for e.g. yum-builddep installing build dependencies again. > > > > > > > This doesn't make sense. They either update at the end of a release or > > the begining or middle, still, they have to update or live with an > > unsupported system. It's not like you can not upgrade to F current for > > very long. > > It allows to fix the bug in F(current) for 7 months until the user needs > to upgrade from F(current-1). And then he could also skip one release > and have a higher chance of the bug being fixed. Nevertheless, this is > just a description of the situation. I like it more to have bugs fixed > in F(current) at the cost of not fixing that much bugs in F(current-1) > to keep it stable. > So when Fedora 12 came out, we allowed users 7 months to upgrade because the latest version of stuff is too unstable for them. At the same time we're also forcing them to upgrade to the latest versions of those packages in F-11 anyway? I hope you can at least acknowledge why I'm not following the logic here? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 4:48 PM, Mike McGrath wrote: > On Sat, 27 Feb 2010, Till Maas wrote: >> >> Afaik the KDE updates work very well and I know a fanatic KDE user who >> cannot expect to wait for the next KDE update, because he knows of bugs >> that are fixed in it. Usually he does not even need to report them, >> because they are already in the KDE upstream bug tracker. So this >> "release becoming unstable" is imho a little exaggerated, because nobody >> is proposing to track unstable upstream releases/upstream SCM with >> updates. >> > > I'm sure that guy loves it. Me? I don't like not being able to predict > what my desktop looks like tomorrow. Just so I'm clear, if we had > implemented what you are proposing... Fedora 11, Fedora 12, Fedora 13 > branched and rawhide would all be identical right now as far as package > version numbers go? > About rawhide: rawhide could/should contain more experimental stuff, such as beta releases or cvs snapshots of actively and frequently developed software. About F-11, F-12, F-13: yeah, pretty much. They should all contain the same stable version of most software. (e.g. I don't like not being able to update some of my gtk packages, because the gtk maintainers don't update their package in older releases.) Are we at the wrong place? Is there such a distro? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/27/2010 02:05 PM, Orcan Ogetbil wrote: > About F-11, F-12, F-13: yeah, pretty much. They should all contain the > same stable version of most software. Then why have numbered Fedora releases at all? Just so we can bump the wallpaper every once in a while? Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 5:15 PM, Josh Stone wrote: > On 02/27/2010 02:05 PM, Orcan Ogetbil wrote: >> About F-11, F-12, F-13: yeah, pretty much. They should all contain the >> same stable version of most software. > > Then why have numbered Fedora releases at all? Just so we can bump the > wallpaper every once in a while? > Well there are certain defaults that change in time, such as the default filesystem, certain core libraries, right? The Fedora release number should be for those components that can't be changed on the fly. Hence I used the word "most" as you quoted. I think the discussion should be how we should quantify this "most". Wallpaper is another example but it can be handled without bumping the release number I guess :) Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010 17:05:54 -0500, Orcan wrote: > About rawhide: rawhide could/should contain more experimental stuff, > such as beta releases or cvs snapshots of actively and frequently > developed software. Why? And what would be the benefit? > About F-11, F-12, F-13: yeah, pretty much. They should all contain the > same stable version of most software. Cannot agree with this. When F-13 is released, F-12 is history except for bug-fixes, security updates, and occasional upgrades that incorporate improvements for issues reported for F-12 and older. To bring "most software" in F-12 and F-11 in sync with F-13 is beyond the scope of creating distribution that is preparing and testing a new release every six months. If somebody finds F-(N) to be lacking, there is F-(N+1). > (e.g. I don't like not being > able to update some of my gtk packages, because the gtk maintainers > don't update their package in older releases.) Where to start and where to stop with upgrade madness? What may be feasible for Gtk, would be a much bigger task for GNOME and other frameworks. You can update your packages in the current dist release and Rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 03:48:08PM -0600, Mike McGrath wrote: > I'm sure that guy loves it. Me? I don't like not being able to predict > what my desktop looks like tomorrow. Just so I'm clear, if we had > implemented what you are proposing... Fedora 11, Fedora 12, Fedora 13 > branched and rawhide would all be identical right now as far as package > version numbers go? No, because there are updates that, e.g. require manual intervention, or are more likely to break a lot of stuff. These would make the difference between the releases. E.g. an update from KDE3 to KDE4 should only happen from a Fedora release to another, but an update from KDE 4.x.y to 4.x.y+1 would be ok. Maybe even from 4.x.y to 4.x+1.z, but I am not that familiar with KDE upgrades. Or postgres updates are a kind of updates that afaik require manual intervention, therefore they should also only happen from release to release. There was a good list about criteria for good updates somewhere in the thread, I can try to find it again if you want. Regards Till pgpfCabgWkH5Y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010, Michael Schwendt wrote: > On Sat, 27 Feb 2010 17:05:54 -0500, Orcan wrote: > > > About rawhide: rawhide could/should contain more experimental stuff, > > such as beta releases or cvs snapshots of actively and frequently > > developed software. > > Why? And what would be the benefit? > > > About F-11, F-12, F-13: yeah, pretty much. They should all contain the > > same stable version of most software. > > Cannot agree with this. When F-13 is released, F-12 is history except > for bug-fixes, security updates, and occasional upgrades that incorporate > improvements for issues reported for F-12 and older. To bring "most > software" in F-12 and F-11 in sync with F-13 is beyond the scope of > creating distribution that is preparing and testing a new release every > six months. If somebody finds F-(N) to be lacking, there is F-(N+1). > Bingo, in this world we'd basically not have F-11 right now. And as soon as F13 comes out we'd no longer support F-12. We'd force users to upgrade immediately and not give them any options to plan for updates, etc, etc. I think the divide in this discussion is along those who want to allow users time to choose when to update (a 6 month window is a long time) and those who want to force new updates on users ad-hoc. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 05:05:54PM -0500, Orcan Ogetbil wrote: > About rawhide: rawhide could/should contain more experimental stuff, > such as beta releases or cvs snapshots of actively and frequently > developed software. Such a repo would be nice, but it won't work for Rawhide as it is, because there needs to be a usable, newer release available within less than six months. Regards Till pgpGDZ4p4Ck7o.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 11:28:28PM +0100, Michael Schwendt wrote: > On Sat, 27 Feb 2010 17:05:54 -0500, Orcan wrote: > > > About rawhide: rawhide could/should contain more experimental stuff, > > such as beta releases or cvs snapshots of actively and frequently > > developed software. > > Why? And what would be the benefit? It would help to (to have such a repo, not necessarily to replace Rawhide with it) to catch FTBFS bugs directly when the commit was done upstream instead of just after they created a release. E.g. if Rawhide contains the new gcc that is more strict, than it would be nice to know that it breaks the current upstream SCM version of a package I maintain directly, so it can be fixed sooner. Regards Till pgpKZnNGZshfE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 5:28 PM, Michael Schwendt wrote: > On Sat, 27 Feb 2010 17:05:54 -0500, Orcan wrote: > >> About rawhide: rawhide could/should contain more experimental stuff, >> such as beta releases or cvs snapshots of actively and frequently >> developed software. > > Why? And what would be the benefit? > For pure developmental purposes. >> About F-11, F-12, F-13: yeah, pretty much. They should all contain the >> same stable version of most software. > > Cannot agree with this. When F-13 is released, F-12 is history except > for bug-fixes, security updates, and occasional upgrades that incorporate > improvements for issues reported for F-12 and older. To bring "most > software" in F-12 and F-11 in sync with F-13 is beyond the scope of > creating distribution that is preparing and testing a new release every > six months. If somebody finds F-(N) to be lacking, there is F-(N+1). > I agree that 6 month cycle creates too much work for keeping al packages up-to-date in all releases. How about a 12 month cycle? >> (e.g. I don't like not being >> able to update some of my gtk packages, because the gtk maintainers >> don't update their package in older releases.) > > Where to start and where to stop with upgrade madness? This is exactly what we should be debating on. How can we draw a borderline? Example: - If a library is required by m other packages, it can only be upgraded once every n months... - If a soname bump requires a rebuild of more than x packages, it has to wait until the next Fedora release. etc I am completely supporting the idea of banning direct stable repo pushes. But this is not for discouraging maintainers from sending updates to stable releases of Fedora. In the contrary, it is to encourage them to submit all their updates to the testing repo, so that they can get tested before being pushed to stable. This way the stable release doesn't fall behind rawhide for more than a couple weeks. 6 months is a long time to tell a user to wait for an update. I hope you get my idea: "use testing, and use it extensively for everything" Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 05:47:18PM -0500, Orcan Ogetbil wrote: > On Sat, Feb 27, 2010 at 5:28 PM, Michael Schwendt wrote: > > Where to start and where to stop with upgrade madness? > > This is exactly what we should be debating on. How can we draw a > borderline? Example: My proposal: If it passes all AutoQA tests and matches the criteria by Kevin Koffler[0], then the update is ok, except that critical path packages should be inspected more carefully. Regards Till [0] http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html pgpruvvB3gBQu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On 02/27/2010 04:21 PM, Richard Hughes wrote: > On 26 February 2010 22:54, Kevin Fenzi wrote: >> - If stable pushes were more restricted, perhaps that would get us more >> testing? If someone required a newer version and could easier >> install/test from updates-testing and provide feedback, don't we all >> win? Perhaps we could have PackageKit/yum say "you have the latest >> stable version of foo, but foo-2.0 is in updates-testing, would you >> like to test it and provide feedback? > > I had PK code to do that, but the check for updates took way too long, > as the updates-testing repo had to be enabled, the primaries > downloaded (and maybe the file lists too), updates resolved and then > disabled again, in ADDITION to the normal updates check. The package > manager is just too slow to get PackageKit data to make such a thing > work without making the user wait an extra 30 seconds. > > If we could speed up the dep checking and downloading, I agree it > would be better for usability, and the exposure of updates-testing > generally. > This sounds interesting, was this a plugin or configuration setting? Could this be something people can opt-in to at first? -- Jeroen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Saturday, 27 February 2010 at 16:44, Mike McGrath wrote: > On Sat, 27 Feb 2010, Mike McGrath wrote: > > > On Sat, 27 Feb 2010, Kevin Kofler wrote: > > > > > Chris Adams wrote: > > > > IMHO you're developing the wrong distro. It is statements like yours > > > > that contribute to the "Fedora is a rolling beta" perception (and I > > > > don't think that's a good perception to have). If you want to target > > > > rawhide with rolling releases of KDE, have fun. Once a release is out > > > > the door, try not to just throw a new kitchen sink in for the hell of > > > > it. > > > > > > Some people actually LIKE rolling releases, indeed some distros use > > > completely rolling releases (e.g. Arch Linux). We are currently somewhere > > > inbetween (partly release-based, partly rolling), and IMHO this compromise > > > is working great. We get the advantages from a rolling release model, but > > > with a lot less surprise breakage as in a true rolling model because > > > disruptive changes like libata go only into new releases. > > > > > > > If only we had some sort of rolling release, that tracked as closely with > > upstream as possible, where the users of said release understood they were > > drinking from the firehose. Meanwhile, along side that release we could > > have periodic stable releases that don't move so quickly. That way you get > > what you want and I get what I want. Oh wait! That's the world we live > > in today. Next time a user tells you "I want a newer X" tell them > > "Upgrade to rawhide". > > > > > > Or to put it another way, why aren't you doing this and telling others to > do this? If someone is on F11 still, why do you think they want the > latest and greatest software? Speaking as someone who is still on F11, I want the latest software as long as it doesn't break anything, because most often there are new useful features in it. > If they did, they'd upgrade to f12. No. Upgrading is a major pain. For example, on my EeePC I have very little space so before upgrading I have to uninstall the largest packages to be able to upgrade at all. And even then, yum-based upgrade is the only option. But even without that case, upgrading takes time and one has to check if everything still works afterwards (for example, read the release notes). When you're busy, you don't have time to do that. So I tend to stay with a release until its end of life. > And further still, why wouldn't they be running rawhide? Because I don't want to wake up worrying if last night's update broke my system or not. > The rolling update release exists. Why force rolling updates on people > that haven't chosen to run rawhide? Nobody is forcing updates on me. I like things the way they are now. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 3:45 AM, Camilo Mesias wrote: > On Sat, Feb 27, 2010 at 6:12 AM, Adam Williamson wrote: >> this is a *terrible* idea. We may see users as a 'resource', but they >> don't see themselves this way. We should not interrupt their usage of >> their computer to try and exploit them to our ends. > > What if it was an opt-in scheme? Users would consent to receive a > limited number of contacts about their current packages and for their > trouble would get streamlined access to potential fixes. > > I think there's enough in that for the opt-in scheme to be marketed > successfully, because although some people would see the interactions > as annoying, others would welcome the chance to participate. That was more the idea. I didn't declare any implementation details because I was pretty sure that would be a topic of some contention. Maybe "coerce" was the wrong idea; the idea was not to make involuntary guinea pigs of anyone, but to give people the chance to take an on-ramp to contribution. We're simply not doing that at all right now, which, given the technical process required, is not too much different than erecting a barrier to participation. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 7:31 AM, Kevin Kofler wrote: > Paul W. Frields wrote: >> How'd it happen? I commented directly in the Bugzilla bugs with the >> link and told the subscribers to the bugs that the package would not >> be issued until some of them tested it and posted feedback to tell me >> their bugs were fixed. > > I see why you're doing it, but still, this is essentially blackmailing > users, I'm not sure it's a good plan to follow. Sorry, I really need to know if my users experience something different than me before I feel comfortable pushing a package update out. This is especially true for a package where I personally am acquainted with a dozen or more users who use it -- meaning there are likely thousands of users out there affected my update. I'm not being pretentious about my or my package's importance to those users, just trying to make sure I don't make things any worse for them if I have an opportunity to do better. Turns out my actual text was a bit less stark: https://bugzilla.redhat.com/show_bug.cgi?id=543278#c53 "The sooner we receive feedback, the sooner we'll know whether we can release this update to the stable distribution. Thanks for participating." But there was a singular goal, which is to encourage people to try out the update so we'd have more assurance the problem was indeed fixed. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F12: lirc-0.8.6-4.fc12 missing from updates testing ?
Hi, In bugzilla 564095 there is mention of an lirc update, lirc-0.8.6-4.fc12, that fixes an issue with lirc on 2.6.32 kernels that has been submitted to updates-testing. This package does not seem to exist there and the link to its bodhi entry from the bugzilla page links to an entry for bind ... Cheers Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
