Some systems, like the Github issue tracker, gather all the requests together in a single list. Calling them "Issues" invites people to submit just about anything, such as "I forgot my password".
At the other extreme, some organisations are so keen to keep support requests away from their developers that they operate two systems and a designated support team copies genuine bugs from the customer-facing trouble-ticket/CRM system to the bug tracker. This reduces the amount of spam that hits the development team but there is overhead in running multiple systems and having staff doing cut and paste.
Will people use it?
Another common problem is that a full bug report template is overkill for some issues. If a user is asking for help with some trivial task and if the tool asks them to answer twenty questions about their system, application version, submit log files and other requirements then they won't use it at all and may just revert to sending emails or making phone calls.
Ideally, it should be possible to demand such details only when necessary. For example, if a support engineer routes a request to a queue for developers, then the system may guide the support engineer to make sure the ticket includes attributes that a ticket in the developers' queue should have.
Beyond Perl
Some of the most well known systems in this space are Bugzilla, Request Tracker and OTRS. All of these solutions are developed in Perl.
These days, Python, JavaScript/Node.JS and Java have taken more market share and Perl is chosen less frequently for new projects. Perl skills are declining and younger developers have usually encountered Python as their main scripting language at university.
My personal perspective is that this hinders the ability of Perl projects to attract new blood or leverage the benefits of new Python modules that don't exist in Perl at all.
Bugzilla has fallen out of the Debian and Ubuntu distributions after squeeze due to its complexity. In contrast, Fedora carries the Bugzilla packages and also uses it as their main bug tracker.
Evaluation
I recently started having a look at the range of options in the Wikipedia list of bug tracking systems.
Some of the trends that appear:
kdb merge. Felix submitted a pull request with the exact code almost a week ago and we have talked with Manoj Srivastava, the developer for ucf, and he seemed to really like the idea. The only changes we made are to add an option for a three-way merge command, and if one is present, the merge is attempted using the specified command. It s all pretty simple really.
Since we decided to include a generic hook for a three-way merge command instead of an Elektra-specific one (which would be less open and would create a dependency on Elektra), we also had to add functionality to Elektra to work with this hook. We ended up writing a new script, called elektra-merge which is now included in our repository. All this script does is act as a liaison between the ucf --three-way-merge-command option and Elektra itself. The script automatically mounts the correct files for theirs and base and dest using the new remount command.
Since the only parameters that are passed to the ucf merge command are the paths of ours, theirs, base and result, we were missing vital information on how to mount these files. Our solution was to create the remount command which mirrors the backend configuration of an existing mountpoint to create a new mountpoint using a new file. So if ours is mounted to system/ours using ini, kdb remount /etc/theirs system/theirs system/ours will mount /etc/theirs to system/theirs using the same backend as ours. Since theirs, base, and result should all have the same backend as ours, we can use remount to mount these files even if all we know is their paths.
Now, package maintainers can edit their scripts to utilize this new feature. If they want, package maintainers can specify a command to use to merge files using ucf during package upgrades. I will soon be posting a tutorial about how to integrate this feature into a package and how to use Elektra in your scripts in order to allow for automatic three-way merges during package upgrade. I will post a link to the tutorial here once it is published.
Sincerely, 
A quick update - Linaro ARMv8 OpenEmbbeded images work just fine with qemu 2.1 as well: Quick benchmarking with age-old ByteMark nbench:
$ http://releases.linaro.org/14.07/openembedded/aarch64/Image
$ http://releases.linaro.org/14.07/openembedded/aarch64/vexpress64-openembedded_lamp-armv8-gcc-4.9_20140727-682.img.gz
$ qemu-system-aarch64 -m 1024 -cpu cortex-a57 -nographic -machine virt \
-kernel Image -append 'root=/dev/vda2 rw rootwait mem=1024M console=ttyAMA0,38400n8' \
-drive if=none,id=image,file=vexpress64-openembedded_lamp-armv8-gcc-4.9_20140727-682.img \
-netdev user,id=user0 -device virtio-net-device,netdev=user0 -device virtio-blk-device,drive=image
[ 0.000000] Linux version 3.16.0-1-linaro-vexpress64 (buildslave@x86-64-07) (gcc version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) ) #1ubuntu1~ci+140726114341 SMP PREEMPT Sat Jul 26 11:44:27 UTC 20
[ 0.000000] CPU: AArch64 Processor [411fd070] revision 0
...
root@genericarmv8:~#
| Index | Qemu | Foundation | Host |
|---|---|---|---|
| Memory | 4.294 | 0.712 | 44.534 |
| Integer | 6.270 | 0.686 | 41.983 |
| Float | 1.463 | 1.065 | 59.528 |
| Baseline (LINUX) : AMD K6/233* | |||
kdb import. As you know, the kdb tool allows users to interact with the Elektra Key Database (KDB) via the command line. Today I would like to explain the import function of kdb.
The command to use kdb import is:
kdb import [options] destination [format]
destination is where the imported Keys should be stored below. For instance, kdb import system/imported would store all the keys below system/imported. This command takes Keys from stdin to store them into KDB. Typically, this command is used with a pipe to read in the Keys from a file.
The format argument you see above can be a very powerful option to use with kdb import. The format argument allows a user to specify which plug-in is used to import the Keys into the Key Database. The user can specify any storage plug-in to serve as the format for the Keys to be imported. For instance, if a user wanted to import a /etc/hosts file into KDB without mounting it, they could use the command cat /etc/hosts kdb import system/hosts hosts. This command would essentially copy the current hosts file into KDB, like mounting it. Unlike mounting it, changes to the Keys would not be reflected in the hosts file and vise versa.
If no format is specified, the format dump will be used instead. The dump format is the standard way of expressing Keys and all their relevant information. This format is intended to be used only within Elektra. The dump format is a good means of backing up Keys from the Key Database for use with Elektra later such as reimporting them later. As of this writing, dump is the only way to fully preserve all parts of the KeySet.
It is very important to note that the dump does not rename keys by design. If a user exports a KeySet using dump using a command such as kdb export system/backup > backup.ecf, they can only import that keyset back into system/backup using a command like cat backup.ecf kdb import system/backup.
The kdb import command only takes one special option:
-s --strategy
preserve any keys already in the destination will not be overwritten
overwrite any keys already in the destination will be overwritten if a new key has the same name
cut all keys already in the destination will be removed, then new keys will be imported
kdb import is as follows:
cat backup.ecf kdb import system/restore
$cat backup.ecf
kdbOpen 1
ksNew 3
keyNew 19 0
system/backup/key1
keyMeta 7 1
binary
keyEnd
keyNew 19 0
system/backup/key2
keyMeta 7 1
binary
keyEnd
keyNew 19 0
system/backup/key3
keyMeta 7 1
binary
keyEnd
ksEnd
kdb ls system/backup prints:
system/backup/key1
system/backup/key2
system/backup/key3
kdb import command is a very useful tool included as part of Elektra. I also wrote a tutorial on the kdb export command. Please go read that as well because those two commands go hand in hand and allow some very powerful usage of Elektra.
Sincerely, kdb import command. Well I also wanted to go over it s sibling function, kdb export. These two commands work very similarly, but there are some differences.
First of all, the command to use kdb export is:
kdb export [options] source [format]
source is the root key of which Keys should be exported. For instance, kdb export system/export would export all the keys below system/export. Additionally, this command exports keys under the system/elektra directory by default. It does this so that information about the keys stored under this directory will be included if the Keys are later imported into an Elektra Key Database. This command export Keys to stdout to store them into the Elektra Key Database. Typically, the export command is used with redirection to write the Keys to a file.
As we discussed already, the format argument can be a very powerful option to use with kdb export. Just like with kdb import the format argument allows a user to specify which plug-in is used to export the Keys from the Key Database. The user can specify any storage plug-in to serve as the format for the exported Keys. For instance, if a user mounted their hosts file to system/hosts using kdb mount /etc/hosts system/hosts hosts they would be able to export these Keys using the hosts format by using the command kdb export system/hosts hosts > hosts.ecf. This command would essentially create a backup of their current /etc/hosts file in a valid format for /etc/hosts.
If no format is specified, the format dump will be used instead. The dump format is the standard way of expressing Keys and all their relevant information. This format is intended to be used only within Elektra. The dump format is a good means of backing up Keys from the Key Database for use with Elektra later such as reimporting them later. As of this writing, dump is the only way to fully preserve all parts of the KeySet.
The kdb export command takes one special option, but it s different than the one for kdb import, that option is:
-E --without-elektra which omits the system/elektra directory of keys
kdb export is as follows:
kdb export system/backup > backup.ecf
kdb export command is a very useful tool just like it s sibling, kdb import. If you haven t yet, please go read the tutorial I wrote for kdb import because these two commands are best used together and can enable some really great features of Elektra.
Sincerely,
Problem
Discussions are sometimes started by mailing a few different mailing
lists so that all relevant parties have a chance to be aware of a new
topic. It s all nice when people can agree on a single venue to send
their replies to, but that doesn t happen every time.
Case in point, I m getting 5 copies of a bunch of mails, through
the following debian-* lists: accessibility, boot, cd, devel,
project.
Needless to say: Reading, or marking a given mail as read once per
maildir rapidly becomes a burden.
Solution
I know some people use a duplicate killer at procmail time (hello
gregor) but I d rather keep all mails in their relevant maildirs.
So here s
mark-read-everywhere.pl
which seems to do the job just fine for my particular setup: all
maildirs below ~/mails/* with the usual cur, new, tmp
subdirectories.
Basically, given a mail piped from mutt, compute a hash on various
headers, look at all new mails (new subdirectories), and mark the
matching ones as read (move to the nearby cur subdirectories, and
change suffix from , to ,S).
Mutt key binding (where X is short for cross post):
macro index X "<pipe-message>~/bin/mark-as-read-everywhere.pl<enter>"
character), at least!
First, wrong intuition
Reading Apache s /etc/apache2/conf.d/charset it looks like the
following directive might help:
AddDefaultCharset UTF-8
text/plain and
text/html. The above directive would have to be combined with
something like this in /etc/apache2/mods-enabled/mime.conf:
AddType text/plain .pl
AddDefaultCharset and to associate the
UTF-8 charset with .pl files instead, keeping the text/x-perl
MIME type, with this single directive (again in
/etc/apache2/mods-enabled/mime.conf):
AddCharset UTF-8 .pl
wget -d) we re moving from:
Content-Type: text/x-perl
Content-Type: text/x-perl; charset=utf-8
:)
turn_servers: [
server:"turn:debrtc.org"
],websocket:
servers: 'wss://ws.sip5060.net',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30,
,
Actually, pending updates to JSCommunicator, you should see a brand new UI! But all the core stuff will be the same.
Architecture
Disclaimer: I m explaining my view of the JSCommunicator architecture, which currently may not be 100% correct. But so far it s been enough for me to make my modifications and additions to the code, so it could be of use. One I get a JSCommunicator Founding Father s stamp of approval, I ll be sure to confirm the accuracy.
Now to explain how the JSCommunicator code interacts, the use of each code item is described, ignoring all the html and css which will vary according to how you choose to use JSCommunicator. I m also not going to explain jQuery which is a dependency but not specific to WebRTC. The core JSCommunicator code is the following:
In sum, 1 - JSCommUI.js handles what is displayed in the UI and feeds data to JSCommManager.js; 2 - JSCommManager.js actually does stuff, feeding data to be displayed to JSCommUI.js; 3 - JSCommManager.js calls functions from the three utils , parseuri.js, webrtc-check.js and jssip-helpher.js which organizes the data from config.js; 4 - JSCommManager.js initializes a SIP User Agent based on the implementation in Arbiter.js.
When making any changes to JSCommunicator, you will likely only be working with JSCommUI.js and JSCommManager.js.
turn_servers: [
server:"turn:debrtc.org"
],websocket:
servers: 'wss://ws.sip5060.net',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30,
,# /etc/apt/sources.list deb http://llvm.org/apt/unstable/ llvm-toolchain main deb http://llvm.org/apt/unstable/ llvm-toolchain-3.4 main deb http://llvm.org/apt/unstable/ llvm-toolchain-3.5 main
$ apt-get install clang-3.4 clang-3.5 clang-3.6 $ clang-3.4 --version Debian clang version 3.4.2 (branches/release_34) (based on LLVM 3.4.2) Target: x86_64-pc-linux-gnu Thread model: posix $ clang-3.5 --version Debian clang version 3.5.0-+rc2-1~exp1 (tags/RELEASE_350/rc2) (based on LLVM 3.5.0) Target: x86_64-pc-linux-gnu Thread model: posix $ clang-3.6 --version Debian clang version 3.6.0-svn214990-1~exp1 (trunk) (based on LLVM 3.6.0) Target: x86_64-pc-linux-gnu Thread model: posix
For tedious reasons, I will at this stage point out that I was born in Galway, Ireland.function is_rackspace
if [ ! -f /usr/bin/xenstore-ls ]; then
return 1
fi
/usr/bin/xenstore-ls vm-data grep -q "Rackspace"
if is_rackspace; then
echo "I am on Rackspace"
fi
echo murata > /data/.cid.info chown system /data/.cid.info chgrp wifi /data/.cid.info chmod 0660 /data/.cid.infoDigging deeper, I found a CM Jira issue about it, and ultimately a code commit. It seems the issue is that more recent S3 s comes with a Murata Wifi chipset that uses MAC addresses not known back in the Android 4.2 (CM-10.1.3 and Replicant-4.2) days. Pulling in the latest fixes for macloader.cpp solves this problem for me, and there is no need for the workaround above. I still need to load the non-free firmware images that I get from CM-10.1.3. I ve created a pull request fixing macloader.cpp for Replicant 4.2 if someone else is curious about the details. You have to rebuild your OS with the patch for things to work (if you don t want to, the workaround using
/data/.cid.info works fine), and install some firmware blobs as below.
adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_apsta.bin_b1 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_apsta.bin_b2 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b0 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b1 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_mfg.bin_b2 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b0 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b1 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_p2p.bin_b2 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b0 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b1 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/bcmdhd_sta.bin_b2 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_murata /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_murata_b2 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_mfg.txt_semcosh /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_murata /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_murata_b2 /system/vendor/firmware/ adb push cm-10.1.3-i9300/system/etc/wifi/nvram_net.txt_semcosh /system/vendor/firmware/
A bit of history: A while ago udeb-producing packages were getting
frozen on a regular fashion, when a d-i release was about to be
cut. While I wasn t looking at the time, I can easily understand the
reasons behind that: d-i is built upon many components, it takes some
time to make sure it s basically in shape for a release, and it s very
annoying when a regression sneaks in right before the installation
images get built.
I took over d-i release maintenance in May 2012 and only a few uploads
happened before the wheezy freeze. I was only discovering the job at
the time, and I basically released whatever was in testing then. The
freeze began right after that (end of June), so I started double
checking things affecting d-i (in addition to or instead of the review
performed by other release team members), and unblocking packages when
changes seemed safe, or once they were tested.
A few uploads happened after the wheezy release and there s already
a Jessie Alpha 1 release. I was about to release Jessie Beta 1
after some fair bits of testing, a debian-installer upload, and the
only remaining bits were: building installation images (hello Steve),
and of course communication (mail announce and website update).
Unfortunately a new upstream release reached testing in the
meanwhile, breaking the installer in several ways. I ll give details
below, of course not because I want to point finger at the maintainer,
but to illustrate the ramifications that a single package s migrating to
testing can induce.
partman-* components:
#757661,
#757662,
#757663,
#757664,
#757665,
#757666.testing as soon as possible.debian-release@ and debian-boot@
asking for an unblock. I ll then review your particular package, and
either let it migrate to testing, or delay it until after the
release.
Update: official announcement.
kdb merge. The kdb tool allows users to access and perform functions on the Elektra Key Database from the command line. We added a new command to this very useful tool, the merge command. This command allows a user to perform a three-way merge of KeySets from the kdb tool.
kdb merge [options] ourpath theirpath basepath resultpath
-i --interactive which attempts the merge in an interactive way
-t --test which tests the proposed merge and informs you about possible conflicts
-f --force which overwrites any Keys in resultpath
s --strategy which is used to specify a strategy to use in case of a conflict
preserve the merge will fail if a conflict is detected
ours the merge will use our version during a conflict
theirs the merge will use their version during a conflict
base the merge will use the base version during a conflict
kdb merge command:
kdb merge -s ours system/hosts/ours system/hosts/theirs system/hosts/base system/hosts/result
Next.