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

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

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

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

2018-01-10 Thread Stephen John Smoogen

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

2018-01-10 Thread Stephen John Smoogen

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

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

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

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

2018-01-10 Thread Stephen John Smoogen

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

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

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

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

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. workaround) on doing so, which is based only on
> o

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 relationship with the

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

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

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

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

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

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