On 13 Jun 2008, at 12:18, Nirbheek Chauhan wrote:

"We're writing a spec that's somewhat like Portage, but where it
breaks Paludis, we prefer to get Portage to change it's behaviour
instead. Don't crib about this however. We could just have easily have
created a whole new spec which broke Portage completely."


Care to give an example instead of FUDing? Paludis is written to match
PMS, not the other way around. And when PMS changes, Paludis is
changed to reflect such changes.


Don't be childish.

- ferdy

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

On Fri, 13 Jun 2008 15:52:30 +0530
"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> >> Interesting to note, however, that Paludis doesn't accept inline
> >> comments, and this behaviour predates PMS.
> >
> > Paludis behaviour there matches Portage behaviour at the time it was
> > written, except that instead of proceeding with garbage values,
> > Paludis gives an error.
>
> Well, then it should be updated to match current Portage behaviour.
> PMS is not supposed to document "How portage worked at one point of
> time" or "The intersection of the capabilities of Portage and
> Paludis". It should follow the current portage's behaviour as closely
> as possible.

Do you really want to make it impossible to install Gentoo using the
most recent official release? Because that's what will happen if we do
what you're suggesting...

--
Ciaran McCreesh

On Friday 13 June 2008 11:23:29 Nirbheek Chauhan wrote:
> On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
> > There's a reason for Paludis not accepting them, and the same reason
> > applies to the question of allowing them in PMS or not, therefore PMS
> > doesn't allow them. There's no evil conspiracy here, just pure logic.
>
> Then I believe we would all like to know the reason why.

The same reason the Ciaran already explained in this very thread.
--
gentoo-dev@lists.gentoo.org mailing list

On Fri, Jun 13, 2008 at 11:32:20AM +0100, David Leverton wrote:
> On Friday 13 June 2008 11:23:29 Nirbheek Chauhan wrote:
> > On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
> > > There's a reason for Paludis not accepting them, and the same reason
> > > applies to the question of allowing them in PMS or not, therefore PMS
> > > doesn't allow them. There's no evil conspiracy here, just pure logic.
> >
> > Then I believe we would all like to know the reason why.
>
> The same reason the Ciaran already explained in this very thread.

Ciaran/Company actually are subtly wrong on this one. Reason is
miscommunication/misreading.


Quoting the original flamebait posting by patrick-

"""
Test case is:

FEATURES="strict" # test and stricter fail

in make.conf ... <flamebait>
"""

Note 'make.conf'. User configuration.

Not make.profile, or any other profile file.

Meaning not under PMS jurisdiction, via the line in the sand ciaran
has drawn to exclude portage configuration from PMS.

Now if the discussion *was* about profile files, yes, inline comments
are not allowed due to backwards compatibility requirements.

In other words, ciaran is wrong about make.conf, but right about
make.defaults and friends, which is what he probably interpretted the
thread about. Screwups happen, unfortunately w/ the air of gentoo-dev
being one of hostility, it sprawls into mega-threads like this.

Either way, this isn't particularly relevant to -dev; belongs on
-project at best, else the paludis mls due to it being a discussion of
paludis incompatibility with existing portage configuration support.

Hopefully the statements above clear up any further reason for this
thread to continue, so kindly leave it dead/buried.

Cheers,
~harring

"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> posted
8b4c83ad0806130322s560c4fb7u70cd03964108723c@mail. gmail.com, excerpted
below, on Fri, 13 Jun 2008 15:52:30 +0530:

> Well, then it should be updated to match current Portage behaviour. PMS
> is not supposed to document "How portage worked at one point of time" or
> "The intersection of the capabilities of Portage and Paludis". It should
> follow the current portage's behaviour as closely as possible.

Ciaran's right on this one. It may have been a bug in portage, now
fixed, but at least until a stable current release media set, a working
PMS can't change the EAPI-0 definition to fail with portage on the old
release media, however stale it might be. If a current release happens
before PMS EAPI-0 finalization, this could possibly be subject to debate,
but until then, it just doesn't work, however much we might wish it could.

Additionally, he and Brian both agree (!!) that out-of-tree portage
config is outside the PMS domain, so the make.conf example doesn't have
anything to do with PMS in any case.

Anyway, I agree with Brian in a different subthread post. The council
has met and this thread and discussions on it are stale, so best to let
it die. I'd have not replied here except after my earlier negative
posts, I felt the need to provide some balance, and take the opportunity
to point out that here, the Paludis devs are right, both practically
(breaking new installs) and theoretically (out of PMS domain).

--
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

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

On Fri, 13 Jun 2008 11:06:01 +0930
Iain Buchanan wrote:

> On Thu, 2008-06-12 at 21:16 -0400, David Relson wrote:
> > On Fri, 13 Jun 2008 09:23:51 +0930
> > Iain Buchanan wrote:
> >
> > > David - at this point I'd try a couple of things. Since you've
> > > upgraded your linux-headers, it's a good idea to recompile your
> > > system libc, as per the elog message.
> > >
> > > Also, since you're getting version error messages, recompile your
> > > kernel and reboot into it. Just to make sure, as you've just done
> > > headers and libc (may be a long shot, but may as well rule it
> > > out).
> > >
> > > Then unload all vm* modules and recompile them also. (Say no to
> > > all vmware-config questions first, then second time around say
> > > yes!). If it doesn't work, downgrade to a previous version of
> > > modules and try them. I use vmware-modules-1.0.0.11-r1 because
> > > that's the only version that works with workstation 4, which I
> > > have a license for.
> > >
> > > Finally, if this all still fails, try with an earlier kernel and
> > > see if it magically works. Then you know it's probably a new
> > > kernal feature thats bugging you!
> > >
> > > I hope you have a few spare clock cycles for all this compiling
> >
> > Hi Iain,
> >
> > I've been using 'uname -r' and its reporting '2.6.25-gentoo-r4'
> > matches the module path,
> > i.e. /lib/modules/2.6.25-gentoo-r4/misc/vmnet.ko, in the "invalid
> > module" message. I'm as certain as can be that there's no mismatch
> > here.
>
> don't be so sure! Do you know that you won't get the same message if,
> for example, you used different compilers for the kernel and the
> module? In my experience, this message can appear when the actual
> kernel number is ok, but it's been compiled differently...
>
> > Also, I've removed all vm* packages and reinstalled vmware-server
> > (and whatever it pulls in, i.e. vmware-modules). This was done
> > after removing all vmware entries from /etc/portage/package*, so
> > the vm* packages are all stable versions -- no ~amd64 versions.
> >
> > Haven't tried rebuilding glibc ...
> >
> > Instead I've installed the latest stable amd64 versions of 2.6.24
> > sources and headers. The kernel is now being built. I should know
> > before too long whether this helps.
>
> good! Let's see what happens...

I've reverted to 2.6.24, emerged vmware-modules, run vmware-config.pl
and am pleased to report that the vmware-modules are loading without
complaint and that vmware-server is running.

I did _not_ disable CONFIG_MODVERSIONS or rebuild glibc.

Regards,

David
--
gentoo-user@lists.gentoo.org mailing list

On Thu, 2008-06-12 at 11:39 +0200, Fernando J. Pereda wrote:
> On 12 Jun 2008, at 04:16, Brian Harring wrote:
> >
> > Why the exherbo/paludis/PMS folk decided to go this route to report,
> > I'm not quite sure aside from assuming they're just griefers.
>
> s-exherbo/paludis/PMS-pkgcore-g and:
>
> http://fpereda.wordpress.com/2008/05/03/on-cooperating-and-paludis-vulnerability/
>
> Except this one wasn't a lie.
>
> I wish there were more cooperation between all of us. But looks like
> it is impossible with some of your people.
>
> - ferdy
>

Please stop whoring the url for that, its old already. There is a huge
difference between that and knowingly witholding information because you
"want to see unit tests done." Quit being a fuckwit.

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

Hi,

I would like to add both keytouch and keytouch-editor to [extra]. I
currently maintain them in community. I am currently cleaning up my
packages in AUR/community and considering moving most (perhaps all) of the
remaining to extra to centralize my packaging to the official repos. I'll
let you know at the time, for now it's just keytouch and keytouch-editor
that I plan to move. At last, keytouch and keytouch-editor have 48 and 44
votes, respectively.


Any objections?

Thanks,
Eric

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

В Чтв, 12/06/2008 в 09:36 +0200, Markus Ullmann пишет:
> The PMS maintainers were withholding information on compatibility
> issues they've seen. As such we can't be sure this will pop up again
> in the future and so I strongly suggest dismissing this as something
> official for gentoo.

Dismissing does not fix PMS. Since PMS requires some specific
knowledge about package manager (PM) internals only few people can
decide on this matters and do actual work. I think what council could do
is to formalize PMS process and thus move from this "draft" point.

By formalizing I mean the following: call for and form PMS team. Team
must represent portage developers and could paludis and pkgcore. All
suggestions for PMS draft must go into bugzilla and after patch for PMS
is created PMS team members should vote on that patch. After voting
patch is applied or discarded. Until there are open bugs in bugzilla
council can not approve PMS.

Of course this is just a sketch of idea. I'm not expanding it and not
trying to discuss details at the moment as to make it viable at least
one portage developer should support this idea... But even without
portage developers this process at least could clear a bit the
situation. For example, currently, PMS team does not include anybody
from portage team - official PM team and thus this team can't represent
Gentoo interests. So until team which will represent Gentoo interests
arise, they'll work on PMS bugs and tell us that PMS is ready we should
not spend our time discussing PMS and trying to approve it.

--
Peter.

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

On Sun, 15 Jun 2008 18:42:28 +0400
Peter Volkov <pva@gentoo.org> wrote:
> By formalizing I mean the following: call for and form PMS team. Team
> must represent portage developers and could paludis and pkgcore. All
> suggestions for PMS draft must go into bugzilla and after patch for
> PMS is created PMS team members should vote on that patch. After
> voting patch is applied or discarded. Until there are open bugs in
> bugzilla council can not approve PMS.

How would a voting system be better than the current "if anyone doesn't
like it, don't commit it until whatever they don't like is fixed"
process?

Do you think that the current proportion of patches that are rejected
for PMS inclusion is too high or too low?

Do you think that the differences between the proportion of patches
from 'Paludis people' that are accepted or rejected and the proportion
of patches from 'Portage people' or 'Pkgcore people' indicates a
problem?

--
Ciaran McCreesh