Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Roy Bamford
On 2020.08.10 16:22, William Hubbs wrote:
> On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> > On 8/8/2020 14:51, William Hubbs wrote:
> > > All,
> > > 
> > > I would like to propose that we switch the default udev provider
> on new
> > > systems from eudev to udev.
> > > 
> > > This is not a lastrites, and it will not affect current systems
> since
> > > they have to migrate manually. Also, this change can be overridden
> at
> > > the profile level if some profile needs eudev (the last time I
> checked,
> > > this applies to non-glibc configurations).
> > > 
> > > What do people think?
> > > 
> > > Thanks,
> > > 
> > > William
> > 
> > Is eudev broken in some way?  If so, has a bug been filed?  If not,
> why not?
> > 
> > If eudev is not broken, then why your proposed fix?
> 
> bitrot and bus factor.
> 
> > It works fine for new installs, having just done one myself.  Seems
> like we
> > aught to keep it that way.  I count six open bugs against eudev
> right now,
> > and none of them look to be critical, so I vote "no" on your
> proposal unless
> > there is some verifiable reason why eudev is no longer suitable to
> be the
> > default udev provider.
> 
[snip] 
> ...because of fear of
> what
> the udev devs might do. That fear never came true.
> 
[snip]
> 
> William
> 

William,

Never is a very long time.
That promise has not been made good ... yet.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpshyF9TLPFs.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Roy Bamford
On 2020.08.08 23:22, Rich Freeman wrote:
> On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford 
> wrote:
> >
> > With the declared aim from upstream of making udev inseparable from
> > systemd, its not something to be done lightly.
> > That's the entire reason that eudev was necessary.
> >
> > I would want some convincing that it was not another step on the
> road
> > to Gentoo being assimilated by systemd.
> 
> So, I really could care less what the default is since it won't impact
> any of my Gentoo hosts either way, ..
[snip]
> 
> -- 
> Rich
> 

Rich,

I don't have a dog in this fight. Being old and cynical, I have static /dev,
so I use neither.

I'm interested in what's changed since the Council decision [1] to make 
eudev the default.

[1] https://bugs.gentoo.org/573922#c28

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgp8OZnGNadvH.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Roy Bamford
On 2020.08.08 19:51, William Hubbs wrote:
> All,
> 
> I would like to propose that we switch the default udev provider on
> new
> systems from eudev to udev.
> 
> This is not a lastrites, and it will not affect current systems since
> they have to migrate manually. Also, this change can be overridden at
> the profile level if some profile needs eudev (the last time I
> checked,
> this applies to non-glibc configurations).
> 
> What do people think?
> 
> Thanks,
> 
> William
> 
> 

William,

With the declared aim from upstream of making udev inseparable from 
systemd, its not something to be done lightly.
That's the entire reason that eudev was necessary.

I would want some convincing that it was not another step on the road
to Gentoo being assimilated by systemd.

We had this discussion several years ago when the default became 
eudev. What's changed?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpb6AvBiQ28_.pgp
Description: PGP signature


Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-20 Thread Roy Bamford
On 2020.06.20 05:58, Aaron Bauman wrote:
> > # Aaron Bauman  (2020-06-20)
> > # Py2 only
> > # Removal in 14 days

[list of stuff]

> 
> -- 
> Cheers,
> Aaron
> 

Aaron,

If everything that needs python2 is being removed,
why not python2 itself?

Al least, python2  is not on your list.

Be first into the future by masking this stuff and
Last out of the past by leaving up to users to decide.
It could stay in the tree, masked, as long as python2.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgp9CIkLXPSD0.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Foundations Trustee Election 2020 - Election Team Formation

2020-06-17 Thread Roy Bamford
On 2020.06.17 10:40, David Abbott wrote:
> On Wed, Jun 17, 2020 at 5:08 AM Roy Bamford 
> wrote:
> >
> > Team,
> >
> > Its time to kick off the Trustee Election for this year.
> >
> > It will span June 21 to about August 3.
> > We need two or three election officials and an infra contact to
> staff this election.
> >
> > If you will be available and have a little free time in that period
> recruiting is now open.
> > Potential candidates should not apply.
> >
> > --
> > Regards,
> >
> > Roy Bamford
> > (Neddyseagoon) a member of
> > elections
> > gentoo-ops
> > forum-mods
> > arm64
> 
> Hi Roy,
> I can help out.
> Regards,
> 
> -- 
> David Abbott (dabbott)
> 
> 

David,

Thank you. I've signed you up at 
https://wiki.gentoo.org/wiki/Project:Elections/Trustees/202006

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpuDUKOvE2Vu.pgp
Description: PGP signature


[gentoo-dev] Gentoo Foundations Trustee Election 2020 - Election Team Formation

2020-06-17 Thread Roy Bamford
Team,

Its time to kick off the Trustee Election for this year.

It will span June 21 to about August 3. 
We need two or three election officials and an infra contact to staff this 
election.

If you will be available and have a little free time in that period recruiting 
is now open.
Potential candidates should not apply.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpzBD_87RDHL.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials

2020-05-30 Thread Roy Bamford
On 2020.05.30 13:14, Rich Freeman wrote:
> On Sat, May 30, 2020 at 6:09 AM Roy Bamford 
> wrote:
> >
> > We sill need more volunteers.
> >
> 
> Not going to be running, so I'm happy to pitch in.
> 
> -- 
> Rich
> 
> 
> 

Rich,

Thank you.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgps3MQbFCaNk.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials

2020-05-30 Thread Roy Bamford
On 2020.05.29 21:10, David Abbott wrote:
> On Fri, May 29, 2020 at 4:03 PM Roy Bamford 
> wrote:
> >
> > Team,
> >
> > Our current council will hold their last meeting on 14-Jun-20.
> > We therefore need to elect a new council before the July meeting.
> >
> > To do this, I'm calling for three volunteers to be election
> officials and an
> > infra member to be the infra contact.
> >
>
... 
[snip]
> >
> > --
> > Regards,
> >
> > Roy Bamford
> > (Neddyseagoon) a member of
> > elections
> > gentoo-ops
> > forum-mods
> > arm64
> 
> Hi Roy,
> Count me in.
> Regards,
> 
> -- 
> David Abbott (dabbott)
> 
> 
David,

Thank you. The election page is up now.
https://wiki.gentoo.org/wiki/Project:Elections/Council/202006

We sill need more volunteers.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpfHGn3U4xxH.pgp
Description: PGP signature


[gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials

2020-05-29 Thread Roy Bamford
Team,

Our current council will hold their last meeting on 14-Jun-20.
We therefore need to elect a new council before the July meeting.

To do this, I'm calling for three volunteers to be election officials and an 
infra member to be the infra contact.

The timeline, still exactly to be determined will span just over 4 weeks.
Two weeks nominations, a few days for infra to set up the ballot on
Woodpecker, two weeks for voting followed by a few days to check 
results.

The timeline I have in mind is nominations open at midnight between 
5/6 Jun. and close at midnight 19/20 Jun. 
Voting starts Midnight 22/23 June and runs until midnight 6/7 July.
Results announced a few days later.

Election officials monitor the project ML for nominations and update 
the election Wiki page to keep track of nominations, acceptances and
manifestos.
Once the votes are in, they rank the results and compare notes.
They should also join #gentoo-elections on freenode. 

Please don't volunteer to support the election if you plan to run.
Candidates may not be election officials.

For completeness, only three election officials are required, so with
myself, we will have a spare. That's good, every now and again,
real life can intervene at the last moment. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpQSMgQtzZQs.pgp
Description: PGP signature


Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Roy Bamford
On 2020.04.07 09:48, Ulrich Mueller wrote:
> >>>>> On Tue, 07 Apr 2020, Samuel Bernardo wrote:
> 
> > No assurance is also a level that takes place in the lower ranking
> > level. If someone needs to use zoom because they are demanded by
> their
> > boss I think that would be even more useful to know that it is
> possible
> > to install zoom in Gentoo and that is rated as the worst possible
> > software. Maybe this would allow others to join our zoom claim...
> 
> We could add a README.gentoo file with our caveats. It won't be
> perfect,
> but maybe better than nothing. (And certainly better than displaying a
> warning on every upgrade, which will eventually annoy people [1].)
> 
> Any suggestions for a wording?
> 
> Ulrich
> 
> 
> [1] https://bugs.gentoo.org/416769
> 

Team,

Just 'No.' 

Its not useful to anyone to single out a single binary only package 
for special treatment.

Lets compare zoom to firefox-bin as a worked example.
Nobody except Mozilla knows whats in firefox-bin. Gentoo doesn't 
build it, its the official Mozilla binary build.

Mozilla distubute source code too. There is no assurace that they 
are the sources used to build firefox-bin.

Over the years Firefox has had its share of CVEs.
How is firefox-bin any different to zoom?

I've only selected firefox-bin as a worked example. There are other 
binary packages in ::gentoo. In the same boat.

They all need to be treated consistently.


Then there is the question of the liability exposure.
There are two prongs to this.

a) any advice will be incomplete and or out of date.
That will damage trust.

b) one day, it will be plain wrong and zoom or whoever will get very 
upset and be able to prove it.

Its OK to publish advice based on beliefs or opinions, there is no 
requirement for beliefs or opinions to be based on fact but we are
not discussing beliefs or opinions here.

In summary, we can't be sure of our facts. We can't be sure that 
any warning complete and correct.

Gentoo must not single out any package for special treatment.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpv44y3BnnyV.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-05 Thread Roy Bamford
On 2020.01.04 13:43, Thomas Deutschmann wrote:
> On 2020-01-04 14:08, Roy Bamford wrote:
> > emerge -1 vanilla-sources
> > eselect kernel ...
> > genkernel all
> > ...
> 
> Please tell user to do
> 
> genkernel --kernel-config=/proc/config.gz all
> 
> by default which will give them a better experience because new kernel
> will be build based on kernel configuration from current running
> kernel.
> Without providing a kernel config, user will probably fall back to
> generic configuration which isn't intended for daily usage.
> 
> 
> -- 
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
> 
> 

Thomas,

Ten years ago the user did 
genkernel all 
and used the default .config provided with genkernel.

Today, genkernel --kernel-config=/proc/config.gz all does not improve 
that config.

genkernel --kernel-config=/proc/config.gz all 
perpetuates the existing .config which is only useful if its not an 
earlier generic configuration.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpjhN8CA5bom.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Roy Bamford
On 2020.01.04 12:54, Rich Freeman wrote:
> On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford 
> wrote:

[snip]
> 
> Apparently git and tar are too complicated for Gentoo users, but
> managing symlinks, using make, managing a bootloader, dealing with the
> kernel's configuration system, and so on are just fine?

emerge -1 vanilla-sources
eselect kernel ...
genkernel all
...

Yep, lots of users have trouble managing their boot loader. They come to
the forums and IRC every day not running the kernel they think they are.
That's not related to any particular kernel sources though.

[snip]

> 
> On a further aside, I just noticed how up-to-date gentoo-sources are.
> Kudos to whoever is doing that these days - for a while it was tending
> to slip a bit but it seems like we're basically current.

+1

> 
> -- 
> Rich
> 
> 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpOaAY6RX0hb.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Roy Bamford
On 2020.01.04 11:01, Rich Freeman wrote:
>
> Is there some reason that we should keep vanilla sources despite not
> getting security handling?
> 
> -- 
> Rich
> 

Rich,

Gentoo had this discussion before. The outcome was that 
vanilla-sources is just as Linus intended.
If Gentoo did anything to it, it wouldn't be vanilla any longer.

Yes, it should be kept. We should not force users to learn
git or tar.

I agree git or a tarball of vanilla-sources is faster and more
efficient but that's not a reason to drop it.
By the same argument we could drop linux-firmware too.
There are probably other packages that only install whatever
they fetch. Could they be dropped?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpNeBPcQXuuf.pgp
Description: PGP signature


Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags

2019-10-01 Thread Roy Bamford
On 2019.09.10 21:44, Michał Górny wrote:
> Hi, everyone.
> 
> I've recently (finally!) started adding tests to cpuid2cpuflags. 
> Tests
> are based on mocked syscalls that return arch-specific data read from
> text files.  So far I've got x86 and ppc covered, and now I'd like to
> add tests for various arm hardware.  Since ARM covers a pretty broad
> range of hardware, I'd use as much data as possible, especially from
> different ARM generations.
> 
> If you have an ARM board and would like to help, please:
> 
> wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2
> tar -xf cpuid2cpuflags-7-dev.tar.bz2
> cd cpuid2cpuflags-7-dev
> ./configure
> make hwcap-dump
> ./hwcap-dump
> 
> and send me the output along with 'uname -m'.  TIA!
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

Team, this is going to be a long rambling tale of woe. Sorry in advance.
On arm64 cpuid2cpuflags-8 tells me
  
Pi4_~arm64 /usr/portage # cpuid2cpuflags 
CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 crc32 v4 v5 v6 v7 v8 
thumb2

but by chance I hit 
[Bug 695854] net-misc/freerdp-2.0.0_rc4 on arm64 - 
aarch64-unknown-linux-gnu-gcc: error: unrecognized command line option 
‘-mfpu=neon’

The 32 bit arm instruction set is optional on arm64.
The 64 bit Raspberry Pis all have it
The Cavium Thunder does not.

It is unlikely that there will ever be a multilib arm64. Only a subset
of arm64 could ever support it, so should we be using CPU_FLAGS_ARM
to cover arm64 too?

There is nothing in the name. Its the content that matters.

On a Pi4 in 64 bit mode, cpuinfo shows
Pi4_~arm64 /usr/portage # cat /proc/cpuinfo 
processor   : 0
BogoMIPS: 108.00
Features: fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd08
CPU revision: 3

In 32 bit mode, the same CPU shows
$ cat pi4_32.txt 
processor   : 0
model name  : ARMv7 Processor rev 3 (v7l)
BogoMIPS: 108.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm crc32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd08
CPU revision: 3


Cavium (64 bit)
arm64-build / # cat /proc/cpuinfo 
processor   : 0
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part: 0x0a1
CPU revision: 1

The Cavium does not have any 32 bit instructions.

From bug 695854, CPU_FLAGS_ARM: neon is not correct on the Cavium.
I suspect that the other 32 bit flags will fail there, as it does not have them
but they might work on the Pi, as it does.

Other than pointing out the problem, I don't know how to test further. 
Guidance welcome.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgp5Xqz7kShdv.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Roy Bamford
Hi Michał,
 
On 2019.08.31 09:03, Michał Górny wrote:
> Hello,
> 
> We still have a lot of packages that are keyworded ~x86/x86 but were
> never keyworded ~amd64.  While I suppose there might be exceptions to
> that, in most cases it means that simply nobody has been using it for
> years.

x86, the 32 bit variety, is still popular at the low power end of the spectrum
for things like network appliances. Not the sort of hardware you would
play many games on these days. 

Proceed with caution. Mask them and leave them in the tree. Wait and
see who shouts, if anyone.

Low power systems don't get updated terribly regularly, so be prepared 
to leave the packages in the tree for a lot longer than the customary 30
days.
 
> 
> Many of them are still at EAPI 0; some were ported to newer EAPIs
> specifically to clean old EAPIs.
> 
> I've already cleaned up some false positives (like svgalib).  If you
> know more, please let me know.
> 
> I have mixed feelings about games on the list.  On one hand, it's
> rather
> obvious that they're x86 binary games.  However, if somebody actually
> used them, they would have probably gained amd64 multilib compat by
> now.


> 
> ---
>
[snip list]
> 
> -- 
> Best regards,
> Michał Górny
> 
> 


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgp66BNhk29KZ.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-17 Thread Roy Bamford
On 2019.07.17 14:25, Michał Górny wrote:
> Hello,
> 
> The QA team would like to introduce the following policy:
> 
> """
> Packages must not disable installing manpages via USE flags (e.g.
> USE=man or USE=doc).  If upstream does not ship prebuilt manpages
> and building them requires additional dependencies, the maintainer
> should build them and ship along with the package.
> """
> 
> 
> Explanatory note:
> 
> This applies to having USE flags that specifically control building
> manpages.  It obviously does not affect:
> 
> a. USE flags that disable building both a program and its manpage
> (e.g.
> if USE=gui disables building gfrobnicate, not installing
> gfrobnicate(1)
> is correct),
> 
> b. use of LINGUAS to control installed manpages.
> 
> 
> Rationale:
> 
> Manpages are the basic form of user documentation on Gentoo Linux. 
> Not
> installing them is harmful to our users.  On the other hand, requiring
> additional dependencies is inconvenient.  Therefore, packaging
> prebuilt
> manpages (whenever upstream doesn't do that already) is a good
> compromise that provides user with documentation without additional
> dependencies.
> 
> 
> What are your comments?
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

Michał,

This works on systems with plenty of resources.
I suspect very few arm users have man/doc/info pages installed.
FEATURES="noman nodoc noinfo" is less than ideal as everything 
is still built, so you pay the build time, but not installed.

Does anyone read documentation on embedded class hardware?
I know I don't. 

Personally, I don't build much on embedded hardware either but I'm 
aware of users that do.

I like to have the choice to not build documentation on low power
systems. Its a part of Gentoos flexibility that should not be removed.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpsuZgzBJDUh.pgp
Description: PGP signature


Re: [gentoo-dev] [News item review] amd64 17.1 profiles are now stable

2019-05-19 Thread Roy Bamford
On 2019.05.19 07:59, Michał Górny wrote:
> Hi,
> 
> As discussed during the Council meeting, I'm sending an updated news
> item for 17.1 profile migration.  This item will be published along
> with
> the profiles being marked stable, and the old one will be removed.
> 
> Besides removing all references to the profiles being 'experimental',
> I've reformatted and updated the text to be a little more clear about
> the new design.
> 
> ---
> Title: amd64 17.1 profiles are now stable
> Author: Michał Górny 
> Posted: 2019-05-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/amd64/13.0
> Display-If-Profile: default/linux/amd64/13.0/selinux
> Display-If-Profile: default/linux/amd64/13.0/desktop
> Display-If-Profile: default/linux/amd64/13.0/desktop/gnome
> Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd
> Display-If-Profile: default/linux/amd64/13.0/desktop/plasma
> Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd
> Display-If-Profile: default/linux/amd64/13.0/developer
> Display-If-Profile: default/linux/amd64/13.0/no-multilib
> Display-If-Profile: default/linux/amd64/13.0/systemd
> Display-If-Profile: default/linux/amd64/17.0
> Display-If-Profile: default/linux/amd64/17.0/selinux
> Display-If-Profile: default/linux/amd64/17.0/hardened
> Display-If-Profile: default/linux/amd64/17.0/hardened/selinux
> Display-If-Profile: default/linux/amd64/17.0/desktop
> Display-If-Profile: default/linux/amd64/17.0/desktop/gnome
> Display-If-Profile: default/linux/amd64/17.0/desktop/gnome/systemd
> Display-If-Profile: default/linux/amd64/17.0/desktop/plasma
> Display-If-Profile: default/linux/amd64/17.0/desktop/plasma/systemd
> Display-If-Profile: default/linux/amd64/17.0/developer
> Display-If-Profile: default/linux/amd64/17.0/no-multilib
> Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened
> Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened/selinux
> Display-If-Profile: default/linux/amd64/17.0/systemd
> 
> A new set of 17.1 amd64 profiles has been added to the Gentoo
> repository in Dec 2017.  These profiles switch to a more standard
> 'no SYMLINK_LIB' multilib layout, 

[snip]

> 
> For more information on the layout, please see the wiki article
> on AMD64 multilib layouts [2].
> 
> [1]:https://bugs.gentoo.org/506276
> [2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
> 
> -- 
> Best regards,
> Michał Górny
> 
> 
> 
> 
> 

Team,

"These profiles switch to a more standard 'no SYMLINK_LIB' multilib" 
layout,

Does that mean that no migration action is required by /no-multilib/ users?
I notice that no-multilib users will get the news item.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpuEgHshod8P.pgp
Description: PGP signature


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Roy Bamford
On 2019.03.22 20:32, Piotr Karbowski wrote:
> Hi,
> 
[snip]

> - We should go back to +suid -elogind default.
> - We should actually NOT put suid on Xorg if USE="suid elogind" but
> put
> suid bit with USE="suid -elogind".
> - We should only ever enable elogind in desktop profiles.
> 
> Personally I'd like to stay without enabling suid by default on
> xorg-server, as otherwise hardly anyone will ever drop the suid from
> it,
> which would be a big step back. Gentoo tried to drop suid from
> xorg-server a handful of times, let's make the current one a final one
> :)
> 
> I'd like to propose doing the following:
> 
> - Keywording elogind on missing archs
> - Making elogind a global USE flag
> - Switching desktop profiles to elogind from consolekit while still
> preserving -suid +elogind on xorg-server for those that does not use
> desktop profiles (systemd profiles users not affected)
> - Making pambase always install the configuration for pam_elogind.so,
> the same way it does for pam_gnome_keyring.so at this very moment,
> effectively removing elogind USE flag from it.
> 
> What do you all think about?
> 
> -- Piotr.
> 

This looks broken by default.
[ebuild   R] x11-base/xorg-server-1.20.4:0/1.20.4::gentoo  USE="doc glamor 
ipv6 udev xorg xvfb -debug -dmx (-elogind) -kdrive -libressl -minimal 
(-selinux) -static-libs -suid* -systemd -unwind -wayland -xcsecurity -xephyr 
-xnest" 

elogind is hard masked and suid is being turned off.
Its arm64, so I expect to find a few rough edges.

However, changes like this need to be coordinated across all arches.
Take a pat on the back for the elogind work and a slap on the wrist
if my arm64 systems don't work any more.

Its still building, I'll test later.  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp9X1hZnO3mp.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format

2018-11-30 Thread Roy Bamford
On 2018.11.30 17:06, Michał Górny wrote:
> On Mon, 2018-11-26 at 21:43 +0000, Roy Bamford wrote:
> > On 2018.11.26 18:58, Michał Górny wrote:
> > > Here's the newest version.
> > > 
> > > Changes:
> > > 
> > > - added explicit notion of parent directory (missing in previous
> GLEP
> > > but present in implementation),
> > > 
> > > - explicitly named GNU tar format with list of permitted
> extensions,
> > > 
> > > - changed volume label to 'gpkg-1.txt' file to improve
> portability;
> > > made
> > > it explicit version identifier as well,
> > > 
> > > - added info on other package formats to rationale.
> > > 
> > 
> > [snip]
> > 
> > The image archive stores all the files to be installed by the binary
> > package.  It should be included as the last of the files in the
> binary
> > package container.
> > 
> > [snip]
> > > 
> > > -- 
> > > Best regards,
> > > Michał Górny
> > > 
> > 
> > Its a nit today but that says that any future extensions, none 
> > yet planned, should be placed before the image archive.
> 
> Yes.
> 
> > The specification needs to avoid the use of relative references.
> > 
> 
> I don't understand.  Could you be more specific what you expect
> instead?
> 
> -- 
> Best regards,
> Michał Górny
> 

Michał,

Enumerate the elements, in the preferred order, which you have 
already done. The is no need, in a specification that is intended
to be easily extensible to specify that any element should be last.
That constrains extensions.

To build on an example extension given earlier. Suppose an 
extension came along to add the ebuild, required eclasses and 
sources. The present wording says that they should be included 
before image archive.

Implementations may be capable of working with partial 
downloads, why force the download of elements that may not be
required to get the payload.

The overhead of the presently define elements is small compared
to the image and its useful to be able check the metadata to
determine if the image is really what is required. 

image 'last' works with the presently defined elements but may 
not be so good in the years to come.

Its a subtle difference between 'last', which means always at 
the end, no mater what, and 'fifth' which is last today but
might not be in the future.
 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp_Ox59p3DZ7.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP r3] Gentoo binary package container format

2018-11-26 Thread Roy Bamford
On 2018.11.26 18:58, Michał Górny wrote:
> Here's the newest version.
> 
> Changes:
> 
> - added explicit notion of parent directory (missing in previous GLEP
> but present in implementation),
> 
> - explicitly named GNU tar format with list of permitted extensions,
> 
> - changed volume label to 'gpkg-1.txt' file to improve portability;
> made
> it explicit version identifier as well,
> 
> - added info on other package formats to rationale.
> 
[snip]

The image archive stores all the files to be installed by the binary
package.  It should be included as the last of the files in the binary
package container.

[snip]
> 
> -- 
> Best regards,
> Michał Górny
> 

Its a nit today but that says that any future extensions, none 
yet planned, should be placed before the image archive.

The specification needs to avoid the use of relative references.


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpXu1HdOG3la.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format

2018-11-19 Thread Roy Bamford
On 2018.11.19 19:33, Rich Freeman wrote:
> On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford 
> wrote:
> >
> > "The archive members support optional OpenPGP signatures.
> > The implementations must allow the user to specify whether OpenPGP
> > signatures are to be expected in remotely fetched packages."
> >
> > Or can the user specify that only some elements need to be signed?
> >
> > Is it a problem if not all elements are signed with the same key?
> > That could happen if one person makes a  binpackage and someone
> > else updates the metadata.
> >
> 
> IMO this is going a bit into PM details for a GLEP that is about
> container formats.
> 

Rich,

Not really. The GLEP needs to be clear about the signing.
Is it every element or none?
The GLEP hints that a mix of is possible with
 
If the implementation needs to manipulate archive members, it must
either create a new signature or discard the existing signature.

An individual binpackage could start life with all elements signed
by the same key.

Some element could be updated and the key for the signature of 
that element changed.

Later still, another element can be changed an have its signature
dropped.   

Should some combinations have no practical value, they should
not be permitted by the GLEP.

> -- 
> Rich
> 
> 
> 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpaUbIZBgWaT.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP r1] Gentoo binary package container format

2018-11-19 Thread Roy Bamford
On 2018.11.19 18:35, Michał Górny wrote:
> Hi,
> 
> On Sat, 2018-11-17 at 12:21 +0100, Michał Górny wrote:
> > Here's a pre-GLEP draft based on the earlier discussion on gentoo-
> > portage-dev mailing list.  The specification uses GLEP form as it
> > provides for cleanly specifying the motivation and rationale.
> 
> Changes in -r1: took into account the feedback and restructured
> the motivation into pointing out advantages of the existing format,
> and focusing on the two real issues of non-transparency and OpenPGP
> implementations deficiencies.  Also added a section on why there's no
> explicit version number.
> 
> > Also available via HTTPS:
> > 
> > rst:  https://dev.gentoo.org/~mgorny/tmp/glep-0078.rst
> > html: https://dev.gentoo.org/~mgorny/tmp/glep-0078.html
> > 
> 
[snip]

Team,

Looks good to me. I can manually unpick the binpackage with tar.
Choose, if I will check the signatures or not, then spray files all
over my broken Gentoo with tar in the same way as I do now.

Implementation detail question. 
It appears that all members must be signed, or none of them since
  
"The archive members support optional OpenPGP signatures. 
The implementations must allow the user to specify whether OpenPGP 
signatures are to be expected in remotely fetched packages."

Or can the user specify that only some elements need to be signed?

Is it a problem if not all elements are signed with the same key?
That could happen if one person makes a  binpackage and someone
else updates the metadata.


> -- 
> Best regards,
> Michał Górny
> 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpX6ueFyt3EF.pgp
Description: PGP signature


Fwd: Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gen...@jonesmz.com]

2018-11-18 Thread Roy Bamford
See attached.

Replying off list because I am not on the whitelist ...

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
--- Begin Message ---
On Sun, Nov 18, 2018 at 5:04 AM Roy Bamford  wrote:

> On 2018.11.18 09:38, Michał Górny wrote:
> > On Sun, 2018-11-18 at 10:16 +0100, Fabian Groffen wrote:
> > > On 17-11-2018 12:21:40 +0100, Michał Górny wrote:
> > > > Problems with the current binary package format
>
> [snip]
>
> > > > 2. **The format relies on obscure compressor feature of ignoring
> > > >trailing garbage**.  While this behavior is traditionally
> > implemented
> > > >by many compressors, the original reasons for it have become
> > long
> > > >irrelevant and it is not surprising that new compressors do not
> > > >support it.  In particular, Portage already hit this problem
> > twice:
> > > >once when users replaced bzip2 with parallel-capable pbzip2
> > > >implementation [#PBZIP2]_, and the second time when support for
> > zstd
> > > >compressor was added [#ZSTD]_.
> > >
> > > I think this is actually the result of a rather opportunistic
> > > implementation.  The fault is that we chose to use an extension that
> > > suggests the file is a regular compressed tarball.
> > > When one detects that a file is xpak padded, it is trivial to feed
> > the
> > > decompressor just the relevant part of the datastream.  The format
> > > itself isn't bad, and doesn't rely on obscure behaviour.
> >
> > Except if you don't have the proper tools installed.  In which case
> > the 'opportunistic' behavior made it possible to extract the contents
> > without special tools... except when it actually happens not to work
> > anymore.  Roy's reply indicates that there is actually interest in
> > this
> > design feature.
> >
> [snip]
>
> Team,
>
> I use to post something like https://wiki.gentoo.org/wiki/Fix_My_Gentoo
> with a link to Patricks binhost on the forums every three or four months.
> It made it worth writing that wiki page anyway.
>
> We still get users removing elements of their toolchain or glbc from time
> to time.  The requirement that I didn't express very well, is that it
> shall
> be possible to install binary packages without the use of any Gentoo
> specific tooling.
>
> The current tarball of tarballs proposal would satisfy that requirement.
>
> Its unlikely that a custom binary format would.  Of course, this being
> Gentoo someone would write a run anywhere script that did the
> unpicking, We already have deb2targz and rpm2targz. We have the
> opportunity to design out binpgk2targz before it exists.
>
> --
> Regards,
>
> Roy Bamford
> (Neddyseagoon) a member of
> elections
> gentoo-ops
> forum-mods
>


Replying off list because I am not on the whitelist.

Please also consider my use case:

I have a cluster file system, cephfs, which all of my gentoo machines mount
for access to various shared file resources.

I want to have all of them mount a cephfs path to the folder which portage
is configured to look for binary packages.

This works great if all of the machines have identical portage
configurations, but breaks down as soon as one machine uses a different use
flag.

The reason for this is that the package file names do not encode anything
other than the package name and version number. So if a binpkg already
exists in my binpkg repository, and another machine builds with different
use flags, the binpkg gets overwritten, potentially while a third machine
is reading the binpkg file.

The filename also does not represent compile time dependencies, or any
number of other possible points of differentiation

This issue could be (at least partially) solved at least 3 ways.

1) append a uuid to each filename. Generated when the bin package file is
generated.
2) encode the hostname of the machine that generated the file
3) encode the use flags in the filename.

Perhaps a fuller solution is to respect an environment variable
"BINARY_PKG_FILENAME_FORMAT" that accepts a series of variable
substitutions to append after the package name and version number?

This variable would be used only when generating the binary package.
Portage would still use any binary package that it found that matched its
needs, regardless of suffix.

Thanks for your time.
--- End Message ---


pgpoqDkTyX_48.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format

2018-11-18 Thread Roy Bamford
On 2018.11.18 09:38, Michał Górny wrote:
> On Sun, 2018-11-18 at 10:16 +0100, Fabian Groffen wrote:
> > On 17-11-2018 12:21:40 +0100, Michał Górny wrote:
> > > Problems with the current binary package format

[snip]

> > > 2. **The format relies on obscure compressor feature of ignoring
> > >trailing garbage**.  While this behavior is traditionally
> implemented
> > >by many compressors, the original reasons for it have become
> long
> > >irrelevant and it is not surprising that new compressors do not
> > >support it.  In particular, Portage already hit this problem
> twice:
> > >once when users replaced bzip2 with parallel-capable pbzip2
> > >implementation [#PBZIP2]_, and the second time when support for
> zstd
> > >compressor was added [#ZSTD]_.
> > 
> > I think this is actually the result of a rather opportunistic
> > implementation.  The fault is that we chose to use an extension that
> > suggests the file is a regular compressed tarball.
> > When one detects that a file is xpak padded, it is trivial to feed
> the
> > decompressor just the relevant part of the datastream.  The format
> > itself isn't bad, and doesn't rely on obscure behaviour.
> 
> Except if you don't have the proper tools installed.  In which case
> the 'opportunistic' behavior made it possible to extract the contents
> without special tools... except when it actually happens not to work
> anymore.  Roy's reply indicates that there is actually interest in
> this
> design feature.
> 
[snip]

Team,

I use to post something like https://wiki.gentoo.org/wiki/Fix_My_Gentoo
with a link to Patricks binhost on the forums every three or four months. 
It made it worth writing that wiki page anyway.

We still get users removing elements of their toolchain or glbc from time
to time.  The requirement that I didn't express very well, is that it shall 
be possible to install binary packages without the use of any Gentoo
specific tooling.

The current tarball of tarballs proposal would satisfy that requirement.

Its unlikely that a custom binary format would.  Of course, this being 
Gentoo someone would write a run anywhere script that did the 
unpicking, We already have deb2targz and rpm2targz. We have the 
opportunity to design out binpgk2targz before it exists.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpFaerHiTnmN.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format

2018-11-17 Thread Roy Bamford
On 2018.11.17 11:21, Michał Górny wrote:
> Hi,
> 
> Here's a pre-GLEP draft based on the earlier discussion on gentoo-
> portage-dev mailing list.  The specification uses GLEP form as it
> provides for cleanly specifying the motivation and rationale.
> 
>[snip glep proposal]
> -- 
> Best regards,
> Michał Górny
> 

Team,
 
One of the attractions of the existing format is that 
tar xf /path/to/tarball -C /mnt/gentoo 
works to fix things like glibc being removed and other
missing essential portage components.

In effect, each binary package can be treated as a
single package stage3 when a user needs a get out of jail
free card.

Does this proposal allow for installing the payload without 
the use of the Gentoo package manager from some random 
distro being used as a rescue media?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpGykl9iWp_g.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

2018-08-26 Thread Roy Bamford
On 2018.08.26 12:15, Michał Górny wrote:
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do
> only
> > > talk about one of the versions. And then you get to validate or
> source
> > > files to be sure that they do have a "or later" clause in them.
> And
> > > then on each bump you ideally should validate it again, etc, that
> no
> > > sources without "or later" allowance are in there...
> > 
> > Yup, precise tracking of license metadata can be a pain.
> > 
> > I'm not really sure if that level of it is worth for us as a distro.
> For
> > _importing_ other project's source code directly into one's project
> > precise license compatibility matters a lot. That's not the scenario
> > we're in. I see LICENSES as mostly a mechanism for end users to
> accept
> > or reject EULAs etc, and I'm curious what are other common
> scenarios.
> > 
> > Michał, could you elaborate on why not distinguishing more precisely
> > between these GPL variants in LICENSES is a _problem_ ? I can
> certainly
> > see the information is not always accurate, but it's not obvious to
> me
> > how severe is the downside, what are the consequences in practice.
> > 
> 
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.
> 
> -- 
> Best regards,
> Michał Górny
> 

Michał,

How far do you want to dig?
Every upstream file or do you trust the upstream top level licence?

What about bundled libs?
Do you trust upstream to have that that right too?

It looks like a lot of work for what is at most, a convenience to users.

What matters most is the licensing for things we distribute as binaries.
That would make an interesting and more manageable test case.

As has already been pointed out. Fixing it is one thing, keeping it fixed
is another.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgplAdhXytuo_.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Roy Bamford
On 2018.07.20 14:14, Rich Freeman wrote:

>  While you can get Gentoo
> running with busybox and such and I completely support having profiles
> to enable this, I'm not sure this is the sort of thing that we want to
> point new users towards as a starting point.
> 
> -- 
> Rich
> 
New to Linux users, I agree. Linux users new to Gentoo should maybe 
have more freedom to shoot themselves in the foot. They are more
likely to be coming to Gentoo to get what they think they want. They just 
don't know how yet, so lets not make it too difficult.

I_KNOW_WHAT_I_AM_DOING or something similar comes to mind.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
arm64
elections
gentoo-ops
forum-mods


pgpU9UN94Wo7a.pgp
Description: PGP signature


Re: [gentoo-dev] Idea for a new project: gentoo-libs

2018-06-23 Thread Roy Bamford
On 2018.06.23 09:55, Marty E. Plummer wrote:
> On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote:
> > On 23/06/2018 09:43, Mikle Kolyada wrote:
> > > But how would it serve gentoo itself? Lots of packages in the
> distro
> > > have dead upstream but still work.
> > > Why would you want to make gentoo an upstream area rather than
> moving a
> > > dead project itself, say,
> > > to github and do the job there?
> > 
> > +1
> > 
> > I like the idea of taking responsibility for the abandoned packages
> that
> > are still useful.
> > 
> > It's probably not Gentoo-specific, so a distro-neutral way of
> handling
> > that seems most appropriate.
> > 
> > It may even be worth it to coordinate with other distros (and maybe
> > downstreams) so that the new version becomes a standard.
> > 
> > Finally, having more than one person on this (to help continuity),
> and a
> > common platform like GitHub also seem very helpful.
> > 
> > Paweł
> > 
> Agreed in general; the problem is getting it started at all; difficult
> to get other distros to join if there is nothing to join.
> 
> 
> 

A couple of generalisations.

The first solution to unmaintained packages should be to move to an 
alternative, if that's possible. Gentoo does not have the resource
to be upstream for very much for the entire Linux community, a point
already made by others.

In volunteer groups things get done by those who want to do them.
Others join later. I think the quote I'm looking for is "Build it and they 
will come".

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpVfuXnGRrnH.pgp
Description: PGP signature


Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

2018-06-17 Thread Roy Bamford
On 2018.06.17 08:49, Brian Dolbec wrote:
> On Sat, 16 Jun 2018 21:40:10 -0700
> Matt Turner  wrote:
> 
> > Hello,
> > 
> > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and
> > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel
> > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has
> > meant classic r100, r200, r300, and r600 drivers and gallium r600
> and
> > radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965
> > drivers as well as gallium i915.
> > 
> > I added more-specific VIDEO_CARDS for those separate drivers a few
> > years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and
> > only get the one radeonsi driver they actually wanted while still
> > enabling support for x11-libs/libdrm's radeon support code which is
> > used by most of those radeon drivers. Of course some users want this
> > control and others don't care at all.
> > 
> > The confusion comes in with "classic" DRI drivers vs Gallium
> drivers.
> > The Gallium abstraction layer allows a hardware driver to handle
> > multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For
> > instance, users try to build the classic i965 driver (there is no
> > Gallium driver for this hardware) with USE=opencl or USE=vaapi and
> > don't understand why they didn't get what they wanted (or
> REQUIRED_USE
> > prevents them from doing so).
> > 
> > Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax,
> > unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a
> > USE_EXPAND for Gallium-only options to attempt to avoid confusion?
> > Another point of confusion: not all Gallium drivers support all of
> > these features. For instance only the r600 and radeonsi drivers
> > support OpenCL. How to best handle this?
> > 
> > It seems like at one extreme you build an extensive set of
> > REQUIRED_USE conditions that force users to micromanage their USE
> > flags, or you let them enable all sorts of impossible combinations
> and
> > deal with the confused bug reports.
> > 
> > I would like to somehow get rid of the 'classic' and 'gallium' USE
> > flags entirely, but I'm not totally sure how. Maybe I can enable
> them
> > dependent on VIDEO_CARDS...
> > 
> > Suggestions welcome.
> > 
> 
> What about creating a tiny pkg that has all the combinations in a
> dictionary and can set the USE and VIDEO_CARDS flags according to the
> video card(s) you have.
> 
> This would be along the same lines as the
> app-portage/cpuid2cpuflags pkg.  Then the pkg is updated as new
> drivers
> and combinations are changed.  Perhaps have it run in pkg_postisnt to
> print any irregularities it finds and ewarn they need fixing.
> 
> -- 
> Brian Dolbec 
> 
> 
> 
> 

That would break for cross compiling.  My Raspberry PI has a VC4
GPU but I build things on an AMD64 box.

Any autodetection needs an emergency manual override, even if its
hidden behind the I_KNOW_WHAT_I_AM_DOING flag.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp49aOi1n44G.pgp
Description: PGP signature


Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

2018-03-23 Thread Roy Bamford
On 2018.03.23 09:48, Ulrich Mueller wrote:
> >>>>> On Thu, 22 Mar 2018, Geaaru  wrote:
> 
> > for both portage and your fork I think that could be interesting add
> > an extension to PMS for define inside profiles or targets masking of
> > packages of a particular repslository. Currently PMS doesn't permit
> > this but have this feature could be help users to define our
> > profiles under overlays.
> 
> > Something like this:
> 
> > sys-devel/gcc::gentoo
> 
> Conceptually that makes no sense. sys-devel/gcc is the name of an
> upstream package, so what does it even mean to mask it in one
> repository but not in another? If it's the same package, then it
> should behave in the same way, regardless of the repository its ebuild
> it hosted in (or the package being installed, in which case it is no
> longer in an ebuild repository).
> 
> If it is a different package however, then it should have a different
> name.
> 
> Ulrich
> 

Ulrich,

That has just irritated me.  The use case is sdlmame.

!!! The following installed packages are masked:
- games-emulation/sdlmame-0.195::Pi_aarch64 (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Pacho Ramos <pa...@gentoo.org> (18 Mar 2018)
# Fails to build (#634662), version bump long time pending (#596162).
# Removal in a month.

games-emulation/sdlmame is masked. I have a higher version in my
overlay than the one in the tree and it gets masked too.  
Its not a problem to me as I know how to manage it.  Its just untidy.

With apologies to Pacho for citing his name in the worked
example.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpTpwKGF0FbM.pgp
Description: PGP signature


Re: [gentoo-dev] Questions on overlays, repositories and PMS

2018-02-24 Thread Roy Bamford
On 2018.02.24 01:32, Michael Lienhardt wrote:
> 
> 
> Il 23/02/2018 20:37, Alec Warner ha scritto:
> > My general observation is that Gentoo is not successful as an
> organization about deprecating and removing things. One area where
> Gentoo has done well is in EAPI and in PMS itself, with mostly-clear
> versioning and standards and whatnot. But in general if something
> worked 15 years ago, it probably still works today (doubly so for
> sys-apps/portage).
> > 
> > There is a different question when building a tool like yours if it
> is worth the effort to support things that are 15 years old and are
> possibly not used (particularly in cases where functionality was
> replaced). I'd recommend starting with the basic implementation and
> adding support for the 'older' formats when users ask for them; but
> this is mostly a trade-off in efforts. If your goal is to build 
> > a "100% compatible" tool then you will probably need to support
> these edge cases.
> 
> You have a very good point.
> I'd like to be complete (it's a side effect of working in formal
> methods), but it's quite unrealistic as I am the only developer in
> this project, and it's true that there are few technical design
> choices that were made in portage that I'd be happier not to
> implement.
> I'd like to implement the /etc/portage/repos.conf system to remove as
> many hard coded references to /usr/portage in my code as possible.
> Moreover, the /etc/portage/repos.conf system looks nice, modular with
> explicit dependencies and it almost unifies all the repositories (I
> don't really understand the need of a DEFAULT section).
> 
> If possible, I'd rather avoid implementing things that are deprecated,
> but like you pointed out, few are (portage seems to be always
> expanding with new/alternative functionalities).
> The ones that are, like the /etc/portage/package.keywords file, seem
> to be still used (I've got a request to support it in my
> get_installation.sh script).
> Additionally, there are two systems that I did not want to implement
> but had to: the IUSE_IMPLICIT and USE_EXPAND.
> I didn't find any good documentation on these systems (nor the PMS nor
> https://dev.gentoo.org/%7Ezmedico/portage/doc/man/portage.5.html are
> very clear on the subject -- the PMS is still clearer), I tested a lot
> and looked at the portage implementation...
> I don't understand the reason to implement these systems with bash
> variables expanded with prefixes, while many of the USE flag
> manipulation is done with dedicated files (use.*, package.use.*).
> It really felt like an old design choice kept there because it worked,
> but which could be simplified.
> 
> On a similar topic, does anyone still have USE-related variables in
> his /etc/env.d folder? (https://wiki.gentoo.org/wiki/USE_ORDER)
> It seems to me that portage's current effort is to have all
> configuration files in /etc/portage or in the profile.
> 
> Best,
> Michael Lienhardt
> 
> 
> 
Michael,

'Support' can be as simple as nagging the user to move with the 
times and failing. 

I suspect that many older systems (including mine) are not updated
because it still works.

crossdev users may be familiar with this approach. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp8okkf_VHbW.pgp
Description: PGP signature


Re: [gentoo-dev] SAT-based dependency solver: request for test cases

2018-02-06 Thread Roy Bamford
On 2018.02.06 10:52, Michael Lienhardt wrote:
> Dear all,
> 
> With the help of some friends and colleagues, I am working on an
> SAT-based dependency solver for portage.
> We need your help to test it and possibly improve in the long run the
> already great portage toolset.
> 
> To help, you can send us the tar generated by this bash script:
> https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh
> This bash script extracts your world file, the USE flags and keywords
> configuration of your system and the list of installed packages you
> have (it should not take more than few seconds).
> With this, we will see if our solver is able to recreate your system
> and how much time it takes.
> 
> You can send everything to my professional email: mlien...@di.unito.it
> 
> 
> The goal of this alternative solver is to overcome some of the
> limitations of emerge.
> Thanks to some users of the forum and the gentoo-user mailing list, I
> already tested the solver on 8 systems, and the results for now are:
>   - emerge is not able to recreate any of these systems (i.e., 'cat
> world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM
> does not succeed, even with the right /etc/portage/package.* files)
>   - our solver takes 2 minutes in average (with little variation), and
> gives either a yes answer (with what to install, which USE flags to
> set, which packages to keyword) or a no answer (with the set of
> conflicting constraints) for every systems
>   - we solved one bug in our solver (a behavior of emerge that seems
> documented only in the PMS document, not in devmanual nor in the wiki,
> and that is visible only in 15 packages), but at least one seems to
> still be around.
> 
> I started discussing this on the gentoo-portage-dev and the
> gentoo-user mailing lists (sorry for the duplicates), and on the forum
> with three posts:
>   - https://forums.gentoo.org/viewtopic-t-1074170.html about the
> documentation I collected to implement the solver
>   - https://forums.gentoo.org/viewtopic-t-1074202.html about the
> solver and its motivations
>   - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests
> I'm doing
> 
> 
> About me:
> I'm a researcher in computer science, about formal methods,
> concurrency and software engineering.
> Friday, I will present my first paper on portage, showing that its
> packages and their dependencies constitute what is called a
> "Multi-Software Product Line" in software engineering. If you skip the
> algebraic definition, it should be readable ^^:
> http://www.di.unito.it/~mlienhar/vamos.pdf
> In 2013, I designed and contributed to the implementation of a
> dependency solver for dynamic cloud architecture (currently maintained
> by Jacopo Mauro https://bitbucket.org/jacopomauro/zephyrus2/src )
> I'm a gentoo user since 2007, and I'm very happy by this opportunity
> to contribute back :).
> 
> 
> Thank you!
> Michael Lienhardt
> 
> 
> 

Michael,

Posting here to alert other potential helpers.
Your script uses

PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords" 

but thats a recent name change.

PACKAGE_KEYWORDS="/etc/portage/package.keywords"

is the old name and my older systems still use that.
You probably need to harvest both and process both as portage does.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpjZkguBNLdT.pgp
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

2018-01-27 Thread Roy Bamford
On 2018.01.27 08:30, Michał Górny wrote:
> W dniu pią, 26.01.2018 o godzinie 20∶48 -0500, użytkownik Michael
> Orlitzky napisał:
> > On 01/26/2018 06:24 PM, Michał Górny wrote:
> > > 
> > > The alternate option of using file hash has the advantage of
> having
> > > a more balanced split.  Furthermore, since hashes are stored
> > > in Manifests using them is zero-cost.  However, this solution has
> two
> > > significant disadvantages:
> > > 
> > > 1. The hash values are unknown for newly-downloaded distfiles, so
> > >``repoman`` (or an equivalent tool) would have to use a
> temporary
> > >directory before locating the file in appropriate subdirectory.
> > > 
> > > 2. User-provided distfiles (e.g. for fetch-restricted packages)
> with
> > >hash mismatches would be placed in the wrong subdirectory,
> > >potentially causing confusing errors.
> > > 
> > 
> > The filename proposal sounds fine, so this is only academic, but:
> are
> > these two points really disadvantages?
> > 
> > What are we worried about in using a temporary directory? Copying
> across
> > filesystem boundaries? Except in rare cases, $DISTDIR itself will be
> > usable a temporary location (on the same filesystem), won't it?
> 
> Why add the extra complexity when there's no need for one? Note that
> there's also the problem of resuming transfers, so in the end we're
> talking about permanent temporary directory where we keep unfinished
> transfers.
> 
> > For the second point, portage is going to tell me where to put the
> file,
> > isn't it? Then no matter what garbage I download, won't portage look
> for
> > it in the right place, because where-to-put-it is determined using
> the
> > same manifest hash that determines where-to-find-it?
> 
> No, it won't. Why would it? You're going to call something like:
> 
>   edistadd foo.tar.gz bar.tar.gz
> 
> ...and it will place the files in the right subdirectories.
> 
> -- 
> Best regards,
> Michał Górny
> 
> 
> 
> 

Michał,

How does this work for fetch restricted files and finding other files
no longer on the mirrors?

Its no longer a download and move it to $DISTFILES, or is it?
Whatever it is, users will need to do it unless files in  $DISTFILES
are accepted by package managers if they are not found in the main 
structure.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpqad588ZI9H.pgp
Description: PGP signature


Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-11 Thread Roy Bamford
On 2018.01.11 01:03, Andreas K. Huettel wrote:
> > Does being 'struck off' the list in this way apply to devs,
> including
> > Council and comrel members?
> 
> So far noone has even considered "striking" devs off the list. If this
> even 
> were to happen ever, it would have to be backed by a full comrel team
> decision 
> / vote. And these don't happen often, don't happen quickly, and don't
> happen 
> lightly. (I much prefer fixing the glibc ebuilds, horrible as these
> may be.)
> 
> We have now an imperfect solution to an unneccessary problem. If
> anyone can 
> come up with a better solution (that is still an improvement over
> doing 
> nothing), I'm all ears. List moderation is not one, since a) it still
> hasn't 
> been implemented technically, b) even if that were done, we would
> still 
> require an active moderation team, and c) then we start bikeshedding
> about the 
> moderation rules.
> 
> 
> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, perl, libreoffice, comrel)


Andreas,

Does removing non  @gentoo.org email address from the ML not require 
that process too?

Gentoo does not have any other disiplinary process than the action by 
comrel that you describe.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp0aZ8m0b6IP.pgp
Description: PGP signature


Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-10 Thread Roy Bamford
On 2018.01.09 21:20, Andreas K. Huettel wrote:

[snip]
> * Obviously, repeated off-topic posting as well as behaviour against
> the
>   Code of Conduct [2] will lead to revocation of the posting
> permission.
> 

[snip]

> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, perl, libreoffice, comrel)

Andreas,

Being somwhat old and cynical, I'm seeing signs of history 
repeating itself.

Does being 'struck off' the list in this way apply to devs, including 
Council and comrel members? 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpeMAJ1kh9Zo.pgp
Description: PGP signature


Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-21 Thread Roy Bamford
On 2017.12.21 00:35, William Hubbs wrote:
> On Wed, Dec 20, 2017 at 07:12:45PM -0500, Michael Orlitzky wrote:
> > On 12/20/2017 06:58 PM, William Hubbs wrote:
> > > 
> > > There already is an overlay for dying packages, it is called
> graveyard,
> > > but no one is putting things there.
> > > 
> > > This email conflates old dying packages with new versions, which
> are a
> > > completely separate issue.
> > > 
> > 
> > Lack of new versions *is* dying. But I can make a package not-dying
> in a
> > few seconds by merging a PR, so long as you don't expect me to do
> the
> > (relatively high) level of QA required for ~arch.
> > 
> > 
> > > If a new version of a package is known to cause wide scale
> breakage, it
> > > goes in package.mask until the breakage is resolved. Otherwise,
> putting
> > > it in ~ is fine. I don't see the need for another level of
> keywords.
> > 
> > The quality of ~arch is its own worst enemy; these days, stable
> packages
> > are just old ~arch packages. Users and developers expect ~arch to
> work,
> > and we have no real policy or documentation stating that it won't.
> Many
> > people will tell you that ~arch works better than stable, because it
> > gets fixed faster.
> 
> ~arch *will* have breakages from time to time, sometimes major
> breakages, until they are masked or fixed. We are not supposed to
> leave
> major breakages there, but ~arch is definitely not for the faint of
> heart. If you are using ~arch, you are expected to be a power user at
> leasst and be able to recover if your system breaks. Production
> servers
> should not be running ~arch at all. That's the whole reason ~arch
> exists.
> 
> Yes, ~arch gets fixed faster than stable, but that is to be expected.
> However, it is definitely not a good reason to put your production
> system on
> full ~arch.
> 
> So, I guess this means that the quality of the ~arch tree is supposed
> to
> be somewhat lower than the quality of the stable tree.
> 
> William
> 
> 

William,

I've been running ~arch everywhere since May 2002 and had exactly 
two major issues. They were :-
Xorg going modular ... which I was aware of before it happened and
expat which came as a surprise while I was dealing with modular
Xorg.

There have been some minor inconviences along the way too but
problems running ~arch have reduced over the years.

Nobody should run Gentoo at all in production unless they build
and test packages offline before pushing the binaries to production.
Then they can run whatever they want.
Every Gentoo install is different and very few possible 
combinations are actually tested.

By all means lower the bar for ~arch. Say, to "builds and works for 
me, needs more testing".  The down side is that it will create more
bug reports and more work, so it may only exchange one problem
for another.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp1acaAGrvTc.pgp
Description: PGP signature


Re: [gentoo-dev] Java 9 on Gentoo

2017-11-18 Thread Roy Bamford
On 2017.11.18 04:16, William L. Thomson Jr. wrote:
> On Sat, 18 Nov 2017 02:40:14 +
> Peter Stuge <pe...@stuge.se> wrote:
> 
> > William L. Thomson Jr. wrote:
> > > > If you have any suggestions as to what I should look at to
> better
> > > > understand the OpenJDK build system I would very much appreciate
> > > > them.  
> > ..
> > > Build OpenJDK stand alone. Get familiar with that.  
> > 
> > It used to be that one could not build OpenJDK without already
> having
> > a working JDK. Has that changed with OpenJDK 9 (IIRC it was planned
> > for OpenJDK 7 :) or not yet, and that is a reason for having icedtea
> > in the mix?
> 
> Yes you are correct, nothing has changed there to my knowledge.
> 
[snip]

> 
> -- 
> William L. Thomson Jr.
> 

You can start with gcc-5.4 with the gcj use flag.
That will bootstrap icedtea:7
icedtea:7 will bootstrap icedtea:8
Tested on arm64.

With icedtea:7 going and gcc-5.4 not having a very long future,
building icedtea for a new arch will be painful. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpgyRdsSikdz.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

2017-10-26 Thread Roy Bamford
On 2017.10.26 21:12, Michał Górny wrote:
> Hi, everyone.
> 
> After a week of hard work, I'd like to request your comments
> on the draft of GLEP 74. This GLEP aims to replace the old
> tree-signing
> GLEPs 58 and 60 with a superior implementation and more complete
> specification.
> 
> The original tree-signing GLEPs were accepted a few years back but
> they
> have never been implemented. This specification, on the other hand,
> comes with a working reference implementation for the verification
> algorithm. I expect to finish the update/generation part in a few
> days,
> then work on additional optimizations (threading, incremental
> verification, incremental updates).
> 
> ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst
> HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
> impl: https://github.com/mgorny/gemato/
> 
> Full text following for inline comments.
> 
[snip lots of hard work]
> 
> -- 
> Best regards,
> Michał Górny
> 
> 
> 

Michał,

Thank you for the hard work.

This GLEP implies that users need to have the entire repository to validate
and authenticate, if I understand it correctly.

For example 
PORTAGE_RSYNC_EXTRA_OPTS="--exclude=<list_of_"
wil still work but the resulting tree could not be authenticaed. as
the top level signature would fail. 

The manifests would still work correctly because they only apply to
the directory containing them. Pruning the repository at 
rsync time will therefore remove the manifents and the files that they cover.

Is that understanding correct?  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgp6HmH_FLlOR.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-project] The status of grsecurity upstream and hardened-sources downstream

2017-06-23 Thread Roy Bamford
On 2017.06.23 19:54, Alice Ferrazzi wrote:
[snip]
> 
> As we already contribute to grsec in the past,
> would be sad to see hardened-sources go away.
> What about the possibility of Gentoo forking PaX ?
> 
> -- 
> Thanks,
> Alice Ferrazzi
> 
> Gentoo Kernel Project Leader
> Mail: Alice Ferrazzi <ali...@gentoo.org>
> PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
> 
> 

Alice,

Forking with what aim?
Keeping the existing functionality alive in line with kernel 
developments or that and adding new features.  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpsyL177pvC6.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

2017-05-29 Thread Roy Bamford
On 2017.05.29 11:59, Alexander Berntsen wrote:
> On 27/05/17 18:17, Patrick Lauer wrote:
> > But you do gentoo wrong, so as a user I'd like you to reconsider
> what 
> > you wrote there and maybe take a long vacation.
> I too do not hate our users (in which I include myself).
> 
> Treating users as a worthless nuisance, unless they're writing ebuilds
> or managing your precious GitHub crap, is a good way to lose users.
> 
> And even if I did hate our users, I agree with William & Ulrich.
> -- 
> Alexander
> berna...@gentoo.org
> https://secure.plaimi.net/~alexander
> 
> 

... and some of those lost users might have gone on to become devs.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpLoBjumJszq.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

2017-03-12 Thread Roy Bamford
On 2017.03.11 20:50, Kristian Fiskerstrand wrote:
> A draft of a Pre-GLEP for the Security project is available for
> reading
> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
> 
> The GLEP follows a line of GLEPs for special projects that have
> tree-wide access in order to ensure proper accountability (c.f GLEP 48
> for QA and still non-produced GLEP for ComRel (I've started working on
> this and will be presenting this one later as current ComRel Lead))
> 
> Comments, patches, threats, etc welcome
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> 

Kristian,

First of all, thank you. We have needed something like this for several 
projects, for some time.

A few odds and ends.

Why do Security Project members need to be ebuild devs?
Non ebuild developers can contribute by producing GLSAs, 
for example. 

Who manages the Security Project (from outside).  It appears from
the draft GLEP, nobody.  That means that the project could become 
moribund and nobody would notice.  Its not like Gentoo enforces 
or even checks for leadership elections. That's an anual event 
anyway, so its not a measure of a projects continued well being. 

Compare the Security Project to council, that have a monthly 
showing of project health. 

Projects tend to be left alone. Gentoo has several projects that 
appear to be unmanaged but cannot be permitted to die out. 
This is one. Who takes the Security Projects pulse and how?

A periodic automated message to -dev that all Security Project
members "reply to list" is both public and mimnimally invasive.
Its no more than 'roll call'.

Now the hard one, who does what when there is no pulse from 
the Security Project?

This isn't really a Security Project issue. If its ever needed, the 
Security Project isn't active. It affects other projects too, like
comrel, QA and others. Perhaps there is a common solution
to taking a proqcts pulse and reacting when there is none.  

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpQAiSAKWYXf.pgp
Description: PGP signature


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

2016-10-27 Thread Roy Bamford
On 2016.10.25 22:52, Ian Stakenvicius wrote:
> On 25/10/16 05:12 PM, Michał Górny wrote:
> > On Tue, 25 Oct 2016 12:01:06 -0500
> > William Hubbs <willi...@gentoo.org> wrote:
> > 
> >> Title: Inportant fstab update
> >> Author: William Hubbs <willi...@gentoo.org>
> >> Content-Type: text/plain
> >> Posted: 2016-10-28
> >> Revision: 1
> >> News-Item-Format: 1.0
> >>
> >> If you are not using /dev/disk/by-* paths in fstab, you do not need
> to
> >> take any action for this news item.
> >>
> >> If you are, it is very critical that you update fstab AS SOON AS
> >> POSSIBLE. Your system will become unbootable in the future if you
> do
> >> not  do so.
> > 
> > I don't think this is a good way to start any text. You should start
> > with a short introduction on what's happening, when and how.
> > 
> > Right now the news item sounds like the world is going to suddenly
> fall
> > apart for no specific reason. Reading it, I don't know what's
> changing,
> > and how to check if it impacts me already (i.e. if it's 'do not
> > reboot' kind of problem) and if it will impact me at all.
> > 
> >> You need to replace the /dev/disk/by-* paths in your fstab with the
> >> equivalent information from the output of the blkid utility.
> > 
> > This is at least unclear, if not misguiding. I read it as 'blkid
> will
> > give you fs info'. However, you're not telling me which of those
> > information I can use and how. I should also point out that blkid
> > supports multiple output formats.
> > 
> > I think it would be better if you explicitly listed the thingies
> > supported by mount(1).
> > 
> 
> Reading mgorny's response, I'm wondering if a news item really makes
> any sense at all for this.  What's being done here is essentially a
> warning/recommendation for users to act so they don't run into a
> problem that's sort-of already there (at least in ~arch)...
> 
> Personally I'd rather see us go the other way, ensure udev settles
> before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
> or something.  Leave the migration away from these paths to general
> education of system setup, since they technically are valid, just not
> ideal.
> 
> 
+1

Add udev-settle now.
Have an advisory news item that says why its been done and what 
users can do if they don't like it or don't need it, and what will happen
long term.
At the same time, depreciate the use of udev symlinks in fstab.

Some time later, remove udev-settle and have another news item.
By now, users will have reacted to the first news item or sympathy 
can be minimal.
 
In the interim, nothing should break because a news item was not
read and acted on immediately. 

That's the important bit ... nothing breaks on user systems.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpRXKeMRcwoT.pgp
Description: PGP signature


Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

2016-01-22 Thread Roy Bamford
On 2016.01.21 17:45, Michał Górny wrote:
[snip]

> 
> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?
> 
[snip]
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
> 

Michał 

Your statement implies that there is an active search process for broken 
packages.

I did not intend to imply that if you happened across a broken package with no 
bugs, 
you needed to raise a bug to remove it from the tree.

Actively building every package in the tree to discover candidates for removal 
takes a lot more resources than searching bugs to identify potential candidates.

Its the old case of absence of evidence is not evidence of absence.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpFDkyRFS8fc.pgp
Description: PGP signature


Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

2016-01-21 Thread Roy Bamford
On 2016.01.21 16:53, William Hubbs wrote:
> On Tue, Jan 19, 2016 at 10:35:15AM -0800, Alec Warner wrote:
> > On Mon, Jan 18, 2016 at 9:44 PM, NP-Hardass <np-hard...@gentoo.org>
> wrote:
> > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > With all of the unclaimed herds and unclaimed packages within
> them, I
> > > started to wonder what will happen after the GLEP 67 transition
> > > finally comes to fruition.  This left me with some concerns and I
> was
> > > wondering what the community thinks about them, and some possible
> > > solutions.
> > >
> > > There is a large number of packages from unclaimed herds that, at
> this
> > > time, look like they will not be claimed by developers.  This will
> > > likely result in a huge increase in maintainer-needed packages
> (and
> > > subsequent package rot).  This isn't to say that some of these
> > > packages weren't previously in a "maintainer-needed" like state,
> but
> > > now, they will explicitly be there.
> > >
> > 
> > Speaking as the dude who founded the treecleaners project...all
> things die.
> > Even software. While some may yearn for a software archive (nee,
> > graveyard!), I put forth that the gentoo-x86 tree is not such a
> thing. Do
> > not weep for the unmaintained packages that will be cleaned![1]
> 
> I couldn't have said this better myself. The gentoo-x86 tree is not a
> software archival service. If packages are unmaintained, that is what
> the treecleaners project is for is to boot those packages out of the
> tree.
> 
> I would like to see a possible timelimit set on how long packages can
> stay in maintainer-needed; once a package goes there, if we can't find
> someone to maintain it, we should consider booting it after that time
> limit passes.
> 
> If someone wants to run the graveyard overlay and keep those old
> packages around more power to them, but they definitely do not
> belong in the main tree if they are unmaintained for an extended
> period
> of time.
> 
> William
> 
> 

There is no point in removing unmaintained but perfectly functional software 
from the tree.
It needs to be both unmaintained and broken. Broken being evidenced by at least 
one open bug.

How would you define unmaintained?
Maybe its not changed for a year or two because there is no need for any 
maintenance?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpjSgX2JV8mk.pgp
Description: PGP signature


Re: [gentoo-dev] Hello Everyone

2015-02-22 Thread Roy Bamford
On 2015.02.22 12:05, Tushar Rajput wrote:
  I am novice programmer and wants to contribute to gentoo.Can you 
 give
 me
 some details?
 Thanks
 

Tushar,

Welcome.  

Sign up to bugs.gentoo.org

Find some bugs in your area of interest, fix them, test the fixes and 
post patches on the bugs. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpdW2SQKTl3b.pgp
Description: PGP signature


Re: [gentoo-dev] ebuild copyright assignment

2015-02-22 Thread Roy Bamford
On 2015.02.18 07:40, Jeroen Roovers wrote:
 On Mon, 16 Feb 2015 06:39:51 -0500
 Mike Frysinger vap...@gentoo.org wrote:
 
  the policy is not it must be Gentoo copyright, but it must have 
 a
  header that says Gentoo copyright even though there's no legal 
 basis
  for it.
 
 Correct, but I have my doubts about the allegedly wobbly legal basis.
 I
 do vividly recall reading these:
 
 http://www.gentoo.org/proj/en/devrel/copyright/index.xml
 http://web.archive.org/web/20040604022011/http://www.gentoo.org/doc/
 en/policy.xml
 
 Copyright in ebuilds (and documentation) should always be assigned to
 Gentoo Technologies. Developers must never put their own names in
 copyright lines. For more information, please see
 http://www.gentoo.org/proj/en/devrel/copyright-assignment.xml
 http://web.archive.org/web/20040624223240/http://www.gentoo.org/
 proj/en/devrel/copyright-assignment.xml
 
 (Page moved to
 http://www.gentoo.org/proj/en/devrel/copyright/index.xml
 http://web.archive.org/web/20040618235041/http://www.gentoo.org/
 proj/en/devrel/copyright/index.xml)
 
[snip]

 
  jer
 
 
 


Here's some history ...

Gentoo Technologies Inc. was interested in using the Gentoo codebase 
commercially. It was not a financial success and the assets of Gentoo 
Technologies Inc. were transferred to the Gentoo Foundation Inc. when 
drobbins left Gentoo. That would be about 2004, when the Foundation 
was established. Commercial use was easier if Gentoo Technologies Inc. 
held the copyright.

Its unclear if anyone actually completed copyright assignment paperwork 
at any time. The legal standing of the ebuild header is also unclear as 
it has never been tested in court.

The remaining idea behind it today is that it might ensure that the 
Foundation is the target of any legal action resulting from an ebuild 
and conversely can take legal action to defend an ebuild.
I say 'might' as international copyright is a minefield. Its wider than 
just ebuilds, its wherever Foundation copyright is asserted.

Both Gentoo Technologies Inc. and Gentoo Foundation Inc. were/are New 
Mexico legal entities, so are subject to New Mexico law. Of course, if 
you are not in New Mexico, or even the USA, that law may not apply to 
you and that's where the minefield starts.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpxPySl2nRlI.pgp
Description: PGP signature


Re: [gentoo-dev] PowerPC status

2014-09-20 Thread Roy Bamford
On 2014.09.18 00:31, Jack Morgan wrote:
 Hello,
 
 The PowerPC development team has had our 2nd monthly meeting and I
 wanted to provide an update on where we are. 
 
[snip]

 I've sent email to the following devs but haven't head back yet so
 don't
 know your current status.
 
 Mark Loeser (halcy0n)
 Gysbert Wassenaar (nixnut)
 Michael Weber (xmw)
 
[snip]
 
 Thanks,
 -- 
 Jack Morgan
 Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org
 Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A
 

I'm fairly sure nixnut retired.
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpcclsP9iPTv.pgp
Description: PGP signature


Re: [gentoo-dev] package.mask vs ~arch

2014-06-30 Thread Roy Bamford
On 2014.06.30 05:01, William Hubbs wrote:
 All,
 
 I am starting a new thread so we don't refer to a specific package,
 but I
 am quoting Rich and hasufell from the previous masking thread.
 
 On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
  On Sun, Jun 29, 2014 at 8:36 AM, hasufell hasuf...@gentoo.org
 wrote:
   This is still too vague for me. If it's expected to be short-
 term,
 then
   it can as well just land in ~arch.
  
  A package that hasn't been tested AT ALL doesn't belong in ~arch.
  Suppose the maintainer is unable to test some aspect of the 
 package,
  or any aspect of the package?  Do we want it to break completely 
 for
  ~arch?  In that event, nobody will run ~arch for that package, and
  then it still isn't getting tested.
 
 I'm not saying that we should just randomly throw something into 
 ~arch
 without testing it, but ~arch users are running ~arch with the
 understanding that their systems will break from time to time and 
 they
 are expected to be able to deal with it when/if it happens. ~arch is
 not a second stable branch.
 
  I agree that masking for testing is like having a 3rd branch, but
 I'm
  not convinced that this is a bad thing.  ~arch should be for
 packages
  that have received rudimentary testing and which are ready for
 testing
  by a larger population.  Masking should be used for packages that
  haven't received rudimentary testing - they might not have been
 tested
  at all.
 
 The concern with this argument is  the definition of rudimentary
 testing
 is subjective, especially when a package supports many possible
 configurations.
 
 I think some packages need wide testing before they go stable, and
 that
 is where ~arch can help out.
 
 In particular, I would argue that for system-critical packages, users
 should be very careful about running ~arch unless they know what the
 fallout can be.
 
 *snip*
 
  I guess the question is, what exactly are we trying to fix?  Even 
 if
  occasionally a maintainer drops the ball and leaves something 
 masked
  for a year, how is that different from a maintainer dropping the
 ball
  and not adding a new release to the main tree for a year?  Would we
 be
  better off if Docker 1 wasn't in the tree at all?  If it happened 
 to
  have a known issue would ~arch users be better off if some other 
 dev
  came along and helpfully added it to the tree unmasked no realizing
  that somebody else was already working on it?
 
 Take a look at profiles/package.mask. You will see many packages in
 there with the description, masked for testing on their masks, with
 no
 bug references, that have been there for multiple years. My view is 
 we
 should either get those masks resolved or boot the affected
 packages/versions out of the tree. If they haven't received
 rudimentary
 testing by now, it is pretty obvious that no one cares about them.
 
 William
 
 

Once upon a time, not so long ago I don't remember it, there were very 
few overlays.  At that time, there was always a lot of packages in the 
tree masked for testing.  At that time, well before layman, overlays 
were inconvenient. 

As overlays have become more widespread and used as a way to lower the 
barrier to contributing directly to Gentoo, there are fewer packages 
masked for testing.

I like the old way, it avoids installing yet another overlay but 
clearly others feel differently or there would not be so many overlays 
to choose from. The reality is, both ways work for me.
Pragmatically, its not practical to merge all of the overlays into the 
tree, then ban overlays.  That would be a return to the old way.

This just represents a change of workflow with time.
The question then is do we need to formalise the changed workflow, or 
can both be allowed to continue side by side?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpwJVV2X65ZZ.pgp
Description: PGP signature


Re: [gentoo-dev] package.mask vs ~arch

2014-06-30 Thread Roy Bamford
On 2014.06.30 16:40, Ian Stakenvicius wrote:
 On 30/06/14 11:36 AM, Michał Górny wrote:

[snip]

 
  But... if you unmask it, someone will test it and report whether
  it works :P.
 
 
 But... if I unmask it, -everyone- using ~arch will install it and
 it'll break all the systems that it doesn't work on, which -could- be
 quite a lot at this point.  :D
 
 
 

Yep.  The good old days ... X11 going modular ... expat-2 and a few 
others that I've forgotten.
There was no news then so if you missed an email to the list you got to 
pick up the pieces.  Those examples may well be me missing emails.

I've run ~arch since mid 2002 and until the last few years always had a 
few builds fail or things build then operate so badly they needed to be 
p.masked locally.  That's what buildpkg is for ... so that after you 
spend 10 hours building *office and find out its a dud, you can back it 
out in a few minutes.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpjfKriB3eLY.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

2014-05-14 Thread Roy Bamford
On 2014.05.12 10:35, Tom Wijsman wrote:
 On Sun, 11 May 2014 19:46:50 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  Rationale: xz-utils is quite widespread nowadays and it is a part
  of @system set. It can achieve better compression ratio than bzip2,
  and faster decompression at the same time.
 
 Some thoughts:
 
 What about putting multiple doc / man / info files in a single .xz
 file
 for each package? Would that further improve the situation?
 
 (As they can share dictionary, instead of having multiple
 dictionaries)
 
 Some algorithms tend to work better for smaller files, whereas others
 work better for larger files; might this be the case for bzip2 vs. 
 xz?
 
 -- 
 With kind regards,
 
 Tom Wijsman (TomWij)
 Gentoo Developer
 
 E-mail address  : tom...@gentoo.org
 GPG Public Key  : 6D34E57D
 GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
 

Some more thoughts ...

What about not compressing files smaller than the filesysem block size 
at all.  In my case its 4k.  Any file gets allocated 4k on disc anyway, 
so compression/decompression is just a waste of resource for files 
=4k. 

I'm not suggesting dynamically determining the output filesystem block 
size (unless you really want to), choose a static limit below which 
compression will not be applied.

That eliminates the discussion about small files.
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpN77XN8fctg.pgp
Description: PGP signature


Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?

2014-03-02 Thread Roy Bamford
On 2014.02.28 14:44, Samuli Suominen wrote:
 
 On 28/02/14 16:18, Tom Wijsman wrote:
  On Fri, 28 Feb 2014 15:28:30 +0200
  Samuli Suominen ssuomi...@gentoo.org wrote:
 
  It would be very helpful if INSTALL_MASK could be overriden from 
 an
  ebuild, ...
  What is the intended goal? Can you give an example?
 
 - User has INSTALL_MASK=/lib/systemd
 - Ebuild has INSTALL_MASK_OVERRIDE=/lib/systemd/systemd-udevd
 /lib/systemd/network
 - Portage's default is to respect ebuild first, then users setting,
 unless he changes INSTALL_MASK_ORDER to respect his
 
 I completely agree using INSTALL_MASK is 100% responsibility of the
 user
 setting it, it's like blind 'rm -f', but some people
 don't agree and keep attacking me.
 I'm using the word attacking because it's constant, relentless,
 repeating and I don't see an end to it. I believe Poly-C just
 proofed that point in this thread.
 
 
 

Samuli,

You can't win this one.  
Consider ln -s /dev/null /lib/systemd/
or whatever. It achieves the same thing and you can't override it 
unless you also remove the symlink.

INSTALL_MASK means 
I_KNOW_WHAT_IM_DOING_AND_AM_PREPARED_TO_KEEP_THE_PIECES

systemd and the components it has sucked in has become the centre of a 
religious war with Zelots on both sides.
All an INSTALL_MASK_OVERRIDE would do is escalate the war.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpLFfXk4wQ0s.pgp
Description: PGP signature


Re: [gentoo-dev] Question, Portage QOS

2014-01-11 Thread Roy Bamford
On 2014.01.10 16:48, Igor wrote:
 Hello All,
 
 Thank you for all our feedback!
 
[snip]
 
 -- 
 Best regards,
  Igor  mailto:lanthrus...@gmail.com
 

Igor,

You don't need anyones permission to start an OSS project.
Just do it.  If its useful, it will get used.
Here, you will be met with almost total apathy because the reality is 
that most subscribers to this list won't respond until you have a 
working demo that they can play with. 

quote
First they ignore you, then they laugh at you, then they fight you, 
then you win.

Mahatma Gandhi
/quote

Good luck.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpE_PYpv0WRt.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: New project: Licenses

2013-11-29 Thread Roy Bamford
On 2013.11.22 09:38, Ulrich Mueller wrote:
  On Thu, 21 Nov 2013, Roy Bamford wrote:
 
  Indeed, that's one of the two TLPs that were suggested. The past 
 QA
  disliked having Licenses as their subproject, though. It depends 
 on
  how the role of QA is defined: If it is seen as primarily
 technical,
  then Licenses (which is largely non-technical) doesn't fit so 
 well.
 
  ... or maybe a sub committee of the Gentoo Foundation Inc?
  because of the non technical and legal implications of the work.
  Trustees get involved with licence corner cases anyway, so a team 
 of
 
  advisors would be a good fit.
 
 I'd rather avoid the term advisors, because we're no lawyers and
 therefore cannot give any legal advice.

Accepted.  Licenses already uses the trustees when legal advice is 
required.
 
 It it clear that in some cases the licenses team will escalate issues
 to the trustees and not to the council. Nevertheless, I see a project
 (TLP or sub-project) as a good enough fit. So no need to invent new
 structures for us. The main goal of having a project page is to
 increase our visibility and to have a convenient starting point for
 organising our information in the wiki.
 
 Ulrich
 

The Foundation bylaws already allow for committees, none have been 
created yet but it would not be inventing a new structure. 

None of this has anything to do with Licenses having a project page 
or not.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgp5yUWdCMgGZ.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: New project: Licenses

2013-11-21 Thread Roy Bamford
On 2013.11.21 15:21, Ulrich Mueller wrote:
  On Thu, 21 Nov 2013, hasufell  wrote:
 
  For the time being, it will be listed as a top-level project.
  (There were some ideas that Licenses could be a subproject of
  another TLP, but so far this hasn't worked out.)
 
  It should be a subproject of QA.
 
 Indeed, that's one of the two TLPs that were suggested. The past QA
 disliked having Licenses as their subproject, though. It depends on
 how the role of QA is defined: If it is seen as primarily technical,
 then Licenses (which is largely non-technical) doesn't fit so well.
 
 Ulrich
 

... or maybe a sub committee of the Gentoo Foundation Inc?
because of the non technical and legal implications of the work.
Trustees get involved with licence corner cases anyway, so a team of 
advisors would be a good fit.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpbmaaTdiQIB.pgp
Description: PGP signature


Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors

2013-11-13 Thread Roy Bamford
On 2013.11.13 19:12, Rich Freeman wrote:

[snip]

 Going back in time with portage is the easy part - it is in CVS.
 
 The real problem is all the distfiles themselves, especially things
 like out-of-tree patch tarballs hosted by devs.
 
 Rich
 

Rich,

The GPL obliges us to keep such patches around for three years, iirc.
Don't we do that ?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpWUwOIhL2tc.pgp
Description: PGP signature


Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

2013-08-10 Thread Roy Bamford
On 2013.08.07 13:45, Michael Weber wrote:
 Greetings,
 
 Gnome Herd decided to target stablilization of 3.8 [1] which requires
 systemd.
 
[snip]
 
Michael
 
 [1] https://bugs.gentoo.org/show_bug.cgi?id=478252
 -- 
 Michael Weber
 Gentoo Developer
 web: https://xmw.de/
 mailto: Michael Weber x...@gentoo.org
 
 

The Gnome team has made their choice.  I'm the light of that, users can 
now make their own choices.

That's what Gentoo is about after all ... choice.

I fully support the Gnome teams choice ... now I have to make one of my 
own. 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpav7ZqUzrXc.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon

2013-08-03 Thread Roy Bamford
On 2013.08.03 16:28, William Hubbs wrote:
[snip]

 
 Ok all, I would like to appologise for the harsh wording.
 
 Markos, to answer your question, there are folks on the team, and at
 least one user, using OpenRc from git without issues, so as far as I
 know there shouldn't be any breakage.
 
 I guess I was a little more harsh than I should have been, because I
 know there are users out here who want ~arch to be rock solid, and I
 have caught flack before from some of that crowd.
 
 William
 
 


~arch is not rock solid and isn't supposed to be.  I do like Williams 
approach to posting a warning about the upcoming change so I cam manage 
it for myself, if I'm feeling nervous.

Any notification of key packages changing like this is appreciated.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpdJ1Fe7qHuW.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC

2013-07-23 Thread Roy Bamford
On 2013.07.22 22:51, Rich Freeman wrote:
 On Sun, Jul 21, 2013 at 4:20 PM, Roy Bamford 
 neddyseag...@gentoo.org
[snip]
 
  Please keep voting in public.  Its good for accountability.
  If not in IRC, find a way to publish who voted and now.
  Council do not get a secret ballot.
 
 Agreed.  I don't think the intent of that item was ever to REPLACE
 in-person voting with email.  I think the intent was to allow for it
 so that when a critical issue comes up a week after the agenda is
 already set that everybody doesn't have to wait 5 weeks for the
 following council meeting.  It seems really odd to have a 100-post
 flamewar with no immediate action, and then to dredge up the topic a
 month later and vote, and then have another 100-post flameware to 
 talk
 about the outcome.  I don't think we need off-the-cuff decisions, but
 if a topic is ripe for a decision we should have a way to actually
 take care of it.
 
 Public debate and votes only make sense.  Bugs might be a useful way
 to record this (much as is done with the trustees).
 
 Rich
 

Rich,

I'm fine with voting via email when its needed, or even all the time as 
long as the votes are published.

You have addressed my concern. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpX4NSfPCVC0.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC

2013-07-23 Thread Roy Bamford
On 2013.07.23 01:57, Rick Zero_Chaos Farina wrote:
[snip]

 I think the real difference [between the foundation and council] is 
 that most of the devs don't care what the
 foundation does as long as it keeps the lights on around here.  Most 
 of us, on the other hand, seem to care greatly about the 
 development
 process and key decisions around that.  If the trustees need to take
 emergency action to keep the lights on I trust them to do the right
 thing.  If the council has to take emergency action to allow systemd
 units to be added without maintainer approval well, you see how
 stupid that sounds?
 
 -Zero
 
[snip]

Rick,

The council should not be denied the ability to reach decisions 
between meetings for the few times it will actually be needed.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpkeMSUUdHPC.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC

2013-07-21 Thread Roy Bamford
On 2013.07.21 15:30, Andreas K. Huettel wrote:
 
 Hello everybody, 
 
[snip]
 - vote for holding meetings every 2nd Tuesday of the month at 2000 
 UTC
 (or 
 1900 UTC depending on daylight savings)

In any timezone in particular?


[snip]
 1: the open floor is the mailing list
 discussion, 
 i.e. no open floor during the meeting anymore

The open floor is a part of the openness and approachability of the 
council.  Its 60 seconds well spent, even if nobody says anything.


 - vote on meeting format 2: shift council votes to mail instead of
 IRC

Please keep voting in public.  Its good for accountability.
If not in IRC, find a way to publish who voted and now.
Council do not get a secret ballot.

[snip]
 - general discussion on the introduction of a Bikeshed of the month 
 (basically the plan to tidy off one unresolved mailing list 
 discussion
 each 
 month)

Ok, so what colour should it be?
[with apologies to Douglas Adams]

[snip]

 
 Best, 
 Andreas
 
 -- 
 Andreas K. Huettel
 Gentoo Linux developer (council, kde)
 dilfri...@gentoo.org
 http://www.akhuettel.de/
 


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpOBoQV65j2k.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Hangouts

2013-06-25 Thread Roy Bamford
On 2013.06.23 22:30, Pavlos Ratis wrote:
 Hello all,
 
 Everyday we talk to each other about different kind of things related
 to Gentoo. IRC and MLs are the primary way of our communication, but
 this is only a text-based communication. I think sometimes it would 
 be
 better to escape from that.
 

[snip]

 Pavlos
 
 
I think audio might be useful but video won't add very much and for 
some topics, will just be a distraction.  

Having used both video and audio conferencing to span the world since 
ISDN was new, once you get more than about three or four participating 
nodes, control becomes difficult ... that's not changed over the years.

Accents are a problem even among native English speakers and by that I 
mean British English from England, not even the entire UK.

Heres a test for you ... http://linuxcrazy.com/?q=node/26
I have a South West England accent ... can you understand me?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpbYloqrAwkT.pgp
Description: PGP signature


Re: [gentoo-dev] Temporary DevRel actions for CoC violations

2013-06-20 Thread Roy Bamford
On 06/19/13 18:35:49, Markos Chandras wrote:
 Hi,
 
 It is unfortunate to observe constant bullying, insults and trolling
 across our public media. Developers have been warned over and over
 that
 such behaviour is not acceptable and they should try to behave
 properly. However, people have ignored such warnings for a very long
 time. This ends today.
 
[snip]
 
 --
 Regards,
 Markos Chandras - Gentoo Linux Developer
 http://dev.gentoo.org/~hwoarang
 

This has my support.  

I would like to see council voice their complete support publically 
too, as thats one of the reasons proctors failed.

-- 
Regards,

Roy Bamford
(Neddyseagoon) an member of
gentoo-ops
forum-mods
trustees



Re: [gentoo-dev] news item -- baselayout-1.x deprecation final warning

2013-04-07 Thread Roy Bamford
On 2013.04.07 20:36, William Hubbs wrote:
 All,
 
 We have continued support for baselayout-1 to baselayout-2/OpenRc
 migration for almost two years now, so I think it is about time we
 kill
 this off.
 
 Here is the news item I want to send out on 10 Apr.
 
 Let me know what you think.
 
 Thanks,
 
 William
 
 

quote
If you do not upgrade your systems to openrc-0.11.8 before it leaves 
the tree, you may need to reinstall them.
/quote

I think you mean

If you do not upgrade your systems to baselayout-2 and openrc-0.11.8 
before openrc-0.11.8 leaves the tree, you may need to reinstall them.

The problem is with baselayout-1 and that's what needs to be updated.
The you may need to reinstall them is a bit over the top.  You can 
always pick up the pieces with a liveCD.

Do you need to point out that the old ( ... ) syntax will no longer 
be supported, or do you intend to tolerate the baselayout-1 syntax in 
/etc/conf.d/net and friends a while longer.

A friendly link to the update guide 
http://www.gentoo.org/doc/en/openrc-migration.xml
may be in order too.

I've seen many users on baselayout-2 with baselayout-1 net files. This 
news item will bypass them.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpUphhQvpZpg.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Gentoo Bugday

2013-02-28 Thread Roy Bamford
On 2013.02.28 02:14, Pavlos Ratis wrote:
 @neddyseagoon: Yeah it would be great to have it back, I think the 
 day
 should remain as is. Every first Saturday of every month. Thanks.
[snip]


Pavlos,

https://forums.gentoo.org/viewtopic-t-952608.html


Poke me the weekend before bugday and I'll do the forums announce.
Eventually, it will be a habit.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgppEk_DtZefo.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Bugday

2013-02-27 Thread Roy Bamford
On 2013.02.27 00:39, Pavlos Ratis wrote:
 Hello everyone,
 
 I would like to announce you a new try to 'revive' the Bugday event.
 As most of the open source projects have their own bugday, I thought
 it would be great to have this event back.  For those who don't know,
 its a monthly 24h event that takes place in #gentoo-bugs. Its goal is
 to close as many bugs as possible . You don't have to be a Gentoo
 expert to participate. Those days are a great way to start joining 
 the
 Gentoo community, improving Bugzilla's and Wiki's quality and looking
 for a mentor to begin the recruitment process. The upcoming bugday
 event is this Saturday and I hope this event will continue in the 
 next
 months. I have created a wiki page for the event[1] and I added some
 guidelines. I have also created a related blog post about the
 event[2].
 
 I have listed some maintainer-wanted and maintainer-need bugs and
 Bugzilla admins also re-enabled the bugday flag. I would like to ask
 the Gentoo project teams to start using this flag to their bugs that
 think that are good to start and enable the flag at them. It would be
 great to a have a really big list with 'good to start' bugs.
 
 It's the first time after a long time that this event will take 
 place,
 so I am looking forward to your participation both users and
 developers and your feedback.
 
 [1] http://wiki.gentoo.org/wiki/Bugday
 [2] http://blog.dastergon.gr/gentoo-bugday/
 
 Thanks,
 Pavlos
 
 

Pavlos,

I used to do a forums announce for the old bugday.  That can be revived 
too if you want.  The old bugday ran to a calender, so the announces 
went up a week beforehand.

Are you goings to stick to the first Saturday in the month ?

Good luck with the revived bugday.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpkDEzO0Yr7K.pgp
Description: PGP signature


Re: [gentoo-dev] Re: linux-firmware

2013-02-22 Thread Roy Bamford
On 2013.02.21 23:18, Rich Freeman wrote:
 On Thu, Feb 21, 2013 at 5:44 PM, Greg KH gre...@gentoo.org wrote:
  This should be a cross-distro issue/solution, so I suggest working
 with
  the Linux Foundation on this.  Anyone object to me doing that?
 
 Go for it (speaking only for myself, but I can't imagine the other
 Trustees would be opposed)!
 
 Rich
 
 

Works for me too, so thats a majority vote of Trustees.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpJWmB3h542p.pgp
Description: PGP signature


Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2013-01-05 Thread Roy Bamford
On 2013.01.05 05:47, Donnie Berkholz wrote:
 On 10:43 Mon 17 Dec , Markos Chandras wrote:
  On 16 December 2012 18:53, Andreas K. Huettel 
 dilfri...@gentoo.org
 wrote:
   How to do this, however, and what software to target should
 probably 
   be decided by people who know more than me... and in the end it
 all 
   boils down to who has the time and motivation.
  
  Outsource it to someone who has the knowledge and interest in doing 
  this. The foundation has the funds to support it, and none of us 
  actually have the time to invest in a complete webpage redesign.
 
 I did much of the design work nearly 2 years ago:
 
 http://dev.gentoo.org/~dberkholz/gentoo_website/
 gentoo_landing_black.png
 http://dev.gentoo.org/~dberkholz/gentoo_website/
 gentoo_landing_install.png
 http://dev.gentoo.org/~dberkholz/gentoo_website/
 gentoo_landing_handbook.png
 http://dev.gentoo.org/~dberkholz/gentoo_website/
 gentoo_landing_handbook2.png
 
 Some early work on it using Bootstrap:
 
 http://a3li.li/~alex/g.o/
 
 That said, why the hell are we wasting time implementing our own
 website 
 backend when we should be using a CMS? We're here to make a distro,
 not 
 a website framework. No reason we should care, day to day, about 
 anything but frontend theming and content.
 
 -- 
 Thanks,
 Donnie
 
 Donnie Berkholz
 Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
 Analyst, RedMonk http://redmonk.com/dberkholz/
 
Donnie.

We make our own website framework for the same reason that everything 
else happens in Gentoo.  Someone is interested in doing it.

I agree its not 'core business' but Gentoo isn't a business.

-- 

Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpdIQacGgwHH.pgp
Description: PGP signature


Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?

2012-12-31 Thread Roy Bamford
On 2012.12.31 14:17, Ben de Groot wrote:
 Happy New Year to all of you!
 
 Looking back at 2012, I wonder what we consider our achievements for
 this past year. What is the state of Gentoo? How have we brought it
 forward and improved it this past year?
 
 And what do we want to see in the coming year? How can we make Gentoo
 more awesome in 2013?
 
 I will add my own thoughts later. I first would like to hear from 
 you.
 -- 
 Cheers,
 
 Ben | yngwin
 Gentoo developer
 Gentoo Qt project lead, Gentoo Wiki admin
 
 

Ben,

I'm older and more cynical than most on this list.  In my mind, 
improvement means change but change is not always improvement.

I'll summarise it in a post French revolution saying ... 
Plus ça change, plus c'est la même chose.

What would make Gentoo more awsome next year?
Getting more devs on board so existing things can move faster.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpZ5eIcZFAXC.pgp
Description: PGP signature


Re: [gentoo-dev] gen_usr_ldscript --libdir=/lib

2012-12-28 Thread Roy Bamford
On 2012.12.27 22:13, William Hubbs wrote:
 On Thu, Dec 27, 2012 at 03:14:37PM -0500, Rich Freeman wrote:
  Something I don't like about this whole debate is that it tends to
  come off as I've never run an initramfs and darn it I want to keep
 it
  that way.  Gentoo has always been a cutting-edge/innovative 
 distro.
  We have prefix, hardened, x32, and we were among the first to
 support
  amd64.  Sure, that flexibility also lets you get away without an
  initramfs where other distros simply cannot.  However, the lack of
 an
  initramfs should not be a crutch.
 
 Rich,
 
 you just hit my concern about this debate right on the head. I feel
 like
 the nay-sayers are opposed to it because of the FHS, and the idea of
 critical software going in / and everything else in /usr. The 
 attitude
 seems to be that has always worked, so it must continue to work into
 the
 future, with no regard to the advantages that moving everything to
 /usr
 would give us.
 
 Another concern I've heard says that we shouldn't do this on linux
 because gentoo *bsd doesn't do it. I don't see that as relevant
 because ebuilds can be smart enough to test whether they are being
 emerged on Linux or *BSD.
 
 William
 
 

I don't think the 'luddites' have quite so black and white a view as 
that but if I expand on it much more, I'll reignite a flamewar we have 
already had. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpM7U4Uf69D8.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing

2012-12-22 Thread Roy Bamford
On 2012.12.21 23:57, Greg KH wrote:
 On Fri, Dec 21, 2012 at 12:01:00AM -0500, Rich Freeman wrote:
  On Thu, Dec 20, 2012 at 11:08 PM, Greg KH gre...@gentoo.org 
 wrote:
   On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote:
   1. Are you party to any *copyright assignment* (eg FSF copyright
 assignment)?
  
   You need to rephrase this to be (in order for it to make any
 sense):
 Are you party to any *copyright assignment* that is not part of
 your
 employment agreement?
  
   Otherwise, everyone in the US, and most other countries, would
 almost
   always have to just say yes to this, as their employer owns the
   copyright for their work no matter what it is done on (open 
 source
 or
   not.)
  
  Work done for hire is certainly owned by the employer, unless an
  agreement to the contrary is explicitly documented, but employment
  agreements that purport to assign copyright for works unrelated to
  employment to the employer are rare.  Maybe they're not as rare in
 the
  software industry, but most people aren't employed in the software
  industry (even if most Gentoo developers might be - though perhaps
 not
  as a big a majority as you might expect).
  
  Certainly I haven't signed any kind of document that assigns
 ownership
  of works created on my own time to my employer, and the legality of
  any contract I did sign to that effect would be dubious.
 
 That's not true in the US, in fact, it's the exact opposite.  Your
 employer has ownership of all of your work, even done on your own
 time,
 unless you explicitly have permission otherwise, if it is done in an
 industry that is related to your employer.  Read the traditional US
 employment agreement for details about this.
 
 Yes, some states allow for exceptions to this rule, but those are the
 exceptions (California has some unique changes here).
 
 You might have signed these types of agreements when you were hired 
 by
 a
 company, and didn't realize it, it's usually quite well hidden in the
 agreement.
 
 Now this is all for the US, Europe has other types of laws, but they
 still assign ownership/copyright of what you do while being paid by
 those companies, to the company, and not to you.  Again, there are
 exceptions, but traditionally that is how they work.
 
   Remember, in the US, individuals who actually own the copyright 
 on
 the
   work they do is quite rare once they get out of college, and even
 then,
   while in college, the school does have the right to assert
 copyright
   ownership of the work, depending on what it was done on/for (who
   provided the equipment, tasks, etc.)
  

[snip]

This is typical for the UK too. My present employer regards my role in 
the Gentoo Foundation as 'employment'.  I had to show that there was no 
conflict of interests before I took up my paid job. 

General UK employment contracts go much further than copyright and
normally extend to any and all inventions created by the employee, 
including inventions made in their own time with their own resources.

 
 thanks,
 
 greg k-h
 
 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

pgpom4yRBTmZ3.pgp
Description: PGP signature


Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Roy Bamford
On 2012.12.17 16:02, Rick Zero_Chaos Farina wrote:
 On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
  Hi everyone,
 
  Give the talk on the list about attracting devs, I've should
  probably mention that I'm teaching a College Course on Gentoo 
  Development
[snip]

 Can I take this course online? Will the lectures be recorded?
 
 -ZC
 

I would be interested in an online version too.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpNo4gexStsn.pgp
Description: PGP signature


Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2012-12-17 Thread Roy Bamford
On 2012.12.17 15:15, Markos Chandras wrote:
 On 17 December 2012 12:31, Dirkjan Ochtman d...@gentoo.org wrote:
  On Mon, Dec 17, 2012 at 11:43 AM, Markos Chandras
 hwoar...@gentoo.org wrote:
  Outsource it to someone who has the knowledge and interest in 
 doing
  this. The foundation has the funds to support it, and none of us
  actually have the time to invest in a complete webpage redesign.
 
  If we have funds for this kind of thing, the PSF process is a good
 example:
 
  http://pythonorg-redesign.readthedocs.org/en/latest/
 
  (And I think that would be a great idea.)
 
  Cheers,
 
  Dirkjan
 
 
 I believe this is something that this[1] project needs to decide and
 set it in motion.
 
 [1]http://www.gentoo.org/proj/en/pr/website.xml
 
 -- 
 Regards,
 Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
 
 
 

To make this project a suitable project for Foundation funding, it 
needs a clearly defined specification that can be circulated for 
interested parties to provide fixed price quotations against.

The specification provides several things:-
1. the scope of work (out of scope work is extra cost)
2. the basis to judge completion (so we pay the fee)
3. some guidance as to implementation details

I know that 3. is unusual in a requirement specification but in this 
case it is unlikely that the Foundation would fund ongoing 
mainatainace, so we would need to dictate a few implementation details.
e.g. no Flash, Gentoo colours,

Its worth contrasting this sort of thing with a bug bounty.  The 
requirement is easy - fix the bug. Judging completion is fairly 
straight forward too. The patch is accepted by $UPSTREAM. 
The requirement specification for a website is a lot of work by 
comparison.

Suppose the team in [1] above wrote the specification, who needs to 
agree it?

The council, the trustees, the body of devs ... some combination of 
that list.  All in all, producing an agreed specification for a website 
it probably as much work as actually building the site. It could easily 
be as much work as the PMS. 

Anyway, I'm rambling a little.
In summary, if we decide to outsource the website project, it needs to 
be carefully controlled.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpTJWDmoCdNZ.pgp
Description: PGP signature


Re: [gentoo-dev] eudev project announcement

2012-12-15 Thread Roy Bamford
On 2012.12.15 03:52, Richard Yao wrote:
 Dear Everyone,
 
   I am pleased to announce the Gentoo eudev project. 
[snip]
 
 Yours truly,
 Richard Yao
 
[snip]

I welcome the choice that this new project brings, that's what Gentoo 
is about - choice.

I wish eudev both good luck and success.  Success comes in many forms, 
so I won't try to predict exactly what that means. Suffice to say, we 
will all recognise it when we see it.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpXmthqMgHAa.pgp
Description: PGP signature


Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

2012-11-25 Thread Roy Bamford
On 2012.11.25 13:44, Ulrich Mueller wrote:
  On Sun, 25 Nov 2012, hasufell  wrote:
 
  License issues seem trivial enough (at least regarding the
  functionality of an ebuild) to be fixed without permission of the
  actual maintainer.
 
 Certainly there are trivial license issues, but not all of them are.
 See bugs 436452 and 441734 for trivial examples, and bugs 440938 and
 12 for non-trivial ones. I think that it's better if bugs are
 filed for the second category, so that the change will be traceable.
 Also the maintainer should at least be informed in case the LICENSE
 change would remove the package from the @FREE license group.
 
  Even if the fix is wrong the ebuild remains intact.
 
  If someone feels uncomfortable about this proposal we could limit
  this permission to the license herd.
 
  Less bugs, quicker fixes.
 
 For the remaining trivial cases I'm fine with it either way. And
 there's no reason to limit the permission to the licenses team.
 
 Ulrich
 
 

From the point of view of the licencor, the licence is just as 
important as the code, so there are no trivial licence issues.
As a trustee, I am unhappy with losing the traceability at all.
Other trustees may have different opinions.

What seems trivial today, may not be trivial tomorrow if a licencor 
gets upset.
   
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpnkQh05fT1u.pgp
Description: PGP signature


Re: [gentoo-dev] fixing LICENSE issues without reporting bugs

2012-11-25 Thread Roy Bamford
On 2012.11.25 14:42, Rich Freeman wrote:
 On Sun, Nov 25, 2012 at 9:30 AM, Roy Bamford 
 neddyseag...@gentoo.org
 wrote:
  From the point of view of the licencor, the licence is just as
  important as the code, so there are no trivial licence issues.
  As a trustee, I am unhappy with losing the traceability at all.
  Other trustees may have different opinions.
 
 Not this one.  License issues can vary in severity, and there may be
 nuances that an outsider might not appreciate.
 
[snip]
 
 Rich
 

 
Rich,

That's my point - something serious may slip by without a bug.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpDPB0T8VgC0.pgp
Description: PGP signature


Re: [gentoo-dev] Re: RFC: virtual/libudev

2012-07-28 Thread Roy Bamford
On 2012.07.27 03:37, Duncan wrote:
[snip]
 
 Not that such promises hold much credibility anyway... see the kde 
 promise (from Aaron S when he was president of KDE e.v. so as 
 credible a  spokesperson as it gets) continued kde3 support as long 
 as there were 
 users.  (AFAIK, at least gnome didn't make /that/ sort of promise in
 the leadup to gnome3.  And no, AS cannot be properly argued to have 
 been 
 referring to others, like debian with its slow release cycles, as he
 was 
 president of kde ev, not president of debian, or of the trinity
 project, 
 which AFAIK didn't even exist at the time, and didn't specify support 
 from OTHERS, not kde, so he was clearly speaking for kde, not for
 other 
 entities.)
 
 -- 
 Duncan - List replies preferred.   No HTML msgs.
 Every nonfree program has a lord, a master --
 and if you use the program, he is your master.  Richard Stallman
 
 
Duncan,

You don't want to listen to Presidents too much.  Look at other real 
life examples.  

Would you claim that the President of the Gentoo Foundation speaks for 
Gentoo? 


-- 
Regards,

Roy Bamford
(Neddyseagoon)

Gentoo Foundation Inc. (President)



Re: [gentoo-dev] Re: Killing UEFI Secure Boot

2012-06-21 Thread Roy Bamford
On 2012.06.21 16:05, Richard Yao wrote:
 On 06/21/2012 11:00 AM, Ian Stakenvicius wrote:
  A firmware replacement for the BIOS does not need to worry about
  floppy drives, hard drives, optical drives, usb devices, isa
  devices, pci devices and pci express drives, etcetera, because
  those live on buses, which the kernel can detect. It would need
  a device tree to inform the kernel of what buses are available,
  but that would be specific to a given board, rather than what is
  attached to it. If the end user makes hardware changes, the
  kernel should be able to handle that, with the exception of
  changes involving RAM, which I believe go into the device tree.
 
  I take it the above statement is based on the kernel being
  directly placed within the BIOS/firmware/nvram on the board, such
  that you couldn't boot anything else but that kernel?
 
 That is correct.
 
[snip]

So when you build a dud kernel and flash your BIOS with it, and we all 
build the odd dud, your motherboard is bricked.

Now what?

Get out your JTAG adaptor and another PC I suppose. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgp8XbNre5giw.pgp
Description: PGP signature


Re: [gentoo-dev] Re: New license: yEd Software License Agreement

2012-04-28 Thread Roy Bamford
On 2012.04.27 18:38, Rich Freeman wrote:

[snip]
 
 Do we as a matter of policy want to respect broken click-through
 download implementations?
 
 Rich
 
Yes we do.

Intent it what counts in the eyes of the law in most places.
Sites with broken click-throughs intend for them to be used.


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees



Re: [gentoo-dev] rfc: location of portage tree

2012-03-29 Thread Roy Bamford
On 2012.03.28 08:46, Alex Alexander wrote:
 On Tue, Mar 27, 2012 at 02:05:54PM -0500, William Hubbs wrote:
  All,
  
  I know this has come up before, but I don't really recall what the
  specific objections were.
  
  IMO the portage directory doesn't belong under /usr at all.

[snip]

  William
 
 If/when this happens, we should also consider improving the internal
 structure of the portage folder. At the moment we just throw
 everything
 in it, which is not very user friendly. I recommend creating a
 subfolder
 for the actual tree, keeping distfiles and packages out.
 
 For example, my /usr/portage/ on this system looks like this:
 
 portage/
   tree/
   profiles/ - tree/profiles/
   distfiles/
   packages/
   layman/
 
 it is a big improvement over the current
 distfiles-and-packages-mixed-with-tree-while-layman-wanders state :)
 -- 
 Alex Alexander | wired
 + Gentoo Linux Developer
 ++ www.linuxized.com
 

Lets move packages/ out of there.  I share /usr/portage over NFS to 
several different arches.  Sharing /usr/portage/packages is a really 
bad idea in that set up. As they all run ~arch, they all build packages 
so I can downgrade quickly.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees



Re: [gentoo-dev] rfc: location of portage tree

2012-03-29 Thread Roy Bamford
On 2012.03.28 20:04, Rich Freeman wrote:
 On Wed, Mar 28, 2012 at 2:53 PM, Christoph Mende ange...@gentoo.org
 wrote:
 
  I believe it's /var/lib/name. Here's what FHS says:
  /var/cache is intended for cached data from applications. Such data
 is
  locally generated as a result of time-consuming I/O or calculation.
  The application must be able to regenerate or restore the data.
 Unlike
  /var/spool, the cached files can be deleted without data loss.
 
 
 I can do rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync and
 it will work just fine, I think.

That's pretty much what happened in a stage1 or stage2 install.
Its not cache though as you don't get back the same data as was 
deleted.  

Think 6 month old install.

 
 That really does point to cache.  The only thing different from a
 browser cache is that portage doesn't automatically refresh it.
 
 distfiles and packages are the same (well, depending on where you get
 your binpackages from, that might or might not be a cache per-se - if
 you're just using FEATURES=buildpkg then you can do an emerge -e 
 world
 and get it back).
Nope.  

If you have just done 
rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync, 
then   emerge -e world  gets you the equivelent of emerge --sync  
emerge world -uDN

Even if you haven't fetched a new tree, you have lost all your old 
binary packages, which you were keeping in case of a broken ~arch 
upgrade that needs to be reverted in a hurry. e.g. one of the nice big 
shiny packages that emerge -e world just updated for you.

[snip]

 
 Rich
 
 
 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees



Re: [gentoo-dev] Documentating advanced portage feaetures in Gentoo Handbook

2012-01-03 Thread Roy Bamford
On 2012.01.03 17:51, Sven Vermeulen wrote:
 Hi guys,
 
 There's a small discussion going on on gentoo-doc [1] about
 documenting (or
 not documenting) advanced portage features in the Gentoo handbook. 
 The
 suggestion currently is to have it as an added chapter in Working
 with
 Portage of which you can find a preview on [2] (don't mind the
 numbering).
 
 [1] http://archives.gentoo.org/gentoo-doc/
 msg_f3c1439def8cd1df8b0f57fdbb7e6462.xml
 [2] http://dev.gentoo.org/~swift/docs/previews/hb-portage-
 advanced.xml
 
 The discussion however is if it is okay to document these things 
 there
 or
 not. 
[snip]
 Thoughts? Suggestions?
 
 Wkr,
   Sven Vermeulen
 
 

Team,

The Gentoo Handbook is about getting the base system installed. 
As such features such as per package CFLAGS have no place there.  They 
are not within the scope of installing the base system.

We already have separate guides for Xorg, Gnome, KDE, ALSA, binary blob 
video drivers and so on. 

I agree these portage features should be documented but probably in a 
'bleeding edge' guide.

Our users will tinker and break things just because they can anyway. At 
least don't give them the means to make them difficult to help in the 
introductory Gentoo text.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpFnzRv5ItmE.pgp
Description: PGP signature


Re: [gentoo-dev] License for Google Chrome

2011-08-27 Thread Roy Bamford
On 2011.08.26 23:06, Mike Gilbert wrote:
 I have been maintaining an ebuild for Google Chrome in an overlay. It
 basically extracts a deb file to /opt. This serves as an easy
 alternative for people who do not have the patience to compile
 Chromium.
 
 Now that I have developer access, I would like to move this to the
 tree. Before doing so, I need some advice on how to deal with the
 EULA[1].
 
 I think clause 2.2 (B) allows me to avoid a fetch restriction.
 
 I think clause 5.3 prohibits mirroring.
 
 Do I need to worry about anything else here?
 
 [1] http://www.google.com/chrome/intl/en/eula_text.html
 
 

Mike,

You will need to add the licence to the tree as its a EULA.
The package will need to be masked by the licence.

If Google provide a click through licence agreement, complying with 
clause 2 is out of our hands. If not, licence masking should ensure 
that users read the licence before they install and subsequently use 
the package. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgppbhFEDuhtW.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoostats, SoC 2011

2011-08-25 Thread Roy Bamford
On 2011.08.24 11:48, Patrick Lauer wrote:
[snip]
 
 If you sneakily add something to cron.daily by default you can get
 pretty nice coverage. But I guess anyone trying that in Gentooland
 will
 meet some rather unpleasant resistance :)
 
 
 
 

This app and if its opt in or opt out will set a precedence for any 
future apps that want automatic user feedback in Gentoo

It has to be opt-in as opt out would be a dangerous precendent to set.

I don't see any harm is a gentle reminder message from emerge, provided 
that the reminder can be turned off too, if the user really does not 
want to opt in. Thats no worse than being nagged about unread news.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpz8BkPEPndt.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

2011-08-20 Thread Roy Bamford
On 2011.08.20 23:20, Rich Freeman wrote:
 On Fri, Aug 19, 2011 at 12:52 PM, Roy Bamford
 neddyseag...@gentoo.org wrote:
  As far as I am aware, under the current organisation there is no
 legal
  connection between the Gentoo Foundation Inc., and the Gentoo
  distribution.
 
[snip]
 
 Regardless of who can get sued, we should comply with the GPL
 regardless.  To that end I agree that we should refrain from shipping
 historical binaries unless we also tarball portage and the distfiles
 from the same period of time.  I definitely agree with his suggestion
 that we should always make both available online simultaneously to
 avoid the 3-year rule.
 
[snip]
 
 Rich
 
 

Rich,

There are two separate issue here and they have separate timescales for 
being addressed.  

We need to comply with the GPL now and always, so we should do as 
Duncan suggests.  Take down old binaries now and post sources with new 
binaries. e.g. the liveDVDs.

Sorting out our internal structure is a separate issue to address in 
slower time but it needs to be done before something goes wrong because 
there just won't be time then.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgppwoI3mHlpS.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

2011-08-19 Thread Roy Bamford
On 2011.08.19 07:50, Duncan wrote:
 Roy Bamford posted on Thu, 18 Aug 2011 17:41:15 +0100 as excerpted:
 
[snip] 
  Just as long as we can provide the patch sets for a period of at
 least
  three years, in case someone asks.  Thats a GPL requirement.
  
  Thats not to say the files need to be online but Gentoo needs to be
 able
  to provide them on request.
 
[snip]
 I know I didn't follow up to ensure it was done.  I hope someone did. 

 FWIW, the legal responsibility would (AFAIK) fall on the foundation,
 so it would presumably be their job to ensure this was done, and 
 from that  point, that previous media were taken down in a timely 
 manner so as not to get Gentoo in that situation once again.

[snip]
 -- 
 Duncan - List replies preferred.   No HTML msgs.
 Every nonfree program has a lord, a master --
 and if you use the program, he is your master.  Richard Stallman
 
That's a very interesting point.

As far as I am aware, under the current organisation there is no legal 
connection between the Gentoo Foundation Inc., and the Gentoo 
distribution.

The Foundation is a legally constituted NFP, registered in New Mexico.  
Gentoo the distro, has no legal body status at all, anywhere in the 
world.

You could make an argument that the Foundation 'owns' Gentoo as the 
Gentoo produced codebase is copyright the Gentoo Foundation Inc. 
However ownership is irrelevant. It does not confer control.
Control rests with the council, who have no legal ties to the 
Foundation.

Think of it as in this example.  A member of the English aristocracy 
owns a Rolls Royce.  It is kept in a garage at chauffeurs cottage so 
the chauffeur is the registered keeper of the car.

One day, the car driven by the chauffeur is involved in a accident and
someone is killed.  Who is prosecuted for the death, the owner or the 
chauffeur?
Well, the owner was clearly not in control (he wasn't driving). 

The total separation of 'ownership' and 'control' of Gentoo is 
fundamentally broken for the same reasons.  Enough of it here, its an 
active thread on  -project just now.
  
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpduKuVXJWcf.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds

2011-08-18 Thread Roy Bamford
On 2011.08.18 10:59, Anthony G. Basile wrote:
[snip]
 
 Understood that infra gets to complain, but that still doesn't tell 
 me
 what the deprecation policy is.  Keep all my large patchsets
 indefinitely? Or remove them when an ebuild no longer needs them?  Or
 1
 year after an ebuild no longer needs them?
 
 -- 
 Anthony G. Basile, Ph. D.
 Chair of Information Technology
 D'Youville College
 Buffalo, NY 14201
 (716) 829-8197
 
 
Just as long as we can provide the patch sets for a period of at least 
three years, in case someone asks.  Thats a GPL requirement.

Thats not to say the files need to be online but Gentoo needs to be 
able to provide them on request.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpLniAICC5Gs.pgp
Description: PGP signature


Re: [gentoo-dev] Council 2011 / 2012 election nomination

2011-06-08 Thread Roy Bamford
On 2011.06.08 01:50, David wrote:
 I nominate William Hubbs (williamh)
 --
 David Abbott (dabbott)
 Gentoo
 http://dev.gentoo.org/~dabbott/
 

David,

It has to be on gentoo-proj...@lists.gentoo.org or it doesn't count.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpdugPopnPER.pgp
Description: PGP signature


Re: [gentoo-dev] Test request: open-iscsi 2.0.872

2011-06-05 Thread Roy Bamford
On 2011.06.05 12:54, Sebastian Pipping wrote:
 Hello!
 
 
 Would be great to have a few people test open-iscsi 2.0.872 before
 moving it from overlay betagarden to the main tree.  To get it
 installed
 please run:
 
   # layman -a betagarden
   # emerge -av =sys-block/open-iscsi-2.0.872
 
[snip]
 Best,
 
 
 
 Sebastian
 
Sebastian,

In the good old days, stuff like this would just be added to the tree 
either hard masked or not keyworded, or both.

Why not still do that?

I won't be testing as I have no use for the package.
This is not a personal crit. I am just not a fan of overlays.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpVYTuopcfuS.pgp
Description: PGP signature


Re: [gentoo-dev] openrc portage news item

2011-04-30 Thread Roy Bamford
On 2011.04.30 01:34, William Hubbs wrote:
[snip]
 
 Also, this patch doesn't stop baselayout-2 from being installed, so I
 do
 not know what state it would leave a system in if you ran this and
 happened to upgrade baselayout, then reboot without installing 
 openrc.
 
 William
 
 

William,

I've been there and done that.  My firewall was blocking git as I 
thought I had no use for it, so I got baselayout2 but not openrc.
openrc was only available from git in 2007
I was late, so I just switched off and went to bed.

I had to back out baselayout2 and do it again.  Its was fairly easy for 
me as I keep binpackages of everything I build.  It still needed a 
liveCD boot.
 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpM8hqxKcRS8.pgp
Description: PGP signature


Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-08 Thread Roy Bamford
On 2011.02.07 20:50, Markos Chandras wrote:
[snip]

 My suggestion, as I said to fosdem, is to freeze, or take a
 snapshot if you like, of the current tree, stabilize what you need to
 stabilize, test the whole tree ( at least compile wise ) for a couple
 of weeks and then replace the existing stable tree. Of course this
 requires automated script testing, hardware facilities etc etc that 
 we don't have so claiming that stable tree is stable is quite 
 wrong.
 
 Regards,
 -- 
 Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
 

Markos,

This is exactly what releng used to do for installer CDs.  This was 
last used for 2008.0 CD/DVD. A snapshot of the stable tree was taken in 
February 200.8 and the release hit the mirrors in September.

The seven month test/fix/retest that it took meant that the CD would 
not boot on new hardware as the kernel lacked drivers.

You will find similar lags when releng used this approach for other 
earlier releases.

We would need to move to a release cycle like the kernel. Calling a 
feature freeze at the start of the test cycle. As we can't everything, 
we might as well distribute binaries of what was tested - just as 
releng used to do. 

To me thats not Gentoo as we would loose the rolling updates.
 
There are degrees of stable.  I believe most Gentoo users 
realise this fairly early on and stick with Gentoo because they like 
the balance it strikes between Debian stable and bleeding edge.
There is a price to pay for being more up to date and it a trade off 
Gentoo users are aware off. Of course, that does not prevent them 
bringing breakages to our attention. 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpXWHwIwNyRh.pgp
Description: PGP signature


Re: [gentoo-dev] avoiding urgent stabilizations

2011-02-08 Thread Roy Bamford
Markos,

A few thoughts inlined.

On 2011.02.08 12:03, Markos Chandras wrote:
 
My main point was that as you move from an old dated set of packages to 
newer packages which by definition are less well tested, stability 
decreases. Users pick somewhere between the two extremes that they are 
happy with. Gentoo stable lies somewhere between Debian stable and LFS 
built live from all the repositories.

 I see what you are saying. However, the 6 months testing is far from
 what I have in mind. 
Thats what releng used to take.

 My only intention is to bring a more stable
 experience to our users. Or, stop claiming that our stable tree rocks
 and Gentoo is perfect for servers because it is not. Ye ye ye I know
 that many many of you have Gentoo on servers but do not forget that
 you
 are developers and you know your way around during breakages. Yes,
 stable tree breaks FAR TOO often. I blame myself for my arch testing
 of
 course however I can't do much about that. 
[snip]

For servers I can point you at the stillborn Gentoo-LAMP project. I 
don't remember much more than its name. Google seems to have forgotten 
it too.

A big part of the problem comes from being a meta-distro. Everyones 
Gentoo is different and we we cannot test all combinations to ensure 
everyone is ok.

More testing will not eliminate the issue but would catch some 
problems. There would be less breakage but not zero.  There is a trade 
off to be made there by both the developers doing the testing and 
the users experiencing the breakage.

I agree that given more resources, the tree could be improved but 
before we move in that direction, I would like to ask is that the best 
use of resources?

As I said above, users are aware of the trade offs involved in choosing 
Gentoo. Are our users really unhappy, or are they just looking for help 
to fix issues when they occur?
Most users do not expect a zero issue upgrade path.

[snip]
 
 Our stable tree is definitely not suitable for server usage unless 
 you have plenty of free time to
 deal with stupid upgrades because nobody, for example, cared to write
 a
 proper elog or news item. 
[snip]
 
 Either you like it or not, arch teams are understaffed. All of them.
All of Gentoo is understaffed.

 Therefore we cannot afford a updated stable tree with high QA around
 it. We need to find a more efficient way to test packages on testing
 tree so we can mark them stable with minimal time and cpu cost. We
 need
 dedicated build boxes, like Diego's tinderbox, to test the testing
 tree
 over and over against critical/common/trivial QA problems. If we
 manage
 that, moving packages from testing-stable will be much more time
 efficient and we can guarantee a high quality stable tree.
If this means a more up to date stable tree, that has to be good as the 
stable tree will move closer to testing and there will be fewer 
packages to maintain.  (Counting different versions as packages)
 
 ps1: Personally I have stopped suggesting gentoo stable for server
 usage
 and I always suggest testing to new users.

I don't quite agree about not recommending Gentoo for servers. Gentoo 
is fine on servers but you need to run a testing environment for your 
updates so you know when you do do an update, exactly what in involved 
and what will happen.  Without your own testing, your server will go 
down from time to time. If you cannot do your own testing, either 
tolerate the downtime or don't use Gentoo.

 
 ps2: Roy, this is not a personal attack. Do not misinterpret my tone
 :)

I see no personal attack in your words. 
 
 Regards,
 -- 
 Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
 
I'll buy you a insert_refreshment_of_your_choice next time we meet.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgp1kdwTwgef8.pgp
Description: PGP signature


Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

2011-01-29 Thread Roy Bamford
On 2011.01.29 05:20, Jeroen Roovers wrote:
[snip] ...
 and that whoever feels to be in place to
 deal out QA (and I think this has gone wrong a few times recently) is
 required to:
 
 1) state and/or explain policy specifically where it is being not
 adhered to;
 2) offer alternatives where policy is not adhered to.
 
[snip] 
  jer
 

Which is another way to say that QA is everyones job.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpC3h3asIyGY.pgp
Description: PGP signature


Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

2011-01-28 Thread Roy Bamford
On 2011.01.28 23:03, Tomáš Chvátal wrote:

[snip]
 Only case where we don't want Devrel interfere with QA decision at 
 all
 is when someone Intentionaly breaks main tree. Seriously if someone
 really hit this issue i don't actually want him to apologize to
 another
 team and pretend like it never happened, i would prefer him long gone
 in
 a place far far away :) We really just want keep control over 
 removing
 access for people that does breakage to main tree just for the
 breakage
 itself, aka it can't be excused in any way.
 
[snip]

Its not QAs decision, if the breakage was intentional or not.  A single 
body, in this case, QA, cannot be both the police and the judicary.

QA can and should be capable of finding wrongs, preventing further 
damage and causing the problem to get fixed. Thats damage limitaion.
If preventing further damage involves revoking commit rights pending 
full investigation, thats fine by me.

Determining the root cause, and determining long term prevention takes 
some investigation. QA may present evidence but its Devrels job to 
weigh the evidence and pass sentence.

 Tom
 


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpFLUpGEZkmr.pgp
Description: PGP signature


Re: [gentoo-dev] Re: On hosting self-produced distfiles

2011-01-21 Thread Roy Bamford
On 2011.01.20 02:55, Diego Elio Pettenò wrote:
 Il giorno mer, 19/01/2011 alle 20.07 -0500, Rich Freeman ha scritto:
  Forward going?  Or, should we go ahead and start retroactively
  updating ebuilds that have mirror:// in them right now?  Presumably
  without a revbump over something like this...
  
 
 I wouldn't mind if it was done retroactively, but I'm not going to 
 ask
 right now for all the ebuilds in tree right now to be converted. If
 you
 do happen to pass through a bunch of old ebuilds and edit them anyway
 please do update them to use long-term-reachable URLs.
 
 -- 
 Diego Elio Pettenò — Flameeyes
 http://blog.flameeyes.eu/
 

Diego,

A few questions ...

How does this work when a developer leaves and his account is removed.  
This will break the links to ~/public_html.

What about our GPL obligations to provide sources?
That carries on even after an ex developers ~/public_html has been 
deleted.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpBmJ00REpD5.pgp
Description: PGP signature


Re: [gentoo-dev] Deprecate EAPIs 1 and 2?

2011-01-02 Thread Roy Bamford
On 2011.01.02 16:02, Petteri Räty wrote:
 On 01/02/2011 05:19 PM, Jorge Manuel B. S. Vicetto wrote:
 
  
  
  One way we could drop EAPI 0 would be if we do a major review of
 tree
  and repo formats to improve upgrade paths, which would however
 likely
  require breaking backwards compatibility at such point.
  I believe such a change would only be acceptable, if we would pack
  enough features and safety measures that it would ensure another
 break
  would not need to be done for a long time.
  
 
 It's quite likely that if you are currently on a system with Portage
 that does not understand EAPI 1 there's so many obstacles along the
 upgrade path that a clean install makes more sense. Maybe someone is
 willing to test this so that we actually know if there is an upgrade
 path from EAPI 0 available any more.
 
 Regards,
 Petteri
 
 

There is an upgrade path from a pure EAPI0 system but it starts with a 
visit to the tinderbox as portage and python block one another.

Some other interesting things along the way:- 
You need to incrementally update gcc and glibc as there is some 
mutual blockage there too.
libpng-1.2, xorg and libexpat too if the box is old enough. How far do 
you want to go back? 

Its a very educational experience but a reinstall is faster.
The real killer is that some core system packages need EAPI0 to build.

Personally, I don't regard tinderbox as any part of any officially 
supported upgrade path.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgp5vUVecLO99.pgp
Description: PGP signature


Re: [gentoo-dev] Technical talk ideas for FOSDEM

2010-12-13 Thread Roy Bamford
On 2010.12.12 21:05, Markos Chandras wrote:
 On Sun, Dec 12, 2010 at 10:50:55PM +0200, Petteri Räty wrote:
  I tried getting input for talks from gentoo-user but so far there
 have
  been no responses. Currently there aren't that many talks proposed
 for
  the distribution miniconf so it should be easy to get purely Gentoo
  related topics in. So what kind of Gentoo related talks would you
 like
  to see and possibly would attend at FOSDEM? Please present your
 ideas
  and I will then try and find speakers + get them submitted.
  
  Regards,
  Petteri
  
 Hi Petteri,
 
 I would be interested in a topic related to the current status of the
 project. Are we in the same state that we used to be e.g. 4 years 
 ago?
 If yes, what is our future strategy and plans? If no, why? Which 
 areas
 are our weakest link? Why we are not as strong as we used to be?
 I do not want to attent another presentation
 saying ye ye use flags, optimization, cflags etc. I am looking for 
 a
 more realistic and abstract approach for the project overall.
 
 -- 
 Markos Chandras (hwoarang)
 Gentoo Linux Developer
 Web: http://hwoarang.silverarrow.org
 Key ID: 441AC410
 Key FP: AAD0 8591 E3CD 445D 6411  3477 F7F7 1E8E 441A C410

Markos,

Interesting - How can you address future strategy and plans without 
addressing Gentoos meta structure too. It could not be a purely 
technical talk ... but thats what interests me.

It might be very Gentoo specific though.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgpa8UBK4v9Qf.pgp
Description: PGP signature


Re: [gentoo-dev] install media and USB debugging

2010-12-11 Thread Roy Bamford
On 2010.12.11 09:26, Andrea Conti wrote:
 Hi,
 
 (First of all: I'm not sure this list is the right place to ask. If 
 it
 
 is not, feel free to point me in the right direction)
 
 Is there a specific reason why the kernel on the install media is
 built 
 with CONFIG_USB_STORAGE_DEBUG=y ? This has the nasty side-effect of 
 completely overwriting the kernel log buffer with junk when booting
 from 
 a USB cdrom drive.
[snip]
 
 Andrea
 

Andrea,

Please file a bug at bugs.gentoo.org
That will get into the right developers work queue

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees


pgp79A9y5OpPV.pgp
Description: PGP signature


Re: [gentoo-dev] EAPI versioning of files in profiles

2010-11-01 Thread Roy Bamford
On 2010.11.01 17:06, Arfrever Frehtes Taifersar Arahesis wrote:
 I would like to suggest improvement in handling of EAPI in profiles:
 Some files could optionally end with :${EAPI}, 

[snip]
 
 -- 
 Arfrever Frehtes Taifersar Arahesis
 

Why does this remind me of GLEP55 ?

If we are going to add metadata like this, or some other way, lets make 
it consistent throughout the tree.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees




Re: [gentoo-dev] FOSDEM 2011

2010-08-26 Thread Roy Bamford
On 2010.08.26 13:07, Alex Legler wrote:
 On Thu, 26 Aug 2010 11:01:27 +0200, Markus Duft
 markus.d...@salomon.at wrote:
 
  booth registration is not yet open, i will have an eye on this
 too...
  (is there any interest in it anyway? who could come up with flyers,
  cds, etc.?)
  
 
 The Gentoo e.V. has printed flyers a year ago. There should be plenty
 left, especially in English. Talk to rbu, sping or hollow. Also,
 there's other stuff like T-Shirts, see
 https://www.gentoo-ev.org/wiki/Events for a few pictures.
 
 As for CDs, we've used the 10.1 LiveDVDs, simply burned to DVD-R, but
 with a nice printed label. You can expect to hand out at least 35 per
 day (we gave them to people for free after a short chat).
 
 -- 
 Alex Legler | Gentoo Security / Ruby
 a...@gentoo.org | a...@jabber.ccc.de
 

Team,

The Foundation could fund flyers and CD/DVDs if there is some 
organisation, a shipping address and so on. There some guidelines at  
http://www.gentoo.org/foundation/en/funding-request-policy.xml

Will there be a new DVD?
10.1 is about a year old already.

I'm not making a funding offer on behalf of the trustees, that will 
require a trustees vote, just pointing out a possibility.

I might get there this year but I won't know until Christmas.
 
-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees




[gentoo-dev] Council Election Results

2010-07-04 Thread Roy Bamford
Team,

The four election officials have determined that result of the 2010 
council election, in order of votes cast is :-

Final ranked list:
ferringb
halcy0n
jmbsvicetto
chainsaw
betelgeuse
scarabeus
wired
patrick
phajdan.jr
sping
_reopen_nominations


On behalf of the election offcials

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees




  1   2   >