Re: Unresponsive maintainer: rnovacek

[Michal Schorm]

Hi,

After some research (it is kinda hard to find somebody dropped form
internal databases) I found out, he left RH in November.

I'm sorry for that, I don't like it either, when somebody left without any
notice :(



I will try to gather more informations today. (Like if those packages
should be orphaned)



On Sun, Jan 15, 2017 at 7:16 PM, Kevin Kofler 
wrote:

> Hi,
>
> has Radek Nováček left Red Hat? The contact information he has everywhere:
> https://fedoraproject.org/wiki/User:Rnovacek
> points to rnova...@redhat.com, but attempts to write there bounce, with:
> 554 5.7.1 : Recipient address rejected: Access denied
>
> Does anybody know how to contact Radek? Is he still interested in
> maintaining his packages or should they be orphaned?
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 

Michal Schorm
Core Services - Databases Team
mail: msch...@redhat.com
Brno-IRC: mschorm
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unresponsive maintainer: rnovacek

[Jan Kurik]

Hi,

one way of contacting him might be via his Linked-in profile:
https://www.linkedin.com/in/radek-novacek

Regards,
Jan

On Mon, Jan 16, 2017 at 9:04 AM, Michal Schorm  wrote:
> Hi,
>
> After some research (it is kinda hard to find somebody dropped form internal
> databases) I found out, he left RH in November.
>
> I'm sorry for that, I don't like it either, when somebody left without any
> notice :(
>
>
>
> I will try to gather more informations today. (Like if those packages should
> be orphaned)
>
>
>
> On Sun, Jan 15, 2017 at 7:16 PM, Kevin Kofler 
> wrote:
>>
>> Hi,
>>
>> has Radek Nováček left Red Hat? The contact information he has everywhere:
>> https://fedoraproject.org/wiki/User:Rnovacek
>> points to rnova...@redhat.com, but attempts to write there bounce, with:
>> 554 5.7.1 : Recipient address rejected: Access denied
>>
>> Does anybody know how to contact Radek? Is he still interested in
>> maintaining his packages or should they be orphaned?
>>
>> Kevin Kofler
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
>
> --
>
> Michal Schorm
> Core Services - Databases Team
> mail: msch...@redhat.com
> Brno-IRC: mschorm
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
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 Elections January 2017 - Voting period ends today at 23:59 UTC

[Jan Kurik]

Hi,

the Voting period of the Fedora Elections to Council, FAmSCo and FESCo
[1] is going to end today (Monday, January 16th, 2017) at 23:59:00
UTC.
Please vote if you have not done so.

You might also check an article published in Fedora Community Blog
[2], summarizing all the interviews with candidates.

[1] https://admin.fedoraproject.org/voting/
[2] https://communityblog.fedoraproject.org/2017-january-elections-interviews/

Thanks for your support.

Regards,
Jan
-- 
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

F26 System Wide Change: Modular Server Preview

[Jan Kurik]

= System Wide Change: Modular Server Preview =
https://fedoraproject.org/wiki/Changes/Modular_Server_Preview

Change owner(s):
* Langdon White 


As we progress down the modularity path, we finally have enough
content, architecture and understanding that we would like to release
an edition of Fedora that is actually usable. However, as we aren't
ready for production yet, we would like to do a "preview" release so
that people can see it and try it but it doesn't actually take the
place of a production edition. As such this Change Proposal requests
that we set up a "Modular Server Edition" with some sort of flag that
indicates that it is meant for experimentation and not real use. We
plan to model the Server Edition in content and most use scenarios.



== Detailed Description ==
The modularity effort is fairly well known and significantly more
information may be found on the wiki or the YouTube Channel. In short,
modularity is attempting to disconnect the lifecycle of applications
from 1) each other 2) the operating system while still maintaining the
ease of use of a typical Linux Distro.



== Scope ==
* Proposal owners:
** The Modularity WG, Factory 2.0, Base Runtime, and Server WG teams
all have contributions to this effort. The work that each team is
doing is significant and wide ranging. However, as the release is
being managed in a "preview channel" none of the changes, whether
released on time or not, will impact any other aspect of Fedora. Also,
while we have high hopes for the amount of content we plan to release,
even a small percentage of that content being ready will be enough to
help prove the concept and generate feedback.

* Other developers:
** A limited number of Fedora Packagers will help to provide modules
and containers for this release of Modular Server. See
https://fedoraproject.org/wiki/Changes/ModuleBuildService for more
details.

* Release engineering:
** List of deliverables: Numerous but largely aligned with the Server
WG Logic Model (
https://kolinahr.fedorainfracloud.org/edit/57ff81347b76717eefcbc44b )
** Release engineering needs to create and deliver this new "edition."
The Factory 2 team is largely responsible. Ralph|Threebean has been
the primary point of contact thus far.
** A preview edition delivering the Modular Server

* Policies and guidelines:
** New guidelines are required, they are currently in Draft state and
we will be collecting feedback to them during the F26 lifecycle for
ratification prior to F27.
*** https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
*** https://fedoraproject.org/wiki/Container:Guidelines
** At this point there are no changes expected to existing guidelines

* Trademark approval: N/A (not needed for this Change)
** This is based on a Fedora Objective and, as a result, does not seem
to require Trademark approval even though it will carry the Trademark.
-- 
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

F26 System Wide Change: Separate Subpackage and Source Debuginfo

[Jan Kurik]

= System Wide Change: Separate Subpackage and Source Debuginfo =
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo

Change owner(s):
* Mark Wielaard 
* Neal Gompa 


Allow to install just the debuginfo for a subpackage and/or without
the source files. The debuginfo packages are huge because they contain
debuginfo and all sources for all subpackages. Being able to install
only the debuginfo for the subpackage that is installed reduces the
size that needs to be downloaded to analyze, trace, profile or debug a
program or core file. Some tracing and profiling tools don't need the
actual source files to provide stack traces or insert probes. So
installing the debugsources should be optional.


== Detailed Description ==
Currently both the .debug files and the source files of all
subpackages are included in a debuginfo package. This creates huge
debuginfo packages with a lot of data that might not be relevant to
the user/developer. By splitting out the sources (found under
/usr/src/debug) and the .debug file for the separate binaries of the
subpackages (under /usr/lib/debug) the amount of data a developer/user
needs to install to trace, profile or debug will be greatly reduced.

Other distributions (notably Suse) already split their debuginfo
packages this way. We will take those patches
(https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsubpkg.diff)
and integrate them into rpm upstream. This will involve two steps: -
https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/us/8
- 
https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package-creation/us/10

This depends on some of the cleanups introduced by the
ParallelInstallableDebuginfo change.

We can either make this work with the current dnf debuginfo-install
plugin by providing a meta package that matches the main-debuginfo
package which depends on all sub- and source-debuginfo packages. Or we
work with the dnf hackers to make dnf debuginfo-install work with
sub-debuginfo packages.

A couple of packages already have hand-written sub-debuginfo packages
(notably the kernel, glibc and gcc). We will work with those packages
to adopt the new standard approach.

Release engineering needs to be involved to see if any changes are
necessary for adding the sub-debuginfo/debugsources packages to the
repodata.


== Scope ==
* Proposal owners:
Patches against rpm upstream need to be integrated as outlined in the
Detailed Description.

* Other developers:
Upstream rpm and dnf maintainers have to review the proposed patches.
If accepted the package maintainers will have to decide whether those
patches can be backported for the next fedora release. Packages that
now split their debuginfo packages by hand might want to change their
package to adopt the new (standard) approach. Once all changes are in
a package debuginfo needs to be regenerated before it becomes
sub-package/source split.

* Release engineering:
Needs to be discussed. In theory no changes apart from those listed
above are needed. But release engineering might know whether any
changes are necessary for adding the sub-debuginfo/debugsources
packages to the repodata.

* List of deliverables:
N/A (Still Unknown)

* Policies and guidelines:
No changes, the debuginfo related rpm macros won't change. They will
just start producing sub-package debuginfo and debugsources packages
once all changes are in place.

* Trademark approval:
N/A (not needed for this Change)
-- 
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

Fedorahosted.org sunset reminder: 2017-02-28

[Kevin Fenzi]

(This is a resend reminder, with some additional faq information)

Greetings. 

Fedora Infrastructure currently maintains two sites for general open
source code hosting: fedorahosted.org and pagure.io. 

Fedorahosted.org was established in late 2007 using Trac for issues and
wiki pages, Fedora Account System groups for access control and source
uploads, and offering a variety of Source Control Management tools
(git, svn, hg, bzr). With the rise of new workflows and source
repositories fedorahosted.org has ceased to grow, adding just one new
project this year and a handful the year before. 

Pagure.io was established in 2015, and is a modern Flask/Python based
application. It is under rapid development and supports git repos for
source code, docs, and tickets. The pull request model is used for
changes along with many options for projects. Access control is
standalone. New projects are self service and added all the time. 

Given the lack of growth and continued maintenance burden, Fedora
Infrastructure would like to retire fedorahosted.org and encourage all
its active projects to move to pagure.io (or whatever other place they
feel best meets their needs). We have tenatively scheduled this
retirement for February 28th, 2017.

The Infrastructure team has already contacted owners of the top ten
projects on Fedora Hosted for input on their needs.  If your project
has special needs, please contact the Infrastructure team (details
below) to discuss options.

After the sunset date, we will continue to provide raw data from public
projects previously hosted at fedorahosted.org, but the service itself
will be closed. We hope to provide this data for download for a few
years, but won't provide it forever. 

A quick FAQ:

Question: pagure.io has some issues/problems that prevent me from
moving my project there. What can I do?

Answer: Please file these issues against pagure:
https://pagure.io/pagure/issues/ and we will try and address them as
best we can. Note that not every feature request can be accommodated
but the team will consider all requests.

Question: How can I migrate my data from fedorahosted to pagure.io?

Answer: You can use the https://pagure.io/pagure-importer tool to
migrate trac data to pagure.io issues. Git repositories should be
easily migrated with a push to the new pagure.io repo. Releases can be
uploaded to pagure.io. There is also available a copr repo with the
latest version of the importer tool:
https://copr.fedorainfracloud.org/coprs/cverna/pagure-importer/

Question: I want to test things out, but not migrate yet, how can I do
that?

Answer: We have a https://stg.pagure.io/ test instance you are welcome
to create projects on and test importing data. Note that from time to
time we clear out this instance, so do not use it for any long term
use. 

Question: What happens if I ignore this/don't get around to migrating
my project by the 2017-02-28 deadline?

Answer: We hope to provide the raw data from projects for download for
a while, so you should be able to download a tar.xz of your old git
repo and trac files, but it will be up to you to extract what you need
from them, and we won't host them forever. The data sunset period would
be at least several additional months.

Question: Does pagure.io support hg, bzr, svn or cvs? 

Answer: no. 

Question: I have a mailing list at lists.fedorahosted.org, what happens
to that?

Answer: We have no plans to retire lists.fedorahosted.org at this time.
All lists and archives will keep functioning. We hope soon to have a
lists.pagure.io domain available and projects that wish to migrate can
do so if they choose. 

Question: I have more questions, where can I get more answers?

Answer: Feel free to ask on the infrastruct...@lists.fedoraproject.org
list or #fedora-admin on IRC

Thanks, 

kevin


pgpSOPG1Pavn5.pgp
Description: OpenPGP digital signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rebuilt SWIG with support for Octave 4.2

[Björn 'besser82' Esser]

Am 14.01.2017 um 19:56 schrieb Björn 'besser82' Esser:
I just backported the upstream patch for adding support for Octave 4.2 
to SWIG in Rawhide.  Build is running [1].


Cheers
  Björn


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=17285610


The recent build [1] of Swig in Rawhide has support for Octave 4.2 now.

Cheers
  Björn


[1]  https://koji.fedoraproject.org/koji/buildinfo?buildID=833864
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Heads up: lua-lpeg 1.0.1 in Rawhide; lua no longer in mock root by default?

[Panu Matilainen]

On 01/15/2017 05:44 PM, Neal Gompa wrote:

On Sun, Jan 15, 2017 at 12:24 AM, Michel Alexandre Salim
 wrote:

Hi all,

Just a heads-up: I just built lua-lpeg 1.0.1 for Rawhide. The release notes
does not seem to suggest any significant API change, but just to be sure we
should probably let it sit in Rawhide for a while.

On the packaging side, turns out Lua is not available by default in the mock
root, and a lot of our Lua packages try to detect the version of Lua used
during the build by using this expansion:


  %{!?luaver: %global luaver %(lua -e "print(string.sub(_VERSION, 5))")}

This now fails because the lua binary is not available when mock rebuilds
the SRPM. For anyone updating other Lua packages the following works:

  %{!?luaver: %global luaver %(test -x /usr/bin/lua && lua -e
"print(string.sub(_VERSION, 5))" || echo 5.3)}

(I'll update my draft Lua packaging guidelines with this, if it looks good
to others)


The lua package was recently refactored to split the libraries out
into lua-libs, so you need to add "BuildRequires: lua" or
"BuildRequires: /usr/bin/lua" to get it specifically.


Note that Lua being special to rpm, and as long as there's just one 
version of Lua in Fedora, you don't actually need the lua executable or 
buildrequires just for that:


%{!?luaver: %global luaver %{lua:print(string.sub(_VERSION, 5))}}


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

Re: drop obsolete static uid/gid allocations

[Ondřej Vašík]

Zbigniew Jędrzejewski-Szmek píše v Ne 15. 01. 2017 v 00:13 +:
> https://git.fedorahosted.org/cgit/setup.git/tree/uidgid has a list
> of "soft static" uids and gids.
> 
> Currently FPC has a process for allocating new numbers on this list,
> but here's a number of static uid/gid allocations from old times,
> which are not necessary. Dropping them will allow those numbers to be
> used in the dynamic pool, reducing the risk of exhaustion of system
> uids or gids.

Dynamic pool uses static id area only in the worst case when uid/gids
200-999 are already allocated.
From the users listed down only "games" user is created by default - so
unless the package that creates the uid/gid is installed, their ids can
theoretically be used for dynamic ids creation. If they are on the
system, you will not get anything by removal of static allocation - as
they will occupy some dynamic id anyway.

> (A "soft static" allocation is only needed for two reasons [1]:
> - the user is used in the initramfs AND files or processes are carried
>   over into the real system,
> - the UID is used on shared between systems.

Third reason is sometimes mentioned - to prevent leak of "sensitive
data" to other "dynamically allocated" when old system user is removed
(and files owned by that users not deleted). But this is more
hypothetical case.

> All other packages should use "dynamic" allocation, i.e. create
> the user/group in %pre and get any free number.)
> 
> I thought I'd file a ticket against setup, but since there's a large
> number of items on this list, I decided to ask here first.
> Any objection to dropping (from the static list) any of the following?
> 
> == No need for static allocation, afaict
> games, man, slocate, squid, named, postgres, mysql, nscd,
> rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp,
> tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd,
> imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci

I agree for some of these I don't see any need for static id allocation
- and they have static id allocated only for historical reasons. (typo
s/tcpdmp/tcpdump btw.).
I don't see imap in the uidgid file.
> 
> == The following are completely unused?
> console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> pvm, xfs

From 45 ids listed above, 40 were reserved before I got maintenance of
the setup package (2008). Only 4 (saned, mock, ricci, luci) were added
by me and 1 is not in uidgid file at all.
Reason for mock is explained in
https://bugzilla.redhat.com/show_bug.cgi?id=928063#c0 . For ricci/luci,
I expect reason for the static id is they belong to High
Availability/Cluster... However, they were dropped meanwhile. Saned
probably doesn't need static id, though.

However, even if I drop these static allocation, I don't think we can
reuse them for any other static allocations anytime soon - as this could
mean dynamic allocation for the new potentially statically allocated
account - if the system was maintained via upgrades from older
Fedoras/RHELs/CentOS.

IMHO, drop of these allocation doesn't bring much gain (except cleaner
uidgid file) and brings some potential risks that can show in future.

Regards,
   Ondrej

> [1] The guidelines (https://fedoraproject.org/wiki/Packaging:UsersAndGroups)
> don't mention the first reason, only the second one. Oh well, changing that
> is probably not worth the effort.



> 
> Zbyszek

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

Re: Unresponsive maintainer: rnovacek

[Jaroslav Reznik]

On Sun, Jan 15, 2017 at 7:16 PM, Kevin Kofler  wrote:
> Hi,
>
> has Radek Nováček left Red Hat? The contact information he has everywhere:
> https://fedoraproject.org/wiki/User:Rnovacek
> points to rnova...@redhat.com, but attempts to write there bounce, with:
> 554 5.7.1 : Recipient address rejected: Access denied
>
> Does anybody know how to contact Radek? Is he still interested in
> maintaining his packages or should they be orphaned?

Yes,
Radek left Red Hat but I'll contact him and I'll ask him if he's still
interested in his packages.

Jaroslav

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



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unresponsive maintainer: rnovacek

[Radek Novacek]

Hi Kevin,

yes, I've left Red Hat in November last year. My personal email is: 
ra...@centrum.cz . I'm still interested in maintaining my packages, but I'm not 
sure if I can give them enough love in the future, so comaintainers are of 
course welcomed.

I've updated the wiki page with correct information.

Sorry for any potential issues.

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

Re: libglvnd review request, reviewer needed

[Hans de Goede]

Hi,

On 13-01-2017 18:17, Nicolas Chauvet wrote:
>
> On 13-01-17 16:56, Hans de Goede wrote:
>> Hi,
>>
>> On 01/12/2017 11:24 PM, Nicolas Chauvet wrote:
>>> 2017-01-12 19:04 GMT+01:00 Hans de Goede :
 Hi All,

 I've just submitted a pkg review request for libglvnd:

 https://bugzilla.redhat.com/show_bug.cgi?id=1412764

 This is the last building block needed to allow full
 parallel installation of the nvidia binary driver and
 nouveau / mesa, without needing various *.conf.d to
 select the right libGL.so / Xserver glx module, etc.

 With this in place the entire Xorg / GL stack will
 automatically do the right thing depending on which
 kernel driver (nouveau or nvidia) is loaded, which
 means that things will no longer break if the kernel /
 userspace config do not match (as there is no more
 userspace config), also see:
>>> This is already in fedora since few months already.
>>
>> Ah, I did not know that, that is great.
>>
>> I plan to do a Fedora 25 update enabling
>> glvnd in mesa coming monday. I will also update
>> libglvnd to match and make it be the provider
>> of libGL.so.1, etc.
>>
>> When I'm done I'll put both of them in a single bodhi update.
>>
>> I've requested co-maintainer rights for libglvnd if
>> you can grant those, that would be great.
>
> Sure, can you please open a bug so we can coordinate which
> changes exactly you want to push.( there are additional patches
> needed for pure mesa cases and glvnd - see
> https://bugs.freedesktop.org/show_bug.cgi?id=98428 ).

I cannot reproduce the problem from that bug, as described in:

https://github.com/NVIDIA/libglvnd/issues/104

For me with the latest xserver + glvnd + glvnd-enabled mesa
I get the following in my xorg.log :

[24.160] (II) modeset(0): [DRI2] Setup complete
[24.160] (II) modeset(0): [DRI2]   DRI driver: i965
[24.160] (II) modeset(0): [DRI2]   VDPAU driver: i965
[24.160] (--) RandR disabled
[24.162] (II) SELinux: Disabled by boolean
[24.165] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[24.165] (II) AIGLX: enabled GLX_ARB_create_context
[24.165] (II) AIGLX: enabled GLX_ARB_create_context_profile
[24.165] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[24.165] (II) AIGLX: enabled GLX_INTEL_swap_event
[24.165] (II) AIGLX: enabled GLX_SGI_swap_control
[24.165] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[24.165] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[24.165] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[24.165] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[24.165] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[24.165] (II) AIGLX: Loaded and initialized i965
[24.165] (II) GLX: Initialized DRI2 GL provider for screen 0

I'll also make sure to test this with the intel ddx before
kicking of builds for this.

As for the changes I plan to make see the attached patch.

Note we've been working on this for quite a while now and
it already has seen quite a bit of testing. So I plan to
kick of rawhide builds for this this afternoon after I've
run one more final batch of tests.

> Also f25 seems a quite disruptive change for switching the
> libGL provider. I'm all in favor about that, as It will settle
> the situation on optimus and drop custom repos, but let's at
> least have a step in f26. Thx

Ack, I'll let this sit in rawhide for a few days before building
it for f25 and pushing it to updates-testing.

Regards,

Hans
>From 8a33c34f411075f0a32611ce34c962945a73c6d7 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Mon, 16 Jan 2017 12:27:54 +0100
Subject: [PATCH] Epoch:1, Release:6 to provide upgrade path from
 negativo17.org rpms New snapshot Add patches to fix building on ARM (from Rob
 Clark) Add BuildRequires: python Add ldconfig scriptlets for library
 sub-packages

---
 ...penGL-Statically-export-a-few-more-things.patch |  27 
 ...ost_cpu-when-undetected-for-easier-debugg.patch |  25 
 0003-Fix-compile-errors.patch  |  37 +
 ...sure-asm-is-compiled-in-unified-syntax-mo.patch |  34 +
 0005-Treat-armv7hl-as-armv7l.patch |  25 
 ...sts-that-cannot-pass-with-pure-c-dispatch.patch |  49 +++
 egl_crash.patch|  80 ---
 libglvnd.spec  | 152 -
 sources|   1 -
 9 files changed, 312 insertions(+), 118 deletions(-)
 create mode 100644 0001-OpenGL-Statically-export-a-few-more-things.patch
 create mode 100644 0002-Print-out-host_cpu-when-undetected-for-easier-debugg.patch
 create mode 100644 0003-Fix-compile-errors.patch
 create mode 100644 0004-armv7-make-sure-asm-is-compiled-in-unified-syntax-mo.patch
 create mode 100644 0005-Treat-armv7hl-as-armv7l.patch
 create mode 100644 0006-skip-tests-that-cannot-pass-with-pure-c-dispatch.patch
 delete mode 100644 egl_cra

F26 Self Contained Change: LXQt Spin

[Jan Kurik]

= Proposed Self Contained Change: LXQt Spin =
https://fedoraproject.org/wiki/Changes/LXQt_Spin

Change owner(s):
* Christian Dersch 

A Fedora Spin providing the LXQt desktop environment.

== Detailed Description ==
LXQt is a lightweight Qt-based desktop environment. Fedora provides it
since Fedora 22 as a group of packages. Now that LXQt is much more
complete, it is time to provide a live spin to our users. Therefore
some effort has been made to provide a first impression and it is
ready for submission as an official spin.

== Scope ==
* Proposal owners:
Implement this Change, almost done.
https://pagure.io/lxqt-remix

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
Add spin to spin-kickstarts, ensure spin has been tested, and release
with rest of spins

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
requested
https://pagure.io/Fedora-Council/tickets/issue/84
-- 
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

The default buildroot no longer contains python/python3

[Petr Šabata]

Let it be known that due to certain packaging changes implemented
in December, neither python nor python3 are automatically pulled
into the default, minimal buildroot anymore.

This negatively affects packages the require python/python3 at
build time but do not explicitly say so, causing FTBFS issues.
This will manifest itself during the upcoming mass rebuild,
at the latest.
https://fedoraproject.org/wiki/Releases/26/Schedule

If your package is affected, make sure you declare your build
dependencies correctly and add anything that's missing.
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2

See https://pagure.io/fesco/issue/1660 for some background on this.

Cheers,
P


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Is there something wrong with the Koji builders?

[Kaleb S. KEITHLEY]

I've done two builds for rawhide this morning.

On the first the armv7hl and ppc64le builds failed because the source
tar file could not be unpacked.

On the second the aarch64 build failed because the source tar file could
not be unpacked.

All the other arches built successfully.

-- 

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

Re: The default buildroot no longer contains python/python3

[Igor Gnatenko]

On Mon, 2017-01-16 at 13:13 +0100, Petr Šabata wrote:
> Let it be known that due to certain packaging changes implemented
> in December, neither python nor python3 are automatically pulled
> into the default, minimal buildroot anymore.
I have to note that for python3 it's not really true, since rpm-build
"depends" (one of depgens require functionality to work[0]) on python3-
setuptools.

Hopefully at some point it will be moved to something like python-
generators (like we did with perl).
> 
> This negatively affects packages the require python/python3 at
> build time but do not explicitly say so, causing FTBFS issues.
> This will manifest itself during the upcoming mass rebuild,
> at the latest.
> https://fedoraproject.org/wiki/Releases/26/Schedule
> 
> If your package is affected, make sure you declare your build
> dependencies correctly and add anything that's missing.
> https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2
> 
> See https://pagure.io/fesco/issue/1660 for some background on this.
> 
> Cheers,
> P
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave@lists.fedoraproj
> ect.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1410631
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ebay-cors-filter's builds started to fail in Fedora Rawhide

[Sandro Bonazzola]

On Mon, Jan 16, 2017 at 2:48 PM,  wrote:

> ebay-cors-filter's builds started to fail in Fedora Rawhide
> https://apps.fedoraproject.org/koschei/package/ebay-cors-
> filter?collection=f26
>
>
>
Looks like fop disabppeared, any hint about what's happening?
Thanks,


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: LXQt Spin

[William Moreno]

This new spin will be coexisting with the current lxde spin? Or users of
the lxde spin will need to move to lxqt?

Is the second option is valid there will be a smooth update process via the
dnf system upgrade tool?

El 16/1/2017 7:01 a. m., "Jan Kurik"  escribió:

> = Proposed Self Contained Change: LXQt Spin =
> https://fedoraproject.org/wiki/Changes/LXQt_Spin
>
> Change owner(s):
> * Christian Dersch 
>
> A Fedora Spin providing the LXQt desktop environment.
>
> == Detailed Description ==
> LXQt is a lightweight Qt-based desktop environment. Fedora provides it
> since Fedora 22 as a group of packages. Now that LXQt is much more
> complete, it is time to provide a live spin to our users. Therefore
> some effort has been made to provide a first impression and it is
> ready for submission as an official spin.
>
> == Scope ==
> * Proposal owners:
> Implement this Change, almost done.
> https://pagure.io/lxqt-remix
>
> * Other developers:
> N/A (not a System Wide Change)
>
> * Release engineering:
> Add spin to spin-kickstarts, ensure spin has been tested, and release
> with rest of spins
>
> * Policies and guidelines:
> N/A (not a System Wide Change)
>
> * Trademark approval:
> requested
> https://pagure.io/Fedora-Council/tickets/issue/84
> --
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: LXQt Spin

[Christian Dersch]

LXDE spin will exist until its maintainer will stop it, LXQt is 
independent from LXDE spin. So nobody is forced to change ;) Also both 
projects are maintained upstream so there is no reason to drop anything 
here.



On 01/16/2017 02:54 PM, William Moreno wrote:
This new spin will be coexisting with the current lxde spin? Or users 
of the lxde spin will need to move to lxqt?


Is the second option is valid there will be a smooth update process 
via the dnf system upgrade tool?


El 16/1/2017 7:01 a. m., "Jan Kurik" > escribió:


= Proposed Self Contained Change: LXQt Spin =
https://fedoraproject.org/wiki/Changes/LXQt_Spin


Change owner(s):
* Christian Dersch 

A Fedora Spin providing the LXQt desktop environment.

== Detailed Description ==
LXQt is a lightweight Qt-based desktop environment. Fedora provides it
since Fedora 22 as a group of packages. Now that LXQt is much more
complete, it is time to provide a live spin to our users. Therefore
some effort has been made to provide a first impression and it is
ready for submission as an official spin.

== Scope ==
* Proposal owners:
Implement this Change, almost done.
https://pagure.io/lxqt-remix

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
Add spin to spin-kickstarts, ensure spin has been tested, and release
with rest of spins

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
requested
https://pagure.io/Fedora-Council/tickets/issue/84

--
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




___
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: RFH: Annotating ELF binaries

[Nick Clifton]

Hi H.J.

> We have 2 different proposals for program properties.  Mine:
> 
> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html
> 
> has a much smaller scope.  New features on upcoming Intel platforms,
> like 5-level paging, need this extension for loader decision at run-time.
> How should we move forward with program property extensions?

I would like to combine the two approaches.  Ie use your notes for
properties that need to be examined at run-time (specifically the
loader, although I imagine that the application itself might be 
interested in reading its own notes).  Plus use the note scheme I
am proposing for static analysis tools.

I am currently using a gcc plugin to generate the notes, and I think
that this should be extendable to generate your notes as well.  (Using
a plugin is advantageous in that it is not tied to the latest gcc release.
It can be built to run with older gcc's, and it can be updated 
independently of the gcc release cycle).

What do you think ?

Cheers
  Nick

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

Re: Is there something wrong with the Koji builders?

[Jaroslav Skarvada]

- Original Message -
> I've done two builds for rawhide this morning.
> 
> On the first the armv7hl and ppc64le builds failed because the source
> tar file could not be unpacked.
> 
> On the second the aarch64 build failed because the source tar file could
> not be unpacked.
> 
> All the other arches built successfully.
> 
> --
> 
> Kaleb
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

I am encountering the same problem even on i686 (when trying to scratch
build graphviz [1, 2]), so there is probably something wrong with the builders

thanks & regards

Jaroslav

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=17302165
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=17302557
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mock error on armv7hl koji

[Kai Engert]

FYI, the issue was gone after Kevin had updated all builders to newer
kernel/libraries and had rebooted them.

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

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


22 packages were orphaned
-
amplab-tachyon [master, f25, f24] was orphaned by tstclair
 Reliable file sharing at memory speed across cluster frameworks
 https://admin.fedoraproject.org/pkgdb/package/amplab-tachyon
budgie [master, f25, epel7, f24] was orphaned by zsun
 Simple and distraction free media player
 https://admin.fedoraproject.org/pkgdb/package/budgie
deltacloud-core [el6, el5] was orphaned by mfojtik
 Deltacloud REST API
 https://admin.fedoraproject.org/pkgdb/package/deltacloud-core
jtoaster [epel7] was orphaned by tstclair
 Java utility class for swing applications
 https://admin.fedoraproject.org/pkgdb/package/jtoaster
kryo-serializers [master, f25, f24] was orphaned by tstclair
 Additional kryo serializers
 https://admin.fedoraproject.org/pkgdb/package/kryo-serializers
rubygem-amazon-ec2 [f25, f24] was orphaned by mfojtik
 Amazon EC2 Ruby Gem
 https://admin.fedoraproject.org/pkgdb/package/rubygem-amazon-ec2
rubygem-aws [master, f25, f24] was orphaned by mfojtik
 Ruby gem for all Amazon Web Services
 https://admin.fedoraproject.org/pkgdb/package/rubygem-aws
rubygem-deltacloud-client [master, f25, f24] was orphaned by mfojtik
 Deltacloud REST Client
 https://admin.fedoraproject.org/pkgdb/package/rubygem-deltacloud-client
rubygem-factory_girl [master, f25, f24] was orphaned by mfojtik
 Framework and DSL for defining and using model instance factories
 https://admin.fedoraproject.org/pkgdb/package/rubygem-factory_girl
rubygem-gherkin [el6, el5] was orphaned by mfojtik
 Fast Gherkin lexer/parser
 https://admin.fedoraproject.org/pkgdb/package/rubygem-gherkin
rubygem-http_connection [el6, el5] was orphaned by mfojtik
 RightScale's robust HTTP/S connection module
 https://admin.fedoraproject.org/pkgdb/package/rubygem-http_connection
rubygem-json_pure [el6] was orphaned by mfojtik
 JSON Implementation for Ruby
 https://admin.fedoraproject.org/pkgdb/package/rubygem-json_pure
rubygem-net-ssh [el6, el5] was orphaned by mfojtik
 Net::SSH: a pure-Ruby implementation of the SSH2 client protocol
 https://admin.fedoraproject.org/pkgdb/package/rubygem-net-ssh
rubygem-openstack [master, el6, f25, f24] was orphaned by mfojtik
 Ruby Openstack Compute and Object-Store bindings
 https://admin.fedoraproject.org/pkgdb/package/rubygem-openstack
rubygem-rack-protection [el6] was orphaned by mfojtik
 Ruby gem that protects against typical web attacks
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rack-protection
rubygem-rack-test [el5] was orphaned by mfojtik
 Simple testing API built on Rack
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rack-test
rubygem-rb-inotify [epel7] was orphaned by mfojtik
 A Ruby wrapper for Linux's inotify, using FFI
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rb-inotify
rubygem-rbvmomi [el6, el5] was orphaned by mfojtik
 Ruby interface to the VMware vSphere API
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rbvmomi
rubygem-rerun [master, f24, el6, f25, el5] was orphaned by mfojtik
 Restarts your app when a file changes
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rerun
rubygem-right_aws [master, f25, f24] was orphaned by mfojtik
 Interface classes for the Amazon EC2/EBS, SQS, S3, SDB, and ACF Web 
Services
 https://admin.fedoraproject.org/pkgdb/package/rubygem-right_aws
rubygem-sinatra [epel7] was orphaned by mfojtik
 Ruby-based web application framework
 https://admin.fedoraproject.org/pkgdb/package/rubygem-sinatra
rubygem-will_paginate [f24, master, f25, el5] was orphaned by mfojtik
 Pagination plugin for web frameworks and other apps
 https://admin.fedoraproject.org/pkgdb/package/rubygem-will_paginate

11 packages were retired
-
kdeaccessibility [master] was retired by rdieter
 KDE Accessibility
 https://admin.fedoraproject.org/pkgdb/package/kdeaccessibility
kdeadmin [master] was retired by rdieter
 KDE Administrative tools
 https://admin.fedoraproject.org/pkgdb/package/kdeadmin
kdeedu [master] was retired by rdieter
 Educational/Edutainment applications
 https://admin.fedoraproject.org/pkgdb/package/kdeedu
kdemultimedia [master] was retired by rdieter
 KDE Multimedia metapackage
 https://admin.fedoraproject.org/pkgdb/package/kdemultimedia
kdeutils [master] was retired by rdieter
 KDE Utilities
 https://admin.fedoraproject.org/pkgdb/package/kdeutils
livereload [master] was retired by williamjmorenor
 Command line utility for starting a server in a directory
 https://admin.fedoraproject.org/pkgdb/package/livereload
onionshare [el6, epel7] was retired by pjp
 Securely and anonymously share files of any size
 https://admin.fedoraproject.org/pkgdb/package/onionshare
perl-Data-

Reviews Weekly

[nobody]

Start Date: 2017-01-09 10:08:02.061927
End Date: 2017-01-16 10:08:02.061927

Neal Gompa : 11

https://bugzilla.redhat.com/show_bug.cgi?id=1411957 pantheon-files
https://bugzilla.redhat.com/show_bug.cgi?id=1411954 
pandora-wallpapers
https://bugzilla.redhat.com/show_bug.cgi?id=1413203 
wingpanel-indicator-session
https://bugzilla.redhat.com/show_bug.cgi?id=1413216 
wingpanel-indicator-sound
https://bugzilla.redhat.com/show_bug.cgi?id=1412737 
slingshot-launcher
https://bugzilla.redhat.com/show_bug.cgi?id=1413288 
wingpanel-indicator-power
https://bugzilla.redhat.com/show_bug.cgi?id=1413396 
wingpanel-indicator-network
https://bugzilla.redhat.com/show_bug.cgi?id=1413301 
wingpanel-indicator-notifications
https://bugzilla.redhat.com/show_bug.cgi?id=1411354 gplugin
https://bugzilla.redhat.com/show_bug.cgi?id=1412732 appcenter
https://bugzilla.redhat.com/show_bug.cgi?id=1413385 
wingpanel-indicator-keyboard


kushal...@gmail.com : 6

https://bugzilla.redhat.com/show_bug.cgi?id=1387178 
golang-github-pelletier-go-buffruneio
https://bugzilla.redhat.com/show_bug.cgi?id=1387115 
golang-github-pkg-errors
https://bugzilla.redhat.com/show_bug.cgi?id=1387131 
golang-github-pkg-sftp
https://bugzilla.redhat.com/show_bug.cgi?id=1412167 
golang-github-cloudfoundry-incubator-candiedyaml
https://bugzilla.redhat.com/show_bug.cgi?id=1387203 
golang-github-pelletier-go-toml
https://bugzilla.redhat.com/show_bug.cgi?id=1412152 
golang-github-blang-semver


Christian Dersch : 5

https://bugzilla.redhat.com/show_bug.cgi?id=1413399 wcstools
https://bugzilla.redhat.com/show_bug.cgi?id=1412788 kf5-libkcddb
https://bugzilla.redhat.com/show_bug.cgi?id=1412773 
kf5-libkcompactdisc
https://bugzilla.redhat.com/show_bug.cgi?id=1412794 kf5-audiocd-kio
https://bugzilla.redhat.com/show_bug.cgi?id=1411438 arc-theme


Igor Gnatenko : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1412252 compat-readline6
https://bugzilla.redhat.com/show_bug.cgi?id=1413133 catimg


Randy Barlow : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1409929 
python-sqlalchemy_schemadisplay
https://bugzilla.redhat.com/show_bug.cgi?id=1411502 flr


Athos Ribeiro : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1411066 python-shortuuid


Filip Szymański : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1411036 python-ECPy


Haïkel Guémar : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1302744 
python-resumable-urlretrieve


Javier Peña : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1412605 python-tinyrpc


Jeremy Cline : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1411462 fegistry


Julien Enselme : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1342688 
python-livereload


Michael DePaulo : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1404012 
module-build-service


Miro Hrončok : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1392457 python2


Roland Grunberg : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1412008 
docker-client-java


Zbigniew Jędrzejewski-Szmek : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1412128 libpreludedb



Completed Review Requests: 35
This report was generated by bz-review-report.py.
The original source is available at: 
https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Jan Kurik]

= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt

Change owner(s):
* Vratislav Podzimek 
* Ondrej Kozina 


Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.


== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.

We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.

For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.

Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.

For rotational devices the cost of enabled discard is negligible


== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.

* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.


* Release engineering:
N/A

* List of deliverables:
N/A

* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.

* Trademark approval:
N/A
-- 
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

Re: Want to help me package Ampache?

[Matthew Miller]

On Mon, Jan 16, 2017 at 08:44:54AM +0100, Remi Collet wrote:
> I don't think this is a blocker.
> 
> Of course you can retire them when no more used by Ampache.
> 
> BTW, perhaps another way is to use bundled versions for these, to not
> expose them as something "stable and maintained".

Yeah, I was going to make this suggestion too. Seems like a reasonable
use of bundling — having them separate really makes things _worse_ for
other people in Fedora, not better. Plus, presumably Ampache itself as
an active project will be interested in making sure any security issues
that affect _that_ project are fixed in these libs, probably with their
own local patches.

-- 
Matthew Miller

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

Re: libglvnd review request, reviewer needed

[Hans de Goede]

Hi,

On 16-01-17 12:46, Hans de Goede wrote:

Hi,

On 13-01-2017 18:17, Nicolas Chauvet wrote:


On 13-01-17 16:56, Hans de Goede wrote:

Hi,

On 01/12/2017 11:24 PM, Nicolas Chauvet wrote:

2017-01-12 19:04 GMT+01:00 Hans de Goede :

Hi All,

I've just submitted a pkg review request for libglvnd:

https://bugzilla.redhat.com/show_bug.cgi?id=1412764

This is the last building block needed to allow full
parallel installation of the nvidia binary driver and
nouveau / mesa, without needing various *.conf.d to
select the right libGL.so / Xserver glx module, etc.

With this in place the entire Xorg / GL stack will
automatically do the right thing depending on which
kernel driver (nouveau or nvidia) is loaded, which
means that things will no longer break if the kernel /
userspace config do not match (as there is no more
userspace config), also see:

This is already in fedora since few months already.


Ah, I did not know that, that is great.

I plan to do a Fedora 25 update enabling
glvnd in mesa coming monday. I will also update
libglvnd to match and make it be the provider
of libGL.so.1, etc.

When I'm done I'll put both of them in a single bodhi update.

I've requested co-maintainer rights for libglvnd if
you can grant those, that would be great.


Sure, can you please open a bug so we can coordinate which
changes exactly you want to push.( there are additional patches
needed for pure mesa cases and glvnd - see
https://bugs.freedesktop.org/show_bug.cgi?id=98428 ).


I cannot reproduce the problem from that bug, as described in:

https://github.com/NVIDIA/libglvnd/issues/104

For me with the latest xserver + glvnd + glvnd-enabled mesa
I get the following in my xorg.log :

[24.160] (II) modeset(0): [DRI2] Setup complete
[24.160] (II) modeset(0): [DRI2]   DRI driver: i965
[24.160] (II) modeset(0): [DRI2]   VDPAU driver: i965
[24.160] (--) RandR disabled
[24.162] (II) SELinux: Disabled by boolean
[24.165] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[24.165] (II) AIGLX: enabled GLX_ARB_create_context
[24.165] (II) AIGLX: enabled GLX_ARB_create_context_profile
[24.165] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[24.165] (II) AIGLX: enabled GLX_INTEL_swap_event
[24.165] (II) AIGLX: enabled GLX_SGI_swap_control
[24.165] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[24.165] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[24.165] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[24.165] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[24.165] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[24.165] (II) AIGLX: Loaded and initialized i965
[24.165] (II) GLX: Initialized DRI2 GL provider for screen 0

I'll also make sure to test this with the intel ddx before
kicking of builds for this.


Ah, so it seems you're right, this is a problem but only
when using the intel ddx not when using the modesetting ddx
for some reason.

Also the patches I added from ajax already fix this, but
only for gallium drivers.

So I will add the 1st patch you've added to:

https://bugs.freedesktop.org/show_bug.cgi?id=98428

To the Fedora mesa pkg and remove the overlapping bits
from ajax' patch.

Regards,

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

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Adam Jackson]

On Sat, 2017-01-14 at 08:20 +0100, Branko Grubic wrote:

> I just want to mention that this change has been pushed (merged) to f25
> branch as well (which is not planed I guess), I filled bug #1413251 [1]

D'oh, my bad. New update in testing shortly.

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

Re: Is there something wrong with the Koji builders?

[Kevin Fenzi]

On Mon, 16 Jan 2017 09:38:25 -0500 (EST)
Jaroslav Skarvada  wrote:

> - Original Message -
> > I've done two builds for rawhide this morning.
> > 
> > On the first the armv7hl and ppc64le builds failed because the
> > source tar file could not be unpacked.
> > 
> > On the second the aarch64 build failed because the source tar file
> > could not be unpacked.
> > 
> > All the other arches built successfully.
> > 
> > --
> > 
> > Kaleb
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >   
> 
> I am encountering the same problem even on i686 (when trying to
> scratch build graphviz [1, 2]), so there is probably something wrong
> with the builders

Yes, there's been ongoing issues since last week: 

* This issue (which seems new in the last few days) where srpm isn't
  unpacking correctly.
  https://pagure.io/fedora-infrastructure/issue/5694

* Sometimes downloads of packages for the mock chroot are failing. Even
  though there's nothing at all wrong with the squid cache (and In fact
  I added a second one this weekend).
  https://pagure.io/fedora-infrastructure/issue/5689

* buildvm's are unstable and sometimes reboot or have odd kernel
  blowups. (The 4.9.x kernel bug is
  https://bugzilla.redhat.com/show_bug.cgi?id=1413314 but it might not
  be a kernel bug at all, since 4.8.x kernels are doing the same now as
  well.

I guess my monday is all mapped out for me. ;) 

will keep the above bugs posted and report back here when I figure
anything out. ;( 

kevin



pgpa0HlI2c10Z.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Kevin Fenzi]

On Sun, 15 Jan 2017 20:29:14 +0100
Martin Ueding  wrote:

> Am 15.01.2017 um 20:23 schrieb Kevin Fenzi:
> > Likely you are logged into a wayland session? In that case
> > xbacklight won't work. You could choose a Gnome on X11 session.   
> 
> I use Awesome WM which uses X.

Ah, then I have no idea what could be going on. 
Did xbacklight work in the past?

kevin


pgpLPU3bBAiRc.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFH: Annotating ELF binaries

[Carlos O'Donell]

On 01/16/2017 09:37 AM, Nick Clifton wrote:
> Hi H.J.
> 
>> We have 2 different proposals for program properties.  Mine:
>>
>> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html
>>
>> has a much smaller scope.  New features on upcoming Intel platforms,
>> like 5-level paging, need this extension for loader decision at run-time.
>> How should we move forward with program property extensions?
> 
> I would like to combine the two approaches.  Ie use your notes for
> properties that need to be examined at run-time (specifically the
> loader, although I imagine that the application itself might be 
> interested in reading its own notes).  Plus use the note scheme I
> am proposing for static analysis tools.
> 
> I am currently using a gcc plugin to generate the notes, and I think
> that this should be extendable to generate your notes as well.  (Using
> a plugin is advantageous in that it is not tied to the latest gcc release.
> It can be built to run with older gcc's, and it can be updated 
> independently of the gcc release cycle).
> 
> What do you think ?

I've added 2 questions to the Toolchain/Watermark wiki but will post them
here for posterity:

(1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what 
you are proposing?
 
(2) What is being done to ensure the attributes are space and time
efficient for dynamic link comparison in the dynamic linker? 
Speed of checking 10,000 DSOs (scalability) for ABI compatibility is 
going to be a very important requirement.

Comments:

(a) Ian requests clear separation between language and psABI notes.

Notes are notes. The attribute system should be sufficiently flexible to
handle both, and the "clear sepration" is just a documentation aspect,
and still important, but just about writing down what the notes mean in
clear detail.

(b) Loadable notes and space/time efficiency vs. non-loadable notes and
static analysis tools.

Run-time checking of properties is radically different from offline
checking of properties and we absolutely need two different designs to
meet these needs. However, if we could weld the two together in a compatible
way, that would be great. For example if the dynamic loader could map from
a 'run-time property' to a 'link-time property' to increase the verbosity
of the error in a failure scenario, then that might be beneficial. If we
could translate 'link-time notes' into 'a collection of run-time properties' in
a semi-automatic fashion given strict rules about the notes application,
then that would also be awesome.

(c) The case against SHT_GNU_ATTRIBUTES (Question 2).

Not used. -- Then we should just use them for x86.

IFUNC complication. -- Any new framework must be able to tolerate that
a given interface may have a "range" of ABIs it works with, and those
represent the set of ABIs it can change to. Attributes that don't allow
sets of values are going to be problematic in the face of IFUNCs.

No loadable segment. -- Correct. They were designed for link-time support only.

Most attributes don't apply to dynamic loading. -- Correct. Space inefficient.

Layout not optimal for loading.  -- Correct. Time/Space inefficient.

In summary SHT_GNU_ATTRIBUTES might not work for run-time properties, but
what about link-time properties? Why not resuse this framework?

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

Orphaning Packages

[Robert Rati]

Packages without co-maintainers:
condor-ec2-enhanced
condor-ec2-enhanced-hooks
condor-job-hooks
condor-low-latency


Packages with co-admins:
jung
apache-log4j-extras
greenmail
jamon-api
jamon-java-parent
jamon-maven-plugin
jamon-nodegen-plugin
jamon-parent
jamon-processor
jamon-runtime
wso2-wsf-cpp
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: drop obsolete static uid/gid allocations

[Richard W.M. Jones]

On Sun, Jan 15, 2017 at 12:13:16AM +, Zbigniew Jędrzejewski-Szmek wrote:
> == The following are completely unused?
> console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> pvm, xfs

I'm going to guess that wnn is related to the Japanese input method of
the same name.  (canna, also a Japanese input method, has its own
static uid & gid registered too).  Both packages run daemons in the
background.

I'm also going to guess that vcsa is something to do with the
/dev/vcs* virtual console devices, although if that's the case then
the group is no longer used.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

nfs-utils-2.1.1 Changes Everything!

[Steve Dickson]

Hello,

The latest nfs-utils release drastically changes how the NFS
servers are configured, for the good IMHO...

All daemon  configuration now goes through /etc/nfs.conf.
See nfs.conf(5) for details.

The command line interfaces in the systemd services files
have been removed. Which means all your current configures
will break, because the variables in /etc/sysconfig/nfs are
no longer used.

Again, I think is a move in the right direction and I know
you might find this surprising 8-) but I really don't want to
break all the current server configuration. So I'm trying t
o figure out how to do this with least amount of impact.

Here is what I see as the options

1) Upgrade rawhide w/out a backward compatible patch
(since it is so early in the release cycle)
Upgrade f25 with an backwards compatible patch 

2) Upgrade rawhide and f25 with the backward compatible
patch... but we have to ween ourselves of the command
line interface at some point...

3) Do nothing and push everything into f27, which is the least
favorite option.

I'm leaning toward option 1... but I'm asking... so I'm listening. :-)

Also, how do I documented something like this?

tia,

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

Planned Outage: Taskotron - 2017-01-17 20:00 UTC

[Tim Flink]

There will be an outage starting at 2017-01-17 20:00 UTC, which will
last approximately 12 hours.

To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:

date -d '2016-01-17 20:00 UTC'

Reason for outage:

We will be upgrading Taskotron to a new version which requires a
migration that will take 8-12 hours. This migration will be very
infrequent if it ever happens and we don't anticipate needing long
outages like this in the future

All jobs which would have run during the outage will be queued for
execution after the outage has completed

Affected Services:

All services on taskotron.fedoraproject.org

Ticket Information: https://pagure.io/fedora-infrastructure/issue/5697

Contact Information: infrastruct...@lists.fedoraproject.org

Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.


pgpFXbVbPMvtY.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: nfs-utils-2.1.1 Changes Everything!

[Ben Cotton]

This strikes me as something that really should go through the change
process. Based on the schedule, you could still get into Rawhide for
eventual inclusion in f26.

As for documenting, it should definitely get a release note that gives
at least some description of the change. If there are more complex
actions involved, it might be worth including something in the System
Administration Guide as well. See the f25 guide
(https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/index.html)
for maintainer information.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Josh Boyer]

On Mon, Jan 16, 2017 at 3:11 PM, Steve Dickson  wrote:
> Hello,
>
> The latest nfs-utils release drastically changes how the NFS
> servers are configured, for the good IMHO...
>
> All daemon  configuration now goes through /etc/nfs.conf.
> See nfs.conf(5) for details.
>
> The command line interfaces in the systemd services files
> have been removed. Which means all your current configures
> will break, because the variables in /etc/sysconfig/nfs are
> no longer used.
>
> Again, I think is a move in the right direction and I know
> you might find this surprising 8-) but I really don't want to
> break all the current server configuration. So I'm trying t
> o figure out how to do this with least amount of impact.
>
> Here is what I see as the options
>
> 1) Upgrade rawhide w/out a backward compatible patch
> (since it is so early in the release cycle)
> Upgrade f25 with an backwards compatible patch
>
> 2) Upgrade rawhide and f25 with the backward compatible
> patch... but we have to ween ourselves of the command
> line interface at some point...
>
> 3) Do nothing and push everything into f27, which is the least
> favorite option.
>
> I'm leaning toward option 1... but I'm asking... so I'm listening. :-)

If you had to transition RHEL customers from the old style to the new
style with a specific support timeframe in mind, how would you do it?
That's what I would do here.

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

Re: nfs-utils-2.1.1 Changes Everything!

[John Florian]

On Mon, 2017-01-16 at 15:11 -0500, Steve Dickson wrote:

Hello,

The latest nfs-utils release drastically changes how the NFS
servers are configured, for the good IMHO...

All daemon  configuration now goes through /etc/nfs.conf.
See nfs.conf(5) for details.

The command line interfaces in the systemd services files
have been removed. Which means all your current configures
will break, because the variables in /etc/sysconfig/nfs are
no longer used.

Again, I think is a move in the right direction and I know
you might find this surprising 8-) but I really don't want to
break all the current server configuration. So I'm trying t
o figure out how to do this with least amount of impact.

Here is what I see as the options

1) Upgrade rawhide w/out a backward compatible patch
(since it is so early in the release cycle)
Upgrade f25 with an backwards compatible patch

2) Upgrade rawhide and f25 with the backward compatible
patch... but we have to ween ourselves of the command
line interface at some point...

3) Do nothing and push everything into f27, which is the least
favorite option.

I'm leaning toward option 1... but I'm asking... so I'm listening. :-)

Also, how do I documented something like this?

tia,

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



I'd only ask that the transition only occur in a clean break between OS 
releases. For those of us managing Puppet, Ansible, etc. it's hard to be 
adaptive to these things unless there's a good condition we can use. It sounds 
like all your proposals would achieve that, but I thought I ought mention it 
anyway.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

post-receive-alternativearch git hook bug?

[Jerry James]

Just did a git push to polymake and got this:


$ git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 454 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: * Notifying alternative-arch people
remote: Traceback (most recent call last):
remote:   File "./hooks/post-receive-chained.d/post-receive-alternativearch",
line 196, in 
remote: run_as_post_receive_hook()
remote:   File "./hooks/post-receive-chained.d/post-receive-alternativearch",
line 188, in run_as_post_receive_hook
remote: pkg=package, url='\n'.join(links), change="\n".join(diffs)
remote: TypeError: not enough arguments for format string

It appears to have been non-fatal, but perhaps somebody could fix that
hook?  Thanks and regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: post-receive-alternativearch git hook bug?

[Pierre-Yves Chibon]

On Mon, Jan 16, 2017 at 02:08:53PM -0700, Jerry James wrote:
> Just did a git push to polymake and got this:
> 
> 
> $ git push
> Counting objects: 3, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 454 bytes | 0 bytes/s, done.
> Total 3 (delta 2), reused 0 (delta 0)
> remote: Emitting a message to the fedmsg bus.
> remote: * Publishing information for 1 commits
> remote: * Notifying alternative-arch people
> remote: Traceback (most recent call last):
> remote:   File "./hooks/post-receive-chained.d/post-receive-alternativearch",
> line 196, in 
> remote: run_as_post_receive_hook()
> remote:   File "./hooks/post-receive-chained.d/post-receive-alternativearch",
> line 188, in run_as_post_receive_hook
> remote: pkg=package, url='\n'.join(links), change="\n".join(diffs)
> remote: TypeError: not enough arguments for format string
> 
> It appears to have been non-fatal, but perhaps somebody could fix that
> hook?  Thanks and regards,

Fixed in:
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=737f6c5

Many thanks for letting us know!
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: nfs-utils-2.1.1 Changes Everything!

[Steve Dickson]

On 01/16/2017 03:24 PM, Ben Cotton wrote:

> This strikes me as something that really should go through the change
> process. Based on the schedule, you could still get into Rawhide for
> eventual inclusion in f26.
I'll be more than willing to do that.. Please advise.

> As for documenting, it should definitely get a release note that gives
> at least some description of the change. If there are more complex
> actions involved, it might be worth including something in the System
> Administration Guide as well. See the f25 guide
> (https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/index.html)
> for maintainer information.
I agree... how is that done?

steved.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Steve Dickson]

On 01/16/2017 03:25 PM, Josh Boyer wrote:
> On Mon, Jan 16, 2017 at 3:11 PM, Steve Dickson  wrote:
>> Hello,
>>
>> The latest nfs-utils release drastically changes how the NFS
>> servers are configured, for the good IMHO...
>>
>> All daemon  configuration now goes through /etc/nfs.conf.
>> See nfs.conf(5) for details.
>>
>> The command line interfaces in the systemd services files
>> have been removed. Which means all your current configures
>> will break, because the variables in /etc/sysconfig/nfs are
>> no longer used.
>>
>> Again, I think is a move in the right direction and I know
>> you might find this surprising 8-) but I really don't want to
>> break all the current server configuration. So I'm trying t
>> o figure out how to do this with least amount of impact.
>>
>> Here is what I see as the options
>>
>> 1) Upgrade rawhide w/out a backward compatible patch
>> (since it is so early in the release cycle)
>> Upgrade f25 with an backwards compatible patch
>>
>> 2) Upgrade rawhide and f25 with the backward compatible
>> patch... but we have to ween ourselves of the command
>> line interface at some point...
>>
>> 3) Do nothing and push everything into f27, which is the least
>> favorite option.
>>
>> I'm leaning toward option 1... but I'm asking... so I'm listening. :-)
> If you had to transition RHEL customers from the old style to the new
> style with a specific support timeframe in mind, how would you do it?
> That's what I would do here.
Are you kidding me! :-) There is no way, IMHO,  to will transition this type of
change into a current RHEL releases. Going forward... only time will tell...

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

Re: nfs-utils-2.1.1 Changes Everything!

[Ben Cotton]

Steve,

The change process is documented at
https://fedoraproject.org/wiki/Changes/Policy

The release notes beats writers will generally search the change list for
changes relevant to their beat. The change proposal template includes a
place for you to draft a release note or include information that will help
the writer fill in the appropriate information.

For the System Administration Guide, visit https://docs.fedoraproject.
org/en-US/Fedora/25/html/System_Administrators_Guide/

and
you see several email addressesnfor authors that you can contact directly.
Alternately, you can email the docs team at docs lists.fedoraproject.org.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: nfs-utils-2.1.1 Changes Everything!

[Josh Boyer]

On Mon, Jan 16, 2017 at 4:45 PM, Steve Dickson  wrote:
>
>
> On 01/16/2017 03:25 PM, Josh Boyer wrote:
>> On Mon, Jan 16, 2017 at 3:11 PM, Steve Dickson  wrote:
>>> Hello,
>>>
>>> The latest nfs-utils release drastically changes how the NFS
>>> servers are configured, for the good IMHO...
>>>
>>> All daemon  configuration now goes through /etc/nfs.conf.
>>> See nfs.conf(5) for details.
>>>
>>> The command line interfaces in the systemd services files
>>> have been removed. Which means all your current configures
>>> will break, because the variables in /etc/sysconfig/nfs are
>>> no longer used.
>>>
>>> Again, I think is a move in the right direction and I know
>>> you might find this surprising 8-) but I really don't want to
>>> break all the current server configuration. So I'm trying t
>>> o figure out how to do this with least amount of impact.
>>>
>>> Here is what I see as the options
>>>
>>> 1) Upgrade rawhide w/out a backward compatible patch
>>> (since it is so early in the release cycle)
>>> Upgrade f25 with an backwards compatible patch
>>>
>>> 2) Upgrade rawhide and f25 with the backward compatible
>>> patch... but we have to ween ourselves of the command
>>> line interface at some point...
>>>
>>> 3) Do nothing and push everything into f27, which is the least
>>> favorite option.
>>>
>>> I'm leaning toward option 1... but I'm asking... so I'm listening. :-)
>> If you had to transition RHEL customers from the old style to the new
>> style with a specific support timeframe in mind, how would you do it?
>> That's what I would do here.
> Are you kidding me! :-) There is no way, IMHO,  to will transition this type 
> of
> change into a current RHEL releases. Going forward... only time will tell...

No, I didn't mean introduce it in e.g. 7.2 -> 7.3.  I meant how would
you phase this in so users using e.g. RHEL 7 have sufficient lead time
to migrate to the new style whenever the next major RHEL release comes
out.  What tools or scripts would you put in place to help with mixed
release environments?  Are there upgrade tools that would be needed?
Those are the things I would think about.  They apply to Fedora
releases as well.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Chris Murphy]

It's definitely a change.

If there's going to be breakage, i.e. no migration tool or script,
then that can't apply retroactively. Just silently breaking Fedora 25
is not OK, I predict only widespread irritation.

A hard break for Fedora 26 or 27 still makes me wonder why there's no
migration tool or script, rather than expect people with possibly
complex setups to have to redo configuration by hand? If there's some
sort of ambiguity and non-standard aspect to existing configuration
files that makes this difficult, hopefully the new configuration
format is designed to be easily parsed automatically so the next time
there's a configuration format change that it can be automatically
migrated. And if the new configuration format doesn't lend itself to
automatic migrations, then I'd say the change should be rejected.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Steve Dickson]

On 01/16/2017 04:58 PM, Josh Boyer wrote:
> On Mon, Jan 16, 2017 at 4:45 PM, Steve Dickson  wrote:
>>
>> On 01/16/2017 03:25 PM, Josh Boyer wrote:
>>> On Mon, Jan 16, 2017 at 3:11 PM, Steve Dickson  wrote:
 Hello,

 The latest nfs-utils release drastically changes how the NFS
 servers are configured, for the good IMHO...

 All daemon  configuration now goes through /etc/nfs.conf.
 See nfs.conf(5) for details.

 The command line interfaces in the systemd services files
 have been removed. Which means all your current configures
 will break, because the variables in /etc/sysconfig/nfs are
 no longer used.

 Again, I think is a move in the right direction and I know
 you might find this surprising 8-) but I really don't want to
 break all the current server configuration. So I'm trying t
 o figure out how to do this with least amount of impact.

 Here is what I see as the options

 1) Upgrade rawhide w/out a backward compatible patch
 (since it is so early in the release cycle)
 Upgrade f25 with an backwards compatible patch

 2) Upgrade rawhide and f25 with the backward compatible
 patch... but we have to ween ourselves of the command
 line interface at some point...

 3) Do nothing and push everything into f27, which is the least
 favorite option.

 I'm leaning toward option 1... but I'm asking... so I'm listening. :-)
>>> If you had to transition RHEL customers from the old style to the new
>>> style with a specific support timeframe in mind, how would you do it?
>>> That's what I would do here.
>> Are you kidding me! :-) There is no way, IMHO,  to will transition this type 
>> of
>> change into a current RHEL releases. Going forward... only time will tell...
> No, I didn't mean introduce it in e.g. 7.2 -> 7.3.  I meant how would
> you phase this in so users using e.g. RHEL 7 have sufficient lead time
> to migrate to the new style whenever the next major RHEL release comes
> out.  What tools or scripts would you put in place to help with mixed
> release environments?  
Understood... I see this as similar to migrating from the SysV init scripts to
systemd... what of tools where there for that? I didn't see many... which is 
fine.
I just wanted to raise the flag that this was happening...

> Are there upgrade tools that would be needed?
> Those are the things I would think about.  They apply to Fedora
> releases as well.
I can't agree with this more... How does one migrate from one configuration
model to another? This is exactly why I'm bring this up to the community.

I will be more than willing to work with any project to make this transition
be as smooth as possible.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Matthew Miller]

On Mon, Jan 16, 2017 at 05:24:28PM -0500, Steve Dickson wrote:
> Understood... I see this as similar to migrating from the SysV init
> scripts to systemd... what of tools where there for that? I didn't
> see many... which is fine.

Well, systemd offers backwards compatibility — old-style init scripts
just keep working until you decide you want to switch.

> I can't agree with this more... How does one migrate from one configuration
> model to another? This is exactly why I'm bring this up to the community.
> 
> I will be more than willing to work with any project to make this transition
> be as smooth as possible.

Thanks! This is very appreciated. 


-- 
Matthew Miller

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

Re: nfs-utils-2.1.1 Changes Everything!

[Steve Dickson]

On 01/16/2017 05:16 PM, Chris Murphy wrote:
> It's definitely a change.
>
> If there's going to be breakage, i.e. no migration tool or script,
> then that can't apply retroactively. Just silently breaking Fedora 25
> is not OK, I predict only widespread irritation.
No.. breaking f25 will not happen... If f25 is upgraded, I already have a
backwards compatible patch that will support both configuration
models.
 
> A hard break for Fedora 26 or 27 still makes me wonder why there's no
> migration tool or script, rather than expect people with possibly
> complex setups to have to redo configuration by hand? 
Yes.. this is the problem.. How does one migrate from one configuration
model to another... smoothly...
 
> If there's some
> sort of ambiguity and non-standard aspect to existing configuration
> files that makes this difficult, hopefully the new configuration
> format is designed to be easily parsed automatically so the next time
> there's a configuration format change that it can be automatically
> migrated. And if the new configuration format doesn't lend itself to
> automatic migrations, then I'd say the change should be rejected.
The new configuration will allow  external project to configure NFS more
easily... In theory... There is talk about moving /etc/nfsmout.conf and
/etc/idmount.conf into /etc/nfs.conf... which would mean both the
server and client would be configurable from one file.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Matthew Miller]

On Mon, Jan 16, 2017 at 05:38:03PM -0500, Steve Dickson wrote:
> > If there's going to be breakage, i.e. no migration tool or script,
> > then that can't apply retroactively. Just silently breaking Fedora 25
> > is not OK, I predict only widespread irritation.
> No.. breaking f25 will not happen... If f25 is upgraded, I already have a
> backwards compatible patch that will support both configuration
> models.

How painful is it to carry this patch for... a long time?


-- 
Matthew Miller

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

Re: drop obsolete static uid/gid allocations

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 16, 2017 at 10:45:00AM +0100, Ondřej Vašík wrote:
> Zbigniew Jędrzejewski-Szmek píše v Ne 15. 01. 2017 v 00:13 +:
> > https://git.fedorahosted.org/cgit/setup.git/tree/uidgid has a list
> > of "soft static" uids and gids.
> > 
> > Currently FPC has a process for allocating new numbers on this list,
> > but here's a number of static uid/gid allocations from old times,
> > which are not necessary. Dropping them will allow those numbers to be
> > used in the dynamic pool, reducing the risk of exhaustion of system
> > uids or gids.
> 
> Dynamic pool uses static id area only in the worst case when uid/gids
> 200-999 are already allocated.
> From the users listed down only "games" user is created by default - so
> unless the package that creates the uid/gid is installed, their ids can
> theoretically be used for dynamic ids creation. If they are on the
> system, you will not get anything by removal of static allocation - as
> they will occupy some dynamic id anyway.

OK. So this makes the removal less useful than I thought, more of a cleanup
then a user-visible change. I'd still like to go through with it though.

> > games, man, slocate, squid, named, postgres, mysql, nscd,
> > rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp,
> > tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd,
> > imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci
> 
> I agree for some of these I don't see any need for static id allocation
> - and they have static id allocated only for historical reasons. (typo
> s/tcpdmp/tcpdump btw.).
> I don't see imap in the uidgid file.

I was copying the stuff by hand, digging for information about packages
online, and I must have copied from the wrong column. There is cyrus, saslauth
in the uidgid list, but those seems to fall into the same category as
mysql/apache/tomcat mentioned elsewhere in the thread, that people want
to keep static because it's more likely to be shared over the network.

> > == The following are completely unused?
> > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> > pvm, xfs
> 
> From 45 ids listed above, 40 were reserved before I got maintenance of
> the setup package (2008). Only 4 (saned, mock, ricci, luci) were added
> by me and 1 is not in uidgid file at all.
> Reason for mock is explained in
> https://bugzilla.redhat.com/show_bug.cgi?id=928063#c0 . For ricci/luci,
> I expect reason for the static id is they belong to High
> Availability/Cluster... However, they were dropped meanwhile. Saned
> probably doesn't need static id, though.

Oh, OK. Maybe we could add comments to the uidgid list with links to the
tickets (at least going forward)?

> However, even if I drop these static allocation, I don't think we can
> reuse them for any other static allocations anytime soon
I grok this part

> - as this could
> mean dynamic allocation for the new potentially statically allocated
> account - if the system was maintained via upgrades from older
> Fedoras/RHELs/CentOS.
But not this. If a system has been continually upgraded and has the
"soft static" user actually created in the local user database, if the
allocation is dropped, it will not be removed from the local user
database, so for those systems nothing would change.

For systems which do *not* have the de-allocated user in the local
database, if a package which creates that user will be installed, an
uid for that user will be pulled from 200-999, and if that range is
completely full, from the soft-static range, as you said above. So
again, very little changes.

> IMHO, drop of these allocation doesn't bring much gain (except cleaner
> uidgid file) and brings some potential risks that can show in future.

I think a cleaner uidgid file is useful: right now that list is a bit
of a museum piece of history of fedora.
OK, so what you as the maintainer, think is worth doing:
a) drop really unused entries (approximately my second list with some 
corrections)
b) drop used-but-unneeded entries (approx. my first list)
?

With ~195 entries the pool of soft static uids is getting low. So
*some* changes will be needed. A cleanup of this list should be a useful
first step.

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

Re: drop obsolete static uid/gid allocations

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 16, 2017 at 07:03:31PM +, Richard W.M. Jones wrote:
> On Sun, Jan 15, 2017 at 12:13:16AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > == The following are completely unused?
> > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> > pvm, xfs
> 
> I'm going to guess that wnn is related to the Japanese input method of
> the same name.  (canna, also a Japanese input method, has its own
> static uid & gid registered too).  Both packages run daemons in the
> background.

OK, thanks. What's the package for wnn?

canna clearly does not need a static uid, and interestingly, it seems
to use dynamic allocation.  So it's just taking up space in the list ;)

> I'm also going to guess that vcsa is something to do with the
> /dev/vcs* virtual console devices, although if that's the case then
> the group is no longer used.
It seems to be used under redhat, removed in commit abbc1c17a0c from
udev/systemd (May 2010). I seems that that file was not under Fedora,
but I'm not sure.

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

Re: nfs-utils-2.1.1 Changes Everything!

[Michael Watters]

Ideally the package should have an upgrade script included to translate
any values set in /etc/sysconfig/nfs into /etc/nfs.conf.  I also believe
it would be best to hold off any breaking changes until Fedora 26.

On 1/16/17 5:24 PM, Steve Dickson wrote:
> I can't agree with this more... How does one migrate from one configuration
> model to another? This is exactly why I'm bring this up to the community.
>
> I will be more than willing to work with any project to make this transition
> be as smooth as possible.
>
> steved. 
> ___
> 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

dnf system-upgrade fails

[Michael Watters]

I have a server running Fedora 24 which I am attempting to upgrade to
Fedora 25.  I've followed the instructions located at
https://fedoraproject.org/wiki/DNF_system_upgrade however the upgrade
process fails after the system is rebooted to run the initial upgrade.
Here are the log entries from my dnf.log file which show some errors.

Jan 16 10:40:16 DEBUG --> Starting dependency resolution
Jan 16 10:40:16 DEBUG --> Finished dependency resolution
Jan 16 10:40:16 DDEBUG timer: depsolve: 166 ms
Jan 16 10:40:16 SUBDEBUG
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 120, in
_main
ret = resolving(cli, base)
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 139, in
resolving
base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.5/site-packages/dnf/base.py", line 541, in resolve
raise exc
dnf.exceptions.DepsolveError: nothing provides kmod-libs(x86-64) =
23-1.fc25 needed by kmod-23-1.fc25.x86_64.
nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by
iptables-1.6.0-2.fc25.x86_64.
nothing provides adwaita-gtk2-theme = 3.22.2-1.fc25 needed by
gnome-themes-standard-3.22.2-1.fc25.x86_64.
nothing provides fipscheck-lib(x86-64) = 1.4.1-11.fc25 needed by
fipscheck-1.4.1-11.fc25.x86_64.
nothing provides system-release(25) needed by fedora-repos-25-1.noarch.
nothing provides python3-dnf-plugins-core = 0.1.21-4.fc25 needed by
dnf-plugins-core-0.1.21-4.fc25.noarch.
package cockpit-shell-120-1.fc25.noarch is not installable.
nothing provides python2-future needed by
python2-stomper-0.4.0-2.fc25.noarch.
nothing provides python-click needed by
python2-flask-1:0.11.1-3.fc25.noarch.
package cronie-anacron-1.5.1-2.fc24.x86_64 requires cronie =
1.5.1-2.fc24, but none of the providers can be installed.
package cryptsetup-1.7.2-1.fc24.x86_64 requires cryptsetup-libs =
1.7.2-1.fc24, but none of the providers can be installed.
package dhcp-client-12:4.3.4-3.fc24.x86_64 requires dhcp-common =
12:4.3.4-3.fc24, but none of the providers can be installed.
package file-5.25-6.fc24.x86_64 requires file-libs = 5.25-6.fc24, but
none of the providers can be installed.
package ipset-6.27-2.fc24.x86_64 requires ipset-libs(x86-64) =
6.27-2.fc24, but none of the providers can be installed.
nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by
iptables-1.6.0-2.fc25.x86_64
Jan 16 10:40:16 CRITICAL Error: nothing provides kmod-libs(x86-64) =
23-1.fc25 needed by kmod-23-1.fc25.x86_64.
nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by
iptables-1.6.0-2.fc25.x86_64.
nothing provides adwaita-gtk2-theme = 3.22.2-1.fc25 needed by
gnome-themes-standard-3.22.2-1.fc25.x86_64.
nothing provides fipscheck-lib(x86-64) = 1.4.1-11.fc25 needed by
fipscheck-1.4.1-11.fc25.x86_64.
nothing provides system-release(25) needed by fedora-repos-25-1.noarch.
nothing provides python3-dnf-plugins-core = 0.1.21-4.fc25 needed by
dnf-plugins-core-0.1.21-4.fc25.noarch.
package cockpit-shell-120-1.fc25.noarch is not installable.
nothing provides python2-future needed by
python2-stomper-0.4.0-2.fc25.noarch.
nothing provides python-click needed by
python2-flask-1:0.11.1-3.fc25.noarch.
package cronie-anacron-1.5.1-2.fc24.x86_64 requires cronie =
1.5.1-2.fc24, but none of the providers can be installed.
package cryptsetup-1.7.2-1.fc24.x86_64 requires cryptsetup-libs =
1.7.2-1.fc24, but none of the providers can be installed.
package dhcp-client-12:4.3.4-3.fc24.x86_64 requires dhcp-common =
12:4.3.4-3.fc24, but none of the providers can be installed.
package file-5.25-6.fc24.x86_64 requires file-libs = 5.25-6.fc24, but
none of the providers can be installed.
package ipset-6.27-2.fc24.x86_64 requires ipset-libs(x86-64) =
6.27-2.fc24, but none of the providers can be installed.
nothing provides iptables-libs(x86-64) = 1.6.0-2.fc25 needed by
iptables-1.6.0-2.fc25.x86_64
Jan 16 10:40:16 INFO (try to add '--allowerasing' to command line to
replace conflicting packages)
Jan 16 10:40:16 DDEBUG Cleaning up.

Is there a way to resolve this?  I tried adding the --allowerasing
option which resulted in dnf attempting to remove the dnf and systemd
packages.

Jan 16 11:29:41 SUBDEBUG
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 60, in main
return _main(base, args)
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 120, in
_main
ret = resolving(cli, base)
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 142, in
resolving
base._plugins.run_resolved()
  File "/usr/lib/python3.5/site-packages/dnf/plugin.py", line 82, in fn
dnf.util.mapall(operator.methodcaller(method), self.plugins)
  File "/usr/lib/python3.5/site-packages/dnf/util.py", line 183, in mapall
return list(map(fn, *seq))
  File
"/usr/lib/python3.5/site-packages/dnf-plugins/protected_packages.py",
line 76, in resolved
raise dnf.exceptions.Error(THREATENED_MSG % ', '.join(threatened))
dnf.exceptions.Error: The operation wo

Re: dnf system-upgrade fails

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 16, 2017 at 10:05:38PM -0500, Michael Watters wrote:
> package cronie-anacron-1.5.1-2.fc24.x86_64 requires cronie =
> 1.5.1-2.fc24, but none of the providers can be installed.
> package cryptsetup-1.7.2-1.fc24.x86_64 requires cryptsetup-libs =
> 1.7.2-1.fc24, but none of the providers can be installed.
> package dhcp-client-12:4.3.4-3.fc24.x86_64 requires dhcp-common =
> 12:4.3.4-3.fc24, but none of the providers can be installed.
> package file-5.25-6.fc24.x86_64 requires file-libs = 5.25-6.fc24, but
> none of the providers can be installed.
> package ipset-6.27-2.fc24.x86_64 requires ipset-libs(x86-64) =
> 6.27-2.fc24, but none of the providers can be installed.

It looks like something is holding back the upgrade. Normally this
should get detected in the 'dnf system-upgrade --download' phase,
and not after reboot, but let's ignore that for now.

Do you have some very old packages that don't have an upgrade
and are not obsoleted by anything? I'd guess that one of them is
holding back either cryptsetup-libs or file-libs or ipset-libs...
Try   rpm -qa|grep -vE '\.fc2[456]|gpg-pubkey|debuginfo'

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

FESCo Elections - January 2017 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for FESCo - January 2017 have concluded, and the results
are shown below.

FESCo is electing 5 seats this time.
A total of 267 ballots were cast, meaning a candidate
could accumulate up to 1869 votes (267 * 7).

The results for the elections are as follows:

  # votes |  name
- +--
1401  | Kevin Fenzi (nirik / kevin)
1075  | Adam Miller (maxamillion / maxamillion)
 988  | Jared Smith (jsmith / jsmith)
 735  | Justin Forbes (jforbes / jforbes)
 691  | Kalev Lember (kalev / kalev)
- +--
 558  | Itamar Reis Peixoto (itamarjp / itamarjp)
 539  | Frederico Lima (fredlima / fredlima)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!
-- 
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

Council Elections - January 2017 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for Council - January 2017 have concluded, and the results
are shown below.

Council is electing 1 seats this time.
A total of 260 ballots were cast, meaning a candidate
could accumulate up to 1300 votes (260 * 5).

The results for the elections are as follows:

  # votes |  name
- +--
 743  | Robert Mayr (robyduck)
- +--
 738  | Justin W. Flory (jflory7)
 466  | Giannis Konstantinidis (giannisk)
 413  | Charles Profitt (cprofitt)
 393  | Itamar Reis Peixoto (itamarjp/itamarjp)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!
-- 
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

FAmSCo Elections - January 2017 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for FAmSCo Elections - January 2017 have concluded, and
the results
are shown below.

FAmSCo is electing 7 seats this time.
A total of 247 ballots were cast, meaning a candidate
could accumulate up to 3211 votes (247 * 13).

The results for the elections are as follows:

  # votes |  name
- +--
1623  | Robert Mayr (robyduck)
1576  | Jona Azizaj (jonatoni)
1274  | Gabriele Trombini (mailga)
1168  | Giannis Konstantinidis (giannisk)
1110  | Itamar Reis Peixoto (itamarjp)
1010  | Frederico Lima (fredlima)
 964  | Sylvia Sanchez (Kohane / lailah)
- +--
 944  | Sirko Kemter (gnokii)
 920  | Zacharias Mitzelos (mitzie)
 862  | Marcel Ribeiro Dantas (mribeirodantas)
 856  | Daniel Lara (danniel)
 735  | Lucas Landim (landim)
 731  | Tulio Macedo (_Teseu_ / teseu)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!
-- 
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

Re: drop obsolete static uid/gid allocations

[Richard W.M. Jones]

On Mon, Jan 16, 2017 at 11:42:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 16, 2017 at 07:03:31PM +, Richard W.M. Jones wrote:
> > On Sun, Jan 15, 2017 at 12:13:16AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > == The following are completely unused?
> > > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> > > pvm, xfs
> > 
> > I'm going to guess that wnn is related to the Japanese input method of
> > the same name.  (canna, also a Japanese input method, has its own
> > static uid & gid registered too).  Both packages run daemons in the
> > background.
> 
> OK, thanks. What's the package for wnn?

A good question!  It took me a while to find, but it looks like we
have now dropped it.  Before it was dropped the package was called
FreeWnn:

  http://pkgs.fedoraproject.org/cgit/rpms/FreeWnn.git

Here is the evidence that it did use the 'wnn' user & group (49.49):

  
http://pkgs.fedoraproject.org/cgit/rpms/FreeWnn.git/tree/FreeWnn.spec?id=5619304c4bf456a7b79ec19fef57b1812aa831e9#n59

For reference, in Debian & Wikipedia it's:

  https://packages.debian.org/sid/freewnn-jserver
  https://en.wikipedia.org/wiki/Wnn

> canna clearly does not need a static uid, and interestingly, it seems
> to use dynamic allocation.  So it's just taking up space in the list ;)
> 
> > I'm also going to guess that vcsa is something to do with the
> > /dev/vcs* virtual console devices, although if that's the case then
> > the group is no longer used.
> It seems to be used under redhat, removed in commit abbc1c17a0c from
> udev/systemd (May 2010). I seems that that file was not under Fedora,
> but I'm not sure.

Good find.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org