date:20180110

On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote:
> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Wed, Jan 10, 2018 at 11:56:46AM +0100, Reindl Harald wrote:
> >>
> >> Am 10.01.2018 um 11:46 schrieb Jan Kurik:
> >> >On existing systems, to make upgrades easier:
> >> >* if nfsnobody was defined, keep it in /etc/passwd *after* the new
> >> >line for nobody:nobody, so that both the old name and the new name map
> >> >to the same numbers
> >> >* if nobody user or group with number 99 was defined, keep it in
> >> >/etc/passwd and /etc/group, but rename to _nobody
> >> that don't make updates easier but breaks existing setups where
> >> nobody:nobody with 99:99 already owns files - don't touch long years
> >> running machines due dist-upgrades please - at least not with "dnf
> >> --releasever=28 distro-sync"
> >
> > That'd amount to leaving existing systems unchanged. That's an option
> > that I didn't like and initially rejected, but yeah, it's probably better.
> > I'll wait a bit more for feedback and update the proposal a bit later
> > to leave existing systems alone (i.e. systems which have either nobody
> > or nfsnobody already defined in the old style).
> >
> > Zbyszek
> 
> This is particularly relevant for rsync or tar restorations from old
> backups, and to NFS shares exposed across old and new environments.
> It's why changing active uid and and gid for any account can be
> perniciously awkward.

Based on this and other feedback, we updated the proposal.
We discussed all the ways in which we could try to reliably determine
if "nobody" is actually used, but that seems impossible. So the updated
version is:

1. update setup.rpm to nobody=65534 on new systems
2. teach systemd to not provide any mapping for nobody (in PID1 and in
   nss-systemd) based on a flag file, and create this file in %post if
   either nobody=99 or nfsnobody users are defined.

This essentially means that existing systems would behave as before,
and new systems will have just one nobody user with uid=65534.

See https://fedoraproject.org/wiki/Changes/RenameNobodyUser for more
detailed description.

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

Re: F28 System Wide Change: Rename "nobody" user

On Wed, Jan 10, 2018 at 10:21:32AM -0500, Matthew Miller wrote:
> On Wed, Jan 10, 2018 at 11:46:13AM +0100, Jan Kurik wrote:
> > Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
> > and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
> > with 99:99 numbers
> 
> See previous thread on this proposal from two years ago:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5GCKZ7Q7PAUQW66EV7IBJGSRJWYXBBH/?sort=date
> 
> There's some good discussion there. I'm still in favor. 

Right. The same people participate in the discussion and the same
things are said. The funny thing is that not the same people are
always saying the same thing.

The situation got both more complicated (because of nss-systemd)
and simpler (because of the one concrete effect of that discussion,
i.e. FPC forbidding the use of "nobody").

I added this link to the Change page.

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

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

On Wed, Jan 10, 2018 at 11:35:16PM +, Sérgio Basto wrote:
> On Wed, 2018-01-10 at 22:27 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Jan 09, 2018 at 08:27:51PM +, Sérgio Basto wrote:
> > > On Tue, 2018-01-09 at 18:28 +0100, Till Hofmann wrote:
> > > > 
> > > > On 01/09/2018 05:53 PM, Sérgio Basto wrote:
> > > > > Packages remaining to rebuild:
> > > > > digikam
> > > > > fawkes
> > > > > kf5-libkface
> > > > > nomacs
> > > > > player
> > > > > simon
> > > > > 
> > > > > Provenpackager request for: 
> > > > > Do fedpkg build in fawkes master [3] 
> > > > > [3]
> > > > > https://src.fedoraproject.org/rpms/fawkes/commits/master
> > > > > 
> > > > 
> > > > 
> > > > That won't help because fawkes ist still FTBFS after the last
> > > > protobuf
> > > > bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093
> > > 
> > > I need more one help from provenpackager merge and build player [1]
> > > from what I see to build fawkes, you just need rebuild player. I
> > > had
> > > confused the deps around package player but all builds correctly on
> > > copr [2] 
> > > 
> > > [1] 
> > > https://src.fedoraproject.org/rpms/player/pull-request/1
> > 
> > I merged the PR and tried a build, but it fails:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=24122011
> > 
> > In file included from /builddir/build/BUILD/player-release-3-1-
> > 0/replace/xdr.c:50:0:
> > /builddir/build/BUILD/player-release-3-1-0/replace/rpc/types.h:91:30: 
> > error: conflicting types for 'int64_t'
> >  typedef signed long long int int64_t;
> >   ^~~
> > In file included from /usr/include/sys/types.h:156:0,
> >  from /usr/include/stdlib.h:394,
> >  from /builddir/build/BUILD/player-release-3-1-
> > 0/replace/rpc/types.h:61,
> >  from /builddir/build/BUILD/player-release-3-1-
> > 0/replace/xdr.c:50:
> > /usr/include/bits/stdint-intn.h:27:19: note: previous declaration of
> > 'int64_t' was here
> >  typedef __int64_t int64_t;
> >^~~
> > {standard input}: Assembler messages:
> > {standard input}: Error: .size expression for xdr.c does not evaluate
> > to a constant
> > make[2]: Leaving directory '/builddir/build/BUILD/player-release-3-1-
> > 0/build'
> 
> Seems to be a issue with newest glibc 2.26.9000 , I opened a report [1]
> 
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=1533278
> 
> 
> Anyway please, you may try to build others PR 
> https://src.fedoraproject.org/rpms/nomacs/pull-request/1
> https://src.fedoraproject.org/rpms/simon/pull-request/1
Building now.

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

Re: F28 System Wide Change: IBus Unicode Typing

2018-01-10 Thread Christopher

On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik  wrote:

> = System Wide Change: IBus Unicode Typing =
> https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing
>
> Change owner(s):
> * Takao Fujiwara 
>
> IBus core provides an Emoji dialog which users can type emoji
> annotations and output the emoji character using IBus (E.g. Typing
> "football" shows U+26BD). The proposal is the dialog also supports to
> type Unicode names (E.g. Typing "copyright sign" shows U+00A9).
>
>
> == Detailed Description ==
> IBus core provides an Emoji dialog and it can be launched with
> Ctrl-Shift-e shortcut key in non-GNOME desktop and `ibus emoji`
> command is available for GNOME desktop [1]. Users can select an emoji
> in emoji lists on the emoji dialog or type an emoji annotation in an
> input entry on the emoji dialog and output the selected emoji using
> IBus.
>
> The proposal is that emoji dialog also supports to type Unicode names
> in the input entry and output the selected Unicode character.
>
> E.g. Typing "copyright sign" shows U+00A9
>
> [1] because gnome-shell has its owned keyboard indicator instead of
> /usr/libexec/ibus-ui-gtk3 and GTK itself also has the similar emoji
> dialog and the emoji implementation is under the consideration in
> GNOME.
>
>
>
> == Scope ==
> * Proposal owners:
> IBus core will include the dictionary of Unicode names
>
> * Other developers:
> N/A
>
> * Release engineering:
> https://pagure.io/releng/issue/7255
>
> * List of deliverables:
> N/A
>
> * Policies and guidelines:
> N/A
>
> * 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
>

With regards to [1], that was a very unfortunate regression[2] of a widely
advertised[3] feature of F25 that was immediately broken in F26. :(
I don't really see the value of unicode entry when I can't easily type
unicode characters on a standard US keyboard. I'm sure it will be useful to
some, but restoring GNOME functionality for ibus-typing-booster would be a
much more useful feature, so that unicode characters (including emojis) can
be searched for using a standard US keyboard layout in a convenient
interface.

[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1430501
[3]: https://fedoramagazine.org/using-favorite-emoji-fedora-25/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: purge sasl maps before gssapi test

2018-01-10 Thread William Brown

https://pagure.io/389-ds-base/issue/49474

https://pagure.io/389-ds-base/issue/raw/files/e6743de00abbe45f0d776fd62
6db5544b8154575ddd506d183f7e215ea09e6bc-0001-Ticket-49474-purge-
saslmaps-before-gssapi-test.patch


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

January 2018 Elections: Interview period is open

2018-01-10 Thread Jan Kurik

Today we are starting the Interview period during which we will
prepare interviews with candidates to the following teams:

* FESCo (Engineering) [1]
* Fedora Council [2]
* Mindshare [3]

This period is open until 2018-Jan-15 at 23:59:59 UTC.

The questions for candidates can be found in the template files [4],
however this election features a new way to submit questionnaires.

Nominees submit their questionnaire answers via a private Pagure issue
[5]. The Election Wrangler or their backup will publish the interviews
to the Community Blog [6] on the first day of the Voting period
(2018-Jan-17).

Please note that the interview is mandatory for all nominees.
Nominees not having their interview ready by end of the Interview
period (2018-Jan-15) will be disqualified and removed from the
election. Nominees may submit their interview answers immediately and
may edit them until the end of the interview period.

The full schedule of the January 2018 Elections is available on the
Elections wiki page [7].

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations
[4] 
https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-January
[5] https://pagure.io/fedora-project-schedule/issues
[6] http://communityblog.fedoraproject.org/
[7] https://fedoraproject.org/wiki/Elections

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

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

2018-01-10 Thread John Florian

On 01/03/2018 06:02 PM, Adam Williamson wrote:

> * The most useful feedback is just whether the kernel boots and works
> correctly on all systems you have access to (assuming they worked OK
> with the previous kernel, of course). If it does, please leave positive
> karma on the relevant update.

I know this update is already out of testing but I wanted to share my
feedback nonetheless as I ran into some regressions.  My x86_64 box
looked to be hanging during boot.  My first thought was, yeah got to run
`akmods --force && reboot` as I always seem to have to for the stupid
nvidia drivers.  (I'd much prefer nouveau but have had no end of
stability problems.)  However, I couldn't get my usual console on tty2
... or anywhere.  Tried rebooting in single user mode and got the same
result.  Today I tried adding `nopti` ... no discernible difference.
Finally, I just let it hang, went to another box and found I could ssh
in.  Wasn't hung at all, but it was the usual nvidia driver problem.

So, the big Qs are:

Why couldn't I get a login on tty2?
Why didn't single-user work?

Oddly, both work now that the kmod has been rebuilt.

Other details:
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
Gigabyte Z97X-UD3H-BK-CF
kernel-4.14.11-300.fc27.x86_64

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

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

2018-01-10 Thread Sérgio Basto

On Wed, 2018-01-10 at 22:27 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jan 09, 2018 at 08:27:51PM +, Sérgio Basto wrote:
> > On Tue, 2018-01-09 at 18:28 +0100, Till Hofmann wrote:
> > > 
> > > On 01/09/2018 05:53 PM, Sérgio Basto wrote:
> > > > Packages remaining to rebuild:
> > > > digikam
> > > > fawkes
> > > > kf5-libkface
> > > > nomacs
> > > > player
> > > > simon
> > > > 
> > > > Provenpackager request for: 
> > > > Do fedpkg build in fawkes master [3] 
> > > > [3]
> > > > https://src.fedoraproject.org/rpms/fawkes/commits/master
> > > > 
> > > 
> > > 
> > > That won't help because fawkes ist still FTBFS after the last
> > > protobuf
> > > bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093
> > 
> > I need more one help from provenpackager merge and build player [1]
> > from what I see to build fawkes, you just need rebuild player. I
> > had
> > confused the deps around package player but all builds correctly on
> > copr [2] 
> > 
> > [1] 
> > https://src.fedoraproject.org/rpms/player/pull-request/1
> 
> I merged the PR and tried a build, but it fails:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24122011
> 
> In file included from /builddir/build/BUILD/player-release-3-1-
> 0/replace/xdr.c:50:0:
> /builddir/build/BUILD/player-release-3-1-0/replace/rpc/types.h:91:30: 
> error: conflicting types for 'int64_t'
>  typedef signed long long int int64_t;
>   ^~~
> In file included from /usr/include/sys/types.h:156:0,
>  from /usr/include/stdlib.h:394,
>  from /builddir/build/BUILD/player-release-3-1-
> 0/replace/rpc/types.h:61,
>  from /builddir/build/BUILD/player-release-3-1-
> 0/replace/xdr.c:50:
> /usr/include/bits/stdint-intn.h:27:19: note: previous declaration of
> 'int64_t' was here
>  typedef __int64_t int64_t;
>^~~
> {standard input}: Assembler messages:
> {standard input}: Error: .size expression for xdr.c does not evaluate
> to a constant
> make[2]: Leaving directory '/builddir/build/BUILD/player-release-3-1-
> 0/build'

Seems to be a issue with newest glibc 2.26.9000 , I opened a report [1]

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1533278


Anyway please, you may try to build others PR 
https://src.fedoraproject.org/rpms/nomacs/pull-request/1
https://src.fedoraproject.org/rpms/simon/pull-request/1

Thanks



> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1522691] Upgrade perl-DBD-Firebird to 1.31

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBD-Firebird-1.31-1.fc |perl-DBD-Firebird-1.31-1.fc
   |26  |26
   ||perl-DBD-Firebird-1.31-1.fc
   ||27



--- Comment #9 from Fedora Update System  ---
perl-DBD-Firebird-1.31-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

On Tue, Jan 09, 2018 at 08:27:51PM +, Sérgio Basto wrote:
> On Tue, 2018-01-09 at 18:28 +0100, Till Hofmann wrote:
> > 
> > On 01/09/2018 05:53 PM, Sérgio Basto wrote:
> > > Packages remaining to rebuild:
> > > digikam
> > > fawkes
> > > kf5-libkface
> > > nomacs
> > > player
> > > simon
> > > 
> > > Provenpackager request for: 
> > > Do fedpkg build in fawkes master [3] 
> > > [3]
> > > https://src.fedoraproject.org/rpms/fawkes/commits/master
> > > 
> > 
> > 
> > That won't help because fawkes ist still FTBFS after the last
> > protobuf
> > bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093
> 
> I need more one help from provenpackager merge and build player [1]
> from what I see to build fawkes, you just need rebuild player. I had
> confused the deps around package player but all builds correctly on
> copr [2] 
> 
> [1] 
> https://src.fedoraproject.org/rpms/player/pull-request/1

I merged the PR and tried a build, but it fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24122011

In file included from 
/builddir/build/BUILD/player-release-3-1-0/replace/xdr.c:50:0:
/builddir/build/BUILD/player-release-3-1-0/replace/rpc/types.h:91:30: error: 
conflicting types for 'int64_t'
 typedef signed long long int int64_t;
  ^~~
In file included from /usr/include/sys/types.h:156:0,
 from /usr/include/stdlib.h:394,
 from 
/builddir/build/BUILD/player-release-3-1-0/replace/rpc/types.h:61,
 from 
/builddir/build/BUILD/player-release-3-1-0/replace/xdr.c:50:
/usr/include/bits/stdint-intn.h:27:19: note: previous declaration of 'int64_t' 
was here
 typedef __int64_t int64_t;
   ^~~
{standard input}: Assembler messages:
{standard input}: Error: .size expression for xdr.c does not evaluate to a 
constant
make[2]: Leaving directory '/builddir/build/BUILD/player-release-3-1-0/build'

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

[Bug 1522691] Upgrade perl-DBD-Firebird to 1.31

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-DBD-Firebird-1.31-1.fc
   ||26
 Resolution|--- |ERRATA
Last Closed||2018-01-10 17:23:26



--- Comment #8 from Fedora Update System  ---
perl-DBD-Firebird-1.31-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Re: Do aci's work in nested groups?

2018-01-10 Thread William Brown

On Wed, 2018-01-10 at 10:44 +0100, Ludwig Krispenz wrote:
> On 01/10/2018 07:03 AM, William Brown wrote:
> > If I have:
> > 
> > (targetattr=x)(version 3.0;  allow(read,
> > search)(groupdn=cn=x);)
> > 
> > If cn=x has member cn=y, and cn=y member uid=z
> > 
> > Does uid=z have permission to the targetattr here? IE do our aci's
> > work
> > through nested groups?
> 
> yes, they should, but there is configurable max nesting level

Great! Thanks for clarifying this :) 

Perhaps something we could look at is aci's resolving membership of an
entry via it's memberOf attributes if memberOf is enabled? That would
allow quicker resolution of nested groups I would think  

> > 
> > 
> 
> -- 
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael
> O'Neill, Eric Shander
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.o
> rg
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Improve the demo objects from install

2018-01-10 Thread William Brown

On Wed, 2018-01-10 at 12:17 -0500, Máirín Duffy wrote:
> 
> On 01/10/2018 10:58 AM, Mark Reynolds wrote:
> > So you could do a filter like this for your example above:
> > 
> > "(|(sn=*brown")(sn=*brown west"))"
> 
> So the case I'm thinking of for the front end is a directory listing,
> in 
> which case you wouldn't be so specific to know to add the West.
> > 
> > or
> > 
> > "(|(sn=* brown")(sn=* brown *"))"  --> note the spaces
> 
> This would grab anything inbetween though right? So it would grab
> Brown 
> as a middle name too. There's no way to specify order positioning
> beyond 
> first * / * last / * anything in middle * ? Eg no regexp?
> 
> The context I'm in here is a front end developer trying to get the
> data 
> in a format so they can provide a list of users in a list interface
> and 
> have a reasonable way to sort without having to rely on just using
> the 
> first substring.

So these are all great points Mairin, but they still exclude:

Singlename
Lastname1 lastname2

Imagine if you last names were say  alice bob. But you wanted to be
found under "alice bob". Today, you would not, you would be found under
"bob". Not what we want at all! And our singlename friend would not
even be allowed to exist at all (do you make their givenname the
surname? That's not right either ...). This is just disrespectful to
both of these individuals :( 

Your "frontend" with it's "western" style of "lastname, othernames" can
not accommodate these people :( 

We have the ability to order by displayName, and the ability to search
on any substring of the name so you can find your identity efficiently.

As a result, sort by displayname and searching is really the best way
to get access to this, even if not perfect, because we allow people to
express their name and identity in a way that is meaningful to them :) 

People will quickly see that it's ordered by "displayname" and they'll
search anyway (if that wasn't their default reaction, most people's
last name are not "aa" ... ). 

Too many "brown"s? Just search "william brown". Or even just " brown"?
uid can be searched too, so if I know there are 300 "william browns", I
can always look for "wibrown" or "firstyear". There are so many options
here :) 

And that's also kind of the point of this change, to highlight how we
think about names in such a limited manner, how we are constraining
ourselves to this single (often American) centric world view. For years
in open source we have had "handles" instead (for example, firstyear
for me). We have no issue just "sorting by handle" and "letting people
choose their handle" etc. We have all this software that works "just
fine" in this environment, so I think people will cope if we just sort
by "displayName" :) 

> 
> ~m
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.o
> rg
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Changelog between OS states (ie: VMs)

2018-01-10 Thread Martin Langhoff

On Tue, Jan 9, 2018 at 12:43 PM, Adam Williamson
 wrote:
> https://pagure.io/compose-utils
>
> that may be of interest to the original poster.

Bingo. https://pagure.io/compose-utils/blob/master/f/compose_utils/changelog.py

thank you!



martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

subscription-manager & related packages naming

2018-01-10 Thread Kevin Howell


Hi,

I am working on a PR to get subscription-manager and related packages 
packaged for python 3 for Fedora (see 
https://github.com/candlepin/subscription-manager/pull/1744), and we're 
aware we've made some naming decisions in the past that aren't quite up 
to the python package naming conventions. Anyways, I was wondering if 
anyone would be available to take a quick look at the spec file in the 
PR and provide feedback (we do our packaging work in the upstream repo, 
otherwise I'd just open a normal review request)...


Some context:

Our overall application has several python modules: rct, rhsm, 
rhsm_debug, rhsmlib, subscription_manager, and right now it's packaged 
as such:


 * package subscription-manager contains all the bin scripts, some
   config files, and all python modules except rhsm
 * package python3-subscription-manager-rhsm or
   subscription-manager-rhsm (depending on whether using python2 or
   python3) contains the rhsm python module (also used by virt-who)
 * package subscription-manager gui lays down the
   subscription_manager:gui module by itself (and there are a couple
   other packages that do similarly)...

Right now, I'm thinking what must be done is: rename 
subscription-manager-rhsm to python-rhsm or python2-rhsm or python3-rhsm 
per the python naming guidelines.


Some specific questions I have are:

 - Anything else that must/should be done to follow the guidelines?

 - Since subscription-manager is an application, and the python modules 
it uses are not  intended for consumption by users, does the 
subscription-manager package itself not fall under the general python 
package naming guidelines?


 - Any good examples of multi-module python applications that are 
packaged 100% (or 99%) correctly?


Thanks in advance for any advice,

Kevin Howell

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

Re: Security updates and batched pushes

2018-01-10 Thread Samuel Sieb


On 01/09/2018 02:09 PM, Tim Landscheidt wrote:

BTW, are there technical reasons why the metadata is updated
en bloc and not incrementally like for example delta RPMs,
or is it just that nobody bothered to implement something
like that yet for metadata?


This has been discussed for a very long time:
https://bugzilla.redhat.com/show_bug.cgi?id=850896
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

2018-01-10 Thread Andrew Lutomirski

On Wed, Jan 10, 2018 at 12:01 PM, Stephen John Smoogen  wrote:
>
> On 10 January 2018 at 14:46, Andrew Lutomirski  wrote:
> >
> >
> > On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen 
> > wrote:
> >>
> >> On 10 January 2018 at 14:23, Andrew Lutomirski  wrote:
> >> >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi  wrote:
> >> >>
> >> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
> >> >>> Kevin Fenzi wrote:
> >>  Well, if this firefox update was urgent, shouldn't it have been
> >>  marked
> >>  urgent?
> >> >>>
> >> >>> Urgency is always in the eye of the beholder. I as a user consider all
> >> >>> security updates "urgent", and in addition, I want ALL updates as soon
> >> >>> as
> >> >>> they passed testing no matter whether they actually are urgent.
> >> >>
> >> >> You also don't want updates-testing to even exist right?
> >> >>
> >> >>>
> >> > I really don't understand why we do this "batched" thing to begin
> >> > with.
> >> 
> >>  To reduce the constant flow of updates that are very minor or affect
> >>  very few mixed in with the major updates that affect lots of people
> >>  and
> >>  are urgent.
> >> >>>
> >> >>> But the users were already able to opt to update only weekly. So why
> >> >>> force a
> >> >>> fixed schedule on them?
> >> >>
> >> >> To save all the Fedora users in the world from having to update
> >> >> metadata
> >> >> for minor changes. Since there's a hourly dnf makecache every user in
> >> >> the world pulls down new metadata ever time we update a repo.
> >> >
> >> > Could Fedora, perhaps, come up with a way to make incremental metadata
> >> > updates fast?  This shouldn't be particularly hard -- a tool like
> >> > casync or even svn should work pretty well.  Or it could be a simple
> >>
> >> This sounds a lot like the Atomic project and how it does things...
> >>
> >
> > Maybe some of Atomic's infrastructure could be used to distribute metadata
> > for regular old Fedora.
> >
>
> OK clearly I should not try to help with a single sentence email as it
> didn't help anyone. I should have asked more questions on what you
> meant by metadata and what you meant by distribution and how svn would
> have been used instead.


SVN is probably a poor model, but imagine that the various metadata
files (repodata, I think) were check in, uncompressed, to an SVN repo.
Then the client could do 'svn up' and take advantage of delta
compression.  I suspect the server load would be too high, though.

Basically, what I'm getting at is that Fedora seems to distribute
comps, prestodelta, primary, filelists, and updateinfo, and they add
up to 20MB compressed for the updates repo.  AFAICT it gets
re-downlaoded from scratch every time, even though the actual list of
changes is probably minimal from day to day.

>
> I should have also asked if you knew enough
> about how atomic did things to give an informed opinion on how that
> was similar to the request. Without that we ended up talking past each
> other.
>

I don't know too much about the details.  I suspect that, if the
.xml.gz files were, instead, one file per package, then they could be
served up from an ostree repo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS

2018-01-10 Thread Dario Lesca

Il giorno mer, 10/01/2018 alle 17.18 +0100, Robert-André Mauchin ha
scritto:
> Maybe you could suggest the package maintainer to add a "Provides:
> stubby" so it can be found directly. CCing Paul Wouters in that
> regard.

[lesca@dodo ~]$ dnf whatprovides stubby -C
Last metadata expiration check: 0:29:45 ago on Wed Jan 10 20:39:15 2018.
getdns-devel-1.2.1-1.fc27.i686 : Development package that includes the 
header files
Repo: updates
Matched from:
Filename: /usr/bin/stubby

Stubby Is in getdns-devel.

I have discovered strubby only now. Thanks.

I have some question:

Why all dns server are not TLS-SSL ready?

There is some simple howto to learn how to use it on workstation ?

and how to integrates with bind / named dns server?

Whit which public dns server can be use? is the 9.9.9.9 the only?

https://medium.com/nlnetlabs/privacy-using-dns-over-tls-with-the-new-quad9-dns-service-1ff2d2b687c5

Many thanks for clarification
 
-- 
Dario Lesca
(inviato dal mio Linux Fedora 27 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

On 10 January 2018 at 14:46, Andrew Lutomirski  wrote:
>
>
> On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen 
> wrote:
>>
>> On 10 January 2018 at 14:23, Andrew Lutomirski  wrote:
>> >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi  wrote:
>> >>
>> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
>> >>> Kevin Fenzi wrote:
>>  Well, if this firefox update was urgent, shouldn't it have been
>>  marked
>>  urgent?
>> >>>
>> >>> Urgency is always in the eye of the beholder. I as a user consider all
>> >>> security updates "urgent", and in addition, I want ALL updates as soon
>> >>> as
>> >>> they passed testing no matter whether they actually are urgent.
>> >>
>> >> You also don't want updates-testing to even exist right?
>> >>
>> >>>
>> > I really don't understand why we do this "batched" thing to begin
>> > with.
>> 
>>  To reduce the constant flow of updates that are very minor or affect
>>  very few mixed in with the major updates that affect lots of people
>>  and
>>  are urgent.
>> >>>
>> >>> But the users were already able to opt to update only weekly. So why
>> >>> force a
>> >>> fixed schedule on them?
>> >>
>> >> To save all the Fedora users in the world from having to update
>> >> metadata
>> >> for minor changes. Since there's a hourly dnf makecache every user in
>> >> the world pulls down new metadata ever time we update a repo.
>> >
>> > Could Fedora, perhaps, come up with a way to make incremental metadata
>> > updates fast?  This shouldn't be particularly hard -- a tool like
>> > casync or even svn should work pretty well.  Or it could be a simple
>>
>> This sounds a lot like the Atomic project and how it does things...
>>
>
> Maybe some of Atomic's infrastructure could be used to distribute metadata
> for regular old Fedora.
>

OK clearly I should not try to help with a single sentence email as it
didn't help anyone. I should have asked more questions on what you
meant by metadata and what you meant by distribution and how svn would
have been used instead. I should have also asked if you knew enough
about how atomic did things to give an informed opinion on how that
was similar to the request. Without that we ended up talking past each
other.




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

Re: Security updates and batched pushes

2018-01-10 Thread Andrew Lutomirski

On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen 
wrote:

> On 10 January 2018 at 14:23, Andrew Lutomirski  wrote:
> >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi  wrote:
> >>
> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
> >>> Kevin Fenzi wrote:
>  Well, if this firefox update was urgent, shouldn't it have been marked
>  urgent?
> >>>
> >>> Urgency is always in the eye of the beholder. I as a user consider all
> >>> security updates "urgent", and in addition, I want ALL updates as soon
> as
> >>> they passed testing no matter whether they actually are urgent.
> >>
> >> You also don't want updates-testing to even exist right?
> >>
> >>>
> > I really don't understand why we do this "batched" thing to begin
> with.
> 
>  To reduce the constant flow of updates that are very minor or affect
>  very few mixed in with the major updates that affect lots of people
> and
>  are urgent.
> >>>
> >>> But the users were already able to opt to update only weekly. So why
> force a
> >>> fixed schedule on them?
> >>
> >> To save all the Fedora users in the world from having to update metadata
> >> for minor changes. Since there's a hourly dnf makecache every user in
> >> the world pulls down new metadata ever time we update a repo.
> >
> > Could Fedora, perhaps, come up with a way to make incremental metadata
> > updates fast?  This shouldn't be particularly hard -- a tool like
> > casync or even svn should work pretty well.  Or it could be a simple
>
> This sounds a lot like the Atomic project and how it does things...
>
>
Maybe some of Atomic's infrastructure could be used to distribute metadata
for regular old Fedora.

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

Re: scotch: packaging a version with 64bit integers

2018-01-10 Thread Dridi Boukelmoune

Sorry for the top post, on my phone...

Telling third party software to link against a different soname suffixed
with 64 would be pkg-config's job, usually.

Dridi

On Jan 10, 2018 14:59, "Sandro Mani"  wrote:

Hi

I've received a request to package a version of scotch with 64bit integers
(as opposed to 32bit). I suppose the details are less important, the bottom
line is

scotch 32bit: typedef int32_t SCOTCH_Num;

scotch 64bit: typedef int64_t SCOTCH_Num;

where SCOTCH_Num affects the public ABI and is used by third parties which
use scotch.


Upstream allows selecting the integer size at compile-time (i.e. passing
-DINTSIZE64 for int64_t). However, this choice has no effect on the library
name, so vanilla upstream will build a library named libscotch.so
regardless of how you configure it.


I'm skeptical whether introducing a downstream scotch64 package with i.e.
libscotch64.so is a good solution, given that possibly no build system of
third-party software using scotch knows about libscotch64.so and would need
to be carefully patched (i.e. to not mix parts using libscotch and those
using libscotch64). Also, introducing downstream specific suffixes is never
a good idea.

The alternative would be to just switch the main scotch package to 64bit
integers, but this may be undesirable for memory-bound applications which
rely on the smaller memory-usage of 32bit integers.


I'm not really sure whether there is a good solution, happy to hear
opinions.


Thanks

Sandro

___
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: Security updates and batched pushes

On 10 January 2018 at 14:23, Andrew Lutomirski  wrote:
>> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi  wrote:
>>
>>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
>>> Kevin Fenzi wrote:
 Well, if this firefox update was urgent, shouldn't it have been marked
 urgent?
>>>
>>> Urgency is always in the eye of the beholder. I as a user consider all
>>> security updates "urgent", and in addition, I want ALL updates as soon as
>>> they passed testing no matter whether they actually are urgent.
>>
>> You also don't want updates-testing to even exist right?
>>
>>>
> I really don't understand why we do this "batched" thing to begin with.

 To reduce the constant flow of updates that are very minor or affect
 very few mixed in with the major updates that affect lots of people and
 are urgent.
>>>
>>> But the users were already able to opt to update only weekly. So why force a
>>> fixed schedule on them?
>>
>> To save all the Fedora users in the world from having to update metadata
>> for minor changes. Since there's a hourly dnf makecache every user in
>> the world pulls down new metadata ever time we update a repo.
>
> Could Fedora, perhaps, come up with a way to make incremental metadata
> updates fast?  This shouldn't be particularly hard -- a tool like
> casync or even svn should work pretty well.  Or it could be a simple

This sounds a lot like the Atomic project and how it does things...


> ad-hoc thing.  Have the mirrors serve up both the whole metadata blob
> and a list of metadata changes.  The client could grab the list of
> changes from last time, compute a bitwise-identical blob, and verify
> the signature on that, deltarpm style.  (But on the decompressed data,
> of course -- no need to repeat the mistakes of the past.)
>
> It seems that all this batched stuff is a rather weak hack to work
> around the extreme inefficiency of Fedora's metadata distribution
> model.

All things are a weak hack to work around some inefficiency and an
extremely important process to deal with needs. Trying to label
something without taking into consideration of the other is where most
arguments go pear shaped.

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



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

Re: Security updates and batched pushes

2018-01-10 Thread Andrew Lutomirski

> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi  wrote:
>
>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
>> Kevin Fenzi wrote:
>>> Well, if this firefox update was urgent, shouldn't it have been marked
>>> urgent?
>>
>> Urgency is always in the eye of the beholder. I as a user consider all
>> security updates "urgent", and in addition, I want ALL updates as soon as
>> they passed testing no matter whether they actually are urgent.
>
> You also don't want updates-testing to even exist right?
>
>>
 I really don't understand why we do this "batched" thing to begin with.
>>>
>>> To reduce the constant flow of updates that are very minor or affect
>>> very few mixed in with the major updates that affect lots of people and
>>> are urgent.
>>
>> But the users were already able to opt to update only weekly. So why force a
>> fixed schedule on them?
>
> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo.

Could Fedora, perhaps, come up with a way to make incremental metadata
updates fast?  This shouldn't be particularly hard -- a tool like
casync or even svn should work pretty well.  Or it could be a simple
ad-hoc thing.  Have the mirrors serve up both the whole metadata blob
and a list of metadata changes.  The client could grab the list of
changes from last time, compute a bitwise-identical blob, and verify
the signature on that, deltarpm style.  (But on the decompressed data,
of course -- no need to repeat the mistakes of the past.)

It seems that all this batched stuff is a rather weak hack to work
around the extreme inefficiency of Fedora's metadata distribution
model.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread Adam Williamson

On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
> On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
> > Initial NOTE: I have made some bigger changes in Ghostscript package during
> > the cleanup, which should be self-contained. In my opinion those changes
> > are not so significant to create "self-contained change" wiki page for it
> > (for F28), but if the consensus of people here will be the opposite, then I
> > will create it additionally...
> 
> As far as I understand, this is going to affect how other packages are built, 
> installed, and run.  It should be reviewed by the affected parties to decide 
> whether it is a self-contained or system-wide change and the respective 
> process should be followed.
> 
> > The new Ghostscript should be available for trying/testing in Rawhide in a
> > few hours. I will follow up with additional information (e.g. tracking BZ
> > link) here in this thread.
> 
> It would be better to create a Copr for testing purposes to avoid disruption 
> of Fedora development.

+1 (or a tag). Lots of stuff hangs off of ghostscript. It'd be nice to
have the implications of this at least broadly figured out in advance
rather than "doing it live" in Rawhide.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

2018-01-10 Thread Kevin Kofler

Yaakov Selkowitz wrote:
> https://github.com/cygwinports/kde-runtime/blob/master/15.04.3-libtirpc.patch

FYI, this patch does not work:
-- Looking for include file rpc/rpc.h
-- Looking for include file rpc/rpc.h - not found
…
-- The following features have been disabled:
 * NFS kioslave, The RPC library is needed to build the NFS kioslave

I replaced it with:
https://src.fedoraproject.org/cgit/rpms/kde-runtime.git/tree/kde-runtime-17.08.3-nfs-libtirpc.patch
which is a backport of:
> https://github.com/cygwinports/kf5-kio-extras/blob/master/16.08.3-nfs-libtirpc.patch
and which works.

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

[389-devel] Re: Improve the demo objects from install



On 01/10/2018 12:17 PM, Máirín Duffy wrote:
>
>
> On 01/10/2018 10:58 AM, Mark Reynolds wrote:
>> So you could do a filter like this for your example above:
>>
>> "(|(sn=*brown")(sn=*brown west"))"
>
> So the case I'm thinking of for the front end is a directory listing,
> in which case you wouldn't be so specific to know to add the West.
>>
>> or
>>
>> "(|(sn=* brown")(sn=* brown *"))"  --> note the spaces
>
> This would grab anything inbetween though right? So it would grab
> Brown as a middle name too. 
Correct.
> There's no way to specify order positioning beyond first * / * last /
> * anything in middle * ? Eg no regexp?
No, sorry. 
>
> The context I'm in here is a front end developer trying to get the
> data in a format so they can provide a list of users in a list
> interface and have a reasonable way to sort without having to rely on
> just using the first substring.
>
> ~m
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Improve the demo objects from install

2018-01-10 Thread Máirín Duffy




On 01/10/2018 10:58 AM, Mark Reynolds wrote:

So you could do a filter like this for your example above:

"(|(sn=*brown")(sn=*brown west"))"


So the case I'm thinking of for the front end is a directory listing, in 
which case you wouldn't be so specific to know to add the West.


or

"(|(sn=* brown")(sn=* brown *"))"  --> note the spaces


This would grab anything inbetween though right? So it would grab Brown 
as a middle name too. There's no way to specify order positioning beyond 
first * / * last / * anything in middle * ? Eg no regexp?


The context I'm in here is a front end developer trying to get the data 
in a format so they can provide a list of users in a list interface and 
have a reasonable way to sort without having to rely on just using the 
first substring.


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

Re: Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS

2018-01-10 Thread Stephen Gallagher

>
>
> > Maybe you could suggest the package maintainer to add a "Provides:
> stubby" so
> > it can be found directly. CCing Paul Wouters in that regard.
>
> That's a good idea! I'll fire of some new builds with that later today
> when I fixup
> the libidn2 handling as well.
>
>

If people are going to search for this directly, it might be useful to add
this to the package description as well (or create a metapackage for stubby
that pulls in the getdns package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS

2018-01-10 Thread Paul Wouters

On 01/10/2018 11:18 AM, Robert-André Mauchin wrote:
> On mercredi 10 janvier 2018 00:07:11 CET  rugk wrote:
>> Providing privacy and security for DNS! (especially after dnscrypt is
>> discontinued now).
>> It would be nice to have this in Fedora.
>>
>> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
>> GitHub: https://github.com/getdnsapi/stubby
>> For distro status see: https://repology.org/metapackage/stubby/versions
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Although upstream has splitted Stubby in a separate repo in August 2017, they 
> still distribute it along Getdns source. Thus in Fedora, the latest Stubby is 
> currently installed with the latest release of Getdns. See https://
> src.fedoraproject.org/rpms/getdns/blob/master/f/getdns.spec
> 
> Maybe you could suggest the package maintainer to add a "Provides: stubby" so 
> it can be found directly. CCing Paul Wouters in that regard.

That's a good idea! I'll fire of some new builds with that later today when I 
fixup
the libidn2 handling as well.

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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

2018-01-10 Thread Jason L Tibbitts III

> "MH" == Miro Hrončok  writes:

MH> This sounds good to me. It didn't occur to me that we can actually
MH> set a dedicated env vars for our builds (which is even better).

Well, doing so requires that we change an rpm macro to export this new
env var in the same place that RPM_BUILD_ROOT is exported.  I believe
the thing we need to override is in the rpm package itself, not
redhat-rpm-config, so it does mean asking the maintainers of the rpm
package nicely to add that.  It's not technically difficult at all.

I could of course be wrong; it may be possible to do this entirely
within redhat-rpm-config, which is a bit easier to have changed.

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

2018-01-10 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1038  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 801  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 383  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 280  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 112  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d704442ae7   
qpid-cpp-1.37.0-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-753e392fc4   
xrdp-0.9.5-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2e2d08b1ff   
awstats-7.6-4.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-49ca8440a1   
gifsicle-1.90-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28611aa33f   
python-bottle-0.12.13-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-885bb5ec89   
poco-1.6.1-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

argbash-2.5.1-1.el7

Details about builds:



 argbash-2.5.1-1.el7 (FEDORA-EPEL-2018-d27cfe0cb3)
 Bash argument parsing code generator

Update Information:

Update to argbash 2.5.1  https://github.com/matejak/argbash/releases/tag/2.5.1

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

Re: Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS

2018-01-10 Thread Robert-André Mauchin

On mercredi 10 janvier 2018 00:07:11 CET  rugk wrote:
> Providing privacy and security for DNS! (especially after dnscrypt is
> discontinued now).
> It would be nice to have this in Fedora.
> 
> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
> GitHub: https://github.com/getdnsapi/stubby
> For distro status see: https://repology.org/metapackage/stubby/versions
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Although upstream has splitted Stubby in a separate repo in August 2017, they 
still distribute it along Getdns source. Thus in Fedora, the latest Stubby is 
currently installed with the latest release of Getdns. See https://
src.fedoraproject.org/rpms/getdns/blob/master/f/getdns.spec

Maybe you could suggest the package maintainer to add a "Provides: stubby" so 
it can be found directly. CCing Paul Wouters in that regard.

Best regards,

Robert-André

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

[Bug 1532539] [PATCH] Invalid definitions in macros.perl

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-5.26.1-402.fc27 has been pushed to the Fedora 27 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f8f01f1e83

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511243] perl-Mail-Message-3.005 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #10 from Fedora Update System  ---
perl-Mail-Message-3.005-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d4b2798525

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1532914] perl-Socket-2.025 is available

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



--- Comment #5 from Fedora Update System  ---
perl-Socket-2.025-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-36ebfbdf9d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

On 10 January 2018 at 08:50, Neal Gompa  wrote:
> On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik  wrote:

>> The new mapping for nobody:nobody would be implemented in two redundant ways:
>> * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
>> * dynamically provided by the nss-systemd module (by compiling systemd
>> with -Dnobody-user=nobody -Dnobody-group=nobody).
>>
>
> Two questions:
>
> 1. Why nobody:nobody instead of nobody:nogroup? I've seen the latter
> in use in several distributions.
> * For note, we use this in Mageia:
> http://gitweb.mageia.org/software/setup/tree/group
> * Debian and Ubuntu also define it this way.
>
> 2. For existing systems, would renaming the nobody:nobody user to
> oldnobody:oldnobody work instead? The uid would be preserved, which
> should keep the mapping sane, and it would make it more obvious that
> it's old, rather than using weird underscores.
>
> In general, I support this change because the two nobody users made
> things confusing for me and many other people. Simplifying this would
> also harmonize things with everyone else, which helps for portability
> of things. :)
>
>

I think all of the above would be good additions to this. Having dealt
with multiple large deployments where 99:99 caused different problems
but then were hard-coded into being fixed if something is Fedora/RHEL
based... a lot of people updating to F28+ would have problems... and a
lot of people update vs fresh install.

> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Security updates and batched pushes

2018-01-10 Thread Kevin Fenzi

On 01/10/2018 04:01 AM, Tomasz Torcz wrote:
> 
>   So, if there ARE updates to be pushed (marked urgent?) and we update 
> metadata
> ANYWAY, this is a good point to flush everything from batched in this push.

We could yeah. We could also only ever push when there are urgent updates...

kevin




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

Re: Security updates and batched pushes

2018-01-10 Thread Kevin Fenzi

On 01/09/2018 12:57 PM, Kevin Kofler wrote:
> Kevin Fenzi wrote:
>> You also don't want updates-testing to even exist right?
> 
> That is not true. I want to leave the decision whether and for how long an 
> update needs to be tested to the package maintainer instead of enforcing 
> minimum testing requirements in the software, because the software can never 
> understand the exact context. Removing updates-testing entirely is not what 
> I want! But this is unrelated to the current issue of artificially delaying 
> updates that satisfy all the criteria for being pushed to stable.

Agreed. Thanks for clarifying.

>> To save all the Fedora users in the world from having to update metadata
>> for minor changes. Since there's a hourly dnf makecache every user in
>> the world pulls down new metadata ever time we update a repo.
> 
> So to save people the download, you make a change that totally defeats the 
> point of dnf checking for updates every hour to begin with?

It doesn't do that though. dnf wants the latest metadata so it can let
users use that cache for things like searching for packages or listing
them or the like.
> 
>> If we update a repo for some minor enhancements it means everyone in the
>> world has to pay for that. If we just push all those out every tuesday and
>> don't update those unless there's something urgent we save everyone a
>> lot of bandwith and us computing time/resources.
> 
> This does not work in practice because there are always updates that are not 
> batched.

I... have seen updates pushes that do not take place when I have been
pushing updates, so I assert you are incorrect. True, it doesn't happen
as often as I was hoping, but it does and has happened.
> 
>> There are definitely more days when there are no updates for a
>> particular repo now. Of course there would be even more if you (or those
>> who do likewise) wouldn't skip batched, but probibly we need to explain
>> why more clearly.
> 
> Are there really? The last couple days, there were basically daily pushes 
> with around 2 updates each.

At least one of those cases was me pushing firefox, right after a
f27-updates push just finished, so yeah, it only had 2 updates in it.
> 
> The batching only makes the daily pushes smaller and not empty, which does 
> not help at all for reducing repodata download size, because there are still 
> no repodata deltas implemented.
> 
>> because it would be a ton more infrastructure and resources.
> 
> Really? Bodhi composes (or triggers the compose of, let's please not discuss 
> the technical details down to that level)
...snip...

but the technical details are what matters here. ;) Making another repo,
building drpms, and doing all the compose will take time, disk space and
cpu cycles and slow all other updates pushes down.

Anyhow, I don't want this to be a back and forth between just us, I'd
like to hear some other opinions and proposals and have FESCo decide on
some adjustment ehre.

I agree the current setup is not ideal and personally I'm open to
adjusting/changing it, but I don't know that I think we should just drop
batched entirely. We should come up with something that balances all the
various needs (you want updates as soon as they are tested, I want not
to update metadata on people all the time, etc).

kevin




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

Re: Security updates and batched pushes

2018-01-10 Thread Kevin Fenzi

On 01/09/2018 02:09 PM, Tim Landscheidt wrote:
> Kevin Fenzi  wrote:
> 
>> […]
> 
> I really don't understand why we do this "batched" thing to begin with.
> 
 To reduce the constant flow of updates that are very minor or affect
 very few mixed in with the major updates that affect lots of people and
 are urgent.
> 
>>> But the users were already able to opt to update only weekly. So why force a
>>> fixed schedule on them?
> 
>> To save all the Fedora users in the world from having to update metadata
>> for minor changes. Since there's a hourly dnf makecache every user in
>> the world pulls down new metadata ever time we update a repo. If we
>> update a repo for some minor enhancements it means everyone in the world
>> has to pay for that. If we just push all those out every tuesday and
>> don't update those unless there's something urgent we save everyone a
>> lot of bandwith and us computing time/resources.
> 
>> […]
> 
> BTW, are there technical reasons why the metadata is updated
> en bloc and not incrementally like for example delta RPMs,
> or is it just that nobody bothered to implement something
> like that yet for metadata?

There is no implementation that I know of. It's been talked about for
many years, but not been implemented.

kevin




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

[389-devel] Re: Improve the demo objects from install



On 01/10/2018 10:53 AM, Máirín Duffy wrote:
>
>
> On 01/10/2018 10:20 AM, Mark Reynolds wrote:
>>> Would this miss someone who had two surnames, say Sally Brown West,
>>> who chooses not to hyphenate?
>> "(sn=*brown*)"
>
> Wouldn't that also match Brownwyn James and Brown West Smith?
Yes it would, but there are endless options here.  I was just trying to
show some of the things you can do with substring filters.

So you could do a filter like this for your example above:

"(|(sn=*brown")(sn=*brown west"))"

or

"(|(sn=* brown")(sn=* brown *"))"  --> note the spaces

Mark

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

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread David Kaspar [Dee'Kej]

On Wed, Jan 10, 2018 at 3:44 PM, Neal Gompa  wrote:

> If the content of "ghostscript-core" is now part of "ghostscript", you
> can do the following:
>
> Obsoletes: ghostscript-core < 9.22-5
> Provides: ghostscript-core = %{version}-%{release}
>
> In addition, packages that currently require "ghostscript-core" can
> and should be fixed for Fedora 28. In my view, there's nothing that
> necessitates this metapackage for a development branch.
>
> If this was going into Fedora 27, for example, then sure, it makes sense.
>

Unfortunately in the current situation, it's not that simple... :-/ Let me
try to explain:

In the context of changes mentioned here (package layout change,
software/resources debundling) specifying Obsoletes/Provides as you
mentioned above for 'ghostscript' (or any other subpackage) wasn't enough.
As I said before, the 'ghostscript-core' contained almost everything from
Ghostscript's build, and 'ghostscript' was an empty metapackage, requiring
'ghostscript-core', 'ghostscript-x11'.

If I would specify the Obsoletes/Provides inside 'ghostscript' package as
you suggest, then the 'ghostscript' package would still miss some scripts
that are now in separate subpackages (*-tools-*). It could lead to people
complaining (in BZs, mailing list) about missing scripts after upgrade to
F28 (the scripts would have been uninstalled during upgrade in this way).
I'm trying to avoid any disturbance to our users that could generally lead
to negative feelings about our distribution.

In order to have the scripts kept during the upgrade, then I would have to
specify additional requirements in 'ghostscript' package for the
'ghostscript-tools-*' subpackages. However, this would create again the
problem I was trying to solve in the first place (to have more granular
package layout), and 'ghostscript' package itself would just become "new"
'ghostscript-core'. I.e., the contents would have been moved from
'ghostscript-core' into 'ghostscript', which is not exactly what I wanted.
:)

So right now, none of the (sub)package has Obsoletes/Provides/Requires for
'ghostscript-core'. Instead, I kept the 'ghostscript-core' with
requirements on 'libgs', 'ghostscript', 'ghostscript-tools-*'. This way the
'ghostscript-core' will not be installed automatically on fresh F28
installations, but for users upgrading from previous version to F28, it
will kept the Ghostscript scripts installed.

My plan is to remove the 'ghostscript-core' once F28 has reached EOL. I
realize now that this might influence the users doing the upgrade anyway
(the 'ghostscript-tools-*' might get uninstalled during upgrade and some of
them might be missing them). But before I need to deal with this, I want to
make sure other packages requiring Ghostscript are fixed first. To kind of
grind the huge change into a smaller chunks of changes, if possible. :)

I'm sorry if my explanation does not make sense. :-/ If that's the chase,
then it might be better to look in the specfile at the package layout (and
dependencies) before and after the change. (
https://src.fedoraproject.org/rpms/ghostscript)

> Okay, this makes sense. I'm a bit disappointed that we couldn't have
> the conf.d thing upstreamed, but we'll see how it goes...
>

Generally it's hard to get something upstreamed unless they have any
benefit from it. I had really hard times trying to convince them to create
a new Github repository for 'urw-base35-fonts' and accepting the AppStream
and fontconfig configuration files there.

For upstream accepting something might mean additional maintenance work,
and they are (understandably) trying to avoid it. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1532914] perl-Socket-2.025 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Socket-2.025-1.fc26 has been pushed to the Fedora 26 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2ae4888a92

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Re: Improve the demo objects from install

2018-01-10 Thread Máirín Duffy




On 01/10/2018 10:20 AM, Mark Reynolds wrote:

Would this miss someone who had two surnames, say Sally Brown West,
who chooses not to hyphenate?

"(sn=*brown*)"


Wouldn't that also match Brownwyn James and Brown West Smith?

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

[EPEL-devel] Re: How to retire/delete an EPEL branch?

On 10 January 2018 at 01:53, Ding Yi Chen  wrote:
> I received a bug[1] asking to remove EPEL7 branch, as the package
> LibRaw, is already in RHEL.
>
> How should I do that?
>
> Regards,
>

We do not remove branches as much as retire the package.

https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

GIT[edit]
Run fedpkg retire DESCRIPTION in all non-stable Fedora branches and
EPEL branches, if applicable. The retiring needs to start with the
oldest branch (e.g. retire on f25 before you retire on master)

Remarks[edit]
The DESCRIPTION parameter should explain why the package was retired,
good messages are:
Obsoleted by bar
Renamed to bar
The command will remove all files from the branch, add a file name
dead.package containing the description and push the changes. Starting
with fedpkg 1.13 it will also retire the package in package DB.
git rm all files in the other branches only if there are special
factors at work, like licensing issues, or package being removed
completely from Fedora.
If you retired master before other older branches you want to retire,
just continue with the older branches. It will still work, but will
block the package in more Koji tags, because tag inheritance will not
be used automatically then.
Ignore any errors related to Package DB. The package state is not
tracked in Package DB anymore and a future fedpkg update will remove
Package DB support from fedpkg.

EPEL[edit]
Note that you can use this process for EPEL as well with one difference:

You can remove the package from any EPEL branch whether or not it has
been released.
For example, if your package has been added to base RHEL in RHEL-6.4
then perform the steps above but use the el6 branch instead of master.

so basically...

fedpkg switch-branch epel-7
fedpkg pull
fedpkg retire

>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1526701
> --
> Ding-Yi CHEN
>
> Software Engineer, Globalization Group
> Red Hat Asia-Pacific Pty Ltd
> dc...@redhat.com
> Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

Re: Package Question

On Mon, Jan 8, 2018 at 12:21 PM, Steve Dickson  wrote:
> Hello,
>
> Is it a problem for a package to pull from two different
> upstream tar balls? Basically have
>
> Source0: http://server.com/package1/package1.tar
> Source1: http://server.com/package2/package2.tar
>
> Then I would, by hand, untar Source1 into Source0 directory.
>
> Before do the work I want to make sure I'm not
> breaking violating any package rules. I did look
> around and didn't see anything addressing this.
>

Personally, I'm not a fan of it. But it does happen quite a lot...

> If this is kosher, are there any examples of other
> packages doing this...
>

PackageKit did this for Fedora 25 to include libdnf for the
PackageKit-Dnf backend before libdnf was introduced into the
distribution in Fedora 26.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

2018-01-10 Thread Nico Kadel-Garcia

On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Wed, Jan 10, 2018 at 11:56:46AM +0100, Reindl Harald wrote:
>>
>> Am 10.01.2018 um 11:46 schrieb Jan Kurik:
>> >On existing systems, to make upgrades easier:
>> >* if nfsnobody was defined, keep it in /etc/passwd *after* the new
>> >line for nobody:nobody, so that both the old name and the new name map
>> >to the same numbers
>> >* if nobody user or group with number 99 was defined, keep it in
>> >/etc/passwd and /etc/group, but rename to _nobody
>> that don't make updates easier but breaks existing setups where
>> nobody:nobody with 99:99 already owns files - don't touch long years
>> running machines due dist-upgrades please - at least not with "dnf
>> --releasever=28 distro-sync"
>
> That'd amount to leaving existing systems unchanged. That's an option
> that I didn't like and initially rejected, but yeah, it's probably better.
> I'll wait a bit more for feedback and update the proposal a bit later
> to leave existing systems alone (i.e. systems which have either nobody
> or nfsnobody already defined in the old style).
>
> Zbyszek

This is particularly relevant for rsync or tar restorations from old
backups, and to NFS shares exposed across old and new environments.
It's why changing active uid and and gid for any account can be
perniciously awkward.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

2018-01-10 Thread Matthew Miller

On Wed, Jan 10, 2018 at 11:46:13AM +0100, Jan Kurik wrote:
> Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
> and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
> with 99:99 numbers

See previous thread on this proposal from two years ago:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5GCKZ7Q7PAUQW66EV7IBJGSRJWYXBBH/?sort=date

There's some good discussion there. I'm still in favor. 


-- 
Matthew Miller

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

[389-devel] Re: Improve the demo objects from install



On 01/09/2018 07:25 PM, William Brown wrote:
> Hi all,
>
> It's time that I'm looking at:
> https://pagure.io/389-ds-base/issue/49425
+1 for 1.4.0!
>
> There are some great reasons to freshen up the default objects we
> install. The current design isn't really reflective of modern directory
> usage, the aci's are not "great" examples, and it's not a super-useful
> foundation out of the box.
>
> As a result, I have some improvements I want to make here. Let's start
> with the simple ones:
>
> Tree layout:
>
> dc=example,dc=com
> cn=389_ds_system,dc=example,dc=com
> ou=people,dc=example,dc=com
> ou=groups,dc=example,dc=com
> ou=services,dc=example,dc=com
> ou=permissions,dc=example,dc=com
>
> This is the structure I want us to ship with: groups, people, service
> accounts, and permission groups. I additionally add an
> nscontainer|ldapsubentry 389_ds_system, which is the "hidden" config
> area that we could start to use for things like pwpolicy, keepalive
> entries, replication service accounts and more. I don't think anything
> here is too controversial :)
>
> Next, demo objects!
>
> uid=demo_user,ou=people,dc=example,dc=com
> cn=demo_group,ou=groups,dc=example,dc=com
>
> These can show a user and group, and lets the cli tools have something
> to show, and how they can be integrated with *acis*.
>
> Again, nothing complex :) 
>
> Permissions! This is where we start to add aci's and get's a bit fun.
>
> I want to ship with a few useful permisisons and acis. The thinking is:
>
> * anonymous read to public ou=People and user attributes (ie Sssd
> should work oob)
> * anonymous read to groups attributes (ie Sssd should work oob)
> * a permission group where members can alter group members
> * a permission group where members can alter users
> * a permission group where members can reset user passwords
> * a permission group where members can create/delete users
> * a permission group where members can create/delete groups
>
> This is a pretty simple set of acis, but I want them to show how
> delegation of permissions can be done safely, and act as examples and
> templates for admins - as well as just being simple and useful for
> small deployments out of the box!
>
>
> Now, this is the final suggestion: I'd like to add some extra schema
> and change user objects by default that we create. 
>
> I would like to add:
>
> nsPerson
>
> I would like them to contain the following:
>
> nsPerson:
> MAY: userPassword, telephoneNumber, seeAlso, description, legalName
> MUST: cn, displayName
>
>
> This is a shift from the traditional person object and there is a
> really good reason - 
> internationalisation. (we replace sn with legalName and make it may,
> and add
> displayName).
>
>
> The current person account *requires* the sn field. However surname
> *does not*
> translate across many cultural boundaries. Some people have multiple
> surnames, some
> have no concept of a surname.
>
> What people do have is a *legal name* which is their full name - for me
> that would be
> givennames + surname. For others just their single name. having a
> single legalName
> field correctly represents this case. And additionally many
> applications don't
> even need a legal name, *only* a displayName of the users choice.
>
> The second reason is identity related. There are many people whos
> chosen name
> for the world (displayName) differs from their actual legal name. As a
> result
> having a displayname field where the user can *choose* how they are
> represented
> is highly important. Consider divorced people (who haven't yet changed
> legal names)
> victims of crime (who need to hide their identity) and more.
>
> I think our current schema doesn't current reflect the "best" in
> identity management
> and by adding nsPerson like this, we can really do the right thing
> here, by
> default.
>
> *obivously* this is a new schema, not changing existing items, so
> existing deployments
> will keep using whatever they want (person etc) - more that new
> deployments will
> see a modern, best practice that they can follow,
>
>
> I'd like to get feedback on this soon, as I'd like to have this in the
> cli
> tool demo I want to release soon.
>
> Thanks everyone,
>
>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Improve the demo objects from install



On 01/10/2018 10:08 AM, Máirín Duffy wrote:
> Hi William,
>
>>  With displayname you can only sort by "order of the displaynames".
>> So we can at least consistently sort this given the scenario above!
>
> Imagine a phone book sorted this way. In the US in any given town
> there would be 50 pages of Johns, making wayfinding really difficult.
> Is there a way for an application that's using LDAP in the backend to
> pull the last substring, for example, if they wanted to use the
> heuristic of last ordered is the sorting key?
>
>>  To *search* for surnames however, now you can do a substring search
>> in the displayName field. I'm not sure of your LDAP profficency, but
>> the search would be:
>
> I'm really not proficient at all. Is this like a regexp so "=*Brown"
> matches any entries that end in "Brown"?
This is common, and you would use a "substring" search filter:

"(sn=*brown)"


> Would this miss someone who had two surnames, say Sally Brown West,
> who chooses not to hyphenate?
"(sn=*brown*)"

You can also use compound search filters too:

Here is an "or" filter:

"(|(legalname=*brown*)(cn=*brown*")(sn=*brown*))"

The options are endless.

Regards,
Mark

>
> Cheers,
> ~m
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

2018-01-10 Thread Adam Jackson

On Tue, 2018-01-09 at 12:25 +0100, Florian Weimer wrote:
> On 01/09/2018 11:00 AM, Petr Pisar wrote:
> > On 2018-01-05, Florian Weimer  wrote:
> > >perl-PDL-2.18.0-4.fc27.src.rpm
> > 
> > [...]
> > > This is based on relatively current Fedora rawhide/x86_64 and reflects
> > > which currently uses svc_/clnt_/xdr_ symbols from glibc.  It does not
> > > indicate whether these packages can use libtirpc or have bundled
> > > replacements.
> > How exactly these xdr_ symbols changed?
> 
> They are compat symbols, so existing binaries can still reference them.
> 
> The perl-PDL situation is yet a bit more complex.  Rebuilding it with 
> the new glibc succeeds because the xdr_ symbols actually come from HDF, 
> which only provides a static library.  Our ld does not default to “-z 
> defs”, so SD.so contains an undefined symbol references to xdr_enum and 
> similar symbols.  This reference is unversioned, so the glibc dynamic 
> linker will still bind it to the base symbol version in glibc (e.g., 
> xdr_enum@GLIBC_2.2.5).

Would it help if xdr_enum@GLIBC_2.2.5 etc. were made weak symbols? That
way an unversioned reference could resolve to the one in libtirpc if
that happens to be in memory. (I _think_ this is how do_lookup_x
already works, but it's hard to ever be sure I'm reading it right.)

Definitely mostly in favor of -z defs though. ld doesn't have a way to
invert that option atm, but once it does that'd nice to have in a mass
rebuild.

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

[389-devel] Re: Improve the demo objects from install

2018-01-10 Thread Máirín Duffy


Hi William,


 With displayname you can only sort by "order of the displaynames". So we can 
at least consistently sort this given the scenario above!


Imagine a phone book sorted this way. In the US in any given town there 
would be 50 pages of Johns, making wayfinding really difficult. Is there 
a way for an application that's using LDAP in the backend to pull the 
last substring, for example, if they wanted to use the heuristic of last 
ordered is the sorting key?



 To *search* for surnames however, now you can do a substring search in the 
displayName field. I'm not sure of your LDAP profficency, but the search would 
be:


I'm really not proficient at all. Is this like a regexp so "=*Brown" 
matches any entries that end in "Brown"? Would this miss someone who had 
two surnames, say Sally Brown West, who chooses not to hyphenate?


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

[Bug 1532539] [PATCH] Invalid definitions in macros.perl

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



--- Comment #2 from Fedora Update System  ---
perl-5.26.1-402.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f8f01f1e83

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

On Wed, Jan 10, 2018 at 9:30 AM, David Kaspar [Dee'Kej]
 wrote:
> On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa  wrote:
>>
>> Is there a specific bug that forces us to require we have transitional
>> packages like this? RPM's Conflicts+Obsoletes logic is powerful enough
>> to allow us to avoid this.
>
> I'm not aware of any BZ/Fedora wiki page that is requiring this. This
> solution was based solely on my best judgment. To clarify on this:
>
> The 'ghostscript-core' is a "main" subpackage in previous subpackage scheme.
> It basically contained almost everything from Ghostscript's compilation, and
> IIRC few of other packages were requiring this package directly in their
> specfiles...
>
> Other packages were not yet updated to requires correct subpackage from new
> subpackage layout. Therefore I decided to transform 'ghostscript-core' into
> auxiliary subpackage, since it was already there.
>
> This should have allowed new Ghostscript to be rolled out without breaking
> build process for them (hopefully completely, or at least it should at
> mitigate most of the problems). And the other packages can be then rebuild
> immediately once their requirements have been appropriately updated. :)
>
>

If the content of "ghostscript-core" is now part of "ghostscript", you
can do the following:

Obsoletes: ghostscript-core < 9.22-5
Provides: ghostscript-core = %{version}-%{release}

In addition, packages that currently require "ghostscript-core" can
and should be fixed for Fedora 28. In my view, there's nothing that
necessitates this metapackage for a development branch.

If this was going into Fedora 27, for example, then sure, it makes sense.

>> Why are examples not shipped? For documentation, this seems to be
>> fine, especially since it's a separate subpackage anyway.
>
> Upstream has decided to drop the examples/ completely from the next version
> of Ghostscript release (9.23). According to them those files are more useful
> for testing purposes rather than actual examples, and those files are poorly
> written PostScript files. They wouldn't help people who would like to learn
> how to write PostScript documents. That's why upstream does not want to ship
> those files anymore.
>
> Since I was doing changes to contents/layout of Ghostscript, I thought it
> was a good time to incorporate this change into the package already.
>
>

Makes sense to me. Thanks for the detailed rationale. :)

>>
>> > * Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
>> > Ghostscript's default choice for rendering of CJK glyphs, which is
>> > Google
>> > Droid Sans Fallback font. In case this proves insufficient, the conf.d/
>> > folder support will be re-established.
>> >
>> > ->> This change is still being discussed with Peng Wu and Akira Tagoh.
>> > So
>> > far, we have agreed to this change, but I will be ready to revert it in
>> > case
>> > people depending on printing CJK-based texts will have any problems. In
>> > case
>> > the Ghostscript's default functionality would prove to be sufficent and
>> > work
>> > OK, then the 'ghostscript-chinese' package could be retired as a result.
>> > ->> For now, we are also waiting for rebase of 'google-droid-fonts' for
>> > Ghostscript to have the latest version of Droid Sans Fallback font and
>> > thus
>> > the latest CJK glyphs coverage.
>> >
>>
>> I'm confused why we would drop support for conf.d directories. Unless
>> it's completely unavoidable, I don't see why we would do this. We
>> can't possibly know of everyone who might be using them, and generally
>> speaking, I'd like to see more software configurable this way, not
>> less.
>
>
> The folder /usr/share/ghostscript/conf.d/ actually comes from the package
> 'ghostscript-chinese'. Ghostscript itself was just configured to check that
> folder for configuration before, if there was any.
>
> The folder itself contained mappings for specific locales into specific
> CJK-based fonts. It was used only after 'ghostscript-chinese' was installed.
> This solution was introduced into Ghostscript more than a decade ago, and it
> is based on this project:
> https://www.freedesktop.org/wiki/Software/CJKUnifonts/
>
> If you look at the project, you will that it is basically dead, and the
> 'ghostscript-chinese' package itself received last update in 2012.
>
> The main purpose of using 'ghostscript-chinese' is to introduce a workaround
> for displaying/printing of CJK-based documents which do not have the correct
> font embedded (for displaying the glyphs inside the document text). When
> document wouldn't have correct CJK font(s) embedded inside it, then
> Ghostscript would the closest substitution(s), so the document can be at
> least displayed/printed in a readable/legible way. However, the substitution
> will never be perfect, and will always be best-effort workaround.
>
> The above described situation was valid several years ago. Nowadays upstream
> has its own solution (i.e.

Re: Package Question

2018-01-10 Thread Steve Dickson

Thanks for all the input... very interesting.

But I decide to go a head can create a new package
which eliminates all the questions about lifecycles
dependencies, licenses, etc 

Again, thanks for all the input!

steved.

On 01/08/2018 12:21 PM, Steve Dickson wrote:
> Hello,
> 
> Is it a problem for a package to pull from two different 
> upstream tar balls? Basically have 
> 
> Source0: http://server.com/package1/package1.tar
> Source1: http://server.com/package2/package2.tar
> 
> Then I would, by hand, untar Source1 into Source0 directory.
> 
> Before do the work I want to make sure I'm not
> breaking violating any package rules. I did look
> around and didn't see anything addressing this.
> 
> If this is kosher, are there any examples of other
> packages doing this... 
> 
> tia,
> 
> 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

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread David Kaspar [Dee'Kej]

On Wed, Jan 10, 2018 at 3:30 PM, David Kaspar [Dee'Kej] 
wrote:

> I hope I didn't forget to mention something important... :D If something
> is unclear, lay it on me! ;)
>

Yeah, I forgot one more small thing to mention... :D For now I'm waiting
for 'google-droid-fonts' to be rebased to latest version, to make sure that
the upstream's default solution for CJK-based documents missing embedded
fonts is up-to-date. (https://bugzilla.redhat.com/show_bug.cgi?id=1532523)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread David Kaspar [Dee'Kej]

On Wed, Jan 10, 2018 at 2:05 PM, Neal Gompa  wrote:

> Is there a specific bug that forces us to require we have transitional
> packages like this? RPM's Conflicts+Obsoletes logic is powerful enough
> to allow us to avoid this.
>
I'm not aware of any BZ/Fedora wiki page that is requiring this. This
solution was based solely on my best judgment. To clarify on this:

The 'ghostscript-core' is a "main" subpackage in previous subpackage
scheme. It basically contained almost everything from Ghostscript's
compilation, and IIRC few of other packages were requiring this package
directly in their specfiles...

Other packages were not yet updated to requires correct subpackage from new
subpackage layout. Therefore I decided to transform 'ghostscript-core' into
auxiliary subpackage, since it was already there.

This should have allowed new Ghostscript to be rolled out without breaking
build process for them (hopefully completely, or at least it should at
mitigate most of the problems). And the other packages can be then rebuild
immediately once their requirements have been appropriately updated. :)

Why are examples not shipped? For documentation, this seems to be
> fine, especially since it's a separate subpackage anyway.
>
Upstream has decided to drop the examples/ completely from the next
version of Ghostscript release (9.23). According to them those files are
more useful for testing purposes rather than actual examples, and those
files are poorly written PostScript files. They wouldn't help people who
would like to learn how to write PostScript documents. That's why upstream
does not want to ship those files anymore.

Since I was doing changes to contents/layout of Ghostscript, I thought it
was a good time to incorporate this change into the package already.

> > * Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
> > Ghostscript's default choice for rendering of CJK glyphs, which is Google
> > Droid Sans Fallback font. In case this proves insufficient, the conf.d/
> > folder support will be re-established.
> >
> > ->> This change is still being discussed with Peng Wu and Akira Tagoh. So
> > far, we have agreed to this change, but I will be ready to revert it in
> case
> > people depending on printing CJK-based texts will have any problems. In
> case
> > the Ghostscript's default functionality would prove to be sufficent and
> work
> > OK, then the 'ghostscript-chinese' package could be retired as a result.
> > ->> For now, we are also waiting for rebase of 'google-droid-fonts' for
> > Ghostscript to have the latest version of Droid Sans Fallback font and
> thus
> > the latest CJK glyphs coverage.
> >
>
> I'm confused why we would drop support for conf.d directories. Unless
> it's completely unavoidable, I don't see why we would do this. We
> can't possibly know of everyone who might be using them, and generally
> speaking, I'd like to see more software configurable this way, not
> less.
>

The folder /usr/share/ghostscript/conf.d/ actually comes from the package
'ghostscript-chinese'. Ghostscript itself was just configured to check that
folder for configuration before, if there was any.

The folder itself contained mappings for specific locales into
specific CJK-based
fonts. It was used only after 'ghostscript-chinese' was installed. This
solution was introduced into Ghostscript more than a decade ago, and it is
based on this project: https://www.freedesktop.org/wiki/Software/
CJKUnifonts/

If you look at the project, you will that it is basically dead, and the
'ghostscript-chinese' package itself received last update in 2012.

The main purpose of using 'ghostscript-chinese' is to introduce a
workaround for displaying/printing of CJK-based documents which do not have
the correct font embedded (for displaying the glyphs inside the document
text). When document wouldn't have correct CJK font(s) embedded inside it,
then Ghostscript would the closest substitution(s), so the document can be
at least displayed/printed in a readable/legible way. However, the
substitution will never be perfect, and will always be best-effort
workaround.

The above described situation was valid several years ago. Nowadays
upstream has its own solution (i.e. workaround) on doing so, which is based
only on one (different) font - Google Droid Sans Fallback.

I'm still discussing this change with Peng Wu (maintainer of
'ghostscript-chinese') and Akira Tagoh (fontconfig upstream developer)
off-the-list, but for now we have agreed to try use the default upstream's
solution for this scenario.

If it works well, this should mean less maintenance work for Peng
('ghostscript-chinese' could be dropped), and we wouldn't have a downstream
solution that could potentially cause additional issues in the future.
Also, the downstream solutions were really not popular with upstream before
(IMHO they didn't like Fedora at all because of it), and I was working with
them for last half and a year to improve our

[EPEL-devel] Fedora EPEL 7 updates-testing report

2018-01-10 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1038  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 800  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 383  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 280  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 112  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d704442ae7   
qpid-cpp-1.37.0-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-753e392fc4   
xrdp-0.9.5-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2e2d08b1ff   
awstats-7.6-4.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-49ca8440a1   
gifsicle-1.90-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28611aa33f   
python-bottle-0.12.13-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-885bb5ec89   
poco-1.6.1-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

R-RInside-0.2.14-5.el7
gammu-1.39.0-1.el7
kompose-1.7.0-1.el7
lizardfs-3.12.0-1.el7
mongodb-2.6.12-5.el7
orangefs-2.9.7-1.el7
pdns-3.4.11-2.el7
poco-1.6.1-3.el7
python-bottle-0.12.13-1.el7
python-gammu-2.11-2.el7
python3-dns-1.15.0-7.el7
wammu-0.44-3.el7
yaml-cpp-0.5.3-7.el7

Details about builds:



 R-RInside-0.2.14-5.el7 (FEDORA-EPEL-2018-1141973a4a)
 C++ Classes to Embed R in C++ Applications

Update Information:

Rebuild with updated R-Rcpp.




 gammu-1.39.0-1.el7 (FEDORA-EPEL-2018-3c49613978)
 Command Line utility to work with mobile phones

Update Information:

Update gammu, python-gammu and wammu

References:

  [ 1 ] Bug #1531832 - wammu-0.44 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1531832
  [ 2 ] Bug #1531519 - gammu-1.39.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1531519
  [ 3 ] Bug #1504333 - gammu-1.38.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1504333
  [ 4 ] Bug #1531828 - python-gammu-2.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1531828
  [ 5 ] Bug #1510442 - python-gammu-2.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1510442




 kompose-1.7.0-1.el7 (FEDORA-EPEL-2018-21ad37dfbd)
 Tool to move from 'docker-compose' to Kubernetes

Update Information:

Update to kompose-1.7.0 source

References:

  [ 1 ] Bug #1478152 - kompose tries to install docker
https://bugzilla.redhat.com/show_bug.cgi?id=1478152
  [ 2 ] Bug #1486973 - kompose-v1.7.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1486973




 lizardfs-3.12.0-1.el7 (FEDORA-EPEL-2018-a88951b7c0)
 Distributed, fault tolerant file system

Update Information:

  An update that adds support for rich (NFS4) ACLs and advanced chunkserver
options.  For the smoothest upgrade experience, first upgrade your metadata
shadows and loggers, then the metadata master, then the chunkservers, and
finally the clients.  See the notes at
https://docs.lizardfs.com/adminguide/upgrading.html for more details (the 3.10
upgrade notes apply if 3.12 are still missing).




 mongodb-2.6.12-5.el7 (FEDORA-EPEL-2018-c4856b5c5a)
 High-performance, schema-free document-oriented database

Update Information:

Updated

[EPEL-devel] Fedora EPEL 6 updates-testing report

2018-01-10 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 910  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 800  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 772  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 383  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 112  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  31  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-37c8dbd6f1   
gifsicle-1.90-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fde8252ab7   
python-bottle-0.12.13-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

R-RInside-0.2.14-5.el6
python-bottle-0.12.13-1.el6

Details about builds:



 R-RInside-0.2.14-5.el6 (FEDORA-EPEL-2018-feb4cc6667)
 C++ Classes to Embed R in C++ Applications

Update Information:

Rebuild with updated R-Rcpp.




 python-bottle-0.12.13-1.el6 (FEDORA-EPEL-2018-fde8252ab7)
 Fast and simple WSGI-framework for small web-applications

Update Information:

Update to 0.12.13    Update to 0.12.9  Ship python34-bottle

References:

  [ 1 ] Bug #1405418 - CVE-2016-9964 python-bottle: redirect() doesn't filter 
"\r\n" which allows for CRLF attack [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1405418

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

[Bug 1532539] [PATCH] Invalid definitions in macros.perl

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-5.26.1-402.fc28



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

scotch: packaging a version with 64bit integers

2018-01-10 Thread Sandro Mani


Hi

I've received a request to package a version of scotch with 64bit 
integers (as opposed to 32bit). I suppose the details are less 
important, the bottom line is


scotch 32bit: typedef int32_t SCOTCH_Num;

scotch 64bit: typedef int64_t SCOTCH_Num;

where SCOTCH_Num affects the public ABI and is used by third parties 
which use scotch.



Upstream allows selecting the integer size at compile-time (i.e. passing 
-DINTSIZE64 for int64_t). However, this choice has no effect on the 
library name, so vanilla upstream will build a library named 
libscotch.so regardless of how you configure it.



I'm skeptical whether introducing a downstream scotch64 package with 
i.e. libscotch64.so is a good solution, given that possibly no build 
system of third-party software using scotch knows about libscotch64.so 
and would need to be carefully patched (i.e. to not mix parts using 
libscotch and those using libscotch64). Also, introducing downstream 
specific suffixes is never a good idea.


The alternative would be to just switch the main scotch package to 64bit 
integers, but this may be undesirable for memory-bound applications 
which rely on the smaller memory-usage of 32bit integers.



I'm not really sure whether there is a good solution, happy to hear 
opinions.



Thanks

Sandro

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

Re: F28 System Wide Change: Rename "nobody" user

On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik  wrote:
> = System Wide Change: Rename "nobody" user =
> https://fedoraproject.org/wiki/Changes/RenameNobodyUser
>
> Change owner(s):
> *Zbigniew Jędrzejewski-Szmek 
> * Lennart Poettering 
>
> Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
> and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
> with 99:99 numbers
>
>
> == Detailed Description ==
> Status quo: Fedora statically defines "nobody:nobody" pair with
> uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
> uid:gid of 65534:65534 in nfs-utils.rpm.
>
> This is problematic in a few different ways:
> * 65534:65534 is used by the kernel as the overflow identifier, when
> some UID cannot be represented in the current namespace. This applies
> to both NFS, but probably more commonly nowadays to UIDs outside of
> the current user namespace (e.g. when a file or process owned by a
> user from outside of a container). Calling this "nfsnobody" is
> misleading.
> * the name for the overflow user is only defined when nfs-utils.rpm is
> installed. In particular in containers people want to minimize the
> number of packages installed, so nfs-utils is likely not to be
> installed.
> * the static nobody:nobody user/group pair was used for various
> services for which weren't "worthy" of creating a dedicated user. This
> is a severely misguided concept, because all processes of the nobody
> user can ptrace and otherwise interact with each other. Separate users
> for each service should be used instead, either normal allocated users
> or systemd's DynamicUser's.
> * other distributions use either nobody:nobody or nobody:nogroup for
> the overflow uid:gid pair, and the different naming in Fedora is
> confusing and can lead to incorrect use.
>
> We propose to:
> * stop using nfsnobody for the overflow uid/gid names
> * stop using nobody for the static user 99 and group 99
> * use the nobody:nobody pair of names for 65534:65534
>
> On existing systems, to make upgrades easier:
> * if nfsnobody was defined, keep it in /etc/passwd *after* the new
> line for nobody:nobody, so that both the old name and the new name map
> to the same numbers
> * if nobody user or group with number 99 was defined, keep it in
> /etc/passwd and /etc/group, but rename to _nobody
>
> The new mapping for nobody:nobody would be implemented in two redundant ways:
> * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
> * dynamically provided by the nss-systemd module (by compiling systemd
> with -Dnobody-user=nobody -Dnobody-group=nobody).
>

Two questions:

1. Why nobody:nobody instead of nobody:nogroup? I've seen the latter
in use in several distributions.
* For note, we use this in Mageia:
http://gitweb.mageia.org/software/setup/tree/group
* Debian and Ubuntu also define it this way.

2. For existing systems, would renaming the nobody:nobody user to
oldnobody:oldnobody work instead? The uid would be preserved, which
should keep the mapping sane, and it would make it more obvious that
it's old, rather than using weird underscores.

In general, I support this change because the two nobody users made
things confusing for me and many other people. Simplifying this would
also harmonize things with everyone else, which helps for portability
of things. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

On Tue, Jan 9, 2018 at 5:51 PM, David Kaspar [Dee'Kej]
 wrote:
> Hello guys! :)
>
> Initial NOTE: I have made some bigger changes in Ghostscript package during
> the cleanup, which should be self-contained. In my opinion those changes are
> not so significant to create "self-contained change" wiki page for it (for
> F28), but if the consensus of people here will be the opposite, then I will
> create it additionally...
>

Overall, I think this is awesome. Just some questions and nits below...

> ->> These subpackages contain files that only a small amount of people will
> ever need. Having them in a separate subpackages will avoid polluting users'
> filesystem after fresh F28+ installations.
>
> * ghostscript-core -- has became an empty metapackage for upgrade purposes.
> It will be removed once Fedora 28 is EOL, and all other packages has updated
> their specfiles to require correct subpackages.
>
> ->> This metapackage makes sure that upgrade from old package layout to new
> package layout should be smooth (tested in F27).
>

Is there a specific bug that forces us to require we have transitional
packages like this? RPM's Conflicts+Obsoletes logic is powerful enough
to allow us to avoid this.

> * LPR setup scripts are no longer being shipped. In case people still need
> those, then 'ghostscript-tools-lpr' will be created for it.
> * examples/ from 'ghostscript-doc' are no longer shipped.
> * Documentation and resources paths no longer contain version string inside
> of them.
>

Why are examples not shipped? For documentation, this seems to be
fine, especially since it's a separate subpackage anyway.

> * Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
> Ghostscript's default choice for rendering of CJK glyphs, which is Google
> Droid Sans Fallback font. In case this proves insufficient, the conf.d/
> folder support will be re-established.
>
> ->> This change is still being discussed with Peng Wu and Akira Tagoh. So
> far, we have agreed to this change, but I will be ready to revert it in case
> people depending on printing CJK-based texts will have any problems. In case
> the Ghostscript's default functionality would prove to be sufficent and work
> OK, then the 'ghostscript-chinese' package could be retired as a result.
> ->> For now, we are also waiting for rebase of 'google-droid-fonts' for
> Ghostscript to have the latest version of Droid Sans Fallback font and thus
> the latest CJK glyphs coverage.
>

I'm confused why we would drop support for conf.d directories. Unless
it's completely unavoidable, I don't see why we would do this. We
can't possibly know of everyone who might be using them, and generally
speaking, I'd like to see more software configurable this way, not
less.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

2018-01-10 Thread Pavel Březina

On 01/09/2018 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jan 09, 2018 at 04:30:56PM +0100, Pavel Březina wrote:

On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:

= System Wide Change: Make authselect default tool instead of authconfig =
https://fedoraproject.org/wiki/Changes/AuthselectAsDefault

Does this change do anything to reduce the number of files in /etc
that do not contain local configuration? PAM is currently one of the
worst offenders, with /etc/pam.d full of "configuration" files.

No. The files must stay since it would require changes in pam itself
and that is out of scope of authselect. Each file corresponds to
individual pam service and is read when pam_start(service_name, ...)
is called.

Elsewhere in the thread /usr/share/authselect/custom is metioned as
directory for admin config. That's OK-ish, as long as you also allow
a directory in /etc for the same purpose. /usr must be allowed to be
immutable.

Would /usr/local be OK as well?

/usr/local is special. Packages are not allowed to put stuff there [1],
and it is instead an alternate install location that is under the
control of the administrator. It seems reasonable to support
authselect configuration located there.

/usr/share/authselect and /etc/authselect are the two main locations
that should be supported, and /usr/local/share/autselect would be an
additional option.

[1]
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER

Thank you for the info. I created upstream ticket to track this change:
https://github.com/pbrezina/authselect/issues/28
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

2018-01-10 Thread Martin Stransky


On 01/08/2018 01:36 AM, Kevin Fenzi wrote:

On 01/07/2018 01:38 PM, Christian Dersch wrote:

Hi all,

within the whole Meltdown and Spectre story I realized that Koji pushes
even security updates to batched only, not directly to stable. In


The critera for bypassing batched is if the update is marked "urgent".


concrete case we have the firefox update [1], which already received 10
positive karma and many users complaining that it takes so long to get
it out as a stable update. Shouldn't we change that behaviour to get
such security updates out fast when maintainer relies on autopush when
karma threshold is reached?


If they are urgent sure... perhaps this should have been so marked?
Or the maintainer/submittor can request stable anytime after it has
enough karma.

Anyhow, I have pushed it to request stable and will do another f27 push
after the current ones finish to get it out today.


Seems to be my fault then, didn't know that the urgent/high state has 
the meaning there.


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

[Bug 1511243] perl-Mail-Message-3.005 is available

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



--- Comment #9 from Fedora Update System  ---
perl-Mail-Message-3.005-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d4b2798525

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1532539] [PATCH] Invalid definitions in macros.perl

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



--- Comment #1 from Panu Matilainen  ---
BTW, the way deltarpm is designed makes this otherwise fairly harmless thing
rather, ehm, conspicuous :)

---

Transaction Summary

Upgrade  75 Packages

Total download size: 308 M
Is this ok [y/N]: y
Downloading Packages:
(1/75): apr-util-1.6.1-1.fc27_1.6.1-2.fc27.x86_ 350 kB/s |  21 kB 00:00
(2/75): cups-filters-1.16.1-3.fc27_1.16.1-4.fc2 1.9 MB/s | 144 kB 00:00
error: Macro %global is a built-in (%define)  ] 699 kB/s | 165 kB 06:42 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(3/75): cups-filters-libs-1.16.1-3.fc27_1.16.1- 1.4 MB/s |  25 kB 00:00
error: Macro %global is a built-in (%define)  ] 703 kB/s | 190 kB 06:40 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
error: Macro %global is a built-in (%define)
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(4/75): devscripts-checkbashisms-2.17.11-1.fc27 485 kB/s |  13 kB 00:00
(5/75): apr-util-ldap-1.6.1-1.fc27_1.6.1-2.fc27 145 kB/s |  17 kB 00:00
error: Macro %global is a built-in (%define)  ] 753 kB/s | 465 kB 06:13 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(6/75): gimp-2.8.22-2.fc27.3_2.8.22-3.fc27.x86_ 7.1 MB/s | 3.4 MB 00:00
[DRPM 1/28] apr-util-1.6.1-1.fc27_1.6.1-2.fc27.x86_64.drpm: done   
[DRPM 2/28] cups-filters-libs-1.16.1-3.fc27_1.16.1-4.fc27.x86_64.drpm: done
[DRPM 3/28] devscripts-checkbashisms-2.17.11-1.fc27_2.17.12-1.fc27.x86_64.drpm:
done
(7/75): hwdata-0.307-1.fc27_0.308-1.fc27.noarch  47 kB/s |  37 kB 00:00
error: Macro %global is a built-in (%define)  ] 1.3 MB/s | 3.7 MB 03:27 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(8/75): gimp-libs-2.8.22-2.fc27.3_2.8.22-3.fc27 113 kB/s |  91 kB 00:00
error: Macro %global is a built-in (%define)  ] 1.3 MB/s | 3.8 MB 03:26 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(9/75): iwl6000-firmware-9.221.4.1-81.fc27_9.22 969 kB/s |  18 kB 00:00
error: Macro %global is a built-in (%define)  ] 1.3 MB/s | 3.9 MB 03:21 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(10/75): initscripts-9.78-1.fc27_9.79-1.fc27.x8 6.3 MB/s | 186 kB 00:00
(11/75): pcre2-10.30-3.fc27_10.30-4.fc27.x86_64 1.8 MB/s |  23 kB 00:00
(12/75): pcre2-devel-10.30-3.fc27_10.30-4.fc27. 2.4 MB/s |  43 kB 00:00
(13/75): pcre2-utf16-10.30-3.fc27_10.30-4.fc27. 2.2 MB/s |  18 kB 00:00
(14/75): libffado-2.3.0-7.fc27_2.4.0-1.fc27.x86 4.2 MB/s | 191 kB 00:00
(15/75): pcre2-utf32-10.30-3.fc27_10.30-4.fc27. 1.6 MB/s |  19 kB 00:00
(16/75): perl-Digest-SHA-6.00-1.fc27_6.01-1.fc2 1.5 MB/s |  23 kB 00:00
(17/75): perl-Module-CoreList-5.20171120-1.fc27 1.9 MB/s |  14 kB 00:00
(18/75): perl-Module-CoreList-tools-5.20171120- 1.3 MB/s | 9.6 kB 00:00
(19/75): publicsuffix-list-20171028-1.fc27_2017 957 kB/s | 8.1 kB 00:00
(20/75): poppler-0.57.0-6.fc27_0.57.0-7.fc27.x8 3.0 MB/s |  39 kB 00:00
(21/75): poppler-glib-0.57.0-6.fc27_0.57.0-7.fc 2.2 MB/s |  28 kB 00:00
(22/75): publicsuffix-list-dafsa-20171028-1.fc2 1.4 MB/s |  33 kB 00:00
(23/75): python3-sphinxcontrib-websupport-1.0.1 671 kB/s |  15 kB 00:00
(24/75): python2-sphinxcontrib-websupport-1.0.1 429 kB/s |  14 kB 00:00
[DRPM 4/28] apr-util-ldap-1.6.1-1.fc27_1.6.1-2.fc27.x86_64.drpm: done  
error: Macro %global is a built-in (%define)  ] 1.4 MB/s | 4.4 MB 03:10 ETA
error: Macro %global is a built-in (%define)
warning: file /usr/lib/rpm/macros.d/macros.perl: 2 invalid macro definitions
(25/75): selinux-policy-devel-3.13.1-283.19.fc2 3.7 MB/s | 587 kB 00:00
(26/75): wireshark-devel-2.4.2-1.fc27_2.4.3-1.f 1.0 MB/s | 152 kB 00:00
(27/75): bakefile-0.2.10-5.fc27.x86_64.rpm  1.4 MB/s | 252 kB 00:00
(28/75): bash-4.4.12-13.fc27.x86_64.rpm 3.4 MB/s | 1.5 MB 00:00
(29/75): container-selinux-2.38-1.fc27.noarch.r 1.7 MB/s |  36 kB 00:00
(30/75): devscripts-compat-2.17.12-1.fc27.x86_6 689 kB/s |  14 kB 00:00
(31/75): wireshark-cli-2.4.2-1.fc27_2.4.3-1.fc2 4.8 MB/s | 6.6 MB 00:01
(32/75): dracut-network-046-8.git20180105.fc27. 4.4 MB/s |  90 kB 00:00
(33/75): dracut-config-rescue-046-8.git20180105 3.2 MB/s |  47 kB 00:00
(34/75):

Re: Security updates and batched pushes

2018-01-10 Thread Tomasz Torcz

January 9, 2018 9:59 PM, "Kevin Kofler"  wrote:

> Kevin Fenzi wrote:
> 
>> To save all the Fedora users in the world from having to update metadata
>> for minor changes. Since there's a hourly dnf makecache every user in
>> the world pulls down new metadata ever time we update a repo.
> 
> So to save people the download, you make a change that totally defeats the
> point of dnf checking for updates every hour to begin with?
> 
>> If we update a repo for some minor enhancements it means everyone in the
>> world has to pay for that. If we just push all those out every tuesday and
>> don't update those unless there's something urgent we save everyone a
>> lot of bandwith and us computing time/resources.
> 
> This does not work in practice because there are always updates that are not
> batched.
> 
>> There are definitely more days when there are no updates for a
>> particular repo now. Of course there would be even more if you (or those
>> who do likewise) wouldn't skip batched, but probibly we need to explain
>> why more clearly.
> 
> Are there really? The last couple days, there were basically daily pushes
> with around 2 updates each.

  So, if there ARE updates to be pushed (marked urgent?) and we update metadata
ANYWAY, this is a good point to flush everything from batched in this push.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1528627] Upgrade perl-Mail-DKIM to 0.50

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Mail-DKIM-0.50-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|ky...@kylev.com |jples...@redhat.com
Last Closed||2018-01-10 06:53:07



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1531969] perl-DBIx-Class-DeploymentHandler-0.002222 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-DBIx-Class-DeploymentH
   ||andler-0.00-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |jples...@redhat.com
Last Closed||2018-01-10 06:51:18



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

On Wed, Jan 10, 2018 at 11:56:46AM +0100, Reindl Harald wrote:
> 
> 
> Am 10.01.2018 um 11:46 schrieb Jan Kurik:
> >On existing systems, to make upgrades easier:
> >* if nfsnobody was defined, keep it in /etc/passwd *after* the new
> >line for nobody:nobody, so that both the old name and the new name map
> >to the same numbers
> >* if nobody user or group with number 99 was defined, keep it in
> >/etc/passwd and /etc/group, but rename to _nobody
> that don't make updates easier but breaks existing setups where
> nobody:nobody with 99:99 already owns files - don't touch long years
> running machines due dist-upgrades please - at least not with "dnf
> --releasever=28 distro-sync"
 
That'd amount to leaving existing systems unchanged. That's an option
that I didn't like and initially rejected, but yeah, it's probably better.
I'll wait a bit more for feedback and update the proposal a bit later
to leave existing systems alone (i.e. systems which have either nobody
or nfsnobody already defined in the old style).

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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build


On 10.1.2018 11:25, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jan 10, 2018 at 09:33:44AM +0100, Miro Hrončok wrote:

On 10.1.2018 03:16, Nick Coghlan wrote:

On 10 January 2018 at 11:30, Jason L Tibbitts III  wrote:

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.


Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look something like:

 PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning


This sounds good to me. It didn't occur to me that we can actually
set a dedicated env vars for our builds (which is even better).


Sounds like a good idea, but it's not entirely clear what "our builds"
means. If it's just koji, then I think this is not enough. We really want
'fedpkg local' and 'fedpkg mockbuild' to emit those warnings too, so that
people can find and fix them easily. And it should not just be possible to
get the warning locally (e.g. by setting a variable from the command line),
but also the default should be the same as in koji, so that the results
of local builds and remote builds match. If this can't be done, the
implementation of this change is going to be harder for packagers.


Noted. Will think about that, added a note to the change page.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 System Wide Change: Rename "nobody" user

2018-01-10 Thread Jan Kurik

= System Wide Change: Rename "nobody" user =
https://fedoraproject.org/wiki/Changes/RenameNobodyUser

Change owner(s):
*Zbigniew Jędrzejewski-Szmek 
* Lennart Poettering 

Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
with 99:99 numbers


== Detailed Description ==
Status quo: Fedora statically defines "nobody:nobody" pair with
uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
uid:gid of 65534:65534 in nfs-utils.rpm.

This is problematic in a few different ways:
* 65534:65534 is used by the kernel as the overflow identifier, when
some UID cannot be represented in the current namespace. This applies
to both NFS, but probably more commonly nowadays to UIDs outside of
the current user namespace (e.g. when a file or process owned by a
user from outside of a container). Calling this "nfsnobody" is
misleading.
* the name for the overflow user is only defined when nfs-utils.rpm is
installed. In particular in containers people want to minimize the
number of packages installed, so nfs-utils is likely not to be
installed.
* the static nobody:nobody user/group pair was used for various
services for which weren't "worthy" of creating a dedicated user. This
is a severely misguided concept, because all processes of the nobody
user can ptrace and otherwise interact with each other. Separate users
for each service should be used instead, either normal allocated users
or systemd's DynamicUser's.
* other distributions use either nobody:nobody or nobody:nogroup for
the overflow uid:gid pair, and the different naming in Fedora is
confusing and can lead to incorrect use.

We propose to:
* stop using nfsnobody for the overflow uid/gid names
* stop using nobody for the static user 99 and group 99
* use the nobody:nobody pair of names for 65534:65534

On existing systems, to make upgrades easier:
* if nfsnobody was defined, keep it in /etc/passwd *after* the new
line for nobody:nobody, so that both the old name and the new name map
to the same numbers
* if nobody user or group with number 99 was defined, keep it in
/etc/passwd and /etc/group, but rename to _nobody

The new mapping for nobody:nobody would be implemented in two redundant ways:
* as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
* dynamically provided by the nss-systemd module (by compiling systemd
with -Dnobody-user=nobody -Dnobody-group=nobody).



== Scope ==
* Proposal owners:
- recompile systemd with the right options to get expected answer from
nss-systemd
- propose patches for setup.rpm to add the new mapping and do the
steps listed in Detailed Description on update
- propose patches for nfs-utils to remove the nfsnobody mapping and do
the steps listed in Detailed Description on update

* Other developers:
watch for regressions

* Release engineering:
#7258: https://pagure.io/releng/issue/7258

* List of deliverables:
N/A

* Policies and guidelines:
nothing
(https://fedoraproject.org/wiki/Packaging:Guidelines#Users_and_Groups
already says "Note that system services packaged for Fedora MUST NOT
run as the nobody user" so no changes are required there.)

* 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-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F28 System Wide Change: Rename "nobody" user

2018-01-10 Thread Jan Kurik

= System Wide Change: Rename "nobody" user =
https://fedoraproject.org/wiki/Changes/RenameNobodyUser

Change owner(s):
*Zbigniew Jędrzejewski-Szmek 
* Lennart Poettering 

Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
with 99:99 numbers


== Detailed Description ==
Status quo: Fedora statically defines "nobody:nobody" pair with
uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
uid:gid of 65534:65534 in nfs-utils.rpm.

This is problematic in a few different ways:
* 65534:65534 is used by the kernel as the overflow identifier, when
some UID cannot be represented in the current namespace. This applies
to both NFS, but probably more commonly nowadays to UIDs outside of
the current user namespace (e.g. when a file or process owned by a
user from outside of a container). Calling this "nfsnobody" is
misleading.
* the name for the overflow user is only defined when nfs-utils.rpm is
installed. In particular in containers people want to minimize the
number of packages installed, so nfs-utils is likely not to be
installed.
* the static nobody:nobody user/group pair was used for various
services for which weren't "worthy" of creating a dedicated user. This
is a severely misguided concept, because all processes of the nobody
user can ptrace and otherwise interact with each other. Separate users
for each service should be used instead, either normal allocated users
or systemd's DynamicUser's.
* other distributions use either nobody:nobody or nobody:nogroup for
the overflow uid:gid pair, and the different naming in Fedora is
confusing and can lead to incorrect use.

We propose to:
* stop using nfsnobody for the overflow uid/gid names
* stop using nobody for the static user 99 and group 99
* use the nobody:nobody pair of names for 65534:65534

On existing systems, to make upgrades easier:
* if nfsnobody was defined, keep it in /etc/passwd *after* the new
line for nobody:nobody, so that both the old name and the new name map
to the same numbers
* if nobody user or group with number 99 was defined, keep it in
/etc/passwd and /etc/group, but rename to _nobody

The new mapping for nobody:nobody would be implemented in two redundant ways:
* as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
* dynamically provided by the nss-systemd module (by compiling systemd
with -Dnobody-user=nobody -Dnobody-group=nobody).



== Scope ==
* Proposal owners:
- recompile systemd with the right options to get expected answer from
nss-systemd
- propose patches for setup.rpm to add the new mapping and do the
steps listed in Detailed Description on update
- propose patches for nfs-utils to remove the nfsnobody mapping and do
the steps listed in Detailed Description on update

* Other developers:
watch for regressions

* Release engineering:
#7258: https://pagure.io/releng/issue/7258

* List of deliverables:
N/A

* Policies and guidelines:
nothing
(https://fedoraproject.org/wiki/Packaging:Guidelines#Users_and_Groups
already says "Note that system services packaged for Fedora MUST NOT
run as the nobody user" so no changes are required there.)

* 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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build


On 10.1.2018 10:28, Petr Viktorin wrote:

On 01/10/2018 09:33 AM, Miro Hrončok wrote:

On 10.1.2018 03:16, Nick Coghlan wrote:
On 10 January 2018 at 11:30, Jason L Tibbitts III  
wrote:

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.


Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look 
something like:


 PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning


This sounds good to me. It didn't occur to me that we can actually set 
a dedicated env vars for our builds (which is even better).


+1, let's do that!


Changed 
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build 
accordingly.





This would potentially even make it possible to push this patch to 
upstream. >

Then either Koji can take care of setting that (and including it in
the mock configs it generates), or else it can be included in some of
the Fedora specific RPM setup.

Cheers,
Nick.

P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.








--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

On Wed, Jan 10, 2018 at 09:33:44AM +0100, Miro Hrončok wrote:
> On 10.1.2018 03:16, Nick Coghlan wrote:
> >On 10 January 2018 at 11:30, Jason L Tibbitts III  wrote:
> >>In the end I just can't shake the notion that it's bad to have some
> >>random non-python-related environment variable basically breaking
> >>python.
> >
> >Aye, I think you've hit on the main problem: if this is keyed off
> >RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
> >provided Python, even if those builds aren't otherwise required to
> >abide by Fedora's policy settings.
> >
> >With a dedicated environment variable instead, that could look something 
> >like:
> >
> > PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
> > PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
> > PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning
> 
> This sounds good to me. It didn't occur to me that we can actually
> set a dedicated env vars for our builds (which is even better).

Sounds like a good idea, but it's not entirely clear what "our builds"
means. If it's just koji, then I think this is not enough. We really want
'fedpkg local' and 'fedpkg mockbuild' to emit those warnings too, so that
people can find and fix them easily. And it should not just be possible to
get the warning locally (e.g. by setting a variable from the command line),
but also the default should be the same as in koji, so that the results
of local builds and remote builds match. If this can't be done, the
implementation of this change is going to be harder for packagers.

Zbyszek

> This would potentially even make it possible to push this patch to upstream.
> 
> >Then either Koji can take care of setting that (and including it in
> >the mock configs it generates), or else it can be included in some of
> >the Fedora specific RPM setup.
> >
> >Cheers,
> >Nick.
> >
> >P.S. Using a dedicated environment variable would have the advantage
> >of allowing anyone else that *also* wanted to look for and remove
> >unqualified references to Python 2 to set it.
> >
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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

jplesnik pushed to perl-Mail-Message (f27). "3.005 bump"

2018-01-10 Thread notifications

From c650a175ca28e5585744fc13f26a4244787fc1d2 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jan 10 2018 09:49:26 +
Subject: 3.005 bump


---

diff --git a/.gitignore b/.gitignore
index 95e52e4..3053447 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Mail-Message-3.000.tar.gz
 /Mail-Message-3.001.tar.gz
 /Mail-Message-3.002.tar.gz
+/Mail-Message-3.005.tar.gz
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index a7571f5..3cab334 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,5 +1,5 @@
 Name:  perl-Mail-Message
-Version:   3.002
+Version:   3.005
 Release:   1%{?dist}
 Summary:   MIME message handling
 Group: Development/Libraries
@@ -21,7 +21,7 @@ BuildRequires:perl(Email::Simple)
 BuildRequires: perl(Encode) >= 2.26
 BuildRequires: perl(Encode::Alias)
 BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires: perl(File::Basename)
 BuildRequires: perl(File::Copy)
 BuildRequires: perl(File::Spec) >= 0.7
@@ -104,12 +104,11 @@ rm -rf t/203head-listgroup.t t/204head-spamgroup.t
 %{?perl_default_filter}
 
 %build 
-yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor
+yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';'
 chmod -R u+w $RPM_BUILD_ROOT/*
 # Fix file encoding
@@ -129,6 +128,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Jan 10 2018 Jitka Plesnikova  - 3.005-1
+- 3.005 bump
+
 * Wed Sep 06 2017 Jitka Plesnikova  - 3.002-1
 - 3.002 bump
 
diff --git a/sources b/sources
index d031889..b9004ab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Mail-Message-3.002.tar.gz) = 
06aa8903ab9f4275916981c4a49a63741cef15161411e6b56ed58e08d539d1e3572e8eaa0bb77b7140e55beb60b8bfc2b26381295b5fcd82bb277652bd86c09e
+SHA512 (Mail-Message-3.005.tar.gz) = 
6990fe1710cc7e8a09430c8686a695e436c454c9e5b2063161ad87d493bbd5ef3825c214c82341b75e2d388354460b0502db7d1c1c5821cef58c0107be75



https://src.fedoraproject.org/rpms/perl-Mail-Message/c/c650a175ca28e5585744fc13f26a4244787fc1d2?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511243] perl-Mail-Message-3.005 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-Mail-Message-3.005-1.f
   ||c28
   Assignee|tcall...@redhat.com |jples...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Mail-Message (master). "3.005 bump"

2018-01-10 Thread notifications

From c650a175ca28e5585744fc13f26a4244787fc1d2 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jan 10 2018 09:49:26 +
Subject: 3.005 bump


---

diff --git a/.gitignore b/.gitignore
index 95e52e4..3053447 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Mail-Message-3.000.tar.gz
 /Mail-Message-3.001.tar.gz
 /Mail-Message-3.002.tar.gz
+/Mail-Message-3.005.tar.gz
diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index a7571f5..3cab334 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,5 +1,5 @@
 Name:  perl-Mail-Message
-Version:   3.002
+Version:   3.005
 Release:   1%{?dist}
 Summary:   MIME message handling
 Group: Development/Libraries
@@ -21,7 +21,7 @@ BuildRequires:perl(Email::Simple)
 BuildRequires: perl(Encode) >= 2.26
 BuildRequires: perl(Encode::Alias)
 BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires: perl(File::Basename)
 BuildRequires: perl(File::Copy)
 BuildRequires: perl(File::Spec) >= 0.7
@@ -104,12 +104,11 @@ rm -rf t/203head-listgroup.t t/204head-spamgroup.t
 %{?perl_default_filter}
 
 %build 
-yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor
+yes y |%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 make
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';'
 chmod -R u+w $RPM_BUILD_ROOT/*
 # Fix file encoding
@@ -129,6 +128,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Jan 10 2018 Jitka Plesnikova  - 3.005-1
+- 3.005 bump
+
 * Wed Sep 06 2017 Jitka Plesnikova  - 3.002-1
 - 3.002 bump
 
diff --git a/sources b/sources
index d031889..b9004ab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Mail-Message-3.002.tar.gz) = 
06aa8903ab9f4275916981c4a49a63741cef15161411e6b56ed58e08d539d1e3572e8eaa0bb77b7140e55beb60b8bfc2b26381295b5fcd82bb277652bd86c09e
+SHA512 (Mail-Message-3.005.tar.gz) = 
6990fe1710cc7e8a09430c8686a695e436c454c9e5b2063161ad87d493bbd5ef3825c214c82341b75e2d388354460b0502db7d1c1c5821cef58c0107be75



https://src.fedoraproject.org/rpms/perl-Mail-Message/c/c650a175ca28e5585744fc13f26a4244787fc1d2?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: HEADS UP - Changes to Ghostscript package in F28

2018-01-10 Thread Kamil Dudka

On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
> Initial NOTE: I have made some bigger changes in Ghostscript package during
> the cleanup, which should be self-contained. In my opinion those changes
> are not so significant to create "self-contained change" wiki page for it
> (for F28), but if the consensus of people here will be the opposite, then I
> will create it additionally...

As far as I understand, this is going to affect how other packages are built, 
installed, and run.  It should be reviewed by the affected parties to decide 
whether it is a self-contained or system-wide change and the respective 
process should be followed.

> The new Ghostscript should be available for trying/testing in Rawhide in a
> few hours. I will follow up with additional information (e.g. tracking BZ
> link) here in this thread.

It would be better to create a Copr for testing purposes to avoid disruption 
of Fedora development.

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

[389-devel] Re: Do aci's work in nested groups?

2018-01-10 Thread Ludwig Krispenz



On 01/10/2018 07:03 AM, William Brown wrote:

If I have:

(targetattr=x)(version 3.0;  allow(read, search)(groupdn=cn=x);)

If cn=x has member cn=y, and cn=y member uid=z

Does uid=z have permission to the targetattr here? IE do our aci's work
through nested groups?

yes, they should, but there is configurable max nesting level





--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1528630] Upgrade perl-Net-Appliance-Session to 4.300001

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Net-Appliance-Session-
   ||4.31-1.fc28
 Resolution|--- |RAWHIDE
   Assignee|negativ...@gmail.com|jples...@redhat.com
Last Closed||2018-01-10 04:28:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

2018-01-10 Thread Petr Viktorin


On 01/10/2018 09:33 AM, Miro Hrončok wrote:

On 10.1.2018 03:16, Nick Coghlan wrote:
On 10 January 2018 at 11:30, Jason L Tibbitts III  
wrote:

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.


Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look 
something like:


 PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning


This sounds good to me. It didn't occur to me that we can actually set a 
dedicated env vars for our builds (which is even better).


+1, let's do that!


This would potentially even make it possible to push this patch to 
upstream. >

Then either Koji can take care of setting that (and including it in
the mock configs it generates), or else it can be included in some of
the Fedora specific RPM setup.

Cheers,
Nick.

P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.






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

Re: Disable a package for Fedora 26

2018-01-10 Thread Jonny Heggheim

On 01/09/2018 10:09 PM, Kevin Kofler wrote:
> Jonny Heggheim wrote:
>> I think the best solution, based on my knowledge and available time, is
>> to upgrade Fedora 26 to the latest upstream.
> So please do that then. The sooner, the better.

I agree, pushed updates to bodhi yesterday, it would be great if someone
could test it on Fedora 26.

https://bodhi.fedoraproject.org/updates/FEDORA-2018-92de33f3b9
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b7e606d011

Jonny



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

[Bug 1532914] perl-Socket-2.025 is available

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



--- Comment #2 from Fedora Update System  ---
perl-Socket-2.025-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-36ebfbdf9d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1532914] perl-Socket-2.025 is available

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



--- Comment #3 from Fedora Update System  ---
perl-Socket-2.025-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2ae4888a92

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: How to retire/delete an EPEL branch?

2018-01-10 Thread Christopher

On Wed, Jan 10, 2018 at 1:53 AM Ding Yi Chen  wrote:

> I received a bug[1] asking to remove EPEL7 branch, as the package
> LibRaw, is already in RHEL.
>
> How should I do that?
>
>
Would (warning: this will lose history) `git push --delete origin epel7`
work? It'd be a shame to lose history if it's not already reflected in
another branch, though. Maybe do `git checkout master && git merge -s ours
epel7 && git push origin master` first to preserve the history in the
master branch without changing the code in that branch?


> Regards,
>
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1526701
> --
> Ding-Yi CHEN
>
> Software Engineer, Globalization Group
> Red Hat Asia-Pacific Pty Ltd
> dc...@redhat.com
> Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1532914] perl-Socket-2.025 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Socket-2.025-1.fc28



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build


On 10.1.2018 00:56, Kevin Kofler wrote:

Jan Kurik wrote:

Currently in Fedora (package names, executable names, etc.), python
means Python 2.
We would like to change it to mean Python 3, but to do that, we need
to free it of the current meaning.
This means explicitly using either "python2" or "python3" throughout
Fedora.


Are you sure that this is worth the pain? Unsuffixed qmake is still the Qt 3
QMake (not even Qt 4), unsuffixed kde-config is still the KDE 3 kde-config
(not even KDE 4), etc., for backwards compatibility. I think changing the
meaning of "python" is unhelpful and counterproductive. Sure, without this
change, more and more users will eventually end up with not having an
unsuffixed "python" installed at all, but IMHO that's better than silently
changing its meaning.


Whether we change it or get rid of it is not yet set in stone. However, 
Python 2 will be gone one day. And that day, everything will break if we 
don't start breaking it now by little chunks.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to retire jenkins.fedorainfracloud.org

2018-01-10 Thread Pierre-Yves Chibon

On Tue, Jan 09, 2018 at 09:25:03AM -0800, Adam Williamson wrote:
> On Tue, 2018-01-09 at 11:03 +0100, Pierre-Yves Chibon wrote:
> > Dear all,
> > 
> > The Fedora Infrastructure team has had a jenkins instance running at
> > jenkins.fedorainfracloud.org for a little while now. This instance was
> > maintained on a best-effort basis though and we often had outage and issues 
> > when
> > upgrading it.
> > Originally the jenkins master was running on RHEL using the RPMs provided by
> > upstream jenkins. When jenkins became available in Fedora, we switched our
> > master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins 
> > is no
> > longer packaged for Fedora, our jenkins master is therefore outdated.
> > 
> > On the other side of the fence, with our dear friends from CentOS, is a 
> > brand
> > new, shiny and well supported Jenkins instance.
> > So we thought it may be good to leverage the CentOS infrastructure to 
> > alleviate
> > our infrastructure and maintenance.
> > 
> > We are currently working on setting up a Jenkins master in ci.centos.org 
> > that
> > would be dedicated to projects ran in pagure.io.
> > It needs a small change to pagure.io and some work on the CentOS side but
> > nothing hard and we expect to be able to migrate the first volunteer 
> > projects by
> > early next week.
> > 
> > Once the first migrations have happened and the first rough edges have been
> > smoothed we will be announcing an official retirement date for
> > jenkins.fedorainfracloud.org and migrate all the projects hosted there to
> > ci.centos.org, and of course help with the potential questions raising from
> > this.
> 
> Will there be a standard / automated migration path for projects that
> have followed documented steps to implement a CI workflow through this
> Jenkins instance, like these:
> 
> https://docs.pagure.org/pagure/usage/pagure_ci_jenkins.html

Having access to the DB we can easily find out which projects are using
jenkins.fic.o and once the migration is figured out and done, adjust the jenkins
URL for these in the DB to make the entire process not require any intervention.

Thanks for pointing it out, it's a good point :)


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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build


On 10.1.2018 03:16, Nick Coghlan wrote:

On 10 January 2018 at 11:30, Jason L Tibbitts III  wrote:

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.


Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look something like:

 PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
 PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning


This sounds good to me. It didn't occur to me that we can actually set a 
dedicated env vars for our builds (which is even better).


This would potentially even make it possible to push this patch to upstream.


Then either Koji can take care of setting that (and including it in
the mock configs it generates), or else it can be included in some of
the Fedora specific RPM setup.

Cheers,
Nick.

P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1532908] perl-SQL-Translator-0.11024 is available