Re: question on spec file for building rpm with source file that includes python and C code
On 3/9/19 8:35 PM, Globe Trotter wrote: Here is the eror message I am getting (expected since I do not know how to handle separate python code). error: Installed (but unpackaged) file(s) found: /usr/lib/python2.7/site-packages/fetchmailconf.py /usr/lib/python2.7/site-packages/fetchmailconf.pyc /usr/lib/python2.7/site-packages/fetchmailconf.pyo fetchmailconf.py is not new so I wonder why it wasn't packaged before. It appears to be a script for generating a configuration file. I wrote a bunch of suggestions, but deleted them all when I found that Debian packages it as: https://packages.debian.org/jessie/fetchmailconf ___ 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
question on spec file for building rpm with source file that includes python and C code
Hello,
I am a modest Fedora contributor and have packaged both C and python code
separately. I would like to package the fetchmail 7.0.0 alpha6 code so I was
working off the existing spec file. However, I am not sure how to handle the
python files which have been included. I was wondering if I could get some
advice.
I am including my SPEC file:
Summary: A remote mail retrieval and forwarding utility
Name: fetchmail
Version: 7.0.0.alpha6
Release: 1%{?dist}
Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.bz2
# systemd service file
Source2: fetchmail.service
# example configuration file
Source3: fetchmailrc.example
URL: http://www.fetchmail.info/
# For a breakdown of the licensing, see COPYING
License: GPL+ and Public Domain
BuildRequires: gcc gettext-devel hesiod-devel krb5-devel openssl-devel systemd
bison-devel flex-devel m4
BuildRequires: python3-devel
BuildRequires: python3-nose
BuildRequires: python3-six
%description
Fetchmail is a remote mail retrieval and forwarding utility intended
for use over on-demand TCP/IP links, like SLIP or PPP connections.
Fetchmail supports every remote-mail protocol currently in use on the
Internet (POP2, POP3, RPOP, APOP, KPOP, all IMAPs, ESMTP ETRN, IPv6,
and IPSEC) for retrieval. Then Fetchmail forwards the mail through
SMTP so you can read it through your favorite mail client.
Install fetchmail if you need to retrieve mail over SLIP or PPP
connections.
%prep
%setup -q
%build
autoreconf -if
%configure --enable-POP3 --enable-IMAP --with-ssl --with-hesiod \
--enable-ETRN --enable-NTLM --enable-SDPS --enable-RPA \
--enable-nls --with-kerberos5 --with-gssapi \
--enable-fallback=no
make
%install
make install DESTDIR=$RPM_BUILD_ROOT
# install example systemd unit
mkdir -p $RPM_BUILD_ROOT%{_unitdir}
install -p -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_unitdir}/fetchmail.service
# install example config file
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}
install -p -m 600 %{SOURCE3} $RPM_BUILD_ROOT%{_sysconfdir}/fetchmailrc.example
# remove fetchmailconf stuff
rm -f $RPM_BUILD_ROOT%{_bindir}/fetchmailconf*
rm -f $RPM_BUILD_ROOT%{_mandir}/man1/fetchmailconf.1*
%find_lang %name
%files -f %{name}.lang
%doc COPYING NEWS README README.SSL TODO-7.0
%{_bindir}/fetchmail
%{_mandir}/man1/fetchmail.1*
%{_unitdir}/fetchmail.service
%config(noreplace) %attr(0600, mail, mail) %{_sysconfdir}/fetchmailrc.example
%changelog
Here is the eror message I am getting (expected since I do not know how to
handle separate python code).
error: Installed (but unpackaged) file(s) found:
/usr/lib/python2.7/site-packages/fetchmailconf.py
/usr/lib/python2.7/site-packages/fetchmailconf.pyc
/usr/lib/python2.7/site-packages/fetchmailconf.pyo
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/python2.7/site-packages/fetchmailconf.py
/usr/lib/python2.7/site-packages/fetchmailconf.pyc
/usr/lib/python2.7/site-packages/fetchmailconf.pyo
Thanks in advance for any advice!___
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: Guidance for a new contributor
>If you want to learn about ANSI C99, GObject and Gtk+-2.0 I can help >you. Thank you for your interest Joël. I would like that, I'll contact you :) I would still want to give back to things I use every day (Fedora project). Saša Savić https://sasa-savic.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-flake8 package not available in F30
Thank you both for your fast reply! > Why do you need to BuildRequire a linting tool? What are you trying to achieve? I just use python-flake8 as an OCD way of having my build fail if i fail pep8 :) It's just used in conjunction of my unit tests. > Note that the name of a package is python3-flake8 – we are removing python2 from Fedora. I should have clued in that Python 2 support is dropped; my bad. I updated my spec to accommodate the fact Python v2 isn't always available and f30 builds great now. Thank you! On Sat, Mar 9, 2019 at 9:34 AM Miro Hrončok wrote: > On 09. 03. 19 15:26, Chris wrote: > > I have a slightly different packaging issue with the repository > structure > > (similar state on both COPR an Koji). > > > > In epel7, f28, and f29 i can use the line: > > BuildRequires: python-flake8 > > python-flake8 was provided by python2-flake8, python2-flake8 was removed > from > rawhide and f30. > > Why do you need to BuildRequire a linting tool? What are you trying to > achieve? > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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: Guidance for a new contributor
Hi Saša, I am the maintainer of GSequencer and would love to get help with various aspects related to it. We could benefit both if I am able to improve the docs by obtaining feedback. http://nongnu.org/gsequencer/ Thought, it is not fedora infrastructure but rather a generic Linux desktop application. I provide it to fedora: https://bodhi.fedoraproject.org/updates/?packages=gsequencer If you want to learn about ANSI C99, GObject and Gtk+-2.0 I can help you. This would be a good point to start, if you want to learn creating user interfaces using Gtk+ with the C programming language. https://developer.gnome.org/gtk-tutorial/stable/ I live in Switzerland CEST, this UTC+2 but the effective time is UTC+1. Best regards, Joël http://krähemann.com/ On Sat, Mar 9, 2019 at 6:24 PM Sasa Savic wrote: > > Hi all, > > TLDR first, > > I am: > * Potential contributor, searching for guidance > * Good with Python, C# (probably nobody cares) and JS, basics of C/C++ > * Experienced with everything above sys engineering (cli/gui, f/s webdev, ...) > > Want to: > * help first (port to py3, fix bug or two, help infra apps, ...) > * learn (improve my c/cpp, work more in devops) > > So, as you can see I really want to hop in and help in Fedora development. > I dumped my side project which means I'll have probably ~10 weekly to work. > Since I am not that creative and don't use a lot of tools, I don't have > much to maintain for myself so I am willing to help towards goals for Fedora. > > I'm most comfortable writing Python for any purpose. IMO that would be the > best use of me (porting, tooling and/or web dev). On the other hand, I would > really want to improve my C and I am willing to work hard on that. Also, I > worked on developing tooling and could help infrastructure team. > > TBH I don't want to waste your time, but I more than willing to help > if someone is willing to guide me (mentor?). I'm in UTC+1. > > PS. I love your work, keep it up. I converted a lot of my colleagues because > of Fedora. > > Regards, > Saša Savić > ___ > 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
Guidance for a new contributor
Hi all, TLDR first, I am: * Potential contributor, searching for guidance * Good with Python, C# (probably nobody cares) and JS, basics of C/C++ * Experienced with everything above sys engineering (cli/gui, f/s webdev, ...) Want to: * help first (port to py3, fix bug or two, help infra apps, ...) * learn (improve my c/cpp, work more in devops) So, as you can see I really want to hop in and help in Fedora development. I dumped my side project which means I'll have probably ~10 weekly to work. Since I am not that creative and don't use a lot of tools, I don't have much to maintain for myself so I am willing to help towards goals for Fedora. I'm most comfortable writing Python for any purpose. IMO that would be the best use of me (porting, tooling and/or web dev). On the other hand, I would really want to improve my C and I am willing to work hard on that. Also, I worked on developing tooling and could help infrastructure team. TBH I don't want to waste your time, but I more than willing to help if someone is willing to guide me (mentor?). I'm in UTC+1. PS. I love your work, keep it up. I converted a lot of my colleagues because of Fedora. Regards, Saša Savić ___ 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: packages provides Re: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)
On Sat, 2019-03-09 at 08:14 +0100, Dridi Boukelmoune wrote:
> On Fri, Mar 8, 2019 at 8:20 PM Sérgio Basto
> wrote:
> >
> > Hello,
> >
> > :P I just found a weird bug :
> >
> > dnf repoquery --available --whatrequires python2-mlt
> > flowblade-0:1.16.0-2.gitd2f153f.fc28.noarch
> > flowblade-0:2.0-1.fc28.noarch
> >
> > dnf repoquery --disablerepo='*' --enablerepo=rawhide --
> > enablerepo=rpmfusion-{,non}free-rawhide --available --requires
> > flowblade
> > (...)
> > mlt-python
> > (...)
> >
> > dnf repoquery --disablerepo='*' --enablerepo=rawhide --
> > enablerepo=rpmfusion-{,non}free-rawhide --available --
> > whatrequires python2-mlt
> >
> > None !!! ???
>
> I do get flowblade, the only difference is that I don't use the
> rpmfusion nonfree repository.
>
> $ dnf repoquery --disablerepo=* --enablerepo=rawhide
> --enablerepo=rpmfusion-free-rawhide --available --whatrequires
> python2-mlt
> Last metadata expiration check: 0:02:03 ago on Sat 09 Mar 2019
> 08:12:08 AM CET.
> flowblade-0:2.0-2.fc30.noarch
Today, I also get flowable in the result.
The main goal of this logic was propose:
If package "b" requires package a-python or pya , and when package "a"
have the sub-package python2-a and provides a-python or pya , remove
provides of package "a" and force package "b" to requires python2-a
instead a-python or pya ...
Now this request seems less important since dnf works correctly ( when
the packages are in repo ) .
I think the problem was when rawhide had mlt-6.12.0-5 it fails to find
dep because mlt-6.12.0-5 didn't have python2-mlt, now with mlt-6.12.0-7
it works (because mlt have python2-mlt sub-package)
Thanks
> Dridi
> ___
> 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
--
Sérgio M. B.
___
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: Uninstallable aqsis-core in fedora 30
On 09. 03. 19 16:30, J. Scheurich wrote: Hi, It looks like "aqsis-core" is not installable in fedora 30 (x86_64) # dnf install aqsis-core Last metadata expiration check: 0:03:47 ago on Sat 09 Mar 2019 04:19:02 PM CET. Error: Problem: conflicting requests - nothing provides libboost_system.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_thread.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_filesystem.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_regex.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_iostreams.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_wave.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 (try to add '--skip-broken' to skip uninstallable packages) I need aqsis-core (a renderer for .RIB files) as requirement for white_dune. Who to ask ? Here: https://bugzilla.redhat.com/show_bug.cgi?id=1674655 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Uninstallable aqsis-core in fedora 30
Hi, It looks like "aqsis-core" is not installable in fedora 30 (x86_64) # dnf install aqsis-core Last metadata expiration check: 0:03:47 ago on Sat 09 Mar 2019 04:19:02 PM CET. Error: Problem: conflicting requests - nothing provides libboost_system.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_thread.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_filesystem.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_regex.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_iostreams.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 - nothing provides libboost_wave.so.1.66.0()(64bit) needed by aqsis-core-1.8.2-31.fc29.x86_64 (try to add '--skip-broken' to skip uninstallable packages) I need aqsis-core (a renderer for .RIB files) as requirement for white_dune. Who to ask ? so long MUFTI ___ 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: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On Sat, Mar 9, 2019 at 7:11 AM Vít Ondruch wrote: > > > Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > > Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): > >>> "MH" == Miro Hrončok writes: > >> MH> On 08. 03. 19 21:16, Neal Gompa wrote: > I really wish we'd allow Epochs to be reset on distribution upgrades. > With dnf distro-sync (which is used by system-upgrade) Epochs don't > really matter and upgrades work as intended anyway... > >> MH> Let's do a Fedora change? Coordinate with FPC? > >> > >> We (FPC) have talked about this before but I don't think it's really up > >> to FPC. The change process isn't really the right way to do it, either, > >> since this is really a policy revision. I just think FESCo needs to > >> decide whether or not it would like to relax the policy, and if so, how. > >> > >> Here are the relevant points as I see them (unless I'm forgetting > >> something): > >> > >> * dnf system-upgrade generally handles versions going backward without > >> issue. The specific case of epoch being reset is not an issue. > >> > >> * dnf upgrade would not handle this, causing problems for those running > >> rawhide or using unsupported methods of upgrading between releases. > >> > >> * Those running rawhide would have to run distro-sync in order to > >> upgrade (which would of course reset any locally built updated > >> packages and such). They would have to do this every time any > >> installed package drops epoch. > >> > >> * Those using an unsupported method of upgrading would need to > >> incorporate distro-sync. > >> > >> * Dropping epoch outside of rawhide would generally be bad. > >> > >> * Koji and the compose process do handle things "going backwards", as > >> this has happened multiple times in the past without things dying. > >> What's important there is which version was most recently tagged. > >> > >> * Bodhi shouldn't be involved here as this would be restricted to > >> rawhide. > >> > >> Personally I'm in support of relaxing the restriction in some form, but > >> I prefer a single "drop Epoch: day" where epochs in rawhide are > >> _automatically_ removed and the packages rebuilt. This gives a single > >> point in time where rawhide users need to do a distro-sync in order to > >> properly track updates. Allowing epochs to be dropped without > >> coordination seems to me to be a burden on rawhide users, but I don't > >> think a single flag day would be problematic. > >> > >> I would expect the first flag day to be busy. I see 756 Epoch: tags > >> currently, though 161 are set to 0 for whatever reason. Afterwards I > >> would expect no more than a small number of packages per cycle to > >> acquire Epoch: tags. > >> > >> - J< > > > > If DNF were helpful and was able to report packages, which has higher > > NVR then E(NVR), > > > I meant (E)NVR actually. > > > V. > > > > then I can imagine that reset of epoch could work. > > Otherwise I am against resetting epochs. > > I'm confused, why would that matter? And DNF always reports NEVRA... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-flake8 package not available in F30
On Sat, Mar 09, 2019 at 09:26:49AM -0500, Chris wrote: > I have a slightly different packaging issue with the repository structure > (similar state on both COPR an Koji). > > In epel7, f28, and f29 i can use the line: > BuildRequires: python-flake8 > > However this package is not available on f30 servers: > Koji ref: https://koji.fedoraproject.org/koji/taskinfo?taskID=33329251 This is available both in F30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1217218 and in Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1217211 Note that the name of a package is python3-flake8 – we are removing python2 from Fedora. > I realize f30 is in rawhide state right now, so i wasn't sure if this is > the right forum for this question or if i should just wait? Rawhide is f31 at the moment. F30 is in beta freeze. -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray ___ 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: python-flake8 package not available in F30
On 09. 03. 19 15:26, Chris wrote: I have a slightly different packaging issue with the repository structure (similar state on both COPR an Koji). In epel7, f28, and f29 i can use the line: BuildRequires: python-flake8 python-flake8 was provided by python2-flake8, python2-flake8 was removed from rawhide and f30. Why do you need to BuildRequire a linting tool? What are you trying to achieve? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
python-flake8 package not available in F30
I have a slightly different packaging issue with the repository structure (similar state on both COPR an Koji). In epel7, f28, and f29 i can use the line: BuildRequires: python-flake8 However this package is not available on f30 servers: Koji ref: https://koji.fedoraproject.org/koji/taskinfo?taskID=33329251 I realize f30 is in rawhide state right now, so i wasn't sure if this is the right forum for this question or if i should just wait? Chris ___ 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: Koji Build Failure Due To Dependency EPEL Dependency Issue
Thanks a lot Kevin! I can confirm it built perfectly! (ref https://koji.fedoraproject.org/koji/taskinfo?taskID=33328352) I truly appreciate your help! Chris On Sat, Mar 9, 2019 at 1:16 AM Kevin Fenzi wrote: > On 3/8/19 6:01 PM, Chris wrote: > > Hi guys, > > > > I apologize if this is a bit premature to revisit this subject. The > thing > > is, the releng ticket Stephen created ( > https://pagure.io/releng/issue/8185) > > based on my Bugzilla ticket ( > > https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed and > marked > > resolved, but the build process still continues to fail. > > > > Recent Koji Build Fail Source: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33310604 > > > > I sat on this for a week thinking maybe it just took time for this change > > to propagate, but now that this was week #2 and it was still failing... i > > should bother you all again :). > > > > Is this a RedHat issue? Perhaps just waiting for the Bugzilla issue to > > close will actually rectify my issue? i realize this can take months; > but > > it's a perfectly acceptable answer. I guess i'm just looking for closure > > at this point. I'd love to share my app with the rest of the fedora > > community. > > > > Thanks in advance! > > Sorry this has been a pain. ;( > > Anyhow, it did get blocked but there was still a version of the package > tagged into epel7 so that was messing things up. I untagged that one and > (I hope you don't mind) resubmitted your scratch build... and now it > completes. :) > > So, you should be all good now I hope. > > kevin > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora rawhide compose report: 20190306.n.1 changes
On Fri, 8 Mar 2019 at 17:37, Kevin Fenzi wrote: [..] > >> There's no glitch I am aware of, so more information would be helpful. > > > > This seems quite OK: > > > > https://admin.fedoraproject.org/mirrormanager/propgation > > > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 > > Well, perhaps you looked at it too soon? > > Right now it's slowly showing mirrors catching up over the last 12 hours > or so. More than 24h later and I'm still not able to find even one European mirror with synced source packages :/ Checked few in US and Canada and situation is the same. Almost half of those mirrors which I've checked are stuck in the same day in the middle of August 2018. Another ~30% are stuck on 17 Feb. It is really hard to believe that on all those out of sync mirrors admins stopped syncing rawhide in one of the two possible days simultaneously. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
Dne 09. 03. 19 v 13:00 Vít Ondruch napsal(a): > Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): >>> "MH" == Miro Hrončok writes: >> MH> On 08. 03. 19 21:16, Neal Gompa wrote: I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... >> MH> Let's do a Fedora change? Coordinate with FPC? >> >> We (FPC) have talked about this before but I don't think it's really up >> to FPC. The change process isn't really the right way to do it, either, >> since this is really a policy revision. I just think FESCo needs to >> decide whether or not it would like to relax the policy, and if so, how. >> >> Here are the relevant points as I see them (unless I'm forgetting >> something): >> >> * dnf system-upgrade generally handles versions going backward without >> issue. The specific case of epoch being reset is not an issue. >> >> * dnf upgrade would not handle this, causing problems for those running >> rawhide or using unsupported methods of upgrading between releases. >> >> * Those running rawhide would have to run distro-sync in order to >> upgrade (which would of course reset any locally built updated >> packages and such). They would have to do this every time any >> installed package drops epoch. >> >> * Those using an unsupported method of upgrading would need to >> incorporate distro-sync. >> >> * Dropping epoch outside of rawhide would generally be bad. >> >> * Koji and the compose process do handle things "going backwards", as >> this has happened multiple times in the past without things dying. >> What's important there is which version was most recently tagged. >> >> * Bodhi shouldn't be involved here as this would be restricted to >> rawhide. >> >> Personally I'm in support of relaxing the restriction in some form, but >> I prefer a single "drop Epoch: day" where epochs in rawhide are >> _automatically_ removed and the packages rebuilt. This gives a single >> point in time where rawhide users need to do a distro-sync in order to >> properly track updates. Allowing epochs to be dropped without >> coordination seems to me to be a burden on rawhide users, but I don't >> think a single flag day would be problematic. >> >> I would expect the first flag day to be busy. I see 756 Epoch: tags >> currently, though 161 are set to 0 for whatever reason. Afterwards I >> would expect no more than a small number of packages per cycle to >> acquire Epoch: tags. >> >> - J< > > If DNF were helpful and was able to report packages, which has higher > NVR then E(NVR), I meant (E)NVR actually. V. > then I can imagine that reset of epoch could work. > Otherwise I am against resetting epochs. > > > Vít > ___ > 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: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
Dne 08. 03. 19 v 23:19 Jason L Tibbitts III napsal(a): >> "MH" == Miro Hrončok writes: > MH> On 08. 03. 19 21:16, Neal Gompa wrote: >>> I really wish we'd allow Epochs to be reset on distribution upgrades. >>> With dnf distro-sync (which is used by system-upgrade) Epochs don't >>> really matter and upgrades work as intended anyway... > MH> Let's do a Fedora change? Coordinate with FPC? > > We (FPC) have talked about this before but I don't think it's really up > to FPC. The change process isn't really the right way to do it, either, > since this is really a policy revision. I just think FESCo needs to > decide whether or not it would like to relax the policy, and if so, how. > > Here are the relevant points as I see them (unless I'm forgetting > something): > > * dnf system-upgrade generally handles versions going backward without > issue. The specific case of epoch being reset is not an issue. > > * dnf upgrade would not handle this, causing problems for those running > rawhide or using unsupported methods of upgrading between releases. > > * Those running rawhide would have to run distro-sync in order to > upgrade (which would of course reset any locally built updated > packages and such). They would have to do this every time any > installed package drops epoch. > > * Those using an unsupported method of upgrading would need to > incorporate distro-sync. > > * Dropping epoch outside of rawhide would generally be bad. > > * Koji and the compose process do handle things "going backwards", as > this has happened multiple times in the past without things dying. > What's important there is which version was most recently tagged. > > * Bodhi shouldn't be involved here as this would be restricted to > rawhide. > > Personally I'm in support of relaxing the restriction in some form, but > I prefer a single "drop Epoch: day" where epochs in rawhide are > _automatically_ removed and the packages rebuilt. This gives a single > point in time where rawhide users need to do a distro-sync in order to > properly track updates. Allowing epochs to be dropped without > coordination seems to me to be a burden on rawhide users, but I don't > think a single flag day would be problematic. > > I would expect the first flag day to be busy. I see 756 Epoch: tags > currently, though 161 are set to 0 for whatever reason. Afterwards I > would expect no more than a small number of packages per cycle to > acquire Epoch: tags. > > - J< If DNF were helpful and was able to report packages, which has higher NVR then E(NVR), then I can imagine that reset of epoch could work. Otherwise I am against resetting epochs. Vít ___ 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: What pulls in weak dependencies?
Dne 09. 03. 19 v 4:03 Mamoru TASAKA napsal(a): > Vít Ondruch wrote on 2019/03/09 8:03: >> Hi, >> >> Running `dnf update`, it tries to install: >> >> Installing weak dependencies: >> mkpasswd x86_64 5.4.1-3.fc31 >> rawhide 39 k >> >> >> >> Trying to query for weak dependencies, nothing requires it: >> >> $ sudo dnf repoquery --whatrecommends mkpasswd >> Last metadata expiration check: 0:07:13 ago on Fri Mar 8 23:51:51 2019. >> >> $ sudo dnf repoquery --supplements mkpasswd >> Last metadata expiration check: 0:07:53 ago on Fri Mar 8 23:51:51 2019. >> >> >> So I wonder how I am supposed to know, why DNF is trying to install such >> packages. >> >> > > > $ dnf repoquery --disablerepo=\* --enablerepo=koji-31 --provides > mkpasswd 2>/dev/null | while read f ; do echo -n -e "$f\t" ; dnf > repoquery --disablerepo=\* --enablerepo=koji-31 --whatrecommends "$f" > 2>/dev/null ; echo ; done > mkpasswd = 5.4.1-3.fc31 > mkpasswd(x86-64) = 5.4.1-3.fc31 > whois-mkpasswd = 5.4.1-3.fc31 libxcrypt-0:4.4.4-1.fc31.x86_64 > > So libxcrypt-0:4.4.4-1.fc31.x86_64 Recommends whois-mkpasswd , which > is provided by mkpasswd . > Thank you. That is actually awful command. I complained in this ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1549851#c10 and on top of that created new ticket requesting providing full information about the packages, which anyhow depend on specific package: https://bugzilla.redhat.com/show_bug.cgi?id=1687070 Vít > Regards, > Mamoru > > > ___ > 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: Fedora rawhide compose report: 20190306.n.1 changes
On 09. 03. 19 7:19, Kevin Fenzi wrote: I also wonder if no new composes even starting is a deliberate choice or some kind of error: https://kojipkgs.fedoraproject.org/compose/rawhide/ The rawhide compose is in a cron job, set to fire at 5:15UTC. However, if there's already one running it will just exit and not launch a new one. Yesterday at that time the completed one wasn't finished, so the cron didn't start a new one. The rawhide compose job at the end cleans up old composes older than 2 weeks, and last nights was the first one to finish in a long time, so it had a lot of old composes to clean up. We should probably move that cleanup to a separate job, but we haven't yet. Thanks. I see Fedora-Rawhide-20190309.n.0 as STARTED now. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
