Re: moving to multiarch for packages with plugins
Wow -- thanks so much everyone who replied. This is really helpful! Cheers, Dennis van Dok (on behalf of the other developers) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54e5b736.90...@nikhef.nl
Bug#778763: ITP: capture-output -- Ruby library to grab given IO output and return it as a string
Package: wnpp Severity: wishlist Owner: Alexander Gerasiov * Package name: ruby-capture-output Version : 1.0.0 Upstream Author : Jakub Pastuszek * URL : https://github.com/jpastuszek/capture-output * License : MIT/Expat Programming Lang: Ruby Description : Ruby library to grab given IO output and return it as a string Provides Caputere.output, Capture.stdout and Capture.stderr methods that can be used to grab output generated by current or spawned process. . This is useful for testing when you need to start a process and check its output or when you need to check current process output. Used for autotests in homesick (#778471). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219130410.30392.65534.reportbug@vice
Bug#778764: ITP: ruby-test-construct -- Ruby library that creates temporary files and directories for testing
Package: wnpp Severity: wishlist Owner: Alexander Gerasiov * Package name: ruby-test-construct Version : 2.0.0 Upstream Author : Ben Brinckerhoff * URL : https://github.com/bhb/test_construct * License : MIT/Expat Programming Lang: Ruby Description : Ruby library that creates temporary files and directories for testing TestConstruct is a DSL for creating temporary files and directories during testing. . Using construct is as simple as calling within_construct and providing a block. All files and directories that are created within that block are created within a temporary directory. The temporary directory is always deleted before within_construct finishes. . There is nothing special about the files and directories created with TestConstruct, so you can use plain old Ruby IO methods to interact with them. It's used in autotests by homesick (#778471) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219130949.30517.49658.reportbug@vice
Re: Hosting offers for Debian development
Mehdi Dogguy writes ("Re: Hosting offers for Debian development"):
> I imagine that this kind of question has been asked many times in the past
> but I didn't see a formal answer for it[1]: If someone is working on some
> new project/service for Debian and wants to be hosted on a DSA-managed
> machine, what are the criteria that should be met to be accepted? I guess
> 'root' access is not out of question, but I am sure there are other
> restrictions.
> It would be nice if DSA could clarify that for their fellow developers.
>
> [1]: or if it exists, I'd be happy to read it.
I don't think there is a formal list of `criteria' in that sense.
(If there is then of course it would be good if DSA could publish it,
eg here: https://dsa.debian.org/)
It's reasonably obvious that DSA would prefer the service to run on a
supported version of Debian (although I don't know how hard a
requirement that is) and that they will take an interest in the
architecture of the service, service users, security considerations,
and so on.
I recently had a need for a service machine, and DSA have been very
helpful and constructive.
I really recommend that if you have a similar need, you send an email
to DSA explaining what you are trying to do (including the
architecture of your service, etc., if that's not obvious). I think
they will help figure out how best to meet your needs.
The last time the project had a general conversation about this kind
of thing it was clear that DSA would much prefer to have Debian
services running on DSA-managed machines. My experience is that
they're willing and able to provide the support needed to make that
happen.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21733.63683.635139.869...@chiark.greenend.org.uk
deadline tommorrow! Re: Call for Debian projects and mentors in the Google Summer of Code 2015
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There are just three ideas there so far, including the one I just added myself - for anybody who hasn't participated in GSoC before, I personally feel there are some really good things about this program both for free software and for Debian and it is worth spending 10 minutes to put a project idea on the wiki. On 13/02/15 09:19, Nicolas Dandrimont wrote: > Hey everyone, > > Do you feel that it's been a long time since Debian participated in > a mentoring program? Well, fear not, this is your lucky day: Google > Summer of Code [0] is starting its 11th edition right now, and the > Debian Project will be applying for a mentoring organization spot > again this year, for the tenth time [1]. > > Our application can only be accepted if we have published a list of > project proposals by the time Google reviews organization > applications. Google ends their review on February 27th, so we need > your help! > > = What does Google Summer of Code do for Debian? = > > Google Summer of Code is a series of student internships, paid in > full by Google, where the student works for a Free Software > organization such as Debian during the summer, and receives a > stipend if the project is successful. > > We have found that GSoC is a good way to get new (and old) > contributors interested in the parts of Debian that you consider > important, and to keep some of them involved with Debian even after > the program ends. > > Putting together project proposals for GSoC allows you to showcase > your part of the project, in part for prospective GSoC students, > but also for the Debian community at large. > > = How do I propose a project for an intern? = > > If you have an idea for a project, please do TWO things: - Publish > the idea on the wiki page [2], filling out the template - Drop us a > mail on the coordination mailing-list [3,4] > > This two-step process helps us track project ideas and allows us to > discuss the project proposals in detail (scope-wise and > length-wise). You need to know (or remember) that the raw coding > phase for GSoC lasts a bit less than three months, and therefore > plan the project accordingly. > > If you're a student, and you have an idea for a project, please > submit it too! Everyone (Member of the Debian project or not, > student or not) is welcome to submit their ideas, and to try and > find people willing to mentor the projects. > > However, the project wiki page is split in two parts: "Project > ideas" and "Projects with confirmed mentors". Please put your > project in the right section, and note that mentors are critical to > the success of a GSoC project. We WILL remove "Projects ideas" > without confirmed mentors before the student application period > starts. > > Don't panic! mentoring takes time, but not _that_ much time, and > all the less if you find a motivated co-mentor (something we very > strongly encourage you to do). Furthermore, we admins will be here > all the way to help you when and if you need it. > > Should you need help about drafting a project proposal, or anything > else related to GSoC, please drop us a mail on the ML [3,4], or > drop by on our IRC channel [5], and we'll see what we can do! > > Cheers, - Nicolas, Sylvestre and Tom, your GSoC'15 admins > > [0] https://developers.google.com/open-source/soc/ [1] > https://wiki.debian.org/SummerOfCode2015 [2] > https://wiki.debian.org/SummerOfCode2015/Projects [3] > soc-coordinat...@lists.alioth.debian.org [4] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination > > [5] irc://irc.debian.org/#debian-soc > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU5kL1AAoJEOm1uwJp1aqDlTEP/iAsbPsRKOJDse+CIDV2ENhx ubUldpXHIOWlRff2zCLw/1HGza4ar38SA9826g+xwVTEjIa/9+Dk7idskLP9HcVw 5mXRtfctZZ5xiMrqFK7b4nv9aQ5Q8FdRcnfrsHAMaKbtuB2JeQom+HlnQ/797CAg M9vBuszBo2bFZV1YPbufqtOAGMF2x4TralcprSvYEEMbf3x2K9KUoOHis4Daou0q bYDqHxrZRciGZmS+ZJLsiBbsua/QVLMR7VQJ2VzEMLVIAFgLibk329gWuHmYphN5 cH8qU5A5cRSd4gh12iicXYa6cfqZb6P8cKfXqIBF3P/hFlFfDs/Sf4yvyDJ4EVLt o2ccPIpkO6uzb43iYqufP2A3JWQw650Qx+iaJZWUMjZM5ApONd3NgMQ5x5dV75UG EdJKH1k2NWMfbXF2X5m1odOqLfiXkF2QSM9cvL4GWeCYK7jeSmk3lqGkybLl50KM v1PZF/5OlFq+lCsqrjMmhBfNXRjNInTO1aoVAe5rEp5FJZstvQsRlvxhBIf77mCv iuLLram1xuZqAfk9YgOp//R+mo/brLwPqhrJziyK/lSyn3EMScsbUALmuK+Rbs13 4sRrtAOPO3wpoX++8aIdTIq6ZW9OMsvr565yFmYRbt8XLbSk0GpZ3XOj93tpcRIs QLGhMg9OuSgsSx1HrH19 =KpA7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54e642f6.80...@pocock.pro
RE:Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
Hi everyone, PICCA Frederic-Emmanuel writes: > @Konrad do you think that this netcdf implementation from scientific python > could be replace by this > netcdf4-python implementation ? Should we get rid of your implentation and > use this one instead (to be clear) The main problem with Python-netCDF interfaces is that no two of them have compatible API even for the most basic operations. Whenever some Python package depends on netCDF, it depends on one of the various Python-netCDF interfaces, and wouldn't work with the other ones. To make it worse, even if your goal is only to provide a single Python interface for new developments, not caring about compatibility, the features of the various Python interfaces are sufficiently different to make a choice very difficult. The unique feature of my own netCDF interface, and the reason why I keep maintaining it, is the C-level API for other Python modules. Each of the other interfaces has such unique features as well. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: research AT khinsen DOT fastmail DOT net http://dirac.cnrs-orleans.fr/~hinsen/ ORCID: http://orcid.org/-0003-0330-9428 Twitter: @khinsen - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21734.18557.231820.534...@gargle.gargle.howl
Bug#778789: ITP: python-congressclient -- client for the open policy framework for the cloud
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-congressclient Version : 1.0.2 Upstream Author : OpenStack Foundation * URL : https://github.com/stackforge/python-congressclient * License : Apache-2.0 Programming Lang: Python Description : client for the open policy framework for the cloud Congress is an open policy framework for the cloud. With Congress, a cloud operator can declare, monitor, enforce, and audit "policy" in a heterogeneous cloud environment. Congress get inputs from a cloud's various cloud services; for example in Openstack, Congress fetches information about VMs from Nova, and network state from Neutron, etc. Congress then feeds input data from those services into its policy engine where Congress verifies that the cloud's actual state abides by the cloud operator's policies. Congress is designed to work with any policy and any cloud service. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219213931.24778.4618.report...@buzig.gplhost.com
Re: Hosting offers for Debian development
On Thu, Feb 19, 2015 at 02:52:51PM +, Ian Jackson wrote: > I recently had a need for a service machine, and DSA have been very > helpful and constructive. > > I really recommend that if you have a similar need, you send an email > to DSA explaining what you are trying to do (including the > architecture of your service, etc., if that's not obvious). I think > they will help figure out how best to meet your needs. > Well, I am sure of that and didn't have doubts about it. Nevertheless, I do think it would be quite helpful to publish at least some sort of guidelines that developers should keep in mind while creating their project, if they plan to be hosted on a DSA-managed machine eventually. It also doesn't have to be exhaustive, but at least give an idea of what is reasonable to expect and what are the general restrictions. Regards, -- Mehdi Dogguy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219220723.gm23...@dogguy.org
Re: Should .a library contains non-reallocatable code?
* Dmitry Katsubo , 2015-02-14, 13:31: I wonder what is the current state-of-art concerning the code in .a library (archive for static linking). Should it contain PIC code? This is what Debian Policy (§10.2) currently says: “As to the static libraries, the common case is not to have relocatable code, since there is no benefit, unless in specific cases; therefore the static version must not be compiled with the ‘-fPIC’ flag. Any exception to this rule should be discussed on the mailing list debian-devel@lists.debian.org, and the reasons for compiling with the ‘-fPIC’ flag must be recorded in the file ‘README.Debian’.” -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219220805.ga8...@jwilk.net
Re: Should .a library contains non-reallocatable code?
Here are two scenarios where building a static library (libfoo) with -fPIC is desirable: * libbar has a stable API, so it should be shipped as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC, then libbar has to be shipped as a a static library too * foomodule is a Python wrapper for libfoo, so it must be shipped as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC, it is not possible to build foomodule at all (The same goes for wrapping the library for most other interpreted languages) (At $DAY_JOB this bit me in the last week [not pertaining to Debian-packaged software] so it's a sore spot at the moment) Unless the circumstances of libfoo make these scenarios unlikely, it seems like it is better for other packages to prefer -fPIC even when building a static library. I wonder whether these scenarios were considered when the Policy was written. Jeff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219231930.gb37...@unpythonic.net
Work-needing packages report for Feb 20, 2015
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 668 (new: 1) Total number of packages offered up for adoption: 151 (new: 0) Total number of packages requested help for: 57 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: morfeusz (#778795), orphaned today Description: morphological analyser of Polish Installations reported by Popcon: 1 667 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 151 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1844 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 73727 athcool (#278442), requested 3768 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 41 awstats (#755797), requested 211 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4184 balsa (#642906), requested 1243 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 738 cardstories (#624100), requested 1396 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 9 chromium-browser (#583826), requested 1726 days ago Description: Chromium browser Reverse Depends: chromedriver chromium-dbg chromium-l10n design-desktop-web mozplugger Installations reported by Popcon: 25974 cups (#532097), requested 2084 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (64 more omitted) Installations reported by Popcon: 144004 debtags (#567954), requested 1844 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2255 developers-reference (#759995), requested 173 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 15461 ejabberd (#767874), requested 108 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 827 fbcat (#565156), requested 1863 days ago Description: framebuffer grabber Installations reported by Popcon: 168 freeipmi (#628062), requested 1365 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 (5 more omitted) Installations reported by Popcon: 6065 gnat-gps (#496905), requested 2366 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 535 gnokii (#677750), requested 978 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1490 gradle (#683666), requested 931 days ago Description: Groovy based build system Reverse Depends: gradle libgradle-plugins-java Installations reported by Popcon: 236 gridengine (#703256), requested 704 days ago Description: Distributed resource management Reverse Depends: gridengine-client gridengine-drmaa-dev gridengine-exec gridengine-master gridengine-qmon logol Installations reported by Popcon: 1109 grub2 (#248397), requested 3937 days ago Description: GRand Unified Bootloader Reverse Depends: grml-rescueboot grml2usb grub-coreboot grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-dbg (37 more omitted) Installations reported by Popcon: 167798 guake (#755928), requested 210 days ago Description: Drop-down terminal for GNOME
