Re: New Menu category Applictions/Multimedia
Le mardi 16 février 2010 à 08:15 +0900, Charles Plessy a écrit : > to achieve this reasonnable default, the maintainers of programs with a menu > entry need some instructions whether they should hide their entry in the major > desktop managers like GNOME, KDE and Xfce. Add the relevant snippets to the .desktop file. To not display it by default: NoDisplay=true To display it only for GNOME and Xfce: OnlyShowIn=GNOME;XFCE; To display it everywhere but in GNOME: NotShowIn=GNOME > Could the GNOME team show the way and issue a couple of guidelines? For > instance what to do if there is no icon available or the icon does not have an > alpha channel? Is it a hint that the entry should not show up in the GNOME > menu? No, this is just a hint that the application is not maintained upstream enough to have a decent icon. For the sake of consistency, it is better if all applications can have 22×22 PNG or SVG icons, but I don’t think this should dictate whether an application belongs in the menu or not. > For the moment, my personnal policy is to always add a FreeDesktop menu entry > and a Debian menu entry whenever the program is graphical. But I would be most > happy to make the FreeDesktop entry conform to the vision of the teams who > make > the desktop managers available to our users. >From what I understand, some applications you are packaging will not be installed except by people who know they want them, so it’s not really a problem. Things get different for the Debian-Med blend, for example. If you install an important number of such applications, you have to wonder which ones you want to really show by default. And this is not something the GNOME team can be helpful with, since we have no idea what they do :) Cheers, -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1266309551.737.9.ca...@meh
Re: Bug#569079: ITP: python-xdgapp -- Python XDG application library
Hi! On Wed, 2010-02-10 at 14:36:03 -0500, Luke Faraone wrote: > On Wed, Feb 10, 2010 at 09:52, Guillem Jover wrote > >What does this provide that python-xdg does not? > > It's depended on by https://launchpad.net/groundcontrol, and > provides a wrapper around some xdg functions. Ah ok, I see it's depending on python-xdg. But still looking at the sources it seems pretty small, around 150 lines of python code, do you know if upstream tried to send that to python-xdg upstream? They might accept it. thanks, guillem -- 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/20100216143601.gc...@gaara.hadrons.org
Bug#570109: ITP: libmath-interpolator-perl -- interpolate between lazily-evaluated points
Package: wnpp Severity: wishlist Owner: "Steffen Möller" * Package name: libmath-interpolator-perl Version : 0.0.3 Upstream Author : Andrew Main (Zefram) * URL : http://search.cpan.org/dist/Math-Interpolator/ * License : GPL or Artistic Programming Lang: Perl Description : interpolate between lazily-evaluated points This class supports interpolation of a curve between known points, known as "knots", with the knots being lazily evaluated. An object of this type represents a set of knots on a one-dimensional curve, the knots possibly not being predetermined. The methods implemented in this class extract knots, forcing evaluation as required. Subclasses implement interpolation by various algorithms. . This code is neutral as to numeric type. The coordinate values used in interpolation may be native Perl numbers, Math::BigRat objects, or possibly other types. Mixing types within a single interpolation is not recommended. -- 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/20100216144804.5113.24306.report...@toshiba.siemens
Re: Missing libstdc++5 for 3rd party software
On 02/15/2010 05:03 PM, Matthias Klose wrote: Is there any chance of getting libstdc++5 back in oldlibs? I don't intend to restore either libstdc++5 or libstdc++2.10-glibc2.2. i'll add them to http://forwardports.debian-maintainers.org/. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- 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/4b7aba1b.6020...@debian.org
unit test generator for shared C/C++ library API
Dear colleagues,
Linux Verification Center at the Institute for System Programming of RAS
and the Linux Foundation have released a free unit test generator for
shared C/C++ library API. It helps to quickly generate simple ("sanity"
or "shallow"-quality) tests for all functions from the library API using
their signatures and data type definitions straight from the library
header files. The quality of generated tests allows to check absence of
critical errors in simple use cases and can be improved by involving of
highly reusable specialized types for the library. API Sanity Autotest
can execute generated tests and detect all kinds of emitted signals,
early program exits, program hanging and specified requirement failures.
API Sanity Autotest can be considered as a tool for low-cost sanity
checking of library API or as a powerful test development framework.
Also it supports universal Template2Code format of tests, random test
generation mode and other useful features. This tool is free software:
you can redistribute it and/or modify it under the terms of the GNU GPLv2.
We suppose this tool can be very useful for shared library developers
and recommend it for including to Debian Linux.
For more information, please see:
http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest
Andrey Ponomarenko
Linux Verification Center at the Institute for System Programming of RAS
--
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/4b7ab9df.7060...@ispras.ru
Downgrading a package to get it into upcoming release
Hi all, I am looking for some advise / opinions. I am working with guys from MongoDB project to get stable package in Debian. We have currently version 1.3.1 in unstable, this is considered as development branch which is not very stable. Is there any way how to reasonably push older version (1.2.x which is considered stable), which has not been in Debian before to enable its inclusion in upcoming Debian freeze/stable release? Thank you, Antonin -- 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/20100216160417.gh25...@bobek.cz
Re: Downgrading a package to get it into upcoming release
On Tue, 16 Feb 2010, Antonin Kral wrote: Hi all, I am looking for some advise / opinions. I am working with guys from MongoDB project to get stable package in Debian. We have currently version 1.3.1 in unstable, this is considered as development branch which is not very stable. Is there any way how to reasonably push older version (1.2.x which is considered stable), which has not been in Debian before to enable its inclusion in upcoming Debian freeze/stable release? You could use epochs to make the old version have a newer version number according to dpkg. I don't know how distasteful that is, though. -- Asheesh. -- Your temporary financial embarrassment will be relieved in a surprising manner. -- 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/alpine.deb.2.00.1002161209520.10...@localhost
Re: Downgrading a package to get it into upcoming release
On Tue, 16 Feb 2010 at 17:04:17 +0100, Antonin Kral wrote: > We have currently > version 1.3.1 in unstable, this is considered as development branch > which is not very stable. If you consider one of your packages to be unsuitable for a stable release, you should ensure that it has a release critical (serious, grave or critical) bug to stop it from propagating to testing automatically. In this case it'd be appropriate to file a bug against version 1.3.1, "mongodb: 1.3.x unsuitable for stable in maintainer's opinion", then close it in version 1:1.2.x (assuming you use epochs as someone else suggested). I see mongodb has accumulated high-severity bugs at an impressive rate already, though, so it's in no immediate danger of migrating... S -- 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/20100216172457.ga15...@reptile.pseudorandom.co.uk
Re: Downgrading a package to get it into upcoming release
hi, On Tue, Feb 16, 2010 at 12:10:16PM -0500, Asheesh Laroia wrote: > You could use epochs to make the old version have a newer version > number according to dpkg. I don't know how distasteful that is, > though. it also might be a bit disruptive for those who have already installed the newer version of this package, don't know if you care about that. if you do, a suggestion: * keep the current development version in unstable * report an RC bug against the development version to keep it from testing, and ask the release team to boot it from testing if it's already there. * upload a new "stable" version to unstable, using a different naming scheme for source and binary packages, complete with the respective conflicts/replaces/provides etc. (i.e. Binary: mongodb-1.2) * once debian has released squeeze, upload transitional packages to force users to migrate to the "development" version. sean signature.asc Description: Digital signature
Re: Downgrading a package to get it into upcoming release
On 16/02/2010 17:04, Antonin Kral wrote: > Hi all, > > I am looking for some advise / opinions. I am working with guys from > MongoDB project to get stable package in Debian. We have currently > version 1.3.1 in unstable, this is considered as development branch > which is not very stable. > > Is there any way how to reasonably push older version (1.2.x which is > considered stable), which has not been in Debian before to enable its > inclusion in upcoming Debian freeze/stable release? 1) Can the two programs be installed together? If yes, simply build a MongoDB1.2 and a MongoDB1.3. If not, then you should use epochs: upload MongoDB 1:1.2 to unstable, and MongoDB 1:1.3 to experimental. -- Jean-Christophe Dubacq -- 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/4b7ad49b.4070...@free.fr
Re: Downgrading a package to get it into upcoming release
On Tue, 16 Feb 2010 18:23:39 +0100 Jean-Christophe Dubacq wrote: > On 16/02/2010 17:04, Antonin Kral wrote: > > Hi all, > > > > I am looking for some advise / opinions. I am working with guys from > > MongoDB project to get stable package in Debian. We have currently > > version 1.3.1 in unstable, this is considered as development branch > > which is not very stable. > > > > Is there any way how to reasonably push older version (1.2.x which is > > considered stable), which has not been in Debian before to enable its > > inclusion in upcoming Debian freeze/stable release? > > 1) Can the two programs be installed together? > > If yes, simply build a MongoDB1.2 and a MongoDB1.3. > > If not, then you should use epochs: upload MongoDB 1:1.2 to unstable, > and MongoDB 1:1.3 to experimental. all of these seem like rather complicated solutions. wouldn't it be a bit simpler to ask for removal from both testing and unstable, then once that happens, upload the old (known stable) version of the package? mike -- 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/20100216125234.203850ce.michael.s.gilb...@gmail.com
Re: Downgrading a package to get it into upcoming release
On Tue, 16 Feb 2010 12:52:34 -0500 Michael Gilbert wrote: > On Tue, 16 Feb 2010 18:23:39 +0100 Jean-Christophe Dubacq wrote: > > > On 16/02/2010 17:04, Antonin Kral wrote: > > > Hi all, > > > > > > I am looking for some advise / opinions. I am working with guys from > > > MongoDB project to get stable package in Debian. We have currently > > > version 1.3.1 in unstable, this is considered as development branch > > > which is not very stable. > > > > > > Is there any way how to reasonably push older version (1.2.x which is > > > considered stable), which has not been in Debian before to enable its > > > inclusion in upcoming Debian freeze/stable release? > > > > 1) Can the two programs be installed together? > > > > If yes, simply build a MongoDB1.2 and a MongoDB1.3. > > > > If not, then you should use epochs: upload MongoDB 1:1.2 to unstable, > > and MongoDB 1:1.3 to experimental. > > all of these seem like rather complicated solutions. wouldn't it be a > bit simpler to ask for removal from both testing and unstable, then once > that happens, upload the old (known stable) version of the package? oh, you would probably need a conflicts with the newer version and a README.Debian to explain what to do for users with the new version already installed. mike -- 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/20100216125516.a68441f8.michael.s.gilb...@gmail.com
Re: Downgrading a package to get it into upcoming release
On 2010-02-16 18:55 +0100, Michael Gilbert wrote: >> all of these seem like rather complicated solutions. wouldn't it be a >> bit simpler to ask for removal from both testing and unstable, then once >> that happens, upload the old (known stable) version of the package? > > oh, you would probably need a conflicts with the newer version and a > README.Debian to explain what to do for users with the new version > already installed. Except that these users will never even see it if the version in the archive is lower than the one they have installed. Your proposal seems like a non-starter to me. 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/87iq9xt5t0@turtle.gmx.de
Re: Downgrading a package to get it into upcoming release
On 2/16/10, Sven Joachim wrote: > On 2010-02-16 18:55 +0100, Michael Gilbert wrote: > >>> all of these seem like rather complicated solutions. wouldn't it be a >>> bit simpler to ask for removal from both testing and unstable, then once >>> that happens, upload the old (known stable) version of the package? >> >> oh, you would probably need a conflicts with the newer version and a >> README.Debian to explain what to do for users with the new version >> already installed. > > Except that these users will never even see it if the version in the > archive is lower than the one they have installed. Your proposal seems > like a non-starter to me. how about versioning it something like 1.3.1-1+reverted1.2.1? mike -- 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/8e2a98be1002161021p25e2a651kb6866337a0123...@mail.gmail.com
Re: Bits from the NM people
Quoting Jan Dittberner on 2010-02-13 12:19:06: > There are surely more ways to show activity even without uploading packages or > doing other packaging work. Hear, hear. From what I've seen, packaging seems to be the 'sexiest' role a DM/DD could take on, and the most visible role. But what would a quality Free OS be without the infrastructure? Wikis, IRC, repositories, listserv... Somewhere on d.o is an excellent FAQ, IIRC -- I don't have a connection as I'm writing this. -- _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org / \ Any technology distinguishable from magic is insufficently advanced. signature.asc Description: Digital signature
Status of systemtap in Debian
[ M-F-T set to debian-devel@ ] Hi, Systemtap[1] is a tool allowing to dynamically insert probes in the Linux kernel, similarly to what is possible with DTrace on Solaris. [1] http://sourceware.org/systemtap/ The state of systemtap in Debian is currently worrying. First, the package has been orphaned (#568866). I'm willing to take over maintenance, but there's another, bigger problem: the Debian kernels don't provide debuginfo, so they are unsuitable for use with systemtap. Users are required to build a custom kernel. This has been discussed at length in #365349, and the blockers are: - disk space on buildds: at least 2 GiB are required to build a kernel with debuginfo. (that doesn't sound too hard to satisfy) - mirror space: each debug .deb would use ~ 450 MB (see http://ddebs.ubuntu.com/pool/main/l/linux/) Debian is currently the only major distro where users are required to build their own kernel to use systemtap, so I think that we should try to support it, at least for some kernel flavors and some architectures. Kernel, buildd and mirror people, what do you think? Thanks, -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100216201306.ga17...@xanadu.blop.info
Re: Status of systemtap in Debian
On 2010-02-16, Lucas Nussbaum wrote: > Systemtap[1] is a tool allowing to dynamically insert probes in the > Linux kernel, similarly to what is possible with DTrace on Solaris. > [1] http://sourceware.org/systemtap/ > > The state of systemtap in Debian is currently worrying. First, the > package has been orphaned (#568866). I'm willing to take over > maintenance, but there's another, bigger problem: the Debian kernels > don't provide debuginfo, so they are unsuitable for use with systemtap. > Users are required to build a custom kernel. > This has been discussed at length in #365349, and the blockers are: > > - disk space on buildds: at least 2 GiB are required to build a kernel > with debuginfo. (that doesn't sound too hard to satisfy) > > - mirror space: each debug .deb would use ~ 450 MB (see > http://ddebs.ubuntu.com/pool/main/l/linux/) > > Debian is currently the only major distro where users are required to > build their own kernel to use systemtap, so I think that we should try > to support it, at least for some kernel flavors and some > architectures. > > Kernel, buildd and mirror people, what do you think? Is that supported on all architectures or is it architecture-specific? Would it be sufficient to provide that infrastructure on the fast arches? I'm concerned how much it increases the build process on our slow architectures, especially considering that you need to write a lot more to disk than it used to and I/O is not that fast. I guess we can arrange it for i386, amd64, powerpc, s390 and ia64 buildd- wise. Kind regards Philipp Kern -- 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/slrnhnm0d7.nc7.tr...@kelgar.0x539.de
Re: Status of systemtap in Debian
Hello, 16 лютого 2010 о 20:35 + Philipp Kern написав(-ла): > Is that supported on all architectures or is it architecture-specific? Systemtap now supports only i386/amd64/ia64/armel/powerpc/s390. > Would it be sufficient to provide that infrastructure on the fast > arches? I'm concerned how much it increases the build process on our > slow architectures, especially considering that you need to write a lot > more to disk than it used to and I/O is not that fast. > > I guess we can arrange it for i386, amd64, powerpc, s390 and ia64 buildd- > wise. > > Kind regards > Philipp Kern > > > > -- > 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/slrnhnm0d7.nc7.tr...@kelgar.0x539.de > signature.asc Description: Digital signature
Re: Status of systemtap in Debian
On 16/02/10 at 20:35 +, Philipp Kern wrote: > On 2010-02-16, Lucas Nussbaum wrote: > > Systemtap[1] is a tool allowing to dynamically insert probes in the > > Linux kernel, similarly to what is possible with DTrace on Solaris. > > [1] http://sourceware.org/systemtap/ > > > > The state of systemtap in Debian is currently worrying. First, the > > package has been orphaned (#568866). I'm willing to take over > > maintenance, but there's another, bigger problem: the Debian kernels > > don't provide debuginfo, so they are unsuitable for use with systemtap. > > Users are required to build a custom kernel. > > This has been discussed at length in #365349, and the blockers are: > > > > - disk space on buildds: at least 2 GiB are required to build a kernel > > with debuginfo. (that doesn't sound too hard to satisfy) > > > > - mirror space: each debug .deb would use ~ 450 MB (see > > http://ddebs.ubuntu.com/pool/main/l/linux/) > > > > Debian is currently the only major distro where users are required to > > build their own kernel to use systemtap, so I think that we should try > > to support it, at least for some kernel flavors and some > > architectures. > > > > Kernel, buildd and mirror people, what do you think? > > Is that supported on all architectures or is it architecture-specific? Systemtap requires CONFIG_KPROBES, which is architecture specific. It works on x86(_64), ia64, arm, sparc, s390, powerpc. > Would it be sufficient to provide that infrastructure on the fast > arches? I'm concerned how much it increases the build process on our > slow architectures, especially considering that you need to write a lot > more to disk than it used to and I/O is not that fast. > > I guess we can arrange it for i386, amd64, powerpc, s390 and ia64 buildd- > wise. Well, anything would be better than the current situation. I'd be fine with i386 and amd64 for one kernel flavor for squeeze, but the more, the better ;) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100216210525.ga20...@xanadu.blop.info
Re: Status of systemtap in Debian
On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > [ M-F-T set to debian-devel@ ] > > Hi, > > Systemtap[1] is a tool allowing to dynamically insert probes in the > Linux kernel, similarly to what is possible with DTrace on Solaris. > [1] http://sourceware.org/systemtap/ > > The state of systemtap in Debian is currently worrying. First, the > package has been orphaned (#568866). I'm willing to take over > maintenance, but there's another, bigger problem: the Debian kernels > don't provide debuginfo, so they are unsuitable for use with systemtap. > Users are required to build a custom kernel. > This has been discussed at length in #365349, and the blockers are: > > - disk space on buildds: at least 2 GiB are required to build a kernel > with debuginfo. (that doesn't sound too hard to satisfy) > > - mirror space: each debug .deb would use ~ 450 MB (see > http://ddebs.ubuntu.com/pool/main/l/linux/) > > Debian is currently the only major distro where users are required to > build their own kernel to use systemtap, so I think that we should try > to support it, at least for some kernel flavors and some > architectures. > > Kernel, buildd and mirror people, what do you think? The kernel team discussed this at our face to face meeting (due to some prompting from the 'crash' maintainer), and I don't remember any objections other than those you brought up. We also discussed limiting the archs/flavors for which we provide debug data to the more popular images, and those best supported by debug tools like crash, systemtap, etc). In addition, this data would probably make more sense to store outside of the normal/widely-mirrored repository (I believe a debug repo has been discussed before?) Our next planned step was for me to contact the buildd/ftpmaster teams about it, which I apparently never did :( -- dann frazier -- 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/20100216205405.ga11...@lackof.org
Re: Status of systemtap in Debian
On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > > - disk space on buildds: at least 2 GiB are required to build a kernel > with debuginfo. (that doesn't sound too hard to satisfy) There currently are packages that require more diskspace than that, for instance the linux-2.6 package on i386 uses 4.7 GB, while it uses 2.6 GB on amd64. I guess it requires an additional 450 MB per kernel flavor or maybe a multiple of that for temporary files that also contain that? The biggest package I could find in a short time seem to be: qt4-x11:7818730k (8058048k latest) openoffice.org: 7652264k (7629368k latest) openjdk-6: 7152062k (7443004k latest) linux-2.6: 4707725k (6319992k latest) opencascade:4619392k (4619392k latest) wxwidgets2.8: 4215131k (4297664k latest) ghc6: 4015377k (4689676k latest) slicer: 3680980k (3680980k latest) gcc-snapshot: 3663284k (3663284k latest) pyside: 3548760k (3548760k latest) boost1.38: 3497562k (3630040k latest) (This is acros several arches.) Do you know if there is any cost in cpu time for this? Kurt -- 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/20100216211726.ga20...@roeckx.be
Re: Status of systemtap in Debian
On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > - disk space on buildds: at least 2 GiB are required to build a kernel > with debuginfo. (that doesn't sound too hard to satisfy) A typical build includes between 2 and 10 of them. > - mirror space: each debug .deb would use ~ 450 MB (see > http://ddebs.ubuntu.com/pool/main/l/linux/) Our archive does not support ddebs. Bastian -- Deflector shields just came on, Captain. -- 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/20100216212730.ga15...@wavehammer.waldi.eu.org
Re: Status of systemtap in Debian
On 16/02/10 at 22:27 +0100, Bastian Blank wrote: > On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > > - disk space on buildds: at least 2 GiB are required to build a kernel > > with debuginfo. (that doesn't sound too hard to satisfy) > > A typical build includes between 2 and 10 of them. Ah, I missed that. Provided the build of the different are sequential, the tree is not cleaned up between builds? So that means at most 20 GiB, which probably excludes more buildds. > > - mirror space: each debug .deb would use ~ 450 MB (see > > http://ddebs.ubuntu.com/pool/main/l/linux/) > > Our archive does not support ddebs. Why couldn't it be done using a normal deb? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100216214745.ga22...@xanadu.blop.info
Re: dpkg source format 3.0 (git)
Jonathan Nieder wrote: > For usability: I imagine what is typically needed is the set of Vcs-Git > fields somewhere conveniently machine-readable, so one could just go > > apt-get source --git whatever > > and get a checkout of its packaging repository. ... which is what debcheckout provides, though I didn’t know it. Thanks to Stefano Zacchiroli for writing it! > Selfishly, I guess if someone implements the 90% solution above, I > would stop caring so much about what source format the buildds use. > Others might be more principled, though. ;-) So indeed, I do not think git-based distributed source packages are worth worrying about yet. In those places where git.debian.org and co are not good enough, I suspect it would be a better use of time to try to improve connectivity. Jonathan -- 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/20100216215855.ga3...@progeny.tock
Re: Downgrading a package to get it into upcoming release
* Simon McVittie [2010-02-16 20:26] wrote: > bug to stop it from propagating to testing automatically. In this case it'd be > appropriate to file a bug against version 1.3.1, "mongodb: 1.3.x unsuitable > for stable in maintainer's opinion", then close it in version 1:1.2.x > (assuming you use epochs as someone else suggested). Absolutely, I've already filled that bug. I will probably go down the path of building another binary package (mongodb-1.2) which I'll then make obsolete, as Sean suggested. Epochs as well as +reverted will definitely work but looks a bit too hackish to me. Anyway, I would like to than everybody for suggestions. > I see mongodb has accumulated high-severity bugs at an impressive rate > already, though, so it's in no immediate danger of migrating... And it looked like pretty quiet afternoon at the beginning :) Some of them are more about personal taste / point of view I would say. Thanks, Antoni -- 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/20100216214736.gb5...@bobek.cz
Bug#570150: ITP: z80ex -- Emulation library for z80 CPUs.
Package: wnpp Severity: wishlist Owner: Adrian Glaubitz Hi, this is a emulation library for z80 CPUs. It is required for the kcemu KC85/4 emulator developed by Thorsten Paul which I also packaged (#538914). But it may also be used for other emulators. Adrian * Package name: z80ex Version : 1.1.18 Upstream Author : boo_...@inbox.ru * URL : http://z80ex.sourceforge.net/ * License : GPL Programming Lang: C Description : Emulation library for z80 CPUs. Emulation library for z80 CPUs. -- 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/20100216220458.12172.54801.report...@z6.physik.fu-berlin.de
Bug#570175: ITP: libhttp-parser-xs-perl -- simple and fast HTTP request parser
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libhttp-parser-xs-perl Version : 0.05 Upstream Author : Kazuho Oku * URL : http://search.cpan.org/dist/HTTP-Parser-XS/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : simple and fast HTTP request parser HTTP::Parser::XS is a fast, primitive HTTP request parser that can be used either for writing a synchronous HTTP server or a event-driven server. It is designed primarily for use with the Plack toolkit. NOTE: this module is not explicitly required for Plack to function, but it is part of Task::Plack and designed to accelerate its HTTP request parsing. -- 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/d1b732a71002161817g4c431298ybcbbc61014a10...@mail.gmail.com
Re: unit test generator for shared C/C++ library API
[CCing you since I presume you are not subscribed] On Tue, Feb 16, 2010 at 11:29 PM, Andrey Ponomarenko wrote: > We suppose this tool can be very useful for shared library developers > and recommend it for including to Debian Linux. > For more information, please see: > http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest If you would like to get your software included in Debian, the best way to do so is package it yourself and get the package sponsored. Here are some links you may want to look at: http://www.debian.org/doc/maint-guide/ http://people.debian.org/~mpalmer/debian-mentors_FAQ.html http://ftp-master.debian.org/REJECT-FAQ.html http://wiki.debian.org/SponsorChecklist http://wiki.debian.org/GettingPackaged http://wiki.debian.org/DebianMaintainer http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/developers-reference/ -- 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/e13a36b31002161847q6fd9e885o921c5d3041c74...@mail.gmail.com
Bug#570180: ITP: docky -- Elegant, powerful, clean dock
Package: wnpp Severity: wishlist Owner: Christopher James Halse Rogers * Package name: docky Version : 2.0.0 Upstream Author : Jason Smith * URL : https://launchpad.net/docky * License : GPL-3+ Programming Lang: C#, Python Description : Elegant, powerful, clean dock Provides an application launcher, running application management, and various "docklets" including a CPU monitor, weather report and clock. It is similar to other docks such as AWN and cairo-dock. . Applications can integrate with Docky to add extra items to their context menus or modify their icons to display more information. This package includes integration helpers for a number of applications, including Banshee, Rhythmbox, Deluge, Tomboy and Zeitgeist. . Docky is derived from the GNOME Do "docky" interface. -- 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/20100217011952.27960.55357.report...@ed.cooperteam.net
Re: Flag images
On lun., 2010-02-15 at 12:03 -0800, Don Armstrong wrote: > Flags are a poor representation of a particular language, and language > selection is better handled using locales and content-negotiation > anyway. [There are many examples where a country speaks many > languages, and examples where multiple countries have the same > language, but different dialects.] But flags (as an image) /are/ a quick way to identify a locale. Sometime they don't exactly overlap, thus the above problem, but they are still useful. Maybe not in content-negotiation, but for example to switch between locales easily, to switch keyboard mapping, to ask for some content different from the current locales, etc. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
