[gentoo-dev] Beware of the portage cache!

2006-07-12 Thread Bryan Ãstergaard
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...

2006-07-12 Thread Matthias Schwarzott
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...

2006-07-12 Thread Jakub Moc
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...

2006-07-12 Thread Danny van Dyk
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

2006-07-12 Thread exg
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...

2006-07-12 Thread 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.

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

2006-07-12 Thread Sune Kloppenborg Jeppesen
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...

2006-07-12 Thread Ciaran McCreesh
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

2006-07-12 Thread Stefan Schweizer
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

2006-07-12 Thread Stefan Schweizer
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

2006-07-12 Thread Emanuele Giaquinta
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

2006-07-12 Thread Aron Griffis
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

2006-07-12 Thread Simon Stelling
[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...

2006-07-12 Thread Danny van Dyk
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.

2006-07-12 Thread Paul de Vrieze
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...

2006-07-12 Thread Danny van Dyk
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

2006-07-12 Thread Stefan Schweizer
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

2006-07-12 Thread Jakub Moc
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

2006-07-12 Thread Henrik Brix Andersen
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

2006-07-12 Thread Ciaran McCreesh
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

2006-07-12 Thread Aron Griffis
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

2006-07-12 Thread Diego 'Flameeyes' Pettenò
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

2006-07-12 Thread Emanuele Giaquinta
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

2006-07-12 Thread Steve Dibb

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

2006-07-12 Thread Donnie Berkholz
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

2006-07-12 Thread John Myers
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

2006-07-12 Thread Ciaran McCreesh
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] Last rites for net-misc/ssh

2006-07-12 Thread Mike Frysinger
On Tuesday 11 July 2006 09:37, Stuart Herbert wrote:
 On 7/11/06, Gustavo Felisberto [EMAIL PROTECTED] wrote:
  I'm removing net-misc/ssh from the tree as Tectia no longer provides a
  free version of they're ssh client and server. The last update to this
  package was one year and half so I'm a bit afraid of security issues that
  might exist that were not reported.

 Have you tried contacting them, and asking them for a license for
 their product, so that you can provide an ebuild for the non-free
 version?

if someone cares enough to do so, then go for it

i only put forth the effort of making an ebuild for it because there was a 
free version for me to download, i never used it (openssh 4eva!)
-mike


pgp5y1SvbFlNh.pgp
Description: PGP signature


Re: [gentoo-dev] Linux World Expo

2006-07-12 Thread Mike Frysinger
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

2006-07-12 Thread Daniel Black
On Thursday 13 July 2006 07:36, Steve Dibb wrote:
 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.

there is always,

1. oh golly I made a mistake
2. rm -rf /var/tmp/portage/{package}/image
3. (vi|emacs|nano) {package}.ebuild
4. FEATURES=noauto ebuild  {package}.ebuild install
5. victory

sure the may be some packages that don't like going through an install twice 
but I'd hope most of the bigger ones would oblige happily.

A FEATURE like dowarn as an alternate to what John Myers said maybe be good 
for the time conscious dev.

 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

As a general implementation strategy I think portage should
initially:
die on dobin, doexe

warn on
doins, doman, doexe

After the QA stuff is fixed in the tree, and the general feeling that mass 
hysteria won't break out because of it, change the warns to a die.

ECLASSES

if these use doins/man/doc then the should probably check them before 
installing:
[ -f ${doc} ]  dodoc ${doc}



-- 
Daniel Black [EMAIL PROTECTED]
Gentoo Crypto/dev-embedded/Forensics/NetMon


pgpvHx9mQGdVB.pgp
Description: PGP signature


Re: [gentoo-dev] Making dobin, doexe die by default and doins, doman, dodoc warn initially

2006-07-12 Thread Diego 'Flameeyes' Pettenò
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

2006-07-12 Thread Ciaran McCreesh
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)

2006-07-12 Thread Drake Wyrm
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)

2006-07-12 Thread Ned Ludd
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)

2006-07-12 Thread Zac Medico
-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)

2006-07-12 Thread Zac Medico
-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