Re: [gentoo-dev] Re: Gentoo Bugday
On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka wrote: > On 27/02/2013 11:39, Pavlos Ratis wrote: >> >> Hello everyone, >> >> I would like to announce you a new try to 'revive' the Bugday event. >> As most of the open source projects have their own bugday, I thought >> it would be great to have this event back. For those who don't know, >> its a monthly 24h event that takes place in #gentoo-bugs. Its goal is >> to close as many bugs as possible . You don't have to be a Gentoo >> expert to participate. Those days are a great way to start joining the >> Gentoo community, improving Bugzilla's and Wiki's quality and looking >> for a mentor to begin the recruitment process. The upcoming bugday >> event is this Saturday and I hope this event will continue in the next >> months. I have created a wiki page for the event[1] and I added some >> guidelines. I have also created a related blog post about the >> event[2]. >> >> I have listed some maintainer-wanted and maintainer-need bugs and >> Bugzilla admins also re-enabled the bugday flag. I would like to ask >> the Gentoo project teams to start using this flag to their bugs that >> think that are good to start and enable the flag at them. It would be >> great to a have a really big list with 'good to start' bugs. >> >> It's the first time after a long time that this event will take place, >> so I am looking forward to your participation both users and >> developers and your feedback. >> >> [1] http://wiki.gentoo.org/wiki/Bugday >> [2] http://blog.dastergon.gr/gentoo-bugday/ >> >> Thanks, >> Pavlos >> >> > > Hi, > > Thanks for your work, it will be great to see Bugday happening again. > > What about the old bugday webpage[1]? It seems a bit broken at the moment, > but may be useful to get running again. > Is the code available somewhere? Who has access to the login in the footer? antarus@flycatcher /var/svnroot/bugday $ grep svnbugday /etc/group svnbugday:x:4005:gurligebis It is there, but only gurligebis has r/w. We should migrate it to git.o.g.o if possible (all the secrets should be in a separate infra-owned repo, basically.) I have no idea who has access to login. > > Best regards, > Michael > > [1] http://bugday.gentoo.org/ > >
[gentoo-dev] Re: Evaluating a new malloc()
On Tue, 26 Feb 2013 08:33:44 -0500 Richard Yao wrote: > With that said, what do people think? I think I see a lot of our upstream bug reports being closed as invalid/unsupported. I think that if upstreams wanted to use jemalloc they would just do so. If they don't then obviously what they have is working fine for them. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
[gentoo-dev] Re: Gentoo Bugday
On 27/02/2013 11:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos Hi, Thanks for your work, it will be great to see Bugday happening again. What about the old bugday webpage[1]? It seems a bit broken at the moment, but may be useful to get running again. Is the code available somewhere? Who has access to the login in the footer? Best regards, Michael [1] http://bugday.gentoo.org/
Re: [gentoo-dev] Gentoo Bugday
On 2/26/13 4:39 PM, Pavlos Ratis wrote: > I would like to announce you a new try to 'revive' the Bugday event. This is excellent! Thank you for your work on this. > I have listed some maintainer-wanted and maintainer-need bugs and > Bugzilla admins also re-enabled the bugday flag. I would like to ask > the Gentoo project teams to start using this flag to their bugs that > think that are good to start and enable the flag at them. It would be > great to a have a really big list with 'good to start' bugs. I'm going to look over chromium@ bugs, but consider also arch testing bugs (STABLEREQ) relevant - just avoid people making too much noise. 1-2 success reports are enough, and the more testing we can get before actually stabilizing, the better. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Gentoo Bugday
Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that takes place in #gentoo-bugs. Its goal is to close as many bugs as possible . You don't have to be a Gentoo expert to participate. Those days are a great way to start joining the Gentoo community, improving Bugzilla's and Wiki's quality and looking for a mentor to begin the recruitment process. The upcoming bugday event is this Saturday and I hope this event will continue in the next months. I have created a wiki page for the event[1] and I added some guidelines. I have also created a related blog post about the event[2]. I have listed some maintainer-wanted and maintainer-need bugs and Bugzilla admins also re-enabled the bugday flag. I would like to ask the Gentoo project teams to start using this flag to their bugs that think that are good to start and enable the flag at them. It would be great to a have a really big list with 'good to start' bugs. It's the first time after a long time that this event will take place, so I am looking forward to your participation both users and developers and your feedback. [1] http://wiki.gentoo.org/wiki/Bugday [2] http://blog.dastergon.gr/gentoo-bugday/ Thanks, Pavlos
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 11:10:09AM -0800, Matt Turner wrote: > On Tue, Feb 26, 2013 at 8:35 AM, Alec Warner wrote: > > In terms of 'following Gentoo policy.' We encourage packages to be as > > close to upstream as possible. I cannot fathom why when you basically > > find a performance bug in malloc, you start a thread on the list about > > replacing it; as opposed to filing a bug against glibc or emailing the > > glibc lists and asking them about it. > > We may not understand it, but it does completely fit ryao's typical > modus operandi. I must second this unfortunately. William pgpfAXRvTdHzU.pgp Description: PGP signature
[gentoo-dev] Last rites: app-emacs/yow
# Ulrich Müller (26 Feb 2013) # Declared as obsolete by upstream. Use fortune.el with # the zippy file from games-misc/fortune-mod instead. # Masked for removal in 30 days, bug #459358. app-emacs/yow
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 1:37 PM, Maciej Mrozowski wrote: > On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: >> On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner wrote: >> > I see a *HUGE* reason. glibc ships with ptmalloc. If you think they >> > should use jemalloc, talk to them. Don't just do it in Gentoo. >> >> Certainly I think it would be far more productive to talk to the glibc >> maintainers first. > > You mean productive like below? ;) > > http://sourceware.org/bugzilla/show_bug.cgi?id=11261 > > Ulrich Drepper: > "Stop reopening. There is a solution for people who are stupid enough to > create too many threads. No implementation will be perfect for everyone. The > glibc implementation is tuned for reasonable programs and will run much faster > than any other I tested." Drepper is no longer around. Upstream glibc is really friendly now, probably in an attempt to throw off the image you rightly had. > Merge of jemalloc upstream is likely never going to happen. Indeed, but not because of Drepper, but rather because GNU projects require copyright assignment for non-trivial contributions and I highly doubt that the jemalloc developers who put it under the BSD license are going to be okay with relicensing to LGPLv3+ and assigning copyright on their work to the FSF.
Re: [gentoo-dev] Evaluating a new malloc()
On 26 February 2013 16:37, Maciej Mrozowski wrote: > On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: > > On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner > wrote: > > > I see a *HUGE* reason. glibc ships with ptmalloc. If you think they > > > should use jemalloc, talk to them. Don't just do it in Gentoo. > > > > Certainly I think it would be far more productive to talk to the glibc > > maintainers first. > > You mean productive like below? ;) > > http://sourceware.org/bugzilla/show_bug.cgi?id=11261 > > Ulrich Drepper: > "Stop reopening. There is a solution for people who are stupid enough to > create too many threads. No implementation will be perfect for everyone. > The > glibc implementation is tuned for reasonable programs and will run much > faster > than any other I tested." > > Merge of jemalloc upstream is likely never going to happen. > > regards > MM It could happen. Ulrich Drepper is no longer in charge of Glibc and he's barely involved in the development at all recently from what i've heard/seen.
Re: [gentoo-dev] Evaluating a new malloc()
On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: > On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner wrote: > > I see a *HUGE* reason. glibc ships with ptmalloc. If you think they > > should use jemalloc, talk to them. Don't just do it in Gentoo. > > Certainly I think it would be far more productive to talk to the glibc > maintainers first. You mean productive like below? ;) http://sourceware.org/bugzilla/show_bug.cgi?id=11261 Ulrich Drepper: "Stop reopening. There is a solution for people who are stupid enough to create too many threads. No implementation will be perfect for everyone. The glibc implementation is tuned for reasonable programs and will run much faster than any other I tested." Merge of jemalloc upstream is likely never going to happen. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 8:35 AM, Alec Warner wrote: > In terms of 'following Gentoo policy.' We encourage packages to be as > close to upstream as possible. I cannot fathom why when you basically > find a performance bug in malloc, you start a thread on the list about > replacing it; as opposed to filing a bug against glibc or emailing the > glibc lists and asking them about it. We may not understand it, but it does completely fit ryao's typical modus operandi.
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner wrote: > I see a *HUGE* reason. glibc ships with ptmalloc. If you think they > should use jemalloc, talk to them. Don't just do it in Gentoo. Certainly I think it would be far more productive to talk to the glibc maintainers first. However, nothing prevents anybody from creating a Gentoo package with an alternative glibc implementation, patchset, whatever, assuming they are willing to maintain it. It really is no different from having an alternative udev implementation. Gentoo is about choice. Now, whether it ever becomes the /default/ choice is another matter entirely. Nobody can prevent people from experimenting - Gentoo developers are permitted to waste their time if desired. :) Rich
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 8:33 AM, Richard Yao wrote: > Unless a significant issue is found in jemalloc itself, I do not see any > reason to continue using glibc's ptmalloc over jemalloc. As far as I > know, FreeBSD, NetBSD, Facebook and others are using jemalloc, so I > expect that no significant issues will be found. jemalloc will still > needs testing before we can consider it. Doing good tests is hard, so I > would like to crowd source ideas on the appropriate way to test a malloc > implementation from the list. My expectation is that people on the list > will collectively think of better ideas than I could on my own. > > With that said, what do people think? > Just want to point out a problem I have personally encountered with another alternate malloc (tcmalloc). Essentially, when you combine libGL.so from nvidia-drivers with tcmalloc, the Google Chrome web browser fails to properly close its worker processes. https://bugs.gentoo.org/show_bug.cgi?id=413637 This thread on the Chromium developer list goes into more detail: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/uLf5l669dCk/MXXfJfIvDF0J The main concern I would have is that upstream developers (like nvidia) are unlikely to test their software with an alternate malloc implementation, so we could end up running into some very subtle bugs. Are the saved cycles really worth it?
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 5:33 AM, Richard Yao wrote: > The Blender project found some fairly remarkable discrepancies between > what their software actually used and what glibc's ptmalloc allocated: > > http://www.sintel.org/development/memory-jemalloc/ > > Results such as these led Blender and others (e.g. Chrome/Chromium, > Firefox, Thunderbird) to bundle private versions of jemalloc. This > bundling situation violates our policy against bundled libraries. The > maintainers could just patch their software to link to libjemalloc. > However, it might make more sense to evaluate jemalloc as a > distribution-wide replacement for glibc's ptmalloc. So I'm confused a bit. The glibc malloc does perform poorly in some edge cases. Lots of folks use an optimized allocator. That doesn't mean that the glibc one is necessarily bad or worth replacing. In terms of 'following Gentoo policy.' We encourage packages to be as close to upstream as possible. I cannot fathom why when you basically find a performance bug in malloc, you start a thread on the list about replacing it; as opposed to filing a bug against glibc or emailing the glibc lists and asking them about it. > > It appears that run the following commands on amd64 to see how jemalloc > works when used system-wide: > > echo dev-libs/jemalloc ~amd64 >> /etc/portage/package.accept_keywords > emerge dev-libs/jemalloc > echo /usr/lib64/libjemalloc.so.1 >> /etc/ld.so.preload Well certainly we would never deploy an ld preload hack. If you want to test jemalloc, why don't you actually recompile the system against libjemalloc (patched glibc)? > > I did this on my system, verified that jemalloc was being loaded with > strace and rebooted. So far, sudo is broken and anything that is 32-bit > will have the loader print an error about the library not being > preloaded. On a related note, setuid binaries will obey > /etc/ld.so.preload, even though they ignore LD_PRELOAD. > > There is a chance that patching jemalloc directly into glibc would solve > the sudo issue, but I imagine that sudo is doing something strange, > which likely merits attention. For now, I am using su as a substitute > until I look into why sudo is broken. > > Unless a significant issue is found in jemalloc itself, I do not see any > reason to continue using glibc's ptmalloc over jemalloc. As far as I > know, FreeBSD, NetBSD, Facebook and others are using jemalloc, so I > expect that no significant issues will be found. jemalloc will still > needs testing before we can consider it. Doing good tests is hard, so I > would like to crowd source ideas on the appropriate way to test a malloc > implementation from the list. My expectation is that people on the list > will collectively think of better ideas than I could on my own. > > With that said, what do people think? > I see a *HUGE* reason. glibc ships with ptmalloc. If you think they should use jemalloc, talk to them. Don't just do it in Gentoo.
Re: [gentoo-dev] [RFC/PATCH] A cleaner API for virtualx.eclass
On Tue, 12 Feb 2013 18:42:28 +0100 ""Paweł Hajdan, Jr."" wrote: > On 2/11/13 11:14 PM, Michał Górny wrote: > > My patches introduce a single wrapper with argv-as-parameter syntax. > > That is, the fore-mentioned example would look like: > > > > virtualx run_tests --foo > > Maybe we can just adapt Ubuntu's (I think) xvfb-run? More > standardization == profit. That's probably a good idea. However, I just stepped up here to replace the ugly API with something better. I think the actual eclass maintainers should have the final word here. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Evaluating a new malloc()
Am 26.02.2013 14:52, schrieb Richard Yao: > On 02/26/2013 08:48 AM, Alexander Berntsen wrote: >> On 26/02/13 14:33, Richard Yao wrote: >>> The Blender project found some fairly remarkable discrepancies >>> between what their software actually used and what glibc's ptmalloc >>> allocated >> Have they filed a bug? >> > > I don't know. You should ask them. > Probably related to http://sourceware.org/bugzilla/show_bug.cgi?id=11261 Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Evaluating a new malloc()
On 02/26/2013 08:48 AM, Alexander Berntsen wrote: > On 26/02/13 14:33, Richard Yao wrote: >> The Blender project found some fairly remarkable discrepancies >> between what their software actually used and what glibc's ptmalloc >> allocated > Have they filed a bug? > I don't know. You should ask them. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Evaluating a new malloc()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/02/13 14:33, Richard Yao wrote: > The Blender project found some fairly remarkable discrepancies > between what their software actually used and what glibc's ptmalloc > allocated Have they filed a bug? - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEsvS4ACgkQRtClrXBQc7WLLQD/Sp6ypPcg5UPGErRRF4lqd9Ad g1bbdXGbDKQ2igbIOcgA/12jT8eBq3z07QgMisOGAL5IexKtfcRL80UDHqEEUaBy =3bY4 -END PGP SIGNATURE-
Re: [gentoo-dev] Evaluating a new malloc()
On 02/26/2013 08:35 AM, Diego Elio Pettenò wrote: > On 26/02/2013 14:33, Richard Yao wrote: >> Results such as these led Blender and others (e.g. Chrome/Chromium, >> Firefox, Thunderbird) to bundle private versions of jemalloc. This >> bundling situation violates our policy against bundled libraries. The >> maintainers could just patch their software to link to libjemalloc. >> However, it might make more sense to evaluate jemalloc as a >> distribution-wide replacement for glibc's ptmalloc. > > Short answer: no. > Would you elaborate on this? From a brief chat in IRC, you mentioned Valgrind, but it looks like that issue has been solved: http://blog.mozilla.org/jseward/2012/06/05/valgrind-now-supports-jemalloc-builds-directly/ jemalloc probably should be merged at glibc upstream, but I have zero contact with glibc development, my Google searches have been fruitless and I want to know what other people think about this. I think it would be wrong to try to go to upstream with the idea if people downstream don't like the idea. Not to mention, glibc is not the only libc in Gentoo and this applies to each of them. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Evaluating a new malloc()
On 26/02/2013 14:33, Richard Yao wrote: > Results such as these led Blender and others (e.g. Chrome/Chromium, > Firefox, Thunderbird) to bundle private versions of jemalloc. This > bundling situation violates our policy against bundled libraries. The > maintainers could just patch their software to link to libjemalloc. > However, it might make more sense to evaluate jemalloc as a > distribution-wide replacement for glibc's ptmalloc. Short answer: no. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] Evaluating a new malloc()
The Blender project found some fairly remarkable discrepancies between what their software actually used and what glibc's ptmalloc allocated: http://www.sintel.org/development/memory-jemalloc/ Results such as these led Blender and others (e.g. Chrome/Chromium, Firefox, Thunderbird) to bundle private versions of jemalloc. This bundling situation violates our policy against bundled libraries. The maintainers could just patch their software to link to libjemalloc. However, it might make more sense to evaluate jemalloc as a distribution-wide replacement for glibc's ptmalloc. It appears that run the following commands on amd64 to see how jemalloc works when used system-wide: echo dev-libs/jemalloc ~amd64 >> /etc/portage/package.accept_keywords emerge dev-libs/jemalloc echo /usr/lib64/libjemalloc.so.1 >> /etc/ld.so.preload I did this on my system, verified that jemalloc was being loaded with strace and rebooted. So far, sudo is broken and anything that is 32-bit will have the loader print an error about the library not being preloaded. On a related note, setuid binaries will obey /etc/ld.so.preload, even though they ignore LD_PRELOAD. There is a chance that patching jemalloc directly into glibc would solve the sudo issue, but I imagine that sudo is doing something strange, which likely merits attention. For now, I am using su as a substitute until I look into why sudo is broken. Unless a significant issue is found in jemalloc itself, I do not see any reason to continue using glibc's ptmalloc over jemalloc. As far as I know, FreeBSD, NetBSD, Facebook and others are using jemalloc, so I expect that no significant issues will be found. jemalloc will still needs testing before we can consider it. Doing good tests is hard, so I would like to crowd source ideas on the appropriate way to test a malloc implementation from the list. My expectation is that people on the list will collectively think of better ideas than I could on my own. With that said, what do people think? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Hello *, I am stuck and have many questions. [In the process of becoming a dev, I've generated a gpg key, of course. It vwas on an old notebook. When I switched to a newer notebook, I forgot to copy it, because I don't use gpg regularly. No risk that it became known - the disk was re-partitioned and re-formatted. Probably, that key has expired anyway.] 1. So, I start gpg --gen-key It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can be done later? 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. After that, gpg --list-keys says /home//.gnupg/pubring.gpg --- pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26] uid [ultimate] sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26] So, my key id is 0x<16_hex_digits_1>, right? 3. Now I do gpg --edit-key 0x<16_hex_digits_1> addkey Then I choose (4) RSA (sign only) right? Then I choose 4096, 1y, y, y, save. Now gpg --list-keys gives /home//.gnupg/pubring.gpg --- pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26] uid [ultimate] sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26] sub 4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26] 4. I do gpg --output revoke.asc --gen-revoke 0x<16_hex_digits_1> and choose 1. 6. Encrypted backup of your secret keys. I don't understand this. 7. In your gpg.conf: # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g I don't understand this. 5. I do gpg --keyserver subkeys.pgp.net --send-key 0x<16_hex_digits_1> 6. On dev.gentoo.org, I am supposed to do perl_ldap -b user -M gpgkey perl_ldap -b user -M gpgfingerprint Is 0x<16_hex_digits_1>? Or 0x<16_hex_digits_3>? What is and how do I get it? Is my username on dev.gentoo.org? What's even more important, perl_ldap asks my ldap password. I suppose I haven't got one. My usual Gentoo password (used in bugzilla, forums) does not work. How do I get an ldap password? 7. If I'll ever complete all the above, I'll add sign to FEATURES in /etc/portage/make.conf, and PORTAGE_GPG_DIR="/home//.gnupg" and also PORTAGE_GPG_KEY="0x<16_hex_digits_3>!" Is this correct? Is it <16_hex_digits_3>, and not, say, <16_hex_digits_1>? Should I add ! at the end, as suggested by mgorny? During the time I'm reading all these instructions, I could bump 10 packages. Very complicated for a person who does not use gpg and knows next to nothing about it. Andrey Grozin
