I bought a new laptop: the ultrathin Satellite T130!

I’m not writing a post about this (awesome) laptop, but on how to make it working with your (Arch) Linux OS.

• Graphics. The Intel GMA 450 works fine with the official Intel driver without any patch; install xf86-video-intel and start X.
• Wireless. Here there are issues. This laptop uses a wireless card with the Realtek 8192SE chipset. There’s a driver, but ATM isn’t included into the last kernel, so you need to build and install the RTL8192SE driver. Take it from AUR.
• Bluetooth. Works! Install bluez package and nothing else.
• Touchpad. Everything works here too. I setup vertical/horizontal and circular scrolling with two fingers (I never tried it before, it’s really nice). Just install xf86-input-synaptics and set your config. Here mine.
• Webcam. I did only a test using mplayer and…works!
• Audio. To mute speakers after headphones connection I had to add a line to modprobe.conf: options snd-hda-intel model=dell-vostro.

In conclusion everything works fine, but I still am trying to made backlight control working; I added the known acpi_backlight=vendor kernel line to GRUB with no lucky.

EDIT: A man sent me a script to fix the backlight issue. The trick is easy: using setpci you can hack the brightness. Then I set up KDE Power Management to run sudo setpci -s 00:02.0 F4.B=40 when I am using Powersafe profile, and sudo setpci -s 00:02.0 F4.B=99 when I am using Performance profile. (You need to add the rule to your sudoers file). This is enough for me, you could use a script to increase/decrease the brightness editing the F4.B argument. Thank you Petri!

Cheers

 
Now available.
 
archone.sourceforge.net
 

 
archone.sourceforge.net

It’s true…It’s live!

Yes men, Repoman is reasen from the dead.

Due to my engagements Repoman development stopped one year ago. Also [deelab] repository was dead and I didn’t need a tool to manage any repository.

But some days ago I joined into [unarch] team, [unarch] is a new repository maintained by few Italian people. So, I need a tool to build and upload packages without fool around.

I completeamely rewrote Repoman. I made it more simple to use, syntax is similar to pacman/makepkg. For example, to add a package you must type $ repoman -S foo meantime if you want to add a package without extract source files (using existing src/ dir) you must type $ repoman -Se foo. Another news is -l, ‘L’ for log: makepkg will log everything. Latest thing, finally all packages are uploaded together using the same lftp session and old packages are removed after the upload of newer packages.

This Repoman looks better too, useful messages and less colors.

Give it a second chance, and let me know what do you think of it ;)

package on AUR

I have two points that i want to clarify about our ffmpeg package.

• the “downgrade” from 30526-1 -> 22511-1 is actually an update, but because my lack of glasses </joke>, i used the wrong revision number when i changed the version schema from a date to revision.
• don’t mark as out of date this package because 0.5.1 version is released,  don’t do  it even when 0.6 will be released. We don’t follow 0.5 branch and even 0.6 branch. We are following trunk because, as one developer once said,  “packaging yet another, “soon to be outdated” version that is not supported by us is not a good idea.”

Hi guys,

GNOME 2.29.92 packages have been uploaded to the Archlinux FTP. To use this repository, you should add this as top repository to pacman.conf:

[gnome-unstable]
Include = /etc/pacman.d/mirrorlist

The packages in the repository have been built in a chroot with testing enabled. Dependencies are mostly versioned. Anyone who’s willing to help on spotting potential bugs, please submit them to our bugtracker[1]. We also have a gnome-unstable thread on our forum[2]

Have fun testing these packages.

[1] http://bugs.archlinux.org
[2] http://bbs.archlinux.org/viewtopic.php?id=79706&p=13

This is  a fork of archbang build with my build scripts. I added some pentesting packages and fixed up the instaler. The installer is under system-> Installer. Its based on the archlinux installer.

Here are the features of archbang-live:

* All/most of  the features that are in archiso-live and slax.

* findiso boot option so you can boot from iso with grub2.

* Development packages.

* Bauerbill replaces packer that’s in archbang.

* Using testing repo.

* Updated kernel to 2.6.33.

Bugs:

* Sound is set to 0% on every reboot.

live password is live

root password is ArchLinux

Everything is up2date as of 3:00 PM on 20100306.

Here is the iso, md5, and packages list.

Package changes here.

rm -R /home/user/.cache/chromium
mkdir /home/user/.cache/chromium
sudo nano /etc/fstab: 

....
cache-chromium    /home/user/.cache/chromium tmpfs defaults,noatime,mode=1777

This is what happens if you ignore a weed growing on your lawn for a while. It grew to over four metres and had thorns all along the stem. In an effort to convince me that I should remove it, my wife found out that it is a Giant Devil’s Fig, which is classified as a “Noxious weed” in Brisbane. After much nagging, I chopped it down before the native bats could eat its fruit and spread it further.

And yes, my lawnmower is missing a front wheel…

A while back, I wrote about using an x86_64 kernel on an i686 userland. After using this setup for a while, I began to discover that it is not that user friendly to have to use linux32 in front many commands. In particular, when building software the ./configure needs to be prefixed with it and bash can not handle creating an alias to transparently do that. Also, I would need to make aliases for all build tools I could encounter (make, cmake, qmake, …), which is almost an impossible task.

In true Baldrick style, I came up with a cunning plan… What if I called my shell with a linux32 prefix and then my system would think it was always an i686 one. I only need my system to think it is an x86_64 when I enter an x86_64 chroot, so that is much easier to create aliases to deal with. The trick was to create a /bin/bash32 file containing:

#!/bin/bash
linux32 /bin/bash -l "$@"

Then add bash32 to the list of shells in /etc/shells and use “chsh -s bash32” to start using it.

After using this setup for several weeks, the only issue I notice is that when using chroot, it will look for /bin/bash32 in the chroot and likely fail. That can be fixed by prefixing with the SHELL environmental variable pointing at an appropriate shell (more than likely /bin/bash). I am sure that creating a wrapper script to handle that would be easy but using chroots via the Arch devtools does not suffer from this problem so I have not looked into it further.

For those that don’t know, the first ever ArchCon will be held in Toronto, Ontario, Canada on July 22 and 23. Ralvez and I are the primary organizers. We’ve got some great presentations lined up and are becoming more confident that we’ll have enough attendees to fund conference activities.

The earlybird registration deadline is fast approaching; you have four days to register for only $100. Register at the registration page: http://archcon.archlinux.ca/

For more information, visit the ArchCon website: http://www.archlinux.ca/archcon2010/

Dieter has set up a couple of wiki pages to help people collaboratively plan the conference, and more importantly, social and vacation activities around the conference. He’s coming all the way from Belgium, and is looking for other Archers to do some road trips and tourist attractions with while in North America.

http://wiki.archlinux.org/index.php/Archcon#Archcon_2010
http://wiki.archlinux.org/index.php/Archcon_extra_activities

The Chakra Project is a “distrolet” based on Arch Linux and providing its own KDE packages (collectively called KDEmod). I really do not like KDE so I am only interested in how the install goes. I used QEMU with a 4GB image and 512MB RAM with the 2010-01-10 “Aesop” installer.

The installer is live CD based, so boots you into a nice looking desktop [01]. Starting the installation takes you to a graphical install system [02] with the prerequisite warning about being an alpha release and the issues it can cause your hamster. After reading some notes and agreeing to various EULAs [03], the install is all go.

Onto the preparation of your system. The language and time settings looked quite ugly [04], but I have suspicions that QEMU was running this quite slow and maybe this was an artefact. I found it good to know that despite the complexities of installing being hidden, there was options to go in deeper [05] if needed. Partitioning [06] was not particularly simple, but that is being reworked for the future.

The actual installation of packages [07] proceeds with a montage of screenshot to whet your appetite for your new install. Of course you probably have already seen what it looks like from the live CD… Then you create some new users [08] (although I do not know what exactly an “Administrator” is), enter the root password and install the bootloader. I have no idea what the “Configure System” item at the end of the installer sidebar does as after installing the bootloader I got a reboot dialog.

The booting system looks familiar [09] to any Arch Linux user. I had expected a graphical boot-up as I had heard something about it using Plymouth, but I guess that is for the future. The login screen indicates that the /etc/hosts file has issues with setting the hostname [10]. Other than that, I was left with a fully working KDE desktop with no obvious issues. Looking at some configuration files to see how well the automatic set-up went found some interesting points. The MODULES array in /etc/rc.conf both disables and enables the e1000 module [11]. Also, I noticed that kdm is started as a daemon rather than using the inittab method, which I guess is more in line with what Chakra wants to provide but I find that to be less flexible. The supplied pacman.conf has the repos listed in an interesting order [12] (I think [core] should at least come before the KDEmod repos).

Overall, the installer does its job despite a few rough edges. The install booted to the desktop with relatively few configuration issues that I could spot. Not bad for something labelled “alpha”. Is it the “Arch made easy” that is often touted on Distrowatch Weekly comments? Maybe. But with a distro like Arch, that is not necessarily a good thing.

Screenshot index:

[01] – Live CD Desktop
[02] – Installer start screen
[03] – EULAs
[04] – Language and timezone setup
[05] – Hidden “advanced” options
[06] – Partitioning
[07] – Package installation
[08] – User creation
[09] – Bootup
[10] – Login
[11] – /etc/rc.conf
[12] – /etc/pacman.conf

*** 187f:0201 unknown device HOW TO ***

 
This’s the device, an unknown usb adapter dvb-t:

[~] lsusb
.....
Bus 001 Device 011: ID 187f:0201
.....

and these are the relative modules:

[~] lsmod
.....
smsusb                 7956  0
smsmdtv              25562  1 smsusb
.....

To fix the error that I’ve reported in the post title, you should try one of the 3 dvb-t firmware available at http://steventoth.net/linux/sms1xxx/ in this way :

cd /lib/firmware/
sudo wget http://steventoth.net/linux/sms1xxx/sms1xxx-hcw-55xxx-dvbt-01.fw
sudo mv sms1xxx-hcw-55xxx-dvbt-02.fw dvb_nova_12mhz_b0.inp

now try to unplug and plug the adapter, and if the firmware that you have select is correct, then it should work:

sudo tail -f /var/log/messages.log
.....
.....
smscore_set_device_mode: firmware download success: dvb_nova_12mhz_b0.inp

but it isn’t true!
 
In fact, if you see only that line as the final output of the message.log, then the device probably still doesn’t work!

You can verify by checking if the modules have created the directory /dev/dvb:

[~] ls /dev/dvb
ls: impossibile accedere a /dev/dvb: No such file or directory

that directory should exist, with a subdirectory called adapter, because without it software like xine or kaffeine cannot interact with the device.

After various tests, I’ve discovered that the cause of the problem is the latest kernel .32 : I’ve try on kernel26-lts 2.6.27.45-1 (of the core repository) and the message.log now gets these new lines:

sudo tail -f /var/log/messages.log
.....
.....
Feb 21 13:04:28 stazione2 kernel: firmware: requesting dvb_nova_12mhz_b0.inp
Feb 21 13:04:29 stazione2 kernel: smscore_set_device_mode: firmware download success: dvb_nova_12mhz_b0.inp
Feb 21 13:04:29 stazione2 kernel: usbcore: registered new interface driver sms1xxx
Feb 21 13:04:29 stazione2 kernel: DVB: registering new adapter (Siano Nova B Digital Receiver)
Feb 21 13:04:29 stazione2 kernel: DVB: registering frontend 1 (Siano Mobile Digital SMS1xxx)...

and ta-daa!

[~] ls /dev/dvb
adapter0
[~]

…still I cannot update it.

The problem is with Akonadi: it does not start with MySQL 5.1.43 and does not start with the new MySQL release too.

I reported this on bugs.kde.org three weeks ago (#225333); others people confirmed this issue (#226960) and I think that Akonadi developers are working on it, logs do not help too much.

So, seems that we will skip this minor release too. Stay tuned.

Hackage now has 1851 Haskell packages, of which 1541 (84%) have been natively packaged for Arch in AUR. All these packages are available via AUR, using the “bauerbill” tool (or other full-resolving package tool for Arch).

You can find the status of all Haskell packages in Arch here, regularly updated using the archlinux Haskell package tools.

Since the GHC 6.12 upgrade, there have been some major package updates:

• darcs-beta 2.3.99.2
• haskell-hslogger 1.0.9
• haskell-missingh 1.1.0.3
• haskell-haxml 1.20.2
• haskell-hdbc 2.2.3
• and many more …

Most things are now ready for GHC 6.12, with the notable exception of packages that:

• depend on gtk2hs (not yet released for GHC 6.12)
• parsec < 3 (Arch will be downgrading to parsec 2 to be HP compliant).

After far too many delays, I’ve finally shipped all the outstanding case badge orders. The badges arrived today, after a delay in production and mailing, and all envelopes have been packaged; they’ll be in the mail tomorrow. I spent a lot of time stuffing envelopes this evening!

I would like to apologize to everyone who has been waiting for badges; the preorder form has been up since early December. I originally said they’d be shipping in early January, and a 1.5 month delay is truly unacceptable. Thanks to everyone for their patience; I will try to perform better in the future. I’ve certainly learned not to rely on shipping estimates!

The new badges are a more modern looking than the old ones; I’ll try to update the pictures on http://schwag.archlinux.ca/ tomorrow.

Changes since last release:

* Updated aufs2 module.

* Updated my mkinitcpio scripts in my build scripts.

* Removed shaman from iso since its not in repo anymore. Its mostly cause no one can build i686 version anymore.

* I found out that some pentium M cpu will not work with my newer pae kernel.  I’m sorry for the inconvenience. Pae kernel was the better way for   still having i686 os with wine and virtualbox-ose support. This also meant i didn’t need to build and upload 2 isos.

Everything is up2date as of 4:50 PM EST on 20100217.

root password is ArchLinux

arch password is arch

Here is the iso, md5, and package list.

Package changes here.

There have been some major changes in Arch’s early userspace tools recently. So I thought I’d take the time to sit down and explain to everyone what these changes are about.

Booting Linux Systems: Why do we need Early Userspace?

Traditionally, booting a Linux system was simple: Your bootloader loaded the kernel. The kernel was extracted and initialized your hardware. The kernel initialized your hard disk controller, found your hard drive, found the root file system, mounted it and started /sbin/init.

Nowadays, there is a shitload of different controllers out there, a huge number of file systems and we are a good distro and want to support them all. So we build them all into one big monolithic kernel image which is now several megabytes big and supports everything and the kitchensink. But then someone comes along and has two SATA controllers, three IDE controller, seven hard drives, plus three external USB drives and who knows what. The Linux kernel will now detect all those asynchronously – and where is the root file system now? Is it on the first drive? Or the third? What is “the first drive” anyway? And how do I mount my root file system on the LVM volume group inside the encrypted container residing on a software RAID array? You see, this is all getting a bit ugly, and the kernel likes to pretend it is stupid – or it simply doesn’t care about your pesky needs, especially now that it has become so fat after we built every imaginable driver in the world into it.

What now? Simple: We pass control to userspace, handle hardware detection there, set up all the complicated stuff that people want, mount the root file system and launch /sbin/init ourselves. You are probably asking yourself “How do I execute userspace applications when the root file system is not mounted?”. The answer is: magic!

What is initramfs?

Okay, the answer is not magic. The answer is actually initramfs: Each Linux system has a ramfs file system that is always mounted and called rootfs. You will probably never see it, because your real file systems are mounted over it. However, the kernel also has a compressed cpio archive attached to it that it extracts directly into rootfs after boot. Even better, you can attach a compressed cpio archive to your kernel from the bootloader which is also extracted into rootfs.

Before the kernel runs the old-fashioned init code, it checks whether rootfs contains a file called /init. If it does, it skips the traditional mounting/init code and instead executes /init. This program is now responsible for doing all these complex task that the kernel thought to be too complicated. This way, we can build a kernel that has no built-in support for any hard disk controller or filesystems at all, instead we build them all as modules (this is actually what we do in the Arch Linux default kernel) and include the needed ones in the initramfs image.

klibc – The Purgatory of the Distro Initramfs Maintainer

klibc was originally created to be a small and lightweight C library for early userspace. It comes with a number of tools to support you in setting everything up. It also comes with klcc, an ugly perl script that calls gcc and builds binaries against klibc instead of your usual C library. When mkinitcpio was originally created in 2006 by Aaron Griffin as a replacement for the old, unflexible mkinitrd and mkinitramfs scripts, it was decided to base it on klibc. From the beginning, klibc had lots of problems:

• The set of shipped tools was limited and the tools that were included lacked vital options.
• Most external tools could not be built against klibc or had to be heavily patched to do so.
• There was no dynamic linker, all binaries were hard-linked against a specific version of klibc – this version changed every time anything in the klibc source or the kernel headers you built against changed, requiring a rebuild of all binaries that used klibc.
• It was not possible to create any dynamic libraries other than klibc itself.

All this resulted in high maintenance effort to keep udev and module-init-tools working, we also had to maintain a small klibc-extras package with our own tools to replace those that were missing from klibc, and we had to include any more advanced application like lvm or cryptsetup as glibc-based statically linked binaries.

At some point, klibc stopped being compatible with the current kernel headers and we had to introduce more and more hacks to be able to rebuild it again when needed. As of Linux 2.6.30, I was unable to build a working version of klibc at all, leaving us with an old binary which could not be bugfixed anymore. In the middle of 2009, upstream died completely, there were no commits made to the git repository anymore, and the mailing list only received a handfull of posts each month. That was when I started to ask myself the following question: Where is the point in maintaining a separate C library and tools that are only used for a fraction of a second each time you boot? What we supposedly gained from this was a smaller initramfs and thus faster boot time.

Keeping it simple

In 2009, I decided that in order to be able to create an initramfs environment with low maintenance effort, many features and much flexibility, the following changes needed to be made:

• Do not maintain a separate C library for it, simply use the one from the normal system
• For basic system and scripting tools, use busybox to get a good compromise between high functionality and small binary size
• For filesystem label, UUID and type detection, use util-linux-ng’s blkid for full and bleeding-edge support of all new and old filesystems
• For other advanced functions, use modprobe, udev, lvm, cryptsetup, mdadm/mdassemble from the normal Arch packages

This way, I would only need to maintain the mkinitcpio scripts themselves and a properly configured busybox binary. I had used busybox for quite some time on my OpenWRT router(s) and was thus familiar with how awesome it was. It also turned out that implementing NFS root support was easier if we used the nfsmount and ipconfig utilities that were shipped with klibc.

It is February 2010 now, and in the last few weeks I finally had the time to do all the work. Just a few days ago I released mkinitcpio 0.6. This version is much stabler, more flexible and less error-prone than any klibc-based version we ever had in the past. On average, the initramfs is now between 600KB and 1MB bigger than the klibc-based ones, I guess nobody will ever complain about that – it is still smaller than on most other distributions. And I am glad that I hopefully never have to touch klibc again.

Hi,

I’m going to remove this package from community and move it to aur because Facebook now has support for XMPP, along with it also is moved json-glib.

• http://wiki.archlinux.org/index.php/Pidgin#Facebook_XMPP
• http://blog.facebook.com/blog.php?post=297991732130

Just because something can be validated does not mean it should be validated. It’s very easy to validate form fields in django and most other web frameworks. That does not mean we should always take advantage of this feature.

Why did I just get this error when creating a user account on a website?:


Error. The password field can contain only letters and numbers


I had included a couple of punctuation characters in my password, because that makes it harder to guess, right?

From a technical standpoint, there is absolutely no reason for this website to tell me I can’t use punctuation characters. If they’re encrypting ascii, then any ascii character should be legit. If they’re encrypting bytestreams, then any unicode byte should be legit.

The only validation a password field should have is to test if the password is ‘too easy.’ Typically a minimum length test is enough, but ensuring the user didn’t enter five 1s or their username as a password can be good validation too (although it’ll annoy the user, not often a good thing). You may also need a maximum length if your database is poorly designed, but make it a very high maximum in case anal-retentive people with 64 character passwords want to buy something from you. After all, why shouldn’t you let them?

Further, don’t force your users to have passwords that conform to arbitrary rules like ” must contain at least one number, one lower case letter, and one capital.” This actually cuts down the total number of options a brute force attacker needs to check if they want to break the password; they now know that eerieairplane is not an option they have to test. After all, eerieairplane and EerieAirPlane are totally different passwords, neither is more “guessable” than the other (unless you are a pilot for Lake Eerie Air, in which case you’re probably better off using pokertoMatotoOthpaste).

Users have different systems for creating their passwords; some of these systems aren’t very intelligent (same password everywhere, or prepend the name of the site to a common word), but forcing a single system of our own on them is even less intelligent.

While we’re on the subject, what’s up with all the corporate sites who believe that having security questions in case you forgot your password helps make things more secure? Honestly, do you think that my random password with extra punctuation is easier to guess than my first dog’s breed, my mother’s maiden name, or my favourite author? What’s the point of having a password at all if both I and any given attacker can just look up these values instead?

Since i became trusted users i’ve seen in the paste months an increasing number of packages submitted in AUR that are in our official repositories. But i don’t want to talk more about this since there is already a rule in our AUR User Guidelines.

I want to talk what you should do when a build  already exists in AUR but for a reason needs to be updated and is not yours:

1. submit in comments an up to date PKGBUILD
2. if the maintainer doesn’t update it, send him an email
3. ask the maintainer if he wants to orphan it
4. send an email to aur-general asking for orphaning

Some user ignore the above and submit a new PKGBUILD with a different name. This in my opinion is the worst thing that can happen since users will be confused and doesn’t know what to use(in the past we had a lot of builds doing the same thing for chromium) and trusted users will have a lot of work trying to clean AUR. A good example is opera which have no more no less than 20 builds.

Change of wind: in the release 2010.04 (04 ?) of ArchOne, you’ll find the new kernel-netbook instead of kernel26-one-dev.

I’m currently testing it on my Aspire One, and although it is still in development, is already working very well.

The kernel is developed by Diego, and includes all the modules used by major netbooks: Acer Aspire One, EeePC, MSI Wind, Samsung N series and many others.
 
For example, it supports the following wireless modules:

• ath5k
• ath9k
• rt2860
• rtl8187se
• broadcom-wl

Some features:

• KMS
• no initrd
• static modules
• packet size around 5 mb
• patchset of Arch
• BFS of Kolivas

This’s the project site, and this’s the link on the Italian forum.