Heh, now I can ride!
Saturday, 12 April 2008
Thursday, 20 March 2008
News from other worlds
I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.
When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .
Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.
Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time
So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.
Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.
Fatality two - why fatality one was met
All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.
This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).
Fatality three - why rpm based system fail to have upgrade support today
Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:
And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).
More bad ideas from the rpm land (glad not to be there)
In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.
They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.
When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .
Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.
Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time
So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.
Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.
Fatality two - why fatality one was met
All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.
This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).
Fatality three - why rpm based system fail to have upgrade support today
Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:
- new-preinst 2
- new-postinst 2
- old-prerm 1
- old-postrm 1
And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).
More bad ideas from the rpm land (glad not to be there)
In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.
They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.
Saturday, 8 March 2008
mistranslations - how to deal with it
Aigars, you could use what I already made for the compedia creation. The code is available on i18n.debian.net in my home dir (I thought I exposed it on alioth, too, but I just checked and is not).
The results for latvian are also present.
The results for latvian are also present.
Wednesday, 5 March 2008
email harvesting prevention - simple and efficient
On this page I've seen this nice way of preventing email addresses harvesting (I have noscripts installed):
When javascript is enabled/permited, it looks like this:
The code is really simple and could be easily automatically applied to pages (the code obfuscates even more, but that is irrelevant - see the original source for the code):
BTW, the PC-BSD site looks really nice, unlike Debian's.
When javascript is enabled/permited, it looks like this:
The code is really simple and could be easily automatically applied to pages (the code obfuscates even more, but that is irrelevant - see the original source for the code):
<script language='JavaScript' type='text/javascript'>
<!--
var prefix = 'ma' + 'il' + 'to';
var path = 'hr' + 'ef' + '=';
var addy35780 = 'g.martinez' + '@';
addy35780 = addy35780 + 'pcbsd' + '.' + 'es';
document.write( '<a ' + path + '\'' + prefix + ':' + addy35780 + '\'>' );
document.write( addy35780 );
document.write( '<\/a>' );
//-->\n </script><script language='JavaScript' type='text/javascript'>
<!--
document.write( '<span style=\'display: none;\'>' );
//-->
</script>This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
<script language='JavaScript' type='text/javascript'>
<!--
document.write( '</' );
document.write( 'span>' );
//-->
</script>
BTW, the PC-BSD site looks really nice, unlike Debian's.
Debian Games Team - have source, but do not import :-/
JoeyH wrote a while back some thoughts on why he hates the DGT SVN repo (mainly our policy to import just the incomplete source of packages - usually just the debian/ directory).
He updated that blog entry and latter said:
Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work.
I was thinking, how about having a different area of the repo where the full source is present and which pulls the debian directory as an external from the current location?
I know it has the huge disadvantage that anything outside of the debian/ directory, but part of the diff, is, for sure, lost. (Still, there is also another team policy to not track anything outside debian directly, except through patches[1], except for really exceptional cases, but even then, there is a need for a strong justification).
Would that work? (I know git-svn doesn't support externals properly, yet, so there's not much gain).
[1] I know Joey, you hate those, too
He updated that blog entry and latter said:
Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work.
I was thinking, how about having a different area of the repo where the full source is present and which pulls the debian directory as an external from the current location?
I know it has the huge disadvantage that anything outside of the debian/ directory, but part of the diff, is, for sure, lost. (Still, there is also another team policy to not track anything outside debian directly, except through patches[1], except for really exceptional cases, but even then, there is a need for a strong justification).
Would that work? (I know git-svn doesn't support externals properly, yet, so there's not much gain).
[1] I know Joey, you hate those, too
Sunday, 2 March 2008
pbuilder - /etc/pbuilderrc no longer a conffile (333294)
I have just finished a completely functional patch for pbuilder's bug #333294. I started this during debconf7, to be more precise, just after Junichi's talk about pbuilder. This patch makes pbuilder smarter smarter about the information it places in the MIRRORSITE variable of the /etc/pbuilderrc.
And now that file is no longer a conffile[1], and it asks some questions via debconf. And since debconf is translatable, there is a Romanian translation, too.
I have published my changes in my pbuilder git repo on alioth.
Anyone interested in the changes can pull from that repo:
git://git.debian.org/git/users/eddyp-guest/pbuilder.git
or
http://git.debian.org/git/users/eddyp-guest/pbuilder.git
[1] this was the main reason the patch wasn't good enough, since modifying a conffile is RC.
And now that file is no longer a conffile[1], and it asks some questions via debconf. And since debconf is translatable, there is a Romanian translation, too.
I have published my changes in my pbuilder git repo on alioth.
Anyone interested in the changes can pull from that repo:
git://git.debian.org/git/users/eddyp-guest/pbuilder.git
or
http://git.debian.org/git/users/eddyp-guest/pbuilder.git
[1] this was the main reason the patch wasn't good enough, since modifying a conffile is RC.
Saturday, 1 March 2008
TDebs - arch is not important, is it?
Updates:
While looking at Neil Williams' talk(hi-res/lo-res) from FOSDEM about cross building and tdebs I was STUNNED about the many (not all, thanks Frans) points that were reiterated during that talk when there were already answered.
Well, I guess you have to repeat yourself a lot to get your ideas through to the other side. So, let's do that.
All (except the first) of the following have been already answered one way or another on the TDebs wiki page.
Q: .mo files are arch independent or not? Neil asks again on his blog.
A: It doesn't matter, does it?
Q: The packages file will explode
A: No, that's addressed.
Q: How do you select languages?
A: Simply use what we have and expand on that.
Q: Do tdebs support anything else than gettext?
A: Yes.
- the arch issue raised by Frans was not the object of my post. Also, not all points are invalid/reiterated, just the ones iterated here. Thanks Frans.
- add a note that there is an image that proves that .mo endianness is irelevant - usefull for readers that might miss that
While looking at Neil Williams' talk(hi-res/lo-res) from FOSDEM about cross building and tdebs I was STUNNED about the many (not all, thanks Frans) points that were reiterated during that talk when there were already answered.
Well, I guess you have to repeat yourself a lot to get your ideas through to the other side. So, let's do that.
All (except the first) of the following have been already answered one way or another on the TDebs wiki page.
Q: .mo files are arch independent or not? Neil asks again on his blog.
A: It doesn't matter, does it?
0 eddy@bounty ~ $ file /usr/share/locale/ro/LC_MESSAGES/wormux.mo
/usr/share/locale/ro/LC_MESSAGES/wormux.mo: GNU message catalog (big endian), revision 0, 228 messages
0 eddy@bounty ~ $ uname -a
Linux bounty 2.6.24.2-bounty #1 SMP Wed Feb 13 02:34:09 EET 2008 x86_64 GNU/Linux
Q: The packages file will explode
A: No, that's addressed.
Q: How do you select languages?
A: Simply use what we have and expand on that.
Q: Do tdebs support anything else than gettext?
A: Yes.
Building in a sarge chroot might not always work
Adeodato correctly points out that building under a Sarge chroot, and expecting the package to work on Sid, might not always[1][2] work mainly because of ABI changes and similar changes. Thus, I am forced to clarify this a little.
Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.
So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.
Thanks Adeodato for the heads-up.
[1] unless your package is a special case
[2] or, better said, in most cases
udate: fixed the link to dato's post
Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.
So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.
Thanks Adeodato for the heads-up.
[1] unless your package is a special case
[2] or, better said, in most cases
udate: fixed the link to dato's post
Thursday, 28 February 2008
sarge + cowbuilder = love
Update:
A disclaimer/warning is needed: UNLESS you KNOW what you're doing, you probably are better off building packages for each of the supported Debian distros.
I know it sounds cheesy, but I couldn't find a better name.
At my workplace we are packaging software to work for as many distros as possible at one time. As a consequence the .deb packages we produce should work fine on all Debian distros: oldstable, stable, testing, sid.
To make sure we achieve that, we are building them in an oldstable chroot. OTOH, using pbuilder is very demanding on I/O, especially when entering the chroot and when exiting it. That slows down a lot the build system and is time to change that.
One reliable alternative is to use cowbuilder (part of cowdancer package). What is interesting is that cowbuilder relies on the existance of /usr/bin/cow-shell inside the chroot, so the cowdancer package needs to be installed both in the chroot and the host machine.
But cowdancer was not a part of sarge, so, if you try to create a new sarge cow directory with cowbuilder, it will fail at the end saying it didn't found the cowdancer package. Also trying to login via cowbuilder --login will complain it didn't found /usr/bin/cow-shell.
The fix for this is simple, once you figured it out and saw that cowdancer is available in sarge as a backport:
Write the same command as before, but omit everything starting with --othermirror. Then install by hand the package in the chroot.
Since after the bootstrap all .deb packages will be in the apt cache in the chroot, you might want to save some disk space:
That's it!
If anything is broken somehow, missing or whatnot, cowbuilder --login --save-after-login is your friend.
[1] the initial bootstrap does not pull from backport anything else but cowdancer
[2] since you want to compile for plain sarge, not sarge+backports ;-)
A disclaimer/warning is needed: UNLESS you KNOW what you're doing, you probably are better off building packages for each of the supported Debian distros.
I know it sounds cheesy, but I couldn't find a better name.
At my workplace we are packaging software to work for as many distros as possible at one time. As a consequence the .deb packages we produce should work fine on all Debian distros: oldstable, stable, testing, sid.
To make sure we achieve that, we are building them in an oldstable chroot. OTOH, using pbuilder is very demanding on I/O, especially when entering the chroot and when exiting it. That slows down a lot the build system and is time to change that.
One reliable alternative is to use cowbuilder (part of cowdancer package). What is interesting is that cowbuilder relies on the existance of /usr/bin/cow-shell inside the chroot, so the cowdancer package needs to be installed both in the chroot and the host machine.
But cowdancer was not a part of sarge, so, if you try to create a new sarge cow directory with cowbuilder, it will fail at the end saying it didn't found the cowdancer package. Also trying to login via cowbuilder --login will complain it didn't found /usr/bin/cow-shell.
The fix for this is simple, once you figured it out and saw that cowdancer is available in sarge as a backport:
cowbuilder --create --distribution sarge --basepath /var/cache/pbuilder/sarge.cow --othermirror 'deb http://www.backports.org/debian sarge-backports main'
You may prefer to be sure that the only thing from backports is cowdancer and use a more hands-on approach[1]. Also, this will eliminate the need to correct later the apt sources to exclude backports[2].Write the same command as before, but omit everything starting with --othermirror. Then install by hand the package in the chroot.
twix:/home/eddy# cowbuilder --create --distribution sarge --basepath /var/cache/pbuilder/sarge.cow
twix:/home/eddy# chroot /var/cache/pbuilder/sarge.cow
twix:/# wget http://ftp.de.debian.org/backports.org/pool/main/c/cowdancer/cowdancer_0.23~bpo.1_i386.deb
twix:/# dpkg -i cowdancer_0.23~bpo.1_i386.deb
twix:/# rm cowdancer_0.23~bpo.1_i386.deb
twix:/# exit
twix:/home/eddy# cowbuilder --update
Since after the bootstrap all .deb packages will be in the apt cache in the chroot, you might want to save some disk space:
twix:/home/eddy# cowbuilder --login --save-after-login
twix:/# aptitude clean
twix:/# exitThat's it!
If anything is broken somehow, missing or whatnot, cowbuilder --login --save-after-login is your friend.
[1] the initial bootstrap does not pull from backport anything else but cowdancer
[2] since you want to compile for plain sarge, not sarge+backports ;-)
Postfix - (almost) a satellite system
When installing postfix and configuring it to act as a "Satellite system", all mails, including messages to root, will go to the remote mail delivery system. Also, there might be a local user account that absolutely doesn't exist on the remote MTA and should stay on the local machine, but, by default, this doesn't happen.
This is not good.
What is needed in such a case is virtual_alias_maps and a /etc/postfix/virtual file such as:
This tip is particularly useful on laptops.
This is not good.
What is needed in such a case is virtual_alias_maps and a /etc/postfix/virtual file such as:
root root@localhost
root@fqdn.domain.name root@localhost
eddy eddy@localhost
eddy@fqdn.domain.name eddy@localhost
This tip is particularly useful on laptops.
Monday, 18 February 2008
[VCS/SCM] same language, different lingo
When people say "lightweight branches":
Export means:
No wonder we have communication problems and people don't grasp the power of a new tool when it changes the meaning of previously used terms.
- In git lingo, most likely they will think about the fact that you don't need a different directory to switch to a different branch.
- In subversion lingo, they will probably mean that the cost of making a branch in the repository does not impose an expensive operation
- In bzr lingo, it seems they mean a repository with short history (aka shallow copy, for most other people)
- it seems that mercurial refers to git's meaning as "named branches" (not sure about this); not sure if mercurial documentation refers to anything else as "lightweight branches"
Export means:
- for subversion: to create a working copy without any meta information
- for mercurial/hg: "The act of exporting a changeset generates an augmented patch file that describes the change."
- for git, it seems to be a useless 'cp -r' operation
No wonder we have communication problems and people don't grasp the power of a new tool when it changes the meaning of previously used terms.
Tuesday, 12 February 2008
wireless prohibition
After setting up wireless via WPA2-PSK with AES and realizing I really need the new firmware, I ended up using the latest wireless-2.6 kernel from branch 'everything'.
Now I am again browsing wireless-ly and I am wondering if the digital divide isn't already here:
Is there any reason why this discrimination is done? do they fear that they won't be able to sell the series?
Now I am again browsing wireless-ly and I am wondering if the digital divide isn't already here:
Is there any reason why this discrimination is done? do they fear that they won't be able to sell the series?
Friday, 8 February 2008
forking privately in Debian
Joachim, the key is probably to implement patch support in srcinst and actually implement something nice which I think has nice applications.
It might be nice to combine srcinst with debian-xcontrol to obtain also customizable dependencies (e.g. no arts support).
I guess you'll be the best person to take over srcinst since:
The basic idea is to have another command[1] wrap aptitude/apt-get/srcinst and make sure it does the proper job, depending on the local configuration.
[1] let's say, the debtoo command - srcinst should remain the tool for clear 'from source installs'
It might be nice to combine srcinst with debian-xcontrol to obtain also customizable dependencies (e.g. no arts support).
I guess you'll be the best person to take over srcinst since:
- John Goerzen doesn't want to/can't continue maintaining it
- is written in Haskell and you know Haskell
- source is available for grabs from http://darcs.complete.org/srcinst/
The basic idea is to have another command[1] wrap aptitude/apt-get/srcinst and make sure it does the proper job, depending on the local configuration.
[1] let's say, the debtoo command - srcinst should remain the tool for clear 'from source installs'
wpa2-psk with aes on a broadcom wlan0 (2.6.24)
Update: I managed to find out why the wpa_action stuff was needed. Please ignore the lines written like this; they are there just for reference.
One more update: it seems that the firmware needs to be in sync. I ended up using the wireless-2.6 kernel from the everything branch.
I just managed to get my wlan from my laptop to work with WPA2-PSK with AES with the free Broadcom driver (now named b43, formerly bcm43xx).
The final trick was to convince wpasupplicat to reload the config with:
This is what it looks like when is working:
Thanks to all people involved in b43 development and all the ones made this possible (Debian developers).
Posted from bed, via wlan.
Update: You need the firmware blob, which can be extracted from a Windows driver with bcm43xx-fwcutter (now called b43-fwcutter);I already had it from my previous attempts to configure wlan with bcm43xx. I am not sure if I should use the new tool. You really need the firmware and driver to be in sync.
Update: it seems the b43 driver page (the entire linuxwireless.org site) went down sometime yesterday evening, since yesterday afternoon I was browsing through the site without any issues. (Note: I live in Europe, for reference)
One more update: it seems that the firmware needs to be in sync. I ended up using the wireless-2.6 kernel from the everything branch.
I just managed to get my wlan from my laptop to work with WPA2-PSK with AES with the free Broadcom driver (now named b43, formerly bcm43xx).
In order to do this I needed linux 2.6.24-1 from unstable and the b43 driver.
0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
0b:00.0 0280: 14e4:4311 (rev 01)
bounty:/home/eddy# lsmod | grep b43
b43 119976 0
rfkill 12816 3 rfkill_input,b43
mac80211 132236 1 b43
led_class 10120 1 b43
input_polldev 9872 1 b43
ssb 39428 2 b43,b44
pcmcia 45720 2 b43,ssb
pcmcia_core 46500 2 b43,pcmcia
firmware_class 15232 2 b43,pcmcia
This is the wpasupplicant.conf file that I used:bounty:/home/eddy# wpa_action wlan0 reload
wpa_action: reloading wpa_supplicant configuration file via HUP signal
bounty:/home/eddy# cat /etc/wpa_supplicant/wpasupplicant.conf | grep -v '^\s*#' | sed 's/psk=.*/psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd/'
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="toblerone"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd
}
and this is the relevant interfaces area:auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpasupplicant.conf
wpa-ap-scan 2
This is what it looks like when is working:
And here's the result of a scan (relevant section):
bounty:/home/eddy# iwconfig wlan0
wlan0 IEEE 802.11g ESSID:"toblerone"
Mode:Managed Frequency:2.412 GHz Access Point: 00:1B:FC:45:33:70
Bit Rate=48 Mb/s Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:1337-0000-C121-d73D-0207-RE41-0000-3210 [2]
Link Quality=98/100 Signal level=-36 dBm Noise level=-68 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Cell 02 - Address: 00:1B:FC:45:33:70
ESSID:"toblerone"
Mode:Master
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=93/100 Signal level=-42 dBm Noise level=-68 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
12 Mb/s; 48 Mb/s
Extra:tsf=0000000072ff542d
and here is proof it works:bounty:/home/eddy# route -nWoooohooo! :-)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.77.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.77.254 0.0.0.0 UG 0 0 0 wlan0
bounty:/home/eddy# ping debian.org
PING debian.org (192.25.206.10) 56(84) bytes of data.
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=1 ttl=36 time=201 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=2 ttl=36 time=199 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=3 ttl=36 time=200 ms
--- debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 199.691/200.519/201.046/0.786 ms
Thanks to all people involved in b43 development and all the ones made this possible (Debian developers).
Posted from bed, via wlan.
Update: You need the firmware blob, which can be extracted from a Windows driver with bcm43xx-fwcutter (now called b43-fwcutter);
Update: it seems the b43 driver page (the entire linuxwireless.org site) went down sometime yesterday evening, since yesterday afternoon I was browsing through the site without any issues. (Note: I live in Europe, for reference)
Subscribe to:
Posts (Atom)