Re: [gentoo-dev] Re: [gentoo-project] New developer: Fabio Erculiani (lxnay)
Thanks to everybody involved in the process and in building up good relationships firstly between Gentoo and Sabayon and secondly among their devs. I am looking forward to contribute to Gentoo KDE and Portage Projects with my knowledge and ideas. In particular, I am looking forward to merge the good part of Sabayon directly, back into Gentoo (where applicable), making it shining and rocking like in the early days (eheh). I hope to be able to rectify false rumours surrounding my name (they're funny btw) and have fun with everybody. I'm not here to conspirate or whatever, I'm here to fix bugs, communicate with other developers, and race with ssuominen and patrick. I will demonstrate my committment through commits, that's the best I could say. Thanks to Samuli, Patrick and Tomas for having convinced me to join. A special thank goes to Betelgeuse and his patience. Regards, -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrite: media-video/qc-usb-messenger
# Samuli Suominen ssuomi...@gentoo.org (28 Sep 2009) # Obsolete. Supported by in-kernel drivers. Masked for removal, # see bug 277605. media-video/qc-usb-messenger It supported 4 device id's which have been supported by in-kernel gspca drivers for quite a while. Also, it doesn't compile with any recent kernel.
Re: [gentoo-dev] Re: [gentoo-project] New developer: Fabio Erculiani (lxnay)
Welcome aboard, looking forward to your contributions, and don't worry about rectifying false rumours, just committing to the tree and making new friends is enough for most. Once again welcome to gentoo it's about freaking time you became a developer :p On Mon, 2009-09-28 at 10:55 +0200, Fabio Erculiani wrote: Thanks to everybody involved in the process and in building up good relationships firstly between Gentoo and Sabayon and secondly among their devs. I am looking forward to contribute to Gentoo KDE and Portage Projects with my knowledge and ideas. In particular, I am looking forward to merge the good part of Sabayon directly, back into Gentoo (where applicable), making it shining and rocking like in the early days (eheh). I hope to be able to rectify false rumours surrounding my name (they're funny btw) and have fun with everybody. I'm not here to conspirate or whatever, I'm here to fix bugs, communicate with other developers, and race with ssuominen and patrick. I will demonstrate my committment through commits, that's the best I could say. Thanks to Samuli, Patrick and Tomas for having convinced me to join. A special thank goes to Betelgeuse and his patience. Regards, signature.asc Description: This is a digitally signed message part
[gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org
Hello there! This may look like like a lot of text but it actually isn't. Please read on. Thanks. During the last few days rbu and I have been teaming up on a proposal implementation improving on some of the issues that persist around layman-global.txt. (previously summarized in [1]) Both layman and the feed aggregator (planet) behind overlays.gentoo.org work with a database of information on repositories. These databases are not shared so changes do not propagate. That's not cool. What we have done for now: - Extended layman-global.txt format to repositories.xml format adding - A list of feed URIs .. for the planet side - Several source URIs .. for mirroring and several protocols - Owner name i.e. the name of the person to contact - quality classification (core, stable, testing, experimental, graveyard) .. to better guide users - project/person distinction .. for the planet side mainly - Created DTDs and Relax NG schemas for both the old and new format - Wrote a converter script from layman-global.txt format to repositories.xml format and back. It also adds generated file style warnings. The scripts have no dependencies other than plain Python. - Prepared a patch against layman trunk at r38 that adds support for - repositories.xml format - display of owner names (in addition to e-mail addresses) We have more or less the following future process in mind: - Collect feedback from the list (right now) and adjust the format and process as needed - Give birth to repositories.xml online - Decide about the final web location of repositories.xml - Put an initial repositories.xml on gentoo infra - Set up the repositories.xml to layman-global.txt converter script on the same machine to propagate all changes over to layman-global.txt in an automated fashion so we can keep it alive and up-to-date while still only editing its replacement - Revise layman patch until wrobel wants it upstream and put our a new layman release after - Setup script to create planet config from repositories.xml (Script creation is in progress.) - Take layman-global.txt offline in a year or so Here is a sample entry for each XML formats: layman-global.txt = overlay contact=sebast...@pipping.org name=sping src=git://git.goodpoint.de/overlay-sping.git status=unofficial type=git linkhttp://git.goodpoint.de/?p=overlay-sping.git/link descriptionGentoo overlay of Sebastian Pipping/description /overlay = repositories.xml = repo name=sping quality=experimental status=unofficial descriptionGentoo overlay of Sebastian Pipping/description homepagehttp://git.goodpoint.de/?p=overlay-sping.git/homepage owner type=person emailsebast...@pipping.org/email nameSebastian Pipping/name /owner source type=gitgit://git.goodpoint.de/overlay-sping.git/source feedhttp://git.goodpoint.de/?p=overlay-sping.git.git;a=atom/feed /repo = The code and schemas can be found at [2]. Now please ask questions and let us know what you think. Sebastian [1] http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg35095.html [2] http://git.goodpoint.de/?p=overlays-xml-specification.git;a=summary
[gentoo-dev] Lastrite: spca drivers
So, you might remember me lastriting qc-usb-messenger earlier today... here's some more webcam drivers: # Samuli Suominen ssuomi...@gentoo.org (28 Sep 2009) # Obsolete. Supported by in-kernel drivers. Masked for removal, # see bug 159176. media-video/gspca media-video/spca5xx media-video/gspcav1 In fact 2 out of 3 was already masked, I just remasked them in to this combo. Also, qc-usb is also getting removed soon as EvaSDK gets around to test the in-kernel stuff, the 3 device id's are supported by the same driver as qc-usb-messenger ones.
Re: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses
On 15:46 Thu 24 Sep , Maciej Mrozowski wrote: Because autopatcher makes it able to specify patches that are version independent (same patches for live and tagged ebuilds), while SCM patching/bootstrapping may be used for some specific cases (I haven't seen any yet personally, hence suggestions to drop it completely or disable by default and not to export src_prepare). Patching not so much, but bootstrapping w/ eautoreconf/autogen.sh totally. When migrating SCM eclasses to EAPI-2, I recommended leaving bootstrap in src_unpack phase and not to move it to src_prepare because I was well aware it will break most live EAPI-2 ebuilds having 'inherit sth scm_eclass'. And because developers doing this change didn't care for that case, I don't see why now they should oppose the idea to fix what they've broken, especially when it's probably going to affect only bad live EAPI-2 ebuilds (with not working PATCHES). But anyway, think for a while about the purpose of SCM eclasses. At least in my opinion, they should only provide [tarball or SCM] - SRCDIR delivery method, so just unpack method - any source processing should be purely *intentional* (and not enabled by default in SCM eclasses) - so in my opinion - unconditionally shadowing src_prepare by SCM eclasses is just architecturally wrong and needs to be fixed. The purpose of SCM eclasses, in my mind, is to provide an environment as similar as possible to that of a released tarball. That certainly includes bootstrapping. It gets annoying when I need to fiddle around with patching the build system if bootstrapping happens during src_unpack(). Then I end up patching during src_unpack(), which goes against the whole idea of src_prepare(). -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
Re: [gentoo-dev] Gentoo usage in companies
On 13:58 Sat 26 Sep , Patrick Lauer wrote: Hello everybody! As Gentoo approaches its 10th birthday I've been wondering how and where it is used. We used to have some great stories from companies in the weekly newsletter, but that one has become very dormant a while ago. I'd like to collect your success stories, endorsements and case studies so we can present to the rest of the world how using Gentoo makes your life easier and is totally awesome. If you don't want to have that information public I'll gladly anonymize it as long as I can be reasonably certain that you really exist. What is important is that you, if you actively use it in a commercial environment, write me whatever you think is important. Or you motivate someone you know to write it. Do your contribution to making things better :) Everything from I use it and it's great! to a story starting on a rainy day in November 1885 is good. Don't be afraid, I'll work with you on making it into something readable. And if you have specific criticism I'll take that too - maybe we can find an easy way to improve things. That is in your best interest too, so go ahead. Invest a few minutes of your time so we can save you more time! I would suggest that you _don't_ reply to this mailinglist but directly send me an email. Otherwise it'd be a long, but very offtopic thread which I'd like to avoid (and we had enough of those already ...) Many thanks in advance for your contributions, You should send this to gentoo-announce. You're not catching the right audience here. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future
On 20:46 Sun 13 Sep , Ryan Hill wrote: On Sat, 12 Sep 2009 14:15:34 +0200 Sebastian Pipping webmas...@hartwork.org wrote: Ryan Hill wrote: Personally I don't see how gaming the system helps us in any way. I was afraid it could be read in such a way. Handing out fake version numbers would be much easier, wouldn't it? I want every single package int he tree to be stable, up to date and polished. But as our resources are limited let's focus on packages that are most important first. That's actually what I meant by gaming the system. We could keep those particular packages up to the minute, but it wouldn't reflect the state of our distro as a whole. It's a false metric and I don't see the advantage in pandering to it. It's much more important that our packages actually work together than have the highest numbers. At the same time, we also want to ensure that any badly out-of-date packages on there aren't outliers that reflect poorly on our actual average status. And frankly, having any way to monitor popular yet outdated packages is a good thing. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
