Re: [gentoo-dev] USE flags dri, cups, pppd
On 19 January 2013 04:49, Andreas K. Huettel dilfri...@gentoo.org wrote: During the server profile discussion, it became clear that we could clean up the base profiles a bit. This is unrelated to the profile versions, as the change would affect all versions (well, at least without bigger changes). What I suggested and what djc and kensington supported was: * move setting USE=dri and USE=cups from default/linux/make.defaults to targets/desktop/make.defaults As said by others, dri can stay in the default base profile, as it only affects things when X is specifically installed, in which case dri would be a good default to have. I'm not sure whether we need to keep cups at all. I haven't printed anything from my personal PC or laptop in years. And I'm sure I'm not the only one. So I'm voting for dropping cups useflag from all profiles. If some people think it is necessary, maybe it can be moved up to the more complete desktop profiles for gnome and kde. For a simple non-gnome/kde desktop, I see no need for cups to be enabled by default at all. Since this may be an unexpected change for some, let's only drop it from the new 13.0 profiles. * remove setting USE=pppd in default/linux/make.defaults, instead have it default to on in net-dialup/capi4k-utils (the only place where it is used) +1 -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] removing the server profiles...
On 19 January 2013 08:01, Christopher Head ch...@chead.ca wrote: I understand that enabling flags only affects packages if they’re installed. I’m just saying that, in my opinion, sane-but-minimal should have CUPS disabled because there are plenty of computers that would want LibreOffice and/or Chromium installed but not have a printer. They need not be servers if the target is simply sane-but-minimal. +1 People who do have printers can always enable it themselves. I don't see any reason for cups to be enabled by default, especially not on a minimal profile, and that includes the simple desktop profile. The kde and gnome profiles are expected to be more complete. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] removing the server profiles...
On Sat, Jan 19, 2013 at 3:26 AM, Ben de Groot yng...@gentoo.org wrote: People who do have printers can always enable it themselves. I don't see any reason for cups to be enabled by default, especially not on a minimal profile, and that includes the simple desktop profile. The kde and gnome profiles are expected to be more complete. Unless we plan on adding yet another profile for normal users I think this is really pushing it. I'm not sure I buy disabling it on the default profile, let alone the desktop one. Yes, I'm sure some people don't own printers. However, that figure has to be fairly low. Yes, users who have printers can enable it, but those without printers can also disable it. I don't think I actually know anybody who owns a computer but not a printer. Frequency of use has to count for something here. Maybe we should have some kind of use-case to guide how we create each profile. I'm concerned that the default profile is going to turn into something that isn't actually useful for anybody. It will still be too heavy for people who are running embedded, it will be way to light for people who just want a computer that works, it won't have support for things people need on servers, and so on. If the default profile isn't actually intended to be used by anybody we can be up-front about that and then create a profile that actually can be used. For the desktop profile I think that it shouldn't pull in KDE/Gnome-related deps/features (which are REALLY heavy), but otherwise should be similar to what you'd get on any other desktop-oriented distro (debian, ubuntu, kubuntu, xubuntu, mint, arch, etc). That generally means that the packages that are installed should be fairly feature-complete, especially around things like multimedia, etc. Could you imagine ANY other desktop-oriented distro not having printer support by default? Rich
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot yng...@gentoo.org wrote: I'm not sure whether we need to keep cups at all. I haven't printed anything from my personal PC or laptop in years. And I'm sure I'm not the only one. Won't repeat my previous email, but this is the kind of situation where a popularity contest application would really help us. Maybe a forum poll? The suggestion that few people actually print anything ever really seems out of touch to me, but it could easily be cultural/generational/etc, and maybe I'm the one who is out of touch. Rich
Re: [gentoo-dev] removing the server profiles...
On 19 January 2013 18:26, Rich Freeman ri...@gentoo.org wrote: On Sat, Jan 19, 2013 at 3:26 AM, Ben de Groot yng...@gentoo.org wrote: People who do have printers can always enable it themselves. I don't see any reason for cups to be enabled by default, especially not on a minimal profile, and that includes the simple desktop profile. The kde and gnome profiles are expected to be more complete. Unless we plan on adding yet another profile for normal users I think this is really pushing it. I'm not sure I buy disabling it on the default profile, let alone the desktop one. I guess it comes down to either this, or the creation of a truly minimal profile, which quite a few people really want. Yes, I'm sure some people don't own printers. However, that figure has to be fairly low. I'm not so sure about that. The majority of my friends and colleagues don't own a printer. When we do need to print something, it would be for work, so we have it printed at work. Yes, users who have printers can enable it, but those without printers can also disable it. I don't think I actually know anybody who owns a computer but not a printer. Frequency of use has to count for something here. Indeed, and from what I see around me, that is fairly low. But this could be a cultural difference. Maybe we should have some kind of use-case to guide how we create each profile. I'm concerned that the default profile is going to turn into something that isn't actually useful for anybody. It will still be too heavy for people who are running embedded, it will be way to light for people who just want a computer that works, it won't have support for things people need on servers, and so on. If the default profile isn't actually intended to be used by anybody we can be up-front about that and then create a profile that actually can be used. I think the default should be minimal but useful. For the desktop profile I think that it shouldn't pull in KDE/Gnome-related deps/features (which are REALLY heavy), but otherwise should be similar to what you'd get on any other desktop-oriented distro (debian, ubuntu, kubuntu, xubuntu, mint, arch, etc). That generally means that the packages that are installed should be fairly feature-complete, especially around things like multimedia, etc. Could you imagine ANY other desktop-oriented distro not having printer support by default? Actually, that is what I would expect from the more basic oriented ones like Arch and Debian. Printer support should be an optional add-on, not part of the basic install. Maybe I'm too idealistic... -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] RFC: new qt category
On 17 January 2013 22:45, Diego Elio Pettenò flamee...@flameeyes.eu wrote: How many packages are we talking about? Especially if you don't want qwt to join there, I assume we're way below 50? If so I would vote nay to any new category at all, to be honest. Roughly 40 is the current estimate. This is above the median 32 per category in the current tree, if that means anything. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] RFC: new qt category
On Sat, Jan 19, 2013 at 11:56 AM, Ben de Groot yng...@gentoo.org wrote: The thing is you would practically never have to do this. Users install apps that have a number of qt modules as dependencies. These qt modules in turn cannot be updated individually (unless there is an ebuild revision bump), but will be included in a world update as a group. Beside the fact that yes, it happens sometimes that you want to rebuild only one of them, and doing 'emerge gui' is nasty enough, what about dbus? emerge dbus - which one did you mean now? Yes there's a category, but that's not a good reason to artificially make it more complicated. I'm pretty sure that if a consensus is to be found, it is that 'qt' as a category name, and dropping the 'qt-' prefix, is not seen with favour by other people beside you and whoever you discussed this with. I would thus ask you to drop that idea. Some of us, including me, are also wondering why a separate category is needed — while you might be over the median, it doesn't mean it's that much more compelling — indeed my feeling is that it would be an useless small category, especially if you only want to keep the core and it won't ever grow. But I won't stop you if it's going to be qt-core/qt-core as package name.
Re: [gentoo-dev] RFC: new qt category
On Sat, Jan 19, 2013 at 7:43 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: Some of us, including me, are also wondering why a separate category is needed — while you might be over the median, it doesn't mean it's that much more compelling — indeed my feeling is that it would be an useless small category, especially if you only want to keep the core and it won't ever grow. But I won't stop you if it's going to be qt-core/qt-core as package name. I tend to agree on leaving qt in the package names themselves for the reasons that have been raised. I'm not sure that the category qt-core makes sense though. Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen for its own sake and we're just making senseless stuff up. qt-core just doesn't make sense if it applies to more than just qt-core. If the reason for the hyphen is to have some kind of major/minor category organization then it really makes sense to not create a new major category just for qt since we'll only have one category for it. x11-qt or dev-qt are probably the best fits with what is there now. If we want to create a new major category then maybe some kind of general category for large development toolkits would make sense, but I just don't see the demand. I do support the idea of a new category for qt though, if they really are going to have upwards of 40 packages. That would put x11-libs up to 180 packages, and qt would be 20% of them. Rich
Re: [gentoo-dev] RFC: new qt category
On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman ri...@gentoo.org wrote: Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen for its own sake and we're just making senseless stuff up. qt-core just doesn't make sense if it applies to more than just qt-core. I actually love x11-qt as an option.
Re: [gentoo-dev] RFC: new qt category
On 01/19/2013 09:39 PM, Diego Elio Pettenò wrote: On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman ri...@gentoo.org wrote: Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen for its own sake and we're just making senseless stuff up. qt-core just doesn't make sense if it applies to more than just qt-core. I actually love x11-qt as an option. That's silly, the x11 bit (qt-gui) is just one of the modules. You can have everything else installed without needing x11 at all ... Maybe lib-qt ? dev-qt sounds confusing to me too, what's dev about it?
Re: [gentoo-dev] RFC: new qt category
On Sat, Jan 19, 2013 at 8:46 AM, Patrick Lauer patr...@gentoo.org wrote: Maybe lib-qt ? dev-qt sounds confusing to me too, what's dev about it? I was thinking about that. A lib-misc, lib-x11, lib-qt, and so on organization actually makes more sense to me than what we're doing with libs in general right now. But, that is a bigger change. Unless we plan to have more categories under lib-* I'm not sure it makes sense to do that for qt alone. Rich
Re: [gentoo-dev] RFC: new qt category
On 19 January 2013 21:46, Patrick Lauer patr...@gentoo.org 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.
If there is too much opposition to a simple qt category (at least
there seems to be some quite vocal opposition), then dev-qt is in my
eyes the next best alternative. A third option we came up with is
qt-framework.
Somewhat comparable categories in the current tree are dev-dotnet and
gnustep-{base,libs}.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] RFC: new qt category
On 01/19/2013 03:14 PM, Ben de Groot wrote: On 19 January 2013 21:46, Patrick Lauer patr...@gentoo.org 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. And so is vim, which is used as editor, by devs. My initial reading of the posted line categories are foo[-]bar reminded me of some discussion with archlinux enthusiasts which find them stupid. It all boils down to: Do we want categories or not? Categories are nasty, I always fail on `emerge -av1 screen` which resolves to app-misc/screen and app-vim/screen. Besides the limitation, categorization creates structure, Does it belong to gnome or kde? is it an x11 app? is it an application or just an library? and so on .. 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 might be usefull, too. But it's plain redundacy to in insist on *qt*/qt-*. Either reject using an appropriate category and place it as misc-randoom/qt-* or use a category and strip the qt- prefix. I'm fine with qt/core, my preference would be lib-qt/core or lib/qt-core. But please don't double the qt. Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
[gentoo-dev] Re: RFC: new qt category
Ben de Groot posted on Sat, 19 Jan 2013 22:14:48 +0800 as excerpted:
On 19 January 2013 21:46, Patrick Lauer patr...@gentoo.org 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.
If there is too much opposition to a simple qt category (at least
there seems to be some quite vocal opposition), then dev-qt is in my
eyes the next best alternative. A third option we came up with is
qt-framework.
Somewhat comparable categories in the current tree are dev-dotnet and
gnustep-{base,libs}.
Despite my interest (kde user), I've stayed out of this until now, as I
figured there were enough others commenting and I didn't have anything
different to say, but...
* In general, yes, I'm in favor of a dedicated qt-* category, but...
*** (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 package name, and dropping the qt- from qt-core, qt-gui, etc, is WAYYY
too generic to be practical. I for one would be cursing the generic
names every time I had to deal with the package. (Tho it's a kde
upstream issue, the same applies to the application formerly known as
kcontrol, now the impossibly generic system-settings, and the former
ksysguard, now generically system-monitor. Anyone active on the kde
general or kde linux lists knows I simply refuse to use the generic
names.)
* (Less strongly.) Please keep the hyphenated category name scheme as
well.
* dev-qt seems appropriate.
* qt-base would work too.
* qt-libs or lib-qt, not so much, because there's executables as well.
* x11-qt not so much, as qt5 is no longer x11 limited. Additionally, x11/
xorg will arguably start losing its dominance to wayland in the qt5
timeframe, with qt5 even now having (preliminary?) wayland support I
believe, and at some point, x11-qt may well look rather quaint and
anachronistic, sort of like references to ip-chains or xfree86 do today.
So my vote would be for dev-qt/qt-*. Yes, that's a doubled qt reference
with the category, but in practice, few use the category name unless they
have to anyway, and it sure beats the namespace polluting alternative!
--
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: removing the server profiles...
Ben de Groot posted on Sat, 19 Jan 2013 18:47:58 +0800 as excerpted: On 19 January 2013 18:26, Rich Freeman ri...@gentoo.org wrote: On Sat, Jan 19, 2013 at 3:26 AM, Ben de Groot yng...@gentoo.org wrote: People who do have printers can always enable [USE=cups] themselves. Unless we plan on adding yet another profile for normal users I think this is really pushing it. Yes, I'm sure some people don't own printers. However, that figure has to be fairly low. I'm not so sure about that. The majority of my friends and colleagues don't own a printer. When we do need to print something, it would be for work, so we have it printed at work. I recently heard someone /else/ recommend no printer, pointing out that it was an additional expense without a lot of practical benefit for many, since ink is expensive, the cheap printers are fiddly and often break, and if you /really/ want something printed, it's easy enough to load it on a thumb-drive and take it to kinkos or the library (or as Ben suggests, work). I had come to that conclusion for myself some time ago and haven't had a printer in years... I won't do inkjet and I always seem to have something better to do with the money that'd buy a decent laser. But it was still rather surprising to me, as like Rich, I'm from the generation where it was just assumed that if you had a computer, you had, and needed, a printer. So to hear (it was a meatspace conversation, with average folks, not geeks) someone ELSE say take it to kinko's if you want to print something was /indeed/ quite surprising/enlightening. So yes, I suppose it really is a generational/cultural thing. The tablet generation and the smartphone generation are rather more likely to find the idea of simply assuming that everyone with a computer/tablet/ smartphone also has a bulky/balky printer... rather quaint. -- 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] RFC: new qt category
On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@gentoo.org 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 that the time has come to split all these out into their own category. This category is to be used for the various modules and applications that belong to the upstream Qt Framework only (these include e.g. assistant and linguist). Third-party applications should remain in the current categories. After some initial bikeshedding we came to the conclusion that naming the category simply qt is the most elegant solution. We will then also be dropping the qt- prefix in package names. This means x11-libs/qt-core will be moved to qt/core, and so on. Please let us know your thought on this. 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 the Qt libs would fit into each of them. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: removing the server profiles...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/2013 12:05 PM, Duncan wrote: Ben de Groot posted on Sat, 19 Jan 2013 18:47:58 +0800 as excerpted: On 19 January 2013 18:26, Rich Freeman ri...@gentoo.org wrote: On Sat, Jan 19, 2013 at 3:26 AM, Ben de Groot yng...@gentoo.org wrote: People who do have printers can always enable [USE=cups] themselves. Unless we plan on adding yet another profile for normal users I think this is really pushing it. Yes, I'm sure some people don't own printers. However, that figure has to be fairly low. I'm not so sure about that. The majority of my friends and colleagues don't own a printer. When we do need to print something, it would be for work, so we have it printed at work. I recently heard someone /else/ recommend no printer, pointing out that it was an additional expense without a lot of practical benefit for many, since ink is expensive, the cheap printers are fiddly and often break, and if you /really/ want something printed, it's easy enough to load it on a thumb-drive and take it to kinkos or the library (or as Ben suggests, work). I had come to that conclusion for myself some time ago and haven't had a printer in years... I won't do inkjet and I always seem to have something better to do with the money that'd buy a decent laser. But it was still rather surprising to me, as like Rich, I'm from the generation where it was just assumed that if you had a computer, you had, and needed, a printer. So to hear (it was a meatspace conversation, with average folks, not geeks) someone ELSE say take it to kinko's if you want to print something was /indeed/ quite surprising/enlightening. Removing cups from the default profile and putting it in the desktop profile makes sense. I don't print from everything, but I often print from things using the desktop profile. If a user really doesn't want cups they can always adjust their make.conf. Let's not bikeshed on this forever, we are only setting a sane default not removing the user's choice. Honestly it can be as simple as cups is default now and removing that will break a lot of desktop users. So again, I vote for moving it to the desktop profile, but not for removing it altogether as that would break a lot of users. - -Zero So yes, I suppose it really is a generational/cultural thing. The tablet generation and the smartphone generation are rather more likely to find the idea of simply assuming that everyone with a computer/tablet/ smartphone also has a bulky/balky printer... rather quaint. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ+tX4AAoJEKXdFCfdEflKTFYP/AtPX4K6KKNlt1vaNUBSdDAr bsINnACEGJC5WljLX9FNgiVBH3yyTPiMJJoCZf494Rl4q1QhUypSg7twdkF9DVS5 1wYpCLeixQoe2LAjRApu5myCPDLMnSTdZIQy0tjsAsU2bO3HcJ++NJj633WMbjSY y54zaQeSTXXxOA+0XFXDEoF2H+icZuTBGsjZgpRlPMWcMglOmh1n9YLgeFT4Bmoz i+GgEB5TtvP9j+UNuuASPwiX3vJRSvaPbShiFGXMeGwiQPiKpam/ZH29EZst02Bv T8nDhWN4qsemCbWVc8ocgU2iA9andeYNkHsU4kB4MnEJUMZw9QwCcIEy6GYa6znv Y7ZBF1lr2Y4cZLXV8NCUChiyEIxLK/6F4kwFq3SnGOh1EEu7tZlWzE3pOjsQigQq kyadls0mlC0IA9mugnTrIJF7KRxzC2DTQhspPypEJc3p4i44/AKA3bHTzTviNwj7 NUIFMBp4zS5csCSVkAwWvCpmX1iX/5V0Xv0w9TKT99Vca2Zn54uB/scLLXOcqiNe jP5FknoDAhBy1iepM3H/5x6V+5YVnhB8wTGCRmXWfmVapQAu7/rQU66nYt0KumEM rR1dns7Qb4cW7VEPJ7E6MabFup6gk994Bd82WA78Sx0CFjfDMFah10l9dP2cbRi3 NCGKbT9JpnAOIsmOoLI1 =OBjr -END PGP SIGNATURE-
[gentoo-dev] [review] adding first stable masks to the new profiles
Hello, We -- the Python team -- would like to add the first masks to the new profiles. As a test target, I have chosen the python_targets_pypy1_9 flag. I have prepared and committed the necessary changes to my CVS checkout [1]. I would appreciate if you could review them and tell me if they are done correctly. The idea is that: 1) pypy1_9 is masked globally -- for old profiles and unsupported arches, 2) pypy1_9 is unmasked for the new profiles in supported arches, 3) pypy1_9 is stable-masked for the new profiles in supported arches. In order to test, I have added pypy1_9 to PYTHON_COMPAT in app-portage/flaggie-0.2-r2 amd64x86-stable ebuild. Sadly, it doesn't seem to work but I believe it is a bug in repoman. The interesting thing is that adding the stable-mask makes the situation even worse. When testing without it, repoman complains about non-keyworded pypy:1.9: dependency.bad36 app-portage/flaggie/flaggie-0.2-r2.ebuild: DEPEND: amd64(default/linux/amd64/10.0) ['dev-python/pypy:1.9'] When running with pypy1_9 flag stable-masked, it complains about python-exec flags as well: dependency.badindev 28 app-portage/flaggie/flaggie-0.2-r2.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['dev-python/python-exec[python_targets_python2_6?,python_targets_python2_7?,python_targets_python3_1?,python_targets_python3_2?,python_targets_pypy1_8?,python_targets_pypy1_9?,-python_single_target_python2_6(-),-python_single_target_python2_7(-),-python_single_target_python3_1(-),-python_single_target_python3_2(-),-python_single_target_pypy1_8(-),-python_single_target_pypy1_9(-)]', 'dev-python/pypy:1.9'] Long output short, it still complains about pypy:1.9 but seems also to notice that pypy1_9 was masked in python-exec. But it is also masked in the ebuild in question, therefore it shouldn't complain… [1]:https://bitbucket.org/mgorny/gx86-working-tree/commits/54ec3860de -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] call for testers: udev predictable network interface names
On Fri, Jan 18, 2013 at 10:07:42AM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/13 09:54 AM, William Hubbs wrote: On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/13 07:24 AM, viv...@gmail.com wrote: Since for servers predictable names are useful and for desktop (which usually have only one ethernet that never change) Is it possible to set desktop profiles to still use ethX, and base profile to use new naming scheme? For wireless situation may be different, many of them are external, could wireless be managed differently? In short, no. At least, not unless the functionality that is currently a configure-time thing is changed into a build-time/install-time thing controlled via a use flag. Actually,this is how I set you up by dropping the file in /etc/udev/rules.d/80-net-name-slot.rules. Nothing changes on your system unless you remove this file and do not have 70-persistent-net.rules. William ..right, but default behaviour can't be changed automatically depending on what profile you're on, as vivo requested, since profiles don't control configuration (just use flags) Right, and we have a policy against using use flags to control the installation of configuration files. vivo, what is your concern here exactly? William pgpnT__EsTSSb.pgp Description: PGP signature
Re: [gentoo-dev] Chromium system ffmpeg
On 1/15/13 4:55 AM, Alexis Ballier wrote: On Mon, 14 Jan 2013 20:34:42 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I'm trying to make Chromium be more compatible with more versions of ffmpeg: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion (although not stated there, that includes libav). I've done quite a lot of work for various packages among the past years on that side, so if you have specific questions, feel free to ask. Oh, one more thing: is there an easy way to check whether e.g. CODEC_ID_OPUS is defined? I just realized it's not a pre-processor symbol but an enum value so #ifdef wouldn't work. I could always check the version #defines, but it requires checking version control to see when it was introduced. It would be great to just have a way to more simply exclude code that requires CODEC_ID_OPUS. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE flags dri, cups, pppd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/13 05:33 AM, Rich Freeman wrote: On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot yng...@gentoo.org wrote: I'm not sure whether we need to keep cups at all. I haven't printed anything from my personal PC or laptop in years. And I'm sure I'm not the only one. The suggestion that few people actually print anything ever really seems out of touch to me, but it could easily be cultural/generational/etc, and maybe I'm the one who is out of touch. I'll add to this bikeshed.. I'll agree (as i believe most will) that the days are going where everyone has a printer linked to their computer. However, I also hold the opinion that many (if not the majority) have access to a printer when necessary, either via their network or (in the case of laptops) via accessing a colleague's network. We could certainly disable/remove cups from the default profiles, and thus drop printing support -- but do we really want to put users into a situation that they will have to rebuild a bunch of stuff for those cases when the -do- want to print something? I think opt-out on this one is still a better option; if you *know* the install will never need to print (or act as a print server), USE=-cups is easy enough to set. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD68kMACgkQ2ugaI38ACPDaqAEAn89GvjNHOs8khpbu7wyKiuyv oYRBXZjhdi2Z0WNhk1cBALaT8gwMuTTJStuEHbcHZnxztgKoxczf6RNXhq4W09ZN =J2tZ -END PGP SIGNATURE-
Re: [gentoo-dev] removing the server profiles...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/13 05:47 AM, Ben de Groot wrote: Actually, that is what I would expect from the more basic oriented ones like Arch and Debian. Printer support should be an optional add-on, not part of the basic install. Maybe I'm too idealistic... Well, it's not part of the basic install -- cups isn't part of @system. It's just installed when you install something that has compile-time printer support, afaik. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD68s4ACgkQ2ugaI38ACPB4pAD/cAJF+K7srugh5gpzaijoanLM s3xGUrWdNl8yQH2l9CMA/0mCq1ThqhSaDUv0b0cjSGuoSwVWz3PX8BQC5OwylPKp =EEv8 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new qt category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/13 05:56 AM, Ben de Groot wrote: And if you really must, is emerge qt/gui so much more difficult than emerge qt-gui? ..no, but having to specify media-libs/phonon now because qt/phonon conflicts (just one of probably many examples) is a bit more of a pain. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD687cACgkQ2ugaI38ACPARewD+OCojV9s7o/TNI8U66S9QEZKj aMamo/OYwBw65I8A7J8A/3wi4XmgoFH+zvskCATuy0PrcMnqiIFW4i8KJBHHiV8v =FISj -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new qt category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jan 19, 2013 at 2:21 PM, Rich Freeman ri...@gentoo.org wrote: Maybe x11-qt, or dev-qt, or just qt, or qt-qt if we must have a hyphen for its own sake and we're just making senseless stuff up. qt-core just doesn't make sense if it applies to more than just qt-core. Wasn't qt-framework the classic-style category name that was suggested in the original post? anything wrong with that? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlD69VEACgkQ2ugaI38ACPBUQgD/VSQ3m1zeO0k+dotPWwD4I8RK 8HoK5aWdXu0SZykvWHYA/jnx6lV9Q+qGhWWvE8WUL5UTCv/Q1sPyHuALMWQEhVja =9yz6 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new qt category
On Jan 19, 2013 5:19 PM, Michał Górny mgo...@gentoo.org wrote: On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@gentoo.org 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 that the time has come to split all these out into their own category. This category is to be used for the various modules and applications that belong to the upstream Qt Framework only (these include e.g. assistant and linguist). Third-party applications should remain in the current categories. After some initial bikeshedding we came to the conclusion that naming the category simply qt is the most elegant solution. We will then also be dropping the qt- prefix in package names. This means x11-libs/qt-core will be moved to qt/core, and so on. Please let us know your thought on this. 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 the Qt libs would fit into each of them. Nope. These modules derive from a single tarball and it makes much more sense to put all of them in the same place.
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot yng...@gentoo.org wrote: I'm not sure whether we need to keep cups at all. I haven't printed anything from my personal PC or laptop in years. As a user, I'ld say this wb a very unpopular move with some of us. I rarely use my 2nd-hand 1995 printer, but sometimes it is essential : eg I now need to print letters to 2 friends abroad who don't have e-mail occasionally I need to print forms downloaded from the Internet for tax purposes or to get mail-in refunds on things I bought. I don't have access to an office printer when last asked, my neighbour reported his printer broken. Please continue to support Cups. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] RFC: new qt category
130119 Ben de Groot wrote:
On 19 January 2013 21:46, Patrick Lauer patr...@gentoo.org 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.
They are also encountered by users when updating KDE etc.
If there is too much opposition to a simple qt category
-- at least there seems to be some quite vocal opposition -- ,
then dev-qt is in my eyes the next best alternative.
'qt' alone is inconsistent with the rest of the tree.
A third option we came up with is qt-framework.
Too long to type again no parallel in the existing tree.
Somewhat comparable categories in the current tree
are dev-dotnet and gnustep-{base,libs}.
Flame-eyes' suggestion is simple, consistent involves least change :
'x11-qt/qt-core' 'x11-qt/qt-gui' etc. Please do it like that.
--
,,
SUPPORT ___//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sat, Jan 19, 2013 at 03:53:25PM -0500, Philip Webb wrote: On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot yng...@gentoo.org wrote: I'm not sure whether we need to keep cups at all. I haven't printed anything from my personal PC or laptop in years. As a user, I'ld say this wb a very unpopular move with some of us. I rarely use my 2nd-hand 1995 printer, but sometimes it is essential : eg I now need to print letters to 2 friends abroad who don't have e-mail occasionally I need to print forms downloaded from the Internet for tax purposes or to get mail-in refunds on things I bought. I don't have access to an office printer when last asked, my neighbour reported his printer broken. Please continue to support Cups. We're only discussing whether or not to have the `cups' USE flag in the base profile, not the package itself. I don't believe we need it in the base profile. The only people who would enable it are those that are setting up a print server or those who are setting up a desktop, in which case they would want to use the desktop profile. -- Mr. Aaron W. Swenson Gentoo Linux Developer Email : titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 pgpTyPWXAp7fI.pgp Description: PGP signature
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sat, 2013-01-19 at 21:04 +, Aaron W. Swenson wrote: On Sat, Jan 19, 2013 at 03:53:25PM -0500, Philip Webb wrote: On Sat, Jan 19, 2013 at 3:18 AM, Ben de Groot yng...@gentoo.org wrote: I'm not sure whether we need to keep cups at all. I haven't printed anything from my personal PC or laptop in years. Please continue to support Cups. We're only discussing whether or not to have the `cups' USE flag in the base profile, not the package itself. I don't believe we need it in the base profile. The only people who would enable it are those that are setting up a print server or those who are setting up a desktop, in which case they would want to use the desktop profile. +1 for moving it to desktop To further add to this bikeshed! Something no-one has added so far is that there is a very easy to use tool to use when you change profiles. enalyze rebuild use It is part of gentoolkit. I first created it to help fix a new users bungled install. But it works perfect for changing profiles with different use flag defaults. In order to keep your installed packages settings the same, run this immediately after the change, look over and/or edit the file created to your liking, then replace the existing pacakage.use PROBLEM SOLVED! NO default USE flag changes will break your system. Same can be done for keyword changes done in profiles enalyze rebuild keywords So, for the new 13.0 profiles, please add this to the recommended steps for migrating profiles. It should greatly reduce the number of bugs and forum threads complaining about breakage. Yeah, I know, there will still be some that don't read instructions and continue to break their shit and complain to us it's our fault. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: new qt category
2013/1/19 Michael Weber x...@gentoo.org But please don't double the qt. yay for lib-cute/qt-core
Re: [gentoo-dev] RFC: new qt category
2013/1/19 Michał Górny mgo...@gentoo.org On Thu, 17 Jan 2013 21:57:16 +0800 Ben de Groot yng...@gentoo.org 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 that the time has come to split all these out into their own category. This category is to be used for the various modules and applications that belong to the upstream Qt Framework only (these include e.g. assistant and linguist). Third-party applications should remain in the current categories. After some initial bikeshedding we came to the conclusion that naming the category simply qt is the most elegant solution. We will then also be dropping the qt- prefix in package names. This means x11-libs/qt-core will be moved to qt/core, and so on. Please let us know your thought on this. 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 the Qt libs would fit into each of them. This would be the right thing to do, or the correct way. Most would really hate it (me too)
Re: [gentoo-dev] call for testers: udev predictable network interface names
2013/1/19 William Hubbs willi...@gentoo.org On Fri, Jan 18, 2013 at 10:07:42AM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/13 09:54 AM, William Hubbs wrote: On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/13 07:24 AM, viv...@gmail.com wrote: Since for servers predictable names are useful and for desktop (which usually have only one ethernet that never change) Is it possible to set desktop profiles to still use ethX, and base profile to use new naming scheme? For wireless situation may be different, many of them are external, could wireless be managed differently? In short, no. At least, not unless the functionality that is currently a configure-time thing is changed into a build-time/install-time thing controlled via a use flag. Actually,this is how I set you up by dropping the file in /etc/udev/rules.d/80-net-name-slot.rules. Nothing changes on your system unless you remove this file and do not have 70-persistent-net.rules. William ..right, but default behaviour can't be changed automatically depending on what profile you're on, as vivo requested, since profiles don't control configuration (just use flags) Right, and we have a policy against using use flags to control the installation of configuration files. vivo, what is your concern here exactly? William My concern was to make simple desktop users happy while leaving the servers safe. The answers given in the previous emails are satisfying, since they cover exhaustively what is in place and what could be (or not) done. Thanks, Francesco
Re: [gentoo-dev] USE flags dri, cups, pppd
This question only matters if you expect there to be non-desktops where there are packages installed that IUSE dri. I'd note that there is no correlation between the use of the desktop profiles and the use of an X11 or wayland server on any given box. The (gui) world is much more than gnome+kde. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] USE flags dri, cups, pppd
On Sat, Jan 19, 2013 at 07:40:56PM -0500, James Cloos wrote:
This question only matters if you expect there to be non-desktops where
there are packages installed that IUSE dri.
I'd note that there is no correlation between the use of the desktop
profiles and the use of an X11 or wayland server on any given box.
The (gui) world is much more than gnome+kde.
-JimC
That's why there's a base desktop profile and desktop/{gnome,kde}
profiles.
Moving `dri' to the base desktop profile is sensible in that we
recommend any user who will be running a GUI use the desktop
profile. Those who aim for a minimalist profile will enable the flag
themselves.
--
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
pgp7VmQZopbDI.pgp
Description: PGP signature
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Thu, Jan 17, 2013 at 07:09:29AM -0500, Michael Mol wrote On Jan 17, 2013 3:35 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Thu, Jan 17, 2013 at 3:23 AM, Walter Dnes waltd...@waltdnes.org wrote: If someone wants a *REALLY* basic system, they can start off with USE=-* and add on stuff as necessary when portage complains and/or ebuilds break. That's what I'd recommend to someone wanting to set up a basic server machine. Yeah, but that sucks with USE_EXPAND. For example, I sure want some version of Python installed, but setting USE=-* removes all support for Python versions and has me add them one by one. I guess I could do that, but now I always have to keep up to date myself, which sucks. My thought is that base should have just enough enabled for stage3 to be self-hosting. Moving existing base to something like common would retain a profile for that most people would want this set. 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 half-way through installing the apps I normally use. I went back to -*. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
