Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:53 PM, hero...@gentoo.org wrote: Dear Denis, Hi Benda, Denis M. g...@politeia.in writes: Please review this, and if you agree that it'd be a good idea come with any suggestions to make it happen as well as with any other thoughts/sys-specs/instances we should be looking for. Thanks for the offering. Though not a member, AT teams might benefit from such a build farm. Almost every Gentoo dev that does software testings of some sorts could benefit from these build farms (although I'd refrain from using that term ;) ..). What are you suggesting practically, making a policy for everyone to donate VM to Gentoo, or developing a midware to do so? My initial idea was to suggest this here (in the gentoo-dev@ ML) first and see what you guys think about the idea. If it gets accepted by majority, then a policy, rules, etc... should be gathered through your comments here. After that we could make a wiki page (as Ago suggested while we were talking about this in IRC) and spam the gentoo-user ML and see how many good people are there :-). Cheers, Benda Regards, Denis M. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 08:59 PM, Matthew Thode wrote: On 11/07/2013 12:26 PM, Markos Chandras wrote: On 11/07/2013 02:48 PM, Matthew Thode wrote: Rackspace (where I work) currently has a developer discount program. I think we also host some open source stuff for various projects. Right now you can try to use http://developer.rackspace.com/ but if we want to make this more official I can ask around. Let me know if we want this as a more official thing (rackspace donating compute resources), no guarantees though :D. To be honest, I would like Gentoo infra to come up with a solution sometime... Last time (a year ago) i asked them about this, they said they have a cluster/big box for this purpose but they just didn't have the time to deploy it properly or something. Not everyone can afford paid solutions when it comes to contributing to free software iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. I've been running my VM for Ago for 13 months now (started on september 2012), where are my $200? ;-) Regards, Denis M. (Phr33d0m) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 09:18 PM, Rich Freeman wrote: On Thu, Nov 7, 2013 at 3:08 PM, Denis M. g...@politeia.in wrote: On 11/07/2013 08:59 PM, Matthew Thode wrote: iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. I've been running my VM for Ago for 13 months now (started on september 2012), where are my $200? ;-) Can't argue with that. :) Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I suspect that if we went out with something specific in mind we might be able to find a sponsor - but it is always best to have some idea just what we're going to be using any donations for (this will be our stage3 builder which cranks out a new stage3 every 20 minutes and reports build failures to double as a tinderbox, etc). Rich Currently Diego's tinderbox does something like that AFAIK. Compiles things and (almost?) automatically submits bugs against the packages with the relevant logs, etc... The initial idea behind my suggestion was that the devs would have the enough system resources to address these bugs (and the ones reported from the users, of course). An example here could be the following: finding/confirming a compilation bug for a package with ~10 USE flags could take tatt quite some compilations depending on the USE flag's combinations (this is actually what arch testers do in order to stabilize/keyword a package). Another example would be, as I mentioned in my previous mails to this thread - a new glibc version comes out and (as you know) quite some packages fail to compile against it. Having the resources, it would be possible to track these packages faster instead of relying on random users/testers to report them to bugs.g.o. And a last one would be testing new KDE/GNOME/whatever-meta-with-huge-number-of-packages. As an AT member myself I could only give examples on how using such system of donating/providing instances would be a benefit. For a comprehensive list of the tasks (for consistency as you said), I'd wait for actual devs to enumerate their needs. I doubt this will go as further as Gentoo actually *buying* resources. The reason is obvious - things have been going fine till now, why throw monnies for something as 'unnecessary' (which is why I haven't received a penny for it, hehehe), that's why I came with the donorship-of-instances version. I believe the 'going out looking for donors' part you said is basically what I'm suggesting here, although I believe you meant donors = huge companies providing clusters, and I doubt that'll happen. From my observation, you can get a lot of work done on a simple 2GB-ram-4-cores VirtualBox VM. Not to talk that lots of people nowadays have these resources to spare. That's why getting actual people (and not companies or whatever) to donate their system resources is easier to get/reach. Regards, Denis M. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Suggestion: support the Dev team with system resources
Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: * They're doing some other tests at the moment * They're on ~arch and need stable * They're not on the architecture needed for that testing * Their system is not 'powerful' enough * etc... The purpose of doing this is that the developers that have the time and dedication would be able to run a couple of different tests concurrently, on different 'instances' provided by the community. That will greatly, IMHO, improve the team's performance and not only in the AT field. The instances provided wouldn't forcefully need to meet any specific minimum requirements (this would be decided once (and if) this gets accepted), but a dual core system with 512MB ram would be somewhat an acceptable instance for the bigger arches (x86 amd64), and maybe lower specs for the other arches[1]. As an example here, I'm giving Ago a VirtualBox VM with 2GB ram and 4 virtual CPUs. Also, for the contributors there shouldn't be any minimum uptime to meet, they'll run the instances the time they use their systems, and if they leave them idle all day/night that would just be better, although they should be able to specify to the team normally the hours their systems would be usable by the devs. There should be a list of users that are able to share their resources and each dev(s) would be given a certain number of instances depending on their needs and such. I know that you might think that doing this will lower the contributor's desktop experience (as VMs tend to be somewhat heavy while compiling). The usage of the AUTOGROUP kernel scheduler and cgroups tends to make the desktop very much usable under high CPU pressure. Please review this, and if you agree that it'd be a good idea come with any suggestions to make it happen as well as with any other thoughts/sys-specs/instances we should be looking for. If you don't think this is a good idea or that it won't profit the Gentoo dev team, please tell me why. Regards, Denis M. (Phr33d0m) PS: This is a re-send as I firstly sent it without subscribing to the ML. So sorry if you receive it 2 times. [1] I apologize if this statement is wrong, it's based of my 0 knowledge on the other arches and the resources they need. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:37 AM, Andreas K. Huettel wrote: Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.: Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: ... I appreciate the idea, but security-wise it's pretty dangerous - given that you as a Gentoo dev are doing sensitive work that may affect many people on a machine not controlled by you yourself nor Gentoo Infra. I completely agree with this, but it's not entirely true. Why? I'll give the example of the AT team: 1. You sync the tree before you start your work (that way you verify the tree is clean). 2. Then you start testing the packages or bugs you're after, which in matter of security is meaningless because testing packages is usually just compiling and running to see if it works as expected. 2.1. Apply random patches to fix if there's an issue. 2.2. goto 2. 3. etc... I see no issue in this in matter of security. Another example would be devs testing packages under development (internal usage in gentoo), for example how new versions of openrc/systemd/glibc/whatever can affect X. I do understand your concern, although I wouldn't call you paranoid as it's just normal to not trust a system that's not completely under your control, but as I said, you don't really... 'care' about it/that. Call me paranoid, but please no. And in absolutely no case one should commit to the tree from such a machine, even with stuff like agent forwarding. Of course! Commiting or any other form of direct communication with the gentoo infra. (either commit to tree or `git push`-ing to any of the other gentoo repos) would be highly discouraged, and I didn't, in any moment, think someone would think of doing that :P. The idea behind this is using the provided instance only and exclusively for testing something you'd normally can't do on your system. Regards, Denis M. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Expanding categories' descriptions
Hello, (I was redirected from gentoo-doc@ to ask this here.) I think it's a good idea to expand the categories' descriptions (found in the corresponding metadata.xml files) with more accurate descriptions of which packages are welcome to fit in which categories. The current descriptions are very vague and aren't probably in the best shape to bring users' a good idea what certain category is about and what packages are to be found there. This can also be an issue for (new) ebuild-writers (either user-contributed ebuilds or just gentoo developers that are not sure about it either). This is of course checked by a gentoo developer if new ebuilds are to be submitted via the bugzilla, but I still think we should provide a better understanding of the categories. If expanding the metadata.xml files does not seem a good idea, we should at least make a little bit more comprehensive description somewhere in the gentoo.org/doc/ or wiki.gentoo.org pages. What do you think about it? Regards, Denis M. (Phr33d0m) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Add HEXCHAT_PLUGINS to USE_EXPAND
On 03/28/2013 02:56 PM, Zac Medico wrote: On 03/27/2013 05:52 AM, Gilles Dartiguelongue wrote: Le mardi 26 mars 2013 à 22:28 +0100, Denis M. a écrit : On 03/21/2013 02:09 PM, Denis M. wrote: Hello, I'd want to ask if it's possible and a good idea to add HEXCHAT_PLUGINS to the global USE_EXPAND var. HEXCHAT_PLUGINS has been created as a user (and maintainer) request in bug 461972 [1] to handle easily the net-irc/hexchat plugins that this package offers, which are: checksum, doat, fishlim and sysinfo. The purposed ebuild can be found on the bug's attached files list. Regards, Denis M. (Phr33d0m) [1] https://bugs.gentoo.org/show_bug.cgi?id=461972 Bump. Hi again, could I get a decisive answer on this please? That does not sound like a bad idea, however I wonder how this extends exactly if we start to do this for ebuilds which install a couple of plugins behind a few regular USE flags nowadays like rhythmbox, abiword, etc. The only potential problem that I can think of is that it bloats the environment with an extra variable that's exported to all ebuilds. With older kernels, environment bloat triggered E2BIG errors, as reported in this bug: https://bugs.gentoo.org/show_bug.cgi?id=262647 Thanks for your replies. As I commented on the hexchat bug, I've decided to use plain USE flags like plugin-... to handle this situation. Also, now I have a better understanding of when to use USE_EXPAND. Regards, Denis M. (Phr33d0m) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Add HEXCHAT_PLUGINS to USE_EXPAND
On 03/21/2013 02:09 PM, Denis M. wrote: Hello, I'd want to ask if it's possible and a good idea to add HEXCHAT_PLUGINS to the global USE_EXPAND var. HEXCHAT_PLUGINS has been created as a user (and maintainer) request in bug 461972 [1] to handle easily the net-irc/hexchat plugins that this package offers, which are: checksum, doat, fishlim and sysinfo. The purposed ebuild can be found on the bug's attached files list. Regards, Denis M. (Phr33d0m) [1] https://bugs.gentoo.org/show_bug.cgi?id=461972 Bump. Hi again, could I get a decisive answer on this please? Thanks in advance, Denis M. (Phr33d0m) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Add HEXCHAT_PLUGINS to USE_EXPAND
Hello, I'd want to ask if it's possible and a good idea to add HEXCHAT_PLUGINS to the global USE_EXPAND var. HEXCHAT_PLUGINS has been created as a user (and maintainer) request in bug 461972 [1] to handle easily the net-irc/hexchat plugins that this package offers, which are: checksum, doat, fishlim and sysinfo. The purposed ebuild can be found on the bug's attached files list. Regards, Denis M. (Phr33d0m) [1] https://bugs.gentoo.org/show_bug.cgi?id=461972 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: net-irc/xchat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2012 09:27 PM, Lars Wendler wrote:
Hey list,
I'm planning to lastrite net-irc/xchat in the next couple of weeks.
Unfortunately my hope that upstream development would be resumed
didn't come true. As the code becomes more and more outdated, open
unfixed security bugs are present[1][2] and at some point in the
future =x11-libs/gtk+-2* will vanish from the tree I don't see any
other option than removing xchat from the tree. I don't see this as
a big drama as we already have a drop-in replacement in form of the
net-irc/hexchat fork.
Hello, I'd have to mention, as HexChat is a fork from XChat it strictly
depends on gtk+-2 as well. So removing gtk+-2* will make HexChat
unusuable (at least the GUI). Also there are no plans on porting it to
anything like gtk+-3 (or Qt (I have to say I'd love that)).
I checked this today and all people have to do is emerge hexchat
and then copy over the xchat config: mkdir ${HOME}/.config ; cp -a
${HOME}/.xchat2 ${HOME}/.config/hexchat
Since hexchat-2.9.4 they also have to move their xchat.conf file to
hexchat.conf (this reminder message displays after emerge).
I'd like to see your opinion on this matter as long as you have
one you'd like to share with me ;) Furthermore I would shift my
attention from the xchat package to hexchat seeing that it
currently gets proxy maintained. If there's no objection I'd like
to become the new contact of the person currently maintaining the
package in portage.
Unfortunately I have some bad news here. The same way XChat's
development died some time ago (with the exception of some critical
patches here and there), HexChat's development has met a wall. The only
active developer has quit the project. I hope this does not mean the end
of the project as there are a couple of contributors who seem interested
in further developing HexChat (they have write access to hexchat's
github repo so further versions will depend on them).
Answering some questions already on this topic, hexchat has it's own
system info script, so xchat-sys is pointless for hexchat (although it
might work - yes, or what hasufell saw was the built-in working and
not the xchat-xsys plugin).
Also, since hexchat-2.9.4 there is no more tcl/lua support. All other
plugins are supported without issues.
There's only one thing to be noted here, there are some perl/python
plugins which make use of xchat packages. Which means that, if you
see something like this: package Xchat:: inside your plugin you have
to remove that line, otherwise hexchat won't be able to load the script.
Regards,
Denis M.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAEBAgAGBQJQsqnjAAoJEB4Ut/VlCFMUKu4QAJO++p1KvDZe327MGkX5eXaA
nj6Aoz6L403evdyfsqpT8WU4nlfmCePMj1wIoH5zFVckIFMbFKop0BSsbKHuMSid
Wk0UWZgrXg+gz2SDFhj+KSoEYKah//FREnvnngl2nQ7ukesA52BQm734Y+xV0fxD
cvZpyZ9KUYphgmjXWrAhfMf5WMmgegNG9SRsiZ4/d80qry/NQ3ehdsqujhQGxBG9
TGNoaqUS3Dx2Qa+YAZqrNGM5CnOVdi+DdKWj53P4eoq6jtGjY9B+DQsMpi3oIaH/
I0T1frlbLHrvZrXQ+LkDemmRPnYQH7p9CvizB6eOBGnh+HxZ+LDuAriJwJHXAKDh
1U20XcAY6tBV6jXI3KFNU1PpWkuDzO4yYTwOHtxTX4XIPUek1J33w+FiQZPO3z6q
G2fDRX8CZLsGyGGbJ2v0WHukq2tKpXMPVeZkniHvSldz+b4/BuYHuvebobn7A7tN
7BdyxIBWrgbp1eH+oaBby5h+pM3bwMhbRCLWFSlDBfoxtW4UIp9TnkctTXprb34S
YUmfgr2RoGysJo3bpUFYjN5evcTt9NIJQ4aU7Knd+7C6S0+LLrjoWN0TfkEttF1w
3+Cq8orE8u4YktwTm6NX9yGO/3YGFveOY6jfDNxgoMbmg7ajmlCDV2fN2y+szglM
hGSRkGcWWyZbKszi7CjP
=wVks
-END PGP SIGNATURE-
[gentoo-dev] Re: net-irc/xchat
On 11/25/2012 09:27 PM, Lars Wendler wrote:
Hey list,
I'm planning to lastrite net-irc/xchat in the next couple of weeks.
Unfortunately my hope that upstream development would be resumed
didn't come true. As the code becomes more and more outdated, open
unfixed security bugs are present[1][2] and at some point in the
future =x11-libs/gtk+-2* will vanish from the tree I don't see any
other option than removing xchat from the tree. I don't see this as
a big drama as we already have a drop-in replacement in form of the
net-irc/hexchat fork.
Hello, I'd have to mention, as HexChat is a fork from XChat it strictly
depends on gtk+-2 as well. So removing gtk+-2* will make HexChat
unusuable (at least the GUI). Also there are no plans on porting it to
anything like gtk+-3 (or Qt (I have to say I'd love that)).
I checked this today and all people have to do is emerge hexchat
and then copy over the xchat config: mkdir ${HOME}/.config ; cp -a
${HOME}/.xchat2 ${HOME}/.config/hexchat
Since hexchat-2.9.4 they also have to move their xchat.conf file to
hexchat.conf (this reminder message displays after emerge).
I'd like to see your opinion on this matter as long as you have
one you'd like to share with me ;) Furthermore I would shift my
attention from the xchat package to hexchat seeing that it
currently gets proxy maintained. If there's no objection I'd like
to become the new contact of the person currently maintaining the
package in portage.
Unfortunately I have some bad news here. The same way XChat's
development died some time ago (with the exception of some critical
patches here and there), HexChat's development has met a wall. The only
active developer has quit the project. I hope this does not mean the end
of the project as there are a couple of contributors who seem interested
in further developing HexChat (they have write access to hexchat's
github repo so further versions will depend on them).
Answering some questions already on this topic, hexchat has it's own
system info script, so xchat-sys is pointless for hexchat (although it
might work - yes, or what hasufell saw was the built-in working and
not the xchat-xsys plugin).
Also, since hexchat-2.9.4 there is no more tcl/lua support. All other
plugins are supported without issues.
There's only one thing to be noted here, there are some perl/python
plugins which make use of xchat packages. Which means that, if you
see something like this: package Xchat:: inside your plugin you have
to remove that line, otherwise hexchat won't be able to load the script.
Regards,
Denis M.
