[gentoo-dev] Beware of the portage cache!
Hi all. Just a quick reminder that you can only rely on static things in most top-level variables in ebuilds. See http://devmanual.gentoo.org/general-concepts/portage-cache/index.html for details. For a real world example on how to break the cache see http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/xmltv/ (every version = 0.5.39 relies on XMLTV_OPTS from the environment). The issue is fixed in newer versions and there should already be a bug to stable those newer versions and get rid of the broken versions. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
On Wednesday 12 July 2006 15:16, Danny van Dyk wrote: Hi all, thanks to djm's efforts i was just able to scan the whole tree using qualudis. For a start, i'll attach a list of QA violations on missing entries in IUSE. As this is a minor change to the ebuilds, I'll go on and fix all the listed ebuilds myself. There are 505 ebuilds which are missing use flags in IUSE that they use in other places. While reading your list I have seen pcmcia often. e.g. on my ebuild v4l-dvb-hg not supporting pcmcia as conditional. A bit digging showed that linux-mod.eclass contains this code: --cut-- IUSE= # don't put pcmcia here, rather in the ebuilds that actually support pcmcia SLOT=0 DESCRIPTION=Based on the $ECLASS eclass RDEPEND=kernel_linux? ( virtual/modutils pcmcia? ( virtual/pcmcia ) ) --cut-- I don't know if pcmcia should then be added to every ebuild including linux-mod.eclass. Please solve this before adding pcmcia on every kernel-module-ebuild. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpdqMJ1OoKWx.pgp Description: PGP signature
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Danny van Dyk wrote: Hi all, thanks to djm's efforts i was just able to scan the whole tree using qualudis. For a start, i'll attach a list of QA violations on missing entries in IUSE. As this is a minor change to the ebuilds, I'll go on and fix all the listed ebuilds myself. There are 505 ebuilds which are missing use flags in IUSE that they use in other places. Danny Wrt the pcmcia thing, well not really ebuilds' fault, see http://bugs.gentoo.org/show_bug.cgi?id=122868 There are already bugs filed for some of the rest, please go fix them ;) http://tinyurl.com/glq4m http://bugs.gentoo.org/show_bug.cgi?id=136953 The arch stuff (x86, amd64...) - well I don't really think they should be in IUSE. Here's a log for the rest, without the arch flags: http://dev.gentoo.org/~jakub/reports/20061712/unstated_flags.log -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Am Mittwoch, 12. Juli 2006 15:23 schrieb Matthias Schwarzott: On Wednesday 12 July 2006 15:16, Danny van Dyk wrote: Hi all, While reading your list I have seen pcmcia often. e.g. on my ebuild v4l-dvb-hg not supporting pcmcia as conditional. A bit digging showed that linux-mod.eclass contains this code: --cut-- IUSE= # don't put pcmcia here, rather in the ebuilds that actually support pcmcia SLOT=0 DESCRIPTION=Based on the $ECLASS eclass RDEPEND=kernel_linux? ( virtual/modutils pcmcia? ( virtual/pcmcia ) ) --cut-- I don't know if pcmcia should then be added to every ebuild including linux-mod.eclass. Please solve this before adding pcmcia on every kernel-module-ebuild. I've ceased adding pcmcia to IUSE after 3 commits. genstef will be talking with kernel team about this. I'd suggest to split the pcmcia dep to a different eclass, but that's just my opinion. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] xpdf status
Guys, The xpdf version we have currently in the tree is a modified one that links to poppler, provided in IRC to genstef by an ubuntu developer (no, ubuntu does not use it); now, I can understand that having a single point of failure is desiderable, but I completely disagree when doing this implies using a thirdy-party version not maintained/hosted anywhere (the reasons being obvious, I hope). Besides, it's improbable that upstream will add support for poppler in xpdf. I really would like to see back the upstream version, what do you think? -- Emanuele -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Danny van Dyk wrote: [Wed Jul 12 2006, 09:16:30AM EDT]
There are 505 ebuilds which are missing use flags in IUSE that they use
in other places.
I once wrote a script (attached) to update IUSE automatically. To use
it, simply:
$ cd games-emulation/xmess
$ fixiuse
It reports what it changed, and give you a resulting repoman commit
line which you can cut-and-paste.
Aron
#!/usr/bin/ruby -w
#
# fixiuse: update IUSE based on apparent usage in ebuild(s)
#
PORTDIR = %x{portageq envvar PORTDIR}.strip
ARCHLIST = IO.read(PORTDIR + '/profiles/arch.list').split(/\s+/)
$added = []
$removed = []
class Regexp
def +(rxp)
Regexp.new(self.to_s + rxp.to_s)
end
end
class Efile
attr_reader :inherits
FLAG = /[']?!?(\w[-\w+.]*)[']?/ # regex to match a USE-flag and put it in
$1
def initialize(filename)
@filename = filename
@old_iuse = nil
@new_iuse = nil
@inherits = []
if File.exists?(@filename)
@e = IO.read(@filename)
else
@e = IO.read(PORTDIR + /eclass/ + @filename + .eclass)
end
end
def inherits?(name)
name == @filename.sub(/\.eclass$/, '') or @inherits.index(name)
end
def write
# Short-circuit if there's nothing to do
return if @new_iuse == @old_iuse
# Remove the existing IUSE and remember the location
iuse_location = @e.index(/^IUSE=/)
@e.gsub!(/\bIUSE=(?:$|([']).*?\1)/m, )
# Insert at remembered location or just after KEYWORDS
if iuse_location.nil?
iuse_location = @e.index(/^KEYWORDS.*\n/) || @e.index(/\n\n/)
iuse_location += $.length
@e.insert(iuse_location, \n)
end
@e.insert(iuse_location, %Q(IUSE=[EMAIL PROTECTED] ' '}))
# Rewrite file
File.open(@filename, w) { |ios| ios.puts @e }
# Announce what we did
a = @new_iuse - @old_iuse
r = @old_iuse - @new_iuse
puts # [EMAIL PROTECTED]
if a.size != 0
puts + Added #{a.join ' '}
puts + * 70
a.each do |x|
system(fgrep, --color=always, -C2, x, @filename)
puts '--'
end
end
if r.size != 0
puts - Removed #{r.join ' '}
puts - * 70
(r + ['$IUSE', '${IUSE}']).each do |x|
system(fgrep, --color=always, -C2, x, @filename)
puts '--'
end
end
puts
# Add to the global accumulators
$added |= a
$removed |= r
end
def scan
# Collect the USE variables from inherited eclasses
inherited_iuse = []
@e.scan(/^inherit\s.*/).each do |line|
line.sub(/#.*/, ).split.each do |name|
next if self.inherits?(name)
@inherits name
eclass = Efile.new(name)
inherited_iuse eclass.scan
@inherits eclass.inherits
end
end
# Collect the content of the old IUSE
if @e =~ %r{^IUSE=.(.*?)[']}m
@old_iuse = $1.split.sort
else
@old_iuse = []
end
# Strip false matches to create e_nc (no comments)
e_nc = @e.gsub(/#.*/, )
e_nc.gsub!(/\b(?:echo|einfo|ewarn|eerror|ebegin|die)\b.*/, )
e_nc.gsub!(/^DESCRIPTION=([']).*?\1[^\n]*/m, )
# Find candidates for IUSE
@new_iuse = e_nc.scan(/\b(?:use_enable|use_with|use[qv]?)\s+/ +
FLAG).flatten
e_nc.scan(/(?:\bSRC_URI|\b[RP]?DEPEND)=.(.*?)[']/m).flatten.each do |dep|
@new_iuse += dep.scan(FLAG + /(?=\?)/).flatten
end
@new_iuse 'boundschecking' if e_nc =~ /\bwant_boundschecking\b/
@new_iuse 'nopie' if e_nc =~ /\bwant_pie\b/
@new_iuse 'nossp' if e_nc =~ /\bwant_ssp\b/
# Special treatment for ebuilds that inherit particular eclasses
if self.inherits? 'confutils'
@new_iuse += e_nc.scan(%r{\b
(?: confutils_use_conflict | confutils_use_depend_all |
confutils_use_depend_any )
}x + ('(?:\s+' + FLAG.to_s + ')+')).flatten
@new_iuse += e_nc.scan(%r{\b
(?: enable_extension_enable | enable_extension_disable |
enable_extension_enableonly |
enable_extension_without | enable_with | enable_withonly )
\s+}x + FLAG).flatten
end
if self.inherits? 'mozconfig'
@new_iuse += e_nc.scan(/\bmozconfig_use_(?:enable|with|extension)\s+/ +
FLAG).flatten
end
if self.inherits? 'x11'
@new_iuse += e_nc.scan(/\buse_build\s+/ + FLAG).flatten
end
# Special treatment for some ebuilds...
case @filename
when /^wine-/
@new_iuse += e_nc.scan(/\bconfig_cache\s+/ + FLAG).flatten
when /^qt-\d/
@new_iuse += e_nc.scan(/\bqt_use\s+/ + FLAG).flatten
when /^ezm3-\d/
@new_iuse += e_nc.scan(/\bseduse\s+/ + FLAG).flatten
when /^xmess-\d/
@new_iuse += e_nc.scan(/\btoggle_feature2?\s+/ + FLAG).flatten
@new_iuse += e_nc.scan(/\btoggle_feature2\s+\S+\s+/ + FLAG).flatten
end
# Clean up
@new_iuse -= [ 'the' ] # common false matches
@new_iuse -= ARCHLIST
@new_iuse.reject! { |x| x =~
/^kernel_|^elibc_|^linguas_|^video_cards_|^input_devices_/ }
(@old_iuse - @new_iuse).each do |u|
# don't remove items from IUSE that are in an
Re: [gentoo-dev] xpdf status
On Wednesday 12 July 2006 16:43, [EMAIL PROTECTED] wrote: Guys, The xpdf version we have currently in the tree is a modified one that links to poppler, provided in IRC to genstef by an ubuntu developer (no, ubuntu does not use it); now, I can understand that having a single point of failure is desiderable, but I completely disagree when doing this implies using a thirdy-party version not maintained/hosted anywhere (the reasons being obvious, I hope). Besides, it's improbable that upstream will add support for poppler in xpdf. I really would like to see back the upstream version, what do you think? The reason for this was security I believe. xpdf code is embedded in lots of other packages (see http://glsa.gentoo.org for some examples). By linking to poppler this is fixed in one place. Though if someone is willing to maintain a vanilla xpdf ebuild I'd have no complaints. Genstef? -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team pgpWmc3mu6JfD.pgp Description: PGP signature
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
On Wed, 12 Jul 2006 15:23:06 +0200 Matthias Schwarzott [EMAIL PROTECTED] wrote: | IUSE= # don't put pcmcia here, rather in the ebuilds that actually | support pcmcia That's not legit. An eclass should list all USE flags that it itself uses. Similarly, an ebuild should list all USE flags that it itself uses, and *not* any that're only used by an eclass it inherits. The solution here is probably to make an I_WANT_PCMCIA variable or somesuch. So long as it's statically defined before the inherit, it's not a cache violation (eclasses are evaluated per-ebuild). -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: xpdf status
Sune Kloppenborg Jeppesen wrote: On Wednesday 12 July 2006 16:43, [EMAIL PROTECTED] wrote: I really would like to see back the upstream version, what do you think? The reason for this was security I believe. xpdf code is embedded in lots of other packages (see http://glsa.gentoo.org for some examples). By linking to poppler this is fixed in one place. Right you are, the reason is security. Though if someone is willing to maintain a vanilla xpdf ebuild I'd have no complaints. Genstef? I have no complaints either. If there is exg doing the security bumps and taking care of the upstream version I am supporting it. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Hi,
This came up in Bug 138792 [dobin etc. should automatically die on failure]
It needs more discussion on the mailing lists.
Some excerpts from the bug: The proposal from Paul Bredbury:
Hi, I propose that the following ebuild commands themselves *die* on
failure, because the vast majority of the time the emerge might as well be
considered a failure if such commands fail.
dobin, dosbin, doexe
Jason Stubbs called for consistency .. i.e making doman and dodoc also die
when nothing the file does not exist. A simple workaround in case an ebuild
is broken: [ -f xxx ] dodoc xxx
SpanKY complained that he cannot set a custom die message then. But this is
not needed here, since every do* command can be clearly identified by the
argument and the directory it will be installed to.
Also as Paul suggested something like that would be possible for a custom
die message:
if [[ -n ${DIE_MSG} ]] ; then
echo !!! ${DIE_MSG}
fi
So, because we want no broken ebuilds and we want consistency I propose to
change this and fix possible problems. They are imo QA problems and should
be fixed.
So what do you think?
- Stefan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xpdf status
Sune Kloppenborg Jeppesen wrote: On Wednesday 12 July 2006 16:43, [EMAIL PROTECTED] wrote: Guys, The xpdf version we have currently in the tree is a modified one that links to poppler, provided in IRC to genstef by an ubuntu developer (no, ubuntu does not use it); now, I can understand that having a single point of failure is desiderable, but I completely disagree when doing this implies using a thirdy-party version not maintained/hosted anywhere (the reasons being obvious, I hope). Besides, it's improbable that upstream will add support for poppler in xpdf. I really would like to see back the upstream version, what do you think? The reason for this was security I believe. xpdf code is embedded in lots of other packages (see http://glsa.gentoo.org for some examples). By linking to poppler this is fixed in one place. That's what I meant with having a single point of failure. While I understand the goal I do not agree with the solution; since when do we prefer to replace an official maintained version of a software with whatever thirdy-party version when this can ease maintenance wrt security? -- Emanuele -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Stefan Schweizer wrote: [Wed Jul 12 2006, 01:37:44PM EDT] This came up in Bug 138792 [dobin etc. should automatically die on failure] Since do* would become functions in this case, you'll have to fix the few ebuilds that use them on the RHS of xargs. grep -r --include \*.ebuild -E 'xargs do(bin|exe|ins|man|doc)' . Assuming the list is relatively short, it should be acceptable to convert these to something like: doman $(find man -name '*.?.gz') The speedtouch ebuild is screwy anyway. There's no reason for the echo. Aron -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xpdf status
[EMAIL PROTECTED] wrote: I really would like to see back the upstream version, what do you think? I don't think anybody would mind you putting them into the tree again. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Am Mittwoch, 12. Juli 2006 17:00 schrieb Aron Griffis: Danny van Dyk wrote: [Wed Jul 12 2006, 09:16:30AM EDT] There are 505 ebuilds which are missing use flags in IUSE that they use in other places. Much of those 505 violations are a missing pcmcia flag, which i stopped to fix once i was notified of pending linux-mod.eclass bug. I once wrote a script (attached) to update IUSE automatically. To use it, simply: $ cd games-emulation/xmess $ fixiuse It reports what it changed, and give you a resulting repoman commit line which you can cut-and-paste. Thanks very much, but all violations have already been fixed :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Tuesday 13 June 2006 01:00, Stephen Bennett wrote: My current idea is to draw up a formal specification of what ebuilds are allowed to do, and what to assume about the environment in which they run, as well as defining the formats of everything under profiles/, metadata.xml files, and other auxiliary information in the tree. I would envision the first version of this document to more or less codify existing practise, perhaps excluding some dubious tricks that are known to break in some cases. Generally, it should be possible to make the tree conform to the first version of the specification by changes no more significant than currently have QA bugs filed for them. Metadata.xml files are already formally defined in http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4 You are welcome to extend/copy this information. Otherwise, go ahead. I don't see problems with codifying what ebuilds are allowed and not allowed to do. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplaZ0b2veb4.pgp Description: PGP signature
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
Am Mittwoch, 12. Juli 2006 15:36 schrieb Jakub Moc: Danny van Dyk wrote: Wrt the pcmcia thing, well not really ebuilds' fault, see http://bugs.gentoo.org/show_bug.cgi?id=122868 Yeah, genstef is working on it. There are already bugs filed for some of the rest, please go fix them ;) http://tinyurl.com/glq4m going to. http://bugs.gentoo.org/show_bug.cgi?id=136953 The arch stuff (x86, amd64...) - well I don't really think they should be in IUSE. Here's a log for the rest, without the arch flags: Nobody talked about adding those to IUSE. The log says that usage of '!arch' _maybe_ a QA problem. QA people need to check those manually. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making dobin, doexe, doins, doman, dodoc die by default
Aron Griffis wrote:
Stefan Schweizer wrote: [Wed Jul 12 2006, 01:37:44PM EDT]
This came up in Bug 138792 [dobin etc. should automatically die on
failure]
Since do* would become functions in this case, you'll have to fix the
few ebuilds that use them on the RHS of xargs.
grep -r --include \*.ebuild -E 'xargs do(bin|exe|ins|man|doc)' .
./local/layman/hanno-xgl/media-libs/mesa/mesa-6.5.1_pre20060620.ebuild: find
${S}/lib* -name '*_dri.so' | xargs doexe
./local/layman/hanno-xgl/media-libs/mesa/mesa-6.5.1_pre20060627.ebuild: find
${S}/lib* -name '*_dri.so' | xargs doexe
./media-libs/mesa/mesa-6.5-r3.ebuild: find ${S}/lib* -name '*_dri.so' |
xargs doexe
./media-libs/mesa/mesa-6.4.2-r2.ebuild: find ${S}/lib* -name '*_dri.so' |
xargs doexe
./app-emulation/vmware-gsx-console/vmware-gsx-console-3.2.0.14497.ebuild:
find man -name \*.\?.gz | xargs doman
Assuming the list is relatively short, it should be acceptable to
convert these to something like:
doman $(find man -name '*.?.gz')
I just pinged MattM about vmware-gsx-console, and the x11 guys about mesa
and some minutes ago fixed timidity-eawpatches and speedtouch.
Thanks :)
- Stefan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Stefan Schweizer wrote: Jason Stubbs called for consistency .. i.e making doman and dodoc also die when nothing the file does not exist. A simple workaround in case an ebuild is broken: [ -f xxx ] dodoc xxx Uh... Sorry but it's pretty hard to imagine something more annoying than an ebuild that dies after a couple of hours compile just because upstream decided to rename Changelog.txt to ChangeLog.txt and noone noticed during version bump, or because someone made a typo there. Fail to see any benefit from this... :S Ditto for manpages. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wed, Jul 12, 2006 at 11:11:01PM +0200, Jakub Moc wrote: Uh... Sorry but it's pretty hard to imagine something more annoying than an ebuild that dies after a couple of hours compile just because upstream decided to rename Changelog.txt to ChangeLog.txt and noone noticed during version bump, or because someone made a typo there. Fail to see any benefit from this... :S Ditto for manpages. How could that slip through the initial testing of the ebuild performed by the developer doing the version bump? ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp9owhC39iqQ.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wed, 12 Jul 2006 23:11:01 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Stefan Schweizer wrote: | Jason Stubbs called for consistency .. i.e making doman and dodoc | also die when nothing the file does not exist. A simple workaround | in case an ebuild is broken: [ -f xxx ] dodoc xxx | | Uh... Sorry but it's pretty hard to imagine something more annoying | than an ebuild that dies after a couple of hours compile just because | upstream decided to rename Changelog.txt to ChangeLog.txt and noone | noticed during version bump, or because someone made a typo there. | Fail to see any benefit from this... :S Ditto for manpages. Uh... Presumably, the person doing the version bump would have, you know... Tested the ebuild before committing it. Standards haven't slipped *that* far have they? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Jakub Moc wrote: [Wed Jul 12 2006, 05:11:01PM EDT] Uh... Sorry but it's pretty hard to imagine something more annoying than an ebuild that dies after a couple of hours compile just because upstream decided to rename Changelog.txt to ChangeLog.txt and noone noticed during version bump, or because someone made a typo there. Fail to see any benefit from this... :S Ditto for manpages. The point is to catch the problems at version-bump time or typo-time rather than put a broken ebuild into portage. IMHO this change can mean nothing but goodness for the overall quality of the portage tree. Surely you don't go around version-bumping and typo-ing without testing prior to commit, right? Regards, Aron pgp9OVi53Gv5D.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wednesday 12 July 2006 23:21, Henrik Brix Andersen wrote: How could that slip through the initial testing of the ebuild performed by the developer doing the version bump? I think that is the point, during testing. If I'm testing the version bump of something that takes 2 hours to build, I'll be happy to see a big fat warning about it, but not that happy to see it fail entirely. Also, we already discussed in the past that there are cases in which dodoc is called within eclasses with a series of names that might or might not exists, because they are mostly standard, and left to dodoc to find the ones good and the ones not. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpHBG80Fh83P.pgp Description: PGP signature
Re: [gentoo-dev] Re: xpdf status
Stefan Schweizer wrote: Though if someone is willing to maintain a vanilla xpdf ebuild I'd have no complaints. Genstef? I have no complaints either. If there is exg doing the security bumps and taking care of the upstream version I am supporting it. I would have no problem in doing it, but since I am the only one so far who see an issue in the current situation I don't think it's worth the effort. -- Emanuele -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Henrik Brix Andersen wrote: On Wed, Jul 12, 2006 at 11:11:01PM +0200, Jakub Moc wrote: Uh... Sorry but it's pretty hard to imagine something more annoying than an ebuild that dies after a couple of hours compile just because upstream decided to rename Changelog.txt to ChangeLog.txt and noone noticed during version bump, or because someone made a typo there. Fail to see any benefit from this... :S Ditto for manpages. How could that slip through the initial testing of the ebuild performed by the developer doing the version bump? Well, it could happen while testing an ebuild. :) I'd be pretty ticked if I were testing Qt and I didn't realize they did change the doc files around before doing a test run. Besides that though, imho, a simple function with a boolean return type shouldn't kill the script executing it. Throw a warning, yes, but not stop everything. Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Henrik Brix Andersen wrote: On Wed, Jul 12, 2006 at 11:11:01PM +0200, Jakub Moc wrote: Uh... Sorry but it's pretty hard to imagine something more annoying than an ebuild that dies after a couple of hours compile just because upstream decided to rename Changelog.txt to ChangeLog.txt and noone noticed during version bump, or because someone made a typo there. Fail to see any benefit from this... :S Ditto for manpages. How could that slip through the initial testing of the ebuild performed by the developer doing the version bump? It couldn't, but this change isn't being made with a bump. We haven't been assured those doing the change right now are going to test every package using doman, dodoc, etc.. Packages will probably start failing left and right. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wednesday 12 July 2006 14:36, Steve Dibb wrote: Well, it could happen while testing an ebuild. :) I'd be pretty ticked if I were testing Qt and I didn't realize they did change the doc files around before doing a test run. Besides that though, imho, a simple function with a boolean return type shouldn't kill the script executing it. Throw a warning, yes, but not stop everything. Then you could have a IM_TESTING_STUFF_DONT_DIE_ON_DODOC variable to override the die or something -- # Just a user; my opinion doesn't matter here... # electronerd, the electronerdian from electronerdia # pgpVCaHEjVfru.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wed, 12 Jul 2006 14:46:32 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | It couldn't, but this change isn't being made with a bump. We haven't | been assured those doing the change right now are going to test every | package using doman, dodoc, etc.. Packages will probably start failing | left and right. EAPI. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Linux World Expo
On Monday 10 July 2006 14:38, Joshua Jackson wrote: So who's planning on going? Basically I'd like to know who's planning on going. I'm still undecided about it honestly, and if I go it'd only be for a few days. Its also probably a good way to find a roomate to make the cost of rooms a bit less. We don't have enough dev's close enough to san fran to allow a whole bunch of us a floor to crash on as far as I know. If however you are, give us a shout with floor space ;) as far as i know, dostrow will be organizing it ... and i'll be showing up to be his love slave and/or assistant -mike pgpQNviLoXAcI.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe die by default and doins, doman, dodoc warn initially
On Thursday 13 July 2006 02:26, Daniel Black wrote:
4. FEATURES=noauto ebuild {package}.ebuild install
FEATURES=noauto has broken at least two times in different ways with portage
2.1 pre-releases.
Same as broke FEATURES=digest and FEATURES=autoaddcvs or whatever that was.
I won't rely on those FEATURES because nobody has a clear idea of what they
should and what they should not do.
if these use doins/man/doc then the should probably check them before
installing:
[ -f ${doc} ] dodoc ${doc}
dodoc of 30 files of which some might not exists take less runtime than 30
checks for files and following dodoc file-by-file.
Better a dodoc $(ls ${doc} 2/dev/null) probably
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgp6PFDk51UF9.pgp
Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe die by default and doins, doman, dodoc warn initially
On Thu, 13 Jul 2006 02:41:26 +0200 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| if these use doins/man/doc then the should probably check them
| before installing:
| [ -f ${doc} ] dodoc ${doc}
|
| dodoc of 30 files of which some might not exists take less runtime
| than 30 checks for files and following dodoc file-by-file.
Uh... Why on earth is the runtime speed for one-off src_install things
being discussed? A few hundredths of a second in non-global code is
utterly irrelevant. The far more important issue is what's more
readable.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)
Zac Medico [EMAIL PROTECTED] wrote: The attached patch for bug #132355 [1] adds a --mindeps option for emerge that effectively allows build time dependencies to be excluded from dependency calculations involving binary and installed packages. With this patch, it's possible to remove all build time dependencies from a system with the command `emerge --depclean --mindeps`. When --mindeps is used to install packages, it causes build time dependencies to be excluded for binary packages and packages that are already installed. Consider this a suggestion disguised as a question: why not make that the overall default instead of enabled with a command-line switch? It makes sense. Don't install the packages that aren't needed. Simple. -- I used to think romantic love was a neurosis shared by two, a supreme foolishness. I no longer thought that. There's nothing foolish in loving anyone. Thinking you'll be loved in return is what's foolish. -- Rita Mae Brown pgpBrWUoe71FW.pgp Description: PGP signature
Re: [gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)
On Tue, 2006-07-11 at 22:32 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, The attached patch for bug #132355 [1] adds a --mindeps option for emerge that effectively allows build time dependencies to be excluded from dependency calculations involving binary and installed packages. With this patch, it's possible to remove all build time dependencies from a system with the command `emerge --depclean --mindeps`. When --mindeps is used to install packages, it causes build time dependencies to be excluded for binary packages and packages that are already installed. This patch will change the previous default behavior for `emerge --usepkg package list`, but if desired, the user will be able use --mindeps together with --usepkg. Are there any suggestions to improve on this idea or is it fine the way that it is? Please invert the logic so that rather than changing default behavior you add a new option choose the types of deps to include. I was in favor and thought we were going to do it after 2.1 and the 2006 release under the idea of the variable ACCEPT_DEPENDS export ACCEPT_DEPENDS=DEPEND RDEPEND PDEPEND emerge -K system Whatever we do in the end does not really matter as long as we don't change default expected behaviors. Zac [1] http://bugs.gentoo.org/show_bug.cgi?id=132355 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEtIlf/ejvha5XGaMRAo26AKCovCALx/VDIft6e+0lh+FI7IQsoQCg8o6M UW+dnXPwMe/tIje1A4RYqRs= =9uIv -END PGP SIGNATURE- -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: Please invert the logic so that rather than changing default behavior you add a new option choose the types of deps to include. Can you explain how my proposed change in the default behavior of --usepkg is going to hurt things? The current default behavior is inconsistent because build time dependencies are considered for packages that are installed but not for binary packages that are about to be installed. By doing away with this one special case for binary packages, the dependency calculation will be consistent for installed vs. binary packages. I was in favor and thought we were going to do it after 2.1 and the 2006 release under the idea of the variable ACCEPT_DEPENDS export ACCEPT_DEPENDS=DEPEND RDEPEND PDEPEND emerge -K system While I admire the flexibility of your ACCEPT_DEPENDS proposal, I feel that it exposes far too much complexity to the user. Eventually, the functionality of emerge will be available as part of the portage api and people will probably be able to exploit it to do all kinds of crazy things like that. I just don't feel that it's appropriate to expose something like that through the emerge interface. Can you explain why we should expose that much complexity through the emerge interface? Whatever we do in the end does not really matter as long as we don't change default expected behaviors. Again, can you explain how my proposed change is going to hurt things? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEtRPH/ejvha5XGaMRAkICAKCutrtehYGHyHN+UQUDjTRvUWxDqwCff4Fv 6Z2UUrFPD4UP9aCD2QHi2XM= =tRS4 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: On Wed, 2006-07-12 at 08:22 -0700, Zac Medico wrote: Ned Ludd wrote: Please invert the logic so that rather than changing default behavior you add a new option choose the types of deps to include. Can you explain how my proposed change in the default behavior of --usepkg is going to hurt things? The current default behavior is inconsistent because build time dependencies are considered for packages that are installed but not for binary packages that are about to be installed. And nor should they be unless the user explicitly asks for it. There basically should be no valid reason to look at build deps as we are dealing with a binary pkg because the package is already built. Updates are most often performed from source, are they not? If the build deps are already merged then they'll be ready and waiting for the next source based update or rebuild. export ACCEPT_DEPENDS=DEPEND RDEPEND PDEPEND emerge -K system While I admire the flexibility of your ACCEPT_DEPENDS proposal, I feel that it exposes far too much complexity to the user. Really? To me it would seem very natural to the Gentoo user who is already familiar with ACCEPT_KEYWORDS. For the type of functionality that we're after, a simple boolean option should suffice. ACCEPT_DEPENDS exposes implementation details that go far beyond the required information. For example, RDEPEND and PDEPEND can actually be collapsed together, so DEPEND and RDEPEND are the only real choices that are currently available. To me it seems like the wrong fix for the problem at hand and changes portage's default behavior in an undesired way. Don't get me wrong I'm definitely in favor of finer grained control over all the dep handling in general, but don't think this option should become the default. I'd invert your logic like in Kumba's proposed patch did and run with that. What about this functionality as it applies to packages that are already installed? If we invert the logic in that case, build deps will no longer be considered by default when the user runs `emerge -uD world` or `emerge --depclean`. That's an even larger change in behavior and, like I said in my reply to Drake, I'm afraid that it would cause lots of complaints and/or bugs filed. My proposed change will provide consistency in all cases with a change in the default --usepkg behavior that I feel will be acceptable to the vast majority of portage users. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEtTz//ejvha5XGaMRAk+uAJ9PwwvS9tOupY8K8g661FHF92vinQCgw9t/ GUsyhoTbR0GDpzxOsVFTfgE= =D6MW -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
