Re: [Freedombox-discuss] What Do You want to use the FreedomBox for?
short term practical wants: - redundant git repository backup - redundant crypto key backup (eg, plan B to regain access to other servers/identity) - personal information store: address book, calendering - VPN/tor/ipv6/cjdns end node (as a gateway for other traffic) - general purpose shell account longer term nice to have: - redundant searchable email store (but probably not actual server) - e-currency wallet (eg bitcoin) - real time messaging server/node (IRC, irssi, xmpp, SIP, voice+video chat) - distributed/redundant file backup with Tahoe-LAFS - distributed/redundant sharded crypto key backup (for friends) - as a gateway for other traffic: - https-everywhere enforcement - ad/cookie/tracking filtering - caching for performance - persistant SSL, dnssec, ipsec, gpg certificate/key store, warn on change - IPv6 tunneling - ultimately, to migrate from rented cloud VPS to owned plug computer hardware for most hosting needs ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] InDisk -- does this technology exist in open source?
The FUSE (filesystem in userspace) library/module is implemented in many/most *NIX operating systems, and would allow a specific on-the-fly virtual file access like you describe to be implemented in a popular programming language (bindings for python, ruby, etc). Classic FUSE examples include reading and editing Wikipedia articles as files, storing files as Gmail attachments, logging of filesystem access, etc. https://en.wikipedia.org/wiki/Filesystem_in_Userspace UNIX has has always been about any/everything as a file, and the plan9 operating system took this even further. There are many, many specific- and general-purpose vritual file system hacks (such as files-as-directories, nested mounting, ramdisk mounting, the proc (process information) and sys (system/kernel information) filesystems, the device filesystem, etc), FUSE is just the most recent incarnation/library. The pizza-bilities are endless! -bryan On Wed, 30 May 2012, Rick C. Hodgin wrote: John, The key point is assembling files which are presented to the app as files, but after requesting them from different sources over the net. The data also doesn't have to be in the literal file format that's presented to the user. Suppose I access an overview.ods spreadsheet file on my K: drive (or /dev/whatever). That file does not physically exist, but through InDisk is a logical file that assembles data from a MySQL database somewhere, queries whatever it's programmed to through the setup, and prepares the ods spreadsheet file on-the-fly when it's requested. This allows the calling app to receive a file as it was designed to do, but no longer directly from a regular storage or network source. It now gets an assembled file which presents as a real file, but all reads/writes/locks/unlocks/etc go through the InDrive layer, which then issues appropriate SQL updates back to the server, or if it's on another format, possibly git push's or whatever. Does Linux/UNIX currently allow that as a generic virtual file system ability? Best regards, Rick C. Hodgin ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FW: [Trisquel-users] Alternative freedom friendly solution to Raspberry Pi
As a potential solution to the never-ending recommended/supported hardware problem, i'm making some effort to either extend or duplicate the semantic wiki at: http://www.wikidevi.com/wiki/Main_Page to include non-wireless devices, environmental ratings, performance benchmarks, kernel support version, documentation availability, price, power consumption, international regulations, etc. This wiki is central, structured, real-time queryable, and all the data can be exported as XML for forking/backup. Hopefully this will reduce background noise of raspberry pi vs. dreamplug vs. shevaplug vs. arduino vs. beaglebone vs. netbook vs. cray super computer vs. TI-83 vs. TP-Link whatever vs. ZOMG this thing from gizmodo flames/threads, and help everybody make informed decisions about which hardware to support and/or purchase. -bryan On Tue, 29 May 2012, Rick C. Hodgin wrote: This came across the Trisquel list. A possible $50 x86-based non-Intel/AMD board with free/libre drivers from VIA Technologies. I've asked Chris for more info on specs? Does anybody know of this product? Best regards, Rick C. Hodgin Original Message From: ch...@thinkpenguin.com Sent: Tue, May 29, 2012 03:59 AM To: trisquel-us...@listas.trisquel.info CC: Subject: [Trisquel-users] Alternative freedom friendly solution to Raspberry Pi The one thing I don't like about the Raspberry Pi project is the use of a graphics chip dependent on non-free software. I think there may be a new better alternative from VIA though. I sent an email to graphics chipset vendor in use in the device and got word back from an engineer (David Berol from wolfsonmicro) that the WM8750 chipset is not dependent on proprietary drivers or firmware. I did have to clarify this though as he thought I was talking about the price :). I've also gotten word through an intermediary who investigated the BIOS situation on the VIA board. This motherboard will be released unlocked. Right now VIA is releasing it with Android although there is nothing preventing this community (free software users) from porting a GNU/Linux distribution to it. It is based on ARM and I think it's primary usefulness would be streaming HD content as the cost is low ($50 USD) and has built-in hardware HD decoding. It has severely limited built-in ram (512MB) although more than sufficient for a purpose built device (HTPC). It also has 2GB internal storage and microsd expansion slot. It also has limited CPU (just 800Mhz). ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBX Hackfest Mon July 9 - Thu 12 July 2012
On Sun, 1 Jul 2012, Markus Sabadello wrote: - Configuration Management.. There was a thread recently about Augeas, Config::Model, UCI, DebConf I will be at the hackfest in NYC tuesday through thursday (and maybe monday afternoon). I'd like to get consensus and write up a proposal for a configuration management system, hack out a minimal set of features, and get them upstreamed into the weekly builds. Does this seem like a realistic goal? The lack of feedback to my earlier message was disconcerting*. -bryan * except from Nick. Thanks Nick! ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx Configuration Management
On Sat, 23 Jun 2012, Nick M. Daly wrote: Bryan, thanks for sending this along. I don't have any answers, but these are pretty fundamental questions. Thanks for the reply! Does anybody else have any guidance or insight? This is more than I want to bite off on my own. In case this thread fell off the radar, the original message is here: http://www.mail-archive.com/freedombox-discuss@lists.alioth.debian.org/msg03428.html I know there was some talk about using James's withsql [0] package for at least storing custom application-specific settings (for, i.e., Plinth and FreedomBuddy) but that doesn't really solve configuration management problems. I'd like to see something that can be hooked into Plinth and built upon there, but maybe there are other, more important criteria. Does anybody know any details about said system? Searching the wiki and discuss mailing list archive didn't turn up anything helpful. Is there some other medium where development planning is taking place? -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
[Freedombox-discuss] FBx config mgmt update
Spoke with James and a few others here at the OpenITP event, notes and a rought plan are below. Some of this feels like reinventing the wheel; a future/mature implementation might use: D-Bus for message passing, PolicyKit for access control, Augeas for read/write or building off ubus (IPC from OpenWrt) and netif (network interface configuration from OpenWrt), extending with augeas configuration or libassuan (from GPG) to handle narrow scope trusted IPC But for now i'm just going to bang something out so that plinth can use the python-augeas interface through an access controlled unix domain pipe. - requirements/compromises: - scope of configuration middleware is regular system files, mostly in /etc (no user/identity management) - files should be edited in place - local changes should be respected - single root/wheel permissions level for reading, writing, and applying changes - configuration versioning taken as a seperate problem from editing - client code (aka plinth) is responsible for semantic/logical validation, and service restarts new program: exmachina: hand of root configuration management daemon which runs with root permissions, listens on a unix domain socket with access controlled by filesystem permissions. uses a very simple api to provide access to augeas configuration file editing and service restarts. plinth/apache, running not-as-root, is passed access at startup (ENV vars? file handle pass?) single-thread, serializes edits simple, written in python (for now), including python client library which replicates python-augeas interface extra features (somedaymaybe): general purpose ncurses, gui, or web interface no-downtime reloads of daemon via HUP (a la nginx) fine-grain ACL dpkg installation general purpose features: process execution, package installation, file read/write -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
Also, just to be explicit, this would provide process separation, but does not address local user authentication or access control. Eg, in this scheme plinth would have permissions to edit all configuration files and would need to authenticate users for access control on it's own (it doesn't do this yet IIRC). What I would like is for the plinth process and the plinth process alone to have access to the unix domain socket. One way to do this would be to create a new group and use file system permissions, but yet another user/group seems like a bad idea. Another way would be to have the (root permissions) /etc/init.d/plinth script generate a secret key, register it with the running exmachina process, and pass that secret key to plinth which would use it to authenticate every RPC call over the pipe. This makes me a bit queasy because I know web applications often make accessible or dump their full environment variables and local scope as a debug feature; surely debug mode for plinth will be disabled, but still... -bryan On Tue, 10 Jul 2012, bnewb...@robocracy.org wrote: Spoke with James and a few others here at the OpenITP event, notes and a rought plan are below. Some of this feels like reinventing the wheel; a future/mature implementation might use: D-Bus for message passing, PolicyKit for access control, Augeas for read/write or building off ubus (IPC from OpenWrt) and netif (network interface configuration from OpenWrt), extending with augeas configuration or libassuan (from GPG) to handle narrow scope trusted IPC But for now i'm just going to bang something out so that plinth can use the python-augeas interface through an access controlled unix domain pipe. - requirements/compromises: - scope of configuration middleware is regular system files, mostly in /etc (no user/identity management) - files should be edited in place - local changes should be respected - single root/wheel permissions level for reading, writing, and applying changes - configuration versioning taken as a seperate problem from editing - client code (aka plinth) is responsible for semantic/logical validation, and service restarts new program: exmachina: hand of root configuration management daemon which runs with root permissions, listens on a unix domain socket with access controlled by filesystem permissions. uses a very simple api to provide access to augeas configuration file editing and service restarts. plinth/apache, running not-as-root, is passed access at startup (ENV vars? file handle pass?) single-thread, serializes edits simple, written in python (for now), including python client library which replicates python-augeas interface extra features (somedaymaybe): general purpose ncurses, gui, or web interface no-downtime reloads of daemon via HUP (a la nginx) fine-grain ACL dpkg installation general purpose features: process execution, package installation, file read/write -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] PHP Alternatives?
On Sat, 14 Jul 2012, Nick M. Daly wrote: CryptoCat (secure chat): CryptoCat Version 2 (???, in development) End client XMPP+OTR clients plus Prosody running on the device? If CryptoCat as-is is desirable, the server-side PHP code is 500 lines including comments and could be ported quickly to python, lua, or node.js. Diaspora / Friendica (social networking): Libertree (Ruby, Alpha) I thought Diaspora was Ruby on Rails? RoundCube / SquirrelMail (webmail): ??? The (very minimal) NULL webmail client is written in C: http://nullwebmail.sourceforge.net/webmail/ OwnCloud (file hosting): ??? WebDav over SSL has good cross-distribution and mobile support IIRC. Most of these projects would require modification anyways to allow some form of cohesive web of trust authentication/access control integration, right? -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
Forgot to update this list, but I submitted a pull request to the Plinth repository: https://github.com/jvasile/Plinth/pull/2 The core of the changes I made are also available in a separate repository: https://github.com/bnewbold/exmachina http://git.bnewbold.net/?p=exmachina.git;a=summary The scheme is pretty complicated and the init.d script is ugly, but the end result is privilege separation and less complicated configuration setting code. I implemented hostname changing as an example, but (ironically?) changing the timezone with /etc/timezone is not supported by augeas out of the box (that I could find). augeas added configuration file lenses for openvpn configuration some years ago, but I haven't tested them. -bryan On Tue, 10 Jul 2012, bnewb...@robocracy.org wrote: Spoke with James and a few others here at the OpenITP event, notes and a rought plan are below. Some of this feels like reinventing the wheel; a future/mature implementation might use: D-Bus for message passing, PolicyKit for access control, Augeas for read/write or building off ubus (IPC from OpenWrt) and netif (network interface configuration from OpenWrt), extending with augeas configuration or libassuan (from GPG) to handle narrow scope trusted IPC But for now i'm just going to bang something out so that plinth can use the python-augeas interface through an access controlled unix domain pipe. - requirements/compromises: - scope of configuration middleware is regular system files, mostly in /etc (no user/identity management) - files should be edited in place - local changes should be respected - single root/wheel permissions level for reading, writing, and applying changes - configuration versioning taken as a seperate problem from editing - client code (aka plinth) is responsible for semantic/logical validation, and service restarts new program: exmachina: hand of root configuration management daemon which runs with root permissions, listens on a unix domain socket with access controlled by filesystem permissions. uses a very simple api to provide access to augeas configuration file editing and service restarts. plinth/apache, running not-as-root, is passed access at startup (ENV vars? file handle pass?) single-thread, serializes edits simple, written in python (for now), including python client library which replicates python-augeas interface extra features (somedaymaybe): general purpose ncurses, gui, or web interface no-downtime reloads of daemon via HUP (a la nginx) fine-grain ACL dpkg installation general purpose features: process execution, package installation, file read/write -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Sun, 22 Jul 2012, Nick M. Daly wrote: Bryan, is this ready for me to add to the weekly images? This might solve FreedomBuddy's OpenVPN service control issues. It's waiting for review/consensus/merge, but at this point there have been no complaints so it's probably good to go? Does Plinth or the freedombox foundation have licensing policy or guidelines? Should I delegate copyright to the foundation? Sort of a mountain over a molehill for this patch. I should probably give the code a one-over and include a HOWTO; I'll do this tomorrow (tuesday). Does anybody have thoughts on logical error handling behavior? Some of the existing Plinth code (eg, hostname changer) would try to revert changes when they failed; i'm not sure if that behavior should be implemented at the exmachina (library/wrapper) level or left to application logic. -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Mon, 23 Jul 2012, Nick Daly wrote: Does anybody have thoughts on logical error handling behavior? Some of the existing Plinth code (eg, hostname changer) would try to revert changes when they failed; i'm not sure if that behavior should be implemented at the exmachina (library/wrapper) level or left to application logic. Thinking about this, I'd like to know how Ex does two things: 1. Whether changes are atomic (how do we prevent the system from seeing a semi-changed state?). Currently this is left to the application logic (separate set/save calls). I'll need to check if Augeas rolls back commits to multiple files if one of the files fails. 2. Whether failed changes aren't implemented. It seems like the least surprising behavior would be: if Ex can't save the changes, it rolls them back and raises an error. That way, the system's never left in an undefined state, and the controlling application can decide whether to give it another go or just bail. I meant at a higher level: the configuration file is saved, but restarting services depending on that configuration file fails. The easy solution with minimal surprise is to bubble up the service restart error message and wait for the user to reconfigure before restarting the service. Rolling back changes could result in large amounts of user-entered data being lost because of a small typo. Some firmwares (pfSense) also implement a test configuration feature which reverts new changes after two minutes unless they are re-confirmed; this helps prevent bricking or user lockout due to misconfiguration. I think this is overkill for now. -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FBx config mgmt update
On Mon, 23 Jul 2012, bnewb...@robocracy.org wrote: I should probably give the code a one-over and include a HOWTO; I'll do this tomorrow (tuesday). Added a HOWTO and some other improvements; updated the pull request: https://github.com/jvasile/Plinth/pull/2 -bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FreedomBox Unstable Image 2012.0819 Available
On Sun, 19 Aug 2012, Nick M. Daly wrote: Freedom Maker: https://github.com/nickdaly/freedom-maker - The weekly image has wireless again! Does wireless work out of the box for anybody? I booted with this week's image, and the Marvell .bin firmware files seem to have been fetched and put in /lib/firmware/mrvl correctly, but I get libertas_sdio firmware errors on boot and uap0 never shows up. I'm also a little confused if the libertas-firmware package should be installed (as it is via multistrap-configs/fbx-base.conf) if the marvell files are used instead... I tried removing that package and got similar (but slightly different) errors. I have an old DreamPlug (serial number DS2-113...), which I believe means it uses the SD8688 SDIO wifi chip (not the SD8787). I've poked around online and the only people who seem to have been able to successfully run the SD8688 chip in access point mode (without re-compiling kernel modules) used the Marvell firmware in combination with specific kernels and modules supplied by GlobalScale (dreamplug.google.com) or spinfex.com.au. What changed to allow inter-operation between the Marvell .bin firmware, the libertas drivers, and the generic 3.2-ish debian kernels? Nick Hardiman, has there been a change since the excellent document you wrote back in late June? I'm going to try the .img you host (once it downloads), though my guess is that it includes a non-debian kernel and modules. Another option (which would only work for the 8688 chips) might be to recompile the old uap8xxx.ko kernel module by hand using patches gleaned from the 'net, but this doesn't seem to work for the 8787 chips. I did a quick search through this mailing list thread and freedom-maker's git history, sorry if i've missed something. --bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] FreedomBox Unstable Image 2012.0819 Available
On Wed, 22 Aug 2012, Nick Daly wrote: Are you building your own image or using the published ones? In either case, only images built from the shiny branch will have wireless enabled, and then only when you plug an ethernet cord into the eth1 slot during the first boot. The /etc/init.d/first-boot file controls this process and it removes itself after configuring the system on the first boot. In this case I used the published image. The first time around I didn't have ethernet plugged in at boot so I re-fetched the first-boot init.d script and ran it by hand (including the wireless fetch). Later I started over with the fresh 2012.0819 image and made sure I had ethernet connectivity to fetch everything (and saw the wget from spinifex succeed). Reading this, it seems like either I built the images from the master branch (entirely possible, that branch doesn't have wireless), or you didn't have an ethernet cord plugged into the eth1 slot during the first boot. If you did, you would've downloaded spinfex's drivers automatically. I'll make sure to call this out in the notes for this week's image. I think the image I got from you is a shiny one: the wifi-ap-setup line in init.d/first-run was uncommented (it is commented out in master), and the spinfex *firmware* was downloaded and placed in /lib/firmware/mrvl (after which the first-run file was deleted). Still no uap8xxx *kernel module* though. Looking more carefully through freedom-maker history, it looks like it compiled a custom kernel at some point (based on work by Bauermann; it presumably included the uap8xx module?), but this was removed because hallelujah! the Dreamplug patches were back-ported already! and no longer need local kernel content since all we need will be in Debian wheezy: https://github.com/NickDaly/freedom-maker/commit/2bd110374a5b39e8bd2c7c4583a4b8dbf8d132a9 https://github.com/NickDaly/freedom-maker/commit/fae93dbf3f2f03f606bb81d09431f50b32321f6d I assume this has to do with device tree information or other bits required to get the kernel to run on a dreamplug. However, while I do see libtertas_sdio.ko and usb8xxx.ko in the wheezy kernel filelist, I don't see uap8xxx.ko: http://packages.debian.org/wheezy/armel/linux-image-3.2.0-3-kirkwood/filelist or in experimental's 3.4 image: http://packages.debian.org/experimental/armel/linux-image-3.4-trunk-kirkwood/filelist or in mainline: https://github.com/mirrors/linux/tree/master/drivers/net/wireless/libertas http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=drivers/net/wireless;h=6690fa09b446d59773f022e7d9ec72516368dbcb;hb=d9875690d9b89a866022ff49e3fcea892345ad92 What I ended up doing last night was to grab Bauermann's 3.4 kernel dreamplug patch set [0], which was based on a 3.2 kernel patches (wheezy kernel is 3.2) and extracted just the uap8xxx module code (which lives in a libertas_uap directory) and then followed Dan Gilmore's very old directions [1] to compile[2] this on my dreamplug (running the 2012.0819 freedom box image, which already had the mrvl .bin firmware), install it, and blacklist the other libertas drivers. After this I did a power-down-reboot (to ensure that any .bin firmware was flushed from chipset memory?) and during the next power up uap0 finally existed, was automatically configured, and came up as a protected freedombox SSID, which I was able to connect to and SSH over from my laptop. So it seems all the wireless configuration works just fine as long as the uap8xxx.ko kernel module exists and is loaded. Anyways, I've gone way out on a limb here, and the question remains: does the wireless access point work for other people (especially with older DreamPlugs) using the weekly image? Perhaps the uap8xxx driver gets snuck in somewhere that I missed, or perhaps there were improvements to the libertas_sdio driver in the debian wheezy kernel and I simply have a configuration or hardware problem. --bryan [0] https://github.com/bauermann/dreamplug [1] http://lists.debian.org/debian-arm/2010/05/msg00081.html [2] had to kludge out line 74 of uap_debug.c; will post soon ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
[Freedombox-discuss] uap8xxx.ko kernel module
[follow up to RE: FreedomBox Unstable Image 2012.0819 Available] I've posted the method I used to get my dreamplug (older 8868 WiFi chipset) working as an accesspoint using the libertas_uap/uap8xx kernel module: https://github.com/bnewbold/dreamplug-libertas_uap This repo includes a .ko file that seem to just work with the most recent weekly unstable image, as well as build directions. As noted in the LICENSE file, this is all very dirty and potentially infringant and would make kernel developers moan and pull their hair out, though the libertas_uap files are indicated as GPL. --bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] DreamPlug and Trac on Wheezy?
It worked fine for me using the wheezy package, at least with tracd... === root@freedombox:~# uname -a Linux freedombox 3.2.0-3-kirkwood #1 Mon Jul 23 22:36:47 UTC 2012 armv5tel GNU/Linux root@freedombox:~# apt-get install trac [...] The following NEW packages will be installed: ca-certificates docutils-common docutils-doc javascript-common libfreetype6 libjpeg8 libjs-jquery liblcms1 libneon27-gnutls libpaper-utils libpaper1 libsvn1 libxml2 libxslt1.1 python-babel python-chardet python-docutils python-genshi python-imaging python-lxml python-pkg-resources python-pygments python-roman python-setuptools python-subversion python-support python-tz sgml-base subversion trac wwwconfig-common xml-core [...] root@freedombox:~# aptitude show trac Package: trac State: installed Automatically installed: no Version: 0.12.3-1 Priority: optional Section: web Maintainer: Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org Architecture: all Uncompressed Size: 7,074 k Depends: python2.7 | python2.6, python (= 2.6.6-7~), python ( 2.8), python-pkg-resources, python-genshi (= 0.6), python-setuptools (= 0.6), libjs-jquery Recommends: apache2 | httpd, python-subversion, python-pygments (= 0.6), python-tz, python-babel (= 0.9.5), python-docutils (= 0.3.9) [...] root@freedombox:~# trac-admin ~/my_project initenv [all defaults] root@freedombox:~# trac-admin ~/my_project deploy ~/public_project root@freedombox:~# tracd --port 8000 /root/my_project [browse to http://freedombox:8000/my_project, /my_project/timeline, /my_project/report, everything looks fine] root@freedombox:~# rm -rf public_project/ my_project/ root@freedombox:~# apt-get remove trac root@freedombox:~# apt-get autoremove = --bryan On Fri, 24 Aug 2012, Nick Daly wrote: Hi folks, could someone help me confirm a weird bug I'm seeing with my own DreamPlug, so I can make sure it's not just me or my system doing something really stupid? I'm trying to run Wheezy's Trac on a DreamPlug, but whenever I set up a repository, it fails to load the page, claiming that the repository needs to be upgraded. Upgrading the repository does nothing (says that the repository's already upgraded), and the web front-end generally fails to load. I'd appreciate if someone could confirm this, so I can be sure I'm not wasting the packagers' time by filing a bug report. I get the same results when using my plugserver setup scripts [0] and when building a repository by hand: $ trac-admin ~/my_project initenv $ trac-admin ~/my_project deploy ~/public_project If it fails miserably for other folks too, I guess I'll just file the bug and switch everything to Redmine for now. Thanks for your time, Nick 0: https://bitbucket.org/nickdaly/plugserver ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] uap8xxx.ko kernel module
On Tue, 4 Sep 2012, Nick Daly wrote: On Tue, Sep 4, 2012 at 8:50 AM, Nick Hardiman n...@internetmachines.co.uk wrote: Is it a kind of update on this 2010 post for a guruplug? http://lists.debian.org/debian-arm/2010/05/msg00081.html yes. As noted in the LICENSE file, this is all very dirty and potentially infringant and would make kernel developers moan and pull their hair out, though the libertas_uap files are indicated as GPL. This worries me though. I'll test it out, but I don't think I'll merge it till we have the license stuff figured out. I'm not good enough at managing my branches (always forgetting which one I'm on), and a lot of folks (including me) would be kind of horrified to find ambiguous code in the core. To be honest, my motivation was limited to finding out if others on this list had to go through the same steps, or if I was just having a problem with my particular version of the DreamPlug. Including these patches in the weekly image isn't something i'd even think about until I had confirmation from somebody with more experience (B'Dale? James?) that it was necessary. Can you source the URLs in the LICENSE file? Your sentence just kind of trails off: The ./firmware/mrvl/ files were floating around on my DreamPlug and probably came from Sorry, I seem to have a habit of that ;) Added this URL: http://www.spinifex.com.au/plugs/downloads/dreamplug/mrvl_uap.tar.gz --bryan ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Investigating Weekly-Image Boot Format Errors
[freedom-maker]source/install.sh still seems to have 3.2.0-3-kirkwood hardcoded in? https://github.com/NickDaly/freedom-maker/blob/master/source/install.sh I would grep around, there seems to be lots of hardcoding in freedom-maker. --bryan On Tue, 20 Nov 2012, Nick M. Daly wrote: The thing that messes with my head the most here is that there's been only one change to Freedom Maker's functional bits between the last successful build and now: : diff --git a/multistrap-configs/fbx-armel.conf b/multistrap-configs/fbx-armel.conf : index aeb64a7..45feddb 100644 : @@ -5,7 +5,7 @@ aptsources=Debian armel : debootstrap=Debian armel : : [armel] : -packages=linux-image-3.2.0-3-kirkwood flash-kernel u-boot-tools u-boot : +packages=linux-image-3.2.0-4-kirkwood flash-kernel u-boot-tools u-boot : source=http://http.debian.net/debian/ : keyring=debian-archive-keyring : suite=wheezy The other changes are README changes or much higher-level project specific changes (changing ExMachina repositories). Nick ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
