[gentoo-dev] Last rites: sys-apps/turbotail

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Just use coreutils' tail.
# Bug #559510
sys-apps/turbotail

-- 
Dion Moult

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Todd Goodman]

* Michael Orlitzky  [150923 08:31]:
> On 09/23/2015 04:40 AM, Todd Goodman wrote:
> > 
> > We haven't had too many problems with it.  Most of our problems seem to
> > be with people having issues with git itself (it was new to almost
> > everyone on the team) and not embracing a good workflow with it (or
> > trying to only use git via Eclipse.)
> > 
> > We have 80 or so Android repos and a much smaller handful of proprietary
> > repos in use.
> > 
> 
> Sorry to harp on this, but does your single gerrit user have write
> access to all 80 of your repos? Yours is internal so the risk is
> limited, but naturally, if we set one up, it would have to be public.

No, there are Projects (repos) which can have project owners and other
levels of permissions.  There's no need to allow wide open access.

We do have most of our small set of developers able to push reviews for
any of our repos but nothing can be committed without review so people
don't tend to "stupid" things (it's also a company so there's the whole
"do something stupid and you're likely to lose your job.")

Some branches are set up to require "gatekeeper" approval in addition to
reviewer approval.  And as I mentioned it's tied into our bug tracking
system as well so one can't even push a review unless the ticket has had
appropriate fields filled out, etc.

> 
> If there's a bug in the web UI somewhere and someone figures out how to
> make it run code, that would put all of our repos at risk. Even without
> being able to run code, a bug might allow privilege escalation: someone
> outside the e.g. portage project might figure out how to push to that
> repo because all of the logic is in Java and not the filesystem.

Yes, as I said we haven't had any formal security audit conducted.

I'd personally expect exploits against Google's accessible Gerrit
instances, but that's obviously not a formal security audit either.

For security of large chunks of software you either pay someone to
perform a formal security audit of it for you or else you get as many
people as you can that you trust to do so.

To me, it's a similar problem to your web server or database or anything
else running on a machine that's on a network.

> 
> The way we have it now, push access is granted through SSH and is
> therefore tied to your user. Implementing users/groups/permissions in
> code would really be a step backwards; this isn't a theoretical argument.

I'm certainly not arguing for or against Gentoo using Gerrit.  It was
mentioned and I just brought up my experience with it.

Though I don't see it as a step backwards.  A user authenticates in
either case and gets permissions based upon that.

Either you trust the authentication mechinism in each case or you don't.

Yes, I agree more complicated permission systems have the ability to
cause problems if set up improperly.

But with both SSH and Gerrit your authentication and permissions are "in
code."

> 
> These issues can totally be fixed -- I'm not saying they're endemic to
> web-based git hosting. But to move access control down to the filesystem
> deviates from how everyone else does things. So first you need to spend
> time getting familiar with the project, then you have to overhaul the
> way it works, and finally you have to get upstream to acknowledge that
> you aren't crazy and accept your docs/patches. That's a lot more work
> than just setting it up.

I don't understand why you said earlier the access control was in code
and now you're saying it's moved to the filesystem?

Filesystem access control for Gerrit is the most basic form you'd use
for any system.  e.g., database files are accessible to the database
user/group only not to anyone else and then per user/group access is
controlled via the "in code" methods.

Again, I'm not arguing for or against Gerrit, just relating my
experience with it.

Todd

[gentoo-dev] Last rites: net-im/birdie

[Dion Moult]

# Dion Moult  (24 sep 2015)
# masked for removal in 30 days.
# upstream dead. functionality bugs. bug #553356
net-im/birdie

-- 
Dion Moult

[gentoo-dev] Last rites: net-wireless/rtl8180

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Bug #547406
# Package no longer builds, module now in kernel.
net-wireless/rtl8180

-- 
Dion Moult

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[wireless]

On 09/24/2015 09:59 AM, Todd Goodman wrote:


Again, I'm not arguing for or against Gerrit, just relating my
experience with it.


Hello Todd,

I'm not a dev, but I have over a dozen ebuilds I have hacked together.
They need work, and there are devs who are helping me. Some of these
ebuilds are becoming quite large, due to the numerous jars or the
extensive configuration of the initial config file setup. I enjoy the
learning and hacking part, but gentoo's tool collection presents itself 
as somewhat disjointed, imho.



If a  collection of overlays could be used to setup a prototype
of Gerrit, then, I'd be willing to participate in fully exploring Gerrit
and its use to 'unify' the  development effort between user hacked 
ebuilds and the portage tree. There is currently no well defined path 
for hackers to become contributors and maybe eventually devs, the flux 
is even more partitioned with github now in the mixxx. If Gerrit could 
unify (like an integrated, experimental restructuring of the devmanual 
into)the workflow tools, I think Gerrit could become a wonderful 
addition to gentoo. Maybe a prototype effort will allow the Gerrit 
community within Gentoo to flush out issues before being formally 
proposed to the larger gentoo dev community?



The devmanual, at least the version used by hackers  and those learning 
'the gentoo way' to create ebuilds, should become more open to 
enhancements, details and examples; and who is more qualified to make 
those mods than folks trying to use the devmanual to get codes stable 
and maybe eventually into the portage tree?  The current devmanual is 
good, if you know what you are doing; a bit weak in the teaching by 
example category, particularly for current and recent issues.



curiously,
James

[gentoo-dev] Last rites: net-news/yarssr

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Upstream dead.
# Bug #551282
net-news/yarssr

-- 
Dion Moult

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Todd Goodman]

* James Le Cuirot  [150924 04:55]:
> On Wed, 23 Sep 2015 21:55:00 -0700
> Daniel Campbell  wrote:
> 
> > I hadn't thought about that angle. If our access backbone is via SSH
> > (and thus the filesystem/machine users) then I'm really not sure how
> > to implement a GitLab or Gerrit instance while hooking into the
> > filesystem. Allowing users to open accounts in order to post bugs, etc
> > just isn't a great idea, imo, and duplicates the effort that already
> > exists in Bugzilla. Maybe it'd be smarter to find a way to `git-am`
> > patches from Bugzilla.
> 
> GitLab can feed off LDAP. Once logged in, the user can add an SSH key
> against the account in much the same way as GitHub. It still uses a
> shared git account for the SSH connection though.
> 
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer

Gerrit can get usernames, etc from LDAP as well.

You can then add SSH keys to use when pushing reviews (or whatever else
has been set up.)

Todd

[gentoo-dev] Last rites: app-cdr/nero

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days.
# Upstream disappeared. Bug #510594
app-cdr/nero

-- 
Dion Moult

[gentoo-dev] Last rites: app-crypt/aesutil

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days.
# Upstream disappeared. Bug #528020
app-crypt/aesutil

-- 
Dion Moult

[gentoo-dev] Last rites: gnome-extra/zeitgeist-datahub

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Obsoleted and uninstallable.
# Bug #553182
gnome-extra/zeitgeist-datahub

-- 
Dion Moult

[gentoo-dev] Last rites: dev-python/twistedsnmp

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days.
# Obsoleted in new pysnmp. Bug #513092
dev-python/twistedsnmp

-- 
Dion Moult

[gentoo-dev] Last rites: sci-chemistry/babel

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Bug #552284
# Upstream disappeared. Use sci-chemistry/openbabel instead.
sci-chemistry/babel

-- 
Dion Moult

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[James Le Cuirot]

On Wed, 23 Sep 2015 21:55:00 -0700
Daniel Campbell  wrote:

> I hadn't thought about that angle. If our access backbone is via SSH
> (and thus the filesystem/machine users) then I'm really not sure how
> to implement a GitLab or Gerrit instance while hooking into the
> filesystem. Allowing users to open accounts in order to post bugs, etc
> just isn't a great idea, imo, and duplicates the effort that already
> exists in Bugzilla. Maybe it'd be smarter to find a way to `git-am`
> patches from Bugzilla.

GitLab can feed off LDAP. Once logged in, the user can add an SSH key
against the account in much the same way as GitHub. It still uses a
shared git account for the SSH connection though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[gentoo-dev] Last rites: dev-lang/gpc

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Abandoned upstream and ancient.
# Bug #559430
dev-lang/gpc

-- 
Dion Moult

[gentoo-dev] Last rites: dev-util/bunny

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Deprecated upstream. Please use
# app-forensics/afl instead. Bug #544794
dev-util/bunny

-- 
Dion Moult

[gentoo-dev] Last rites: dev-lang/path64

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days.
# Broken and replaced by dev-lang/ekopath. Bug #559510
dev-lang/path64

-- 
Dion Moult

[gentoo-dev] Last rites: sci-chemistry/icm-browser

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Bug #466724
# Heavily out of date. Use sci-chemistry/icm
sci-chemistry/icm-browser
-- 
Dion Moult

[gentoo-dev] Last rites: net-dialup/intel-536ep

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Bug #426012
# Outdated kernel support, licensing issues.
net-dialup/intel-536ep

-- 
Dion Moult

[gentoo-dev] Last rites: dev-ada/polyorb

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Bug #216244
# Outdated and does not compile due to upstream bug.
dev-ada/polyorb

-- 
Dion Moult

[gentoo-dev] Last rites: sci-geosciences/josm-plugins

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Bug #472002
# Can't keep up with upstream changes.
sci-geosciences/josm-plugins

-- 
Dion Moult

[gentoo-dev] Last rites: dev-embedded/scratchbox-toolchain-cs*

[Dion Moult]

# Dion Moult  (24 Sep 2015)
# Masked for removal in 30 days. Outdated toolchains. Bug #549364
dev-embedded/scratchbox-toolchain-cs2005q3_2-glibc2_5
dev-embedded/scratchbox-toolchain-cs2007q3-glibc2_5
dev-embedded/scratchbox-toolchain-cs2009q1-203sb1
dev-embedded/scratchbox-toolchain-cs2009q1-eglibc2_8
dev-embedded/scratchbox-toolchain-cs2009q3-eglibc2_10

-- 
Dion Moult

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Leno Hou]

On Fri, Sep 11, 2015 at 8:01 PM, Leno Hou  wrote:

>
> 2. We believe to make Gentoo support ppc64le, we still need to compile
> kernel and bootloader
>
>- Which version of kernel provided by Gentoo would you suggest us to
>use?
>
>   As to Ubuntu, there will be many patches to make the kernel
> workable, so how to patch
>   our Gentoo kernel  to make it work for ppc64le?
>

Upstream's 4.2.1 is OK  :-)
I've compiled sys-kernel/gentoo-sources-4.2.1 on Ubuntu and
successfully booted  Ubuntu as following.
root@ppc64le:~# uname -a
Linux ppc64le 4.2.1-gentoo #1 SMP Wed Sep 23 19:28:17 PDT 2015
ppc64le ppc64le ppc64le GNU/Linux


>- Which version of grub suitable for ppc64le ?  Is there any patches
>to ppc64le grub ?
>
> 3. When the gentoo we make out workable on ppc64le, we would like to know
> the process of
> making it officially supported by Gentoo community
>
>- For each arch, do we have a subteam to verify the packages? If so,
>how to reach these guys?
>- For hardware environment, does anyone have Power8 systems ?
>
>  Again, please apply POWER8 Systems and join our work  :-)
 [1]: https://www.runabove.com/instances/ibm-power8.xml
 [2]: https://ptopenlab.com/cloudlabconsole/#/
 [3]: http://osuosl.org/services/powerdev/request_hosting


> -Leno Hou
>

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 14 Aug 2015 15:52, Leno Hou wrote:
> On Wed, Aug 12, 2015 at 3:47 PM, Mike Frysinger wrote:
> > On 12 Aug 2015 15:20, Leno Hou wrote:
> > > **Most importantly, Any Ideas/steps of how to  porting gentoo on  ppc64le
> > > architecture?**
> >
> > do you have hardware ?  then it's simply a matter of booting Gentoo in it
> > and
> > filing/fixing bugs :).
> >
> 
> YES. We have KVM virtual machine of ppc64le.  Can we booting/filing/fixing
> by KVM ?

KVM is fine.  i'm assuming you can't boot a ppc64le vm when the host is
ppc64be ?  i don't think any Gentoo dev has access to ppc64le hardware,
so we'd rely on ibm to fix bugs and such.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

On 25 Sep 2015 10:32, Leno Hou wrote:
> On Thu, Sep 24, 2015 at 11:07 PM, Mike Frysinger wrote:
> > On 14 Aug 2015 15:52, Leno Hou wrote:
> > > On Wed, Aug 12, 2015 at 3:47 PM, Mike Frysinger wrote:
> > > > On 12 Aug 2015 15:20, Leno Hou wrote:
> > > > > **Most importantly, Any Ideas/steps of how to  porting gentoo on
> > > > > ppc64le architecture?**
> > > >
> > > > do you have hardware ?  then it's simply a matter of booting Gentoo in
> > > > it and filing/fixing bugs :).
> > >
> > > YES. We have KVM virtual machine of ppc64le.  Can we
> > > booting/filing/fixing by KVM ?
> >
> > KVM is fine.  i'm assuming you can't boot a ppc64le vm when the host is
> > ppc64be ?
> 
> We can boot ppc64le by KVM on POWER7  (abbrev. PowerKVM)
> and KVM on Power7 is big endian. If you have real POWER7 hardware,

we have a Gentoo box running on a POWER7 from IBM:
IBM,8231-E2B POWER7 32 x 3.5GHz

it has KVM enabled in it.  so i guess we should be able to start a LE
instance in KVM there.

> you can install Ubuntu or RedHat ( integrated with KVM by default) on
> POWER7.

are you really making this suggestion on a Gentoo list ? ;)
booting other distros isn't generally interesting to us.
don't you already have a Gentoo instance booting ?
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Leno Hou]

On Thu, Sep 24, 2015 at 11:07 PM, Mike Frysinger  wrote:

> On 14 Aug 2015 15:52, Leno Hou wrote:
> > On Wed, Aug 12, 2015 at 3:47 PM, Mike Frysinger wrote:
> > > On 12 Aug 2015 15:20, Leno Hou wrote:
> > > > **Most importantly, Any Ideas/steps of how to  porting gentoo on
> ppc64le
> > > > architecture?**
> > >
> > > do you have hardware ?  then it's simply a matter of booting Gentoo in
> it
> > > and
> > > filing/fixing bugs :).
> > >
> >
> > YES. We have KVM virtual machine of ppc64le.  Can we
> booting/filing/fixing
> > by KVM ?
>
> KVM is fine.  i'm assuming you can't boot a ppc64le vm when the host is
> ppc64be ?


We can boot ppc64le by KVM on POWER7  (abbrev. PowerKVM)
and KVM on Power7 is big endian. If you have real POWER7 hardware,
you can install Ubuntu or RedHat ( integrated with KVM by default) on
POWER7.



> i don't think any Gentoo dev has access to ppc64le hardware,
> so we'd rely on ibm to fix bugs and such.
>

As above, we can boot ppc64le by KVM on POWER7. Is not mean that we can
booting/filing/fixing by KVM? If so, i'll try to get some KVM virtual
machines :-)


-mike
>

-Leno Hou