Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Raymond Jennings]

+1 for at least having this discussed out in the open.

The issue of copyright did tickle my mind when I saw the headers during my
dev quiz.

On Mon, Oct 24, 2016 at 4:21 PM, Rich Freeman  wrote:

> On Mon, Oct 24, 2016 at 7:10 PM, Matt Turner  wrote:
> > On Mon, Oct 24, 2016 at 4:07 PM, Rich Freeman  wrote:
> >> On Mon, Oct 24, 2016 at 6:34 PM, Matt Turner 
> wrote:
> >>> In order to contribute to GNU projects, one must sign a copyright
> >>> assignment statement.
> >>>
> >>> Gentoo doesn't have anything similar as far as I'm aware, which makes
> >>> me question the legitimacy of "Gentoo Foundation" copyrights.
> >>>
> >>> What is the story?
> >>>
> >>
> >> The story of what?
> >>
> >> Are you asking whether they're legally binding?  You'd have to sue
> >> somebody to find out, because as far as I'm aware the matter is
> >> untested in court.  I think you could make an argument that
> >> voluntarily placing that header on your work is an assignment of
> >> copyright.  You could also argue otherwise.  A court would decide who
> >> wins.
> >
> > I'm asking whether we're just cargo-culting it along, or if we have
> > (had) some kind of system in place to assign copyright. I think Ciaran
> > answered: we used to but not anymore.
> >
>
> As I said, you could debate whether the present system already assigns
> copyright.  I don't think it is ideal.  It certainly isn't backed by
> any court decisions that I'm aware of.  That doesn't necessarily mean
> that it wouldn't be upheld if it did go to court.  There is really no
> way to be certain without trying it.
>
> But, it is better to rely upon methods that are already proven in
> court over ones that have yet to be proven.  I'm not disputing that.
>
> --
> Rich
>
>

[gentoo-dev] rsync.gentoo.org rsync modules: gentoo-repo-changelog added, gentoo-x86-portage & gentoo-sec discontinued.

[Robin H. Johnson]

As part of the upcoming change to no longer distribute ChangeLogs in the
main tree, Infra would like to announce some updates to the rsync
modules.

1.
The following legacy modules are hereby discontinued.
- rsync.gentoo.org::gentoo-sec
- rsync.gentoo.org::gentoo-x86-portage

'gentoo-sec' was a 2004-era attempt at distributing Gentoo developer
GPG keyrings. There have been no sync attempts recorded on any of the
rsync.gentoo.org nodes in over 2 years, and the material therein all
dates to 2004 only.

'gentoo-x86-portage' was the older name of the 'gentoo-portage' module,
and was maintained as an alias. For the 2016 calender year to date,
there have been only 11 attempts to fetch the legacy name from any of
the rsync.gentoo.org official nodes.

Community mirrors (rsyncN.CC.gentoo.org) are encouraged to drop the old
modules at their convenience.

2.
Approximately 2016/Nov/01, a new module will be available:
- rsync.gentoo.org::gentoo-repo-changelog
This module will contain the same directory structure as the repo/gentoo
tree (gentoo-portage module), but will ONLY contain ChangeLog files.
The update schedule may have gaps exceeding 6 hours initially.

Community mirrors (rsyncN.CC.gentoo.org) can prepare to mirror the new
module at their convenience.

3.
Not sooner than 2016/Nov/15, ChangeLogs will be removed from the
'gentoo-portage' rsync module. They may or may not still be referenced
by the thick Manifests.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[William L. Thomson Jr.]

On Saturday, October 29, 2016 11:44:39 PM EDT M. J. Everitt wrote:
>
> Whilst this may potentially be a contentious topic (and one that g-p-m
> has partially attempted to address) there has been a mildly aggressive
> policy applied to treecleaning, whereby if something is old and missing
> a maintainer and/or has even minor issues it is likely be nuked without
> so much as anyone attempting to solve the issues. Granted, all too often
> there IS nobody to address any issues, or outstanding bugs,

Its a slippery slope Gentoo is going down. The lack of man power causes many 
things to go un-maintained. I will not comment on tree-cleaning being right or 
wrong. Essentially what is taking place at a high level is packages over all 
are being whittled down package by package due to a lack of man power.

Eventually it could reach some equilibrium that the amount of packages is 
reduced to match the amount of man power to maintain. However it also runs the 
risk of another downward spiral side effect.

The less packages in tree, the less may come to Gentoo. Which may further lead 
to lack of man power issues in the future. Which means more packages to un-
maintained and more have to be cleaned. 

There is only 1 long term solution to this issue which is to increase man 
power. Otherwise you end up with such a reduced package set it diminishes the 
over all benefit. Gentoo would become a further niche distro moving further 
from mainstream.

Or find a way to further automate package maintenance and such, but even that 
has its limitations. Man power at some point must increase. The amount of 
software is only increasing worldwide daily exponentially.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Gentoo on Android stage3

[William L. Thomson Jr.]

On Saturday, October 29, 2016 4:42:21 PM EDT M. J. Everitt wrote:
>
> Completely out of my depth here, but can you cross-compile a

On Gentoo yes its called crossdev[1]. You can have a build system/toolchain 
for any arch you need to make an entire system or binaries for and  them over 
to what ever device. Use a very powerful host system of a completely different 
arch, like x86_64 to build armv7 and others.

I did this a while back to make tun/tap kernel drivers for an android system. 
I also used it a very long time ago using docs in vapier's devspace[2] before 
it was documented else where. That was when I got my first x86_64 system and 
there were no 64bit pre-compiled kernels or livecds at the time. So I used a 
i686 Gentoo system to make a x86_64 kernel.

The best part of that last story, I got kernel patches from SuperMicro because 
x86_64 stuff was so new. The SuperMicro kernel patches were made against a 
Gentoo kernel.

1. https://wiki.gentoo.org/wiki/Cross_build_environment
2. http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[M. J. Everitt]

On 29/10/16 21:25, NP-Hardass wrote:
> On 10/29/2016 02:30 PM, Kristian Fiskerstrand wrote:
>>
>> Someone needs to take over responsibility for the packages
>> (maintainership) and fixing the issues then. If not, they should be removed.
>>
> I'm only talking about the packages that have no other issues and are
> only being treecleaned because of this dependency.  Honestly, I don't
> care about any of those packages.  I only brought this up because
> sometimes it is better to only treeclean when appropriate, and if
> switching from one dep to another (which should have been virtual'd)
> resolves it, it might not still meet the conditions for tree cleaning.
> We don't normally tree clean packages simply because they are old or
> don't have a maintainer.
>
> So, I will reiterate my one and only point, for those that are only
> being removed due to the removal of capi4kutils, how many are still
> worthy of being treecleaned after swapping out that dep?
>
> If you feel that is too high a maintenance burden, fine, remove them
> all.  I'm merely proposing it be looked at since otherwise we are
> potentially removing packages that don't have to or shouldn't be removed.
>
Whilst this may potentially be a contentious topic (and one that g-p-m
has partially attempted to address) there has been a mildly aggressive
policy applied to treecleaning, whereby if something is old and missing
a maintainer and/or has even minor issues it is likely be nuked without
so much as anyone attempting to solve the issues. Granted, all too often
there IS nobody to address any issues, or outstanding bugs, but I too am
somewhat of the opinion that if a package builds, has some form of
upstream source, does NOT have any security vulnerabilities, it should
live in the main Gentoo tree. This doesn't seem to be a view shared by
all, but there appears to be a bias to remove and potentially re-add
later, than maintain what we have properly.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[Kristian Fiskerstrand]

On 10/29/2016 10:25 PM, NP-Hardass wrote:
> If you feel that is too high a maintenance burden, fine, remove them
> all.  I'm merely proposing it be looked at since otherwise we are
> potentially removing packages that don't have to or shouldn't be removed.

If they aren't properly maintained, they certainly should be removed. if
you want to keep them and have fixes for known issues, take over
maintainership

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Multiple misc. Python packages for grabs

[Manuel Rüger]

On 29.10.2016 23:21, Michał Górny wrote:
> Hello,

> dev-util/bumpversion

Added myself as a maintainer.





signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Multiple misc. Python packages for grabs

[Michał Górny]

Hello,

The Python team is dropping itself from maintainers of the following
packages. As a result, those packages no longer have any maintainer:

app-admin/supervisor
app-editors/leo
app-misc/yworklog
app-text/pdfminer
app-text/pylize
dev-util/bumpversion
dev-util/tailor
net-ftp/pybootd
net-im/turses
net-irc/redirbot
net-misc/charm
net-misc/pycnb
net-misc/whatportis
net-news/rawdog
net-voip/blink
sys-process/glances
www-apps/bitten
x11-misc/menumaker

Those packages are not really part of the Python ecosystem. Most of
them had python@g.o added as a co-maintainer (or in some cases as
the only maintainer, without even bothering to ping us) because
the software in question was written in Python, and never had been
really maintained by the Python team. Once the primary maintainer
abandoned them, they became sole Python team responsibility.

Using this opportunity, I would like to note that there really is no
reason to add Python team as co-maintainers to every software ever
written in Python. The Python team focuses on maintaining tools
and modules needed to use and develop Python on Gentoo.

-- 
Best regards,
Michał Górny



pgp4uKkjoVe0_.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[NP-Hardass]

On 10/29/2016 02:30 PM, Kristian Fiskerstrand wrote:
> On 10/29/2016 07:59 PM, NP-Hardass wrote:
>> On 10/08/2016 07:57 AM, Pacho Ramos wrote:
>>> # Fails to build (#515294), nothing needs it, relies on obsolete
>>> capi4kutils. 
>>>
>>
>> For all the packages being removed due to capi4kutils, how many were
>> investigated with net-libs/libcapi?  For WINE, we transitioned to using
>> libcapi instead of capi4kutils, and I don't see why some of those
>> couldn't as well, provided the capi4kutils is the only reason why those
>> are being treecleaned.
>>
> 
> Someone needs to take over responsibility for the packages
> (maintainership) and fixing the issues then. If not, they should be removed.
> 

I'm only talking about the packages that have no other issues and are
only being treecleaned because of this dependency.  Honestly, I don't
care about any of those packages.  I only brought this up because
sometimes it is better to only treeclean when appropriate, and if
switching from one dep to another (which should have been virtual'd)
resolves it, it might not still meet the conditions for tree cleaning.
We don't normally tree clean packages simply because they are old or
don't have a maintainer.

So, I will reiterate my one and only point, for those that are only
being removed due to the removal of capi4kutils, how many are still
worthy of being treecleaned after swapping out that dep?

If you feel that is too high a maintenance burden, fine, remove them
all.  I'm merely proposing it be looked at since otherwise we are
potentially removing packages that don't have to or shouldn't be removed.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[Kristian Fiskerstrand]

On 10/29/2016 07:59 PM, NP-Hardass wrote:
> On 10/08/2016 07:57 AM, Pacho Ramos wrote:
>> # Fails to build (#515294), nothing needs it, relies on obsolete
>> capi4kutils. 
>>
> 
> For all the packages being removed due to capi4kutils, how many were
> investigated with net-libs/libcapi?  For WINE, we transitioned to using
> libcapi instead of capi4kutils, and I don't see why some of those
> couldn't as well, provided the capi4kutils is the only reason why those
> are being treecleaned.
> 

Someone needs to take over responsibility for the packages
(maintainership) and fixing the issues then. If not, they should be removed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[NP-Hardass]

On 10/08/2016 07:57 AM, Pacho Ramos wrote:
> # Fails to build (#515294), nothing needs it, relies on obsolete
> capi4kutils. 
> 

For all the packages being removed due to capi4kutils, how many were
investigated with net-libs/libcapi?  For WINE, we transitioned to using
libcapi instead of capi4kutils, and I don't see why some of those
couldn't as well, provided the capi4kutils is the only reason why those
are being treecleaned.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[Benda Xu]

Rich Freeman  writes:

> Well, that would be a different approach, but I imagine you could
> build for prefix-style install using something like Catalyst and
> cross-compile.  I have no idea how much tweaking that would require.
> The main issue is that unless you use qemu you're only going to get
> one pass.  If you are going to use qemu then you could just build it
> all in an emulator and copy it over.

qemu-user with binfmt on a powerful workstation was my option, until I
actually tried it out (around 2013).  It was much slower (5x? 10x?) than
running native on a phone.  Not sure if the emulation of qemu-user
significantly improved over the years.

> You definitely could create a squashfs of /usr/portage and then just
> mount that on your phone.  You could also nfs mount it I suppose, or
> use something like iSCSI (you might need kernel modules for both).  Or
> use something like sshfs.  I've also used a compressed ram filesystem
> for this purpose in the past (basically like a tmpfs only compressed,
> often used as a high-priority swap).
>
> And of course if you can spare the RAM you can build in tmpfs.
>
> So, there are definitely some "easy" options though some of them will
> cost performance.

Indeed.  Nice hints.  Actually we have zram documented in our wiki[1].

> Another option might be USB OTG.  I think the 6P supports that with
> the right drivers.  As long as it isn't noexec I'd think you could
> install Prefix on that.

Nexus should have no problem.  The only paranoid vendor was Samsung
with a subset of their products.

Benda

1. 
https://wiki.gentoo.org/wiki/Asus_Transformer_Infinity_%28TF700T%29/Install#RAM_and_SWAP_considerations

Re: [gentoo-dev] Gentoo on Android stage3

[Benda Xu]

Hi Michael,

"M. J. Everitt"  writes:

>> No SD slot on Nexus.  We will stress the internal NAND flash with
>> millions of ebuilds and rsync :)

> Completely out of my depth here, but can you cross-compile and

Ah, I was half-joking. Considering the recent advancement of NAND flash,
I expect it lasts longer than those 3 years ago.  Back in 2013, I used a
low-quality class 10 microSD card for development, rsync'ed over 500
times before the card showed some signs of failure.

So it is pretty safe to rsync, say, once a week.  Before it wears out,
the phone will be outdated or squashdelta becomes available.

cross-compile is possible, but not trivial.  After all, the goal of this
project is to develop on Android *natively in-situ*, exactly the same as
PC: no more SDK, no more cross-compiling and no more ROM-flashing. Just
use portage to compile kernels, build java apps and rolling release,
what do you say?

ROM-flashing a phone is equivalent to reinstalling the whole OS on a PC.
My laptop runs nearly 10 years without reinstallion (and surviving a
migration from HDD to SSD).  The software on mobile devices is far more
inflexible.  What the android world lacks is a damn good solid package
manager, Gentoo/portage/Prefix is one way to save this chaos.

> is there some way of leveraging the USB-C connection on the Nexus 6P
> .. or are we talking super-complex then?!

Oh yeah, you can attach a USB flash drive or even an HDD[0] via a USB
OTG[1] adapter.

> Will keep you posted about the Samsung .. will have a stab over the
> holiday period.

Great.  Looking forward to it.

Benda

0. 
https://wiki.gentoo.org/wiki/Asus_Transformer_Infinity_%28TF700T%29/Install#RAM_and_SWAP_considerations
1. https://en.wikipedia.org/wiki/USB_On-The-Go


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo on Android stage3

[Rich Freeman]

On Sat, Oct 29, 2016 at 12:22 PM, Benda Xu  wrote:
>
> Homework received.  I have little experience blogging though.
>
> I will need first to set up a blog and then draft a writeup.
>
> Any hints?

Gentoo can set them up, or you can just use Wordpress or whatever
(Gentoo wasn't taking new blog request when I set it up).  I suggest
keeping it simple.

If you need help with proofreading/etc you can always ask pr@, or one
of us I'm sure.

-- 
Rich

Re: [gentoo-dev] Gentoo on Android stage3

[Kristian Fiskerstrand]

On 10/29/2016 06:22 PM, Benda Xu wrote:
> Kristian Fiskerstrand  writes:
> 


> 
> I will need first to set up a blog and then draft a writeup.
> 
> Any hints?
> 

You can request a blog from blogs.gentoo.org and ask for it to be
included in planet and universe

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[Benda Xu]

Kristian Fiskerstrand  writes:

>>> Actually .. given my nosiness in -pr matters lately, anyone done a
>>> write-up for Planet.g.o or suchlike that we can post up to social media?
>>> From my own stand-point it might be something the wider community would
>>> be interested in, and didn't know was a 'thing'?
>> 
>> It would be a good thing, especially since this relies on Gentoo
>> Prefix (I think), 

@Rich, yes, that's true.

>> which is a fairly unique capability I've yet to see in any other
>> distro.
>
> +1
>
> Would certainly like to see a writeup of positive things in a blog post
> that can be shared in social media.

Homework received.  I have little experience blogging though.

I will need first to set up a blog and then draft a writeup.

Any hints?

Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo on Android stage3

[Benda Xu]

Francesco Riosa  writes:

> Christmas is coming, I'll enjoy this

Haha, good point.  Should've called it Halloween release ;)

Benda

Re: [gentoo-dev] Gentoo on Android stage3

[Rich Freeman]

On Sat, Oct 29, 2016 at 11:42 AM, M. J. Everitt  wrote:
> On 29/10/16 16:35, Benda Xu wrote:
>> No SD slot on Nexus.  We will stress the internal NAND flash with
>> millions of ebuilds and rsync :)
>>
>> That makes me think of squashdelta sync, but probably after gaining
>> control of linux kernels to manage the squashfs module.
>>
> Completely out of my depth here, but can you cross-compile and is there
> some way of leveraging the USB-C connection on the Nexus 6P .. or are we
> talking super-complex then?!
>

Well, that would be a different approach, but I imagine you could
build for prefix-style install using something like Catalyst and
cross-compile.  I have no idea how much tweaking that would require.
The main issue is that unless you use qemu you're only going to get
one pass.  If you are going to use qemu then you could just build it
all in an emulator and copy it over.

You definitely could create a squashfs of /usr/portage and then just
mount that on your phone.  You could also nfs mount it I suppose, or
use something like iSCSI (you might need kernel modules for both).  Or
use something like sshfs.  I've also used a compressed ram filesystem
for this purpose in the past (basically like a tmpfs only compressed,
often used as a high-priority swap).

And of course if you can spare the RAM you can build in tmpfs.

So, there are definitely some "easy" options though some of them will
cost performance.

Another option might be USB OTG.  I think the 6P supports that with
the right drivers.  As long as it isn't noexec I'd think you could
install Prefix on that.

-- 
Rich

Re: [gentoo-dev] Gentoo on Android stage3

[Kristian Fiskerstrand]

On 10/29/2016 05:36 PM, Rich Freeman wrote:
> On Sat, Oct 29, 2016 at 11:18 AM, M. J. Everitt  wrote:
>> On 29/10/16 16:14, M. J. Everitt wrote:
>>> On 29/10/16 16:09, Benda Xu wrote:

 This is an announcement of the latest Gentoo on Android stage3 tarball,
>>
>> Actually .. given my nosiness in -pr matters lately, anyone done a
>> write-up for Planet.g.o or suchlike that we can post up to social media?
>> From my own stand-point it might be something the wider community would
>> be interested in, and didn't know was a 'thing'?
>>
> 
> It would be a good thing, especially since this relies on Gentoo
> Prefix (I think), which is a fairly unique capability I've yet to see
> in any other distro.
> 

+1

Would certainly like to see a writeup of positive things in a blog post
that can be shared in social media.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[M. J. Everitt]

On 29/10/16 16:35, Benda Xu wrote:
> Hey MJE,
>
> "M. J. Everitt"  writes:
>
>> COOL ! I'll have to give this a try .. got an old(er) Samsung Galaxy
>> S4 Active,
> From our past experience[1], Samsung sometimes imposed noexec to /data by
> kernel hacks.  It'll be interesting to find out what it looks like on
> the Galaxy S4.
>
>> and I'm currently using the Huawei Nexus 6P ..
> No SD slot on Nexus.  We will stress the internal NAND flash with
> millions of ebuilds and rsync :)
>
> That makes me think of squashdelta sync, but probably after gaining
> control of linux kernels to manage the squashfs module.
>
>> Keep up the good work! :D
> Thanks and have fun.
>
> Benda
>
> 1. https://wiki.gentoo.org/wiki/Android/Devices
Completely out of my depth here, but can you cross-compile and is there
some way of leveraging the USB-C connection on the Nexus 6P .. or are we
talking super-complex then?!

Will keep you posted about the Samsung .. will have a stab over the
holiday period.

Cheers,
Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[Rich Freeman]

On Sat, Oct 29, 2016 at 11:18 AM, M. J. Everitt  wrote:
> On 29/10/16 16:14, M. J. Everitt wrote:
>> On 29/10/16 16:09, Benda Xu wrote:
>>>
>>> This is an announcement of the latest Gentoo on Android stage3 tarball,
>
> Actually .. given my nosiness in -pr matters lately, anyone done a
> write-up for Planet.g.o or suchlike that we can post up to social media?
> From my own stand-point it might be something the wider community would
> be interested in, and didn't know was a 'thing'?
>

It would be a good thing, especially since this relies on Gentoo
Prefix (I think), which is a fairly unique capability I've yet to see
in any other distro.

-- 
Rich

Re: [gentoo-dev] Gentoo on Android stage3

[Benda Xu]

Hey MJE,

"M. J. Everitt"  writes:

> COOL ! I'll have to give this a try .. got an old(er) Samsung Galaxy
> S4 Active,

From our past experience[1], Samsung sometimes imposed noexec to /data by
kernel hacks.  It'll be interesting to find out what it looks like on
the Galaxy S4.

> and I'm currently using the Huawei Nexus 6P ..

No SD slot on Nexus.  We will stress the internal NAND flash with
millions of ebuilds and rsync :)

That makes me think of squashdelta sync, but probably after gaining
control of linux kernels to manage the squashfs module.

> Keep up the good work! :D

Thanks and have fun.

Benda

1. https://wiki.gentoo.org/wiki/Android/Devices


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo on Android stage3

[M. J. Everitt]

On 29/10/16 16:14, M. J. Everitt wrote:
> On 29/10/16 16:09, Benda Xu wrote:
>> Hi Fellows,
>>
>> This is an announcement of the latest Gentoo on Android stage3 tarball,
>>
>>   
>> http://distfiles.gentoo.org/experimental/prefix/rap/rap-stage3-armv7a_hardfp-20161026.tar.xz
>>
>> snapshot from the latest main Gentoo repository, featuring gcc-5.4,
>> glibc-2.23, and the latest prefix-standalone (aka. RAP) profiles[1].
>>
>> The tarball runs Gentoo natively[2] under /data/gentoo (:=EPREFIX[3,4])
>> on a rooted[5] android device newer than 2011 or armv7a[6], alongside
>> the Android stack.
>>
>> The installation guide is at
>>
>>   https://wiki.gentoo.org/wiki/Project:Android/tarball
>>
>> with a list of tested devices at
>>
>>   https://wiki.gentoo.org/wiki/Android/Devices
>>
>>
>> Next we are going to build a normal-user version, and to manage Android
>> kernels with portage[7].
>>
>> Time to unleash the mobile power with Gentoo.
>>
>> Enjoy,
>> Benda
>>
>> 1. 
>> https://archives.gentoo.org/gentoo-dev-announce/message/772326d735c8c7c469beffc0a9bb0b97
>> 2. No chroot or PRoot
>> 3. 
>> https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#EPREFIX_variable
>> 4. https://projects.gentoo.org/pms/6/pms.html#x1-12100011.1.3
>> 5. https://en.wikipedia.org/wiki/Rooting_%28Android_OS%29
>> 6. https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_cores
>> 7. https://wiki.gentoo.org/wiki/Project:Android
>> 8. Previous announcement:
>>
>> https://archives.gentoo.org/gentoo-dev-announce/message/890e3e40977a37bb499fb02d35efe74a
>>
> COOL ! I'll have to give this a try .. got an old(er) Samsung Galaxy S4
> Active, and I'm currently using the Huawei Nexus 6P ..
>
> Keep up the good work! :D
>
> MJE
>
Actually .. given my nosiness in -pr matters lately, anyone done a
write-up for Planet.g.o or suchlike that we can post up to social media?
From my own stand-point it might be something the wider community would
be interested in, and didn't know was a 'thing'?

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[Francesco Riosa]

Christmas is coming, I'll enjoy this

Thank you!

2016-10-29 17:09 GMT+02:00 Benda Xu :

> Hi Fellows,
>
> This is an announcement of the latest Gentoo on Android stage3 tarball,
>
>   http://distfiles.gentoo.org/experimental/prefix/rap/rap-
> stage3-armv7a_hardfp-20161026.tar.xz
>
> snapshot from the latest main Gentoo repository, featuring gcc-5.4,
> glibc-2.23, and the latest prefix-standalone (aka. RAP) profiles[1].
>
> The tarball runs Gentoo natively[2] under /data/gentoo (:=EPREFIX[3,4])
> on a rooted[5] android device newer than 2011 or armv7a[6], alongside
> the Android stack.
>
> The installation guide is at
>
>   https://wiki.gentoo.org/wiki/Project:Android/tarball
>
> with a list of tested devices at
>
>   https://wiki.gentoo.org/wiki/Android/Devices
>
>
> Next we are going to build a normal-user version, and to manage Android
> kernels with portage[7].
>
> Time to unleash the mobile power with Gentoo.
>
> Enjoy,
> Benda
>
> 1. https://archives.gentoo.org/gentoo-dev-announce/message/
> 772326d735c8c7c469beffc0a9bb0b97
> 2. No chroot or PRoot
> 3. https://wiki.gentoo.org/wiki/Project:Prefix/Technical_
> Documentation#EPREFIX_variable
> 4. https://projects.gentoo.org/pms/6/pms.html#x1-12100011.1.3
> 5. https://en.wikipedia.org/wiki/Rooting_%28Android_OS%29
> 6. https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_cores
> 7. https://wiki.gentoo.org/wiki/Project:Android
> 8. Previous announcement:
>https://archives.gentoo.org/gentoo-dev-announce/message/
> 890e3e40977a37bb499fb02d35efe74a
>
>

Re: [gentoo-dev] Gentoo on Android stage3

[M. J. Everitt]

On 29/10/16 16:09, Benda Xu wrote:
> Hi Fellows,
>
> This is an announcement of the latest Gentoo on Android stage3 tarball,
>
>   
> http://distfiles.gentoo.org/experimental/prefix/rap/rap-stage3-armv7a_hardfp-20161026.tar.xz
>
> snapshot from the latest main Gentoo repository, featuring gcc-5.4,
> glibc-2.23, and the latest prefix-standalone (aka. RAP) profiles[1].
>
> The tarball runs Gentoo natively[2] under /data/gentoo (:=EPREFIX[3,4])
> on a rooted[5] android device newer than 2011 or armv7a[6], alongside
> the Android stack.
>
> The installation guide is at
>
>   https://wiki.gentoo.org/wiki/Project:Android/tarball
>
> with a list of tested devices at
>
>   https://wiki.gentoo.org/wiki/Android/Devices
>
>
> Next we are going to build a normal-user version, and to manage Android
> kernels with portage[7].
>
> Time to unleash the mobile power with Gentoo.
>
> Enjoy,
> Benda
>
> 1. 
> https://archives.gentoo.org/gentoo-dev-announce/message/772326d735c8c7c469beffc0a9bb0b97
> 2. No chroot or PRoot
> 3. 
> https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#EPREFIX_variable
> 4. https://projects.gentoo.org/pms/6/pms.html#x1-12100011.1.3
> 5. https://en.wikipedia.org/wiki/Rooting_%28Android_OS%29
> 6. https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_cores
> 7. https://wiki.gentoo.org/wiki/Project:Android
> 8. Previous announcement:
>
> https://archives.gentoo.org/gentoo-dev-announce/message/890e3e40977a37bb499fb02d35efe74a
>
COOL ! I'll have to give this a try .. got an old(er) Samsung Galaxy S4
Active, and I'm currently using the Huawei Nexus 6P ..

Keep up the good work! :D

MJE



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Gentoo on Android stage3

[Benda Xu]

Hi Fellows,

This is an announcement of the latest Gentoo on Android stage3 tarball,

  
http://distfiles.gentoo.org/experimental/prefix/rap/rap-stage3-armv7a_hardfp-20161026.tar.xz

snapshot from the latest main Gentoo repository, featuring gcc-5.4,
glibc-2.23, and the latest prefix-standalone (aka. RAP) profiles[1].

The tarball runs Gentoo natively[2] under /data/gentoo (:=EPREFIX[3,4])
on a rooted[5] android device newer than 2011 or armv7a[6], alongside
the Android stack.

The installation guide is at

  https://wiki.gentoo.org/wiki/Project:Android/tarball

with a list of tested devices at

  https://wiki.gentoo.org/wiki/Android/Devices


Next we are going to build a normal-user version, and to manage Android
kernels with portage[7].

Time to unleash the mobile power with Gentoo.

Enjoy,
Benda

1. 
https://archives.gentoo.org/gentoo-dev-announce/message/772326d735c8c7c469beffc0a9bb0b97
2. No chroot or PRoot
3. 
https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#EPREFIX_variable
4. https://projects.gentoo.org/pms/6/pms.html#x1-12100011.1.3
5. https://en.wikipedia.org/wiki/Rooting_%28Android_OS%29
6. https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_cores
7. https://wiki.gentoo.org/wiki/Project:Android
8. Previous announcement:
   
https://archives.gentoo.org/gentoo-dev-announce/message/890e3e40977a37bb499fb02d35efe74a

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[David Seifert]

On Sa, 2016-10-08 at 13:57 +0200, Pacho Ramos wrote:
> # Pacho Ramos  (08 Oct 2016)
> # Uses get_libdir at global scope (#593382). Dead for ages. Removal
> in
> a
> # month.
> app-cdr/nero

I'd like to keep this package, hence fixed the issues, bumped to
EAPI=6, took over maintainership.

Re: [gentoo-dev] newsitem: important fstab update

[Peter Stuge]

Peter Stuge wrote:
> --8<-- mount(8)
..
>   portable. The mount(8) command internally uses udev symlinks
> -->8--

That's of course only the mount in util-linux.


//Peter

Re: [gentoo-dev] newsitem: important fstab update

[Peter Stuge]

Ian Stakenvicius wrote:
> > WilliamH wants everyone using /dev/disk/by-label/
> > paths in fstab to instead use LABEL= , to avoid issues if udev
> > doesn't create the symlinks before localmount tries to use them.
..
> UUID is the same situation in this case -- in fstab you can do it by
> UUID= or you can do it by /dev/disk/by-uuid/.  The latter
> form depends on udev finishing up and would have the same issue.

It seems that the former form may also depend on udev having settled.

--8<-- mount(8)
   The device indication.
..
  The recommended setup is to use tags (e.g. LABEL=) rather
  than  /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks
  in the /etc/fstab file. The tags are more readable,  robust  and
  portable. The mount(8) command internally uses udev symlinks, so
  use the symlinks in /etc/fstab has no advantage over  the  tags.
  For more details see libblkid(3).
-->8--

Oops. Let's look further:

--8<-- libblkid(3)
   The  high-level  part  of  the library supports two methods to evaluate
   LABEL/UUID.  It reads information directly from a block device or  read
   information  from  /dev/disk/by-*  udev symlinks. The udev is preferred
   method by default.
-->8--

..so when is the non-default method (querying devices) used?


//Peter

Re: [gentoo-dev] newsitem: important fstab update

[Daniel Campbell]

On 10/28/2016 06:00 AM, Mike Gilbert wrote:
> On Fri, Oct 28, 2016 at 12:56 AM, Daniel Campbell  wrote:
>> On 10/25/2016 10:01 AM, William Hubbs wrote:
>>> All,
>>>
>>> this item is about an important fstab update. In short, people need to
>>> move away from /dev/disk-by/* in their fstab vfiles.
>>>
>>> I do have a question about the newsitem -- how do I make it display only
>>> for Linux users?
>>>
>>> Thanks,
>>>
>>> William
>>>
>> Replying to top level since it doesn't seem to fit elsewhere.
>>
>> I have an external HDD that I use for periodic, air-gapped backups. I
>> use /dev/disk/by-label for it. With that support being removed (or
>> rather, problematic for some system configurations), which method is
>> most future-proof? I saw mention of UUIDs; is that what we should switch to?
>>
>> In my case, it's a removable drive so it may be assigned to something
>> besides sdc at times.
> 
> If it is a removable drive, you probably do *not* have it set to mount
> on bootup, correct?
> 
> If so, none of this applies to you since the udev-provided symlinks
> will be available to you.
> 
I didn't think about that, actually. Yeah, I don't expect it on boot up
since I don't have a regular backup schedule. I just plug it in, run a
script, sync and unmount.

Still, I learned about LABEL= and UUID= with vanilla fstab. Good stuff
to know.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] GLEP RFC: Third-party contributions

[Daniel Campbell]

On 10/28/2016 06:53 AM, Rich Freeman wrote:
> On Fri, Oct 28, 2016 at 12:49 AM, Daniel Campbell  wrote:
>> On 10/27/2016 06:13 AM, Michał Górny wrote:
>>>
>>> So yes, it would probably be enough to put such a simple statement
>>> somewhere. The problem is: where? ;-) GLEP seemed like a
>>> straightforward solution to make it global.
>>>
>>
>> Could it be relevant on the git workflow page? I consult that on a
>> regular basis (it's even in my watch list), and accepting/pushing
>> contributions seems like it's right in line with our expected git workflow.
>>
> 
> I think that the git workflow page is probably a good place to
> consolidate developer-focused (or serious-contributor-focused)
> information.  I don't think it is a great place to point outside
> contributors.
> 
> An external contribution has a few parts:
> 1.  External contributor submits contribution.
> 2.  Somebody makes sure it is good.
> 3.  The contribution makes it into a repository official branch.
> 
> Part 3 and possibly part 2 might belong on that git workflow page.  I
> think part 1 really needs to be on a "how to contribute" page that is
> really focused on outsiders.
> 
> Of course, having an overall git workflow that is inclusive of both
> internal and external contributions where it comes to the actual
> Gentoo dev doing the commits seems like a good idea.
> 
+1

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature