Re: Go (golang) packaging, part 2
On 31/01/2013 13:32, Jean-Christophe Dubacq wrote: >> > > Don't forget package.el for emacs! Wait, what? package.el uses Ruby, and not elisp? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Candidates for removal from testing results)
On 2013-01-24 15:47, Niels Thykier wrote: > [...] > # #697402 > remove bzr-gtk/0.103.0+bzr792-3 > Reassigned to python and downgraded. > # #694642 > remove glpi/0.83.31-1 > Fixed in sid and downgraded. > # #696816 > remove jenkins/1.447.2+dfsg-2 > Fixed in sid. > # #694589 > remove lastfmproxy/1.3b-2 > Removed from testing. > # #696844 > remove pmw/1:4.24-1 > Downgraded to important. ~Niels -- 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/510a3196.5060...@thykier.net
Re: Go (golang) packaging, part 2
On 31 January 2013 08:25, Chow Loong Jin wrote: > On 31/01/2013 13:32, Jean-Christophe Dubacq wrote: >>> > >> Don't forget package.el for emacs! > > Wait, what? package.el uses Ruby, and not elisp? > How did we start a thread on go packaging and now mention TeX Live package manager (tlmgr) ?! Regards, Dmitrijs. -- 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/canbhluh3s9zgvr93jttprlzdaqhjnxqhvq8o+nh2kcpn_ev...@mail.gmail.com
Re: bash readline
Hi Jack, Jack Andrews writes: > i really like the readline in bash - it seems bash is "vi complete" in > vi mode. Unfortunately it’s not vim-complete (not sure about “pure” vi), take for example this command line: foo "bar" baz Then, press Escape, 0, w, w, c, i, " — nothing happens, but in vim, this would replace “bar”. > now, i haven't looked closely, but i think the good vi mode is a patch > on (bash?) readline in debian? I suggest you look closely before posting: http://patch-tracker.debian.org/package/bash/4.2+dfsg-0.1 I see some patches on the readline code there, but none mentions something related to “df;” (I might be wrong). > but on ubu^H^H^Hdebian, rlwrap uses the vanilla readline and it's > really annoying that i can't get the same line editing features with > rlwrap (and, i expect, readline). I can confirm that. I suspect libreadline differs from bash’s readline. -- Best regards, Michael -- 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/x6r4l1myzc@midna.zekjur.net
Re: Go (golang) packaging, part 2
Chow, am Thu, Jan 31, 2013 at 09:44:27AM +0800 hast du folgendes geschrieben: > Well, really, the manageable case I was talking about was pip/easy_install > inside a Python virtualenv, which is basically a Python installation that is > kept completely distinct from the system's installation and doesn't touch > anything dpkg is supposed to be managing. it's not really "completely distinct". That aside that's basically what you get with the Go toolset if you change GOPATH. You can freely install libraries just like easy_install and use them from programs. (Except that the end product is always a binary that doesn't care if a library changes, contrary to Python.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#699428: ITP: maliit-framework -- flexible text input method framework
Package: wnpp Severity: wishlist Owner: Iain Lane * Package name: maliit-framework Version : 0.94.1 Upstream Author : Jan Arne Petersen , Michael Hasselmann * URL : https://wiki.maliit.org/Main_Page * License : LGPL-2.1+ Programming Lang: C++, C Description : flexible text input method framework Maliit provides a flexible and cross-platform input method framework for mobile and embedded text input. It has a plugin-based client-server architecture where applications act as clients and communicate with the Maliit server via toolkit-specific input context plugins. -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] -- 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/20130131112002.1200.51879.reportbug@raring
Bug#699429: ITP: maliit-plugins -- text input method framework - plugins
Package: wnpp Severity: wishlist Owner: Iain Lane * Package name: maliit-plugins Version : 0.94.0 Upstream Author : Jan Arne Petersen , Michael Hasselmann * URL : https://wiki.maliit.org/Main_Page * License : BSD-3-clause Programming Lang: C+ Description : flexible text input method framework - plpugins Maliit provides a flexible and cross-platform input method framework for mobile and embedded text input. It has a plugin-based client-server architecture where applications act as clients and communicate with the Maliit server via toolkit-specific input context plugins. . This package contains the maliit reference on-screen keyboard. -- 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/20130131113147.2745.33088.reportbug@raring
Building and using shared libraries using gccgo
* Michael Stapelberg:
> Can you please list the full instructions you did to accomplish building
> sparse/index/regexp as a shared library?
Sure. See the Makefile at the end of this mail. Please note that I don't
really know what I'm doing here -- just tried a few things and tried to
make sense of error messages until I got working binaries.
I put symlinks to the index, sparse, regexp directories into
src/code.google.com/p/codesearch and added -Isrc to every gccgo
invocation, so that the compiler looks for the local imports in the
right place. For the shared libraries, I added
1. -shared -fPIC
2. -fno-split-stack
Otherwise I could not link executables and got the following error
message:
/usr/bin/ld.bfd.real: cindex: hidden symbol `__morestack' in
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgcc.a/morestack.o) is referenced
by DSO
/usr/bin/ld.bfd.real: final link failed: Bad value
When the libraries are put into
src/code.google.com/codesearch/lib{sparse,regexp,index}.so, they are
subsequently found by the compiler -- and apparently used for imports,
even if the source files are missing.
I have not yet figured out how to specify the full namespace-related
path to the linker yet: -lcode.google.com/p/codesearch/index causes ld
then to look for libcode.google.com/p/codesearch/index.so which is
almost but not quite what is needed.
Cheers,
-Hilko
PREFIX=src/code.google.com/p/codesearch
GCCGO_FLAGS=-Isrc
GCCGO_LIBFLAGS = -shared -fPIC -fno-split-stack
GCCGO_LDFLAGS = -L$(PREFIX)
GCCGO_EXE_LDFLAGS = $(GCCGO_LDFLAGS) -Wl,-R,$(PREFIX)
dirs:
mkdir -p $(PREFIX)
ln -sf `pwd`/regexp `pwd`/index `pwd`/sparse $(PREFIX)/
LIBS=sparse regexp index
DYNLIBS=$(patsubst %,$(PREFIX)/lib%.so,$(LIBS))
dynlibs: $(DYNLIBS)
$(PREFIX)/lib%.so: $(PREFIX)/%/*.go
gccgo $(GCCGO_FLAGS) $(GCCGO_LIBFLAGS) -o $@ $^
$(PREFIX)/libregexp.so: $(PREFIX)/regexp/*.go
gccgo $(GCCGO_FLAGS) $(GCCGO_LIBFLAGS) -o $@ $^ $(GCCGO_LDFLAGS)
-lsparse
$(PREFIX)/libindex.so: $(PREFIX)/index/*.go
gccgo $(GCCGO_FLAGS) $(GCCGO_LIBFLAGS) -o $@ $^
$(GCCGO_LDFLAGS) -lsparse -lregexp
BINS=cindex csearch cgrep
cindex: cmd/cindex/*.go
gccgo $(GCCGO_FLAGS) -o $@ $^ $(GCCGO_EXE_LDFLAGS) -lindex
csearch: cmd/csearch/*.go
gccgo $(GCCGO_FLAGS) -o $@ $^ $(GCCGO_EXE_LDFLAGS) -lregexp -lindex
cgrep: cmd/cgrep/*.go
gccgo $(GCCGO_FLAGS) -o $@ $^ $(GCCGO_EXE_LDFLAGS) -lregexp
bins: $(DYNLIBS) $(BINS)
--
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/87ip6d4l1p.fsf...@msgid.hilluzination.de
Re: Building and using shared libraries using gccgo
Am 31.01.2013 13:02, schrieb Hilko Bengen: > 2. -fno-split-stack >Otherwise I could not link executables and got the following error >message: >/usr/bin/ld.bfd.real: cindex: hidden symbol `__morestack' in >/usr/lib/gcc/x86_64-linux-gnu/4.7/libgcc.a/morestack.o) is referenced >by DSO >/usr/bin/ld.bfd.real: final link failed: Bad value better use -fuse-ld=ld.gold, or in a packaging context, build-depend on binutils-gold. gold should be available on all archs where gccgo is available. Matthias -- 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/510a72d6.30...@debian.org
Processed: Re: Bug#699437: [Wheezy] dmraid (Promise Fastrak 100) boot issue
Processing commands for cont...@bugs.debian.org: > reassign 699437 dmraid 1.0.0.rc16-4.2 Bug #699437 [dmraid / os setup general] [Wheezy] dmraid (Promise Fastrak 100) boot issue Warning: Unknown package '/' Warning: Unknown package 'os' Warning: Unknown package 'setup' Bug reassigned from package 'dmraid / os setup general' to 'dmraid'. No longer marked as found in versions 1.0.0.rc16-4.2. Ignoring request to alter fixed versions of bug #699437 to the same values previously set Bug #699437 [dmraid] [Wheezy] dmraid (Promise Fastrak 100) boot issue Marked as found in versions dmraid/1.0.0.rc16-4.2. > thanks Stopping processing here. Please contact me if you need assistance. -- 699437: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699437 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.135964639532242.transcr...@bugs.debian.org
Re: GFDL in main
* Jakub Wilk , 2012-12-12, 21:25: Status update: [...] http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=jw...@debian.org&tag=gfdl binutils gdb gengetopt texi2html I haven't wrapped my head around these yet... I'll try again in a few days, unless somebody beats me to it (hint, hint). I've filed (or upgraded...) bugs against all of them, except gengetopt, which is a rather odd case. I asked upstream to clarify licensing of their documentation: http://lists.gnu.org/archive/html/help-gengetopt/2013-01/msg0.html -- Jakub Wilk -- 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/20130131170124.ga5...@jwilk.net
git.debian-maintainers.org, or somewhere else
(You might saw a similar maessage at http://lists.debian.org/debian-user/2013/01/msg01149.html . There were no replies.) packages.debian.org/source/squeeze/vsftpd is refering to http://git.debian-maintainers.org/?p=daniel/vsftpd.git. The reference is in the left column of the page, under the links for vsftpd title ( Debian Source Repository (Git) ). $ host git.debian-maintainers.org Host git.debian-maintainers.org not found: 3(NXDOMAIN) Neither packages.debian.org/source/wheezy/vsftpd nor the sid page seem to have the Debian Source Repository (Git) entry. Was the repository transfered to another site? Is it temporarily not avaialble? Something else? Should the entry in the squeeze page removed? Isn't maintaing debian source in a ro public accessible git repositories a good idea? -- 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/20130131163532.gb24...@nt1.in
Re: git.debian-maintainers.org, or somewhere else
On Thu, Jan 31, 2013 at 18:35 +0200, Regid Ichira wrote: > packages.debian.org/source/squeeze/vsftpd is refering to > http://git.debian-maintainers.org/?p=daniel/vsftpd.git. The > reference is in the left column of the page, under the links for > vsftpd title ( Debian Source Repository (Git) ). > > $ host git.debian-maintainers.org > Host git.debian-maintainers.org not found: 3(NXDOMAIN) > > Neither packages.debian.org/source/wheezy/vsftpd nor the sid page > seem to have the Debian Source Repository (Git) entry. Was the > repository transfered to another site? Is it temporarily not > avaialble? Something else? Should the entry in the squeeze page > removed? The Vcs-* entries have been removed in 2.3.4-1 as you can see in the changelog: -- snip -- vsftpd (2.3.4-1) unstable; urgency=low … * Removing vcs fields. … -- Daniel Baumann Mon, 05 Sep 2011 15:55:00 +0200 -- snip -- I am not sure why Daniel decided to remove them or where the package is maintained now, but that explains the behaviour you see on p.d.o and in the PTS. > Isn't maintaing debian source in a ro public accessible git > repositories a good idea? It is a good idea, but it is up to the maintainer to decide how (s)he wants to maintain her/his packages. Using a git repository certainly isn't mandatory even though it is quite common these days. Note that you can always get a source package with, for example, "apt-get source PKG" -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: git.debian-maintainers.org, or somewhere else
On Thu, 31 Jan 2013 18:35:32 +0200 Regid Ichira wrote: > packages.debian.org/source/squeeze/vsftpd is refering to > http://git.debian-maintainers.org/?p=daniel/vsftpd.git. Packages in stable are not generally updated for changes in the VCS links. Always use the package in unstable as the reference - if that doesn't give a link, only the maintainer knows why that was removed. > Neither packages.debian.org/source/wheezy/vsftpd nor the sid page > seem to have the Debian Source Repository (Git) entry. Was the > repository transfered to another site? Try asking the maintainer (follow the link to the PTS from the page you mentioned). There might also be information in the changelog for the latest version (in this case unstable) - again, linked from the PTS. In this case, 2.3.4-1 removed the vcs fields without further explanation, so ask the maintainer. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMzVcKUM00R.pgp Description: PGP signature
Re: Go (golang) packaging, part 2
On Jan 31, 2013, at 09:44 AM, Chow Loong Jin wrote: >Well, really, the manageable case I was talking about was pip/easy_install >inside a Python virtualenv, which is basically a Python installation that is >kept completely distinct from the system's installation and doesn't touch >anything dpkg is supposed to be managing. > >It's useful for installing crap from PyPI in a more or less standard, >distro-agnostic manner. This arrangement works pretty well for me in practice, especially since `virtualenv --system-site-packages` can usually give you the mix you need. Cheers, -Barry signature.asc Description: PGP signature
consensus about Built-Using?
Looking at recent package rejections for NEW uploads with the only thing being a
missing Built-Using attribute, and the voluntary disclosures in the recent
golang thread, I'm wondering if there is a consensus about the use of the
Built-Using attribute. The current solutions looks rather simplistic, and don't
offer much value (maybe except for easily implementing this in dak).
- footnote 58 in policy 7.8 says "The archive software might reject
packages that refer to non-existent sources". However they are also
manually rejected. And it looks like others aren't aware of this too.
- The scope of what belongs into Built-Using is not clear. Policy is
vague ("Examples include ...") and ftp-master seems to have a much
more narrow interpretation.
If "linking with static libraries" (and "object files" is missing here)
is what you want, then nearly every package having an executable
should have a Built-Using: eglibc. Every binary or shared library
linking with -lgcc (libgcc.a) should have a Built-Using: gcc-4.x.
Same for clang and probably most other compilers.
Is this wanted?
What is the value having this?
Looking further:
- binaries copying config.{guess,sub}: Built-Using: autotools?
- documentation copying templates: Built-Using:
- ...
- policy 7.8 requires the "exactly equal" relation to express this
dependency. This might be convenient for the dak developers, however
it is not what you always want.
- {gcj,gnat,gdc}-4.x do *only* use the upstream tarball in a
gcc-4.x-source package, which doesn't change between full source
uploads. So the correct field is e.g.:
Built-Using: gcc-4.7 (>= 4.7.2), gcc-4.7 (<< 4.7.3)
However I still fail to see, why the corresponding build-dependency
cannot be used to extract this information.
- libgcc.a doesn't change much, so what value does an exact version
have? An interval spanning even major versions would be good
enough to express this dependency. Otoh, how does a package uploader
get this interval, instead of the exact version?
- Built-Using doesn't belong into the binary package. Now you add >100
Built-Using attributes into the gcc-4.x control file just to replace
everyone of these with the *source* package name. Nice! Granted,
Ansgar Burchardt did provide me with a patch, but I won't do such
exercises on my own. Why not as part of the changes file?
- Built-Using shouldn't track source packages but binary packages.
If the field is supposed to be used for license tracking, then you
should consider that binary packages built from within the same
source package have different licenses.
E.g. a Built-Using linking against libiberty.a should have a
different outcome than linking against the binutils libs (which
nobody should do anyway, but this is a different story ...)
As a first step, policy 7.8 should allow ranges instead of exact binary
versions. And I would like ask ftp-master not to reject packages just on the
basis of a missing Built-Using field. Please accept, and file a non-RC issue
about this instead.
Matthias
--
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/510af324.5070...@debian.org
Re: consensus about Built-Using?
On Thu, Jan 31, 2013 at 11:41:40PM +0100, Matthias Klose wrote:
> Looking at recent package rejections for NEW uploads with the only thing
> being a
> missing Built-Using attribute, and the voluntary disclosures in the recent
> golang thread, I'm wondering if there is a consensus about the use of the
> Built-Using attribute. The current solutions looks rather simplistic, and
> don't
> offer much value (maybe except for easily implementing this in dak).
>
> - footnote 58 in policy 7.8 says "The archive software might reject
>packages that refer to non-existent sources". However they are also
>manually rejected. And it looks like others aren't aware of this too.
>
> - The scope of what belongs into Built-Using is not clear. Policy is
>vague ("Examples include ...") and ftp-master seems to have a much
>more narrow interpretation.
>
>If "linking with static libraries" (and "object files" is missing here)
>is what you want, then nearly every package having an executable
>should have a Built-Using: eglibc. Every binary or shared library
>linking with -lgcc (libgcc.a) should have a Built-Using: gcc-4.x.
>Same for clang and probably most other compilers.
>Is this wanted?
>What is the value having this?
The issue is licensing. These flags (IIRC) are to instruct the archive
to keep the source, so long as there's a package that was built using
it. Could be wrong, though.
This is a pretty important legal thing, IMHO. :)
>
>Looking further:
>- binaries copying config.{guess,sub}: Built-Using: autotools?
>- documentation copying templates: Built-Using:
>- ...
>
> - policy 7.8 requires the "exactly equal" relation to express this
>dependency. This might be convenient for the dak developers, however
>it is not what you always want.
>
>- {gcj,gnat,gdc}-4.x do *only* use the upstream tarball in a
> gcc-4.x-source package, which doesn't change between full source
> uploads. So the correct field is e.g.:
> Built-Using: gcc-4.7 (>= 4.7.2), gcc-4.7 (<< 4.7.3)
> However I still fail to see, why the corresponding build-dependency
> cannot be used to extract this information.
>
>- libgcc.a doesn't change much, so what value does an exact version
> have? An interval spanning even major versions would be good
> enough to express this dependency. Otoh, how does a package uploader
> get this interval, instead of the exact version?
>
> - Built-Using doesn't belong into the binary package. Now you add >100
>Built-Using attributes into the gcc-4.x control file just to replace
>everyone of these with the *source* package name. Nice! Granted,
>Ansgar Burchardt did provide me with a patch, but I won't do such
>exercises on my own. Why not as part of the changes file?
>
> - Built-Using shouldn't track source packages but binary packages.
>If the field is supposed to be used for license tracking, then you
>should consider that binary packages built from within the same
>source package have different licenses.
>E.g. a Built-Using linking against libiberty.a should have a
>different outcome than linking against the binutils libs (which
>nobody should do anyway, but this is a different story ...)
>
> As a first step, policy 7.8 should allow ranges instead of exact binary
> versions. And I would like ask ftp-master not to reject packages just on the
> basis of a missing Built-Using field. Please accept, and file a non-RC issue
> about this instead.
>
> Matthias
>
>
> --
> 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/510af324.5070...@debian.org
>
--
.''`. Paul Tagliamonte
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
Work-needing packages report for Feb 1, 2013
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: 530 (new: 15) Total number of packages offered up for adoption: 141 (new: 1) Total number of packages requested help for: 62 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: batv-milter (#699110), orphaned 4 days ago Description: Mail Filter (milter) for BATV signing/verification Installations reported by Popcon: 5 bup (#699163), orphaned 3 days ago Description: highly efficient file backup system based on git Installations reported by Popcon: 174 gdome2 (#698981), orphaned 5 days ago Description: DOM level2 library for accessing XML files Installations reported by Popcon: 12944 ike-scan (#698994), orphaned 5 days ago Description: discover and fingerprint IKE hosts (IPsec VPN Servers) Installations reported by Popcon: 173 inform (#698980), orphaned 5 days ago (non-free) Description: story file compiler for the Inform interactive fiction language Installations reported by Popcon: 38 libdumbnet (#698982), orphaned 5 days ago Description: A dumb, portable networking library Installations reported by Popcon: 1228 libnss-ldap (#699114), orphaned 4 days ago Description: NSS module for using LDAP as a naming service Installations reported by Popcon: 4678 libpam-ldap (#699116), orphaned 4 days ago Description: Pluggable Authentication Module for LDAP Installations reported by Popcon: 5033 mrxvt (#698983), orphaned 5 days ago Description: lightweight multi-tabbed X terminal emulator Installations reported by Popcon: 511 mt-st (#698986), orphaned 5 days ago Description: Linux SCSI tape driver aware magnetic tape control Installations reported by Popcon: 1184 nvi (#698988), orphaned 5 days ago Description: 4.4BSD re-implementation of vi Installations reported by Popcon: 3248 qmtest (#699036), orphaned 5 days ago Description: Testing Framework (part of the Quality Management Toolset (QM)) Installations reported by Popcon: 26 rxvt (#698991), orphaned 5 days ago Description: VT102 terminal emulator for the X Window System Installations reported by Popcon: 1969 rxvt-beta (#698992), orphaned 5 days ago Description: VT102 terminal emulator for the X Window System Installations reported by Popcon: 94 uucp (#699118), orphaned 4 days ago Description: Unix to Unix Copy Program Installations reported by Popcon: 1140 515 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: cityhash (#699101), offered 4 days ago Description: family of non-cryptographic hash functions for strings Installations reported by Popcon: 2 140 older packages have been omitted from this listing, 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 1095 days ago Description: maintenance tools for a Xapian index of Debian packages Installations reported by Popcon: 61634 asymptote (#517342), requested 1434 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 4137 athcool (#278442), requested 3019 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 65 balsa (#642906), requested 494 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 782 bastille (#592137), requested 908 days ago Description: Security hardening tool Installations reported by Popcon: 176 cardstories (#624100), requested 647 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 8 chromium-browser (#583826), requested 977 days ago Description: Chromium browser Installations reported by Popcon: 11967 debtags (#567954), requested 1095 days ago Description: Enables support for package tags Installations reported by Popcon: 2441 doc-central (#566364), requested 1104 days ago Description: web-based documentation browser Installations reported by Popcon: 202 fbcat (#565156), requested 1114 days ago Description: framebuffer grabber Installations reported by Popcon: 158 flightgear (#487388), requested 1685
Bug#699496: ITP: apr-json -- JSON serializer / deserializer for use with Apache Portable Runtime (APR)
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: apr-json Version : 0.0.0 Upstream Author : Moriyoshi Koizumi * URL : https://github.com/moriyoshi/apr-json * License : Apache 2.0 Programming Lang: C Description : APR-based JSON serializer/deserializer libapr-json provides a JSON serializer/deserializer based on the Apache Portable Runtime (APR). -- 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/20130201004917.24859.24960.report...@alice.fifthhorseman.net
Re: Go (golang) packaging, part 2
On 01/02/2013 05:23, Barry Warsaw wrote: > This arrangement works pretty well for me in practice, especially since > `virtualenv --system-site-packages` can usually give you the mix you need. Yes it does in most cases, but --system-site-packages can do the wrong thing in certain edge-cases like trying to find a sane interface to libmagic in Python. There are at least three different Python modules available on PyPI that provide the magic module, i.e. "import magic", and *all* of them have *different* APIs. If you're lucky, you end up deploying on a distro (e.g. in shared hosting or in a PaaS like Openshift) that has the wrong magic module installed on the system, and your application/library crashes and burns in a very spectacular manner. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Bug#699507: ITP: python-json-pointer -- resolve JSON pointers
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-json-pointer Version : 0.6 Upstream Author : Stefan Kögl * URL : https://github.com/stefankoegl/python-json-pointer * License : BSD-3-clauses Programming Lang: Python Description : resolve JSON pointers Python-json-pointer is a small library to resolve JSON pointers. -- 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/20130201043817.31678.24178.report...@buzig.gplhost.com
Bug#699508: ITP: python-json-patch -- library to apply JSON patches
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-json-patch Version : 0.12 Upstream Author : Stefan Kögl * URL : https://github.com/stefankoegl/python-json-patch * License : BSD-3-clauses Programming Lang: Python Description : library to apply JSON patches Python-json-patch is a Python module (a library) to apply JSON Patches according to http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-08 -- 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/20130201044209.31759.14283.report...@buzig.gplhost.com
Bug#699511: ITP: haskell-rosezipper -- Generic zipper implementation for Data.Tree in Haskell
Package: wnpp Severity: wishlist Owner: Masayuki Hatta * Package name: haskell-rosezipper Version : 0.2 Upstream Author : Krasimir Angelov and Iavor S. Diatchki * URL : http://hackage.haskell.org/package/rosezipper * License : BSD Programming Lang: Haskell Description : Generic zipper implementation for Data.Tree in Haskell This Haskell library provides a Haskell datastructure for working with locations in trees or forests. This is used by Yi. -- 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/20130201070543.26908.1396.report...@xanadu.mhatta.org
