Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
I find that as long as you read and follow the Gentoo XML Guide, writing docs is easy and using XML is handy. What I like the most is, as it was already noted, that I don't have to take care of the layout. However I have never found anything about writing project pages. Is there anything out there that I have overlooked ? If not, I'd really love to see this as a small addition to our XML guide. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Jakub Moc wrote: Uhm... Sorry to see this issue brought up yet again. Just a couple of brief notes: - The in-kernel drivers seriously are not an equivalent alternative, let alone the preferred one, for stuff like hda-intel or any similar drivers that are under permanent heavy development, at least for now. - This is not a duplicated maintenance effort, it's simply needed to have external alsa-drivers ebuilds, and it's needed to have them supported as ALSA upstream won't accept bugs about in-kernel drivers. - The two are basically different branches, and it's *not* about whether the code is newer or older in one or the other at all. I completely disagree with your assessment of the in-kernel hda-intel state. My workstation uses one of those (labelled nVidia MCP 55, for the curious), and my experiences with in-kernel ALSA have been nothing but positive with the intel audio, whether compiled or as modules. For the record, the kernel and alsa team have gone back and forth on this for a long time -- and it's always been my task to update the ALSA guide for whichever wins, or at least that's how it's been lately. The thing about ALSA upstream not accepting certain bugs -- I'm not sure Diego ever mentioned any such thing; is this really true? At the very least, this should cut down on spurious bug reports on our own bugzilla. However, it'd be nice from the point of view of the GDP if the kernel and ALSA maintainers would decide, once and for all, what should be supported and what shouldn't, whether in-kernel or alsa-drivers is recommended. Because it's been going back and forth for years as to which gets priority in the docs. Pick something for the users to install and stick with it, please. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
Denis Dupeyron wrote: I find that as long as you read and follow the Gentoo XML Guide, writing docs is easy and using XML is handy. What I like the most is, as it was already noted, that I don't have to take care of the layout. However I have never found anything about writing project pages. Is there anything out there that I have overlooked ? If not, I'd really love to see this as a small addition to our XML guide. We don't maintain ProjectXML. Not sure who does, if anyone. It's definitely not the GDP's area of responsibility. FYI, we do have nice guides on writing GuideXML: [1] http://www.gentoo.org/doc/en/xml-guide.xml [2] http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New ALSA maintainers
Josh Saddler napsal(a): I completely disagree with your assessment of the in-kernel hda-intel state. My workstation uses one of those (labelled nVidia MCP 55, for the curious), and my experiences with in-kernel ALSA have been nothing but positive with the intel audio, whether compiled or as modules. I could say the same about your assessment of the in-kernel hda-intel drivers, as could many other users... Same for via82xx - never had much luck with the in-kernel drivers, plus upgrading the whole kernel over and over again just to test whether something got fixed is a major PITA. As said, these are two different branches, what works for somebody doesn't need to work for someone else. For the record, the kernel and alsa team have gone back and forth on this for a long time -- and it's always been my task to update the ALSA guide for whichever wins, or at least that's how it's been lately. The thing about ALSA upstream not accepting certain bugs -- I'm not sure Diego ever mentioned any such thing; is this really true? I really don't get these fights, the two things can co-exist quite nicely and users can benefit from this. What's this need to 'deprecate' the external stuff once again about? (And yeah, ALSA upstream doesn't deal with in-kernel drivers bugs.) At the very least, this should cut down on spurious bug reports on our own bugzilla. However, it'd be nice from the point of view of the GDP if the kernel and ALSA maintainers would decide, once and for all, what should be supported and what shouldn't, whether in-kernel or alsa-drivers is recommended. Because it's been going back and forth for years as to which gets priority in the docs. Pick something for the users to install and stick with it, please. Both should be supported, as explained above. Spurious bugs? Not really sure what you mean. And no, kernel 2.4 is definitely not *the* reason to keep the external alsa drivers supported (Frankly I'd be very happy to see the whole 2.4 kernel branch declared as unsupported on Gentoo - noone's really testing anything against those kernels these days and the bugs are lingering there for ages as noone cares; even the 2.4 kernels we still have in the tree are pretty much unmaintained). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New ALSA maintainers
On 3/28/07, Jakub Moc [EMAIL PROTECTED] wrote: Josh Saddler napsal(a): I completely disagree with your assessment of the in-kernel hda-intel state. My workstation uses one of those (labelled nVidia MCP 55, for the curious), and my experiences with in-kernel ALSA have been nothing but positive with the intel audio, whether compiled or as modules. I could say the same about your assessment of the in-kernel hda-intel drivers, as could many other users... Same for via82xx - never had much luck with the in-kernel drivers, plus upgrading the whole kernel over and over again just to test whether something got fixed is a major PITA. As said, these are two different branches, what works for somebody doesn't need to work for someone else. I'm afraid I experiment the same issues. For my hda-intel, in-kernel drivers do not work, at least for now. Maybe we could find a way to integrate (see replace) the in-kernel alsa version with the portage one. -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
I completely disagree with your assessment of the in-kernel hda-intel state. My workstation uses one of those (labelled nVidia MCP 55, for the curious), and my experiences with in-kernel ALSA have been nothing but positive with the intel audio, whether compiled or as modules. I have two hda-intel machines. One runs with in-kernel alsa, for the other I had to use alsa-driver. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo infra backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Wed, 28 Mar 2007 10:30:56 +1200 Christopher Sawtell [EMAIL PROTECTED] wrote: There are plenty of ways of doing that, most of which don't involve the huge cost of having to use a horrible version control system... I wonder if you would be so kind as to expand on the meaning of your use of cost and horrible in the above sentence? Distributed systems don't work well with Gentoo's current development model, which is entirely centralised. Our current development model is restricted by our current SCM. Having code managament in local copies seems to me an essential feature. This goes double for people who don't have commit access to our repositories. There are also issues of performance and stability, both of which were discussed at length the last time this topic came up... I thought performance was one of the reasons for moving away from CVS. Anyway. I've been reading some SCM comparisons and there are three systems which I think are the best candidates for moving to: git, mercurial and darcs. These are the three fastest and most capable SCMs. Git is still the fastest but mercurial and darcs are not far behind. Darcs has the best merging capabilities probably due to its being based on a solid mathematical foundation; patch algebra. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCkOvp/VmCx0OL2wRAi6mAJ91JvMdHOa8m55bXaKBs8n3T9ZThgCfaqcW K86k6wGAFCIVFJoxg48SS3s= =CCx2 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
On Wednesday 28 March 2007, Josh Saddler wrote: Denis Dupeyron wrote: I find that as long as you read and follow the Gentoo XML Guide, writing docs is easy and using XML is handy. What I like the most is, as it was already noted, that I don't have to take care of the layout. However I have never found anything about writing project pages. Is there anything out there that I have overlooked ? If not, I'd really love to see this as a small addition to our XML guide. We don't maintain ProjectXML. Not sure who does, if anyone. It's definitely not the GDP's area of responsibility. FYI, we do have nice guides on writing GuideXML: [1] http://www.gentoo.org/doc/en/xml-guide.xml [2] http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml I do (sort of), and it is documented at: http://www.gentoo.org/proj/en/metastructure/projectxml.xml Unfortunately I don't know of any page that uses all features, but if you look around you can find some. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGInWKoiyb5.pgp Description: PGP signature
Re: [gentoo-dev] New ALSA maintainers
On Wed, 2007-03-28 at 01:46 -0700, Josh Saddler wrote: At the very least, this should cut down on spurious bug reports on our own bugzilla. However, it'd be nice from the point of view of the GDP if the kernel and ALSA maintainers would decide, once and for all, what should be supported and what shouldn't, whether in-kernel or alsa-drivers is recommended. Because it's been going back and forth for years as to which gets priority in the docs. Pick something for the users to install and stick with it, please. The default genkernel kernel configurations (for at least x86/amd64) use in-kernel ALSA (as modules) and will for the forseeable future. If someone wants to argue with me over why I shouldn't be doing that, I'm all ears, but am likely to not change this until such time as we add some additional support to the Installer for allowing the install of on-disk external kernel modules in Networkless mode, and online external kernel modules in the other modes. In other words, if you want me to change it, you better break out your python-fu and get coding. ;] -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
SCM choices (was: Re: [gentoo-dev] Re: Gentoo infra backups)
On Wed, 2007-03-28 at 12:30 +0200, Marijn Schouten (hkBst) wrote: I've been reading some SCM comparisons and there are three systems which I think are the best candidates for moving to: git, mercurial and darcs. These are the three fastest and most capable SCMs. Git is still the fastest but mercurial and darcs are not far behind. Darcs has the best merging capabilities probably due to its being based on a solid mathematical foundation; patch algebra. Please, everyone, go back and read the actual *facts* that were discovered using copies of *our* repositories before going around using data from outside sources. Unless you're willing to spend the time to *prove* that some other SCM is faster/better than CVS and actually works *with our repositories* properly, then there's no point in discussing this *yet again* on the list. Remember that when this was investigated last summer, *none* of the alternate SCMs were really viable for us, with Subversion being the least likely to suck. I'm sure things might have changed a bit since then, but one of the major things we noticed from the study was that our findings on *our* data set didn't really match the FUD/evangelism that was being spouted by proponents of other SCMs. Picking a SCM is *not* a religious or political move. It should be done entirely for technical reasons. If you want to bring this back up, I ask you to have the data to back it up. Otherwise, we really don't need to discuss it since everybody is going to have differing opinions based on nothing but anecdotes and here say. We get enough of that around here. Let's try to stick to facts and reproducible data. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
On 3/28/07, Paul de Vrieze [EMAIL PROTECTED] wrote: I do (sort of), and it is documented at: http://www.gentoo.org/proj/en/metastructure/projectxml.xml Unfortunately I don't know of any page that uses all features, but if you look around you can find some. Thanks Paul, that's exactly what I was needing. I didn't think of looking for it in the metastructure pages. I wrongly assumed it was GDP stuff. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo infra backups
I've been reading some SCM comparisons and there are three systems which I think are the best candidates for moving to: git, mercurial and darcs. These are the three fastest and most capable SCMs. Git is still the fastest but mercurial and darcs are not far behind. Darcs has the best merging capabilities probably due to its being based on a solid mathematical foundation; patch algebra. Reading comparisons is one thing and using is the other. But the thing is, gentoo ends up with central repository, anyway. Provided the repository is less ancient than CVS (which is basically subversion), distributed users can branch it without having to have commit access. This hybrid model makes much more sense to me than forcing everyone to use DSCM. I have exercised the approach on overlay before I was granted commit access and now continue to work the same way pushing my branches back to svn. I think this possibility totally invalidates the very idea of DSCM importance. Love, H -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Mon, 2007-03-26 at 12:01 -0500, Mike Bonar wrote: Should we encourage more content to go into the wiki, expecially content that is likely to change over a short period of time? Gentoo has no wiki. Not entirely true, project overlays on overlays.g.o can use the wiki on trac there. And at least we (Java) use it to hash out new stuff (that's exactly content that is likely to change over a short period of time), that can be later converted to guidexml (FAQs etc). - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCl+etbrAj05h3oQRAo1wAJ9bwzarFNWHXaNKjdkC9+zFMLzapgCfRyBB PJltO8soodQZLPE637hqJYM= =kq4g -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anant Narayanan wrote: I guess the point of last year's GuideXML SoC project was to help devs who didn't find writing GuideXML *cough* exciting *cough* enough. Which is why I developed Beacon [1]. Looks like the project hasn't been as successful as I would have liked within Gentoo (although other projects [2] are certainly considering using it!). The fault is entirely mine, and I will strive to improve Beacon to a really usable level, and maybe convince the Infra team to install a copy on one of our servers for our devs to use. I think it lacks advertisement, IMHO many people just know there was such project but have no idea if it was completed or what. And having it online (at least some demo) would help greatly so people can easily try it out without having to install a webserver, checking out the sources etc etc. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCmCltbrAj05h3oQRAn7EAJ0SgRHTeU339uMt/zkH6EoifOjtdwCgktHH wo5WimRT1DoUC1FSLEbVWqo= =01NV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tuesday 27 March 2007, Ciaran McCreesh wrote: On Tue, 27 Mar 2007 15:19:29 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: one of Gentoo's priorities is to enable alternative package managers to coexist sanely ... it is not one of Gentoo's priorities at this time to replace Portage with a different package manager Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? If it is not a limiting factor, portage is certainly a critical part of the distribution. And yes there are many features that should be offered but are not. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHbA1mbup1V.pgp Description: PGP signature
Re: [gentoo-dev] New ALSA maintainers
On Wed, 28 Mar 2007 08:54:21 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Daniel Drake wrote: I have suggested that herd support for the kernelspace side (alsa-driver) be slowly reduced, by redirecting users who file bugs against it to reproduce with the in-kernel drivers, and then let kernel handle the bug resolution. This will remove duplicated maintenance efforts. The only crummy thing about this is that the in kernel drivers have NEVER supported my sound card. Not even on 2.6.20. I'm using hda-intel and it just never works. I end up always returning back to alsa-driver. So I don't think that the code bases are the same. But I guess this is what I'll have to live with unless I want to step up as an alsa maintainer. Well, I just tested in-kernel 2.6.20 and alsa-driver 1.0.14_rc3 both work equally well with my Intel HDA in my IBM ThinkPad Z60m. The only reason I changed to alsa-driver was when there was a mismatch between alsa-lib and the 32 bit alsa-lib on ~amd64. I'll see if the in-kernel drivers work now (via-82xx). Based on my fond experiences with ipw2200, rt2500 and rt2x00, once something is in-kernel it just seem to work better, IMO. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
On Wednesday 28 March 2007, Denis Dupeyron wrote: On 3/28/07, Paul de Vrieze [EMAIL PROTECTED] wrote: I do (sort of), and it is documented at: http://www.gentoo.org/proj/en/metastructure/projectxml.xml Unfortunately I don't know of any page that uses all features, but if you look around you can find some. Thanks Paul, that's exactly what I was needing. I didn't think of looking for it in the metastructure pages. I wrongly assumed it was GDP stuff. Denis. Well, googling for gentoo projectxml does get you to the right place immediately ;-). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpEWpIQnJk0f.pgp Description: PGP signature
Re: [gentoo-dev] New ALSA maintainers
Le Wed, 28 Mar 2007 11:22:22 +0200, Ioannis Aslanidis [EMAIL PROTECTED] a écrit : On 3/28/07, Jakub Moc [EMAIL PROTECTED] wrote: Josh Saddler napsal(a): I completely disagree with your assessment of the in-kernel hda-intel state. My workstation uses one of those (labelled nVidia MCP 55, for the curious), and my experiences with in-kernel ALSA have been nothing but positive with the intel audio, whether compiled or as modules. I could say the same about your assessment of the in-kernel hda-intel drivers, as could many other users... Same for via82xx - never had much luck with the in-kernel drivers, plus upgrading the whole kernel over and over again just to test whether something got fixed is a major PITA. As said, these are two different branches, what works for somebody doesn't need to work for someone else. I'm afraid I experiment the same issues. For my hda-intel, in-kernel drivers do not work, at least for now. Maybe we could find a way to integrate (see replace) the in-kernel alsa version with the portage one. All the new features are incorporated first in the alsa-driver. It implies at it will make no difference for peoples using old hardwares. But for peoples using new hardwares, or wanting to have new features such as volume control in dB with some hardwares, they have no other choice as to use the alsa-driver package. Also bug fixes come first in alsa-driver from Alsa, and only later in the in-kernel driver. As I see it, It is necessary to support the in-kernel driver as it come with every kernel, but it is also necessary to support alsa-driver because some users not only want it, but they need it to get alsa to work well with their hardware. And I don't think at replacing the in-kernel driver by the alsa-driver will implies less work. It will be more work for the maintainers of the kernel's ebuilds. It is also much simpler to upgrade the alsa-* packages to get a new alsa version as to upgrade the whole kernel. Ciao, Dominique -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
On 3/28/07, Daniel Drake [EMAIL PROTECTED] wrote: snip ...here are the diffs of the latest alsa development release vs the latest kernel development release: snip Just a user opinion here, but I find the need to use unstable alsa-driver to solve a bug every now and then. This procedure would be more complicated if I had to run a development kernel to solve a sound problem. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Mike Pagano wrote: Just a user opinion here, but I find the need to use unstable alsa-driver to solve a bug every now and then. This procedure would be more complicated if I had to run a development kernel to solve a sound problem. And you'll still have that option. I hope you file bugs when these scenarios occur so that we can guarantee quality in our stable tree. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
The fact is that the bug has been around for quite a long time now: http://bugs.gentoo.org/show_bug.cgi?id=165679 Anyway, see Flameeyes's comments for details (in the ChangeLog) On 3/28/07, Daniel Drake [EMAIL PROTECTED] wrote: Doug Goldstein wrote: The only crummy thing about this is that the in kernel drivers have NEVER supported my sound card. Not even on 2.6.20. I'm using hda-intel and it just never works. I end up always returning back to alsa-driver. So I don't think that the code bases are the same. Please file a kernel bug. With your help, it'll get fixed. It won't be too much work for either of us. Thanks, Daniel -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Daniel Drake napsal(a): Jakub Moc wrote: - The in-kernel drivers seriously are not an equivalent alternative, let alone the preferred one, for stuff like hda-intel or any similar drivers that are under permanent heavy development, at least for now. If hda-intel (or any other driver) from the kernel sources does not work on your system then you should file a bug. Yes, there are drivers under heavily development, this also applies to many other kernel subsystems too. We live with it. It's not as bad as it sounds. It not only doesn't work for me, it doesn't work for majority of people that have responded on this thread. So, something's wrong there I guess? :) - This is not a duplicated maintenance effort, it's simply needed to have external alsa-drivers ebuilds, and it's needed to have them supported as ALSA upstream won't accept bugs about in-kernel drivers. That's not true. I have supported in-kernel ALSA drivers for a long time and have never seen this be the case. Hmmm, I'm not entirely sure what are you responding to here? What I said was that ALSA upstream won't accept bugs about in-kernel drivers - now how's that related to whether you (or kernel upstream) support them or not? Additionally - forcing people to upgrade kernel for their sound issues is not a solution for many of them. Kernel upgrades tend to break lots of stuff on every minor version bump (and it's not only external modules that upstream seems to plain hate and ignore mostly). Not exactly what users would like to see when all they are trying to get is working sound. Plus it's lot easier (and faster) to get patches into external drivers than get them accepted into kernel. Interestingly in this case, the in-kernel driver is a touch newer than the hda-intel one. It includes support for a few more hardware devices. Again these are only very small differences though. As said, it's not about code being newer or older, it's about having two different branches of the code. One works for someone, the other works for someone else. What's exactly the benefit from trying to kill support for upstream ALSA code and forcing people to use in-kernel drivers (beyond what you see as 'duplicated' maintenance effort)? Users honestly don't care much about 'duplicated' effort, they want a working sound on their boxes. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New ALSA maintainers
On Wed, Mar 28, 2007 at 04:49:25PM +0200, Jakub Moc wrote: Daniel Drake napsal(a): Jakub Moc wrote: - The in-kernel drivers seriously are not an equivalent alternative, let alone the preferred one, for stuff like hda-intel or any similar drivers that are under permanent heavy development, at least for now. If hda-intel (or any other driver) from the kernel sources does not work on your system then you should file a bug. Yes, there are drivers under heavily development, this also applies to many other kernel subsystems too. We live with it. It's not as bad as it sounds. It not only doesn't work for me, it doesn't work for majority of people that have responded on this thread. So, something's wrong there I guess? :) Maybe because this thread is a lot more interesting for people that doesn't have working in-kernel drivers? For what it's worth I'm using in-kernel alsa drivers with hda-intel and it's always worked just fine for me. - This is not a duplicated maintenance effort, it's simply needed to have external alsa-drivers ebuilds, and it's needed to have them supported as ALSA upstream won't accept bugs about in-kernel drivers. That's not true. I have supported in-kernel ALSA drivers for a long time and have never seen this be the case. Hmmm, I'm not entirely sure what are you responding to here? What I said was that ALSA upstream won't accept bugs about in-kernel drivers - now how's that related to whether you (or kernel upstream) support them or not? Is it really important who supports it? I think most users would care about their drivers being supported or not instead of who supports them. Additionally - forcing people to upgrade kernel for their sound issues is not a solution for many of them. Kernel upgrades tend to break lots of stuff on every minor version bump (and it's not only external modules that upstream seems to plain hate and ignore mostly). Not exactly what users would like to see when all they are trying to get is working sound. Plus it's lot easier (and faster) to get patches into external drivers than get them accepted into kernel. I don't think anybody is trying to force anything. Daniel have stated that alsa-driver should be supported for a long time. Interestingly in this case, the in-kernel driver is a touch newer than the hda-intel one. It includes support for a few more hardware devices. Again these are only very small differences though. As said, it's not about code being newer or older, it's about having two different branches of the code. One works for someone, the other works for someone else. What's exactly the benefit from trying to kill support for upstream ALSA code and forcing people to use in-kernel drivers (beyond what you see as 'duplicated' maintenance effort)? Users honestly don't care much about 'duplicated' effort, they want a working sound on their boxes. I'll just repeat myself here as you've basically just repeated your claim about forcing people to use in-kernel drivers.. Nobody is forcing anybody to use in-kernel drivers. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
So, maybe this is a boneheadedly obvious thing, but having just spoken with Daniel about this, I'll just summarise my findings. I, for one, was always using alsa-driver for my new Dell laptop. As it turns out, Dan has the identical laptop, but he's always been using the in-kernel driver. I always just chalked it up to well, Dan's just leeter than me in matters of kernel things anyway, so yeah. Then one day, I walked over and I asked him what I was doing wrong in my kernel config. You know what it was for me? I saw that I had intel audio hardware, so I kept configuring intel8x0. As soon as I activated hda-intel, it was all good. Now, obviously that was just me being stupid and ignorant, but there are possibly a couple more issues. One is that if you've emerged alsa-driver for your kernel, and then recompile that kernel, you're possibly mixing two types of alsa drivers in the /lib/modules directory which would definitely lead to brokenness. So my challenge to those having problems: try it out on a fresh kernel and report your bug. And, please let's dispense with this forcing people to do anything. There's no such ultimatum at work here, please don't jump to erroneous conclusions. thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New ALSA maintainers
Ioannis Aslanidis wrote: The fact is that the bug has been around for quite a long time now: http://bugs.gentoo.org/show_bug.cgi?id=165679 This bug is exactly the kind that makes maintaining alsa-driver (and any other out-of-kernel module) a small nightmare. It's exactly the kind of bug that never exists when people use in-kernel drivers. Maybe I misunderstood your tone and actually you are supporting the changes I have suggested? Even so I'm not sure how this relates to Doug's problem? He didn't provide any details here, and was not involved on that bug. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Well, to be honest, I am neither supporter nor detractor. I think that it's upstream that should go and fix themselves. It's them who have caused all this. ALSA guys do not support in-kernel stuff. Kernel guys do not support alsa stuff. Great, isn't it? On 3/28/07, Daniel Drake [EMAIL PROTECTED] wrote: Ioannis Aslanidis wrote: The fact is that the bug has been around for quite a long time now: http://bugs.gentoo.org/show_bug.cgi?id=165679 This bug is exactly the kind that makes maintaining alsa-driver (and any other out-of-kernel module) a small nightmare. It's exactly the kind of bug that never exists when people use in-kernel drivers. Maybe I misunderstood your tone and actually you are supporting the changes I have suggested? Even so I'm not sure how this relates to Doug's problem? He didn't provide any details here, and was not involved on that bug. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Bryan Østergaard napsal(a): Nobody is forcing anybody to use in-kernel drivers. Uhm... http://bugs.gentoo.org/show_bug.cgi?id=172490 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
On Wed, 2007-03-28 at 14:29 +0200, Vlastimil Babka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Mon, 2007-03-26 at 12:01 -0500, Mike Bonar wrote: Should we encourage more content to go into the wiki, expecially content that is likely to change over a short period of time? Gentoo has no wiki. Not entirely true, project overlays on overlays.g.o can use the wiki on trac there. And at least we (Java) use it to hash out new stuff (that's exactly content that is likely to change over a short period of time), that can be later converted to guidexml (FAQs etc). Gentoo has no wiki. The Gentoo/Java project has one. As do many other projects, including a couple I'm on, but my previous statement is still true. At any rate, it's just arguing semantics, where there's no need for it, and all that does is cause tension, frustration and aggression. Maybe if we all were a little less likely to go around trying to prove everybody else wrong by trying to dissect their wording and instead focused on technological improvements of our distribution, we'd have some really kick ass technology being created. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New ALSA maintainers
Ioannis Aslanidis wrote: Well, to be honest, I am neither supporter nor detractor. I think that it's upstream that should go and fix themselves. It's them who have caused all this. The bug you linked to is a natural effect of maintaining kernel drivers outside of the kernel source tree. It is not the fault of the alsa-driver maintainers (either Gentoo or upstream people who push tarballs), since they don't control the in-kernel API's. It's not the kernels fault because the kernel does not claim to maintain a stable internal API, and it actually readily claims the opposite. This is not going to change. With reference to the problems an unstable internal API causes, kernel people will give you one answer and one answer only: get your code in the kernel. Problems like these simply do not happen there. So, in this particular case, if the alsa-driver portage package did not exist, the bug in question (plus a whole series of others in the same class) simply will not ever occur. This is a good thing. ALSA guys do not support in-kernel stuff. ALSA guys being upstream alsa-project.org people? That's not correct, they are the people who put the code in the kernel. ALSA guys being downstream gentoo maintainers? That's true, since there is a separate team who maintain the kernel. Kernel guys do not support alsa stuff. Upstream kernel guys? No, they support alsa, actually most of the bugs are handled by the alsa-project.org people who generally handle them very well. Downstream kernel guys (i.e. Gentoo kernel herd)? No, we support the sound subsystem and the ALSA drivers just like all other subsystems and drivers in the kernel. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Anyhow, I would like to see alsa-drivers removed, but only with the condition that the in-kernel ALSA drivers work as expected. The bug I mentioned, if you reread it, you will notice that if there was no external alsa-driver, hda-intel would be marked broken as well, for some users. Just to make it short, in-kernel hda-intel works for some people, but it doesn't for others. The logical bug to be fixed is that the kernel guys (not our kernel guys) check what's going wrong in there. If that did happen, then your point of view wouldn't need any argumentation. What really has annoyed me is the fact that the external driver works, and I hope to see that not happen again. Unfortunately, that's not in my hands right now. If we are able to convince upstream maintainers about this, to report the bugs properly and to get them fixed as required, we could go ahead and remove alsa-drivers. Until that happens, seeing the current proofs, the best choice is if it works don't fix it. On 3/28/07, Daniel Drake [EMAIL PROTECTED] wrote: Ioannis Aslanidis wrote: Well, to be honest, I am neither supporter nor detractor. I think that it's upstream that should go and fix themselves. It's them who have caused all this. The bug you linked to is a natural effect of maintaining kernel drivers outside of the kernel source tree. It is not the fault of the alsa-driver maintainers (either Gentoo or upstream people who push tarballs), since they don't control the in-kernel API's. It's not the kernels fault because the kernel does not claim to maintain a stable internal API, and it actually readily claims the opposite. This is not going to change. With reference to the problems an unstable internal API causes, kernel people will give you one answer and one answer only: get your code in the kernel. Problems like these simply do not happen there. So, in this particular case, if the alsa-driver portage package did not exist, the bug in question (plus a whole series of others in the same class) simply will not ever occur. This is a good thing. ALSA guys do not support in-kernel stuff. ALSA guys being upstream alsa-project.org people? That's not correct, they are the people who put the code in the kernel. ALSA guys being downstream gentoo maintainers? That's true, since there is a separate team who maintain the kernel. Kernel guys do not support alsa stuff. Upstream kernel guys? No, they support alsa, actually most of the bugs are handled by the alsa-project.org people who generally handle them very well. Downstream kernel guys (i.e. Gentoo kernel herd)? No, we support the sound subsystem and the ALSA drivers just like all other subsystems and drivers in the kernel. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
On Wed, Mar 28, 2007 at 05:36:57PM +0200, Jakub Moc wrote: Bryan Østergaard napsal(a): Nobody is forcing anybody to use in-kernel drivers. Uhm... http://bugs.gentoo.org/show_bug.cgi?id=172490 Which isn't exactly the same as removing alsa-driver and forcing people to use in-kernel drivers.. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: SCM choices (was: Re: [gentoo-dev] Re: Gentoo infra backups)
On Wed, 2007-03-28 at 15:23 +0200, Kevin F. Quinn wrote: SVN consumes double the bandwidth to checkout a full tree. It would also be interesting to find out why the server disk usage is 4x that of CVS (and what difference the choice of back-end makes). I would bet that the file-system also makes some difference, along with the back-end choices. Unless Alec took this into consideration. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New ALSA maintainers
Jakub Moc wrote: It not only doesn't work for me, Bug please! :) it doesn't work for majority of people that have responded on this thread. So, something's wrong there I guess? :) I don't regard this thread as quantifiable measure. Nevertheless, lets count the number of successes and failures on this thread so far: jakub: failure aslandis: failure cardoe: failure wltjr: success nightmorph: success seemant: success kloeri: success uberlord: success gentoodoo: 1 each way I'm not asking for more people to add experiences, and I'm not saying that in-kernel is any more reliable than alsa-driver. I'm just pointing out how easy it is to misinterpret the information on a thread, and how you cannot make the above statement. Maybe this wasn't a serious comment, in which case I apologise for taking it seriously. Email sucks for communication. Hmmm, I'm not entirely sure what are you responding to here? What I said was that ALSA upstream won't accept bugs about in-kernel drivers - now how's that related to whether you (or kernel upstream) support them or not? Sorry, I can see how my response wasn't clear. When I say I support I mean that I accept the bugs on Gentoo bugzilla and work them through til resolution. So, you're correct that me supporting something is not related to any decisions made upstream. However, many bugs which pass through my support follow a common pattern: I request lots of useful info, am not able to immediately solve the problem myself, so I instruct the user how to file the bug upstream. In most cases they do so, and I track the upstream bug. And it's these cases I'm referring to - I've never seen any upstream bugs rejected due to them using in-kernel drivers. Please understand that it wouldn't make much sense for them to reject it either. There is no difference personnel-wise between the people who release alsa-driver and the people who send patches into the kernel. If they were to refuse bugs from people who use kernel drivers then why do they spend a considerable amount of time regularly synchronising patches? Additionally - forcing people to upgrade kernel for their sound issues is not a solution for many of them. Kernel upgrades tend to break lots of stuff on every minor version bump (and it's not only external modules that upstream seems to plain hate and ignore mostly). Not exactly what users would like to see when all they are trying to get is working sound. Beyond the usual statements that we aren't forcing anything: I will not deny that there is some user convenience gained by having the drivers separated from the kernel. Conversely, such packages are maintenance nightmares and are susceptible to entire classes of bugs that they would not be otherwise, and these are often passed onto the user. Sometimes we are even forced to take drastic measures such as marking heavily experimental code stable. The problem I'm solving here, I am solving from a development perspective. We have duplicated code and duplicated effort, and one of the copies currently doesn't have any real manpower taking care of it. Plus it's lot easier (and faster) to get patches into external drivers than get them accepted into kernel. I'm not sure that it is any easier, because the process of patch submission (file a bug) is the same. It may be faster, but I don't think thats a big factor. We generally do a good job keeping on top of the kernel bug list and regularly doing bugfix kernel releases. Although it may be faster for maintainers to supply new packages like alsa-driver, it's not *that* much different. All of the complaints so far seem to be regarding that *handling bugs* is more convenient for certain use cases when supported ALSA drivers are provided by an out-of-kernel package. (for clarity: a kernel driver not working IS a kernel bug, even if you have alternative ways of getting that hardware working) There is some truth here. However, more importantly in my eyes, our development resources are thin and there are currently 0 people standing behind alsa-driver. Additionally our processes across the entire Gentoo tree are based on the assumptions that things work, and bugs are treated as exceptions. Sure, we accept that bugs exist, and there are plenty of them, and we look to improve our methods of handling them (I have certainly done this a lot for the kernel) but we don't revolve our entire system around the assumption that the packages in the stable tree have bugs. What I'm trying to say is that even though there are some downsides here, the overall process is improved given the resources we have. Even though I'm sure my personal opinion is clear, I don't have a strong stake in the ALSA herd. The real reason why alsa-driver is not getting any support behind it right now is that nobody is standing behind it. If someone wants to step up and take over maintenance of alsa-driver, and put the required amount of
Re: [gentoo-dev] New ALSA maintainers
Jakub Moc wrote: Bryan Østergaard napsal(a): Nobody is forcing anybody to use in-kernel drivers. Uhm... http://bugs.gentoo.org/show_bug.cgi?id=172490 Sorry, my comments on that bug are a little unclear. I am not suggesting removal of alsa-driver from Portage, neither I am suggesting that the documentation stops documenting alsa-driver, nor am I suggesting any other way of forcing people to move away from it. I am simply asking if the documentation team are willing to recommend the in-kernel version over the portage one, given that the in-kernel one is being properly maintained and the portage one is not. This is different from forcing someone to use in-kernel drivers. I will add a clarification to the bug. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
On Wed, 2007-03-28 at 18:05 +0200, Ioannis Aslanidis wrote: Anyhow, I would like to see alsa-drivers removed, but only with the condition that the in-kernel ALSA drivers work as expected. The bug I mentioned, if you reread it, you will notice that if there was no external alsa-driver, hda-intel would be marked broken as well, for some users. Just to make it short, in-kernel hda-intel works for some people, but it doesn't for others. I would be curious to know if it's just a simple not being aware of all Chipset ID's. I know a while back when I first got my laptop, the bcm43xx driver did not recognize my card, 4319 chipset. Being as how it's the 4318 and more. I went upstream, they asked me a bit of info. Turns out the driver did not have info for 4319. They added it, and my card was recognized. Now granted it did take a bit of time before those changes were added to kernel sources. I had to apply a minor patch for a bit to not use external stuff. Then there were some other issues, and still some minor ones. Not sure if that would apply here, where the hda-intel driver works for some and not others. Likely have different chipsets that both should work with that driver. If the driver is aware of all chipset ID's. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New ALSA maintainers
On Wed, 2007-03-28 at 13:54 -0400, Daniel Drake wrote: Even though I'm sure my personal opinion is clear, I don't have a strong stake in the ALSA herd. The real reason why alsa-driver is not getting any support behind it right now is that nobody is standing behind it. If someone wants to step up and take over maintenance of alsa-driver, and put the required amount of time/effort into maintaining such a large kernel code base outside of the kernel, then I can accept that. I can accept that not everyone shares my views, and although I unintentionally managed to frustrate the previous maintainer a few times, I did accept that he was willing to stick by ideas just as I was prepared to stick by mine. Lack of package maintainer, makes most all discussions about alsa-driver moot. Or any package lacking a maintainer. :) Everyone who is claiming that alsa-driver works and in-kernel I personally want to see some chipset ID's. What exact chips people have that work, and don't work. Please provide the output of lspci -nn Only care about the line for your sound card. And if yours works or doesn't and with which driver, in-kernel, or external.. Then we can say grep kenrel driver sources, or etc for that chipset ID, and go from there :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New ALSA maintainers
On Wed, 28 Mar 2007 13:54:04 -0400 Daniel Drake [EMAIL PROTECTED] wrote: I'm fully 100% serious on the above. I challenge you to PROVE ME WRONG. I secretly hope you do, since that means I'll get a couple of interesting bugs to handle and I may even be able to solve them myself. There was an instance where stable kernel alsa mis-matched stable alsa-lib and alsa-lib32 (emul soundlibs) at some point, and using alsa-driver was the only option. Pretty sure that was amd64, but may have been ~amd64 too. That has since then been solved, but it was nasty and something that really shouldn't happen. ie, kernel team didn't listen to alsa-team didn't listen to arch teams. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Vlastimil, I think it lacks advertisement, IMHO many people just know there was such project but have no idea if it was completed or what. And having it online (at least some demo) would help greatly so people can easily try it out without having to install a webserver, checking out the sources etc etc. Yes, I think that seems to be the problem. I will try and work something out over the next few weeks and maybe get a demo up for everyone to use. gentoo.ru had one sometime back, but they removed it recently. Cheers, - -- Anant -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGCsWvTon3xA72kU4RAgzMAJ4/k0/UQfbkkB64JRQDbqGVrRyYLgCeJUTW ApR2IyexpVCAsahv+8ak1YE= =zgd9 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi Ciaran, On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Of course that doesn't mean that it doesn't have its drawbacks, certainly things can be done in better ways; but isn't that the case with all legacy software? Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Gentoo infra backups
Michael Krelin wrote: Reading comparisons is one thing and using is the other. But the thing is, gentoo ends up with central repository, anyway. Provided the repository is less ancient than CVS (which is basically subversion), distributed users can branch it without having to have commit access. This hybrid model makes much more sense to me than forcing everyone to use DSCM. I have exercised the approach on overlay before I was granted commit access and now continue to work the same way pushing my branches back to svn. I think this possibility totally invalidates the very idea of DSCM importance. This makes a lot of sense. Since there are people who offer facilities, perhaps a good answer is Please set up a mirror of our anoncvs as this will enable quicker disaster recovery. That would give redundancy for 98% of the material, as noted, and is easily done. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New ALSA maintainers
Daniel Drake wrote: I have suggested that herd support for the kernelspace side (alsa-driver) be slowly reduced, by redirecting users who file bugs against it to reproduce with the in-kernel drivers, and then let kernel handle the bug resolution. This will remove duplicated maintenance efforts. This is perfectly reasonable where it is a card with drivers in both, but alas-drivers supports a broader range of hardware, eg the echo audio cards (guess who has one ;) which have never been available in-kernel. This will also mean no more stabling of -rc releases (and probably fewer of those in portage at all). Sounds fine. alsa-driver won't be going away altogether, as it is still needed for 2.4 users (but we won't support them forever) and I think it may include a couple of drivers which aren't yet in the kernel tree. So the bug resolution for cards with drivers _not_ in the kernel will be to pass them upstream if they are reproducible? I guess I'd like some assurance that as long as alsa-drivers supports hardware for which there are no kernel drivers, it will at least be available in the portage tree. It might be worth stripping duplicate drivers out of alsa-drivers altogether so that the two might even co-exist? Would eliminate the bug duplication in any event. From what I've read in this thread, the only area of difficulty would be new chipsets, but then there'd be more developer time with less bugs, and that seems to be the way things are going anyhow. Thanks for all your hard work on the kernel. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
I have suggested that herd support for the kernelspace side (alsa-driver) be slowly reduced, by redirecting users who file bugs against it to reproduce with the in-kernel drivers, and then let kernel For what it's worth, the PPC team has been suggesting the use of the in-kernel drivers for a while now (more than a year) since things just seem to be easier that way. -Joe -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
On 3/28/07, Daniel Drake [EMAIL PROTECTED] wrote: Jakub Moc wrote: Bryan Østergaard napsal(a): Nobody is forcing anybody to use in-kernel drivers. Uhm... http://bugs.gentoo.org/show_bug.cgi?id=172490 Sorry, my comments on that bug are a little unclear. I am not suggesting removal of alsa-driver from Portage, neither I am suggesting that the documentation stops documenting alsa-driver, nor am I suggesting any other way of forcing people to move away from it. I am simply asking if the documentation team are willing to recommend the in-kernel version over the portage one, given that the in-kernel one is being properly maintained and the portage one is not. This is different from forcing someone to use in-kernel drivers. Now that makes much more sense to me and I agree with it. Users should use the in-kernel driver unless it doesn't work. -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E
