Re: [Base] Base Design WG agenda meeting 8st June 2015 14:15 UTC on #fedora-meeting-2
Hi, Sorry for not being able to join last meeting - I had a training:( I won't be able to attend next meeting - I am traveling to US, but if you are going to vote about lnykryn joining the WG, please consider me voting *+1*. Thanks, Vašek On 06/08/2015 04:58 PM, Harald Hoyer wrote: On 08.06.2015 10:29, Harald Hoyer wrote: *IMPORTANT*: #fedora-meeting-2 ... I repeat: *two* Agenda: - Interview candidates for new memberships - Optionally accept new members - Status - Docker - Status - BuildRequires - Open Floor Please add items by replying to this mail. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2015-06-08/fedora_base_design_working_group.2015-06-08-14.15.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2015-06-08/fedora_base_design_working_group.2015-06-08-14.15.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2015-06-08/fedora_base_design_working_group.2015-06-08-14.15.log.html -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic Phone: +420 739 666 824 -- 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: [Base] Base Design WG agenda meeting 1st June 2015 14:15 UTC on #fedora-meeting-2
Hi guys, I am sorry I missed the meeting yesterday - I had a training I completely forgot about, but anyway, my comments to the topic(s) follow: Gathering of an information for the modularization proposal should surely be a common effort of es and Base - as both WGs has edditions/spins as their users From my pov Base should own intersection of the package set from (all?) editions/spins/WGs. Thus if we agree on using scl for our modularization, then yes, it should be in Base's hands to add it the core pkg set. But also as jreznik said, we screwed up in generating requirements for such minimal/common package set:). On the other hand whatever is optional and not THE ONE technology we choose to support should be probably in hands of es so that we don't add bloat to base system. 14:47:53 langdon msekleta, i guess i am making the argument that if es says this is how we do x, which relies on y then es needs to work with base to get y included in base for use by the editions (or other WGs in general) If it is agreed upon that all editions will benefit from that x and y, then yes. But let's imagine Workstation decides to use xdg-apps and server decides to use Docker for similar use cases - how do es or Base get involved in here? That's my 2c:) Cheers, Vašek On 1.6.2015 17:13, Harald Hoyer wrote: On 01.06.2015 10:50, Harald Hoyer wrote: *IMPORTANT*: #fedora-meeting-2 ... I repeat: *two* Agenda: - Interview candidates for new memberships - Optionally accept new members - Open Floor Please add items by replying to this mail. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2015-06-01/fedora_base_design_working_group.2015-06-01-14.17.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2015-06-01/fedora_base_design_working_group.2015-06-01-14.17.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2015-06-01/fedora_base_design_working_group.2015-06-01-14.17.log.html -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic Phone: +420 739 666 824 -- 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: Vagrant group in comps
On 2.3.2015 02:55, Josef Stribny wrote: Hi all, I would like to introduce a new @vagrant group that should pull in vagrant with vagrant-libvirt plugin (at the very least) since libvirt might be the preferred virtualization when used with Vagrant on Fedora and I would like to encourage users to use the packaged plugin. Also, we set libvirt as a default provider in the Fedora package and I think it would be nicer to recommend install Vagrant group instead of install vagrant-libvirt package. What do you think? Is it reasonable or unnecessary? (Btw. this is connected with the new Fedora 22 Vagrant feature[0]) Regards Josef [0] https://fedoraproject.org/wiki/Changes/Vagrant I think it' a great idea. The only problem I see atm is a String Freeze [1] which was at 2015-02-24. I'd suggest to following the Breaking the freeze instructions in [1] and going on with addition if it gets approved as users would definitely benefit from this change. [1] https://fedoraproject.org/wiki/Software_String_Freeze_Policy?rd=ReleaseEngineering/StringFreezePolicy Regards, Vašek -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: yum or dnf in the Fedora 22 Docker base image?
On 17.2.2015 12:33, Daniel J Walsh wrote: Not that I know of. On 02/16/2015 09:50 AM, M. Edward (Ed) Borasky wrote: Thanks! Are there tracking bugs in Bugzilla I can subscribe to? I don't think there are any - feel free to file it. On Mon, Feb 16, 2015 at 9:42 AM, Daniel J Walsh dwa...@redhat.com wrote: On 02/16/2015 12:31 PM, M. Edward (Ed) Borasky wrote: On Mon, Feb 16, 2015 at 5:19 AM, Daniel J Walsh dwa...@redhat.com wrote: I think the F22 and Rawhide (Is it F23 at this point), should both use dnf not yum. We need to get more testing on dnf in containers. I'm ready to start testing F22 containers either way and would prefer dnf. What's the best process to get this rolling? Who owns the image - release engineering or Project Atomic? The reason I ask is that Project Atomic has their own mailing list and uses Trac, not the Red Hat Bugzilla, for issue tracking. Either way, my main upstream component (RStudio Server) may end up stuck with F21 - it doesn't link with the latest Boost right now and they only support CentOS and Debian/Ubuntu. Vaclav is handling this right now. I don't see this as owned by ProjectAtomic. The problem currently is I am not able to build any Fedora image due to some Anaconda problems. I'll get back to you as soon as I have something helpful. Vašek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: Agenda for Env-and-Stacks WG meeting (2014-11-25)
#fedora-meeting: Env and Stacks (2014-11-26) Meeting started by vpavlin at 12:01:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-11-26/env-and-stacks.2014-11-26-12.01.log.html . Meeting summary --- * init process (vpavlin, 12:01:38) * Follow-ups (vpavlin, 12:02:21) * LINK: https://fedoraproject.org/wiki/User:Ncoghlan/User_level_package_management (vpavlin, 12:09:30) * ncoghlan started with a draft for a User Level Package Management topic (vpavlin, 12:12:19) * bkabrda plans to deploy devpi (vpavlin, 12:12:19) * devpi instance wil be here: 209.132.184.166 (nothing is there ATM) (vpavlin, 12:16:35) * Language specific repositories (vpavlin, 12:16:54) * ACTION: ncoghlan to describe the devpi pilot and what we'd like to get out of it (vpavlin, 12:19:09) * Koji devels are looking into building non-RPM content (Java jars in the first place) (vpavlin, 12:23:32) * WRT vondruch'a opinion, Ruby might not be good candidate for Language specific repositories project (vpavlin, 12:36:37) * Python's PEP 440 versioning scheme explicitly introduced redistributor support, any ecosystems without that feature may be ill-suited (ncoghlan, 12:38:58) * pip and conda both came out of the Python community - the origins of that split reflects a real difference in the way application developers and data analysts approach their tools (vpavlin, 12:45:23) * ACTION: everybody should look at conda/NixOS and continue to discuss Language specific repositories on ML. (hhorak, 12:53:14) * Election planning (vpavlin, 12:54:17) * Every voting member should state if he wants continue his participation as a voting member in the Env Stacks WG by 10th Dec 2014, no response counts as negative answer (vpavlin, 12:56:31) * EnvStacks WG elections should be aligned with FESCo elections as it would be easier for us and users (vpavlin, 12:57:43) * Decision to be made if we want Townhall, Interviews (or nothing?) (vpavlin, 13:04:48) * Chairman for next meeting (vpavlin, 13:06:09) * hhorak to chair meeting on 2014-12-03 (vpavlin, 13:08:40) * Open floor (vpavlin, 13:08:48) Meeting ended at 13:22:52 UTC. Action Items * ncoghlan to describe the devpi pilot and what we'd like to get out of it * everybody should look at conda/NixOS and continue to discuss Language specific repositories on ML. Action Items, by person --- * ncoghlan * ncoghlan to describe the devpi pilot and what we'd like to get out of it * **UNASSIGNED** * everybody should look at conda/NixOS and continue to discuss Language specific repositories on ML. People Present (lines said) --- * ncoghlan (91) * vpavlin (57) * hhorak (30) * vondruch (26) * bkabrda (7) * zodbot (4) * jreznik (3) * mclasen (2) * nphilipp (1) * samkottler (0) * sicampbell (0) * tjanez (0) * juhp (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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: [Base] Base Design WG agenda meeting 14 November 2014 15:00 UTC on #fedora-meeting
On 11.11.2014 17:02, Matthew Miller wrote: On Tue, Nov 11, 2014 at 03:30:43PM +0100, Harald Hoyer wrote: - Docker update Note that Docker images are currently not building properly in Koji. At this point in the cycle, this seems fairly urgent. Who has ownership for this? http://koji.fedoraproject.org/koji/tasks?state=allview=treemethod=imageorder=-id This doesn't look good...and as Image Factory doesn't provide very good logs, I have no idea where the problem might be (I don't have rights to build an image to investigate anyway..) Dennis, do you know why those builds fail? Also, let me know if there are any news in communication with Docker about pushing our images or if there is anything I can do in this area Vašek -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 14 November 2014 15:00 UTC on #fedora-meeting
On 12.11.2014 16:25, Matthew Miller wrote: On Wed, Nov 12, 2014 at 07:00:11AM -0600, Dennis Gilmore wrote: Big issue here is that its all manual processes and tehy do not want us to update the images often, in the rawhide case we want to update daily. Yeah. I think we shold avoid pushing rawhide to them for now. Possibly push it to a secondary docker repo like fedora-rawhide (repo means too many things, but in this case, it's a collection of docker images on https://hub.docker.com/), or else for F22 look at hosting our own. That sounds good to me - let's update fedora:rawhide (https://registry.hub.docker.com/_/fedora/) base image for example weekly and create f.e. fedora/rawhide image which could be pushed there easily daily and mention this from fedora repo. Would that work for you? Vašek -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 14 November 2014 15:00 UTC on #fedora-meeting
I also have one more topic... Software written in Go is linked statically and we are not able to figure out which version of Go was used during build. Means that despite we have latest Go with all CVE fixed in Fedora, we still have these CVEs in some packages built from old Go releases. I've heard someone to mention we could use Bundles tag in RPM header to track this. I am not sure if I understood it correctly as I hasn't been able to find anything about it... With this said I am CCing Florian once again to help us out:) Regards, Vašek On 11.11.2014 15:47, Jaroslav Reznik wrote: - Original Message - Agenda: - Status buildrequires cleanup work (davids nils!) - Update on factory-reset work - Docker update - Open Floor One more topic - generic network install images, there was a question raised, if Base WG would like to take care of it. I'll provide more details in the meeting. Jaroslav Last meeting logs: http://meetbot.fedoraproject.org/fedora-meeting/2014-10-31/fedora_base_design_working_group.2014-10-31-15.02.log.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 14 November 2014 15:00 UTC on #fedora-meeting
On 11.11.2014 16:26, Vít Ondruch wrote: Dne 11.11.2014 v 16:17 Václav Pavlín napsal(a): I also have one more topic... Software written in Go is linked statically and we are not able to figure out which version of Go was used during build. Means that despite we have latest Go with all CVE fixed in Fedora, we still have these CVEs in some packages built from old Go releases. I've heard someone to mention we could use Bundles tag in RPM header to track this. You mean bundled virtual provide, e.g. Provides: bundled(go) = 1.0.0 etc. See https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle for more information. Thanks! That's probably it, although I think we need to set this automatically during the build to make it useful. Vašek Vít I am not sure if I understood it correctly as I hasn't been able to find anything about it... With this said I am CCing Florian once again to help us out:) Regards, Vašek On 11.11.2014 15:47, Jaroslav Reznik wrote: - Original Message - Agenda: - Status buildrequires cleanup work (davids nils!) - Update on factory-reset work - Docker update - Open Floor One more topic - generic network install images, there was a question raised, if Base WG would like to take care of it. I'll provide more details in the meeting. Jaroslav Last meeting logs: http://meetbot.fedoraproject.org/fedora-meeting/2014-10-31/fedora_base_design_working_group.2014-10-31-15.02.log.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: Meeting minutes from Env-and-Stacks WG meeting (2014-10-14)
On 14.10.2014 16:51, Honza Horak wrote: #fedora-meeting: Env and Stacks (2014-10-14) Meeting started by hhorak at 13:02:18 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-14/env-and-stacks.2014-10-14-13.02.log.html . Meeting summary --- * init process (hhorak, 13:02:39) * Docker, Docker, Docker (hhorak, 13:06:09) * LINK: https://fedoraproject.org/wiki/Docker (ncoghlan, 13:07:26) * ACTION: hhorak will create a new task about preparing dockerfiles recommended tips (hhorak, 13:40:28) * dockerfile_lint (hhorak, 13:41:03) * LINK: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000565.html (ncoghlan, 13:45:20) * checks to dockerfile_lint might be done in parallel with defining some recommended practices to write dockerfiles (hhorak, 13:46:20) * IDEA: dockerfile_lint could be run in %check section of fedora-dockerfiles package; dockerfile_lint does not seem to be usable in Taskotron unless we start building layered images in Fedora (hhorak, 13:54:55) Yes, running in %check should be ok for now. When we start building layered images, we will probably want to check every Dockerfile coming for build and fail on errors, or at least report warnings. Vašek * taskotron will allow to run some tasks for arbitrary components only, but since it does not do it now we should be fine with running dockerfile_lint in %check for now (hhorak, 14:08:35) * we should start to think about delivering layered images during some of the next meetings (or on ML) (hhorak, 14:17:23) * Picking chairman for the next meeting (hhorak, 14:20:06) * OpenFloor (hhorak, 14:21:13) * standardized macros for bootstrapping packages (hhorak, 14:46:30) * IDEA: packages bootstraps are implemented without any standardization, but with some rules at least for RPM macros names it might be much more easy to bootstrap packages (hhorak, 14:46:30) Meeting ended at 14:50:15 UTC. Action Items * hhorak will create a new task about preparing dockerfiles recommended tips Action Items, by person --- * hhorak * hhorak will create a new task about preparing dockerfiles recommended tips * **UNASSIGNED** * (none) People Present (lines said) --- * hhorak (65) * ncoghlan (54) * nphilipp (21) * juhp (17) * tflink (13) * bkabrda1 (6) * [GNU] (5) * zodbot (4) * pkovar (2) * bkabrda (0) * samkottler (0) * sicampbell (0) * vpavlin (0) * tjanez (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 03 October 2014 15:00 UTC on #fedora-meeting
Dennis, how can I help you to figure out image publishing process? Let me know if I can be any help, we should definitely move forward on this and it probably doesn't make sense vote until you say we have a workflow how to ship the image. Vašek On 3.10.2014 08:56, Václav Pavlín wrote: Hi I will be traveling to Prague in the afternoon so I'd suggest to cancel this meeting as 2 members are not going to be there and I my bus might get delay. Vašek On 3.10.2014 02:57, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 02 Oct 2014 18:28:40 +0200 Phil Knirsch pknir...@redhat.com wrote: Unfortunately tomorrow is a public holiday in Germany, but if someone else from the WG would run the meeting i've put together a proposed agenda for tomorrow to give a few updates: Agenda: - Update buildrequires cleanup work (davids) - Update Alpha base image - Open Floor Thanks regards, Phil I will be missing the meeting due to being on PTO Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJULfRzAAoJEH7ltONmPFDRB7kQAKkrlI37MubsAPVtpgHl8riB +kzk4owFeyxRMOwhEahRWDNAPOj9GA2gB53DjE9sWfTrlBfgIQxK+vjrOGCUfkaJ hvPRVOTp1yrpchea6FnR7H8ZWD1HEcFgTt8ffpCHegnWJCfGlRgE4Ac1FZ75DicC wPx3z9iSzYTMNei13QgDFjsUyVROI7BDT0eQAuCGAqoJ5waGhoNzIuGf7HiNYpi5 VhYUuHXrOWRGBf8rRnxo94MLZWJKuLCd0mGNklMnZoA7eyJ1fxclfAEUf4NBFc7/ mfpK1zpQRiHkfsQSfZFOghTNOepWCWxKlLJIC2aYEbWDSQFTyzyigX8cm6tflfzi pBGuukHq/SNhcBtrnnNCKLGfB4T2kzPr3ph52urqqcKlDOLXTJ16nD2GdDmMdG8F ija2QmhZBEHO5b99J/b74iTgGmbrA+5XPrCF2c0hD6YG+CIcxI0e+uie6Y2e2zsC AoJnOf94eavkEWCJhIzKOhieLBo/pZ0JfwAuvR//euf52tUlaAvE2/aEehY5Ezb+ PaZ8fKgH71BST/r3exNKKv7BOWkQkcyBXeFhOkPuaToEOX17UoHisJdDrdxx/tAk AeZAAGvJSYeEt57HzObCbeS/OEZ+cCfnJu4s+zmuSiXImWkbyYV04xLTmLxzE+oP NvsU1+XAno8as7nylz5U =DLam -END PGP SIGNATURE- -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 03 October 2014 15:00 UTC on #fedora-meeting
Hi I will be traveling to Prague in the afternoon so I'd suggest to cancel this meeting as 2 members are not going to be there and I my bus might get delay. Vašek On 3.10.2014 02:57, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 02 Oct 2014 18:28:40 +0200 Phil Knirsch pknir...@redhat.com wrote: Unfortunately tomorrow is a public holiday in Germany, but if someone else from the WG would run the meeting i've put together a proposed agenda for tomorrow to give a few updates: Agenda: - Update buildrequires cleanup work (davids) - Update Alpha base image - Open Floor Thanks regards, Phil I will be missing the meeting due to being on PTO Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJULfRzAAoJEH7ltONmPFDRB7kQAKkrlI37MubsAPVtpgHl8riB +kzk4owFeyxRMOwhEahRWDNAPOj9GA2gB53DjE9sWfTrlBfgIQxK+vjrOGCUfkaJ hvPRVOTp1yrpchea6FnR7H8ZWD1HEcFgTt8ffpCHegnWJCfGlRgE4Ac1FZ75DicC wPx3z9iSzYTMNei13QgDFjsUyVROI7BDT0eQAuCGAqoJ5waGhoNzIuGf7HiNYpi5 VhYUuHXrOWRGBf8rRnxo94MLZWJKuLCd0mGNklMnZoA7eyJ1fxclfAEUf4NBFc7/ mfpK1zpQRiHkfsQSfZFOghTNOepWCWxKlLJIC2aYEbWDSQFTyzyigX8cm6tflfzi pBGuukHq/SNhcBtrnnNCKLGfB4T2kzPr3ph52urqqcKlDOLXTJ16nD2GdDmMdG8F ija2QmhZBEHO5b99J/b74iTgGmbrA+5XPrCF2c0hD6YG+CIcxI0e+uie6Y2e2zsC AoJnOf94eavkEWCJhIzKOhieLBo/pZ0JfwAuvR//euf52tUlaAvE2/aEehY5Ezb+ PaZ8fKgH71BST/r3exNKKv7BOWkQkcyBXeFhOkPuaToEOX17UoHisJdDrdxx/tAk AeZAAGvJSYeEt57HzObCbeS/OEZ+cCfnJu4s+zmuSiXImWkbyYV04xLTmLxzE+oP NvsU1+XAno8as7nylz5U =DLam -END PGP SIGNATURE- -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] F21 Alpha Docker base image release
On 2.10.2014 00:03, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 01 Oct 2014 09:56:32 +0200 Václav Pavlín vpav...@redhat.com wrote: Hi, Dennis, could you please build Alpha base image with updated bash? (And probably also prepare F20 and Rawhide images so that we can really call the Fedora image official with all it's tags? There is no looking back Alpha is done, Beta TC1 is out the door, though the docker image is missing with kokji down I can not see why it failed to compose. We can not go back. Fedora 20 will never have official docker images and we produce branched and rawhide images nightly. so there is plenty of newer images available not sure what you mean by with all it's tags? I probably don't understand - why is it impossible to build F20 image? By with all it's tags I mean so that we can have fedora:20, fedora:21 and fedora:rawhide in Docker Hub We should probably also consider using Fedora Cloud SIG account on github to push these image to Docker Automated builds - it would probably look better then using Lokesh's account (no offence:) ). hithub is not an acceptable medium to use for Fedora release engineering. as I understand it docker do not care where it is hosted so long as things are in git that they can pull from. so we will use fedorahosted. Right, I haven't realized we can use any git - fedorahosted is definitely the correct place in this case. The *interim* workflow for uploading official Fedora image to Docker Hub would be: 1. Download tar.gz and ks from Koji 2. Unpack 3. Compress layer.tar as xz not acceptable. if we must use different compression we will adjust koji to compress things differently. we do not do manipulation of the deliverables, we take them as they come out. The problem is that we have image with metadata . ├── repositories └── 20bb2f8f723c9244e8c7f5b09edbbadff5dfa38c2e4165d3cfdb19ba6a2d1a6e ├── json ├── *layer.tar* └── VERSION And what we need to provide to Docker Automated builds is only the file layer.tar 4. Upload Dockerfile, ks and *.tar.xz to Fedora Cloud SIG github repository (same as releng will upload to fedorahosted. https://github.com/lsm5/docker-brew-fedora/tree/21) 5. Update https://github.com/docker-library/official-images/blob/master/library/fedora I agree with Matt we should ship what we have and follow up with Docker on enablement of import for our images (containing metadata) built in Koji. I am all for shipping what we have. we need to work out how to actually do it. Does this make sense to you? If there will be no objections, could we vote? - -1 for your proposal as is. Lokesh, would you like to continue to maintain the process of getting Fedora Docker base images to the audience? Thanks regards, Vašek -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJULHotAAoJEH7ltONmPFDRWI4P+wf14y47GL+yVeCvdVm9iqWl uxIqZrKyxjtRn8s7aDFyGKBf92WinVtP8rZrpvtA3Kmb4prJ/0vT64JxxLhwR6rM jg4s8FaqdM7JJtIHzkowWGTxU45pNo2mv1CJ3i6z4Wx3pXMRs4uaY1SZUxoObgS4 O7qbm7qWL6Moh/ybCJ0IFgqKxVq5vF9U/vJLA07otoGZuD75RZ5+OcStokgH7HmJ zJSqSVFa8iuDAIPjvI4rK6PA9Dm/iMYPMYJ8Cl1XcU4xBOe1F18nOyWHZH4TxKvX zYUEFP6oF9GVmzny0+0cY3XQ7q4JWK8i0GkTr1Q9uZyEGT9Li992dmud8IUKE6Y5 dte0bahC+LjQrGfG/YsAMfzOtggoIhANm/fjNxsPZyYV7n6dJ8fieM0x1ZJhNdBM fIzeHFS/SaILmFGcEeD8ZFkXlp8kbHoYkP30u0mtDmovOXwqbbyhri7tgoZBKgUc bjAKwFQ/IlPsfyzJaQnSzK5DVOfkb3oD2EdkM3uTd2qOR3alRiPxm5UYNdx5NEbE SMo/dcYBPcs8ly+iLzyDY2dtkL9lGM/ZXARgrLYWGVWY5GiERLI9CeCiMaw9ukgY WRoGjGZzVL/kBg4iz7BU69mbNniwcSXOtxklKWkAlVRzrWW/QPqmrJLLCf8RJUPg /L8NZ1S02hNRjoi6TesD =KnPu -END PGP SIGNATURE- -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] F21 Alpha Docker base image release
Hi, Dennis, could you please build Alpha base image with updated bash? (And probably also prepare F20 and Rawhide images so that we can really call the Fedora image official with all it's tags?) We should probably also consider using Fedora Cloud SIG account on github to push these image to Docker Automated builds - it would probably look better then using Lokesh's account (no offence:) ). The *interim* workflow for uploading official Fedora image to Docker Hub would be: 1. Download tar.gz and ks from Koji 2. Unpack 3. Compress layer.tar as xz 4. Upload Dockerfile, ks and *.tar.xz to Fedora Cloud SIG github repository (same as https://github.com/lsm5/docker-brew-fedora/tree/21) 5. Update https://github.com/docker-library/official-images/blob/master/library/fedora I agree with Matt we should ship what we have and follow up with Docker on enablement of import for our images (containing metadata) built in Koji. Does this make sense to you? If there will be no objections, could we vote? Lokesh, would you like to continue to maintain the process of getting Fedora Docker base images to the audience? Thanks regards, Vašek -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 26 September 2014 15:00 UTC on #fedora-meeting
Hey, So to follow on the topic of publishing F21 Alpha base image... I talked to Tianon from Docker today on IRC and our current output of build in Koji is not acceptable as input for their official images repo - they use Dockerfiles to build even base images - input is a Dockerfile and tarred rootfs without metadata. Problem is that our Koji image already has metadata and is already a proper Docker image. We could configure Image Factory to produce just rootfs tar, but then we wouldn't be able to track the images. Current output of Koji enables us to track the image back to every RPM package included into it by the image ID. Tianon also mentioned future feature which would support signed images - we would probably want to produce such signed image by ourselves, not just give Docker rootfs and let them sign it. He said it's valid use case and he will try to think of a way how to improve Docker Hub's Automated Builds to support import of proper image and not just tarred rootfs. We could still publish F21 Alpha image - it would just require some manual work and the result would not share the ID generated by Koji. Regards, Vašek On 26.9.2014 12:13, Václav Pavlín wrote: On 26.9.2014 11:41, Phil Knirsch wrote: Agenda: - Introduction David Sommerseth, taking over buildrequires cleanup work from Benedikt - Discussion: Sharing alpha base image on Docker Hub I am not sure if I will make it to the meeting so I'll comment here. Matt asked if we are going to push Alpha base image to Docker Hub and I think there is no reason why we shouldn't. From [1] I guess Lokesh is the one who deals with Fedora images - is that true, Lokesh? Could you, Dennis and Lokesh, work together to get F21 Alpha image on Docker Hub? Let me know if I can be any help! [1] https://github.com/docker-library/official-images/blob/master/library/fedora Thanks, Vašek - Open Floor Thanks regards, Phil -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 26 September 2014 15:00 UTC on #fedora-meeting
On 26.9.2014 11:41, Phil Knirsch wrote: Agenda: - Introduction David Sommerseth, taking over buildrequires cleanup work from Benedikt - Discussion: Sharing alpha base image on Docker Hub I am not sure if I will make it to the meeting so I'll comment here. Matt asked if we are going to push Alpha base image to Docker Hub and I think there is no reason why we shouldn't. From [1] I guess Lokesh is the one who deals with Fedora images - is that true, Lokesh? Could you, Dennis and Lokesh, work together to get F21 Alpha image on Docker Hub? Let me know if I can be any help! [1] https://github.com/docker-library/official-images/blob/master/library/fedora Thanks, Vašek - Open Floor Thanks regards, Phil -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Potential cancel of Base Design WG agenda meeting 19 September 2014 15:00 UTC on #fedora-meeting
I am not really on vacation, but WiFi on the Prague airport sucks so +1 from me for canceling. Vašek On 19.9.2014 16:04, Michal Sekletar wrote: On Fri, Sep 19, 2014 at 02:58:00PM +0200, Phil Knirsch wrote: Hi everyone. Hey Phil, As i'm not feeling well at all i won't be able to make it to our regular meeting today. With Harald and vpavlin both on vacation I am up for canceling today's meeting for good. Regards, Michal So if any of you want to do run it feel free to do so, but i won't be able to attend. And sorry for the late notice. Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Terminology for docker/atomic images
On 8.9.2014 16:03, Dusty Mabe wrote: On Mon, Sep 08, 2014 at 09:29:12AM -0400, Colin Walters wrote: On Sun, Sep 7, 2014, at 11:22 PM, Dusty Mabe wrote: In a nutshell, it would be great if we added Container to references we make to the container image (in conversation and docs). I tend to say Docker Base Image - that's the terminology upstream Docker uses: https://docs.docker.com/articles/baseimages/ I think in the context of Docker, i.e. when you already know you are talking about the Docker daemon and Docker containers, then Docker Base Image is clear enough. I think when you don't have that context to begin with and you hear Docker Base Image then it is not so clear. I'm fine with incorporating their terminology so we can be more clear though: Docker Container Base Image ? Unfortunately we have to balance clarity with convenience. The longer it gets the more people won't like it so that is something to consider. Dusty I agree with Colin - Docker Base Image is what we should use when talking about Docker images which are then used in Docker Layered Images as a base layer on top of which you can build. Please don't make the terminology too complicated. If you are in context of Docker you can safely use Base Image and Layered Image. If you talk in general, adding Docker will bring you to the right namespace. Do we need a documentation of this somewhere on Fedora Wiki? Vašek -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: fakesystemd package breaking builds
Hi, There is new fakesystemd build for F21 which should fix the breakage, sorry. Vaclav On St 27. srpen 2014, 15:23:27 CEST, Jerry Vonau wrote: On August 27, 2014 at 7:28 AM Rex Dieter rdie...@math.unl.edu wrote: Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802 That has a sub-build[1] that is failing but for a different reason: Error: Package: harfbuzz-icu-0.9.35-2.fc22.x86_64 (build) Requires: libicuuc.so.52()(64bit) Might be fallout from the gcc mass rebuild. I don't see where fakesystemd is being pulled into the buildroot[2], can you point that out for me? Jerry 1. https://koji.fedoraproject.org/koji/taskinfo?taskID=7453378 2. https://kojipkgs.fedoraproject.org//work/tasks/3378/7453378/root.log -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: fakesystemd package breaking builds
Hi Lennart, It's a package that fakes systemd presence in system. It's solely intended for Docker images as we don't want systemd there (at least as long as it takes to prepare systemd-container Michal is working on). I made a mistake and it ended up being pulled in buildroot. Ping me on IRC if you have more questions or comments. Vasek On St 27. srpen 2014, 20:16:20 CEST, Lennart Poettering wrote: On Wed, 27.08.14 07:28, Rex Dieter (rdie...@math.unl.edu) wrote: Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802 (which is no direct systemd dependencies, mind you) I can guess why this fakesystemd package came into existence, but I question the wisdom behind it's implementation. As far as I can tell, it contains only: Provides: systemd (and a few other systemd-related dependencies) What is fakesystemd supposed to be? Wouldn't it be a good idea to pass such things by me or so before introducing this? I mean, people are welcome to ignore me, but it would be nice to at least inform me about this... There was already a systemd-mini, and now a fakesystemd, I mean, what is this all about? Anyone? Lennart -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: fakesystemd package breaking builds
On St 27. srpen 2014, 20:27:51 CEST, Lennart Poettering wrote: On Wed, 27.08.14 20:20, Václav Pavlín (vpav...@redhat.com) wrote: Heya, It's a package that fakes systemd presence in system. It's solely intended for Docker images as we don't want systemd there (at least as long as it takes to prepare systemd-container Michal is working on). I made a mistake and it ended up being pulled in buildroot. Ping me on IRC if you have more questions or comments. So what is systemd-container supposed to do? And what precisely is fakesystemd supposed to do? And that mini thing? fakesystemd owns same directories systemd does and has set provides to fulfill most RPM dependencies for systemd. For example you want to run httpd in your Docker container which brings systemd, devicemapper, kmod... in. If the base image contains fakesystemd none of these dependencies is installed. If you really need systemd in you container you can use following command: yum swap -- remove fakesystemd -- install systemd systemd-libs systemd-container (I think it's the same thing you refer to as mini) should remove dependencies which does not make sense in container (again devicemapper, kmod...) and hwdb and should run as init in multi-service containers. Well I am not sure if it ends up being really systemd-container or simply fixed systemd. If I am not mistaken this was second topic for last Base WG meeting which we didn't get to:) So hopefully this week? Vasek This sounds all very much not thought to the end. Can you please explain what these packages precisely do, and why they exist? Lennart -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: fakesystemd package breaking builds
On St 27. srpen 2014, 20:47:33 CEST, Lennart Poettering wrote: On Wed, 27.08.14 20:35, Václav Pavlín (vpav...@redhat.com) wrote: So what is systemd-container supposed to do? And what precisely is fakesystemd supposed to do? And that mini thing? fakesystemd owns same directories systemd does and has set provides to fulfill most RPM dependencies for systemd. For example you want to run httpd in your Docker container which brings systemd, devicemapper, kmod... in. If the base image contains fakesystemd none of these dependencies is installed. If you really need systemd in you container you can use following command: yum swap -- remove fakesystemd -- install systemd systemd-libs systemd-container (I think it's the same thing you refer to as mini) should remove dependencies which does not make sense in container (again devicemapper, kmod...) and hwdb and should run as init in multi-service containers. Well I am not sure if it ends up being really systemd-container or simply fixed systemd. If I am not mistaken this was second topic for last Base WG meeting which we didn't get to:) So hopefully this week? I am not on the base WG. I was not selected for it. If you come up with schemes like this, it is really a good idea to actually ask the people who work on the package you are trying to work on or work around... Well you was very helpful on last meeting and I guess you'll be invited to the next one as systemd should be on the plate again. Can we please do this stuff more systematically? I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that... Talk to Michal Sekletar about it then - he is working on something we call systemd-container internally. We need systemd running in Docker container. I don't like to have needless stuff in images but if the result is just drop the hwdb then I am fine with that. But regarding kmod/devicemapper, can we please get some stats about how big this individually are, and how much is saved by this? kmod at least is 150K or so only. Is there really any value in doing this weird stuff for a fricking 150K?! Fedora has no bigger fishes to fry? I'll prepare stats for you tomorrow. The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we please always discuss this first, and see if we can find a different solution? We don't need three different solutions, if one works too... We've talked about this on Flock - it's not only about disk space but also about security reasons (CC'ing Dan Walsh). My goal was not to have needless junk in base image - if we are not going to use systemd to manage services there, why should it be there with all it's dependencies? Vasek Lennart -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 25 July 2014 15:00 UTC on #fedora-meeting
WRT discussion on the WG meeting about adding systemd to comps to block fakesystemd [1] installation to real OS - systemd is in @core group since F14 [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1118740 [2] https://git.fedorahosted.org/cgit/comps.git/commit/?id=4e79f60c30b1cb6db55b11def06bd4b5e7e492f7 Regards, Vaclav On Pá 25. červenec 2014, 15:06:11 CEST, Václav Pavlín wrote: Thanks Matt, I was going ask for discussion about this for today's meeting. On Pá 25. červenec 2014, 14:57:53 CEST, Matthew Miller wrote: On Fri, Jul 25, 2014 at 01:25:12PM +0200, Phil Knirsch wrote: Agenda: - Status update builrequires cleanup - Really talk with Vaclav Pavlin as candidate for WG :) - Open floor I saw in the Env Stacks minutes the suggestion that the Base WG should produce the Docker base image. If that's not agreed on by both sides let's figure that out rather than making it a hot potato. I may or may not be online during the meeting, so throwing this out now. :) -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] Base Design WG agenda meeting 25 July 2014 15:00 UTC on #fedora-meeting
Thanks Matt, I was going ask for discussion about this for today's meeting. On Pá 25. červenec 2014, 14:57:53 CEST, Matthew Miller wrote: On Fri, Jul 25, 2014 at 01:25:12PM +0200, Phil Knirsch wrote: Agenda: - Status update builrequires cleanup - Really talk with Vaclav Pavlin as candidate for WG :) - Open floor I saw in the Env Stacks minutes the suggestion that the Base WG should produce the Docker base image. If that's not agreed on by both sides let's figure that out rather than making it a hot potato. I may or may not be online during the meeting, so throwing this out now. :) -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- 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: [Base] The Base Design WG is looking for a new committee member!
On 27.6.2014 18:13, Phil Knirsch wrote: Hi everyone. As Bill Nottingham has decided to resign from the committee we now have a free seat that we'd like to fill with another person. In order to fill this seat i'm therefore reaching out here to Fedora development to offer allow any applicant from the community to get in touch with us and let us know you're interested, why you're interested, why you think you'd be a good fit and maybe even the things you'd like to drive or accomplish in the Base Design WG. For more background on what the Base WG does, here our Fedora wiki: https://fedoraproject.org/wiki/Base In order to contact us you can either reply directly to me or join us during our regular meetings each Friday at 15:00 UTC on #fedora-meeting. I strongly suspect next weeks meeting will be canceled due to the US holiday, but after that we'll be doing weekly meetings again. Looking forward to see you there! Thanks regards, Phil Hi all, I decided to sign up for the seat in Base Working Group. To introduce myself - I work for Red Hat for two years and during that time I moved from grub1 maintainer to systemd and initscripts co-maintainer to someone who maintains and defines Docker base images. Apart from that I am responsible for distribution bugs and there is some more stuff on my plate. As the WG member I would like to contribute to discussions around Docker and build-req minimization. I've already worked on Fedora base images a bit and you can see the results here: http://vpavlin.fedorapeople.org/fedora-base-image/ But as Fedora isn't only about Docker (luckily) I'd like to also help with defining what *base* really mean in Fedora and how to integrate it with other WGs' work. I am already member of Environment Stack WG so I'd like to use this opportunity to become a binding element of these groups. Thanks regards, Vaclav Pavlin -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes from Env-and-Stacks WG meeting (2014-07-08)
#fedora-meeting: Env and Stacks (2014-07-08) Meeting started by mmaslano at 12:00:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-07-08/env-and-stacks.2014-07-08-12.00.log.html . Meeting summary --- * init process (mmaslano, 12:02:24) * docker plans (mmaslano, 12:05:59) * vpavlin will take a look at current Fedora images and try to minimize them as much as possible. (mmaslano, 12:07:42) * LINK: https://registry.hub.docker.com/u/juhp/fedora-haskell-ghc/ (juhp_, 12:17:53) * vpavlin will ask scollier to cooperate on Fedora Dockerfiles with WG (vpavlin, 12:24:25) * LINK: https://github.com/fedora-cloud/Fedora-Dockerfiles/wiki/Guidelines-for-Creating-Dockerfiles (juhp_, 12:30:40) * vpavlin to check with other WGs about their Docker plans (vpavlin, 12:43:29) * sicampbell will take a look at Docker integration with copr (vpavlin, 12:48:08) * Tasklist (vpavlin, 12:51:04) * vpavlin to add tasks related to Docker to tasklist (vpavlin, 12:54:59) Meeting ended at 12:56:30 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * vpavlin (44) * mmaslano (32) * sicampbell (13) * juhp_ (10) * zodbot (5) * jreznik (5) * bkabrda (4) * sgallagh (2) * pingou (1) * samkottler (0) * tjanez (0) * juhp (0) * sic (0) * hhorak (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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: free seats in Env and Stacks WG - volunteers wanted
On Út 1. červenec 2014, 11:31:35 CEST, Marcela Maslanova wrote: Env and Stacks Working Group has noble plan to make development in Fedora easier and also work with new technologies, which are not in Fedora yet. The whole statement can be found here: https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document There is missing Atomic and/or Docker, because all members were mostly interested in things mentioned in the document than looking at containers. I believe we need someone who can pick what will be in Fedora base image. Details can be found in Matt statement: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-June/000431.html We don't have manpower to work on all projects, but we started to work or co-operate on these: 1/ testing additional repositories – Playground repo https://fedoraproject.org/wiki/Changes/Playground_repository Playground plugin is similar to Copr plugin http://dnf.baseurl.org/2014/03/19/copr-plugin/ 2/ automation – Automated packages review tools https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Automated_packages_review_tools 3/ automation – Taskotron tool for Fedora tests https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan 4/ Build Systems – Copr http://copr.fedoraproject.org/ 5/ Software Collections in Fedora https://fedoraproject.org/wiki/Changes/SCL 6/ DevAssistant http://devassistant.org/ 7/ Continuous Integration - prototype of few projects If you are interested in current topics or containers, then please let us know on env-and-sta...@lists.fedoraproject.org what you want to do and what you did until now. I received some private replies, but I'd like to give opportunity to wider audience. Thanks, Marcela ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks Hi, I would like to sign up for one of these seats. I am already working with Docker and Docker images - I define and maintain RHEL Docker base images, thus I think I could help with these tasks in Fedora as well. When base images are ready, I'd like to concentrate on building layered images in Copr, which, in my opinion, would help Fedora QA with automation of image testing. Regards, Vaclav Pavlin -- Lead Infrastructure Engineer Developer Experience Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
Hi, With current changes in Fedora regarding Fedora.next and productization of Fedora distribution I would like to suggest following change. Package systemd ships file 90-default.preset [1] (full path: /usr/lib/systemd/system-preset/90-default.preset) which contains rules for command 'systemctl preset NAME'. This command enables/disables the unit represented by NAME based on the entry in preset file. File 90-default.preset for example contains line 'enable sshd.service' which enables sshd when command mentioned above is called (mostly from rpm macro %systemd_post [1]). Currently this file is part of systemd package which doesn't seem to be right. It contains default values specific for distribution, is not part of systemd upstream repository and is maintained downstream. Based on these arguments, I'd like to propose to move this file to the fedora-release package (or elsewhere, if you can suggest better place). This package is specific to Fedora distribution as well and contains Fedora specific configuration files (i.e. Fedora repo files). The question of moving the file somewhere else than systemd might be really interesting for working groups either. It defines which services should be enabled by default after installation, which might differ for different products. (Or not, has anybody thought about this yet?) An example off top of my head - we would like to have sshd enabled after installation by default on server, but disabled on workstation. I would like to ask release engineering for any feedback and representatives of working groups to discuss this on their meetings. Thanks Regards, Vaclav Pavlin [1] http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset [2] http://cgit.freedesktop.org/systemd/systemd/tree/src/core/macros.systemd.in -- 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: ABRT in the comps group 'standard'
On 6.12.2013 10:56, Jakub Filak wrote: I'd like to add abrt-cli package to the comps group 'standard'. Regarding the discussion, there are two main concernes about adding abrt-cli to Standard comps group: 1) There will be some notifications popping up which can confuse users. Not true. Nothing changes for desktop environments. Package abrt-desktop is already part of GNOME and Cinnamon comps groups. What we are talking about here is abrt-cli [1] - command line interface, which will let users to list, review and report crashes on their systems caught by abrt. Root is informed about crashes by email, normal users should not be affected. 2) Abrt is sending information by default without opt-in. Not true. Abrt only stores crash details localy unless user calls 'abrt-cli report' command, or enables uReports [2]. Abrt actually helps to find and solve problems [3] so we decided to add abrt-cli to Standard comps group for F21. Regards, Vaclav [1] http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/System_Administrators_Guide/sect-abrt-cli.html [2] https://github.com/abrt/faf/wiki/uReport [3] https://bugzilla.redhat.com/show_bug.cgi?id=1036959 -- 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: ABRT in the comps group 'standard'
On Pá 6. prosinec 2013, 12:39:09 CET, Miroslav Suchý wrote: On 12/06/2013 12:14 PM, Jóhann B. Guðmundsson wrote: I would say that abrt should not be installed et all unless user has agreed to it at install time. I think abrt serves as good source of info in case of unexpected crashes, which is quite important to have stable system. So although being puzzled is not very nice, being disappointed by crashing applications is much worse from my point of view. So try to look at it from broader perspective - I see more benefits in having abrt installed. +1 My mother would be puzzled, if ABRT would popup on her Fedora box. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
