Dear all,
Version 1.8.1 of babeld, the Babel routing daemon, is available from
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz.asc
This release makes two important changes, and upgrading is strongly
recommended.
> you may find this video interesting:
> https://youtu.be/agPdI7cY5eU
Cool. I see some more info on https://meshpoint.me/
> We are using Babel routing for MeshPoint, and we would like to become
> a more active contributors to Babel project.
Let's try to arrange to meet and have a chat. I'll
> Presently, I'm starting my babeld instances in 2.1 seconds intervals and
> then wait 25 seconds for convergence.
That's not what Babel is optimised for.
Babel is built around the assumption that links are unstable. A Babel
node keeps a fair amount of state so it can reroute quickly in the
> However, using a more convoluted 7-node setup I can hardly get under 40
> seconds.
How are you measuring? Are you rebooting your routers, or merely toggling
links up/down?
If the latter, than there is a problem. If the former, then you should
either make sure that the state file is
>>> My thinking on this is that you only need the host routes when a client
>>> actually roams.
>> This is only going to work if you either use no hold time, or implement
>> the optional algorithm in Section 3.1 of rfc6126bis.
> I'm assuming you mean the ACKed retraction algorithm in Section
Dear all,
According to the current version of the IETF 101 agenda, the Babel meeting
ought to take place on
Thursday 22 March 2018 at 18:10 London (winter) time
Park Suite
https://tools.ietf.org/agenda/101/
Remote participation is possible, and warmly welcomed. Please see
> https://github.com/christf/libbabelhelper
When you feel you're ready, please provide me with a one-line description,
and I'll add a link to the Babel page.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
17:34:25.800782 IP6 fe80::a6b6:7003:d50:6868.6696 > ff02::1:6.6696: babel 2 (8)
hello
17:34:25.801038 IP6 fe80::a6b6:7003:d50:6868.6696 >
fe80::d17a:7827:dae0:58f1.6696: babel invalid header
17:34:25.801075 IP6 fe80::a6b6:7003:d50:6868.6696 > ff02::1:6.6696: babel 2
(24) hello ihu
> The main benefit of a well-known format is that the requirement for a
> client goes from easy parsing code to *no* parsing code.
Right. So either we add a dependency on JSON to babeld, or we add
a trivial parser to every program that consumes babeld's input.
> In this example, parsing the
> I agree that the current format is very easy to parse for a human, which
> is a benefit. I am struggling to have a machine parse this though.
You need a lexer. Here's a simple lexer for you:
https://www.irif.fr/~jch/software/babel/babel-lexer.c
-- Juliusz
Hi,
I've pushed the code to run Babel over unicast. It's in branch "unicast".
In order to use it, you need to say in your config file:
default unicast true
It's a per-interface parameter.
The code is pretty nasty, and not up-to-date with master, so I'll probably
be rebasing it some more.
> Nils and I wrote such a daemon, called mmfd. It is able to forward
> multicast packets in the whole network. To learn about the topology and
> the relevant neighbours, it queries babeld: mmfd is listening via
> "monitor" on the babeld socket.
Good.
> What do you think of providing the same
> I didn't mean any present incorrect behaviour, but rather a weakness which may
> (or may not) reappear at some point later and cause painful bugs
I'm not worried, that's the kind of issue that valgrind is good at
detecting (and I regularly run babeld through valgrind). There's plenty
of other
> I noticed that there's this new commit (b8fb6d896a234eaa06) which removes
> explicit initialization from check_xroutes() in xroute.c.
Fixed, thanks.
(I don't know what I was thinking when I accepted this patch. I need a rest.)
-- Juliusz
___
> The implementation does not have all the battle-tested optimisations of
> babeld at the protocol level.
On the other hand, babeld suffers from having too many features (it serves
among others as a platform for student projects), which implies having
bugs. Like the bug that Gwendoline and
> One thing that fell out of that was mainline babeld had a very
> suboptimal routine for merging routes (also it's use of memcmp was
> inefficient) - and juliusz put out a call for a qsorted implementation
> a while back.
Just to be clear -- the quadratic behaviour is for routes redistributed
> I like to share what I do. Will you be in Berlin for the BattleMesh this
> year?
I haven't decided yet, I've got a lot of work in May and I'm already going
to IETF this spring.
> I am hesitant to implement this because that would require l3roamd to
> identify all the AP on the path and then
> I wasn't aware of Toke's implementation of babel so far. Why are there
> two?
I happen to believe that open (published) file formats and open protocols
are way more important than free software. If the protocol is published,
then it is easy enough to redo the implementation; if the protocol is
> I think babel is meant to do triggered updates however using tcpdump I was
> not able to see them when the route was inserted.
That's a fair assessment. Triggered updates are broken in 1.8.0, they
should work in current master. (My fault for introducing the bug, and
full credit to Gwendoline
Christof, I'm very much interested in your experiments, which are likely
to improve the quality of the Babel implementations.
> We have update-interval set to 5 minutes to reduce the load on the network
> because we are hoping to run this topology on 500+ APs with 1000+ Clients.
The protocol is
> I am using babel 1.8 in an experimental Freifunk network
Cool.
> It seems that routes are accumulating in this network. At the moment there
> are well over 600 routes being distributed by babeld (echo dump |nc ::1
> babelport reveals 617 lines).
> I am probably missing something essential
Ok, I see.
> The algorithm let every node in a network compute its own value of "Load
> Centrality" and afterwards let nodes disseminate computed indexes so
> that each node, at convergence, is aware of the centrality index of all
> nodes in the network.
[...]
> For the moment forget that
> I would like that Babel-nodes running an implementation of the original
> protocol (call them standard-nodes) would be able to "forward
> information" contained in sub-TLVs coming from "extended-nodes".
[...]
> Is it possible to accomplish this kind of “silent-propagation”?
No. In Babel, an
> While not exactly a flag day from a protocol perspective, the commit
> removing keep-unfeasible will break existing startup scripts and conf
> files that have it enabled.
> https://github.com/jech/babeld/commit/0111f5c1d69ce643a6a76a811eb8f89fb4deb936
Right. Need to add it to the changelog.
> But I have a set of additional routes (created by olsrd) on
> - host_a (debian) in the main kernel routing table
> - host_b (openwrt) in a dedicated routing table
> But none of the gets considered to be announced.
You need to explicitly ask babeld to announce these routes. You need to
add
> Hi, myself and Justin Kilpatrick have done a lot of this kind of stuff, and
> Docker is kind of a distraction IMO.
My colleagues are divided on that subject. Matthieu is rather fond of
Docker, while Gwendoline prefers nemu.
-- Juliusz
___
> I am trying to run babeld inside docker here:
> https://github.com/zoobab/babeld-in-docker
> I can't get 2 containers to see each other, and I can't figure out why
> (multicast or any ipv6 option might not be enabled by default).
> If someone can help...
Is the filesystem shared between the
> I see, however the project has already been accepted so i will have to
> do it anyway :(
Good.
Perhaps you can tell us more about the project, so we can work together at
tweaking its parameters to make sure it is useful to the wider Babel
community? Preferably on the list, since there's a
will speak about the recent evolution of the protocol;
- Juliusz Chroboczek will open the security discussion;
- Zheng (Sandy) Zhang will speak about BIER over IPv6.
BIER is a technology for multicast forwarding that doesn't require
per-session state in every router, and therefore has a chance
> The other values in the appendix are from babeld, aren't they?
Uh-huh.
I'll think it over.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Forwarded with permission of the author.
--- Begin Message ---
Hi Juliusz and Toke
I am fixing some issues in Babel code in BIRD related to seqno requests
and i found that parts of the Babel RFC less than clear.
1) 3.2.6. The Table of Pending Requests
The table of pending requests contains
> I've got a working commit that adds price as an unsigned integer in
> between the metric and prefix fields in route updates.
You're modifying the base protocol rather than doing an extension, so
please change the header so that unmodified Babel routers don't try to
associate with your routers.
Added babel-users to CC.
> During discussion about this the other night, I guessed at an admin
> distance of 100 for Babel. In conversation this morning with Don
> Slice he indicated that a number of 100 might be a bit low as that do
> we really trust Babel more than OSPF? Do people have
>> I confess curiosity, now that we have quagga, bird, and mainline babeld
>> versions, and nifty new stuff like unicast hellos, as to how well they
>> interoperate at this point, as well as perform, under a stress test like:
> And FRR...
Babeld and FRR are known to interoperate, but that's
Hi folks,
As some of you may be aware, FRR master branch speaks Babel.
https://github.com/FRRouting/frr
The Babel support is based on Matthieu's old Quagga code.
After some bug fixing by Donald Sharp (thanks!), it's reached the level of
maturity where it can run as an edge router for both
> Could it run on openwrt and mips?
No, GC built binaries for MIPS32 currently require an FPU. I've put
a small ARM board behind my router for that very reason.
The Go team are aware of the issue, and I'm optimistic that this will be
fixed ina future version. You'll still have to live with the
> Cool, but how do I build this thing?
> % go get -v github.com/Vivena/babelweb2
> github.com/Vivena/babelweb2 (download)
> package babelweb2/parser: unrecognized import path "babelweb2/parser"
Thanks for the report, I've forwarded it to the authors.
In the meantime, you can do:
cd ~/go/src
> Nice. But the demo needs more routers :P
Too tired right now, sorry. I need to set up FRR or BIRD to speak RIPng
to our Cisco, so the Babel network gets a default IPv6 route, and to set
up a few wireless routers in random places.
> Is it documented somewhere what information the interface
Dear all,
I've been tasked with organising a meeting about unicast Hellos in Babel.
I've consulted the people I could reach, and Wednesday morning appears to
suit at least a few of them.
So let's meet on
Wednesday 19 July at 10am
I'll see tomorrow morning if I can get a room at the Hilton.
Dear all,
The Babel working group meeting at IETF 99 will be on
17th July 2017 at 17:40 CEST in room Athens/Barcelona
If you're attending IETF 99, please come. If you're not attending, please
do try to participate over this new-fangled Interenet thing:
>> 1. ad-hoc mode doesn't work as well as infrastructure mode;
> Has anyone tries using 802.11s configured interface?
Interesting idea. I'd be surprised if it worked much better than plain
ad-hoc mode, but I'd love to be proved wrong.
>> If you're using diversity routing (Babel-Z), be
>>
Hi Valent,
> my name is Valent and I'm founder of www.otvorenamreza.org which is a
> partner project with Wlan Slovenia (we are neighbours) and also
> www.meshpoint.me
We know. You're famous :-)
> We currently have mostly single radio nodes (tplink wr841nd and
> ubiquiti nanostation Loco m2)
> I'm wondering... what if, in the hypothetical routing protocol "Babble",
> one got rid of multicast hellos and ETX entirely, and routed using RTT
> measured by unicast hellos.
Interesting idea.
I think that's a perfectly legitimate implementation of Babel with Unicast
Hellos: we're leaving the
>> 2. 802.11 uses adaptative rate control on unicast frames, but not on
>> multicast frames.
> This is not entirely true, since hostapd is able to send multicast as
> unicast-frames.
And this will cause Babel's link-quality estimation to yield incorrect values.
Dynamically computed metrics are
> Can you provide text?
Yes, I will do. Please focus on specifying the on-the-wire bits, I'll
take care of the appendix.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
> Does this mean whatever we decide for wildcard requests applies to
> wildcard updates as well?
Yes, er, no, er, I have no idea.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
I've put some CDF graphs of the results here:
https://www.irif.fr/~jch/software/babel/battlemeshv10.html
I've omitted the BATMAN5 data, since it was adding a lot of noise to the
graphs.
It looks like Babel did very well in the 8-17 test, and resonably well in
the others but with a fair number
> Hi, I was wondering what is the best way to enable the RTT metric with
> sensible defaults. It looks like max-rtt-penalty is the option that turns it
> on. What is a good value to set this at starting out?
Yeah, the RTT metric is fiddly. For very good reasons -- it's an
intrinsically unstable
For anyone interested, the Z3 algorithm is named in honour of Benjamin,
the author of the mail I'm replying to.
> Beware also that babel does not support all "recent" channel configurations:
> https://wiki.freifunk.net/ideas
That's not quite true.
> In the absence of explicit diversity routing
> R1(AP mode) ---> R2( Station mode)
All of your routes are single-hop, so there's no diversity information
being propagated. You'll need some longer routes in order to see anything..
> The channel information remains as 11 and 36 for station mode but ap
> mode it is 255. Whether it is
> I have implemented support for subtlvs and the mandatory bit in
> Bird[1][2] and confirmed that it correctly discards source-specific
> updates from Matthieu's branch.
Thanks, Toke!
I should be a little more free starting this week-end, I'll try to get
mandatory bits in all remaining
Matthieu, could you please write up a new version of the I-D with your
encoding? You might want to speak to Gwendoline, since she needs to write
up her TOS-specific encoding.
> If we keep this behaviour and mix tos-specific routes, we will have
> to send 4 wildcard requests to have all routes.
> Unable to find the channel information.
Send the SIGUSR1 signal to babeld (killall -USR1 babeld), then check the
log (using logread if a recent version of LEDE/OpenWRT, in /var/log/babeld.log
if using an older version).
-- Juliusz
___
Babel-users
> Can anyone help me regarding sample config's for diversity routing babel
> configuration.
Just say
diversity true
in /etc/babeld.conf.
You can check that it's working by running babeld with the "-d1" flag, and
checking that the routes carry reasonable channel information.
-- Juliusz
While the protocol is defined to work over either IPv6 or IPv4, all
implementations known to me use IPv6 for control traffic. If you need to
run Babel over a network that cannot carry even link-local IPv6, you'll
need to modify the implementation.
The alternative is to set up an overlay network.
--- Begin Message ---
There is now a mailing list for the design team specifying the
integration of HNCP and Babel security.
The list address is homenet-babel-...@ietf.org
We have added those people that had initial discussions around this
during IETF 97.
Ray and Mark
> I've just done a first draft of mandatory bits in babeld. The code is in
> branch "mandatory" of the github repository. It doesn't look *that* bad.
Matthieu and Gwendoline have fixed some bugs, so if you're tracking that
branch, please pull.
-- Juliusz
Hi,
I've just done a first draft of mandatory bits in babeld. The code is in
branch "mandatory" of the github repository. It doesn't look *that* bad.
If nobody objects too loudly, I'm going to write the protocol up in the
rfc6126bis draft, then merge the mandatory branch into master. Please
> I'm working on securing routing metrics from forgery rather than
> actual encryption/security for the data in transit. I doubt what I
> come up with will end up meeting anyone else's requirements nor be
> upstreamable due to just how much I'll probably end up touching on.
You might be
Folks,
If you have an opinion on the subject, please chime in on ba...@ietf.org.
--- Begin Message ---
Dear all,
As some of you have hinted (more or less rudely), there is an alternative
to the AE-based encoding of source-specific and TOS-sensitive routes that
I suggested: adding a mandatory
Dear all,
[This message is crossposted between both mailing lists, followups to
babel@ietf, please.]
I think there are at least four people interested in making a unicast-only
version of Babel, and that requires adding support to the protocol for
sending Hellos over unicast. We had a discussion
Dear all,
This is just to remind you that there will be a Babel meeting at IETF-98
in Chicago this Tuesday at 13:00 CDT. That's 19:00 Paris time, if I'm not
confused.
https://datatracker.ietf.org/meeting/98/agenda.html
(The Homenet meeting is on Monday.)
You're all warmly encouraged to
Not applied.
> - Add INCLUDES variable for headers
What for? Why do I need to maintain an extra variable?
> - Add support for tags and TAGS
No objection, but I just use a private shell alias.
> - create "reallyclean" to get rid of tags, TAGS, gmon.out, cscope.out
Rejected. There's no need
Rejected.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Applied.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
> In part I broke up the makefile changes because I figured you wouldn't
> like the compile guards
> and whole program stuff, but I found that really helpful later on in the
> rabeld effort, while optimizing and trying to understand how things
> worked.
You're right, don't overdo the squashing.
Thanks a lot, Dave. I've cherry picked the changes that are obviously
correct.
> I am not particularly huge on posting and reviewing patches in-line
> on mailing lists, but I can repost this pull request here, if desired.
Dave, github pull requests are the worst user interface I can imagine.
>> Using Lede 17.01 rc 2 and OpenWRT CC I get some unreachable routes.
>> I'm somewhat puzzled. The setup contains 2 nodes sharing a wireless
>> ad-hoc link.
> .. this happened due to a poor wifi link.
Good. Babel culls asymmetric links, since it's impossible to establish
reliable communication
> Is there a specific emacs or vi "c-style" setting I should use while
> hacking on babeld? (.el file would be helpful)
(setq c-basic-offset 4
indent-tabs-mode nil)
> functions typically start with the { on the first line
Right. In all other cases, { is on the line of the statement
> Sun Feb 19 17:15:45 2017 daemon.info babeld[1171]: Neighbour
> fe80::227:22ff:fe2e:4153 dev wlan0 reach rxcost 256 txcost 65535
> rtt 0.000 rttcost 0 chan 1.
It looks like an asymmetric link -- the local node hears neighbour 4153,
but 4153 doesn't hear the local node. If you manage to
> Under which conditions are rtt and rttcost included?
When we've received a valid timestamp from the neighbour within the last
three minutes (see valid_rtt in neighbour.c).
A zero rtt is strange; could you please send us your configuration?
-- Juliusz
> node2 & node 3 are deliver their routes to node1 and i can see them in the
> routing table or in babelweb (attached screenshot) 10.19.88.0/21 but the route
> that node2 announced is not distributed to node 3.
Plase add
split-horizon false
to the configuration files.
-- Juliusz
> In your case, the problem comes from the split-horizon optimisation: you
> should disable it, because it only makes sense for transitive media.
Right. Add the following to babeld.conf:
split-horizon false
-- Juliusz
___
Babel-users mailing list
>> - extend the IHU timestamp sub-TLV to allow an optional timestamp,
>> perhaps only used when sent over unicast;
> I just checked [1], we should be able to do that without breaking
> interoperability. Nice.
That's by design. Draft-jonglez-babel-rtt-extension (of which you are the
first
>> Based on the patch juliusz supplied me to enable unicast IHU, and
>>
>> default enable-timestamp true
>>
>> this stops sending timestamps (which apparently relies on hellos and
>> IHUs being bundled together)
> Can you provide the patch in question?
I cannot find the original patch, but it
> Well, the rabel repo exists for the crazy ideas... and unfortunately
> testing them at scale tends towards being a PITA.
Exactly my point. Ideas are cheap.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
> If that is the only error in two highly speculative documents then I'm
> winning. :)
You'll be helpful (I prefer this to "winning") when you implement some of
your ideas and provide us with hard data to show that they are useful.
(For the record, CS6 and unicast IHU have both been implemented,
> I think it supports globbing on interfaces (?), which strikes me as
> a useful feature in babeld when interfaces come and go as they do
> nowadays with horrific names like enx2a1c0359e29b as generated by
> systemd. Some way to automagically recognize when an interface (e.g. vpn
> or usb network)
> so if I understand correctly, when A sends an Update to B, B needs to know
> address of A and, according to the proper circumstances, B gets address of A
> either from IPv6 packet's source address (case 1) or from The Next-hop TLV
> sent on purpose by A (case 2).
Correct.
> x y z
Dear all,
Babeld-1.8.0 is available from
https://www.irif.fr/~jch//software/files/babeld-1.8.0.tar.gz
https://www.irif.fr/~jch//software/files/babeld-1.8.0.tar.gz.asc
For more information about babeld and the Babel routing protocol, please
see
Hi Christof,
> * I am aware that babel 1.8 is not stable yet.
It's stable -- I just need to take the time to do a release.
> As Babel 1.8 will be incompatible to 1.7
Babeld 1.8 will be fully compatible with 1.7. It's babeld 1.9 which will
change the source-specific routing extension, and that
Hi Denis,
The Babel neighbour sensing mechanism is exactly as you describe: if
a given IP address hasn't sent you a Hello, it doesn't exist, and all
packets from it are silently dropped until it sends a Hello. This is by
design.
You are correct that an IHU does not carry explicit information
> Hello, I want to ask how babel read the message that send by other node to
> themself ?
Function parse_packet in file message.c.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
>>> is that in a branch somewhere yet?
>> No, sorry.
> Got an ETA?
Dave, it's September. Do you imagine what September looks like at university?
> I'm in the process of rebuilding the yurtlab,
Lucky man. I am in the process of grading undergrad internships.
-- Juliusz
> like it to do is have a dedicated ipv6 ULA ip address for management
> purposes (not using a vlan here), and announce that to the network, but
> never offer itself as a routing opportunity to anything
[...]
> out br-lan something deny?
> in?
> inflate the metric?
out br-lan ula/128 allow
out
> is that in a branch somewhere yet?
No, sorry.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>> I guess I'll define a new type "conservative" which corresponds to what is
>> done if the interface is not detected as wireless. Or do you have better
>> ideas?
> Call it "type default" so that there is no preconception, and explain what
> it does in the man page?
Point taken, but I don't
>> Split-horizon is *disabled* on interfaces of type "auto", so if you want
>> split-horizon, you should manually set the interface type.
> I'm not sure I get the meaning of "auto", then. Does it mean babeld will
> auto-detect the interface type (whenever possible, using e.g. netlink to
> look
I've just pushed some changes that could, in some edge cases, break your
configuration files. Since I'd like to release 1.8 before the end of the
summer, I'll be grateful if you could test.
First of all, the keyword "wired" is now deprecated (undocumented but
supported for backwards
Dear all,
IETF is over, we've had the first meeting of the Babel WG. It went
pleasantly smoothly. You'll find the full recording of the meeting[1],
the minutes, as well as all the meeting materials, including slides[2].
[1]
> What time zone is that?
CEST, also known as UTC+2.
Unless I got something wrong, that's
16:20 CEST (Berlin, Paris, Warsaw)
14:20 UTC
15:20 BST (London)
10:20 EDT (New York, NY)
7:20 PDT (Vacaville, CA)
11:20 ART (Buenos Aires)
___
Dear all,
Just to remind you that the Babel IETF working group is meeting today
for the first time from 16:20 to 18:20 in room Potsdam II.
Remote participation is possible, and appreciated:
https://www.ietf.org/meeting/96/remote-participation.html
If you've got a decent connection, I
Dear all,
This is to remind you that IETF 96 is next week in Berlin. There will be
two sessions that should be of interest to members of these lists:
Homenet, on Monday 18 July at 14:00 in room "Potsdam I";
Babel, on Thursday 21 July at 16:20 in room "Potsdam II".
Other sessions might be
>> atomic updates in babel,
> Patches gladly accepted. Or I'll do it at some point, but don't hold your
> breath
Anyone working on that? Or are you all holding your breath?
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
> Which is one more argument in favour of disabling split horizon by default
> in the next version.
Opinions on that? Does anyone feel that doubling the amount of Babel
traffic on wired links (no change on wireless links) is prohibitive?
-- Juliusz
> For the record, after a chat on IRC Jech helped me out and told me to
> disable split-horizon processing on the interface (as the routes were
> all coming in on the same interface). Works great now.
Which is one more argument in favour of disabling split horizon by
> I'd suggest to look into the Familiy of Olinuxino boards produced by
> Olimex: https://www.olimex.com/Products/OLinuXino/open-source-hardware
> or one of their system-on-module boards.
Ah, right. I recall looking into them, but found their website confusing
(too many models, difficult to find
>> repeatedly failing and restoring an interface (ifconfig down/up),
This is a known issue, Dave. The code that checks for interface down/up
events is racy, it can get confused if you do up/down/up and it doesn't
trigger before the interface gets back up -- it thinks that nothing
changes.
The
--- Begin Message ---
Dear Donald Eastlake,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
babel Session 1 (2:00:00)
Thursday, Afternoon Session II 1620-1820
Room Name: Potsdam II size: 175
> the long slow EABI changeover that was obsoleted almost overnight by the
> armhf work the raspian folk did, and so on.
I am pretty positive that armhf predates raspbian. Let's please give
credit where credit is due.
-- Juliusz
___
Babel-users
1 - 100 of 606 matches
Mail list logo
