It happened to me almost dozen times now, so here's my rage :D
I want to send a pull request to a Fedora project*, I clone it, fork it, push to
the fork, open a PR and there it goes:
! This repo requires all commits to have the Signed-off-by whatnot in them !
So I have to go again, amend with
https://src.fedoraproject.org/rpms/
Project option
->
Enforce signed-off commits in pull-request
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jan 17, 2019 at 11:15 AM Miro Hrončok wrote:
>
> It happened to me almost dozen times now, so here's my rage :D
On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote:
> It happened to me almost dozen times now, so here's my rage :D
>
> I want to send a pull request to a Fedora project*, I clone it, fork it,
> push to the fork, open a PR and there it goes:
...
> benefit, just pain. I've signed the F
On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote:
> It happened to me almost dozen times now, so here's my rage :D
>
> I want to send a pull request to a Fedora project*, I clone it, fork it,
> push to the fork, open a PR and there it goes:
>
> ! This repo requires all commits to have
Hello,
Could I have some help with CMake please?
I have a WIP spec here[1] that won't build. It always fails with:
> + cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
$ cmake [path] [flags]
So inyour case
$ cmake . [flags]
I suppose
This is caused by a CMake update in rawhide.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jan 17, 2019 at 12:31 PM Ankur Sinha wrote:
>
> Hello,
>
> Could I have some help with CMake
On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote:
> Why do Fedora upstreams enforce this?
I enforce the DCO in Bodhi. I started doing it after attended a talk by
Richard Fontana where he suggested it as a way to be explicit about the
license of contributions (i.e., not just the license of the
On Thu, Jan 17, 2019 12:46:13 +0100, Michal Schorm wrote:
> $ cmake [path] [flags]
> So inyour case
> $ cmake . [flags]
> I suppose
>
> This is caused by a CMake update in rawhide.
Thanks for your reply, Michal.
The cmake command seems to run OK (as pasted in my initial e-mail). I
get the sa
On 17. 01. 19 12:59, Randy Barlow wrote:
On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote:
Why do Fedora upstreams enforce this?
I enforce the DCO in Bodhi. I started doing it after attended a talk by
Richard Fontana where he suggested it as a way to be explicit about the
license of contr
> I get the same error when trying to build for F29 also, so that may not be
> the case.
I thought that would be the case, since several packages I maintain
started to fail in Koschei with same symptoms after new CMake version
from 3.13.2 to 3.13.3.
I fixed them the way I advised you, so I just a
Announcing the creation of a new nightly release validation test event
for Fedora 30 Rawhide 20190117.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
On Thu, Jan 17, 2019 13:09:38 +0100, Michal Schorm wrote:
> > I get the same error when trying to build for F29 also, so that may not be
> > the case.
>
> I thought that would be the case, since several packages I maintain
> started to fail in Koschei with same symptoms after new CMake version
>
On 1/17/19 12:59 PM, Randy Barlow wrote:
> On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote:
>> Why do Fedora upstreams enforce this?
>
> I enforce the DCO in Bodhi. I started doing it after attended a talk by
> Richard Fontana where he suggested it as a way to be explicit about the
> license
On 17. 01. 19 13:28, Sheogorath wrote:
On 1/17/19 12:59 PM, Randy Barlow wrote:
On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote:
Why do Fedora upstreams enforce this?
I enforce the DCO in Bodhi. I started doing it after attended a talk by
Richard Fontana where he suggested it as a way t
You can use include(GNUInstallDirs) and then where install() is
called, you need to have install(… LIBRARY DESTINATION
${CMAKE_INSTALL_LIBDIR}).
On Thu, Jan 17, 2019 at 12:37 PM Ankur Sinha wrote:
>
> Hello,
>
> Could I have some help with CMake please?
>
> I have a WIP spec here[1] that won't bu
On Thu, 2019-01-17 at 13:04 +0100, Miro Hrončok wrote:
> I'd be very interested to know how adding some random line to a
> commit message
> grants an explicit license according to something that is not even
> linked from
> the commit message :(
I've actually wondered this myself, and agree that
Igor Gnatenko wrote:
> You can use include(GNUInstallDirs) and then where install() is
> called, you need to have install(… LIBRARY DESTINATION
> ${CMAKE_INSTALL_LIBDIR}).
Right, the command in the upstream CMakeLists.txt is trying to install
something without saying WHERE it should be installed.
Ankur Sinha wrote:
> [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107
Any reason why you are not using the %cmake RPM macro?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
On Thu, Jan 17, 2019 14:07:06 +0100, Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > You can use include(GNUInstallDirs)
They have included this, albeit a little later:
https://github.com/arbor-sim/arbor/blob/28e45aee46eb25dd91652768a5f5d496db05ba3a/CMakeLists.txt#L250
> >and then where install(
On Thu, Jan 17, 2019 14:07:44 +0100, Kevin Kofler wrote:
> Ankur Sinha wrote:
> > [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107
>
> Any reason why you are not using the %cmake RPM macro?
I need to build the package with MPI also (mpich/openmpi) and the %cmake
macro doe
On 1/17/19 3:06 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 17, 2019 at 11:13:47AM +0100, Miro Hrončok wrote:
It happened to me almost dozen times now, so here's my rage :D
I want to send a pull request to a Fedora project*, I clone it, fork it,
push to the fork, open a PR and there it g
I want to install Notable[0]. As it is not yet packaged for fedora, I tried
to install it with the rpm package.
--
# rpm-ostree install notable-1.1.0.x86_64.rpm
error: Importing package notable: Unsupported path:
/opt/Notable/LICENSE.electron.txt; See
https://github.com/projectatom
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_indian_languages
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email:
== Detailed Description ==
Currently, ibus-m17n is the default
No missing expected images.
Compose FAILS proposed Rawhide gating check!
2 of 47 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 17/132 (x86_64), 1/2 (arm)
New failures (same test not failed in Rawhide-20190116.n.0):
OLD: Fedora-Rawhide-20190116.n.0
NEW: Fedora-Rawhide-20190117.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 2
Dropped packages:2
Upgraded packages: 68
Downgraded packages: 9
Size of added packages: 27.70 MiB
Size of dropped packages
Hello, I am testing various changes in boinc-client systemd unit file.
At every RPM package update, it happens really often that on a machine
that installs the new RPM version, does not get the new systemd unit
file version, so it is not updated. To successfully update the file, I
have to remove th
Here are the recent changes to the packaging guidelines.
-
We have begun to remove content from the wiki. The old pages should all
now have links to the new docs site. As we continue to work on the new
documents, the corresponding wiki pages will be emptied and left only
with the link to th
On Thu, Jan 17, 2019 at 05:02:59PM +0100, Germano Massullo wrote:
> Hello, I am testing various changes in boinc-client systemd unit file.
> At every RPM package update, it happens really often that on a machine
> that installs the new RPM version, does not get the new systemd unit
> file version,
On Thu, 2019-01-17 at 11:13 +0100, Miro Hrončok wrote:
> It happened to me almost dozen times now, so here's my rage :D
>
> I want to send a pull request to a Fedora project*, I clone it, fork it, push
> to
> the fork, open a PR and there it goes:
>
> ! This repo requires all commits to have th
context: https://github.com/coreos/fedora-coreos-tracker/issues/104
There are some udev rules that support various hardware on different cloud
providers
that we'd like to provide as part of Fedora CoreOS so it can operate on those
platforms
as expected. In the past these udev rules could be prov
On Thu, Jan 17, 2019 at 11:41:29AM -0500, Dusty Mabe wrote:
> context: https://github.com/coreos/fedora-coreos-tracker/issues/104
>
> There are some udev rules that support various hardware on different cloud
> providers
These rules: https://github.com/coreos/init/tree/master/udev/rules.d ?
So
> "RG" == Raphael Groner writes:
RG> Fedora packaging is becoming to get heavy magic aspects.
Well, obviously we would prefer that the scriptlets just go away and not
be replaced with magic. The magic macros exist to accommodate those who
wish to have a single spec across Fedora and EPEL, T
On 17. 01. 19 17:26, Adam Williamson wrote:
If a project is enforcing sign-off but doesn't have
the DCO or any other kind of prominent statement of what the sign-off
is*for*, that is meaningless, because there's no reasonable context
for the sign-off text.
Exactly.
Also, the text sometimes is
Hi all,
I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS,
and helping bring aspects of Container Linux to Fedora. I'll be maintaining
a package upstream, console-login-helper-messages. I also help out with
ostree/rpm-ostree upstream. Looking forward to contributing further
Apologies for second email. The package I have under review is
console-login-helper-messages, at
https://bugzilla.redhat.com/show_bug.cgi?id=1667174.
On Thu, Jan 17, 2019 at 12:31 PM Robert Fairley wrote:
> Hi all,
>
> I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS,
>
On Thu, Jan 17, 2019 at 12:31:46PM -0500, Robert Fairley wrote:
> I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS,
> and helping bring aspects of Container Linux to Fedora. I'll be maintaining
> a package upstream, console-login-helper-messages. I also help out with
> ostr
On 1/17/19 12:31 PM, Robert Fairley wrote:
> Hi all,
>
> I'm an intern at Red Hat in Toronto, Canada. I'm working on Fedora CoreOS,
> and helping bring aspects of Container Linux to Fedora. I'll be maintaining a
> package upstream, console-login-helper-messages. I also help out with
> ostree/
On Thu, 2019-01-17 at 00:48 +0100, Björn 'besser82' Esser wrote:
> Am Mittwoch, den 16.01.2019, 22:08 + schrieb Jonathan Dieter:
> > Just a heads up Rawhide has had zchunked metadata for almost three
> > weeks, and I'd greatly appreciate some more testing on the client side
> > before we finish
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>
> RH> Ah, I see, you're talking about the case when the enctype is already
> RH> not permitted. That all makes sense then.
>
> Right. Basically, if any one of these:
>
> * Warnings in previous versions about principals withou
On Wed, Jan 09, 2019 at 02:56:59PM -0500, Ben Cotton wrote:
> Congratulations to the last System-Wide Change proposal of F30!
>
> https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks
>
> == Summary ==
> Language support groups in Comps file will get replaced by langp
> "RH" == Robbie Harwood writes:
RH> If I backport this to fc29, will that assuage people's concerns?
I think it would certainly help and I wouldn't complain. In fact, I'd
love to start running that as soon as I can. However, it wouldn't help
anyone who does a (supposedly supported) F28->F
On Thu, 2019-01-17 at 18:20 +0100, Miro Hrončok wrote:
> On 17. 01. 19 17:26, Adam Williamson wrote:
> > If a project is enforcing sign-off but doesn't have
> > the DCO or any other kind of prominent statement of what the sign-off
> > is*for*, that is meaningless, because there's no reasonable cont
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>
> RH> If I backport this to fc29, will that assuage people's concerns?
>
> I think it would certainly help and I wouldn't complain. In fact, I'd
> love to start running that as soon as I can. However, it wouldn't
> help anyon
On Thu, Jan 17, 2019 at 05:01:45PM -0500, Robbie Harwood wrote:
> Jason L Tibbitts III writes:
>
> >> "RH" == Robbie Harwood writes:
> >
> > RH> If I backport this to fc29, will that assuage people's concerns?
> >
> > I think it would certainly help and I wouldn't complain. In fact, I'd
> >
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2019-01-21 15:00 UTC'
Links to all issues to be
Michal Schorm wrote:
> $ cmake [path] [flags]
> So inyour case
> $ cmake . [flags]
> I suppose
>
> This is caused by a CMake update in rawhide.
It looks like this was an accidental regression rather than an intentional
change, apparently introduced by this merge:
https://gitlab.kitware.com/
On 1/17/19 7:08 AM, Ankur Sinha wrote:
> On Thu, Jan 17, 2019 14:07:44 +0100, Kevin Kofler wrote:
>> Ankur Sinha wrote:
>>> [1] https://github.com/sanjayankur31/rpm-specs/blob/arbor/arbor.spec#L107
>>
>> Any reason why you are not using the %cmake RPM macro?
>
> I need to build the package with MP
On Thu, Jan 17, 2019 16:41:42 -0700, Orion Poplawski wrote:
> On 1/17/19 7:08 AM, Ankur Sinha wrote:
> Just pass the extra options to %cmake. But be sure to use "%cmake" and not
> "%{cmake}". See
> https://src.fedoraproject.org/rpms/vtk/blob/master/f/vtk.spec#_675 for
> example.
OK--that's slig
libqalculate soname bump is happening with v2.8.2. The following
packages are affected -
plasma-workspace
step
cantor
qalculate-kde
I will rebuild these packages and file bug reports if needed.
Mukundan.
signature.asc
Description: OpenPGP digital signature
No missing expected images.
Failed openQA tests: 2/2 (x86_64)
Old failures (same test failed in testing-20190117.0):
ID: 346332 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/346332
ID: 346333 Test: x86_64 AtomicHost-dvd_ostree-i
On 1/17/19 6:37 AM, arnaud gaboury wrote:
I want to install Notable[0]. As it is not yet packaged for fedora, I
tried to install it with the rpm package.
--
# rpm-ostree install notable-1.1.0.x86_64.rpm
error: Importing package notable: Unsupported path:
/opt/Notable/LICENSE.el
No missing expected images.
Failed openQA tests: 2/2 (x86_64)
ID: 346334 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/346334
ID: 346335 Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org
On Fri, Jan 18, 2019 at 12:49 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Wed, Jan 09, 2019 at 02:56:59PM -0500, Ben Cotton wrote:
> > Congratulations to the last System-Wide Change proposal of F30!
> >
> >
> https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_W
Hi,
filed a bug about the issue with cmake.
https://bugzilla.redhat.com/show_bug.cgi?id=1667306
It seems also to affect a package review.
https://bugzilla.redhat.com/show_bug.cgi?id=1563831
Regards, Raphael
___
devel mailing list -- devel@lists.fedorapr
54 matches
Mail list logo
