[gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?
Luca Barbato [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 16 Mar 2008 07:30:00 +0100: Raúl Porcel wrote: Xulrunner-1.9 is a big change, and the apps using it won't work until they are fixed. So this needs to be decided, i've been working on slotting xulrunner, and i'm ready to put it in the tree. However i'd like to see what developers(since they will be the ones who will have to deal with this) and users prefer. Even if an app is compatible with xulrunner-1.9, it will have to be patched if we slot xulrunner. Since the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions with current xulrunner-1.8. The other approach would be not slotting it, p.mask xulrunner-1.9 and wait until all the packages work against it and then unmask. Given the number of applications I'd rather have them fixed with the patches pushed to respective upstreams if we got there first. Thanks for the wisdom of asking about this, Raul. Given the way you worded things, it looks like the consensus is heading a way other than you might have expected. Unslotted xulrunner seems to be the consensus, so we aren't committing to forever maintain patches ourselves -- on a package-base that may well expand over time. Some questions. What's the possibility of getting upstream to handle the renaming, thereby making slotting much easier while eliminating the eternal patch commitment? Has the issue even been brought up with mozilla-upstream? I know they aren't always the most receptive to community suggestions, but it's worth asking, anyway. How many packages are we talking about? Regardless of how we go, fixing ten is going to be far easier than a hundred, or five hundred. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?
Duncan wrote: Unslotted xulrunner seems to be the consensus, so we aren't committing to forever maintain patches ourselves -- on a package-base that may well expand over time. The consensus is to have updated applications, the new xulrunner seems quite an improvement so make _quite_ sense move towards it. Some questions. What's the possibility of getting upstream to handle the renaming, thereby making slotting much easier while eliminating the eternal patch commitment? Has the issue even been brought up with mozilla-upstream? I know they aren't always the most receptive to community suggestions, but it's worth asking, anyway. Discussing with upstream this would be good as well, BUT you shouldn't rely on that. How many packages are we talking about? A list had been produced already and is relatively short and some are just nsplugins (and those shouldn't require a change) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?
Duncan wrote: Luca Barbato [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 16 Mar 2008 07:30:00 +0100: Raúl Porcel wrote: Xulrunner-1.9 is a big change, and the apps using it won't work until they are fixed. So this needs to be decided, i've been working on slotting xulrunner, and i'm ready to put it in the tree. However i'd like to see what developers(since they will be the ones who will have to deal with this) and users prefer. Even if an app is compatible with xulrunner-1.9, it will have to be patched if we slot xulrunner. Since the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions with current xulrunner-1.8. The other approach would be not slotting it, p.mask xulrunner-1.9 and wait until all the packages work against it and then unmask. Given the number of applications I'd rather have them fixed with the patches pushed to respective upstreams if we got there first. Thanks for the wisdom of asking about this, Raul. Given the way you worded things, it looks like the consensus is heading a way other than you might have expected. Unslotted xulrunner seems to be the consensus, so we aren't committing to forever maintain patches ourselves -- on a package-base that may well expand over time. Some questions. What's the possibility of getting upstream to handle the renaming, thereby making slotting much easier while eliminating the eternal patch commitment? Has the issue even been brought up with mozilla-upstream? I know they aren't always the most receptive to community suggestions, but it's worth asking, anyway. How many packages are we talking about? Regardless of how we go, fixing ten is going to be far easier than a hundred, or five hundred. Upstream won't do that...so i guess this means xulrunner gets unslotted :) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] maintainer wanted: x11-themes/gtk-engines-murrine
On Mon, 17 Mar 2008 11:25:59 -0400 Josh Nichols [EMAIL PROTECTED] wrote: I personally don't use this engine anymore, so I'm looking for someone to take it off my hands. There are a few open bugs (including a version bump), but they should be pretty easy to fix: https://bugs.gentoo.org/show_bug.cgi?id=192797 https://bugs.gentoo.org/show_bug.cgi?id=198815 https://bugs.gentoo.org/show_bug.cgi?id=204488 jokey has kindly agreed to let me proxy maintain this package, so I'll take it unless an existing dev really wants it. --atj -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
Hi again,
I've just come up with a plan for the new eclass based on previous
feedback. Basically, I want to commit this patch [1] ASAP.
If I commit this right now here's what's going to happen :
- ebuilds that use the gnome2 eclass and other eclasses that don't
export pkg_preinst() will be fine. Most Gnome packages are thus fine.
- ebuilds that have inherit gnome2 $eclass_foo [*] will still work
for now, but won't work once I commit the rest of the eclass changes
- ebuilds that have inherit $eclass_foo gnome2 [*] won't work as
they used to.
[*] if $eclass_foo has indeed a pkg_preinst somewhere, like the games
eclass.
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
somewhere) I'd really appreciate it, as I really don't want to read
through thousands of ebuilds to figure it out.
Thanks
Rémi
[1] The Patch (tm)
--- gnome2.eclass 10 Feb 2008 14:47:14 - 1.83
+++ gnome2.eclass 17 Mar 2008 16:30:31 -
@@ -106,6 +106,9 @@
rm -fr ${D}/usr/share/applications/mimeinfo.cache
}
+gnome2_pkg_preinst() {
+}
+
gnome2_pkg_postinst() {
gnome2_gconf_install
fdo-mime_desktop_database_update
@@ -131,4 +134,4 @@
fi
}
-EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_postinst pkg_postrm
+EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_preinst
pkg_postinst pkg_postrm
--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
On Mon, Mar 17, 2008 at 10:02 PM, Rémi Cardona [EMAIL PROTECTED] wrote:
[snip]
[1] The Patch (tm)
--- gnome2.eclass 10 Feb 2008 14:47:14 - 1.83
+++ gnome2.eclass 17 Mar 2008 16:30:31 -
@@ -106,6 +106,9 @@
rm -fr ${D}/usr/share/applications/mimeinfo.cache
}
+gnome2_pkg_preinst() {
+}
+
Shouldn't this function be
gnome2_pkg_preinst() {
:
}
? Because bash chokes on empty functions..
[snip]
--
~Nirbheek Chauhan
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] bzr.eclass into Portage
Hi, in the Emacs overlay we imported the bzr.eclass from the xeffects overlay. In the near future Emacs development will switch from CVS to Bazaar and thus we need the new eclass in Portage to still provide our live ebuilds from app-editors/emacs-cvs. Question is now, who wrote it? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
Nirbheek Chauhan a écrit :
Shouldn't this function be
gnome2_pkg_preinst() {
:
}
? Because bash chokes on empty functions..
I was actually planning on using a bogus debug-print statement :) but
thanks for letting me know.
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
Le lundi 17 mars 2008 à 17:32 +0100, Rémi Cardona a écrit :
[snip]
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
somewhere) I'd really appreciate it, as I really don't want to read
through thousands of ebuilds to figure it out.
Here is my brute force method:
$ # extract the list of package defining custom pkg_preinst()
$ egrep -r ^.*?_pkg_preinst /usr/portage/eclass/* |cut -f1 -d: |sed \
s:/usr/portage/eclass/::g;s:.eclass::g |sort|uniq| tee \
export-preinst.list
$ # extract the list of ebuilds inheriting gnome2 eclass
$ find /usr/portage/ -name *.ebuild -exec egrep -H gnome2 {} \; | \
cut -f1 -d: |uniq| tee gnome-inherit.list
$ # wh
$ for x in $(cat gnome-inherit.list); do for y in \
$(cat export-preinst.list); do egrep --color -H inherit.*${y} $x; \
done; egrep --color -H ^pkg_preinst $x; done | \
tee output-unformated.list
$ cat output-unformated.list |cut -f1 -d:|sort|uniq
of course YMMV and there might be simpler/faster solutions but oh
well... it gave me an output of 62 packages.
--
Gilles Dartiguelongue [EMAIL PROTECTED]
Gentoo
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
Rémi Cardona kirjoitti: Now, basically, if the portage metadata or QA people could tell me a way to figure *all* the ebuilds that inherit gnome2 *and* have a pkg_preinst() function somewhere (either in the ebuild or in an eclass somewhere) I'd really appreciate it, as I really don't want to read through thousands of ebuilds to figure it out. Thanks http://archives.gentoo.org/gentoo-dev/msg_a57bf5f459324975bae8843fe7cdf469.xml signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bzr.eclass into Portage
Christian Faulhammer kirjoitti: Hi, in the Emacs overlay we imported the bzr.eclass from the xeffects overlay. In the near future Emacs development will switch from CVS to Bazaar and thus we need the new eclass in Portage to still provide our live ebuilds from app-editors/emacs-cvs. Question is now, who wrote it? V-Li Look at the SCM history in xeffects? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
On Tuesday 18 March 2008 00:42:02 Gilles Dartiguelongue wrote:
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
somewhere) I'd really appreciate it, as I really don't want to read
through thousands of ebuilds to figure it out.
Here is my brute force method:
Wow.. :p
$ # extract the list of package defining custom pkg_preinst()
$ egrep -r ^.*?_pkg_preinst /usr/portage/eclass/* |cut -f1 -d: |sed \
s:/usr/portage/eclass/::g;s:.eclass::g |sort|uniq| tee \
export-preinst.list
$ grep -l 'EXPORT_FUNCTIONS.*pkg_preinst' $(portageq portdir)/eclass/*.eclass |
\
while read eclass; do
basename $eclass .eclass
done | tee export-preinst.list
$ # extract the list of ebuilds inheriting gnome2 eclass
$ find /usr/portage/ -name *.ebuild -exec egrep -H gnome2 {} \; | \
cut -f1 -d: |uniq| tee gnome-inherit.list
$ inquisitio --repository gentoo --all-versions --compact --keys INHERITED \
--matcher exact gnome2 | cut -d' ' -f2 | tee gnome2-inherited.list
[...]
of course YMMV and there might be simpler/faster solutions but oh
well... it gave me an output of 62 packages.
While inquisitio may not be faster it is certainly more reliable. Another option
is to rely on the metadata cache in an rsync tree where INHERITED is the tenth
line in each entry.
--
Bo Andresen
Gentoo KDE Dev
signature.asc
Description: This is a digitally signed message part.
