Re: svn-buildpackage
Le Tue, Mar 30, 2010 at 09:52:02AM +0200, Cecile Forella a écrit : *E: Found unresolved issues: M debian/patches/use-ffmpeg-swscaler.patch E: Resolve them manually before continuing* (ici j'ai modifié le fichier use-ffmpeg-swscaler.patch) Comment puis-je faire des modifs sans qu'il me mette une erreur? Bonjour Cécile, il faut ajouter --svn-ignore-new pour construire un paquet avec svn-buildpackage sans avoir envoyé les changements dans le référentiel amont. Amicalement, -- Charles Plessy, Tsurumi, Kanagawa, Japon -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100330083102.ga8...@kunpuu.plessy.org
Re: problème patches
Bonjour On Tuesday 30 March 2010 11:00:28 Cecile Forella wrote: Apparemment le patch n'a pas la bonne version par rapport au paquet debian. Comment peut on changer sa version? Je manque un peu d'info sur le contexte pour pouvoit t'aider. D'où viennent ces patchs ? Est-ce que tu es en train de mettre à jour paraview ? (update d'upstream) A+ Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003301125.15183.dominique.dum...@hp.com
Re: problème patches
On Tuesday 30 March 2010 11:00:28 Cecile Forella wrote: Apparemment le patch n'a pas la bonne version par rapport au paquet debian. Comment peut on changer sa version? En fait, pendant le process de build, les patchs sont appliqués sur le source que tu as sous la main. Si tu change le source, il se peut que les patches ne s'appliquent plus corrrectement. Donc avant de modifier le source de paraview, il faut appliquer tous les patches avec quilt: $ export QUILT_PATCHES=debian/patches/ $ quilt push -a Ensuite tu peux éditer les sources (en utilisant quilt pour ne pas te mélanger les pinceaux): $ quilt new mon_patch $ quilt edit mon_patch ... $ quilt refresh Avant de builder le package, il faut faire $ quilt pop -a HTH Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003301139.41270.d...@komarr.gre.hp.com
Re: problème patches
A. Le mardi 30 mars 2010 à 18:37 +0900, Charles Plessy a écrit : Le Tue, Mar 30, 2010 at 11:00:28AM +0200, Cecile Forella a écrit : Lorsque je fais un svn-buildpackage sur les sources de paraview, j'ai l'erreur suivante : Application de use-ffmpeg-swscaler.patch patching file VTK/IO/vtkFFMPEGWriter.cxx Hunk #1 FAILED at 20. Hunk #2 FAILED at 244. Hunk #3 FAILED at 259. 3 out of 3 hunks FAILED -- rejects in file VTK/IO/vtkFFMPEGWriter.cxx patching file VTK/CMake/FindFFMPEG.cmake Hunk #1 FAILED at 31. Hunk #2 FAILED at 71. Hunk #3 FAILED at 86. Hunk #4 FAILED at 96. 4 out of 4 hunks FAILED -- rejects in file VTK/CMake/FindFFMPEG.cmake patching file VTK/IO/CMakeLists.txt Hunk #1 FAILED at 233. 1 out of 1 hunk FAILED -- rejects in file VTK/IO/CMakeLists.txt Le patch use-ffmpeg-swscaler.patch ne s'applique pas proprement (forcez l'application avec -f) make: *** [debian/stamp-patched] Erreur 1 dpkg-buildpackage: erreur: debian/rules build a produit une erreur de sortie de type 2 Rebonjour, À vue de nez, il manque la propriété mergeWithUpstream sur le répertoire debian. svn propset mergeWithUpstream 1 debian C'est cette commande qui indique à svn-buildpackage que les sources amont ne sont pas inclues dans le référentiel. C'est pour ça que quand la propriété est oubliée, aucun patch ne peut être appliqué ! Ma faute, je l'ai oublié quand j'ai déplace paraview de pkg-scicomp = debian-science. C'est corrigé. Ceci étant dit, aujourd'hui le référentiel pour paraview est git://alioth.debian.org/git/pkg-scicomp/paraview.git… Faudrait le tuer ce git. C'est une vieille version du packaging paraview. Sylvestre -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1269942108.7169.160.ca...@korcula.inria.fr
Re: problème patches
Le mardi 30 mars 2010 à 12:19 +0200, Raphael Hertzog a écrit : On Tue, 30 Mar 2010, Sylvestre Ledru wrote: Ceci étant dit, aujourd'hui le référentiel pour paraview est git://alioth.debian.org/git/pkg-scicomp/paraview.git… Faudrait le tuer ce git. C'est une vieille version du packaging paraview. Ce n'est pas ce que disent les champs Vcs-* du paquet source actuellement présent dans sid... mais c'est que dis la prochaine version qui sera uploadée: http://svn.debian.org/viewsvn/debian-science/packages/paraview/trunk/debian/changelog Sylvestre -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1269946298.7169.611.ca...@korcula.inria.fr
Bug#575887: ITP: urg -- library to access Hokuyo URG/UTM laser range scanners
Package: wnpp Severity: wishlist Owner: Albert Huang a...@debian.org Owner: Albert Huang a...@debian.org * Package name: urg Version : 0.8.11 Upstream Author : Satofumi KAMIMURA s-kamim...@hokuyo-aut.co.jp * URL : http://www.hokuyo-aut.jp/02sensor/07scanner/download/urg_programs_en/ * License : LGPL Programming Lang: C, C++ Description : library to access Hokuyo URG/UTM laser range scanners Hokuyo infrared laser range scanners provide range measurements to nearby objects using LIDAR technology. Uses include factory automation for automated safety systems and robotics research platforms. . urg provides libraries and an API for controlling and reading data from Hokuyo sensors. -- 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/20100330051649.4709.59555.report...@ocha.csail.mit.edu
Re: Serializing transitions
On Sun, Mar 28, 2010 at 09:53:56AM +, Philipp Kern wrote: On 2010-03-28, Wouter Verhelst wou...@grep.be wrote: With old buildd, it was always possible to add this bug # after the fact. I don't know what the case is with new buildd/new wanna-build, but it might be a good idea to look into that... That hasn't changed. It's mildly annoying though that you cannot do file bug, mark package as failed with the bug number in one step. True. You always have to wait for the BTS confirmation first. Perhaps it would be nice to talk to the debbugs maintainers and work out a way in which the BTS can inform wanna-build of a bug number without buildd admin intervention? Maybe this could work through something like X-Debbugs-Cc where the bts would pass on version, architecture, and package version in a machine-readable format. A mail processor on the wanna-build end could then parse that and add it to the right place in the database. Of course, that would prerequire that the bts track architectures, which it currently doesn't... It would certainly make sense to make this an automated process; there's really no need for the buildd maintainer to have to do this manually. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- 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/20100330085252.ga3...@celtic.nixsys.be
Re: Best practices for development workstations
On Mon, Mar 29, 2010 at 07:03:00PM -0500, John Goerzen wrote: Hi folks, I'm trying to solicit comments on what people are using for development environments and how well it's working. Here are some situations I imagine are common: 1. workstation running sid I've followed this model for over a decade. It works well, in general, and I keep up with development well enough that I can fix problems when they arise. However, it tends to lead to a certain amount of cruft over the years. Moreover, it's not really appropriate for a laptop or a situation in which Internet access isn't readily available to fix problems. I'm hoping to move away from that model. I've been in this situation ever since I upgraded from potato to woody back in late 2000, right before I became a Debian Developer. I've continued this practice on my work laptops that I often have to take to customers to work -- so they have to work reliably for me. There've been cases where sid has been broken when I needed the laptop for work, but these have been rare; and in the nine years that I've now used it, I can count only two times when it had an impact on my work: yaboot once broke, refusing to boot the laptop, and of course I only noticed when I was off-site, away from rescue CD's and had to use it to give a presentation. This was then done without slides, obviously. The other time was with the XFree-Xorg transition, when my X server wouldn't work for a few days and I had to use the laptop at a customer's site to configure something on their network. It was a little awkward to have to explain why I didn't have a graphical user interface, but I still could do my work, so it wasn't a problem as such. Of course, sid does require you to do a little more hand-holding, and this can be annoying at times. But if you stay up-to-date with things, I find that it's not usually a problem. I do /not/ run sid on my secondary systems, because while I don't mind having to do a bit more work to keep my primary system up-to-date, I do mind having to repeat that for other systems. So these usually run stable or testing, depending on the case. My previous laptop was a powerbook, so I still occasionally use it for some powerpc testing. However, building packages on that machine takes more effort, because it's running testing; I feel that using chroots, either through pbuilder or directly, or doing things like virtual machines, is quite a burden, and that it interferes with my workflow. When using one of my secondary machines, I'm therefore usually not as productive as when using my primary one. I guess what I'm trying to say is that while I understand the motivation of many developers to run testing or stable on their machine, running sid instead does have some important advantages for Debian Developers, while the disadvantages are not as serious as they would seem at first sight. Of course, this all depends on how much time you're willing to put into building/testing packages on the one hand, and maintaining your primary system on the other. To me, the balance is in favour of running sid, but of course YMMV. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Serializing transitions
On Tue, 30 Mar 2010, Wouter Verhelst wrote: You always have to wait for the BTS confirmation first. Perhaps it would be nice to talk to the debbugs maintainers and work out a way in which the BTS can inform wanna-build of a bug number without buildd admin intervention? Maybe this could work through something like X-Debbugs-Cc where the bts would pass on version, architecture, and package version in a machine-readable format. A mail processor on the wanna-build end could then parse that and add it to the right place in the database. Of course, that would prerequire that the bts track architectures, which it currently doesn't... X-Debbugs-Cc and a script should be more than enough, you can certainly parse the pseudo-headers to find out the packages and the version. And when you report the bug, you can add a custom pseudo-header Arch that the BTS would ignore but that your script would use. Without the Arch pseudo-header, it would be assigned to all failed arches. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100330093400.gi28...@rivendell
Re: Proposal: Automatic selection of hardware specific packages
On Mon, Mar 29, 2010 at 11:51:54PM +0200, Guillem Jover wrote: Hi! I've had this idea in my head for long, but as never found the time to work on it, didn't feel appropriate to throw it to the wall and expect someone else to implement it. Anyway, it seems to me it might be a nice GSoC project, and not necessarily too complex. As I've my plate already full, I'm not volunteering myself for mentoring, though. I'm CCing de...@l.d.o as they should be in the loop and Petter as he was working on integrating package data into discover-data at some point in the past, which might be interested in mentoring. Problem ~~~ I've always found it annoying that it's become very difficult to hunt all packages that might be needed for or useful with the current hardware on the system, and usually you tend to miss some. It might be even trickier for non-technical users who might not even know they need specific packages for something to work. Proposal Ideally the package manager front-ends would propose for installation to the user all hardware related packages for currently detected hardware in the system, or removal once such hardware is not present (although that might need to be disabled for pluggable hardware). This could include drivers, firmware, tools and applications [0]. There's a distinction between packages that are required for something to work, which could be handled somehow as Recommends, and packages which might have additional functionality if the hardware is present, which could be handled as Suggests. Ubuntu developed a tool called 'jockey' for installing hardware drivers. There is an ITP for it in Bug #436722. Jockey is in my opinion the best place to do something like this. I CCed Martin Pitt, the developer of jockey (and quoted the remaining parts of the email in case he did not read the original one). Each package would provide a list of patterns for the hardware it supports. Depending on their size, they could be provided in a new field (for example Hardware-Id), or on a new control file (but then that would need to get extracted from binary packages and collected into a foo-data package for example) or something else. Those patterns would match against the device IDs of cpu, pci, pnp, usb, eisa, dmi, pcmcia, acpi, ieee1394, etc. For some packages this information is already known, and can be automatically extracted from some files (and possibly converted to the chosen pattern format). For example X.Org drivers have an internal list of patterns, not sure if those can be easily extracted, for Linux kernel modules one can extract those with something like: ,--- |PATH=/sbin:$PATH | |find -name '*.ko' | xargs modinfo -F alias | \ | egrep '^(pci|pnp|eisa|pcmcia|usb|acpi|dmi|ieee1394|ssb|wmi):' `--- [0] An incomplete list from when I looked into this could include: Drivers --- xserver-xorg-video-*, xserver-xorg-input-*, *-source, firmware-* Tools - Graphic cards: gatos, radeontool, rovclock, atitvout, s3switch, i810switch, matroxset, nvclock, nvtv, libglide3. Sound cards: awesfx, ld10k1. Webcams: qcam, qpcr1k, pencam. CPUs: athcool, set6x86. Laptops: i8kutils, fnfxd, fnfx-client, toshset, toshutils, tpb, spicctrl. Printers: foomatic-db-hpijs, hpijs, hplip, hpoj. SCSI: scsitools, sg-utils. Design and Implementation ~ Things to decide and work on, would include: * The format of the patterns for each hardware type. There's existing examples that could be either reused or based for inspiration. * A tool to extract at package build time as much of the IDs as possible from existing files and convert them to the normalized form, if need be. (Ideally independent of any packaging helper.) * Consider and decide where to ship such information. * It might be a good idea to be able to have a global override, for testing purposes, and a faster initial deployment, once a working implementation is in place those could be moved to each package. * Decide how to make the front-ends use the information, for example by creating a shared library that does the detection and matching, and just returns the list of packages, or through an external program (say a new hwsel, or maybe just adapting and/or extending disover or any of the other hardware detectors to be easily integrated with the front-ends), etc. * The actual integration with the front-ends. regards, guillem -- To UNSUBSCRIBE, email to deity-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329215154.ga30...@gaara.hadrons.org -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgp8wW4Sa5mV0.pgp Description: PGP signature
Re: Best practices for development workstations
Hi John, On Dienstag, 30. März 2010, John Goerzen wrote: The ability to easily rebuild a chroot is appealing. However, I do not have a fast mirror at home; my broadband connection is just barely broadband. pbuilder highly recommends a local or a fast mirror. So I am concerned about this approach for security reasons as well. squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) cheers, Holger (running lenny + custom backports on his laptop (ie I'm using xorg from experimental but provided in a local stable repo), plus chroots as well virtual machines with virtualbox. Building is always done in pbuilder (or an extra, clean lenny chroot). signature.asc Description: This is a digitally signed message part.
Re: Best practices for development workstations
Hi Holger. Excerpts from Holger Levsen's message of Ter Mar 30 09:56:34 -0300 2010: (...) On Dienstag, 30. März 2010, John Goerzen wrote: The ability to easily rebuild a chroot is appealing. However, I do not have a fast mirror at home; my broadband connection is just barely broadband. pbuilder highly recommends a local or a fast mirror. So I am concerned about this approach for security reasons as well. squid! (Or any other normal http proxy. I don't recommend any apt-proxy solution...) Can you explain why? Thanks in advance. (...) -- marcot http://wiki.debian.org/MarcoSilva -- 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/1269954437-sup-5...@zezinho
Re: Best practices for development workstations
Paul Wise wrote: So I am concerned about this approach for security reasons as well. Could you detail your concerns here? That was a braino. I meant to say *performance* reasons. -- John -- 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/4bb1fd3d.6090...@complete.org
Re: About new source formats for packages without patches
Ben Finney schrieb: Raphael Hertzog hert...@debian.org writes: There's a default value currently and it's 1.0, and I want to remove the existence of a default value in the long term because it does not make sense to have a default value corresponding to a source format that is no longer recommended. That's the part I don't see a reason for. Any future formats will be unambiguously distinguishable. Those format-undeclared source packages can't be eradicated from the earth entirely. So why not simply declare that they are source format 1.0, as is without changes, and will always be recognised as such even *after* that format is utterly deprecated? What you describe is actually really a default to 1.0 behaviour. And though I dislike the way lintian warned about a missing debian/source/format file, I understand quite well why the dpkg maintainer would like to remove that default: 1.0 in ambiguous in many ways (for example in changing silently to native package format if the orig.tar.gz is missing).. I'm not going to convert my few packages to a 3.0 format any time soon if it doesn't prove to be beneficial for me, but I will add an explicit 1.0 format specification to those packages I upload in the meantime. My main reason for not yet switching is that hg-buildpackage and svn-buildpackage don't completely support the 3.0 format yet as far as I can tell. Anyhow, I would really welcome if dpkg-source would support some additional values in debian/source/format: 1.0 (native) 1.0 (non-native) default (native) default (non-native) Which would allow me to explicitly follow the current recommendation of the dpkg maintainers (last two) or explicitly state that my package is format 1.0 of either flavour. Regards, Sven -- 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/4bb20ec7.9090...@incase.de
Re: About new source formats for packages without patches
Julien BLACHE schrieb: Raphael Hertzog hert...@debian.org wrote: I expect this to be of particular interest when we'll have VCS-powered source formats (say 3.0 (git2quilt)) that generate source packages that are plain 3.0 (quilt) based on the git repository information. This is becoming crazy, really. I agree. dpkg-dev should not be depending on any VCS and it should not promote any particular VCS either. I know that git is the new black (oh, wait, that was something else), but I personally don't like it. And I especially dislike how so many git lovers are trying to push it onto others, while there are perfectly good reason (not applicable to all teams or projects of course) not to use git but some other VCS (be it distributed or not. Regards, Sven -- 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/4bb21032.6050...@incase.de
Re: Best practices for development workstations
On Mon, Mar 29, 2010 at 05:43:06PM -0700, Russ Allbery wrote: John Goerzen jgoer...@complete.org writes: I use a combination of the two of these except with testing on my primary workstation (the one that I can't afford to have go down), but list and deprioritize sid in sources.list on the workstation running testing. Then when testing builds of my own applications, I let apt resolve dependencies from unstable where needed. One other potential problem with having my build environment be the same as my workstation: I sometimes have non-Debian packages installed (MythTV, nvidia drivers, other stuff I'm working on, etc.) that I occasionally worry could cause dependency issues. To date I have been careful with where I build things, and haven't yet had that problem. But there is something of a conflict between work environment and clean development environment. Of course, once I go to having development in its own environment, there is no longer much call for running sid directly on the thing -- and listing but deprioritizing sid could be useful for when I have to test things from sid. -- John -- 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/20100330152323.ga27...@excelii.com
Re: Best practices for development workstations
On Tue, Mar 30, 2010 at 09:02:59AM +0800, Paul Wise wrote: On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen jgoer...@complete.org wrote: 1. workstation running sid I used that until DebConf9 when I reinstalled and switched from i386 to amd64. 2. workstation running squeeze or lenny At the moment I have only one workstation (a laptop). I use testing, unstable and experimental, with pinning setup to upgrade within that suite where I've upgraded a package, until the version migrates to a lower suite. I'm having a bit of trouble visualizing how that works; can you spell out your apt settings? -- John -- 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/20100330152431.gb27...@excelii.com
Re: About new source formats for packages without patches
Sven Mueller wrote: (for example in changing silently to native package format if the orig.tar.gz is missing) That's not true is it? At least, if I use 'debuild' I get a pretty big warning if the orig.tar.gz is missing. snip $ apt-get source acct $ rm acct_6.5.1.orig.tar.gz $ debuild This package has a Debian revision number but there does not seem to be an appropriate original tar file or .orig directory in the parent directory; (expected one of acct_6.5.1.orig.tar.gz, acct_6.5.1.orig.tar.bz2, acct_6.5.1.orig.tar.lzma or acct-6.5.1.orig) /snip If that is debuild specific, wouldn't it be much simpler to implement the same check in dpkg-dev than having every package add this silly format file? I for one am very happy I won't be seeing the Lintian warning anymore and have no intention of adding the source/format file until forced to for my (very few) packages. IMO format 1.0 is perfectly adequate for tons of packages and should remain the default without any need to be specified. Cheers, FJP -- 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/201003301804.07574.elen...@planet.nl
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
On 12065 March 1977, Joerg Jaspert wrote: ries.debian.org, the host behind ftp-master.debian.org, has hardware trouble, a failed memory module keeps resetting the machine at random intervals. Will send a notice when service is back to normal. And another update for you all out there, waiting: After several ping-pongs the support finally understood that no round of firmware updates, changing slots of the DIMMs and trying whatever does not help, so we are now waiting for a new mainboard to arrive, as well as a technician. The current timeline lets us assume this is done, latest, day after tomorrow, please be patient. Will keep you updated when status changes. The backup plan still is moving this service to another machine. This hasn't been done yet for various reasons. One of them is simply that it took a little longer to move the remaining services away from it, but also the amount of work included. Now, should the technician not be able to resurrect ries, our backup plan extends to have the disks shipped over and replace the ones currently in rietz. -- bye, Joerg I'm in no condition to drive...wait! I shouldn't listen to myself, I'm drunk! -- 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/87fx3hdbus@gkar.ganneff.de
Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode j...@debian.org
* Package name: dh-autoreconf
Version : 1
Upstream Author : Julian Andres Klode j...@debian.org
* License : GPL-2
Programming Lang: Perl
Description : debhelper add-on to call autoreconf and clean up after the
build
Package: dh-autoreconf
Architecture: all
Depends: ${misc:Depends}, autoconf, automake | automaken, libtool
Description: debhelper add-on to call autoreconf and clean up after the build
dh-autoreconf provides a debhelper sequence addon named 'autoreconf' and two
commands, dh_autoreconf and dh_autoreconf_clean.
.
The dh_autoreconf command creates a list of the files and their checksums,
calls autoreconf and then creates a second list for the new files.
.
The dh_autoreconf_clean command compares these two lists and removes all
files which have been added or changed (files may be excluded if needed).
I am using this inside the gnome-main-menu package and it works perfectly,
although a bit slow because it creates md5sums of the whole source tree
two times (I may add an option to use timestamp+size instead for larger
source packages).
(Please note that I'm not subscribed to debian-devel, so please keep the
bug report or me in To/CC)
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
pgpiCkN7pPfBk.pgp
Description: PGP signature
Re: Naming policy for Perl modules (mass bug filing)
Hi, Ansgar Burchardt ans...@43-1.org writes: the Debian Perl Policy asks for packages for the Foo::Bar module to be named libfoo-bar-perl [1]. Some packages do not adhere to this scheme: [...] Unless there are objections I will file bugs of severity normal in a few days for these packages. The bugs are now filed with severity wishlist and user-tagged. A list can be obtained from [1]. Regards, Ansgar [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-naming-policy;users=ans...@2008.43-1.org -- 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/87zl1ppxte@marvin.43-1.org
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Tue, Mar 30, 2010 at 06:15:26PM +0200, Julian Andres Klode wrote:
Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode j...@debian.org
* Package name: dh-autoreconf
Version : 1
Upstream Author : Julian Andres Klode j...@debian.org
* License : GPL-2
Programming Lang: Perl
Description : debhelper add-on to call autoreconf and clean up after
the build
Package: dh-autoreconf
Architecture: all
Depends: ${misc:Depends}, autoconf, automake | automaken, libtool
Description: debhelper add-on to call autoreconf and clean up after the build
dh-autoreconf provides a debhelper sequence addon named 'autoreconf' and two
commands, dh_autoreconf and dh_autoreconf_clean.
.
The dh_autoreconf command creates a list of the files and their checksums,
calls autoreconf and then creates a second list for the new files.
.
The dh_autoreconf_clean command compares these two lists and removes all
files which have been added or changed (files may be excluded if needed).
I am using this inside the gnome-main-menu package and it works perfectly,
although a bit slow because it creates md5sums of the whole source tree
two times (I may add an option to use timestamp+size instead for larger
source packages).
It seems that we could also read the requested versions of automake and
autoconf from debian/control and export them automatically using:
# Setup the environment for autoreconf to run the correct versions
sub program {
my $program=shift;
my $version=;
open (CONTROL, 'debian/control') ||
error(cannot read debian/control: $!\n);
foreach my $builddeps (join('', CONTROL) =~
/^Build-Depends[^:]*:.*\n(?:^[^\w\n].*\n)*/gmi) {
while ($builddeps =~ /$program([0-9.]+)/g) {
error(Multiple versions of $program requested ($version, $1)) if
($version ne );
$version=$1;
}
}
close CONTROL;
return $version eq ? $program : $program.-.$version;
}
$ENV{AUTOCONF} = program(autoconf) if not defined $ENV{AUTOCONF};
$ENV{AUTOHEADER} = program(autoconf) if not defined $ENV{AUTOHEADER};
$ENV{ACLOCAL} = program(automake) if not defined $ENV{ACLOCAL};
$ENV{AUTOMAKE} = program(automake) if not defined $ENV{AUTOMAKE};
Does this sound like a good idea?
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
pgpMrSZitMydV.pgp
Description: PGP signature
Re: Best practices for development workstations
John Goerzen jgoer...@complete.org writes: One other potential problem with having my build environment be the same as my workstation: I sometimes have non-Debian packages installed (MythTV, nvidia drivers, other stuff I'm working on, etc.) that I occasionally worry could cause dependency issues. To date I have been careful with where I build things, and haven't yet had that problem. But there is something of a conflict between work environment and clean development environment. Of course, once I go to having development in its own environment, there is no longer much call for running sid directly on the thing -- and listing but deprioritizing sid could be useful for when I have to test things from sid. I always do all package builds inside pbuilder unless for some reason I have to look at the results of a partial build, which is how I get around that problem. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87eij1ln1b@windlord.stanford.edu
Re: Serializing transitions
On Tue, 30 Mar 2010, Raphael Hertzog wrote: X-Debbugs-Cc and a script should be more than enough, you can certainly parse the pseudo-headers to find out the packages and the version. And when you report the bug, you can add a custom pseudo-header Arch that the BTS would ignore but that your script would use. Another method is that you can use usertags to set a tag that corresponds to a wannabuild db index (with a specific user) and then query the bts for that at some later point in time. You can handle architectures in a similiar fashion if you want. For example: Source: foo Severity: serious User: wannabu...@buildd.debian.org UserTags: wannabuildid-12345, wannabuildarch-i386 then after a suitable wait (or perhaps in a cron job which looked for filed bugs which didn't have a bug # associated): bts select users:wanabu...@buildd.debian.org tag:wannabuildid-12345 would return the bug using the soap interface. [There is a planned feature called uservalues which would make this slightly more elegant, but i haven't completed it yet.] Don Armstrong -- Identical parts aren't. -- Beach's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100330180819.gr21...@teltox.donarmstrong.com
Bug#575950: ITP: libperl-prereqscanner-perl -- module for extracting prerequisites from Perl code
Package: wnpp Owner: gregor herrmann gre...@debian.org Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libperl-prereqscanner-perl Version : 0.100830 Upstream Author : Jerome Quelin * URL : http://search.cpan.org/dist/Perl-PrereqScanner/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module for extracting prerequisites from Perl code Perl::PrereqScanner will extract loosely distribution prerequisites from files. The extraction may not be perfect but tries to do its best. It will currently find the following prereqs: * plain lines beginning with use or require in perl modules and scripts * regular inheritance declared with the base and parent pragmata * Moose inheritance declared with the extends keyword * Moose roles included with the with keyword -- 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/20100330174255.ga12...@belanna.comodo.priv.at
Re: Naming policy for Perl modules (mass bug filing)
On Tue, Mar 30, 2010 at 11:40 AM, Ansgar Burchardt ans...@43-1.org wrote: Hi, Ansgar Burchardt ans...@43-1.org writes: the Debian Perl Policy asks for packages for the Foo::Bar module to be named libfoo-bar-perl [1]. Some packages do not adhere to this scheme: [...] Unless there are objections I will file bugs of severity normal in a few days for these packages. The bugs are now filed with severity wishlist and user-tagged. A list can be obtained from [1]. Regards, Ansgar [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-naming-policy;users=ans...@2008.43-1.org -- 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/87zl1ppxte@marvin.43-1.org Philosophical question: When does this sort of thing get taken care of? In twenty years, will Debian (if it's still going) have myriad misnamed libraries? I know one can Shouldn't housecleaning like this be of higher priority, especially say, when a new version has just been put out? That way, maintainers would have months to slowly work on one package (and its associated reverse-dependencies) at a time. I do not know the technical constraints (no autobuild, etc), but consistency is a valuable trait of an operating system. -- Luke L. -- 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/c1775fd41003301204k21a4f8f5yf9fe76330ee4a...@mail.gmail.com
Re: German Debian
I'm a bit late but... Marc Haber mh+debian-de...@zugschlus.de wrote: Unfortunately, all of Debian. Translating technical texts from English to German is controversial at its best, and the Debian translators have taken my least favorite approach of eliminating all English, leading to barbarities like SMTP-Sendezentrale or Sicherheitsgutachten. Debian's German translations feel to me (a native speaker of German) as babelfished from English. ACK I used to take a look at Debian's translations of my own package's Debconf templates, but nowadays I just treat them as just another language that I don't speak. This approach saves me a lot of grief. Same here. Sounds like Debian has QA issues wrt the website translations. I assume that you reported that to the German website l10n folks, debian-i18n and debian-www? They are resistant to advice and think their way is the correct way. They work with a word list, so it must be correct. I found the same. They seem to want to invent a new german IT-lingo, which simply isn't accepted by the majority who just talk german grammar with english vocabulary. I don't care anymore for german translations. May the ones who cannot read the english original *and* have trouble with the german text discuss with them. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- 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/871vf1d1lc@alhambra.kuesterei.ch
Bug#575953: ITP: gmock -- Google's framework for writing and using C++ mock classes
Package: wnpp Severity: wishlist Owner: Fredrik Hallenberg hal...@debian.org Owner: Fredrik Hallenberg hal...@debian.org * Package name: gmock Version : 1.4.0 Upstream Author : Zhanyong Wan w...@google.com * URL : http://code.google.com/p/googlemock * License : Google (SEE BELOW) Programming Lang: C++ Description : Google's framework for writing and using C++ mock classes Google's framework for writing and using C++ mock classes on Linux, Mac OS X, and Windows. Inspired by jMock, EasyMock, and Hamcrest, and designed with C++'s specifics in mind, it can help you derive better designs of your system and write better tests. Google Mock: - provides a declarative syntax for defining mocks, - can easily define partial (hybrid) mocks, which are a cross of real and mock objects, - handles functions of arbitrary types and overloaded functions, - comes with a rich set of matchers for validating function arguments, - uses an intuitive syntax for controlling the behavior of a mock, - does automatic verification of expectations (no record-and-replay needed), - allows arbitrary (partial) ordering constraints on function calls to be expressed, - lets a user extend it by defining new matchers and actions. - does not use exceptions, and - is easy to learn and use. License, please advise if this is ok: Copyright 2008, Google Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- 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/20100330185104.14952.24808.report...@localhost
Re: md5sums files... and beyond
Hi,
In case anyone wonders about the status of replacing md5sums with
something stronger _in_ the binary packages, this should be considered
to be suspended until the next development cycle. (at least, from my
PoV).
It have been pointed out that those current checksum aren't sufficient
to validate that an installed package is secure (quoting Joey Hess:
there are innumerable ways for an attacker to inject bad
behavior/backdoors onto a system without touching binaries originating
from dpkg.[1] and it's also fairly easy to modify a file in /etc to
provide a backdoor ...)
Therefore, it should be clear that there is no urgency in replacing
DEBIAN/md5sums as they are useful for corruption and local (benign)
modification checksumming. (quoting Russ Allbery[2]).
The initial proposal to replace md5sum with ${better}sum:
http://wiki.debian.org/Sha256sumsInPackages
should be enhanced with further meta-data. A very early draft is:
http://wiki.debian.org/Proposals/BinaryPackageDescriptor
Regards,
Franklin
On Thu, 2010-03-11 at 00:44 +0100, Frank Lin PIAT wrote:
On Wed, 2010-03-03 at 03:06 +0100, Wouter Verhelst wrote:
I must say I was somewhat surprised by these numbers. Out of 2483
packages installed on my laptop, 2340 install md5sums. While that
might've been useful at some point, I don't think it still is.
Hi all,
Can you think of any sensible reason for not including md5sums of
control files, especially the {pre,post}{inst,rm} scripts ?
In the shasum file, those files could be either:
1. inserted, with the patch rewritten to match their expected
location on the target system.
or
2. inserted as a *comment* in the shasum file, like:
#68b329da9893e34099c7d8ad5cb9c940 CONTROL.TAR:postinst
[1] http://lists.debian.org/msgid-search/20100308225913.ga25...@gnu.kitenet.net
[2] http://lists.debian.org/msgid-search/87wrxmbkdn@windlord.stanford.edu
--
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/1269982677.3574.252.ca...@solid.paris.klabs.be
Bug#575964: ITP: portlet-api-2.0-spec -- Java Portlet Specification V2.0
Package: wnpp Severity: wishlist Owner: Damien Raude-Morvan draz...@debian.org Owner: Damien Raude-Morvan draz...@debian.org * Package name: portlet-api-2.0-spec Version : 1.0 Upstream Author : Apache Software Foundation * URL : http://portals.apache.org/portlet-spec/portlet-api-2.0/ * License : Apache-2.0 Programming Lang: Java Description : Java Portlet Specification V2.0 The Java Portlet API version 2.0 developed by the Java Community Process JSR-286 Expert Group. . Portlets are pluggable user interface components that are managed and displayed in a web portal like Liferay or JBoss Gatein. . Package current source code is taken from Apache Portals project http://portals.apache.org/. -- 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/20100330220959.32729.10689.report...@gauloise.lan.drazzib.com
Re: About new source formats for packages without patches
Sven Mueller deb...@incase.de writes: Ben Finney schrieb: Any future formats will be unambiguously distinguishable. Those format-undeclared source packages can't be eradicated from the earth entirely. So why not simply declare that they are source format 1.0, as is without changes, and will always be recognised as such even *after* that format is utterly deprecated? What you describe is actually really a default to 1.0 behaviour. Specifically, a behaviour of *recognising* that a package is in source format 1.0. That's a fact of that package in that state, that shouldn't change just because time has passed. In other words, a source package left as it was from five years ago (i.e., with no source format declaration) is still source format 1.0 five years ago, today, in ten years, and in a hundred years; because the passage of time doesn't change the format that the source package is in. [source format 1.0 is] ambiguous in many ways (for example in changing silently to native package format if the orig.tar.gz is missing).. Maybe so. I don't see how that is improved by pretending that a package which is in source format 1.0 is instead in a different format. Calling it a different format from 1.0 would be false. The dpkg tool needs to recognise the format for what it is, and respond however the dpkg maintainers feel is appropriate in the presence of that format. Now, *in response to* recognising that fact (“the package is in source format 1.0”), the behaviour of the tool can and should change over time; I have no argument against that behaviour gradually getting more hostile to that format over time. The only thing I'm arguing for in this case is that such packages are, in fact, in source package format 1.0, that fact doesn't change over time, and in the absence of any declarative change to the package they should not be falsely identified as any other format. Again, I say all this only to correct misinterpretation, just as I hope to be corrected if I have misinterpreted the situation. Thanks. -- \ “As scarce as truth is, the supply has always been in excess of | `\ the demand.” —Josh Billings | _o__) | Ben Finney -- 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/87vdcdmg82@benfinney.id.au
Re: About new source formats for packages without patches
On Wed, 31 Mar 2010 12:29:01 +1100, Ben Finney ben+deb...@benfinney.id.au wrote: Specifically, a behaviour of *recognising* that a package is in source format 1.0. That's a fact of that package in that state, that shouldn't change just because time has passed. In other words, a source package left as it was from five years ago (i.e., with no source format declaration) is still source format 1.0 five years ago, today, in ten years, and in a hundred years; because the passage of time doesn't change the format that the source package is in. Yes, the source package, being the .dsc and associated components is still in source format 1.0. It also states that it is, with Format: 1.0 in said .dsc file. The unpacked source package has no format, it's a directory on disk with certain properties. You could take that directory and produce a source package in any number of formats. The debian/source/format is then not a declaration of what format the directory is in, but what format the tools should produce when creating a source package from it. What we are talking about is what the maintainer of the package wants to happen when they produce the source package. Anything that actually cares that if it unpacks and rebuilds a source package it will use the same format can just request the same format as the source package declares in the .dsc. If the maintainer wishes to stick on 1.0 in 10 years time when the project has moved on then why shouldn't they have to request that somehow? Thanks, James -- 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/87ljd9jm84@jameswestby.net
Bug#575973: ITP: libperl5i-perl -- Fix as much of Perl 5 as possible in one pragma
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libperl5i-perl Version : 2.0.3 Upstream Author : Michael G Schwern mschw...@cpan.org * URL : http://search.cpan.org/dist/perl5i/ * License : Perl Programming Lang: Perl Description : Fix as much of Perl 5 as possible in one pragma Perl 5 has a lot of warts. There's a lot of individual modules and techniques out there to fix those warts. perl5i aims to pull the best of them together into one module so you can turn them on all at once. This includes adding features, changing existing core functions and changing defaults. It will likely not be 100% backwards compatible with Perl 5, though it will be 99%, perl5i will try to have a lexical effect. Please add to this imaginary world and help make it real, either by telling me what Perl looks like in your imagination (http://github.com/schwern/perl5i/issues) or make a fork (forking on github is like a branch you control) and implement it yourself. -- 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/20100331020210.6142.97509.report...@skydancer.freeside.biz
Bug#575974: ITP: libtime-y2038-perl -- Versions of Perl's time functions which work beyond 2038
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libtime-y2038-perl Version : 20100225 Upstream Author : Michael G Schwern mschw...@cpan.org * URL : http://search.cpan.org/dist/Time-y2038/ * License : Perl Programming Lang: Perl Description : Versions of Perl's time functions which work beyond 2038 On many computers, Perl's time functions will not work past the year 2038. This is a design fault in the underlying C libraries Perl uses. Time::y2038 provides replacements for those functions which will work accurately +/1 142 million years. -- 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/20100331022204.6338.63920.report...@skydancer.freeside.biz
Bug#575975: ITP: libperl6-caller-perl -- Perl6-like OO caller() interface for perl5
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libperl6-caller-perl Version : 0.100 Upstream Author : Curtis Ovid Poe, o...@cpan.org * URL : http://search.cpan.org/dist/Perl6-Caller/ * License : Perl Programming Lang: Perl Description : Perl6-like OO caller() interface for Perl 5 By default, this module exports the caller function. This automatically returns a new caller object. An optional argument specifies how many stack frames back to skip, just like the CORE::caller function. -- 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/20100331022808.6433.51705.report...@skydancer.freeside.biz
Bug#575976: ITP: libmodern-perl-perl -- Enable all of the features of Modern Perl with one command
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libmodern-perl-perl Version : 1.03 Upstream Author : chromatic, chromatic at wgz.org * URL : http://search.cpan.org/dist/Modern-Perl/ * License : Perl Programming Lang: Perl Description : Enable all of the features of Modern Perl with one command Modern Perl programs use several modules to enable additional features of Perl and of the CPAN. Instead of copying and pasting all of these use lines, instead write only one: use Modern::Perl; For now, this only enables the strict and warnings pragmas, as well as all of the features available in Perl 5.10. It also enables C3 method resolution order; see perldoc mro for an explanation. In the future, it will include additional CPAN modules which have proven useful and stable. See http://www.modernperlbooks.com/mt/2009/01/toward-a-modernperl.html for more information, and http://www.modernperlbooks.com/ for further discussion of Modern Perl and its implications. -- 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/20100331025529.6721.8116.report...@skydancer.freeside.biz
Bug#575977: ITP: libautovivification-perl -- Lexically disable autovivification.
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libautovivification-perl Version : 0.05 Upstream Author : Vincent Pit, perl at profvince.com, http://www.profvince.com * URL : http://search.cpan.org/dist/autovivification/ * License : Perl Programming Lang: Perl Description : Lexically disable autovivification. When an undefined variable is dereferenced, it gets silently upgraded to an array or hash reference (depending of the type of the dereferencing). This behaviour is called autovivification and usually does what you mean (e.g. when you store a value) but it's sometimes unnatural or surprising because your variables gets populated behind your back. This is especially true when several levels of dereferencing are involved, in which case all levels are vivified up to the last, or when it happens in intuitively read-only constructs like exists. This pragma lets you disable autovivification for some constructs and optionally throws a warning or an error when it would have happened. -- 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/20100331031713.7020.16556.report...@skydancer.freeside.biz
Bug#575980: ITP: libdatetime-timezone-tzfile-perl -- Perl handling of tzfile (zoneinfo) timezone files
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libdatetime-timezone-tzfile-perl Version : 0.002 Upstream Author : Andrew Main (Zefram) zef...@fysh.org * URL : http://search.cpan.org/dist/DateTime-TimeZone-Tzfile * License : Perl Programming Lang: Perl Description : Perl handling of tzfile (zoneinfo) timezone files An instance of this class represents a timezone that was encoded in a file in the tzfile(5) format. These can express arbitrary patterns of offsets from Universal Time, changing over time. Offsets and change times are limited to a resolution of one second. This class implements the DateTime::TimeZone interface, so that its instances can be used with DateTime objects. -- 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/20100331034125.7455.74879.report...@skydancer.freeside.biz
Bug#575979: ITP: libautobox-dump-perl -- human/perl readable strings from the results of an EXPR
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libautobox-dump-perl Version : 20090426.1746 Upstream Author : Chas. J Owens IV, chas.owens at gmail.com * URL : http://search.cpan.org/dist/autobox-dump/ * License : Perl Programming Lang: Perl Description : Human/perl readable strings from the results of an EXPR The autobox::dump pragma adds, via the autobox pragma, a method to normal expression (such as scalars, arrays, hashes, math, literals, etc.) that produces a human/perl readable representation of the value of that expression. -- 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/20100331033615.7274.7296.report...@skydancer.freeside.biz
Bug#575983: ITP: libhash-merge-simple-perl -- Recursively merge two or more hashes, simply
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libhash-merge-simple-perl Version : 0.04 Upstream Author : Robert Krimen, rkrimen at cpan.org * URL : http://search.cpan.org/dist/Hash-Merge-Simple/ * License : Perl Programming Lang: Perl Description : Recursively merge two or more hashes, simply Hash::Merge::Simple will recursively merge two or more hashes and return the result as a new hash reference. The merge function will descend and merge hashes that exist under the same node in both the left and right hash, but doesn't attempt to combine arrays, objects, scalars, or anything else. The rightmost hash also takes precedence, replacing whatever was in the left hash if a conflict occurs. -- 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/20100331035347.7670.12588.report...@skydancer.freeside.biz
Bug#575984: ITP: libtaint-util-perl -- Test for and flip the taint flag without regex matches or eval
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libtaint-util-perl Version : 0.08 Upstream Author : Avar Arnfjoro Bjarmason a...@cpan.org * URL : http://search.cpan.org/dist/Taint-Util/ * License : Perl Programming Lang: Perl Description : Test for and flip the taint flag without regex matches or eval Wraps perl's internal routines for checking and setting the taint flag and thus does not rely on regular expressions for untainting or odd tricks involving eval and kill for checking whether data is tainted, instead it checks and flips a flag on the scalar in-place. -- 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/20100331035637.7737.31485.report...@skydancer.freeside.biz
Bug#575982: ITP: libindirect-perl -- Lexically warn about using the indirect object syntax.
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libindirect-perl Version : 0.19 Upstream Author : Vincent Pit, perl at profvince.com, http://www.profvince.com * URL : http://search.cpan.org/dist/indirect/ * License : Perl Programming Lang: Perl Description : Lexically warn about using the indirect object syntax. When enabled (or disabled as some may prefer to say, since you actually turn it on by calling no indirect), this pragma warns about indirect object syntax constructs that may have slipped into your code. This syntax is now considered harmful, since its parsing has many quirks and its use is error prone (when swoosh isn't defined, swoosh $x actually compiles to $x-swoosh). It currently does not warn for core functions (print, say, exec or system). This may change in the future, or may be added as optional features that would be enabled by passing options to unimport. This module is not a source filter. -- 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/20100331035038.7604.78416.report...@skydancer.freeside.biz
Bug#575986: ITP: libdatetime-timezone-systemv-perl -- Perl handling of System V and POSIX timezone strings
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libdatetime-timezone-systemv-perl Version : 0.003 Upstream Author : Andrew Main (Zefram) zef...@fysh.org * URL : http://search.cpan.org/dist/DateTime-TimeZone-SystemV/ * License : Perl Programming Lang: Perl Description : Perl handling of System V and POSIX timezone strings An instance of this class represents a timezone that was specified by means of a System V timezone string or the POSIX extended form of the same syntax. These can express a plain offset from Universal Time, or a system of two offsets (standard and daylight saving time) switching on a yearly cycle according to certain types of rule. This class implements the DateTime::TimeZone interface, so that its instances can be used with DateTime objects. -- 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/20100331041215.7934.24750.report...@skydancer.freeside.biz
Bug#575981: ITP: libdatetime-format-epoch-perl -- Convert DateTimes to/from epoch seconds
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libdatetime-format-epoch-perl Version : 0.11 Upstream Author : Eugene van der Pijll pi...@gmx.net * URL : http://search.cpan.org/dist/DateTime-Format-Epoch/ * License : Perl Programming Lang: Perl Description : Convert DateTimes to/from epoch seconds This module can convert a DateTime object (or any object that can be converted to a DateTime object) to the number of seconds since a given epoch. It can also do the reverse. -- 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/20100331034540.7530.67068.report...@skydancer.freeside.biz
Bug#575987: ITP: libdate-jd-perl -- Conversion between flavours of Julian Date
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libdate-jd-perl Version : 0.003 Upstream Author : Andrew Main (Zefram) zef...@fysh.org * URL : http://search.cpan.org/dist/Date-JD/ * License : Perl Programming Lang: Perl Description : Conversion between flavours of Julian Date For date and time calculations it is convenient to represent dates by a simple linear count of days, rather than in a particular calendar. This is such a good idea that it has been invented several times. If there were a single such linear count then it would be the obvious data interchange format between calendar modules. With several versions, calendar modules can use such sensible data formats and still have interoperability problems. This module tackles that problem, by performing conversions between different flavours of day count. These day count systems are generically known as Julian Dates, after the most venerable of them. Among Julian Date systems there are also some non-trivial differences of concept. There are systems that count only complete days, and those that count fractional days also. There are some that are fixed to Universal Time (time on the prime meridian), and others that are interpreted according to a timezone. Some consider the day to start at noon and others at midnight, which is semantically significant for the complete-day counts. The functions of this module appropriately handle the semantics of all the non-trivial conversions. The day count systems supported by this module are Julian Date, Reduced Julian Date, Modified Julian Date, Dublin Julian Date, Truncated Julian Date, Chronological Julian Date, Rata Die, and Lilian Date, each in both integral and fractional forms. -- 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/20100331041700.8010.89118.report...@skydancer.freeside.biz
Bug#575988: ITP: libdate-iso8601-perl -- Perl handling of the three ISO 8601 numerical calendars
Package: wnpp Severity: wishlist Owner: Ivan Kohler ivan-deb...@420.am Owner: Ivan Kohler ivan-deb...@420.am * Package name: libdate-iso8601-perl Version : 0.003 Upstream Author : Andrew Main (Zefram) zef...@fysh.org * URL : http://search.cpan.org/dist/Date-ISO8601/ * License : Perl Programming Lang: Perl Description : Perl handling of the three ISO 8601 numerical calendars The international standard ISO 8601 Data elements and interchange formats - Information interchange - Representation of dates and times defines three distinct calendars by which days can be labelled. It also defines textual formats for the representation of dates in these calendars. This module provides functions to convert dates between these three calendars and Chronological Julian Day Numbers, which is a suitable format to do arithmetic with. It also supplies functions that describe the shape of these calendars, to assist in calendrical calculations. It also supplies functions to represent dates textually in the ISO 8601 formats. ISO 8601 also covers time of day and time periods, but this module does nothing relating to those parts of the standard; this is only about labelling days. -- 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/20100331042000.8088.83001.report...@skydancer.freeside.biz
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
On Wed, Mar 31, 2010 at 12:15 AM, Joerg Jaspert jo...@debian.org wrote: On 12065 March 1977, Joerg Jaspert wrote: ries.debian.org, the host behind ftp-master.debian.org, has hardware trouble, a failed memory module keeps resetting the machine at random intervals. Will send a notice when service is back to normal. And another update for you all out there, waiting: After several ping-pongs the support finally understood that no round of firmware updates, changing slots of the DIMMs and trying whatever does not help, so we are now waiting for a new mainboard to arrive, as well as a technician. The current timeline lets us assume this is done, latest, day after tomorrow, please be patient. Will keep you updated when status changes. The backup plan still is moving this service to another machine. This hasn't been done yet for various reasons. One of them is simply that it took a little longer to move the remaining services away from it, but also the amount of work included. Now, should the technician not be able to resurrect ries, our backup plan extends to have the disks shipped over and replace the ones currently in rietz. I'm wondering if Debian has the resources (DSA, local admins and hardware) to have a hot-swappable backup machine for ftpmaster, since it does go down occasionally and when it does the downtime is fairly disruptive to Debian. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/i2oe13a36b31003302254h2ef20b6ey61f4922cee6ae...@mail.gmail.com
