Re: nss_myhostname as default in Fedora

[Petr Spacek]

On 25.1.2016 17:39, Lennart Poettering wrote:
> On Mon, 25.01.16 17:11, Florian Weimer (fwei...@redhat.com) wrote:
> 
>> On 01/25/2016 03:23 PM, Lennart Poettering wrote:
>>> On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.com) wrote:
>>>
> It is intended as a convenient fallback mechanism, and is only supposed
> to have an effect if 'gateway' is not defined in the local DNS (the
> 'domain' or 'search' zones). Would it help if those limitations were
> more explicit, e.g. documented in nss-myhostname(8)?

 I understand that the goal is that nss_myhostname will not override
 existing names, due to the way the NSS is configured.

 What I do not understand is how the the “gateway” name can be
 useful.
>>>
>>> Here's a very obvious, trivial example: wherever I am I can now simply
>>> type "ping gateway" to know whether connectivity to my local router
>>> works.
>>
>> But that's not actually true, isn't it?  If nss_myhostname doesn't
>> override “gateway”, the outcome depends on the network you are on.  With
>> a captive portal, you are likely pinging the portal server, not the
>> default gateway.  And if you are on one of Microsoft's corporate
>> networks, you might end up at gateway.microsoft.com (whatever this
>> is).
> 
> Well, IRL you'd actually quickly notice, since ping shows you the full
> fqdn of the host, and hence gives you a very clear hint on what it is
> actually pinging. 
> 
>> Because it's so unreliable, we cannot put this trick into documentation,
>> and we shouldn't train users to rely on this functionality.
> 
> Yeah, single-label names are like that. If you want trustable
> single-label names, you better shouldn't use search domains (and quite
> frankly, I am not particularly a fan of the search domain concept
> myself, because of its ambiguities. In systemd-resolved we by default
> ignore the DHCP-reported search domains because of this.)
> 
> Note that systemd-resolved's LLMNR implementation actually excepts
> itself from resolving "gateway" even though a single-label name (it
> also excepts itself from a couple of other names, such as
> "localhost"). Which basically means: the "gateway" name is safe
> exactly when you turn off the search domain logic (or to put this
> correctly if networkd is used: it is safe unless you *turn on* the
> search domain logic).
> 
>> Right.  If software (or documentation) uses “gateway” to mean “address
>> of the default gateway”, it will break, depending on search path
>> configuration and other network properties.
>>
>> I don't think this is what Fedora wants (and what you intended).
> 
> I disagree. It only breaks if the user enables domain search logic,
> and configures a domain in there that actually serves a host called
> "gateway".

I disagree with your disagreement. We have only 1 shared namespace for this
world, and like it or not, the root zone (and thus all single-label names in
it) is managed by ICANN.

Fritzbox already did the mistake and used "box." as fake TLD for their
"gateways", and this is going to cause trouble because Amazon bought box. TLD 
[1].

"gateway." (as any other single-label name) can face the same faith one day,
when somebody decides to spend $$$ and buy it. Training anyone to rely on
"gateway" or any other single-label name is a bad idea.

"gateway.local." is okay, because RFC 6762 reserved "local." for this purpose.

However, I agree with you that 'search' mechanism is broken by design. Still,
disabling the search mechanism does not make use of single-label names safe or
even reliable.

So, please, do not push "gateway." or any other single-label name forward. It
will cause trouble sooner or later.

[1]
https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/990

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

[Petr Pisar]

On 2016-01-25, Zbigniew Jędrzejewski-Szmek  wrote:
> On Mon, Jan 25, 2016 at 04:34:55PM -0600, Jason L Tibbitts III wrote:
>> A huge list of packages and owners follows.  Please consider cleaning up
>> your packages if you can.  (Yes, I have some on the list, which
>> I've fixed already.)  Packagers with no owners listed might have been
>> orphaned or retired but are still showing up in the spec tarball.
>
> I agree with what poeple said on IRC: involving all those maintainers
> is mostly a waste of time. Better to just run a script to fix those overnight,
> and than deal with any fallout.
>
This can bring bugs because, as noted in the orignal message, some
people use to change wrong permissions coming from %install section.

The real fix would to remove them locally, scratch-rebuild them, check
no file permissions changed against the latest build and only then push
the changes into dist-git.

-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

[Nathanael D. Noblet]

On Mon, 2016-01-25 at 16:34 -0600, Jason L Tibbitts III wrote:

> beanstalkd (jjh, gnat)

removed defattr.


-- 
Nathanael
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Andrew Lutomirski]

On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson  wrote:
>>> >>> It is intended as a convenient fallback mechanism, and is only supposed
>>> >>> to have an effect if 'gateway' is not defined in the local DNS (the
>>> >>> 'domain' or 'search' zones). Would it help if those limitations were
>>> >>> more explicit, e.g. documented in nss-myhostname(8)?
>>> >>
>>> >> I understand that the goal is that nss_myhostname will not override
>>> >> existing names, due to the way the NSS is configured.
>>> >>
>>> >> What I do not understand is how the the “gateway” name can be
>>> >> useful.
>>> >
>>> > Here's a very obvious, trivial example: wherever I am I can now simply
>>> > type "ping gateway" to know whether connectivity to my local router
>>> > works.
>>>
>>> But that's not actually true, isn't it?  If nss_myhostname doesn't
>>> override “gateway”, the outcome depends on the network you are on.  With
>>> a captive portal, you are likely pinging the portal server, not the
>>> default gateway.  And if you are on one of Microsoft's corporate
>>> networks, you might end up at gateway.microsoft.com (whatever this
>>> is).
>>
>> Well, IRL you'd actually quickly notice, since ping shows you the full
>> fqdn of the host, and hence gives you a very clear hint on what it is
>> actually pinging.
>>
>>> Because it's so unreliable, we cannot put this trick into documentation,
>>> and we shouldn't train users to rely on this functionality.
>>
>> Yeah, single-label names are like that. If you want trustable
>> single-label names, you better shouldn't use search domains (and quite
>> frankly, I am not particularly a fan of the search domain concept
>> myself, because of its ambiguities. In systemd-resolved we by default
>> ignore the DHCP-reported search domains because of this.)
>>
>> Note that systemd-resolved's LLMNR implementation actually excepts
>> itself from resolving "gateway" even though a single-label name (it
>> also excepts itself from a couple of other names, such as
>> "localhost"). Which basically means: the "gateway" name is safe
>> exactly when you turn off the search domain logic (or to put this
>> correctly if networkd is used: it is safe unless you *turn on* the
>> search domain logic).
>>
>>> Right.  If software (or documentation) uses “gateway” to mean “address
>>> of the default gateway”, it will break, depending on search path
>>> configuration and other network properties.
>>>
>>> I don't think this is what Fedora wants (and what you intended).
>>
>> I disagree. It only breaks if the user enables domain search logic,
>> and configures a domain in there that actually serves a host called
>> "gateway".
>
> Which from my time, a good 10 years or so, at a large global service
> provider and as a Red Hat consultant on customer sites both of those
> were often true so I'm not sure it's something that you can assume
> either way. And given on those networks there's generally LOT of
> legacy platforms that make assumptions about that sort of thing I'm
> not sure it's something you can just turn around and say "well just
> turn it off you idiots".
>

I think that the "gateway" override should not be conflated with
always letting the gethostname(2) return value resolve.

I also think that the whole gethostname(2) mechanism is terminally
screwed up.  We abuse the hostname for multiple purposes:

1. It shows up in the default bash prompt.
2. It gets sent to remote DHCP servers.  I think this is a mistake on
desktop machines.
3. Some programs seem to thing that gethostbyname(gethostname())
should return some reasonable concept of "my ip address" despite the
general nonexistence of such a concept.

I'll propose a strawman:

 - gethostname(2) always returns "localhost".

 - "localhost" always resolves to 127.0.0.1 or ::1

 - bash learns to use some intelligent value derived from whatever
hostnamectl would return

 - the default DHCP clients send a client identifier that's a function
only of the MAC address used to send the query

 - Whatever systemd magic special-cases "localhost" as "trust what
DHCP says" goes away.

and that's it.

This trivially solves one silly annoyance: when I install Fedora, why
on Earth is "what's your hostname" a reasonable question to ask me?

Servers may have their own considerations, and NetworkManager and/or
networkd could consider having a client-id override.  But I think that
my strawman proposal should cover almost all desktop usecases and even
almost all server usecases.

If people really want to force a non-"localhost" hostname on a server,
then forcing it to resolve to something intelligent might make sense,
as having everything fail when resolution times out or ends up with
SERVFAIL or NXDOMAIN is nasty.  But when I force my hostname to
"foo.corp.bar.com", I probably have something other than 127.0.0.1 in
mind.

Heck, strawman #2 should cover every use case:

 - Anaconda defaults the hostname to "localhost".  For the workstation
product, Anaconda stops asking for a hostname entirely

Re: nss_myhostname as default in Fedora

[Peter Robinson]

>> >>> It is intended as a convenient fallback mechanism, and is only supposed
>> >>> to have an effect if 'gateway' is not defined in the local DNS (the
>> >>> 'domain' or 'search' zones). Would it help if those limitations were
>> >>> more explicit, e.g. documented in nss-myhostname(8)?
>> >>
>> >> I understand that the goal is that nss_myhostname will not override
>> >> existing names, due to the way the NSS is configured.
>> >>
>> >> What I do not understand is how the the “gateway” name can be
>> >> useful.
>> >
>> > Here's a very obvious, trivial example: wherever I am I can now simply
>> > type "ping gateway" to know whether connectivity to my local router
>> > works.
>>
>> But that's not actually true, isn't it?  If nss_myhostname doesn't
>> override “gateway”, the outcome depends on the network you are on.  With
>> a captive portal, you are likely pinging the portal server, not the
>> default gateway.  And if you are on one of Microsoft's corporate
>> networks, you might end up at gateway.microsoft.com (whatever this
>> is).
>
> Well, IRL you'd actually quickly notice, since ping shows you the full
> fqdn of the host, and hence gives you a very clear hint on what it is
> actually pinging.
>
>> Because it's so unreliable, we cannot put this trick into documentation,
>> and we shouldn't train users to rely on this functionality.
>
> Yeah, single-label names are like that. If you want trustable
> single-label names, you better shouldn't use search domains (and quite
> frankly, I am not particularly a fan of the search domain concept
> myself, because of its ambiguities. In systemd-resolved we by default
> ignore the DHCP-reported search domains because of this.)
>
> Note that systemd-resolved's LLMNR implementation actually excepts
> itself from resolving "gateway" even though a single-label name (it
> also excepts itself from a couple of other names, such as
> "localhost"). Which basically means: the "gateway" name is safe
> exactly when you turn off the search domain logic (or to put this
> correctly if networkd is used: it is safe unless you *turn on* the
> search domain logic).
>
>> Right.  If software (or documentation) uses “gateway” to mean “address
>> of the default gateway”, it will break, depending on search path
>> configuration and other network properties.
>>
>> I don't think this is what Fedora wants (and what you intended).
>
> I disagree. It only breaks if the user enables domain search logic,
> and configures a domain in there that actually serves a host called
> "gateway".

Which from my time, a good 10 years or so, at a large global service
provider and as a Red Hat consultant on customer sites both of those
were often true so I'm not sure it's something that you can assume
either way. And given on those networks there's generally LOT of
legacy platforms that make assumptions about that sort of thing I'm
not sure it's something you can just turn around and say "well just
turn it off you idiots".

Peter
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 25, 2016 at 06:16:13PM -0600, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> Better to just run a script to fix those overnight, and than deal
> ZJ> with any fallout.
> 
> Sure, I could, but I figured it's at least worth informing people.
> Maybe there's some use case for this of which I'm not aware.  Or perhaps
> I've made a mistake and include some packages in my list which should
> not be there.

But you said "consider fixing those if you can", and not "drop me
a note to opt out" ;)

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf dependency information for koji builds

[Mikolaj Izdebski]

On 01/23/2016 04:14 PM, Orion Poplawski wrote:
> It would be very helpful to have information on what packages are
> pulling in what dependencies in the root.log of koji builds.  Is this
> possible with dnf?

I've quickly hacked a proof-of-concept script to do that:

  https://gist.github.com/mizdebsk/21e5fd776aa4ba577582

The script is ran with taskId of buildArch Koji task as argument.
It should print on stdout list of packages in buildroot with dependency
information. Each line of output is in form:

  A: B, C, D

which means that package A pulled in packages B, C and D.
The script can be easily adjusted to do more interesting stuff.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> Better to just run a script to fix those overnight, and than deal
ZJ> with any fallout.

Sure, I could, but I figured it's at least worth informing people.
Maybe there's some use case for this of which I'm not aware.  Or perhaps
I've made a mistake and include some packages in my list which should
not be there.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora Rawhide 20160125 compose check report

[Adam Williamson]

On Mon, 2016-01-25 at 12:21 -0800, Adam Williamson wrote:
> On Mon, 2016-01-25 at 15:57 +, Fedora compose checker wrote:
> > Missing expected images:
> > 
> > Kde disk raw armhfp
> > 
> > No images in this compose but not Rawhide 20160124
> > 
> > Images in Rawhide 20160124 but not this:
> > 
> > Cloud_atomic vagrant virtualbox x86_64
> > Cloud_atomic vagrant libvirt x86_64
> 
> Looks like there's some kind of timing issue going on here, causing the
> compose check to get tired of waiting for the openQA tests to complete
> and send the email before they're done. Most likely the compose is
> turning up later than it used to. I'll look into it and make whatever
> adjustments to the timers/timeouts seem necessary, sorry for the
> incomplete reports!

Ah, so unfortunately it's not quite so simple. What actually happened
was a problem while check-compose was waiting for the openQA tests to
complete.

What check-compose does is it asks openQA if all the tests for the
compose being checked are done. If they're not yet, it goes to sleep
for a couple of minutes, wakes up, and asks again. It keeps doing that
until all the tests are done (or it hits a configurable timeout).

If it gets some kind of erroneous response when it tries to talk to
openQA, it sleeps 5 seconds and tries again. It does that cycle 5
times, but if it hits 5 bad responses in a row, it decides something's
seriously wrong with openQA, and gives up waiting. It also gives up
waiting *immediately* if it gets a ConnectionError from python-
requests. If check-compose gives up waiting, it sends out the report
immediately - without the openQA results. That's what happened here:
check-compose woke up and waited for results as usual for 50 minutes or
so, but then it hit some kind of error and gave up waiting. I *think*
it probably hit the ConnectionError case.

Looking at the Apache logs it seems like the openQA web server stopped
responding to requests briefly around the time of the check-compose
failure. (openQA uses a reverse proxy setup; openQA itself runs a non-
externally-accessible web server process on a non-standard port, Apache
faces outward and proxies requests for the openQA domain through to the
openQA server). This...seems to happen occasionally. It used to happen
quite a lot when the openQA server box also ran all the tests - heavy
test load would cause the server to stop responding. It happens much
less now the server VMs aren't also running tests, but it seems like it
did happen last night, it's *possibly* happening when we're saving hard
disk images from completed tests to use as a base for later tests (the
worker box has to upload a rather large disk image file to the openQA
server, which seems like it can cause the server to struggle).

For now I think I'm gonna make the 'wait' code (which is really in the
openQA python client, not in check-compose itself) a bit more forgiving
- have it retry for a bit longer than ~30 seconds, and have it retry on
ConnectionError too, instead of immediately bailing. (I can't find a
very detailed reference on all the situations in which python-requests
raises ConnectionError - the best I can find is "In the event of a
network problem (e.g. DNS failure, refused connection, etc), Requests
will raise a ConnectionError exception.", which is kind
of...lacking...so just treating it as something we might recover from
seems reasonable). Hopefully that'll mitigate this for now.

In the Glorious Future, of course, openQA sends out a fedmsg when it
completes the tests for a compose, so we don't have to have things sit
around 'waiting' for the tests to complete by yelling "ARE WE THERE
YET?!" at the server every two minutes. Implementation of the Glorious
Future isscheduled.
-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf dependency information for koji builds

[Mikolaj Izdebski]

On 01/25/2016 11:37 AM, Michael Schroeder wrote:
> On Sat, Jan 23, 2016 at 04:26:43PM +0100, Dan Horák wrote:
>> On Sat, 23 Jan 2016 08:14:44 -0700
>> Orion Poplawski  wrote:
>>
>>> It would be very helpful to have information on what packages are 
>>> pulling in what dependencies in the root.log of koji builds.  Is this 
>>> possible with dnf?
>>
>> I'm worried it's similar to the issue discussed in
>> https://bugzilla.redhat.com/show_bug.cgi?id=1148627 where libsolv
>> provides only the top level result.
> 
> It's not libsolv that only provides the top level result. libsolv provides
> all the needed data, it's dnf/hawkey that only displays the top level.
> 
> Regarding the pulled in dependencies, libsolv also provides that, but
> hawkey doesn't have an API for it (yet?).

It is possible to reconstruct dependency graph from hawkey sack.

(Koschei does that to compute "dependency distance" - minimal number of
edges you need to traverse in order to get from SRPM to given
build-dependency package. [1])

[1]
https://github.com/msimacek/koschei/blob/fd48addd9f401889916dc7e58893bc563dcca909/koschei/util.py#L312

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 25, 2016 at 04:34:55PM -0600, Jason L Tibbitts III wrote:
> A huge list of packages and owners follows.  Please consider cleaning up
> your packages if you can.  (Yes, I have some on the list, which
> I've fixed already.)  Packagers with no owners listed might have been
> orphaned or retired but are still showing up in the spec tarball.

I agree with what poeple said on IRC: involving all those maintainers
is mostly a waste of time. Better to just run a script to fix those overnight,
and than deal with any fallout.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Test-Announce] Planned Outage: Taskotron upgrade - 2016-01-26 @ 15:00 UTC

[Tim Flink]

Planned Outage: taskotron.fedoraproject.org - 2016-01-26 15:00 UTC

There will be an outage starting at 2016-01-26 15:00 UTC, which will
last approximately 3 hours.

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

date -d '2016-01-26 15:00 UTC'

Reason for outage:

We will be performing a major upgrade on the production Taskotron
instance which requires downtime while we rebuild and migrate the
backing machines.

Affected Services:

taskotron.fedoraproject.org

Services not listed are not affected by this outage.

Contact Information:

Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5073

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


pgpF6wYp1o_Mq.pgp
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: The %license property is now supported in EPEL6 - breaks SCL build

[Jason L Tibbitts III]

> "RC" == Remi Collet  writes:

RC> FYI, I just open an issue to have this reverted.
RC> https://fedorahosted.org/fedora-infrastructure/ticket/5071

Well that was not particularly nice.  Why can't we work together to fix
any bugs?

In any case, I can't reproduce the breakage myself using the spec
provided in the bugzilla ticket so it's kind of difficult for me to
debug.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora Rawhide 20160125 compose check report

[Adam Williamson]

On Mon, 2016-01-25 at 15:57 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Kde disk raw armhfp
> 
> No images in this compose but not Rawhide 20160124
> 
> Images in Rawhide 20160124 but not this:
> 
> Cloud_atomic vagrant virtualbox x86_64
> Cloud_atomic vagrant libvirt x86_64

Looks like there's some kind of timing issue going on here, causing the
compose check to get tired of waiting for the openQA tests to complete
and send the email before they're done. Most likely the compose is
turning up later than it used to. I'll look into it and make whatever
adjustments to the timers/timeouts seem necessary, sorry for the
incomplete reports!
-- 
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging practices and hardened packages

[Jan Kratochvil]

On Mon, 25 Jan 2016 19:16:33 +0100, Kevin Fenzi wrote:
> so you could well have an update that isn't the current one that has no
> debuginfo on mirrors, but you could always get it from koji. 

If you have only a core file you know build-ids dumped there but not NVRAs.
build-id -> NVRA mapping was provided by
https://fedoraproject.org/wiki/Darkserver
but currently it AFAIK does not work.  Besides that even Koji clears the
builds pretty soon.  These issues are addressed by ABRT servers.


Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging practices and hardened packages

[Kevin Fenzi]

On Mon, 25 Jan 2016 20:12:44 +0300
Roman Tsisyk  wrote:

> One more question.
> How long debuginfo packages are stored in repositories?
> For example, someone may have an old version of package for which
> debuginfo already has gone. How to debug in this case?

They are kept just like any other subpackages of a package. ;) 

So, if it's ever been a stable update or used in a final compose, the
package it kept forever in koji. Packages at final release are kept
forever. Of course for updates only the current packages are included,
so you could well have an update that isn't the current one that has no
debuginfo on mirrors, but you could always get it from koji. 

kevin


pgpjyPNy38niI.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging practices and hardened packages

[Jan Kratochvil]

On Mon, 25 Jan 2016 18:12:44 +0100, Roman Tsisyk wrote:
> How long debuginfo packages are stored in repositories?
> For example, someone may have an old version of package for which debuginfo
> already has gone.
> How to debug in this case?

ABRT retrace server has some storage and infrastructure for that.


Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [design-suite] Broken packages

[Jon Ciesla]

On Mon, Jan 25, 2016 at 11:48 AM, Jonathan Wakely  wrote:

> On 25/01/16 11:04 +, Jonathan Wakely wrote:
>
>> On 24/01/16 14:35 -0600, Jon Ciesla wrote:
>>
>>> On Sun, Jan 24, 2016 at 1:47 PM, Luya Tshimbalanga <
>>> l...@fedoraproject.org>
>>> wrote:
>>>
>>> Checking the nightly compose from Design Suite Lab[1], these packages
 are currently broken according to root.log[2] : Blender,
 LuxRender-Blender, Synfig, Calligra-Krita

 synfig-0.64.3-8.fc24.x86_64 requires
 libboost_program_options.so.1.59.0()(64bit)

 Working on it, it doesn't build as-is in rawhide.
>>>
>>
>> Does it work if you just add -std=gnu++11 ?
>>
>
> I've pushed a fix to make synfig build with C++11, and added a patch
> for a gcc5 bug when using C++11 (which will be fixed in gcc6).
>
> It's building now.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Thank you!

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Mattias Ellert]

mån 2016-01-25 klockan 18:09 +0100 skrev Marcin Juszkiewicz:
> W dniu 25.01.2016 o 17:03, Vít Ondruch pisze:
> > So it appears this thread was probably not enough. Which keeps us with
> > interesting state where mock by default does not install weak
> > dependencies where Koji installs them. It causes interesting issues already.
> 
> mock/koji not installing weak dependencies == anything wanting ruby 
> being broken.
> 
> Reason: "ruby" suggests "rubypick" which suggests "ruby".
> 
> Packages buildrequire "ruby" but do not get "rubypick" installed (or if 
> they are lucky they get) so are unable to find Ruby because there is no 
> "/bin/ruby" executable.

If ruby needs ruby-pick to work, then ruby-pick must not be a weak
dependency of ruby, but a hard one.

The koji buildroot really should only install hard dependencies. The
buildroot is supposed to be the minimal possible set needed to build
the package. If a package that would be installed as a weak dependency
of one of the build dependencies is needed to build the package, that
packa is a build dependency too.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [design-suite] Broken packages

[Jonathan Wakely]

On 25/01/16 11:04 +, Jonathan Wakely wrote:

On 24/01/16 14:35 -0600, Jon Ciesla wrote:

On Sun, Jan 24, 2016 at 1:47 PM, Luya Tshimbalanga 
wrote:


Checking the nightly compose from Design Suite Lab[1], these packages
are currently broken according to root.log[2] : Blender,
LuxRender-Blender, Synfig, Calligra-Krita

synfig-0.64.3-8.fc24.x86_64 requires
libboost_program_options.so.1.59.0()(64bit)


Working on it, it doesn't build as-is in rawhide.


Does it work if you just add -std=gnu++11 ?


I've pushed a fix to make synfig build with C++11, and added a patch
for a gcc5 bug when using C++11 (which will be fixed in gcc6).

It's building now.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re[2]: Debugging practices and hardened packages

[Roman Tsisyk]

> Saturday, January 23, 2016 9:36 PM UTC from Zbigniew Jędrzejewski-Szmek 
> :
> 
> On Sat, Jan 23, 2016 at 08:12:06PM +0300, Roman Tsisyk wrote:
> > > Thursday, January 14, 2016 10:03 AM -06:00 from Michael Catanzaro 
> > > :
> > > 
> > > 
> > > 'coredumpctl gdb' is great and you will enjoy it!
> > > 
> > 
> > I have problems with `coredump gdb` and `coredump dump` on rawhide:
> > 
> > ```
> > # coredumpctl list
> > TIMEPID   UID   GID SIG PRESENT EXE
> > Sat 2016-01-23 19:58:31 MSK   21237   995   992   6   /usr/bin/tarantool
> If there is no little star here   ^,
> then coredumpctl doesn't see the core file.

Probably I had limited disk space on that machine.
I've tried on another rawhide box and coredumpctl works well:

TIMEPID   UID   GID SIG PRESENT EXE
Mon 2016-01-25 16:51:09 MSK   12653   989   983   6 * /usr/bin/tarantool
/var/lib/systemd/coredump/ is not empty



One more question. 
How long debuginfo packages are stored in repositories?
For example, someone may have an old version of package for which debuginfo 
already has gone.
How to debug in this case?

-- 
WBR,
   Roman Tsisyk 
   http://tarantool.org/ - an efficient in-memory data store and a Lua 
application server
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Marcin Juszkiewicz]

W dniu 25.01.2016 o 17:03, Vít Ondruch pisze:

So it appears this thread was probably not enough. Which keeps us with
interesting state where mock by default does not install weak
dependencies where Koji installs them. It causes interesting issues already.


mock/koji not installing weak dependencies == anything wanting ruby 
being broken.


Reason: "ruby" suggests "rubypick" which suggests "ruby".

Packages buildrequire "ruby" but do not get "rubypick" installed (or if 
they are lucky they get) so are unable to find Ruby because there is no 
"/bin/ruby" executable.


https://bugzilla.redhat.com/show_bug.cgi?id=1300669 shows how it look on 
aarch64.


> Not sure if I should prepare my packages to be ready or not 

"rubypick" is yours ;D
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: hawaii

[Sérgio Basto]

Hi,

On Seg, 2016-01-25 at 13:40 +0100, Vít Ondruch wrote:
> Dne 22.1.2016 v 21:12 Pier Luigi Fiorini napsal(a):
> > 2016-01-22 20:58 GMT+01:00 Kevin Fenzi :
> > > On Fri, 22 Jan 2016 19:46:12 -
> > > " mastaiza"  wrote:
> > > 
> > > > Yes hawaii-shell .
> > > > Here on this page
> > > > https://fedoraproject.org/wiki/Changes/Hawaii_Desktop specify
> > > this
> > > > command.
> > > 
> > > Yeah, that change is marked (as you can see at the bottom) as
> > > Incomplete.
> > > 
> > > So, it's never been finished and formally submitted.
> > > 
> > > You should mail the Owner(s) directly asking if they plan to
> > > continue
> > > or if the command is expected to work yet.
> > > 
> > > kevin
> > > 
> > > 
> > All significant packages are now available except for the settings
> > application that is under review.
> > Mean time I'll read what's supposed to be the next step to formally
> > submit the change.
> > 
> Just in case:
> 
> https://fedoraproject.org/wiki/Changes/Policy
> 
> And you might be interested in schedule especially:
> 
> https://fedoraproject.org/wiki/Releases/24/Schedule
> 
> since the proposal submission deadline is 2016-02-02.

At least, you may provide some instructions to install it ... 
 
https://fedoraproject.org/wiki/Changes/Hawaii_Desktop#User_Experience

dnf install @hawaii
Warning: Group 'hawaii' does not exist.

How I install it ? 

Thanks, 

> 
> Vít
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Mon, 25.01.16 17:11, Florian Weimer (fwei...@redhat.com) wrote:

> On 01/25/2016 03:23 PM, Lennart Poettering wrote:
> > On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.com) wrote:
> > 
> >>> It is intended as a convenient fallback mechanism, and is only supposed
> >>> to have an effect if 'gateway' is not defined in the local DNS (the
> >>> 'domain' or 'search' zones). Would it help if those limitations were
> >>> more explicit, e.g. documented in nss-myhostname(8)?
> >>
> >> I understand that the goal is that nss_myhostname will not override
> >> existing names, due to the way the NSS is configured.
> >>
> >> What I do not understand is how the the “gateway” name can be
> >> useful.
> > 
> > Here's a very obvious, trivial example: wherever I am I can now simply
> > type "ping gateway" to know whether connectivity to my local router
> > works.
> 
> But that's not actually true, isn't it?  If nss_myhostname doesn't
> override “gateway”, the outcome depends on the network you are on.  With
> a captive portal, you are likely pinging the portal server, not the
> default gateway.  And if you are on one of Microsoft's corporate
> networks, you might end up at gateway.microsoft.com (whatever this
> is).

Well, IRL you'd actually quickly notice, since ping shows you the full
fqdn of the host, and hence gives you a very clear hint on what it is
actually pinging. 

> Because it's so unreliable, we cannot put this trick into documentation,
> and we shouldn't train users to rely on this functionality.

Yeah, single-label names are like that. If you want trustable
single-label names, you better shouldn't use search domains (and quite
frankly, I am not particularly a fan of the search domain concept
myself, because of its ambiguities. In systemd-resolved we by default
ignore the DHCP-reported search domains because of this.)

Note that systemd-resolved's LLMNR implementation actually excepts
itself from resolving "gateway" even though a single-label name (it
also excepts itself from a couple of other names, such as
"localhost"). Which basically means: the "gateway" name is safe
exactly when you turn off the search domain logic (or to put this
correctly if networkd is used: it is safe unless you *turn on* the
search domain logic).

> Right.  If software (or documentation) uses “gateway” to mean “address
> of the default gateway”, it will break, depending on search path
> configuration and other network properties.
> 
> I don't think this is what Fedora wants (and what you intended).

I disagree. It only breaks if the user enables domain search logic,
and configures a domain in there that actually serves a host called
"gateway".

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


4 packages were orphaned

lexertl [f23, f22, master] was orphaned by jjames
 Modular lexical analyzer generator
 https://admin.fedoraproject.org/pkgdb/package/lexertl
libpuma [f23, f22, master] was orphaned by jjames
 Library for parsing and manipulating C/C++ source code
 https://admin.fedoraproject.org/pkgdb/package/libpuma
tex-zfuzz [f23, f22, master] was orphaned by jjames
 Type-checker and LaTeX style for Z spec language
 https://admin.fedoraproject.org/pkgdb/package/tex-zfuzz
undertaker [f23, f22, master] was orphaned by jjames
 Find always-on and always-off conditional C code
 https://admin.fedoraproject.org/pkgdb/package/undertaker

5 packages were retired

KPMcore [master] was retired by mattia
 Library for managing partitions by KDE programs
 https://admin.fedoraproject.org/pkgdb/package/KPMcore
nautilus-open-terminal [master] was retired by pfrields
 Nautilus extension for an open terminal shortcut
 https://admin.fedoraproject.org/pkgdb/package/nautilus-open-terminal
openstack-glance [master] was retired by apevec
 OpenStack Image Service
 https://admin.fedoraproject.org/pkgdb/package/openstack-glance
python-sqlalchemy [epel7] was retired by kevin
 Modular and flexible ORM library for python
 https://admin.fedoraproject.org/pkgdb/package/python-sqlalchemy
radiusclient-ng [master] was retired by nmav
 RADIUS protocol client library
 https://admin.fedoraproject.org/pkgdb/package/radiusclient-ng

1 packages unorphaned
-
python-webob [el6, epel7] was unorphaned by ricky
 WSGI request and response object
 https://admin.fedoraproject.org/pkgdb/package/python-webob

0 packages were unretired


9 packages were given

mod_extract_forwarded [el6] was given by timj to dmaphy
 Extract real source IP for forwarded HTTP requests
 https://admin.fedoraproject.org/pkgdb/package/mod_extract_forwarded
octave [f23, f22, master] was given by jcapik to orion
 A high-level language for numerical computations
 https://admin.fedoraproject.org/pkgdb/package/octave
openstack-ironic-python-agent [master] was given by trown to apevec
 A python agent for provisioning and deprovisioning Bare Metal servers
 https://admin.fedoraproject.org/pkgdb/package/openstack-ironic-python-agent
os-apply-config [f23, f22, master] was given by sdake to apevec
 Configure files from cloud metadata
 https://admin.fedoraproject.org/pkgdb/package/os-apply-config
os-collect-config [f23, f22, master] was given by sdake to apevec
 Collect and cache metadata running hooks on changes
 https://admin.fedoraproject.org/pkgdb/package/os-collect-config
os-refresh-config [f23, f22, master] was given by sdake to apevec
 Refresh system configuration
 https://admin.fedoraproject.org/pkgdb/package/os-refresh-config
python-dateutil [el5] was given by hguemar to mcepl
 Powerful extensions to the standard datetime module
 https://admin.fedoraproject.org/pkgdb/package/python-dateutil
python-webob [f23, f22, master, el5] was given by ricky to mrunge
 WSGI request and response object
 https://admin.fedoraproject.org/pkgdb/package/python-webob
samtools [f23, f22, master] was given by ron to verdurin
 Tools for nucleotide sequence alignments in the SAM format
 https://admin.fedoraproject.org/pkgdb/package/samtools

0 packages had new branches



Sources: https://github.com/pypingou/fedora-owner-change
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/25/2016 03:23 PM, Lennart Poettering wrote:
> On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.com) wrote:
> 
>>> It is intended as a convenient fallback mechanism, and is only supposed
>>> to have an effect if 'gateway' is not defined in the local DNS (the
>>> 'domain' or 'search' zones). Would it help if those limitations were
>>> more explicit, e.g. documented in nss-myhostname(8)?
>>
>> I understand that the goal is that nss_myhostname will not override
>> existing names, due to the way the NSS is configured.
>>
>> What I do not understand is how the the “gateway” name can be
>> useful.
> 
> Here's a very obvious, trivial example: wherever I am I can now simply
> type "ping gateway" to know whether connectivity to my local router
> works.

But that's not actually true, isn't it?  If nss_myhostname doesn't
override “gateway”, the outcome depends on the network you are on.  With
a captive portal, you are likely pinging the portal server, not the
default gateway.  And if you are on one of Microsoft's corporate
networks, you might end up at gateway.microsoft.com (whatever this is).

Because it's so unreliable, we cannot put this trick into documentation,
and we shouldn't train users to rely on this functionality.

>> As I tried to explain above, I'm not really worried about nss_myhostname
>> overriding name resolution, but that software relies on the specific
>> functionality of the “gateway” name provided by nss_myhostname, but
>> *this* name is overridden by DNS (with a suitable search path) or
>> nss_files, so that it no longer resolves to the expected address.
> 
> Search lists are local configuration. Software which relies on
> specific search paths to be configured will already break pretty much
> everywhere...

Right.  If software (or documentation) uses “gateway” to mean “address
of the default gateway”, it will break, depending on search path
configuration and other network properties.

I don't think this is what Fedora wants (and what you intended).

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Vít Ondruch]

Dne 25.1.2016 v 17:03 Vít Ondruch napsal(a):
> Dne 12.1.2016 v 15:18 Vít Ondruch napsal(a):
>> Dne 18.8.2015 v 16:26 Vít Ondruch napsal(a):
>>> Hi all,
>>>
>>> Today, I noticed that mock build root prepared by DNF is significantly
>>> larger then prepared by YUM (see attached logs). Owners of packages
>>> installed into minimal buildroot probably wants to review their
>>> dependency chain.
>>>
>>> I also reported the issue against DNF [1] in case DNF guys wants to
>>> improve this situation.
>>>
>>>
>>> Vít
>>>
>>>
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1254634
>>>
>> This change does not look to be reflected on Koji, so I opened
>>
>> https://fedorahosted.org/rel-eng/ticket/6330
>>
>>
>> Vít
> So this request was rejected:
>
>
>
> Changes (by ausil):
>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  after thinking about this some I think that all deps should be installed
>  into the buildroot. I am going to close this as won't fix. This really
>  needs to have more thought. and discussion before anything is done. there
>  is work, tradeoffs and unexpected results regardless of what is done.
>
>
>
> So it appears this thread was probably not enough. Which keeps us with
> interesting state where mock by default does not install weak
> dependencies where Koji installs them. It causes interesting issues already.
>
> Not sure if I should prepare my packages to be ready or not 
>
>
> Vít

Actually there is the upstream Koji ticket opened:

https://fedorahosted.org/koji/ticket/326#comment:4

So there is still some hope :)


Vít
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Build root prepared by DNF is way larger

[Vít Ondruch]

Dne 12.1.2016 v 15:18 Vít Ondruch napsal(a):
> Dne 18.8.2015 v 16:26 Vít Ondruch napsal(a):
>> Hi all,
>>
>> Today, I noticed that mock build root prepared by DNF is significantly
>> larger then prepared by YUM (see attached logs). Owners of packages
>> installed into minimal buildroot probably wants to review their
>> dependency chain.
>>
>> I also reported the issue against DNF [1] in case DNF guys wants to
>> improve this situation.
>>
>>
>> Vít
>>
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1254634
>>
>
> This change does not look to be reflected on Koji, so I opened
>
> https://fedorahosted.org/rel-eng/ticket/6330
>
>
> Vít

So this request was rejected:



Changes (by ausil):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 after thinking about this some I think that all deps should be installed
 into the buildroot. I am going to close this as won't fix. This really
 needs to have more thought. and discussion before anything is done. there
 is work, tradeoffs and unexpected results regardless of what is done.



So it appears this thread was probably not enough. Which keeps us with
interesting state where mock by default does not install weak
dependencies where Koji installs them. It causes interesting issues already.

Not sure if I should prepare my packages to be ready or not 


Vít
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide 20160125 compose check report

[Fedora compose checker]

Missing expected images:

Kde disk raw armhfp

No images in this compose but not Rawhide 20160124

Images in Rawhide 20160124 but not this:

Cloud_atomic vagrant virtualbox x86_64
Cloud_atomic vagrant libvirt x86_64
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: AWS stuff in EPEL (aka: have I broke bodhi?)

[Kevin Fenzi]

On Mon, 25 Jan 2016 13:52:31 +0100
Fabio Alessandro Locati  wrote:

> Hello,
> 
> I'm speaking about the following two bodhi updates:
> 
> - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-49246e36a3
> - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c576a00844
> 
> Both seems to be in both testing and pending testing status.
> 
> How I did it?
> - Create the bodhi update
> - Unpush the bodhi update
> - Push the bodhi update back to testing
> 
> The packages had dependency problems that I've fixed in the meantime
> but I was not expecting to solve them so quickly.
> 
> In the repo testing [0][1] they do not appear, so my guess is that in
> reality they are in pending-testing but for some reason the masher
> does not pick them up (probably for the push-unpush-push thing).
> 
> How can I make it work again?

They look fine to me, and should go out in the next updates push. 

They were submitted to testing to late to be in the last one yesterday. 

kevin


pgpk6TNjF6Zt7.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Mon, 25.01.16 09:08, Florian Weimer (fwei...@redhat.com) wrote:

> > It is intended as a convenient fallback mechanism, and is only supposed
> > to have an effect if 'gateway' is not defined in the local DNS (the
> > 'domain' or 'search' zones). Would it help if those limitations were
> > more explicit, e.g. documented in nss-myhostname(8)?
> 
> I understand that the goal is that nss_myhostname will not override
> existing names, due to the way the NSS is configured.
> 
> What I do not understand is how the the “gateway” name can be
> useful.

Here's a very obvious, trivial example: wherever I am I can now simply
type "ping gateway" to know whether connectivity to my local router
works.

I also know that in my local wlan, as well as in the one of my
girlfriend's or my parent's: I can reconfigure the router by typing
http://gateway/ into my webbrowser, without having to check IP
configuration, leave the web browser, or even know the router's brand
or default configuration.

> As I tried to explain above, I'm not really worried about nss_myhostname
> overriding name resolution, but that software relies on the specific
> functionality of the “gateway” name provided by nss_myhostname, but
> *this* name is overridden by DNS (with a suitable search path) or
> nss_files, so that it no longer resolves to the expected address.

Search lists are local configuration. Software which relies on
specific search paths to be configured will already break pretty much
everywhere...

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/22/2016 01:06 PM, Florian Weimer wrote:
> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
> 
>> PS - There is some other discussion around "mymachines" which seems much
>> more problematic.  I'd like to just focus on myhostname for now.  The
>> glibc maintainer has indicated that he wants to wait for mymachines to be
>> resolved, but it's almost two months now and I don't see that being
>> resolved soon.
> 
> I still have philosophical objects to myhostname as well.  I find it odd 
> that at one end, we struggle with DNS name space hijacking, but on another
> end, we do basically the same thing:
> 
> 
> 
> The order in nsswitch.conf does not matter (and neither does any non-DNS 
> name resolution mechanism) because if we end up having software which 
> expects that “gateway” resolves to the IP address of the default gateway,
> we still have an interoperability problem.  And if “gateway” is never
> intended for name resolution, why synthesize the name at all?


For what it's worth, nss_myhostname is extremely valuable even without
"gateway". Having the the machine's hostname automatically resolving even to
DHCP-assigned addresses solves a lot of issues, including some extremely
common ones related to FreeIPA installation.

So if nothing else, I'd really like to see this feature back to being
installed by default.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlamMT4ACgkQeiVVYja6o6NuYwCgsByDXdtc2Ok1zwtdgSXOTN01
/RsAnRdCAjMDFD6Vch3kN4Bdo/B7IC9z
=BOZh
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Lennart Poettering]

On Fri, 22.01.16 19:06, Florian Weimer (fwei...@redhat.com) wrote:

> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
> 
> > PS - There is some other discussion around "mymachines" which seems much 
> > more
> > problematic.  I'd like to just focus on myhostname for now.  The glibc
> > maintainer has indicated that he wants to wait for mymachines to be 
> > resolved,
> > but it's almost two months now and I don't see that being resolved soon.
> 
> I still have philosophical objects to myhostname as well.  I find it odd
> that at one end, we struggle with DNS name space hijacking, but on
> another end, we do basically the same thing:
> 
>   
> 
> The order in nsswitch.conf does not matter (and neither does any non-DNS
> name resolution mechanism) because if we end up having software which
> expects that “gateway” resolves to the IP address of the default
> gateway, we still have an interoperability problem.  And if “gateway” is
> never intended for name resolution, why synthesize the name at all?

nss-myhostname and systemd-resolved map the "gateway" name to the
addresses of the locally configured default routing gateway. Note that
we only do this for the single-label "gateway". A such it might
conflict with LLMNR names (which are all single-label names) as well
as search domain lists (which are generally applied to single-label
names), but generally not with classic DNS fqdns. This is because
A/ RRs are generally not assigned to TLDs, and while that's not a
strict requirement (and in fact there are some TLDs which have A/
RRs, such as .dk), this is strongly recommended against by many
internet organizational bodies, including ICANN and IAB:

https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-08-13-en
https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/

They recommend against allowing TLDs with address RRs specifically
because they conflict with local uses of single-label domains, in the
contexts of search lists and systems such as LLMNR.

Now, with that background, which clearly suggests that single-label
names are subject to *local* interpretation, nss-myhostnames resolves
"gateway" locally to the locally configured gateway, and I believe
that's completely within the idea and general accepted logic of
single-label domains. Now, you can argue this might create conflicts
with search domain logic and LLMNR, but well, the basic idea of
LLMNR/search lists is that it is non-organized, that it creates a very
local view of the worrld and subject to first-come-first-serve
conflicts.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python naming guidelines clarification

[Thomas Spura]

Zbigniew Jędrzejewski-Szmek  schrieb am Do., 21. Jan.
2016 um 16:50 Uhr:

> On Thu, Jan 21, 2016 at 02:36:00PM +0100, Jan Včelák wrote:
> > On Thu, Jan 21, 2016 at 2:12 PM, Robert Kuska  wrote:
> > >> And what is the best current practice if the library contains some
> > >> utilities. Should the utilities land in the python{2,3}-name package?
> > >> Should it land in both?
> > >>
> > >> To give you an example, the ripe.atlas.sagan ships a utility
> > >> parse_abuf. I'm currently removing it from the package as the upstream
> > >> is going to deprecate it with the next release. But theoretically,
> > >> should the utility be included in python2-ripe-atlas-sagan as
> > >> parse_abuf2 and in python3-ripe-atlas-sagan as parse_abuf? Or would it
> > >> be better for instance to create a package ripe-atlas-sagan which will
> > >> contain just the Python 3 version of the utility?
> > >
> > > As I suggested in my email before, package just one version running on
> > > Python3 (if supported) when utility provides same functionality
> whether run
> > > with Python3 or Python2.
> > >
> > > There are special cases when you have to provide bin files for both
> major
> > > versions of python, good example is python-pip (python3-pip installs
> python3
> > > modules, python2-pip installs python2 modules).
> > >
> > > Here are conventions for naming executables and some mentions about
> > > Python2/Python3 executables conflicts:
> > > https://fedoraproject.org/wiki/Packaging:Python#Naming
> > >
> > > I believe that your confusion (you are not alone) is caused by
> misleading
> > > example specfile in python packaging guidelines and lack of verbosity
> > > about such cases, I already tried to argue about changing it
> > > https://fedorahosted.org/fpc/ticket/558#comment:6
> > >
> > > Lets assume python project named `example` which ships executable
> `example`:
> > >
> > > 1. `example` is pure application, supports Python3 -
> > > I package it as `example` with executable `example` running on
> Python3, all
> > > backend libraries will be also packaged under `example` rpm as they
> are not meant
> > > to be used as libraries in other projects
> > >
> > > 2. `example` is application and it also ships libraries which may be
> used in
> > > other projects -
> > > I package it as `example` which will ship executable `example` running
> on Python3,
> > > I will build it for both Python2 and Python3 and package its libraries
> under
> > > python2-example and python3-example, (hence `example` will require
> `python3-example`)
> > >
> > > 3. `example` is application with different behaviour for both major
> python versions -
> > > I package `example` as `python-example` with `python2-example` and
> `python3-example`
> > > subpackages carrying both backends libraries and executables,
> unversioned executable
> > > `example` will be packaged under `python2-example` (hence running on
> python2).
>
> Yes, this is a very nice description. It would be great this become
> part of the guidelines, because this is an issue that comes up quite
> often. Current guidelines talk about case 3. prominently, but it
> actually quite rare, and most packages are either case 1. or 2.
>

Hopefully, cases 1 and 2 can be discussed in general, as it also applies to
other packages than just python:
https://fedoraproject.org/wiki/User:Tibbs/AppsVsLibs


> > > - Original Message -
> > >> From: "Jan Včelák" 
> > >> To: "Development discussions related to Fedora" <
> devel@lists.fedoraproject.org>
> > >> Sent: Thursday, January 21, 2016 12:40:47 PM
> > >> Subject: Re: Python naming guidelines clarification
> > >>
> > >> On Wed, Jan 20, 2016 at 11:54 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > >> > Yes, the guidelines apply to the source rpm name too. Those
> > >> > srpms should be called python-*, because they contain python
> libries.
>
> Here I assumed that your package is case 2. It looks like this
> from the description. If those modules can be used externally,
> than case 2. applies, if they cannot, then case 1. applies.
>
> Zbyszek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

AWS stuff in EPEL (aka: have I broke bodhi?)

[Fabio Alessandro Locati]

Hello,

I'm speaking about the following two bodhi updates:

- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-49246e36a3
- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c576a00844

Both seems to be in both testing and pending testing status.

How I did it?
- Create the bodhi update
- Unpush the bodhi update
- Push the bodhi update back to testing

The packages had dependency problems that I've fixed in the meantime but
I was not expecting to solve them so quickly.

In the repo testing [0][1] they do not appear, so my guess is that in
reality they are in pending-testing but for some reason the masher does
not pick them up (probably for the push-unpush-push thing).

How can I make it work again?

Best regards,
Fabio Alessandro Locati
-- 
Fabio Alessandro Locati

PGP Fingerprint: B960 BE9D E7A8 FA12 273A  98BB 6D6A 29D6 709A 7851
https://keybase.io/fale


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: hawaii

[Vít Ondruch]

Dne 22.1.2016 v 21:12 Pier Luigi Fiorini napsal(a):
> 2016-01-22 20:58 GMT+01:00 Kevin Fenzi  >:
>
> On Fri, 22 Jan 2016 19:46:12 -
> " mastaiza" mailto:mastaiza...@gmail.com>>
> wrote:
>
> > Yes hawaii-shell .
> > Here on this page
> > https://fedoraproject.org/wiki/Changes/Hawaii_Desktop specify this
> > command.
>
> Yeah, that change is marked (as you can see at the bottom) as
> Incomplete.
>
> So, it's never been finished and formally submitted.
>
> You should mail the Owner(s) directly asking if they plan to continue
> or if the command is expected to work yet.
>
> kevin
>
>
> All significant packages are now available except for the settings
> application that is under review.
> Mean time I'll read what's supposed to be the next step to formally
> submit the change.
>

Just in case:

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

And you might be interested in schedule especially:

https://fedoraproject.org/wiki/Releases/24/Schedule

since the proposal submission deadline is 2016-02-02.


Vít
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Jonathan Wakely]

On 13/01/16 11:07 +0200, Kari Koskinen wrote:

It is not too late. The point of updates testing is to catch problems
before they land in stable. Dealing with occasional downgrade is part
of running up dates testing. At this point it seems clear that updating
KeepasX to version 2 on Fedora 22 would be undesirable.


Given the keepassx 2.0.0 has a serious bug that causes it to corrupt
its database, with apparently no way to recover it, should it be
downgraded again in rawhide?

See https://bugzilla.redhat.com/show_bug.cgi?id=1282825#c36 for the
link to the bug.

The decision might be easier if F23 hadn't already been updated :-(
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [design-suite] Broken packages

[Jonathan Wakely]

On 24/01/16 14:35 -0600, Jon Ciesla wrote:

On Sun, Jan 24, 2016 at 1:47 PM, Luya Tshimbalanga 
wrote:


Checking the nightly compose from Design Suite Lab[1], these packages
are currently broken according to root.log[2] : Blender,
LuxRender-Blender, Synfig, Calligra-Krita

synfig-0.64.3-8.fc24.x86_64 requires
libboost_program_options.so.1.59.0()(64bit)


Working on it, it doesn't build as-is in rawhide.


Does it work if you just add -std=gnu++11 ?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf dependency information for koji builds

[Michael Schroeder]

On Sat, Jan 23, 2016 at 04:26:43PM +0100, Dan Horák wrote:
> On Sat, 23 Jan 2016 08:14:44 -0700
> Orion Poplawski  wrote:
> 
> > It would be very helpful to have information on what packages are 
> > pulling in what dependencies in the root.log of koji builds.  Is this 
> > possible with dnf?
> 
> I'm worried it's similar to the issue discussed in
> https://bugzilla.redhat.com/show_bug.cgi?id=1148627 where libsolv
> provides only the top level result.

It's not libsolv that only provides the top level result. libsolv provides
all the needed data, it's dnf/hawkey that only displays the top level.

Regarding the pulled in dependencies, libsolv also provides that, but
hawkey doesn't have an API for it (yet?).

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: Micro Bit

[Kushal Das]

On 17/01/16, Zbigniew Jędrzejewski-Szmek wrote:
> How does this relate to https://bugzilla.redhat.com/show_bug.cgi?id=1113915?

micro:bit MicroPython is a port with some key differences. No filesystem
, everything is in one file appended to the end of the firmware, few
extra modules like 'microbit', and 'music'. The GPIO access is done
differently.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
CentOS Cloud SIG lead
http://kushaldas.in
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: The %license property is now supported in EPEL6 - breaks SCL build

[Remi Collet]

Le 24/01/2016 14:02, Remi Collet a écrit :
>> epel-rpm-macros was added to the buildroot and buildsys-build group in comps 
>> which defines the macros

FYI, I just open an issue to have this reverted.
https://fedorahosted.org/fedora-infrastructure/ticket/5071


Remi.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F24 System Wide Change: Langpacks Using RPM Tags

[Jan Kurik]

= Proposed System Wide Change: Langpacks Using RPM Tags =
https://fedoraproject.org/wiki/Changes/LangpacksInstallationWithRPMWeakDependencies

Change owner(s):
* Parag Nemade 
* Jan Silhan 

Langpacks installations is re-designed using language metapackages
langpacks- and RPM weak dependencies (Supplements tag).


== Detailed Description ==
This is similar to what we have dnf langpacks plugin which is already
in Fedora but there is one missing thing that this plugin currently
does not provide automatic installation of langpacks. E.g. if you
enable or install Fedora in Japanese language then installation of any
base package like libreoffice-core or man-pages are not installing
automatically libreoffice-langpack-ja or man-pages-ja. This is because
dnf is not providing required hook to re-resolve the transaction
unlike yum. But now with using RPM tags or weak dependencies like
Supplements, we just need to ensure we have langpacks-xx metapackage
is already installed on the system and when a base package is getting
installed, it will pull its langpack for that xx language
automatically in the transaction set.

This will help in anaconda installation also. When particular set of
languages are selected in anaconda then anaconda should pull all the
required langpacks in the same initial installation.


== Scope ==
Proposal owners:
* Check all langpacks providing packages add Supplements tag in their
each langpack subpackage.
* Create metapackages like langpacks-. We have submitted
package review here:
https://bugzilla.redhat.com/show_bug.cgi?id=1300569

Other developers:
* To all other developers of packages who provides langpacks, they
need to add the Supplements tag as given in this draft guideline to
each langpack subpackage.

Release engineering: N/A

Policies and guidelines:
* Working with FPC on this new langpacks guideline:
https://fedoraproject.org/wiki/PackagingDrafts/Langpack
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Florian Weimer]

On 01/22/2016 10:45 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jan 22, 2016 at 07:06:26PM +0100, Florian Weimer wrote:
>> On 01/21/2016 11:18 PM, Orion Poplawski wrote:
>>
>>> PS - There is some other discussion around "mymachines" which seems much 
>>> more
>>> problematic.  I'd like to just focus on myhostname for now.  The glibc
>>> maintainer has indicated that he wants to wait for mymachines to be 
>>> resolved,
>>> but it's almost two months now and I don't see that being resolved soon.
>>
>> I still have philosophical objects to myhostname as well.  I find it odd
>> that at one end, we struggle with DNS name space hijacking, but on
>> another end, we do basically the same thing:
>>
>>   
>>
>> The order in nsswitch.conf does not matter (and neither does any non-DNS
>> name resolution mechanism) because if we end up having software which
>> expects that “gateway” resolves to the IP address of the default
>> gateway, we still have an interoperability problem.  And if “gateway” is
>> never intended for name resolution, why synthesize the name at all?
> 
> It is intended as a convenient fallback mechanism, and is only supposed
> to have an effect if 'gateway' is not defined in the local DNS (the
> 'domain' or 'search' zones). Would it help if those limitations were
> more explicit, e.g. documented in nss-myhostname(8)?

I understand that the goal is that nss_myhostname will not override
existing names, due to the way the NSS is configured.

What I do not understand is how the the “gateway” name can be useful.
As I tried to explain above, I'm not really worried about nss_myhostname
overriding name resolution, but that software relies on the specific
functionality of the “gateway” name provided by nss_myhostname, but
*this* name is overridden by DNS (with a suitable search path) or
nss_files, so that it no longer resolves to the expected address.

From my point of view, the fact that software (or the user) cannot know
that “gateway” resolves to the default gateway makes the name pretty
much useless.

What am I missing?

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org