Bug#691801: ITP: procenv -- utility to dump all aspects of its environment
Package: wnpp Severity: wishlist Owner: James Hunt * Package name: procenv Version : 0.5 Upstream Author : James Hunt * URL : https://launchpad.net/procenv/ * License : GPL-3.0+ Programming Lang: C Description : utility to dump all aspects of its environment Command-line tool that displays as much detail about itself and its environment as possible. It can be used as a test tool, to understand the type of environment a process runs in, and for comparing system environments. See blog post for example output and use-cases: http://ifdeflinux.blogspot.dk/2012/10/procenv-and-process-environment.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/20121029214235.18406.93104.reportbug@localhost6.localdomain6
Bug#691800: ITP: minieigen -- Small boost::python wrapper of parts of the Eigen library
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: minieigen Version : 0.3 Upstream Author : Václav Šmilauer * URL : http://www.launchpad.net/minieigen * License : LGPL-3.0+ Programming Lang: C++, Python Description : Small boost::python wrapper of parts of the Eigen library Small wrapper for core parts of Eigen, c++ library for linear algebra. It is mainly useful for inspecting c++ code which already uses eigen and boost::python. Supported types are Vectors (2,3,6 and dynamic-sized with integer and floating-point values), Matrices (3x3, 6x6 and dynamic-sized with floating-point values) and Quaternions. Numerous methods are wrapped and the original API of Eigen is followed. The package will be maintained in Debian-Science team. -- 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/20121029214118.26957.93766.report...@debian.home.debian
Bug#691799: ITP: pygts -- Python wrapper for the GNU Triangulated Surface library (GTS)
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: pygts Version : 0.3.1 Upstream Author : Thomas J. Duck * URL : http://pygts.sourceforge.net * License : LGPL-2.0 Programming Lang: C, Python Description : Python wrapper for the GNU Triangulated Surface library (GTS) PyGTS is a python package used to construct, manipulate, and perform computations on 3D triangulated surfaces. It is a hand-crafted and pythonic binding for the GNU Triangulated Surface (GTS) Library. The package will be maintained in Debian-Science team. -- 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/20121029194953.24358.20025.report...@debian.home.debian
Re: Towards d-i wheezy beta 4
Christian PERRIER, le Mon 29 Oct 2012 06:52:23 +0100, a écrit : > I just added cdebconf to the list of wished packages Yep it is. Samuel -- 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/20121029195419.gc5...@type.youpi.perso.aquilenet.fr
Re: Towards d-i wheezy beta 4
Quoting Cyril Brulebois (k...@debian.org): > If you want to see packages migrate from sid to testing before that, > please speak up. I'm tempted to keep everything l10n-ish for release > candidates (beta 4 might be the last beta). That's fair, yes. Gives me more time to use my whip on translators..and avoid you to bother with the many l10n uploads I recently did. I just added cdebconf to the list of wished packages (Samuel may want to confirm this as this is related to speech synthesis stuff). signature.asc Description: Digital signature
Re: Mandatory -dbg packages
On Mon, Oct 29, 2012 at 10:48:24AM +, Philip Ashmore wrote: > >>On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote: > >>>While this feature allows gdb to know the correct source locations, using > >>>it > >>>implies that packages requiring the feature contain incorrect source paths > >>>- > >>>wouldn't it be better for these packages to contain correct source paths in > >>>the first place? [...] > In Fedora, the dbg package includes the source code for the package, > and the debug information points to it. In Debian, they do not, and that's a feature; first, there are many valid use cases of using debug packages that do not require the source code. Second, having the source in the debug package implies duplication of said source, which is a waste of space. > In Fedora, by convention, such source code goes under /usr/src. Actually, on RPM-based systems, installing a source package implies the source goes in to /usr/src somewhere; even if you built an RPM source package with source living in $HOME, installing it will still make the source go into /usr/src. In that light, it makes sense that they have their debug packages point towards that directory. In Debian, installing a source package is just not possible technically; you can only unpack them. When you do that, by default they get unpacked in your current working directory. In other words, the location of the actual source in a source package on a Debian system is utterly unpredictable, and so there is no such concept as a "correct source location" on Debian-based systems. > If you prefer your users mess with .gdbinit so they can create a > useful stack trace then that's up to you. There is no need for source to be able to produce a useful stack trace; the file and function names are part of the debugging symbols. In other words, once you install the debugging symbols -- regardless of where they think the source lives -- you will be able to produce a useful stack trace. The only reason why you'd want to connect the source to the debugging symbold is because you need to connect the original source lines to the object code that you're inspecting -- e.g., because you're single-stepping through a library. While doing that can be useful in some corner cases, it's not something I expect a random user would ever need to do. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. signature.asc Description: Digital signature
Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool
On Sun, Oct 28, 2012 at 08:03:02AM +0100, Philipp Kern wrote:
> I'd prefer if such a tool could replace an existing one. Why not aim at
> replacing dput if there's a reason for it?
I must concur. I can't see the reason for dput, dupload and dput-ng to
co-exist. If dput-ng has the momentum and is a superset of the features of the
previous two we should remove the previous two. I use the royal 'we', too often
we hide behind our package-centric view of the world ("package A is not
actively maintained. Package B reimplements it. Removing Package A is inactive
maintainer C's problem."). But having a plethora of
similar-but-slightly-different tools to do the same job increase the surface
area of stuff for beginners to navigate through and makes it that much harder
for contributors to get a handle on things.
--
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/20121029151928.GB27366@debian
Re: Mandatory -dbg packages
Hello! Stefano Rivera has written on Monday, 29 October, at 16:57: >Hi Tzafrir (2012.10.29_16:29:06_+0200) >> While clearing your throat, mind telling us how this works in Ubuntu >> with PPAs? What happens if you installed a package from a PPA and you >> want to generate a backtrace of a program that happens to use that >> package? >> 1. You'll get debug information for the package. >> 2. You won't get debug information for the package. >> 3. You may accidentally get debug information for a diffent version of >>the package. >2. It'll tell you that there aren't any debug symbols available. (IIRC) >The -dbgsym packages are only generated in primary archive builds. I'm sorry to disappoint you about the Ubuntu PPAs but look into my PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see all those dbg packages. And users were used them to give me feedback to bugs with full backtrace. Cheers! Andriy. -- 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/20121029151841.gb9...@rep.kiev.ua
Re: Mandatory -dbg packages
Hi Tzafrir (2012.10.29_16:29:06_+0200) > While clearing your throat, mind telling us how this works in Ubuntu > with PPAs? What happens if you installed a package from a PPA and you > want to generate a backtrace of a program that happens to use that > package? > > 1. You'll get debug information for the package. > 2. You won't get debug information for the package. > 3. You may accidentally get debug information for a diffent version of >the package. 2. It'll tell you that there aren't any debug symbols available. (IIRC) The -dbgsym packages are only generated in primary archive builds. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20121029145730.gd1...@bach.rivera.co.za
Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool
On Mon, Oct 29, 2012 at 03:53:42PM +0100, Wouter Verhelst wrote: > Wrong. It will be a new thing, not related to the previous thing. It's evidently related: if not in terms of actual reused code but in terms of who is expected to use it and what it is to be used for. > On Sun, Oct 28, 2012 at 01:19:31PM -0400, Michael Gilbert wrote: > > I don't see the harm in calling things what they actually are. > > It's rude. In your opinion. I disagree. -- 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/20121029145855.GA27366@debian
Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool
On Sun, Oct 28, 2012 at 01:19:31PM -0400, Michael Gilbert wrote: > On Sun, Oct 28, 2012 at 12:25 PM, Wouter Verhelst wrote: > > If not, why are you claiming to replace their code? It's fine to be > > writing "something else" to replace older code; but it's fairly rude to > > be claiming that whatever you're writing is the "next generation" of > > that older code > > Any rewrite will be a "next generation" of the previous thing. Wrong. It will be a new thing, not related to the previous thing. > I don't see the harm in calling things what they actually are. It's rude. > There were probably some hurt feelings on the Star Trek staff when > Star Trek: TNG came around, but that's not sufficient justification to > stop the writers of that show from calling it what they wanted to call > it. This is totally irrelevant to the discussion at hand. Even so: - The "next generation" in TNG is about the characters (who are a generation younger than the original series), not about the show. - The original guy who came up with the original star trek was also involved with TNG. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121029145342.gj24...@grep.be
Re: Mandatory -dbg packages
On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote: > Yeah, in (cough)Fedora, kdbg even offers to download and install debug > packages for you. > Debug packages also make back-traces more than useless, and > (cough)Ubuntu offers to download debug packages which it installs and > re-examines the back-trace to see if more are needed. While clearing your throat, mind telling us how this works in Ubuntu with PPAs? What happens if you installed a package from a PPA and you want to generate a backtrace of a program that happens to use that package? 1. You'll get debug information for the package. 2. You won't get debug information for the package. 3. You may accidentally get debug information for a diffent version of the package. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- 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/20121029142905.gx12...@pear.tzafrir.org.il
Re: Mandatory -dbg packages
On 29/10/12 07:25, Neil Williams wrote: On Mon, 29 Oct 2012 08:53:05 +0800 Paul Wise wrote: On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote: While this feature allows gdb to know the correct source locations, using it implies that packages requiring the feature contain incorrect source paths - wouldn't it be better for these packages to contain correct source paths in the first place? There is no such thing as a "correct source path", I unpack source tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John Doe uses ~/src/debian/pool/f/foo/foo-0.1/. The "correct source path" for gdb is whatever the user has put into ~/.gdbinit - the paths inside the package don't matter. dir /path/one/ dir /path/another/ In Fedora, the dbg package includes the source code for the package, and the debug information points to it. In Fedora, by convention, such source code goes under /usr/src. If you prefer your users mess with .gdbinit so they can create a useful stack trace then that's up to you. Philip -- 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/508e5ef8.6010...@philipashmore.com
Re: Mandatory -dbg packages
Michael Biebl wrote: >Afaik the work was started by pochu as port of GSoC [1][2]. According >to >[3], Marc was his mentor. I've CCed both, maybe they can comment on >what's still missing. >I'd love to see that happen. Joss ended up being the mentor (melange lists this correctly). I don't remember at all how this worked out... Marc -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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/574f2c09-8cbc-483a-8ec2-3155c1a86...@email.android.com
Re: Mandatory -dbg packages
On Mon, 29 Oct 2012 08:53:05 +0800 Paul Wise wrote: > On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote: > > > While this feature allows gdb to know the correct source locations, using it > > implies that packages requiring the feature contain incorrect source paths - > > wouldn't it be better for these packages to contain correct source paths in > > the first place? > > There is no such thing as a "correct source path", I unpack source > tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John > Doe uses ~/src/debian/pool/f/foo/foo-0.1/. The "correct source path" for gdb is whatever the user has put into ~/.gdbinit - the paths inside the package don't matter. dir /path/one/ dir /path/another/ -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpIxNgCino3A.pgp Description: PGP signature
Re: Bug#690142: marked as done (remote named DoS on recursor (CVE-2012-5166))
On Mon, Oct 29, 2012 at 12:13:19PM +1300, Matthew Grant wrote: > This is a notice that the bind9 9.8.1.dfsg.P1-4.x package might be > replaced, after going through the appropriate channels (Debian Release > Team). LaMont will be uploading our work to wheezy-proposed shortly. In any case the security fix should migrate to testing first. If needed the urgency can be bumped. Please also discuss the upload to unstable with the release team first, to avoid wasted effort. The latter sentence sounds Ubuntu-ish, you'll be targetting unstable, not t-p-u. Kind regards Phliipp Kern signature.asc Description: Digital signature
