Missing expected images:
Docker_base docker x86_64
Server dvd arm
Failed openQA tests: 19/94 (x86_64), 5/19 (i386)
New failures (same test did not fail in 27-20171110.n.1):
ID: 168670 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org
Hi folks! I'm proposing we cancel the blocker review meeting for
Monday, as there are no proposed Server Final blockers at present.
Please yell if you think we will need to run a meeting. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happ
# Fedora Quality Assurance Meeting
# Date: 2017-11-13
# Time: ** 16:00 ** UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
It's time for another meeting! We've finished with Fedora 27, but
not Fedora Modular Server 27,
OLD: Fedora-Modular-27-20171110.n.1
NEW: Fedora-Modular-27-2017.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0.00 B
Size of dropped packages
On 11/10/2017 10:43 AM, Richard W.M. Jones wrote:
> On Fri, Nov 10, 2017 at 09:47:02AM -0800, Kevin Fenzi wrote:
>> All that said, I don't see where s390x is involved in the current build.
>> The parent task is being handled by buildvm-23, but indeed it seems like
>> something has gone wrong. I can
On Fri, Nov 10, 2017 at 09:47:02AM -0800, Kevin Fenzi wrote:
> All that said, I don't see where s390x is involved in the current build.
> The parent task is being handled by buildvm-23, but indeed it seems like
> something has gone wrong. I can try and free that task to another
> builder, but that
OLD: Fedora-Modular-Bikeshed-20171026.n.0
NEW: Fedora-Modular-Bikeshed-20171026.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packag
On 11/10/2017 09:18 AM, Matthew Miller wrote:
...snip...
>
> On a bigger note: Do we really want to have a window after branch where
> Bodhi isn't active? Might it be better to put that as part of the
> Branch step? I don't think we want a longer freeze period (especially
> during beta) but we
Y
On 10/11/17 17:38, nicolas.mail...@laposte.net wrote:
Full details are in cap_from_text(3) by the looks of it.
Unfortunately, no. None of the fine manuals I located explain the difference
between ep and just p flags :( Everyone seems to use +ep blindly, but the
Fedora spec only adds p?
The
Missing expected images:
Docker_base docker x86_64
Server dvd arm
Failed openQA tests: 18/94 (x86_64), 4/19 (i386)
ID: 168522 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/168522
ID: 168536 Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: h
On 11/10/2017 06:32 AM, Richard Shaw wrote:
> On Fri, Nov 10, 2017 at 8:25 AM, Christopher
> wrote:
>
> +1000 from me.
>
> I maintain or co-maintain probably more than 60 packages and I still don't
> completely get it. I've read the wiki, I watched the video on arbitrary
> branching and I *KINDA
On Fri, Nov 10, 2017 at 11:18 AM, Matthew Miller
wrote:
And, on a even bigger note, the F27 July-to-October experiment worked
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like
to suggest that if the April/May
On 11/10/2017 07:01 AM, Richard W.M. Jones wrote:
> On Fri, Nov 10, 2017 at 06:33:09AM -0800, John Reiser wrote:
>> On 11/10/2017 1058Z, Richard W.M. Jones wrote:
>>
>>> 24 hours and counting ...
>>>
>>> I talked to someone on #fedora-admin about this and it is caused by
>>> Koji having to load the
> Full details are in cap_from_text(3) by the looks of it.
Unfortunately, no. None of the fine manuals I located explain the difference
between ep and just p flags :( Everyone seems to use +ep blindly, but the
Fedora spec only adds p?
Regards,
--
Nicolas mailhot
__
- Mail original -
De: "Jeffrey Ollie"
> Instead of setting CAP_NET_RAW on the binary, why not have systemd give the
> service the capability at runtime? The blackbox exporter isn't something
> that you run from the CLI much anyway is it?
Yes that's another solution, I hadn't thought so f
On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
> [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
This looks generally good to me. The one change I would make is to
add to "Tue: Primary date from which rest of schedule derives". Make
that:
Tue: Primary date
On 10/11/17 16:47, nicolas.mail...@laposte.net wrote:
Thanks a lot, I should have thought of it myself, I must be tired today.
Is there a difference between
setcap cap_net_raw+ep
and
%caps(cap_net_raw=p)
I can't seem to locate a correct setcap or %caps() reference
I imagine you want =ep to
Missing expected images:
Workstation live i386
Kde live i386
Failed openQA tests: 6/137 (x86_64)
New failures (same test did not fail in 27-20171110.n.0):
ID: 168421 Test: x86_64 Workstation Ostree-dvd_ostree-iso
base_services_start
URL: https://openqa.fedoraproject.org/tests/168421
ID
Instead of setting CAP_NET_RAW on the binary, why not have systemd give the
service the capability at runtime? The blackbox exporter isn't something
that you run from the CLI much anyway is it?
Here's what part of my service file looks like:
[Service]
User=blackbox_exporter
Group=blackbox_exporte
Hi Tom
Thanks a lot, I should have thought of it myself, I must be tired today.
Is there a difference between
setcap cap_net_raw+ep
and
%caps(cap_net_raw=p)
I can't seem to locate a correct setcap or %caps() reference
Regards,
--
Nicolas Mailhot
_
OLD: Fedora-Modular-27-20171110.n.0
NEW: Fedora-Modular-27-20171110.n.1
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0.00 B
Size of dropped packages
Hi,
There is a RPM macro for it. You may find a good example in the spec file of
wireshark
On November 10, 2017 5:07:28 PM GMT+01:00, nicolas.mail...@laposte.net wrote:
>Hi,
>
>I'm building the prometheus blackbox exporter that needs the
>CAP_NET_RAW capability to conduct ICMP probes (I don't w
On 10/11/17 16:07, nicolas.mail...@laposte.net wrote:
I'm building the prometheus blackbox exporter that needs the CAP_NET_RAW
capability to conduct ICMP probes (I don't want to run it as root)
I've done the naïve
setcap cap_net_raw+ep
/builddir/build/BUILDROOT/prometheus-blackbox-exporter-0.
Hi everybody,
I tried to merge together all the changes we were facing during the
last time with regards to Changes Policy & Fedora Release Life Cycle.
The outcome is available in [1] and [2]. Before I will ask FESCo for a
review, I would like to ask anyone who is interested for a review and
comme
Hi,
I'm building the prometheus blackbox exporter that needs the CAP_NET_RAW
capability to conduct ICMP probes (I don't want to run it as root)
I've done the naïve
setcap cap_net_raw+ep
/builddir/build/BUILDROOT/prometheus-blackbox-exporter-0.10.0-1.fc28.llt.x86_64/usr/bin/prometheus-blackbox-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-11-10 at 14:39 +0100, Florian Weimer wrote:
> On 11/08/2017 06:08 PM, Björn 'besser82' Esser wrote:
> > Hello everyone,
> >
> > since there has been some discussion in the last time about
> > removing
> > libcrypt from glibc in some tim
On Fri, Nov 10, 2017 at 06:33:09AM -0800, John Reiser wrote:
> On 11/10/2017 1058Z, Richard W.M. Jones wrote:
>
> >24 hours and counting ...
> >
> >I talked to someone on #fedora-admin about this and it is caused by
> >Koji having to load the metadata (files, dependencies etc) of every
> >RPM into
On Fri, Nov 10, 2017 at 09:12:33AM -0500, Neal Gompa wrote:
> On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
> >> Zbigniew Jędrzejewski-Szmek wrote:
> >> > The fedora-release package contains stuff that is tie
On 11/10/2017 1058Z, Richard W.M. Jones wrote:
24 hours and counting ...
I talked to someone on #fedora-admin about this and it is caused by
Koji having to load the metadata (files, dependencies etc) of every
RPM into its database. Combined with the fact this happens to be
running on s390x and
On Fri, Nov 10, 2017 at 8:25 AM, Christopher
wrote:
>
> The biggest concerns/questions I have about modularity are probably not
> even the biggest challenges the modularity effort has to overcome. My
> concerns/questions are really about "what's my role in this?". I'm not
> involved in the releas
On Fri, Nov 10, 2017 at 9:02 AM Neal Gompa wrote:
> On Fri, Nov 10, 2017 at 8:40 AM, Kalev Lember
> wrote:
> > On 11/10/2017 02:23 PM, Kevin Kofler wrote:
> >> Please just ignore this module nonsense. The more maintainers boycott
> it,
> >> the less likely it is to succeed and produce completely
On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
>> Zbigniew Jędrzejewski-Szmek wrote:
>> > The fedora-release package contains stuff that is tied to each Fedora
>> > version and changes slowly, and it also contains
On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > The fedora-release package contains stuff that is tied to each Fedora
> > version and changes slowly, and it also contains the preset files for
> > systemd units, which change fairly often (a few
On 11/10/2017 02:21 PM, Kevin Kofler wrote:
Björn 'besser82' Esser wrote:
libxcrypt will be fully binary compatible with software linked against
glibc's libcrypt and does not require any rebuilds. However, the
converse is not true: programs linked against libxcrypt will not work
with glibc's li
On Fri, Nov 10, 2017 at 8:40 AM, Kalev Lember wrote:
> On 11/10/2017 02:23 PM, Kevin Kofler wrote:
>> Please just ignore this module nonsense. The more maintainers boycott it,
>> the less likely it is to succeed and produce completely unnecessary extra
>> work for you, me and all the other maintai
Zbigniew Jędrzejewski-Szmek wrote:
> The fedora-release package contains stuff that is tied to each Fedora
> version and changes slowly, and it also contains the preset files for
> systemd units, which change fairly often (a few requests per month).
Why not have a separate fedora-presets then? Jus
On 11/09/2017 02:26 AM, Yaakov Selkowitz wrote:
On 2017-11-08 11:08, Björn 'besser82' Esser wrote:
since there has been some discussion in the last time about removing
libcrypt from glibc in some time [1,2,3,4] and splitting it out into a
separate project which can evolve quicker, I'd like to he
On 11/10/2017 02:23 PM, Kevin Kofler wrote:
> Please just ignore this module nonsense. The more maintainers boycott it,
> the less likely it is to succeed and produce completely unnecessary extra
> work for you, me and all the other maintainers.
Kevin, please stop the trolling and belittling oth
On 11/08/2017 06:08 PM, Björn 'besser82' Esser wrote:
Hello everyone,
since there has been some discussion in the last time about removing
libcrypt from glibc in some time [1,2,3,4] and splitting it out into a
separate project which can evolve quicker, I'd like to hear your
oppinion about replac
Christopher wrote:
> Is it necessary for maintainers to create modules for their RPM packages?
> Is modularity something that a maintainer for an RPM package must deal
> with?
Please just ignore this module nonsense. The more maintainers boycott it,
the less likely it is to succeed and produce co
Björn 'besser82' Esser wrote:
> libxcrypt will be fully binary compatible with software linked against
> glibc's libcrypt and does not require any rebuilds. However, the
> converse is not true: programs linked against libxcrypt will not work
> with glibc's libcrypt. It comes with a set of extende
= System Wide Change: time-1.8 =
https://fedoraproject.org/wiki/Changes/time-1.8
Change owner(s):
* Petr
A new time tool version 1.8 has changed output format.
== Detailed Description ==
After many years a new 1.8 version of time tool was released. This
version brings some noticeable changes:
Missing expected images:
Workstation live i386
Kde live i386
Failed openQA tests: 6/137 (x86_64)
New failures (same test did not fail in 27-20171105.n.0):
ID: 168248 Test: x86_64 Workstation Ostree-dvd_ostree-iso
install_default_upload
URL: https://openqa.fedoraproject.org/tests/168248
ID
On Thu, Nov 09, 2017 at 01:52:19PM +, Richard W.M. Jones wrote:
> On Thu, Nov 09, 2017 at 12:01:44PM +, Richard W.M. Jones wrote:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=23008582
> >
> > This has been stuck in the final tagging stage for must be at least 1
> > hour now
On 2017-11-09 07:27, Zdenek Dohnal wrote:
Adding gtk+ maintainer. Paul, would you mind commenting about this
issue?
On 11/09/2017 01:07 AM, Michael Catanzaro wrote:
On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa wrote:
libkprint, kde-print-manager, etc. may have dependencies that make
the mix i
45 matches
Mail list logo
