Here s my (fifteenth) monthly update about the activities I ve done in the F/L/OSS world.

Debian

This was my 24th month of contributing to Debian. I became a DM in late March last year and a DD last Christmas! \o/ Amongs a lot of things, this was month was crazy, hectic, adventerous, and the last of 2020 more on some parts later this month.
I finally finished my 7th semester (FTW!) and moved onto my last one! That said, I had been busy with other things but still did a bunch of Debian stuff Here are the following things I did this month:

Uploads and bug fixes:

• leiningen-clojure (2.9.1-3) - Fixing FTBFS, bug #973094.
• ruby-gh (0.18.0-2) - Fixing FTBFS, bug #976163.
• libgit2 (1.0.1+dfsg.1-3) - libgit2 transition; cf: bug #971571.
• libgit-raw-perl (0.87+ds-1) - Transition upload for bug #971567.
• python-pygit2 (1.3.0+dfsg1-2) - Transition upload for bug #971564.
• golang-gopkg-libgit2-git2go.v30 (30.3.2-1) - Transition upload for bug #976522.
• libgit2 (1.1.0+dfsg.1-1) - New upstream version, v1.1.0.
• golang-gopkg-libgit2-git2go.v31 (31.4.3-1) - Transition upload for bug #976522.
• libgit2 (1.1.0+dfsg.1-2) - libgit2 transition; cf: bug #971571.
• python-pygit2 (1.4.0+dfsg1-1) - New upstream version, v1.4.0.
• ruby-rugged (1.1.0+ds-1) - Transition upload for bug #971565.
• rails (2:6.0.3.4+dfsg-2) - Fixes for bug #976291 and 974065. Thanks, Praveen!
• ruby3.0 (3.0.0~preview2-1) - New upstream version, v3.0.0~preview2.
• golang-github-robertkrimen-otto (0.0~git20200922.ef014fd-1) - Fixing FTBFS, bug #976549.
• bidi-clojure (2.1.3-2) - Fixing FTBFS, bug #975224.
• comidi-clojure (0.3.2-2) - Fixing FTBFS, bug #975218.
• ruby3.0 (3.0.0~rc1-1) - New upstream version, v3.0.0~rc1.
• polybar (3.5.3-1) - New upstream version, v3.5.3.
• ruby3.0 (3.0.0-1) - New upstream version, v3.0.0. Merry Christmas! \o/
• pathetic-clojure (0.5.1-2) - Source-only upload for migration.
• url-clojure (0.1.1-2) - Source-only upload for migration.
• libgit2 (1.1.0+dfsg.1-3) - Fix for bug #972574. Thanks, Cedric!
• ruby-paper-trail (11.1.0-1) - New upstream version, 11.1.0.

Other $things:

• Attended the Debian Ruby team meeting.
• Mentoring for newcomers.
• FTP Trainee reviewing.
• Moderation of -project mailing list.
• Sponsored golang-github-gorilla-css for Fedrico.

---

Debian (E)LTS

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my fifteenth month as a Debian LTS and sixth month as a Debian ELTS paid contributor.
I was assigned 26.00 hours for LTS and 38.25 hours for ELTS and worked on the following things:

LTS CVE Fixes and Announcements:

• Issued DLA 2474-1, fixing CVE-2020-28928, for musl.
  For Debian 9 Stretch, these problems have been fixed in version 1.1.16-3+deb9u1.
• Issued DLA 2481-1, fixing CVE-2020-25709 and CVE-2020-25710, for openldap.
  For Debian 9 Stretch, these problems have been fixed in version 2.4.44+dfsg-5+deb9u6.
• Issued DLA 2484-1, fixing #969126, for python-certbot.
  For Debian 9 Stretch, these problems have been fixed in version 0.28.0-1~deb9u3.
• Issued DLA 2487-1, fixing CVE-2020-27350, for apt.
  For Debian 9 Stretch, these problems have been fixed in version 1.4.11. The update was prepared by the maintainer, Julian.
• Issued DLA 2488-1, fixing CVE-2020-27351, for python-apt.
  For Debian 9 Stretch, these problems have been fixed in version 1.4.2. The update was prepared by the maintainer, Julian.
• Issued DLA 2495-1, fixing CVE-2020-17527, for tomcat8.
  For Debian 9 Stretch, these problems have been fixed in version 8.5.54-0+deb9u5.
• Issued DLA 2488-2, for python-apt.
  For Debian 9 Stretch, these problems have been fixed in version 1.4.3. The update was prepared by the maintainer, Julian.
• Issued DLA 2508-1, fixing CVE-2020-35730, for roundcube.
  For Debian 9 Stretch, these problems have been fixed in version 1.2.3+dfsg.1-4+deb9u8. The update was prepared by the maintainer, Guilhem.

ELTS CVE Fixes and Announcements:

• Issued ELA 324-1, fixing CVE-2020-28928, for musl.
  For Debian 8 Jessie, these problems have been fixed in version 1.1.5-2+deb8u2.
• Issued ELA 325-1, fixing CVE-2020-28896, for mutt.
  For Debian 8 Jessie, these problems have been fixed in version 1.5.23-3+deb8u4.
• Issued ELA 327-1, fixing CVE-2020-25709 and CVE-2020-25710, for openldap.
  For Debian 8 Jessie, these problems have been fixed in version 2.4.40+dfsg-1+deb8u8.
• Issued ELA 335-1, fixing CVE-2020-0499, for flac.
  For Debian 8 Jessie, these problems have been fixed in version 1.3.0-3+deb8u1.
• Issued ELA 340-1, fixing CVE-2020-35492, for cairo.
  For Debian 8 Jessie, these problems have been fixed in version 1.14.0-2.1+deb8u3.

Other (E)LTS Work:

• Front-desk duty from 21-12 until 27-12 and from 28-12 until 03-01 for both LTS and ELTS.
• Triaged openldap, python-certbot, lemonldap-ng, qemu, gdm3, open-iscsi, gobby, jackson-databind, wavpack, cairo, nsd, tomcat8, and bountycastle.
• Marked CVE-2020-17527/tomcat8 as not-affected for jessie.
• Marked CVE-2020-28052/bountycastle as not-affected for jessie.
• Marked CVE-2020-14394/qemu as postponed for jessie.
• Marked CVE-2020-35738/wavpack as not-affected for jessie.
• Marked CVE-2020-3550 3-6 /qemu as postponed for jessie.
• Marked CVE-2020-3550 3-6 /qemu as postponed for stretch.
• Marked CVE-2020-16093/lemonldap-ng as no-dsa for stretch.
• Marked CVE-2020-27837/gdm3 as no-dsa for stretch.
• Marked CVE-2020- 13987, 13988, 17437 /open-iscsi as no-dsa for stretch.
• Marked CVE-2020-35450/gobby as no-dsa for stretch.
• Marked CVE-2020-35728/jackson-databind as no-dsa for stretch.
• Marked CVE-2020-28935/nsd as no-dsa for stretch.
• Auto EOL ed libpam-tacplus, open-iscsi, wireshark, gdm3, golang-go.crypto, jackson-databind, spotweb, python-autobahn, asterisk, nsd, ruby-nokogiri, linux, and motion for jessie.
• General discussion on LTS private and public mailing list.

---

Other $things! \o/

Bugs and Patches Well, I did report some bugs and issues and also sent some patches:

• Issue #44 for github-activity-readme, asking for a feature request to set custom committer s email address.
• Issue #711 for git2go, reporting build failure for the library.
• PR #89 for rubocop-rails_config, bumping RuboCop::Packaging to v0.5.
• Issue #36 for rubocop-packaging, asking to try out mutant :)
• PR #212 for cucumber-ruby-core, bumping RuboCop::Packaging to v0.5.
• PR #213 for cucumber-ruby-core, enabling RuboCop::Packaging.
• Issue #19 for behance, asking to relax constraints on faraday and faraday_middleware.
• PR #37 for rubocop-packaging, enabling tests against ruby3.0! \o/
• PR #489 for cucumber-rails, bumping RuboCop::Packaging to v0.5.
• Issue #362 for nheko, reporting a crash when opening the application.
• PR #1282 for paper_trail, adding RuboCop::Packaging amongst other used extensions.
• Bug #978640 for nheko Debian package, reporting a crash, as a result of libfmt7 regression.

Misc and Fun Besides squashing bugs and submitting patches, I did some other things as well!

• Participated in my first Advent of Code event! :)
  Whilst it was indeed fun, I didn t really complete it. No reason, really. But I ll definitely come back stronger next year, heh! :)
  All the solutions thus far could be found here.
• Did a couple of reviews for some PRs and triaged some bugs here and there, meh.
• Also did some cloud debugging, not so fun if you ask me, but cool enough to make me want to do it again! ^_^
• Worked along with pollo, zigo, ehashman, rlb, et al for puppet and puppetserver in Debian. OMG, they re so lovely! <3
• Ordered some interesting books to read January onward. New year resolution? Meh, not really. Or maybe. But nah.
• Also did some interesting stuff this month but can t really talk about it now. Hopefully sooooon.

---

Until next time.
:wq for today.

See the Conclusion for a summary if you re impatient :-)

Motivation Over the last few months, I have been developing a new index format for Debian Code Search. This required a lot of careful refactoring, re-implementation, debug tool creation and debugging. Multiple factors motivated my work on a new index format:

1. The existing index format has a 2G size limit, into which we have bumped a few times, requiring manual intervention to keep the system running.
2. Debugging the existing system required creating ad-hoc debugging tools, which made debugging sessions unnecessarily lengthy and painful.
3. I wanted to check whether switching to a different integer compression format would improve performance (it does not).
4. I wanted to check whether storing positions with the posting lists would improve performance of identifier queries (= queries which are not using any regular expression features), which make up 78.2% of all Debian Code Search queries (it does).

I figured building a new index from scratch was the easiest approach, compared to refactoring the existing index to increase the size limit (point ). I also figured it would be a good idea to develop the debugging tool in lock step with the index format so that I can be sure the tool works and is useful (point ).

Integer compression: TurboPFor As a quick refresher, search engines typically store document IDs (representing source code files, in our case) in an ordered list ( posting list ). It usually makes sense to apply at least a rudimentary level of compression: our existing system used variable integer encoding. TurboPFor, the self-proclaimed Fastest Integer Compression library, combines an advanced on-disk format with a carefully tuned SIMD implementation to reach better speeds (in micro benchmarks) at less disk usage than Russ Cox s varint implementation in github.com/google/codesearch. If you are curious about its inner workings, check out my TurboPFor: an analysis . Applied on the Debian Code Search index, TurboPFor indeed compresses integers better:

Disk space

8.9G codesearch varint index

5.5G TurboPFor index Switching to TurboPFor (via cgo) for storing and reading the index results in a slight speed-up of a dcs replay benchmark, which is more pronounced the more i/o is required.

Query speed (regexp, cold page cache)

18s codesearch varint index

14s TurboPFor index (cgo)

Query speed (regexp, warm page cache)

15s codesearch varint index

14s TurboPFor index (cgo) Overall, TurboPFor is an all-around improvement in efficiency, albeit with a high cost in implementation complexity.

Positional index: trade more disk for faster queries This section builds on the previous section: all figures come from the TurboPFor index, which can optionally support positions. Conceptually, we re going from:

type docid uint32
type index map[trigram][]docid

to:

type occurrence struct  
    doc docid
    pos uint32 // byte offset in doc
 
type index map[trigram][]occurrence

The resulting index consumes more disk space, but can be queried faster:

1. We can do fewer queries: instead of reading all the posting lists for all the trigrams, we can read the posting lists for the query s first and last trigram only.
   This is one of the tricks described in the paper AS-Index: A Structure For String Search Using n-grams and Algebraic Signatures (PDF), and goes a long way without incurring the complexity, computational cost and additional disk usage of calculating algebraic signatures.
2. Verifying the delta between the last and first position matches the length of the query term significantly reduces the number of files to read (lower false positive rate).
3. The matching phase is quicker: instead of locating the query term in the file, we only need to compare a few bytes at a known offset for equality.
4. More data is read sequentially (from the index), which is faster.

Disk space A positional index consumes significantly more disk space, but not so much as to pose a challenge: a Hetzner EX61-NVME dedicated server ( 64 /month) provides 1 TB worth of fast NVMe flash storage.

6.5G non-positional

123G positional

93G positional (posrel) The idea behind the positional index (posrel) is to not store a (doc,pos) tuple on disk, but to store positions, accompanied by a stream of doc/pos relationship bits: 1 means this position belongs to the next document, 0 means this position belongs to the current document. This is an easy way of saving some space without modifying the TurboPFor on-disk format: the posrel technique reduces the index size to about . With the increase in size, the Linux page cache hit ratio will be lower for the positional index, i.e. more data will need to be fetched from disk for querying the index. As long as the disk can deliver data as fast as you can decompress posting lists, this only translates into one disk seek s worth of additional latency. This is the case with modern NVMe disks that deliver thousands of MB/s, e.g. the Samsung 960 Pro (used in Hetzner s aforementioned EX61-NVME server). The values were measured by running dcs du -h /srv/dcs/shard*/full without and with the -pos argument.

Bytes read A positional index requires fewer queries: reading only the first and last trigram s posting lists and positions is sufficient to achieve a lower (!) false positive rate than evaluating all trigram s posting lists in a non-positional index. As a consequence, fewer files need to be read, resulting in fewer bytes required to read from disk overall. As an additional bonus, in a positional index, more data is read sequentially (index), which is faster than random i/o, regardless of the underlying disk.

1.2G

19.8G

21.0G regexp queries

4.2G (index)

10.8G (files)

15.0G identifier queries The values were measured by running iostat -d 25 just before running bench.zsh on an otherwise idle system.

Query speed Even though the positional index is larger and requires more data to be read at query time (see above), thanks to the C TurboPFor library, the 2 queries on a positional index are roughly as fast as the n queries on a non-positional index ( 4s instead of 3s). This is more than made up for by the combined i/o matching stage, which shrinks from 18.5s (7.1s i/o + 11.4s matching) to 1.3s.

3.3s (index)

7.1s (i/o)

11.4s (matching)

21.8s regexp queries

3.92s (index)

1.3s

5.22s identifier queries Note that identifier query i/o was sped up not just by needing to read fewer bytes, but also by only having to verify bytes at a known offset instead of needing to locate the identifier within the file.

Conclusion The new index format is overall slightly more efficient. This disk space efficiency allows us to introduce a positional index section for the first time. Most Debian Code Search queries are positional queries (78.2%) and will be answered much quicker by leveraging the positions. Bottomline, it is beneficial to use a positional index on disk over a non-positional index in RAM.

The cisco.iosxr collection from Ansible Galaxy provides an iosxr_user module to manage local users, along with their SSH keys. However, the module is quite slow, do not display a diff for changed SSH keys, never signal change when a key is modified, and does not delete obsolete keys. Let s write a custom Ansible module managing only the SSH keys while fixing these issues.

How to add an SSH key to a user Adding SSH keys to users in Cisco IOS-XR is quite undocumented. First, you need to encode the key with the ssh-rsa key ASN.1 format, like an OpenSSH public key, but without the base64-encoding:

$ awk ' print $2 ' id_rsa.pub \
      base64 -d \
    > publickey_vincent.raw

Then, you upload the key with SCP to harddisk:/publickey_vincent.raw and import it for the current user with the following IOS command:

crypto key import authentication rsa harddisk:/publickey_vincent.b64

However, if you want to import a key for another user, you need to be part of the root-system group:

username vincent
 group root-lr
 group root-system

With the following admin command, you can attach a key to another user:

admin crypto key import authentication rsa username cedric harddisk:/publickey_cedric.b64

Code The module has the following signature and it installs the specified key for each user and remove keys from retired users the ones we do not specify.

iosxr_users:
  keys:
    vincent: ssh-rsa AAAAB3NzaC1yc2EAA[ ]ymh+YrVWLZMJR
    cedric:  ssh-rsa AAAAB3NzaC1yc2EAA[ ]RShPA8w/8eC0n

Prerequisites Unlike the iosxr_user module, our custom module only handles SSH keys, one per user. Therefore, the user definitions have to already exist in the running configuration.¹ Moreover, the user defined in ansible_user needs to be in the root-system group. The cisco.iosxr collection must also be installed as the module relies on its code. When running the module, ansible_connection needs to be set to network_cli and ansible_network_os to iosxr. These variables are usually defined in the inventory.

Module definition Starting from the skeleton described in the previous article, we define the module:

module_args = dict(
    keys=dict(type='dict', elements='str', required=True),
)
module = AnsibleModule(
    argument_spec=module_args,
    supports_check_mode=True
)
result = dict(
    changed=False
)

Getting the installed keys The next step is to retrieve the keys currently installed. This can be done with the following command:

# show crypto key authentication rsa all
Key label: vincent
Type     : RSA public key authentication
Size     : 2048
Imported : 16:17:08 UTC Tue Aug 11 2020
Data     :
 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
 00D81E5B A73D82F3 77B1E4B5 949FB245 60FB9167 7CD03AB7 ADDE7AFE A0B83174
 A33EC0E6 1C887E02 2338367A 8A1DB0CE 0C3FBC51 15723AEB 07F301A4 B1A9961A
 2D00DBBD 2ABFC831 B0B25932 05B3BC30 B9514EA1 3DC22CBD DDCA6F02 026DBBB6
 EE3CFADA AFA86F52 CAE7620D 17C3582B 4422D24F D68698A5 52ED1E9E 8E41F062
 7DE81015 F33AD486 C14D0BB1 68C65259 F9FD8A37 8DE52ED0 7B36E005 8C58516B
 7EA6C29A EEE0833B 42714618 50B3FFAC 15DBE3EF 8DA5D337 68DAECB9 904DE520
 2D627CEA 67E6434F E974CF6D 952AB2AB F074FBA3 3FB9B9CC A0CD0ADC 6E0CDB2A
 6A1CFEBA E97AF5A9 1FE41F6C 92E1F522 673E1A5F 69C68E11 4A13C0F3 0FFC782D
 27020301 0001
[ ]

ansible_collections.cisco.iosxr.plugins.module_utils.network.iosxr.iosxr contains a run_commands() function we can use:

command = "show crypto key authentication rsa all"
out = run_commands(module, command)
out = out[0].replace(' \n', '\n')

A common library to parse a command output is textfsm: a Python module using a template-based state machine for parsing semi-formatted text.

template = r"""
Value Required Label (\w+)
Value Required,List Data ([A-F0-9 ]+)
Start
 ^Key label: $ Label 
 ^Data\s+: -> GetData
GetData
 ^ $ Data 
 ^$$ -> Record Start
""".lstrip()
re_table = textfsm.TextFSM(io.StringIO(template))
got =  data[0]: "".join(data[1]).replace(' ', '')
       for data in re_table.ParseText(out) 

got is a dictionary associating key labels, considered as usernames, with a hexadecimal representation of the public key currently installed. It looks like this:

>>> pprint(got)
 'alfred': '30820122300D0609[ ]6F0203010001',
 'cedric': '30820122300D0609[ ]710203010001',
 'vincent': '30820122300D0609[ ]270203010001' 

Comparing with the wanted keys Let s now build the wanted dictionary using the same structure. In module.params['keys'], we have a dictionary associating usernames to public SSH keys in the OpenSSH format:

>>> pprint(module.params['keys'])
 'cedric': 'ssh-rsa AAAAB3NzaC1yc2[ ]',
 'vincent': 'ssh-rsa AAAAB3NzaC1yc2[ ]' 

We need to convert these keys in the same hexadecimal representation used by Cisco above. The ssh-keygen command and some glue can do the conversion:²

$ ssh-keygen -f id_rsa.pub -e -mPKCS8 \
     grep -v '^---' \
     base64 -d \
     hexdump -e '4/1 "%0.2X"'
30820122300D06092[ ]782D270203010001

Assuming we have a ssh2cisco() function doing that, we can build the wanted dictionary:

wanted =  k: ssh2cisco(v)
          for k, v in module.params['keys'].items() 

Applying changes Back to the skeleton described in the previous article, the last step is to apply the changes if there is a difference between got and wanted when not running with check mode. The part comparing got and wanted is taken verbatim from the skeleton module:

if got != wanted:
    result['changed'] = True
    result['diff'] = dict(
        before=yaml.safe_dump(got),
        after=yaml.safe_dump(wanted)
    )
if module.check_mode or not result['changed']:
    module.exit_json(**result)

Let s copy the new or changed keys and attach them to their respective users. For this purpose, we reuse the get_connection() and copy_file() functions from ansible_collections.cisco.iosxr.plugins.module_utils.network.iosxr.iosxr.

conn = get_connection(module)
for user in wanted:
    if user not in got or wanted[user] != got[user]:
        dst = f"/harddisk:/publickey_ user .raw"
        with tempfile.NamedTemporaryFile() as src:
            decoded = base64.b64decode(
                module.params['keys'][user].split()[1])
            src.write(decoded)
            src.flush()
            copy_file(module, src.name, dst)
    command = ("admin crypto key import authentication rsa "
               f"username  user   dst ")
    conn.send_command(command, prompt="yes/no", answer="yes")

Then, we remove obsolete keys:

for user in got:
    if user not in wanted:
        command = ("admin crypto key zeroize authentication rsa "
                   f"username  user ")
        conn.send_command(command, prompt="yes/no", answer="yes")

---

The complete code is available on GitHub. Compared to the iosxr_user module, this one displays a diff when running with --diff, correctly signals a change, is faster, ³ and deletes unwanted SSH keys. However, it is unable to create users and cannot configure passwords or multiple SSH keys.

---

1. In our environment, the Ansible playbook pushes a full configuration, including the user definitions. Then, it synchronizes the SSH keys.
2. Despite the argument provided to ssh-keygen, the format used by Cisco is not PKCS#8. This is the ASN.1 representation of a Subject Public Key Info structure, as defined in RFC 2459. Moreover, PKCS#8 is a format for a private key, not a public one.
3. The main factors for being faster are:
   • not creating users, and
   • not reuploading existing SSH keys.

Here it is. Debian had seven hundred thousand bugs reported in its history. Yet another French winner, indeed two, this time:

• Cedric Boutillier is the winner in the "race of bug #700000" by reporting "override: libzoom-ruby:oldlibs/extra libzoom-ruby1.8:oldlibs/extra" against ftp.debian.org, as part of a quite massive bunch of wishlist bug reports to deal cleanly with old transitional Ruby packages. I somehow suspect C dric retained his bug reports to catch the right moment..:-)
• I won the bet about the day this bug report would happen by missing it only by 7 days: I did bet for February 14th 2013, two years after the release of squeeze and I was secretely expecting we would also release wheezy around that time.

The French gang already got #200000 (by Michel Grentzinger) and #400000 (by /me), and #600000 by Cyril "KiBi" Brulebois. We're good at stupid games, as it seems. Of course, I will soon open the wiki page for the bug #800000 bet, which will again include a place where you can also bet for bug #1000000. Be patient, the week-end is coming..:-)

Here it is. Debian had seven hundred thousand bugs reported in its history. Yet another French winner, indeed two, this time:

• Cedric Boutillier is the winner in the "race of bug #700000" by reporting "override: libzoom-ruby:oldlibs/extra libzoom-ruby1.8:oldlibs/extra" against ftp.debian.org, as part of a quite massive bunch of wishlist bug reports to deal cleanly with old transitional Ruby packages. I somehow suspect C dric retained his bug reports to catch the right moment..:-)
• I won the bet about the day this bug report would happen by missing it only by 7 days: I did bet for February 14th 2013, two years after the release of wheezy and I was secretely expecting we would also release wheezy around that time.

The French gang already got #200000 (by Michel Grentzinger) and #400000 (by /me), and #600000 by Cyril "KiBi" Brulebois. We're good at stupid games, as it seems. Of course, I will soon open the wiki page for the bug #800000 bet, which will again include a place where you can also bet for bug #1000000. Be patient, the week-end is coming..:-)

Most of the day before the conference, and the conference morning spent working and finalizing my RTL status presentation. My apologies to the lecturers whose lectures I attend only physically (sorry, I can t split my attention too well). To my disappointment I had very few attendees in the talk, but I can understand the competition, as the other parallel talks were quite interesting. In at least one of them I wished to attend my self (if I could only be in two places in the same time ). Maybe next year we should have less parallel talks (4 tacks is a lot). To still push some of the RTL issues, I ve done a private talk over RTL issues for Caolan and Jan (kendy), which was interesting with some feedback. Jan took fdo#44657 on himself, and by the evening he showed me a great improvement in the status of things, so at least there s horizontal scrolling in Calc with RTL interface. With the help of Rene, I got master builds for Debian, and would spend the rest of the conference to check some bugs with it. During the evening dinner and social event I wanted to thank Miklos personally for really improving the RTF support for RTL and Hebrew documents, and he showed me a few of the new stuff he d done in master/3.7. While working I ve noticed a few regressions, and I m glad they were caught early. Cedric told me that after last years talk, he started to check his features also in RTL interface, which for me was the best feedback on my efforts. Having developers keeping RTL in mind (even only nce in a while) saves a lot of trouble along the road. I would prefer to check and double check features while they re being created instead of trying to get bugs fixed later on the release process. Another thing which I enjoyed noticing is the fresh blood the GSoC project brings to LibreOffice. I ve met with Miklos and Eilidh and got impressed with how a successful internship was used as a springboard into a good job. As there almost aren t any Israelis who take part in GSoC, I m not used to notice the effect closely. The event dinner and mingling was very successful for me, I ve got a chance to talk with old friends and meet some of the new attendees (and even get some technical work done by talking with people) Thanks again for the organizational team.
Filed under: LibreOffice

I've uploaded a CVS snapshot of abook yesterday to experimental. C dric Duval did commit really useful stuff there, like the possibility for user defined fields and views, renaming the custom fields, and lists which can contain a quite big amount of entries. It would be nice if you could give it some testing and send in feedback about it so that I have more than just my own impression about it for deciding if it's ready to upload to unstable for it making it into the release of etch.
Some things I've noticed so far: You can't use a comma in lists because it is used as field separator. Yes, this needs to get changed, but it is no real regression, because the only list used before was the email addresses and you wasn't able to use it there neither. The date field type isn't yet completely supported — it is planed to have content checking in it, I could think of having flexible display ways for date fields, too. So far it has its reason why it isn't released yet upstream, it has its problem, but I think it is still a great advancement over the current stable release and would make sense to get included in etch. Give it a try and report back, either to me or to the upstream list.