we can haz jenkins
so just in case it completely passed anybody *else* by, I thought I'd note that we totally have a Fedora Jenkins instance: http://jenkins.cloud.fedoraproject.org/ After a bit of poking about, I found a wiki page which explains a bit about who's running it, why, and what you can do with it: https://fedoraproject.org/wiki/Jenkins@infra It was announced to the infrastructure list in 2013, but not apparently anywhere else: https://lists.fedoraproject.org/pipermail/infrastructure/2013-March/012659.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Taskotron Staging Has Been Deployed
This has been a long time coming but after running on smaller systems for the last couple months to make sure that all the parts are running smoothly, Taskotron is now running in staging: https://taskotron.stg.fedoraproject.org/ What does this mean? It means that we are almost ready to turn on the production Taskotron system and turn off AutoQA. The staging environment will be used to test the code in a production-ish environment so that we aren't testing new configuration or features in production and is one of the last steps before we can truly say that Taskotron is running in Fedora. We're planning to deploy the production systems sometime next week so if you are responsible for a package and follow the results from AutoQA, please take a look at the Taskotron output for your packages and let us know if there are any discrepancies that we may have missed in our testing. If you're a tester (or anyone else), feel free to look through the results and let us know if you see anything that doesn't seem right. Task results can be found at: https://taskotron.stg.fedoraproject.org/resultsdb/jobs Simulated bodhi comments from the running tasks can be found at: https://taskotron.stg.fedoraproject.org/fakefedorainfra/boji/comments/0 Please report any issues found to: https://phab.qadevel.cloud.fedoraproject.org/ While replacing AutoQA is a significant milestone, Taskotron is far from complete. Keep an eye out for blog posts and mailing list threads about the next steps for Taskotron once the production system is up and running. If you have any questions, come find one of us in #fedora-qa, qa-devel@ or continue a thread here. Tim signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Make buildSRPMFromSCM faster?
The first step of most Koji builds is buildSRPMFromSCM, where a .src.rpm file is built from the git repo. Currently this involves completely building a mock buildroot containing all the BuildRequires, and running `rpmbuild -bs'. This takes many minutes (especially when arm is chosen as a builder). It seems the reason for this is because the spec file has to be fully parsed in order to work out the Source lines. Since Source lines might depend on RPM macros which might depend on any BuildRequire'd package, every BR package must be installed in the mock root. `rpmbuild -bs' takes seconds because it just bundles all the Source files with the spec file into an SRPM. Is this really necessary? Two shortcuts seem possible: (1) Limit the use of macros in Source lines, so that only a simple, standard, perhaps pre-cached buildroot can be used. (2) Perhaps uglier: Just build an SRPM that contains everything in dist-git + everything in the lookaside cache, and hope for the best ... Thoughts? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
How about not rebuilding the chroot every time... It's not like you have to worry about leftover BR's from building another package. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sáb, 2014-07-19 at 12:30 +0100, Richard W.M. Jones wrote: > The first step of most Koji builds is buildSRPMFromSCM, where a > .src.rpm file is built from the git repo. > > Currently this involves completely building a mock buildroot > containing all the BuildRequires, and running `rpmbuild -bs'. This > takes many minutes (especially when arm is chosen as a builder). If I understood the question, I use fedpkg switch-branch f20 , fedpkg switch-branch master etc and fedpkg srpm . > It seems the reason for this is because the spec file has to be fully > parsed in order to work out the Source lines. Since Source lines > might depend on RPM macros which might depend on any BuildRequire'd > package, every BR package must be installed in the mock root. > `rpmbuild -bs' takes seconds because it just bundles all the Source > files with the spec file into an SRPM. > > Is this really necessary? Just if we have "Source lines might depend on RPM macros which might depend on any BuildRequire'd" :) have you any example , Source lines ? Source lines should be immutable I remember put a ifdef in a source line for i386 and src.rpm wasn't equal for i386 and x86_64, but should, because we only export one of them. > Two shortcuts seem possible: > > (1) Limit the use of macros in Source lines, so that only a simple, > standard, perhaps pre-cached buildroot can be used. > > (2) Perhaps uglier: Just build an SRPM that contains everything in > dist-git + everything in the lookaside cache, and hope for the best ... > > Thoughts? > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sat, Jul 19, 2014 at 1:30 PM, Richard W.M. Jones wrote: > > The first step of most Koji builds is buildSRPMFromSCM, where a > .src.rpm file is built from the git repo. > > Currently this involves completely building a mock buildroot > containing all the BuildRequires, and running `rpmbuild -bs'. This > takes many minutes (especially when arm is chosen as a builder). > > It seems the reason for this is because the spec file has to be fully > parsed in order to work out the Source lines. Since Source lines > might depend on RPM macros which might depend on any BuildRequire'd > package, [...] For most packages this is not the case (i.e you do not need BR to build the srpm) ... maybe we should have some way to flag a package as such? Maybe just by adding a file with a specific name to the repo? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sat, Jul 19, 2014 at 03:37:15PM +0100, Sérgio Basto wrote:
>
>
> On Sáb, 2014-07-19 at 12:30 +0100, Richard W.M. Jones wrote:
> > The first step of most Koji builds is buildSRPMFromSCM, where a
> > .src.rpm file is built from the git repo.
> >
> > Currently this involves completely building a mock buildroot
> > containing all the BuildRequires, and running `rpmbuild -bs'. This
> > takes many minutes (especially when arm is chosen as a builder).
>
> If I understood the question, I use
> fedpkg switch-branch f20 , fedpkg switch-branch master etc and fedpkg
> srpm .
The question is related to what Koji does, not what local developers
do with 'fedpkg'.
> Just if we have "Source lines might depend on RPM macros which might
> depend on any BuildRequire'd" :)
> have you any example , Source lines ? Source lines should be immutable
> I remember put a ifdef in a source line for i386 and src.rpm wasn't
> equal for i386 and x86_64, but should, because we only export one of
> them.
Well something like (made up example):
Source0: %{lang_download_url}/%{name}-%{version}.tar.gz
where %lang_download_url is an RPM macro defined in some
lang-specific package that's not part of a normal build root.
I have no idea if there are packages which do this, which is kind of
my point. We spend probably an extra 10 minutes on each build on a
pretty obscure corner case.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, Jul 10, 2014 at 08:17:07AM +0300, Oron Peled wrote: > On Thursday 10 July 2014 01:49:41 Lennart Poettering wrote: > > Please understand that we are not duplicating "adduser" here. Already in > > the name of the tool we wanted to make clear thtat this is abotu system > > users, nothing else. The file format we defined has been reduced to the > > minimum possible, in order to make it difficult for people to use it for > > anything else than this. > > There are cases where a home directory of system users carry some semantics. > > Two examples from the top of my head: > * Some tftpd implementations use it as the base path (and chroot into it) > * Some anonymous ftpd implementation have similar use (chroot into ~ftp) Another interesting use case is gitolite: it's a system user that needs: - a shell (/bin/sh in Fedora) -- otherwise sshd won't allow login (/sbin/nologin) or login fails (/sbin/login) - a home directory (/var/lib/gitolite in Fedora) -- so sshd can use ~/.ssh/authorized_keys to work out who's allowed to use the service & what they're allowed to do sshd prevents users from ever getting the default shell due to the configuration of authorized_keys. However, it doesn't need/want a password allowing standard login (though the admin will do "su - gitolite" from root for initial setup or version migration). See http://gitolite.com/gitolite/how.html for more details on how gitolite's ssh authentication works. -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ANNOUNCE: Taking over ownership of orphaned package xmlrpc-epi
Hello Everyone, Since this package has been abandoned and I'd like to have it for dependencies for users of Second Life and maybe others who might find it useful. I've also fixed some minor compile issues for string security. Thanks, Shawn-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sat, Jul 19, 2014 at 5:30 AM, Richard W.M. Jones wrote: > (1) Limit the use of macros in Source lines, so that only a simple, > standard, perhaps pre-cached buildroot can be used. How about just trying to parse the Source lines, and if that fails due to use of macros that can't be evaluated in a simpleminded way, revert to the method used now? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sat, Jul 19, 2014 at 7:26 AM, Richard Shaw wrote: > How about not rebuilding the chroot every time... It's not like you have to > worry about leftover BR's from building another package. That could lead to packages that happen to build some of the time due to an undetected dependency on something that isn't in the BR but happens to be in a cached buildroot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Saturday, July 19, 2014, 8:20:30 PM, Eric Smith wrote: > On Sat, Jul 19, 2014 at 7:26 AM, Richard Shaw wrote: >> How about not rebuilding the chroot every time... It's not like you have to >> worry about leftover BR's from building another package. > That could lead to packages that happen to build some of the time due > to an undetected dependency on something that isn't in the BR but > happens to be in a cached buildroot. Then you would at least get failure or a working package. Just because a package builds without failure doesn't mean it is the intended build. A less desirable case would be a package with optional build dependencies, that gets built with different configurations based on the presence of extra packages that happen to be in that cached buildroot. Having the required packages for build and no more is important. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sat, Jul 19, 2014 at 7:20 PM, Eric Smith wrote: > On Sat, Jul 19, 2014 at 7:26 AM, Richard Shaw > wrote: > > How about not rebuilding the chroot every time... It's not like you have > to > > worry about leftover BR's from building another package. > > That could lead to packages that happen to build some of the time due > to an undetected dependency on something that isn't in the BR but > happens to be in a cached buildroot. I fail to see why this would occur building an SRPM, the dependencies should be identical for all packages, we're not talking about actually building the package, just building the SRPM. For that matter, instead of rebuilding a chroot every time, why not cache one (tar?) so you get rid of the transaction overhead. It can still be re-created on a regular basis in case any of the packages in the chroot get updated, you just don't do it every time for every package. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
lör 2014-07-19 klockan 12:30 +0100 skrev Richard W.M. Jones: > The first step of most Koji builds is buildSRPMFromSCM, where a > .src.rpm file is built from the git repo. > > Currently this involves completely building a mock buildroot > containing all the BuildRequires, and running `rpmbuild -bs'. This > takes many minutes (especially when arm is chosen as a builder). The buildroot for the buildSRPMFromSCM step is not even the full default buildroot for the package build step and it doesn't install the BRs. On my recent koji builds 'group install "srpm-build"' results in "Install 10 Packages (+226 Dependent packages)" and no additional packages are installed during the buildSRPMFromSCM step. For the build step the 'group install "build"' results in "Install 24 Packages (+141 Dependent packages)" after which the BRs and their dependencies are installed. (These numbers are from rawhide.) > It seems the reason for this is because the spec file has to be fully > parsed in order to work out the Source lines. Since Source lines > might depend on RPM macros which might depend on any BuildRequire'd > package, every BR package must be installed in the mock root. > `rpmbuild -bs' takes seconds because it just bundles all the Source > files with the spec file into an SRPM. If there are such lines they will break since the BRs are not installed during the buildSRPMFromSCM step. > Is this really necessary? > > Two shortcuts seem possible: > > (1) Limit the use of macros in Source lines, so that only a simple, > standard, perhaps pre-cached buildroot can be used. > > (2) Perhaps uglier: Just build an SRPM that contains everything in > dist-git + everything in the lookaside cache, and hope for the best ... > > Thoughts? > > Rich. Mattias smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Sat, Jul 19, 2014 at 7:12 PM, Richard Shaw wrote: > On Sat, Jul 19, 2014 at 7:20 PM, Eric Smith wrote: >> That could lead to packages that happen to build some of the time due >> to an undetected dependency on something that isn't in the BR but >> happens to be in a cached buildroot. > I fail to see why this would occur building an SRPM, the dependencies should Right. A "thinko" on my part. Sorry. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
