Search Results: "rul"

15 February 2010

William Pitcock: Healthy Menu for Slim with Diet Software

sofwarediet285
Want a healthy diet, but difficulty determining diet have much less heart disease and diabetes, now do not need to be confused. The problem currently existing software can determine which food or menu with us. This tool was created Muhammad Burhanuddin SI students majoring in the College information systems Information Management and Computer Engineering (STIKOM). Pemuda Surabaya original was inspired by his desire to want to get the ideal body weight. He then sought a reference from a variety of books on diet and sehata the ideal body shape. From the book, he then designed a program for determining menu diet with computerized systems. Yes at first it was because I found it difficult to lose weight and see the number of experts in determining the diet for patients with certain diseases, he said on the red building STIKOM Surabaya, Jalan Kedung Baruk, Thursday (15/10/2009). During the decisive finishing diet program, she had difficulty in the verification phase of the rule which took one month of a total of four months of completion of the program is the final project. This 21 year young man said this program can ciptaanya to help digunakanahli nutrition diet suitable for the patient. At first nutritionist to determine the menu of resus a patient s blood type that has gone through laboratory tests. Then determine the disease
patients suffered until finally obtained the results of a diet, he said.

Christine Spang: a foray into emacs

This spring I'm taking a class that does all its programming assignments in MIT Scheme. The last time I had to write Scheme for class, we used PLT Scheme, and thus the DrScheme editor. This time, with that option out, I've decided to do the assignments in Emacs. It is, after all, an editor built out of lisp. I've used vim for the last five years or so. Some people ask me why this is so I do go to MIT after all, where Emacs was originally written. The answer to that is simply that Debian got to me first, and at the time at least, the people I knew there used vim. I've heard Emacs is good, but up until this point every time I've tried it I've thrown it down in frustration and then couldn't figure out how to exit the damn thing. This time I was more determined, and made it through the initial hump of being completely useless at the editor. Here are a few of my observations so far, after mucking around for a couple days over a period of about two weeks: I'm pretty sure at this point that I'm still trying to bend emacs into being vim with different keybindings instead of figuring out how emacs wants to be used. It's also difficult to compare and contrast between the two editors in that my .vimrc contains years of tweaks and customizations whereas my .emacs started out as a clean slate. There are two things I'm doing to try to mentally separate emacs from vim, to avoid my fingers' muscle memory from becoming confused:
  1. I'm always using emacs in an X window with dark-on-light text, whereas I always use vim in a terminal with light-on-dark text.
  2. I'm only writing scheme in emacs. No other languages so far.
I'm planning to keep working on these programming assignments in emacs, despite it being annoying slower than I would be in vim. Tips and pointers for improving my experience are welcome.

14 February 2010

Gregor Herrmann: RC bugs 2010/05, 2010/06

again a short overview about my RC bug activities: mostly pkg-perl related again, but at least a few other things, too ....

11 February 2010

Joachim Breitner: Diploma Thesis Finished

Earlier today, I went to a local copy shop and had my diploma thesis printed. This afternoon, I will hand it in. The title is Loop subgroups of Fr and the images of their stabilizer subgroups in GLr( ) and discusses a group-theoretical result. I assume that very few readers care about the content of the thesis, but maybe some are interested in a few assorted LaTeX hints. I m also publishing the full TeX source code, maybe someone can make use of it. Less chatty varioref I m using the varioref package, in conjunction with the cleveref package. This provides a command \vref fig:S3S4l which will expand to, for example, to Figure 1 on page 11 . But if the referenced figure is actually on the current page, the next page, the previous page or the facing page (in two-side layouts), it will say so: Figure 1 on this page. This is very nice, but I assume that the reader of my thesis is able to find Figure 1 when it is visible, i.e. on the current or facing page. One can remove the referencing texts with the commands \def\reftextfaceafter , \def\reftextfacebefore and \def\reftextcurrent . But because varioref puts a space between Figure 1 and this text, we will get a superfluous space even before punctuation. The remedy is the command \unskip, which removes this space again. So I use in my preamble: 
\def\reftextfaceafter  \unskip %
\def\reftextfacebefore \unskip %
\def\reftextcurrent    \unskip %
Palatino and extra leading I chose the Palatino font for my thesis, using the mathpazo package. Various sources (such as the KOMA-Script manual) suggest to use 5% extra leading: 
\linespread 1.05
Counting figures independently from chapters I don t have too many figures and tables in my thesis, and I want them to be numbered simple 1, 2, ... By default, LaTeX would say 1.1, 1.2, 2.1, ... This can be fixed using the remreset package and these commands: 
\makeatletter
\@removefromreset figure chapter 
\renewcommand \thefigure \arabic figure 
\@removefromreset table chapter 
\renewcommand \thetable \arabic table 
\makeatother
No widows and club lines LaTeX already avoids these, but I wanted to get rid of them completely. This can be done with: 
% Disable single lines at the start of a paragraph (Schusterjungen)
\clubpenalty = 10000
% Disable single lines at the end of a paragraph (Hurenkinder)
\widowpenalty = 10000 \displaywidowpenalty = 1000
Struck table lines I had to typeset tables with some lines struck, and I could not find a ready command for that. I used the following definition, based on the code for \hline. Note that it probably does not adjust well to other font sizes and needs to be adjusted manually: 
\makeatletter
\def\stline %
  \noalign \vskip-.7em\vskip-\arrayrulewidth\hrule \@height \arrayrulewidth\vskip.7em 
\makeatother
Title page in one-sided layout According to the KOMA manual, the title page as set by LaTeX is not meant to be the cover of a publication, and therefore has to be set with the margins of a right page i.e. a larger right margin and a smaller left margin. But when printing cheaply, one often just put a transparent sheet on top of the print, so the title page is the cover. You can convince KOMA that you are right by using 
\KOMAoptions twoside=false 
\begin titlepage 
...
\end titlepage 
\KOMAoptions twoside=true
Not flushing the page for chapter heads LaTeX would put the list of algorithms on a new right page. I found this a waste of paper for my few algorithms, and preferred to put the list right after the table of contents. You can override the LaTeX behavior using: 
\tableofcontents
 
\let\cleardoublepage\relax  % book
\let\clearpage\relax  % report
\let\chapter\section
\listofalgorithms
This code also reduces the size of the heading to that of a section. The same trick also works with \chapter. Math in headings vs. PDF bookmarks LaTeX with the hyperref package creates nice PDF bookmarks from your chapter and section titles. Unfortunately, PDF bookmark names can only be plain strings, while the titles in the document might contain some math symbols. You can make both happy with \texorpdfstring: 
\section Stabilizer subgroups in \texorpdfstring $\GL_r(\Z/2\Z)$ GL\_r(Z/2Z)
Setting lines for the signature The diploma thesis contains a small note which I have to sign, saying that I created it on my own etc. Below that, I put two labeled lines for date and signature, using the tabbing environment: 
\begin tabbing 
\rule 4cm .4pt \hspace 1cm  \= \rule 7cm .4pt  \\
Ort, Datum \> Unterschrift
\end tabbing

10 February 2010

Bernd Zeimetz: BSP2010 a great success - 200 bugs eliminated

Some of the participants of the BSP here in M nchengladbach asked me to put the blog post from blog.credativ.com on planet Debian. I think thats a great idea as the BSP was not only successfull, but also a lot of fun and it was very nice to meet a lot of Debian Developers and package maintainers. We were glad that so many people followed the invitation! So here we go - please leave your comments at the original blog post.

Debian Logo
The 2010 Debian Bug Squashing Party turned out to be a great success: around 200 bugs were fixed, ready for the forthcoming version of Debian. The weekend of 22-24 January saw this year s Bug Squashing Party hosted yet again by credativ. The aim of the weekend was to find and fix bugs in the next Debian release. The results were as follows:
Work on Debian Results
Installed Patches 5
Fixed Bugs 44
Non-critical Bugs 28
Completely removed Packages 87
Packages removed from Testing 29
Altogether that gives a grand total of 200 bugs. In addition, information was gathered on a further 100 bugs, which will help when they come to be fixed. A lot of time was also spent on quality assurance, an under appreciated but very important job. More gossip: it is rumoured that backports.org is not far off becoming an official Debian project and in the meantime it will be launching a brand new website running on ikiwiki. Our guests from far and wide were more than happy with the BSP party: Steve McIntyre: (Debian project leader)
Thanks to the folks at credativ for hosting and participating in the BSP - we got a huge amount of work done towards the next release and had a great time doing it!
Stefano Zacchiroli:
My 1st M nchengladbach BSP, won t be the last! Lots of cool people and hacking, and I ve enjoyed my 1st traditional Formorer s chilli too :).
credativ would like to thank all those who came and got involved - now you can lean back, relax and enjoy the photos of the event.

9 February 2010

Stefano Zacchiroli: RC bugs of the week - issue 20

RCBW - #20 With a couple of days of delay, here are this last week squashes, by yours truly: The delay is due to FOSDEM, it's hard to squash bugs when you are: (1) having fun (best FOSDEM ever, if you ask me), (2) connected with very poor network connectivity (let's say: FOSDEM-quality network). Also, there are just 6 squashes, but last week there were 8, so ... :-) (I know, I suck). Among the main highlights of the week, I just want to cite Mehdi Dogguy: he was with me at JFLA 2010 last week and I've managed to grab him into the "RCBW tunnel". With a handful of well-targeted NMUs, he has fixed about 10 RC bugs in the few days of the conference. He is too shy to blog about that, but since I'm evil, I'm disclosing it here :-P Welcome on board, Mehdi! (now you're doomed: you must continue doing that!)

8 February 2010

Kartik Mistry: My Hero


* Cyril Brulebois (kibi) is my hero

7 February 2010

MJ Ray: The Phone Co-op 2010

Ed Mayo talking to the Phone Co-op meeting
Ed Mayo talking to the Phone Co-op meeting Yesterday I had the pleasure to be at the Phone Co-ops annual meeting, as those of you who follow me on identi.ca or elsewhere will already know. The proceedings included a speech from Cooperatives-UK Chief Exec Ed Mayo that included the co-op pub in Salford, spurning David Beckham s gift and this summer s Co-operatives Fortnight. As ever, the bits I liked best were the lively question-and-answer sessions, both on Ed s speech and the annual report. I took notes and reproduce them below, but I didn t capture every question, or every answer and none of this is verbatim. Questions to Ed about UK cooperation included:

Questions about the annual report asked about:

Asheesh Laroia: Cosmetic carbon copy: The opposite of blind carbon copy

I propose a new feature for email software: Cosmetic carbon copy. CCC works very similarly to today's carbon copy feature: If you put an address in the CCC: list, when the recipients open the message, they can see the address. The one difference is that with "cosmetic" carbon copy, the CCC:d address never recieves the message. An example might illustrate the situation. Let's say someone (Alice) wants to invite Bob to a movie but doesn't want Charlie to come. She might send this email: 
From: alice@example.com
To: bob@example.com
CCC: charlie@example.com
Subject: MOOOVIEEE!

Hey all my friends, join me for a movie tonight!
When Alice sends the email, Bob recives a copy. Bob thinks that Charlie received a copy, as he will be in the CC list. But Alice's mail software never sent Charlie a copy. So Alice can relax, knowing that Bob won't forward a copy to Charlie, since Bob thinks he already received it. Alice and Bob will meet up without Charlie, and Alice will quietly sigh in relief.

How can this work? Cosmetic carbon copy works on the same principle as blind carbon copy: the contents of the message are fundamentally independent from the recipients. Saavy email users have used the "blind carbon copy" feature for years. When you place an address in the BCC list, that address will receive a copy of the email even though other recipients won't see the address listed. This allows for a form of privacy between the sender of the email and that hidden recipient. This works because, like postal mail, email messages are delivered using an "envelope" that contains the actual recipients. When you compose a message in Alpine, Gmail, or Thunderbird, you are writing the contents of the envelope. When you hit send, the mail software looks for email addresses that should receive a copy. It creates one envelope per address, stuffs the letter inside, and sends the whole thing on its way through the Internet using a protocol called SMTP. When the recipient (Bob)'s email system receives it, the letter is pulled out of the envelope and placed in an inbox. Which means the envelope is entirely invisible to Bob, the recipient. Most mail software puts information about the envelope in email headers. Since each email recipient gets a separate envelope, In the case of cosmetic carbon copy, Alice's letter claims that Charlie was on the CC: list. But Bob can never learn that Charlie's copy was never sent. So to implement cosmetic carbon copy, Alice's mail program must understand this rule:
  • For each address in the CCC list, copy the message to the CC: list in the email message.
  • Create no new envelopes when sending the message.
Because of the last bullet point, this "carbon copying" is purely cosmetic rather than functional.

A possible privacy problem You might wonder, what happens when Bob hits reply-all to say "Yes, I'm coming"? Then (oh no!) Charlie might see the invitation. Not a problem: Most of my friends use Gmail, and Gmail users almost always hit Reply instead of Reply-All. Gmail used to have an experimental option called "Reply All by Default", but thankfully they removed that option. A future version of this specification might suggest mangling the last "." in the BCC:d email addresses with the ONE DOT LEADER character, which looks like "." but isn't one. That way, even if Bob clicks "Reply all," Charlie's email address is subtly incorrect and will bounce.

Future work The story I've told here is marginally simplified so it's understandable to a less-technical audience. Those who want a more technical version can request I submit an RFC. Perhaps in two months? (File under "games to play with email.")

6 February 2010

Cyril Brulebois: G-I, part 4

A picture is worth a thousand words: A slightly longer story follows, resuming from the previous episode, where Gtk seemed to be working. Making sure Gtk actually works Since the udebs are quite fat already, I decided to put the contents of the gtk2.0-examples package into a new revision of the new libgtk-x11-udeb package. gtk-demo was running fine (if one forgets that this demo application is really easier to deal with if one uses a window manager), although image handling was broken. Julien and I spent quite some time double-checking that the libpixbufloader-png.so plugin was present; that both previous DirectFB-based udeb and new x11-based udeb were very similar; that configuration was generated properly; we went so far as to include strace in the netboot image, and to check the configuration file was open() d, but the plugin was never to be even looked for. All this resulting in a Unrecognized file format message every time. Josselin, our Messiah, enlightened us: although Gtk was previously using some configuration files to determine which pixbufloader plugin to use, it still continues to access those files but relies on a MIME database in the end. Installing the host s /usr/share/mime/mime.cache database did the trick (we have a proper fix pending), and all of a sudden, we got image support (which is needed for the logo_installer.png displayed on top of every screen, as well as for some icons during the installation, like the final one). Tweaking d-i itself Julien took care of rootskel-gtk. It was mostly about: Another easy step was cdebconf. Mostly: search and destroy on the few bits using DirectFB. An interesting issue we had was that even though a proper cursor theme was installed and made the default, we only had a black cross as X pointer. That s where we learnt it s needed to manually set a cursor for the root window, which can be done this way: 
GdkCursor *cursor = gdk_cursor_new(GDK_LEFT_PTR);
gdk_window_set_cursor(gdk_get_default_root_window(), cursor);
gdk_cursor_unref(cursor);
Tweaking gtk2-engines was trivial, just a matter of building against the x11 flavour of Gtk instead of the directfb one. Some substitutions in debian/control and debian/rules, and that was done. Julien also took care of tweaking console-setup so that keyboard-configuration s and console-setup-udeb s postinst scripts call setxkbmap when $DISPLAY is set. Meaning we were able to replace kbd-chooser with console-setup-udeb, leading to a correct setting within X right after having selected the layout! Reverting d-i s r61645 (which disabled Gtk-based d-i images) was trivial (although while looking back, it was probably unnecessary), and after having messed around with the packages lists (there s a lot of local udebs at this point), especially to add some fonts, we managed to get an image which seems to work fine (at least in my VirtualBox environment). I tried Chinese, Japanese, Arabic, and French installations, and all of them seem to work fine (installed systems were bootable after an installation in the selected language) while issues were limited to some rendering or translation glitches, which didn t seem critical at all. Next steps Since there were some iterations, and since the trial-and-error approach was chosen, the first goal is to generate clean patches against all modified packages, and make sure a single walk through all packages in a clean chroot is sufficient to generate a working d-i image again. Once that done, which should probably considered (at least, I hope!) quite a good base already, the idea is to look into the various udebs to see whether there are some parts that could be disabled (maybe introducing a trimmed-down flavour especially for the udeb in some non-flavoured-yet libraries), so as to reduce the size of the resulting image. In the meanwhile, one can fetch the current hand-built netboot image by browsing http://people.debian.org/~kibi/di-x11/. It s only available for amd64, and weights 23MB. There s a sha256sum as well as a detached GPG signature in the same directory.

5 February 2010

Cyril Brulebois: G-I, part 3

Last night was the third one spent on playing around with X in a d-i environment. Making sure X actually works So far, running X was nice already, but is it really possible to run some applications inside? Bad news is that many trivial applications (xeyes, xclock, ) pull more dependencies than previously packaged. Finally, xev was chosen, and it indeed works fine (provided one makes sure it gets the focus). X was crashing when the (only last) client was exiting, and that wasn t normal. Thankfully the bug was reproducible outside d-i and Julien sent a patch a few minutes later. In the meanwhile, using -noreset did the trick to keep X running. Another way to run X applications there, is to point the host environment to the guest environment using DISPLAY=$GUEST:0 xterm. With VirtualBox, I followed those steps: Moving forward: cairo, pango, gtk The next step was to rework some udebs. Legend: Current situation, keeping only the relationships between udebs of interest: I took care of gtk+2.0 while Julien hacked pango1.0 and cairo. Some more libraries were needed, but being X libraries, tweaking the packaging was as trivial as for the first X libraries, and it only took a couple of minutes: libxcomposite, libxdamage, and libxinerama. Once those added to localudebs/ and to pkg-lists/local, and once the image rebuilt, I prepared a tiny Hello world -style application: Pango wasn t quite happy at first (message wrapped): 
(hello:1991): Pango-WARNING **: failed to choose a font, expect
              ugly output. engine-type='PangoRenderFc', script='latin'
Indeed, since no fonts were included, there was a tiny issue. No big deal, adding ttf-dejavu-udeb did the trick. I wanted to play around with a non-Latin language, so I asked for an example (thanks, Theppitak!), and once ttf-thai-tlwg-udeb added as well, one gets: Of course, there are many more features to test, but that sounds like we re going in the right direction (and this is not a joke about RTL). Next step Have a look at the green boxes, which may require to have a closer look at g-i s integration within d-i (it might be needed to see how it s supposed to be started, that might help testing the tweaked packages).

Adrian von Bidder: Multiple Interfaces, Same IP

Playing around a bit with ssh tunneling right now. When I create a kind of VPN concentrator with a few tun interfaces: is there any reason why I can't just assign the same IP on all these tun interfaces? A quick test shows this set up working nicely, with ifconfig tunX localip pointopoint remoteip (the localip part being the same) setting up the routes to chose the right tun device for all remote IP addresses, and ping worked just fine for me. Firewall rules will always have the remote IP and/or the interface name to decide when a packet applies. Obviously setting up a listening socket at only one of these interfaces is not so trivial now since I can't just listen to the IP, but that's a restriction I'm happy with. Anything else I'm not thinking of right now?

4 February 2010

Mike Hommey: xulrunner 1.9.1.6-2 diff stats

As part of preparing xulrunner 1.9.2 (which would lead to Iceweasel 3.6), I have gone through all the patches currently applied to the latest xulrunner release, to keep track of what should be upstreamed, what needed feedback, what patches I needed to update in upstream bugzilla, etc. As I have talked about our differences with upstream on a few occasions already, and as I was doing this grunt work anyway, I thought it would be nice to make the results public. First, a few reference numbers (excluding changes to generated configure files): A few observations on the above data: The latter used to be true, but is not anymore: xulrunner 1.9.1.6-2 added a lot of changes and is now up to: 98 files changed, 1107 insertions(+), 517 deletions(-). What happened ? will you ask me. A lot happened: the test suite, attempts at correctly installing C++ headers and IDL files, bug fixes. Work has also been done such that make clean/distclean doesn t leave stuff around and that xulrunner can be properly built twice in a row. Differences between 1.9.1.6-1 and 1.9.1.6-2 look like this: 31 files changed, 341 insertions(+), 167 deletions(-). Some were stolen from bugzilla (13 files changed, 162 insertions(+), 70 deletions(-)): Many others were sent: A few others were filed without a patch, as I felt a proper upstreamable patch needed discussion (3 files changed, 16 insertions(+), 3 deletions(-)): A few changes are related to the way we build and how we run the test suite (5 files changed, 35 insertions(+), 18 deletions(-)): Finally, a few were related to the Debian changes history (2 files changed, 1 insertions(+), 26 deletions(-)): Going through the rest of the changes between upstream and the latest Debian release, we can split in 5 categories of changes:
Those that were picked from upstream, or sent and eventually applied in 1.9.2 or trunk (12 files changed, 68 insertions(+), 41 deletions(-)): Those that were picked from bugzilla or sent there, but are not applied upstream for various reasons (29 files changed, 138 insertions(+), 209 deletions(-)): Those that were reported but for which I wanted feedback for a proper fix, yet a patch was applied in Debian because this was necessary (6 files changed, 22 insertions(+), 13 deletions(-)): Those that are yet to be sent to bugzilla (15 files changed, 111 insertions(+), 54 deletions(-)): And finally, the changes that are either Debian specific or not deemed upstreamable (30 files changed, 460 insertions(+), 77 deletions(-) ; this can sound huge, but see the details below): Note, the numbers in the various diff stats obviously don t add up, since some changes overlap. All that information doesn t account the few additional components added in debian/filemonitor and debian/extra-stuff, that account for nearly 600 lines (excluding licensing boilerplate), but I ll talk about these in another post. This analysis also helped spotting another harmless merge error (the first one was spotted a few weeks ago and just left the enable-system-lcms around, without any effect): a variable replacement in a Makefile that doesn t have any effect, since the 2 variables have the same value. Only a pointless 1 line change.

3 February 2010

David Welton: Italy vs Google

I'm starting to notice a pattern here: One way of seeing things is that politicians and businessmen in Italy noticed Google was actually making quite a bit of money, and even if they don't quite understand this internet thing, they want some of the loot. And while Google certainly is becoming big enough to be cause for worry and discussion, the moves against them in Italy do not seem anything like a rational response calculated to offset severe failures in the market. In any case, it will be interesting to see what happens. Maybe, after China, we'll see Google quit Italy as well?

Pablo Lorenzzoni: Swiss Tournament in Ruby

Being a chess player (not a very good one), I ve always been intrigued by Swiss Tournaments. They are so practical, and ensure that even a lowsy player like myself, can play the same number of rounds as any other player. That s being inclusive! I ve played some knock-out tournaments (to me it meant being kicked off in the second or third round), and, given their nature, not-so-good players tend not to attend these tournaments (since their fun will, almost surely, end before long). Well, to solve a very similar problem, but not in any game championship, a co-worker suggested we could use a Swiss Tournament system. I liked the idea, but not being sure it could really solve the problem, I had to quickly implement something to test our data with so Ruby to the rescue! In no time we were up and running, and apart from minor issues that were being fixed along the way, I guess it s a pretty good implementation. You can checkout the code to get a feel of it. Of course, it doesn t follow any rules from any Chess or Go association (Wikipedia, after all, was my guide here), but it serves our goal. Being a proof-of-concept code, feel free to improve it (just tell me about it, will you?).

Cyril Brulebois: G-I, part 2

Getting to X After having prepared a bunch of libraries, the idea was to get X in shape. I d like to thank Julien Cristau very much for his support all along the way, since I knew nothing about X. Basically the plan was to get: Not much to say about the former, it only pulled two additional libraries compared to what was previously udeb-ified: libaudit0 and libselinux1. Since security modules aren t the primary concerns in this exercise, --enable-xselinux quickly became --disable-xselinux and those dependencies went away. Both drivers were trivial to tweak, nothing really worth noting there. Once those 3 additional packages added to localudebs/ and to pkg-lists/local, the mklibs tool really wasn t happy with them during the rebuild of the netboot image, since the drivers are X plugins, meaning they need symbols which aren t defined in other libraries. Example: 
No library provides non-weak EventSwapVector
Since the idea is to get something working rather than getting something perfect at once, d-i s packages/mklibs/src/mklibs.py (installed as /usr/bin/mklibs) was told to stop raising an exception, and to print a warning message instead. Rebuilding an image was then working again. It took some time, but finally it got noticed those packages were actually all installed in the initramfs, so there was no need to try and load/install them manually during the installation process, everything was there already, and it was sufficient to switch to VT2 to see the /usr/bin/Xorg binary. Some packages were still needed: xkb-data, and x11-xkb-utils. The latter also pulled libxkbfile1, but well, an additional library doesn t sound very scary. At this point, one has to try and run Xorg. The result was a black screen, and no means of getting back to another terminal, be it inside Qemu or VirtualBox. Troubleshooting X First idea: adding the openssh-server-udeb package to the image, and start sshd from there. But then one has to go through the missing config file, tweaking privilege separation, generating a host key, setting a password, etc. And for whatever reasons, it wasn t possible to access it. That s where the DebianInstaller/NetworkConsole page on the Debian Wiki came into play: it includes a few steps to get a working sshd within d-i, painlessly. So, X was actually starting properly, but getting a black screen is now the default. One wants X -retro to get the well-known old behaviour. From udevadm info --export-db, it looked like input stuff were missing, and indeed, udev-udeb doesn t include /lib/dev/input_id and /lib/udev/rules.d/60-persistent-input.rules. Since scp seems broken, wget from the host did the trick followed by chmod +x for the input_id file, otherwise that doesn t work so well. But still, there were some missing evdev stuff. And indeed evdev wasn t to be seen in lsmod, nor available to be modprobe d. That s where it became a little dirtier: wget and udpkg on mouse-modules-2.6.30-2-amd64-di, followed by depmod to make sure, and then modprobe was OK. A little udevadm trigger run to ensure udev was fully aware of the new situation, and restarting X led to a moving cursor there, as well as a working keyboard, since it was possible to switch between terminals! Prove it! Alright, I m proudly providing you with a screenshot: (Really, I ve never been so happy to see this fracking black-and-grey-grid screen. I kid you not!) If we forget about the very few network-console-related questions answered to get an sshd running, please note that the installation process is still just starting, the very first debconf question is still unanswered. Now, patching udev again so that udev-udeb includes the two mentioned files was almost easy (details aren t important anyway), while pulling evdev.ko module automatically was trivial, just a matter of adding such a line to a packages list (I picked pkg-lists/netboot/amd64.cfg): 
mouse-modules-$ kernel:Version
Which means one can now, out of the box: Next step Rework the Pango/Cairo/Gtk stack to use X11 instead of DirectFB.

1 February 2010

Cyril Brulebois: G-I, part 1

Producing udebs How to patch That s actually quite trivial. Most packages from Josselin s 1st and 2nd lists are libraries, and generating udebs for libraries is easy. Basically it boils down to declaring a new binary package: Now, populating it might depend on the considered source package, but thankfully, pkg-x11 packages are quite sane, using debhelper s dh_install. So duplicating debian/libfooN.install into debian/libfooN-udeb.install is usually sufficient. It s a bit trickier when dh_movefiles is used, but calling install and cp -r after the dh_movefiles call should be sufficient. Next step, tweak shlibs for libfooN. Without that step, a libbarM package built against libfooN would get libfooN in Depends, which is not appropriate. The idea is to get libfooN-udeb instead. Trivial: add --add-udeb=libfooN-udeb to the dh_makeshlibs call. Possible issues at that step: Various checks to perform: Results (These files might be moved around during the following steps, but this post shall be kept up-to-date and point to them at all time.) Legend: Graphs are scaled down to 75%, click for full size. Step 1: Step 2: Adding udebs to a d-i image Basic d-i image General guidelines (see d-i documentation for detailed installation, needed packages, etc.): 
svn co svn://svn.debian.org/svn/d-i/trunk/ debian-installer-trunk
cd debian-installer-trunk/installer/build
make build_netboot
If that breaks (e.g. due to missing packages), make sure there s a similar entry in sources.list.udeb: 
deb http://yourmirror/debian squeeze main/debian-installer
If everything goes well, the generated image should be available as dest/netboot/mini.iso, and tmp/netboot/udeb.list should contain the list of embedded udebs. To give it a try: 
qemu-system-x86_64 -cdrom dest/netboot/mini.iso
Actually adding udebs Drop all additional udebs under localudebs/. Needed Packages and Packages.gz should be generated on the fly (but beware, secure apt is then disabled, even for non-local udebs). Now, tell d-i we want some more packages. If all of them are wanted, one can do that: 
for i in localudebs/*.udeb; do \
  dpkg-deb --showformat='$ Package \n' -W $i; \
done > pkg-lists/local
(Update: Thanks to Guillem for pointing out a better and cleaner way than dpkg --info $i grep Package: awk ' print $2 ') Generate a new image (note the rebuild part of the target): 
make rebuild_netboot
Make sure they got added by looking in tmp/netboot/udeb.list and profit! What s next Future steps include: Stay tuned.

31 January 2010

Gregor Herrmann: RC bugs 2010/04

again, I focussed on the RC bugs in the perl group. & again, carnil++ was very active both in finding & in fixing them :)

Stefano Zacchiroli: RC bugs of the week - issue 19

RCBW - #19 Back with the "ordinary track" of RCBW, here is this week squashes by yours truly: The attentive reader have noticed that there is one more than usual, the reason is the mighty BSP in M nchengladbach, which has powered all above squashes. I've enjoyed the BSP a lot, my first in M nchengladbach, which won't be the last. I recommend checking it out at least once in the future, even only for tasting Formorer's chili :-) The main highlight of the week is my personal award to the best feedback ever from an NMU-ed maintainer, the award goes to Jonas, kudos for your attitude.

Cyril Brulebois: Saving Private G-I

(Disclaimer: this post is not about G.I.) Graphical installer Josselin posted his thoughts about g-i, and given at least the first parts sound doable, I m tempted to have a look at dealing with the needed udebs. Never touched anything like this before, but oh well, one learns every day. Time to learn a bit more about X11 as well. It looks like generating a new mini.iso (using d-i s trunk) wasn t that difficult, so hopefully once I m done with a few udebs, it should be possible to add them to this image and make sure those are usable, at least when loaded manually. Once that finished, gluing everything together is probably going to be another story, but hopefully that won t be impossible. Unrelated stories

Next.

Previous.