Re: Lost KDC for FEDORAPROJECT.ORG realm

[Steve Dickson]

On 1/23/24 10:13 AM, Miro Hrončok wrote:

On 23. 01. 24 16:08, Steve Dickson wrote:

Hello,

I had to change my /etc/krb5.conf do to
some realm changes... and now when I
to a kinit to FEDORAPROJECT.ORG  it
hangs for a while then errors with

kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while 
getting initial credentials


My question is, what has to be in the /etc/krb5.conf
for the FEDORAPROJECT.ORG realm to be found?

In the past I didn't think there was anything in
the file and assume the realm was found by the

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

Any ideas?


There is an ongoing outage of FAS, see https://status.fedoraproject.org/


For once it is NOT me!!! :-)

Thanks everyone for the info!!! I'll keep an eye out.

steved.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Lost KDC for FEDORAPROJECT.ORG realm

[Steve Dickson]

On 1/23/24 10:08 AM, Steve Dickson wrote:

Hello,

I had to change my /etc/krb5.conf do to
some realm changes... and now when I
to a kinit to FEDORAPROJECT.ORG  it
hangs for a while then errors with

kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while 
getting initial credentials


My question is, what has to be in the /etc/krb5.conf
for the FEDORAPROJECT.ORG realm to be found?

In the past I didn't think there was anything in
the file and assume the realm was found by the

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/


On further review... it appears fedoraproject_org
in /etc/krb5.conf.d/ defines the KDC for  FEDORAPROJECT.ORG

[realms]
 FEDORAPROJECT.ORG = {
kdc = https://id.fedoraproject.org/KdcProxy
pkinit_anchors = FILE:/etc/pki/ipa/fedoraproject_ipa_ca.crt
 }

Has something change where I need to do some type of update?

steved.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Lost KDC for FEDORAPROJECT.ORG realm

[Steve Dickson]

Hello,

I had to change my /etc/krb5.conf do to
some realm changes... and now when I
to a kinit to FEDORAPROJECT.ORG  it
hangs for a while then errors with

kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while 
getting initial credentials


My question is, what has to be in the /etc/krb5.conf
for the FEDORAPROJECT.ORG realm to be found?

In the past I didn't think there was anything in
the file and assume the realm was found by the

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

Any ideas?

tia!

steved.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xmlParseMemory() and xmlParseMemory gone rawhide?

[Steve Dickson]

On 11/18/23 12:39 PM, Dan Horák wrote:

On Sat, 18 Nov 2023 12:30:04 -0500
Steve Dickson  wrote:


Hello,

When building an nfs-utils rpm in rawhide
I get the following errors:

xml.c: In function ‘junction_parse_xml_buf’:
xml.c:293:15: error: implicit declaration of function ‘xmlParseMemory’
[-Werror=implicit-function-declaration]
293 | tmp = xmlParseMemory(buf, (int)len);
|   ^~
xml.c:293:13: error: assignment to ‘xmlDocPtr’ {aka ‘struct _xmlDoc *’}
from ‘int’ makes pointer from integer without a cast
[-Werror=int-conversion]
293 | tmp = xmlParseMemory(buf, (int)len);
| ^
xml.c: In function ‘junction_xml_write’:
xml.c:390:9: error: ‘xmlIndentTreeOutput’ undeclared (first use in this
function)
390 | xmlIndentTreeOutput = 1;
| ^~~
xml.c:390:9: note: each undeclared identifier is reported only once for
each function it appears in
cc1: some warnings being treated as errors

Now I can build the upstream nfs-utils in rawhide, f39 and f38
without a problem... It is only when I try to build a rawhide
rpm that these errors happen. Any ideas??


https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-parser.html
says xmlParseMemory() has been deprecated and thus probably not
available in the rawhide build of libxml2.


Thank you!

steved.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

xmlParseMemory() and xmlParseMemory gone rawhide?

[Steve Dickson]

Hello,

When building an nfs-utils rpm in rawhide
I get the following errors:

xml.c: In function ‘junction_parse_xml_buf’:
xml.c:293:15: error: implicit declaration of function ‘xmlParseMemory’ 
[-Werror=implicit-function-declaration]

  293 | tmp = xmlParseMemory(buf, (int)len);
  |   ^~
xml.c:293:13: error: assignment to ‘xmlDocPtr’ {aka ‘struct _xmlDoc *’} 
from ‘int’ makes pointer from integer without a cast 
[-Werror=int-conversion]

  293 | tmp = xmlParseMemory(buf, (int)len);
  | ^
xml.c: In function ‘junction_xml_write’:
xml.c:390:9: error: ‘xmlIndentTreeOutput’ undeclared (first use in this 
function)

  390 | xmlIndentTreeOutput = 1;
  | ^~~
xml.c:390:9: note: each undeclared identifier is reported only once for 
each function it appears in

cc1: some warnings being treated as errors

Now I can build the upstream nfs-utils in rawhide, f39 and f38
without a problem... It is only when I try to build a rawhide
rpm that these errors happen. Any ideas??

tia,

steved.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FEDORA-2023-ed0c57b4ba — unspecified update for libtirpc — Fedora Updates System

[Steve Dickson]

On 10/25/23 12:20 PM, Adam Williamson wrote:

On Wed, 2023-10-25 at 12:03 -0400, Steve Dickson wrote:

Hello,

This update failed [1] due to a system timeout [2]
not a test failure... Is there some way to override
or wave the failure.


Failed tests are automatically retried one time. However,
for...reasons[0]...this isn't shown immediately in Bodhi; the test will
remain showing as 'failed' until the rerun completes (at which point
the result will become whatever the rerun's result was). You can see
the actual current status of testing on your update at
https://openqa.fedoraproject.org/tests/overview?build=Update-FEDORA-2023-ed0c57b4ba=38=fedora=2
- all tests are either green (passed) or blue (running) currently.

In general I monitor all openQA update test results and don't let
flakey results stand - if a test flakes twice in a row I will restart
it manually. Please check with me before waiving openQA results as it
can have problematic consequences if the problem *does* reproduce for
subsequent updates.

[0] https://progress.opensuse.org/issues/123625


Yes... it seemed to clear itself up! Thank you!

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

FEDORA-2023-ed0c57b4ba — unspecified update for libtirpc — Fedora Updates System

[Steve Dickson]

Hello,

This update failed [1] due to a system timeout [2]
not a test failure... Is there some way to override
or wave the failure.

tia,

steved.


[1] https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed0c57b4ba
[2] https://openqa.fedoraproject.org/tests/2225991#
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: python3 build failure

[Steve Dickson]

On 7/20/23 2:09 PM, Yaakov Selkowitz wrote:

On Thu, 2023-07-20 at 13:59 -0400, Steve Dickson wrote:

This bz[1] was opened on one of my packages not building on f39.
I did a quick rawhide scratch build and sure enough
the build fails with [2]


The important part is earlier in the log:

ModuleNotFoundError: No module named 'distutils'

distutils was removed in 3.12 for https://peps.python.org/pep-0632/

Solution: Add BuildRequires: python3-setuptools to get it building for
now, and work with upstream to migrate to a modern Python packaging
setup.

Yes... this was the needed required package.




But when I do the build locally on both f38 and rawhide (f39)
there is no problem and I do have a "BuildRequires: python3-devel"
in the spec file so I'm a bit lost as to what can be the
problem...


F38 is on Python 3.11, where distutils still exists.  Your mock cache
must be stale if local rawhide builds are still succeeding without
this.


Well the F38 scratch build still builds w/out add adding
new dependency... should I go ahead and add it or not worry
about it?

Thank you... very much!!!

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

python3 build failure

[Steve Dickson]

Hello,

This bz[1] was opened on one of my packages not building on f39.
I did a quick rawhide scratch build and sure enough
the build fails with [2]

Traceback (most recent call last):
  File 
"/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py", line 
93, in trace

result = func(*args, **kw)
 ^
  File "/usr/lib/python3.11/site-packages/mockbuild/util.py", line 597, 
in do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command, 
output), child.returncode)

mockbuild.exception.Error: Command failed:

But when I do the build locally on both f38 and rawhide (f39)
there is no problem and I do have a "BuildRequires: python3-devel"
in the spec file so I'm a bit lost as to what can be the
problem...

Any thoughts? tia!!

steved.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2219922
[2] https://kojipkgs.fedoraproject.org//work/tasks/2595/103632595/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

strange python3 mock error

[Steve Dickson]

Hello,

I'm getting a very strange mock error [1] on a package [2]
that was recently ported to python 3.

The package builds fine locally... only fails in a
scratch build... and that function that the error is c
complaining about does not exist in the package...

Not clear what to do... tia!

steved.

[1] https://kojipkgs.fedoraproject.org//work/tasks/4223/100064223/build.log
[2] https://src.fedoraproject.org/rpms/NFStest
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

What happen kup in Fedora 37

[Steve Dickson]

Hello,

I'm trying to access kernel.org with kup
script but it does not seem to be in Fedora 37.

The only rpm I can find is kup-0.3.6-11.fc36.rpm.

What am I missing??

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange RPM build warning

[Steve Dickson]

On 2/28/23 12:37 PM, Chuck Anderson wrote:

February is abbreviated as "Fed" in the first changelog entry:

* Tue Fed 28 2023 Steve Dickson  1.2.6-4.rc2
- Updated to latest upstream RC release: rpcbind-1_2_7-rc2

Yup! That was the problem... Thank you for your time!!!

steved.


On Tue, Feb 28, 2023 at 12:33:39PM -0500, Steve Dickson wrote:



On 2/28/23 12:12 PM, Miro Hrončok wrote:

On 28. 02. 23 17:43, Steve Dickson wrote:

Hello,

I'm getting this warning

RPM build warnings:
  source_date_epoch_from_changelog set but %changelog is missing

But the %changelog is not missing...

Any ideas?


Could you please share the spec file?

I've seen this when the %changelog was considered "invalid" by RPM. That
way, it is ignored. E.g. when it is not sorted by date or if the dates
are bogus.

Sure... see the attachment... I don't see any bogus dates... but
maybe I'm just not seeing something... Thanks!



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange RPM build warning

[Steve Dickson]

On 2/28/23 12:37 PM, Miro Hrončok wrote:

On 28. 02. 23 18:33, Steve Dickson wrote:



On 2/28/23 12:12 PM, Miro Hrončok wrote:

On 28. 02. 23 17:43, Steve Dickson wrote:

Hello,

I'm getting this warning

RPM build warnings:
 source_date_epoch_from_changelog set but %changelog is missing

But the %changelog is not missing...

Any ideas?


Could you please share the spec file?

I've seen this when the %changelog was considered "invalid" by RPM. 
That way, it is ignored. E.g. when it is not sorted by date or if the 
dates are bogus.

Sure... see the attachment... I don't see any bogus dates... but
maybe I'm just not seeing something... Thanks!


rpm will tell you:

==
RPM build warnings:
     source_date_epoch_from_changelog set but %changelog is missing

RPM build errors:
     bad date in %changelog: Tue Fed 28 2023 Steve Dickson 
 1.2.6-4.rc2

==

It should be Feb, not Fed.

Sometimes you just need a second pair of eyes! :-)
A strange way to say there is an invalid date...
But thank you... very much!!!




Tip: Always use rpmdev-bumpspec (or %autochangelog); never write the 
changelog %entry manually.

I will definitely look into this...

Thanks again!

steved.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange RPM build warning

[Steve Dickson]

On 2/28/23 12:12 PM, Miro Hrončok wrote:

On 28. 02. 23 17:43, Steve Dickson wrote:

Hello,

I'm getting this warning

RPM build warnings:
 source_date_epoch_from_changelog set but %changelog is missing

But the %changelog is not missing...

Any ideas?


Could you please share the spec file?

I've seen this when the %changelog was considered "invalid" by RPM. That 
way, it is ignored. E.g. when it is not sorted by date or if the dates 
are bogus.

Sure... see the attachment... I don't see any bogus dates... but
maybe I'm just not seeing something... Thanks!

steved.
# These are macros to be usable outside of the build section
%global rpcbind_user_group rpc
%global rpcbind_state_dir %{_rundir}/rpcbind

Name:   rpcbind
Version:1.2.6
Release:4.rc2%{?dist}
Summary:Universal Addresses to RPC Program Number Mapper
License:BSD
URL:http://nfsv4.bullopensource.org

Source0:http://downloads.sourceforge.net/rpcbind/%{name}-%{version}.tar.bz2
Source1: %{name}.sysconfig

Requires: glibc-common setup
Conflicts: man-pages < 2.43-12
BuildRequires: make
BuildRequires: automake, autoconf, libtool, systemd, systemd-devel
BuildRequires: libtirpc-devel, quota-devel
Requires(pre): coreutils shadow-utils
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd coreutils

Patch001: rpcbind-1.2.7-rc2.patch

Patch100: rpcbind-0.2.3-systemd-envfile.patch
Patch101: rpcbind-0.2.3-systemd-tmpfiles.patch
Patch102: rpcbind-0.2.4-runstatdir.patch
Patch103: rpcbind-0.2.4-systemd-service.patch
Patch104: rpcbind-0.2.4-systemd-rundir.patch

Provides: portmap = %{version}-%{release}
Obsoletes: portmap <= 4.0-65.3

%description
The rpcbind utility is a server that converts RPC program numbers into
universal addresses.  It must be running on the host to be able to make
RPC calls on a server on that machine.

%prep
%setup -q

%patch001 -p1

%patch100 -p1
%patch101 -p1
%patch102 -p1
%patch103 -p1
%patch104 -p1

%build
autoreconf -fisv
%configure \
--enable-warmstarts \
--with-statedir="%rpcbind_state_dir" \
--with-rpcuser="%rpcbind_user_group" \
--with-nss-modules="files altfiles" \
--sbindir=%{_bindir} \
--enable-rmtcalls \
--enable-debug

make all

%install
mkdir -p %{buildroot}{%{_sbindir},%{_bindir},/etc/sysconfig}
mkdir -p %{buildroot}%{_unitdir}
mkdir -p %{buildroot}%{_tmpfilesdir}
mkdir -p %{buildroot}%{_mandir}/man8
mkdir -p %{buildroot}%{rpcbind_state_dir}
make DESTDIR=$RPM_BUILD_ROOT install

install -m644 %{SOURCE1} %{buildroot}/etc/sysconfig/rpcbind

# The binaries now live in /usr/bin, moving from /usr/sbin
# For compatibility create a couple symlinks. 
cd ${RPM_BUILD_ROOT}%{_sbindir}
ln -sf ../bin/rpcbind
ln -sf ../bin/rpcinfo


%pre

# Softly static allocate the rpc uid and gid.
getent group rpc >/dev/null || groupadd -f -g 32 -r rpc
if ! getent passwd rpc >/dev/null ; then
	if ! getent passwd 32 >/dev/null ; then
	   useradd -l -c "Rpcbind Daemon" -d /var/lib/rpcbind  \
	  -g rpc -M -s /sbin/nologin -o -u 32 rpc > /dev/null 2>&1
	else
	   useradd -l -c "Rpcbind Daemon" -d /var/lib/rpcbind  \
	  -g rpc -M -s /sbin/nologin rpc > /dev/null 2>&1
	fi
fi

%post
%systemd_post rpcbind.service rpcbind.socket

%preun
%systemd_preun rpcbind.service rpcbind.socket

%postun
%systemd_postun_with_restart rpcbind.service rpcbind.socket

%triggerin -- rpcbind > 0.2.2-2.0
if systemctl -q is-enabled rpcbind.socket
then
	/bin/systemctl reenable rpcbind.socket  >/dev/null 2>&1 || :
	/bin/systemctl restart rpcbind.socket >/dev/null 2>&1 || :
fi

%files
%license COPYING
%config(noreplace) /etc/sysconfig/rpcbind
%doc AUTHORS ChangeLog README
%{_bindir}/rpcbind
%{_bindir}/rpcinfo
%{_sbindir}/rpcbind
%{_sbindir}/rpcinfo
%{_mandir}/man8/*
%{_unitdir}/%{name}.service
%{_unitdir}/%{name}.socket
%{_tmpfilesdir}/%{name}.conf
%attr(0700, %{rpcbind_user_group}, %{rpcbind_user_group}) %dir %{rpcbind_state_dir}

%changelog
* Tue Fed 28 2023 Steve Dickson  1.2.6-4.rc2
- Updated to latest upstream RC release: rpcbind-1_2_7-rc2

* Fri Jan 20 2023 Fedora Release Engineering  - 1.2.6-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

* Sat Jul 23 2022 Fedora Release Engineering  - 1.2.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

* Fri Jan 21 2022 Fedora Release Engineering  - 1.2.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

* Fri Jul 23 2021 Fedora Release Engineering  - 1.2.6-1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

* Mon May 17 2021 Steve Dickson  1.2.6-0
- Updated to latest upstream release: rpcbind-1_2_6 (bz 1959127)

* Tue Mar 02 2021 Zbigniew Jędrzejewski-Szmek  - 1.2.5-5.rc1.5
- Rebuilt for updated systemd-rpm-macros
  See https://pagure.io/fesco/issue/2583.

* Wed Jan 27 2021 Fedora Release Engineering  - 1.2.5-5.rc1.4
- Re

Strange RPM build warning

[Steve Dickson]

Hello,

I'm getting this warning

RPM build warnings:
source_date_epoch_from_changelog set but %changelog is missing

But the %changelog is not missing...

Any ideas?

tia,

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

gaps test failed

[Steve Dickson]

Hello,

My update [1] failed because the gaps test failed

sbin/mount.nfs: gap:  (0x5590..0x55a0 probable component: __printf_chk) 
in annobin notes.
/sbin/mount.nfs: gap:  (0x11760..0x11770 probable component: 
__printf_chk) in annobin notes.
/sbin/mount.nfs: FAIL: gaps test because gaps were detected in the 
annobin coverage


which means I can not move the update to stable.

What is a gap test and how do I fix it?

tia,

steved.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-e83239c44f
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PSA: koji armv7hl builders locking up

[Steve Dickson]

On 8/7/22 3:49 PM, Kevin Fenzi wrote:

Or just wait... I have been checking them a few times a day and
rebooting any that are locked up.

How long do we have to wait? [1] has been stuck since
Mon, 08 Aug 2022 14:17:44 UTC

steved.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90612742
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

nfs4-acl-tools

[Steve Dickson]

Hello,

I just took over the maintership of nfs4-acl-tools
and it appears the command has not been part
of Fedora since f32.

Granted there has not been any upstream activity
until now, but is there a way to get back into,
at least, rawhide?

tia,

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Maintainer Change

[Steve Dickson]

Hello,

I'm taking over the maintainership of a package.

In the past I would access the pkgdb via a link
similar to [1] to change ACLs that link
no longer exists How is this done these days?

tia,

steved.


[1] https://admin.fedoraproject.org/pkgdb/acls/name/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: sign_and_send_pubkey: signing failed for RSA

[Steve Dickson]

It turns out all that was needed was a reboot.

I did an update and since the kernel was not updated
I didn't do a reboot... that was the mistake...
I guess the flux capacitor got update and needed
a reboot!

Thanks for the help!!

steved.

On 10/27/21 8:16 AM, Chris Kelley wrote:

Hi Steve,

You don't specify which version of Fedora each box is using, but if you 
have one running F32 or earlier and one running F33+ then Petr is 
probably correct. This is likely a result of SHA-1 being disabled in the 
DEFAULT SWCP:


https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 
<https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2>
https://pagure.io/fedora-docs/release-notes/issue/470 
<https://pagure.io/fedora-docs/release-notes/issue/470>


You can use 'update-crypto-policies --show' to see what your active 
policy is, presumably it is DEFAULT on both machines.


Cheers,

Chris

On Wed, 27 Oct 2021 at 12:11, Petr Pisar <mailto:ppi...@redhat.com>> wrote:


V Tue, Oct 26, 2021 at 01:31:31PM -0400, Steve Dickson napsal(a):
 > A very strange problem... on one of my fedora
 > build machine I'm getting the following error
 > when I do a git pull
 >
 > $ git pull
 > sign_and_send_pubkey: signing failed for RSA
"/home/steved/.ssh/id_rsa" from
 > agent: agent refused operation

Disabled SHA-1 in system-wide cryptopolicy?

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
<https://pagure.io/fedora-infrastructure>


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

sign_and_send_pubkey: signing failed for RSA

[Steve Dickson]

Hello,

A very strange problem... on one of my fedora
build machine I'm getting the following error
when I do a git pull

$ git pull
sign_and_send_pubkey: signing failed for RSA "/home/steved/.ssh/id_rsa" 
from agent: agent refused operation

ste...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

On a different machine, using the same public and
private rsa keys... The pull works...

$ git pull
Already up to date.

Anybody have clue at as to what is going on??

tia,

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

1974358 – Review Request: fdr - Flight Data Recorder

[Steve Dickson]

Hello,

Anybody interested in doing a "review swap" or just a review??
Here is my review request [1]. I would like to get this into f35.

tia,

steved.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1974358
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git push on master branch rejected.

[Steve Dickson]

On 2/22/21 9:31 AM, Steve Dickson wrote:
> 
> 
> On 2/22/21 9:28 AM, Steve Dickson wrote:
>>
>>
>> On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
>>> On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
>>>>
>>>> Thanks you for your rapid reply! 
>>>>
>>>> On 2/21/21 4:57 PM, Michael Young wrote:
>>>>> On Sun, 21 Feb 2021, Steve Dickson wrote:
>>>>>
>>>>>> I apologies if I missed something... If there is a
>>>>>> thread that talks about this please point me at it
>>>>>> but...
>>>>>>
>>>>>> when I do a git push on the master branch I get:
>>>>> ...
>>>>>
>>>>> You missed the branch renaming - master has been replaced by rawhide with 
>>>>> alias main.
>>>> I figured it was something like that... but when I do a git branch -r I 
>>>> don't 
>>>> see the rawhide branch... So how do I move from master to rawhide?
>>>>
>>>> From your explanation I figured all I had to is a
>>>>  git checkout -b main origin/main
>>>>
>>>> which worked but when I do a git pull I get
>>>>
>>>> $ git pull
>>>> error: cannot lock ref 'refs/remotes/origin/rawhide': 
>>>> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot 
>>>> create 'refs/remotes/origin/rawhide'
>>>> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>>>>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
>>>> ref)
>>>>
>>>> It appears that a very old refs "origin/rawhide/user/steved/pnfs-rawhide" 
>>>> is messing things up... so how do I get ride of that old refs?
>>>
>>> I have renamed it on the server side, so if you try again this should work 
>>> now
>>> :)
>> Thank you... but I still unable to create the rawhide branch:
>>
>> git pull
>> error: cannot lock ref 'refs/remotes/origin/rawhide': 
>> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
>> 'refs/remotes/origin/rawhide'
>> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
>> ref)
>>  * [new branch]  rawhide_old/user/steved/pnfs-rawhide -> 
>> origin/rawhide_old/user/steved/pnfs-rawhide
>>
>> Doing the pull again I get:
>>
>> git pull
>> error: cannot lock ref 'refs/remotes/origin/rawhide': 
>> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
>> 'refs/remotes/origin/rawhide'
>> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
>> ref)
> 
> Well it appears this is still the problem
> 
> origin/rawhide/user/steved/pnfs-rawhide
> origin/rawhide_old/user/steved/pnfs-rawhide
Never mind... I just had to recreate the git tree... thanks again!

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git push on master branch rejected.

[Steve Dickson]

On 2/22/21 9:28 AM, Steve Dickson wrote:
> 
> 
> On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
>> On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
>>>
>>> Thanks you for your rapid reply! 
>>>
>>> On 2/21/21 4:57 PM, Michael Young wrote:
>>>> On Sun, 21 Feb 2021, Steve Dickson wrote:
>>>>
>>>>> I apologies if I missed something... If there is a
>>>>> thread that talks about this please point me at it
>>>>> but...
>>>>>
>>>>> when I do a git push on the master branch I get:
>>>> ...
>>>>
>>>> You missed the branch renaming - master has been replaced by rawhide with 
>>>> alias main.
>>> I figured it was something like that... but when I do a git branch -r I 
>>> don't 
>>> see the rawhide branch... So how do I move from master to rawhide?
>>>
>>> From your explanation I figured all I had to is a
>>>  git checkout -b main origin/main
>>>
>>> which worked but when I do a git pull I get
>>>
>>> $ git pull
>>> error: cannot lock ref 'refs/remotes/origin/rawhide': 
>>> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot 
>>> create 'refs/remotes/origin/rawhide'
>>> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>>>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
>>> ref)
>>>
>>> It appears that a very old refs "origin/rawhide/user/steved/pnfs-rawhide" 
>>> is messing things up... so how do I get ride of that old refs?
>>
>> I have renamed it on the server side, so if you try again this should work 
>> now
>> :)
> Thank you... but I still unable to create the rawhide branch:
> 
> git pull
> error: cannot lock ref 'refs/remotes/origin/rawhide': 
> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
> 'refs/remotes/origin/rawhide'
> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
> ref)
>  * [new branch]  rawhide_old/user/steved/pnfs-rawhide -> 
> origin/rawhide_old/user/steved/pnfs-rawhide
> 
> Doing the pull again I get:
> 
> git pull
> error: cannot lock ref 'refs/remotes/origin/rawhide': 
> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
> 'refs/remotes/origin/rawhide'
> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
> ref)

Well it appears this is still the problem

origin/rawhide/user/steved/pnfs-rawhide
origin/rawhide_old/user/steved/pnfs-rawhide

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git push on master branch rejected.

[Steve Dickson]

On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
> On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
>>
>> Thanks you for your rapid reply! 
>>
>> On 2/21/21 4:57 PM, Michael Young wrote:
>>> On Sun, 21 Feb 2021, Steve Dickson wrote:
>>>
>>>> I apologies if I missed something... If there is a
>>>> thread that talks about this please point me at it
>>>> but...
>>>>
>>>> when I do a git push on the master branch I get:
>>> ...
>>>
>>> You missed the branch renaming - master has been replaced by rawhide with 
>>> alias main.
>> I figured it was something like that... but when I do a git branch -r I 
>> don't 
>> see the rawhide branch... So how do I move from master to rawhide?
>>
>> From your explanation I figured all I had to is a
>>  git checkout -b main origin/main
>>
>> which worked but when I do a git pull I get
>>
>> $ git pull
>> error: cannot lock ref 'refs/remotes/origin/rawhide': 
>> 'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
>> 'refs/remotes/origin/rawhide'
>> From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
>>  ! [new branch]  rawhide-> origin/rawhide  (unable to update local 
>> ref)
>>
>> It appears that a very old refs "origin/rawhide/user/steved/pnfs-rawhide" 
>> is messing things up... so how do I get ride of that old refs?
> 
> I have renamed it on the server side, so if you try again this should work now
> :)
Thank you... but I still unable to create the rawhide branch:

git pull
error: cannot lock ref 'refs/remotes/origin/rawhide': 
'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
'refs/remotes/origin/rawhide'
From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
 ! [new branch]  rawhide-> origin/rawhide  (unable to update local ref)
 * [new branch]  rawhide_old/user/steved/pnfs-rawhide -> 
origin/rawhide_old/user/steved/pnfs-rawhide

Doing the pull again I get:

git pull
error: cannot lock ref 'refs/remotes/origin/rawhide': 
'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
'refs/remotes/origin/rawhide'
From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
 ! [new branch]  rawhide-> origin/rawhide  (unable to update local ref)


steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git push on master branch rejected.

[Steve Dickson]

Thanks you for your rapid reply! 

On 2/21/21 4:57 PM, Michael Young wrote:
> On Sun, 21 Feb 2021, Steve Dickson wrote:
> 
>> I apologies if I missed something... If there is a
>> thread that talks about this please point me at it
>> but...
>>
>> when I do a git push on the master branch I get:
> ...
> 
> You missed the branch renaming - master has been replaced by rawhide with 
> alias main.
I figured it was something like that... but when I do a git branch -r I don't 
see the rawhide branch... So how do I move from master to rawhide?

From your explanation I figured all I had to is a
 git checkout -b main origin/main

which worked but when I do a git pull I get

$ git pull
error: cannot lock ref 'refs/remotes/origin/rawhide': 
'refs/remotes/origin/rawhide/user/steved/pnfs-rawhide' exists; cannot create 
'refs/remotes/origin/rawhide'
From ssh://pkgs.fedoraproject.org/rpms/nfs-utils
 ! [new branch]  rawhide-> origin/rawhide  (unable to update local ref)

It appears that a very old refs "origin/rawhide/user/steved/pnfs-rawhide" 
is messing things up... so how do I get ride of that old refs?


tia,

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

git push on master branch rejected.

[Steve Dickson]

Hello,

I apologies if I missed something... If there is a
thread that talks about this please point me at it
but... 

when I do a git push on the master branch I get:

$ git push
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 12 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 684 bytes | 684.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Ref refs/heads/master is blocked
remote: Denied push for ref 'refs/heads/master' for user 'steved'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/nfs-utils
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/nfs-utils'

I was able to do the push on the other branches (f34,f33,f32)
so it appears something has changed on the master branch.

Any ideas?

tia!

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/17/21 6:55 PM, Ed Greshko wrote:
> On 18/02/2021 05:11, Steve Dickson wrote:
>> I agree... ignoring syntax error or parsing error just does not seem
>> like the appropriate thing to do... Error out! Tell me what is broken
>> so I can fix it!!
> 
> Replace the "," with a " " in the DNS= entry of /etc/systemd/resolved.conf 
> file.
> 
> And if you didn't format it that way, find out who did.
That is the question!!! I upgraded and DNS broke!

I didn't even know there was a /etc/systemd/resolved.conf
file until this unfortunate experience... 

> 
> And, if you've never made an incorrect format in a configuration file in your 
> life, consider yourself
> lucky.  The worst ones are formatting failures which occur silently yet 
> things don't work.
> 
Of course I have... when I change things and break things I see the 
error... but in this case I upgraded (aka I changed nothing) and the
error was ignored... Killing my DNS... That is a bug.. IMHO.. 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/16/21 9:03 AM, Ed Greshko wrote:
> On 16/02/2021 21:37, Steve Dickson wrote:
>>
>> On 2/15/21 9:16 PM, Dominique Martinet wrote:
>>> Steve Dickson wrote on Mon, Feb 15, 2021 at 09:04:52PM -0500:
>>>>> I think if no IP was successfully parsed the fallback ought to kick in,
>>>>> so it's a systemd-resolved bug -- do you want to report this upstream or
>>>>> shall I now I've had a look?
>>>> Fedora bz or an upstream bz? If is the latter where do I report it?
>>> We have systemd devs in fedora so I think either would work out.
>>>
>>> upstream is on github: https://github.com/systemd/systemd/issues
>>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1929212
>>
>> Thanks for the help!
> 
> FWIW, I suppose I don't know why a BZ is needed since the 
> /etc/systemd/resolved.conf has a sample
> for the DNS= parameter showing:
> 
> # Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
> # Cloudflare: 1.1.1.1 1.0.0.1 2606:4700:4700:: 2606:4700:4700::1001
> # Google: 8.8.8.8 8.8.4.4 2001:4860:4860:: 2001:4860:4860::884
> 
> And the man page for resolved.conf explicitly states:
> 
>     DNS=
>    A space-separated list of IPv4 and IPv6 addresses to use as system
>    DNS servers.
> 
> Is the expectation that any character which may be considered a delimiter 
> should be acceptable?Who/what was setting DNS=?? It was not me... and 
> obviously it didn't read the man page! :-) 
> Wouldn't the more appropriate course of action be to correct format?
Fail!!! If something is wrong which will cause DNS not to work... Fail!!
Give the Admin a changed to fix the problem... IMHO... 

steved.

> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/16/21 9:02 AM, Troy Curtis Jr wrote:
> 
> 
> On Mon, Feb 15, 2021 at 10:02 PM Dominique Martinet  > wrote:
> 
> Michael Catanzaro wrote on Mon, Feb 15, 2021 at 08:46:57PM -0600:
> > We removed the fallbacks due to complaints from users who didn't want 
> DNS
> > ever going to Cloudflare or Google. So the lack of fallback is expected 
> and
> > should not be reported as a bug.
> 
> setting DNS= (or DNS="") explicitely should not fallback, I agree with
> that. There are people who want no DNS whatsoever and that should be
> configurable.
> 
> But if extract_first_word() returned a non-empty string and
> manager_add_dns_server_by_string fails (for all iterations of the loop),
> it should definitely kick some fallback in -- the user obviously wanted
> *something*, it just doesn't work.
> 
> 
> Steve's situation provides the perfect example for why a fallback is likely 
> undesirable. It sounds like his
> configuration never worked. There were explicit DNS values configured that 
> weren't being used, yet
> he never noticed because it fell back to something that seemed to work. It 
> would take a deeper and
> deliberate look before the user realized the desired configuration wasn't 
> applied. It is better to error
> than guess in many cases.
I agree... ignoring syntax error or parsing error just does not seem
like the appropriate thing to do... Error out! Tell me what is broken
so I can fix it!!

steved.  
>  
> 
> 
> > I think we have larger issues with DNS server assignment on cloud 
> servers,
> > which I've reported as https://pagure.io/fedora-server/issue/10 
> . But I also
> > notice Steve's case is different, since he really does have some static 
> DNS
> > configuration, just using commas where spaces are required. So seems 
> like a
> > misconfiguration by the cloud provider?
> 
> Not sure where the configuration snippet with comma comes from but yes
> ultimately it's "just" a configuration error.
> Nevertheless, a config that somehow worked until a recent update through
> fallback, I don't think we want more unhappy users :)
> 
> -- 
> Dominique
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
> 
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines 
> 
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> 
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/16/21 6:05 AM, David Both wrote:
> This situation is due to the change from the old resolver to the new 
> systemd-resolved.
> 
> I have a page on my technical web site that describes the problem and the 
> circumvention.
> 
> http://www.linux-databook.info/?page_id=5951
> 
> This does not, erm, resolve the problem but it does get you back to a working 
> resover.
Right stopping/disabling the systemd-resolved then creating your own 
/etc/resovled.conf
is the work around... 

systemd is in the booting business... However did it get in DNS business... 
And that was a good idea??? ;-)

> 
> I hope this helps.
It did... Thanks you!

steved
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 9:16 PM, Dominique Martinet wrote:
> Steve Dickson wrote on Mon, Feb 15, 2021 at 09:04:52PM -0500:
>>> I think if no IP was successfully parsed the fallback ought to kick in,
>>> so it's a systemd-resolved bug -- do you want to report this upstream or
>>> shall I now I've had a look?
>>
>> Fedora bz or an upstream bz? If is the latter where do I report it?
> 
> We have systemd devs in fedora so I think either would work out.
> 
> upstream is on github: https://github.com/systemd/systemd/issues
> 
https://bugzilla.redhat.com/show_bug.cgi?id=1929212

Thanks for the help!

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 8:53 PM, Dominique Martinet wrote:
> Hi Steve,
> 
> Steve Dickson wrote on Mon, Feb 15, 2021 at 08:40:17PM -0500:
>> When I have DNS=67.207.67.3,67.207.67.2 I get
> 
> FWIW the man page states it is a space-separated list of IPs, you might
> want to try DNS="67.207.67.3 67.207.67.2"
> 
> I quickly had a look at the code and I don't think anything changed
> recently with how the parsing works, but dd2e9e1d0e82 ("resolve: ignore
> invalid service template name") (18 Nov 2020) changed the error bubbling
> up (it's now ignored when it was an error), so the fallback no longer
> kicks in for you.
> 
> 
> I think if no IP was successfully parsed the fallback ought to kick in,
> so it's a systemd-resolved bug -- do you want to report this upstream or
> shall I now I've had a look?
> 
Fedora bz or an upstream bz? If is the latter where do I report it?

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 8:16 PM, Ed Greshko wrote:
> On 16/02/2021 09:10, Steve Dickson wrote:
>> On 2/15/21 7:55 PM, Ed Greshko wrote:
>>> On 16/02/2021 08:50, Steve Dickson wrote:
>>>> But I think this is the problem... 
>>>>
>>>> systemctl start systemd-resolved
>>>> systemctl -o cat status systemd-resolved
>>>> Starting Network Name Resolution...
>>>> Positive Trust Anchors:
>>>> . IN DS 20326 8 2 
>>>> e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
>>>> Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 
>>>> 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.i>
>>>> Failed to add DNS server address '67.207.67.2,67.207.67.3', ignoring: 
>>>> Invalid argument
>>>> Using system hostname 'steved-v4dev-f33.nfsv4.dev'.
>>>> Started Network Name Resolution.
>>>>
>>>> What has changed in the parsing of DNS server addresses???
>>> I get...
>>>
>>> Positive Trust Anchors:
>>> . IN DS 20326 8 2 
>>> e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
>>> Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 
>>> 17.172.in-addr.arpa 1>
>>> Using system hostname 'meimei.greshko.com'.
>>>
>>> I don't see where your DNS servers are defined from the previous post you 
>>> showed.
>>>
>>> My primary interface is enp2s0 and I get...
>>>
>>> [egreshko@meimei ~]$ nmcli device show enp2s0 | grep -i dns
>>> IP4.DNS[1]: 192.168.1.142
>>> IP6.DNS[1]: 2001:b030:112f::19
>>>
>>> Does something get returned for your eth0 device?
>> No...
>>
>> nmcli device show eth0 | grep -i dns
>> nmcli device show eth1 | grep -i dns
>>
>> but... after changing /etc/systemd/resolved.conf to DNS=8.8.8.8
>> Then doing a systemctl restart systemd-resolved
>> The dns started to work... There is an issue
>> with the latest systemd-resolved
> 
> I don't think so
> 
> In my /etc/systemd/resolved.conf I have
> 
> #DNS=
When I have DNS=67.207.67.3,67.207.67.2 I get
# systemctl -o cat status systemd-resolved
Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 
18.172.in-addr.arpa 19.172.i>
Failed to add DNS server address '67.207.67.2,67.207.67.3', ignoring: Invalid 
argument

When I change DNS=67.207.67.2 and restart systemd-resolved
my dns comes back... w/out the error.

> 
> So, you're just manually adding a DNS server.  
No... the DNS=67.207.67.2,67.207.67.3 is coming from
the cloud provider.

> You're interface still doesn't have a DNS server defined.
> As Far As I can Tell.
Right! Because whatever changed in systemd-resolved can longer
parse DNS=,. Which it could before...

> 
> Why don't you try adding servers to your network configuration instead?
I'm a VM in a cloud... I have no control over the network servers. 

> 
> I have systemd-246.10-1.fc33.x86_64 installed on all systems with no problems.
I do to... 
# rpm -q systemd
systemd-246.10-1.fc33.x86_64

But you don't have in ',' in your DNS statments.

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 7:55 PM, Ed Greshko wrote:
> On 16/02/2021 08:50, Steve Dickson wrote:
>> But I think this is the problem... 
>>
>> systemctl start systemd-resolved
>> systemctl -o cat status systemd-resolved
>> Starting Network Name Resolution...
>> Positive Trust Anchors:
>> . IN DS 20326 8 2 
>> e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
>> Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 
>> 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.i>
>> Failed to add DNS server address '67.207.67.2,67.207.67.3', ignoring: 
>> Invalid argument
>> Using system hostname 'steved-v4dev-f33.nfsv4.dev'.
>> Started Network Name Resolution.
>>
>> What has changed in the parsing of DNS server addresses???
> 
> I get...
> 
> Positive Trust Anchors:
> . IN DS 20326 8 2 
> e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
> Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 
> 17.172.in-addr.arpa 1>
> Using system hostname 'meimei.greshko.com'.
> 
> I don't see where your DNS servers are defined from the previous post you 
> showed.
> 
> My primary interface is enp2s0 and I get...
> 
> [egreshko@meimei ~]$ nmcli device show enp2s0 | grep -i dns
> IP4.DNS[1]: 192.168.1.142
> IP6.DNS[1]: 2001:b030:112f::19
> 
> Does something get returned for your eth0 device?
No...

nmcli device show eth0 | grep -i dns
nmcli device show eth1 | grep -i dns

but... after changing /etc/systemd/resolved.conf to DNS=8.8.8.8
Then doing a systemctl restart systemd-resolved
The dns started to work... There is an issue
with the latest systemd-resolved

steved.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 7:31 PM, Ed Greshko wrote:
> I think I may have sent this off-list
> 
> On 16/02/2021 08:17, Steve Dickson wrote:
>> On 2/15/21 7:12 PM, Ed Greshko wrote:
>>> On 16/02/2021 06:40, Steve Dickson wrote:
>>>> I just updated to latest Fedora 33 and
>>>> I no longer have any DNS name solution.
>>>> The network is up... but...
>>>>
>>>> $ pingwww.yahoo.com
>>>> ping:www.yahoo.com: Name or service not known
>>>>
>>>> I changed nothing!
>>>>
>>>> How would be the bet way to debug this???
>>> What is the output of
>>>
>>> resolvectl status
>>>
>>>
>> # resolvectl status
>> Global
>>     Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
>> resolv.conf mode: missing
>>
>> Link 2 (eth0)
>> Current Scopes: LLMNR/IPv4 LLMNR/IPv6
>>   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 3 (eth1)
>> Current Scopes: LLMNR/IPv4 LLMNR/IPv6
>>   Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
> 
> Well, that is an indication of a problem as it should return something 
> like
> 
> Link 2 (enp2s0)
>     Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
>  Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
> DNSSEC=no/unsupported
> Current DNS Server: 192.168.1.142
>    DNS Servers: 192.168.1.142 2001:b030:112f::19
>     DNS Domain: greshko.com
> 
> The question then is how your eth0 and/or eth1 obtain their IP addresses.  
> Are they configured
> statically or via DHCP?
> 
> 
statically...

But I think this is the problem... 

systemctl start systemd-resolved
systemctl -o cat status systemd-resolved
Starting Network Name Resolution...
Positive Trust Anchors:
. IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 
18.172.in-addr.arpa 19.172.i>
Failed to add DNS server address '67.207.67.2,67.207.67.3', ignoring: Invalid 
argument
Using system hostname 'steved-v4dev-f33.nfsv4.dev'.
Started Network Name Resolution.

What has changed in the parsing of DNS server addresses???

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 7:25 PM, Sam Varshavchik wrote:
>> # cat /run/NetworkManager/no-stub-resolv.conf
>> cat: /run/NetworkManager/no-stub-resolv.conf: No such file or directory
>>
>> Who is suppose to create that? It is on /run so it be created on every 
>> reboot...
> 
> NetworkManager. Maybe you have /run/NetworkManager/resolv.conf, I have both 
> of them. I'm too lazy to look up what's the difference.
Nope... 

# ls /run/NetworkManager/resolv.conf
/bin/ls: cannot access '/run/NetworkManager/resolv.conf': No such file or 
directory

> 
>> > Now, perform a test lookup using the dig command, directly, to your real 
>> > DNS server.
>> >
>> > dig @8.8.8.8 www.yahoo.com
>> I can't do this because bind-utils was not install and I can not install it
>> because DNS is broken..
> 
> "host" has an optional second parameter, the DNS server's IP address.
> 
Unfortunately..  # host
bash: host: command not found
:-)

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 7:24 PM, Ed Greshko wrote:
> On 16/02/2021 08:17, Steve Dickson wrote:
>> On 2/15/21 7:12 PM, Ed Greshko wrote:
>>> On 16/02/2021 06:40, Steve Dickson wrote:
>>>> I just updated to latest Fedora 33 and
>>>> I no longer have any DNS name solution.
>>>> The network is up... but...
>>>>
>>>> $ pingwww.yahoo.com
>>>> ping:www.yahoo.com: Name or service not known
>>>>
>>>> I changed nothing!
>>>>
>>>> How would be the bet way to debug this???
>>> What is the output of
>>>
>>> resolvectl status
>>>
>>>
>> # resolvectl status
>> Global
>>Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
>> resolv.conf mode: missing  
>>
>> Link 2 (eth0)
>> Current Scopes: LLMNR/IPv4 LLMNR/IPv6   
>>  Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 3 (eth1)
>> Current Scopes: LLMNR/IPv4 LLMNR/IPv6   
>>  Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
> 
> Well, that is an indication of a problem as it should return something 
> like
> 
> Link 2 (enp2s0)
>     Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 
>  
>  Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
> DNSSEC=no/unsupported
> Current DNS Server: 192.168.1.142 
>  
>    DNS Servers: 192.168.1.142 2001:b030:112f::19  
>  
>     DNS Domain: greshko.com
> 
> The question then is how your eth0 and/or eth1 obtain their IP addresses.  
> Are they configured
> statically or via DHCP?
Both Statically:

BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth0
GATEWAY=164.90.128.1
HWADDR=22:df:7b:34:93:fe
IPADDR=164.90.129.207
IPADDR6=2604:a880:800:c1::470:e001/64
IPV6ADDR=2604:a880:800:c1::470:e001/64
IPV6INIT=yes
IPV6_DEFAULTGW=2604:A880:0800:00C1::::0001
NETMASK=255.255.240.0
NETMASK1=255.255.0.0
ONBOOT=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=yes

BOOTPROTO=none
DEVICE=eth1
HWADDR=a6:91:39:b6:3c:7e
IPADDR=10.108.0.2
NETMASK=255.255.240.0
ONBOOT=yes
STARTMODE=auto
TYPE=Ethernet
USERCTL=no

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 7:12 PM, Ed Greshko wrote:
> On 16/02/2021 06:40, Steve Dickson wrote:
>> I just updated to latest Fedora 33 and
>> I no longer have any DNS name solution.
>> The network is up... but...
>>
>> $ pingwww.yahoo.com
>> ping:www.yahoo.com: Name or service not known
>>
>> I changed nothing!
>>
>> How would be the bet way to debug this???
> 
> What is the output of
> 
> resolvectl status
> 
> 
# resolvectl status
Global
   Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: missing  

Link 2 (eth0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6   
 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (eth1)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6   
 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 6:19 PM, Sam Varshavchik wrote:
> Steve Dickson writes:
> 
>> Hello,
>>
>> I just updated to latest Fedora 33 and
>> I no longer have any DNS name solution.
>> The network is up... but...
>>
>> $ ping www.yahoo.com
>> ping: www.yahoo.com: Name or service not known
>>
>> I changed nothing!
>>
>> How would be the bet way to debug this???
> 
> Inspect what it's your /etc/resolv.conf, confirm that your name server is 
> 127.0.0.10, or something this bizarre.
I guess it is bizarre... 
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

> 
> Now look in /run/NetworkManager/no-stub-resolv.conf to see what your real DNS 
> server is. Let's assume that you see it's 8.8.8.8, but you should be able to 
> recognize your usual DNS server in there.
# cat /run/NetworkManager/no-stub-resolv.conf 
cat: /run/NetworkManager/no-stub-resolv.conf: No such file or directory

Who is suppose to create that? It is on /run so it be created on every 
reboot... 
> 
> Now, perform a test lookup using the dig command, directly, to your real DNS 
> server.
> 
> dig @8.8.8.8 www.yahoo.com
I can't do this because bind-utils was not install and I can not install it
because DNS is broken..

> 
> Make sure you use the IP address you got from no-stub-resolv.conf
> 
> Assuming that this lookup succeeds, proceed as follows:
> 
> systemctl stop systemd-resolved
> systemctl disable systemd-resolved
> rm -f /etc/resolv.conf
> ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf
since there is no no-stub-resolv.conf... 
ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf
# cat /etc/resolv.conf 
cat: /etc/resolv.conf: No such file or directory

> 
> Verify that your DNS service is now working, then announce that you joined 
> the systemd fan club, and ask for your membership information.
I wish I could! :-) 

I think the bottom line is /run/NetworkManager/no-stub-resolv.conf is
is no longer being created... 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Don't update to the latest f33!

[Steve Dickson]

On 2/15/21 6:00 PM, Stephen John Smoogen wrote:
> 
> 
> On Mon, 15 Feb 2021 at 17:39, Steve Dickson  <mailto:ste...@redhat.com>> wrote:
> 
> Hello,
> 
> I just updated to latest Fedora 33 and
> I no longer have any DNS name solution.
> The network is up... but...
> 
> $ ping www.yahoo.com <http://www.yahoo.com>
> ping: www.yahoo.com <http://www.yahoo.com>: Name or service not known
> 
> I changed nothing!
> 
> How would be the bet way to debug this???
> 
> 
> It could be all kinds of things.. I updated this morning and still have DNS 
> so not sure which.
> 
> 1. what does /etc/resolv.conf say? Mine is pretty default but there are 
> different ways this could be happening:
> # See man:systemd-resolved.service(8) for details about the supported modes of
> # operation for /etc/resolv.conf.
> 
> nameserver 127.0.0.53
> options edns0 trust-ad
> search redhat.com <http://redhat.com> southeast.rr.com 
> <http://southeast.rr.com>
This is on a server in the cloud.. which might the problem but it
was not before the update. Here is what the /etc/resolv.conf

# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

> 
>  2. what does systemd-resolv say
> [ssmoogen@localhost freenode-znc]$ systemd-resolve www.yahoo.com 
> <http://www.yahoo.com>
systemd-resolve www.yahoo.com
www.yahoo.com: resolve call failed: No appropriate name servers or networks for 
name found

I do find this odd... a second network interface. Not sure
where that came from... 

eth1: flags=4163  mtu 1500
inet 10.108.0.2  netmask 255.255.240.0  broadcast 10.108.15.255
inet6 fe80::a491:39ff:feb6:3c7e  prefixlen 64  scopeid 0x20
ether a6:91:39:b6:3c:7e  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 19  bytes 1370 (1.3 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Obviously that is a non route-able address... I did turn i off but
it did not help with the DNS.. 

> 3. again if you are set up with systemd-resolv does it show up as broken in 
> systemctl or
> [root@localhost ~]# ss -npl| grep systemd-resolv
It seems to be live... https://paste.centos.org/view/52f7ce26

Thanks!

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Don't update to the latest f33!

[Steve Dickson]

Hello,

I just updated to latest Fedora 33 and 
I no longer have any DNS name solution. 
The network is up... but... 

$ ping www.yahoo.com
ping: www.yahoo.com: Name or service not known

I changed nothing! 

How would be the bet way to debug this???

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Serial Console with Fedora 33

[Steve Dickson]

Hello

On 12/13/20 7:35 PM, Sérgio Basto wrote:
> ~]# grubby --remove-args="rhgb quiet" --args=console=ttyS0,115200 --
> update-kernel /boot/vmlinuz-4.2.0-1.fc23.x86_64
This worked... thanks! 
> 
> 
> This command removes the Red Hat graphical boot argument, enables 
> boot message to be seen, and adds a serial console. As the console 
> arguments will be added at the end of the line, the new console will 
> take precedence over any other consoles configured.
Good to know! Thanks again!

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

Serial Console with Fedora 33

[Steve Dickson]

Hello,

How does one set up a serial console with F33?

In the past I would edit kernelopts with grub2-editenv
and set "console=tty0 console=ttyS0,115200n8".

As well as set the following in /etc/grub2.conf
terminal_output console
#set timeout=5
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

But in Fedora 33 there is no kernelopts in the grub2 env,
so does one create a serial console in f33?

tia,

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

Re: Failed to pair: org.bluez.Error.AuthenticationFailed

[Steve Dickson]

On 12/8/20 2:39 PM, Steve Dickson wrote:
> 
> 
> On 12/8/20 8:11 AM, Steve Dickson wrote:
>> Hello,
>>
>> I realize this is probably not the most appropriate list
>> to ask this question... but
>>
>> I have a pair of Jabra Elite 45h headphones that 
>> was working just fine until I updated to Fedora 33.
>>
>> When I try to pair via bluetoothctl I get the following error
>>
>> [bluetooth]# pair 70:BF:92:D6:51:CB
>> Attempting to pair with 70:BF:92:D6:51:CB
>> [CHG] Device 70:BF:92:D6:51:CB Connected: yes
>> Failed to pair: org.bluez.Error.AuthenticationFailed
>> [CHG] Device 70:BF:92:D6:51:CB Connected: no
>>
>> when I try to pair via the GUI I get
>> bluetoothd[8275]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 
>> 70:BF:92:D6:51:CB: Connection refused (111)
>>
>> It probably does not matter but I do have selinux set to permissive
>>
>> Anybody have clue as to what is going on?
> FYI... I just opened up this bz 
> https://bugzilla.redhat.com/show_bug.cgi?id=1905671

Its a kernel problem... On the 5-9 kernel I tried 
bluez-5.53, bluez-5.54, bluez-5.5 all failed
with  Connection refused (111)

Then I tried bluez-5.5 on the last 5.8 kernel
(5.8.18-300.fc33)... everything worked again

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

Re: Failed to pair: org.bluez.Error.AuthenticationFailed

[Steve Dickson]

On 12/8/20 10:28 AM, José Abílio Matos wrote:
> But is it a problem of the kernel or the daemon?
> 
Its a kernel problem... On the 5-9 kernel I tried 
bluez-5.53, bluez-5.54, bluez-5.5 all failed
with  Connection refused (111)

Then I tried bluez-5.5 on the last 5.8 kernel
(5.8.18-300.fc33)... everything worked again!

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

Re: Failed to pair: org.bluez.Error.AuthenticationFailed

[Steve Dickson]

On 12/8/20 8:11 AM, Steve Dickson wrote:
> Hello,
> 
> I realize this is probably not the most appropriate list
> to ask this question... but
> 
> I have a pair of Jabra Elite 45h headphones that 
> was working just fine until I updated to Fedora 33.
> 
> When I try to pair via bluetoothctl I get the following error
> 
> [bluetooth]# pair 70:BF:92:D6:51:CB
> Attempting to pair with 70:BF:92:D6:51:CB
> [CHG] Device 70:BF:92:D6:51:CB Connected: yes
> Failed to pair: org.bluez.Error.AuthenticationFailed
> [CHG] Device 70:BF:92:D6:51:CB Connected: no
> 
> when I try to pair via the GUI I get
> bluetoothd[8275]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 
> 70:BF:92:D6:51:CB: Connection refused (111)
> 
> It probably does not matter but I do have selinux set to permissive
> 
> Anybody have clue as to what is going on?
FYI... I just opened up this bz 
https://bugzilla.redhat.com/show_bug.cgi?id=1905671

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

Re: Failed to pair: org.bluez.Error.AuthenticationFailed

[Steve Dickson]

On 12/8/20 10:28 AM, José Abílio Matos wrote:
> Clearly I am stealing the thread but I also have a problem with bluetooth in 
> Fedora 33 and I unable to point what is the problem.
> 
> 
> I have followed the instruction at
> 
> https://fedoraproject.org/wiki/How_to_debug_Bluetooth_problems
Using this as a guideline I see the following errors
lsusb -v | grep Bluetooth | grep DeviceProtocol
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
  bDeviceProtocol 1 Bluetooth

and in the systemtab statuss
Endpoint registered: sender=:1.52 path=/MediaEndpoint/A2DPSource/sbc
Endpoint registered: sender=:1.70 path=/MediaEndpoint/A2DPSink/sbc
Endpoint registered: sender=:1.70 path=/MediaEndpoint/A2DPSource/sbc
src/profile.c:ext_start_servers() RFCOMM server failed for Headset Voice 
gateway: rfcomm_bind: Address already in use (98)
src/profile.c:ext_start_servers() RFCOMM server failed for Headset unit: 
rfcomm_bind: Address already in use (98)
Endpoint unregistered: sender=:1.70 path=/MediaEndpoint/A2DPSink/sbc
Endpoint unregistered: sender=:1.70 path=/MediaEndpoint/A2DPSource/sbc
src/profile.c:ext_connect() Headset Voice gateway failed connect to 
70:BF:92:D6:51:CB: Connection refused (111)
profiles/audio/avdtp.c:avdtp_connect_cb() connect to 70:BF:92:D6:51:CB: 
Connection refused (111)
profiles/audio/avdtp.c:avdtp_connect_cb() connect to 70:BF:92:D6:51:CB: 
Connection refused (111)

avdtp_connect_cb() is part of the bluetoothd daemon but that
but that does mean it is not a kernel issue. Trying to figure out
how to turn on more debug.

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

Re: Failed to pair: org.bluez.Error.AuthenticationFailed

[Steve Dickson]

On 12/8/20 8:31 AM, Peter Robinson wrote:
> On Tue, Dec 8, 2020 at 1:10 PM Steve Dickson  wrote:
>>
>> Hello,
>>
>> I realize this is probably not the most appropriate list
>> to ask this question... but
>>
>> I have a pair of Jabra Elite 45h headphones that
>> was working just fine until I updated to Fedora 33.
>>
>> When I try to pair via bluetoothctl I get the following error
>>
>> [bluetooth]# pair 70:BF:92:D6:51:CB
>> Attempting to pair with 70:BF:92:D6:51:CB
>> [CHG] Device 70:BF:92:D6:51:CB Connected: yes
>> Failed to pair: org.bluez.Error.AuthenticationFailed
>> [CHG] Device 70:BF:92:D6:51:CB Connected: no
>>
>> when I try to pair via the GUI I get
>> bluetoothd[8275]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 
>> 70:BF:92:D6:51:CB: Connection refused (111)
>>
>> It probably does not matter but I do have selinux set to permissive
>>
>> Anybody have clue as to what is going on?
> 
> Do you have a relatively new laptop with a Intel bluetooth adapter,
> something like AX2xx series? If so it might be this issue [1] in
> conjunction with the 5.9 kernel, I can't tell if the problem was
> resolved but there seems to be a workaround [2] search for
> IdentityResolvingKey for the relevant bit.
I don't have that driver 

lsusb | grep Blue
Bus 001 Device 004: ID 8087:0a2b Intel Corp. Bluetooth wireless interface

But thanks for the info!

steved.
> 
> 
> [1] https://www.spinics.net/lists/linux-bluetooth/msg88074.html
> [2] https://www.spinics.net/lists/linux-bluetooth/msg88147.html
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Failed to pair: org.bluez.Error.AuthenticationFailed

[Steve Dickson]

Hello,

I realize this is probably not the most appropriate list
to ask this question... but

I have a pair of Jabra Elite 45h headphones that 
was working just fine until I updated to Fedora 33.

When I try to pair via bluetoothctl I get the following error

[bluetooth]# pair 70:BF:92:D6:51:CB
Attempting to pair with 70:BF:92:D6:51:CB
[CHG] Device 70:BF:92:D6:51:CB Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device 70:BF:92:D6:51:CB Connected: no

when I try to pair via the GUI I get
bluetoothd[8275]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 
70:BF:92:D6:51:CB: Connection refused (111)

It probably does not matter but I do have selinux set to permissive

Anybody have clue as to what is going on?

tia,

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

Re: nfs-utils: compiler error tracking strlen on Rawhide armv7hl and i686

[Steve Dickson]

On 11/8/20 11:21 PM, John Reiser wrote:
> Let's handle some preliminary errors in this thread on building nfs-utils, 
> before they spread even more.
> 
> 1. Be specific.  State the package name in both the Subject and the first 
> line of the body.
> This provides context which aids the scanning of Subjects and enables 
> detection and correction
> of copy+paste errors.
> 
> 2. The return value from both printf() and snprintf() with a format of 
> "%s/%s" is
>    s(trlen(str1) + 1 + strlen(str2))   /* +1: the '/' separator */
> [note that this is strlen() of the unconstrained destination array],
> and the number of bytes written (if not limited by the size parameter to 
> snprintf())
> is 1 more because of the terminating NUL byte '\0'.
> Thus the minimum size of the unconstrained destination is (2 + strlen(str1) + 
> strlen(str2)).
> 
> 3. Do not use "PATH_MAX + 1".  Almost always it indicates a programmer error.
> From /usr/include/linux/limits.h we see that
>    #define PATH_MAX    4096    /* # chars in a path name including nul */
> Increasing the size does not work: if (4096 <= strlen(path))  /* Yes, '<=' */
> then the Linux kernel will do something other than what you naively expect.
> The "destination too small" error condition for (rv = snprintf(array, size, 
> format, ...))
> is (size <= rv); using anything else is a bug.
By using PATH_MAX instead of PATH_MAX +1 and 
by using snprintf() instead of sprintf() and 
finally checking the return value of snprintf()
the error no longer exists.

> 
> 
> After taking care of those bugs above, and looking at the constants such as 
> '2147483645'
> and '2147483648' in the compiler's complaints, it is obvious that the 
> compiler erred
> when tracking the result value from some call to strlen().  If you want help 
> then
> please supply the complete source code.  I could not locate the downloadable 
> source for
>    [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
> even after following several links.
If still interested here is the srpm [1] (the patch is in tmp.diff)

Thanks everyone for all the input!!! It was definitely appreciated!! 

steved.

[1] http://people.redhat.com/steved/.tmp/nfs-utils-2.5.2-1.fc34.src.rpm
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Rawhide build failure on strange archs

[Steve Dickson]

Hello,

I'm getting a build failure on the armv7hl arch
and the i686 arch, which do not make much sense.

The build is [1] and only those arche are  complaining about an sprintf() 
statement.
The rest of the arches are fine with the statment... %99.9 of the arches
that are used today... I didn't even realize i686 was still supported!

The is the failure:
conffile.c: In function 'conf_init_dir':
conffile.c:707:22: error: '%s' directive writing between 6 and 2147483645 bytes 
into a region of size between 4095 and 4096 [-Werror=format-overflow=]
  707 |   sprintf(fname, "%s/%s", dname, d->d_name);
  |  ^~
In file included from /usr/include/stdio.h:866,
 from conffile.c:45:
/usr/include/bits/stdio2.h:38:10: note: '__sprintf_chk' output 8 or more bytes 
(assuming 2147483648) into a destination of size 4097
   38 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  |  ^~
   39 |   __bos (__s), __fmt, __va_arg_pack ());
  |   ~

So I change the sprintf() to an snprintf() [2] guaranteeing no
overflow and I got the same failure. So it is something esoteric 
about those arches... that I'm missing... 

Anybody have clue as to what is going on??

tia,

steved.


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=55126237
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Removing unsupported AUTH_DES interfaces in libtirpc.

[Steve Dickson]

Hey... 

Thanks for all the input!

On 10/19/20 1:21 PM, Steve Dickson wrote:
> Hello,
> 
> About a year ago I stub out the interfaces
> and had them return an error if called. 
> No one has complained... 
> 
> This time I would like to remove interfaces
> so there will be no support whatsoever to 
> pass some upcoming audits... 
> 
> This means I will need to change the SONAME for 
> libtirpc which will effect a large other packages.
> 
> The last time I did this all hell broke out so
> I'm trying to avoid that this time.
> 
> So can someone please point me to the correct
> way to change a SONAME without cause total chaos
> 

It sounds like I'm trying to fix something that is 
not broken... and I too want want to keep the 
ABI as stable as possible.

So I will nix the idea of changing the SONAME 
and just remove functions from the header files.

Thanks again!!

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

Removing unsupported AUTH_DES interfaces in libtirpc.

[Steve Dickson]

Hello,

About a year ago I stub out the interfaces
and had them return an error if called. 
No one has complained... 

This time I would like to remove interfaces
so there will be no support whatsoever to 
pass some upcoming audits... 

This means I will need to change the SONAME for 
libtirpc which will effect a large other packages.

The last time I did this all hell broke out so
I'm trying to avoid that this time.

So can someone please point me to the correct
way to change a SONAME without cause total chaos

tia,

steved.


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

Re: Kerberos authentication fails: unable to obtain a session

[Steve Dickson]

On 3/10/20 1:55 PM, Kevin Fenzi wrote:
> On Tue, Mar 10, 2020 at 10:42:09AM -0400, Steve Dickson wrote:
>> Hello,
>>
>> I'm trying to do a scratch build 
>> $ fedpkg scratch-build --arches x86_64 --srpm
>>
>> and I'm getting the $SUBJECT error. I know I have 
>> a Kerberos ticket:
>>
>> $ klist 
>> Ticket cache: KEYRING:persistent:24013:krb_ccache_zynJSfJ
>> Default principal: ste...@fedoraproject.org
>>
>> Valid starting   Expires  Service principal
>> 03/10/2020 10:35:13  03/10/2020 20:34:33  
>> HTTP/proxy01.fedoraproject@fedoraproject.org
> 
> This should normally be 'HTTP/koji.fedoraproject@fedoraproject.org'
> 
> when you see a proxy name there it usually means you have rdns true in
> /etc/krb5.conf (it should be false), or krb_rdns or krb_canon_host true
> in /etc/koji.conf or ~/.koji.conf (should be false). 
That worked... Thank you very much!!!

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

Re: Kerberos authentication fails: unable to obtain a session

[Steve Dickson]

On 3/10/20 10:42 AM, Steve Dickson wrote:
> Hello,
> 
> I'm trying to do a scratch build 
> $ fedpkg scratch-build --arches x86_64 --srpm
> 
> and I'm getting the $SUBJECT error. I know I have 
> a Kerberos ticket:
> 
> $ klist 
> Ticket cache: KEYRING:persistent:24013:krb_ccache_zynJSfJ
> Default principal: ste...@fedoraproject.org
> 
> Valid starting   Expires  Service principal
> 03/10/2020 10:35:13  03/10/2020 20:34:33  
> HTTP/proxy01.fedoraproject@fedoraproject.org
>   renew until 03/17/2020 10:34:33
> 03/10/2020 10:34:41  03/10/2020 20:34:33  
> krbtgt/fedoraproject@fedoraproject.org
>   renew until 03/17/2020 10:34:33
> 
> 
> Any ideas?
It turns out I can get a ticket from another machine.. 

Sorry for the noise.

steved.

> 
> tia,
> 
> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Kerberos authentication fails: unable to obtain a session

[Steve Dickson]

Hello,

I'm trying to do a scratch build 
$ fedpkg scratch-build --arches x86_64 --srpm

and I'm getting the $SUBJECT error. I know I have 
a Kerberos ticket:

$ klist 
Ticket cache: KEYRING:persistent:24013:krb_ccache_zynJSfJ
Default principal: ste...@fedoraproject.org

Valid starting   Expires  Service principal
03/10/2020 10:35:13  03/10/2020 20:34:33  
HTTP/proxy01.fedoraproject@fedoraproject.org
renew until 03/17/2020 10:34:33
03/10/2020 10:34:41  03/10/2020 20:34:33  
krbtgt/fedoraproject@fedoraproject.org
renew until 03/17/2020 10:34:33


Any ideas?

tia,

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

Re: Fedora 31 Network Strangeness

[Steve Dickson]

On 1/31/20 10:31 AM, Tom Hughes wrote:
> On 31/01/2020 15:29, Tom Hughes wrote:
>> On 31/01/2020 15:23, Steve Dickson wrote:
>>
>>>> I know there was a change with systemd-networkd in a recent release so
>>>> that it now creates a unique but persistent MAC for bridges and maybe
>>>> other systems like NetworkManager have done the same?
>>> Hmm... this seems odd to me... any idea why this was done?
>>
>> I believe this is the relevant NEWS entry:
>>
>>    https://github.com/systemd/systemd/blob/master/NEWS#L926
>>
>> I think the idea is to ensure that a bridge always has the same
>> address, as by default it gets the address of whichever slave
>> happens to join first - that's fine in the common case where
>> there is one address added at boot and then others come and go
>> but may be non-deterministic if multiple addresses are added
>> at boot time.
> 
> Actually thinking about it the MAC address policy comes from a
> link unit so is applied by udev and isn't systemd-networkd specific.
> 
> There is an example in that NEWS entry of a link unit to turn
> this off and go back to the old behaviour.

Thanks for the info!! 

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

Re: Fedora 31 Network Strangeness

[Steve Dickson]

On 1/31/20 9:55 AM, Tom Hughes wrote:
> On 31/01/2020 14:28, Steve Dickson wrote:
> 
>> I've recently updated my laptop to F31. Then I was no longer
>> able to ssh into it. After a little debugging... it turns
>> out my laptop was not getting the expected ip address
>> from DHCP. The reason for that was the MAC address it was
>> sending to dhcpd had change!!! Looking at the interfaces
>>
>> bridge0: flags=4163  mtu 1500
>>  inet 172.31.1.175  netmask 255.255.0.0  broadcast 172.31.255.255
>>  inet6 fe80::98f9:f0d0:4b79:cdaa  prefixlen 64  scopeid 0x20
>>  ether 3a:00:66:8a:dd:b9  txqueuelen 1000  (Ethernet)
>>  RX packets 259601  bytes 112149182 (106.9 MiB)
>>  RX errors 0  dropped 0  overruns 0  frame 0
>>  TX packets 256704  bytes 39319273 (37.4 MiB)
>>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> enp0s31f6: flags=4163  mtu 1500
>>  ether 8c:16:45:fe:c1:f1  txqueuelen 1000  (Ethernet)
>>  RX packets 355186  bytes 134328851 (128.1 MiB)
>>  RX errors 0  dropped 0  overruns 0  frame 0
>>  TX packets 256743  bytes 40395059 (38.5 MiB)
>>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>  device interrupt 16  memory 0xec20-ec22
>>
>> The bridge0 interface has as different MAC that the enp0s31f6 interface.
>> How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
>> is set in the ifcfg-bridge0_slave_1.
> 
> How are you managing your network? NetworkManager? systemd-networkd? The
> old network rc script?
Using systemctl status it appears NetworkManager is active and
systemd-networkd is not so I guess NetworkManager is doing the management

> 
> I know there was a change with systemd-networkd in a recent release so
> that it now creates a unique but persistent MAC for bridges and maybe
> other systems like NetworkManager have done the same?
Hmm... this seems odd to me... any idea why this was done?

tia,

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

Fedora 31 Network Strangeness

[Steve Dickson]

Hello,

I've recently updated my laptop to F31. Then I was no longer
able to ssh into it. After a little debugging... it turns
out my laptop was not getting the expected ip address 
from DHCP. The reason for that was the MAC address it was
sending to dhcpd had change!!! Looking at the interfaces 

bridge0: flags=4163  mtu 1500
inet 172.31.1.175  netmask 255.255.0.0  broadcast 172.31.255.255
inet6 fe80::98f9:f0d0:4b79:cdaa  prefixlen 64  scopeid 0x20
ether 3a:00:66:8a:dd:b9  txqueuelen 1000  (Ethernet)
RX packets 259601  bytes 112149182 (106.9 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 256704  bytes 39319273 (37.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s31f6: flags=4163  mtu 1500
ether 8c:16:45:fe:c1:f1  txqueuelen 1000  (Ethernet)
RX packets 355186  bytes 134328851 (128.1 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 256743  bytes 40395059 (38.5 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 16  memory 0xec20-ec22  

The bridge0 interface has as different MAC that the enp0s31f6 interface.
How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
is set in the ifcfg-bridge0_slave_1.

What has changed and where is the bridge MAC address coming from???

tia,

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

1794117 – Disabling support for UDP for NFSv3

[Steve Dickson]

FYI... 

NFS over UDP will be deprecated in the 5.6 kernel. 

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

Its not clear what or if any havoc this could cause
but the commit (f745bfdc) has been accepted upstream.
Just letting the community know...  

If by chance a bz is opened, please feel free to send me a 
private email with the link... As we all know Bugzilla 
is just another word for... spam! ;-) 

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

1794117 – Disabling support for UDP for NFSv3

[Steve Dickson]

FYI... 

NFS over UDP will be deprecated in the 5.6 kernel. 

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

Its not clear what or if any havoc this could cause
but the commit (f745bfdc) has been accepted upstream.
Just letting the community know...  

If by chance a bz is opened, please feel free to send me a 
private email with the link... As we all know Bugzilla 
is just another word for... spam! ;-) 

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

New Package Process

[Steve Dickson]

Hello,

I have a new contributor who wants to get 
a package into Fedora.  

The package is called "Flight Data Recorder"
   https://github.com/oracle/fdr

It manages ftraces to record kernel data in way, when 
there is a kernel crash, one can go back and "see" what
happen... It sounds very promising IMHO.

Now I've done this process a number of times
in the past... but not for a while and there 
always seems to be a few new tweaks... 

So could point me to the latest doc on 
how to get a package in from a existing and 
non-existing contributor. I would appreciated it.

tia,

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

Re: Question about libtirpc CNAME Change.

[Steve Dickson]

Hello,

On 11/18/19 10:44 AM, Florian Weimer wrote:
> * Steve Dickson:
> 
>> In a recent upstream commit, the outdated, unsupported
>> AUTH_DES authentication is now compiled out by default.
>>
>> This does effect the API, but does it really need a CNAME change
>> since it interface can be recompiled back in? 
>>
>> The reason I ask, change libtirpc's CNAME will require
>> a large number of packages (at least 40) to be
>> rebuild (aka rawhide chaos at its finest!) 
> 
> Do you mean a SONAME change?
Yup... I did!

> 
> No, you shouldn't do that.  Just stub out the functions so that they
> always fail when called, but leave the symbols there.
Ok... thanks!

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

Question about libtirpc CNAME Change.

[Steve Dickson]

Hello,

In a recent upstream commit, the outdated, unsupported
AUTH_DES authentication is now compiled out by default.

This does effect the API, but does it really need a CNAME change
since it interface can be recompiled back in? 

The reason I ask, change libtirpc's CNAME will require
a large number of packages (at least 40) to be
rebuild (aka rawhide chaos at its finest!) 

tia,

steved.

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

Changing the maintainer on a couple packages

[Steve Dickson]

Hello,

I would like to change the maintership of nfsometer 
and nfstest now that they have been re-write in
python 3.  

How do I do that?

tia,

steved.
___
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: sign_and_send_pubkey: signing failed: agent refused operation

[Steve Dickson]

On 5/16/19 5:11 AM, Jakub Jelen wrote:
> On Wed, 2019-05-15 at 17:09 -0400, Steve Dickson wrote:
>> Hello,
>>
>> I'm getting the following error when I'm access the fedora git trees.
>>
>> sign_and_send_pubkey: signing failed: agent refused operation
>> ste...@pkgs.fedoraproject.org: Permission denied (publickey).
>> fatal: Could not read from remote repository.
>>
>> Please make sure you have the correct access rights
>> and the repository exists.
>>
>> Now I know I have the correct publickey (id_rsa/id_rsa.pub)
>> because they work on a different host. and generally 
>> when I have the wrong keys, I get the above error minus
>>
>> sign_and_send_pubkey: signing failed: agent refused operation
>>
>> Any idea what is happening? 
> 
> What Fedora and OpenSSH version are you using? 
Update F29 and  openssh-7.9p1-5.fc29

> Does it work if you downgrade openssh? 
Do do for some reason things started working again w/out a downgrade.

Are you using gnome-keyring? 
No.

> What is the output of "echo $SSH_AUTH_SOCK"?
/run/user/3606/keyring/ssh

> 
> This error means that the agent fails to provide the signature using
> your private key for some reason. Running the ssh-agent separately in
> debug mode (ssh-agent -d) might show a bit more information.
OK... thanks for the tip... but like I said.. things just started
working again... Maybe was because I am on a remote Oracle campus? ;-) 

Thanks!

steved.

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

sign_and_send_pubkey: signing failed: agent refused operation

[Steve Dickson]

Hello,

I'm getting the following error when I'm access the fedora git trees.

sign_and_send_pubkey: signing failed: agent refused operation
ste...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Now I know I have the correct publickey (id_rsa/id_rsa.pub)
because they work on a different host. and generally 
when I have the wrong keys, I get the above error minus

sign_and_send_pubkey: signing failed: agent refused operation

Any idea what is happening? 

tia,

steved.
___
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: Did the XML API change?

[Steve Dickson]

On 12/11/18 11:59 AM, Igor Gnatenko wrote:
> No, it didn't. BUT I believe that the problem is here:
> 
> /bin/sh ../../libtool  --tag=CC   --mode=link gcc -pipe  -Wall
> -Wextra  -Werror=strict-prototypes  -Werror=missing-prototypes
> -Werror=missing-declarations  -Werror=format=2  -Werror=undef
> -Werror=missing-include-dirs  -Werror=strict-aliasing=2
> -Werror=init-self  -Werror=implicit-function-declaration
> -Werror=return-type  -Werror=switch  -Werror=overflow
> -Werror=parentheses  -Werror=aggregate-return  -Werror=unused-result
> -fno-strict-aliasing  -Werror=format-overflow=2 -Werror=int-conversion
> -Werror=incompatible-pointer-types -Werror=misleading-indentation -O2
> -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -D_FILE_OFFSET_BITS=64  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libjunction.la
> display.lo export-cache.lo junction.lo locations.lo nfs.lo path.lo
> xml.lo  -lresolv
> …
> /usr/bin/ld: ../../support/junction/.libs/libjunction.a(nfs.o): in
> function `nfs_parse_xml':
> /builddir/build/BUILD/nfs-utils-2.3.3/support/junction/nfs.c:1386:
> undefined reference to `xmlXPathNewContext'
> 
> libjunction.la is not linked against libxml2 and later when you
> construct nfsref, it is failing with undefined symbols.
Got it... thanks!!!

steved.

> On Tue, Dec 11, 2018 at 5:55 PM Steve Dickson  wrote:
>>
>> Hello,
>>
>> I'm getting a bunch of xml routines undefined
>>
>> https://koji.fedoraproject.org/koji/getfile?taskID=31408933=DEFAULT=build.log=-4000
>>
>> on my rawhide build... everything builds just fine on f29...
>> and I have BuildRequires: libxml2-devel
>>
>> Is there something more I have BuildRequires on rawhide?
>>
>> tia,
>>
>> steved.
>> ___
>> 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
> 
___
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: Did the XML API change?

[Steve Dickson]

On 12/11/18 11:59 AM, Tom Hughes wrote:
> On 11/12/2018 16:46, Steve Dickson wrote:
> 
>> I'm getting a bunch of xml routines undefined
>>
>> https://koji.fedoraproject.org/koji/getfile?taskID=31408933=DEFAULT=build.log=-4000
>>
>> on my rawhide build... everything builds just fine on f29...
>> and I have BuildRequires: libxml2-devel
>>
>> Is there something more I have BuildRequires on rawhide?
> 
> You probably want to have libjunction.a before -lxml2 when linking.
That worked... thanks!!

steved.
> 
> Tom
> 
___
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

Did the XML API change?

[Steve Dickson]

Hello,

I'm getting a bunch of xml routines undefined 

https://koji.fedoraproject.org/koji/getfile?taskID=31408933=DEFAULT=build.log=-4000

on my rawhide build... everything builds just fine on f29... 
and I have BuildRequires: libxml2-devel

Is there something more I have BuildRequires on rawhide?

tia,

steved.
___
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 30: Deprecating /etc/sysconf/nfs

[Steve Dickson]

On 10/12/18 2:54 PM, Stephen Gallagher wrote:
> On Fri, Oct 12, 2018 at 2:48 PM Steve Dickson  wrote:
>>
>> Hello,
>>
>> A few years back there was a movement the NFS community
>> to consulate all nfs configuration into one file
>> call /etc/nfs.conf... See nfs.conf(5)
>>
>> Maybe stupidly, I've maintain backwards compatibility
>> for that last couple Fedora releases. I think it is
>> time to go to the single file configuration, since
>> the development on Fedora 29 is winding down and
>> it's winding up for Fedora 30.
>>
>> On fresh rawhide installs /etc/sysconfig/nfs will still
>> be installed but with direction to use /etc/nfs.conf
>>
>> If /etc/sysconfig/nfs does exists the configuration will
>> *not* be overridden... but the systemd scripts will
>> no longer use that file to do any configuration.
>>
>> We are working tool that will convert sysconfig/nfs
>> configs into nfs.conf configs... It is not clear
>> how I'm going to package it since it is something
>> I do not want to support forever... but only time will tell.
>>
>> I'm not sure what will break, but pretty sure something
>> is going to break. ;-) I'm steved on freenode and OFTC
>> IRC channels... feel ping me...
>>
> 
> 
> Steve, please file a Change Proposal[1] for Fedora 30 to submit to
> FESCo so we can help coordinate this.
Done... 
 https://fedoraproject.org/wiki/Changes/nfs.conf

Is there anything else that need to happen?

steved.
___
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 30: Deprecating /etc/sysconf/nfs

[Steve Dickson]

Hello,

A few years back there was a movement the NFS community
to consulate all nfs configuration into one file 
call /etc/nfs.conf... See nfs.conf(5)

Maybe stupidly, I've maintain backwards compatibility
for that last couple Fedora releases. I think it is
time to go to the single file configuration, since
the development on Fedora 29 is winding down and
it's winding up for Fedora 30.

On fresh rawhide installs /etc/sysconfig/nfs will still
be installed but with direction to use /etc/nfs.conf

If /etc/sysconfig/nfs does exists the configuration will
*not* be overridden... but the systemd scripts will
no longer use that file to do any configuration.

We are working tool that will convert sysconfig/nfs
configs into nfs.conf configs... It is not clear
how I'm going to package it since it is something
I do not want to support forever... but only time will tell.

I'm not sure what will break, but pretty sure something
is going to break. ;-) I'm steved on freenode and OFTC
IRC channels... feel ping me...

steved.
___
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: The update system has the wrong package

[Steve Dickson]

On 05/31/2018 12:02 PM, Randy Barlow wrote:
> On 05/30/2018 02:23 PM, Steve Dickson wrote:
>> You are right... I only did a rawhide build... but that is no longer the case
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=27299567
>>
>> And I'm still having the problem... the update system is only
>> showing rpcsvc-proto-devel instead rpcsvc-proto which is definitely
>> since  rpcsvc-proto-devel is part of the rpcsvc-proto package.
> 
> As Adam said, you should be able to manually type the NVR into the
> candidate builds box.
That's what I did... Thanks!

steved.
___
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/message/HP2AXF4WNUKJGT333R27YH7UDZPWZVIA/

Re: The update system has the wrong package

[Steve Dickson]

On 05/29/2018 05:00 PM, Adam Williamson wrote:
> On Tue, 2018-05-29 at 16:54 -0400, Steve Dickson wrote:
>> Hello,
>>
>> I'm trying to update the rpcsvc-proto package. 
>> When I try to create a new update, the system
>> only gives me rpcsvc-proto-devel as a choice
>> not rpcsvc-proto.
>>
>> Where do I open up a ticket to get this taken 
>> care of? 
> 
> https://github.com/fedora-infra/bodhi
Thank you... https://github.com/fedora-infra/bodhi/issues/2397

> 
> but you can just free type the NVR into the relevant field, note. If
> it's a valid NVR for a build with the right tags it'll be accepted.
> 
I can't seem to get that to work... :-(

steved.
___
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/message/5LIXBPU5RMSP3UUHVNJTKG2ODRXSFY5U/

Re: The update system has the wrong package

[Steve Dickson]

On 05/29/2018 06:40 PM, Michael Schwendt wrote:
> On Tue, 29 May 2018 16:54:00 -0400, Steve Dickson wrote:
> 
>> Hello,
>>
>> I'm trying to update the rpcsvc-proto package. 
>> When I try to create a new update, the system
>> only gives me rpcsvc-proto-devel as a choice
>> not rpcsvc-proto.
>>
>> Where do I open up a ticket to get this taken 
>> care of? 
> 
> Koji doesn't display any update for F28 or older, so which candidate
> build do you refer to? For Rawhide F29 you don't need to file update
> tickets in bodhi.
You are right... I only did a rawhide build... but that is no longer the case
https://koji.fedoraproject.org/koji/taskinfo?taskID=27299567

And I'm still having the problem... the update system is only
showing rpcsvc-proto-devel instead rpcsvc-proto which is definitely
since  rpcsvc-proto-devel is part of the rpcsvc-proto package.

steved.
___
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/message/OBA47IEC7TFKCHLVXRFDACCLKG6CWYGM/

The update system has the wrong package

[Steve Dickson]

Hello,

I'm trying to update the rpcsvc-proto package. 
When I try to create a new update, the system
only gives me rpcsvc-proto-devel as a choice
not rpcsvc-proto.

Where do I open up a ticket to get this taken 
care of? 

steved.
___
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/message/6LEGYVJDV3NMLRXVM63RUL6XZWOSILVX/

Problem: package fwupdate-libs-10-6.fc28.x86_64 requires shim

[Steve Dickson]

Hello,

I've getting the following error when I try to update from f27 to f28:

# dnf system-upgrade download --refresh --releasever=28
Before you continue ensure that your system is fully upgraded by running "dnf 
--refresh upgrade". Do you want to continue [y/N]: y
Fedora 28 - x86_64 - Updates4.1 kB/s | 257  B 00:00
Fedora 28 - x86_64  2.0 MB/s |  60 MB 00:30
Last metadata expiration check: 0:00:00 ago on Sat 10 Mar 2018 01:30:36 PM EST.
Error: 
 Problem: package fwupdate-libs-10-6.fc28.x86_64 requires shim, but none of the 
providers can be installed
  - problem with installed package fwupdate-libs-10-1.fc27.x86_64
  - shim-x64-13-0.7.x86_64 does not belong to a distupgrade repository
  - fwupdate-libs-10-1.fc27.x86_64 does not belong to a distupgrade repository

Looking at the koji builds there is no shim-x64... but there is a shim-13

Any ideas?

tia,

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

Re: libevent-2.1.8 SONAME change.

[Steve Dickson]

On 02/15/2018 07:04 AM, Peter Robinson wrote:
> On Thu, Feb 15, 2018 at 11:51 AM, Steve Dickson <ste...@redhat.com> wrote:
>> Hello,
>>
>> Yesterday I updated libevent to the latest upstream release.
>>
>> I mistakenly did not realized there was a SONAME change
>> in this update. So if your package is dependent on
>> libevent, you are going to have to rebuild.
>>
>> My apologies for this oversight...
> 
> Specifying major version numbers in the library files (extract below)
> will ensure a build failure when the soname bumps to ensure this
> doesn't happen and that you're aware of it can do do appropriate
> communication/side tag builds/etc so it doesn't break rawhide for
> everyone else that's trying to get things done in the future.
> 
> %{_libdir}/libevent-*.so.*
> %{_libdir}/libevent_core-*.so.*
> %{_libdir}/libevent_extra-*.so.*
> %{_libdir}/libevent_openssl-*.so.*
> %{_libdir}/libevent_pthreads-*.so.*

Excellent idea! The rawhide rpm has been updated.

Again... sorry for the pain. 

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

libevent-2.1.8 SONAME change.

[Steve Dickson]

Hello,

Yesterday I updated libevent to the latest upstream release.

I mistakenly did not realized there was a SONAME change
in this update. So if your package is dependent on 
libevent, you are going to have to rebuild. 

My apologies for this oversight... 

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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[Steve Dickson]

On 01/29/2018 12:42 PM, Steven Whitehouse wrote:
> 
> 
> 
>  Forwarded Message 
> Subject:  Re: Fedora27: NFS v4 terrible write performance, is async 
> working
> Date: Sun, 28 Jan 2018 21:17:02 +
> From: Terry Barnaby <ter...@beam.ltd.uk>
> To:   Steven Whitehouse <swhit...@redhat.com>, Development discussions 
> related to Fedora <devel@lists.fedoraproject.org>, Terry Barnaby 
> <ter...@beam.ltd.uk>
> CC:   Steve Dickson <ste...@redhat.com>, Benjamin Coddington 
> <bcodd...@redhat.com>
> 
> 
> 
> On 28/01/18 14:38, Steven Whitehouse wrote:
>> Hi,
>>
>>
>> On 28/01/18 07:48, Terry Barnaby wrote:
>>> When doing a tar -xzf ... of a big source tar on an NFSv4 file system 
>>> the time taken is huge. I am seeing an overall data rate of about 1 
>>> MByte per second across the network interface. If I copy a single 
>>> large file I see a network data rate of about 110 MBytes/sec which is 
>>> about the limit of the Gigabit Ethernet interface I am using.
>>>
>>> Now, in the past I have used the NFS "async" mount option to help 
>>> with write speed (lots of small files in the case of an untar of a 
>>> set of source files).
>>>
>>> However, this does not seem to speed this up in Fedora27 and also I 
>>> don't see the "async" option listed when I run the "mount" command. 
>>> When I use the "sync" option it does show up in the "mount" list.
>>>
>>> The question is, is the "async" option actually working with NFS v4 
>>> in Fedora27 ?
No. Its something left over from v3 that allowed servers to be unsafe.
With v4, the protocol defines stableness of the writes.

>>> ___
>>
>> What server is in use? Is that Linux too? Also, is this v4.0 or v4.1? 
>> I've copied in some of the NFS team who should be able to assist,
>>
>> Steve.
> 
> Thanks for the reply.
> 
> Server is a Fedora27 as well. vers=4.2 the default. Same issue at other 
> sites with Fedora27.
> 
> Server export: "/data *.kingnet(rw,async,fsid=17)"
> 
> Client fstab: "king.kingnet:/data /data nfs async,nocto 0 0"
> 
> Client mount: "king.kingnet:/data on /data type nfs4 
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,nocto,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.202.2,local_lock=none,addr=192.168.202.1)"
> 
> 
This looks normal except for setting fsid=17...

The best way to debug this is to open up a bugzilla report
and attached a (compressed) wireshark network trace to see 
what is happening on the wire... The entire tar is not needed
just a good chunk...

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

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

[Steve Dickson]

On 01/15/2018 01:28 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 15, 2018 at 11:04:32AM -0500, Steve Dickson wrote:
>>
>>
>> On 01/10/2018 05:46 AM, Jan Kurik wrote:
>>> = System Wide Change: Rename "nobody" user =
>>> https://fedoraproject.org/wiki/Changes/RenameNobodyUser
>> A nit... The proposed rename looks like:
>> nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin
>>
>> Now that this is going to be used for NFS, should the user information 
>> field be more generic? 
>>
>> Because with NFS is not an overflow its a id mapping. Maybe just 'Kernel 
>> User'? 
>>
>> Again... just an incredibly small nit! ;-) 
> Hmm, good point. Maybe "Kernel Unmappable User" ?
> nss-systemd in it's code currently uses "User Nobody", but that
> doesn't explain anything, and I think that both pieces of
> information are important to convey: that it is a kernel
> concept, and that it is for overflow/unmapped users that are
> hence anonymous.
"Kernel Unmappable User" works... IMHO.

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

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

[Steve Dickson]

On 01/10/2018 05:46 AM, Jan Kurik wrote:
> = System Wide Change: Rename "nobody" user =
> https://fedoraproject.org/wiki/Changes/RenameNobodyUser
A nit... The proposed rename looks like:
nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin

Now that this is going to be used for NFS, should the user information 
field be more generic? 

Because with NFS is not an overflow its a id mapping. Maybe just 'Kernel User'? 

Again... just an incredibly small nit! ;-) 

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

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

[Steve Dickson]

Hello,

In summary: Legacy application that expect the 99 uid or the 
'nfsnobody' user name will break, but from an NFS protocol
aspect I think we are fine since the same value is going
over the wire. 

This is a Fedora only thing since the user name nfsnobody is 
not used in other distros. 

The Details:
On 01/13/2018 06:18 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jan 13, 2018 at 10:18:14AM -0500, Steve Dickson wrote:
>> On 01/13/2018 08:50 AM, Steve Dickson wrote:
>>> So I guess the next question is what the current
>>> nobody id (25) used for and why does it exist?
>>
>> Doing some research on this back in Aug 2001
>> nfsnobody was added to nfs-utils for the reasons stated in 
>>https://bugzilla.redhat.com/show_bug.cgi?id=22685
> That bug is rh-private. Copying the important bit below:
> 
> Bob Matthews 2001-08-24 11:50:09 EDT
>> Hackish fix is in RAWHIDE.  I'm marking this closed DEFERRED until a real
>> fix comes down the pipe from the nfs-utils maintaine>
> There weren't any reasons really, except the need to quickly provide a
> name for 65534 and 'nobody' was already used for 99 and there wasn't
> time to do the renaming properly. I think it is fitting that we finish
> the process with a proper fix to change the bug status to RESOLVED for
> the 17th anniversary.
Googling 'linux nobody uid' it appears nobody is a uid used by apps
that don't want to run as root. In case they got hacked the would 
not have root privileges, but with SElinux around I think that
problem has been solve. 

But legacy apps that do a chown(3) call to uid 99 will break.

> 
> So... I was away from this thread for two days, and there was a lot of
> back and forth, but not too much new information.  For this change to
> be implemented properly, input from NFS maintainers is very important.
> Steve, please, consider if there are any changes needed in nfs-utils
> to support the nfsnobody→nobody name change, apart from what is
> described in the Change page. If some additional info or steps need to
> be added, please say so.
Again, the biggest issue I see is backwards compatibility with NFS
users expecting nfsnobody to exist. Protocol wise I think we are
fine since the value is going over the wire will not change.

Is it wrong to expect a uid or user name to exist across releases?
In the Fedora world... probably not... but in the enterprise 
world... it could be. Only time will tell. 

 
The change has to made in two packages nfs-utils and setup
with the bigger change in setup. 

From packaging stand point I think it would be good for 
nfs-utils to get out of the user/group creation business, 
so once the changes are made to setup, I'll just add a 
dependency to the setup and no longer create users 
and groups.

Here is what has to change:
From:
nobody:x:99:99:Nobody:/:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
nobody:x:99:
nfsnobody:x:65534:

To:
nobody:x:65534:65534:Nobody:/:/sbin/nologin
nobody:x:65534

With a few other nits to be cleaned up in setup.

Since we are here... does it make sense to update nobody 
home directory to something like:

nobody:x:65534:65534:Nobody:/root:/sbin/nologin

Or give it its own home dir:

nobody:x:65534:65534:Nobody:/nobody:/sbin/nologin

Obviously that is up to the maintainers of setup.

What is the next step? Use that old bz or create
new ones?

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

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

[Steve Dickson]

On 01/13/2018 08:50 AM, Steve Dickson wrote:
> So I guess the next question is what the current
> nobody id (25) used for and why does it exist?

Doing some research on this back in Aug 2001
nfsnobody was added to nfs-utils for the reasons stated in 
   https://bugzilla.redhat.com/show_bug.cgi?id=22685

Basically they were concern about changing the 
uid value of the current 'nobody' account.

Why? IDK... 

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

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

[Steve Dickson]

On 01/12/2018 07:32 PM, Louis Lagendijk wrote:
> On Fri, 2018-01-12 at 07:20 -0500, Steve Dickson wrote:
>> Instead of doing the blow by blow these threads
>> always turn into I'm just going jump to the point.
>>
>> systemd wants to use uid 65534 and it can't because
>> NFS is using it. So instead of changing systemd needs
>> they want to change NFS potentially break all NFS 
>> environments. 
>>
>> Is or isn't this what we are talking about without
>> all the bloviation to justify the change.
>>
>> steved.
> 
> Breaking all NFS environments is a (way?) too strong statement. My file
> server is running Freebsd and it uses 65534 as userid for default.
> Freebsd however calls it nobody, go, figure Now for nfs this is
> nowadays no problem anymore as we have the id-mapper. It now maps
> between 99 and  65534 and will start to automagically map between 65534
> and 65534. 
> Are there any real world examples of files owned by nobody left on
> Fedora?
> 
> I guess that other OSs/distributions use 65534 for nobody, so this
> change would improve inter-operability with other environments.
I was worried the over-the-wire uid was going to change but at 
this point I have a better understanding of what is needed.

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

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

[Steve Dickson]

On 01/12/2018 05:11 PM, Neal Gompa wrote:
>> Side Note: I have a ping out to a SUSE guy to see how they handle this
>> but the guy lives on the other side of the earth so I probably
>> will not get a response until tomorrow.
> I can tell you what that is, as I run (open)SUSE systems.
> 
> SUSE systems set the following in their /etc/passwd:
> nobody:x:65534:65533:nobody:/var/lib/nobody:/bin/bash
> 
> This is what they set for /etc/group:
> nobody:x:65533:
> nogroup:x:65534:nobody
> 
> This only varies slightly from what Mageia and Debian/Ubuntu do in
> that nobody is both a member of nogroup but has its own nobody group.
I too verified the above but they also have this id mapping
in /etc/idmapd.conf
 [Mapping]
nobody-user = nobody
Nobody-Group = nobody

which is the glue to make the nobody id used.
We have these commented out, by default.

So I guess the next question is what the current
nobody id (25) used for and why does it exist?

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

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

[Steve Dickson]

On 01/12/2018 10:57 AM, Daniel Walsh wrote:
> On 01/12/2018 10:41 AM, Steve Dickson wrote:
>>
>> On 01/12/2018 09:47 AM, Lennart Poettering wrote:
>>> On Fr, 12.01.18 09:28, Steve Dickson (ste...@redhat.com) wrote:
>>>
>>>>> User namespacing is a Linux kernel feature. It's most well known
>>>>> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
>>>> Well know for how long?
>>> The commit adding user namespaces to the Linux kernel was in 2007. 11
>>> years ago, in kernel 2.6.23.
>> Wow... we've been living this way a long time... Seemly without any problems?
>> If that is the case then I really don't see a need for this change
>> that could potentially cause such havoc.
> Having this in the kernel and actually anyone using it are two different 
> things.  We are just beginning to finally use this now.
Ah... this explains the exposure of nfsnobody... 

So if its just beginning to be used... we can change the defaults... right? :-) 

>>  
>>>>> It's not systemd that came up with reusing 65534 for user
>>>>> namespacing. It's kernel people:
>>>>>
>>>>>  $ cat /proc/sys/kernel/overflowuid
>>>>>  65534
>>>> How was that number chosen and why can't be changed?
>>> It's conceptually the same thing: it's where UIDs are mapped that
>>> cannot be mapped properly otherwise.
>> Right... I'm assuming this overflow almost never happens
>> from looking at the code.
> Well in UserNamespace it happens all the time.  Basically any Inode that is 
> owned by a uid that is not mapped in the usernamespace will be reported as 
> this UID.
Ok... understood.

>>> In theory you can change it by echoing something into sysctl, but
>>> that's mostly theoretic, and not what the various consumers of userns
>>> do.
>> Understood.
>>
>>> And regardless, it's conceptually the same thing anyway, so it makes a
>>> ton of sense to use the UID there for both NFS and userns
>>> purposes. While I have my reservations about userns in general the
>>> logic behind using that UID for this purpose is very clear to me and
>>> makes sense as far as I can see.
>>>
>> So the problem trying to be solved is when the overflow uid/gid
>> are used (which is rarely), the owner of the file become
>> nfsnobody which does not make any sense because it is on a local filesystem.
> It is not rare.
>> If this is the case, my I suggest that since the overflow uid/gid is
>> basically an arbitrary value and easily changeable... Why not
>> have some boot process echo '99' into /proc/sys/kernel/overflowuid
>> which would match nicely to a uid/gid of a user named 'nobody'?
> You would force everyone everwhere to make this change.
If I'm understanding your question... Yes this would be a fedora-only 
thing... but so what? We have a lot of Fedora only things.

Side Note: I have a ping out to a SUSE guy to see how they handle this
but the guy lives on the other side of the earth so I probably
will not get a response until tomorrow.

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

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

[Steve Dickson]

On 01/12/2018 09:47 AM, Lennart Poettering wrote:
> On Fr, 12.01.18 09:28, Steve Dickson (ste...@redhat.com) wrote:
> 
>>> User namespacing is a Linux kernel feature. It's most well known
>>> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
>> Well know for how long?
> 
> The commit adding user namespaces to the Linux kernel was in 2007. 11
> years ago, in kernel 2.6.23.
Wow... we've been living this way a long time... Seemly without any problems?
If that is the case then I really don't see a need for this change
that could potentially cause such havoc.
 
> 
>>> It's not systemd that came up with reusing 65534 for user
>>> namespacing. It's kernel people:
>>>
>>> $ cat /proc/sys/kernel/overflowuid 
>>> 65534
>> How was that number chosen and why can't be changed?
> 
> It's conceptually the same thing: it's where UIDs are mapped that
> cannot be mapped properly otherwise.
Right... I'm assuming this overflow almost never happens
from looking at the code. 

> 
> In theory you can change it by echoing something into sysctl, but
> that's mostly theoretic, and not what the various consumers of userns
> do.
Understood.

> 
> And regardless, it's conceptually the same thing anyway, so it makes a
> ton of sense to use the UID there for both NFS and userns
> purposes. While I have my reservations about userns in general the
> logic behind using that UID for this purpose is very clear to me and
> makes sense as far as I can see.
> 
So the problem trying to be solved is when the overflow uid/gid
are used (which is rarely), the owner of the file become 
nfsnobody which does not make any sense because it is on a local filesystem.

If this is the case, my I suggest that since the overflow uid/gid is 
basically an arbitrary value and easily changeable... Why not 
have some boot process echo '99' into /proc/sys/kernel/overflowuid 
which would match nicely to a uid/gid of a user named 'nobody'? 

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

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

[Steve Dickson]

On 01/12/2018 07:40 AM, Lennart Poettering wrote:
> On Fr, 12.01.18 07:20, Steve Dickson (ste...@redhat.com) wrote:
> 
>> Instead of doing the blow by blow these threads
>> always turn into I'm just going jump to the point.
>>
>> systemd wants to use uid 65534 and it can't because
>> NFS is using it. So instead of changing systemd needs
>> they want to change NFS potentially break all NFS 
>> environments.
> 
> This is really not helpful. Grow up.
sigh... 

> 
> User namespacing is a Linux kernel feature. It's most well known
> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.
Well know for how long?

> 
> Neither Docker, nor flatpak/bubblewrap, nor LXC are systemd projects.
> 
> It's not systemd that came up with reusing 65534 for user
> namespacing. It's kernel people:
> 
> $ cat /proc/sys/kernel/overflowuid 
> 65534
How was that number chosen and why can't be changed?
 
> 
> You know, if you want my personal opinion: 
I don't...

> 
>> Is or isn't this what we are talking about without
>> all the bloviation to justify the change.
> 
> It really is not. You *really* should read up on what the Linux kernel
> has been doing with user namespaces and how it started using the 65534
> UID for that.
> 
> That UID long ceased to be Steve Dickson's private property, and it's
> not systemd who took it away from you. It's evil evil kernel
> hackers. Please complain to them.
more sigh... This attitude is so old and unnecessary... sigh again... 

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

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

[Steve Dickson]

Instead of doing the blow by blow these threads
always turn into I'm just going jump to the point.

systemd wants to use uid 65534 and it can't because
NFS is using it. So instead of changing systemd needs
they want to change NFS potentially break all NFS 
environments. 

Is or isn't this what we are talking about without
all the bloviation to justify the change.

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

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

[Steve Dickson]

On 01/10/2018 11:14 AM, Stephen John Smoogen wrote:
> On 10 January 2018 at 08:50, Neal Gompa  wrote:
>> On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik  wrote:
> 
>>> The new mapping for nobody:nobody would be implemented in two redundant 
>>> ways:
>>> * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
>>> * dynamically provided by the nss-systemd module (by compiling systemd
>>> with -Dnobody-user=nobody -Dnobody-group=nobody).
>>>
>>
>> Two questions:
>>
>> 1. Why nobody:nobody instead of nobody:nogroup? I've seen the latter
>> in use in several distributions.
>> * For note, we use this in Mageia:
>> http://gitweb.mageia.org/software/setup/tree/group
>> * Debian and Ubuntu also define it this way.
>>
>> 2. For existing systems, would renaming the nobody:nobody user to
>> oldnobody:oldnobody work instead? The uid would be preserved, which
>> should keep the mapping sane, and it would make it more obvious that
>> it's old, rather than using weird underscores.
>>
>> In general, I support this change because the two nobody users made
>> things confusing for me and many other people. Simplifying this would
>> also harmonize things with everyone else, which helps for portability
>> of things. :)
>>
>>
> 
> I think all of the above would be good additions to this. Having dealt
> with multiple large deployments where 99:99 caused different problems
> but then were hard-coded into being fixed if something is Fedora/RHEL
> based... a lot of people updating to F28+ would have problems... and a
> lot of people update vs fresh install.
Your are correct... there will problems... compatible problems with
mostly likely legacy servers... like f27?? ;-) 

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

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

[Steve Dickson]

WOW... Why do you guys keep picking on NFS?? :-)

On 01/10/2018 05:46 AM, Jan Kurik wrote:
> = System Wide Change: Rename "nobody" user =
> https://fedoraproject.org/wiki/Changes/RenameNobodyUser
> 
> Change owner(s):
> *Zbigniew Jędrzejewski-Szmek 
> * Lennart Poettering 
> 
> Use "nobody:nobody" as the names for the kernel overflow UID:GID pair,
> and retire the old "nfsnobody" name and the old "nobody:nogroup" pair
> with 99:99 numbers
> 
> 
> == Detailed Description ==
> Status quo: Fedora statically defines "nobody:nobody" pair with
> uid:gid of 99:99 in setup.rpm, and "nfsnobody:nfsnobody" pair with
> uid:gid of 65534:65534 in nfs-utils.rpm.
> 
> This is problematic in a few different ways:
> * 65534:65534 is used by the kernel as the overflow identifier, when
> some UID cannot be represented in the current namespace. This applies
> to both NFS, but probably more commonly nowadays to UIDs outside of
> the current user namespace (e.g. when a file or process owned by a
> user from outside of a container). Calling this "nfsnobody" is
> misleading.
Misleading to Whom??? -2 has been used since the 80's 
There has to be an uid/gid to map unknown uid/gid to. 

> * the name for the overflow user is only defined when nfs-utils.rpm is
> installed. In particular in containers people want to minimize the
> number of packages installed, so nfs-utils is likely not to be
> installed.
So if the nfs-utils is not installed... the id/gid will not be created

> * the static nobody:nobody user/group pair was used for various
> services for which weren't "worthy" of creating a dedicated user. This
> is a severely misguided concept, because all processes of the nobody
> user can ptrace and otherwise interact with each other. Separate users
> for each service should be used instead, either normal allocated users
> or systemd's DynamicUser's.
> * other distributions use either nobody:nobody or nobody:nogroup for
> the overflow uid:gid pair, and the different naming in Fedora is
> confusing and can lead to incorrect use.
But the uid/gid are still -2. 

> 
> We propose to:
> * stop using nfsnobody for the overflow uid/gid names
> * stop using nobody for the static user 99 and group 99
> * use the nobody:nobody pair of names for 65534:65534
What are you going to replace it with?? When a server
gives a client a uid/gid that it does know about
the client has to uid/gid to map it to. Somebody has
to own the files.

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

> 
> The new mapping for nobody:nobody would be implemented in two redundant ways:
> * as a static allocation in /etc/passwd and /etc/group managed by setup.rpm
> * dynamically provided by the nss-systemd module (by compiling systemd
> with -Dnobody-user=nobody -Dnobody-group=nobody).
Again... I have to ask why? What problem is this solving.

> 
> 
> 
> == Scope ==
> * Proposal owners:
> - recompile systemd with the right options to get expected answer from
> nss-systemd
> - propose patches for setup.rpm to add the new mapping and do the
> steps listed in Detailed Description on update
> - propose patches for nfs-utils to remove the nfsnobody mapping and do
> the steps listed in Detailed Description on update
> 
> * Other developers:
> watch for regressions
Watch out??? Expect! When start messing around with uid/gid in
the NFS world... your going to break things... most likely
legacy worlds... 

This is a very bad idea... IMHO... 

steved.

> 
> * Release engineering:
> #7258: https://pagure.io/releng/issue/7258
> 
> * List of deliverables:
> N/A
> 
> * Policies and guidelines:
> nothing
> (https://fedoraproject.org/wiki/Packaging:Guidelines#Users_and_Groups
> already says "Note that system services packaged for Fedora MUST NOT
> run as the nobody user" so no changes are required there.)
> 
> * Trademark approval:
> N/A (not needed for this Change)
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[Steve Dickson]

Thanks for all the input... very interesting.

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

Again, thanks for all the input!

steved.

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

Re: rpcgen?

[Steve Dickson]

On 01/09/2018 06:10 AM, Richard W.M. Jones wrote:
> 
> https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval=508864
> says:
> 
>   "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel 
> to their spec files."
> 
> but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen.
Nor will it... There is going to be a new package call rpcsvc-proto 
that will contain the rpcgen command along with other things 
like header files... There is the upstream git tree:
   http://github.com/thkukuk/rpcsvc-proto

Here is the Review Request for the package, if interested. 
   https://bugzilla.redhat.com/show_bug.cgi?id=1532364

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

Package Question

[Steve Dickson]

Hello,

Is it a problem for a package to pull from two different 
upstream tar balls? Basically have 

Source0: http://server.com/package1/package1.tar
Source1: http://server.com/package2/package2.tar

Then I would, by hand, untar Source1 into Source0 directory.

Before do the work I want to make sure I'm not
breaking violating any package rules. I did look
around and didn't see anything addressing this.

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

tia,

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

nfs-utils: does not compile in rawhide

[Steve Dickson]

Just an FYI... 

nfs-utils currently does not compile in rawhide do
to this change: 
   https://bugzilla.redhat.com/show_bug.cgi?id=1531540

We know about and should be resolved by the EOD...

Personally I think this is step in the right direction
but apologize for the inconvenience
 
steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

SONAME Change: nfs-utils-2.3.1

[Steve Dickson]

Hello,

In the latest nfs-utils upstream release the SONAME has 
change on the libnfsidmap.so library.  The API is 
was tidied up so internal functions and variable
are no longer exposed.

As I see it, this change should only effect two patches
nfs-ganesha and sssd-nfs-idmap, unless there are other 
packages that are depended this library that I don't
know of. 

This will only effect rawhide. I'll do the push but
wait to do the build until I talk with owners of 
those packages. 

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 12:33 PM, Adam Williamson wrote:
> On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
>> Then on the other hand I get these pull-requests that
>> work so well! 
>>
>> So I just don't understand why for non-massive changes
>> why is it not required to go through the pull-request
>> process?
> 
> There is a pedestrian reason, which is that the pull request system is
> very *new*. It's only been there a couple of months. So it's not
> surprising that all existing policies haven't been rewritten around it.
Fair enough... It is a very good system. 

> 
> But there are also the practical reasons others have given several
> times but you have just ignored in your multiple replies. Put yourself
> in the shoes of a provenpackager who needs to make corresponding
> changes to, say, 50 packages. All those changes need to go through
> before an important modernization/cleanup to another package can be
> completed, for instance.
> 
> Now you file 50 pull requests. And wait. And wait. And wait...
Guilty as charged... :-) 

This is a massive change... I do get that.. 

> 
> How long will it be before you can get the modernization/cleanup
> finished? You're going to be sitting there waiting for 50 people to
> respond to pull requests, and it's a racing certainty at least one of
> them just *won't*. In the mean time you'll be working on other things,
> and losing track. It just makes it much harder to get important stuff
> done. Fedora is a *distribution*, and a large part of being a
> distribution is some level of consistency in the way we provide
> software to people. It's *important* that we have a mechanism by which
> we can make a reasonable cut at having multiple packages, maintained by
> different people, do things the same way - and have the packages
> changed promptly when those policies change.
> 
> I wouldn't say this is an open-and-shut case, there are reasonable
> arguments in favor of using the PR process for changes, sometimes or
> always. But I agree with other folks that you're not doing yourself any
> favours by acting as if this policy is clearly insane and you're the
> only sane person in the room, and as if there had been some sort of
> major controversy or disaster when there hasn't. 
Sane person?? You are actually calling me a sane person!?? That's a first... ;-)

I just think its odd to have so many people that can changes so
much without any boundaries... I just didn't realize that was the case.

> Someone fixed up some
> dependencies in your package which you should've fixed yourself years
> ago. That's the sum total of what happened. Your git complaints don't
> seem to make sense to anyone else and you've refused to explain exactly
> what this special workflow you have is despite more than one person
> specifically asking you.
This time... but there has been other changes... 

> 
> Important note: I'm a proven packager. I make changes to other packages
> when I judge that it's appropriate to do so, under the policy.
> 
I think making these single changes via the PR system would be
the best policy.

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

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 12:10 PM, Mathieu Bridon wrote:
> On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
>> On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
>>> You're blowing this way out of proportion, as if this was a
>>> catastrophe. History shows that it isn't.
>>
>> Maybe I am... Would not be the first time! ;-)
>>
>> In last couple of months there were a couple of changes
>> that were non-critical so I'm getting the feeling
>> people are getting a bit embolden... which is worrisome.
>>
>> Then on the other hand I get these pull-requests that
>> work so well! 
>>
>> So I just don't understand why for non-massive changes
>> why is it not required to go through the pull-request
>> process?
> 
> This wasn't a trivial change.
> 
> It certainly was trivial for each package it got applied to, but it got
> applied to quite a few packages.
> 
> That's essentially a similar change to mass-rebuilds, just at a smaller
> scale.
> 
> It was also announced properly on this list, enough time in advance, so
> it shouldn't have taken you by surprise.
> 
> If you really want to insist on the maintainers's responsibilities,
> start by reading announcements on this list.
:-) This is a very tough list to keep up with I generally 
look for things on delve-annou...@lists.fedoraproject.org
I must have missed it... 

pull-request go directly to my in box... much easier to find ;-)

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