Bug#317808: Shouldn't this be a RFP?
I don't see this package anywhere currently in Debian, yet you sent this as an RFA (Request for Adoption), perhaps you were requesting that it be packaged instead? Micah signature.asc Description: Digital signature
Bug#312413: CAN-2005-1921
Hey Penny, One of the applications affected by a recent swatch of PEAR XML_RPC (aka XML-RPC or xmlrpc) and PHPXMLRPC security flaws that allow remote attackers to execute arbitrary PHP code via an XML file (which is not properly sanitized before being used in an eval statement) is serendipity! Be sure that when packaging serendipity that CAN-2005-1921 is fixed before it is uploaded. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243938: ITP: rkhunter
On Sun, 14 Aug 2005, Frederik Dannemare wrote: > On Tuesday 09 August 2005 05:41, Matt Taggart wrote: > > The ITP for rkhunter has been quiet since Feb 15. > > > > Frederik, > > I understand your concern about waiting for upstream to integrate > > patches you sent so that the initial version of the package gets to > > start out with a more reasonable debian diff. Has upstream taken them > > yet? > > Not to my knowledge. At least I haven't heard anything from upstream yet > regarding a merge of my patches. Could you send to this bug report the changes requested of upstream, so that we can help with this process, or at least have these documented here. > > I don't think we should wait forever and if they haven't been > > accepted then I think you should proceed. > > I guess you're right. I'm under an expreme work load at work these > months, though, so my time is limited. Perhaps someone else can take the packaging to get it going, and when you are under less pressure and have more time can co-maintain or take it over? > > I and others are waiting for this package and it would be good if > > something was available in the next few weeks. > > I'll see what I can do. Hopefully, I'll manage to find some time in the > upcoming weekends... Do not apply more stress than necessary. Myself, or one of the others here would be happy to get the package into shape and get it uploaded to get things started, then when you have more time you can begin to do either co-maintainence, or take over the package. > > > > The package available in, > > > > http://people.debian.org/~ema/packages/ > > > > is dated Jan 06. Is this the most recent attempt at packaging > > available? > > I suspect it is. This is Emanuele's last attempt, we haven't heard anything from him here, so we can assume it is the latest. However, I imagine it needs to be updated to a newer version, and perhaps integrate your changes that you sent to upstream. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243938: Existing packages
Hi everyone, I am going over the 1.2.7-10 package and making a few changes here and there, getting it ready to be uploaded into the archive... I've just got some testing to do. Regarding package maintainence -- it sounds like a few of you have expressed desire to help and work together and get sponsorship for the package. I am fine with sponsoring the package, if you are prepared to actually maintain it Sponsorship for me means meeting a few criteria: 1. conversant in the relevant developer documentation, policy, Developer's Reference and where to find things related to the package. Need to also be on d-d-announce 2. Gotta be lintian, pbuilder and install clean. 3. The package needs to be maintained (bugs should be responded to/fixed; new upstream versions packaged, etc.) 4. and (I'm not really strict on this), intending to join the debian project at some point... I find sponsorship to be a burden on developers and if people aren't ever going to become maintainers that might be a problem in the long term 5. need to have a gpg key... preferably signed by someone in the web of trust If these requirements are too much, and make it not worth you having me sponsor the package, I'd probably prefer to just be the maintainer myself, but would be very happy to have your contributions/improvements and act as co-maintainers! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243938: Existing packages
On Sat, 03 Sep 2005, Micah Anderson wrote: > If these requirements are too much, and make it not worth you having me > sponsor the package, I'd probably prefer to just be the maintainer myself, > but would be very happy to have your contributions/improvements and act as > co-maintainers! I dont think I was very clear here, basically the options are: 1. One of you be the package maintainer. Because there can only be one maintainer it would either have to be one of you, or we setup an alioth project, with a mailing list and that mailing list is the package maintainer. We setup a svn repository for the package so everyone can access it and make changes that all can share. 2. I be the primary maintainer and you can co-maintain it. This would mean that you would subscribe to the package so you would get bug reports, you can respond to bug reports, and improve the package, and I participate in that process and do the uploads. We would have a svn repository for this scenario as well. So, the way I see it is if there is one of you who really wants to be the rkhunter maintainer, and is looking for a package to maintain actively with debian (perhaps for the purpose of being a stepping stone to becoming a debian maintainer, as having a package in the archive is a necessary step), then speak up and say you will be that person and that the requirements for sponsorship I detailed previously are acceptable. Or, if you just want to help we can do a co-maintainership. I'm fine with managing the package, but I want to give you guys the opportunity to be the package maintainer if you want (especially since you have done some good work on it already!). micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243938: rkhunter debian
Andrea, You may have missed the most recent actions in the bug log[1], if you review it you will see that indeed people are actually working on this. In fact, a 1.2.7 package has been prepared, and I am ready to upload it, however I am just trying to sort out from the people who have worked on it if there is real interest in maintaining it collaboratively, or not. Micah 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243938 Andrea Rezzonico schrieb am Thursday, den 08. September 2005: > Hi, > > Since nobody is really doing it, I've packaged the new version of rkhunter > (1.2.7), you can find the .deb here > http://www.uaz.ch/debian/rkhunter/rkhunter_1.2.7-2_all.deb > > bye > Andrea Rezzonico -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488753: Uploaded passenger
David Moreno and I spent some time at Debconf preparing a new version of Passenger to address the various issues that ftp master had, and upgraded it to a new version. We uploaded it last night, and it is now in the NEW queue, we'll have to close this ITP after (or if) it is accepted, as well as move it to the proper area in the debian-ruby-extras team area. micah signature.asc Description: Digital signature
Bug#449031: Chandler
Hello, A friend of mine recently was telling me about Chandler, and my natural instinct was to see if it was in Debian, and it wasn't so I was less interested in trying it out myself. However, I thought I would see if there was an ITP, and lo! there is. However, it hasn't seen any movement since June, so this message is a friendly *poke* to see where things are at. I certainly understand people are quite busy, so please don't take this the wrong way, I'm just curious about the status of this project. micah signature.asc Description: Digital signature
Bug#488753: passenger_2.2.4debian-1_i386.changes REJECTED
Hi Torsten, Thanks for looking over Passenger, and thanks for noticing some missing copyright/license information! Sorry that those were not included. * Torsten Werner [2009-08-18 15:54-0400]: > Hi Maintainer, > > > rejecting because the copyright file is missing license and copyright > information for most of the vendor packages. For example: > > ext/nginx/* (eg. Manlio Perillo) > ext/common/* (eg. René Nyffenegger) > test/stub/rails_apps/mycook/public/javascripts/*.js (eg. Fuchs) > ext/apache2/Hooks.cpp (eg. scgi & CNRI license) I've just finished going through all the files and updated the copyright document with all the missing pieces (everything you noted above was added, plus several more). I've uploaded a new version with these fixes just now. Micah signature.asc Description: Digital signature
Bug#503977: Tahoe-LAFS for Ubuntu!
Hi! * Zooko Wilcox-O'Hearn [2009-08-26 01:03-0400]: > Dear Micah Anderson and Fernando Ribeiro: > > You've each expressed interest in Tahoe-LAFS in the past. Now we've > finally gotten it all packaged up to be included in Ubuntu. Are > either of you authorized to do package reviews for Ubuntu? I am not authorized to do package reviews for Ubuntu. I am a Debian developer and can get packages into Debian. Typically Debian is 'upstream' for Ubuntu for packages, they have those sync'd from Debian to Ubuntu on a regular basis. If they are in Debian already, it is much easier to get them into Ubuntu. I am interested in getting this into Debian, although I cannot commit to being the sole package maintainer. As a first step towards a team-based approach, I have requested from the Debian Alioth team resources for a packaging team. Once this has been approved, I would encourage everyone to join the team. This way we can share a mailing list for maintainence, and a revision control system for managing the package(s) involved. Some background... In October of 2008, I wrote to the Tahoe list indicating that I would be interested in helping get Tahoe into Debian, the thread is here: http://allmydata.org/pipermail/tahoe-dev/2008-October/000840.html. Myself, Fernando and Brian Warner reviewed the pre-requirements that were needed and what work had been done so far. Brian Warner had already put some time into making packages, and offered to review those packages and sponsor them for Debian (rather than re-doing the packaging from scratch). So, I can approach this from the Debian side. To review the current state of things: Tahoe-lafs -- http://revu.ubuntuwire.com/p/tahoe-lafs Debian ITP: missing Todo: file ITP, I will do this now. package tahoe-lafs based off of Ubuntu package, and then have Ubuntu sync in the future. Zfec - http://revu.ubuntuwire.com/p/zfec Debian ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503976 (open) This is currently listed as an Intent to Package by Zooko since October of 2008. Zooko, do you actually "Intend" to package this for Debian? The ITP bug title indicates that you are intending to do this. Todo: Waiting for response from Zooko about desire to package this. Package zfec, base it off of the ubuntu package and then have Ubuntu sync in the future Foolscap http://revu.ubuntuwire.com/p/foolscap Debian ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499699 (closed) The python-foolscap package is in Debian since end of December, it is currently at version 0.4.2. Todo: A request for this package to be sync'd to Ubuntu should happen. Pycryptopp -- http://revu.ubuntuwire.com/p/pycryptopp Debian ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503977 (closed) The python-pycryptopp package is in Debian, currently at revision 0.5.15, it looks like this is being handled by Zooko (although perhaps you would like to integrate it into the team repository when it is available?) Todo: A request for this package to be sync'd to Ubuntu should happen signature.asc Description: Digital signature
Bug#544338: ITP: tahoe-lfs -- A secure distributed filesystem
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: tahoe-lfs Version : 1.5.0 Upstream Author : Allmydata, INC * URL : http://allmydata.org * License : GPLv2 or later Programming Lang: Python Description : A secure distributed filesystem Tahoe, the Least Authority File System, is a distributed filesystem that features high reliability, strong security properties, and a fine-grained sharing model. Files are encrypted, signed, erasure-coded, then distributed over multiple servers, such that any (configurable) subset of the servers will be sufficient to recover the data. The default 3-of-10 configuration tolerates up to 7 server failures before data becomes unrecoverable. . Tahoe offers "provider-independent security": the confidentiality and integrity of your data do not depend upon the behavior of the servers. The use of erasure-coding means that reliability and availability depend only upon a subset of the servers. . Tahoe files are accessed through a RESTful web API, a human-oriented web server interface, and CLI tools. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503977: Tahoe-LAFS for Ubuntu!
* Micah Anderson [2009-08-30 14:44-0400]: > Tahoe-lafs > -- > http://revu.ubuntuwire.com/p/tahoe-lafs > Debian ITP: missing > > Todo: file ITP, I will do this now. package tahoe-lafs based off of > Ubuntu package, and then have Ubuntu sync in the future. ITP Done: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544338 micah signature.asc Description: Digital signature
Bug#497940: Augeas and Puppet
Hi Marc, * Marc Fournier <[EMAIL PROTECTED]> [2008-11-12 05:43-0500]: > Hello, > > I've filed a packaging request in debian's BTS a few weeks ago (#497940). > > I've also made a package a while ago. It builds on debian lenny and ubuntu > ibex, but not on etch. Last week sometime, I uploaded to Debian a package that Bart Cortooms made (CC'd on this email). It is currently sitting in the Debian NEW queue, waiting to be processed by the FTP masters. I'm sending this email to the bug report, because there hasn't been any information added to that bug report yet which would let anyone know about this forward progress. > I consider this as work in progress. It can be downloaded from > http://ppa.launchpad.net/mfournier/ubuntu/pool/main/liba/libaugeas-ruby/ > > As I'm not used to packaging, I'm not sure if what I done is the way it > should be. I'd be glad to have some feedback on this ! Perhaps Bart could have a look at your packaging work and see about integrating anything. I'm not sure if either of you are interested in co-maintainership, or a team-maintainance strategy, but they might be worth considering. Also, it seems like you are primarily focused around Ubuntu, so it could be that you take on the Ubuntu packaging, and art the Debian side? In any case, I leave it to you two to decide, I'm simply sponsoring the upload to Debian as a developer. Micah signature.asc Description: Digital signature
Bug#456227: What is the status of sphinxsearch?
Hi all, The last update to the Debian ITP bug (456227), and the Launchpad group (https://code.launchpad.net/~pkg-sphinx) was in July of last year. I'm wondering what the situation is with this effort? I'm sure everyone is very busy, so I don't mean to be a pest, but I also wanted to point out that the package was pretty much ready to go, just needing one or two last tweaks to get it in place (although a RC for 0.9.9 was released sometime last year now too). Are folks still interested in getting sphinxsearch into debian and ubuntu? micah signature.asc Description: Digital signature
Bug#488753: (forw) Re: Boost bundling
In an effort to try and determine where the situation with Passenger in Debian is stalled, I went on a small adventure to figure out where things are. What follows is the details of the current situation, as well as a helpful explanation from the Passenger folks. I intend to respond to that message when I can, but first I wanted to get the current state of things loaded up into this bug report, so others can see where things are at. First I found that Passenger/mod_rails had been uploaded to NEW[0] some four months ago by Leandro Nunes dos Santos and Filipe Lautert . However, it had not been accepted by the FTP masters, and as such it was not part of the archive yet. Typically when there is a delay such as this in accepting the package into the archive there is some problem, either legal/licensing or technical that is keeping the package from being accepted. I contacted a member of the FTP team to ask what the hold-up was and was told the reason is because passenger has an embedded copy of boost and the FTP team has asked the maintainer at least twice about it and have received no reply. The embedded code problem is an interesting one, one that I have been involved in over the years working in on testing-security where we've been forced to track embedded code copies in Debian[1] so that we could have a chance to deal with security issues in embedded code copies. (A prominently horrible example is the xpdf code-base which was at one time embedded in more than 10 different source packages in Sarge, this was reduced in Etch significantly thanks to the xpdf library fork called poppler which packages were encouraged to link against, instead of embedding). As a result of these issues causing significant number of hours to track, update and manage, with many clever technical solutions developed to do things like use the clamav signature mechanisms to scan the entire archive, etc. Eventually the Debian project saw fit to adopt a policy[2] with specific language about embedded "convenience copies" of code (section 4.13). And this is where Passenger is currently stuck. I took a little bit of time the other day to try and figure out why Passenger embedded Boost and could not find much rationale online, until I found an older blog post[3] about the 1.0.2 release that contains this snippet: Fixed conflicts with system-provided Boost library Passenger makes use of the Boost C++ library. Its sources are included into the Passenger sources. But if the system already has a different Boost version installed, then the two Boost libraries would conflict with each other, and Passenger would fail to install. We’ve made sure that this doesn’t happen: now, installation will succeed even if there’s already another Boost version installed. This is a good first effort, however I believe that this solution doesn't get at the root of the problem and instead makes one of the symptoms go away instead of solving the problem. So I posted to the comments section of the blog asking for more details, and describing the issue around embedding copies of other code, and then received the following response in email (which I have obtained permission to forward here): - Forwarded message from Hongli Lai - Sender: Hongli Lai From: Hongli Lai Subject: Re: Boost bundling Date: Thu, 05 Mar 2009 10:06:44 +0100 To: mi...@debian.org Hi Micah, I saw your reply to my blog about making Boost a build dependency, but I'm afraid your arguments do not hold in our case: - The best argument for wanting to depend on Boost dynamically, is to make it easier to solve security problems. However, upgrading the Boost library will only partially fix security problems. That's because most Boost code live in C++ header files, which get inlined directly by the compiler into the executable. If a security flaw was found in a header then you'd have to recompile the executable that uses Boost even if Boost is a shared library. - Most people don't have Boost installed, or don't have the right version of Boost installed. By far and large, most of our users are _not_ Debian users, and installing Boost is a huge huge pain for 80% of our user base. By _not_ bundling Boost we'll alienate most of our users. I have a different software program which does not bundle Boost, and the #1 support question by users is related to installing Boost. Even Debian users will have a difficult time. We depend on a very specific version of Boost, one that hasn't been packaged by Debian yet. I don't think that telling our Debian users "what? don't have the right version of Boost installed? then wait x months/years until Debian has packaged it, then upgrade your distro" is an acceptable answer to our users, don't you agree? The Fedora guys have tried to patch Phusion Passenger to get rid of the Boost bundling, but after they're done they found out that Fedora ships the wrong version of Boost, putting them back at squa
Bug#488753: (forw) Re: Boost bundling
* Hongli Lai [2009-03-06 09:53-0500]: > Micah Anderson wrote: >> However, it had not been accepted by the FTP masters, and as such it was >> not part of the archive yet. Typically when there is a delay such as >> this in accepting the package into the archive there is some problem, >> either legal/licensing or technical that is keeping the package from >> being accepted. I contacted a member of the FTP team to ask what the >> hold-up was and was told the reason is because passenger has an embedded >> copy of boost and the FTP team has asked the maintainer at least twice >> about it and have received no reply. > > That's strange, I don't recall having been contacted about this subject > before. Sorry I wasn't clear here. I was referring to the Debian packager maintainers, not you (what we would call 'upstream'). micah signature.asc Description: Digital signature
Bug#488753: Boost bundling
Hi, Thanks again for your prompt and complete response to this. I'd like to respond to one or two points you brought up. * Hongli Lai [2009-03-05 04:06-0500]: > - The best argument for wanting to depend on Boost dynamically, is to > make it easier to solve security problems. However, upgrading the Boost > library will only partially fix security problems. That's because most > Boost code live in C++ header files, which get inlined directly by the > compiler into the executable. If a security flaw was found in a header > then you'd have to recompile the executable that uses Boost even if > Boost is a shared library. Of course this is true, there is no dispute that you would have to recompile the exeuctable that uses Boost in this case. However, in Debian this issue is actually best handled through the distribution's dependency system. In otherwords, an application, such as Passenger, would be packaged by a Debian developer to have certain meta-data detailed in its debian/control file. The important bits in this case are the Build-Depends line, which specifies what libraries, development headers and associated applications are necessary to properly build the final application. When we find a security issue in headers, such as the Boost library, we can easily find those applications that have properly listed those Build-Depends and rebuild them against the fixed header files. If the application has a hidden set of vulnerable files tucked somewhere deep in its distributed directory structure, we will only be able to rely on either our hand constructed list of embedded code copies, the maintainer being diligent, or some other external mechanism for notification that there is a security issue that might also affect Passenger, due to the embedded code. In this case, someone from the security team will need to tear apart the Passenger source package, dig around until they find the Boost embedded code and then compare the published vulnerability (which is otherwise clearly associated with either Boost version numbers or source code revision numbers for patches) and compare, side-by-side the affected code region and try to make a vulnerability assessment. This is not fun work, and is prone to errors. Its much simplier to get the CVE id from Mitre that details that Boost version X.Y.z has a buffer overflow issue in whatever chunk of code, the fix is in this patch, and we can quite simply determine which packages in our archive need to be rebuilt as a result of the clear dependency declarations. This is all of course if we find out that an application has this embedded copy of the code and that this code has an issue. We of course now know that Passenger has this, but in many situations we find out the hard way, or not at all. > - Most people don't have Boost installed, or don't have the right > version of Boost installed. By far and large, most of our users are > _not_ Debian users, and installing Boost is a huge huge pain for 80% of > our user base. By _not_ bundling Boost we'll alienate most of our users. > I have a different software program which does not bundle Boost, and the > #1 support question by users is related to installing Boost. As a Debian developer, where making this process easy for the user is one of our primary goals, I understand what you are trying to do. Most people don't have pretty much everything installed that every application needs to run, and if they do, do not have the right version installed at all. This is exactly what distributions, such as Debian, manage for the users. When you install a package on Debian, you automatically get all the right dependencies, at the right version, needed to properly run that package. Due to the fact that Passenger is not currently being distributed by distributions like Debian, Ubuntu, or any of the other myriad of other distributions, then people who are running these distributions (and estimates of numbers for Debian alone are well over a million users and this doesn't include Ubuntu which pulls its packages from Debian, or any of the other many distributions which base themselves also on Debian packages) will come to you to get the code and install it, and will appreciate the reduction of depedency resolution that you provide by giving them everything they need. However, if we could get this into Debian, where we have over a decade of experience managing dependencies, then this very large percentage of your user-base now doesn't care at all that you are bundling Boost as a convenience copy, in fact they now are annoyed that you do because of the security problems previously outlined. So when we are talking about transitioning from you playing the role of the distributor, to Debian playing the role of the distributor, this convenience copy of Boost looses its relevance (for these people) and instead becomes a negative, rather than a positive, addition to the package as a whole. Of course, not everyone of your users is
Bug#450909: I will upload this package
I've started looking over this package and will upload it shortly, thanks Daniel this is great. Micah signature.asc Description: Digital signature
Bug#440565: I will sponsor
Hi all, I'm planning on sponsoring this package. I've begun review of it, and will likely be uploading it shortly. Micah signature.asc Description: Digital signature
Bug#409595: Ping
Hi, This ITP is almost a year old now, what is going on with it? Micah signature.asc Description: Digital signature
Bug#456227: Status of this ITP?
Hi, I'm wondering if there has been any progress made on the packaging of sphinxsearch? I see that this ITP was opened in mid-December and the last activity was a little over a month ago. I can offer sponsorship of this package if you need it. Micah signature.asc Description: Digital signature
Bug#456227: Notes on this package
I've reviewed this package and made some notes on things that I think need to be changed before it can be uploaded to the archive. I previously sent these directly to Monty, but for posterity, I am re-sending to the ITP bug here. > > I can offer sponsorship of this package if you need it. > That would actually be nice. I've got packaging up and usable on > launchpad. If you'd like to look at it: > https://launchpad.net/~pkg-sphinx/+archive I cannot sponsor for ubuntu, but for debian I can. I was able to pull the source package and am taking a look at it. > Otherwise, let me know where to stick them and I'll make a new source > package that's actually targeted at Debian. Have you given much thought about how you are wanting to maintain both an ubuntu and debian package? There are going to be differences in both and perhaps you will want a different branch in the SCM? I'm new to launchpad and bzr, but it looks like there is just a trunk branch at the moment (correct me if I am wrong). If you want to create debian specific packags, and separate development completely, you could create an alioth account to get a SCM repository in Debian land. But if you just want to make a different branch in the existing launchpad bzr for Debian, you could upload the debian-specific package to http://mentors.debian.net, or just put it somewhere that I can get at it. > I need to update this to a later version - but this would be ok for now > I think. If there is a newer version available, lets do that at the same time, probably best to get the latest and greatest in all at once, no? Although, it looks like you've been pulling from the SVN trunk, and the Sphinx page says that r1112 is pretty much a release, except for out of date documentation. Specific notes on the package: . README.Debian needs to be filled out . the version numbers in the changelog are long and ubuntuy, but I think it makes sense to denote the svn revision, maybe change those to debian in the debian branch (version 0.9.8-0u buntu3~svn985 has a space in the version number, which is not legal... maybe you want to fix that?) . The Vcs, Homepage, and Browser debian/control fields would have to be changed if you made a different branch for debian . I know the upstream home page has as their description of Sphinx "Free open-source SQL full-text search engine", but what about changing it to be a little more descriptive, such as, "Fast standalone full-text SQL search engine" or similar? The "Free open-source" part of the description is what gets me... . Longer description shouldn't reference the license in the first paragraph, just cut that first part out. In the second paragraph, instead of using the project text verbatum, maybe change "Generally," to be "Sphinx search is a standalone..." and change the last paragraph just to be, "Sphinx is an acronym which is officially decoded as SQL Phrase Index." and get rid of the "Yes, I know..." part (its a little glib for a package description). The doc/sphinx.txt has some good additional information that might be worth including (in the About and Features sections), but you do want to keep things not too long . I made a couple minor cosmetic changes to debian/rules, I've attached a diff to this email . I notice that there is a daemon (searchd), but you are not providing an initscript for it, there should be one created and it should be named after the package (perhaps a cronjob is needed as well?) . libmysqlclient-dev is only in experimental right now, can this use libmysqlclient15-dev until that is available in sid? . the /bin/bash bootstrap in the rules is something that is weird, first of all it is not a bash script at all, and you aren't build-depending on bash, so you probably shouldn't include it. It would be better to have an autotools: build target in debian/rules that maybe did that if you needed to run it. The sphinx.conf file. There isn't one being generated with some sane defaults and put into /etc/sphinx.conf (perhaps considering putting some defaults in /etc/defaults/sphinxsearch?). This filename might cause some problems, because of the package name, but it shouldn't be a big deal for now, but it might be worthwhile to make things be in /etc/sphinxsearch/sphinx.conf. The config also has /var/log/searchd.log created, maybe that should be /var/log/sphinxsearch.log, or maybe /var/log/sphinxsearch/searchd.log would be better. The default location for the PID file in the config is: @CONFDIR@/log/searchd.pid That should be /var/run/searchd.pid I do notice however that /var/lib/sphinx-search is created, when that=20 probably should be /var/lib/sphinxsearch to correspond to the package name. Also /var/lib/sphinxsearch/data should be created, as that is used. I hope this isn't all overwhelming! Micah --- rules 2008-02-11 19:38:09.0 -0500 +++ /tmp/rules_mine 2008-02-11 21:57:48.0 -0500 @@ -29,9 +29,7 @@ configure: patch configure-stamp configure-stamp: - dh_testdir - #
Bug#456227: Notes on this package
* Monty Taylor <[EMAIL PROTECTED]> [2008-02-18 14:02-0500]: > I have fixed most of these things... (might have missed one or two) and > uploaded to mentors.debian.net... Sorry to take so long to get back to you on this. I've looked over the package again and its looking really good. I've got a few comments in-line: > >> I need to update this to a later version - but this would be ok for now > >> I think. > > > > If there is a newer version available, lets do that at the same time, > > probably best to get the latest and greatest in all at once, no? > > Although, it looks like you've been pulling from the SVN trunk, and the > > Sphinx page says that r1112 is pretty much a release, except for out of > > date documentation. Looks like you updated to the svn r1112... but I took so long to get back to you, Sphinx-0.9.8-rc1 (r1198; Mar 06, 2008) is out now, and this one is being called the stable beta... Since it may take a while to get this through NEW, maybe it should be bumped again? > > Specific notes on the package: > > > > . README.Debian needs to be filled out Looks like you removed it, thats fine. > > . the version numbers in the changelog are long and ubuntuy, but I think > > it makes sense to denote the svn revision, maybe change those to debian > > in the debian branch (version 0.9.8-0u buntu3~svn985 has a space in the > > version number, which is not legal... maybe you want to fix that?) Looks taken care of. > > . I know the upstream home page has as their description of Sphinx "Free > > open-source SQL full-text search engine", but what about changing it to > > be a little more descriptive, such as, "Fast standalone full-text SQL > > search engine" or similar? The "Free open-source" part of the > > description is what gets me... ... > > . Longer description shouldn't reference the license in the first > > paragraph, just cut that first part out. In the second paragraph, Both look good now. > > . I made a couple minor cosmetic changes to debian/rules, I've attached > > a diff to this email > > > > . I notice that there is a daemon (searchd), but you are not providing > > an initscript for it, there should be one created and it should be > > named after the package (perhaps a cronjob is needed as well?) Last I recall you were waiting for someone to provide an initscript, have you heard anything about this? If it doesn't look like its coming soon, what would you like to do? From my basic understanding of Sphinx the daemon needs to be running to be useful and a regular cronjob needs to be run to rebuild the index. > > The sphinx.conf file. There isn't one being generated with some sane > > defaults and put into /etc/sphinx.conf (perhaps considering putting > > some defaults in /etc/defaults/sphinxsearch?). Now there are no config files installed at all? I can't find anything in /etc/defaults, /etc/sphinxsearch, or /etc -- if you try to start searchd like this, you get: FATAL: no readable config file (looked in /etc/sphinxsearch/sphinx.conf, ./sphinx.conf). > > The config also has /var/log/searchd.log created, maybe that should be > > /var/log/sphinxsearch.log, or maybe /var/log/sphinxsearch/searchd.log > > would be better. ... > > The default location for the PID file in the config is: > > @CONFDIR@/log/searchd.pid > > > > That should be /var/run/searchd.pid Not sure whats going on with these as there is no config now... and there is no log created either. > > I do notice however that /var/lib/sphinx-search is created, when that > > probably should be /var/lib/sphinxsearch to correspond to the package name. > > Also /var/lib/sphinxsearch/data should be created, as that is used. Looks like these are resolved, great. Something I noticed on package build: dpkg-shlibdeps: warning: debian/sphinxsearch/usr/bin/searchd shouldn't be linked with libz.so.1 (it uses none of its symbols). Whats up with that? Finally, something unrelated to the actual packaging, but I did notice that there were quite a few warnings that were generated during compilation in sid. You might want to send some of these upstream to get things cleaned up so that sphinxsearch will continue to build against the latest compilers, for example: sphinxmetaphone.cpp: In function ‘int ProcessCode(int, int, CurrentWord_t&, BYTE*, BYTE*)’: sphinxmetaphone.cpp:337: warning: deprecated conversion from string constant to ‘char*’ sphinxmetaphone.cpp:337: warning: deprecated conversion from string constant to ‘char*’ In file included from sphinxexpr.cpp:392: sphinxexpryy.cpp: In function ‘int yyparse(ExprParser_t*)’: sphinxexpryy.cpp:1214: warning: deprecated conversion from string constant to ‘char*’ sphinxexpryy.cpp:1218: warning: deprecated conversion from string constant to ‘char*’ sphinxexpryy.cpp:1332: warning: deprecated conversion from string constant to ‘char*’ sphinxstd.h: In function ‘DWORD sphF2DW(float)’: sphinxstd.h:178: warning: dereferencing type-punned pointer will break strict-aliasing rules sphin
Bug#456227: Checking in
Hi, I'm just checking in about where things are at. I haven't heard anything since my last message on March 24th. I totally understand being busy, I just thought I'd find out where things are at. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489392: Another correction
The URL for this package is incorrect, the URL points to ocamlbricks when it should be pointing to marionnet, as follows: http://darcs.marionnet.org/repos/marionnet also, this is a source code repository URL, is there a project URL that could be used here instead? This looks very interesting, and I am looking forward to the packaging! Micah signature.asc Description: Digital signature
Bug#488753: What is the status of this?
Hi, I see that this bug was reported at the end of June of this year and there has been no update sent here since. What is the current state of this ITP? You said in the original report: > There is a guy (Neil Wilson) who already started to package > passenger to Ubuntu. I'll contact him and see what we > can do to have this package in Debian/Ubuntu. Did you contact Neil and ask him about this? If so, what is the status of this? Thanks, Micah signature.asc Description: Digital signature
Bug#488753: What is the status of this?
* Filipe Lautert <[EMAIL PROTECTED]> [2008-08-13 10:49-0400]: > he already has a package for ubuntu and I already reviewed it, so it > shall be fine for Debian too. We will try to keep the same version for > both, so he can remove it from ubuntu and just let it be copied from > Debian. > I'm just out-of-time right now, so I plan to do the last checks and > upload it maye by the end of this month/begging of next. Thanks for the update, its appreciated! Is the ubuntu package available so others may review it? micah signature.asc Description: Digital signature
Bug#456227: What is the status of sphinxsearch?
* Marco Rodrigues [2009-04-04 05:06-0400]: > > Are folks still interested in getting sphinxsearch into debian and > > ubuntu? > > Yes. Can you push it to NEW ? There was unresolved issues that were going to be fixed before it was pushed into NEW. I'd like to know that they are fixed, and that someone is going to be responsible for this package before I sponsor it. I wont sponsor a package that doesn't have an active maintainer. micah signature.asc Description: Digital signature
Bug#522636: ITP: libpacket-ruby -- ruby library for Event driven network programming
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libpacket-ruby Version : 0.1.15 Upstream Author : Hemant Kumar * URL : http://packet.googlecode.com/ * License : MIT Programming Lang: Ruby Description : ruby library for Event driven network programming Packet is a pure ruby library for writing network applications in Ruby. It follows Evented Model of network programming and implements almost all the features provided by EventMachine. It also provides real easy to user UNIX workers for concurrent programming. Source code is here: http://github.com/gnufied/packet -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522637: ITP: libbackgroundrb-ruby -- BackgrounDRb is a job server and scheduler for moving long-running tasks into the background
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libbackgroundrb-ruby Version : 1.2 Upstream Author : Hement Kumar * URL : http://backgroundrb.rubyforge.org/ * License : MIT Programming Lang: Ruby Description : BackgrounDRb is a job server and scheduler for moving long-running tasks into the background BackgrounDRb is a Ruby job server and scheduler. Its main intent is to be used with Ruby on Rails applications for offloading long-running tasks. Since a Rails application blocks while serving a request it is best to move long-running tasks off into a background process that is divorced from http request/response cycle. The source can be found here: git clone git://github.com/gnufied/backgroundrb.git -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#490146: Lets get this into Debian?
Hi, Is there any reason why you wish to wait to get this package into Debian, including the patches that you have put together? Its been since August of 2007 that this has been sitting here, it would be really nice to get this resolved! micah signature.asc Description: Digital signature
Bug#490146: Lets get this into Debian?
* Ryan Niebur [2009-05-06 19:57-0400]: > Micah, I will take this over if you don't. > > Richard, do you have any work in progress packaging that Micah or I > could work off of? If not, no problem, just I (and Micah probably > doesn't want to either) don't want to duplicate work that's already > been done. I have something that seems to work fairly well, I cant remember where I got it from now :) I'll put it in the pkg-ruby WIP area for people to have a look. micah signature.asc Description: Digital signature
Bug#488753: (fwd) [ftpmas...@debian.org: passenger_2.0.3-1_i386.changes REJECTED]
Hi folks, I'm just wondering what the status of this upload is. Its been 2 months since this reject was sent, and the change to fix it is pretty trivial. Also, 2.2.2 of passenger is available, so it might be good to update to that before re-uploading. Micah - Forwarded message from Mark Hymers - From: Mark Hymers To: Filipe Lautert , Leandro Nunes dos Santos Cc: Debian Installer Subject: passenger_2.0.3-1_i386.changes REJECTED Date: Sat, 07 Mar 2009 14:58:06 + Dear Maintainer, Having recieved your email regarding the embedded boost copy, I'll allow that through. That means however that your debian/copyright file needs to contain the boost copyright/license information. I'm therefore REJECTing the package. Please re-upload with debian/copyright updated and I'll process it again. Thanks, Mark === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. - End forwarded message - signature.asc Description: Digital signature
Bug#488753: (fwd) [ftpmas...@debian.org: passenger_2.0.3-1_i386.changes REJECTED]
I just went through and did some work to get 2.2.2 working with the
existing setup, it required these changes... hope this helps:
Index: debian/control
===
--- debian/control (revision 3254)
+++ debian/control (working copy)
@@ -13,7 +13,7 @@
Package: libapache2-mod-passenger
Architecture: any
-Depends: ${shlibs:Depends}, apache2-mpm-worker, ruby, rubygems (>= 1.2)
+Depends: ${shlibs:Depends}, apache2-mpm-worker, ruby, rubygems (>= 1.2),
librack-ruby1.8 (>= 1.0.0-2)
Suggests: python, rails, passenger-doc
Description: Rails and Rack support for Apache2
Phusion Passenger — a.k.a. mod_rails or mod_rack — makes
Index: debian/libapache2-mod-passenger.install
===
--- debian/libapache2-mod-passenger.install (revision 3254)
+++ debian/libapache2-mod-passenger.install (working copy)
@@ -1,4 +1,3 @@
usr/bin
usr/lib
-etc
../passenger.{conf,load} etc/apache2/mods-available
Index: debian/rules
===
--- debian/rules(revision 3254)
+++ debian/rules(working copy)
@@ -4,7 +4,7 @@
include /usr/share/cdbs/1/rules/simple-patchsys.mk
DEB_DH_INSTALL_SOURCEDIR := $(DEB_DESTDIR)
-DEB_INSTALL_DOCS_passenger-doc += DEVELOPERS.TXT
$(DEB_DESTDIR)/usr/share/doc/passenger/
+DEB_INSTALL_DOCS_phusion_passenger-doc += DEVELOPERS.TXT
$(DEB_DESTDIR)/usr/share/doc/phusion_passenger/
DEB_INSTALL_MANPAGES_libapache2-mod-passenger += man/*
bindir = usr/bin
@@ -12,7 +12,7 @@
builddir = pkg/fakeroot
moddir = usr/lib/apache2/modules
modsavailabledir = etc/apache2/mods-available
-passengermodule = usr/lib/passenger/mod_passenger.so
+passengermodule = usr/lib/phusion_passenger/mod_passenger.so
admintools = passenger-memory-stats passenger-make-enterprisey
passenger-status
clean::
@@ -24,6 +24,7 @@
mv $(builddir) $(DEB_DESTDIR)
binary-install/libapache2-mod-passenger::
+ mkdir -p $(CURDIR)/debian/$(cdbs_curpkg)/$(modsavailabledir)
mkdir -p $(CURDIR)/debian/$(cdbs_curpkg)/$(moddir)
mv $(CURDIR)/debian/$(cdbs_curpkg)/$(passengermodule)
$(CURDIR)/debian/$(cdbs_curpkg)/$(moddir)
rm
$(CURDIR)/debian/$(cdbs_curpkg)/$(bindir)/passenger-install-apache2-module
signature.asc
Description: Digital signature
Bug#478741: pkg-ruby group
Hi Jérémy, I saw that you have done some work on the Redmine package, and you have a version over at mentors.d.n. As you probably know, Richard Hurt was doing some work on a Redmine package, but had to give up that effort. He was putting his work into the pkg-ruby-extras alioth Work-In-Progress area of the subversion repository, so that the entire pkg-ruby-extras team could collaborate on the package, and provide feedback. I notice that there has not been any action on your package since your last post to the bug, and I had some ideas for how to move it forward: a. join the pkg-ruby-extras alioth group[0] b. have a look at the packages-wip/redmine packaging effort to compare this with your package c. update packages-wip/redmine with your improved work d. send an email to the pkg-ruby-extras-maintainers[1] indicating that you have done the above and would like a review and upload I'm certain that this will move your package forward, and it would be great to have you part of the team! micah 0. http://pkg-ruby-extras.alioth.debian.org/join.html 1. http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers/ signature.asc Description: Digital signature
Bug#116937: lckdutils
I did indeed make an intent to package, however I was contacted by the original person who was going to package it and was told that someone else was working on putting it together, so I contacted that person back in March, and include their response below. I was assuming that they would send something to the BTS about the fact that they were actually working on it, but apparantly they didn't. I would like to get this package in, as I am particularly eager to have it available (especially since I am maintaining the kernel patch), and am wondering if Arnd is still intending to get a package made? >From: Arnd Bergmann <[EMAIL PROTECTED]> >To: Micah Anderson <[EMAIL PROTECTED]> >Subject: Re: [EMAIL PROTECTED]: Re: Taking over ITP] >Date: Thu, 6 Mar 2003 03:24:13 +0100 >Cc: [EMAIL PROTECTED], Kevin Rosenberg <[EMAIL PROTECTED]> >Message-Id: <[EMAIL PROTECTED]> >Status: RO >X-Status: A >Content-Length: 11451 >Lines: 198 > > >On Thursday 06 March 2003 02:21, Micah Anderson wrote: >> Arnd, >> >> I wanted to drop you into the loop because I am very motivated to get the >> lkcd package completed. Yann mentioned I should contact you because he had >> sent his preliminary work to you. Have you gotten anywhere with what he h= >as >> done, where can I pick it up? I have almost finished a package, but would >> be interested to see what you have in case there is something I should ad= >d. > >I haven't found the time to work on it in the last week, but I had some >progress. I have ported it to CVS head, changed lcrash to be built for >all available targets in one binary instead of only for the default >architecture, and changed building qlcrash to link against qt3-mt. >There are two of my coworkers (Michael Holzheu and Andreas Herrman) >that working on the upstream code and I planned to go through >any changes with them so they can check them in to the CVS. > >I still want to split out lcrash into its own package, because the other >parts are not needed on s390 and check that it builds on the s390 >build server. The attached diff is where I stopped last week, >hopefully we can merge our work. > >I am now also in the progress of becoming a DD and want to do the package >for my Task. I have put Kevin Rosenberg on CC because he is my >Application Maintainer. >I am not interested on the kernel-patch-lkcd package, because I'm not >actually using it. I only use lcrash to analyse system dumps from the >s390 dump facility. > > Arnd <>< > > - Forwarded message from Yann Dirson <[EMAIL PROTECTED]> - > > > Date: Wed, 5 Mar 2003 09:37:38 +0100 > > From: Yann Dirson <[EMAIL PROTECTED]> > > To: Micah Anderson <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > > Micah Anderson <[EMAIL PROTECTED]> > > Subject: Re: Taking over ITP > > > > On Tue, Mar 04, 2003 at 07:51:10PM -0800, Micah Anderson wrote: > > > I would like to take over the ITP for the lkcd package. > > > > > > I am not a DD, but I have a sponsor and intend to upload shortly. > > > > Ah OK. Please check with Arnd Bergmann <[EMAIL PROTECTED]>, > > who also notified me of his interest in this package, and to whom I > > have sent my preliminary work. > > > > I think it would also make sense that the one taking lkcdutils would > > adopt the kernel-patch-lkcd package as well. > > > > Regards, > > -- > > Yann Dirson <[EMAIL PROTECTED]> =20 > > http://www.alcove.com/ Technical support manager =20 > > Responsable de l'assistance technique Senior Free-Software Consultant = =20 > > Consultant senior en Logiciels Libres Debian developer > > ([EMAIL PROTECTED])D?veloppeur Debian > On Fri, 16 May 2003, Guillaume Morin wrote: > Hi, > > According to the Debian BTS, you intended to package lckdutils along > with the kernel patch. Do you still plan to upload it ? > > Regards, > > Guillaume. > > -- > Guillaume Morin <[EMAIL PROTECTED]> > >What is the point of trying to dream anymore ? (Alanis Morisette)
Bug#116937: lckdutils
I will see what I can do. Please send me what you have so far and give me a run down of where you were going and what you still think needs to be done. I don't have access to a s390, and I am not sure if I understand what the requirements are for that building for that platform? Probably best to not CC the bug address with the package files that you have put together so far. Thanks, micah Arnd Bergmann schrieb am Samstag, den 17. Mai 2003: > On Saturday 17 May 2003 05:14, Micah Anderson wrote: > > I did indeed make an intent to package, however I was contacted by the > > original person who was going to package it and was told that someone > > else was working on putting it together, so I contacted that person > > back in March, and include their response below. I was assuming that > > they would send something to the BTS about the fact that they were > > actually working on it, but apparantly they didn't. > > > > I would like to get this package in, as I am particularly eager to > > have it available (especially since I am maintaining the kernel > > patch), and am wondering if Arnd is still intending to get a package > > made? > > I still want to, but since I haven't found time to finish my work > on it in the last few months, it is probably better if you do it. > Sorry for my holding up the package instead of getting it done. > > I can send you what I have so far (if I I haven't already given > it to you) and help you with the packaging decisions that still > have to be made and with testing the package on s390. Is that > ok for you? > > Arnd <><
Bug#348625: Whats the status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, What is the status of this ITP? It has been half a year and there is no information in this bug report about where things are at. It really would be nice to have puppet in debian! micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFErAQF9n4qXRzy1ioRAl13AJsGgBRGKTnxcLu3zAj2ID2/RLgWogCgprFm 9N8XDvvW2i+JuQqLH9uEnUU= =CfjV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348625: Whats the status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micah Anderson wrote: > > Hi, > > What is the status of this ITP? It has been half a year and there is no > information in this bug report about where things are at. It really > would be nice to have puppet in debian! > > micah Well, to answer my own question, I see that puppet is currently waiting NEW processing as it was uploaded about 2 weeks ago. This is great news, thanks all! micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFErAZP9n4qXRzy1ioRAveiAJ4iHDBzIWlR6b7oTZezLHb574a99QCgpT05 GgJcCUNhRVjLo+MOEEuelg4= =sAzM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333756: roundcube 0.1beta2 was released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maximiliano Curia wrote: > Hello, > > Roundcube's upstream finally made a new release, they fixed lots of bugs and > added a few features. > Looks like its still a beta (0.1-beta2)... wonder when it will be out of beta. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE4nmz9n4qXRzy1ioRArVCAJwLhu3E22nvl+1UZpvv4BD/eHz0eACfbz4f XGBAzKBFtQqLbCh/wITbvTs= =YeAG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#116937: Taking over ITP
I would like to take over the ITP for the lkcd package. I am not a DD, but I have a sponsor and intend to upload shortly. Micah
Bug#116937: [installer@ftp-master.debian.org: lkcdutils_4.1-1_i386.changes is NEW]
The lkcdutils package that I have been working on for some time, was finally uploaded today. It will take a couple weeks before it enters the archive (because new packages require manual intervention). It is for this reason I tagged this bug as pending upload and I will close it once the package is in. Micah - Forwarded message from Debian Installer <[EMAIL PROTECTED]> - From: Debian Installer <[EMAIL PROTECTED]> To: Micah Anderson <[EMAIL PROTECTED]> Subject: lkcdutils_4.1-1_i386.changes is NEW Date: Thu, 21 Oct 2004 11:17:09 -0400 (new) lkcdutils-dev_4.1-1_i386.deb optional devel Development files for lkcdutils The Linux Kernel Crash Dump (LKCD) project allows for kernel crash dumps to be captured for analysis, either in a dump device (such as swap, or a dedicated dump device) or over the network. . This package includes the header files and the libraries associated with creating lkcdutils. . The home page for lkcdutils is: http://lkcdutils.sourceforge.net (new) lkcdutils_4.1-1.diff.gz optional devel (new) lkcdutils_4.1-1.dsc optional devel (new) lkcdutils_4.1-1_i386.deb optional devel Utilities to capture and analyze kernel crash dumps The Linux Kernel Crash Dump (LKCD) project has created this set of utilities to go along with the kernel patches that allow for a kernel crash dump to be captured for analysis. Currently, when a kernel crashes it prints an Oops on the screen, and one has to manually write what the screen reads in order to have any hope of diagnosis. Using the LKCD kernel patches and utilities a crash dump can be captured, either on disk in a dump device (such as the swap partition), or over the network using a network dump device and then easily analyzed or provided to kernel developers to analyze. . The home page for lkcdutils is: http://lkcdutils.sourceforge.net (new) lkcdutils_4.1.orig.tar.gz optional devel Changes: lkcdutils (4.1-1) unstable; urgency=low . * Updated patches to be in sync with new CVS/website reorg * Created netdump.init script to be installed in init.d * Created patch to modify /etc/rcS.d/S10checkroot.sh and put it in the scripts directory with information about it in README.Debian * Installing example scripts in /usr/share/lkcdutils/scripts * Created patch to make things that were going into redhat /etc/sysconfig into standard /etc/lkcdutils directory instead * Set configure to use --prefix option to install into debian/tmp because Makefile doesn't handle a prefix option yet. * Added patch to fix the kldwarf.c source not compiling due to improper header reference to libdwarf.h * Added patch lkcdutils-sles9-altix-unwind which converts the ia86 trace module so that it can take advantage of kernel unwind tables when generating backtraces. * Added patch lkcdutils-sles9-altix that provides better support for SGI Altix IA64 based systems. * Added patch lkcdutils-sles9 which adds the changes and functionality inthe SLE99 tree. * Created dpatch infrastructure to apply patches necessary to build * Initial Release (Closes: #273040) Announcing to debian-devel-changes@lists.debian.org Closing bugs: 273040 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. - End forwarded message - signature.asc Description: Digital signature
Bug#116937: LKCD ITP status ?
Hello, I have been working on this, it has been difficult because the repeated attempts to get information about which version of what corresponds to what in the LKCD file-structure, had up until recently been met with no answer. In addition I was out of the country for some time, this caused some email back-loggage that I have been clearing recently. I have begun a correspondance with Suparna Bhattacha and we have both decided that the CVS tagged version is probably the best version to actually package. I believe that I will be able to develop this relationship with him and through this be able to get this version packaged now. There are a few remaining issues left to be decided (such as how to deal with the different versions between 2.4 and 2.6, separate packages?), and if others are interested in helping facilitate this to completion, I'd be more than happy to work with someone to resolve these issues the right way. micah Mario 'BitKoenig' Holbe schrieb am Friday, den 13. February 2004: > Hello, > > i'm mailing you because regarding Debian Bug #116937 it seems, > you all have been willing to package lkcdutils more or less > time ago. > If you don't know what I'm talking about, it is higly possible > that I made a mistake. In this case please just ignore this > mail or drop me a small comment regarding this. > > Since I don't know, if you follow the conversations about > #116937, I'm mailing to you directly. > > As far as I can see, there were at least 4 persons involved > last: > * Arnd Bergmann, who seems to not have the time to finish > a package and thus more or less gave it up to > * Micah Anderson > * Hilko Bengen > and last but not least > * Yann Dirson > > On Fri, Feb 13, 2004 at 05:43:40PM +0100, Yann Dirson wrote: > > Well, first of all, is there still someone interested in packaging it > > ? I'm convinced we should have it, so I'm willing to do something, > > but since I already a good number of packages to take care of, I'd > > rather someone else do that. If noone does, and you're willing to > > test, > > My question is exactly the same as Yanns: > > Is anybody of you still working on a lkcdutils package or > willing to do it and has the time to do it? > It would be nice, if you would drop some small comment to > the BTS, whether you are or not, in the hope, we find > somebody who finally does it :) > > > thanks for your work and patience & regards, >Mario > -- > I heard, if you play a NT-CD backwards, you get satanic messages... > That's nothing, if you play it forwards, it installs NT. signature.asc Description: Digital signature
Bug#116937: LKCD ITP status ?
Hilko, Great, I am in the process of getting the proper CVS tagged release information, and when I do I will send it on to include you. Regarding Alioth, perhaps I don't understand Alioth well enough to know why this would be a benefit to us. If I am correct Alioth is used for free software projects that debian is leading (this is not what we are doing with LKCD), and provides CVS, mailing lists, file hosting, project tracking etc. My reading of the lkcd project is that they already have a mailing list, they already have a CVS area, and file hosting. I don't know if they have bug tracking, which might be a way that it could be utilized. However, as I said, I haven't used Alioth yet, so you may know better than I do how this could be used to our advantage, so please tell me :) Micah Hilko Bengen schrieb am Friday, den 20. February 2004: > Micah Anderson <[EMAIL PROTECTED]> writes: > > > There are a few remaining issues left to be decided (such as how to > > deal with the different versions between 2.4 and 2.6, separate > > packages?), and if others are interested in helping facilitate this > > to completion, I'd be more than happy to work with someone to > > resolve these issues the right way. > > Because I tracked the CVS version for some time, I might be able to > help. What do you think about setting up a project on Alioth? > > -Hilko > signature.asc Description: Digital signature
Bug#139749: Known security problems in webgui
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, There are a number of security issues in webgui that should be addressed before this package is uploaded to debian. Please be sure to take care of these: CVE-2006-0680 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0680 CVE-2005-4694 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4694 CVE-2006-0165 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0165 CVE-2005-2837 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2837 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+Tv59n4qXRzy1ioRAobUAJ9TDzC7d7kzAFKnFurQvHFqhv323QCgqXQV 3qsUDFG9MSb+MZ1Ads1jGeU= =Vxz7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243938: Progress?
Hello, Its been a month since the last viewable activity on this ITP. There recently was a new release of rkhunter and I am very interested in seeing it packaged for Debian, so I guess I am just being irritating in asking whats going on, but I will offer my help if any is needed. Thanks, micah signature.asc Description: Digital signature
Bug#243938: Progress?
Sounds good -- this bug had just gone radio silent, so I wanted to see if it had been dropped or something, nice to see there is good reason behind it. If you have a package that works, and is good it might be a good idea to upload it so it gets a spot in the new queue, and as you may know things in the new queue don't necessarily get processed in order. Getting things in there, and then updating the package with a different installer is an option. Thanks for the update! micah Frederik Dannemare schrieb am Tuesday, den 15. February 2005: > On Tuesday 15 February 2005 23:12, Micah Anderson wrote: > > Hello, > > > > Its been a month since the last viewable activity on this ITP. There > > recently was a new release of rkhunter and I am very interested in > > seeing it packaged for Debian, so I guess I am just being irritating > > in asking whats going on, but I will offer my help if any is needed. > > Hi, > > I emailed upstream author 3 weeks ago with some (rather big) patches to > suggest a much more flexible installer process. > > When I saw the 1.2.0 release last week I yet again emailed upstream and > asked about my suggestion. He wrote back to me that he was a bit behind > on unread mails in his inbox, but he would let me know when he had had > time to review my patches. > > Until then I'm a bit hessitating as to package rkhunter (I'm also very > busy with my NM process, atm). Anyways, the NEW queue is *huge* these > days, so an upload of rkhunter tomorrow most likely would be waiting in > the NEW queue for months, I estimate. > > Best regards, > -- > Frederik Dannemare | mailto:[EMAIL PROTECTED] > http://qa.debian.org/developer.php?login=Frederik+Dannemare > http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#141611: cfg2html license
It appears as if there is an actual license available for cfg2html
now, however it doesn't look like one that fits the DFSG guidelines,
which is unfortunate. Here it is for reference:
http://f6.grp.yahoofs.com/v1/kCjYQQyCJlnLOdnga3jNaMFoeK9qfPdCQxqztlp1mQFx1PUKXEkvxBjNah0acrFNtcAcamrfhO_jwddc__tOjyoPHA/License.txt
$Header: /home/CVS/cfg2html/release/doc/License.txt,v 2.5 2003/09/04
10:25:27 ralproth Exp $
End-User License Agreement for the cfg2html package
This End-User License Agreement ("EULA") is a legal agreement between
you (either an individual or a single entity) and the mentioned
authors (ROSE SWE and cfg2html authors, see file AUTHORS/Linux or
README.txt/hpux) of this Software for the software product identified
above, which includes computer software and may include associated
media, printed materials, and "online" or electronic documentation
("SOFTWARE PRODUCT"). By installing, copying, or otherwise using the
SOFTWARE PRODUCT, you agree to be bounded by the terms of this EULA.
If you do not agree to the terms of this EULA, do not install or use
the SOFTWARE PRODUCT.
SOFTWARE PRODUCT LICENSE. All versions of the SOFTWARE PRODUCT are
protected by copyright laws and international copyright treaties, as
well as other intellectual property laws and treaties. The sole
property belongs to ROSE SWE and the cfg2html authors.
1. GRANT OF LICENSE. This EULA grants you the following rights:
Installation and Use. You may install and use an unlimited number of
copies of the SOFTWARE PRODUCT.
Reproduction and Distribution. You may reproduce and distribute an
unlimited number of copies of the SOFTWARE PRODUCT; provided that each
copy shall be a true and complete copy, including all copyright and
trademark notices, and shall be accompanied by a copy of this EULA
(e.g. original tar/sd/rpm/dev archive). Copies of the SOFTWARE PRODUCT
may be distributed as a scandalize product or included with your own
product as long as the SOFTWARE PRODUCT is not sold or included in a
product or package that intends to receive benefits through the
inclusion of the SOFTWARE PRODUCT. The SOFTWARE PRODUCT may be
included in any free or non- profit packages or products.
2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. You can reverse
engineer, decompile, or disassemble the SOFTWARE PRODUCT. Please send
modified versions back to the authors using diff(1) files suitable for
patch(1).
Separation of Components. The SOFTWARE PRODUCT is licensed as a single
product. Its component parts may not be separated for use on more than
one computer.
Software Transfer. You may permanently transfer all of your rights
under this EULA, provided the recipient agrees to the terms of this
EULA.
Termination. Without prejudice to any other rights, the authors of
this Software may terminate this EULA if you fail to comply with the
terms and conditions of this EULA. In such event, you must destroy all
copies of the SOFTWARE PRODUCT and all of its component parts.
3. COPYRIGHT. All title and copyrights in and to the SOFTWARE PRODUCT
(including but not limited to any images, photographs, animations,
video, audio, music, text, and "applets" incorporated into the
SOFTWARE PRODUCT), the accompanying printed materials, and any copies
of the SOFTWARE PRODUCT are owned by the authors of this Software. The
SOFTWARE PRODUCT is protected by copyright laws and international
treaty provisions. Therefore, you must treat the SOFTWARE PRODUCT like
any other copyrighted material.
LIMITED WARRANTY
NO WARRANTIES. The authors of this Software expressly disclaims any
warranty for the SOFTWARE PRODUCT. The SOFTWARE PRODUCT and any
related documentation is provided "as is" without warranty of any
kind, either express or implied, including, without limitation, the
implied warranties or merchantability, fitness for a particular
purpose, or disarrangement. The entire risk arising out of use or
performance of the SOFTWARE PRODUCT remains with you.
NO LIABILITY FOR DAMAGES. In no event shall the authors of this
Software be liable for any special, consequential, incidental or
indirect damages whatsoever (including, without limitation, damages
for loss of business profits, business interruption, loss of business
information, or any other pecuniary loss) arising out of the use of or
inability to use this product, even if the authors of this Software is
aware of the possibility of such damages and known defects. cfg2html
may hang your productive system! This is caused by faulty or hardware
related software such as *fdisk, diagnostic tools etc. For this reason
the usage of cfg2html on a mission critical system is not encouraged!
cfg2html also tends to fill up your filesystem with large log files.
If this is a problem for your system then simply do not use this
program.
Bug#336318: How is this different from libapache-mod-acct?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can you describe how this would be different from the existing libapache-mod-acct* packages? micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDggld9n4qXRzy1ioRAlFxAJ9RX+RyeSb7+nxVc82SRjqTwAiegACfVK8v vjRU98TzB1TbALRN9tAT/tg= =fYtT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336318: License
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The license for mod_watch is not super friendly: http://www.snert.com/Software/mod_watch/LICENSE.TXT I imagine the author could be persuaded to change it if there was a compelling interest to package it in Debian. micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDghEX9n4qXRzy1ioRAqVLAJ0cqR1gaDmPmztUbJBfknxe992HAwCdGQWm 8bo/+fQgXov16OMBSREpzIY= =mZPM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330117: Be aware of security issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If someone does decide to package PmWiki, please be aware of the known security issues that exist, and be sure that any version that is uploaded has these fixed. See: CVE-2005-3849 Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDihQH9n4qXRzy1ioRAruOAJ4kwqH5LNtad21ffaELh32NaTPd4gCgjleF 7bFX+srcuiTb90uMpeDHnXw= =UK4X -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#701962: Upload of libsodium
Hello, I am eager to have libsodium available in Debian. From what I can tell, the last state is László asking Raúl: > I've updated the packaging[2]. Will upload it with those changes if >you don't mind. > > https://github.com/gcsideal/libsodium/commits/master Raúl, it seems like there is just needed an acknowledgment from you that these changes are ok, and then the package would be uploaded to Debian. I'd really like this to be available, so I wanted to check with you about this. thanks! micah pgpYhR3gIXJ9x.pgp Description: PGP signature
Bug#701962: Upload of libsodium
micah anderson writes: I just tried to build this and I had to remove two symbols from the libsodium10.symbols file to get it to build, on 386. - _crypto_stream_salsa20@Base 0.6.0 - _crypto_stream_salsa20_xor_ic@Base 0.6.0 +#MISSING: 0.6.1-1# _crypto_stream_salsa20@Base 0.6.0 +#MISSING: 0.6.1-1# _crypto_stream_salsa20_xor_ic@Base 0.6.0 18:31:17 dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below 18:31:17 dpkg-gensymbols: warning: debian/libsodium10/DEBIAN/symbols doesn't match completely debian/libsodium10.symbols 18:31:17 --- debian/libsodium10.symbols (libsodium10_0.6.1-1+0~20140811181730.5+jessie~1.gbpb11145_i386) 18:31:17 +++ dpkg-gensymbols4cPxAS 2014-08-11 18:31:17.0 + 18:31:17 @@ -1,6 +1,6 @@ 18:31:17 libsodium.so.10 libsodium10 #MINVER# 18:31:17 - _crypto_stream_salsa20@Base 0.6.0 18:31:17 - _crypto_stream_salsa20_xor_ic@Base 0.6.0 18:31:17 +#MISSING: 0.6.1-1+0~20140811181730.5+jessie~1.gbpb11145# _crypto_stream_salsa20@Base 0.6.0 18:31:17 +#MISSING: 0.6.1-1+0~20140811181730.5+jessie~1.gbpb11145# _crypto_stream_salsa20_xor_ic@Base 0.6.0 18:31:17 crypto_aead_chacha20poly1305_abytes@Base 0.6.0 18:31:17 crypto_aead_chacha20poly1305_decrypt@Base 0.6.0 18:31:17 crypto_aead_chacha20poly1305_encrypt@Base 0.6.0 18:31:17 dh_makeshlibs: failing due to earlier errors 18:31:17 debian/rules:8: recipe for target 'binary-arch' failed 18:31:17 make: *** [binary-arch] Error 2 18:31:17 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 18:31:17 E: Failed autobuilding of package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioly98cm@muck.riseup.net
Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG
> Why exactly should shell=True be necessary? It turns out that shell=True (basically what started the fork) is not needed now. Vinay changed it in the latest release of the "original" python gnupg, which came after a bunch of CVEs and some comments in this thread as a result of python-gnupg-ng: http://seclists.org/oss-sec/2014/q1/303 The original reason for doing shell=True is/was commented on python-gnupg (original) code: without that, it didn't work in windows. So while it is true that Shell=True is not needed, python-gnupg-ng has other advantages: its more community based (it has a bugtracker and public repo, to begin with), the code has diverged from the original a bit in adding various gnupg functionality to the module, re-reading of the original having security and documentation in minde and improving the overall code quality. I'd argue that including this in Debian is a win because this one has: * Better gnupg options parsing * Better code structure. * Better documentation. * Open repo and bugtracker. Also - we have a package ready to upload for it. pgpF3YZLn26TJ.pgp Description: PGP signature
Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG
intrigeri writes: > Hi, > > micah anderson wrote (14 Aug 2014 21:12:03 GMT) : >> Also - we have a package ready to upload for it. > > Where can I find this package? It is available at: deb http://deb.leap.se/debian sid main as well as the git repository: git clone https://leap.se/git/python_gnupg-ng.git pgpOpUspBfBqb.pgp Description: PGP signature
Bug#564820: ITP: libpam-barada -- PAM module to provide
On Sun, 14 Feb 2010 15:38:28 -0800, Andrew Pollock wrote: > On Sat, Feb 13, 2010 at 06:22:19PM -0500, micah wrote: > > > > Hey Andrew, any progress on this? > > It's all ready to go, I'm just waiting for upstream to make a release that > addresses > > E: libpam-barada: possible-gpl-code-linked-with-openssl > > and then it'll be good to go. Excellent! Are you interested in some testing? I'd be interested to give it a try myself, as this is how I stumbled on the ITP, because I was wanting it. I wonder if barada could be linked against gnutls instead? micah pgpSqApxE78so.pgp Description: PGP signature
Bug#564820: ITP: libpam-barada -- PAM module to provide
On Sun, 14 Feb 2010 23:26:47 -0500, micah anderson wrote: > On Sun, 14 Feb 2010 15:38:28 -0800, Andrew Pollock > wrote: > > On Sat, Feb 13, 2010 at 06:22:19PM -0500, micah wrote: > > > > > > Hey Andrew, any progress on this? > > > > It's all ready to go, I'm just waiting for upstream to make a release that > > addresses > > > > E: libpam-barada: possible-gpl-code-linked-with-openssl > > > > and then it'll be good to go. > > Excellent! Are you interested in some testing? I'd be interested to give > it a try myself, as this is how I stumbled on the ITP, because I was > wanting it. > > I wonder if barada could be linked against gnutls instead? Looking at it a little closer I actually don't see why barada should link to openssl at all, it doesn't do any transport-layer security and is just using the crypto primitives from openssl: openssl/rand.h and openssl/hmac.h -- pretty straightforward crypto primitives that are provided by gcrypt. Although it is not the same API (and the header files aren't named the same), they are conceptually equivalent, so I think that the right thing to do in this case would be to use gcrypt instead of openssl... Switching to that shouldn't be that hard actually, I think even easier than working out the boring licensing issues. micah pgpBLTxPlnSiF.pgp Description: PGP signature
Bug#572029: ITP: pppd-sql -- pppd-sql provides a MySQL or PostgreSQL backend for CHAP/PAP pppd authentication
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: pppd-sql Version : 0.8.0 Upstream Author : Maik Broemme * URL : https://babelize.org/pppd-sql.php * License : GPLv3 Programming Lang: C Description : pppd-sql provides a MySQL or PostgreSQL backend for CHAP/PAP pppd authentication pppd-sql is a plugin for the Point-to-Point server (pppd) that adds an authentication backend using a MySQL or PostgreSQL database for the Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). It supports MS-CHAPv1 and MS-CHAPv2 too. The IPCP negotiation after authentication handshake is also supported. pppd-sql supports a flexible configuration scheme, has concurrent connection handling for single users across multiple tunnel servers, and comes with easy and handy documentation -- 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/20100301045548.10395.29084.report...@lillypad.riseup.net
Bug#572555: ITP: libcompass-ruby -- Compass is a SASS-based stylesheet authoring tool
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libcompass-ruby Version : 0.10.0.pre8 Upstream Author : Chris Eppstein * URL : http://wiki.github.com/chriseppstein/compass/ * License : Public Domain Programming Lang: Ruby Description : Compass is a SASS-based stylesheet authoring tool Compass is a stylesheet authoring tool that uses the Sass stylesheet language to make your stylesheets smaller and your web site easier to maintain. Compass provides ports of the best of breed css frameworks that you can use without forcing you to use their presentational class names. It’s a new way of thinking about stylesheets. -- 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/20100304205426.3194.64645.report...@lillypad.riseup.net
Bug#572586: ITP: libruby-fssm -- keeps track via inotify the state paths and fires events when state changes
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libruby-fssm Version : 0.1.3 Upstream Author : Travis Tilley * URL : http://github.com/ttilley/fssm * License : MIT Programming Lang: Ruby Description : keeps track via inotify the state paths and fires events when state changes The File System State Monitor keeps track of the state of any number of paths and will fire events when said state changes (create/update/delete). FSSM supports using Inotify on GNU/Linux. -- 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/20100304224533.6592.26814.report...@lillypad.riseup.net
Bug#572597: ITP: libffi-ruby -- ruby extension for loading dynamic libraries, binding functions, and calling those functions from ruby code
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libffi-ruby Version : 0.6.2 Upstream Author : Wayne Meissner * URL : http://wiki.github.com/ffi/ffi * License : MIT Programming Lang: Ruby, C Description : ruby extension for loading dynamic libraries, binding functions, and calling those functions from ruby code Ruby-FFI is a ruby extension for programmatically loading dynamic libraries, binding functions within them, and calling those functions from Ruby code. Moreover, a Ruby-FFI extension works without changes on Ruby and JRuby. Discover why should you write your next extension using Ruby-FFI here[http://wiki.github.com/ffi/ffi/why-use-ffi]. -- 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/20100305033920.1823.83828.report...@lillypad.riseup.net
Bug#572586: ITP: libruby-fssm -- keeps track via inotify the state paths and fires events when state changes
On Fri, 5 Mar 2010 09:40:10 +0100, Paul van Tilburg wrote: > On Thu, Mar 04, 2010 at 05:45:33PM -0500, Micah Anderson wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Micah Anderson > > > > * Package name: libruby-fssm > > Shouldn't this be libfssm-ruby (given that the lib/module is named fssm)? Er, yes. The ITP name was a mistake on my part, the package I have built is actually libfssm-ruby. :) micah pgpeM6ntySQ3g.pgp Description: PGP signature
Bug#572694: ITP: librb-inotify-ruby -- simple linux kernel inotify wrapper for monitoring file and directory changes
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: librb-inotify-ruby Version : 0.7.0 Upstream Author : Nathan Weizenbaum * URL : http://github.com/nex3/rb-inotify * License : MIT Programming Lang: Ruby Description : simple linux kernel inotify wrapper for monitoring file and directory changes This is a simple ruby wrapper over the inotify Linux kernel subsystem for monitoring changes to files and directories. It uses the FFI gem to avoid having to compile a C extension. -- 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/20100305183710.21118.47640.report...@lillypad.riseup.net
Bug#573874: ITP: compass-susy-plugin -- Susy is a elastic grid framework for Compass
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: compass-susy-plugin Version : 0.6.3 Upstream Author : Eric Meyer * URL : http://www.oddbird.net/susy/ * License : MIT Programming Lang: Ruby Description : Susy is a elastic grid framework for Compass Susy is a semantic CSS framework, entirely native to Compass. Susy is an elastic grid system that will never activate the side-scroll bar. With Susy you can build quick, custom grids that respond to the needs of the user without giving up design integrity. Susy sets your width on the outer element (container), adds a max-width of 100% and builds the rest of your grid in percentages. The philosophy and technique are based on Natalie Downe's "CSS Systems" - which introduces difficult math in the service of beautiful structure. Using simple mixins, columns can be created, suffixed, prefixed, and nested easily - and always in flexible percentages. -- 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/20100314163403.20393.2100.report...@algae.riseup.net
Bug#544338: tahoe and zfec
Hi! On Sun, 14 Mar 2010 23:49:28 +0100, Giovanni Mascellani wrote: > I'm interested in packaging tahoe-lafs and zfec for Debian. You opened > the ITP bugs for these two packages, but they seem to be quite inactive. > Are you still working on it? Thanks for writing about this. I have wanted to work on this, but have not been able to find the time. I have added Jacob to the CC list, because I have been speaking with him about working on these packages as well. > If not, I'd like to acquire the ownership of the bugs and go on for it. > I'd start from the Ubuntu packages, trying to make them suitable for Debian. Sure, I only care that they get packaged! > I never worked on Python packages, so this could take some time. Also, > I surely won't be able to work on it for at least the next week. Of > course I'm totally open to co-maintain these packages with others: for > instance, I'm not a DD (although I just started the NM process), so > Micah could help in getting the packages into the archive! My > preferred VCS is GIT, and I already maintain many packages on it. I know that Jacob is also interested in working on it too, so perhaps you can collaborate? I would be happy to help by sponsoring/reviewing your packages! Micah pgpON9fTXcitp.pgp Description: PGP signature
Bug#663101: [Pkg-puppet-devel] Bug#663101: RFP: foreman -- puppet dashboard and node classifier
On Thu, 08 Mar 2012 14:56:56 +0100, Laurent Bigonville wrote: > Package: wnpp > Severity: wishlist > > * Package name: foreman > Version : 0.4.2 > Upstream Author : Ohad Levy > Paul Kelly > * URL : http://theforeman.org/ > * License : GPL3 > Programming Lang: ruby (rails) > Description : puppet dashboard, external node classifier and more There is a package of foreman available from upstream, it works fairly well (although upgrades seem to have a problem with debconf). I'd suggest that someone might reach out to the upstream packager and work with them to sponsor it for Debian. micah -- 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/87aa3r15f8@algae.riseup.net
Bug#565308: mysql's security issues
Hi, I'm wondering if the recent security upgrade that we just had in Squeeze, which included not only unspecified and undisclosed vulnerabilities from upstream, but also a requirement to upgrade MySQL to a completely new upstream version would be the same situation with mariadb? micah -- 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/8762ef14yc@algae.riseup.net
Bug#646607: ITP: atheme-services -- modular IRC services daemon
On Mon, 19 Mar 2012 21:35:31 -0500, Mike Mestnik wrote: > http://mikemestnik.net/debian/atheme-services/ > > Fully usable package, needs mentor and upstream permission. I understood upstream has given permission for packaging, as noted in the bug report: "If you are planning to package Services for a package distribution, please stick to packaging only the longterm supported tree only. It will help us to ensure that your users are using software we still maintain. Thank you for your cooperation!" assuming this is the version you packaged, and there is no other issue, then I don't see why there needs to be permission, but perhaps you could detail that? micah -- 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/87mx7bnd8i@algae.riseup.net
Bug#439993: libapache2-mod-pubcookie: changing back RFP to ITP
retitle 439993 ITP: libapache2-mod-pubcookie -- apache2 module supporting Pubcookie authentication owner 439993 baner...@u.washington.edu thanks The package was finished, and an upload attempted, but there were some licensing issues that were pending resolution, namely: . a license review of the source code, filling out debian/copyright to account for everything . remove the embedded copy of openssl . if openssl is needed, is an openssl license exception required (as it is incompatable with apache 2.0 license)? . cgic carries a different license . there seems to be another copy of both cgic and pubcookie in src/contrib/index.cgi_ldap/pubcookie-uh-ldap.zip, that version of pubcookie seems to carry a different license. I'm not sure I understand the requirements of this license. Is it telling me that my webserver has to have a "credits" page? -- pgpistHBp4nTa.pgp Description: PGP signature
Bug#620821: upstream in NM
Hi, I think it would be great if the functionality of vpnautoconnect was integrated into NM upstream, probably Barraud's experience on vpnautoconnect would help quite a bit. However, until that is available in NM, the functionality that vpnautoconnect provides is very useful, especially in absense of anything else that provides this. I would be happy to review and sponsor this package, and when the author has determined it has become obsolete, then we can remove it. Until then, it seems useful to include. micah -- pgpmQtRHvioGL.pgp Description: PGP signature
Bug#246424: RFP: bittornado -- Bittorrent client featuring enhanced gui, curses mode and advanced features that the existing bittorrent package is lacking
Package: wnpp Severity: wishlist * Package name: bittornado Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Bittorrent client featuring enhanced gui, curses mode and advanced features that the existing bittorrent package is lacking BitTornado is the next generation bittorrent client that was build on the original BitTorrent. This client features an enhanced GUI and console/curses mode, lots of new features under the hood, and is generally one of the most advanced clients out there. Get this if you need to limit your bandwidth, or you want more control of your torrents. Its python and does everything the original bittorrent does, plus more... -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=C, LC_CTYPE=C
Bug#253389: RFP: maia-mailguard -- Maia Mailguard is a web-based interface and management system for the popular AMaViS e-mail scanner.
Package: wnpp Severity: wishlist * Package name: maia-mailguard Version : Version 1.0.0 RC3 Upstream Author : Robert Lablanc <[EMAIL PROTECTED]> * URL : http://www.renaissoft.com/projects/maia/ * License : MAIA MAILGUARD LICENSE Description : Maia Mailguard is a web-based interface and management system for the popular AMaViS e-mail scanner. Maia Mailguard is a web-based interface and management system for the popular AMaViS e-mail scanner. Written in Perl and PHP, Maia Mailguard gives end-users control over how their mail is processed by virus scanners and spam filters, while giving mail administrators the power to configure site-wide defaults and limits. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=C, LC_CTYPE=C
Bug#253464: RFP: rulesdujour -- RulesDuJour is a bash script intended to automatically download new versions of SpamAssassin rulesets as the authors release new versions.
Package: wnpp Severity: wishlist * Package name: rulesdujour Version : 1.14 Upstream Author : Chris Thielen <[EMAIL PROTECTED]> * URL : http://www.exit0.us/index.php/RulesDuJour * License : Unlicensed Description : RulesDuJour is a bash script intended to automatically download new versions of SpamAssassin rulesets as the authors release new versions. RulesDuJour eases the maintenance of rapidly changing SpamAssassin rulesets by downloading and installing them either interactively, or on a schedule. Scheduling is achieved via the standard unix cron. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.6 Locale: LANG=C, LC_CTYPE=C
Bug#237716: Whats the status?
Hello, Last I heard Wesley was going to wait a "week or so" before deciding that the ITP has expired and you'd package this yourself. That was Wed, 5 May 2004 21:25:13 +0200 ... I'm quite curious to know whats going on with this? While I do not want to discourage your grand plans Wesley, it seems like it would be rather trivial to simply package the cryptsetup binary instead of going through changing a lot of things? I personally would be thrilled to have them, but just getting the binary out there would be nice too. (However, I should note that a perfectly compatable cryptsetup is available in the hashalot package, but this is based on the bash script, which I believe is being deprecated in favor of the C program). Micah
Bug#253464: RFP: rulesdujour -- RulesDuJour is a bash script intended to automatically download new versions of SpamAssassin rulesets as the author s release new versions.
I can't for the life of me figure out why this response, nor my report to spamassassin never seemed to make it in to the BTS, so I am resending it (originally sent Jun 9th): On Tue, 15 Jun 2004, Niklas Vainio wrote: > Hello, > > On Wed, Jun 09, 2004 at 11:00:13AM -0500, Micah Anderson wrote: > > * Package name: rulesdujour > > How about naming it spamassassin-rulesdujour (for clarity) or asking the > Spamassassin maintainer to include it in the Spamassassin package? A fine idea, I will submit a wishlist bug on spamassassin and then merge this bug with that one, or is there a better way to do that? > > * License : Unlicensed > > Please get a confirmation about the license, please. I was trying to locate the author, and I finally got him (his obfuscated email address was pretty obfuscated). I asked about the license, he replied (see below) that GPL was fine with him. Subject: Re: Rules DuJour From: Chris Thielen <[EMAIL PROTECTED]> To: Micah Anderson <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signa ture"; boundary="=-l573hX/X7Oo2iy/uQynt" Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 10 Jun 2004 09:52:58 -0500 X-Bogosity: No, tests=bogofilter, spamicity=0.050506, version=0.13.7.2 Status: RO X-Status: A Content-Length: 1605 --=-l573hX/X7Oo2iy/uQynt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-06-09 at 20:17, Micah Anderson wrote: > Hi, > I am not really sure which address is yours, but I'm trying a couple > to see if I get one of them through :) This address works :) > Are you the author of the current Rules du Jour? I'm thinking of > packaging it for Debian, and need to attribute it and apply a proper > license to it, but I can't really find one on the wiki. Yes, I'm the author. I haven't assigned a license to RDJ yet but GPL is fine for me. A Debian package... cool :) I'm an avid Debian user myself but don't know jack about making packages. Some things to consider: - Built-in auto-updating of the script should be disabled or enabled? - It would probably make more sense to use a config file in /etc/ instead of the my_rules_du_jour wrapper.
Bug#253464: Passing on a RFP for RulesDuJour
reassign 253464 spamassassin thanks It was suggested that this RFP be passed to the spamassassin package as a wishlist to see if you'd consider bundling it with the package. If not, please reassign the bug back to the WNPP RFP queue. Thanks, micah
Bug#578157: and another!
On Mon, 13 Dec 2010 14:55:18 +0100, Jonas Smedegaard wrote: > Thanks for the encouragements, everyone! Go Jonas go!! Maybe we can send you some bitcoins in thanks :) micah pgpeQOKV58bNj.pgp Description: PGP signature
Bug#578157: and another!
On Mon, 13 Dec 2010 14:55:18 +0100, Jonas Smedegaard wrote: > On Sat, Dec 11, 2010 at 08:48:46PM -0500, micah wrote: > > > >> Also I noticed that upstream released 0.3.17 this week. > > > >And it looks like 0.3.18 is now there... > > > >Jumping on the bandwagon here, but without any time myself to help in > >the packaging effort :P > > Package json-spirit now uploaded to NEW queue targeted unstable. > > Package bitcoin now updated to upstream 0.3.18 release. Still needs a > few adjustments to compile - and anyway awaits ftpmaster approval of > json-spirit. > > Thanks for the encouragements, everyone! Looks like there is an Ubuntu PPA for bitcoin, version 0.3.19 is up now with builds for maverick and lucid: https://launchpad.net/~stretch/+archive/bitcoin One thing I've noted is that upstream is moving quite fast, bitcoin is in beta and sometimes there are frequent releases. So, it might require relatively quick turn over in packaging. Do you have a repository somewhere with any work done thus far? I've tried out the cli for a while and it seems like a worthwhile package to make without the gui bits. micah pgpHAodzSnbTT.pgp Description: PGP signature
Bug#578157: and another!
On Thu, 6 Jan 2011 17:45:57 +0100, Jonas Smedegaard wrote: > On Thu, Jan 06, 2011 at 04:46:30PM +0100, Jonas Smedegaard wrote: > >On Thu, Jan 06, 2011 at 10:33:35AM -0500, micah anderson wrote: > >>Do you have a repository somewhere with any work done thus far? > >>I've tried out the cli for a while and it seems like a worthwhile > >>package to make without the gui bits. > > > >Sorry - I thought the news was already filed here in the bugreport: > > > >The final official packaging was uploaded ultimo december, now > >awaiting ftpmaster approval: > >http://ftp-master.debian.org/new/bitcoin_0.3.19~dfsg-2.html > > > > > >It is also unofficially available using this APT line: > > > > deb http://debian.jones.dk/ unstable freedombox Great! I noticed that you are build-depending on libdb4.7++, I dont know that much about the bdb madness, but I do know that the bitcoin that I compiled from source was compiled against libdb4.8++ and when I try and install your packaged version, it can't read the wallet database. Is there any specific reason you went with 4.7 instead of 4.8, or was it just what your build environment had? My guess is that it would be best to switch to 4.8 right away, before this is accepted into Debian, because the transition from 4.7 to 4.8 is not going to be trivial (although, in theory... nuking the transaction logs, and removing the database environment will make it work, it will be a pain and somewhat scary for people's wallets). micah pgpUny0xu902E.pgp Description: PGP signature
Bug#578157: and another!
On Fri, 7 Jan 2011 17:02:20 +0100, Jonas Smedegaard wrote: > On Fri, Jan 07, 2011 at 10:39:11AM -0500, micah anderson wrote: > >I noticed that you are build-depending on libdb4.7++, I dont know that > >much about the bdb madness, but I do know that the bitcoin that I > >compiled from source was compiled against libdb4.8++ and when I try and > >install your packaged version, it can't read the wallet database. > > > >Is there any specific reason you went with 4.7 instead of 4.8, > > Yes. > > src/build-unix.txt includes this note: > > >You need Berkeley DB 4.7. Don't use 4.8, the database/log* files > >are incompatible. This is interesting... I am using DB 4.8 just fine. I suspect that this build-unix.txt is out of date, or just wrong. The database/log files are just transaction logs, and while it is true that they are incompatible, this is normal for ABI differences between berkeley db versions. > > Helmuth Grohne, showing up on IRC just before I released the > packaging, claims this might actually be a reason to run away > screaming from Bitcoin, as it indicates a disastrous design flaw in > relying on the network API on the internal BDB format of > (little-endian!) v4.7. talking about irc gave me an idea. I stopped over to #bitcoin-dev, and asked them what the deal was: 11:46:01 < hacim> i noticed in src/build-unix.txt, it says to use Berkeley DB 4.7 11:46:10 < hacim> "You need Berkeley DB 4.7. Don't use 4.8, the database/log* files are incompatible" 11:46:15 < hacim> however, I'm using 4.8 just fine... 11:46:15 < ArtForz> yes, use bdb 4.7 11:46:33 < ArtForz> well, now your DB is auto-upgraded to 4.8 11:46:42 < hacim> the database/log* files are just transaction logs 11:46:51 < ArtForz> = 4.7 can't read it anymore 11:47:01 < hacim> they are of course incompatible with 4.7, this is the definition of the ABI change :) 11:47:13 < gavinandresen> As long as you don't reinstall a precompiled bitcoin you'll be fine. 11:47:23 < ArtForz> yep 11:48:03 < hacim> ok, so there is nothing about the 4.7 libraries, such as relying on the network API in the internal bdb format of little-endian 4.7? 11:48:10 < ArtForz> nope 11:48:29 < ArtForz> it's just that 4.8 isnt backwards compatible with 4.7 and binary builds use 4.7 11:48:31 < hacim> so, for new installs, why would one chose to use 4.7, when you will need to upgrade anyways? 11:48:48 < hacim> eventually those binary builds will need to use 4.8, and people will have to transition 11:48:54 < ArtForz> why? 11:49:04 < hacim> if the history of bdb is to be any indicator of the future... 11:49:13 < ArtForz> so far the binary builds are 4.7, so going to selfcompiled w/ 4.8 is a one-way street 11:49:14 < hacim> do you know anyone using bdb4.1? 11:49:52 < ArtForz> when binary build switches to 4.8, recommended version for compiling will switch to 4.8 (duh) 11:49:59 < hacim> why would anyone want to use 4.7 right now is beyond me 11:50:14 < ArtForz> no one WANTS to, everyone using a precompiled binary HAS to 11:50:20 < hacim> ArtForz: the 'binary build' meaning the binaries offered on the website? 11:50:56 < gavinandresen> hacim: you want to volunteer to organize an effort to make sure 4.8 is supported on windows mac and all the linux flavors people are using? 11:52:59 < hacim> gavinandresen: it works fine on three different linux flavors that I've tried this morning 11:53:07 < gavinandresen> hacim: or, to say it another way: bitcoin uses 4.7 because two years ago that is what Satoshi decided to use, and nobody has put in the effort needed to upgrade. It just hasn't been a priority. 11:53:32 < gavinandresen> hacim: great! so create a patch and recruit some people to see if it works on mac and windows. 11:53:32 < hacim> gavinandresen: it doesn't bother me that other people use 4.7 so it seems there is no particular reason to use 4.7, its just what their pre-compiled binary versions use, and the only reason that they dont move to 4.8 is because nobody has bothered to try it on mac and windows. As a test, I backed up my .bitcoin/ and then ran your version, with libdb4.7++ and start it up. It creates a wallet and I let it download all the current blocks. I then stop it, run a self-compiled bitcoin, linked against libdb4.8++, it converts the database to 4.8 format, and things continue to work as normal. micah pgpQhZEsQk9ol.pgp Description: PGP signature
Bug#607322: Adopting the package
Hi Evandro, If you are interested in adopting the package, you simply have to follow this: http://www.debian.org/devel/wnpp/#howto-o If you are not a Debian Developer, I'd be happy to sponsor your packages. micah -- pgpvd80FXe9d1.pgp Description: PGP signature
Bug#563951: [Pkg-puppet-devel] MCollective Debian packages
Hi Jonas, On Mon, 25 Jul 2011 22:40:24 +0200, Jonas Genannt wrote: > after ActiveMQ is included into Debian and the Bug #634868 is fixed, > MCollective can enter Debian. > > I have prepared new packages for Debian. Great! > Puppet and MCollective has got the same Upstream and used every often > together. > > I think the best would be, if the MCollective packages are maintained > within the Puppet Pkg Group. > > Would do you think? I think that this would be a good idea. > If you create an new git repro within the pkg-puppet Group I can > provide you my MCollective packages. I created an activemq.git within the pkg-puppet group, I believe that you want to follow this to push: http://wiki.debian.org/Alioth/Git#Initial_push micah pgp81ZmbKqH1V.pgp Description: PGP signature
Bug#563951: [Pkg-puppet-devel] MCollective Debian packages
On Wed, 17 Aug 2011 12:29:45 -0400, micah anderson wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > > Hello! > > On Tue, 16 Aug 2011 19:13:47 +0200, Jonas Genannt > wrote: > > the MCollective packages are now ready. > > Great! > > > The MCollective package is lintian clean, except for some warnings > > about no manpages for binaries. > > > > Could any DD please check my packages? > > I'll look them over and confirm that they work. I notice that the README.Debian reads: In Debian you can simply install `activemq` package. You can find an working configuration for activemq in the examples directory. but there is no 'activemq' package in debian... also perhaps the package should Suggest that? micah pgph0bjkGHvQ6.pgp Description: PGP signature
Bug#563951: [Pkg-puppet-devel] MCollective Debian packages
Hello! On Tue, 16 Aug 2011 19:13:47 +0200, Jonas Genannt wrote: > the MCollective packages are now ready. Great! > The MCollective package is lintian clean, except for some warnings > about no manpages for binaries. > > Could any DD please check my packages? I'll look them over and confirm that they work. micah pgpG8grJQCQAV.pgp Description: PGP signature
Bug#710464: ITP: python-scrypt -- Python bindings for the scrypt key derivation function library
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-scrypt Version : 0.5.3 Upstream Author : Magnus Hallin * URL : http://bitbucket.org/mhallin/py-scrypt * License : BSD Programming Lang: Python Description : Python bindings for the scrypt key derivation function library This is a set of Python bindings for the scrypt key derivation function. . Scrypt is useful when encrypting password as it is possible to specify a minimum amount of time to use when encrypting and decrypting. If, for example, a password takes 0.05 seconds to verify, a user won't notice the slight delay when signing in, but doing a brute force search of several billion passwords will take a considerable amount of time. This is in contrast to more traditional hash functions such as MD5 or the SHA family which can be implemented extremely fast on cheap hardware. -- 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/20130531015921.29433.70885.report...@muck.riseup.net
Bug#713913: ITP: libscrypt -- scrypt shared library.
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: libscrypt Version : stable1 Upstream Author : Joshua Small * URL : http://www.lolware.net/libscrypt.html * License : Upstream still deciding Programming Lang: C Description : scrypt shared library. Scrypt shared library, implementing the reference implementation of the scrypt binary. -- 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/20130623200838.29179.13209.report...@muck.riseup.net
Bug#720577: ITP: python-qt4reactor -- Provides support for Twisted to be driven by the Qt mainloop
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-qt4reactor Version : 1.0 Upstream Author : Michael Terry * URL : https://github.com/ghtdak/qtreactor * License : Expat Programming Lang: Python Description : Twisted Qt4 integration This package provides support for Twisted to be driven by the Qt mainloop -- 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/20130823125630.23442.68432.report...@muck.riseup.net
Bug#578157: and another!
On Fri, 7 Jan 2011 20:17:29 +0100, Jonas Smedegaard wrote:
> On Fri, Jan 07, 2011 at 12:06:37PM -0500, micah anderson wrote:
> >On Fri, 7 Jan 2011 17:02:20 +0100, Jonas Smedegaard
> >wrote:
> >> On Fri, Jan 07, 2011 at 10:39:11AM -0500, micah anderson wrote:
> >> >I noticed that you are build-depending on libdb4.7++, I dont know
> >> >that much about the bdb madness, but I do know that the bitcoin that
> >> >I compiled from source was compiled against libdb4.8++ and when I
> >> >try and install your packaged version, it can't read the wallet
> >> >database.
> >> >
> >> >Is there any specific reason you went with 4.7 instead of 4.8,
> >>
> >> Yes.
> >>
> >> src/build-unix.txt includes this note:
> >>
> >> >You need Berkeley DB 4.7. Don't use 4.8, the database/log*
> >> >files are incompatible.
> >
> >This is interesting... I am using DB 4.8 just fine. I suspect that this
> >build-unix.txt is out of date, or just wrong. The database/log
> >files are just transaction logs, and while it is true that they are
> >incompatible, this is normal for ABI differences between berkeley db
> >versions.
> >
> >
> >>
> >> Helmuth Grohne, showing up on IRC just before I released the
> >> packaging, claims this might actually be a reason to run away
> >> screaming from Bitcoin, as it indicates a disastrous design flaw in
> >> relying on the network API on the internal BDB format of
> >> (little-endian!) v4.7.
> >
> >talking about irc gave me an idea. I stopped over to #bitcoin-dev, and
> >asked them what the deal was:
> [IRC conversation snipped]
> >so it seems there is no particular reason to use 4.7, its just what
> >their pre-compiled binary versions use, and the only reason that they
> >dont move to 4.8 is because nobody has bothered to try it on mac and
> >windows.
> >
> >As a test, I backed up my .bitcoin/ and then ran your version, with
> >libdb4.7++ and start it up. It creates a wallet and I let it download
> >all the current blocks. I then stop it, run a self-compiled bitcoin,
> >linked against libdb4.8++, it converts the database to 4.8 format, and
> >things continue to work as normal.
>
> Thanks a lot for your investigation!
>
> So what really is the issue here is that _at_ _each_ _runtime_
> _environment_ are the db files incompatible.
http://download.oracle.com/docs/cd/E17276_01/html/programmer_reference/changelog_4_8.html#id1655659
Database or Log File On-Disk Format Changes:
1. The log file format changed in 4.8.
So it seems that its just the db4.8 logs are not backward compatible
with 4.7. Transaction logs are great, if you want to do recovery, but I
wonder if they are really needed. If I recall, they simply grow, until
you rotate them, unless you set specific DB_CONFIG flags.
> @Micah: Could you please test if upgrading works like this:
>
>1) Move aside your precious .bitcoin folder
>2) Start the current Debian Bitcoin (or upstream binary)
>3) Let Bitcoin run until its db is fully init'ed (i.e. dir is ~150MB)
>3) Quit Bitcoin
>4) Install packages libdb4.8-util and db4.7-util
you mean db4.8-util and db4.7-util :)
>5) run the following commands:
I think that the following commands should only be run after I've
stopped the running bitcoind:
> db4.7_recover -h ~/.bitcoin
> db4.8_upgrade -h ~/.bitcoin wallet.dat
>
>6) Start your locally compiled Bitcoin
>7) Tell me if it worked out or not :-)
It seems like it works, here is the log:
mi...@algae:~$ mv .bitcoin/ .bitcoin_bak
mi...@algae:~$ /usr/bin/bitcoind
bitcoin server starting
mi...@algae:~$ Warning: To use bitcoind, you must set rpcpassword=
in the configuration file: /home/micah/.bitcoin/bitcoin.conf
If the file does not exist, create it with owner-readable-only file permissions.
mi...@algae:~$ cp .bitcoin_bak/bitcoin.conf .bitcoin
mi...@algae:~$ /usr/bin/bitcoind
bitcoin server starting
...
mi...@algae:~$ du -sch .bitcoin
168M.bitcoin
168Mtotal
mi...@algae:~$ /usr/bin/bitcoind stop
mi...@algae:~$ db4.7_recover -h ~/.bitcoin
mi...@algae:~$ db4.8_upgrade -h ~/.bitcoin wallet.dat
mi...@algae:~$ working/bitcoin-0.3.18/src/bitcoind
bitcoin server starting
mi...@algae:~$ working/bitcoin-0.3.18/src/bitcoind getinfo
{
"version" : 31800,
"balance" : 0.,
"blocks" : 75297,
"connections" : 9,
"proxy" : "",
"generate" : false,
"genproclimit" : -1,
"difficulty" : 511.77353426,
"hashespersec" : 0,
Bug#578157: and another!
On Mon, 10 Jan 2011 09:46:29 +0100, Jonas Smedegaard wrote: > On Mon, Jan 10, 2011 at 12:54:58AM -0500, micah anderson wrote: > >On Fri, 7 Jan 2011 20:17:29 +0100, Jonas Smedegaard > >wrote: > >> So what really is the issue here is that _at_ _each_ _runtime_ > >> _environment_ are the db files incompatible. > > > >http://download.oracle.com/docs/cd/E17276_01/html/programmer_reference/changelog_4_8.html#id1655659 > > > >Database or Log File On-Disk Format Changes: > > > > 1. The log file format changed in 4.8. > > > >So it seems that its just the db4.8 logs are not backward compatible > >with 4.7. Transaction logs are great, if you want to do recovery, but I > >wonder if they are really needed. If I recall, they simply grow, until > >you rotate them, unless you set specific DB_CONFIG flags. > > According to Helmut Grohne, all Bitcoin users maintain a full history of > transactions in those logs - so I suspect they shouldn't be rotated but > just (slowly) grow and grow... Well sure, that is because they are transaction logs and every database operation is written to the logs. That is the definition of database transaction logs... it is nothing particularly unique to bitcoin. Berkeley DB (and other databases, when configured to do so) produces transaction logs that can be used to reconstruct changes from a given point in time. It is true that bitcoin maintains a full history of all bitcoin operations (if I used the word 'transactions' here, it would be confusing because 'transactions' as also a database term, that history is maintained in the database itself. > >> @Micah: Could you please test if upgrading works like this: > >> > >>1) Move aside your precious .bitcoin folder > >>2) Start the current Debian Bitcoin (or upstream binary) > >>3) Let Bitcoin run until its db is fully init'ed (i.e. dir is > >> ~150MB) > >>3) Quit Bitcoin > >>4) Install packages libdb4.8-util and db4.7-util > > > >you mean db4.8-util and db4.7-util :) > > Ah, yes. Had crept into README.Debian too - corrected now. > > > >>5) run the following commands: > > > >I think that the following commands should only be run after I've > >stopped the running bitcoind: > > That happened in 3), no? Yes, it did! What didn't happen was you numbered 3 twice, and so my brain skipped the "3) Quit Bitcoin" and thought it didn't exist because it had already done "3) Let Bitcoin run until its db is fully init'ed (i.e. dir is ~150MB)" and iterated to the next number :) It took me a good 5 minutes to realize that. Good morning. > Any, I am not this detailed in the readme (and not sure why I spelled it > out to you either - you seem to know usage of this tool better than > me!). I'm not sure I know it better, I just maybe know different parts better, and you know other parts better. thanks for the libdb4.8++ upload, i upgraded to that version and everything works fine! micah pgp4ztGwtqVQc.pgp Description: PGP signature
Bug#578157: and another!
On Mon, 10 Jan 2011 16:13:13 +0100, Jonas Smedegaard wrote: > On Mon, Jan 10, 2011 at 09:48:06AM -0500, micah anderson wrote: > >On Mon, 10 Jan 2011 09:46:29 +0100, Jonas Smedegaard > >wrote: > >> On Mon, Jan 10, 2011 at 12:54:58AM -0500, micah anderson wrote: > >> >On Fri, 7 Jan 2011 20:17:29 +0100, Jonas Smedegaard > >> >wrote: > >> >> So what really is the issue here is that _at_ _each_ _runtime_ > >> >> _environment_ are the db files incompatible. > >> > > >> >http://download.oracle.com/docs/cd/E17276_01/html/programmer_reference/changelog_4_8.html#id1655659 > >> > > >> >Database or Log File On-Disk Format Changes: > >> > > >> > 1. The log file format changed in 4.8. > >> > > >> >So it seems that its just the db4.8 logs are not backward compatible > >> >with 4.7. Transaction logs are great, if you want to do recovery, > >> >but I wonder if they are really needed. If I recall, they simply > >> >grow, until you rotate them, unless you set specific DB_CONFIG > >> >flags. > >> > >> According to Helmut Grohne, all Bitcoin users maintain a full history > >> of transactions in those logs - so I suspect they shouldn't be > >> rotated but just (slowly) grow and grow... > > > >Well sure, that is because they are transaction logs and every database > >operation is written to the logs. That is the definition of database > >transaction logs... it is nothing particularly unique to bitcoin. > >Berkeley DB (and other databases, when configured to do so) produces > >transaction logs that can be used to reconstruct changes from a given > >point in time. > > You wrote "wonder if they are really needed." > > What I meant to say was that according to Helmut Grohne, each and every > Bitcoin user _must_ maintain a full history. Yep, that is true. > >It is true that bitcoin maintains a full history of all bitcoin > >operations (if I used the word 'transactions' here, it would be > >confusing because 'transactions' as also a database term, that history > >is maintained in the database itself. > > So, what was the point again? That the storage format need not be in > log format? The storage format is the database. The logs are database transaction logs. You get those transaction logs with *every* berkeley db implementation with every software that uses them. In fact, I dont know a database implementation that doesn't have transaction log capability (http://en.wikipedia.org/wiki/Transaction_log). A database transaction log (also commonly called a binary log) is just a record of every operation that has happened on the database. They are not unique to bitcoin at all. Database transaction logs are there in the case of crash, you can do a restore by replaying the logs. Bitcoin stores inside the *database* the entire history of all bitcoin operations. The fact that database transaction logs are on just means that the entire history of all database operations, (which, incidentally aren't exclusively bitcoin trades between users), is also written to the transaction logs. > As I understand it, the log format is used only when bootstrapping via > IRC, but I really don't know these details. No, the database transaction logs are a property of databases, and are not unique to bitcoin at all. The bootstrap via IRC basically does this: 1. uses a hard-coded address in the source to connect 2. gets p2p info and blocks from other nodes on irc 3. writes the acquired info into the database It just so happens that the way database writes are done is by doing this: a. writing to the database log file what exactly is going to be written to the disk, once that has been committed to hard storage it then... b. does the database operation databases do this because if there is a crash, the database may not have properly flushed to the disk 30 different database operations, so they never were written... but there is storage of the log which has all the changes that should be there, so those are replayed. as that wikipedia page says: If, after a start, the database is found in an inconsistent state or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions. Additionally, all transactions that are already committed but whose changes were not yet materialized in the database are re-applied. Both are done to ensure atomicity and durability of transactions. > Helmut Grohne seemed to know - he mentioned having reverse-engineerd the > protocol and reimplemented in Python. I tried to persuade hime to join > me in maintaining Bitcoin - until his own implementation perhaps would > eventually mature and be superior. No luck, unfortunately. :-( haha, awesome, would be nice to have it in python. pgpFflp355s9K.pgp Description: PGP signature
Bug#578157: and another!
On Mon, 10 Jan 2011 21:31:39 +0100, Jonas Smedegaard wrote:
> On Mon, Jan 10, 2011 at 02:15:17PM -0500, micah anderson wrote:
> >>>> On Mon, Jan 10, 2011 at 12:54:58AM -0500, micah anderson wrote:
> >>>>>Transaction logs are great, if you want to do recovery, but I
> >>>>>wonder if they are really needed. If I recall, they simply grow,
> >>>>>until you rotate them, unless you set specific DB_CONFIG flags.
>
> >Database transaction logs are there in the case of crash, you can do a
> >restore by replaying the logs.
> >
> >Bitcoin stores inside the *database* the entire history of all bitcoin
> >operations. The fact that database transaction logs are on just means
> >that the entire history of all database operations, (which,
> >incidentally aren't exclusively bitcoin trades between users), is also
> >written to the transaction logs.
>
> Ok. I think I get it now. Thanks for clarifying.
>
> I consider adding a shell wrapper looking something like this:
>
> set -e
> umask=077
> basedir=~/.bitcoin
> dbfile="$basedir/DB_CONFIG"
> cfgfile="$basedir/bitcoin.conf"
> [ -d ~/.bitcoin ] || mkdir ~/.bitcoin
> [ -e "$dbfile" ] || echo 'set_flags DB_LOG_AUTOREMOVE' > "$dbfile"
the above scares me a little, because someone might have put their own
db config into their DB_CONFIG, and the above would overwrite it,
everytime they start the daemon.
> [ -e "$cfgfile" ] || perl -le
> 'print"rpcpassword=",map{(a..z,A..Z,0..9)[rand 62]}0..9' > "$cfgfile"
nice, but again, wont this run each time bitcoind is started, thus
making a new rpcpassword every time?
For fun, I just committed a few things to the collab-maint repository:
. examples/bitcoin.conf
. bitcoind(1) and bitcoin.conf(5) man pages
but I am not so sure what the right way to install the man pages are,
maybe cdbs does it magically? Check it out and please correct it if its
wrong.
micah
pgpC49GMbFgra.pgp
Description: PGP signature
Bug#578157: and another!
On Mon, 17 Jan 2011 10:50:25 +0100, Jonas Smedegaard wrote:
> On Mon, Jan 17, 2011 at 12:03:53AM -0500, micah anderson wrote:
> >On Mon, 10 Jan 2011 21:31:39 +0100, Jonas Smedegaard wrote:
> >> I consider adding a shell wrapper looking something like this:
> >>
> >> set -e
> >> umask=077
> >> basedir=~/.bitcoin
> >> dbfile="$basedir/DB_CONFIG"
> >> cfgfile="$basedir/bitcoin.conf"
> >> [ -d ~/.bitcoin ] || mkdir ~/.bitcoin
> >> [ -e "$dbfile" ] || echo 'set_flags DB_LOG_AUTOREMOVE' > "$dbfile"
> >
> >the above scares me a little, because someone might have put their own
> >db config into their DB_CONFIG, and the above would overwrite it,
> >everytime they start the daemon.
> >
> >> [ -e "$cfgfile" ] || perl -le
> >> 'print"rpcpassword=",map{(a..z,A..Z,0..9)[rand 62]}0..9' > "$cfgfile"
> >
> >nice, but again, wont this run each time bitcoind is started, thus
> >making a new rpcpassword every time?
>
> The frontmost [] means "test for this, and if not, then...".
Of course, I read that wrong!
> Does it still scare you?
No, I am not frightened now that I am no longer ignorant!
> >For fun, I just committed a few things to the collab-maint repository:
> >. examples/bitcoin.conf
> >. bitcoind(1) and bitcoin.conf(5) man pages
> >
> >but I am not so sure what the right way to install the man pages are,
> >maybe cdbs does it magically? Check it out and please correct it if its
> >wrong.
>
> Nice!
>
> Did you hardcode the manpages or generate (at least the bitcoind one)
> using help2man?
Well, I used help2man to give me a template, but it wasn't very good, so
I mostly did manual work on it.
> Oh well, I'll have a look at it.
>
> Oh, and please pretty please add your name as uploader. I would looove
> this to be a teamwork between us - even if you might go busy on me for
> years at a time ;-)
Will do.
m
pgpyg5pPYIIKc.pgp
Description: PGP signature
Bug#333756: Taking Roundcube ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil McGovern wrote: > On Sat, Feb 10, 2007 at 09:02:31AM +0100, Vincent Bernat wrote: >> Without any activity on this ITP since more than one year, I take it >> over. Neil, if you finally do not agree, take the ITP back. > > Fine by me, it seems I *don't* actually have enough time to look at > this. Thanks for taking care of it :) > > Neil Just a word of caution -- roundcube is still very buggy, I've tried the latest checkouts over the last few months and although it looks nice, I think the upstream developer has been overwhelmed by everyone wanting all kinds of things, this has delayed an official stable release significantly. Although I think a package of roundcube could be nice, I know I would not install it until it has stabilized more, and you might be wary of becoming a bug catcher... micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFzgsj9n4qXRzy1ioRAtiyAKCfOqZvmctoHYqNJS9k8A30J/1boQCgjUKK bYZT8JQ0Y9Rs43u/zvEH2u4= =Vx7B -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#609883: Status?
Hi Nicholas, I'm inquiring as to the status of the packaging of percona-server-core that you took on as an ITP for the Debian Mysql packaging team. I haven't seen an update to this bug for some time now and figured it was time for a ping. thanks! micah -- -- 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/87fw08pbwr@minnow.riseup.net
Bug#707620: ITP: python-dirspec -- Python User Folders Specification Library
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: python-dirspec Version : 4.2.0 Upstream Author : Canonical Ltd. * URL : https://launchpad.net/dirspec * License : LGPL-3 Programming Lang: Python Description : Python User Folders Specification Library A library for handling the XDG Base Directory specification, and the XDG User Directories for music, videos, etc… -- 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/20130509155316.12651.46511.report...@muck.riseup.net
Bug#707625: ITP: u1db -- Ubuntu One structured data storage - Python API
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: u1db Version : 0.1.4 Upstream Author : Canonical Ltd * URL : https://launchpad.net/u1db * License : LGPL-3 Programming Lang: Python, C Description : Ubuntu One structured data storage - Python API U1DB is a database API for synchronised databases of JSON documents. It’s simple to use in applications, and allows apps to store documents and synchronise them between machines and devices. U1DB itself is not a database: instead, it’s an API which can be backed by any database for storage. This means that you can use U1DB on different platforms, from different languages, and backed on to different databases, and sync between all of them. It's built to sync with your own servers or with Ubuntu One. -- 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/20130509183819.15506.65409.report...@muck.riseup.net
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Apollon Oikonomopoulos writes: > On 09:29 Thu 02 Feb , micah wrote: >> Apollon Oikonomopoulos writes: >> >> ... >> > - As soon as 4.8.2-1 enters testing, I intend to upload 4.8.2-2, with >> >the following changes: >> ... >> >It will go through NEW for puppet-terminus-puppetdb, vim-puppet and >> >puppet-el, but there should be no problems here. >> >> According to the release page[0]: >> >> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day migrations) >> >> Doesn't that mean that this package wont be able to make it through NEW? > > It will go through NEW (unstable is not affected by the freeze). Also > the "no new packages" stuff actually means "no new source packages in > testing". Ah, I didn't realize this subtle difference. > I know it's a bit late (but not too late), but I think we should have a > shot with the release team. The change is not that big and it will not > break existing systems anyway. I think so too - especially considering DSA uses puppet with storedconfigs. micah
Bug#919945: License clarification resolved
The unclear license situation has been resolved by upstream. I believe that removes the remaining blocker for this package to be put into the archive. -- micah
Bug#919944: License clarification resolved
The unclear license on this package was resolved by upstream. I believe that this can be packaged now. -- micah
Bug#919937: status update
Antoine Beaupré writes: > We've processed a bunch of the dependencies for this, and uploaded some > to NEW (with related git repos in salsa). Some are not done yet, mostly > because their license is unclear. The packages indicated in this table as having unclear licenses have had that issue resolved, so those packages can be built now.
