Bug#644726: ITP: kpdftool -- GUI interface for managing PDFs with GhostView and ImageMagick
Package: wnpp Severity: wishlist Owner: Simone Rossetto -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: kpdftool Version : 0.23 Upstream Author : Rodrigo Oliveira * URL : http://kde-apps.org/content/show.php/KPDFTool?content=33194 * License : GPL Programming Lang: C++ Description : GUI interface for managing PDFs with GhostView and ImageMagick KPDFTool can be used to perform basic and usefull operations with PDF and PS (PostScript) files such as merge, extract pages and protect the text. All operations can be accomplished in a simple and practical way without knowledge of shell-based backends. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOkFnDAAoJEFZ1rdOc8CImL7sQAIXvpGYB9f2M4lDj4lXyjknM 5VPizNQmSj3wQcnIsKPWALCEohaUqQpr9DpfgcvLJDW8icoR3fGS/jMliBQHOWmu jLoY05UkVB5i996lyNY/v7zHyYrSIaYpHjghJQ76W+17GiQVeCW9fPK5veowAWbI BvmzHGLYl7+1vnuRp2xpri6HFcI/+T3IH6W+b1zzVZDccBYq33ZeTWrf91eXnTjX AiEa9D1MsAufQ1ew5UVNANNKsH5FeyFX23/BV8b0cDYih1Se7M0WtPwAUECqpw9i e0HsPiPegCEaq8s01fZv36CAMfXlPqzf19xRNrRVmK8ei374noma9M0tpAf3Gisk 8Js5EOb3L9e64oSsY1GGdBi15RdzSGMjywFzvcr0RrBhTU5+x1sAoaCiXrK3f6W9 ZnkMJVHzKFV6XnIpLevPEAMQsvqOXRUHrbmSqQ+Cp/h9HdWY3cVZWpT4v0WQo1sF O/9YvyFQrwiEbeMGX3Ngk1HSwuckgLb37VH4FWLQvfOMEl7Hf/Awq58GAXw0kqp+ E2fI9tl3JGEPHV/j/mZO7voQISfh2zUGFUBUiLix1xc67Qxld9BMn6BNDdXz2bF9 TxnTiMpHnr0J4JumB55mylpKcF6SEfhBp1LyRRRFWRqcx9d26LePd7l+5epSkqcW UPD9POtyljepsbEyAC+A =Llux -END PGP SIGNATURE- -- 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/20111008141013.20719.41462.report...@droscy.casa.local
Re: New package doesn't fix the problem in the old version
Raf Czlonka writes ("Re: New package doesn't fix the problem in the old
version"):
> Hi Ian,
> > There is a third possibility which is that the maintainer has made a
> > judgement that this bug is not worth going to special effort to fix in
> > the package. Policy does not need to be involved.
>
> My point is exactly that: "who makes the call?".
The maintainer(s) of the package(s) in question. If you disagree and
care enough to escalate it, and you haven't managed to persuade the
maintainer, then debian-devel is available to give a second opinion
and if that's not sufficient for you, or doesn't reach consensus, the
Technical Committee is available to make a formal determination.
Note that when I say "haven't managed to persuade the maintainer", I
don't mean that you harangued them in a bug report, by (for example)
implying they're lazy. I mean that you had a reasonable and friendly
conversation where you make sure that the maintainer is aware of all
the relevant tradeoffs and consequences. You need to conduct this
conversation in a manner that doesn't presuppose that the maintainer
has no option but to do as you wish.
> It's not just about that package and that particular bug.
> Maybe there should be a clear policy, which should apply to all releases
> which are fully fledged (stable, testing, unstable[0]), on what is
> deemed to be called a bug fix - IMHO uninstall (purge rather) a package
> and install it again is not.
No, there shouldn't. Whether a transiently present bug needs special
action in current packages to fix it up, and how perfect that special
action needs to be, is not something we can or should write a single
simple policy for.
It's a tradeoff, of precisely the kind that we delegate to
maintainers.
> If we scale it (might be a bit far-fetched, but it really isn't IMHO)
> we get to the point where personal judgement and opinion takes
> precedence over everything else and is quite harmful[1].
If a person makes a wrong judgement, we have mechanisms to deal with
that. They may not be ideal, and I would like to see them improved,
but that doesn't mean that the right answer is to try to nail
everything down in policy.
Ian.
--
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/20112.27211.999112.164...@chiark.greenend.org.uk
Re: New package doesn't fix the problem in the old version
On Sat, Oct 08, 2011 at 04:20:43PM +0100, Ian Jackson wrote:
> Raf Czlonka writes ("Re: New package doesn't fix the problem in the old
> version"):
> > > There is a third possibility which is that the maintainer has made a
> > > judgement that this bug is not worth going to special effort to fix in
> > > the package. Policy does not need to be involved.
> >
> > My point is exactly that: "who makes the call?".
>
> The maintainer(s) of the package(s) in question. If you disagree and
> care enough to escalate it, and you haven't managed to persuade the
> maintainer, then debian-devel is available to give a second opinion
> and if that's not sufficient for you, or doesn't reach consensus, the
> Technical Committee is available to make a formal determination.
To nitpick a bit, your third possibility mentioned that the fix is "not
worth", but there are at least two sub-cases there: (1) maintainer does
not want to spend *their own time* preparing the fix, but would gladly
accept patches from others and (2) the maintainer does not want the fix
to reach user machines (e.g. because they consider the fix might make
things worse).
Given Raf's interest in getting this particular issue fixed, I wonder
whether he has tried proposing a patch to the maintainer (there is no
trace of it in the buglog mentioned in this thread). Going that way can
be way more useful in actually improving the life of users affected by
the issue than this intriguing discussion about who *in theory* is
responsible of cleaning up old debris.
Share the code, we'll all be happier.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#644742: ITP: ocaml-gstreamer -- OCaml bindings for gstreamer
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: ocaml-gstreamer Version : 0.1.0 Upstream Author : The Savonet Team * URL : http://savonet.sf.net/ * License : LGPL 2.1 Programming Lang: OCaml Description : OCaml bindings for gstreamer GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. . This package provides an interface to gstreamer to OCaml programmers. -- 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/20111008163945.17771.86787.reportbug@Obey
e2dis status update
> Ivan Shmakov writes: […] > The news is that both the disassembly (e2dis) and reassembly (imrt) > tools are now working (but read below for a caution) and available > from their public Git repository [1] at Gitorious! > [1] https://gitorious.org/e2dis/e2dis-devel […] > Unfortunately, the performance of the image reassembly tool (imrt) is > extremly poor for the filesystems of more than a few MiB's size. Long story short: the changes I've made over a month made imrt significantly faster. I didn't do much testing, but it seems like an order of magnitude jump! > (And it seems that there may be subtle bugs, too.) The bug I was referring to is that it seems that the version of libgcrypt I use apparently doesn't support as many as 30 or 40 digest objects existing at the same time. With the digest removal logic re-done properly (8f56056d), it doesn't seem like a big issue anymore. > As with jigdo-file(1), imrt doesn't rely on filenames, and instead > “guesses” the output chunks the files passed to it correspond by > comparing the hashes (SHA-1 and SHA256 as of a726267a.) However, > such a comparison is currently implemented in a straightforward yet > suboptimal (as in: totally dumb) way, leading to the problem. It was improved considerably in the commits from 2acc4706 to b5009c14 (roughly.) Then, I've switched to using prepared statements extensively (a51bf977, 5d2f278c), thus reducing the time to complete a simple 64 MiB test image reassembly by roughly 20%. Finally, I've implemented the “cue sheet” support (abd326b5, 64743751.) Now, e2dis recurses over the filesystem's directories and records the filenames for all the “chunks” whose digests are recorded. Conversely, imrt uses this table to narrow the comparison of the files being processed to only such digests. If that fails, it still falls back to doing full search. For the test image, this change reduces the time by some 75% more! As for the missing parts: there's still virtually no command line interface, and I hope to fix that within a month or so, making a proper release shortly after. Neither is there documentation, nor handy tools to maintain the databases created. In particular, while the format allows a single databased to hold indices for several images (say, it may be images for different platforms), there's no tools to either “split” such a database, or “join” a few together. […] -- FSF associate member #7257 -- 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/86botr5raz@gray.siamics.net
Re: debian/rules binary and build target dependencies clarification
2011/10/7 Bernhard R. Link : > * Дмитрий Матросов [111007 16:27]: >> But in the section 7.7 of Debian policy manual: >> > clean, build-arch, and binary-arch >> >Only the Build-Depends and Build-Conflicts fields must be satisfied when >> >these targets are invoked. >> > build, build-indep, binary, and binary-indep >> >The Build-Depends, Build-Conflicts, Build-Depends-Indep, and >> >Build-Conflicts-Indep fields must be satisfied when these targets are >> >invoked. >> >> And footnote 55: >> > Anyone building the build-indep and binary-indep targets is assumed to be >> > building the whole package, and therefore installation of all build >> > dependencies is required. >> >> So, as i understand, in this case dependencies will look like >> >>binary : binary-arch binary-indep >>binary-indep : build-indep build-arch > What you write here looks like makefile dependencies, i.e. like > something written in debian/rules. In that sense it is obviously > wrong. Nothing says you must have called build-arch to be able > to run build-indep or binary-indep. > > All it says is that people are not required to add things to > "Build-Depends-Indep:" which are already in "Build-Depends:". So, this means that there is no strict relationship between content of Build-Depends-* field and build-* target dependencies like: "'Build-Depends' field contains all dependencies for 'build-arch' target and nothing more", or "'Build-Depends-Indep' contains all dependencies for 'build-indep' target and nothing more". Am i understand you correctly? > P.S: Note that currently Build-Depends-Indep is not working as > Debian is stalled in a decade old dream for a technical solution, > so one has to put everything in Build-Depends anyway... Well, i just want to understand theory :) -- 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/cafdvufm4rhnwdt9--zydsl09ktqkfoskzxit38kc9_ucwn_...@mail.gmail.com
Bug#644752: RFP: Rodent -- fast, small and powerful file manager
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: Rodent Version: 4.7.2 Upstream Author: Edscott Wilson Garcia URL: http://rodent.xffm.org License: GPL Description: Rodent is fast, small and powerful file manager. Rodent is fast, small and powerful file manager for the GNU operating system (but it also works in BSD). That's one way to look at it. Another way is to call it a graphic shell (that's probably more accurate). * Rodent wastes no space on menus or function buttons (display real estate is too valuable). * All functionality is available through popup menu or keyboard action. * Popup menu is context sensitive. * Full lpterminal is available from keyboard. * Functionality is extendible via plugin tecnology. -- 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/20111008204823.98c396b8.populus.trem...@yahoo.com
Re: Work-needing packages report for Oct 7, 2011
On 10/07/2011 02:28 AM, w...@debian.org wrote: > The following is a listing of packages for which help has been requested > through the WNPP (Work-Needing and Prospective Packages) system in the > last week. I really missed receiving this weekly update. Great to see it's back! Christian -- 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/4e90bd59.7060...@kvr.at
OSS Research Help Needed Please - drawing for tablet computer ($500.00 gift card) for participation.
Hello! We are asking you for some help from the Open Source communities. As researchers at the University of Tennessee we are interested in discovering more about learning and interactions of members of the open source forums. This research is conducted through the University of Tennessee and is in no way associated with any forum organization. To further our research we would like input from forum members. The responses are very important to us so we can better understand what tools help forum members learn and have a productive experience in participation. There are two ways you can help: 1. Take a survey about the tools you use in the forum. We are requesting approximately 15 minutes of your time to participate in our survey. Survey link: http://survey.utk.edu/mrIWeb/mrIWeb.dll?I.Project=FORUMLEARN *As a thank you, upon exiting the survey you will be given an opportunity to submit information to be entered in a drawing for a tablet computer ($500.00 Gift Card).* 2. Have a one on one interview talking about the forums, how you learn, and tools used. *As a thank you for your interview you will be sent a $25.00 gift card. * Email lh...@utk.edu for more information. You may do either or both of the above. Please be assured that your answers will be confidential. No individual’s answers will ever be identified in any report. Should you have any questions about the project or our interest in using the results, we encourage you to contact Lila Holt, at lh...@utk.edu) or Vandana Singh at vand...@utk.edu. Contact information you provide for the drawing is completely separate from your survey answers and there will be no way to identify participants in the actual survey responses. Nor will contact information be used for any other purpose. The odds of being selected will depend on the number of respondents to this survey.
