Re: [gentoo-dev] Gentoo Council 14/7 introductory meeting
On 07/12/2010 10:18 PM, Paweł Hajdan, Jr. wrote: Rationale: Meeting summary for 20091012 is to be completed. Meeting summary for 20100419 is also to be completed, and all following council meetings lack summaries. This makes it hard to follow the council's work. I've seen this at work quite a bit. I've also seen an elegant solution that works moderately well. The minutes of the meeting are taken in realtime during the meeting by whoever will take it, and this is shared with the participants in realtime. This way errors in the minutes are instantly corrected. When the meeting is done you just save and publish the minutes and you are done. Realtime collaboration could involve any number of mechanisms. I don't know if google docs supports it, but I imagine Wave would. There might be other mechanisms as well. Webex/GotoMeeting/etc are usually the methods employed in the business world. There might be an FOSS equivalent. I think this should be purely up to the council's discretion, but I wanted to offer this as a suggestion. I'm not a fan of slacker marks in the first place - but, if you have to have them then I'd do it in a way so as to avoid creating a negative incentive for volunteering to do the work in the first place. Rich
Re: [gentoo-dev] 'State of Gentoo' BoF session, Linux Symposium 2010.
Wonderful, thank you. Robert Am 12.07.2010 um 02:04 schrieb Robin H. Johnson robb...@gentoo.org: On Sun, Jul 11, 2010 at 01:30:08AM -0400, Jacob Godserv wrote: I've had my own uneducated ideas about this exact topic. I'd love to hear more about this. Will notes or a recording be posted anywhere? I'm uncertain if there is going to be any official (FOSDEM-like) recording of the BoF sessions, but I'll put up whatever slides and notes I make. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Gentoo Council 14/7 introductory meeting
Hi, Am Dienstag, den 13.07.2010, 13:06 -0400 schrieb Richard Freeman: I've seen this at work quite a bit. I've also seen an elegant solution that works moderately well. The minutes of the meeting are taken in realtime during the meeting by whoever will take it, and this is shared with the participants in realtime. This way errors in the minutes are instantly corrected. When the meeting is done you just save and publish the minutes and you are done. Realtime collaboration could involve any number of mechanisms. I don't know if google docs supports it, but I imagine Wave would. There might be other mechanisms as well. Webex/GotoMeeting/etc are usually the methods employed in the business world. There might be an FOSS equivalent. Take a look at app-editors/gobby :) - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
[gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 commit in sci-as tronomy/kapteyn: metadata.xml ChangeLog kapteyn-1 .9.2.ebuild)
On Tue, 13 Jul 2010 19:25:51 + (UTC), Kacper Kowalik (xarthisius)
xarthis...@gentoo.org wrote:
if use doc; then
insinto /usr/share/doc/${PF}
doins doc/*.pdf || die
An open question to all:
Should we be hiding pdf's behind USE=doc?? I've seen it here and there
as of late. I thought USE=doc was for compiling docs and/or pulling in
extra deps to build docs.
Thanks,
Jeremy
Re: [gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 commit in sci-astronomy/kapteyn: metadata.xml ChangeLog kapteyn-1.9.2.ebuild)
On 7/13/10 12:32 PM, Jeremy Olexa wrote:
On Tue, 13 Jul 2010 19:25:51 + (UTC), Kacper Kowalik (xarthisius)
xarthis...@gentoo.org wrote:
if use doc; then
insinto /usr/share/doc/${PF}
doins doc/*.pdf || die
An open question to all:
Should we be hiding pdf's behind USE=doc?? I've seen it here and there
as of late. I thought USE=doc was for compiling docs and/or pulling in
extra deps to build docs.
In my opinion we're never going to have 100% consistency here. I'd say
let everybody implement it in a way one thinks is the best.
The description of the flag is Adds extra documentation (API, Javadoc,
etc). So if something is an extra documentation, it seems to be fine to
hide it behind USE=doc.
And I'd prefer to keep the meaning of extra documentation flexible and
open to interpretation, just because there is no obvious benefit to aim
for 100% consistency here, and overstandardization would be bad.
Paweł
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 commit in sci-astronomy/kapteyn: metadata.xml ChangeLog kapteyn-1.9.2.ebuild)
On 07/13/2010 01:32 PM, Jeremy Olexa wrote:
On Tue, 13 Jul 2010 19:25:51 + (UTC), Kacper Kowalik (xarthisius)
xarthis...@gentoo.org wrote:
if use doc; then
insinto /usr/share/doc/${PF}
doins doc/*.pdf || die
An open question to all:
Should we be hiding pdf's behind USE=doc?? I've seen it here and there
as of late. I thought USE=doc was for compiling docs and/or pulling in
extra deps to build docs.
I've seen it used sometimes where the docs themselves are really large,
and/or require a separate SRC_URI download as well.
But yah, makes most sense when you need it to change build deps and
actually do something.
Steve
Re: [gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 com mit in sci-astronomy/kapteyn: metadata.xml ChangeLo g kapteyn-1.9.2.ebuild)
On Tue, 13 Jul 2010 12:43:17 -0700, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
On 7/13/10 12:32 PM, Jeremy Olexa wrote:
On Tue, 13 Jul 2010 19:25:51 + (UTC), Kacper Kowalik (xarthisius)
xarthis...@gentoo.org wrote:
if use doc; then
insinto /usr/share/doc/${PF}
doins doc/*.pdf || die
An open question to all:
Should we be hiding pdf's behind USE=doc?? I've seen it here and there
as of late. I thought USE=doc was for compiling docs and/or pulling in
extra deps to build docs.
In my opinion we're never going to have 100% consistency here. I'd say
let everybody implement it in a way one thinks is the best.
I will highly disagree with this statement. If *WE* are not consistent,
how do the users of the distro know what to expect? Why does this USE
flag have a different standard then the rest?
The description of the flag is Adds extra documentation (API, Javadoc,
etc). So if something is an extra documentation, it seems to be fine to
hide it behind USE=doc.
And I'd prefer to keep the meaning of extra documentation flexible and
open to interpretation, just because there is no obvious benefit to aim
for 100% consistency here, and overstandardization would be bad.
No obvious benefit besides being consistent to our userbase. Do our
users expect non-consistent USE flags? That sounds bad to me. Sadly, I
think this is a subject that we will never get a consensus on. Maybe
the
description should be changed to:
global:doc: Adds extra documentation (API, Javadoc, PDFs at
maintainer's discretion, etc)
-Jeremy
Re: [gentoo-dev] USE=doc for .pdf's ? (WAS: Re: [gentoo-commits] gentoo-x86 commit in sci-astronomy/kapteyn: metadata.xml ChangeLog kapteyn-1.9.2.ebuild)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 13.07.2010 22:04, Jeremy Olexa pisze: global:doc: Adds extra documentation (API, Javadoc, PDFs at maintainer's discretion, etc) I think you missed API here. I don't really see the difference between bunch of html files and one 8Mb pdf file. In most cases the former are not build either, yet they are doc flag dependent. Cheers, Kacper Kowalik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAkw8zPYACgkQIiMqcbOVdxTQogP+Ki4Ik61GfT0zsRJ/bKN86pnR PGQehSEapEoyG0qcUUbc4kXKqYxsO6oyVpTMNTZq3vCLPyALjM3/oOlcP9/Rh3Lh t6iw7jgA29iz+pF204WZ4ACPG+74libf0hZf6Gw2npgMA6MWPRSpRmAv8rBIoOrZ nS4FZFtmOxyaOhmnyAI= =ro1B -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Wednesday 07 of July 2010 02:16:13 Maciej Mrozowski wrote:
On Thursday 03 of June 2010 01:32:09 Nathan Phillip Brink wrote:
On Mon, May 31, 2010 at 03:29:01PM +0200, Maciej Mrozowski wrote:
On Wednesday 26 of May 2010 19:27:43 Mike Frysinger wrote:
On Wednesday 26 May 2010 05:38:00 Maciej Mrozowski wrote:
I've updated documentation, added example usage and option to keep
libtool files (ltdl.so supposedly needs those as I was told, no
idea what for).
IMO, ltdl.so is probably just being silly. Perhaps these files contain
information that is useful on non-Linux systems for dlopen()ing
plugins.
more applicable to us w/Linux is that static linking with libtool
needs them. the AUTOTOOLS_KEEP_LA_FILES seems kind of spurious
considering current tree behavior and assumption of gnu-capable
linking systems.
It is spurious when we forget about run-time dynamic linking (plugins)
in some apps.
libtool loader (ltdl.so) needs .la files unfortunately. One example -
imagemagick - removing .la files for coders makes 'convert' unable to
locate them (silly, but hey...).
This case can be caught by checking if the .la file has the following in
it: ``
# Should we warn about portability when linking against -modules?
shouldnotlink=yes
''
Excellent. Eclass updated, see attachment. AUTOTOOLS_KEEP_LA_FILES option
removed. Now removing .la files relies only on shouldnotlink value (and
static-libs presence in IUSE that is).
Removing .la files which are useless on a given system would be very
nice. It would be even more useful if unused .a files could be swept
away at the same time :-).
They are - just add static-libs to IUSE and disable said USE flag when
emerging.
I've also had an idea to be smarter and to look for patches (PATCHES array)
updating any .m4, Makefile.{ac,in}, configure.{ac.in} files and to run
eautoreconf automatically in ${eclass}_src_prepare but I've decided it's a
bit too much. I may rethink the idea later though.
If there are no objections nor further comments, I'd like to unleash new
eclass for public consumption within a few days.
Before I do so, please comment on the following changes I've made:
- always pass --disable-dependency-tracking
- always remove static libs corresponding to plugins (based on
shouldnotlink=yes)
- add remove_libtool_files [all|none] function
- add some low-profile echo messages showing removed files
- append myeconfargs at the end of econfargs so that eclass defaults can be
overriden at request
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=history;f=eclass/autotools-
utils.eclass
If there are no further issues, I'll commit it to tree (with announcement)
within three or more days.
--
regards
MM
