Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
> probably belongs in -project. Not even in -project, it simply wasn't public mailing-list material. For those who haven't understood yet, the -dev and -project mailing lists are not for keeping us informed of your random thought of the day or lamenting about why-oh-why-is-the-whole-world-so-unfair-to-me-when-I'm-being-so-nice-to-everybody-no-kidding. Keep tweeting it though. Denis.
Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
Nirbheek Chauhan wrote: Please, do not waste everyone's time and bandwidth with thoughts that do not belong on this list, and hence they do not care about. Let's be nice. Somehow I don't think Duncan's goal was to get the mailing lists to be as flame-filled as he perceives IRC to be... :) Agreed that just about everything but the original council summary in this thread (and I mean the first original one) probably belongs in -project.
[gentoo-dev] Gentoo stats server/client @ 2009-06-20
Just a quick note that target "Make existing data processing fine-configurable" by now is complete and part of smolt's upstream code: http://git.fedorahosted.org/git/smolt.git The motivation for this feature was to allow users to shape smolt's behavior to fir their needs for privacy: If a user's machine has a few qualities that are quite unique he can now exclude them from transmission so he keeps his privacy and still contributes data. Sebastian
Re: [gentoo-dev] [GSoC status] Web-based image builder
Eitan Mosenkis wrote: > All comments, questions, suggestions, etc. are welcome. Interesting - could you point me/us at some design document or provide more detailed description of how the whole process works? -- Krzysiek Pawlik key id: 0xBC51 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [packagekit] [gentoo-dev] Inviting you to project "PackageMap"
Sebastian Pipping wrote: >> I'd like to determine the subset of URLs that appear >> exactly once in both gentoo and debian source packages. > > Mappable homepages in Debian: 6222 > Mappable homepages in Gentoo: 9582 > Shared (without normalization): 1183 With normalization for SourceForge, Google Code, Alioth, Savannah, Berlios, RobyForge, Gna, Pypi the number of directly mappable packages increases by about 500: Mappable homepages in Debian: 6222 Mappable homepages in Gentoo: 9582 Shared (w/o normalization): 1183 Shared (w/ normalization): 1670 Sebastian
[gentoo-dev] [GSoC status] Web-based image builder
This is my first weekly status report, so I'll introduce my project a little. I'm building a web-based application in PHP (with MySQL) that will allow the user to build a customized image of a linux installation. The intent is to support various different architectures/profiles, using the binary packages currently found on tinderbox.dev.gentoo.org. Users should be able to produce tarballs or, I hope, ISO images, etc. Also, I'd like to note before I get down to the status part, that if anyone would like to volunteer to do some web or graphic design for the project, whoever ends up using it (or their eyes) will probably thank you. I'm a much better web programmer than designer. As of now, I've made local copies of three different package sets to work with, default-linux/amd64, hardened/x86, and embedded/beagle. I'm working with solar to get some more packages added to tinderbox so I can test things more completely, but as of now my backend can generate a complete target environment for any of the above profiles and attempt to emerge system (the only one where enough binpkgs are available to actually complete this is the amd64). The backend polls the database for requested builds and builds them as requested, sending detailed logs back to the database. The frontend is coming along nicely, currently featuring user login, build request (as of now just choosing a name and selecting the profile), and log viewer. All comments, questions, suggestions, etc. are welcome.
Re: [gentoo-dev] Some last riting for sound and treecleaners (bossogg, gmpc plugins and ekg2)
On Sat, Jun 20, 2009 at 12:39 AM, Samuli Suominen wrote: > # Samuli Suominen (19 Jun 2009) > # Installs __init__.py directly into root of site-packages wrt #247851. > # Still depends on sqlite 2. Masked for removal in 30 days. > media-sound/bossogg > > # Samuli Suominen (18 Jun 2009) > # - gmpc plugins are no longer valid with 0.18.0 > # removed in 30 days > # - ekg2 doesn't build with stable glibc wrt #247994 > # removed in 60 days > media-plugins/gmpc-autoplaylist > media-plugins/gmpc-serverstats > <=net-im/ekg2-20061202 > -dev-announce as well, please -- ~Nirbheek Chauhan
[gentoo-dev] Some last riting for sound and treecleaners (bossogg, gmpc plugins and ekg2)
# Samuli Suominen (19 Jun 2009) # Installs __init__.py directly into root of site-packages wrt #247851. # Still depends on sqlite 2. Masked for removal in 30 days. media-sound/bossogg # Samuli Suominen (18 Jun 2009) # - gmpc plugins are no longer valid with 0.18.0 # removed in 30 days # - ekg2 doesn't build with stable glibc wrt #247994 # removed in 60 days media-plugins/gmpc-autoplaylist media-plugins/gmpc-serverstats <=net-im/ekg2-20061202
Re: [packagekit] [gentoo-dev] Inviting you to project "PackageMap"
Marijn Schouten (hkBst) wrote: > Neither of the gits gentoo has seems very split, I was referring to git in Debian here: Package: git-core Binary: git-core, git-doc, git-arch, git-cvs, git-svn, git-email, git-daemon-run, git-gui, gitk, gitweb > texlive with (http://www.tug.org/texlive/) seems to be missing from this list. > > $ eix -H http://www.tug.org/texlive/ | tail -n 1 > Found 79 matches. > > I suspect you used grep (or whatever) to construct your data, instead of using > the package manager or a tool that knows how to extract the data available in > packages (and eclasses). True, grep and friends. > I'm not sure which 3 cases you mean. I was referring to what I said before, in summary: 1) non-unique homepages 2) extra work for split packages 3) extra work for category mapping > I did not argue for a data format nor for a specific language nor coding style > nor anything that seems to match what you are saying here; I only spoke about > how to populate the CPE database. I understood you wanted to replace the XML colection with mapping code. I got you wrong then. I agree that combining automated fill of the database with manual can speed things up a lot. Sebastian
Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
On Fri, Jun 19, 2009 at 9:18 PM, Duncan<1i5t5.dun...@cox.net> wrote: > Wow, joke or not, this is the kind of thing that makes me glad I don't do > IRC. There's enough of it here, where people get to think about what > they write before they post (whether they actually /do/ or not...). I > don't need more of that sort of stuff in my life. I wasn't there and > don't know, and don't care to know, the details. And my life remains > much simpler and happier for that. =:^) > Denis already pointed out that this is not the place for discussions like this, even more so since your reply is doubly-offtopic. Please, do not waste everyone's time and bandwidth with thoughts that do not belong on this list, and hence they do not care about. -- ~Nirbheek Chauhan
Re: [packagekit] [gentoo-dev] Inviting you to project "PackageMap"
Paul Wise wrote: > The scripts were in my mail and the files are on every Debian mirror: > > wget -O - > http://ftp.debian.org/debian/dists/unstable/main/binary-amd64/Packages | grep > -h ^Homepage | sort | uniq -c | sort -n -r | head -n 10 > wget -O - http://ftp.debian.org/debian/dists/unstable/main/source/Sources | > grep -h ^Homepage | sort | uniq -c | sort -n -r | head -n 10 I see, thanks. I wrote: > I'd like to determine the subset of URLs that appear > exactly once in both gentoo and debian source packages. I made a script for this job now. With zero normalization I get this result: Mappable homepages in Debian: 6222 Mappable homepages in Gentoo: 9582 Shared (without normalization): 1183 That's about 11% of the Gentoo tree. The script is up here: http://git.goodpoint.de/?p=packagemap.git;a=tree;f=code/debian Sebastian
[gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
Steven J Long posted 1354782.qazs4eu...@news.friendly-coders.info, excerpted below, on Fri, 19 Jun 2009 09:52:18 +0100: > Thomas Anderson wrote: > >> Tiziano Muller(dev-zero) banned igli from #-council for what he called >> repeated trolling after private warnings. > > This is inaccurate, and to be frank, a lie. > > dev-zero was placed on /ignore > Furthermore, he only banned me 8 hours after I had left the channel. > (It's OK, it's a joke.) Wow, joke or not, this is the kind of thing that makes me glad I don't do IRC. There's enough of it here, where people get to think about what they write before they post (whether they actually /do/ or not...). I don't need more of that sort of stuff in my life. I wasn't there and don't know, and don't care to know, the details. And my life remains much simpler and happier for that. =:^) -- 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: Council meeting summary for meeting on June 11, 2009
[...] This list is for technical discussions only. Also, public mailing-lists are not for discussing your personal issues. Denis.
[gentoo-dev] Re: why I do not have /usr/lib/tls on my gentoo?
David Shen posted 53e35fd50906190041j35d95488lbcf3c7eb1efa8...@mail.gmail.com, excerpted below, on Fri, 19 Jun 2009 15:41:30 +0800: > I am trying to install Xen VM on my gentoo 2008 x64. According to what > http://en.gentoo-wiki.com/wiki/Xen said, I should run "mv /usr/lib/tls > /usr/lib/tls.disabled" and re-compile glibc and gcc to disable the 'tls' > feature. But I found that my system *DOES NOT* have the /usr/lib/tls > file/directory. Does this changed its place, or this prerequisite does > not apply to x64 system? First, note for future reference that "x64" is a rather ambiguous term, as it's (AFAIK) unofficial and could be equally argued to apply to Intel's ia64 aka "itanium" aka "itanic" architecture or to AMD's amd64 aka x86_64 architecture. Of course, this list is for the amd64 arch and it can be assumed you are referring to that here, but as I said, for future reference. =:^O Meanwhile, to your question: I don't do xen but based on my knowledge of Gentoo and Linux history from the 2004 time frame, that doesn't apply to a modern Gentoo Linux system. "tls" refers to "thread local storage". I'm somewhat confused on the exact relationships (whether tls was the nptl on or off version, a google produced some hints that it was the nptl on version, but nothing definitive), but tls was related to nptl, "native posix thread library", which was introduced by Red Hat back in 2002 and was just becoming a big thing on Gentoo about the time I switched to Gentoo around May, 2004. Prior to that, Linux had normally used Linux threads for threading. However, Linux-threads was Linux-only and wasn't entirely POSIX compatible, among other issues. NPTL was higher performing, and gradually took over and became the standard, both due to the better performance and because it WAS POSIX compliant and therefore made easier porting between Linux and the BSDs and various UNIX variants. NPTL did/does require either a 2.6 kernel or a patched 2.4 kernel, and was supported by glibc. Just checking the older glibc versions still in the tree, thru glibc 2.5*, the Gentoo glibc ebuilds have the nptl and nptlonly USE flags. With glibc 2.6, Gentoo was apparently dropping mainline kernel 2.4 support and nptl (and nptlonly) apparently became the un-USE-flagged default. Anyway, back when glibc was built for both nptl and linux-threads, /usr/lib/tls contained one version, while the other was in the standard /lib and /usr/lib locations (where lib means lib64 on amd64, with an equivalent 32-bit version for multilib users). BTW, x86(32) and amd64 no-multilib users now build glibc only once, while amd64 multilib users (the default) build it twice, once for 32-bit and once for 64-bit. During the linux-threads/nptl both era, that was doubled, so amd64 multilib users were actually building glibc four times, one each for nptl and linux-threads, for each of 32-bit and 64-bit! No WONDER emerging glibc seemed to take so long back then! So assuming you're using a 2.6 kernel and glibc >= 2.6 as well, /usr/lib(64)/tls should not exist, unless for some reason it wasn't removed properly during whatever glibc emerge would have gotten rid of it (the first 2.6 version if users hadn't been running USE=nptl nptlonly, the first glibc emerge after they switched to those USE flags if they did run them). The same should apply to the corresponding 32-bit libdir, for those still running multilib (I'm running no-multilib and don't remember where the 32-bit dir was, anymore). Thus, apparently that step of the the xen guide is either still around for the legacy installs still using old glibc versions, or it's there to ensure people remove the dir if it's unused cruft that didn't get cleaned up properly for whatever reason. Since you don't have that dir, you shouldn't have to worry about it. Here's some wikipedia links that should serve as beginning points for further research, if you're curious: http://en.wikipedia.org/wiki/Thread-local_storage http://en.wikipedia.org/wiki/Nptl http://en.wikipedia.org/wiki/LinuxThreads (stub article) -- 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
[gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
Thomas Anderson wrote: > Tiziano Muller(dev-zero) banned igli from #-council for what he called > repeated trolling after private warnings. This is inaccurate, and to be frank, a lie. dev-zero was placed on /ignore by me a couple of weeks previously after unwelcome /msg'ing wrt dev ML, that he was told was unwelcome, which he refused to respect. That was the ONLY private discussion we had and had nothing to do with #-council. Furthermore, he only banned me 8 hours after I had left the channel. Additionally, his user-rel issue was only raised AFTER I had raised the above in #-devrel, a process he chose to ignore until raising in userrel a couple of hours later, and then later trying to turn #-council into #-userrel, pretending the devrel issue had never occurred. (In the interests of accuracy I should point out it was +q not +b.) If I thought you had both time and inclination to actually reign your developers in when they step out of line, I'd file a devrel bug against him. As it is, I don't have the time to be insulted on bugzilla as well as online, and am just glad there is an election on; none of the user-rel people I spoke to afterwards knew anything about raising it with you for review; they only asked for the ban to be rescinded, which it was. I'd like to ask prospective Council members to answer the question I posted in my last mail to -project (which I assume you guys read. If not, I suggest new members consider keeping up to date with it, since many externals find dev to be beyond the pale. It's not just your developers who get put off by the nonsense.) What you put in your summary concerns me an awful lot less than the constant kowtowing to a supposed authority figure who on inspection is just another student, making all the classic student mistakes. It's not like others haven't pointed this out to you over and over; maybe you should start to consider it for a change? OK, put it this way: how offended do you think dev-zero would have felt if I had spoken to him in the way ciaranm addressed trelane in #-council over the last week or two? Or I'm sure anyone can find PLENTY of examples from this ML. Odd that CoC doesn't apply, but others are held up to a much higher standard and indeed treated most unfairly by people in positions of authority abusing that position for partisan aims. And sorry, tanderson, but consider my words of support for your campaign rescinded after the concerted nature of your part in the politicking. You clearly have a year or two more of growing-up to do, minimum, AFAIC. Lovey-dovey words about all getting along and documentation, are not sufficient to hold up to the rigours of the process you wish to lead. I'll chalk it up to inexperience on your part, as I know your heart is in the right place. If I'm wrong, feel free to flame me and I'll revise my opinion. Nice summaries though. /me looks forward to seeing gentoofan on the Council in a week or three and even more to quoting ciara at dev-zero. (It's OK, it's a joke.) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
