Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Robert Bridge
Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 09:36:29 -0700
 Joe Peterson lava...@gentoo.org wrote:
 2) it makes sense to have these in the filename, but not
 internal meta-data
 
 For those of us who understand the process, it makes sense to have EAPI
 in the filename too.

Which seems to be an enlightened few who... How did we manage before you
graced us with your presence?!

*humbly prostrates myself before this paragon of enlightenment*

Robbie



Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-24 Thread Robert Bridge
Ciaran McCreesh wrote:
 On Tue, 24 Feb 2009 21:17:57 +
 Except that once we have EAPI in the file extension, we can change
 anything we want in arbitrary ways without having to worry about
 backwards compatibility, so we won't need silly hacks.

Like the file name structure?



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Robert Bridge
Petteri Räty wrote:
 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   b) .eapi.ebuild
 - current Portage does not work with this
   c) .eapi.new extension
 - ignored by current Portage

I have been thinking about this specific option. I will admit I don't
know if this has already been noted, but would this create the
possibility of multiple ebuilds with the same $C/$P-$PV?

Currently the filesystem enforces the uniqueness of that tuple, will
that uniqueness be allowed to lapse? (i.e. allow multiple ebuilds for
the same $C/$P-$PV with different EAPIs?)

If not, how is anyone proposing to enforce the uniqueness here?

Just a silly thought...
RobbieAB



Re: [gentoo-dev] Retiring

2009-05-05 Thread Robert Bridge

Markos Chandras wrote:
Some one could say Post it on gentoo.org homepage. I wonder if users ever 
visit that page to read gentoo news :\


I can safely say that some never do...

RobbieAB



Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Robert Bridge

Patrick Lauer wrote:

On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:

On Thu, 14 May 2009 20:06:51 +0200

Patrick Lauer patr...@gentoo.org wrote:

Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=

Uh, so horribly utterly and obviously wrong.

inherit foo
EAPI=4

where foo is both a global and a non-global eclass that sets metadata.


Interesting, but quite subtly wrong. I'm surprised that you try to slip such 
an obvious logical mistake in in an attempt to save your arguments.


Patrick, in the interest of making this comprehensible to the average 
schmuck like me, which you seem to be trying to do, could you actually 
explain WHY this is wrong? Otherwise it looks like you are simply trying 
the arrogant I am right because I say so line.



If you're looking for a formally correct alternative that works in the
way you suggest, I already provided one, and you already read about it
-- and it still doesn't solve the problems that 55 does.


And glep55 doesn't solve the problem either. It's neither formal nor correct, 
plus in this case ... what on earth are you trying to communicate?


Again, see my previous comment.


We can encode all the relevant info in the first line of the ebuild
starting with EAPI=

No we can't. That's *obviously* completely wrong.

It's obviously quite specifically not. Can you show any case where that fails 
or where adding this restriction removes relevant functionality?


Both of you need to explain your opinions here.


Just my thoughts,
R.



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Robert Bridge
Speaking as a user, I seem to recall having multiple versions of python
installed in the past, and never really knowing or caring which version was
being used so long as stuff worked. If you want to install python-3.14159 in
the stable tree, than go right ahead, so long as anything that doesn't work
with python-3 can still access python-2 and does so without me knowing, it
doesn't matter.

So the question isn't SHOULD python-3 be stabilised, it's what will break if
it is surely?


Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

2008-06-10 Thread Robert Bridge
On Tue, 10 Jun 2008 02:58:54 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

  Well, in general, if you rely on extensions changing every time a
  program cannot deal with a new feature of a file format, it would be
  quite crazy.  For example, if C programs had to start using .c-2,
  .c-3, etc., it would get ugly fast.
 
 Which is why programs that use any major C feature introduced since
 1980 use the extension '.cc' or '.cpp'.

Except any program using .cc or .cpp for code is liable to break on
gcc, as they are C++ file extensions, and to the best of my (admittedly
limited knowledge) C and C++ are distinct languages...

So relying on the file extension seems to be a recipe for
misunderstanding. Why limit the functionality of the package manager to
rely on the file names? How do you protect the package manager from a
malicious ebuild masquerading under the wrong EAPI? Relying on the file
name for information is the kind of design decision we laugh at in
Windows, so why adopt it here?
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

2008-06-19 Thread Robert Bridge
On Thu, 19 Jun 2008 12:11:11 +0100
Roy Marples [EMAIL PROTECTED] wrote:

 On Thursday 19 June 2008 02:43:12 Chris Gianelloni wrote:
  Nope.   What I see as a problem is that the primary author and
  current de facto maintainer is so much of an asshole that he was
  forcibly removed from the Gentoo project, which PMS is supposed to
  be written for, and has ostracized (at least) one of the package
  manager's development team with his constant not-so-subtle
  attacks.  Quite frankly, I'd prefer see Gentoo take control over
  the specification that defines the most important single feature of
  Gentoo and remove the non-Gentoo developers from its development.
  No offense, but you're not a Gentoo developer any longer and you
  shouldn't have a say in how *we* manage ourselves.  You're more
  than welcome to contribute code, fork, or whatever the hell you
  want.  This is open source, after all, but that doesn't mean you
  should be allowed to hold the position of power over Gentoo that
  you've been granted.
 
 I would like to see Gentoo grow some balls and start banning people
 from -dev and other media used. I don't mean temporary bans, I mean
 for life.
 
 Yes, it's not nice. Yes, Gentoo should be open for all and encourage 
 participation from all. However, some people have demonstrated time
 and time again over quite a number of years that they wont change no
 matter what. These people are posionous [1].

Slightly ironic for me to suggest this, but...

It is the gentoo-dev mailing list, restrict posting to gentoo devs
(i.e. only people with a @gentoo.org email address) would make a lot of
sense.

Rob.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Assigning bugs back to bug-wranglers@

2008-06-30 Thread Robert Bridge
On Mon, 30 Jun 2008 12:52:02 -0500
Jeremy Olexa [EMAIL PROTECTED] wrote:
 On a side note: How is the b-w SOP doc coming? It is obvious to me
 the b-w is tedious a time consuming so I would like to help every now
 and then but I really am not sure about the rules wrt assignment just
 by looking at metadata.xml. IMO, b-w'ing is something that anyone can
 do.

I would be happy to give it a try if there is an SOP doc to follow. I
may not be a dev, and I'm certainly not massively skilled technically,
but if I can bw a few bugs, it's a few less for the good bw. :)

Rob.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] ICC Profile

2008-07-17 Thread Robert Bridge
On Fri, 18 Jul 2008 11:34:11 +0900
Luca Barbato [EMAIL PROTECTED] wrote:

 Adam Stylinski wrote:
  The intel C Compiler (icc)
 
 icc, xlc, llvm, sunstudio could be interesting fields of discovery.
 
 Which are the pitfalls of using icc?
 
 lu
 

If I recall correctly, needing some packages compiled with ICC flags
set one way, and needing others compiled with the same flag set the
oter way.

Can it compile a kernel yet?

Rob.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Robert Bridge
On Fri, 18 Jul 2008 16:30:20 +0200
Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:

 IMHO it would be better to teach users to explicitly specify
 '@system' during updates, e.g. `emerge -uDN @system @world`.

Why not just re-instate the implicit dependency of world on system?

Rob.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Robert Bridge
On Fri, 18 Jul 2008 15:16:18 +0100
Sébastien Fabbro [EMAIL PROTECTED] wrote:

 There was some attempts a few years ago for rolling up a full Gentoo
 with icc, but it hit several problems if I recall. Now both icc and
 gcc have improved since then.

Including needing package specific CFLAGS because some packages in
@system needed mutually exclusive flag settings. 

I'll see if I can dig up the link for an old blog on the topic later.
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.

2008-08-16 Thread Robert Bridge
On Sat, 16 Aug 2008 09:17:10 +0200
Aniruddha [EMAIL PROTECTED] wrote:

 Borg hasn't  been updated in portage for a while despite the fact that
 new versions were released over a year ago (see
 http://bugs.gentoo.org/show_bug.cgi?id=184699 ). Therefor I suggest
 app-office/borg gets removed from portage.

Why not put together an ebuild for a recent version? 

If there are no major changes, an ebuild will probably get it updated
quickly enough, in my experience.

Rob.



Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.

2008-08-16 Thread Robert Bridge
On Sat, 16 Aug 2008 18:42:35 +0200
Aniruddha [EMAIL PROTECTED] wrote:

 I've filed the bugreport (version bump) a year ago. It looks like borg
 has no maintainer.

So maintain it. You don't need to be a dev to write an ebuild, and
there are enough devs who are happy to throw an eye over user donated
ebuilds and commit them to the tree...

Removing a package from portage simply because no one has commited the
up-to-date version you want is silly. If the only problem is
no version bumping, provide the ebuild. Someone will commit it. I've
done that for a few packages, it's not hard. 

I don't know anything about borg specifically, but as a user, I would
not want to see packages being removed from portage just because the
devs are too busy to write version bump ebuilds.

Rob.



Re: [gentoo-dev] License Interpretation

2008-08-20 Thread Robert Bridge
On Wed, 20 Aug 2008 15:10:18 -0400
Jim Ramsay [EMAIL PROTECTED] wrote:

IANAL, but the following line is critical:

 it is essential to do so in order to
 achieve operability of the Software with another software program, and
 you have first requested Adobe to provide the information necessary to
 achieve such operability and Adobe has not made such information
 available.

Given the situation as you outline it, I think the sub-section above
expressly permits the binary patch.

The request has been made, Adobe have not co-operated, that clause has
been invoked...

At least, that's how I would read it.

Rob.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

2008-10-02 Thread Robert Bridge
On Wed, 01 Oct 2008 09:37:25 -0700
Zac Medico [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Ryan Hill wrote:
  On Mon, 29 Sep 2008 22:31:46 -0700
  Zac Medico [EMAIL PROTECTED] wrote:
  
  Can package.use syntax be extended to allow set entries?
  @compiz-fusion -gnome kde kde4
  Perhaps, but we need to clarify how that sort of setting will
  affect nested sets. For example, if @compiz-fusion contains nested
  sets, would those USE settings apply to the nested sets as well?
  Will nested sets be allowed to have independent USE settings from
  the sets that nest them?
  
  Maybe a nested set could inherit the USE flag settings of its
  parent set unless it has its own entry in package.use.
  
  Though what happens if a package is in both sets which have
  conflicting flags in package.use?  I would say that the nested set
  has to have priority.  If not, I can easily imagine people getting
  confused when their USE settings for a set are being applied to all
  but one or two packages.
 
 It seems to me that the most logical approach would be to do some
 sort of incremental stacking, similar to the way that USE flags
 stack in the profiles. Suppose that we have the following settings
 in package.use:
 
  @kde-metafoo bar
  @kdeedu-meta -foo
 
 If the flags are stacked incrementally, analogously to the way that
 they are stacked in profiles, then the above setting would apply the
 foo and bar flags to all of @kde-meta except for the
 @kdeedu-meta subset which would only have bar applied since foo
 has been disabled incrementally. Does this approach seem reasonable?

From a lowly users perspective, I would say this is more intuitive. It
fits with the expected policy of the closest flag to the package taking
precedence...

Rob.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

2008-10-10 Thread Robert Bridge
On Fri, 10 Oct 2008 17:56:37 +0200
Marius Mauch [EMAIL PROTECTED] wrote:

 On Fri, 10 Oct 2008 14:48:19 +0200
 Fabian Groffen [EMAIL PROTECTED] wrote:
 
  Whatever.  Some of you seem to have some quite agressive dislikement
  to it.  In the end it's just a name/tag.  I guess I could live with
  anything, including c3p0.
 
 Well, while I dislike x64 I'm more concerned about using different
 names (amd64 and x64) for the same architecture (same would apply if
 you had used i386 or ia32 in some cases instead of x86) and was just
 checking if there was any functional reason for that difference.

I would agree with this.

As a user coming to the project, x64 is NOT the same arch as amd64, it
has a different name! Select one name for the arch, and use it
everywhere. Consistent naming is more important than having the name
absolutely technically correct.

And seeing as Gentoo uses amd64 for all those arches in the main tree
with minimal problems, I personally would vote for using amd64 in -alt
to retain consistency with the rest of Gentoo.

Just my 2 cents.

Rob.


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: Adding lxde-base category

2008-11-01 Thread Robert Bridge
On Sat, 01 Nov 2008 12:05:54 +0100
Ben de Groot [EMAIL PROTECTED] wrote:

 Hi,
 
 I would like to add a new category to the tree: lxde-base, to be used
 for the LXDE desktop [1,2] packages, in correspondence to the
 categories for the other desktop environments we have (gnome, kde,
 xfce). With the help of a few users I have been developing ebuilds
 for these packages in the lxde overlay [3], and I would like to move
 the ebuilds for the release versions into the official tree now. (The
 overlay also contains live svn ebuilds.)
 
 LXDE currently has 14 packages that would go into this new category,
 which is comparable to what xfce-base has. It also uses x11-wm/openbox
 as default WM, and x11-misc/pcmanfm as default filemanager, although
 these can be easily swapped for others.
 
 Comments are welcome!

As a use who looked at LXDE for older machines, but decided that not to
mess around with overlays on otherwise stable x86 boxes, can I vote for
this?

 1: http://lxde.org/
 2: https://bugs.gentoo.org/157989
 3: http://www.bitbucket.org/yngwin/lxde-overlay/src/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Adding NETBEANS to USE_EXPAND

2008-11-19 Thread Robert Bridge
On Wed, 19 Nov 2008 19:03:12 +0100
Miroslav Šulc (fordfrog) [EMAIL PROTECTED] wrote:

 I'd like to add NETBEANS to USE_EXPAND. Netbeans (www.netbeans.org) is
 modular IDE with 18 modules (clusters). Users can freely choose what
 support thay want to build in netbeans, though some modules need other
 modules to compile and work. Are there any objections?

As a sometimes programmer who prefers Eclipse, would it be an option to
do something similar for that IDE?

This obviously leads to the question of when does a package qualify for
such an option instead of using a set of regular USE flags...

Just a few thoughts,
RobbieAB.


signature.asc
Description: PGP signature


Re: [gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Robert Bridge
On Sat, Jul 31, 2010 at 4:09 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 On 7/31/10 4:37 AM, Hanno Böck wrote:
 Though we might discuss if vpx is really a good name or it shouldn't be vp8.

 It might also be webm. Not sure what's more intuitive for people. Also,
 nteresting question would be whether to enable the flag by default an in
 which profiles (desktop?).

Speaking as a user, I would ask what the standard file ending is? Most
users won't know what the codec is, they will just know is foo.webm or
foo.vpx/8.

Just a thought if debating the name.

RobbieAB.



Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-21 Thread Robert Bridge
On Thu, 21 May 2020 at 09:47, Michał Górny  wrote:

>
> Option 1: IP-based limiting
> ===
>

Preface this with IANAL, check with your own legal counsel...

While IP address based methods might be attractive  technically, do
remember that an IP address is considered Personally Identifiable in
European Data Protection law.

The fact submissions require an action by the user will probably be
sufficient to be explicit consent, any system storing these details should
allow for the use to revoke their consent: If you collect anything
personally identifiable, you will need to provide a mechanism for users to
request the removal of all their submissions.

Tread carefully with this project. :)


Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-21 Thread Robert Bridge
There are only 4 billion to reverse, not that hard really with a rainbow
table...

On Thu, 21 May 2020 at 13:08, Michał Górny  wrote:

> On Thu, 2020-05-21 at 13:57 +0200, Ulrich Mueller wrote:
> > > > > > > On Thu, 21 May 2020, Robert Bridge wrote:
> > > On Thu, 21 May 2020 at 09:47, Michał Górny  wrote:
> > > > Option 1: IP-based limiting
> > > > ===
> > > >
> > > Preface this with IANAL, check with your own legal counsel...
> > > While IP address based methods might be attractive  technically, do
> > > remember that an IP address is considered Personally Identifiable in
> > > European Data Protection law.
> > > The fact submissions require an action by the user will probably be
> > > sufficient to be explicit consent, any system storing these details
> should
> > > allow for the use to revoke their consent: If you collect anything
> > > personally identifiable, you will need to provide a mechanism for
> users to
> > > request the removal of all their submissions.
> > > Tread carefully with this project. :)
> >
> > You don't have to store any IP addresses, you can store a cryptographic
> > hash like their b2sum (salted if necessary).
> >
>
> Yes, this is as great as storing hashes of phone numbers ;-).
>
> --
> Best regards,
> Michał Górny
>
>