Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

After one of the elog lines states:
"They are listed in /usr/share/doc/${PF}/INSTALL.gz."
However on my system that file is compressed with .bz2 instead
So maybe that line should be:
"They are listed in /usr/share/doc/${PF}/INSTALL.bz2"?

Reproducible: Always

Created an attachment (id=112420) [details]
Diff file

man make.conf / PORTAGE_COMPRESS

So what? The message is still wrong.

(In reply to comment #3)
> So what? The message is still wrong.

So what? It will be *still* wrong after you 'fix' it and you set
PORTAGE_COMPRESS="gzip" 

Exactly. Now that we've established that - how about a real solution?

Like, use your brain/common sense? Thanks.

*** Bug 169874 has been marked as a duplicate of this bug. ***

Hm, I don't even have that varible set in my make.conf (I do have bzip2 USE
flag however)
Ok, if one cannot do something smart like:

elog "They are listed in /usr/share/doc/${PF}/INSTALL.${DOC_EXTENSION}."

then what about adding the line:
"NOTE: docs could also be compressed with bzip2"
or something like that.
Then not so experienced users like me will not bug you anymore with this issue
(I see there's already a similiar bug)

(In reply to comment #8)
> elog "They are listed in /usr/share/doc/${PF}/INSTALL.${DOC_EXTENSION}."

Talk about over-engineering...

*** Bug 170939 has been marked as a duplicate of this bug. ***

*** Bug 172427 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> (In reply to comment #8)
> > elog "They are listed in /usr/share/doc/${PF}/INSTALL.${DOC_EXTENSION}."
> 
> Talk about over-engineering...

# find /usr/portage/ -name '*.ebuild' | xargs egrep -l
'einfo.*share.*gz|elog.*share.*gz'|wc -l
196
#

Lots of potential for duplicate bug reports there.

Some options:
 a) DOC_EXTENSION/over-engineered fix - but only complete fix?
 b) have einfo|elog regsub their arguments - quick hack, complete fix
impossible
 c) leave as is - untidy, possible version skew indication
 d) teach gunzip bz2 - :)

*** Bug 173160 has been marked as a duplicate of this bug. ***

*** Bug 176564 has been marked as a duplicate of this bug. ***

reopening to reassign

Changing severity to normal, since these are not just typos, but documentation
errors.

How about just using wildcards:
elog "They are listed in /usr/share/doc/${PF}/INSTALL."*
(assuming we're talking about postinst)

too much overhead for any of these solutions ...

just rewrite the message to not explicitly include the full path:
"They are listed in the INSTALL file in /usr/share/doc/${PF}/"

*** Bug 180594 has been marked as a duplicate of this bug. ***

*** Bug 186242 has been marked as a duplicate of this bug. ***

*** Bug 186511 has been marked as a duplicate of this bug. ***

(In reply to comment #21)
> *** Bug 186511 has been marked as a duplicate of this bug. ***

I'm a bit surprised using ".../INSTALL$(ecompress --suffix)" hasn't occured
here yet. Anyone thought of that? If so, any reason for not using this? Could
there still be portage versions out there that don't have ecompress? In that
case you could use ".../INSTALL$(ecompress --suffix 2>/dev/null || echo .gz)".
Note that the latest ecompress does cache the suffix, so the overhead will be
negligible.

or just make it read "the INSTALL file in /usr/share/doc/${PF}/"

people arent retarded, they can tab complete

*** Bug 189178 has been marked as a duplicate of this bug. ***

*** Bug 185990 has been marked as a duplicate of this bug. ***

Maybe this should be added to the "writing ebuilds" docs somewhere. I think it
would be best to not reference the complete path and filename explicitly, but
rather describe it's location (as vapier suggested in comment #23). Why don't
we make this policy and close this bug? 

I understand jakub saying that this is really not worth the overhead it caused,
but pointing users to a file that doesn't exist just feels wrong from a QA
point of view, even if the correct filename can be found easily.

*** Bug 195678 has been marked as a duplicate of this bug. ***

*** Bug 199982 has been marked as a duplicate of this bug. ***

*** Bug 202506 has been marked as a duplicate of this bug. ***

Okay, so is the Portage team saying that this is too much of a pain and with
little gain to add in the ${ECOMPRESS_EXTENSION} or whatever we want to call
it?  If that's the case, is everyone in agreement that we will just tell people
the directory to look for the files?  "The INSTALL file can be found in
/usr/share/i_like_penguins/" ?  If so, then I'll go ahead and start getting
something done about this.  I just want to be sure of what everyone's position
is before I do anything.  Thanks

yes, rewrite the message

Created an attachment (id=140959) [details]
devmanual patch

How does this sound for documentation on devmanual?

looks sexy, thanks

Is using `ecompress --suffix` to find out extension for manpages entirely wrong
then? I needed this for media-gfx/xloadimage and media-gfx/xli for
update_alternatives to symlink manpages correctly. 

If this is wrong, please provide a alternative.

ecompress isnt part of PMS ... it could easily be integrated though as the API
should be clean

however, you're talking about internal stuff, not messages displayed to the
user.  there still should be no reference to suffixes in messages.

*** Bug 207373 has been marked as a duplicate of this bug. ***

*** Bug 207688 has been marked as a duplicate of this bug. ***

Since these are such simple fixes, why doesn't the QA team just go in and do
the fix when they find it?  I realize the whole stepping on toes thing, but
come on, this is silly.

(In reply to comment #38)
> Since these are such simple fixes, why doesn't the QA team just go in and do
> the fix when they find it?  I realize the whole stepping on toes thing, but
> come on, this is silly.
> 

We will go and fix them (eventually when I get time), but we want to make
maintainers aware of this as well.  I'll be sending something to
g-dev/g-dev-announce, since we want to teach people instead of just going and
changing things without letting people know why the change is needed.

Guys, I disagree with you. (In reply to comment #23)
> people arent retarded, they can tab complete

I'm not so sure about that, but this isn't the point. Not listing the exact
file breaks copy and paste for people how like to have a look at the file in
question in some specific file viewer, for example. To me it's more about this
last bit of exactness/quality Gentoo is lacking constantly. Granted this one is
minor issue, but it wouldn't be a big issue to let Portage provide
$ECOMPRESS_EXTENSION. The work needed to modify the ebuilds accordingly
wouldn't be different to what is happening now.

(In reply to comment #0)
> After one of the elog lines states:
> "They are listed in /usr/share/doc/${PF}/INSTALL.gz."
> However on my system that file is compressed with .bz2 instead
> So maybe that line should be:
> "They are listed in /usr/share/doc/${PF}/INSTALL.bz2"?
> 
> Reproducible: Always
> 

I would like to suggest other things to put it in DB_CONFIG sample, like:

#
http://www.stanford.edu/services/directory/openldap/configuration/bdb-config.html
set_flags DB_LOG_AUTOREMOVE


# http://www.mail-archive.com/openldap-software@openldap.org/msg06940.html 
# http://coreservices.blog.gustavus.edu/2006/05/03/fedora-core-5-and-openldap/
#set_lk_max_locks 2000
#set_lk_max_lockers 2000
#set_lk_max_objects 2000

All done here.

Looks like we've got more of these in the tree, reopening...

Victor, I've CCed you on this bug, because you've been adding several of these
compression bugs.

In the future, could you please just mention on the relevant bug what you're
intending to do, and the QA devs can suggest the best way to go about it?  Many
of these bugs are being filed to the same people, who'll be a little unhappy at
receiving all these emails for effectively the same problem.  It would save
both the time of the bug wranglers, and all the devs who have to deal with
these bugs.  So next time, please ask for advice and then wait a few days and
if you haven't had a reply, then start filing them.

Also, you could always mention the issue on gentoo-dev to try and get some
attention.  It's possible someone with free time might have gone through and
fixed all the bugs without bothering all these different people...

Its my opinion, for any QA bug like this, to open bugs for each of the
maintainers to make them aware of the issue.  Just going and fixing the problem
isn't going to educate anyone so they don't reintroduce the same issue again
somewhere else.

With that said, all of these are fixed...closing again until we find more :)