crossdev stores the EXTRA_ECONF options w/o quotes

Hi,

Minor bug in crossdev, as the title says its storing the options I
passed without the quotes.  That means emerge spills some messages about
'command not found' referring to the second options on those lines.

Here's an example of what I'm doing (mind you it doesn't work for what
its intended -- i.e. the mingw-w64 tools are not quite right, they are
missing the 32 bit libc++ and other details):

$ sudo crossdev -t x86_64-w64-mingw32 \
> --b 2.22 --g 4.6.2 \
> --benv
EXTRA_ECONF="--enable-targets=x86_64-w64-mingw32,i686-w64-mingw32" \
> --genv EXTRA_ECONF="--enable-multilib --enable-targets=all" \
> --lenv EXTRA_ECONF="--enable-lib64 --enable-lib32"

That command succeeds.

Later using emerge for my weekly update:

/etc/portage/env/cross-x86_64-w64-mingw32/mingw64-runtime: line 2:
--enable-lib32: command not found
/etc/portage/env/cross-x86_64-w64-mingw32/gcc: line 2:
--enable-targets=all: command not found

And the offending lines:

$ head -n 2 /etc/portage/env/cross-x86_64-w64-mingw32/mingw64-runtime
/etc/portage/env/cross-x86_64-w64-mingw32/gcc

Re: crossdev stores the EXTRA_ECONF options w/o quotes

On Saturday 04 February 2012 18:22:24 René Berber wrote:
> Minor bug in crossdev

bugs should be filed in bugs.gentoo.org
-mike

Licence compliance - capturing all source files used to make a build?

Hi, how do others handle open source licence compliance when building 
some base system using gentoo?

In particular I guess simply capturing the ebuilds is not sufficient and 
it's necessary to capture and distribute all the source and patch files 
used to create a build.  The emerge tool doesn't obviously give a way to 
capture this stuff.  I looked in the eclasses, particularly the epatch 
file and I'm not clear that I can easily hook into that.

At the moment I'm using a bashrc file to grab everything from the build 
directory.  This seems reasonably robust for source files.  However, for 
patches I have considered creating a fake patch utility which would 
record all the files it operates on.  Any other suggestions?  Perhaps 
catalyst already has done something like that - not familiar with it though?

Whilst the above is largely targeting GPL type licences, are there other 
things I should consider for other licences? Other things I need to 
ensure I distribute for GPL? Any pointers to (simple) documentation on 
how one can be a compliant open source citizen..?

Thanks

Ed W

Re: Licence compliance - capturing all source files used to make a build?

Ed W wrote:
> Hi, how do others handle open source licence compliance when building
> some base system using gentoo?

Review the packages that get built, and adhere to their licenses. It
can be a fair bit of work.

> In particular I guess simply capturing the ebuilds is not sufficient
> and it's necessary to capture and distribute all the source and
> patch files used to create a build.

How do you build your system? If you use catalyst, the open source
gold standard citizen publishes spec files, snapshot, toolchain and
toolchain source.

> The emerge tool doesn't obviously give a way to capture this stuff.

First step is to analyze licenses. emerge does know the license for a
package, and it is available in /var/db/pkg/ after install.

> I looked in the eclasses, particularly the epatch file and I'm not
> clear that I can easily hook into that.

If you have patches which use a different license than the package
they modify then you have more work to do. Portage doesn't help here.
A good start would be to add record of all patches applied by emerge.
Indeed add it into the epatch command.

> Whilst the above is largely targeting GPL type licences, are there
> other things I should consider for other licences?

ARM manuals

Hello,

I know my ideas to main stream Gentoo on arm, are not very popular
with gentoo devs.

A while back there was talk of Gentoo and Ubuntu exploring
some deeper form of cooperation; a merger of sorts. Surely
an interesting idea. Curiously, Ubuntu seems to be able to
publish documents, very easily.

The point of this message, is to share the Ubuntu vision
for (Ubuntu) Linux on ARM; where the  embedded and the
computer versions of Linux are on a collision coarse.

https://wiki.ubuntu.com/ARM

I hope you enjoy Ubuntu's vision for Linux on Arm.
In essence, it will soon be as ubiquitous as x86,
or at least many believe this scenario is plausible.

On this link above, we see where TI, Freescale and Nvidia
are all lining up for a piece of the corps (the x86 corps
that is).

enjoy!
James

Re: Licence compliance - capturing all source files used to make a build?

Hi

> It's not simple. You have to learn the requirements of each license
> and see if and how they allow themselves to be combined. There are
> businesses doing exactly that. If you want to DIY I think you just
> have to start by reading the licenses. You may or may not want an
> IP lawyer sitting beside you while doing it.

This is the kind of unhelpful answer that I can find plenty of examples 
of through google...

Consider that all software comes with some kind of licence.  Generally 
if you ask a non opensource company about licensing costs then even the 
sales droid can help you out. I do find it quite baffling that on 
average if you question an opensource user then their answer on 
licensing is that one should redirect the question to one of the most 
expensive and opaque professions on earth...  If your mate gave you that 
answer in the pub when you asked what price for a beer you would 
immediately cotton on that they don't really know and are bluffing...

The bit people seem to miss is that legal documents are for forcing 
arbitration in the event of dispute - in the meantime people are 
supposed to rub along in a cooperative manner.  That many OSS advocates 
seem to feel that employing expensive lawyers is the only way to talk to 
them shows that they are probably missing the bigger picture...

On a more constructive note: I think I do understand the key terms of 
the main software licences we use, from my understanding they are not 
all that onerous.  So can we perhaps move this topic onto tips, 
suggestions and practical matters about moving forward?  I'm not sure 

Re: Licence compliance - capturing all source files used to make a build?

Ed W wrote:
>> It's not simple. You have to learn the requirements of each license
>> and see if and how they allow themselves to be combined. There are
>> businesses doing exactly that. If you want to DIY I think you just
>> have to start by reading the licenses. You may or may not want an
>> IP lawyer sitting beside you while doing it.
>
> This is the kind of unhelpful answer that I can find plenty of examples of 
> through google...
>
> Consider that all software comes with some kind of licence.  Generally if 
> you ask a non opensource company about licensing costs then even the sales 
> droid can help you out. I do find it quite baffling that on average if you 
> question an opensource user then their answer on licensing is that one 
> should redirect the question to one of the most expensive and opaque 
> professions on earth...

That's not what I wrote, I wrote that *you* should read the licenses.

I wouldn't have mentioned an IP lawyer at all had it not been for the
fact that I know that you are in the US. :)

Lawyer or not depends on how much self education one is interested
in. I've given open source law advice to customers and have had some
contact guiding IP lawyers to better understanding. But it really is
a big field, and you weren't clear on if you already had a good
understanding of the requirements in the various licenses.

> If your mate gave you that answer in the pub when you asked what
> price for a beer you would immediately cotton on that they don't

Re: ARM manuals

Re: Licence compliance - capturing all source files used to make a build?

Hi

> I wouldn't have mentioned an IP lawyer at all had it not been for the
> fact that I know that you are in the US. :)

I'm in the UK

> I use catalyst, and I control what gets deployed with custom ebuilds
> and snapshots. The fewer packages in the final system the better;
> less stuff to track.

Whilst I guess it should be possible to tear apart catalyst and find out 
how they do it, does anyone happen to know or have a heads up on the 
code for catalyst?  It must be a solved problem so I should think others 
have solved this in various ways?

Thanks

Ed W

Can I get some interest in the uclibc-0.9.33.ebuild

Hi, could all uclibc users take a peek at: 
https://bugs.gentoo.org/show_bug.cgi?id=308477

I have bumped the ebuild to 0.9.33 and also added some extremely hacky 
patches to build iconv (and accidentally also locale) support.  From my 
limited understanding this almost works as expected and seems very 
achievable to get to a fully working state.  The iconv support is the 
main thing I wanted. Locales seem to be included as part of the same 
uclibc config switch, but don't add that much extra space - it would be 
nice to have them independently selectable though

I need some help:
- Testing the iconv stuff and working on the patches so they can go upstream
- Fixing the ebuild to have an iconv flag to bring this stuff in a 
selectable way
- Fixing the ebuild to allow selectable locales in some gentoo 
acceptable way?
- Testing with hardened, ie gcc-4.5.3-r2 and the adjusted variable as 
per bug (this brings SSP support to gcc on uclibc)
- Testing on as many other architectures than x86 as possible...

The goal is to get this into tree as a masked ebuild as soon as 
possible.  The rest of the tree is growing away from supporting uclibc 
because its the easiest option. However, if we can get 0.9.33 in good 
shape then we have a modern drop in libc replacement which supports 
modern hardened compilers, nptl and more - it's then feasible to start 
filing bugs to other packages to add small patches as appropriate.  In 
particular having even partially working iconv support in uclibc would 
appear to reduce the number of packages with uclibc conditional compiles 
by a large chunk...

Grateful for help getting this in shape

Thanks

Ed W