Re: debian and lilypond 2.12
Gauvain Pocentek wrote: Hi all, On 06/07/2009 03:59 PM, Gilles Filippini wrote: really don't want to take over the package without interaction with Thomas. But I'm definitly interesting in helping out with this package, maybe in a team as Vincent Bernat suggested in an other mail. Maybe you can put the package in the Debian Multimedia Team and help maintaining it? \r http://wiki.debian.org/DebianMultimedia -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Uwe Kleine-König wrote: Hi, I was wondering about how far are we with implementing a RT kernel in Debian... Some progress here? Would be nice. The patch I created that "fits" on Debian's vanilla kernel creates conflicts on the sources with the Debian patches. I hope to be able to clean that up by minimizing the -rt series (e.g. the first broken out patch consists usually of various bits from the -tip tree that are (AFAIK) not all needed.) So just have some more patience. How are things going? Just interest... Hhhm, well, I spottet a problem. The thing is that linux-rt does many deep changes in the kernel and I won't be able to support the harder problems. And upstream probably won't help because the Debian rt-kernel isn't a vanilla rt-kernel. Moreover even the broken out rt-patch isn't nicely sorted (e.g. bisectable, some patches undo changes of other patches earier in the series etc. pp), so I fear the Debian kernel team isn't filled with enthusiasm when asked to add an rt variant. I already thought about packaging debian-kernel + rt for Debian and vanilla-kernel + rt for a non-Debian package repository such that it's easy for bug reporters to try out a vanilla kernel. But that still needs more work. I currently investigate how the Debian kernel packages are created. Any help is welcome. Probably the first step will be to create a vanilla-rt package, but that wont be accepted to go into Debian main. Just trying to keep thinks a bit alive here ;) How are things going Uwe? Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Uwe Kleine-König wrote: Hello, I was wondering about how far are we with implementing a RT kernel in Debian... Some progress here? Would be nice. The patch I created that "fits" on Debian's vanilla kernel creates conflicts on the sources with the Debian patches. I hope to be able to clean that up by minimizing the -rt series (e.g. the first broken out patch consists usually of various bits from the -tip tree that are (AFAIK) not all needed.) So just have some more patience. How are things going? Just interest... \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Uwe Kleine-König wrote: Hello, I was wondering about how far are we with implementing a RT kernel in Debian... Some progress here? Would be nice. The patch I created that "fits" on Debian's vanilla kernel creates conflicts on the sources with the Debian patches. I hope to be able to clean that up by minimizing the -rt series (e.g. the first broken out patch consists usually of various bits from the -tip tree that are (AFAIK) not all needed.) So just have some more patience. Thanks for the head up. I'm glad that there is work in progress and am able to wait with patience knowing that ;) \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Uwe Kleine-König wrote: Hello, [your To: header was strange, maybe my mail reaches less recipents than your's] To get some progress here, I'm searching for a person who wants and is capable in filing a wishlist bug (with a patch vs. the package linux-2.6 Maybe providing a patch package is a better first step? thanks for thinking. Who could provide such a patch package? I can. I'd need a sponsor, though. I know two Debian developers, I will ask them. The patch on top of Debian's 2.6.29 is already made[1]---I just merged v2.6.29-rt1 and Debian's tree. Best regards Uwe [1] Available in my git repo at git://git.pengutronix.de/git/ukl/linux-2.6.git debian-rt or browsable at: http://git.pengutronix.de/?p=ukl/linux-2.6.git;a=shortlog;h=debian-rt The actual diff is at: http://git.pengutronix.de/?p=ukl/linux-2.6.git;a=commitdiff;h=debian-rt;hp=debian/v2.6.29 Hi all, I was wondering about how far are we with implementing a RT kernel in Debian... Some progress here? Would be nice. Regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Felipe Sateler wrote: Grammostola Rosea wrote: Fabian Greffrath wrote: Grammostola Rosea schrieb: But that doesn't really solve the problem imo. The problem is solved when Ardour in unstable hit testing and then stable after a while. Now it seems to be stuck in unstable... You don't seem to understand the Debian release policy. Once a stable version has been released, there is zero chance that another package will be added. The only chance for ardour to be part of a stable Debian release is Squeeze, not Lenny. I understand it. But my point still is there... Also maybe Debian can be a bit less conservative when such a core app is not in stable and stable releases go out the door after years! I guess some packages are added in Etch after a while. But main point is, that Ardour should hit testing after a while. BTW, ardour migrated to testing yesterday. That's great news! Thanks for listening and time and efforts! \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Fabian Greffrath wrote: Grammostola Rosea schrieb: But that doesn't really solve the problem imo. The problem is solved when Ardour in unstable hit testing and then stable after a while. Now it seems to be stuck in unstable... You don't seem to understand the Debian release policy. Once a stable version has been released, there is zero chance that another package will be added. The only chance for ardour to be part of a stable Debian release is Squeeze, not Lenny. I understand it. But my point still is there... Also maybe Debian can be a bit less conservative when such a core app is not in stable and stable releases go out the door after years! I guess some packages are added in Etch after a while. But main point is, that Ardour should hit testing after a while. Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Uwe Kleine-König wrote: Hello, I guess there are multimedia users out there who care much about a stable system, reproducible results and have to earn some money from their work - so they do not want to deal with unforseable changes. Please do not advertise testing as a release which is ready for users. (Yes, I admit I use testing in the way you describe - but *I* know what I'm doing.) But is not that big problem to install two kernels? One, the default Lenny kernel and an RT kernel from testing? To get some progress here, I'm searching for a person who wants and is capable in filing a wishlist bug (with a patch vs. the package linux-2.6 Maybe providing a patch package is a better first step? thanks for thinking. Who could provide such a patch package? \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Grammostola Rosea wrote: Andreas Tille wrote: On Sat, 28 Mar 2009, Cassiel wrote: debian stable aims to production servers, That's wrong. Debian stable aims at production systems. If your arguing would be true I wonder why stable contains applications like Openoffice.org or audio players or ... IMO multimedia users can/should live with testing without any fear of system crashes and security updates. I guess there are multimedia users out there who care much about a stable system, reproducible results and have to earn some money from their work - so they do not want to deal with unforseable changes. Please do not advertise testing as a release which is ready for users. (Yes, I admit I use testing in the way you describe - but *I* know what I'm doing.) But is not that big problem to install two kernels? One, the default Lenny kernel and an RT kernel from testing? To get some progress here, I'm searching for a person who wants and is capable in filing a wishlist bug (with a patch vs. the package linux-2.6 thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Andreas Tille wrote: On Sat, 28 Mar 2009, Cassiel wrote: debian stable aims to production servers, That's wrong. Debian stable aims at production systems. If your arguing would be true I wonder why stable contains applications like Openoffice.org or audio players or ... IMO multimedia users can/should live with testing without any fear of system crashes and security updates. I guess there are multimedia users out there who care much about a stable system, reproducible results and have to earn some money from their work - so they do not want to deal with unforseable changes. Please do not advertise testing as a release which is ready for users. (Yes, I admit I use testing in the way you describe - but *I* know what I'm doing.) But is not that big problem to install two kernels? One, the default Lenny kernel and an RT kernel from testing? \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Free Ekanayaka wrote: Hi Vincent, |--==> On Wed, 25 Mar 2009 14:31:38 +0100, Vincent Danjean said: VD> Grammostola Rosea wrote: >>I read this on the Debian multimedia mailinglist: >>>Unfortunately lenny was already freezed by that time, and although >>>both of the above updates were really safe (IMO) and despite all the >>>efforts I and especially Reinhard put into convincing the release >>>managers, we are unable to convince them to accept the updates in >>>lenny. >>> >>>I personally felt very disappointed by all this, especially >>>considering that lenny got out *2* months later. >> >>Please some reactions on this issue and I hope it can be solved! Would >>be great! :) VD> IMHO, the best thing to do in these cases is to prepare lenny backports of VD> the packages... VD> It is not as good as if the packages were in lenny, but it allows lenny users VD> to easily install the packages without switching to testing or waiting for VD> the next release. A backport for Lenny is available in the 64 Studio repositories, see: http://wiki.debian.org/DebianMultimedia But that doesn't really solve the problem imo. The problem is solved when Ardour in unstable hit testing and then stable after a while. Now it seems to be stuck in unstable... Also the backport is an 64studio repo, people expect Lenny backports to be in the Lenny backports... \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Adrian Knoth wrote: On Wed, Mar 25, 2009 at 12:37:37PM +0100, Grammostola Rosea wrote: Why only in 64studio and not in plain Debian? What's good for Debian is good for us :-) but the Debian project may not want to tweak the kernel or the FireWire stack just for the benefit of FFADO users. In the 64 Studio project we have more flexibility to do things like that. Some background info here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463 What is true about this? Shouldn't plain Debian also support those Pro audio Firewire devices, the ones the FFADO team are making drivers for? It's easy: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration#Module_auto-loading Compile both modules and blacklist the new Juju modules. That's the current upstream recommendation. Even if the default will change around 2.6.30 (or later, I don't know the exact schedule), the FFADO users could still enable the old ieee1394 modules. We already have libraw1394-v2 in sid, but as outlined, FFADO currently only works with the old stack. This might also change in the future, especially if the Google Summer of Code project succeeds. (in-kernel alsa driver module for firewire audio) IOW: ship both stacks, decide for one and blacklist the other. FFADO users will then select the appropriate one. And of course, I'll continue looking into the FFADO-on-Juju issue. I asked an guy who did some work on the RT kernel for Ubuntu. This is what he said: 1) Ubuntu RT kernel don't offer the same guarantees that offer one of the Debian kernels. For example DOS vulnerabilities are accepted into Ubuntu RT Kernel (because it live in universe) when in Debian aren't accepted at all. 2) Kernel packages between Debian and Ubuntu are very different. Different version, different build infrastructure, different approach in accepting external sources. These packages are one of few packages that Ubuntu don't inherit from Debian. 3) Lenny is just released. I suppose that the next Debian release will probably be in two years. In meanwhile it is probably that almost rt bits will be merged and available in vanilla kernel (when it happen the rt kernel could became one of all kernel flavours that Debian offers). In other words a lot of effort is required for satisfy high quality requested by Debian policy. Comments on this? \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Kushal Koolwal wrote: About 6 months back I had done some extensive benchmarking on real-time kernels applying RT patch to Debian stock kernel on x86 architecture. I read about call for help in maintaining,testing debian rt kernel here: http://marc.info/?l=linux-rt-users&m=123808104027590&w=2 I will be glad to offer help in testing real-time kernels. I only have x86 machines. Please note I am not a DD. Kushal Koolwal Thanks for your offer! How experienced are you? Cause I think we're searching for some project leaders. Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Cassiel wrote: 2009/3/26 Tzafrir Cohen <mailto:tzaf...@cohens.org.il>> I'm trying to follow this thread, but I'm not sure everybody here even using the same terminology. On Thu, Mar 26, 2009 at 02:01:22PM +0100, Cassiel wrote: > Hi > > 2009/3/26 Adrian Knoth mailto:a...@drcomp.erfurt.thur.de>> > > > On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote: > > > > > The problem is an realtime kernel and a proper configuration for music > > > production. Without that, you better stay away from music production > > > > Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks, > > ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running > > on a dualcore amd64 laptop. > > > > It's an outdated myth that you need RT kernels for audio production, > > though it helps with very low latencies. (let's say buffer sizes below > > 10ms and high CPU loads) > > > > > maybe it is worthwhile to clarify where "audio production" begins and "audio > fun" ends. > Recording 16 tracks + monitoring could be an impossible task with your !=RT > kernel. Could you please be more specific? What extra patches do you think need applying? What changes to the configuration are needed? Vs. what upstream kernel version? References, supporting benchmarks and such would be an added bonus. When talking about RT kernel only one patch comes into play -->> http://www.kernel.org/pub/linux/kernel/projects/rt/ other references regarding kernel config are found in -->> http://www.alsa-project.org/main/index.php/Low_latency_howto IMHO, the upstream kernel version should follow the RT patch releases. That would be a nice thing imho, yes. Benchmarks can be easily provided by users if encouraged to use the same toolbox, eg.-->> http://git.kernel.org/?p=linux/kernel/git/tglx/rt-tests.git;a=summary Actually I have none but as I introduced in the previous post recording one more track on my i386 PentiumIV dual core running Ardour with 14-16 tracks + fx + software monitoring (i.e. ardour) is possible running RT kernels, running stock kernels results in too many xruns. Much info about RT kernels you find here: http://rt.wiki.kernel.org/index.php/Main_Page -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Reinhard Tartler wrote: Grammostola Rosea writes: Could you comment on this? I think it's the best when Ardour will hit Lenny. New packages are not in scope of the update policy of released debian versions. So this is not going to happen. Second option is as a Lenny backport. That's more likely. However only packages in testing are candidates for lenny-backports. Btw. why doesn't Ardour from unstable hit testing? This is normal for packages in Sid after some time right? Now there is no Ardour in stable AND testing. http://release.debian.org/migration/testing.pl?package=ardour So this should be fixed, wait till it hit testing and then make an backport? \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Andreas Tille wrote: On Wed, 25 Mar 2009, Grammostola Rosea wrote: taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia "menu" in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. That was clear, but it bumped up a old idea I had in my head ;) Please take that idea serious... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. But we do not choose a distro - we just have a distro which is called Debian. And we want to handle the packages which are just inside Debian. The choice inside Debian was done based on the user interest and time of developers. Now you misunderstood what I said ;) Maybe I was not clear, but the discussion was about which apps you should choose for such a metapackage, and I said, just pick some common used apps, to give an idea what is possible. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. Well, I think the problem with the RT kernel was understood and it is just a an issue of just *doing* the actual packaging - so why not just starting with this? [bit offtopic, there is another thread about this] I really like the openness for an RT kernel in Debian. I didn't expect it, so I'm really happy with. I hope some guys will jump in ! I will do my best to tell it around and ask people to join [/bit offtopic, there is another thread about this] Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia "menu" in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Well, sure the applications will be installed in the menu of your desktop if you if you installed the according package - but there is no central place to pick the packages which might be interesting. Just take me as a more or less multimedia ignorant person I would have a hard time to find out all the relevant packages for graphical sequencing so I'd be really glad if there would be a tasks page which assembles the short descriptions and links to the homepage of the projects to enable a quick overview. In how far it is different for instance to Debian Junior's puzzles page. There are a lot of nice puzzles in Debian and you will finally pick some favourites of them. So why not presenting a reasonable overview about what is there? sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing?
Vincent Danjean wrote: Grammostola Rosea wrote: I read this on the Debian multimedia mailinglist: Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. Please some reactions on this issue and I hope it can be solved! Would be great! :) IMHO, the best thing to do in these cases is to prepare lenny backports of the packages... It is not as good as if the packages were in lenny, but it allows lenny users to easily install the packages without switching to testing or waiting for the next release. Free (Debian Multimedia member), Could you comment on this? I think it's the best when Ardour will hit Lenny. Second option is as a Lenny backport. Btw. why doesn't Ardour from unstable hit testing? This is normal for packages in Sid after some time right? Now there is no Ardour in stable AND testing. Thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
Hi, Now we're talking about improving Debian for multimedia, realtime kernels and the like, I thought let's make some work on more things to overcome some dissadvantages of Debian for audio production compared to other distro's. Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... I read this on the Debian multimedia mailinglist: EDR> It's not a matter of debian developer laziness ... the ardour in sid EDR> needs patches to _upstream_ libraries. If/when those upstream libraries EDR> accept the patches the ardour devs need, then those libraries can get EDR> into debian and ardour can use the debian packaged versions rather than EDR> it's own forked versions. 100% agreed, ardour not in lenny is a Real Pity (TM). To recap happened: 0) the ardour package was built against some 3rd party libs shipped inside the upstream tarball, this raised an RC bug 1) that bug was around for a long time, there were no easy fix for that, but eventually all of the patches made it the 3rd party upstream projects, which in turned made it to si 2) I've fixed RC bug in ardour in version 2.7.1-2 http://packages.debian.org/changelogs/pool/main/a/ardour/ardour_2.7.1-2/changelog It was on Dec 18th, that means nearly 2 months before lenny got release. At this point ardour was RC-free BUT.. 3) It was depending on jackd 0.109.2, uploaded a few days before. Note that jack 0.109.2 was a very important release because it fixed important bugs in version 0.106, which had been around for almost one year. Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. ( http://www.mail-archive.com/debian-multime...@lists.debian.org/msg03163.html ) Please some reactions on this issue and I hope it can be solved! Would be great! :) Thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Andreas Tille wrote: On Tue, 24 Mar 2009, nescivi wrote: Given that there are several audio oriented distributions based on Debian (e.g. 64studio and pure:dyne) that would benefit from this, and I am sure their teams may be interested in helping to support it too. IMHO it makes perfectly sense to try to join forces with these Debian based distributions and try to comaintain a -rt kernel package together with these guys to ensure a solit maintenance inside Debian. A lot of linux audio users build their own patched kernels, because they can't get it from the distribution; So why don't these people try to go the right way (tm) and work on an official -rt kernel package? and not all of them enjoy doing it. (I've kept postponing it, but if I don't find one in a distro soon, I'll probably have to... the current Ubuntu rt kernel seems to have some other issues I believe... at least on 64bit...) One reason more to finally solve the problem in the source distribution to make sure that all derivers will profit from it. A little sidestep: Also for a realtime kernel for music production it's important to have the right drivers in it, to support firewire devices for example. I read this on the Debian multimedia mailinglist: We're aiming to have this package in 64 Studio 3.0, we also need to change our 2.6.29-rc4 kernel to support the old firewire stack though. >> Why only in 64studio and not in plain Debian? What's good for Debian is good for us :-) but the Debian project may not want to tweak the kernel or the FireWire stack just for the benefit of FFADO users. In the 64 Studio project we have more flexibility to do things like that. Some background info here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/276463 What is true about this? Shouldn't plain Debian also support those Pro audio Firewire devices, the ones the FFADO team are making drivers for? Regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: realtime kernel for Debian
Giacomo A. Catenazzi wrote: Raphael Hertzog wrote: On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote: Do you really need real time kernel? Debian is a technical driven project, but reading the previous two quotes, "real time" is used as marketing thing. It's good to question the use of any feature, but a real-time kernel is certainly very useful in many industrial applications and Debian is popular in that field. (Don't put a marketing label on anything where you are not yourself sure of your expertise.) Yes, I didn't write very well my sentence: the previous quotes was more about "there exist rt kernels", "ubuntu has a rt kernel", but not solid requirements. I had to write some "seems", and I'm sorry for the two quoted people if it seems an attack. Anyway, later in the mail, I asked for precise needs, so we could see better what we should improve. IMHO most users want a low latency kernel, but not a slower kernel, so a CONFIG_HZ_1000 would be nice. But the original post was about multimedia production (and not reproduction), so the needs are probably other. My point was more: - Debian has not rt kernel. Why? Non DD interested or/and low demand? This is an important point. We must not produce a rt-kernel if we cannot provide testers and developers (in unstable). - kernel management is a weak point in distribution: no good method for kernel dependencies, using full capabilities, ... so IMHO we should try harder with the normal kernel, so that we can use the same infrastructure and testers. If we fail and we are able to support rt kernels, IMO it is good to provide it in Debian. The original mail was about "multimedia production" and few year ago kernel developers had a lot of interaction with music industries. I'm not an expert in the field, but how far are we in their need with standard kernels?) I do use a real-time kernel on a Debian based system for one of my customers (but I have to recompile the kernel anyway because I do other customizations) and I have good reasons to do so because I can't suffer serial overrun and I must ensure that the serial interrupt handler is run in the required time and that no other (kernel) task has higher priority. These *other customizations* are important to rt-kernel. So we need a person (or more) that know the needs and could support us. "realtime" alone is only a label ;-) Thanks for the reactions so far! I think the newer kernels are improved for realtime (for audio usage, real low latency etc.). And there was some discussion about better realtime support in default kernels: http://linuxmusicians.com/viewtopic.php?f=24&t=490 I think 95% of the users of the linuxaudio.org community (LAU mailinglist) uses a realtime kernel (CONFIG_HZ_1000 + Mingo patch (!?)). Discussion if it is still needed bumps up there once in a while, for example: http://linuxaudio.org/mailarchive/lau/2009/3/10/153190 But till now people reports better results (mostly in terms of latency and xruns for jackd) with a patched kernel. I know two people has started working again on rt patches for the newer kernel: http://lwn.net/Articles/319544/ quote: The realtime preemption project is a longstanding effort to provide deterministic response times in a general-purpose kernel. Much code resulting from this work has been merged into the mainline kernel over the last few years, and a number of vendors are shipping commercial products based upon it. But, for the last year or so, progress toward getting the rest of the realtime work into the mainline has slowed. On February 11, realtime developers Thomas Gleixner and Ingo Molnar resurfaced with the announcement of a new realtime preemption tree and a newly reinvigorated development effort. Merging into the mainline kernel would be the best imho. So people who want to record stuff, realtime with fx, can use the default kernel. It would make a lot of people pretty happy. Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
realtime kernel for Debian (was: Please Improve Debian for Multimedia Production)
Jim wrote: Grammostola Rosea, I want also to direct your attention to the kernel, as it has the possibility to be more supportive of those specific needs, by having low latency and real-time extensions patched and enabled. The debian folks (especially "waldi" aka Bastien Blank will say some or all of these are less stable than they could be -- perhaps googling around or asking him when he's not so busy will drum up some details.) Mmh this is interesting, cause there is an realtime kernel available in the ubuntu hardy repo, but not in Debian yet. Would be nice if there was one which users could install. But I'm not an rt-kernel expert at all, so maybe I should forward this to some other people... But I think it's good to have some discussion about a realtime kernel for Debian on the Debian-dev list... Looking forward to your opinions on this. \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Michael Hanke wrote: Hi, On Fri, Mar 20, 2009 at 04:29:35PM +0100, Fabian Greffrath wrote: As an additional hint the multimedia team might consider using the Debian Pure Blends framework which enables them to show quite simply what is just there and what they are working on (for instance see just issued bits [1]). So if you are interested in those tasks and bugs pages or in multimedia related metapackages just ask me in case there might be some technical questions about Blends. You can read more here [2]. Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian Multimedia Team, we don't see ourself as a Debian Blend. We are just a bunch of maintainers maintaining a bunch of packages *in* Debian: Right, and that is what blends are about -- maintaining packages *in* Debian. You just get some additional magic that helps you to make your work a bit more visible and guides users like the starter of this thread, as well as potential contributers My aim as the thread starter was to ask for developers and/or package maintainers for multimedia in Debian. Because there are a lot nice packages which are not in Debian now or are pretty outdated. I know the Debian Multimedia Team exist, but I think they can use some help here... Regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please Improve Debian for Multimedia Production
Hi, Since a while I'm pretty active in using Debian/Linux for Multimedia production, especially focusing on music production (check www.linuxmusicians.com for instance). Debian is a great system to use for this. Unfortunately there are nice music production applications which are not in Debian yet or are pretty outdated (also those in unstable). It would be nice if we could improve Debian for multimedia production and package more multimedia packages and keep them up to date. For instance, I posted some apps which are not in Debian right now as wishes (RFP): http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com (There is work on progress on Frescobaldi, Rumor (my first Debian package ;) ) and Gtklick.) Of course we have the Debian Multimedia Team, which takes care of a lot of multimedia packages for Debian. So if you like to help in this progress, the best thing you could do imo is joining the Debian Multimedia Team: http://wiki.debian.org/DebianMultimedia http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers Thanks in advance, \r ps: I'm not an official member of the Debian Multimedia Team myself. I'm just a musician which uses Debian now, but I think I'm gonna join the team myself. I recently build my first Debian package :), so I'm almost ready to join ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Fwd: Re: Bug#520236: Please package minicomputer for Debian]
Hi, I reported approximately 6 bugs, which where actually RFP. I reported those as wishes, not as RFP. For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241 Can I change it? How? \r --- Begin Message --- On Wed, Mar 18, 2009 at 11:34:37AM +0100, rosea wrote: > Package: minicomputer > Severity: wishlist Whoa. Could you please read http://www.debian.org/devel/wnpp/ (look for "RFP") before submitting any more of these? The batch of bugs you're filing are all going into a state where they need to be fixed up by hand, at the moment ... -- Colin Watson [cjwat...@debian.org] --- End Message ---
building packages/ chroot/ pbuilder/...
Hi, I want to build packages for Debian. I'm running a debian testing/unstable mix, but the packages should be build in Sid right? How should I do it? I've seen a lot of different tools/ways on the web... please give me some clear information and good references. I've also just setup a apt-cacher local mirror, should I do anything with it when setting up a building environment? Regards, \R -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
starting gnome with xephyr in chroot fails
I tried to start Xephyr: debian-live$ Xephyr :1 -screen 1024x768 -ac Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! but then in chroot environment: :/usr/bin# env DISPLAY=:1 gnome-session & (gnome-session:3729): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (gnome-session:3729): Gtk-WARNING **: cannot open display: :1 [1] 3729 [1]+ Exit 1 env DISPLAY=:1 gnome-session What could this be? Thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
