Thanks
Just a note. With recent rollout of patches-0.2 a broken patch slipped in. I just reported this as bug #236402
this also needs gnome-extra/yelp-2.22.1-r11 as well as a newer version of app-office/openoffice to go stable, at least on amd64....
Also requires a newer version of nspr to go stable.
Could you please make this bug depend on the STABLEREQs or updates of things we need, so we can see what's left to do before we stabilize Firefox ? bug 236678. And maybe we can disable flag xulrunner sensitivity for a time while we fix bug 234110 ? ... and only stabilize FF3 for now, and Xul later ... FF3 is now out since a long while, and I would not like Gentoo to be the last distribution to make it available in stable :) (In reply to comment #2) > this also needs gnome-extra/yelp-2.22.1-r11 as well as a newer version of > app-office/openoffice to go stable, at least on amd64.... What's wrong with openoffice-2.4.1.ebuild from august 11th ? (please provide a link or bug #) (In reply to comment #3) > Also requires a newer version of nspr to go stable. > What's wrong with =net-proxy/dnsproxy-1.15 ? i did not find any bug open, any problem with this version ? for who ? in which arch ? version to bump ?
This is not net-proxy/dnsproxy but dev-libs/nspr.
Note that <mozilla-firefox-3.0.2 or <mozilla-firefox-bin-3.0.2 has a bug which will cause Flash 10 to crash the browser when a rendering a wmode frame. Since Flash 10 is being fastracked into stabilisation, could >=mozilla-firefox-3.0.2 be the one that goes stable?
bug 236678 is not a blocker, since bsd and mips don't do stable keywords.
I've heard xulrunner-1.9 alone should be no problem now. Could it be done then? We need it to get newer swt/eclipse stable, thanks.
This should probably happen sooner rather than later. Mozilla will EOL Firefox 2 in mid-December (i.e., no security patches or upgrades of any sort after that): http://www.mozilla.com/en-US/firefox/all-older.html
(In reply to comment #9) > This should probably happen sooner rather than later. Mozilla will EOL Firefox > 2 in mid-December (i.e., no security patches or upgrades of any sort after > that): > > http://www.mozilla.com/en-US/firefox/all-older.html > Indeed, Firefox 2 is on track to be retired by the end of 2008: http://www.pcworld.com/businesscenter/article/153015/mozilla_plans_for_firefox_20s_final_days.html
Okay...so this is getting ready guys now that i've fixed bug 234110...if nobody has problems against this, i'll cc arches tomorrow
Any news on keywoarding arches? Firefox 3.0 should go stable soon as EOL for 2.0 is in mid-december.
This is getting ridiculous. Every other distro has shipped FF3 in stable for months. FF2 is deprecated upstream and will not receive security updates. Even if you stabilize FF3 today, users who sync infrequently will still be running FF2 for weeks, long after it is unsupported. This bug really makes Gentoo look bad. Please just mark FF3 stable and be done with it.
FYI: this is the bug that made me abandon Gentoo as a desktop OS 3 months ago. This is not the only issue I had but it was clearly the decisive one. I am still using Gentoo on the server side. I switched to OpenSUSE for the desktop.
(In reply to comment #14) > FYI: this is the bug that made me abandon Gentoo as a desktop OS 3 months ago. > This is not the only issue I had but it was clearly the decisive one. > > I am still using Gentoo on the server side. I switched to OpenSUSE for the > desktop. > Gentoo did not mark mozilla-firefox-3.* as ~arch just out of evil. There were important bugs. And this does not surprise me. I used a swiftfox beta a short time before release and it deleted part of my bookmarks (yes, I had a backup). When a program still has data-deleting bugs short before release, it suggests (yes, doest not prove, but suggests) that the final release has bad quality. And it is remarkably easy to emerge testing software on Gentoo. I for example am using mozilla-firefox-3.0.4-r1 (and take double care with my bookmarks), and am not bothered that Gentoo hasn't declared it stable. It takes seconds to add the three lines to package.keywords. I prefer that software be declared stable when it is indeed ready. in fact, I regret having installed the unstable firefox; I did this when I still had a "I want the latest" mentality. I have since realized the obvious: newer, less tested software is most often more buggy and slower; so I only get "the latest, even if untested" software when I think it really has important new features or bug fixes that compensate the risk. I have not downgraded my system to entirely stable software, but I have stopped upgrading to the latest ~x86 versions, and, as the versions I use become stable, my system is steadily got stable - it is now less buggy and overall better. Oh, and firefox 2 support will not end in a few weeks - other distros (such as Novell and RedHat) still use firefox2 and have committed to backport security fixes. Remember also hat gecko 1.8 is still used by a lot of projects, including the latest Thunderbird-2.0.0.18. Thunderbird 3.0 is not even in beta. I don't think it was a wise decision on your part to abandon Gentoo and I hope you come back. If you have any trouble, you can count on the knowledgeable people at the gentoo-user mailing list - the knowledge and helpfulness of these people is part of the reason I like Gentoo so much.
It is really easy add firefox-3 and related apps to package.keywords if you need it, I am using it since it was added to portage tree without problems, I also still have epiphany merged against xul-1.8 because of some web sites still not working with gecko 1.9. If you want to contribute with Mozilla gentoo team, maybe you could try to become a Gentoo dev. I know that it is usually not an option because you maybe wouldn't have enough time, but you should also take care that Raul Porcel is doing a lot of work for maintaining mozilla apps and he cannot do much more, then, please reconsider your position as maintaining firefox and related apps are not as easy as you seem to think :-)
(In reply to comment #15) > I prefer that software be declared stable when it is indeed ready. I understand this, and I embrace it. But I get confused... Stability decisions in Gentoo seem to be all over the place. Some observations of mine: * Gnome releases, which occur predictably every 6 months, take 4 months after release to be marked stable in Gentoo. Other distros can get new Gnome out within a month. * A monster package like OpenOffice.org 3 is marked stable a week after release. Other distros still haven't included it in their releases because, according to them, the delivery schedule slipped so much that they couldn't verify it was stable. * Firefox, seemingly simpler than Gnome and OO.o but still a complex program, is not stable in Gentoo almost 6 months after release. Preview releases happened for over 6 months. It was included as stable in the BETA (not even rc) stage in a certain other distro's "long term support" version. Firefox is software used the world over. Are you (Jorge) saying that its source is not stable enough as released to be marked as stable in a distro within 6 months? It has been almost a year since the first FF3 was released to the public. For me, as a user, what gets me about the whole process is that I just don't know what's holding this ebuild up, or that ebuild, but not a third one. I don't know if it's just that I'm a n00b, but I don't know where to go in the Gentoo world to find out that information. And this bug doesn't seem to give even an ETA. I appreciate that the standard response is going to be "become a Gentoo dev". Well, I don't have the ability to code. But what I AM good at is planning and coordination. It seems this is lacking, at least in this instance. Where do I go to volunteer to help with that? Please don't think I'm harping on the Firefox maintainer(s). The problem with coordination seems to happen throughout Gentoo when marking ebuilds as stable. Witness the TWO e2fsprogs blocking issues within the past couple of years. By the way, I had stable Firefox 2.0.17 kill three folders of bookmarked tabs one day. So I don't think that behavior is limited to FF3. :-)
(In reply to comment #17) > (In reply to comment #15) > > I prefer that software be declared stable when it is indeed ready. > > I understand this, and I embrace it. But I get confused... Stability > decisions in Gentoo seem to be all over the place. Some observations of mine: > Bugzilla is not the place for discussions like this, please use the mailing lists. Packages have different stabling times simply because it's up to the maintainers to decide when their packages are stable and not all devs are alike.
(In reply to comment #13) > This is getting ridiculous. Every other distro has shipped FF3 in stable for > months. FF2 is deprecated upstream and will not receive security updates. We all know that. > Even if you stabilize FF3 today, users who sync infrequently will still be > running FF2 for weeks, long after it is unsupported. The last point is not our concern. > This bug really makes Gentoo look bad. Please just mark FF3 stable and be done > with it. Stabilisation of a package must follow some strict rules; as long as they are not met, we can not stabilise. This is sad; but those strict rules made Gentoo "stable" really "appreciable/enjoyable distribution" ... if we stop following them, we run in the wall. The real problem is: why can't we stab now ? which package is blocking ? which feature is unstable ? That is the topic ! (In reply to comment #14) > FYI: this is the bug that made me abandon Gentoo as a desktop OS 3 months ago. > This is not the only issue I had but it was clearly the decisive one. You were free to unmask this package. Dont blame the distro or maint for the fact you dont know how to unmask.
(In reply to comment #17) > * Gnome releases, which occur predictably every 6 months, take 4 months after > release to be marked stable in Gentoo. Other distros can get new Gnome out > within a month. Gentoo had E17 in portage more than 3 years before Debian unstable. That's why i came to Gentoo.
> (In reply to comment #15) > > I prefer that software be declared stable when it is indeed ready. > > I understand this, and I embrace it. But I get confused... Stability > decisions in Gentoo seem to be all over the place. Some observations of mine: > > * Gnome releases, which occur predictably every 6 months, take 4 months after > release to be marked stable in Gentoo. Other distros can get new Gnome out > within a month. That they are predictable does not mean that the stabilization should be quick. And by these "other distros", do you mean distros like Ubuntu and Fedora? These two have lax rules for stability; Gentoo stable is supposed to honor the name. If you want the latest GNOME, then just wait some weeks after release (as a safety measure), look for the bug reports, and then use package.keywords to inform Portage of your wishes. > > * A monster package like OpenOffice.org 3 is marked stable a week after > release. Other distros still haven't included it in their releases because, > according to them, the delivery schedule slipped so much that they couldn't > verify it was stable. This may have to do with Gentoo having a rolling release process. Also appreciate that 1) Different developers have varying rules for stability ("different" developers includes both the difference between Ubuntu developers and Gentoo developers and the difference between the various developers from a given distribution) 2) Different developers have varying amounts of time 3) Different distros have varying ways to test a new program version, varying amounts of users that use the new version, and varying skill levels of their userbase. 4) Different distros have different issues when integrating a given program > > * Firefox, seemingly simpler than Gnome and OO.o but still a complex program, > is not stable in Gentoo almost 6 months after release. Preview releases > happened for over 6 months. It was included as stable in the BETA (not even rc) > stage in a certain other distro's "long term support" version. While I like Ubuntu and recommend it to all Linux newcomers, (and installed it in my home and in a friend's computer), their QA has issues. As a quick example, the installer for 8.04, 8.04.1 and 8.10 does not work on AMD64 systems with SATA hard disks and vt8251 controller (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190492). This has been reported 10 months ago, in 2008-02-09. They haven't fixed it, have not provided feedback to the (many) bug reporters and have not include this vital information in the release notes for 8.04. Ditto for 8.04.1 and 8.10. I was one of the reporters, and I tried to help them as much as I could; I tested several versions of their installer, collected several information (lspci -vvnn, dmesg, /proc/cmdline, /proc/cpuinfo, everything), for each installer, each time testing it two ways: with and without the pci=nomsi kernel parameter. I also collected this information for the Mandriva installer (which works on the same hardware), told the developers about the pci=nomsi workaround and begged them to at least include this information in the release notes. And possibly mention the workaround too, so users like me wouldn't spend three days trying to debug the system, nor would hear a colleague saying "how do you claim Linux is easy to use? You spent days trying to install it in Wanderson's computer!". No developer response. Not even a "Thank you for your information, we are working on other bugs and will focus on this one when we have time". And no explanation of why in the Earth isn't this information in the release notes. > > Firefox is software used the world over. Are you (Jorge) saying that its source is not stable enough as released to be marked as stable in a distro within 6 months? It has been almost a year since the first FF3 was released to the public. 1) It is not very meaningful to count the time since the first beta was released. 2) MS Windows is also used all over the world. 3) See points 1-4 above > For me, as a user, what gets me about the whole process is that I just don't > know what's holding this ebuild up, Bug 234646 depends on: 234110 Bug 234110 was solved only recently. Also, besides =www-client/mozilla-firefox-3.0.*, what do you have to put in packake.keywords to install firefox 3? ~dev-libs/nss-3.12 and ~dev-libs/nspr-4.7.1, yes? So to know what is holding mozilla-firefox (besides the obvious information at the top of this page), you can look at bug reports for dev-libs/nss and dev-libs/nspr.
Bug 234646 depends on: bug 234110 bug 236678 bug 240117 bug 245352 bug 247040 bug 248133 bug 249161 Have fun fixing the bugs
I vouch for Jorge and Raul on this one. I'd rather have what a Gentoo developer says is stable which is that they mark software stable when it is "stable", rather than have another distro's opinion of stable which is, "If it doesn't crash when you start it up, it's stable".
I really wish I could code so I could help, maybe I should set myself a project to learn?
I think this is an extremely poor decision for Gentoo, as a distro...but I'm just an ordianary user, so what I say doesn't matter at all. Just keep in mind, though, that core apps like this deserve extra consideration in the minds of us useless users. IMO, the bugs listed have no business stopping FF3 from going 'stable'. But if you wish to avoid having to deal with bug reports in the future, then leaving everything ~ARCH, is obviously the best way to go for you personally.
(In reply to comment #14) > FYI: this is the bug that made me abandon Gentoo as a desktop OS 3 months ago. > This is not the only issue I had but it was clearly the decisive one. > > I am still using Gentoo on the server side. I switched to OpenSUSE for the > desktop. > There is no problem with installing one package (firefox) unstabled in stable distro in Gentoo. With at least some version of fx/xulrunner there are still problems. If you had none then you can simply put ~x86 as accepted keyword for those packages.
>I think this is an extremely poor decision for Gentoo, as a distro...but I'm >just an ordianary user, so what I say doesn't matter at all. Just keep in >mind, though, that core apps like this deserve extra consideration in the minds >of us useless users. IMO, the bugs listed have no business stopping FF3 from >going 'stable'. But if you wish to avoid having to deal with bug reports in >the future, then leaving everything ~ARCH, is obviously the best way to go for >you personally. The bugs listed are certainly reasons to not stablize FF3. One of the bugs says that the xulrunner library can cause epiphany to not run properly. How can we say that FF3 is stable when one if its libraries stops another program from running? I don't see why everyone is so worked up about FF3 not being marked stable. There's nothing stopping you from using it just because its not stable. If it's so important to use FF3 then just keyword it in package.keywords and use it. But it shouldn't be marked stable until it _is_ stable. If I was an epiphany user I wouldn't want to emerge FF3 only to have epiphany stop working even though they're both marked stable.
> The bugs listed are certainly reasons to not stablize FF3. One of the bugs > says that the xulrunner library can cause epiphany to not run properly. How > can we say that FF3 is stable when one if its libraries stops another program > from running? > > I don't see why everyone is so worked up about FF3 not being marked stable. > There's nothing stopping you from using it just because its not stable. If > it's so important to use FF3 then just keyword it in package.keywords and use > it. But it shouldn't be marked stable until it _is_ stable. > > If I was an epiphany user I wouldn't want to emerge FF3 only to have epiphany > stop working even though they're both marked stable. > Well, I've looked over this list of bugs, and specifically, the epiphany bug you mentioned. This bug has not even been duplicated as far as I can tell. Every time somebody misconfigures something on Gentoo, then files a bug, it seems it's a blocker for about 6 months...until they report that 'well...I removed --funroll-loops' from my CFLAGS, and it works now'..bottom line, unless we accept that even stable packages may not work with every possible combination of use variables, CFLAGS, other unstable packages, noobs learning the ropes, etc, ad nauseum, ad inifinitum, nothing is ever going to go stable in Gentoo...which is looking pretty much like the situation we find ourselves in right now. As far as Firefox 2 security patches being ported from Redhat or whoever...that is not a serious position. Those patches won't be ported, even if they are provided to Gentoo...are you joking? FF3 is being blocked by a few unconfirmed bugs (just search the forums or mail list for this bug) and you think some major effort is going materialize to port Redhat patches to FF2 on Gentoo? Right? Blockers are bugs that have been Dev-duped and/or confirmed by a 'significant' number of users...not every random bug posted in bugzilla meets that standard.
Are you sure this is the proper place for this discussion?. I am a bit tired of this comments. I sent a reply two days ago that finally didn't sent it because of comment #18 , but I will sent it anyway now for clarifiying my position: (In reply to comment #17) > (In reply to comment #15) > * Gnome releases, which occur predictably every 6 months, take 4 months after > release to be marked stable in Gentoo. Other distros can get new Gnome out > within a month. > Other distros usually have payed people (for example, Mandriva, Ubuntu, OpenSuSE, Fedora...) that are able to do this faster than Gnome Gentoo Team, whose members needs to take care of gnome when they have time :-) > * A monster package like OpenOffice.org 3 is marked stable a week after > release. Other distros still haven't included it in their releases because, > according to them, the delivery schedule slipped so much that they couldn't > verify it was stable. > I think that this was because of a security fix: http://bugs.gentoo.org/235824 anyway, I think that much less apps DEPENDS or RDEPENDS on openoffice that on firefox/xulrunner > * Firefox, seemingly simpler than Gnome and OO.o but still a complex program, > is not stable in Gentoo almost 6 months after release. Preview releases > happened for over 6 months. It was included as stable in the BETA (not even rc) > stage in a certain other distro's "long term support" version. As said just before, there are a lot of other apps that depend on xulrunner and firefox (see for example http://bugs.gentoo.org/show_bug.cgi?id=213296 ), and they need to be checked before blindly stabilizing firefox3/xulrunner1.9 Well, I know that Ubuntu included firefox3 really fast, but, I am not sure if it's a really strong argument, for example, Mandriva included Firefox3 from recently released Mandriva 2009.0... > For me, as a user, what gets me about the whole process is that I just don't > know what's holding this ebuild up, or that ebuild, but not a third one. I > don't know if it's just that I'm a n00b, but I don't know where to go in the > Gentoo world to find out that information. And this bug doesn't seem to give > even an ETA. > Well, in this specific case seems that Raúl Porcel (or any other Mozilla team member) needs to add arches to CC list, maybe they haven't had enough time or they have get some problem (who knows...), for know I would suggest you a bit more of patience :-) > Well, I don't have the ability to code. But what I AM good at is planning and > coordination. It seems this is lacking, at least in this instance. Where do I > go to volunteer to help with that? I don't know, but I think that planning and cordination, even being needed and highly appreciated :-), cannot do much if some bugs needs to be fixed before stabilizing some apps _______________ On the other hand, I see comments like this in many other places, for example, as I am a Mandriva Triage member I usually have to read comments from reporters critizing Mandriva because his bugs are not fixed fast enough. Or, for example, I have had a lot of problems for getting some fixes related with Pulseaudio in Ubuntu (well, they haven't being applied yet!)
FYI as soon as ff3.0.5 gets out, which is scheduled for 16 december, we'll mark it stable. There's no point in doing it ATM, since in less than 6 days we would have to stabilize 3.0.5 as well as it contains security fixes.
FYI ff 3.0.5 has been released yesterday
And there's a new bug!
and if the bug is specific to 3.0.5, we should better keep trying to stab 3.0.4 . I desagree with asking for stab of 3.0.4. Let's focus on an old version. We dont want to stab the latest; that's the workd of unstable. We want to stab any 3.* that dont haw too many bugs; so, before upgrading the title of bug to 3.0.5, please explain us why you do so: should 3.0.5 really bring bug fix ? if no, please let's focus on 3.0.4. Thanks.
(In reply to comment #33) > and if the bug is specific to 3.0.5, we should better keep trying to stab 3.0.4 > . I desagree with asking for stab of 3.0.4. Let's focus on an old version. We > dont want to stab the latest; that's the workd of unstable. We want to stab any > 3.* that dont haw too many bugs; so, before upgrading the title of bug to > 3.0.5, please explain us why you do so: should 3.0.5 really bring bug fix ? if > no, please let's focus on 3.0.4. Thanks. > The bug is not specific to 3.0.5, its on 3.0.4 even, please read the summary of the bugs. And i'm not going to stable 3.0.4 because it contains security issues which are fixed on 3.0.5.
Ok good: so stable will better stay with 2.0.0.18 without security fixes introduced in 3.0.5.
@Vytautas - I think stable be 2.0.0.19 shortly, which does include the security fixes in 3.0.0.5. That will be an issue when 3.0.0.6 is released however.
(In reply to comment #32) > And there's a new bug! > I s it a bug? I'm not so sure....I also find bizarre some of these people who show up here seemingly expressing relief that FF 3 will not go stable on Gentoo in any form for the foreseeable future, and keep expressing the opinion that it isn't ready to go stable, for reasons that they can't quite explain in technical terms. Just because somebody files a bug report, about some corner case they just discovered (or think they discovered...as I think this case will prove) does not mean a package should not go stable...3 things must be considered...1) Does the bug actually exist or is it just a configuration issue for a particular system. 2) What is the actual impact of the bug and the likelyhood that it will be fixed soon if it is an upstream problem 3) Does the bug, on whole, completely overshadow other improvements that may be more important in a web browser for the user community, to the point that it must stop the package from going stable I just tested that bug with an old profile, and could not dupe it. Neither could the reporter when he tried with a new profile (a workaround, to be sure)...and even if it does exist for some particular Gentoo configuration (I'm guessing a very small percentage, if anybody) it's impact is minor, at best. A perfect example of the kind of bug reports that seem to be enough to stop FF 3 from going stable on Gentoo, but nowhere else.
Guys, could you please stop this pointless bugspam in here? This won't make the bugs magically disappear. So either help resolving/fixing the bugs which are blocking this one from getting fixed or wait _patiently_ until someone else finds the time to do so. Rants and opinions are totally useless for the progress of this bug and don't belong into a bugtracker. Thank you.
(In reply to comment #38) > Guys, could you please stop this pointless bugspam in here? This won't make the > bugs magically disappear. So either help resolving/fixing the bugs which are > blocking this one from getting fixed or wait _patiently_ until someone else > finds the time to do so. > Rants and opinions are totally useless for the progress of this bug and don't > belong into a bugtracker. > Thank you. > Your welcome! I just did help...I tried and I could not dupe the bug.
Arches, please mark stable: =dev-libs/nspr-4.7.3 Arches: alpha amd64 arm hppa ia64 ppc ppc64 x86 =dev-libs/nss-3.12.2_rc1 Arches: alpha amd64 arm hppa ia64 ppc ppc64 x86 =net-libs/xulrunner-1.9.0.5 Arches: alpha amd64 arm hppa ia64 ppc ppc64 x86 =www-client/mozilla-firefox-3.0.5 Arches: alpha amd64 arm hppa ia64 ppc ppc64 x86 =www-client/mozilla-firefox-bin-3.0.5 Arches: alpha amd64 arm hppa ia64 ppc ppc64 x86 I'll cc arches when i'm back, tuesday 23 december 2008, unless a new bug comes up
hppa: Please add the xulrunner USE-flag on your make.defaults wherever firefox is. -------------- All: Sync your tree if nss-3.12.2_rc1 requires sqlite-3.6, i've downgraded the dep.
amd64 all done
Well, amd64 undone... xulrunner-1.9.0.5-patches-0.1.tar.bz2 is not available anywhere... its bug #252224
(In reply to comment #43) > Well, amd64 undone... xulrunner-1.9.0.5-patches-0.1.tar.bz2 is not available > anywhere... its bug #252224 > It should be now, sync again
minor issue with www-client/mozilla-firefox: * QA Notice: Pre-stripped files found: * /var/tmp/portage/www-client/mozilla-firefox-3.0.5/image/usr/lib/mozilla-firefox/firefox
amd64/x86 stable
alpha/arm/ia64 stable And obviously, www-client/mozilla-firefox-bin should only be amd64 and x86 :)
I dont know if that is normal, if i broke my portage (i had to update to portage 2.2 branch), or, else, but, amongst other things: moon-gen-3 ~ # emerge -DaNuv world [...] [ebuild U ] www-client/mozilla-firefox-3.0.5 [2.0.0.18] [...] [ebuild U ] www-client/mozilla-firefox-2.0.0.19 [2.0.0.18] [...] Total: 39 packages (36 upgrades, 2 in new slots, 1 reinstall), Size of downloads: 255,974 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: www-client/mozilla-firefox:0 ('ebuild', '/', 'www-client/mozilla-firefox-2.0.0.19', 'merge') pulled in by =www-client/mozilla-firefox-2* required by ('installed', '/', 'gnome-extra/yelp-2.22.1-r2', 'nomerge') (and 2 more) ('ebuild', '/', 'www-client/mozilla-firefox-3.0.5', 'merge') pulled in by www-client/mozilla-firefox required by ('installed', '/', 'app-text/acroread-8.1.3', 'nomerge') www-client/mozilla-firefox required by @world ********************************************************** It may be a local bug, or, even a PEBCAK (by trying to use portage 2.2 on stable distro); any way, here is what i am said. Too tired to work on this tonight. Just showing for interest. At least for me, migration will neither be trivial nor transparent. But in the case it is a bug, and other people meet it ... As FF3 is in stab tree, I think we can close this bug.
Please see this: 252459
(In reply to comment #41) > hppa: Please add the xulrunner USE-flag on your make.defaults wherever firefox > is. You mean, replace firefox with xulrunner? Why?
ppc and ppc64 done
(In reply to comment #50) > (In reply to comment #41) > > hppa: Please add the xulrunner USE-flag on your make.defaults wherever firefox > > is. > > You mean, replace firefox with xulrunner? Why? > No, not replace. xulrunner is preferred over firefox, and firefox is preferred over seamonkey. Firefox3 doesn't include the needed files for building stuff anymore. You can, of course replace the firefox USE-flag by xulrunner. The depends are this way ATM: xulrunner? net-libs/xulrunner !xulrunner? firefox? firefox-2 !xulrunner? !firefox? seamonkey
Since firefox 3 is now going stable, can I recommend an announcement is made on the main website and announce mailing list about the xulrunner use flag and how to avoid the ff3/ff2 block. This will help alleviate a lot of repetitive support for forum, irc and mailing list users (as well as some needless bugs I suspect). (Personally I think this should've been done before the first arch stabilised ff3 and announcements about blocks / issues like this before they happen would help to improve Gentoo)
(In reply to comment #48) I've duped that, but with an interesting subtlety: If I run emerge -auD world I get : "These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-libs/e2fsprogs-libs-1.41.3 [1.41.2] [ebuild U ] app-editors/nano-2.1.7 [2.1.5] [ebuild U ] sys-apps/busybox-1.12.2-r1 [1.11.1] [ebuild U ] sys-devel/automake-1.10.2 [1.10.1-r1] [ebuild N ] dev-lang/swig-1.3.36 USE="R java perl python -chicken -clisp -doc -guile -lua -mono -mzscheme -ocaml -octave -php -pike -ruby -tcl -tk" [ebuild N ] media-libs/lcms-1.17 USE="jpeg python tiff zlib" [ebuild N ] net-libs/xulrunner-1.9.0.5 USE="dbus gnome ipv6 java -custom-optimization -startup-notification" [ebuild U ] www-client/mozilla-firefox-3.0.5 [2.0.0.19] USE="dbus%* xulrunner%* -custom-optimization% -startup-notification%" LINGUAS="-bn% -bn_IN% -cy% -eo% -et% -gl% -hi% -hi_IN% -id% -is% -kn% -lv% -mr% -oc% -si% -sq% -sr% -te% -th%" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict:..." But if I run 'emerge -pu mozilla-firefox -1 e2fsprogs-libs nano busybox' I get: "[ebuild U ] sys-devel/automake-1.10.2 [1.10.1-r1] [ebuild N ] dev-lang/swig-1.3.36 USE="R java perl python -chicken -clisp -doc -guile -lua -mono -mzscheme -ocaml -octave -php -pike -ruby -tcl -tk" [ebuild U ] sys-libs/e2fsprogs-libs-1.41.3 [1.41.2] [ebuild U ] app-editors/nano-2.1.7 [2.1.5] [ebuild U ] sys-apps/busybox-1.12.2-r1 [1.11.1] [ebuild N ] media-libs/lcms-1.17 USE="jpeg python tiff zlib" [ebuild N ] net-libs/xulrunner-1.9.0.5 USE="dbus gnome ipv6 java -custom-optimization -startup-notification" [ebuild U ] www-client/mozilla-firefox-3.0.5 [2.0.0.19] USE="dbus%* xulrunner%* -custom-optimization% -startup-notification%" LINGUAS="-bn% -bn_IN% -cy% -eo% -et% -gl% -hi% -hi_IN% -id% -is% -kn% -lv% -mr% -oc% -si% -sq% -sr% -te% -th%"" Without any errors. As far as I can tell the only difference here is the order of installation! P.S. It feels like I'm trying to hijack this bug! Should I start a new one, or just keep going with comments on this one.
Try my bloved emerge -DaNuv world :) and report please :)
(In reply to comment #52) > No, not replace. xulrunner is preferred over firefox, and firefox is preferred > over seamonkey. Like this? Index: make.defaults =================================================================== RCS file: /var/cvsroot/gentoo-x86/profiles/arch/hppa/make.defaults,v retrieving revision 1.2 diff -u -B -r1.2 make.defaults --- make.defaults 10 Apr 2008 19:53:15 -0000 1.2 +++ make.defaults 30 Dec 2008 17:41:30 -0000 @@ -11,7 +11,7 @@ FEATURES="sandbox sfperms strict" -USE="cups foomaticdb fortran gdbm gpm imlib libwww pic spell xml2 firefox" +USE="cups foomaticdb fortran gdbm gpm imlib libwww pic spell xml2 firefox xulrunner" # 2006/08/18 - Donnie Berkholz <dberkholz@gentoo.org> # Defaults for video drivers
(In reply to comment #56) > (In reply to comment #52) > > No, not replace. xulrunner is preferred over firefox, and firefox is preferred > > over seamonkey. > > Like this? > > Index: make.defaults > =================================================================== > RCS file: /var/cvsroot/gentoo-x86/profiles/arch/hppa/make.defaults,v > retrieving revision 1.2 > diff -u -B -r1.2 make.defaults > --- make.defaults 10 Apr 2008 19:53:15 -0000 1.2 > +++ make.defaults 30 Dec 2008 17:41:30 -0000 > @@ -11,7 +11,7 @@ > > FEATURES="sandbox sfperms strict" > > -USE="cups foomaticdb fortran gdbm gpm imlib libwww pic spell xml2 firefox" > +USE="cups foomaticdb fortran gdbm gpm imlib libwww pic spell xml2 firefox > xulrunner" > > # 2006/08/18 - Donnie Berkholz <dberkholz@gentoo.org> > # Defaults for video drivers > Yes
(In reply to comment #55) Okay then (goodness, I didn't think about verbose!, but I originally found the problem with some permutation of -auND world): "PhiJ home # emerge -DaNuv world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-libs/e2fsprogs-libs-1.41.3 [1.41.2] USE="nls" 479 kB [ebuild U ] app-editors/nano-2.1.7 [2.1.5] USE="ncurses nls unicode -debug -justify -minimal -slang -spell" 1,435 kB [ebuild U ] sys-apps/busybox-1.12.2-r1 [1.11.1] USE="pam -debug -make-symlinks -savedconfig (-selinux) -static" 1,974 kB [ebuild U ] sys-devel/automake-1.10.2 [1.10.1-r1] 915 kB [ebuild N ] dev-lang/swig-1.3.36 USE="R java perl python -chicken -clisp -doc -guile -lua -mono -mzscheme -ocaml -octave -php -pike -ruby -tcl -tk" 0 kB [ebuild N ] media-libs/lcms-1.17 USE="jpeg python tiff zlib" 878 kB [ebuild N ] net-libs/xulrunner-1.9.0.5 USE="dbus gnome ipv6 java -custom-optimization -startup-notification" 33,307 kB [ebuild U ] www-client/mozilla-firefox-3.0.5 [2.0.0.19] USE="dbus%* gnome ipv6 java xulrunner%* -bindist -custom-optimization% -iceweasel -mozdevelop -restrict-javascript -startup-notification% (-debug%) (-filepicker%) (-moznopango%) (-xforms%) (-xinerama%) (-xprint%)" LINGUAS="en en_GB -af -ar -be -bg -bn% -bn_IN% -ca -cs -cy% -da -de -el -en_US -eo% -es -es_AR -es_ES -et% -eu -fi -fr -fy -fy_NL -ga -ga_IE -gl% -gu -gu_IN -he -hi% -hi_IN% -hu -id% -is% -it -ja -ka -kn% -ko -ku -lt -lv% -mk -mn -mr% -nb -nb_NO -nl -nn -nn_NO -oc% -pa -pa_IN -pl -pt -pt_BR -pt_PT -ro -ru -si% -sk -sl -sq% -sr% -sv -sv_SE -te% -th% -tr -uk -zh -zh_CN -zh_TW" 11,387 kB Total: 8 packages (5 upgrades, 3 new), Size of downloads: 50,372 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: www-client/mozilla-firefox:0 ('ebuild', '/', 'www-client/mozilla-firefox-3.0.5', 'merge') pulled in by www-client/mozilla-firefox required by world ('installed', '/', 'www-client/mozilla-firefox-2.0.0.19', 'nomerge') pulled in by =www-client/mozilla-firefox-2* required by ('installed', '/', 'net-www/mplayerplug-in-3.50', 'nomerge') =www-client/mozilla-firefox-2* required by ('installed', '/', 'gnome-extra/yelp-2.22.1-r2', 'nomerge') (and 1 more) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook."
Created attachment 176897 [details] /tmp/emerge--info -v is only usefull to avoid asking people their emerge --info What i was pointing to, was especially -N ... because many breakage are due to a broken dep (a dep compiled with flags you changed in the mean time). -Nv thus often at least show the problem (half time), and, sometimes even just fix it (by remerging the package with bad flags). It's strange, I have yelp, and did not encounter this. Paste a bit more of "equery -d firefox", that should who why those two ask (and stick to) for an old version of Firefox. Also emerge -vp net-www/mplayerplug-in gnome-extra/yelp for me: [ebuild R ] gnome-extra/yelp-2.22.1-r2 USE="xulrunner -beagle -debug -lzma" 0 kB so, we have the same Yelp and this version did not block FF3 upgrade for me.
(In reply to comment #59) Err, this appears to be bug 253181 that we're discussing!
Summary of bug seems fulfilled, and all archs seems to be done; can't we now close this bug ?
(In reply to comment #61) > Summary of bug seems fulfilled, and all archs seems to be done; can't we now > close this bug ? > hppa is not done
All done for HPPA.
All done then
