Bug#636308: ITP: fso-common -- configuration files for FSO related devices
Package: wnpp Severity: wishlist Owner: Rico Rommel * Package name: fso-common Version : 0.1 * License : GPL Description : configuration files for FSO related devices This package contains configuration files that are not part of fso-packages and dependencies to packages needed for Openmoko devices -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802073801.4361.35411.reportbug@pinguin.deutsches-haus
Re: Patch mgmt workflow proposal
also sprach Ben Finney [2011.08.02.0223 +0200]: > > This comes about ¾ of the way to the history pollution done by TopGit. > > I consider it very useful information, when needed. It's only pollution > if you let it be so. That is a very wise statement, and I agree. > > Not only would users potentially get confused by this additional > > branch (which is an implementation detail), it would also get in > > the way in gitk output (cf. pristine-tar) and annoy even the > > unconfused. > > That's an argument not for hobbling a useful branching-and-merging > workflow, but for improving the output of those programs. Advocate > with Git (and other VCSen) to hide merged revisions by default, > the way Bazaar does. One person's reasonable default is another person's nightmare. Fact is that we have new contributors who are being shyed away by complexity. Fact is also that you can already hide information explicitly. I have already dipped my foot in the water on this [http://bugs.debian.org/636228], but I feel somewhat it's an uphill battle. In the end, the best solution is one that doesn't expose implementation details in the first place. The discussion at http://www.spinics.net/lists/git/msg162549.html is shaping up to be interesting. -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems http://lavender.cime.net/~ricky/badgers.txt digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#636330: RFA: convirt -- management system for open source hypervisors and cloud platforms
Package: wnpp Severity: normal Hi, I request an adopter for the convirt package. There are 2 open RC bugs caused by upstream source being non-DFSG-free. Unfortunately, upstream doesn't respond nor issue updates in a timely manner. Maybe someone wants to pick up maintainership. She will need to do quite a bit of upstream work also. The package description is: Convirt is a management system for open source hypervisors and cloud platforms aimed at rapid provisioning, lifecycle automation and private cloud management. . With ConVirt, you configure, monitor and automate your Xen and KVM deployments and private clouds from a single at-a-glance dashboard. Thanks, Roland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802091131.1078.42829.report...@rst-pc1.lan.work-microwave.de
Re: A few observations about systemd
On Tue, Aug 02, 2011 at 08:37:03AM +0200, Vincent Bernat wrote: > Or have a firewall configured. A (properly configured) firewall¹ might prevent *inbound* service abuse, but there's always a potential for a mis- or un-configured service to cause problems on a network (*outbound* service abuse²): a contrived example might be a DHCP server advertising leases³. 1. and we still don't supply a configured firewall with a default install 2. yes, perhaps a properly configured firewall has a default deny outbound policy, too… 3. which I expect no existing packaged dhcpd will do; hence contrived -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802091606.GB918@pris
Bug#636333: ITP: combat -- CORBA scripting with Tcl
Package: wnpp Severity: wishlist Owner: Thomas Girard * Package name: combat Version : 0.8.1 Upstream Author : Frank Pilhofer * URL : http://www.fpx.de/Combat/ * License : BSD-2 Programming Lang: Tcl Description : CORBA scripting with Tcl Combat is a CORBA Object Request Broker that allows the implementation of CORBA clients and servers in the Tcl programming language. . On the client side, Combat is not only useful to easily test-drive existing CORBA servers, including the ability for rapid prototyping or to interactively interface with servers from a console, but makes Tcl an exciting language for distributed programming. Also, Tk allows to quickly develop attractive user interfaces accessing CORBA services. Server-side scripting using [incr Tcl] classes also offers a wide range of possibilities. . Combat is compatible with the CORBA 3.0 specification including the IIOP protocol, and has been tested to interoperate with a wide range of open-source and commercial ORBs, including MICO, TAO and ORBexpress. . Combat is written in pure Tcl, allowing it to run on all platforms supported by Tcl, which is a much wider range than supported by any other ORB. Packaging is here: http://anonscm.debian.org/gitweb/?p=pkg-corba/pkg-combat.git;a=summary -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802095014.32363.68374.reportbug@gratos
Re: A few observations about systemd
On Mon, Aug 01, 2011 at 12:14:31PM +0200, Marco d'Itri wrote: > > Making the "do not start by default" policy default for the distro should > > improve out-of-box security. > When I install a package I want to actually use it. > A better security policy is to not install by default useless packages. > What is "use"? For example rsync package provides both "rsync" client and rsync daemon. Both cases are "use", right? Another example is dovecot-imapd. It's possible to use it in preauthenticated mode. In such case no system-wide daemon is required and mail client should just start imapd and talk with it using stdin/stdout. Also some services may be needed only sometimes (like ejabberd on laptop when developing some XMPP stuff). Or "tor" package that also provides system-wide tor daemon. At the same time it's possible to use tor individually by every user and start it only when needed. At least on laptops. -- WBR, Dmitry signature.asc Description: Digital signature
Re: A few observations about systemd
On Aug 02, Dmitry Nezhevenko wrote: > What is "use"? The maintainers decides what are the prevalent use cases of the package and try to use defaults which are appropriate for the largest number of users. > For example rsync package provides both "rsync" client and > rsync daemon. Both cases are "use", right? Yes, and very few people use standalone rsync servers. > Another example is dovecot-imapd. It's possible to use it in > preauthenticated mode. In such case no system-wide daemon is required and > mail client should just start imapd and talk with it using stdin/stdout. Again something which is very uncommon. > Also some services may be needed only sometimes (like ejabberd on laptop > when developing some XMPP stuff). This corner case could be applied to just about everything. > Or "tor" package that also provides system-wide tor daemon. At the same > time it's possible to use tor individually by every user and start it only > when needed. At least on laptops. And this one too. In summary, you need to use some common sense and knowledge of the packages involved and their users. -- ciao, Marco signature.asc Description: Digital signature
Bug#636350: ITP: gpac -- multimedia framework for research and academic purposes
Package: wnpp Severity: wishlist Owner: Debian Multimedia Maintainers * Package name: gpac Version : 0.4.5+svn3450 Upstream Author : Jean Le Feuvre * URL : http://gpac.sourceforge.net * License : LGPL Programming Lang: C Description : multimedia framework for research and academic purposes GPAC stands for GPAC Project on Advanced Content (a recursive acronym). It is an Open Source multimedia framework for research and academic purposes. The project covers different aspects of multimedia, with a focus on presentation technologies (graphics, animation and interactivity). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e380750.c586e50a.37a0.a...@mx.google.com
Re: [Lennart Poettering] Re: A few observations about systemd
Jon Dowland writes: > It completely predates Debian releasing non-Linux > kernels and is not mentioned in the social contract. That some > people feel it justifies (or even mandates) non-Linux kernels in > Debian is a retcon. pf, ZFS; these are valid reasons stated that > support kFreeBSD. "I interpret 'the Universal OS to mean'?" is not. Debian has a long history of trying to make it possible to use Debian for as many purposes as we can, even when that means that the system has to be more complicated, or even when it means Debian has to be less perfectly suited to some particular purposes - even particular purposes which many people think are very important. Or to put it another way, we place a very high value on flexibility. Whatever phrase one uses to encapsulate this, I think it is one of Debian's strengths. Being able to run a different kernel is, I think, one of those strengths. Others have given practical reasons why one might want to run a specific different kernel right nnow. But another reason is just that it wouldn't be healthy for us to bind ourselves too inextricably to the success of any other project, even one as well-established and apparently successful as the Linux kernel. For me, all this means we should not standardise on an init system which depends heavily on very Linux-specific (and perhaps not even particularly stable) kernel features. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20024.15657.543535.292...@chiark.greenend.org.uk
Re: Minimal init [was: A few observations about systemd]
Marc Haber writes ("Re: Minimal init [was: A few observations about systemd]"):
> On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
> wrote:
> >No, I don't think so. If these external tools double fork then they
> >are just wrong.
>
> Double Forking has been the right way to do it for decades. Demanding
> >from upstreams that they change their software this fundamentally to
> cater for a new init system is as unrealistic as demanding from
> upstreams to stay around snooping for new IP addresses that came
> online after the daemon was started to cater for IPv6.
However it is very easy to patch daemons to have an option which
causes them not to fork. Most daemons /already/ have a mode in which
they don't fork, for debugging purposes.
I think we should be quite happy to carry those patches forever, for
the few upstreams who won't take them.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20024.16007.757337.635...@chiark.greenend.org.uk
Re: Making daemons compatible with systemd [was: Minimal init]
Juliusz Chroboczek writes ("Making daemons compatible with systemd [was:
Minimal init]"):
> > From what I've seen in Lennart's posts, adding systemd support doesn't
> > seem to be too complicated.
>
> No. No changes at all are necessary to be compatible with systemd.
> This is a very impressive feature of systemd; at the same time, this is
> what complicates systemd, and creates a dependency on cgroups.
I don't think this is a good tradeoff.
It is much better to modify the few upstream daemons which would need
patching, than to add all of this extra machinery to support what
seems to me to be a design whose entire purpose is to workaround a
to-my-mind-broken interface paradigm (daemon(3)) invented decades ago.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20024.16123.959575.290...@chiark.greenend.org.uk
Bug#636374: ITP: libbusiness-edi-perl -- class for generating U.N. EDI interchange objects
Package: wnpp Severity: wishlist Owner: Ben Webb * Package name: libbusiness-edi-perl Version : 0.05 Upstream Author : Joe Atzberger * URL : http://search.cpan.org/dist/Business-EDI/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : class for generating U.N. EDI interchange objects The focus of functionality is to provide object based access to EDI messages and subelements. At present, the EDI input processed by Business::EDI objects is JSON from the edi4r ruby library, and there is no EDI output beyond the perl objects themselves. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802191842.29253.43381.report...@li147-160.members.linode.com
Bug#636378: ITP: libcql-parser-perl -- Common Query Language parser
Package: wnpp Severity: wishlist Owner: Ben Webb * Package name: libcql-parser-perl Version : 1.10 Upstream Author : Ed Summers * URL : http://search.cpan.org/dist/CQL-Parser/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Common Query Language parser Base class for boolean nodes in a CQL parse tree. See CQL::AndNode and CQL::OrNode. CQL::BooleanNode inherits from CQL::Node. Typically you'll want to use CQL::AndNode or CQL::OrNode to instantiate the object. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802192709.29320.74511.report...@li147-160.members.linode.com
Bug#636379: ITP: libnet-z3950-simple2zoom-perl -- gateway between Z39.50 and SRU/SRW
Package: wnpp Severity: wishlist Owner: Ben Webb * Package name: libnet-z3950-simple2zoom-perl Version : 1.04 Upstream Author : Sebastian Hammer and colleagues * URL : http://search.cpan.org/dist/Net-Z3950-Simple2ZOOM/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : gateway between Z39.50 and SRU/SRW The Net::Z3950::Simple2ZOOM module provides all the application logic of a generic "Swiss Army Gateway" between Z39.50 and SRU. It is used by the simple2zoom program, and there is probably no good reason to make any other program to use it. For that reason, this library-level documentation is more than usually terse. The library has only two public entry points: the new() constructor and the launch_server() method. The synopsis above shows how they are used: a Simple2ZOOM object is created using new(), then the launch_server() method is invoked on it to -- get ready for a big surprise here -- launch the server. (In fact, this synopsis is essentially the whole of the code of the simple2zoom program. All the work happens inside the library.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802193226.29376.17198.report...@li147-160.members.linode.com
Bug#636380: ITP: libsru-perl -- framework for Search and Retrieval by URL
Package: wnpp Severity: wishlist Owner: Ben Webb * Package name: libsru-perl Version : 0.99 Upstream Author : Ed Summers * URL : http://search.cpan.org/dist/SRU/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : framework for Search and Retrieval by URL The SRU package provides a framework for working with the Search and Retrieval by URL (SRU) protocol developed by the Library of Congress. SRU defines a web service for searching databases containing metadata and objects. SRU often goes under the name SRW which is a SOAP version of the protocol. You can think of SRU as a RESTful version of SRW, since all the requests are simple URLs instead of XML documents being sent via some sort of transport layer. You might be interested in SRU if you want to provide a generic API for searching a data repository and a mechanism for returning metadata records. SRU defines three verbs: explain, scan and searchRetrieve which define the requests and responses in a SRU interaction. This set of modules attempts to provide a framework for building an SRU service. The distribution is made up of two sets of Perl modules: modules in the SRU::Request::* namespace which represent the three types of requests; and modules in the SRU::Response::* namespace which represent the various responses. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802193358.29404.10207.report...@li147-160.members.linode.com
Re: Making daemons compatible with systemd
]] Ian Jackson | It is much better to modify the few upstream daemons which would need | patching, than to add all of this extra machinery to support what | seems to me to be a design whose entire purpose is to workaround a | to-my-mind-broken interface paradigm (daemon(3)) invented decades ago. I'm looking forward to your patches for the proprietary HP and Dell daemons that are used for monitoring the health of various hardware components. (Sure, they might not be packaged for Debian, but adopting an init system that doesn't deal with double-forking would be much, much worse than adopting one which is Linux-specific for our Linux ports.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc07lhbx@qurzaw.varnish-software.com
Bug#636381: ITP: liblibrary-callnumber-lc-perl -- utility functions to deal with Library-of-Congress call numbers
Package: wnpp Severity: wishlist Owner: Ben Webb * Package name: liblibrary-callnumber-lc-perl Version : 0.10 Upstream Author : Bill Dueber * URL : http://search.cpan.org/dist/Library-CallNumber-LC/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : utility functions to deal with Library-of-Congress call numbers Library::CallNumber::LC is mostly designed to do call number normalization, with the following goals: The normalized call numbers are comparable with each other, for proper sorting The normalized call number is a short as possible, so left-anchored wildcard searches are possible (e.g., searching on "A11*" should give you all the A11 call numbers) A range defined by start_of_range and end_of_range should be correct, assuming that the string given for the end of the range is, in fact, a left prefix. That last point needs some explanation. The idea is that if someone gives a range of, say, A-AZ, what they really mean is A - AZ.99. The end_of_range method pads the given call number out to three cutters if need be. There is no attempt to make end_of_range normalization correspond to anything in real life. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802195902.29566.55652.report...@li147-160.members.linode.com
Re: Providing official virtualisation images of Debian
On 07/30/2011 08:52 AM, olivier sallou wrote: Adding this possiblity would provide VM for Debian but also Debian users to create their own Debian customized VM. this should be very easy to integrate into live-studio.debian.net and live-build.debian.net. I talked some time ago with one of the developpers on Debian Live and was expecting to do so this summer (if he has some time...). returned after debconf, catching up with real-life, and then getting to it on friday.. i'll put up a little announcement on the weekend about the current status etc. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e38593c.7090...@progress-technologies.net
Bug#636399: ITP: cookiesafe-lite -- Control which websites have permission to set cookies.
Package: wnpp Severity: wishlist Owner: Ximin Luo I intend to package this as part of the pkg-mozext group. * Package name: cookiesafe-lite Version : 1.4 Upstream Author : csdev https://addons.mozilla.org/en-US/firefox/user/7045/ * URL : https://addons.mozilla.org/en-US/firefox/addon/cs-lite/ * License : GPL-2 Programming Lang: Javascript Description : Control which websites have permission to set cookies. This extension will allow you to easily control cookie permissions. It can be accessed from the statusbar, a toolbar button, or the context menu. Just click on the icon to allow, block, or temporarily allow the site to set cookies. You can also view, clear or edit the cookies and exceptions by right clicking on the cs lite icon. This is a lighter, scaled down version of CookieSafe. It contains less features, but is considerably easier to use. The extension has been completely recoded from top to bottom making this the most stable version to date. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110802214326.11567.35488.reportbug@localhost.localdomain
Re: Minimal init [was: A few observations about systemd]
On Tue, Aug 02, 2011 at 07:14:31PM +0100, Ian Jackson wrote:
> Marc Haber writes ("Re: Minimal init [was: A few observations about
> systemd]"):
> > On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson
> > wrote:
> > >No, I don't think so. If these external tools double fork then they
> > >are just wrong.
> > Double Forking has been the right way to do it for decades. Demanding
> > >from upstreams that they change their software this fundamentally to
> > cater for a new init system is as unrealistic as demanding from
> > upstreams to stay around snooping for new IP addresses that came
> > online after the daemon was started to cater for IPv6.
> However it is very easy to patch daemons to have an option which
> causes them not to fork. Most daemons /already/ have a mode in which
> they don't fork, for debugging purposes.
> I think we should be quite happy to carry those patches forever, for
> the few upstreams who won't take them.
FWIW, I've gotten feedback from Samba upstream that the upstart job for smbd
in Ubuntu, which runs the daemon foregrounded, is concerning to them because
foreground mode hasn't been tested upstream in about a decade. No bug
reports yet about actual breakage, but if not for the fact that smbd manages
to bewilder upstart's daemon tracking code when allowed to daemonize (fix
coming soon), I would switch the job to invoke smbd in the usual fashion.
There's also the matter that if your daemon is being run in the foreground,
other services depend on it, and you're not using socket activation, there's
ambiguity as to when the service is actually "started". A racy startup is a
bad thing.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: A few observations about systemd
Ian Jackson chiark.greenend.org.uk> writes: > Debian has a long history of trying to make it possible to use Debian > for as many purposes as we can, even when that means that the system > has to be more complicated, or even when it means Debian has to be > less perfectly suited to some particular purposes - even particular > purposes which many people think are very important. Like others who made similar arguments in the thread earlier, you're using a very contrived notion of what count as different "purposes Debian is usable for". kFreeBSD support is useful for only few people. Alternative ways of using the same effort would be useful for a lot more people, and a lot more diverse uses. You're obfuscating this fact by acknowledging only kFreeBSD as feature that counts as "making it possible to use Debian" for the people it benefits. > Or to put it another way, we place a very high value on flexibility. > Whatever phrase one uses to encapsulate this, I think it is one of > Debian's strengths. Lacking good support for systemd, and especially being stuck with sysvinit any longer than necessary, is very much the opposite of flexibility. > Being able to run a different kernel is, I think, one of those > strengths. Others have given practical reasons why one might want to > run a specific different kernel right nnow. But another reason is > just that it wouldn't be healthy for us to bind ourselves too > inextricably to the success of any other project, even one as > well-established and apparently successful as the Linux kernel. Timescale for switching init systems is shorter than the timescale Linux could realistically fail over. And even if you assume a switch in the future that does not imply that it would make sense to waste effort on workarounds now. A healthy Debian that had benefited from all Linux features would likely be better prepared for a switch to a different kernel than a Debian that had spent years catering to arbitrary limitations for hypothetical reasons. > For me, all this means we should not standardise on an init system > which depends heavily on very Linux-specific (and perhaps not even > particularly stable) kernel features. systemd has already been adopted widely enough to ensure that kernel features it depends on won't just suddenly disappear. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20110803t015816-...@post.gmane.org
