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 attachment 112420 [details, diff] 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 attachment 140959 [details, diff] 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 :)
