Hi KP
Am 27.05.2017 um 19:15 schrieb kp kirchdoerfer:
Hi all;
the recent discussions about ntpd failing on i686 SMP and patching it,
required to test the proposed patch with uClibc-ng 1.0.24.
Wouldn't it be easier and better to just wait for the uClibc team to fix
the mainstream code?
chee
Hi Bob
(copying this to leaf-devel)
Sorry, I was too fast, I did not look into the i386 code but the one in
x86_64
Am 03.05.2017 um 20:03 schrieb Robert K Coffman Jr. -Info From Data Corp.:
Eric,
IRC user ddrown confirmed the x64 patch I mentioned earlier seems to fix
the issue on i386 as w
Hi Bob
(copying this to leaf-devel)
Am 03.05.2017 um 20:03 schrieb Robert K Coffman Jr. -Info From Data Corp.:
Eric,
IRC user ddrown confirmed the x64 patch I mentioned earlier seems to fix
the issue on i386 as well. I'm not really sure what to do with that
information. Is it possible to pat
Hi Andrew
Am 29.01.2017 um 14:33 schrieb Andrew:
this is not an apkg issue. it's an buildpacket issue.
Alledgedly buildpacket has requirements that cannot always be met,
because apkg cannot or does not set UID/permissions. I see this as a
weakness of the packaging system.
cheers
ET
sm
Hi KP
Am 29.01.2017 um 00:45 schrieb kp kirchdoerfer:
Am Samstag, 28. Januar 2017, 10:04:59 schrieb Andrew:
On 28.01.2017 03:30, kp kirchdoerfer wrote:
Hi Andrew;
Am Freitag, 27. Januar 2017, 20:55:15 schrieb Andrew:
Hi.
I've fixed perf, it should be built now.
I'm testing...
Also I not
Hi KP
Am 15.01.2017 um 16:35 schrieb kp kirchdoerfer:
> Hi all;
>
> I've committed a 4.9.(3) kernel to master for review.
>
> While I believe we should wait for an official new LTS kernel (probably 4.10),
> upgrading the kernel to 4.9 made me aware of missing and failing packages
> (ipt-netflow, i
Hi Tom
Am 05.01.2017 um 19:29 schrieb Tom Eastep:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 01/03/2017 12:05 PM, Martin Hejl wrote:
>> Hi Erich
>>
>
> That having been said, I don't understand why Shorewall module loading
> should behave differently between 'shorewall reload
Am 05.01.2017 um 15:53 schrieb Boris:
> Hej Erich,
>
> Am 03.01.2017 um 19:12 schrieb Erich Titl:
>> Hi Boris
>>
...
>>
>> I for myself have decided a long time ago to use some offline tool to
>> handle my certificates. It is better anyway to keep this t
Hi KP
Am 03.01.2017 um 20:19 schrieb kp kirchdoerfer:
> Hi;
>
> Am Dienstag, 3. Januar 2017, 21:05:21 schrieb Martin Hejl:
>> Hi Erich
>>
>> Am 03.01.2017 um 19:59 schrieb Erich Titl:
>>> Am 03.01.2017 um 16:04 schrieb Martin Hejl:
>>>> Hi all,
Am 03.01.2017 um 20:19 schrieb kp kirchdoerfer:
> Hi;
>
> Am Dienstag, 3. Januar 2017, 21:05:21 schrieb Martin Hejl:
>> Hi Erich
>>
>> Am 03.01.2017 um 19:59 schrieb Erich Titl:
>>> Am 03.01.2017 um 16:04 schrieb Martin Hejl:
>>>> Hi all,
>&
Hi Martin
Am 03.01.2017 um 20:05 schrieb Martin Hejl:
> Hi Erich
>
> Am 03.01.2017 um 19:59 schrieb Erich Titl:
>> Am 03.01.2017 um 16:04 schrieb Martin Hejl:
>>> Hi all,
>>>
>>> the shorewall init script for 6.0.1 in /etc/init.d/shorewa
Am 03.01.2017 um 16:04 schrieb Martin Hejl:
> Hi all,
>
> the shorewall init script for 6.0.1 in /etc/init.d/shorewall currently
> reads (relevant part only):
>
> =
>
> start() {
> echo "Starting IPv4 shorewall rules..."
> wa
Hi Boris
Am 03.01.2017 um 11:49 schrieb Boris:
> Hej all,
>
>
> I was missing those scripts, too. And as far that I remember, they are
> even not in the easyrsa-package.
Please note that the easyrsa scripts themselves are kind of proof of
concept thingies and not intended for _real_ crucial cert
Hi KP
Am 03.12.2016 um 18:03 schrieb kp kirchdoerfer:
> Hi Erich;
>
> can you pls explain, what we do have expect with the post_upgrade branch and
> how to test it?
>
> If all goes well, which branch do you want it to merged with?
It just contains a modified upgrade which will try to execute a s
Hi Andrew
Am 02.10.2016 um 19:58 schrieb Andrew:
> On 02.10.2016 20:45, Erich Titl wrote
:...
>> We need to find out if this is an issue for the majority of our users.
>> most of the drivers will probably just work as they work in standad
>> distros.
> This is issue for
Hi
Am 02.10.2016 um 18:36 schrieb kp kirchdoerfer:
> Hi;
>
> Am Sonntag, 2. Oktober 2016, 19:29:37 schrieb Andrew:
>> Hi.
>>
>> Built-in drivers have much less parameters. For ex., interrupt
>> throttling, etc.
We need to find out if this is an issue for the majority of our users.
most of the dr
Hi KP
It looks like the packages are not available for 5.2.7, but latest
specifies 5.2.7
AP# upgrade -c
aborting: cannot find
https://sourceforge.net/p/leaf/packages/ci/5.2.7/tree/version
cheers
ET
--
Hi Andrew
Am 29.07.2016 um 11:02 schrieb Andrew:
28.07.2016 19:31ers, kp kirchdoerfer пишет:
Hi Andrew;
Am Donnerstag, 28. Juli 2016, 12:24:58 schrieb Andrew:
Hi.
I think that we should move root, config and maybe some other 'core'
packages to initrd - to make it possible to run on tiny syst
Hi Folks
More woes trying to compile master, perf just would not
cat:
/home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/perf/perf/util/intel-pt-decoder/.intel-pt-insn-decoder.o.d:
No such file or directory
make[5]: ***
[/home/mega/leaf/devel/bering-uclibc/source/i486-unknow
Hi Folks
I see that mini-httpd has been updated. I am surprised that it does not
compile now.
cp -aL savelog-mini_httpd
/home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/mini_httpd/etc/cron.daily/
cp: cannot stat 'savelog-mini_httpd': No such file or directory
:-(
cheers
Hi KP
Am 07.05.2016 um 18:38 schrieb kp kirchdoerfer:
Am Samstag, 7. Mai 2016, 17:59:55 schrieb Erich Titl:
Hi Folks
I tried to look into the init bug, just to run into one with the build
environment
mega@leafbuilder64:~/leaf/devel/bering-uclibc$ git branch
maint
* master
new-initrd
Hi Folks
I tried to look into the init bug, just to run into one with the build
environment
mega@leafbuilder64:~/leaf/devel/bering-uclibc$ git branch
maint
* master
new-initrd
new_upgrade
mega@leafbuilder64:~/leaf/devel/bering-uclibc$ git status
On branch master
Your branch is up-to-date
Hi KP
Am 14.04.2016 um 13:21 schrieb kp kirchdoerfer:
> Hi Erich;
>
...
>>> Another observation: it only happens with vfat formated sda1, formating
>>> with ext[234] doesn't show this error.
>>
>> This is completely weird, AFAIK the code does not make a difference
>> between file system types. It
Hi KP
Am 11.04.2016 um 15:39 schrieb kp kirchdoerfer:
> Am Samstag, 9. April 2016, 14:23:31 schrieb Erich Titl:
>>
>> Need to look into linuxrc, where this should be umounted. As I forgot
>> the charger for my other laptop, I have no access to the source code, sorry.
&g
Am 10.04.2016 18:37, schrieb Andrew:
>
...
>>
>> kp
> 128MB DOM and 256-512MB flash works OK.
>
> As I understood, trouble happens on flash that is formatted manually...
What difference does that make? Don't we pass the right parametres?
cheers
ET
-
Hi KP
Am 10.04.2016 14:55, schrieb kp kirchdoerfer:
> Hi Erich;
>
...
>>
Need to look into linuxrc, where this should be umounted. As I forgot
the charger for my other laptop, I have no access to the source code,
sorry.>
>>> Are you away for a few days, or will it have to wait until
Hi KP
Am 10.04.2016 13:28, schrieb kp kirchdoerfer:
> Hi;
>
...
>>
>> Need to look into linuxrc, where this should be umounted. As I forgot
>> the charger for my other laptop, I have no access to the source code, sorry.
>
> Are you away for a few days, or will it have to wait until end of summer?
Hi KP
Am 09.04.2016 10:44, schrieb kp kirchdoerfer:
> Hi;
>
> I've booted LEAF 6.0.0-alpha1 iso image in a vm with an attached (virtual) hd.
> If the disk is partitioned and formatted it will be mounted during boot, but
> never umounted.
>
> mount shows
> /dev/sda1 on /tmp/tmp.kci8fg type vfat etc
Hi KP
Am 03.04.2016 um 14:22 schrieb kp kirchdoerfer:
...>>
>> I've made my work on removing moddb traces available as remote repository
>> (remove_moddb) - pls review before it will be merged!
>> Maybe the leftover is solved as well.
>
> Anyone looked into the branch, if the changes making sense
Hi KP
Am 03.04.2016 um 14:06 schrieb kp kirchdoerfer:
> Hi Erich;
...
>> /etc/hosts
>
> I think this will not help in terms of user friendliness...
No it won't but it would at least be correct
>
>>
>> So everything can remain as is, but that does not make the LEAF software
>> any better.
Hi Sven
Am 02.04.2016 um 00:16 schrieb Sven Kirmess:
> That annoys me to. :-)
>
> The root package includes the whole content of the /root directory to the
> configdb.lrp file.
>
> # more /var/lib/lrpkg/root.local
> root
> var/lib/random-seed
>
>
> Would probably make sense to redirect this fi
Am 02.04.2016 um 12:00 schrieb Andrew:
> 02.04.2016 10:48, Erich Titl пишет:
...
>> You are right, but this is mostly due to the fact that the webconf
>> interface does not attract our developers. Maybe the fact that it is
>> written in shell keeps them away. Even big Cisco an
Hi Andrew
Am 02.04.2016 um 00:37 schrieb Andrew:
> 31.03.2016 23:30, Erich Titl пишет:
>> Hi KP
>>
>> some more bugging
>>
>>
>> Network configuration menu
>>
>> 1) interfaces file
>> 2
Hi KP
Am 02.04.2016 um 00:28 schrieb kp kirchdoerfer:
> Hi Erich;
>
...
>>
>> Mhhh.. I don't know, IMHO less is more
>
> It shows a lot more in my case; and while it might not useful for you, it
> came
> in quite handy from time to time, at least for me.
>
> Each of both a re two lines of co
Hi KP
just to reiterate the menu stuff
I tried for the first time menu item c)
On my slow and small router I lost patience before anything could be
displayed and went to start this mail
And then this
--- saved/root/.ash_history
+++ running/root/.ash_history
@@ -1143,3 +1143,657 @@
wpa
Hi KP
some more bugging
Network configuration menu
1) interfaces file
2) hosts IP adresses
3) hostname
4) resolv.conf
5) superserver daemon configuration
6) hosts.allow
7) hosts.deny
8) networks
q) quit
Am 31.03.2016 um 19:26 schrieb kp kirchdoerfer:
> Hi Erich;
>
> Am Donnerstag, 31. März 2016, 19:00:45 schrieb Erich Titl:
>> Hi KP
>>
>> Am 31.03.2016 um 17:31 schrieb kp kirchdoerfer:
>> ...>
>>
>>> The name "hwdetect" is mislead
Hi KP
Am 31.03.2016 um 17:31 schrieb kp kirchdoerfer:
...>
> The name "hwdetect" is misleading. The more interesting part of hwdetect now
> is loading modules from /etc/modules rather than loading hardware.
> This way I can add pppoe to /etc/modules, run hwdtect (of "f" from lrcfg
> menu)
> and
Am 31.03.2016 um 10:47 schrieb Andrew:
> It just blocks killing on console logout (IMHO it'll be bad if all
> remains mounted after logout)
sure
. It oesn't hurt TERM/KILL signals.
Tests have shown problems for some reason. normal background operation
works fine.
cheers
ET
-
Am 31.03.2016 um 10:30 schrieb Andrew:
> 31.03.2016 01:32, Erich Titl пишет:
>> Am 30.03.2016 um 17:20 schrieb Andrew:
>>> 30.03.2016 17:17, Erich Titl пишет:
...
> Command can push itself in background. Something like this:
>
> if [ "$1" == "--nofork
Am 30.03.2016 um 17:20 schrieb Andrew:
> 30.03.2016 17:17, Erich Titl пишет:
...
>>
>> There are a few drawbacks with the invocation
>>
>> - umount_delayed must be pushed to the background to terminate
> it may call itself with some parameter (that indicates that it&
Hi Folks
I am not convinced this is necessary but it does not hurt, so I added
another function to mount_modules to allow delayed umount
Tests show
SALT# mount_modules
SALT# umount_modules
SALT# mount_modules
SALT# umount_delayed &
SALT# mount_modules
SALT# umount_delayed &
[1]- Terminated
Am 27.03.2016 um 18:26 schrieb kp kirchdoerfer:
> Am Sonntag, 27. März 2016, 16:03:06 schrieb Erich Titl:
>> Hi KP
>>
>> Am 26.03.2016 um 16:55 schrieb kp kirchdoerfer:
>>> H Gents;
>>
>> ...
>>
>>> At last I changed hwdetect to neglect
Hi KP
Am 26.03.2016 um 16:55 schrieb kp kirchdoerfer:
H Gents;
...
At last I changed hwdetect to neglect moddb, and to do not use
/var/lib/lrpkg/*.depmod any longer - there is no need to copy modules to
/lib/modules any more.
IMHO we could also ditch hwdetect. There is hardly any differe
Hi Folks
After building kernels many times these few days I am a bit annoyed by
the missing dependencies in our buildtool, e.g. after modifying a
Bering-something.cdiff I cannot just build kernel and it will just build
the something (sub)arch by honoring all the dependencies. This makes
developmen
Hi Folks
I am trying to build the subarch wrap in i486-unknown-linux-uclibc.
Everything works fine except that the modules contain the 'sound'
modules which I explicitly disabled in the config.
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
# CONFIG_SOUND is
Hi Folks
I played a bit more with the model specific kernel configuration for
WRAP as this is my current testbed.
I have been able to cut 2 MB of memory from my installation by removing
modules from the WRAP config. The modules being the ones hardly ever
used on a WRAP platform like RAID, most th
Am 15.03.2016 um 20:41 schrieb Andrew:
> I'm not sure that it's really will be a big difference between all
> CS553x drivers enabled and CS5535-only driver...
By building a device specific subarch we can also save quite a bit in
storage, as modules.sqfs may be dramatically smaller.
cheers
ET
Hi Andrew
Am 15.03.2016 um 20:41 schrieb Andrew:
> I'm not sure that it's really will be a big difference between all
> CS553x drivers enabled and CS5535-only driver...
Right, it does not make much of a difference, maybe 30K.
-rw-rw-r-- 1 mega mega 2079760 Mar 15 15:24 linux-alix
-rw-rw-r-- 1 m
Am 15.03.2016 um 17:48 schrieb kp kirchdoerfer:
...
>>
>> That is fine. But then I _believe_ the geodes all use the same PATA
>> companion chips, so we might really restrict them there too. Seeing the
>> difference in size, it hardly matters. I just don't like to include dead
>> code.
>
> Ok, you
Hi KP
Am 15.03.2016 um 17:28 schrieb kp kirchdoerfer:
> Hi Erich;
>
...
>
> Just to be clear I don't argue against a seperate WRAP image, until it's
> proofed to be outdated by download stats.
> But I'm questioning seperate images for ALIX and Geode.
That is fine. But then I _believe_ the geod
Hi KP
Am 15.03.2016 um 16:17 schrieb kp kirchdoerfer:
...
> Hi Erich;
>
> what's the difference between the alix specific kernel and the geode kernel?
Tha ALIX kernel has just one single PATA adapter. All the other storage
drivers are absent.
>
> Will the difference justify a seperate image?
Am 15.03.2016 um 10:01 schrieb Erich Titl:
> Hi Folks
>
> the uboot compile breaks in new-initrd-6.x probably due to the compiler
> being gcc5
>
> /home/mega/leaf/devel/bering-6/source/armv6zk-unknown-linux-uclibcgnueabi/uboot/u-boot-2013.01.01/include/linux/compiler-gcc.h:87
Hi Folks
the uboot compile breaks in new-initrd-6.x probably due to the compiler
being gcc5
/home/mega/leaf/devel/bering-6/source/armv6zk-unknown-linux-uclibcgnueabi/uboot/u-boot-2013.01.01/include/linux/compiler-gcc.h:87:30:
fatal error: linux/compiler-gcc5.h: No such file or directory
compilati
Am 15.03.2016 um 00:15 schrieb Andrew:
> I'm not sure that it even requires intrusion... it seems like storage
> drivers are compiled as built-in
That would be great news.
>
> It'll require more testing on live hardware/emulator to ensure this.
cheers
ET
---
Am 14.03.2016 um 23:07 schrieb LEAF Linux Embedded Appliance Framework
Git repository:
>
> Branch: new-initrd-6.x
>
> linux: revert changes for versatile/bcmrpi configs
>
> it seems like configs are completely wrong, taretted to x86_64
Very possible as marked in the comment to those changes
Am 14.03.2016 um 19:12 schrieb Andrew:
> These files are for moddb/initmod. It seems like we should clean them
> after merge your changes.
Ah, OK. I will leave them as is for the moment until we have a stable
environment.
Thanks
ET
Am 14.03.2016 um 17:28 schrieb Andrew:
> Hi.
>
> modules-xxx.sqfs is built for each subarch specified in makefile.
What are the files applied to each subarch and how are they
defined/generated?
mega@leafbuilder:~/leaf/devel/bering-6/source/i486-unknown-linux-uclibc/kmodules$
ls
buildtool.cfg co
Hi Andrew
Am 14.03.2016 um 17:24 schrieb Andrew:
> It seems like you do something wrong. Because in master these modules
> are already compiled in kernel:
Mhhh... this is master
mega@leafbuilder:~/leaf/devel/bering-6/repo/linux$ git branch
* master
new-initrd-6.x
mega@leafbuilder:~/leaf/devel
Hi Folks
The code generating kmodules/modules-karch.sqfs is quite cryptic and I
don't really want to play a guessing game on how it works. What do I
have to do in kmodules to get modules-xxx.sqfs built? It appears the
documentation lacks a bit there.
Thanks
ET
--
Hi Andrew
Am 14.03.2016 um 16:30 schrieb Andrew:
> Strange. Maybe you didn't specify ARCH=i386 in command line on x86_64?
I started with the config for geode, which is running on ALIX. Now the
current config is aimed at loading CS5536 as a module, not compiled into
the kernel.
What is needed to
Am 14.03.2016 um 14:15 schrieb Erich Titl:
> Hi Folks
>
> I am trying to build a specific kernel for the ALIX board, but I am
> failing configuring the CS553x ATA driver into the kernel, e.g. the
> driver can be enabled as a module but menuconfig does not allow it to be
> compil
Hi Folks
I am trying to build a specific kernel for the ALIX board, but I am
failing configuring the CS553x ATA driver into the kernel, e.g. the
driver can be enabled as a module but menuconfig does not allow it to be
compiled into the kernel.
Am I missing some prerequisite here?
Thanks
ET
---
Am 14.03.2016 um 13:32 schrieb Andrew:
> 14.03.2016 12:28, Erich Titl пишет:
>> Hi Andre
>>
>> Am 12.03.2016 um 19:40 schrieb Andrew:
>>> Hi.
>> ...>>
>>>> Please let us know how you do a major kernel upgrade. If you write it
>>>&g
Hi Andre
Am 12.03.2016 um 19:40 schrieb Andrew:
> Hi.
...>>
>> Please let us know how you do a major kernel upgrade. If you write it
>> down, you might see that there are unnecessaty steps or you may
>> convince me that the diff files are valuable.
>>
> 1. Upgrade kernel version, copy configs,
Hi Andrew
Am 11.03.2016 um 18:19 schrieb Andrew:
11.03.2016 16:24, Erich Titl пишет:
Hi Andrew
Am 11.03.2016 um 12:50 schrieb Andrew:
11.03.2016 08:48, Erich Titl пишет:
Hi Andrew
Am 10.03.2016 um 21:19 schrieb Andrew:
10.03.2016 22:07, Erich Titl пишет:
Am 10.03.2016 um 19:39 schrieb
Hi Andrew
Am 11.03.2016 um 12:50 schrieb Andrew:
> 11.03.2016 08:48, Erich Titl пишет:
>> Hi Andrew
>>
>> Am 10.03.2016 um 21:19 schrieb Andrew:
>>> 10.03.2016 22:07, Erich Titl пишет:
>>>> Am 10.03.2016 um 19:39 schrieb Andrew:
>>>>> 10
Hi Andrew
Am 10.03.2016 um 21:19 schrieb Andrew:
> 10.03.2016 22:07, Erich Titl пишет:
>> Am 10.03.2016 um 19:39 schrieb Andrew:
>>> 10.03.2016 20:03, Erich Titl пишет:
...
>>>> But in the end you have to do it for every arch, not only common config.
>>>>
Am 10.03.2016 um 19:39 schrieb Andrew:
> 10.03.2016 20:03, Erich Titl пишет:
>> Hi Andrew
>>
>> Am 10.03.2016 um 18:53 schrieb Andrew:
>>> Hi.
>>>
>>> For common config case you can easily check what real differences are
>>> between conf
Hi Andrew
Am 10.03.2016 um 18:53 schrieb Andrew:
> Hi.
>
> For common config case you can easily check what real differences are
> between configs.
>
> + kernel upgrade is enough easy: just update common config (be make
> oldconfig) and try to generate other configs (looking on cdiff output -
Hi Folks
Some time ago I suggested to not keep complete kernel config files, but
base them on a common basic configuration and diff files, so common
settings would be kept in a single file only. This has been implemented
in the config.cdiff files. I was falsely convinced, that common config
settin
Hi Folks
I am observing the following when building for bcmrpi
echo bcmrpi
bcmrpi
xzcat patch-4.4.3.xz | patch -p1 -s -d
/home/mega/leaf/devel/bering-6/source/armv6zk-unknown-linux-uclibcgnueabi/linux/linux-4.1
1 out of 1 hunk FAILED -- saving rejects to file
Documentation/ABI/testing/sysfs-bus-u
Am 09.03.2016 um 19:09 schrieb kp kirchdoerfer:
> Am Mittwoch, 9. März 2016, 12:38:05 schrieb Erich Titl:
>> Hi Folks
>>
>> I have successfully installed new-initrd-6.x on my WRAP testbed. This
>> system does not have neither moddb nor initmod anymore.
>>
>>
Hi Andrew
Am 09.03.2016 um 12:52 schrieb Andrew:
> Hi.
>
> Can you also run 'free' to see RAM usage in both cases?
Sure, it might show different numbers due to uncompressed drivers in the
kernel.
SALT login: root
LEAF Bering-uClibc 6.0.0-alpha2 Rev 1 uClibc 1.0.12 at SALT
Linux 4.4.3-i486 #1 T
Hi Folks
I have successfully installed new-initrd-6.x on my WRAP testbed. This
system does not have neither moddb nor initmod anymore.
Here a few numbers to compare it to the current master branch. Master is
alpha1, new-initrd-6.x is alpha2 for comparison
>>
SALT# cat /etc/motd
LEAF Ber
Hi Folks
it looks like perf on master is broken or has a missing dependency
make
DESTDIR=/home/mega/leaf/devel/bering-6/build/i486-unknown-linux-uclibc/perf/usr
-C
/home/mega/leaf/devel/bering-6/source/i486-unknown-linux-uclibc/linux/linux/tools/perf
install)
make[1]: Entering directory
`
Hi Andrew
Am 07.03.2016 um 22:46 schrieb Andrew:
> Delayed unmounting is mostly for services that have delayed modules
> loading (like wpa-supplicant or hostapd) to ensure that all is ok.
If you really want to do this right, then you would need to insert
control logic that communicates with the
Hi Andrew
Am 07.03.2016 um 21:46 schrieb Andrew:
> 07.03.2016 20:41, kp kirchdoerfer пишет:
...
>>
>> Another drawback is the time it needs to load modules.sqfs.
>> If we choose to that for several packages it will raise startup times
>> significantly.
> Delayed umount can solve this. Just termina
Hi Andrew
Am 07.03.2016 um 21:46 schrieb Andrew:
> 07.03.2016 20:41, kp kirchdoerfer пишет:
>> Am Montag, 7. März 2016, 20:26:58 schrieb Andrew:
>>> Maybe we should just mount storage till hostapd will start?
>> Will hostapd really load the modules without changes to the init process?
> If it lo
Hi KP
Am 07.03.2016 um 18:42 schrieb kp kirchdoerfer:
> Am Montag, 7. März 2016, 11:13:47 schrieb Erich Titl:
...
>>
>
> Needs to be patch-4.4.3.xz in repo/linux/buildtool.cfg
> Fixed in git.
Looks like you did not check it :-(
There is more than a single patch necessary.
Hi KP
Am 07.03.2016 um 19:41 schrieb kp kirchdoerfer:
> Am Montag, 7. März 2016, 20:26:58 schrieb Andrew:
>> Maybe we should just mount storage till hostapd will start?
>
> Will hostapd really load the modules without changes to the init process?
I doubt it.
> The later is something I try to
Am 07.03.2016 um 19:26 schrieb Andrew:
> Maybe we should just mount storage till hostapd will start?
It is not hostapd, it's wpa supplicant and this is not new-initrd, so
the module copying is still done the old way.
>
> Also, maybe it'll be good to add delayed umount (for ex., 3-5 seconds)?
I
Hi Folks
OK after some twiddling with buildtool.cfg in master I succeeded to
build a 486 version.
There are a few quirks in shorewall and specifically we need to add the
following to /etc/modules in case we want to connect to WPA2 protected AP's
# appears to be needed for WPA/WPA2
ccm
ctr
Now m
Hi Folks
Is master supposed to compile completely? To me it looks broken.
mega@leafbuilder:~/leaf/devel/bering-6$ git branch
* master
new-initrd-6.x
mega@leafbuilder:~/leaf/devel/bering-6$ git pull
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (16/16), done.
remote: Tota
Am 06.03.2016 um 15:22 schrieb Andrew:
> 06.03.2016 15:48, Erich Titl пишет:
...
>> OK
> IMHO it's easier that maintain abstract 'common config' that isn't
> correspond to any target so can't be checked at all.
>>> P.S. it seems like you forgot to
Am 06.03.2016 um 11:05 schrieb Andrew:
> 4.4 config seems to be re-created from scratch; + currently we use i486
> as base config - so I moved all changes from i486 cdiff to base config.
That is quite a bit puzzling that the 486 config should be common to all.
OK
>
> P.S. it seems like you for
Hi Andrew
Am 05.03.2016 um 20:30 schrieb Andrew:
> I cleaned configs (there was a lot of strange things - as I understood,
> you just build storage drivers in kernel instead of modules, all other
> changes are unnecessary?).
There should not be any other changes in config, if they are I would
l
Hi Andrew
Am 05.03.2016 um 20:30 schrieb Andrew:
> I cleaned configs (there was a lot of strange things - as I understood,
> you just build storage drivers in kernel instead of modules, all other
> changes are unnecessary?).
The ones to config, yes, but there is more to it . I pushed a
new-init
Hi Andrew
Am 05.03.2016 um 11:54 schrieb Andrew:
> Hi.
>
> I'll try to look on it at this weekend.
I believe I made some progress
mega@leafbuilder:~/leaf/devel/bering-6$ git status
On branch new-initrd-6.x
Your branch and 'origin/new-initrd-6.x' have diverged,
and have 101 and 17 different comm
Am 05.03.2016 um 00:57 schrieb kp kirchdoerfer:
> Hi Erich;
> ...
>
> They are not forgotten, they are still used for armv6 toolchain.
> We need to update the raspberry kernel (armv6) to 4.4, until then both kernel
> versions configs are needed to keep the kernel for raspberry pi at 4.1, which
>
Hi Folks
I am trying to rebase new-initrd to master and failing miserably due to
weird (for me) conflicts. In order to make progress I would like to
suggest to clean up master in a way to be at least consistent with the
actual kernel release, e.g. the person responsable for the introduction
of 4.4
Am 10.02.2016 um 22:17 schrieb Erich Titl:
> Hi Folks
>
> It appears that sourceforge changed access policies today. Could someone
> comment please.
>
The problem appears to be that sourceforge is redirecting http requests
partially to https. Not all sourceforge hosts support htt
Hi Folks
It appears that sourceforge changed access policies today. Could someone
comment please.
SALT# wget -v
http://sourceforge.net/p/leaf/packages/ci/master/tree/stable?format=raw
--2016-02-10 21:14:32--
http://sourceforge.net/p/leaf/packages/ci/master/tree/stable?format=raw
Resolving sourcef
Hi KP
Am 08.02.2016 um 19:34 schrieb kp kirchdoerfer:
> Am Montag, 8. Februar 2016, 18:32:07 schrieb Erich Titl:
>> Hi KP
>>
>> Am 08.02.2016 um 18:26 schrieb kp kirchdoerfer:
>> ...
>>
>>> You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.dep
Am 08.02.2016 um 18:54 schrieb Andrew:
> Modules can be loaded by daemon (for ex. accel-ppp loads needed modules).
Right, so at daemon start the modules need to be accessible
ET
--
Site24x7 APM Insight: Get Deep Visibi
Hi KP
Am 08.02.2016 um 18:26 schrieb kp kirchdoerfer:
...
>
> You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides the
> necesssry modules and therefor requires no user intervention to load the
> necessary modules.
OK, so who is loading the modules, please. LINUXRC does no
Hi KP
Just to make it more clear
Am 07.02.2016 um 14:09 schrieb kp kirchdoerfer:
> Hi;
>
..
>
> I don't think we can't make this a valuable decision.
>
> Just adding more code and more options to load modules will increase
> maintenance work and will be confusing in the future.
>
> If we d
Hi KP
Am 07.02.2016 um 14:09 schrieb kp kirchdoerfer:
> Hi;
>
..
>
> I don't think we can't make this a valuable decision.
>
> Just adding more code and more options to load modules will increase
> maintenance work and will be confusing in the future.
>
> If we do not copy modules during bo
Hi Andrew
Am 03.02.2016 um 22:56 schrieb Andrew:
> 03.02.2016 22:47, Erich Titl пишет:
>> Hi Andrew
>>
>> Am 03.02.2016 um 19:03 schrieb Andrew:
>>> Hi.
>>>
>> ...>>
>>>> Erich made the proposal to change the init scripts of s
Hi Andrew
Am 03.02.2016 um 19:03 schrieb Andrew:
> Hi.
>
...>>
>> Erich made the proposal to change the init scripts of such packages to mount
>> modules.sqfs and load whatever required.
> Good solution.
>
> But IMHO we should leave possibility to use old behavior on systems.
What behaviour wou
1 - 100 of 1025 matches
Mail list logo
