Re: RFS: pyscrabble
First of all: well done! Consider joining PAPT[1] and moving your package there Comments: * You still need python-setuptools in Build-Depends, I know that you've patched setup.py to not use pkg_resources, but clean-patched rule doesn't depend on patch (test it in pbuilder and you'll know what am I talking about) * If you start server twice in a row, you cannot stop it later (pyscrabble-server.pid contains wrong PID, start-stop-daemon should handle this, but apparently it doesn't) [1] http://python-apps.alioth.debian.org/policy.html -- http://people.debian.org/~piotr/sponsor.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP bugs
On Tue, 2 Oct 2007 13:15:42 +0200 Pierre THIERRY [EMAIL PROTECTED] wrote: Scribit Neil Williams dies 02/10/2007 hora 09:57: ITP bugs are not required. ITP bugs are required by most sponsors. As DD's, you and I are free to skip ITP bugs but maintainers needing sponsorship should file an ITP. Indeed there's very valuable information layed out in a very friendly way in the ITP, like language, license and homepage of the project being packaged. I can understand why sponsors may want to require them. Actually, I require the same information (and then some more) in the RFS email when sponsoring. I require the ITP for different reasons: An ITP open for at least a week ensures that other DD's and interested parties have a chance to check the proposed package name for conflicts, add a comment about whether there are likely problems just from the type of package (e.g. yet another image gallery website system) or the likely dependencies (php4). This is because an ITP report always gets copied to debian-devel as a special case of bug handling. More eyes means more problems are spotted before the package gets anywhere near any users. An ITP also helps avoid duplicated work - you should always check for an ITP before starting work on any new package. That is why an ITP should have been opened for at least a week before I do the sponsoring. File the ITP when you start working on a package - before you've even run your first build. File an RFS only when you have done everything you can to prepare an acceptable package and have uploaded it to mentors. In the RFS, start with the info from the original ITP and then start adding more information for the sponsor. Those are my recommendations for ITP and RFS. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp3zPKa05sBe.pgp Description: PGP signature
Re: How package a binary library with unversioned soname?
Nikolaus Schulz [EMAIL PROTECTED] writes: On Mon, Oct 01, 2007 at 05:35:36PM -0700, Russ Allbery wrote: While with non-free software you can't really change the binaries, you definitely *can* change the packaging structure however you'd like. Does it make sense to have six different packages? Or is this really one thing that should be shipped as a single package? Wouldn't merging the packages require some patch management system? I hoped to get along without such a thing. It would require that you make modifications to the upstream source, probably. So will lots of other things, though. The only packages for which I don't end up needing some sort of patch management system or strategy for modifying the upstream source are ones for which I'm upstream. How big? Byte-wise they're small, my current GPL deb's are 100k each. The binary library packages eat 700k for one printer series. It sounds like between that and the separate binaries for different printing systems, it would be useful to separate things out into separate packages. I personally am not particularly uncomfortable with shipping binary packages that use RPATH to find libraries in a subdirectory of /usr/lib, provided that they have a tight dependency on exactly the version of the library package they need (which for this application you'll probably need anyway). Other people may differ. Hmm, I guess I should mention another problem. Unfortunately one of these binary libraries has a path hard-coded: it expects private data files in /usr/lib/bjlib. I'm not sure, is this fatal? What is the best course of action here? What sort of private data files? At least at first glance, that doesn't seem unreasonable, as long as it doesn't expect to do something like write to the at path. This pile of code does sound like a rather spectacular mess, though, so it's worth thinking long and hard about whether Debian really needs it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP bugs
On Mon, 2007-10-01 at 20:41 +0200, Pierre THIERRY wrote: Among my 5 packages waiting at mentors.d.n, only the two more recents close ITP bugs. Would it be better practice if I issue a new Debian revisions for the 3 others after opening an ITP bug, with a changelog closing the latter? An ITP bug is a good idea to avoid duplication. I wouldn't bother with a new package just to close an ITP, though. File one and close it by hand when the package is uploaded. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Reason for Failed build on some arch only
Hi, My package Xosview is failed to build on (atleast) two arch with same reason. Following are links from buildd. mipsel: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mipsel;stamp=1190303855 mips: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mips;stamp=1190807389 Can anyone please look at guide me to some point? No bug reported, but it is safer to fix it before that :P -- Cheers, --- Kartik Mistry || GPG: 0xD1028C8D || IRC: kart_ kartikmistry.org/blog || kartikm.wordpress.com -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reason for Failed build on some arch only
On 2007-10-03, Kartik Mistry [EMAIL PROTECTED] wrote: Hi, My package Xosview is failed to build on (atleast) two arch with same reason. Following are links from buildd. Hi! Did you actualy read the logs? It says quite clearly: your config.guess and config.sub is outdated. Find newer versions in autotools-dev /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reason for Failed build due to using $HOME
On Wed, 3 Oct 2007 18:52:43 +0530 Kartik Mistry [EMAIL PROTECTED] wrote: Hi, My package Xosview is failed to build on (atleast) two arch with same reason. You are using /home/ for some reason and that is not allowed - building a package should not cause any changes outside the build directory. The mips and mipsel buildd's are specially configured to catch these errors for specialised reasons, the clue is: failed to open configuration file `/nonexistent/.dpkg.cfg' for reading: Permission denied failed to open configuration file `/nonexistent/.dpkg.cfg' for reading: Permission denied $HOME is set to /nonexistent/ and is inaccessible, deliberately. Stop trying to use $HOME in your build. It looks like you are expecting to read dpkg-architecture values from a file instead of retrieving them from the dpkg-architecture binary itself. man dpkg-architecture Following are links from buildd. mipsel: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mipsel;stamp=1190303855 mips: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mips;stamp=1190807389 Can anyone please look at guide me to some point? No bug reported, but it is safer to fix it before that :P The bug is in your package and it would be RC so fix it soon. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp4DiuANjcS6.pgp Description: PGP signature
Re: Reason for Failed build on some arch only
On Wed, Oct 03, 2007 at 06:52:43PM +0530, Kartik Mistry wrote: Hi, My package Xosview is failed to build on (atleast) two arch with same reason. Following are links from buildd. mipsel: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mipsel;stamp=1190303855 mips: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mips;stamp=1190807389 Can anyone please look at guide me to some point? No bug reported, but it is safer to fix it before that :P I think this documents your options: /usr/share/doc/autotools-dev/README.Debian.gz Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pyscrabble
On tisdagen den 2 oktober 2007, Piotr Ożarowski wrote: First of all: well done! Consider joining PAPT[1] and moving your package there Thanks! Comments: * You still need python-setuptools in Build-Depends, I know that you've patched setup.py to not use pkg_resources, but clean-patched rule doesn't depend on patch (test it in pbuilder and you'll know what am I talking about) *bonk* I think the most natural solution is to let clean-patched depend on the patches being applied, as the name of the target suggests. * If you start server twice in a row, you cannot stop it later (pyscrabble-server.pid contains wrong PID, start-stop-daemon should handle this, but apparently it doesn't) Always this problem with script daemons, where /proc/pid/exe isn't the program you started. I've solved it with --startas now. When I was at it, I also LSBized the init script. I also improved the README.Debian for pyscrabble-server, explaining why the log isn't automatically rotated, and then I added -r to the dh_installinit call for the same reason. Finally I fixed the bug that the Close button in the About dialog didn't work. An updated package has been uploaded to mentors.d.n. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) signature.asc Description: This is a digitally signed message part.
Re: How package a binary library with unversioned soname?
On Wed, Oct 03, 2007 at 12:57:06AM -0700, Russ Allbery wrote: Nikolaus Schulz [EMAIL PROTECTED] writes: Wouldn't merging the packages require some patch management system? I hoped to get along without such a thing. It would require that you make modifications to the upstream source, probably. So will lots of other things, though. The only packages for which I don't end up needing some sort of patch management system or strategy for modifying the upstream source are ones for which I'm upstream. Sorry, it's clear that I have to modify the source, and I have already done so. With patch management system I meant something like dpatch. Doesn't dumping several upstream tarballs in one Debian source package require something like that? How big? Byte-wise they're small, my current GPL deb's are 100k each. The binary library packages eat 700k for one printer series. It sounds like between that and the separate binaries for different printing systems, it would be useful to separate things out into separate packages. Yes, something like two or three packages for each printer series might be reasonable. In principle, I think it is desirable to * keep pure CUPS packages separate, * keep core drivers and GUI clients seperate, * keep programs separate that depend on the non-free libraries. I still have to check what can be reasonably done here. But the GUI program which pops up the printing dialog shares two binary libraries with the core driver, so it's clear I can't split this if I have to make these libs private to one package. :-( I personally am not particularly uncomfortable with shipping binary packages that use RPATH to find libraries in a subdirectory of /usr/lib, provided that they have a tight dependency on exactly the version of the library package they need (which for this application you'll probably need anyway). Other people may differ. I agree. So making the libraries private would be a possible way to do it, sidestepping the shlibs problem... Given the annoying dependencies of the GUI client, is there any doable alternative? If there is no hard showstopper, I would still find it more natural to have the libs as a separate package. One could argue that certainly no other free software will link against such undisclosed libraries, but why shouldn't there exist more than one (non-free or contrib) package using them? Do the strict assumptions of the shlibs format really make it impossible to package libraries with unversioned sonames? Hmm, I guess I should mention another problem. Unfortunately one of these binary libraries has a path hard-coded: it expects private data files in /usr/lib/bjlib. I'm not sure, is this fatal? What is the best course of action here? What sort of private data files? At least at first glance, that doesn't seem unreasonable, as long as it doesn't expect to do something like write to the at path. Configuration files and undocumented binary data, probably describing internals of the supported printers. They seem to be read-only. I was just worrying about the directory name, because it might not comply with policy; especially since bjlib probably won't be the package name. This pile of code does sound like a rather spectacular mess, though, so it's worth thinking long and hard about whether Debian really needs it. It is an awful mess, yes! And I've asked myself more than once if it's a sane idea to package this. But these drivers support printer models and model specific features for which, to my knowledge, no free alternative exists. And my impression is that many Debian and Ubuntu users already use these drivers anyway; either by alienizing the official Canon rpm's, or by installing the unofficial Debian packages at [1]. And even the latter don't even try to meet Debian standards. So I think, yes, there are many Debian users who need it; and I want to package it. Clearly this won't be a very nice package, but it will be an ugly package or no package at all. I just hope the thing will finally be good enough to both find a sponsor and have the ftp-masters wave it. Nikolaus [1] http://mambo.kuhp.kyoto-u.ac.jp/~takushi/#canon signature.asc Description: Digital signature
Re: How package a binary library with unversioned soname?
Nikolaus Schulz [EMAIL PROTECTED] writes: Okay, just to be sure: you suggest making a separate library package, but putting the libs in /usr/lib/libpackage and RPATH-linking the binaries, right? That is, treating the library as private, although it is a separate package. Phew. Right. I think this is the best of a set of bad options for the situation that you're in, but that it's acceptable. You'll have to maintain tight dependencies between the binary packages and the library package since there aren't versioned SONAMEs to help and you basically can't use the shlibs system the way it's intended given the structure of these packages. But it's not really that different from a binary that allows plugins that are shipped in a separate package; it just has the direction of dependency reversed. I don't know if others would disagree with me. I guess then there would be no need for a -dev package? Hmm. Upstream has included the necessary header files in every pacakage which needs them. Of course the packages would still need to build-depend upon the libraries, to make the linking succeed. No problem. -dev packages are for Debian users to do development against the libraries or for other packages that depend on those libraries to build against them, neither of which seems to be useful outside of this complex of packages itself. dpkg-shlibdeps would still choke upon the unversioned soname, but I could just hard-code the library dependency and be done with it. There would be no shlibs file. Again no problem, right? That's my take, yes. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How package a binary library with unversioned soname?
Nikolaus Schulz [EMAIL PROTECTED] writes: On Wed, Oct 03, 2007 at 12:57:06AM -0700, Russ Allbery wrote: It would require that you make modifications to the upstream source, probably. So will lots of other things, though. The only packages for which I don't end up needing some sort of patch management system or strategy for modifying the upstream source are ones for which I'm upstream. Sorry, it's clear that I have to modify the source, and I have already done so. With patch management system I meant something like dpatch. Doesn't dumping several upstream tarballs in one Debian source package require something like that? No, they're unrelated. Dumping unrelated tarballs together requires repackaging the upstream source to create a custom .orig.tar.gz file, documenting how you did that (I prefer doing so in debian/copyright), and ideally creating a get-orig-source debian/rules target to redo the work on an automated basis. Configuration files and undocumented binary data, probably describing internals of the supported printers. They seem to be read-only. I was just worrying about the directory name, because it might not comply with policy; especially since bjlib probably won't be the package name. Policy doesn't require that /usr/lib subdirectories be named after the package. It's just recommended because it makes it easier to figure out what belongs to what without falling back on dpkg -S, and because it makes conflicts less likely. If nothing else is using that directory now, I don't expect it would be a problem. It is an awful mess, yes! And I've asked myself more than once if it's a sane idea to package this. But these drivers support printer models and model specific features for which, to my knowledge, no free alternative exists. And my impression is that many Debian and Ubuntu users already use these drivers anyway; either by alienizing the official Canon rpm's, or by installing the unofficial Debian packages at [1]. And even the latter don't even try to meet Debian standards. So I think, yes, there are many Debian users who need it; and I want to package it. Clearly this won't be a very nice package, but it will be an ugly package or no package at all. I just hope the thing will finally be good enough to both find a sponsor and have the ftp-masters wave it. Okay. I don't have an opinion one way or the other -- I personally hate printers, so I'm just commenting from a general Policy perspective. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How package a binary library with unversioned soname?
On Wed, Oct 03, 2007 at 06:29:18PM +0200, Nikolaus Schulz wrote: On Wed, Oct 03, 2007 at 12:57:06AM -0700, Russ Allbery wrote: I personally am not particularly uncomfortable with shipping binary packages that use RPATH to find libraries in a subdirectory of /usr/lib, provided that they have a tight dependency on exactly the version of the library package they need (which for this application you'll probably need anyway). Other people may differ. Oh, sorry, obviously I didn't read that properly! I thought the use of RPATH was restricted to private libraries *which are not shipped as separate packages*. Okay, just to be sure: you suggest making a separate library package, but putting the libs in /usr/lib/libpackage and RPATH-linking the binaries, right? That is, treating the library as private, although it is a separate package. Phew. I guess then there would be no need for a -dev package? Hmm. Upstream has included the necessary header files in every pacakage which needs them. Of course the packages would still need to build-depend upon the libraries, to make the linking succeed. No problem. dpkg-shlibdeps would still choke upon the unversioned soname, but I could just hard-code the library dependency and be done with it. There would be no shlibs file. Again no problem, right? Well, if you say this approach is acceptable and if I don't find a snag, then I'll probably go for it. -- Okay, I've ripped the thread apart a bit, sorry. Please don't ignore the rest of my previous post. Thanks, Nikolaus signature.asc Description: Digital signature
Re: Multiple binary packages
On Wed, 3 Oct 2007 22:35:27 +0200 Jeffrey Ratcliffe [EMAIL PROTECTED] wrote: configure: error: cannot find install-sh or install.sh in . ./.. ./../.. make: *** [config.status] Error 1 install-sh or install.sh is an upstream file, it has nothing to do with the install files in debian/ but it seems to me that writing the appropriate package.install files should be enough. Those determine which files (installed by the package, using install.sh) go into which Debian packages after the split. install.sh is only concerned with before the split. Have you deleted the original file for some reason? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpUzBbrRgBEo.pgp Description: PGP signature
Multiple binary packages
I've been trying to build multiple packages from one source using the example given in http://lists.debian.org/debian-mentors/2007/04/msg00347.html and http://www.miriamruiz.es/weblog/?p=42 as an example. debuild seems to fall over with configure: error: cannot find install-sh or install.sh in . ./.. ./../.. make: *** [config.status] Error 1 debuild: fatal error at line 1228: debian/rules build failed but it seems to me that writing the appropriate package.install files should be enough. This doesn't seem to be doing the trick in the packages (tesseract-ocr and tesseract-ocr-dev) that I am working on. Is there more to it than just the package.install files, or does my mistake lie elsewhere? Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pyscrabble
uploaded, lets see what ftp-masters will say about this trademark issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiple binary packages
Am Mittwoch, den 03.10.2007, 22:35 +0200 schrieb Jeffrey Ratcliffe: I've been trying to build multiple packages from one source using the example given in http://lists.debian.org/debian-mentors/2007/04/msg00347.html and http://www.miriamruiz.es/weblog/?p=42 as an example. debuild seems to fall over with configure: error: cannot find install-sh or install.sh in . ./.. ./../.. make: *** [config.status] Error 1 debuild: fatal error at line 1228: debian/rules build failed If you simply do an: ls -lA hello-0.1 you will see, that the autotools files (install-sh, ...) are links to tools of automake version 1.9. And they are probably dead links, because you miss the automake 1.9 package. But that's just a guess. but it seems to me that writing the appropriate package.install files should be enough. That's correct. However I dislike the `install -d' and `cp' calls in debian/rules. dh_installdirs and dh_install exist. By using dh_install, you don't need to create the directories with dh_dirs first. This doesn't seem to be doing the trick in the packages (tesseract-ocr and tesseract-ocr-dev) that I am working on. Is there more to it than just the package.install files, or does my mistake lie elsewhere? Elsewhere. See above. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: prboom (updated package)
Dear mentors, I am looking for a sponsor for the new version 2:2.4.7+dfsg-1 of my package prboom. It builds these binary packages: prboom - clone of the legendary first person shooter Doom The package appears to be lintian clean. The upload would fix these bugs: 426804 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/prboom - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/prboom/prboom_2.4.7+dfsg-1.dsc I would be glad if someone uploaded this package for me. -- Marco Rodrigues http://Marco.Tondela.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How package a binary library with unversioned soname?
On Wed, Oct 03, 2007 at 11:51:41AM -0700, Russ Allbery wrote: Nikolaus Schulz [EMAIL PROTECTED] writes: Doesn't dumping several upstream tarballs in one Debian source package require something like that? No, they're unrelated. I guess you mean that in a very strict sense... We're talking about merging tightly related upstream packages because they may not warrant stand-alone Debian packages, aren't we? Dumping unrelated tarballs together requires repackaging the upstream source to create a custom .orig.tar.gz file, documenting how you did that (I prefer doing so in debian/copyright), and ideally creating a get-orig-source debian/rules target to redo the work on an automated basis. Okay. I did consider such repackaging, but reading the developers reference regarding that topic made me very reluctant to do so. It's good to see this as a reasonable option; the actual composing of the right set of Debian packages will have to wait until I have the necessary understanding of all involved components. Thanks! Nikolaus signature.asc Description: Digital signature
Re: How package a binary library with unversioned soname?
On Wed, Oct 03, 2007 at 11:48:42AM -0700, Russ Allbery wrote: Nikolaus Schulz [EMAIL PROTECTED] writes: Okay, just to be sure: you suggest making a separate library package, but putting the libs in /usr/lib/libpackage and RPATH-linking the binaries, right? That is, treating the library as private, although it is a separate package. Phew. Right. [...] dpkg-shlibdeps would still choke upon the unversioned soname, but I could just hard-code the library dependency and be done with it. There would be no shlibs file. Again no problem, right? That's my take, yes. Okay, cool, I'll go ahead then. I like this solution. I think it's a pretty good translation of the status of these libraries into packaging. Thanks! Nikolaus signature.asc Description: Digital signature
Re: How package a binary library with unversioned soname?
Nikolaus Schulz [EMAIL PROTECTED] writes: On Wed, Oct 03, 2007 at 11:51:41AM -0700, Russ Allbery wrote: Nikolaus Schulz [EMAIL PROTECTED] writes: Doesn't dumping several upstream tarballs in one Debian source package require something like that? No, they're unrelated. I guess you mean that in a very strict sense... We're talking about merging tightly related upstream packages because they may not warrant stand-alone Debian packages, aren't we? Yes, and I don't see any connection between a patch management system and combining upstream source. They really don't have anything to do with each other so far as I can tell. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How package a binary library with unversioned soname?
On Wed, Oct 03, 2007 at 06:13:43PM -0700, Russ Allbery wrote: Yes, and I don't see any connection between a patch management system and combining upstream source. They really don't have anything to do with each other so far as I can tell. I just imagined having several, unchanged upstream tarballs in one (unpacked) source package, and unpack+patch these sources with some patch management system. This would have preserved the upstream tarballs, which I thought is of very high priority. Might have been a completely dumb idea. :-) Repackaging the source is fine for me, that way I can stick with svn for me and dpkg for the rest of the world, that's great. Nikolaus PS. I'm offline from tomorrow till Sunday. signature.asc Description: Digital signature
RFS: fuse-convmvfs
Dear mentors, I am looking for a sponsor for my package fuse-convmvfs. * Package name: fuse-convmvfs Version : 0.2.4-1 Upstream Author : Z.C. Miao [EMAIL PROTECTED] * URL : http://fuse-convmvfs.sourceforge.net/ * License : GPL Section : utils It builds these binary packages: fuse-convmvfs - mirrors a whole filesystem tree from one charset to another. (perhaps, maps a whole filesystem... would sound better, but I have kept upstream's interpretation here). Long description: convmvfs is a FUSE (File System in Userspace) utility that tranparently mirrors a filesystem tree converting the filenames from one charset to another on the fly. Only the names of files and directories are converted, the file content remains intact. The mirrored tree is mounted at a given mountpoint. The package appears to be lintian and linda clean. The upload would fix these bugs: 445105 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fuse-convmvfs - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget: http://mentors.debian.net/debian/pool/main/f/fuse-convmvfs/fuse-convmvfs_0.2.4-1.dsc I would be glad if someone checked uploaded this package for me. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fuse-convmvfs
On Thu, Oct 04, 2007 at 09:14:51AM +0400, Stanislav Maslovski wrote: convmvfs is a FUSE (File System in Userspace) utility that tranparently Just noticed this misprint in the description and the man page, corrected, package re-uploaded. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
