Re: [gentoo-dev] remove cups from releases/make.defaults ?
On Sat, 5 May 2012, hasufell wrote: # grep ^USE /usr/portage/profiles/releases/make.defaults USE=acl cups gdbm gpm nptl nptlonly sysfs unicode This is used by /usr/portage/profiles/default/linux/amd64/10.0 for example, so I have cups in default NON-DESKTOP profile like it was a mandatory useflag. When you are at it: Why is USE=gdbm there? Even desktops run fine without sys-libs/gdbm nowadays; even sys-libs/db is only needed on desktops if you use libreoffice (in contrast to e.g. openoffice-bin where it is bundled, fortunately). Maybe this was different when e.g. some applications (netscape?) could use gdbm instead of berkeley's db, but nowadays, when many applications (e.g. firefox) have switched to sqlite, it seeems that gdbm is outdated. I have USE=-cups -gdbm ... in make.conf on KDE desktop machines since ages and no problems with it.
Re: [gentoo-dev] remove cups from releases/make.defaults ?
On 05/06/2012 04:58 AM, Ben wrote: On 6 May 2012 04:45, hasufellhasuf...@gentoo.org wrote: # grep ^USE /usr/portage/profiles/releases/make.defaults USE=acl cups gdbm gpm nptl nptlonly sysfs unicode This is used by /usr/portage/profiles/default/linux/amd64/10.0 for example, so I have cups in default NON-DESKTOP profile like it was a mandatory useflag. Is it? I don't even have a printer and expect that profile to be the very minimum. This would rather be a useflag for targets/desktop/make.defaults imo. I see a similar discussion has happened 2 years ago, but I don't see a solution there. I would argue (and I did 2 years ago) that it doesn't belong even in the desktop profile. I'm certainly not the only desktop user who hasn't had a printer in years. Cheers, Ben | yngwin +1 for getting rid of it everywhere in profiles, it's one of those steps you do during installation as first thing, set USE=-cups (when you realize GTK+ pulling it in for printing widgets/dialogs)
[gentoo-dev] Last rites: net-im/emesene:0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (06 May 2012) # Stopped working long time ago. Removal in 30 days # Use emesene:2 as an alternative net-im/emesene:0 - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPpkCeAAoJEPqDWhW0r/LCtr4P/0U1+JvnsLCEUGxEWVpytxMd 6+Jm1cBvJ6z8p0aKemz7w879hEzQ1Gb4/9nbJ0Uydzf1p5yNzvAqc14OI1h8M9Xo wm9o9YJBDoQ1xmgt1NIMjLxuTS2MJAOPMU/zzQ60Lha9RjLDnWDH1M1arwofZ++m j6xfaYDPtxCKojRmU/b/uX3m3iykilVBGbxhiBLr7LeShwS3tLRu2YPrWek9T209 H/00Er1i5zf4jBufd/aOsH71mvzegdvHNNOjhx69V8Ras8iQCsP8AF/YYZrlIl4P S3k7+2/Vfze1Pz1cwIzIuPy7aty7SknCjVbqJIm0WkuwIQJs2KaeEqp4jp+QWARW OolHD5T1JEHAWozXD5MacSJC4X++yRh+vNh734Gx3FyFwc1MYLjx1a+4owMIEyTN r4cWqYkgQt83WTkMfV/vGrPzm4W9ABvPrU71/RtXcheWJ0gQQSxycLDWTBqJ/2+H s0X2Bjo24mlbDNPH0MNRs8BsXflH1RI0HeYods7sdXdjtn5fc7PFP/wlplCSCaKw 2uheBLNzzUGuXFbcn+oUUR8eX418KKRo/943YiOuZz4wwzBliOVjO4ntVVR6m6Yg iueCCZ5U+07SBSH+nhTmgqY0kUKvIBagxk0jn3Tu0M2PUt98JBzDh+ouywbZ3UCI afmNcm5upo1XTCdDP+Zo =6lYP -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/06/2012 03:04 AM, Ben wrote: On 6 May 2012 08:29, Dale rdalek1...@gmail.com wrote: I mentioned this once a long time ago. We expect things to stay the same unless we do something to change them. If things change without us doing the change, we tend to freak out a bit. We don't need any freaking out. Sounds to me like it would be a good idea to make a new, more minimal profile. What do you guys think? Cheers, Ben | yngwin A new minimal profile targeting who? Desktop users with lightweight DE/WM ? Sounds about right to me - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPpkMNAAoJEPqDWhW0r/LCb/sQAKewKPPsWqPvb+wy14difjuh kg36VFKkDC2D2YFH6sj89LHFilC3xKNN1IOA8Nxa22hXM3F4zhfyLQet55Y99L4U 8+S29cN/IBGA3/aHvXgvYjTCrybQHGBmQFRjnDaGkPK/Nf87Khp6/8jbJFEhU1wu 8VuzJaErVZJDVbCVfD7hITEkWHizg2flV7LNkONVkFhl37WZ7+Oxx/hC3HXZ4kae 65SYKVmcMitzwrO+1y6/y+YIvc1jN3JaZcG7zUrgMjYswlZRfVtO6XYv8mGbGx71 TH+M8YsybqewCiy+4H57ULgrV27t0bWseepMVZ8CWMOx2sChkWvY+DB5rQTKX55I lx/xcuUChIKpmAQq3uyMRaQvFxQqemwpUG8XZQGQLyIAFvWa5Rc2WJKk0sF+io87 Uf5jebOx5t33ehCkikLeAJMreEC0CLE2o6gDGVKGRVLXqWEGQbMif00eObiZLyu9 dE8/ma+xisS4YQCBGsuJaQX7yf3aTYy94lArgee0I/Zp7dhI8uvlFCiHeP1/+Z1d upbYD1KFMEVgYv4WYA+5M4EU2Azbn+qhHkXPzBGI16tDeO+KxqueyxZhSQ9/X9VM u1EBhW/+OX2BiItQ2qaemkD2MNq9Yl/HWkdLLT6kTBMZ1oOzxyN/VlLQN9DcWGcK KKJLqeuEN7KxX786jBwb =vbD9 -END PGP SIGNATURE-
Re: [gentoo-dev] remove cups from releases/make.defaults ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/06/2012 02:58 AM, Ben wrote: On 6 May 2012 04:45, hasufell hasuf...@gentoo.org wrote: # grep ^USE /usr/portage/profiles/releases/make.defaults USE=acl cups gdbm gpm nptl nptlonly sysfs unicode This is used by /usr/portage/profiles/default/linux/amd64/10.0 for example, so I have cups in default NON-DESKTOP profile like it was a mandatory useflag. Is it? I don't even have a printer and expect that profile to be the very minimum. This would rather be a useflag for targets/desktop/make.defaults imo. I see a similar discussion has happened 2 years ago, but I don't see a solution there. I would argue (and I did 2 years ago) that it doesn't belong even in the desktop profile. I'm certainly not the only desktop user who hasn't had a printer in years. Cheers, Ben | yngwin That makes sense but maybe it is something that releng@ should decide? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPpkQqAAoJEPqDWhW0r/LCRzEP/0L+NMu6l3Ngvuoy7BQS2Xry nyx+VE4lyRppxje0nOdf9Lg7twoPGhl4wkFhOL844H0jcTyh4OBrVaagQLmvElu6 lPz3EpmRtiWOESePPlrtjbGJl+iUMBxCBkMIcdujEalQLtSDgCMRci5H6jYocBke DVm0+MP2j3tM38aDZVE1Ix3EFYb8zgpkVCIGPND5NieLM54rW/hLJ5OOdjBdv2J9 6dmScL8SPTK+1SvybvRdQbx2ySEhtq8iuRRS5iVoEzsUZbnY4b0NKcHJY+RPb25D wkHnr89APAr0lEQwCn5EAwkucA8P6O64yR+O7nzkXQm4bvJQ07CtNlGTj0COAmOJ 1OKaMJQbl0j53RBdngZAkXAKXaOND8poy/btOZ82kZ24DxrvnRyNChw7EkbWr2ig wgowisKSBHQIMgZWxjbrasAYBmEOnsOB0GJcIigXNwyMbtOMSwNkldnZlw98j9if augG8vHgexBqMA9orWDqyWl7jYOtTd300NHPoet+WO4soWezZ4lnY4goNMIpVSxX PqtPUObTcKzaOcjG8CC6J1qKjrttyNFyszp/amo3gzDKnOKuxVZKPqDpGpdNw6Ty AWa2h/gl+IOxK2D8S61i02ftOyf9/lblqVibC5MC+BeQMJOhl3FA0J7K5XcOlplY ogfrlG3COutvB9NpVwR0 =M9TA -END PGP SIGNATURE-
Re: [gentoo-dev] add global useflag: webkit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/06/2012 02:55 AM, Ben wrote: On 6 May 2012 08:34, hasufell hasuf...@gentoo.org wrote: # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module IIRC this was already voted on ~2 years ago (before I retired). It's just waiting for someone to implement it. See also bug #285743. Cheers, Ben | yngwin Any logs about that? I don't remember but to be honest there is nothing to discuss here. 33 packages are more than enough to justify a new global use flag. The description also looks good to me - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPpkSXAAoJEPqDWhW0r/LC5kIP/1WL9bcKcXdQS7/J47YrckNj //lv/7fBUdXwroF37b1snSzREflLNoaIhqPAqB6jukB0cApUMbRHEPuPARV/hro/ OWjCU6UfBYC6Sr8fiw98xeScKH1UitUj1PWArGdM0B6gM2RGY6PB1UR0FxRKZPrA 2abD3jRngvPjHkuCJ2iic6CAeo2C2NrX4lSSTsNNM4NNLqPh0Hc3OmUk/A/cp9jx 0z8U4PxoWTWxhFx9E2mkg2fE9Fsyf+/9gVVZpSml2RD2NVtk9Nw5S3acVlSrooX4 xpIL5hkQaU+a31ELa3cB9Hn3XUA5muAxLQwmkVTHF5srsRlFHjqF20IoCmLwt+oe dGg3uC4bxHw8lnnDzQMaP4NaZjkBRFaGYmE5Hb5V5k0ZTGmSm/DCj1TPGETLFJ/l K/CjDxsWmKJpaxAHEQD+VKqS8KiD6U3FrIoWfKsSNk+0Y+tDwCKaxuUDZjGvUZER jbJIQqmwaSD2GXQU1qEpoNn8Sjg9CpwNhwOiUjEIc/3To5vRFuIjgTYw4TdXw+JO z+ftLC/9SXeCkd1dfh7GwaoxKGOl2GoOdUpROmzaXjTGdaeAKoNHc0Y4Y4IZQr97 jYjraY11v/c53bYA+mi8lvlheOP9PPL1r5K/IqX270/xCXjMYn+3G57k3pJW3+Zc mv4iWudewyjJrLYSFQwU =RJdP -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On Sun, 06 May 2012 10:23:25 +0100 Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/06/2012 03:04 AM, Ben wrote: On 6 May 2012 08:29, Dale rdalek1...@gmail.com wrote: I mentioned this once a long time ago. We expect things to stay the same unless we do something to change them. If things change without us doing the change, we tend to freak out a bit. We don't need any freaking out. Sounds to me like it would be a good idea to make a new, more minimal profile. What do you guys think? Cheers, Ben | yngwin A new minimal profile targeting who? Desktop users with lightweight DE/WM ? I don't think even heavyweight DE/WM usually needs ldap... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] add global useflag: webkit
On Sun, May 6, 2012 at 2:34 AM, hasufell hasuf...@gentoo.org wrote: # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module I suggest the following description: Add support for the WebKit HTML rendering/layout engine. Otherwise +1 from me. Thanks, Davide
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On Sun, May 6, 2012 at 5:37 AM, Michał Górny mgo...@gentoo.org wrote: I don't think even heavyweight DE/WM usually needs ldap... Tend to agree. I don't think we want to create a new profile every time we want to change one of the flags. Some other questionable ones: emboss - Adds support for the European Molecular Biology Open Software Suite firefox - probably OK for what it does now, but not everybody uses it xulrunner - not even used now There will always be some level of variation if you are looking at single flags. What matters isn't coming up with profiles that exactly match all of our users, but rather ones that are good for 80+% of them. As far as ldap goes, if we wanted an enterprise desktop profile that might be a good fit for such a configuration. I agree that -ldap isn't really a lightweight desktop so much as a normal one. If you really wanted lightweight then you'd probably not be running desktop at all, or the regular desktop vs kde/gnome. The bottom line is that we don't need 47 different profile targets - there will always be a use for 1 more. That's why we all run Gentoo - we aren't bound by the decisions made for us by the package maintainers. Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
eclass/ has a ChangeLog
(and this is getting old that everyone keeps ignoring it, I've proposed
punting the ChangeLog from eclass/ directory once, and repeating it now)
On 05/06/2012 02:42 PM, Fabian Groffen (grobian) wrote:
grobian 12/05/06 11:42:07
Modified: libtool.eclass
Log:
also apply sol2-conf patchset
Revision ChangesPath
1.100eclass/libtool.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/libtool.eclass?rev=1.100view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/libtool.eclass?rev=1.100content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/libtool.eclass?r1=1.99r2=1.100
Index: libtool.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v
retrieving revision 1.99
retrieving revision 1.100
diff -u -r1.99 -r1.100
--- libtool.eclass 6 May 2012 10:41:48 - 1.99
+++ libtool.eclass 6 May 2012 11:42:07 - 1.100
@@ -1,6 +1,6 @@
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v 1.99 2012/05/06
10:41:48 grobian Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v 1.100 2012/05/06
11:42:07 grobian Exp $
# @ECLASS: libtool.eclass
# @MAINTAINER:
@@ -333,7 +333,7 @@
fi
done
;;
- mint-conf|gold-conf)
+ mint-conf|gold-conf|sol2-conf)
ret=1
local subret=1
if [[ -e ${d}/configure ]]; then
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
On 06-05-2012 14:41:13 +0300, Samuli Suominen wrote: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) % head Changelog # ChangeLog for eclass directory # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.241 2012/05/06 10:41:48 grobian Exp $ 06 May 2012; Fabian Groffen grob...@gentoo.org +ELT-patches/sol2-conf/2.4.2, libtool.eclass: Add ELT patch for Solaris x64 libtool problem where the linker is set to 'ld_sol2' -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] remove cups from releases/make.defaults ?
hasufell wrote:
# grep ^USE /usr/portage/profiles/releases/make.defaults
USE=acl cups gdbm gpm nptl nptlonly sysfs unicode
I cannot find any description about 'nptlonly' and 'sysfs' in either
/profiles/use{,.local}.desc. Are they still used?
This is used by /usr/portage/profiles/default/linux/amd64/10.0 for
example, so I have cups in default NON-DESKTOP profile like it was a
mandatory useflag.
Is it? I don't even have a printer and expect that profile to be the
very minimum.
+1 on that.
Thanks for cleaning up profiles!
--
Cyprien/Fulax
gentoo-lisp project contributor
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
El dom, 06-05-2012 a las 07:33 -0400, Rich Freeman escribió: On Sun, May 6, 2012 at 5:37 AM, Michał Górny mgo...@gentoo.org wrote: I don't think even heavyweight DE/WM usually needs ldap... Tend to agree. I don't think we want to create a new profile every time we want to change one of the flags. Some other questionable ones: emboss - Adds support for the European Molecular Biology Open Software Suite firefox - probably OK for what it does now, but not everybody uses it xulrunner - not even used now There will always be some level of variation if you are looking at single flags. What matters isn't coming up with profiles that exactly match all of our users, but rather ones that are good for 80+% of them. As far as ldap goes, if we wanted an enterprise desktop profile that might be a good fit for such a configuration. I agree that -ldap isn't really a lightweight desktop so much as a normal one. If you really wanted lightweight then you'd probably not be running desktop at all, or the regular desktop vs kde/gnome. Maybe desktop should be more lightweight oriented and for people (like me) wanting more, use gnome/kde instead (or create xfce/lxde... if they need other flags...) The bottom line is that we don't need 47 different profile targets - there will always be a use for 1 more. That's why we all run Gentoo - we aren't bound by the decisions made for us by the package maintainers. Rich signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
On 05/06/2012 02:45 PM, Fabian Groffen wrote: On 06-05-2012 14:41:13 +0300, Samuli Suominen wrote: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) % head Changelog # ChangeLog for eclass directory # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.241 2012/05/06 10:41:48 grobian Exp $ 06 May 2012; Fabian Groffengrob...@gentoo.org +ELT-patches/sol2-conf/2.4.2, libtool.eclass: Add ELT patch for Solaris x64 libtool problem where the linker is set to 'ld_sol2' sorry, my bad if I missed something... was only reading commits ML. :-/
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On 05/06/2012 03:01 PM, Pacho Ramos wrote: El dom, 06-05-2012 a las 07:33 -0400, Rich Freeman escribió: On Sun, May 6, 2012 at 5:37 AM, Michał Górnymgo...@gentoo.org wrote: I don't think even heavyweight DE/WM usually needs ldap... Tend to agree. I don't think we want to create a new profile every time we want to change one of the flags. Some other questionable ones: emboss - Adds support for the European Molecular Biology Open Software Suite firefox - probably OK for what it does now, but not everybody uses it xulrunner - not even used now There will always be some level of variation if you are looking at single flags. What matters isn't coming up with profiles that exactly match all of our users, but rather ones that are good for 80+% of them. As far as ldap goes, if we wanted an enterprise desktop profile that might be a good fit for such a configuration. I agree that -ldap isn't really a lightweight desktop so much as a normal one. If you really wanted lightweight then you'd probably not be running desktop at all, or the regular desktop vs kde/gnome. Maybe desktop should be more lightweight oriented and for people (like me) wanting more, use gnome/kde instead (or create xfce/lxde... if they need other flags...) There will be no xfce/ sub profile as we don't need one (ever). Xfce is working fine on default (standard) desktop components from freedesktop.org and the GTK+ toolkit. We can still do our changes directly in the desktop profile, such as, enabling USE flags like thunar in make.defaults (or if needed, package.use) since the flags will only concern packages within xfce-* categories and/or Xfce specific packages in other categories. When this was discussed earlier, the LXDE and ROX maintainers declared same, and it seems to still be valid from what I can see. Only GNOME and KDE maintainers wanted one, because they have packages in random categories which can be used in a generic way, or oriented towards their desktops. As in, desktop is (or should be) already the lightweight version. The story behind USE flags like ldap and cups are spawning from something else, and I'm all for removing them both. The bottom line is that we don't need 47 different profile targets - there will always be a use for 1 more. That's why we all run Gentoo - we aren't bound by the decisions made for us by the package maintainers. Rich
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
On Sun, 6 May 2012 07:33:59 -0400 Rich Freeman ri...@gentoo.org wrote: Some other questionable ones: emboss - Adds support for the European Molecular Biology Open We've had this discussion before... The question is not are people likely to want emboss?. The question is of people who use packages that have an emboss use flag, are those people likely to want emboss?. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El dom, 15-04-2012 a las 17:09 +0200, Philipp Riegger escribió: On Sat, 14 Apr 2012 14:24:25 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 04/14/2012 02:16 PM, Pacho Ramos wrote: Due long devaway, his packages need a co-maintainer, feel free to add to metadata if you want. Thanks: dev-util/ciabot-svn media-sound/teamspeak-client-bin media-sound/teamspeak-server-bin sys-apps/newrelic-sysmond I believe it's time to lastrite teamspeak* because they link against mysql libraries with SONAME we don't ship anymore Therefore rendering the packages useless Can you elaborate on this? I have these ebuilds in my local overlay, renamed to install the latest versions. So maybe a (really simple) version bump would be enough. Philipp Well, in tree versions are still buggy and outdated, I would vote for either: 1. Mask them for removal (server is already hardmasked, but client not). 2. Proxy maintain them if anyone volunteers. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
Am Samstag, 5. Mai 2012, 23:15:46 schrieb Markos Chandras:
On 05/05/2012 08:04 PM, Michał Górny wrote:
On Sat, 5 May 2012 20:40:47 +0200 Andreas K. Huettel
dilfri...@gentoo.org wrote:
there's a growing culture of libreoffice extensions, and (with
the help of an eclass prepared by scarabeus) it would be nice to
get some of them into the portage tree. Now we have to decide
where to put them.
Suggestion: new category office-ext
What do you think?
office-plugins, to follow suit.
This may be confusing as people would expect these plugins to work
with both {open,libre}office packages. If these plugins are just for
libreoffice then I would prefer app-libreoffice like other people have
already suggested
I've collected information and the extensions (should) work with any office
variant, openoffice and libreoffice. To be more precise, they should work with
anything that uses the so-called uno bridge.
This is why I like the new category office-plugins best... and would like to
implement that one.
Any additional objections?
Cheers, Andreas
--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
Am Sonntag, 6. Mai 2012, 14:03:02 schrieb Pacho Ramos: El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/06/2012 05:35 PM, Pacho Ramos wrote: Well, in tree versions are still buggy and outdated, I would vote for either: 1. Mask them for removal (server is already hardmasked, but client not). 2. Proxy maintain them if anyone volunteers. I would proxy maintain. Feel free to send me a pm on #irc.freenode.net, user xmw. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+mqR0ACgkQknrdDGLu8JAtEAD+PnlLNWhp7xYmD/UAePOnTnxQ Emeh3NCZExK62gaIQBkBAINCB0vxpFn3APnyGk3Ohsnrg5KBHqk1AVfxdGo3IZtY =wBk/ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: Am Sonntag, 6. Mai 2012, 14:03:02 schrieb Pacho Ramos: El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( Well, in this case I intentionally was referring only to eclass/ as maybe it can be implemented for it even handling normal packages as currently signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
On 06-05-2012 19:23:47 +0200, Pacho Ramos wrote: El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( Well, in this case I intentionally was referring only to eclass/ as maybe it can be implemented for it even handling normal packages as currently The implementation has never been the problem. It's that people want to be able to edit (correct) the messages. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
El dom, 06-05-2012 a las 19:28 +0200, Fabian Groffen escribió: On 06-05-2012 19:23:47 +0200, Pacho Ramos wrote: El dom, 06-05-2012 a las 18:10 +0200, Andreas K. Huettel escribió: Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( Well, in this case I intentionally was referring only to eclass/ as maybe it can be implemented for it even handling normal packages as currently The implementation has never been the problem. It's that people want to be able to edit (correct) the messages. In that case... :-( Thanks for noticing signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
On Sun, 6 May 2012, Andreas K Huettel wrote: I've collected information and the extensions (should) work with any office variant, openoffice and libreoffice. To be more precise, they should work with anything that uses the so-called uno bridge. This is why I like the new category office-plugins best... and would like to implement that one. Is there any chance that there will be more than one or two office-* categories in future? If not, I think that we shouldn't introduce a new category prefix for this. The category should be named app-* instead. How about app-ooo, following the naming of the virtual? Ulrich
Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/05/12 09:06, Andreas K. Huettel wrote:
Am Samstag, 5. Mai 2012, 23:15:46 schrieb Markos Chandras:
On 05/05/2012 08:04 PM, Michał Górny wrote:
On Sat, 5 May 2012 20:40:47 +0200 Andreas K. Huettel
dilfri...@gentoo.org wrote:
there's a growing culture of libreoffice extensions, and (with
the help of an eclass prepared by scarabeus) it would be nice to
get some of them into the portage tree. Now we have to decide
where to put them.
Suggestion: new category office-ext
What do you think?
office-plugins, to follow suit.
This may be confusing as people would expect these plugins to work
with both {open,libre}office packages. If these plugins are just for
libreoffice then I would prefer app-libreoffice like other people have
already suggested
I've collected information and the extensions (should) work with any office
variant, openoffice and libreoffice. To be more precise, they should work
with
anything that uses the so-called uno bridge.
This is why I like the new category office-plugins best... and would like
to
implement that one.
Any additional objections?
I prefer app-plugins even if it is broader.
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+myw0ACgkQ6Ex4woTpDjTVJwCfZjNrwt9WXj6JlELPLwF60kj2
wl4An3EM5GaEvUTsVRbTlVIP+puoQz35
=nn8m
-END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
Am Samstag 05 Mai 2012, 20:54:09 schrieb Andreas K. Huettel:
Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
# @ECLASS-VARIABLE: CMAKE_VERBOSE
# @DESCRIPTION:
# Set to enable verbose messages during compilation.
By default this is deactivated which is inconvenient imo and results in
pastes having minimum information.
I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
that I have proper information on what is going on.
Are there any arguments against this being default?
I think the resistance against this more has to do with the output being
more esthetically pleasing (yes I know this is not really a good point for
us, but in general the cmake output is quite nice) than with writing to
stdout is expensive (which was a joke in the previous thread).
That being said, it probably makes sense to change the default to =1, as it
definitely helps debugging to see the build commands.
I've taken the liberty to change the default in the kde overlay. We'll likely
move this to the main tree with other changes after some testing. Semantics
needed to change a bit; the description now reads:
# @ECLASS-VARIABLE: CMAKE_VERBOSE
# @DESCRIPTION:
# Set to OFF to disable verbose messages during compilation
: ${CMAKE_VERBOSE:=ON}
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
If you `vim foo.ebuild` the default template will automatically include
lines for DEPEND and RDEPEND, but not for RESTRICT
Therefore I suggest we move this example a bit down in skel.ebuild as
it's more logical to continue with new lines instead of applying in-between
Any objections?
--- skel.ebuild 2012-01-20 18:18:14.692033044 +0200
+++ /tmp/skel.ebuild 2012-05-07 00:45:01.871648515 +0300
@@ -85,11 +85,6 @@
# use any USE flags, set to .
IUSE=gnome X
-# A space delimited list of portage features to restrict. man 5 ebuild
-# for details. Usually not needed.
-#RESTRICT=strip
-
-
# Build-time dependencies, such as
#ssl? ( =dev-libs/openssl-0.9.6b )
#=dev-lang/perl-5.6.1-r1
@@ -103,6 +98,11 @@
# The below is valid if the same run-time depends are required to compile.
RDEPEND=${DEPEND}
+# A space delimited list of portage features to restrict. man 5 ebuild
+# for details. Usually not needed.
+#RESTRICT=strip
+
+
# Source directory; the dir where the sources can be found (automatically
# unpacked) inside ${WORKDIR}. The default value for S is ${WORKDIR}/${P}
# If you don't need to change it, leave the S= line out of the ebuild
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
I prefer it right after IUSE which is where it currently is in skel.ebuild.
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On Mon, 07 May 2012, Samuli Suominen wrote: If you `vim foo.ebuild` the default template will automatically include lines for DEPEND and RDEPEND, but not for RESTRICT Are we now using behaviour of editors as a reference? With Emacs or XEmacs, the template includes RESTRICT and places it before DEPEND and RDEPEND. Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Ulrich
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On 05/07/2012 01:27 AM, Ulrich Mueller wrote: On Mon, 07 May 2012, Samuli Suominen wrote: If you `vim foo.ebuild` the default template will automatically include lines for DEPEND and RDEPEND, but not for RESTRICT Are we now using behaviour of editors as a reference? With Emacs or XEmacs, the template includes RESTRICT and places it before DEPEND and RDEPEND. I would rather see RESTRICT dropped from the template included for emacs, because it's not expected for majority of ebuilds to have need for it (a fact). The template for emacs should be kept in sync with the example for vim (or whichever way around). Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Yeah, I will if someone has a (good) argument for doing so.
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On Mon, 07 May 2012, Samuli Suominen wrote: On 05/07/2012 01:27 AM, Ulrich Mueller wrote: Are we now using behaviour of editors as a reference? With Emacs or XEmacs, the template includes RESTRICT and places it before DEPEND and RDEPEND. I would rather see RESTRICT dropped from the template included for emacs, because it's not expected for majority of ebuilds to have need for it (a fact). So what? Then you just leave the variable empty. The template (or rather skeleton in Emacs' terms) knows that the RESTRICT variable is optional and will automatically remove the line. The template for emacs should be kept in sync with the example for vim (or whichever way around). The skeleton for Emacs is kept in sync with skel.ebuild and the devmanual, of course. I don't use vim and therefore I don't know what its template does. Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Yeah, I will if someone has a (good) argument for doing so. RESTRICT and PROPERTIES are on a single line and it's natural to add them to the second group of such variables, namely LICENSE, SLOT, KEYWORDS, and IUSE. Whereas DEPEND and RDEPEND typically extend over several lines; sometimes they are quite long. So, a RESTRICT line placed after *DEPEND will be much more easily missed than in its current place. Ulrich
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
Am Montag 07 Mai 2012, 01:24:39 schrieb Ulrich Mueller: On Mon, 07 May 2012, Samuli Suominen wrote: On 05/07/2012 01:27 AM, Ulrich Mueller wrote: Are we now using behaviour of editors as a reference? With Emacs or XEmacs, the template includes RESTRICT and places it before DEPEND and RDEPEND. I would rather see RESTRICT dropped from the template included for emacs, because it's not expected for majority of ebuilds to have need for it (a fact). So what? Then you just leave the variable empty. The template (or rather skeleton in Emacs' terms) knows that the RESTRICT variable is optional and will automatically remove the line. The template for emacs should be kept in sync with the example for vim (or whichever way around). The skeleton for Emacs is kept in sync with skel.ebuild and the devmanual, of course. I don't use vim and therefore I don't know what its template does. Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Yeah, I will if someone has a (good) argument for doing so. RESTRICT and PROPERTIES are on a single line and it's natural to add them to the second group of such variables, namely LICENSE, SLOT, KEYWORDS, and IUSE. Whereas DEPEND and RDEPEND typically extend over several lines; sometimes they are quite long. So, a RESTRICT line placed after *DEPEND will be much more easily missed than in its current place. This entire ridiculous discussion just makes me convinced that it's best to * use neither vi nor emacs * and stick to my own personal preference of variable order, which is not identical to either. Eat this! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-05-06 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-05-06 23h59 UTC. Removals: x11-themes/qgtkstyle2012-04-30 14:27:28 pesa media-libs/tunepimp 2012-05-01 10:04:54 johu x11-drivers/xf86-input-virtualbox 2012-05-02 10:17:35 polynomial-c media-plugins/vdr-vdrmanager2012-05-03 16:09:33 jer dev-php/Horde_ActiveSync2012-05-03 18:24:33 a3li dev-php/Horde_Alarm 2012-05-03 18:24:34 a3li dev-php/Horde_Argv 2012-05-03 18:24:34 a3li dev-php/Horde_Auth 2012-05-03 18:24:34 a3li dev-php/Horde_Autoloader2012-05-03 18:24:34 a3li dev-php/Horde_Browser 2012-05-03 18:24:34 a3li dev-php/Horde_Cache 2012-05-03 18:24:34 a3li dev-php/Horde_Cli 2012-05-03 18:24:35 a3li dev-php/Horde_Compress 2012-05-03 18:24:35 a3li dev-php/Horde_Constraint2012-05-03 18:24:35 a3li dev-php/Horde_Controller2012-05-03 18:24:35 a3li dev-php/Horde_Core 2012-05-03 18:24:35 a3li dev-php/Horde_Crypt 2012-05-03 18:24:35 a3li dev-php/Horde_Data 2012-05-03 18:24:36 a3li dev-php/Horde_DataTree 2012-05-03 18:24:36 a3li dev-php/Horde_Date 2012-05-03 18:24:36 a3li dev-php/Horde_Date_Parser 2012-05-03 18:24:36 a3li dev-php/Horde_Db2012-05-03 18:24:36 a3li dev-php/Horde_Exception 2012-05-03 18:24:36 a3li dev-php/Horde_Feed 2012-05-03 18:24:36 a3li dev-php/Horde_Form 2012-05-03 18:24:37 a3li dev-php/Horde_Group 2012-05-03 18:24:37 a3li dev-php/Horde_History 2012-05-03 18:24:37 a3li dev-php/Horde_Http 2012-05-03 18:24:37 a3li dev-php/Horde_Icalendar 2012-05-03 18:24:37 a3li dev-php/Horde_Image 2012-05-03 18:24:37 a3li dev-php/Horde_Imap_Client 2012-05-03 18:24:38 a3li dev-php/Horde_Imsp 2012-05-03 18:24:38 a3li dev-php/Horde_Injector 2012-05-03 18:24:38 a3li dev-php/Horde_Itip 2012-05-03 18:24:38 a3li dev-php/Horde_Kolab_Format 2012-05-03 18:24:38 a3li dev-php/Horde_Kolab_Server 2012-05-03 18:24:39 a3li dev-php/Horde_Kolab_Session 2012-05-03 18:24:39 a3li dev-php/Horde_Kolab_Storage 2012-05-03 18:24:40 a3li dev-php/Horde_Ldap 2012-05-03 18:24:40 a3li dev-php/Horde_Lock 2012-05-03 18:24:40 a3li dev-php/Horde_Log 2012-05-03 18:24:40 a3li dev-php/Horde_LoginTasks2012-05-03 18:24:40 a3li dev-php/Horde_Mail 2012-05-03 18:24:41 a3li dev-php/Horde_Memcache 2012-05-03 18:24:41 a3li dev-php/Horde_Mime 2012-05-03 18:24:41 a3li dev-php/Horde_Mime_Viewer 2012-05-03 18:24:41 a3li dev-php/Horde_Nls 2012-05-03 18:24:42 a3li dev-php/Horde_Notification 2012-05-03 18:24:42 a3li dev-php/Horde_Oauth 2012-05-03 18:24:42 a3li dev-php/Horde_Pdf 2012-05-03 18:24:42 a3li dev-php/Horde_Perms 2012-05-03 18:24:43 a3li dev-php/Horde_Prefs 2012-05-03 18:24:43 a3li dev-php/Horde_Rdo 2012-05-03 18:24:43 a3li dev-php/Horde_Role 2012-05-03 18:24:43 a3li dev-php/Horde_Routes2012-05-03 18:24:43 a3li dev-php/Horde_Rpc 2012-05-03 18:24:43 a3li dev-php/Horde_Scribe2012-05-03 18:24:43 a3li dev-php/Horde_Secret2012-05-03 18:24:44 a3li dev-php/Horde_Serialize 2012-05-03 18:24:44 a3li dev-php/Horde_Service_Facebook 2012-05-03 18:24:44 a3li dev-php/Horde_Service_Twitter 2012-05-03 18:24:45 a3li dev-php/Horde_SessionHandler2012-05-03 18:24:45 a3li dev-php/Horde_Share 2012-05-03 18:24:45 a3li dev-php/Horde_SpellChecker 2012-05-03 18:24:45 a3li dev-php/Horde_Sql 2012-05-03 18:24:45 a3li dev-php/Horde_Stream_Filter 2012-05-03 18:24:45 a3li dev-php/Horde_Stream_Wrapper2012-05-03 18:24:45 a3li dev-php/Horde_Support 2012-05-03 18:24:45 a3li dev-php/Horde_SyncMl2012-05-03 18:24:45 a3li dev-php/Horde_Template 2012-05-03 18:24:46 a3li dev-php/Horde_Test
Re: [gentoo-dev] add global useflag: webkit
2012-05-06 02:34:26 hasufell napisał(a): # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] add global useflag: webkit
On 05/07/2012 02:47 AM, Arfrever Frehtes Taifersar Arahesis wrote: 2012-05-06 02:34:26 hasufell napisał(a): # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. You mean that for example KDE users who set +webkit in make.conf would possibly get some weird gtk-deps too?
Re: [gentoo-dev] add global useflag: webkit
2012-05-07 03:00:31 hasufell napisał(a): On 05/07/2012 02:47 AM, Arfrever Frehtes Taifersar Arahesis wrote: 2012-05-06 02:34:26 hasufell napisał(a): # grep :webkit use.local.desc | wc -l 33 I would vote to make this a global useflag: webkit - Adds support for the webkit library/module I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. You mean that for example KDE users who set +webkit in make.conf would possibly get some weird gtk-deps too? 16 packages have webkit USE flag, which enables dependency on net-libs/webkit-gtk: app-misc/gramps app-office/gnucash app-pda/gtkpod app-text/xiphos dev-java/swt dev-util/geany-plugins dev-util/mono-tools gnome-extra/avant-window-navigator-extras gnome-extra/zenity mail-client/balsa media-gfx/gimp media-sound/gmusicbrowser media-sound/gpodder media-sound/rhythmbox net-im/empathy x11-misc/google-gadgets 15 packages have webkit USE flag, which enables dependency on x11-libs/qt-webkit: dev-python/PyQt4 dev-python/pyside kde-base/kget kde-base/perlqt kde-base/qtruby kde-base/qyoto kde-base/smokeqt net-im/psi net-im/qutim net-irc/quassel sci-chemistry/ball sci-geosciences/merkaartor x11-libs/qt-assistant x11-libs/qt-declarative x11-libs/qt-demo -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] add global useflag: webkit
On 7 May 2012 08:47, Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags. I don't think that is necessary. Ben | yngwin
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On Sunday 06 May 2012 17:56:41 Michael Sterrett wrote: I prefer it right after IUSE which is where it currently is in skel.ebuild. this -mike signature.asc Description: This is a digitally signed message part.
