RFS: volumeicon
Dear mentors, I am looking for a sponsor for my package "volumeicon". * Package name: volumeicon Version : 0.3.0-1 Upstream Author : Maato (I have contacted upstream to see if he has a preferred name, but have not yet heard back) * URL : http://www.softwarebakery.com/maato/volumeicon.html * License : GPLv3 Section : sound It builds these binary packages: volumeicon - systray volume icon for alsa The package appears to be lintian clean. The upload would fix these bugs: 586522 My motivation for maintaining this package is: although there are volume-control applets for several of the major panels already in Debian, nothing is available for Tint2 (my panel of choice) and other more bare-bones panel systems. Volumeicon sits in the system tray and is panel-agnostic, so it provides this functionality for those who don't use one of the major panels. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/volumeicon - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/volumeicon/volumeicon_0.3.0-1.dsc I would be glad if someone uploaded this package for me. Thanks! -- Andrew Gainer signature.asc Description: PGP signature
Re: RFS: volumeicon
Great, thanks for letting me know! --Andrew On Sun, 13 Feb 2011 22:33:40 -0500 Scott Howard wrote: > You can get access to the collab-maint git repo without being a DD. > Get a public alioth account (one with -guest appended onto a user > name), upload your ssh key, and then apply for membership with the > collab-maint team [1]. Your ssh key that you upload to alioth will get > you onto alioth.debian.org. From their you can get to the git repo and > set one up for your project [2]. The wiki at [2] has great > instructions on how to do that. > > Cheers, > Scott > > [1] https://alioth.debian.org/projects/collab-maint/ > [2] http://wiki.debian.org/Alioth/Git > > signature.asc Description: PGP signature
RFS: libbs2b and bs2b-ladspa
Dear mentors, I am looking for a sponsor for my packages "libbs2b" and "bs2b-ladspa". * Package name: libbs2b Version : 3.1.0-1 Upstream Author : Boris Mikhaylov * URL : http://bs2b.sourceforge.net * License : GPL-2 and others Section : libs It builds these binary packages: libbs2b-dev - Bauer stereophonic-to-binaural DSP library development files libbs2b0 - Bauer stereophonic-to-binaural DSP library -- and -- * Package name: bs2b-ladspa Version : 0.9.1-1 Upstream Author : Sebastian Pipping and Boris Mikhaylov * URL : http://bs2b.sourceforge.net * License : GPL-2 and others Section : sound It builds these binary packages: bs2b-ladspa - Bauer stereophonic-to-binaural DSP LADSPA plugin The package appears to be *sort of* lintian clean. * There are several old-fsf-address-in-copyright-file warnings. Is the correct procedure on these to correct the license texts (seems fishy) or leave them alone (and let lintian yell at me)? * libbs2b gives "no-symbols-control-file usr/lib/libbs2b.so.0.0.0". A quick bit of Googling leads me to believe that this isn't very important for a slow-moving API like this library's, but my knowledge of the inner workings of the linking system is pretty rudimentary. Input on this or other aspects of library packaging would be much appreciated. * libbs2b also gives "source-contains-prebuilt-windows-binary win32/sndfile/libsndfile-1.dll", which is true. Of course, I'm not using the win32 files at all, so I guess the best thing to do is just to strip them out, but I'm not sure what the Debian Way to do this is. The upload would fix these bugs: 634993, 634994 My motivation for maintaining this package is: I use this library and LADSPA plugin daily for serious headphone listening. It has also attracted some interest from the community. Some nontrivial number of these audiophile users are moving into Linux by way of the Voyage-MPD project, which is Debian-based; an official Debian package would help these users, many of whom would not be comfortable with compiling software by hand, to try use bs2b in their systems. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libbs2b - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libbs2b/libbs2b_3.1.0-1.dsc -- and -- - URL: http://mentors.debian.net/debian/pool/main/b/bs2b-ladspa - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bs2b-ladspa/bs2b-ladspa_0.9.1-1.dsc I would be glad for any comments in review and, eventually, if someone would upload this package for me. Thanks! Andrew Gainer signature.asc Description: PGP signature
Re: RFS: libbs2b and bs2b-ladspa
Thanks for the review! On Thu, 21 Jul 2011 20:44:16 +0200 Paul Wise wrote: > On Thu, Jul 21, 2011 at 8:04 PM, Andrew Gainer wrote: > > > The package appears to be *sort of* lintian clean. > > When in doubt, run lintian with --info, which gives detailed > information about the warnings. Seems like I learn a new trick every day. This looks super-useful. > > * There are several old-fsf-address-in-copyright-file warnings. Is > > the correct procedure on these to correct the license texts (seems > > fishy) or leave them alone (and let lintian yell at me)? > > Fix them in debian/copyright and ask upstream to fix them in the > source code. Done. > > * libbs2b gives "no-symbols-control-file usr/lib/libbs2b.so.0.0.0". > > A quick bit of Googling leads me to believe that this isn't very > > important for a slow-moving API like this library's, but my > > knowledge of the inner workings of the linking system is pretty > > rudimentary. Input on this or other aspects of library packaging > > would be much appreciated. > > Symbols files are more useful for slower-moving ABIs, since they relax > dependency versions. This problem seems to have disappeared when I did some other futzing with the build system. I don't know why it did, but hopefully that's an end on it. > > * libbs2b also gives "source-contains-prebuilt-windows-binary > > win32/sndfile/libsndfile-1.dll", which is true. Of course, I'm not > > using the win32 files at all, so I guess the best thing to do is > > just to strip them out, but I'm not sure what the Debian Way to do > > this is. > > Yep, write a debian/rules get-orig-source tarball to create a new > tarball with those things removed. Done. I used the rules file from your package 'cultivation' as a template. I've changed the revision of libbs2b to 3.1.0+dfsg-1 to reflect this. New versions of both packages uploaded, fixing these and a couple of other glitches. lintian --pedantic now complains only of the lack of an upstream changelog in bs2b-ladspa, which is out of my hands. Thanks again for your advice, Paul. --Andrew signature.asc Description: PGP signature
Re: RFS: libbs2b and bs2b-ladspa
Thanks for your review! On Mon, 25 Jul 2011 12:44:49 +0300 "Eugene V. Lyubimkin" wrote: > [ I prefer to have a bumped package version after an each review ] Other mentors have preferred that I use the VCS for keeping track of pre-release changes and leave the changelog clean, with only the "Initial release (Closes: #ITP)" entry. As a relative neophyte to the Debian packaging-and-policy world, I'm not sure what the best way to approach this is. Can you clarify this? > --- > libbs2b > --- > > 1) there is definitely something wrong with >remove_win32_build_instruction patch, its size is more than 2 MiB > and it includes some autotools stuff; It looks like things got out of hand when I was trying to get rid of the win32/ directory to avoid some binary blobs. I've made this much cleaner by removing everything from this directory *except* the makefiles, which aren't run anyway as we're not building in a Windows environment, and leaving all the makefile contents alone. Everything is now handled in debian/rules:get-orig-source, so no patch is needed at all. > 2) Vcs-* fields point to LADSPA plugin repository; Derp. Fixed. > 3) debian/copyright: > 3.1) there is no m4/pkg.m4 source file; > 3.2) build-aux/* copyright years should be at least 1996-2010; > 3.3) aclocal.m4, */Makefile.in: is automatically generated, does not >need the entry; > 3.4) configure: copyright years should be 1992-2010. All fixed. > --- > bs2b-ladspa > --- > 2) debian/copyright: > 2.1) s!Files: *!Files: src/plugin.c! ; > 2.2) spurious 'Copyright 2009 Boris Mikhaylov' (copy leftover?); > 2.3) same (or about the same) corrections as in libbs2b's >debian/copyright. All fixed. I've gone ahead and uploaded the fixed version to mentors without bumping the version number for now, so you and other mentors can see the code changes if interested. Thanks again for your help! --Andrew signature.asc Description: PGP signature
Re: RFS: libbs2b and bs2b-ladspa
On Mon, 25 Jul 2011 20:33:18 +0300 "Eugene V. Lyubimkin" wrote: > Yes. Different sponsors prefer different ways to deal with pre-release > changes, I believe there's no single "best way". I want bumped after > each review (and with a usual changelog between) versions for > packages I intend to sponsor. Of course, if you have another > sponsor(s) in the mind, just ignore this. Alright, thanks for the clarification. I've bumped each package to *-2, added changelog entries, and uploaded again. --Andrew signature.asc Description: PGP signature
Re: OT: Saving GNU/Linux FOSS in the age of Android and iOS
On Fri, 4 Nov 2011 09:25:03 -0400 Bill Cox wrote: > The magic happening in Android, and I hate to admit but iOS too, is > they've gone back to the bazaar model where anyone can share any app > they like. You know that the Android and iOS 'app stores' are curated, right? On Android, at least, anyone can write an application with Free tools and distribute it however they like; to get it into the App Store requires the cooperation of Google or another managing entity. This doesn't seem very different to me, especially because: > That freedom to share is missing in Debian. To get a package *into* Debian. it needs to satisfy standards. To build a package that *installs* on Debian, you need to read about three pages of docs and run a handful of commands. Here in the Age of Ubuntu, you see this all the time. What is it you're proposing here in terms of software distribution? That the free software world needs better mechanisms than the Debian repositories for distributing software? That the curation requirements are too stringent? > To get there in GNU/Linux, I'm recommending that a basic "app" run in > a chroot and permissions jail, with hard links to the exact shared > libraries with which the app was originally built and tested. In your proposed system, does every GUI application come with its own binary copy of X11? If not, how do you deal with changes in the ABI? If so, how do you get more than one window at once? What do you do when two applications want to talk to each other but link against different versions of libdbus? Does every sound-based application ship with its own ALSA/OSS/whatever? If so, how do you handle mixing? If no, again, how do you handle ABI drift? Sandboxing is great for security, but trying to segregate applications into discrete library universes seems likely to damage or destroy the idea of a unified operating environment, which is essential for a lot of what we want computers to do. In any event, what you propose is a radical re-architecture of the desktop operating system. A desktop OS with sandboxing built in at the core is certainly a worthy experiment, and one which other groups are already working on. It doesn't look like Debian to me, though. What is it about this project that makes you think "Debian"? > In GNU/Linux land, > we've got Debian, Red Hat, Suse, Gentoo, and many other incompatible > distros where a binary from one will not run on the other. If I want > the whole world of deviant GNU/Linux hackers to enjoy the deep tones > of my stupid buggy fart app, I have to package it many different ways, > and pass the high standards of the monks of the various Linux base > distros. It's never going to happen. In fact, all you have to do is *get someone to help you*, as this mailing list shows. Not quite so onerous as having to learn all the packaging standards yourself, although you still might struggle to find a maintainer for your hypothetical fart noisemaker. Maybe not, though... there's a lot of silly stuff in Debian. In any event, the idea of a unified cross-distro packaging system comes up a lot, but it seems to miss an important point: each of yum, apt, pacman, and all the others is *already* a unified packaging system built deeply into the architectures of the distros that use it. The only mechanism I can see for eliminating packaging diversity is for the market share of n-1 packaging groups of distributions to vanish. This doesn't sound like a Big Win for the free community to me. > I just hope to > convince some of the Debian devs that there is a problem, and to start > thinking about a solution. If Debian wants simply to be the software > run on servers in dark closets, fine. Ignore the problem in that > case. Call me old-fashioned, but I just don't see the problem. Debian is not designed to be everything to everyone — there are just so many different kinds of computer users with so many different needs. Raw Debian is explicitly a bare-metal, do-anything-you-know-how-to-do GNU/Linux distribution, and radically changing that must necessarily disenfranchise the server-closet crowd and the e17-on-my-phone crowd even if it does manage to create a more fart-app-friendly distribution framework. On the other hand, there is a rich ecosystem of Debian derivatives providing a wealth of different computing experiences for many different kinds of users. Millions of people run Ubuntu on the desktop, for example, including my mother, who still calls a mouse a "clicker". The situation seems to be pretty healthy to me. Of course, bringing new software of reasonable quality into the system is always a boon, but I think we're doing a pretty okay job at that. --Andrew signature.asc Description: PGP signature
