that years ago, except it was "well you can't change
global scope behaviour for EAPIs, but just how much more flexibility
than that is needed?".
Given that the fixed header gives you ALL the flexibility. You may give
provision to consider the next bytes as any kind of serializa
e cache in such format will make portage ignore any
future change.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ryan Hill wrote:
some other random ideas i've seen tossed around:
- #!/bin/env eapi-parser
- split EAPI into EAPI and some separate counter which would only be
incremented on uncompatible changes to the ebuild format
- change .ebuild to .eb
- waffles (sorry, lunchtime)
Yummy!
--
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato wrote:
You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound. On top of that, you're
introducing a whole bunch of disk seeks in what's otherwise a nice
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 04:04:46 +0100
Luca Barbato wrote:
given that the simplest thing is hacking ebuild.sh and extract eapi
with a simple C program (you can use pcre or ragel if you want)
exactly before the ebuild source:
That you're bringing ebuild.sh into this
tting the eapi before sourcing.
real1m10.636s
user0m16.941s
sys 0m0.368s
cold cache, no metadata available
real6m23.106s
user3m32.141s
sys 1m50.855s
with eapitool
real6m26.564s
user3m31.853s
sys 1m50.511s
I'd rather see more people backing their ideas
Thomas Anderson wrote:
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
Yes, it will warn noisily. This is unacceptable, since stable users
will have months and months of noise when new rules come along.
"unacceptable"...
as in "it's ugly to see"...
much had been said probably
because glep-54 has impact to a lesser number of people and thus is less
interesting than the all encompassing glep-55.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
them.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ciaran McCreesh wrote:
On Thu, 26 Feb 2009 20:34:07 +0100
Luca Barbato wrote:
I'm still waiting for you to answer this:
Be specific. Explain how this works when, say, 0.34.4 is current, you
have a 0.34.5_live and 0.34.5 comes out.
being live working as substitute for 0.34.5_preN (
Ciaran McCreesh wrote:
On Thu, 26 Feb 2009 21:40:26 +0100
Luca Barbato wrote:
Be specific. Explain how this works when, say, 0.34.4 is current,
you have a 0.34.5_live and 0.34.5 comes out.
being live working as substitute for 0.34.5_preN (_live) component
the appearance of 0.34.5 will be
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
d take too much.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
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
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
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
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
eting.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
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
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
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
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
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
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
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 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
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 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
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 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/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/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/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/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: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
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
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
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
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
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
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
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
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
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
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
- --
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
is _really_ annoying for
qemu-chroots)
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
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
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.
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
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
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
On 07/27/2012 07:24 PM, Mike Frysinger wrote:
> yes, and i'm waiting on the POSIX group to formalize C.UTF-8. that's the
> only
> real option in my mind for making unicode the default. any other
> amalgamations of various locales is ugly as sin.
When they meet? I'd be fine with a pre-release
On 08/07/2012 09:00 PM, Olivier Crête wrote:
> I expect that in the not so long term, systemd will become an essential
> user-space component of desktop Linux, just like crond, syslog, dbus,
> udev or glibc. Sharing that code just makes sense, that allows
As in completely optional and easily repla
On 08/08/2012 04:53 PM, Michał Górny wrote:
> Yes, and please remove all the occurrences of 'GNU' because I don't
> like it.
We have people working on a clang/freebsd gentoo, you might help them
and use that. It sort of works fine.
For a project Flameeyes replaced most of system using smaller
alt
On 08/07/2012 05:00 AM, hero...@gentoo.org wrote:
> Hi,
>
> "Andreas K. Huettel" writes:
>
>> # Andreas K. Huettel (7 Aug 2012)
>> # Many display bugs and compatibility problems, does not build with
>> cups-1.6.
>> # Upstream is dead. There's no real way to support this anymore. Masked for
>>
On 07/18/2012 08:27 PM, Michał Górny wrote:
> I don't think we should give more support to building a system from
> a statically linked rescue suite tool.
For people wanting to shave some seconds from their boot openrc using
busybox is quite handy and should be used as default IMHO.
lu
On 08/09/2012 10:57 AM, Michał Górny wrote:
> No. I meant to have 'GNU' tools with 'GNU' stripped. Isn't that what
> the whole discussion is about? Changing names of tools just for
> someone's liking?
No, we are discussing about an upstream merging two unrelated projects
assuring users that nothin
On 08/09/2012 12:01 PM, Michał Górny wrote:
> On Thu, 09 Aug 2012 11:20:52 +0200
> Luca Barbato wrote:
>
>> On 08/09/2012 10:57 AM, Michał Górny wrote:
>>> No. I meant to have 'GNU' tools with 'GNU' stripped. Isn't that what
>>> the w
On 08/09/2012 04:02 PM, Peter Stuge wrote:
> Luca Barbato wrote:
>> Repeat after me: having your first process require anything more
>> than libc is stupid and dangerous.
>
> Why do you say?
Because libc supposedly should be stable, other libraries are a bit more
prone t
On 08/09/2012 09:43 PM, Michał Górny wrote:
> On Thu, 09 Aug 2012 10:42:15 +0200
> Luca Barbato wrote:
>
>> Repeat after me: having your first process require anything more than
>> libc is stupid and dangerous.
>
> But you are aware that glibc is probably much, much
On 08/10/2012 09:43 AM, Michał Górny wrote:
> vdr is a first example which comes to my mind. They workaround program
> configuration limitations and the init.d scripts become a complex
> extra-configuration parser + plugin loader. Well, another thing here is
> that upstream AFAIK is not willing to
On 8/12/12 6:10 PM, Jason A. Donenfeld wrote:
The gods heard your call, and have replied:
Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.
-- Lennart [1]
[1] http://lists.fre
On 08/14/2012 09:14 PM, Peter Stuge wrote:
> But it means nothing for someone who wants to open a box, switch on
> the power, and go online to $socialmediasite or $emailprovider.
Sabayon does a decent job for them.
lu
On 8/18/12 5:31 AM, Mike Frysinger wrote:
i'll probably land it later this weekend/monday.
Would be nice having a list of bugs open so people might have a look and
see if there is something big left.
boost and gnutls seem big enough already to spend some time to get those
fixed before unlea
On 08/28/2012 05:35 PM, Sylvain Alain wrote:
> Hi everyone, I don't want to start a flamewar on that subject, but I would
> like to know if there's any official position about the current situation.
udev might or might not eventually get forked to avoid systemd
borg-approach.
mdev works fine for
On 09/10/2012 03:55 AM, Doug Goldstein wrote:
> Hey all,
>
> Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to
> app-emulation/qemu at some point this week. The app-emulation/qemu
> ebuilds will effectively die and be replaced by the
> app-emulation/qemu-kvm ebuilds. I've broug
On 9/10/12 11:05 PM, William Hubbs wrote:
On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote:
On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote:
In researching this program, I have found that it and ifplugd, which is
the alternative, have been unmaintained for years. Also Debian
On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
I like the current syntax.
lu
On 09/03/2012 10:54 PM, Maciej Mrozowski wrote:
> On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
>> Is there a reason not to support static-libs in an ebuild if the package
>> supports it?
>>
>> It seems some developers don't care about this option. What's the gentoo
>> policy on this? Isn't
On 09/21/2012 06:06 PM, Zac Medico wrote:
> On 09/20/2012 10:34 AM, Ambroz Bizjak wrote:
>> The question now is, how should this method for checking
>> --crosscompile be implemented? In particular, we have two options:
>>
>> - Environment variable. If so, how to call it? Possible names are
>> CROSS
On 09/22/2012 05:25 PM, hasufell wrote:
> add_library(foostatic STATIC foo.cpp foo.h)
> set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo)
> add_library(foo SHARED foo.cpp foo.h)
Looks a bit kludgy but should work well as a macro, willing to contact
upstream and/or ask cmake devs to incl
On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
I like the current one your proposal seems quite a problem for a large
deal of usecases.
> 1. It is not really human-friendl
No.
Alex Alexander wrote:
>On Sep 22, 2012 8:25 PM, "Michał Górny" wrote:
>>
>> On Sat, 22 Sep 2012 20:11:48 +0300
>> Alex Alexander wrote:
>>
>> > On Sep 22, 2012 7:38 PM, "Michał Górny" wrote:
>> > >
>> > > emerge 'foo >= 1.1' 'bar < 1.0'?
>> > > emerge foo '>=' 1.1 bar '<' 1.0?
>> >
>> > How is
"Michał Górny" wrote:
>It is a simple eclass using autotools out-of-source builds to build
>packages for multiple ABIs when multilib is supported.
>
>Use case: xorg packages, ask Matt.
>---
>gx86/eclass/autotools-multilib.eclass | 72
>+++
> 1 file changed, 72 inser
201 - 300 of 758 matches
Mail list logo
