On Mon, 21 Jan 2013 13:27:18 +0800
Ben de Groot wrote:
> On 21 January 2013 12:16, Peter Stuge wrote:
> > Panagiotis Christopoulos wrote:
> >> I don't build server machines every day, others do and it would be
> >> much appreciated if they could respond here.
> >
> > I build catalyst stage4s. An
On Sun, 2013-01-20 at 18:03 +0100, Chí-Thanh Christopher Nguyễn wrote:
> We can either set it in the base profile, then there is no need for
> IUSE="+dri". Or we can set it in every single ebuild that has the dri
> flag. I prefer the former because it reduces our maintenance burden.
You make it s
Pozdrawiam/Best regards
Tomasz Kondzioła
Dnia 20 sty 2013 o godz. 10:26 Pacho Ramos napisał(a):
> Looks like no package is included in it, I think we should drop that
> herd then
>
> Do you agree?
>
On Sun, 20 Jan 2013 21:56:35 + (UTC)
"Christian Faulhammer (fauli)" wrote:
> fauli 13/01/20 21:56:35
>
> Modified: ChangeLog
> Removed: claws-mail-rssyl-0.34.ebuild
> Log:
> clean up
I'm guessing you meant to remove the old 0.33 ebuild, not the newly s
On 21 January 2013 12:16, Peter Stuge wrote:
> Panagiotis Christopoulos wrote:
>> I don't build server machines every day, others do and it would be
>> much appreciated if they could respond here.
>
> I build catalyst stage4s. Any default profiles are kindof pointless
> for me; I have USE=-* and t
On 21 January 2013 10:42, Duncan <1i5t5.dun...@cox.net> wrote:
> So that's what I (and others, but less explicitly) propose, leaving
> USE=dri where it is in the old and soon-to-be-deprecated 10.x profiles so
> nobody gets broken, while in the new 13.0 profiles, USE=dri is moved from
> base to desk
Doug Goldstein wrote:
> we go through the effort to ALLOW users to build their own binary
> blobs but is it really necessary as part of our culture?
I don't think that question can be answered?
The way I see it either someone maintains those packages, or not.
I'd be sad to see them go, but am no
On Sun, Jan 20, 2013 at 10:45 PM, Peter Stuge wrote:
> Doug Goldstein wrote:
>> sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios,
>> sys-firmware/vgabios
> ..
>> So basically, how important is it to keep supporting these separately
>> buildable blobs knowing that it might slow the rel
Doug Goldstein wrote:
> sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios,
> sys-firmware/vgabios
..
> So basically, how important is it to keep supporting these separately
> buildable blobs knowing that it might slow the release of QEMU within
> our own tree.
Each of those sys-firmwar
On 01/20/2013 4:23 AM, Pacho Ramos wrote:
> Looks like no package is included in it, I think we should drop that
> herd then
>
> Do you agree?
Yeah, I am the only maintainer of mips-sources anyways. Any problems with
that package should go to me or the mips herd direct.
--
Joshua Kinard
Gentoo
Panagiotis Christopoulos wrote:
> I don't build server machines every day, others do and it would be
> much appreciated if they could respond here.
I build catalyst stage4s. Any default profiles are kindof pointless
for me; I have USE=-* and the flags that I want.
Anything else seems a bit too r
On Sun, Jan 20, 2013 at 6:28 PM, Peter Stuge wrote:
> Alec Warner wrote:
> [..removed 25 lines of quoted text which I had already read..]
>> The primary complaint was the fact that there is too much email.
>
> Many emails are not neccessarily a problem if only they have high
> signal-to-noise rati
Ciaran McCreesh posted on Sun, 20 Jan 2013 22:00:20 + as excerpted:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sun, 20 Jan 2013 16:59:24 -0500 "Rick \"Zero_Chaos\" Farina"
> wrote:
>> chithanh, maybe you can explain to everyone why USE=dri is needed for
>> base profile. You se
Alec Warner wrote:
[..removed 25 lines of quoted text which I had already read..]
> The primary complaint was the fact that there is too much email.
Many emails are not neccessarily a problem if only they have high
signal-to-noise ratio.
I have *never* seen so competent people output so incompete
On Sun, Jan 20, 2013 at 3:01 PM, Thomas Sachau wrote:
> So you want to re-implement multilib-portage in an eclass without the
> additional benefits a package-manager level implementation has?
I really wish you'd just make the PMS diff and get your stuff
implemented. How long has it been?
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2013-01-20 23h59 UTC.
Removals:
media-gfx/opencolorio 2013-01-16 05:57:48 pinkbyte
dev-util/nvidia-cuda-npp2013-01-17 10:14:37 jlec
virtual/pcmcia
> "AWS" == Aaron W Swenson writes:
AWS> That's why there's a base desktop profile and desktop/{gnome,kde}
AWS> profiles.
/usr/portage/profiles/targets/desktop/make.defaults still has too much
crap for a real base profile for a box which (might) run X or wl.
Also, I suspect the things dri br
Thomas Sachau schrieb:
> So you want to re-implement multilib-portage in an eclass without the
> additional benefits a
package-manager level implementation has?
Once the package-manager level implementation becomes available in g-x86
then we can switch to it. If something in the proposed changes
Gilles Dartiguelongue schrieb:
> Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit :
>> Michał Górny schrieb:
>>> Hello,
>>>
>>> There is a fair interest in multilib and while still early, it would be
>>> a good moment to decide on how USE flags to use for it.
>>>
>>> The current attemp
On Sun, Jan 20, 2013 at 4:59 PM, Rick "Zero_Chaos" Farina
wrote:
>> If we have it as IUSE default, it can be removed from the profiles
>> entirely. Having it only in the desktop profile is not good in any
>> scenario I can think of.
>
> chithanh, maybe you can explain to everyone why USE=dri is ne
Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit :
> Michał Górny schrieb:
> > Hello,
> >
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> >
> > The current attempts are mostly using USE=multilib
On Mon, 21 Jan 2013 00:01:05 +0100
Thomas Sachau wrote:
> Michał Górny schrieb:
> > Hello,
> >
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> >
> > The current attempts are mostly using USE=multilib which
Sergei Trofimovich schrieb:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny wrote:
>
>> Hello,
>>
>> There is a fair interest in multilib and while still early, it would be
>> a good moment to decide on how USE flags to use for it.
>>
>> The current attempts are mostly using USE=multilib whic
Michał Górny schrieb:
> Hello,
>
> There is a fair interest in multilib and while still early, it would be
> a good moment to decide on how USE flags to use for it.
>
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor. What I would go for is a clear var
On Mon, 21 Jan 2013 01:05:56 +0300
Sergei Trofimovich wrote:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny wrote:
>
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> >
> > The current attempts are mos
On Sun, 20 Jan 2013 20:11:31 +0100
Michał Górny wrote:
> Hello,
>
> There is a fair interest in multilib and while still early, it would be
> a good moment to decide on how USE flags to use for it.
>
> The current attempts are mostly using USE=multilib which is not really
> expressive and poor.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 20 Jan 2013 16:59:24 -0500
"Rick \"Zero_Chaos\" Farina" wrote:
> chithanh, maybe you can explain to everyone why USE=dri is needed for
> base profile. You seem to be the most knowledgable here, can you
> cite a specific example for how/why a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> If we have it as IUSE default, it can be removed from the profiles
> entirely. Having it only in the desktop profile is not good in any
> scenario I can think of.
>
chithanh, maybe you can explain to everyone why USE=dri is needed for
base profile.
On Sun, Jan 20, 2013 at 9:32 AM, Andreas K. Huettel
wrote:
> Am Sonntag, 20. Januar 2013, 10:39:58 schrieb Rich Freeman:
>>
>> What's the point? I don't think democracy is the best way to handle
>> these sorts of things.
>
> LOL. Yeah, but haven't we tried to give ourselves rules that at least re
On 01/20/2013 05:30 AM, Pacho Ramos wrote:
> Due swegener focusing in less packages until he has more time:
> x11-misc/x11vnc -> maybe net-libs/libvncserver could be interested in
> this
>
Yeah, I picked it up. As always, anyone is free to co-maintain if they like.
signature.asc
Description: O
Hello,
There is a fair interest in multilib and while still early, it would be
a good moment to decide on how USE flags to use for it.
The current attempts are mostly using USE=multilib which is not really
expressive and poor. What I would go for is a clear variable specifying
which targets packa
On 17:52 Sun 20 Jan , Andreas K. Huettel wrote:
>
> >
> > *the thing with USE flags is a big change.
>
> You're kidding, right?
>
> If we seriously start doing that, we'll either get slapped with "dont bother
> us with that" by the council members, or nobody wants to run for council
> an
On 1/20/13 1:46 AM, Luca Barbato wrote:
> On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote:
>> have a way to more simply exclude code that requires CODEC_ID_OPUS.
>
> Exclude in chrome or in libavcodec?
>
> The latter is a matter of adding --disable-decoder=opus and/or not
> --enable-libopus in the c
Ben de Groot wrote:
> On 20 January 2013 21:35, Dale wrote:
>> Same here. I have had to re-emerge qt packages several times myself.
>> It seems that when I do, I have to do them all one at a time too.
> In which case you're better off with something like:
>emerge -a1 `eix --only-names -IC qt`
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2013 04:34 AM, Pacho Ramos wrote:
> If we agree on keeping this herd instead of trying to find one
> maintainer per package, somebody should join. Otherwise I will
> move their packages to maintainer-needed in a week
>
> Thanks
>
I will joi
Am Sonntag, 20. Januar 2013, 10:39:58 schrieb Rich Freeman:
>
> What's the point? I don't think democracy is the best way to handle
> these sorts of things.
LOL. Yeah, but haven't we tried to give ourselves rules that at least resemble
it?
If I wanted to find out expert opinions and act on tha
Mike Frysinger schrieb:
> On Sunday 20 January 2013 10:54:55 Chí-Thanh Christopher Nguyễn wrote:
>> Yes, I mentioned this in another post already. We can use EAPI=1 IUSE
>> defaults instead. But this will not change any systems so I fail to
>> see the point behind this. This will only move clutter
Andreas K. Huettel posted on Sun, 20 Jan 2013 17:52:40 +0100 as excerpted:
>> *the thing with USE flags is a big change.
>
> You're kidding, right?
>
> If we seriously start doing that, we'll either get slapped with "dont
> bother us with that" by the council members, or nobody wants to run for
On Sunday 20 January 2013 10:54:55 Chí-Thanh Christopher Nguyễn wrote:
> Ben de Groot schrieb:
> > On 20 January 2013 23:22, Chí-Thanh Christopher Nguyễn wrote:
> >> Andreas K. Huettel schrieb:
> * move setting USE=dri from default/linux/make.defaults to
> targets/desktop/make.defaults
>
Ben de Groot posted on Sun, 20 Jan 2013 21:59:49 +0800 as excerpted:
> On 20 January 2013 21:35, Dale wrote:
>> Same here. I have had to re-emerge qt packages several times myself.
>> It seems that when I do, I have to do them all one at a time too.
>
> In which case you're better off with some
On Sun, 20 Jan 2013 16:20:42 +0100
"Andreas K. Huettel" wrote:
> I would like to suggest and ask your opinion on a simple way of getting the
> developers' collective opinion: cast votes with a shell script on our
> favourite shell server, which is then displayed on a web page (either only as
>
Brian Dolbec schrieb:
> But, doesn't your point above very strongly suggest that IUSE=+dri
> should be set on those pkgs irregardless of where/if the dri USE flag
> should be set in some profile.
We can either set it in the base profile, then there is no need for
IUSE="+dri". Or we can set it in e
>
> *the thing with USE flags is a big change.
You're kidding, right?
If we seriously start doing that, we'll either get slapped with "dont bother
us with that" by the council members, or nobody wants to run for council
anymore.
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gento
On Sun, Jan 20, 2013 at 7:39 AM, Rich Freeman wrote:
> On Sun, Jan 20, 2013 at 10:20 AM, Andreas K. Huettel
> wrote:
>> So, a thread like "Should we enable useflag Z by default" would then include
>> "Please discuss here, vote on ..." with a link to the count page (updated via
>> cron every 1h).
On Sun, 2013-01-20 at 10:30 -0500, Rich Freeman wrote:
> It seemed like most who were knowledgeable suggested disabling dri was
> a bad move. I think it is required for kernel-modesetting among other
> things. Why would somebody install xorg and not use dri?
>
> Rich
>
Since I'm not so knowle
Ben de Groot schrieb:
> On 20 January 2013 23:22, Chí-Thanh Christopher Nguyễn
> wrote:
>> Andreas K. Huettel schrieb:
* move setting USE=dri from default/linux/make.defaults to
targets/desktop/make.defaults
>> I must say that I am unhappy about this. The packages in question should
>> n
On 20 January 2013 23:22, Chí-Thanh Christopher Nguyễn
wrote:
> Andreas K. Huettel schrieb:
>>> * move setting USE=dri from default/linux/make.defaults to
>>> targets/desktop/make.defaults
>
> I must say that I am unhappy about this. The packages in question should
> not be built with dri disabled
On 16:20 Sun 20 Jan , Andreas K. Huettel wrote:
> I would like to suggest and ask your opinion on a simple way of getting the
> developers' collective opinion: cast votes with a shell script on our
> favourite shell server, which is then displayed on a web page (either only as
> stats, or wi
On Sun, Jan 20, 2013 at 10:20 AM, Andreas K. Huettel
wrote:
> So, a thread like "Should we enable useflag Z by default" would then include
> "Please discuss here, vote on ..." with a link to the count page (updated via
> cron every 1h). On login to ..., a message similar to the "open elections
> m
On Sun, Jan 20, 2013 at 10:22 AM, Chí-Thanh Christopher Nguyễn
wrote:
> Andreas K. Huettel schrieb:
>>
>> Summarizing this thread:
>>
>>> * move setting USE=dri from default/linux/make.defaults to
>>> targets/desktop/make.defaults
>>
>> +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang
>> c
Chí-Thanh Christopher Nguyễn schrieb:
>>> * move setting USE=dri from default/linux/make.defaults to
>>> targets/desktop/make.defaults
>> +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang
>> chitanh, titanofold, zerochaos wants to keep this in default profile
>>
>> ===> done because it's sti
Andreas K. Huettel schrieb:
>
> Summarizing this thread:
>
>> * move setting USE=dri from default/linux/make.defaults to
>> targets/desktop/make.defaults
>
> +1 by dilfridge, djc, kensington, vapier, pesa, hwoarang
> chitanh, titanofold, zerochaos wants to keep this in default profile
>
> ===> done
Hi everyone,
we've now had a few cases where mails were sent to this list to get a general
opinion whether
* some change should be implemented
* some feature is still needed
* ...
While discussing this on a mailing list is nice, there are some disadvantages:
* Threads are easily hijacked, an
On 23:47 Sat 19 Jan , Walter Dnes wrote:
> ...
> On a lark, I once tried the "default/linux/x86/10.0" profile for a
> re-install on my netbook without "-*". I soon ended up with more "-"
> entries in make.conf and package.use, than I have add-on entries when
> using "-*". And I was only ha
On 20 January 2013 09:10, Pacho Ramos wrote:
> Only one package is inside it:
> net-misc/capi4hylafax
>
> It should probably be moved to kingtaco (if he is still interested...
> are you?) or maintainer-needed until any other steps up as maintainer.
>
> What do you think about removing this herd?
# Hans de Graaff (20 Jan 2013) Mask
# dev-lang/ruby-enterprise for removal, bug 453178. The current
# versions have minor security issues, the latest versions are masked
# and don't work, and upstream announced end-of-life almost a year
# ago. Ruby 1.9 has almost all of the benefits of REE, so th
On 01/20/2013 07:45 AM, Michael Palimaka wrote:
On 20/01/2013 20:23, Pacho Ramos wrote:
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
+1
Yes drop it. I see no need.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bl
On 20 January 2013 21:35, Dale wrote:
> Same here. I have had to re-emerge qt packages several times myself.
> It seems that when I do, I have to do them all one at a time too.
In which case you're better off with something like:
emerge -a1 `eix --only-names -IC qt`
--
Cheers,
Ben | yngwin
Summarizing this thread:
> * move setting USE=dri from default/linux/make.defaults to
> targets/desktop/make.defaults
+1 by dilfridge, djc, kensington, vapier, pesa, hwoarang
chitanh, titanofold, zerochaos wants to keep this in default profile
===> done because it's still 2:1 (see remark at bot
On 01/20/13 10:32, Pacho Ramos wrote:
> Looks like no package is included in it, I think we should drop
> that herd then
>
> Do you agree?
>
>
+1
Duncan wrote:
> Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted:
>
>> On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote:
>>> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the
>>> hyphenated qt-pkg names. As a user, most of the time I DO only re
On 20/01/2013 20:10, Pacho Ramos wrote:
Only one package is inside it:
net-misc/capi4hylafax
It should probably be moved to kingtaco (if he is still interested...
are you?) or maintainer-needed until any other steps up as maintainer.
What do you think about removing this herd?
+1
On 20/01/2013 20:21, Pacho Ramos wrote:
Looks like it's still listed in herds.xml even being empty and with no
packages inside it. Probably it's time to safely remove it completely.
OK with that?
Best regards
+1
On 20/01/2013 21:34, Pacho Ramos wrote:
Feel free to join for taking care of its packages. If nobody joins, will
move that packages to maintainer-needed in a week
Thanks
Hi,
I will join this herd.
People who are interested in specific packages should still feel free to
add themselves to/ta
On 20/01/2013 20:26, Pacho Ramos wrote:
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
+1
On 20/01/2013 20:32, Pacho Ramos wrote:
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
+1
On 20/01/2013 20:23, Pacho Ramos wrote:
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
+1
On 20/01/2013 20:19, Pacho Ramos wrote:
Hello
Looks like no package is inside this herd, I think would be safe to drop
it. What do you think?
Thanks
+1
El jue, 17-01-2013 a las 08:31 -0800, Zac Medico escribió:
> On 01/17/2013 08:00 AM, Pacho Ramos wrote:
> > Another try ;)
>
> Looks good to me.
+ 20 Jan 2013; Pacho Ramos +readme.gentoo.eclass:
+ Finally commit readme.gentoo.eclass to create a README.gentoo doc
file
+ recording tips shown vi
...and use if for src_configure().
---
gx86/eclass/autotools-multilib.eclass | 41 +--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index fe6372d..3aa5f27 100644
--- a/g
On 16/01/13 20:20, Luca Barbato wrote:
> Again please do not mix qemu system emulation with qemu userspace
> wrappers. They have different needs and requirements.
qemu-user-1.2.2 in portage.
I'll drop the mask as said before.
We can discuss on irc or here on what's the best strategy today anytim
Feel free to join for taking care of its packages. If nobody joins, will
move that packages to maintainer-needed in a week
Thanks
signature.asc
Description: This is a digitally signed message part
Due swegener focusing in less packages until he has more time:
x11-misc/x11vnc -> maybe net-libs/libvncserver could be interested in
this
signature.asc
Description: This is a digitally signed message part
On 1/20/13 11:09 AM, Pacho Ramos wrote:
> dev-python/pycuda
Sci is taking this.
signature.asc
Description: OpenPGP digital signature
dev-python/pycuda
media-gfx/bootsplash-themes
media-gfx/fbgrab
media-gfx/fbida
media-gfx/fblogo
media-gfx/quat
media-gfx/splash-themes-gentoo
media-gfx/splashutils
sys-apps/v86d
Thanks for taking care of them
signature.asc
Description: This is a digitally signed message part
Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted:
> On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote:
>> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the
>> hyphenated qt-pkg names. As a user, most of the time I DO only refer
>> to the packa
On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote:
> have a way to more simply exclude code that requires CODEC_ID_OPUS.
Exclude in chrome or in libavcodec?
The latter is a matter of adding --disable-decoder=opus and/or not
--enable-libopus in the configure.
lu
On 20 January 2013 17:21, Pacho Ramos wrote:
> Looks like it's still listed in herds.xml even being empty and with no
> packages inside it. Probably it's time to safely remove it completely.
>
> OK with that?
> Best regards
Yes please
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project
If we agree on keeping this herd instead of trying to find one
maintainer per package, somebody should join. Otherwise I will move
their packages to maintainer-needed in a week
Thanks
signature.asc
Description: This is a digitally signed message part
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
signature.asc
Description: This is a digitally signed message part
On 20/01/13 10:26, Pacho Ramos wrote:
> Looks like no package is included in it, I think we should drop that
> herd then
>
> Do you agree?
>
Agreed.
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
signature.asc
Description: This is a digitally signed message part
Looks like no package is included in it, I think we should drop that
herd then
Do you agree?
signature.asc
Description: This is a digitally signed message part
20.01.2013 13:10, Pacho Ramos wrote:
> Only one package is inside it:
> net-misc/capi4hylafax
Personally, i think that keeping herd only for one package(if it's not
god-damn-hard-to-maintain) is a bit overkill.
--
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead
On 20 January 2013 17:10, Pacho Ramos wrote:
> Only one package is inside it:
> net-misc/capi4hylafax
>
> It should probably be moved to kingtaco (if he is still interested...
> are you?) or maintainer-needed until any other steps up as maintainer.
>
> What do you think about removing this herd?
Looks like it's still listed in herds.xml even being empty and with no
packages inside it. Probably it's time to safely remove it completely.
OK with that?
Best regards
signature.asc
Description: This is a digitally signed message part
On 20 January 2013 17:09, Nikos Chantziaras wrote:
> On 20/01/13 10:39, Ben de Groot wrote:
>> There is no need for multiple qt categories. We want everything that
>> the upstream Qt Project considers to be part of the Qt Framework to be
>> in one category. Besides that there are only a handful of
Hello
Looks like no package is inside this herd, I think would be safe to drop
it. What do you think?
Thanks
signature.asc
Description: This is a digitally signed message part
Only one package is inside it:
net-misc/capi4hylafax
It should probably be moved to kingtaco (if he is still interested...
are you?) or maintainer-needed until any other steps up as maintainer.
What do you think about removing this herd?
signature.asc
Description: This is a digitally signed mes
On 20/01/13 10:39, Ben de Groot wrote:
On 20 January 2013 15:59, Nikos Chantziaras wrote:
Just a user with a suggestion here. Since portage already has kde-base and
kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.)
Qt5 will have standard core modules and extensions.
On 20 January 2013 15:59, Nikos Chantziaras wrote:
> Just a user with a suggestion here. Since portage already has kde-base and
> kde-misc, why not qt-base and qt-misc (and qt-something is the need arises.)
> Qt5 will have standard core modules and extensions. qt-base and qt-misc
> look like the
On 20 January 2013 06:59, Francesco Riosa wrote:
> 2013/1/19 Michał Górny
>> Just a completely different idea -- how about putting those libraries
>> into different categories appropriate to the topic? We have a bunch of
>> categories like dev-libs, media-libs, etc. -- and I wonder how many of
>>
On 20 January 2013 05:03, Philip Webb wrote:
> 130119 Ben de Groot wrote:
>> On 19 January 2013 21:46, Patrick Lauer wrote:
>>> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it?
>> These are libraries and applications
>> that are used by developers of end-user applications.
On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote:
> * In general, yes, I'm in favor of a dedicated qt-* category, but...
Good :-)
> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the
> hyphenated qt-pkg names. As a user, most of the time I DO only refer to
> the
On 19 January 2013 23:38, Michael Weber wrote:
> We have a fixed number of exact 2 tags (foo and bar),
> This limitation has proven it's usability in the past of Gentoo, but
> there are reasons to break it up (Like making up funny points like regex
> and it has always been this way). foo-bar-baz m
On 17/01/13 15:57, Ben de Groot wrote:
Presently we already have a good number of split qt-* library packages
in x11-libs. With the arrival of Qt5 upstream has gone a lot further
in modularization, so we expect the number of packages to grow much
more. We, the Gentoo Qt team, are of the opinion t
96 matches
Mail list logo
