Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

El mié, 20-06-2012 a las 23:43 +0200, Justin escribió:
 On 20.06.2012 22:35, Ciaran McCreesh wrote:
  On Wed, 20 Jun 2012 16:25:30 -0400
  Richard Yao r...@gentoo.org wrote:
  Multilib (and/or multiarch) support
 The current binaries cause a great deal of pain, particularly
  when a user does not want to upgrade something. I had this problem
  with WINE and glibc because I wanted to avoid the reverse memcpy()
  fiasco on my systems. This situation would have been avoided entirely
  if the package manager supported multilib.
  
  This one's unlikely to happen unless someone's prepared to put in the
  work.
 
 Tommy worked a lot on this and he asked for help to bring his
 proposal/spec/glep into shape.
 We are all aware what this is all about and know that anybody who is
 using multilib would benefit.
 Can't you simply work with him together to get it into what you expect
 it to be instead of pointing out that it isn't?
 

Also, if I remember correctly, Tommy asked for this some months ago, you
asked for what he sent some days ago and now you require more and more
work to delay things to be implemented. I also don't understand why
Gentoo is forced to stick with old ways of doing things until new EAPI
is approved while Exherbo is free to implement and use things like that
special way of handling DEPENDENCIES without waiting for any EAPI to be
accepted... or maybe I am wrong and people is able to use any PM manager
compliant with EAPI on exherbo without issues?


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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Wed, 20 Jun 2012 23:43:36 +0200
Justin j...@gentoo.org wrote:
 On 20.06.2012 22:35, Ciaran McCreesh wrote:
  On Wed, 20 Jun 2012 16:25:30 -0400
  Richard Yao r...@gentoo.org wrote:
  Multilib (and/or multiarch) support
 The current binaries cause a great deal of pain,
  particularly when a user does not want to upgrade something. I had
  this problem with WINE and glibc because I wanted to avoid the
  reverse memcpy() fiasco on my systems. This situation would have
  been avoided entirely if the package manager supported multilib.
  
  This one's unlikely to happen unless someone's prepared to put in
  the work.
 
 Tommy worked a lot on this and he asked for help to bring his
 proposal/spec/glep into shape.
 We are all aware what this is all about and know that anybody who is
 using multilib would benefit.
 Can't you simply work with him together to get it into what you expect
 it to be instead of pointing out that it isn't?

In order to do that, it would have to get to the stage where I
understood exactly what changes are needed and why. I'm not convinced
*anyone* understands that yet.

Writing PMS patches, at least to the level that we can review them, is
only difficult if you don't know what you want changed or why.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 08:08:55 +0200
Pacho Ramos pa...@gentoo.org wrote:
 Also, if I remember correctly, Tommy asked for this some months ago,
 you asked for what he sent some days ago and now you require more and
 more work to delay things to be implemented.

I still haven't seen a clear description of exactly what should be
changed and why. I've also not seen a description of exactly what
problem is being solved, nor a discussion of the relative merits of
implementing a solution to whatever that problem is. All I've seen is a
mess of code that gets it working in Portage (which isn't the same as
implements it for Portage) and a big wall of text that contains lots
that no-one needs to know and little of what's important. This needs to
go through the GLEP process, and it needs a PMS diff.

In case you're not aware, the first time Gentoo did multilib, it was
done as a series of random changes to Portage that no-one really
thought through or understood. As you can see, that didn't work...

 I also don't understand why Gentoo is forced to stick with old ways
 of doing things until new EAPI is approved

That's not what's going on here. The issue is that there might be one
person who understands what the new way of doing things, but he
hasn't told us what he thinks that is. Once we get a proper
explanation, getting an EAPI out doesn't take long.

The main problem here isn't even EAPI related. Ebuild developers don't
even know what they'll be expected, required or able to do for multilib.

 while Exherbo is free to implement and use things like that special
 way of handling DEPENDENCIES without waiting for any EAPI to be
 accepted...

The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
have it because Portage couldn't implement it. Now it doesn't have it
because it's too controversial to get it approved. Exherbo does have it
because it was carefully discussed, compared to alternatives, planned
out, tested, accepted by the expendable figurehead, and then rolled out.

 or maybe I am wrong and people is able to use any PM manager
 compliant with EAPI on exherbo without issues?

If anyone ever manages to come up with another package mangler that can
get close to implementing what Exherbo needs, then sure.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[justin]

On 21/06/12 08:41, Ciaran McCreesh wrote:
 On Wed, 20 Jun 2012 23:43:36 +0200
 Justin j...@gentoo.org wrote:
 On 20.06.2012 22:35, Ciaran McCreesh wrote:
 On Wed, 20 Jun 2012 16:25:30 -0400
 Richard Yao r...@gentoo.org wrote:
 Multilib (and/or multiarch) support
The current binaries cause a great deal of pain,
 particularly when a user does not want to upgrade something. I had
 this problem with WINE and glibc because I wanted to avoid the
 reverse memcpy() fiasco on my systems. This situation would have
 been avoided entirely if the package manager supported multilib.

 This one's unlikely to happen unless someone's prepared to put in
 the work.

 Tommy worked a lot on this and he asked for help to bring his
 proposal/spec/glep into shape.
 We are all aware what this is all about and know that anybody who is
 using multilib would benefit.
 Can't you simply work with him together to get it into what you expect
 it to be instead of pointing out that it isn't?
 
 In order to do that, it would have to get to the stage where I
 understood exactly what changes are needed and why. I'm not convinced
 *anyone* understands that yet.
 
 Writing PMS patches, at least to the level that we can review them, is
 only difficult if you don't know what you want changed or why.
 

He wants to deprecate the app-emulation/emul-linux-x86-* packages and
build it if needed directly from normal ebuilds through the package
manager. This was stated a couple of times and is not hard to
understand, even without PMS patches, GLEPS and so.

*anyone* understands that there are cases when the x86 libs are needed
and every gentoo package maintainer should understand, that letting the
user build their own x86 libs is what we want in ideal case.

There is a working implementation as a branch of portage for some time
now and people work on it.

So two basic things are there, the need and the idea of a working
solution. This also means, that people need to have an idea of what is
real problem. (And if not, it was asked a couple of times for discussion)

Won't it be a good thing, if you instead of showing all of us, that you
can tell where people fail to present something in the right way, help
and guide them to write the necessary things like PMS patches, GLEPs
etc., so that we can proceed in an efficient way?

justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
 On Thu, 21 Jun 2012 08:08:55 +0200
 Pacho Ramos pa...@gentoo.org wrote:
  Also, if I remember correctly, Tommy asked for this some months ago,
  you asked for what he sent some days ago and now you require more and
  more work to delay things to be implemented.
 
 I still haven't seen a clear description of exactly what should be
 changed and why. I've also not seen a description of exactly what
 problem is being solved, nor a discussion of the relative merits of
 implementing a solution to whatever that problem is. All I've seen is a
 mess of code that gets it working in Portage (which isn't the same as
 implements it for Portage) and a big wall of text that contains lots
 that no-one needs to know and little of what's important. This needs to
 go through the GLEP process, and it needs a PMS diff.
 
 In case you're not aware, the first time Gentoo did multilib, it was
 done as a series of random changes to Portage that no-one really
 thought through or understood. As you can see, that didn't work...
 

Then, looks clear to me that the way to get things approved in newer
EAPIs is not clear enough as looks like a lot of devs (like me) don't
know them (for example, when things to be added to EAPI need also a GLEP
and a PMS diff, also the needing to get an implementation for any
package manager). Is this documented in some place? If not, I think it
should be documented and, of course, it should be done by PMS team if
possible as they clearly know what they expect to get for approval if
needed since, I discussed some days ago, council will simply accept some
specific features to be included in next eapi once they are accepted by
PMS team. That way, we could save a lot of time, know what steps are
pending, try to ask for help for some specific steps and, finally, get
it discussed in PMS people providing all what is needed.


  I also don't understand why Gentoo is forced to stick with old ways
  of doing things until new EAPI is approved
 
 That's not what's going on here. The issue is that there might be one
 person who understands what the new way of doing things, but he
 hasn't told us what he thinks that is. Once we get a proper
 explanation, getting an EAPI out doesn't take long.
 

But you must confess that old problems like multilib support, force
package rebuilding or optional dep support are still pending while still
needing and, the problem with the way things are discussed now is that
some day anybody arises the problem again, other one demands more things
to be provided, a discussion starts, the problem gets stalled... one
year later the same problem arises again. There is clearly a lack of
information to the rest of developers about how to propose anything to
get accepted for next EAPI.

 The main problem here isn't even EAPI related. Ebuild developers don't
 even know what they'll be expected, required or able to do for multilib.
 
  while Exherbo is free to implement and use things like that special
  way of handling DEPENDENCIES without waiting for any EAPI to be
  accepted...
 
 The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
 have it because Portage couldn't implement it. Now it doesn't have it
 because it's too controversial to get it approved. 

It was only a example, but thanks for the info :)

 Exherbo does have it
 because it was carefully discussed, compared to alternatives, planned
 out, tested, accepted by the expendable figurehead, and then rolled out.
 
  or maybe I am wrong and people is able to use any PM manager
  compliant with EAPI on exherbo without issues?
 
 If anyone ever manages to come up with another package mangler that can
 get close to implementing what Exherbo needs, then sure.
 

Then, you accept exherbo is not forced to *only* follow EAPI while you
force Gentoo and portage to only support features approved in an EAPI?



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

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Michał Górny]

On Wed, 20 Jun 2012 18:24:33 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Wed, 20 Jun 2012 19:11:33 +0200
 hasufell hasuf...@gentoo.org wrote:
  On 06/20/2012 07:07 PM, Michał Górny wrote:
   Please read the rationale. Again. The whole thing. Three times.
  
  Please read my suggestions. Again. The whole thing. Three times.
 
 Can we all agree to just stop this and just restrict the arguing to
 being between SDEPEND and DEPENDENCIES? Cheers.

You just volunteered to write portage patches. Cheers.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ciaran McCreesh]

On Thu, 21 Jun 2012 09:29:49 +0200
Michał Górny mgo...@gentoo.org wrote:
 On Wed, 20 Jun 2012 18:24:33 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
  On Wed, 20 Jun 2012 19:11:33 +0200
  hasufell hasuf...@gentoo.org wrote:
   On 06/20/2012 07:07 PM, Michał Górny wrote:
Please read the rationale. Again. The whole thing. Three times.
   
   Please read my suggestions. Again. The whole thing. Three times.
  
  Can we all agree to just stop this and just restrict the arguing to
  being between SDEPEND and DEPENDENCIES? Cheers.
 
 You just volunteered to write portage patches. Cheers.

Both were already implemented in Paludis, if you're looking for a
reference implementation to try it out. There are also examples of
use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
can give you a small patch to turn SDEPEND on for an EAPI if you like
(it's just a one line addition to the EAPI definition file).

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Michał Górny]

On Thu, 21 Jun 2012 08:30:24 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Thu, 21 Jun 2012 09:29:49 +0200
 Michał Górny mgo...@gentoo.org wrote:
  On Wed, 20 Jun 2012 18:24:33 +0100
  Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
   On Wed, 20 Jun 2012 19:11:33 +0200
   hasufell hasuf...@gentoo.org wrote:
On 06/20/2012 07:07 PM, Michał Górny wrote:
 Please read the rationale. Again. The whole thing. Three
 times.

Please read my suggestions. Again. The whole thing. Three times.
   
   Can we all agree to just stop this and just restrict the arguing
   to being between SDEPEND and DEPENDENCIES? Cheers.
  
  You just volunteered to write portage patches. Cheers.
 
 Both were already implemented in Paludis, if you're looking for a
 reference implementation to try it out. There are also examples of
 use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
 can give you a small patch to turn SDEPEND on for an EAPI if you like
 (it's just a one line addition to the EAPI definition file).

Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
in Paludis' doesn't work here. We're discussing Gentoo features,
and official package manager in Gentoo is portage. If you don't believe
me, check out the docs.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 09:25:10 +0200
Pacho Ramos pa...@gentoo.org wrote:
 Then, looks clear to me that the way to get things approved in newer
 EAPIs is not clear enough as looks like a lot of devs (like me) don't
 know them (for example, when things to be added to EAPI need also a
 GLEP and a PMS diff, also the needing to get an implementation for any
 package manager).

That's very much a judgement call. If a feature is easy, low impact
and uncontroversial, you can ask for it on IRC, the mailing lists or
bugzilla, and chances are someone will do all the work for you. If it's
a big feature with broad impact requiring lots of changes, you need to
do however much work is necessary such that a) the people working on
PMS understand it well enough to document it, b) developers understand
it well enough to know what it involves for them, c) the Council can
compare and contrast it with other proposals, and d) it can be
implemented.

The implement it in a package manager thing is because of what
happened with REQUIRED_USE. It hadn't been implemented previously, and
as it turns out it has some fairly hefty usability issues.

   I also don't understand why Gentoo is forced to stick with old
   ways of doing things until new EAPI is approved
  
  That's not what's going on here. The issue is that there might be
  one person who understands what the new way of doing things, but
  he hasn't told us what he thinks that is. Once we get a proper
  explanation, getting an EAPI out doesn't take long.
  
 
 But you must confess that old problems like multilib support, force
 package rebuilding or optional dep support are still pending while
 still needing and, the problem with the way things are discussed now
 is that some day anybody arises the problem again, other one demands
 more things to be provided, a discussion starts, the problem gets
 stalled... one year later the same problem arises again. There is
 clearly a lack of information to the rest of developers about how to
 propose anything to get accepted for next EAPI.

The reason those are still pending is because no-one knows what the
*problem* is, let alone the solution. That's not an EAPI issue, it's a
developers saying I want a flying unicorn! issue.

 Then, you accept exherbo is not forced to *only* follow EAPI while you
 force Gentoo and portage to only support features approved in an EAPI?

I think you have a severe misunderstanding of what the EAPI process is
about here... It's not about forcing anything. The point of the EAPI
process is to allow Gentoo to roll things out without requiring
developers to rewrite all their ebuilds every few months (which
happens on Exherbo, incidentally), and without breaking user systems.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog

[Samuli Suominen]

On 06/21/2012 10:37 AM, Ben de Groot (yngwin) wrote:

yngwin  12/06/21 07:37:15

   Modified: lightdm-1.2.2-r2.ebuild ChangeLog
   Log:
   Re-tidy. Restore glib slot. Drop unnecessary gobject-introspection minimal 
version (there is nothing lower in tree). Restore useful comments.


There is no glib3 and all the commands are self-explanatory. And users 
might still have older gobject-introspection installed, with nothing 
forcing the upgrade now.
I consider this a regression (in every regard) and will just do the same 
changes again with the next fixes




   (Portage version: 2.2.0_alpha110/cvs/Linux x86_64)

Revision  ChangesPath
1.2  x11-misc/lightdm/lightdm-1.2.2-r2.ebuild

file : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2view=markup
plain: 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2content-type=text/plain
diff : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?r1=1.1r2=1.2

Index: lightdm-1.2.2-r2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- lightdm-1.2.2-r2.ebuild 20 Jun 2012 04:58:41 -  1.1
+++ lightdm-1.2.2-r2.ebuild 21 Jun 2012 07:37:15 -  1.2
@@ -1,6 +1,6 @@
  # Copyright 1999-2012 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 
1.1 2012/06/20 04:58:41 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 
1.2 2012/06/21 07:37:15 yngwin Exp $

  EAPI=4
  inherit autotools eutils pam
@@ -15,18 +15,16 @@
  KEYWORDS=~amd64 ~x86
  IUSE=+introspection qt4

-COMMON_DEPEND==dev-libs/glib-2
+COMMON_DEPEND=dev-libs/glib:2
dev-libs/libxml2
sys-apps/accountsservice
virtual/pam
x11-libs/libX11
=x11-libs/libxklavier-5
-   introspection? ( =dev-libs/gobject-introspection-1 )
-   qt4? (
-   x11-libs/qt-core:4
+   introspection? ( dev-libs/gobject-introspection )
+   qt4? ( x11-libs/qt-core:4
x11-libs/qt-dbus:4
-   x11-libs/qt-gui:4
-   )
+   x11-libs/qt-gui:4 )
  RDEPEND=${COMMON_DEPEND}
=sys-auth/pambase-20101024-r2
  DEPEND=${COMMON_DEPEND}
@@ -36,7 +34,7 @@
sys-devel/gettext
virtual/pkgconfig

-DOCS=NEWS
+DOCS=( NEWS )

  src_prepare() {
sed -i -e 's:getgroups:lightdm_:' tests/src/libsystem.c || die #412369
@@ -54,18 +52,18 @@
  }

  src_configure() {
+   # Set default values if global vars unset
local _greeter _session _user
_greeter=${LIGHTDM_GREETER:=lightdm-gtk-greeter}
_session=${LIGHTDM_SESSION:=gnome}
_user=${LIGHTDM_USER:=root}
-
+   # Let user know how lightdm is configured
einfo Gentoo configuration
einfo Default greeter: ${_greeter}
einfo Default session: ${_session}
einfo Greeter user: ${_user}

-   econf \
-   --localstatedir=/var \
+   econf --localstatedir=/var \
--disable-static \
$(use_enable introspection) \
$(use_enable qt4 liblightdm-qt) \
@@ -78,15 +76,17 @@
  src_install() {
default

+   # Install missing files
insinto /etc/${PN}
doins data/{${PN},users,keys}.conf
-
doins ${FILESDIR}/Xsession
fperms +x /etc/${PN}/Xsession

+   # Remove unnecessary files
prune_libtool_files --all
rm -rf ${ED}/etc/init

+   # Install proper pam files
pamd_mimic system-local-login ${PN} auth account session
pamd_mimic system-local-login ${PN}-autologin auth account session
  }



1.43 x11-misc/lightdm/ChangeLog

file : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/ChangeLog?rev=1.43view=markup
plain: 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/ChangeLog?rev=1.43content-type=text/plain
diff : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/ChangeLog?r1=1.42r2=1.43

Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/x11-misc/lightdm/ChangeLog,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- ChangeLog   20 Jun 2012 04:58:41 -  1.42
+++ ChangeLog   21 Jun 2012 07:37:15 -  1.43
@@ -1,6 +1,10 @@
  # ChangeLog for x11-misc/lightdm
  # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/ChangeLog,v 1.42 
2012/06/20 04:58:41 ssuominen Exp $
+# $Header: /var/cvsroot/gentoo-x86/x11-misc/lightdm/ChangeLog,v 1.43 
2012/06/21 07:37:15 yngwin Exp $
+
+  21 

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ciaran McCreesh]

On Thu, 21 Jun 2012 09:42:36 +0200
Michał Górny mgo...@gentoo.org wrote:
   You just volunteered to write portage patches. Cheers.
  
  Both were already implemented in Paludis, if you're looking for a
  reference implementation to try it out. There are also examples of
  use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in
  Exherbo. I can give you a small patch to turn SDEPEND on for an
  EAPI if you like (it's just a one line addition to the EAPI
  definition file).
 
 Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
 in Paludis' doesn't work here. We're discussing Gentoo features,
 and official package manager in Gentoo is portage. If you don't
 believe me, check out the docs.

And since when was Implemented in Portage a requirement for an EAPI
feature?

The implementation requirement is to avoid REQUIRED_USE-like screwups.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: Killing UEFI Secure Boot

[Duncan]

Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted:

 3. How does getting a x86 system to boot differ from getting a MIPS
 system or ARM system to boot? Does it only work because the vendors made
 it work or is x86 fundamentally harder?

I can answer this one.  x86 is harder at the bootloader stage, but in 
turn easier, or perhaps simply different, at the kernel and kernel device 
interface level.

Consider, most MIPS and ARM systems ship with a specific set of basic 
devices, configured to use specific IO addresses, IRQs, etc, and that's 
it, at least to get up and running (USB devices, etc, may be able to be 
plugged in, but they're not normally needed for boot).  If you've been 
keeping up with the kernel (say via LWN, etc), this has been one of the 
big deals with the ARM tree recently, as until now each board had its 
own hard-coded kernel config directly in the tree, and it was getting 
unmanageable.  They're switching to device tree, etc, allowing the boot 
loader to feed the kernel a file with this information at boot time, thus 
allowing a whole bunch of different boards to boot off the same shipped 
kernel, while at the same time getting the explosion of individual board 
files out of the kernel tree.  This is a BIG deal on ARM and similar 
embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all.

Meanwhile, on x86, the system must be prepared for end-user switch-out of 
pretty much everything. memory, storage (consider floppy, hard drive, 
optical disk either direct or el-torito, USB stick, etc, all bootable and 
all end-user changable!), even quantity and speed of CPUs, and the 
firmware BIOS (or replacement) must cope with that and be able to boot 
off it.  Even back in the 386 era when everything was jumper-configured, 
users could still change pretty much everything out, other than the mobo 
itself.   Now days, it's even MORE complex, as most of these devices can 
be configured in dozens or hundreds of mode combinations via plug-n-
pray, and they often don't /have/ a default -- they **MUST** be so 
configured in ordered to be operable for the intended use.  Sure, the 
BIOS CAN leave some of it for the kernel to do, but other bits, not so 
much, as otherwise, how does the kernel even get loaded -- the BIOS must 
pick one of the many boot options, configure it (as well as the CPU and 
the system between storage and the CPU, storage chipset, memory, etc) at 
least well enough to read in the boot loader and/or kernel.  None of 
that's necessary on ARM, etc, because (pretty much) everything there's a 
totally arbitrary-as-shipped config, nothing to dynamically negotiate and 
get working before the kernel or secondary bootloader (after the BIOS) 
can even work!

-- 
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] Re: My wishlist for EAPI 5

[Duncan]

Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:

 On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
 On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote:

 POSIX Shell compliance
 
 So far as I know, every PM relies heavily upon bash anyway (and can't
 easily be made not to), so even if developers would accept having to
 rewrite all their eclasses, it still wouldn't remove the dep.
 
 Lets address POSIX compliance in the ebuilds first. Then we can deal
 with the package managers.

Additionally, this is extremely unlikely because a number of developers 
insist on bash, to the extent that it would likely split gentoo in half 
if this were to be forced.  It wouldn't pass council.  It's unlikely to 
even /get/ to council.

Openrc could move to POSIX shell because its primary dev at the time 
wanted it that way and it's only a single package.  However, even then, 
doing it was controversial enough that said developer ended up leaving 
gentoo in-part over that, tho he did continue to develop openrc as a 
gentoo hosted project for quite some years.  Now you're talking trying to 
do it for /every/ (well, almost every) package, thus touching every 
single gentoo dev.  It's just not going to happen in even the medium term 
(say for argument APIs 5-7ish), let alone be something practical enough 
to implement, soon enough (even if everyone agreed on the general idea, 
they don't), to be anything like conceivable for EAPI5.

So just let that one be.  It's simply not worth tilting at that windmill.

(Arguably, multi-arch, while practical and actually working at least with 
portage in an overlay, fails that last bit as well.  If it was pushed, 
perhaps for EAPI6 or 7, but it's just not practical to consider it for 
EAPI5... unless you want to wait 3-5 years for EAPI5!)

-- 
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] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog

[Ben de Groot]

On 21 June 2012 15:39, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 06/21/2012 10:37 AM, Ben de Groot (yngwin) wrote:

 yngwin      12/06/21 07:37:15

   Modified:             lightdm-1.2.2-r2.ebuild ChangeLog
   Log:
   Re-tidy. Restore glib slot. Drop unnecessary gobject-introspection
 minimal version (there is nothing lower in tree). Restore useful comments.


 There is no glib3

Since glib is slotted, we specified the slot. There was no good reason
for you to change that. Besides, it is conceivable there will be a glib-3
in the future. Using the slot is more precise and more likely to be
future-proof.

 and all the commands are self-explanatory.

And what's wrong with leaving the comments in place, which the
maintainers put there for a reason? In my opinion it is good practice
to document why you are doing things, to make sure maintainers
after us will understand -- they might not be as experienced.

 And users might
 still have older gobject-introspection installed, with nothing forcing the
 upgrade now.

Regular maintenance should take care of that. We are not in the
habit of specifying minimal versions for all dependencies.

 I consider this a regression (in every regard) and will just do the same
 changes again with the next fixes

Please don't fix things that aren't broken.

If you think they are broken, then make sure it is documented
in the proper places (such as devmanual) before barging in
and changing the way the maintainers chose to do things.




   (Portage version: 2.2.0_alpha110/cvs/Linux x86_64)

 Revision  Changes    Path
 1.2                  x11-misc/lightdm/lightdm-1.2.2-r2.ebuild

 file :
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2view=markup
 plain:
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?rev=1.2content-type=text/plain
 diff :
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild?r1=1.1r2=1.2

 Index: lightdm-1.2.2-r2.ebuild
 ===
 RCS file:
 /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -u -r1.1 -r1.2
 --- lightdm-1.2.2-r2.ebuild     20 Jun 2012 04:58:41 -      1.1
 +++ lightdm-1.2.2-r2.ebuild     21 Jun 2012 07:37:15 -      1.2
 @@ -1,6 +1,6 @@
  # Copyright 1999-2012 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
 -# $Header:
 /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 1.1
 2012/06/20 04:58:41 ssuominen Exp $
 +# $Header:
 /var/cvsroot/gentoo-x86/x11-misc/lightdm/lightdm-1.2.2-r2.ebuild,v 1.2
 2012/06/21 07:37:15 yngwin Exp $

  EAPI=4
  inherit autotools eutils pam
 @@ -15,18 +15,16 @@
  KEYWORDS=~amd64 ~x86
  IUSE=+introspection qt4

 -COMMON_DEPEND==dev-libs/glib-2
 +COMMON_DEPEND=dev-libs/glib:2
        dev-libs/libxml2
        sys-apps/accountsservice
        virtual/pam
        x11-libs/libX11
        =x11-libs/libxklavier-5
 -       introspection? ( =dev-libs/gobject-introspection-1 )
 -       qt4? (
 -               x11-libs/qt-core:4
 +       introspection? ( dev-libs/gobject-introspection )
 +       qt4? ( x11-libs/qt-core:4
                x11-libs/qt-dbus:4
 -               x11-libs/qt-gui:4
 -               )
 +               x11-libs/qt-gui:4 )
  RDEPEND=${COMMON_DEPEND}
        =sys-auth/pambase-20101024-r2
  DEPEND=${COMMON_DEPEND}
 @@ -36,7 +34,7 @@
        sys-devel/gettext
        virtual/pkgconfig

 -DOCS=NEWS
 +DOCS=( NEWS )

  src_prepare() {
        sed -i -e 's:getgroups:lightdm_:' tests/src/libsystem.c || die
 #412369
 @@ -54,18 +52,18 @@
  }

  src_configure() {
 +       # Set default values if global vars unset
        local _greeter _session _user
        _greeter=${LIGHTDM_GREETER:=lightdm-gtk-greeter}
        _session=${LIGHTDM_SESSION:=gnome}
        _user=${LIGHTDM_USER:=root}
 -
 +       # Let user know how lightdm is configured
        einfo Gentoo configuration
        einfo Default greeter: ${_greeter}
        einfo Default session: ${_session}
        einfo Greeter user: ${_user}

 -       econf \
 -               --localstatedir=/var \
 +       econf --localstatedir=/var \
                --disable-static \
                $(use_enable introspection) \
                $(use_enable qt4 liblightdm-qt) \
 @@ -78,15 +76,17 @@
  src_install() {
        default

 +       # Install missing files
        insinto /etc/${PN}
        doins data/{${PN},users,keys}.conf
 -
        doins ${FILESDIR}/Xsession
        fperms +x /etc/${PN}/Xsession

 +       # Remove unnecessary files
        prune_libtool_files --all
        rm -rf ${ED}/etc/init

 +       # Install proper pam files
        pamd_mimic system-local-login ${PN} auth account session
        pamd_mimic system-local-login ${PN}-autologin auth account session
  }



 1.43                 x11-misc/lightdm/ChangeLog

 file :
 

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Michał Górny]

On Thu, 21 Jun 2012 08:41:23 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Thu, 21 Jun 2012 09:42:36 +0200
 Michał Górny mgo...@gentoo.org wrote:
You just volunteered to write portage patches. Cheers.
   
   Both were already implemented in Paludis, if you're looking for a
   reference implementation to try it out. There are also examples of
   use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in
   Exherbo. I can give you a small patch to turn SDEPEND on for an
   EAPI if you like (it's just a one line addition to the EAPI
   definition file).
  
  Wait, did I just write to exherbo ml? No, don't think so.
  'Implemented in Paludis' doesn't work here. We're discussing Gentoo
  features, and official package manager in Gentoo is portage. If you
  don't believe me, check out the docs.
 
 And since when was Implemented in Portage a requirement for an EAPI
 feature?

Remember EAPI4 and features which had reference implementation not
in portage?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ciaran McCreesh]

On Thu, 21 Jun 2012 10:54:19 +0200
Michał Górny mgo...@gentoo.org wrote:
  And since when was Implemented in Portage a requirement for an
  EAPI feature?
 
 Remember EAPI4 and features which had reference implementation not
 in portage?

Actually, yes, since that was most of them. Nearly all of them got
implemented quickly. Our policy on this has always been ask Zac
whether he thinks they're reasonably quick to implement.

But you know this, so kindly keep your disruption to places where
you're right.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog

[Samuli Suominen]

On 06/21/2012 11:42 AM, Ben de Groot wrote:

Please don't fix things that aren't broken.


ditto :)

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Richard Yao]

On 06/21/2012 04:29 AM, Duncan wrote:
 Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:

 On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
 On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote:
 POSIX Shell compliance
 So far as I know, every PM relies heavily upon bash anyway (and can't
 easily be made not to), so even if developers would accept having to
 rewrite all their eclasses, it still wouldn't remove the dep.

 Lets address POSIX compliance in the ebuilds first. Then we can deal
 with the package managers.
 Additionally, this is extremely unlikely because a number of developers 
 insist on bash, to the extent that it would likely split gentoo in half 
 if this were to be forced.  It wouldn't pass council.  It's unlikely to 
 even /get/ to council.

 Openrc could move to POSIX shell because its primary dev at the time 
 wanted it that way and it's only a single package.  However, even then, 
 doing it was controversial enough that said developer ended up leaving 
 gentoo in-part over that, tho he did continue to develop openrc as a 
 gentoo hosted project for quite some years.  Now you're talking trying to 
 do it for /every/ (well, almost every) package, thus touching every 
 single gentoo dev.  It's just not going to happen in even the medium term 
 (say for argument APIs 5-7ish), let alone be something practical enough 
 to implement, soon enough (even if everyone agreed on the general idea, 
 they don't), to be anything like conceivable for EAPI5.

 So just let that one be.  It's simply not worth tilting at that windmill.

 (Arguably, multi-arch, while practical and actually working at least with 
 portage in an overlay, fails that last bit as well.  If it was pushed, 
 perhaps for EAPI6 or 7, but it's just not practical to consider it for 
 EAPI5... unless you want to wait 3-5 years for EAPI5!)

It is just a wish list.

Anyway, people need to decide on what they want from a new EAPI before
one is made. Once they decide, it should be possible to work out the
details.

Re: [gentoo-dev] My wishlist for EAPI 5

[Alec Warner]

On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos pa...@gentoo.org wrote:
 El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
 On Thu, 21 Jun 2012 08:08:55 +0200
 Pacho Ramos pa...@gentoo.org wrote:
  Also, if I remember correctly, Tommy asked for this some months ago,
  you asked for what he sent some days ago and now you require more and
  more work to delay things to be implemented.

 I still haven't seen a clear description of exactly what should be
 changed and why. I've also not seen a description of exactly what
 problem is being solved, nor a discussion of the relative merits of
 implementing a solution to whatever that problem is. All I've seen is a
 mess of code that gets it working in Portage (which isn't the same as
 implements it for Portage) and a big wall of text that contains lots
 that no-one needs to know and little of what's important. This needs to
 go through the GLEP process, and it needs a PMS diff.

 In case you're not aware, the first time Gentoo did multilib, it was
 done as a series of random changes to Portage that no-one really
 thought through or understood. As you can see, that didn't work...


 Then, looks clear to me that the way to get things approved in newer
 EAPIs is not clear enough as looks like a lot of devs (like me) don't
 know them (for example, when things to be added to EAPI need also a GLEP
 and a PMS diff, also the needing to get an implementation for any
 package manager). Is this documented in some place? If not, I think it
 should be documented and, of course, it should be done by PMS team if
 possible as they clearly know what they expect to get for approval if
 needed since, I discussed some days ago, council will simply accept some
 specific features to be included in next eapi once they are accepted by
 PMS team. That way, we could save a lot of time, know what steps are
 pending, try to ask for help for some specific steps and, finally, get
 it discussed in PMS people providing all what is needed.


  I also don't understand why Gentoo is forced to stick with old ways
  of doing things until new EAPI is approved

 That's not what's going on here. The issue is that there might be one
 person who understands what the new way of doing things, but he
 hasn't told us what he thinks that is. Once we get a proper
 explanation, getting an EAPI out doesn't take long.


 But you must confess that old problems like multilib support, force
 package rebuilding or optional dep support are still pending while still
 needing and, the problem with the way things are discussed now is that
 some day anybody arises the problem again, other one demands more things
 to be provided, a discussion starts, the problem gets stalled... one
 year later the same problem arises again. There is clearly a lack of
 information to the rest of developers about how to propose anything to
 get accepted for next EAPI.

I'm not following you here.

1) Usually features need a reference implementation.
2) For portage, there are like 3-5 people who know portage well enough
to write that for you.
3) You generally have to convince them to do it before you can move forward.
4) Most features never even get a reference implementation.

There is this vague idea that you can just propose something; get
consensus on the ML, everyone goes to implement it, and then it works
just as designed. That is usually called the 'waterfall' model and its
really hard to do correctly.

What I imagine the process is:

1) Submit an idea to the ML; you just need feedback (not consensus,
which is likely impossible for non-trivial ideas.)
  1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required.
2) Take feedback from step one and make an initial implementation. You
will likely find some assumptions in your 'design' from step one were
wrong, as well as other implementation issues (UI, performance, etc.)
3) Modify your idea to address the problems in 2.
4) Modify your implementation to address the problems in 2.
5) Repeat steps 2-4 a few times until you have solved all the 'big' problems.
6) Submit a diff to PMS outlining how the package manager behavior is
changed by your feature. This generally needs to be specific enough so
that other package manager authors can implement the feature.
7) Submit a devmanual patch telling users how to use the feature.

Most people fail at step two; usually because they try to get
'consensus' at step one, which is stupid and a waste of time. There
are a few hundred people on this list; we will never all agree, on
basically anything. So take the feedback people give you and do
something with it.


 The main problem here isn't even EAPI related. Ebuild developers don't
 even know what they'll be expected, required or able to do for multilib.

  while Exherbo is free to implement and use things like that special
  way of handling DEPENDENCIES without waiting for any EAPI to be
  accepted...

 The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
 

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

[Richard Yao]

On 06/21/2012 04:08 AM, Duncan wrote:
 Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted:
 
 3. How does getting a x86 system to boot differ from getting a MIPS
 system or ARM system to boot? Does it only work because the vendors made
 it work or is x86 fundamentally harder?
 
 I can answer this one.  x86 is harder at the bootloader stage, but in 
 turn easier, or perhaps simply different, at the kernel and kernel device 
 interface level.
 
 Consider, most MIPS and ARM systems ship with a specific set of basic 
 devices, configured to use specific IO addresses, IRQs, etc, and that's 
 it, at least to get up and running (USB devices, etc, may be able to be 
 plugged in, but they're not normally needed for boot).  If you've been 
 keeping up with the kernel (say via LWN, etc), this has been one of the 
 big deals with the ARM tree recently, as until now each board had its 
 own hard-coded kernel config directly in the tree, and it was getting 
 unmanageable.  They're switching to device tree, etc, allowing the boot 
 loader to feed the kernel a file with this information at boot time, thus 
 allowing a whole bunch of different boards to boot off the same shipped 
 kernel, while at the same time getting the explosion of individual board 
 files out of the kernel tree.  This is a BIG deal on ARM and similar 
 embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all.
 
 Meanwhile, on x86, the system must be prepared for end-user switch-out of 
 pretty much everything. memory, storage (consider floppy, hard drive, 
 optical disk either direct or el-torito, USB stick, etc, all bootable and 
 all end-user changable!), even quantity and speed of CPUs, and the 
 firmware BIOS (or replacement) must cope with that and be able to boot 
 off it.  Even back in the 386 era when everything was jumper-configured, 
 users could still change pretty much everything out, other than the mobo 
 itself.   Now days, it's even MORE complex, as most of these devices can 
 be configured in dozens or hundreds of mode combinations via plug-n-
 pray, and they often don't /have/ a default -- they **MUST** be so 
 configured in ordered to be operable for the intended use.  Sure, the 
 BIOS CAN leave some of it for the kernel to do, but other bits, not so 
 much, as otherwise, how does the kernel even get loaded -- the BIOS must 
 pick one of the many boot options, configure it (as well as the CPU and 
 the system between storage and the CPU, storage chipset, memory, etc) at 
 least well enough to read in the boot loader and/or kernel.  None of 
 that's necessary on ARM, etc, because (pretty much) everything there's a 
 totally arbitrary-as-shipped config, nothing to dynamically negotiate and 
 get working before the kernel or secondary bootloader (after the BIOS) 
 can even work!
 

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.

With that said, I am not convinced by your argument that x86 is
fundamentally more complex. Many of the things you attributed to the
BIOS are in fact handled by the kernel. There is plenty of duplication
between the two, where the BIOS will configure things and then the
kernel will configure them again. However, the BIOS does not accomplish
anything useful in those cases.

Re: [gentoo-dev] My wishlist for EAPI 5

[Ben de Groot]

On 21 June 2012 05:33, Alec Warner anta...@gentoo.org wrote:
 On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao r...@gentoo.org wrote:
 Here is my wishlist for EAPI 5:
[...]
 POSIX Shell compliance
        There has been a great deal of work done to give the user full control
 of what is on his system and there is more that we can do there. In
 particular, I think a lean Gentoo Linux system should be able to use
 busybox sh and nothing else. That requires POSIX shell compliance.
 OpenRC init scripts support this and the configure scripts support this.
 The few exceptions are bugs that are addressed by the Gentoo BSD developers.
        As such, I think we should make EAPI=5 use POSIX shell by default. If
 an ebuild requires bash, we can allow the ebuild to declare that (e.g.
 WANT_SH=bash), but that should be the exception and not the rule.


 Our ebuilds are written in bash. [...] Screw
 trying to get the PM to stop using bash; developers are not interested
 in writing ebuilds in posix shell; bar none.

 Why would I as an ebuild author waste a bunch of time writing my
 ebuild in posix compatible sh when I can use bash (and if I had a
 better language than bash to write ebuilds in; I'd use that too.) You
 are free to write your ebuilds in posix sh; good luck to you.

Ebuilds are written in bash. And the convenience of using bash
far outweighs any benefits of using posix sh instead. One needs
to make a very strong case to convince enough developers to
change this...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

Re: [gentoo-dev] My wishlist for EAPI 5

[Patrick Lauer]

On 06/21/12 15:25, Pacho Ramos wrote:
 El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
 On Thu, 21 Jun 2012 08:08:55 +0200
 Pacho Ramos pa...@gentoo.org wrote:
 Also, if I remember correctly, Tommy asked for this some months ago,
 you asked for what he sent some days ago and now you require more and
 more work to delay things to be implemented.
 I still haven't seen a clear description of exactly what should be
 changed and why. I've also not seen a description of exactly what
 problem is being solved, nor a discussion of the relative merits of
 implementing a solution to whatever that problem is. All I've seen is a
 mess of code that gets it working in Portage (which isn't the same as
 implements it for Portage) and a big wall of text that contains lots
 that no-one needs to know and little of what's important. This needs to
 go through the GLEP process, and it needs a PMS diff.

 In case you're not aware, the first time Gentoo did multilib, it was
 done as a series of random changes to Portage that no-one really
 thought through or understood. As you can see, that didn't work...

 Then, looks clear to me that the way to get things approved in newer
 EAPIs is not clear enough as looks like a lot of devs (like me) don't
 know them (for example, when things to be added to EAPI need also a GLEP
 and a PMS diff, also the needing to get an implementation for any
 package manager). Is this documented in some place?
No, and this is a rather random ad-hoc requirement that hasn't been
specified before.

All previous EAPI processes went through some debate with dev-portage@
and the other involved people (mostly pkgcore/ferringb and
paludis/ciaranm), then the proposal got handed to council to vote on,
and if council was happy that proposal was hammered into PMS and the new
EAPI published. Most of the time new features had a crude approximation
of a patch for PMS available so that the documentation updates were done
in a timely manner.

I have no idea why Ciaran is trying to redefine the process now suddenly
and why people are taking this nonsense seriously.

  If not, I think it
 should be documented and, of course, it should be done by PMS team if
 possible as they clearly know what they expect to get for approval if
 needed since, I discussed some days ago, council will simply accept some
 specific features to be included in next eapi once they are accepted by
 PMS team. That way, we could save a lot of time, know what steps are
 pending, try to ask for help for some specific steps and, finally, get
 it discussed in PMS people providing all what is needed.
I would say PMS team accepts what council signs off ... or am I seeing
the order wrong here?


So, the normal way to get a feature into the next EAPI is ... write a
specification to the best of your capabilities, present it here, when
people are done bashing it ask PMS people to help you prepare a PMS
patch so that you can suggest it to Council, and then it's mostly a
matter of waiting until the next EAPI is finalized (which currently runs
at a glacial pace of about one EAPI a year as far as I remember)


Take care,

Patrick

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 19:15:02 +0800
Patrick Lauer patr...@gentoo.org wrote:
  Then, looks clear to me that the way to get things approved in newer
  EAPIs is not clear enough as looks like a lot of devs (like me)
  don't know them (for example, when things to be added to EAPI need
  also a GLEP and a PMS diff, also the needing to get an
  implementation for any package manager). Is this documented in some
  place?
 No, and this is a rather random ad-hoc requirement that hasn't been
 specified before.

It's dependent upon the level of complexity of the work, and whether or
not anyone on the PMS team understands it enough to be able to do the
work themselves. As far as I know, none of us do on this one, so it's
down to whoever wants it to educate us enough that we can get it done...

 All previous EAPI processes went through some debate with dev-portage@
 and the other involved people (mostly pkgcore/ferringb and
 paludis/ciaranm), then the proposal got handed to council to vote on,
 and if council was happy that proposal was hammered into PMS and the
 new EAPI published. Most of the time new features had a crude
 approximation of a patch for PMS available so that the documentation
 updates were done in a timely manner.

Actually, we've been passing pretty much final PMS patches to the
Council to vote on. 

 I have no idea why Ciaran is trying to redefine the process now
 suddenly and why people are taking this nonsense seriously.

I'm not.

 I would say PMS team accepts what council signs off ... or am I seeing
 the order wrong here?

The PMS team makes suggestions to the Council, and the Council accepts
a subset of those. The Council can also suggest that the PMS team looks
at a particular feature, but as Gentoo has no mechanism in place for
forcing work to get done, that only works if there's someone with both
the time and the knowledge to figure it out.

 So, the normal way to get a feature into the next EAPI is ... write a
 specification to the best of your capabilities, present it here, when
 people are done bashing it ask PMS people to help you prepare a PMS
 patch so that you can suggest it to Council

Yup, and for difficult cases like the ones under discussion, a part of
presenting it is to demo a working implementation on real packages so
that we gain real world experience of the feature.

It's also important to note that the best of your capabilities may
not be anywhere near enough for the PMS people or the package mangler
people to do the remainder of the work.

 and then it's mostly a
 matter of waiting until the next EAPI is finalized (which currently
 runs at a glacial pace of about one EAPI a year as far as I remember)

I like how you simultaneously troll both sides of that issue. Weren't
you previously claiming there were too many EAPIs and that we shouldn't
have lots of new ones?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Rich Freeman]

On Thu, Jun 21, 2012 at 5:27 AM, Alec Warner anta...@gentoo.org wrote:
 There is this vague idea that you can just propose something; get
 consensus on the ML, everyone goes to implement it, and then it works
 just as designed. That is usually called the 'waterfall' model and its
 really hard to do correctly.


++

Waterfall has problems even in places where people are paid to do
work.  It has little chance of working here.

Devs aren't paid to do work.  They do what interests them.  So, the
most effective way to make something happen is to do it yourself, or
better still make it something interesting, do it yourself, and
inspire others to help you out.  A working program will always gather
more interest than a discussion on a list.

Plus Gentoo is all about choice - even if it never becomes the
standard lots of people will do it anyway.  Look at paludis, systemd,
and so on.  The autobuilt releases started out as drobbins side
project on funtoo before they became the mainstream Gentoo way.
Showing people that something works is always better than telling
them.

Rich

Re: [gentoo-dev] About what would be included in EAPI5

[Homer Parker]

On Wed, 2012-06-20 at 17:50 +0100, Ciaran McCreesh wrote:
 
  Then there are ebuilds that don't call eautoreconf, in the first
  place. Should we require that all of them inherit autotools now,
 just
  for the unlikely case that user patches could be applied?
 
 If the aim is to provide a working feature to users, yes. The
 alternative is to not provide user patches support. 

Damnit, let the user shoot themself in the foot but let them learn from
it. Remember back in the day when you had no clue? You learned from it.
You can only protect them so much. If they want to use custom patches
then they need to learn how.

-- 
Homer Parker hpar...@gentoo.org


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

[gentoo-dev] Authorship of app-doc/pms

[Andreas K. Huettel]

Dear all,
according to git blame, this is the distribution of authorship across the
current git master of the pms tex source.

2   Pierre-Yves Aillet
5   Fernando J. Pereda
6   Mark Loeser
7   Richard Brown
8   Thomas Anderson
25  NotCommittedYet (???)
27  Bo Ørsted Andresen
28  Brian Harring
37  Michał Górny
197 David Leverton
557 Ulrich Müller
678 Stephen Bennett
694 Christian Faulhammer
1903Ciaran McCreesh

Given that and my usual subtlety, I think the current title page misrepresents
contributorship, and would like to request that the following patch is applied
to branches master and eapi-5.

Best, Andreas


From 3572b4cb400b2ff156e4f28d3dffe82c687a1dc9 Mon Sep 17 00:00:00 2001
From: Andreas K. Huettel andreas.huet...@physik.uni-r.de
Date: Thu, 21 Jun 2012 14:03:24 +0200
Subject: [PATCH] Update author information

---
 pms.cls |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/pms.cls b/pms.cls
index db2fd48..b2faef1 100644
--- a/pms.cls
+++ b/pms.cls
@@ -114,7 +114,7 @@
 citecolor=black,
 linkcolor=black,
 pdftitle={Package Manager Specification},
-pdfauthor={Stephen P. Bennett, Ciaran McCreesh},
+pdfauthor={Ulrich Mueller, Stephen P. Bennett, Christian Faulhammer,
Ciaran McCreesh},
 pdfcreator={pdfLaTeX and hyperref},
 pdfsubject={Defining a feature set for package managers in the
 Gentoo world},
@@ -125,10 +125,19 @@
 }
 % Some metadata needed for the title page generation
 \title{Package Manager Specification}
-\author{Stephen P. Bennett \\
-\href{mailto:s...@exherbo.org}{s...@exherbo.org} \and Ciaran
-McCreesh \\
-\href{mailto:ciaran.mccre...@googlemail.com}
{ciaran.mccre...@googlemail.com}}
+\author{
+Ulrich Müller \\
+\href{mailto:u...@gentoo.org}{u...@gentoo.org}
+\and
+Stephen P. Bennett \\
+\href{mailto:s...@exherbo.org}{s...@exherbo.org}
+\and
+Christian Faulhammer \\
+\href{mailto:fa...@gentoo.org}{fa...@gentoo.org}
+\and
+Ciaran McCreesh \\
+\href{mailto:ciaran.mccre...@googlemail.com}
{ciaran.mccre...@googlemail.com}
+}
 % Reads the last commit date from the Git repository and even succeeds
 % when none is available
 \ifthenelse{\equal{\VCDateISO}{}}
--
1.7.9.4



--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing


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

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
 
 In case you're not aware, the first time Gentoo did multilib, it was
 done as a series of random changes to Portage that no-one really
 thought through or understood. As you can see, that didn't work... 

No, but paved the way for other distros as they had nothing even close.
I'm sure you remember back then. Don't be an ass.

-- 
Homer Parker hpar...@gentoo.org


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

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

On Thu, 2012-06-21 at 09:24 +0200, justin wrote:
 Won't it be a good thing, if you instead of showing all of us, that
 you
 can tell where people fail to present something in the right way, help
 and guide them to write the necessary things like PMS patches, GLEPs
 etc., so that we can proceed in an efficient way? 

That's not his style. Never has been, and I don't see that changing.

-- 
Homer Parker hpar...@gentoo.org


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

Re: [gentoo-dev] About what would be included in EAPI5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 07:04:41 -0500
Homer Parker hpar...@gentoo.org wrote:
   Damnit, let the user shoot themself in the foot but let them
 learn from it. Remember back in the day when you had no clue? You
 learned from it. You can only protect them so much. If they want to
 use custom patches then they need to learn how.

That's not the issue. The issue is advertising a user patches feature
when there's no way for the user to know up-front whether or not their
patches will be applied. This whole discussion started because user
patches are currently randomly ignored sometimes.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 07:11:27 -0500
Homer Parker hpar...@gentoo.org wrote:
 On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
  In case you're not aware, the first time Gentoo did multilib, it was
  done as a series of random changes to Portage that no-one really
  thought through or understood. As you can see, that didn't work... 
 
   No, but paved the way for other distros as they had nothing
 even close. I'm sure you remember back then. Don't be an ass.

And what did Gentoo get out of it?

What I remember is Gentoo putting in lots of work randomly changing
things until things worked, and ending up not knowing what most of
those changes were or why they were done. The end result is that
there's still a random smattering of multilib-related mess cluttering
up ebuild internals that doesn't actually do anything except cause
intermittent breakages. Doing experiments is great as a way of
understanding the problem, but it isn't how you deliver a solution.
That takes a lot more work, and someone has to be prepared to do it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 07:14:49 -0500
Homer Parker hpar...@gentoo.org wrote:
 On Thu, 2012-06-21 at 09:24 +0200, justin wrote:
  Won't it be a good thing, if you instead of showing all of us, that
  you
  can tell where people fail to present something in the right way,
  help and guide them to write the necessary things like PMS patches,
  GLEPs etc., so that we can proceed in an efficient way? 
 
   That's not his style. Never has been, and I don't see that
 changing.

Yeah, I'm afraid I'm not available for hire to work full time on
providing basic tutoring and hand-holding on design and technical
writing -- it's not really my cup of tea. But if you have the money,
there are plenty of others who make their livings teaching that sort of
thing.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-misc/lightdm: lightdm-1.2.2-r2.ebuild ChangeLog

[Alexis Ballier]

On Thu, 21 Jun 2012 16:42:11 +0800
Ben de Groot yng...@gentoo.org wrote:
  And users might
  still have older gobject-introspection installed, with nothing
  forcing the upgrade now.
 
 Regular maintenance should take care of that. We are not in the
 habit of specifying minimal versions for all dependencies.

yes we are, if you are not then you should change this.
things like https://bugs.gentoo.org/show_bug.cgi?id=266293 are
perfectly valid bugs and annoy users. its not because you hadnt had a
bug report that its not worth preventing it.

A.

[gentoo-dev] Re: Re: [gentoo-pms] Authorship of app-doc/pms

[Andreas K. Huettel]

  Dear all,
  according to git blame, this is the distribution of authorship
  across the current git master of the pms tex source.
 
 Not that I particularly mind either way, but your stats are way off due
 to reformatting. If you just use git blame, someone who changes a \t
 to a \em in a paragraph gets measured as writing that line and every
 line in the paragraph following it.
 
 If you're looking to change the authors list, I recommend doing so
 based upon asking people whether they think they should be on there, and
 adding anyone who says yes, rather than on bogus stats.

Well at least I added some data to undermine my request. Your turn now.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing


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

[gentoo-dev] Re: [gentoo-pms] Authorship of app-doc/pms

[Ciaran McCreesh]

On Thu, 21 Jun 2012 14:46:39 +0200
Andreas K. Huettel dilfri...@gentoo.org wrote:
  Not that I particularly mind either way, but your stats are way off
  due to reformatting. If you just use git blame, someone who
  changes a \t to a \em in a paragraph gets measured as writing that
  line and every line in the paragraph following it.
  
  If you're looking to change the authors list, I recommend doing so
  based upon asking people whether they think they should be on
  there, and adding anyone who says yes, rather than on bogus stats.
 
 Well at least I added some data to undermine my request. Your turn
 now.

Oh, I think your request is fine, and your results are reasonable. I
just think letting anyone who can say with a straight face that they
should be there be there is a better measure than numbers that don't
tell you anything.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

On Thu, 2012-06-21 at 13:30 +0100, Ciaran McCreesh wrote:
 On Thu, 21 Jun 2012 07:11:27 -0500
 Homer Parker hpar...@gentoo.org wrote:
  On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
   In case you're not aware, the first time Gentoo did multilib, it was
   done as a series of random changes to Portage that no-one really
   thought through or understood. As you can see, that didn't work... 
  
  No, but paved the way for other distros as they had nothing
  even close. I'm sure you remember back then. Don't be an ass.
 
 And what did Gentoo get out of it?
 
 What I remember is Gentoo putting in lots of work randomly changing
 things until things worked, and ending up not knowing what most of
 those changes were or why they were done. The end result is that
 there's still a random smattering of multilib-related mess cluttering
 up ebuild internals that doesn't actually do anything except cause
 intermittent breakages. Doing experiments is great as a way of
 understanding the problem, but it isn't how you deliver a solution.
 That takes a lot more work, and someone has to be prepared to do it.
 

The hell? Other distos where still thinking of how to implement
multilib and we had it. I know first hand as I trashed a system trying
out the latest-n-greatest.. And the next round fixed it. The -emul
packages from then on along with the multilib profiles have worked fine.
Again, quit being an ass. Oh, and what I remember is.. You didn't
contribute. There was kingtaco, lv, and kuglafang sp?. So you're clear
there, you didn't have a damn thing to do with it.

-- 
Homer Parker hpar...@gentoo.org


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

Re: [gentoo-dev] About what would be included in EAPI5

[Homer Parker]

On Thu, 2012-06-21 at 13:25 +0100, Ciaran McCreesh wrote:
 On Thu, 21 Jun 2012 07:04:41 -0500
 Homer Parker hpar...@gentoo.org wrote:
  Damnit, let the user shoot themself in the foot but let them
  learn from it. Remember back in the day when you had no clue? You
  learned from it. You can only protect them so much. If they want to
  use custom patches then they need to learn how.
 
 That's not the issue. The issue is advertising a user patches feature
 when there's no way for the user to know up-front whether or not their
 patches will be applied. This whole discussion started because user
 patches are currently randomly ignored sometimes.
 

I guess I missed it's not a global feature, sorry. That said,
everything else stands.

-- 
Homer Parker hpar...@gentoo.org


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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

On Thu, 21 Jun 2012 08:13:50 -0500
Homer Parker hpar...@gentoo.org wrote:
  And what did Gentoo get out of it?
  
  What I remember is Gentoo putting in lots of work randomly changing
  things until things worked, and ending up not knowing what most of
  those changes were or why they were done. The end result is that
  there's still a random smattering of multilib-related mess
  cluttering up ebuild internals that doesn't actually do anything
  except cause intermittent breakages. Doing experiments is great as
  a way of understanding the problem, but it isn't how you deliver a
  solution. That takes a lot more work, and someone has to be
  prepared to do it.
 
   The hell? Other distos where still thinking of how to
 implement multilib and we had it. I know first hand as I trashed a
 system trying out the latest-n-greatest.. And the next round fixed
 it. The -emul packages from then on along with the multilib profiles
 have worked fine.

...so why are people running around demanding that reinventing multilib
is the number one priority and has to be in EAPI 5 immediately then? I
was under the impression that your fellow developers don't consider the
-emul packages to be an adequate solution. If that isn't the case, and
the existing mechanism is in fact fine as you claim, then great, we can
ignore multilib from an EAPI perspective.

I can only go on what your colleagues are claiming here. I suggest if
you're upset at the suggestion that Gentoo doesn't have a decent
multilib implementation then you take it up with all the people who are
demanding the PMS team provide them with one.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/06/12 05:33 AM, Richard Yao wrote:
 On 06/21/2012 04:08 AM, Duncan wrote:
 Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as
 excerpted:
 
 3. How does getting a x86 system to boot differ from getting a
 MIPS system or ARM system to boot? Does it only work because
 the vendors made it work or is x86 fundamentally harder?
 
 I can answer this one.  x86 is harder at the bootloader stage,
 but in turn easier, or perhaps simply different, at the kernel
 and kernel device interface level.
 
 Consider, most MIPS and ARM systems ship with a specific set of
 basic devices, configured to use specific IO addresses, IRQs,
 etc, and that's it, at least to get up and running (USB devices,
 etc, may be able to be plugged in, but they're not normally
 needed for boot).  If you've been keeping up with the kernel (say
 via LWN, etc), this has been one of the big deals with the ARM
 tree recently, as until now each board had its own hard-coded
 kernel config directly in the tree, and it was getting 
 unmanageable.  They're switching to device tree, etc, allowing
 the boot loader to feed the kernel a file with this information
 at boot time, thus allowing a whole bunch of different boards to
 boot off the same shipped kernel, while at the same time getting
 the explosion of individual board files out of the kernel tree.
 This is a BIG deal on ARM and similar embedded archs, but doesn't
 affect x86 (either 32-bit or 64-bit) at all.
 
 Meanwhile, on x86, the system must be prepared for end-user
 switch-out of pretty much everything. memory, storage (consider
 floppy, hard drive, optical disk either direct or el-torito, USB
 stick, etc, all bootable and all end-user changable!), even
 quantity and speed of CPUs, and the firmware BIOS (or
 replacement) must cope with that and be able to boot off it.
 Even back in the 386 era when everything was jumper-configured, 
 users could still change pretty much everything out, other than
 the mobo itself.   Now days, it's even MORE complex, as most of
 these devices can be configured in dozens or hundreds of mode
 combinations via plug-n- pray, and they often don't /have/ a
 default -- they **MUST** be so configured in ordered to be
 operable for the intended use.  Sure, the BIOS CAN leave some of
 it for the kernel to do, but other bits, not so much, as
 otherwise, how does the kernel even get loaded -- the BIOS must 
 pick one of the many boot options, configure it (as well as the
 CPU and the system between storage and the CPU, storage chipset,
 memory, etc) at least well enough to read in the boot loader
 and/or kernel.  None of that's necessary on ARM, etc, because
 (pretty much) everything there's a totally arbitrary-as-shipped
 config, nothing to dynamically negotiate and get working before
 the kernel or secondary bootloader (after the BIOS) can even
 work!
 
 
 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?  Otherwise I don't see
how you could get away with the BIOS not worrying about all those
devices..  IE, I don't forsee many general x86 users giving up their
ability to boot off usb stick or cdrom or pxe based on a boot-time
bios choice, or to boot windows or alternative linux kernels (which
could be located who knows where) at whim.  And I don't see how an
alternative BIOS would be able to provide this ability without dealing
with all the things Duncan mentioned...


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU
7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI
=CwME
-END PGP SIGNATURE-

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

[Richard Yao]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

 Otherwise I don't see how you could get away with the BIOS not
 worrying about all those devices..  IE, I don't forsee many general
 x86 users giving up their ability to boot off usb stick or cdrom or
 pxe based on a boot-time bios choice, or to boot windows or
 alternative linux kernels (which could be located who knows where)
 at whim.  And I don't see how an alternative BIOS would be able to
 provide this ability without dealing with all the things Duncan
 mentioned...

An initramfs should be able to provide all of that functionality.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP4zgzAAoJECDuEZm+6ExkeSUP/0PrjZtnWvbdXpTYwTN/U1wq
lVl/nx6mXAq6wwxrhgHMzMvzh68oxqAhZgOASLFoQnO92WbVJzxBZtxBQftR5TGV
k5NGVKCLwVkIi7tQGLk3vLHo3l6MnmwCjmfSCSbr7VEqil2hgy5EwhUiWvibzKlp
34m9g75Z/JR/dMk7qcG7z2lvJNSDlL2Ufgqi5YPQqqmqsMHGi350ZM91dkilOkV2
OtBwJzD+JlvQl+ALBv33KmI37VslcB/ydcx08YfE6BuOkHdusOM6/Den4JUrmS2I
WDvcejzgxjneOifoL+0hiM9ooG3L6Q19G3ZNSSqAit85P5ms6Cm9Bul2lO6+EiQu
iwYLcH/5nwkVC/8bRaHvzTnSaKyvyip9lKzeZyD9fnsMirxV6R3T3aWyIwhBdb8E
pe85C+n4Wd5n4nhuwQW8AP860yftco9aNSrx1uIb+PMEi38+yLTwNjrR/shQ7RcK
76mpWIWat/YpLRNF9Va7PN3FaslsTGVyQdgcBtci9S9IXWhwGyc7ZDS7DIq7CYTT
9pE9dYqDOmEl0kWt5e4EgrjD4ibwhOsvddBJBcW2spphnRBuHwkzdp7K7pW3KX1z
Wj4triKllBLwMJvIcDk6Nv0tm0YO+kzxDhEsjBajjDR48652ijF6RYLi2cV7Ui+9
Hnsvgz6oEc7sNL9VbPnZ
=Aacv
-END PGP SIGNATURE-

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

[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] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Michał Górny wrote:

Hello,

A simple solution to a program long-unsolved. In GLEP form.


Just a couple of minor points/nitpicks:

1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, 
should REQUIRED_USE be re-verified:


a) for every dep resolution
b) when the package is involved in the resolution for some other reason 
(not necessarily being reinstalled, just when the resolver has some 
reason to look at it)

c) something else?

I think b) should be sufficient (and probably easier to implement), but 
is there any reason why it wouldn't be?


2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of 
package B being disabled, but it's unlikely to be useful.  To make this 
more concrete, a fictional but vaguely plausible example:


app-text/docmangler:

# links to poppler to handle PDFs, and can use Ghostscript for
# PostScript support if available
IUSE=postscript
IUSE_RUNTIME=postscript
DEPEND=app-text/poppler
RDEPEND=${DEPEND}
postscript? ( app-text/ghostscript )

app-misc/coolapp:

IUSE=doc
# if Ghostscript is installed, docmangler uses it for both
# PostScript and PDF files, but Ghostscript misrenders our PDFs
DEPEND=doc? ( app-text/docmangler[-postscript] )

Here, the [-postscript] dep would force the user to disable that flag, 
but it wouldn't do much good because Ghostscript would still be 
installed.  This doesn't happen with regular USE flags because (if the 
ebuild is written correctly) disabling the flag removes the feature even 
if its dependencies happen to be installed.


Possible solutions:

a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make 
sense in that case to disallow them in !foo-style conditionals in the 
dependencies of the package itself, as that could cause similar paradoxes)
c) don't address it in the spec itself, and require people to manually 
write the dep in the blocker form if it's required

d) something else?

a) is pretty icky IMHO, especially if the flag pulls in multiple 
packages.  I could live with either b) or c), but b) is less flexible 
and c) leaves a potential trap for the unwary.  Any opinions?

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

[Peter Stuge]

Roy Bamford wrote:
   I take it the above statement is based on the kernel being
   directly placed within the BIOS/firmware/nvram on the board,

This is sometimes called Linux-as-bootloader (LAB/lab for short) in
the coreboot project.


   such that you couldn't boot anything else but that kernel?

Yes and no. A kernel can kexec() another program.


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

Any firmware modification has potential to brick, and shouldn't be
done unless you are comfortable with the modification, or with
solving a brick problem. :)

Keep backup flash chips, if your boot flash is socketed.

There are also several software techniques to eliminate and/or
reduce the brick risk.

Again, if you flash nothing but a kernel into the boot flash then
the machine will just laugh at you in your face and not start.

coreboot has infrastructure for separating normal boot from fallback
boot, for when the normal boot fails.

Writing to the flash chip is not an all-or-nothing operation.
coreboot uses a super simple filesystem for the boot flash, which can
be aligned to eraseblocks in the flash chip, such that only ever the
normal boot files are erased and rewritten, while leaving fallback
contents untouched. Even a power outage during flashing will not
brick your machine.


 Get out your JTAG adaptor and another PC I suppose.

PCs don't usually have JTAG as convenient as embedded systems, but
the boot flash can always be written with other suitable dedicated
hardware, from the outside, as you write.


//Peter


pgp1B1JHshB5P.pgp
Description: PGP signature

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/06/12 03:05 PM, David Leverton wrote:
 Michał Górny wrote:
 Hello,
 
 A simple solution to a program long-unsolved. In GLEP form.
 
 Just a couple of minor points/nitpicks:
 
 [ Snip! ]
 
 2) It's not forbidden for package A to depend on an IUSE_RUNTIME
 flag of package B being disabled, but it's unlikely to be useful.
 To make this more concrete, a fictional but vaguely plausible
 example:
 
 app-text/docmangler:
 
 # links to poppler to handle PDFs, and can use Ghostscript for #
 PostScript support if available IUSE=postscript 
 IUSE_RUNTIME=postscript DEPEND=app-text/poppler 
 RDEPEND=${DEPEND} postscript? ( app-text/ghostscript )
 
 app-misc/coolapp:
 
 IUSE=doc # if Ghostscript is installed, docmangler uses it for
 both # PostScript and PDF files, but Ghostscript misrenders our
 PDFs DEPEND=doc? ( app-text/docmangler[-postscript] )
 
 Here, the [-postscript] dep would force the user to disable that
 flag, but it wouldn't do much good because Ghostscript would still
 be installed.  This doesn't happen with regular USE flags because
 (if the ebuild is written correctly) disabling the flag removes the
 feature even if its dependencies happen to be installed.
 
 Possible solutions:
 
 a) automatically rewrite the dep as postscript? (
 app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b)
 forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make 
 sense in that case to disallow them in !foo-style conditionals in
 the dependencies of the package itself, as that could cause similar
 paradoxes) c) don't address it in the spec itself, and require
 people to manually write the dep in the blocker form if it's
 required d) something else?
 
 a) is pretty icky IMHO, especially if the flag pulls in multiple 
 packages.  I could live with either b) or c), but b) is less
 flexible and c) leaves a potential trap for the unwary.  Any
 opinions?
 

I'd say (c) , since IUSE_RUNTIME is not an enforceable state of the
tree and if docmangler is used but fails when ghostscript is installed
anyways, then the DEPEND should specify this regardless of whether the
'postscript' flag (used by IUSE_RUNTIME) is set or whether ghostscript
is in the user's world file.





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jc+cACgkQ2ugaI38ACPCUOAD+ICKl69MUhUTRj+2HBQ0pNlvo
Bqa5/TmaD0oKIkLi+xgBAIGwynEBXC3dXsG7Amky0OiEUyen41kURybNLR8FIkT2
=jMZ4
-END PGP SIGNATURE-

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Michał Górny]

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton levert...@googlemail.com wrote:

 Michał Górny wrote:
  Hello,
 
  A simple solution to a program long-unsolved. In GLEP form.
 
 Just a couple of minor points/nitpicks:
 
 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, 
 should REQUIRED_USE be re-verified:
 
 a) for every dep resolution
 b) when the package is involved in the resolution for some other
 reason (not necessarily being reinstalled, just when the resolver has
 some reason to look at it)
 c) something else?
 
 I think b) should be sufficient (and probably easier to implement),
 but is there any reason why it wouldn't be?

Well, I don't understand the difference between a) and b) in your case
but the idea is that REQUIRED_USE should be re-verified if either
enabled USE flag list or REQUIRED_USE changes.

 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
 of package B being disabled, but it's unlikely to be useful.  To make
 this more concrete, a fictional but vaguely plausible example:
 
 app-text/docmangler:
 
 # links to poppler to handle PDFs, and can use Ghostscript for
 # PostScript support if available
 IUSE=postscript
 IUSE_RUNTIME=postscript
 DEPEND=app-text/poppler
 RDEPEND=${DEPEND}
  postscript? ( app-text/ghostscript )
 
 app-misc/coolapp:
 
 IUSE=doc
 # if Ghostscript is installed, docmangler uses it for both
 # PostScript and PDF files, but Ghostscript misrenders our PDFs
 DEPEND=doc? ( app-text/docmangler[-postscript] )
 
 Here, the [-postscript] dep would force the user to disable that
 flag, but it wouldn't do much good because Ghostscript would still be 
 installed.  This doesn't happen with regular USE flags because (if
 the ebuild is written correctly) disabling the flag removes the
 feature even if its dependencies happen to be installed.
 
 Possible solutions:
 
 a) automatically rewrite the dep as
  postscript? ( app-text/ghostscript )
  !postscript? ( !app-text/ghostscript )
 b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make 
 sense in that case to disallow them in !foo-style conditionals in the 
 dependencies of the package itself, as that could cause similar
 paradoxes) c) don't address it in the spec itself, and require people
 to manually write the dep in the blocker form if it's required
 d) something else?
 
 a) is pretty icky IMHO, especially if the flag pulls in multiple 
 packages.  I could live with either b) or c), but b) is less flexible 
 and c) leaves a potential trap for the unwary.  Any opinions?

Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Michał Górny wrote:

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton levert...@googlemail.com wrote:

1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:

a) for every dep resolution
b) when the package is involved in the resolution for some other
reason (not necessarily being reinstalled, just when the resolver has
some reason to look at it)
c) something else?


Well, I don't understand the difference between a) and b) in your case


Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and 
that I have it installed and then modify one of the flags it uses in my 
configuration, but don't run any PM commands.  Then suppose I install a 
Gnome package.  Normally installing a Gnome package wouldn't require the 
PM to go anywhere near kde-meta, but being strict about revalidating 
REQUIRED_USE would require it to look through every installed package, 
just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every 
installation command.  Is that necessary?


 but the idea is that REQUIRED_USE should be re-verified if either
 enabled USE flag list or REQUIRED_USE changes.

Would that mean the enabled USE flag list should be updated in the VDB 
every time REQUIRED_USE is checked, even when the package isn't being 
reinstalled?  I think it would probably be easier to just recheck 
REQUIRED_USE, without trying to figure out whether any of the 
IUSE_RUNTIME flags were changed, it's just a question of how eager we 
want to be.



2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
of package B being disabled, but it's unlikely to be useful.  To make
this more concrete, a fictional but vaguely plausible example:



Possible solutions:

a) automatically rewrite the dep as
  postscript? ( app-text/ghostscript )
  !postscript? ( !app-text/ghostscript )
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
sense in that case to disallow them in !foo-style conditionals in the
dependencies of the package itself, as that could cause similar
paradoxes)

 c) don't address it in the spec itself, and require people

to manually write the dep in the blocker form if it's required
d) something else?



Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).


One case that I forgot to mention before: if some package does something 
like


if has_version app-text/docmangler[postscript]; then
# ...
else
# ...
fi

Here, again, the else branch can lead to incoherent results as it 
can't assume that the postscript flag being disabled means Ghostscript 
isn't installed, and this one can't be forbidden by restricting the 
allowed dep forms.  I think we'd have to just say don't do that then

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

On Thu, 2012-06-21 at 14:20 +0100, Ciaran McCreesh wrote:
 On Thu, 21 Jun 2012 08:13:50 -0500
 Homer Parker hpar...@gentoo.org wrote:
   And what did Gentoo get out of it?
   
   What I remember is Gentoo putting in lots of work randomly changing
   things until things worked, and ending up not knowing what most of
   those changes were or why they were done. 

In the beginning there was a method...

 The end result is that
   there's still a random smattering of multilib-related mess
   cluttering up ebuild internals that doesn't actually do anything
   except cause intermittent breakages. Doing experiments is great as
   a way of understanding the problem, but it isn't how you deliver a
   solution. That takes a lot more work, and someone has to be
   prepared to do it.
  
  The hell? Other distos where still thinking of how to
  implement multilib and we had it. I know first hand as I trashed a
  system trying out the latest-n-greatest.. And the next round fixed
  it. The -emul packages from then on along with the multilib profiles
  have worked fine.
 
 ...so why are people running around demanding that reinventing multilib
 is the number one priority and has to be in EAPI 5 immediately then? I
 was under the impression that your fellow developers don't consider the
 -emul packages to be an adequate solution. If that isn't the case, and
 the existing mechanism is in fact fine as you claim, then great, we can
 ignore multilib from an EAPI perspective.

And now it needs revamped.. I see no problem with re-investigating the
problem to make it better/easier/whatever.

 I can only go on what your colleagues are claiming here. I suggest if
 you're upset at the suggestion that Gentoo doesn't have a decent
 multilib implementation then you take it up with all the people who are
 demanding the PMS team provide them with one.
 

I can only suggest you keep track of your train of thought.. In the
beginning vs now are two completely separate issues. We were first, is
it surprising the method needs looked at? No.



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

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Michał Górny]

On Thu, 21 Jun 2012 21:26:26 +0100
David Leverton levert...@googlemail.com wrote:

 Michał Górny wrote:
  On Thu, 21 Jun 2012 20:05:46 +0100
  David Leverton levert...@googlemail.com wrote:
  1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
  should REQUIRED_USE be re-verified:
 
  a) for every dep resolution
  b) when the package is involved in the resolution for some other
  reason (not necessarily being reinstalled, just when the resolver
  has some reason to look at it)
  c) something else?
 
  Well, I don't understand the difference between a) and b) in your
  case
 
 Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and 
 that I have it installed and then modify one of the flags it uses in
 my configuration, but don't run any PM commands.  Then suppose I
 install a Gnome package.  Normally installing a Gnome package
 wouldn't require the PM to go anywhere near kde-meta, but being
 strict about revalidating REQUIRED_USE would require it to look
 through every installed package, just in case any have IUSE_RUNTIME
 and REQUIRED_USE set, for every installation command.  Is that
 necessary?

No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).

Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.

   but the idea is that REQUIRED_USE should be re-verified if either
   enabled USE flag list or REQUIRED_USE changes.
 
 Would that mean the enabled USE flag list should be updated in the
 VDB every time REQUIRED_USE is checked, even when the package isn't
 being reinstalled?  I think it would probably be easier to just
 recheck REQUIRED_USE, without trying to figure out whether any of the 
 IUSE_RUNTIME flags were changed, it's just a question of how eager we 
 want to be.

No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.

  2) It's not forbidden for package A to depend on an IUSE_RUNTIME
  flag of package B being disabled, but it's unlikely to be useful.
  To make this more concrete, a fictional but vaguely plausible
  example:
 
  Possible solutions:
 
  a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
  b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
  sense in that case to disallow them in !foo-style conditionals in
  the dependencies of the package itself, as that could cause similar
  paradoxes)
   c) don't address it in the spec itself, and require people
  to manually write the dep in the blocker form if it's required
  d) something else?
 
  Good observation. I think b) is the best solution since forced
  removal of random dependencies is a very bad idea (and misuse of
  blockers).
 
 One case that I forgot to mention before: if some package does
 something like
 
  if has_version app-text/docmangler[postscript]; then
  # ...
  else
  # ...
  fi
 
 Here, again, the else branch can lead to incoherent results as it 
 can't assume that the postscript flag being disabled means
 Ghostscript isn't installed, and this one can't be forbidden by
 restricting the allowed dep forms.  I think we'd have to just say
 don't do that then

Well, as I see it restricting is more of a policy than a technical
requirement. But in the current form, the spec doesn't allow passing
IUSE_RUNTIME flags to has_version() so we're on the safe side :P.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

[Michał Górny]

Just a short note as it seems some confusion arises lately:

Ciaran McCreesh is not a Gentoo dev and his words don't represent
the position of Gentoo development team.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Michał Górny wrote:

No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).

Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.


That's what I thought, was just making sure we're on the same page.


No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.


'K


Well, as I see it restricting is more of a policy than a technical
requirement.


As long as we're clear on which it is, and what restrictions if any the 
PM can/should impose...



But in the current form, the spec doesn't allow passing
IUSE_RUNTIME flags to has_version() so we're on the safe side :P.


True.  Do we want to keep it that restrictive?

Re: [gentoo-dev] Packages up for grabs due wormo taking care of bug wrangling only

[Christian Ruppert]

On 06/17/12 at 12:02AM +0200, Christian Ruppert wrote:
 On 06/16/12 at 11:39AM +0200, Pacho Ramos wrote:
  app-admin/ulogd
  app-arch/pdv
  
  
  
  Feel free to get them
  
  Thanks
  
  
  
 
 I'll take app-admin/ulogd.
 
 -- 
 Regards,
 Christian Ruppert
 Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member
 Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8

It may take some time till I get to it so if someone else is faster, feel free.
:P

-- 
Regards,
Christian Ruppert
Gentoo Linux developer, Bugzilla administrator and Infrastructure member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8


pgpQsfUqv2mKF.pgp
Description: PGP signature

Re: [gentoo-dev] My wishlist for EAPI 5

[Rich Freeman]

On Thu, Jun 21, 2012 at 4:26 PM, Homer Parker hpar...@gentoo.org wrote:

        In the beginning there was a method...

        And now it needs revamped.. I see no problem with re-investigating the
 problem to make it better/easier/whatever.


++

I for one am happy to have had a working amd64 system for the last
decade, even if it might have been somewhat better if I had been stuck
on 32-bit while the perfect system was devised.

Gentoo doesn't need thrown-together hacks, but half-decent solutions
that work shouldn't be held up in favor of ideal solutions that don't
exist.  There is always room for evolution.

That said, as far as EAPIs go I'm in favor of shipping whatever is
ready to ship.

Rich

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

[Rich Freeman]

On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge pe...@stuge.se wrote:
 Roy Bamford wrote:

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

 Any firmware modification has potential to brick, and shouldn't be
 done unless you are comfortable with the modification, or with
 solving a brick problem. :)

So, why are we still going back and forth about this?  If people want
to work on coreboot they can do so (I'm sure they have a list).  If
people want to fork coreboot or redo it from scrach they can do so and
start their own list.

When it is shiny and perfect and has a following of hundreds of linux
users we can always discuss whether we recommend using it in the
handbook on -dev then.  Otherwise it seems about as on-topic as
debating whether grub or systemd or openrc should have feature A/B/C -
we're a DISTRO - we integrate and ship what upstream gives us...

Rich

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

[Richard Yao]

On 06/21/2012 06:51 PM, Rich Freeman wrote:
 On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge pe...@stuge.se wrote:
 Roy Bamford wrote:

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

 Any firmware modification has potential to brick, and shouldn't be
 done unless you are comfortable with the modification, or with
 solving a brick problem. :)
 
 So, why are we still going back and forth about this?

This idea has technical merit and it has sparked a very insightful
discussion in which I learned many things that I did not know. My
original intention in emailing the list was to learn such things, so my
email has fulfilled its purpose.

My email has also led to an interesting off list conversation between
myself and Peter about this. I believe that the exchange of ideas that
this prompted has been mutually beneficial. My hope is that our
discussion catalyzes improvements in both Gentoo and coreboot.

On 06/21/2012 06:51 PM, Rich Freeman wrote:
 we're a DISTRO - we integrate and ship what upstream gives us...

RHEL is a distribution, but I understand that RedHat does a great deal
of upstream programming and is also upstream for some things. Do you
consider it to be inappropriate for us to play a larger role in both
upstream development and as upstream ourselves?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Richard Yao]

On 06/21/2012 04:29 AM, Duncan wrote:
 Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:
 
 On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
 On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org wrote:
 
 POSIX Shell compliance

 So far as I know, every PM relies heavily upon bash anyway (and can't
 easily be made not to), so even if developers would accept having to
 rewrite all their eclasses, it still wouldn't remove the dep.

 Lets address POSIX compliance in the ebuilds first. Then we can deal
 with the package managers.
 
 Additionally, this is extremely unlikely because a number of developers 
 insist on bash, to the extent that it would likely split gentoo in half 
 if this were to be forced.  It wouldn't pass council.  It's unlikely to 
 even /get/ to council.
 
 Openrc could move to POSIX shell because its primary dev at the time 
 wanted it that way and it's only a single package.  However, even then, 
 doing it was controversial enough that said developer ended up leaving 
 gentoo in-part over that, tho he did continue to develop openrc as a 
 gentoo hosted project for quite some years.  Now you're talking trying to 
 do it for /every/ (well, almost every) package, thus touching every 
 single gentoo dev.  It's just not going to happen in even the medium term 
 (say for argument APIs 5-7ish), let alone be something practical enough 
 to implement, soon enough (even if everyone agreed on the general idea, 
 they don't), to be anything like conceivable for EAPI5.
 
 So just let that one be.  It's simply not worth tilting at that windmill.

Would you (or someone else) elaborate on the specific features of bash
that people find attractive?

Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

[Homer Parker]

On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote:
 Just a short note as it seems some confusion arises lately:
 
 Ciaran McCreesh is not a Gentoo dev and his words don't represent
 the position of Gentoo development team.
 


Amen.

-- 
Homer Parker hpar...@gentoo.org


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

Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

[Sylvain Alain]

Amen to that too, but can you post the actual comments that he said ?



2012/6/21 Homer Parker hpar...@gentoo.org

 On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote:
  Just a short note as it seems some confusion arises lately:
 
  Ciaran McCreesh is not a Gentoo dev and his words don't represent
  the position of Gentoo development team.
 


 Amen.

 --
 Homer Parker hpar...@gentoo.org




-- 
Salut
alp
Sylvain

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Zac Medico]

On 06/21/2012 02:32 PM, David Leverton wrote:
 Michał Górny wrote:
 But in the current form, the spec doesn't allow passing
 IUSE_RUNTIME flags to has_version() so we're on the safe side :P.
 
 True.  Do we want to keep it that restrictive?

Shouldn't has_version allow any atom that would be allowed in *DEPEND?
-- 
Thanks,
Zac

Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

[Doug Goldstein]

On Thu, Jun 21, 2012 at 9:12 PM, Sylvain Alain d2racing...@gmail.com wrote:
 Amen to that too, but can you post the actual comments that he said ?



 2012/6/21 Homer Parker hpar...@gentoo.org

 On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote:
  Just a short note as it seems some confusion arises lately:
 
  Ciaran McCreesh is not a Gentoo dev and his words don't represent
  the position of Gentoo development team.
 


        Amen.

 --
 Homer Parker hpar...@gentoo.org




 --
 Salut
 alp
 Sylvain


Guys,

Let's act like adults here. Just because someone disagrees with you
doesn't mean they have something personally against you so there's no
reason to take it to that level. This thread should end right now in
the interest of civil discussion.

-- 
Doug Goldstein

[gentoo-dev] Re: Killing UEFI Secure Boot

[Duncan]

Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:

 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.

But you have to be able to load the kernel first, before it can do all 
that detection.  And to load it, you need to be able to read the device 
it's located on, which in a modern x86 system (as contrasted with mips/
arm) generally means detection of what's there, some mechanism to choose 
which available devices to check for a kernel or boot loader or whatever, 
and some way to dynamically configure it, since many devices are simply 
(device info probable) bricks until configured, these days.

Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian 
S suggested), but then you're back to hard-configuring it in ordered to 
do so, thus losing all that extra flexibility that's part of what makes 
x86 different.  Which was the question that I was addressing.

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

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Doug Goldstein]

On Thu, Jun 21, 2012 at 2:42 AM, Michał Górny mgo...@gentoo.org wrote:
 On Thu, 21 Jun 2012 08:30:24 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Thu, 21 Jun 2012 09:29:49 +0200
 Michał Górny mgo...@gentoo.org wrote:
  On Wed, 20 Jun 2012 18:24:33 +0100
  Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
   On Wed, 20 Jun 2012 19:11:33 +0200
   hasufell hasuf...@gentoo.org wrote:
On 06/20/2012 07:07 PM, Michał Górny wrote:
 Please read the rationale. Again. The whole thing. Three
 times.
   
Please read my suggestions. Again. The whole thing. Three times.
  
   Can we all agree to just stop this and just restrict the arguing
   to being between SDEPEND and DEPENDENCIES? Cheers.
 
  You just volunteered to write portage patches. Cheers.

 Both were already implemented in Paludis, if you're looking for a
 reference implementation to try it out. There are also examples of
 use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
 can give you a small patch to turn SDEPEND on for an EAPI if you like
 (it's just a one line addition to the EAPI definition file).

 Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
 in Paludis' doesn't work here. We're discussing Gentoo features,
 and official package manager in Gentoo is portage. If you don't believe
 me, check out the docs.

 --
 Best regards,
 Michał Górny

I would recommend the two of you step away from this thread and
discussion for a day or two and come back to it with a fresh look at
the suggestions and the code that's available and then we can move on
getting this into an EAPI from there.

-- 
Doug Goldstein

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

[Richard Yao]

On 06/22/2012 01:02 AM, Duncan wrote:
 Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
 
 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.
 
 But you have to be able to load the kernel first, before it can do all 
 that detection.  And to load it, you need to be able to read the device 
 it's located on, which in a modern x86 system (as contrasted with mips/
 arm) generally means detection of what's there, some mechanism to choose 
 which available devices to check for a kernel or boot loader or whatever, 
 and some way to dynamically configure it, since many devices are simply 
 (device info probable) bricks until configured, these days.
 
 Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian 
 S suggested), but then you're back to hard-configuring it in ordered to 
 do so, thus losing all that extra flexibility that's part of what makes 
 x86 different.  Which was the question that I was addressing.
 

Placing it in the firmware is what I suggested. I also later stated that
it is possible for the firmware to contain an initramfs that would
enable it to start a kernel located on a device.

It seems to me that this would work if device trees for motherboards
were readily available and the EEPROM chips have sufficient capacity. I
am under the impression that UEFI firmware is large enough that capacity
on UEFI motherboards should not be an issue. The main issue would be
obtaining device trees.

[gentoo-dev] Re: My wishlist for EAPI 5

[Duncan]

Richard Yao posted on Thu, 21 Jun 2012 20:38:17 -0400 as excerpted:

 Would you (or someone else) elaborate on the specific features of bash
 that people find attractive?

For me (not a gentoo dev), in simplest terms it's just that I don't like 
having to keep track of what's a bashism and what's POSIX.  If individual 
devs prefer POSIX code, they can certainly write ebuilds (or a 4th gentoo 
package manager for that matter) in all POSIX, but there's enough devs 
that for /whatever/ reason strongly prefer bash, where strongly is 
ultimately defined as if it's redefined to POSIX, there's a lot of other 
projects I can spend my time on instead, that won't force me into jumping 
thru those hoops, and that fact is widely enough known, that it's 
unlikely in the extreme.

But to give you a example I've seen on this list (one of the few bits I 
know isn't POSIX)...  Many people appreciate the advantages of [[ tests, 
looser quoting, ==/=~ pattern matching tests, etc.

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

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

[Richard Yao]

On 06/22/2012 01:10 AM, Richard Yao wrote:
 On 06/22/2012 01:02 AM, Duncan wrote:
 Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:

 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.
 But you have to be able to load the kernel first, before it can do all 
 that detection.  And to load it, you need to be able to read the device 
 it's located on, which in a modern x86 system (as contrasted with mips/
 arm) generally means detection of what's there, some mechanism to choose 
 which available devices to check for a kernel or boot loader or whatever, 
 and some way to dynamically configure it, since many devices are simply 
 (device info probable) bricks until configured, these days.

 Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian 
 S suggested), but then you're back to hard-configuring it in ordered to 
 do so, thus losing all that extra flexibility that's part of what makes 
 x86 different.  Which was the question that I was addressing.

 Placing it in the firmware is what I suggested. I also later stated that
 it is possible for the firmware to contain an initramfs that would
 enable it to start a kernel located on a device.

 It seems to me that this would work if device trees for motherboards
 were readily available and the EEPROM chips have sufficient capacity. I
 am under the impression that UEFI firmware is large enough that capacity
 on UEFI motherboards should not be an issue. The main issue would be
 obtaining device trees.

Before anyone says it, information on how to initialize the memory
controller and possibly a few other bits prior to loading the kernel is
also necessary. I omitted that by mistake.

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Michał Górny]

On Thu, 21 Jun 2012 20:38:17 -0400
Richard Yao r...@gentoo.org wrote:

 On 06/21/2012 04:29 AM, Duncan wrote:
  Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:
  
  On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
  On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao r...@gentoo.org
  wrote:
  
  POSIX Shell compliance
 
  So far as I know, every PM relies heavily upon bash anyway (and
  can't easily be made not to), so even if developers would accept
  having to rewrite all their eclasses, it still wouldn't remove
  the dep.
 
  Lets address POSIX compliance in the ebuilds first. Then we can
  deal with the package managers.
  
  Additionally, this is extremely unlikely because a number of
  developers insist on bash, to the extent that it would likely split
  gentoo in half if this were to be forced.  It wouldn't pass
  council.  It's unlikely to even /get/ to council.
  
  Openrc could move to POSIX shell because its primary dev at the
  time wanted it that way and it's only a single package.  However,
  even then, doing it was controversial enough that said developer
  ended up leaving gentoo in-part over that, tho he did continue to
  develop openrc as a gentoo hosted project for quite some years.
  Now you're talking trying to do it for /every/ (well, almost every)
  package, thus touching every single gentoo dev.  It's just not
  going to happen in even the medium term (say for argument APIs
  5-7ish), let alone be something practical enough to implement, soon
  enough (even if everyone agreed on the general idea, they don't),
  to be anything like conceivable for EAPI5.
  
  So just let that one be.  It's simply not worth tilting at that
  windmill.
 
 Would you (or someone else) elaborate on the specific features of bash
 that people find attractive?

Local variables, reasonable behavior (like 'FOO=abc bar' where bar is
macro), arrays, [[ ]] tests (which are obviously faster than calling
external test program).

One more use: printing useful die messages (in POSIX sh there's no way
to do a backtrace).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature