Is lack of UTF support an RC bug? [was: Bug#386299: ekg2: Plugin/program compilation option mismatch]
On Thu, Sep 07, 2006 at 02:46:16AM -0700, Steve Langasek wrote: > severity 386299 serious > thanks > > On Wed, Sep 06, 2006 at 06:14:55PM +0100, Marcin Owsiany wrote: > > > Unicode support in ekg2 is highly experimental and not yet supported > > upstream, therefore the debian package is built without UTF-8 support. > > > On Wed, Sep 06, 2006 at 05:56:17PM +0200, Tristan Seligmann wrote: > > > Attempting to run ekg2 yields the following: > > > Try running it in some iso-8859 locale. > > That's not an acceptable answer, given that almost all locales for etch will > be Unicode by default. This makes the package unreleasable. Of course, the > package seems to only be in experimental at all, so I don't see why you > would bother to downgrade the bug... It doesn't matter for ekg2, which will stay in experimental for quite a while I'm afraid, but it is important for at least two other of my packages (which are in etch) which don't support UTF-8 at all. And I'm reasonably sure they are not the only packages in etch which don't support UTF. Who decided that we should just drop them all? After all generating a non-UTF locale and setting an environment variable isn't a very difficult workaround? I mean, when has lack of UTF support become an RC-bug? Charset support is not even mentioned in the policy, other than for debian/changelog. Don't get me wrong, I'm not against UTF-8, but just dropping everything that doesn't support it, without a former warning, sounds ridiculous. regards, Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 signature.asc Description: Digital signature
Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution
On Sun, Jan 07, 2001 at 06:30:33PM -0500, Thomas Smith wrote: > * Keep old Packages.gz file with Descriptions. > * Make new Small-Packages.gz file w/o Descriptions, and have > new version of apt look for it, if so configured. > * Some method of getting the descriptions separately. Maybe > Descriptions.gz or maybe per-package or whatever. > * Perhaps merge Descriptions (if they're downloaded), or put > placeholders (Description: ), into files > in /var/state/apt/lists/ so there's no compatability break > in those. Something like this should be implemented anyway when translated Descriptions will be supported and Packages size will grow by some 6 times. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Developer Behavior
On Tue, Jan 09, 2001 at 08:03:40PM +1100, Hamish Moffatt wrote: > > How can you be on the keyring while not having an account on auric? > > Either you are a developer and you have both, or you are not a developer > > and you have neither. > > Probably you can't. I don't know the NM process well enough to be sure. > > A couple of people mentioned that they do not have an account, > not that they have not been approved. People tend to put a '==' between the above two... Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
When to call update-alternatives?
Well, I know that in postinst and prerm, but when which argument is passed? I thought that "cd /var/lib/dpkg/info && grep -10 update-alternatives *postinst|less -S" would help me, but it did quite the contrary. There is a total mess! A quick summary of how it is called in different packages: - always ($1 is not tested at all), - if [ "$1" = "configure" ] - if [ "$1" != "upgrade" ] - if [ "$1" = "configure" -o "$1" = "abort-upgrade" ] - if [ "$1" = "configure" -o "$1" = "upgrade" ] They can't all be right? After rereading section 6 of the policy, I think that the right way is to call it in postinst if [ "$1" = "configure" ], and in postrm, if [ "$1" = "remove" ] Is this correct? regards, Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Calculating deps size - splitting a package
Hi! ekg2 consists of a main program, and a dozen or so plugins, currently all in one package. Most of the dependancies come from shlibs, which investigates both the main program and the plugins. As it is with plugins, different people use different subsets of them. Since the current setup causes the package to pull in such stuff as X or libsqlite3, I want to split the plugins into different packages. However creating one package for a plugin would be an overkill. So I want to create some sets of plugins, to achieve a compromise between the number of packages and the size of the dependancies for an average user. Since there are currently 16 plugins, I don't want to investigate each one manually. Ideally, there would be a tool, which would run ldd on each plugin in turn and show the list of all direct and indirect dependancies (with their installed-sizes) that adding the plugin in question to a binary package would pull in. I am interested on the total effect to an end-user, for each plugin. Is there something like this (or close) available? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Calculating deps size - splitting a package
On Fri, Nov 04, 2005 at 02:49:44PM +0100, Francesco P. Lovergine wrote: > On Fri, Nov 04, 2005 at 12:17:52PM +0100, Marcin Owsiany wrote: > > > > Since there are currently 16 plugins, I don't want to investigate each > > one manually. Ideally, there would be a tool, which would run ldd on > > each plugin in turn and show the list of all direct and indirect > > dependancies (with their installed-sizes) that adding the plugin in > > question to a binary package would pull in. I am interested on the total > > effect to an end-user, for each plugin. > > Mmm, if plugins used dlopen() ldd would not help in that respect. They don't. The main program dlopen()s the plugins, which in turn are just linked against whathever shared libraries they need. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Removal of xmms and its reverse-dependancies - what is the status?
An xmms rev-dep I maintain (xmms-xf86audio) is useless without xmms, and not really portable to any of its replacements. Therefore I agree it should be removed if xmms is removed. However: - the reporter said to ask for removal after xmms is removed - the ftpmaster removal wiki page says reverse-dependancies should usually be removed first. - #461309 (against ftp.debian.org) is tagged moreinfo - the thread mentioned in #461309 is dead So what's the status? Is xmms removal decided yet, or not? Should I ask for xmms-xf86audio removal now, or wait? -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A tool for tracking masked updates to stable packages
Hi, I've just started to do research in order to write a tool which I was always missing. What I have so far is just a brief "background" information, explaining the problem - see below. I thought it might be good to ask here if I'm not trying to reinvent something that already exists. Or maybe someone has some ideas about this issue? | Background | -- | | Maintaining Debian stable systems sometimes requires installation of | unofficial versions of packages: | | - backporting newer versions, when significant new functionality is |required on the system but unavailable in the official version found |in the current stable release. In this case, the version string |usually sorts as newer than the official stable version string. This |means that pinning is not necessary, as apt will upgrade such package |by default. | | - making local changes to the official version. In this case, the most |reliable way is to make the version string sort as older than the |official one (using the "tilde" feature of dpkg) and force |installation of such package using pinning. (The other strategy: |trying to invent a version string newer than the current one, but |older than the next one is difficult to do reliably.) | | In both cases, there is one major drawback: apt will not warn you where | newer versions of official packages (point releases, security updates) | will appear in the stable release. This means you may miss some | important change. | | The point of this document is to design a utility whose job is to do | exactly this: let you track newer official versions of locally overriden | packages. | -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A tool for tracking masked updates to stable packages
On Sun, Aug 10, 2008 at 09:59:32AM +0200, Vincent Fourmond wrote: > > Marcin Owsiany wrote: > > | - making local changes to the official version. In this case, the most > > |reliable way is to make the version string sort as older than the > > |official one (using the "tilde" feature of dpkg) and force > > |installation of such package using pinning. (The other strategy: > > |trying to invent a version string newer than the current one, but > > |older than the next one is difficult to do reliably.) > > In that case, a solution that comes to my mind is to use the Forbid > feature of aptitude: you install the locally-modified version and forbid > the version currently in stable. This way, aptitude won't install it, > but it will upgrade to a later version if there is one. I must admit that I did not know this particular feature of aptitude. However after having a look at the documentation, it does not seem to be the right tool in the case which is most interesting for me, that is automated package management on distributed hosts. It seems like you need to at least run a command on each host for each package/version combination that you do not like. Does not sound really scalable, especially combined with the fact that "only one version can be forbidden at once." Moreover, even though I find aptitude indispensable on a desktop, I refrain from using it for automation due to things like #445035 or #445034. I've started coding now, but for several reasons I decided to implement it in python (using python-apt). If it works, then it can always be treated as a prototype and reimplemented as an apt-cache subcommand. -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#506151: ITP: apt-forktracer -- a utility for managing package versions
Package: wnpp Severity: wishlist Version: N/A; reported 2008-11-18 Package name: apt-forktracer Upstream Author: Copyright (C) 2008 Marcin Owsiany URL: http://marcin.owsiany.pl/apt-forktracer-page License: GPL v2 or later Description: a utility for managing package versions apt-forktracer tries to alleviate the problem that APT stops tracking official versions of a package after you pin it or install a newer version. . It displays a list of packages which are in an inconsistent state or have a version other than the newest official installed. You can choose to ignore certain packages - if they match certain criteria - with a configuration file. I already announced the intent to write such program in August: http://lists.debian.org/debian-devel/2008/08/msg00248.html I finally completed it, and it is available for download from the homepage. The documentation is available there as well. As I said in the original thread, it is implemented in Python, as I wanted to learn the language better and I thought it is more appropriate for prototyping. I am open to suggestions for a better name. "Fork" may have negative connotation, but I could not think of anything else that would emphasize the fact that the program is interested in two versions at the same time, one of which is "official". -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433847: ITP: kydpdict -- a frontend to YDP Collins dictionary
Package: wnpp Severity: wishlist Owner: Marcin Owsiany <[EMAIL PROTECTED]> * Package name: kydpdict Version : 0.9.3 Upstream Author : Maciej Witkowiak <[EMAIL PROTECTED]>, Andrzej Para <[EMAIL PROTECTED]> * URL : http://members.elysium.pl/ytm/html/kydpdict.html * License : GPL 2 Programming Lang: C++ Description : a frontend to YDP Collins dictionary Has a QT interface, and also supports a few other proprietary dictionary formats Obviously the package will have a better description than this. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686-mactel Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433849: ITP: libydpdict -- a library for reading YDP dictionaries
Package: wnpp Severity: wishlist Owner: Marcin Owsiany <[EMAIL PROTECTED]> * Package name: libydpdict Version : 0.99 Upstream Author : Wojtek Kaniewski <[EMAIL PROTECTED]> * URL : http://toxygen.net/ydpdict/ * License : LGPL 2.1 Programming Lang: C Description : a library for reading YDP dictionaries This was split off ydpdict package (which I maintain), which is now (since version 0.99) uses this library for reading the dictionary. Naturally the package will have a better description than this. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686-mactel Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kydpdict relationships
Hi, [ retrying on this list as suggested by Sean ] I'm packaging kydpdict (#433847) which contains a Qt-based front-end for several dictionary formats. Most of them are proprietary English-Polish dictionaries that you need to pay for. However the upstream package contains free dictionary files taken from another (GPL) program "SAP" (not in Debian, but included e.g. by PLD) by Bohdan R. Rau. These are naturally much smaller than the proprietary ones, but nonetheless useful. Since these dictionary files take well over the half of the package size (even if that's less than 600 KiB), I decided to put them in a separate arch-all binary package: kydpdict-data. Now I need to decide what the relationship between these two should be. If you're lucky to have at least one of the proprietary dictionaries, then you probably wouldn't want to install the free one, since any of the pay-for ones are definitely better - this suggests a "kydpdict Suggests: kydpdict-data" relationship. However since Debian as such cannot distribute any of the non-free ones, and the program is _totally_useless_ when _no_ dictionary is present - this suggests a "Depends:" relationship. A "depends" would also mean I could put the desktop file and icon in the -data package, but that's not really an argument, as they're only a couple of kilobytes. Which way should I go? Does anyone remember what the relationship between quake1 and its data files was? That would be similar, I guess.. -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 signature.asc Description: Digital signature
Re: kydpdict relationships
On Tue, Jul 24, 2007 at 07:55:09PM -0500, Manoj Srivastava wrote: > On Tue, 24 Jul 2007 22:38:37 +0200, Joerg Jaspert <[EMAIL PROTECTED]> said: > > > On 11090 March 1977, Marcin Owsiany wrote: > >> Now I need to decide what the relationship between these two should > >> be. > > > Depends. > > Hmm. Let us examine the two common cases: > a) User has not bought proprietary dictionaries. > i) With recommends installed by default; they can have a working >package. Without that, the binary package is useless. >ii) With Depends, the binary ackage works. > b) User has proprietary dictionaries. > i) With recommends, the user can just install the proprietary >package first. The system works >ii) With Depends, there is a possible conflict; or else you have a >useless package installed, whether you want it or not. I don't think the other dictionaries conflict each other. > If we are going to transition to installing Recommends by > default in lenny, I would say go with the Recommends, since it caters > to more users. > > Or else, use Depends, but that makes the system less efficient > for those of our users who decide they want a partially proprietary > solution (which we promise to support as well, as I recall). Sounds like a good strategy. I'll make it Recommends, as it will be better for people using systems like an armel-based nokia (hi, Piotr) which I suppose doesn't have a particularily large mass storage. If it turns out that recommends won't be installed by default for lenny, I can easily turn it into a Depends. > > But we dont care about those non-free files, as they wont ever end up > > in a thing where you could add some relation in your package control > > data. > > Sure, but the proprietary .deb could use Enhances :). I would be quite astonished if there ever was a deb of any of the proprietary dictionaries :) -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 signature.asc Description: Digital signature
Request for ideas how to fix #297074
First, a short explanation of the use case: 1. User runs poedit (aka potooledit) on a partially translated po file. 2. Poedit retrieves only the untranslated messages from the file (by filtering it through potool -fnt) and puts them into a temporary po file 3. Poedit launches $EDITOR on that temporary po file 4. User does some translation, saves the file, exits the editor 5. Poedit merges the original and the temporary file back together Now, to reproduce the bug: 1. use an editor which can auto-detect the file encoding, e.g. vim AND 2. run poedit on a file which is in encoding A, while your locale is set to use encoding B. (where neither A nor B is a subset of the other. For example UTF-8 and Latin2) What happens in step 3 is that vim looks at an ascii-only file (since msgids are in POSIX locale) and when the user inputs the translation in her own language, the editor decides to use encoding B (since it's the locale default). Then in step 5 poedit merges the original (in encoding A) and the temporary (in encoding B) creating a broken and a difficult to fix file with different parts in differing encodings. Does anyone have any ideas on how to fix this properly, keeping in mind that poedit is editor-agnostic so it is hard to determine what encoding the editor has chosen to use for the temporary file. The only metadata available seems to be the Content-type field of the header in the original po file, but I can't see how to enforce it for the temporary file... -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 signature.asc Description: Digital signature
Bug#602782: ITP: command-runner-applet -- a panel applet which periodically displays a command output
Package: wnpp Severity: wishlist Owner: Marcin Owsiany * Package name: command-runner-applet Version : 0.1 Upstream Author : Marcin Owsiany * URL : N/A * License : GPLv2 Programming Lang: Python Description : a panel applet which periodically displays a command output This applet periodically runs a configured shell command and displays its output in a text label on the GNOME panel. . It is useful for keeping track of something, for which having a terminal window constantly open would be inconvenient. It's very simple for now, but does its job. A snippet from the README follows: How does it work You add the applet to your panel the usual way: right-click, select "add to panel" and select the Command Runner applet. Once it starts, it loads its configuration and periodically runs a shell command, displaying its result in a simple text label on the panel, pausing for 5 seconds between the command invocations. The command which is run is configurable via a little 'Preferences' dialog accessible by right-clicking the applet. There is also an 'About' dialog. The default command is "echo 'Hello.'" What is it good for? I deveped it to be able to keep an eye on the size of the mail queue on my laptop, to avoid the problem where a misconfiguration I introduced would stop any mail from being sent from my system. -- 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/20101108021904.18319.51164.report...@beczulka
Best practice for cleaning autotools-generated files?
Hello, The current best practice for dealing with packages using GNU autotools (as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to run autoreconf in a prerequisite of a build target, and to remove its results in the clean target. However that README does not give any hints on how to best do the cleaning. How are others doing it? I could think of the following ways: * maintain a blacklist of generated files, and "rm" them in the clean target. This has the downside that as soon as any of: - automake - aclocal - autoconf - autopoint - autoheader - libtoolize decides to introduce a new autogenerated file, my package is going to collect cruft on a sourceful rebuild (e.g. NMUs). And because of the time skew problems, it is cruft which can potentially break the build in subtle ways. Looking (for example) at the amazing list of files that autopoint copies into the po/ subdirectory, I have very little faith that something new won't appear in the future. The only way this would be acceptable was if there was a way to make dpkg-build abort if added files are found outside the debian directory. That would cause the person building the package to add any new files to the blacklist. OTOH the security team probably wouldn't like it? * maintain a whitelist of distributed files, and "rm" everything else (apart from the debian directory) in the clean target. Since I use (or plan to use) git-buildpackage, I don't have a tarball which could serve as an authoritative whitelist. Thus an additional whitelist refresh step would be required every time I merge the upstream branch into the debian branch. That's bad. Furthermore, a whitelist approach would mercilessly elliminate all files on a "clean", so one would have to be really careful not to leave unchecked but precious files in the source tree at any time... :-/ * for every autoool, maintain an anti-autotool that would know how to revert the actions of its counterpart. Basically just like automake-generated files encode the knowledge of how to "make clean" after a "make all", there would need to be a "-clean" counterpart for every autotool that autoreconf can call. However this would need to be a team effort, as such cleanup tools would need to closely follow their "generator" counterparts. Are there other ways? Comments? regards, -- Marcin Owsiany http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- 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/20110315222957.GA5440@beczulka
Re: Best practice for cleaning autotools-generated files?
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote: > How are others doing it? Thanks for all the responses (I never expected to start such a big discussion - it must have been a while since I last read debian-devel), and especially for the pointer to dh-autoreconf. This looks like exactly what I was looking for! I wish it was mentioned in the autotools-dev README. regards, -- Marcin Owsiany http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- 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/20110317213849.GJ9900@beczulka
Bug#618945: ITP: gaduhistory -- a program for reading EKG history
Package: wnpp Severity: wishlist Owner: Marcin Owsiany * Package name: gaduhistory Version : 0.4 Upstream Author : Dominik "Socek" Długajczyk * URL : http://projects.socek.org/index.php/p/gaduhistory/ * License : GPLv2+ Programming Lang: Python Description : a program for reading EKG chat history This program lets you view Gadu-Gadu chat history of the EKG and EKG2 programs in an ncurses-based text interface. It uses SQLite databases internally for fast access. -- 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/20110319184408.12831.57639.reportbug@beczulka
Suspicious reply from katie
I have a package in experimental: [EMAIL PROTECTED]:~$ madison ekg2 ekg2 | 20040912+1500-1 | experimental | source, alpha, hppa, i386, mips, sparc [EMAIL PROTECTED]:~$ I have just uploaded another version, which resulted in receiving the attached message. Note the NEW status, and the warning. Is this a katie bug? Or did I do something wrong? regards, Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 --- Begin Message --- (new) ekg2_20041007+2000-1.diff.gz optional net (new) ekg2_20041007+2000-1.dsc optional net (new) ekg2_20041007+2000-1_i386.deb optional net WARNING: Already present in main distribution. instant messenger client for UNIX systems EKG2 is an open source instant messenger program for UNIX systems. The program has a plugin-based structure, and supports multiple protocols, currently Jabber, Gadu-Gadu and IRC. . The program is being actively developed, but already has many useful features, including: - irssi-like ncurses interface, with mouse support - launching shell commands on certain events - "remote control" via pipe or socket - encryption support - sending SMs (using an external program such as sms-pl) - mail checking . Homepage: http://ekg2.org/ (new) ekg2_20041007+2000.orig.tar.gz optional net Changes: ekg2 (20041007+2000-1) experimental; urgency=low . * New snapshot from upstream. * Removed installation instructions for docs and examples which were removed upstream (this includes stale manpages, which need to be rewritten). * Don't install commands.txt and vars.txt twice, instead symlink from docs to the file installed by upstream Makefiles. Announcing to debian-devel-changes@lists.debian.org Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. --- End Message --- signature.asc Description: Digital signature
Bug#144046: general: Sections are not finely grained
On Mon, Apr 22, 2002 at 03:46:06PM +0200, Javier Fernandez-Sanguino Pena wrote: > As a suggestion, I would use the layout used by either the current Menu > system, the GNOME or KDE proyect for the layout of applications together > with some of our "special" sections (base). I think it would be better to drop the sections altogether and use a keyword-based system someone suggested a few months ago. The advantages would be: - ultimate fine-grainedness (?) - no dillemas about where to put packages which fit in more than section (like x11 net-related programs) Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#144046: general: Sections are not finely grained
On Mon, Apr 22, 2002 at 04:15:45PM +0200, Javier Fernández-Sanguino Pe?a wrote: > > I think it would be better to drop the sections altogether and use a > > keyword-based system someone suggested a few months ago. The advantages > > would be: > > - ultimate fine-grainedness (?) > > - no dillemas about where to put packages which fit in more than > >section (like x11 net-related programs) > > Users need a hierachical layout in order to find software. Who said that available keywords must be kept in a flat list? :-) You could always group them in sections! I think that a properly designed keyword system can have all the benefits of a section-only system, while being much more flexible at the same time. > Keyword > by themselves are not that much useful since they would be only appropiate > to the language used. What do you mean? > Several disadvantages: > > 1.- more difficult to translate than sections How is "modem" more difficult to translate then "comm"? :-P > 2.- are not organised hierarchicaly (sp?) Like I said, grouping them shouldn't be a problem. Then selecting a group in a hypothetical package browser could mean the same as selecting a "OR" of all the keywords in it. > 3.- difficult to represent graphically in a package-administration gui > (sections are easily represented as trees). Ease of representation doesn't mean ease of use. The problem is with packages which might be in more than one subtree (i.e. section): think of a GNOME IRC client (could be both in x11/gnome or in net/irc in the setup you suggest) or some network-based scientific computation system (both in net and science/math). Since a package may only be in one section, if you dive into wrong subtree, you're moving away from the goal. This is the disadvantage of a tree system. But when using keywords, each keyword you select brings you closer to the goal. You could think of keywords like of a tree system, where each package can be at as many branches as many keywords it has. I hope you know what I mean. > If you want to have a keyword-based system I would suggest you > take a look at dpkg-iasearch (yes, not documented, but it's a proof of > concept) which uses natural language retrieval techniques (TFIDF > vectorisation of documents) to allow for more powerful searchs than > "apt-cache search XXX". I'll have a look at it. But I think that such tools would be most useful if each package would have a "Keywords:" field. > Also take in account that the users will always see a > hierarchicaly (sp?) division of software if using the menu system (in any > window manager) or KDE and GNOME. I guess that's a completly different thing. We're discussing package management now. regards Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: a new home for debian-installer
On Sun, Nov 24, 2002 at 11:07:35AM +0100, Mateusz Papiernik wrote: > > Since I'm a Norwegian and not a German, I'd prefer not to. ;) My > > German is quite rusty. > If it will only the page, which is now, I can translate it into Polish, > but I haven't debian-account yet. > > btw, official debian polish translator AFAIR is porridge? Well, there's no such thing as an "official translator". I'm just a coortinator, see http://www.debian.org/devel/website/translation_coordinators BTW you can always send me your translation and I can commit it. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Pick a name, any name...
On Wed, Nov 27, 2002 at 11:24:10AM +0100, Francesco Paolo Lovergine wrote: > I like maintaining the idea of forge, so my proposal is VULCAN > (from Roman mithology). > He was the God of volcanic fire and of metal work. Maybe "lemnos"? This is where he used to work... Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
/usr/{share/man,bin} vs /usr/X11R6/{man,bin} (policy 12.8.7)
Hi!
There is a package I adopted (bugsx), which uses Imake. However the
previous maintainer didn't use upstream makefile install{,.man} targets
(which put the binary and manpage in /usr/X11R6/{man,bin}), and instead
installed them manually into /usr/{share/man,bin}.
My question is: how to interpret policy section 12.8.7. Is to mean:
"All packages using imake should puth files where imake-generated
makefile would put them, period."
or
"Everything should go to /usr/{bin,share/man}, but if your package uses
imake, you're allowed to be lazy and leave it the old way".
regards,
Marcin
--
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Are build-dependancies mandatory?
On Fri, Apr 27, 2001 at 06:00:07AM -0500, BugScan reporter wrote: > > Package: cvs (debian/main) > Maintainer: Eric Gillespie, Jr. <[EMAIL PROTECTED]> > 95263 missing build dependency The policy says: A source package may declare a dependency or a conflict on a binary package. Then why is missing build dependency considered an RC bug? I know build-depends is a good thing, but shouldn't the policy be changed then? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Are build-dependancies mandatory?
On Fri, Apr 27, 2001 at 06:13:37AM -0500, Adam Heath wrote: > On Fri, 27 Apr 2001, Marcin Owsiany wrote: > > The policy says: > > > > A source package may declare a dependency or a conflict ^^^ > > on a binary package. [...] > Some 3.x policy version added build dependencies. If your package follows > said policy, then it must have correct build dependencies. I still don't understand why the policy (version 3.5.3.0) doesn't simply say "must" rather then "may". Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Are build-dependancies mandatory?
On Fri, Apr 27, 2001 at 03:25:54PM -0700, Sean 'Shaleh' Perry wrote: > > > > I still don't understand why the policy (version 3.5.3.0) > > doesn't simply say "must" rather then "may". > > > > Debian is a community which exists for the mutual benefit of its members. > > Members playing games like 'policy does not say I *HAVE* to do it' do not make > Debian a better place. Don't get me wrong, I was just trying to learn what's the status of build depends. Now it seems it's a standard, while the policy gives the impression it's some kind of a draft... Marcin PS: PLEASE respect my mail-followup-to. I do read mail from lists I'm subscribed to. -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Are build-dependancies mandatory?
On Mon, Apr 30, 2001 at 09:18:20AM +0100, Julian Gilbey wrote: > On Sun, Apr 29, 2001 at 05:05:08PM -0700, Daniel Schepler wrote: > > Is this an inconsistency with the above quote from section 7.6, which > > uses the word "may"? > > Yes. Ah, you see my point now :) Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Dpkg problems
On Tue, May 01, 2001 at 04:15:58PM -0400, Jon Eisenstein wrote: > I seem to be in a very troublesome spot... My dpkg segfaults in any needed > situation: Maybe try strace'ing it (of course if you have strace installed)? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Dpkg problems
On Tue, May 01, 2001 at 06:12:29PM -0400, Jon Eisenstein wrote:
> open("/var/lib/dpkg/status", O_RDONLY) = 4
> fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> old_mmap(NULL, 0, PROT_READ, MAP_SHARED, 4, 0) = 0
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
I'd say it _might_ be corrupt /var/lib/dpkg/status, though dpkg
usually exits gracefuly in such cases...
Marcin
--
Marcin Owsiany <[EMAIL PROTECTED]>
http://student.uci.agh.edu.pl/~porridge/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: rfc1149
On Wed, May 02, 2001 at 09:50:01PM +0200, [EMAIL PROTECTED] wrote: > 11 years ago IETF described a IP protocol to transport IP datagrams using > pigeons. African or European? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: rfc1149
On Wed, May 02, 2001 at 06:20:30PM -0400, Jaldhar H. Vyas wrote: > On Wed, 2 May 2001, Daniel Burrows wrote: > > > Actually, I think it has been implemented recently. I think maybe a > > Debian package would have to go into contrib though, unless you can find a > > way to squeeze pigeons into a .deb ;-) > > > > Haven't you heard the expression "free as a bird"? Pigeons belong in > main. We just need to create new section of the archive up in a tree or > something. No need to create a section for them. Birds can sit on the tree directly. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Locale for i18n boot-floppies
Since nobody helped on debian-boot, I'm posting this here. Anyone? thanks Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 --- Begin Message --- Hi! The status is that we need a locale for i18n bf. Edmund GRIMLEY EVANS posted a locale definition that should be both usable and small. (attached) However I seem to lack the knowledge needed to compile it: [EMAIL PROTECTED]:~$ LANG=C localedef -i c-utf8-in C-at-UTF8 /usr/share/i18n/locales/i18n:1597: LC_MONETARY: unknown character in field `currency_symbol' no output file produced because warning were issued Please help Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 comment_char % escape_char / LC_IDENTIFICATION title "POSIX/i18n locale for UTF-8" source "" address"" contact"" email "debian-boot@lists.debian.org" tel"" fax"" language "" territory "" revision "draft" date "2001-05-30" % category "[EMAIL PROTECTED]:2000";LC_IDENTIFICATION category "[EMAIL PROTECTED]:2000";LC_CTYPE category "[EMAIL PROTECTED]:2000";LC_COLLATE category "[EMAIL PROTECTED]:2000";LC_TIME category "[EMAIL PROTECTED]:2000";LC_NUMERIC category "[EMAIL PROTECTED]:2000";LC_MONETARY category "[EMAIL PROTECTED]:2000";LC_MESSAGES category "[EMAIL PROTECTED]:2000";LC_PAPER category "[EMAIL PROTECTED]:2000";LC_NAME category "[EMAIL PROTECTED]:2000";LC_ADDRESS category "[EMAIL PROTECTED]:2000";LC_TELEPHONE END LC_IDENTIFICATION LC_COLLATE copy "POSIX" END LC_COLLATE LC_MESSAGES copy "POSIX" END LC_MESSAGES LC_NUMERIC copy "POSIX" END LC_NUMERIC LC_TIME copy "POSIX" END LC_TIME LC_ADDRESS copy "i18n" END LC_ADDRESS LC_CTYPE copy "i18n" END LC_CTYPE LC_MEASUREMENT copy "i18n" END LC_MEASUREMENT LC_MONETARY copy "i18n" END LC_MONETARY LC_NAME copy "i18n" END LC_NAME LC_PAPER copy "i18n" END LC_PAPER LC_TELEPHONE copy "i18n" END LC_TELEPHONE --- End Message ---
Re: Could be this user be nuked from the ML, too ? (was: Wiadomo?? nie mog?a by? dostarczona)
On Thu, Sep 13, 2001 at 09:04:20AM +0200, Martin Quinson wrote:
> Every time I post to debian-devel, I get this automatic reply I can read. Is
> the fault of seting a wrong auto-responder grave enough to nuke this guy
> from the list, or should I set a procmail rule ?
>
> Thanks, Mt.
>
> On Thu, Sep 13, 2001 at 08:56:57AM +, Tomek Zubilew wrote:
> > Przykro mi, ale Twoja wiadomo?? o temacie "splitting /var/lib/dpkg/status
> > and handling desc translation (was: ddts notification)" nie mog?a by?
> > dostarczona do adresata ("Tomek Zubilew" <[EMAIL PROTECTED]>). Powodem tego
> > jest przekroczenie dozwolonej
> > pojemno?ci jej/jego skrzynki pocztowej, spr?buj p??niej.
BTW this means "quota exceeded", so this is probably this guy's
ISP's fault.
Marcin
--
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: How many people need locales?
On Sun, Sep 23, 2001 at 10:45:13PM -0400, Adam Di Carlo wrote: > Eduard Bloch <[EMAIL PROTECTED]> writes: > > > Okay, if nobody objects I will start implementing support for it in > > boot-floppies (dbootstrap). > > We already support all this. Please work with what we have - don't > reinvent the wheel. We just need some help with the fonts, now, I > belive. Not sure if slang-wide every was uploaded, either... Fonts seem OK. What needs fixing is how dbootstrap displays boxes while running in a bterm. Please see my posts to -boot from this month for more information. Marcin
Re: OpenPKG vs. APT
On Sun, Jan 13, 2002 at 11:37:41AM -0800, Will Lowe wrote: > > Is there any deb available for it? > > Not currently. If there's a lot of demand I'll package it, but it > seemed silly to bloat the Packages file further by making a .deb > containing 139 lines of perl. Maybe it should be just added to apt package as an example? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Debbugs and ACK messages
On Wed, Apr 03, 2002 at 07:38:28PM -0500, Anthony DeRobertis wrote: > [EMAIL PROTECTED] > > I think we need a better way to specify flags. Especially > because now we've got to worry about which comes first (or does > it matter)? But then we need a way for these flags to be easily propagated to addresses we currently use: [EMAIL PROTECTED] etc... Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#141070: ITP: aptconf -- debconf infrastructure for setting up apt sources
On Wed, Apr 03, 2002 at 04:03:27PM -0500, Jeff Licquia wrote: > On Wed, 2002-04-03 at 13:38, Rob Bradford wrote: > > Ooh nice, maybe you could integrate with apt-spy or something to find > > the fastest for the user? > > I don't see why not, though I'd be more inclined to add pin support > first. I had a crazy idea of doing directed graphs for country support, > so you could just pick your country and the software would find the > "closest" mirror. It's not that simple. For example in Poland there are a few mirrors, and the "closest" depends on the exact location/ISP of the user. Actually pretty often some mirrors abroad are _much_ faster than the Polish ones. Also the situation changes frequently (suddenly a very good mirror becomes outdated or unreachable), so a tool that automatically probes the mirrors via network is a must. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#650200: ITP: autorenamer -- program to rename files to make them sort in given order
Package: wnpp Severity: wishlist Owner: Marcin Owsiany * Package name: autorenamer Version : 0.1 Upstream Author : Marcin Owsiany * URL : https://github.com/porridge/autorenamer * License : BSD Programming Lang: Python Description : program to rename files to make them sort in given order This is a simple graphical program that lets you reorder the files using drag-and-drop and then changes the names of the files such that their alphabetical sorting matches the ordering you chose. . Currently the renaming consists of prepending each filename with a short number. . The program displays thumbnails of files using GNOME libraries. -- 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/2027174315.2973.32738.reportbug@beczulka
Automatically dumping test-suite.log on make check failure
Does anyone know a way to make the automake-generated test suite scripts cat the test-suite.log to stderr on failure? It just reports which tests failed but hides the actual messages. This is most annoying on buildds which then promptly remove the whole build dir, and one has to then tediously find a porter box, set up schroot, fetch the package, install build-deps, run the build and then finally manually cat the log. Example: make[7]: Entering directory `/«PKGBUILDDIR»/test/automatic' PASS: endian1 PASS: convert PASS: message1 PASS: message2 PASS: packet PASS: hash FAIL: connect PASS: resolver PASS: protocol make[8]: Entering directory `/«PKGBUILDDIR»/test/automatic' Making all in script make[9]: Entering directory `/«PKGBUILDDIR»/test/automatic/script' make[9]: Nothing to be done for `all'. make[9]: Leaving directory `/«PKGBUILDDIR»/test/automatic/script' make[9]: Entering directory `/«PKGBUILDDIR»/test/automatic' make[9]: Nothing to be done for `all-am'. make[9]: Leaving directory `/«PKGBUILDDIR»/test/automatic' make[8]: Leaving directory `/«PKGBUILDDIR»/test/automatic' Testsuite summary for libgadu 1.12.0-rc3 # TOTAL: 9 # PASS: 8 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See test/automatic/test-suite.log make[7]: *** [test-suite.log] Error 1 more at https://buildd.debian.org/status/fetch.php?pkg=libgadu&arch=kfreebsd-amd64&ver=1%3A1.12.0~rc3-1&stamp=1399557832&file=log -- Marcin Owsiany http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140508171048.GA20344@localhost
Re: Automatically dumping test-suite.log on make check failure
2014-05-08 19:33 GMT+02:00 Guillem Jover : > Hi! > > On Thu, 2014-05-08 at 19:10:48 +0200, Marcin Owsiany wrote: > > Does anyone know a way to make the automake-generated test suite scripts > cat > > the test-suite.log to stderr on failure? It just reports which tests > failed but > > hides the actual messages. This is most annoying on buildds which then > promptly > > remove the whole build dir, and one has to then tediously find a porter > box, > > set up schroot, fetch the package, install build-deps, run the build and > then > > finally manually cat the log. Example: > > Yes, pass VERBOSE=1 to the «make check» call. This was brought up > recently in the following thread: > > <https://lists.debian.org/debian-devel/2014/04/msg00322.html> > Awesome, thank you! Marcin
Bug#929040: ITP: tty-solitaire -- klondike solitaire game for text terminal
Package: wnpp Severity: wishlist Owner: Marcin Owsiany * Package name: tty-solitaire Version : 1.1.1 Upstream Author : Murilo Pereira * URL : https://github.com/mpereira/tty-solitaire * License : MIT Programming Lang: C Description : klondike solitaire game for text terminal This game runs in any terminal with UTF-8 support.
Bug#1022074: ITP: ledgerhelpers -- collection of helper programs and a helper library for Ledger (ledger-cli)
Package: wnpp Severity: wishlist Owner: Marcin Owsiany X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ledgerhelpers Version : 0.3.4 Upstream Author : Manuel Amador (Rudd-O) * URL : https://github.com/Rudd-O/ledgerhelpers * License : GPLv2+ Programming Lang: Python Description : collection of helper programs and a helper library for Ledger (ledger-cli) This is a collection of small single-purpose programs to aid your accounting with Ledger (ledger-cli). Think of it as the batteries that were never included with Ledger. What can you do with these programs: - Enter transactions easily with addtrans. - Update your price quotes with updateprices. - Record multi-currency ATM withdrawals with withdraw-cli. - Record FIFO stock or commodity sales with sellstock-cli. - Interactively clear transactions with cleartrans-cli. - Keep your ledger chronologically sorted with sorttrans-cli. I plan to maintain this package inside the Debian Python Team.
