Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

2017-02-08 Thread Jonathan Yu
On Wed, Feb 8, 2017 at 1:19 PM, Ben Hutchings <b...@decadent.org.uk> wrote:

> Control: notfound -1 4.8.15-2
> Control: tag -1 moreinfo
>
> On Wed, 2017-02-08 at 09:17 -0800, Jonathan Yu wrote:
> > Package: src:linux
> > Version: 4.8.15-2
> [...]
>

Hey Ben,

Forgot to say: Thank you very much for your great work! I've never had any
trouble upgrading in the past, which is a testament to your hard work :)

>
> But this is the working version, not the broken versin.  Which 4.9.x
> version did you install?  If it is 4.9.2-2 (current in testing), please
> try 4.9.6-3 (current in unstable).
>

I'm using: ii  linux-image-4.9.0-1-amd644.9.2-2
 amd64Linux 4.9 for 64-bit PCs (signed)

I will upgrade to the version in unstable and try again, thanks for the
tip!

Here's my apt policy (I guess it might be helpful if this was included in
reportbug reports) - I use packages mostly from testing :)

$ apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://dl.google.com/linux/chrome/deb stable/main amd64 Packages
 release v=1.0,o=Google, Inc.,a=stable,n=stable,l=Google,c=main,b=amd64
 origin dl.google.com
 -10 http://ftp.us.debian.org/debian experimental/non-free i386 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/non-free amd64 Packages
 release
o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/main i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/non-free i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/main i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 -10 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/contrib i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/contrib amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=contrib,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/non-free i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=non-free,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/non-free amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=non-free,b=amd64
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/main i386 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=i386
 origin ftp.us.debian.org
 900 http://ftp.us.debian.org/debian testing/main amd64 Packages
 release o=Debian,a=testing,n=stretch,l=Debian,c=main,b=amd64
 origin ftp.us.debian.org
Pinned packages:


Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9

2017-02-08 Thread Jonathan Yu
Package: src:linux
Version: 4.8.15-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After upgrading my system (Debian testing) and rebooting, the system hangs at
"Loading initial ramdisk".

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I also tried editing the Grub boot parameters to remove "quiet splash", but
this did not produce any additional output. I'm happy to help troubleshoot
the problem and provide other diagnostics that you may need. I didn't see
anything useful in the systemd journal or dmesg for a successful boot. 

I'm currently booted with an older kernel that I had installed (4.8) and that
works fine.

   * What was the outcome of this action?

The system hangs.

   * What outcome did you expect instead?

I expected the system to boot normally.

Here are the contents of my /boot folder. I should be using Debian packages for
everything, except for Chrome Beta which I have installed via Google's 
repository.

$ ls -al /boot
total 72M
drwxr-xr-x.  5 root root 1.0K Jan 25 12:08 .
drwxr-xr-x. 22 root root 4.0K Jan 25 11:52 ..
-rw-r--r--   1 root root 180K Nov 12 20:38 config-4.8.0-1-amd64
-rw-r--r--   1 root root 180K Jan  4 11:39 config-4.8.0-2-amd64
-rw-r--r--   1 root root 182K Jan 12 07:52 config-4.9.0-1-amd64
drwx--   3 root root 4.0K Dec 31  1969 efi
drwxr-xr-x.  5 root root 1.0K Feb  8 08:56 grub
-rw---.  1 root root  13M Jun 12  2016 initramfs-4.6.0-1-amd64.img
-rw---   1 root root  13M Feb  8 08:56 initrd.img-4.8.0-1-amd64
-rw---   1 root root  13M Feb  8 08:56 initrd.img-4.8.0-2-amd64
-rw---   1 root root  13M Feb  8 08:56 initrd.img-4.9.0-1-amd64
drwx--.  2 root root  12K Feb 10  2016 lost+found
-rw-r--r--   1 root root 3.1M Nov 12 20:38 System.map-4.8.0-1-amd64
-rw-r--r--   1 root root 3.0M Jan  4 11:39 System.map-4.8.0-2-amd64
-rw-r--r--   1 root root 3.1M Jan 12 07:52 System.map-4.9.0-1-amd64
-rw-r--r--   1 root root 4.0M Nov 16 09:13 vmlinuz-4.8.0-1-amd64
-rw-r--r--   1 root root 4.0M Jan  5 20:14 vmlinuz-4.8.0-2-amd64
-rw-r--r--   1 root root 4.0M Jan 13 06:51 vmlinuz-4.9.0-1-amd64

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2 (2017-01-04)

** Command line:
BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 root=/dev/mapper/theory--vg-theory--root ro 
quiet splash

** Not tainted

** Kernel log:
[   10.089155] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   10.089690] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   10.090060] iwlwifi :03:00.0 wlp3s0: renamed from wlan0
[   10.226610] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.226611] Bluetooth: BNEP filters: protocol multicast
[   10.226614] Bluetooth: BNEP socket layer initialized
[   10.550151] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[   10.566160] psmouse serio1: synaptics: queried max coordinates: x [..5676], 
y [..4758]
[   10.595881] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1096..]
[   10.653481] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 
0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x1, board id: 3053, fw id: 2560
[   10.653488] psmouse serio1: synaptics: serio: Synaptics pass-through port at 
isa0060/serio1/input0
[   10.690881] input: SynPS/2 Synaptics TouchPad as 
/devices/platform/i8042/serio1/input/input8
[   10.793849] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[   10.797434] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   10.799530] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   10.799784] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.013734] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.013995] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.035325] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   11.045690] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.045976] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.257971] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.258233] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   11.273130] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   11.281949] bridge: automatic filtering via arp/ip/ip6tables has been 
deprecated. Update your scripts to load br_netfilter if you need this.
[   11.299334] IPv6: ADDRCONF(NETDEV_UP): vmnat: link is not ready
[   11.355302] Ebtables v2.0 registered
[   11.436688] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   12.817758] thinkpad_acpi: docked into hotplug port replicator
[   13.693745] usb 4-5: new SuperSpeed USB device number 2 using xhci_hcd
[   13.719705] usb 4-5: New USB device found, idVendor=17ef, idProduct=1010
[   13.719710] usb 4-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   13.719713] usb 4-5: Product: 

Bug#823287: selinux-basics: System cannot boot with SELinux enabled after upgrade

2016-05-03 Thread Jonathan Yu
On Tue, May 3, 2016 at 10:10 AM, Laurent Bigonville 
wrote:
>
>
> Do you have a policy installed on your machine?
>

I do not - I was unable to install the latest selinux-policy-default
package from unstable due to dependency problems that I was unable to
resolve.

The following packages have unmet dependencies:
 selinux-policy-default : Depends: policycoreutils (>= 2.2.1) but it is not
going to be installed
 udev : Depends: libblkid1 (>= 2.19.1) but it is not going to be installed
Depends: adduser but it is not going to be installed
Depends: util-linux (>= 2.27.1)
Depends: procps


> The policy package currently in unstable is not compatible with the new
> userspace and needs to be adjusted, see bug #805492.
>

Ah, it does look like the same problem. However, I expected some sort of
safeguard that would prevent me from breaking my system -- i.e. a check in
selinux-activate that ensured that a policy was available, if that is
required to boot. Making my system unbootable is not desired behaviour.


> I've unfortunately not a lot of time for this. That means that if you want
> to use SELinux in debian, you'll have to compile/build your own policy.
>

I can understand that. I have some experience with Debian packaging, but
little with SELinux or advanced things like maintainer scripts, however I'd
be happy to spend a few weekends hacking on this if you can give me some
direction. I'll read through #805492 this weekend and come back to you with
questions.

Thanks again for all your contributions to Debian :)


Bug#823287: selinux-basics: System cannot boot with SELinux enabled after upgrade

2016-05-02 Thread Jonathan Yu
Package: selinux-basics
Version: 0.5.4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Thank you for your work bringing SELinux to Debian!

I regret that my knowledge of both SELinux and systemd is limited, so I do not
know what diagnostics to collect or how to collect it.  That said, I can
reproduce this problem at will, and I'm happy to collect whatever diagnostics
you need.

   * What led up to the situation?

I upgraded my system doing full-upgrade. My system is mainly 'testing' with
some packages coming from 'unstable' (I tried updating to the newer
selinux-utils in unstable, but to no avail).

Unfortunately there are not much diagnostics provided during boot, and I
could not find any trace of the failed boots in journalctl or in files
in /var/log, presumably because the problems occurred at such an early
stage of boot. I checked /var/log/syslog, but did not find much informative.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Removing the "selinux=1 security=selinux" flags from grub allowed me to boot.
I then used "selinux-activate disabled" to disable SELinux while we sort
these issues out.

I also tried running "selinux-activate disabled" and re-activating it again,
as it seems to do something with restorecond on first boot after activation.
Unfortunately this did not change anything :(

   * What outcome did you expect instead?

I expected that my system could continue booting. I've never had significant
issues with Debian upgrades (thanks to careful maintainers like you :) and
guess that there must be something strange about the way my system is
configured.

There was some interesting-looking output in /var/log/audit; here's a
section:

May  2 20:31:38 theory systemd[1]: Listening on CUPS Scheduler.
May  2 20:31:38 theory systemd[1]: Listening on D-Bus System Message Bus Socket.
May  2 20:31:38 theory systemd[1]: apt-daily.timer: Adding 7h 21min 31.345143s 
random time.
May  2 20:31:38 theory systemd[1]: Started Daily apt activities.
May  2 20:31:38 theory systemd[1]: Started Daily Cleanup of Temporary 
Directories.
May  2 20:31:38 theory systemd[1]: Reached target Timers.
May  2 20:31:38 theory systemd[1]: Started CUPS Scheduler.
May  2 20:31:38 theory systemd[1]: Reached target Paths.
May  2 20:31:38 theory systemd[1]: Listening on Virtual machine lock manager 
socket.
May  2 20:31:38 theory systemd[1]: Listening on mpd.socket.
May  2 20:31:38 theory systemd[1]: Listening on Virtual machine log manager 
socket.
May  2 20:31:38 theory systemd[1]: Reached target Sockets.
May  2 20:31:38 theory systemd[1]: Reached target Basic System.
May  2 20:31:38 theory systemd[1]: Started Run anacron jobs.
May  2 20:31:38 theory systemd[1]: Starting Accounts Service...
May  2 20:31:38 theory systemd[1]: Starting IIO Sensor Proxy service...
May  2 20:31:38 theory systemd[1]: Starting Restore /etc/resolv.conf if the 
system crashed before the ppp link was shut down...
May  2 20:31:38 theory systemd[1]: Starting Thermal Daemon Service...
May  2 20:31:38 theory systemd[1]: Starting Modem Manager...
May  2 20:31:38 theory systemd[1]: Started CUPS Scheduler.
May  2 20:31:38 theory systemd[1]: Started D-Bus System Message Bus.
May  2 20:31:38 theory ModemManager[1176]:   ModemManager (version 
1.4.14) starting in system bus...
May  2 20:31:38 theory dbus-daemon[1183]: Failed to start message bus: Failed 
to open "/etc/selinux/default/contexts/dbus_contexts": No such file or directory
May  2 20:31:38 theory systemd-udevd[823]: Process '/usr/sbin/alsactl -E 
HOME=/run/alsa restore 2' failed with exit code 99.
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.thermald': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.ModemManager1': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'net.hadess.SensorProxy': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.NetworkManager': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.login1': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to NameOwnerChanged 
signal for 'org.freedesktop.Accounts': Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to subscribe to activation signal: 
Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to register name: Connection timed out
May  2 20:31:38 theory systemd[1]: Failed to set up API bus: Connection timed 
out
May  2 20:31:38 theory systemd[1]: Starting Network Manager...
May  2 20:31:38 theory systemd[1]: Starting LSB: Start the GNUstep distributed 
object mapper...
May  2 20:31:38 theory systemd[1]: Started Regular background program 
processing 

Bug#747072: Better as a Go application?

2016-03-25 Thread Jonathan Yu
Keybase has a command-line client written in Go. Perhaps it would be
easier/better to package this one instead?

https://github.com/keybase/client


Bug#808707: findbugs: please move the GUI to a separate package

2015-12-21 Thread Jonathan Yu
I think there's another option: work with the upstream FindBugs maintainers
to make the UI dependencies optional (e.g. when attempting to start the UI,
display an error message indicating that a non-headless JRE should be
installed). This doesn't seem like a problem specific to Debian, or is it?
Are there JREs used in the wild that are headless? I don't know too much
about it, but I wonder whether the Compact Profiles might have similar
limitations.

Just a thought, since it could help avoid vendor-specific patches.

On Mon, Dec 21, 2015 at 5:58 PM, Gioele Barabucci  wrote:

> Package: findbugs
> Version: 2.0.3+repack-2
> Severity: wishlist
>
> Dear Maintainer,
>
> would it be possible to move the GUI of findbugs to a separate package?
>
> Right now findbugs is a dependency of gradle-debian-helper (via gradle
> -> libgradle-plugins-java). Because of the GUI, findbugs depends on
> default-jre instead of default-jre-headless.
>
> Depending on default-jre means that installing gradle-debian-helper
> brings in many X11 and desktop components, like dconf, glib (and
> plugins), libasound2, gtk (both version 2 and 3), cairo, libx11,
> libwayland. In the end, installing the gradle-debian-helper requires
> installing about 400 MB of software.
>
> If the findbugs package contained only the command line version, it could
> depend on just default-jre-headless and avoid this long chain of
> dependencies.
>
> Regards,
>
> --
> Gioele Barabucci 
>
>


-- 
Cheers,

Jonathan


Bug#781918: RFP: docker-swarm -- Docker-native clustering system

2015-04-04 Thread Jonathan Yu
Package: wnpp
Severity: wishlist

* Package name : docker-swarm
  Version : 0.2.0-rc2 (for experimental)
  Upstream Author : Victor Vieux vi...@docker.com  Andrea Luzzardi
  Copyright holder: Docker, Inc.
* URL : https://docs.docker.com/swarm/ https://github.com/docker/swarm
* License : Apache 2.0 (documentation under Creative Commons - unsure of full 
terms)
  Programming Lang: Go
  Description : Docker-native clustering system

Docker Swarm is native clustering for Docker. It turns a pool of Docker
hosts into a single, virtual host.

Swarm serves the standard Docker API, so any tool which already communicates
with a Docker daemon can use Swarm to transparently scale to multiple hosts:
Dokku, Compose, Krane, Flynn, Deis, DockerUI, Shipyard, Drone, Jenkins...
and, of course, the Docker client itself.

Like other Docker projects, Swarm follows the batteries included but
removable principle. It ships with a set of simple scheduling backends out
of the box, and as initial development settles, an API will be developed to
enable pluggable backends. The goal is to provide a smooth out-of-the-box
experience for simple use cases, and allow swapping in more powerful backends,
like Mesos, for large scale production deployments.

More about Docker Swarm:

   The goal of Docker Swarm is to enable easier management of several Docker
   systems -- many people looking to use docker (see docker.io package) in
   production would benefit from this. At the moment, the proposed installation
   instructions are to run Swarm as a Docker image, but this requires running
   potentially untrusted code obtained over the Internet.

   It is not a dependency for any other package. There are many competing
   technologies but this is the most popular open source one, since it is
   part of the Docker ecosystem itself.

   I do not use it, yet, however many others do (or are looking to trial it).

Proposed maintainers for this package:

   The Debian Golang team seems like an appropriate place to host this work.
   As this is an RFP and not an ITP, I hope they are willing to maintain it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#770244: ITP: caliper -- framework for writing, running and viewing Java microbenchmarks

2014-11-23 Thread Jonathan Yu
Hey Tim,

On Sun, Nov 23, 2014 at 8:21 PM, Potter, Tim (Cloud Services) 
timothy.pot...@hp.com wrote:

 Hi Jonathan.  I have to admit not having that much experience with Java
 benchmarking frameworks so I will defer to you on the matter of the
 suitability of different libraries.


I'm not an expert either, having not used either JMH or Caliper, I'm just
an interested party :-)


 I’m in the process of trying to package the Dropwizard Metrics library (
 https://github.com/dropwizard/metrics) which is actually a dependency for
 Dropwizard itself, and Caliper is a dependency for the metrics library.  I
 agree that it would be nice to avoid duplicating functionality in the
 Debian archive but in this case I don’t think there is a way around it
 right now.


Fair enough, if it's required as a dependency then there's no way around
things. I suppose the choice of Caliper vs JMH might be useful to raise
with upstream, but as Debian package maintainers, there's not much we can
(or should) do :-)

Warm wishes,

Jonathan


Bug#770244: ITP: caliper -- framework for writing, running and viewing Java microbenchmarks

2014-11-22 Thread Jonathan Yu
Hi Tim,

Is the Java Microbenchmark Harness (JMH) already available in Debian? If
so, why do we need Caliper?

The general consensus (OK, admittedly it's a small sample size) seems to be
that JMH is better:
https://groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/7lY8x8SvHgwJ
- it's reasonably easy to use and seems more likely to be correct than
Caliper. This is all pretty anecdotal but a product could do worse than
having an endorsement from Java performance expert Martin Thompson.

If you have existing tests or a project depends on Caliper, then those are
certainly valid reasons to package it. But if you're writing new tests and
this is for personal use, then I'd suggest considering JMH instead.

Cheers,

Jonathan

On Mon, Nov 17, 2014 at 2:19 PM, Tim Potter t...@hp.com wrote:

 Package: wnpp
 Severity: wishlist
 Owner: Tim Potter t...@hp.com

 * Package name: caliper
   Version : 1.0-beta-1
   Upstream Author : Gregory Kick g...@google.com
 * URL : http://code.google.com/p/caliper/
 * License : Apache-2.0
   Programming Lang: Java
   Description : framework for writing, running and viewing Java
 microbenchmarks

 Caliper is an entire toolchain for making performance-related
 decisions about Java code that work in concert to help users get
 complete and accurate information about performance while minimizing
 the opportunities for misinformation.

 The primary focus of Caliper is microbenchmarks, but it can support
 arbitrary kinds of measurements including memory allocated, memory
 consumed, or arbitrary domain-specific measurements like compression
 ratio.

 Above all, Caliper aims to be as simple as possible while providing
 more unambiguous, consistent and comprehensive data than equivalent
 benchmarks written without it.


 --
 To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/20141117191942.8.12737.reportbug@02ed91797728


On Mon, Nov 17, 2014 at 2:19 PM, Tim Potter t...@hp.com wrote:

 Package: wnpp
 Severity: wishlist
 Owner: Tim Potter t...@hp.com

 * Package name: caliper
   Version : 1.0-beta-1
   Upstream Author : Gregory Kick g...@google.com
 * URL : http://code.google.com/p/caliper/
 * License : Apache-2.0
   Programming Lang: Java
   Description : framework for writing, running and viewing Java
 microbenchmarks

 Caliper is an entire toolchain for making performance-related
 decisions about Java code that work in concert to help users get
 complete and accurate information about performance while minimizing
 the opportunities for misinformation.

 The primary focus of Caliper is microbenchmarks, but it can support
 arbitrary kinds of measurements including memory allocated, memory
 consumed, or arbitrary domain-specific measurements like compression
 ratio.

 Above all, Caliper aims to be as simple as possible while providing
 more unambiguous, consistent and comprehensive data than equivalent
 benchmarks written without it.


 --
 To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/20141117191942.8.12737.reportbug@02ed91797728




Bug#742864: ITP: openjdk-8 -- OpenJDK 8 - Open source implementation of the Java Platform Standard Edition 8

2014-06-02 Thread Jonathan Yu
Emmanuel,

Disclaimer: I haven't done any work on Debian Java, so my opinion isn't
here isn't worth anything. :-)

If I understand correctly, the difference between the profiles is simply
the number of Java packages available at runtime [0].

Whether the compact1 profile is worth packaging despite only a 6-7%
improvement in startup times depends on whether performance improvement is
the only benefit we think is worthwhile with these profiles.

Here's my take:

1. If you only need features from the compact1 profile, then you only need
to install this profile

2. If there is an exploitable vulnerability in some other code (e.g.
JavaEE), but you do not have any software installed that needs it, then the
existence of this compact1 profile means that your system is not vulnerable
to the problem. If on the other hand, you are forced to install the full
profile, then you could be vulnerable (e.g. forcing some class to be loaded
via Reflection and exploiting it).

But:

* I suppose this is just theoretical; and
* I'm by no means a security expert; and
* There are also costs to packaging/maintaining the profile

So ultimately, a decision will have to be made with these considerations in
mind.

Jonathan

[0] https://blogs.oracle.com/jtc/entry/a_first_look_at_compact

On Mon, Jun 2, 2014 at 5:51 PM, Emmanuel Bourg ebo...@apache.org wrote:

 After further investigation the error I encountered was caused by GNU
 Make 4.0. Erik Joelsson from Oracle kindly provided a patch [1] and I've
 been able to build the compact JREs.

 I did a quick test with headless applications to see the difference in
 startup time between the full JRE and the compact1 profile. I measured
 the time to run 'mvn -version' and 'ant -version' 100 times. The compact
 JRE was faster by 6-7% only. With clirr the compact JRE was ~13% faster.

 With an average startup time of ~100ms the difference was hardly
 noticeable. Now I wonder if packaging the compact JREs is really worth
 the trouble.

 Emmanuel Bourg

 [1] http://mail.openjdk.java.net/pipermail/build-dev/2014-June/012715.html


 --
 To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/538cf1fd.9060...@apache.org




Bug#748583: ITP: get directories of configuration files -- get directories of configuration files

2014-05-18 Thread Jonathan Yu
Jonas,

I assume there was a typo in the package name. Shouldn't it be
libfile-configdir-perl?

Cheers,

Jonathan

This message was sent from my mobile device. Please forgive my
typographical errors and brevity.
On May 18, 2014 12:33 PM, Jonas Smedegaard d...@jones.dk wrote:

 Package: wnpp
 Severity: wishlist
 Owner: Jonas Smedegaard d...@jones.dk

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 * Package name: get directories of configuration files
   Version : 0.013
   Upstream Author : Jens Rehsack rehs...@cpan.org
 * URL : https://metacpan.org/release/File-ConfigDir
 * License : Artistic or GPL-1+
   Programming Lang: Perl
   Description : get directories of configuration files

  File::ConfigDir is a helper for installing, reading and finding
  configuration file locations. It's intended to work in every supported
  Perl5 environment and will always try to Do The Right Thing(tm).

 This module is needed (indirectly) by recent releases of
 libmoox-options-perl.

 It will be maintained in the Debian Perl team.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQF8BAEBCgBmBQJTeN/zXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWGm0H/jfTRYDwEeFKLBok7azMQVL/
 9JtPSMHV5Brtbu0zHrdvmBIp+BhAIh7IrDQ3hxAwjLbOsxVcBsVfI1L1ejxhZWYo
 AolQGuv5sI8Ff2CbDa7Fkv1aC1sitVsgXL956kL/+XI5bb6xxzLZDFgGhDbso7ci
 xqJy53X2UW/T5xV1n/+d8+pZWq7AWtVAUtTtydPzToyZuEq6p1ES5P56ROSbCfl2
 NLZIBt8SsulbUwm58w8e/hepgf+9W7EOsGCUgzJ3XHxfM9egzEwO76q4vF+R9atr
 jkRbRExOMy2HEW3axcbVDbmyo2B84zGzaIkTxk0GdBEGS1JGrncSXvOM7ddRCso=
 =e6E2
 -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/20140518162939.29411.28327.report...@bastian.jones.dk




Bug#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)

2014-01-19 Thread Jonathan Yu
Hey Scott,

I don't presume to be an expert here, but I wanted to mention that the
package name specified in your ITP does not match the usual
conventions for libraries in Debian, nor for Java libraries
specifically:

Java libraries packages must be named libXXX[version]-java (without
the brackets) [0]

Might you consider renaming this package to make it more easily discoverable?

Cheers,

Jonathan

[0] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html

On Sun, Jan 19, 2014 at 5:33 PM, Scott Howard show...@debian.org wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Scott Howard show...@debian.org

 * Package name: sbbi-upnplib
   Version : 1.0.4
   Upstream Author : SuperBonBon Industries
 * URL :  http://sourceforge.net/p/triplea/code/HEAD/tree/upnp/
 * License :  Apache-1.1
   Programming Lang: Java
   Description : Java library for universal plug and play (upnp)

 This is a dependency of the newest versions of the triplea package. To be
 maintained under the java team umbrella.
 Initial repo:
 http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git


 --
 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/20140119223359.15198.7602.report...@esc-303123.ee.nd.edu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)

2014-01-19 Thread Jonathan Yu
Hey Scott,

It has been said that There are only two hard things in Computer
Science: cache invalidation and naming things. -- Phil Karlton :-)

The binary package was of the most concern to me, because that's what
users will look for when installing. I actually have no experience
with Java packaging, so I'm not sure what the conventions are there.
Personally, my preference would be for source + binary packages to be
the same name.

I used to work on packaging Perl libraries mainly, and in that case,
our convention was generally to stick with the lib*-perl pattern, for
both source and binary packages. Initially, we also did this for
applications (e.g. libcpanminus-perl), but later decided to go with
just application names (i.e. cpanminus) in cases where the application
is meant to be used standalone and not as a library. We codified these
conventions in the policy for the Debian Perl Group [0]. Whether
something is more appropriately a library or application requires some
discretion on the part of the packaging Debian contributor/developer,
of course. And I'm not sure what to name the source package in a case
where there is both a library and application component. I guess the
analogue with Perl modules is also different because upstream Perl
package names (Module::Name) are not valid Debian package names
anyway, so they have to be transmogrified to fit our convention, and
lib*-perl seems as fine a convention as any.

Does apt-get source expect the source package name, or will it also
work with binary package names? If I do apt-get source libupnp-java,
will it download the sbbi-upnplib package? If so, then this seems to
be an especially trivial point, and I'd be happy with either name. In
any case, since I'm not an expert here, let's see if someone on the
debian-java list chimes in :-)

Cheers,

Jonathan

[0] http://pkg-perl.alioth.debian.org/policy.html#package_naming_policy

On Sun, Jan 19, 2014 at 9:43 PM, Scott Howard showard...@gmail.com wrote:
 Hi all,
 The binary package is named libupnp-java, seen here:
 http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git;a=blob;f=debian/control;h=8014fb5b4d2c3eb60968caaa6c239562002dd9f7;hb=HEAD

 I named the source package to match the name of the upstream tarball
 file (sbbi-upnplib-1.0.4.tar.gz) I struggled with either naming the
 source package the same as the binary package, or to name it like I
 suggest here. Since upstream refers to the project as sbbi-upnplib and
 their tarball had that in it, I'm leaning toward keeping the name what
 they call it. It will be discoverable since the binary package has the
 proper java library package name. I was worried about it not being
 discoverable if I didn't put the sbbi-upnplib source package name.

 Given that, do you still think it should be renamed? I don't mind either way.

 ~Scott

 On Sun, Jan 19, 2014 at 8:50 PM, Jonathan Yu jaw...@cpan.org wrote:
 Hey Scott,

 I don't presume to be an expert here, but I wanted to mention that the
 package name specified in your ITP does not match the usual
 conventions for libraries in Debian, nor for Java libraries
 specifically:

 Java libraries packages must be named libXXX[version]-java (without
 the brackets) [0]

 Might you consider renaming this package to make it more easily discoverable?

 Cheers,

 Jonathan

 [0] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html

 On Sun, Jan 19, 2014 at 5:33 PM, Scott Howard show...@debian.org wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Scott Howard show...@debian.org

 * Package name: sbbi-upnplib
   Version : 1.0.4
   Upstream Author : SuperBonBon Industries
 * URL :  http://sourceforge.net/p/triplea/code/HEAD/tree/upnp/
 * License :  Apache-1.1
   Programming Lang: Java
   Description : Java library for universal plug and play (upnp)

 This is a dependency of the newest versions of the triplea package. To be
 maintained under the java team umbrella.
 Initial repo:
 http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git


 --
 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/20140119223359.15198.7602.report...@esc-303123.ee.nd.edu



 --
 To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/camdxsejlkidda__v6lfzbe+iaf0j5yocl6uoaongoq0rr3z...@mail.gmail.com



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#720536: ITP: libmango-perl -- Pure-Perl non-blocking I/O MongoDB client

2013-08-24 Thread Jonathan Yu
Hi cstamas,

Given the scary note: Note that this whole distribution is EXPERIMENTAL
and will change without warning!​

Might I suggest either: uploading this package only to experimental, not to
sid; or to sid, but adding an RC bug so that this package does not get
migrated to testing/stable?

My apologies if this was already part of your plan. I know the warning is
pretty obvious, but I think it would be useful to prevent users from
ignoring the docs and relying on the current API as-is.

Thanks for your contributions to Debian :-)

Cheers,

Jonathan


Bug#707528: libvideo-fourcc-info-perl: FTBFS: gpg: fatal: can't create directory `/sbuild-nonexistent/.gnupg': No such file or directory

2013-05-13 Thread Jonathan Yu
These errors are very strange indeed. I would suggest either disabling the
tests or removing this package (I have no strong feeling either way). I
could do the same in the upstream version (or pass co-maintainership to
someone else), but I guess it would be good to know what caused this
breakage in the first place...


Bug#676164: UUID-0.04 marked UNAUTHORIZED RELEASE on CPAN

2012-06-17 Thread Jonathan Yu
Hi Florian,

(Cc'ing debian-perl list - hopefully some of the current active members can
chime in)

I spent a few spare cycles to do a quick investigation. The good news is
that it looks like your instincts were correct. However, in summary, I
would suggest a removal of the UUID module from Debian if possible. The
full diff between UUID-0.02/UUID-0.04 is small, so it is pasted at the
bottom of this message.

1. I checked on PAUSE and the current permissions set for UUID do not
mention either of the names that have been added to UUID 0.04 from UUID
0.02:

*module**userid**fullname**type**owner*UUIDhttps://pause.perl.org/pause/authenquery?pause99_peek_perms_by=mepause99_peek_perms_query=UUIDpause99_peek_perms_sub=1
BRAAMhttps://pause.perl.org/pause/authenquery?pause99_peek_perms_by=apause99_peek_perms_query=BRAAMpause99_peek_perms_sub=1
Peter
J. Braam first-come LZAP
UUIDhttps://pause.perl.org/pause/authenquery?pause99_peek_perms_by=mepause99_peek_perms_query=UUIDpause99_peek_perms_sub=1
LZAPhttps://pause.perl.org/pause/authenquery?pause99_peek_perms_by=apause99_peek_perms_query=LZAPpause99_peek_perms_sub=1
Lukáš
Zapletal modulelist LZAP
2. No license or copyright information exists in UUID 0.02:

From UUID-0.02/:
$ grep -ir copyright .
$ grep -ir license .

(both blank)

So it is questionable whether we are actually allowed to distribute this in
Debian or not, unless I've missed something...

3. Last upload of the UUID module (version 0.02) was in 2001; the packaging
style seems to be of quite an old vintage. There are serious outstanding
bugs on the RT (not installable on CentOS) that do not have replies from
the package maintainer. This means that Debian is effectively the
maintainer (there is no upstream), which would certainly put greater load
on the pkg-perl team than desired.

4. The removal won't be easy since the reverse depends are doc-base and
linux-base (though perhaps they can be retooled to use a different Perl
UUID library without too much effort):

$ apt-cache rdepends libuuid-perl
libuuid-perl
Reverse Depends:
  linux-base
  doc-base

5. The UUID 0.04 doesn't add much over UUID 0.02 - it seems the only
notable change is the addition of licensing information which isn't
actually legal (since the authors that added that license do not appear to
be copyright holders).

Diff between the UUID 0.02 and UUID 0.04 versions:

diff '--unified=3' UUID-0.02/Changes UUID-0.04/Changes
--- UUID-0.02/Changes   2001-02-08 09:07:59.0 -0500
+++ UUID-0.04/Changes   2009-07-22 23:18:11.0 -0400
@@ -1,5 +1,16 @@
 Revision history for Perl extension UUID.

+0.04 Wed Jul 22 20:17:26 PDT 2009
+  - Seems to be abandoned (again)
+  - Bump version number and upload to PAUSE
+
+0.03  Fri Jan 12 15:24:24 MST 2007
+  - Added Artistic license
+  - Took over maintaining (Colin Faber - CFABER)
+
+0.02  Unknown
+   - unknown changes
+
 0.01  Thu Feb  8 06:07:59 2001
- original version; created by h2xs 1.20 with options
-A -n UUID
Only in UUID-0.04: License
diff '--unified=3' UUID-0.02/MANIFEST UUID-0.04/MANIFEST
--- UUID-0.02/MANIFEST  2001-02-08 09:07:59.0 -0500
+++ UUID-0.04/MANIFEST  2007-01-12 17:29:53.0 -0500
@@ -1,6 +1,8 @@
 Changes
+License
 MANIFEST
 Makefile.PL
 UUID.pm
 UUID.xs
 test.pl
+META.yml Module meta-data (added by
MakeMaker)
Only in UUID-0.04: META.yml
diff '--unified=3' UUID-0.02/UUID.pm UUID-0.04/UUID.pm
--- UUID-0.02/UUID.pm   2001-03-01 11:25:57.0 -0500
+++ UUID-0.04/UUID.pm   2009-07-22 23:16:39.0 -0400
@@ -18,7 +18,7 @@

 @EXPORT_OK = ( @{$EXPORT_TAGS{'all'}} );

-$VERSION = '0.02';
+$VERSION = '0.04';

 bootstrap UUID $VERSION;

@@ -46,8 +46,16 @@

 UUID::{generate, parse, unparse}

+=head1 LICENSE
+
+This library is licensed under the Perl Artistic License. Details of this
license can be found within the 'License' text file
+
 =head1 AUTHOR

+Joseph N. Hall joseph.nathan.h...@gmail.com
+
+Colin Faber cfa...@clusterfs.com
+
 Peter J. Braam br...@mountainviewdata.com

 =head1 SEE ALSO

On Fri, Jun 15, 2012 at 8:54 AM, Florian Schlichting 
fschl...@zedat.fu-berlin.de wrote:

 Hi Jonathan,

  What stops you from downloading directly instead of using uscan?

 the fact that it's a big red ** UNAUTHORIZED RELEASE ** warning, and I
 am in no position to judge whether that's a false alarm and it is in
 fact a perfectly authorized release or not (I note the two authors are
 not the same, so this may well be a hostile takeover that I wouldn't
 want to get involved in). I've been emailing cpan authors about this
 before, and they have been able to fix it within a day or so.

 This shouldn't stop you from taking the initiative and uploading a new
 version, if you happen to know more and/or feel comfortable making such
 a decision :-)

 Florian




Bug#676164: UUID-0.04 marked UNAUTHORIZED RELEASE on CPAN

2012-06-13 Thread Jonathan Yu
Florian,

What stops you from downloading directly instead of using uscan?

The permission issue is a CPAN/PAUSE problem that has affected many
modules, including e.g. Algorithm::Diff::XS. But we do have the correct
versions in Debian, since the maintainer can download even unauthorized
versions and upload them in the appropriate lib*-perl package at his/her
discretion.

Cheers,

Jonathan

On Mon, Jun 11, 2012 at 9:44 AM, Florian Schlichting 
fschl...@zedat.fu-berlin.de wrote:

 Hi Joseph,

 your CPAN release 0.04 of UUID is marked ** UNAUTHORIZED RELEASE ** in
 bold
 red, and the latest version that comes up under the distribution
 permalink (http://search.cpan.org/dist/UUID/) is still UUID-0.02.

 Is it possible for you to do something about that? This is likely a
 permissions issue on PAUSE (which I know very little about how to fix),
 but without it being indexed properly on CPAN, it won't show up on
 downstream watchlists and e.g. not make it into the next Debian stable
 release.

 Florian



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org

 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-perl-maintainers



Bug#661578: libalgorithm-diff-perl: debian/copyright::Source incorrect URL

2012-02-28 Thread Jonathan Yu
On Tue, Feb 28, 2012 at 1:54 AM, Jari Aalto jari.aa...@cante.net wrote:

 Package: libalgorithm-diff-perl
 Version: 1.19.02-2
 Severity: minor

 debian/copyright points to old Ned Konz's version 1.15:

Source: http://search.cpan.org/dist/Algorithm-Diff/


This should always point to the latest one installed via the CPAN shell
(e.g. when doing 'cpan install Algorithm::Diff).


 The one packaged in Debian is by Tye McQueen and the correct URL is:

http://search.cpan.org/~tyemq/


We have (apparently) decided to use Tye McQueen's version, which is
apparently tagged as an UNAUTHORIZED RELEASE. This is a PAUSE issue - the
upload permissions need to be transferred to Tye McQueen from Ned Konz and
reindexed. (Correction: I just checked the permissions, TYEMQ has upload
permissions, but the releases are still tagged UNAUTHORIZED. I will ask the
PAUSE admins to reindex the distribution).

Thank you for your bug report.

Cheers,

Jonathan


Bug#636133: Replace libgtk2-mozembed-perl with libgtk2-webkit-perl?

2012-02-03 Thread Jonathan Yu
Hi all,

In August 2011, gregor mentioned that we could attempt to replace
libgtk2-mozembed-perl (which is currently FTBFS) with libgtk2-webkit-perl,
which was never uploaded (since being packaged in 2009). I am wondering if
there are comments as to whether we could solve BTS#636133 by replacing
libgtk2-mozembed-perl with libgtk2-webkit-perl (there is only one reverse
dependency of libgtk2-mozembed-perl, and it looks like it could use
libgtk2-webkit-perl instead).

Should we pursue this avenue, or does anyone know of a reason we shouldn't
bother?

I have not yet attempted to build libgtk2-webkit-perl nor test it against
the mentioned reverse dependency, gmusicbrowser. But it looks like we have
little choice but to remove libgtk2-mozembed-perl, as it is obsoleted by
upstream (per Chris Butler's comment).

Cheers,

Jonathan

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636133


Bug#655710: libdevel-ebug-perl: Failing tests t/finished.t

2012-02-03 Thread Jonathan Yu
I've been investigating this today, and it appears that the debugger is now
faulty (I am still not sure whether it is related to the bug report filed
regarding the changes in YAML).

Running the yaml.pl script manually (turning on warnings for good measure),
we get the following output:

 perl -w yaml.pl
---
'/foo/foo- hate': bz
---
'/foo/foo- hate': bz

If we comment out this (the fourth) line in yaml.pl

#print YAML::Dump (YAML::Load (YAML::Dump ($hash)));

we get only one output:

---
'/foo/foo- hate': bz

So, obviously all four lines are being correctly executed when running
yaml.pl directly.

If we un-comment that line (return it back to its original state) and run
the test by executing the debugger manually:

(sid)root@aven:/tmp/libdevel-ebug-perl# perl bin/ebug --backend perl
bin/ebug_backend_perl t/yaml.pl
* Welcome to Devel::ebug 0.52
main(t/yaml.pl#3):
my $hash = { '/foo/foo- hate' = 'bz' };
ebug: n
main(t/yaml.pl#4):
print YAML::Dump ($hash);
ebug: n
ebug: Program finished. Enter 'restart' or 'q'

The program finishes and the debugger does not show that it has executed
the last line in yaml.pl. Thus, the test fails - since we expected another
line to be executed (the YAML Dump/Load/Dump operation).

It is difficult to isolate the cause of this, though that B::Deparse bug
seems promising. I have not done enough spelunking into the internals of
Devel::ebug to say.

Of course, perl's built-in debugger does not seem to suffer from this
problem:

 perl -d -w t/yaml.pl

Loading DB routines from perl5db.pl version 1.33
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(t/yaml.pl:3):my $hash = { '/foo/foo- hate' = 'bz' };
  DB1 n
main::(t/yaml.pl:4):print YAML::Dump ($hash);
  DB1 n
---
'/foo/foo- hate': bz
main::(t/yaml.pl:5):print YAML::Dump (YAML::Load (YAML::Dump ($hash)));
  DB1 n
---
'/foo/foo- hate': bz
Debugged program terminated.  Use q to quit or R to restart,
  use o inhibit_exit to avoid stopping after program termination,
  h q, h R or h o to get additional info.
  DB1

I don't believe anything there has changed, so I am not sure why
Devel::ebug is broken.

Cheers,

Jonathan


Bug#634607: Add Affero GPL license to /usr/share/common-licenses

2011-12-28 Thread Jonathan Yu
Hi Mike,

On Wed, Dec 28, 2011 at 7:47 AM, Mike Gabriel 
mike.gabr...@das-netzwerkteam.de wrote:

 I would love Debian to support this by setting a little signal which could
 be adding the license to common-licenses.


To be fair, I don't think that inclusion in common-licenses is what you
think it is. Russ can correct me if I'm mistaken here, but my impression is
that common-licenses is around for a technical purpose: to conserve on disk
space where many packages share a common license (rather than installing
thousands of copies of a given file) as well as save some disk space on
mirrors (as individual packages using those common licenses do not need to
include the license text, and may simply refer to the file in common l
icenses).

Inclusion in common-licenses does not send a signal that Debian endorses
nor condemns a given license, only that there are many (the threshold of
many in this case is 1000+) packages use the given license. Similar things
can be accomplished by doing an analysis of debian/copyright files for
packages in the repository (e.g. figure out the most common licenses in the
Debian main repository), which would provide more valuable insight as to
the proliferation of licenses in Debian.

I think the problem comes down to this:

1. If a license is included in base-files (in common-licenses), then that
file is included with every Debian system. This unfortunately also includes
other platforms, where it may waste disk space (e.g. mobile devices).

2. If a license is added to base-files, it cannot be removed. This is
because, if packages refer to the license file in common-licenses, that
file cannot be removed until the packages are all corrected to install the
license file itself.

So the 1000+ package requirement is needed to prevent
base-files/common-licenses from becoming very large and thus wasting lots
of space on constrained systems.

The AGPL is considered Free according to the DFSG [0], [1] - which is about
as much of an endorsement from Debian as you can get, or should get. Debian
is a nonpartisan organization as a whole, and as long as software is
DFSG-compatible, it is welcomed by Debian.

The inclusion of BSD or GPL in common-licenses does not mean the Debian
project as a whole endorses those licenses, though it would be necessary
that they are considered DFSG-free (otherwise they would not meet the 1000+
package requirement in the main repository). That being said, there are
many Debian Developers who are for or against BSD or the GPL for various
reasons (the Permissive vs Copyleft war has been going on for ages). It is
by no means an endorsement for either of those licenses. Heck, the Artistic
License is discouraged even by the Perl Foundation due to those
aforementioned enforceability concerns, but it is part of common-licenses
because of the sheer number of packages that reference it. It doesn't mean
people should use it for their own software :-)

Hopefully I'm not completely off-base here. Russ is in a much better
position to answer these questions than I am, but having dealt with these
issues in the past (for Artistic License 2.0) and having shared in your
frustration that a license is not included in common-licenses, I hope that
I understand the situation clearly enough now.

Warm wishes,

Jonathan

[0] http://www.debian.org/social_contract#guidelines

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;bug=495721 (Credit
to Wikipedia for this reference, as the Wiki at
http://wiki.debian.org/DFSGLicenses does not mention the AGPL at all)


Bug#634607: Add Affero GPL license to /usr/share/common-licenses

2011-12-27 Thread Jonathan Yu
Hi,

On Tue, Dec 27, 2011 at 10:05 AM, Mike Gabriel 
mike.gabr...@das-netzwerkteam.de wrote:

However, I would love Debian to give a signal on A-GPL as for many
 server-side projects (CMS, Groupware, etc.) A-GPL from my perspective
 definitely is the license to be preferred. However, this is mostly opinion
 and surely people can see that differently.


What sort of signal are you looking for?

We had the same request/issue with the Artistic License version 2.0 some
months (years?) ago. Lots of new software (Perl 6 stuff specifically) uses
it, and adoption is on the rise due to the clearer wording. It was
clarified because of speculation that Artistic License 1.0 is not
enforceable. Anyway, AL2 falls below the given threshold as well.

However, that is not to say that Debian main does not have plenty of AL2
packages. Just less than 1000 :-)

A license being in common-licenses is no indication as to whether it is
preferred or not (after all GPL-1.0 is in there, and I hope that's not the
*preferred* choice nowadays in light of the two subsequent versions). It's
just convenient to save disk when there is a reasonably high probability
that a user's system is going to install software licensed under those
terms.

I would personally argue that not much disk space is used from inclusion to
common-licenses (and that the used space is quickly recovered due to
reduced duplication), though those wiser than me have reminded me that
there are people who use Debian on platforms other than PCs that have
essentially unlimited amounts of storage capacity, such as mobile devices
in particular.

Cheers,

Jonathan


Bug#636133: libgtk2-mozembed-perl: FTBFS: gdkconfig.h: No such file or directory

2011-07-31 Thread Jonathan Yu
Hi,

I have successfully reproduced this issue in a sid chroot, and
subsequently confirmed that this issue (the immediate issue, but not
the FTBFS) can be fixed by rebuilding libgtk2-perl:

[ XS xs/GtkMozEmbed.xs ]
[ CC xs/GtkMozEmbed.c ]
In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
 from /usr/include/gtk-2.0/gdk/gdk.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:32,
 from /usr/lib/perl5/Gtk2/Install/gtk2perl.h:29,
 from ./gtkmozembed2perl.h:28,
 from xs/GtkMozEmbed.xs:21:
/usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h:
No such file or directory
compilation terminated.
make[1]: *** [xs/GtkMozEmbed.o] Error 1
make[1]: Leaving directory `/root/libgtk2-mozembed-perl'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

After rebuilding and installing the rebuilt version:

(Reading database ... 26678 files and directories currently installed.)
Preparing to replace libgtk2-perl 2:1.223-1+b1 (using
.../libgtk2-perl_1.223-2_i386.deb) ...
Unpacking replacement libgtk2-perl ...
Setting up libgtk2-perl (2:1.223-2) ...

(this version came out of the pkg-perl git)

[ XS xs/GtkMozEmbed.xs ]
[ CC xs/GtkMozEmbed.c ]
In file included from xs/GtkMozEmbed.xs:21:0:
./gtkmozembed2perl.h:34:25: fatal error: gtkmozembed.h: No such file
or directory
compilation terminated.
make[1]: *** [xs/GtkMozEmbed.o] Error 1
make[1]: Leaving directory `/root/libgtk2-mozembed-perl'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

It looks like the gtkmozembed.h file is no longer available anywhere.
There are a few results from apt-file, but the newest version of
xulrunner (now in sid) is xulrunner-5.0, which does not seem to
provide this file.

apt-file says:

icedove-dev: /usr/include/icedove/gtkmozembed.h
kompozer-dev: /usr/include/kompozer/gtkembedmoz/gtkmozembed.h
xulrunner-dev: /usr/include/xulrunner-1.9.1/unstable/gtkmozembed.h

I think that this package will only be able to build if you restrict
it to build with the previous version of xulrunner...

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#635668: libdbd-odbc-perl: package may be built with incorrect pointer size on 64-bit systems

2011-07-27 Thread Jonathan Yu
Package: libdbd-odbc-perl
Severity: grave
Tags: security
Justification: user security hole


Because of changes that Microsoft made to the ODBC specification, the previously
32-bit binary protocol now supports 64-bit values on systems that support it 
(e.g.
on amd64 and possibly the ia64 architectures).

During build time, DBD::ODBC probes for a utility called odbc_config, which, 
like
pkg-config, is intended to provide developers with the compiler flags used to 
build
unixODBC itself. However, because this is not included with Debian's unixODBC 
(it
is not installed into any of the unixodbc binary packages), it is not possible 
to
tell whether the package should be compiled assuming 32-bit or 64-bit data 
types.

When the odbc_config cannot be found (since it is not available in Debian), the
macro SIZEOF_LONG is not defined, so DBD::ODBC assumes that unixODBC was built
with 32-bit-long SQLLEN and SQLULEN.

This raises a potential security issue because unixODBC could write 64-bit 
values
into buffers that are only 32-bits large (DBD::ODBC having provided 32-bit-long
buffers based on the assumption of SQLLEN and SQLULEN being 32-bits).

This issue is explained at length on the blog of the DBD::ODBC upstream 
developer:
http://www.martin-evans.me.uk/node/116

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#635077: RM: sqlfairy -- ROM; Package replaced by libsql-translator-perl (currently not installable)

2011-07-22 Thread Jonathan Yu
Package: ftp.debian.org
Severity: normal


This source package has been replaced by libsql-translator-perl. For some 
reason, I didn't submit a removal request when we renamed the source package 
(sorry about that).

This is related to bug #635051



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#634397: libjavascript-perl: FTBFS: jslock.h:221:1: error: unknown type name 'namespace'

2011-07-18 Thread Jonathan Yu
I am able to reproduce this issue on my sid chroot. From a quick
glance at the error messages, it looks like the header files include
C++ code (namespace, new), which is unexpected when trying to link
with it in C-land...

Cheers,

Jonathan

On Mon, Jul 18, 2011 at 6:02 PM, Lucas Nussbaum
lu...@lucas-nussbaum.net wrote:
 Source: libjavascript-perl
 Version: 1.16-3
 Severity: serious
 Tags: wheezy sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20110718 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part:
 cc -c  -I/usr/include/nspr/ -I/usr/include/mozjs/ -D_REENTRANT -D_GNU_SOURCE 
 -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include 
 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -DMOZILLA_1_8_BRANCH=1   
 -DVERSION=\1.16\ -DXS_VERSION=\1.16\ -fPIC -I/usr/lib/perl/5.12/CORE   
 JavaScript.c
 In file included from /usr/include/mozjs/jsapi.h:48:0,
                  from JavaScript_Env.h:12,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/js-config.h:50:0: warning: JS_THREADSAFE redefined 
 [enabled by default]
 JavaScript_Env.h:8:0: note: this is the location of the previous definition
 In file included from /usr/include/mozjs/jsobj.h:56:0,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jslock.h:221:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jslock.h:221:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jsobj.h:57:0,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jsvalue.h: In function 'JSDOUBLE_IS_INT32':
 /usr/include/mozjs/jsvalue.h:111:16: error: 'false' undeclared (first use in 
 this function)
 /usr/include/mozjs/jsvalue.h:111:16: note: each undeclared identifier is 
 reported only once for each function it appears in
 /usr/include/mozjs/jsvalue.h:112:24: error: expected expression before 
 'int32_t'
 /usr/include/mozjs/jsvalue.h: At top level:
 /usr/include/mozjs/jsvalue.h:241:1: error: conflicting types for 
 'MAGIC_TO_JSVAL_IMPL'
 /usr/include/mozjs/jsvalue.h:233:1: note: previous definition of 
 'MAGIC_TO_JSVAL_IMPL' was here
 /usr/include/mozjs/jsvalue.h:324:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jsvalue.h:324:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jstl.h:43:0,
                  from /usr/include/mozjs/jsvector.h:44,
                  from /usr/include/mozjs/jsobj.h:58,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jsbit.h:255:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jsbit.h:255:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jsvector.h:44:0,
                  from /usr/include/mozjs/jsobj.h:58,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jstl.h:47:15: fatal error: new: No such file or directory
 compilation terminated.
 make[2]: *** [JavaScript.o] Error 1

 The full build log is available from:
   
 http://people.debian.org/~lucas/logs/2011/07/18/libjavascript-perl_1.16-3_lsid64.buildlog

 A list of current common problems and possible solutions is available at
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.

 --
 | Lucas Nussbaum
 | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
 | jabber: lu...@nussbaum.fr             GPG: 1024D/023B3F4F |



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-perl-maintainers




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#634397: Proposed removal of libjavascript-perl

2011-07-18 Thread Jonathan Yu
Hi all,

I propose that we consider removing libjavascript-perl. It looks like
it has been failing to build for quite some time, but we have not
known because there have not been any new versions of
libjavascript-perl.

Thanks to Lucas Nussbaum, we have discovered that the package doesn't
build today. Even when it did build (where it was built against
libmozjs-dev 1.9.1.19), it emitted a bunch of warnings during built.
Looking at the historic build logs, it seems to have a spotty history
of frequently failing to build from source (presumably due to changes
in the API/ABI of SpiderMonkey).

I investigated the issue and it appears to be related to the version
of the SpiderMonkey library that this package is built against,
libmozjs-dev. By installing snapshots, I have been able to determine
that these package versions:

libmozjs-dev 1.9.2.13-2 (source: iceweasel 3.6.13-2)
libmozjs3d 1.9.2.13-2 (source: iceweasel 3.6.13-2)

cause libjavascript-perl to fail to build. Note that the last time
libmozjs-dev *DID* build against libjavascript-perl (version 1.9.1.19
of libmozjs-dev), it was against libmozjs2d, where it still emitted a
bunch of warnings during build [0].

So my reasons FOR a removal of this package are thus:

1. It is not used by many packages (its only reverse dependency is
debian-edu-config)

2. It looks like it has been broken for a long time (many outstanding
bug reports upstream, as well as test failures)

3. It is now several versions behind the latest libmozjs -- there is
currently a libmozjs6d, and the last time this package built was
against libmozjs2d.

4. It may be too difficult to figure out how to get this package to
build, and is probably not worth it considering that it appears pretty
dead upstream

Cheers,

Jonathan

[0] 
https://buildd.debian.org/status/fetch.php?pkg=libjavascript-perlarch=mipselver=1.16-3%2Bb1stamp=1304478428

-- Forwarded message --
From: Lucas Nussbaum lu...@lucas-nussbaum.net
Date: Mon, Jul 18, 2011 at 6:02 PM
Subject: Bug#634397: libjavascript-perl: FTBFS: jslock.h:221:1: error:
unknown type name 'namespace'
To: sub...@bugs.debian.org


Source: libjavascript-perl
Version: 1.16-3
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20110718 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part:
 cc -c  -I/usr/include/nspr/ -I/usr/include/mozjs/ -D_REENTRANT -D_GNU_SOURCE 
 -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include 
 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -DMOZILLA_1_8_BRANCH=1   
 -DVERSION=\1.16\ -DXS_VERSION=\1.16\ -fPIC -I/usr/lib/perl/5.12/CORE   
 JavaScript.c
 In file included from /usr/include/mozjs/jsapi.h:48:0,
                  from JavaScript_Env.h:12,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/js-config.h:50:0: warning: JS_THREADSAFE redefined 
 [enabled by default]
 JavaScript_Env.h:8:0: note: this is the location of the previous definition
 In file included from /usr/include/mozjs/jsobj.h:56:0,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jslock.h:221:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jslock.h:221:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jsobj.h:57:0,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from JavaScript.h:19,
                  from JavaScript.xs:5:
 /usr/include/mozjs/jsvalue.h: In function 'JSDOUBLE_IS_INT32':
 /usr/include/mozjs/jsvalue.h:111:16: error: 'false' undeclared (first use in 
 this function)
 /usr/include/mozjs/jsvalue.h:111:16: note: each undeclared identifier is 
 reported only once for each function it appears in
 /usr/include/mozjs/jsvalue.h:112:24: error: expected expression before 
 'int32_t'
 /usr/include/mozjs/jsvalue.h: At top level:
 /usr/include/mozjs/jsvalue.h:241:1: error: conflicting types for 
 'MAGIC_TO_JSVAL_IMPL'
 /usr/include/mozjs/jsvalue.h:233:1: note: previous definition of 
 'MAGIC_TO_JSVAL_IMPL' was here
 /usr/include/mozjs/jsvalue.h:324:1: error: unknown type name 'namespace'
 /usr/include/mozjs/jsvalue.h:324:14: error: expected '=', ',', ';', 'asm' or 
 '__attribute__' before '{' token
 In file included from /usr/include/mozjs/jstl.h:43:0,
                  from /usr/include/mozjs/jsvector.h:44,
                  from /usr/include/mozjs/jsobj.h:58,
                  from /usr/include/mozjs/jsfun.h:47,
                  from /usr/include/mozjs/jsinterp.h:48,
                  from JavaScript_Env.h:14,
                  from 

Bug#603250: Removal of libfile-temp-perl

2011-07-17 Thread Jonathan Yu
To whoever might stumble upon this bug,

I looked into it quickly and it looks like libmodule-pluggable-perl has
already been removed from squeeze. I guess we need to leave this bug
here to prevent it from being migrated to testing.

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#603249: Removal of libfile-temp-perl

2011-07-16 Thread Jonathan Yu
To whoever might stumble upon this bug,

I looked into it quickly and it looks like libfile-temp-perl has
already been removed from squeeze. I guess we need to leave this bug
here to prevent it from being migrated to testing.

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#630578: debian-policy: clarify usage of Uploaders field

2011-06-15 Thread Jonathan Yu
Hi,

I will second Emilio's response here... In the Debian Perl Group, I
have been marked Uploader of many of our packages (though I'm not yet
a DD), since otherwise Lintian complains about it (with the exception
of the more recently introduced new Team Upload syntax).

I would suggest that anyone who is listed in d/changelog (in the
trailer lines) should also be listed in Uploaders, unless they have
explicitly asked to be removed, or unless the relevant changelog
entries have been marked Team Upload or Non-maintainer Upload.

I think that anyone who considers themselves a custodian of the
package(s) in question should be added to Uploaders, whether or not
they are a DD, and whether or not they actually do the uploading (e.g.
if the package is being sponsored, the sponsor need not add themselves
to Uploaders if they do not wish to do so).

Hope this helps,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#619030: ITP: libdevel-caller-ignorenamespaces-perl -- module for hiding namespaces from caller()

2011-03-20 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdevel-caller-ignorenamespaces-perl
  Version : 1.0
  Upstream Author : David Cantrell da...@cantrell.org.uk
* URL : http://search.cpan.org/dist/Devel-Caller-IgnoreNamespaces/
* License : Artistic or GPL-2
  Programming Lang: Perl
  Description : module for hiding namespaces from caller()

Devel::Caller::IgnoreNamespaces is a Perl module designed to hide namespaces
from caller(). It allows you to register namespaces that should be hidden by
means of a replacement caller() function.

NOTE: this package is needed to upgrade libsub-wrappackages-perl



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#619037: ITP: libgetopt-lucid-perl -- module for parsing command line arguments

2011-03-20 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: 
debian-de...@lists.debian.org,debian-p...@lists.debian.org,dagol...@cpan.org

* Package name: libgetopt-lucid-perl
  Version : 0.19
  Upstream Author : David Golden dagol...@cpan.org
* URL : http://search.cpan.org/dist/Getopt-Lucid/
* License : Apache-2.0
  Programming Lang: Perl
  Description : module for parsing command line arguments

Getopt::Lucid is a Perl module for parsing command line arguments, similar in
nature to Getopt::Long (in Perl core). The goal of this module is to provide
good code readability and clarity of intent, relying on plain-English option
specification as opposed to the more symbolic approach of Getopt::Long.

NOTE: this package is required for ylastic-costagent (see BTS#618980)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#619035: RFP: libzeromq-perl -- ZeroMQ2 wrapper for Perl

2011-03-20 Thread Jonathan Yu
retitle 619035 ITP: libzeromq-perl -- ZeroMQ2 wrapper for Perl
owner 619035 !
thanks

Hello,

I intend to package this shortly :-)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#619079: ITP: libobject-tiny-perl -- module for building classes, simply

2011-03-20 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libobject-tiny-perl
  Version : 1.06
  Upstream Author : Adam Kennedy ad...@cpan.org
* URL : http://search.cpan.org/dist/Object-Tiny/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for building classes, simply

Object::Tiny is a Perl module for building classes as simply as possible. It
is useful for rapid prototyping, especially for data classes with a simple
structure and mostly read-only accessors. It is a minimalistic way to build
classes, intentionally omitting complex features that interfere with the way
you build modules.

NOTE: this package is needed for ylastic-costagent (see BTS#618980)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#618931: ITP: liblog-contextual-perl -- module for simple contextual logging

2011-03-19 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: 
debian-de...@lists.debian.org,debian-p...@lists.debian.org,fri...@gmail.com

* Package name: liblog-contextual-perl
  Version : 0.00304
  Upstream Author : frew - Arthur Axel fREW Schmidt fri...@gmail.com
* URL : http://search.cpan.org/dist/Log-Contextual/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for simple contextual logging

Log::Contextual is a Perl module that provides an implementation-independent
interface for simple data logging. It supports painless switching between any
logger that implements the defined interface, either for the entire program
(using set_logger) or for a given section of code (using with_logger).

The framework supports many logging levels that are enabled using environment
variables (these are, in order of decreasing verbosity: trace, debug, info,
warn, error, and fatal).

This package includes simple loggers that can be seamlessly upgraded to more
advanced loggers, such as Log::Dispatchouli (see liblog-dispatchouli-perl).

NOTE: this package is needed for the packaging of
libdbix-class-deploymenthandler-perl (see BTS#617978)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#618980: ITP: ylastic-costagent -- client for submitting AWS usage data to Ylastic

2011-03-19 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: 
debian-de...@lists.debian.org,debian-p...@lists.debian.org,dagol...@cpan.org

* Package name: ylastic-costagent
  Version : 0.003
  Upstream Author : David Golden dagol...@cpan.org
* URL : http://search.cpan.org/dist/App-Ylastic-CostAgent/
* License : Apache-2.0
  Programming Lang: Perl
  Description : client for submitting AWS usage data to Ylastic

ylastic-costagent is a program that downloads usage data from an Amazon Web
Services (AWS) account and uploads it to Ylastic URL:http://ylastic.com/
for cost analysis.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#617985: perl-modules: missing Provides for File::Path (version 2.04 is in Perl 5.10.0)

2011-03-14 Thread Jonathan Yu
Hey Dominic,

 I agree that the Provides/Conflicts/Replaces are missing for this module,
 but I'm not sure why you picked ( 2.04): 5.10.1 has 2.07_03, so this
 should be ( 2.08), shouldn't it?

 Nevermind, I realise now that the subject line explains that you were
 looking at 5.10.0 (presumably by mistake).

You are correct of course :-)

As long as the correct Provides/Conflicts/Replaces stuff is added, I
am happy. Will this require changes in the libfile-path-perl point of
view? I haven't investigated so far, but my thought would be that only
perl-modules needs to be changed.

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#618024: ITP: libmethod-signatures-simple-perl -- module for basic method declarations with signatures

2011-03-13 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmethod-signatures-simple-perl
  Version : 0.06
  Upstream Author : Rhesa Rozendaal rh...@cpan.org
* URL : http://search.cpan.org/dist/Method-Signatures-Simple/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for basic method declarations with signatures

Method::Signatures::Simple is a Perl module that enables developers to make
basic method declarations, optionally with a signature as well. It provides
a
small amount of syntactic sugar and is intended to be a stepping stone to
the
more feature-complete Method::Signatures (see libmethod-signatures-perl) and
MooseX::Method::Signatures (see libmoosex-method-signatures-perl) modules.


Bug#618272: ITP: libperlio-gzip-perl -- module providing a PerlIO layer to gzip/gunzip

2011-03-13 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libperlio-gzip-perl
  Version : 0.18
  Upstream Author : Nicholas Clark, nwc10+perlio-g...@colon.colondot.net
* URL : http://search.cpan.org/dist/PerlIO-gzip/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module providing a PerlIO layer to gzip/gunzip

PerlIO::gzip is a Perl module that provides a PerlIO layer for manipulating
files in the format used by the gzip program. Compression and decompression
are both implemented, but cannot be used simultaneously (i.e. files cannot
be opened for both reading and writing).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#617946: ITP: libtest-www-mechanize-mojo-perl -- module for testing web applications built using Mojolicious

2011-03-12 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtest-www-mechanize-mojo-perl
  Version : 0.0.8
  Upstream Author : Shlomi Fish shlo...@iglu.org.il
* URL : http://search.cpan.org/dist/Test-WWW-Mechanize-Mojo/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for testing web applications built using
Mojolicious

Test::WWW::Mechanize::Mojo is a Perl framework for testing web applications
based on Mojolicious (see libmojolicious-perl). It extends the functionality
of Test::WWW::Mechanize (see libtest-www-mechanize-perl) by enabling testing
without requiring a web server.


Bug#617978: ITP: libdbix-class-deploymenthandler-perl -- framework for deploying and upgrading databases

2011-03-12 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdbix-class-deploymenthandler-perl
  Version : 0.001004
  Upstream Author : Arthur Axel Schmidt frioux+c...@gmail.com
* URL :
http://search.cpan.org/dist/DBIx-Class-DeploymentHandler/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : framework for deploying and upgrading databases

DBIx::Class::DeploymentHandler is a collection of tools for deploying and
upgrading databases with DBIx::Class. It is similar to, but more flexible
than, DBIx::Class::Schema::Versioned (see libdbix-class-perl).

It is really just a recommended set of Moose roles that provide:

 * Downgrades in addition to upgrades
 * Multiple sql files files per upgrade/downgrade/install
 * Perl scripts allowed for upgrade/downgrade/install
 * Just one set of files needed for upgrade


Bug#617985: perl-modules: missing Provides for File::Path (version 2.04 is in Perl 5.10.0)

2011-03-12 Thread Jonathan Yu
Package: perl-modules
Version: 5.10.1-17
Severity: important


The perl-modules package is missing:

  Provides: libfile-path-perl
  Conflicts: libfile-path-perl ( 2.04)

I noticed this problem as a result of an sbuild issue:

  Using: libtest-simple-perl (= 0.88) | perl (= 5.11.1) works
  But:   libfile-path-perl | perl (= 5.11.1) does not work

This is because the second case currently causes the sbuild resolver to
think that libfile-path-perl is missing. In the first case, sbuild's
resolver thinks there is a version of libtest-simple-perl installed, but
which is too old (~*PROVIDES* is  0.88), so version 0.88 is correctly
downloaded and installed, without causing issues due to the alternative
dependency not being satisfiable.

Anyway, simple fix is to add the Provides/Conflicts mentioned.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages perl-modules depends on:
ii  perl  5.10.1-17  Larry Wall's Practical Extraction 

perl-modules recommends no packages.

perl-modules suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#617788: ITP: cpan-listchanges -- package change history notification tool

2011-03-11 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: cpan-listchanges
  Version : 0.05
  Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net
* URL : http://search.cpan.org/dist/cpan-listchanges/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : package change history notification tool

cpan-listchanges is a command-line application that compares the Changes file
between arbitrary versions of a package. It is similar to apt-listchanges,
and by default, it compares the currently installed version with the latest
one available on CPAN.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#617744: ITP: libnet-frame-perl -- framework for crafting raw frames

2011-03-10 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libnet-frame-perl
  Version : 1.07
  Upstream Author : Patrice Auffret gomor-c...@gomor.org
* URL : http://search.cpan.org/dist/Net-Frame/
* License : Artistic
  Programming Lang: Perl
  Description : framework for crafting raw frames

Net::Frame is a Perl framework for crafting raw frames (Layers 2 through 7).
Out of the box, it can be used to produce ARP, Ethernet, IPv4, PPP, TCP and
UDP frames. It has an extensible design for new frame implementations.

This module only creates frames; Net::Write (see libnet-write-perl) can be
used to write frames directly to wire.

NOTE: this package replaces a now-defunct RFP for libnet-packet-perl
(Net::Frame is an upstream fork of Net::Packet, and Net::Packet is
deprecated upstream)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#615963: libvendorlib-perl: tilde expansion tests failing

2011-03-08 Thread Jonathan Yu
Damyan,

I was initially unable to reproduce the issue because sbuild by
default does mount /home inside the chroot.

However, Salvatore told me via IRC that the buildd's are configured in
such a way that they do not have a writable home.

I don't know whether this is an issue with sbuild (though we can
certainly do some sort of hack to get around this issue) or a problem
with the way buildd's are set up.

However, I guess it's preferred if packages being built don't write
junk to /home anyway...

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#616628: ITP: libmoosex-insideout-perl -- Moose extension for non-intrusive subclassing

2011-03-05 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-insideout-perl
  Version : 0.105
  Upstream Author : Hans Dieter Pearcey h...@cpan.org
* URL : http://search.cpan.org/dist/MooseX-InsideOut/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Moose extension for non-intrusive subclassing

MooseX::InsideOut is a Perl module that enables non-intrusive subclassing of
non-Moose classes with Moose. By setting up attribute slot storage somewhere
other than $self, you can extend classes whose internals are not hash-based.

NOTE: this package is needed for the upgrading of libpoe-filter-xml-perl



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#616029: actually a technical term

2011-03-02 Thread Jonathan Yu
Nicholas,

He knows this, and I pointed him to this page describing it:

http://qa.perl.org/phalanx/kwalitee.html

He said yesterday he would be sending a more detailed report shortly.

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#616029: what is kwalitee?

2011-03-01 Thread Jonathan Yu
tag 616029 wontfix
thanks

Hello,

I was on IRC when you were discussing this a moment ago.

With all due respect:

This suggestion is stupid.

Cheers,

Jonathan

On Tue, Mar 1, 2011 at 7:43 PM, Adam Heath doo...@brainfood.com wrote:
 package: libtest-strict-perl
 version: 0.14-1

 There is an unknown word, 'kwalitee' in the package description. Please put
 the correct word in its place.



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#615963: cannot reproduce: tilde expansion tests failing

2011-03-01 Thread Jonathan Yu
tag 615963 unreproducible
severity 615963 important
thanks

Hello,

I cannot reproduce this issue on my system -- downgrading to important.

Here is the build log:
aven'jon(~/pkg-perl/trunk/libvendorlib-perl) build
Copying package data to temporary build area...
Downloading latest upstream version...
libvendorlib-perl: Version (0.10) available on remote site:
  http://search.cpan.org/CPAN/authors/id/R/RK/RKITOVER/vendorlib-0.10.tar.gz
  (local version is 0.10)
libvendorlib-perl: Successfully downloaded updated package vendorlib-0.10.tar.gz
and symlinked libvendorlib-perl_0.10.orig.tar.gz to it
Building source package...
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package libvendorlib-perl
dpkg-buildpackage: source version 0.10-1
dpkg-buildpackage: source changed by Nicholas Bamber nicho...@periapt.co.uk
 dpkg-source --before-build build
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b build
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building libvendorlib-perl using existing
./libvendorlib-perl_0.10.orig.tar.gz
dpkg-source: info: building libvendorlib-perl in
libvendorlib-perl_0.10-1.debian.tar.gz
dpkg-source: info: building libvendorlib-perl in libvendorlib-perl_0.10-1.dsc
 dpkg-genchanges -S ../libvendorlib-perl_0.10-1_source.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build build
dpkg-buildpackage: full upload (original source is included)
Building package using sbuild (unstable)...
sbuild (Debian sbuild) 0.60.8 (12 Dec 2010) on aven.local

+--+
¦ libvendorlib-perl 0.10-1 (i386)01 Mar 2011 21:19 ¦
+--+

Package: libvendorlib-perl
Version: 0.10-1
Source Version: 0.10-1
Architecture: i386
E: 80apt-get-update: Ign http://localhost unstable InRelease
E: 80apt-get-update: Get:1 http://localhost unstable Release.gpg [835 B]
E: 80apt-get-update: Get:2 http://localhost unstable Release [146 kB]
E: 80apt-get-update: Get:3 http://localhost unstable/main i386
Packages/DiffIndex [2038 B]
E: 80apt-get-update: Get:4 http://localhost unstable/main
TranslationIndex [2232 B]
E: 80apt-get-update: Get:5 http://localhost unstable/main i386
2011-03-01-1412.05.pdiff [13.3 kB]
E: 80apt-get-update: Get:6 http://localhost unstable/main i386
2011-03-01-1412.05.pdiff [13.3 kB]
E: 80apt-get-update: Get:7 http://localhost unstable/main i386
2011-03-01-2011.01.pdiff [9777 B]
E: 80apt-get-update: Get:8 http://localhost unstable/main i386
2011-03-01-2011.01.pdiff [9777 B]
E: 80apt-get-update: Fetched 175 kB in 58s (2997 B/s)
Ign http://localhost unstable InRelease
Hit http://localhost unstable Release.gpg
Hit http://localhost unstable Release
Hit http://localhost unstable/main i386 Packages/DiffIndex
Hit http://localhost unstable/main TranslationIndex
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
¦ Fetch source files   ¦
+--+


Local sources
-

libvendorlib-perl_0.10-1.dsc exists in /tmp/tmp.xnTx3NkSRz; copying to chroot

Check arch
--


+--+
¦ Install core build dependencies (internal resolver)  ¦
+--+

Build-Depends: build-essential, fakeroot
Checking for already installed dependencies...
build-essential: already installed (11.5)
fakeroot: already installed (1.14.5-2)
Checking for dependency conflicts...
Installing positive dependencies:
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Removing negative dependencies:
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Checking correctness of dependencies...
Cannot open 
/var/lib/schroot/mount/sid-4bbe2c8d-49cf-4f3f-900a-9f84086fcc34/sid/etc/lsb-release:
No such file or directory

+--+
¦ Install libvendorlib-perl build dependencies (internal 

Bug#615925: ITP: libsub-exporter-globexporter-perl -- module for exporting shared globs

2011-02-28 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libsub-exporter-globexporter-perl
  Version : 0.002
  Upstream Author : Ricardo Signes r...@cpan.org
* URL : http://search.cpan.org/dist/Sub-Exporter-GlobExporter/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for exporting shared globs

Sub::Exporter::GlobExporter is a Perl module that enables packages to share
glob references with other modules. This allows your module to be subclassed,
for the subclass to re-use the same glob when exporting, or to export a new
one. This scheme provides extensibility by returning a collection validator,
allowing arbitrary options to be passed to the globref locator.

NOTE: this has been needed for an upgrade of liblog-dispatchouli-perl
for some time now.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#615605: libjson-perl: upgrade libjson-pp-perl from Recommends to Depends

2011-02-27 Thread Jonathan Yu
Package: libjson-perl
Version: 2.27-1
Severity: important


Due to a misunderstanding as to the intent of this package, and its
relation to JSON::PP (see libjson-pp-perl), JSON::PP was considered a
Recommends rather than a Depends.

In a discussion with David Golden, it was identified that this package
should be considered a Depends. The JSON::backportPP module was not meant
to be used in normal circumstances:

   However, as long as libjson-perl will work (i.e. the JSON module) in
   the absence of libjson-pp-perl, then it should be a Recommends rather
   than a Depends.

  Will work, but was not designed to be used that way.  The
  JSON::backportPP was a stopgap to ensure that if something went wrong
  with the split of JSON::PP, that JSON would still have a pure-perl
  fallback.  It's an engineering safety, not an intended user API.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#615002: libjson-pp-perl

2011-02-25 Thread Jonathan Yu
Hi all,

I have done some investigation and believe I can offer some
clarification regarding libjson-pp-perl...

The upstream JSON package formerly contained two key modules:
* JSON (this selected JSON::XS if available, or fell back to the
included JSON::PP module otherwise)
* JSON::PP

Upstream has now split JSON::PP into its own package, instead
replacing it in the JSON package with JSON::backportPP.

So the load order is now:
* JSON::XS (from libjson-xs-perl)
* JSON::PP (from the libjson-pp-perl module that I am preparing to upload soon)
* JSON::backportPP (formerly the JSON::PP, but renamed to avoid
namespace conflicts; this is included with the JSON package)

As far as I can tell, the separately packaged JSON::PP is newer than
JSON::backportPP, so I am not sure what level of support the author
intends for the backportPP module. It is therefore in Debian's best
interests to upload libjson-pp-perl (and as Nicholas mentioned,
CPAN::Meta requires it now, so we will need to upload it in order to
upgrade).

Hope this helps clarify things :-)

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#614597: libnamespace-clean-perl: Uninstallable alongside libpackage-stash-perl (0.25-1), upstream update needed

2011-02-22 Thread Jonathan Yu
Hello,

Thanks for your bug report.

If I recall correctly, the issue is that:

DBIx::Class requires a new namespace::clean

namespace::clean needs a new Package::Stash

new Package::Stash needs Package::Stash::XS

However, Package::Stash::XS ... well, I guess it was just accepted in
the archive recently. We will prepare the other dependencies and
upload them at our earliest convenience.

Cheers,

Jonathan

On Tue, Feb 22, 2011 at 9:42 AM, Jo Shields direct...@apebox.org wrote:
 Package: libnamespace-clean-perl
 Version: 0.18-1
 Severity: important
 Tags: upstream

 From the changelog to libpackage-stash-perl (0.25-1):

   * Breaks: libclass-mop-perl ( 1.09~),
 libmoosex-roles-withoverloading-perl ( 0.09~), libnamespace-clean-perl
 ( 0.19~) due to API changes.

 As a result, libdbix-class-perl is uninstallable.

 Upstream is up to version 0.20 of libnamespace-clean-perl which
 supposedly is unaffected by the problem, assuming the numbering in
 libpackage-stash-perl is accurate.



 -- System Information:
 Debian Release: squeeze/sid
  APT prefers maverick-updates
  APT policy: (500, 'maverick-updates'), (500, 'maverick-security'),
 (500, 'maverick-backports'), (500, 'maverick')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.35-25-generic (SMP w/4 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash


 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#614392: ITP: libpoe-component-resolver-perl -- POE Component for domain name resolution

2011-02-21 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpoe-component-resolver-perl
  Version : 0.910
  Upstream Author : Rocco Caputo rcap...@cpan.org
* URL : http://search.cpan.org/dist/POE-Component-Resolver/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : POE Component for domain name resolution

POE::Component::Resolver is a Perl module that provides nonblocking domain
name resolution by using Socket::GetAddrInfo's getaddrinfo() function in
subprocesses where they are permitted to block indefinitely.

By default, it will use a maximum of eight subprocesses and prefer address
families in whatever order Socket::GetAddrInfo returns them. These defaults
can be overridden with constructor parameters.

NOTES: this package is needed for the upgrade of
libpoe-component-client-keepalive-perl, which is needed for an upgrade
of libpoe-component-client-http-perl



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#614067: RM: libwww-myspace-perl -- ROM; module does not work due to changed MySpace web interface

2011-02-19 Thread Jonathan Yu
Package: ftp.debian.org
Severity: normal


This module is broken following changes on the MySpace web interface
in late 2010. The upstream was the person that initially proposed this
removal, as apparently there are no plans to fix the module anytime
soon. Previously, this package was removed from testing to prevent its
inclusion in squeeze. Given upstream's inactivity, we (the Debian Perl
Group) believe it would be best to simply remove the package from
Debian entirely.

Please see bug report #603737 for additional details.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#603737: Should libwww-myspace-perl be removed?

2011-02-19 Thread Jonathan Yu
block 603737 by 614067
thanks

To all interested parties:

I have requested that this package be removed from the archive. Please
see BTS#614067 for details.

This bug can be closed once 614067 is resolved.

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#523224: libnet-jabber-perl: changing back from ITA to O

2011-02-19 Thread Jonathan Yu
Note to anyone attempting to take over this package:

It has been sitting in our repository for quite some time, due to a
request for copyright info from upstream that is still pending. I
suppose either upstream doesn't use the RT or the upstream libraries
aren't very well maintained.

Perhaps it is a thought to have this package removed from Debian altogether.

For details, please see https://rt.cpan.org/Ticket/Display.html?id=59761

Cheers,

Jonathan

On Sat, Feb 19, 2011 at 11:57 AM, Lucas Nussbaum lu...@debian.org wrote:
 retitle 523224 O: libnet-jabber-perl -- Perl modules for accessing the Jabber 
 protocol
 noowner 523224
 thanks

 Hi,

 This is an automatic email to change the status of libnet-jabber-perl back 
 from ITA
 (Intent to Adopt) to O (Orphaned), because this bug hasn't seen any activity
 during the last 6 months.

 If you are still interested in adopting libnet-jabber-perl, please send a 
 mail to
 cont...@bugs.debian.org with:

  retitle 523224 ITA: libnet-jabber-perl -- Perl modules for accessing the 
 Jabber protocol
  owner 523224 !
  thanks

 However, it is not recommended to keep ITA for a long time without acting on
 the package, as it might cause other prospective maintainers to refrain from
 adopting the package. It is also a good idea to document your progress on this
 ITA from time to time, by mailing 523...@bugs.debian.org.

 Thank you for your interest in Debian,
 --
 Lucas, for the QA team debian...@lists.debian.org



 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608562: any progress?

2011-02-14 Thread Jonathan Yu
Alessandro,

If I had any work done on this, it would be in the repository. I guess
it just got forgotten, especially when the freeze was underway.

You can feel free to take it over if you'd like to do so :-)

Cheers,

Jonathan

On Mon, Feb 14, 2011 at 5:44 AM, Alessandro Ghedini al3x...@gmail.com wrote:
 Hello Jonathan,
 how is this going?

 Cheers

 --
 perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#613476: ITP: libjio -- library for journalled, transaction-oriented I/O

2011-02-14 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: libjio
  Version : 1.01
  Upstream Author : Jonathan Yu jaw...@cpan.org
* URL : http://blitiri.com.ar/p/libjio/
* License : BOLA
  Programming Lang: C
  Description : library for journalled, transaction-oriented I/O

libjio is a userspace library for journalled, transaction-oriented file
input/output operations. It provides a simple interface to perform common
file operations in a non-intrusive threadsafe and atomic way, with safe and
fast crash recovery.

The library guarantees file integrity even after unexpected crashes, never
leaving your files in an inconsistent state. On disk, the file you work on
is exactly like a regular one, but a special directory is created to store
in-flight transactions.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#613187: xs/SceneQuery.xs:28: error: cannot convert [..]

2011-02-13 Thread Jonathan Yu
Dominic,

It looks like the dependencies might've changed recently...
who-uploads for both libogre-dev and libgtk2.0-dev give me nothing,
however:

 libgtk2.0-dev | 2.20.1-2 | squeeze | amd64, armel,
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc,
s390, sparc
 libgtk2.0-dev | 2.20.1-2 | wheezy  | amd64, armel,
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc,
s390, sparc
 libgtk2.0-dev | 2.20.1-2 | sid | alpha, amd64,
armel, hppa, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386,
mips, mipsel, powerpc, s390, sparc

All versions are the same across the suites.

 libogre-dev | 1.6.4.dfsg1-1 | squeeze | amd64, armel, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 libogre-dev | 1.6.4.dfsg1-1 | wheezy  | amd64, armel, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 libogre-dev | 1.6.4.dfsg1-1 | sid | armel, mips
 libogre-dev | 1.7.1-1   | sid | alpha, amd64, hppa,
hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mipsel, powerpc,
s390, sparc

It looks like libogre-dev was upgraded recently enough to not have
migrated to testing yet.

The upstream changelog for libogre-perl (new version is 0.50) has:

0.50 2010-12-14 | support Ogre = 1.7.2
- dropping support for versions of Ogre before 1.7.2 (released 2010-11-03)
- removed Readonly (optional) dependence (for one example)
- ported to 1.7.2

So perhaps this fix also makes Ogre work with libogre-dev = 1.7.1?

At this point, it looks like Ogre may not support 1.7.1, and the new
version doesn't support the existing libogre-dev (not tested by me yet
though, just based on the changelog entry). A bit of a tricky
situation indeed.

Cheers,

Jonathan

On Sun, Feb 13, 2011 at 8:18 AM, Dominic Hargreaves d...@earth.li wrote:
 Package: libogre-perl
 Version: 0.40-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)

 This package failed to build on sid i386 today:

 g++ -c  -pthread -I/usr/include/OGRE   -pthread -I/usr/include/gtk-2.0 
 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo 
 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 
 -I/usr/include/libpng12 -I/usr/include/libdrm   -Wno-write-strings -O2 -g   
 -DVERSION=\0.40\ -DXS_VERSION=\0.40\ -fPIC -I/usr/lib/perl/5.10/CORE  
 -DPERLOGRE_HAS_GTK2 Ogre.c
 xs/SceneQuery.xs: In function 'void 
 XS_Ogre__SceneQuery_getSupportedWorldFragmentTypes(PerlInterpreter*, CV*)':
 xs/SceneQuery.xs:28: error: cannot convert 'const 
 std::setOgre::SceneQuery::WorldFragmentType, 
 std::lessOgre::SceneQuery::WorldFragmentType, 
 Ogre::STLAllocatorOgre::SceneQuery::WorldFragmentType, 
 Ogre::CategorisedAllocPolicy(Ogre::MemoryCategory)0u  *' to 'const 
 std::setOgre::SceneQuery::WorldFragmentType, 
 std::lessOgre::SceneQuery::WorldFragmentType, 
 std::allocatorOgre::SceneQuery::WorldFragmentType *' in initialization
 Ogre.c: In function 'void 
 XS_Ogre__Root__setCurrentSceneManager(PerlInterpreter*, CV*)':
 Ogre.c:14683: error: 'class Ogre::Root' has no member named 
 '_setCurrentSceneManager'
 xs/ResourceGroupManager.xs: In function 'void 
 XS_Ogre__ResourceGroupManager_DEFAULT_RESOURCE_GROUP_NAME(PerlInterpreter*, 
 CV*)':
 xs/ResourceGroupManager.xs:28: error: 'BOOTSTRAP_RESOURCE_GROUP_NAME' is not 
 a member of 'Ogre::ResourceGroupManager'
 xs/RenderSystem.xs: In function 'void 
 XS_Ogre__RenderSystem_bindGpuProgramParameters(PerlInterpreter*, CV*)':
 xs/RenderSystem.xs:123: error: no matching function for call to 
 'Ogre::RenderSystem::bindGpuProgramParameters(Ogre::GpuProgramType, 
 Ogre::GpuProgramParametersSharedPtr)'
 /usr/include/OGRE/OgreRenderSystem.h:1103: note: candidates are: virtual void 
 Ogre::RenderSystem::bindGpuProgramParameters(Ogre::GpuProgramType, 
 Ogre::GpuProgramParametersSharedPtr, Ogre::uint16)
 xs/Node.xs: In function 'void XS_Ogre__Node_getMaterial(PerlInterpreter*, 
 CV*)':
 xs/Node.xs:320: error: 'class Ogre::Node' has no member named 'getMaterial'
 Ogre.c: In function 'void XS_Ogre__Node_getRenderOperation(PerlInterpreter*, 
 CV*)':
 Ogre.c:30052: error: 'class Ogre::Node' has no member named 
 'getRenderOperation'
 Ogre.c: In function 'void 
 XS_Ogre__MovableObject_detatchFromParent(PerlInterpreter*, CV*)':
 Ogre.c:30567: error: 'class Ogre::MovableObject' has no member named 
 'detatchFromParent'
 Ogre.c: In function 'void 
 XS_Ogre__Mesh_getLodIndexSquaredDepth(PerlInterpreter*, CV*)':
 Ogre.c:32217: error: 'class Ogre::Mesh' has no member named 
 'getLodIndexSquaredDepth'
 Ogre.c: In function 'void 
 XS_Ogre__Material_getLodIndexSquaredDepth(PerlInterpreter*, CV*)':
 Ogre.c:35427: error: 'class Ogre::Material' has no member named 
 'getLodIndexSquaredDepth'
 Ogre.c: In function 'void 
 XS_Ogre__GpuProgram_setSurfaceAndPassLightStates(PerlInterpreter*, 

Bug#609628: [buildd-tools-devel] Bug#609628: Build interacts badly with local::lib (installs Perl modules to local::lib directory)

2011-02-12 Thread Jonathan Yu
Hi Roger,

Thanks for the follow-up.

I did a dist-upgrade of my system. I'm not sure what exactly was
upgraded (incidentally a new version of liblocal-lib-perl seems to be
installed, as the environment variables are slightly different now).

Anyway, I can no longer reproduce the issue, so I take it the new
sbuild fixed things. I suppose the bug can be closed (though I don't
know what version specifically it was fixed in).

Cheers,

Jonathan

On Tue, Feb 1, 2011 at 9:02 AM, Roger Leigh rle...@codelibre.net wrote:
 On Sun, Jan 30, 2011 at 10:18:13AM -0500, Jonathan Yu wrote:
 I ran into this issue again, so I had it dump out `env' during build
 (by adding it to debian/rules).

 Notice these variables (put in by local:;lib -- if these are sanitized
 by sbuild, this bug should go away. Perhaps Env::Sanctify can be used
 for this purpose?)

 MODULEBUILDRC=/home/jon/.perl5/.modulebuildrc
 PERL_MM_OPT=INSTALL_BASE=/home/jon/.perl5
 PERL5LIB=/home/jon/.perl5/lib/perl5/i486-linux-gnu-thread-multi:/home/jon/.perl5/lib/perl5

 I might be in a position to provide a patch at some point...

 This is the current environment filter regex (lib/Sbuild/Conf.pm):

        'ENVIRONMENT_FILTER'                    = {
            DEFAULT = ['^DEB(IAN|SIGN)?_[A-Z_]+$',
                        '^(C(PP|XX)?|LD|F)FLAGS(_APPEND)?$']
        },

 This is from current git, though a similar regex is in the
 unstable version.  Are you using the version from unstable or git?
 If not, could you try it using the above regex?

 Note you can set '$environment_filter = ['^DEB(IAN|SIGN)?_[A-Z_]+$',
                        '^(C(PP|XX)?|LD|F)FLAGS(_APPEND)?$'];'
 in your .sbuildrc.


 Thanks,
 Roger

 --
  .''`.  Roger Leigh
  : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
  `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iEYEARECAAYFAk1IEoUACgkQVcFcaSW/uEh2VQCfakJePFgQ5oJOgDKSGoOQcBY0
 K7gAoMvP7TqQCgsqmR5vwP3XIh0Uk09u
 =4y5E
 -END PGP SIGNATURE-





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#525022: Missing man page for memcachedb

2011-02-05 Thread Jonathan Yu
Hi there,

I wrote a manpage you can use for memcachedb. Note that I'm new to
writing manpages (this was my first after looking at a blog post about
it, drawing some inspiration from Perl's autogenerated .pod files).
Please forgive any errors I've made :-)

I have it in a local copy of the memcachedb source package as
debian/memcachedb.man. It is installed using the following override in
debian/rules:

override_dh_installman:
dh_installman $(CURDIR)/debian/memcachedb.man

Lintian is happy with this as installed by my local memcachedb source
package (built using sbuild in an unstable chroot).

.TH MEMCACHEDB 1 05 February 11
.SH NAME
memcachedb \- persistence-enabled variant of memcached
.SH SYNOPSIS
\fBmemcachedb\fP [\fIOPTIONS\fP]
.SH DESCRIPTION
MemcacheDB (pronounced \fImem-cash-dee-bee\fP) is a persistence-enabled
variant of the \fBmemcached\fP distributed key-value storage system. It is
NOT a cache solution, but rather a persistent storage engine for fast and
reliable key-value based object storage and retrieval.
.PP
It conforms to the \fBmemcache\fP protocol, which means that \fImemcached\fP
clients can connect and use the persistent key-value store transparently. It
also provides reliability and high-availability through its transaction and
replication support, courtesy of its BerkeleyDB storage backend.
.SH OPTIONS
.TP
\fC\-p\fP num
TCP port to listen on  (default: 21201)
.TP
\fC\-U\fP num
UDP port to listen on (default: 0, off)
.TP
\fC\-s\fP file
UNIX Domain Socket path to listen on (disables network support)
.TP
\fC\-a\fP mask
Access mask for unix socket, in octal (default: 0700)
.TP
\fC\-l\fp ip_addr
Interface to listen on (default: INADRR_ANY)
.TP
\fC\-d\fP
Run as a daemon
.TP
\fC\-r\fP
Maximize core file limit
.TP
\fC\-u\fP username
Assume identity of \fIusername\fP (only when run as root)
.TP
\fC\-c\fP num
Maximum simultaneous connections (default: 4096)
.TP
\fC\-b\fP num
Item size smaller than \fInum\fP bytes will use fast memory allocation
(default: 2048 bytes)
.TP
\fC\-v\fP
Verbose (print errors/warnings while in event loop)
.TP
\fC\-vv\fP
Very verbose (also print client commands/reponses)
.TP
\fC\-h\fP
Print brief usage instructions and exit
.TP
\fC\-i\fP
Print complete copyright and license information
.TP
\fC\-P\fP file
Save process ID in \fIfile\fP (only used with the \-d option)
.TP
\fC\-t\fP num
Number of threads to use (default: 4)
.SS Berkeley DB Options
.TP
\fC\-m\fP num
In-memory cache size of BerkeleyDB in megabytes (default: 256MB)
.TP
\fC\-A\fP num
Underlying page size in bytes (default: 4096, range: 512B-64KB, power-of-two)
.TP
\fC\-f\fP file
Filename of database (default: \fIdata.db\fP)
.TP
\fC\-H\fP dir
Environment HOME of database (default: \fI/data1/memcachedb\fP)
.TP
\fC\-G\fP dir
Log directory of database (default: same as Environment HOME, see \-H)
.TP
\fC\-B\fP db_type
Type of database, options are: 'btree' or 'hash' (default: btree)
.TP
\fC\-L\fP num
Log buffer size in kBytes (default: 4096kB)
.TP
\fC\-C\fP num
Perform a checkpoint every \fInum\fP seconds (0 to disable, default:
300 seconds)
.TP
\fC\-T\fP num
Do \fBmemp_trickle\fP every \fInum\fP seconds (0 to disable, default:
30 seconds)
.TP
\fC\-e\fP num
Percentage of the pages in the cache that should be clean (default: 60%)
.TP
\fC\-D\fP num
Perform deadlock detection every \fInum\fP milliseconds (0 to disable,
default: 100ms)
.TP
\fC\-N\fP
Enable \fBDB_TXN_NOSYNC\fP for a large performance gain (default: off)
.TP
\fC\-E\fP
Automatically remove log files that are no longer needed
.TP
\fC\-X\fP
Allocate region memory from the heap (default: off)
.SS Replication Options
.TP
\fC\-R\fP
Identifies the host and port used by this site (required)
.TP
\fC\-O\fP
Identifies another site participating in this replication group
.TP
\fC\-M\fP/\fC\-S\fP
Start memcachedb as a master or slave
.TP
\fC\-n\fP num
Number of sites participating in replication (default: 2)
.SH CAVEATS
.IP \(bu 4
Because this is a persistent storage solution, expire time specified in the
corresponding memcache protocol clients will be silently discarded.
.SH FILES
.TP
\fC/etc/memcachedb.conf\fR
.SH SEE ALSO
memcached(1)
.SH AUTHOR
MemcacheDB was written and is maintained by Steve Chu stv...@gmail.com,
based on Memcached by Danga Interactive, Inc. http://www.danga.com/

Cheers,

Jonathan


memcachedb.man
Description: Unix manual page


Bug#609628: Build interacts badly with local::lib (installs Perl modules to local::lib directory)

2011-01-30 Thread Jonathan Yu
I ran into this issue again, so I had it dump out `env' during build
(by adding it to debian/rules).

Here's what I got:

 debian/rules build
env
DEB_BUILD_ARCH_OS=linux
CPPFLAGS=
SHELL=/bin/bash
SCHROOT_COMMAND=dpkg-buildpackage -us -uc -r/usr/bin/fakeroot
_=/usr/bin/sbuild
CFLAGS=-g -O2
APT_CONFIG=/var/lib/sbuild/apt.conf
DEB_HOST_ARCH_BITS=32
CXXFLAGS=-g -O2
PERL_MM_OPT=INSTALL_BASE=/home/jon/.perl5
DEBEMAIL=jaw...@cpan.org
DEB_BUILD_GNU_CPU=i486
SSH_CONNECTION=10.0.1.2 2180 10.0.1.3 22
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/usr/games
DEB_HOST_ARCH_CPU=i386
SSH_TTY=/dev/pts/0
FFLAGS=-g -O2
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_SYSTEM=linux-gnu
PS3=\[\e[1;37m\]? \[\e[0m\]
LDFLAGS=
DEB_BUILD_ARCH=i386
PWD=/tmp
HOME=/home/jon
SCHROOT_USER=jon
PERL5LIB=/home/jon/.perl5/lib/perl5/i486-linux-gnu-thread-multi:/home/jon/.perl5/lib/perl5
SCHROOT_GID=1000
LOGNAME=jon
DEB_HOST_GNU_TYPE=i486-linux-gnu
SHLVL=1
BLOCKSIZE=K
DEB_HOST_ARCH_OS=linux
SCHROOT_UID=1000
DEB_BUILD_ARCH_BITS=32
USER=jon
SCHROOT_SESSION_ID=sid-420d2cc3-fcd7-4880-9f98-b6743e600ccc
OLDPWD=/tmp/libinline-perl-0.48
SCHROOT_GROUP=jon
MAKEFLAGS=
MFLAGS=
SSH_CLIENT=10.0.1.2 2180 22
MAIL=/var/mail/jon
MODULEBUILDRC=/home/jon/.perl5/.modulebuildrc
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
PROMPT_COMMAND=echo -ne \033]0;`hostname -s`: `pwd`\007
PS1=\[\e[0;35m\]\h\[\e[1;37m\]'\[\e[0;32m\]\u\[\e[1;30m\](\[\e[1;33m\]\w\[\e[1;30m\])\[\e[1;37m\]
\[\e[0m\]
EDITOR=/usr/bin/nano
PAGER=/bin/more
LC_ALL=POSIX
DEB_HOST_ARCH=i386
DEB_BUILD_GNU_TYPE=i486-linux-gnu
LANG=en_CA.UTF-8
TERM=linux
PS4=\[\e[1;37m\]+ \[\e[0m\]
PS2=\[\e[1;37m\] \[\e[0m\]
MAKELEVEL=1

Notice these variables (put in by local:;lib -- if these are sanitized
by sbuild, this bug should go away. Perhaps Env::Sanctify can be used
for this purpose?)

MODULEBUILDRC=/home/jon/.perl5/.modulebuildrc
PERL_MM_OPT=INSTALL_BASE=/home/jon/.perl5
PERL5LIB=/home/jon/.perl5/lib/perl5/i486-linux-gnu-thread-multi:/home/jon/.perl5/lib/perl5

I might be in a position to provide a patch at some point...

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608567: ITP: libanyevent-http-perl -- simple non-blocking HTTP/HTTPS client

2011-01-19 Thread Jonathan Yu
Hi Dmitry,

I've actually forgotten about t his module. The changenote log says we
need copyright information for it from the author (though I don't
think I've talked to him about it yet).

I don't remember to what extent I've prepared the package.

Cc: Debian Perl Team, perhaps one of you are interested in finishing
this up? :-)

Cheers,

Jonathan

On Wed, Jan 19, 2011 at 2:46 AM, Dmitry E. Oboukhov un...@debian.org wrote:
 Hi, Jonathan!

 Have You already packaged this module? I need it. Could I get the
 package in any VCS?

 --
 ... mpd is off

 . ''`.                               Dmitry E. Oboukhov
 : :’  :   email: un...@debian.org jabber://un...@uvw.ru
 `. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608560: ITP: libcps-perl -- module to manage flow of control in Continuation Passing Style

2011-01-01 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcps-perl
  Version : 0.11
  Upstream Author : Paul Evans leon...@leonerd.org.uk
* URL : http://search.cpan.org/dist/CPS/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to manage flow of control in Continuation
Passing Style

CPS is a Perl module that enables developers to write code in Continuation
Passing Style, which is a style of writing code where the normal call/return
mechanism is replaced by explicit continuations. It is useful whenever some
form of asynchronous or event-based programming is in use.

This module is required for upgrading IO::Async (libio-async-perl) to
version 0.34



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608562: ITP: libcatalyst-engine-psgi-perl -- Catalyst engine for the PSGI protocol

2011-01-01 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcatalyst-engine-psgi-perl
  Version : 0.11
  Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net
* URL : http://search.cpan.org/dist/Catalyst-Engine-PSGI/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Catalyst engine for the PSGI protocol

Catalyst::Engine::PSGI is a Perl module that provides backend support for the
Catalyst MVC framework on any of a multitude of web servers that comply with
the Perl Web Server Gateway Interface (PSGI) specification.

It is commonly used with the Plack middleware (see libplack-perl).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608565: ITP: libmath-symbolic-perl -- module for performing symbolic calculations

2011-01-01 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmath-symbolic-perl
  Version : 0.606
  Upstream Author : Steffen Müller smuel...@cpan.org
* URL : http://search.cpan.org/dist/Math-Symbolic/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for performing symbolic calculations

Math::Symbolic is a Perl module for performing symbolic calculations, similar
to Computer Algebra Systems (CAS) like Maxima, Maple and Mathematica. Using
this software, algebraic expressions can be parsed from strings, manipulated
in Perl and even compiled into code references.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608567: ITP: libanyevent-http-perl -- simple non-blocking HTTP/HTTPS client

2011-01-01 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libanyevent-http-perl
  Version : 1.5
  Upstream Author : Marc Lehmann schm...@schmorp.de
* URL : http://search.cpan.org/dist/AnyEvent-HTTP/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : simple non-blocking HTTP/HTTPS client

AnyEvent::HTTP is an simple non-blocking HTTP/HTTPS client implementation,
which uses AnyEvent under the hood for asynchronous I/O. It supports GET,
POST and other request methods, cookies and more. It is well suited to most
HTTP tasks, while retaining fine-grained control over request and response
headers to cater to more complex requirements.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608609: ITP: libpackage-pkg-perl -- collection of package manipulation utilities

2011-01-01 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpackage-pkg-perl
  Version : 0.0019
  Upstream Author : Robert Krimen robertkri...@gmail.com
* URL : http://search.cpan.org/dist/Package-Pkg/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : collection of package manipulation utilities

Package::Pkg is Perl module that provides several utility functions useful
for manipulating packages and their subroutines. You can install arbitrary
code references as functions in a given namespace, alias functions from one
package to another, and set up an exporter.

In many respects, this package provides functionality similar to Sub::Install
(see libsub-install-perl) and Sub::Exporter (see libsub-exporter-perl).

NOTE: this package is required for Getopt::Usaginator
(libgetopt-usaginator-perl), which in turn is required for an upgraded
Config::JFDI (libconfig-jfdi-perl).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608086: ITP: libmoosex-multimethods-perl -- Moose extension enabling multiple method dispatch

2010-12-26 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-multimethods-perl
  Version : 0.10
  Upstream Author : Florian Ragwitz r...@debian.org
* URL : http://search.cpan.org/dist/MooseX-MultiMethods/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Moose extension enabling multiple method dispatch

MooseX::MultiMethods is a Perl module providing multiple method dispatch
based on Moose type constraints. When invoking a method declared as multi,
a matching variant will be selected based on the passed parameters and the
declared type constraints.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#597743: libnet-bluetooth-perl: Possible typo in package description

2010-12-25 Thread Jonathan Yu
tags 597743 + pending
fixed 597743 0.40-3
owner jaw...@cpan.org
thanks

This bug is now fixed in a yet-to-be uploaded 0.40-3. The upstream
development looks inactive though, so this might not be uploaded for
awhile (we're not going to push another release just for such a small
fix).

Cheers,

Jonathan

On Wed, Sep 22, 2010 at 1:35 PM, Jonathan Yu jonathan.i...@gmail.com wrote:
 Hi Davide,

 Thanks for spotting the typo and letting us know. Actually, I think
 the description should be rewritten completely, so I'll take a look
 when I have a free moment.

 Cheers,

 Jonathan

 On Wed, Sep 22, 2010 at 1:18 PM, Davide Prina davide.pr...@gmail.com wrote:
 Package: libnet-bluetooth-perl
 Severity: minor

 In DDTSS I see:

 Net::Bluetooth allow to manage Bluetooth features such a device and services
 discovery

 I think it must be:


 Net::Bluetooth allow to manage Bluetooth features such as device and
 services discovery                                      ^
 |

 Ciao
 Davide

 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 --
 Dizionari: http://linguistico.sourceforge.net/wiki
 Client di posta: http://www.mozilla.org/products/thunderbird
 GNU/Linux User: 302090: http://counter.li.org
 Non autorizzo la memorizzazione del mio indirizzo su outlook




 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608001: ITP: libclone-fast-perl -- module for fast data structure copying

2010-12-25 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libclone-fast-perl
  Version : 0.93
  Upstream Author : Trevor Hall wazzut...@cpan.org
* URL : http://search.cpan.org/dist/Clone-Fast/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for fast data structure copying

Clone::Fast is a Perl module for quickly copying (cloning) arbitrary data
structures. Deep references in the structure will refer to the cloned data
structure. It is similar in concept to Storable's clone function, but is
significantly faster since it doesn't need to convert data structures to
and from a binary format.

NOTE: this is needed for Dancer (libdancer-perl)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608024: ITP: libgitalist-perl -- modern Git web viewer

2010-12-25 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libgitalist-perl
  Version : 0.002006
  Upstream Author : Dan Brook b...@cpan.org
* URL : http://search.cpan.org/dist/Gitalist/
* License : unparsable
  Programming Lang: Perl
  Description : modern Git web viewer

Gitalist is a web frontend for Git repositories based on code from gitweb.cgi
and powered by Catalyst (see the libcatalyst-perl package). It extends gitweb
with many advanced features, including:

 * Multiple repository support
 * Multiple branch support
 * Commit comparisons
 * Atom feeds
 * Color coded commit history



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#608024: ITP: libgitalist-perl -- modern Git web viewer

2010-12-25 Thread Jonathan Yu
The license terms for this package are Perl (Artistic + GPL). I just
forgot to fix that before the submission :-)

This upload probably won't happen for awhile, since it is blocked by
the following NEW modules:

  - Catalyst::Controller::ActionRole
  - File::Type::WebImages
  - Template::Plugin::Cycle
  - Git::PurePerl
  - Catalyst::View::Component::SubInclude
  - Catalyst::Plugin::Unicode::Encoding
  - MooseX::MultiMethods
  - Test::utf8

On Sat, Dec 25, 2010 at 11:11 PM, Jonathan Yu jaw...@cpan.org wrote:
 Package: wnpp
 Owner: Jonathan Yu jaw...@cpan.org
 Severity: wishlist
 X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

 * Package name    : libgitalist-perl
  Version         : 0.002006
  Upstream Author : Dan Brook b...@cpan.org
 * URL             : http://search.cpan.org/dist/Gitalist/
 * License         : unparsable
  Programming Lang: Perl
  Description     : modern Git web viewer

 Gitalist is a web frontend for Git repositories based on code from gitweb.cgi
 and powered by Catalyst (see the libcatalyst-perl package). It extends gitweb
 with many advanced features, including:

  * Multiple repository support
  * Multiple branch support
  * Commit comparisons
  * Atom feeds
  * Color coded commit history



 --
 To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/aanlktim5kdy8j9-lv9zoqzvzuh2chgaomavn+8gjc...@mail.gmail.com





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#605282: ITP: libdbix-class-inflatecolumn-ip-perl -- extension for creating NetAddr::IP objects from columns

2010-11-28 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdbix-class-inflatecolumn-ip-perl
  Version : 0.02001
  Upstream Author : Dagfinn Ilmari Mannsåker ilm...@ilmari.org
* URL : http://search.cpan.org/dist/DBIx-Class-InflateColumn-IP/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : extension for creating NetAddr::IP objects from columns

DBIx::Class::InflateColumn::IP is an extension to DBIx::Class which creates
NetAddr::IP (see libnetaddr-ip-perl) objects from column data on-the-fly. It
supports columns stored as an integer or varchar, as well as custom address
classes.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#591974: Looks like we should drop libmojomojo-perl for squeeze

2010-11-25 Thread Jonathan Yu
Hi,

We've spoken to the upstream maintainers, who say that removing the
offending swfupload parts should be okay.

I'll spend some time (hopefully tonight) repacking to remove those
parts. My only concern was that swfupload should be made available in
non-free prior to the removal of those parts from libmojomojo-perl,
and the RFP for swfupload is still outstanding.

I'm not sure how to best proceed. I can certainly remove the swfupload
stuff from libmojomojo-perl, which will close that RC bug, but it
opens another wishlist bug since it's not possible to easily install
the full libmojomojo-perl as per upstream (i.e. MojoMojo +
swfupload).

See: http://lists.debian.org/debian-wnpp/2010/11/msg00070.html (RFP #602253)

Your advice would be greatly appreciated.

Cheers,

Jonathan

On Thu, Nov 25, 2010 at 6:32 AM, Alexander Reichle-Schmehl
toli...@debian.org wrote:
 Hi David!

 * David Bremner brem...@unb.ca [101113 21:58]:

 So I would say not quite yet for removal, but if nothing starts moving
 in the next week or so I would not oppose removal.

 I was looking through open RC bugs and stumbled over this one.  I was
 wondering, if you can report any progress on this bug?


 Best Regards,
  Alexander




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#599139: ITP: libmoosex-nonmoose-perl -- easy subclassing of non-Moose classes

2010-10-04 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-nonmoose-perl
  Version : 0.15
  Upstream Author : Jesse Luehrs d...@tozt.net
* URL : http://search.cpan.org/dist/MooseX-NonMoose/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : easy subclassing of non-Moose classes

MooseX::NonMoose allows for easily subclassing non-Moose classes with Moose,
taking care of the annoying details connected with doing this. It tries to be
as non-intrusive as possible - when this module is used, inheriting from
non-Moose classes and inheriting from Moose classes should work identically,
aside from the few caveats mentioned below.

NOTE that this package is needed for upgrading of
libdbix-class-schema-loader-perl



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#597743: libnet-bluetooth-perl: Possible typo in package description

2010-09-22 Thread Jonathan Yu
Hi Davide,

Thanks for spotting the typo and letting us know. Actually, I think
the description should be rewritten completely, so I'll take a look
when I have a free moment.

Cheers,

Jonathan

On Wed, Sep 22, 2010 at 1:18 PM, Davide Prina davide.pr...@gmail.com wrote:
 Package: libnet-bluetooth-perl
 Severity: minor

 In DDTSS I see:

 Net::Bluetooth allow to manage Bluetooth features such a device and services
 discovery

 I think it must be:


 Net::Bluetooth allow to manage Bluetooth features such as device and
 services discovery                                      ^
 |

 Ciao
 Davide

 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 --
 Dizionari: http://linguistico.sourceforge.net/wiki
 Client di posta: http://www.mozilla.org/products/thunderbird
 GNU/Linux User: 302090: http://counter.li.org
 Non autorizzo la memorizzazione del mio indirizzo su outlook




 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#597364: debian-maintainers: Add Jonathan Yu jaw...@cpan.org as a Debian Maintainer

2010-09-18 Thread Jonathan Yu
Package: debian-maintainers
Severity: normal


Contents of add-F3C2F688A21CB648 follow:

Comment: Add Jonathan Yu jaw...@cpan.org as a Debian Maintainer
Recommended-By:
  Russ Allbery r...@debian.org,
  Obey Arthur Liu art...@milliways.fr
Agreement:
  http://lists.debian.org/debian-newmaint/2010/09/msg00036.html
Advocates:
  http://lists.debian.org/debian-newmaint/2010/09/msg00037.html
  http://lists.debian.org/debian-newmaint/2010/09/msg00038.html
Date: Sat, 18 Sep 2010 18:45:48 -0400
Action: import
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.10 (GNU/Linux)
  
  mQINBEruEj8BEADDYcMwQVJ3/pU+cLbjhR1SaH0jimUnpevUEuKokScwnE13R19U
  D6MNOiyLSsFecUTWFsBbAn2W3oM4jArnfGXzdCZYAJKpN8nGJ0wohBdsAxn5ShDc
  s1VDV5axkbpNdAoKueyOPjdYeydPLpSAGtgiLI8GomslO9dX8vxs3o58yVJYHDpx
  O9X7JNrI9paxZ13+u3YfVtkbQhzUx2J1BJRZUBw/uoQi5tgXDYid/NC+RAVQV2Av
  Ra56iDCQwoX38X53QdlbZ4escVx36uQBHRb/8KR9kklhzhWa3KPK+c4gNgG9kIX2
  NZxTIqP4x6goGJdzkA/0OTjWAQD7L7Ju3pMzQv/Zs5ciaql1nlO0CqLeQyebxKWF
  43WuGFqZ+3DfBfVkEpgVawSn2H2ngWGuMwm/4qr+UUOUVGyZHe1TrR0q0fKR3Q3l
  PS5/tPG+1oDgVFelENbdBMOZuhqqY9guEQ6V4RwnGOr5FeIaiaIbhfQE73dp/dMD
  ChLQivJY6B7c22eyZ/YkN66Lv0rDL8yn1YeEagLszffgpOBah92+jKVRPeE7jkUS
  eXni72OuOaxZclFMCqs13gChe9CHviCo0/+PgNJ7WZ33hTbfRASVF5Q5+JvEPVHr
  g/ZlqXWR67tfTfmYo/4MjZ+o4X1azfeHQVUr1bUzMncmqX8yHt5U+v0wWQARAQAB
  tCVKb25hdGhhbiBZdSA8am9uYXRoYW4uaS55dUBnbWFpbC5jb20+iQI6BBMBCAAk
  AhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheABQJK7iXsAhkBAAoJEPPC9oiiHLZI
  R00P+wXSAqS6JOolNIJqPaQ8xTgSFLWh5BK4SW9+3Gm3G+WU7/eJpZ9o3Vi5o4kr
  EFYpRO0SEsPN0hIsWabdZ/zrH8En3QKxdqJj8S3wUqSG3RCYE/uxI7Hy+Df1Ge5M
  YBB3D6+MMVZQhr9DQmaGJ4kZ8Qh8ZZZ8rkkF/UDKqy0ArBvQgTGw1sNp5WF2vVC7
  IKpOJNnscrSu0G0zcFSqhPWrcmcOeu35SiKNnz3/qj7TMqEzswHEbInMxdyX4/HT
  VtbymHcqu9hbXkLfyUmpaYMpNczM91Z9x5D4NEe4ICoiWtQNn7a8KHgOE0ETmm3i
  vBFKUIs7Oz6FkdcKIR4ztkC6m9z9fs18yqAfLULumb1lV3BFOWm3ahJJDzDbZZdq
  4cvxeZjtWav5rKByww0KmDvrqZCqw4+iiqVMdU0BcoJ6F+MhIu75CnZLw5473sgN
  Coa+czxtZkzCzujFabmZl0Am+5oYP8Sc3bj2aQzEWIO4fj18PitSKT3s4j8VuW13
  4zWrm1L3P2cc3RAwQ2tGZDpJ+Ru9Z79MwyCrkDgh7MTf+U7YI0udY75x/cjZ2BaO
  +RDXWS0vLCBrLmrUnPvJCNStqVfCpl9YO8gNJXE+4ygMwpoYM1nqYTxrov1xZ+aQ
  IDvjrjWo/MaDflRHAWibUiTqpGt0wGSQWcMwKb0hrvzRo6+QiEYEEBEIAAYFAkru
  JTAACgkQYYN9T93mai/EeACfW8kSPgt68hMv0XgDZWHerQmTjuwAnR7JAHgVOF8t
  QFOVl3pC+RJAMMXKiGsEEBECACsFAkruV5UFgwHihQAeGmh0dHA6Ly93d3cuY2Fj
  ZXJ0Lm9yZy9jcHMucGhwAAoJENK7DQFl0P1YXvsAoIxXwiqx2f1LEkhQYUiRkqeR
  6SZCAJ0VobbEaYHWR3z2UvxPF7xYueU7ZokCNwQTAQgAIQUCSu4SPwIbAwULCQgH
  AwUVCgkICwUWAgMBAAIeAQIXgAAKCRDzwvaIohy2SLo4D/9jr0yxINcsLB2nnZMS
  r0SS6KYUiFzuSoRrIXMn4bbRLxm0oOrHN2Uym+ZJwtrZ99nxxNH8wrmsHdU5RwsS
  A29wTiBQtz6ONCR2yR3Ac570D8aYKQnY1OPkN/8HyDeW9WLSYgP5RsGWgqtUJer5
  L87NjbIC/N5uQvwoz0F60/S+w5GfeMDFDZCJ0fexD342bYNGiDJsfajZIMKolL0Y
  Si0jEVG3blfVJANCFHLspxtcouErG1PDT4KrarFfW4nIYjznYDvnjxbP0yCIJw/e
  OSlDM7D/Tfglml+Ni+aZtDwYD5t4CKR4+ExHtkDNNyNW+tT8PKiYai8PelVXJWTM
  +vNGY1TNcsSaUQxdOXITcJJoREQqIg4zQP/PRDIJFs1Kc8evMcCnrvwZ8bXK4Ewc
  2/8+lYcFIAVZdLzKlWMphymArPwT5IU8LoI8LCRZ06vnZs+0ALYQdPifksPZTLmW
  EOcEyZZu9xZbj8CI0VAVq3+7w5IxrGaXiTOBs/6IpYsbGg1mB6gLaROh6NN3KCY1
  8z6S/a6jF8Awh7JB4C0K2cQKUsTmK79twahkjsH+lWEF1FnpbjAfMrTOikddYH46
  QC7tztBoAN54DaKhLFhgLWO32RwI0oduP3Gu0smSjQYkbECMMnW5WaEDDutXmcWv
  8Pl/6WLoqbVf1Be/jcfZt4wMZYhGBBARAgAGBQJMRg8bAAoJEGM7hShReOKlzk4A
  n03L9F7foDhFxDpLyh9rtPCd3p5qAJ0Y7vk1JxTFDeh9O9W05WfurA6uFIhrBBAR
  AgArBQJMSt2iBYMB4oUAHhpodHRwOi8vd3d3LmNhY2VydC5vcmcvY3BzLnBocAAK
  CRDSuw0BZdD9WAtkAJ9BqyOvFCZTXNLyp4lFP7g0PcxVAACfTyZjTgaXfLdtcZ+P
  5x2wH24/BE60IEpvbmF0aGFuIFl1IDxqb25AbHVtaW5lc2NlbnQuY2E+iQI3BBMB
  CAAhBQJK7iNJAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEPPC9oiiHLZI
  8OMP/1oPVUBqyTipPRs9XUpsEM71MZlzEHvR0PsrM8mR0hQgfoSlBZxBVN9kkugT
  Gdb8HN1xb2insPAEPo+VrdhUw+DkZArLLQz2DG51TM5524BQ/mMBXhpTaNvzvQqg
  xEjRXuOx8XHArVI8KritRBvViO2pfUtCxrOjUwBZQd1NBE1UZO9A3qSVt5ryuB4x
  66iufEMUhjJS3SHWYLhQfhancRAFvb76TWutkCvuwFcIFjVbe1kWUfZmFIoLHKHq
  4viCe5o+LZe0BQ8fkACBh/GQRSo7/4h/vUkUP59iWbGfm7pmhx0zNSGyvZHuCm0g
  sqXvDjZPPE3oFEntFrZRgDQX8H1ItXigWiQxoKibnDhtAYr29+78ANmsst4/a/6i
  0lVdrJAIjuvvYR2uMBEIp9UH8cqRdpcnlk8O12CLm3qDD7avpFjuraxck6/B2jDn
  3bU2MjDDEB1d5JxhxDHmS2QLF1sauaCC5dB/RINKkZXlWIi/kXLtC4ouySBTsGa+
  i/69UTxUbyQ1zq8TnyGjOwvLNqLHeIYZrAaEt66cgXpIc1E4Lxc4EsuQlPTsggSR
  DzGsSWvjPTqdwAOjuQGmk9pQwESa8fOMNMfPWuaM0gQFgFut+rI/NYc08EqUCjyL
  A0/eL4fHo74L9wjHAGDkOrImKRGbHpQNbBWzAUJm54/KkycWiEYEEBEIAAYFAkru
  JC8ACgkQYYN9T93mai8uqQCdEvQfYTn1KP8NO+ylc4I614yaejgAoIEPfSUwzhOH
  FSS66PISwMl/Sa5ziGsEEBECACsFAkruV5UFgwHihQAeGmh0dHA6Ly93d3cuY2Fj
  ZXJ0Lm9yZy9jcHMucGhwAAoJENK7DQFl0P1YeE8AmwUVUnTvp7TfldSdmyTyYTcW
  uOJUAJ92++MmEE/pDwe/drQGXpp6Mi7X/4hrBBARAgArBQJMSt2iBYMB4oUAHhpo
  dHRwOi8vd3d3LmNhY2VydC5vcmcvY3BzLnBocAAKCRDSuw0BZdD9WFz5AJ4jRzIY
  B/QgJ+daViO1nzLLZ05bUwCfehGTCSAGlOsdpKD+T8ba+wPTBhK0HkpvbmF0aGFu
  IFl1IDxqb25AaW1hZ2luYXJ5LmNhPokCNwQTAQgAIQUCSu4jyAIbAwULCQgHAwUV
  CgkICwUWAgMBAAIeAQIXgAAKCRDzwvaIohy2SEiTD/9XO3Rnf8yCqGP+IfKHH7oY
  HycTeUq7LxnOkM8W0YLl2jgkbN+Hbj2qCqI+mq2OBp3U3o02/gUmoL11L/9peXpT

Bug#592506: What to do about libtest-harness-perl?

2010-08-21 Thread Jonathan Yu
Hi,

On Sat, Aug 21, 2010 at 10:03 AM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 Why has Build.PL become NotBuild.PL?

I'm not the author here, but my guess is that Build.PL was renamed so
that Makefile.PL would be the preferred version, perhaps due to a bug
with some interaction with Module::Build that they're investigating.

I think that Debian packages are all built by Makefile.PL anyway
(regardless of the presence of Build.PL, unless it is the only one of
the two present, or unless we use an override to change the
buildsystem)... so this means the change shouldn't affect us at all.

Of course, this stuff requires closer inspection, and I've been out of
the packaging game for awhile now :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578518: Status on libmojolicious-perl ITP?

2010-06-26 Thread Jonathan Yu
Hi everyone:

Thanks, Jonas, for reminding me about that package. What happened was
I had told the upstream people about changes we needed, and I guess
they didn't get around it for awhile. We had version xxx24, this
problem was fixed in xxx25, and the current version is xxx26.

I've updated the package in our repository and it appears good to go.

If, in the future, you wish to take ownership of it/maintain it with
CDBS, feel free to do so. I don't currently have much time to
dedicated to Debian Perl stuff (due to $day_job), though as you can
see I try to make some time here and there.

Cheers,

Jonathan

On Sat, Jun 26, 2010 at 8:08 PM, gregor herrmann gre...@debian.org wrote:
 On Sat, 26 Jun 2010 18:40:44 +0200, Jonas Smedegaard wrote:

 My packaging is on behalf of the Perl team, but one possible
 issue could be that I use CDBS which Jonathan might not favor.
 In practice this means that hardly anybody will touch the package,
 but that's nothing new and not the first package in this situation :)
 ...so it seems you do care after all ;-)

 I tried not to, but maybe I did :)

 It is not the first time I hear the meme of hardly anyone using
 CDBS.  That is not my experience, but whatever...

 Just my experience with CDBS packages in the pkg-perl group over the
 last years ...

 I shall not infect the pending libmojolicious-perl package with my
 weird packaging preference, but just cross my fingers that some
 ordinary Debian Developer pay some interest in it instead.

 Let's see what Jonathan says; maybe he's happy with the takeover or
 has some other informations ...

 Cheers,
 gregor

 --
  .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
  : :' :  Debian GNU/Linux user, admin,  developer - http://www.debian.org/
  `. `'   Member of VIBE!AT  SPI, fellow of Free Software Foundation Europe
   `-    BOFH excuse #230:  Lusers learning curve appears to be fractal

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIcBAEBCAAGBQJMJpaSAAoJELs6aAGGSaoGHeYQAJlbVbuQ6QJik3zZer69Z/Mn
 qIpA4oBIPg/qmzMIsCq1rmDJU8h2r5qw1TOxmAlQcCpkFLAFESCg79eUKLoK2Yfq
 aAyqjSm7h7HNMnzoihAS9SWtRNLBdV+nz3is1xWL5VBIOa1nT/xCvECdXHKh9Ixa
 JvxQiMC3Bw/pIJSZQKmtjfdxqhccfp9xypGcDvJxfZNJp9oqE4d+NbtCIbEOWj2x
 klYGsbnz7N6vhl20WEN5Pw8xThpw5YFWbd9Cegn5pCwlI8X31RwlqXgw1CrCbQ6P
 2hjY/WrSyIH66AUiCgzvZNerCOTC9Z9tDJ99Qg/GRJWxf9mOfRGS0Jj0WZ5kPD5J
 Ckln9nK45ZTE/8S0j3t8p5WGGrInLsMElJaVvG9xC0RlnpC1kfj7RKFHjfAAF5Uq
 1Wv22jSyeE/ETyTC8rCWxPnKYsdh0FN0AoMpru4k3bBaJtMSYVy3bj3emOi3ZoLm
 esySEihjV7L1OpjFnjLXTdhLF9UwtHvGxcK6w8o3mXIeecoqDZHqLJLXSWyoyEli
 JOGXv9TwOF23OTSugJfO7YZ2nrhx2MWO6WxfSn4jD4YzBAqwyry8V906BrxWVA4C
 AGLVND2XKxOrPMWr8wmZg5D6lYr/mC4teDc8PJfcOstwOZ4DE6iZJ3x5VTNxIONw
 c7SKjdFflIjnWp8Ma2jd
 =2ccQ
 -END PGP SIGNATURE-





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#582833: RFP: valadoc -- documentation generator for generating API documentation from Vala source code

2010-05-23 Thread Jonathan Yu
Package: wnpp
Severity: wishlist


* Package name: valadoc
  Version : ? (unknown, version in git available)
  Upstream Author : Florian Brosch flo.bro...@gmail.com 
* URL : http://live.gnome.org/Valadoc
* License : GPL-2
  Programming Lang: Vala (GNOME GLib + GObject meta-language)
  Description : documentation generator for generating API documentation 
from Vala source code

valadoc is a program similar to javadoc and others, for providing
in-line API documentation. It is written in vala and available from
the GNOME git repository:

  $ git clone git://git.gnome.org/valadoc

It is unknown whether this package belongs in vala-utils, vala-doc,
or neither. It is not written nor supported by the GNOME development
team or the Vala people.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#551926: [Python-modules-team] Bug#551926: cannot be installed together with pip or pip-python

2010-05-08 Thread Jonathan Yu
Hi,

On Sat, May 8, 2010 at 4:51 AM, Sandro Tosi mo...@debian.org wrote:
 I think the issue has been open for long enough without clear consensus.
 Hence all packages should rename their /usr/bin/pip to something else and
 document the difference vs upstream in README.Debian.

 BTW, finding new names is hard, but choosing a 3 letter acronym is a
 recipe for problems...

I don't want to keep beating this dead horse, but the position from
the Perl community is that:
1. We picked the name 'pip' first (the release of Perl's pip precedes
Python's pip)
2. The author of Python's pip was informed of the naming conflict on his blog
3. The author chose to ignore it

And now we're in this mess. So, either the author is a jerk, or he
just didn't think anyone would be installing both on the same system.
But as we have the 'pip' package name, I think it is fair we get the
'pip' script name.

I see no reason for Perl's pip to have to change its name, simply
because the author of Python's pip chose a name which was already in
use by someone else, and because the author was already informed that
something like this might happen, and chose to proceed anyway.

 of course I'm s little biased on this, but I'm attending Pycon italia
 and 2 talks (over the 4 given by know) already provide explicit
 references to pip and also about how to use it (that's as simple as
 pip install module).

What happens if someone releases a script called 'sh' and wants to
install it to /usr/bin/sh? Despite being informed that obviously it
conflicts with peoples' shells. I consider this a similar problem, but
on a much smaller scale (obviously Perl's pip is not as popular as
sh), but the point is still valid.

 would be another source of frustration for the python community
 willing to use debian (and that community is already being harmed
 several times).

Rather than cripple Perl's pip, if it's really not in use by anyone, I
think we should just remove the pip package and let Python take over
the name and /usr/bin path. But if it is in use, then given the author
of the Python script had advance warning, I think the Python
community effectively did this harm to themselves.

I do not think it is unreasonable to think of script names the same as
module names, as: on a first-come, first-served basis -- it is the
responsibility of each author to do a search to make sure they are not
picking the same names as anyone else. Not only did he fail to do
adequate research, he failed to predict this would happen and change
the name accordingly.

In summary: if we do not need the Perl version, remove it. If we need
the Perl version, its name should stay as 'pip'. This decision should
be made irrespective of Python's pip, because Perl's pip came first
(so I think it deserves that privilege).

Cheers,

Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#580683: libjs-jquery: add several jQuery plugins to this package

2010-05-07 Thread Jonathan Yu
Package: libjs-jquery
Severity: wishlist


Hi,

First, let me mention that I do not actually program with jQuery,
so I'm not sure how it works. So if I'm completely off-base with
this bug report, I ask for your forgiveness.

There are several files which appear to be plugins for jQuery,
which are not found in your bundle. Subsequently, they appear to
be duplicated several times in different packages. Including them
in your library is probably a good thing, since it will ensure a
new version is used.

That being said, I'm not sure if these are configuration files of
some sort for jQuery. So feel free to close the bug report.

Some basic investigation yields the following packages have
filenames:

=== jquery.autocomplete.js

mediawiki-metavidwiki: 
/usr/share/mediawiki-metavidwiki/skins/mv_embed/jquery/plugins/jquery.autocomplete.js
python-django-extensions: 
/usr/share/pyshared/django_extensions/media/django_extensions/js/jquery.autocomplete.js
webgen0.5: /usr/share/webgen/webgui/public/js/jquery.autocomplete.js
(also the upcoming libmojomojo-perl, which is why I noticed this)

=== jquery.livequery.js

nothing yet, but is used in the upcoming libmojomojo-perl, which I
am currently packaging for Debian.

=== jquery.form.js

couchdb: /usr/share/couchdb/www/script/jquery.form.js
drupal6: /usr/share/drupal6/misc/jquery.form.js
jpoker: /usr/share/jpoker/js/jquery.form.js
sagemath: /usr/share/sagemath/dsage/static/jquery.form.js
spip: /usr/share/spip/prive/javascript/jquery.form.js
wordpress: /usr/share/wordpress/wp-includes/js/jquery/jquery.form.js
(also the upcoming libmojomojo-perl)

=== jquery.cookies.js

couchdb: /usr/share/couchdb/www/script/jquery.cookies.js
(jquery.cookies.2.0.1.min.js is used in libmojomojo-perl)

=== jquery.editinplace.js

nothing yet, but is used in the upcoming libmojomojo-perl

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

libjs-jquery depends on no packages.

Versions of packages libjs-jquery recommends:
pn  javascript-common none (no description available)

libjs-jquery suggests no packages.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#580533: ITP: libtest-notabs-perl -- module for scanning for hard tabs in files

2010-05-06 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtest-notabs-perl
  Version : 1.0
  Upstream Author : Tomas Doran bobtf...@bobtfish.net
* URL : http://search.cpan.org/dist/Test-NoTabs/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for scanning for hard tabs in files

Test::NoTabs is a Perl test module that scans your project/distribution for
any Perl files (scripts, modules, etc) that contain hard tabs (the \t, or
0x09) character. Tabs can render with slightly different width depending on
the author's environment, so it's best to use spaces instead.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#580588: RM: libtext-query-perl -- ROM; no reverse dependencies, no maintainer (previously orphaned)

2010-05-06 Thread Jonathan Yu
Package: ftp.debian.org
Severity: normal


I was taking over maintainership of this module, but it turned out
that the one place it was formerly used (gpsdrive-scripts) wasn't
actually using it. So I nominate this package for removal.

This was discussed on the debian-perl list; here are the reasons
I proposed initially:
I am nominating libtext-query-perl for removal from Debian, for the
following reasons:

1. It currently fails to build with tests enabled (the package in
Debian right now, not maintained within the group get, but orphaned by
its original maintainer, gets around this by simply skipping the
tests)

2. Test failures are not a Debian-specific issue, either, and I don't
think it can be fixed without some substantial patches; CPAN Testers
reports PASS (61)   FAIL (84)   UNKNOWN (1). We are getting errors
similar to: http://www.cpantesters.org/cpan/report/5711283 -- and I'm
sure many of these other reports are the same:
http://www.cpantesters.org/show/Text-Query.html#Text-Query-0.07

3. The last upstream release was in 1999 (over ten years ago...)

4. The package has no maintainer (I am willing to step in to adopt the
package, but without any active upstream this seems like a bad idea)

5. There have been 3 open bugs in the upstream request tracker (well,
four, but one is duplicate) for over two years:
https://rt.cpan.org/Dist/Display.html?Name=Text-Query

6. Popcon score for libtext-query-perl is pretty high - 510 installed,
76 vote. This is probably due to it being a dependency of gpsdrive,
which has a popcon of 530 installed, 91 vote. It should be noted that
libtext-query-sql-perl (the other package which depends on
Text::Query, and written by the same upstream author) has a
significantly lower popcon score.

Full discussion here:
http://lists.debian.org/debian-perl/2010/02/msg00035.html



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#580589: RM: libtext-querysql-perl -- ROM; no reverse dependencies, no maintainer (previously orphaned)

2010-05-06 Thread Jonathan Yu
Package: ftp.debian.org
Severity: normal


Please see the bug report filed for libtext-query-perl. The same
rationale should be applied here.

A discussion happened on the debian-perl list and was archived:
http://lists.debian.org/debian-perl/2010/02/msg00035.html



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#580353: ITA: libkinosearch-perl

2010-05-05 Thread Jonathan Yu
Package: wnpp
Severity: normal
Owner: Jonathan Yu jaw...@cpan.org
X-Debbugs-CC: debian-p...@lists.debian.org

Hi,

I am adopting this module after receiving permission from the current
maintainer.

-- Forwarded message --
From: Dominic Hargreaves d...@earth.li
Date: Thu, Mar 18, 2010 at 6:19 PM
Subject: Re: Future of KinoSearch in Debian
To: debian-p...@lists.debian.org


On Thu, Mar 18, 2010 at 04:48:16PM -0400, Jonathan Yu wrote:
 Hey Dominic,

 Thanks for speaking up. I'd also like to adopt KinoSearch under the
 group if you don't mind. Though you seem to be doing a good job
 maintaining it, so I won't press you further if you'd like to keep it.
 I just think it'd be nicer to keep all of the KinoSearch versions in
 the same place, as it makes coordinating things easier.

 [Only Cc'd the Debian Perl List this time, as I guess debian-devel doesn't 
 care]

Sure, go ahead. I should have included that explicitly in my previous
mail I guess :)

Cheers,
Dominic.

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


--
To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100318221935.gj4...@urchin.earth.li



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#580375: ITP: libkinosearch1-perl -- Perl library providing search engine features

2010-05-05 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libkinosearch1-perl
  Version : 1.00
  Upstream Author : Marvin Humphrey mar...@rectangular.com
* URL : http://search.cpan.org/dist/KinoSearch1/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl library providing search engine features

KinoSearch is a loose port of the Java search engine library, Apache Lucene.
It is written in Perl and C, designed primarily for providing website search
functionality, but it can be put to many different uses.

It has the following features:

 * Extremely fast and scalable: KinoSearch can handle millions of documents
 * Incremental indexing (addition/deletion of documents to/from an existing
   index)
 * Full support for 12 Indo-European languages
 * Support for boolean operators (AND, OR, and AND NOT), parenthetical
   groupings, and prepended +plus and -minus
 * Algorithmic selection of relevant excerpts and highlighting of search
   terms within excerpts
 * Highly customizable query and indexing APIs
 * Phrase matching
 * Stemming
 * Stoplists

KinoSearch1 is derived from KinoSearch version 0.165 and is considered
the stable upstream branch.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578901: libvideo-fourcc-info-perl: FTBFS with newer Module::Build: MYMETA.yml and MANIFEST

2010-04-23 Thread Jonathan Yu
Hi,

Surely this issue causes upstream failures too. I'll fix it for a
subsequent release (upstream) when I have time. It's because
MANIFEST.SKIP is missing MYMETA.yml (if it is patched to include that
file, it will work too). This is due to perl 5.10.0 not having
MYMETA.yml files, but the toolchain shipped with 5.10.1 and newer
does, so this also affects 5.12.

I will fix this probably in a week or so. I've got two last exams, one
tomorrow morning and one on Wednesday.

Cheers,

Jonathan

On Fri, Apr 23, 2010 at 9:55 AM, Damyan Ivanov d...@debian.org wrote:
 -=| Niko Tyni, Fri, Apr 23, 2010 at 03:50:55PM +0300 |=-
 Package: libvideo-fourcc-info-perl
 Version: 1.004-1
 Severity: important
 User: debian-p...@lists.debian.org
 Usertags: perl-5.12-transition

 This package fails to build with newer versions of Module::Build,
 including libmodule-build-perl_0.360700-1 in sid and perl_5.12.0-1
 in experimental.

   # Distribution files are missing in MANIFEST:
   # MYMETA.yml

   #   Failed test 'All files are listed in MANIFEST or skipped'
   #   at t/01manifest.t line 34.
   # Looks like you failed 1 test of 4.

 Maybe we should not run MANIFEST tests during package build? MANIFEST
 correctless has nothing to do with the package, right?

 Not sure how to achieve it, though.

  (1) Build-Conflict with libtest-distmeta-perl (dh-make-perl refresh
     can be tought to do that)?

  (2) Drop AUTOMATED_TESTING=1 (co) from debian/rules?

  (3) Another approach could be to patch Module::Build to not refresh
     META/create MYMETA unless asked to.

 My preference goes with (2).

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQIcBAEBCAAGBQJL0abZAAoJEOQbTFV/DYC+458QAKp8Ebp5KZsZrufqeunr4EZj
 WW8WjZ2az9Mpq2yaGEGvdDCj3CZ122/N1MkaLpuwutzrufH5R2TOTvVBoicoHSx0
 YpJwv3piVlbtuDdr6+67EFdKI/kUHiw6XewN9xac2+6zE7yL6AydxSLcLQ3hGQjq
 p9J8kwrw8qDqlJkcUZULIkQPwqCiQ98xgK1MQuUo899K5KAvYVmxR/n+XCiePkdd
 ceAfu6kgu13ek71EEaHK8yk44zL0BnBBUfNZuC9LiLPVWTefyZY0Q97voo0d0t2M
 UpJR9GZD/zgmBJVORYy1eGElRE8epch/v5+EZf/lD91lbkGmlJkqTvG4GrWVzMHs
 /UK4KY7R5MXj0X5mKKm7vdhc5/VKQePo/k4DmrW7wibQTMqDv8pI+aFbZMf9L90n
 Y7IxHH/7XDTAnukkc3YZ2fT5Vu76yDi6Ck+fHUUTR5WSYIE2UgCXX1WFu2QgXt+x
 f2fpq4pOUgCshdC4rBBrqFbxGsg0jFKlT7iOodciRqlOV+BfwSUi77QO8ve9mDw2
 OQtwRVJmbvN6FdDoqG/lZ8xOSxbBlQcsFqbqG52W6QNhqQrnGzPvQkbi4MUZsfWc
 GQ1jnafbN+W+mYSd0mwqXuArqAI+V909bUz5F0Dzyn6iGzA9HoRyPNCwZ106H2nn
 ROdkl9qVodmt7F/T4w1O
 =84zN
 -END PGP SIGNATURE-

 ___
 pkg-perl-maintainers mailing list
 pkg-perl-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578411: ITP: libmusicbrainz-discid-perl -- Perl interface to the MusicBrainz libdiscid library

2010-04-19 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmusicbrainz-discid-perl
  Version : 0.03
  Upstream Author : Nicholas J. Humfrey n...@aelius.com
* URL : http://search.cpan.org/dist/MusicBrainz-DiscID/
* License : GPL-2+
  Programming Lang: Perl
  Description : Perl interface to the MusicBrainz libdiscid library

MusicBrainz::DiscID is a Perl interface to the MusicBrainz libdiscid library.
It is useful for calculating a MusicBrainz DiscID from an audio compact disc
in the drive. The coding style differs slightly from the C library as this
module supports Perl's Object-Oriented programming features.

This module was informally RFP'd via the mailing list. I have Cc'd the
requestor (Kurt Roeckx) to this bug submission. See also:
http://lists.debian.org/debian-perl/2010/04/msg00010.html



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#577045: libmodern-perl-perl vs libmodern-perl

2010-04-18 Thread Jonathan Yu
On Sun, Apr 18, 2010 at 2:18 PM, Ivan Kohler ivan-deb...@420.am wrote:
 Originally I had uploaded libmodern-perl-perl by accident and was
 surprised it made it through NEW.  I was planning on asking for removal
 (and for libmodern-perl to be renamed to or Provide:
 libmodern-perl-perl).

 However it seems that David Moreno da...@debian.org may be MIA-ish?
 (The most recent activity I can find is an upload of libxml-treepp-perl
 on 2009-08-26?)

 So I am considering just running with libmodern-perl-perl (via pkg-perl
 svn) and asking for libmodern-perl's removal.

 Any objections?
I fully agree with this course of action, as long as you're careful
that reverse dependencies of libmodern-perl are identified and fixed.
Otherwise, we can also provide a temporary dummy package, but I think
getting the reverse dependencies fixed should be our priority.

 --
 _ivan


 --
 To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20100418181800.gc13...@420.am





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#577045: libmodern-perl-perl vs libmodern-perl

2010-04-18 Thread Jonathan Yu
On Sun, Apr 18, 2010 at 3:00 PM, Ivan Kohler ivan-deb...@420.am wrote:
 On Sun, Apr 18, 2010 at 02:42:08PM -0400, Jonathan Yu wrote:
 On Sun, Apr 18, 2010 at 2:18 PM, Ivan Kohler ivan-deb...@420.am wrote:
  So I am considering just running with libmodern-perl-perl (via pkg-perl
  svn) and asking for libmodern-perl's removal.
 
 I fully agree with this course of action, as long as you're careful
 that reverse dependencies of libmodern-perl are identified and fixed.
 Otherwise, we can also provide a temporary dummy package, but I think
 getting the reverse dependencies fixed should be our priority.

 There are no reverse deps.  I'm guessing Replaces: libmodern-perl
 should be sufficient for unstable/testing folks that have
 libmodern-perl installed?
I believe it both Replaces libmodern-perl (that means files in
libmodern-perl-perl overwrite ones in libmodern-perl) and Provides
libmodern-perl (ie, a virtual package). Depending on what is needed,
transitional empty binary packages may be needed as well. But if there
are no reverse deps we don't need to bother with any of that, simply
removing libmodern-perl should be good..

 --
 _ivan


 --
 To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20100418190036.gd13...@420.am





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#576907: ITP: libplack-perl -- interface between web servers and Perl web applications

2010-04-08 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libplack-perl
  Version : 0.9929
  Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net
* URL : http://search.cpan.org/dist/Plack/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : interface between web servers and Perl web applications

Plack is a set of tools similar to Ruby's Rack or Python's Paste for WSGI. It
implements the Perl Server Gateway Interface (PSGI) standard interface, which
allows developers to decouple their web application framework from the local
web server environment.

This package contains middleware components, a reference server and utilities
for web application frameworks.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#576912: liblog-dispatch-perl: new upstream version available

2010-04-08 Thread Jonathan Yu
Package: liblog-dispatch-perl
Severity: wishlist


While packaging Plack (libplack-perl), the tests optionally used
Log::Dispatch::Array if available. The test explicitly depends on
version 2.25 or better of this module (current upstream is 2.26).

Here is the changelog between the existing version in the archive
2.22 and 2.26:

2.26 Sep 22, 2009

- Doc updates. The 2.23 constructor API was still shown in all the output
  subclasses. Fixed by Jon Swartz.


2.25 Sep 15, 2009

- Added a workaround for a weird tainting issue with Params::Validate. This
  caused a taint exception when a Log::Dispatch::Syslog was created under
  taint mode. Note that there is still a problem in Params::Validate itself,
  this is just a hack.


2.24 Sep 13, 2009

- Simplified new constructor API (the 2.23 API is still silently supported but
  not documented):

  Log::Dispatch-new( outputs = [ [ 'File', ... ],
   [ 'Screen', ... ],
 ]
);

  Implemented by Jon Swartz.

- All of the mail sending modules now warn unconditionally if sending mail
  fails. This removes the incorrect use of warnings::enabled() in some
  modules. RT #43516.


2.23 Sep 12, 2009

- New constructor API that simplifies creating your Log::Dispatch object.
  Implemented by Jon Swartz.

- Made name parameter optional. We now auto-generate a unique name if one is
  not given. Implemented by Jon Swartz.

- Added a newline parameter that causes a newline to be added to each message,
  and updated the documentation regarding newlines. Implemented by Jon Swartz.

- Removed repetitive boilerplate documentation from each output
  class. Implemented by Jon Swartz.

- The level_names and level_numbers used internally are now computed once and
  shared between output objects. Implemented by Jon Swartz.

- Updated repo url - now at http://hg.urth.org/hg/Log-Dispatch

- Explicitly depend on Sys::Syslog 0.16.

- Added warn as a synonym for warning. RT #44821. Requested by Dylan Martin.

- Added an add_callback method to Log::Dispatch and
  Log::Dispatch::Output. This lets you add a new formatting callback after an
  object is created. Based on a patch from Ricardo Signes. RT #48283.

- The Log::Dispatch docs mistakenly told you to provide a log() method when
  creating a new output class. RT #40561.

- Made all modules have the same version as Log::Dispatch itself.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#576964: ITP: libchart-clicker-perl -- module for powerful, extensible charting

2010-04-08 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libchart-clicker-perl
  Version : 2.60
  Upstream Author : Cory G Watson gp...@cpan.org
* URL : http://search.cpan.org/dist/Chart-Clicker/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for creating attractive charts and graphs

Chart::Clicker is a Perl module that aims to create beautiful graphs in a
powerful and extensible way. A variety of charts can be created, including
line, bar and area charts (as well as their stacked equivalents), scatter,
pie, bubble, candlestick and polar area. Charts can be saved in a variety
of formats, including PNG, SVG, PDF and PostScript.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#576479: ITP: libhttp-server-simple-psgi-perl -- simple HTTP server with PSGI application support

2010-04-04 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libhttp-server-simple-psgi-perl
  Version : 0.14
  Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net
* URL : http://search.cpan.org/dist/HTTP-Server-Simple-PSGI/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : simple HTTP server with PSGI application support

HTTP::Server::Simple::PSGI is a simple standalone HTTP server, based on the
HTTP::Server::Simple module (see libhttp-server-simple-perl). This module can
be easily used as an embedded web server for development purposes.

NOTE: this package is needed for packaging Dancer (libdancer-perl),
and probably other stuff too.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#573929: ITP: libcatalyst-devel-perl -- collection of development tools for Catalyst

2010-03-14 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcatalyst-devel-perl
  Version : 1.27
  Upstream Author : Catalyst Contributors, see Catalyst.pm
* URL : http://search.cpan.org/dist/Catalyst-Devel/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : collection of development tools for Catalyst

Catalyst::Devel is a collection of modules that are useful for developing and
testing Catalyst applications, but which are not required to run them. It is
intended to simplify deployment of Catalyst applications; among other things,
it currently includes:

Module::Install::Catalyst
Provides various utilities for creating Catalyst module distributions.

Catalyst::Helper
Helper module for bootstrapping a Catalyst application via catalyst.pl.

Catalyst::Restarter
Utility to restart the server when files have changed

NOTES:
previously, this module was part of libcatalyst-modules-perl, but I
want to move it out of that bundle because it contains many useful
modules even where the rest of the Catalyst modules are not needed. A
bare-bones installation of the Catalyst runtime + Catalyst::Devel
might be sufficient for developers, and it would be useful to
(perhaps) minimize attack surface area in case there are
vulnerabilities in other Catalyst modules.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#573341: ITP: libmath-gradient-perl -- module for calculating smooth numerical transitions

2010-03-10 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmath-gradient-perl
  Version : 0.04
  Upstream Author : Tyler MacDonald j...@crackerjack.net
* URL : http://search.cpan.org/dist/Math-Gradient/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for calculating smooth numerical transitions

Math::Gradient is a Perl module that is useful for calculating numbers needed
to make smooth transitions between two or more numerical values (graphically
represented as gradients). The primary intent of this module is to make it
easy to mix colours, both in terms of basic and multiple-point gradients.

NOTE: this is needed for packaging of Chart::Clicker



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#573347: ITP: libhash-multivalue-perl -- module for storing multiple values per key in a hash

2010-03-10 Thread Jonathan Yu
Package: wnpp
Owner: Jonathan Yu jaw...@cpan.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libhash-multivalue-perl
  Version : 0.08
  Upstream Author : Tatsuhiko Miyagawa miyag...@bulknews.net
* URL : http://search.cpan.org/dist/Hash-MultiValue/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for storing multiple values per key in a hash

Hash::MultiValue is a Perl module that provides an object (and a plain hash
reference) that may contain multiple values per key. The hash behaves like a
single-value hash reference, but also provides an API to retrieve multiple
values explicitly on demand.

NOTE: this package is needed for packaging Plack



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



  1   2   3   4   >