[gentoo-dev] Re: How to set CXX compiler?
On 06/07/2020 10:48, Xianwen Chen (陈贤文) wrote:
Thank you, Michael and James.
Yes, I plan to submit a nice patch to the Makefile to upstream.
However, I think something is not right on my computer.
I have earlier tried to specify
emake CC="$(tc-getCXX)" prefix="${EPREFIX}/usr" DESTDIR="${D}"
Somehow, emerge does not know what $(tc-getCXX) is.
[...]
Below is the content of the ebuild:
###
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
RESTRICT="splitdebug"
sosicon_git_commit="655c75a4de75dbd4998ced6473aea255fed2492c"
[...]
The ebuild is missing an "inherit" line below the "EAPI" one that
specifies "toolchain-funcs" (which is the eclass that provides the
"tc-*" functions. Try
EAPI=7
inherit toolchain-funcs
[gentoo-dev] Re: Last rites: media-video/subliminal
On 19/04/2020 22:47, Michał Górny wrote: # Michał Górny (2020-04-19) # Unmaintained. Stuck on Python 3.6. Last release in 2016. # Removal in 30 days. Bug #718410. media-video/subliminal It's an active project. Just not doing releases often. Today 2.1.0 was released: https://github.com/Diaoul/subliminal/releases/tag/2.1.0 Add support for python 3.6, 3.7 and 3.8 Drop support for python 3.3 and 3.4
[gentoo-dev] Re: Packaging changes in LLVM 10
On 16/03/2020 14:37, Gerion Entrup wrote: when I compile LLVM for myself, I also always choose SHARED_LIBS simply because of RAM usage when linking the libraries. In the past, I was not able to link the single library on my 16 GB machine (I have not tested it now and this could be dependent on other circumstances). What is the current expected RAM usage for LLVM 10? Sounds something else was wrong perhaps. I'm on 16GB RAM, 10GB of which are for the tmpfs I use for portage, and even with that it builds fine with -j4.
[gentoo-dev] Re: Changing policy about -Werror
On 09/09/2018 14:32, Andrew Savchenko wrote: My point is that in *most* cases -Werror indeed should be removed, because upstream rarely can keep up with all possible configure, *FLAGS, compiler versions and arch combinations. But! In some cases — especially for security oriented software — this flag may be pertain and may be kept at maintainer's discretion. The rationale is that -Werror usually points to dangerous situations like uninitialized variables, pointer type mismatch or implicit function declaration (and much more) which may lead to serious security implications. Not sure if user feedback is welcome or not, but consider: A piece of security oriented software gets an update (v2) that closes a security hole in v1. User tries to update to v2, but the emerge fails because of -Werror. User stays on v1 and thus remains vulnerable. -Werror achieved the exact opposite of what the intent was.
[gentoo-dev] Re: News item: upgrading to Plasma 5
On 03/04/16 20:34, Michael Palimaka wrote: Hi, KDE team intends to stabilise Plasma 5 shortly, so please review the accompanying news items. There's many packages that warn me about not having KDE installed when upgrading to Plasma 5. It's in a quite accusatory tone even: WARNING! Your system configuration does not contain "kde-apps/kdebase-runtime-meta". With this setting you are unsupported by KDE team. All missing features you report for misc packages will be probably ignored or closed as INVALID. I think should be fixed, or if not then at least be addressed in the news item because I find the warning very confusing.
[gentoo-dev] Re: RFC News item: FFmpeg default
he page you have tried to view (Why Debian returned to FFmpeg) is currently available to LWN subscribers only. On 14/07/15 14:12, Jason A. Donenfeld wrote: https://lwn.net/Articles/650816/ On Apr 16, 2015 1:51 PM, Ben de Groot yng...@gentoo.org mailto:yng...@gentoo.org wrote: On 11 April 2015 at 15:19, Ben de Groot yng...@gentoo.org mailto:yng...@gentoo.org wrote: And since this is now on the Council's agenda, we're waiting for their decision. Since the Council had no objections, this has now been committed. Thanks for all the feedback. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Re: git://anongit.gentoo.org is extremely slow
On 23/04/15 23:01, Robin H. Johnson wrote: On Wed, Apr 22, 2015 at 05:11:13PM +0300, Nikos Chantziaras wrote: Adding overlays with layman is now extremely slow after the overlays were moved to anongit.gentoo.org. Cloning anything beginning with git://anongit.gentoo.org/ is capped at 15KB/s, sometimes 10KB/s. This is unworkably slow. Is this intentional? Where are you located? I'm wondering if you're suffering connectivity impacts of the location change. Both boxes have enough hardware: anongit (manakin): Xeon E5-2620, 32GB RAM, 512GB SSD (RAID1), US-East git (oystercatcher): Xeon E5-1650, 64GB RAM, 240GB SSD (RAID1), Germany We'll be bringing a EU location for anongit online as well soon, mostly as the US-East doesn't have IPv6, and we can't put a tunnel into there. The problem seems to have been fixed now. It was not a location problem, because only git:// seemed to be affected: git clone git://...- 15KB/s git clone https://... - 2MB/s
[gentoo-dev] git://anongit.gentoo.org is extremely slow
Adding overlays with layman is now extremely slow after the overlays were moved to anongit.gentoo.org. Cloning anything beginning with git://anongit.gentoo.org/ is capped at 15KB/s, sometimes 10KB/s. This is unworkably slow. Is this intentional?
[gentoo-dev] Re: multilib amd64 news item for review
On 17/03/15 18:29, Michał Górny wrote: Dnia 2015-03-17, o godz. 16:55:32 René Neumann li...@necoro.eu napisał(a): Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. Because this is how users learn new fun stuff. Like sane configuration. I don't see why ABI_X86 is not the sane option. Using wildcards in package.use is what sounds insane to me. Are you suggesting that the sane way of setting USE flags globally is moving them from make.conf into package.use and use wildcards to set them globally? And to bring this even further: Wouldn't the nicest approach to add ABI_X86=32 This will disable some 64-bit web browser plugins. I don't see why the package.use wildcard wouldn't do that too. ABI_X86=32 64 to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). This will enable some possibly-unwanted 64-bit software, e.g. 64-bit Windows support in wine. I don't see why the package.use wildcard wouldn't do that too.
[gentoo-dev] Re: multilib amd64 news item for review
On 29/03/15 19:24, Michał Górny wrote: Dnia 2015-03-29, o godz. 19:14:43 Nikos Chantziaras rea...@gmail.com napisał(a): On 17/03/15 18:29, Michał Górny wrote: Dnia 2015-03-17, o godz. 16:55:32 René Neumann li...@necoro.eu napisał(a): Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. Because this is how users learn new fun stuff. Like sane configuration. I don't see why ABI_X86 is not the sane option. Using wildcards in package.use is what sounds insane to me. Because it overrides the defaults without providing a way to append to them. According to emerge --info, ABI_X86 seems to append, not override. In make.conf: ABI_X86=32 Then: $ emerge --info | grep -i abi_x86 You get: ABI_X86=32 64 64 seems to be always there. You cannot override it. Using ABI_X86=32 in make.conf seems to only append 32 to the default. If this is not the case, and */* abi_x86_32 in package.use really does something different, then this is implemented in a way too confusing for people and should be considered a bug :-/
[gentoo-dev] Re: multilib amd64 news item for review
On 29/03/15 21:00, Andrew Savchenko wrote: */* long list of 433 flags Yeah, just noticed that I can't split the lines. I then tried to define an array of USE flags in make.conf: GLOBAL_USE_FLAGS=( ... ) so that I can then use that array in package.use, but for some reason make.conf doesn't accept arrays :-/
[gentoo-dev] Re: multilib amd64 news item for review
On 29/03/15 20:28, Michał Górny wrote: Dnia 2015-03-29, o godz. 19:59:19 Nikos Chantziaras rea...@gmail.com napisał(a): According to emerge --info, ABI_X86 seems to append, not override. In make.conf: ABI_X86=32 Then: $ emerge --info | grep -i abi_x86 You get: ABI_X86=32 64 64 seems to be always there. You cannot override it. Using ABI_X86=32 in make.conf seems to only append 32 to the default. Portage may do that because it's forced by default. But some packages 'unforce' it, and that's when it matters. If this is not the case, and */* abi_x86_32 in package.use really does something different, then this is implemented in a way too confusing for people and should be considered a bug :-/ Yes, USE support in make.conf is a big pile of random misbehaviors and bugs that need to be killed with fire. Looks like I'm moving USE flags and abi_x86_32 into package.use... I hope that doesn't compromise emerge --info output for bugzilla issues?
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-video/mplayer2 media-video/smplayer2
On 16/03/15 11:58, Alexander Berntsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/03/15 10:15, Ben de Groot wrote: # These projects have been abandoned upstream. Most mplayer2 devs have moved # on to media-video/mpv, and users are suggested to do the same. We have # media-video/baka-mplayer and media-video/smplayer available as Qt-based GUIs. Does smplayer work with mpv? (baka-mplayer is not sufficient for my needs.) Version 14.9.0.6690 and up supports mpv.
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: media-video/mplayer2 media-video/smplayer2
On 16/03/15 16:27, Rich Freeman wrote: On Mon, Mar 16, 2015 at 10:09 AM, Ben de Groot yng...@gentoo.org wrote: On 16 March 2015 at 21:54, Юра Цимбалов yura.t...@gmail.com wrote: That would be great, but it depends on getting newer mpv stable, while (s)mplayer2 is dead and broken right now. https://bugs.gentoo.org/buglist.cgi?quicksearch=mplayer2list_id=2703540 Why it's broken? As stated in my original message: See bugs 452484, 485994, 512082, 519212. Obviously if software has serious issues it needs to be treecleaned, but I seem to recall this package coming up in the whole ffmpeg defaults discussion. As I recall libav is now the default, and the argument was that users should just use mplayer2 and such for compatibility. Now it sounds like stable users don't have that option, at least for a time. mpv prefers ffmpeg, actually. It still works with libav, but this results in some missing features and some bugs. Does someone know which packages in portage work better with libav than with ffmpeg? If there aren't any, ffmpeg should probably be made the default, in order to reduce the amount of problems.
[gentoo-dev] Re: Should there be a preference with qt4 and qt5 USE flags?
On 08/03/15 21:35, Alexandre Rostovtsev wrote: On Sun, 2015-03-08 at 21:31 +0200, Nikos Chantziaras wrote: Some ebuilds in portage for Qt-based software support both Qt4 as well as Qt5. Some have +qt4 qt5 in IUSE, others have qt4 qt5. Is there a guideline for this somewhere? If a package needs Qt and thus lists: REQUIRED_USE=^^ ( qt4 qt5 ) but otherwise doesn't prefer one version over the other and both are equally well supported, should qt4 still be enabled by default? Follow what upstream developers suggest and/or what works best in practice? At least that's what is usually done for gtk2 vs. gtk3. Both work equally well. (I'm upstream.)
[gentoo-dev] Should there be a preference with qt4 and qt5 USE flags?
Some ebuilds in portage for Qt-based software support both Qt4 as well as Qt5. Some have +qt4 qt5 in IUSE, others have qt4 qt5. Is there a guideline for this somewhere? If a package needs Qt and thus lists: REQUIRED_USE=^^ ( qt4 qt5 ) but otherwise doesn't prefer one version over the other and both are equally well supported, should qt4 still be enabled by default?
[gentoo-dev] Re: vmware team needs help
Btw, what is the appropriate place to discuss vmware overlay related issues?
[gentoo-dev] Re: vmware team needs help
On 13/02/15 00:03, Andreas K. Huettel wrote: * sorting out the screwed-up bundled library situation VMware seems to bundle everything they need. Currently, revdep-rebuild triggers false positives for a library that is no longer in portage (libgtop-2.0.so.7 from gnome-base/libgtop-2.28.5; it was removed from the tree.) I'd like to do the same as firefox-bin and other binary packages, and add an /etc/revdep-rebuild/ file: SEARCH_DIRS_MASK=/opt/vmware This prevents vmware from triggering bogus revdep-rebuild loops.
[gentoo-dev] Re: vmware team needs help
On 15/02/15 20:20, Andreas K. Huettel wrote: Am Sonntag, 15. Februar 2015, 18:29:25 schrieb Nikos Chantziaras: Btw, what is the appropriate place to discuss vmware overlay related issues? Best is probably #gentoo-virtualization on freenode. Any non-realtime place?
[gentoo-dev] Re: vmware team needs help
On 13/02/15 00:03, Andreas K. Huettel wrote: We have an overlay that can be used and is used for user contributions. Any plans to move it to github so we can fork and send pull requests?
[gentoo-dev] Re: vmware team needs help
On 14/02/15 20:30, Andreas K. Huettel wrote: Am Samstag, 14. Februar 2015, 15:38:12 schrieb Nikos Chantziaras: On 13/02/15 00:03, Andreas K. Huettel wrote: We have an overlay that can be used and is used for user contributions. Any plans to move it to github so we can fork and send pull requests? Any plans to take the quizzes and take responsibility yourself? :) I've been around long enough (2005-ish or so) to know that I don't want the Gentoo dev-community drama :-P But perhaps more importantly, I tend to disappear for whole months at a time. Should user-submitted patches/pull requests be sent to the vmware herd email, or directly to you?
[gentoo-dev] Are users forced to use PAM?
In bug 524074 (https://bugs.gentoo.org/show_bug.cgi?id=524074), Joshua Kinard mentioned that Gentoo cannot support systems where PAM isn't installed. I'd like to know whether this is true or not, especially since no part of the system seems to actually require it. It is there if you need it. I don't have a use for it, personally. (The issue at hand is that sudo links against -lshadow, which should not happen and therefore that link command removed from the build.)
[gentoo-dev] Re: Are users forced to use PAM?
On 05/10/14 16:20, Diego Elio Pettenò wrote: Please get upstream to apply the patch and release a new sudo version. Simple as this: -pam is not by default tested and you keep the pieces if it breaks. If you can get upstream to just apply that patch, you solve your problem. Insulting developers as it's happening on that bug will bring you nowhere. I didn't insult anyone.
[gentoo-dev] Re: bash-completion-2.1-r1
On 09/09/13 13:05, Michał Górny wrote: Dnia 2013-09-09, o godz. 12:50:03 Samuli Suominen ssuomi...@gentoo.org napisał(a): On 09/09/13 12:24, Michał Górny wrote: 1. how to properly disable completions the 'new way'? something like http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/ should be replicated at wiki.gentoo.org Did you actually try that? Trying plain: complete -r git it removes git completion indeed. But when I type 'git tab', it is loaded back :). You can disable the bash-completion USE flag of dev-vcs/git. This isn't a real solution, of course, since you need to recompile the whole package every time you want to disable or enable bash completion. But if you don't intend to actually ever use Git's completion, then this should work.
[gentoo-dev] Header files and ABI_X86
Now that Gentoo is much better in handling multilib libraries, but Gentoo is source-based, there's the question of which header files are used between different ABI builds. As I understand it, only the headers from the default ABI are installed. That means that building for abi_x86_32 on a amd64 system will use the headers installed by the abi_x86_64 build of the used library. From a developer's point of view, does that mean that we now have to keep Gentoo in mind when writing header files, or does Gentoo apply any kind of magic here to fix differences between header files for different archs? For example, if I need to provide a PTR_SIZE macro in a header that contains the size of void pointers on this particular system, I would detect this with autoconf and then just use that, so the header file would end up simply containing: #define PTR_SIZE 8 on x86-64, and: #define PTR_SIZE 4 on x86. The x86-64 header won't work properly when building on Gentoo for abi_x86_32. As a developer, this is a no-no for me: #ifdef THIS_ARCH #define PTR_SIZE 8 #elif defined THAT_ARCH #define PTR_SIZE 4 ... because detection should be done in autoconf, not in the header file. So how does Gentoo solve that problem?
[gentoo-dev] Re: Header files and ABI_X86
On 22/08/13 11:16, Michał Górny wrote: Dnia 2013-08-22, o godz. 10:56:10 Nikos Chantziaras rea...@gmail.com napisał(a): Now that Gentoo is much better in handling multilib libraries, but Gentoo is source-based, there's the question of which header files are used between different ABI builds. As I understand it, only the headers from the default ABI are installed. That means that building for abi_x86_32 on a amd64 system will use the headers installed by the abi_x86_64 build of the used library. The build process installs alls headers by default and compares if they're the same. The ebuild can also specify that some headers need to be wrapped -- in that case they are installed with an ABI-detecting wrapper on top. Perfect. That's exactly what I wanted to know :-) From a developer's point of view, does that mean that we now have to keep Gentoo in mind when writing header files, or does Gentoo apply any kind of magic here to fix differences between header files for different archs? For example, if I need to provide a PTR_SIZE macro in a header that contains the size of void pointers on this particular system, I would detect this with autoconf and then just use that, so the header file would end up simply containing: #define PTR_SIZE 8 on x86-64, and: #define PTR_SIZE 4 on x86. The x86-64 header won't work properly when building on Gentoo for abi_x86_32. As a developer, this is a no-no for me: #ifdef THIS_ARCH #define PTR_SIZE 8 #elif defined THAT_ARCH #define PTR_SIZE 4 ... because detection should be done in autoconf, not in the header file. As a developer, you should learn not to put anything system- or machine- -specific in public headers. This is simply wrong, and will break more ways than you could imagine. We're hacking it over but it's far from perfect, and is not an excuse to write more screwed up software. Anything you detect about the host should be used *only* inside C files, and header files that are only used during build-time and not installed. That's good advice in general, but sometimes this can't be done. C++ templates for example need to be in headers, and thus there's sometimes gonna be platform-specific stuff in them. Even if the headers are private, they still need to be there and will get included indirectly.
[gentoo-dev] Re: desktop experience on smartphone: thoughts and plans against Ubuntu edge
On 13/08/13 08:21, heroxbd wrote: Dear Fellows, Canonical is raising money by pushing their concept of Ubuntu for Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) in parallel to Android to drive the external HDMI output with X11 protocal, so that desktop applications can run on the smartphone. [...] I feel sorry to the behavior of Canonical. We, people from the Gentoo community, can show the general public what is the cooperative way to develop desktop/smartphone hybrid to benefit all. Note that Canonical, if their project succeeds, it going to ship actual devices. It's not just going to deliver a hack, but rather a real, supported, ready to be used device. No Gentoo project could possibly offer a real alternative to this.
[gentoo-dev] Re: New global USE flag: qt5
On 27/05/13 18:06, Michael Palimaka wrote: Hi all, Qt 5 has been available for some time, and we are making preparations to move it to the tree. As we will be supporting user choice where packages can be build against both Qt 4 and Qt 5, we will require a new global USE flag: qt5 - Adds support for the Qt 5 application and UI framework Please note that this flag will be immediately masked until Qt 5 actually makes it to the tree, but is required to do the necessary pre-work. I suppose there will be an eqmake5 that should be called instead of eqmake4 when that USE flag is set?
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 25/03/13 21:01, Markos Chandras wrote:
On 25 March 2013 17:12, Nikos Chantziaras rea...@gmail.com wrote:
On 24/03/13 23:12, Markos Chandras wrote:
On Mar 24, 2013 8:51 PM, Nikos Chantziaras rea...@gmail.com
mailto:rea...@gmail.com wrote:
In the end it's another program that will end up in my ~/bin directory.
Why? Don't you want to work with me and maintain it together? Why keep
it working just for you?
I can do that. Though the current ebuild seems to work just fine. There's
no alsa USE flag and it builds with automake 1.13.
I don't know what you mean by this: there is no alsa use flag
~$ grep alsa tvtime-1.0.2_p20110131-r3.ebuild
http://dev.gentoo.org/~a3li/distfiles/${PN}-1.0.2-alsamixer-r1.patch
http://dev.gentoo.org/~a3li/distfiles/${PN}-1.0.2-alsa-r1.patch
http://dev.gentoo.org/~a3li/distfiles/${PN}-1.0.2-alsa-fixes.patch;
IUSE=alsa nls xinerama
alsa? ( media-libs/alsa-lib )
if use alsa; then
epatch ${DISTDIR}/${PN}-1.0.2-alsa-r1.patch
epatch ${DISTDIR}/${PN}-1.0.2-alsamixer-r1.patch
epatch ${DISTDIR}/${PN}-1.0.2-alsa-fixes.patch
So there is an alsa use flag and it does apply quite a lot of
patches in there. So the open bug is not fixed yet. Could you have a
look?
Hmm, indeed. I didn't actually read the ebuild before. I did:
$ equery uses tvtime
and there's no alsa USE flag. Also, emerging tvtime with the flag
enabled and then disabled, results in no changes. The flag is being
ignored here?
Anyway, note that I cannot test whether the patches actually work at
runtime or not. My TV card uses an SAA7130 chip with no internal audio
cabality. Instead, it has a line-out jack, which I connect to the
line-in of my sound card in order to get sound from it.
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 25/03/13 08:40, Nuno J. Silva (aka njsg) wrote: On 2013-03-25, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: On Fri, Mar 22, 2013 at 8:15 PM, Markos Chandras hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (22 Mar 2013) # Fails with automake-1.12 (#424289) # Problems with the alsa patches (#403389) # Herd has not interest in it and needs a maintainer # Removal in a month unless a new maintainer steps up # and fix all the bugs # Alternatives: media-tv/me-tv, media-tv/mythtv media-tv/tvtime Too sad to see it being treecleaned. :( I used it for a long time, and it really rocks, but I don't own any pc-tv hw anymore. I'd like to avoid it being treecleaned, but without the hw, it is just impossible. Similar problem here, I do own a tv tuner, but there are no *analog* broadcasts here. From what I know, tvtime only works with analog TV. If you get the classic TV white static, and a shhh sound, it works ;-)
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 24/03/13 23:12, Markos Chandras wrote: On Mar 24, 2013 8:51 PM, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com wrote: On 24/03/13 22:25, Matt Turner wrote: On Sun, Mar 24, 2013 at 7:43 AM, Markos Chandras hwoar...@gentoo.org mailto:hwoar...@gentoo.org wrote: And what if it breaks again in the future? Should we go over the same discussion again? Can't this be restated as Shouldn't we tree clean it now since it could have bugs in the future?? Tree cleaning packages over future hypothetical bugs seems like bad policy. Well, even though I wasn't happy to see tvtime getting tree-cleaned, I understand that Gentoo doesn't work with hired packagers. This isn't Ubuntu or RedHat Linux. Gentoo packagers don't maintain what they're not interested in. In the end it's another program that will end up in my ~/bin directory. Why? Don't you want to work with me and maintain it together? Why keep it working just for you? I can do that. Though the current ebuild seems to work just fine. There's no alsa USE flag and it builds with automake 1.13.
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 24/03/13 12:01, Markos Chandras wrote: On Mar 24, 2013 1:19 AM, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com wrote: On 24/03/13 02:12, Markos Chandras wrote: On 24 March 2013 00:02, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com wrote: On 23/03/13 01:15, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org mailto:hwoar...@gentoo.org (22 Mar 2013) # Fails with automake-1.12 (#424289) # Problems with the alsa patches (#403389) # Herd has not interest in it and needs a maintainer # Removal in a month unless a new maintainer steps up # and fix all the bugs # Alternatives: media-tv/me-tv, media-tv/mythtv media-tv/tvtime These aren't alternatives (they're only dealing with digital TV, not analog.) AFAIK, tvtime has no alternatives at all. If it goes, analog TV users can't watch TV anymore :-/ Nothing I can do. It has no maintainer and quite a few outstanding bugs. If people need it, they should probably move it to a local overlay. Shouldn't this be marked as maintainer-needed instead of dropping it? How would that help fixing all the open bugs? Maintainer-needed@g.o is for packages that have no maintainer. If they are broken we remove these as well Are there more then the two mentioned in the mask message? Those two have fixes.
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 24/03/13 22:25, Matt Turner wrote: On Sun, Mar 24, 2013 at 7:43 AM, Markos Chandras hwoar...@gentoo.org wrote: And what if it breaks again in the future? Should we go over the same discussion again? Can't this be restated as Shouldn't we tree clean it now since it could have bugs in the future?? Tree cleaning packages over future hypothetical bugs seems like bad policy. Well, even though I wasn't happy to see tvtime getting tree-cleaned, I understand that Gentoo doesn't work with hired packagers. This isn't Ubuntu or RedHat Linux. Gentoo packagers don't maintain what they're not interested in. In the end it's another program that will end up in my ~/bin directory.
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 23/03/13 01:15, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (22 Mar 2013) # Fails with automake-1.12 (#424289) # Problems with the alsa patches (#403389) # Herd has not interest in it and needs a maintainer # Removal in a month unless a new maintainer steps up # and fix all the bugs # Alternatives: media-tv/me-tv, media-tv/mythtv media-tv/tvtime These aren't alternatives (they're only dealing with digital TV, not analog.) AFAIK, tvtime has no alternatives at all. If it goes, analog TV users can't watch TV anymore :-/
[gentoo-dev] Re: Last rites: media-tv/tvtime
On 24/03/13 02:12, Markos Chandras wrote: On 24 March 2013 00:02, Nikos Chantziaras rea...@gmail.com wrote: On 23/03/13 01:15, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (22 Mar 2013) # Fails with automake-1.12 (#424289) # Problems with the alsa patches (#403389) # Herd has not interest in it and needs a maintainer # Removal in a month unless a new maintainer steps up # and fix all the bugs # Alternatives: media-tv/me-tv, media-tv/mythtv media-tv/tvtime These aren't alternatives (they're only dealing with digital TV, not analog.) AFAIK, tvtime has no alternatives at all. If it goes, analog TV users can't watch TV anymore :-/ Nothing I can do. It has no maintainer and quite a few outstanding bugs. If people need it, they should probably move it to a local overlay. Shouldn't this be marked as maintainer-needed instead of dropping it?
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On 03/03/13 09:11, Alec Warner wrote: [...] My understanding of the summary is that the nvidia-driver Gentoo team only supports kernels that nvidia themselves (upstream) support. The Kernels 3.4 are not supported by upstream, so they are also not supported in Gentoo. [...] There is a fear as well, that the patches may damage cards (since the patches are not supported by the vendor.) Is there any communication with NVidia about this? They have a Linux developers forum: https://devtalk.nvidia.com/default/board/98/linux
[gentoo-dev] Re: RFC: new qt category
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 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. 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 they can cover these.
[gentoo-dev] Re: RFC: new qt category
On 20/01/13 10:39, Ben de Groot wrote: On 20 January 2013 15:59, Nikos Chantziaras rea...@gmail.com 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 they can cover these. 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 third-party extensions, such as qwt. There is no need for a separate category for those at this point in time. These are the essential modules: http://qt-project.org/wiki/Qt-Essentials-Modules and these are (or will be) the add-on modules: http://qt-project.org/wiki/Qt-Essentials-Modules So maybe qt-base and qt-addon?
[gentoo-dev] Re: eudev project announcement
On 15/12/12 06:16, Peter Stuge wrote: Richard Yao wrote: Where is development now? We have rewritten the build system and restored support for older kernels and verified compatibility as far back as Linux 2.6.31. We have tagged 1_beta1 and eudev is in the portage tree. A few lingering dependency issues exist, but we should have them ironed out shortly. Not yet something I care about. (That's fine.) I hope that eudev wants to do the respectable thing for any fork, ie. work hard to minimize the amount of wasted effort in both projects by sharing much code and bugfixes. I, on the other hand, hope that this isn't an indication of Gentoo not being interested in systemd. I'm eagerly awaiting the moment where I can emerge systemd and just have it working.
[gentoo-dev] Re: glibc-2.16 moving to ~arch
On 18/08/12 18:42, Mike Frysinger wrote: On Saturday 18 August 2012 02:01:12 Diego Elio Pettenò wrote: On Fri, Aug 17, 2012 at 10:44 PM, Mike Frysinger vap...@gentoo.org wrote: there's a trivial patch needed to make 1.49 work. forcing people to use 1.50 is purely the boost's maintainers choice. [...] there's a trivial patch long been available that you've refused to merge. so any errors here are of your choosing. So you pretend that people apply trivial patches because you're in a hurry to unmask something yes, the patch here is trivial. it removes 1 line of unused code and has fixed a lot of other packages. deflecting the argument to a flawed system of your own creation doesn't change it. if you're worried about gnutls breakage, you've only yourself to blame. -mike Maybe Diego loaded the gun, but you're the one pulling the trigger. In any event, the user is the one getting shot, not you nor Diego.
[gentoo-dev] Re: Fwd: Heads up for Qt5
On 28/07/12 08:22, Ben de Groot wrote: In preparation for that, we want to ask maintainers of all ebuilds in the tree with dependencies on Qt4, to make sure that they have the proper slot. Otherwise your package may pull in Qt5 while it may not in fact support it. This can be trouble if the application actually works with Qt5. It might depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code), needlessly pulling-in Qt4. Many applications simply build and run as-is and no code changes are necessary. So what would be the methodology of making sure a package has the proper slot?
[gentoo-dev] Re: Fwd: Heads up for Qt5
On 28/07/12 09:46, Davide Pesavento wrote: On Fri, Jul 27, 2012 at 11:27 PM, Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com wrote: [...] So what would be the methodology of making sure a package has the proper slot? Obviously you would need to make sure that the package actually does support Qt5. Then, as I see it, we could do either: || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 ) This is wrong because qt4 and qt5 are not binary compatible. or: qt4? ( x11-libs/qt-gui:4 ) qt5? ( x11-libs/qt-gui:5 ) This is the only alternative AFAICS. In that case, if Qt5 is installed, the application might depend on Qt4, but when building it, might link against Qt5.
[gentoo-dev] Re: Fwd: Heads up for Qt5
On 28/07/12 12:27, Ralph Sennhauser wrote: On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot yng...@gentoo.org wrote: We do not have (nor want to support) a qt useflag. We have opted for qt4 and qt5 useflags as the most straightforward and least confusing. Indeed, the flag qt has almost disappeared from the tree. Good to know. Why the different policies between the gtk and qt USE flags? This just looks inconsistent.
[gentoo-dev] Re: -Werror unwanted?
On 14/05/12 23:42, Chí-Thanh Christopher Nguyễn wrote: I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. Upstream does not need to take into account warnings produced by compilers for lesser known architectures, as explained above. These warnings could be harmless or introduce silent breakage. The user often can't tell. You can have breakage without any warnings being emitted, and you can have warnings that result in no breakage whatsoever. Furthermore, -Werror on Gentoo makes zero sense; portage will already produce a QA notice with warnings that have the potential to result in breakage. -Werror is not needed.
[gentoo-dev] Re: Making user patches globally available
On 27/04/12 17:15, Duncan wrote: Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: Having the package manager interact with an eclass function like epatch_user is ugly, and it's unnecessary since we can pull all of the pieces into the package manager in EAPI 5. Any eclasses that currently call epatch_user can have a conditional like this: if has $EAPI 0 1 2 3 4 ; then epatch_user else apply_user_patches_here fi But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. According to the source, calling it twice is perfectly safe.
[gentoo-dev] Re: Gentoostats, SoC 2011
On 23/08/11 00:20, Vikraman wrote: Hi all, Gentoostats[0] is a GSoC 2011 project to collect package statistics from gentoo machines. Please check it out. Bug reports and feature suggestions are welcome. To submit your stats, use the app-portage/gentoostats ebuild from betagarden overlay[1]. [0] https://soc.dev.gentoo.org/gentoostats/ [1] https://soc.dev.gentoo.org/gentoostats/about Is this project dead now?
[gentoo-dev] Re: New license: yEd Software License Agreement
On 27/04/12 20:38, Rich Freeman wrote: On Fri, Apr 27, 2012 at 11:33 AM, Amadeusz Żołnowskiaide...@gentoo.org wrote: And this is probably the case when user has to accept a license on the website. This is URL for zip archive of yEd-3.9.1: http://www.yworks.com/en/products_download.php?file=yEd-3.9.1.zip It directs to website with license text, check-box for accept and download button. If check-box is not set, following message is shown: In order to download yEd, it is necessary that you first accept the license terms. If check-box is set, client is redirected to the page with actual link to zip archive. It turns out the vendor is lying - you can download it fine without accepting the license from: http://www.yworks.com/products/yed/demo/yEd-3.9.1.zip No doubt the vendor WANTS users to accept the license first, but it is not necessary from a technical standpoint. Didn't the user already accept the license by putting it in ACCEPT_LICENSE? If not, portage will not download it.
[gentoo-dev] Re: About gcc-4.6 unmasking
On 22/02/12 00:38, Alec Warner wrote: On Tue, Feb 21, 2012 at 1:26 AM, Pacho Ramospa...@gentoo.org wrote: As looks like fixing old grub is far away because nobody know what is causing that issues, probably trying to get grub-1.99 ready for stabilization would be interesting (we will need to do that sooner or later anyway) Ubuntu has used grub2 for 3 years, I am considering working on making it stable for at least x86 / amd64. That's good news. I think Gentoo has a policy on not providing unmaintained software in the tree (they're getting tree cleaned.) Given that Grub 1 is both beta software (it got stuck at 0.97, never made it to 1.0) and unmaintained, stabilizing Grub 2 ASAP is the sanest thing you can do, since even though it's also beta software, it's at least maintained by upstream.
[gentoo-dev] Re: zlib breakage
On 09/24/2011 08:24 AM, Mike Frysinger wrote: On Friday, September 23, 2011 17:44:50 Nikos Chantziaras wrote: I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2 packages currently in the tree. The maintainer of zlib pushed those revisions with a patch that alters macro identifiers, making Gentoo's zlib incompatible with upstream. the defines in question are internal to zlib. packages relying on them are broken, plain and simple. Then fix *them*, not zlib. As a result, a lot of packages stopped building. the *only* code that broke was code that was copied out of the zlib tree and directly imported into other projects -- minizip. because the code was designed to be compiled linked as part of the zlib project, it uses internal zlib defines. projects copying the code into their own tree and not cleaning things up made a mistake. for many, this is a direct violation of Gentoo policy and they should be fixed to use the minizip code that zlib exports. for the rest that modify the code heavily, they should stop using the internal defines since their own code base doesn't support pre-ansi C compilers. Then why did you fix zlib instead of those bad packages? Bug reports for broken packages come in and then are being modified to fit Gentoo's zlib. and those fixes can be sent to the respective upstreams See above. Breaking compatibility with upstream zlib also means that non-portage software, the ones I install with ./configure --prefix=$HOME/usr make install, also won't build. send the fix to the upstream maintainer Maybe 5% of users know how to code. The rest doesn't. It's a mess right now and it just doesn't look right. The bug that deals with it was locked from public view: because you keep presenting the same flawed ideas and ignore the responses. in fact, all of the answers i posted above i already posted to the bug. You ignore the suggestions, which is the reason the same arguments pop up over and over again. The core issue is that ~arch is turning into a testing ground for upstreams rather than for Gentoo packaging. It's not nice to keep something in portage unmasked that is *known* to break packages, and *especially* if it's a beta release of an important base library (which zlib 1.2.5.1 certainly is). But you ignore that repeatedly. And this makes it very frustrating to communicate. ~arch is not for cleaning up upstream crap. ~arch is for testing packages that will later be marked stable.
[gentoo-dev] Re: zlib breakage
On 09/24/2011 10:07 AM, Mike Frysinger wrote: On Sat, Sep 24, 2011 at 02:43, Nikos Chantziaras wrote: On 09/24/2011 08:24 AM, Mike Frysinger wrote: the defines in question are internal to zlib. packages relying on them are broken, plain and simple. Then fix *them*, not zlib. they are being fixed already Then why did you fix zlib instead of those bad packages? i have no idea what you're talking about. they're both getting fixed. You are right. I will stop posting about this. I'm sorry for the noise I caused.
[gentoo-dev] zlib breakage
I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2 packages currently in the tree. The maintainer of zlib pushed those revisions with a patch that alters macro identifiers, making Gentoo's zlib incompatible with upstream. As a result, a lot of packages stopped building. Bug reports for broken packages come in and then are being modified to fit Gentoo's zlib. Breaking compatibility with upstream zlib also means that non-portage software, the ones I install with ./configure --prefix=$HOME/usr make install, also won't build. It's a mess right now and it just doesn't look right. The bug that deals with it was locked from public view: https://bugs.gentoo.org/show_bug.cgi?id=383179 Is there a plan for this, or will we have to live with what is essentially an incompatible Gentoo fork of zlib?
[gentoo-dev] Re: zlib breakage
On 09/24/2011 02:10 AM, Matt Turner wrote: On Fri, Sep 23, 2011 at 5:44 PM, Nikos Chantziarasrea...@arcor.de wrote: I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2 packages currently in the tree. The maintainer of zlib pushed those revisions with a patch that alters macro identifiers, making Gentoo's zlib incompatible with upstream. As a result, a lot of packages stopped building. Bug reports for broken packages come in and then are being modified to fit Gentoo's zlib. Breaking compatibility with upstream zlib also means that non-portage software, the ones I install with ./configure --prefix=$HOME/usr make install, also won't build. [...] It seemed to me like this was a silly problem from the outset. vapier did arguably the right thing, and if that means exposing some broken software, fine. We handle plenty of breakage worse than this, but I understand that it can be inconvenient. However, you completely lost any support when you said Yes, bad idea. But it's in my liberty to write code however I see fit. That just makes me want to slap you. I'll echo what vapier said in response: it's absolutely your prerogative to do whatever you want, but it's not our responsibility to make sure that it works in Gentoo. The code is perfectly valid. You cannot force people to follow your coding standards. If it's valid C code, it doesn't matter that it contradicts your personal preferences. It's not your code and you don't have a saying in it. What's next, banning software that indents code with tabs instead of spaces? It's a bad call. You've made plenty of those lately. This is just another one. IMO, you don't have the skills and insight to mess with this stuff. So when you try, breakage happens. I hope you retire soon. Are you kidding me? Grow up. This was just another episode of Vapier's hostile and arrogant behavior towards users. Every time someone comes up with a valid argument of why he's wrong, the final answer is don't care, I do what I please because I'm the dev and you're not. So my reply was the politest I could come up with without using the f-word.
[gentoo-dev] Re: zlib breakage
On 09/24/2011 02:40 AM, Alec Warner wrote: This was just another episode of Vapier's hostile and arrogant behavior towards users. Every time someone comes up with a valid argument of why he's wrong, the final answer is don't care, I do what I please because I'm the dev and you're not. So my reply was the politest I could come up with without using the f-word. I'm curious what you think the final answer should be? Taking other people's input and concerns into account would be OK. Knowing when you're wrong is a useful thing. Right now, zlib does the exact opposite of what should be done; Vapier changed zlib, and tries to fix the packages that break because of that change. The correct way to handle it is to let zlib be, and fix the packages that stopped working with zlib 1.2.5.1. Why is that the correct way? Because we don't know yet what upstream is planning. We don't know if they'll rename those macros. If they won't, then Gentoo is creating problems for itself. Packages that won't build out of the box on Gentoo's zlib will need to be patched. And you can't go to upstream of those packages with that patch, because it's none of their business. They know their code works against vanilla zlib, they have no reason to change it. If Gentoo decides to break a base library by making it incompatible with the upstream version, it's their own fault. If, on the other hand, you send a patch upstream that fixes compilation against vanilla zlib 1.2.5.1, they will most probably accept it, because it's a fix for a problem that is not distro-specific. If their software won't build against zlib 1.2.5.1, it's *their* problem, not ours. This is why I think the current solution is headed 180 degrees from the correct direction.
[gentoo-dev] Re: zlib breakage
On 09/24/2011 03:23 AM, Brian Harring wrote: [...] Right now, zlib does the exact opposite of what should be done; Vapier changed zlib, and tries to fix the packages that break because of that change. The correct way to handle it is to let zlib be, and fix the packages that stopped working with zlib 1.2.5.1. Why is that the correct way? Because we don't know yet what upstream is planning. We don't know if they'll rename those macros. If they won't, then Gentoo is creating problems for itself. Packages that won't build out of the box on Gentoo's zlib will need to be patched. And you can't go to upstream of those packages with that patch, because it's none of their business. They know their code works against vanilla zlib, they have no reason to change it. If Gentoo decides to break a base library by making it incompatible with the upstream version, it's their own fault. Incompatible with upstream version ? Why in quotes? Quick bug count, 12 packages (most of which are doing bad things in their header usage) went boom. 13 out of *608* packages. I reiterate, 6-!@#*ing-hundred-and-8. If that 13 became 50 I'd be viewing this differently, but half the time core pkg upgrades break that /alone/ (meaning upstream induced breakage). The packages that break with vanilla zlib 1.2.5.1 (like Lynx, which I fixed myself and sent upstream) are less than those that break with r1 and r2. So that argument doesn't hold. Also, you didn't rebuild the whole tree, so there's no way of knowing whether there's 13 packages that break or 130. The packages are broken; while vapier is mildly ahead of the curve, updating upstream is going in parallel. If vapier is such an expert, why did he use _Z_ as the prefix for those macros? It's a well known fact that identifiers beginning with an underscore and followed by a capital letter (or another underscore) are reserved in C and shouldn't be used. I strongly suspect you've got the unstated 13th, or hit some fallout thus why you're pushing on this as hard as you are. While that sucks for you, you'd have hit the same breakage once upstream releases the API change. Introducing something to the tree that is known to break packages means it's better to mask it. On top of that, zlib 1.2.5.1 is a beta version, which supports masking more strongly when you combine it with the breakage. All vapier is doing is frankly fixing the offending packages (which those patches then go upstream) so the upstream zlib change can be made w/out any fallout. If upstream accepts the changes, then that's good work. But not when doing that with an unmasked package. ~arch is for testing. We tested. Now we know it's borked, so mask it. When it looks ready, unmask it for another round of wide testing. By and large, this is good open source behaviour, and fits with the gentoo don't fuck with upstream's releases philosophy (which is aimed at avoiding the sort of hellacious backporting/monkey-patching debian/fedora are known for). But we *did* fuck with upstream's release.
[gentoo-dev] Stable and keyword requests by users
Can users file stable and keyword requests?
[gentoo-dev] Re: Gentoostats, SoC 2011
On 08/24/2011 01:48 PM, Patrick Lauer wrote: [...] If you sneakily add something to cron.daily by default you can get pretty nice coverage. But I guess anyone trying that in Gentooland will meet some rather unpleasant resistance :) emerge always asks me after a world update whether I want to auto clean packages with a yes/no prompt. I wouldn't be bad if once a month or whatever it would ask me whether I want to upload my stats. Gentoostats should probably become a runtime dep of Portage itself by default, but not used automatically.
[gentoo-dev] Re: a virtual advantage ?
On 06/26/2011 06:54 PM, Philip Webb wrote: Yesterday, I upgraded 'xorg-drivers' to the latest stable 1.10 then found upon rebooting that X failed to recognise the keyboard. Yes, it's happened before I was not surprised: I had to switch the machine off, reboot, login as root -- experience long ago made me avoid booting directly into a GUI -- recompile 'xf86-input-evdev', after which everything returned to normal. Yes, there's a warning after the new 'xorg-drivers' has been installed, but I wasn't sure exactly which pkg(s) needed remerging, so took the chance. Hmm? AFAIK, it gives you an actual command that will emerge all x11-drivers/*. So can you not be sure which pkgs need remerging?
[gentoo-dev] Re: a virtual advantage ?
On 06/26/2011 09:25 PM, Philip Webb wrote: 110626 Nikos Chantziaras wrote: On 06/26/2011 06:54 PM, Philip Webb wrote: Yesterday, I upgraded 'xorg-drivers' to the latest stable 1.10 then found upon rebooting that X failed to recognise the keyboard. Yes, it's happened before I was not surprised: I had to switch the machine off, reboot, login as root -- experience long ago made me avoid booting directly into a GUI -- recompile 'xf86-input-evdev', after which everything returned to normal. Yes, there's a warning after the new 'xorg-drivers' has been installed, but I wasn't sure exactly which pkg(s) needed remerging, so took the chance. it gives you an actual command that will emerge all x11-drivers/*. Yes, but it's not precise enough : root:534 xorg-server qlist -I -C x11-drivers/ x11-drivers/nvidia-drivers x11-drivers/xf86-input-evdev x11-drivers/xf86-video-nv x11-drivers/xf86-video-vesa The only one I needed to remerge is the 2nd in the list. But you don't know that for sure, and neither can portage (driver ABI changes are not something portage can track.) The only sure thing is to emerge them all.
[gentoo-dev] Re: Please migrate to git-2.eclass
On 06/25/2011 12:35 AM, Michał Górny wrote: Hello, git-2.eclass is in the tree for a while now, and there's still awful lot of packages using old deprecated git.eclass. I think I remember seeing deprecation warnings in the past when an ebuild was using a deprecated eclass (right at the beginning when the emerge starts.) Perhaps it would be a good idea to add one of those in git.eclass.
[gentoo-dev] About the Qt 4.7.3 bump
Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform.
[gentoo-dev] Re: About the Qt 4.7.3 bump
On 05/11/2011 02:11 PM, Markos Chandras wrote: On Wed, May 11, 2011 at 02:05:16PM +0300, Nikos Chantziaras wrote: Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. Sorry wrong link http://qt.nokia.com/developer/changes/changes-4.7.3/ No big changes but yet again is labeled as bug-fix release Yep, only for Symbian though. We already had the SSL certificate patch in 4.7.2-r1. I actually didn't look at the changelog itself, but at the Git diffs instead, where I saw that there were zero changes for non-Symbian (except the SSL patch). But now that it's in, it's in I guess. Nothing we can do about it :-)
[gentoo-dev] Re: About the Qt 4.7.3 bump
On 05/11/2011 03:32 PM, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 11.5.2011 13:05, Nikos Chantziaras napsal(a): Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. With this approach you could ask why we bump each kde release. As most of the apps does not change at all. I don't know :-P Avoiding needless bumps was, IIRC, one of the reasons Gentoo uses split ebuilds. Anyway, I mentioned this because in the past, at least one time, a version bump for Qt was omitted exactly because there were no changes.
[gentoo-dev] Re: Please enhance your USE descriptions!
On 03/29/2011 08:00 PM, Matt Turner wrote: On Tue, Mar 29, 2011 at 2:24 PM, justinj...@gentoo.org wrote: Hi, the descriptions of USE flags should explain what the USE is good for. In my opinion some thing like Enables foo intergration or Enables support for foo if it isn't totally clear what foo is, sucks!! There are many, many description which do not tell me as a user without googling what I could enable or not. That doesn't make gentoo very user friendly! So please enhance you descriptions!! Thanks justin One USE flag I remember in particular bothering me was gnome-extra/gnome-games' guile USE flag. The global description says guile - Adds support for the guile Scheme interpreter but this flag is actually determines whether a number of games are installed by this package. The most extreme one I remember is the gtk flag of GCC: Adds support for x11-libs/gtk+ (The GIMP Toolkit) Hmm, OK. So without that flag, GCC won't be able to build gtk? Or gimp? Or any software using gtk?
[gentoo-dev] Re: Last rites: www-client/chromium-bin
On 03/05/2011 04:41 AM, Rich Freeman wrote: On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexanderwi...@gentoo.org wrote: Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Clearly your definition of modern doesn't include my server... :) Just checked and the last build clocked in at 192 minutes. I need to make sure I have /var/tmp/portage symlinked back to a non-tmpfs location whenever I build it or else the system pretty-much dies from a lack of RAM. Then I'd say you have your tmpfs mount options configured wrongly :-) You should specify a maximum amount of RAM it should use. When it fill up, it then uses swap.
[gentoo-dev] Re: Last rites: www-client/chromium-bin
On 03/05/2011 12:00 PM, Nikos Chantziaras wrote: On 03/05/2011 04:41 AM, Rich Freeman wrote: On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexanderwi...@gentoo.org wrote: Anyway, compilation on a modern system shouldn't take more than an hour. ~15-20 minutes on a quad i5. Clearly your definition of modern doesn't include my server... :) Just checked and the last build clocked in at 192 minutes. I need to make sure I have /var/tmp/portage symlinked back to a non-tmpfs location whenever I build it or else the system pretty-much dies from a lack of RAM. Then I'd say you have your tmpfs mount options configured wrongly :-) You should specify a maximum amount of RAM it should use. When it fill up, it then uses swap. I take that back. It seems you can't do that with tmpfs :-(
[gentoo-dev] Re: libjpeg-turbo by default for ~arch users
On 02/28/2011 08:18 PM, Samuli Suominen wrote: libjpeg-turbo-1.1.0 final is out and in tree now, and everything in tree has been tested against it working. Unless any objections, i'll commit this minor change so ~arch users will get it by default now: [...] While you're at it, could you change HOMEPAGE to: http://libjpeg-turbo.virtualgl.org as that seems to be the proper homepage for the project.
[gentoo-dev] Re: libpng-1.5 smooth upgrade
On 02/13/2011 01:21 AM, Mike Frysinger wrote: On Friday, February 11, 2011 11:49:43 Samuli Suominen wrote: On 02/11/2011 06:38 PM, Paweł Hajdan, Jr. wrote: 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. [...] We have been discussing about removing libpng.pc, libpng.so and unversioned headers from the libpng 1.5.x package allowing it to install parallel with libpng 1.4.x. [...] i dont see any real advantages with SLOT-ed installs of libpng beyond ABI (i.e. what we're doing today with libpng-1.2.x and libpng-1.4.x). there are however plenty of downsides. patching packages in the tree is a huge hassle, you add hassle to end users who d/l random packages and try to build things themselves, and you make Gentoo non-standard wrt every other distro out there. best we follow what everyone else is already doing, and what upstream packages will have to ultimately do anyways -- fix their code to work with libpng-1.5 when the API has been forcibly broken. Or you can mask libpng-1.5 since most users aren't interested in having the latest version of something they won't be using directly. Wait until packages have been fixed upstream. Then 8 months or a year later, unmask it.
[gentoo-dev] Re: Suggestion: Portage should not mask packages globally, but only for some arches
On 02/02/2011 10:30 AM, Kacper Kowalik wrote:
W dniu 02.02.2011 08:59, Nikos Chantziaras pisze:
It seems that KDE 4.6 is still hard-masked for x86 and amd64 because
it's waiting for ppc and ppc64 keywords. I believe it would be
beneficial for people if they wouldn't have to wait for arches that
don't affect them at all.
[...]
I don't know what gave you the idea that ppc* has anything to do with
masking/unmasking of KDE-4.6. Just 2 facts:
1) you can unmask anything by using /etc/portage/package.unmask,
therefore nothing can ever hold *you* back
This is about all users in general. Not just me :-) If putting stuff
in /etc/portage/package.unmask should be considered the recommended
solution for this, then we wouldn't need a masking system in the first
place. When something is hard-masked, it tells the user we're not
considering it safe or working yet.
2) arches already have independent package.mask files, see
${PORTDIR}/profiles/arch/powerpc/package.mask for an example.
It seems they aren't used though. I mainly posted this because of the
discussion on this page:
http://blog.tampakrap.gr/kde-sc-4-6-0-in-gentoo
It seems devs have can't modify arch/powerpc/package.mask on their own?
If not, this looks like a problem, delaying packages for all arches.
[gentoo-dev] Re: Suggestion: Portage should not mask packages globally, but only for some arches
On 02/02/2011 11:01 PM, Christian Faulhammer wrote: Hi, Nikos Chantziarasrea...@arcor.de: On 02/02/2011 10:30 AM, Kacper Kowalik wrote: W dniu 02.02.2011 08:59, Nikos Chantziaras pisze: It seems that KDE 4.6 is still hard-masked for x86 and amd64 because it's waiting for ppc and ppc64 keywords. I believe it would be beneficial for people if they wouldn't have to wait for arches that don't affect them at all. [...] Don't be so impatient...Debian users wait two years for a new major version of KDE. I know. Though Debian is not a rolling-release distro, like Gentoo is. Don't get me wrong though; it's not that I'm impatient. I already unmasked it here. I brought this up simply because it seemed like a needless inefficiency that the popular arches get stalled by the less popular ones. That's all really, so hopefully no one will read more into it than there is.
[gentoo-dev] Suggestion: Portage should not mask packages globally, but only for some arches
It seems that KDE 4.6 is still hard-masked for x86 and amd64 because it's waiting for ppc and ppc64 keywords. I believe it would be beneficial for people if they wouldn't have to wait for arches that don't affect them at all. It seems better if the packages can be unmasked for x86 and amd64 and only kept hard-masked for ppc/ppc64 while they wait for keywords. Otherwise, all arches will feel the effect of the slowest one without there being a need for this.
[gentoo-dev] Re: MULTI_ABI support addition to main tree portage
On 01/29/2011 07:03 PM, Pacho Ramos wrote: I would like to know what is blocking this from landing main tree in the near future, as I reviewed: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html and looks like there wasn't major problems (at least commented in this thread) Thanks a lot for the info :-) Heh, me too. Been waiting for this one like crazy. The emul- packages never worked reliably here.
[gentoo-dev] Re: Rail Model font for coders
On 01/20/2011 11:14 AM, hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com wrote: There is a font for coders called Rail Model, please include it with Linux distributions: http://code.google.com/p/railmodel/downloads/detail?name=RailModelFont.zipcan=2q= If this is a joke, I don't get it :-P I was curious about what this font is about, and its description is: Rail Model Font is a Pro Bono (for the public good) Hare Krishna Ritvik Universal Religion Project for spiritual / philosophical reasons and thus any full or part technical or non-technical opensource resources and licenses used of Local Religion (e.g. Christianity, Islam, Judaism, Buddhism, Jainism) organisations and individuals and/or commercial organisation and individuals and/or other non-profit organisations and individuals, they are considered donations to His Divine Grace A C Bhaktivedanata Swami Prabhupada, Founder Acharya Permanent Sole Initiator of the Hare Krishna Movement the permanent person, not the estate, state, representative/s or representative organisation/s etc. Wait, what... huh?
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/23/2010 09:32 AM, Mike Frysinger wrote: On Tuesday, November 23, 2010 01:36:15 Graham Murray wrote: Mike Frysingervap...@gentoo.org writes: well, not quite. the way we agreed in the past was to not revbump the masked package, but once it was unmasked, we revbump it just once at that point. Is there somewhere which tells users when there are upgrades to toolchain packages which are not revbumped once they have been unmasked and in ~arch? if they arent revbumped, then the changes dont matter to you This isn't always the case though, due to developer mistakes. Sometimes when doing emerge -e system, there are changes in /etc files that affect runtime behavior rather than build behavior. And it seems to happen quite often. This is with non-masked packages though. It's the reason I do emerge -e system quite often (every 3 months or so); runtime fixes are applied by devs without revbumps.
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/21/2010 08:49 PM, Ryan Hill wrote: On Sun, 21 Nov 2010 13:54:19 +0200 Alex Alexanderwi...@gentoo.org wrote: On Sun, Nov 21, 2010 at 01:47:57AM -0600, Ryan Hill wrote: On Sun, 21 Nov 2010 17:35:18 +1300 Alistair Bushali_b...@gentoo.org wrote: We don't do revbumps on masked toolchain packages. Why not? Yeah why not? do you inform users of this? Users unmasking toolchain packages need to be paying close attention to what's going on behind the scenes. They're in the tree for people who know what they're doing to test. Even unmasked, toolchain revbumps are expensive and we do them only when absolutely necessary. If you pushed important fixes to gcc, you should revbump it before unmasking it. If you skip the revbump, I'm sure most users will miss this. There's virtually no expense to a revbump in this case. You just asked every user currently using gcc-4.5.1 to rebuild it, isn't a revbump the best, safest way to do that? Since everyone and their dog seems to have unmasked it already I'll make an exception. :-P I don't know about the others, but I unmasked it in order to test it against non-portage compiles. Just because people unmask it doesn't necessarily mean they switched their system gcc profile to it. The problem should be obvious; those people will then see that it got unmasked, so will assume it's ready for testing in-tree packages with it and switch their gcc profile. But without a revbump...
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/21/2010 12:46 AM, Ryan Hill wrote: I'm unmasking sys-devel/gcc-4.5.1 tomorrow. I'd like to recommend everyone who has already unmasked it to rebuild it now as there has been some important patches added recently (see ChangeLog). revbump?
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/21/2010 04:57 AM, Ryan Hill wrote: On Sun, 21 Nov 2010 01:38:23 +0200 Nikos Chantziarasrea...@arcor.de wrote: On 11/21/2010 12:46 AM, Ryan Hill wrote: I'm unmasking sys-devel/gcc-4.5.1 tomorrow. I'd like to recommend everyone who has already unmasked it to rebuild it now as there has been some important patches added recently (see ChangeLog). revbump? We don't do revbumps on masked toolchain packages. Why not?
[gentoo-dev] Re: fat binaries
On 11/15/2010 01:30 AM, Diego Elio Pettenò wrote: Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto: I have a package (sci-libs/mpir) whose configure supports building of fat binaries with both x86 and amd64 assembler in the binary. Oh the heck are they implemented? If they are FatELF, no they shouldn't be used, ever, full stop. In most cases, this sounds fishy and almost a hack deemed to failure so my default vote would be do not expose this functionality to the user. It's not FatELF. It's pretty much what the Intel compiler does, but in this case it's done by hand; the binary includes several versions of the code. Which version is executed depends on the CPU detected at runtime. Has nothing to do with the FatELF brain damage :-)
[gentoo-dev] Should I file three bug reports or just one?
I've updated to dev-libs/openssl-1.0.0a today, and it tells me: Old versions of installed libraries were detected on your system. In order to avoid breaking packages that depend on these old libs, the libraries are not being removed. You need to run revdep-rebuild in order to remove these old dependencies. If you do not have this helper program, simply emerge the 'gentoolkit' package. # revdep-rebuild --library libcrypto.so.0.9.8 # revdep-rebuild --library libssl.so.0.9.8 This won't work correctly for these three packages: app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-gtklibs app-emulation/vmware-workstation because revdep-rebuild wants to emerge them repeatedly, since they're binary packages. How do I report this? Do I file one bug per package, or do I file only one for dev-libs/openssl where I list the three above packages?
[gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 07/04/2010 05:29 PM, Lars Wendler wrote: Hi list, now that openrc has no active upstram anymore [1] what shall we do? To be honest I was really looking forward for openrc/baselayout-2 finally becoming stable in Gentoo but this seems to be quite implausible now that openrc has no upstream anymore. If there's anyone out there who would volunteer to maintain openrc, please step up now or else I fear we must abandon openrc which would be very sad. How about switching to something that has a very active upstream? http://bugs.gentoo.org/150190
[gentoo-dev] Re: [gentoo-dev-announce] debug USE flag misuse
On 07/01/2010 11:00 PM, Ryan Hill wrote: [...] The way to control compiler flags in Gentoo is CFLAGS. That is true. However, there's a problem; you can control package options of individual packages with USE flags, but you can't control compilation switches of individual packages with CFLAGS. This will naturally make people feel like using USE flags to modify compilation options is a good idea. Surely, one has to sympathize with this mindset even though it's a wrong thing to do.
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 06/28/2010 10:51 AM, Ciaran McCreesh wrote: On Mon, 28 Jun 2010 10:44:54 +0300 Samuli Suominenssuomi...@gentoo.org wrote: You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. And we can't be held hostage by few packages (marginal cases), that's why we have function called $(no-as-needed) in flag-o-matic.eclass to disable the behavior for these packages. Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. --as-needed is a flag that tries to solve a specific (and very annoying) problem. It deserves a bit of special treatment. It's not a ricer flag :-)
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 01:47 PM, Enrico Weigelt wrote: * Nikos Chantziarasrea...@arcor.de schrieb: Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken. In my personal experience, most times a warning comes it, the code *is* broken (but *might* work in most situations). That's the key to it: most times. Granted, without -Wall (or any other options that tweaks the default warning level) we can be very sure that the warning is the result of a mistake by the developer. But with -Wall, many warnings are totally not interesting (unused parameter) and some even try to outsmart the programmer even though he/she knows better (taking address of variable declared register). In that last example, fixing it would even be wrong when you consider the optimizer and the fuzzy meaning of register which the compiler is totally free to ignore.
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 03:23 PM, Harald van Dijk wrote:
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote:
On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
* Nikos Chantziarasrea...@arcor.de schrieb:
Did it actually occur to anyone that warnings are not errors?
You can have them for correct code. A warning means you might
want to look at the code to check whether there's some real
error there. It doesn't mean the code is broken.
In my personal experience, most times a warning comes it, the
code *is* broken (but *might* work in most situations).
That's the key to it: most times. Granted, without -Wall (or any
other options that tweaks the default warning level) we can be very
sure that the warning is the result of a mistake by the developer.
But with -Wall, many warnings are totally not interesting (unused
parameter) and some even try to outsmart the programmer even
though he/she knows better (taking address of variable declared
register). In that last example, fixing it would even be wrong
when you consider the optimizer and the fuzzy meaning of register
which the compiler is totally free to ignore.
The compiler is not totally free to ignore the register keyword.
Both the C and the C++ standards require that the compiler complain
when taking the address of a register variable. Other compilers will
issue a hard error for it. Fixing the code to not declare the
variable as register would be the correct thing to do.
No, it would not be the correct thing to do, because of the following.
(This is part of a discussion between me and someone quite smarter than
me, who explained the issue in detail.)
The basic issue is that the code takes the address of the variable in
question in expressions passed as parameters to certain function calls.
These function calls all happen to be in-linable functions, and it
happens that in each function, the address operator is always canceled
out by a '*' dereference operator - in other words, we have '*p', which
the compiler can turn into just plain 'p' when the calls are in-lined,
eliminating the need to actually take the address of 'p'.
A compiler is always free to ignore 'register' declarations *anyway*,
even if enregistration is possible. Therefore a warning that it's not
possible to obey 'register' is unnecessary, because it's explicit in the
language definition that 'register' is not binding. It simply is not
possible for an ignored 'register' attribute to cause unexpected
behavior. Warnings really should only be generated for situations where
it is likely that the programmer expects different behavior than the
compiler will deliver; in the case of an ignored 'register' attribute,
the programmer is *required* to expect that the attribute might be
ignored, so a warning to this effect is superfluous.
Now, I understand why they generate the warning - it's because the
compiler believes that the program code itself makes enregistration
impossible, not because the compiler has chosen for optimization
purposes to ignore the 'register' request. However, as we'll see
shortly, the program code doesn't truly make enregistration impossible;
it is merely impossible in some interpretations of the code. Therefore
we really are back to the compiler choosing to ignore the 'register'
request due to its own optimization decisions; the 'register' request is
made impossible far downstream of the actual decisions that the compiler
makes (which have to do with in-line vs out-of-line calls), but it
really is compiler decisions that make it impossible, not the inherent
structure of the code.
When a function is in-lined, the compiler is not required to generate
the same code it would generate for the most general case of the same
function call, as long as the meaning is the same.
For example, suppose we have some code that contains a call to a
function like so:
a = myFunc(a + 7, 3);
In the general out-of-line case, the compiler must generate some
machine-code instructions like this:
push #3
mov [a], d0
add #7, d0
push d0
call #myFunc
mov d0, [a]
The compiler doesn't have access to the inner workings of myFunc, so it
must generate the appropriate code for the generic interface to an
external function.
Now, suppose the function is defined like so:
int myFunc(int a, int b) { return a - 6; }
and further suppose that the compiler decides to in-line this function.
In-lining means the compiler will generate the code that implements the
function directly in the caller; there will be no call to an external
linkage point. This means the compiler can implement the linkage to the
function with a custom one-off interface for this particular invocation
- every in-line invocation can be customized to the exact context where
it appears. So, for example, if we call myFunc right now and registers
d1 and d2 happens to be available, we can put the parameters in d1 and
d2, and the generated function will refer to those registers for the
parameters rather
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 08:14 PM, Harald van Dijk wrote: On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote: On 06/27/2010 03:23 PM, Harald van Dijk wrote: The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. No, it would not be the correct thing to do, because of the following. (This is part of a discussion between me and someone quite smarter than me, who explained the issue in detail.) [snip] That explanation seems to be written by someone who does not know that taking the address of a register variable is simply not allowed. It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard: The register specifier [...] specifies that the named variable has automatic storage duration (3.7.3). A variable declared without a storage-class-specifier at block scope or declared as a function parameter has automatic storage duration by default. A register specifier is a hint to the implementation that the variable so declared will be heavily used. [ Note: the hint can be ignored and in most implementations it will be ignored if the address of the variable is taken. This use is deprecated (see D.4). — end note ] OK, long read, but the the conclusion is that fixing the code to not declare the variable as register would be the correct thing to do it *not* the correct thing to do. The correct thing to do is to ignore the warning, which is not possible if warnings are turned into errors. And which is not possible if the warning is a hard error in the first place. You also mentioned that other compilers will issue a hard error for it. That sounds rather strange, and I wonder which compilers that might be; someone should file a bug report against them ;) Well, let's start with gcc; that's quite an important one for Gentoo... That code compiles just fine. I don't know of any GCC version that issues an error for this rather than just a warning.
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/27/2010 09:10 PM, dev-ran...@mail.ru wrote: On Sun, Jun 27, 2010 at 08:48:25PM +0300, Nikos Chantziaras wrote: ... It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard: ... Not in C. ISO/IEC 9899:1999 (aka C99), section 6.7.1, note 101: The implementation may treat any register declaration simply as an auto declaration. However, whether or not addressable storage is actually used, the address of any part of an object declared with storage-class specifier register cannot be computed, either explicitly (by use of the unary operator as discussed in 6.5.3.2) or implicitly (by converting an array name to a pointer as discussed in 6.3.2.1). Thus, the only operator that can be applied to an array declared with storage-class specifier register is sizeof. Wasn't aware of the difference here. But anyway, the warning is issued by GCC for C++ too, not just C.
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/26/2010 10:39 PM, Enrico Weigelt wrote: * Petteri Rätybetelge...@gentoo.org schrieb: There should be useful stuff here: http://video.fosdem.org/2010/devrooms/distributions/How_to_be_a_good_upstream.ogv [...[ #2 One point i don't agree is the dont add -Werror rule. actually, i'm thinking of making -Wall and -Werror mandatory. if some package doenst build fine, it's simply broken. period. That's the most hilarious thing I've read in ages. xD
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On 06/26/2010 11:12 PM, Ciaran McCreesh wrote: On Sat, 26 Jun 2010 21:57:33 +0200 Enrico Weigeltweig...@metux.de wrote: Uhm. No. Certain compilers will give you warnings for f(g(a), g(b)) if you -Wall. Warn on what exactly ? That f's arguments are evaluated in an unspecified order. Which compilers do that ? For all you know, gcc 4.7. New gcc releases regularly issue lots of new warnings for correct code, particularly with -Wall. Other compilers are even worse. Did it actually occur to anyone that warnings are not errors? You can have them for correct code. A warning means you might want to look at the code to check whether there's some real error there. It doesn't mean the code is broken.
[gentoo-dev] Re: Tone in Gentoo
On 06/16/2010 08:43 AM, Jeroen Roovers wrote: On Wed, 16 Jun 2010 05:33:27 +0200 Sebastian Pippingsp...@gentoo.org wrote: Tone is currently not a strength of Gentoo. As I have heard there are people not joining Gentoo because the atmosphere in Gentoo is lacking respect and empathy. That's a conclusion first, then a premise? I have searched a few places for rules on tone, looking at the Gentoo Social Contract [1], the Code of Conduct [2] and the Philosophy of Gentoo [3]. In a way the Code of Conduct defines what good and bad behavior is. The term Acceptable behaviour may make sense as a counterpart to Unacceptable behaviour but feels like what you can get away with to me anyhow. - How come tone is so rough when we actually meant to be a friendly community? Has it always been that way? What are you referring to? forums.g.o? bugs.g.o? #gentoo? Who, where, when, what channel, thread? - With these Code of Conduct rules in place how come DevRel is not publicly reminding of these rules where necessary? When did you point this out to devrel? [... snip ...] Those replies are a good example of the rude behavior the poster is referring to. The replies consisted of sarcastic questions in you're an idiot style. The only thing they do is trying to trigger a hostile response from the poster. Very good example of tone in Gentoo.
[gentoo-dev] Re: Tone in Gentoo
On 06/16/2010 09:18 PM, Alec Warner wrote: On Wed, Jun 16, 2010 at 8:36 AM, Nikos Chantziarasrea...@arcor.de wrote: On 06/16/2010 08:43 AM, Jeroen Roovers wrote: On Wed, 16 Jun 2010 05:33:27 +0200 Sebastian Pippingsp...@gentoo.orgwrote: Tone is currently not a strength of Gentoo. As I have heard there are people not joining Gentoo because the atmosphere in Gentoo is lacking respect and empathy. That's a conclusion first, then a premise? I have searched a few places for rules on tone, looking at the Gentoo Social Contract [1], the Code of Conduct [2] and the Philosophy of Gentoo [3]. In a way the Code of Conduct defines what good and bad behavior is. The term Acceptable behaviour may make sense as a counterpart to Unacceptable behaviour but feels like what you can get away with to me anyhow. - How come tone is so rough when we actually meant to be a friendly community? Has it always been that way? What are you referring to? forums.g.o? bugs.g.o? #gentoo? Who, where, when, what channel, thread? - With these Code of Conduct rules in place how come DevRel is not publicly reminding of these rules where necessary? When did you point this out to devrel? [... snip ...] Those replies are a good example of the rude behavior the poster is referring to. The replies consisted of sarcastic questions in you're an idiot style. The only thing they do is trying to trigger a hostile response from the poster. Don't read so much between Jer's words. The tone of the reply could certainly use improvement but I do not think his questions were meant to be sarcastic at all or imply the poster was an idiot. The only thing Jer was trying to 'trigger' is a response with some evidence of 'bad tone' so we can continue the discussion. I don't think a hostile reply was intended at all. It's the overall tone that isn't nice. Usually, when someone posts something, lots of people reply with sarcastic-looking you're wrong, prove it or gtfo replies. Even if the OP is wrong, that's not the way to tell him that. If you want to be constructive, you should include the reasons of why you thing he's wrong in your reply, or ask him to elaborate more. Just look at some threads where lots of developers were fighting each other and track down the first post that triggered the flame; it's usually of the proof or gtfo sort. It's bound to annoy the poster and make him get hostile even if his original intentions were anything but hostile.
[gentoo-dev] qt4.eclass vs qt4-r2.eclass
There are two eclasses for Qt: qt4.eclass and qt4-r2.eclass Which one should I inherit?
[gentoo-dev] Re: qt4.eclass vs qt4-r2.eclass
On 04/19/2010 12:32 AM, Theo Chatzimichos wrote: On Monday 19 April 2010 00:10:15 Nikos Chantziaras wrote: There are two eclasses for Qt: qt4.eclass and qt4-r2.eclass Which one should I inherit? We have a guide for writing Qt4 ebuilds Tom and Theo, Yep, I should have RTFM'ed more :P Thanks for the pointers.
[gentoo-dev] Re: MinGW for windows - creating dlls
On 03/17/2010 03:38 PM, Mansour Al Akeel wrote: Hello all, I am not sure if this is the best list to ask, but I will ask here since it's related to development and cross compilation. I have setup a 32 bit chroot environment to be able to cross develop for windows. I followed this guide: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml You should be better off using this instead: http://www.nongnu.org/mingw-cross-env
[gentoo-dev] Re: MinGW for windows - creating dlls
On 03/25/2010 07:43 PM, Mike Frysinger wrote: On Thursday 25 March 2010 12:57:21 Nikos Chantziaras wrote: On 03/17/2010 03:38 PM, Mansour Al Akeel wrote: I am not sure if this is the best list to ask, but I will ask here since it's related to development and cross compilation. I have setup a 32 bit chroot environment to be able to cross develop for windows. I followed this guide: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml You should be better off using this instead: http://www.nongnu.org/mingw-cross-env mingw + dlls + etc... works just fine under crossdev/Gentoo -mike It's just a bit difficult to work with. It needs a lot of effort to set everything up. I recommend mingw-cross-env because it simply works out of the box and you can even compile stuff like Qt and build Windows Qt applications without any effort. 64-bit Windows apps also easy to build. So all things considered, it's the better solution. crossdev of course has other virtues and is universal. It's really just the MS Windows special case that makes mingw-cross-env worth looking at, since it's specialized for just this, while crossdev is a generic solution. Btw, does anyone intent to put an ebuild of mingw-cross-env in Portage? :P
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/19/2010 08:26 PM, Alec Warner wrote: On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziarasrea...@arcor.de wrote: You guys always make easy decisions so complicated. :P Masking a package is not complicated. Yes, that's why all the heated debates about Python 3 exist, because it's all so simple. It *is* simple, but you don't want it to be.
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/19/2010 10:57 AM, Ciaran McCreesh wrote: On Fri, 19 Mar 2010 03:54:28 -0500 Dalerdalek1...@gmail.com wrote: Ciaran McCreesh wrote: On Thu, 18 Mar 2010 23:17:17 +0100 Ben de Grootyng...@gentoo.org wrote: Because it is extremely useless to the great majority of users. Most packages in the tree are useless to the great majority of users. Which is why most users don't install everything. I have about 1000 packages installed here. The packages installed are either something I use or a dependency of something I use. What exactly is this being installed for again? If nothing depends on it, there is no need to have it. It's being installed because it's a dependency of something you use. Replace Python with any other library and we wouldn't be having this discussion. It's weird that we have this discussion, that's true. Why don't you guys simply do what you did before when Qt3 was still in the tree? Qt3 applications depended on x11-libs/qt:3, Qt4 ones on x11-libs/qt:4 (before the Qt4 ebuild split). It seems very obvious and straightforward that the same applies here. And if a package offers both Python 2 and Python 3 compatibility, it should depend on whatever the upstream of that package considers best. Also, we had a qt and qt4 USE flag before. Why not python and python3 flags? That's an additional way ebuilds can choose deps. You guys always make easy decisions so complicated. :P
[gentoo-dev] Re: news regarding mysql 5.1 incomplete
On 02/25/2010 02:44 AM, Robin H. Johnson wrote: On Wed, Feb 24, 2010 at 01:45:31PM +0100, Hanno Böck wrote: Just noticed yesterday an issue with the upgrade documentation in the news regarding mysql 5.1 and revdep-rebuild. It suggests running # revdep-rebuild --library libmysqlclient.so.15 but this is not enough. mysql has more than one library and not all applications link against the main lib. On a server system (which uses as-needed), I encountered two packages (apr- util and mysql-python) only linking against libmysqlclient_r.so. So at least when mysql 5.1 gets stable, we should correct this. News item updated now. It looks like qt-sql might have been linking to libmysqlclient_r too. I didn't catch it myself as I used the @preserved-rebuild support in newer Portage. Doesn't revdep-rebuild support regular expressions? You might want to use one to catch all linkages.
[gentoo-dev] Re: News item: MySQL 5.1 bump
On 02/16/2010 12:12 AM, Robin H. Johnson wrote: On Mon, Feb 15, 2010 at 11:51:59PM +0200, Nikos Chantziaras wrote: On 02/15/2010 11:21 PM, Robin H. Johnson wrote: This is my last blocker for getting MySQL 5.1 series into ~arch status. itle: MySQL 5.1 unmasking Author: Robin H. Johnsonrobb...@gentoo.rog Content-Type: text/plain Posted: 2010-02-15 Revision: 1 News-Item-Format: 1.0 Display-If-Installed:dev-db/mysql-5.1 The 5.1 series of MySQL is going to be unmasked at the same time as the release of this news item. When upgrading from an older major version, you will be required to rebuild everything linked to the libmysqlclient.so.15. I assume older major version means 4.x versions and older, not 5.0, right? The following transitions required rebuilds: 3.23 - 4.0 4.0 - 4.1 4.1 - 5.0 5.0 - 5.1 5.1 - 5.[45] don't require anything at present, but 5.x - 6.0 may. Major version in the context of upstream MySQL is the first TWO digits. This should be mentioned in the news item since what MySQL thinks are major version numbers disagrees with the common sense of: Major.minor.patch Most people will interpret older major version as being MySQL 4.x and older.
[gentoo-dev] Re: News item: MySQL 5.1 bump
On 02/15/2010 11:21 PM, Robin H. Johnson wrote: This is my last blocker for getting MySQL 5.1 series into ~arch status. itle: MySQL 5.1 unmasking Author: Robin H. Johnsonrobb...@gentoo.rog Content-Type: text/plain Posted: 2010-02-15 Revision: 1 News-Item-Format: 1.0 Display-If-Installed:dev-db/mysql-5.1 The 5.1 series of MySQL is going to be unmasked at the same time as the release of this news item. When upgrading from an older major version, you will be required to rebuild everything linked to the libmysqlclient.so.15. I assume older major version means 4.x versions and older, not 5.0, right?
[gentoo-dev] X vs gtk USE flags
Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools.
[gentoo-dev] Re: X vs gtk USE flags
On 02/08/2010 01:36 PM, AllenJB wrote: On 08/02/10 11:15, Nikos Chantziaras wrote: Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. [...] I don't see that either system makes particularly more sense than the other. The only situation that comes immediately to mind is: Under the current system, if packages add or remove support for multiple toolkits, the changes are trivial, but under your system it would invoke shuffling use flags around (which could easily affect dependencies in other packages). It would also not be immediately clear which toolkits support has been added/removed under the proposed system (since a package would go from, for example, having use flags gtk kde to just X). If it would be problematic for a package to switch to X then of course it might be better to leave it as-is. But most of the time, the programs in question only state gtk or fltk in them, even though Gtk is not optional at all. A perfect example here is media-video/xvattr. If you don't set the gtk USE flag, then you don't get the graphical tool at all, only the command line tool. So in other words what I propose a bit more sanity, not some iron claw that hangs above the developer's heads. The situation right now is mixed anyway. Many packages use X, many others gtk or fltk. The sanity part in this is simple that a general rule of USE flags is: If it's *not* optional, don't make it a USE flag. In the case of xvattr for example, Gtk is not optional if you want the X utility.
