Thanks for the followup reply. --sent from OnePlus device--
On Thu, 30 Apr, 2020, 6:23 PM , <jnq...@gmail.com> wrote: > @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. > >
