Re: [gentoo-dev] BOINC needs maintainer
Am Mittwoch, 17. Februar 2016, 15:20:56 CET schrieb Justin Lecher (jlec): > currently BOINC supposed to be maintained by the science team, but we > are not really carrying about it. Is there anyone around whole likes to > take this over? I have a sci-misc/boinc-7.6 ebuild in my overlay "seden" (via layman). Feel free to use it. Works fine, at least on my system. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] BOINC needs maintainer
Am Donnerstag, 18. Februar 2016, 09:37:28 CET schrieb David Seifert: > On Do, 2016-02-18 at 09:29 +0100, Sven Eden wrote: > > Am Mittwoch, 17. Februar 2016, 15:20:56 CET schrieb Justin Lecher > > > > (jlec): > > > currently BOINC supposed to be maintained by the science team, but > > > we > > > are not really carrying about it. Is there anyone around whole > > > likes to > > > take this over? > > > > I have a sci-misc/boinc-7.6 ebuild in my overlay "seden" (via > > layman). > > > > Feel free to use it. Works fine, at least on my system. > > > > Sven, would you be willing to maintain it as a proxy maintainer? > Sure. I am using it several times a week, and I am watching their repo, so I normally learn about new versions rather fast. And since the client_release tags now sport 7.6 subversions, I just pushed boinc-7.6.25.ebuild. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bzipped manpages
Am Dienstag, 10. Januar 2017, 13:36:15 CET schrieb Jan Stary: > > You arguing that 40MB is nothing on modern systems (which, by the way is > > not exactly true, talking about embedded ones). > > Can you gove an example of an embedded system with manpages? My Raspberry Pi 3. ;-) Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bzipped manpages
Am Donnerstag, 12. Januar 2017, 19:08:05 CET schrieb Walter Dnes: > On Wed, Jan 11, 2017 at 05:15:25PM +0100, Jan Stary wrote > > > On Jan 11 13:34:09, sven.e...@gmx.de wrote: > > > Am Dienstag, 10. Januar 2017, 13:36:15 CET schrieb Jan Stary: > > > > > You arguing that 40MB is nothing on modern systems (which, by the > > > > > way is > > > > > not exactly true, talking about embedded ones). > > > > > > > > Can you gove an example of an embedded system with manpages? > > > > > > My Raspberry Pi 3. ;-) > > > > How is that an embedded system? > > It's a full blown linux installation. > > Not every "full blown linux installation" has a multi-terabyte hard > drive attached. There are small laptops with SSDs instead of spinning > disks. And my Raspberry PI 3 has less CPU power, less RAM and less storage space than my goddam android cell phone. ;-) Btw.: Even "embedded experts" wholeheartedly agree that they disagree what "embedded" actually is. But I do think SoCs actually *do* qualify, at least to some degree... signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Montag, 17. Dezember 2012, 11:11:38 schrieb Tomáš Chvátal: > Hi lads, > lately I am having bit of problems from getting relevant debug info from > users. > > Since we already have splitdebug for quite time (and I suppose quite > few of us are using it) how about making it to default profiles > default enabled and add -g to default cflags. Currently it is only > enabled in the developer profile. > > This results in 2 gb data in /usr/lib/debug for my system which is not > (snip) Hello Tomáš, on my system I have set up everything with splitdebug enabled. My CFLAGS use - march=native, -O2 and -ggdb. And this is the result: (Yes, I have a dedictated partition for that.) ~ $ LC_ALL=C df -h /usr/lib/debug/. Filesystem Size Used Avail Use% Mounted on /dev/sda10 25G 22G 1.7G 93% /usr/lib64/debug This is a full KDE-4.9.4 system with a total of 1,807 packages installed. I guess the regular user would end up somewhere between your 2G and my 22G. But I bet it will be slightly more likely my end, wouldn't it? Sincerly Sven -- http://pwxlib.sourceforge.net signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Montag, 17. Dezember 2012, 11:47:24 schrieb Tomáš Chvátal: > 2012/12/17 Sven Eden : > > Hello Tomáš, > > > > on my system I have set up everything with splitdebug enabled. My CFLAGS > > use - march=native, -O2 and -ggdb. > > And this is the result: (Yes, I have a dedictated partition for that.) > > > > ~ $ LC_ALL=C df -h /usr/lib/debug/. > > > > Filesystem Size Used Avail Use% Mounted on > > /dev/sda10 25G 22G 1.7G 93% /usr/lib64/debug > > > > This is a full KDE-4.9.4 system with a total > > of 1,807 packages installed. > > > > I guess the regular user would end up somewhere between your 2G and my > > 22G. > > But I bet it will be slightly more likely my end, wouldn't it? > > Well your "problem" is using -ggdb, that adds ton of stuff that makes > things large exponencialy in most cases, i bet you would be around 5-6 > on -g usage. First, I do not want to argue. I just want to state, and prove for at least _my_ machine, that this is not true. Second, my whole system is compiled using gcc-4.7.2. This means, that the results below might differ greatly from a setting where stable gcc-4.5.4 is used for the whole. But this doesn't matter, because gcc-4.7.* will, eventually, become the stable and current gcc. (Unless it is skipped, of course.) Third, "_My_ Machine" means: My setting, hardware, USE-Flags and CFLAGS. For this the assumption -ggdb would add about 300% in size is "a bit" exsessive. Background: The option "-g" produces debugging information in the operating systems native format, already fit for GDB. -ggdb simply uses the most expressive format. Both, as I believe, result in "DWARF-2" format on my system. At least I get no difference whether I specify "-g -gdwarf-2" or "-ggdb". GDB extensions are added if possible. It seems to me, judging the results of the tests below, that those "gdb- extensions" are already enabled by default (gcc-4.7.2). I have not found any information on that regarding DWARF-2, but at least http://gcc.gnu.org/onlinedocs/gccint/DBX-Options.html states that DEFAULT_GDB_EXTENSIONS (for DBX output) is always turned on by default. Maybe that's true for DWARF-2 as well? Below are the resulting sizes of all .debug files having been generated first using "-ggdb", then using "-g" in make.conf CFLAGS. The tested packages are: 1) kde-base/kate (C++ Code, heavy library usage) and 2) dev-libs/lzo (ANSI C) I believe both are, regarding their code base, far enough apart for building up a test case. It is _not_ representative, of course. 1) --- kde-base/kate - Compiled with -ggdb in CFLAGS: # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum" 32652140 Compiled with -g in CFLAGS: # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum" 32652140 Result: No size change at all. 2) --- dev-libs/lzo - Compiled with -ggdb in CFLAGS: # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum" 558664 Compiled with -g in CFLAGS: # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum" 558304 Result: A difference of 260 bytes or 0.06%. Far away from the assumed 300%. Conclusion: I do not doubt that -ggdb adds size. It does. And maybe, if I did an emerge -e @world would reduce the size used on my system between 30% and 40%. But not about 66% like assumed. However, even if it where "around 5-6" G, it would be thrice the initial assumption of 2G. And that's the whole point. Sincerly Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Montag, 17. Dezember 2012, 11:48:12 schrieb Walter Dnes:
> On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
>
> > 1) --- kde-base/kate
> > -
> >
> > Compiled with -ggdb in CFLAGS:
> > # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do
> >
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 32652140
> >
> > Compiled with -g in CFLAGS:
> > # sum=0; for file in $(equery f kde-base/kate | grep "\.debug") ; do
> >
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 32652140
> >
> > Result: No size change at all.
> >
> >
> > 2) --- dev-libs/lzo
> > -
> >
> > Compiled with -ggdb in CFLAGS:
> > # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do
> >
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 558664
> >
> > Compiled with -g in CFLAGS:
> > # sum=0; for file in $(equery f dev-libs/lzo | grep "\.debug") ; do
> >
> > xSize=$(stat -c "%s" $file) ; sum=$((sum+xSize)) ; done ; echo "$sum"
> > 558304
> >
> >
> > Result: A difference of 260 bytes or 0.06%. Far away from the assumed
> > 300%.
> >
> >
> > Conclusion:
> > I do not doubt that -ggdb adds size. It does. And maybe, if I did an
> > emerge -e @world would reduce the size used on my system between 30% and
> > 40%. But not about 66% like assumed.
> >
> >
> > However, even if it where "around 5-6" G, it would be thrice the initial
> > assumption of 2G. And that's the whole point.
>
> On my 32-bit machines I have...
>
> FLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
> -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS="${CFLAGS}"
>
> See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
> include "-fno-unwind-tables -fno-asynchronous-unwind-tables". Would I
> have to rebuild system and world without...
>
> -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
>
> ...to have debug data available?
No, you haven't, if you have compiled everything with "-g" or "-ggdb".
According to the web page you linked, the DWARF-2 tables are then written into
the .debug files. Without -g/-ggdb, they are stripped and no longer available
for debugging.
So according to your CFLAGS, you'd have to rebuild everything, yes, but a
simple "-g" would do.
Oh, and "splitdebug" in "FEATURES" would be a good idea, too! ;)
Sincerly
Sven
--
http://pwxlib.sourceforge.net
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Dienstag, 18. Dezember 2012, 12:43:55 schrieb Marcin Mirosław:
> W dniu 18.12.2012 12:13, Sven Eden pisze:
(snip, because this has nothing to do with the previous discussion.)
> >> On my 32-bit machines I have...
> >>
> >> FLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
> >> -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS="${CFLAGS}"
> >>
> >> See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
> >>
> >> include "-fno-unwind-tables -fno-asynchronous-unwind-tables". Would I
> >> have to rebuild system and world without...
> >>
> >> -fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
> >>
> >> ...to have debug data available?
> >
> > No, you haven't, if you have compiled everything with "-g" or "-ggdb".
> >
> > According to the web page you linked, the DWARF-2 tables are then written
> > into the .debug files. Without -g/-ggdb, they are stripped and no longer
> > available for debugging.
> >
> > So according to your CFLAGS, you'd have to rebuild everything, yes, but a
> > simple "-g" would do.
> >
> > Oh, and "splitdebug" in "FEATURES" would be a good idea, too! ;)
>
> Hi Sven!
> Meseems you are not right, please look at it:
> $ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
>
> |grep "unwind\|-g"
>
> [ 1e2] -grecord-gcc-switches
> [ 1f8] -ggdb
> [ 202] -frecord-gcc-switches
> $ size /usr/bin/sqlite3
>textdata bss dec hex filename
> 445454124 328 48997bf65 /usr/bin/sqlite3
>
>
> And with -fno-unwind...
> $ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
>
> |grep "unwind\|-g"
>
> [ 1e2] -grecord-gcc-switches
> [ 1f8] -ggdb
> [ 202] -frecord-gcc-switches
> [ 218] -fno-unwind-tables
> [ 22b] -fno-asynchronous-unwind-tables
> $ size /usr/bin/sqlite3
>textdata bss dec hex filename
> 427134124 328 47165b83d /usr/bin/sqlite3
>
> As you can see I have splitdebug turned on.
> Marcin
Hi Marcin,
I am not right with what? All I did was interpreting a quoted link. And what
is this supposed to mean? So /usr/bin/sqlite3 looses size. Yes. This goes
along with the quoted link. But did you compare the current size of
/usr/lib64/debug/usr/bin/sqlite3.debug before and after?
Sorry for any inconvenience, but I assure you, I have absolutly no idea what
you intent to show.
Sincerly
Sven
--
http://pwxlib.sourceforge.net
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] tools-portage herd unmaintained packages
Am Dienstag, 25. Dezember 2012, 15:09:21 schrieb Pacho Ramos: > El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió: > > All: > > > > The following packages in the tools-portage herd are effectively > > unmaintained packages and need a maintainer to step up and maintain them. > > > > app-portage/ufed > > > > What did occur finally with them? Hi all, what has happened to app-portage/ufed? I could take care of it. I am no official dev, but maybe via a proxy maintainership? Would that be possible? SIncerly Sven -- http://pwxlib.sourceforge.net signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs due lack of time
Am Samstag, 16. Februar 2013, 14:08:06 schrieb Pacho Ramos: > Due pva lack of time the following packages are now up for grabs: > app-emulation/e-uae > app-emulation/uae AFAIK both are long dead. The current actively developed uae variant is PUAE, but I'd say it is not ready for a wider audience right now. It syncs regularly with WinUAE, but its GUIs are in a bad shape. The configuration documentation is ... well ... lacking at best. The PUAE maintainer, GnoStiC, has only a Mac to develop on. All linux stuff is currently done by me. And I am busy cleaning up code and getting to a state where I can bring the front-ends back into a working state. PUAE: https://github.com/GnoStiC/PUAE My cleanup-branch: https://github.com/Yamakuzure/PUAE Note: We cross-merge. regularly. Most people use an Amiga emulator for some nostalgic gaming only anyway. Therefore it might be a good idea to add fs-uae (gamerlay-stable) to the tree, if there is any need for it. However, if there is a need to keep uae and e-uae, I could proxy maintain both. The code base I am working on is the same after all. And I have plenty of Amiga stuff lying around to test p-uae (Dragons Megademo anyone? ;)) anyway. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
Am Mittwoch, 25. September 2013, 11:05:24 schrieb Ian Stakenvicius: > On 25/09/13 10:51 AM, Rich Freeman wrote: > > On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius > > > > wrote: > >> William, I think what Tom was mentioning here is that he thinks > >> a one-sentence answering the "Why" would be a good idea to have > >> in the news item, so users that don't have a clue on all of these > >> sep-/usr issues will get an idea of why the change is being > >> made. > > > > How about something like: Due to many upstream changes properly > > supporting a separate /usr without an initramfs has become > > increasingly difficult - despite all our efforts it already breaks > > in some exotic configurations, and this is a trend likely to grow > > worse. > > > > Rich > > How about changing "[properly] supporting a separate /usr without an > initramfs" to "supporting a system with /usr missing at boot time" ? > More generic, indicates the actual problem better. Otherwise sounds > great to me. Maybe some links to articles that explain *why* the so called "UsrMerge" was needed/done would be a good idea. I have a feeling that many people (still) think a separate /usr partition would be something they needed badly, and that it is all Lennards fault (and his wrecked systemd project) that a separate /usr /suddenly/ needs an initrd. In fact, only really rare cornercases (*) actually *need* a separate /usr partition, and none can't live with an initrd. The most prominent sites would be, I believe, https://fedoraproject.org/wiki/Features/UsrMove/ and http://http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ with references to http://http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ ? Don't understand me wrong, please. I have always worked with a separate /usr partition, and was extremely pissed off when, all of a sudden, I was told that I'd need an initrd to support it further. My thoughts where a bit like: "/But why? I need, that! It is highly useful, because because ... erm.. (no idea...) ... Because I've *always* used it that way!/" In the end I found absolutely no reason for _not_ merging /usr into / and did it. Result: No initrd and one partition less to take care of. I have never had any disadvantage by that merge over a year ago on all my machines. And then I took a closer look at all servers (debian, ranging from Sarge over Lenny to Squeeze) at my workplace, and none ever even had a separate /usr. Cheers Sven (*): Like /usr over NFS signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
Am Mittwoch, 25. September 2013, 11:39:20 schrieb Ian Stakenvicius: > On 25/09/13 11:27 AM, Sven Eden wrote: > > Am Mittwoch, 25. September 2013, 11:05:24 schrieb Ian > > > > Stakenvicius: > >> On 25/09/13 10:51 AM, Rich Freeman wrote: > >>> On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius > >>> > >>> > >>> wrote: > >>>> William, I think what Tom was mentioning here is that he > >>>> thinks a one-sentence answering the "Why" would be a good > >>>> idea to have in the news item, so users that don't have a > >>>> clue on all of these sep-/usr issues will get an idea of why > >>>> the change is being made. > >>> > >>> How about something like: Due to many upstream changes > >>> properly supporting a separate /usr without an initramfs has > >>> become increasingly difficult - despite all our efforts it > >>> already breaks in some exotic configurations, and this is a > >>> trend likely to grow worse. > >>> > >>> Rich > >> > >> How about changing "[properly] supporting a separate /usr without > >> an initramfs" to "supporting a system with /usr missing at boot > >> time" ? More generic, indicates the actual problem better. > >> Otherwise sounds great to me. > > > > Maybe some links to articles that explain *why* the so called > > "UsrMerge" was needed/done would be a good idea. > > This isn't UsrMerge tho. I think bring that discussion into the news > item would probably be going too far beyond its intended scope. Yes, of course. It is just that the mentioned upstream changes are because of the merge, meaning boot relevant stuff is installed in /usr instead of /. > > [ Snip the rest ] > > Documentation suggesting a separate /usr isn't necessary (or rather, > probably, is only necessary for certain things, like /usr-on-NFS or > LVM-without-ROOT or crypto-/usr ) does make sense in general but > probably that discussion would be better done in the Handbook (or > linked to by the Handbook) rather than in the news item. Yes, maybe the references about why upstream did/does change belongs on a wiki page or something like that. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
Am Samstag, 12. Oktober 2013, 08:45:15 schrieb Pacho Ramos: > Due pebenito retirement: > dev-libs/ustr I've never heard of that package before, but the description sounded interesting. So I went to their site and read what it is about, and it looks like a project that seems to be ideal for my work. And while I'll be at introducing ustr into our existing projects (about 90% are pure C99 on debian servers), I could proxy maintain it. The integration will need me to have it usable, valid and stable anyway. ;) Honestly, there are at least three big projects at my work that suffer in many places from the problems ustr solves. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
Am Samstag, 2. November 2013, 16:03:30 schrieb Michał Górny: > Dnia 2013-11-02, o godz. 14:51:26 > > Tom Wijsman napisał(a): > > On Sat, 02 Nov 2013 09:16:45 -0400 > > > > "Anthony G. Basile" wrote: > > > This is a followup to a discussion on IRC yesterday regarding > > > breakage that's occurring to catalyst builds as a result of the > > > recent move from dev-python/python-exec to dev-lang/python-exec. > > > > This has been happening to users as well, for example: > > > > http://forums.gentoo.org/viewtopic-t-973998.html > > http://forums.gentoo.org/viewtopic-t-974412.html > > From what I heard, most of people get this working through a plain: > > emerge -Du @world > > If someone is really reluctant to world updates, it is enough to > upgrade dev-python/python-exec to 1.*: > > emerge -1v dev-python/python-exec I tried the world upgrade (yes, with --deep and with "--with-bdeps y" also) to no avail. "emerge -1av --nodeps $(qdepends -q -N -C -Q python-exec)" just wanted to rebuild app-portage/smart-live-rebuild - needless to say this didn't solve anything. Even unmerging python-exec didn't help. The blocker output was the following: = Conflict: 1 block !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-lang/python-exec:0 (dev-lang/python-exec-0.::gentoo, ebuild scheduled for merge) pulled in by dev-lang/python-exec:0[python_targets_jython2_5(-)?, python_targets_jython2_7(-)?, python_targets_pypy2_0(-)?, python_targets_python3_2(-)?, python_targets_python3_3(-)?, python_targets_python2_6(-)?, python_targets_python2_7(-)?, - python_single_target_jython2_5(-), -python_single_target_jython2_7(-), - python_single_target_pypy2_0(-), -python_single_target_python3_2(-), - python_single_target_python3_3(-), -python_single_target_python2_6(-), - python_single_target_python2_7(-)] required by (dev-python/python- exec-1.1::gentoo, ebuild scheduled for merge) (dev-lang/python-exec-0.3.1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by dev-python/PyQt4-4.10.2 # required by kde-misc/synaptiks-0.8.1-r4 # required by @kde_sed # required by @selected # required by @world (argument) =dev-lang/python-exec-0. ** = PyQt4 and synaptiks were only the messengers, btw. dev-lang/python-exec-0. has the Targets pypy2_0 and python3_3 which dev- lang/python-exec-0.3.1 does not have. But both dev-python/python-exec-1.1 and dev-python/python-exec-1.2 want a dev-lang/python-exec:0 with the same target setting. Btw. Why does dev-python/python-exec:2 has a dependency on dev-python/python- exec:0 ? Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
Am Montag, 4. November 2013, 10:01:18 schrieb Sven Eden: > Btw. Why does dev-python/python-exec:2 has a dependency on > dev-python/python- exec:0 ? Sorry, I meant: "Why does dev-python/python-exec:2 has a dependency on dev- lang/python- exec:0 ?" of course. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
Am Montag, 4. November 2013, 12:55:45 schrieben Sie: > Dnia 2013-11-04, o godz. 10:01:18 > > Sven Eden napisał(a): > > PyQt4 and synaptiks were only the messengers, btw. > > dev-lang/python-exec-0. has the Targets pypy2_0 and python3_3 which > > dev- lang/python-exec-0.3.1 does not have. But both > > dev-python/python-exec-1.1 and dev-python/python-exec-1.2 want a > > dev-lang/python-exec:0 with the same target setting. > > Did you play with package.accept_keywords? This looks like another > attempt at trying to unmask flags through changing keywords > on packages... No. $ wc -l /etc/portage/package.accept_keywords 0 /etc/portage/package.accept_keywords But you brought me on the right track, thank you very much! I had an entry dev-lang/python-exec -python_targets_python3_3 In /etc/portage/profile/package.use.mask which was needed to be able to install media-gfx/blender. It's been a while, I do not even remember why this was necessary... Sorry for the fuss! > > > Btw. Why does dev-python/python-exec:2 has a dependency on > > dev-python/python- exec:0 ? > > To avoid mistakenly depcleaning it too early, with old packages that > depended on dev-python/python-exec (with no slot). Ah, okay. Thank you very much for the clarification! signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to support C++11 in libraries?
Am Mittwoch, 18. Dezember 2013, 08:54:47 schrieb Michał Górny: > This raises the following question: how do we want to do it? I see two > possibilities: > > a) adding USE=c++11 and USE-deps to all the packages in question, > > b) doing the switch via synchronous version bump and matching > dependencies. > (snip) > > What are your thoughts? I have already switched to C++11 on all my projects ages ago. It offers a lot, and the incompatibilities are rare at best. C++11 is the current standard with the next being worked on already. What is the rationale for staying with C++03 or (worse) C++98 in the first place? Nothing is gained. Only the need to fix what becomes broken. ( And a lot breakage can occur from using something like #include Instead of the C++11 #include ... Breakages that are trivial to fix ... ) And as C++11 is stricter in many places, I consider a program failing to compile with -std=c++11 to be broken and buggy per se, and needing to be fixed asap anyway. (I consider any C program failing to compile with g++ broken as well, allthough the cases might be more complex.) So I'd go the reverse way. Make CXXFLAGS="-std=c++11" the default, and only override this for packages that do fishy stuff and break with it. But of course this must be tested thoroughly first. I have some extra time to spare in the first three weeks of january, and I've already planned to do an 'emerge -e @world' with c++11 as a global default anyway. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to support C++11 in libraries?
Am Donnerstag, 19. Dezember 2013, 16:23:08 schrieb Jan Kundrát: > On Thursday, 19 December 2013 16:00:13 CEST, Ian Stakenvicius wrote: > > A change in profiles? 14.0/* adds that to the default CXXFLAGS in > > base, new stage3's etc are all rolled with this. We recommend > > migration to 14.0 profile and have a check somewhere about > > "-std=c++11" missing from CXXFLAGS in case it's overridden in > > make.conf, so users put it in place? > > Before you invest any more time in this, please understand that C++98 and > C++11 are source-incompatible. There is no way to expect that a package > builds fine when you throw -std=c++11 on it. And even if you patched them > all, you are breaking an unknown number of 3rd party software over which > you have exactly zero control. No. If you do something against the standard that is working due to lack of control when compiling with -std=c++98, then your source code is severly broken. Most developers will use C++03 (plus tr1) anyway, won't they? And no, the languages are _not_ "source-incompatible". That would be a scandal! But if you have your C++98/03 code, and do what most developers do and let your console be flooded with warnings you ignore, you must not be surprised, if the compilation fails when you decide to throw "-std=c++11 -Wall -Wextra -Wpedantic -fsanitize=address -fsanitize=thread" with gcc 4.8.2 at it. There is absolutely no reason to expect a compilation to fail with C++11, if it went well with C++03 and "-Wall -Wextra -pedantic". If you try to outsmart your compiler, it will get it's revenge very soon and very hard. And according to [1] it goes even further: Quote: > If you use C++11 then in general you can combine C++11 code built with GCC > 4.X and C++03 code built with any GCC, but there is not the same guarantee > that you can combine with C++11 code built with GCC 4.Y or GCC 4.Z, because > the C++11 features are not all stable yet (e.g. for GCC 4.9 I'm about to add > a new virtual function to a base class in .) This is why C++11 > support is still labelled "experimental", because it would be worse to claim > it's stable and then have to break the ABI. So basically C++11 <-> C++03 is no problem at all (unless you *export* certain symbols [2]), but combining C++11 from different gcc versions is nowhere guaranteed to work. Cheers Sven [1] : https://lwn.net/Articles/552831/ [2] : http://gcc.gnu.org/wiki/Cxx11AbiCompatibility signature.asc Description: This is a digitally signed message part.
