Bug#696582: ITP: meritous -- action-adventure dungeon crawl game
Package: wnpp Severity: wishlist Owner: Sylvain Beucler * Package name: meritous Version : 1.2 Upstream Author : Lancer-X/ASCEAI * URL : http://www.asceai.net/meritous/ * License : GPL Programming Lang: C Description : action-adventure dungeon crawl game Long description: Far below the surface of the planet is a secret. A place of limitless power. Those that seek to control such a utopia will soon bring an end to themselves. Seeking an end to the troubles that plague him, PSI user MERIT journeys into the hallowed Orcus Dome in search of answers. . Mertious is a action-adventure game with simple controls but a challenge to find a balance of power verses recovery time during real-time battles. Set in a fractually-generated world, the player can explore thousands of rooms in search of powerful artifacts, tools to help them, and to eventually free the Orcus Dome from evil. This is actually a re-upload. I'm part of the Debian Games team and noticed #672759: RM: meritous -- RoQA; FTBFS; unmaintained; low popcon RoQA; FTBFS; unmaintained; low popcon I'm adressing these points below: - RoQA/unmaintained: I'll assume that the original packager (sponsored by tolimar back in 2008) was contacted and is now unresponsive, so I'm taking over. In addition, the game wasn't part of the games team AFAICT and fell off our radar. - FTBFS: just a missing build-dep on zlib - low popcon: consider this is a game and that people tend to uninstall them after beating it; other games such as flare or abuse are in this range (100-200). Not that popularity means quality ;) The game is otherwise finished and, despite the removal of unfree/unclear music, quite enoyable. -- Sylvain -- 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/20121223095815.1032.35729.reportbug@gun
how to add my project?
Hello! How can i add my project into debian-devel repository? For example, my program is the based on httrack library tool, the GUI for it, it's the clone from WinHTTrack tool, classical for windows systems. This project was programmed in Qt4 without any KDE or Gnome dependencies, source code is checked with cppcheck, formatted with astyle and hosted on Sorceforge. The project site: https://sourceforge.net/projects/httraqt/ Thanks for any answers! And Marry Christmas! Developer E.Kalinowski -- 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/50d6dbae.4090...@yahoo.de
Re: how to add my project?
On Sun, Dec 23, 2012 at 11:23:42AM +0100, Eduard wrote: > Hello! > How can i add my project into debian-devel repository? For example, > my program is the based on httrack library tool, the GUI for it, > it's the clone from WinHTTrack tool, classical for windows systems. > This project was programmed in Qt4 without any KDE or Gnome > dependencies, source code is checked with cppcheck, formatted with > astyle and hosted on Sorceforge. http://wiki.debian.org/DebianMentorsFaq#How_do_I_add_a_new_package_to_the_archive.3F -- WBR, wRAR signature.asc Description: Digital signature
Unexpected result when using "apt-file -a source search"
Hi, I was seeking for source code copies of a certain library that for instance contains a file named bgzf.c and so I did $ sudo apt-file -a source update $ apt-file -a source search bgzf.c genometools: /src/external/samtools-0.1.18/bgzf.c Because I was pretty sure that this file also exists in the source of samtools and tabix I tried to grep the Contents-source files directly and got: $ zgrep bgzf.c /var/cache/apt/apt-file/*unstable*Contents-source.gz /var/cache/apt/apt-file/http.debian.net_debian_dists_unstable_main_Contents-source.gz:bgzf.c samtools,tabix /var/cache/apt/apt-file/http.debian.net_debian_dists_unstable_main_Contents-source.gz:src/external/samtools-0.1.18/bgzf.c genometools Any idea why apt-file -a source search missed samtools and tabix? It seems the reason is the coma separated list of these two packages. I have no idea whether this is a valid syntax for Contents-source.gz files but if yes apt-file should be able to cope with this. On the other hand I somehow suspect some problem with the Contents-source.gz file because I rather think that the second line pointing to package genometools looks somehow "correct". Or did I just missed something? Kind regards Andreas. -- http://fam-tille.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/20121223104442.gf21...@an3as.eu
Re: Unexpected result when using "apt-file -a source search"
Le Sun, Dec 23, 2012 at 11:44:42AM +0100, Andreas Tille a écrit : > > Any idea why > >apt-file -a source search > > missed samtools and tabix? Hi Andreas, it is http://bugs.debian.org/676642 Cheers, -- Charles -- 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/20121223111914.ge16...@falafel.plessy.net
Re: Packaging upstream tarballs with mixed C and Python sources
On Sun, Dec 23, 2012 at 09:11:11AM +0800, Paul Wise wrote:
> On Sat, Dec 22, 2012 at 11:50 PM, Игорь Пашев wrote:
>
> > I think override_dh_auto_{build,install,clean} in debian/rules could help.
> > For example:
> >
> > override_dh_auto_build:
> > cd server && ... # build server
> > $(MAKE) ... # build in top dir
>
> Best talk upstream into providing a better build system, but until
> they do that, this workaround would be better I think:
>
> override_dh_auto_build:
> dh_auto_build --sourcedirectory=server
> dh_auto_build
Exactly what I was looking for, thanks a lot!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
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/20121223113808.ga25...@physik.fu-berlin.de
Re: Packaging upstream tarballs with mixed C and Python sources
On 12/22/2012 11:23 PM, John Paul Adrian Glaubitz wrote: > If I just create the usual debhelper 9 rules file, the package will be > built from the C sources only, ignoring the Python code for launcher > and server. While the "dh 9 short style" with override_* thing is nice (I've learn to love it, after a bit more than a year of resisting it), it isn't at all mandatory. And in some cases, it's not adapted (this case seem to be one of the cases it isn't adapted). Why don't you just use the older packaging style, and call "python setup.py --install-layout=deb--root=debian/" in the install target (or whatever is needed if upstream don't use python-setuptools)? Thomas -- 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/50d6ee06.7010...@debian.org
Re: how to add my project?
Hello Eduard, On Sun, Dec 23, 2012 at 11:23:42AM +0100, Eduard wrote: > Hello! > How can i add my project into debian-devel repository? For example, > my program is the based on httrack library tool, the GUI for it, > it's the clone from WinHTTrack tool, classical for windows systems. I assume that you are talking about getting your software into the official Debian repositories, so I'll describe this procedure. First, in order for a particular to become part of Debian, it has to be packaged. This means, someone needs to write a number of scripts which go into a directory called "debian". These scripts will compile your package and build a Debian package (.deb). Furthermore, the debian directory contains a changelog describing the changes of the package, a so-called control file which tells the package manager about the dependencies (i.e. other Debian packages which have to be installed as well for your package to work) and many more files (depending on the particular type of package). After the package has been built and it meets the quality standards for packages in Debian, it can be uploaded by a Debian Developer (DD) into the Debian archives where it will become available for installation in Debian unstable (and Debian testing and eventually Debian stable). If you are not a Debian Developer, you can still have your packages uploaded into Debian through the means of Debian mentors [1]. Debian mentors is a repository where newbies can upload their packages and ask Debian Developers to sponsor these, which means reviewing and eventually uploading these packages. Once you have gained enough experience and self-confidence - after uploading more packages to Debian through sponsored uploads through Debian mentors - you can eventually apply to become a Debian Developer yourself. Anyway, in your case I would suggest you get into contact with the Debian Developer who maintains the package "webhttrack" [2] (you find his email address on this website). Since your application is a GUI for the webhttrack package, it might make sense that he maintains the GUI for it as well. Hope that helps! Cheers, Adrian > [1] http://mentors.debian.net/ > [2] http://packages.debian.org/stable/web/webhttrack -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121223120357.gb25...@physik.fu-berlin.de
Bug#696593: ITP: sun -- sun calculates the sun's rise/set times
Package: wnpp Severity: wishlist Owner: Steffen Vogel Package name: sun Version : 0.1 Upstream Author : Steffen Vogel URL : http://www.steffenvogel.de/2012/12/23/cron-jobs-fur-sonnenauf-untergang/ License : GPL Programming Lang: ANSI C Description : sun calculates the sun's rise/set times, the solar noon and the daylight time duration I wrote this tool to easily schedule the switching of my lighting for home automation. Its a stand alone binary following the unix paradigm. Its designed to be used in conjunjtion with cron, at date etc. For me this tool is extremly useful as you might note with these examples: Schedule a BIOS wakeup 10 minutes before the sunrise in Berlin: nvram-wakeup -s $(date -d "-10min $(sun rise -q Berlin)" +%s) Shutdown the system 10 minutes after sunset: shutdown $(date -d +10min $(src/sun set --lat=50.55 --lon=-6.2) +%H:%M) Enable my lighting at cilil twiglight: echo ~/bin/enable-lightning | at $(sun set -q Frankfurt -t civil) The sourcecode is hostet at github: https://github.com/stv0g/sun Debian packaging is already completed. I'm currently providing the package in my own apt repository: http://packages.0l.de/debian/pool/main/s/sun/ Its based on the solar calculations: http://lexikon.astronomie.info/zeitgleichung/neu.html from Arnold Barmettler Merry X-Mas Steffen PS: Please excuse my mistakes i've propably made. Thats my first ITP and Debian package overall... -- 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/20121223145406.25702.14910.report...@styx.lan
Re: Bug#696593: ITP: sun -- sun calculates the sun's rise/set times
Hi Steffen, On Sun, Dec 23, 2012 at 03:54:06PM +0100, Steffen Vogel wrote: > PS: Please excuse my mistakes i've propably made. Thats my first ITP and > Debian package overall... Sounds like an interesting project. Have you already uploaded your package to Debian mentors [1] to ask for sponsorship? Cheers, Adrian > [1] http://mentors.debian.net/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121223152552.gb27...@physik.fu-berlin.de
Re: Bug#696593: ITP: sun -- sun calculates the sun's rise/set times
On Sun, Dec 23, 2012 at 04:25:52PM +0100, John Paul Adrian Glaubitz wrote: > Hi Steffen, > > On Sun, Dec 23, 2012 at 03:54:06PM +0100, Steffen Vogel wrote: > > PS: Please excuse my mistakes i've propably made. Thats my first ITP and > > Debian package overall... > > Sounds like an interesting project. Have you already uploaded your Seconded, to be sure. I could totally find this useful too. > package to Debian mentors [1] to ask for sponsorship? > > Cheers, > > Adrian > > > [1] http://mentors.debian.net/ > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > -- > 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/20121223152552.gb27...@physik.fu-berlin.de > Thanks for your work! Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
openmotif is now LGPL, retirement of lesstif in jessie?
Hi all, I don't know how many of you still care for the motif widgetset, but due to the way I got involved in Debian, I have kept a small eye on it. Recently ICS [1] release a new version of openmotif, and this time they stuck a LGPL license on it. I think this is good news, as it means that we can get rid of a less optimal situation where we were using a less than complete open source replacement, lesstif, to build programs needing the motif widgetset. The last couple of years lesstif has annoyed users quite a lot because the elementary copy/paste functionality was not properly implemented [2]. Of course, we still have to release wheezy, but may I (also with my lesstif co-maintainer hat on) already suggest to get rid of lesstif for jessie. What do you think? Paul PS: how nice that the latest update to the policy already removed the lesstif/openmotif text. [1] http://motif.ics.com/motif [2] http://lesstif.sourceforge.net/#help signature.asc Description: OpenPGP digital signature
Re: openmotif is now LGPL, retirement of lesstif in jessie?
On Sun, Dec 23, 2012 at 07:56:06PM +0100, Paul Gevers wrote: > Of course, we still have to release wheezy, but may I (also with my > lesstif co-maintainer hat on) already suggest to get rid of lesstif for > jessie. > > What do you think? Sounds reasonable to me, especially since lesstif seems to be abandonend (last release 2007) while OpenMotif just had a release in October 2012 (according to Wikipedia). Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/20121223192535.ga28...@physik.fu-berlin.de
Re: openmotif is now LGPL, retirement of lesstif in jessie?
Hi, I for one would be glad to see openmotif in jessie, as I have a package planned, MetView, which has recently been relicensed as open source, but uses OpenMotif. In particular it uses a layout widget which doesn't work in lesstif. (MetView is in active development and increasingly uses Qt4, but still needs Motif). So I strongly favour getting OpenMotif in Jessie, whether or not Lesstif is removed. best regards Alastair On 2012-12-23 18:56, Paul Gevers wrote: > Hi all, > > I don't know how many of you still care for the motif widgetset, but due > to the way I got involved in Debian, I have kept a small eye on it. > > Recently ICS [1] release a new version of openmotif, and this time they > stuck a LGPL license on it. I think this is good news, as it means that > we can get rid of a less optimal situation where we were using a less > than complete open source replacement, lesstif, to build programs > needing the motif widgetset. The last couple of years lesstif has > annoyed users quite a lot because the elementary copy/paste > functionality was not properly implemented [2]. > > Of course, we still have to release wheezy, but may I (also with my > lesstif co-maintainer hat on) already suggest to get rid of lesstif for > jessie. > > What do you think? > > Paul > PS: how nice that the latest update to the policy already removed the > lesstif/openmotif text. > > [1] http://motif.ics.com/motif > [2] http://lesstif.sourceforge.net/#help > -- Alastair McKinstry , , http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- 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/50d75b55.7060...@sceal.ie
Re: Package variant selection policy using meta packages
On Sat, Dec 22, 2012 at 02:57:56PM +0100, Joachim Breitner wrote: > Hi, > > Am Samstag, den 22.12.2012, 14:39 +0200 schrieb Andrei POPESCU: > > On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: > > > Users tend to fall into one of three classes: > > > A. Users that, if they have foo-dev installed, always also want > > > foo-prof installed. > > > B. Users that want to manually decide for what packages they want > > > the -prof package and for what package not. > > > C. Users who don’t want any -prof package around. > > > > > > Currently, we only really help user B. If user A installs foo-dev there > > > is nothing that ensures that he gets foo-prof installed as well. > > > > And a foo-dev Recommends: foo-prof is not suitable because? > > because we cannot tell what the user will want. For example, a user of > xmonad will not want -prof packages installed, and an addition 400MB of > useless stuff on his computer is not in his, and hence our, interest. > > Also, a user from the class A wants a stronger guarantee than just > Recommends, which is just a suggestion to the package manager, but not a > a hard relation. No, that's not true; a Recommends is not a Suggests. Yes, I'm aware you didn't mean to say that. However, the very definition of Recommends implies that it is stronger than a suggestion, yet less than a hard dependency. It seems perfectly suited for your purpose. It covers case A perfectly, and B too, with some effort (but then, users in class B need to excert some effort anyway; the difference is only that now they need to decide which packages not to install when installing a -dev package, rather than which packages to install in addition to their -dev packages). It doesn't cover class C, but then that can be covered quite easily by having all packages with profiling information have something like Provides: haskell-profiling With that, users in class C can use equivs to create a package which Conflicts: haskell-profiling And then they'll never get any -prof packages installed, without any need for these metapackages. -- 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/20121223211504.ge18...@grep.be
Re: Package variant selection policy using meta packages
Hi, Am Sonntag, den 23.12.2012, 22:15 +0100 schrieb Wouter Verhelst: > No, that's not true; a Recommends is not a Suggests. That’s not what I said. But it is a suggestion in the sense that installing a package without the package that is Recommends is valid. > It seems perfectly suited for your > purpose. It covers case A perfectly, and B too, with some effort (but > then, users in class B need to excert some effort anyway; the difference > is only that now they need to decide which packages not to install when > installing a -dev package, rather than which packages to install in > addition to their -dev packages). I’m still not convinced. What if a user once decided not too care about -prof package, and not install them, or only some of them every time he needed them. Now he notices that this is annoying and wants all of them, for the -dev packages already installed. Recommends does not help him at all here, as they are taken only into consideration when installing a package. With my scheme, he could install i-want-all-prof-packages and the package manager will automatically install the missing -prof packages. Another point that has been missed so far: Class B should (probably) be the default, while class A should be possible. Even if Recommends would fit A perfectly the wrong variant would be the default. With meta-packages the approaches would be equally good, and ghc could have a Depends on i-want-some-prof-packages | i-want-all-prof-package to hint that the first one should be the default (whether this works should still be tested). > It doesn't cover class C Ignore class C, I’m not sure if that is a demanded use case. OTOH, your solution is what I proposed, only that it’s only accessible to people who know equivs. My original question stands: Is there anything inherently wrong with my approach, or would it, if I find it the best solution, ok to employ it? The fact that Recommends might provide some of its features does not answer that. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Package variant selection policy using meta packages
On Sun, Dec 23, 2012 at 10:31:19PM +0100, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 23.12.2012, 22:15 +0100 schrieb Wouter Verhelst: > > No, that's not true; a Recommends is not a Suggests. > > That’s not what I said. But it is a suggestion in the sense that > installing a package without the package that is Recommends is valid. > > > It seems perfectly suited for your > > purpose. It covers case A perfectly, and B too, with some effort (but > > then, users in class B need to excert some effort anyway; the difference > > is only that now they need to decide which packages not to install when > > installing a -dev package, rather than which packages to install in > > addition to their -dev packages). > > I’m still not convinced. What if a user once decided not too care about > -prof package, and not install them, or only some of them every time he > needed them. Now he notices that this is annoying and wants all of them, > for the -dev packages already installed. Recommends does not help him at > all here, as they are taken only into consideration when installing a > package. You can easily search for those packages in aptitude, by using the following search string: ?and(?installed, ?broken-recommends(libghc.*prof$)) Sounds like all you need is just a bit of documentation which explains that. > With my scheme, he could install i-want-all-prof-packages and the > package manager will automatically install the missing -prof packages. Actually, that's not guaranteed, since your proposed i-want-all-prof-packages package doesn't actually have any relationship with the prof packages. As such, removing all haskell packages might be a correct solution to the problem of "installing this package causes a shitload of package conflicts" too and might be the solution the package manager chooses, depending on the packages which are already installed, the other operations that are being requested at the same time you install the metapackage, and the phase of the moon. In the worst case, the correct and wanted solution is 137 "no, not that one, please calculate the next solution" replies to aptitude away (and not available if you use another package manager, unless you manually install all -prof packages, which makes your metapackage useless). > Another point that has been missed so far: Class B should (probably) be > the default, while class A should be possible. Even if Recommends would > fit A perfectly the wrong variant would be the default. > > With meta-packages the approaches would be equally good, and ghc could > have a Depends on i-want-some-prof-packages | i-want-all-prof-package to > hint that the first one should be the default (whether this works should > still be tested). > > > It doesn't cover class C > > Ignore class C, I’m not sure if that is a demanded use case. OTOH, your > solution is what I proposed, only that it’s only accessible to people > who know equivs. Not entirely. I propose a virtual package, you propose a non-virtual package. Other than that, yes, they are similar, but not quite the same thing. > My original question stands: Is there anything inherently wrong with my > approach, See above: it doesn't actually solve the problem, it only serves to confuse the package manager since it's not actually defined what your weird package relationships mean. > or would it, if I find it the best solution, ok to employ it? > The fact that Recommends might provide some of its features does not > answer that. I suppose that's true. -- 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/20121223221836.gh18...@grep.be
Re: Package variant selection policy using meta packages
Hi, Am Sonntag, den 23.12.2012, 23:18 +0100 schrieb Wouter Verhelst: > > With my scheme, he could install i-want-all-prof-packages and the > > package manager will automatically install the missing -prof packages. > > Actually, that's not guaranteed, since your proposed > i-want-all-prof-packages package doesn't actually have any relationship > with the prof packages. As such, removing all haskell packages might be > a correct solution to the problem of "installing this package causes a > shitload of package conflicts" too and might be the solution the package > manager chooses, depending on the packages which are already installed, > the other operations that are being requested at the same time you > install the metapackage, and the phase of the moon. It’s true that the interaction with the package managers might render this problematic; this needs to be tested. Although in this case I think it should work, as apt-get, AFAIK, will always prefer installing packages over removing existing ones. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#696623: ITP: seekwatcher -- utility to visualize block I/O patterns
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: seekwatcher Version: 0.12+hg20091016-1 Upstream Author: Chris Mason URL: https://oss.oracle.com/~mason/seekwatcher/ License: GPL-2 Description: utility to visualize block I/O patterns Seekwatcher generates graphs from blktrace runs to help visualize IO patterns and performance. It can plot multiple blktrace runs together, making it easy to compare the differences between different benchmark runs. VCS-Browser: http://git.debian.org/?p=collab-maint/seekwatcher.git signature.asc Description: This is a digitally signed message part.
