Re: [HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 03, 2018 at 04:21:12PM +, Petr Pisar wrote:
> On 2018-11-28, Igor Gnatenko  wrote:
> > the removal of glibc-all-langpacks from the buildroot[0] is done.
> > Standard buildroot has decreased from 445 to 237 megabytes in
> > installed size ;)
> >
> That's nice, but Koji builders have not been reconfigured away from
> LANG=en_US.UTF-8 and that means that all builds run in C (not C.UTF-8)
> locale now and e.g. every Perl package build spits a warning like this:
> 
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "en_US.UTF-8"
> are supported and installed on your system.
> 
> Example
> .

https://pagure.io/releng/issue/7962

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Net-IDN-Encode-2.400-7.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b2c056d6b0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: [HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead

[Peter Robinson]

> * Petr Pisar  [2018-12-03 11:24]:
> > On 2018-11-28, Igor Gnatenko  wrote:
> > > the removal of glibc-all-langpacks from the buildroot[0] is done.
> > > Standard buildroot has decreased from 445 to 237 megabytes in
> > > installed size ;)
> > >
> > That's nice, but Koji builders have not been reconfigured away from
> > LANG=en_US.UTF-8 and that means that all builds run in C (not C.UTF-8)
> > locale now and e.g. every Perl package build spits a warning like this:
> >
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> >   LANGUAGE = (unset),
> >   LC_ALL = (unset),
> >   LANG = "en_US.UTF-8"
> > are supported and installed on your system.
> >
> > Example
> > .
>
> This is even causing some of my builds to fail because some cmake
> variables (CMAKE_SYSTEM_PROCESSOR below) end up containing a warning:
>
>   -- Found assembler: /usr/bin/clang
>   CMAKE_SYSTEM_PROCESSOR: _bin_sh: warning: setlocale: LC_ALL: cannot 
> change locale (en_US.UTF-8)
>   x86_64
>   CMake Error at functions.cmake:7 (message):
> Only AMD64, ARM64 and ARM are supported
>   Call Stack (most recent call first):
> CMakeLists.txt:175 (clr_unknown_arch)
>
> What's the correct way to disable this "setlocale: LC_ALL: cannot change
> locale (en_US.UTF-8)" warning? What environment variables should I be
> (un)setting when building in koji? Or should I install a langpack
> instead?

I suspect the proper fix will be in the cmake-rpm-macros package so
that it's fixed in a central location for all cmake consumers.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1475784] Useless dependency on perl(Email::Address)

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Email-MessageID-1.406- |perl-Email-MessageID-1.406-
   |10.fc30 |10.fc30
   ||perl-Email-MessageID-1.406-
   ||10.fc29
 Resolution|--- |ERRATA
Last Closed||2018-12-06 21:38:45



--- Comment #5 from Fedora Update System  ---
perl-Email-MessageID-1.406-10.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Octave 4.4 update coming soon to rawhide

[Orion Poplawski]

On 12/4/18 11:10 PM, Vascom wrote:

I am want rpm, not module.


The module provides rpms.  What's the difference?


ср, 5 дек. 2018 г. в 00:38, José Abílio Matos :


On Tuesday, 4 December 2018 13.09.16 WET Vascom wrote:

What about Octave 4.4. for F29?


It is already there, although hidden (in a sense). :-)
BTW the same applies for F28.
Octave 4.4 is available as module.

See http://lists.gnu.org/archive/html/octave-maintainers/2018-11/msg00117.html

Basically you need to run as root:

# dnf module install octave:4.4
# dnf module enable octave:4.4

and then if you already have octave installed:

# dnf upgrade

or if you do not:

#dnf install octave

I had to find these instructions by myself when Orion released the update as
it was the first time that I had to explicitly deal with modules.
--
José Abílio

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org




--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Hi. i wish to contribute

[Suraj Rajendra Patil]

Hi, my name is Suraj and I have an idea for an article which is Linux commands
im newbie to this word please guide me with proper steps . im very enthusiastic 
person to
start contribute to my favorite os that is fedora 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Neal Gompa]

On Thu, Dec 6, 2018 at 7:59 AM Florian Weimer  wrote:
>
> * Neal Gompa:
>
> > The problem with merged source trees (aka source-git) is that it
> > implies forking projects.
>
> But that's true for *any* distribution that wants to integrate things.
> I guess you could govern everything by build flags eventually, but
> upstreams will rarely be willing to backport those to older branches
> (if they even have release branches as such).
>
> > It's an easy trap to start having vendor trees and maintain your own
> > functionality independent from upstream.
>
> And how does the current dist-git prevent that?  I know packages which
> have managed to fall into the fork trap even with dist-git.
>

Sure, fork traps and such do still happen, but they're a lot rarer
because that is much more painful with our current packaging model.
It's a lot more obvious that package is in bad shape when it has ~100+
patches and is hard to rebase than it is when you have Git trees and
can just do merges all the time. Once you've done merges, it becomes
impossible to sort out.

> > Fundamentally, I don't want having patches to be too easy, because
> > then people _will_ do that. Fedora should strive to remain close to
> > upstream projects and interact with them to make things better[1].
>
> To be honest, that's an awful attitude.
>
> Do you want me to spend time on packaging work instead of glibc
> maintenance?  Do you really think that's a good use of my time?
>

I think that if you're maintaining large patch sets that you might
want to consider talking to upstream about doing more releases. If
glibc has so many problems that this becomes an issue even with the
short life cycle in Fedora, then maybe upstream needs to reconsider
its release model a bit and do more frequent releases per version
series. Actually, does it even do that now? I'm not actually sure...

> Do you really think an unavoidable conflict each time you merge parallel
> development into a source RPM provides value?
>
> > And the thing is, it's not like I'm unfamiliar with merged source
> > models. I've worked in distributions that operated that way, and the
> > consequence is almost always that things are patched and changed
> > without ever interacting with upstream. Of course, that's their choice
> > to do so, but most distributions do not have "upstream-first" as a
> > specific goal.
>
> We do that in Fedora, too.
>
> A recent example is the switch to the C.UTF-8 locale, which is not
> upstream *at all*.  It was pointed out at the time, and the issue was
> completely ignored.
>

My understanding is that we allowed the feature in because it was
actively being shepherded into glibc upstream. However, shortly after
it was included in Fedora, the change owners stopped working on it
upstream (from what I can tell). As a consequence, the C.UTF-8 locale
is probably what I would consider one of our biggest failures. It's
present in Fedora, openSUSE, Debian, and now Mageia. But it isn't
present upstream. No one is working on it upstream, and I have very
little hope for the developers of that locale to finish the job they
started.

We do not usually screw up that badly in the distribution in such a
way that we have such a deviation from upstream and simultaneously
stop working on upstreaming the change or consider to drop it because
it isn't being upstreamed.

> > In addition, it may seem like it makes things easier (and maybe
> > faster), but it actually makes things much harder and slower for
> > everyone else. Merged source trees make it so that it's stupid easy to
> > have light forks of everything, which means people will just patch and
> > change things without consequence. That makes it much harder to
> > identify changes for rebasing to newer versions, what's safe to drop,
> > and so on.
>
> That's just a matter of tooling.  A lot of information can be recovered
> from Git history, and it's going to be easier to do this in a single
> repository than with copied patches, without tooling that enforces that
> the patches actually contain what they say.
>

It's a lot clearer that patch files applied to a tarball are
distinctly packager things vs a cacophony of changes from upstream and
downstream mixed together. Aside from the rdopkg triple-repo process
that Ken brought up in the thread, I don't know of any clean process
for making these changes identifiable.

> The point is to keep that history around.  With the current model, the
> information might theoretically be available somewhere, but with the
> split between Fedora, branches, wildly differing patch management
> practices, in addition to all the upstream differences we encounter,
> it's extremely difficult to recover.
>
> In a sense, it's the old discussion between explicit rename recording
> and rename detection.  I think it's clear by now that rename detection
> has won.
>

That is not the same thing. This is about sorting out who did what and
why, not what happened.



-- 
真実はいつも一つ！/ Always, there's only one 

Re: Fedora Lifecycles: imagine longer-term possibilities

[Neal Gompa]

On Thu, Dec 6, 2018 at 3:54 PM Ken Dreyer  wrote:
>
> On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer  wrote:
> > I'm worried that this kind of pointless work makes it hard to attract
> > talent.
>
> Florian, you might want to check out rdopkg.
> https://github.com/softwarefactory-project/rdopkg . It's a bit like
> fedpkg, in that it's a CLI with sub-commands.
>
> The idea is that you have three Git remotes:
>
> originssh://ktdre...@pkgs.fedoraproject.org/rpms/remctl
> patchesg...@example.com:ktdreyer/remctl
> upstreamhttps://git.eyrie.org/git/kerberos/remctl.git
>
> The "origin" is dist-git, the "upstream" is obviously the upstream
> project, and the "patches" remote is a fork of upstream.
>
> You can maintain all your backports and cherry-picks in the "patches"
> remote, in "-patches" branches. So for rawhide, the dist-git branch is
> "master", so the patches branch would be "master-patches". This branch
> is the upstream point release tag, plus any downstream cherry-picks.
>
> The "rdopkg patch" command will automatically run git-format-patch
> with the proper commit range and inject the patch series into the
> .spec file. It will update the %changelog and dist-git commit message
> as well.
>
> We use that to maintain several hundred cherry-picks across many
> different releases of Ceph. The RDO teams use it to help maintain over
> 800 packages. (I have "rdopkg patch" running in Jenkins also, so the
> rest of my team can just do "git cherry-pick -x" for their backports
> and not have to touch packaging or dist-git.)
>
> We get the strong history preservation guarantees that dist-git always
> gives us, along with the flexibility to rebase or edit patch series
> quickly. The patches remote can live anywhere. It is similar to
> Debian's patch-queue concept from git-buildpackage.
>
> Even if you maintain a package in Fedora that has just one or two
> patches, it is really handy to use rdopkg to manage that. You can jump
> back and forth between the "-patches" branch and the dist-git branch.
> The ability to quickly rebase or amend patches makes packaging fun
> again (for me anyway :)
>

I consider rdopkg a nice compromise between the differing models. It's
a shame that rdopkg is behind the terrible contribution process that
is RDO/OpenStack (gerrit, though at least that's better than mail
queues), otherwise it'd replace my existing tooling for maintaining my
more complex packages. I also quibble a bit about it being licensed
ASL 2.0 (as that makes it tricky to integrate with the rest of my
tooling), but meh.

The rdopkg model also permits working with the native VCS, whatever it
may be (Git, Mercurial, etc.), while still exporting cleanly to
Dist-Git. It also doesn't require us to actually support all the
necessary Git features for Git repos in Pagure today.

In fact, I had been discussing with the rdopkg author the idea of
using it for Mageia a couple years ago to replace mgarepo, though
unfortunately he disappeared off the face of the earth after our first
conversations, so that never went anywhere.


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Rawhide-20181206.n.0 compose check report

[Adam Williamson]

On Thu, 2018-12-06 at 15:25 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Compose FAILS proposed Rawhide gating check!
> 5 of 47 required tests failed
> openQA tests matching unsatisfied gating requirements shown with **GATING** 
> below

So - this is a new feature of check-compose I wrote yesterday :)

As part of the 'NoMoreAlpha' change from a few releases back:

https://fedoraproject.org/wiki/Changes/NoMoreAlpha

we planned to start gating Rawhide composes - only syncing them out to
become the current public state of the 'Rawhide' tree if they pass some
subset of the automated compose tests. However, this has not yet been
implemented.

An initial gating policy was actually committed to the Fedora Greenwave
config some months back by Ralph Bean, and since then it's been
possible to ask Greenwave whether a given compose passes or fails the
policy - but nothing was hooked up beyond that; no-one's been doing
anything with that information.

Ultimately the idea is that the Greenwave decision should be hooked
into the compose sync process, but I thought before we go that far,
it'd be useful to know just how often composes actually *do* meet the
requirements. So I enhanced check-compose to request the decision from
Greenwave and include it in the output, like this. This should help us
get an idea just how often we'd be refusing to sync composes if we
turned gating on.

The failures that fail the gating check today are down to
https://bugzilla.redhat.com/show_bug.cgi?id=1654537 and the Everything
netinst tests for both x86_64 and UEFI failing because of the network
not being up in the guest for some reason. The FreeIPA bug I'm hopeful
we can get fixed soon, I'm not sure what's going on with the netinst
failure, I'll have to look into that. (It's a bit tricky because, when
the network in the guest doesn't work, we don't get any logs from the
test...)

Eagle-eyed readers may not a slight bug in the new feature: Greenwave
reports *5* failed requirements, but the details below show only *4*
tests with **GATING**. This is because the other failed test - the
FreeIPA server test - doesn't show up in the check-compose output for
some reason. If you re-run check-compose now, it *does* show up, so
this is likely some kind of ordering issue to do with exactly what
state that job is in when check-compose runs (my working theory is that
it's in 'uploading' state - that could cause it to fall between some
code cracks). I'll see if I can fix that.

Thanks folks!
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Ken Dreyer]

On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer  wrote:
> I'm worried that this kind of pointless work makes it hard to attract
> talent.

Florian, you might want to check out rdopkg.
https://github.com/softwarefactory-project/rdopkg . It's a bit like
fedpkg, in that it's a CLI with sub-commands.

The idea is that you have three Git remotes:

originssh://ktdre...@pkgs.fedoraproject.org/rpms/remctl
patchesg...@example.com:ktdreyer/remctl
upstreamhttps://git.eyrie.org/git/kerberos/remctl.git

The "origin" is dist-git, the "upstream" is obviously the upstream
project, and the "patches" remote is a fork of upstream.

You can maintain all your backports and cherry-picks in the "patches"
remote, in "-patches" branches. So for rawhide, the dist-git branch is
"master", so the patches branch would be "master-patches". This branch
is the upstream point release tag, plus any downstream cherry-picks.

The "rdopkg patch" command will automatically run git-format-patch
with the proper commit range and inject the patch series into the
.spec file. It will update the %changelog and dist-git commit message
as well.

We use that to maintain several hundred cherry-picks across many
different releases of Ceph. The RDO teams use it to help maintain over
800 packages. (I have "rdopkg patch" running in Jenkins also, so the
rest of my team can just do "git cherry-pick -x" for their backports
and not have to touch packaging or dist-git.)

We get the strong history preservation guarantees that dist-git always
gives us, along with the flexibility to rebase or edit patch series
quickly. The patches remote can live anywhere. It is similar to
Debian's patch-queue concept from git-buildpackage.

Even if you maintain a package in Fedora that has just one or two
patches, it is really handy to use rdopkg to manage that. You can jump
back and forth between the "-patches" branch and the dist-git branch.
The ability to quickly rebase or amend patches makes packaging fun
again (for me anyway :)

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Lennart Poettering]

On Do, 06.12.18 19:42, Florian Weimer (fwei...@redhat.com) wrote:

> >> Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
> >> happen some ID overlaps with FreeIPA/Samba which is undesirable. I would 
> >> say
> >> that this must be solves if this module is enabled by default. Was there 
> >> any
> >> progress in this area?
> >
> > I think that's a misunderstanding of what the module does. At the
> > point the module announces those uid/gid ranges they are already
> > reserved, hence the conflict is already there. nss-mymachines is hence
> > only the messanger, not the culprit.
>
> I don't think we enforce that reservation system-wide.  Do we filter out
> those accounts when they come in over LDAP?  Can users add them locally
> using adduser?
>
> None of the NSS modules in glibc provide such filtering.

The UID/GID allocation in systemd itself (for DynamicUser=1) and in
systemd-nspawn (for --private-users=) both check NSS before they take
a UID/GID. Hence, if LDAP users live in the same range we use it makes
the space scarcer, but it shouldn't cause conflicts — as long as
everything is properly registered in NSS.

"adduser" registers from the range 1000…6 on Fedora by
default. DynamicUser=1 uses the range 61184…65519. systemd-nspawn uses
524288…1879048191. So these at least do not overlap.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Florian Weimer]

* Lennart Poettering:

> On Do, 06.12.18 14:58, Pavel Březina (pbrez...@redhat.com) wrote:
>
>> > Then there is nss-mymachines. It's primarily useful if
>> > systemd-machined or systemd-nspawn is used. Given that those are now
>> > part of the 'systemd-container' RPM it would be OK to also add
>> > nss-mymachines to nsswitch.conf only when the RPM is installed, if
>> > there's a concept for that. That said, in order to simplify things,
>> > and given that systemd is a very core part of the OS I'd personally
>> > just put it statically in nsswitch.conf too by default. After all a
>> > missing NSS module listed in nsswitch.conf is just skipped, hence this
>> > should not matter. This module should be in the 'passwd', 'group' and
>> > 'hosts' lines.
>>
>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
>> happen some ID overlaps with FreeIPA/Samba which is undesirable. I would say
>> that this must be solves if this module is enabled by default. Was there any
>> progress in this area?
>
> I think that's a misunderstanding of what the module does. At the
> point the module announces those uid/gid ranges they are already
> reserved, hence the conflict is already there. nss-mymachines is hence
> only the messanger, not the culprit.

I don't think we enforce that reservation system-wide.  Do we filter out
those accounts when they come in over LDAP?  Can users add them locally
using adduser?

None of the NSS modules in glibc provide such filtering.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Florian Weimer]

* Petr Pisar:

> On 2018-12-06, Florian Weimer  wrote:
>> In a sense, it's the old discussion between explicit rename recording
>> and rename detection.  I think it's clear by now that rename detection
>> has won.

> Can you give us some example of a rename detection that works?

I meant file system rename detection.  Nothing works perfectly.  But any
system only needs to beet the accuracy of the information that
developers record manually, and that is a more tractable problem.

> If a packager cherry-picks patches, he looses upstream's commit IDs. If
> an upstream uses non-descriptive commit messages (e.g. five commits with
> the same "A bug fix" subject), commit messages are not uniq. If the
> packager needs to ammend patches (the commit bodies) to resolve conflicts
> (i.e. porting back the fixes by rebasing the patches), the code changes
> are not uniq. If an upstream releases a new version after a year, the
> packager won't probably remember all the cherry-picked fixes.
>
> How can a packager identify which commits originates from the upstream
> and which are uniq to Fedora and must be carried across rebases to
> a new release?

Without tooling?  The same way as today.  Look at the commit and see if
it is upstream, using commit subject, author email and date for fuzzy
matching if necessary, and commit IDs if listed in the commit message.

Even that's an improvement over what people record in patch files today.
Without -x, git cherry-pick will not immediately mangle the subject,
email and date.  With -x, you have the commit ID (but which may not be
reliable if it comes from the wrong branch).

Tooling can do better and look at the actual changes to match them with
seemingly unrelated upstream changes.

> A tempting answer could be use merge-commits extensively. However, would
> that really help? I must admit I'm not fond of merge-commits and I don't
> have much experience with them.

You could merge in the upstream history with the remaining
downstream-specific patches on top, yes.  But it's not necessary to do
it this way.

> If I imagine a dist-git tree full of intermingled upstream and Fedora
> commits, I don't know how I as a packager would package a new upstream
> release. Should I just blindy believe in "git merge"? I have a few bad
> experiences with git losing diff chunks on the way. How could I keep
> the packaging accountable and verifiable?

At the minimum: git merge plus diff against the upstream, to see what
downstream changes remain.  And then perhaps add new commits to revert
spurious differences from upstream.  Or use the “merge the rebased tree”
approach I mentioned.

The interesting question is whether we'd preserve that history
downstream, when rebasing.  Historically, it's a full rebase to Fedora
for almost all packages, and it's up to package maintainers to
re-instantiate all the downstream customization.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction David Schwörer

[Christopher Brown]

On Thu, Dec 6, 2018 at 5:28 PM David Schwörer  wrote:

>  This will make Fedora an even more
> attractive OS for Fusion Physicists.
>

Wow, welcome David!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[Dusty Mabe]

On 12/6/18 6:20 AM, arnaud gaboury wrote:
> 
> 
> On Wed, Dec 5, 2018 at 4:13 PM Dusty Mabe  > wrote:
> 
> 
> 
> On 12/5/18 5:14 AM, arnaud gaboury wrote:
> >
> >
> > On Tue, Dec 4, 2018 at 6:57 PM Dusty Mabe    >> wrote:
> >
> >
> >
> >     On 12/4/18 11:40 AM, Dusty Mabe wrote:
> >
> >     >
> >     > I will look at the configs and see if I can figure out where 
> things are going wrong.
> >     >
> >
> >     I think this a a regression is some of the new yaml parsing in 
> pungi. I opened a bug
> >     to see https://pagure.io/pungi/issue/1092
> >
> >     The updates-testing runs are running right after the updates runs 
> and overwriting the ref.
> >     For now we can disable updates-testing composes for silverblue so 
> that it won't overwrite
> >     the updates run.
> >
> >     Here is a PR for that:
> >     
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/
> >
> >     Dusty
> >
> >
> > My issue has been solved and could upgrade
> 
> Yep. We put in a workaround yesterday. We should be good now. Sorry about 
> that.
> 
> 
> Don't be sorry and be proud for your very quick action and for the good work 
> you do with this wonderful distro.

Thanks! It's an incredible team of people that help pull it off. I'm thankful 
for everyone who contributes!

Dusty 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead

[Omair Majid]

* Petr Pisar  [2018-12-03 11:24]:
> On 2018-11-28, Igor Gnatenko  wrote:
> > the removal of glibc-all-langpacks from the buildroot[0] is done.
> > Standard buildroot has decreased from 445 to 237 megabytes in
> > installed size ;)
> >
> That's nice, but Koji builders have not been reconfigured away from
> LANG=en_US.UTF-8 and that means that all builds run in C (not C.UTF-8)
> locale now and e.g. every Perl package build spits a warning like this:
> 
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LANG = "en_US.UTF-8"
> are supported and installed on your system.
> 
> Example
> .

This is even causing some of my builds to fail because some cmake
variables (CMAKE_SYSTEM_PROCESSOR below) end up containing a warning:

  -- Found assembler: /usr/bin/clang
  CMAKE_SYSTEM_PROCESSOR: _bin_sh: warning: setlocale: LC_ALL: cannot 
change locale (en_US.UTF-8)
  x86_64
  CMake Error at functions.cmake:7 (message):
Only AMD64, ARM64 and ARM are supported
  Call Stack (most recent call first):
CMakeLists.txt:175 (clr_unknown_arch)

What's the correct way to disable this "setlocale: LC_ALL: cannot change
locale (en_US.UTF-8)" warning? What environment variables should I be
(un)setting when building in koji? Or should I install a langpack
instead?

Thanks,
Omair

-- 
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging FOSS that requires MATLab at runtime

[Przemek Klosowski]

On 12/3/18 8:48 AM, Ankur Sinha wrote:

On Mon, Dec 03, 2018 12:41:41 +0100, Kevin Kofler wrote:

Since correctness is really important here, if upstream does not test
the toolboxes against Octave, we shouldn't either

I think that if it runs at all, we should ship it.

Some upstreams seem pretty conservative. E.g., SPM seems to have done a lot
of work on Octave compatibility already, and the page seems to imply that it
will more or less work, with some issues, they just do not support it still.
Fedora, in contrast, is a forward-looking distribution that is about
shipping Features First and with Freedom (i.e., no MATLAB!) included.

No, I disagree with this.


I assume that the package you propose would work with Octave and Matlab 
co-installed. If it didn't, I would think it would be unacceptable, 
because it would effectively be evicting Octave.


It seems to me that there has to be some sort of O.vs.M. configuration, 
so people who don't want to take the risk can still use the Matlab 
setup. We are not making life harder for those folks: they have to 
manually install Matlab regardless whether the package Requires Octave 
or not.




These are not user-end applications where an
annoying bug may be fixed in a future release and make everyone happy.
These are toolboxes that are used for analyses of data, and the results
from the analyses contribute to science. Then, other studies will build
on these results, and so on. If there's any hint of lack of correctness,
being conservative makes sense---it is too much of a risk. A minor issue
can undo years of work and progress.

It would be very bad if an issue in our provision of the toolbox with
Octave resulted in a retraction, later on, for example.
[...]
If a researcher uses a MATLab toolbox with Octave, it is their
responsibility to check for correctness. If we provide them, it is ours,
and this is not a responsibility we have the man power to take on. We'd
rather rely on upstream.


Software licenses usually claim that "the customer is solely responsible 
for selecting the software and determining the software’s suitability 
for the customer’s particular purpose". I would not be surprised if 
Matlab license contained a similar clause, and the researchers should 
check for correctness anyway.



I think that if it runs at all, we should ship it.


It seems to me that 'runs at all' is too low of a bar; I would 
personally prefer that it passes some regression tests. Providing such 
tests, which presumably would also allow people to sanity-check against 
both back ends, would be a nice added value for both end users and for 
Fedora.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Lennart Poettering]

On Do, 06.12.18 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> > I wonder if we should think of a tighter system integration and subsume
> > the tasks of nss_machines into SSSD.
> > It would allow for detection and logging of UID conflicts should they
> > happen in a live system with the ability, for the admin to better
> > choose which of the pools should have priority in case of conflict ...
>
> Integration with sssd could be useful, dunno. But nss modules only report
> existing usage of uids on the system. So by the time the nss modules are
> invoked, it's already too late, in the sense that two completely unrelated
> entities are sharing the user, possibly leading to unintended privilege
> augmentation or information leakage. Nss modules are not useful to "choose"
> anything.

Yes, I agree fully. Announcing allocated users with NSS is one thing,
it's something we always should do, unconditionally. It's only
reasonably way to announce you took possession of a range. Actually
allocating ranges is a different discussion. It's a discussion worth
having, but is unrelated from the NSS discussion I think.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Valgrind and Fedora debuginfo: best GUI

[Jan Kratochvil]

On Thu, 06 Dec 2018 11:59:35 +0100, Germano Massullo wrote:
> This seems to not happen with Valgrind

I would first suggest using compiler option -fsanitize=address instead of
valgrind.


Jan Kratochvil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Lennart Poettering]

On Do, 06.12.18 11:25, Simo Sorce (s...@redhat.com) wrote:

> > > Summary: I'd make things simple, and enable all four unconditionally
> > > and by default without any dynamic infrastructure, without postinst
> > > scripts or anything. If that's not acceptable, then at least two of the
> > > four should be unconditionally enabled.
> >
> > I also think we should "enable" them unconditionally, in the sense that
> > they should be configured in the default /etc/nsswitch.conf configurations.
> > As Lennart wrote, if the module is not installed in the filesystem, that
> > configuration has no effect. And if it is installed, but talks to an
> > inactive service, it has almost no effect too (apart from the linkage
> > and small runtime overhead). "Enabling" them in one consistent way in
> > the normal distro configuration seems much better to me then patching
> > it in, in a slightly different way on each installation.
> >
> > In QA the subject of reducing the test matrix often comes up. This is
> > a nice opportunity: let's avoid having a nsswitch line that depends on
> > the installation order.
> >
> > --
> >
> > Also, we are not talking about whether those modules are active or not.
> > They *already* *are*, on any Fedora system where the configuration was
> > not overridden and the right packages are installed. The question is
> > *how* they should be enabled: either through the installed file or through
> > rpm scriptlets. Without those modules, too much stuff breaks, so disabling
> > them is not a realistic option.
>
> I wonder if we should think of a tighter system integration and subsume
> the tasks of nss_machines into SSSD.
> It would allow for detection and logging of UID conflicts should they
> happen in a live system with the ability, for the admin to better
> choose which of the pools should have priority in case of conflict ...

No disrespect, but think this would mean the layering is the wrong way
round: sssd is an add-on currently, a layer above systemd. systemd as
the lower layer really shouldn't call into higher layer stuff for
registering UIDs/GIDs. I mean, conceptually, higher level stuff should
call into lower level stuff but not the other way round. (And there's
also the problem that sssd is hardly universally accepted. systemd
probably runs on more systems not using sssd than on those using
sssd.)

Currently Linux has no nice protocol for registering UIDs or UID
ranges. In systemd we tried to make the best from what we got, and
what the layers underneath permit us (i.e. glibc NSS):

1. we always register the IDs we take possession of in NSS, to make
   sure that it can be used as a comprehensive database of UID
   registrations. (That's what the nss modules mentioned in my earlier
   mail are about after all).

2. When picking a UID we check with NSS first if the UID is already
   taken.

3. When picking a UID we also check if any IPC object is already owned
   by the UID.

4. When checking whether UID is used we take the lckpwdf() lock first
   (if we can, since its in /etc, i.e. potentially read-only), in
   order to serialize registration. This sucks a bit admittedly, since
   strictly speaking that lock is just about the file-based database
   (i.e. /etc/passwd and friends). But it's the best there is, and it
   is official glibc API.

We also documented in a lot of detail the UID/GID range assumptions we
make:

https://systemd.io/UIDS-GIDS

I think it would be great if we could come to a better protocol for
taking possession of UID ranges in the long run. But I still think the
best database for such allocation should be NSS itself, right
now. What would be great if we'd at least agree on a better lock file
though, maybe in /run. And maybe some rules that when you allocate
long UID ranges at once (like container managers do), that you only
have to NSS check key UIDs from it.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1656896] Upgrade perl-Mail-IMAPClient to 3.40

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-12-06 11:48:43



--- Comment #1 from Tom "spot" Callaway  ---
perl-Mail-IMAPClient-3.40-1.fc30 is now in rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 06, 2018 at 11:25:04AM -0500, Simo Sorce wrote:
> On Thu, 2018-12-06 at 16:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Dec 06, 2018 at 02:36:36PM +0100, Lennart Poettering wrote:
> > > On Do, 06.12.18 12:20, Pavel Březina (pbrez...@redhat.com) wrote:
> > > 
> > > > Hello,
> > > 
> > > Heya!
> > > 
> > > > systemd and nss-mdns packages modifies nsswitch.conf in their %post
> > > > scriptlets which creates conflicts with authselect on systems that are
> > > > configured by authselect. This needs to be solved somehow.
> > > > 
> > > > Originally, I wanted to create an authselect command that can be used by
> > > > packages on systems that are configured by authselect and on systems 
> > > > that
> > > > are configured with different ways [1]. But it turned out that there are
> > > > only two packages that touches nsswitch.conf so I do not think this is
> > > > necessary.
> > > > 
> > > > I prepared initial design document with multiple solutions that came to 
> > > > my
> > > > mind [2] and I would like to discuss this with the community to see 
> > > > what is
> > > > the correct and desired way to solve this.
> > > 
> > > nss-systemd should be in nsswitch.conf by default. It's required for
> > > systemd's DynamicUser=1 option to work correctly, and that's core
> > > service functionality. Hence, given that systemd is Fedora's PID 1,
> > > nss-systemd should also be in nsswitch.conf unconditionally (in the
> > > 'passwd' and 'group' lines). A system where nss-systemd is not enabled
> > > is simply broken right now.
> > > 
> > > nss-myhostname should be in nsswitch.conf by default too. It's very
> > > minimal, and just makes sure the local hostname remains resolvable all
> > > the time. By enabling this, installers and image generators don't have
> > > to patch /etc/hosts anymore like they traditionally did, in fact they
> > > can remove it altogether and just leave resolution of the local
> > > hostname to the module, and it will magically follow whatever is
> > > currently set via sethostname(). This module should be in the 'hosts'
> > > line.
> > > 
> > > Then there is nss-mymachines. It's primarily useful if
> > > systemd-machined or systemd-nspawn is used. Given that those are now
> > > part of the 'systemd-container' RPM it would be OK to also add
> > > nss-mymachines to nsswitch.conf only when the RPM is installed, if
> > > there's a concept for that. That said, in order to simplify things,
> > > and given that systemd is a very core part of the OS I'd personally
> > > just put it statically in nsswitch.conf too by default. After all a
> > > missing NSS module listed in nsswitch.conf is just skipped, hence this
> > > should not matter. This module should be in the 'passwd', 'group' and
> > > 'hosts' lines.
> > > 
> > > Finally, there's nss-resolve. It's the client side to
> > > systemd-resolved. It's the client side to systemd-resolved's
> > > DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
> > > Fedora right now. Quite frankly I think it should be, but that's another
> > > political discussion (and I am not sure I am ready to have it right
> > > now). The module is benign though: if resolved is not running it
> > > doesn't do anything. It only does its thing if resolved is
> > > running. Thus I'd also suggest to just enable it by default, and
> > > simplify things because then people can use resolved just by doing
> > > "systemctl enable systemd-resolved" and don't need to do anything
> > > else. This module should be in the 'hosts' line.
> > > 
> > > Summary: I'd make things simple, and enable all four unconditionally
> > > and by default without any dynamic infrastructure, without postinst
> > > scripts or anything. If that's not acceptable, then at least two of the
> > > four should be unconditionally enabled.
> > 
> > I also think we should "enable" them unconditionally, in the sense that
> > they should be configured in the default /etc/nsswitch.conf configurations.
> > As Lennart wrote, if the module is not installed in the filesystem, that
> > configuration has no effect. And if it is installed, but talks to an
> > inactive service, it has almost no effect too (apart from the linkage
> > and small runtime overhead). "Enabling" them in one consistent way in
> > the normal distro configuration seems much better to me then patching
> > it in, in a slightly different way on each installation.
> > 
> > In QA the subject of reducing the test matrix often comes up. This is
> > a nice opportunity: let's avoid having a nsswitch line that depends on
> > the installation order.
> > 
> > --
> > 
> > Also, we are not talking about whether those modules are active or not.
> > They *already* *are*, on any Fedora system where the configuration was
> > not overridden and the right packages are installed. The question is
> > *how* they should be enabled: either through the installed file or through
> > rpm scriptlets. Without those modules, too much stuff breaks, so 

Self Introduction David Schwörer

[David Schwörer]

Hi all,

My name is David Schwörer, and I am a PhD Student in Ireland and have
been using Fedora for many years, and would like to contribute to Fedora.

I am one of the upstream developers of BOUT++, a library to write fluid
and plasma simulations in curvilinear geometry. BOUT++ is a C++ library
that allows to implement close to analytic equations in C++ or python.
Various time solvers are available to evolve the system of equation.

I have been using BOUT++ for a while now, and think it would be nice if
it would be available in Fedora. This will make Fedora an even more
attractive OS for Fusion Physicists.

Review Request:
https://bugzilla.redhat.com/show_bug.cgi?id=1519834

I am looking for a sponsor, so I can become the maintainer of this package.

Kind Regards,
David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Simo Sorce]

On Thu, 2018-12-06 at 16:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Dec 06, 2018 at 02:36:36PM +0100, Lennart Poettering wrote:
> > On Do, 06.12.18 12:20, Pavel Březina (pbrez...@redhat.com) wrote:
> > 
> > > Hello,
> > 
> > Heya!
> > 
> > > systemd and nss-mdns packages modifies nsswitch.conf in their %post
> > > scriptlets which creates conflicts with authselect on systems that are
> > > configured by authselect. This needs to be solved somehow.
> > > 
> > > Originally, I wanted to create an authselect command that can be used by
> > > packages on systems that are configured by authselect and on systems that
> > > are configured with different ways [1]. But it turned out that there are
> > > only two packages that touches nsswitch.conf so I do not think this is
> > > necessary.
> > > 
> > > I prepared initial design document with multiple solutions that came to my
> > > mind [2] and I would like to discuss this with the community to see what 
> > > is
> > > the correct and desired way to solve this.
> > 
> > nss-systemd should be in nsswitch.conf by default. It's required for
> > systemd's DynamicUser=1 option to work correctly, and that's core
> > service functionality. Hence, given that systemd is Fedora's PID 1,
> > nss-systemd should also be in nsswitch.conf unconditionally (in the
> > 'passwd' and 'group' lines). A system where nss-systemd is not enabled
> > is simply broken right now.
> > 
> > nss-myhostname should be in nsswitch.conf by default too. It's very
> > minimal, and just makes sure the local hostname remains resolvable all
> > the time. By enabling this, installers and image generators don't have
> > to patch /etc/hosts anymore like they traditionally did, in fact they
> > can remove it altogether and just leave resolution of the local
> > hostname to the module, and it will magically follow whatever is
> > currently set via sethostname(). This module should be in the 'hosts'
> > line.
> > 
> > Then there is nss-mymachines. It's primarily useful if
> > systemd-machined or systemd-nspawn is used. Given that those are now
> > part of the 'systemd-container' RPM it would be OK to also add
> > nss-mymachines to nsswitch.conf only when the RPM is installed, if
> > there's a concept for that. That said, in order to simplify things,
> > and given that systemd is a very core part of the OS I'd personally
> > just put it statically in nsswitch.conf too by default. After all a
> > missing NSS module listed in nsswitch.conf is just skipped, hence this
> > should not matter. This module should be in the 'passwd', 'group' and
> > 'hosts' lines.
> > 
> > Finally, there's nss-resolve. It's the client side to
> > systemd-resolved. It's the client side to systemd-resolved's
> > DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
> > Fedora right now. Quite frankly I think it should be, but that's another
> > political discussion (and I am not sure I am ready to have it right
> > now). The module is benign though: if resolved is not running it
> > doesn't do anything. It only does its thing if resolved is
> > running. Thus I'd also suggest to just enable it by default, and
> > simplify things because then people can use resolved just by doing
> > "systemctl enable systemd-resolved" and don't need to do anything
> > else. This module should be in the 'hosts' line.
> > 
> > Summary: I'd make things simple, and enable all four unconditionally
> > and by default without any dynamic infrastructure, without postinst
> > scripts or anything. If that's not acceptable, then at least two of the
> > four should be unconditionally enabled.
> 
> I also think we should "enable" them unconditionally, in the sense that
> they should be configured in the default /etc/nsswitch.conf configurations.
> As Lennart wrote, if the module is not installed in the filesystem, that
> configuration has no effect. And if it is installed, but talks to an
> inactive service, it has almost no effect too (apart from the linkage
> and small runtime overhead). "Enabling" them in one consistent way in
> the normal distro configuration seems much better to me then patching
> it in, in a slightly different way on each installation.
> 
> In QA the subject of reducing the test matrix often comes up. This is
> a nice opportunity: let's avoid having a nsswitch line that depends on
> the installation order.
> 
> --
> 
> Also, we are not talking about whether those modules are active or not.
> They *already* *are*, on any Fedora system where the configuration was
> not overridden and the right packages are installed. The question is
> *how* they should be enabled: either through the installed file or through
> rpm scriptlets. Without those modules, too much stuff breaks, so disabling
> them is not a realistic option.

I wonder if we should think of a tighter system integration and subsume
the tasks of nss_machines into SSSD.
It would allow for detection and logging of UID conflicts should they
happen in a live system with 

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 06, 2018 at 02:36:36PM +0100, Lennart Poettering wrote:
> On Do, 06.12.18 12:20, Pavel Březina (pbrez...@redhat.com) wrote:
> 
> > Hello,
> 
> Heya!
> 
> > systemd and nss-mdns packages modifies nsswitch.conf in their %post
> > scriptlets which creates conflicts with authselect on systems that are
> > configured by authselect. This needs to be solved somehow.
> >
> > Originally, I wanted to create an authselect command that can be used by
> > packages on systems that are configured by authselect and on systems that
> > are configured with different ways [1]. But it turned out that there are
> > only two packages that touches nsswitch.conf so I do not think this is
> > necessary.
> >
> > I prepared initial design document with multiple solutions that came to my
> > mind [2] and I would like to discuss this with the community to see what is
> > the correct and desired way to solve this.
> 
> nss-systemd should be in nsswitch.conf by default. It's required for
> systemd's DynamicUser=1 option to work correctly, and that's core
> service functionality. Hence, given that systemd is Fedora's PID 1,
> nss-systemd should also be in nsswitch.conf unconditionally (in the
> 'passwd' and 'group' lines). A system where nss-systemd is not enabled
> is simply broken right now.
> 
> nss-myhostname should be in nsswitch.conf by default too. It's very
> minimal, and just makes sure the local hostname remains resolvable all
> the time. By enabling this, installers and image generators don't have
> to patch /etc/hosts anymore like they traditionally did, in fact they
> can remove it altogether and just leave resolution of the local
> hostname to the module, and it will magically follow whatever is
> currently set via sethostname(). This module should be in the 'hosts'
> line.
> 
> Then there is nss-mymachines. It's primarily useful if
> systemd-machined or systemd-nspawn is used. Given that those are now
> part of the 'systemd-container' RPM it would be OK to also add
> nss-mymachines to nsswitch.conf only when the RPM is installed, if
> there's a concept for that. That said, in order to simplify things,
> and given that systemd is a very core part of the OS I'd personally
> just put it statically in nsswitch.conf too by default. After all a
> missing NSS module listed in nsswitch.conf is just skipped, hence this
> should not matter. This module should be in the 'passwd', 'group' and
> 'hosts' lines.
> 
> Finally, there's nss-resolve. It's the client side to
> systemd-resolved. It's the client side to systemd-resolved's
> DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
> Fedora right now. Quite frankly I think it should be, but that's another
> political discussion (and I am not sure I am ready to have it right
> now). The module is benign though: if resolved is not running it
> doesn't do anything. It only does its thing if resolved is
> running. Thus I'd also suggest to just enable it by default, and
> simplify things because then people can use resolved just by doing
> "systemctl enable systemd-resolved" and don't need to do anything
> else. This module should be in the 'hosts' line.
> 
> Summary: I'd make things simple, and enable all four unconditionally
> and by default without any dynamic infrastructure, without postinst
> scripts or anything. If that's not acceptable, then at least two of the
> four should be unconditionally enabled.

I also think we should "enable" them unconditionally, in the sense that
they should be configured in the default /etc/nsswitch.conf configurations.
As Lennart wrote, if the module is not installed in the filesystem, that
configuration has no effect. And if it is installed, but talks to an
inactive service, it has almost no effect too (apart from the linkage
and small runtime overhead). "Enabling" them in one consistent way in
the normal distro configuration seems much better to me then patching
it in, in a slightly different way on each installation.

In QA the subject of reducing the test matrix often comes up. This is
a nice opportunity: let's avoid having a nsswitch line that depends on
the installation order.

--

Also, we are not talking about whether those modules are active or not.
They *already* *are*, on any Fedora system where the configuration was
not overridden and the right packages are installed. The question is
*how* they should be enabled: either through the installed file or through
rpm scriptlets. Without those modules, too much stuff breaks, so disabling
them is not a realistic option.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1656894] Upgrade perl-Config-Model to 2.129

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|david.hanneq...@gmail.com   |jples...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1656899] New: Upgrade perl-Test-WWW-Mechanize to 1.52

[bugzilla]

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

Bug ID: 1656899
   Summary: Upgrade perl-Test-WWW-Mechanize to 1.52
   Product: Fedora
   Version: rawhide
 Component: perl-Test-WWW-Mechanize
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, trem...@tremble.org.uk



Latest Fedora delivers 1.50 version. Upstream released 1.52. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Bodhi update problems?

[Richard Shaw]

On Thu, Dec 6, 2018 at 9:53 AM Randy Barlow 
wrote:

> On Thu, 2018-12-06 at 08:37 -0600, Richard Shaw wrote:
> > 1. When I add updates for one package and then type in a new name at
> > the top and select the other package I want in the update the
> > existing updates that are checked off turn into six digit numbers.
>
> This should have been fixed by 3.11.3, deployed to production
> yesterday. Did you see it today?
>
> https://github.com/fedora-infra/bodhi/issues/2791
>
> > 2. All of my updates started showing "logout required" but I haven't
> > changed the way I submit updates.
>
> This one should have been fixed by 3.11.1, which was deployed last
> week. It was actually due to the order of the options in the new update
> form changing, while the default remained the first option (so, the
> default changed to logout).
>
> https://github.com/fedora-infra/bodhi/issues/2778


Yup, just submitted one a few minutes ago and it worked as expected. Thanks.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Petr Pisar]

On 2018-12-06, Daniel P  Berrangé  wrote:
> On Thu, Dec 06, 2018 at 02:48:32PM +, Petr Pisar wrote:
>> On 2018-12-06, Florian Weimer  wrote:
>> > In a sense, it's the old discussion between explicit rename recording
>> > and rename detection.  I think it's clear by now that rename detection
>> > has won.
>> >
>> Can you give us some example of a rename detection that works?
>> 
>> If a packager cherry-picks patches, he looses upstream's commit IDs.
>
> You should essentially always use 'git cherry-pick -x $HASH' this causes
> the commit message to have a line appended:
>
> (cherry picked from commit d6b27d3e4c40946efa79e91d134616b41b1666c4)
>
I did not know about the -x option. Thanks. I used to ammend the
original commit ID manually.

However, this is essentially the "explicit rename recording" that
Florian claims is not needed anymore.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi update problems?

[Randy Barlow]

On Thu, 2018-12-06 at 08:37 -0600, Richard Shaw wrote:
> 1. When I add updates for one package and then type in a new name at
> the top and select the other package I want in the update the
> existing updates that are checked off turn into six digit numbers.

This should have been fixed by 3.11.3, deployed to production
yesterday. Did you see it today?

https://github.com/fedora-infra/bodhi/issues/2791

> 2. All of my updates started showing "logout required" but I haven't
> changed the way I submit updates.

This one should have been fixed by 3.11.1, which was deployed last
week. It was actually due to the order of the options in the new update
form changing, while the default remained the first option (so, the
default changed to logout).

https://github.com/fedora-infra/bodhi/issues/2778


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1656896] New: Upgrade perl-Mail-IMAPClient to 3.40

[bugzilla]

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

Bug ID: 1656896
   Summary: Upgrade perl-Mail-IMAPClient to 3.40
   Product: Fedora
   Version: rawhide
 Component: perl-Mail-IMAPClient
  Assignee: tcall...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest Fedora delivers 3.39 version. Upstream released 3.40. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1656894] New: Upgrade perl-Config-Model to 2.129

[bugzilla]

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

Bug ID: 1656894
   Summary: Upgrade perl-Config-Model to 2.129
   Product: Fedora
   Version: rawhide
 Component: perl-Config-Model
  Assignee: david.hanneq...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: david.hanneq...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest Fedora delivers 2.128 version. Upstream released 2.129. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1656892] New: Upgrade perl-Catalyst-Plugin-Session to 0.41

[bugzilla]

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

Bug ID: 1656892
   Summary: Upgrade perl-Catalyst-Plugin-Session to 0.41
   Product: Fedora
   Version: rawhide
 Component: perl-Catalyst-Plugin-Session
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



Latest Fedora delivers 0.40 version. Upstream released 0.41. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Kamil Dudka]

On Thursday, December 6, 2018 3:48:32 PM CET Petr Pisar wrote:
> On 2018-12-06, Florian Weimer  wrote:
> 
> > In a sense, it's the old discussion between explicit rename recording
> > and rename detection.  I think it's clear by now that rename detection
> > has won.
> >
> >
> 
> Can you give us some example of a rename detection that works?
> 
> If a packager cherry-picks patches, he looses upstream's commit IDs. If
> an upstream uses non-descriptive commit messages (e.g. five commits with
> the same "A bug fix" subject), commit messages are not uniq. If the
> packager needs to ammend patches (the commit bodies) to resolve conflicts
> (i.e. porting back the fixes by rebasing the patches), the code changes
> are not uniq. If an upstream releases a new version after a year, the
> packager won't probably remember all the cherry-picked fixes.
> 
> How can a packager identify which commits originates from the upstream
> and which are uniq to Fedora and must be carried across rebases to
> a new release?
> 
> A tempting answer could be use merge-commits extensively. However, would
> that really help? I must admit I'm not fond of merge-commits and I don't
> have much experience with them.
> 
> If I imagine a dist-git tree full of intermingled upstream and Fedora
> commits, I don't know how I as a packager would package a new upstream
> release. Should I just blindy believe in "git merge"? I have a few bad
> experiences with git losing diff chunks on the way. How could I keep
> the packaging accountable and verifiable?
> 
> -- Petr

It is not covered by any policy or supported tooling but, just to help
myself with future maintenance, I always append "Upstream-commit: "
to the commit message whenever I take a patch (commit) from the upstream
git repository.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Lennart Poettering]

On Do, 06.12.18 14:58, Pavel Březina (pbrez...@redhat.com) wrote:

> > Then there is nss-mymachines. It's primarily useful if
> > systemd-machined or systemd-nspawn is used. Given that those are now
> > part of the 'systemd-container' RPM it would be OK to also add
> > nss-mymachines to nsswitch.conf only when the RPM is installed, if
> > there's a concept for that. That said, in order to simplify things,
> > and given that systemd is a very core part of the OS I'd personally
> > just put it statically in nsswitch.conf too by default. After all a
> > missing NSS module listed in nsswitch.conf is just skipped, hence this
> > should not matter. This module should be in the 'passwd', 'group' and
> > 'hosts' lines.
>
> Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can
> happen some ID overlaps with FreeIPA/Samba which is undesirable. I would say
> that this must be solves if this module is enabled by default. Was there any
> progress in this area?

I think that's a misunderstanding of what the module does. At the
point the module announces those uid/gid ranges they are already
reserved, hence the conflict is already there. nss-mymachines is hence
only the messanger, not the culprit. Moreover, I think that
registering all taken users in NSS is really key to minimize such
conflicts. Hence, I am very strongly of the opinion that any component
taking possession off a user or a range of users it *must* show up in
NSS too, so that other components know.

I commented on the bug too.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Rawhide-20181206.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
5 of 47 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 28/131 (x86_64), 3/23 (i386), 1/2 (arm)

New failures (same test not failed in Rawhide-20181205.n.0):

ID: 316407  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/316407
ID: 316408  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/316408
ID: 316411  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/316411
ID: 316412  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/316412
ID: 316413  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/316413
ID: 316414  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/316414
ID: 316415  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/316415
ID: 316424  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/316424
ID: 316425  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/316425
ID: 316492  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/316492

Old failures (same test failed in Rawhide-20181205.n.0):

ID: 316419  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/316419
ID: 316430  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/316430
ID: 316438  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/316438
ID: 316440  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/316440
ID: 316441  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/316441
ID: 316443  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/316443
ID: 316444  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/316444
ID: 316459  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/316459
ID: 316510  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/316510
ID: 316511  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/316511
ID: 316515  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/316515
ID: 316516  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/316516
ID: 316517  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/316517
ID: 316518  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/316518
ID: 316519  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/316519
ID: 316525  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/316525
ID: 316526  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/316526
ID: 316527  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/316527
ID: 316528  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/316528
ID: 316529  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/316529
ID: 316530  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/316530
ID: 316539  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/316539

Soft failed openQA tests: 3/131 (x86_64), 2/23 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Rawhide-20181205.n.0):

ID: 316427  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/316427
ID: 316428  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/316428
ID: 316447  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/316447

Old soft failures (same test soft failed in Rawhide-20181205.n.0):

ID: 316422  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/316422
ID: 316423  Test: i386 Server-dvd-iso install_default
URL: 

Re: Fedora Lifecycles: imagine longer-term possibilities

[Daniel P . Berrangé]

On Thu, Dec 06, 2018 at 02:48:32PM +, Petr Pisar wrote:
> On 2018-12-06, Florian Weimer  wrote:
> > In a sense, it's the old discussion between explicit rename recording
> > and rename detection.  I think it's clear by now that rename detection
> > has won.
> >
> Can you give us some example of a rename detection that works?
> 
> If a packager cherry-picks patches, he looses upstream's commit IDs.

You should essentially always use 'git cherry-pick -x $HASH' this causes
the commit message to have a line appended:

(cherry picked from commit d6b27d3e4c40946efa79e91d134616b41b1666c4)

If you cherry-pick from a commit that was in turn a cherry-pick, you'll
get a long series of annotations so you can see the chain of picks.

IMHO this is one of those annoying git cases where the commonly desired
behaviour is not in fact the 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Petr Pisar]

On 2018-12-06, Florian Weimer  wrote:
> In a sense, it's the old discussion between explicit rename recording
> and rename detection.  I think it's clear by now that rename detection
> has won.
>
Can you give us some example of a rename detection that works?

If a packager cherry-picks patches, he looses upstream's commit IDs. If
an upstream uses non-descriptive commit messages (e.g. five commits with
the same "A bug fix" subject), commit messages are not uniq. If the
packager needs to ammend patches (the commit bodies) to resolve conflicts
(i.e. porting back the fixes by rebasing the patches), the code changes
are not uniq. If an upstream releases a new version after a year, the
packager won't probably remember all the cherry-picked fixes.

How can a packager identify which commits originates from the upstream
and which are uniq to Fedora and must be carried across rebases to
a new release?

A tempting answer could be use merge-commits extensively. However, would
that really help? I must admit I'm not fond of merge-commits and I don't
have much experience with them.

If I imagine a dist-git tree full of intermingled upstream and Fedora
commits, I don't know how I as a packager would package a new upstream
release. Should I just blindy believe in "git merge"? I have a few bad
experiences with git losing diff chunks on the way. How could I keep
the packaging accountable and verifiable?

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Tracking translation status of a package built in koji

[Sundeep Anand]

On Tue, Dec 4, 2018 at 6:34 PM Sundeep Anand  wrote:

> Hi Dominik,
>
> Thank you so much trying that out. Actually, to get stats saved for a
> package, the package is to be added in Transtats, 'mkvtoolnix'
> So, dry run of jobs (you must have unchecked it) will not bug you, with an
> error. And, to add a package, we need to be logged in.
>
> Fedora login needs OIDC key, I think infra people are working on it, so it
> will be available soon.
>
> regards,
> sundeep
>
>
> On Fri, Nov 30, 2018 at 5:34 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
>
>> On Friday, 30 November 2018 at 06:51, Sundeep Anand wrote:
>> > Hi Everyone,
>> >
>> > At times this could be a requirement to track or know translation
>> status of a package which has (just) built in koji.
>> > Transtats could be used for this purpose. We just need to run a job.
>> >
>> > Steps:
>> >1. Navigate to
>> https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based
>> >2. Select 'Sync Package Build System' job template and proceed.
>> >3. You may read and continue with the tasks defined in YML.
>> >4. Select or enter package name. For example: anaconda.
>> >Select Build System and Tag. For example: koji and rawhide
>> >Click 'Next'
>> >5. And run the job. Upon successful completion an unique URL will be
>> created.
>> >
>> > This could really be helpful. We are working on creating alerts or
>> warnings.
>> > Feel free to share comments on this here: http://feedback.transtats.xyz
>>
>> Doesn't seem to work. I get this after step 5:
>> Alas! Something unexpected happened.
>>   Stats NOT saved. Package does not exist.
>>
>> ... even though I can see seemingly correct output logged for my
>> package (mkvtoolnix).
>>
>> Also, attempting to do a "Fedora Login" gives me:
>>
>> 400 - Bad Request
>>
>> Invalid redirect_uri
>>
>> despite having a valid Kerberos ticket.
>>
>>
Fedora authentication is now working. Feel free to add package, as well.
Thanks!



> Regards,
>> Dominik
>> --
>> Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
>> There should be a science of discontent. People need hard times and
>> oppression to develop psychic muscles.
>> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1656335] Upgrade perl-XXX to 0.32

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XXX-0.32-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-12-06 09:41:44



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Bodhi update problems?

[Richard Shaw]

I've noticed the following two things happening the last couple of weeks...

1. When I add updates for one package and then type in a new name at the
top and select the other package I want in the update the existing updates
that are checked off turn into six digit numbers.

2. All of my updates started showing "logout required" but I haven't
changed the way I submit updates.

Anyone else seeing this?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-rawhide-kernel-nodebug is not getting updates

[Richard W.M. Jones]

On Mon, Nov 26, 2018 at 07:14:50AM -0600, Justin Forbes wrote:
> On Fri, Nov 23, 2018 at 7:47 AM Dan Horák  wrote:
> >
> > On Fri, 23 Nov 2018 14:28:46 +0100
> > Igor Gnatenko  wrote:
> >
> > > Does anybody know why?
> > >
> > > Last kernel available there is 2 weeks old.
> > >
> > > https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/
> >
> > I've already pinged #fedora-kernel few days ago, but let's notify the
> > kernel list too.
> >
> Between Plumbers conference and some vacation, I was not around to
> keep it updated, it should get rc4 today and remain on track.

First a basic question: How do I tell if an installed kernel is a
"debug" or "nodebug" kernel?  I think it should be made more clear in
the %description or the release field or something like that.

Anyway it seems like Rawhide isn't getting new nodebug kernels.

- Latest nodebug kernel:
  kernel-4.20.0-0.rc1.git4.2.fc30.x86_64.rpm
  (https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/)

- Latest Rawhide kernel:
  kernel-4.20.0-0.rc5.git2.1.fc30
  (https://koji.fedoraproject.org/koji/packageinfo?packageID=8)

I suppose the Rawhide kernels are debug kernels since there is a
recent changelog message ("- Reenable debugging options.")  but I
can't tell for sure.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Tom Hughes]

On 06/12/2018 14:11, Florian Weimer wrote:

* Tom Hughes:


Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.


Not in the file shipped by the glibc package.


Well something that has been installed as part of the live
image has enabled them then...

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Matthew Miller]

On Thu, Dec 06, 2018 at 01:42:06PM +0100, Florian Weimer wrote:
> > https://github.com/user-cont/source-git
[...]
> > We would love to take development off dist-git (but keep dist-git!)
> > and move it to git repos with real source code which match upstream
> > repositories. In such repo you have branches which track respective
[...]
> That sounds very nice.
> 
> Is there a place to discuss this approach?

I would suggest *this list*, although perhaps if it's something other than
lifecycle a new thread (so it doesn't get lost).


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1656335] Upgrade perl-XXX to 0.32

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1656335
Bug 1656335 depends on bug 1656392, which changed state.

Bug 1656392 Summary: Review Request: perl-JSON-Color - Encode to colored JSON
https://bugzilla.redhat.com/show_bug.cgi?id=1656392

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Florian Weimer]

* Tom Hughes:

> Based on my experimentation with an F29 live image last week both
> nss-systemd and nss-myhostname are in the default configuration.

Not in the file shipped by the glibc package.

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Florian Weimer]

* Lennart Poettering:

> nss-myhostname should be in nsswitch.conf by default too. It's very
> minimal, and just makes sure the local hostname remains resolvable all
> the time. By enabling this, installers and image generators don't have
> to patch /etc/hosts anymore like they traditionally did, in fact they
> can remove it altogether and just leave resolution of the local
> hostname to the module, and it will magically follow whatever is
> currently set via sethostname(). This module should be in the 'hosts'
> line.

The way myhostname is currently implemented, it is rather problematic.
I think it has largely stopped stomping over the DNS namespace (with the
_gateway change), so it could be moved to the front, eliminating all
those problems.

The other issue is that the systemd NSS modules are quite heavy and pull
in other DSOs and may cause single-thread optimizations to be disabled
because they load libpthread.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20181206.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181205.n.0
NEW: Fedora-Rawhide-20181206.n.0

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  0
Dropped packages:1
Upgraded packages:   43
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:812.66 KiB
Size of upgraded packages:   1.89 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -143.50 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20181206.n.0.iso
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20181206.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20181206.n.0.iso

= DROPPED IMAGES =
Image: Workstation live i386
Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20181205.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: ibus-xkbc-1.3.3.20100922-13.fc29
Summary: The XKBC engine for IBus input platform
RPMs:ibus-xkbc
Size:812.66 KiB


= UPGRADED PACKAGES =
Package:  GraphicsMagick-1.3.31-2.fc30
Old package:  GraphicsMagick-1.3.31-1.fc30
Summary:  An ImageMagick fork, offering faster image generation and better 
quality
RPMs: GraphicsMagick GraphicsMagick-c++ GraphicsMagick-c++-devel 
GraphicsMagick-devel GraphicsMagick-doc GraphicsMagick-perl
Size: 11.79 MiB
Size change:  1.70 KiB
Changelog:
  * Wed Dec 05 2018 Rex Dieter  - 1.3.31-2
  - GraphicsMagic-perl 1.3.31 is broken (#1655294)


Package:  R-errors-0.3.1-1.fc30
Old package:  R-errors-0.3.0-3.fc30
Summary:  Uncertainty Propagation for R Vectors
RPMs: R-errors
Size: 114.35 KiB
Size change:  4.14 KiB
Changelog:
  * Wed Dec 05 2018 I??aki ??car  - 0.3.1-1
  - Update to 0.3.1


Package:  R-quantities-0.1.2-1.fc30
Old package:  R-quantities-0.1.1-2.fc30
Summary:  Quantity Calculus for R Vectors
RPMs: R-quantities
Size: 760.21 KiB
Size change:  3.78 KiB
Changelog:
  * Wed Dec 05 2018 I??aki ??car  - 0.1.2-1
  - Update to 0.1.2


Package:  R-units-0.6.2-1.fc30
Old package:  R-units-0.6.1-1.fc30
Summary:  Measurement Units for R Vectors
RPMs: R-units R-units-devel
Size: 4.09 MiB
Size change:  21.59 KiB
Changelog:
  * Wed Dec 05 2018 I??aki ??car  - 0.6.2-1
  - Update to 0.6-2


Package:  bcm283x-firmware-20181204-1.afd824a.fc30
Old package:  bcm283x-firmware-20181105-1.55e5912.fc30
Summary:  Broadcom bcm283x firmware for the Raspberry Pi
RPMs: bcm283x-firmware
Size: 11.39 MiB
Size change:  8.36 KiB
Changelog:
  * Wed Dec 05 2018 Peter Robinson  
20181204-1.afd824a
  - Latest firmware update


Package:  bodhi-3.11.3-100.fc30
Old package:  bodhi-3.11.2-100.fc30
Summary:  A modular framework that facilitates publishing software updates
RPMs: bodhi-client bodhi-composer bodhi-docs bodhi-server python2-bodhi 
python2-bodhi-client python3-bodhi python3-bodhi-client
Size: 5.99 MiB
Size change:  1.34 KiB
Changelog:
  * Wed Dec 05 2018 Randy Barlow  - 3.11.3-100
  - Update to 3.11.3.
  - https://github.com/fedora-infra/bodhi/releases/tag/3.11.3


Package:  brltty-5.6-29.fc30
Old package:  brltty-5.6-27.fc29
Summary:  Braille display driver for Linux/Unix
RPMs: brlapi brlapi-devel brlapi-java brltty brltty-at-spi2 brltty-docs 
brltty-dracut brltty-espeak brltty-espeak-ng brltty-speech-dispatcher brltty-xw 
ocaml-brlapi python3-brlapi tcl-brlapi
Size: 11.87 MiB
Size change:  -743.82 KiB
Changelog:
  * Wed Dec 05 2018 Jaroslav ??karvada  - 5.6-28
  - Built OCaml bindings with distribution CFLAGS and consolidated patches
  - Fixed Cython build requires
  - Used macro for python3 path

  * Wed Dec 05 2018 Jaroslav ??karvada  - 5.6-29
  - Improved CFLAGS handling when building Ocaml bindings


Package:  btrfs-progs-4.19.1-1.fc30
Old package:  btrfs-progs-4.17.1-1.fc29
Summary:  Userspace programs for btrfs
RPMs: btrfs-progs btrfs-progs-devel
Size: 4.64 MiB
Size change:  122.72 KiB
Changelog:
  * Wed Dec 05 2018 Eric Sandeen  4.19.-1
  - New usptream release


Package:  buildah-1.6-10.dev.git5cca1d6.fc30
Old package:  buildah-1.6-9.dev.git01f9ae2.fc30
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 23.68 MiB
Size change:  888 B
Changelog:
  * Thu Dec 06 2018 Lokesh Mandvekar (Bot)  - 
1.6-10.dev.git5cca1d6
  - autobuilt 5cca1d6


Package:  byte-buddy-1.9.5-3.fc30
Old package:  byte-buddy-1.9.5-2.fc30
Summary:  Runtime code generation for the Java virtual machine
RPMs: byte-buddy byte-buddy-agent byte-buddy-javadoc 
byte-buddy-maven-plugin byte-buddy-parent
Size: 8.46 MiB
Size change:  -396 B
Changelog:
  * Wed Dec 05 2018 Mat Booth  - 1.9.5-3
  - Enable test suites


Package:  calligra-3.1.0-11.fc30
Old package:  calligra

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

On 12/6/18 2:36 PM, Lennart Poettering wrote:

On Do, 06.12.18 12:20, Pavel Březina (pbrez...@redhat.com) wrote:


Hello,


Heya!


systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.

Originally, I wanted to create an authselect command that can be used by
packages on systems that are configured by authselect and on systems that
are configured with different ways [1]. But it turned out that there are
only two packages that touches nsswitch.conf so I do not think this is
necessary.

I prepared initial design document with multiple solutions that came to my
mind [2] and I would like to discuss this with the community to see what is
the correct and desired way to solve this.


nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.

nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.

Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.


Reading https://bugzilla.redhat.com/show_bug.cgi?id=1284325 there is can 
happen some ID overlaps with FreeIPA/Samba which is undesirable. I would 
say that this must be solves if this module is enabled by default. Was 
there any progress in this area?



Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.

Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

On 12/6/18 1:31 PM, Florian Weimer wrote:

* Pavel Březina:


systemd and nss-mdns packages modifies nsswitch.conf in their %post
scriptlets which creates conflicts with authselect on systems that are
configured by authselect. This needs to be solved somehow.


Other packagers (notably sssd) have made the required changes by
requesting them form glibc developers.

Would this help to solve the problem here?


If all those packages should be enabled by default, this probably the 
best solution.




Thanks,
Florian


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Tom Hughes]

On 06/12/2018 13:36, Lennart Poettering wrote:


nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.

nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.


Based on my experimentation with an F29 live image last week both
nss-systemd and nss-myhostname are in the default configuration.


Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.

Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.


Equally, neither nss-mymachines or nss-resolve appear to be in
the default configuration on an F29 image.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Elections — Voting now open

[Ben Cotton]

On Thu, Dec 6, 2018 at 5:07 AM Miro Hrončok  wrote:
>
> Note that some answers in [2] seem to be mixed up (see [3]).
>
> Maybe wait with your votes until that is resolved.
>
Thank you for catching those, Miro. All of the issues with the
questionnaires should now be fixed. If you notice anything else amiss,
please open a ticket in Pagure[1]

[1] https://pagure.io/fedora-project-schedule/issues

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Lennart Poettering]

On Do, 06.12.18 12:20, Pavel Březina (pbrez...@redhat.com) wrote:

> Hello,

Heya!

> systemd and nss-mdns packages modifies nsswitch.conf in their %post
> scriptlets which creates conflicts with authselect on systems that are
> configured by authselect. This needs to be solved somehow.
>
> Originally, I wanted to create an authselect command that can be used by
> packages on systems that are configured by authselect and on systems that
> are configured with different ways [1]. But it turned out that there are
> only two packages that touches nsswitch.conf so I do not think this is
> necessary.
>
> I prepared initial design document with multiple solutions that came to my
> mind [2] and I would like to discuss this with the community to see what is
> the correct and desired way to solve this.

nss-systemd should be in nsswitch.conf by default. It's required for
systemd's DynamicUser=1 option to work correctly, and that's core
service functionality. Hence, given that systemd is Fedora's PID 1,
nss-systemd should also be in nsswitch.conf unconditionally (in the
'passwd' and 'group' lines). A system where nss-systemd is not enabled
is simply broken right now.

nss-myhostname should be in nsswitch.conf by default too. It's very
minimal, and just makes sure the local hostname remains resolvable all
the time. By enabling this, installers and image generators don't have
to patch /etc/hosts anymore like they traditionally did, in fact they
can remove it altogether and just leave resolution of the local
hostname to the module, and it will magically follow whatever is
currently set via sethostname(). This module should be in the 'hosts'
line.

Then there is nss-mymachines. It's primarily useful if
systemd-machined or systemd-nspawn is used. Given that those are now
part of the 'systemd-container' RPM it would be OK to also add
nss-mymachines to nsswitch.conf only when the RPM is installed, if
there's a concept for that. That said, in order to simplify things,
and given that systemd is a very core part of the OS I'd personally
just put it statically in nsswitch.conf too by default. After all a
missing NSS module listed in nsswitch.conf is just skipped, hence this
should not matter. This module should be in the 'passwd', 'group' and
'hosts' lines.

Finally, there's nss-resolve. It's the client side to
systemd-resolved. It's the client side to systemd-resolved's
DNS/mDNS/LLMNR/DoT/DNSSEC stack. systemd-resolved is not default in
Fedora right now. Quite frankly I think it should be, but that's another
political discussion (and I am not sure I am ready to have it right
now). The module is benign though: if resolved is not running it
doesn't do anything. It only does its thing if resolved is
running. Thus I'd also suggest to just enable it by default, and
simplify things because then people can use resolved just by doing
"systemctl enable systemd-resolved" and don't need to do anything
else. This module should be in the 'hosts' line.

Summary: I'd make things simple, and enable all four unconditionally
and by default without any dynamic infrastructure, without postinst
scripts or anything. If that's not acceptable, then at least two of the
four should be unconditionally enabled.

Lennart

--
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Florian Weimer]

* Neal Gompa:

> You're confusing this with trust. And yes, there's some trust to give
> here, but keeping a (tiny) amount of friction for small patch sets
> that increases as your patch load goes up just further encourages not
> maintaining heavy patch loads.

Heavy patch loads are just a fact of life.  Currently, Fedora 28 glibc
is at ~90 upstream patches.  Fedora 27 glibc was at ~190 upstream
patches at end of life (depending whether you count the last update that
didn't make it before EOL).  The few Fedora-specific patches come on top
of that.

For comparison, Red Hat Enterprise Linux 7 glibc is currently at around
880 patches.  Most of them a straight upstream backports, as in Fedora.

The overhead from managing those patches used to be substantial, but we
have mostly automated it, in a different way from the kernel and Red
Hat's middleware products, because Fedora would not allow us to use
established downstream practices.  Unfortunately, our automation is
still somewhat brittle and incomplete.  It still takes around seven
minutes to prepare the sources for a totally trivial upstream backport
of a single patch, something that should ideally be a single “git
cherry-pick” command (which would also leave less room for mistakes).
Of course, in seven minutes, you can fill in a lot of patch
documentation that allows you to figure out later what you did and why.

I'm worried that this kind of pointless work makes it hard to attract
talent.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Florian Weimer]

* Neal Gompa:

> The problem with merged source trees (aka source-git) is that it
> implies forking projects.

But that's true for *any* distribution that wants to integrate things.
I guess you could govern everything by build flags eventually, but
upstreams will rarely be willing to backport those to older branches
(if they even have release branches as such).

> It's an easy trap to start having vendor trees and maintain your own
> functionality independent from upstream.

And how does the current dist-git prevent that?  I know packages which
have managed to fall into the fork trap even with dist-git.

> Fundamentally, I don't want having patches to be too easy, because
> then people _will_ do that. Fedora should strive to remain close to
> upstream projects and interact with them to make things better[1].

To be honest, that's an awful attitude.

Do you want me to spend time on packaging work instead of glibc
maintenance?  Do you really think that's a good use of my time?

Do you really think an unavoidable conflict each time you merge parallel
development into a source RPM provides value?

> And the thing is, it's not like I'm unfamiliar with merged source
> models. I've worked in distributions that operated that way, and the
> consequence is almost always that things are patched and changed
> without ever interacting with upstream. Of course, that's their choice
> to do so, but most distributions do not have "upstream-first" as a
> specific goal.

We do that in Fedora, too.

A recent example is the switch to the C.UTF-8 locale, which is not
upstream *at all*.  It was pointed out at the time, and the issue was
completely ignored.

> In addition, it may seem like it makes things easier (and maybe
> faster), but it actually makes things much harder and slower for
> everyone else. Merged source trees make it so that it's stupid easy to
> have light forks of everything, which means people will just patch and
> change things without consequence. That makes it much harder to
> identify changes for rebasing to newer versions, what's safe to drop,
> and so on.

That's just a matter of tooling.  A lot of information can be recovered
from Git history, and it's going to be easier to do this in a single
repository than with copied patches, without tooling that enforces that
the patches actually contain what they say.

The point is to keep that history around.  With the current model, the
information might theoretically be available somewhere, but with the
split between Fedora, branches, wildly differing patch management
practices, in addition to all the upstream differences we encounter,
it's extremely difficult to recover.

In a sense, it's the old discussion between explicit rename recording
and rename detection.  I think it's clear by now that rename detection
has won.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Florian Weimer]

* Tomas Tomecek:

>> * Matthew Miller:
>> 
>> 
>> Make it cheap to maintain branches.  I expect that one what to achieve
>> this would be to build directly out of Git, with synthesized release
>> numbers and changelogs.  This way, you can apply a lot of fixes to
>> multiple branches without encountering mandatory conflicts.
>
> We are aiming for something similar what you just described. I created this 
> wiki page to describe the work briefly:
>
> https://fedoraproject.org/wiki/CI/source-git
>
> The actualy work is happening here now:
>
> https://github.com/user-cont/source-git
>
> We would love to take development off dist-git (but keep dist-git!)
> and move it to git repos with real source code which match upstream
> repositories. In such repo you have branches which track respective
> Fedora versions -- you can easily cherry pick fixes. We would validate
> every pull request in such repo and stuff would get merged only when
> it passes testing. Right now we are trying to write minimal code to
> make such thing work, evaluate it and present at devconf.cz to get
> some more feedback.

That sounds very nice.

Is there a place to discuss this approach?

I assume you still generate a flattened source tarball and inject that
into the RPM spec file?

I do wonder if it would be preferably to write the source RPM directly
(from a plain working tree, without history), with non-flattened paths,
and archive that in Koji for reproducibility.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Florian Weimer]

* Pavel Březina:

> systemd and nss-mdns packages modifies nsswitch.conf in their %post
> scriptlets which creates conflicts with authselect on systems that are
> configured by authselect. This needs to be solved somehow.

Other packagers (notably sssd) have made the required changes by
requesting them form glibc developers.

Would this help to solve the problem here?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

On 12/6/18 7:04 AM, Kaleb S. KEITHLEY wrote:

> 
>> And the other active maintainer (branto) and I don't have cycles to
>> devote to keeping (any part of) it building on 32-bit archs.
> 
> But people can always send patches. ;-)

If someone else would like to take over as maintainer, I'm happy to give
it up.

LMK.

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Kaleb S. KEITHLEY]

On 12/5/18 9:50 PM, Peter Robinson wrote:
> Kaleb,
> 
> Firstly the title is misleading as there was no heads up, a heads up
> is notice before you actually push the change, not when you do the
> change.

I suggest you take this up with branto. He's the one who built it
without 32-bit archs without any warning. I only found out about it when
I got build notices from koji (or pagure or whatever.)

You would have preferred no notice at all?

>> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
>> starting in fedora-30/rawhide.
>>
>> The upstream project doesn't support it. The armv7hl builders don't have
>> enough memory (or address space) to build some components.
>>
>> And the other active maintainer (branto) and I don't have cycles to
^^
>> devote to keeping it building on 32-bit archs.
^
>>
>> (FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
>> it has packages for i686 and armv7hl for people who want to run ceph on
>> 32-bit archs.)
> 
> As others have asked in the thread can we possibly build client only?

We?

Since the above seems to have been unclear:

> And the other active maintainer (branto) and I don't have cycles to
> devote to keeping (any part of) it building on 32-bit archs.

But people can always send patches. ;-)

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned python-adns

[Tomas Hozza]

Hi all.

I just orphaned python-adns. I don't need it and don't plan to maintain it. The 
last upstream release was in 2007 and it does not support Python3. Also it 
FTBFS in rawhide.

python-adns is required by transmission-remote-cli. Please consider removing 
the dependency, so that python-adns can be retired or please consider 
maintaining python-adns as well.

Regards,
Tomas
-- 
Tomas Hozza
Associate Manager, Software Engineering - EMEA ENG Core Services

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Atomic 29: ostree upgrade failed because of libdnf

[arnaud gaboury]

On Wed, Dec 5, 2018 at 4:13 PM Dusty Mabe  wrote:

>
>
> On 12/5/18 5:14 AM, arnaud gaboury wrote:
> >
> >
> > On Tue, Dec 4, 2018 at 6:57 PM Dusty Mabe  du...@dustymabe.com>> wrote:
> >
> >
> >
> > On 12/4/18 11:40 AM, Dusty Mabe wrote:
> >
> > >
> > > I will look at the configs and see if I can figure out where
> things are going wrong.
> > >
> >
> > I think this a a regression is some of the new yaml parsing in
> pungi. I opened a bug
> > to see https://pagure.io/pungi/issue/1092
> >
> > The updates-testing runs are running right after the updates runs
> and overwriting the ref.
> > For now we can disable updates-testing composes for silverblue so
> that it won't overwrite
> > the updates run.
> >
> > Here is a PR for that:
> >
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/LGL6LPHSOPNKQUWGYHGZVSDOX466WHFH/
> >
> > Dusty
> >
> >
> > My issue has been solved and could upgrade
>
> Yep. We put in a workaround yesterday. We should be good now. Sorry about
> that.
>

Don't be sorry and be proud for your very quick action and for the good
work you do with this wonderful distro.



> Dusty
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

authselect: what to do with systemd and nss-mdns that modify nsswith.conf

[Pavel Březina]

Hello,

systemd and nss-mdns packages modifies nsswitch.conf in their %post 
scriptlets which creates conflicts with authselect on systems that are 
configured by authselect. This needs to be solved somehow.


Originally, I wanted to create an authselect command that can be used by 
packages on systems that are configured by authselect and on systems 
that are configured with different ways [1]. But it turned out that 
there are only two packages that touches nsswitch.conf so I do not think 
this is necessary.


I prepared initial design document with multiple solutions that came to 
my mind [2] and I would like to discuss this with the community to see 
what is the correct and desired way to solve this.


Thank you,
Pavel.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YMQOZCV32272UIGZM45NVJLVZY2UOZH/


[2] 
https://fedoraproject.org/wiki/User:Pbrezina/Authselect_and_packages_that_modifies_nsswitch

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Valgrind and Fedora debuginfo: best GUI

[Germano Massullo]

I have to debug certain BOINC Manager problems (C++ language), and
instead of importing and building the whole source tree in a project
in a SDK like Eclipse, I want to simply use the debuginfos already
available in Fedora repository.
Concerning GDB usage I can do that with QtCreator. It attaches to and
external running program, and I can easly see the sources.
This seems to not happen with Valgrind on QtCreator: I can manage to
start Valgrind and BOINC Manager, but I don't see anything.
What do you suggest me to do to achieve using Valgrind in a GUI in a quick way?

Thank you
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 Elections — Voting now open

[Miro Hrončok]

Dne 06. 12. 18 v 1:36 Ben Cotton napsal(a):

Voting is now open for the Fedora 29 election cycle. You can vote in
the Elections app[1]. Interviews with candidates are available on the
Fedora Community Blog[2], with links available in the Elections app.
Voting ends at 23:59 UTC on 20 December.

[1] https://admin.fedoraproject.org/voting/
[2] http://communityblog.fedoraproject.org/


Note that some answers in [2] seem to be mixed up (see [3]).

Maybe wait with your votes until that is resolved.

[3] https://pagure.io/fedora-project-schedule/issue/55


--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1547165] perl-ExtUtils-CBuilder should require gcc

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Net-IDN-Encode-2.400-7.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b2c056d6b0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1656647] mod_proxy_uwsgi is not in the component list

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC|bazanlui...@gmail.com,  |kh...@redhat.com,
   |emman...@seyman.fr, |ppi...@redhat.com,
   |ita...@ispbrasil.com.br,|qg...@redhat.com
   |perl-devel@lists.fedoraproj |
   |ect.org |
  Component|bugzilla|Administration
Version|el6 |4.4
   Assignee|ita...@ispbrasil.com.br |hss-ied-b...@redhat.com
Product|Fedora EPEL |Bugzilla
 QA Contact|extras...@fedoraproject.org |tools-b...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1623268] CVE-2011-2767 mod_perl: arbitrary Perl code execution in the context of the user account via a user-owned .htaccess [epel-7]

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||mod_perl-2.0.10-3.el7



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org