Bug#603336: ITP: classads -- library for Condor's classads expression language
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: classads Version : 1.0.9 Upstream Author : Condor Team * URL : http://www.cs.wisc.edu/condor/classad * License : Apache Programming Lang: C++, Description : library for Condor's classads expression language A classad (classified ad) is a mapping from attribute names to expressions. In the simplest cases, the expressions are simple constants (integer, floating point, or string), thus a form of property list. Attribute expressions can also be more complicated. There is a protocol for evaluating an attribute expression of a classad vis a vis another ad. Two classads match if each ad has attribute requirements that evaluate to true in the context of the other ad. Classad matching is used by the Condor central manager to determine the compatibility of jobs and workstations where they may be run. This package is necessary for packaging Condor itself (#602842). Ubuntu has a classads package that served as starting point of this effort. Here is the current list of changes on top of that: * Shorten and slightly improve package descriptions. * Raise debhelper compat to 7 (already build-depended on >7). * Add another binary package 'classads' to install the command line utilities. Keeping them in the runtime library package would have made it impossible to co-install a future libclassad1 package, due to file conflicts. * Move to an unversioned -dev package. There is no intention to maintain multiple library versions in parallel. * No longer install unneeded .la files (squeeze release goal). * No longer install duplicate license files as docs. * Add VCS information to debian/control. * Move to a DEP-5 compliant debian/copyright. * Improve clean target in debian/rules to remove all temporary files. The packaging is available at: http://git.debian.org/?p=pkg-exppsy/classads.git -- GPG key: 4096R/7FFB9E9B Michael Hanke http://mih.voxindeserto.de -- 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/20101113080343.ga6...@meiner
Re: Squeeze Artwork: selection of default theme
[Mark Brown] > This is the first time I've heard of the -desktop list. Great to hear that you now know about the location of artwork discussions, given that you imply by posting here that you are interested in such work. > Honestly I'd have expected something like this to show up on -devel, > or at least -devel-announce, at some point. And I do not expect it, I must admit. Everyone do not get a say on most decisions made in Debian, and this is a good thing to speed up development and keep the overhead of decisions low. This time you (and I) did not get to provide input on the visual profile for Squeeze, but a lot of people were involved in the process and I trust them to do good work. I see no need for a rematch, nor any need to try to overrule those doing this work. I believe it is well within the scope and authority of the desktop group to make such decision, and am happy there are people working on the visual profile in Debian. Happy hacking, -- Petter Reinholdtsen -- 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/2flvd41setg@login1.uio.no
source package format 3.0 with multiple tar balls
Hi,
I can't get $subject to work, and the wiki page
http://wiki.debian.org/Projects/DebSrc3.0
is hard to parse/udnerstand in this respect.
I have two source tarballs
luatex_0.64.0.orig.tar.bz2
unpacking into luatex-beta-0.64.0/.
luatex_0.64.0.orig-manual.tar.bz2
unpacking into luatex-beta-0.64.0/manual/
but it seems that an additional level of "manual" (=component)
is created:
dpkg-source: warning: ignoring deletion of file manual/manual/luatexref-env.tex
dpkg-source: warning: ignoring deletion of file manual/manual/fdata.lua
...
So I guess I have to repackage again the two orig .tar.bz2 (they are
distributed like that), the source format cannot work with that.
Am I right or do I miss something here?
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
HUTTOFT (n.)
The fibrous algae which grows in the dark, moist environment of
trouser turn-ups.
--- Douglas Adams, The Meaning of Liff
--
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/20101113122047.gk21...@gamma.logic.tuwien.ac.at
Re: [buildd-tools-devel] testers wanted: sbuild and build-dependencies
On Wed, Nov 10, 2010 at 05:17:30PM -0500, Andres Mejia wrote: > On Wed, Nov 10, 2010 at 2:57 PM, Goswin von Brederlow > wrote: > > Roger Leigh writes: > > > >> On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote: > >>> Roger Leigh writes: > >> > >> The existing approach to determinism is not to support alternatives > >> at all, which is clearly not ideal. While I don't think we should > >> be encouraging the use of alternative build-deps, this is one of the > >> most commonly reported bugs in sbuild--there are valid use cases for > >> them. > > > > Actually alternatives are supported. Most notably in A [i386] | B > > [!i386]. Sbuild fixates on the first alternative that should be > > installable. That makes it 100% perdictable to the uploader which > > package he gets. > > This use of alternatives will fail on non-i386 machines using sbuild's > internal build-dep resolver. It will succeed using apt or aptitude > however. > > Here's an example for anyone willing to try. It doesn't matter if the > architecture restrictions are there or not. > Build-Depends: linux-headers-2.6-i386 [i386] | linux-headers [!i386] This is, AFAICT, working exactly as intended. It's correctly picking the "linux-headers" alternative. It then fails because linux-headers is a virtual package, and the internal resolver won't resolve virtual packages (where the apt and aptitude resolvers will) by default. D: Running command: /usr/bin/schroot -d / -c sid-amd64-sbuild-b7bb4e56-286d-470f -870d-0673d257e7db --run-session -q -u root -p -- /usr/bin/apt-get --purge -o DP kg::Options::=--force-confold -o DPkg::Options::=--refuse-remove-essential -q -- no-install-recommends -y install linux-headers Reading package lists... Building dependency tree... Reading state information... E: Package 'linux-headers' has no installation candidate Package linux-headers is a virtual package provided by: apt-get failed. Package installation failed If you set $enable_virtual=1, it will attempt to deterministically resolve the dependency and it will then succeed: D: Running command: /usr/bin/schroot -d / -c sid-amd64-sbuild-ed94fbb6-5775-4598-8237-e965218bbc94 --run-session -q -u root -p -- /usr/bin/apt-get --purge -o DPkg::Options::=--force-confold -o DPkg::Options::=--refuse-remove-essential -q --no-install-recommends -s install linux-headers-2.6-amd64 Reading package lists... Building dependency tree... Reading state information... The following extra packages will be installed: cpp-4.3 gcc-4.3 gcc-4.3-base linux-headers-2.6.32-5-amd64 linux-headers-2.6.32-5-common linux-kbuild-2.6.32 Suggested packages: gcc-4.3-locales gcc-4.3-multilib libmudflap0-4.3-dev gcc-4.3-doc libgcc1-dbg libgomp1-dbg libmudflap0-dbg The following NEW packages will be installed: cpp-4.3 gcc-4.3 gcc-4.3-base linux-headers-2.6-amd64 linux-headers-2.6.32-5-amd64 linux-headers-2.6.32-5-common linux-kbuild-2.6.32 So I don't think we need to worry too much about this specific case; it's merely highlighting how deficient the internal resolver is! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
hi dear add my id for link exchnage
hi dear add my id for link exchnage
Bug#603393: ITP: libgis -- A Virtual Globe library
Package: wnpp Severity: wishlist Owner: Andy Spencer * Package name: libgis Version : 0.4.1 Upstream Author : Andy Spencer * URL : http://lug.rose-hulman.edu/code/projects/libgis/wiki * License : GPL Programming Lang: C Description : A Virtual Globe library libgis is a "Virtual Globe" library which uses OpenGL to render an image of the earth using satellite and terrain data from publicly accessible servers. This is similar in concept to Google Earth and NASA World Wind, except implemented as a library. The source code for this project can be found at git://git.gnome.org/libgis -- 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/20101113172142.19302.35093.report...@b
Re: bits from the DPL: sprints, events, delegations, assets
Hi,
On Sat, Nov 13, 2010 at 04:49:04AM +0100, Stefano Zacchiroli wrote:
> Squeeze Release
> ===
>
> The monthly RFH section is once more for the Squeeze Release. Trying to
> read Release Team minds, I get something like: ? the RC bug count [1] is
> proceedings in the right direction, but it is still not (fast) enough to
> release ?. At the time of writing, the most recent stats [2] speak of
> 126 bugs that need to be fixed ... and we are about 1'000 developers!
> Please consider devoting some of your Debian time to fix RC bugs, no
> matter if you are the maintainer of the affected packages or not.
> Release is inherently a collaborative activity and not something up to
> the Release Team only; collaboration is also the only way to keep up
> with the high quality standards Debian has delivered in the past.
>
> [1] http://bugs.debian.org/release-critical/
> [2] http://blog.schmehl.info/Debian/rc-stats/2010-45
So I looked at [2], clicked through to the Universal Debian Database
[3], selected Sort By "last modified", and clicked Search. The very
first bug on the result [4] is #545911, which is already fixed.
This surprised me greatly, since I thought I was searching for bugs
"affecting" squeeze.
I later noticed that among the list of filters is "marked as done"
which was not considered. So the default search appears to be "bugs
that affected squeeze at some point in time", which is slightly
different from what I had first imagined ("bugs affecting squeeze
NOW").
So, a tip for others: be sure to "ignore" bugs marked as done.
Cheers,
-Steve
[3] http://udd.debian.org/bugs.cgi
[4]
http://udd.debian.org/bugs.cgi?release=squeeze&patch=&pending=&security=&wontfix=&upstream=&forwarded=&claimed=&deferred=¬main=¬squeeze=&base=&standard=&merged=ign&done=&outdatedsqueeze=&outdatedsid=&needmig=&newerubuntu=&fnewer=&fnewerval=7&rc=1&sortby=last_modified&sorto=asc
signature.asc
Description: Digital signature
Re: bits from the DPL: sprints, events, delegations, assets
On Sat, Nov 13, 2010 at 14:26:39 -0600, Steve M. Robbins wrote: > So I looked at [2], clicked through to the Universal Debian Database > [3], selected Sort By "last modified", and clicked Search. The very > first bug on the result [4] is #545911, which is already fixed. > It's marked as fixed in lilypond 2.12.3-1. Squeeze has lilypond 2.12.2-1. So it does affect squeeze. Cheers, Julien signature.asc Description: Digital signature
Re: bits from the DPL: sprints, events, delegations, assets
On Sat, Nov 13, 2010 at 09:34:02PM +0100, Julien Cristau wrote: > On Sat, Nov 13, 2010 at 14:26:39 -0600, Steve M. Robbins wrote: > > > So I looked at [2], clicked through to the Universal Debian Database > > [3], selected Sort By "last modified", and clicked Search. The very > > first bug on the result [4] is #545911, which is already fixed. > > > It's marked as fixed in lilypond 2.12.3-1. Squeeze has lilypond > 2.12.2-1. So it does affect squeeze. Aha! I suspected I was missing some detail like that. Thanks, -Steve signature.asc Description: Digital signature
Re: bits from the DPL: sprints, events, delegations, assets
On 13/11/10 at 14:26 -0600, Steve M. Robbins wrote:
> Hi,
>
> On Sat, Nov 13, 2010 at 04:49:04AM +0100, Stefano Zacchiroli wrote:
>
> > Squeeze Release
> > ===
> >
> > The monthly RFH section is once more for the Squeeze Release. Trying to
> > read Release Team minds, I get something like: ? the RC bug count [1] is
> > proceedings in the right direction, but it is still not (fast) enough to
> > release ?. At the time of writing, the most recent stats [2] speak of
> > 126 bugs that need to be fixed ... and we are about 1'000 developers!
> > Please consider devoting some of your Debian time to fix RC bugs, no
> > matter if you are the maintainer of the affected packages or not.
> > Release is inherently a collaborative activity and not something up to
> > the Release Team only; collaboration is also the only way to keep up
> > with the high quality standards Debian has delivered in the past.
> >
> > [1] http://bugs.debian.org/release-critical/
> > [2] http://blog.schmehl.info/Debian/rc-stats/2010-45
>
> So I looked at [2], clicked through to the Universal Debian Database
> [3], selected Sort By "last modified", and clicked Search. The very
> first bug on the result [4] is #545911, which is already fixed.
>
> This surprised me greatly, since I thought I was searching for bugs
> "affecting" squeeze.
>
> I later noticed that among the list of filters is "marked as done"
> which was not considered. So the default search appears to be "bugs
> that affected squeeze at some point in time"
Wrong
> , which is slightly
> different from what I had first imagined ("bugs affecting squeeze
> NOW").
>
> So, a tip for others: be sure to "ignore" bugs marked as done.
Please don't. There are many cases where a bug can be marked as done,
while still affecting squeeze.
Usually, a good way to understand why the bug still affects squeeze is
to look at the BTS found/fixed graph, and at rmadison.
- Lucas
--
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/20101113204329.ga9...@xanadu.blop.info
Re: source package format 3.0 with multiple tar balls
dpkg-source unpacks the second tarball to a subdirectory based on the -manual postfix. The upstream tarball contains a manual subdirectory: $ tar tf luatex-beta-0.64.0-doc.tar.bz2 | head -n2 luatex-beta-0.64.0/manual/ luatex-beta-0.64.0/manual/graphics/ So the manual/manual thing comes from the orig.tar suffix plus the subdir inside the upstream tarball. So, two options: File a bug on dpkg-source asking for it to strip the additional levels of subdirectories with single entries until a file or a directory with multiple files/directories in it shows up. Adapt your packaging to use the additional level of subdirectory. This would be the simpler option, unless I am missing something. BTW, upstream uses a -doc tarball suffix, why not use that? -- 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/aanlktim_75qhlflko0uaarebewtnyoya4a2jsbrjm...@mail.gmail.com
Re: source package format 3.0 with multiple tar balls
Hi Paul,
thanks for the answer.
On So, 14 Nov 2010, Paul Wise wrote:
> $ tar tf luatex-beta-0.64.0-doc.tar.bz2 | head -n2
> luatex-beta-0.64.0/manual/
> luatex-beta-0.64.0/manual/graphics/
>
> So the manual/manual thing comes from the orig.tar suffix plus the
> subdir inside the upstream tarball.
yup, so it is.
> Adapt your packaging to use the additional level of subdirectory. This
> would be the simpler option, unless I am missing something.
I choose option 3: repackage the two tar balls into one ;-) As I did
it the last releases.
> BTW, upstream uses a -doc tarball suffix, why not use that?
You mean keep the -doc, that unpacks into
luatex-0.64.0/doc/manual/...
and adapt the packaging.
Yeah, that could be a good option with less work.
Thanks for the suggestion.
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
MELCOMBE REGIS (n.)
The name of the style of decoration used in cocktail lounges in mock
Tudor hotels in Surrey.
--- Douglas Adams, The Meaning of Liff
--
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/20101114043719.ga20...@gamma.logic.tuwien.ac.at
