Re: [gentoo-dev] Updating Council page with voting information
On Sat, Apr 22, 2006 at 12:10:01 +0200, Mike Frysinger wrote: > with the trustee voting process coming up i thought i should get on the ball > and give a brief overview of the current Council election process > > so can people check out the new Voting section and tell me what ya'll think: > http://www.gentoo.org/proj/en/council/ Looks nice to me (I'm not familiar to the voting process) except that there is no information on how nominees are decided. Should one volunteer or do other people say they want to nominate him? Also, a word on who is eligible to vote (every dev? every dev who has been >X months in gentoo?) would be nice. Also, I don't know if you're responsible for this page, but 3 of the 4 "previous result links" are 404 (only the vote distribution remains). /Alexandre -- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgp4Pj9Uyj13D.pgp Description: PGP signature
Re: [gentoo-dev] Updating Council page with voting information
On Saturday 22 April 2006 06:30, Alexandre Buisse wrote: > On Sat, Apr 22, 2006 at 12:10:01 +0200, Mike Frysinger wrote: > > with the trustee voting process coming up i thought i should get on the > > ball and give a brief overview of the current Council election process > > > > so can people check out the new Voting section and tell me what ya'll > > think: http://www.gentoo.org/proj/en/council/ > > Looks nice to me (I'm not familiar to the voting process) except that > there is no information on how nominees are decided. Should one > volunteer or do other people say they want to nominate him? there are no restrictions on nominations ... you can nominate yourself or find some sucker to do it for you ;) > Also, a > word on who is eligible to vote (every dev? every dev who has been >X > months in gentoo?) would be nice. hrm, i thought the GLEP covered this, but i guess not ... i'll update the page > Also, I don't know if you're responsible for this page, but 3 of the 4 > "previous result links" are 404 (only the vote distribution remains). the cvs QA script is preventing me from committing those files atm -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Updating Council page with voting information
On Friday 21 April 2006 19:40, Mike Frysinger wrote: > with the trustee voting process coming up i thought i should get on the > ball and give a brief overview of the current Council election process > > so can people check out the new Voting section and tell me what ya'll > think: http://www.gentoo.org/proj/en/council/ ive started adding nomination information from the previous election so if you posted an introduction but i cant seem to find it (i.e. it isnt on the page), please forward it to me -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] www-client/amaya needs new maintainer
www-client/amaya is without an active maintainer and has an open security bug : https://bugs.gentoo.org/show_bug.cgi?id=129874 It needs a bump to 9.5, and it also needs a maintainer/herd. If nobody steps in to fix it, package will have to be masked then removed from portage. -- Thierry Carrez (Koon) Gentoo Linux Security Team -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] dev-libs/libvc and app-misc/rolo need new maintainers
dev-libs/libvc is without an active maintainer and has an open security bug : https://bugs.gentoo.org/show_bug.cgi?id=127757 This bug also affects Rolo, which also misses an active maintainer/herd. If nobody steps in to fix them, packages will have to be masked then removed from portage. -- Thierry Carrez (Koon) Gentoo Linux Security Team -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Documentation Encoding
Hi! I'm using UTF-8 encoding in my system. The main problem is, that lots of /usr/share/man/* and /usr/share/doc/* files are iso8859-2 encoded (as my LINGUAS is set to pl). I think, that Portage itself should recode all the files, which go to /usr/share/man/ and /usr/share/doc/ directories to UTF-8 by default. There's also a problem with Groff, which is unable to show unicode chars correctly. I made a package to solve it (http://hoth.amu.edu.pl/~d_szeluga/groff-utf8.tar.bz2), but I think it's a bit dirty hack. So: Are there any plans, to make Portage install all the docs in desired encoding? Are there any plans, to do something with Groff? -- PGP: 0xAB6AF545 Fingerpring: FE1C FC81 61E9 3979 4A1E B0E2 27DB 5EA1 AB6A F545 JID: damjanek chopin edu pl pgps9i4Vh1eWN.pgp Description: PGP signature
Re: [gentoo-dev] Documentation Encoding
Damian Szeluga wrote: > I'm using UTF-8 encoding in my system. The main problem is, that lots > of /usr/share/man/* and /usr/share/doc/* files are iso8859-2 encoded (as my > LINGUAS is set to pl). I think, that Portage itself should recode all the > files, which go to /usr/share/man/ and /usr/share/doc/ directories to UTF-8 > by default. Not sure if that will be an easy task since the source encoding is probably not known. Probably this should go upstream? > There's also a problem with Groff, which is unable to show > unicode chars correctly. I made a package to solve it > (http://hoth.amu.edu.pl/~d_szeluga/groff-utf8.tar.bz2), but I think it's a > bit dirty hack. I am absolutely out of time now, hope to be able to look at it in a week. .. actually I had a look :-) So this is a different package from groff as it seems. http://www.haible.de/bruno/packages-groff-utf8.html Dunnow, but probably trying to integrate UTF-8 support in groff and working with upstream should be doable if that package is working? We in JP land often have problems with Japanese man pages and others and there was a patch floating around (USE=cjk emerge groff) that kind of solves the problem a bit. So, fixing groff is definately a good idea! Any takers? ;-) The last time I looked in the code I couldn't make much out of it :-( Kalin. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for app-laptop/ibm-acpi
Hi, The kernel module found in app-laptop/ibm-acpi has been included in the vanilla kernel since linux-2.6.10. There has been no releases of the stand-alone module since March 2005. Unless somebody has a really good reason as to why we should keep the external module in portage I will package.mask it in a week from now and remove it from portage 30 days later. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpmGsOK8ok2I.pgp Description: PGP signature
[gentoo-dev] confusing ppp/rp-pppoe setup
Hi, at the moment, /usr/lib/pppd/2.4.2/rp-pppoe.so is installed by net-dialup/ppp - nothing special - well, it's not a very recent version. In the syslog it says: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2 On the other hand, i've got net-dialup/rp-pppoe-3.8 installed and it installs a symlink: /etc/ppp/plugins/rp-pppoe.so -> /usr/lib/pppd/2.4.2/rp-pppoe.so Is this symlink needed? And why is it installed by rp-pppoe? (And is the /etc/ppp/plugins dir needed at all? What do plugins do in /etc/ppp/plugins? Don't they belong to /usr/lib/pppd/2.4.2/ ?) Well, yet another question: ppp-2.4.2 now includes the rp-pppoe.so plugins from rp-pppoe - do the ppp-people maintain that module by themselfs now? Or do they just download the plugin from the rp-pppoe-people and include it in their sources? I can imagine a ppp-ebuild that downloads a more recent version of rp-pppoe and builds the rp-pppoe.so-plugins directly from the rp-pppoe sources instead of using the ppp-sources. So what's going on there? I'd be happy about some comment from the maintainers. Greetings Sven -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: killing USE=userlocales
Mike Frysinger wrote: for you peeps who want to give this a shot, sync up and try glibc-2.4-r2. hopefully i wont have [m]any more changes to make before i release it into ~arch. pretty cool. couple dumb questions though. one, does this make the compile time explode? IIRC that was one of the original reasons userlocales was introduced. ghetto timetests show: Sun Apr 16 00:25:33 2006 >>> sys-libs/glibc-2.4-r2 merge time: 1 hour, 3 minutes and 26 seconds. Sat Apr 22 04:23:23 2006 >>> sys-libs/glibc-2.4-r2 merge time: 1 hour, 41 minutes and 18 seconds. could be noise though. two, what to do about messages such as: * (314/357) Generating te_IN.UTF-8 ... LC_ADDRESS: invalid escape `%n' sequence in field `postal_fmt' [ !! ] --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Documentation Encoding
On Saturday 22 April 2006 10:02, Kalin KOZHUHAROV wrote: > Damian Szeluga wrote: > > There's also a problem with Groff, which is unable to show > > unicode chars correctly. I made a package to solve it > > (http://hoth.amu.edu.pl/~d_szeluga/groff-utf8.tar.bz2), but I think it's > > a bit dirty hack. > > I am absolutely out of time now, hope to be able to look at it in a week. > .. actually I had a look :-) So this is a different package from groff as > it seems. http://www.haible.de/bruno/packages-groff-utf8.html > > Dunnow, but probably trying to integrate UTF-8 support in groff and working > with upstream should be doable if that package is working? yes ... working with upstream is best as i'm pretty clueless when it comes to UTF8 issues in groff and wont really be of any use in getting it fixed in portage ... see this bug: http://bugs.gentoo.org/126361 > We in JP land often have problems with Japanese man pages and others and > there was a patch floating around (USE=cjk emerge groff) that kind of > solves the problem a bit. if you want/need cjk support, you'll have to use groff-1.18.x as groff-1.19.x wont work -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: killing USE=userlocales
On Saturday 22 April 2006 12:18, R Hill wrote: > one, does this make the compile time explode? IIRC that was one of the > original reasons userlocales was introduced. no, the compile times are the same with locale-gen as with USE=userlocales ... it's simply a different way of doing it > Sun Apr 16 00:25:33 2006 >>> sys-libs/glibc-2.4-r2 > merge time: 1 hour, 3 minutes and 26 seconds. > > Sat Apr 22 04:23:23 2006 >>> sys-libs/glibc-2.4-r2 > merge time: 1 hour, 41 minutes and 18 seconds. this is because your /etc/locales.gen isnt configured thus the default is to generate *all* locales but the thing now is, once you edit the config file, you just run `locale-gen` rather than wait another hour for `emerge glibc` > * (314/357) Generating te_IN.UTF-8 ... > LC_ADDRESS: invalid escape `%n' sequence in field `postal_fmt' [ !! ] it's a bug in the locale files, these are not new errors ... you just never noticed them before because they were lost in the emerge output -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: > The kernel module found in app-laptop/ibm-acpi has been included in > the vanilla kernel since linux-2.6.10. There has been no releases of > the stand-alone module since March 2005. Is Gentoo planning on eradicating the 2.4 kernel from the tree in the next few weeks? -- This message has been brought to you by the letter three. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
On Sat, Apr 22, 2006 at 12:36:53PM -0700, Drake Wyrm wrote: > Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: > > The kernel module found in app-laptop/ibm-acpi has been included in > > the vanilla kernel since linux-2.6.10. There has been no releases of > > the stand-alone module since March 2005. > > Is Gentoo planning on eradicating the 2.4 kernel from the tree in the > next few weeks? No, some of the 2.4 kernels (e.g. hardened/gentoo-sources) are still maintained. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
On Saturday 22 April 2006 15:46, Tim Yamin wrote: > On Sat, Apr 22, 2006 at 12:36:53PM -0700, Drake Wyrm wrote: > > Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: > > > The kernel module found in app-laptop/ibm-acpi has been included in > > > the vanilla kernel since linux-2.6.10. There has been no releases of > > > the stand-alone module since March 2005. > > > > Is Gentoo planning on eradicating the 2.4 kernel from the tree in the > > next few weeks? > > No, some of the 2.4 kernels (e.g. hardened/gentoo-sources) are still > maintained. and vanilla-sources certainly isnt going anywhere linux-2.4 will be supported for quite sometime -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
On Sat, Apr 22, 2006 at 12:36:53PM -0700, Drake Wyrm wrote: > Is Gentoo planning on eradicating the 2.4 kernel from the tree in the > next few weeks? What does that have to do with ibm-acpi? The module doesn't compile against linux-2.4.x anyways. ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpicSI85Nimd.pgp Description: PGP signature
Re: [gentoo-dev] Re: killing USE=userlocales
Mike Frysinger wrote: > this is because your /etc/locales.gen isnt configured thus the default is to > generate *all* locales > can you magically migrate the existing /etc/locales.build to /etc/locales.gen? regards, Tuan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] www-client/amaya needs new maintainer
i think that i did it this is the amaya-9.5.ebuild attached it's working for me and i hope it'll work for every one. it builds amaya-9.5-fullsrc not with all its dependencies (freetype - wxwidgets - mesa) these are installed locally into amaya folder so they won't affect the original system ones - i really hope so :) - try it and if needed - i'm sure it's needed - modify it . On 4/22/06, Thierry Carrez <[EMAIL PROTECTED]> wrote: > www-client/amaya is without an active maintainer and has an open > security bug : > > https://bugs.gentoo.org/show_bug.cgi?id=129874 > > It needs a bump to 9.5, and it also needs a maintainer/herd. If nobody > steps in to fix it, package will have to be masked then removed from > portage. > > -- > Thierry Carrez (Koon) > Gentoo Linux Security Team > > -- > gentoo-dev@gentoo.org mailing list > > amaya-9.5.ebuild Description: Binary data
Re: [gentoo-dev] www-client/amaya needs new maintainer
i think that i did it this is the amaya-9.5.ebuild attached it's working for me and i hope it'll work for every one. it builds amaya-9.5-fullsrc with all its dependencies (freetype - wxwidgets - mesa) these are installed locally into amaya folder so they won't affect the original system ones - i really hope so :) - try it and if needed - i'm sure it's needed - modify it . On 4/22/06, Thierry Carrez <[EMAIL PROTECTED]> wrote: > www-client/amaya is without an active maintainer and has an open > security bug : > > https://bugs.gentoo.org/show_bug.cgi?id=129874 > > It needs a bump to 9.5, and it also needs a maintainer/herd. If nobody > steps in to fix it, package will have to be masked then removed from > portage. > > -- > Thierry Carrez (Koon) > Gentoo Linux Security Team > > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] QA Proposal v3
Here is the newest revision of my proposal. Not much has changed, but I added and changed some small things. Constructive feedback is appreciated. I'd like to get this voted on by the council at the next meeting. * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. Coding style issues fall under this category, and while they are not severe, they can make automated checks of the tree more difficult. * There will be cases when our tools are incapable of handling a certain situation and policy must be broken in order to get something working completely. This will hopefully not occur very often but each time it does occur, the QA team and the maintainer will come to some agreement on an interim solution and it is expected that a bug will be opened with the appropriate team to work towards a correct solution. * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. * The QA team will maintain a list of current "QA Standards" with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. * In order to join the QA team, you must be a developer for at least 4 months and must ask the current lead for approval. * The QA team will work with Recruiters to keep related documentation and quizzes up to date, so that up and coming developers will have access to all of the necessary information to avoid past problems. * QA will take an active role in cleaning up unmaintained and broken packages from the tree. It is also encouraged of members of the QA team to assist in mentoring new developers that wish to take over unmaintained packages/herds. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpP8aunh9bTt.pgp Description: PGP signature
Re: [gentoo-dev] QA Proposal v3
* In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. Maybe there should be something more here about dealing with maintainers who are refusing to cooperate. What if the maintainer reverts the changes that the QA team makes? * The QA team will maintain a list of current "QA Standards" with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document Why isn't this list meant to be comprehensive? I know that there will be QA problems that come up that you haven't thought about yet, but it would be really really nice to have a list with all of the QA problems that could come up and how to fix them. It would help new developers avoid mistakes and it would benefit the QA team by giving them a document that they can direct devs to when there is a problem. ~tcort -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: > On Sat, Apr 22, 2006 at 12:36:53PM -0700, Drake Wyrm wrote: > > Is Gentoo planning on eradicating the 2.4 kernel from the tree in the > > next few weeks? > > What does that have to do with ibm-acpi? The module doesn't compile > against linux-2.4.x anyways. That's a different matter. I didn't realize that it was 2.6 _only_. My apologies. I should have looked for that before responding. Also: while there are still a couple of 2.6 kernels in the tree prior to 2.6.10, I'm going to speculate that the arm, sparc, and s390 crowds are not so interested in that particular module. -- I used to think romantic love was a neurosis shared by two, a supreme foolishness. I no longer thought that. There's nothing foolish in loving anyone. Thinking you'll be loved in return is what's foolish. -- Rita Mae Brown pgpbafw8PBmFO.pgp Description: PGP signature
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > * QA will take an active role in cleaning up unmaintained and broken > packages from the tree. I hope this is meant to read more like: "QA will take an active role in cleaning up unmaintained packages from the tree if they are severly broken or have open security issues." What i mean here is that unmaintained != broken (if it works, leave it be), and partially broken != unworthy to be in the tree, for example if nothing provides equal functions, why get rid of something that works for the most part, so unmaintained with some bugs just means maintainer needed, not "buhbye!" severly broken here would mean does not even compile, or gui comes up but most functions just create a segfault. In short, i would like to see the above sentence changed to something a little less radical. (example provided) Thanks Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESvGh/aM9DdBw91cRArWqAJ9JhfuUr1JvJr4xgOZn0aAlMeil6wCeN22x rwtxKd77YT2mNTAZbIEyPps= =akQa -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: killing USE=userlocales
On Saturday 22 April 2006 17:37, Tuan Van wrote: > Mike Frysinger wrote: > > this is because your /etc/locales.gen isnt configured thus the default is > > to generate *all* locales > > can you magically migrate the existing /etc/locales.build to > /etc/locales.gen? i guess that would be trivial/logical to do -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Proposal v3
Thomas Cort wrote: * The QA team will maintain a list of current "QA Standards" with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document Why isn't this list meant to be comprehensive? I know that there will be QA problems that come up that you haven't thought about yet, but it would be really really nice to have a list with all of the QA problems that could come up and how to fix them. It would help new developers avoid mistakes and it would benefit the QA team by giving them a document that they can direct devs to when there is a problem. ~tcort Is a complete list of QA problems possible? I don't think that would necessarily be a finite list. -tercel -- gentoo-dev@gentoo.org mailing list
