//dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman
Index: package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
===
--- package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
(revision 45369)
+++ package/ke
//dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman
Index: package/network/services/hostapd/files/netifd.sh
===
--- package/network/services/hostapd/files/netifd.sh(revision 45369)
+++ package/network/services/hostapd/fi
ot sure if my solution is optimal, but it seems to work. WPS button is
maybe not that often used functionality, but it might be fixed in any case.
Routers with multiple radios are common now, so the bug is maybe more
prominent than earlier.
The modified script has been in a slightly different forma
Somebody should reboot the buildbot master as it reports all builds as failed
at the "broken packages" step.
http://buildbot.openwrt.org:8010/one_line_per_build
The actual builds themselves are ok/failed, but even the ok builds get
declared broken at this step.
There is again the same python
I noticed that the sysupgrade script seems to fail to force a sysupgrade.
Trying to sysupgrade WNDR3700v2
from ar71xx r11464-cabaaf06fe
to ath79 r11469-db09335848
I tested with console sysupgrade, and that failed, too. Router reboots the
current firmware without flashing. The ssh console o
I noticed today problems with new master builds, both with ipq806x/R7800 and
ar71xx/WNDR3700:
* Some services do not start and their processes are not visible in the
process list. Examples: collectd and nlbwmon
* logread command always hangs. Both from SSH console and luci
Looking at the rece
Petr Štetiar kirjoitti 27.12.2019 klo 0.59:
Hannu Nyman [2019-12-26 22:37:31]:
Hi,
I noticed today problems with new master builds, both with ipq806x/R7800 and
ar71xx/WNDR3700:
* Some services do not start and their processes are not visible in the
process list. Examples: collectd and
g")
Reported-by: Hannu Nyman
Signed-off-by: Petr Štetiar
---
That seems to take care of the logread problem. Thanks.
But neither collectd not nlbwmon starts. They are still broken with the
current ubus.
Looking now at the (again working) system log reveals:
root@router2:~# logread | grep co
Petr Štetiar kirjoitti 27.12.2019 klo 16.04:
Petr Štetiar [2019-12-27 13:25:41]:
Hannu Nyman [2019-12-27 11:33:46]:
Hopefully you/somebody will revert the ubus changes in master until then.
can you confirm, that following fix[1] actually fixes the issues you're
seeing? Thanks.
Petr Štetiar kirjoitti 28.12.2019 klo 23.01:
Hannu Nyman [2019-12-28 12:53:27]:
Hi,
For me, at least collectd and nlbwmon do not start.
I've just pushed fix[1], thanks for the report.
1. https://git.openwrt.org/e3e939d8e624290d14471d913154f4febf3a160b
-- ynezz
Thanks. After
> The problem does not seem to be with the image - older builds upgrade to
the same image just fine, but the recent ones seem to fail.
>
> Example: taking the most recent rpi-4-squashfs-factory.img.gz from
2019-12-28 and trying to upgrade to rpi-4-squashfs-sysupgrade.img.gz from the
same date d
Petr Novák kirjoitti 29.12.2019 klo 13.49:
I am normally building my own images, but to make sure this is easy to
reproduce, I have recreated the problem with the most recent snapshot builds as
well.
Can you be explicit with "most recent"?
You mean r11829-e3e939d8e6 images that contain the l
Petr Štetiar kirjoitti 1.1.2020 klo 22.46:
Petr Novák [2020-01-01 21:11:30]:
But how come the workaround was to use an older libubox and ubus - was there
any new check which was not there before?
I don't have definitive answer, as I would need RPi-4 (or any other real
hardware with Cortex-A72
Petr Novák kirjoitti 2.1.2020 klo 19.40:
Q: are all the platforms where this problem has been observed multi-core (like
the RPi4 or mt7621) or has this ever been experienced on a single core system?
Was the Qemu test Petr S. has done been running a multi-core or single core
emulation?
My tr
I have noticed that Christian has had the libtool 2.4.2 version bump in his
staging repo since March 2019. I assume that it has caused no trouble for him
so far, so I just wonder if it should be pushed to the main repo at some point?
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=com
Michal Cieslakiewicz wrote on Sun Jan 19 03:08:16 PST 2020:
> This patchset changes device string to 'wndr3700-v2' (adds dash before
variant) making it compatible with naming convention for ath79 target. Then
board, under its new name, is added to uboot-envtools.
What is the motivation for t
Hauke Mehrtens kirjoitti 19.1.2020 klo 19.17:
On 1/16/20 11:05 AM, Petr Štetiar wrote:
BTW it's still master + 2 stable releases which will receive the support? Once
the 20.y is out, the 18.06 is EOL?
I think this is not really clarified yet. I assume that 15.05 and 17.01
are now officially fu
Sven Roederer kirjoitti 30.4.2021 klo 1.44:
Am Donnerstag, 29. April 2021, 01:54:34 CEST schrieb Sven Roederer:
Using a freshly installed OpenWrt 21.02 fails to install a package that has
been downloaded manually. I had seen this initially when using my own image
where a package was missing. To
Sven Roederer kirjoitti 30.4.2021 klo 22.43:
...
Digging further I found installing online pulled librt in. Restarting from
scratch ...
Downloading librt and wall via wget and running `opkg *.ipk` - packages have
been installed successfully.
So the issue is obviously caused by resolving the depe
Sven Roederer kirjoitti 1.5.2021 klo 21.52:
Am Samstag, 1. Mai 2021, 15:14:35 CEST schrieb Hannu Nyman:
Sven Roederer kirjoitti 30.4.2021 klo 22.43:
...
Digging further I found installing online pulled librt in. Restarting from
scratch ...
Downloading librt and wall via wget and running `opkg
I think that it might be wise to mark ubus as target-specific "nonshared"
(PKG_FLAGS:=nonshared)
Based on forum discussion, we have currently a broken 21.02.0-rc2
imagebuilder, as libiwinfo can't find the correct libubus version.
https://forum.openwrt.org/t/21-02-0-rc2-build-error-on-libubus2
Paul Spooren kirjoitti 5.6.2021 klo 22.49:
Sounds good to me. Do you mind investigate what other packages are affected
I went through the ~60 instances of "nonshared" packages in the main OpenWrt
repo, and found that toggling six packages to nonshared would solve the
common problems:
libub
Hannu Nyman kirjoitti 6.6.2021 klo 10.56:
Paul Spooren kirjoitti 5.6.2021 klo 22.49:
Sounds good to me. Do you mind investigate what other packages are affected
I went through the ~60 instances of "nonshared" packages in the main
OpenWrt repo, and found that toggling six p
Looks like the packages buildbot is somehow stuck. No new builds has
been uploaded since Tuesday 22nd.
https://downloads.openwrt.org/snapshots/packages/
Buildbot status shows only janitor activity for the last four days.
https://buildbot.openwrt.org/master/packages/#/waterfall
_
-resourced compared to the
half-dormant 19.07 branch. I would think that the current RC release
should already have the priority for build resources.
On 2021-06-26 13:59, Hauke Mehrtens wrote:
On 6/26/21 10:15 AM, Hannu Nyman wrote:
Looks like the packages buildbot is somehow stuck. No new builds
Petr Štetiar kirjoitti 2.7.2021 klo 16.11:
Hannu Nyman [2021-06-05 13:40:21]:
Hi,
Based on forum discussion, we have currently a broken 21.02.0-rc2
imagebuilder, as libiwinfo can't find the correct libubus version.
seems like there is broken 21.02.0-rc3 imagebuilder as well:
op
Add the next bunch of new config symbols found after
eaa9c94c7 exposed their existence.
Signed-off-by: Hannu Nyman
---
Buildbot is currently broken on those targets due to the missing
symbols.
(I didn't yet touch CONFIG_USB_XHCI_TEGRA as I am not sure if
it should be added enabled for
Hauke Mehrtens wrote at Sun Aug 29 02:53:47 PDT 2021:
> Should we just release with this as a known problem?
>
> Other than this problem I am not aware of any other critical problem.
We should.
It is annoying that 21.02 was branched more than 6 months ago, but no final
release has happened by
Hauke Mehrtens wrote on Sat Sep 4 16:16:04 PDT 2021:
> Hi,
>
> The OpenWrt community is proud to announce the first stable release of the
OpenWrt 21.02 stable version series.
> ...
Who could edit the download server's front page?
https://downloads.openwrt.org/ still calls 21.02 as "Upcoming",
Adrian Schmutzler wrote at Tue Aug 24 05:50:42 PDT 2021:
( https://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036159.html )
> I just created an overview of current 5.4->5.10 conversion state. Sharing
it FYI below.
>
> Note that targets which are not converted or that nobody cares for
e9hack kirjoitti 26.9.2021 klo 10.02:
Am 24.09.2021 um 22:04 schrieb e9hack:
In the past (a few days ago), it was possible to disable or shut-down wifi
by introduce the command 'wifi down'. This doesn't work currently. After
some seconds, wifi is start again.
It may be related to a page fault
e9hack kirjoitti 26.9.2021 klo 15.48:
Am 26.09.2021 um 12:54 schrieb Hannu Nyman:
e9hack kirjoitti 26.9.2021 klo 10.02:
Am 24.09.2021 um 22:04 schrieb e9hack:
In the past (a few days ago), it was possible to disable or shut-down
wifi by introduce the command 'wifi down'. This do
e9hack kirjoitti 27.9.2021 klo 16.39:
Am 27.09.2021 um 14:01 schrieb Felix Fietkau:
Normally it should be active by default. Is CONFIG_KERNEL_ELF_CORE set
in your .config?
It was not activated, but the output from gdb looks not so helpful:
hb@vbox-linux6:~/src/openwrt/LEDE/archer-C7-ath79-5.1
Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to know, which line of code in netifd it crashes on, so I
can fix it. So far the bug has not shown
Felix Fietkau kirjoitti 27.9.2021 klo 19.17:
On 2021-09-27 17:45, Hannu Nyman wrote:
Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to
Heads up:
Forum has several reports that downloads.openwrt.org now fails in 21.02.0 and
master due to invalid certificate.
Possibly related to the letsencrypt's old root certificate expiring today
Or wolfssl not liking the remaining root cert?
https://letsencrypt.org/docs/dst-root-ca-x
I updated my buildhost to Ubuntu 21.10 and noticed that while it compiles
master ok, the OpenWrt 21.02 build fails already at the tools build stage.
m4 is the failing tool. Error log below.
I noticed that Rosen has recently updated m4 in master to 1.4.19, so I tested
cherry-picking the 1.4.1
Based on forum discussion, I tested 802.11r with my routers and noticed that
the current OpenWrt defaults (reassociation deadline 1000 ms and "FT over
DS") do not really work. I was unable to get my Android devices to realiably
roam with those values.
Switching to FT over Air and lengthening t
Koen Vandeputte wrote at Tue Jan 11 02:03:33 PST 2022:
> I noticed that custom thread names don't seem to work anymore these days.
> Htop got bumped recently but the issue still isn't fixed.
>
> This feature was very useful to check which thread consumes a lot of cpu
> during debugging applicatio
On 2/20/22 23:57, Hauke Mehrtens wrote:
> We would like to branch off OpenWrt 22.03 as openwrt-21.03 tomorrow.
> We would also like to create branches on the default feeds too.
>
> Petr will set up the new build bot instance together with Paul and we
would like to do an 22.03.0-rc1 soon when the
On 2022-04-04 11:58, claudiu.bez...@microchip.com wrote:
On 04.04.2022 11:11, Claudiu Beznea - M18063 wrote:
On 03.04.2022 10:23, Hannu Nyman wrote:
All targets are steadily green (with
the exception of at91/sama7 and its packages arm_cortex-a7_vfpv4 ).
I'll have a look on this.
Paul Spooren kirjoitti 6.11.2022 klo 18.15:
While I initially thought that $(AUTORELEASE) would be a nice feature to avoid
the standard review comment “Please bump the PKG_RELEASE”, it turned into a
massive increase of bandwidth usage: Every checkout of openwrt.git and package
feeds needs to b
Apparently the mpc85xx CPU type was changed from 8540 to 8548 on 29 Dec 2022,
causing the package architecture to be powerpc_8548 instead of powerpc_8540,
but noboby informed the packages buildbot, so it is still trying to churn
powerpc_8540 and naturally fails :-(
PR: https://github.com/ope
Michal Cieslakiewicz kirjoitti 3.2.2020 klo 20.54:
Remove read-only flag from U-boot environment partition for Netgear
WNDR3700 v1 and v2 so u-boot-envtools can modify data there.
Any reason, why you have left out the third router in the series, WNDR3800?
It is identical to WNDR3700v2 except
Paul Spooren wrote at Sat Feb 29 03:55:54 PST 2020
>
> for the last few days I get the following error for multiple targets,
> would it be possible to rerun the snapshot servers to rebuild the
> package `iw`?
>
> $ make manifest PROFILE="devolo_dvl1750e"
>
> [...]
>
> Collected errors:
> * satisf
I tested the kernel 5.4 support with ipq806x/R7800 and noticed that at least
two kernel packages get broken with 5.4:
* exfat-nofuse: exFAT is included in Linux 5.4 as a driver in the staging
section. The header definitions in exfat-nofuse conflict with the ones
already in Linux 5.4 be defaul
There is something strange going on in the buildbot. It doesn't seem to like
the current codebase.
Lots of core packages fail currently e.g. for mips_24kc (=ath79). The core
packages is so intertwined that I can't even figure out which is the actual
culprit.
https://downloads.openwrt.org/sna
Rosen Penev wrote at Sat Mar 21 20:36:15 PDT 2020:
> Remove GLOB_ONLYDIR patch. Does not seem to be needed.
> ...
> The GLOB_ONLYDIR macro is only needed for fstools, which should be fixed
there.
Which of those conflicting statements is true?
"GLOB_ONLYDIR does not seem to be needed" or
"Th
Kevin Darbyshire-Bryant kirjoitti 1.4.2020 klo 13.14:
In preparation for dropping the out of tree cake module and using
in tree cake from upstream, rename the package to kmod-sched-cake-oot
(out of tree)
Initially add a PROVIDES kmod-sched-cake so that package dependencies
can be satisfied.
Ult
Kevin Darbyshire-Bryant kirjoitti 1.4.2020 klo 13.14:
Cake has been in upstream linux from 4.19 onward yet openwrt still
builds a module from out of tree source. This patch set intends to drop
the out of tree module for those versions of linux that contain an
in-tree version + various backports
Kevin Mahoney wrote at Wed Apr 1 20:15:21 PDT 2020:
> I'm working with an IPQ8065 based board with dual QCA9984s. I have it up
and running but the wireless interfaces mac address is garbage.
> "00:03:7f:12:34:56" to be exact. I haven't been able to find the magic
that reads and sets the proper
David Bauer write at Thu Apr 2 12:53:59 PDT 2020:
> -KERNEL_PATCHVER:=4.19
> +KERNEL_PATCHVER:=5.4
> KERNEL_TESTING_PATCHVER:=5.4
Please remove the KERNEL_TESTING_PATCHVER line at the same time.
It has no purpose after the same version has been adopted as the default kernel.
___
I do not think that there is a nice clean solution, as I do not remember
seeing a solution of different packages for iniramfs, factory and sysupgrade
images.
I would approach that with a two-step build process, using two .config recipes:
* First a build with a smaller .config recipe without th
Eneas U de Queiroz wrote at Thu Apr 9 17:39:17 PDT 2020:
> This was reported to me here:
>
https://github.com/openwrt/openwrt/commit/dcf3e63a35d05e7e5103819c0f17195bfafe9baa#commitcomment-38390450
> The update to kconfig-v5.6 broke TARGET_MULTI_PROFILE because it would not
accept bool TARGET_DEV
Petr Štetiar kirjoitti 11.4.2020 klo 12.43:
Hannu Nyman [2020-04-11 09:00:11]:
Hi,
Applying the patch propsed here helped to fix my ath79 multi-device build.
So can this be interpreted as your `Tested-by:` ? Thanks.
-- ynezz
Yes, it can.
Hannu
Looks like the recent kconfig changes broke the whole packages buildbot.
(For some weird reason, the arc targets succeed, but all others fail
miserably... )
http://buildbot.openwrt.org/master/packages/grid
http://buildbot.openwrt.org/master/packages/one_line_per_build
Some of errors in th
Hannu Nyman kirjoitti 11.4.2020 klo 17.07:
But most errors seem to be related to recursive errors inside the rather
complex mac80211 wifi driver collection. I have a hunch that for buildbot
the "treat recursive dependencies as warnings instead of errors" option
(from 3204430e3 )
Philip Prindeville wrote at Mon Apr 20 19:36:14 PDT 2020:
> Collected errors:
> * check_data_file_clashes: Package kmod-ipt-nat6 wants to install file
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/lib/modules/5.4.33/xt_MASQUERADE.ko
> But that file is already provided by package
W. Michael Petullo kirjoitti 23.4.2020 klo 19.50:
I have started to notice a gunzip warning when decompressing the
OpenWrt images I build. This is with master df27e949:
gunzip openwrt/bin/targets/x86/64/openwrt-x86-64-generic-ext4-
combined.img.gz -c >/dev/null
gzip: openwrt-aquinas-git/bin/tar
Apparently the openwrt-18.06 packages buildbot has been offline three weeks,
since 22 April 2020:
http://buildbot.openwrt.org/openwrt-18.06/packages/one_line_per_build
Is that intentional?
There has been some talk about 18.06.3
(http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023
Petr Štetiar kirjoitti 17.5.2020 klo 16.58:
Hannu Nyman [2020-05-16 11:46:55]:
Hi,
Apparently the openwrt-18.06 packages buildbot has been offline three weeks,
since 22 April 2020:
http://buildbot.openwrt.org/openwrt-18.06/packages/one_line_per_build
Is that intentional?
yep, because
Heads up, the usage of the new fakeroot package has failed in a major way in
buildbot, and the phase2 packages buildbot has failed to build any package
for 1-2 days.
That has caused ALL master snapshot downloadable packages to be removed from
the download server for most package archs. The dow
e9hack kirjoitti 19.10.2020 klo 18.28:
after commit 1f5f599d0ea434820e06fd540ecbc9c7f15399b4 (zoneinfo: Updated to the
latest release) time zone isn't set.
Before this commit:
root@openwrt:~# date +"%Z %z"
CEST +0200
After this commit:
root@openwrt:~# date +"%Z %z"
+
The localtime link i
Hannu Nyman kirjoitti 19.10.2020 klo 19.01:
Could it be that the zoneinfo format has changed so that musl is not
compatible any more?
I suspect this:
http://mm.icann.org/pipermail/tz-announce/2020-October/59.html
Changes to build procedure
The Makefile now defaults POSIXRULES
Hi,
it seems to me that the buildbot's worker amounts are not in balance with the
commit frequency and actual workload of the various branches.
The phase1 images buildbot has only 3 active workers for master (which has
regularly new commits), while the stable 22.03 has 8 workers.
The same i
I am repeating myself, but it looks strange that we have only 3 build workers
on packages for the active master branch, while the almost dormant 22.03 has
currently 10 active workers (and concurrent builds).
The packages build cycle in master is currently uncomfortably long.
Hannu
Hi,
it se
git.openwrt.org seems to give intermittently lots of timeouts, both with the
actual git access and with the web interface. Results are either 500 or 504.
perus@ub2304:/Openwrt/DL-WRX36/feeds/packages$ git pull
fatal: unable to access 'https://git.openwrt.org/feed/packages.git/': The
requested
Looks like the new buildbot code and new instances (also for 23.05) are not
yet quite stable...
Packages of some popular architectures like aarch64_cortex-a53 for mt7622 and
ipq807x have not been built for a week in master.
There has been many timeouts of "3600 seconds without output" in mast
#x27;IGNORE_ERRORS=n m y', b'BUILD_LOG=1', b'CONFIG_AUTOREMOVE=y',
b'CONFIG_SIGNED_PACKAGES='], attempting to kill
4028 process killed by signal 9
4029 program finished with exit code -1
4030 elapsedTime=49718.148698
No gettext completion before the final
Paul D kirjoitti 24.7.2023 klo 13.19:
For those executing this at the command line, how does one 'repeat'?
-v 1 -v 2, or -v1 -v2 or -v123 or -v 1,2,3?
I had to think for a bit since it wasn't immediately obvious.
Perhaps a hint string with "(repeatable eg -v 1 -v 2)"?
On 2023-07-22 14:40, L
e9hack kirjoitti 9.11.2023 klo 17.32:
I face a strange behaviour since commit
516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition
on bringing up wireless devices). After a reboot or a full restart of
hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only
Felix Fietkau kirjoitti 10.11.2023 klo 16.38:
On 10.11.23 15:21, e9hack wrote:
Too fast. I did reboot with the old version again. The patched version
does work.
Fix pushed, thanks for testing!
- Felix
Thanks,
I tested the current netifd with the fix, and it seems to work ok, again.
Pleas
Looks like the release branches might have a too strong priority in the
combined image buildbot, so that release branches get always built before the
development main/master.
Recently there has been a steady flow of mostly small/unessential
fixes/improvements for 22.03 and 23.05, so buildbot h
Source code is your friend...
My two cents are on the backport of the HAS_LUAJIT_ARCH dependency to snort3.
Main/master shows that symbol definition:
```
.config - OpenWrt Configuration
> Search (LUAJIT)
┌───
I keep wondering what is going on with Attitude Adjustment?
rc1 was published in November and it has been three months since then.
Based on developers' messages in August-October 2012, the goal was to publish
AA in 2012, and possibly also the next release already in 2012. Now we are at
the end
collectd-mod-uptime is already there, but there has been no Luci support for
it, so no graphs are shown.
Based on forum discussion (see
https://forum.openwrt.org/viewtopic.php?id=42478 ), I submit a patch to add
the support to luci-statistics.
Patch is for Luci trunk and the functionality ca
Buildslave "nico" seems to have DNS / connectivity trouble.
svn: Can't connect to host 'svn.openwrt.org': Connection timed out
It quickly fails the svn update and jumps into the next target platform. It
goes rapidly through all targets and marks them done :-(
This has now happened in three
Apparently the buildslave "nico" continues to have problems with DNS
or network connectivity. Buildboot admins already turned it off for a
day due to trouble in finding svn.openwrt.org, but apparently also
luci svn server is unreachable for "nico".
http://buildbot.openwrt.org:8010/builders/
laves/nico
http://buildbot.openwrt.org:8010/one_line_per_build
In 25.3.2013 15:37, Mirko Vogt wrote:
On 03/25/2013 08:28 AM, Hannu Nyman wrote:
Updating feed 'luci' from
'http://svn.luci.subsignal.org/luci/trunk/contrib/package' ...
svn: OPTIONS of
'http://svn.luci.subsignal.org/luc
"ubox" takes care of the block-mount actions since r36988:
https://dev.openwrt.org/changeset/36988
However, there is no documentation about the current fstab config
format. I have been unable to get fstab working. My USB disk not not
mount automatically, although I can manually mount it jus
blob;f=block.c;h=d456dd586ff741fdd556b6a11d7eec6a50e8cf2b;hb=ab78547f19ce30efc845ce1229b766eddb8efa16
Earlier it was possible to leave out uuid and just specify the device to be
monitored.
On 26.6.2013 13:47, John Crispin wrote:
On 26/06/13 12:46, Hannu Nyman wrote:
"ubox" takes care of the block-mount actions since
I tried to add a new bug ticket to the bug tracker, but apparently entering
new tickets has been disabled for us casual users without login access.
There is no link to "new ticket" in the main menu and the "Add a new ticket"
link from the "wiki" page ( https://dev.openwrt.org/wiki ) to
https:/
This is a suggestion for a patch to fix the broken ubox kmodloader/insmod
preventing certain nls codepage modules from being loaded. Most important one
is nls_iso8859-1.ko as it is used by most FAT based drives, and its absence
makes mounting most USB sticks impossible.
The bug was introduced
les. Luci needs to draw the
graph for each plugin instance, not for each data instance.
http://git.verplant.org/?p=collectd.git;a=commitdiff;h=cc3640ba512862cd5745446f1f1a997dd4344454
Signed-off-by: Hannu Nyman
___
openwrt-devel mailing list
openwrt
.
http://git.verplant.org/?p=collectd.git;a=commit;h=6ef3385ccec835c7efae1ff3d5895858003a6da7
Signed-off-by: Hannu Nyman
--- packages/utils/collectd/Makefile(revision 38418)
+++ packages/utils/collectd/Makefile(working copy)
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=collectd
plant.org/?p=collectd.git;a=commitdiff;h=cc3640ba512862cd5745446f1f1a997dd4344454
Signed-off-by: Hannu Nyman
---
luci/trunk/applications/luci-statistics/luasrc/statistics/rrdtool/definitions/conntrack.lua
(revision 9920)
+++
luci/trunk/applications/luci-statistics/luasrc/statistics/rrdtool/
Radvd has been updated to 1.8.5 a few months ago, while Openwrt still uses
1.8.3. http://www.litech.org/radvd/
This patch updates radvd to 1.8.5. No major changes required.
signed off by: hannu.ny...@iki.fi
perus@hnvb:/Openwrt/trunk/feeds/packages$ patch -p1 -i radvd185.patch
patching file ip
Radvd has been updated to 1.8.5 a few months ago, while Openwrt still uses
1.8.3. http://www.litech.org/radvd/
This patch updates radvd to 1.8.5. No major changes required.
signed off by: hannu.ny...@iki.fi
Looks like the mail program messed the long lines in the previous message so I
am rese
Radvd has been updated to 1.8.5 a few months ago, while Openwrt still uses
1.8.3. http://www.litech.org/radvd/
This patch updates radvd to 1.8.5. No major changes required.
signed off by: hannu.ny...@iki.fi
I send the patch again to make sure that Windows does not mess with LFs...
(not sure if
There has not been successful buildbot snapshots for a week for any platform.
The buildbot status screens are full of exceptions. Alternatively, some of
the builds have now been on the make for 37 hours, without the displayed
status progressing even into the kernel compilation status.
http://tk
New snapshots have started to appear on the server, so apparently the new
buildmaster is online.
What is new address of the buildbot system's status interface?
(The old address seems to be dead.)
Hannu
On 16.6.2012 15:20, Travis Kemen wrote:
The internet connection the master is currently on
Radvd has been updated to 1.9.1 in June. There are some changes related to
IPv6 functionality, but additionally the change concerns scrapping the
built-in daemonization code and starting to use libdaemon for that.
This patch updates radvd to 1.9.1 and adds the dependency for libdaemon.
signed
When collectd's modbus plugin was marked broken in May, there was some
discussion on list if collectd (used by Luci statistics) should be bumped up
from the currently used old 4.10 branch (4.10.7) to the 5.1 released in
April. See https://lists.openwrt.org/pipermail/openwrt-devel/2012-May/015524
On Wednesday, August 15, 2012 at 12:09:15 PM "John Crispin"
wrote:
> As you may have noticed we are getting prepared for the Attitude
Adjustment release.
Does that also mean that Backfire is going to be retired? With no formal
10.03.2 forthcoming?
Is the plan that AA will be the new "stable
Based on the update activity on trunk, it looks like the trunk is again open
for post-AA patches.
This patch updates the usb-modeswitch and usb-modeswitch-data packages to the
August 2012 version (from the January version.
Related ticket #12014: https://dev.openwrt.org/ticket/12014
Signed-o
Is there any status update regarding the Attitude Adjustment 12.09 (or
12.10?) release process?
It has already been about four weeks since the beta was published, so it
would be nice to hear any news about the schedule.
I have not seen any branching at the SVN, but after an announced freeze f
I have seen no status update regarding the buildbots since the rumored RAID
failure week ago. The snapshot directory is currently completely empty. Forum
and bug tracker get steady input from frustrated users who are unable to
install new packages as opkg points to snapshots.
There are no new
What is happening with the Attitude Adjustment release process?
The last news over three weeks ago, in late September, was that there is
going to be a beta2, soon.
https://lists.openwrt.org/pipermail/openwrt-devel/2012-September/016843.html
Rather soon after that message there was the (rumoure
Great that new trunk snapshots have finally started to get built ;-)
However, one of the buildbots "nico" has been failing all its builds
since at least early September when I first noticed the issue with
it. Looks like nico's faulty build system (?) has not been fixed in
the latest re-con
I just noticed that also the buildslave "carme" silently fails all its builds.
It successfully builds the firmwares, but has wrong SSH public keys, so that
it fails at the upload stage. The built firmwares never get to server :-(
Apparently the upload script does not produce error for a failing
201 - 300 of 380 matches
Mail list logo
