@Harshad & @Michael, I did not mean to disappear from the conversation, sorry, I started working on some loosely related config stuff I had not planned on doing yet, leading up to testing your situation so I could craft a fix, and while doing so the internet connection went down for a long while. I've been getting around to responding since it was restored but been a little busy.
I've spent some time investigating, however beyond the known and by- design "stale value" problem that I previously described, I do not see anything new to fix. The build using stretch instead of buster when you've done `lb config` followed by `lb config --distribution buster` with the version of live- build you are using which has stretch as the default, is to be expected based upon how "updating"/"modifying" the config works (blocking automatic determination of option values from other option values). On the first run LB_DISTRIBUTION defaults to "stretch" because you did not use "--distribution", and because you did not specify "--parent- distribution", LB_PARENT_DISTRIBUTION copies LB_DISTRIBUTION. Then when trying to modify LB_DISTRIBUTION to "buster" in the second run, only that option gets updated, not LB_PARENT_DISTRIBUTION, and with LB_PARENT_DISTRIBUTION actually being used over LB_DISTRIBUTION (in some places at least) for a debian image, "stretch" thus gets used from that option rather than "buster" from the other, and thus apt is using stretch. This "stale value" behaviour is documented in the `lb config` man page. I ended up going off in a direction of thinking that some permission issue was occurring without a warning being shown, which was very confusing, such that the files were not being modified, but I think now that this must have been just confusion, since I can find no such issue with modifying the config files, and the output in the screenshots provided give supporting evidence to suggest strongly that they were being written fine. The problem could have been resolved either by using `--parent- distribution buster`, or deleting the config files before running `lb config --distribution buster`, which I thought had been tried and had not worked, but a mistake must have been made I guess as it should have worked as long as you have the right permissions. Things may improve on the "stale value" front soon. One part of the config work I mentioned that I did yesterday involved creating a new `- -ignore-saved` option for `lb config` which causes it to ignore any existing config, thus operating in a "replace" mode rather than "modify" mode, requiring you to specify all customised options along with it, but because the existing saved values are ignored, prevents stale values causing issues like this. I have submitted this enhancement for consideration for the next release. I have an idea of how the "stale value" issue could be addressed even better, but no firm clear idea on how to achieve it in a nice way, so it might not happen. I see no valid basis that advice should be to always run `lb config` with elevated privileges, you just need to be consistent about whether you do or do not. Anyway, I'm glad you got it working in the end. Regards, Lyndon On Tue, 2020-04-28 at 12:13 +0530, Harshad Joshi wrote: > Yes. I initially executed everything under sudo > Didn't work so I had to switch to actual root. > > --sent from OnePlus device-- > Didn't work so I had to switch to actual root. > > --sent from OnePlus device-- > On Tue, 28 Apr, 2020, 11:48 AM , <jnq...@gmail.com> wrote: > > Sorry, to be more clear, by root I wasn't referring to actual root, > > but use of sudo, as in I expected that you must have run `sudo lb > > config...` to initially create the config instead of just `lb > > config...`, but dropped the `sudo` on trying to modify it, which > > then failed. `lb config` does not require `sudo`, unlike the other > > commands. So yeah, if you'd created it initially with sudo, I can > > understand it requiring sudo to then make adjustments. But no error > > appearing in a situation of having originally used `sudo` and then > > trying to modify without is very much not ideal. On Tue, 2020-04-28 at 16:28 +1000, Michael . wrote: > > I wasn't going to post but this is a "problem" that has been > > occurring > > for quite a while now and has been brought up in this list before. > > The > > best thing to do with all live build commands (i.e. lb clean, lb > > config, lb build) is to run them as root. Doing this forces live > > build > > to run the config you tell it to run and where you tell it to run. > If > > you run lb config as root without having changed directory (e.g. cd > > home/USERNAME/LiveBuild) it will create the config and build it in > > the > > root folder.
