Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On Tue, 2011-06-07 at 20:16 +0200, Ulrich Mueller wrote: Even if it fulfills the restrictions for global variables, it is still an abuse of the spec, because PMS defines S as follows: The full path to the temporary build directory, used by src_compile, src_install etc. I don't see how setting S violates this specification. For each ruby implementation that we build for the definition of S holds. It just has a different value for each implementation. And for EAPI 4 it will fail, because S is required to exist as initial working directory in most src_* phase functions. Correct, so in EAPI 4 we now set the RUBY_S variable to handle the initial setup, and then we set S as part of the environment setup when we are iterating through each ruby implementation within each of the PMS phases. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On Wed, 08 Jun 2011, Hans de Graaff wrote: Even if it fulfills the restrictions for global variables, it is still an abuse of the spec, because PMS defines S as follows: The full path to the temporary build directory, used by src_compile, src_install etc. I don't see how setting S violates this specification. For each ruby implementation that we build for the definition of S holds. It just has a different value for each implementation. The value of S that is assigned in global scope (i.e. the one containing the wildcard) violates it. Ulrich
Re: [gentoo-dev] Reducing glibc's default locale.gen
On 6/7/11 9:53 PM, Matt Turner wrote: Building 400~ locales is not fun on mips when building stages. Do you have some data to quantify not fun? How long does it take? No user has a need for more than some small subset of the total available locales. I filed bug [1] to request the ability to select locales in catalyst spec files, but no responses after six months -- which is totally typical of catalyst bugs. I commented in bug [2] suggesting that we perhaps reduce the default locale.gen to only 'en_US.UTF-8 UTF-8' or some other limited subset. It makes sense to me, especially for exotic arches. It seems that locale-gen is cheap anyway on x86 and amd64, where it probably matters most. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
@council: We need to discuss ways to improve the current policy. See below. On 06/07/11 23:09, Mike Frysinger wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. It was not only that, and the situation escalated as people tried to lawyer around instead of doing something productive like writing a perl script to wrap the nonsense so they can ignore it. Result was an unambiguous policy so that no lawyering happens and all ChangeLogs make sense. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. So you say that you want to follow the rules but accidentally forgot it? Since it has caused so much trouble I'd like to see it discussed and improved by the council. I disagreed with the initial strict wording, and I think the fallout has shown that we need to find a common ground so that no one feels he has to ignore the rules. if you want useless information, then automate it. there's no reason at all to not do so. i prefer to keep useful information in the changelogs of packages i maintain without cluttering up with noise. -mike Here's the problem. Useful depends a lot on the context. Sometimes I only care about a new addition. Sometimes I care about when and how a patch was introduced. Sometimes I care about removals because some monkey has broken things for me. In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. Cheers, Dirkjan
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, 8 Jun 2011 11:28:47 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. What if we wanted to remove ChangeLogs then for autogeneration? Will we require all devs to quickly update their portage versions? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/08/11 11:43, Michał Górny wrote: On Wed, 8 Jun 2011 11:28:47 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. What if we wanted to remove ChangeLogs then for autogeneration? Will we require all devs to quickly update their portage versions? Just make committing the ChangeLog fatal on the server side ;) There are enough ways to get it done ... -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/08/2011 12:28 PM, Dirkjan Ochtman wrote: On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. Then repoman commit should have a flag to leave out removals from ChangeLog entries so unlazy people can still leave the cruft out from them. Ref. http://bugs.gentoo.org/show_bug.cgi?id=365373
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 11:45, Samuli Suominen ssuomi...@gentoo.org wrote: IMO we should just make repoman commit update the ChangeLog. Then repoman commit should have a flag to leave out removals from ChangeLog entries so unlazy people can still leave the cruft out from them. Ref. http://bugs.gentoo.org/show_bug.cgi?id=365373 I disagree; I think having the information about removed packages is useful. Cheers, Dirkjan
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Dale posted on Tue, 07 Jun 2011 22:45:34 -0500 as excerpted: Mike Frysinger wrote: On Tuesday, June 07, 2011 19:41:20 Dale wrote: I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. umm, no, ive done no such thing. try again. -mike Let me see if I understand this correctly. Most devs and some users wants things put in the changelog. I don't know if it was you before but in the past someone didn't want to put when versions are removed. That person, whoever it was, said they were not going to do it because it was silly or whatever. This was taken to the council and it was decided that all changes had to be put in the changelog. Now in this thread, about the same thing from my understanding. You said waste of time and the policy is not sane. So, council says it has to be done. You say you won't. Tell me where I missed the point here. Mike's actually correct. He didn't say he was going to defy council, rather, that he simply wouldn't be removing ebuilds /at/ /all/ until either the changelog is auto- generated (making the case moot) or the council changes policy. That means they'll either fall to someone else to do, or will simply remain there, but either way, it's quite different from directly defying the council decision. Gentoo devs are volunteers in any case, and as such, the system, to the degree that it works at all, does so because volunteers are (within reason) allowed to have their foibles and the system ultimately works around them. Because everyone has their foibles and if the system couldn't work around them, the system would quickly cease to be! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 7:17 AM, Duncan 1i5t5.dun...@cox.net wrote: He didn't say he was going to defy council, rather, that he simply wouldn't be removing ebuilds /at/ /all/ until either the changelog is auto- generated (making the case moot) or the council changes policy. That means they'll either fall to someone else to do, or will simply remain there, but either way, it's quite different from directly defying the council decision. As long as all versions in the tree compile cleanly and are free from security issues, I don't see any issue with keeping older ebuilds around. If anything I think that some packages are too quick to remove ~arch versions. I run stable but accept the odd ~arch package. When I do accept a ~arch package I only accept one version of it with the goal of going stable once whatever drove me to accept ~arch gets there. When the ~arch package disappears I just have to re-evaluate my new options and try again, and sometimes it feels like I never end up in stable. (I do realize that a few types of packages will probably never be stable by their nature, and that is fine.) If old versions become QA issues then we already have processes to deal with that. It is the duty of maintainers to deal with such problems. In any case, the rule is simple - if you remove an ebuild you have to include a note in the Changelog. That could change, or it might not, or perhaps it will become automated, but either way it is the rule right now. One thing I will say is that I appreciate the civility in this thread so far. I think everybody on both sides of the issue realizes that this is contentious, and I think everybody would be open to a better solution. Rich
Re: [gentoo-dev] Reducing glibc's default locale.gen
On Wed, Jun 8, 2011 at 3:40 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 6/7/11 9:53 PM, Matt Turner wrote: Building 400~ locales is not fun on mips when building stages. Do you have some data to quantify not fun? How long does it take? To build glibc - once for the n32 ABI with only the en_US.UTF-8 locale: 1h 15m - three times for o32/n32/n64 ABIs with only en_US.UTF-8: 4h 50m - three times for o32/n32/n64 ABIs with all locales: 6h I can reconfirm how long it takes just by running locale-gen on all locales, but according to my numbers it takes 1h 10m to generate all the locales. The o32/n32/n64 configuration is what I've been planning to ship as a compromise between shipping only a single ABI and a set of stages for every ABI, but each ABI adds significant time, and n32 replaces o32 so I'll just plan to drop o32. So roughly the time required to build all the locales is equal to the time to build glibc for a single ABI. No user has a need for more than some small subset of the total available locales. I filed bug [1] to request the ability to select locales in catalyst spec files, but no responses after six months -- which is totally typical of catalyst bugs. I commented in bug [2] suggesting that we perhaps reduce the default locale.gen to only 'en_US.UTF-8 UTF-8' or some other limited subset. It makes sense to me, especially for exotic arches. It seems that locale-gen is cheap anyway on x86 and amd64, where it probably matters most. Good, thanks for your feedback. Matt
Re: [gentoo-dev] RFC: remove annoying You should enable -g (or higher) for debugging! message
On 5/7/11 4:20 PM, Paweł Hajdan, Jr. wrote: This is mostly a nit-like RFC. The developer profile adds a profile.bashrc, which prints the You should enable -g (or higher) for debugging! message when -g is not in CFLAGS. I wonder if we can remove that file. It has been added 3 years ago: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/developer/profile.bashrc?view=markup It is not obvious from looking at emerge output what prints this message, it doesn't fit well with the rest of the output, and may be easy to miss: * USE:elibc_glibc gtk kernel_linux test userland_GNU x86 * FEATURES: sandbox splitdebug test userpriv usersandbox You should enable -g (or higher) for debugging! Unpacking source... Unpacking mtr-0.80.tar.gz to /var/tmp/portage/net-analyzer/mtr-0.80/work I think it is not necessary for every developer to add -g to CFLAGS - the main point is to have any symbols at all, not just to-the-file-and-line-precise debugging info. If the latter is needed, the developer will obviously know what to do. What do you think about removing gentoo-x86/profiles/targets/developer/profile.bashrc file? FYI: I went ahead and committed the change. Enjoy a slightly simpler developer profile! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: removal of net-print/foo2zjs-99999999 (earlier versions are fubar)
On 6/2/11 5:20 PM, Paweł Hajdan, Jr. wrote: I'd like to remove net-print/foo2zjs-. Non-live versions are severely outdated (2008) and unusable (upstream changes tarballs in-place, digest verification is broken). I went ahead and committed the change. I might try to provide some non-live ebuild in the future, and of course help is welcome. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: removal of net-print/foo2zjs-99999999 (earlier versions are fubar)
On Wed, 08 Jun 2011 16:09:53 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 6/2/11 5:20 PM, Paweł Hajdan, Jr. wrote: I'd like to remove net-print/foo2zjs-. Non-live versions are severely outdated (2008) and unusable (upstream changes tarballs in-place, digest verification is broken). I went ahead and committed the change. I might try to provide some non-live ebuild in the future, and of course help is welcome. BTW if you'd like to create an eclass for that kind of live packages (which fetch packages from upstream), I could add smart rebuild possibility to start-live-rebuild [1]. This way, foo2zjs users would be able to upgrade their package whenever upstream tarball changes. [1]:https://github.com/mgorny/smart-live-rebuild -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Gentoo package statistics -- GSoC 2011
Hi everyone, I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: * Uname, portage profile, timestamp of portage tree * ARCH, CHOST, CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS, MAKEOPTS * ACCEPT_KEYWORDS, FEATURES, USE, LANG, SYNC, GENTOO_MIRRORS * Repository, Keyword, Useflags (plus,minus,unset), Counter, Size, and Build time for each installed package Is there a need to collect files installed by a package ? Doesn't PFL[1] already provide that ? Please provide some feedback on what other data should be collected, etc. Also, I'm starting work on the webUI, and would like some recommendations for stats pages, such as: * Packages installed sorted by users * Top arches, keywords, profiles * Most enabled, disabled useflags per package/globally [0] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoostats.git;a=commit;h=1b9697a090515d2a373e83b1094d6e08ec405c02 [1] http://www.portagefilelist.de/index.php/Main_Page -- Vikraman signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On 6/8/11 4:36 PM, Vikraman wrote: I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: Excellent, good luck with the idea! I think that better information about how Gentoo is actually used will greatly help improving it. Is there a need to collect files installed by a package ? Doesn't PFL[1] already provide that ? Well, PFL is not an official Gentoo project. It might be useful, but I wouldn't say it's a priority. Please provide some feedback on what other data should be collected, etc. In my opinion it's *not* about collecting as much data as possible. I think it's most important to get the core functionality working really well, and convincing as large percentage of users as possible to enable reporting the statistics (to make the results - hopefully - accurately represent the user base). Please note that in some cases it may mean collecting _less_ data, or thinking more about the privacy of the users. For me, as a developer, even a list of packages sorted by popularity (aka Debian/Ubuntu popcon) would be very useful. Ah, and maybe files in /etc/portage: package.keywords and so on. It could be useful to see what people are masking/unmasking, that may be an indication of stale stabilizations or brokenness hitting the tree. Anyway, I'd call it an enhancement. Also, I'm starting work on the webUI, and would like some recommendations for stats pages, such as: * Packages installed sorted by users Cool! * Top arches, keywords, profiles And percentage of ~arch vs arch users? * Most enabled, disabled useflags per package/globally Also great, especially the per-package variant. It'd be also useful to have per-profile data, to better tune the profile defaults. [0] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoostats.git;a=commit;h=1b9697a090515d2a373e83b1094d6e08ec405c02 I took a quick look at the code. Some random comments: - it uses portage Python API a lot. But it's not stable, or at least not guaranteed to be stable. Have you considered using helpers like portageq (or eventually enhancing those helpers)? - make the licensing super-clear (a LICENSE file, possibly some header in every source file, and so on) - how about submitting the data over HTTPS and not HTTP to better help privacy? - don't leave exception handling as a TODO; it should be a part of your design, not an afterthought - instead of or in addition to the setup.txt file, how about just writing the real setup.py file for distutils? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
Wasn't there a project like this a couple of years ago which tried to use a cross-distro tool ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On Wed, 2011-06-08 at 09:17 +0200, Ulrich Mueller wrote: The value of S that is assigned in global scope (i.e. the one containing the wildcard) violates it. Ah, right, I initially read Donnie's quotation from PMS as an endorsement for our approach, but that is only true for our EAPI=4 solution where we only change S within a function. That leaves the question what to do with the approach for EAPI=2,3. I'd rather not risk breaking ebuilds by removing this support just for a violation of PMS if there is no real problem exposed by it. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On Wed, 2011-06-08 at 17:19 +0200, Paweł Hajdan, Jr. wrote: In my opinion it's *not* about collecting as much data as possible. I think it's most important to get the core functionality working really well, and convincing as large percentage of users as possible to enable reporting the statistics (to make the results - hopefully - accurately represent the user base). Please note that in some cases it may mean collecting _less_ data, or thinking more about the privacy of the users. +1 on this. Taking the extreme, I'd rather see a properly implemented architecture that is installed on 50% of Gentoo system just reporting on the arch, then something that collects a lot more data and is installed on 50 machines. Once the framework is in place and there is user uptake then it is easy to slowly extend the statistics collection and gather more useful data. For me, as a developer, even a list of packages sorted by popularity (aka Debian/Ubuntu popcon) would be very useful. That would be useful. Ah, and maybe files in /etc/portage: package.keywords and so on. It could be useful to see what people are masking/unmasking, that may be an indication of stale stabilizations or brokenness hitting the tree. Anyway, I'd call it an enhancement. I'd rather not see this in the initial gsoc project if that means we'll sacrifice a big rollout. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On Wed, 08 Jun 2011 17:43:38 +0200 Hans de Graaff gra...@gentoo.org wrote: That leaves the question what to do with the approach for EAPI=2,3. I'd rather not risk breaking ebuilds by removing this support just for a violation of PMS if there is no real problem exposed by it. The 'invariant' restriction on S in PMS is, strictly speaking, stronger than it has to be. However, working out exactly what set of weaker rules would be ok proved to be too difficult -- historically, Portage has had various different behaviours for global scope variables that are assigned variable values. Thus, PMS is the way it is there because we know for sure that if you follow those rules you're safe; if you don't, you'll definitely cause problems for EAPI 4, and you may or may not get away with it for earlier EAPIs. It's a bit like assuming that it's ok to dereference a null pointer and get a zero, since that's what one particular system does... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: removal of net-print/foo2zjs-99999999 (earlier versions are fubar)
On 6/8/11 4:17 PM, Michał Górny wrote: BTW if you'd like to create an eclass for that kind of live packages (which fetch packages from upstream), I could add smart rebuild possibility to start-live-rebuild [1]. This way, foo2zjs users would be able to upgrade their package whenever upstream tarball changes. [1]:https://github.com/mgorny/smart-live-rebuild Interesting, sounds like that could be useful. But I have no idea how such an eclass would look like (rather trivial), and there are not many packages that would use it (currently just one). How about PROPERTIES=live? We could add live to possible values of PROPERTIES... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: removal of net-print/foo2zjs-99999999 (earlier versions are fubar)
On Wed, 08 Jun 2011 18:14:49 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 6/8/11 4:17 PM, Michał Górny wrote: BTW if you'd like to create an eclass for that kind of live packages (which fetch packages from upstream), I could add smart rebuild possibility to start-live-rebuild [1]. This way, foo2zjs users would be able to upgrade their package whenever upstream tarball changes. [1]:https://github.com/mgorny/smart-live-rebuild Interesting, sounds like that could be useful. But I have no idea how such an eclass would look like (rather trivial), and there are not many packages that would use it (currently just one). How about PROPERTIES=live? We could add live to possible values of PROPERTIES... That won't be enough. s-l-r has to get somehow the method of checking and the URL list. Right now, it is constructed in such a way that the method is based on VCS eclass being inherited, and then it grabs appropriate ebuild vars from environment.bz2. Such an eclass would have to take tarball URIs in some kind of envvar and export some kind of 'download timestamp'. Then the Python module in s-l-r would HEAD those URIs to get the current timestamp and compare that to the value exported in environment.bz2. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: removal of net-print/foo2zjs-99999999 (earlier versions are fubar)
On 6/8/11 6:25 PM, Michał Górny wrote: Such an eclass would have to take tarball URIs in some kind of envvar and export some kind of 'download timestamp'. Then the Python module in s-l-r would HEAD those URIs to get the current timestamp and compare that to the value exported in environment.bz2. Feel free to suggest such an eclass and/or file an enhancement bug for the package, but for now I probably won't be able to work on that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 23:44:49 Michał Górny wrote: On Tue, 7 Jun 2011 17:45:03 -0400 Mike Frysinger wrote: On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote: On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? the tree has already been migrated. automatic ChangeLog generation is trivial to implement, and many many projects already have scripts to do it. Including portage's egencache which can generate ChangeLogs from git. Just a side note. very cool ... wasnt aware of that guy, thanks -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 23:45:34 Dale wrote: So, council says it has to be done. You say you won't. Tell me where I missed the point here. you missed the point as soon as you incorrectly stated that i said i wont. thus the rest of your e-mail is useless noise. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wednesday, June 08, 2011 05:27:27 Patrick Lauer wrote: So you say that you want to follow the rules but accidentally forgot it? no idea what you're talking about. the new policy has 0 relevance to actions performed before said policy went into effect. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Council 2011 / 2012 election nomination
On 2011.06.08 01:50, David wrote: I nominate William Hubbs (williamh) -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/ David, It has to be on gentoo-proj...@lists.gentoo.org or it doesn't count. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpdugPopnPER.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On 08.06.2011 18:36, Vikraman wrote: Hi everyone, I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: * Uname, portage profile, timestamp of portage tree * ARCH, CHOST, CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS, MAKEOPTS * ACCEPT_KEYWORDS, FEATURES, USE, LANG, SYNC, GENTOO_MIRRORS * Repository, Keyword, Useflags (plus,minus,unset), Counter, Size, and Build time for each installed package May be collect hardware info kernel configs too? For example cpuinfo, lspci and lsusb(?). I think, that after 1-3 month after installing gentoo, user can(should) receive newsitem about participating in `Package statistics` project. This newsitem can contains short instruction how-to install and configure this tool. And even in other gentoo projects(for example write short wiki page) And, where can I found ebuilds to the `Package statistics` project? Sory for my english... and Good luck!
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 1:06 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 08, 2011 05:27:27 Patrick Lauer wrote: So you say that you want to follow the rules but accidentally forgot it? no idea what you're talking about. the new policy has 0 relevance to actions performed before said policy went into effect. -mike Right, to be perfectly clear, the initial email in this thread was from halcy0n (May 16), and it was about something that happened before the new policy. Mike's first reply in this thread was after the new policy and was 3 weeks later on Jun 7. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wednesday, June 08, 2011 13:40:49 Matt Turner wrote: and was 3 weeks later on Jun 7. i havent had much time for Gentoo lately :/. but maybe people think that's good so i'll stop being a hassle. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On Wed, Jun 08, 2011 at 05:19:33PM +0200, Paweł Hajdan, Jr. wrote: On 6/8/11 4:36 PM, Vikraman wrote: I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: Excellent, good luck with the idea! I think that better information about how Gentoo is actually used will greatly help improving it. Well, that information cannot be collected automatically, can it ? Is there a need to collect files installed by a package ? Doesn't PFL[1] already provide that ? Well, PFL is not an official Gentoo project. It might be useful, but I wouldn't say it's a priority. Please provide some feedback on what other data should be collected, etc. In my opinion it's *not* about collecting as much data as possible. I think it's most important to get the core functionality working really well, and convincing as large percentage of users as possible to enable reporting the statistics (to make the results - hopefully - accurately represent the user base). Please note that in some cases it may mean collecting _less_ data, or thinking more about the privacy of the users. For me, as a developer, even a list of packages sorted by popularity (aka Debian/Ubuntu popcon) would be very useful. Ah, and maybe files in /etc/portage: package.keywords and so on. It could be useful to see what people are masking/unmasking, that may be an indication of stale stabilizations or brokenness hitting the tree. Anyway, I'd call it an enhancement. Also, I'm starting work on the webUI, and would like some recommendations for stats pages, such as: * Packages installed sorted by users Cool! * Top arches, keywords, profiles And percentage of ~arch vs arch users? * Most enabled, disabled useflags per package/globally Also great, especially the per-package variant. It'd be also useful to have per-profile data, to better tune the profile defaults. [0] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoostats.git;a=commit;h=1b9697a090515d2a373e83b1094d6e08ec405c02 I took a quick look at the code. Some random comments: - it uses portage Python API a lot. But it's not stable, or at least not guaranteed to be stable. Have you considered using helpers like portageq (or eventually enhancing those helpers)? - make the licensing super-clear (a LICENSE file, possibly some header in every source file, and so on) - how about submitting the data over HTTPS and not HTTP to better help privacy? Fair points, thanks! - don't leave exception handling as a TODO; it should be a part of your design, not an afterthought - instead of or in addition to the setup.txt file, how about just writing the real setup.py file for distutils? Yes, these are part of my sub-goals for next week. -- Vikraman signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On Wed, Jun 08, 2011 at 09:35:26PM +0400, Николай Антонов wrote: On 08.06.2011 18:36, Vikraman wrote: Hi everyone, I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: * Uname, portage profile, timestamp of portage tree * ARCH, CHOST, CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS, MAKEOPTS * ACCEPT_KEYWORDS, FEATURES, USE, LANG, SYNC, GENTOO_MIRRORS * Repository, Keyword, Useflags (plus,minus,unset), Counter, Size, and Build time for each installed package May be collect hardware info kernel configs too? For example cpuinfo, lspci and lsusb(?). That's not part of package statistics. There's the smolt project for hardware statistics. I think, that after 1-3 month after installing gentoo, user can(should) receive newsitem about participating in `Package statistics` project. This newsitem can contains short instruction how-to install and configure this tool. And even in other gentoo projects(for example write short wiki page) And, where can I found ebuilds to the `Package statistics` project? The server hasn't been deployed yet, and ebuilds will be available soon! Sory for my english... and Good luck! -- Vikraman signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On 17:19 Wed 08 Jun , Paweł Hajdan, Jr. wrote: On 6/8/11 4:36 PM, Vikraman wrote: I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: Excellent, good luck with the idea! I think that better information about how Gentoo is actually used will greatly help improving it. Is there a need to collect files installed by a package ? Doesn't PFL[1] already provide that ? Well, PFL is not an official Gentoo project. It might be useful, but I wouldn't say it's a priority. I would love to see it happen, but it's more important to roll out a minimal working solution now and add on later. By combining installed files with USE flag settings, this project could actually attempt to factor out which USE flags result in which files in an automatic fashion. That would address one of the biggest objections many people have had to such a package-to-file search engine. It would also be pretty useful for some other GSoC projects, like the ebuild generator and the auto dependency scanner. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgp99ZuhwbiGQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger wrote: On Tuesday, June 07, 2011 23:45:34 Dale wrote: So, council says it has to be done. You say you won't. Tell me where I missed the point here. you missed the point as soon as you incorrectly stated that i said i wont. thus the rest of your e-mail is useless noise. -mike So, you are saying that you won't be doing anything that will require you to add entries to the changelog. That works. It doesn't do much for the packages you maintain but that doesn't break the rules either. Let's just hope in the meantime things stay stable. Dale :-) :-)
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On Wed, 2011-06-08 at 23:31 +0530, Vikraman wrote: Excellent, good luck with the idea! I think that better information about how Gentoo is actually used will greatly help improving it. Well, that information cannot be collected automatically, can it ? You could pop up a window at random times and ask the user. So it can be done. Whether it's a good idea … Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On Wed, 2011-06-08 at 16:50 +0100, Ciaran McCreesh wrote: On Wed, 08 Jun 2011 17:43:38 +0200 Hans de Graaff gra...@gentoo.org wrote: That leaves the question what to do with the approach for EAPI=2,3. I'd rather not risk breaking ebuilds by removing this support just for a violation of PMS if there is no real problem exposed by it. The 'invariant' restriction on S in PMS is, strictly speaking, stronger than it has to be. However, working out exactly what set of weaker rules would be ok proved to be too difficult -- historically, Portage has had various different behaviours for global scope variables that are assigned variable values. Thus, PMS is the way it is there because we know for sure that if you follow those rules you're safe; if you don't, you'll definitely cause problems for EAPI 4, and you may or may not get away with it for earlier EAPIs. It's a bit like assuming that it's ok to dereference a null pointer and get a zero, since that's what one particular system does... Thanks for the background on this particular part of the specification. I think I'll add an eqawarn to the eclass for EAPI=2,3 and migrate ebuilds over naturally. I'll bump the remaining ones in 6 months or so. That also gives overlays some time to move to EAPI=4. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
El 08/06/11 20:07, Vikraman escribió: On Wed, Jun 08, 2011 at 09:35:26PM +0400, Николай Антонов wrote: On 08.06.2011 18:36, Vikraman wrote: Hi everyone, I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: * Uname, portage profile, timestamp of portage tree * ARCH, CHOST, CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS, MAKEOPTS * ACCEPT_KEYWORDS, FEATURES, USE, LANG, SYNC, GENTOO_MIRRORS * Repository, Keyword, Useflags (plus,minus,unset), Counter, Size, and Build time for each installed package May be collect hardware info kernel configs too? For example cpuinfo, lspci and lsusb(?). That's not part of package statistics. There's the smolt project for hardware statistics. Well there is another reason about why you don't want' to log that: Hardened users. Not having access to the kernel .config helps in making the system more resilient to some attacks, as a result many hardened users are very stubborn in not having the .config files published. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wednesday, June 08, 2011 13:04:08 Mike Frysinger wrote: On Tuesday, June 07, 2011 23:45:34 Dale wrote: So, council says it has to be done. You say you won't. Tell me where I missed the point here. you missed the point as soon as you incorrectly stated that i said i wont. thus the rest of your e-mail is useless noise. sorry, this was probably overly dismissive. let's rephrase to something like the long e-mails were redundant/rhetorical and incorrectly attempted to apply to me. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
May be collect hardware info kernel configs too? For example cpuinfo, lspci and lsusb(?). That's not part of package statistics. There's the smolt project for hardware statistics. Well there is another reason about why you don't want' to log that: Hardened users. Not having access to the kernel .config helps in making the system more resilient to some attacks, as a result many hardened users are very stubborn in not having the .config files published. I would really like to see a nice way to set what information I want sent. Perhaps a config file in /etc ? Also, an option to see what is being sent would be great. :) I look forward to start contributing my machine's info. -Ross
