fidzu : ubuntu

Earlier this month, I spoke at ContainerDays, part of the excellent DevOpsDays series of conferences -- this one in lovely Portland, Oregon.

I gave a live demo of Kubernetes running directly on bare metal. I was running it on an 11-node Ubuntu Orange Box -- but I used the exact same tools Canonical's world class consulting team uses to deploy Kubernetes onto racks of physical machines.

You see, the ability to run Kubernetes on bare metal, behind your firewall is essential to the yin-yang duality of Cloud Native computing. Sometimes, what you need is actually a Native Cloud.

Deploying Kubernetes into virtual machines in the cloud is rather easy, straightforward, with dozens of tools now that can handle that.

But there's only one tool today, that can deploy the exact same Kubernetes to AWS, Azure, GCE, as well as VMware, OpenStack, and bare metal machines. That tools is conjure-up, which acts as a command line front end to several essential Ubuntu tools: MAAS, LXD, and Juju.

I don't know if the presentation was recorded, but I'm happy to share with you my slides for download, and embedded here below. There are a few screenshots within that help convey the demo.

Cheers,
Dustin

22 Aug 2017 2:24am GMT

This is the third post in our series on our git workflow tooling in Ubuntu. There is an index of all our planned posts in the first post. As mentioned there, it is important to keep in mind that the tooling and implementation are still highly experimental.

Nish introduced our imported repositories using the git ubuntu clone wrapper, as well as using git directly.

I'd like to go into a little more detail about what we're actually importing.

Automatic imports watch for new source publications in Launchpad. When they occur, the importer will push new commits and tags to match those publications and move up branch pointers automatically. All branches maintained by the importer are fast-forwarding. A temporary exception to this is during our experimental stage, before we release a 1.0. Until then, we may re-import packages as we work on the importer.

Our importer maintains one repository per source package in lp:~usd-import-team for now. Eventually we expect to make these available under an alias of the form lp:ubuntu/+source/<package>.

The imported trees correctly reflect the ancestry of individual source packages. This includes both Debian and Ubuntu history, with Ubuntu history correctly parented from the appropriate points in Debian's history.

There is a branch corresponding to each Debian and Ubuntu series (eg. sid, stretch, xenial, artful), and in the case of Ubuntu, pocket (eg. trusty-updates, xenial-security, artful-proposed). We'll cover details on how exactly these work, and the logic behind their design, in future posts.

Single source of truth

A goal of the importer is to reflect the single source of truth, which we define as Launchpad's source publication history. Therefore, the only source of the imported tags and branches must come via the importer and not directly from uploaders. Only the importer can push to the imported repositories. We do have a mechanism to preserve "rich history" provided by git committers that in any other project they'd be able to push directly; more on this in a future post.

Note that this methodology means that upstream's commit graphs are typically not made available by the importer. You won't find individual upstream commits by looking in our imported respository against a particular package. We may decide to make this possible in the future by relying on the "rich history" import mechanism combined with the use of our parenting invariant. More on this in a future post.

We're trying hard to make sure that there is no case where a source package upload can cause the importer to fail. We're treating any failure to import a source package as a bug in our importer. The importer should be able to import anything that was ever uploaded to Debian or Ubuntu.

Available branches

As Nish mentioned, there are two main types of branches:

1. Devel branches: the branches on which to start development.
2. Pocket branches: understanding the current state of the archive.

There are also "applied" versions of these branches, which provide quilt patches already applied.

The "devel" branches

Ubuntu developers are used to using pull-lp-source to grab the latest version of a package source on which to base development. We want to make git clone work instead.

What is the correct version on which to base development? In Ubuntu, this can vary depending on the exact publication state. Usually you want the highest version published in the development release, or the highest version published in a particular series for an SRU. For this purpose, the git importer maintains devel branches. For the development release, this is just called ubuntu/devel. For a stable release, it is ubuntu/<codename>-devel; for example: ubuntu/xenial-devel.

This is intended to save developers the effort of figuring out which pocket to use (between the release pocket, proposed, updates and security) and saves scripts from having to figure it out themselves.

One exception to this is in the rare case that a version in the proposed pocket has been discarded, such as a failed SRU. The importer only follows new version publications and does not follow deletions. In this case you may wish to start directly from a pocket branch (described below). Alternatively, before you begin you could start from the devel branch and use git revert to add a commit reversing the published change in line with the deletion. The infrastructure doesn't care which method you choose.

Pocket branches

A different use case is to look at the git branches to understand what the archive looks like today, or how it looked in the past.

Ubuntu's pockets

First let's review what Ubuntu pockets actually are.

In Ubuntu, the archive for a particular release ("series") is divided up into a number of "pockets", which correspond to the entries in your sources.list file:

1. The release pocket. This pocket has no specific name. During development, the release pocket is where package eventually land. Upon release, this pocket is frozen and never changes again.
2. The "proposed" pocket. This pocket is used for two different purposes depending on whether the series is in development or has been released. During development, this is the staging area in which packages are built, tested and checked for installability before they land. When all tests pass, packages are moved into the release pocket in a process called proposed migration. After release, the proposed pocket is used for a different purpose: manual user verification of proposed stable release updates through the SRU verification process. When a package passes SRU verification, the package is moved into the updates pocket, rather than the release pocket is as the case during development.
3. The "updates" pocket. Only used for stable releases, this pocket is used to issue recommended updates to users during the lifetime of a stable release.
4. The "security" pocket. Only used for stable releases, this pocket is used to issue security updates to users during the lifetime of a stable release. Updates to the security pocket are always also copied into the updates pocket.

The name of a pocket is in the form <series>-<type>, such as xenial-security and artful-updates. As an exception, the release pocket is the series with no suffix, such as trusty.

Importing pockets into git

The importer maintains a branch for each pocket, in the form ubuntu/<pocket name>, such as ubuntu/trusty (the Trusty release pocket), ubuntu/xenial-security, ubuntu/artful-proposed and so on.

Combining pocket branches: the devel branches

To support the archeology use case, the importer must maintain these pocket branches. However, for the ongoing development use case, it's far more convenient for developers to use our "devel branches".

We do this by making use of our "parenting invariant", which we'll describe in more detail in a future post. For now, it's sufficient to understand that the devel branches are the points at which you should start development, and the pocket branches can be used to examine the current state of the various pockets in the Ubuntu archive.

Applied branches

For our drive-by contributor use case, it would be nice if these drive-by contributors didn't have to understand quilt. It's reasonable to expect that, straight after running git clone from Ubuntu and selecting an appropriate branch, the tree that appears is exactly the source used to build the corresponding Ubuntu package. For drive-by contributors unfamiliar with Debian packaging, this means that quilt patches should appear applied. Our "applied" branches and tags provide this function.

The non-applied branches are the normative imports from Debian and Ubuntu developer uploads. They are intended to represent the source package exactly and without any derived components. This means that quilt patches appear indebian/patches/ as normal, but are not applied.

From one of these import commits, all quilt patches (if any) are applied one by one. Each application results in a separate git commit. A final commit with an identical tree is added for branch fast-forwarding purposes, and these commits form the line of the "applied" branch.

Consequently, you can switch to an "applied" branch, or corresponding tag, and you'll see the state of the Ubuntu source package with all patches applied and as if quilt doesn't exist. Drive-by contributors can then file pull requests against such a branch (eg. applied/ubuntu/devel) and bots and sponsors will be able to understand exactly what is being requested.

It will often be necessary to pull out requested changes into a separate quilt patch, add dep3 headers, and possibly squash the requested change into an existing quilt patch, before uploading. We hope to automate some of this in the future, but for now this is left as a task for sponsors who accept git workflow upload requests. Contributors can either submit pull requests against the applied branches this way, or fold up into quilt patches themselves and submit pull requests against the non-applied branches instead.

In the future, it may be desirable for all Ubuntu developers to forget quilt and live entirely inside git-based patchsets. For the time being, we want to support both traditional and git-based workflows. So both applied and non-applied branches are maintained by the importer.

It is a matter of debate as to whether the non-applied or applied branches should appear by default. We are open to further discussion on this.

Available tags

The first time the importer imports a new version of a source package, it tags it using an "import tag", which is of the form import/<version>. The patches-applied equivalent is derived, and the result is tagged in the formapplied/<version>.

Pocket copies, such as from Debian into Ubuntu via autosync, are not tagged; the pocket branches are moved forward with new commits (with identical trees) as necessary.

Since not all valid package version strings are valid git tag names, the tag names are escaped using the same rules as specified in dep14, Debian's recommendation on git repository layouts.

We use tags of the form upload/<version> to supply rich history for adoption into the imported commit graph. This cannot be pushed directly; more on this in a future post.

To support the preservation of orig tarballs using pristine tar, the importer also tags upstream/<version>.

pristine-tar and the dsc branches

So that the git repositories contain all the information needed to reconstruct an imported source package, the importer also stores the orig tarballs using pristine-tar and the signed dsc file in separate branches. Orig tarballs are automatically extracted on package build as needed by the git ubuntu build wrapper. This means that git ubuntu clonefollowed by git ubuntu build should Just Work.

Orig tarballs between Debian and Ubuntu may vary in exceptional cases, so the importer keeps these properly namespaced in debian/pristine-tar and ubuntu/pristine-tar branches to avoid collisions, and likewise for the dsc files debian/dsc and ubuntu/dsc. pristine-tar doesn't currently support multiple branches; it assumes a single branch of pristine-tar. Our git ubuntu build wrapper works around this for now. In the future I'd like for us to drive getting parameterised branch name support into pristine-tar upstream to support our use case.

Conclusion

In order to provide a full understanding of what we're doing to those developers interested in all the detail, I've tried to cover all the git reference objects presented by our importer in this post today.

In our next post, Nish will continue discussing the git ubuntu tooling by introducing git ubuntu tag.

21 Aug 2017 5:18pm GMT

This is the third post in our series on our git workflow tooling in Ubuntu. There is an index of all our planned posts in the first post. As mentioned there, it is important to keep in mind that the tooling and implementation are still highly experimental.

Nish introduced our imported repositories using the git ubuntu clone wrapper, as well as using git directly.

I'd like to go into a little more detail about what we're actually importing.

Automatic imports watch for new source publications in Launchpad. When they occur, the importer will push new commits and tags to match those publications and move up branch pointers automatically. All branches maintained by the importer are fast-forwarding. A temporary exception to this is during our experimental stage, before we release a 1.0. Until then, we may re-import packages as we work on the importer.

Our importer maintains one repository per source package in lp:~usd-import-team for now. Eventually we expect to make these available under an alias of the form lp:ubuntu/+source/<package>.

The imported trees correctly reflect the ancestry of individual source packages. This includes both Debian and Ubuntu history, with Ubuntu history correctly parented from the appropriate points in Debian's history.

There is a branch corresponding to each Debian and Ubuntu series (eg. sid, stretch, xenial, artful), and in the case of Ubuntu, pocket (eg. trusty-updates, xenial-security, artful-proposed). We'll cover details on how exactly these work, and the logic behind their design, in future posts.

Single source of truth

A goal of the importer is to reflect the single source of truth, which we define as Launchpad's source publication history. Therefore, the only source of the imported tags and branches must come via the importer and not directly from uploaders. Only the importer can push to the imported repositories. We do have a mechanism to preserve "rich history" provided by git committers that in any other project they'd be able to push directly; more on this in a future post.

Note that this methodology means that upstream's commit graphs are typically not made available by the importer. You won't find individual upstream commits by looking in our imported respository against a particular package. We may decide to make this possible in the future by relying on the "rich history" import mechanism combined with the use of our parenting invariant. More on this in a future post.

We're trying hard to make sure that there is no case where a source package upload can cause the importer to fail. We're treating any failure to import a source package as a bug in our importer. The importer should be able to import anything that was ever uploaded to Debian or Ubuntu.

Available branches

As Nish mentioned, there are two main types of branches:

1. Devel branches: the branches on which to start development.
2. Pocket branches: understanding the current state of the archive.

There are also "applied" versions of these branches, which provide quilt patches already applied.

The "devel" branches

Ubuntu developers are used to using pull-lp-source to grab the latest version of a package source on which to base development. We want to make git clone work instead.

What is the correct version on which to base development? In Ubuntu, this can vary depending on the exact publication state. Usually you want the highest version published in the development release, or the highest version published in a particular series for an SRU. For this purpose, the git importer maintains devel branches. For the development release, this is just called ubuntu/devel. For a stable release, it is ubuntu/<codename>-devel; for example: ubuntu/xenial-devel.

This is intended to save developers the effort of figuring out which pocket to use (between the release pocket, proposed, updates and security) and saves scripts from having to figure it out themselves.

One exception to this is in the rare case that a version in the proposed pocket has been discarded, such as a failed SRU. The importer only follows new version publications and does not follow deletions. In this case you may wish to start directly from a pocket branch (described below). Alternatively, before you begin you could start from the devel branch and use git revert to add a commit reversing the published change in line with the deletion. The infrastructure doesn't care which method you choose.

Pocket branches

A different use case is to look at the git branches to understand what the archive looks like today, or how it looked in the past.

Ubuntu's pockets

First let's review what Ubuntu pockets actually are.

In Ubuntu, the archive for a particular release ("series") is divided up into a number of "pockets", which correspond to the entries in your sources.list file:

1. The release pocket. This pocket has no specific name. During development, the release pocket is where package eventually land. Upon release, this pocket is frozen and never changes again.

2. The "proposed" pocket. This pocket is used for two different purposes depending on whether the series is in development or has been released. During development, this is the staging area in which packages are built, tested and checked for installability before they land. When all tests pass, packages are moved into the release pocket in a process called proposed migration. After release, the proposed pocket is used for a different purpose: manual user verification of proposed stable release updates through the SRU verification process. When a package passes SRU verification, the package is moved into the updates pocket, rather than the release pocket is as the case during development.

3. The "updates" pocket. Only used for stable releases, this pocket is used to issue recommended updates to users during the lifetime of a stable release.

4. The "security" pocket. Only used for stable releases, this pocket is used to issue security updates to users during the lifetime of a stable release. Updates to the security pocket are always also copied into the updates pocket.

The name of a pocket is in the form <series>-<type>, such as xenial-security and artful-updates. As an exception, the release pocket is the series with no suffix, such as trusty.

Importing pockets into git

The importer maintains a branch for each pocket, in the form ubuntu/<pocket name>, such as ubuntu/trusty (the Trusty release pocket), ubuntu/xenial-security, ubuntu/artful-proposed and so on.

Combining pocket branches: the devel branches

To support the archeology use case, the importer must maintain these pocket branches. However, for the ongoing development use case, it's far more convenient for developers to use our "devel branches".

We do this by making use of our "parenting invariant", which we'll describe in more detail in a future post. For now, it's sufficient to understand that the devel branches are the points at which you should start development, and the pocket branches can be used to examine the current state of the various pockets in the Ubuntu archive.

Applied branches

For our drive-by contributor use case, it would be nice if these drive-by contributors didn't have to understand quilt. It's reasonable to expect that, straight after running git clone from Ubuntu and selecting an appropriate branch, the tree that appears is exactly the source used to build the corresponding Ubuntu package. For drive-by contributors unfamiliar with Debian packaging, this means that quilt patches should appear applied. Our "applied" branches and tags provide this function.

The non-applied branches are the normative imports from Debian and Ubuntu developer uploads. They are intended to represent the source package exactly and without any derived components. This means that quilt patches appear in debian/patches/ as normal, but are not applied.

From one of these import commits, all quilt patches (if any) are applied one by one. Each application results in a separate git commit. A final commit with an identical tree is added for branch fast-forwarding purposes, and these commits form the line of the "applied" branch.

Consequently, you can switch to an "applied" branch, or corresponding tag, and you'll see the state of the Ubuntu source package with all patches applied and as if quilt doesn't exist. Drive-by contributors can then file pull requests against such a branch (eg. applied/ubuntu/devel) and bots and sponsors will be able to understand exactly what is being requested.

It will often be necessary to pull out requested changes into a separate quilt patch, add dep3 headers, and possibly squash the requested change into an existing quilt patch, before uploading. We hope to automate some of this in the future, but for now this is left as a task for sponsors who accept git workflow upload requests. Contributors can either submit pull requests against the applied branches this way, or fold up into quilt patches themselves and submit pull requests against the non-applied branches instead.

In the future, it may be desirable for all Ubuntu developers to forget quilt and live entirely inside git-based patchsets. For the time being, we want to support both traditional and git-based workflows. So both applied and non-applied branches are maintained by the importer.

It is a matter of debate as to whether the non-applied or applied branches should appear by default. We are open to further discussion on this.

Available tags

The first time the importer imports a new version of a source package, it tags it using an "import tag", which is of the form import/<version>. The patches-applied equivalent is derived, and the result is tagged in the form applied/<version>.

Pocket copies, such as from Debian into Ubuntu via autosync, are not tagged; the pocket branches are moved forward with new commits (with identical trees) as necessary.

Since not all valid package version strings are valid git tag names, the tag names are escaped using the same rules as specified in dep14, Debian's recommendation on git repository layouts.

We use tags of the form upload/<version> to supply rich history for adoption into the imported commit graph. This cannot be pushed directly; more on this in a future post.

To support the preservation of orig tarballs using pristine tar, the importer also tags upstream/<version>.

pristine-tar and the dsc branches

So that the git repositories contain all the information needed to reconstruct an imported source package, the importer also stores the orig tarballs using pristine-tar and the signed dsc file in separate branches. Orig tarballs are automatically extracted on package build as needed by the git ubuntu build wrapper. This means that git ubuntu clone followed by git ubuntu build should Just Work.

Orig tarballs between Debian and Ubuntu may vary in exceptional cases, so the importer keeps these properly namespaced in debian/pristine-tar and ubuntu/pristine-tar branches to avoid collisions, and likewise for the dsc files debian/dsc and ubuntu/dsc. pristine-tar doesn't currently support multiple branches; it assumes a single branch of pristine-tar. Our git ubuntu build wrapper works around this for now. In the future I'd like for us to drive getting parameterised branch name support into pristine-tar upstream to support our use case.

Conclusion

In order to provide a full understanding of what we're doing to those developers interested in all the detail, I've tried to cover all the git reference objects presented by our importer in this post today.

In our next post, Nish will continue discussing the git ubuntu tooling by introducing git ubuntu tag.

21 Aug 2017 4:53pm GMT

I know I'm very late, but I really wanted to talk about this year Google Summer of Code.

For the third year in a row, I was a mentor. And this year I have a huge deception to share. I'm really sad. This week, I'v received the GSoC 2011 t-shirt. They sent me the wrong size. XXXL. I can use it as a sleeping bag with my girlfriend. I'm really disappointed.

Hopefully, GSoC is not only about receiving a t-shirt. It is also about mentoring a student.

Nearly two years ago, I started working on a complete refactoring of GTG. The code was a mess, with a lot of duplicate everywhere, with two bugs appearing while you were trying to solve one, etc.

I abstracted the structure we were using in several places and started to write a library to handle those "Acyclical Directed Graphs". As usual, it appeared that development was taking longer than expected. Weeks turned into months. Then, when it started to look good, I discovered that I forgot one critical point: thread-awareness. I felt hopeless.

Because I didn't had the motivation to do that heavy work, I proposed it as a Summer of Code project to a very motivated student: Izidor Matušov^[1].

Words doesn't do any justice to the excellent work that Izidor did this summer. He's simply awesome. Some students are goods because they have previous experience. Izidor kicks asses. He learns so quickly, he's so assertive. The work was even harder than what we anticipated. But he managed to achieve everything, including feeding me with cookies at the Desktop Summit, where we met and had an awesome hacking week.

As much as I'm deceipted about the t-shirt, I'm delighted about the work achieved this summer. Izidor now knows GTG nearly as much as I do. He's taking initiatives, like organizing an online GTG hackfest on November 26th^[2] and he's a bug-answering machine.

Dear Google, GNOME foundation and Lanedo^[3], I would like to thank you. Thanks to your support:

1. I received a worthless piece of clothes that travelled half of the world in order to clean my cat's dirtiness.
2. GTG 0.2.9 should be released before the end of the year
3. GTG gained a new co-maintainer
4. I gained a new friend. And it probably worth everything else.

Congratulations, co-maintainer Izidor. And welcome to the community!

06 Nov 2011 6:23pm GMT

Part 1 : Introduction
Part 2 : Home is Desktop
Part 3 : There's no tray icon in GNOME !
Part 4 : Kill The Double Click

When I started installing the best desktop possible for Marie and Jean, we were still in the GNOME 2.X era. GNOME 3 solved my previous concerns. No in the way I envisioned it, but solved them anyway. No more desktop icons, no more tray icons.

But now that I'm introducing Marie and Jean to GNOME 3, I still have some concerns. And one of that main concern is the infamous double-click!

Do you remember? Jean is a very brilliant mind, even though he never used a computer during his whole life. As a reasoning scientist, he was trying to find the logic behind my teaching.

During one of our first lesson, "Using the mouse", the conversation went like this:
- How do I know if I have to click or double click?
- Well, you double-click on icon and simple click on links and buttons.
- How do I know what is a button or an icon?
- …

Since that time, I've tried many times to find a logic behind single or double clicking. There is not. You have to learn it by experience. And it is totally, utterly pointless.

I also realized that a single click was something really hard for Jean. Achieving to click on a given point without moving the mouse is really hard for older people. Then, ask them to click twice, with a completely arbitrary speed, without moving the mouse, not to quickly, not to slowly. Impossible.

Marie, on her side, was double-clicking everywhere. And, surprisingly, it works most of the time.

So, why do we have double-click in some places? Because we want to be able to select an item without "activating" it. How often does it happen? Never for Jean. Very rarely for Marie.

To summarize, we are making the most frequent action very hard to nearly impossible in order to allow a very rare action?

I tried to disable completely the double-clicking in Nautilus.

Do you know what?

It works. Even for me. I had chronic pain in my hand and disabling double-click was a relief. I explained to Marie to never double-click anymore. She's still double-clicking from time to time but everything works even better than before. Jean was eventually able to launch a file from within Nautilus.

Selection of one or multiple file with single mouse click

What about selection of files? I explained to Marie to draw a square with the mouse. And, yes, she found that absolutely intuitive. The only drawback I found so far was the inconsistency with lists, where double-clicking is still required. Marie called me one day because she tried to play a specific song in Rhythmbox. It wasn't working. I realize that she had to double-click on the song. "But you told me to never double click anymore!". Sorry Marie.

I'm myself incredibly frustrated by any system that requires double-click. Why do we still have double-click by default in GNOME3?


Part 1 : Introduction
Part 2 : Home is Desktop
Part 3 : There's no tray icon in GNOME !
Part 4 : Kill The Double Click


Picture by Dave Dugdale

05 Nov 2011 12:17pm GMT

Si vous deviez me décrire en deux mots, nul doute que fourbe et profiteur vous viendraient spontanément à la bouche. Paresseux, parasite et inutile suivraient de près. Et j'en suis fier. J'en ai même fait mon mode de vie.

Ma technique est simple mais éprouvée. Je croise un inconnu dans la rue à l'air affable. Tenez, prenez ce jeune homme à l'allure dynamique. Il s'appelle Jean, c'est ma prochaine victime. Il ne se doute encore de rien mais j'irai dormir dans le lit de sa femme tout en vidant son frigo.

Au premier abord, je fais le numéro du sympa-sociable, les circonstances m'ont conduit dans la rue, où j'ère sans but précis, mais je ne me plains pas, je ne quémande rien, au contraire, je refuse tout geste de pitié trop ostentatoire. J'ai ma fierté.

Lorsque Jean se propose de m'emmener manger à la maison, juste pour la soirée, je fais d'abord mine de ne pas être intéressé. Mais mes yeux acquiescent et Jean, en rigolant, insiste, me forçant presqu'à le suivre. Inutile de vous dire que c'est ce que j'attendais mais la victime doit croire qu'elle a l'initiative, c'est primordial.

Martine, la femme de Jean, n'est que moyennement contente de cet imprévu. Qu'à cela ne tienne, je fais mon charmeur, je séduis tout en ayant l'air de ne pas vouloir déranger. Je fais également un peu le pitre pour la dérider.

Et ça marche. Avant la fin de la soirée, elle discutera avec moi plus qu'avec Jean lui-même, ce dernier étant parfaitement inconscient du destin de proie que je lui réserve. De manière indirecte, je fais comprendre que je n'ai nul part où aller. Jean et Martine n'ont pas le cœur de me renvoyer seul dans le froid de la nuit. Ils se proposent donc de m'héberger, juste pour une nuit. Tandis que je m'installe confortablement sur le sofa, j'entends Martine descendre l'escalier. Elle est en déshabillé, prête à aller au lit.

- « Bonne nuit ! » me lance-t-elle avec un sourire innocent avant de remonter dare-dare dans sa chambre.

Je ricane. Je n'ai même pas eu besoin de répondre. Une seule soirée me suffit. Homme ou femme, nul ne me résiste. Je suis comme ça moi.

Bien entendu, le « seulement pour une nuit » se prolongera. Je commencerai doucement à faire comprendre mes goûts précis, envoyant Jean au supermarché afin de m'acheter ce que je souhaite. Lorsqu'elle rentre du travail, Martine a à peine un regard pour Jean. Elle se rue à l'intérieur pour voir comment je vais. Pendant ce temps-là, je me prélasse sur le canapé, je me balade un peu. Avec mon air faussement négligent, j'ai pris soin de casser quelques bibelots auxquels ils tenaient beaucoup, par pure cruauté.

Lorsque Jean partit quelques jours dans sa famille à l'étranger, je n'hésitai pas: je me glissai une nuit dans le lit de Martine, sans même lui demander, sans même m'annoncer. Elle prit un air faussement surpris mais je sais qu'elle n'attendait que cela. Elles sont toutes les mêmes. Jean nous a surpris en rentrant plus tôt. Cela ne lui a pas plu. Il m'a dit qu'il m'avait sorti de la rue, qu'il n'acceptait pas cela.

Par méchanceté, j'ai répondu en déféquant sur la moquette du salon. Il a pu tout nettoyer. Il n'était vraiment pas content mais Martine a fini par le convaincre de me garder et d'exercer le moindre de mes désirs.

Il faut dire qu'ils sont vraiment bien mes deux esclaves. Je dors dans leur lit, ils me nourrissent, nettoient sans que je n'aie besoin de faire attention à rien. Quoi que je fasse, ils me regardent avec un air attendri et me trouvent adorable. Même au milieu de la nuit, il suffit que je me mette à miauler pour qu'ils s'enquièrent immédiatement de mes besoins.

Des esclaves aussi dociles, c'est rare. Je vais les garder encore quelques temps.

28 Oct 2011 4:59pm GMT