Hi Eric,
That sounds great.
Is there already something we can test/hack ?
Any idea on the timeline, especially for the (long awaited) uClibc upgrade ?
What about a 3-way diff tool during upgrade process ? We would then
have a really upgradable system.
Regards,
Cedric
2006/6/11, Eric Spakman <
Hello Paul,
> Hi Eric and friends,
>
>
> I stumbled across a couple of problems today while playing with hostapd.
>
>
> It looks like WPA2 (psk) is not working properly with my Atheros CM9
> card. I did a cursory visual inspection of the source and it looks like
> the problem might be fixed by co
Hello Cedric,
> Hi Eric,
>
> That sounds great.
> Is there already something we can test/hack ?
I have an image I can send you this evening (UTC) when I'm home. If there
is more demand, maybe it can be placed somewhere on the LEAF site.
> Any idea on the timeline, especially for the (long awaite
Hello Paul,
>
> The second problem is probably a madwifi driver bug or an inability of
> the CM9 card.
>
> I was trying to run WPA with CCMP (AES in CBC mode) as one of the
> available cyphers. (hostapd was configured to allow ccmp as well as tkip).
> My Mac was working fine, but my wife's PC was
> I have an image I can send you this evening (UTC) when I'm home. If there
> is more demand, maybe it can be placed somewhere on the LEAF site.
I'll be there ;)
> Not yet, it depends on everyones free time ;)) The move to a new config
> system and/or uClibc upgrade touches every package setup in
Op Ma, 12 juni, 2006 10:26 am schreef Cédric Schieli:
>> I have an image I can send you this evening (UTC) when I'm home. If
>> there is more demand, maybe it can be placed somewhere on the LEAF site.
>>
>
> I'll be there ;)
>
Ok :))
>
>> Not yet, it depends on everyones free time ;)) The move to
> > I meant a timeline (TODO list ?) for an upgraded uClibc toolchain.
> > Thus we can start rebuilding and testing ;)
> > As buildtool now permit using a local checkout, wouldn't be useful to
> > have a dedicated cvs branch for that work to be done ?
> >
> Not sure, now that we tag the sources it
On Sun, 2006-06-11 at 23:39 +0200, Eric Spakman wrote:
> Hello list,
>
> The Bering-uClibc crew is working on a new config/backup system. In this
> system config changes are no longer saved in the package itself but in a
> seperate "configdb" package. The same is true for modules, which are saved
Hello Nataneal,
>> It works as follows (somewhat simplified):
>> -At startup (pre-init) the sha1-sums of files listed in a
>> .local
>> file are calculated and saved in a .sha1 file. The files listed
>> in .local are user changable files like config files and f.e.
>> ssh-keys -At backup time the
Hello Cedric,
>> Not sure, now that we tag the sources it should be easier to checkout a
>> specific version. Making a seperate branch would introduce extra work
>> and take extra time we don't have..
>
> Yes, but what about 2.4.x bugfix releases while this long process of
> upgrading every packa
On Mon, 2006-06-12 at 11:39 +0200, Eric Spakman wrote:
> Hello Nataneal,
[ cutted a few lines ]
> > This leads us to: create checksums (or save "status") of everything
> > in /etc during package installation (during boot in other words). This is
> > the "default", or "pristine" database. Do your
On Mon, 2006-06-12 at 09:24 +0200, Eric Spakman wrote:
> Hello Cedric,
> >
> > What about a 3-way diff tool during upgrade process ? We would then
> > have a really upgradable system.
> >
> That would be nice, but could be implemented afterwards. The question is
> if it's really needed. If the cha
On Mon, 2006-06-12 at 10:26 +0200, Cédric Schieli wrote:
> As pointed out somewhere in this list, documentation is often
> contained in config files. Merging when there are no incompatible
> changes gives you an opportunity to get new "doclets". If changes are
> incompatible, let's spawn a shell f
On Mon, 2006-06-12 at 11:19 +0200, Cédric Schieli wrote:
> > [...] The current system is really very simple and
> > doesn't use extra tools like diff and patch. Besides config files (text
> > files) compress very good so the result will probably be a lot smaller
> > than introducing new requiremen
Hello Nataneal,
>>
>
> [ cutted a few lines ]
>
>> Correct, although we took a slightly different direction. The reason we
>> use .local files is that when you boot the /etc directory grows with
>> every installed package (files are added), so the sha1sum is calculated
>> again and again for the s
Hello Natanael,
> Have you seen etc-update in gentoo or mergemaster in freebsd? Can be
> nice to have a look so you can get som inspiration ;)
Yes, I've tried gentoo and really liked the idea of etc-update
> diff -u foo.conf foo.conf.new
>
> and ask: would you like to:
> 1) keep the old config.
Hello Nataneal,
>> That would be nice, but could be implemented afterwards. The question
>> is if it's really needed. If the changes between package
>> versions/revisions are compatible, it's just a matter of replacing the
>> package. If the changes are incompatible, the question is if a 3-way
>>
On Mon, 2006-06-12 at 14:04 +0200, Eric Spakman wrote:
> Hello Nataneal,
hi hi
> >> Currently we create a .sha1 file for every package instead of
> >> one big sha1 file. I played with it a few days and this implementation
> >> seems to work most flexible, although I can't rememember all the reason
On Mon, 2006-06-12 at 14:12 +0200, Eric Spakman wrote:
> Hello Nataneal,
hi.
> > Now, run a utility that:
> >
> >
> > diff -u foo.conf foo.conf.new
> >
> > and ask: would you like to: 1) keep the old config.
> > 2) replace old with new.
> > 3) do nothing.
> >
> >
> > conf=foo.conf case $choice in
Hello Nataneal,
>> Cool, but user changes are lost if you choose the option to update the
>> config file. I was more thinking about something that updates the new
>> config file with changes from the old one, which is probably almost
>> impossible ;)
>
> Nothing is impossible. The "impossible" jus
Hi Nataneal,
>> Correct, although it's somewhat difficult to remove a package without a
>> .list file.
>>
>
> apk-tools create the package listing on the fly. Something like:
>
> tar -ztf package.apk > var/db/apk/package/CONTENTS tar -zxf package.apk
>
That can also be implemented in Bering-uClib
On Mon, 2006-06-12 at 15:37 +0200, Eric Spakman wrote:
> Hi Nataneal,
> > But the, what happens if you try to upgrade apk-tools? after apk_delete,
> > there are no apk_add to install the new package. I solved it by first
> > unpacking the new package, then compare the lists and remove all files
>
Hi Nataneal,
>>
>
>>> But the, what happens if you try to upgrade apk-tools? after
>>> apk_delete, there are no apk_add to install the new package. I solved
>>> it by first unpacking the new package, then compare the lists and
>>> remove all files that are in old list but not in new list. (reverse
On Mon, 2006-06-12 at 20:52 +0200, Eric Spakman wrote:
> Hi Nataneal,
> >>
> >
>
> >> In most cases (HD/Flash/Floppy) the first device is the backup device,
> >> having a seperate variable would only introduce redundancy. But I was
> >> thinking about adding a menu entry where an user can select t
Hi Nataneal,
>>> I'd suggest to add a CFGDEV and default it to:
>>>
>>>
>>> CFGDEV=$PKGPATH
>>>
>>>
>>> Then can the user choose himself.
>>>
>>>
>> Good suggestion didn't thought about that, but PKGPATH can be a list
>> and the first entry can still be a CDROM.
>
> then you could default CFGDEV t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Spakman wrote:
>>> I'm not sure if it's obvious if
>>> backup fails that the above entry can be the fault, if a note is added
>>> in the leaf.cfg file that the first entry is the backup device in the
>>> PKGPATH
>>> it could be clearer. But I'm s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Natanael Copa wrote:
> On Mon, 2006-06-12 at 20:52 +0200, Eric Spakman wrote:
>> Hi Nataneal,
In most cases (HD/Flash/Floppy) the first device is the backup device,
having a seperate variable would only introduce redundancy. But I was
th
27 matches
Mail list logo
