Uploading A/DeMuDi packages to Debian

[Free Ekanayaka]

Hi Junichi,

I'm starting a new thread, as we are turning page :)

JU> Condolences.
JU>
JU> I've just subscribed to the mailing list and the first major thread is
JU> this, a coincidence.
JU>

Well, it seems really you're the Deus Ex Machina from Debian then.. :)

JU> Anyway, I'm interested in merging what's available in DeMuDi into
JU> Debian proper, and getting crufty frameworks polished, and
JU> up-to-speed.

That's perfectly in the spirit of A/DeMuDi; as far as was possible
I've always tried to upload back to Debian what was done in A/DeMuDi.

One big obstacle is that I'm not yet a DD, though I've passed the
tests of the NM process almost one year ago, see:

https://nm.debian.org/nmstatus.php?email=free%40agnula.org

I was put on hold because my GPG subkey was expired. I've created a
new one and pinged the DAMs a couple of times, no reply :/

Honestly I never understood why such a pain..

I have a few packages in the archive yet, and I find it a bit
difficult to maintain them (or upload new ones), as I always need to
bother some DD to sponsor me. So I often end up using mentors.d.n..

JU> 1. patched kernels -- they can enter Debian as tailored kernels,
JU> probably after a few disagreements with FTP team and
JU> debian-installer team for having too many kernel flavors
JU>

Having the kernel in the archive would be great, but even maintaining
it outside it's not bad, especially once that all kernel-patch
packages of the case are in the pool.

Note also that the most important patch for A/DeMuDi, the
realtime-preempt one, usually doesn't apply cleanly on the patch
Debian kernel source, and would require some modifications (however I
recently noticed that since the latest 2.6.15, it applies cleanly on
Debian sources too).

JU> 2. patched packages -- they can enter Debian with patches merged,
JU> probably having a coordinated effort using debian-multimedia ML as
JU> a place for coordination
JU>

Sure. Actually there are very few patched packages, for most I've
submitted bug to the BTS, but I'd like the divergence to be eventually
zero.

JU> 3. CDs -- they probably need to be hosted outside of Debian, since
JU> they will be chunky.
JU>

This is true for any CDD, at the moment. Till the concept of CDD gets
really integrated into Debian, it will be difficult to have CD images
in.

JU> 4. scripts to generate the CDs -- they can be packaged into Debian, so
JU> that anyone could theoretically build a CDD from Debian sources.
JU>

I'd love to see this, but it would require some work. Probably adding
some features to existing package like debian-cd would almost
eliminate the need of such scripts at all.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> Anyway, I'm interested in merging what's available in DeMuDi into
JU> Debian proper, and getting crufty frameworks polished, and
JU> up-to-speed.
That's perfectly in the spirit of A/DeMuDi; as far as was possible
I've always tried to upload back to Debian what was done in A/DeMuDi.
One big obstacle is that I'm not yet a DD, though I've passed the
https://nm.debian.org/nmstatus.php?email=free%40agnula.org
I was put on hold because my GPG subkey was expired. I've created a
new one and pinged the DAMs a couple of times, no reply :/

For this particular problem I think you'll have to demonstrate that
you are now in control of gpg intrinsics, which shall need a bit more
time.

Post by Free Ekanayaka
I have a few packages in the archive yet, and I find it a bit
difficult to maintain them (or upload new ones), as I always need to
bother some DD to sponsor me. So I often end up using mentors.d.n..

In my experience so far, co-maintenance model seems to be less of a
hassle. Sharing a CVS/svn/arch tree with several people, and
uploading the resulting package is much easier than inspecting a
package tarball/diff/.dsc.

Post by Free Ekanayaka
JU> 1. patched kernels -- they can enter Debian as tailored kernels,
JU> probably after a few disagreements with FTP team and
JU> debian-installer team for having too many kernel flavors
JU>
Having the kernel in the archive would be great, but even maintaining
it outside it's not bad, especially once that all kernel-patch
packages of the case are in the pool.
Note also that the most important patch for A/DeMuDi, the
realtime-preempt one, usually doesn't apply cleanly on the patch
Debian kernel source, and would require some modifications (however I
recently noticed that since the latest 2.6.15, it applies cleanly on
Debian sources too).

It would be nice to have some communication with debian-kernel
guys. They tend to be around on #debian-***@opn irc channel or the
mailing list, and are quite active.

Post by Free Ekanayaka
JU> 2. patched packages -- they can enter Debian with patches merged,
JU> probably having a coordinated effort using debian-multimedia ML as
JU> a place for coordination
JU>
Sure. Actually there are very few patched packages, for most I've
submitted bug to the BTS, but I'd like the divergence to be eventually
zero.

Okay, that's fine.

I'm suspecting that there are quite a few packages that are not
updated in Debian archive but are in agnula. It would be nice to get
them included to Debian.

Let's start with the easy part: I'll do the sponsoring, or
co-maintenance; whichever you prefer, to decrease the difference
between Debian and what's in DeMuDi.

I guess this is it:
http://demudi.agnula.org/packages/PACKAGES.LIST

...ah, there is already a DeMuDi subversion repository.

Could you add me to the project ? I'm '***@debian.org'.

regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,
JU> Anyway, I'm interested in merging what's available in DeMuDi into
JU> Debian proper, and getting crufty frameworks polished, and
JU> up-to-speed.

Post by Free Ekanayaka
That's perfectly in the spirit of A/DeMuDi; as far as was possible
I've always tried to upload back to Debian what was done in A/DeMuDi.
One big obstacle is that I'm not yet a DD, though I've passed the
https://nm.debian.org/nmstatus.php?email=free%40agnula.org
I was put on hold because my GPG subkey was expired. I've created a
new one and pinged the DAMs a couple of times, no reply :/

JU> For this particular problem I think you'll have to demonstrate that
JU> you are now in control of gpg intrinsics, which shall need a bit more
JU> time.

I've suspected something like that, but what disappointed me most is
that I got no reply to my mails.

Post by Free Ekanayaka
I have a few packages in the archive yet, and I find it a bit
difficult to maintain them (or upload new ones), as I always need to
bother some DD to sponsor me. So I often end up using mentors.d.n..

JU> In my experience so far, co-maintenance model seems to be less of a
JU> hassle. Sharing a CVS/svn/arch tree with several people, and
JU> uploading the resulting package is much easier than inspecting a
JU> package tarball/diff/.dsc.

Yes, that would be a perfect model for me. I don't care too much of
uploading myself or having somebody else who upload on my behalf, but
he has to be responsive and check the packages when it's time to
upload.

JU> 1. patched kernels -- they can enter Debian as tailored kernels,
JU> probably after a few disagreements with FTP team and
JU> debian-installer team for having too many kernel flavors
JU>

Post by Free Ekanayaka
Having the kernel in the archive would be great, but even
maintaining it outside it's not bad, especially once that all
kernel-patch packages of the case are in the pool.
Note also that the most important patch for A/DeMuDi, the
realtime-preempt one, usually doesn't apply cleanly on the patch
Debian kernel source, and would require some modifications (however I
recently noticed that since the latest 2.6.15, it applies cleanly on
Debian sources too).

JU> It would be nice to have some communication with debian-kernel
JU> guys. They tend to be around on #debian-***@opn irc channel or the
JU> mailing list, and are quite active.
Good.

JU> 2. patched packages -- they can enter Debian with patches merged,
JU> probably having a coordinated effort using debian-multimedia ML as
JU> a place for coordination
JU>

Post by Free Ekanayaka
Sure. Actually there are very few patched packages, for most I've
submitted bug to the BTS, but I'd like the divergence to be eventually
zero.

JU> Okay, that's fine.

JU> I'm suspecting that there are quite a few packages that are not
JU> updated in Debian archive but are in agnula. It would be nice to get
JU> them included to Debian.

JU> Let's start with the easy part: I'll do the sponsoring, or
JU> co-maintenance; whichever you prefer, to decrease the difference
JU> between Debian and what's in DeMuDi.

JU> I guess this is it:
JU> http://demudi.agnula.org/packages/PACKAGES.LIST

JU> ...ah, there is already a DeMuDi subversion repository.

JU> Could you add me to the project ? I'm '***@debian.org'.

There's also an Alioth project:

http://alioth.debian.org/projects/demudi

along with a subversion repository:

http://svn.debian.org/wsvn/demudi

My original plan when I've applied for the Alioth project was to
create a working area for maintaining packages in the multimedia area.
This is simpler than spawning a new project for every package, which
are often very simple. That's why I wanted to name the Alioth project
as "debian-multimedia", I didn't want to put the stress on A/DeMuDi,
but the length of the name exceeded the limits :/

Now we could consider the idea again.. what do you think?

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> http://demudi.agnula.org/packages/PACKAGES.LIST
JU> ...ah, there is already a DeMuDi subversion repository.
http://alioth.debian.org/projects/demudi
http://svn.debian.org/wsvn/demudi

http://demudi.alioth.debian.org/browser/ on
http://demudi.agnula.org/wiki/DevelopRepository was a dead link,
http://svn.debian.org/wsvn/demudi, on the other hand, seems to work
better.

Looking into the repository, I'd need a method to obtain upstream
tarballs. I am assuming debian/watch files are enough to obtain them.

Post by Free Ekanayaka
My original plan when I've applied for the Alioth project was to
create a working area for maintaining packages in the multimedia area.
This is simpler than spawning a new project for every package, which
are often very simple. That's why I wanted to name the Alioth project
as "debian-multimedia", I didn't want to put the stress on A/DeMuDi,
but the length of the name exceeded the limits :/
Now we could consider the idea again.. what do you think?

I should think quite a few people will be interested in doing the
uploading part, I could do for a starters, and others can join in
later. We should probably have an IRC channel for demudi so that we
don't try to tred on each other's toes, and a mailing list so that
requested uploads can be tracked. We can probably use
debian-***@l.d.o for the mailing list, do you have a IRC channel?

regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> http://demudi.alioth.debian.org/browser/ on
JU> http://demudi.agnula.org/wiki/DevelopRepository was a dead link,
JU> http://svn.debian.org/wsvn/demudi, on the other hand, seems to work
JU> better.

JU> Looking into the repository, I'd need a method to obtain upstream
JU> tarballs. I am assuming debian/watch files are enough to obtain them.

The demudi repository on svn.debian.org is quite outdated.. Anyway I
usually import source packages with svn-inject along with the -o
option, so that we don't keep the whole upstream into SVN. As you say,
working watch files are enough to get the tarball.

Post by Free Ekanayaka
My original plan when I've applied for the Alioth project was to
create a working area for maintaining packages in the multimedia area.
This is simpler than spawning a new project for every package, which
are often very simple. That's why I wanted to name the Alioth project
as "debian-multimedia", I didn't want to put the stress on A/DeMuDi,
but the length of the name exceeded the limits :/
Now we could consider the idea again.. what do you think?

JU> I should think quite a few people will be interested in doing the
JU> uploading part, I could do for a starters, and others can join in
JU> later. We should probably have an IRC channel for demudi so that we
JU> don't try to tred on each other's toes, and a mailing list so that
JU> requested uploads can be tracked. We can probably use
JU> debian-***@l.d.o for the mailing list, do you have a IRC channel?

Yes, that mailing list is quite silent and needs a bit of revamp!
Maybe we could forward the commits to it? BTW I always dreamt about
forming a:

Debian Multimedia Team <debian-***@lists.debian.org>

which would be the Maintainer of all (or most of) the multimedia
packages in Debian, and care about quality assurance. Bug reports to
shall be reported to the lists and developers who directly care about
the package listed in the Uploaders field, like what happens with
debian-***@lists.debian.org does for the d-i packages.

We have a registered #demudi channel on FreeNode, but not a
#debian-multimedia AFAIK, I think someone should register it..

The #demudi channel is listed in the CIA bot too.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> http://demudi.alioth.debian.org/browser/ on
JU> http://demudi.agnula.org/wiki/DevelopRepository was a dead link,
JU> http://svn.debian.org/wsvn/demudi, on the other hand, seems to work
JU> better.
JU> Looking into the repository, I'd need a method to obtain upstream
JU> tarballs. I am assuming debian/watch files are enough to obtain them.
The demudi repository on svn.debian.org is quite outdated.. Anyway I
usually import source packages with svn-inject along with the -o
option, so that we don't keep the whole upstream into SVN. As you say,
working watch files are enough to get the tarball.

Okay, updating it to be up-to-speed and moving over to it as the main development environment might be a way forward.

Post by Free Ekanayaka

Post by Free Ekanayaka
My original plan when I've applied for the Alioth project was to
create a working area for maintaining packages in the multimedia area.
This is simpler than spawning a new project for every package, which
are often very simple. That's why I wanted to name the Alioth project
as "debian-multimedia", I didn't want to put the stress on A/DeMuDi,
but the length of the name exceeded the limits :/
Now we could consider the idea again.. what do you think?

JU> I should think quite a few people will be interested in doing the
JU> uploading part, I could do for a starters, and others can join in
JU> later. We should probably have an IRC channel for demudi so that we
JU> don't try to tred on each other's toes, and a mailing list so that
JU> requested uploads can be tracked. We can probably use
Yes, that mailing list is quite silent and needs a bit of revamp!
Maybe we could forward the commits to it? BTW I always dreamt about
which would be the Maintainer of all (or most of) the multimedia
packages in Debian, and care about quality assurance. Bug reports to
shall be reported to the lists and developers who directly care about
the package listed in the Uploaders field, like what happens with

That would be good. Real names of maintainers should be in the
Uploaders: field, but using debian-multimedia as a collective place to
discuss bugs would be cool.

Post by Free Ekanayaka
We have a registered #demudi channel on FreeNode, but not a
#debian-multimedia AFAIK, I think someone should register it..
The #demudi channel is listed in the CIA bot too.

Okay, I'm not too happy about freenode since it rejects my bot, but we
can probably work with it.

regards,
junichi

[Free Ekanayaka]

Post by Free Ekanayaka
The demudi repository on svn.debian.org is quite outdated.. Anyway I
usually import source packages with svn-inject along with the -o
option, so that we don't keep the whole upstream into SVN. As you say,
working watch files are enough to get the tarball.

JU> Okay, updating it to be up-to-speed and moving over to it as the
JU> main development environment might be a way forward.

Then I'll clean up the repository and start injecting all the packages
I handle, both in Debian or not. Packages not in Debian will have "-0"
as a revision number.

Post by Free Ekanayaka

Post by Free Ekanayaka
My original plan when I've applied for the Alioth project was to

Yes, that mailing list is quite silent and needs a bit of revamp!
Maybe we could forward the commits to it? BTW I always dreamt about
forming a:h
which would be the Maintainer of all (or most of) the multimedia
packages in Debian, and care about quality assurance. Bug reports to
shall be reported to the lists and developers who directly care about
the package listed in the Uploaders field, like what happens with

JU> That would be good. Real names of maintainers should be in the
JU> Uploaders: field, but using debian-multimedia as a collective place to
JU> discuss bugs would be cool.

Let's start this with the packages in the SVN repository, then we'll
advertise this on the debian-multimedia list.. is it acceptable or are
we trampling toes?

Post by Free Ekanayaka
We have a registered #demudi channel on FreeNode, but not a
#debian-multimedia AFAIK, I think someone should register it..
The #demudi channel is listed in the CIA bot too.

JU> Okay, I'm not too happy about freenode since it rejects my bot, but we
JU> can probably work with it.

Ok, anyway feel free to suggest or open a channel on another server.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka

Post by Free Ekanayaka
The demudi repository on svn.debian.org is quite outdated.. Anyway I
usually import source packages with svn-inject along with the -o
option, so that we don't keep the whole upstream into SVN. As you say,
working watch files are enough to get the tarball.

JU> Okay, updating it to be up-to-speed and moving over to it as the
JU> main development environment might be a way forward.
Then I'll clean up the repository and start injecting all the packages
I handle, both in Debian or not. Packages not in Debian will have "-0"
as a revision number.

If you are ready, you can ping me, and I'll try and sponsor whatever
needs sponsoring.

Post by Free Ekanayaka

Post by Free Ekanayaka

Post by Free Ekanayaka
My original plan when I've applied for the Alioth project was to

Yes, that mailing list is quite silent and needs a bit of revamp!
Maybe we could forward the commits to it? BTW I always dreamt about
forming a:h
which would be the Maintainer of all (or most of) the multimedia
packages in Debian, and care about quality assurance. Bug reports to
shall be reported to the lists and developers who directly care about
the package listed in the Uploaders field, like what happens with

JU> That would be good. Real names of maintainers should be in the
JU> Uploaders: field, but using debian-multimedia as a collective place to
JU> discuss bugs would be cool.
Let's start this with the packages in the SVN repository, then we'll
advertise this on the debian-multimedia list.. is it acceptable or are
we trampling toes?

We can probably initially work with Maintainer: set to your mail
address, and Uploaders: set to me.

After a bit more thought, I don't see an immediate benefit in making a
blanket team. I'll try discussing this in debian-multimedia ML before
that so that others will know and have time to consider.


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,

Post by Free Ekanayaka

Post by Free Ekanayaka
The demudi repository on svn.debian.org is quite outdated.. Anyway I
usually import source packages with svn-inject along with the -o
option, so that we don't keep the whole upstream into SVN. As you say,
working watch files are enough to get the tarball.

JU> Okay, updating it to be up-to-speed and moving over to it as the
JU> main development environment might be a way forward.

Post by Free Ekanayaka
Then I'll clean up the repository and start injecting all the packages
I handle, both in Debian or not. Packages not in Debian will have "-0"
as a revision number.

JU> If you are ready, you can ping me, and I'll try and sponsor whatever
JU> needs sponsoring.

Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

I've included you in the demudi project on Aioth, so you can:

svn checkout svn+ssh://***@svn.debian.org/svn/demudi

and get the sources. Commits are notified on this mailing list:

http://lists.alioth.debian.org/mailman/listinfo/demudi-commits

you may want to subscribe there too. I'll try to prepare more uploads
in the next days.

JU> We can probably initially work with Maintainer: set to your mail
JU> address, and Uploaders: set to me.

JU> After a bit more thought, I don't see an immediate benefit in making a
JU> blanket team. I'll try discussing this in debian-multimedia ML before
JU> that so that others will know and have time to consider.

Fine, one step at a time.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

Reading the BTS, it looks like it was a closed ITP.

Could you follow the usual Debian guidelines and fill in the fields
and Cc debian-***@l.d.o?
(if you already have the package, it should be trivial)

* Package name : fmit
Version : x.y.z
Upstream Author : Name <***@example.org>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
Description : Free Music Instrument Tuner


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

JU> Reading the BTS, it looks like it was a closed ITP.

I've noticed that the bug was closed, but I reopened it, following the
indications from David Moreno Garza who originally closed it. This is
the relevant log:

Bug reopened, originator not changed. Request was from Free Ekanayaka <***@64studio.com> to ***@bugs.debian.org. Full text and rfc822 format available.

Should I really submit a new ITP?

Cheers,

Free

[Junichi Uekawa]

Hi,

This is just to note that we're trying to package fmit.
It's a GPL tuner.

Post by Free Ekanayaka
JU> Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

JU> Reading the BTS, it looks like it was a closed ITP.
I've noticed that the bug was closed, but I reopened it, following the
indications from David Moreno Garza who originally closed it. This is
Should I really submit a new ITP?

Nah, I don't think that's worth it.

I've noticed the following lintian warnings, and they sound like
legitimate ones; care to fix?

W: fmit: binary-without-manpage fmit
W: fmit: zero-byte-file-in-doc-directory usr/share/doc/fmit/NEWS.gz
W: fmit: zero-byte-file-in-doc-directory usr/share/doc/fmit/README


regards,
junichi

[Free Ekanayaka]

Post by Free Ekanayaka
Should I really submit a new ITP?

JU> Nah, I don't think that's worth it.

Fine.

JU> I've noticed the following lintian warnings, and they sound like
JU> legitimate ones; care to fix?

JU> W: fmit: binary-without-manpage fmit
JU> W: fmit: zero-byte-file-in-doc-directory usr/share/doc/fmit/NEWS.gz
JU> W: fmit: zero-byte-file-in-doc-directory usr/share/doc/fmit/README

Right, I've written a quick man page and deleted the empty files from
debian/docs.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> I've noticed the following lintian warnings, and they sound like
JU> legitimate ones; care to fix?
JU> W: fmit: binary-without-manpage fmit
JU> W: fmit: zero-byte-file-in-doc-directory usr/share/doc/fmit/NEWS.gz
JU> W: fmit: zero-byte-file-in-doc-directory usr/share/doc/fmit/README
Right, I've written a quick man page and deleted the empty files from
debian/docs.

I'm having problems in that this application doesn't seem to run
very reliably on my system (amd64).

closing the window it always exits with a free() errror

$ fmit
Free Music Instrument Tuner version 0.96.4 built at Jan 27 2006 13:46:35
Install directory '/usr'
CaptureThread: INFO: Built in transports
CaptureThread: INFO: JACK unavailable
CaptureThread: INFO: ALSA available
CaptureThread: INFO: Auto detecting a working transport ... using ALSA
CaptureThread: INFO: ALSA: try to set format to Signed 16 bit Little Endian success
CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
CaptureThread: INFO: ALSA: try to set sampling rate to 96000 failed
CaptureThread: INFO: ALSA: try to set sampling rate to 48000 success
CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
*** glibc detected *** free(): invalid next size (normal): 0x00000000008c1870 ***


and


[13:47:58]dancer64:trunk> fmit
Free Music Instrument Tuner version 0.96.4 built at Jan 27 2006 13:46:35
Install directory '/usr'
CaptureThread: INFO: Built in transports
CaptureThread: INFO: JACK unavailable
CaptureThread: INFO: ALSA available
CaptureThread: INFO: Auto detecting a working transport ... using ALSA
CaptureThread: INFO: ALSA: try to set format to Signed 16 bit Little Endian success
CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
CaptureThread: INFO: ALSA: try to set sampling rate to 96000 failed
CaptureThread: INFO: ALSA: try to set sampling rate to 48000 success
CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
-> finishes with a segmentation fault before Window appears.



regards,
junichi

[Junichi Uekawa]

Hi,

I'm trying to debug why 'fmit' is so unstable on my unstable amd64
box. Backtrace is looking suspiciously too qt to be application
specific. Anyone seen this kind of backtrace recently? At first sight
it looks like some allocator bug.


[21:53:00]dancer64:trunk> gdb /usr/bin/fmit
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/fmit
[Thread debugging using libthread_db enabled]
[New Thread 47596280818048 (LWP 16294)]
Free Music Instrument Tuner version 0.96.4 built at Jan 27 2006 21:51:28
Install directory '/usr'
Qt: gdb: -nograb added to command-line options.
Use the -dograb option to enforce grabbing.
CaptureThread: INFO: Built in transports
CaptureThread: INFO: JACK unavailable
CaptureThread: INFO: ALSA available
CaptureThread: INFO: Auto detecting a working transport ... using ALSA
CaptureThread: INFO: ALSA: try to set format to Signed 16 bit Little Endian success
CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
CaptureThread: INFO: ALSA: try to set sampling rate to 96000 failed
CaptureThread: INFO: ALSA: try to set sampling rate to 48000 success
[New Thread 1082132832 (LWP 16297)]
CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
*** glibc detected *** free(): invalid next size (normal): 0x00000000008c66b0 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread 47596280818048 (LWP 16294)]
0x00002b49de5fcdf0 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002b49de5fcdf0 in raise () from /lib/libc.so.6
#1 0x00002b49de5fe2a0 in abort () from /lib/libc.so.6
#2 0x00002b49de6329ae in __libc_message () from /lib/libc.so.6
#3 0x00002b49de63870b in _int_free () from /lib/libc.so.6
#4 0x00002b49de6389ee in free () from /lib/libc.so.6
#5 0x00002b49de629823 in fclose@@GLIBC_2.2.5 () from /lib/libc.so.6
#6 0x00002b49de6a9743 in __nss_database_lookup () from /lib/libc.so.6
#7 0x00002b49de6aaa37 in __nss_passwd_lookup () from /lib/libc.so.6
#8 0x00002b49de65f4cc in getpwuid_r@@GLIBC_2.2.5 () from /lib/libc.so.6
#9 0x00002b49de65ed3f in getpwuid () from /lib/libc.so.6
#10 0x00002b49dd9814b9 in QSessionManager::setRestartCommand () from /usr/lib/libqt-mt.so.3
#11 0x00002b49dd981990 in QSessionManager::setRestartCommand () from /usr/lib/libqt-mt.so.3
#12 0x00002b49dc8ba43a in _SmcProcessMessage () from /usr/X11R6/lib/libSM.so.6
#13 0x00002b49dc9c784d in IceProcessMessages () from /usr/X11R6/lib/libICE.so.6
#14 0x00002b49dd97bb9f in QSmSocketReceiver::socketActivated () from /usr/lib/libqt-mt.so.3
#15 0x00002b49dd97bddc in QSmSocketReceiver::qt_invoke () from /usr/lib/libqt-mt.so.3
#16 0x00002b49dda613a2 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#17 0x00002b49dda61d8b in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#18 0x00002b49dddca052 in QSocketNotifier::activated () from /usr/lib/libqt-mt.so.3
#19 0x00002b49dda805aa in QSocketNotifier::event () from /usr/lib/libqt-mt.so.3
#20 0x00002b49dd9fb000 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#21 0x00002b49dd9fb264 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#22 0x00002b49dd98bc6a in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3
#23 0x00002b49dd9ed711 in QEventLoop::activateSocketNotifiers () from /usr/lib/libqt-mt.so.3
#24 0x00002b49dd99f45f in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#25 0x00002b49dda12cde in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#26 0x00002b49dda12be7 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#27 0x00002b49dd9f9de6 in QApplication::exec () from /usr/lib/libqt-mt.so.3
#28 0x0000000000421435 in main ()


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,
JU> I'm trying to debug why 'fmit' is so unstable on my unstable amd64
JU> box. Backtrace is looking suspiciously too qt to be application
JU> specific. Anyone seen this kind of backtrace recently? At first sight
JU> it looks like some allocator bug.

Hi Junichi,

sorry for the little delay. I've tested the package both on i386 and
amd64: the with first fmit runs fine, while with the latter I get the
same misbehaviour you report.

However the package seems to be functional as well.

Cheers,

Free

JU> [21:53:00]dancer64:trunk> gdb /usr/bin/fmit
JU> GNU gdb 6.4-debian
JU> Copyright 2005 Free Software Foundation, Inc.
JU> GDB is free software, covered by the GNU General Public License, and you are
JU> welcome to change it and/or distribute copies of it under certain conditions.
JU> Type "show copying" to see the conditions.
JU> There is absolutely no warranty for GDB. Type "show warranty" for details.
JU> This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

JU> (gdb) run
JU> Starting program: /usr/bin/fmit
JU> [Thread debugging using libthread_db enabled]
JU> [New Thread 47596280818048 (LWP 16294)]
JU> Free Music Instrument Tuner version 0.96.4 built at Jan 27 2006 21:51:28
JU> Install directory '/usr'
JU> Qt: gdb: -nograb added to command-line options.
JU> Use the -dograb option to enforce grabbing.
JU> CaptureThread: INFO: Built in transports
JU> CaptureThread: INFO: JACK unavailable
JU> CaptureThread: INFO: ALSA available
JU> CaptureThread: INFO: Auto detecting a working transport ... using ALSA
JU> CaptureThread: INFO: ALSA: try to set format to Signed 16 bit Little Endian success
JU> CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
JU> CaptureThread: INFO: ALSA: try to set sampling rate to 96000 failed
JU> CaptureThread: INFO: ALSA: try to set sampling rate to 48000 success
JU> [New Thread 1082132832 (LWP 16297)]
JU> CaptureThread: WARNING: ALSA: cannot set channel count to one. channels will be mixed
JU> *** glibc detected *** free(): invalid next size (normal): 0x00000000008c66b0 ***

JU> Program received signal SIGABRT, Aborted.
JU> [Switching to Thread 47596280818048 (LWP 16294)]
JU> 0x00002b49de5fcdf0 in raise () from /lib/libc.so.6
JU> (gdb) bt
JU> #0 0x00002b49de5fcdf0 in raise () from /lib/libc.so.6
JU> #1 0x00002b49de5fe2a0 in abort () from /lib/libc.so.6
JU> #2 0x00002b49de6329ae in __libc_message () from /lib/libc.so.6
JU> #3 0x00002b49de63870b in _int_free () from /lib/libc.so.6
JU> #4 0x00002b49de6389ee in free () from /lib/libc.so.6
JU> #5 0x00002b49de629823 in fclose@@GLIBC_2.2.5 () from /lib/libc.so.6
JU> #6 0x00002b49de6a9743 in __nss_database_lookup () from /lib/libc.so.6
JU> #7 0x00002b49de6aaa37 in __nss_passwd_lookup () from /lib/libc.so.6
JU> #8 0x00002b49de65f4cc in getpwuid_r@@GLIBC_2.2.5 () from /lib/libc.so.6
JU> #9 0x00002b49de65ed3f in getpwuid () from /lib/libc.so.6
JU> #10 0x00002b49dd9814b9 in QSessionManager::setRestartCommand () from /usr/lib/libqt-mt.so.3
JU> #11 0x00002b49dd981990 in QSessionManager::setRestartCommand () from /usr/lib/libqt-mt.so.3
JU> #12 0x00002b49dc8ba43a in _SmcProcessMessage () from /usr/X11R6/lib/libSM.so.6
JU> #13 0x00002b49dc9c784d in IceProcessMessages () from /usr/X11R6/lib/libICE.so.6
JU> #14 0x00002b49dd97bb9f in QSmSocketReceiver::socketActivated () from /usr/lib/libqt-mt.so.3
JU> #15 0x00002b49dd97bddc in QSmSocketReceiver::qt_invoke () from /usr/lib/libqt-mt.so.3
JU> #16 0x00002b49dda613a2 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
JU> #17 0x00002b49dda61d8b in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
JU> #18 0x00002b49dddca052 in QSocketNotifier::activated () from /usr/lib/libqt-mt.so.3
JU> #19 0x00002b49dda805aa in QSocketNotifier::event () from /usr/lib/libqt-mt.so.3
JU> #20 0x00002b49dd9fb000 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
JU> #21 0x00002b49dd9fb264 in QApplication::notify () from /usr/lib/libqt-mt.so.3
JU> #22 0x00002b49dd98bc6a in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3
JU> #23 0x00002b49dd9ed711 in QEventLoop::activateSocketNotifiers () from /usr/lib/libqt-mt.so.3
JU> #24 0x00002b49dd99f45f in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
JU> #25 0x00002b49dda12cde in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
JU> #26 0x00002b49dda12be7 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
JU> #27 0x00002b49dd9f9de6 in QApplication::exec () from /usr/lib/libqt-mt.so.3
JU> #28 0x0000000000421435 in main ()


JU> regards,
JU> junichi

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> Hi,
JU> I'm trying to debug why 'fmit' is so unstable on my unstable amd64
JU> box. Backtrace is looking suspiciously too qt to be application
JU> specific. Anyone seen this kind of backtrace recently? At first sight
JU> it looks like some allocator bug.
Hi Junichi,
sorry for the little delay. I've tested the package both on i386 and
amd64: the with first fmit runs fine, while with the latter I get the
same misbehaviour you report.
However the package seems to be functional as well.

I'll try to track down the problem, which probably is on amd64 Qt
side, which I suspect might take some time.

For the timebeing, feel free to push me any other package.


regards,
junichi

[Free Ekanayaka]

Post by Free Ekanayaka
However the package seems to be functional as well.

JU> I'll try to track down the problem, which probably is on amd64 Qt
JU> side, which I suspect might take some time.

Yes, these are nasty issues..

JU> For the timebeing, feel free to push me any other package.

Thanks, I think the three kernel-patch packages at:

http://svn.debian.org/wsvn/demudi

are all worth to be uploaded.

Cheers,

Free

[Antonio]

On Tue, 31 Jan 2006 12:56:00 +0100
[cut]

Post by Free Ekanayaka
JU> For the timebeing, feel free to push me any other package.
http://svn.debian.org/wsvn/demudi
are all worth to be uploaded.

Excuse my ignorance, I'm just curious. Why we need a patch for the
realtime-lsm while there is jet a module in debian
(realtime-lsm-source) installable with module-assistant? Maybe I'm
misunderstanding something obvious in the SVN repository.

Feel free to ignore me :-)


Best Regards,

~ Antonio

[Free Ekanayaka]

|--==> Antonio writes:

A> Excuse my ignorance, I'm just curious. Why we need a patch for the
A> realtime-lsm while there is jet a module in debian
A> (realtime-lsm-source) installable with module-assistant? Maybe I'm
A> misunderstanding something obvious in the SVN repository.

A> Feel free to ignore me :-)

You're right, there's actually no compelling need, but I find more
comfortable to use the patch so that the realtime module gets shipped
directly with the kernel-image package and I don't have additional
module packages such as realtime-modules-x.y.z. Especially if you have
several flavours of the kernel and the relevant packages., this might
be a bit annoying.

Cheers,

Free

[Antonio]

On Tue, 31 Jan 2006 13:50:19 +0100

Post by Free Ekanayaka
A> Excuse my ignorance, I'm just curious. Why we need a patch for
A> the realtime-lsm while there is jet a module in debian
A> (realtime-lsm-source) installable with module-assistant? Maybe
A> I'm misunderstanding something obvious in the SVN repository.
A> Feel free to ignore me :-)
You're right, there's actually no compelling need, but I find more
comfortable to use the patch so that the realtime module gets shipped
directly with the kernel-image package and I don't have additional
module packages such as realtime-modules-x.y.z. Especially if you have
several flavours of the kernel and the relevant packages., this might
be a bit annoying.

OK, it perfectly reasonable to me. You have satisfied my curiosity ;-).


Best Regards,

~ Antonio

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> I'll try to track down the problem, which probably is on amd64 Qt
JU> side, which I suspect might take some time.
Yes, these are nasty issues..
JU> For the timebeing, feel free to push me any other package.
http://svn.debian.org/wsvn/demudi
are all worth to be uploaded.

I uploaded kernel-patch-bootsplash. I think it needs an accompanying
userland component; do you have a package for it?

For kernel-patch-realtime-lsm, wouldn't it be better to include it to
existing realtime-lsm module package? I could argue that they have
different development cycles, which would be agreeable, but it would
be nice if they are coordinated somewhere.

I'm cc'ing Guenter who's maintaining realtime-lsm module for Debian.

For kernel-patch-realtime-preempt, do you have an ITP for it?


regards,
junichi

[geiger]

Post by Junichi Uekawa
I uploaded kernel-patch-bootsplash. I think it needs an accompanying
userland component; do you have a package for it?
For kernel-patch-realtime-lsm, wouldn't it be better to include it to
existing realtime-lsm module package? I could argue that they have
different development cycles, which would be agreeable, but it would
be nice if they are coordinated somewhere.
I'm cc'ing Guenter who's maintaining realtime-lsm module for Debian.
For kernel-patch-realtime-preempt, do you have an ITP for it?

Hi,

I am going to drop realtime lsm sooner or later, as the newer Debian
kernels don't allow the module to be loaded any more because of
security issues. [1]
It is said that rtlimits is the future for setting realtime priority,
so it might be better to go in that direction.

Guenter

[1] http://lists.debian.org/debian-kernel/2005/10/msg00272.html

Post by Junichi Uekawa
regards,
junichi
--
_______________________________________________
Users mailing list
http://lists.agnula.org/cgi-bin/mailman/listinfo/users

[Free Ekanayaka]

Post by Junichi Uekawa
For kernel-patch-realtime-lsm, wouldn't it be better to include it to
existing realtime-lsm module package? I could argue that they have
different development cycles, which would be agreeable, but it would
be nice if they are coordinated somewhere.
I'm cc'ing Guenter who's maintaining realtime-lsm module for Debian.
For kernel-patch-realtime-preempt, do you have an ITP for it?

No, I'm opening it.

g> Hi,

g> I am going to drop realtime lsm sooner or later, as the newer Debian
g> kernels don't allow the module to be loaded any more because of
g> security issues. [1]

Well, I really hope that this can fix in the coming Debian kernels, I
found the realtime-source package really handy for people running
stock Debian kernels.

If not, than one would be forced to re-compile a kernel to use the
realtime module, and in this case a kernel patch is more comfortable
then a separate source tree.

In both cases I think it makes sense to merge the patch and the stand
alone module source in a single source package.

I can work on that if we all agree.

g> It is said that rtlimits is the future for setting realtime priority,
g> so it might be better to go in that direction.

I didn't try it yet, but I was told something like at the moment you
have to list the names of the applications that have privileges to run
real-time into a file, for every application, which is a bit annoying.

AFAIR you also need a tweaked pam package, I don't know if the Debian
one is suited (it wasn't, but this might have changed).

Can anybody confirm this? Or is there somebody successfully and
happily running with rtlimits?

Cheers,

Free

[Antonio]

On Wed, 01 Feb 2006 10:33:13 +0100
[cut]

Post by Free Ekanayaka
g> I am going to drop realtime lsm sooner or later, as the newer
g> Debian kernels don't allow the module to be loaded any more
g> because of security issues. [1]
Well, I really hope that this can fix in the coming Debian kernels, I
found the realtime-source package really handy for people running
stock Debian kernels.
If not, than one would be forced to re-compile a kernel to use the
realtime module, and in this case a kernel patch is more comfortable
then a separate source tree.
In both cases I think it makes sense to merge the patch and the stand
alone module source in a single source package.
I can work on that if we all agree.
g> It is said that rtlimits is the future for setting realtime
g> priority, so it might be better to go in that direction.
I didn't try it yet, but I was told something like at the moment you
have to list the names of the applications that have privileges to run
real-time into a file, for every application, which is a bit annoying.
AFAIR you also need a tweaked pam package, I don't know if the Debian
one is suited (it wasn't, but this might have changed).
Can anybody confirm this? Or is there somebody successfully and
happily running with rtlimits?

I haven't tried it neither. The realime-lsm approach have been too handy
to motivate me to try the new way. But...

Searching on the LAU archives I have found this link about realtime
kernel and PAM:

http://alsa.opensrc.org/index.php?page=RealtimeKernelAndPAM

Maybe you know it jet but can be interesting for someone exploring the
topic.

I'll try to use the .deb with the patched pam indicated in that link and
reports if it works.

If the switch to rtlimt is easy I'd like to see the switch in
demudi ASAP (and the easiest way would be to push it in debian). But I
know that the realtime-lsm (although insecure) is a really run in
approach, so rtlimit have to reach the same degree of reliability
before being adopted.

Best Regards,

~ Antonio

[Free Ekanayaka]

Hi Antonio,

|--==> Antonio writes:

A> I haven't tried it neither. The realime-lsm approach have been too handy
A> to motivate me to try the new way. But...

A> Searching on the LAU archives I have found this link about realtime
A> kernel and PAM:

A> http://alsa.opensrc.org/index.php?page=RealtimeKernelAndPAM

A> Maybe you know it jet but can be interesting for someone exploring the
A> topic.

A> I'll try to use the .deb with the patched pam indicated in that link and
A> reports if it works.

Ok, thanks a lot, let us know..

A> If the switch to rtlimt is easy I'd like to see the switch in
A> demudi ASAP (and the easiest way would be to push it in debian). But I
A> know that the realtime-lsm (although insecure) is a really run in
A> approach, so rtlimit have to reach the same degree of reliability
A> before being adopted.

Yes I agree, let's keep it for a while.

Cheers,

Free

[pw.marcus]

Post by Free Ekanayaka
Hi Antonio,
A> I haven't tried it neither. The realime-lsm approach have been too handy
A> to motivate me to try the new way. But...
A> Searching on the LAU archives I have found this link about realtime
A> http://alsa.opensrc.org/index.php?page=RealtimeKernelAndPAM
A> Maybe you know it jet but can be interesting for someone exploring the
A> topic.
A> I'll try to use the .deb with the patched pam indicated in that link and
A> reports if it works.
Ok, thanks a lot, let us know..
A> If the switch to rtlimt is easy I'd like to see the switch in
A> demudi ASAP (and the easiest way would be to push it in debian). But I
A> know that the realtime-lsm (although insecure) is a really run in
A> approach, so rtlimit have to reach the same degree of reliability
A> before being adopted.
Yes I agree, let's keep it for a while.
Cheers,
Free
_______________________________________________
Users mailing list
http://lists.agnula.org/cgi-bin/mailman/listinfo/users

Hy all,
did you see the wiki of hubuntu studio ?
they describe another way to setup realtime for new kernels.

http://ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAM


cheers.

[tim hall]

Post by pw.marcus
did you see the wiki of hubuntu studio ?
they describe another way to setup realtime for new kernels.
http://ubuntustudio.com/wiki/index.php/Breezy:Rlimits-Aware_PAM

Have you tried doing this? does it work with DeMuDi?

AFAIU patching PAM is the 'proper' way to go about granting realtime
privileges. realtime-lsm is (becoming) deprecated, although obviously, we're
still using it here. I get the impression that set_rtlimits is a bit of a
kludge (comparatively speaking) and worth avoiding.

Ubuntu 'Dapper' will probably release with an rtlimits patched PAM. It will
take longer to get the Debian PAM maintainers to accept the patch. If anyone
manages to get a DIY version working and can write up some kind of report for
DeMuDi, that might take the waiting out of wanting for some people. The
recommendation is to stick with realtime-lsm until a proper patched PAM
package can be provided.

[tim hall]

Post by tim hall
AFAIU patching PAM is the 'proper' way to go about granting realtime
privileges. realtime-lsm is (becoming) deprecated, although obviously,
we're still using it here. I get the impression that set_rtlimits is a bit
of a kludge (comparatively speaking) and worth avoiding.
Ubuntu 'Dapper' will probably release with an rtlimits patched PAM. It will
take longer to get the Debian PAM maintainers to accept the patch. If
anyone manages to get a DIY version working and can write up some kind of
report for DeMuDi, that might take the waiting out of wanting for some
people. The recommendation is to stick with realtime-lsm until a proper
patched PAM package can be provided.

I just thought I should make it clear that I'm summarising the discussion so
far in an effort to understand it myself and for anyone else who is finding
this a rather complex confusing subject. Please correct any errors.

[October]

Post by Junichi Uekawa
For kernel-patch-realtime-lsm, wouldn't it be better to include it to
existing realtime-lsm module package? I could argue that they have
different development cycles, which would be agreeable, but it would
be nice if they are coordinated somewhere.
I'm cc'ing Guenter who's maintaining realtime-lsm module for Debian.
For kernel-patch-realtime-preempt, do you have an ITP for it?

No, I'm opening it.

g> Hi,

g> I am going to drop realtime lsm sooner or later, as the newer Debian
g> kernels don't allow the module to be loaded any more because of
g> security issues. [1]

Well, I really hope that this can fix in the coming Debian kernels, I
found the realtime-source package really handy for people running
stock Debian kernels.

If not, than one would be forced to re-compile a kernel to use the
realtime module, and in this case a kernel patch is more comfortable
then a separate source tree.

In both cases I think it makes sense to merge the patch and the stand
alone module source in a single source package.

I can work on that if we all agree.

g> It is said that rtlimits is the future for setting realtime priority,
g> so it might be better to go in that direction.

I didn't try it yet, but I was told something like at the moment you
have to list the names of the applications that have privileges to run
real-time into a file, for every application, which is a bit annoying.

AFAIR you also need a tweaked pam package, I don't know if the Debian
one is suited (it wasn't, but this might have changed).

Can anybody confirm this? Or is there somebody successfully and
happily running with rtlimits?

Cheers,

Free

_______________________________________________
Users mailing list
***@lists.agnula.org
http://lists.agnula.org/cgi-bin/mailman/listinfo/users
Hello,

I've been experimenting with rtlimits with Ubuntu Dapper 6.04 ("Flight 3") without any further modificiations. The ubuntu team might have modified PAM to allow this to work but as rtlimits is not included or documented in ubuntu (AFAIK) I suspect they have not, or my successes might be due to the fact that I'm running "set_rlimits" to control rtlimits and this may be some sort of workaround. I first found out about rtlimits at this page: http://tapas.affenbande.org/?page_id=22

rtlimits is made easier to use through the use of a small app by Jonathan Woithe called "set_rlimits", the current version of which can be found here: http://www.physics.adelaide.edu.au/~jwoithe/

As it stands now rtlimits (with 'set_rlimits') requires a file listing realtime privs for both applications AND user/groups. You must also start these applications with a different string such as 'set_rlimits qjackctl' and apps started that way will not play nicely with other apps started without it (as example: xmms+jack plugin started without set_rtlimits and qjackctl started with it).

Realtime-lsm is convenient, apply it and forget it, and it's true, in it's current state using rtlimits is a bit more of a hassle, but it also seems to provide somewhat better performance (the Dapper kernels also have CONFIG_PREEMPT=y by default). While I haven't tested it thoroughly enough to have any concrete statistics or benchmarks I can usually rely on rtlimits (via 'set_rlimits') to allow lower latencies without xruns than running realtime-lsm, at least with the Dapper kernels.

I'm also thinking that for those that primiarly use fluxbox and the like for music studio will not have much trouble finding ways to easily incorporate 'set_rlimits' into a customized application menu. For KDE and Gnome and the like it will, of course, be a slightly bigger undertaking.

I've been documenting my experiments with Ubuntu Dapper and realtime methods at my blog: http://oktyabr.blogspot.com if anyone is interested.

Best,

Jon Hoskins


-----------------------------------------------------------------------
In a world without walls who needs gates or windows?

--unknown

---------------------------------
Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

[Junichi Uekawa]

Hi,

Post by geiger

Post by Junichi Uekawa
I uploaded kernel-patch-bootsplash. I think it needs an accompanying
userland component; do you have a package for it?
For kernel-patch-realtime-lsm, wouldn't it be better to include it to
existing realtime-lsm module package? I could argue that they have
different development cycles, which would be agreeable, but it would
be nice if they are coordinated somewhere.
I'm cc'ing Guenter who's maintaining realtime-lsm module for Debian.
For kernel-patch-realtime-preempt, do you have an ITP for it?

Hi,
I am going to drop realtime lsm sooner or later, as the newer Debian
kernels don't allow the module to be loaded any more because of
security issues. [1]
It is said that rtlimits is the future for setting realtime priority,
so it might be better to go in that direction.

For the timebeing, would it work if it is compiled-in? I will need to
evaluate if realtime-lsm kernel patch has a place in Debian.

It sounds to me the alternatives are still in their nascent stage that
is vaporware.


regards,
junichi

[Free Ekanayaka]

Post by geiger
Hi,
I am going to drop realtime lsm sooner or later, as the newer Debian
kernels don't allow the module to be loaded any more because of
security issues. [1]
It is said that rtlimits is the future for setting realtime priority,
so it might be better to go in that direction.

JU> For the timebeing, would it work if it is compiled-in? I will need to
JU> evaluate if realtime-lsm kernel patch has a place in Debian.

I don't think I fully understand what you mean here, please would you
elaborate?

JU> It sounds to me the alternatives are still in their nascent stage that
JU> is vaporware.

Rtlimits has been around for several month, and has been merged in the
upstream kernel tree. However its adoption in the Linux audio
community seems to be very slow, and for this reason I think that
having a kernel-patch and a module-source package for realtime-lsm
it's definitely worthy till rtlimits becomes the established choice.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka

Post by geiger
I am going to drop realtime lsm sooner or later, as the newer Debian
kernels don't allow the module to be loaded any more because of
security issues. [1]
It is said that rtlimits is the future for setting realtime priority,
so it might be better to go in that direction.

JU> For the timebeing, would it work if it is compiled-in? I will need to
JU> evaluate if realtime-lsm kernel patch has a place in Debian.
I don't think I fully understand what you mean here, please would you
elaborate?

I was trying to say:

1. realtime-lsm module no longer works with stock kernel
(presumably from some symbols not being exported?)

2. iff realtime-lsm patch compiled in to kernel works,
that should be kept.

3. realtime-lsm module may be removed from Debian, but the kernel
patch will enter Debian. This explanation will be required for
ftp-masters who will be wondering why two packages of the same
codebase are trying to enter Debian at the same time.

regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,

Post by Free Ekanayaka

Post by geiger
I am going to drop realtime lsm sooner or later, as the newer Debian
kernels don't allow the module to be loaded any more because of
security issues. [1]
It is said that rtlimits is the future for setting realtime priority,
so it might be better to go in that direction.

JU> For the timebeing, would it work if it is compiled-in? I will need to
JU> evaluate if realtime-lsm kernel patch has a place in Debian.

Post by Free Ekanayaka
I don't think I fully understand what you mean here, please would you
elaborate?

JU> I was trying to say:

JU> 1. realtime-lsm module no longer works with stock kernel
JU> (presumably from some symbols not being exported?)

Yes, it doesn't work because the capability security is compiled in
and not built as a module.

JU> 2. iff realtime-lsm patch compiled in to kernel works,
JU> that should be kept.

The works with the latest Debian kernels, it's sufficient to set the
appropriate config flags.

JU> 3. realtime-lsm module may be removed from Debian, but the kernel
JU> patch will enter Debian. This explanation will be required for
JU> ftp-masters who will be wondering why two packages of the same
JU> codebase are trying to enter Debian at the same time.

The best option for me would be to have the stock kernel to support a
modular capability again (actually I see no reason for not doing
that), *and* include the patch in the current realtime-lsm source
package (introducing a new binary package).

If not, we may want to convert the current realtime-lsm package and
make it sport only the patch.

In both cases rather than uploading a new package, I think it makes
more sense to adapt the existing one to the new situation.

Cheers,

Free

[geiger]

Hi,

Post by Junichi Uekawa
1. realtime-lsm module no longer works with stock kernel
(presumably from some symbols not being exported?)

No, its because the commoncap module is compiled into the kernel, which
defines fixed a security policy for the Debian kernel instead of beeing
able to change it with modules.

Post by Junichi Uekawa
2. iff realtime-lsm patch compiled in to kernel works,
that should be kept.

If you recompile the kernel anyhow, then you can configure it in a way
that the realtime-lsm module works. The kernel patch is in no way
better than the module, security wise its is worse. Pushing
the realtime kernel-patch into Debian, knowing that it will soon be
obsolete and knowing that a superior working solution (the realtime-lsm
module) already exists in Debian doesn't make sense.

Post by Junichi Uekawa
3. realtime-lsm module may be removed from Debian, but the kernel
patch will enter Debian. This explanation will be required for
ftp-masters who will be wondering why two packages of the same
codebase are trying to enter Debian at the same time.

I will remove the realtime-lsm module as soon as the pam package
gets updated. Using an up to date pam version to grant realtime
permissions is adding two lines in /etc/security/limits.conf.
This is the working solution accepted by the kernel developers.

You can still upload kernel-patch-realtime, but in my eyes it is
pretty useless, time would be better spent by lobbying for a newer
version of pam or for getting this bug fixed:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326555

Guenter

Post by Junichi Uekawa
regards,
junichi
--
_______________________________________________
Users mailing list
http://lists.agnula.org/cgi-bin/mailman/listinfo/users

[Free Ekanayaka]

|--==> geiger writes:

g> If you recompile the kernel anyhow, then you can configure it in a way
g> that the realtime-lsm module works. The kernel patch is in no way
g> better than the module, security wise its is worse. Pushing
g> the realtime kernel-patch into Debian, knowing that it will soon be
g> obsolete and knowing that a superior working solution (the realtime-lsm
g> module) already exists in Debian doesn't make sense.

AFAICT the patch is *equivalent* to the module, they are actually the
same thing: you get a new security kernel module. The only difference
is that with the patch you don't have to build an external Debian
package, the module will be included in the kernel-image or
linux-image package.

Post by Junichi Uekawa
3. realtime-lsm module may be removed from Debian, but the kernel
patch will enter Debian. This explanation will be required for
ftp-masters who will be wondering why two packages of the same
codebase are trying to enter Debian at the same time.

g> I will remove the realtime-lsm module as soon as the pam package
g> gets updated. Using an up to date pam version to grant realtime
g> permissions is adding two lines in /etc/security/limits.conf.
g> This is the working solution accepted by the kernel developers.

I didn't test rtlimits yet. Are two lines enough? I was told that you
have to add an entry for each application needing realtime privileges,
but this information might be wrong.

g> You can still upload kernel-patch-realtime, but in my eyes it is
g> pretty useless, time would be better spent by lobbying for a newer
g> version of pam or for getting this bug fixed:

g> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326555

If the rtlimits approach is, from the user's point of view, equivalent
to realtime-lsm, I do agree. But I'm wondering how long will it take
to close the bug above, as till know it seems to have been completely
ignored. Anyhow if we decide to not upload the patch, it's fine for
me, and I'll join the lobbying team :)

Cheers,

Free

[geiger]

Post by Free Ekanayaka
AFAICT the patch is *equivalent* to the module, they are actually the
same thing: you get a new security kernel module. The only difference
is that with the patch you don't have to build an external Debian
package, the module will be included in the kernel-image or
linux-image package.

right, I thought it was compiled in, which would be different.

Post by Free Ekanayaka

Post by Junichi Uekawa
3. realtime-lsm module may be removed from Debian, but the kernel
patch will enter Debian. This explanation will be required for
ftp-masters who will be wondering why two packages of the same
codebase are trying to enter Debian at the same time.

g> I will remove the realtime-lsm module as soon as the pam package
g> gets updated. Using an up to date pam version to grant realtime
g> permissions is adding two lines in /etc/security/limits.conf.
g> This is the working solution accepted by the kernel developers.
I didn't test rtlimits yet. Are two lines enough? I was told that you
have to add an entry for each application needing realtime privileges,
but this information might be wrong.

You are talking about the workaround, called set_rtlimits. This is only
needed on distributions without pam.

Here is what I have in my /etc/security/limits.conf:

@audio - rt_priority 100
@audio - nice -10
@audio - memlock 4000000

which grants the permissions to users in the "audio" group, using an
updated pam_limits module.

Post by Free Ekanayaka
g> You can still upload kernel-patch-realtime, but in my eyes it is
g> pretty useless, time would be better spent by lobbying for a newer
g> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D326555
If the rtlimits approach is, from the user's point of view, equivalent
to realtime-lsm, I do agree. But I'm wondering how long will it take
to close the bug above, as till know it seems to have been completely
ignored. Anyhow if we decide to not upload the patch, it's fine for
me, and I'll join the lobbying team :)

Thats good to hear. As pam is a modular system, one could also write
(copy) the pam_limits module, rename it to pam_rtlimits and package
that. Of course it is preferable to have a working pam module in the
pam package, but the other approach would also be possible, if the
pam maintainers do not want to update pam for whatever reason.

G=FCnter

Post by Free Ekanayaka
Cheers,
Free
_______________________________________________
Users mailing list
http://lists.agnula.org/cgi-bin/mailman/listinfo/users

[Junichi Uekawa]

Hi,

Post by geiger
I will remove the realtime-lsm module as soon as the pam package
gets updated. Using an up to date pam version to grant realtime
permissions is adding two lines in /etc/security/limits.conf.
This is the working solution accepted by the kernel developers.
You can still upload kernel-patch-realtime, but in my eyes it is
pretty useless, time would be better spent by lobbying for a newer
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326555

Thanks for putting me into context. Considering the background, it
would seem silly to include the kernel patch to Debian archive at this
point.

The remaining point to address would be integration of demudi kernel
to Debian, which probably depends on this patch.


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,

Post by geiger
I will remove the realtime-lsm module as soon as the pam package
gets updated. Using an up to date pam version to grant realtime
permissions is adding two lines in /etc/security/limits.conf.
This is the working solution accepted by the kernel developers.
You can still upload kernel-patch-realtime, but in my eyes it is
pretty useless, time would be better spent by lobbying for a newer
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326555

JU> Thanks for putting me into context. Considering the background, it
JU> would seem silly to include the kernel patch to Debian archive at this
JU> point.

JU> The remaining point to address would be integration of demudi kernel
JU> to Debian, which probably depends on this patch.

Yes it currently does indeed, but if we switch to rtlimits than the
patch is no longer needed of course.

Anyway I'm really not sure about the idea of uploading the kernel to
Debian. There are many kernel patch packages in Debian, but currently
no other kernel image packages than the official ones. If we upload
the DeMuDi kernel, then why other people should not upload their
kernels too?

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
JU> Thanks for putting me into context. Considering the background, it
JU> would seem silly to include the kernel patch to Debian archive at this
JU> point.
JU> The remaining point to address would be integration of demudi kernel
JU> to Debian, which probably depends on this patch.
Yes it currently does indeed, but if we switch to rtlimits than the
patch is no longer needed of course.
Anyway I'm really not sure about the idea of uploading the kernel to
Debian. There are many kernel patch packages in Debian, but currently
no other kernel image packages than the official ones. If we upload
the DeMuDi kernel, then why other people should not upload their
kernels too?

I'm ambivalent on this point.

However, to build the CDD, it would be nice if the CDD can be built
completely from sources available within Debian.


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> I'm ambivalent on this point.

JU> However, to build the CDD, it would be nice if the CDD can be built
JU> completely from sources available within Debian.

This is also true. My concern is that if every CDD (existent or
prospective) wants to have its kernel in Debian, that could be a
problem.

Anyway this not that urgent, let's keep working on all other packages
in the meantime.

Cheers,

Free

[tim hall]

Post by Junichi Uekawa

Anyway I'm really not sure about  the idea of  uploading the kernel to
Debian. There are many kernel patch packages  in Debian, but currently
no other  kernel image packages than  the official ones.  If we upload
the DeMuDi kernel,  then why   other people  should not  upload  their
kernels too?

Someone has to be the first. No?

Post by Junichi Uekawa
I'm ambivalent on this point.
However, to build the CDD, it would be nice if the CDD can be built
completely from sources available within Debian.

As a humble user, I only vaguely understand all this business with realtime
capabilities and the security issues involved. Apart from the dependencies,
what would be the reasons for not including all DeMuDi packages including the
kernel in Debian? Surely it would be appropriate for a Custom Debian
Distribution to be installable from pure Debian sources.

just my 0.02

[Junichi Uekawa]

Hi,

Post by tim hall

Post by Junichi Uekawa
I'm ambivalent on this point.
However, to build the CDD, it would be nice if the CDD can be built
completely from sources available within Debian.

As a humble user, I only vaguely understand all this business with realtime
capabilities and the security issues involved. Apart from the dependencies,
what would be the reasons for not including all DeMuDi packages including the
kernel in Debian? Surely it would be appropriate for a Custom Debian
Distribution to be installable from pure Debian sources.

Including low-latency kernel will require quite a bit of overhead
including making sure it builds and works on most architectures. That
will mean I (or somebody else) will have to hack kernel on ppc and
amd64 architectures which are less tested for -RT trees.

I think it's something to discuss with debian-kernel guys.

What would be the implication of including kernel images of
low-latency kernel variation into Debian?

I'm Cc'ing debian-kernel for input.


regards,
junichi

[Sven Luther]

Post by Junichi Uekawa
Hi,

Who made the comments you are replying to and where were those posts made ?

Post by Junichi Uekawa

Post by tim hall

Post by Junichi Uekawa
I'm ambivalent on this point.
However, to build the CDD, it would be nice if the CDD can be built
completely from sources available within Debian.

As a humble user, I only vaguely understand all this business with realtime
capabilities and the security issues involved. Apart from the dependencies,
what would be the reasons for not including all DeMuDi packages including the
kernel in Debian? Surely it would be appropriate for a Custom Debian
Distribution to be installable from pure Debian sources.

Including low-latency kernel will require quite a bit of overhead
including making sure it builds and works on most architectures. That
will mean I (or somebody else) will have to hack kernel on ppc and
amd64 architectures which are less tested for -RT trees.

Well, i think the -RT tree on powerpc is used in the embedded world, but i
guess the problem may not be in the core kernel, but in a whole bunch of
drivers never built on those embedded targets.

Post by Junichi Uekawa
I think it's something to discuss with debian-kernel guys.
What would be the implication of including kernel images of
low-latency kernel variation into Debian?

I guess we could make it a subarch for now, so duplicate all flavours (or
those that make sense) with the -RT stuff enabled, as has already been done
for vserver. I now have a fast build machine (still in its box though), so i
don't worry about the duplication of kernels this means.

But i disagree on enabling those things on the main kernels yet, as they are
cause of random breakage still, but i would defer to others with more
knowledge.

Friendly,

Sven Luther

[Sven Luther]

Ok, after a small chat with a part of the kernel team, it appears that :

1) preempt (and other -RT features ?) are still too broken for enabling in the
main flavours.

2) the kernel team has not the ressources to track these preempt flavours, and
the (load of) additional bug report they will create.

3) it is now relatively easy to add preempt flavours, and from a technically
packaging infrastructure this would be a no brainer.

So, given this, if the support of these -RT kernels will be handled only by
the existing kernel team, then there is no way we want to add those, but on
the other hand, if there is additional ressources added to the kernel team to
handle those flavours and the accompanying bug reports, we would be willing to
add a few select flavours. I guess those would be the i386, amd64, and powerpc
(at least the powerpcs and powerpc64 flavours, do we really need to care about
32bit smp systems for this ?).

Friendly,

Sven Luther

[Junichi Uekawa]

Hi,

Post by Sven Luther
1) preempt (and other -RT features ?) are still too broken for enabling in the
main flavours.

Yes, I think it's too large a patch to include unconditionally into
mainline Debian kernel.

Post by Sven Luther
2) the kernel team has not the ressources to track these preempt flavours, and
the (load of) additional bug report they will create.
3) it is now relatively easy to add preempt flavours, and from a technically
packaging infrastructure this would be a no brainer.
So, given this, if the support of these -RT kernels will be handled only by
the existing kernel team, then there is no way we want to add those, but on
the other hand, if there is additional ressources added to the kernel team to
handle those flavours and the accompanying bug reports, we would be willing to
add a few select flavours. I guess those would be the i386, amd64, and powerpc
(at least the powerpcs and powerpc64 flavours, do we really need to care about
32bit smp systems for this ?).

I think we'll have a lot of problems with support SMP userland let
alone kernel for -RT, so that will probably need some work.

My current plan is to maintain the -RT variant with guys working with
debian-multimedia, so yes, this means new members joining in to
debian-kernel team to look after bugs specific to -RT variants.

regards,
junichi

[Sven Luther]

Post by Junichi Uekawa
Hi,

Post by Sven Luther
1) preempt (and other -RT features ?) are still too broken for enabling in the
main flavours.

Yes, I think it's too large a patch to include unconditionally into
mainline Debian kernel.

A patch ? What exactly are you speaking about ? I was talking about preempt,
which is now part of the mainline 2.6 tree, but not enabled by default.

Post by Junichi Uekawa

Post by Sven Luther
2) the kernel team has not the ressources to track these preempt flavours, and
the (load of) additional bug report they will create.
3) it is now relatively easy to add preempt flavours, and from a technically
packaging infrastructure this would be a no brainer.
So, given this, if the support of these -RT kernels will be handled only by
the existing kernel team, then there is no way we want to add those, but on
the other hand, if there is additional ressources added to the kernel team to
handle those flavours and the accompanying bug reports, we would be willing to
add a few select flavours. I guess those would be the i386, amd64, and powerpc
(at least the powerpcs and powerpc64 flavours, do we really need to care about
32bit smp systems for this ?).

I think we'll have a lot of problems with support SMP userland let
alone kernel for -RT, so that will probably need some work.

Euh, powerpc64 is smp by default, and if i remember well, preempt is actually
easier to deal with in a smp-friendly case.

Post by Junichi Uekawa
My current plan is to maintain the -RT variant with guys working with
debian-multimedia, so yes, this means new members joining in to
debian-kernel team to look after bugs specific to -RT variants.

Cool, then.

Friendly,

Sven Luther

[Junichi Uekawa]

Hi,

Post by Sven Luther

Post by Junichi Uekawa

Post by Sven Luther
1) preempt (and other -RT features ?) are still too broken for enabling in the
main flavours.

Yes, I think it's too large a patch to include unconditionally into
mainline Debian kernel.

A patch ? What exactly are you speaking about ? I was talking about preempt,
which is now part of the mainline 2.6 tree, but not enabled by default.

-RT patch is a large tree that Ingo is maintaining outside of kernel tree.

http://people.redhat.com/mingo/realtime-preempt/

preempt is included in the mainline kernel bit by bit, but doesn't
include all the required stuff.

I would have thought that it's in a state where it is already almost
always safe to enable preempt on architectures that remotely support
functional SMP...

Post by Sven Luther

Post by Junichi Uekawa
I think we'll have a lot of problems with support SMP userland let
alone kernel for -RT, so that will probably need some work.

Euh, powerpc64 is smp by default, and if i remember well, preempt is actually
easier to deal with in a smp-friendly case.

In my impression, jack (jack-audio-connection-kit) support for SMP is
not prime-time yet, which means most of audio-apps won't function
correctly in SMP situation. Binding all apps to one CPU might work
better, but that will need some more investigation and development.

regards,
junichi

[Sven Luther]

Post by Junichi Uekawa
Hi,

Post by Sven Luther

Post by Junichi Uekawa

Post by Sven Luther
1) preempt (and other -RT features ?) are still too broken for enabling in the
main flavours.

Yes, I think it's too large a patch to include unconditionally into
mainline Debian kernel.

A patch ? What exactly are you speaking about ? I was talking about preempt,
which is now part of the mainline 2.6 tree, but not enabled by default.

-RT patch is a large tree that Ingo is maintaining outside of kernel tree.

Ah, ok, so this would be the same situation as the xen or vserver patches,
which we already have subarchitectures (maybe not very well named).

I would counsel you to get a svn checkout of the linux-2.6 package, and
investigate into what Bastian did for vserver, and do something similar.

I can add you to the alioth project if you want to commit stuff, altough i
think that maybe the exp branch (targeted as 2.6.16) would be best placed to
do this kind of work.

Friendly,

Sven Luther

[Junichi Uekawa]

Hi,

Post by Sven Luther

Post by Junichi Uekawa

Post by Sven Luther

Post by Junichi Uekawa

Post by Sven Luther
1) preempt (and other -RT features ?) are still too broken for enabling in the
main flavours.

Yes, I think it's too large a patch to include unconditionally into
mainline Debian kernel.

A patch ? What exactly are you speaking about ? I was talking about preempt,
which is now part of the mainline 2.6 tree, but not enabled by default.

-RT patch is a large tree that Ingo is maintaining outside of kernel tree.

Ah, ok, so this would be the same situation as the xen or vserver patches,
which we already have subarchitectures (maybe not very well named).
I would counsel you to get a svn checkout of the linux-2.6 package, and
investigate into what Bastian did for vserver, and do something similar.
I can add you to the alioth project if you want to commit stuff, altough i
think that maybe the exp branch (targeted as 2.6.16) would be best placed to
do this kind of work.

Thanks for the guidance.

This is part of 'merge DeMuDi back to Debian' project; I'll be squashing other parts first.
We haven't even got lowlatency patches into Debian yet.

Free, (or anyone else doing DeMuDi kernel) would you like to see how
we could integrate into official kernel-image building tree ?

regards,
junichi

[Free Ekanayaka]

Post by Sven Luther
Ah, ok, so this would be the same situation as the xen or vserver patches,
which we already have subarchitectures (maybe not very well named).
I would counsel you to get a svn checkout of the linux-2.6 package, and
investigate into what Bastian did for vserver, and do something similar.
I can add you to the alioth project if you want to commit stuff, altough i
think that maybe the exp branch (targeted as 2.6.16) would be best placed to
do this kind of work.

JU> Thanks for the guidance.

JU> This is part of 'merge DeMuDi back to Debian' project; I'll be squashing other parts first.
JU> We haven't even got lowlatency patches into Debian yet.

JU> Free, (or anyone else doing DeMuDi kernel) would you like to see how
JU> we could integrate into official kernel-image building tree ?

I few weeks ago I've checked out the source of the linux-2.6 package
(BTW, nice work!) from the SVN repository, and adding more flavors is
just a matter of modifying the debian/arch configuration files. It
should not be difficult at all.

I'm just wondering if we should include these low-latency kernel
packages in the current linux-2.6 source package, or rather clone a
new one in some smart way. If other Custom Debian Distributions need
their own kernels, including everything in one single source package
could turn to be a not very scalable approach.

Cheers,

Free

[Bastian Blank]

Post by Free Ekanayaka
If other Custom Debian Distributions need
their own kernels, including everything in one single source package
could turn to be a not very scalable approach.

It is quite easy to modify the linux-2.6 sources to use the linux-tree-X
and build an own set of images.

Bastian

[Sven Luther]

Post by Bastian Blank

Post by Free Ekanayaka
If other Custom Debian Distributions need
their own kernels, including everything in one single source package
could turn to be a not very scalable approach.

It is quite easy to modify the linux-2.6 sources to use the linux-tree-X
and build an own set of images.

I don't think this is the way we want to go though, a bit for the same reason
you used a subarch for the vserver patches.

Friendly,

Sven Luther

[Sven Luther]

Post by Free Ekanayaka

Post by Sven Luther
Ah, ok, so this would be the same situation as the xen or vserver patches,
which we already have subarchitectures (maybe not very well named).
I would counsel you to get a svn checkout of the linux-2.6 package, and
investigate into what Bastian did for vserver, and do something similar.
I can add you to the alioth project if you want to commit stuff, altough i
think that maybe the exp branch (targeted as 2.6.16) would be best placed to
do this kind of work.

JU> Thanks for the guidance.
JU> This is part of 'merge DeMuDi back to Debian' project; I'll be squashing other parts first.
JU> We haven't even got lowlatency patches into Debian yet.
JU> Free, (or anyone else doing DeMuDi kernel) would you like to see how
JU> we could integrate into official kernel-image building tree ?
I few weeks ago I've checked out the source of the linux-2.6 package
(BTW, nice work!) from the SVN repository, and adding more flavors is
just a matter of modifying the debian/arch configuration files. It
should not be difficult at all.
I'm just wondering if we should include these low-latency kernel
packages in the current linux-2.6 source package, or rather clone a
new one in some smart way. If other Custom Debian Distributions need
their own kernels, including everything in one single source package
could turn to be a not very scalable approach.

As said, you should build not a new flavour, but a new subarch, in a way
similar of the work bastian blank did with the vserver patches. I am not sure
this infrastructure is fully functional, but it is the way these things should
be handled.

Oh, and it would be very nice if we didn't get spam back from the agnula
mailing list handler or whatever, saying we are not subscribed and such, or
maybe we should drop the agnula mailing list, as it seems clear they don't
really want to speak with us :/

Friendly,

Sven Luther

[Bastian Blank]

Post by Sven Luther
As said, you should build not a new flavour, but a new subarch, in a way
similar of the work bastian blank did with the vserver patches. I am not sure
this infrastructure is fully functional, but it is the way these things should
be handled.

The problem is that it does not scale. I don't think we can build more
than around 10 image for i386.

Bastian

[Sven Luther]

Post by Bastian Blank

Post by Sven Luther
As said, you should build not a new flavour, but a new subarch, in a way
similar of the work bastian blank did with the vserver patches. I am not sure
this infrastructure is fully functional, but it is the way these things should
be handled.

The problem is that it does not scale. I don't think we can build more
than around 10 image for i386.

Why not ? i386 is supposed to have nice and fast hardware, so this should not
be a major problem.

Also, we don't need to rebuild all flavours, only a few ones for select arches
and flavours.

Friendly,

Sven Luther

[Free Ekanayaka]

|--==> Sven Luther writes:

SL> As said, you should build not a new flavour, but a new subarch, in a way
SL> similar of the work bastian blank did with the vserver patches. I am not sure
SL> this infrastructure is fully functional, but it is the way these things should
SL> be handled.

Ok, I got the idea. If the kernel team decides it's doable I can start
work on that myself, this should address the lack of human resources
issue raised on an other post.

SL> Oh, and it would be very nice if we didn't get spam back from the agnula
SL> mailing list handler or whatever, saying we are not subscribed and such, or
SL> maybe we should drop the agnula mailing list, as it seems clear they don't
SL> really want to speak with us :/

Very sorry for that. I've set "Send mail to poster when their posting
is held for approval?" to "No", hope that's enough.

Cheers,

Free

[Sven Luther]

Post by Free Ekanayaka
SL> As said, you should build not a new flavour, but a new subarch, in a way
SL> similar of the work bastian blank did with the vserver patches. I am not sure
SL> this infrastructure is fully functional, but it is the way these things should
SL> be handled.
Ok, I got the idea. If the kernel team decides it's doable I can start
work on that myself, this should address the lack of human resources
issue raised on an other post.

Well, the lack of human ressources will show of over the months upto the
release, and the years that this code base is active, so we need more than a
momentarily commitment :)

Post by Free Ekanayaka
SL> Oh, and it would be very nice if we didn't get spam back from the agnula
SL> mailing list handler or whatever, saying we are not subscribed and such, or
SL> maybe we should drop the agnula mailing list, as it seems clear they don't
SL> really want to speak with us :/
Very sorry for that. I've set "Send mail to poster when their posting
is held for approval?" to "No", hope that's enough.

Thanks.

Friendly,

Sven Luther

[Free Ekanayaka]

|--==> Sven Luther writes:

SL> Well, the lack of human ressources will show of over the months upto the
SL> release, and the years that this code base is active, so we need more than a
SL> momentarily commitment :)

Well, I believe that myself plus some other good boys from the AGNULA
community or debian-multimedia team can drive these new set of kernel
packages at least until the Etch gets released. Beyond that is
difficult to speak, because I'm not sure about the future of Ingo's
realtime-preempt patch.

Cheers,

Free

[Sven Luther]

Post by Free Ekanayaka
SL> Well, the lack of human ressources will show of over the months upto the
SL> release, and the years that this code base is active, so we need more than a
SL> momentarily commitment :)
Well, I believe that myself plus some other good boys from the AGNULA
community or debian-multimedia team can drive these new set of kernel
packages at least until the Etch gets released. Beyond that is
difficult to speak, because I'm not sure about the future of Ingo's
realtime-preempt patch.

Beyond is easy, since the kernel in a stable release will not change, so you
have just to handle security updates related to the -RT patches.

Friendly,

Sven Luther

[tim hall]

Post by Sven Luther
Oh, and it would be very nice if we didn't get spam back from the agnula
mailing list handler or whatever, saying we are not subscribed and such, or
maybe we should drop the agnula mailing list, as it seems clear they don't
really want to speak with us :/

I am following this discussion on the AGNULA list. I am not commenting because
most of this discussion is way over my head, but it is very useful to keep
tabs on it. I'd prefer it if most of this discussion could be kept in the
open.

[Free Ekanayaka]

Post by Sven Luther
Oh, and it would be very nice if we didn't get spam back from the agnula
mailing list handler or whatever, saying we are not subscribed and such, or
maybe we should drop the agnula mailing list, as it seems clear they don't
really want to speak with us :/

th> I am following this discussion on the AGNULA list. I am not commenting because
th> most of this discussion is way over my head, but it is very useful to keep
th> tabs on it. I'd prefer it if most of this discussion could be kept in the
th> open.

The discussion has now moved to the debian-kernel list, which is the
most appropriate place, as all DDs dealing with kernel packaging are
subscribed there.

Probably such development issue should be tracked at:

http://wiki.debian.org/DebianMultimedia

and we should place a link to the above document in the demudi web
site too.

Cheers,

Free

[tim hall]

Post by Free Ekanayaka

Post by Sven Luther
Oh, and it would be very nice if we didn't get spam back from the
agnula mailing list handler or whatever, saying we are not subscribed
and such, or maybe we should drop the agnula mailing list, as it seems
clear they don't really want to speak with us :/

th> I am following this discussion on the AGNULA list. I am not
commenting because th> most of this discussion is way over my head, but it
is very useful to keep th> tabs on it. I'd prefer it if most of this
discussion could be kept in the th> open.
The discussion has now moved to the debian-kernel list, which is the
most appropriate place, as all DDs dealing with kernel packaging are
subscribed there.
http://wiki.debian.org/DebianMultimedia
and we should place a link to the above document in the demudi web
site too.

OK. np.

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka

Post by Sven Luther
Oh, and it would be very nice if we didn't get spam back from the agnula
mailing list handler or whatever, saying we are not subscribed and such, or
maybe we should drop the agnula mailing list, as it seems clear they don't
really want to speak with us :/

th> I am following this discussion on the AGNULA list. I am not commenting because
th> most of this discussion is way over my head, but it is very useful to keep
th> tabs on it. I'd prefer it if most of this discussion could be kept in the
th> open.
The discussion has now moved to the debian-kernel list, which is the
most appropriate place, as all DDs dealing with kernel packaging are
subscribed there.
http://wiki.debian.org/DebianMultimedia
and we should place a link to the above document in the demudi web
site too.

I almost forgot about this, and it's been a month. What's the current
status? Are we looking into building a package anytime soon?


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> I almost forgot about this, and it's been a month. What's the current
JU> status? Are we looking into building a package anytime soon?

I couldn't find the mentioned branch for vserver, which was suggested
to use as template, I've asked on debian-kernel to be pointed to it,
but no reply :/ At the moment I'm too busy and don't have time to push
on, but I'll have more spare time from mid April.. I'm already a bit
familiar with the code of the linux-2.6 Debian source package, and it
shouldn't be an hard task, but I really lack time ATM.

Cheers,

Free

[tim hall]

Post by Sven Luther
Who made the comments you are replying to and where were those posts made ?

Yep, that last post was difficult to follow.

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> I uploaded kernel-patch-bootsplash. I think it needs an accompanying
JU> userland component; do you have a package for it?

Great!

There's an unofficial package here:

http://mentors.debian.net/debian/pool/main/b/bootsplash/

but it needs some tweaking, I'll work on it and let you know.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Junichi Uekawa
I'm trying to debug why 'fmit' is so unstable on my unstable amd64
box. Backtrace is looking suspiciously too qt to be application
specific. Anyone seen this kind of backtrace recently? At first sight
it looks like some allocator bug.

I've tried to find out if this application works under ibook, and it
was equally unusable. I guess this isn't a powerpc problem.




regards,
junichi

[jazzride]

Post by Free Ekanayaka
JU> Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

Hi free
I notice Agnula's project has no more public funds, so sad...
What can we expect for the future: end of Agnula ?

Don't know what to do now.
Come back to win + Samplitude, APODIO 33... :-(

regards....


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0606-2, 07/02/2006
Analyse le : 09/02/2006 16:53:20
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[robin]

Post by jazzride

Post by Free Ekanayaka
JU> Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one

(see

Post by Free Ekanayaka
#280876, the ITP is from Emiliano Grilli but I'll maintain the

package

Post by Free Ekanayaka
myself).

Hi free
I notice Agnula's project has no more public funds, so sad...
What can we expect for the future: end of Agnula ?
Don't know what to do now.
Come back to win + Samplitude, APODIO 33... :-(
regards....
---

Agnula Demudi is alive and well. Work continues but obviously with some
changes.

robin

[.]

Post by robin

Post by jazzride
Don't know what to do now.
Come back to win + Samplitude, APODIO 33... :-(
regards....
---

Agnula Demudi is alive and well. Work continues but obviously with some
changes.
robin

Hello everybody, i'm a Demudi user since the woody based one...

I know some people who want to make something for Ubuntu so that the audio
packages are ready and so on.

I am not sure what they will actually do, but may be there could be an
interest to gather everybody under the debian community then makes the source
packages recompilable for both target (debian etch and ubuntu).

My observation is that Demudi is somehow in disfortune with the slow release
cycle of debian (almost 2 years). I see that 1.3.0rc1 is already based on
Etch and i remember how to was impossible for the previous team to use the
unstable branch close of the release of the Sarge. They went for a unstable
snapshot for a short while !

Instead the ubuntu core is on a 6month cycle, and you can expect that it won't
change during this period.

Well, i don't use Ubuntu and don't intend to for now. But may there is an
opportunity to attract a new public (user+dev). Because the pure Debian
branch is great for its diversity but not a great joy for a final "product",
and the Demudi project aim is somehow to be that (installable CD ready to
run).

Cheers,

L.

[.]

Re, this link could be of some interest:

http://ubuntustudio.com/wiki/index.php/Welcome%2C_Musicians%21

Cheers,

L.

[jazzride]

Post by robin
Agnula Demudi is alive and well. Work continues but obviously with some
changes.
robin

It's ok :)

Do you think I could install

1° Debian Sarge "classic" on my computer
2° Agnula 1.3.0 beta ? (i could change kernel etc )

... maybe it's stupid, don't know....

regards.


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0606-3, 09/02/2006
Analyse le : 10/02/2006 10:01:19
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[robin]

Post by jazzride

Post by robin
Agnula Demudi is alive and well. Work continues but obviously with
some changes.
robin

It's ok :)
Do you think I could install
1° Debian Sarge "classic" on my computer
2° Agnula 1.3.0 beta ? (i could change kernel etc )
... maybe it's stupid, don't know....
regards.
---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0606-3, 09/02/2006
Analyse le : 10/02/2006 10:01:19
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com
_______________________________________________

If you mean Sarge plus Demudi packages, installing via synaptic, it
should work. The other way being Sarge upgraded to Demudi, via
demudi-upgrade script.

As to whether to do that it depends what you are trying to achieve.

robin

[tim hall]

Post by jazzride
Do you think I could install
1° Debian Sarge "classic" on my computer
2° Agnula 1.3.0 beta ? (i could change kernel etc )
... maybe it's stupid, don't know....

I would guess that the dependencies of 1.3.0 will force you to install
packages from etch in order to get it working. Let us know. As usual, you get
to keep all the pieces. ;)

[Jorge Salgueiro]

Post by tim hall

Post by jazzride
Do you think I could install
1° Debian Sarge "classic" on my computer
2° Agnula 1.3.0 beta ? (i could change kernel etc )
... maybe it's stupid, don't know....

I would guess that the dependencies of 1.3.0 will force you to install
packages from etch in order to get it working. Let us know. As usual, you get
to keep all the pieces. ;)
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
_______________________________________________
Users mailing list
http://lists.agnula.org/cgi-bin/mailman/listinfo/users

do not install any kde package from sarge kde


.... $$%·# ??!!!!

[The Other]

Post by jazzride
Do you think I could install
1° Debian Sarge "classic" on my computer
2° Agnula 1.3.0 beta ? (i could change kernel etc )
... maybe it's stupid, don't know....

Hello Jazzride,

It's not stupid. I'm doing it right now as I wait patiently for the
DeMuDi repositories to resync.

Debian Sarge is installed on 1 partition.
DeMuDi 1.3.0 is installed on a 2nd partition.
GRUB is the boot loader/manager

(I also have 2 partitions of WindowsNT (1 for the OS, 1 for data) set
up, and 1 Linux data partition.)

You have to reboot to change Operating System, but the flexibility is
worth it.

For instance, the fstab for Sarge and DeMuDi can read/write anything on
each other, the linux data partition, and anything on the Windows NT
partitions (by using VFAT for WindowsNT, not NTFS). WindowsNT can only
read it's 2 partitions. So if I need to transfer files between
WindowsNT and Sarge or DeMuDi, I have to put the files on the WindowsNT
data partition.

Best Regards,
Stephen.

[jazzride]

Post by Antonio
Best Regards,
Stephen.
---

thanks :)


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0606-4, 10/02/2006
Analyse le : 11/02/2006 23:39:24
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[tim hall]

Post by The Other

Post by jazzride
Do you think I could install
1° Debian Sarge "classic" on my computer
2° Agnula 1.3.0 beta ? (i could change kernel etc )
... maybe it's stupid, don't know....

Hello Jazzride,
It's not stupid. I'm doing it right now as I wait patiently for the
DeMuDi repositories to resync.
Debian Sarge is installed on 1 partition.
DeMuDi 1.3.0 is installed on a 2nd partition.
GRUB is the boot loader/manager
(I also have 2 partitions of WindowsNT (1 for the OS, 1 for data) set
up, and 1 Linux data partition.)
You have to reboot to change Operating System, but the flexibility is
worth it.
For instance, the fstab for Sarge and DeMuDi can read/write anything on
each other, the linux data partition, and anything on the Windows NT
partitions (by using VFAT for WindowsNT, not NTFS). WindowsNT can only
read it's 2 partitions. So if I need to transfer files between
WindowsNT and Sarge or DeMuDi, I have to put the files on the WindowsNT
data partition.

Thanks Stephen, I now realise I completely misunderstood jazzride's question.
Oops!

[jazzride]

Post by tim hall
Thanks Stephen, I now realise I completely misunderstood jazzride's question.
Oops!

no no :)

I 'm thinking about these 2 solutions

1° Agnula on HDA + Sarge on HDB ( 2OS)
2° or Install Sarge + "upgrade" to Agnula (1 OS)

Don't know what could be the best solution for me :)

Regards

thanks Stephen and Tim :)


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0606-4, 10/02/2006
Analyse le : 12/02/2006 11:18:49
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[The Other]

Post by jazzride
I 'm thinking about these 2 solutions
1° Agnula on HDA + Sarge on HDB ( 2OS)
2° or Install Sarge + "upgrade" to Agnula (1 OS)
Don't know what could be the best solution for me :)

Debian Sarge upgraded to DeMuDi 1.2.1 is okay and works.

Debian Sarge upgraded to DeMuDi 1.3.0 is not easy, and there is a
problem with the 1.3.0 repositories which are not (currently) sync'd
with the Debian repositories.

Which means, when you're trying to add packages that didn't come on the
DeMuDi 1.3.0 CD, you may run in to unresolvable dependicies and can't
install the new package.

To get around this problem, I suggest you consider your solution 1 above.

I also find using solution 1 above is a good way to give you the best of
all worlds. By maintaining 3 separate partitions, it allows you to have
a rock-stable distribution OS on 1 partition, and a more
state-of-the-art distribution OS on a 2nd partition. Partition 2 is a
safe place to test and work out any problems with the newer
kernel/distribution OS. Then I use a 3rd partition as a data/backup
partition. You can save partition 2 config files and settings on
partition 3 while you do a reinstall of the partition 2 OS. This helps
you to bring back the OS and software on partition 2 very quickly.

When you finally get partition 2 OS rock-stable, start using partition 1
as your new state-of-the-art distribution and repeat the process. You
can now grow your new software in a safe environment. (If something
goes wrong, you can always reboot into the partition 1 OS and regain
access to the Internet, Email, etc., to get the help you need to fix the
break in the OS on partition 2, or vice versa if partition 2 was stable
and partition 1 was state-of-the-art.) I hope I explained that well.

Stephen.

[jazzride]

Post by The Other

Post by jazzride
I 'm thinking about these 2 solutions
1° Agnula on HDA + Sarge on HDB ( 2OS)
2° or Install Sarge + "upgrade" to Agnula (1 OS)
Don't know what could be the best solution for me :)

Debian Sarge upgraded to DeMuDi 1.2.1 is okay and works.
Debian Sarge upgraded to DeMuDi 1.3.0 is not easy, and there is a
problem with the 1.3.0 repositories which are not (currently) sync'd
with the Debian repositories.
Which means, when you're trying to add packages that didn't come on the
DeMuDi 1.3.0 CD, you may run in to unresolvable dependicies and can't
install the new package.
To get around this problem, I suggest you consider your solution 1 above.
I also find using solution 1 above is a good way to give you the best of
all worlds. By maintaining 3 separate partitions, it allows you to have
a rock-stable distribution OS on 1 partition, and a more
state-of-the-art distribution OS on a 2nd partition. Partition 2 is a
safe place to test and work out any problems with the newer
kernel/distribution OS. Then I use a 3rd partition as a data/backup
partition. You can save partition 2 config files and settings on
partition 3 while you do a reinstall of the partition 2 OS. This helps
you to bring back the OS and software on partition 2 very quickly.
When you finally get partition 2 OS rock-stable, start using partition 1
as your new state-of-the-art distribution and repeat the process. You
can now grow your new software in a safe environment. (If something
goes wrong, you can always reboot into the partition 1 OS and regain
access to the Internet, Email, etc., to get the help you need to fix the
break in the OS on partition 2, or vice versa if partition 2 was stable
and partition 1 was state-of-the-art.) I hope I explained that well.
Stephen.
---
Antivirus avast! : message Entrant sain.
Base de donnees virale (VPS) : 0608-0, 20/02/2006
Analyse le : 22/02/2006 00:13:10
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

thanks :)
Pascal


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0608-0, 20/02/2006
Analyse le : 22/02/2006 00:13:20
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[jazzride]

Post by jazzride

Post by The Other

Post by jazzride
I 'm thinking about these 2 solutions
1° Agnula on HDA + Sarge on HDB ( 2OS)
2° or Install Sarge + "upgrade" to Agnula (1 OS)
Don't know what could be the best solution for me :)

Debian Sarge upgraded to DeMuDi 1.2.1 is okay and works.
Debian Sarge upgraded to DeMuDi 1.3.0 is not easy, and there is a
problem with the 1.3.0 repositories which are not (currently) sync'd
with the Debian repositories.
Which means, when you're trying to add packages that didn't come on
the DeMuDi 1.3.0 CD, you may run in to unresolvable dependicies and
can't install the new package.
To get around this problem, I suggest you consider your solution 1 above.
I also find using solution 1 above is a good way to give you the best
of all worlds. By maintaining 3 separate partitions, it allows you to
have a rock-stable distribution OS on 1 partition, and a more
state-of-the-art distribution OS on a 2nd partition. Partition 2 is a
safe place to test and work out any problems with the newer
kernel/distribution OS. Then I use a 3rd partition as a data/backup
partition. You can save partition 2 config files and settings on
partition 3 while you do a reinstall of the partition 2 OS. This
helps you to bring back the OS and software on partition 2 very quickly.
When you finally get partition 2 OS rock-stable, start using partition
1 as your new state-of-the-art distribution and repeat the process.
You can now grow your new software in a safe environment. (If
something goes wrong, you can always reboot into the partition 1 OS
and regain access to the Internet, Email, etc., to get the help you
need to fix the break in the OS on partition 2, or vice versa if
partition 2 was stable and partition 1 was state-of-the-art.) I hope
I explained that well.
Stephen.
---
Antivirus avast! : message Entrant sain.
Base de donnees virale (VPS) : 0608-0, 20/02/2006
Analyse le : 22/02/2006 00:13:10
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

thanks :)
Pascal
---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0608-0, 20/02/2006
Analyse le : 22/02/2006 00:13:20
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com
---
Antivirus avast! : message Entrant sain.
Base de donnees virale (VPS) : 0608-0, 20/02/2006
Analyse le : 22/02/2006 15:27:16
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

and...
what do you think about this idea:

1- A MEPIS + agnula 1.3.0 kernel+patch +jack etc? do you think this
could work ?
regards :)


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0608-0, 20/02/2006
Analyse le : 22/02/2006 15:28:10
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[jazzride]

and...
what do you think about this idea:

a MEPIS + agnula 1.3.0 kernel+patch +jack etc? do you think this could
work ?
regards :)


sorry for the long message :-(

[juto aviten]

HI Jazzride,
why come back to APODIO is bad??
I use this distro and it works as fire!
I used agnula since 3 years too as Dynebolic and the three distro have
their own avantages, I made 3 partitions for each... I always feel
strange about some strange relation of concurrence between the community
as debian - fedora - mandriva and others independant distro... I don't
talk only for you but for many people that have this kind of attitude...
APODIO have no funding, same for Dynebolic and both do a great job...
Agnula is a great job and the question is does Agnula need funding to
continue to rocks? if yes that's pity if not I am really happy to use it
again and again with apodio & dynebolic!!!
please don't compare Apodio to win/samplitude... sound really bad for me...

cheers


juto

Post by jazzride
I notice Agnula's project has no more public funds, so sad...
What can we expect for the future: end of Agnula ?
Don't know what to do now.
Come back to win + Samplitude, APODIO 33... :-(

[jazzride]

Post by juto aviten
HI Jazzride,
why come back to APODIO is bad??
I use this distro and it works as fire!
I used agnula since 3 years too as Dynebolic and the three distro have
their own avantages, I made 3 partitions for each... I always feel
strange about some strange relation of concurrence between the community
as debian - fedora - mandriva and others independant distro... I don't
talk only for you but for many people that have this kind of attitude...
APODIO have no funding, same for Dynebolic and both do a great job...
Agnula is a great job and the question is does Agnula need funding to
continue to rocks? if yes that's pity if not I am really happy to use it
again and again with apodio & dynebolic!!!
please don't compare Apodio to win/samplitude... sound really bad for me...
cheers
juto

Hi
1° you can't say samplitude is a bad soft that's wrong. Samplitude is a
great soft, really professional. Ardour and Samplitude are great softs,
Linux works better than Win specially for Music + computer you're right.

2° Mandriva = a society even if in France we have a mandriva community,
Debian = a community, it' s not the same. And if you try to install
APODIO on an old computer (< 256 Mo RAM), you can't. But i think you can
install Demudi.

3° Debian (Debian + Demudi + Knoppix + Mepis) works better on my
computer than Mandriva...


---
Antivirus avast! : message Sortant sain.
Base de donnees virale (VPS) : 0606-4, 10/02/2006
Analyse le : 12/02/2006 13:12:56
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

[juto aviten]

Post by jazzride
1° you can't say samplitude is a bad soft that's wrong. Samplitude is
a great soft, really professional. Ardour and Samplitude are great
softs, Linux works better than Win specially for Music + computer
you're right.

yes but samplitude is proprietary.. I don't see the point to say linux
it's better or not, it's simply another world, something else... in
debate with window$ or mac$ users you will have always someone to tell
you that their softwares they use is better than any under linux... my
position is different, I want to show them that they could work on free
software as they did before on proprietary OS and more they could join
communities and have access to more liberty in the way they use computers.

Post by jazzride
2° Mandriva = a society even if in France we have a mandriva
community, Debian = a community, it' s not the same. And if you try to
install APODIO on an old computer (< 256 Mo RAM), you can't. But i
think you can install Demudi.

The community is not only in France but in different countries in their
own languages, also I don't want to defend the mandriva society, that's
not my goal at all, I am first a Debian ideology defender and I use it
but when I do workshop or exchange with the "other" world I can't
propose Debian to straight or long time window$ users and everyone here
knows why... my goal is not to show one distro but many (from fedora to
Debian, Mandriva, Gentoo...etc) and show the diversity in the world of
gnu/linux, not showing one aspect of the forces ;-)
Also as an Apodio user, I don't see the point to use apodio on old
machine, apodio is for multimedia and you could use big stuff as Ardour,
Cinelerra, puredata, blender...etc many of this application can't be
used on old machines (for big recording studio or film production...) if
I want to used old machine I will used damn small linux or debian that's
rights or put more ram in my old machines... all these are
complementary... Why always try to separate what is complementary?
One other issue about Apodio is that it is made by people that don't
earn one penny on it : just for freedom, to encourage freedom... it's
not a company...

Post by jazzride
3° Debian (Debian + Demudi + Knoppix + Mepis) works better on my
computer than Mandriva...

that's for sure a better reason... I use computer for different matters
and also with a lot of newbies in this field and I always install 2/3
linux distro and the most used by people are apodio or knoppix...
Debian/demudi have to be configured a lot by terminal (which I like
sometimes more than graphics) but I can't say the same for newbies whom
are afraid of command lines...
I do a lot of installation and use different machines for it, and apodio
is really fast to install and straight to use without too much config...
I regret that Demudi could not work as apodio in these ways... because
when you install knoppix or demudi livecd (not so updated...) you don't
install a straight debian/demudi and after the install it's a big
mess... for my work with groups of people/installation...etc it's not
easy to do, so debian/demudi is really for my personnal use but not for
all my works with installation and people (newbies)...

one of my wish is to have a livecd agnula that you could use as live
and/or install on your harddisk and synchronize with debian package...
it's missing...


friendly


juto

[robin]

Post by juto aviten

Post by jazzride
1° you can't say samplitude is a bad soft that's wrong. Samplitude is
a great soft, really professional. Ardour and Samplitude are great
softs, Linux works better than Win specially for Music + computer
you're right.

yes but samplitude is proprietary.. I don't see the point to say linux
it's better or not, it's simply another world, something else... in
debate with window$ or mac$ users you will have always someone to tell
you that their softwares they use is better than any under linux... my
position is different, I want to show them that they could work on free
software as they did before on proprietary OS and more they could join
communities and have access to more liberty in the way they use computers.

Post by jazzride
2° Mandriva = a society even if in France we have a mandriva
community, Debian = a community, it' s not the same. And if you try to
install APODIO on an old computer (< 256 Mo RAM), you can't. But i
think you can install Demudi.

The community is not only in France but in different countries in their
own languages, also I don't want to defend the mandriva society, that's
not my goal at all, I am first a Debian ideology defender and I use it
but when I do workshop or exchange with the "other" world I can't
propose Debian to straight or long time window$ users and everyone here
knows why... my goal is not to show one distro but many (from fedora to
Debian, Mandriva, Gentoo...etc) and show the diversity in the world of
gnu/linux, not showing one aspect of the forces ;-)
Also as an Apodio user, I don't see the point to use apodio on old
machine, apodio is for multimedia and you could use big stuff as Ardour,
Cinelerra, puredata, blender...etc many of this application can't be
used on old machines (for big recording studio or film production...) if
I want to used old machine I will used damn small linux or debian that's
rights or put more ram in my old machines... all these are
complementary... Why always try to separate what is complementary?
One other issue about Apodio is that it is made by people that don't
earn one penny on it : just for freedom, to encourage freedom... it's
not a company...

Post by jazzride
3° Debian (Debian + Demudi + Knoppix + Mepis) works better on my
computer than Mandriva...

that's for sure a better reason... I use computer for different matters
and also with a lot of newbies in this field and I always install 2/3
linux distro and the most used by people are apodio or knoppix...
Debian/demudi have to be configured a lot by terminal (which I like
sometimes more than graphics) but I can't say the same for newbies whom
are afraid of command lines...
I do a lot of installation and use different machines for it, and apodio
is really fast to install and straight to use without too much config...
I regret that Demudi could not work as apodio in these ways... because
when you install knoppix or demudi livecd (not so updated...) you don't
install a straight debian/demudi and after the install it's a big
mess... for my work with groups of people/installation...etc it's not
easy to do, so debian/demudi is really for my personnal use but not for
all my works with installation and people (newbies)...
one of my wish is to have a livecd agnula that you could use as live
and/or install on your harddisk and synchronize with debian package...
it's missing...
friendly
juto

Most of Demudi system administration (as required for desktop use) are
handled by GUI applications. Synaptic, Gnome System Tools spring to mind.

The live cd is for demonstration purposes at present.

robin

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).
and get the sources.

Hmm... there is already new upstream version released.




regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).
and get the sources.

JU> Hmm... there is already new upstream version released.

Funny, it has been published few hours after my commit! I'm going to
update the source.

Cheers,

Free

[Junichi Uekawa]

Hi,

Post by Free Ekanayaka

Post by Free Ekanayaka
I handle, both in Debian or not. Packages not in Debian will have "-0"
as a revision number.

JU> If you are ready, you can ping me, and I'll try and sponsor whatever
JU> needs sponsoring.
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

The following is the change I would at least like:

Index: debian/pbuilder-test/001_testldd
===================================================================
--- debian/pbuilder-test/001_testldd (\uffff\uffff\uffff\uffff\u543e\u0441\uffff 0)
+++ debian/pbuilder-test/001_testldd (\uffff\uffff\uffff\uffff\u543e\u0441\uffff 0)
@@ -0,0 +1,3 @@
+#!/bin/bash
+ldd /usr/bin/fmit
+
Index: debian/changelog
===================================================================
--- debian/changelog (\uffff\uffff\uffff\uffff\u543e\u0441\uffff 618)
+++ debian/changelog (\u7bcf\u7f50\uffff\uffff\u6f5f\uffff\uffff)
@@ -1,13 +1,17 @@
fmit (0.96.2-1) unstable; urgency=low

+ [Free Ekanayaka]
* New upstream release
* First upload to Debian (Closes: #280876)
* Added fftw3-dev build dependency
* Set the --with-Qt3-dir to /usr/share/qt3
* Fixed old fsf address
* Updated Standard-Versions
+
+ [Junichi Uekawa]
+ * add pbuilder-test/ directory for minimal testing.

- -- Free Ekanayaka <***@agnula.org> Wed, 25 Jan 2006 12:09:47 +0100
+ -- Junichi Uekawa <***@debian.org> Thu, 26 Jan 2006 08:29:15 +0900

fmit (0.9.9-0.demudi1) unstable; urgency=low


But commit fails, I think we need a group-writable directory there.

svn: Can't create directory '/svn/demudi/db/transactions/622-1.txn': Permission denied


regards,
junichi

[Free Ekanayaka]

|--==> Junichi Uekawa writes:

JU> Hi,

Post by Free Ekanayaka

Post by Free Ekanayaka
I handle, both in Debian or not. Packages not in Debian will have "-0"
as a revision number.

JU> If you are ready, you can ping me, and I'll try and sponsor whatever
JU> needs sponsoring.

Post by Free Ekanayaka
Yes, I've prepared the first package to upload, it's a new one (see
#280876, the ITP is from Emiliano Grilli but I'll maintain the package
myself).

JU> The following is the change I would at least like:

JU> Index: debian/pbuilder-test/001_testldd
JU> ===================================================================
JU> --- debian/pbuilder-test/001_testldd (\uffff\uffff\uffff\uffff\u543e\u0441\uffff 0)
JU> +++ debian/pbuilder-test/001_testldd (\uffff\uffff\uffff\uffff\u543e\u0441\uffff 0)
JU> @@ -0,0 +1,3 @@
JU> +#!/bin/bash
JU> +ldd /usr/bin/fmit
JU> +
JU> Index: debian/changelog
JU> ===================================================================
JU> --- debian/changelog (\uffff\uffff\uffff\uffff\u543e\u0441\uffff 618)
JU> +++ debian/changelog (\u7bcf\u7f50\uffff\uffff\u6f5f\uffff\uffff)
JU> @@ -1,13 +1,17 @@
JU> fmit (0.96.2-1) unstable; urgency=low

JU> + [Free Ekanayaka]
JU> * New upstream release
JU> * First upload to Debian (Closes: #280876)
JU> * Added fftw3-dev build dependency
JU> * Set the --with-Qt3-dir to /usr/share/qt3
JU> * Fixed old fsf address
JU> * Updated Standard-Versions
JU> +
JU> + [Junichi Uekawa]
JU> + * add pbuilder-test/ directory for minimal testing.

JU> - -- Free Ekanayaka <***@agnula.org> Wed, 25 Jan 2006 12:09:47 +0100
JU> + -- Junichi Uekawa <***@debian.org> Thu, 26 Jan 2006 08:29:15 +0900

JU> fmit (0.9.9-0.demudi1) unstable; urgency=low

Nice, I didn't now about the pbuilder tests :) I'm appling the changes.

JU> But commit fails, I think we need a group-writable directory there.

JU> svn: Can't create directory '/svn/demudi/db/transactions/622-1.txn': Permission denied

Mmh:

free-***@costa:/svn/demudi$ ls -la /svn/demudi/db/transactions/
total 8
drwxrwsr-x 2 root demudi 4096 Jan 25 21:55 .
drwxrwsr-x 5 root demudi 4096 Jan 25 21:55 ..

maybe you are not in the demudi group for some reason?

Cheers,

Free