Hi all,
wanted to give you all a status update as to where we stand with pungi and Fedora 23. the current blocker is https://bugzilla.redhat.com/show_bug.cgi?id=1208092 there is a bug in mock where it forcibly unmounts anything that is mounted in the chroot. I have proposed it as a blocker for F23 Alpha.
leading up to this we hit an issue where the mounting was not happening correctly. it turns out that when you pass os.path.join two variables the first one is silently dropped. not sure if this is a bug in python or the way that os.path.join is supposed to work. we have a workaround deployed in the runroot plugin.
Right now we are working in a non optional fashion but it is one that works with pungi. http://koji.fedoraproject.org/koji/taskinfo?taskID=10328143 is a failed runroot task if you look in the mock log you can see the mount being forcibly unmounted.
we could force the use of bind mounts only in runroot and add the mounts to the mock config, which would be an additional step to take and one that goes against what was intended and limits the options unless we then mount them elsewhere and bind mount. it is kind of messy.
We have branching on Tuesday and are just over two weeks from Alpha change freeze, our window to get pungi working is rapidly shrinking. we do have other deliverables to sort out yet also
Regards
Dennis
On Friday, July 10, 2015 09:58:59 AM Mathieu Bridon wrote:
leading up to this we hit an issue where the mounting was not happening correctly. it turns out that when you pass os.path.join two variables the first one is silently dropped. not sure if this is a bug in python or the way that os.path.join is supposed to work.
Do you mean this?
>>> os.path.join('/foo', '/bar') == '/bar' TrueIf this is what you mean, then it indeed is the expected behaviour:
If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component.
https://docs.python.org/2/library/os.path.html#os.path.join
This is the case, so we will have to get a patch into koji to not use os.path.join
Dennis
On Fri, 2015-07-10 at 09:03 -0500, Dennis Gilmore wrote:
On Friday, July 10, 2015 09:58:59 AM Mathieu Bridon wrote:
leading up to this we hit an issue where the mounting was not happening correctly. it turns out that when you pass os.path.join two variables the first one is silently dropped. not sure if this is a bug in python or the way that os.path.join is supposed to work.
Do you mean this?
>>> os.path.join('/foo', '/bar') == '/bar' TrueIf this is what you mean, then it indeed is the expected behaviour:
If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component.
https://docs.python.org/2/library/os.path.html#os.path.joinThis is the case, so we will have to get a patch into koji to not us os.path.join
Or rather, only pass it absolute paths as the first argument.
What code in Koji does that?
On Fri, Jul 10, 2015 at 9:58 AM, Mathieu Bridon bochecha@daitauha.fr wrote:
On Fri, 2015-07-10 at 09:03 -0500, Dennis Gilmore wrote:
On Friday, July 10, 2015 09:58:59 AM Mathieu Bridon wrote:
leading up to this we hit an issue where the mounting was not happening correctly. it turns out that when you pass os.path.join two variables the first one is silently dropped. not sure if this is a bug in python or the way that os.path.join is supposed to work.
Do you mean this?
>>> os.path.join('/foo', '/bar') == '/bar' TrueIf this is what you mean, then it indeed is the expected behaviour:
If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component.
https://docs.python.org/2/library/os.path.html#os.path.joinThis is the case, so we will have to get a patch into koji to not us os.path.join
Or rather, only pass it absolute paths as the first argument.
What code in Koji does that?
This is specific to the runroot plugin, the code is in ./plugins/runroot.py (relative path at root of git clone dir).
-AdamM
-- Mathieu
rel-eng mailing list rel-eng@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/rel-eng
rel-eng@lists.fedoraproject.org