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
Re: Proposed multimedia team migration to salsa.d.o
On Mon, Jan 1, 2018 at 2:43 PM, James Cowgill <jcowg...@debian.org> 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 <hhas...@gmail.com> 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 <ftpmas...@ftp-master.debian.org> 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 deba...@debian.org 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 andreas.cadhal...@googlemail.com 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 शिरीष shirisha...@gmail.com 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 e.kiag...@gmail.com 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 andr...@an3as.eu 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=detailgroup_id=1aid=314215atid=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 Fri, May 24, 2013 at 11:57 AM, rosea.grammostola rosea.grammost...@gmail.com 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 Tilleandr...@an3as.eu 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 Thu, May 23, 2013 at 5:51 AM, Andreas Tille andr...@an3as.eu 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 Mon, May 20, 2013 at 5:17 PM, Andreas Tille andr...@an3as.eu 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
Debian multimedia blend
On Mon, Apr 8, 2013 at 1:28 AM, Felipe Sateler fsate...@gmail.com 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 andr...@an3as.eu 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=detailgroup_id=1aid=314215atid=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 fsate...@gmail.com 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)
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 ti...@debian.org 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: Please consider maintaining Blends information (Was: Bullet Physics Library)
On Wed, Mar 20, 2013 at 12:14 PM, Andreas Tille ti...@debian.org wrote: On Tue, Mar 19, 2013 at 5:10 AM, Andreas Tille ti...@debian.org 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)
On Wed, Mar 20, 2013 at 6:33 PM, Andreas Tille ti...@debian.org 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: 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 fake...@ammd.net 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 wea...@riseup.net wrote: On Fri, September 7, 2012 1:57 pm, Felipe Sateler wrote: Hi, On Fri, Sep 7, 2012 at 4:13 PM, Weaver wea...@riseup.net 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: Joining the team
On Fri, Sep 7, 2012 at 11:46 AM, Ho Wan Chan smartbo...@gmail.com 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: List of required packages.
Hi, On Fri, Sep 7, 2012 at 4:13 PM, Weaver wea...@riseup.net 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: Jackd2 - Pulseaudio negotiation failing
On Sun, Aug 19, 2012 at 2:39 AM, frederic rech f.r...@yahoo.fr 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
Re: Jackd2 - Pulseaudio negotiation failing
On Sun, Aug 19, 2012 at 12:11 PM, frederic rech f.r...@yahoo.fr 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
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
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 ailo...@warpmail.net 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: /usr/bin/qjackctl and pasuspender on Wheezy
On Tue, May 29, 2012 at 2:26 PM, Adrian Knoth a...@drcomp.erfurt.thur.de 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: Remaining packages with debian-multime...@l.d.o as maintainer:
On Tue, Nov 9, 2010 at 07:29, Gürkan Sengün gur...@phys.ethz.ch 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 Maintainerspkg-multimedia-maintain...@lists.alioth.debian.org 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
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
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
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 Klumppmatth...@nlinux.org 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#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#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#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: 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.
Re: What to do for new packages
El 17/12/08 16:29 Reinhard Tartler escribió: Felipe Sateler fsate...@gmail.com 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.
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 fsate...@gmail.com 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 (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: 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.
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: 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.
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 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 in d-m to move back so svn (am I right in this?). My personal choice would be git, FWIW. I'm not that happy with svn either, but when Sam founded pkg-multimedia, he told me he has chosen svn because that would attract most people as svn is the common denominator most people understand. I don't disagree with him here. But I also think that this plan didn't work out too well. In effect I think we don't have more than 4, perhaps 5 people that are actually doing work in pkg-multimedia, and I would be surprised if more than half of these people actually favour svn. I personally favour bzr. but I think I could perhaps do with git
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 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.
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: 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: 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: 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=Ardourpath=%2Ftrunk%2FSConstructrev=0sc=0isdir=0 -- 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: 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.
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 debian-multimedia@lists.debian.org
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.
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 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.
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 string.h #include md5.h +#include bswap.h /* * The basic MD5 functions.
Working on other packages?
What's the team's policy WRT working on other packages of the team? It's because I was watching at the bugs page for the team, and there seem to be some that are easy to fix. So... I just get the svn, fix the bug and commit, or should I send a patch to the BTS? I ask because the wiki says: All members can work on all packages, although there is some sort of split What is that split? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Csound
On Thursday 02 August 2007 07:12:42 Free Ekanayaka wrote: FS And how do you inject only the debian/ directory? That's the effect of the -o option of svn-inject (see man svn-inject, you may also want to have a look at the svn-buildpackage documentation) Done it. The -o option isn't documented in man svn-inject, though (just filed a bug). What the package has right now is: repacked source (done through debian/dfsg-repack) build-deps are ok (I think) build and install to debian/tmp Move some stuff around to comply with debian policy (it seems I got the java one wrong: I apparently moved the wrong lib). What needs to be done: Figure out how the bindings work (I have absolutely 0 expertise in this). There should be at least bindings for lua, java and python. I don't know how python/lua/java package dependencies are detected. Figure out a sane package split (there are 32 binaries installed and 4 libraries plus several plugins). Wait for upstream to send me notes on what the official csound installer for windows includes with some notes, since it has a similar directory structure that could be useful. I may be forgetting stuff. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Csound
On Wednesday 01 August 2007 18:04:00 Free Ekanayaka wrote: Yes we are using svn (because of svn-buildpackage FWIW, there is git-buildpackage too. and because it's the default RCS for Alioth projects). Are you already registered on Alioth? If so, please let me have you're login name so that I can include you in the demudi Alioth project and you can start commit. My username is fsateler-guest. I'm not sure how should I proceed for the conversion to svn. I'm using the following method for work on git: Import the upstream source to the upstream branch. Remove non-free stuff from the source in the dfsg-clean branch. Do the actual packaging in the master branch. I'm not sure if this is possible in subversion, or if you are using a different schema. Apparently you are only saving the debian/ subfolder in svn. -- Felipe Sateler signature.asc Description: This is a digitally signed message part.
Csound
Hi. I'm taking over the csound package from Hans Fugal, and updating it to version 5. However the package has resulted in being bigger than I thought, so I think it would be better if you guys could help me out co-maintaining it. The problem with it is that it csound has grown very big: language bindings, plugins, and more. Plus, the build system is scons which I'm not really familiar with. In short, I'd like to join the team and co-maintain csound with you. I have already started work in csound, but I don't have a public space to make it available. I'm using git, but if you want I can switch to svn (which is what you are apparently using). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
