Lennart Poettering gave this interview where he said some thing which lead me to the conclusion that he misunderstood some things about unix.

So I do not want to bash systemd or Lennart himself here. This is not a “I hate systemd” article, to be honest, I even like systemd. I acknowledge that a lot of people hate systemd for specific reasons, and I even can agree to a certain degree with some of these points, but overall, I do not hate it.

Everything is a file. Yes it is.

Lets talk about the article from above. There are two things I want to talk about here. The first one is the everything-is-a-file concept:

One of the most well-known concepts that people often cite about Unix is that everything’s a file. I personally think that’s a complete bullshit thing. That’s because everything is not a file. My printer is not a file and if Unix pretends that my printer is a file, that’s complete rubbish because a file is a very different thing.

The above quote is from the article.

I think that Lennart completely misunderstood what the concept is here. Yes, in Unix “everything is a file”. But, in my understanding, this is not a rule but rather an abbreviation to explain an abstraction. The “everything is a file”-thingy is nothing more than a way to interface with things. Fundamentally, there is not such thing like a “printer” or “graphics card” - at least there is no other way to represent those in a operating system, besides a file.

Unix does not say that everything is a file (note the missing quotes in this sentence). It says that files are the interfaces for all the things. The actual quote

Everything is a file.

is just a way to tell users in a short and time-saving manner how Unix abstracts hardware.

Lennart continues...

He said that most people who are programmers will eventually learn about object-oriented programming, hopefully at university or another school. They will find that the most abstract concept that object-oriented programming has, how it sees the world, is generally the object.

which I hope will never be the case. Object orientation is dead.

Do one thing! Do it well!

The second point I want to talk about here is the idea of Unix that a program should do one thing only but do it well.

Lennart says

People often complain that systemd has one large repository where a lot of components are living in one source code repository. They think that is not Unix and that’s actually the greatest rubbish of all. Because if you look at BSDs, which unlike Linux are actually true Unixes, they all maintain pretty much the entire Kernel and user space in one single source code repository. Contrary to what people think, in Unix, everything ended up being maintained in one repository, just like systemd.

which also completely misses the point.

The whole idea is not that everything should be kept in small repositories and cleanly seperated – I really do not care whether my system comes from one giant repository or from hundreds or even thousands of repositories. And I bet nobody does.

What people are complaining about is that systemd does not do only one job. systemd does not have one concern but many. Is it an init system? Is it a service/job control system? Is it a bootloader? Is it a time synchronization application? Is it a package manager? Is it a printer daemon? Is it a container/virtualization layer/helper/manager? Is it a <insert thing>? No, it is not – and yes, it is all of them. And exactly that is the problem people complain about. It doesn't seperate concerns.

Conclusion

I know that Lennart has always an open ear for concerns and critical voices - at least he once wrote that.

I guess he got some things wrong here and I hope that if he sees that he will understand the concerns of the broader community.

---

Please note that this is my view on the things. I'm also just human and I might got things wrong here(, too). I'm more than happy to learn, so if you have anything you want to talk to me about, feel free to send me an email. I know the topics I scratched here are more than emotionally discussed in the community. Because of this: Please keep it calm if you send me an email, keep it technical. I will happily ignore emotional stuff.

Tags: #linux

This is the 21th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happenend?

Well, as I said before, I have a really busy masters degree to do, so progress in imag slowed down a lot. Believe me or not, I don't like that. I want to continue to work on imag as much as possible, but right now, I just do not have enough time for it.

I have a plan, though.

But first, lets see what happenend in the last four weeks.

PRs/Issues

The following issues and PRs were touched in the last weeks:

• #764 initialized the work on imag-mail
• #838 bumped up the clap version
• #839 updated dependencies
• #840 works on bulk-import for imag-mail
• #841 is a bug report on the behaviour of imag link internal --list
• #842 fixes #841
• #843 fixes another small bug in a UI
• #844 fixes a typo
• #845 adds Makefile support for cargo-outdated

What will happen

Well, I cannot predict the future. As Christmas (and 33c3) is coming up, I don't know how much time I will have to work on imag.

But what I want to do: Shift my focus a bit. Before I had a kind of Shotgun-Approach: Implement everything, work on multiple things all the time. I will not do this anymore. In fact, I will move issues from the 0.3.0 release to 0.4.0 and so on, shift everything by one release. That will free the 0.3.0 release and I will focus on one goal in this release then: A scripting API.

I want to develop an imag library for writing scripts for imag. I think about Ruby, because that's a language I am familiar with. Another option would be Lua. I hope I can construct the scripting-API interface in a way so it can be re-used to write a Lua interface.

But that will it be for 0.3.0. Having a neat scripting API (not low-level but rather high-level) gives us the possibility to quickly write simple integrations with tools, for example to integrate mails, a wiki or something similar.

I hope that's a plan. 0.3.0 is due to March 2017 as far as I remember, so there's plenty of time for this.

My next post will be around mid-january 2017, so I think it is appropriate to wish you all a very fine Christmas and a good new year!

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 20th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

Also, I have some changes to this series of blog posts. Read about it here as well.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

In the past two weeks, we got almost nothing done, honestly. We had four pull requests and no new issues. Why is that? Well, most of the PRs are mine as well as most of the issues are opened by me. And I have a hell lot to do with my masters degree. Also, I want to write pull requests to the rust-vobject crate to give it a high-level interface to be able to write my calendar and contacts module with it. This is, as you might think, a nontrivial task and therefor take some time as well.

We had one new contributor though. Thanks to Steven Allen for PR #834.

That's why we didn't have that much progress. I will sum it up here:

• 834 optimized one point in libimagutil where I opened one file twice. Thanks again, Steven Allen, for the contribution!
• 835 moved the functionality of the EntryHeader (the querying by string in the header toml data structure) to a new libimagstore module, so the module libimagstore::store does only contain a minimal EntryHeader type for backwards compatibility.
• 836 eliminates the EntryHeader type completely and replaces it by toml::Value, its inner type. This is not completed at the time of writing.
• 837 adds older compilers to the CI setup for travis.

The future

Lets see what will happen in the next four weeks.

Yes, that's right. I will do...

Less updates

I will slow down this blogging series. This was the 20th iteration on the subject, so I already do this for 40 weeks now. I will now slow this down and only post every four weeks about imag. Partly because my masters degree is really time consuming, partly because I already planned this beforehand. Every four weeks will be enough, I guess. I'm not sure whether I will continue include all PRs and issues or only the major ones. We'll see.

Plans

For the next four weeks I plan to get some functionality into rust-vobject. I will then start to implement imag-contact and I hope to get some progress with imag-mail, but I cannot promise anything.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 19th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

We have more than 150 stars now! Wow!

Besides that we had really not that much progress in the last 14 days. My masters degree keeps me busy all day long and I really have a hard time with all the things I have to do for my courses, so progress slows down way more than I expected. But I can't change that, so ...

PRs merged/closed in the last 14 days

• 821 imported commits from our v0.2.0 release branch into the master branch.
• 822 updates our dependencies. Luckily this worked without too much hassle. Still, we had some problems while updating. We only had to update a method from itertools which was removed. We also had to update task-hookrs as both imag and task-hookrs depend on uuid and they really should depend on the same version of uuid, so I updated task-hookrs to the latest uuid, which in fact included some code removal in the codebase of task-hookrs. This was because uuid depends (and we also need it) on serde, which was update from 0.7.* to 0.8.*. As serde included some new awesome things, we were able to remove some code in task-hookrs.
• 823
• 827 implements PartialEq on StoreId, which is a really neat improvement in my opinion. We derive()d it before, but we now only compare the local part of the StoreId object (read: The store-part, not the path to the store itself, which could be absent sometimes, causing weird bugs).
• 828
• 829
• 831

Also, two really old PRs were closed. I do not list older PRs normally, but these two are really noteworthy:

• 624 included cargo workspace support in our build setup. I'm not sure it works the way I expected it to, as (for example) clap gets rebuild several times... but at least cargo doesn't yell at us anymore, so I included it.
• 656 sets the codegen units for rustc to 2. I hope we get slightly better build times on travis from that.

PRs opened in the last 14 days and not yet closed

• 824
• 826 bakes in shell completion generation for all the imag-* tools
• 832 – now, this is a really great PR from mario-kr. Mario found a way to build shell completion for all the imag tools, starting at the imag binary itself. I did not even think about this as solution, but it works and I'm willing to merge this as soon as Mario did some cleanup work in the PR. What he did is: He include()d all ui.rs files, where we (more or less by accident) always used the same function name to build the clap:App: build_ui(App) -> App. He includes these source files via a neat macro as sub modules and is then able to call all these build_ui functions to build a App object (with subcommands for each imag module). From that App object, he can retrieve the bash/fish/zsh completion (at build time). This is awesome!
• 833

Issues opened and already closed

As far as I see, we had no issues opened in the last 14 days that were also closed within theses two weeks.

Maybe in the next iteration again.

The future

Lets have a quick look what the future might bring us in the imag codebase.

Issues opened and not yet closed

• 830 was our only issue we opened in the last 14 days. It wants a rewrite of all the *.sh scripts we use to test binaries. These scripts really should be rewritten in Rust, we now have the ability to do tests in-memory, so there shouldn't be any issues with implementing these things in Rust. It is really a trivial task (not for a complete rust beginner IMO), so I'll not start implementing this soon, so others can step up.

Other things

As said above, I have a lot to do for my masters degree, so I cannot tell how much we can get done in the next two weeks. I'd love to see some progress with the email module, so we can merge this one at least, but I cannot promise it, sadly.

This does not mean I'm not interested in imag anymore. I'm interested even more in it. I just do not have enough time at the moment to do all the things I want to do.

tags: #linux #open source #programming #rust #software #tools #imag

I could not think of a better title, I'm sorry.

These are notes how to create a kernel which can be booted in qemu and pass a drive to it which has loadable kernel modules.

The idea

I wanted to play around with the linux kernel and write a minimal filesystem inside the kernel tree. I wanted to boot the kernel in a QEMU, as I do not want to mess with my running kernel.

Here are the steps I did (on a debian VM I run on my universitys infrastructure).

Setup

sudo apt-get install build-essential bc git gcc
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
make x86_64_defconfig
make kvmconfig
make menuconfig

The last step brings up the kernel configuration interface, which I used to enable SATA (Device Drivers -> Serial ATA and Parallel ATA drivers (libata) -> Generic ATA support) support which is needed to be able to mount a device into the qemu instance, where we can put things to play around with in the VM.

I then did a make -j 16 (if you have not 8 cores, use a lower number).

While the kernel compiled, I created a busybox initramfs. I used this blog article for how to do it. I'll dump in the commands from the blog article, for detailed information, go and read it, it's a really good article. I didn't do the speed-optimizing things, as the QEMU boots fast enough for me (~3 seconds).

(I used the latest busybox, but I don't see why it should work with the one from the article, which is about two versions old)

curl http://busybox.net/downloads/busybox-1.23.2.tar.bz2 | tar xjf -
cd busybox-1.23.2
mkdir -pv /tmp/obj/busybox-x86
make O=/tmp/obj/busybox-x86 defconfig
make O=/tmp/obj/busybox-x86 menuconfig # See below why
cd /tmp/obj/busybox-x86
make -j 16

# it does not install in your system, so you can execute this without fear
make install

mkdir -p /tmp/initramfs/x86-busybox
cd /tmp/initramfs/x86-busybox
mkdir -pv {bin,sbin,etc,proc,sys,usr/{bin,sbin}}
cp -av /tmp/obj/busybox-x86/_install/* .

# now edit the init script
vim init

You have to enable busybox build as static binary (with the menuconfig part).

The init script I use:

#!/bin/sh

echo "INIT SCRIPT"

mount -t proc none /proc
mount -t sysfs none /sys
mount -t debugfs none /sys/kernel/debug

mkdir /tmp
mount -t tmpfs none /tmp

mdev -s # We need this to find /dev/sda later

echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"

exec /bin/sh

The init script boots into a /bin/sh. We can now build the initramfs with it:

chmod +x init
find . -print0 \
    | cpio --null -ov --format=newc \
    | gzip -9 > /tmp/initramfs-busybox-x86.cpio.gz

Try it out (1)

Now we can try it out, whether the kernel boots and we get out shell:

# In the kernel tree:
qemu-system-x86_64 \
    -kernel arch/x86_64/boot/bzImage \
    -initrd /tmp/initramfs-busybox-x86.cpio.gz \
    -nographic -append "console=ttyS0"

We should see some output like this:

[...]
[    7.170702] Freeing unused kernel memory: 1200K (ffffffff81f55000 - ffffffff82081000)
[    7.171539] Write protecting the kernel read-only data: 14336k
[    7.177328] Freeing unused kernel memory: 816K (ffff880001934000 - ffff880001a00000)
[    7.219360] Freeing unused kernel memory: 1116K (ffff880001ce9000 - ffff880001e00000)
INIT SCRIPT
mount: mounting none on /sys/kernel/config failed: No such file or directory
mount: mounting none on /tmp failed: No such file or directory

Boot took 7.33 seconds

/bin/sh: can't access tty; job control turned off
/ # [    7.630681] input: ImExPS/2 BYD TouchPad as /devices/platform/i8042/serio1/input/input3

/ #

(Yes, the output is slightly messed up... but hey! We just booted a linux kernel in a QEMU!

Load the kernel module

We can now create a kernel module in the linux kernel tree:

# In the kernel tree
git checkout -b my-module
mkdir fs/iamcoolfs/ # because I like filesystems
cat <<EOS > ./fs/iamcoolfs/Kconfig
config COOL_FS
        tristate "COOLFS support"
        help
          Private FS for playing and learning FS programming

          This will definitively eat everything you put into it.

EOS
cat <<EOS > ./fs/iamcoolfs/Makefile
#
# Makefile for the linux mb-filesystem routines.
#

obj-$(CONFIG_MB_FS) += coolfs.o
EOS
cat <<EOS > ./fs/iamcoolfs/coolfs.c
#include <linux/init.h>
#include <linux/module.h>

static int __init coolfs_init(void)
{
        pr_debug("cool module loaded\n");
        return 0;
}

static void __exit coolfs_fini(void)
{
        pr_debug("cool module unloaded\n");
}

module_init(coolfs_init);
module_exit(coolfs_fini);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("<YOUR NAME GOES HERE>");

EOS

This creates all the files we need for a minimal module. Because I like filesystems and I really want to implement a minimal filesystem, I chose to create the files in ./fs, but I guess it shouldn't matter.

Make sure you adapt the fs/Kconfig file to find your new module! Put

source "fs/coolfs/Kconfig"

into it.

Now you can execute make menuconfig and find the configuration option for your new module. We can also simply make M=fs/coolfs to build the module. Now we create a (ext2) disk where we can cp the module to, so we can mount that disk into our QEMU and use the module there:

dd if=/dev/zero of=/tmp/disk bs=4M count=100
sudo mkfs.ext2 /tmp/disk # you could also try ext4, for example
mkdir /tmp/disk-mount
sudo mount /tmp/disk /tmp/disk-mount
cp fs/coolfs/coolfs.ko /tmp/disk-mount/
sudo umount /tmp/disk-mount

Try it out (2)

And when we boot our QEMU now with -hda /tmp/disk, we can find /dev/sda in the booted instance and mount that:

# In the booted VM
mkdir sda
mount /dev/sda ./sda
ls sda

Happy FS dev!

tags: #c #linux #open source #programming #software #testing #kernel

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 18th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

I released filters in v0.1.1 and task-hookrs in v0.2.1.

They are now licensed under the terms of MPL-2.0, there were no changes in functionality besides, in the filters library, one can use a filter as an Fn now, but only on nightly rust. I did not bump the version from v0.1.0 to v0.2.0 because I do not think that nightly features should be promoted. They are nice to play with, but stable rust is my target, so I do not include these things as minor versions. And, as semver specifies, we are in v0.x.y, so I can do anything I want!

New contributors

In the last 14 days I got some PRs:

• matthew-piziak submitted #797: “Simplify implementation of FoldResult and add tests”
• mario-kr submitted #810: “Single crate for all binaries”
• rnestler submitted #818: “[WIP] Use Result for from_storeid”
• Thiez submitted #820: “Add Iterator for Iterator> tracing”

Thank you all very much for your contributions!

PRs merged/closed in the last 14 days

• 759 added support for commit-on-drop, so we create one commit for all changes of one imag run.
• 775 added readline support in libimaginteraction.
• 786
• 788
• 789
• 790
• 793
• 794
• 799
• 800
• 801 starts libimagannotation, a library for annotating entries (simply a combination of libimagnotes and libimagentrylink).
• 803 one part of 802
• 804 another part of 802
• 805
• 807 and another part of 802 which rewrites the external linking part of libimagentrylink.
• 808
• 809 a hook for the store which denies deletion of entries that have still links to other entries.
• 815 a prep-PR for the upcoming release.
• 816
• 817
• 819

PRs opened in the last 14 days and not yet closed

There's not much to say about the following list of PRs, so I just list them here.

• 810
• 812
• 818
• 820

Issues opened and already closed

And there's not that much to say about this issues either... so I simply list them here.

• 787
• 811

The future

Well, the future. The release is really close. I am still not sure how to properly do the release.

As listed below, we have some discussion in #814, and TheNeikos suggested to simply run cargo publish --no-verify in a loop until all crates are up there. I do not like this idea very much, though I do not see an alternative. If you have an alternative, feel free to tell!

For readers that are not familiar with the imag codebase, here's the problem again:

• We have multiple crates in one repository.
• We have multiple root crates in one repository.

That means, we have a rather complex net of dependencies of crates in one repository. We have more than 30 crates there. A release process would need to find the one crate that does not depend on any other crate from our repository, cargo publish that one and then walk up the dependency tree until all crates are published. For this, we would either need to parse the Cargo.toml files, to find the dependencies, or just loop over all crates and try to force-publish (as in cargo publish --no-verify) them.

If you have any idea how to do this in a clean and nice (and reproducible) and automated way (I do not want to do this by hand, really), feel free to post a comment on #814!

Issues opened and not yet closed

Some issues were opened that are not yet closed.

• 791
• 792 wants ENV-var expansion from the configuration.
• 798 wants the git-mv hook for Store::move* functions
• 802 tracking issue for the libimagentrylink rewrite to return iterators instead of Vecs.
• 806
• 813
• 814 is a discussion how to do the upcoming (first) release (version 0.2.0)

That's it for today, I guess.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 17th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

I posted an article about how I organize my 0.x.y releases.

Now lets see what happened in the past 14 days.

Despite me not beeing on vacation in the last 14 days (surprise!), we didn't manage to get this much done. But at least we got some things done.

PRs merged/closed in the last 14 days

• 767
• 770
• 774 adds copyright- and license-notices at the beginning of all files.
• 772 adds tests for error-returing store hooks.

PRs opened in the last 14 days and not yet closed

• 764 adds imag-mail based on libimagmail.
• 771 implements utility functions to be used with the clap “validator functions” feature, so they can be used to verify commandline input.
• 775 adds readline support in libimaginteraction, so one can use readline to ask the user for data.
• 783 rewrites the README.md file of the repository.

Issues opened and already closed

• 769 as superceeded by 781

The future

Issues opened and not yet closed

• 765 started a discussion about whether the linking-feature should be extended for a link-annotation feature.
• 766 started a discussion about caching. Thanks you for the issue, Julian!
• 768 asks for better documentation of the linking feature. Thank you again, Julian!
• 773
• 776
• 777 asks to reduce the use of foo.fold(Ok(()),... and replace it by fold_defresult or similar helper functions we have in the codebase.
• 778 asks for a refactor of the FromStoreId trait that is defined and used in libimagdiary.
• 779 asks for a refactor of libimagentryfilter.
• 780
• 781 asks for updating all dependencies of imag.
• 782 asks for changing the libimagstore::store::Store interface to be non-consuming where possible.
• 784 asks for refactoring the libimagstore::store::EntryHeader type. This is actually a really complex issue which might be solved in several PRs rather than in one step.
• 785 asks for a imag mv feature, with some functionality like mv, but also some functionality to move store entries. Thank you again, Julian!

Other things

I finally started my masters degree this week and I guess I will have a rather high workload in this semester, so I really hope I'm able to do some imag things.

Doing the 0.2.0 release within this year (it is planned to happen before 31.12.2016) should be possible, though we will see whether the 3-month-cycle for the next releases I announced in the blog post about my release strategy will be possible.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell. Despite my one-week trip to the Dolomite Alps, I got a hell lot of things done.

Read it up here, in the 16th iteration on whats coming up in imag, the personal information management suite for the commandline

The past

I published a crate imag on crates.io to claim the name "imag" – it doesn't contain anything by now – I only created it to claim the name and therefor is published in version 0.0.0. As version 0.2.0 should be published within this year, this will soon change. I do not yet have any ideas how to publish a multi-crate project on crates.io, though.

(If you wonder why I jump from 0.0.0 to 0.2.0 – I already had a really early release of imag, 0.1.0, which had some minimal functionality. After that, I started a big rewrite and rewrote the complete codebase, because the initial foundations and core infrastructure was just not well done.)

We also had a small contribution from Julian Ganz, thank you very much!

PRs merged/closed in the last 14 days

Here are the closed PRs from the last 14 days. The range also includes some PRs that did not yet hit the master branch, as they are from another long-running PR which introduces some tests for libimagstore (and fixes for bugs from that library).

• 486 – finally! Git support! This PR merged the initial git hook support, so the store is now git version controlled. While this is fundamental git support (and was a rather long-running PR), more PRs will come and add additional features. The following PRs were involved in this PR:

  • 728
  • 731
  • 735
  • 736
  • 739
  • 740
  • 744
  • 745
  • 746
  • 747
  • 748
  • 752

• 729

• 730 introduced matrix builds with travis, to have faster build times.

• 734 introduced more Makefile targets, so one can execute tests via the makefile now.

• 741

• 742

• 751

• 756 introduced an option in the configuration file to disable git hooks.

• 757 reverted a feature from the initial git hook support which was broken.

• 758 fixed that git created empty commits if no change was made to the contents of the store.

• 760

• 762

• 763

PRs opened in the last 14 days and not yet closed

Some PRs from the last 14 days are not yet closed:

• 750
• 759 introduces a new feature so that the commit for a change in the store is made when the store is closed, that leads to less commit noise in the repository.
• 761

Issues opened and already closed

We did not open that much issues in the last 14 days, but anyways some are already closed:

• 733 was closed as this was a duplicate.
• 738
• 754
• 755

The future

What's coming up in the future?

Issues opened and not yet closed

Lets have a look at the issues we opened and did not close in the last 14 days, we clearly want to close them in the next 14 days:

• 732
• 737
• 753

Other things

Well... I have about two weeks left until my semester starts again, so two more weeks to get some stuff done. After that, I guess, development will slow down a bit. Hopefully not much, but enough so I can get good grades in my masters degree.

I'm almost done with the 0.2.0 milestone, so the first release for imag could happen in the next two weeks. We have 83% already done and only soft-required things left, so theoretically we could release in this very moment. Though, I'd like to at least merge the store tests before we do 0.2.0.

Also I'm really thinking about release-strategy and also how to do the release.

Strategy before 1.0.0 would be to simply git tag a commit on the master branch and declare that as release. After that I guess I will create version branches, but as a 1.* release is far away in the future, I don't think too hard about it.

The second thing is – how to release this crate on crates.io? I mean... imag is a crate with multiple root crates and also multiple crates in one repository. I already asked on reddit but I'm not sure the answers fit my problem. All these crates have one root crate which depends on all other crates in the repository. imag does not have that – in the imag repository, each imag-* directory is a root crate that depends on other crates from the repository. And the bin subdirectory also contains one.

I'm not even sure whether it is actually possible with cargo to publish this setup on crates.io.

Maybe I should ask in the cargo IRC channel on this specific subject.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 awesome days in the imag codebase

A lot has happened in this 14 days, despite I first thought it wouldn't be this much. Read up here what progress we made, implementing the PIM suite for the commandline – imag!

The past

Lets have a look at the last 14 days. As said, a lot of things happened – more than I thought could happen, actually.

PRs merged/closed in the last 14 days

Here goes a list of the merged and closed pull requests from the last 14 days, the more important ones are annotated:

• 670
• 672
• 691 was a PR on 635
• 673
• 674 disabled the debug output on travis.
• 675
• 692 adds a helper for Result types to automatically trace() errors when mapping over them.
• 693
• 694
• 695
• 696
• 706
• 707
• 708 fixed the imag-link testing code.
• 709
• 710
• 712
• 713
• 717
• 718 was a PR on 635
• 719
• 720 superceeded 719
• 721 was a PR on 486 and implemented the UpdateHook for the git hook implementation. Finally making progress there!
• 722 was a PR on 721 to refactor the hook
• 723 is a PR on 486 and fixed the hook implementation for the CI servers, so the tests run successfully now. code a bit.
• 725

The following PRs were PRs towards #667 – the rewrite of the StoreId type.

• 678
• 679
• 680
• 681
• 682
• 683
• 684
• 685
• 690

PRs opened in the last 14 days and not yet closed

Here is a list of pull requests we have opened in the last 14 days but are not yet merged.

I hope they will land soon.

• 711
• 726
• 728

Issues opened and already closed

We also have a few issues that were opened and closed within the last 14 days:

• 686
• 688
• 700 as follow-up for 667
• 702 as follow-up for 667
• 703 as follow-up for 667
• 705 as follow-up for 667
• 716

The future

And now,... what's coming up in the next 14 days.

Issues opened and not yet closed

The bunch of issues we have opened but didn't manage to close, yet. There are more than expected, actually.

• 671
• 676
• 687
• 699 as follow-up for 667
• 701 as follow-up for 667
• 704 as follow-up for 667
• 715
• 724

git hooks!

Well, well...

I'm working heavily on the git hook implementations, this is cooking for way to long now. The basics are already working, though. One can commit changes to the store with a default message which is set in the configuration file (no commandline yet, though the --override-config flag should work – at least I cannot see why it shouldn't). One can also commit via the commandline (interactive) by either using the editor or by typing on the commandline directly, though there only a single line is supported.

What I want to implement in the basic git hook support:

• When a file is created, it should be added to the repository (done)
• When a file is removed, it should be removed from the repository

What I want to implement as soon as possible:

• When a file is moved, it should be moved in the repository
• A user might want to select, what entries in the store should be committed automatically with a commit message from the configuration, and what things she wants to commit herself.
• If there is no repository in the store, it should be created automatically. If there are entries that are not yet added, but are not part of the update hook (so they are not in the repository and we are currently working on another entry) the user should at least get a warning. Even better would be if the user could decide whether the entries should be committed automatically or whether they should be left alone.

Other things

Another week of vacation.

Yes, I'm on vacation again from September 10th until September 19th (or maybe 20th). There will be no merges in this time, but you are all welcome to open PRs or issues and of course I will answer and review as soon as I'm back.

tags: #linux #open source #programming #rust #software #tools #imag

As I wrote in the last iteration on what's coming up in imag, I was on vacation from Tuesday, August 16th until Sunday, August 21th, so there was little progress in this period.

Anyways, we got some things done. Read about it here, in the 14th iteration on what's coming up in imag, the personal information management suite for the commandline.

The past

First, lets have a look at the past.

Issues with the compiler

This is actually the first time I have issues with the compiler that broke my build. The beta compiler fails due to some regression. We therefor allow travis to fail the beta compiler job.

There is already a PR for reverting this change, so we build imag on beta as soon as the beta compiler was released with the fix for this issue.

PRs merged/closed in the last 14 days

These PRs were merged or closed unmerged in the last 14 days.

• 479 – We do not need a LGPL checker in my opinion. The LICENSE file should be enough.
• 502
• 510
• 638 was reopened in 656
• 646 rewrote the Makefile.
• 648 rewrote the libimagentryfilter crate by using the filters crate – thank you, impo!
• 649
• 650
• 651 added github pages with the documentation for all crates imag depends on (of course the imag-* binaries are not documented in here, but all libimag* crates are). Finally!
• 652 allows travis to fail the CI builds with the beta compiler, as written above.
• 654
• 659
• 661 adds some documentation for the github pages.
• 665
• 666
• 669

PRs opened in the last 14 days and not yet closed

These PRs were opened in the last two weeks and are not yet closed.

• 655 reverts 652
• 656 rewrites 638
• 667 rewrites the StoreId type as reported in this blog post

Issues opened and already closed

There was only one issue which was opened in the last 14 days and is already closed:

• 647 – Rewrite the libimagentryfilter helper with the filters crate
• 668

The future

Things that come up for the next two weeks.

Issues opened and not yet closed

These issues were opened in the last period, but are not yet closed. Of course we want to close them as soon as possible.

• 653 – As described above, we ran into an issue with the beta compiler and disabled the travis checks for them. This issue is a tracking issue for reverting this patch.
• 658 asked whether to disable the debug output in travis. We agreed that we do not want the debug output anymore in travis, so this turned into a tracking issue.
• 660
• 662
• 663
• 664

Other things

I declared my goals for the rest of the year. I really want to release version 0.2.0 of imag within this year, but some thing have to be done beforehand:

1. Fix the StoreId problem
2. Implement the git hooks (which requires the fix for the StoreId)
3. Fix imag-notes edit which seems to be broken
4. (optionally) Have a minimal working mail module
5. (optionally) Cleanup imag-diary/libimagdiary a bit

Some more required (hard or soft) and optional things can be found in the milestone for this release I created.

tags: #linux #open source #programming #rust #software #tools #imag