Re: [gentoo-dev] Gentoo desktop system built with musl libc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Anthony G. Basile schrieb: Hi everyone, Tigger alert ... shameless plug. I sent the following to the musl-libc email list yesterday. I thought other gentoo devs may be interested in what I've been up to with musl: [...] Very interesting! Thank you! -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV1HeZAAoJEBgiZgGABV/M9Y4P/jw471thGOe3BcCJqPyetl93 WUVpY/k2sKfvtM9QYRGAbe0MK2MC/iH7rH3c+bpPshACD65nX6ngaE0lz99K6Q/A 2N6BAp5X9S0tGeJqyJyq2JYY7hyW6lm/zIv27nWhYTL/VIpRuCPkBk7T4XUDdxe3 EgI+ynuvfAnq2OsQ/+ftstOU1xLpmI19bVZ54ztB0FkXVRvdvCxe4u0XBH8bIwrV TbgShSdQpyjlzFRPTSmGLg1BXYOC8XBwg9mrNC39g4PrjTOVgn4/04MN+ZWAYo9Y 4yviknLTiPhzjHJrSkrdQDn5soK7nEBVViT/z63x4mopkOG5RnktmEjLAcK7JTwo 8z/F/LBLSLGnlgzYVPKBuXfScs4QQ6gSh2lxOQYAvO+xGR90+72LxYQk/bk0TKod h/wWy6ERk9ial1kgyA9WOiQBrQd0hCfAc1Fzh8hy8E9Xa6WXdh52Wk9Isu6245F/ 5w6Mn6o16jIxvLHIV92NMZu2RyZEr3qERLoXol0gJQ6qZJgFMUPvwsUdM4xqJPrB yxGNCvHe2Uit9JvL98suACcogNMdD4QNbxMt2Zukm89kg0OJEk79YNy9lrjWnSZG xk9iJAGVT0Ej4wEI/RFKujcuTM3DjGIC4OaMYExkECfIpWm7FoDGvy1J0Ky0XY58 k6ChOqwbumL+cbD0EGEI =h9Q2 -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-java/{a lot of packages}
# Patrice Clement monsie...@gentoo.org (19 Aug 2015) # Upstream dead: no releases since 2010. # Technology has moved on and there are far better alternatives # (easymock, mockito and jmock). # Masked for removal in 30 days. See bug #190307. dev-java/mockobjects # Patrice Clement monsie...@gentoo.org (19 Aug 2015) # Upstream dead too: no releases since 2005. # Masked for removal in 30 days. See bug #190307. dev-java/xdoclet # Patrice Clement monsie...@gentoo.org (16 Aug 2015) # Dependency of dev-java/base64. This project isn't getting a lot of traction # and we already have a ton of Java serialiser APIs in the tree. # Masked for removal. See bug #557866. dev-java/java-xmlbuilder # Patrice Clement monsie...@gentoo.org (16 Aug 2015) # Last release was in 2008. Does not compile with recent JDKs (= 1.8). # Masked for removal. See bug #557920. dev-java/httpunit # Patrice Clement monsie...@gentoo.org (16 Aug 2015) # Project discontinued: part of the java.util namespace as of Java 8. # See https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html. # Masked for removal. See bug #557866. dev-java/base64 # Patrice Clement monsie...@gentoo.org (14 Aug 2015) # Unreachable HOMEPAGE (dead). Very very very old package: # last release came out in 2001. # Masked for removal in 30 days. See bug #232666. dev-java/tclib # Patrice Clement monsie...@gentoo.org (14 Aug 2015) # Last release is over 13 years old (!). # Masked for removal in 30 days. See bug #177032. app-text/jdictionary # Patrice Clement monsie...@gentoo.org (1 Aug 2015) # Package relying on j2me. Not useful anymore since j2me has long been removed. # Removal in 30 days. See bug #556460. dev-java/antenna signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo desktop system built with musl libc.
On Wed, Aug 19, 2015 at 12:19 PM, Anthony G. Basile bluen...@gentoo.org wrote: Tigger alert ... shameless plug. I sent the following to the musl-libc email list yesterday. I thought other gentoo devs may be interested in what I've been up to with musl: Very cool! Cheers, Dirkjan
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, Aug 19, 2015 at 11:00:49AM -0700, Zac Medico wrote: On 08/19/2015 10:49 AM, hasufell wrote: On 08/19/2015 07:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. Why is it called Package-Manager: then? Because repoman in bundled with portage, I guess. I suppose we could change it to something else. How about the line below? Signed-off-by: dev name (repoman version) Cheers, —Guilherme
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 12:48 PM, Mike Gilbert wrote: On Wed, Aug 19, 2015 at 1:38 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 08/19/2015 12:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. If repoman supported adding a signedoffby line I'd likely use it more for commits. Still running repoman full before commit though. I do not believe we have an requirement for adding Signed-off-by in the gentoo repository. Why do you feel the need to do that? General completeness is all -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 10:49 AM, hasufell wrote: On 08/19/2015 07:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. Why is it called Package-Manager: then? Because repoman in bundled with portage, I guess. I suppose we could change it to something else. And how often was that useful in practice? Well, there haven't been any EAPI bumps lately. However, in the time that follows an EAPI bump, it can be very useful if there are new dependency features that require new repoman checks. -- Thanks, Zac
[gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it.
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, Aug 19, 2015 at 06:33:16PM +0200, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. I was wondering why this is there also; I would vote for removing it as well. William signature.asc Description: Digital signature
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 19.08.2015 18:33, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. With that line removed, how do we notice that people are committing without repoman or not running repoman checks at least? There is quite a risk of things going straight into stable by mistake when repoman is not used. Best, Sebastian
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 07:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. Why is it called Package-Manager: then? And how often was that useful in practice?
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, Aug 19, 2015 at 1:38 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 08/19/2015 12:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. If repoman supported adding a signedoffby line I'd likely use it more for commits. Still running repoman full before commit though. I do not believe we have an requirement for adding Signed-off-by in the gentoo repository. Why do you feel the need to do that?
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 08:00 PM, Matthew Thode wrote: On 08/19/2015 12:48 PM, Mike Gilbert wrote: On Wed, Aug 19, 2015 at 1:38 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 08/19/2015 12:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. If repoman supported adding a signedoffby line I'd likely use it more for commits. Still running repoman full before commit though. I do not believe we have an requirement for adding Signed-off-by in the gentoo repository. Why do you feel the need to do that? General completeness is all Signed-off-by has a completely different purpose which is not part of our workflow, so that tag is pretty useless to us most of the time. See https://wiki.gentoo.org/wiki/Talk:Gentoo_git_workflow#Sign-Off
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 08:00 PM, Zac Medico wrote: On 08/19/2015 10:49 AM, hasufell wrote: And how often was that useful in practice? Well, there haven't been any EAPI bumps lately. However, in the time that follows an EAPI bump, it can be very useful if there are new dependency features that require new repoman checks. Still am not sure how this is useful in practice. Some commit is broken, someone else finds out. He runs repoman locally: * repoman reports the brokenness - ask the committer which repoman version he used (and if he can reproduce it with latest stable repoman) * repoman does not report brokenness - report a bug against his local version after checking that he is up2date Now with git... it is even easier to test these things, because you can just jump back in time and run repoman on the offending commit. No reason to include that information in all commits, afais. And it doesn't tell you much anyway, because other versions could be affected too by the bug, so you end up debugging properly anyway.
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, Aug 19, 2015 at 2:09 PM, hasufell hasuf...@gentoo.org wrote: Signed-off-by has a completely different purpose which is not part of our workflow, so that tag is pretty useless to us most of the time. See https://wiki.gentoo.org/wiki/Talk:Gentoo_git_workflow#Sign-Off I agree. Generally it is used to signify agreement to a developer certificate of origin. I would recommend using it for any other purpose, especially since there has been talk of instituting a DCO for Gentoo (based on the Linux DCO). We're not at the point of doing that just yet, but I wouldn't stick something entirely different in that field so that if we do institute a DCO we end up doing it differently than every other project that uses Git. If we want to capture this it should go in its own header. If the goal is to capture the repoman version, then I'd just capture the repoman version, or some identifier for the set of rules repoman was checking against at the moment (I'm not sure if repoman uses any kind of data updated outside of portage releases). -- Rich
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. -- Thanks, Zac
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
V
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 12:37 PM, Zac Medico wrote: On 08/19/2015 09:33 AM, hasufell wrote: I don't want to start a lot of bikeshed, but I think this information is practically useless. If there has been a problem with a commit, ask the developer about his repoman version (which I believe was the reason for this, unless you want me to add Package-Manager: paludis-2.4.0 to every commit ;). Let's just remove it. The intent is to leave a record of the version of repoman used, which leaves an audit trail in case there's a bug in some some version (or to detect if someone is using an ancient version). It can especially be useful when new repoman checks need to be added for new EAPI features. If repoman supported adding a signedoffby line I'd likely use it more for commits. Still running repoman full before commit though. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, 19 Aug 2015 14:24:24 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, Aug 19, 2015 at 2:09 PM, hasufell hasuf...@gentoo.org wrote: Signed-off-by has a completely different purpose which is not part of our workflow, so that tag is pretty useless to us most of the time. See https://wiki.gentoo.org/wiki/Talk:Gentoo_git_workflow#Sign-Off I agree. Generally it is used to signify agreement to a developer certificate of origin. I would recommend using it for any other purpose, especially since there has been talk of instituting a DCO for Gentoo (based on the Linux DCO). We're not at the point of doing that just yet, but I wouldn't stick something entirely different in that field so that if we do institute a DCO we end up doing it differently than every other project that uses Git. If we want to capture this it should go in its own header. If the goal is to capture the repoman version, then I'd just capture the repoman version, or some identifier for the set of rules repoman was checking against at the moment (I'm not sure if repoman uses any kind of data updated outside of portage releases). It does not other the the metadata.dtd file it checks for updates and updates itself with. But that is very likely to change with the rewrite I have in progress (albeit slowly). I have also seriously been contemplating splitting off it's release from the main portage package. Most users don't ever use repoman. Plus once the plugin system and checks data downloads are in place, there will be far less need for updates and releases. I would still keep it part of the portage repository due to it's ties to the codebase. Just release it as a separate installable package. -- Brian Dolbec dolsen
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On 08/19/2015 11:11 AM, hasufell wrote: On 08/19/2015 08:00 PM, Zac Medico wrote: On 08/19/2015 10:49 AM, hasufell wrote: And how often was that useful in practice? Well, there haven't been any EAPI bumps lately. However, in the time that follows an EAPI bump, it can be very useful if there are new dependency features that require new repoman checks. Still am not sure how this is useful in practice. Some commit is broken, someone else finds out. He runs repoman locally: * repoman reports the brokenness - ask the committer which repoman version he used (and if he can reproduce it with latest stable repoman) * repoman does not report brokenness - report a bug against his local version after checking that he is up2date I guess that will probably work well enough. Now with git... it is even easier to test these things, because you can just jump back in time and run repoman on the offending commit. Well, that's true if they use merge commits. If they rebase, that's trickier. I'm not really worried about it, though. No reason to include that information in all commits, afais. And it doesn't tell you much anyway, because other versions could be affected too by the bug, so you end up debugging properly anyway. Yeah, I'm will willing to let it go away. -- Thanks, Zac
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, 19 Aug 2015 17:25:51 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, Aug 19, 2015 at 3:09 PM, Brian Dolbec dol...@gentoo.org wrote: It does not other the the metadata.dtd file it checks for updates and updates itself with. But that is very likely to change with the rewrite I have in progress (albeit slowly). I have also seriously been contemplating splitting off it's release from the main portage package. Now I remember the conversations. Having repoman rules at the repository level, local system level, and a few others (I forget where the thread was). Overlays can have their own rules, and so on. It doesn't make sense to update portage every time there is a new QA policy. EXACTLY! There will still need to be occasional releases due to the need for additional or changed code. But for trivial changes like deprecating an EAPI or adding a new eclass,... That is all data it can easily download or even get within the git/rsync tree. Then just iterate over the various entries. There will be no need for a new release. -- Brian Dolbec dolsen
[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 06/07/15 um 17:08 schrieb Michał Górny:
Hello, developers.
[snip]
Sadly, there are two problems with using Ninja:
1) it will not work with some packages,
[snip]
So, what do you think? Should I start switching random packages to
Ninja whenever it works?
Oh, and this would be done via something like:
: ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
before inherit line. To respect user forcing another generator, and
to get deps right.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
FYI we have a tracker bug now[1]. Bug alias is ninja-porting Toralf
Förster is already tinderboxing it. If we have all bugs fixed we can
discuss to enable it globally.
[1] https://bugs.gentoo.org/show_bug.cgi?id=557992
Kreetings
- --
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1
iQJ8BAEBCgBmBQJV1QcfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0v80oP/22dI/4S0b36oxM+fKwh13a+
6Q9RMflwZtd+OKLPaeqZEU3XS2E/F0r8WR/GDWzZuRRFpJbOXjVjaB+GwEwrvi7V
t5bN8Xu8wTMuACEc8RbJWl1WClnEm8pEyODutdwXaePSt+w4cIOivdNZopzdkgFD
LkNAMk7wbsb4RNnbdpcmIXEFn0SSZvV52B8nof9l1XMhPgwYACa2E7PyY/uVzWae
nP1NfZLM8HRI9S41+jS4hDdrpIls03XBvdcEZfDZ3Wiru5ibXEcyYcSbjzvNlUpp
N+wCSjbtawjVuWF/h/ltW07EXtJEqlz0PrdW2P6rf1H7G8Z0vmzLGPh1LJ4cOVYH
cTMmEagQJjKiQnv1z+ijJrpsEVAAerApVpcEtoDmFFSwjxgEr34dGlNETrTWAB8x
vv14aVp94T+o5satjNQSeB6jyPySO4slTEYlZ2NZpX50oelF1aUgX4glaxadU0Yb
5Nd+xu4W7eeZf1TJ/DNTx8kHOEHnGzff/JZ+4+tUrtR/V61fHGPWrFRmiBC2U2Br
HjdaCefWE+lEbJm81a4LH0k7S0axMPZQHCuuicUt3uy2eNxJpBOMMDe0xGfzadZ1
c26sJgU6SdQhGSwMy6PiQGYw8AY9ffQk7KTfGiX5E4oMiiWXGDTU6jschqw4+ZlI
45qYstN0xi7VeAut8uYJ
=6/bq
-END PGP SIGNATURE-
Re: [gentoo-dev] repoman adding Package-Manager: portage-2.2.20.1 to every single commit
On Wed, Aug 19, 2015 at 3:09 PM, Brian Dolbec dol...@gentoo.org wrote: It does not other the the metadata.dtd file it checks for updates and updates itself with. But that is very likely to change with the rewrite I have in progress (albeit slowly). I have also seriously been contemplating splitting off it's release from the main portage package. Now I remember the conversations. Having repoman rules at the repository level, local system level, and a few others (I forget where the thread was). Overlays can have their own rules, and so on. It doesn't make sense to update portage every time there is a new QA policy. -- Rich
[gentoo-dev] Gentoo desktop system built with musl libc.
Hi everyone, Tigger alert ... shameless plug. I sent the following to the musl-libc email list yesterday. I thought other gentoo devs may be interested in what I've been up to with musl: I want to announce to the list that I've built and will be maintaining three hardened, fully featured XFCE4 Gentoo desktop systems for amd64, each based on glibc, uClibc and musl respectively. These are affectionately called Bluemoon (glibc), Lilblue (uClibc) and Bluedragon (musl) Gentoo Linux. You can download them from the release site [1] where you'll find links to their home pages and how to install and maintain them. Except for their libc and some minor details here and there, I've tried to make them as identical as possible. They should not be thought of as embedded in that they do not use busybox to provide the system utilities. Rather they employ all the usual packages you'd find on any regular Linux desktop. The are also hardened meaning that they are built with our gcc specs which turn on ssp, pie, relro, bind now and stack check by default, and they use a PaX/Grsecurity patched kernel with all practical security features turned on. In addition to the release tarballs, I'm also providing about 5000 extra packages. Gentoo is a from source distribution and you can always try to build packages from source on your local system, but Gentoo also provides the possibility of using pre-compiled packages made available from a binary package host (BINHOST). The package set for each system is at links [2], [3] and [4]. Also, these systems can be maintained like any other Gentoo system using portage and emerge, but I've also written a new release engineering tool that allows the end user to easily maintain each by tracking a reference system defined upstream. You can read about the Gentoo Reference System suite at link [5]. Its a long document so you may want to read just the Intro and Quickstart. The main reasons for building these systems was to 1) facilitate comparisons between the three libc's and 2) to push the limits of each to see what breaks, and then fix either the packages or the libc itself. To this end, the GRS suite also acts like a poor-man's tinderbox and provides build logs for packages which have failed. These can be seen at links [6], [7] and [8]. Nonetheless, the systems are useful. The release tarballs come with abiword, gnumeric, the gimp, eog, hexchat, mplayer and smplayer, midori web browser, claws-mail, and there are many more packages on the BINHOST. The glibc and uClibc are polished and work pretty much bug free. You'd expect that since the entire Gentoo community works with Gentoo+glibc, and I've been working at Gentoo+uClibc for a while fixing things. However the musl desktop is the newest addition and it does have some issues. In particular, the charset is messed up and I have yet to clean that up for the next release. For reasons I don't understand yet I'm getting Japanese characters sometimes. Contribute if you can. You can open bugs on http://bugs.gentoo.org. Mention that you're working with musl and not glibc and ask that the bug be assigned to bluen...@gentoo.org. [1] http://releases.freeharbor.net/ [2] http://bluemoon.freeharbor.net [3] http://lilblue.freeharbor.net [4] http://bluedragon.freeharbor.net [5] https://wiki.gentoo.org/wiki/Project:RelEng_GRS [6] http://bluemoon-tinderbox.freeharbor.net [7] http://lilblue-tinderbox.freeharbor.net [8] http://bluedragon-tinderbox.freeharbor.net -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
