Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On Tue, 29 Jan 2013 22:47:26 +0100
Pacho Ramos wrote:
> Also, autoformatting will help to prevent every package setting
> messages with different lines length (in some cases really long lines
> that I finally reported some bugs in the past to get them fitting in
> "standard" 80 characters per line).
I agree with you, there should be consistency as far as reasonable.
Formatting certainly is a valid means. Some sort of tags could
be used if formatting isn't desired. Ie similar to eclass-manpages.
The eclass blurb:
readme.gentoo - An eclass for installing a README.gentoo doc file
recording tips
I know it started out as CONFIGURATION, but README.gentoo is generic
enough to contain other package specific info a user or upstream
developer might be interested in. What I have in mind right now are
patches.
This could look like the following in an ebuild:
README_GENTOO_PATCHES=( "${FILESDIR}"/*.patch )
epatch "${README_GENTOO_PATCHES[@]}"
Then the eclass generates for each patch in README_GENTOO_PATCHES a
note within a standard section containing patch name, author, subject
line. This needs something similar enough to a git format patch to
magically work though, but might be a nice addition and would help the
goal of consistency. Also git-format-patch like patches are anyway
preferable to dangling patches with maybe a bug number in the ebuild
at best.
signature.asc
Description: PGP signature
Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
What's the primary Idea behind multilib at all?
Isn't it just a workaround to keep prebuild software
from lazy/incapable/dead upstreams working (skype, ...)?
Is there any other real use besides bragging about processor
capabilities and compiling an stage1 boot loader?
Please don't get me wrong. I honor the whole effort done to bring this
magic into portage/..., but I see limits in the underlying file system.
The current solution suggested by FHS-2.3 [1] is to use
/lib and /usr/lib, which works for runtime emul- packages,
since software either installed to /opt/{${PN},bin} or had no
alternative in /bin or /usr/bin.
On 01/27/2013 02:40 PM, Thomas Sachau wrote:> 2. How do you handle
other abi-specific files like headers or binaries
> and cases like binaries with abi-specific content? Is it possible
> to preserve them for all requested abis or to preserve them for an
> non-default abi?
On 01/27/2013 05:08 PM, Pacho Ramos wrote:> Maybe installing headers
in other place would be interesting :/
This is getting wired now, when we get an x86, x86_64 and x86_32
(srsly?) implementation of cp(1).
Either we avoid collision python style with /bin/${PN}- and some
link magic, to select the "best" according to moon phases.
In the spirit of FHS, I thought about introducing /bin for some
time, but this continues with other dirs.
We would need /var/lib as well (/var/lib/munin/ has ABI specific
.rrd files),
/usr/include/ ... wait a minute.
What about separating these ABIs on top dir and keeping the respective
sub-trees clean, like //{,usr/}{bin,lib}?
// could be realised by one of these systems
- - chroot (just like / chroots), needs root.
- - Gentoo/PREFIX style
- - modified runtime linker to pic correct LD_LIBRARY_PATH.
These // can be anything, like different ABIs,
different libc implementations, different keyword (stable, testing),
different Distros, - as long as it runs with the current kernel.
Well, thin-provisioning, qemu, *random virtualization*.
One ABI, maybe the one that can run/chroot all others sould be defined
as qual="", just like non-multilib systems.
Replication of //{home,usr/portage} can be avoided by symlinks
or bind-mounts, or hardlinks.
(Srsly, /usr/portage/"ebuilds,profiles,metadata,caches" has to be in
/var/portage.)
It'd be a pretty good solution for restraining mentioned (malicious)
software, /skype/ for example.
Some roundups have to be made for exhausive $PATH, X11 .desktop files,
to enable starting other //
Comments?
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlEI20AACgkQknrdDGLu8JAGBAD+MPkmNxKSCrHcAnj5PUaxyTM1
Hhymj3cHaxBuTFHlK78A/2t5qJNyg1c0nc6FSePKXq+MXWp/RVDWMb5XCpfEh4dR
=xmPN
-END PGP SIGNATURE-
Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/30/2013 09:35 AM, Michael Weber wrote: > These // can be anything, like different ABIs, different libc > implementations, different keyword (stable, testing), different > Distros, - as long as it runs with the current kernel. Well, > thin-provisioning, qemu, *random virtualization*. Did I ever mention, you can boot into these //!?! initrd context: "mount root partition $ROOTDEV at $TARGET" mkdir /fun mount -o bind $TARGET/ /fun exec switch_root /fun /sbin/init Mount output get's confusing about multiple lines mentioning $ROOTDEV, esp. for init.d/fsck, but IMHO fsck should be done in initrd, and not single-user mode with read-only mount and with binaries from that broken partition. - - other story. Or have it on separate partition - like the traditional "I switch distros" aproach. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEI3zEACgkQknrdDGLu8JBrLgEAgI2m92etcKYF7/5wWEmJc1DZ 3apcjuDokN3WxUcxDdIA/A67DJBV5OKmVxX9wSaeomakg8Ql5oCqETXM6b9n1uy+ =Lkq3 -END PGP SIGNATURE-
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Wed, 30 Jan 2013 01:39:16 +0100
Maciej Mrozowski wrote:
> On Sunday 27 of January 2013 19:11:16 Micha³ Górny wrote:
> > On Sun, 27 Jan 2013 21:04:14 +0300
> >
> > Sergei Trofimovich wrote:
> > > On Sun, 27 Jan 2013 17:30:22 +0100
> > >
> > > Micha³ Górny wrote:
> > > > On Sun, 27 Jan 2013 16:07:48 +
> > > >
> > > > Ciaran McCreesh wrote:
> > > > > On Sun, 27 Jan 2013 16:12:37 +0100
> > > > >
> > > > > Micha³ Górny wrote:
> > > > > >RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > > > > >
> > > > > >dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > > > >
> > > > > This looks like it might be a bit fragile. Is it something better
> > > > > addressed by an EAPI extension?
> > > >
> > > > I have no idea. This one's clear and simple. Not sure how you could be
> > > > able to do that better in EAPI.
> > >
> > > EAPI might allow lib[multiple?][use?][flags?] as an alias of
> > > [multiple?,use?,flags?].
> > I still don't think that would be really helpful.
> >
> > dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]
> >
> > is IMO just more confusing than the usual [ssl,...] -- people start
> > thinking 'does it mean something special?'
> >
> > Unless you mean adding the brackets to the variable itself -- but that
> > will be just scary...
> >
> > dev-libs/libfoo${MULTILIB_USEDEP}
>
> Alternatively, less fragile but more verbose would be eclass function to
> produce dependency string. While it may sound as overkill - we already do it
> in KDE:
And in ruby, and in arfrever's python
add_foo_dep $(add_bar_dep ...) ... oh wait, it doesn't work like that.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 30 Jan 2013 09:35:12 +0100
Michael Weber wrote:
> What's the primary Idea behind multilib at all?
> Isn't it just a workaround to keep prebuild software
> from lazy/incapable/dead upstreams working (skype, ...)?
Yes. And 32-bit wine for 32-bit Windows apps which are common.
> On 01/27/2013 02:40 PM, Thomas Sachau wrote:> 2. How do you handle
> other abi-specific files like headers or binaries
> > and cases like binaries with abi-specific content? Is it possible
> > to preserve them for all requested abis or to preserve them for an
> > non-default abi?
>
> On 01/27/2013 05:08 PM, Pacho Ramos wrote:> Maybe installing headers
> in other place would be interesting :/
>
> This is getting wired now, when we get an x86, x86_64 and x86_32
> (srsly?) implementation of cp(1).
>
> Either we avoid collision python style with /bin/${PN}- and some
> link magic, to select the "best" according to moon phases.
We don't want 32-bit cp. Thomas likes to support every weird idea
coming from a random user, I don't.
> In the spirit of FHS, I thought about introducing /bin for some
> time, but this continues with other dirs.
> We would need /var/lib as well (/var/lib/munin/ has ABI specific
> .rrd files),
> /usr/include/ ... wait a minute.
>
> What about separating these ABIs on top dir and keeping the respective
> sub-trees clean, like //{,usr/}{bin,lib}?
>
> // could be realised by one of these systems
> - - chroot (just like / chroots), needs root.
> - - Gentoo/PREFIX style
> - - modified runtime linker to pic correct LD_LIBRARY_PATH.
>
> These // can be anything, like different ABIs,
> different libc implementations, different keyword (stable, testing),
> different Distros, - as long as it runs with the current kernel.
> Well, thin-provisioning, qemu, *random virtualization*.
No. 32-bit chroot is an old idea and has nothing to do with multilib.
It's an alternative to multilib and there's no point in reinventing it.
- --
Best regards,
Michał Górny
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iJwEAQEIAAYFAlEI7rsACgkQfXuS5UK5QB02KAP7BLGGggDrHYeO4gC+nW3sKUEr
LI9Gr/D8ag8eGXpAtYphlZgQYQ1uXWk50MHOiPyO6x6blKV+wUtaH3oyc62POU2W
w3hsadhzVW6YRekzbUAKqdyhLqjgcliyWfoQQ6GGkRXAgKq4FcdTet972xd4omPQ
vyiTx+1LJ/yUyKIIArI=
=0uAW
-END PGP SIGNATURE-
Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/30/2013 10:58 AM, Michał Górny wrote:
> On Wed, 30 Jan 2013 09:35:12 +0100 Michael Weber
> wrote:
> We don't want 32-bit cp. Thomas likes to support every weird idea
> coming from a random user, I don't.
What is wrong with "random" or "user"? Should I take "random user"
personally? Honestly, I have no idea.
Where do you want to draw the line?
How would you handle library packages shipping binaries?
Just `rm "${D}"/usr/bin`?
>> In the spirit of FHS, I thought about introducing /bin for
>> some time, but this continues with other dirs.
>
>> What about separating these ABIs on top dir and keeping the
>> respective sub-trees clean, like //{,usr/}{bin,lib}?
> No. 32-bit chroot is an old idea and has nothing to do with
> multilib.
Right, that was the intent of my mail.
Not to question some multilib internal stupidity like how to handle
clashing pkg-config files but to question the approach in common.
Maybe FatELF would work with this multilib/USE approch w/o cluttering
the file system [1].
Multilib: funny clashes all over the tree, partial blessed by FHS.
Emul- packages, frozen, incapable of compiling and adding additional
stuff - collision avoidance by upstream.
Separated trees/chroots/... to be merged in $PATH et. al.
Is there any consent on how to proceed?
I support an slim solution, but as it turns out "architecture
independent" from FHS is just a lie. Or handled very badly.
[1] http://en.wikipedia.org/wiki/Fat_binary
> It's an alternative to multilib and there's no point in reinventing
> it.
Yeah, did not reinvent it, just want to re-think it's validity.
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlEJBGsACgkQknrdDGLu8JDMWAD+Ksp5FmqOKgHxuLtR/smWJCgU
SjnM/V64GFnGrCtSqdoA/32BHJdFrO/6YzUZTMhHp+o9u/QgAEjgbKRutdptqZwQ
=dSTv
-END PGP SIGNATURE-
Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 30 Jan 2013 12:30:51 +0100
Michael Weber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 01/30/2013 10:58 AM, Michał Górny wrote:
> > On Wed, 30 Jan 2013 09:35:12 +0100 Michael Weber
> > wrote:
>
> > We don't want 32-bit cp. Thomas likes to support every weird idea
> > coming from a random user, I don't.
> What is wrong with "random" or "user"? Should I take "random user"
> personally? Honestly, I have no idea.
Sorry, I didn't meant to offend anyone. I'm just saying that if nobody
shows a real need for having a 32-bit 'cp', then there's no point
in having that. How would you benefit from having it?
> Where do you want to draw the line?
> How would you handle library packages shipping binaries?
> Just `rm "${D}"/usr/bin`?
64-bit executables overwrite 32-bit ones. Correct order and the problem
solves itself.
> >> In the spirit of FHS, I thought about introducing /bin for
> >> some time, but this continues with other dirs.
> >
> >> What about separating these ABIs on top dir and keeping the
> >> respective sub-trees clean, like //{,usr/}{bin,lib}?
> > No. 32-bit chroot is an old idea and has nothing to do with
> > multilib.
>
> Right, that was the intent of my mail.
> Not to question some multilib internal stupidity like how to handle
> clashing pkg-config files but to question the approach in common.
I don't understand the problem with pkg-config files. pkg-config lies
in lib32/lib64, so the files are separate and don't clash.
> Multilib: funny clashes all over the tree, partial blessed by FHS.
Clashes are mostly people's faults. I keep my headers tidy; sadly, many
people believe that constant API is not an important thing and you end
up really bad.
- --
Best regards,
Michał Górny
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iJwEAQEIAAYFAlEJCB0ACgkQfXuS5UK5QB2VMwP/bjCt2BI8hn6QGN4ff03vBx1P
hmyUzw4DKKbNI5S5XYz6VprVTjh3YAm8oq8gZs3NuySNe81oyHdjn9xWO8mPOvk5
z0MxbQvrvem+HxSNEqmNtO5jxMUgMx+se6ysazn8TTd6UXXAT73mPHNoMDByznWX
3nnrELQUG4dKFxPYXDE=
=vMqF
-END PGP SIGNATURE-
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 30 January 2013 05:47, Pacho Ramos wrote:
> El mar, 29-01-2013 a las 14:03 +0800, Ben de Groot escribió:
>> On 29 January 2013 03:30, Pacho Ramos wrote:
>> > El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
>> >> I've started using this eclass, but with README files, not the variable,
>> >> because this is currently the only way I can make sure it honours my
>> >> formatting.
>> >>
>> >
>> > Couldn't it be covered if "echo -e" was used (even with fmt) and you,
>> > then, control formatting with some of the sequences it allows (they are
>> > shown in its man page)?
>>
>> No. The eclass should assume that DOC_CONTENTS is already correctly
>> formatted. If you must, you can add a convenience function for people
>> who do want reformatting, but this should NOT be the default. Please
>> don't make this eclass harder to use than it needs to be.
>>
>
> I can add a variable (and probably will), but would prefer to keep it
> formatting messages by default, otherwise, how will you set DOC_CONTENTS
> variable inside a pkg phase (instead of global scope) without adding
> tabs to it? You can of course add it, but it will be read as something
> like:
> src_prepare() {
> DOC_CONTENTS="blablabla
> blablabla"
> # Rest of src_prepare stuff
> }
I still prefer the eclass not to mess with formatting by default. You
can do what you want by
src_prepare() {
DOC_CONTENTS="blabla
indented content"
# other stuff
}
src_install() {
default
readme.gentoo_reformat
}
> Also, autoformatting will help to prevent every package setting messages
> with different lines length (in some cases really long lines that I
> finally reported some bugs in the past to get them fitting in "standard"
> 80 characters per line).
Sometimes long lines are what is required. If not, then filing a bug
is the friendly solution.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El mié, 30-01-2013 a las 21:24 +0800, Ben de Groot escribió:
> On 30 January 2013 05:47, Pacho Ramos wrote:
> > El mar, 29-01-2013 a las 14:03 +0800, Ben de Groot escribió:
> >> On 29 January 2013 03:30, Pacho Ramos wrote:
> >> > El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
> >> >> I've started using this eclass, but with README files, not the variable,
> >> >> because this is currently the only way I can make sure it honours my
> >> >> formatting.
> >> >>
> >> >
> >> > Couldn't it be covered if "echo -e" was used (even with fmt) and you,
> >> > then, control formatting with some of the sequences it allows (they are
> >> > shown in its man page)?
> >>
> >> No. The eclass should assume that DOC_CONTENTS is already correctly
> >> formatted. If you must, you can add a convenience function for people
> >> who do want reformatting, but this should NOT be the default. Please
> >> don't make this eclass harder to use than it needs to be.
> >>
> >
> > I can add a variable (and probably will), but would prefer to keep it
> > formatting messages by default, otherwise, how will you set DOC_CONTENTS
> > variable inside a pkg phase (instead of global scope) without adding
> > tabs to it? You can of course add it, but it will be read as something
> > like:
> > src_prepare() {
> > DOC_CONTENTS="blablabla
> > blablabla"
> > # Rest of src_prepare stuff
> > }
>
> I still prefer the eclass not to mess with formatting by default. You
> can do what you want by
>
> src_prepare() {
> DOC_CONTENTS="blabla
> indented content"
> # other stuff
> }
But it will be recorded with indent in README.gentoo, what is not
desired.
>
> src_install() {
> default
> readme.gentoo_reformat
> }
>
> > Also, autoformatting will help to prevent every package setting messages
> > with different lines length (in some cases really long lines that I
> > finally reported some bugs in the past to get them fitting in "standard"
> > 80 characters per line).
>
> Sometimes long lines are what is required. If not, then filing a bug
> is the friendly solution.
>
In that case, you could set the variable to skip formatting as, the
preferred option is to keep them in standard length, and the exception
is to require longer lines (in that case they could be covered with the
variable)
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH eutils] Die if epunt_cxx is called unnecessarily.
Currently, epunt_cxx always succeeds. This results in some
of the ebuilds keeping its use even though the C++ checks were removed
upstream.
Therefore, I'm suggesting to add a simple check to the function -- if
none of the patching attempts succeed, die requesting the user to remove
the invocation.
---
gx86/eclass/eutils.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..9d77389 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1269,10 +1269,14 @@ epunt_cxx() {
local dir=$1
[[ -z ${dir} ]] && dir=${S}
ebegin "Removing useless C++ checks"
- local f
+ local f any_found
find "${dir}" -name configure | while read f ; do
- patch --no-backup-if-mismatch -p0 "${f}"
"${PORTDIR}/eclass/ELT-patches/nocxx/nocxx.patch" > /dev/null
+ patch --no-backup-if-mismatch -p0 "${f}" \
+ "${PORTDIR}/eclass/ELT-patches/nocxx/nocxx.patch" >
/dev/null \
+ && any_found=1
done
+
+ [[ -n ${any_found} ]] || die "No C++ checks to punt."
eend 0
}
--
1.8.1.2
[gentoo-dev] Re: [PATCH eutils] Die if epunt_cxx is called unnecessarily.
On Wed, 30 Jan 2013 22:36:53 +0100 Michał Górny wrote: > Currently, epunt_cxx always succeeds. This results in some > of the ebuilds keeping its use even though the C++ checks were removed > upstream. > > Therefore, I'm suggesting to add a simple check to the function -- if > none of the patching attempts succeed, die requesting the user to remove > the invocation. eqawarn? -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH eutils] Die if epunt_cxx is called unnecessarily.
On Wed, 30 Jan 2013 17:57:20 -0600 Ryan Hill wrote: > On Wed, 30 Jan 2013 22:36:53 +0100 > Michał Górny wrote: > > > Currently, epunt_cxx always succeeds. This results in some > > of the ebuilds keeping its use even though the C++ checks were removed > > upstream. > > > > Therefore, I'm suggesting to add a simple check to the function -- if > > none of the patching attempts succeed, die requesting the user to remove > > the invocation. > > eqawarn? Yes, eqawarn if we don't want users to be hurt :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [PATCH eutils] Die if epunt_cxx is called unnecessarily.
On Thu, 31 Jan 2013 00:53:06 +0100 Michał Górny wrote: > On Wed, 30 Jan 2013 17:57:20 -0600 > Ryan Hill wrote: > > On Wed, 30 Jan 2013 22:36:53 +0100 > > Michał Górny wrote: > > > Currently, epunt_cxx always succeeds. This results in some > > > of the ebuilds keeping its use even though the C++ checks were removed > > > upstream. > > > > > > Therefore, I'm suggesting to add a simple check to the function -- if > > > none of the patching attempts succeed, die requesting the user to remove > > > the invocation. > > > > eqawarn? > > Yes, eqawarn if we don't want users to be hurt :P. I think it would be overkill to make what is essentially a no-op into a fatal error. A warning would be appropriate. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-dev] Lastrite: www-client/xxxterm
# Rafael G. Martins (31 Jan 2013) # Renamed to xombrero. Please install www-client/xombrero (bug #417555) # The package was not pkg-moved to fix the upstream versioning mess. # Removal in 30 days www-client/xxxterm -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
