Search Results: "Julien Viard de Galbert"

5 March 2017

Julien Viard de Galbert: Raspberry Pi 3 as desktop computer

For about six months I ve been using a Raspberry Pi 3 as my desktop computer at home. The overall experience is fine, but I had to do a few adjustments.
First was to use KeePass, the second to compile gcc for cross-compilation (ie use buildroot).
KeePass I m using KeePass + KeeFox to maintain my passwords on the various websites (and avoid reusing the same everywhere).
For this to work on the Raspberry Pi, one need to use mono from Xamarin:
sudo apt-key adv --keyserver hkp:// --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo "deb wheezy main"   sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mono-runtime
The install instruction comes from mono-project and the initial pointer was found on raspberrypi forums, stackoverflow and Benny Michielsen s blog.
And for some plugin to work I think I had to apt-get install mono-complete. Compiling gcc Using the Raspberry Pi 3, I recovered an old project based on buildroot for the raspberry pi 2. And just for building the tool-chain I had a few issues. First the compilation would stop during mnp compilation:
 /usr/bin/gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -O2 -Wa,--noexecstack tmp-divrem_1.s -fPIC -DPIC -o .libs/divrem_1.o
tmp-divrem_1.s: Assembler messages:
tmp-divrem_1.s:129: Error: selected processor does not support ARM mode  mls r1,r4,r8,r11'
tmp-divrem_1.s:145: Error: selected processor does not support ARM mode  mls r1,r4,r8,r11'
tmp-divrem_1.s:158: Error: selected processor does not support ARM mode  mls r1,r4,r8,r11'
tmp-divrem_1.s:175: Error: selected processor does not support ARM mode  mls r1,r4,r3,r8'
tmp-divrem_1.s:209: Error: selected processor does not support ARM mode  mls r11,r4,r12,r3'
Makefile:768: recipe for target 'divrem_1.lo' failed
make[]: *** [divrem_1.lo] Error 1
I Googled the error and found this post on the Raspberry Pi forum not really helpful
But I finally found an explanation on Jan Hrach s page on the subject.
The raspbian distribution is still optimized for the first Raspberry Pi so basically the compiler is limited to the old raspberypi instructions. While I was compiling gcc for a Raspberry Pi 2 so needed the extra ones. The proposed solution is to basically update raspbian to debian proper. While this is a neat idea, I still wanted to get some raspbian specific packages (like the kernel) but wanted to be sure that everything else comes from debian. So I did some apt pinning. First I experienced that pinning is not sufficient so when updating source.list with plain debian Jessie, make sure to add theses lines before the raspbian lines:
# add official debian jessie (real armhf gcc)
deb jessie main contrib non-free
deb-src jessie main
deb jessie/updates main
deb-src jessie/updates main
deb jessie-updates main
deb-src jessie-updates main
Then run the following to get the debian gpg keys, but don t yet upgrade your system:
apt update
apt install debian-archive-keyring
Now, let s add the pinning.
First if you were using APT::Default-Release "stable"; in your apt.conf (as I did) remove it. It does not mix well with fine grained pinning we will then implement. Then, fill your /etc/apt/preferences file with the following:
# Debian
Package: *
Pin: release o=Debian,a=stable,n=jessie
Pin-Priority: 700
# Raspbian
Package: *
Pin: release o=Raspbian,a=stable,n=jessie
Pin-Priority: 600
Package: *
Pin: release o=Raspberry Pi Foundation,a=stable,n=jessie
Pin-Priority: 600
# Mono
Package: *
Pin: release v=7.0,o=Xamarin,a=stable,n=wheezy,l=Xamarin-Stable,c=main
Pin-Priority: 800
Note: You can use apt-cache policy (no parameter) to debug pinning.
The pinning above is mainly based on the origin field of the repositories (o=)
Finally you can upgrade your system:
apt update 
apt-cache policy gcc 
rm /var/cache/apt/archives/* 
apt upgrade 
apt-cache policy gcc
Note: Removing the cache ensure we download the packages from debian as raspbian is using the exact same naming but we now they are not compiled with a real armhf tool-chain. Second issue with gcc The build stopped on recipe for target 's-attrtab' failed. There are many references on the web, that one was easy, it just need more memory, so I added some swap on the external SSD I was already using to work on buildroot. Conclusion That s it for today, not bad considering my last post was more that 3 years ago

19 June 2013

Julien Viard de Galbert: Building a custom debian CD

The French version is available on : Cr e un CD d installation d une debian sp cialis e The goal is to build a debian install CD suitable for the distribution of a complete system including the operating system and applications. Debian already has a tool for that purpose: simple-cdd. Simple-cdd is a set of scripts wrapping debian-cd which is the tool used to build official CDs. In our case, we will include some non-free packages (firmwares for instance) and application specific packages in the system. Using simple-cdd Simple-cdd gets some of its configuration from your host computer, so it s recommended to work on a machine similar to your target (in particular the machine should use the same architecture: i386 or amd64). All the following actions should be done in a working directory that will contain the downloads and configurations for our system. We will start by creting a configuration file my-cdd.conf stating the mirror and components to use:
mirror_components="main contrib non-free"
Then we will launch the build-simple-cdd tool once. This will build a local mirror of the needed packages that we will reused later. So be patient this can be a bit long.
build-simple-cdd --conf ./my-cdd.conf
Once done, you should get a CD iso in the images subfolder. Customizing the image To customize our image we will create a profile my-profile that will define which package to install and which extra package to include on the CD (dev packages for instance). Create a profiles folder:
mkdir profiles
Selecting the packages If you ve got an already installed machine (the one you used to test your application) you can ask dpkg to list the installed packages from that machine and use that as a basis.
dpkg --get-selections >package-list
In this file only the names of packages in the install state are needed:
grep -e '\<install$' package-list   awk ' print $1 ;' >profiles/my-profile.downloads
The file my-profile.downloads is a list of packages to include on the CD-ROM. The list of program to install is my-profile.packages . The tool will resolve dependencies, so we don t need to track down all dependencies add add them to these files. Specific packages We want to add some custom packages that we built ourselves to the CD, those packages not present in the debian archive. Let s create a local_pkg folder and fill it with all of our packages. We now can update the configuration to use all those files and make the profile my-profile the default profile.
mirror_components="main contrib non-free"
If you now run the tool again, you ll get a full custom install CD!
build-simple-cdd --conf ./my-cdd.conf
However you might have missed some specific packages or their dependencies, in that case they will be missing on the CD. To find this out, check the messages for a line like:
WARNING: missing optional packages from profile my-profile: libevent-2.0-5 [...]
In that case libevent from squeeze-backports was missing. Simple-cdd is not able to download packages from backports, so I just added the packages to local_pkg . Customizing the installer Simple-cdd automatically uses a default profile. This profile might not suite your needs. To override it you just have to place modified file in the profiles folder. To do so, first copy the desired file from /usr/share/simple-cdd/profiles/ and update it. For instance the default.pressed file:
cp /usr/share/simple-cdd/profiles/default.pressed profiles
Then update the wanted options in this file. For example the partitioning options. Also as we enabled contrib and non-free you should uncomment the following lines:
d-i apt-setup/non-free  boolean true
d-i apt-setup/contrib boolean true
Adding extra files to the CD Finally we want to add the documentation, sources and other files to the CD. Simple-cdd can add files to the simple-cdd folder but there is no way to add a complete directory structure. However, as we can override the profiles, we can also override some scripts, especially tools/build/debian-cd that builds the CD.
mkdir -p tools/build
cp /usr/share/simple-cdd/tools/build/debian-cd tools/build
Then add the following lines after the $extras_base_dir cleanup:
if [ -d "$cd_extras" ]; then
  mkdir -p "$extras_base_dir"
  cp -a "$cd_extras/." "$extras_base_dir"
Finally let s add the cd_extras variable to our configuration file :
Be careful to not create files conflicting with the CD content, nothing would warn you about that! Conclusion We now have a way of building a debian install CD including any files we might want to deliver with our system: sources and documentation for example.

3 April 2011

Julien Viard de Galbert: Kernel develpoment on e60

Now that I have access to the serial console on Samsung e60 reader let s build a new linux kernel for it. The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don t seam to embed homemade patches. As for ggc I didn t take time to check.
I choose to use the emdebian cross-development toolchain lenny version. (As the article in the french open silicium magazine #1 about FriendlyARM proposes to do). Installing the cross-development toolchain on debian First the archive keys:
sudo apt-get install emdebian-archive-keyring
Then we add a /etc/apt/sources.list.d/emdebian.list file with the following content:
deb lenny main
deb-src lenny main
The we update the package list to install the needed packages:
sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi
That s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove. The kernel sources Samsung released it s modified version. By cloning the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the version (the last in the branch). In order to better sort the changes michel.s had splat them into several patches
(patchs on e60-open project). After a few trials I build a series file allowing to apply those patches with quilt or better to import them to a git branch with git quiltimport. The order I choose allows to drop easily some patches (the last ones). One particular point on those patches is that some include binary files: U-Boot Before compiling the kernel, we need the mkimage utility from U-Boot. Here, Let s build the U-Boot released by Samsung, and let s just copy the tools/mkimage to a location in our PATH (that s the only install method I could find).
make smdkc100_config
make CROSS_COMPILE=arm-linux-gnueabi-
cp tools/mkimage ~/bin/
Building linux For the config, one of the patches includes a .config. That file is a copy of config_rfs so even without the previous patch, we can get Samsung s config. Finally we can compile!
make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage
We can then load our kernel by following The kernel testing howto from e60-open project. To load the kernel we will need the following command:
sudo dnw arch/arm/boot/uImage
That it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the /lib/modules/max14540.ko and lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel. Missing source code The Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let s wait Conclusion We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for and our kernel does not want to load them. (I ve already done a few tests but that will be a next posts topic.)
But without the missing sources it will be hard for us to best use our e60 reader. Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.

Cyril Brulebois: Debian XSF News #8

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).
  1. Let s start with a few common bugs reported over the past few weeks:
    • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
    • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
    • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
    • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
  2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
  3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
  4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
    • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
    • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
  5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
  6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
    • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
    • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
    • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
  7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
    • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
    • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
    • [KiBi] xterm: new upstream, to unstable.
    • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
    • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
    • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
    • [KiBi] libxp to unstable, nothing fancy, that s libxp
    • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
    • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
    • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
    • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
    • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
    • [KiBi] siliconmotion video driver: to unstable.
    • [KiBi] pixman: new upstream release candidate, to experimental
    • [Sean] last but not least: many compiz packages to experimental.

14 March 2011

Julien Viard de Galbert: Triage X Bugs of the Week (TXBW18)

Better later than never, I restarted to triage last week, here is the report for it. In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage. Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD. The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

4 March 2011

Cyril Brulebois: Debian XSF News #7

Time for a seventh Debian XSF News issue!

11 February 2011

Julien Viard de Galbert: Triage X Bugs of the Week (TXBW12)

This report is 2 week late It was delayed by an important event, not the release of squeeze, but the birth of my first child: C lestine is born Monday the 31th of January. My wife and C lestine are both fine now but the firsts days were not that easy. I m starting to recover from the lack of sleep, but I m still very late on my debian tasks ;) So I guess I just drop Triaging for week 13, 14 and maybe 15 Now the bugs I triaged just before : The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

1 February 2011

Cyril Brulebois: Debian XSF News #3

Time for a third Debian XSF News issue! Debian XSF News #3 It s been a year On a personal note, it s been a year to the day since I first looked into X. After having hacked on the Debian Installer to make it use X.Org instead of DirectFB, I did some heavy bug triaging, resulting in a drop in the xorg-server bug count in March. The same happened past week as written above, resulting in a second drop. In the meanwhile, the bug count remained more or less stable, since we try to reply quickly to new bugs, and since Julien Viard de Galbert does bug triaging on a weekly basis: BTS graph for xorg-server One might ask: what does maintaining X mean?

22 January 2011

Julien Viard de Galbert: Triage X Bugs of 2011 first Weeks (TXBW9-10-11)

I ve been lasy about the reporting lately, so this is a 3 weeks update at once ! The bug count according to udd is down to 818. I guess this is due to Kibi s triaging on input related bugs, but I helped to close a few one too ! I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! ;) The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

21 January 2011

Cyril Brulebois: Debian XSF News #2

Time for a second Debian XSF News issue! I ll skip stuff related to the new katamari since I wrote about that already.

17 January 2011

Julien Viard de Galbert: Triaging bugs is not that hard !

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer s job. While it s true in general, some understaffed teams are so flooded by bugs that they just can t do it.
I ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks! Then the thread evolved in lots of directions, I m not following all of it, but there was the question of the bug triaging and as I m doing it for the X packages, I want to share about my experience here. The available triaging docs The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o ! Now if all those docs don t help you, then try to improve the docs as a first step ! ;) Talk with the maintainer(s) Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway. My current process This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!
  1. List bug from UDD: XSF unstable bugs sorted by date.
  2. Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
  3. Read the report, don t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
  4. If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it s not that often that I have something to test).
  5. Decide what to do, most of the time, I will ping the submitter.
  6. I m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
    So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
    The triaging procedure suggest to ping -submitter, but using mutt it s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
  7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
  8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
  9. When the submitter answers, just react accordingly, if the bug can be closed, then close it ! ;)
  10. If after some time, the bug are still not answered, consider closing them (I haven t started that yet, but this will probably get the bug number down faster:) ).
Note: Sometime I don t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. ;) To submitters, please keep the bug CCed when you answer, thanks. For the skeptics Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don t close bugs if I m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! ;) Also this work might look boring, but it s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I ve learned on Xorg. Conclusion As long as I have time for it, I ll continue to triage bugs and I d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! ;) Get involved !

31 December 2010

Julien Viard de Galbert: Triage X Bugs of the last 2010 Week (TXBW8)

Happy new year ! The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

23 December 2010

Julien Viard de Galbert: Triage X Bugs of the Christmas Week (TXBW7)

For some reason1 bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn t write to me, this bug will have waited for what about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort ;) The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date. Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail.

17 December 2010

Julien Viard de Galbert: Triage X Bugs of the Week 6 (TXBW6)

An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875 The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

9 December 2010

Julien Viard de Galbert: Triage X Bugs of the Week 4 and 5 (TXBW4-5)

Last week I was too busy for the triaging work, so I did more this week Anyway there are still some 871 bug candidate for triaging, so again, any help would be appreciated ! Also I d like to thank again people giving me cheers and advices when they receive my pings ;-) The buglist now: The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

26 November 2010

Julien Viard de Galbert: Triage X Bugs of the Week 3 (TXBW3)

This week it has been harder for me to start on this but KiBi s post Debian XSF News #1 pushed me to continue. Thanks for the cheers! The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

25 November 2010

Cyril Brulebois: Debian XSF News

Since people seem to like it, I ll be trying to publish some news about ongoing work on the XSF side, on a (possibly) regular basis. Let s have a look at what happened since last time I blogged about X in Debian, mostly by checking what appeared in my =debian-x mailbox. Debian XSF News #1 What are the XSF plans?

19 November 2010

Julien Viard de Galbert: Triage X Bugs of the Week 2 (TXBW2)

Hey, one more week ! Well my UDD query report 879 bugs today not a great improvement since last week if more bugs are opened than I can close, I m not going to make it alone ! The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

18 November 2010

Julien Viard de Galbert: Did you realize how great format 3.0 (quilt) is ?

I did just yesterday ! I was hacking on fluxbox and rebuilding the package to test directly on my system.
When I was happy with my changes I thought, I should write a patch for this
But guess what ! With format 3.0 (quilt) it was already there, in the debian/patch directory, just waiting to be renamed and completed with a nice DEP-3 header ! It is a lot more easy to contribute with those tools! So thank you debian folks !

12 November 2010

Julien Viard de Galbert: Triage X Bugs of the Week 1 (TXBW1)

Here is my report for the first week, (actualy I m a little bit late, but friday loked like a better day for such reports) That s it about 880 bugs more to go ! The X Strike Force (still) needs you ! You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.