Guidance on creating man pages for procd utilities
Greetings, I would like to create man pages for uxc and some of the other utilities in the procd repository. Searching through some of the commits in the openwrt/packages repository shows that man pages are intensionally disabled from being built, but I still think they are helpful to have. Perhaps there could be -doc packages like in other distributions? Please advise, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] ApkWrt
This is incredible work Paul! If I were running Alpine, would I be able to install an OpenWrt repository in /etc/apk/repositories and install OpenWrt packages? Would I be able to copy my APKBUILDS over from Alpine's aports repository and easily port them over to OpenWrt? I look forward to reading the documentation. Regards, On February 12, 2022 1:16:05 PM UTC, Paul Spooren wrote: >Hi all, > >For the last year or so[1] I’ve been working on replacing the package manager >OPKG with APK (Alpine Package Keeper)[2]. Different from our OPKG fork is APK >an actively developed project. OPKG is replaced entirely, both on device as >well as the build system. > >Using some CI I started to build all available snapshot firmware images and >published them for others to test[3]. Some targets fail to build but I’m >working on it. Please feel free to give it a try and provide feedback! > >At this point only the base system is compiled without the community feeds, >the installation of remote packages already works (e.g. `apk add tc-full`). >Other commands like `apk audit` allow system integrity checks and more. > >The SDK already works to create `.apk` packages, the ImageBuilder requires a >bit more work. Overall APK still depends on OpenSSL and libfetch, after >getting the base up and running I’ll start to look into replacing those with >more lightweight alternatives like WolfSSL and uclient-fetch. > >Within the next month I hope to create documentation in collaboration with >Daniel to explain how APK, uvol and uxc can work together. Essentially it >allows to install containers on OpenWrt devices. Just a few days ago we ran >Alpine Linux within a container on a Belkin RT3200, simply installed from an >`alpine.apk` package, the same works for Debian containers. In future this >could allow to run arbitrary container setups on routers. > >This work required a bunch of help, so thanks to John, Timo, Ariadne and >Daniel! > >Best, >Paul > >[1]: https://github.com/openwrt/openwrt/pull/4294 >[2]: https://gitlab.alpinelinux.org/alpine/apk-tools >[3]: https://downloads.asu.aparcar.org/apkwrt/targets/ > > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt developer meeting at Battlemesh and COVID-19
Hello, I would love an invite as an outside contributor. Regards, On March 26, 2020 8:38:28 AM UTC, Paul Spooren wrote: >Hi team, > >I hope everyone is fine & healthy and can use the time in quarantine to > >finally review those important patches I sent! > >>> Based on recent events regarding COVID-19 the Battlemesh and the >OpenWrt >>> developer meeting will not take place in May this year. >> it's really nice and necessary to meet in person, but I would like to >(ab)use the current situation and find out, if it would be possible to >hold remote meetings as well. That way we could meet in person every >~12 months, possibly having remote meetings in between, thus achieving >the 6 months cadence we've talked about on the last IRL meeting. >> >> One or two weekend days would probably work for most of us (based on >the recent votes). >> >> I don't have any prior experience with such meetings, but I assume >it's going to be quite common format in the upcoming days, so we might >look around and steal the best parts from the other FOSS projects. > >My current classes are taught via meet.google.com and zoom.us, both >cases works fine with about 20 members per session. For other >"meetings" >I used meet.jit.si which works fine too, however not tried at a bigger >scale. > >Do you plan to invite non-core-developers (like me) again or only the >core clique? If I remember the meeting in Hamburg correct we also >wanted >to invite package maintainers to have a bigger crowed discussing about >OpenWrts future. > >Best, >Paul > > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from others... (resending)
Excellent idea! But perhaps we could use either CONFIG_CONSTRAINED, or CONFIG_DEVICE_THIN instead? Regards, On May 2, 2020 9:54:16 PM UTC, Philip Prindeville wrote: >Hi all, > >We sometimes get into debates about whether certain functionality >should be allowed and oftentimes the gating factor is “will this fit in >a skinny platform” (i.e. something highly constrained, like 32MB of >DRAM)? I suppose there’s a similar argument about what a “small >footprint” machine has in terms of Flash, as well. > >Some of us work with more current machines that are also more capable, >realizing that eventually machines with 32MB of DRAM and 128MB of Flash >will “age out” through failure and scarcity. > >By then we’ll have a new “normal” about what the minimum expectations >are, and the conversation will continue, but with different parameters. > >Understanding that the definition of a “skinny” machine isn’t today >what it was 5 years ago, and that it won’t be the same again in another >5 years, I’d like to proposal a CONFIG_ symbol that denotes that a >platform is in a class of constrained architectures. > >Or, conversely, that a platform doesn’t have to observe overly >restrictive constraints on “what will fit”. > >(The smallest router platform I own has 256MB of DRAM, an 2GB of Flash >for instance, and it’s a 12 years old PC Engines Alix 2D… most of the >“current” machines I have are AMD64 and have 64GB of DRAM and 32GB or >more of Flash… with 256GB being the median…) > >This would allow us to develop packaging that both fits into >constrained architectures, as well as targeting further along the >evolving curve of “more RAM, more disk” that newer and newer platforms >inevitably follow. > >For instance, I was on IRC yesterday with Jo-Philipp talking about >whether the xt_geoip database should be propagated across sysupgrades, >understanding that: > >(1) some people might use it in their firewall rules >(/etc/firewall.user) to block certain country codes as part of their >system coming up, and don’t want to be in the vulnerable position of >just having performed a sysupgrade and reboot, but now finding >themselves without the geo-location database and therefore not able to >block certain countries, ISPs, etc. that are known to harbor APT’s; > >(2) the database takes slightly over 7MB today, and that might be more >than one can reasonable propagate during a sysupgrade, and some people >might not want to risk a failed sysupgrade… understanding that they can >re-download and re-install the database without too much trouble (it >takes a couple of minutes to download and unpack, even on a modest >broadband connection); > >My proposal is the CONFIG_SKINNY parameter (and possibly others, if we >need to triage in multiple dimensions; see below). If this is set, >then conservative decisions need to be made in packaging about disk and >RAM consumption. If this isn’t set, packaging might assume there’s >“room to stretch one’s legs”. > >In the prior scenario, the assumption would be that backing up the >geo-location database is feasible on unconstrained platforms, and one >could add: > >ifneq ($(CONFIG_SKINNY),y) >define Package/iptgeoip/conffiles >/usr/share/xt_geoip/ >endef >endif > >to feeds/packages/net/xtables-addons/Makefile for example. > >Then we can move away from the argument about “should X be allowed” to >the more productive discussion “when is it acceptable to allow X” >instead? > >And hopefully, what’s “allowed” (or viable) will only increase over >time, giving us more and more options to tailor OpenWRT into the >optimal configuration for our needs. > >So, I put to you 4 questions: > >(1) should we include CONFIG_SKINNY? >(2) what is the minimum DRAM that a platform should have to not be >considered “skinny”? >(3) what is the minimum Flash (or other storage) that a platform should >have to not be considered “skinny”? >(4) should clock speed figure into this? or some “normalized” >accounting of clock speed, that takes super-scalar and deep pipelining >into consideration, such as MIPS, be considered? or should this be an >orthogonal parameter, such as CONFIG_SLOW? > >I’ll kick off with my own initial empirically derived answers, with: > >(1) yes, it can’t really do any harm… people who don’t want to deal >with it won’t, making everything effectively “skinny” which is the >status quo; >(2) 256MB is already fairly capable… we can use that as the initial >definition of “skinny” and tweak it as experience dictates is >reasonable; >(3) 512MB is also a fair amount of space for image plus extended >logging; >(4) above 1000 MIPS, I’d not consider an embedded platform to be >“slow”… a 500MHz processor executing 2 instructions per cycle, or >having 2 cores and 1 instruction per core per cycle, is fairly capable, >easily able to handle traffic shaping on a 100Mb/s link; > >What does everyone else think? > >Thanks, > >-Philip > > >___ >openwrt-devel mailing list >openwrt-devel@
Re: [OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from others... (resending)
I like that even better. OpenWrt has traditionally focused on embedded systems such as routers and the like. So these should be the default as you say. Then if I want to run OpenWrt on a larger machine, I can add the fat so to speak. On May 2, 2020 11:48:03 PM UTC, m...@adrianschmutzler.de wrote: >Hi, > >just a single thought on this: > >For me, this quickly raised the question: What's normal and what's >exceptional? > >Your proposal assumes that "huge" devices are normal (default), and >skinny devices are the exception which has to be "marked". > >Why not the other way around? For standard, just keep the basic stuff, >and then mark some targets/devices that have the capability to carry on >extra work/duties... > >While I intentionally raise this question for a _general_ discussion, >in practice "my proposal" actually would have some benefits: >- While your proposal would mark all tiny devices/targets, I would just >mark the "excessive" devices. So, with "my" solution there is no chance >a tiny device is overlooked and broken by some package adding a lot of >stuff to the upgrade. If on the other hand an "excessive" device is >overlooked, no damage would be done. >- Since this is about "extra features", and you seem to think about >different categories, it makes more sense and would be easier to >(specifically) mark the devices that would get those extra features, >instead of marking a whole lot of other devices not getting them. >- Your whole idea for me sounds like it's about "nice-to-have" stuff. >Since the OpenWrt default is to provide the necessary minimum, the >default config should also mirror this concept (again, thus marking the >"extra"). > >So, while I'm not sure whether I really like your idea in general, I'd >create something like > >CONFIG_HUGE_FLASH >CONFIG_EXTRA_MEMORY > >or whatever similar to mark the "big" devices if I had to. > >Best > >Adrian > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Philip Prindeville >> Sent: Samstag, 2. Mai 2020 23:54 >> To: OpenWrt Development List >> Subject: [OpenWrt-Devel] Proposal: Differentiating "skinny" platforms >from >> others... (resending) >> >> Hi all, >> >> We sometimes get into debates about whether certain functionality >should >> be allowed and oftentimes the gating factor is “will this fit in a >skinny >> platform” (i.e. something highly constrained, like 32MB of DRAM)? I >suppose >> there’s a similar argument about what a “small footprint” machine has >in >> terms of Flash, as well. >> >> Some of us work with more current machines that are also more >capable, >> realizing that eventually machines with 32MB of DRAM and 128MB of >Flash >> will “age out” through failure and scarcity. >> >> By then we’ll have a new “normal” about what the minimum expectations >> are, and the conversation will continue, but with different >parameters. >> >> Understanding that the definition of a “skinny” machine isn’t today >what it >> was 5 years ago, and that it won’t be the same again in another 5 >years, I’d >> like to proposal a CONFIG_ symbol that denotes that a platform is in >a class of >> constrained architectures. >> >> Or, conversely, that a platform doesn’t have to observe overly >restrictive >> constraints on “what will fit”. >> >> (The smallest router platform I own has 256MB of DRAM, an 2GB of >Flash for >> instance, and it’s a 12 years old PC Engines Alix 2D… most of the >“current” >> machines I have are AMD64 and have 64GB of DRAM and 32GB or more of >> Flash… with 256GB being the median…) >> >> This would allow us to develop packaging that both fits into >constrained >> architectures, as well as targeting further along the evolving curve >of “more >> RAM, more disk” that newer and newer platforms inevitably follow. >> >> For instance, I was on IRC yesterday with Jo-Philipp talking about >whether >> the xt_geoip database should be propagated across sysupgrades, >> understanding that: >> >> (1) some people might use it in their firewall rules >(/etc/firewall.user) to >> block certain country codes as part of their system coming up, and >don’t >> want to be in the vulnerable position of just having performed a >sysupgrade >> and reboot, but now finding themselves without the geo-location >database >> and therefore not able to block certain countries, ISPs, etc. that >are known to >> harbor APT’s; >> >> (2) the database takes slightly over 7MB today, and that might be >more than >> one can reasonable propagate during a sysupgrade, and some people >might >> not want to risk a failed sysupgrade… understanding that they can re- >> download and re-install the database without too much trouble (it >takes a >> couple of minutes to download and unpack, even on a modest broadband >> connection); >> >> My proposal is the CONFIG_SKINNY parameter (and possibly others, if >we >> need to triage in multiple dimensions; see below). If this is set, >then >> conservative decis
