May 2016 - rel-eng - Fedora Mailing-Lists

by Fedora Release Engineering

rel-eng: 您好 1.如何预防劳动者的“应聘欺诈”，如何证明劳动者的“欺诈”？ 2.招收应届毕业生，应注意哪些细节问题？ 3.招用达到法定退休年龄的人员，应注意哪些细节问题？ 4.招用待岗、内退、停薪留职的人员，应注意哪些细节问题？ 5.入职体检需注意哪些细节问题？ 6.入职前后用人单位应告知劳动者哪些情况，如何保留证据？ 7.《入职登记表》如何设计，才能起到预防法律风险的作用？ 8.劳动者无法提交《离职证明》，该怎么办？ 9.企业如何书写《录用通知书》，其法律风险有哪些？附件中的内容希望能帮助到您的工作。。。莫等闲，白了少年头，空悲切。宋·岳飞《满江红》 2016/5/12 星期四0:21:32 律向菱

7 years, 11 months

1
0
0 / 0

#6402: Bodhi is ignoring epoch

by Fedora Release Engineering

#6402: Bodhi is ignoring epoch -----------------------------+------------------------ Reporter: jussilehtola | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Final | Component: mash Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Problem: bodhi seems to be ignoring epoch in the determination of obsolete updates. Full description: There's an issue with segfaults in epson-inkjet-printer-escpr version 1.6.4. I updated the package to 1.6.5, and pushed out the update epson- inkjet-printer-escpr-1.6.5-1.1lsb3.2. However, I noticed that the file that was causing the crash had not been changed from 1.6.4 to 1.6.5. So, I introduced Epoch 1, rolled back the package to the 1.5.2 version, and pushed out the resulting epson-inkjet- printer-escpr-1.5.2-3.1lsb3.2 as updates. However, bodhi has marked the latter update, epson-inkjet-printer- escpr-1.5.2-3.1lsb3.2 (epoch 1), as being obsoleted by epson-inkjet- printer-escpr-1.6.5-1.1lsb3.2 (epoch 0). This should not happen, because 1:1.5.2-3.1lsb3.2 is newer than 0:1.6.5-1.1lsb3.2. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6402> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
4
0 / 0

#6413: It's Atomic Host, not Atomic

by Fedora Release Engineering

#6413: It's Atomic Host, not Atomic -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ In the cases where we're talking about "Atomic Host", please rename the file name from just "Atomic" to "AtomicHost" (if the filename can't contain spaces). -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6413> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
2
0 / 0

comps and spin-kickstarts migration this friday (2016-05-13)

by Kevin Fenzi

Greetings. This friday (2016-05-13) at 16UTC we will be migrating: https://fedorahosted.org/comps/ https://fedorahosted.org/spin-kickstarts/ to https://pagure.io/fedora-comps/ https://pagure.io/fedora-kickstarts/ With this migration we will be changing the workflow for changes to these repositories from a simple commit model to a pull request model. This means in order to make some change you should submit a pull request, which will be reviewed by at least one other person and then pushed live into the repo. Initially commit on these new repos will be set to the pagure releng group, but more people will be added as needed. This model will allow us to run CI tests on Pull Requests and confirm that they are not going to cause syntax errors or other simple breakage. Additionally, this will allow us to properly handle changes to these repos during milestone Freezes (getting approval for a freeze break before pushing changes, etc). With the migration of the fedora-kickstarts project we will also be trying to identify owner(s) for each kickstart file. This will allow us to properly assign issues to the folks that can address them. Thanks, kevin

7 years, 11 months

1
0
0 / 0

[Fedocal] Reminder meeting : Fedora Release Engineering

by Dennis Gilmore

Dear all, You are kindly invited to the meeting: Fedora Release Engineering on 2016-05-09 from 10:30:00 to 11:30:00 US/Central At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Fedora Release Engineering weekly meeting Source: https://apps.fedoraproject.org/calendar/meeting/2026/

7 years, 11 months

2
1
0 / 0

Fedora Docker Registry Proposal

by Adam Miller

Hello all, I have been working on a proposal on how to handle Fedora's Docker Registry requirements to deliver our future "docker-ized" content to users in a way that won't leave us with a bottleneck to the user community hitting a single download location. Below you will find that proposal and I would greatly appreciate feedback. The good news is I did a small PoC of the plan I would like to propose along with the workflow (simulating some steps in the process for brevity), and it all worked! The potentially bad news is that this introduces a reasonable amount of net-new services inside the Fedora Infrastructure. I wanted to sanity-check this proposal with the Rel-Eng crew and then send to the Infrastructure Team for feedback and advisement after I'm sure this makes sense to everyone from a rel-eng perspective. Thank you all in advance. Quick vocab background for Docker stuff: registry: a collection of docker image repositories repository: named after an image and is a collection of multiple tags of an that image tag: an arbitrary string assigned to a specific docker image (identified by the image's sha256 checksum) NOTE: The "latest" tag is special and is assumed if no tag is provided. This is true also for a 'docker pull' operation and an image tagged "latest" will be the default image pulled by users. Proposal: Pulp[0] + Crane[1] + MirrorManager[2] + Docker Distribution[3] Pulp is a platform for managing repositories of content, such as software packages, and making it available to a large numbers of consumers. It is also capable of managing docker content. Crane is a stand-alone python flask wsgi application written by the Pulp team to serve as a API entry point for the docker client and will answer to an user's 'docker pull'. It does not however create content manifests or provide hosting for docker image content, instead it depends on someone creating the manifest metadata themselves or having pulp publish it and serves 302 redirects to the docker client so they can find where the docker images actually live. I'll assume everyone here knows their way around MirrorManager. Docker Distribution is the defacto standard open source implementation of the Docker Registry V2 API spec[4]. It provides many features but the ability to have it's back-end storage be provided by a "mirror network" much like the one Fedora has at it's disposal is not one of them. The reason we need this in place is because the mechanism by which you could push a docker image directly to Pulp in Docker Registry v1 no longer exists in v2 so we must instead perform a "sync" operation between the two. (This is a common problem for all known "third party" v2 registry implementations). Workflow: OSBS will perform Builds, as these builds complete they will be pushed to the docker-distribution (v2) registry, these will be considered "candidate images". Pulp will sync and publish the candidate repository. Testing will occur using the "candidate images" (details of how we want to handle that are outside the scope of this proposal). A "candidate image" will be marked stable once it's criteria have been satisfied to do so. (This is vague because this is a topic of ongoing discussion and work to decide what criteria an image will need to abide by before being considered "stable" and promoted as such) Once stable, pulp will publish that repository's content to a directory, we will split that content and sync the image layers along with their metadata to Mirror Manager master mirror. We will also sync the repo metadata published by Pulp to somewhere Crane can pick it up. (This could and will likely be something that Bodhi triggers via the Pulp REST API) Mirror Manager will Pulp distribute to the mirrors the image layers and their metadata. Crane will get the new repository metadata and will serve redirects to the new content relative to download.fedoraproject.org which will perform another redirect (via MirrorManager) where the docker client upon a "docker pull" will find it's content. I have put together an ascii diagram in hopes that it will assist in seeing the full picture. https://maxamillion.fedorapeople.org/FedoraPulpDocker.txt (I couldn't get it to paste cleanly into my email client) If there are any questions, comments, or feedback please let me know. Thank you, -AdamM [0] - http://www.pulpproject.org/ [1] - https://github.com/pulp/crane [2] - https://github.com/fedora-infra/mirrormanager2/ [3] - https://github.com/docker/distribution/ [4] - https://docs.docker.com/registry/spec/api/

7 years, 11 months

6
8
0 / 0

Beat all the s'e_xual records with our new size

by Fedora Release Engineering

peyote meetings.with a fresh and clear air. Exhausted by the long crossing, they hung laughed shyly. Each one of them introduced himself. I talked with them for hours about everything except thebecause the strip that they were opening as they went along would We are here to bring you something wonderful! You never supposed that some medicine could make feel so sure in bed. Choose Dr.Maxman, that will start a new wave of your s'e_xual pleasure. Your dick will be leader of the world! Rely upon this wonder-medicine and you will be so surprised with your size! laughed shyly. Each one of them introduced himself. I talked with them for hours about everything except thebecause the strip that they were opening as they went along would

7 years, 11 months

1
0
0 / 0

Re: #5886: need method for distributing urgent fixes... urgently

by Fedora Release Engineering

#5886: need method for distributing urgent fixes... urgently ------------------------------+------------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 23 Alpha | Component: mash Resolution: | Keywords: meeting planning Blocked By: | Blocking: ------------------------------+------------------------------ Comment (by kevin): There were some patches to createrepo that allowed for parallel drpm generation, but I don't think we ever got them working right and/or enabled them. Perhaps we could engage with createrepo/createrepo_c upstream and see what they can do there? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5886#comment:41> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
0
0 / 0

#6405: Create Fedora 24 Beta candidates

by Fedora Release Engineering

#6405: Create Fedora 24 Beta candidates ----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ We now need a Beta candidate build. This should fix all outstanding blocker bugs and thus is a 'release candidate' build. Please include: * [https://bodhi.fedoraproject.org/updates/kernel-4.5.2-302.fc24 kernel-4.5.2-302.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1321330 #1321330] * [https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f7048425f libhif-0.2.2-3.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1259865 #1259865] * [https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5 java-1.8.0-openjdk-1.8.0.91-2.b14.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1329342 #1329342] (FE) * [https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f939ef633 firefox-46.0-4.fc24] for [https://bugzilla.redhat.com/show_bug.cgi?id=1315225 #1315225] (FE) Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6405> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
10
0 / 0

Re: #5886: need method for distributing urgent fixes... urgently

by Fedora Release Engineering

#5886: need method for distributing urgent fixes... urgently ------------------------------+------------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 23 Alpha | Component: mash Resolution: | Keywords: meeting planning Blocked By: | Blocking: ------------------------------+------------------------------ Comment (by ausil): I would rather we pursue a course of action that results in deltas not going away. we will never get the deltas back when they get temporarily disabled. the cached deltas will go away. I think the only viable option will be an out of band repo. The oout of band repo generations will also be much faster as it will be really small. Without major work in redesigning tools and workflows we can not do the delta generation in an asynchronous way. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5886#comment:40> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng May 2016