rking udev and making sure it stays as lean as possible isn't that bad.
Making mdev a bit richer and enjoy the speed advantage of busybox over
stand alone shells could be another option.
Most of the perceived speed in non-shell init systems is due not having
to spawn as many processes. A full busybox wouldn't spawn many processes.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
od fit for embedded devices.
Last time I looked at systemd it was anything that lean.
Obviously you can say that if you already need dbus and glib and ...
${systemd_deplist} it doesn't count.
Likewise if you are already using busybox it comes with a quite rich shell.
Most depends on what you c
On 07/26/2012 12:45 PM, Andreas K. Huettel wrote:
>>>>>>> On Thu, 26 Jul 2012, Luca Barbato wrote:
>>> I'd add it, it is a gpl incompatible opensource license.
>>
>> No problem to add it. But IMHO the usage restriction in section 3
>> mak
I'd add it, it is a gpl incompatible opensource license.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Software License for The Fraunhofer FDK AAC Codec Library for Android
© Copyright 1995 - 2012 Fraunhofer-Gesellschaft zur Förderung der angewandten
Forschung e.V.
fference if that ABI is native or not.
cross vs host paths is an annoying problem due the slightly different
behaviour between native and cross compiler toolchains, it tends to
ignore environment variables and other small differences making dropping
an native cross compiler in a qemu chroot, QUI
is _really_ annoying for
qemu-chroots)
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
succeed either adding to busybox the missing bits
of bash we use or forking bash (so eventually it could be developed on a
source repo) and making it lean and fast for our specific purposes.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
y but program that have to run. Think about generators.
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/hfm8ACgkQ6
and possibly split RDEPEND/DEPEND to have HDEPEND to list build
dependencies that need to be run on host.
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigm
On 06/17/2012 05:39 PM, Michał Górny wrote:
> But Python doesn't have one. Bindings built using other
> languages don't have that either.
That seems something interesting to tackle with the python community.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
the purpose of the xfconf.eclass which is designed so that we
> cope with 99,0% using just pkg_setup()
defining a function and call it from the eclass would be impossible?
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
nt to try to get serious on 5, we could try to gather the
hardened/security people across distributions and setup the whole chain
to be parallel and cut deals with OEM to store this trust-chain keys
along with MS.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
they mandate a UI which lists all boot images known to the EFI boot
> manager, and the user can easily whitelist both individual loaders and
> the keys used to sign them.
>
That would be a good compromise.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
gt; Is there a wiki or forum thread somewhere where folks can gloat and/or
>> commiserate?
>
> i haven't set up anything
Shall we start a http://wiki.gentoo.org/wiki/amd64-x32 page?
> -mike
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIG
What I am afraid of is that we use nested list
> with tricky syntax, and one could miss the specifics of "" use.
it doesn't look that bad, the result would be getting
foo and bar in workdir I guess.
for github, sourceforge, bitbucket, gnome, etc, we might use something
like gi
urprising
> (not that the fallback syntax isn't surprising already).
Does not look that bad, do you have an actual example so we can see how
bad could get?
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GN
s the systemd in the url might be have people consider it a sort
of tell-tale. It could had been
http://bluez.org/known_issue/separate-usr-problems
Maybe.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
uite*
concerned about this "vertical" and linux-only approach.
If you consider that in 2 weeks the whole thing went from "udev moves to
systemd since is easier for us, but not be concerned udev can build
stand alone" to "udev stand alone is unsupported" you ca
On 04/05/12 17:59, Greg KH wrote:
> On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
>> On 04/05/12 14:35, Walter Dnes wrote:
>>> What could work is a shim or compatability layer that gets
>>> called, and pre-processes requests and forwards them to
How are you going to not use it then?
I guess freebsd is still a supported platform for enlightenment and all
the programs I use.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
more precise, they should work
> with
> anything that uses the so-called "uno bridge".
>
> This is why I like the new category "office-plugins" best... and would like
> to
> implement that one.
>
> Any additional objections?
I pre
On 04/05/12 14:35, Walter Dnes wrote:
> What could work is a shim or compatability layer that gets
> called, and pre-processes requests and forwards them to mdev.
That's my idea =)
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
see how hard is to make
that nicer for our non-udev/non-dbus users on linux.
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+kMHwACg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/05/12 11:35, "Paweł Hajdan, Jr." wrote:
> On 5/4/12 8:02 PM, Luca Barbato wrote:
>> I consider dbus still not reliable for core services.
>
> Just curious - why? I just have no idea about how dbus works or what are
&g
doubt Chrom{e,ium} is losing tons of users due to their udev /
> dbus / etc requirements.
If dbus and libudev are just for fringe features might be nice disable
them. I wonder if there isn't already a setting for it. chrome for
android won't use them anyway.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
anything beyond the C library.
The integration would be mdev -> shell -> dbus or mdev -> socket ->
dbus. I consider dbus still not reliable for core services.
> -mike
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG
ormation? I guess would be
possible to patch it out, probably dbus would cover that base as well.
(As soon I have some time I might dabble with a dbus integration for mdev)
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18
afe and store the messages somewhere in tmpfs and
write them to issue right before giving a shell.
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
ystem in a hard to recover state because you happened to
> forget to check a filesystem option (which ironically isn't under Filesystems
> in the kernel). it's piss-poor user facing behavior.
Many already stated that regarding that version of udev, no reason to
restate it a
conf's (I thought it was GPLv3, which
> would've meant it wasn't compatible)...We'll work on getting those
> patches and the pkg.m4 in the tree and getting a 0.2 release rolled
> out in the next day or 2.
I just sent a couple of patches to pkg-config to update the m4 with some
additional macros to provide stock --with-foo, I guess they will be
useful for you as well, if you import it before I can send you the same
patchset.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
hould not
have huge deps and that assumption fails for a number of reasons, I
guess mostly due the fact who writes some software doesn't expect it to
be run on early boot =\
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
rested in), but there is
> also
> "pkg-config-lite" and "pkgconf". they should be compatible with the
> canonical
> pkg-config. they aren't yet in the tree, but will be once we agree on this
> topic.
>
> any comments ?
Please do now =)
lu
- --
it is either fix the programs or find replacement
that have less or no dependencies.
> Did someone mentioned mentioning two cross-linked program/data trees
> (well, three or four in our case) with fuzzy classification rules is
> against KISS?
Enumerate them, I'm sick of vague problem
orked
> on (see [1]), I feel that the statement above that newer udev can't be
> stabled should be re-evaluated.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
the
>> all-clear.
>
> To the best of my knowledge, the repo should be fixed now. Please note
> that the history has changed. So either do a fresh git clone or follow
> git-rebase(1), section "RECOVERING FROM UPSTREAM REBASE".
>
Thank you a lot =)
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 3/25/12 11:56 AM, Krzysztof Pawlik wrote:
On 28/02/12 22:13, Krzysztof Pawlik wrote:
If there are no objections then during the weekend (March 3, 4) I will add this
to portage (after finishing remaining TODO items, PyPy requires 4G of RAM(!!)).
Hello,
Slightly late due to Real Life™ but fi
Provided with the eselect opengl patch an implementation and the mesa
changes. If they are ok for everybody I'd change the ati and nvidia
drivers as well. (a better name for the amd-graphics driver would be
welcome btw)
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Additionally make switching headers and libraries work for GLES OpenVG
and EGL.
---
modules/opengl.eselect | 30 ++
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/modules/opengl.eselect b/modules/opengl.eselect
index 2e8dd23..3f55ed5 100644
--- a/mod
he paths and have the
bind-mount game working, the alternative way is to build the native part
by unpacking the cross packages and the build system packages there
so
/ <- emulated
/etc/ld.so.conf.d/native
/usr/${nativehost}/
/usr/${emulatedhost}/
and then you need to trick portage a bit
Sounds
aviocat, graph2dot ismindex, qt-faststart
and cws2fws under either a single useflag or unconditionally.
The rest of the tools aren't of any use since avprobe superceeds them.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Hi, I tried to avoid depending on eselect-python if the useflag is disabled.
Please test and review.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
--- /usr/portage/eclass/python.eclass 2012-03-06 20:31:12.0 -0800
+++ /var/tmp/python.eclass 2012-03-19 21:24
On 3/14/12 10:59 AM, Rich Freeman wrote:
Well, anybody is welcome to create any replacement/addition for
(/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it
good enough, perhaps others will even use it.
There is a SoC out there for that.
Beyond that, anything else is just a sug
On 3/14/12 4:37 PM, Greg KH wrote:
Not really, I don't think we support systems without udev anymore,
right? And we get away with a lot of these different "options" at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.
I think we support
On 3/14/12 10:58 AM, Matthew Summers wrote:
__Everyone__ is already using an initramfs, therefore there are no
initramfs-less systems anymore (it may just be empty). Every single
person reading this thread that has not already done so needs to
immediately go read the relevant documentation locat
On 3/12/12 8:53 PM, Robin H. Johnson wrote:
On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote:
Yeah, I think it's an easy fix either in openrc or in an initscript
somewhere. I changed nothing except my kernel (was missing devtmpfs -- it's
not under Filesystems!), uninstalled module-
On 3/11/12 10:33 AM, William Hubbs wrote:
On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
On 3/10/12 6:53 PM, Rich Freeman wrote:
neither the genkernel nor dracut docs have specific instructions about
I guess we could pour more effort in getting dracut more easy to use
and/or
On 3/10/12 7:50 PM, Rich Freeman wrote:
Well, I'm trying not to take sides in that war. Unless we want to
patch the living daylights out of upsteam it seems almost moot.
It is not a matter about siding. If our boot process requires glib or
dbus we are sore idiots if we aren't either of them a
On 3/10/12 6:53 PM, Rich Freeman wrote:
neither the genkernel nor dracut docs have specific instructions about
I guess we could pour more effort in getting dracut more easy to use
and/or try to figure out which are the items that should be moved to /
and fix the remaining ones...
lu
On 03/03/12 18:26, Luca Barbato wrote:
> I'm trying to get better support for efika and possibly other similar
> systems like pandaboard.
In order to make all the headers switchable I'd move the headers to
specific dirs, so we would have global/GL and all the implementations
tter ideas?
lu
PS: I'd consider GL implementations monolithic so you cannot mix and
match them at least for now.
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 28/02/12 13:03, Martin Gysel wrote:
> Am 28.02.2012 11:51, schrieb Luca Barbato:
>> I'd add a new ebuild for qemu-user that is always static, with a
>> initscript to ease having the binfmt set up, it will be close
>> resembiling the ebuild qemu-user-static from sabayon
be close
resembiling the ebuild qemu-user-static from sabayon and not colliding
with qemu.
Is anybody against to this approach?
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 2/23/12 3:47 PM, Francesco Riosa wrote:
Hi,
my name is Francesco Riosa, I would be interested in a more
complete support of the oyranos color managment programs in ::gentoo.
Oyranos is intended to be multy platform and in some sense multy os,
but in the current incarnation has good support
On 2/11/12 2:00 PM, Fabio Erculiani wrote:
I think this is not the first time it's been discussed here, but maybe
I'm wrong.
Other distros associate a more user-friendly package name (application
name) to packages.
Say, they bind libreoffice-writer to "LibreOffice Writer" in package metadata.
Ho
On 11/7/11 3:58 PM, Samuli Suominen wrote:
On 11/07/2011 11:57 AM, Diego Elio Pettenò wrote:
Il giorno dom, 06/11/2011 alle 19.37 +0200, Samuli Suominen ha scritto:
With bug 365121 we don't really have a working compiz in Portage
anymore
for quite a while.
I'm using it with USE=-dbus ... mayb
On 11/5/11 1:58 AM, Kacper Kowalik wrote:
Hi,
I'd like to ask that we enable verbose building by default. I have
cmake-utils.eclass in mind, because it's dead easy there, but there's a
lot of packages that support things like "make V=1" or "make VERBOSE=1" too.
I've seen too many bugs reports to
sr so the
new and grand udev can do all its stuff...
Going around upstream asking to provide init.d files themselves might be
useful btw.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 9/15/11 1:33 PM, Joost Roeleveld wrote:
On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote:
On 15/09/2011 16:33, Joost Roeleveld wrote:
Hi Devs,
Not sure if you are aware of the discussions on the gentoo-user list
about the upcoming change where systemd and udev require /usr to
support burden for no gain...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 5/20/11 6:54 PM, Mike Pagano wrote:
On Friday 20 May 2011 04:58:12 Luca Barbato wrote:
On 5/17/11 6:57 PM, William Hubbs wrote:
That shouldn't be read as endorsing the peculiar and conceptually broken
init replacement called systemd.
lu
Just curious, would you mind elaborating on
On 5/17/11 6:57 PM, William Hubbs wrote:
All,
I think we should support the /run directory [1] [2]. The issue is
that there are at least two packages, udev and dracut, in gentoo, which
support the use of this directory. Support for it is being worked on in
openrc, and systemd will use it once it
On 03/23/2011 04:17 PM, Tomáš Chvátal wrote:
> And yep i think we should provide both options if they really continue
> to evolve (seems like libav is done by everyone and ffmpeg by vlc guys).
VLC is just graciously hosting the git...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gent
til there is a proper replacement for this handling,
the Gentoo sources archive, we really shouldn't be putting the data in
non-permanent locations, the team should, nowadays, be on the same page
as me on this."
I read it as: before infra was against, now they should be on the same
page -> thus agree.
my 2 eurocents
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
: I'm checking what happens with the xcb move since it should be
compatible but it could not.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
std_shrext .so .a .la; do
# Search the libtool library
lib="$searchdir/lib${name}${search_ext}"
if test -f "$lib"; then
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 10/5/10 4:33 PM, Ciaran McCreesh wrote:
On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbato wrote:
Bluntly put, you seem to not know how libtool exactly works and
further down in the thread how linking exactly works. Please try to
learn the fine Gentoo docs on the subject and feel free to ask
On 10/5/10 9:52 AM, Angelo Arrifano wrote:
By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I don't
really feel like forcing users to change
packages.
Well I consider the .la sort of legacy byproduct of libtool and not
something useful, probably in the future I'll send a patch to have the
.la put as last item in search order for both libtool and libltdl to
make it a non issue for everybody =P
lu
--
Luca Barbato
Gentoo/
On 10/04/2010 12:00 AM, Rémi Cardona wrote:
Using libltdl (libtool's dlopen wrapper) is a*legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.
To my knowledge ltdl would load just fine the .so if the .la isn't found.
lu
--
Luca Barbato
Ge
ed" by checking whether anything currently
in the tree needs it, but this doesn't take into account anything that
/isn't/ in the tree yet.
I think the simpler solution is that if it needs .la, before reaching
the tree it has to be fixed...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
#x27;t an earth shattering change like a nonfunctional libc in the
stable tree or a broken version of coreutils, please keep a bit of
perspective.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
d in a way I can understand so that I
can address them?
During the past discussions you were somehow overly conservative, taking
issue of corner cases and overall on the aggressive stance.
I know that you had a rough week but others do as well, Diego among them.
lu
--
Luca Barbato
G
working with iproute2 or any other tool
> that i already know the syntax of. no need to learn ridiculously
> convoluted array syntax foo for /etc/init.d/net.eth*.
if you are using /etc/ifup.eth* what would prevent having oldnet run
those as the newnet do?
lu
--
Luca Barbato
Gentoo/linux
htt
e great ^^
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 08/23/2010 11:07 PM, Mike Frysinger wrote:
> On Monday, August 23, 2010 16:21:44 Luca Barbato wrote:
>> I'd put openrc on freedesktop btw.
>
> we've sort of already settled into the places ... jumping to another place
> doesnt gain us much. current infrastructure
e for all our use-cases, not as stable as openrc nowadays,
not as fast as suggested and for server usage plainly wrong.
I'd put openrc on freedesktop btw.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
he qt team about it.
I'd like to have a gles and an openvg useflag defined to:
gles - prefer using egl+opengles instead of glx+opengl
openvg - enable openvg support
Comments?
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
> Attaching both the new rev and a diff against the first one.
What about having a SCONSOPTS and leave MAKEOPTS unmangled?
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
> system libraries (I'm working on icu and sqlite). This will require even
> more testing on Gentoo side, because using system libraries is a
> scenario that upstream's QA _never_ tests.
I see...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
On 08/12/2010 08:23 PM, Thilo Bangert wrote:
> its a small and neat piece of code. for anybody looking at deploying
Why isn't already an official project ^^?
It looks quite what we need =P
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
it isn't that hard even if IMHO it should be
declared by env var.
lu
PS: what about the user defined plugin dir (yes, it does exist)?
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
s more intuitive for people. Also,
> nteresting question would be whether to enable the flag by default an in
> which profiles (desktop?).
vpx -> you use libvpx
vp8 -> you want vp8
as for decoding ffmpeg is already a provider so application using it
won't need additional useflag IMHO
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
resolve this issue in case ChangeLog's
> will be generated from git log and until somebody suggests how to edit
> ChangeLogs generated from git I think have to keep ChangeLogs in
> gentoo-x86.
>
We could abuse git-note
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
/out calling eselect opengl that way first.
The discussion about how to handle two parallel merge in a safer way
seems interesting though.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
emerge more reliable.
I wonder if that case shouldn't be handled better with an huge ewarn so
people concerned would really run it in a benchmark environment, alone.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
probably instead), poppler-qt3, poppler-qt4 and
> poppler-utils.
If we could manage to convince poppler upstream that would be nice to
actually provide bindings packages aside a core one...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
ely need for either a better mail client
and/or other ways to be more responsive.
I think either Patrick or Tomáš could be a good asset for the council in
my place. Hopefully in the mean time I'll focus on fixing what make me
being slackered out of council and reply this late to your nominati
ds
could fit.
>
> [1] http://www.openfabrics.org
> [2] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git
>
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
use absolute majority even if it is more strict.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
he past days even if it wasn't
actual code =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Any objections or questions?
I think it's a good idea =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Nirbheek Chauhan wrote:
> I would like to kick-start the nominations by nominating Mart Raudsepp
> (leio), Petteri Räty (betelgeuse), and Luca Barbato (lu_zero) [all of
> them are CCed]
Patrick Lauer wrote:
> * lu_zero, because he's done a good job and brings in his own idea
Alexey Shvetsov wrote:
its realy a good idea to make targets for qemu selectable =) since not all
targets work all time at the same condition.
By tomorrow I'm going to push the use_expand changes and the unified
qemu ebuild.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gento
eting.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Luca Barbato wrote:
Duncan wrote:
Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe?
Right, anyway either one or two vars, anybody has a strong feeling
towards one of them or against any of them?
QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS, that's it.
-USE_E
Duncan wrote:
Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe?
Right, anyway either one or two vars, anybody has a strong feeling
towards one of them or against any of them?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org
We have a proposed unified qemu ebuild[1] in bugzilla that would let
users have a per-target granularity thanks to Xake.
I'm not sure if would be better have QEMU_TARGETS or separated
USER_TARGETS and SOFTMMU_TARGETS.
[1]http://bugs.gentoo.org/show_bug.cgi?id=267883
--
Luca Barbato
G
ng to get done, or you
don't, in which case there's no point to branches, and any migration
can be done using a simple tag.
I'd like you to rethink your statement and then come again.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
d take too much.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
x all 'pkg fails tests' bugs in bugzilla first.
And the fact some testsuites in system and commonly used libs take from
10x to 100x the buildtime to run.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
201 - 300 of 758 matches
Mail list logo
