I was thinking about future of Mock and I would like to share my thought with you:
* This year will be EOLed RHEL5. Despite that I would like to keep RHEL5 configs for maybe an additional year. I.e. support RHEL5 as build target.
* On the other hand - I'm thinking about ending support for RHEL6 as host platform. I.e. no longer build new mock version for RHEL6. But still have RHEL6 config, so users can build their SRPM for RHEL6. This will allow me to get rid of some compatibility workarounds and use --new-chroot everywhere (as RHEL6 does not have systemd-nspawn).
* Make --new-chroot default. Did you tested it? Do you have cases when it does not work? Please report it. I plan to keep --old-chroot option for some time (definitely for this year).
* Check gpg signatures in rawhide. See https://pagure.io/releng/issue/6600
I welcome any comments.
Mirek
Dne 25.1.2017 v 15:09 Miroslav Suchý napsal(a):
- Make --new-chroot default. Did you tested it? Do you have cases when it does not work? Please report it. I plan to
keep --old-chroot option for some time (definitely for this year).
Do you have some tracker for this?
https://bugzilla.redhat.com/show_bug.cgi?id=1372234
Vít
Dne 25.1.2017 v 16:14 Vít Ondruch napsal(a):
Do you have some tracker for this?
Nope. This is why I wrote this email. So you get familiar with the plan and have chance to comment.
I am aware of those nspawn bugs, and I do plan to address them.
Dne 25.1.2017 v 16:14 Vít Ondruch napsal(a):
Dne 25.1.2017 v 15:09 Miroslav Suchý napsal(a):
- Make --new-chroot default. Did you tested it? Do you have cases when it does not work? Please report it. I plan to
keep --old-chroot option for some time (definitely for this year).
Do you have some tracker for this?
And I just filled another:
https://bugzilla.redhat.com/show_bug.cgi?id=1419501
Vít
On 25 January 2017 at 09:09, Miroslav Suchý msuchy@redhat.com wrote:
I was thinking about future of Mock and I would like to share my thought with you:
- This year will be EOLed RHEL5. Despite that I would like to keep RHEL5 configs for maybe an additional year. I.e.
support RHEL5 as build target.
- On the other hand - I'm thinking about ending support for RHEL6 as host platform. I.e. no longer build new mock
version for RHEL6. But still have RHEL6 config, so users can build their SRPM for RHEL6. This will allow me to get rid of some compatibility workarounds and use --new-chroot everywhere (as RHEL6 does not have systemd-nspawn).
If this happens please make a large version number change so that people who host on RHEL-6 (which is still growing of all things) can stick to an old version and figure out what to do from then on.
- Make --new-chroot default. Did you tested it? Do you have cases when it does not work? Please report it. I plan to
keep --old-chroot option for some time (definitely for this year).
- Check gpg signatures in rawhide. See https://pagure.io/releng/issue/6600
I welcome any comments.
Mirek
buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org
Hi,
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
One thing that I have been though is about configurations, we maybe should have a separate package with all configurations , all files /etc/mock/*cfg except site-defaults.cfg should have separate releases , when Fedora 27 arrive, we will need new configurations and for that, we shouldn't release a new mock version (IMO) but a new mock- fedora (configurations) version like RPFusion btw [1] Second thought, is use more "include statement" [2] i.e instead we generate all /etc/mock/*cfg , maybe we can use "include statement" for example F24 configurations is just headers and include some templates , this could useful for example when I want change metadata_expire=0 to metadata_expire=6h , instead need edit many files i386, x86_64 etc I just need change in one template.
Cheers,
[1] https://github.com/rpmfusion-infra/mock-rpmfusion
[2] https://github.com/rpmfusion-infra/mock-rpmfusion/commit/00159ac231900f bb3eead47e3974d3f0e777e131 more info about use of include n configuration here: https://bugzilla.redhat.com/show_bug.cgi?id=1272381
Dne 28.1.2017 v 07:00 Sérgio Basto napsal(a):
One thing that I have been though is about configurations, we maybe should have a separate package with all configurations , all files /etc/mock/*cfg except site-defaults.cfg should have separate releases , when Fedora 27 arrive, we will need new configurations and for that, we shouldn't release a new mock version (IMO) but a new mock- fedora (configurations) version like RPFusion btw [1]
-1 The cadence of mock release should be faster than fedora releases. I personally target to every 2 months. So Fedora branching is always good poke to create new mock release and address all patches and reports I got in mean time.
Second thought, is use more "include statement" [2] i.e instead we generate all /etc/mock/*cfg , maybe we can use "include statement" for example F24 configurations is just headers and include some templates , this could useful for example when I want change metadata_expire=0 to metadata_expire=6h , instead need edit many files i386, x86_64 etc I just need change in one template.
+1 Patches are welcome.
- Make --new-chroot default. Did you tested it? Do you have cases when it does not work? Please report it. I plan to
keep --old-chroot option for some time (definitely for this year). I welcome any comments.
I'm glad to see systemd-nspawn as new tool for containerization (+namespaces). It is really cool now, and I almost can use mock as light-weight containers for my tasks and builds.
I didn't test `--new-chroot` itself because it doesn't fit my use-cases. How do you use `--new-chroot` ? I'm using `--shell` for some general purposes because it splits stdout and stderr of command, which is desired and expected behaviour.
For example: $ mock -q -r epel7.cfg --shell 'rpmspec -P somespec.spec' > spec-parsed.spec , or `rpmspec -q ` and so on. rpmspec will output smth like
warning: bogus date in %changelog: Thu May 26 2006 Tim Waugh twaugh@redhat.com 3.1-13
on most of specs to stderr. But in case of --*-chroot or systemd-nspawn I'll get broken spec with mixed output and so on. It looks for me as systemd's bug now, not mock's. Isn't it?
I tested systemd-nspawn a bit and faces with several issues. --- First of all, I can't mount_bind to /tmp inside chroot. It looks odd.. (I'll report it on BZ tomorrow).
try config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/home', '/tmp/test' )) config_opts['use_nspawn'] = True
In case of `use_nspawn` - /tmp instide chroot empty at all! --- Second - using of `use_nspawn` breaks `--shell` option also :( It mixes stderr and stdout. Does it hard to fix..? Would 'Make --new-chroot default' affect `--shell` behaviour ? --- Third. I faced with a bit strange behaviour while mock processing changes in config files. When I change * config_opts['macros']['%_smp_mflags'] * config_opts['chroot_setup_cmd'] * config_opts['plugin_conf']['root_cache_enable'] and so on, I expect that changes would be affected immediately and cache would be rebuilded. But it doesn't have any effects until I manually run # rm -rf /var/lib/mock* /var/cache/mock/*
Is it "by design"..? Is it possible to force root rebuilding on changes that would affect build process..?
---
Miroslav, do you have any plans/PoC on implementing templates ( https://github.com/rpm-software-management/mock/issues/6#issuecomment-262604... ) ? :)
Dne 1.2.2017 v 22:18 Vit Ry napsal(a):
I didn't test `--new-chroot` itself because it doesn't fit my use-cases. How do you use `--new-chroot` ?
It is the same as config_opts['use_nspawn'] = True
I'm using `--shell` for some general purposes because it splits stdout and stderr of command, which is desired and expected behaviour.
For example: $ mock -q -r epel7.cfg --shell 'rpmspec -P somespec.spec' > spec-parsed.spec , or `rpmspec -q ` and so on. rpmspec will output smth like
warning: bogus date in %changelog: Thu May 26 2006 Tim Waugh twaugh@redhat.com 3.1-13
on most of specs to stderr. But in case of --*-chroot or systemd-nspawn I'll get broken spec with mixed output and so on. It looks for me as systemd's bug now, not mock's. Isn't it?
Really? With mock-1.3.3 I run: mock --shell --new-chroot ">&2 echo 'error'" >/tmp/o 2>/tmp/e and /tmp/o is empty end /tmp/e contains:
INFO: mock.py version 1.3.3 starting (python version = 3.5.2)... Start: init plugins INFO: selinux disabled Finish: init plugins Start: run Start: chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: skipping root_cache aging check INFO: enabled dnf cache Start: cleaning dnf metadata Finish: cleaning dnf metadata INFO: enabled HW Info plugin Finish: chroot init Start: shell error Finish: shell
First of all, I can't mount_bind to /tmp inside chroot. It looks odd.. (I'll report it on BZ tomorrow).
Please do.
Second - using of `use_nspawn` breaks `--shell` option also :( It mixes stderr and stdout. Does it hard to fix..?
See above.
Would 'Make --new-chroot default' affect `--shell` behaviour ?
Definitely yes.
Third. I faced with a bit strange behaviour while mock processing changes in config files. When I change
- config_opts['macros']['%_smp_mflags']
- config_opts['chroot_setup_cmd']
- config_opts['plugin_conf']['root_cache_enable']
and so on, I expect that changes would be affected immediately and cache would be rebuilded. But it doesn't have any effects until I manually run # rm -rf /var/lib/mock* /var/cache/mock/*
Is it "by design"..? Is it possible to force root rebuilding on changes that would affect build process..?
Unless you have config_opts['plugin_conf']['root_cache_opts']['age_check'] = False then root cache should be deleted when timestamp of config change. See: https://github.com/rpm-software-management/mock/wiki/Plugin-RootCache If you experience something else, then it is bug.
Miroslav, do you have any plans/PoC on implementing templates ( https://github.com/rpm-software-management/mock/issues/6#issuecomment-262604... ) ? :)
Not in my TODO list for near future.
I'm using `--shell` for some general purposes because it splits stdout and stderr of command, which is desired and expected behaviour.
For example: $ mock -q -r epel7.cfg --shell 'rpmspec -P somespec.spec' > spec-parsed.spec , or `rpmspec -q ` and so on. rpmspec will output smth like
warning: bogus date in %changelog: Thu May 26 2006 Tim Waugh twaugh@redhat.com 3.1-13
on most of specs to stderr. But in case of --*-chroot or systemd-nspawn I'll get broken spec with mixed output and so on. It looks for me as systemd's bug now, not mock's. Isn't it?
Really? With mock-1.3.3 I run: mock --shell --new-chroot ">&2 echo 'error'" >/tmp/o 2>/tmp/e and /tmp/o is empty end /tmp/e contains:
Erm.. I'm strongly confused, but now (after last `yum update`?) it works fine on C7.3! So, I will stress-test systemd_nspawn again.
The only weird way with redirecting stderr only. But looks like it is systemd's bug, and not so important for me now.
I tried with Fedora rawhide (26):
# dnf -y --releasever=26 --installroot=/srv/mycontainer install systemd passwd dnf fedora-release vim-minimal
// strange for me (!) # systemd-nspawn -D /srv/mycontainer /bin/bash -c "echo hello; echo error >&2" 2>/dev/null hello error
// ok # systemd-nspawn -D /srv/mycontainer /bin/bash -c "echo hello; echo error >&2" 1>/dev/null Spawning container mycontainer on /srv/mycontainer. Press ^] three times within 1s to kill container. error Container mycontainer exited successfully.
// ok # systemd-nspawn -D /srv/mycontainer /bin/bash -c "echo hello; echo error >&2" 2>e 1>o # cat e ... error ...
$ mock -q -r epel-7-x86_64 --shell --new-chroot "echo stdout; echo 'error' >&2" 2>/dev/null stdout error
Same with last RHEL7/Centos 7.3.
Unless you have config_opts['plugin_conf']['root_cache_opts']['age_check'] = False then root cache should be deleted when timestamp of config change. If you experience something else, then it is bug.
No, I haven't this line in config. And it looks like a bug for me also. But I need some more time to stable reproduce it. Currently it is heizenbug =\
Miroslav, do you have any plans/PoC on implementing templates ( https://github.com/rpm-software-management/mock/issues/6#issuecomment-262604... ) ? :)
Not in my TODO list for near future.
Ok, I would send another useful proposals ;)
Hi,
On Thu, 2017-02-02 at 11:35 +0100, Miroslav Suchý wrote:
Really? With mock-1.3.3 I run: mock --shell --new-chroot ">&2 echo 'error'" >/tmp/o 2>/tmp/e and /tmp/o is empty end /tmp/e contains:
fedora-review do something like:
mock -r fedora-26-x86_64 --quiet --chroot -- rpm --eval "%dist %fedora %epel %buildarch %_libdir %_isa %arch"
stderr is empty and stdout got the warning message [1] and that breaks the fedora-review script. and with --old-chroot it works !
[1] /etc/localtime is not a symlink, not updating container timezone. .fc26 26 %epel %buildarch /usr/lib64 (x86-64) %arch
Second - using of `use_nspawn` breaks `--shell` option also :( It mixes stderr and stdout. Does it hard to fix..?
See above.
On Tue, 2017-08-22 at 14:49 +0200, Miroslav Suchý wrote:
Dne 20.8.2017 v 02:31 Sérgio Basto napsal(a):
/etc/localtime is not a symlink, not updating container timezone.
How did you get that. localtime is symlink since mock-1.2.0 (that is 3 years ago)!
Ah thanks for the tip ! , the issue was in my /etc/localtime of the system, my laptop have Fedora 25, but I use one modified kde [1] (kde4) and kde4 in "adjust date and time" use a copy of a file instead one symlink , I enter in gnome-control-center and set date and time and voilá the symbol link is there and mock works well ! . But in epel7 with kde4 may not work !
Best regards,
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/
Mirek _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.or g
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
Can be a little of topic but, may we enable or disable repos in command line ? or something like this :
mock -r epel-7-x86_64 --install foo --enablerepo=testing
(where testing is defined in /etc/mock/epel-7-x86_64.cfg )
Thanks and best regards.
Dne 2.3.2017 v 04:42 Sérgio Basto napsal(a):
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
Can be a little of topic but, may we enable or disable repos in command line ? or something like this :
mock -r epel-7-x86_64 --install foo --enablerepo=testing(where testing is defined in /etc/mock/epel-7-x86_64.cfg )
Thanks and best regards.
You can use "--pm-cmd" to achieve this ...
Vít
On Qui, 2017-03-02 at 09:40 +0100, Vít Ondruch wrote:
Dne 2.3.2017 v 04:42 Sérgio Basto napsal(a):
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
Can be a little (*)off topic but, may we enable or disable repos in command line ? or something like this :
mock -r epel-7-x86_64 --install foo --enablerepo=testing
(where testing is defined in /etc/mock/epel-7-x86_64.cfg )
Thanks and best regards.
You can use "--pm-cmd" to achieve this ...
Can you exemplify ? please I already poke pm-cmd while ago and never found the solution . Sometimes I'd like install packages from a testing repo or a copr repo , and I have to use a manual process like download packages and install from file system ...
Thank you,
Dne 2.3.2017 v 19:04 Sérgio Basto napsal(a):
On Qui, 2017-03-02 at 09:40 +0100, Vít Ondruch wrote:
Dne 2.3.2017 v 04:42 Sérgio Basto napsal(a):
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
Can be a little (*)off topic but, may we enable or disable repos in command line ? or something like this :
mock -r epel-7-x86_64 --install foo --enablerepo=testing(where testing is defined in /etc/mock/epel-7-x86_64.cfg )
Thanks and best regards.
You can use "--pm-cmd" to achieve this ...
Can you exemplify ? please I already poke pm-cmd while ago and never found the solution . Sometimes I'd like install packages from a testing repo or a copr repo , and I have to use a manual process like download packages and install from file system ...
Whatever you write behing --pm-cmd is treated as YUM/DNF commands, e.g.:
~~~ --pm-cmd install foo == dnf install foo ~~~
Sometimes there is collision with mock parameters, so it might be handy to use double dash to separate the YUM/DNF parameters, e.g.:
~~~ mock --pm-cmd -- install foo ~~~
Vít
Dne 2.3.2017 v 04:42 Sérgio Basto napsal(a):
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
Can be a little of topic but, may we enable or disable repos in command line ? or something like this :
mock -r epel-7-x86_64 --install foo --enablerepo=testing(where testing is defined in /etc/mock/epel-7-x86_64.cfg )
Thanks and best regards.
From mock man page: --disablerepo=REPO Pass --disablerepo option to package manager to disable a repository. It can be specified multiple times.
... --enablerepo=REPO Pass --enablerepo option to package manager to enable a repository. It can be specified multiple times.
In other word - yes mock understands this argument.
On Sex, 2017-03-03 at 08:17 +0100, Miroslav Suchý wrote:
Dne 2.3.2017 v 04:42 Sérgio Basto napsal(a):
On Qua, 2017-01-25 at 15:09 +0100, Miroslav Suchý wrote:
I welcome any comments.
Can be a little of topic but, may we enable or disable repos in command line ? or something like this :
mock -r epel-7-x86_64 --install foo --enablerepo=testing
(where testing is defined in /etc/mock/epel-7-x86_64.cfg )
Thanks and best regards.
From mock man page: --disablerepo=REPO Pass --disablerepo option to package manager to disable a repository. It can be specified multiple times.
... --enablerepo=REPO Pass --enablerepo option to package manager to enable a repository. It can be specified multiple times.
In other word - yes mock understands this argument.
Fantastic ! it works
Thank you,
buildsys@lists.fedoraproject.org
-
Miroslav Suchý -
Stephen John Smoogen -
Sérgio Basto -
Vit Ry -
Vit Ry
-
Vít Ondruch