Bug#818446: roarplaylistd: FTBFS: error: 'SLP_OK' undeclared
Good morning, can you please provide the config.h from your build? (it's created by configure). I don't see why exactly this fails as it builds without OpenSLP fine for me. Thank you for your additional information. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#795209: ITP: sndio -- Small audio and MIDI framework from OpenBSD
signature.asc Description: This is a digitally signed message part
Bug#755846: libroar2: no multiarch possible
reflum, On Fri, 2014-07-25 at 09:47 +0100, Simon McVittie wrote: affects 755846 libopenal1 thanks On Thu, 24 Jul 2014 at 19:26:27 +0200, Patrick Matthäi wrote: Am 24.07.2014 um 12:14 schrieb Philipp Schafft: upstream speaking, I think this is a bug in the way OpenAL and/or roaraudio is packaged in Debian, not in upstream code, so there isn't a great deal of relevance for upstream here. I just answerd because this report hit our mailinglist's spam filter somehow. I will have a look in the next days if it is possible with the current upstream code base. I think the most appropriate answer would be for libopenal1 to either drop the libroar-compat2 dependency again, or turn it into a dynamically-loaded plugin that can be dropped to Suggests (like its dependency on libportaudio2). I would say ... or Recommends, like libpulse0, but according to popcon, roaraudio is several orders of magnitude less widely used than pulseaudio, and only 0.45% of libroar-compat2 installations actually have roaraudio installed. RoarAudio isn't used in Debian *because* Ron Lee droped all the useful dependencies to it while his personal vendeta (see the archives). Droping dependencies is what broke the package. And Debian seems to be all about 'drop it, NEVER fix it!'. This bug report supports this. It's no longer about fixing but went directly into a droping request. As upstream I often hear from people that they wonder why RoarAudio isn't working when they install the debian package: The answer is because Debian decided (see archives) NOT to support RoarAudio because of in fact I never heared about any technical reason for that. I will consider to recommend Patrick Matthäi to send a removal request for RoarAudio as this ongoing drama is more harming the RoarAudio project than bringing anyone forward. Btw. as you also pointed to the DECnet support: It's perfectly the same: Dependencies to it were drop not fixed so it became useless while I see people worring about it on the project's mailinglist as they actually use it to make money. It's said to see such a grate project as Debian being no longer interesting in fixing problems. Looking into libopenal1 in more detail, it doesn't actually have a backend to support roaraudio: what it supports is (among other things) libsndio, which as far as I can tell is the OpenBSD audio API. In OpenAL 1.14 this *was* dlopened, but in 1.15 it was changed upstream to use ordinary library linking. That makes perfect sense if you're on OpenBSD and libsndio is the audio API, but doesn't really make sense on Debian where sndio is really roaraudio. OpenAL maintainers, please consider reverting the sndio backend to use dlopen like 1.14 did, or dropping roaraudio-via-fake-sndio support until/unless someone provides an actual roaraudio backend analogous to the pulseaudio backend. A real roaraudio backend would make configuration make more sense, too: it seems more reasonable to enable roaraudio via drivers=roaraudio than to use drivers=sndio and rely on knowing that sndio is really roaraudio. If someone is going to work on this, please let me know. I'm sure this can be done in a nice and smooth way! I notice this isn't the first time libopenal1 has had an undesirable dependency chain from libroar-compat2: #673178. Looking at the multiarch situation anyway, for completeness: The libraries in libroar-compat2, which are all that OpenAL actually needs right now, look superficially OK for marking as multiarch. However, libroar-compat2 also contains /usr/bin/roarify which differs between architectures (it contains absolute paths to libroar.so.2, libroaross.so.2, /usr/lib/x86_64-linux-gnu/roaraudio/complibs, etc.). If libroar-compat2 is meant to be for manual use, more like aoss, pulsedsp, socksify etc., then nothing should be normal-library-linked to it. It's consider to be useful for the user. That includes *both* manual use and direct linking. This is why directlinking works at all. Because it is designed to do so. I notice that OpenAL seems to be the only thing using its libsndio, and the fact that it provides libsndio at all seems like an abuse of the fact that (a) OpenAL happens to have a libsndio backend, and (b) Debian happens to not have the real libsndio. On the other hand, if the intention is that other packages should be able to depend on the fake libsndio like libopenal1 does, I would suggest either: - generating a real libsndio2 package and having libopenal1 use that; or As there is currently no other implementation I consider libroarsndio the non-openbsd port of libsndio. - making roarify a separate package that is Architecture:any, not multiarch, and depends on libroar-compat2 of the same architecture. Further down the stack, libroar-compat2 depends on libroar2. libroar2 also looks OK for multiarch: it only contains architecture-prefixed libraries. Please see roar-config --list-path
Bug#755846: libroar2: no multiarch possible
flum, upstream speaking, On Thu, 2014-07-24 at 08:54 +0200, John Paul Adrian Glaubitz wrote: libopenal1 depends on libroar-compat2 and a 32 bits libopenal1 is required for wine, for example. Thus, this bug prevents the co-installation of 32 and 64 bit OpenAL applications! Please add Multi-Arch support for roar as soon as possible! I thought Debian decided to render RoarAudio useless by droping all dependencies to it? Anyway: 'roar-config --list-path' prints a list of paths it knows about. It may be a good hint to see what directories need to be taken into account (e.g. plugin directories). It may also be useful to check if the multi arch enabled plugin set the right paths. There is no reqirement for the listed binaries (bin-*) to be the same arch or something as libroar. They just need to be runable by libroar by simply calling one of the exec-family's functions. If there is anything that needs to be done upstream* please open a ticket at http://bts.keep-cool.org/ and/or inform us (via roarau...@lists.keep-cool.org). Thank you for your work and have a nice day! * There are plans for a release soon anyway. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#755892: restart doesn't work (server is terminated)
Package: mini-httpd Version: 1.19-9.3 Severity: important flum, when the mini-httpd is restarted by logrotate (or manually) there is a race condition preventing it from starting again. To mee it seems that the problem is that mini-httpd can not bind to the port if there are any active HTTP connections while the server is restarted. This results in the server to be stopped but not restarted. The initscript should check if the start command within the restart succeeded and handle the case if it doesn't. I'm looking forward to see a fix soon and thank you already for taking care of this problem. Have a nice day! -- Philipp. (Rah of PH2) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691217: honor cflags by worng way, several missing files and manpages
reflum, speaking as upstream. On Mon, 2012-10-22 at 23:04 -0430, PICCORO McKAY Lenz wrote: please this its important : there's missing files in dh_install --list-missing step, a binary utility for handle plugins, this should fixed in roarclients.install files the file binary missing are * roarfish * roarpluginrunner * roarpluginaplication u can see when compiled in dh_install step, there several and also missing manpages several missing manpages thank you for reporting. roarpluginrunner (+roarpluginaplication) is becomming a more and more important tool so it would be really good if it would be included. roarfish is going to be removed soon from upstream package so if not included currently it is best not to include it to not confuse users with a tool poping up just for one or two versions. Thank you for your investigation. PS: there is a new dir included in the new version with build-system specific files which also needs to be added as it is needed by e.g. rpld. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#680744: Upstream complains
severity 680744 important thanks flum, we still get complains upstream about this breakage so I set the severity to important as this should really be resolved soon. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#683503: New version 0.1rc0 of SavannahIce released
flum, I'm proud to announce the release of SavannahIce version 0.1rc0. This release mainly updates the Makefile to include the install, uninstall and semi-install targets as well as the distclean target. This makes SavannahIce ready to get packaged and used. This release also includes some smaller code changes to allow simpler migration to the new Common Protocol Interface (CPI) with the next release. The version was changed to include 'rc' as the code base left the state of being an experimental experiement. To honor this and welcome the package in the family of RoarAudio packages in good Shape we did this step. Feel free to send bugs or suggestions :) For details see the changelog at the end of this mail. you can find the download as allways on the website at: http://roaraudio.keep-cool.org/downloads.html ChangeLog: v. 0.1rc0 - Wed Aug 01 2012 26:05 CEST * Prepared porting to the common protocol interface (See: #267) * Updated Makefile (Closes: #268) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#255417: fixed upstream
flum, This has been fixed upstream in r18473. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#679235: animals! hey!
reflum, (CC to the bug so everybody stay informed.) On Thu, 2012-07-12 at 19:55 +0200, Patrick Matthäi wrote: Am 12.07.2012 14:10, schrieb Philipp Schafft: My next move is that I will release a new version within the next weeks (I don't see a rush here as Debian is in freeze currently). Ok, found a major legal bug so speeded this up. There was wrong/missing license infos. I don't think it affects the Debian package. I just did a new release. You can find it on the homepage[0]. From the ChangeLog: v. 201207131226 - Fri Jul 13 2012 14:26 CEST * Changed ChangeLog format to RoarAudio Changelog Format. * Allow answering sure to Want to play again?. * Updated legal infrastructure. * Updated manpage. * Updated Makefile. [0] http://software.keep-cool.org/animals.html -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#680742: Re: Bug#680742: Request: Reactivation of RoarAudio support in openal-soft
flum Ansgar Burchardt, (I'm not subscriped to this bug, if you have futur questions to me please Cc me). Given that Philipp Schafft plans to request removal of roaraudio from Debian[1], I don't think it would be useful to revert this change. I offered both ways: O and RM. The RM is *only* because the removed dependencys (not only openal). If they are re-installed the reason for the RM becomes invalid. I will leave the Debian project anyway (currently pawing over packages to new maintainers). But (not yet in public) there seems to a person interested in taking it. Also wasn't libroar-compat2 just lowered from a Recommends to a Suggests? Or have there been further changes in addition to those mentioned in [2]? I don't think so. Please also check the build-depends to be sure (they likely need to include libroar-dev). Thank you for your work and have a nice day :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#679235: i am willing to adopt those animals
reflum alberto fuentes, I'm happy you are interested in the package. Currently the package is maintained in svn at the-me's server. Are you interested in keeping it in svn? Maybe the-me can offer you access so there is no need to move. If you like to move it to anywhere else I'm fine, too, of cause. Do you need any more infos? Anything else I can help you with? Thank you for your interest and time :) @Holger Levsen See http://lists.debian.org/debian-devel/2012/06/msg01031.html -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#679236: O: ckport -- portability analysis and security checking tool
reflum, On Thu, 2012-06-28 at 12:29 +0200, Thomas Preud'homme wrote: Le mercredi 27 juin 2012 12:49:40, vous avez écrit : As it is not fully useless I only orphan it not asking for RM. The package itself is in good shape. Upstream development is not affected by this. I hope the package will find a new home. I will gladly help a new maintainer as needed. However there was no new upstream release for one year when previous releases were made every other month approximately. Is upstream development still going on? Sure. It was slown down because of other work, mostly including the now useless work for the Debian RoarAudio packages. I think there will be an upstream release before end of freeze. The package description is: ckport is a tool to check already compiled binaries and libraries for porting and security problems. . It uses objdump to read the binaries and analyses calls and jumps to functions. . This package is architecture independent and can be used on non-host architecture binaries if an objdump tool for the target architecture is installed. I've just discovered this package with this orphaning message and I find it very interesting. I'm thus interested to maintain or co-maintain it, but due to personal business right now, I will not adopt it before september. So if someone else is interested in this package fell free to adopt it and I will join in later. Thank you for your interest. Maybe the-me (currently the co maintainer) is willing to keep it untill September. He is currently hard to reach. But I don't think it is urgent at the moment anyway. Again thank you for your interested and time :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#679235: RFA: animals -- Traditional AI animal guessing engine using a binary tree DB
Package: wnpp Severity: normal I request an adopter for the animals package. After the personal vendetta by Ron Lee against me I'm no longer interested in wasting my time for the Debian project. The package itself is in good shape and easy to maintain. I still will do the upstream and will happly help a new maintainer to take this, including answering questions and be cooperative with futur problems. Hope all those little animals find a nice new home! The package description is: You think of an animal, and this package tries to guess it... when it's wrong, you teach it about your animal. . To be more flexible and help educational aspect this game does not contain an initial database. This also allows it to be used for non animals like guessing of tools or locations. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679236: O: ckport -- portability analysis and security checking tool
Package: wnpp Severity: normal Hereby I orphan the package ckport. The package as made hardy useful by Ron Lee's personal vendetta against me. While not directly related most packages provided data for this package (ckport database) will be removed or orphaned. As it is not fully useless I only orphan it not asking for RM. The package itself is in good shape. Upstream development is not affected by this. I hope the package will find a new home. I will gladly help a new maintainer as needed. The package description is: ckport is a tool to check already compiled binaries and libraries for porting and security problems. . It uses objdump to read the binaries and analyses calls and jumps to functions. . This package is architecture independent and can be used on non-host architecture binaries if an objdump tool for the target architecture is installed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676592: RM: celt -- ROM; abandoned upstream, replaced by opus
reflum, The resolution to that is independent of this removal request, I'll keep people who need to know in the loop as we learn more - but I mention it here because there are rumours that roaraudio (those nice folk who brought you a DECnet dependency to d-i) may try to resurrect this package, or embed it themselves, so just in case that is actually true, I'm red-flagging it here as an Unwise Move to make. To make this very clear: The RoarAudio as well asl the OLD mumble team was who told tat embedding is bad from the very moment Ron was asking us to do. The RoarAudio Team supports the removal itself fully. We just had problems with the way of transition (see the transition bug). This has been 'fixed' already (as Ron said, dak doesn't report us ;) Also the DECnet problem has been fixed. Where it should be: in the package dnprogs. To repeat myself: The RoarAudio Team supports this removal fully. (PS: I'm away this weekend.) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#674649: Last infos
Dear archive reader, If you wonder what happend please read: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674634 -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#673406: Why not
severity 673406 wishlist tags 673406 moreinfo thanks reflum, On Mon, 2012-05-21 at 14:28 +0100, Christine Caulfield wrote: Can you give me a good reason why it should not be a Debian native package? It's been this way for a very long time now as you mentioned an nobody else has felt the need to complain. In fact (though I can't be sure) I think it was recommended to me in the first place by someone else on the project. [...] Making it a non-native package just doubles my workload for a package that has extremely minimal use and benefits nobody that I can see. I fully support this statement. Maybe Steve McIntyre can give some more input on this. As this does not affect useability nor usefullnes and the above I do downgrade this to wishlist for the moment. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#255417: Forwarded bug to upstream
forwarded 255417 https://trac.xiph.org/ticket/1875 tags 255417 upstream thanks Just checked for this in upstream's svn. It seems to be still present. It is a problem with libxml as used by ices2. I forward this bug and hope to get it fixed soon. Thanks for your work and kind report. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#309356: ices2: Monaural audio not properly recoded from stdin
reflum, PCM does not contain any header. This means you need to ensure yourself that both, mpg321's and ices2's settings match. In case your audio is really mono and ices2 thinks it is stereo it will read each even sample as right channel and each odd sample as left. this will make it sound like it would play twice as fast (including everything moved one octave higher). Does mpg321 has some info on what it will output exactly? if so please ensure ices2's settings match this exactly. Hope I was of help. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#676541: closed by Ron r...@debian.org (roaraudio dependency removed from ices2)
# reopening as not solved in any way reopen 676541 thanks On Thu, 2012-06-07 at 23:09 +, Debian Bug Tracking System wrote: Hi Philipp, I'm a little surprised that you claim there was no prior discussion or that you don't know why this was done, since the need for this was discussed with you in person, Oh, I was asked by the maintainer (Jonas Smedegaard who did *all* uploads) to open this ticket exactly because it was not discussed publicly and not with me or anyone else. as the only logical conclusion to you digging your heels in and insisting that obsolete things were Absolutely Essential to the functionality of roar, and that you and the-me would rather see roar removed before dropping things like the abandoned celt codec, or DECnet ... This seems to be your personal vendetta against me and other persons. There is pefectly no common set between usages with CELT and ices2. So all arguments in this direction are just wrong. If you have a problem with DECnet, why don't you file a ticket against that package? Haven't seen one. Also the problem with dnet-common has been fixed. So where is your point? I don't see how any of those points interact at all with ices2 usage of ices2. The think about releases: rillian offered me to release at any time I think it is a good idea. In fact I could do myself just don't know the correct protocol to do this. Please also stop closing random bugs because you don't like them. Thanks. PS: Your MUA only sets 'Ron' as real name, this makes it harder for people to use the search in their MUA. Please consider changing this. -- 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. Just say Ok. and it will happen. It doesn't get much easier than that. You send a one line patch to break the package. In the bug you opend (after you gave us 13 minutes to upload or NMU as you said, very nice move btw.) you tell us that it is this easy as it is no transition to opus but a pure removal of celt. Please look at the title of this ticket. Transitions do *NOT* consist of removing something without replaceing
Bug#675014: libroar2: Could the dependency on libdnet please be optional?
reflum, On Tue, 2012-05-29 at 12:28 +0200, Helge Hafting wrote: Package: libroar2 Severity: wishlist Dear Maintainer, I installed a game that uses libroar2. And libroar2 pulls in libdnet and dnet-common, so on every boot I get messages about DECnet not being set up. (And some cpu time and bootup time gets wasted). I have no plans of ever using any DECnet support, and I believe that is the case for the vast majority of other users too. Don't misunderstand, I think it is nice that sound via DECnet is supported - possibly very useful for those who actually use DECnet. But it'd be nice if this support was optional, so that no decnet stuff will be _needed_ in order to use libroar2. It is fine that libroar2 will use DECnet _if it is there_, but it'd be nice if the package could be installable and useable without DECnet. That would avoid bloating the machine with never-used stuff. Thank you for your kind report. In fact you are the first person asking for this in a kind way. Here is some background: libdnet includes runtime for DECnet. This is what is included in the standard C runtime for IP (glibc). Because of a lot people being ideots this never made it's way into the standard runtine for GNU/Linux which would be the right way. In fact to make everything worse they added conflicting functions to glibc. This requires some tricks to write programs supporting DECnet which also use the normal system interfaces. libdnet mostly contains stuff like node name lookup (like DNS functions for IP). Nothing causing harm by itself. Because of this above we need to link it and have it as depends. If we downgrade the depends to a recommends or suggests programs using libroar will not load at all anymore (dynamic linker will fail with 'library not found'). dnet-common is the package doing the configuration. It is recommended by libdnet (which seems to be changed currently, down to suggests). It can safely be removed. For example using 'apt-get remove --purge dnet-common'. (The purge is optional, see apt's manpage for more details). If installed but not configured it will just print the infos you have seen at boot and do nothing else. Even if configured the used CPU time and RAM is below what I was abled to messure. It seems it uses ~8KB of kernel memory after boot (of cause only if configured!). Much less than what is used by IP support. So, don't panic, just remove dnet-common and also those boot messages should be gone. If you have any questions feel free to ask and/or reasign this report to libdnet/dnet-common. If you don't I will close this report in a few days. Thanks again for taking your time to write this ticket. Hope I was of help. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
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#674649: Please disable celt support in roaraudio
reflum, On Sat, 2012-05-26 at 21:37 +0930, Ron wrote: As you know, we're planning on removing the celt package from Wheezy. Please disable celt support at the soonest opportunity so that we can move ahead with doing that before the freeze. This codec is obsolete now and should no longer be used by general purpose applications. CELT adds a lot pain to maintainers and upstream. So I'm with you that it should be removed. Yet removal requires a good transtion. The first part was Opus entering Debian. As of my understanding this was slowed down by legal problems. The same problems slowing down (src:roaraudio) upstream development. The next step is to implement the needed support for Opus in upstream. See http://bts.keep-cool.org/ticket/243 for details. This takes about two upstream release cycles (~2*1 month). Of cause you can speed this up by helping the upstream team with implementing the needed support. Last step is to give users the time to update their config and convert all files encoded in CELT (this may also apply to other packages providing file based operations). I already wrote a mail to the RA/RS-Announce list to speed up this last step. Still people can not yet switch over because this depends on the not yet implemented support. I would guess this will need one or two months itself. So I consider this transition doable in about 4 months. As you are very, very late in the Debian release cycle I don't think this can be done before the upcoming freeze. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#665886: dnet-progs: uninstallable on kfreebsd-*
tags 665886 +pending thanks reflum, On Tue, 2012-03-27 at 21:25 +0200, Philipp Schafft wrote: On Mon, 2012-03-26 at 21:00 +0100, Adam D. Barratt wrote: dnet-progs is uninstallable on kfreebsd-* as it depends on kmod, which is linux-only. Thanks for your report. The package is 'all' not 'any'. I think it needs to be changed to 'any' to solve this problem. Will discuss this with chrissie tomorrow. I just commited a patch. It will be tested and uploaded this week if working. Still I consider this more cosmetic as the package is little usefull on kFreeBSD as the kernel does not support the protocol. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#665886: dnet-progs: uninstallable on kfreebsd-*
reflum, On Mon, 2012-03-26 at 21:00 +0100, Adam D. Barratt wrote: Hi, dnet-progs is uninstallable on kfreebsd-* as it depends on kmod, which is linux-only. Thanks for your report. The package is 'all' not 'any'. I think it needs to be changed to 'any' to solve this problem. Will discuss this with chrissie tomorrow. -- 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 pmatth...@debian.org (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
Bug#660785: transition: roaraudio
reflum,
On Sun, 2012-02-26 at 18:35 +0100, Cyril Brulebois wrote:
Philipp Schafft l...@lion.leolix.org (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#577400: Bug as been closed upstream
flum, this bug has been closed (wontfix) upstream. Please see upstream bug report for details. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#636917: Fixed upstream
tags 636917 fixed-upstream thanks flum, I commited an updated to the upstream svn yesterday. It has rev 18203. I don't know when the next release will be (I'm not the release manager for libao) but the next release will include it. Hope I helped you. :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#655740: libdnet: please reduce Recommends on dnet-common to a Suggests
reflum, I will bring this up with chrissie on our next tuesday meeting. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#516305: #516305: icecast2: Likes to disconnect sources streaming silence (extremely low bit rates)
flum, Thanks to all of you for your work. When the source client sends no data it is hard for the server process to find out if it is still alive. I don't see a good solution on the server side. I consider it part of the job of the source client to ensure a running flow of data. There are serveral ways to do this. The managed bitrate is one of them, still I consider it a workaround. Other ways are to inject empty ogg pages or add some noise to the signal. The later is what roard does (it adds noise at -102dB which is that low that decoding to 16 bits will result in a stream of perfect silence and will not result in quality loose for 16 bit audio at all). I suggest the maintainer team of icecast to close this bug as it is the source client's job. Maybe somebody should send them bugreports. Still the patch looks interesting and I will discuss it with the rest of the upstream team. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#585039: Willing to help
reflum, On Sat, 2011-11-19 at 16:05 -0500, Geoffrey Thomas wrote: On Sat, 19 Nov 2011, Philipp Schafft wrote: flum, As I care for the package as user... I'm willing to help a new maintainer in a team. Taking it over alone may not be as efficent as I don't know much about the internals and my leak of time. If necessary I would think about to take it alone. Hi Philipp, I'm definitely happy to have help -- I'll ask my sponsor about how team maintenance works. Ok. I sill don't have my DD so I need to use a sponser for uploads, too. Also same question to you: are you on IRC? I can be found as ph3-der-loewe on 'common networks'. Thank you for your work so far :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#585039: Willing to help
flum, As I care for the package as user... I'm willing to help a new maintainer in a team. Taking it over alone may not be as efficent as I don't know much about the internals and my leak of time. If necessary I would think about to take it alone. @Hans: Are you somewhere on IRC so I can talk to you more directly? -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#648729: my mistake - some libraries needed to be updated.
tag 648729 + confirmed pending thanks reflum, On Mon, 2011-11-14 at 20:31 +0530, shirish शिरीष wrote: Hi all, Can it be changed to having the libroar and libroar-compat1 libraries be in recommends or something. For when I installed their updates, after that roaraudio worked fine. What this means/meant was that the above libraries libroar and libroar-compat1 need to be in recommends (atleast that is how it appears to a user/me) . Actually dpkg should have called those two libraries if they are needed for roaraudio to work properly. After I did that it worked fine. Thank you very much for your report. I think I found it. Will test it and upload as soon as possible. :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#646669: Merging #646669 to #646669
forcemerge 646340 646669 thanks reflum, After reading stuff I still think this happend because of liby been overwritten (#646340). Another rebuild of the package should work fine. If this is untrue please unmerge/reopen this bug. Thanks for your work. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#646353: reopening
tag 646353 + pending thanks reflum, On Tue, 2011-10-25 at 19:53 +0200, Julian Taylor wrote: found 646353 2.57 reopen 646353 thanks you can verfy it by adding: export CFLAGS+=-Wl,--as-needed to the top of debian/rules. you will get this dpkg-shlibdeps warning (which must be considered an error in this case): dpkg-shlibdeps: warning: symbol dnet_htoa used by debian/libdnet/usr/lib/libdnet_daemon.so.2.43.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol getnodebyname used by debian/libdnet/usr/lib/libdnet_daemon.so.2.43.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol crypt used by debian/libdnet/usr/lib/libdnet_daemon.so.2.43.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol getobjectbyname used by debian/libdnet/usr/lib/libdnet_daemon.so.2.43.1 found in none of the libraries. using ldd -r on the installed libaries results in the undefined symbols as in my opening report. I'm sorry. I have overseen a little detail yesterday. A patch as been commited and will be included in the next upload. Thanks for reporting :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#646669: roaraudio: FTBFS: cp: cannot stat `debian/tmp/usr/lib/libroaryiff.so': No such file or directory
reflum, On Wed, 2011-10-26 at 02:30 +0200, Mònica Ramírez Arceda wrote: Source: roaraudio Version: 0.4~rc0-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20111022 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. The full build log is available from: http://people.debian.org/~lucas/logs/2011/10/22/roaraudio_0.4~rc0-1_lsid64.buildlog I'm currently offlion while writing this. I guess this is because of the recent probem with bison overwriting YIFF in the archive. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#646519: Please don't recommend dnet-common
forcemerge 608807 646519 thanks reflum, On Mon, 2011-10-24 at 20:30 +0200, Juliusz Chroboczek wrote: Since libdnet recommends dnet-common, dnet-common gets installed on systems that really don't care about DECnet. Since dnet-common tends to do weird things to your Ethernet interfaces, this regularly breaks working systems. Please do not recommend dnet-common, just suggest it. This has been discussed already. Please see #608807. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#640861: dnprogs: NMU corrupts (defaults) config file
Package: dnet-common Version: 2.56.1+nmu1 Severity: important Tags: confirmed The NMU wrongly worksaround #635604 by abusing $DNET_INTERFACES in /etc/default/decnet. It changes the content of the file based on debconf information in the postinst script. The correct way would be to to not create (or not alter if already present) the node database (/etc/decnet.conf). The result of this bug: This change is not undone by later reconfigure runs or upgrades. The change is permanent and users. even creating the node database would not enable decnet as documented and expected by users. just undoing the change in the NMU would leave users which installed the NMU version with this broken copy and require us to update the init scripts to handle this special case. The upgrade process should undo this. This should be done by string filling the variable with the default if it is empty and old version is the NMU. Also the node database must be deleted (moved away) if the old version is the NMU and no node database existed before the NMU. This is the hard part. Maybe we can check for the debconf data if we would generate a new one with the current settings. In any case the config files should be backupped. This may also trigger 'locally motified conffile' or something. I haven't check this yet. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#635604: Cleaning up...
flum, I'm currently cleaning up the NMU. Here are some infos: * The bug is solved upstream, the next release to debian will provide a diffrent fix than the NMU but still it is fixed in both versions. The release is only delayed at the moment because of some cleanup of the NMU. Hopefully we can upload tomorrow. * DECnet can always be diabled by just deleting /etc/decnet.conf. Reboot is needed to restore stuff or resetting mac address manually. * MAC address is set using 'ip link set $iface address $mac' (if ip is installed) or 'ifconfig $iface hw ether $mac allmulti up'. In both manpages I haven't found any infos when this may become a permanent change. I never have seen this. chrissie also thinks that this may be a bug in the card or the card's driver. Maybe someone should talk to the card's driver writers to find out. If someone opens a bug about this feel free to add me to the Cc. * For cards with the bug I can't do anything to help you to restore the vendor's MAC address. If it was falsely overwritten it is now overwritten. sorry. Maybe the card's vendor, some mangement tool for eternet card's I don't know or the driver writer can help. A personal note: I can understand all of you who had problems with cards changeing the address permenantly. The problem with DHCP is well know but there is no known (to me) fix for this. If someone finds one in the DHCP RFCs, please tell me! I had to reconfigure my DHCPd as well. The change of the MAC address isn't invented by us, too. Good or bad, it is in the DECnet specs. If we want to provide a conforming (and because of this working) DECnet support we need to do this. I hope this helped at least some people. I'm really sorry for all the trouble. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#639629: dnprogs: [INTL:sk] Slovak po-debconf translation
tags 639629 pending fixed-upstream thanks reflum, On Sun, 2011-08-28 at 21:46 +0200, Slavko wrote: Package: dnprogs sk.po attached Thank you very much for your work. It will be included in the next release (wich hopfully will be uploaded tomorrow). I just commited it to cvs :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#616652: remove dnet support for now
fixed 616652 libroar1/0.4~beta4~pr0-1 severity 616652 wishlist thanks On Sat, 2011-08-27 at 09:55 +0200, Stefan Fritsch wrote: It is simply not acceptable for an audio library to cause a new network protocol to be enabled and the machines MAC address to be changed. You should build libroar1 without dnet support until libdnet is changed so that just installing it doesn't cause dnet to be enabled. See my last post on this bug[0]. libdnet does not require(depend on) any kernel module, changed network configuration or similar. The is _was_ a bug in dnet-common witch you may have noticed. Please see #635604 (and maybe #636373). Do not (re)open bugs on the wrong package. Thanks. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616652#20 -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#636913: muroard prevents audio from working
reflum, thanks for your input. On Fri, 2011-08-19 at 10:02 +0200, Vincent Lefevre wrote: On 2011-08-19 03:03:41 +0200, Philipp Schafft wrote: reflum, Thanks for reporting yet another bug. On Sun, 2011-08-07 at 00:28 +0200, Vincent Lefevre wrote: When muroard is enabled (which is the default), I cannot play audio files. For instance, with ogg123, I get: ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave ERROR: Cannot open device alsa. [...] 'It\'s not a bug, it\'s a feature!'. This is exactly the expected behavior. I disagree. I now use pulseaudio, and I have no such error if ogg123 uses alsa directly. This is because there is an ALSA plugin for pulseaudio in Debian. The one for RoarAudio is currently not in Debian. This is mostly because ALSA stuff is very, very hard to test. Also this depends on config provided by other packges (like the alsa package). You may consider writing bugreports aginst them, too. I would be very happy if stuff would get smoother in this area, but this is a lot of work and I don't have the resource to handle all of them. I already talked to many software developers about this, including but not limited to open bug reports to solve those problems on Debian's BTS. Feel free to spends some of your time to help ;) µRoarD takes the audio device and expects other clients to connect to it not try to connect to the device directly. If you card does not support multiple simultanus streams you will get messages like the ones you saw IF the application tries to access the device DIRECTLY. But this means a change of configuration. That's bad for a package that was installed automatically during an upgrade. And even when installed manually, a package shouldn't make things no longer work just after its installation (i.e. it should let the user do the configuration first, such as updating /etc/libao.conf first). Yes. See above. Note: muroard was automatically installed due to a dependency. I haven't fund such a dependeny. If there is one it may be a bug. Please provide more information about this here or in another bug report against the package falsely depending on µRoarD. There was a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613625 but it's now fixed (however once installed, the muroard package remained). Of cause. But I can't fix a fixed bug. I'm sorry if this bug still causes trouble. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#633984: [INTL:da] Danish translation of the debconf templates dnprogs
reflum, Thank you very much for your work. I just commited it so it will be included in the next release (soon). I'm also very sorry for the delay. On Fri, 2011-07-15 at 18:11 +0100, Joe Dalton wrote: Package: dnprogs Severity: wishlist Tags: l10n patch Please include the attached Danish dnprogs translations. joe@joe-desktop:~/over/debian/dnprogs$ msgfmt --statistics -c -v -o /dev/null da.po da.po: 15 oversatte tekster. bye Joe -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#636373: libdnet: Only suggest dnet-common
reflum,
On Tue, 2011-08-02 at 20:48 +0200, Nicos Gollan wrote:
Package: libdnet
Version: 2.56
Severity: normal
Installing dnet-common requires user input for an archaic artifact that
most users will not be familiar with. People who wat to use DECnet will
know where to look.
Please reduce dnet-common to a suggestion for libdnet.
I will talk to chrissi about this. I'm not sure if a suggest is a good
idea. Maybe there is some other way to help with this problem. We are
aware of this but there doesn't seem to be a good solution as at least
one user group needs to take extra action. (ideally both user groups
('dumb user' and 'user wanting to actively use this feature') would not
need to take extra actions).
Also I will have a look at other packages with similar requirements.
--
Philipp.
(Rah of PH2)
signature.asc
Description: This is a digitally signed message part
Bug#635604: Problem in postinst script
retitle 635604 postinst script does always generate node database tags 635604 upstream confirmed thanks Thanks for reporting this problem. The problem is that the postinst script does not detect if data from debconf database are defaults or actual user inputs. The node database should not be generated if 'skip and leave config as it is' is selected. I'm currently unsure about the best way to fix this. Will talk to chrissi again about this tomorrow. Btw. the other problems you noticed arise from this (like the un-unique MACs or the problems with DHCP). The problem with the NIC not restoring original MAC address is strange. Without more information I would guess it's the card's firmware or driver's fault. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#636371: libroar1: Do not depend on system libcelt
reflum, On Tue, 2011-08-02 at 20:33 +0200, Nicos Gollan wrote: Depending on a system-level libcelt will frequently break until the CELT bitstream becomes stable. This can and likely will cause interoperability issues at some point, e.g. when Debian updates from the by now seriously outdated 0.7 library. If CELT is absolutely required, supply a private library like e.g. Mumble does. The RoarAudio developer team is in contact with both upstream and ron (the debian maintainer for celt/opus). We are aware of those problems. The protocol used to transmit CELT data (codec=ROAR_CELT) transmits the used version of CELT so the other end can (and will) check if they match so there will be no problem between packages compiled with diffrent versions of CELT (beside that it does not work). ron told me he is going to not upgrade libcelt to newer versions any more but to migrate all software to opus as soon as it gets into a clear legal state. Same goes for RoarAudio devels: as soon as the legal problems are solved we will start to support opus and this package will be migraded as well. I will contact ron again to ask him if anything changed I need to know about or if the planed migration path is still valid. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#634335: , Bug#634791: roaraudio, muroar: debian/control uses hardcoded list of non-Linux architectures
reflum, On Mon, 2011-07-18 at 16:12 +0200, Robert Millan wrote: Package: roaraudio Package: muroar The debian/control file in roaraudio [and muroar] uses a negated list of architectures to specify a package relationship (most likely Build-Depends) on a Linux-specific package. [...] Thanks for reporting this bug. I will take care of it with the next release. Some details (for the rest of the maintainer team ;): I found the following 3 lions: libdnet-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], This is maybe going to change with the next releases of libdnet-dev. Will talk to chrissie about this. libpulse-dev [!hurd-i386], Pulseaudio is broken. It is most broken on hurd. libasound2-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], For this one the bug report is correct. This needs to be changed. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#599680: crashes with: illegal hardware instruction
Package: blender Version: 2.57.2-svn36339-1 Followup-For: Bug #599680 flum, when I run blender I get the following error: $ blender Illegal instruction I started it with gdb and blender-gdb installed and got the following backtrace: #0 0x08b21a8e in RNA_def_property_range (prop=0x9425c08, min=1, max=9) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/makesrna/intern/rna_define.c:1156 #1 0x08b25ef0 in RNA_def_int (cont_=0x94254a0, identifier=0x8c5271d filemode, default_value=8, hardmin=1, hardmax=9, ui_name=0x8c5270b File Browser Mode, ui_description=0x8c533c0 The setting for the file browser mode to load a .blend file, a library or a special file, softmin=1, softmax=9) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/makesrna/intern/rna_define.c:2137 #2 0x082fb775 in WM_operator_properties_filesel (ot=0x9425410, filter=2052, type=8, action=0, flag=8) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/windowmanager/intern/wm_operators.c:832 #3 0x082fbd72 in WM_OT_open_mainfile (ot=0x9425410) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/windowmanager/intern/wm_operators.c:1499 #4 0x082fa514 in WM_operatortype_append (opfunc=0x82fbd00 WM_OT_open_mainfile) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/windowmanager/intern/wm_operators.c:143 #5 0x082fdc81 in wm_operatortype_init () at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/windowmanager/intern/wm_operators.c:3140 #6 0x082f3483 in WM_init (C=0x92d2680, argc=1, argv=0xb5b4) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/blender/windowmanager/intern/wm_init_exit.c:134 #7 0x082e29fe in main (argc=1, argv=0xb5b4) at /build/buildd-blender_2.57.2-svn36339-1-i386-1VM4Xs/blender-2.57.2-svn36339/source/creator/creator.c:1242 I hope that will help you to solve the problem. Thanks for your work :) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages blender depends on: ii libavcodec52 4:0.6.2-3 Libav codec library ii libavdevice524:0.6.2-3 Libav device handling library ii libavformat524:0.6.2-3 Libav file format library ii libavutil50 4:0.6.2-3 Libav utility library ii libc62.11.2-10 Embedded GNU C Library: Shared lib ii libfftw3-3 3.2.2-1 library for computing Fast Fourier ii libfreetype6 2.4.4-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.6.0-6 GCC support library ii libgl1-mesa-glx [lib 7.10.2-2free implementation of the OpenGL ii libglu1-mesa [libglu 7.10.2-2The OpenGL utility library (GLU) ii libgomp1 4.6.0-6 GCC OpenMP (GOMP) support library ii libilmbase6 1.0.1-3 several utility libraries from ILM ii libjack0 [libjack-0. 1:0.120.1+svn4142-1 JACK Audio Connection Kit (librari ii libjpeg626b1-1 The Independent JPEG Group's JPEG ii libopenal1 1:1.13-2Software implementation of the Ope ii libopenexr6 1.6.1-4.1 runtime files for the OpenEXR imag ii libopenjpeg2 1.3+dfsg-4 JPEG 2000 image compression/decomp ii libpng12-0 1.2.44-2PNG library - runtime ii libpython3.2 3.2-4 Shared Python runtime library (ver ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libsdl1.2debian 1.2.14-6.3 Simple DirectMedia Layer ii libsndfile1 1.0.24-1Library for reading/writing audio ii libstdc++6 4.6.0-6 The GNU Standard C++ Library v3 ii libswscale0 4:0.6.2-3 Libav video scaling library ii libtiff4 3.9.5-1 Tag Image File Format (TIFF) libra ii libx11-6 2:1.4.3-1 X11 client-side library ii libxi6 2:1.4.2-1 X11 Input extension library ii python3.23.2-4 An interactive high-level object-o ii ttf-dejavu 2.33-1 Metapackage to pull in ttf-dejavu- ii zlib1g 1:1.2.3.4.dfsg-3compression library - runtime blender recommends no packages. Versions of packages blender suggests: pn yafraynone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to
Bug#577400: device-internal no longer available
flum, what package/software do you try to build needing it's own libao plugin to be build outside the libao tree? -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#624685: vclt-tools: Use Digest::SHA and drop Depends on libdigest-sha1-perl
tag 624685 + pending fixed-upstream thanks reflum On Sat, 2011-04-30 at 18:20 +0200, Salvatore Bonaccorso wrote: We from the Debian Perl Group would like to drop libdigest-sha1-perl at some point, see [1]. Most of the functionality (except sha1_transform) of Digest::SHA1 is also provided by Digest::SHA. Switching from Digest::SHA1 to Digest::SHA should be in principle as easy as substituting the use of Digest::SHA1 with Digest::SHA. Digest::SHA is in Perl core since version 5.9.3 and thus is in Debian's perl since Lenny. Changing use of Digest::SHA1 to Digest::SHA would thus reduce external dependencies by one. [1] http://deb.li/digestsha thanks for the info. Just tested it and it produced exactly the same output for both modules. It also works on etch (which is still in the list of systems upstream needs to care about). Both bin/sc2vclt and bin/xiph2vclt use Digest::SHA1 qw(sha1). But the very same functionality is provided by Digest::SHA. Changing the use of Digest::SHA1 to Digest::SHA will thus allow to drop the Depends on libdigest-sha1-perl. Could you plase change this (and too apply upstream)? commited the changes to upstream. Upload to Debian will be done within the next days. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#589756: Still no RoarAudio plugin in audacious-plugins
found 589756 2.4.2-1 thanks The bug seems not to be fixed. The package does not contain a plugin nor does it depend on libroar*. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#616652: libroar1: libdnet NEEDS to go
reflum, On Thu, 2011-03-17 at 00:14 -0400, Jonathan Lane wrote: I'm using a seven year old machine with a 2.0GHz Athlon XP and 512MB RAM. I still like using full-featured web browsers (Iceweasel) and watching videos with (s)mplayer. This means that every megabyte of RAM counts, especially in kernel space. My system is not even 1/4 of yours. I never noticed the module because of system resources used. libdnet consumes about 24KB RAM on my system. I suspect this will be swapped out if not used. It DOES NOT depend on any kernel module, changed network configuration or something else. It does only depend on standard c lib as loaded by (nearly) any process anyway. Your request is like if I would file a bug report aginst IPv6 because I have IPv6 stuff loaded but not used. I suspect this does wast much more system resources (yes, at least one time I noticed the resources used by that). Imagine my shock and dismay when installing a simple ncurses audio player altered my MAC address and inserted a kernel module. That module, by the way, has been ORPHANED for a year. This is not done by libroar nor libdnet. dnet-common may do this depending on system configuration. Beside the normal 'not configured' state the package asks explecitly if it should configure the interface. If you have a (very old) package please upgrade. Please do not report bug reports for stuff that has been fixed long ago. --- Please report bug reports aginst the corresponding package, not against package which *may* use the corresponding package *indirectly*. --- Reporting aginst libroar is like reporting ifupdown bugs aginst iceweasel. Debian's Alpha port has been dropped. /me is very unsure what this has to do with this report. DECNet is a very, very minor use case. The odds of anybody trying to *stream audio* over DECnet instead of IPv4 or IPv6 is astronomically small. I doubt anyone but the libroar developers themselves even care about that particular usage. Please get this junk out of the Debian package. DECnet is _much_ better for streaming stuff (for example because of very much lower jitter). Because of this supporting this is important. I know serveral users of it which aren't anything else than just plain users. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#613771: Still working on it...
flum, The problem seems to be a bug somewhere in ALSA and the HDA driver. Another user reported it to me. The problem seems that µRoarD starts up with a sample rate of 44.1kHz by default. The card only supports 48kHz. ALSA is resampling and takes a lot CPU time. I'm unsure if we can solve this in this package or if this needs to be forwarded to ALSA package (See #592911 and changelog for why). But I think the problem is already known to upstream. I'm still working on this and try to find a good solution. Thanks again for reporting this and providing all the infos :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#613772: /etc/init.d/muroard stop has no effect if MUROARD='NO'
reflum, On Thu, 2011-02-17 at 04:47 +0100, Vincent Lefevre wrote: If in /etc/default/muroard one doesn't have MUROARD='YES' (e.g. after a config change), then /etc/init.d/muroard stop has no effect. In /etc/init.d/muroard, the check [ $MUROARD = 'YES' ] || exit 0; should be done for start only. We plan to have a new upstream release (and upload to Debian) within the next days. I'm sure we can fix this with this release. Many thanks for reporting this bug. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#613771: muroard takes too much CPU time
reflum, On Thu, 2011-02-17 at 04:38 +0100, Vincent Lefevre wrote: In its default configuration, muroard constantly takes about 45% CPU (even when there's no sound). -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages muroard depends on: ii libao41.0.0-5Cross Platform Audio Output Librar ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib Thanks for reporting this strange bug. Please provide the following infos: $ cat /etc/libao.conf $ cat /proc/cpuinfo $ aplay -l $ lspci | grep -i multimedia ALSA version (if installed). Can be found out by: $ dpkg -l libasound\* Does it also happen if you start µRoarD as user without arguments? Does it still happen if you start it with -R 48000? Are use used to strace? -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#612887: cmus: please avoid the dependency on several sound
reflum, I'm still confused about this. Please not that I'm not the maintainer nor anyone else offical for the package, so it's safe to just ignore me. If you think this is a libroar bug please reassign the bug to libroar but I do not yet see where libdnet and #608807 come into play. Can you please clearify this? libdnet does not depend or recommend on any daemon. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#612887: cmus: please avoid the dependency on several sound servers
reflum, On Fri, 2011-02-11 at 11:43 +0100, Paul Menzel wrote: Dear Debian folks, upgrading to DebPkg:cmus 2.3.3-4 installed DebPkg:libroar1 as a dependency [1] * Add RoarOutput plugin (Closes: #609202), thanks to Philipp Schafft l...@lion.leolix.org for the patch. which in turn pulled in DebPkg:libdnet. $ apt-cache rdepends libdnet libdnet Reverse Depends: [...] I don't understand what libdnet has to do with the actuall report. Please clarify this a bit for me. I already have DebPkg:pulseaudio installed, so I guess I do not need a second sound server. (If I understood something incorrectly about the purpose of PulseAudio and RoarAudio please tell me and close the report.) I have just checked the package dependecys. libroar* does not depend on any sound server but recommends virtual package roaraudio-server. So you can have it installed without such an additional server. To avoid that dependency could you please package the RoarAudio plugin separately in for example DebPkg:cmus-plugin-roaraudio. I use roard (package: roaraudio) instlled. I do not like to have any dependecy on *pulse* packages. See? It is exacktly the other way around here. So if cmus does have plugin in a new plugin package pulseaudio support (and maybe other) should be moved into a seperate package as well. I am putting Philipp in CC because he is the author of the patch. Thanks. :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#610642: dnprogs: [INTL:ru] Russian debconf templates translation update
reflum, On Thu, 2011-01-20 at 21:24 +0300, Yuri Kozlov wrote: Russian debconf templates translation update is attached. Thanks for you fast response! Stuff is allready commited and will be part as of next release within the next days. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#609202: Please enable RoarAudio support
reflum, On Tue, 2011-01-11 at 17:59 +0100, Alessio Treglia wrote: Hi, On Tue, Jan 11, 2011 at 12:35 PM, Philipp Schafft l...@lion.leolix.org wrote: All you need to do is a Build-Depends on libroar-dev (= 0.4~beta2). I just have noticed we do not yet have it in experimental. Will ask Patrick about it. It's great! Please let me know once available in experimental. I saw you found it a day before I was about to send you a mail. ;) About the build problems of experimental version (#610254): I'm currently working on getting update uploaded. I hope it will be fixed after this upload. Thanks again for you good works, thanks for helping Debian and make the wold a bit better :) -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#599808: Module failture on some archs
flum, After some time of testing I got a bit closer to why this module does not work on some archs: The module uses the refence implementation in nealry unchanged from to do the calculation itself. The problem is that the refrence implementation is buggy. It does not caclulate the same result on a given string for all archs. I also discovered another problem (see #610254): Refence implementation uses wrong casts on big endian systems and triggers FTBFS. This may apply to this module as well. (I'm not sure.) Before this module is packaged upstream should be contacted (I Cced him in this mail) and asked to fix or replace the code used from refrence implementation. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#609202: Please enable RoarAudio support
reflum, On Mon, 2011-01-10 at 10:16 +0100, Alessio Treglia wrote: Philipp, Thank you for taking the time to report this bug and helping to make Debian better. Thank you for looking at your bug reports. :) I've seen your message in the CMus development mailing list, so I was wondering if you already have a patch for the current version in unstable. If so, I'll apply it with a new upload to Debian experimental. My patch was written against cmus-2.3.3 as downloaded by apt-get source so it should work with this older version, too. All you need to do is a Build-Depends on libroar-dev (= 0.4~beta2). I just have noticed we do not yet have it in experimental. Will ask Patrick about it. Hope I was abled to help you. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#608807: ices2: ethernet address changed
reflum, On Tue, 2011-01-04 at 01:28 +0100, Jonas Smedegaard wrote: Hi Philipp, Thanks for your clarification, On Tue, Jan 04, 2011 at 12:46:21AM +0100, Philipp Schafft wrote: I suggest to: close the bug as invalid (it's not ices2's problem) as the install does exactly what it is suppost to do: it try to set up the system in a way all features works OR re-assign it to source package dnprogs which includes libdnet and dnet-common and request for some better way to solve this. Already done the latter: reassigned to libdnet. Jup. Saw it. I find it wrong to close it when indeed there _is_ a bug somewhere. It's just that I don't consider this a bug but a missing feature. So I would have a look at it anyway. Some time ago we already had a fix in this direction. I'm currently thing about if we can get dnet-common to support installing in unconfigured mode (we allready support to deconfigure it, just by rm-ing the config file after install). Will have a look at it within the next days, don't know how much work it will be. Are there any plans to request unblock of ices2 2.0.1-9 for squeeze? -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#608807: Possible solution
flum,
I allready commited the following fix to upstream. Hope it get reviewed
soon.
I added a debconf question asking if the package should be configured.
I hope it will pass some more tests and review.
I'm not going to change the recommends to suggests as suggests is much
to weak and will affect other users ('why is my network net set up
correctly?').
Added note about network reconfig and default to not configure.
--
Philipp.
(Rah of PH2)
signature.asc
Description: This is a digitally signed message part
Bug#608812: muroard user left in passwd after purge
tags 608812 + pending thanks reflum, On Tue, 2011-01-04 at 16:27 -0700, Bob Proulx wrote: tags 608812 - moreinfo + patch thanks Bob Proulx wrote: I believe the best corrective action is to ensure in the init script file /etc/init.d/muroard that start-stop-daemon ensures that the process has actually exited before the script exits. Currently it does: start-stop-daemon --stop --pidfile /var/run/muroard.pid --user muroard --exec /usr/bin/muroard || true I propose the following change to /etc/init.d/muroard to correct this problem. Add the following options to start-stop-daemon. --retry 30 --oknodo --quiet I propose that the script change this way: stop|terminate|shutdown) echo -n Stopping $DESC: -start-stop-daemon --stop $SSD_OPTS || true +start-stop-daemon --stop --retry 30 --oknodo --quiet $SSD_OPTS echo $NAME. ;; I tested that through several iterations and I believe it is the best solution to the problem. Thanks for info. So my guess about it seemed to be true. Will test that fix and if it works (I guess so) will include it in next upload (in a few days). thanks for reporting. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#608807: Possible solution
reflum,
On Tue, 2011-01-04 at 23:37 +0100, Jonas Smedegaard wrote:
On Tue, Jan 04, 2011 at 11:21:24PM +0100, Philipp Schafft wrote:
I added a debconf question asking if the package should be
configured.
Choice is good, but not what this bug is about.
This bug is about default behaviour. So only if default config (with or
without interacting with debconf!) is to _not_ enable DECnet, this bug
is not solved by that approach.
see bellow.
I'm not going to change the recommends to suggests as suggests is
much
to weak and will affect other users ('why is my network net set up
correctly?').
Users of DECnet obviously need DECnet configured by default. My
proposal is not to change that.
This is what the package does currently. How I understand this is that
you want to relex this a bit.
But users of DECnet should install the _tool_ to handle DECnet, not just
install the _library_ and expect that to pull in the tool. That is
simply the wrong way around, and cause this bugreport: Currently users
of _any_ tool which _can_ support DECnet, gets DECnet enabled by
default.
there is no 'the tool'. Can't follow you here. I just assume you talk
about dnet-common. If that is wrong please correct me.
dnet-common is just the package taking care about config. it does not
(really) include any tools at all!
dnet-progs in contrast includes some tools. Those are common to be used
with DECnet but not required for anything than there own functionalty (a
'leaf' package). (btw.: only about 10% (according to popcon) of DECnet
users have it installed!)
If you for example set up RoarAudio with DECnet support you just need
libdnet and a configured system (which is normally done by dnet-common).
There is no need for dnet-progs or any other package.
So what do you consider 'tool' here? any decnet enabled package could be
such a tool. Even ices2 could be.
I think we agree about libdnet's role in this game. It should just do
it's job and do not force configured network. This is done by both
Recommends and Suggests.
libdnet is the central and the only central package for DECnet support.
Above you said:
Users of DECnet obviously need DECnet configured by default.
so how do differ?
Pollicy tells the following in '7.2 Binary Dependencies - Depends,
Recommends, Suggests, Enhances, Pre-Depends':
Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.
Suggests
This is used to declare that one package may be more useful
with one or more others. Using this field tells the packaging
system and the user that the listed packages are related to
this one and can perhaps enhance its usefulness, but that
installing this one without them is perfectly reasonable.
As libdnet is central package it is normally useless if system is not
configured. A configured network will not 'perhaps enhance its
usefulness' but without it it is normally useless.
So I understands this the way policy suggests us to use Recommends which
we currently do.
No user of the _library_ should be surprised that it did not magically
setup their network!
Nor should any user installing a DECnet using application be surprised
by not setting up network correctly.
If we drop from Recommends to Suggests it makes installing this
complicated and requires some document telling you how to setup, not
just apt-get install what you want like it is currently.
Users of the tool should be unaffected by the change of the _libary_
no
longer pulling in the tool. After all, users of the tool should
explicitly install the tool!
I strongly believe that the simplest and most elegant approach to
solving this bug is to lower the relationship of the _library_ with
the
_tool_ to only be a suggestion.
See above.
If you have any idea how to solve this in a way not affecting existing
or new users and helps with non-users but dependecy installing people
please tell me!
As I do not know how to find out automatically or do some good guess (or
any guess at all!) I think it is best to ask user if he/she/hir/it want
to do the full setup or skip it.
I would be happy to hear from you :)
--
Philipp.
(Rah of PH2)
signature.asc
Description: This is a digitally signed message part
Bug#608812: muroard user left in passwd after purge
tag 608812 moreinfo thanks reflum, On Mon, 2011-01-03 at 10:24 -0700, Bob Proulx wrote: Package: muroard Version: 0.1.0-4 Severity: normal When the muroard package is installed it adds a muroard user to the password database. When the muroard package is purged the muroard user is left behind instead of being cleaned up and removed. I just tested it in my sid sandbox and it worked fine. The current postrm script does the following: purge) if getent passwd|grep -q ^muroard: ; then userdel muroard 21 /dev/null || true fi I don't see how it could leave the user beside userdel failing. Please do the following: # userdel muroard; echo $? and report the output. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#608812: muroard user left in passwd after purge
reflum, On Mon, 2011-01-03 at 11:41 -0700, Bob Proulx wrote: Philipp Schafft wrote: I just tested it in my sid sandbox and it worked fine. =20 The current postrm script does the following: purge) if getent passwd|grep -q ^muroard: ; then userdel muroard 21 /dev/null || true fi =20 I don't see how it could leave the user beside userdel failing. Hmm... Agreed. If that is there then it should have been removed. Here is what I know: The following NEW packages will be installed: dnet-common libdnet libroar0 muroard The following packages will be upgraded: ... ices2 ... 17 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Seems this way: ices2 depends libroar0. libroar0 recommends roaraudio-server which is virtual, muroard got selected. libroar0 depends libdnet. libdnet recommends dnet-common. And so those were installed with the ices2 upgrade this morning. This caused the hardware ethernet address to be set to aa:0:4:0:a:4. I filed Bug#608807 concerning it. Will answer to that after I answered to this one. To restore functionality I removed the following: $ sudo apt-get remove --purge dnet-common libdnet libroar0 muroard Reading package lists... Done Building dependency tree =20 Reading state information... Done The following packages will be REMOVED: dnet-common* ices2* libdnet* libroar0* muroard* 0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded. After this operation, 1,200 kB disk space will be freed. Do you want to continue [Y/n]?=20 (Reading database ... 282207 files and directories currently installed.) Removing dnet-common ... Purging configuration files for dnet-common ... Removing ices2 ... Removing libroar0 ... Purging configuration files for libroar0 ... Removing libdnet ... Purging configuration files for libdnet ... Removing muroard ... Stopping muRoarD: muroard. Purging configuration files for muroard ... userdel: user muroard is currently logged in Processing triggers for man-db ... Processing triggers for doc-base ... Processing 1 removed doc-base file(s)... Registering documents with scrollkeeper... But it didn't clean up everything: # grep muroard /etc/passwd muroard:x:125:29::/var/lib/muroard:/bin/false Therefore I removed the user manually. # deluser muroard Removing user `muroard' ... Done. Please do the following: # userdel muroard; echo $? and report the output. Too late since I already removed the user manually. But clearly in the above output the user did exist at that time and was removed by the deluser command. If I run it again now it clearly has produces different output ensuring that we can trust that the above actually did remove the user. # deluser muroard /usr/sbin/deluser: The user `muroard' does not exist. hm. Still after both Patrick Matthäi and me had a look at the package we can not reproduce or find by audit the error. Can you please try installing and purging again? if you only install muroard there should be no problem with *dnet* as it is a depends of libroar0 not muroard. Unfortunately due to Bug#608807 I am hesitant to install it again to try it because I don't want decnet to reset my mac address again. I could however create a dummy package to fulfil the dependency for testing if needed. See above. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#608807: ices2: ethernet address changed
reflum, On Mon, 2011-01-03 at 09:54 -0700, Bob Proulx wrote: Package: ices2 Version: 2.0.1-9 Severity: normal A dist-upgrade today upgraded ices2. The new dependencies pulled in dnet-common, libdnet, libroar0, and muroard which caused the machine to set the ethernet address to aa:0:4:0:a:4 from its previous address. This of course caused the network to be problematic until the arp caches timed out. The package changing the ethernet address appears to be dnet-common which is now a dependency of ices2. To clear this up: From #608812 ices2 depends libroar0. libroar0 recommends roaraudio-server which is virtual, muroard got selected. libroar0 depends libdnet. libdnet recommends dnet-common. The network setup thingy is part of dnet-common. Installing without it is possible. libdnet does not produce strange errors on missing dnet-common, it just detects the non existing support (implecide) and returns normal ENOSYS and friends. So no problem here if not installed. So please have a look if installing without recommends works. Depends of ices2 on libroar0 isn't the problem. I suggest to: close the bug as invalid (it's not ices2's problem) as the install does exactly what it is suppost to do: it try to set up the system in a way all features works OR re-assign it to source package dnprogs which includes libdnet and dnet-common and request for some better way to solve this. I do not consider this a ices2 bug as dnet-common is not a depends or recommends of ices2. Does ices2 really need to have decnet installed and configured? No, but: libroar0 is used and it depends on libdnet so installed libdnet is required (but the lib is very small and and stuff so I do not consider this a problem). Configrued: no but in the case you actually want to use DECnet support. Hope I made this a bit more clear :) Bob -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ices2 depends on: ii libasound2 1.0.23-2.1 shared library for ALSA applicatio ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libogg0 1.2.0~dfsg-1 Ogg bitstream library ii libroar00.3-2foundation libraries for the RoarA ii libshout3 2.2.2-5+b1 MP3/Ogg Vorbis broadcast streaming ii libvorbis0a 1.3.1-1 The Vorbis General Audio Compressi ii libvorbisenc2 1.3.1-1 The Vorbis General Audio Compressi ii libxml2 2.7.8.dfsg-2 GNOME XML library ii netbase 4.44 Basic TCP/IP networking system ices2 recommends no packages. Versions of packages ices2 suggests: ii icecast2 2.3.2-6Ogg Vorbis and MP3 streaming media ii muroard [roaraudio-server]0.1.0-4minimalist RoarAudio sound daemon -- no debconf information -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#606019: roarplaylistd ftbfs with ld --no-add-needed
tag 606019 +pending upstream tag 606019 -patch thanks Some infos on this bug: * Does not seem to affact Debian at the moment * Needs to be fixed by upstream, requires data from configure script to be used by Makefile * This should be passed to upstream's BTS. * The provided patch is useless as it is a dirty workaround and does not solve the possible problem at all. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#572770: libgstreamer0.10-0: The package has a memory leak of 5mb/h in Usage(playing radio stream)
fixed 572770 0.10.30-1 thanks After retesting with newer version and quick chat with upstream I beleve this to be fixed in version 0.10.30-1. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#603117: roarplaylistd: ..needs a wee jump starting 'touch /tmp/.rpld '
reflum, I guess your problem is a duplicate of #603117 Please have a look at it and my mail to that post and tell me if you think this is a diffrent problem. Currently I can't reproduce it. Du you have roard (from roaraudio package) installed and running? ...my fix suggestion: 'touch /tmp/.rpld ' /tmp/.rpld is a socket opened by rpld. It should be created in case startup was successful. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#603042: roarplaylistd: /tmp/.rpld may fail to materialize
reflum, About the warning: 'Warning: Restore failed' is normal as it can not restore old state on first startup as there is no old state to restore. This is normal to happen on install. Maybe we can do something about the warning but for the moment it can just be ignored. About the chown in init script: Yes. This is a bug. It is on TODO list of upstream and will likely be fixed by next release. About the fail to start: It seems it fails to start from what you said. Is there any roaraudio-server running? I recommend the use of roard from roaraudio package. You can confirm with something like: ps aux | grep roard -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#602330: libdnet: DECnet causes eth0 to stop passing traffic
reflum, On Wed, 2010-11-03 at 12:17 -0700, Ted Wexler wrote: Installing libdnet with apt-get install libdnet causes eth0 to stop passing traffic. Not entirely sure what's going on here, but below is the output from /var/log/messages while this is happening: Nov 3 11:54:18 debian kernel: [ 857.904819] NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team Nov 3 11:54:18 debian kernel: [ 857.906861] DECnet: Routing cache hash table of 1024 buckets, 16Kbytes Nov 3 11:54:18 debian kernel: [ 857.906868] NET: Registered protocol family 12 Nov 3 11:56:38 debian kernel: [ 997.364345] udevd version 125 started I can't seem to find any other correlating evidence. ping does not fail with any errors, just behaves like the host is not responding. -- System Information: Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) There is a bug in newer kernels. 2.6.26 is affaced IIRC. Please provode: * ifconfig eth0 * lspci | grep Ethernet Try: ifconfig eth0 allmulti wait a moment and see if network works again. Does that help? -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#592785: #592785 please default to OSS on kfreebsd
flum, why is this file included at all? libao has a nice way to select a working backend at runtime. why is it forced to use some backend by default? As far as I can see the file does not exist in upstream trunk. The file was added to debian/ at rev 1842 which was version 0.8.0-1 with no changelog entry. maybe the file should be removed completly. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#589760: libao4: Debian's package does not include the RoarAudio plugin -- Additional information
reflum, Tested 1.0.0-4 with RoarAudio enabled today. I found two FTBFS which happen if you try this. Both are fixed in upstream. This means that this feature requires a newer release of the source and not just repacking. Enabling the RoarAudio support also enables OpenBSD's sndio code. Because of this a Build-Depends on libsndio-dev (no version as it is a virtual package provided by libroar-dev) should also be added to avoid problems with this in future. The Coressponding depends for runtime is libsndio0 (provided by libroar-compat0). Those provides are done in consensus with OpenBSD's sndio upstream devel so no future collisions will happen. Build-Depends for RoarAudio needs to be: libroar-dev (= 0.3~beta7-pr2-2) This version is not yet released but I hope the RoarAudio package maintainer will do the release within the next days. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#583596: animals should be able to guess different things too
reflum, I added support to use multible databases. (upload will soon be made) Currently I only support databases given by the user as arguments. Should there also be support for something like ~/.animalsdb or $ANIMALSDB? The name of the 'object type' is stored in the database file as well. If none was found 'animal' is used so old files still works. If no plural form is given (the program uses singular and plural form) the plural is singular form plus tailing plural-'s'. Hope this fix is what you was looking for. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#588185: blind porting didn't help, need test system for porting
reopen thanks As the build system at reports there is still need for some more porting. See: https://buildd.debian.org/status/package.php?p=dnprogs Nexts steps include to get a account on a system with the affected arch and do some porting as the blind porting seemed not to solve the complete problem. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
