On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:
> GnuTLS uses Nettle, but does not provide access to DES. You can use
> Nettle directly:
>
> https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
>
> OpenSSL will work as well, but as Nettle is a preexisting dependency,
> it's proba
On Fri, 9 Mar 2018 16:14:39 +0100, Florian Weimer wrote:
> On 01/29/2018 03:38 PM, Michael Schwendt wrote:
> > The reason why I ask is that Claws Mail still uses encrypt() with the sole
> > purpose of being able to decrypt old passwords. It doesn't convert them to
>
On Mon, 29 Jan 2018 15:38:00 +0100, Michael Schwendt wrote:
> On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
>
> > = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
On Sat, 03 Mar 2018 19:42:48 +0100, Kevin Kofler wrote:
> PS:
>
> I wrote:
>
> > Richard Hughes wrote:
> >> 64x64 is a very low bar indeed, compared to all of the other
> >> platforms, e.g. Windows Store or the Apple AppStore.
> >
> > All that's going to happen with such a requirement is th
On Fri, 02 Mar 2018 16:11:23 +0100, Kevin Kofler wrote:
> Richard Hughes wrote:
> > 64x64 is a very low bar indeed, compared to all of the other
> > platforms, e.g. Windows Store or the Apple AppStore.
>
> All that's going to happen with such a requirement is that specfiles are
> going to run
On Thu, 8 Feb 2018 18:39:19 +0100, Petr Stodulka wrote:
> > The following:
> > %files
> > /some/directory/
> >
> > is equivalent to:
> > %files
> > %dir /some/directory
> > /some/directory/*
> >
> >
> > There's nothing wrong here.
> >
> >
>
> Exactly. IMHO, use of %dir macro for "top" pkg
On Thu, 8 Feb 2018 18:09:25 +, Tomasz Kłoczko wrote:
> I'm sure that in the past it was difference here :|
You are mistaken about that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
On Mon, 5 Feb 2018 07:42:45 -0500, Josh Boyer wrote:
> >> rpms/gqview
> >
> > Really?!
>
> Congratulations, you have just explained why absentee maintainers are
> bad and why we orphan things.
No. I've only shown how surprised I am to discover that it is an orphan
in the Fedora package colle
On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:
> rpms/gqview
Really?!
It is unmaintained for over 10 years.
It has been forked into Geeqie (package "geeqie") roughly 10 years
ago, and Geeqie at least has seen several releases since then.
___
de
On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
> = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
>
> Change owner(s):
> * Björn Esser
> * Florian Weimer
>
> There are plans to remove libcrypt fr
On Fri, 26 Jan 2018 14:52:24 +0100, Remi Collet wrote:
> DEBUG util.py:439: Error: Transaction check error:
> DEBUG util.py:439:file /usr/share/info/dir conflicts between
> attempted installs of annobin-3.2-1.fc28.x86_64 and info-6.5-1.fc28.x86_64
>
> Seems related to
> https://src.fedorapro
On Thu, 25 Jan 2018 15:24:38 +0100, Adrian Reber wrote:
> /usr/include/qt5/QtGui/qstatictext.h:70:18: note: no known conversion for
> argument 1 from 'QString' to 'const QStaticText&'
>
> Which does not seem to be libcdio related. Is this a know error
> in audacious-plugins?
It is due to Qt 5
Are recent GCC changes we need to be aware of?
i686 build ends due to various internal compiler errors.
The same code has built fine before a few months ago.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1020693
https://kojipkgs.fedoraproject.org//work/tasks/8584/24438584/build.log
__
Maybe create a solution based on "koji download-build --help"?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On Fri, 19 Jan 2018 22:53:30 -0500, Dusty Mabe wrote:
> On 01/19/2018 10:39 PM, Reindl Harald wrote:
> Thanks!
> I didn't know about this, but it's not exactly what I'm looking for because
> that seems
> to includ everything that has been built. I'm looking more specifically for
> just a repo
On Fri, 19 Jan 2018 15:32:13 +, Tomasz Kłoczko wrote:
> > dnf install wine.i686
>
> wine is completely brain damaged example.
Maybe. Something on x86_64 is broken nevertheless.
If memory serves correctly, Yum could handle it, but dnf seems to run into
non-arch-specific explicit dependenc
On Thu, 18 Jan 2018 20:07:27 -0600, Rex Dieter wrote:
> I can
> dnf install .i686
>
> and I see no 64bit packages pulled in.
With F27,
dnf install wine.i686
really pulls in various x86_64 alongside their i686 builds.
___
devel mailing list -- deve
On Tue, 16 Jan 2018 18:13:40 +0100, Daniel Veillard wrote:
> > https://src.fedoraproject.org/rpms/libxml2/pull-requests
>
> Page not found (404)
It loads fine here and shows five pull requests.
A temporary 404 would be a Fedora infrastructure problem to
report somewhere.
_
On Fri, 12 Jan 2018 16:13:24 +0100, Pierre-Yves Chibon wrote:
> I believe the script runs at least daily so if you see something wrong then do
> report it :)
Here's a recently opened ticket about package "aide":
Date: Fri, 12 Jan 2018 11:17:42 +
https://bugzilla.redhat.com/show_bug.cgi?i
On Mon, 1 Jan 2018 18:24:38 +0100, Pierre-Yves Chibon wrote:
> > That's due to data migration bugs from pkgdb -> pagure over dist-git
> > -> bugzilla. If you're not listed as contributor on src.fedoraproject.org
> > for this package, eventually that will be synced to bugzilla.
> > I also still
On Wed, 27 Dec 2017 10:37:33 -0700, Jerry James wrote:
> On Wed, Dec 27, 2017 at 5:16 AM, bugzilla redhat com wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1529276
> >
> > Bug ID: 1529276
> >Summary: findbugs-contrib-7.2.0.sb is available
> >Product:
On Mon, 4 Dec 2017 15:17:32 +0100, David Kaspar [Dee'Kej] wrote:
> What happened in the case that lead me to write my initial e-mail was this:
> 1) Proven packager received a BZ report for his own package.
> 2) Proven packager discovered the issue was actually caused by package I
> maintain/own.
>
On Tue, 14 Nov 2017 08:27:28 +0100, Milan Crha wrote:
> Hi,
> the sum of changes is part of the release notes, which can be found
> here:
> https://github.com/libical/libical/releases
Would be great, if such a document were included within the package.
> > vcal_manager.c: In function 'vcal
On Mon, 13 Nov 2017 15:04:55 +0100, Milan Crha wrote:
> > The upgrade seems to be API incompatible, so more than rebuilding
> > dependencies is necessary.
>
> Hi,
> that's true. libical upstream removed some deprecated symbols, most
> notably icaltimetype::is_utc.
Dunno yet what's the re
On Wed, 01 Nov 2017 12:26:12 +0100, Milan Crha wrote:
> Hello,
> I'd like to give a heads up about a plan to update libical to its 3.0.0
> release in rawhide once I figure out some details about its build. This
> release also obsoletes libical-glib package, the project had been added
> into
On Thu, 26 Oct 2017 18:16:00 -0400, Stephen John Smoogen wrote:
> We have been getting bounced emails from Axel Thimm for a while and I
> don't have any other way to contact him. He was an early maintainer of
> packages but has not been seen in fas since 2013.
> If anyone has had contact with him
On Sun, 15 Oct 2017 18:09:12 +0200, Till Hofmann wrote:
> Hi all,
>
> if I want to downgrade a package in rawhide only (I only pushed the
> update to rawhide), do I need to add an Epoch?
>
> background:
> I updated librealsense to librealsense2 and afterwards realized that the
> new library is a
On Tue, 10 Oct 2017 13:29:19 +0200, Jiri Vanek wrote:
> Hello all!
>
> I seek advice how to proceed with following situation.
>
> There is new package for f27 - java-9-openjdk.
> The issue is, RPM do not like change of directory to symlink which is exactly
> what happened, and
> dies with cpi
On Sun, 8 Oct 2017 18:34:09 +0200, Pierre-Yves Chibon wrote:
> > I've not been a maintainer of the package since Fedora 13.
> >
> > I'm not listed as a maintainer in pkgdb, although there are three
> > "Obsolete" entries that have been inherited for many years it seems.
>
> You are marked as a
On Sun, 8 Oct 2017 11:58:56 + (UTC), buildsys fedoraproject org wrote:
> audacity has broken dependencies in the rawhide tree:
> On x86_64:
> audacity-2.1.3-6.fc28.x86_64 requires libwx_baseu-3.0-gtk2.so.0()(64bit)
-snip-
Why do I get such an email?
I've not been a maintainer of the pa
On Tue, 3 Oct 2017 10:40:46 -0500, Greg Hellings wrote:
> So I have a new package that's gotten through review. Previously requesting
> git access was handled by pkgdb.
>
> Where is that functionality now? Is it still there? Is there a new way to
> do it under Pagure?
It's a bit of a maze:
https
Nothing depends on pth anymore.
Nothing BuildRequires pth-devel anymore.
gnupg2 has changed to using npth.
Also, there has been a strange pull request with the title
``Add CI tests using the standard test interface''
that requires extra packager commitment without touching the package:
https://src
On Sun, 01 Oct 2017 13:54:05 +0100, Sérgio Basto wrote:
> btw Io-language and ardour2 buildrequires soundtouch-devel but not use
> it ...
Indeed. It only uses the soundtouch library as a fallback, if fftw is not
available as needed for an internal rubberband lib. For the sake of making
the build
On Sat, 2 Sep 2017 20:25:25 +0200, Michael Schwendt wrote:
> Anything depending on Audacious libaudcore will need a rebuild due to a
> SONAME change from libaudcore.so.4 to libaudcore.so.5 that has been
> introduced with the upgrade to Audacious 3.9 in Rawhide.
Same for F27 where t
On Mon, 18 Sep 2017 12:36:11 +0200, Vít Ondruch wrote:
> I'd say you should try to downgrade to fprintd-0.7.0-4.fc27 as a
> workaround and wait for fixed selinux-policy ...
Right. The fprintd test update has been published before the strictly
needed selinux-policy update. Meanwhile, the latter is
Anything depending on Audacious libaudcore will need a rebuild due to a
SONAME change from libaudcore.so.4 to libaudcore.so.5 that has been
introduced with the upgrade to Audacious 3.9 in Rawhide.
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote:
> > It's been several hours since this entirely new package repo has been
> > created,
> > but the koji build still fails. How long does it take for koji to learn
> > about this new package?
> it takes as long someone from releng
It's been several hours since this entirely new package repo has been created,
but the koji build still fails. How long does it take for koji to learn
about this new package?
$ fedpkg build
Building ampache_browser-1.0.0-1.fc28 for rawhide
Created task: 21592583
Task info: https://koji.fedoraproje
On Mon, 21 Aug 2017 10:07:48 +0200, Petr Stodulka wrote:
> > *ouch* Covering such a corner-case is of limited use, IMO.
> > What other package tools would benefit from such a protection?
> >
>
> It's corner case, but user is user. We could say same thing about udev,
> systemd, dnf...
> Why t
On Fri, 18 Aug 2017 11:55:33 -0400, Matthew Miller wrote:
> On Fri, Aug 18, 2017 at 11:45:40AM -0400, Irina Boverman wrote:
> > I have a package in F25/F25 stable distributions that will not install
> > because the dependency is no longer there (new version of libwebsockets was
> > promoted to sta
On Fri, 18 Aug 2017 17:03:57 +0200, Petr Stodulka wrote:
> >> # dnf remove setup
> rpm is low level tool. No, I am talking just about use of dnf which is high
> level tool for working
> with packages/modules.
*ouch* Covering such a corner-case is of limited use, IMO.
What other package tool
On Fri, 18 Aug 2017 15:20:55 +0200, Petr Stodulka wrote:
> >>> $ rpm -q --whatrequires setup
> >>> rpcbind-0.2.4-7.rc2.fc26.x86_64
> >>> shadow-utils-4.3.1-3.fc26.x86_64
> >>>
>
> # dnf remove setup
>
> I am not talking about update, I am talking about situation that you can
> break c
On Fri, 18 Aug 2017 08:10:16 -0400, Neal Gompa wrote:
> On Fri, Aug 18, 2017 at 7:55 AM, Michael Schwendt wrote:
> > On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
> >
> >> Hi folks,
> >>
> >> I found now that the setup rpm is removable from t
On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
> Hi folks,
>
> I found now that the setup rpm is removable from the system,
Clarify, please. What exactly have you found out? Have you found an update
case where one of the package updater tools removed it actually?
$ rpm -q --whatrequ
On Thu, 17 Aug 2017 15:54:25 -0700, Luya Tshimbalanga wrote:
> Following the request from Design team, I struggle to package Knotter
> for review due to failure related to Qt5.
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21287726
>
> As I am not familiar with Qt5. Can someone help to
On Tue, 15 Aug 2017 22:13:00 +0200, Jos de Kloe wrote:
> Hi,
>
> I just build a new version of g2clib (upgraded from 1.4.0 to 1.6.0), and
> with this change this static library for grib file handling changes name:
> old: libgrib2c.a
> new: libg2c_v1.6.0.a
>
> I dont know of a packaging guideline
On Sat, 12 Aug 2017 10:45:29 +0800, Chenxiong Qi wrote:
> [root@e151b05870c7 pkgs]# dnf repoquery koji
> Last metadata expiration check: 0:01:39 ago on Sat Aug 12 02:25:14 2017.
> koji-0:1.10.1-13.fc25.noarch
> koji-0:1.13.0-2.fc25.noarch
>
> and koji-1.13 is listed by resolving the dependencies
On Fri, 21 Jul 2017 18:06:58 -0500, Jason L Tibbitts III wrote:
> MS> The ticket blocks FE-NEEDSPONSOR. No idea why you've approved the
> MS> review officially, setting the fedora-review+ flag without being
> MS> able to sponsor the new contributor.
>
> Because that is perfectly acceptable. It
On Thu, 20 Jul 2017 09:36:10 -0400 (EDT), John Ellson wrote:
> Specific examples please?
Non-versioned Obsoletes as one example. Arch-independent explicit Requires
as another example.
When is the last time you've run the fedora-review tool on this src.rpm?
___
On Wed, 19 Jul 2017 14:40:41 +0100, Richard W.M. Jones wrote:
> > > these packages (https://copr.fedorainfracloud.org/coprs/jonludlam/opam/)
> > > about a year ago and never heard back, so... technically I guess I
> > > could proceed with the non-responsive maintainer policy. But is that
> > > the
On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote:
> Jaroslav Škarvada requested that i move the discussion from:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1410366
>
> about unifying the graphviz .spec file with upstream, to this list.
>
>
> Perhaps the unification object
On Thu, 6 Jul 2017 14:33:21 +0200, Jos de Kloe wrote:
> Anyway, one thing still puzzles me.
> You put the proj-nad and proj-epsg requires in both sub-packages now,
> and clearly this works well.
> However, the BuildRequires on proj-nad and proj-epsg are still in the
> generic section, so does this
On Wed, 28 Jun 2017 13:21:43 +0530, Parag Nemade wrote:
> On Wed, Jun 28, 2017 at 12:29 PM, Michal Novotny wrote:
>
> > Can you, please, show the emails or just one of them?
> >
> >
>
> https://lists.fedoraproject.org/archives/search?mlist=scm-commits%40lists.fedoraproject.org&q=audacious-plug
Whoever set up that service, seriously?
Why would I receive 610 emails for activity in "epel7"? For packages with
a longer git history, it will likely be thousands of emails.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
On Mon, 12 Jun 2017 22:38:11 + (UTC), till fedoraproject org wrote:
> eflspot, dchen, sereinit 114 weeks ago
> audacious-plugins (maintained by: mschwendt, atkac, danfruehauf)
> audacious-plugins-jack-3.8.2-2.fc26.i686 requires libjack
On Thu, 01 Jun 2017 02:29:53 +, Christopher wrote:
> Do you have a link to an explanation of the automated fedora-review
> process, and/or some of these step-by-step checklists you mention?
fedora-review is a tool and a package with the same name. You simply point
it at a bugzilla ticket numb
On Wed, 5 Apr 2017 14:18:02 +0200, Vít Ondruch wrote:
> Just to make sure, I'll quote myself from my initial response:
>
> Dne 4.4.2017 v 08:05 Vít Ondruch napsal(a):
> > Please do these changes just in Rawhide.
And you think in Rawhide you are free to violate upgrade paths?
Breaking dependenc
On Wed, 5 Apr 2017 13:11:56 +0200, Vít Ondruch wrote:
> Is this some special process for js-jquery?
No.
> It is quite common that package bumps its version or soname and breaks
> something. We either fix the incompatibility or provide "compat" package.
>
> You can take recent update of openssl
On Wed, 5 Apr 2017 10:37:30 +0200, Vít Ondruch wrote:
> > https://fedoraproject.org/wiki/Package_Renaming_Process
> >
> > https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
> >
> > because you want the new js-jquery2 package to replace the previous
> >
On Tue, 4 Apr 2017 11:48:44 +0200, Vít Ondruch wrote:
> It is not rename jquery is updated and introduced new jquery2
> package. There is nothing to obsolete anywhere
*sigh*
It is exactly this,
https://fedoraproject.org/wiki/Package_Renaming_Process
https://fedoraproject.org/wiki
On Tue, 4 Apr 2017 14:48:53 +0200, Tarjei Knapstad wrote:
> I would like to revive a stalled Package Review request created by
> someone else, but I am unsure how to proceed. I've commented on the
> request and added an updated SPEC and SRPM, but I'm not sure how to
> proceed from here. Should I c
On Tue, 4 Apr 2017 08:05:13 +0200, Vít Ondruch wrote:
> Please do not obsolete anything. For rubygem-jquery-rails, I'd like to
> use jQuery 1.x, 2.x as well as 3.x
It would only be a rename. It would not stop you from adding explicit
Requires to pull in all three js-jquery packages.
_
On Mon, 03 Apr 2017 19:35:24 +, Christopher wrote:
> There seem to be a lot of possible guidance on the Wiki for what I'm trying
> to do, but no clear, unambiguous step-by-step path to follow. So, I'm
> seeking advice here.
>
> js-jquery provides jquery 2.x and js-jquery 2.x
> js-jquery1 prov
On Mon, 03 Apr 2017 11:30:38 +0200, Igor Gnatenko wrote:
> That wasn't call to change anything,
I know.
> I don't want to change anything,
I know.
> RPM behavior is not interesting because it is just evaluating constraints,
> nothing else. Interesting thing is depsolving - libsolv.
Maybe, but
On Sat, 01 Apr 2017 19:54:28 +0200, Igor Gnatenko wrote:
> repo system 0 testtags
> #>=Pkg: foo-static 1 1 x86_64
> repo available 0 testtags
> #>=Pkg: bar 1 1 x86_64
> #>=Obs: foo-static
> #>=Pkg: foo-static 2 1 x86_64
> system x86_64 rpm system
> poolflags implicitobsoleteusescolors
> solv
On Sat, 1 Apr 2017 15:52:53 +0100, Tomasz Kłoczko wrote:
> Please start playing with those specs files which I've posted.
You have seen my reply to that faulty test case of yours, haven't you.
Nothing would change.
> I fully understand that it is not easy to understand some new approach if
> so
On Fri, 31 Mar 2017 22:44:27 +0100, Tomasz Kłoczko wrote:
> OK so it is exactly like trying to fix the C code issue with left some
> parts of last changes iteration which should be fixed by deleted such
> lines completely and instead such deletion someone is implementing jump
> over such left pa
On Fri, 31 Mar 2017 21:10:29 +0100, Tomasz Kłoczko wrote:
> According to those two "laws" at the moment *I think* that what it was
> codified in FPG was caused by something stupid :)
> Lets say .. it was something like misinterpretation when in on upgrade test
> package from 2.0 to 3.0 someone for
On Fri, 31 Mar 2017 15:16:22 -0400, Fernando Nasser wrote:
> A few issues I remember caused by unversioned Obsoletes (before they
> were banished to Hell) were:
>
> - Not being able, ever again, to provide the thing being obsoleted. And
> believe me, things change ;-)
>
> - The Obsoletes affe
On Fri, 31 Mar 2017 19:41:30 +0100, Tomasz Kłoczko wrote:
> OK. Could you please show me example?
Any non-versioned Obsoletes tag in the repo metadata hides the obsolete
package from the depsolver's view during updates, and depending on the
implementation even during first installs.
> It is yet
On Fri, 31 Mar 2017 17:32:09 +0100, Tomasz Kłoczko wrote:
> I see that you and other people proposing versioned Obsoletes rules never
> ever analysed step by step whole scenario(s) or done kind of 10 min POC to
> prove correctness/incorrectness of this. Looks like again .. it is result
> of using
On Thu, 30 Mar 2017 19:05:54 +0100, Tomasz Kłoczko wrote:
> I see more and more issues related to FPG. And most discouraging is not
> what is inside FPG because I can agree with most of the advices in this
> document
> Seem some packagers are using it almost blindly. And we are not talking
> about
On Wed, 29 Mar 2017 19:26:31 +0100, Tomasz Kłoczko wrote:
> On 29 March 2017 at 17:04, Michael Schwendt wrote:
>
> > It has been discussed several times, has met resistance and lead to
> > actions like
> > https://fedoraproject.org/wiki/Features/SystemPythonExecuta
On Wed, 29 Mar 2017 14:40:31 +0100, Tom Hughes wrote:
> On 29/03/17 14:16, Ralf Corsepius wrote:
> > On 03/29/2017 02:26 PM, Nikolai Kondrashov wrote:
> >> I would say using env in the shebang line is useful. Particularly for
> >> portability. As a developer, I wouldn't like removing it from my
On Tue, 14 Mar 2017 19:04:22 -0400, Randy Barlow wrote:
> What do you find misleading about the review?
It has discussed headers that are not installed anywhere. I expected
to find a spec file that either deletes headers from the buildroot or
includes them in a non-devel package to begin with. In
On Tue, 14 Mar 2017 17:34:16 -0400, Randy Barlow wrote:
> During a package review[0], I suggested that a CLI application's header
> files need to go into a -devel subpackage (they are currently not being
> packaged, except for the -debuginfo subpackage.) The reviewer
> disagrees, but fedora-review
On Tue, 28 Feb 2017 14:51:21 +0100, Björn 'besser82' Esser wrote:
> >>> These are required NOT to be noarched.
> >> This is a Python-package from pypi, not a header only lib… I don't see
> >> any reason for forcing the built binary packages to be archful… There is
> >> no configuration or anyth
On Mon, 27 Feb 2017 22:49:22 +0100, Björn 'besser82' Esser wrote:
> Am 27.02.2017 um 12:36 schrieb Ralf Corsepius:
> > On 02/26/2017 11:13 PM, Susi Lehtola wrote:
> >> Hi,
> >>
> >>
> >> I've packaged pybind11 which is a seamless interface between Python and
> >> C++11. This is a headers-only pa
On Fri, 20 Jan 2017 15:04:56 +0700, Dmitrij S. Kryzhevich wrote:
> Anyway lib_64_ must be handled in another way.
The two new Perl based subst expressions added to %install also are
specific to lib64 build targets and won't be correct where %_libdir expands
to /usr/lib.
> Group: System
> Provided I get some guidance (or readings, account settings, ...), I
> ciuld maintain or co-maintain the package if necessary.
> Release:0%{?dist}
First release of a package usually starts with 1 not 0:
https://fedoraproject.org/wiki/Packaging:Versioning#Release_Tag
> %package devel
>
On Fri, 06 Jan 2017 09:07:55 -, Martin Gansser wrote:
> See koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=17175933
>
> An update of libclaw had to be done because of a problem with mock, see
> Https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread
On Thu, 5 Jan 2017 00:58:00 +, Richard W.M. Jones wrote:
> It would also be nice if:
>
> PYTHON=/usr/bin/python3 %configure
>
> didn't (silently) do the wrong thing by default. For a long time we
> shipped a nbdkit-python3 package which was using python2, and that was
> found to be the ca
On Thu, 29 Dec 2016 14:52:29 +, Sérgio Basto wrote:
> BTW
> I received ABRT report for package mlt has reached 100 occurrences
> Packages: mlt
> Function: QObject::disconnect(QObject const*, char const*, QObject
> const*, char const*)
> First occurrence: 2016-12-17
> Type: core
> Count:
On Mon, 02 Jan 2017 15:10:26 +0100, Pavel Raiskup wrote:
> >
> > %global %_configure :
> > %configure
> >
> > As a result, %configure tries to run “:” instead of “./configure”, which
> > is a NOP, and only the shell variable initialization remains.
> >
> > Is this the recommend way to initiali
On Fri, 30 Dec 2016 00:24:03 +, Richard W.M. Jones wrote:
> OK, maybe you're talking about having %{_isa} in the spec file, ie:
>
> %package doc
> ...
> BuildArch: noarch
> Requires: %{name}%{?_isa} = %{version}-%{release}
>
> ? That would make the dependency include "(x86-64)" (or
On Fri, 30 Dec 2016 00:09:24 +, Richard W.M. Jones wrote:
> On Mon, Dec 26, 2016 at 09:59:54AM +0100, Michael Schwendt wrote:
> > On Sun, 25 Dec 2016 21:33:52 -0500, David Muse wrote:
> >
> > > I guess noarch packages shouldn't have any arch-specific depende
On Thu, 29 Dec 2016 17:11:10 -0700, Orion Poplawski wrote:
> > $ claw-config all --libs
> > -L/usr/lib -lclaw_application -lclaw_logger -lclaw_dynamic_library -ldl
> > -lclaw_configuration_file -lclaw_graphic -lpng -lz -ljpeg -lclaw_logger
> > -lclaw_net -lclaw_tween
> >
> > Is relinking with a
It may be necessary to debug the cmake libclaw detection script.
claw-config is broken, btw, and it's likely that this has not been
caught during review:
$ claw-config --libs
-L/usr/lib
$ claw-config application --libs
-L/usr/lib -lclaw_application -lclaw_logger
$ claw-config dynamic_
On Sun, 25 Dec 2016 21:33:52 -0500, David Muse wrote:
> I guess noarch packages shouldn't have any arch-specific dependencies.
> Is that correct?
Yes.
Noarch packages may be built on any machine of any arch, they may be
copied to any repository for any arch, and they are supposed to be usable
w
On Sat, 24 Dec 2016 15:06:03 -0500, David Muse wrote:
> Oh, I just realized that there's an rpmdiff tool.
Mentioned in your original mail. ;-)
> Well, I tried that,
> and the only difference it shows is the timestamp for each file, which I
> would expect to be different. An rpmdiff -iT of the
On Sat, 24 Dec 2016 12:39:59 +, Sérgio Basto wrote:
> Hi,
> libaudclient was no longer used by any package, so it is a good time to
> retire it for F26 . As usual who may want it, can take it .
Why has it been reintroduced then?
Apparently, no effort has been spent on using it within "conk
On Sat, 24 Dec 2016 03:32:41 -0500, David Muse wrote:
> Hello,
>
> I recently started getting errors like:
>
> 17046740 build (f26, rudiments-1.0.1-1.fc24.src.rpm): open
> (arm04-builder06.arm.fedoraproject.org) -> FAILED: BuildError: The
> following noarch package built differently on differe
On Mon, 12 Dec 2016 16:29:39 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Dec 12, 2016 at 05:09:58PM +0100, Michael Schwendt wrote:
> > On Mon, 12 Dec 2016 15:56:33 +, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > > 4) Package complies to the Packaging G
On Mon, 12 Dec 2016 15:56:33 +, Zbigniew Jędrzejewski-Szmek wrote:
> > 4) Package complies to the Packaging Guidelines: this seems to me like
> > a catch all question, it summarizes all other items, doesn't it?
>
> Yeah. The checklist in fedora-review requires contains a few strange
> items
On Sat, 10 Dec 2016 04:18:44 +, Zbigniew Jędrzejewski-Szmek wrote:
> > >> Here find some helpful links about the Fedora Packager and their
> > >> processes:
> > >>
> > >> * https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> > >> * https://fedoraproject.org/wiki/Category:
On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:
> Hi all
>
> Just modified the gsequencer.spec file. Now, it should be more the fedora way.
>
> https://sourceforge.net/projects/ags/files/fedora/
>
> Additionally, I uploaded the srpm and rpm packages built.
>
> * gsequencer
> * gsequen
On Fri, 09 Dec 2016 11:00:45 -0800, Adam Williamson wrote:
> > Same applies to your usage scenario. Personal experience is just that:
> > personal experience.
>
> Yes, but the burden of proof always lies with those who want to change
> stuff. I've got the easy job here: I just get to say 'look,
On Fri, 9 Dec 2016 19:41:28 +0100, Ralf Corsepius wrote:
> And? What*s the problem? It's part of a packagers job to balance the
> tradeoffs and find a viable compromise.
You don't need to agree. In the reply you've truncated, I've only pointed
out how I feel about the updates flood. It's my numb
On Fri, 09 Dec 2016 09:40:08 -0800, Adam Williamson wrote:
> This is just a bunch of entirely unsupported assertions, and thus not
> worth the time to respond to.
Same applies to your usage scenario. Personal experience is just that:
personal experience.
> But I'll just note that it is not possi
On Fri, 09 Dec 2016 08:44:26 -0800, Adam Williamson wrote:
> On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote:
> > The apparently random flow of poorly tested "rushed out" updates
>
>
Nah, not needed at all. Basically, one can update a desktop workstat
101 - 200 of 1479 matches
Mail list logo
