Bug#854613: linux-image-4.8.0-2-amd64: System hangs at "Loading initial ramdisk" after upgrading to 4.9
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
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
On Tue, May 3, 2016 at 10:10 AM, Laurent Bigonvillewrote: > > > 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
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?
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
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 Barabucciwrote: > 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
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
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
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
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
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)
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)
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
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
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
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
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
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?
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
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
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
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
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
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)
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'
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
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
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
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
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()
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
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
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
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
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
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)
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
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
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
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
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)
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
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
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
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
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
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?
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
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
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
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
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
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
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
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?
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
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?
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
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 [..]
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)
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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