Re: Please grant freeze exception for RoarAudio related packages
reflum, On Sat, 2012-07-28 at 15:58 +0200, Julien Cristau wrote: > On Sat, Jul 28, 2012 at 15:51:15 +0200, Philipp Schafft wrote: > > > Will you be so kind and allow uploads for aroarfw, ckport, muroard and > > vclt-tools? > > > You don't need our permission for uploading, so go ahead. Oh. I'm sorry, it was maybe my bad wording: I kindly asks if you will allow them to go into testing/wheezy. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Please grant freeze exception for RoarAudio related packages
flum, Small background: I left the Debian project because of the CELT/Opus/mumble/RoarAudio case. Because of Ron's bad timing all of this falls into the freeze interval. I'm very sorry about this. Some time ago I asked if I should file O or RM bugs for my packages. You told me that you have no preference. In meantime some people got interested and took over my packages. I'm thankful to those people. All non RoarAudio packages as well as src:roarplaylistd have successfully moved to the new maintainsers already. The following packages still contain my name in Mainatiner or Uploader field in current unstable/testing version. I opend tickets about the removal of my name as I was told. * aroarfw (#682876) * ckport (#682886) * muroar (#682885, see below) * muroard (#682877) * roaraudio (#682878, see below) * vclt-tools (#682879) I kindly ask you to allow uploads with my name removed so this is done before the release. This is very important to me as I consider my good name damaged with the current situation in Debian (this is why I leave the project). Patrick Matthäi is willing to do uploads as soon as you allow it. Also as of my knowlage he will do his own requests for some security(?) updates soon for muroar and roaraudio so they are just listed here for completness. Will you be so kind and allow uploads for aroarfw, ckport, muroard and vclt-tools? Thank you for your work and time. PS: please keep Patrick Matthäi in CC as he is not on the list. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: Futur status of RoarAudio packages
reflum, On Wed, 2012-06-27 at 10:30 +0100, Neil McGovern wrote: > On Tue, Jun 26, 2012 at 09:06:12PM +0200, Philipp Schafft wrote: > > > I have no preference either way, as long as the package complies with > > > release > > > policy, then it may be included in the release. > > > > > Your answer isn't very helpfull to me as it is. So I have some > > questions: > > I think that's because we don't have a strong opinion either way. > > > * If I want to go for keeping it in debian (what I of cause prefer > > and will do my very best) will you 0) allow uploads while in > > freeze for packages readding RoarAudio support, 1) will you > > suggest to do this to people who removed it because of Ron? > > (Statement on this ML will of cause do, just something I can > > link). > > We will allow *unblocks* which comply with the wheezy freeze policy[0], > on a case by case basis. I am NOT going to issue a statement other than > that, and will NOT direct maintainers in this matter. > > Your argument with Ron is something that (as I indicated earlier) needs > to be solved in unstable, or via the tech-ctte if you're not getting > anywhere (I believe that there was a similar bug already open, but I > could be wrong). > > For avoidence of doubt, the release team are not getting involved in > your argument. Please take it elsewhere. > > > * If your answer to one of the above question is 'no' I don't feel > > like spending time on this will help anybody. I suggested to > > file RMs but you asked to keep them. Shell I just orphan them > > instead? > > > > Please do not get me wrong: I'm very interested in maintainig the > > packages and ensure they are in a good shape, but I'm not interested in > > maintaining perfectly useless packages. > > > > If the packages are actually useless, I would suggest RM bugs are the > best way to go. Thank you for your infos. I will file RM requests (also for unstable as I don't see how the situation could be resolved this way) as soon (still wating for the-me to be back from holidays). Also will leave the Debian project as I'm not willing to waste more time in this and earn the frustation of my users. They are already complaining upstream. > [0] Note: this is in DRAFT form until we freeze... > http://release.debian.org/wheezy/freeze_policy.html -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: Futur status of RoarAudio packages
reflum, On Fri, 2012-06-15 at 11:23 +0100, Neil McGovern wrote: > Hi, > > On Thu, Jun 14, 2012 at 10:41:42PM +0200, Philipp Schafft wrote: > > I want to ask if the release team decided anything in this direction. > > Does the release team want a useful version of the package in wheezy? > > [...] > It's quite hard to get the "Release Team" to make an official statement in the > timescales you're probably after, especially as you're not looking for any > discussion. > > However, as Release Manager (and I have discussed this with the other RM), my > official statement is: > > I have no preference either way, as long as the package complies with > release > policy, then it may be included in the release. > > I would suggest that solving this issue in unstable, one way or the > other may be a better area to concentrate your efforts. Thank you for your reply. I'm still in my busy sommer weeks so this response is a bit late. Will have free time again by mid of next week (including time for debian). Your answer isn't very helpfull to me as it is. So I have some questions: * If I want to go for keeping it in debian (what I of cause prefer and will do my very best) will you 0) allow uploads while in freeze for packages readding RoarAudio support, 1) will you suggest to do this to people who removed it because of Ron? (Statement on this ML will of cause do, just something I can link). * If your answer to one of the above question is 'no' I don't feel like spending time on this will help anybody. I suggested to file RMs but you asked to keep them. Shell I just orphan them instead? Please do not get me wrong: I'm very interested in maintainig the packages and ensure they are in a good shape, but I'm not interested in maintaining perfectly useless packages. Solving this in unstable isn't an option for me because this makes renders it unuseable for people using stable (people are already asking me what happend). I thank you for your answer. PS: Please keep Patrick in Cc. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Futur status of RoarAudio packages
Dear Release Team, Ron Lee recently asked every maintainer with a package depending on one of our libs to remove them. It is not clear to me why he did that. All problem with our packages relevant for the new stable release have been solved (I have only one wishlist ticket left on my QA page). By removing all those dependencies he made the package perfectly useless as it is backend software and is hardly useful without other software using it. In #675610 he writes "We'd like to have nothing depending on roar for wheezy, [...]". I'm not sure about the "We" in this statement. Also I have not got any info from him or the Release Team or any other Team as far as I know. (If I missed something please kindly point me to that). I want to ask if the release team decided anything in this direction. Does the release team want a useful version of the package in wheezy? I'm not interested in any discussion but a plain offical statement from the Release Team. If the Release Team is interested in keeping the package there needs to be a discussion (diffrent thread or on IRC, ...) how to solve the situation. If there is no interested in a useful version I will submit RM bugs against all related packages I'm the maintainer for and suggest Patrick Matthäi (the maintainer of the other half of releated packages) to do the same. I don't see a point in keeping a package made useless and wasting more of our and others time. Thanks you for your help and infos. PS: Please keep Patrick Matthäi in CC as he is no longer subscribed to this list. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#674634: transition: celt
reflum, On Mon, 2012-05-28 at 22:37 +0930, Ron wrote: > On Mon, May 28, 2012 at 11:54:14AM +0200, Philipp Schafft wrote: > > On Sat, 2012-05-26 at 18:38 +0930, Ron wrote: > > > Roar, I've been assured by its upstream is likewise easy to just disable > > > support for it - but the-me is giving me some pointless pushback ... > > > I'll NMU that too when the time comes if really needed if this is the > > > final blocker. > > > > > > There shouldn't be any other flow on from this so far as I know. > > > Some of these packages may enable Opus support instead, but doing so > > > is not a prerequisite for us being able to remove celt for Wheezy. > > > > Removal of CELT will remove a major feature of src:roaraudio. It will > > not render the package useless just will make it useless for a group of > > users. > > For anyone actually relying on CELT for this (of which I highly suspect > there is very near to nobody), the current situation is already worse > than useless. The version we have is not bitstream compatible with the > version of celt that other distros are shipping, so the result of trying > to use it will be something approximating speaker and ear popping noise. This is completly untrue. You yourself told me you taked to other distros to sync this. Also the Protocol requires sending a magic including the bitstream version. If the versions don't match it will fail and tell the user about the problem. Please stop telling everybody's software would be broken. > This also would have happened to them if I'd actually uploaded a newer > version of CELT as several people had requested ... No. See above. > If nobody has reported that to you, then it confirms my suspicion that > nobody will actually notice it going away. No. See above. > Since you don't even mention celt support in any of your descriptions > of roar, either in the package or on your website, this seems more like > a minor easter egg than a "major feature" anyway. Package descriptions are no docs. If I list all features I will have documentation. See your own package descriptions... > > This is why we like to make this a smooth transition with getting > > in Opus first, then removing CELT. Also note that this transition needs > > users using it to change config so it should not be a single upload > > removing one and adding the other. > > If you can't sanely handle this in one upload, then your package is > broken for your users anyway. There is no arbitrary period of time > on the order of "1 month" as you claimed earlier in which they will > all update to the first version before you upload the second. This has nothing to do with the package but with users. Users are nothing I can update via upload. > > The cirtical factor is time here. Ron Lee is a bit late with this > > transition in the release cycle. Had he given us about a month more we > > would have done all this already and everybody would be happy. > > Let's be very clear on this point. You have been asking me about this > for over a year now, and have been fully informed on everything that > was planned. So if anyone is "a bit late" getting their act together, > you'll need to discuss that with the man you see in the mirror. Let's make it *very* clear: Last time I asked you you said nothing about this nor pinged the package maintainer via an offical (like BTS) or inoffical (like pinging me on IRC) channel. > Yes, this is late in the cycle - but only from the perspective of the > release team. Everyone else, including you, has known this was coming, > and that things would happen fast after the IETF working group finally > concluded, as uncertain as the actual date for that had been. And > everyone else, except you, has been extremely cooperative and has got > their part of the work done already, efficiently and painlessly. See above. > A few days ago, you claimed this would take 4 months. Today you claim > a month. Without getting gnuplot out to fit this, on that projection > we should be down to my 15 minute estimate, by say, this Wednesday? I'm sorry if this was unclear: I was talking about the technical part here. The diffrence is because there is not only your schedule but also the one of other groups. The RoarAudio project has a defined release cycle to ensure quality. Depending on when you ping us (what you never did) changes take one or two months to go in if they are accepted. You can read about it here: https://bts.keep-cool.org/wiki/ReleaseCycle > I already sent you the one line patch that was needed. And I still have > the 12 minutes up my sleeve from doing that if you'd like me to upload it. >
Bug#674634: transition: celt
reflum, On Sat, 2012-05-26 at 18:38 +0930, Ron wrote: > Roar, I've been assured by its upstream is likewise easy to just disable > support for it - but the-me is giving me some pointless pushback ... > I'll NMU that too when the time comes if really needed if this is the > final blocker. > > There shouldn't be any other flow on from this so far as I know. > Some of these packages may enable Opus support instead, but doing so > is not a prerequisite for us being able to remove celt for Wheezy. Removal of CELT will remove a major feature of src:roaraudio. It will not render the package useless just will make it useless for a group of users. This is why we like to make this a smooth transition with getting in Opus first, then removing CELT. Also note that this transition needs users using it to change config so it should not be a single upload removing one and adding the other. The cirtical factor is time here. Ron Lee is a bit late with this transition in the release cycle. Had he given us about a month more we would have done all this already and everybody would be happy. I have discusses several possibile ways to get this solved with the-me (the maintainer). In fact both of us would *really* like to get this done. CELT always added some extra work both upstream and in maintaining packages because of the unfrozen bitstream. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#660785: transition: roaraudio
reflum,
On Sun, 2012-02-26 at 18:35 +0100, Cyril Brulebois wrote:
> Philipp Schafft (26/02/2012):
> > On Sat, 2012-02-25 at 20:17 +0100, Cyril Brulebois wrote:
> > > In case there's any issues with it, it can go away from testing, no rdeps.
> >
> > It's still a very much used software. I also noticed some people install
> > it from source. I would very much like to keep it. It's much better to
> > tell the people to just install the package and know it will work.
> >
> > The very few upstream releases are just because the software is very
> > stable and there are no much changes required.
> >
> > (PS: I'm one of upstream supporters and commit patches from time to
> > time)
>
> putting back my words in the “let's try and get ${a set of packages} to
> migrate together” context, it doesn't mean I want to get rid it
> entirely. It basically means a temporary removal from testing so that
> the transition can proceed. Once the package is fixed, it can get back
> in; and in case anything can be done by the release team to make that
> happen (which usually isn't the case), we are happy to do so.
Ah, ok. Thanks for your clarification.
--
Philipp.
(Rah of PH2)
signature.asc
Description: This is a digitally signed message part
Bug#660785: transition: roaraudio
reflum, On Sat, 2012-02-25 at 20:17 +0100, Cyril Brulebois wrote: > Patrick Matthäi (21/02/2012): > > * ices2: > > This is the only package which fails, upstream fix available, see #659827 > > In case there's any issues with it, it can go away from testing, no rdeps. It's still a very much used software. I also noticed some people install it from source. I would very much like to keep it. It's much better to tell the people to just install the package and know it will work. The very few upstream releases are just because the software is very stable and there are no much changes required. (PS: I'm one of upstream supporters and commit patches from time to time) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: Freeze exception: roaraudio, muroard, libao
reflum, On Mon, 2010-08-16 at 22:46 +0200, Mehdi Dogguy wrote: > On 08/16/2010 09:04 PM, Patrick Matthäi wrote: > > There are also no installations in Lenny which may break, just > > because this package is quite new in Debian at all, we were just not > > 100% ready at the time where Squeeze has been frozen. :( > > > > That's what I suspected. So, basically, the sources in the archive are > not ready and you want to push as much as possible changes from > upstream's trunk. IMO, "roaraudio" is not in a releasable state and > didn't get much testing… it's only less than one month old (in the > archive) and doesn't have any reverse dependency. Maybe it's worth > considering whether we really want to include the package in a stable > release at the moment. yes we had a bad release. We figured that out and fixed things. As we do not patches in the debian package we tryed to fix everything upstream. we also got fixes from others so we fixed some more things. for example the ALSA plugin which is not build by the debian package nor the upstream package. I also said that we can offer a version which is free of those changes. However I think as they are minor the effect of a 'strange' version (with backported bugfixes) may be more confusing. If you require us to do so, we will even if we do not like that. About the usage by other packages: As you noted the package is new in debian but the project is much older (started June 2008). Some packages did not yet updated the depends, for example: #589756 (Audacious), #589760 (libao), #591636 (ices2). Those are bugs I reported because I know the upstream version has working support. There may be more reports and some devels haven't yet noticed the presense of RoarAudio in Debian for sure. Audacious for example includes very good support in 2.4, but Debian still has 2.3 (devel version) because they missed the freeze themselfs. Maybe they will do a unblock request or maybe they will do a backport or something later. Don't know. Backporting of RoarAudio would be on the list again. Also there is something I would like to call 'implecide depends' indroduced by roarify. roarify (part of libroar-compat0) is a tool to make other software use RoarAudio without them needing native support. roarify is not yet another OSS emulation but much more. It also emulates other sound systems and provides emulation for binarys to help with shell scripts and such using binarys of some sound system. It currently includes emulation for: OSS, DMX4Linux, PulseAudio (parts), EsounD, aRtsc, sndio (handled more directly by the Debian package), YIFF Sound System and RSound (not part of debian yet). Also some tools for NAS are handled. If you do a rdepends for them I'm sure you get a no that short list of tools what can use RA. The daemon it self (roard as part of the roaraudio binary package) also includes protocol emulation. Basicly the same applys for it, too. Another thing why I think the package should be in is OpenBSD's sndio API. libroarsndio (part of libroar-compat0) is developed to emulate it in a very nice way. We are in close contact with OpenBSD's upstream devels to ensure it is a good emulation. It is very helpfull to have it around for porters so they can test sndio support without needing a OpenBSD box around. (I hope it's OK to answer to the other mail as part of this as this ha snothing to do with µRoarD package) > The popcon is 2 o_O It's very simple: first of all the package is not very old. Currently most uses use a version compiled from source. You know yourself people do not upgrade as often as they should. also It's not yet in stable nor oldstable so the user basis is limited anyway. And as long as I'm not sure about if this package is inlcuded and in which state I can't realy recommend users to upgrade to the RA package and tell them later they need to upgrade again because it is removed. So what to do? Option 0: let the upstream which is (nearly) bugfix-only release in Option 1: backport bugfixes and let such a package in in this case I need to know which parts exactly you dislike so we know what to backport. Option 2: remove the package. We do dislike this most (I'm sure every package maintainer would ;) See above why we think this is bad to do. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: Freeze exception: roaraudio, muroard, libao
reflum, On Wed, 2010-08-18 at 10:27 +0200, Mehdi Dogguy wrote: > On 08/17/2010 10:50 PM, Philipp Schafft wrote: > > > > If this is ok with you we will upload by tomorrow I guess. > > > > Did you see my mail about removing it from testing? Yes. Will answer to it soon. As I said in the original mail the devels are on holidays (some are back, but I'm not) so I takes some time discuss what we can do to help the process. Also I don't see a relation between problems in the roaraudio package and this small bug in muroard package. I just asked for both in a mail to not need to send too much mails for packages with simular names. The packages do not share code or something. also muroard is considered stable in upstream and by users. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: Freeze exception: roaraudio, muroard, libao
reflum, On Tue, 2010-08-17 at 13:22 +0100, Mark Brown wrote: > On Mon, Aug 16, 2010 at 09:07:37PM +0200, Patrick Matth??i wrote: > > > It is not oss-only; roaraudio just fucks up in the current code base if > > there is ONLY alsa available. > > Could you be more specific please? One of the biggest motiviations for > removing OSS is to get rid of the need for the OSS compatibility bodges > which cause all sorts of pain for ALSA. Patrick and I talked about this a bit more and I found a solution which makes everyone happy I hope: we remove the OSS backend completly and use the libao plugin and because of this use OSS or ALSA or whatever is selected by libao. This removes all depends on the actual soundsystem completly from the package. The package is unchanged expect a small patch updating a single line in the configuration header and one line in the Makefile. If this is ok with you we will upload by tomorrow I guess. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Freeze exception: roaraudio, muroard, libao
flum,
I'd like to ask for a freeze exception for the packages roaraudio,
muroard and libao. The freeze hit us while working on some updates
fixing bugs relevant to debian.
Here is a list of why I think the packages should be unblocked for
update:
muroard:
missing depends on oss-compat (#592911). If the package is not
installed muroard may become completly unusable.
roaraudio:
from offical changelog (you can find a commented diffstat at the
end of this mail:
* Fixed locking bug with libroaross and Audacity
(Make Audacity work again)
* Added working resampler code thanks to maister.
(Closes: #592017)
* Changed way to find default driver.
(Do not fail on ALSA only systems)
* Updated Debian init script
(Small fixes and cleanups)
* Added VS API
(added a small API for simpler access. if this is a problem,
we can provide a version without it just for Debian.)
* Fixed strange bug in RSound emulation killing streams
after long time.
* Disabled build of broken libao and audacious
(they are in upstream now)
Here is the current changelog for the new version with comments
as above:
[ Patrick MatthÀi ]
* Add missing dependencies to the libroar-dev package.
[ Philipp Schafft ]
* Added symlink for libsndio.so -> libsndio.so.* in -dev package
(this fixes a FTBFS of libao triggered by the libroar-compat0
package)
* Install bash completion script
(We can remove this if needed for the unblock)
* Enabled ALSA support, recommend OSS.
(This is needed on ALSA only systems. Without it the package
becomes completly unusable on ALSA only systems)
* Enabled CELT (0.7.1) support
(This enables the CELT support for RA as it updates internels to
support the CELT version shiped with Debian.
If you do not like this we can disable it again.)
libao:
I talked to the offical maintainer (John Ferlito) and he gave me
his ok for this mail.
libao currently FTBFS if RoarAudio is installed. This requires
fix in libao and fix as stated above.
The bug (#592013) in libao was fixed in 1.0.0-5 which is hold
back because of the freeze. The bug in RA has no BTS entry
currently.
We would like to add a Depends instead of a Conflicts or
something to fix this as this will in addition enable roar and
sndio output as a pro with no additional problems. The code is
already in the old version and works (beside the fixed FTBFS
with sndio).
If you do not want us to include the additional outputs we can
of cause just set a Conflicts but would be unhappy about it.
Idepended on the kind of fix (Depends or Conflicts) this
requires a new upload (1.0.0-6) as the problem is not yet
completly fixed.
John Ferlito prefers to wait for the new version of libroar
(roaraudio) before he does his upload to make sure the problem
is really fixed.
Hope you now have all informations you need. If not I'm happy to provide
the missing things.
It follows a commented diffstat for current trunk version of RoarAudio.
Changes to the release versions will only be minor changes like
changelog and todo list updates.
ChangeLog| 11
Makefile.inc |4
TODO | 40 +
configure| 119 -
dist/debian-like/defaults|7
dist/debian-like/roaraudio | 22 -
doc/man1/roarmonhttp.1 | 17
doc/new-cmds | 229 ++
doc/standard/RoarAudio-3-0-ra-codecs | 89
doc/standards| 30 +
(Those docs are not used in the Debian package)
include/libroar/beep.h | 15
include/libroar/error.h |4
include/libroar/libroar.h|1
include/libroar/roarx11.h|2
include/libroar/socket.h | 19
include/libroar/stream.h | 52 --
include/libroar/vs.h | 99
(Header for the new VS API, see above)
include/libroardsp/convert.h | 59 +-
include/libroardsp/libroardsp.h |1
include/libroardsp/resampler_poly3.h | 50 ++
include/roaraudio.h |4
include/roaraudio/audio.h|9
include/roaraudio/beep.h | 49 ++
include/roaraudio/socket.h | 53 ++
include/roaraudio/stream.h | 56 ++
libroar/Makefile |2
libroar/basic.c |3
libroar/error.c | 131 ++
libroar/file.c |5
libroar/vio_select.c | 13
