Re: stk backport to buster?
Hi, On Wed, Jan 27, 2021 at 8:58 PM Thorsten Glaser wrote: > Hi maintainers, > > are you planning to backport stk? This would be a prerequisite for > a backport of polyphone; I could have a look at it myself if simply > rebuilding would work, or if there’s not too much CFrustFrust involved. > No, I'm not. As a matter of fact, I've been grossly neglecting stk since a few years. Maybe you could be interested in taking over? It is not much maintenance, but the annoyance is the unstable-abi that requires transitions on each update. -- Saludos, Felipe Sateler
Bug#956672: rtkit activation fails, because service unit is installed at the wrong place
On Sun, Apr 19, 2020 at 4:45 PM Boyuan Yang wrote:
> Control: tags -1 -pending +patch
> X-Debbugs-CC: sate...@debian.org
>
> Alright -- I think I got the reason.
>
> Since we switched to meson buildsystem, all variable handling happens in
> meson.build. Starting at
>
> https://salsa.debian.org/multimedia-team/rtkit/-/blob/0a0f6d58f792f8dcf38f9b0b4cf925e9f4f4337d/meson.build#L61
> :
>
> systemunitdir = ''
> if systemunitdir == '' and systemd_dep.found()
> systemunitdir = systemd_dep.get_pkgconfig_variable(
> 'systemdsystemunitdir',
> default: '',
> )
> endif
> if systemunitdir == ''
> systemunitdir = get_option('libdir') / 'systemd' / 'system'
> endif
>
>
OK, so the problem is that the `systemunitdir = ''` at the first line is
wrong. It should be `systemunitdir = get_option('systemd_systemunitdir')`
(like the polkit_actiondir block a few lines up).
NMU welcome ;). Otherwise I'll take a look over the weekend.
--
Saludos,
Felipe Sateler
Bug#946104: autopkgtest fails with "Failed to retrieve max realtime priority: Input/output error"
Control: tags -1 moreinfo Hi Michael, On Tue, Dec 3, 2019 at 5:45 PM Michael Biebl wrote: > Source: rtkit > Version: 0.12-4 > Severity: normal > > Hi Felipe, > > today I was investigating why an update of systemd (v244) was blocked by > a failing autopkgtest in rtkit from testing migration. > > When trying to investigate the issue, I could reproduce the failure with > both systemd v243 and v244 locally. So I assume it's the rtkit > autopkgtest which is flaky since [1] shows autopkgtest passing. > I've attached logs for both sid and bullseye. > The tests are run on Debian sid. > I can't reproduce the failures. How are you running the tests? -- Saludos, Felipe Sateler
Bug#924260: Csound: regression in diskgrain stretch->buster when file sr != orchestra sr
On Sun, Mar 10, 2019, 14:18 Sam Hartman wrote: > package: csound > severity: important > justification: Stretch regression with no work around without code > changes > version: 1:6.12.2~dfsg-3 > tags: patch, fixed-upstream, upstream > > Hi. In https://github.com/csound/csound/issues/1119 > I reported an issue. > > In stretch, if you want to deal with a file that doesn't match the > orchestra sample rate in diskgrain, you have to do all the work in your > orchestra. > Between stretch and buster upstream tried to improve it but got a couple > of things wrong: > > * Most seriously, they handle the initial file seek according to the > orchestra sr not the file sr. So there will be a jump of > uncontrollable length when the first file buffer is exausted. > > * They scale the pitch but not the pointer read rate, so the orchestra > still has to know about the gap. > > This is fixed in f23c45efcef upstream. > I confirmed that code change works against the upstream code base and > the Debian code base. > Thanks for such a thorough bug report. I think this is self-contained enough to warrant a stable upload. One thing that needs checking is if the move of find_file.h has any impact. I would suggest not applying that part just to be safe. Another thing to check would be if syncgrain and syncloop need a similar change, as noted by Victor. > > I'd like to try and get an unblock to get this into buster. I want your > support obviously before trying to do that. I'm happy to do everything > (prepare a package; upload; file an unblock), simply write the unblock > justification, sit back and let you deal, or accept that you don't think > this is worth trying to get an unblock for. > My justification for the unblock is that it's a well-constrained change, > something that is possible in stretch is entirely impossible in the > current buster code, and there is an easy fix. > Please go ahead. The change looks small enough. I'm currently away so I'm going to be of limited assistance, but please feel free to go ahead. Help is always appreciated. Saludos, Felipe Sateler
Bug#916066: csound regression: zir opcode appears entirely broken; hangs instrument
Control: tags -1 confirmed upstream Control: forwarded -1 https://github.com/csound/csound/issues/1088 On Sun, Dec 9, 2018 at 4:03 PM Sam Hartman wrote: > > I was experiencing strange failures with orchestras with csound 6.12 and > eventually I've tracked it down to the zir opcode to read a value from > zk-space at i-time. > Ouch! I have forwarded the issue upstream. Hopefully it will be fixed soon. > Interestingly, Debian doesn't seem to be shipping zir.csd or really most > of the examples. > We used to, as I got them somewhere, and they're really useful. > I'm not seeing any license problems, so it would be cool if we either > shipped them or documented why not. Do you have csound-doc installed? It's there, at least in html form. Do you want the examples in csd form? -- Saludos, Felipe Sateler
Bug#916047: csound: regression in String handling
Control: tags -1 upstream confirmed Control: forwarded -1 https://github.com/csound/csound/issues/1087 On Sun, Dec 9, 2018 at 1:54 PM Sam Hartman wrote: > I noticed that my orchestras were failing on several sound files after > upgrading to buster, and tracked it down to some cases of filenames > being input in the score file. Ouch! I have forwared the bug upstream. Hopefully it will be fixed soon. In the meantime, you can work around the bug by avoiding filenames which match /[nm][ \t]+/ -- Saludos, Felipe Sateler
Re: fluidsynth 2.0
(Sorry, this seems to have gotten stuck in the drafts folder) On Fri, Oct 26, 2018 at 5:05 AM Bodo Meißner wrote: > Hello Felipe, > > thanks for the hint. > > Zitat von Felipe Sateler : > > > I think the more relevant question is whether version 2.0.0 introduced > any > > backwards-incompatible change. > > According to the documentation, version 2.0.0 introduced incompatible > API changes, not only adding new functions. > Bummer. Hopefully the API changes don't impact everyone. > > If so, then it probably needs fixing in all > > reverse dependencies before it can be updated. > > For the binary library this can probably be handled by installing both > libfluidsynth1 and libfluidsynth2 packages. > Right. > > Is there a way to handle incompatible and conflicting > libfluidsynth-dev versions? > For example source package A build-depends on libfluidsynth-dev > <2.0.0, source package B and build-depends on libfluidsynth-dev >= > 2.0.0? > Until now I didn't find information about this topic. Links to related > documentation are welcome. > But does it make any sense to keep both versions? Does fluidsynth upstream plan to continue supporting both? > Or does this mean that all packages that build-depend on > libfluidsynth-dev would have to be changed to use version >= 2.0.0? > I think this is the more viable option. The number of packages is not large (I see 24), and many are maintained here in this team. I think the first step would be to prepare a package targeting experimental, see how much stuff fails to build and how hard it is to fix. With that info, it can be decided if it's best to keep both or port all apps to version 2.0. -- Saludos, Felipe Sateler
Re: fluidsynth 2.0
Hi On Thu, Oct 25, 2018, 07:21 Bodo Meißner wrote: > Hello Multimedia team, > > is there a plan to add packages for fluidsynth version 2.0.x? (current > version is 2.0.1) > > In version 2.0.0 the API function fluid_player_seek() and related > functions were added to libfluidsynth. This function is used by music > players to start at a specific position in the score. > I think the more relevant question is whether version 2.0.0 introduced any backwards-incompatible change. If so, then it probably needs fixing in all reverse dependencies before it can be updated. If not, then it is just a matter of updating the package. I'm sure patches for that are very welcome ;) Saludos
Bug#881342: stretch update for rtkit
On Wed, Mar 14, 2018 at 2:35 PM, Adrian Bunk wrote: > On Wed, Feb 21, 2018 at 03:24:08PM +, Debian Bug Tracking System wrote: > >... > > rtkit (0.11-6) unstable; urgency=medium > > . > >* Move dbus and polkit from Recommends to Depends > > rtkit can't do much really without either of them so bump them to > Depends. > > (Closes: #881342) > >... > > Thanks a lot for fixing this bug for unstable. > > It is still present in stretch, could you also fix it there? > Alternatively, I can fix it for stretch if you don't object. > I'd be happy if you do. I'm currently suffering from ENOTIME so I'm not likely to get around to doing that soon. -- Saludos, Felipe Sateler
Re: Proposed multimedia team migration to salsa.d.o
On Mon, Jan 1, 2018 at 2:43 PM, James Cowgill wrote:
> Hi,
>
> As you've probably seen, the Debian Gitlab instance salsa.debian.org is
> up and running (in beta). Since alioth.debian.org is deprecated and
> might be disabled soon, we need to migrate things over to salsa.
>
Agreed.
>
> This is what I propose. I posted it on IRC, but for more discussion I'm
> posting it to the mailing lists now.
>
> salsa.debian.org team
> ===
> A group on salsa.debian.org has been created here:
> https://salsa.debian.org/multimedia-team
>
> Existing members of the alioth team have not been migrated over which
> should help prune inactive members. Anyone who was a member of the
> alioth team can click the "Request Access" button and an someone will
> approve you.
>
> Usually, team members who are DDs are given "Owner" permissions in the
> group and other members are given "Master" permissions.
>
I have no problem with this rule. We can revisit later if needed.
> When creating a new project:
> * The project name should be the same as the source package name.
>
This is the same policy as currently, so no change here.
> * "Issues" should be disabled (use the BTS instead).
>
This has been done by default on salsa. So new projects will get issues
disabled by default.
> * A commit notification hooks should be setup (see below).
>
> New Vcs-* URLs:
>
> ```
> Vcs-Git: https://salsa.debian.org/multimedia-team/package.git
> Vcs-Browser: https://salsa.debian.org/multimedia-team/package
> ```
>
> https://lists.debian.org/debian-devel-announce/2017/12/msg3.html
> https://wiki.debian.org/Salsa/Doc
>
> New maintainer address
> ===
> There is not going to be a replacement for alioth mailing lists, so we
> are going to switch back to using "debian-multimedia@lists.debian.org"
> as the mailing list used in the Maintainer field of all packages.
>
> https://lists.debian.org/debian-devel-announce/2017/09/msg4.html
OK with me.
>
> Commit notifications
> ===
> The commit mailing list is also on alioth and will soon be disabled.
> This is replaced by the "Emails on push" integration on salsa which
> sends emails to tracker.debian.org which you can subscribe to. This
> needs to be enabled manually per project.
>
> See: https://wiki.debian.org/Salsa/Doc#Email_notifications
>
> IRC notifications can be enabled using Irker. Again this needs to be
> enabled manually per project.
>
> See: https://wiki.debian.org/Salsa/Doc#IRC_notifications
>
> Automation
> ---
> Enabling these should probably be automated and checked using the GitLab
> API because inevitably someone will forget to enable it in a repository.
>
> Eg for "Emails on push":
>
> https://docs.gitlab.com/ee/api/services.html#emails-on-push
> ```
> curl -X PUT -H "Private-Token: $GITLAB_API_PRIVATE_TOKEN" -F
> "recipients=dispatch+${package}_...@tracker.debian.org"
> https://salsa.debian.org/api/v4/projects/multimedia-team%
> 2F${package}/services/emails-on-push
> ```
>
> Migration
> ===
> Migration of the maintainer email address can start immediately. New
> packages can also immediately start hosting their VCS on salsa.debian.org.
>
> For existing packages, I propose:
> - Wait until salsa.debian.org is declared stable (expected at the end of
> January)
> - Announce to the lists before migration starts
> - Set all repositories on alioth read-only (eg using a git pre-receive
> hook)
> - Migrate everything to salsa using Christoph Berg's import script:
> http://www.df7cb.de/blog/2017/Salsa_batch_import.html
We can add the email on push + irker notifications to the script here.
> At this point we should attempt to upload all packages at least once
> before the mailing list on alioth is disabled. Unfortunately this is a
> lot of work, so I am quietly hoping there will be an alternative
> solution for this so we don't loose bug reports sent to the old
> maintainer address.
>
It appears some people are working on providing a replacement for the
alioth lists, as a stop-gap for a release cycle or so:
https://lists.alioth.debian.org/pipermail/alioth-staff-replacement/Week-of-Mon-20171225/90.html
--
Saludos,
Felipe Sateler
Re: Package Cinelerra not in Debian
On 26 October 2016 at 23:15, Humberto Hassey wrote: > Hello Guys, I am very surprised that Cinelerra is not in the Debian reops, > it is the only serious video editing software out there. > > Are there any plans on including it on Debian or is there a problem that is > preventing it from happening? There have been previous attempts to package it[1]. Unfortunately, it appears nobody has been able to complete the work. In particular, it appears the licensing status is not fully clear. Maybe you can step up to become the maintainer? You are more than welcome to join us at the multimedia team to do so. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=331072 -- Saludos, Felipe Sateler
Re: kodiplatform_16.0.0-1_i386.changes is NEW
On 11 September 2015 at 12:24, Debian FTP Masters wrote: > binary:libkodiplatform-dev is NEW. > binary:libkodiplatform16 is NEW. > source:kodiplatform is NEW. I just realized this has debian-multimedia@ as Maintainer. This should be changed to pkg-multimedia-maintainers@. -- Saludos, Felipe Sateler
Re: Demo music in Debian?
On Sat, Nov 29, 2014 at 2:53 PM, W. Martin Borgert wrote: > Some days ago, I helped a young colleague to install Debian. > At some point, they asked themself, whether the sound card worked. > They started the default music player application in Gnome, but > there was nothing to try. When one buys a telephone or a mobile > music player, it comes with some demo sound files to try it, > before having to copy files to it. Not so Debian. Usually I do a locate '*.wav' to find wav files, or go to youtube if it is a desktop. If none are found, you can use any of the games in debian that have sound as well. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAfdZj_e=bf=hddxx3y12e0uvj2a408_0vtyny00cyl4br5...@mail.gmail.com
Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.
On Sat, Nov 22, 2014 at 8:51 AM, Andreas Cadhalpun wrote: > Hi, > > On 22.11.2014 10:11, Fabian Greffrath wrote: >> >> I have two more ideas regarding this issue: >> >> 1) We have two library packages that conflict with each other. Why don't >> we have two -dev packages that conflict with each other, then? >> >> I suggest to introduce a new libavcodec-extra-dev package that depends >> on "libavcodec | libavcodec-extra" and change the libavcodec-dev package >> to only depend on the regular libavcodec. The shlibs need to get >> adjusted accordingly, of course. >> >> This way, maintainers have a means to consider the possible license >> clash at build time and we dont have to juggle conflicts with virtual >> packages. > > > That's a nice idea, but just as the shlibs.local method, it doesn't work in > all cases. See my previous example of libkfilemetadata4, which would still > have the problem, because it only indirectly depends on libavcodec (via > libavformat) and thus can't change the libavcodec dependency. I believe what is missing is that libav*-dev should all depend on libavcodec-dev | libavcodec-gpl2-dev. Then it can just fine build-depend on "libavformat-dev, libavcodec-gpl2-dev" > >> 2) There seem to be only very few packages which are at risk of a >> license clash when the libavcodec-extra package is installed. However, >> we currently treat this as the rule, not the exception. > > > The problem here is that it might seem to affect only few packages, but > nobody has really looked, so we can't know. In particular, it's hard to > verify that none of the libraries (indirectly) linked are GPL v2 only. Of course, this cannot be done for jessie. But for jessie + 1 if the change is done early, this gives plenty of time for maintainers to adjust. > >> I suggest to turn the situation around and provide the GPLv3 codecs in >> the regular libavcodec package. For the few package for which this could >> impose a license problem, we should provide an extra GPLv2 package. >> >> >> So, together with my first proposal this would result in the following >> package situation: >> >> libavcodec-dev depends libavcodec | libavcodec-gpl2 >> libavcodec-gpl2-dev depends libavcodec-gpl2 >> libavcodec provides all codecs, even the gpl3-compatible ones >> libavcodec-gpl2 provides only the gpl2-compatible codecs >> libavcodec-extra* is no more >> >> What do you think? > > > Before enabling the GPL v3 codecs by default someone would have to check all > reverse dependencies, whether they would be compatible. That means not only > to check for GPL-2 only in all reverse-dependencies, but also in their > linked in libraries and if any of the more exotic licenses of some (parts) > of them would indirectly imply GPL-2 only. I would propose the following transition plan: Step 1: libavcodec-dev depends on libavcodec-gpl2-dev Step 2: Ping all rdeps maintainers with this change. Step 3: swap the dependencies of libavcodec-dev I would also add that libavcodec-gpl2-XY should Provide: libavcodec-gpl2 (ie, an unversioned name) so that packages that conflict with gpl3 can do so easily by depending on the virtual package. Or alternatively do similarly with libavcodecXY providing libavcodec-gpl3 and making packages Conflict with that virtual package. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAfdZj-gqoBzCzZ2_S9HbxQ+4PScnHTwL12rv8Y2Wh=gvko...@mail.gmail.com
Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.
On Fri, Feb 21, 2014 at 12:15 AM, shirish शिरीष wrote: > Lastly, is there a possibility of having a metapackage so people could > have all of it in one go ? Codecs, video player, the works. > > something like :- > > $ apt-get install debian-multimedia If you do find some packages that improve decoding over just installing vlc or totem (as described by Fabian), we could add them to the multimedia-players metapackage, which is quite empty at this time. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caafdzj8uygqtku9wasslds87r_d_w4csb0crpkwbz-bzm5h...@mail.gmail.com
Re: [GSoC] blends-dev new implementation, files needed in debian-multimedia, git permissions
On Wed, Sep 18, 2013 at 3:57 PM, Emmanouil Kiagias wrote: > Hello everyone, Hi Emmanouil, > > My name is Emmanouil Kiagias and I am working with Andreas Tille on Redesign > metapackage creation for Debian Blends[0] GSoC Project. This project will > replace the current blends-dev package (mainly the blend-gen-control > script). > > One new feature of blends-dev provides an automatic changelog entry which > dumps the packages differences between the latest and the previous release > of a Blend into the debian/changelog file (track added/removed packages > between releases). To achieve that we save for each Blend release a json > file which contains the package dependencies (taken from the task files) > under a dependency_data/ directory (this directory should exist into the > Blend root directory). Then we compare the json files for two releases and > we dump the differences into the debian/changelog. > > For the moment I committed to every Blend the needed files so when we > replace the current blends-dev package with the new, we can be sure that no > errors will occur due to missing json files. > > In debian-multimedia Blend case I do not have the permissions to the git > repository so I can't make the commit myself. So can you add me as a member > so I can make the commit(my alioth name is ekiagias-guest)? I have added you to the project, welcome! -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8ac4QritTCYq_50ivyD=yhwi0zh+nf9vchhpgpr2m...@mail.gmail.com
Re: Patch for tasks files (Was: Please consider maintaining Blends information)
Hi Andreas, On Mon, May 27, 2013 at 7:19 AM, Andreas Tille wrote: > Hi Felipe, > > On Mon, Apr 15, 2013 at 12:50:12PM -0300, Felipe Sateler wrote: >> > Would you consider adjusting ACLs to pkg-multimedia to enable write >> > permissions for any DD as described here[1]. I'd be interested in >> > fixing some technical details in the tasks in the future without beeing >> > forced to become a member of multimedia team. >> >> I've submitted a support ticket to alioth, at >> https://alioth.debian.org/tracker/?func=detail&group_id=1&aid=314215&atid=21 >> >> No response yet, though... > > I can confirm that it does not yet work. :-( > > So please consider the patch below with the following log entry: Applied and pushed. Thanks and sorry for the delay! -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caafdzj_5ulla9dnmomjrgi9katmn6qbj4kuntfr2fj4esjn...@mail.gmail.com
Re: Debian multimedia blend
On Thu, May 23, 2013 at 5:51 AM, Andreas Tille wrote: > Hi, > > I hope a lot of you will join DebConf! > > On Wed, May 22, 2013 at 11:22:48AM -0400, Felipe Sateler wrote: >> Well, lets see how this evolve. Hopefully users will give us enough >> feedback to make them really useful. > > To enhance this feedback I have registered an event for DebConf: Unfortunately I'm not going to DebConf... I think I can still participate remotely? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj-_BHSEDQ+3N=Pr4JFc-7PF01ij6yNh094z=iuhgkp...@mail.gmail.com
Re: Debian multimedia blend
On Fri, May 24, 2013 at 11:57 AM, rosea.grammostola wrote: > On 05/22/2013 11:35 PM, rosea.grammostola wrote: >> >> On 05/22/2013 05:22 PM, Felipe Sateler wrote: >>> >>> On Mon, May 20, 2013 at 5:17 PM, Andreas Tille wrote: >>>> >>>> On Mon, May 20, 2013 at 11:12:20PM +0200, Holger Levsen wrote: >>>>> >>>>> Hi Felipe (and others, I guess), >>>>> >>>>> On Montag, 20. Mai 2013, Felipe Sateler wrote: >>>>>> >>>>>> They are currently in the NEW queue, should reach unstable soon. >>>>>> The metapackage names are: >>>>> >>>>> [sniped] >>>>> >>>>> cool! I'm too curious how this will turn out! But a new Debian >>>>> multimedia >>>>> blends seems like a great idea! Thanks for your work on this! >>>> >>>> >>>> +1 >>> >>> >>> Well, lets see how this evolve. Hopefully users will give us enough >>> feedback to make them really useful. >> >> >> These packages and subdirs are a good starting point. Linuxaudio is >> transforming every day, so I think a lot has to change in the different >> meta-packages. >> >> The biggest recent changes imo in linuxaudio is >> >> a) release of Ardour3 (with midi support) >> b) release of Non-Session-Manager (NSM) >> >> >> Point a means that LV2 plugins are more and more important for mixing >> and using virtual softsynths/instruments. LV2 plugins are listed in the -audio-plugins package. >> >> Point b gives revival to the 'one-task-one-tool-approach' in the audio >> area. It should be in Debian as soon as possible (new release is coming >> within a few weeks) >> http://non.tuxfamily.org/ Lets hope someone packages it. I'm too short on time to do it myself. >> >> It might be good to have a 'NON' metapackage with Non-Timeline, >> Non-Mixer, Non-Sequencer and Non-session-manager. I don't think so. I think metapackages should relate to tasks, not suites. That means that each non application should go in the relevant task rather than create a non metapackage. >> >> You want the NSM supported apps in Debian and likely in the >> metapackages. An NSM metapackage like you've for ladi, might be good >> too: http://non.tuxfamily.org/wiki/ApplicationsSupportingNsm I'm not quite sure of the usefulness of the ladi task, to be honest. >> >> I think 'audio-plugins' should be 'softsynths or virtual instruments'. >> >> Then you've to think about where to put the LV2 and DSSI plugins. >> Special metapackage or in one of the existing ones (mixing/softsynths) >> You've LV2 plugins for mixing and LV2 plugins as softsynths/virtual >> instruments. I'm not sure I understand what you mean. How do you propose to split the audio-plugins task? >> >> I think I would remove the timestretching package, you'll find it in >> your DAW normally (Ardour/Qtractor). Yes, it can probably be folded into the audio-plugins task. > I've edit the tasks, it should be more 'state-of-the-linuxaudio-art' now. > Use it if you like. I'll review them and incorporate changes, thanks! Not today, though. > > Note, some packages are not in Debian yet! But I think they're important for > the future of linuxaudio in Debian: > > - Ardour3 > - non-mixer http://non.tuxfamily.org/ > - non-timeline > - non-session-manager > - non-sequencer > - carla http://kxstudio.sourceforge.net/KXStudio:Applications:Carla > - calfbox (free alternative for linuxsampler SFZ sampler, > http://repo.or.cz/w/calfbox.git) > - lisaloqt (frontend for calfbox) Well, they are not in debian because they have not been packaged yet (except for ardour3 I think). Lets hope we can bring in more developers to package all these interesting applications! -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caafdzj9k40tsqgrovvpufonzap7-6g7cfci7yhxrgm0f8az...@mail.gmail.com
Re: Debian multimedia blend
On Mon, May 20, 2013 at 5:17 PM, Andreas Tille wrote: > On Mon, May 20, 2013 at 11:12:20PM +0200, Holger Levsen wrote: >> Hi Felipe (and others, I guess), >> >> On Montag, 20. Mai 2013, Felipe Sateler wrote: >> > They are currently in the NEW queue, should reach unstable soon. >> > The metapackage names are: >> [sniped] >> >> cool! I'm too curious how this will turn out! But a new Debian multimedia >> blends seems like a great idea! Thanks for your work on this! > > +1 Well, lets see how this evolve. Hopefully users will give us enough feedback to make them really useful. > As promised I will care for the web sentinel featuring these tasks as > soon as possible (<= 48h). Great! > > Many thanks for working on this and your nice enhancements (bug reports) > to blends-dev. > > BTW, any DD has commit permissions to Blends VCS so you can even commit > your patches directly. OK, but my perl fu is rather disappointing, so I'd rather pass patches through review ;) -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8BSPD40fxMNCTz33fV+38FKGKuTNO=ol7omtffomb...@mail.gmail.com
Re: Debian multimedia blend
On Mon, May 20, 2013 at 1:21 PM, rosea.grammostola wrote: > On 05/20/2013 07:17 PM, Felipe Sateler wrote: >> >> On Mon, Apr 8, 2013 at 1:28 AM, Felipe Sateler wrote: >>> >>> I'm hesitant to actually build and upload the metapackages >> >> >> I've just uploaded them today. I expect/hope to get a lot of feedback >> on how inappropriate they are ;). >> >> Any comments/improvements are appreciated >> > > Nice. > What's the name of the packages and where can we find them? They are currently in the NEW queue, should reach unstable soon. The metapackage names are: multimedia-ambisonics multimedia-audio-plugins multimedia-devel multimedia-djing multimedia-drums multimedia-firewire multimedia-graphics multimedia-guitar multimedia-jack multimedia-ladi multimedia-looping multimedia-midi multimedia-mixing multimedia-musiciantools multimedia-players multimedia-samplers multimedia-soundsynthesis multimedia-timestretching multimedia-video -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj-F2z1MBvFfp2O_3fPA-5Rsak=vvjro_suiy6vc+8r...@mail.gmail.com
Debian multimedia blend
On Mon, Apr 8, 2013 at 1:28 AM, Felipe Sateler wrote: > I'm hesitant to actually build and upload the metapackages I've just uploaded them today. I expect/hope to get a lot of feedback on how inappropriate they are ;). Any comments/improvements are appreciated -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8v-N4XobN7dKfGc2oMhKx=elu1amugvb2ncaondku...@mail.gmail.com
Re: Please consider maintaining Blends information (Was: Bullet Physics Library)
On Mon, Apr 8, 2013 at 5:53 PM, Andreas Tille wrote: > Hi Felipe, > > Would you consider adjusting ACLs to pkg-multimedia to enable write > permissions for any DD as described here[1]. I'd be interested in > fixing some technical details in the tasks in the future without beeing > forced to become a member of multimedia team. I've submitted a support ticket to alioth, at https://alioth.debian.org/tracker/?func=detail&group_id=1&aid=314215&atid=21 No response yet, though... -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj-_96UDJPqmMszOu8tA8T6PRQw8Vnjq4YKRbqXr0P=_...@mail.gmail.com
Re: Please consider maintaining Blends information (Was: Bullet Physics Library)
On Wed, Mar 20, 2013 at 1:29 PM, Felipe Sateler wrote: > Rosea, would you like to bring the multimedia-related tasks into > debian? We can bring them into the pkg-multimedia git area. I have copied the tasks and did a few changes, nothing too important. Renamed the tasks to multimedia-*, merged a few tasks and deleted some I didn't consider useful for us to maintain. I have imported the git repository into the team area, it is available at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/multimedia-blends.git I'm hesitant to actually build and upload the metapackages before the release, but we can still improve the definitions before doing that. Any help is appreciated. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8w+QvwmW3=povRTtaaed++Vw=rowdwju8s0tobyfk...@mail.gmail.com
Re: Please consider maintaining Blends information (Was: Bullet Physics Library)
On Wed, Mar 20, 2013 at 6:33 PM, Andreas Tille wrote: > On Wed, Mar 20, 2013 at 01:29:49PM -0300, Felipe Sateler wrote: >> > As you can see the Blends tools can even work on foreign Git >> > repositories and you might negotiate with Rosea whether he might like to >> > lead / join / guide this effort. >> >> Indeed, there are several useful tasks. Some are not within the domain >> of the pkg-multimedia team, though (the desktop or fluxbox tasks, for >> example). > > This is actually no problem. A Blend is not a collection of packages > maintained by team members. A Blend is rather a collection of packages > useful for a certain task and the Blends team picks the needed things > from the package pool - whoever might maintain the single packages. I understand. However, I meant that some tasks don't have much to do with multimedia, and thus don't really fit within the Multimedia Blend scope. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj-smmPm7+FUZ4qHbbiC7SiGamX_5z=q_hsgvue+qc1...@mail.gmail.com
Re: Please consider maintaining Blends information (Was: Bullet Physics Library)
On Wed, Mar 20, 2013 at 12:14 PM, Andreas Tille wrote: >> On Tue, Mar 19, 2013 at 5:10 AM, Andreas Tille wrote: >> >> > The same is perfectly valid for Debian Multimedia: Last change was done >> > at 2011-07-27 (by fsateler)[4] and those both teams are missing a really >> > big chance to get new users / developers by failing to drive by the >> > Debian Wheezy release notes which is regarded by a large user base all >> > over the world. IMHO it is your choice to tell the world: >> > >> > Hey, there are people inside Debian who care about Games / Multimedia >> > and we have all this cool stuff for you. Debian wants to be one of >> > the big distributions in this field. >> > >> > or you can keep on doing your admitedly fine technical work in your >> > teams which are really studious but shyly hidden inside the large >> > package pool of Debian with 30k packages. >> >> Indeed. Unfortunately, we haven't been able to properly leverage the >> blends tools. I wonder how can we find people willing to help out on >> this? I've been thinking of asking in the upstream user lists for >> people that might be interested in helping out defining usable >> metapackages, but I haven't done it yet. Any other ideas? > > Well, I can only tell from my experience: It is not promising just to > talk about the things that should be done. You rather need to do things > yourself and make it popular. You will make mistakes or forget things > and people will give hints how to fix this. You should try to approach > to get something out that makes some sense for the moment. > > If I were you I would definitely go together with Rosea Grammostola who > has created his own metapackge layout at > >https://github.com/johnsen/meta-blends > > which is even rendered at my test-server: > >http://blends.debian.net/meta-blends/tasks/ > > So there *is* somebody who does reasonable work and I'd regard this > more reasonable than > >http://blends.debian.net/multimedia/tasks/ > > which is more or less my poor work according to SVN - sometimes due to > some hints from here. And I would try really hard to verify if it might > make sense to start from scratch with a 1:1 copy of Rosea's work. The > rationale behind this advise is that you need to start with something > that is actually *used* in practise rather than some academic example > created by some poor outsider (as I consider myself). > > As you can see the Blends tools can even work on foreign Git > repositories and you might negotiate with Rosea whether he might like to > lead / join / guide this effort. Indeed, there are several useful tasks. Some are not within the domain of the pkg-multimedia team, though (the desktop or fluxbox tasks, for example). Rosea, would you like to bring the multimedia-related tasks into debian? We can bring them into the pkg-multimedia git area. Here are some comments as to the tasks that we could bring back: Openstudiopro-admin: Outside pkg-multimedia domain (OD) Openstudiopro-ambisonics: Within doman (WD), but possibly could be merged into other tasks Openstudiopro-composing: WD Openstudiopro-desktop: OD Openstudiopro-devel: OD Openstudiopro-djing: WD Openstudiopro-beat: WD Openstudiopro-firewire: WD Fluxbox: OD Openstudiopro-graphics: Not quite sure, but possibly WD Openstudiopro-guitar: WD Openstudiopro-jack: WD Openstudio-ladi: WD, possibly should be merged with -jack Openstudiopro-looping: WD Openstudiopro-midi: WD Openstudiopro-mixing: WD Openstudiopro-multimedia: WD, could possibly use a better name Openstudiopro-muse2build: OD Openstudiopro-musician: WD Openstudiopro-muscicnotation: WD Openstudiopro-plugins-dssi: WD Openstudiopro-plugins-fst: WD Openstudiopro-plugins-ladspa: WD Openstudiopro-plugins-lv2: WD, all these plugins-* tasks could be merged? Openstudiopro-realtime: Not quite sure, AFAIK a realtime kernel is not needed these days Openstudiopro-recording: WD Openstudiopro-samplers: WD Openstudiopro-soundsynthesis: WD Openstudiopro-synths: WD, could be merged with soundsynthesis Openstudiopro-timestretching: WD, could be merged into plugins? Openstudiopro-trackers: WD Openstudiopro-video: WD -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj9KT0Z1TDcLo0BcTj+U63f4+SU78b=c7x9a-knaemw...@mail.gmail.com
Re: Please consider maintaining Blends information (Was: Bullet Physics Library)
Hi Andreas, others. (dropping the games list and bug since this doesn't really concern them). On Tue, Mar 19, 2013 at 5:10 AM, Andreas Tille wrote: > The same is perfectly valid for Debian Multimedia: Last change was done > at 2011-07-27 (by fsateler)[4] and those both teams are missing a really > big chance to get new users / developers by failing to drive by the > Debian Wheezy release notes which is regarded by a large user base all > over the world. IMHO it is your choice to tell the world: > > Hey, there are people inside Debian who care about Games / Multimedia > and we have all this cool stuff for you. Debian wants to be one of > the big distributions in this field. > > or you can keep on doing your admitedly fine technical work in your > teams which are really studious but shyly hidden inside the large > package pool of Debian with 30k packages. Indeed. Unfortunately, we haven't been able to properly leverage the blends tools. I wonder how can we find people willing to help out on this? I've been thinking of asking in the upstream user lists for people that might be interested in helping out defining usable metapackages, but I haven't done it yet. Any other ideas? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj-3V+G_2A01prxdJ6T_-vM_HytV3_=4JY7fUjt=euj...@mail.gmail.com
Re: Presentation + A debian-based for audio creation and production, stage technics and video blend (or "the future of TangoStudio")
On Thu, Nov 22, 2012 at 5:00 AM, Aurélien Roux wrote: > Hi! > > Been kind of mute this last days. I didn't give up about it, but I had to > think about it, read some doc (a lot actually, in the bunch of links you all > gave me!! thanks ;) ), and check things with some friends. > > So, to keep you updated, after some reflexion, here is what I decided to > try: > > - First, contributing by (trying to) packaging the non-quadrilogy. The main > developper told me there already was a bug report against WNPP, so I'll > begin at the following step. If this works (i.e. if non-quadrilogy enters > Debian), and so on, I will ask to join debian-multimedia as a maintainer for > this suite, at least, If you need help, you can ask in the developers list (this one is the user list). We will be happy to help. http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers > > - Second, try to build my first basic meta-package, and see what it gives, > and how it works (I'm not really clear with it now, but probably because I > never did something like this. > > - Third, try to build several meta-packages, like multi-tracks recording, > electro-music environnment, live-music environnment (these are prospectives > things, I didn't think about it in terms of meta-packages at the beginning, > so I've got to think about it a bit more). My goal is to have at least one > ready for next summer (2013), but my schedule are quite stretched so hope > it's going to be possible. I think this should really be through the Debian Pure Blends, it is about time we had a few blends for multimedia. It is very easy to define them, the hard part is to choose which packages to include. Doing the metapackages by hand will probably be a lot of wasted time and energy. > > - Fourth, which is not from Debian side, the AMMD (the label/artists > cooperative I work in) will propose an iso of Debian with preseed, and so > on, so that people that wants a "out-of-the-box" thing like TangoStudio is > by now, will have something. As this point is the very one about which there > is absolutely non consensus, I think getting it out of Debian might be a > good solution. But it will be a Debian, still, but with some pre-chosen > options, and easy-to-install steps. Having the metapackages ready will certainly help with this. > > > I might not be so present on the list for the upcoming days/weeks. I'm sure > mailing-lists are a useful tool, but participating might turn in a huge > time-eater activity, and I often prefer to read-only, and participate less. > If you're on the LAD, LAU, FFADO mailing-lists, you may have not noticed > that I subscribed! > > All the best. > Aurélien > > PS : when coming to the second step, as I'm pretty sure I want to do it (or > even *need*), I'm still not so sure I'm the best skilled to drive such a > thing, so don't hesitate to come along with me! For this it is a good idea to keep your progress visible, and inform about it periodically, naybe someone will be tempted to go and help if you do that! -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8+5erbOq3vUeSPm=0xoihy-rx4u8k63xfnttph5u_...@mail.gmail.com
Re: List of required packages.
On Fri, Sep 7, 2012 at 8:54 PM, Weaver wrote: > > On Fri, September 7, 2012 1:57 pm, Felipe Sateler wrote: >> Hi, >> >> On Fri, Sep 7, 2012 at 4:13 PM, Weaver wrote: >>> Hello, >>> >>> I have always had a problem getting video to work on Debian. >>> >>> I run Unstable, with all the multimedia urls in /etc/apt/sources.list. >>> I have installed all recommended packages, including libdvdcss2, with no >>> joy. >>> >>> I've Googled till my eyes are out of my head. >>> >>> I've been to the Debian-Multimedia site, but can find no recommended >>> list >>> of packages. I have no more luck with Mplayer or Mplayer2 than I have >>> with >>> any of the players. >>> >>> As an idea to what might be missing, using GXine, by opening the file >>> manager and selecting specific packages, I can get them to play - audio >>> only. >> >> The debian multimedia team is not related to that site, and using it >> can cause breakage in your computer. Please remove that site from your >> sources.list, and remove all the packages coming from there, >> installing the debian versions. > > Ummm, there are no 'Debian Versionjs' of libdvdcss2, or a number of other > necessary packages. Yes, we are still missing dvdcss. Which other packages do you need? > > However, in order to help we are going >> to need more information: >> >> 1. What sort of videos? DVDs? > > HD DVDs. > > Downloaded videos from internet? Youtube? > > This is not a problem. > Standard browser plug-ins take care of those, but different packages, like > ligdata take care of those. > All gstreamer packages are installed also. It's just the DVD scenario > presenting problems. > >> 2. What output do you get from the video players when trying to play them? > > A few different ones that turn up on a regular basis, relating to the > demuxer and plug-in deficits, which is why I am enquiring for a list of > required packages. It is very hard to help if you do not provide the needed information. Please post the output from your video player. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj_EfMnC=zpml2g1oep7xmqksufrkejoh3squfovlso...@mail.gmail.com
Re: List of required packages.
Hi, On Fri, Sep 7, 2012 at 4:13 PM, Weaver wrote: > Hello, > > I have always had a problem getting video to work on Debian. > > I run Unstable, with all the multimedia urls in /etc/apt/sources.list. > I have installed all recommended packages, including libdvdcss2, with no joy. > > I've Googled till my eyes are out of my head. > > I've been to the Debian-Multimedia site, but can find no recommended list > of packages. I have no more luck with Mplayer or Mplayer2 than I have with > any of the players. > > As an idea to what might be missing, using GXine, by opening the file > manager and selecting specific packages, I can get them to play - audio > only. The debian multimedia team is not related to that site, and using it can cause breakage in your computer. Please remove that site from your sources.list, and remove all the packages coming from there, installing the debian versions. However, in order to help we are going to need more information: 1. What sort of videos? DVDs? Downloaded videos from internet? Youtube? 2. What output do you get from the video players when trying to play them? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caafdzj_75kviqpp4q4q4wpk+np88dwj-e-qwnt+3n0nsthf...@mail.gmail.com
Re: Joining the team
On Fri, Sep 7, 2012 at 11:46 AM, Ho Wan Chan wrote: > Hello. Hello Howard (I'm CCing you because I don't know if you are suscribed). > > I'm Howard Chan and I want to join the Debian Multimedia Team. > > As a contributor towards Ubuntu Studio, I want to learn more about > packaging. So please consider my application. Great! Please read our wiki page[1], especially the DevelopPackaging section, and subscribe to the developers list (this is the user list, but there is not much user traffic...). What do you have in mind to contribute? Any particular packages you want to contribute to? [1] wiki.debian.org/DebianMultimedia -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8NxW4-V6-ZvRP_+T3=zoqlhfdsor1dwvof8ygcaop...@mail.gmail.com
Re: Jackd2 - Pulseaudio negotiation failing
On Sun, Aug 19, 2012 at 12:11 PM, frederic rech wrote: > >> >> most people on the list uninstall PA... But there's a possibility that >> Jack >> & PA can live together, have you follow the howto here : >> >> http://jackaudio.org/pulseaudio_and_jack > > Hmm, will try option 3, redirecting via pulseaudio-module-jack. Lets > see how that goes... > > > >>> Please let the list know -F It works! I followed the instructions in the jack wiki[1], and it works. The only problem is volume management: I need to access the alsa mixer directly via alsamixer to manipulate the volumes (it was muted by default which confused me a bit). Is it possible to trick the gnome applet into manipulating the hardware mixer instead of the pulseaudio mixer? [1] http://trac.jackaudio.org/wiki/WalkThrough/User/PulseOnJack -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj8SOWpvqxiMc4=UH9q3i=md_u33uap4bscny5_o5rs...@mail.gmail.com
Re: Jackd2 - Pulseaudio negotiation failing
On Sun, Aug 19, 2012 at 2:39 AM, frederic rech wrote: > > Hi Felipe, > > most people on the list uninstall PA... But there's a possibility that Jack > & PA can live together, have you follow the howto here : > > http://jackaudio.org/pulseaudio_and_jack Hmm, will try option 3, redirecting via pulseaudio-module-jack. Lets see how that goes... -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj_tK=nseqspa4mbpuz7qpa-uzfah9ujrsmnln2viq9...@mail.gmail.com
Jackd2 - Pulseaudio negotiation failing
Hi, I can't seem to get jack to negotiate the sound card with pulseaudio. I'm getting the following error: Sat Aug 18 21:22:41 2012: control device hw:0 Sat Aug 18 21:22:41 2012: control device hw:0 Sat Aug 18 21:22:41 2012: [1m [31mERROR: Failed to acquire device name : Audio0 error : Method "RequestRelease" with signature "i" on interface "org.freedesktop.ReserveDevice1" doesn't exist [0m Sat Aug 18 21:22:41 2012: [1m [31mERROR: Audio device hw:0 cannot be acquired... [0m Sat Aug 18 21:22:41 2012: [1m [31mERROR: Cannot initialize driver [0m Sat Aug 18 21:22:41 2012: [1m [31mERROR: JackServer::Open failed with -1 [0m Sat Aug 18 21:22:41 2012: [1m [31mERROR: Failed to open server [0m After killing pulseaudio jack works OK. Any ideas? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj9xwy+2=apoteeumllje0twqo7nhek8dwock9kw59e...@mail.gmail.com
Re: /usr/bin/qjackctl and pasuspender on Wheezy
On Tue, May 29, 2012 at 2:26 PM, Adrian Knoth wrote: > On 05/29/2012 08:19 PM, Felipe Sateler wrote: > >>> I realize, if wanting to use pulseaudio-module-jack, you don't want PA to >>> get suspended. But what if you uninstall it, or disable d-bus in qjackctl >>> (in effect starting jackd instead of jackdmp)? >> >> I've never installed pulseaudio-module-jack, but from what I >> understand it is not very useful, since pulseaudio is much higher >> latency than jack. > > > pulseaudio-module-jack is cool. You have jackd running on the real > soundcard and then use pulseaudio-module-jack to bridge to consumer > apps, that is, to make jackd the audio backend for pulseaudio. > > Works like a charm over here, mplayer, flash and basically everything > that is not jack is playing via pulseaudio and pulseaudio-module-jack to > the permanently running jackd. A pretty popular setup AFAIK. Aha, looks like it works the other way around then. I thought it was plugin for making jack output to PA. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caafdzj8uk5x-x5x1qzk5pvuq_b4betinqkilesyx9nomtzt...@mail.gmail.com
Re: /usr/bin/qjackctl and pasuspender on Wheezy
I'm not an expert in JACK, so hopefully someone will correct me if I'm wrong... On Tue, May 29, 2012 at 12:52 PM, Kaj Ailomaa wrote: > > Not being a scripting wizard, I'm not able to understand how > /usr/bin/qjackctl works. > > Is PA supposed to be suspended at some point? Only if you have jackd2 with dbus support (like the jackd2 package in debian). > I can't figure out if it is because of /usr/bin/qjackctl at any point. AFAIK, no. It is the jack daemon that negotiates the sound card with PA, qjackctl just starts and stops it. This information is all based on last time I tried automatic negotiation, which was a while ago. If PA is already using the sound card (say, your mp3 player is running), the negotiation will fail and PA will not let jackd have control of the sound card. In other words, jack asks "pretty please, can I have the sound card?", and PA decides wether to do it or not. > > I realize, if wanting to use pulseaudio-module-jack, you don't want PA to > get suspended. But what if you uninstall it, or disable d-bus in qjackctl > (in effect starting jackd instead of jackdmp)? I've never installed pulseaudio-module-jack, but from what I understand it is not very useful, since pulseaudio is much higher latency than jack. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAfdZj_ddZBzVj8i+f1kD6B6wXhmy2a0FdyR2npXJTBVDFii=a...@mail.gmail.com
Re: Remaining packages with debian-multime...@l.d.o as maintainer:
On Mon, Nov 15, 2010 at 11:48, Alessio Treglia wrote: > FYI, all the packages listed above have been imported into our git area. > > Enjoy! :) Please upload them so that we don't get bugs in the now-for-users list during the squeeze cycle. Or will debbugs be ssmart enough if we change it after the release? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiku6ef+5fddedaisesywxqmpzby74ft1p55_...@mail.gmail.com
Re: Bits from the Debian Multimedia team
On Mon, Nov 8, 2010 at 03:46, Andreas Tille wrote: > Hi, > > I would be really happy if discussion which is not directly packaging > related would be done on debian-multime...@lists.debian.org. > Indeed, we should start using the list if we want others to use it. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikhnieyofjtgyrcwx36vgttaiipgi7jeaijf...@mail.gmail.com
Re: Remaining packages with debian-multime...@l.d.o as maintainer:
On Tue, Nov 9, 2010 at 07:29, Gürkan Sengün wrote: > On 11/09/10 11:13, Andreas Tille wrote: >> >> On Tue, Nov 09, 2010 at 09:08:43AM +0100, G??rkan Seng??n wrote: >>> >>> If debian-multimedia is not interested in those. I will definitely keep >>> maintaing them, since I also use those. So I'll just remove >>> debian-multimedia >>> from the Uploaders with the next upload... >> >> I think this is a misunderstanding: Debian Multimedia as a team is >> definitely interested (as well in the package as in team maintenance). >> However, the list address should be >> >> Debian Multimedia Packages >> Maintainers > > So I'll with the next upload, put this into the Maintainers field, and > myself > to uploaders, did I get it right, now? And please move/create/import the repository into the team's git area. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin-vx=rxj-utnzrcft2gxs=otsogw_gobekj...@mail.gmail.com
Remaining packages with debian-multime...@l.d.o as maintainer:
(Gürkan, Joost, Romain, Paul and Willem, you are CCed because I don't know if you are subscribed to either of the lists. Some background you may have missed: we want to repurpose debian-multimedia@lists.debian.org as a user oriented list, so we need to get rid of references to it in packages). With my current sid system, there are the following packages with debian-multime...@l.d.o as the Maintainer: fusd-kor gigedit gmerlin ll-scope openmovieeditor rev-plugins sineshaper stops vco-plugins vkeybd Of those, gigedit is the only one with a valid git repository in our team area (vkeybd has an empty one). It even has an upload to experimental. Reading back old discussions, it seems that: Jonas has an interest in vkeybd, but probably forgot about it (that would explain the empty repository). Jonas also cares about openmovieeditor. Alessio should probably care about stops, because aeolus depends on it (ping?). Uploaders of the other packages, do you still care about these packages? They have seen little or no activity lately. You are welcome to join us at the new team [1]. So, I propose we file O: bugs about all the other packages (I volunteer to do that), and people who care about the packages import them into the git area if not done already. I will wait 2 weeks before starting orphaning them, in case someone wants to take them. Also, the following packages have debian-multime...@l.d.o in the Uploaders field: freecycle goattracker milkytracker ocp Gürkan, you are maintainer in all of them. If you want, you can join us and maintain them within our team. Otherwise, please remove the reference to the debian-multimedia@lists.debian.org in those packages. [1] wiki.debian.org/DebianMultimedia -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=ymcyk=x8nh2xsw4dpi8uydndhbcy7pacew...@mail.gmail.com
Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
On Sat, Oct 30, 2010 at 11:36, Andreas Tille wrote: > On Thu, Oct 28, 2010 at 08:34:38PM -0300, Felipe Sateler wrote: >> Since we need to advertise this list, I think we should do a Bits From >> our team. I have started a draft in >> http://wiki.debian.org/DebianMultimedia/BitsFrom, so please add >> anything you think we should be saying. > > That's a really good idea. I have enhanced the Blends paragraph a bit. > Once this bits are published I probably will unsubscribe the packaging > list (so please at least CC me in Blends related subjects) and subscribe > rather the general list. Please, people, add whatever you think is important to the above wiki page. In particular, I think the consumer side needs some real info in there. Maybe Reinhardt or Fabian can add something there? All other people are encouraged to add their view on what we have done too! -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikg6cxh8komgujcc2tv+sd3lerpvos+h1uqe...@mail.gmail.com
Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
ne* (not only discussed). If > you ask me, it should be done *before* Squeeze release. Even if we > will probably not able to release metapackages (we did not even decided > whether we want them at all - see below) - we can mention DeMuDi in the > release notes of Squeeze anyway. If not - we are simlpy missing a chance > to get attention of a wide public. I wholeheartedly agree with this. I will try to start modifying the tasks (they are a good base). I've added a new task, hopefully others can help too (I think we have too many, maybe we should merge some of them). > > 4. Metapackages > I'm in favour of creating metapackages because they have certain > advantages > and they at least do not harm. Those who do not like this stuff will not > install it - that's fine. As long as we don't have point 3, this one is moot. > > 5. Debtags > The DebTags technique should be used more heavily in Blends (see for > instance > [9]). I do not mind what comes first: Designing Debtags for multimedia > packages and proper debtagging for *all* relevant packages or defining > tasks, putting the packages in and use the tasks pages for enabling proper > DebTagging. IMHO the latter approach is more simple and can be easier > done. Once the DebTagging is done properly we might be able to decide > about means how to create tasks from DebTags. In any case we have to *do* > something - nothing comes from sit and wait. I don't really care much about debtags. They are inconsistent, little used and even less policed. > > That are my concerns about DeMuDi. I admit the point in time for such a mail > is not really well choosen because I'll be offline from tomorrow to 30. > October > (MiniDebConf in Paris). I'll give a Blends talk at this MiniDebConf and I > would like to say something about DeMuDi - I hope it will be more than this > kind of TODO list. There is at least one commit that is not by you now :p -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim=sbsfaaydnqmd3kofc1qwea9xvdnwrtofv...@mail.gmail.com
Bug#530852: Upgrading severity
severity 530852 serious severity 530859 serious severity 571961 serious thanks A changed liblo has been uploaded, thus bumping severity. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8a0bda451003020737h43234ccev6d13d0ed50bbe...@mail.gmail.com
Re: closing down debian-multimedia alioth project and l.d.o list?
On Thu, 2009-12-03 at 21:40 +0100, Holger Levsen wrote: > Hi, > > On Donnerstag, 3. Dezember 2009, Eric Dantan Rzewnicki wrote: > > Maybe it shouldn't. (?) Activity has pretty much entirely moved to > > pkg-multimedia-maintain...@lists.alioth.debian.org > > Ah, I wasnt aware of that. I sthere an archive? Yes, http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/ -- Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part
Bug#556392: jackeq does not start
reassign 556392 libjack0 retitle 556392 Please ship libjack0.100.0.so.0 compatibility link thanks Daniel Vidal wrote: Hi Arch is i386... I see on my old machine (etch upgraded to lenny) and libjack-0.100.0.so.0 is a link to another libjack shared library (that also is a link to another library)... I think this link is break on my installation... i must review this... I read the content files on libjack-0.100 package (etch, lenny...) and in etch this file is a real file, not a link... this is my mistake... Perhaps this link is created in the installation of new versions of libjack-0.100.0. Hmm, the link is lost on sid and squeeze. I think we should put it back in the libjack0 package. I think you can close the bug... This deserves a bit more discussion, I think. Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556392: jackeq does not start
Daniel Vidal wrote: Package: jackeq Version: 0.4.1-1 When invoke "jackeq" from konsole it does not start with this message jackeq: error while loading shared libraries: libjack-0.100.0.so.0: cannot open shared object file: No such file or directory This library only can be found on etch version of libjack0.100.0-0... not in lenny... not in squeeze... not in sid... i think this app must be removed from debian versions lenny squeeze and sid... or modified to not use this library I'am using Debian 5.0, kernel 2.6.29.4 RT SMP PREEMPT What architecture? My amd64 contains the correct libjack.so.0 reference. -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: JACK2 package naming convention
Adding pkg-multimedia to the loop. On Fri, 2009-09-25 at 12:40 +0100, Daniel James wrote: > Hi all, > > I have built some JACK2 (1.9.3) debs for Lenny, and Ubuntu Hardy and > Jaunty, based on the Debianization by Nedko Arnaudov. However some users > still want to use JACK1 versions (such as 0.116.2), pointing out that > some features are not yet fully available in JACK2. For instance, > FireWire audio interface support through FFADO, see: > > http://subversion.ffado.org/ticket/234#comment:1 > > As JACK2 is a ground-up rewrite, is there a case for Debian/Ubuntu > packages being named differently from JACK1 packages so that users have > a choice about which to install or use? > > Cheers! > > Daniel > > -- Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part
Re: Update for liblo package on Debian
On Mon, 2009-09-07 at 11:09 +0200, Robert Jordens wrote: > Hi Matthias, > > On Fri, Sep 4, 2009 at 9:31 PM, Matthias Klumpp wrote: > > I package some applications for Ubuntu and Debian which need a newer > > version of liblo than it is available in Debian. > > Would it be possible to update the liblo package on Debian to fix #509330? > > We had a discussion on the bug report for Ubuntu that week and already > > updated the package: > > https://bugs.launchpad.net/ubuntu/+source/liblo/+bug/255360 > > So could you update the package in Debian too, please? This would be great! > > I'd suggest putting liblo into debian-multimedia's care. > Anyone interested in packaging 0.26? I have already packaged it, and it failed to go through new last time. I have been busy since then, but I expect to find time soon (next couple of weeks) to finally get this through. You are welcome to try out the package in the git repository in the meantime (and report any issues with it as well) at http://git.debian.org/?p=pkg-multimedia/liblo.git -- Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part
Bug#530859: sineshaper: build-depends on versioned liblo0-dev
Package: sineshaper Version: 0.4.2-4 Severity: minor User: pkg-multimedia-maintain...@lists.alioth.debian.org Usertags: drop-liblo0-dev sineshaper build-depends on liblo0-dev (>= 0.18). That version is already satisfiable even in oldstable, so the version can be dropped. liblo0-dev will soon be a package provided by liblo-dev, so sineshaper will FTBFS when that package is uploaded. Dropping the versioning should be enough to fix this. I will bump the severity to serious when the new liblo is uploaded. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530852: rosegarden: build-depends on versioned liblo0-dev
Package: rosegarden Version: 1.7.3-1 Severity: minor rosegarden build-depends on liblo0-dev (>= 0.7). That version is already satisfiable even in oldstable, so the version can be dropped. liblo0-dev will soon be a package provided by liblo-dev, so rosegarden will FTBFS when that package is uploaded. Dropping the versioning should be enough to fix this. I will bump the severity to serious when the new liblo is uploaded. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522150: amsynth: Depends on libjack0.100.0-0
El 29/04/09 01:03 Adeodato Simó escribió: > + Felipe Sateler (Tue, 28 Apr 2009 21:03:45 +1000): > > Hello, Felipe. > > > El 19/04/09 17:54 Adeodato Simó escribió: > > > I note that the Debian Multimedia Team is listed as the maintainer for > > > amsynth. Could some member of the team make an upload? amsynth is the > > > last package holding the dropping of libjack0.100.0-0, which if I’m not > > > mistaking is a goal of yourselves. :-) > > > > > > But I’m tracking it myself as well, so it’d be great to have it off my > > > plate at some point. Or let me know if I should stop tracking it. > > > > The package got already uploaded, so it is probably too late by now. > > Thanks for keeping track of this! I think it is OK for you to drop this > > transition from your tracklist, since it is probable that the new jack > > will wait until a new upstream release before a new upload. > > > > Once again, thanks for keeping this on your mind! I'm sorry for not > > letting you know earlier that the jack package would not get uploaded yet > > (I'm not one of the people most involved with that package, I just > > announced the transition). > > I see. Well, nevermind: all packages have been rebuilt, and amsynth > uploaded as you hinted, so there is no package left depending on > libjack0.100.0-0 in unstable (and soon in testing), which means you can > remove the libjack0.100.0-0 transitional package at your convenience, be > it an upload only for that, or as part of a new upstream version, or > whatever. > > I'm not sure what the status regarding the development package is, but I > think I gave clear instructions on how that change should be pursued. I > won't be tracking that, though. Do not worry about that, I will take care of it. As soon as the jack people are ready to upload a version dropping the -0 transitional package, I will follow your instructions and drop in a separate upload (allowing for migration to testing) the -0-dev package, and making the -dev Provide the transitional package. I will file minor (or serious in the case of versioned build-depends) bugs against all affected packages and eventually drop the Provides. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#522150: amsynth: Depends on libjack0.100.0-0
El 01/04/09 22:06 Daniel James escribió: > Hi Felipe, > > > The Debian Multimedia Maintainers will be dropping libjack0.100.0-0 > > soon, so you should switch to using upstream's default name. Changing > > libjack0.100.0-0 to libjack0 in debian/control and dropping > > debian/patches/80_libjack.dpatch should be enough. > > Unfortunately not in the longer term, there is a more serious bug that > amsynth does not work with JACK 2 at all (for example, the current > upstream 1.9.2 release of JACK). > > I have contacted the upstream author of amsynth about this, but it seems > the application would need a partial re-write, as the way it currently > opens JACK ports is non-standard. For the short run it doesn't matter, because jack2 is not going to be in debian soonish, and we are transitioning from versioned jack packages to unversioned ones, so this should be fixed anyways. BTW, where can I find information on jack2? I can't find anything other than the source tarball in jack's webpage. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#522150: amsynth: Depends on libjack0.100.0-0
Package: amsynth Version: 1.2.0-3.2 Severity: normal The Debian Multimedia Maintainers will be dropping libjack0.100.0-0 soon, so you should switch to using upstream's default name. Changing libjack0.100.0-0 to libjack0 in debian/control and dropping debian/patches/80_libjack.dpatch should be enough. This bug's severity will be raised to severity serious when the updated jack is uploaded to unstable. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages amsynth depends on: ii libasound2 1.0.19-1shared library for ALSA applicatio ii libatk1.0-0 1.24.0-2The ATK accessibility toolkit ii libc62.9-6 GNU C Library: Shared libraries ii libcairo21.8.6-2+b1 The Cairo 2D vector graphics libra ii libcairomm-1.0-1 1.6.4-1 C++ wrappers for Cairo (shared lib ii libgcc1 1:4.3.3-5 GCC support library ii libglib2.0-0 2.20.0-2The GLib library of C routines ii libglibmm-2.4-1c2a 2.20.0-1C++ wrapper for the GLib toolkit ( ii libgtk2.0-0 2.14.7-4+b1 The GTK+ graphical user interface ii libgtkmm-2.4-1c2a1:2.14.3-2 C++ wrappers for GTK+ 2.4 (shared ii libjack0.100.0-0 0.116.1-4 JACK Audio Connection Kit (librari ii libpango1.0-01.22.4-2Layout and rendering of internatio ii libsigc++-2.0-0c2a 2.0.18-2type-safe Signal Framework for C++ ii libsndfile1 1.0.19-2Library for reading/writing audio ii libstdc++6 4.3.3-5 The GNU Standard C++ Library v3 amsynth recommends no packages. amsynth suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#458660: Still unreproducible here
El 26/12/08 03:10 Felipe Sateler escribió: > Can you reproduce it with 2.7.1-2? BTW, I ask because your logs show that the build hanged in a library that is no longer being built, namely soundtouch. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: RT prio settings and much more
El 11/03/09 23:38 Daniel James escribió: > Hi Raffaele, > > > I can't go in deep about debian packages accept/reject workflow and > > policy stuff but non-free repository should allow some compromise in > > these direction... > > It wasn't about free versus non-free (for once), it was that Ardour > developers were forced to embedded their own forked versions of > libraries, because upstream authors had not applied patches that Ardour > needed to function properly. > > Some Debian developers decided this was unacceptable, as a matter of > policy - result: no Ardour in Lenny. I don't think that's a win for Debian. This is not completely true. Ardour embedded many libraries that could easily be stripped out: they were just convenience copies. AFAIK, libsndfile was the only one that needed to be patched. Indeed, said bug about embedded code copies is already fixed and closed, and ardour has not migrated yet to testing. Why? Because of another Release Critical bug, #458660. So far this bug has been difficult to reproduce, so any help in diagnosing this bug would be appreciated. I think this bug should be fixed now that we don't build the embedded libraries, but need confirmation. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: how can I contribute?
El 09/01/09 13:56 Grammostola Rosea escribió: > Daniel James wrote: > > Hi Rosea, > > > >> Can I invite more people to join the Debian-multimedia team and > >> improve Debian for music production? > >> Do you need more people to contribute? > > > > I think help is always welcome. I think it's a question of finding the > > right tasks for the right people though. Debian welcomes experienced > > developers, but the barrier for entry is still high. > > > > Debian itself doesn't have much infrastructure for users to help other > > users, apart from mailing lists. In the 64 Studio project we > > have some forums for this purpose: http://www.64studio.com/forum > > On what kind of system do you need to build the packages for Debian > multimedia? I am running a Debian testing/ unstable mix right now You should build packages in unstable. You can accomplish this with a chroot if you don't want to move to unstable. See the pbuilder and cowbuilder packages. BTW, you may want to check http://wiki.debian.org/DebianMultimedia/Merge Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#458660: Still unreproducible here
Can you reproduce it with 2.7.1-2? Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#446405: marked as done (ardour: Embeds too many libs)
Attached is a revised syslibs patch that should get rid of soundtouch and
rubberband. Also attached is an interdiff of the two patches.
Saludos,
Felipe Sateler
Index: ardour/SConstruct
===
--- a/SConstruct 2008-12-25 13:18:49.0 -0300
+++ b/SConstruct 2008-12-25 16:39:46.0 -0300
@@ -504,8 +504,8 @@
libraries['core'] = LibraryInfo (CCFLAGS = '-Ilibs')
-#libraries['sndfile'] = LibraryInfo()
-#libraries['sndfile'].ParseConfig('pkg-config --cflags --libs sndfile')
+libraries['sndfile-ardour'] = LibraryInfo()
+libraries['sndfile-ardour'].ParseConfig('pkg-config --cflags --libs sndfile')
libraries['lrdf'] = LibraryInfo()
libraries['lrdf'].ParseConfig('pkg-config --cflags --libs lrdf')
@@ -533,6 +533,12 @@
else:
env['AUBIO'] = 0
+libraries['vamp'] = LibraryInfo ()
+libraries['vamp'].ParseConfig('pkg-config --cflags --libs vamp-sdk')
+
+libraries['vamphost'] = LibraryInfo ()
+libraries['vamphost'].ParseConfig('pkg-config --cflags --libs vamp-hostsdk')
+
env = conf.Finish ()
if env['FFT_ANALYSIS']:
@@ -862,18 +868,15 @@
# these are part of the Ardour source tree because they are C++
#
-libraries['vamp'] = LibraryInfo (LIBS='vampsdk',
- LIBPATH='#libs/vamp-sdk',
- CPPPATH='#libs/vamp-sdk')
-libraries['vamphost'] = LibraryInfo (LIBS='vamphostsdk',
- LIBPATH='#libs/vamp-sdk',
- CPPPATH='#libs/vamp-sdk')
-
env['RUBBERBAND'] = False
conf = Configure (env)
-
-if conf.CheckHeader ('fftw3.h'):
+if env['SYSLIBS']:
+libraries['rubberband'] = LibraryInfo()
+libraries['rubberband'].ParseConfig('pkg-config --cflags --libs rubberband')
+libraries['rubberband'].Append( CCFLAGS = [ '-DUSE_RUBBERBAND' ] )
+env['RUBBERBAND'] = True
+elif conf.CheckHeader ('fftw3.h'):
env['RUBBERBAND'] = True
libraries['rubberband'] = LibraryInfo (LIBS='rubberband',
LIBPATH='#libs/rubberband',
@@ -1089,10 +1092,6 @@
# cannot use system one for the time being
#
-libraries['sndfile-ardour'] = LibraryInfo(LIBS='libsndfile-ardour',
-LIBPATH='#libs/libsndfile',
-CPPPATH=['#libs/libsndfile/src'])
-
#libraries['libglademm'] = LibraryInfo()
#libraries['libglademm'].ParseConfig ('pkg-config --cflags --libs libglademm-2.4')
@@ -1112,11 +,9 @@
]
subdirs = [
-'libs/libsndfile',
'libs/pbd',
'libs/midi++2',
'libs/ardour',
-'libs/vamp-sdk',
'libs/vamp-plugins/',
# these are unconditionally included but have
# tests internally to avoid compilation etc
@@ -1165,9 +1162,6 @@
libraries['soundtouch'] = LibraryInfo(LIBS='soundtouch',
LIBPATH='#libs/soundtouch',
CPPPATH=['#libs', '#libs/soundtouch'])
-libraries['sndfile-ardour'] = LibraryInfo(LIBS='libsndfile-ardour',
-LIBPATH='#libs/libsndfile',
-CPPPATH=['#libs/libsndfile', '#libs/libsndfile/src'])
#libraries['libglademm'] = LibraryInfo(LIBS='libglademm',
# LIBPATH='#libs/libglademm',
# CPPPATH='#libs/libglademm')
@@ -1182,11 +1176,9 @@
subdirs = [
'libs/sigc++2',
-'libs/libsndfile',
'libs/pbd',
'libs/midi++2',
'libs/ardour',
-'libs/vamp-sdk',
'libs/vamp-plugins/',
# these are unconditionally included but have
# tests internally to avoid compilation etc
@@ -1249,9 +1241,12 @@
# timestretch libraries
#
-timefx_subdirs = ['libs/soundtouch']
-if env['RUBBERBAND']:
-timefx_subdirs += ['libs/rubberband']
+if env['SYSLIBS']:
+timefx_subdirs = []
+else:
+timefx_subdirs = ['libs/soundtouch']
+if env['RUBBERBAND']:
+timefx_subdirs += ['libs/rubberband']
opts.Save('sc
Re: What to do for new packages
El 18/12/08 14:24 Free Ekanayaka escribió: > |--==> On Thu, 18 Dec 2008 13:55:20 -0300, Felipe Sateler said: > >>* commit messages are copied to both pkg-multimedia-commits@ and the > >>PTS for the relevant package. The former results then in a very busy > >>mailing list but if one is interested only in a specifc package he > >>can just subscribe to the PTS. > > FS> I just setup this, and I have a problem: the list is members only. > I'm not FS> sure how to deal with this, since I don't think most people > will want to FS> suscribe to the commits list. Specially sporadic > contributors. We should FS> either whitelist mail sent from alioth (is this > possible?), allow non-members FS> posts, or don't send mail there at all. > > If possible I would go for whitelist-ing mail sent from alioth, > mailman should support it, check Privacy Options -> Sender filters > in the list's administrative interface. I worked around this by making the script send the mail from the users.alioth.debian.org address of the pusher instead of the committer's address. So, when creating the repository, use the setup-repository script that will take care of this. BTW, Free, I added you to the project. Welcome :) Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: What to do for new packages
El 17/12/08 16:29 Reinhard Tartler escribió: > Felipe Sateler writes: > > El 26/11/08 12:27 Felipe Sateler escribió: > >> OK, so I'm about to co-maintain liblo, which is an OSC library, and can > >> be considered a multimedia package (csound, rosegarden and ardour are > >> some "big" packages using it). > >> So... I want to bring it under the scope of the teams-to-become-one. I > >> have imported the sources into a git repository. demudi already has a > >> git area enabled in alioth, pkg-multimedia doesn't. Should I use the > >> demudi area? What list should I put in the Maintainer field? > >> Given that pkg-multimedia is more active maybe we should it? > > > > So what's the conclusion on this? Since pkg-multimedia doesn't have a git > > repository I just pushed my changes to the demudi git area. I'm still not > > clear on which mailing list to use yet. The poll didn't have much > > participation, and ended up in a 3:2 win for pkg-multimedia. > > Yeah, good idea. Feel free to correct me, but if nobody objects about > this very small win, I'd suggest this: > > * maintainer is set to >pkg-multimedia-maintain...@lists.alioth.debian.org > > * discussion happens on that list as well > > * pkg-multimedia gets an git repository (Felipe, please request one and >start moving the packages. btw, is it possible to redirect the old >locations to the new ones? - I don't think so, but you never know) > > * packages formerly in svn are being migrated on a best efford basis >without a fixed deadline. > > * commit messages are copied to both pkg-multimedia-commits@ and the >PTS for the relevant package. The former results then in a very busy >mailing list but if one is interested only in a specifc package he >can just subscribe to the PTS. I just setup this, and I have a problem: the list is members only. I'm not sure how to deal with this, since I don't think most people will want to suscribe to the commits list. Specially sporadic contributors. We should either whitelist mail sent from alioth (is this possible?), allow non-members posts, or don't send mail there at all. > > These points should be seen as proposed clarification to > http://wiki.debian.org/DebianMultimedia/Merge I put these and Free's suggestions into that page. I also copied the setup-script from collab-maint and modified it a bit for our purposes. PS: I think we can stop CCing each other, it's pretty clear we all read the lists. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#446405: marked as done (ardour: Embeds too many libs)
package ardour
found 446405 1:2.7.1-1
thanks
This upload doesn't actually fix this, there is a typo in debian/rules:
diff --git a/debian/rules b/debian/rules
index c57613c..b20eafa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -62,7 +62,7 @@ DEB_SCONS_EXTRA_FLAGS := \
NLS=yes \
FREEDESKTOP=no \
$(NJOBS) \
- SYLIBS=yes
+ SYSLIBS=yes
DEB_SCONS_NOOPT_FLAGS := DEBUG=no FPU_OPTIMIZATION=no
ifneq (,$(findstring amd64,$(DEB_BUILD_ARCH)))
Note that even enabling that option there are some externally available
libraries installed:
% dpkg -c ../ardour_2.7.1-1_amd64.deb| awk '{print $6}' | \
grep /usr/lib/ardour2/.
./usr/lib/ardour2/libardour_cp.so
./usr/lib/ardour2/librubberband.so
./usr/lib/ardour2/libsndfile-ardour.so
./usr/lib/ardour2/libgtkmm2ext.so
./usr/lib/ardour2/libvampsdk.so
./usr/lib/ardour2/libardour.so
./usr/lib/ardour2/ardour-2.7.1
./usr/lib/ardour2/libpbd.so
./usr/lib/ardour2/engines/
./usr/lib/ardour2/engines/libclearlooks.so
./usr/lib/ardour2/vamp/
./usr/lib/ardour2/vamp/libardourvampplugins.so
./usr/lib/ardour2/libmidi++.so
./usr/lib/ardour2/surfaces/
./usr/lib/ardour2/surfaces/libardour_mackie.so
./usr/lib/ardour2/surfaces/libardour_powermate.so
./usr/lib/ardour2/surfaces/libardour_genericmidi.so
./usr/lib/ardour2/libsoundtouch.so
./usr/lib/ardour2/libvamphostsdk.so
soundtouch, rubberband and vamp* seem to be available in Debian.
Saludos,
Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
Re: What to do for new packages
El 17/12/08 16:29 Reinhard Tartler escribió: > * pkg-multimedia gets an git repository (Felipe, please request one and >start moving the packages. btw, is it possible to redirect the old >locations to the new ones? - I don't think so, but you never know) I requested a git repository. I don't know what you mean by redirecting the old locations to the new ones, could you explain please? Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: What to do for new packages (was: Multimedia Teams in Debian)
El 26/11/08 12:27 Felipe Sateler escribió: > OK, so I'm about to co-maintain liblo, which is an OSC library, and can be > considered a multimedia package (csound, rosegarden and ardour are some > "big" packages using it). > So... I want to bring it under the scope of the teams-to-become-one. I have > imported the sources into a git repository. demudi already has a git area > enabled in alioth, pkg-multimedia doesn't. Should I use the demudi area? > What list should I put in the Maintainer field? > Given that pkg-multimedia is more active maybe we should it? So what's the conclusion on this? Since pkg-multimedia doesn't have a git repository I just pushed my changes to the demudi git area. I'm still not clear on which mailing list to use yet. The poll didn't have much participation, and ended up in a 3:2 win for pkg-multimedia. While I don't really care which list to use, we should use the resources of only one project, I guess (ie, if we are going to use pkg-multimedia we should create a git area for it). I can ask for the git area to be created if you want. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
El 01/12/08 05:36 Reinhard Tartler escribió: > (did you mail me in private on purpose? if not, feel free to quote > anything in this mail in public) Oops, no, that was an accident. Replying to list now for completeness sake. > > Felipe Sateler <[EMAIL PROTECTED]> writes: > > El 30/11/08 15:07 Reinhard Tartler escribió: > >> >> > Note that upstream releases need not be official. You can tag in > >> >> > your local copy some point in history as upstream/x.y.z+somedate, > >> >> > and use that as the upstream release. > >> >> > >> >> Ugh. And why and when should we do that? > >> > > >> > For the same reasons you take a particular snapshot any time. It just > >> > saves you the hassle of manufacturing a tarball and importing it into > >> > a "fake" upstream branch. > >> > >> I cannot imagine any case when I would have wanted to do that. could you > >> perhaps name examples? Maybe I just don't understand this point, but it > >> doesn't seem too important to me either. > > > > Snapshots are useful when a bug has been fixed upstream, and the > > backporting is not trivial. Usually this would happen only when the > > bugfix is very invasive, involves license issues and/or upstream doesn't > > release frequently. > > These are all cases that don't happen that frequently, right? > > > In that case, all you would have to do is: > > > > git tag -s upstream/version $commit > > git checkout master > > git merge upstream/version > > # update changelog, patches, etc > > git-buildpackage > > > > git-buildpackage will find the tag by itself and create the .orig.tar.gz > > for you. > > Interesting. We should document this in some sort of tool knowledge base > on the team wiki pages. But not as first point but rather under the > "when things become tricky"-section. This can be done later on, when need arises. > > >> >> Would that make it rather difficult for upstream to know what changes > >> >> we have done in the package? > >> > > >> > I worded it badly. The tag would be present in the debian git > >> > repository, and as such it would be public. Also, upstream doesn't > >> > need to care about this, since we would still be using quilt patches > >> > that can be mailed to them. Also, if upstream is tracking the debian > >> > branch, merge points are stored, so upstream knows precisely which > >> > point in time you snapshotted. > >> > >> upstream would still have the hassle to understand git and the way we > >> use git. I'd prefer to save them this efford unless we have good reasons > >> to do so. > > > > Ehmm, that's what the quilt patches are for. If upstream wants to track > > debian, they can track the git repository. If they don't, you submit the > > quilt patches. Note that this workflow would only make much sense if > > upstream is already using git and you are tracking their master branch in > > your upstream branch. > > I was talking about the corner case you were sketching out > before. Upstream would have *additionally* have to know what *release* > we are using. and if we are using some "self-released" snapshot version > of upstream's VCS, upstream still would have to know what exact snapshot > we have used. Ideally this comes from the version number but that might > not work in some cases and upstream might want to verify that our idea > of the snapshot version matches upstream's. In principle this calls for > some ways to verify to "upstream" snapshot mechanism. This is > > a) trivial if know our workflow an are familiar to git > b) cumbersome if you don't use git. > > upstream's that don't use git fall into category b). We as team of > course fall in category a). > > I really don't want to make such a fuzz about it, we have already > stressed this point way too much. all I want to say is that upstream > snapshot taking is something we should rather avoid. If it becomes > necessary, we need to properly document and communicate how we are doing > it in a verifyable way to upstream. That's all. Indeed. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
El 30/11/08 04:32 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > > There's also git-cvsimport, which I used for a while. However, the import > > stage is very slow, since it is done over the net. Subsequent updates are > > very slow too (unless one keeps the cvsimport updated very frequently). > > The problem is that one has to checkout every point in history, making it > > very slow for relatively large projects. > > in order to speed up the whole thing, I'd recommend rsync'ing the cvs > repository to localhost first and then run the conversion. That's how we > tracked the OpenBSD CVS in git in a project I've worked previously on. Yes, but that requires me to remember to do that :). The point was that doing this requires more effort than it's worth, if upstream does releases frequently. > > >> > In the case of ffmpeg, where there are no released tarballs, it would > >> > make sense to directly track the git repository (ie, the upstream > >> > branch is a clone of upstream's master branch). > >> > >> The particular problem with ffmpeg is that upstream uses svn externals > >> to track the 'libswscale' subdirectory. The upstream git repository even > >> leaves that directory out completely. I haven't found a better way to > >> track upstream than what we currently have as the current > >> get-orig-tar.sh, but I'm open for improvements on that. > > > > Hmm, this is strange. I assume libswscale can't easily be built > > independently of ffmpeg, or that would be done, am I right? What > > motivation has upstream for doing this? > > libswscale is historically developed in the mplayer svn, ffmpeg has more > or less integrated that in their own tree (well, it is optional but has > more features than the internal scaler). It has no standalone > buildsystem, but integrates cleanly in both the ffmpeg and mplayer build > system. > > The sanest way would be to move the libswscale repository back to > ffmpeg. That however would break bisecting, so they insist on rewriting > the ffmpeg svn repository so seamlessly integrate the development > history. This is a tedious job Diego is working for over a year on. Ehm, I'm not sure I understand this. Moving the libswscale repository back to ffmpeg would break bisecting of libswscale, you mean? And Diego is trying to retrofit libswscale's history into ffmpeg's? > > >> > In either case, "upstream" releases should be tagged (eg, > >> > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff > >> > is not a diff against upstream's tip, but against these tags. > >> > >> If we track "upstream releases" (which I think we should do by default > >> unless there are compelling reasons not to do so, see the ffmpeg > >> example), indeed! > > > > Note that upstream releases need not be official. You can tag in your > > local copy some point in history as upstream/x.y.z+somedate, and use that > > as the upstream release. > > Ugh. And why and when should we do that? For the same reasons you take a particular snapshot any time. It just saves you the hassle of manufacturing a tarball and importing it into a "fake" upstream branch. > Would that make it rather > difficult for upstream to know what changes we have done in the package? I worded it badly. The tag would be present in the debian git repository, and as such it would be public. Also, upstream doesn't need to care about this, since we would still be using quilt patches that can be mailed to them. Also, if upstream is tracking the debian branch, merge points are stored, so upstream knows precisely which point in time you snapshotted. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
El 29/11/08 17:41 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > >> For point 1: How often do you "snapshot" upstream? Every upstream commit > >> of their VCS or only upstream releases? What to do with upstreams that > >> don't do commits in years? (think ffmpeg, toolame). > > > > In our case, we track upstream releases only, but only because it doesn't > > make much sense to do otherwise[1]: csound uses CVS (ugh), thus making it > > painful to track it directly. > > for cvs, there is cvs2svn, which can export in a format compatible to > git-fast-import. Therefore AFAIUI it should be pretty easy to track the > upstrem cvs with git. > > I'm not suggesting (yet) to do that. I think it only makes sense if we > had a large set of patches that we want to get upstream. There's also git-cvsimport, which I used for a while. However, the import stage is very slow, since it is done over the net. Subsequent updates are very slow too (unless one keeps the cvsimport updated very frequently). The problem is that one has to checkout every point in history, making it very slow for relatively large projects. > > > In the case of ffmpeg, where there are no released tarballs, it would > > make sense to directly track the git repository (ie, the upstream > > branch is a clone of upstream's master branch). > > The particular problem with ffmpeg is that upstream uses svn externals > to track the 'libswscale' subdirectory. The upstream git repository even > leaves that directory out completely. I haven't found a better way to > track upstream than what we currently have as the current > get-orig-tar.sh, but I'm open for improvements on that. Hmm, this is strange. I assume libswscale can't easily be built independently of ffmpeg, or that would be done, am I right? What motivation has upstream for doing this? > > > In either case, "upstream" releases should be tagged (eg, > > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff > > is not a diff against upstream's tip, but against these tags. > > If we track "upstream releases" (which I think we should do by default > unless there are compelling reasons not to do so, see the ffmpeg > example), indeed! Note that upstream releases need not be official. You can tag in your local copy some point in history as upstream/x.y.z+somedate, and use that as the upstream release. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: What to do for new packages
El 27/11/08 18:01 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > > OK, so I'm about to co-maintain liblo, which is an OSC library, and can > > be considered a multimedia package (csound, rosegarden and ardour are > > some "big" packages using it). > > ok. cool! > > > So... I want to bring it under the scope of the teams-to-become-one. I > > have imported the sources into a git repository. > > IIRC we agreed on tracking upstream releases in an upstream branch, > maintain debian packaging in a branch derived from the upstream branch > but keep patches to the upstream source in quilt. Is that correct? > > We should really document that somewhere. Probably on wiki.debian.org > would be a good place. OK, I've started a page: http://wiki.debian.org/DebianMultimedia/Merge. Please add, edit, remove whatever you think necessary. I just filled a stub based on what I think we have agreed. > > > demudi already has a git area > > enabled in alioth, pkg-multimedia doesn't. Should I use the demudi area? > > What list should I put in the Maintainer field? > > Given that pkg-multimedia is more active maybe we should it? > > I really don't mind using pkg-multimedia-maintainers, since it is more > active. I've setup a doodle poll, please vote here: > > http://doodle.com/v6df6bx2akdft73f Great! I placed my vote. I agree with Fabian that debian-multimedia may be associated with Marillat's repository, and we should avoid that. Free's point about using the same project for lists and everything is also important. Using different alioth projects would be confusing, I think. > > > BTW, I have applied for joining the pkg-multimedia project, in case we > > end up using any resources there. > > I noticed you have already been added! welcome! Cool. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
What to do for new packages (was: Multimedia Teams in Debian)
OK, so I'm about to co-maintain liblo, which is an OSC library, and can be considered a multimedia package (csound, rosegarden and ardour are some "big" packages using it). So... I want to bring it under the scope of the teams-to-become-one. I have imported the sources into a git repository. demudi already has a git area enabled in alioth, pkg-multimedia doesn't. Should I use the demudi area? What list should I put in the Maintainer field? Given that pkg-multimedia is more active maybe we should it? BTW, I have applied for joining the pkg-multimedia project, in case we end up using any resources there. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
El 22/11/08 05:47 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > > I think it avoids confusion to have a single list. If later on it shows > > to be a problem, the list can be split. Maintaining both lists from the > > start sounds like preemptive optimization to me. > > Ok, with that having in mind, I'm OK with using a common list. In case > "problems arise", we reconsider. OK. > > >> I've made these drawings before vcs-pkg.org was founded. After that, > >> Marting and the other guys over there did come to similar conclusions > >> but even further reaching conclusions. I at least try to follow their > >> discussion mailing lists. > > > > I haven't been following lately, but it appears the current "panacea" is > > TopGit... haven't tried it yet though. I'll give it a spin. > > AFAIUI TopGit is a tool on top of git that can convert quilt patches to > git branches and vice versa. See below. Eehm, AIUI, TopGit works from branches to quilt. Not the other way around. > > >> > Agreed. Uniformity is key for collaboration across packages. > >> > >> Ok. What mode do you propose? > > > > I don't think it's important what particular mode is used, as long as > > it's consistent. What I do for csound is an upstream branch tracking > > releases, and a master branch where we use quilt for patch > > management. I think it makes it easier since most patches are > > short-lived in our case. > > Key facts here: > > - upstream branch *tracking* upstream > - patch management using quilt. > > For point 1: How often do you "snapshot" upstream? Every upstream commit > of their VCS or only upstream releases? What to do with upstreams that > don't do commits in years? (think ffmpeg, toolame). In our case, we track upstream releases only, but only because it doesn't make much sense to do otherwise[1]: csound uses CVS (ugh), thus making it painful to track it directly. In the case of ffmpeg, where there are no released tarballs, it would make sense to directly track the git repository (ie, the upstream branch is a clone of upstream's master branch). In either case, "upstream" releases should be tagged (eg, upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff is not a diff against upstream's tip, but against these tags. > > FWIW, I think that is a very reasonable approach. For ffmpeg, I have > written a get-orig.source.sh shell script that can generate arbitrary > "releases" with any mangling debian packaging requires. I think that > approach can be adopted by other packages, even if they don't need > special mangling. In the simplest case, the get-orig-source.sh script > will be a frontend to uscan(1). In any case, the result of that script > is then used as base for commits in the "upstream branch", see above. It's a simple approach, so it would probably minimize confusion. Another way we used to do with csound is: the upstream branch contains the pristine upstream tarball, the dfsg-clean branch has the mangled upstream code and the master branch contains the debian packaging. Then builds are done against the dfsg-clean branch instead of the upstream branch, and unstripped builds can be done agains the upstream branch. The problem with this approach is that the code that you are stripping because you can't/don't want to distribute in Debian is still served by Debian via the vcs in alioth. The ffmpeg case is somewhat particular, as the same packaging can build 2 source packages (ffmpeg and ffmpeg-debian). I'm not really sure what approach is the best. I would > > > Other people prefer topic branches and an integration branch. This > > may be better for longer-lived patches. The guys from vcs-pkg seem to > > swear by this last workflow. TopGit seems to be able to generate a > > linear quilt patchset, which is nice for people wanting to review the > > source package. > > Exactly. I think we don't do a mistake if we continue maintaining quilt > patches for now. I'd say let's see how this works out and reconsider > later. Lets try to set a few guidelines for new/transitioning packages, then. 1. Packages should be maintained in a git repository (using the pkg-multimedia or demudi namespace?) 2. The maintainer field should be set to... 3. Patches to upstream should be stored as quilt patches which are then used in the build process (ie, no direct changes to the source files). 4. How to manage upstream sources? [1] At least, that's what I thought when I first created the git repo. I don't know if my comaintainer agrees on the motivation. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
El 21/11/08 16:18 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > >> I think the same could work with the "common" multimedia team as well: > >> > >> debian-multimedia@lists.debian.org: "General Discussion" > >> [EMAIL PROTECTED]: "bug flow, etc" > >> > >> However, I wouldn't mind if the pkg-multimedia-maint list would set a > >> Mail-Follow-Up to header to debian-multimedia@ in order to focus > >> discussion. > > > > Hmm, so what would be the point of pkg-multimedia-maint if mails are > > answered to debian-multimedia? > > to avoid cluttering the archive with upload notifications and > bugmail. Thinking more about it, that might only be necessary with > larger teams like the debian games team or the KDE team. pkg-multimedia > survived pretty well with one single list for both discussion and > maintainer contact address. I think it avoids confusion to have a single list. If later on it shows to be a problem, the list can be split. Maintaining both lists from the start sounds like preemptive optimization to me. But I think we are "fighting over sand" here: packages will continue to have either list for a while. > > >> http://wiki.tauware.de/misc:vcs-packaging > >> http://wiki.tauware.de/misc:vcs-packaging2 > > > > You might want to look at vcs-pkg.org > > I've made these drawings before vcs-pkg.org was founded. After that, > Marting and the other guys over there did come to similar conclusions > but even further reaching conclusions. I at least try to follow their > discussion mailing lists. I haven't been following lately, but it appears the current "panacea" is TopGit... haven't tried it yet though. I'll give it a spin. > > >> Moreover various people have explained their details on how to handle > >> patches with a DVCS, and with git in particular. The nice thing about > >> svn here is that you don't have that much choice (because svn does not > >> offer similar features at all) and discussion on that is avoided. So if > >> we want to move to git, we must document very carefully the exact way > >> how to use to tool git. > > > > Agreed. Uniformity is key for collaboration across packages. > > Ok. What mode do you propose? I don't think it's important what particular mode is used, as long as it's consistent. What I do for csound is an upstream branch tracking releases, and a master branch where we use quilt for patch management. I think it makes it easier since most patches are short-lived in our case. Other people prefer topic branches and an integration branch. This may be better for longer-lived patches. The guys from vcs-pkg seem to swear by this last workflow. TopGit seems to be able to generate a linear quilt patchset, which is nice for people wanting to review the source package. > > >> As a side note, I think we have 2 special packages in pkg-multimedia, > >> namely ffmpeg-debian/ffmpeg and vlc. I think we should somehow make it > >> clear that they are special. However that should not be the main concern > >> for the matter of this discussion, I just wanted to point out that they > >> are special maintenance wise. > > > > Why are they special? > > vlc is mainly maintained by xtophe, and previously by sam. Both are vlc > upstream developers. I think that indeed makes vlc special. > > ffmpeg-debian is very special because of its, well interesting, > packaging. have a look at the latest commits :) Hmm, OK. Do you fear that "collaborators" will go and mess up your packaging? I haven't seen that happen yet. There's nothing wrong with noting special packages, though. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
El 21/11/08 07:19 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > > El 23/04/08 06:09 Fabian Greffrath escribió: > >> I believe we could start merging the efforts of both the > >> pkg-multimedia-maintainers and the debian-multimedia groups into one > >> bigger project, although the current scopes of both projects are > >> slightly different. Since this has allready been suggested today, I'd > >> like to hear some other (Hello, team members!) opinions about it. > > > > Hello all. This discussion died without any further action towards > > merging both teams. I re-brought it up a few days ago at the > > debian-multimedia list[1], and the general consensus (ie, 2 other people) > > is that they should be merged. Now, re-reading this particular thread, it > > seems that the pkg-multimedia team didn't have anything against it. So, > > lets work out a way to move forward. > > Yes, I still have that thread 'ticked', but I have to admit that I was > too busy/lazy to actually answer it. Sorry for that. > > Let me please think aloud. I'm currently looking at the package lists: > > http://qa.debian.org/[EMAIL PROTECTED] > http://qa.debian.org/[EMAIL PROTECTED] >lioth.debian.org > > both are pretty impressive lists. I think I didn't even touch half the > packages of pkg-multimedia, and didn't even really look inside the > packages of debian-multimedia. Furthermore I have to admit that in the > past, I've mainly cared for ffmpeg and sponsored from time to time > people from pkg-multimedia. This is something missing from the d-m team at this point. DD manpower to sponsor non-DD contributors. Although true collaboration would be ideal, it is a first step towards that. > > To me at least the pkg-multimedia team is a bit similar to the Debian QA > Team. There is a pool of packages that are cared for by interested > people. In the pkg-multimedia team, I don't think we have maintained a > list with 'active' team members, but more or less 'hoped' that bugs are > fixed by members of the team that cared. I don't feel there is strong > commitment by the team member for all packages, but the respective > maintainers all have their 'pet' packages. > > In the end, what does merging the team mean to me? For me, it is > enlarging the pool of potential people that potentially touch the > package. This doesn't need to be a bad think, but realistically, we could > have the same with using the alioth 'collab-maint' "project", no? I think you answered yourself that question with your next paragraph: > > Still having a (common) dedicated multimedia maintainer's team would > group a set of people interested in a set of related packages. I think > this is a desirable goal. Having a common list is motivating. Activity generates more activity, IME. Collab-maint doesn't create this effect. > > > First of all, the bikeshed :) : which list and name to use. It was > > suggested that debian-multimedia be kept as a discussion list about > > multimedia in debian, and pkg-multimedia for the maintainership of > > packages. While it sounds nice at first, I think it doesn't make much > > sense. At least nobody has been using any of both lists for that purpose. > > I think it should be better if only one list would be kept. I'm not sure > > what kind of "general" discussion was expected in the d-m list. The kde > > in debian lists (which follow this dual-list model) show that the > > "general discussion" one ended up pretty much dead. I also think that > > Debian Multimedia Team is a cooler name. > > I disagree. The Debian Games Team follow the same dual-list approach. It > turns out that the pkg- list, that listed in the maintainer field is > pretty crowded with bug mail, while the "general discussion" list is > pretty much well used for general discussion. > > I think the same could work with the "common" multimedia team as well: > > debian-multimedia@lists.debian.org: "General Discussion" > [EMAIL PROTECTED]: "bug flow, etc" > > However, I wouldn't mind if the pkg-multimedia-maint list would set a > Mail-Follow-Up to header to debian-multimedia@ in order to focus > discussion. Hmm, so what would be the point of pkg-multimedia-maint if mails are answered to debian-multimedia? > > > Second, VCS coordination. From what I can see, pkg-multimedia uses svn. > > d-m also uses svn, but is slowly moving towards git. Is there any > > interest in the p-m people to move to git? I fear that there is no > > interest
Re: Multimedia Teams in Debian
El 23/04/08 06:09 Fabian Greffrath escribió: > I believe we could start merging the efforts of both the > pkg-multimedia-maintainers and the debian-multimedia groups into one > bigger project, although the current scopes of both projects are > slightly different. Since this has allready been suggested today, I'd > like to hear some other (Hello, team members!) opinions about it. Hello all. This discussion died without any further action towards merging both teams. I re-brought it up a few days ago at the debian-multimedia list[1], and the general consensus (ie, 2 other people) is that they should be merged. Now, re-reading this particular thread, it seems that the pkg-multimedia team didn't have anything against it. So, lets work out a way to move forward. First of all, the bikeshed :) : which list and name to use. It was suggested that debian-multimedia be kept as a discussion list about multimedia in debian, and pkg-multimedia for the maintainership of packages. While it sounds nice at first, I think it doesn't make much sense. At least nobody has been using any of both lists for that purpose. I think it should be better if only one list would be kept. I'm not sure what kind of "general" discussion was expected in the d-m list. The kde in debian lists (which follow this dual-list model) show that the "general discussion" one ended up pretty much dead. I also think that Debian Multimedia Team is a cooler name. Second, VCS coordination. From what I can see, pkg-multimedia uses svn. d-m also uses svn, but is slowly moving towards git. Is there any interest in the p-m people to move to git? I fear that there is no interest in d-m to move back so svn (am I right in this?). My personal choice would be git, FWIW. Administrative merging of the teams (ie, removing demudi or pkg-multimedia from alioth to use only one) should be done at least right after squeeze (since packages in lenny will point to both places). Lets hope this gets the ball rolling. [1] http://lists.debian.org/debian-multimedia/2008/11/msg00033.html Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: liblo0-dev
El 19/11/08 07:36 Free Ekanayaka escribió: > Hi Robert, > > |--==> On Wed, 19 Nov 2008 09:56:20 +, Robert Jordens > | <[EMAIL PROTECTED]> said: > > RJ> Hi Ian, > > RJ> On Fre, 2008-11-14 at 03:01 -0800, Ian McIntosh wrote: > >>liblo is at 0.25 now and the deb is at 0.23. Can we update? > > RJ> I'd love to. But I'm generally a bit behind with my Debian packages. > RJ> I suggest that debian-multimedia have an eye on this as well. If > anyone RJ> has some time, please go ahead. I can take a look at it, since it is needed for my package csound. > > Unfortunately I'm late with my packaging work as well, and the Debian > Multimedia Team in general is seriously lacking man power at the > moment :( I think that merging with the pkg-multimedia team would make some sense. At least there would be more than 1 DD to sponsor potential contributors. I moved csound out of debian-multimedia precisely because I couldn't get a sponsor. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Switching to git
El 14/10/08 16:34 Free Ekanayaka escribió: > Hi team, > > since today we have git repository for our packages What is the structure of the git repository? There seem to be some branches for each patch, but then the patch is stored in master as a quilt patch. What is the intended workflow? Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#446405: ardour: Embeds too many libs
On Thursday 29 May 2008 08:28:34 Daniel James wrote: > It's really not a good idea, because the system libraries don't yet have > the patches that Ardour needs. That's why the upstream authors can't > support a syslibs version. AFAIK, sndfile was the only patched library. The others can be used (and SConstruct contains some comments about them). -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Ardour still not present in testing
On Thursday 01 May 2008 12:13:38 Daniel James wrote: > Hi Felipe, > > > Actually, when/if it builds it won't go either, since it has 4 RC bugs > > and there is no version in testing. > > Is there any way we can resolve this? Can we just get security support > removed so that the embedding of libraries is no longer an issue? > > I seriously doubt that Ardour is installed on any security-critical > servers. I think this should be taken to the release and security teams. Note though that there are non-security related RC bugs, these would need to be fixed first. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Ardour still not present in testing
On Wednesday 30 April 2008 15:41:32 Tshepang Lekhonkhobe wrote: > On Wed, Apr 30, 2008 at 9:18 PM, Brandon Simmons > > <[EMAIL PROTECTED]> wrote: > > Hello, > > Writing to inquire why Ardour has not yet made it to into Lenny. I > > couldn't glean the reason from the Debian developer page. If there are > > issues with the package, are they being resolved? I would think this > > package would be in high demand, but apparently not. > > It's failing to build on a few archs, so by default can't transition into > Lenny: * http://bjorn.haxx.se/debian/testing.pl?package=ardour Actually, when/if it builds it won't go either, since it has 4 RC bugs and there is no version in testing. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
On Thursday 24 April 2008 08:36:52 Joost Yervante Damad wrote: > In my opinion the packages would be better served if they just had > individual maintainers assigned. This is one of the reasons I removed my > timidity package from the debian-multimedia team. I think packages would be better served by real team collaboration. What I saw was that d-m was just a place where people ask for a sponsor for multimedia-related packages instead of a place where people ask for (and receive) help maintaining their packages, which is what I think is more useful (does this happen in pkg-multimedia?). -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
On Wednesday 23 April 2008 03:59:55 Reinhard Tartler wrote: > Felipe Sateler <[EMAIL PROTECTED]> writes: > > I tried to maintain the csound package within the debian-multimedia team, > > but it seemed pretty much dead, which is why I moved out. > > OTOH, if what you say is right, maybe I tried in the wrong place. > > I had the impression that the 'other' debian-multimedia team was rather > focus on 'professional' audio and video editing tools rather than > 'classic' multimedia packages like media players and multimedia > libraries. > > If the debian-multimedia team is indeed dead, we should avoid setting it > in the maintainer field of any package. Nobody is served with > unreachable (or non-existant) maintainers. Note that the (some?) maintainers are still active AFAICS, it's just that the list itself isn't useful. I haven't seen much collaboration. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
On Tuesday 22 April 2008 05:12:28 tim hall wrote: > Gürkan Sengün wrote: > > Hello > > > > I had created a list of all teams findable for the period of the year > > 2007: http://krum.ethz.ch/ddc/teams-of-2007.txt > > > > Is there a reason why there's two multimedia groups in Debian? > > > > Is there a chance or interest to merge them together? > > are you referring to the fact that there is a 'Debian Multimedia > Packages Maintainers' and 'Debian Multimedia Team'? I believe the split > is deliberate for administrative reasons. AFAIU debian-multimedia is the > umbrella, including testers, interested users etc. and used for general > discussion; pkg-multimedia-maintainers is specifically for the > maintainers of multimedia packages and is focussed on functional > requirements for producing packages. I'm not really sure this is right: % grep-aptavail -FMaintainer,Uploaders debian-multimedia@lists.debian.org -sPackage | wc -l 54 I tried to maintain the csound package within the debian-multimedia team, but it seemed pretty much dead, which is why I moved out. OTOH, if what you say is right, maybe I tried in the wrong place. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: STK 4.3.0 released
Hi Thomas. It seems you haven't had luck getting STK into debian. Are you still interested on it? If you are, you may want to contact Jonas Smedegaard <[EMAIL PROTECTED]>, which may be able to help you. However, you need to agree to some conditions: 1. Packaging done with git in the collab-maint repo. 2. He will be a comaintainer, not just a sponsor. 3. Are willing to use CDBS (which you are since it is already on CDBS). If you are, you need get a username in alioth and apply to the collab-maint project. Then I can help you set up a git repository there. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
RFC/RFS: Csound 5.08
Hi all. I have working csound 5.08 packages. If someone could review and (maybe) sponsor them, I would be very grateful. The package can be found at deb-src http://felipe.sateler.com/debian unstable main or dget http://felipe.sateler.com/debian/pool/main/c/csound/csound_5.08.0.dfsg-1.dsc Csound is a widely used sound synthesis software, with over 450 signal processors. It can work as a compiler or in realtime. This is a major update since the version in debian, which is from 2005. The package has been taken over from Hans Fugal with his blessing. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Some of your Debian packages might need attention
On Monday 03 March 2008 06:11:53 DDPOMail robot wrote: > Dear Debian Multimedia Team, > > The following possible problem(s) were detected in the package(s) > you maintain in Debian: > > === ardour: > = This package has 3 bug(s) that should be fixed for the next Debian > release: - #442495 <http://bugs.debian.org/442495> > ardour: FTBFS if build twice in a row > Bug part of a release goal: double compilation support > - #446405 <http://bugs.debian.org/446405> > ardour: Embeds too many libs > This is a Release-Critical bug! > - #458660 <http://bugs.debian.org/458660> > ardour: FTBFS: build times out > This is a Release-Critical bug! > = This package has not been in testing for 211 days. > If things don't change, it won't be part of lenny! > See <http://release.debian.org/migration/testing.pl?package=ardour> Huh? The svn repo contains version 1:2.2-2 of ardour, but the version in the archive is 1:2.3.1-1. Maybe forgot to commit the changes to the repo? -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: CinePaint removed from testing
On Tuesday 29 January 2008 14:47:36 Robin Rowe wrote: > Hi. I'm the CinePaint project leader. I got a note from Daniel James at > 64Studio that CinePaint has been removed from Debian. I tried contacting > Debian maintainer Andrew Lau by email, but got no reply. > > Daniel pointed me toward the Debian bug report, see below. I don't know > what it means. What's the problem? What needs to be done? The problem is not the bug you show below, but that cinepaint is a GTK+ 1.x application. GTK+ 1.x and related libs are scheduled for removal from debian, because it is no longer supported by anyone. As part of the removal, all reverse dependencies must be removed. There was an attempt to reintroduce it to debian by Thanasis Kinias, but so far nothing has happened. See the bug log for cinepaint's removal for more details[1]. I should point out that as long as cinepaint requires GTK+ 1.x, then it has a verey low chance of entering debian. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437837 -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#458730: rosegarden 1.6.1-1 not in unstable repository
On Wednesday 02 January 2008 10:43:39 Paul Menzel wrote: > Subject: rosegarden 1.6.1-1 not in unstable repository > Package: rosegarden > Version: 1:1.6.0-1 > Severity: minor > > *** Please type your report below this line *** > > A happy new year everyone, > > > sorry if I am wrong, but despite [1] it looks like rosegarden 1.6.1-1 is > not available yet. So maybe it is server error. At [2] for i386 also > 1.6.0-1 is only available. This is because the i386 buildd has not yet built rosegarden 1.6.1. rosegarden-data is available at version 1.6.1 because it is arch:all and thus was uploaded to i386 when uploaded to amd64. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Csound
Hi all. I have been working with csound and finally have a package ready. It
is available from mentors[1], or alternatively from the svn repo
(debian/rules has a get-orig-source target), and I would greatly appreciate
it if any of you could check it out and maybe even upload it.
Note that there is a lintian warning about a not-clean source, but since
dpkg-buildpackage calls clean before build there should be no issue as it is
properly cleaned up on the clean target. I didn't override the lintian
warning/add special code to clean the upstream tarball because hopefully
upstream will provide clean sources from now on.
[1]http://mentors.debian.net/debian/pool/main/c/csound
--
Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
Re: FTBS of ardour
On Sunday 21 October 2007 08:19:23 Nico Golde wrote:
> Hi Ardour maintainers,
> Did someone of you already look into:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446597?
> I ask because this is the only thing missing from fixing the
> security flaw in ardour described on:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445889
The scons bug that was blocking this is gone[1], anyone with ardour experience
care to fix that bug? AFAICS, it is just a matter of applying the attached
patch.
[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444204
--
Felipe Sateler
diff -Nru trunk/gtk2_ardour/editor_mouse.cc trunk.new/gtk2_ardour/editor_mouse.cc
--- trunk/gtk2_ardour/editor_mouse.cc 2007-10-22 19:30:28.0 -0300
+++ trunk.new/gtk2_ardour/editor_mouse.cc 2007-10-22 19:38:39.0 -0300
@@ -1530,8 +1530,8 @@
*/
if (!drag_info.move_threshold_passed) {
- bool x_threshold_passed = (abs ((nframes64_t) (drag_info.current_pointer_x - drag_info.grab_x)) > 4LL);
- bool y_threshold_passed = (abs ((nframes64_t) (drag_info.current_pointer_y - drag_info.grab_y)) > 4LL);
+ bool x_threshold_passed = (((nframes64_t) abs (drag_info.current_pointer_x - drag_info.grab_x)) > 4LL);
+ bool y_threshold_passed = (((nframes64_t) abs (drag_info.current_pointer_y - drag_info.grab_y)) > 4LL);
drag_info.move_threshold_passed = (x_threshold_passed || y_threshold_passed);
signature.asc
Description: This is a digitally signed message part.
Re: FTBS of ardour
On Friday 26 October 2007 14:52:00 Nico Golde wrote:
> Hi Felipe,
>
> * Felipe Sateler <[EMAIL PROTECTED]> [2007-10-26 18:50]:
> > On Wednesday 24 October 2007 05:42:49 Nico Golde wrote:
> > > Updating to the latest Scons build file in ardour svn should
> > > solve this, they added some uninstall rule referring to
> > > upstream.
> + [ Delete ('$PREFIX/etc/ardour2'),
> + Delete ('$PREFIX/lib/ardour2'),
> + Delete ('$PREFIX/bin/ardour2')])
>
> env.Alias('revision', the_revision)
> env.Alias('install', env.Install(os.path.join(config_prefix, 'ardour2'),
> 'ardour_system.rc')) +env.Alias('uninstall', remove_ardour)
>
> I don't know if this is complete, I guess it's not but this is from
> revision 2539 which is quite a big change.
I think this is unrelated: it creates an uninstall target, which has nothing
to do with cleaning the build.
--
Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
Re: FTBS of ardour
On Wednesday 24 October 2007 05:42:49 Nico Golde wrote: > Updating to the latest Scons build file in ardour svn should > solve this, they added some uninstall rule referring to > upstream. What revision? I can't see anything in the websvn at http://viewcvs.ardour.org/log.php?repname=Ardour&path=%2Ftrunk%2FSConstruct&rev=0&sc=0&isdir=0 -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Please test csound
On Friday 26 October 2007 04:50:08 you wrote: > Hi Felipe, > > I did the uploads for csound for Hans Fugal. But I am sorry, I currently > do not have the time to do a decent review. Hope that someone else will > be able to do so. Did you ask on other lists too ? Hmm, I though I'd a better review here. I will ask on -mentors. > If you just need someone to upload, I can do so. I trust in your > judgement and I am sure that you will fix any problems that will arise. Thanks for the offer. However, csound is not a trivial package anymore, so I'd prefer independent review before uploading. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Please test csound
On Monday 22 October 2007 01:18:06 Felipe Sateler wrote:
> Hi. I've been working on csound, and I think the package is going nice. I
> would like, however, an independent review of the package.
Is anyone going to check this out? I have source packages available at
mentors[1]. Please do review it.
[1] http://mentors.debian.net/debian/pool/main/c/csound
dget
http://mentors.debian.net/debian/pool/main/c/csound/csound_5.07.0.dfsg-1.dsc
--
Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
Re: FTBS of ardour
On 10/23/07, Nico Golde <[EMAIL PROTECTED]> wrote: > Hi Felipe, > * Felipe Sateler <[EMAIL PROTECTED]> [2007-10-23 10:22]: > > On Sunday 21 October 2007 08:19:23 Nico Golde wrote: > > > Hi Ardour maintainers, > > > Did someone of you already look into: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446597? > > > I ask because this is the only thing missing from fixing the > > > security flaw in ardour described on: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445889 > > > > I've been looking into this. The pkg-config issue is trivial, a pkg-config > > build-dep was missing. > > Are you sure about this? I don't really think so I think > this is a scons issue, if you look at the build log failing > because of pkg-config you can see another place where > pkg-config is there in the same build Ah, this is true. I failed to see that pkg-config was brought in by some dependency earlier, and that the failure was when cleaning. I know what the problem is, but unfortunately there is nothing we can do, please see scons bug 444204. In short, the problem is that the current snapshot in unstable doesn't actually execute configuration directives when called with -c (clean) or -h (help). This has the side effect that all configure calls return false, which makes cleaning and asking for help break. This is apparently fixed in upstream svn, but hasn't got here yet. I wasn't able to reproduce the problem here since I have scons on hold for exactly this reason (I do feel somewhat embarrased for not seeing this before, though). > > > I'm having a problem with the abs issue, though: I > > can't understand why it is there, and it doesn't appear here on i386. > > From what I see the problem is that it does not know to > which type the value should be converted, there is no > variant for nframes64_t or int64_t and int64_t is assignment > compatible with float and int for example. > So typecasting should solve this. The strange thing is that this should happen in other 32-bit architectures too, since the int64_t is defined as a long long int, which has no abs implementation in the std:: namespace. Anyways, my patch moved the casting from double to int64_t to after the abs is done, which should resolve the ambiguity (double std::abs(double) is present in the C++ standard). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FTBS of ardour
On Sunday 21 October 2007 08:19:23 Nico Golde wrote:
> Hi Ardour maintainers,
> Did someone of you already look into:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446597?
> I ask because this is the only thing missing from fixing the
> security flaw in ardour described on:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445889
I've been looking into this. The pkg-config issue is trivial, a pkg-config
build-dep was missing. I'm having a problem with the abs issue, though: I
can't understand why it is there, and it doesn't appear here on i386. I think
the problem is there because (for some strange reason) abs(long long) is
defined on i386 and other archs but not on mips. I (hopefully, I don't have a
mips machine to test on) work around that by making it an abs(double) and
then casting to nframes_t. This appears to work here.
Attached is a patch that makes the necessary changes.
--
Felipe Sateler
diff -Nru trunk/debian/control trunk.new/debian/control
--- trunk/debian/control 2007-10-22 19:27:07.0 -0300
+++ trunk.new/debian/control 2007-10-22 19:37:03.0 -0300
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Multimedia Team
Uploaders: Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>, Robert Jordens <[EMAIL PROTECTED]>, Free Ekanayaka <[EMAIL PROTECTED]>
-Build-Depends: autotools-dev, quilt, patchutils (>= 0.2.25), cdbs (>= 0.4.27-1), debhelper (>= 4.1.0), scons, dh-buildinfo, libsigc++-2.0-dev, libxml2-dev (>= 2.5.7), libasound2-dev (>= 0.9.4), libsndfile1-dev, libsamplerate0-dev, liblrdf0-dev (>= 0.3.1-4), ladspa-sdk (>= 1.1-2), libjack-dev, libgtkmm-2.4-dev, libglade2-dev, libpango1.0-dev, libgnomecanvasmm-2.6-dev, libgnomecanvas2-dev, libglib2.0-dev, libglademm-2.4-dev, gettext, intltool, libboost-dev, libsoundtouch1-dev, liblo0-dev, libcairomm-1.0-dev (>= 1.2.4)
+Build-Depends: autotools-dev, quilt, patchutils (>= 0.2.25), cdbs (>= 0.4.27-1), debhelper (>= 4.1.0), scons, dh-buildinfo, libsigc++-2.0-dev, libxml2-dev (>= 2.5.7), libasound2-dev (>= 0.9.4), libsndfile1-dev, libsamplerate0-dev, liblrdf0-dev (>= 0.3.1-4), ladspa-sdk (>= 1.1-2), libjack-dev, libgtkmm-2.4-dev, libglade2-dev, libpango1.0-dev, libgnomecanvasmm-2.6-dev, libgnomecanvas2-dev, libglib2.0-dev, libglademm-2.4-dev, gettext, intltool, libboost-dev, libsoundtouch1-dev, liblo0-dev, libcairomm-1.0-dev (>= 1.2.4), pkg-config
Standards-Version: 3.7.2
Package: ardour
diff -Nru trunk/gtk2_ardour/editor_mouse.cc trunk.new/gtk2_ardour/editor_mouse.cc
--- trunk/gtk2_ardour/editor_mouse.cc 2007-10-22 19:30:28.0 -0300
+++ trunk.new/gtk2_ardour/editor_mouse.cc 2007-10-22 19:38:39.0 -0300
@@ -1530,8 +1530,8 @@
*/
if (!drag_info.move_threshold_passed) {
- bool x_threshold_passed = (abs ((nframes64_t) (drag_info.current_pointer_x - drag_info.grab_x)) > 4LL);
- bool y_threshold_passed = (abs ((nframes64_t) (drag_info.current_pointer_y - drag_info.grab_y)) > 4LL);
+ bool x_threshold_passed = (((nframes64_t) abs (drag_info.current_pointer_x - drag_info.grab_x)) > 4LL);
+ bool y_threshold_passed = (((nframes64_t) abs (drag_info.current_pointer_y - drag_info.grab_y)) > 4LL);
drag_info.move_threshold_passed = (x_threshold_passed || y_threshold_passed);
signature.asc
Description: This is a digitally signed message part.
Re: Some of your Debian packages might need attention
On Monday 22 October 2007 12:56:30 DDPOMail robot wrote: > === rosegarden: > = This package has not been able to migrate from unstable > to testing for 183 days. > See <http://bjorn.haxx.se/debian/testing.pl?package=rosegarden> > > === sineshaper: > = This package has not been in testing for 178 days. > = This package has not been able to migrate from unstable > to testing for 178 days. > See <http://bjorn.haxx.se/debian/testing.pl?package=sineshaper> These two packages are not migrating due to unmet (build-)dependencies. Rosegarden is waiting for guile to build, and sineshaper is waiting for gtk+-2.0. Is it possible to make the DDPO robot ingore these, or is there a reason to not ignore them? -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Please test csound
Hi. I've been working on csound, and I think the package is going nice. I
would like, however, an independent review of the package. The debian/rules
file in the svn repo contains a get-orig-source rule to get and dfsg-clean
the upstream source. It will leave an appropriate tarball in the current
directory[1]. There is however a problem with current scons in debian[2], so
you'll need an older version[3] to get it to build.
[1] The dfsg-cleaning is removing a couple of opcodes, and upstreams provided
debian/ subdir, since it only gets in the way.
[2] http://bugs.debian.org/444204
[3] You'll need 0.97.0d20070809-1, available from
http://snapshot.debian.net/archive/2007/08/11/debian/pool/main/s/scons/
--
Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
Re: STK 4.3.0 released
On Monday 01 October 2007 18:42:41 Thomas de Grivel wrote: > I need an uploader though I still wonder about the usability of this > package : the debian package has binaries with support for oss, > alsa and jack but the installed headers do not provide them unless > the user defines some (unprefixed) macros like __LINUX_ALSA__. > > I feel we should at least create some config.h at compilation and > maybe include it in stk headers, or let the user include it. Another > less intrusive solution would be to create a pkgconfig file. I can do > both. Maybe even upstream would be interested ? A quick glance through the sources suggest that such macros are really used only when building the stk source files, but not in the installed header files, except for defining some unix-specific macros/typedefs/includes. Since all debian-generated versions will be unix-based, maybe it makes sense to "hardcode" the macros at installation time, or provide a config.h that gets included by all needing headers. The .pc file I think is not optimal since there is a chance that someone might not use it to get the appropriate CXXFLAGS. It should not be difficult to change configure.ac to create a config.h that contains the apropriate definitions. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: STK 4.3.0 released
On Wednesday 26 September 2007 17:14:43 Thomas de Grivel wrote: > Hi all ! I am rather new here and would like to contribute a bit. > I am myself a programmer (see http://patchwork13.sf.net/) and currently > learning to maintain my own debian packages. > > Enough with presentations, let me introduce what brings me here. > Pw13 uses the STK lib from Stanford CCRMA and to my surprise it is > included in Debian (as opposite to many distributions) but fails to work. > > All I get is : > > symbol lookup error: /usr/lib/libstk.so.0: > > undefined symbol: jack_set_error_function > > If you definitely don't care/know about my problem (which I can > understand), here is a more interesting thing : ccrma released a new STK > version which is not yet packaged, and I might be interested in taking care > of it. http://ccrma-mail.stanford.edu/pipermail/stk/2007-August/000370.html Great initiative. However, stk is maintained by Guenter Geiger, not debian-multimedia. I provided a patch to Guenter for version 4.2.1[1], but unfortunately that went nowhere. You should contact Guenter about this directly, and maybe bring stk to debian-multimedia. [1] http://bugs.debian.org/427294 -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Some of your Debian packages might need attention
On Thursday 23 August 2007 08:30:05 DDPOMail robot wrote: > Dear Debian Multimedia Team, > > The following possible problem(s) were detected in the package(s) > you maintain in Debian: > > === ardour: > = This package has not been able to migrate from unstable > to testing for 103 days. Ardour has been FTBFS on mips http://buildd.debian.org/fetch.cgi?pkg=ardour;ver=1%3A2.0.5-1;arch=mips;stamp=1186492760 > > === rosegarden: > = This package has not been able to migrate from unstable > to testing for 123 days. This one is waiting for libopenexr-dev >=1.2.2-3 on hppa, which already is there. Maybe a rebuild should be asked on hppa? > > === sineshaper: > = This package has not been in testing for 118 days. > = This package has not been able to migrate from unstable > to testing for 118 days. This one also has been FTBFS on mips and mipsel http://buildd.debian.org/fetch.cgi?pkg=sineshaper;ver=0.4.2-4;arch=mips;stamp=1179137740 http://buildd.debian.org/fetch.cgi?pkg=sineshaper;ver=0.4.2-4;arch=mipsel;stamp=1179146345 All build failures on mips and mipsel have been a segmentation fault in ld. Maybe [EMAIL PROTECTED] should be asked on why is this happening? -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#438059: fix
package ardour-gtk
merge 438059 438061
thanks
Currently there is no version of ardour in testing. However, ardour-gtk no
longer exists: it has been replaced by ardour. Apparently ardour hasn't
entered testing because it hasn't been built on mips and mipsel.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434117: patch
package flake
tags 434117 patch
thanks
Attached is a patch that should fix it. Can't test since here it builds fine
(and I wonder why, it shouldn't).
--
Felipe Sateler
diff -Nru -Nru trunk.orig/libflake/md5.c trunk/libflake/md5.c
--- trunk.orig/libflake/md5.c 2007-08-22 20:00:45.0 -0400
+++ trunk/libflake/md5.c 2007-08-22 20:01:08.0 -0400
@@ -16,6 +16,7 @@
#include
#include "md5.h"
+#include "bswap.h"
/*
* The basic MD5 functions.
