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.
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#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#919943: ITP: golang-github-getlantern-systray -- a cross platfrom Go library to place an icon and menu in the notification area
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: golang-github-getlantern-systray Version : 0.0~git20181206.eaad711-1 Upstream Author : Lantern * URL : https://github.com/getlantern/systray * License : Apache-2.0 Programming Lang: Go Description : a cross platfrom Go library to place an icon and menu in the notification area Package systray is a cross platfrom Go library to place an icon and menu in the notification area. . This is a dependency for the riseup-vpn ITP (#919937)
Bug#919937: ITP: riseup-vpn -- Minimal, easy to use vpn client
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: riseup-vpn Version : 0.18.12 Upstream Author : LEAP Encryption Access Project * URL : https://0xacab.org/leap/bitmask-vpn * License : GPLv3 Programming Lang: Go Description : Minimal, easy to use VPN client A minimalistic implementation, written in golang, of Bitmask VPN. The only User Interface is a small systray icon. This provides simple setup for VPN service through Riseup. -- micah
Bug#919935: ITP: golang-github-protonmail-go-autostart -- A Go library to run a command after login
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: golang-github-protonmail-go-autostart Version : 0.0~git20181114.c527205-1 Upstream Author : * URL : https://github.com/ProtonMail/go-autostart * License : MIT Programming Lang: Go Description : A Go library to run a command after login A Go library to run a command after login. This is a dependency for the package riseupvpn that is also being packaged.
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
intrigeri <intrig...@debian.org> writes: > Hi, > > micah: >> Apollon Oikonomopoulos <apoi...@debian.org> writes: >>>> On the master, I see nothing in the puppet logs, but I do see in the >>>> apache logs: >>>> >>>> newpuppetmaster:8140 0.0.0.0 - - [03/Feb/2017:08:41:30 -0800] "GET >>>> /production/certificate/puppetdb? HTTP/1.1" 404 5361 "-" "Ruby" >>>> >>>> but nothing else. The puppetmaster has no certs pending to be signed and >>>> only has one cert signed (the puppetmaster itself). There is nothing in >>>> /var/lib/puppet/ssl on the master besides the puppetmaster cert bits. >>>> >>>> I'm wondering if this works for others, or if maybe this part of the >>>> puppet3 compatibility was missed? >>> >>> From the looks of it, you're using a Webrick puppetmaster. You should >>> switch to puppet-master-passenger instead :) > >> Hmmm, I've got that installed: > >> ii puppet-master-passenger 4.8.2-1 all >> configuration management system, scalable master service > > [...] > >> am I missing something here? > > Micah, has this been fixed since then somehow? If not, may you please > report it as a separate bug, since it already affects Stretch and is > somewhat off-topic on a bug report that's about "Enable a Puppet > master to connect to PuppetDB"? Yes, sorry that the result wasn't fed back here - it was a mistake on my part and unrelated to this package. micah
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Apollon Oikonomopoulos <apoi...@debian.org> writes: >> On the master, I see nothing in the puppet logs, but I do see in the >> apache logs: >> >> newpuppetmaster:8140 0.0.0.0 - - [03/Feb/2017:08:41:30 -0800] "GET >> /production/certificate/puppetdb? HTTP/1.1" 404 5361 "-" "Ruby" >> >> but nothing else. The puppetmaster has no certs pending to be signed and >> only has one cert signed (the puppetmaster itself). There is nothing in >> /var/lib/puppet/ssl on the master besides the puppetmaster cert bits. >> >> I'm wondering if this works for others, or if maybe this part of the >> puppet3 compatibility was missed? > > From the looks of it, you're using a Webrick puppetmaster. You should > switch to puppet-master-passenger instead :) Hmmm, I've got that installed: ii puppet-master-passenger 4.8.2-1 all configuration management system, scalable master service and apache is configured to use it: lrwxrwxrwx 1 root root 37 Feb 3 09:45 puppet-master.conf -> ../sites-available/puppet-master.conf root@newpuppetmaster:/etc/apache2/sites-enabled# and it is running: root 10853 0.0 0.0 105732 7860 ?Ss 09:46 0:00 /usr/sbin/apache2 -k start root 10854 0.0 0.1 474520 9792 ?Ssl 09:46 0:00 Passenger watchdog root 10857 0.0 0.1 1174672 11580 ? Sl 09:46 0:00 Passenger core nobody 10862 0.0 0.1 483104 11400 ?Sl 09:46 0:00 Passenger ust-router www-data 10880 0.4 0.0 523892 6680 ?Sl 09:46 0:00 /usr/sbin/apache2 -k start www-data 10881 0.6 0.0 589428 6672 ?Sl 09:46 0:00 /usr/sbin/apache2 -k start puppet 10945 7.1 0.6 157664 56976 ?Sl 09:46 0:01 Passenger AppPreloader: /usr/share/puppet/rack/puppet-master puppet 10967 0.2 0.6 292752 53796 ?Sl 09:46 0:00 Passenger RubyApp: /usr/share/puppet/rack/puppet-master am I missing something here? micah
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Hi, Apollon Oikonomopoulos <apoi...@debian.org> writes: > - puppet 4.8.2-1 will (hopefully) migrate to testing tomorrow, 3 days >before the Freeze. This will be the first version in Stretch >supporting Puppet 3 clients. This has migrated. I've upgraded my Stretch puppet4 server to 4.8.2-1 and am testing it. Unfortunately, I've already found a problem. If I have a new puppet3 node and I do: root@puppetdb:~# puppet agent -t Exiting; no certificate found and waitforcert is disabled root@puppetdb:~# It doesn't generate a CSR, there is no /var/lib/puppet/ssl directory. Yes, this is puppet3 that is failing here, but I suspect it is because it is not getting the right response from the master. On the master, I see nothing in the puppet logs, but I do see in the apache logs: newpuppetmaster:8140 0.0.0.0 - - [03/Feb/2017:08:41:30 -0800] "GET /production/certificate/puppetdb? HTTP/1.1" 404 5361 "-" "Ruby" but nothing else. The puppetmaster has no certs pending to be signed and only has one cert signed (the puppetmaster itself). There is nothing in /var/lib/puppet/ssl on the master besides the puppetmaster cert bits. I'm wondering if this works for others, or if maybe this part of the puppet3 compatibility was missed? micah signature.asc Description: PGP signature
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Apollon Oikonomopoulos <apoi...@debian.org> writes: > On 09:29 Thu 02 Feb , micah wrote: >> Apollon Oikonomopoulos <apoi...@debian.org> 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#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Apollon Oikonomopoulos <apoi...@debian.org> 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? micah 0. https://release.debian.org/
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
micah <mi...@riseup.net> writes:
> I agree that it doesn't look hard to add the terminus package, but I was
> hoping we could provide some kind of upgrade path for people to keep
> their storedconfig database, but I can't seem to figure out what is
> going on here.
Ok, I got it working:
1. wget http://downloads.puppetlabs.com/puppetdb/puppetdb-2.3.8.tar.gz
2. verify and uncompress it
3. cp -avp puppetdb-2.3.8/ext/master/lib/puppet/*
/usr/lib/ruby/vendor_ruby/puppet/
4. copy active record dbadapter details to [main] section of puppet.conf
5. apply the attached patch[0] to
/usr/lib/ruby/vendor_ruby/puppet/face/storeconfigs.rb
--- storeconfigs.orig.rb 2016-08-24 09:04:48.428728886 +
+++ storeconfigs.rb 2016-08-24 09:51:34.658495419 +
@@ -35,16 +35,15 @@
begin
Puppet::Rails.connect
- # Fetch all nodes, including exported resources and their params
- nodes = Puppet::Rails::Host.all(:include => {:resources => [:param_values, :puppet_tags]},
- :conditions => {:resources => {:exported => true}})
-
- catalogs = nodes.map { |node| node_to_catalog_hash(node) }
-
catalog_dir = File.join(workdir, 'catalogs')
FileUtils.mkdir(catalog_dir)
-
- catalogs.each do |catalog|
+
+ nodes = []
+ # Fetch all nodes, including exported resources and their params
+ Puppet::Rails::Host.find_each(:include => {:resources => [:param_values, :puppet_tags]},
+:conditions => {:resources => {:exported => true}}, batch_size: 1) do |node|
+catalog = node_to_catalog_hash(node)
+ nodes << node[:name]
filename = File.join(catalog_dir, "#{catalog[:data][:name]}.json")
File.open(filename, 'w') do |file|
@@ -52,7 +51,7 @@
end
end
- node_names = nodes.map(&:name).sort
+ node_names = nodes.sort
timestamp = Time.now
6. puppet storeconfigs export
7. copy the exported file to the server running puppetdb software and
import the data with:
puppetdb import --infile ./storeconfigs-2017XX.tar.gz
This wouldn't be too hard to make work in a debian package, so people
can actually upgrade, but we need the termini package first.
micah
0. https://tickets.puppetlabs.com/browse/PDB-165
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Hi, Georg Faerber <ge...@riseup.net> writes: > I think the following might be of interest: > > I've tested the proposed way of intrigeri, which is described at [1]: > >> puppetdb-termini has no dependencies except puppet-agent. It just >> ships 16 .rb files, that live in the upstream Puppet Git repository, >> and are distributed in PuppetDB upstream tarballs. > > This is described at [2] as well. > > I've set up a puppetmaster out of j-bp, copied the .rb files into > '/usr/lib/ruby/vendor_ruby/puppet', set up upstream puppetdb in another > machine, and configured the puppetmaster to talk to the puppetdb. This > works as expected, and creating a puppet-termini package doesn't seem to > be hard. As the puppet packages are team maintained, I could join the > team and create such an initial package, if that's the way to go. I just tried to do this too and can confirm what you found. However, I was trying to follow the directions[0] to migrate my storedconfigs database to puppetdb. In order to do that, you need to do a 'puppet storeconfigs export'. That only works in puppet3, so I grabbed the puppetdb-termini package[1] version 3.2.4[2] as this was the latest version I could find that wasn't version 4, and copied those .rb files as you did, and then was able to run 'puppet storeconfigs export', but weirdly it doesn't actually generate the tarball that I expect: root@newpuppetmaster:~# puppet storeconfigs --verbose export /usr/lib/ruby/vendor_ruby/puppet/defaults.rb:465: warning: key :queue_type is duplicated and overwritten on line 466 Info: Connecting to mysql database: puppet root@newpuppetmaster:~# that is the right database and right database connector, but I dont see it doing anything, even when I strace. I agree that it doesn't look hard to add the terminus package, but I was hoping we could provide some kind of upgrade path for people to keep their storedconfig database, but I can't seem to figure out what is going on here. any ideas? micah 0. https://docs.puppet.com/puppetdb/3.0/migrate.html 1. later it was renamed terminus 2. https://apt.puppetlabs.com/pool/jessie/PC1/p/puppetdb/puppetdb-termini_3.2.4-1puppetlabs1_all.deb signature.asc Description: PGP signature
Bug#848245: ITP: leap-cli -- command-line tool for managing LEAP platform service provider infrastrucutre
Package: wnpp Severity: wishlist Owner: Micah Anderson <mi...@debian.org> * Package name: leap-cli Version : 1.9.0 Upstream Author : LEAP Encryption Access Project <leap-disc...@lists.riseup.net> * URL : http://leap.se * License : MIT Programming Lang: Ruby Description : command-line tool for managing LEAP platform service provider infrastrucutre The leap command line tool is used by sysadmins to manage everything about a service provider’s infrastructure, including: * Create, initialize, and deploy nodes. * Manage keys and certificates. * Query information about the node configurations. * Everything about your provider is managed by editing JSON configuration files and running leap commands. The leap command-line tool is run on your workstation, and never on a server you are deploying to. It is also run from within a provider instance: The leap command requires that the current working directory is a valid provider instance, except when running leap new to create a new provider instance.
Bug#846258: ITP: ruby-clean-test -- Get your Test::Unit test cases readable and fluent, without RSpec, magic, or crazy meta-programming.
Package: wnpp Severity: wishlist Owner: micah <mi...@muck.riseup.net> * Package name: ruby-clean-test Version : 1.0.0 Upstream Author : Dave Copeland <davetron5...@gmail.com> * URL : http://www.github.com/davetron5000/clean_test * License : Apache Programming Lang: Ruby Description : Get your Test::Unit test cases readable and fluent, without RSpec, magic, or crazy meta-programming. This library is a set of small, simple tools to make your Test::Unit test cases easy to understand. This isn't a massive change in how you write tests, but simply some helpful things will make your tests easier to read. I plan to maintain this package in the ruby-pkg-extras team, it is needed for some dependencies for other packages.
Bug#846250: ITP: ruby-gli -- ruby-gli allows you to make a polished, easy-to-maintain command-line application without a lot of syntax
Package: wnpp Severity: wishlist Owner: Micah Anderson <mi...@debian.org> * Package name: ruby-gli Version : 2.14.0 Upstream Author : Dave Copeland <davetron5...@gmail.com> * URL : https://github.com/davetron5000/gli * License : Apache Programming Lang: Ruby Description : ruby-gli allows you to make a polished, easy-to-maintain command-line application without a lot of syntax GLI (Git-Like Interface) is an easy way to help you make a 'command-suite' command-line application (e.g. one like git), in a polished, easy-to-maintain way without a lot of syntax, and without restricting you in any way from the power of OptionParser. GLI uses a simple DSL, but retains all the power you'd expect from the built-in OptionParser. I plan to maintain this package in the ruby-pkg-extras team, it is needed for some dependencies for other packages.
Bug#844424: ITP: ruby-airbrussh -- Airbrussh pretties up your SSHKit and Capistrano output
Package: wnpp Severity: wishlist Owner: Micah Anderson <mi...@debian.org> * Package name: ruby-airbrussh Version : 1.1.1 Upstream Author : Matt Brictson <airbru...@mattbrictson.com> * URL : https://github.com/mattbrictson/airbrussh * License : MIT Programming Lang: Ruby Description : Airbrussh pretties up your SSHKit and Capistrano output Airbrush is a replacement log formatter for SSHKit that makes Capistrano output much easier on the eyes. It Provides concise, useful log output that is easy to read. This package is a new dependency for capistrano, it will be maintained inside the pkg-ruby-extras team.
Bug#843986: ITP: ruby-ya2yaml -- An UTF8 safe YAML dumper.
Package: wnpp Severity: wishlist Owner: Micah Anderson <mi...@debian.org> * Package name: ruby-ya2yaml Version : 0.31 Upstream Author : Akira FUNAI <funai.ak...@gmail.com> * URL : http://rubyforge.org/projects/ya2yaml/ * License : MIT Programming Lang: Ruby Description : An UTF8 safe YAML dumper. Ya2YAML is "yet another to_yaml". It emits YAML document with complete UTF8 support (string/binary detection, "\u" escape sequences and Unicode specific line breaks). I plan to maintain this package in the ruby-pkg-extras team, it is needed for some dependencies for other packages.
Bug#775827: RFA: grok -- powerful pattern-matching and reacting tool
Stig - I'd be interested in adopting this package. I use Grok not infrequently and would be happy to help. - Micah
Bug#689879: Can you provide an example?
I've been unsuccessfully trying to manipulate and query /sys/kerenl/mm/ksm/ entries using udevadm. I'd like to set some values like I would with sysfs.conf and have them be set at boot, which is what I would use sysfsutils for, but your message indicates I should be doing this another way. I'd love to do it the 'right' way, but I can't seem to figure out what that is. Could you provide an example of how you would do this so they would be set on a reboot: echo 1 /sys/kernel/mm/ksm/run echo 100 /sys/kernel/mm/ksm/sleep_millisecs I woul dhave set these in /etc/sysfs.conf and issued a /etc/init.d/sysfsutils reload in the past. thanks! micah -- 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/87y4j6cmxc@muck.riseup.net
Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG
intrigeri intrig...@debian.org 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#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#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 mi...@debian.org 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#738093: Thanks for adopting stunnel4!
Hi Peter, Great to see you've adopted the stunnel4 package! I use it quite a bit and I was sad to see it was being orphaned and I didn't have time to pick up another package right now. So, although I can't really help much - I wanted to give some words of encouragement and thanks for taking it on. If you need a second set of eyes to look over an updated package, or if you need help with any of the Debian process for updating a package, let me know, I'm happy to help. micah pgpdFrZ5BJjiF.pgp Description: PGP signature
Bug#720577: ITP: python-qt4reactor -- Provides support for Twisted to be driven by the Qt mainloop
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-qt4reactor Version : 1.0 Upstream Author : Michael Terry mte...@ubuntu.com * 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#717888: ITP: gtk-theme-config -- Configure GTK theme colors.
Package: wnpp Severity: wishlist Owner: Micah Gersten mic...@ubuntu.com * Package name: gtk-theme-config Version : 0.9 Upstream Author : Satyajit Sahoo satyajit.ha...@gmail.com * URL : https://github.com/satya164/gtk-theme-config * License : GPLv3 Programming Lang: Vala Description : Configure GTK theme colors. This little tool allows anyone to change some basic elements of a GTK theme easily (both GTK2 and GTK3) with a simple interface. -- 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/20130726014828.23460.24186.reportbug@localhost6.localdomain6
Bug#653113: Status of reviewboard?
Hello, I haven't seen an update on this ITP since 30 Aug 2012, and the mentors bug was closed after no response (#669720). It would be really great if this work wasn't lost, it seemed very close to being finished. Maybe now things are in a better state? micah pgpQd1l4by5Gs.pgp Description: PGP signature
Bug#713913: ITP: libscrypt -- scrypt shared library.
Michael Stapelberg stapelb...@debian.org writes: Hi Micah, Micah Anderson mi...@debian.org writes: Scrypt shared library, implementing the reference implementation of the scrypt binary. Please improve this package description. It is unclear what scrypt is and why it’s great. How about something like: The scrypt algorithm is a password-based key derivation function designed to require large amounts of memory. This proof-of-work scheme is intended to make it costly to perform large-scale hardware attacks. . This package contains a shared library implementing the scrypt algorithm, based on the original implementation with a number of harnesses and simplified interfaces. -- 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/87d2rbcux6@muck.riseup.net
Bug#713913: ITP: libscrypt -- scrypt shared library.
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: libscrypt Version : stable1 Upstream Author : Joshua Small techn...@lolware.net * 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#710464: ITP: python-scrypt -- Python bindings for the scrypt key derivation function library
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-scrypt Version : 0.5.3 Upstream Author : Magnus Hallin mhal...@gmail.com * 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#707615: ITP: python-autopep8 -- tool that automatically formats Python code to conform to autopep8
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-autopep8 Version : 0.8.7 Upstream Author : Hideo Hattori hhatto...@gmail.com * URL : https://pypi.python.org/pypi/autopep8 * License : Expat Programming Lang: Python Description : tool that automatically formats Python code to conform to autopep8 autopep8 automatically formats Python code to conform to the PEP 8 style guide. It uses the pep8 utility to determine what parts of the code needs to be formatted. autopep8 is capable of fixing most of the formatting issues that can be reported by pep8. -- 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/20130509150714.31392.1496.report...@muck.riseup.net
Bug#707619: ITP: python-paisley -- CouchDB client written in Python to be used within a Twisted application
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: python-paisley Version : 0.3.1 Upstream Author : David Reid and Thomas Herve * URL : https://github.com/objcode/paisley * License : Expat Programming Lang: Python Description : CouchDB client written in Python to be used within a Twisted application Paisley implements the CouchDB API for Twisted. -- 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/20130509152120.1002.77317.report...@muck.riseup.net
Bug#707620: ITP: python-dirspec -- Python User Folders Specification Library
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * 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 mi...@debian.org * 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#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#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#474299: semantik is in Ubuntu
semantik 0.7.3 is in Ubuntu. I'm actually addressing a DFSG issue with it (waf) and will be uploading 0.8.3 to Ubuntu soon. I can post a followup when I'm done. At that point, if someone would like to adopt it into Debian, that would be great. 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/50ee534d.1000...@ubuntu.com
Bug#646607: hardening flags
Hi, It would be great if you could add the hardening-flags to the atheme-services package, as described here: http://wiki.debian.org/HardeningWalkthrough 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/87zkb4y5fn@algae.riseup.net
Bug#646607: ITP: atheme-services -- modular IRC services daemon
On Mon, 19 Mar 2012 21:35:31 -0500, Mike Mestnik che...@mikemestnik.net 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#663101: [Pkg-puppet-devel] Bug#663101: RFP: foreman -- puppet dashboard and node classifier
On Thu, 08 Mar 2012 14:56:56 +0100, Laurent Bigonville bi...@debian.org wrote: Package: wnpp Severity: wishlist * Package name: foreman Version : 0.4.2 Upstream Author : Ohad Levy ohadl...@gmail.com Paul Kelly pike...@blueyonder.co.uk * 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#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#563951: [Pkg-puppet-devel] MCollective Debian packages
On Wed, 17 Aug 2011 12:29:45 -0400, micah anderson mi...@riseup.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed Hello! On Tue, 16 Aug 2011 19:13:47 +0200, Jonas Genannt jonas.gena...@capi2name.de 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 jonas.gena...@capi2name.de 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#563951: [Pkg-puppet-devel] MCollective Debian packages
Hi Jonas, On Mon, 25 Jul 2011 22:40:24 +0200, Jonas Genannt jonas.gena...@capi2name.de 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#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#615033: ITP: gnome-web-photo -- Create snapshot images of and print web pages from the command line
Package: wnpp Severity: wishlist Owner: Micah Gersten mic...@ubuntu.com * Package name: gnome-web-photo Version : 0.10 Upstream Author : Christian Persch c...@gnome.org, Vincent Untz vu...@gnome.org * URL : http://git.gnome.org/browse/gnome-web-photo * License : LGPL 2.1 or later Programming Lang: (C) Description : Create snapshot images of and print web pages from the command line GNOME Web Photographer is a tool to generate full-size image files and thumbnails from HTML files and web pages. It can also be used to print those. -- 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/20110225034217.7927.13999.reportbug@localhost6.localdomain6
Bug#522138: Gears is dead
Google Gears has been dead upstream for about a year, I don't know if there's any reason to get this into Debian. We dropped it in Ubuntu in Maverick. 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/4d579697.2050...@ubuntu.com
Bug#578157: and another!
On Mon, 17 Jan 2011 10:50:25 +0100, Jonas Smedegaard d...@jones.dk 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 d...@jones.dk 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
'printrpcpassword=,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#578157: and another!
On Mon, 10 Jan 2011 21:31:39 +0100, Jonas Smedegaard d...@jones.dk 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
'printrpcpassword=,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, 10 Jan 2011 09:46:29 +0100, Jonas Smedegaard d...@jones.dk 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 d...@jones.dk 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 d...@jones.dk 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 d...@jones.dk 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 d...@jones.dk 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 Fri, 7 Jan 2011 20:17:29 +0100, Jonas Smedegaard d...@jones.dk 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 d...@jones.dk
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=password
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,
testnet : false,
keypoololdest : 1294638747,
paytxfee : 0.,
errors :
}
mi...@algae:~$
I will now compile a new Bitcoin against Berkeley DB 4.8, with a README
mentioning essential parts of above - blindly hoping that it works.
I checked with the bitcoin community, and found there are quite a number
of people using bdb4.8 on gentoo, redhat, fedora and freebsd.
Please be careful to test against current release, not the version I am
about to release :-)
Yep, I used 0.3.19~dfsg-3~0jones1 for this test.
micah
pgpLJBJUK16RJ.pgp
Description: PGP signature
Bug#578157: and another!
On Thu, 6 Jan 2011 17:45:57 +0100, Jonas Smedegaard d...@jones.dk 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 d...@jones.dk 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#578157: and another!
On Mon, 13 Dec 2010 14:55:18 +0100, Jonas Smedegaard d...@jones.dk 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#448638: any progress on i2p?
Hi, , | I would love for it to be non-native, but the only way I have been able | to do that is by following the workaround at the bottom of bug 580804: | | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580804 ` Did you see the follow-up posts on debian-mentors to your sponsorship request? Specifically, this one, which details how to do it: http://lists.debian.org/debian-mentors/2010/11/msg00478.html micah -- pgpkDy6d2ZOSM.pgp Description: PGP signature
Bug#578157: and another!
On Mon, 13 Dec 2010 14:55:18 +0100, Jonas Smedegaard d...@jones.dk 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!
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 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/871v5nwykh@algae.riseup.net
Bug#560244: ITP: mysql-cluster
Ubuntu already has this packaged, maybe this can be coordinated with the Ubuntu Server team. https://launchpad.net/ubuntu/+source/mysql-cluster-7.0 -- 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/4c17a416.2020...@micahscomputing.com
Bug#568501: Progess on ITP
Is there any progress on this? Do you still ITP? If you need any help, please let me know. Thanks. -- 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/4bda4194.1090...@micahscomputing.com
Bug#544338: tahoe and zfec
Hi! On Sun, 14 Mar 2010 23:49:28 +0100, Giovanni Mascellani mascell...@poisson.phc.unipi.it 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#573874: ITP: compass-susy-plugin -- Susy is a elastic grid framework for Compass
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: compass-susy-plugin Version : 0.6.3 Upstream Author : Eric Meyer e...@oddbird.net * 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#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 pau...@debian.org wrote: On Thu, Mar 04, 2010 at 05:45:33PM -0500, Micah Anderson wrote: Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * 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 mi...@debian.org * Package name: librb-inotify-ruby Version : 0.7.0 Upstream Author : Nathan Weizenbaum nex...@gmail.com * 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#572555: ITP: libcompass-ruby -- Compass is a SASS-based stylesheet authoring tool
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: libcompass-ruby Version : 0.10.0.pre8 Upstream Author : Chris Eppstein ch...@eppsteins.net * 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 mi...@debian.org * Package name: libruby-fssm Version : 0.1.3 Upstream Author : Travis Tilley ttil...@gmail.com * 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 mi...@debian.org * Package name: libffi-ruby Version : 0.6.2 Upstream Author : Wayne Meissner wmeiss...@gmail.com * 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#572029: ITP: pppd-sql -- pppd-sql provides a MySQL or PostgreSQL backend for CHAP/PAP pppd authentication
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: pppd-sql Version : 0.8.0 Upstream Author : Maik Broemme mbroe...@plusserver.de * 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#564820: ITP: libpam-barada -- PAM module to provide
On Sun, 14 Feb 2010 23:26:47 -0500, micah anderson mi...@riseup.net wrote: On Sun, 14 Feb 2010 15:38:28 -0800, Andrew Pollock apoll...@debian.org 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#564820: ITP: libpam-barada -- PAM module to provide
On Sun, 14 Feb 2010 15:38:28 -0800, Andrew Pollock apoll...@debian.org 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
Hey Andrew, any progress on this?
it was written specifically with Android devices in mind.
There are many HOTP client out there[1]. Is it really android specific
in any way? I suggest dropping that sentence.
The piece that would be put in Debian is not Android specific, but there
is a companion application that goes along with barada that is for
Android.
Also, you say that there are many HOTP clients out there, but I have not
found any easy ones such as this one for Debian. Also your URL you cite
is a 404:
[1] http://rcdevs.com/products/openotp/tokens.php
There is companion software which runs on Android, so that your
^^ ${your phone}
Is that true? Maybe this libpam-barada works for other HOTP clients,
with different client software on other phones, but this is the text
From the upstream and unless someone is able to determine that it works
on non-android phones, it seems a little too soon to generalize it.
I suppose this new RFC is more secure than plain old OTP/OPIE (?). In
any case, the package could include those 2 keyword for `aptitude
search`
I think the existence of OTP in HTOP will cause aptitude to find
it. OPIE is just another OTP implementation, just like HOTP is, so I'm
not sure if it needs to be listed, but I wouldn't care if someone did.
micah
pgphbmZA7R3p7.pgp
Description: PGP signature
Bug#564820: HOTP
I would suggest that the PAM architecture is better suited to providing only _one_ factor of authentication per plugin. Does this module really implement two factors? If not, you probably shouldn't claim that it does. Have you read the HOTP RFC[0]? micah 0. http://tools.ietf.org/html/rfc4226 -- It is no measure of health to be well adjusted to a profoundly sick society. - J Krishnamurti pgpVnisja1y6z.pgp Description: PGP signature
Bug#503977: Tahoe-LAFS for Ubuntu!
Hi! * Zooko Wilcox-O'Hearn zo...@zooko.com [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 mi...@debian.org * 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 mi...@riseup.net [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#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 ftpmas...@debian.org [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#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#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#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 ftpmas...@debian.org - From: Mark Hymers ftpmas...@debian.org To: Filipe Lautert fil...@debian.org, Leandro Nunes dos Santos leandronu...@safernet.org.br Cc: Debian Installer instal...@ftp-master.debian.org 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#490146: Lets get this into Debian?
* Ryan Niebur ryanrya...@gmail.com [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#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#522636: ITP: libpacket-ruby -- ruby library for Event driven network programming
Package: wnpp Severity: wishlist Owner: Micah Anderson mi...@debian.org * Package name: libpacket-ruby Version : 0.1.15 Upstream Author : Hemant Kumar gethem...@gmail.com * 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 mi...@debian.org * Package name: libbackgroundrb-ruby Version : 1.2 Upstream Author : Hement Kumar gethem...@gmail.com * 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#456227: What is the status of sphinxsearch?
* Marco Rodrigues goth...@sapo.pt [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#488753: Boost bundling
everything a given program requires, bundled all together. This results in serious application bloat, sloppy security support, and a total nightmare for upgrades. How many copies of Rails do you have installed on your system? In each of those Rails copies, how many copies of other ruby libraries are bundled in there that you have installed elsewhere (as gems, etc.)? How many of those Rails application trees have Rails itself bundled underneath them? In your gems directory, how many different versions of the same gem do you have installed? How many of those do you actually need? If one has two different gems that use the same binaries, how does that work? Typically, the last installed gem wins. This sounds very much like Windows DLL hell, and this is why I got into the Debian game, I didnt want to waste my life playing dependency resolution games. Playing these games is the path to total madness. This is why Debian, and I am sure other distributions, are begging the Ruby/Rails community to realize this problem and begin supporting simultaneous versions of libraries on a system, this is how most other programming languages work. At one time, this is how C was, but it became totally unmanageable and it *had to change*, I believe that for any programming language, or framework, to succeed over the long run is to figure out how to become friendly to distributions that will bring their amazing applications, their language, and their framework to the larger world in a convenient distribution format, coupled with ease of management and security and piece of mind that they do not have random stuff tucked away in weird places that could result in their system being vulnerable. That essentially requires doing the only sane solution to this problem that has been develped in the last 40 years: get a system that will let a binary, or package use the installed system libraries through a mechanism of stable library versioning, and stop trying to work around an existing package management system. 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 leandronu...@safernet.org.br and Filipe Lautert fil...@debian.org. 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 hon...@phusion.nl - Sender: Hongli Lai hongli...@gmail.com From: Hongli Lai hon...@phusion.nl 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
Bug#488753: (forw) Re: Boost bundling
* Hongli Lai hon...@phusion.nl [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#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#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#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#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#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#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#456227: Notes on this package
-punned pointer will break strict-aliasing rules etc. Micah
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 - # Add here commands
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
