[Cerowrt-devel] openwrt package overriding issues on iproute2

[Dave Taht]

...

or we build a subset of ceropackages nightly out of the openwrt build
system (and NOT fail the build if they fail - for example kmod-cake
does not presently build for linux 4.0 systems.

Travis, any thoughts on the below? I would like to be building a bunch
of new qdiscs (fq_pie, cake, a couple variants of fq_codel) in the
mainline build system, and it looks like the iproute2 problem was just
solved (ish). I am still kind of thinking we are still screwed without
creating a distinct new package name for it....

I have no desire to build all of ceropackages, just a couple needed
things. Originally I was thinking slamming it into the routing repo,
but maybe doing it in ceropackages or some other more limited repo
that could get built nightly on your cluster (as part of, but not fail
the build).

*my* goals here is for me to not have to build all of openwrt ever
again, personally, and get the new experimental code up and running,
faster, for more people, and platforms, than we could ever do living
outside the main build systems... and lastly, not mess anyone else up
while doing so.


On Tue, May 26, 2015 at 11:32 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Tue, May 26, 2015 at 11:01 AM, Kevin Darbyshire-Bryant
> <kevin at darbyshire-bryant.me.uk> wrote:
>> Hi Dave & Felix,
>>
>> Looks like someone else has noticed and fixed, I fell into this and other
>> package pointing difficulties a couple of days ago when trying to produce
>> some 'cake' install instructions for 'cake'.
>>
>> https://patchwork.ozlabs.org/patch/476504/
>>
>> A couple of other tidy ups too:
>>
>> https://patchwork.ozlabs.org/patch/476505/
>> https://patchwork.ozlabs.org/patch/476506/
>>
>> Applied all locally and things seem more sensible!
>
> groovy.
>
> the next piece of what I wanted here was something similar to the
> ubuntu ppa mechanism for opkg.
>
> We build iproute2 in the openwrt base repo, and iproute2 doing the
> advanced and experimental cake stuff in the routing repo.
>
> Builders (such as hopefully NOT me!) can select stuff using the -p
> option on the feeds to make stuff into the default
> firmware.
>
> but users down stream have to be able to take the same package from a
> different feed if they want to play with us.
>
> Theoretically the version numbers are the same or differ. It is not
> clear to me what happens in opkg.  I think my preferred solution is
> that opkg pulls from the first version of the package listed in
> /etc/opkg.conf, so that after flipping the order (from base to routing
> (well, "cero" in our present case)) in that file, we can then pull
> down the advanced stuff via opkg -f install tc, no muss, no fuss.
>
> but that might need to reinstall it's own version of the libs, and
> hopefully -f would do that?
>
> If we were version number based, then we would occilate between
> versions of openwrt packages when they
> bump their version number up and we don't (or vice versa).
>
> (I note that the iproute thing in ceropackages is lagging behind cake
> a bit right now)
>
> It sounds like you are in a position to fiddle with this?
>
>>
>> Kevin
>>
>>
>> On 02/05/15 09:49, Dave Taht wrote:
>>
>> I had figured I could override the default iproute2 with the one in
>> ceropackages with:
>>
>> ./scripts/feeds install -f -p cero iproute2
>>
>> But so far no luck. Tried removing and installing, no luck either. ?
>>
>> Aside from that I have kmod-sched-fq_pie and kmod-sched-cake building, at
>> least, and everything
>> else wrapped up for a test build of chaos calmer with all the new stuff.
>>
>> Will try harder in the morning, brute forcing if I have to.
>>
>>
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67