Bug#462839: RFA: nxtvepg
Package: wnpp Severity: normal I'm looking for someone to maintain nxtvepg. Here is the package description: Description: Nextview EPG decoder and browser In this software package you find a decoder for Nextview - an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. . Currently, Nextview EPG is transmitted by: * in Germany and Austria: Kabel1, 3Sat, RTL-II, EuroNews (coverage: apx. 31 networks) * in Switzerland: SF1, TSR1, TSI1, EuroNews, 3sat, Kabel1 (coverage: apx. 37 networks) * in France: Canal+, M6 (coverage: 8 networks) * in Turkey: TRT-1 (coverage: 17 networks) . The EPG information is read from /dev/vbi, i.e. you need some TV card which provides a VBI data stream. bttv cards work. zoran might work too, but I haven't tested that due to lack of hardware... It is not a too time consuming package, though it needs to be updated to the new tcl packaging policy (#450471, #460598). Since I moved, I have no longer the possibility to use an analogue TV card, and can't therefore use nor test the package. Prospective maintainers should possess suitable hardware. Basic knowledge of Tcl/Tk would be plus ;) -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy') Architecture: i386 (i686) Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473128: ITP: openal-soft -- linux-port of the windows implementation of the cross-platform 3D-audio library OpenAL
Andres Mejia <[EMAIL PROTECTED]> writes: > Could anyone provide a list of the reverse dependencies for openal? I would > like to test a few more packages with the new openal libraries. >> grep-dctrl -FBuild-Depends,Build-Depends-Indep \ -s Package libopenal-dev -n /var/lib/apt/lists/*_Sources funguloids glest tremulous warsow antigrav boson btanks chromium crystalspace fgfs-atlas flightgear freealut haskell-openal hugs98 mplayer nel openarena osgal pyopenal rss-glx scorched3d simgear soya supertuxkart taoframework torcs trigger vegastrike warzone2100 xpilot-ng -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479659: RFH: wine -- Windows API implementation
Ove Kaaven <[EMAIL PROTECTED]> writes: > Package: wnpp > Severity: normal > > Since my time may be limited in the future, I am seeking comaintainers > for the Wine package in Debian, at least to ensure that new Wine releases > may continue to be uploaded in a timely fashion, and to keep the package's > bug count down. (And given that pretty much half the open bugs are "missing > manpage" bugs, documentation writers would also help...) > > I have created a project for this on alioth.debian.org. I've loaded the > current packaging (all versions since etch) into a Git repository there, and > put up some instructions on http://pkg-wine.alioth.debian.org/ Have you considered talking to Scott Ritchie <[EMAIL PROTECTED]> and/or to Stephan Hermann <[EMAIL PROTECTED]>? They both have worked on the wine package in ubuntu quite successfully AFAIS, and TBH, I don't see a particular reason why the package should be diverged across the two distributions. I'm CC'ing the two in order to make them aware of this RFH bug and offer sponsoring uploads, since the two are not DDs but UDs. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311373: Still interested in this package?
hi, This bug has been left open for a really long time, do you still intend to maintain it? If not, I'd like to have this package maintained in the collab-maint archive: http://alioth.debian.org/projects/collab-maint/ regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311373: Still interested in this package?
On Fri, Jan 13, 2006 at 02:52:28AM -0800, Stephen Birch wrote: > Reinhard Tartler([EMAIL PROTECTED])@2006-01-13 10:54: > > This bug has been left open for a really long time, do you still intend > > to maintain it? > > Hi there.. > > My original intention was to wait until my long standing debian > application completed and then do the packaging but the application > process seems to be rather FUBAR. Both my NM and also the sponsorship > of my other packages are both in a frustrating quagmire because the > other folks involved are so very slow. > > FYI I hit the same problem with another package (spca5xx) which had > other interested parties. I ended up creating an alioth account and > now several people are maintaining that package. It worked out really > well. > > Let me ask ... > > Does collab-maint involve more than just creating an alioth account? it is a completly new project, we'll see how it will evolve. We would need an sponsor anyway, but there are some interested DDs for that. You need an alioth account and contact then Raphael Hertzog to add you to the team. I will upload the current ubuntu package to collab-main svn then. > BTW wifi-radar is already packaged in ubuntu and the package (to my > eye) looks okay so I was planning to just import that package into > Debian. I don't have time to reinvent the wheel! I was involved when reviewing and eventually uploading it to ubuntu, I use it from time to time on my ubuntu laptop. > > I may end up dropping my Debian activities anyway ... I have started > to look into joining Ubuntu instead - the NM process has pretty much > tested my patience to the limit. Although there have been no issues, > my application has been in the works since 2004-01-28. Life is too > short :-) I'm currently on the other way round: in order to help ubuntu further, I started NM myself in order to bring packages like wifi-radar to debian. This is one pice on my fight to lower divergence :) regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311373: Still interested in this package?
On Fri, Jan 13, 2006 at 03:11:05AM -0800, Stephen Birch wrote: > Reinhard Tartler([EMAIL PROTECTED])@2006-01-13 11:58: > > it is a completly new project, we'll see how it will evolve. We > > would > > need an sponsor anyway, but there are some interested DDs for > > that. You > > need an alioth account and contact then Raphael Hertzog to add you > > to > > the team. > > I do already have an alioth account, I needed one to get spca5xx uploaded > - but my account is a "-guest" account. > > > I will upload the current ubuntu package to collab-main svn then. > > Cool. Would you mind putting a 'closes #311373' in the changelog to > close the ITP please. I just injected it into http://svn.debian.org/wsvn/collab-maint/ext-maint/wifi-radar/trunk/ I'm happily open for collaborative maintenance, just get an alioth account and ask Raphael for access to the collab-maint svn, and add yourself to Uploaders, or so. > Good luck with your NM - I think it all comes down to the people > involved. If you get a responsive AM it will go smoothly. Although my > AM is a top-notch guy (Joerg) he is just badly over extended hence the > very slow progress. I don't mind slow progress. My sponsor is quite responsive, and I'm also in touch with quite some other DDs, so thats no problem for me :) regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337937: Invitation to join pkg-games
Hi there, perhaps you would like to join us in the pkg-games group on alioth: http://alioth.debian.org/projects/pkg-games/ We maintain a common svn archive to maintain packages collaboratively. Perhaps this makes it easier for you to find a sponsor. -- regards, Reinhard
Bug#311367: Any progress
Hi, I see that Mark Purcell (CC'ed) has created an alioth project for packaging mythtv [1], but I cannot see any progress on that side yet. Marc, could you please give a status update in this bug trail? Thanks [1] http://alioth.debian.org/projects/pkg-mythtv/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352950: status update
owner 352950 Debian Games Team <[EMAIL PROTECTED]> stop Status update: This package is currently beeing worked on within the Debian Games team. The current status can be seen here: http://svn.debian.org/wsvn/pkg-games/packages/openal/?rev=0&sc=0 We are currently preparing an upload for the Upstream version 0.0.8, see the Thread about this here: http://lists.alioth.debian.org/pipermail/pkg-games-devel/2006-February/000425.html We are currently trying to resolve #345964, and have therefore proposed introducing library versioning upstream: http://opensource.creative.com/pipermail/openal-devel/2006-February/001980.html We are currently waiting on upstream reaction to decide how we set the SONAME of the next upload regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349419: Packages found for dnssd
Just wanted to note that sebastien prepared some packages for ubuntu: http://revu.tauware.de/details.py?upid=1830 Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365087: ITP: debcheck -- Checks whether dependencies of debian packages can be satisfied
Sven Mueller wrote: > It would be quite nice if the tool had an option to do the following: > Given the Packages file (or other compatible list of packages) on STDIN > and a set of "seed" packages on the commandline, print out all the > packages needed to fulfill the dependencies (if all dependencies can be > fulfilled - error out if not). did you look at the package 'germinate'? Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477806: Any updates on this bug?
Rogerio Brito writes: > Is there any progress on this? Any updates? Is there a package that actually and actually benefits from djbfft? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523338: ITP: radare -- Free advanced command line hexadecimal editor
Sebastian Reichel writes: > Package: wnpp > Severity: wishlist > Owner: Sebastian Reichel > > * Package name: radare > Version : 1.2.3 > Upstream Author : pancake > * URL : http://radare.org > * License : GPL > Programming Lang: C + scripts in various languages > Description : Free advanced command line hexadecimal editor > > The project aims to create a complete free *nix-like toolchain for > working with binary files. What's the status of this ITP? Are preliminary packages available somewhere? In case you need help or sponsoring, please let us know in this ITP bug. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523338: ITP: radare -- Free advanced command line hexadecimal editor
AFAIUI sponsor requests should go to debian-mentors. Please not that I'm not a mentors regular, so I'm not really sure of the exact procedures here. Nevertheless, I'm copying the mailing list. Sebastian Reichel writes: > I am searching for a sponsor, so feel free to do so ;) My preliminary review of http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=radare minor points: * spurious configure target, please remove it. * build-target could be improved, e.g. by placing both variants in different make targets. also consider a VPATH build. * clean rules unpatches before running clean. This will break if you had modifications to the clean parts of the build system. You don't do that here, but I'm mentioning it just in case. The src/arch directory seems to contain source files of various licenses, that I believe are part of the created binaries. I therefore do not think that we can redistribute the radare binary under GPLv2. E.g.: - src/arch/dalvik seems to come from the android project, which is Apache License 2.0. Please note that in debian/copyright. - src/arch/x86/udis86/* seem to be BSD licensed. - the files in src/arch/sparc seem to be GPL-3 licensed. In general, run the tool `devscripts -r .` in the top level root directory to get a brief license check. AFAIUI this is the tool ftpmaster uses to examine NEW packages. I fear debian/copyright needs to mention all this. Are there other opinions on that from mentors? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#469397: ITP: xbmc -- XBox Media Center Linux Port
Andres Mejia writes: > On Monday 27 April 2009 11:38:04 Paul Menzel wrote: >> As you probably know XBMC 9.04 (Babylon) Beta 1 was released some days >> ago [3]. >> >> XBMC could probably attract more users and get more testing, if it is >> packaged for Debian. >> >> Could you give us a status update, please? > > Alright. I'm still working on getting xbmc to use system libs instead of the > internal libs included with the xbmc source. I've had a setback with ffmpeg > where > I had to drop back to using the internal libs for ffmpeg. I haven't gotten > around > to fixing this. What version of ffmpeg does xbmc include? I think a lot of trouble can be avoided if a version is integrated that is shared by debian and other ffmpeg downstreams. Since version 0.5 was released recently, that would be a good candidate. In fact, Debian tracks the 0.5 release branch of ffmpeg, and will probably keep tracking it for quite some time. > As with the FHS issue, I think this will be a trivial fix anyway so once xbmc > uses system libs, then an upload to Debian will surely follow soon. > > For anyone wondering, there's a 99.9% chance there won't be an upload for the > release of XBMC 9.04 to Debian. :-( how often/frequently does xbmc release? is there a roadmap? http://xbmc.org gives me a 500 - Internal Server Error ATM. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527746: RFP: dirac -- advanced royalty-free video compression format
Andres Mejia writes:
> Package: wnpp
> Severity: wishlist
>
> * Package name: dirac
> Version : 1.0.2
> Upstream Author : Thomas Davies
> * URL : http://diracvideo.org/
> * License : MPL 1.1, LGPL, GPL, MIT
> Programming Lang: C
> Description : advanced royalty-free video compression format
>
> Dirac is an advanced royalty-free video compression format designed for a wide
> range of uses, from delivering low-resolution web content to broadcasting HD
> and
> beyond, to near-lossless studio editing.
Ubuntu already has this packaged, here the latest few changelog entires:
dirac (1.0.2-0ubuntu1) jaunty; urgency=low
* New upstream release
* debian/watch: Remove "debian uupdate"
* debian/control: Add ${misc:Depends} to all packages
* debian/{control,rules,patches/*}: Drop patchsys and patch as applied
upstream.
-- Iain Lane Wed, 18 Feb 2009 23:29:52 +
dirac (1.0.0-0ubuntu1) jaunty; urgency=low
* New upstream release 1.0.0 (LP: #302954)
* debian/dirac.manpages, debian/dirac.links: Move manpage and symlink
names out into separate files. Add missing manpage links.
* debian/BMPtoRGB.1: Update with missing manpages.
-- Iain Lane Fri, 28 Nov 2008 00:03:56 +
dirac (0.10.0-0ubuntu1) intrepid; urgency=low
* New upstream release (LP: #259495)
* debian/patches/warn_unused_result.patch: Patch some fwrite calls to take
results, fixing FTBFS. Also b-d on quilt for this.
-- Iain Lane Tue, 19 Aug 2008 20:27:46 +0100
dirac (0.9.1-0ubuntu2) hardy; urgency=low
* debian/control: Added missing build-dependencies for documentation.
-- Matvey Kozhev Thu, 14 Feb 2008 01:31:42 +0600
http://packages.ubuntu.com/karmic/dirac
I'd suggest to just import that package into our git repository and use
that as basis for the debian packaging.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532690: [Openal-devel] ALURE 1.0 Debian packages
Andres Mejia writes: >> > Also, I see there's an option for building a static library but doesn't >> > allow it to be built with the shared library. This isn't like OpenAL Soft >> > where there's no such option and the -DLIBTYPE=STATIC option has to be >> > passed into cmake. For ALURE, do you have any objections for installing >> > static libraries alongside shared libraries? >> >> My main reservation with static libraries with ALURE (as opposed to OpenAL) >> is that it shares the same name as the shared lib. If you install both >> libalure.so and libalure.a, then linking with -lalure will always pick the >> shared lib AFAIK. Conversely, libalure.a isn't needed for any pre-compiled >> binaries, and since pkg-config isn't flexible enough to "select" between >> shared and static, all linking the user does would use the shared lib if >> it's there. > > -lalure would indeed pick the shared lib by default. I will go ahead and > provide > a static library for ALURE in Debian as well. May I ask why? For debian, we generally try to avoid static libraries if there is no good reason for that. If there is a good reason[1] for dong so, please add a note in the package. If it is only for convenience for the users, I'd recommend to not ship the .a and .la files at all, since IME it avoids headaches in the future. [1] good reasons include massive performance gains, extra features, etc. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532690: [Openal-devel] ALURE 1.0 Debian packages
Andres Mejia writes: >> [1] good reasons include massive performance gains, extra features, etc. > > It's merely for convenience to users. > > Who's "we" by the way? I see various static libraries on my system alone, > including static libs for libc, zlib, libbz2, and freealut, so I'm guessing > "we" > is not Debian. Well, I'm perhaps overexaggerating here. For libc, zlib and libbz2 I do see uses cases, and I'm fairly sure that there are some other packages that link statically. At least for these libraries, I can see why users really expect to have the static libraries around. does this apply as well to alut, openal and alure as well? If yes, then shipping alure.a is no problem. if not, I'd recommend to spare the headaches here. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532690: [Openal-devel] ALURE 1.0 Debian packages
Andres Mejia writes: > What headaches? Forgive my lack of imagination here. Right now I don't see a > reason why static libraries should be removed. I'm not for removing, I'm more for not introducing them in the first place. Recent problem (fail to find the bugno, sry), libjack-dev used to ship a .la file, which has been dropped. Other libraries that can use jack still referenced the jack.la in their own .la fail, which rendered application to FTBFS. Solution: recompile the intermediate libraries to drop the reference .la file. As said, aybe I'm really just overexaggerating here and try to be too cautious. alure seems a really small library with rather few users, so it probably doesn't matter here. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
Paul Bone writes: > This is mostly correct. Mercury is indeed self-hosting and was > previously included in Debian. Mercury has a number of different > backends two of these target C, high-level C and low-level C. The > Mercury source distribution includes C intermediate files for the > standard library and compiler generated by the low-level C backend, > these can be compiled with GCC to generate binaries which can be used to > bootstrap an installation by re-compiling the Mercury sources. > > I have a working Debian package that builds and bootstraps Mercury from > the source distribution. It requires gcc-3.4 as a build-depend and is > able to bootstrap itself so that the resulting binaries are optimal on > 32bit and 64bit machines (the explanation involves a discussion of > tagged pointers). > > I hope that this will be acceptable by the Debian project and that > distributing intermediate files in the .orig.tar.gz file is not a > problem. The same applies to the package aspectc++, a package that I maintain since some time. AspectC++ is a language extension for C++ for aspect oriented programming (AOP). It is built on top of an C/C++ Parsing and Manipulation framework (PUMA), where some functionality (e.g. support for various GNU language extension) is implemented using AspectC++ aspects. There you have a pretty similar situation, and I'm doing a very similar approach: Shipping intermediate files that can be processed with gcc. I suggest that you use these intermediate files only for compiling an intermediate compiler for bootstrapping. With that compiler, redo all intermediate files and build the binaries of the compiler that will eventually end up in the package. This ensures that you'll end with a working compiler on all architectures. BTW, this approach was actually suggested to me by Lamont Jones a few years ago. It seems to be a quite common approach, FWIW. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534144: ITP: opencore-amr -- libraries for Adaptive Multi Rate (AMR) OpenCORE implementation
Andres Mejia writes: > On Tuesday 04 August 2009 04:20:54 Fabian Greffrath wrote: >> Fabian Greffrath schrieb: >> > the packages in our GIT repository look good despite the fact that they >> > still track version 0.1.0. When do you plan to upgrade them to 0.1.1 and >> > upload to Debian? >> >> Andres?! > > Sorry, was waiting for Martin to respond to me about what the next version of > opencore-amr should be. Because of the way libtool forces the values of > library > versions to be a certain way, we might have to downgrade to 0.0.2, unless he > thinks the API is stable to merit a version 1.0.0. What about uploading 0.0.2 right now to get it at least out of NEW? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#492477: Notes about the loggerhead package
Hi Jelmer, here some notes I made while reviewing the loggerhead package: - it installs a conffile /etc/loggerhead.conf. After having a short look at it, it seems to me that for almost every usecase, the user is expected to edit this file. This means that on every upgrade where we edit the default config, a conffile change will happen. I don't think this is really what we want. How about shipping the default config in /usr/share/doc/loggerhead/example.conf and guide the user in a README.Debian file to copy it manually to /etc/loggerhead.conf? He needs to adapt the file anyways. This way we can also get rid of that /etc/default/loggerhead file. The initscript could then just check for the presence of /etc/loggerhead.conf and be done with it. - init script. The dependencies in loggerhead currently state this: # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog I'm not sure if this is right. The source does not reference syslog anywhere, moreover, AFAIUI loggerhead requires the network to be up. Therefore I suggest "$local_fs $remote_fs $network" instead (inspired by the apache2 init script) - any particular reason to upload to experimental? I propose uploading to unstable instead. Sure, it won't make it for the lenny release, but unless it is in an highly experimental state that we don't want 'regular' users to use and test it, I see no reason to 'hide' it in experimental. Please comment on the 3 points above and indicate if you agree or disagree. I'll go on with uploading when we sort these changes out. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#555852: [Romain Beauxis] gmerlin-avdecoder_1.0.1-2_amd64.changes REJECTED
Forwarding the current status of this ITP. Short summary: It was rejected by ftpmasters because of issues in debian/copyright. The package currently needs someone to pick up the package and cleanup the file. --- Begin Message --- Hi ! Guys, I've had it with this package. Fabian, if you want to fix the copyright file, I'll upload your package. However, I'm not touching it myself anymore. Romain -- Message transmis -- Sujet : gmerlin-avdecoder_1.0.1-2_amd64.changes REJECTED Date : samedi 28 novembre 2009 De : Barry deFreese À : Romain Beauxis , Debian Multimedia Team Timestamp: 2009-11-25 16:57:08.810103+00:00 The new upload fixes some but there are still several issues: missing license/copyright statements: License of files in lib/GSM610 is not in debian/copyright lib/GSM610/gsm_encode.c: * Copyright 1992 by Jutta Degener and Carsten Bormann, Technische lib/GSM610/gsm_encode.c: * Universitaet Berlin. See the accompanying file "COPYRIGHT" for lib/GSM610/gsm_encode.c- * details. THERE IS ABSOLUTELY NO WARRANTY FOR THIS SOFTWARE. more files... lib/GSM610/README:Copyright 1992, 1993, 1994 by Jutta Degener and Carsten Bormann, more files... Unclear or missing license on files in lib/libw32dll/dmo/* lib/libw32dll/dmo/DMO_VideoDecoder.c: Copyright 2000 Eugene Kuznetsov (d...@euro.ru) lib/libw32dll/dmo/DMO_AudioDecoder.c: Copyright 2001 Eugene Kuznetsov (d...@euro.ru) more files... lib/libw32dll/wine/pe_image.c: * Copyright 1994Eric Youndale & Erik Bos lib/libw32dll/wine/pe_image.c: * Copyright 1995Martin von L.wis lib/libw32dll/wine/pe_image.c: * Copyright 1996-98 Marcus Meissner lib/libw32dll/wine/windef.h: * Copyright 1996 Alexandre Julliard lib/libw32dll/wine/module.c: * Copyright 1995 Alexandre Julliard more files... lib/libw32dll/wine/ldt_keeper.c: * Copyright (C) 2000-2003 the xine project more files... lib/libw32dll/wine/resource.c: * Copyright 1993 Robert J. Amstadt lib/libw32dll/wine/resource.c: * Copyright 1995 Alexandre Julliard lib/libw32dll/wine/registry.h: * Copyright 2000 Eugene Kuznetsov (d...@euro.ru) more files... lib/libw32dll/wine/elfdll.c: * Copyright 1999 Bertho A. Stultiens lib/libw32dll/wine/vfl.c: * Copyright 1998 Marcus Meissner Therefore I am rejecting this package again. Thank you, Barry deFreese Debian FTP Assistant === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. --- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers --- End Message --- -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Bug#469397:
Mathieu Malaterre writes: > The current package needs: > > $ dpkg-checkbuilddeps > dpkg-checkbuilddeps: Unmet build dependencies: libvdpau-dev | > nvidia-190-libvdpau-dev | nvidia-185-libvdpau-dev | > nvidia-180-libvdpau-dev > > > This should be changed to accept: > > http://packages.debian.org/sid/nvidia-libvdpau-dev > > $ apt-cache policy nvidia-libvdpau-dev > nvidia-libvdpau-dev: > Installed: 195.22-1 > Candidate: 195.22-1 > Version table: > *** 195.22-1 0 > 100 /var/lib/dpkg/status > 190.42-3 0 > 100 http://ftp.fr.debian.org unstable/non-free Packages the problem is that nvidia-libvdpau-dev is in non-free, whereas ffmpeg is in main. Packages in main must not build depend on packages in non-free. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560410: ITP: alsoft-conf -- OpenAL-Soft configuration utility
Matias D'Ambrosio writes: > Package: wnpp > Severity: wishlist > Owner: "Matias D'Ambrosio" > > > * Package name: alsoft-conf > Version : 1.4.3 > Upstream Author : Matias D'Ambrosio > * URL : http://www.anduin.net/~angasule/ > * License : GPL2 > Programming Lang: C++ > Description : OpenAL-Soft configuration utility > > An easy to use GUI tool to configure OpenAL-Soft. Perhaps it makes sense to maintain it togehter with openal-soft in the debian games team? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569641: Bug#569635: ITP: libva -- Video Acceleration (VA) API for Linux
Hi Andres, On Mo, Feb 15, 2010 at 20:06:46 (CET), Andres Mejia wrote: > Packaging for libva is available at > git://git.debian.org/git/pkg-multimedia/libva.git > http://git.debian.org/?p=pkg-multimedia/libva.git;a=summary On Friday 12 February 2010 19:41:50 Andres Mejia wrote: > Packaging for vdpau-video is available at > git://git.debian.org/git/pkg-multimedia/vdpau-video.git > http://git.debian.org/?p=pkg-multimedia/vdpau-video.git;a=summary I've looked at both packages, they both seems fine licensing and build-script wise. However, both use source format 3.0 (quilt). We have decided in the past against this package due to deficiencies in git-buildpackage for that format. I'd therefore suggest to revert to format 1.0 until we generally agree to upgrade existing packages. Moreover, do you know if libva works with GM945 chipsets? If yes, you have me as co-maintainer. If not, is there perhaps someone else in the team interested in these two packages? Regarding vaapi in general, I've heard that nivdia's vdpau supports hardware deinterlacing. Does something similar exist for vdpau? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871vgeuyzi@faui44a.informatik.uni-erlangen.de
Bug#573345: ITP: radare2 -- free advanced command line hexadecimal editor
On Wed, Mar 10, 2010 at 19:06:18 (CET), Sebastian Reichel wrote: > Note: radare2 coexists with radare1 and the binary of this package is > called radare2, so I name the source package radare2, too. But I don't > plan to continue maintaining radare1. I will ask for removal once radare2 > is in the repository. what is upstreams opinion on this? is radare1 superseeded upstream? In that case, I'd rather avoid introducing a new package name and just upload the new version with the name 'radare', automatically replacing the old one. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878wa0ggc8@faui44a.informatik.uni-erlangen.de
Bug#416605: boxbackup in debian
[cc'ing the ITP bug in debian, it seems that quite some ppl are subscribed there] Hi Jérôme, As you surely have noticed, I intend to maintain boxbackup in debian as an official package. I mainly took your packages as base, and fixed the remaining lintian warnings. Nice work on the debconf'isation! I have uploaded test packages at http://siretart.tauware.de/upload-queue for public reviewing and/or testing. I would very appreciate it if you could have a look at it and tell me if something important is missing. According to Chris Wilson, there have been a "few known bugs" in 0.10. It would be great if someone could cherry-pick the changes from the svn trunk, I'll glady incorporate them into my tree. I'm maintaining the packages in bzr. You can browse the source package at [1]. In order to get the history of my source package, use the following command to get a copy of my branch: apt-get install bzr bzrtools bzr get http://bazaar.launchpad.net/~siretart/boxbackup/boxbackup.debian I intend to upload my packages this week (maybe wednesday) to debian unstable, unless someone raises objections. Please note that it might take some additional weeks until it gets reviewed by the debian ftp-masters and eventually enters unstable. Happy hacking! [1] http://codebrowse.launchpad.net/~siretart/boxbackup/boxbackup.debian/files -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpJwHz0ZQ7lK.pgp Description: PGP signature
Bug#416605: boxbackup in debian
Jérôme Schell <[EMAIL PROTECTED]> writes: > Reinhard Tartler a écrit : >> Hi Jérôme, >> > > Hi Reinhard, > >> As you surely have noticed, I intend to maintain boxbackup in debian as >> an official package. I mainly took your packages as base, and fixed the >> remaining lintian warnings. Nice work on the debconf'isation! >> > > Thanks, I'm glad that my work on this package could, at last, hit the > Debian archive :) Absolutely! >> I have uploaded test packages at http://siretart.tauware.de/upload-queue >> for public reviewing and/or testing. I would very appreciate it if you >> could have a look at it and tell me if something important is missing. >> > > Unfortunately, I don't think I have, at the moment, a system to test > your packages on :( What system would you have available? ubuntu or other debian based Distribtutions would work fine for me as well. Would you like to be listed as Co-Maintainer when I upload the package to Debian? > The only thing I see is the need to remove reference to boxbackup-utils > package in README.Debian as you suppressed this package. Thanks for noticing this, will correct this before uploading. Another issue, perhaps you can help me with this: What happens on package upgrades with local changes? If an admin customizes the config, do your scripts preserve local changes? I'm not too familiar with debconf programming, but it doesn't really look like it. It seems that I need to do some upgrade tests. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpFlxvW3O7ZH.pgp Description: PGP signature
Bug#401800: work ongoing in ubuntu to package this
There is work ongoing to package ecryptfs for ubuntu. It is tracked by this bug: https://bugs.launchpad.net/ubuntu/+bug/114426 To see the current state of affairs, follow the bugtrail or see the package online at: http://codebrowse.launchpad.net/~x1/+junk/ecryptfs-utils/changes -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405616: DeSmuME Debian packaging
"Pascal Giard" <[EMAIL PROTECTED]> writes: > Hello Reinhard, > i'm a DeSmuME developper and Debian maintainer. Hi there, nice to meet you. > I've already created a Debian package for the 0.7.0 version. > Debian packaging files are available in the CVS tree at > http://desmume.cvs.sf.net . > > May I suggest that you use my packaging files? Oh, I already packaged DesMuMe for the debian Games team. You can find the package here: http://svn.debian.org/wsvn/pkg-games/packages/trunk/desmume/?rev=0&sc=0 I actually uploaded it to ubuntu already, but didn't do so for debian yet. The main reason is that I waited for comments on my packaging and at least one ack from another member, but didn't get any feedback. I don't use DesmuME anymore, since my girlfriend bought an DS, and therefore I play now on real hardware ;) Anyway, how to proceed from here? May I suggest you look at what is currently in the debian games team svn and give me feedback about it? If you are okay with what is there, I'll just upload it to debian with the Maintainer set to the debian games team. If we do so, may I suggest you to join the debian games team so you can directly commit to our team's svn? In case you don't know about the Debian Games Team yet, please see http://wiki.debian.org/Games/Development. In short: * irc at #debian-games on oftc * DGT is an alioth team. You need an alioth account to join * to apply, just leave a team's admin (goneri, eddyp or baby) a message on irc or email. You don't need to be an debian developer for this, you get svn commit access and an alioth shell account instantly. Thanks for your work on DesmuME. Looking forward to hear from you soon, -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpw7mI4ZHt8R.pgp Description: PGP signature
Bug#405616: DeSmuME Debian packaging
"Pascal Giard" <[EMAIL PROTECTED]> writes: > Done. I'm now part of the Debian Games Team. Welcome to the team! :) > I've looked at your packaging files and would like to keep and improve > your manpage but i'd rather stick with my packaging files for the > rest. > > Why? Mostly because cdbs makes the debian/rules smaller and easier to read. The debian games team packaging policy mandates the usage of debhelper. Moreover, I'm not too comfortable with cdbs either (but use it myself for python packages). I therefore decided to stay with debhelper. If the other team members don't object with the packaging being cdbs, I don't mind much here as well. > Also, i noticed that your ubuntu package is missing few important files... > Namely, the menu entries but more importantly the glade interface files. Ah, thanks for review! > You mentionned that you're not using DeSmuME anymore. With your > permission, i'd take over maintenance of the package. (In practice, > the maintainer would still be the Debian Games Team). > > What do you think? I very welcome this idea, please proceed. If you need an upload to debian, just tell me, I'll happily sponsor you. I'll also arrange the new package to be synced over the ubuntu one. Thanks for your work on the package -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpp3OnUlMSe9.pgp Description: PGP signature
Bug#416605: [Box Backup] debian.myreseau.org - New Debian Packages only for stable?
Wolfgang Trexler <[EMAIL PROTECTED]> writes: > On my Debian Etch Server there are new packages proposed for boxbackup, > while I didn't see them for oldstable (sarge). What is the reason for > these new packages, it would be nice if such changes could be announced > here... > > Reading package lists... > Building dependency tree... > The following packages will be upgraded: > boxbackup-client boxbackup-server > 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > Inst boxbackup-client [0.10-1] (0.10-1 debian.myreseau.org) > Inst boxbackup-server [0.10-1] (0.10-1 debian.myreseau.org) > Conf boxbackup-client (0.10-1 debian.myreseau.org) > Conf boxbackup-server (0.10-1 debian.myreseau.org) I've just uploaded a boxbackup package to backports.org. [1] has instructions how to use it. Please note about the versioning: The package in debian/etch has (currently) the version number 0.10-1 (and is built against glibc2.5). This means that you cannot upgrade from the package you got from debian.myreseau.org directly, but must manually check/install the package. The backport I've built and uploaded to backports.org has the version number 0.10-1~bpo.1 (and is built against glibc2.3, the one from etch). This is lower than 0.10-1 to ensure that there is an upgrade path from etch to lenny. If anyone finds problems with that packages, or wants to help out with maintaining them, do not hesitate to contact me! [1] http://backports.org/dokuwiki/doku.php?id=instructions -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409563: Any testpackages available?
I see that ITP has been stale since February. However, there seems to be an alioth team created, but I don't see a thinkfinger package there. What's the problem with the current packages? Are you still working on them? Do you need a sponsor? Beein keen on testing the testpackages ;) Reinhard! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpwOZatqk7DN.pgp Description: PGP signature
Bug#573345: radare2 package
On Fri, Mar 26, 2010 at 19:45:50 (CET), Sebastian Reichel wrote: > Reinhard Tartler: Can you sponsor the package? I had a look at the package, but this "Format 3.0 (quilt)" gives me headaches: $ gbp-clone git://git.debian.org/collab-maint/radare.git $ cd radare $ git-buildpackage -S seems to work. however, now the working copy is dirty (check git status) and a file debian/patches/debian-changes-0.4-1 is created with this as comment: , | Description: Upstream changes introduced in version 0.4-1 | This patch has been created by dpkg-source during the package build. | Here's the last changelog entry, hopefully it gives details on why | those changes were made: | . | radare2 (0.4-1) unstable; urgency=low | . |* Initial release (Closes: #573345) | + build system patch to add version to the libs | + disable asm.m68k, BSD 4 clause is GPL incompatible | . | The person named in the Author field signed this changelog entry. | Author: Sebastian Reichel | Bug-Debian: http://bugs.debian.org/573345 ` This also appears in debian.tar.gz. I cannot imagine this is really intended. Please clarify. TBH, I don't think "Format 3.0 (quilt)" works nicely with git-buildpackage. How about using "Format 3.0 (native)" instead? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6h44zgv@faui44a.informatik.uni-erlangen.de
Bug#477572: RFP: python-pymedia -- Python module for editing wav, mp3, ogg, avi, divx, dvd files
On Sat, Apr 10, 2010 at 06:27:56 (CEST), Per W. wrote: > - The pymedia project includes much of the ffmpeg code, while it should > better dynamically link to the existing ffmpeg libs (like > libavformat.so.52 and libavcodec.so.52) > - The included ffmpeg code is badly outdated and not cleanly separated > - The code-base seems to be unmaintained. > - It depends on the i386 architecture > - We already have python-gst0.10 and pygame for python multimedia support > > So it might be a bad idea to Maintain a Debian package for pymedia. > Anyway I created a initial package for you to experiment with. > In the current state the package compiles and installs without problems > on amd64 but the import fails. I've skimmed a bit over upstream source, and it seems that not only avcodec, but also parts of liba52 and faad are included. On the first sight, all of these copy look rather ancient to me, but I may be wrong. in any case, I don't think the approach pymedia has taken is a good candidate for debian. While the project itself seems interesting, I'd strongly recommend a serious reengineering that includes using system libraries before working any further on packaging. I didn't even look at your packaging, because you have decided to only commit the debian/ directory in you svn without the upstream source. Therefore, I went to the upstream webpage and downloaded the source tarball. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ljcvh5um@faui44a.informatik.uni-erlangen.de
Bug#457272: status update
packaging is currently on git.debian.org http://git.debian.org/?p=pkg-multimedia/dvbcut.git;a=summary But I currently don't have the time (and interest) to finally upload it to debian. It seems that an ubuntu user called 'bojo42' has updated the packaging in his PPA: https://launchpad.net/~bojo42/+archive/dvbcut Next steps would be to update to integrate this work into the pkg-multimedia packaging branch and eventually upload it to debian. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bpd6mrtc@faui44a.informatik.uni-erlangen.de
Bug#581760: ITP: myscreen -- A tab system and display system statistics for screen
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.general as well. On Sat, May 15, 2010 at 17:59:37 (CEST), Clément Mondon wrote: > Package: wnpp > Severity: wishlist > Owner: "Clément Mondon" > > > * Package name: myscreen > Version : 0.7 > Upstream Author : Clément Mondon > * URL : http://www.clement-mondon.fr/myscreen > * License : GPL > Programming Lang: C > Description : A tab system and display system statistics for screen >myscreen is a configuration of screen, a full-screen window >manager that multiplexes a physical terminal. >myscreen include screen configuration file and a program >that provides several statistics. >Configuration file allows to enable hardstatus bar in the >manner of a tab system of graphical terminal. >The program myscreen-stats provides several informations : >number of users connected, uptime, upload and download rate, >wifi quality, loadaverage, number of processes, cpus, disks, >ram and swap. > >myscreen-stats was written in C unlike ubuntu's package >named screen-profiles. is this intended to be part of the description? If yes, I'd suggest to drop it, because: - it has been renamed to byobu - the package is in debian as well - is the implementation helpful information to decide which of the two more appropriate for a given usecase? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87632p6k3l@faui44a.informatik.uni-erlangen.de
Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol
retitle 529974 ITP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol owner 529974 ! stop I'm going to package rtmpdump next week. On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote: > * Package name: rtmpdump > * URL : [hidden obsolete url] > * License : GPL > Programming Lang: C++ > Description : download media streamed with the RTMP/RTMPE protocol > > A small dumper for media content streamed over the RTMP/RTMPE protocol. > Supplying an rtmp url will result in a dumped flv file, which can be > played/transcoded using ffmpeg/mplayer, etc. A download script for BBC's > iPlayer streams is included. As Howard already mentioned, the mplayer project hosting kindly offers hosting for rtmpdump these days, so I'll package that. Not only that, but that package also provides librtmp, which ffmpeg 0.6 can use. For this reason I'm going to take this package under the pkg-multimedia umbrella. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-wnpp
Bug#530427: Upload to debian?
Hi, I'm wondering about the status on this ITP. i noticed the packaging here: http://git.debian.org/?p=pkg-libvirt/libguestfs.git;a=summary but no packages in the archive yet. Can you perhaps give some status update about your upload plans? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxsdd8sg@faui44a.informatik.uni-erlangen.de
Bug#530427: [Pkg-libvirt-maintainers] Upload to debian?
On Mon, Aug 23, 2010 at 13:52:13 (CEST), Guido Günther wrote: > We basically need to split out the build of the appliance and make that > downloadable from an external URI. Not much work but nobody got around > to it so far. Another way would be to fix the supermin appliance build > for Debian but that would involve a lot of dependencies to be installed > on the VM host. > Cheers, Oh, I see. Thanks for you great work on pkg-libvirt! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eidptuel@faui44a.informatik.uni-erlangen.de
Bug#601114: ITP: ffms2 -- An FFmpeg based source library and Avisynth plugin for easy frame accurate access
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: ffms2 Version : 2.13 Upstream Author : Fredrik Mellbin, Mike Matsnev * URL : http://code.google.com/p/ffmpegsource * License : MIT (but debian packages will be GPL'ed because of linking against ffmpeg) Programming Lang: C++ Description : An FFmpeg based source library and Avisynth plugin for easy frame accurate access FFmpegSource (usually known as FFMS or FFMS2) is a cross-platform wrapper library around FFmpeg, plus some additional components to deal with file formats FFmpeg's libavformat has (or used to have) problems with. It gives you an easy, convenient way to say "open and decompress this media file for me, I don't care how you do it" and get frame- and sample-accurate access (usually), without having to bother with the sometimes less than straightforward and less than perfectly documented FFmpeg API. The library is written in C++, but the public API is C-friendly and it's easy to simply include and link directly with a pure C application. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101023145241.1387.37824.report...@debian
Bug#601114: ITP: ffms2 -- An FFmpeg based source library and Avisynth plugin for easy frame accurate access
On Sat, Oct 23, 2010 at 16:52:41 (CEST), Reinhard Tartler wrote: > Package: wnpp > Severity: wishlist > Owner: Reinhard Tartler > > * Package name: ffms2 > Version : 2.13 > Upstream Author : Fredrik Mellbin, Mike Matsnev > * URL : http://code.google.com/p/ffmpegsource > * License : MIT (but debian packages will be GPL'ed because of > linking against ffmpeg) > Programming Lang: C++ > Description : An FFmpeg based source library and Avisynth plugin for > easy frame accurate access > > FFmpegSource (usually known as FFMS or FFMS2) is a cross-platform > wrapper library around FFmpeg, plus some additional components to deal > with file formats FFmpeg's libavformat has (or used to have) problems > with. It gives you an easy, convenient way to say "open and decompress > this media file for me, I don't care how you do it" and get frame- and > sample-accurate access (usually), without having to bother with the > sometimes less than straightforward and less than perfectly documented > FFmpeg API. > > The library is written in C++, but the public API is C-friendly and > it's easy to simply include and link directly with a pure C > application. I've now imorted the source, I'd be glad for reviews and comments. I'd really appreciate if some uscan expert coult write a debian/watch file for this package that downloads updated sources from googlecode and repacks the 7z source to tar.gz or tar.bz2. thanks in advance! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwvwpx6g@faui44a.informatik.uni-erlangen.de
Bug#515850: RFP: mjpegtools - MJPEG video capture/editting/playback MPEG encoding
On Thu, Sep 03, 2009 at 10:14:02 (CEST), Fabian Greffrath wrote: > Reinhard Tartler schrieb: >>> Will it make sense to start packaging in pkg-multimedia git now? >> if you have some spare time, why not. I just fear that it will rott in >> NEW. It wouldn't be the first package to end like that :-( > > Regarding mjpegtools, I think the source even got some more severe > license issues than the ones you pointed out before, > e.g. mjpegtools-1.9.0/aenc/common.h (and several other files in aenc/): > > /* > * Copyright (c) 1991 MPEG/audio software simulation group, All Rights > Reserved > * common.h > */ > /** > * MPEG/audio coding/decoding software, work in progress * > * NOT for public distribution until verified and approved by the * > * MPEG/audio committee. For further information, please contact * > * Davis Pan, 508-493-2241, e-mail: p...@gauss.enet.dec.com * > [...] > > Doen's look likely to meet the DFSG requirements. :( I took another look at the source code. Indeed, is some considerable work in the package that is derived from the MSSG (the Mpeg software simulation group). More information on that group can be found here: http://www.mpeg.org/MPEG/video/mssg-free-mpeg-software.html It is basically a buggy, orphaned and incomplete reference implementation, which projects like mjpegtools took as basis and improved them. The original authors disappeared, and from what I deduce from http://www.mpeg.org/MPEG/mpeg-pointers-and-resources/, the MSSG software is considered "public-domain" nowadays. I guess we can and should try to get the package into debian, with these pieces of information included in debian/copyright. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaksun9q@faui44a.informatik.uni-erlangen.de
Bug#277538: Still interested in this package?
Hi there, I just saw your ITP in #277538. Are you still interested in this package? I saw that you uploaded a first package to mentors (http://mentors.debian.net/debian/pool/main/a/aspectc++/). Is this your current state? Is some newer work somewhere available? I'd like to offer help. As I started working with AspectC++ I'm quite interested in having a good AspectC package. I'm doing research about behavior of aspectc++ programs. How do you intend to manage the file puma.config? In your package, I don't see any handling with that. I would suggest writing wrapper scripts that set variable PUMA_CONFIG to a generated puma.config file generated by the postinst script. I noticed that you renamed the source package from ac++ to aspectc++. I like the latter name better, since ac++ is just one part of aspectc++. -- Reinhard Tartler <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#295682: RFS: pong2 -- Remake of old arcade classic in OpenGL
Package: wnpp Severity: normal * Package name : pong2 Version : 0.1.0-1 Upstream Author : Johannes Jordan <[EMAIL PROTECTED]> * URL : http://pong2.berlios.de/ * License : GPL Description : Pong2 is an up till now two player (networked) game inspired by the classical "Pong" from Amiga, which adds another dimension to the playing field. Crazy graphics, fast gameplay, great fun ;) . It also has multiplayer support! 2 players can play against each other. This is my first RFS. I checked my package with Matthew Palmers Checklist for sponsored uploads. It should be fine, but I'm open for any suggestions. Package builds cleanly within sarge and sid (tested with pbuilder) and has been tested on i386 and amd64. I think it is ready for inclusion in debian. You can get my source package from: http://siretart.tauware.de/pong2 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#295682: pong2 package in NEW
tags pending thanks Lucas Wall kindly sponsored my package, it is sitting in the NEW Queue right now and is awaiting approval. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#306333: ITP: londonlaw
Package: wnpp Severity: wishlist Package Description: london law game London Law is an online multiplayer adaptation of the classic Scotland Yard board game (also see Wikipedia), first published by Ravensburger in 1983. The game is unusually asymmetric; one player controls the movements of the criminal Mr. X as he tries to evade Scotland Yard, while another one to five players control five detectives trying to track him down. Mr. X has an advantage in access to transportation routes, and his precise location remains hidden for most of the game. The detectives have only the advantage of superior numbers, so they must work in concert to limit the criminal's options. London Law features an attractive map overlaid on high-resolution satellite imagery. This python game was packaged using cdbs. Prelimary packages are at http://siretart.tauware.de/debian/londonlaw/ I'm currently looking for a sponsor for this package, since I'm not a DD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310994: ITP: openttd -- open source clone of the Microprose game "Transport Tycoon Deluxe"
On 5/27/05, Matthijs Kooijman <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Matthijs Kooijman <[EMAIL PROTECTED]> > > > * Package name: openttd > Version : 0.4.0.1 > Upstream Author : Various > * URL : http://www.openttd.org/ > * License : GPL > Description : open source clone of the Microprose game "Transport > Tycoon Deluxe" > > I am working on this package and would like to see it in debian. I am still > looking for a sponsor until I can apply as NM. As far as I understood it, it requires media files from the original game. Is this correct? Or are there free media files available? -- regards, Reinhard
Bug#316503: ITP: istanbul -- Desktop session recorder
On 7/1/05, Luca Bruno <[EMAIL PROTECTED]> wrote: > * Package name: istanbul > Version : 0.1.0 > Upstream Author : Zaheer Abbas Merali <[EMAIL PROTECTED]> > * URL : http://live.gnome.org/istanbul > * License : GPL > Description : Desktop session recorder > > Istanbul is a desktop session recorder for the Free Desktop. > It records your session into an Ogg Theora video file. > To start the recording, you click on its icon in the > notification area. To stop you click its icon again. > .. > It works on Gnome, KDE, XFCE and others. you might be interested to learn that Daniel Holbach already packaged this for ubuntu, you may grab his sourcepackage from here: http://siretart.tauware.de/revu/details.py?upid=15 He will be glad to hear that you intend to maintain it for debian! -- regards, Reinhard
Bug#637765: ITP: pcsc-cyberjack -- REINER SCT cyberJack USB chipcard reader user space driver
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
* Package name: pcsc-cyberjack
Version : 3.99.5final.SP02
Upstream Author : Matthias Bruestle, Harald Welte, Martin Preuss
(supp...@reiner-sct.com)
* URL : http://www.reiner-sct.de/
* License : LGPL 2.1+
Programming Lang: C
Description : REINER SCT cyberJack USB chipcard reader user space driver
Package: libifd-cyberjack6
Architecture: any
Depends: pcscd, ${misc:Depends}, ${shlibs:Depends}
Suggests: pcsc-tools
Recommends:
Description: REINER SCT cyberJack USB chipcard reader user space driver
This package includes the IFD driver for the cyberJack contactless
(RFID) and contact USB chipcard reader.
Package: fxcyberjack
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Recommends: libifd-cyberjack6
Description: Graphical diagnostics and maintenance tool for Reiner SCT
Cyberjacks
This package contains the graphical tool which allows diagnosing
typical driver setup problems. It is also able to flash new software to
current cyberJack readers.
Suggestions for improvements of the descriptions are very welcome.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110814084456.28637.10568.report...@faui43f.informatik.uni-erlangen.de
Bug#578787: Fwd: [Open Octave Development] New Anouncement List
Hi, it seems to me we don't even have the package in Debian yet, altough there is an ITP (#578787), and a git repo: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/oomidi.git It seems to me that 'oomidi' might not be the best name for the package. How about renaming it to openoctave? Just to clarify, Jonas, Adrian, are you still interested and working on the package? I personally won't have time and hardware to work on it, but it seems to me that the package is a bit in the limbo since April. In any case, I think a working package and a watch file is more useful for pkg-multimedia than subscribing to yet another mailinglist. But YMMV. Cheers, Reinhard On Sa, Okt 08, 2011 at 11:20:51 (CEST), rosea grammostola wrote: > Original Message > Subject: [Open Octave Development] New Anouncement List > Date: Fri, 07 Oct 2011 18:26:36 -0600 > From: Christopher Cherrett > Reply-To: developm...@openoctave.org > To: developm...@openoctave.org, m...@openoctave.org > > > > *Note to distro packaging specialists*. We've created an announce > mailing list for news and developments for OOM, including announcements > for tarball releases. You may miss the thrills and overwhelming > excitement of our regular mailing lists, but the announce ML will keep > you informed, so you can package from the latest builds. We hope you > take advantage of this, and keep all of our shared users up to date with > the latest features and developments from the OpenOctave team. Thanks! > > To subscribe to the announce mailing list, send an email to: > > *announce-subscr...@openoctave.org > <mailto:announce-subscr...@openoctave.org>* > > and then send mail to: > > *annou...@openoctave.org <mailto:annou...@openoctave.org>* -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjn3n4oa@faui43f.informatik.uni-erlangen.de
Bug#567863: RFP: Handbrake - video transcoder
On Mo, Okt 10, 2011 at 07:12:23 (CEST), Rogério Brito wrote: > Hi there. > > I'm just including the Multimedia team, as they don't seem to be subscribed > to this bug. > > > On Oct 09 2011, Ralf Jung wrote: >> > Can't be packaged as x264 video codec and aac and mp3 audio codec aren't >> > free. >> How can that be, I can decode and encode mp3 and view MPEG4 videos without >> problems, installing only packages from the debian repositories...? > > Ralf, I think that when Christian wrote that, we didn't have x264 and lame > in the main archive. Things have changed since this bug was originally > filed. > > Once we have faac (if it's acceptable for our archive), then it would be > lovely to have a new version of handbrake (e.g., from their git tree) in the > archive, as it is a frontend for multimedia libraries that quite possibly > passes the "useable by mom and dad" usability test, especially since it > comes with sensible presets. I don't think we'll ever have faac in Debian because of its license. See https://bugs.edge.launchpad.net/ubuntu/+source/faac/+bug/374900 for details. Luckily, we have vo-aacenc (http://packages.debian.org/sid/main/libvo-aacenc0), which is the aac encoder from android and can encode aac just fine. >> As far as I know, Handbrake does not even implement any of this. It uses >> gstreamer, ffmpeg and others. > > Well, it does implement some things, like, for instance, their decombing > routines, which is very nice for some interlaced and almost-interlaced > things. > > As a side-effect, this decombing of theirs results in variable frame rates, > which potentially feeds fewer frames to x264 (or whatever encoder is in > question), making the bitrates tend to lower. > > Another side-effect that people may not appreciate because they run fast > architectures is that outputting fewer frames, some slower video cards > (e.g., in a powerpc machine) can have a fighting chance of playing some > videos. > > I don't know of any implementation of handbrake's decombing algorithm in > other software (e.g., ffmpeg/libav, mplayer, mplayer2, gstreamer etc.) Does > anyone know? > > The other transcoders (arista, transmaggedon) are jokes regarding the amount > of configurability that they allow. I agree that Handbrake is a really great tool. Actually, I did take a look at the sources and found out, that it would require a lot of efford to get it into debian. The reason is that the ship a lot of patched libraries that we already have in debian. I don't think this code duplication is acceptable for the Debian system. As for this RFP, I think any potential packager should identify the included libraries and start upstreaming the included patches. Then, try to build them against the libraries that Debian already ships. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkh9wekr@faui43f.informatik.uni-erlangen.de
Bug#648896: ITP: kup -- kernel.org upload tool
On Mi, Nov 16, 2011 at 00:05:58 (CET), Ben Hutchings wrote: > Package: wnpp > Severity: wishlist > Owner: Ben Hutchings > > * Package name: kup > Version : 0.2 > Upstream Author : H. Peter Anvin > * URL : git://git.zytor.com/users/hpa/kup/kup.git The URL is not a website. I haven't seen seen git:// urls in other package descriptions yet, but http://git.zytor.com/?p=users/hpa/kup/kup.git;a=summary would have made it easier, I think. > * License : GPLv2+ > Programming Lang: Perl > Description : kernel.org upload tool > > This utility is used to upload files to kernel.org and other > systems using the same upload system (kup-server). Each upload > is required to have a PGP signature, and the server will generate > multiple compressed formats if the content uploaded is intended to be > compressed. Do you intend to package kup-server as well? It seems to be included in the same sources after all, but you don't mention it in the package description. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcqkk3yy@faui43f.informatik.uni-erlangen.de
Bug#648896: ITP: kup -- kernel.org upload tool
On Mi, Nov 16, 2011 at 06:56:22 (CET), Ben Hutchings wrote: [...] > Yes. The packaging is already committed at > <http://anonscm.debian.org/gitweb/?p=kernel/kup.git>. I'm waiting for > the Perl transition to clear before uploading. Thank you for working on the package! Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqgsjyu7@faui43f.informatik.uni-erlangen.de
Bug#670052: ITP: libpostproc -- FFmpeg derived postprocessing library
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
* Package name: libpostproc
Version : ?
Upstream Author : Michael Niedermayer (michae...@gmx.at)
* URL : http://git.videolan.org/?p=libpostproc.git;a=summary
* License : GPLv2+
Programming Lang: C
Description : FFmpeg derived postprocessing library
Proposed package metadata:
Package: libpostproc-dev
Section: libdevel
Architecture: any
Depends: libpostproc52 (= ${binary:Version})
Description: FFmpeg derived postprocessing library - development headers
This package contains the postprocessing library for legacy
applications.
Package: libpostproc52
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: FFmpeg derived postprocessing library
This package contains the postprocessing library for legacy
applications.
Suggestions for better package descriptions welcome.
For inclusion in team pkg-multimedia, I solicit for supporters inside
team pkg-multimedia. I expect this library to take very little efford
maintenance way and to go away in the long term. It has only been
created because libav dropped it from its sources. We need to carry it
in Debian until all packages that depend on it have migrated away from
it.
Preliminary packaging can be inspected here:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libpostproc.git
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120422155630.765.4375.reportbug@localhost6.localdomain6
Bug#456165: ITP: handbrake -- Rips and encodes DVDs (was Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h)
On Sat, May 12, 2012 at 5:40 PM, Andres Mejia wrote: > > I just noticed that libmkv was written specifically for handbrake. In > this case, I wouldn't even bother uploading libmkv separately and just > use whatever libmkv ships with handbrake. TBH, I agree. Fabian, this does not mean that your work on git+ssh://git.debian.org/git/pkg-multimedia/libmkv was in vain. As soon as some other package uses it, we can use your packaging and upload to debian. But until then, we gain little to nothing by shipping it outside of handbrake -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceaxgCL=+pa4swb6h8x55_sbf6_pr9wbr79qawa3cnk...@mail.gmail.com
Bug#376521: ITP: kwlan -- wpasupplicant frontend for KDE
On Mon, Jul 03, 2006 at 02:45:18PM +0200, Fathi Boudra wrote: > Package: wnpp > Severity: wishlist > Owner: Fathi Boudra <[EMAIL PROTECTED]> > > * Package name: kwlan > Version : 0.4.7 > Upstream Author : Thomas Michel <[EMAIL PROTECTED]> > * URL : http://home.arcor.de/tom.michel > * License : dual licensed GPL-2 and BSD license > Description: wpasupplicant frontend for KDE > > Kwlan is a wireless lan manager for KDE. It uses wpasupplicant to connect > to wireless networks. It allows to configure different network profiles using > all encryptions wpasupplicant provides (wep, wpa, wpa2 etc). Systray icon > shows connection status. > > Features: > * Scan for available networks > * Configure WPA Supplicant network profiles > * Systray icon displays connection status > * Dynamic or static IP address configuration > > It is based on wpa_gui by Jouni Malinen <[EMAIL PROTECTED]> I had a look at the website, on the first look, it seems quite similar to wpa_gui, but on the other hand, it seems to have additional functionality like starting wpasupplicant on session login. Perhaps you are interested in joining the pkg-wpa team on alioth [1]? We could share an svn repository and discuss best integration of kwlan into the wpasupplicant package in debian on the wpa-pkg-devel mailinglist [2]. Gruesse, Reinhard [1] http://alioth.debian.org/projects/pkg-wpa [2] http://lists.alioth.debian.org/mailman/listinfo/pkg-wpa-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356289: python-gst0.10 now available
python-gst0.10 is now available in the archive. Whats the status of this ITP now? Do you perhaps have already some preview .debs for public testing somewhere? Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456165: Details from Handbrake as to why it is statically linked to libraries
On Wed, Sep 12, 2012 at 1:45 PM, Alex Brooks wrote: > Hello, > > I'm new to the Debian bugs system, so please excuse me if I break etiquette. No, you're doing perfectly fine! > I'm really looking forward to Handbrake being available in the main > repositories, but I thought that the packagers need to be aware of > some information that the Handbrake devs have written about why they > statically link to libraries. > > First, from their development FAQ (https://trac.handbrake.fr/wiki/SupportFAQ): > >>Why doesn't HandBrake use my system libraries? >>HandBrake requires a lot of control over the specific versions of 3rd party >>libraries it utilizes. To make sure everything is to its specifications, it >>downloads and builds most of its dependencies and statically links them, all >>without touching your system libraries." > That's an perfectly understandable reasoning from an upstream perspective. The problem is that this conflicts with the requirements of a distribution of the size of Debian. Here, shipping the same piece of software in different versions embedded in other packages makes the life of package maintainers, release managers, archive administrators and the security team unnecessarily hard. Therefore, we cannot accept this and need patch the software to work with the system provided libraries. > and > >>"Why can't I build HandBrake? x264 fails to compile and then libhb does too. >>You need to build and install yasm for x264 to use cpu acceleration." Debian does already ship a working copy of x264. Handbrake should just use it. > Also, in the source, there is a file called README.debian. I've > pasted the contents of the file at the bottom of this message. It's > very informative. > > Thanks, and good luck with getting Handbrake packaged up! > > Alex Brooks > > == > > handbrake for Debian > > > HandBrake bundles its own copies of ffmpeg and related media libraries. This > is > an upstream decision that the Ubuntu maintainers will respect. Yes, that may be fine for ubuntu, and might be fine for debian/experimental. It is certainly unacceptable for a debian stable release. Having said this, I'd be OK to have embedded libraries in an upload to experimental. > This is done by running contrib/getcontrib.sh which wgets each library from > HandBrake's website. Yeah, the autobuilders in both debian and ubuntu do not have access to the internet at compilation time. Therefore, the parts of the build scripts that download stuff need to be disabled and all sources need to be available in the source package. > > Upstream has asked us to do this because they have modified their libraries to > address the finickiness of the platforms that they support, along with > prerelease patches that add support for advanced HandBrake functionality such > as > surround-sound downmixing. Again, that's understandable, but more a workaround than a solution. > HandBrake then statically links against these libraries, and they are not > installed to the system so it doesn't interfere with other parts of the > system. > Different or older versions of these packages are included in the Ubuntu > distribution already, and have passed our guidelines for Multiverse inclusion. As indicated above, this static linking is what makes packaging handbrake challenging. > > === Detailed Breakdown of Bundled Libraries and Reasons === > > a52dec - 0.7.4 > patch to allow downmix to dolby prologic ii Can be included in the distro package > faad2 2.6.1 > patch to configure.ac so it will build with libtool 2.2.x Not necessary when using the system copy > > ffmpeg svn 15462 > patch for building on beos > patch that adds aac-latm codec > patch fixes memory leak provoked by h264 streams with lots of errors > patch for cygwin > patch for solaris debian does not support beos, cygwin or solaris, so those patches are irrelevant. Debian's libavcodec does support aac-latm already. I'm not sure about the memory leak fix, but that fix should be fixed upstream in any case. > libdca svn 81 > newer than released version We can update the system copy of the library, no problem here. > libdvdread 0.9.7 > patch for os x, changes path to dvdcss > patch for cygwin, configure fixes all of those do not affect debian. > faac > patch for cygwin configure please see https://bugs.launchpad.net/ubuntu/+source/faac/+bug/374900 My understanding is that including faac in GPL'ed binaries as Handbrake does results in unredistributable binaries. > lame version 3.98 What about it? > libmp4v2 svn 45 > project was stagnant. using a fork that has picked up development So? > libmkv 0.6.3 > > mpeg2dec 0.5.1 > > libogg 1.1.3 > > libsamplerate 0.1.4 > > libvorbis aotuv fork b5 > > libtheora 1.0 > > libx264 git 1028 > patch for cygwin configure > patch for solaris build scripts > patch to allow forcing an IDR frame > > xvidcore 1.1.3 > patch for os x configure > patch for cygwin configure > patch configure to reco
Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss
On Fri, Sep 14, 2012 at 1:19 PM, Dmitry Smirnov wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-de...@lists.debian.org > >Package name: libdvdcss-pkg > Version: 1.2.12-1 > Upstream Author: Dmitry Smirnov > License: GPL-3+ > Description: download, build and install libdvdcss package > This package will automatically download, build and install > libdvdcss on your system. > . > libdvdcss is a library for accessing and unscrambling DVDs > encrypted > with the Content Scramble System (CSS). > It is a free software but it may be illegal in some > jurisdictions. > > This is a proof-of-concept implementation of automated installer for > libdvdcss. This has been discussed before within the pkg-multimedia team. There is even preliminary work available at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libdvdcss-installer.git;a=summary. Team pkg-multimedia, does anyone remember or know why that branch has not been uploaded to debian yet? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceaodlmphs3jnclws6tsm6ka7boymxuh8qac132axhf...@mail.gmail.com
Bug#690693: ITP: thin-provisioning-tools -- Tools to manage thinly provisioned volume metadata in LVM
On Tue, Oct 16, 2012 at 5:38 PM, Neil Wilson wrote: > Package: wnpp > Severity: wishlist > Owner: Neil Wilson > > * Package name: thin-provisioning-tools > Version : 0.1.5 > Upstream Author : Red Hat, Inc. > * URL : https://github.com/jthornber/thin-provisioning-tools > * License : GPL v3 > Programming Lang: C++ > Description : Tools to manage thinly provisioned volume metadata in LVM > > Installs check, dump and restore tools that manage the thin volume > metadata in the thin provisioning pool. The message description is too terse to be useful for an average user. What is "thinly provisioned volume metadata"? Does it have anything to do with thin clients? Why would I or some system administrator want to install the package? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0ccebpKX9-TRNuz6iKs=vxkkbt1e2dyp93cpy8unaow7a...@mail.gmail.com
Bug#690693: ITP: thin-provisioning-tools -- Tools to manage thinly provisioned volume metadata in LVM
You might want to include some of the information of http://fedoraproject.org/wiki/Features/ThinProvisioning to your package description. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceab4lr3m3zvaubsiwer1nl91b1c2uauvn90btwf2ck...@mail.gmail.com
Bug#687624: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
On Thu, Dec 13, 2012 at 1:59 PM, wrote: > The following commit has been merged in the master branch: > commit d191a4eb0740b54661c4cc0fc288b79063e822a4 > Author: Dmitry Smirnov > Date: Thu Dec 13 23:59:01 2012 +1100 > > RFP/ITP bug #695849 assigned > > diff --git a/debian/changelog b/debian/changelog > index 9c36013..19d9f30 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,5 +1,5 @@ > glmark2 (2012.11-1) UNRELEASED; urgency=low > > - * Initial release (Closes: #). > + * Initial release (Closes: #695849). > > -- Dmitry Smirnov Thu, 13 Dec 2012 23:31:56 +1100 TBH, I think this package is (currently) not fit for the pkg-multimedia team for two reasons: a) It does not contain the upstream sources, only the packaging directory debian/ is in the tree b) It is not backed up by some other pkg-multimedia team member. Dimitry, unless both issues can be fixed, I think collab-maint would serve a much better umbrella than pkg-multimedia. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0ccealzxqqsumhwzbdwy_rq6esp9yvexvvl_yk3cspuxq...@mail.gmail.com
Bug#695849: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
On Thu, Jan 3, 2013 at 1:43 PM, Dmitry Smirnov wrote: > On Thu, 3 Jan 2013 23:10:15 Reinhard Tartler wrote: >> On Thu, Dec 13, 2012 at 1:59 PM, > wrote: >> > The following commit has been merged in the master branch: >> > commit d191a4eb0740b54661c4cc0fc288b79063e822a4 >> > Author: Dmitry Smirnov >> > Date: Thu Dec 13 23:59:01 2012 +1100 >> > >> > RFP/ITP bug #695849 assigned >> > >> > diff --git a/debian/changelog b/debian/changelog >> > index 9c36013..19d9f30 100644 >> > --- a/debian/changelog >> > +++ b/debian/changelog >> > @@ -1,5 +1,5 @@ >> > >> > glmark2 (2012.11-1) UNRELEASED; urgency=low >> > >> > - * Initial release (Closes: #). >> > + * Initial release (Closes: #695849). >> > >> > -- Dmitry Smirnov Thu, 13 Dec 2012 23:31:56 >> > +1100 >> > > Sorry Reinhard, I'm a bit confused which package you're talking about -- > "glmark2" or "libdvdcss-pkg"? You quoted one bug but posted to another... Oh, sorry, I was indeed talking about glmark2. Sorry, for copying the wrong bug, fixed now. > >> TBH, I think this package is (currently) not fit for the >> pkg-multimedia team for two reasons: >> >> a) It does not contain the upstream sources, only the packaging >> directory debian/ is in the tree > > If it is glmark2 it is easy enough to fix if you're concerned about team's > best practice. Is this so important because of team preference? > In SVN we usually track only packaging. I think choosing git shouldn't always > imply git-buildpackage repository layout... Well, I think consistency in the workflow is important for working efficiently in a team. Therefore, this point is for me an absolute requirement for working on the package. IOW: I do not the svn-buildpackage package layout, and I absolutely hate it. >> b) It is not backed up by some other pkg-multimedia team member. > > Please help me to understand -- because I'm not sure what package you're > talking about. Do we need at least one team member to back it up? > Or would you insist on minimum two members? Yes, I do really think that *every* package in pkg-multimedia should have *at least* two *active* team members in the Uploaders field. Everything else indicates that not enough developers in the team care for the package, which in the end is harmful for pkg-multimedia. We already a pretty bad maintainer per package ratio, and adding more poorly-maintained packages does not help at all. > >> Dimitry, unless both issues can be fixed, I think collab-maint would >> serve a much better umbrella than pkg-multimedia. > > Although glmark2 is finished I'm a bit reluctant to take responsibility for it > at this time but I might do it later. > Package "glmark2" is much related to multimedia and appears to be a good fit > for a team. Does it make sense to move it to collab-maint for some time? Even > if not maintained now, it's a new package so perhaps it's not too important > where it is waiting for maintainer while it is not uploaded yet. > > It feels a bit like "finish it or leave"... Speaking about finishing, did you > have a chance to try it? Do you think it is useful despite failure of some > opengl (but not opengl-es) tests? If so I'm happy to own ITP even though it > might not be a right time for me. Sorry, I neither have time nor interest to investigate glmark2, nor do I find glmark2 particularly in scope of pkg-multimedia. Moreover, the svn-buildpackage style packaging already deterred me enough to refrain me to take a closer look. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0ccezvqvpv1x+xvxhvgwat9q5motggd7py34t5hqbued3...@mail.gmail.com
Bug#695849: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
On Thu, Jan 3, 2013 at 2:19 PM, Dmitry Smirnov wrote: > On Fri, 4 Jan 2013 00:02:12 Reinhard Tartler wrote: >> >> b) It is not backed up by some other pkg-multimedia team member. >> > >> > Please help me to understand -- because I'm not sure what package you're >> > talking about. Do we need at least one team member to back it up? >> > Or would you insist on minimum two members? >> >> Yes, I do really think that *every* package in pkg-multimedia should >> have *at least* two *active* team members in the Uploaders field. >> Everything else indicates that not enough developers in the team care >> for the package, which in the end is harmful for pkg-multimedia. We >> already a pretty bad maintainer per package ratio, and adding more >> poorly-maintained packages does not help at all. > > OK, thanks for explaining. I have two concerns though. > > This package is not uploaded so it does not affect maintainer per package > ratio. Not yet. It does becaus it already uses team ressources: a) mailing list (commit logs, etc.) b) clutters the list on http://git.debian.org c) is already processed by PET: http://pet.debian.net/pkg-multimedia/pet.cgi BTW, c) is how I came aware of the package: ansgar pinged on irc that the contained watch file confuses PET, so I implemented his suggestion. > It doesn't make any sense to move package repository to collab-maint whenever > there is less than two active maintainers. Wouldn't we push less active > packages away from pkg-multimedia like this? Yes, and I think this is desireable if we do not want pkg-multimedia to deter to "some other multimedia-related Debian QA"-group. Let's please leave that for the proper Debian QA group. > You're talking about desirable (ideal) situation. I'm not sure if I understand this comment. >> > It feels a bit like "finish it or leave"... Speaking about finishing, did >> > you have a chance to try it? Do you think it is useful despite failure >> > of some opengl (but not opengl-es) tests? If so I'm happy to own ITP >> > even though it might not be a right time for me. >> >> Sorry, I neither have time nor interest to investigate glmark2, nor do >> I find glmark2 particularly in scope of pkg-multimedia. Moreover, the >> svn-buildpackage style packaging already deterred me enough to refrain >> me to take a closer look. > > Sorry Reinhard, I didn't know you feel so strong about it. Of course I'll move > the package to collab-maint if you insist. Otherwise I'll convert its > repository to git-buildpackage layout so we can decide whenever we want it in > pkg-multimedia. Thanks. It's not that I really "insist" on something. I'm wondering what is the best way to go with the package. While not uploaded yet, it already does consume considerable team ressources, and since it seems that nobody else in the team is interested in the package, I feel that you would have less effort with leaving the packaging style as it is and just move the repository to collab-maint. Sorry if my previous mails on the package were too harsh. I strongly suspect that we have a number of other packages within the team with the same issues as glmark2. Nevertheless, I do not intend to play the "team police" game proactively, but only when I stumble upon (obvious) problems in problematic package. I would appreciate if other active team members would join this effort. Happy new year! :-) -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceb51tp4UdCBRJ=6=D9V7oW+Ek+sj-=0xd3wn0+3h41...@mail.gmail.com
Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)
On Mo, Jan 02, 2012 at 16:37:57 (CET), Fabian Greffrath wrote: > owner 203211 pkg-multimedia-maintain...@lists.alioth.debian.org > severity 203211 wishlist > tags 203211 = > thanks > > This ITP looks like a perfect candidate for the pkg-multimedia team > now. Indeed, I've enjoyed using it in the past several times. Does it nowadays work properly with the system libav, or does it still require its internal copy? If the latter, then it's going to be a lot of work to get it in shape. In any case, count me in as Uploader. Cheers, Reinhard. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871urije32@faui43f.informatik.uni-erlangen.de
Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)
On Mo, Jan 02, 2012 at 17:03:14 (CET), Fabian Greffrath wrote: > Am 02.01.2012 16:53, schrieb Reinhard Tartler: >> Does it nowadays work properly with the system libav, or does it still >> require its internal copy? If the latter, then it's going to be a lot of >> work to get it in shape. > > I haven't had a look at the source, but according to the 2.5.6 release > notes they "Updated the FFmpeg libraries (version 0.9)". So this sounds > like they still use an internal copy, but since it's recent enough, > maybe it's not that hard to use the system libav headers and link > against the system libs? Please give it a try and report what issues you encounter. I may be available for some of the harder tasks. Cheers. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty4ehytd@faui43f.informatik.uni-erlangen.de
Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)
On Mon, Jan 2, 2012 at 5:03 PM, Fabian Greffrath wrote: > Am 02.01.2012 16:53, schrieb Reinhard Tartler: > >> Does it nowadays work properly with the system libav, or does it still >> require its internal copy? If the latter, then it's going to be a lot of >> work to get it in shape. > > > I haven't had a look at the source, but according to the 2.5.6 release notes > they "Updated the FFmpeg libraries (version 0.9)". So this sounds like they > still use an internal copy, but since it's recent enough, maybe it's not > that hard to use the system libav headers and link against the system libs? I've now found the time to look at how avidemux "uses" ffmpeg, but unfortunately, I have bad news: avidemux specifically downloads an ffmpeg-0.9 tarball (we use libav in debian), and then applies a larger number of patches: http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/cmake/patches/ Most of those patches actually look pretty scary to me. Additionally, most of the comments in those patches don't really make sense to me either. I conclude that trying to link avidemux dynamically against the system libavcodec is not feasible. Shipping a static copy of avcodec and friends doesn't make me feel too happy either :-/ -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0ccebRbP=pjpplb3svfmtjkdkl8fmwvvrjnhsvfa9uwhy...@mail.gmail.com
Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)
On Tue, Jan 3, 2012 at 12:14 AM, Reinhard Tartler wrote: > On Mon, Jan 2, 2012 at 5:03 PM, Fabian Greffrath wrote: >> Am 02.01.2012 16:53, schrieb Reinhard Tartler: >> >>> Does it nowadays work properly with the system libav, or does it still >>> require its internal copy? If the latter, then it's going to be a lot of >>> work to get it in shape. >> >> >> I haven't had a look at the source, but according to the 2.5.6 release notes >> they "Updated the FFmpeg libraries (version 0.9)". So this sounds like they >> still use an internal copy, but since it's recent enough, maybe it's not >> that hard to use the system libav headers and link against the system libs? > > I've now found the time to look at how avidemux "uses" ffmpeg, but > unfortunately, > I have bad news: > > avidemux specifically downloads an ffmpeg-0.9 tarball (we use libav in > debian), and > then applies a larger number of patches: > http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/cmake/patches/ > > Most of those patches actually look pretty scary to me. Additionally, most > of the comments in those patches don't really make sense to me either. > > I conclude that trying to link avidemux dynamically against the system > libavcodec > is not feasible. Shipping a static copy of avcodec and friends doesn't make me > feel too happy either :-/ I think I have a doable solution: Let's have the avidemux source package build depend on libav-source, and have avidemux's build system apply its patches on that source. This way we have have the code duplication only in the binary code, but no longer have to binNMU avidemux in case changes happen in Libav. Fabian, what do you think about this solution? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0ccea1E-q==ZOBztJ5rU=qgyxdlsxt7owtsckdxfdptns...@mail.gmail.com
Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)
On Di, Jan 03, 2012 at 08:40:56 (CET), Fabian Greffrath wrote: > Am 03.01.2012 08:31, schrieb Reinhard Tartler: >> I think I have a doable solution: Let's have the avidemux source >> package build depend on libav-source, and have avidemux's build >> system apply its patches on that source. This way we have the >> code duplication only in the binary code, but no longer have to >> binNMU avidemux in case changes happen in Libav. >> >> Fabian, what do you think about this solution? > > Phew, sounds doable but not desirable and is IMHO too dirty for a > Debian package. Well, it was built for libav-extra, but hey, why not. > If we really decide to give this package a try, we should figure out > which patches are really necessary to actually build and use avidemux, > get in contact with the author of these patches and together try to > convince upstream (whether ffmpeg or libav, I don't care) to either > include them or find a cleaner solution for the problem they are > supposed to solve. That would be nice. However, I don't have the time and energy to encourage avidemux upstream to collaborate properly with libav (or ffmpeg). Any other opinions on the libav-source approach? Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehvhf6t2@faui43f.informatik.uni-erlangen.de
Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)
On Thu, Jan 5, 2012 at 4:04 PM, Richard Shaw wrote: > On Thu, Jan 5, 2012 at 3:13 AM, Fabian Greffrath wrote: >> Hi all, >> >> I have checked the rpmfusion package for avidemux and they have patched it >> to use the system libraries for libass, liba52, llibmad and libtwolame at >> least. Furthermore, the package has "BuildRequires: ffmpeg-devel" but I >> could not found a patch to force it to use the system ffmpeg libraries. > > I took over mantainership around 2.5.3 so I'm not the original author > of the spec file. Now that I think about it I probably don't need to > BR: ffmpeg-devel but the original maintainer may have begun an attempt > to un-bundle ffmpeg. I'm a bit confused now. Fabian noticed that Fedora's avidemux 2.5.3 package already did unbundle ffmpeg. Is this untrue? Or did I misunderstand you two? > >> I have put Richard Shaw, the maintainer of this package in rpmfusion into >> CC. Richard, can you tell us more about avidemux' usage of the ffmpeg >> libraries in your package? > > As mentioned previously, the bundled ffmpeg is heavily patched. I > doubt if avidemux wasn't grandfathered in during the 3rd party repo > merger that it would pass a review request today since RPM Fusion has > the same policy against bundled libraries as Fedora. I had some luck > un-bundling some of the other libraries as you noticed, but ffmpeg is > beyond me. We would be happy to share the work and take your patches for using the system libraries for the Debian package. Besides, have you by chance already asked upstream to comment on your patches? If yes, what was the response? > I think a lot of the patches for ffmpeg are to maintain "frame > accuracy", this feature has been dropped from the upcoming 2.6 release > (there are pro's and con's to both approaches) and it may be much > easier to un-bundle ffmpeg from this version. That's great to hear! Maybe we (i.e., in Debian) should, directly look at packaging the 2.6 development branch. > I've already started building preview release packages. The building > is rather odd, I actually have to do a temporary install of > avidemux_core in the %build section so the headers are available for > linking by all the other sub-projects (cli, QT, GTK, plugins, etc.). > I know the build systems differ quite a bit but I would think the > building methodology would sill be the same. Let me know if anyone > would like to take a look and I'll make my spec file available. Yes, that would probably be helpful for preparing the Debian package. Do you use some VCS for your packaging work? In case you are interested in our current packaging branch, it is at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/avidemux.git > I haven't yet taken a look at un-bundling ffmpeg from 2.6 so any help > would be appreciated. Sure! -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceb6CUQB0t_-rBs0q4yYbw93-L=co0ypeb+je9mec2m...@mail.gmail.com
Bug#655618: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
clone 655618 -1 retitle 655618 ITP: nx-libs-light --- NX Protocol client-only libraries and binaries retitle -1 ITP: nx-libs --- NX Protocol client/server libraries and binaries stop On Fr, Jan 13, 2012 at 10:20:15 (CET), Mike Gabriel wrote: > Hi Paul, hi John, > > On Fr 13 Jan 2012 09:30:09 CET Paul van der Vlis wrote: > >> Op 13-01-12 02:22, John A. Sullivan III schreef: >> >>> As SPICE improves, I think we should consider it >>> seriously. Its cross platform support is very good which would no >>> longer limit X2Go server to Windows only and the idea of an adaptive >>> protocol is absolutely intriguing. I long for the day we can >>> realistically do video playing on the virtual desktop across a WAN. >> >> X2go-server is not Windows-only, it even does not run on Windows. >> Not sure what you want to say. > > Note: we tend to get off-topic here. This thread is about packaging > X2Go server / NX-libs for Debian. Please note by the To:/Cc: field, how > many lists/people are involved in this discussion. I think the recipient list is appropriate. It includes everyone that should discuss the inclusion of this software into the Debian Archive. As some people raised concerns about including the x2go server into Debian, I'm there splitting this ITP into two parts, following to the way x2go provides its sources: At http://code.x2go.org/releases/source/nx-libs/ two tarballs of nx-libs are provided: one called 'lite' and one called 'full'. AFAIUI, the 'lite' tarball is a true subset of the 'full' tarball containing only the parts that are relevant for building the client parts of the NX stack. This is what bug #655618 is about from now on. The package is being prepared at http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree and, from what I see, is appropriate for being uploaded to unstable. For clarity, I think we should rename the git repository from nx-libs.git to nx-libs-light.git. Mike, can you please handle that? For further discussion of the server parts (called "agent" in NX lingo), which AFAIUI is a heavily patched fork of the old XNest codebase linked against the Nomachine NX protocol libraries, please use the cloned bug. I agree that without the blessing of the release team the security team, it shouldn't go into unstable (or wheezy), but if the ftp-masters agree, then I think it could go into experimental, so that interested parties can start to have another serious look at it. If the project decides that the server becomes suitable for inclusion into unstable, it will then replace the 'nx-libs-light' package. As I understand from Mike's other posting in this thread, there are people looking at porting the agent to a newer codebase. But this is a rarther long-term option. As are the suggestions to port x2go to SPICE. As for the concerns with Nomachine, while it is true that NX 4.0 is no longer GPL licensed, the 3.x codebase has seen updates, which maintain its previous license, the GPLv3. I take this as indication that Nomachine still has an interest in maintaining the 3.x codebase, which included security fixes in the latest releases. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty3zc2sb@faui43f.informatik.uni-erlangen.de
Bug#655618: x2goagent/nxagent crashes reintroduced :-(
The following message is a courtesy copy of an article that has been posted to gmane.linux.terminal-server.x2go.devel as well. On So, Jan 15, 2012 at 00:28:24 (CET), Mike Gabriel wrote: > the latest nx-libs.git 3.5.0.6 seems to reintroduce the x2goagent > crashes again we observed earlier. > > The problem has also already been re-introduced with nx-libs.git > 3.5.0.2 and a separate x2goagent (with its own nx-X11 source tree). > > We will have to check the patches being re-introduced between 3.5.0.0 > and 3.5.0.2. > > I wil also rebuild nx-libs packages with state of commit > http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=aa166550657f3a928f5d7a8babc0956b69f4a587 > > as this one was definitely the last working/stable state. > > Simple test: connect from client A -> session A: X2Go server A -> > session B: X2Go server B. On session termination of session B (on > server B), the session A on server A crashes. Thanks for the notice. I'll hold back uploads to debian until the cause of these crashes have been investigated. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boq4rool@faui43f.informatik.uni-erlangen.de
Bug#405896: ITP: keepassx -- light-weight and easy-to-use password manager
Package: wnpp Severity: wishlist Owner: Reinhard Tartler <[EMAIL PROTECTED]> * Package name: keepassx Version : 0.2.2 Upstream Author : Tarek Saidi <[EMAIL PROTECTED]> * URL : http://keepassx.sourceforge.net/ * License : GPL Programming Lang: C++ Description : light-weight and easy-to-use password manager KeePassX is an application for people with extremly high demands on secure personal data management. It has a light interface and is cross platform. . KeePassX saves many different information e.g. user names, passwords, urls, attachemts and comments in one single database. For a better management user-defined titles and icons can be specified for each single entry. Furthermore the entries are sorted in groups, which are customizable as well. The integrated search function allows to search in a single group or the complete database. . KeePassX offers a little utility for secure password generation. The password generator is very customizable, fast and easy to use. Especially someone who generates passwords frequently will appreciate this feature. . The complete database is always encrypted either with AES (alias Rijndael) or Twofish encryption algorithm using a 256 bit key. Therefore the saved information can be considered as quite safe. KeePassX uses a database format that is compatibel with KeePass Password Safe. This makes the use of that application even more favourable. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405896: ITP: keepassx -- light-weight and easy-to-use password manager
Moritz Muehlenhoff <[EMAIL PROTECTED]> writes: >> The complete database is always encrypted either with AES (alias >> Rijndael) or Twofish encryption algorithm using a 256 bit key. Therefore >> the saved information can be considered as quite safe. KeePassX uses a > ^^ > Ummm. > > Apart from that, just because it uses strong ciphers it doesn't mean it's > secure. It appears to only have a single author and to be very fresh and I > don't think it has received real review so far. Until it has matured more > I wouldn't upload this to unstable, as every flaw will expose all the pass- > words and passphrases of a user. Err, while I agree that the description should make false or misleading statements (I will take that part out), I'm a bit confused about your statement to not upload it to unstable. I mean, in a truly security sensitive environment, every security sensitive tool should be audited anyway. I'd still like to upload it to unstable, so that it gets wider testing. If someone notices security issues, the package will get an RC bug, and if there is no quick fix, it may be removed from testing. But why are you saying that it mustn't enter unstable? Did you perhaps already audit keepassx or have made any experience while using it? I think your concerns apply to the dozen other password managers we already ship in etch as well. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpJHize3kjKG.pgp Description: PGP signature
Bug#412566: ITP: aes2501-wy -- userspace software for usb aes2501 fingerprint scanner
Miguel Gea Milvaques <[EMAIL PROTECTED]> writes: > Description : userspace software for usb aes2501 fingerprint scanner > > Command line scanning sofware for AES2501B usb fingerprint reader. The ouput > are gray pnm files with quite good quality. I also have such an fingerprint scanner, and was looking for software for that. Can I somehow assist you with co-maintenance and/or writing code? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgp5QQrdCCPFC.pgp Description: PGP signature
Bug#416605: ITP: boxbackup -- Server and Clients for the BoxBackup remote backup system
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler <[EMAIL PROTECTED]>
* Package name: boxbackup
Version : 0.10
Upstream Author : Ben Summers <[EMAIL PROTECTED]>
* URL : http://www.fluffy.co.uk/boxbackup/
* License : BSD with advertising clause
Programming Lang: C++
Description : Server and Clients for the BoxBackup remote backup system
I'm currently using boxbackup for my private use. I've crafted packages
for my own used based on the ones from Jérôme Schell, I needed to apply
one patch from upstream though. I'd like to see boxbackup in debian, so
I'm filing this ITP. Help with this package is highly appreciated.
I'm CC'ing Jérôme Schell and Jesus Climent with this email, as they both
have expressed interest in the boxbackup packages. I'm CC'ing the
boxbackup devel mailing list as well, perhaps there are even more people
interested in seeing boxbackup in debian. If someone feels interested in
Comaintaining this package, please contact me.
The debian/control file currently looks like this:
Package: boxbackup-server
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}, perl (>= 5.6.0), gawk, ucf
(>= 0.08), openssl (>= 0.9.7)
Recommends: boxbackup-utils
Description: Server for BoxBackup remote backup system
Boxbackup is an automatic on-line backup system.
The server waits for connections from remote clients,
authenticates them via x509 certificates and stores the
encrypted data on hard drives with optionnals RAID techniques.
It also supports versions historization and per-user quotas.
Package: boxbackup-client
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}, ucf (>= 0.07), perl (>=
5.6.0), openssl (>= 0.9.7)
Description: Client for BoxBackup remote backup system
Boxbackup is an automatic on-line backup system.
The client is watching for changes on the local filesystem,
connects to a Boxbackup server and send the changes via a
secure channel. All data is encrypted before being sent to
the server. A command line tool is provided for restoration
of backups including deleted files and old versions.
Package: boxbackup-utils
Architecture: all
Depends: perl (>= 5.6.0), openssl (>= 0.9.6c)
Description: Utilities for BoxBackup remote backup system
Boxbackup is an automatic on-line backup system.
This package contains utilities for managing SSL clients
certificates.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416605: [Box Backup] Bug#416605: ITP: boxbackup -- Server and Clients for the BoxBackup remote backup system
Chris Wilson <[EMAIL PROTECTED]> writes: >> I'm currently using boxbackup for my private use. I've crafted packages >> for my own used based on the ones from Jérôme Schell, I needed to apply >> one patch from upstream though. I'd like to see boxbackup in debian, so >> I'm filing this ITP. Help with this package is highly appreciated. > > Please could you send the patch, so that I review it for inclusion in my > tree at least? Why at least? Well, find it attached, it was taken from upstream svn. Are you interested in maintaining boxbackup in debian, then? pgpo6jOP4Ih9c.pgp Description: PGP signature patch Description: Binary data -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Bug#416605: [Box Backup] Bug#416605: ITP: boxbackup -- Server and Clients for the BoxBackup remote backup system
Chris Wilson <[EMAIL PROTECTED]> writes: > I don't have commit rights (at least, not without review) to the main > Box Backup trunk, but I maintain my own tree and I'm the most active > developer at the moment, so the best way (IMHO) to get this change > committed to the trunk is via my working tree. That's not much of a problem, I think. I'd rather focus on released versions than contantly updating to the latest svn trunk version, unless there is a specific reason to do so. (bugs, etc.). > If it's possible, I'd be very interested to see Box Backup packages for > my working tree (as well as trunk) in Debian unstable. What I could think of was to have the latest released version in debian/unstable, and if necessary a later development version in experimental, if you think this would help. >> Are you interested in maintaining boxbackup in debian, then? > > Yes, I'm interested in supporting Box on all platforms, and I run Ubuntu > on my laptop so I'm interested in Debian packages as well. Ubuntu is fine as well, as I'm using boxbackup on one ubuntu server myself. Do you have experience with packaging? Whould you be comfortable with maintaining the packaging in bazaar? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418178: RFA: nxtvepg
Package: wnpp Severity: normal I'm not using nxtvepg any longer, so it would be great if someone could take over this package. Also non-DDs are welcome, I'm happy to sponsor upload if necessary. The package is IMO in quite good shape, prospective uploaders should first update it to the latest upstream version released in January. Description: Nextview EPG decoder and browser In this software package you find a decoder for Nextview - an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. . Currently, Nextview EPG is transmitted by: * in Germany and Austria: Kabel1, 3Sat, RTL-II, EuroNews (coverage: apx. 31 networks) * in Switzerland: SF1, TSR1, TSI1, EuroNews, 3sat, Kabel1 (coverage: apx. 37 networks) * in France: Canal+, M6 (coverage: 8 networks) * in Turkey: TRT-1 (coverage: 17 networks) . The EPG information is read from /dev/vbi, i.e. you need some TV card which provides a VBI data stream. bttv cards work. zoran might work too, but I haven't tested that due to lack of hardware... Tag: interface::x11, role::program, scope::utility, uitoolkit::tk, use::viewing, x11::application -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#631784: O: mediatomb -- UPnP MediaServer
Package: wnpp Version: 0.12.1-2 On Fri, Jun 24, 2011 at 10:29:03 (CEST), Reinhard Tartler wrote: [...] > I know that I did the last upload of the package, but since I don't > really use it, getting the package in shape is not really my > priority. For the team, I ask you what to do about it. Do we have > volunteers to get it in shape or shall we rather orphan/remove it from > Debian? Summary of this thread: Noone seems to have the time or interest to care for mediatomb in Debian. I'm therefore orphaning the package with this bug for now in the hope that someone finds the time to at least fix the open RC bugs and change the ownership of the package to the Debian QA team. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boxj207x@faui43f.informatik.uni-erlangen.de
Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: mplayer2 Version : 2.0beta1 Upstream Author : Uoti Urpala * URL : http://www.mplayer2.org/ * License : GPL Programming Lang: C Description : next generation movie player for Unix-like systems MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. Another big feature of MPlayer is the wide range of supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, but also SDL (plus all its drivers) and some low level card-specific drivers (for Matrox, 3Dfx and Radeon, Mach64 and Permedia3). Most of them support software or hardware scaling, therefore allowing fullscreen display. MPlayer is also able to use some hardware MPEG decoder boards, such as the DVB and DXR3/Hollywood+. The text above is copied from the existing mplayer package. It is basically a well-known and quite popular fork of mplayer. TBH, I'm a bit unsure what to do with it. From the first look, it seems that mplayer2 is better suited for being included in a distro release, but not (yet) in its current form. Currently, it includes a copy of ffmpeg-mt, a well-known fork of the ffmpeg package, which features multithreaded h264 decoding and actually is already in debian as part of the chromium-browser package. While ffmpeg-mt is currently being integrated/merged into ffmpeg upstream, mplayer2's future is not that certain. Having this in mind, I intend to maintain the package under the pkg-multimedia umbrella. mplayer2 shoudl go to experimental for now, including ffmpeg-mt. Help and ideas with that is more than welcome! -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217115115.5101.47056.reportbug@debian
Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
BTW, this request known in ubuntu as https://launchpad.net/bugs/611851 -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aahuonzr@faui44a.informatik.uni-erlangen.de
Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
Thanks for jumping on this ITP, I wanted to point you to this ITP yesteday but got distracted by other stuff. Seems you've noticed it anyway, which is cool! :-) On Fri, Feb 18, 2011 at 12:08:25 (CET), Uoti Urpala wrote: > Reinhard Tartler tauware.de> writes: >> Package: wnpp >> Severity: wishlist >> Owner: Reinhard Tartler tauware.de> >> >> * Package name: mplayer2 >> Version : 2.0beta1 >> Upstream Author : Uoti Urpala pp1.inet.fi> >> * URL : http://www.mplayer2.org/ >> * License : GPL >> Programming Lang: C >> Description : next generation movie player for Unix-like systems >> >>MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, >>QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, >>supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It >>can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. >> >>Another big feature of MPlayer is the wide range of supported output >>drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, > >> The text above is copied from the existing mplayer package. It is > > The long description really needs a rewrite. Absolutely. Actually, this is also true for the package description of the existing 'mplayer' package. >> basically a well-known and quite popular fork of mplayer. TBH, I'm a bit >> unsure what to do with it. From the first look, it seems that mplayer2 >> is better suited for being included in a distro release, but not (yet) >> in its current form. Currently, it includes a copy of ffmpeg-mt, a > > I'm not sure if you've misunderstood something or just phrased things > inaccurately, but I think this description is at least misleading for > people who aren't already familiar with the setup. Thanks for your elaboration on the issue. For practical packaging issue, I think it makes most sense to just use the copy of ffmpeg-mt that is included in the mplayer2 tarball. This is what i've referred to with saying 'includes a copy of ffmpeg-mt'. > I think having a package using FFmpeg-mt available is good, as it's a > substantial performance improvement over anything available in Debian today. > However as above this isn't directly forced by MPlayer2 itself. Which has been requested several times now. Relevant reports include: http://bugs.debian.org/575600 http://launchpad.net/bugs/611851 -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762sh35ff@faui44a.informatik.uni-erlangen.de
Bug#457272: dvbcut: changing back from ITP to RFP
retitle 457272 ITP: dvbcut -- Qt application for cutting parts out of DVB streams owner 457272 ! thanks On Sat, Feb 19, 2011 at 18:02:11 (CET), Lucas Nussbaum wrote: > This is an automatic email to change the status of dvbcut back from ITP > (Intent to Package) to RFP (Request for Package), because this bug hasn't seen > any activity during the last 6 months. > > If you are still interested in adopting dvbcut, please send a mail to > with: > > retitle 457272 ITP: dvbcut -- Qt application for cutting parts out of DVB > streams > owner 457272 ! > thanks > > However, it is not recommended to keep ITP for a long time without acting on > the package, as it might cause other prospective maintainers to refrain from > packaging that software. It is also a good idea to document your progress on > this ITP from time to time, by mailing <457...@bugs.debian.org>. Thanks for reminding me about this. It was sitting in our git branch and I've just uploaded it. It is currently sitting in NEW. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipwaoq97@faui44a.informatik.uni-erlangen.de
Bug#613806: [SCM] mplayer2/master: use pkg-multimedia team as maintainer
On Sun, Mar 20, 2011 at 22:50:16 (CET), siret...@users.alioth.debian.org wrote: > The following commit has been merged in the master branch: > commit 19bbc946c6b3a57dba182be5e22a1377db32a143 > Author: Reinhard Tartler > Date: Sun Mar 20 22:48:51 2011 +0100 > > use pkg-multimedia team as maintainer > > diff --git a/debian/control b/debian/control > index 42ad45e..0295f70 100644 > --- a/debian/control > +++ b/debian/control > @@ -1,7 +1,8 @@ > Source: mplayer2 > Section: video > Priority: extra > -Maintainer: Reinhard Tartler > +Maintainer: Debian Multimedia Maintainers > > +Uploaders: Reinhard Tartler > Build-Depends: > autoconf, > automake, Okay, initial packaging is done, result can be seen here: http://git.debian.org/?p=pkg-multimedia/mplayer2.git As per team policy that each package needs a 2nd support, I herby solicit for reviewers of the package that agree to put themselves in the uploaders field. Most work was in debian/copyright, I'd appreciate a second look to check that I didn't miss anything (probably I did lots, but let's try to get it uploaded ASAP now as NEW processing time seem to be rather longish these days)... -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762rda1qy@faui44a.informatik.uni-erlangen.de
Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
> I just tested your mplayer2 package. It works fine so far, but it's > missing a "Conflicts: mplayer" line in the control file, because > both mplayer2 and mplayer contain /usr/bin/mplayer and the > respective manpage. Oh, thanks for the notice! I think we should install it as /usr/bin/mplayer2, and also rename the manpage accordingly. Alessio, what do you think? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r59wuypq@faui44a.informatik.uni-erlangen.de
Bug#619885: ITP: vo-aacenc -- Free AAC encoder
Package: wnpp Owner: Reinhard Tartler Severity: wishlist * Package name: vo-aacenc Version : 0.1.0-rc1 Upstream Author : Martin Storsjö * URL or Web page : http://opencore-amr.git.sourceforge.net/ * License : Apache License 2.0 Description : Free AAC encoder I received the following message from Martin: From: Martin Storsjö Subject: vo-aacenc, vo-amrwbenc prerelease To: Reinhard Tartler , Luca Barbato Date: Mon, 28 Mar 2011 10:24:15 +0300 (EEST) Hi, As discussed on irc earlier, I've added the vo-aacenc and vo-amrwbenc libraries into the opencore-amr project on sourceforge, http://opencore-amr.git.sourceforge.net/. I've got a prerelease of the libraries up on http://albin.abo.fi/~mstorsjo/vo-aacenc-0.1.0-rc1.tar.gz and http://albin.abo.fi/~mstorsjo/vo-amrwbenc-0.1.0-rc1.tar.gz. I'd appreciate if you'd give it a look and let me know if there's any issues with packaging these. If everything goes well, I'll release this version soon and announce them. The libraries include small encoding apps for testing the basic library functionality, but they don't need to be included in any .deb at least, I'd say. Patches for using them from libav are available at https://github.com/mstorsjo/ffmpeg. // Martin Martin, Andres, or any other pkg-multimedia team member, would you be willing to co-maintain this package with me? Same question for vo-amrwbenc, which ITP will be following shortly. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrjj7jjw@faui44a.informatik.uni-erlangen.de
Bug#619891: ITP: vo-amrwbenc -- AMR encoder
Package: wnpp Owner: Reinhard Tartler Severity: wishlist * Package name: vo-amrwbenc Version : 0.1.0-rc1 Upstream Author : Martin Storsjö * URL or Web page : http://opencore-amr.git.sourceforge.net/ * License : Apache License 2.0 Description : VisualOn AMR-WB encoder library This library contains an encoder implementation of the Adaptive Multi Rate Wideband (AMR-WB) audio codec. The library is based on a codec implementation by VisualOn, part of the Stagefright framework from the Google Android project. Similar to the sister ITP (Debian Bug #619885) I solicit for "co-maintainers" in the pkg-multimedia team for this package. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei5r7f3f@faui44a.informatik.uni-erlangen.de
Bug#444368: ITP: dvd95 -- DVD9 to DVD5 converter
On Mon, Jun 3, 2013 at 9:41 PM, Fabian Greffrath wrote: > Hey Alessio, > > Am Sonntag, den 19.05.2013, 16:39 +0100 schrieb Alessio Treglia: >> I'll upload it as soon as possible. > > any news? It still seems to lack a 2nd person to back up the package in the team. http://anonscm.debian.org/gitweb/?p=pkg-multimedia/dvd95.git;a=blob;f=debian/control;h=bf7e69466bfc42dfccf1bef7946c3ee13448159c;hb=HEAD -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0ccebthqq2jacyupig9q1lxyonm-vsawdwa3mtwstngj6...@mail.gmail.com
Bug#665318: ITP: faac -- AAC audio encoder
On Fri, Jun 21, 2013 at 11:10 AM, Fabian Greffrath wrote: > Dear folks, > > Am 18.10.2012 10:23, schrieb Stefano Zacchiroli: > >> The fact that "it may infringe existing patents" is not, per se, against >> the patent policy. In fact, that statement is true for every package in >> the archive: *alleged* sowftware patent violations can be found in >> almost any piece of software out there. >> >> Luca, can you please reconsider? > > > should we try again to get faac into Debian? I've now polished the package a bit and uploaded it to NEW. Let's see what happens. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceZ6t_6QFgV4WR55J1dUY4L=gdd2gmv7sj6lmlbj-zp...@mail.gmail.com
Bug#741655: O: dvbcut
Package: wnpp Severity: normal As per discussion with its comaintainer Fabrice Coutadeur, I'm orphaning dvbcut. Upstream is more or less dead, and it seems the original maintainers do not respond to inquiries to take the sourceforge project over, so there may or may not be a new project based on these sources. In any case, given that I am no longer using this package, and its future is rather unclear, I'm orphaning this package for now. It kind-of works at the moment, which is why it's probably OK to not remove it for now, but keep in mind that it is already quite heavily patched to build against modern versions of Qt and Libav. I'm going to move the git respoitory from git.debian.org to collab-maint soon, so that we don't loose the commits. regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140315002605.1235.46917.reportbug@debian-build
Bug#742022: O: avbin
Package: wnpp Severity: normal Hi, Based on the maintainer's main in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741935#20, I herby orphan the avbin package on his behalf. Best regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318122801.29904.91688.reportbug@debian-build
Bug#731858: Maybe the vxl package should be rather removed?
Hi Mathieu, I've just came across your bug report that requests to have the vxl package orphaned. AFAIUI, there are no packages in debian that link against it. If this is true, I would argue to have the package removed. It seems to be inside debian, providing this software as system library serves little value and that interested users are much better off compiling from upstream sources directly. Do you agree? In this case, we should reassign this bug to ftp.debian.org and ask for its removal. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccebK+VmuQe-vzxRZP04_XNSySNR2sW9=j9+ruqvgg2n...@mail.gmail.com
Bug#731858: Maybe the vxl package should be rather removed?
Control: retitle -1 vxl: RoM; unmaintained Control: reassign -1 ftp.debian.org > On Mon, Mar 31, 2014 at 4:47 AM, Reinhard Tartler wrote: >> Hi Mathieu, >> >> I've just came across your bug report that requests to have the vxl >> package orphaned. AFAIUI, there are no packages in debian that link >> against it. If this is true, I would argue to have the package >> removed. It seems to be inside debian, providing this software as >> system library serves little value and that interested users are much >> better off compiling from upstream sources directly. >> >> Do you agree? In this case, we should reassign this bug to >> ftp.debian.org and ask for its removal. On Mon, Mar 31, 2014 at 3:10 AM, Mathieu Malaterre wrote: > Agreed. Could you please fill the reportbug info ? Thx much Sure. Let me do this with this email. Thanks for the fast response! -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0cceYaY8ZYrd48W7jFdmeTdj=sZ0cFsJH74XL=dzzv_po...@mail.gmail.com
Bug#448208: RFS: amtterm
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.mentors as well. Hello PIAT, Franklin PIAT <[EMAIL PROTECTED]> writes: > I am looking for a sponsor for my package "amtterm". "Paul Wise" <[EMAIL PROTECTED]> writes on 31.10.2007: > Quick review of the diff: > > The patches need proper authorship info (name and email) > > Might want to use quilt for the patches > > 10_destdir.dpatch shouldn't be necessary, you can usually override > makefile variables by doing something like $(MAKE) prefix=/usr > > the homepage you specify is more of a download location, which usually > goes in debian/copyright. probably best to remove it > > mk/*.dep and maybe Make.config look like they should be removed in > debian/rules clean. > > Don't forget to send the patches upstream > > debian/watch only needs to be 2 lines long > > Remove the commented out commands and other cruft from debian/rules if > you don't need them. It seems that you did not react to Paul's suggestions to improve the package. Moreover it seems that you have not updated to package since that 27 Oct 2007. ay I ask you if you are still interested in maintaining the package? At our university, we have quite a number of machines with Intel's AMT and having a well maintained package would be helpful. You might also be interested to hear that a collegue of mine, Michael Gernoth (CC'ed) maintains a private git repository of amt at [1]. He just mentioned to me that at least some of his package really should go in the debian package. Please tell me if you are interested in Co-Maintenance or if you prefer if someone else would take over this ITP. [1] http://git.zerfleddert.de/cgi-bin/gitweb.cgi/amt -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448208: RFS: amtterm
(I'm reordering your reply a bit) Franklin PIAT <[EMAIL PROTECTED]> writes: >> Please tell me if you are interested in Co-Maintenance or if you prefer >> if someone else would take over this ITP. > > I'm not using the packages myself, so you can take it over. I can remain > co-maintainer if you want some help (we still need a sponsor). Thanks for your work so far! Sponsoring your package is no problem for me. > I have also fixed lintian errors and other minor stuffs, and I have > setup a repository, which could be moved to collab-maint. > http://git.debian.org/?p=users/franklin-guest/amtterm.git > Finally, i've uploaded that new package. Excllent, thanks. I've cloned that branch and uploaded it to the collab-maint repository. It seems that you are already in the collab maint-maint group, so you can already commit here: http://git.debian.org/?p=collab-maint/amtterm.git;a=summary Michael, you are welcome to join as well if you are interested! >> "Paul Wise" <[EMAIL PROTECTED]> writes on 31.10.2007: >>> Quick review of the diff: >>> Might want to use quilt for the patches > I've sticked to dpatch. Since I'm very much used to quilt and have a dislike for dpatch, would you mind if I changed that to quilt before uploading? >> It seems that you did not react to Paul's suggestions to improve the >> package. Moreover it seems that you have not updated to package since >> that 27 Oct 2007. > > As I mentioned, I wasn't aware of it. That's now fixed. In future, please make sure that you CC your ITP bug when asking for a sponsor of a new package. That's how I found your packaging work. >> [1] http://git.zerfleddert.de/cgi-bin/gitweb.cgi/amt > > Did he get in touch with upstream, to get those patches merged ? Michael? Can you please clarify? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448208: RFS: amtterm
Franklin PIAT <[EMAIL PROTECTED]> writes: > I assume we'll wait for Michael's patch to make the first upload. We just integrated his 2 patches and published the branch. We'll continue with some testing and then I'll upload it to unstable. >> http://git.debian.org/?p=collab-maint/amtterm.git;a=summary > > I'll delete my temporary repository (users/franklin/...) Ok, great. >> > Did he get in touch with upstream, to get those patches merged ? >> >> Michael? Can you please clarify? No, he did not. I suggest that we forward all patches in a batch to Gerd by attaching debian/patches/* and pointing him to http://git.debian.org/?p=collab-maint/amtterm.git;a=tree;f=debian/patches;hb=HEAD Can you do that or do you prefer if I approach Gerd? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#515850: RFP: mjpegtools - MJPEG video capture/editting/playback MPEG encoding
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.general as well. [ CC'ed ftp-master, please see below ] José Manuel Santamaría Lema writes: > It should be great if someone can package this tools for debian, a software > which I'm packaging depend on this tools. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467228 are you willing to package it under the pkg-multimedia umbrella? > Its already packaged in ubuntu multiverse: > http://packages.ubuntu.com/jaunty/mjpegtools > > There is also a version in debian-multimedia: > http://debian-multimedia.org/dists/unstable/main/binary-i386/package/mjpegtools.php Sure, ubuntu has imported some packages from marillat, including mjpegtools. > I don't understand why mjpegtools is in ubuntu multiverse because as > far as I know, ubuntu multiverse is non-free software, but mjpegtools > seems to be free software as its dependencies. The debian/copyright file is close to useless. You need to inspect the source manually to get an idea of its legal status. >From mpeg2enc/mpeg2coder.cc (but there are many similar comments in >mpeg2enc/*.cc): /* * Disclaimer of Warranty * * These software programs are available to the user without any license fee or * royalty on an "as is" basis. The MPEG Software Simulation Group disclaims * any and all warranties, whether express, implied, or statuary, including any * implied warranties or merchantability or of fitness for a particular * purpose. In no event shall the copyright-holder be liable for any * incidental, punitive, or consequential damages of any kind whatsoever * arising from the use of these programs. * * This disclaimer of warranty extends to the user of these programs and user's * customers, employees, agents, transferees, successors, and assigns. * * The MPEG Software Simulation Group does not represent or warrant that the * programs furnished hereunder are free of infringement of any third-party * patents. * * Commercial implementations of MPEG-1 and MPEG-2 video, including shareware, * are subject to royalty fees to patent holders. Many of these patents are * general enough such that they are unavoidable regardless of implementation * design. * */ One can now argue what "commercial implementation" actually means. I'm still waiting for ftp-master to comment on this, but AFAIUI, I don't see why debian wouldn't be able to ship the binaries of mjpegtools, lame and similar free software in non-free. non-free as a convenience for users[1], that build assemble and sell pre-installed and pre-configured devices running debian. [1] http://debian.org/distrib/pre-installed ftp-master, can you please comment on adding this kind software to non-free? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
