On Tue, 2020-03-10 at 17:23 +0000, jnq...@gmail.com wrote: > On Tue, 2020-03-10 at 15:31 +0000, jnq...@gmail.com wrote: > > double checking some of my recent contributions with further test > > runs, > > one of the issues on my todo list to look into is that when > > creation > > of > > the source disc is turned on, I'm seeing the following for each > > source > > package download: > > > > ``` > > Picking 'audit' as source package instead of 'libaudit-common' > > NOTICE: 'audit' packaging is maintained in the 'Git' version > > control > > system at: > > https://salsa.debian.org/debian/audit.git > > Please use: > > git clone https://salsa.debian.org/debian/audit.git > > to retrieve the latest (possibly unreleased) updates to the > > package. > > Need to get 1143 kB of source archives. > > Get:1 http://deb.debian.org/debian buster/main audit 1:2.8.4-3 > > (dsc) > > [2483 B] > > Get:2 http://deb.debian.org/debian buster/main audit 1:2.8.4-3 > > (tar) > > [1124 kB] > > Get:3 http://deb.debian.org/debian buster/main audit 1:2.8.4-3 > > (diff) > > [16.7 kB] > > Fetched 1143 kB in 1s (867 kB/s) > > Download complete and in download only mode > > W: Download is performed unsandboxed as root as file 'audit_2.8.4- > > 3.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: > > Permission denied) > > ``` > > > > note the troubling warning at the end. > > > > with a lot to do I have not yet even determined whether this is a > > new > > problem that has surfaced from my changes on master to the source > > stage, specifically I made a change to have files downloaded to a > > new > > empty folder rather the the root of chroot, so perhaps we need to > > change the owner of that directory to satisfy apt/aptitude?, or > > whether > > it already existed beforehand. > > > > help solving this would be appreciated if anyone can get to an > > understanding of the problem before I do. > > brief update, so it does indeed occur on the current release in sid > so > has nothing to do with my contribution changes. > > i'll try pushing on ahead with investigating and either push an MR or > bug report at some point later... > > perhaps a google search might also be a good idea (will go do that > now)...
Okay so I've solved this. MR to be submitted shortly. for those interested (anyone? :p) previously source packages would be downloaded to the root directory of the chroot, which required root permission, hence the errors. in one of my recent contributions that has been merged I have changed things so that the packages are downloaded to a new empty directory, but that is still owned by root and with permissions of 755. I've just tried changing that to 777 to give this '_apt' user access, and that solves it. So we just need a line to set the permission of this new directory I had it create to 777 and bug fixed! yay!!
