date:20180313

Re: GNOME 3.28.0 megaupdate

2018-03-13 Thread Fabio Valentini

On Mon, Mar 12, 2018 at 10:09 AM, Kalev Lember  wrote:
> Hi all,
>
> I'm wrangling the GNOME 3.28.0 builds in Fedora and the plan is to
> submit a single megaupdate with all of 3.28.0 builds into Bodhi. If
> you're helping with builds, please use 'fedpkg build --target f28-gnome'
> for F28 builds and I'll pick your build up when submitting the bodhi
> update later this week.
>
> Thanks,
> Kalev

Hi Kalev,

I've also added updated (re-)builds of gala and wingpanel to the side
tag today. They both link against libmutter*, which had an soname bump
recently (since version 3.27.92, I believe), and I adapted and rebuilt
them in the f28-gnome side tag so your mega-update doesn't create
broken dependencies (at least not due to any of my packages).

Thanks,
Fabio

 ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GNOME 3.28.0 megaupdate

2018-03-13 Thread Kalev Lember

On 03/13/2018 08:00 PM, Fabio Valentini wrote:
> On Mon, Mar 12, 2018 at 10:09 AM, Kalev Lember  wrote:
>> Hi all,
>>
>> I'm wrangling the GNOME 3.28.0 builds in Fedora and the plan is to
>> submit a single megaupdate with all of 3.28.0 builds into Bodhi. If
>> you're helping with builds, please use 'fedpkg build --target f28-gnome'
>> for F28 builds and I'll pick your build up when submitting the bodhi
>> update later this week.
>>
>> Thanks,
>> Kalev
> 
> Hi Kalev,
> 
> I've also added updated (re-)builds of gala and wingpanel to the side
> tag today. They both link against libmutter*, which had an soname bump
> recently (since version 3.27.92, I believe), and I adapted and rebuilt
> them in the f28-gnome side tag so your mega-update doesn't create
> broken dependencies (at least not due to any of my packages).

Hi Fabio, libmutter soname bump is already in stable (it was in mutter
3.27.92 that's already tagged with f28,
https://koji.fedoraproject.org/koji/buildinfo?buildID=1053846), but
sure, let's include the rebuilds in the megaupdate. Thanks!

I've filed the update in Bodhi now,
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5ebe0eb1f2

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-13 Thread Emmanuel Seyman

* Igor Gnatenko [07/03/2018 08:43] :
>
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.

I've fixed the following:

perl-AI-DecisionTree
perl-Algorithm-FastPermute
perl-Algorithm-SVM
perl-CSS-Minifier-XS
perl-Crypt-RC4-XS
perl-FCGI
perl-GStreamer-Interfaces
perl-Geo-IP
perl-HTML-Template-Pro
perl-Search-Xapian
perl-Socket-MsgHdr
perl-Sys-CPU
perl-Text-CHM
perl-Text-CharWidth
perl-Text-ExtractWords
perl-Text-Ngram
perl-Tk-TableMatrix
perl-URI-Escape-XS
perl-Unicode-Map8
perl-Unicode-String
perl-XML-Bare
perl-re-engine-RE2

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora-Atomic 27-20180313.0 compose check report

2018-03-13 Thread Fedora compose checker

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

2018-03-13 Thread Milan Crha

On Mon, 2018-03-12 at 17:27 +0100, Pierre-Yves Chibon wrote:
> Does that sound right?

Hi,
yes, it does. Thanks.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken rawhide buildroot/tools?

2018-03-13 Thread Emmanuel Seyman

* Jan Synacek [13/03/2018 09:59] :
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25678436

From the root.log:

DEBUG util.py:439:  No matching package to install: 'NetworkManager-glib-devel'
DEBUG util.py:439:  Not all dependencies satisfied
DEBUG util.py:439:  Error: Some packages could not be found.
DEBUG util.py:577:  Child return code was: 1

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30

2018-03-13 Thread Nikos Mavrogiannopoulos

On Wed, 2017-11-08 at 18:08 +0100, 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 replacing glibc's libcrypt with libxcrypt [5] for
> Fedora
> 29 (or 30).

A bit late, but thank you for driving that effort! It was time to move
to a better crypt lib.

> Anyways, before this can happen, there is still some work to be done
> with libxcrypt, like adding a FIPS mode or FIPS compliance in a
> different way.

I agree with Florian's comment on that.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to get qtpass RPM into EPEL7?

2018-03-13 Thread Vascom

I can take it and maintain for EPEL.

вт, 13 мар. 2018 г. в 12:16, Marcin Dulak :

> Hi,
>
> I would like qtpass is built for EPEL7, but the maintainer is not
> interested.
> I provided a patch for EPEL7 build
> https://bugzilla.redhat.com/show_bug.cgi?id=1541439
> How to proceed further?
>
> Best regards,
>
> Marcin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: QMake equivalent of CMake flag -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}

2018-03-13 Thread Germano Massullo

Il 11/03/2018 01:56, Kevin Kofler ha scritto:
> The upstream makefile hardcodes /usr/lib here:
> https://github.com/open-eid/chrome-token-signing/blob/master/host-linux/chrome-token-signing.pro#L22
> The easiest fix is probably to just change:
> ffconf.path = /usr/lib/mozilla/native-messaging-hosts
> to:
> ffconf.path = $$LIBDIR/mozilla/native-messaging-hosts
> with a patch and pass LIBDIR=%{_libdir} on the command line (in the
> specfile, along with all the other command line arguments you are passing).

Thank you, I will proceed in such way
** UPDATE ** I let upstream read your message and I think the following
pull request has been made based on your suggestions
https://github.com/open-eid/chrome-token-signing/pull/100

> But I see a bigger issue here: THIS PACKAGE BUNDLES A PREBUILT BINARY XPI
> with the Firefox extension
> (https://github.com/open-eid/chrome-token-signing/blob/master/%7B443830f0-1fff-4f9a-aa1e-444bafbc7319%7D.xpi).
> This is NOT allowed in Fedora and should never have passed review. The
> package should instead rebuild the XPI from source. It will not be signed,
> but the Fedora Firefox accepts unsigned extensions if they are installed in
> system-wide directories.

Ok I will compile the extension from sources.

> By the way, Fedora ships the chromium browser which should be able to load
> the Chrome extension. You may have to change /etc/opt/chrome to
> /etc/chromium in hostconf.path, not sure whether Chromium checks both. And
> then there is that /opt/google/chrome/ckjefchnfjhjfedoccjbhjpbncimppeg.json
> that is apparently setting up auto-downloading the prebuilt extension from
> upstream (or really, from Google's store). (Just like the Firefox one, it is
> NOT built with the source code.) This file is NOT shippable as is, also
> because:
> 1. Fedora packages MUST NOT install to /opt. I am not sure what the correct
>directory actually is for Chromium, and
> 2. that file sets up auto-updating the extension from upstream. But we do
>NOT want to have packaged extensions updated directly from upstream.
> But
> 1. 
> https://github.com/open-eid/chrome-token-signing/blob/master/host-linux/ee.ria.esteid.json
>references that ckjefchnfjhjfedoccjbhjpbncimppeg extension as the only
>allowed origin, so that would need updating too if the ID changes.
> 2. I have no idea in what paths Chromium looks for systemwide extensions. If
>it's only /opt, we are stuck and need Chromium patched first.
> 3. Last I checked, Chromium did not require signed extensions (only Chrome
>did, and only on some platforms), but this may have changed, in which
>case Chromium would have to be patched, too.

Once I the work on the extension will be finished, if I will have some
free time I will try patching the package to work on Chromium too

> PS: I see one similar package in Fedora:
> https://src.fedoraproject.org/cgit/rpms/chrome-gnome-shell.git/tree/chrome-gnome-shell.spec
> but they chickened out of shipping the browser extensions entirely and ship
> only the native-messaging-host part. So you have to install the package AND
> install the extension from the browser's extension installation mechanism.
>
> This would be a solution if you cannot package the extensions in a way
> compliant with Fedora policies, but it is not very user-friendly.

I don't know if such approach would work on Firefox. For example, the
most important part of chrome-token-signing package is the JSON file and
I have been told that purpose of the extension is only to let Firefox
use the related JSON file. In a few words, you can't have such kind JSON
file without a related extension.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Google Summer of Code 2018

2018-03-13 Thread Martin Bříza


Hi,

the student application period for this year's GSoC has begun!
If you were thinking about posting a project idea or applying as a mentor,  
there's still time to do so!


For this year, we have a project idea page here: [1].
You can create a new idea by opening a pull request against  
mentored-projects [2] - the file you're looking for is  
/gsoc/2018/ideas.adoc .


Please feel free to contact me if you need help with anything!
mbriza on freenode, martinbriza on telegram or this email directly,  
whichever works for you.


Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Google Summer of Code 2018

2018-03-13 Thread Martin Bříza


On Tue, 13 Mar 2018 11:32:18 +0100, Martin Bříza  wrote:


Hi,

the student application period for this year's GSoC has begun!
If you were thinking about posting a project idea or applying as a  
mentor, there's still time to do so!


For this year, we have a project idea page here: [1].
You can create a new idea by opening a pull request against  
mentored-projects [2] - the file you're looking for is  
/gsoc/2018/ideas.adoc .


Please feel free to contact me if you need help with anything!
mbriza on freenode, martinbriza on telegram or this email directly,  
whichever works for you.


Martin


I forgot the links:

[1] https://docs.fedoraproject.org/mentored-projects/gsoc/2018/index.html
[2] https://pagure.io/mentored-projects
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken rawhide buildroot/tools?

2018-03-13 Thread Jan Synacek

Hi,

I was trying to update pidgin, but the package doesn't build and it
doesn't seem to be a packaging problem to me [1]. What's happening?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25678436
-- 
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken rawhide buildroot/tools?

2018-03-13 Thread Fabio Valentini

On Tue, Mar 13, 2018, 10:00 Jan Synacek  wrote:

> Hi,
>
> I was trying to update pidgin, but the package doesn't build and it
> doesn't seem to be a packaging problem to me [1]. What's happening?
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25678436


It looks like it's still referencing / trying to build against libnm-glib,
which has been deprecated and retired from rawhide.

Fabio


> Jan Synacek
> Software Engineer, Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken rawhide buildroot/tools?

2018-03-13 Thread Jan Synacek

On Tue, Mar 13, 2018 at 10:14 AM, Emmanuel Seyman  wrote:
> * Jan Synacek [13/03/2018 09:59] :
>>
>> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25678436
>
> From the root.log:
>
> DEBUG util.py:439:  No matching package to install: 
> 'NetworkManager-glib-devel'

Never mind, I'm blind.

Thanks!
-- 
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How to get qtpass RPM into EPEL7?

2018-03-13 Thread Marcin Dulak

Hi,

I would like qtpass is built for EPEL7, but the maintainer is not interested.
I provided a patch for EPEL7 build 
https://bugzilla.redhat.com/show_bug.cgi?id=1541439
How to proceed further?

Best regards,

Marcin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Enable dbus-broker

2018-03-13 Thread Tom Gundersen

On Fri, Feb 23, 2018 at 7:59 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote:
>> Proposed System Wide Change: Enable dbus-broker
>> https://fedoraproject.org/wiki/Changes/EnableDbusBroker
>
> What about renaming this to DbusBrokerAsTheDefaultDbusImplementation?
>
> "Enable" correctly describes the technical operation (systemctl invocation),
> but it isn't obvious just from the title that this is about replacing
> normal dbus daemon.

Will do.

>> == Scope ==
>> * Proposal owners:
>> ** Fix regressions.
>> ** Enabledbus-broker.service in system and user-global context of
>> systemd (via systemd presets).
>
>> ** Pull in dbus-broker package from dbus package.
> I'm not sure if this is the correct way to do this. People might want
> to install systems with just normal dbus (e.g. in containers or minimal
> installations). It'd be better to update comps [1] to pull in dbus-broker
> instead of dbus into @Standard.
>
> [Based on our preeliminary discussions]
> This replaces the system wide bus and user busses.
> What about the at-spi2 private dbus instance?

I have submitted a patch to enable at-spi2 to use dbus-broker in
addition to dbus-daemon.

> Would dbus-broker be fast
> enough to change gdm to use the user bus?

/gdm/at-spi2/ ?

A priori, I would have thought so, but I have not tried to reproduce
their benchmarks, so I can't say for certain.

> Do you have plans to replace this last use too?

It is certainly possible, but I see this as an orthogonal issue to
providing the system/user bus so it is not something we have looked
into (apart from making sure it is possible), and ultimately it is up
to the at-spi2 maintainers what bus implementation they want to depend
on.

> If dbus-broker becomes the default like described in the Change page,
> what other dependencies on dbus will remain?

On the daemon itself, none to my knowledge (assuming my at-spi2 patch
is merged).

> Since this is already testable [2], what about asking for testing on
> devel-announce@ and test-announce@ ? This is a pretty big change, and
> I don't we can make the decision to use this by default without
> widespread testing.

Will do.

Cheers,

Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

2018-03-13 Thread Mark Wielaard

On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote:
> Some x86_64 packages need a 32-bit glibc during build time.  Koji
> does not provide it.
> [...]
> Comments?  Suggestions?

Why don't we just make koji provide it?
That is how a normal 64bit Fedora install looks like. Those have the
32bit packages available. So it makes sense to me that the koji build
repo also provides it for consistency. Why isn't the koji buildroot
just like a normal install?

Cheers,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

speed-dreams compilation problem

2018-03-13 Thread Martin Gansser

Hi,
speed-dreams fails on rawhide, f28, f27 and f26 with this error message:

-- Checking for module 'FreeSOLID'
--   Package 'qhull', required by 'FreeSOLID', not found
-- Checking for module 'SOLID'
--   Package 'SOLID', required by 'virtual:world', not found
-- Looking for SOLID - found (/usr/lib64/libFreeSOLID.so)
-- Looking for library Solid - found
-- Version '2.2-trunk'
CMake Deprecation Warning at cmake/internaldeps.cmake:242 (cmake_policy):
  The OLD behavior for policy CMP0026 will be removed from a future version
  of CMake.
  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  src/libs/tgf/CMakeLists.txt:48 (ADD_SDLIB_LIBRARY)
-- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR) 
CMake Error at cmake/thirdpartydeps.cmake:449 (MESSAGE):
  Cannot find CURL header files
Call Stack (most recent call first):
  src/libs/tgfclient/CMakeLists.txt:17 (ADD_CURL_INCLUDEDIR)
-- Configuring incomplete, errors occurred!
See also 
"/builddir/build/BUILD/speed-dreams-src-base-2.2.2-0.1.20180309svn6528.rc2.fc27.1/CMakeFiles/CMakeOutput.log".
See also 
"/builddir/build/BUILD/speed-dreams-src-base-2.2.2-0.1.20180309svn6528.rc2.fc27.1/CMakeFiles/CMakeError.log".
RPM build errors:

koji build.log: 
https://kojipkgs.fedoraproject.org//work/tasks/2635/25682635/build.log

https://koji.fedoraproject.org/koji/taskinfo?taskID=25682285
https://koji.fedoraproject.org/koji/taskinfo?taskID=25682291
https://koji.fedoraproject.org/koji/taskinfo?taskID=25682293
https://koji.fedoraproject.org/koji/taskinfo?taskID=25682306

how can this be solved ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg request-repo always fails - Could not execute request_repo

2018-03-13 Thread Chenxiong Qi

On Fri, 2018-02-16 at 10:33 +, Martin Gansser wrote:
> Hi,
> 
> tried to create a new repo, but this fails always with:
> 
> [martin@f27 ~]$ fedpkg --module-name gnome-shell-extension-netspeed
> request-repo 1377631
> Could not execute request_repo: The following error occurred while
> creating a new issue in Pagure: Invalid or expired token. Please
> visit https://pagure.io/ to get or renew your API token.

Have you checked if the token is valid, like permission?

> 
> already create a new API Token on [1] and migrate the API token
> described here [2]
> 
> [1] https://pagure.io/
> [2] https://fedoraproject.org/wiki/Changes/fedrepo-req-to-fedpkg#Migr
> ation
> 
> any help ?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Enable dbus-broker

2018-03-13 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Mar 13, 2018 at 01:38:24PM +0100, Tom Gundersen wrote:
> On Fri, Feb 23, 2018 at 7:59 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote:
> >> Proposed System Wide Change: Enable dbus-broker
> >> https://fedoraproject.org/wiki/Changes/EnableDbusBroker
> >
> > What about renaming this to DbusBrokerAsTheDefaultDbusImplementation?
> >
> > "Enable" correctly describes the technical operation (systemctl invocation),
> > but it isn't obvious just from the title that this is about replacing
> > normal dbus daemon.
> 
> Will do.
> 
> >> == Scope ==
> >> * Proposal owners:
> >> ** Fix regressions.
> >> ** Enabledbus-broker.service in system and user-global context of
> >> systemd (via systemd presets).
> >
> >> ** Pull in dbus-broker package from dbus package.
> > I'm not sure if this is the correct way to do this. People might want
> > to install systems with just normal dbus (e.g. in containers or minimal
> > installations). It'd be better to update comps [1] to pull in dbus-broker
> > instead of dbus into @Standard.
> >
> > [Based on our preeliminary discussions]
> > This replaces the system wide bus and user busses.
> > What about the at-spi2 private dbus instance?
> 
> I have submitted a patch to enable at-spi2 to use dbus-broker in
> addition to dbus-daemon.
> 
> > Would dbus-broker be fast
> > enough to change gdm to use the user bus?
> 
> /gdm/at-spi2/ ?
Yes, not sure what happened there.

> A priori, I would have thought so, but I have not tried to reproduce
> their benchmarks, so I can't say for certain.
> 
> > Do you have plans to replace this last use too?
> 
> It is certainly possible, but I see this as an orthogonal issue to
> providing the system/user bus so it is not something we have looked
> into (apart from making sure it is possible), and ultimately it is up
> to the at-spi2 maintainers what bus implementation they want to depend
> on.
FTR: https://github.com/GNOME/at-spi2-core/pull/2

From the point of view of the whole distro, it makes a lot of sense to
switch all uses. Maybe not all at once, to make it easier to diagnose
regressions, but in the long term. Carrying two implementations increases
the disk and memory footprint, the attack and bug surface, the number
of updates, and hence the amount of testing. In this case none of those
costs are very big, but since dbus runs pretty much everywhere, it still
makes sense to (plan to) minimize them.

> > If dbus-broker becomes the default like described in the Change page,
> > what other dependencies on dbus will remain?
> 
> On the daemon itself, none to my knowledge (assuming my at-spi2 patch
> is merged).
Great! That's the answer I was hoping for ;)

> > Since this is already testable [2], what about asking for testing on
> > devel-announce@ and test-announce@ ? This is a pretty big change, and
> > I don't we can make the decision to use this by default without
> > widespread testing.
> 
> Will do.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

2018-03-13 Thread Jakub Jelinek

On Tue, Mar 13, 2018 at 02:58:37PM +0100, Mark Wielaard wrote:
> On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote:
> > Some x86_64 packages need a 32-bit glibc during build time.  Koji
> > does not provide it.
> > [...]
> > Comments?  Suggestions?
> 
> Why don't we just make koji provide it?
> That is how a normal 64bit Fedora install looks like. Those have the
> 32bit packages available. So it makes sense to me that the koji build
> repo also provides it for consistency. Why isn't the koji buildroot
> just like a normal install?

The right fix would be to make koji deal with multilibs properly,
mock can handle that fine already, then glibc32 wouldn't be needed at all.

If that doesn't happen, we need glibc32, but only 0.01% of packages actually
need it, so e.g. forcing it into every buildroot would be a vaste of time.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: new section for 'Join the package collection maintainers'

2018-03-13 Thread Jonathan Wakely

On 12/03/18 21:02 -0300, Athos Ribeiro wrote:

On Tue, Mar 13, 2018 at 12:35:19AM +0100, René Genz wrote:

the other day I wanted to contribute a fix to an RPM package's spec file.

I struggled with uploading my changes to my fork on src.fedoraproject.org.
puiterwijk and clime from #fedora-admin IRC channel on freenode.net pointed me
in the right direction:
* 'packager' status for FAS account required, else all repos, including forks,
are read-only
* workaround is to use a "Remote pull-request"
* requirement of 'packager' status is being worked on.

With this information contributing the fix was easy.

[snip...]

Now I try to add the information to Fedora's documentation.
From my point of view, this would be a good website:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

I propose to:
add a new major point 2, so:
"2. How to join the Fedora Package Collection Maintainers?"
will be:
"3. How to join the Fedora Package Collection Maintainers?"

Should your new item really come first? The page is about joining the
package maintainers, so why should "how to contribute without joining"
come before "how to join"?

The new major point 2 would be something like:
---8<---
2. Notes for one-off contributors

Your contribution is welcome.

At first you must https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Create_a_Fedora_Account)>.

Before proceeding, please sync your account by login on
https://src.fedoraproject.org/ using your FAS credentials.

See 2.3.1 - It deals with the FAS account creation. Maybe you could link
there to avoid replication :)

At the moment any repos, including forks, on https://src.fedoraproject.org require your
FAS account to have 'packager' status for write access (and read access if you use the
"SSH" Source GIT URL).

I don't think it's helpful to mention the SSH URL part. If you don't
have write access, just use the HTTPS URL.

Either you get the status or you use a https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
f.e. with https://pagure.io/new)>, as a workaround.

This should be "for example" or "e.g." not "f.e."

And it doesn't seem like a workaround, it seems like the proper way to
do it.

The requirement to be a packager is being worked on.
---8<---

I would rather see something like:

If you are not an Fedora packager, i.e., you are not in the 'packager'
FAS group, you can send pull requests to src.fedoraproject.org. To do

Yes, I agree it's better to say "in the 'packager' FAS group" rather
than "have 'packager' status".

so, you must use a https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
f.e. with https://pagure.io/new)>

How about:

3. One-off contributions

Changes to existing packages can be suggested by submitting https://docs.pagure.org/pagure/usage/pull_requests.html)>.
You must have a to create
a pull request. If your account is not in the 'packager' group then
you cannot create a fork on src.fedoraproject.org so must use an
external Git hosting platform (e.g. https://pagure.io/new) and use a
https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review Request: glusterd2- new management daemon for GlusterFS

2018-03-13 Thread Kaushal M

Hi all,

I'm looking for reviewers for the review request [1] for the glusterd2
package. It has been reviewed once before on initial submission by
Robert-Andre. The spec is updated based on the comments recieved, and
the dependencies have been packaged and/or updated in rawhide. The
package is now ready for acceptance IMO.

I'm up for swapping reviews to help move this faster.

[1]: https://bugzilla.redhat.com/1540553
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Request for testing: dbus-broker as system and user bus

2018-03-13 Thread Tom Gundersen

Hi,

dbus-broker is a new DBus message bus implementation. We are proposing
it as the default in Fedora as of F29 [0], and as such we would be
grateful for as much testing as possible before the switch is made.

For instructions on how to test, see [1].

Cheers,

Tom and David

[0]: 

[1]: 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: new section for 'Join the package collection maintainers'

2018-03-13 Thread Athos Ribeiro

On Tue, Mar 13, 2018 at 02:13:14PM +, Jonathan Wakely wrote:
[snip...]
> How about:
> 
> 3. One-off contributions
> 
> Changes to existing packages can be suggested by submitting  requests (https://docs.pagure.org/pagure/usage/pull_requests.html)>.
> You must have a  to create
> a pull request. If your account is not in the 'packager' group then
> you cannot create a fork on src.fedoraproject.org so must use an
> external Git hosting platform (e.g. https://pagure.io/new) and use a
>  (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

I believe this will do it. +1

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: speed-dreams compilation problem

2018-03-13 Thread Martin Gansser

forgot to post the CMakeError.log file:
CMakeError.log: 
https://martinkg.fedorapeople.org/Packages/speed-dreams/CMakeError.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: speed-dreams compilation problem

2018-03-13 Thread Robert-André Mauchin

On mardi 13 mars 2018 15:14:51 CET Martin Gansser wrote:
> -- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR)
> CMake Error at cmake/thirdpartydeps.cmake:449 (MESSAGE):
>   Cannot find CURL header files

Well did you try the obvious, adding libcurl-devel as a BR?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

2018-03-13 Thread Florian Weimer


On 03/13/2018 03:03 PM, Jakub Jelinek wrote:

On Tue, Mar 13, 2018 at 02:58:37PM +0100, Mark Wielaard wrote:

On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote:

Some x86_64 packages need a 32-bit glibc during build time.  Koji
does not provide it.
[...]
Comments?  Suggestions?


Why don't we just make koji provide it?
That is how a normal 64bit Fedora install looks like. Those have the
32bit packages available. So it makes sense to me that the koji build
repo also provides it for consistency. Why isn't the koji buildroot
just like a normal install?


The right fix would be to make koji deal with multilibs properly,
mock can handle that fine already, then glibc32 wouldn't be needed at all.


I think we requested these feature fifteen years ago, even before there 
was Koji.  I recently (two months ago) tried to bump the priority, but 
haven't heard anything back.  It's a pretty fringe use case, and 
probably needs major complications within Koji.


So we need to assume that we'll still need glibc32 going forward.

The big question, at this point, is what we as packages have to do to 
prevent leaking a rebuild into the compose.  As far as I understand it, 
every package rebuild will trigger this.  Build with --skip-tag and file 
a releng ticket to have it tagged correctly?



If that doesn't happen, we need glibc32, but only 0.01% of packages actually
need it, so e.g. forcing it into every buildroot would be a vaste of time.


It's actually a bit worse because since it's buildroot-only, we need to 
express build requires in such a way that they can be fulfilled by 
glibc-devel.i686.  Otherwise, people would not be able to rebuild these 
packages using mock.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Make dbus-broker the default DBus implementation

2018-03-13 Thread Jan Kurik

= Proposed System Wide Change: Make dbus-broker the default DBus
implementation =
https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation


Owner(s):
  * David Herrmann 
  * Tom Gundersen 


Enable dbus-broker.service to use dbus-broker as system and session
message bus backend.


== Detailed description ==
The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases.
The main focus points of dbus-broker are reliability, scalability and
security. The dbus-broker project tries to improve on these points
over dbus-daemon, and thus provide a better alternative. And in-depth
analysis can be found in the initial announcement of dbus-broker. An
excerpt:

* Accounting: dbus-broker maintains per-user accounting, including
inter-user quotas. This guarantees that no single user can cause
irregularly high memory consumption in the daemon. Unlike dbus-broker,
dbus-daemon accounts memory in a multi-tier system, based on plain
resource counters on users, connections, and other resources. The
multi-tier system suffers from resource-chaining-exhaustion, where
clients effectively circumvent the accounting by creating multiple
connections/objects, which themselves grant them each a new set of
quotas. The single-tier accounting scheme of dbus-broker avoids this,
while at the same time adding inter-user quotas to prevent misuse even
across clients.

* Reliability: While D-Bus is used on reliable transports, dbus-daemon
might still silently drop messages and given circumstances. This is
the only possible solution dbus-daemon has, given several of its
runtime guarantees. The dbus-broker project changed the architecture
of the bus daemon to a degree, that it can provide many guarantees,
including that no message will be silently, or unexpectedly, dropped.

* Scalability: The message bus broker is a crucial infrastructure on
modern linux system, which is a hot-path for almost all IPC going on.
Hence, the broker should perform fast and be scalable to its users.
dbus-daemon has several **global** data-structures that affect the
overall scalability of independent message transactions. dbus-broker
does not employ any global data-structures (unless required by the
spec), as such any message transaction is only affected by the data
provided by the involved peers. Moreover, even for spec-defined global
behavior, dbus-broker avoids global data-structures, unless clients
actually make use of these obscure features. In several other cases,
dbus-daemon scales O(n) time looking up message targets and related
data. dbus-broker runs all these in O(log(n)) time.

* Linux-specific: The dbus-broker project was explicitly designed for
linux system, making use of many linux-specific APIs and behavior.
This allows mitigation of several possible DoS attacks.


== Scope ==
* Proposal owners:
** Fix regressions.
** Enable dbus-broker.service in system and user-global context of
systemd (via systemd presets).
** Pull in dbus-broker package from dbus package.

* Other developers:
** Watch for regressions

* Release engineering: #7262 https://pagure.io/releng/issues/7262

* List of deliverables:
N/A

* Policies and guidelines:
No changes needed.

* Trademark approval:
No changes needed.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28-20180313.n.0 compose check report

2018-03-13 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 19/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 202806  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/202806
ID: 202812  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/202812
ID: 202835  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/202835
ID: 202843  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/202843
ID: 202844  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202844
ID: 202845  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/202845
ID: 202853  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/202853
ID: 202855  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/202855
ID: 202856  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/202856
ID: 202858  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/202858
ID: 202862  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/202862
ID: 202863  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202863
ID: 202864  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/202864
ID: 202877  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/202877
ID: 202884  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/202884
ID: 202887  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/202887
ID: 202893  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/202893
ID: 202896  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/202896
ID: 202911  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/202911
ID: 202924  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/202924
ID: 202935  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/202935
ID: 202940  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/202940
ID: 202950  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/202950
ID: 202958  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/202958
ID: 202959  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/202959

Soft failed openQA tests: 66/137 (x86_64), 14/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 202798  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202798
ID: 202799  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202799
ID: 202801  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/202801
ID: 202802  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202802
ID: 202804  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/202804
ID: 202805  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/202805
ID: 202818  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/202818
ID: 202821  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202821
ID: 202822  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/202822
ID: 202823  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202823
ID: 202824  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202824
ID: 202825  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/202825
ID: 202828  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202828
ID: 202846  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/202846
ID: 202850  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/202850
ID: 202860  Test: x86_64 AtomicHost-dvd_ostree-iso

Re: New "tests" namespace to share test code

2018-03-13 Thread Petr Šplíchal

Hi!

We've had some more discussions regarding this topic within the CI
team. Here's a brief summary of the recommendation we agreed upon:

Tests may be written in different ways, but are enabled in a
standard way directly in the package git repository as defined
by the Standard Test Interface. [1]

Test code can be stored directly in the package git repository
(recommended as default) or fetched from another location hosted
in the Fedora infrastructure such as the Tests Namespace. [2] The
decision where the test code is stored is up to the package maintainer.

[1] https://fedoraproject.org/wiki/CI/Standard_Test_Interface
[2] https://fedoraproject.org/wiki/CI/Share_Test_Code

psss...

On 1 March 2018 at 18:06, Honza Horak  wrote:
> On 03/01/2018 04:00 PM, Petr Šplíchal wrote:

 To sum up what I've heard so far from the developer side:

 * I would like to enable tests for my component (yes, I want)
 * I will take care of them (really, I see the benefit in CI)
 * I want to easily collaborate on tests with qe (direct commits)
 * I don't want to give qe commit access to the rpms dist git
>>>
>>> This is quite likely the crux of the problem.
>>>
>>> Personally, I'm perfectly happy to give write access to any repo
>>> to people who have shown that they know what they are doing.
>>> We have pull requests in dist-git pagure now, and I think this is
>>> a better approach:
>>> 1. ask QE contributors to submit PRs
>>> 2. if enough cooperation happens and trust is established, give
>>>privileges to write to the repo directly, possibly with an agreement
>>>that this specific person should only touch tests, and not the
>>>packaging.
>>>
>>> I think it's perfectly fine to never get to point 2.: many many
>>> upstream projects require a review from a second person, or sometimes
>>> even two reviews before a PR is merged, which means that one _never_
>>> merges their own PR, and another contributor is always involved. We
>>> usually don't do this in dist-git, but I'm quite sure that requiring
>>> reviews for dist-git changes would raise quality and catch many silly
>>> mistakes. Either way, it's nowadays possible to cooperate using a
>>> single repo without fully trusting the other person, frictionlessly.
>>
>>
>> Good point. However, if there is a qe/devel team which prefers to
>> collaborate on tests in a separate repo because this is the most
>> efficient way they found so far, why should we stop them and try
>> to enforce a less efficient workflow? (Which they can workaround
>> by a different git repo.)
>>
 * I want to efficiently maintain tests long-term
 * I want to have just a single place for my tests (no duplication)
 * I don't want to backport new tests to old branches (enable once)
 * I want to easily enable testing for all supported branches
>>>
>>> Those four items depend strongly on the package. My thinking is
>>> biased by some specific usecases (mainly systemd), but I'm sure many
>>> other packages are like that: a lot of tests would be for new
>>> functionality, and then the tests _are_ tied to the branch being
>>> tested.
>>>
>>> While I agree that keeping tests separate avoids a bit of effort
>>> required to update multiple branches, this effort isn't very big. If
>>> the tests indeed apply cleanly to all branches, then it's just a
>>> matter of doing 'git merge' or 'git cherry-pick' once per branch.
>>>
 * I want to keep rpms dist git clean (just metadata & patches)
>>>
>>> Meh.
>>>
 * I want to run all available relevant tests (not to list them)
 * I want to execute set of tests based on a tag (e.g. Tier1)
>>>
>>> Those two sound like stuff that should be solved in the tooling,
>>> whatever is used to run tests.
>>>
 * I want an easy way to clone tests (fedpkg clone tests/pkg)
>>>
>>> Tests alone make no sense, you need something to test, and
>>> cloning one repo is easier than cloning two repos, so there's no
>>> advantage to the split here.
>>
>>
>> But "fedpkg clone tests" is easier than cloning from a "random"
>> git repository where I was forced to save my tests because I was
>> not allowed to save them in Fedora tests namespace.
>>
 I believe the tests namespace resolves them all.
>>>
>>> None of those arguments convince me that separate repos for tests are
>>> a good default. Sure, there are specific packages where this will make
>>> sense, or specific packagers with idiosyncratic workflows, but I'd
>>> rather "start small", with the simple configuration, and only move
>>> specific packages to the more complicated setup once that proves to
>>> be required.
>>
>>
>> Why default? Test namespace should be an option. Not the default.
>> Storing tests directly in dist git is and will be possible.
>> Anybody who finds this as a better way can do so. But why
>> enforcing this approach to all?
>
>
> +1 Exactly! I don't really see any reason why to force people to follow one
> way when there are obvious

Re: F29 System Wide Change: Make dbus-broker the default DBus implementation

2018-03-13 Thread Steve Grubb

Hello,

Just a quick question...dbus was patched to support SE Linux. I see no
mention of SE Linux support below. Does it replicate the same SE Linux
support?

Thanks,
-Steve

On Tue, 13 Mar 2018 17:32:20 +0100
Jan Kurik  wrote:

> = Proposed System Wide Change: Make dbus-broker the default DBus
> implementation =
> https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation
> 
> 
> Owner(s):
>   * David Herrmann 
>   * Tom Gundersen 
> 
> 
> Enable dbus-broker.service to use dbus-broker as system and session
> message bus backend.
> 
> 
> == Detailed description ==
> The dbus-broker project is an implementation of a message bus as
> defined by the D-Bus specification. Its aim is to provide high
> performance and reliability, while keeping compatibility to the D-Bus
> reference implementation. It is exclusively written for linux systems,
> and makes use of many modern features provided by recent linux kernel
> releases.
> The main focus points of dbus-broker are reliability, scalability and
> security. The dbus-broker project tries to improve on these points
> over dbus-daemon, and thus provide a better alternative. And in-depth
> analysis can be found in the initial announcement of dbus-broker. An
> excerpt:
> 
> * Accounting: dbus-broker maintains per-user accounting, including
> inter-user quotas. This guarantees that no single user can cause
> irregularly high memory consumption in the daemon. Unlike dbus-broker,
> dbus-daemon accounts memory in a multi-tier system, based on plain
> resource counters on users, connections, and other resources. The
> multi-tier system suffers from resource-chaining-exhaustion, where
> clients effectively circumvent the accounting by creating multiple
> connections/objects, which themselves grant them each a new set of
> quotas. The single-tier accounting scheme of dbus-broker avoids this,
> while at the same time adding inter-user quotas to prevent misuse even
> across clients.
> 
> * Reliability: While D-Bus is used on reliable transports, dbus-daemon
> might still silently drop messages and given circumstances. This is
> the only possible solution dbus-daemon has, given several of its
> runtime guarantees. The dbus-broker project changed the architecture
> of the bus daemon to a degree, that it can provide many guarantees,
> including that no message will be silently, or unexpectedly, dropped.
> 
> * Scalability: The message bus broker is a crucial infrastructure on
> modern linux system, which is a hot-path for almost all IPC going on.
> Hence, the broker should perform fast and be scalable to its users.
> dbus-daemon has several **global** data-structures that affect the
> overall scalability of independent message transactions. dbus-broker
> does not employ any global data-structures (unless required by the
> spec), as such any message transaction is only affected by the data
> provided by the involved peers. Moreover, even for spec-defined global
> behavior, dbus-broker avoids global data-structures, unless clients
> actually make use of these obscure features. In several other cases,
> dbus-daemon scales O(n) time looking up message targets and related
> data. dbus-broker runs all these in O(log(n)) time.
> 
> * Linux-specific: The dbus-broker project was explicitly designed for
> linux system, making use of many linux-specific APIs and behavior.
> This allows mitigation of several possible DoS attacks.
> 
> 
> == Scope ==
> * Proposal owners:
> ** Fix regressions.
> ** Enable dbus-broker.service in system and user-global context of
> systemd (via systemd presets).
> ** Pull in dbus-broker package from dbus package.
> 
> * Other developers:
> ** Watch for regressions
> 
> * Release engineering: #7262 https://pagure.io/releng/issues/7262
> 
> * List of deliverables:
> N/A
> 
> * Policies and guidelines:
> No changes needed.
> 
> * Trademark approval:
> No changes needed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

2018-03-13 Thread Mark Wielaard

Hi,

On Tue, Mar 13, 2018 at 03:31:40PM +0100, Florian Weimer wrote:
> On 03/13/2018 03:03 PM, Jakub Jelinek wrote:
> > The right fix would be to make koji deal with multilibs properly,
> > mock can handle that fine already, then glibc32 wouldn't be needed at all.
> 
> I think we requested these feature fifteen years ago, even before there was
> Koji.  I recently (two months ago) tried to bump the priority, but haven't
> heard anything back.  It's a pretty fringe use case, and probably needs
> major complications within Koji.
> 
> So we need to assume that we'll still need glibc32 going forward.
> 
> The big question, at this point, is what we as packages have to do to
> prevent leaking a rebuild into the compose.  As far as I understand it,
> every package rebuild will trigger this.  Build with --skip-tag and file a
> releng ticket to have it tagged correctly?

I sadly have no idea.

> > If that doesn't happen, we need glibc32, but only 0.01% of packages actually
> > need it, so e.g. forcing it into every buildroot would be a vaste of time.
> 
> It's actually a bit worse because since it's buildroot-only, we need to
> express build requires in such a way that they can be fulfilled by
> glibc-devel.i686.  Otherwise, people would not be able to rebuild these
> packages using mock.

Yeah, the current way to pull things in that works everywhere seems to
be to do use file based requires like /usr/lib/libc.so because otherwise
things break in koji.

I always assumed koji was just a mock running in "the cloud", but I assume
it is slightly more involved than that.

Cheers,

Mark
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

librsvg2 CVEs

2018-03-13 Thread Michael Schwendt

Why are CVEs about librsvg2 not being tracked within the package?
Bugzilla shows several CLOSED EOL and a few current ones not mentioned
within the package %changelog.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: new section for 'Join the package collection maintainers'

2018-03-13 Thread René Genz

On 13.03.2018 01:02, Athos Ribeiro wrote:
> On Tue, Mar 13, 2018 at 12:35:19AM +0100, René Genz wrote:
>> I propose to:
>> add a new major point 2, so:
>> "2. How to join the Fedora Package Collection Maintainers?"
>> will be:
>> "3. How to join the Fedora Package Collection Maintainers?"
>>
>> The new major point 2 would be something like:
>> ---8<---
>> 2. Notes for one-off contributors
>>
>> Your contribution is welcome.
>>
>> At first you must > (https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Create_a_Fedora_Account)>.
>>
>> Before proceeding, please sync your account by login on 
>> https://src.fedoraproject.org/ using your FAS credentials.
> 
> See 2.3.1 - It deals with the FAS account creation. Maybe you could link
> there to avoid replication :)
> 

The proposed link:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Create_a_Fedora_Account
links to section 2.1.3 "Create a Fedora Account".

Or do you recommend the following link for the same target?
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Fedora_Account

>>
>> At the moment any repos, including forks, on https://src.fedoraproject.org 
>> require your FAS account to have 'packager' status for write access (and 
>> read access if you use the "SSH" Source GIT URL).
>>
>> Either you get the status or you use a > (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
>>  f.e. with https://pagure.io/new)>, as a workaround.
>> The requirement to be a packager is being worked on.
>> ---8<---
> 
> I would rather see something like:
> 
> If you are not an Fedora packager, i.e., you are not in the 'packager'
> FAS group, you can send pull requests to  src.fedoraproject.org. To do
> so, you must use a  (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
> f.e. with https://pagure.io/new)>
> 

Your proposal is easier to read. I will use it.
To explain why non-packager have to use remote pull-requests, instead of 
forking on src.fedoraproject.org, I would append something like:

Any repos on https://src.fedoraproject.org, including forks, are read-only for 
non-packager. Only packager can write.
It is being worked on that forks will be writable for non-packager.

> Also, I do not understood what you meant with
> 
> "The requirement to be a packager is being worked on."

As far as I remember that is what puiterwijk wrote in the IRC channel.
Due to read-only forks for non-packager on src.fedoraproject.org the code must 
be hosted on a remote git repo and a remote pull-requests must be used.
I assume puiterwijk meant that in the future forks on src.fedoraproject.org 
will be writable for non-packager.

>>
>> What do you think?
> 
> I think it is valuable information and should be added to the wiki :)
> Thanks!
> 

Thank you for your support and help. :)

>> I can edit the wiki.
> 
> Can you? Note that to edit the wiki you must be in at least one extra
> FAS group other the the CLA ones.
> 

In my FAS account one group reads "wikiedit (user)".
I requested that membership in order to fix a wrong command in a SSSD or 
FreeIPA testcase in the wiki during Fedora 26 branching as far as I remember.
-- 
Kind regards,
René
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 compose report: 20180313.n.0 changes

2018-03-13 Thread Fedora Branched Report

OLD: Fedora-28-20180312.n.0
NEW: Fedora-28-20180313.n.0

= SUMMARY =
Added images:0
Dropped images:  9
Added packages:  1
Dropped packages:0
Upgraded packages:   10
Downgraded packages: 0

Size of added packages:  137.73 MiB
Size of dropped packages:0 B
Size of upgraded packages:   47.54 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   25.38 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: KDE live i386
Path: Spins/i386/iso/Fedora-KDE-Live-i386-28-20180312.n.0.iso
Image: Modular dvd armhfp
Path: Modular/armhfp/iso/Fedora-Modular-dvd-armhfp-28-20180312.n.0.iso
Image: Modular dvd i386
Path: Modular/i386/iso/Fedora-Modular-dvd-i386-28-20180312.n.0.iso
Image: Modular dvd ppc64
Path: Modular/ppc64/iso/Fedora-Modular-dvd-ppc64-28-20180312.n.0.iso
Image: Modular dvd aarch64
Path: Modular/aarch64/iso/Fedora-Modular-dvd-aarch64-28-20180312.n.0.iso
Image: Modular dvd x86_64
Path: Modular/x86_64/iso/Fedora-Modular-dvd-x86_64-28-20180312.n.0.iso
Image: Modular dvd s390x
Path: Modular/s390x/iso/Fedora-Modular-dvd-s390x-28-20180312.n.0.iso
Image: Modular dvd ppc64le
Path: Modular/ppc64le/iso/Fedora-Modular-dvd-ppc64le-28-20180312.n.0.iso
Image: Modular dvd src
Path: Modular/source/iso/Fedora-Modular-dvd-source-28-20180312.n.0.iso

= ADDED PACKAGES =
Package: f28-backgrounds-28.1.0-1.fc28
Summary: Fedora 28 default desktop background
RPMs:f28-backgrounds f28-backgrounds-base f28-backgrounds-extras-base 
f28-backgrounds-extras-gnome f28-backgrounds-extras-kde 
f28-backgrounds-extras-mate f28-backgrounds-extras-xfce f28-backgrounds-gnome 
f28-backgrounds-kde f28-backgrounds-mate f28-backgrounds-xfce
Size:137.73 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  desktop-backgrounds-28.0.0-1.fc28
Old package:  desktop-backgrounds-27.0.0-2.fc28
Summary:  Desktop backgrounds
RPMs: desktop-backgrounds-basic desktop-backgrounds-compat 
desktop-backgrounds-gnome desktop-backgrounds-waves
Size: 13.42 MiB
Size change:  568 B
Changelog:
  * Mon Mar 05 2018 Luya Tshimbalanga <l...@fedoraproject.org> - 28.0.0-1
  - Enable F28 theme


Package:  ghc-codec-rpm-0.2.0-5.fc28
Old package:  ghc-codec-rpm-0.2.0-4.fc28
Summary:  A library for manipulating RPM files
RPMs: ghc-codec-rpm ghc-codec-rpm-devel
Size: 9.18 MiB
Size change:  224 B
Changelog:
  * Tue Mar 06 2018 Adam Williamson <awill...@redhat.com> - 0.2.0-5
  - Rebuild against the new-old ghc-conduit-extra soname


Package:  ghc-conduit-combinators-1.1.2-4.fc28
Old package:  ghc-conduit-combinators-1.1.2-3.fc28
Summary:  Commonly used conduit functions, for both chunked and unchunked 
data
RPMs: ghc-conduit-combinators ghc-conduit-combinators-devel 
ghc-conduit-combinators-devel-doc
Size: 3.79 MiB
Size change:  3.14 KiB
Changelog:
  * Tue Mar 06 2018 Adam Williamson <awill...@redhat.com> - 1.1.2-4
  - Rebuild against new ghc-conduit-extra, again


Package:  ghc-conduit-extra-1.2.3.2-4.fc28
Old package:  ghc-conduit-extra-1.2.3.2-3.fc28
Summary:  Batteries included conduit: adapters for common libraries
RPMs: ghc-conduit-extra ghc-conduit-extra-devel
Size: 5.26 MiB
Size change:  5.68 KiB
Changelog:
  * Tue Mar 06 2018 Jens Petersen <peter...@redhat.com> - 1.2.3.2-4
  - rebuild


Package:  ghc-content-store-0.2.0-5.fc28
Old package:  ghc-content-store-0.2.0-4.fc28
Summary:  Store and retrieve data from an on-disk store
RPMs: ghc-content-store ghc-content-store-devel
Size: 2.22 MiB
Size change:  3.55 KiB
Changelog:
  * Tue Mar 06 2018 Adam Williamson <awill...@redhat.com> - 0.2.0-5
  - Rebuild against the new-old ghc-conduit-extra soname


Package:  ghc-cpio-conduit-0.7.0-5.fc28
Old package:  ghc-cpio-conduit-0.7.0-4.fc28
Summary:  Conduit-based CPIO
RPMs: ghc-cpio-conduit ghc-cpio-conduit-devel
Size: 1.21 MiB
Size change:  1.20 KiB
Changelog:
  * Tue Mar 06 2018 Adam Williamson <awill...@redhat.com> - 0.7.0-5
  - Rebuild against new ghc-conduit-extra, again


Package:  ghc-tar-conduit-0.1.1-5.fc28
Old package:  ghc-tar-conduit-0.1.1-4.fc28
Summary:  Parse tar files using conduit for streaming
RPMs: ghc-tar-conduit ghc-tar-conduit-devel
Size: 1.11 MiB
Size change:  1.23 KiB
Changelog:
  * Tue Mar 06 2018 Adam Williamson <awill...@redhat.com> - 0.1.1-5
  - Rebuild against the new-old ghc-conduit-extra soname


Package:  ghc-typed-process-0.2.1.0-4.fc28
Old package:  ghc-typed-process-0.2.1.0-3.fc28
Summary:  Run external processes, with strong typing of streams
RPMs: ghc-typed-process ghc-typed-process-devel
Size: 1.64 MiB
Size change:  1.55 KiB
Changelog:
  * Tue Mar 06 2018 Jens Petersen <peter...@redhat.com> - 0.2.1.0-4
  - disable testsuite since it affected the package hash


Package:

Re: F29 System Wide Change: Make dbus-broker the default DBus implementation

2018-03-13 Thread Tom Gundersen

On Tue, Mar 13, 2018 at 11:55 PM, Steve Grubb  wrote:
> Does it replicate the same SE Linux support?

Yes.

Cheers,

Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: new section for 'Join the package collection maintainers'

2018-03-13 Thread René Genz

On 13.03.2018 15:13, Jonathan Wakely wrote:
> On 12/03/18 21:02 -0300, Athos Ribeiro wrote:
>> On Tue, Mar 13, 2018 at 12:35:19AM +0100, René Genz wrote:
[snip]
>>> I propose to:
>>> add a new major point 2, so:
>>> "2. How to join the Fedora Package Collection Maintainers?"
>>> will be:
>>> "3. How to join the Fedora Package Collection Maintainers?"
> 
> Should your new item really come first? The page is about joining the
> package maintainers, so why should "how to contribute without joining"
> come before "how to join"?

I considered my case, only a one-off contribution, it is less text to read.
I am fine with adding the new information to the end.

[snip]
>>>
>>> At the moment any repos, including forks, on https://src.fedoraproject.org 
>>> require your FAS account to have 'packager' status for write access (and 
>>> read access if you use the "SSH" Source GIT URL).
> 
> I don't think it's helpful to mention the SSH URL part. If you don't
> have write access, just use the HTTPS URL.
> 

The SSH URL can be used to download too, but `git clone` printed 'permission 
denied' as far as I remember.

>>> Either you get the status or you use a >> (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
>>>  f.e. with https://pagure.io/new)>, as a workaround.
> 
> This should be "for example" or "e.g." not "f.e."

OK

> 
> And it doesn't seem like a workaround, it seems like the proper way to
> do it.

Other git hosting platforms support write access for users' forks.
I was surprised to find out this is not the case for src.fedoraproject.org.
Of course, with this behavior the remote pull-request is the proper way to do 
it.

> 
>>> The requirement to be a packager is being worked on.
>>> ---8<---
>>
>> I would rather see something like:
>>
>> If you are not an Fedora packager, i.e., you are not in the 'packager'
>> FAS group, you can send pull requests to  src.fedoraproject.org. To do
> 
> Yes, I agree it's better to say "in the 'packager' FAS group" rather
> than "have 'packager' status".

OK

> 
>> so, you must use a > (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>,
>> f.e. with https://pagure.io/new)>
> 
> How about:
> 
> 3. One-off contributions
> 
> Changes to existing packages can be suggested by submitting  requests (https://docs.pagure.org/pagure/usage/pull_requests.html)>.
> You must have a  to create
> a pull request. If your account is not in the 'packager' group then

Should it not be written with a comma, like "If ... group, then"?

> you cannot create a fork on src.fedoraproject.org so must use an

You can create a fork on src.fedoraproject.org if your account is not a member 
of the 'packager' group.
For this account and repo:
* up- and downloading with the SSH URL fails
* downloading with the HTTPS URL works
(I guess uploading with the HTTPS URL is not supported, like it is in pagure.io)

> external Git hosting platform (e.g. https://pagure.io/new) and use a
>  (https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request)>.

Thank you for your input. :)
Too late for me to write a new version of the proposal today. Feel free to beat 
me to it.
-- 
Kind regards,
René
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

71 matches

Mail list logo