Re: [gentoo-dev] rfc: Qt version 4.5.2 news item
> On Wed, 23 Sep 2009, Alex Alexander wrote: > We're planning on stablereq'ing Qt 4.5.2 (really) soon, so I've > written this news item to cover default USE flag changes that could > confuse users :) > Please review, thanks: GLEP 42 says that you should wrap lines at 72 columns. Ulrich
Re: [gentoo-dev] rfc: Qt version 4.5.2 news item
On Wed, Sep 23, 2009 at 10:16, Ulrich Mueller wrote: > GLEP 42 says that you should wrap lines at 72 columns. > > Ulrich Correct, I was sure I'd miss something. Thanks :) Title: Qt 4.5.2 default USE flag changes Author: Alex Alexander Content-Type: text/plain Posted: 2009-09-23 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://www.linuxized.com/p192 -- Alex || wired Gentoo Dev www.linuxized.com
[gentoo-dev] On shebangs of scripts
Hi all, Recently, we added a new QA check in Gentoo Prefix' Portage to check shebangs (the #! things) of scripts before they are installed. We basically did this simply because we don't want to use say /usr/bin/perl and because this executable might not exist (e.g. on vanilla FreeBSD). Even if it does exist, we still don't want to use it, since we installed a newer/better version, that also can find the installed packages. This basically does not affect Gentoo Linux, however, we do run into several other cases right now that do affect Gentoo Linux: - shebangs like #!python, these are invalid and used by some python packages - shebangs like #!/usr/local/bin/python, this is not a good idea, used IIRC by python itself - shebangs like #!/bin/csh or #!/bin/tcsh that are correct in itself, but basically need tcsh to be installed to run, e.g. vim does this The problem with these is that they are executable scripts, e.g. a user could expect them to be able to run, IMO. Solving this can be done by fixing the shebang (as for the first two cases), adding a runtime dependency (for the last case), or by removing the executable bit of the scripts so they no longer can be run, and they merely become examples/documentation. Should we start filing bugs on these issues? In the end, they are broken scripts on the system. Is there interest for porting the Prefix shebang QA check to normal Portage? -- Fabian Groffen Gentoo on a different level
[gentoo-dev] 2nd KDE (mini) Meeting - September 2009
Hey, The KDE Team will have a supplemental September meeting tomorrow to discuss the state of KDE 4.3.1 and Qt 4.5 / gcc 4.4, as agreed in the previous meeting. Date: Thursday, 2009/09/24 Time: 1900 UTC Channel: #gentoo-meetings Topics: - KDE 4.3.1 state: bugs, stabilization - Qt 4.5.x and gcc 4.4 see ya there :) -- Alex || wired Gentoo Dev www.linuxized.com
Re: [gentoo-dev] On shebangs of scripts
Fabian Groffen wrote: > Should we start filing bugs on these issues? In the end, they are > broken scripts on the system. Is there interest for porting the Prefix > shebang QA check to normal Portage? Sounds useful to me, my vote for it. Sebastian
Re: [gentoo-dev] On shebangs of scripts
On Wed, Sep 23, 2009 at 2:53 AM, Fabian Groffen wrote: > Hi all, > > Recently, we added a new QA check in Gentoo Prefix' Portage to check > shebangs (the #! things) of scripts before they are installed. We > basically did this simply because we don't want to use say > /usr/bin/perl and because this executable might not exist (e.g. on > vanilla FreeBSD). Even if it does exist, we still don't want to use it, > since we installed a newer/better version, that also can find the > installed packages. This basically does not affect Gentoo Linux, > however, we do run into several other cases right now that do affect > Gentoo Linux: > > - shebangs like #!python, these are invalid and used by some python > packages > - shebangs like #!/usr/local/bin/python, this is not a good idea, used > IIRC by python itself > - shebangs like #!/bin/csh or #!/bin/tcsh that are correct in itself, > but basically need tcsh to be installed to run, e.g. vim does this > > The problem with these is that they are executable scripts, e.g. a user > could expect them to be able to run, IMO. Solving this can be done by > fixing the shebang (as for the first two cases), adding a runtime > dependency (for the last case), or by removing the executable bit of the > scripts so they no longer can be run, and they merely become > examples/documentation. Should there ever be executable scripts in /usr/share? If the consensus is 'no', could portage remove the +x bit automatically? Other distros debate about +x in /usr/share/doc too: https://bugzilla.redhat.com/show_bug.cgi?id=487527#c3 - From what I gather, other distros decided that they can be +x if they work properly (meaning, proper dependencies) > > Should we start filing bugs on these issues? In the end, they are > broken scripts on the system. Is there interest for porting the Prefix > shebang QA check to normal Portage? > > > -- > Fabian Groffen > Gentoo on a different level > >
[gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses
In pre-EAPI-2, src_unpack phase was the most logical phase to be provided by
SCM eclasses, thus classes has been set up to export ${ECLASS}_src_unpack.
This phase in most (if not all) SCM eclasses provided:
- unpack functionality - fetch and store in ${DISTDIR}
- bootstrap functionality - either patching or bootstrapping just unpacked
sourced with command
In EAPI-2, bootstrap functionality belongs to prepare phase, thus it's been
moved there - SCM eclasses in EAPI-2 codepath has been set up to provide
src_prepare.
And this is the problem (some people may be even unaware of it).
In pre EAPI-2 it was sufficient to do the following in live ebuilds:
inherit ${some_eclass} ${scm_eclass}
${scm_eclass} inherited as last one, would just shadow src_unpack, providing
what we want. In EAPI-2 however, it as well shadows src_prepare which is in
*most* cases unwelcome, especially if one uses autopatcher (base.eclass, so
cmake-utils.eclass, kde4-*.eclass, and probably some other).
Because SCM bootstrap is either not used at all, or used very rarely, there's
suggestion to:
- either drop it
- or (preferably) to make SCM eclasses export src_prepare only on specific
request
- or to make it easier - to not export it at all - thus making it required for
developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is
required.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses
> On Thu, 24 Sep 2009, Maciej Mrozowski wrote:
> Because SCM bootstrap is either not used at all, or used very
> rarely, there's suggestion to:
> - either drop it
> - or (preferably) to make SCM eclasses export src_prepare only on
> specific request
> - or to make it easier - to not export it at all - thus making it
> required for developer to intentionally invoke
> ${ECLASS}_src_prepare if bootstrapping is required.
Not a good idea, IMHO. In pre-EAPI-2, the SCM eclasses shadow
src_unpack of base.eclass, so also no autopatching of base.eclass
takes place. If we now change it _not_ to export src_prepare, then
there may be surprises when bumping an ebuild to EAPI-2.
Besides, most SCM eclasses (at least cvs, subversion, git and bzr)
have their own autopatch facility running in src_prepare (before
bootstrap). Why would one need _both_ this and the one in base.eclass?
Ulrich
