This new version adds support for making and submitting screenshots of the actual desktop, of course only if the user wants this. The user must start the client with the -s option, to let him submit the screenshot. it also fixes some bugs, which caused to not be able to login to the page with the unique_key. The dependency on wget was now removed, the client send the data now with the python-functions. But there is also a new dependency on scrot, which is needed to take the screenshot. For more details or more changes, please read the changelog here: http://www.gentoo-stats.org/index.php?c=changelog There were again no system- or arch-dependent changes so the client is already stable on the as stable marked arches. Please add this to the tree, thanks. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 47854 [details] basc-1.5.5.ebuild
This needs input from a security perspective (added dsd to the cc field). Imho the "show limited system information when user enabled it in the preferences"-feature is ok. Screenshots are a different issue: Instead of automatically making one, you could ask the user to manually make one after showing a HUGE disclaimer. Nevertheless you'll have to ensure people don't post goatse.cx pictures, that the screenshot does not contain enough info such as hostname, usernames, kernel version, ... It might be a better idea to have the user contribute wallpapers instead of screenshots, but you'll have to do some moderating I guess.
pvdabeel, I've discussed this with the Koon from the security-team in #gentoo-security. He said, this would be okay, as it is now. The screenshot is an jpeg-image with compression rate 70. It also will be resized to a width of 500px by the sys-overview-page automatically and then compressed by the rate 65. There is absolutley no possibility to see a hostname or a kernelversion or something like this, because it is definitley much too blurred, unless the user places a string on his desktop which is larger than 48px. This explains also the Preferences-page too, on which every user *must* enable this publishing of his system-overview. So there should really be no problem with this.
btw. here is an example on how it looks like: http://www.gentoo-stats.org/index.php?c=userpage&sys=1302
I think that showing system details violates the privacy policy you agreed to. If you really insist on doing this, you need to get the user to agree to it first. Default disabled. My patience is running low..
Well this would be the smallest problem, I think. Perhaps the following text, as it'll be shown on the preferences-page, would be enough? "Attention: By enabling the publishing of your system to other users, you're agreeing with our <a href="http://www.gentoo-stats.org/index.php?c=privacy">Privacy Policy</a>. Please read it carefully."
No, my point is that publishing info about that violates the privacy policy (or at least the way I see it..)
so what to do? There *must* be the possibility to provide some "special" functions to the users. Such a system-overview which could be published by the user himself could be such a special fearure (a user-magnet). Can we modify this policy or write another one or something like that? The point is, that this all is absolutley anonymous, so it is safe for every user. There is no possibility to get information about hostnames, software-versions or something else. So, why it shouldn't be possible???
It would be nice, if there could be any suggestion or solution for this soon.
It appears that I misinterpreted some of these new features. Will investigate further tomorrow. I trust pvdabeel to give feedback and commit this when it is ready.
okay, is there any chance, to get this ebuild into the tree then?
#3 is enough to put me at ease. New version has dependencies that need stable masking on hppa and mips. cc'ing those archs: Mips, hppa please mask media-gfx/scrot stable.
We don't mark things stable without going through proper testing first. You should be doing the same for basc and not committing ebuilds straight to stable. Read the frickin' policy docs...
giblib/scrot now have ~hppa
Could this screenshot taking be made under a use flag? I don't want to install scrot because of a feature I am not going to use.
I've just modified the ebuild of 1.5.6 to make use of the USE-Flag "screenshot". It the useflag screenshot is set, then scrot (and dependencies) will be installed, if not, then even not... I'll relase this 1.5.6 in the next one or two days, so I've a bit more time to find one or two more bugs to fix.
I'm just wondering why this has mips keywords at all? Did whoever comitted this crap have a mips box to test the app on? And no, I'm not going to test it because I feel (and it seems like most of the mips team agrees) that we don't like the idea of publishing statistics of our machines on a server that isn't an official gentoo box.
As you can see here: http://www.gentoo-stats.org/index.php?c=archstats, it is running great on mips(64). And, btw, nobody knows which machine belongs to which user. So there is no need to be afraid or angry about these statistics, which at first should help the devs! And again btw, we are working to make this project an official gentoo project, so don't worry, but stay tuned.
You completely missed the point. An ebuild is *not* to have arch keywords unless a dev from that arch team has keyworded it. That is gentoo policy.
okay, this might be the policy of gentoo, but I'm also knowing, that the *main* idea behind gentoo was to provide a distribution in which every user can decide whether to use a program, to modify a configuration, to change *everything* as he wanted to, or not. But if you (the devs) now are deciding if a user is allowed to use a program or not, this will break this glorious idea behind gentoo. Well, I'm very far away from wanting to make prescriptions to you (the devs). But this is, what I'm and what many, neally all other users in the german channels are thinking about this point. But, however, this is your distribution. So do, what you want to do... *My* point is, to make it available as "testing" (~keyword) to as many users as even possible and *then* to figure out if it is stable or not.
but hey... we are working on make this project official, so I should learn to play in your liga. If your way is the official and correct way gentoo should go, I'll learn to go this way too...
You again miss the point. The problem with keywording something on an arch you can't test is that you don't know if it works on that particular arch, and you don't know if it will break the portage tree. There have been arch specific bugs on things as simple as scripts (because things like python or perl don't behave exactly the same on all arches). The standard procedure for getting something keyworded is to file a bug with a CC for all arches asking them to test and keyword. In this case, it went in with keywords...clearly wrong. As a perfect example of breaking deps, you added the media-gfx/scrot dependancy, which has no mips keywords...oops! If whoever added the mips keywords in the first place had been able to test on mips, then they would have also been able to test scrot on mips, thus keywording both.
yeah, okay, from this view you might be right. I've already thought about this scrot thingy and I've also already changed the dependency on scrot in the ebuild for 1.5.6 to an IUSE="screenshot" and a RDEPENT of ?screenshot(media-gfx/scrot) So this way should be correct then... And, btw, I'm making this free to every dev to change this in the ebuild for 1.5.5 too.
I would like to apologise for the comment I made yesterday, it appears that I jumped to some conclusions about the new features. I have looked in more detail, and sent my remaining concerns to Pieter, who will relay them on.
Created attachment 47981 [details] basc-1.5.5.ebuild fixed dep. This is the modified ebuild with the fixed dependency on media-gfx/scrot, which should now only be emerged, if the USE-flag "screenshot" is set.
mips keywords removed from all versions, since they were never added legitimately. Do not add them back in without explicit permission from someone on the mips team.
I'm not happy about the way we, gentoo developers, handled this entire mips keyword thing. mips people, we were not correct to assume that because the older versions of the client had successfully registered mips systems, those older versions could also be added with the mips keyword. In other words we assumed you had tested the mips ebuild by registering two machines. That was clearly a misunderstanding. Our apologies for that. My #12 comment was intended as a test request for the new ebuild, which was NOT keyworded on mips and hppa. From my conversations on irc with the mips developers I had the impression that the client not sending PCI data to the server was interpreted as a bug. We are aware that mips machines lack pci, just like some ppc and old x86 machines lack pci. As far as I can tell sending pci data to the server was never a requirement. If you have other "inconveniences" regarding this application, both client or server side, please do not hesitate opening a bug about it. Or sending Alexander some feedback. To the author of comment #22: I added the ebuild in question to the tree with KEYWORDS="x86 sparc ppc amd64 ~ppc64" As you can see there is NO MIPS KEYWORD, NOR ~MIPS, NO HPPA and NO ~HPPA EITHER. This bug was intended as a test request for the new ebuild I've added -without- keywords on your architecture. As you probably know repoman would have prevented me from doing what you're saying I did, so I'm not sure what the point you're trying to make is since I didn't do what you're saying I did. I did however incorrectly assume that the -older- ebuilds which had registered mips machines were tested, so those were indeed keyworded. Those didn't have any dependencies on applications that are not currently mips keyworded. To the author of comment #17: "Did whoever comitted this crap" I was the one committing this "crap". For starters, why don't you start explaining me or Alexander why you think what I committed was "crap" so we can improve things? And yes, I have a mips box, an Octane ip30 R12K dual 400 with 1G ram and 18G HD. It has Octane2 blue skins, a broken lightbar and a SGI 21inch monitor attached to it. It has Irix 6.5 installed and netboots Gentoo Linux (It lacks a cdrom, which I'm hoping to buy to help make a livecd for the machine.). Is there anything else you want to know? To the author of Comment #26: I have added the mips team again to this 'please test and mask accordingly bug'. Please test and report back as requested in comment #12 so we can fix whatever renders the application "broken" on mips.
To back up what I was saying: revision 1.2 date: 2005/01/09 01:49:03; author: ciaranm; state: Exp; lines: +2 -2 Remove mips keywords, since it hasn't been tested by a mips developer. Whoever added that keyword was in serious violation of policy. Do not add mips back in without explicit permission from someone on the mips team. Changes: --- # Copyright 1999-2004 Gentoo Foundation +++
To back up what I was saying: revision 1.2 date: 2005/01/09 01:49:03; author: ciaranm; state: Exp; lines: +2 -2 Remove mips keywords, since it hasn't been tested by a mips developer. Whoever added that keyword was in serious violation of policy. Do not add mips back in without explicit permission from someone on the mips team. Changes: --- # Copyright 1999-2004 Gentoo Foundation +++ # Copyright 1999-2005 Gentoo Foundation 1.5.5 did not have the mips keyword in it. And I've explained why we assumed the older ones were tested (because mips machines were registered.) Currently 0,31% of all 949 registered machines are mips machines. Again our apologies for assuming the machines registered were yours.
Re comment #28 -- check the entire changeset, you'll see that the mips keyword was removed from several ebuilds.
After speaking to the author of Comment #29 on irc, it is clear that there are indeed no intentions of testing the ebuild for this python script. I therefore consider this issue closed. My apologies to the hppa team for accidentally cc'ing them (browser auto-complete).
