How to package a Git repository
I would like to build (S)RPMs directly from a Git repository (which contains the .spec file in the top-level directory). This is for a CI-style project, with a quick release cycle. I have a Lua script fragment which generates a proper SRPM with the mock-scm target in COPR, and which is also compatible with “fedpkg srpm”. But rpmbuild strips leading path components from Source: and Patch: references, so this only works if all files are in a single directory. Are there any alternatives that work in COPR, EPEL and Fedora proper? I think it's strange that I have to put a tarball somewhere just for RPM's sake if there is no separate upstream, and there are no upstream releases as a result. It's just an annoyance and yet another step that can go wrong in various ways. Thanks, Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Review request: perl-Path-Iterator-Rule, perl-Number-Range
Hi I need the following packages reviewed to update licensecheck and perl-String-Copyright: perl-Path-Iterator-Rule - https://bugzilla.redhat.com/show_bug.cgi?id=1373244 perl-Number-Range - https://bugzilla.redhat.com/show_bug.cgi?id=1374642 Happy to review in exchange. Sandro -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review request: perl-Path-Iterator-Rule, perl-Number-Range
Il 09/09/2016 11:46, Sandro Mani ha scritto: Hi I need the following packages reviewed to update licensecheck and perl-String-Copyright: perl-Path-Iterator-Rule - https://bugzilla.redhat.com/show_bug.cgi?id=1373244 perl-Number-Range - https://bugzilla.redhat.com/show_bug.cgi?id=1374642 hi take! for now I have nothing to be reviewed urgently (maybe only after https://bugzilla.redhat.com/show_bug.cgi?id=1366843 ) if there is someone who needs it i leave these regards .g Happy to review in exchange. Sandro -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
In DNF CI we use rpm-gitoverlay[0], but due to RPM we have to prepare archive from git, replace path for %(auto)setup, and some other magic, so you can't use it as is in Fedora. But you can easily use it with COPR as you don't have to follow all guidelines. When I deal with one project I just do: $ rpm-gitoverlay build-package -n libdnf rpm copr --owner ignatenkobrain --project libdnf which does everything for me. [0] https://github.com/ignatenkobrain/rpm-gitoverlay On Fri, Sep 9, 2016 at 11:25 AM, Florian Weimer wrote: > I would like to build (S)RPMs directly from a Git repository (which contains > the .spec file in the top-level directory). This is for a CI-style project, > with a quick release cycle. > > I have a Lua script fragment which generates a proper SRPM with the mock-scm > target in COPR, and which is also compatible with “fedpkg srpm”. But > rpmbuild strips leading path components from Source: and Patch: references, > so this only works if all files are in a single directory. > > Are there any alternatives that work in COPR, EPEL and Fedora proper? > > I think it's strange that I have to put a tarball somewhere just for RPM's > sake if there is no separate upstream, and there are no upstream releases as > a result. It's just an annoyance and yet another step that can go wrong in > various ways. > > Thanks, > Florian > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Versioning the Packaging Guidelines
Dear list, There is an ongoing thread in debian-devel on their Standards-Version usage. Reading this, it strikes me that Fedora lacks this info. The basic package lifecycle is that it is reviewed to current standards, and after that start lagging from the actual standards. To which extent depends on the maintainer. Debian addresses this by actually versioning their guidelines, and tracking the last version checked in the package. There are checklists how to update between each version of the standard. Could we learn anything from this? Fedora is not a rolling distribution, but the guidelines are. Would it be a good idea to actually provide versions of the guidelines? To track the last version checked in the packages? If not for anything else., it would certainly make the life of fedora-review maintainers easier. That said, I'm turning a blind eye to the obvious technical hassles versioning a wiki. Just my 5 öre --alec -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Versioning the Packaging Guidelines
Il 09/09/2016 14:13, Alec Leamas ha scritto: Dear list, There is an ongoing thread in debian-devel on their Standards-Version usage. Reading this, it strikes me that Fedora lacks this info. The basic package lifecycle is that it is reviewed to current standards, and after that start lagging from the actual standards. To which extent depends on the maintainer. Debian addresses this by actually versioning their guidelines, and tracking the last version checked in the package. There are checklists how to update between each version of the standard. Could we learn anything from this? Fedora is not a rolling distribution, but the guidelines are. Would it be a good idea to actually provide versions of the guidelines? To track the last version checked in the packages? If not for anything else., it would certainly make the life of fedora-review maintainers easier. hi to me it seems the opposite ... regards .g That said, I'm turning a blind eye to the obvious technical hassles versioning a wiki. Just my 5 öre --alec -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Versioning the Packaging Guidelines
On Fri, Sep 9, 2016 at 8:13 AM, Alec Leamas wrote: > Dear list, > > > There is an ongoing thread in debian-devel on their Standards-Version usage. > Reading this, it strikes me that Fedora lacks this info. > > The basic package lifecycle is that it is reviewed to current standards, and > after that start lagging from the actual standards. To which extent depends > on the maintainer. Correct. And the lag is really kind of the hard part. To my knowledge, there is still no group that actively reviews already approved package for continued adherence to any version of the guidelines. There are good reasons for this, mostly stemming from lack of review resources to begin with, but that means a review is a one-time event for the bulk of the packages in Fedora. > Debian addresses this by actually versioning their guidelines, and tracking > the last version checked in the package. There are checklists how to update > between each version of the standard. > > Could we learn anything from this? Fedora is not a rolling distribution, but > the guidelines are. Would it be a good idea to actually provide versions of > the guidelines? To track the last version checked in the packages? I think these are ideas worth discussing, but you should probably discuss them with the FPC directly. > If not for anything else., it would certainly make the life of fedora-review > maintainers easier. That said, I'm turning a blind eye to the obvious > technical hassles versioning a wiki. It wouldn't be that difficult to pull it out of the wiki and into a pagure.io repo that actually publishes things, etc. Again a topic of conversation for the FPC. I would really suggest opening a ticket with them. josh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Versioning the Packaging Guidelines
W dniu 09.09.2016 o 14:25, gil pisze: >> Could we learn anything from this? Fedora is not a rolling >> distribution, but the guidelines are. Would it be a good idea to >> actually provide versions of the guidelines? To track the last version >> checked in the packages? >> >> If not for anything else., it would certainly make the life of >> fedora-review maintainers easier. > to me it seems the opposite ... As long time Debian user (who played with packaging too) I would say that updating package to newest guidelines was described well in guidelines changelog. Especially when package is well maintained it often just meant "updated to latest standards. no changes required". -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Versioning the Packaging Guidelines
On 09/09/16 14:39, Josh Boyer wrote: On Fri, Sep 9, 2016 at 8:13 AM, Alec Leamas wrote: Dear list, There is an ongoing thread in debian-devel on their Standards-Version usage. Reading this, it strikes me that Fedora lacks this info. It wouldn't be that difficult to pull it out of the wiki and into a pagure.io repo that actually publishes things, etc. Again a topic of conversation for the FPC. I would really suggest opening a ticket with them. Done: https://fedorahosted.org/fpc/ticket/646 Cheers! --alec -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaned: elementry, evas-generic-loaders
Christopher Meng wrote:
> 100 is not enough at all, even .
100 is enough for all practical purposes. Even kdelibs3, which has had no
upstream release for 8 years, is only at -75. And in the unlikely event you
really reach 99, you can go to 99.1, 99.2, …
> Since efl has higher version, just use proper macros.
>
> Obsoletes: evas-generic-loaders <= %{version}-%{release}
That should be < rather than <= again. And it only makes sense if the
version numbers actually correlate. Otherwise it is too broad.
There is no case in which < 1.17.0-100 will fail, but something like < 3.0
will work. The -100 hack is actually the narrowest Obsoletes you can use. If
you don't like it, use < 1.17.1 (the next narrowest).
> Obsoletes: evas-generic-loaders%{?_isa} <= %{version}-%{release}
And this one is just nonsense, as Igor Gnatenko pointed out.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] Fedora 25 Branched 20160909.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 25 Branched 20160909.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/25 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160909.n.0_Security_Lab Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/relval/ ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
TBB license change and package rebuilds
[This message BCC'd to affected maintainers.] A new version of tbb has been released. With this release, the license changes from "GPLv2 with exceptions" to "ASL 2.0". There is no soname bump in this release, but one section of the API changed in a backwards-incompatible way. Therefore, I intend to rebuild all tbb-using packages for Rawhide and F-25, in case they use that part of the API. I have already done local builds in mock, with no problems. The affected packages are: - ceres-solver - embree - gazebo - mathicgb - OCE - suitesparse There is another reason for these rebuilds. TBB was available only on a restricted set of architectures in the past, and most of these packages still reflect that. Today, though, TBB is available on all arches in all supported versions of Fedora, and in RHEL > 6. I propose to remove the architecture restrictions from the above packages, or use them only for RHEL <= 6. (except for embree, which has an architecture restriction of its own). If the suitesparse maintainer does not object, I would also like to fix something I noticed in the build logs. GCC complains about unrecognized pragmas. - #pragma ivdep: I propose to change all instances of this to #pragma GCC ivdep. - #pragma novector: there is no GCC equivalent, so nothing can be done here. - #pragma omp ...: I propose to build CHOLMOD with -fopenmp so these will be defined and used. If any maintainers of the above packages object to any part of this plan, please let me know soon. If nobody objects, I will do all of these builds early next week. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:
I would like to build (S)RPMs directly from a Git repository (which
contains the .spec file in the top-level directory). This is for a
CI-style project, with a quick release cycle.
I have a Lua script fragment which generates a proper SRPM with the
mock-scm target in COPR, and which is also compatible with “fedpkg
srpm”. But rpmbuild strips leading path components from Source: and
Patch: references, so this only works if all files are in a single
directory.
Are there any alternatives that work in COPR, EPEL and Fedora proper?
I think it's strange that I have to put a tarball somewhere just for
RPM's sake if there is no separate upstream, and there are no upstream
releases as a result. It's just an annoyance and yet another step that
can go wrong in various ways.
This is my situation with everything I package (privately for my employer). I
went in circles for a while simply believing I had to be doing something wrong
until I considered the fact that most people doing packaging are not the
authors. This all settled in completely when I began recalling the days of
yore when one would download a tgz, extract, config, make, etc.. Still I think
it's a shame that this isn't handled better. With very large projects it's
quite a waste of time to archive just to meet the expected input format only to
have the process reversed immediately.
That said, I do much as Igor has already mentioned. My build process starts
with tito but lands in our Koji. I use the following Makefile without any
changes for each of my projects to facilitate tito's
tito.release.KojiGitReleaser:
$ cat Makefile
# Extract NVR from the spec while stripping any macros, specifically the
# disttag macro.
name := $(shell awk '/^Name:/{print $$2}' *.spec)
version := $(shell \
awk '/^Version:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
)
release := $(shell \
awk '/^Release:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
)
# The treeish we'll archive is effectively the Git tag that tito created.
treeish := ${name}-${version}-${release}
# Koji's buildSRPMFromSCM method expects a target named "sources" which
# ultimately must ensure that a tarball of the package's sources and its spec
# file are present. Our practice is to always keep a spec file in the Git
# repository, but we must build the tarball on the fly to resemble an upstream
# published work.
sources:
git archive \
--output=${name}-${version}.tar.gz \
--prefix=${name}-${version}/ \
${treeish}
Hope this helps!
--
John Florian mailto:john.flor...@dart.biz>>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F26 System Wide Change: DNF 2.0
= Proposed System Wide Change: DNF 2.0 = https://fedoraproject.org/wiki/Changes/DNF-2.0 Change owner(s): * Jan Silhan * Michal Luscon * Igor Gnatenko DNF rebase to version 2.0. == Detailed Description == DNF-2.0 is the next upcoming major version of DNF package manager. Unfortunately, it brings some incompatibilities with previous version of DNF (DNF-1) which were either needed to preserve compatibility with YUM CLI or where bigger redesigns were needed. A list of identified incompatible changes can be found here http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html == Scope == Proposal owners: * complete release notes * deliver DNF-2.0 stack to Rawhide Other developers: * Owners of 3rd party DNF plugins or components depending on DNF should check and adjust their packages otherwise they may not work with DNF-2.0. Release engineering: * All release engineering tools that depends on DNF should be tested against DNF-2.0. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish
2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.
X. Requires some files in upstream repo
I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.
On Fri, Sep 9, 2016 at 4:47 PM, John Florian wrote:
> On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:
>
> I would like to build (S)RPMs directly from a Git repository (which
> contains the .spec file in the top-level directory). This is for a
> CI-style project, with a quick release cycle.
>
> I have a Lua script fragment which generates a proper SRPM with the
> mock-scm target in COPR, and which is also compatible with “fedpkg
> srpm”. But rpmbuild strips leading path components from Source: and
> Patch: references, so this only works if all files are in a single
> directory.
>
> Are there any alternatives that work in COPR, EPEL and Fedora proper?
>
> I think it's strange that I have to put a tarball somewhere just for
> RPM's sake if there is no separate upstream, and there are no upstream
> releases as a result. It's just an annoyance and yet another step that
> can go wrong in various ways.
>
>
> This is my situation with everything I package (privately for my employer).
> I went in circles for a while simply believing I had to be doing something
> wrong until I considered the fact that most people doing packaging are not
> the authors. This all settled in completely when I began recalling the days
> of yore when one would download a tgz, extract, config, make, etc.. Still I
> think it's a shame that this isn't handled better. With very large projects
> it's quite a waste of time to archive just to meet the expected input format
> only to have the process reversed immediately.
>
> That said, I do much as Igor has already mentioned. My build process starts
> with tito but lands in our Koji. I use the following Makefile without any
> changes for each of my projects to facilitate tito's
> tito.release.KojiGitReleaser:
>
> $ cat Makefile
> # Extract NVR from the spec while stripping any macros, specifically the
> # disttag macro.
> name := $(shell awk '/^Name:/{print $$2}' *.spec)
> version := $(shell \
>awk '/^Version:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
>)
> release := $(shell \
>awk '/^Release:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
>)
> # The treeish we'll archive is effectively the Git tag that tito created.
> treeish := ${name}-${version}-${release}
>
> # Koji's buildSRPMFromSCM method expects a target named "sources" which
> # ultimately must ensure that a tarball of the package's sources and its
> spec
> # file are present. Our practice is to always keep a spec file in the Git
> # repository, but we must build the tarball on the fly to resemble an
> upstream
> # published work.
> sources:
>git archive \
>--output=${name}-${version}.tar.gz \
>--prefix=${name}-${version}/ \
>${treeish}
>
>
> Hope this helps!
> --
> John Florian
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160909.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Failed openQA tests: 12/92 (x86_64), 2/17 (i386), 1/2 (arm) New failures (same test did not fail in 25-20160908.n.0): ID: 33211 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/33211 ID: 33232 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/33232 ID: 33234 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/33234 ID: 33245 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/33245 ID: 33260 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/33260 ID: 33289 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/33289 Old failures (same test failed in 25-20160908.n.0): ID: 33198 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33198 ID: 33207 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/33207 ID: 33253 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/33253 ID: 33271 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/33271 ID: 33272 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/33272 ID: 33273 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/33273 ID: 33274 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/33274 ID: 33275 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33275 ID: 33291 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/33291 Passed openQA tests: 68/92 (x86_64), 15/17 (i386) New passes (same test did not pass in 25-20160908.n.0): ID: 33254 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33254 ID: 33270 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33270 Skipped openQA tests: 13 of 111 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
On Fri, 2016-09-09 at 16:54 +0200, Igor Gnatenko wrote:
Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish
I don't have any problem with this at all. For my test builds I don't use
tito.release.KojiGitReleaser
but rather tito.release.KojiReleaser which produces builds named like:
builder-6.14-1.git.6.05be4b1.fc24
builder-6.14-1.git.7.40346c1.fc24
builder-6.14-1.git.8.c448a30.fc24
... where the '.6', '.7', '.'8' following represents the number of commits
since the last "tito tag" operation. I only get burned when redo one of those
"steps" with "git commit --fixup" followed later by "git rebase -i
--autosquash". However, by that time I'm finalizing a branch and can live with
a reinstall vs upgrade.
2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.
I'm not 100% sure I follow you here, but I suspect I get away with this because
all my spec's have:
Source0:%{name}-%{version}.tar.gz
Granted, this would never fly in Fedora proper, but for private work it suits
me fine. I otherwise attempt to adhere to FPG as much as possible as it
generally makes life simpler.
X. Requires some files in upstream repo
I'm not sure I follow here either, but as the author and packager for my
projects, I actually prefer that our Git repo has everything needed, spec,
Makefile, etc. right there. The only part that makes me cringe is the fact
that Makefile is duped all over the place. I hate dupes and strive for DRY
because eventually they all need to change.
I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.
In my case (but perhaps not Mr. Weimer's) is that I don't have to be proper per
Fedora. FWIW, I found tito to be a godsend for bringing ease to my situation.
That all said, I'm very curious how your rpm-gitoverlay helps exactly. I've
found a solution that works for me, but I hammered out a solution without as
broad an understanding of how Fedora is built as I have now -- and I'm certain
my current understanding is probably woefully lacking. Is rgo something that
could be used with our private Koji setup? My quick glance at the code leads
me it's suited for copr or rpmbuild only.
--
John Florian mailto:john.flor...@dart.biz>>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
On Fri, Sep 9, 2016 at 5:25 AM, Florian Weimer wrote: > I would like to build (S)RPMs directly from a Git repository (which > contains the .spec file in the top-level directory). This is for a > CI-style project, with a quick release cycle. > > I have a Lua script fragment which generates a proper SRPM with the > mock-scm target in COPR, and which is also compatible with “fedpkg srpm”. > But rpmbuild strips leading path components from Source: and Patch: > references, so this only works if all files are in a single directory. > > Are there any alternatives that work in COPR, EPEL and Fedora proper? > > I think it's strange that I have to put a tarball somewhere just for RPM's > sake if there is no separate upstream, and there are no upstream releases > as a result. It's just an annoyance and yet another step that can go wrong > in various ways. > > Thanks, > Florian > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org There is the --build-in-place option to rpmbuild, which will "Build from locally checked out sources. Sets _builddir to current working directory. Skips handling of -n and untar in the %setup and the deletion of the buildSubdir." This might be helpful, if the current working directory is the root of the git repository. I think it's a relatively new option-- I seem to remember it being added somewhere in the Fedora 23 cycle? Ben Rosser -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to package a Git repository
2016-09-09 3:25 GMT-06:00, Florian Weimer : > I would like to build (S)RPMs directly from a Git repository (which > contains the .spec file in the top-level directory). This is for a > CI-style project, with a quick release cycle. > Tito can help you: https://github.com/dgoodwin/tito -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TBB license change and package rebuilds - openmp issues
On 09/09/2016 08:24 AM, Jerry James wrote: > There is no soname bump in this release, but one section of the API > changed in a backwards-incompatible way. If they broke ABI, why wasn't the soname bumped? > If the suitesparse maintainer does not object, I would also like to > fix something I noticed in the build logs. GCC complains about > unrecognized pragmas. > - #pragma ivdep: I propose to change all instances of this to #pragma GCC > ivdep. > - #pragma novector: there is no GCC equivalent, so nothing can be done here. > - #pragma omp ...: I propose to build CHOLMOD with -fopenmp so these > will be defined and used. I'm concerned about this last change - if I understand it correctly everything that link to CHOLMOD will now need to use -fopenmp as well. I'm not necessarily opposed to this, but it does have larger ramifications. I know in various places libraries will provide both serial and openmp versions. I wonder if it's time for Fedora to work out a scheme for this, or perhaps simply embrace the multi-core age and accept openmp versions as standard. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2016-09-09)
=== #fedora-meeting: FESCO (2016-09-09) === Meeting started by kalev at 16:00:26 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2016-09-09/fesco.2016-09-09-16.00.log.html . Meeting summary --- * init process (kalev, 16:00:29) * #1609 Fedora 26 schedule proposal (kalev, 16:02:18) * AGREED: Keep the originally-approvde Wednesday mass-rebuild (+1:7, 0:0, -1:0) (kalev, 16:10:22) * #1617 Council update on Third Party Software policy (kalev, 16:10:37) * AGREED: Approve https://fedorahosted.org/fesco/ticket/1617#comment:10 with the edit "... by an active Fedora Working Group (for Editions) or FESCo (for all other deliverables) ..." (+1:6, 0:0, -1:0) (kalev, 16:22:27) * Next week's chair (kalev, 16:23:02) * AGREED: jwb to chair next week (kalev, 16:23:56) * Open Floor (kalev, 16:24:12) Meeting ended at 16:29:29 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * kalev (50) * sgallagh (26) * nirik (21) * zodbot (16) * Rathann (15) * jwb (12) * jsmith (9) * pbrobinson (5) * paragan (5) * cschalle (2) * maxamillion (0) * dgilmore (0) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TBB license change and package rebuilds - openmp issues
On Friday, 09 September 2016 at 18:22, Orion Poplawski wrote: > On 09/09/2016 08:24 AM, Jerry James wrote: > > There is no soname bump in this release, but one section of the API > > changed in a backwards-incompatible way. > > If they broke ABI, why wasn't the soname bumped? > > > If the suitesparse maintainer does not object, I would also like to > > fix something I noticed in the build logs. GCC complains about > > unrecognized pragmas. > > - #pragma ivdep: I propose to change all instances of this to #pragma GCC > > ivdep. > > - #pragma novector: there is no GCC equivalent, so nothing can be done here. > > - #pragma omp ...: I propose to build CHOLMOD with -fopenmp so these > > will be defined and used. > > I'm concerned about this last change - if I understand it correctly everything > that link to CHOLMOD will now need to use -fopenmp as well. I'm not > necessarily opposed to this, but it does have larger ramifications. I know in > various places libraries will provide both serial and openmp versions. I > wonder if it's time for Fedora to work out a scheme for this, or perhaps > simply embrace the multi-core age and accept openmp versions as standard. I'd be wary against making it default. Thread-safety is still not universal and sometimes multi-threading makes things slower. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TBB license change and package rebuilds - openmp issues
On Fri, Sep 09, 2016 at 10:22:19AM -0600, Orion Poplawski wrote: > On 09/09/2016 08:24 AM, Jerry James wrote: > > There is no soname bump in this release, but one section of the API > > changed in a backwards-incompatible way. > > If they broke ABI, why wasn't the soname bumped? > > > If the suitesparse maintainer does not object, I would also like to > > fix something I noticed in the build logs. GCC complains about > > unrecognized pragmas. > > - #pragma ivdep: I propose to change all instances of this to #pragma GCC > > ivdep. > > - #pragma novector: there is no GCC equivalent, so nothing can be done here. > > - #pragma omp ...: I propose to build CHOLMOD with -fopenmp so these > > will be defined and used. > > I'm concerned about this last change - if I understand it correctly everything > that link to CHOLMOD will now need to use -fopenmp as well. I'm not > necessarily opposed to this, but it does have larger ramifications. I know in > various places libraries will provide both serial and openmp versions. I > wonder if it's time for Fedora to work out a scheme for this, or perhaps > simply embrace the multi-core age and accept openmp versions as standard. Why would you need to compile all other libraries that use something with -fopenmp just because you built something with -fopenmp? If it is a shared library, it will be (have to be) linked with -fopenmp and thus link libgomp and libpthread, but other libraries can still be serial or use POSIX threads on their own. If it is a static library, sure, you need to make sure you link with -fopenmp whatever links that static library in, but that doesn't mean you need to compile anything else with -fopenmp. If the library compiled with -fopenmp calls into code from other libraries from parallel regions, sure, you need to make sure that those functions are thread safe, but that is about it. Jakub -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TBB license change and package rebuilds - openmp issues
On 09/09/2016 07:37 PM, Dominik 'Rathann' Mierzejewski wrote: On Friday, 09 September 2016 at 18:22, Orion Poplawski wrote: On 09/09/2016 08:24 AM, Jerry James wrote: There is no soname bump in this release, but one section of the API changed in a backwards-incompatible way. If they broke ABI, why wasn't the soname bumped? If the suitesparse maintainer does not object, I would also like to fix something I noticed in the build logs. GCC complains about unrecognized pragmas. - #pragma ivdep: I propose to change all instances of this to #pragma GCC ivdep. - #pragma novector: there is no GCC equivalent, so nothing can be done here. - #pragma omp ...: I propose to build CHOLMOD with -fopenmp so these will be defined and used. I'm concerned about this last change - if I understand it correctly everything that link to CHOLMOD will now need to use -fopenmp as well. I'm not necessarily opposed to this, but it does have larger ramifications. I know in various places libraries will provide both serial and openmp versions. I wonder if it's time for Fedora to work out a scheme for this, or perhaps simply embrace the multi-core age and accept openmp versions as standard. I'd be wary against making it default. Thread-safety is still not universal and sometimes multi-threading makes things slower. Regards, Dominik Many codes can use multithreading support, though one sometimes gets conflicts. It would be beneficial to have two builds - single threaded and multithreaded, perhaps with single threaded as default. People can then choose appropriate package. Multithreaded can lead to improvements, but is problem dependent. Are there standard flags for multithreaded builds? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Weak deps in updates
ok. With excellent help from walters we got the atomic updates composes working again and everything has now pushed out. (Although fedora-24-updates-testing just pushed out so it will take it a few to mirror). So, all the updates/updates-testing repos should now have weak deps. Can folks retest and let me know if there's still any issues? Thanks, kevin pgpdxey_Dfyiu.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please clean up unneeded files from fedorapeople.org groups and repos
On Fri, 9 Sep 2016 08:37:19 +0200 Igor Gnatenko wrote: > Kevin, help me please with cleanup: > > [ignatenkobrain@people02 ~][PROD]$ rm -rf > /home/fedora/ignatenkobrain/public_git/* > rm: cannot remove > ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/20/3a73563e678017862cc45354588d40a967a57d’: > Permission denied > rm: cannot remove > ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/8b/cff8eb33b25bef2d995ce4bc420153f2c1aade’: > Permission denied > rm: cannot remove > ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/a8/3159425e2105565b79d0daeef7e16073d0d32a’: > Permission denied > rm: cannot remove > ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/e5/2ea1c393718f48e74abf0c2062b753cb542f4c’: > Permission denied > rm: cannot remove > ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/ef/56842f0422bf92e453ec47c8f1556bdeb04b77’: > Permission denied > rm: cannot remove > ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/f0/5c6e5deddbcc835948588534b0c2f34248d6f6’: > Permission denied Removed. Those were files pushed by someone else into your repo. I would have thought acls would allow you to remove them, but the acls seem to have gotten lost somewhere. Anyhow, they are removed and thanks for cleaning up your space. kevin pgpQvfKZY5nTo.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24, small backward steps
Just a couple of smallish things after upgrading (via dnf) from F23 to F24 a couple of months ago: 1. deja-dup gui: one has to deselect then reselect the Overview option in order to be offered the "Backup Now" option. The details option in the progress dialog will only display two or three lines, is not resizeable, and does not follow resizing the entire dialog The progress dialog does not wait to be dismissed at the end, causing any messages about problems (like failure to backup a particular file) to not be seen 2. fingerprint identification: The laptop has a fingerprint reader and it works fine. However I prefer not to use it. The user set up specifies that fingerprint login is disabled. However whenever I am asked for a password the fingerprint reader blinks until I swipe a finger over it (even after using a password). No fingerprint is registered. This is different than F23 where it never blinked. 3. Scrolling issues: This, edge and natural scrolling via the touchpad, was covered nicely in a previous thread. Solutions offered there work well but should be better integrated as I am sure they will be. Desktop is: gnome-desktop3-3.20.2-1.fc24.x86_64 laptop is Thinkpad X240 (Intel graphics) Not to be a pita, just trying to help I really like Fedora & the Gnome desktop -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@leidos.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24, small backward steps
On Fri, 2016-09-09 at 15:53 -0400, Roger Wells wrote: > Just a couple of smallish things after upgrading (via dnf) from F23 to > F24 a couple of months ago: > > 1. deja-dup gui: > > one has to deselect then reselect the Overview option in order > to be offered the "Backup Now" option. > > The details option in the progress dialog will only display two > or three lines, is not resizeable, and does not follow resizing the > entire dialog > > The progress dialog does not wait to be dismissed at the end, > causing any messages about problems (like failure to backup a particular > file) to not be seen This really isn't anything particular to Fedora. deja-dup is just an app we ship. The appropriate place to report issues with it is to its upstream bug tracker. > 2. fingerprint identification: > > The laptop has a fingerprint reader and it works fine. However > I prefer not to use it. The user set up specifies that fingerprint login > is disabled. > > However whenever I am asked for a password the fingerprint > reader blinks until I swipe a finger over it (even after using a > password). > > No fingerprint is registered. > > This is different than F23 where it never blinked. This you should probably file a bug on (against, I guess, gnome-shell? But it depends a lot on the answer to my second question below...), but with a bit more detail. What exactly do you mean by "The user set up specifies that fingerprint login is disabled" - what "user set up" are you referring to exactly? When exactly does this happen - more detail on "whenever I am asked for a password". Thanks! -- 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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F26 System Wide Change: DNF 2.0
Hi, On Fri, 2016-09-09 at 16:49 +0200, Jan Kurik wrote: > = Proposed System Wide Change: DNF 2.0 = This email says it is a system-wide change. > https://fedoraproject.org/wiki/Changes/DNF-2.0 But this page keeps saying « not a System Wide Change ». Which is? :) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F26 System Wide Change: DNF 2.0
If it requires actions from releng, then it's system-wide change. But it's not about changing existing process of building distro, it's just bugfixing releng tools. So I'm not sure. On Fri, Sep 9, 2016 at 10:38 PM, Mathieu Bridon wrote: > Hi, > > On Fri, 2016-09-09 at 16:49 +0200, Jan Kurik wrote: >> = Proposed System Wide Change: DNF 2.0 = > > This email says it is a system-wide change. > >> https://fedoraproject.org/wiki/Changes/DNF-2.0 > > But this page keeps saying « not a System Wide Change ». > > Which is? :) > > > -- > Mathieu > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F26 System Wide Change: DNF 2.0
On Fri, Sep 09, 2016 at 11:00:21PM +0200, Igor Gnatenko wrote: > If it requires actions from releng, then it's system-wide change. But > it's not about changing existing process of building distro, it's just > bugfixing releng tools. > > So I'm not sure. > > On Fri, Sep 9, 2016 at 10:38 PM, Mathieu Bridon wrote: > > Hi, > > > > On Fri, 2016-09-09 at 16:49 +0200, Jan Kurik wrote: > >> = Proposed System Wide Change: DNF 2.0 = > > > > This email says it is a system-wide change. > > > >> https://fedoraproject.org/wiki/Changes/DNF-2.0 > > > > But this page keeps saying « not a System Wide Change ». > > > > Which is? :) Well, it could influence releng depending on the behavior of dnf-2 vs -1 and I think dnf is critical enough that making it a System Wide Change would be a good idea regardless. What is the down side of making a System-Wide Change? More people know about it? A more defined rollback procedure? Both seems like good ideas :) My 2cts, Pierre -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24, small backward steps
On Fri, 9 Sep 2016, Adam Williamson wrote: 2. fingerprint identification: The laptop has a fingerprint reader and it works fine. However I prefer not to use it. The user set up specifies that fingerprint login is disabled. However whenever I am asked for a password the fingerprint reader blinks until I swipe a finger over it (even after using a password). No fingerprint is registered. This is different than F23 where it never blinked. This you should probably file a bug on (against, I guess, gnome-shell? But it depends a lot on the answer to my second question below...), but with a bit more detail. What exactly do you mean by "The user set up specifies that fingerprint login is disabled" - what "user set up" are you referring to exactly? When exactly does this happen - more detail on "whenever I am asked for a password". Thanks! This happened to me too. I did not enable fingerprint based logins (since half a dozen governments have my fingerprints) and whenever I open my laptop or unlock the screensaver using a password, the green fingerprint LED starts blinking. This did not happen on f23. Paul -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24, small backward steps
On 09/09/2016 04:44 PM, Adam Williamson wrote: > On Fri, 2016-09-09 at 15:53 -0400, Roger Wells wrote: >> Just a couple of smallish things after upgrading (via dnf) from F23 to >> F24 a couple of months ago: >> >> 1. deja-dup gui: >> >> one has to deselect then reselect the Overview option in order >> to be offered the "Backup Now" option. >> >> The details option in the progress dialog will only display two >> or three lines, is not resizeable, and does not follow resizing the >> entire dialog >> >> The progress dialog does not wait to be dismissed at the end, >> causing any messages about problems (like failure to backup a particular >> file) to not be seen > > This really isn't anything particular to Fedora. deja-dup is just an > app we ship. The appropriate place to report issues with it is to its > upstream bug tracker. Just did that. > >> 2. fingerprint identification: >> >> The laptop has a fingerprint reader and it works fine. However >> I prefer not to use it. The user set up specifies that fingerprint login >> is disabled. >> >> However whenever I am asked for a password the fingerprint >> reader blinks until I swipe a finger over it (even after using a >> password). >> >> No fingerprint is registered. >> >> This is different than F23 where it never blinked. > > This you should probably file a bug on (against, I guess, gnome-shell? > But it depends a lot on the answer to my second question below...), but > with a bit more detail. What exactly do you mean by "The user set up > specifies that fingerprint login is disabled" - what "user set up" are > you referring to exactly? When exactly does this happen - more detail > on "whenever I am asked for a password". Thanks! 1. Press the button on the upper right corner of the Gnome desktop. 2. Press the settings button on the lower left of the menu 3. Select Users On the resulting "Users" dialog one can select Fingerprint Login: Disabled/Enabled In my case it is Disabled As far as when this occurs, at least: 1. at boot up login 2. after suspense login and not 1. not when a browser asks for a password when visiting a site 2. when issuing a command using sudo, like mounting an external share Once again, this did not occur on F23 and started as soon as I upgraded to F24 Its no big deal. We could do like windows 10 which just stops the fingerprint reader when a password is entered. Let me know if you think I should submit this upstream somewhere. It feels like it may be similar to the scrolling problems mentioned that seem be fixed after installing libinit and adjusting some configuration files in /etc. After doing that the Gnome "Mouse & Touchpad" settings dialog (same place as the "Users" mentioned above) took on a whole new meaningful life. HTH, thanks for your response > -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@leidos.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24, small backward steps
On Fri, 2016-09-09 at 17:45 -0400, Roger Wells wrote: > > Let me know if you think I should submit this upstream somewhere. Probably to gnome-shell on bugzilla.gnome.org , I guess. -- 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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: TBB license change and package rebuilds - openmp issues
On 09/09/2016 10:50 AM, Jakub Jelinek wrote: > On Fri, Sep 09, 2016 at 10:22:19AM -0600, Orion Poplawski wrote: >> On 09/09/2016 08:24 AM, Jerry James wrote: >>> There is no soname bump in this release, but one section of the API >>> changed in a backwards-incompatible way. >> >> If they broke ABI, why wasn't the soname bumped? >> >>> If the suitesparse maintainer does not object, I would also like to >>> fix something I noticed in the build logs. GCC complains about >>> unrecognized pragmas. >>> - #pragma ivdep: I propose to change all instances of this to #pragma GCC >>> ivdep. >>> - #pragma novector: there is no GCC equivalent, so nothing can be done here. >>> - #pragma omp ...: I propose to build CHOLMOD with -fopenmp so these >>> will be defined and used. >> >> I'm concerned about this last change - if I understand it correctly >> everything >> that link to CHOLMOD will now need to use -fopenmp as well. I'm not >> necessarily opposed to this, but it does have larger ramifications. I know >> in >> various places libraries will provide both serial and openmp versions. I >> wonder if it's time for Fedora to work out a scheme for this, or perhaps >> simply embrace the multi-core age and accept openmp versions as standard. > > Why would you need to compile all other libraries that use something with > -fopenmp just because you built something with -fopenmp? If it is a shared > library, it will be (have to be) linked with -fopenmp and thus link libgomp > and libpthread, but other libraries can still be serial or use > POSIX threads on their own. If it is a static library, sure, you need to > make sure you link with -fopenmp whatever links that static library in, but > that doesn't mean you need to compile anything else with -fopenmp. > If the library compiled with -fopenmp calls into code from other libraries > from parallel regions, sure, you need to make sure that those functions are > thread safe, but that is about it. > > Jakub Ah, yes, thanks for the clarification. However, suitesparse does ship static libraries, so at least for those I think the openmp versions should be named different. One question I have though is if the application using the shared openmp compiled library is not linked with -fopenmp, will the openmp code in the library get activated or not? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] 2016-09-12 @ 16:00 UTC - Fedora 25 Blocker Review
# F25 Blocker Review meeting # Date: 2016-09-12 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We currently have 9 proposed Beta blockers and 9 proposed Final blockers to review (whew - this might be a long one). If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F25 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] 2016-09-12 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2016-09-12 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! We haven't had a meeting for a while and everyone should be around so far as I know, so a good time to sync up. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 25 Beta status 3. Test Day status 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedorahosted.org sunset: 2017-02-28
On Wed, 2016-09-07 at 10:44 -0600, Kevin Fenzi wrote: > Greetings. > > Fedora Infrastructure currently maintains two sites for general open > source code hosting: fedorahosted.org and pagure.io. > > Fedorahosted.org was established in late 2007 using Trac for issues and > wiki pages, Fedora Account System groups for access control and source > uploads, and offering a variety of Source Control Management tools > (git, svn, hg, bzr). With the rise of new workflows and source > repositories fedorahosted.org has ceased to grow, adding just one new > project this year and a handful the year before. I'm replying here as I'm not subscribed to users@. Pagure is fine for code projects, but we (still) use the fedora-qa trac instance for tracking non-code-related activity, like arranging Test Days. Is Pagure the recommended replacement for this kind of purpose also? It doesn't feel right. If not, what is? Thanks! -- 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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160909.n.0 compose check report
Missing expected images: Kde live i386 Kde live x86_64 Cloud_base raw-xz i386 Atomic raw-xz x86_64 Kde raw-xz armhfp Failed openQA tests: 5/85 (x86_64), 3/16 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20160908.n.0): ID: 33357 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33357 ID: 33389 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/33389 ID: 33395 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33395 Old failures (same test failed in Rawhide-20160908.n.0): ID: 33309 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33309 ID: 33310 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/33310 ID: 33326 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/33326 ID: 5 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/5 ID: 33356 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/33356 ID: 33394 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/33394 Passed openQA tests: 80/85 (x86_64), 13/16 (i386) New passes (same test did not pass in Rawhide-20160908.n.0): ID: 33306 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/33306 ID: 33325 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/33325 ID: 33361 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/33361 ID: 33373 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33373 ID: 33376 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/33376 ID: 33377 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/33377 Skipped openQA tests: 1 of 103 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
