Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
W dniu 2012-04-14 13:02, Pacho Ramos pisze: > Hello > > From time to time I see old bug reports that are still wrongly > opened and referring to old packages no longer in the tree. Would > be possible to add a way to periodically check for bugs referring > in summary to obsolete packages and, then, allow us to have a > cleaner bug list? Hi, what about siutation package was removed from tree. After sometime other maintainer wants to put this package to the tree again, shouldn't fix those bugs before doing this? Marcin
Re: [gentoo-dev] About adding a way to check for bugs referring to no longer existing packages in the tree
W dniu 2012-04-15 18:10, Samuli Suominen napisał(a): When package foobar gets removed from Portage, the remaining bugs affecting foobar gets closed with resolution WONTFIX/OBSOLETE/FIXED depending on type of the bug. When package foobar gets readded to Portage, the maintainer needs to check also for closed bugs. That's how it is now, and the workflow wouldn't change with this proposal. So you are right, but irrelevant to the /topic in hand. Thanks for clarification, i was afraid sentence "cleaner bug list" means remove/make unavailable in future. Marcin
Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree
W dniu 16.05.2016 o 10:45, Dirkjan Ochtman pisze: > On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec wrote: >> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now >> modular, and using the portage plugin system. The system is not yet >> fully plug and play. Those changes will take place in the stage3 >> re-writes. > > Thanks for working on this, it sounds great! But it doesn't sounds so great for every every user;) https://bugs.gentoo.org/show_bug.cgi?id=583252
Re: [gentoo-dev] Defaulting for debug information in profiles
W dniu 18.12.2012 12:13, Sven Eden pisze:
> 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! ;)
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
Re: [gentoo-dev] Defaulting for debug information in profiles
W dniu 18.12.2012 13:03, Sven Eden pisze:
> 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,
Hi Sven!
> 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?
My fault, I didn't respond below correct paragraph. I was thinking about:
>>> 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.
I tried to show that without "-g/-ggdb" gcc generates DWARF-2 tables and
strip doesn't remove it from binaries. I pasted examples with sqlite3
compiles with "-ggdb" but I'm getting the same results without debug
flags. When I add -fno-unwind-tables and -fno-asynchronous-unwind-tables
I'm getting smaller size of "text" (and all binary also).
And I agree with all you write about recompiling system with "-g" and
splitdebug.
Hmm, now I think you was thinking only about adding debug information to
Walters' gentoo and didn't want to talk about growing eh_frame...
> Sorry for any inconvenience, but I assure you, I have absolutly no idea what
> you intent to show.
I hope I throwed some light on my earlier answer.
regards,
Marcin
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
W dniu 2014-03-31 19:35, Toralf Förster pisze: > On 03/31/2014 01:15 PM, Alex Xu wrote: >> On 31/03/14 03:36 AM, Dirkjan Ochtman wrote: >>> So, I'm interested... How widely used is the HPN patch set? Are there >>> any good indications that it doesn't negatively impact security? > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292932 >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693424 > >> https://lists.fedoraproject.org/pipermail/devel/2007-July/105570.html > >> https://aur.archlinux.org/packages/openssh-hpn/ > >> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/162253 > > > Those bug reports are good arguments to have HPN as a feature in openssh. > > And most of them now many years old and still open. > > That's an argument to rethink if HPN should be activated quietly. According to last problem with openssl and +tls-heartbeat I'd like to see less features enabled by default. USE="-*" isn't the best solution;) Marcin
Re: [gentoo-dev] RFC: using .xz for doc/man/info compression
W dniu 11.05.2014 23:27, Pacho Ramos pisze: > El dom, 11-05-2014 a las 19:46 +0200, Michał Górny escribió: >> Hello, developers. >> >> I'd like to raise the following item for discussion: making .xz >> the default compressor used by portage for documentation, man pages >> and info files. That is, the equivalent of: >> >> PORTAGE_COMPRESS=xz >> >> in make.globals. >> >> Rationale: xz-utils is quite widespread nowadays and it is a part >> of @system set. It can achieve better compression ratio than bzip2, >> and faster decompression at the same time. >> >> I have confirmed that both sys-apps/man and sys-apps/man-db can >> handle .xz compressed man pages, and sys-apps/texinfo can handle .xz >> compressed info pages. Major text editors and pagers support .xz >> alike .bz2 (i.e. usually they support both or neither :)). >> >> The additional question is: what preset to use? To help discussing >> this, I'd like to quote the tables from 'man xz': >> >> Preset DictSize CompCPU CompMem DecMem >>-0 256 KiB 03 MiB1 MiB >>-1 1 MiB 19 MiB2 MiB >>-2 2 MiB 2 17 MiB3 MiB >>-3 4 MiB 3 32 MiB5 MiB >>-4 4 MiB 4 48 MiB5 MiB >>-5 8 MiB 5 94 MiB9 MiB >>-6 8 MiB 6 94 MiB9 MiB >>-7 16 MiB 6 186 MiB 17 MiB >>-8 32 MiB 6 370 MiB 33 MiB >>-9 64 MiB 6 674 MiB 65 MiB >> >> Preset DictSize CompCPU CompMem DecMem >> -0e 256 KiB 84 MiB1 MiB >> -1e 1 MiB 8 13 MiB2 MiB >> -2e 2 MiB 8 25 MiB3 MiB >> -3e 4 MiB 7 48 MiB5 MiB >> -4e 4 MiB 8 48 MiB5 MiB >> -5e 8 MiB 7 94 MiB9 MiB >> -6e 8 MiB 8 94 MiB9 MiB >> -7e 16 MiB 8 186 MiB 17 MiB >> -8e 32 MiB 8 370 MiB 33 MiB >> -9e 64 MiB 8 674 MiB 65 MiB >> >> I'd like to note here that increasing dictionary size over file size >> does not improve compression. However, the options involved in CompCPU >> may. >> >> Depending on the expected amount of complexity, I'd either go for: >> >> 1) -6e (or -6, the default) -- max CompCPU, reasonable use of memory, >> and dictionary larger than most (or all?) documents that are going to >> be compressed, >> >> 2) -Ne with minimal 'N' for CompCPU==8 and DictSize > filesize -- still >> max compression ratio while keeping lowest memory requirements possible. >> >> Your thoughts? >> > > Per: > https://bugs.gentoo.org/show_bug.cgi?id=372653 > > Looks like bzip2 was still better for small files :/ Hi! I did test on medium sized man file (bash): $ man -a -w bash /usr/share/man/man1/bash.1.bz2 $ stat --printf=%s\\n /usr/share/man/man1/bash.1.bz2 62606 $ time man -c -P /bin/cat bash >/dev/null real0m0.248s user0m0.316s sys 0m0.012s $ time man -c -P /bin/cat bash >/dev/null real0m0.252s user0m0.324s sys 0m0.016s $ time man -c -P /bin/cat bash >/dev/null real0m0.249s user0m0.320s sys 0m0.012s Now I recompress using xz -6 and next: $ stat --printf=%s\\n /usr/share/man/man1/bash.1.xz 66628 $ time man -c -P /bin/cat bash >/dev/null real0m0.234s user0m0.304s sys 0m0.004s $ time man -c -P /bin/cat bash >/dev/null real0m0.244s user0m0.288s sys 0m0.024s $ time man -c -P /bin/cat bash >/dev/null real0m0.239s user0m0.308s sys 0m0.012s And with file compressed using '-6e': $ stat --printf=%s\\n /usr/share/man/man1/bash.1.xz 66700 $ time man -c -P /bin/cat bash >/dev/null real0m0.233s user0m0.292s sys 0m0.016s $ time man -c -P /bin/cat bash >/dev/null real0m0.234s user0m0.300s sys 0m0.008s Imho there is no real advantages to change current compressor for man files. Regards
