Processed: tagging as pending bugs that are closed by packages in NEW
Processing commands for cont...@bugs.debian.org: > # Mon Mar 5 07:03:18 UTC 2012 > # Tagging as pending bugs that are closed by packages in NEW > # http://ftp-master.debian.org/new.html > # > # Source package in NEW: fonts-lato > tags 662111 + pending Bug #662111 [wnpp] ITP: fonts-lato -- sans-serif typeface family font Added tag(s) pending. > # Source package in NEW: libtext-bibtex-perl > tags 599485 + pending Bug #599485 [libtext-bibtex-perl] New upstream release (v0.48) Added tag(s) pending. > # Source package in NEW: libtext-bibtex-perl > tags 578633 + pending Bug #578633 [libtext-bibtex-perl] libtext-bibtex-perl: UNIVERSAL->import is getting deprecated with Perl 5.12.0 Added tag(s) pending. > # Source package in NEW: python-fudge > tags 643566 + pending Bug #643566 [wnpp] ITP: python-fudge -- Fudge is a Python module for using fake objects (mocks and stubs) to test real ones. Added tag(s) pending. > # Source package in NEW: mtbl > tags 661208 + pending Bug #661208 [wnpp] ITP: mtbl -- immutable sorted string table library Added tag(s) pending. > End of message, stopping processing here. Please contact me if you need assistance. -- 661208: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661208 662111: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662111 599485: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599485 643566: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643566 578633: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578633 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133093102927593.transcr...@bugs.debian.org
Processed: no owner
Processing commands for cont...@bugs.debian.org: > noowner 603248 Bug #603248 [wnpp] O: keysafe -- safe, simple storage system for passwords Removed annotation that Bug was owned by Mahyuddin Susanto . > thanks Stopping processing here. Please contact me if you need assistance. -- 603248: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603248 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133092964418083.transcr...@bugs.debian.org
Bug#662080: ITP: hadori -- Hardlinks identical files
Julian Andres Klode writes: > On Sun, Mar 04, 2012 at 07:00:13AM +0100, Goswin von Brederlow wrote: >> Timo Weingärtner writes: >> >> > Package: wnpp >> > Severity: wishlist >> > X-Debbugs-CC: debian-de...@lists.debian.org >> > >> >Package name: hadori >> > Version: 0.2 >> > Upstream Author: Timo Weingärtner >> > URL: https://github.com/tiwe-de/hadori >> > License: GPL3+ >> > Description: Hardlinks identical files >> > This might look like yet another hardlinking tool, but it is the only one >> > which only memorizes one filename per inode. That results in less merory >> > consumption and faster execution compared to its alternatives. Therefore >> > (and because all the other names are already taken) it's called >> > "HArdlinking DOne RIght". >> > . >> > Advantages over other hardlinking tools: >> > * predictability: arguments are scanned in order, each first version is >> > kept >> > * much lower CPU and memory consumption >> > * hashing option: speedup on many equal-sized, mostly identical files >> > >> > The initial comparison was with hardlink, which got OOM killed with a >> > hundred >> > backups of my home directory. Last night I compared it to duff and rdfind >> > which would have happily linked files with different st_mtime and st_mode. >> > >> > I need a sponsor. I'll upload it to mentors.d.n as soon as I get the bug >> > number. >> > >> > >> > Greetings >> > Timo >> >> I've been thinking about the problem of memory consumption too. But I've >> come to a different solution. One that doesn't need memory at all. > > I know yet another solution. For each file you visit, you simply visit > the complete tree. Than you have n + 1 visits, but get constant space > usage. > >> >> Instead of remembering inodes, filenames and checksums create a global >> cache (e.g. directory hierachy like .cache//) >> and hardlink every file to there. If you want/need to include uid, gid, >> mtime, mode in there then make that part of the .cache path. >> >> Garbage collection in the cache would be removing all files with a link >> count of 1. >> >> Going one step further link files with unique size [uid, gid, mtime, >> ...] to .cache/ and change that into .cache//> hash>/ when you find a second file with the same size that isn't >> identical. That would save on the expensive hashing of clearly unique >> files. > > So implement an object store and replace files outside the object > store with hardlinks to the store. Yes, this is guaranteed to work > for some cases, but also has problems. If you create files first, and > then move them to the store, you still need to check every file with > link count != 1 and check whether it is in the cache already. And for > this, you need a lookup by inode if you want to avoid hashing. > > And this is basically the same hierarchy as git has: > .git/objects/first 2 hex digits of sha1sum/remaining sha1sum In the above every file is in the cache. A link count of 1 would indicate a new file that hasn't been processed yet. Unfortunately you can also have files with link count != 1 that aren't processed yet, e.g. 2 new files that are hardlinked to each other. Detecting wether a file is already in cache or not actualy needs to check 2 things: 1) link count == 1 => new file, add to cache 2) link count != 1 but hash of file not known (e.g. extended attribute not set) => new set of files that are hardlinks to each other Actually the link count can be completly ignored if you always add a flag when you've processed a file. Note: The above wastes time in the 2nd case since it would checksum all the files that are hardlinks one by one and replace them with hardlinks into the cache. But you could remember the inode and name of the first occurance. This would only use up memory proportionally to the number of new inodes. >> You could also use a hash that computes the first byte from the first >> 4k, second byte from 64k, thrid from 1mb and so on. That way you can >> check if the beginning of 2 files match without having to checksum the >> whole file or literally comprare the two. > > If the beginning can match. They're not guaranteed to match just because > the hashes match. This wouldn't be to proof identity but to quickly proof difference. If the first 4k differ then the file will not match. Only makes sense if you have a lot of big files of equal size. MfG Goswin -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hay39aqg.fsf@frosties.localnet
Bug#518696: [Fwd: Re: Progress?]
Sorry for the previous message, it left my console incomplete; continuing with the intended reply: Προωθημένο Μήνυμα Από: Georgios M. Zarkadas Προς: Rogério Brito Θέμα: Re: Progress? Ημ/νία: Mon, 05 Mar 2012 01:30:00 +0200 Στις 04-03-2012, ημέρα Κυρ, και ώρα 18:44 -0300, ο/η Rogério Brito έγραψε: > Hi, Ondřej. > > On Sun, Mar 4, 2012 at 18:12, Ondřej Surý wrote: > > any progress on uploading to unstable? I can help/sponsor/comaintain. > > If you don't respond, I'll just pick whatever is in collab-maint, > > check it (is the conflict with moreutils solved) and upload to > > unstable? > > Just for the record, I have updated the packaging and pushed it to > collab-maint: > > http://anonscm.debian.org/gitweb/?p=collab-maint/parallel.git > > Please let me know if there is anything else that I should do. > > Regards, > You must do either of following: [1] Declare the package's conflict with moreutils in the control file, because both packages share a binary in the path (/usr/bin/parallel). That, is the debian/control file must contain a line: Conflicts: moreutils Also, it may be needed (someone with more experience in policy should tell) that moreutils also declares that conflict. This is for the case that the default (--gnu) configuration is chosen for the package. [2] Use the --tollef personality as default. Then there is no need for a Conflicts, nor a need to modify moreutils. You just have to use dpkg-divert in the install scripts to divert the moreutils' parallel with your package's version. Regarding ikiwiki-hosting-web, I believe that its only dependency from moreutils is the use of chronic in its cron job. In any case a conflict with that package is not necessary; the conflict with moreutils will be enough. Also, for the case that --tollef / dpkg-divert is chosen, a later change by the site admin of parallel's personality to --gnu will not interfere with the ikiwiki-hosting-web package. Just, FYI, the mentors thread, where the previous package's attempt was discussed is: http://lists.debian.org/debian-mentors/2011/04/msg00203.html I have since that time, taken other paths inside Debian and my interest in packaging parallel has diminished; however if you feel you need help with the dpkg-divert thing (assuming you choose the option [2]) I can devote a small fraction of time to that. regards George Zarkadas signature.asc Description: This is a digitally signed message part
Processed: okay these are the same
Processing commands for cont...@bugs.debian.org: > forcemerge 560244 585877 Bug#560244: ITP: mysql-cluster -- MySQL database server with cluster support Bug#585877: RFP: mysql-cluster Forcibly Merged 560244 585877. > End of message, stopping processing here. Please contact me if you need assistance. -- 560244: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560244 585877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585877 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133090371215141.transcr...@bugs.debian.org
Processed: okay this is a WNPP bug
Processing commands for cont...@bugs.debian.org: > reassign 585877 wnpp Bug #585877 [mysql-5.1] mysql-server: drops cluster support, but the suggested "mysql-cluster" package does not exist Bug reassigned from package 'mysql-5.1' to 'wnpp'. > retitle 585877 RFP: mysql-cluster Bug #585877 [wnpp] mysql-server: drops cluster support, but the suggested "mysql-cluster" package does not exist Changed Bug title to 'RFP: mysql-cluster' from 'mysql-server: drops cluster support, but the suggested "mysql-cluster" package does not exist' > owner 585877 pkg-mysql-ma...@lists.alioth.debian.org Bug #585877 [wnpp] RFP: mysql-cluster Owner recorded as pkg-mysql-ma...@lists.alioth.debian.org. > End of message, stopping processing here. Please contact me if you need assistance. -- 585877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585877 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13309026559524.transcr...@bugs.debian.org
Bug#511715: ITP: gallery3 -- web-based photo album written in PHP
Coin, Quoting you from Gallery's ML: Another thing that should be discussed is whether it's worth having a gallery3 package in the main Debian repository. The benefit of having a package in the Debian repository is the simplicity of installation via "apt-get install gallery3" Having a gallery3 package hosted outside of the main Debian repository (such as my people.debian.org repository) gets the same benefit, assuming one has configured their system to access that repository. While initially somewhat complicated, the setup is a one time cost. There are also ways to simplify the repository setup, such as a helper package. You're not the only DD having hit a license problem, and if every (if not all) DD had created a personal repository for each package causing problem, there would be no central repository at all. Do you intend to support sid, testing, stable, and security up to old-stable by yourself in the long run? Do you really think this situation is sustainable? Now that you have tell upstream that it is not necessary, do you think anyone of them will help you solve the licensing problem? You also forgot about the trust and security problem caused by adding any apt key like explained in your installation procedure[1]. What would happen if your GPG key is compromised? If you want to help Debian and your users you'll have to clean this up and make up a decision. If the source code of the SWF apps cannot be provided, then i think you could provide a package with such files removed and the corresponding features deactivated. If you also want to care about the lost features, and if these files are _really_ allowed to be distributed at all, then you may package them separately in a non-free package which would enhance the free one (and provide a helper script of some sort to activate the feature if needed). Please do not consider this mail an offensive one. I just think you made a mistake and i wanted to explain my point of view. I also think you should perfectly be able to improve the situation. Don't forget you may also ask your fellow developers for opinions and/or help on the MLs. [1] http://codex.gallery2.org/Gallery3:Installation_on_Debian -- Marc Dequènes (Duck) pgpZhk5qN3TZ5.pgp Description: PGP Digital Signature
Bug#662244: RFA: redir -- Redirect TCP connections
Package: wnpp Severity: normal I request an adopter for the redir package. The package description is: It can run under inetd or stand alone (in which case it handles multiple connections). It is 8 bit clean, not limited to line mode, is small and light. Supports transparency, FTP redirects, http proxying, and bandwidth limiting. . redir is all you need to redirect traffic across firewalls authenticate based on an IP address etc. No need for the firewall toolkit. The functionality of inetd/tcpd and "redir" will allow you to do everything you need without screwy telnet/ftp etc gateways. (I assume you are running IP Masquerading of course.) redir is old software, appears to be abandoned upstream (i tried to interest the upstream maintainer in providing some fixes several years ago, but nothing came of it). Pretty much anything that redir can do can probably be done at least as well by socat, so i'm not sure that redir adds much of value to the archive. I plan to do a last bit of maintenance to bring the package up-to-date if anyone wants to adopt it, but may end up requesting its removal from the archive if i get no takers. Regards, --dkg -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120304223253.22334.58617.report...@pip.fifthhorseman.net
Bug#633677: libvia transition
Hi Michael, On Thu, Feb 9, 2012 at 09:38:51 +0100, Michael Hanke wrote: > Dear Release Team, > > I will upload a new SO version of LIBVIA shortly. Right now only ODIN > and LIPSIA use this library. The LIBVIA dependency of ODIN will be > dropped by the next upload (few more days). how many is "few"? :) Cheers, Julien signature.asc Description: Digital signature
Bug#518696: Progress?
Hi, Ondřej.
On Sun, Mar 4, 2012 at 18:12, Ondřej Surý wrote:
> any progress on uploading to unstable? I can help/sponsor/comaintain.
> If you don't respond, I'll just pick whatever is in collab-maint,
> check it (is the conflict with moreutils solved) and upload to
> unstable?
Just for the record, I have updated the packaging and pushed it to collab-maint:
http://anonscm.debian.org/gitweb/?p=collab-maint/parallel.git
Please let me know if there is anything else that I should do.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOtrxKNWtukzmz015B_k2uuRN_Ng=goag-wvhsy50fwv2sx...@mail.gmail.com
Bug#578563: Looking for a new sponsor for FriBID
On tisdagen den 11 oktober 2011, you stated the following: > My prospective sponsor won't be able to sponsor for some time. If anyone > else can offer sponsoring (or even review the packaging), please leave a > message. I just sent an annoyed message to my bank support, but I guess I should just forget about the official BankID client and look into this instead at the earliest opportunity. -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#518696: Progress?
Hurray!
On Sun, Mar 4, 2012 at 18:12, Ondřej Surý wrote:
> any progress on uploading to unstable? I can help/sponsor/comaintain.
> If you don't respond, I'll just pick whatever is in collab-maint,
> check it (is the conflict with moreutils solved) and upload to
> unstable?
>
> It would be nice to have GNU parallel in wheezy and we just have a
> time for that.
Indeed, I have just been packaging it for my own use (well, you can
see my name all over the repository in collab-maint) and I use it
frequently enough.
I had no hope of it being uploadable to debian proper, but I can give
it a few final touches and push a new packaging, which I'd love you to
sponsor.
If you are online, it would be good to chat a little bit and indicate
when the package is ready.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caotrxknnp6ygv9l+nvrieyndptpjq_hcfw8k9mhwfuq9xe_...@mail.gmail.com
Bug#518696: Progress?
Hi, any progress on uploading to unstable? I can help/sponsor/comaintain. If you don't respond, I'll just pick whatever is in collab-maint, check it (is the conflict with moreutils solved) and upload to unstable? It would be nice to have GNU parallel in wheezy and we just have a time for that. O. -- Ondřej Surý -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg_rfn+hwgtt4ps_4mb34v3l60zy8pdgmsn8czxtwfw...@mail.gmail.com
Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.03.2012 19:44, schrieb Mike Gabriel: > Hi Joachim, > > On So 04 Mär 2012 14:42:50 CET Joachim Falk wrote: > >>> I'd suggest to sync your Git to Alioth and continue/collaborate there. >>> Do you have an account on Alioth? If not, I'd suggest registering and >>> then apply for membership in the group ,,collab-maint''. >> Ok, I have registered as jfalk-guest and applied for the project >> pkg-tigervnc. Between, I fixed all the built errors for Xvnc. > > Downloading the xorg packaging tree for building the package does not > look like the right approach for building Xvnc to me. I'd rather think > that Xvnc can be built against the available Xorg headers on the build > system. I don't think so. I don't really download the xorg tree but the debian package for building various X11 servers (X, xnest, xdmx, xvfb, etc.). This package is already striped down to use the available system libs and headers to built the servers. The only development stuff this package provided is xserver-xorg-dev, which containts only headers. These are used to develop driver, which are loaded by the X11 server. So it should be sufficient to built the vnc.so component of tigervnc. However, I don't think that it is sufficient to built the standalone Xvnc X11 server. > I am not sure if your Git repository works the way it currently is > constructed. At least it looks like a not-so-usual packaging repos. > I am not an overall expert but what I prefer is using tools like > git-import-orig and pristine-tar. Well the tigervnc and xorg stuff are integrated as subprojects into the top project. I admit the tigervnc stuff is a svn checkout. The real question is: How do we handle patches on top of the orig sources. Either we use quilt for this then the subprojectness of xorg and tigervnc is no problem. Otherwise we drop quilt and use native git management for both tigervnc and xorg. However, in this case we have to import a fully patched version of the xorg tree. Otherwise, the xorg quilt patches would be applied over our modifications. That is a pretty unsatisfactory situation. > > To give some insight in what I mean I uploaded a point where I would > start from to my Git site: > http://code.das-netzwerkteam.de/gitweb?p=debian/tigervnc.git;a=summary > > For a better overview, please check out some other packaging projects I > am involved in: > http://code.das-netzwerkteam.de/gitweb?p=debian/x2goclient.git;a=summary > >> Now the install stage has a problem. Furthermore, we will need >> to modify the tigervnc configuration to use an external fltk if >> possible. I think, we also need to check what else tigervnc uses from >> internal sources. > > The internally shipped sources appear to be in upstream's common folder. > These source should be replacable by Debian package header files shipped > with Debian sid. > > Unfortunately, I do not have the time I would like to give to this > project, I hope for better times during the next couple of weeks. :-( > > Greetings, > Mike > > Regards, Joachim - -- Joachim Falk You can always tell a really good idea by the enemies it makes. --programmers' axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU9kBAAoJEIjUIAk+3OYM12wP/jR4uVG87p+0X3lIoiZhZmO/ 6ZCGjaP0Dr0kypulQNVyhhTkrHFYp7zlx9Pge9TXQzNHHm7MTiTuM/fSNAAc0YT2 cHVov37vttIc6sUcD1SRFIT1xeBkNmw4zoDPIaJDWrE311C3dn0GZDXpGbBMDBcD la2M7vuZxFQgLokxI4prul2vjKLjRXfCfUrpp8zudZT4Zfc5lGg2t++sUeACn8pw TvloNP3lgXc6SeSK84lD7qGDLt6GGzFysgmgh5TFs3nJ9F8t8sRMKJtIKkW8AYX0 H4KfQkWcYCWAeKzicaX2lq9B3JFEprxLBxNGX1F2pFustpA7Hx4Nh8GAv5OkE5f8 oMbWacXTmU3uWgq4R8jwhtEuE73NaiiCyA6YeTCRqNBWx5kYe7Rzgo6IUDM192Rc K6FKpYGmfpl2I1PmDLMTtLR1A3UXVkIuk29tfYm2UDSEEBFW3wPv+LNUWjr2gpVz 5DFZCXD4m8UmkR7IzNyS3El/Suz2UZV4Geaj32eCLxJrKfN2FDozVUQjSz1IiVxG BuTWSRAatS+yU+SRwm1Scoc6WNuu4WnIirCzrWcTvgFeU7nnCPnR5s/FSyFeJQ9U 6P/Q3BE6p4V1JSdMrwB+v8LKJjlUsmHMTOfr2egOWtoJSmV82AaNKSLLS40ZUgvj g5Qu6UO+sy15MBGNmmuD =9H3N -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f53d909.90...@gmx.de
Bug#647875: RFA: tuxonice-userui
On Mon, Nov 07, 2011 at 04:41:19PM +0900, Arnaud Fontaine wrote: > As I'm not using tuxonice-userui anymore and don't have so much time > to maintain it neither, I think that something else should take over > the maintainership. > > The package is currently in a quite good shape as I just uploaded a > package fixing serious bugs a few days ago. There has been no recent > upstream release but it's still maintained (according to the activity > from the Git repository). If someone wants to take over, then the Git > repository should be used, for now at least. The current work in progress is available at http://anonscm.debian.org/gitweb/?p=collab-maint/tuxonice-userui.git;a=summary There are some build issues in the new version and when they are fixed upstream I intend to upload it. -- WBR, wRAR signature.asc Description: Digital signature
Bug#662080: ITP: hadori -- Hardlinks identical files
On Sun, Mar 04, 2012 at 07:26:13PM +0100, Timo Weingärtner wrote: > Hallo Julian Andres, > > 2012-03-04 um 12:31:39 schriebst Du: > > But in any case, avoiding yet another tool with the same security > > issues (CVE-2011-3632) and bugs (and more bugs) as we currently > > have would be a good idea. > > > > hadori bugs: > > - Race, possible data loss: Calls unlink() before link(). If > > link() fails the data might be lost (best solution appears > > to be to link to a temporary file in the target directory > > and then rename to target name, making the replacement > > atomic) > > I copied that from ln -f, which has the same bug then. Could be. The other way is definitely safer. > > > - Error checking: Errors when opening files or reading > > files are not checked (ifstream uses the failbit and > > stuff). > > If only one of the files fails nothing bad happens. If both fail bad things > might happen, that's right. > > > Common security issue, same as CVE-2011-3632 for Fedora's hardlink: > > [Unsafe operations on changing trees] > > - If a regular file is replaced by a non-regular one before an > > open() for reading, the program reads from a non-regular file > > - A source file is replaced by one file with different owner > > or permissions after the stat() and before the link() > > - A component of the path is replaced by a symbolic link after > > the initial stat()ing and readdir()ing. An attacker may use > > that to write outside of the intented directory. > > > > (Fixed in Fedora's hardlink, and my hardlink by adding a section > > to the manual page stating that it is not safe to run the > > program on changing trees). > > I think that kind of bugs will stay until it is possible open/link by inode > number. Perhaps *at() can help at the file currently examined. Nobody said they have to be fixed. As I wrote, the "fix" was to mention it in the manpage. > > Right now I only used it for my backups which are only accessible by me (and > root). > > > Possibly hardlink only bugs: > >- Exaggeration of sizes. hardlink currently counts every > > link replaced -st_size, even is st_nlink > 1. I don't > > know what hadori does there. > > hadori does not have statistics. They should be easy to add, but I had no use > for them. > > > You can also drop your race check. The tool is unsafe on > > changing trees anyway, so you don't need to check whether > > someone else deleted the file, especially if you're then > > linking to it anyway. > > I wanted it to exit when something unexpected happens. But then there are just other cases where you don't, like opening files. And also, users will complain if you exit just because one file has a problem. They expect the program to continue with the remaining ones (at least they expected this in my audio conversion script, so I do this in hardlink as well). > > > I knew that there were problems on large trees in 2009, but got nowhere with > > a fix in Python. We still have the two passes in hardlink and thus need to > > keep all the files currently, as I did not carry the link-first mode over > > from my temporary C++ rewrite, as memory usage was not much different in my > > test case. But as my test case was just running on /, the whole thing may > > not be representative. If there are lots of duplicates, link-first can > > definitely help. > > > > The one that works exactly as as you want is most likely Fedora's hardlink. > > I've searched for other implementations and all the others do two passes when > one is obviously enough. Fedora's hardlink should do one pass only and link the first file to later files. It's fairly simple code. But nobody apart from Fedora and some other RPM distributions use it. > > > Yes. It looks readable, but also has far less features than hardlink (which > > were added to hardlink because of user requests). > > I still don't get what --maximize (and --minimize) are needed for. In my > incremental full backup scenario I get best results with keep-first. When > hardlinking only $last and $dest (see below) even --maximize can disconnect > files from older backups. That's to be expected. I don't know the reasons either. I thought they came from hardlinkpy (of which hardlink was a rewrite with the goal of increasing object-orientedness, and readability). But it seems they didn't. It turns out that this was a user request, or actually a feature of that user's fork of hardlinkpy: BEGINNE LOGBUCH UM Fri Dec 19 15:48:39 2008 Dez 19 18:54:56 Gegebenenfalls sollte man es zusammenführen, weil die Modifikation, welche ich benötige, auch den Link-Count der Dateien vergleicht und immer diejenige mit dem höheren erhält und die mit dem niedrigeren durch einen Hardlink auf die andere ersetzt. (If a non-German-speaking person wants to
Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs
Hi Joachim, On So 04 Mär 2012 14:42:50 CET Joachim Falk wrote: I'd suggest to sync your Git to Alioth and continue/collaborate there. Do you have an account on Alioth? If not, I'd suggest registering and then apply for membership in the group ,,collab-maint''. Ok, I have registered as jfalk-guest and applied for the project pkg-tigervnc. Between, I fixed all the built errors for Xvnc. I am not sure if your Git repository works the way it currently is constructed. At least it looks like a not-so-usual packaging repos. I am not an overall expert but what I prefer is using tools like git-import-orig and pristine-tar. Downloading the xorg packaging tree for building the package does not look like the right approach for building Xvnc to me. I'd rather think that Xvnc can be built against the available Xorg headers on the build system. To give some insight in what I mean I uploaded a point where I would start from to my Git site: http://code.das-netzwerkteam.de/gitweb?p=debian/tigervnc.git;a=summary For a better overview, please check out some other packaging projects I am involved in: http://code.das-netzwerkteam.de/gitweb?p=debian/x2goclient.git;a=summary Now the install stage has a problem. Furthermore, we will need to modify the tigervnc configuration to use an external fltk if possible. I think, we also need to check what else tigervnc uses from internal sources. The internally shipped sources appear to be in upstream's common folder. These source should be replacable by Debian package header files shipped with Debian sid. Unfortunately, I do not have the time I would like to give to this project, I hope for better times during the next couple of weeks. :-( Greetings, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgphmm7VB8xOD.pgp Description: Digitale PGP-Unterschrift
Bug#662080: ITP: hadori -- Hardlinks identical files
Hallo Julian Andres, 2012-03-04 um 12:31:39 schriebst Du: > But in any case, avoiding yet another tool with the same security > issues (CVE-2011-3632) and bugs (and more bugs) as we currently > have would be a good idea. > > hadori bugs: > - Race, possible data loss: Calls unlink() before link(). If > link() fails the data might be lost (best solution appears > to be to link to a temporary file in the target directory > and then rename to target name, making the replacement > atomic) I copied that from ln -f, which has the same bug then. > - Error checking: Errors when opening files or reading > files are not checked (ifstream uses the failbit and > stuff). If only one of the files fails nothing bad happens. If both fail bad things might happen, that's right. > Common security issue, same as CVE-2011-3632 for Fedora's hardlink: > [Unsafe operations on changing trees] > - If a regular file is replaced by a non-regular one before an > open() for reading, the program reads from a non-regular file > - A source file is replaced by one file with different owner > or permissions after the stat() and before the link() > - A component of the path is replaced by a symbolic link after > the initial stat()ing and readdir()ing. An attacker may use > that to write outside of the intented directory. > > (Fixed in Fedora's hardlink, and my hardlink by adding a section > to the manual page stating that it is not safe to run the > program on changing trees). I think that kind of bugs will stay until it is possible open/link by inode number. Perhaps *at() can help at the file currently examined. Right now I only used it for my backups which are only accessible by me (and root). > Possibly hardlink only bugs: >- Exaggeration of sizes. hardlink currently counts every > link replaced -st_size, even is st_nlink > 1. I don't > know what hadori does there. hadori does not have statistics. They should be easy to add, but I had no use for them. > You can also drop your race check. The tool is unsafe on > changing trees anyway, so you don't need to check whether > someone else deleted the file, especially if you're then > linking to it anyway. I wanted it to exit when something unexpected happens. > I knew that there were problems on large trees in 2009, but got nowhere with > a fix in Python. We still have the two passes in hardlink and thus need to > keep all the files currently, as I did not carry the link-first mode over > from my temporary C++ rewrite, as memory usage was not much different in my > test case. But as my test case was just running on /, the whole thing may > not be representative. If there are lots of duplicates, link-first can > definitely help. > > The one that works exactly as as you want is most likely Fedora's hardlink. I've searched for other implementations and all the others do two passes when one is obviously enough. > Yes. It looks readable, but also has far less features than hardlink (which > were added to hardlink because of user requests). I still don't get what --maximize (and --minimize) are needed for. In my incremental full backup scenario I get best results with keep-first. When hardlinking only $last and $dest (see below) even --maximize can disconnect files from older backups. > > It > > started with tree based map and multimap, now it uses the unordered_ > > (hash based) versions which made it twice as fast in a typical workload. > > That's strange. In my (not published) C++ version of hardlink, unordered > (multi) maps were only slightly faster than ordered ones. I then rewrote > the code in C to make it more readable to the common DD who does not > want to work with C++, and more portable. > > And it does not seem correct if you spend so much time in the map, at > least not without caching. And normally, you most likely do not have > the tree(s) you're hardlinking on cached. I have, because I usually run: $ rsync -aH $source $dest --link-dest $last $ hadori $last $dest Grüße Timo signature.asc Description: This is a digitally signed message part.
Processed: retitle 635065 to RFP: whatweb -- Next generation web scanner
Processing commands for cont...@bugs.debian.org: > retitle 635065 RFP: whatweb -- Next generation web scanner Bug #635065 [wnpp] ITP: whatweb -- Next generation web scanner Changed Bug title to 'RFP: whatweb -- Next generation web scanner' from 'ITP: whatweb -- Next generation web scanner' > thanks Stopping processing here. Please contact me if you need assistance. -- 635065: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635065 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133088501011957.transcr...@bugs.debian.org
Bug#662205: ITP: cyclograph -- CycloGraph plots the altimetry of your route
Package: wnpp Severity: wishlist Owner: Federico Brega * Package name: cyclograph Version : 1.5.0 Upstream Author : Federico Brega * URL : http://cyclograph.sourceforge.net/ * License : GPL v3 Programming Lang: Python Description : CycloGraph plots the altimetry of your route CycloGraph is a program useful for cyclists (but not only for them). It shows a graphical rapresentation of the route. You can manually provide data on the route you want to visualize (distance, altitude) or import from files produced from commercial or closed software witch does a similar task. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120304172125.23370.14477.reportbug@mercurius
Processed: retitle 662138 to ITP: mysql-utilities -- MySQL Utilities - command-line interface to MySQL
Processing commands for cont...@bugs.debian.org: > retitle 662138 ITP: mysql-utilities -- MySQL Utilities - command-line > interface to MySQL Bug #662138 [wnpp] RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL Changed Bug title to 'ITP: mysql-utilities -- MySQL Utilities - command-line interface to MySQL' from 'RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL' > thanks Stopping processing here. Please contact me if you need assistance. -- 662138: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662138 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133087642827480.transcr...@bugs.debian.org
Bug#662175: ITP: basilisk-ii-cvs -- Basilisk II (jit). Motorola 680x0 based Mac emulator
Hi Giulio, On 12-03-04 at 03:52pm, Giulio Paci wrote: > Package: wnpp > Severity: wishlist > Owner: Giulio Paci > > * Package name: basilisk-ii-cvs > Version : Unreleased CVS tree snapshot > Upstream Author : Christian Bauer > * URL : http://basilisk.cebix.net/ > * License : (GPL) > Programming Lang: (C++) > Description : Basilisk II (jit). Motorola 680x0 based Mac emulator Basilisk II have been in the archive already in the past: http://packages.qa.debian.org/b/basilisk2.html The packaging git is still around: http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git I'd be happy to help you maintain it, if you are interested in team-maintainance. Jérémy Lal (cc'ed) also showed some interest in the past and might also be interested. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sun, Mar 04, 2012 at 01:33:14PM +0100, intrigeri wrote: > > I named it opensync0 since that plugin depends on libopensync0, which > > is available in Squeeze. > > libopensync0 was a binary library package built from the opensync > source package. Using ABI numbers in such a binary package name is > recommended. But I don't see any reason to use ABI numbers in the name > of this *source* package, unless you really expect to maintain > multiple opensyncN-plugin-barry *source* packages concurrently in > Debian, which can be done, but generally needs to be backed with > solid arguments. I already do maintain two separate opensync plugin source trees. They are both included in Barry, under the opensync-plugin and opensync-plugin-0.4x directories. The opensync API changed significantly between 0.2x and 0.3x, hence the need for two plugin sources. > > The opensync-plugin-4x plugin depends on libopensync1 which is not > > yet officially released, but does work. That plugin is named > > opensync1-plugin > > I can't find any such package in Debian. The 0.3x version of opensync was called libopensync1exp7 in Debian, but may have been removed by now. In my own binary packaging for 0.3x I moved to calling the binary package libopensync1, since that matched the pkgconfig name to some degree. > > In order to use both 0.22 opensync and 0.4x on the same system, the > > specific naming was needed. > > Can these two versions of opensync be installed concurrently on > a Debian testing/sid system? Yes. I'd have to double check the -dev packages, but I worked specifically to make it possible to install both at the same time. > > The opensync subdirectories do not get built automatically. > > Do you confirm you mean that the opensync-plugin/ and > opensync-plugin/debian are part of the orig.tar.gz, shipped in the > source package, but not used to build any binary package? Yes. There are opensync-plugin/debian and opensync-plugin-0.4x/debian that are both built separately, or as make targets from the root debian/rules file. The main subprojects (the plugins, the gui/, and the desktop/ directories) have their own configure scripts and can be used standalone if desired, although they all depend on the Barry library. > >> I find it misleading to write "barry (0.18.0-1) unstable" in > >> debian/changelog right now; I think it should only be done at the last > >> minute, once the package is really ready to be uploaded to Debian > >> unstable, which is not presently the case. Until this point is > >> reached, I find it saner to: > >> > >> * either keep UNRELEASED instead of unstable > >> * or manually manage lower-than-release but increasing version > >> numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) > >> * or use git-dch to get automated lower-than-release but increasing > >> version numbers > > > I'm not sure how this is misleading, since if it doesn't exist in > > Debian, then Debian shouldn't care. > > I, as the one who's spending time to review your packaging, and > offered to sponsor your packages, do care. I find it useful to be able > to infer, from a given package version number (be it a source or > binary package built from your Git repository, or installed on my > system), if it was a package that was uploaded to Debian or a random > development snapshot. With the versionning scheme you're currently > using, how can we distinguish between a package built from your > current Git repository, and the package (with version 0.18.0-1 as > well) that will hopefully get uploaded into Debian once all this stuff > is sorted out? I misunderstood who you were referring to. I can see how you would care, and it's not my intention to make it confusing. But once 0.18.0-1 is uploaded to Debian, my git repo should not say 0.18.0-1 anymore. My git repo contains the version number of the next release, so I can use it in the same state that it will be released in, and fix issues that arise. As soon as the release is made, the version gets bumped again. I would assume that if I'm doing the maintainer work, I'd have some say over when an upload happens, and could therefore update the version numbers appropriately. > > The Desktop GUI currently requires either libopensync0 or libopensync1, > > or both, and is fairly useless without the plugins to go along with it. > > It is tricky to compile the Desktop for both. > > Just to confirm I've understood what you mean, do you mean the desktop > GUI binary package should depend on libopensync1exp7, and the source > package should build-depend on whatever opensync -dev package? Well, libopensync1exp7 should not be used at all. It is too old. The latest opensync 0.3x devel tree in git should be used instead, if we're going the devel tree route. To clarify, the Desktop GUI which is found in Barry is designed to use either opensync 0.2x or 0.3x, or both. It uses dlopen to load the library manually, so technically opensync can be uninstalled completely a
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (04 Mar 2012 13:59:49 GMT) : >> I, as the one who's spending time to review your packaging, and >> offered to sponsor your packages, do care. I find it useful to be >> able to infer, from a given package version number (be it a source >> or binary package built from your Git repository, or installed on >> my system), if it was a package that was uploaded to Debian or >> a random development snapshot. With the versionning scheme you're >> currently using, how can we distinguish between a package built >> from your current Git repository, and the package (with version >> 0.18.0-1 as well) that will hopefully get uploaded into Debian once >> all this stuff is sorted out? > I misunderstood who you were referring to. I can see how you would care, > and it's not my intention to make it confusing. > But once 0.18.0-1 is uploaded to Debian, my git repo should not say > 0.18.0-1 anymore. My git repo contains the version number of the next > release, so I can use it in the same state that it will be released in, > and fix issues that arise. As soon as the release is made, the version > gets bumped again. This does not answer the "how can we distinguish..." problem, and will therefore make things harder for reviewers and sponsors, who will lack any kind of version numbering to distinguish between package snapshots you show them, but well, in the end you decide. > I would assume that if I'm doing the maintainer work, I'd have some > say over when an upload happens, and could therefore update the > version numbers appropriately. Sure. *You* prepare the packages, so *you* decide when it should get uploaded :) > To clarify, the Desktop GUI which is found in Barry is designed to > use either opensync 0.2x or 0.3x, or both. It uses dlopen to load > the library manually, so technically opensync can be uninstalled > completely and the Desktop will still run, just not sync. But in > order to build, you need the headers, etc. This is a ./configure > compile issue, and I haven't made it work The Debian Way(TM) yet. > It only works in my binary-meta system. > But since opensync 0.3x probably won't exist in Debian for now, you > only need libopensync0-dev to build the Desktop. Ok. Fixing this FTBFS is top-priority as far as Debian is concerned. If it ain't buildin', then we can't ship it. > Barry is much like the linux kernel source tree: everything is > included, almost like modules, and everything gets built during > development, in order to keep all code in lock step. This is done on > purpose, in order to encourage developers to build and test the > whole thing. But the subprojects are separate enough that they can > be extracted if necessary. Thanks for clarifying. > So while Barry won't be splitting up, a script could be added to create > separate tarballs for you, if that makes it easier. Personally, I won't have any use for such tarballs. As long as you throw sane source packages at me, I'm happy. Sorry if I've been unclear, I'm not pushing towards artificially splitting. I don't think such source package splitting should be decided merely as a way to answer the initial question, that is "how do you make packages build optionally". There are many other much more valid reasons to split, or not to split. At some point, *you* have to make a decision about which ones of these subprojects need to get its own source package, or not. You answered "yes" in practice to this question for the opensync plugin. Fine with me. But please, don't artificially move $APP into a dedicated source package only to make its build optional right now. I understand this is a cheap short-term solution, but splitting has serious long-term costs, such as making it harder to upgrade the splitted bits in lock step later. Maybe just create a branch dedicated for Debian, that removes these package from debian/control, and that's all? > I have no guarantee that Barry (let alone opensync) will make it > into Debian. So I really hesitate ripping up Barry's existing, and > working, packaging for Debian, when I'll need it to release binary > packages soon anyway. Fair enough. Barry making it into Debian or not now mostly depends on you, though :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85obsc1k2g@boum.org
Bug#602842: marked as done (ITP: condor -- high throughput computing job scheduling)
Your message dated Sun, 04 Mar 2012 15:02:33 + with message-id and subject line Bug#233482: fixed in condor 7.7.4+git3-gd7ce75b~dfsg.1-1 has caused the Debian Bug report #233482, regarding ITP: condor -- high throughput computing job scheduling to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 233482: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=233482 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: condor Version : 7.4.4 Upstream Author : Condor Team, Computer Sciences Department, University of Wisconsin-Madison URL : http://www.cs.wisc.edu/condor * License : Apache License, Version 2 Programming Lang: C++, Java Description : workload management system Description --- [from webpage] Condor is a specialized workload management system for compute-intensive jobs. Like other full-featured batch systems, Condor provides a job queueing mechanism, scheduling policy, priority scheme, resource monitoring, and resource management. Users submit their serial or parallel jobs to Condor, Condor places them into a queue, chooses when and where to run the jobs based upon a policy, carefully monitors their progress, and ultimately informs the user upon completion. While providing functionality similar to that of a more traditional batch queueing system, Condor's novel architecture allows it to succeed in areas where traditional scheduling systems fail. Condor can be used to manage a cluster of dedicated compute nodes (such as a "Beowulf" cluster). In addition, unique mechanisms enable Condor to effectively harness wasted CPU power from otherwise idle desktop workstations. For instance, Condor can be configured to only use desktop machines where the keyboard and mouse are idle. Should Condor detect that a machine is no longer available (such as a key press detected), in many circumstances Condor is able to transparently produce a checkpoint and migrate a job to a different machine which would otherwise be idle. Condor does not require a shared file system across machines - if no shared file system is available, Condor can transfer the job's data files on behalf of the user, or Condor may be able to transparently redirect all the job's I/O requests back to the submit machine. As a result, Condor can be used to seamlessly combine all of an organization's computational power into one resource. Plan At the batch queueing systems BoF at DebConf10 this software has been discussed as a potential addition to Debian. I plan to start tracking the 'stable' series -- maybe adding a dedicated package for the 'development' series sometime in the future (if there is enough manpower). Upstream already has some Debian packages, but uses external software that is downloaded and built from source instead of exclusively relying on Debian packages. I want to start from upstream packaging and improve integration into the Debian system. If you are interested in co-maintaining this package, please drop me a note. --- End Message --- --- Begin Message --- Source: condor Source-Version: 7.7.4+git3-gd7ce75b~dfsg.1-1 We believe that the bug you reported is fixed in the latest version of condor, which is due to be installed in the Debian FTP archive: condor-dbg_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb to main/c/condor/condor-dbg_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb condor-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb to main/c/condor/condor-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb condor-doc_7.7.4+git3-gd7ce75b~dfsg.1-1_all.deb to main/c/condor/condor-doc_7.7.4+git3-gd7ce75b~dfsg.1-1_all.deb condor_7.7.4+git3-gd7ce75b~dfsg.1-1.debian.tar.gz to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1-1.debian.tar.gz condor_7.7.4+git3-gd7ce75b~dfsg.1-1.dsc to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1-1.dsc condor_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb condor_7.7.4+git3-gd7ce75b~dfsg.1.orig.tar.gz to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1.orig.tar.gz libclassad-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb to main/c/condor/libclassad-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb libclassad2_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb to main/c/condor/libclassad2_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 233.
Bug#233482: marked as done (ITP: condor -- high throughput computing job scheduling)
Your message dated Sun, 04 Mar 2012 15:02:33 +
with message-id
and subject line Bug#233482: fixed in condor 7.7.4+git3-gd7ce75b~dfsg.1-1
has caused the Debian Bug report #233482,
regarding ITP: condor -- high throughput computing job scheduling
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
233482: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=233482
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: RFP
http://www.cs.wisc.edu/condor/
will become OpenSource soon (RPMs already available)
--
Steffen Grunewald * * * Merlin cluster admin (http://pandora.aei.mpg.de)
Albert-Einstein-Institut (MPI Gravitationsphysik, http://www.aei.mpg.de)
Science Park Golm, Am Mühlenberg 1, 14476 Potsdam, Germany
e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
--- End Message ---
--- Begin Message ---
Source: condor
Source-Version: 7.7.4+git3-gd7ce75b~dfsg.1-1
We believe that the bug you reported is fixed in the latest version of
condor, which is due to be installed in the Debian FTP archive:
condor-dbg_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
to main/c/condor/condor-dbg_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
condor-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
to main/c/condor/condor-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
condor-doc_7.7.4+git3-gd7ce75b~dfsg.1-1_all.deb
to main/c/condor/condor-doc_7.7.4+git3-gd7ce75b~dfsg.1-1_all.deb
condor_7.7.4+git3-gd7ce75b~dfsg.1-1.debian.tar.gz
to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1-1.debian.tar.gz
condor_7.7.4+git3-gd7ce75b~dfsg.1-1.dsc
to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1-1.dsc
condor_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
condor_7.7.4+git3-gd7ce75b~dfsg.1.orig.tar.gz
to main/c/condor/condor_7.7.4+git3-gd7ce75b~dfsg.1.orig.tar.gz
libclassad-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
to main/c/condor/libclassad-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
libclassad2_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
to main/c/condor/libclassad2_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 233...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Hanke (supplier of updated condor package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 24 Feb 2012 08:37:32 +0100
Source: condor
Binary: condor condor-dev condor-doc condor-dbg libclassad-dev libclassad2
Architecture: source i386 all
Version: 7.7.4+git3-gd7ce75b~dfsg.1-1
Distribution: experimental
Urgency: low
Maintainer: Michael Hanke
Changed-By: Michael Hanke
Description:
condor - workload management system
condor-dbg - debugging symbols for Condor
condor-dev - development files for Condor
condor-doc - documentation for Condor
libclassad-dev - library for Condor's classads expression language
(development)
libclassad2 - library for Condor's classads expression language
Closes: 233482
Changes:
condor (7.7.4+git3-gd7ce75b~dfsg.1-1) experimental; urgency=low
.
* Initial upload to Debian experimental (Closes: #233482).
After acceptance into Debian an upload to unstable is expected to happen
once a build-time test suite is operational.
* Drop NeuroDebian team as maintainer, upstream will eventually become the
primary maintainer, with Michael Hanke being the uploader for the time
being.
* Merge commits from 7.7.4 maintenance branch.
* Enable GSOAP support.
Checksums-Sha1:
ed2932070cf5a23a248c39593e38ca6fe3c318f8 2538
condor_7.7.4+git3-gd7ce75b~dfsg.1-1.dsc
915ea21bff1fc5a52a87cd5f597d667774df91f0 8276101
condor_7.7.4+git3-gd7ce75b~dfsg.1.orig.tar.gz
006e3feccf8e97ada1ad7e8bdc972b2e9ec68a32 56286
condor_7.7.4+git3-gd7ce75b~dfsg.1-1.debian.tar.gz
eacf5799780f72c69516ec628aa8d6c557c51991 4354690
condor_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
55910a84c39abc4bb06a69769f28baeaba8c7b61 386470
condor-dev_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
8dfa37d498e03ee10dcee3ff98b7274777f1ca93 1337222
condor-doc_7.7.4+git3-gd7ce75b~dfsg.1-1_all.deb
211f61ec50be1ead94a2b735dce9f5931042e386 11728748
condor-dbg_7.7.4+git3-gd7ce75b~dfsg.1-1_i386.deb
33dcdc8bf96f73e1677c
Bug#662175: ITP: basilisk-ii-cvs -- Basilisk II (jit). Motorola 680x0 based Mac emulator
Package: wnpp Severity: wishlist Owner: Giulio Paci * Package name: basilisk-ii-cvs Version : Unreleased CVS tree snapshot Upstream Author : Christian Bauer * URL : http://basilisk.cebix.net/ * License : (GPL) Programming Lang: (C++) Description : Basilisk II (jit). Motorola 680x0 based Mac emulator -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120304145238.12417.28028.reportbug@geppetto
Bug#662168: RFP: automx -- A mail user agent auto configuration service
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: automx Version : 0.8_beta1 Upstream Author : state of mind * URL : http://automx.org/ * License : GPLv3 Programming Lang: Python Description : A mail user agent auto configuration service [Upstream long description] automx makes setting up a mail account easy. All your users need to provide is real name, mail address and password. Their mail client and automx will safely handle the rest. automx runs on your server and handles mail account profile requests from your mail clients. Put an end to endless phone calls trying to coach users to configure settings, whose dialogs they can't find. Stop waisting your time writing Tutorials nobody reads. automx unifies Microsofts and Mozillas mail account provisioning standards in one powerful Open Source tool. Choose from many backends, including LDAP and SQL, and let automx create standard and individualized profiles for multiple domains on the fly! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9TjX8ACgkQbO4uEp7kOBMUTgCdHR/3O5ppgJr3JFLFuyQM2h59 3HQAoKEolfhJLRh1Rho5W6CTUiYiydTE =X8qv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120304154301.4583.1753.reportbug@blackhost
Processed: owner 662138
Processing commands for cont...@bugs.debian.org: > owner 662138 ! Bug #662138 [wnpp] RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL Owner recorded as Dmitry Smirnov . > thanks Stopping processing here. Please contact me if you need assistance. -- 662138: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662138 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133087123429792.transcr...@bugs.debian.org
Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.02.2012 15:01, schrieb Mike Gabriel: > Hi Joachim, > > On Mo 27 Feb 2012 23:30:51 CET Joachim Falk wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Am 23.02.2012 20:00, schrieb Joachim Falk: >>> Am 23.02.2012 13:04, schrieb Mike Gabriel: Hi Joachim, >>> On Do 23 Feb 2012 11:47:45 CET Joachim Falk wrote: >>> > Hmm. Wait a bit. At the moment I am at work. Maybe this evening I have > time to update my package to tigervnc 1.1.90. I already began > yeasterday > with this. And you are right there is now only cmake. I have begun > to integrate the xorg server and the tigervnc sources into their own > subdirs as git projects and svn checkouts. The quilt problem runs much > deeper. Quilt for the toplevel project is no problem I think. However, > the xorg tree has its own quilt files which have to be applied too. >>> Hang on. I would love to prepare the package via Git on git.debian.org. I am about to commit (at the weekend, probably) a version that is based on 1.1.90 and uses quilt and cmake via cdbs. >>> Do you have an account on Alioth? I really want to recommend package development under Git. >> Did you create your version on Alioth? >> >>> Well git is a distributed version control system ;) >>> >>> git clone http://xiao.jfalk.de/~joachim/tigervnc/tigervnc.git >> Mine is as denoted above. It is still not fully functional. But >> the patch system is finalized. Some patches from my tigervnc 1.1.0 deb >> are already applied. The tigervnc and xorg tree integration is mostly >> finished. I still seem to have a problem with the generation of the >> automake/autoconf build files for the xorg tree. >> > > I'd suggest to sync your Git to Alioth and continue/collaborate there. > Do you have an account on Alioth? If not, I'd suggest registering and > then apply for membership in the group ,,collab-maint''. Ok, I have registered as jfalk-guest and applied for the project pkg-tigervnc. Between, I fixed all the built errors for Xvnc. Now the install stage has a problem. Furthermore, we will need to modify the tigervnc configuration to use an external fltk if possible. I think, we also need to check what else tigervnc uses from internal sources. > > Thanks+Greets, > Mike Regards, Joachim - -- Joachim Falk You can always tell a really good idea by the enemies it makes. --programmers' axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU3FRAAoJEIjUIAk+3OYMH00QAI9F7bgRdt5vz0qdHTpw362j Qg3qoL25dHQZiJQb7vqWRiRrq4dYFp5xpBSl+Ty+/LbW5xthqPqhXE9zkbvVL1SZ Vw1Jr/nRmODUDmxzpfXvWt3mh4pX+kKGvIJU3h1vQRO7hET2PC7oq/geyRgolnj9 dhAhB1xjWtvV9fzE/PnySHhhY3hvtdOnYKSL4BNNQL49r/bc7shcXQ51zs1cRxLC V0QsN6PvImImokv/oE7BA+e0YFfmWFFHAJhno3PEm9xgx5GZRizxlgP44xhOAMuB pLui5xUWWIme66ogK0xxG1qzDRp2nK4+zGnSaufacJABGI55p73YgyjfGzM72NZE uUTLI1vrdiPRX++/BHnnIS/pNpx8bTSfjWYWyHS/+L64kUP1BMFm/zfwbhy0VTTq 6E42GTex21DttQQS5Ncr/ZCXSOam/VOwe6V21uN2CfF2alDMlPjps8H3zwCMtnZ/ /1NPH+BkMYUWAaaTuE8Hs4/txCpGHAuAc78enLrKPopwPAGB4R1ls6FyBk3MwDCa UuG4aj1ad9R8EKLnbPiCo4Zcz5584iPwsQqub2VBOBoHwAuXImt2clCg5sbrOte8 G6IjTRmkPVgbtW/45s2qxB2V7hG5OEcr4f5715Te6ESJYFmDvNJnUcRBdOMFiUbo gX3MI4DFt+26ISFg2hXJ =+FQK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f53715a.2020...@gmx.de
Bug#648645: marked as done (O: genesis -- general-purpose neural simulator)
Your message dated Sun, 04 Mar 2012 13:10:26 + with message-id and subject line Bug#662143: Removed package(s) from unstable has caused the Debian Bug report #648645, regarding O: genesis -- general-purpose neural simulator to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 648645: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648645 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: genesis Severity: important Hi, There are several RC bugs filed against genesis and none of them appear to have gotten any maintainer reaction for months. If you need help solving the issues, please tag the bugs help or/and request assistances on debian-de...@lists.debian.org. Alternatively, open an RFH bug against wnpp. If you are still active and interested in this package, please reply to this bug within 14 days. Otherwise I will assume you have lost interest in this package and orphan this package. ~Niels --- End Message --- --- Begin Message --- Version: 2.2.1-12+rm Dear submitter, as the package genesis has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see http://bugs.debian.org/662143 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org. Debian distribution maintenance software pp. Joerg Jaspert (the ftpmaster behind the curtain) --- End Message ---
Processed: RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL
Processing commands for cont...@bugs.debian.org: > retitle 662138 RFS: mysql-utilities -- MySQL Utilities - command-line > interface to MySQL Bug #662138 [wnpp] ITP: mysql-utilities -- MySQL Utilities - command-line interface to MySQL Changed Bug title to 'RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL' from 'ITP: mysql-utilities -- MySQL Utilities - command-line interface to MySQL' > -- Stopping processing here. Please contact me if you need assistance. -- 662138: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662138 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133086601426505.transcr...@bugs.debian.org
Bug#662138: RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL
retitle 662138 RFS: mysql-utilities -- MySQL Utilities - command-line interface to MySQL -- Source package is available from http://mentors.debian.net/debian/pool/main/m/mysql-utilities/mysql-utilities_1.0.4-1.dsc -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203042359.54503.only...@member.fsf.org
Processed: your mail
Processing commands for cont...@bugs.debian.org: > owner 660445 ! Bug #660445 [wnpp] O: libmicrohttpd -- library embedding HTTP server functionality Owner recorded as beberk...@gmail.com. > retitle 660445 ITA: libmicrohttpd -- library embedding HTTP server > functionality Bug #660445 [wnpp] O: libmicrohttpd -- library embedding HTTP server functionality Changed Bug title to 'ITA: libmicrohttpd -- library embedding HTTP server functionality' from 'O: libmicrohttpd -- library embedding HTTP server functionality' > owner 660438 ! Bug #660438 [wnpp] O: gnunet -- secure, trust-based peer-to-peer framework Owner recorded as beberk...@gmail.com. > retitle 660438 ITA: gnunet -- secure, trust-based peer-to-peer framework Bug #660438 [wnpp] O: gnunet -- secure, trust-based peer-to-peer framework Changed Bug title to 'ITA: gnunet -- secure, trust-based peer-to-peer framework' from 'O: gnunet -- secure, trust-based peer-to-peer framework' > thanks Stopping processing here. Please contact me if you need assistance. -- 660438: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660438 660445: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660445 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133086569925356.transcr...@bugs.debian.org
Processed: block 604174 with 662138
Processing commands for cont...@bugs.debian.org: > block 604174 with 662138 Bug #604174 [wnpp] ITP: mysql-workbench -- a visual database modeling, administration and queuing tool Was blocked by: 662138 Ignoring request to alter blocking bugs of bug #604174 to the same blocks previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 604174: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604174 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133086569925354.transcr...@bugs.debian.org
Processed: Re: RFP: faenza-icon-theme -- Faenza Icon Theme
Processing commands for cont...@bugs.debian.org: > close 662059 Bug#662059: RFP: faenza-icon-theme -- Faenza Icon Theme 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to nodiscc > thanks Stopping processing here. Please contact me if you need assistance. -- 662059: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662059 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133086562225038.transcr...@bugs.debian.org
Bug#662059: RFP: faenza-icon-theme -- Faenza Icon Theme
close 662059 thanks Hi, There is an ITP for this icon theme, please take a look here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595106, therefore I close your RFP. Cheers, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f53745c.2010...@free.fr
Processed: block 604174 with 662138
Processing commands for cont...@bugs.debian.org: > block 604174 with 662138 Bug #604174 [wnpp] ITP: mysql-workbench -- a visual database modeling, administration and queuing tool Was not blocked by any bugs. Added blocking bug(s) of 604174: 662138 > thanks Stopping processing here. Please contact me if you need assistance. -- 604174: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604174 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133086549224615.transcr...@bugs.debian.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi, Chris Frey wrote (03 Mar 2012 14:50:14 GMT) : > Stable is what I had handy. I realize this is a work in progress. I suggest you use a pbuilder sid chroot to build packages that are supposed to be uploaded into sid at some point. > There's a large body of work on the opensync side that is not yet > visible to anyone in Debian. Maybe I can get that into Debian as > well, but I doubt it will make the Wheezy deadline. Yeah, see the recent announce on debian-devel (today or yesterday) about the current poor state of opensync in Debian. Not reassuring. >> > I've also fixed some lintian errors. The following warnings remain: >> >> W: opensync0-plugin-barry: new-package-should-close-itp-bug >> > This can be ignored, I think. >> >> Putting two source packages into the same Git repository will be >> a pain. Let's talk about this other, new source package >> (opensync0-plugin-barry) later, and keep focused on the barry one to >> start with. By the way, I think the source package would be better >> called opensync-plugin-barry; and if it really needs to be a separate >> source package, Lintian is right, you need to fill an ITP for >> opensync-plugin-barry, and close it in its debian/changelog. > I named it opensync0 since that plugin depends on libopensync0, which > is available in Squeeze. libopensync0 was a binary library package built from the opensync source package. Using ABI numbers in such a binary package name is recommended. But I don't see any reason to use ABI numbers in the name of this *source* package, unless you really expect to maintain multiple opensyncN-plugin-barry *source* packages concurrently in Debian, which can be done, but generally needs to be backed with solid arguments. Anyway, the dependency on a package that is not part of Debian testing/unstable makes this plugin not suitable, as is, for Debian. Let's postpone the opensync part for now. > The opensync-plugin-4x plugin depends on libopensync1 which is not > yet officially released, but does work. That plugin is named > opensync1-plugin I can't find any such package in Debian. > In order to use both 0.22 opensync and 0.4x on the same system, the > specific naming was needed. Can these two versions of opensync be installed concurrently on a Debian testing/sid system? > But the entire opensync side of things can be postponed for now, > at least where Debian is concerned. Ok. > The opensync subdirectories do not get built automatically. Do you confirm you mean that the opensync-plugin/ and opensync-plugin/debian are part of the orig.tar.gz, shipped in the source package, but not used to build any binary package? >> I find it misleading to write "barry (0.18.0-1) unstable" in >> debian/changelog right now; I think it should only be done at the last >> minute, once the package is really ready to be uploaded to Debian >> unstable, which is not presently the case. Until this point is >> reached, I find it saner to: >> >> * either keep UNRELEASED instead of unstable >> * or manually manage lower-than-release but increasing version >> numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.) >> * or use git-dch to get automated lower-than-release but increasing >> version numbers > I'm not sure how this is misleading, since if it doesn't exist in > Debian, then Debian shouldn't care. I, as the one who's spending time to review your packaging, and offered to sponsor your packages, do care. I find it useful to be able to infer, from a given package version number (be it a source or binary package built from your Git repository, or installed on my system), if it was a package that was uploaded to Debian or a random development snapshot. With the versionning scheme you're currently using, how can we distinguish between a package built from your current Git repository, and the package (with version 0.18.0-1 as well) that will hopefully get uploaded into Debian once all this stuff is sorted out? > If git-dch can completely eliminate editing the changelog file, > though, that might be worth looking into. It does not completely eliminate, but it avoids many of the usual pitfalls beginners at Debian packaging often fall in. >> Building in a sid chroot fails for me: [...] >> => missing build-deps? You need to make sure your package actually builds properly in a clean sid pbuilder chroot. Seriously, this is a prerequisite for any further review of mine. > The Desktop GUI currently requires either libopensync0 or libopensync1, > or both, and is fairly useless without the plugins to go along with it. > It is tricky to compile the Desktop for both. Just to confirm I've understood what you mean, do you mean the desktop GUI binary package should depend on libopensync1exp7, and the source package should build-depend on whatever opensync -dev package? > Without opensync plugins, though, we should leave the Desktop out of > Debian for now. Is there an easy way to make packages optional? I'm not sure what you mean by "optional".
Bug#662138: ITP: mysql-utilities -- MySQL Utilities - command-line interface to MySQL
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: mysql-utilities Version: 1.0.4 Upstream Author: Oracle and/or its affiliates URL: https://launchpad.net/mysql-utilities License: GPL-2 Description: MySQL Utilities -- command-line interface to MySQL MySQL Utilities is both a set of command-line utilities as well as a Python library for making the common tasks easy to accomplish. The library is written entirely in Python, meaning that it is not necessary to have any other tools or libraries installed to make it work. . MySQL Utilities is a set of easy-to-use scripts intended to make working with servers easier. It is part of the MySQL Workbench. This is an unbundled component of MySQL Workbench. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203042341.15594.only...@member.fsf.org
Bug#651724: marked as done (ITA: pdfcube -- PDF document viewer with 3D effects)
Your message dated Sun, 04 Mar 2012 12:16:01 +
with message-id
and subject line Bug#651724: fixed in pdfcube 0.0.4-1
has caused the Debian Bug report #651724,
regarding ITA: pdfcube -- PDF document viewer with 3D effects
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
651724: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651724
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: pdfcube
Version: 0.0.2-3
On 12/11/2011 04:43 PM, Alexander Wirt wrote:
> A long time there wasn't any activity in pdfcube itself. (0.0.3 didn't had
> any relevant features. It just broke several things). But feel free to take
> over :).
Ok, I will do that. Thank you! (BCC'ed sub...@bugs.debian.org)
Cheers, Andreas
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: pdfcube
Source-Version: 0.0.4-1
We believe that the bug you reported is fixed in the latest version of
pdfcube, which is due to be installed in the Debian FTP archive:
pdfcube_0.0.4-1.diff.gz
to main/p/pdfcube/pdfcube_0.0.4-1.diff.gz
pdfcube_0.0.4-1.dsc
to main/p/pdfcube/pdfcube_0.0.4-1.dsc
pdfcube_0.0.4-1_amd64.deb
to main/p/pdfcube/pdfcube_0.0.4-1_amd64.deb
pdfcube_0.0.4.orig.tar.gz
to main/p/pdfcube/pdfcube_0.0.4.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 651...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Moog (supplier of updated pdfcube package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 Dec 2011 10:19:12 +0100
Source: pdfcube
Binary: pdfcube
Architecture: source amd64
Version: 0.0.4-1
Distribution: unstable
Urgency: low
Maintainer: Andreas Moog
Changed-By: Andreas Moog
Description:
pdfcube- PDF document viewer with 3D effects
Closes: 425263 464830 507880 615438 651724 659531
Changes:
pdfcube (0.0.4-1) unstable; urgency=low
.
* New Maintainer (Closes: #651724)
* New upstream release:
- builds with libpoppler 0.18
- include manpage (Closes: #464830)
- handle command line options (Closes: #507880)
* debian/{compat,control,rules}:
- use dh sequencer
- bump debhelper compat level to 9
- export buildflags from dpkg-buildflags
- override dh_installman cause upstream doesn't install it
* debian/control:
- wrap and sort build-depends
- drop freeglut3-dev build-depends, not needed anymore
- drop libpoppler-dev build-depends, pdfcube only needs poppler-glib
Thanks Pino Toscano (Closes: #659531)
- add libboost-dev and libboost-program-options-dev build-depends
- fix spelling in description (Closes: #425263)
Thanks Peter Eisentraut
- add Vcs-Git and Vcs-Browser fields
- move homepage to Homepage field (Closes: #615438)
- bump standards version to 3.9.3
* debian/copyright:
- convert to DEP5 copyright format
* debian/dirs:
- removed, it's not needed
* debian/docs:
- don't install empty NEWS file
* debian/pdfcube.1[.txt]:
- removed, included upstream
* debian/rules:
- allow parallel building
* debian/watch - added
Checksums-Sha1:
3423b14aa484ebe84ded98c609edfef638397466 1279 pdfcube_0.0.4-1.dsc
801f1e277180e7a0a212742bb5c6e3272310aaac 113009 pdfcube_0.0.4.orig.tar.gz
4cffd3575ea408086479770860a8b5cfee7543c7 2096 pdfcube_0.0.4-1.diff.gz
2626fd96ed4b1b3f8a0679b77291e19d83145d39 39904 pdfcube_0.0.4-1_amd64.deb
Checksums-Sha256:
6cd4ff0e5e937f92026d2453979fb80c7b7d7d96c6d0bfe7fce547fb3cddf424 1279
pdfcube_0.0.4-1.dsc
f137d5a3bd05cb4d954e9e9885eb216e256625ca44e7bd2d7fd8243ea6b3aeb6 113009
pdfcube_0.0.4.orig.tar.gz
04837c66ee12af4376b2144e87bbfe54eaceece60fd4ae6b0b3b8505e467f845 2096
pdfcube_0.0.4-1.diff.gz
9e392fabb27725d41619062204cea3f4030f3fa9e0700f04bc33c4e963b69330 39904
pdfcube_0.0.4-1_amd64.deb
Files:
aa71c9fb2264c62b5127f808de1533c6 1279 text optional pdfcube_0.0.4-1.dsc
5eb9d11f4e9d1e0bc00d729b4387d30d 113009 text optional pdfcube_0.0.4.orig.tar.gz
a7d925c7d099669899340a5cb9759288 2096 text optional pdfcube_0.0.4-1.diff.gz
30e376cc7ef25d54f48723b987c528c3 39904 text optional pdfcube_0.0.4-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: Gnu
Bug#662080: ITP: hadori -- Hardlinks identical files
On Sun, Mar 04, 2012 at 07:00:13AM +0100, Goswin von Brederlow wrote: > Timo Weingärtner writes: > > > Package: wnpp > > Severity: wishlist > > X-Debbugs-CC: debian-de...@lists.debian.org > > > >Package name: hadori > > Version: 0.2 > > Upstream Author: Timo Weingärtner > > URL: https://github.com/tiwe-de/hadori > > License: GPL3+ > > Description: Hardlinks identical files > > This might look like yet another hardlinking tool, but it is the only one > > which only memorizes one filename per inode. That results in less merory > > consumption and faster execution compared to its alternatives. Therefore > > (and because all the other names are already taken) it's called > > "HArdlinking DOne RIght". > > . > > Advantages over other hardlinking tools: > > * predictability: arguments are scanned in order, each first version is > > kept > > * much lower CPU and memory consumption > > * hashing option: speedup on many equal-sized, mostly identical files > > > > The initial comparison was with hardlink, which got OOM killed with a > > hundred > > backups of my home directory. Last night I compared it to duff and rdfind > > which would have happily linked files with different st_mtime and st_mode. > > > > I need a sponsor. I'll upload it to mentors.d.n as soon as I get the bug > > number. > > > > > > Greetings > > Timo > > I've been thinking about the problem of memory consumption too. But I've > come to a different solution. One that doesn't need memory at all. I know yet another solution. For each file you visit, you simply visit the complete tree. Than you have n + 1 visits, but get constant space usage. > > Instead of remembering inodes, filenames and checksums create a global > cache (e.g. directory hierachy like .cache//) > and hardlink every file to there. If you want/need to include uid, gid, > mtime, mode in there then make that part of the .cache path. > > Garbage collection in the cache would be removing all files with a link > count of 1. > > Going one step further link files with unique size [uid, gid, mtime, > ...] to .cache/ and change that into .cache// hash>/ when you find a second file with the same size that isn't > identical. That would save on the expensive hashing of clearly unique > files. So implement an object store and replace files outside the object store with hardlinks to the store. Yes, this is guaranteed to work for some cases, but also has problems. If you create files first, and then move them to the store, you still need to check every file with link count != 1 and check whether it is in the cache already. And for this, you need a lookup by inode if you want to avoid hashing. And this is basically the same hierarchy as git has: .git/objects/first 2 hex digits of sha1sum/remaining sha1sum > > You could also use a hash that computes the first byte from the first > 4k, second byte from 64k, thrid from 1mb and so on. That way you can > check if the beginning of 2 files match without having to checksum the > whole file or literally comprare the two. If the beginning can match. They're not guaranteed to match just because the hashes match. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpEizNmg3bwX.pgp Description: PGP signature
Bug#662080: ITP: hadori -- Hardlinks identical files
On Sun, Mar 04, 2012 at 03:18:50AM +0100, Timo Weingärtner wrote: > Hallo Julian Andres, > > 2012-03-04 um 01:07:42 schriebst Du: > > On Sun, Mar 04, 2012 at 12:31:16AM +0100, Timo Weingärtner wrote: > > > > The initial comparison was with hardlink, which got OOM killed with a > > > hundred backups of my home directory. Last night I compared it to duff > > > and rdfind which would have happily linked files with different st_mtime > > > and st_mode. > > > > You might want to try hardlink 0.2~rc1. In any case, I don't think we need > > yet another such tool in the archive. If you want that algorithm, we can > > implement it in hardlink 0.2 using probably about 10 lines. I had that > > locally and it works, so if you want it, we can add it and avoid the > > need for one more hack in that space. > > And why is lighttpd in the archive? Apache can do the same ... Can it? Apache uses threads, lighttpd uses an event loop for processing. That's a different topic though. But in any case, avoiding yet another tool with the same security issues (CVE-2011-3632) and bugs (and more bugs) as we currently have would be a good idea. hadori bugs: - Race, possible data loss: Calls unlink() before link(). If link() fails the data might be lost (best solution appears to be to link to a temporary file in the target directory and then rename to target name, making the replacement atomic) - Error checking: Errors when opening files or reading files are not checked (ifstream uses the failbit and stuff). Common security issue, same as CVE-2011-3632 for Fedora's hardlink: [Unsafe operations on changing trees] - If a regular file is replaced by a non-regular one before an open() for reading, the program reads from a non-regular file - A source file is replaced by one file with different owner or permissions after the stat() and before the link() - A component of the path is replaced by a symbolic link after the initial stat()ing and readdir()ing. An attacker may use that to write outside of the intented directory. (Fixed in Fedora's hardlink, and my hardlink by adding a section to the manual page stating that it is not safe to run the program on changing trees). Possibly hardlink only bugs: - Exaggeration of sizes. hardlink currently counts every link replaced -st_size, even is st_nlink > 1. I don't know what hadori does there. (and it requires more work to fix that in hardlink, as we currently do not combine links to the same inode in any way, and likely want --dry-run to work correct as well). You can also drop your race check. The tool is unsafe on changing trees anyway, so you don't need to check whether someone else deleted the file, especially if you're then linking to it anyway. > > > hardlink 0.2 is written in C, and uses a binary tree to map > > (dev_t, off_t) to a struct file which contains the stat information > > plus name for linking. It requires two allocations per file, one for > > the struct file with the filename, and one for the node in the tree > > (well, actually we only need the node for the first file with a > > specific (dev_t, off_t) tuple). A node has 3 pointers. > > The "hardlink" I used at that time was written in python and definitely > didn't > do it the way I want. I know. I knew that there were problems on large trees in 2009, but got nowhere with a fix in Python. We still have the two passes in hardlink and thus need to keep all the files currently, as I did not carry the link-first mode over from my temporary C++ rewrite, as memory usage was not much different in my test case. But as my test case was just running on /, the whole thing may not be representative. If there are lots of duplicates, link-first can definitely help. The one that works exactly as as you want is most likely Fedora's hardlink. > > hadori is written in C++11 which IMHO makes it look a little more readable. Yes. It looks readable, but also has far less features than hardlink (which were added to hardlink because of user requests). You can get it even shorter and more efficient if you use POSIX's nftw() to walk the directory tree instead of your recurse()/recurse_start() pair (you just need to write one callback that takes a complete file path, a type info, a stat buffer, and the basename of the file). Does not work on Haiku though, or BSDs prior to 2002. Alternatively, there's also fts() if you don't care about the System V line of UNIXes (e.g. Solaris). You can tell both to not cross mount points and do not follow symbolic links, which makes the whole thing very easy. > It > started with tree based map and multimap, now it uses the unordered_ (hash > based) versions which made it twice as fast in a typical workload. That's strange. In my (not published) C++ version of hardlink, unordered (multi) maps were only slightly faster than ordered ones. I then rewrote the code in C to make it more readable to the common
Processed: Reassign ITA to wnpp
Processing commands for cont...@bugs.debian.org: > notfound 651724 pdfcube/0.0.2-3 Bug #651724 [pdfcube] ITA: pdfcube Bug No longer marked as found in versions pdfcube/0.0.2-3. > reassign 651724 wnpp Bug #651724 [pdfcube] ITA: pdfcube Bug reassigned from package 'pdfcube' to 'wnpp'. > retitle 651724 ITA: pdfcube -- PDF document viewer with 3D effects Bug #651724 [wnpp] ITA: pdfcube Changed Bug title to 'ITA: pdfcube -- PDF document viewer with 3D effects' from 'ITA: pdfcube' > End of message, stopping processing here. Please contact me if you need assistance. -- 651724: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651724 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133086041923663.transcr...@bugs.debian.org
Bug#655955: marked as done (O: opendchub -- hub clone for DC (Direct Connect P2P network))
Your message dated Sun, 04 Mar 2012 11:03:30 + with message-id and subject line Bug#662069: Removed package(s) from unstable has caused the Debian Bug report #655955, regarding O: opendchub -- hub clone for DC (Direct Connect P2P network) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 655955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655955 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: normal Hello, I am the sponsor of the opendchub package. Since the package is RC buggy since a longer time and the maintainer is not responsible since an longer time I orphan it. I would be happy if someone could take care of the package. If you are not an Debian Developer you may ask me directly per mail for sponsoring your upload(s). -- System Information: Debian Release: 5.0.9 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) --- End Message --- --- Begin Message --- Version: 0.8.2-2+rm Dear submitter, as the package opendchub has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see http://bugs.debian.org/662069 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org. Debian distribution maintenance software pp. Joerg Jaspert (the ftpmaster behind the curtain) --- End Message ---
Processed: tagging 630469
Processing commands for cont...@bugs.debian.org: > tags 630469 + pending patch Bug #630469 [wnpp] ITP: grabserial -- Grab serial port output Added tag(s) pending and patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 630469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630469 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133085929714370.transcr...@bugs.debian.org
Bug#598897: marked as done (ITA: jde -- JDEE, Java Development Environment for Emacs(en))
Your message dated Sun, 04 Mar 2012 11:01:13 + with message-id and subject line Bug#662077: Removed package(s) from unstable has caused the Debian Bug report #598897, regarding ITA: jde -- JDEE, Java Development Environment for Emacs(en) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 598897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: normal The current maintainer of jde, Michael W. Olson (GNU address) , is no longer maintaining it and suggested someone else take it over. Michael Olson writes: > I'm not maintaining any Debian packages anymore, so you're welcome to > take it over if you like. > > On Fri, Oct 1, 2010 at 4:44 PM, Eric Warmenhoven > wrote: >> Hi, >> >> It's been a while since there's been any activity with the jde package, >> and I was wondering if you need or want any help with it. Do you still >> have time for it? I'd be happy to help however I can. >> >> Thanks, >> Eric >> pgppRBRW0IAFV.pgp Description: PGP signature --- End Message --- --- Begin Message --- Version: 2.3.5.1-5+rm Dear submitter, as the package jde has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see http://bugs.debian.org/662077 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org. Debian distribution maintenance software pp. Joerg Jaspert (the ftpmaster behind the curtain) --- End Message ---
Bug#641303: marked as done (ITP: pinktrace -- ptrace wrapper library)
Your message dated Sun, 04 Mar 2012 09:34:31 + with message-id and subject line Bug#641303: fixed in pinktrace 0.1.2-1 has caused the Debian Bug report #641303, regarding ITP: pinktrace -- ptrace wrapper library to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 641303: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641303 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist Owner: Jakub Wilk * Package name: pinktrace Version : 0.1.2 Upstream Author : Ali Polatel * URL : http://dev.exherbo.org/~alip/pinktrace/ * License : BSD-3-clause Programming Lang: C Description : ptrace wrapper library PinkTrace is a lightweight C library that eases the writing of tracing applications. It consists of the following parts: - Wrappers around different ptrace() requests. - An API for decoding arguments (strings, socket addresses, …) - An experimental API for encoding arguments. - An initial implementation of a callback-driven higher-level library called pinktrace-easy. -- Jakub Wilk --- End Message --- --- Begin Message --- Source: pinktrace Source-Version: 0.1.2-1 We believe that the bug you reported is fixed in the latest version of pinktrace, which is due to be installed in the Debian FTP archive: libpinktrace-0.1-1_0.1.2-1_i386.deb to main/p/pinktrace/libpinktrace-0.1-1_0.1.2-1_i386.deb libpinktrace-dev_0.1.2-1_i386.deb to main/p/pinktrace/libpinktrace-dev_0.1.2-1_i386.deb libpinktrace-easy-0.1-0_0.1.2-1_i386.deb to main/p/pinktrace/libpinktrace-easy-0.1-0_0.1.2-1_i386.deb pinktrace_0.1.2-1.debian.tar.gz to main/p/pinktrace/pinktrace_0.1.2-1.debian.tar.gz pinktrace_0.1.2-1.dsc to main/p/pinktrace/pinktrace_0.1.2-1.dsc pinktrace_0.1.2.orig.tar.bz2 to main/p/pinktrace/pinktrace_0.1.2.orig.tar.bz2 python-pinktrace_0.1.2-1_i386.deb to main/p/pinktrace/python-pinktrace_0.1.2-1_i386.deb python3-pinktrace_0.1.2-1_i386.deb to main/p/pinktrace/python3-pinktrace_0.1.2-1_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 641...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jakub Wilk (supplier of updated pinktrace package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 24 Feb 2012 16:29:47 +0100 Source: pinktrace Binary: libpinktrace-0.1-1 libpinktrace-easy-0.1-0 libpinktrace-dev python-pinktrace python3-pinktrace Architecture: source i386 Version: 0.1.2-1 Distribution: experimental Urgency: low Maintainer: Jakub Wilk Changed-By: Jakub Wilk Description: libpinktrace-0.1-1 - ptrace wrapper library (low-level API) libpinktrace-dev - development files for ptrace wrapper library libpinktrace-easy-0.1-0 - ptrace wrapper library (higher-level API) python-pinktrace - Python 2.X bindings for ptrace wrapper library python3-pinktrace - Python 3.X bindings for ptrace wrapper library Closes: 641303 Changes: pinktrace (0.1.2-1) experimental; urgency=low . * Initial release (closes: #641303). * Add patch to fix SONAME. (soname.diff) * Add patch not to export a private symbol. (private-symbols.diff) * Add patch to link libpinktrace easy with libpinktrace. (libpinktrace-easy-linkage.diff) * Add patch to remove images and scripts referring to external sites from the documentation. (offline-documentation.diff) * Add patch to add $(top_builddir)/include to include path, allowing out-of-tree builds. (out-of-tree-includes.diff) * Add patch to fix path to python-test.sh, allow out-of-tree testing of Python modules. (python-test-path.diff) Checksums-Sha1: 5b7efe1e11d17f282256b29df3118ded913277a3 2199 pinktrace_0.1.2-1.dsc a40f2b0e816ed49432879a6c710f34736eb2 443905 pinktrace_0.1.2.orig.tar.bz2 cb83e83d4788806454cb9f4a9fd4723309eb9a5a 9590 pinktrace_0.1.2-1.debian.tar.gz 5bf2429306fb6d48c014807facad88416755ce39 16362 libpinktrace-0.1-1_0.1.2-1_i386.deb e0c2d12b2d622e0cb5d103b27d7ebf239470d58b 13506 libpinktrace-easy-0.1-0_0.1.2-1_i386.deb ee35992edfc1738c1f4c16f6d18dc797a336a6b6 201566 libpinktrace-dev_0.1.2-1_i386.deb bab5612f155bb7c409f4e54f21d720cc1e0665b8 59822 python-pinktrace_0.1.2-1_i386.deb
Bug#653972: marked as done (ITA: eris -- The WorldForge client entity library)
Your message dated Sun, 04 Mar 2012 09:32:47 + with message-id and subject line Bug#653972: fixed in eris 1.3.19-1 has caused the Debian Bug report #653972, regarding ITA: eris -- The WorldForge client entity library to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 653972: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653972 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: normal The current maintainer of eris, Michael Koch , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: eris Binary: liberis-1.3-dev, liberis-1.3-15, liberis-1.3-15-dbg, liberis-doc Version: 1.3.14-3 Maintainer: Michael Koch Build-Depends: cdbs, debhelper (>= 5), libsigc++-2.0-dev, doxygen, libglib2.0-dev, libatlas-cpp-0.6-dev (>= 0.6.0), libmercator-0.2-dev (>= 0.2.7), libskstream-0.3-dev (>= 0.3.6), libwfmath-0.3-dev (>= 0.3.9), chrpath Build-Conflicts: libsigc++-1.2-dev, libsigc-perl, libsigcoperl-dev Architecture: any Standards-Version: 3.8.3 Format: 1.0 Files: fde5e20e35698987be9bcbd682a2029f 1272 eris_1.3.14-3.dsc ac113b43b3c7fb714ede636c7fc80cdd 560929 eris_1.3.14.orig.tar.gz 5ca780e722ea1c9532064ce7136159d8 4245 eris_1.3.14-3.diff.gz Checksums-Sha1: 1dfdeef77de062b3084b1d546fb2da8f3c7cb65d 1272 eris_1.3.14-3.dsc 74d679226443326994555af91cbeab2d184b2165 560929 eris_1.3.14.orig.tar.gz ba255d67fdcac0a6bb22601f6cd1f2296e2faeae 4245 eris_1.3.14-3.diff.gz Checksums-Sha256: 4b82663b6e9a802e73187fd867b828555ab8e1342da029ce47ce12974493c49d 1272 eris_1.3.14-3.dsc eff9d26c153653089d16b68fd2122509d44bffa7e240921e606cad8d3c9ed723 560929 eris_1.3.14.orig.tar.gz f8bd99aa3993f4dd00d938fd53a15e6ccee73ce2442aff5f043cd0e785dde77f 4245 eris_1.3.14-3.diff.gz Homepage: http://www.worldforge.org/ Directory: pool/main/e/eris Priority: source Section: libs Package: liberis-1.3-15 Source: eris Version: 1.3.14-3 Installed-Size: 744 Maintainer: Michael Koch Architecture: amd64 Depends: libatlas-cpp-0.6-1, libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libmercator-0.2-6, libsigc++-2.0-0c2a (>= 2.0.2), libskstream-0.3-4 (>= 0.3.6), libstdc++6 (>= 4.2.1), libwfmath-0.3-4 Description: The WorldForge client entity library Eris is designed to simplify client development (and avoid repeating the same work several times), by providing a common system to deal with the back end tasks. Notably, Eris encapsulates most of the work in getting Atlas entities available on your client, logging into a server, and managing updates from the server. Thus it can be considered as a session layer above Atlas, providing persistent (for the session) objects as opposed to Atlas ones (which are transient). It handles the client-side implementation of the meta-server protocol, and querying game servers; out-of-game (OOG) operations (via the Lobby and Rooms), and most important in-game (IG) operations such as entity creation, movement and updates. . Eris provides a generic 'Entity' class, which you are free to sub-class and provide to the system (by registering a factory with the World); thus you are free to create different classes to handle characters, walls, vehicles, etc as your client dictates. An alternative approach is to simply create peer classes, and connect them to Eris via callbacks. Eris makes extensive use of libSigC++, which must be correctly installed and functioning on your system. Familiarity with signal/slot programming concepts is essential for using Eris; the libSigC++ home-page has some examples. Gtk+ or QT signal systems also provide a good introduction. Homepage: http://www.worldforge.org/ Tag: role::shared-lib Section: libs Priority: optional Filename: pool/main/e/eris/liberis-1.3-15_1.3.14-3_amd64.deb Size: 295254 MD5sum: 6802d5759e2f74eebb10a88af2e8e129 SHA1: e09dfe753f68108173074903c24e26ab79f41fa9 SHA256: 4de77bb64980c98c78e76e27a5b350271df3b8a2790e628a6a94009199afcc39 Package: liberis-1.3-15-dbg Source: eris Version: 1.3.14-3 Installed-Size: 5672 Maintainer: Michael Koch Architecture: amd64 Depends: liberis-1.3-15 (= 1.3.14-3) Description: The WorldForge client entity library - debugging library Eris is designed to simplify client development (and avoid repeating the same work several times), by providing
Bug#662121: RFP: node-ejs -- embedded Javascript templates
Package: wnpp Severity: wishlist * Package name: node-ejs Version : 0.6.1 Upstream Author : TJ Holowaychuk * URL : http://search.npmjs.org/#/ejs * License : MIT Programming Lang: Javascript Description : embedded Javascript templates -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120304092756.13116.51688.report...@isafjordur.dyndns.org
Bug#662117: RFP: node-mysql -- pure JavaScript Client implementing the MySQL protocol
Package: wnpp Severity: wishlist * Package name: node-mysql Version : 0.9.5 Upstream Author : Felix Geisendörfer * URL : https://github.com/felixge/node-mysql * License : MIT/X Programming Lang: Javascript Description : pure JavaScript Client implementing the MySQL protocol -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120304084746.30581.24270.report...@isafjordur.dyndns.org
Processed: rubyripper ITP
Processing commands for cont...@bugs.debian.org: > retitle 463584 ITP: rubyripper -- an open-source secure ripper for Linux Bug #463584 [wnpp] RFP: rubyripper -- an open-source secure ripper for Linux Changed Bug title to 'ITP: rubyripper -- an open-source secure ripper for Linux' from 'RFP: rubyripper -- an open-source secure ripper for Linux' > owner 463584 ! Bug #463584 [wnpp] ITP: rubyripper -- an open-source secure ripper for Linux Owner recorded as "Scott Leggett" . > thanks Stopping processing here. Please contact me if you need assistance. -- 463584: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463584 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133085077629875.transcr...@bugs.debian.org
Bug#602463: Still interested in packaging clanlib2?
On 03.03.2012 23:51, Fabien Givors (Debian packages) wrote: > Hi Andreas, > > Yes, I opened bug #602463 some time ago... > > I did most of the packaging. Unfortunately, I couldn't get rid of some > lintian warnings. So, the package is not perfect. > > I can give you the product of my work if you want. It worked quite well. I'd propose to have it maintained under the Debian Games umbrella, with a git repository at Alioth. If you send me your current debian/directory, I'll inject it into the repository. > Unfortunately, at the same time, my spare time > amount began to decrease dramatically :) And I was not able to pursue > my task. No problem ;-) > Currently, last clanlib version is 2.3.5 [1], and the API does not > seem to have changed a lot [2]. So, the question is, should we package > the last "stable" 2.2 version, or the last released version? I'd say go for the 2.3 release, I'll test the Trophy game against that. > I hope we will be able to work together, Me too! Cheers, Andreas signature.asc Description: OpenPGP digital signature
Processed: merging 661779 661780
Processing commands for cont...@bugs.debian.org: > merge 661779 661780 Bug#661779: RFP: node-tap -- Test Anything Protocol tools for NodeJS Bug#661780: RFP: node-tap -- Test Anything Protocol tools for NodeJS Merged 661779 661780. > thanks Stopping processing here. Please contact me if you need assistance. -- 661780: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661780 661779: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661779 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133084996925066.transcr...@bugs.debian.org
