On Tue, Jan 22, 2019 at 10:30 AM Jakub Jelinek wrote:
>
> On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
> > This is already happening, gcc was updated, I see bugs for gcc 9 related
> > FTBFS being open. This is not a proper way to coordinate this kind of thing.
>
> I'm sorry, I for
On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek
wrote:
> This makes the assumption, which was also made earlier in the thread,
> that it's somehow impossible to check what bootloader is installed.
> Why? My bootloader is happy to tell me its version:
> $ bootctl
> ...
> Curren
On Sat, May 4, 2019 at 9:36 PM Chris Murphy wrote:
>
> While handling this bug with a Common Bugs report is suboptimal, it
> has long been expected that users should read Common Bugs before
> installing or upgrading their systems. Making that advice more
> prominent might be reasonable.
I never
On Thu, May 2, 2019 at 5:31 PM Irina Boverman wrote:
>
> and this:
> dnf install -y --allowerasing git zip unzip python krb5-workstation
> java-1.8.0-openjdk java-1.8.0-openjdk-devel authconfig expect python3
> python3-requests python3-websockets pycurl which
> Fedora 29 - x86_64 - Updates
On Fri, May 3, 2019 at 8:18 PM Nicolas Mailhot via devel
wrote:
>
> Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit :
> > On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel
> > wrote:
> > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel
wrote:
>
> Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit :
> > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel
> > wrote:
> > [..]
> > > You're assuming the only use is roolback. It's not
> >
> > Point taken. Can you
> Have you reported this to the dnf maintainers via bugzilla?
Not yet, I dumped my upgrade notes here and then browsed bugzilla for
error messages happening during my first f30 boot (turns out there's
already a ticket for all of them) and then time ran out.
Dridi
_
On Thu, May 2, 2019 at 8:30 AM Samuel Sieb wrote:
>
> On 5/1/19 8:16 AM, Dridi Boukelmoune wrote:
> > Here I had to remove the following packages (and they took some of
> > their dependencies away with them) beforehand:
> >
> > - python2-hawkey-0.31.0-2.fc29.x86_64
Hi,
On Tue, Apr 30, 2019 at 4:01 PM Matthew Miller wrote:
>
> It's been six months, and like clockwork, we release Fedora 30 today!
Congratulations! I have done in-place upgrades since Fedora 15 and I
was never let down. This time I even had scheduled a set of offline
tasks to do while my laptop
On Sat, Apr 27, 2019 at 10:13 AM Jaroslav Mracek wrote:
>
snip
>> I just hope the DNF team would implement a retry on failed downloads
>> to not consider a repository unavailable right off the bat especially
>> when we have a list of mirrors to pick from.
>>
>
> We are working on improvement.
Tha
On Thu, Apr 25, 2019 at 11:50 PM Jan Pokorný wrote:
>
> On 25/04/19 09:35 +0200, Dridi Boukelmoune wrote:
> > Also please note that fedora-cisco-openh264.repo ships with
> > "skip_if_unavailable=true".
>
> off-topic: which in fact doesn't matter much, sinc
> That was my understanding, yes. If it is set in the repo file, that
> will override the default.
I'm all for this change, "skip_if_unavailable=true" is a terrible default,
I have spent a fair amount of time this morning on some updates
testing [1] and since RPM Fusion repositories don't set this
> Was this the privileged operation? What privilege does it require? I
> just run the command as a non-admin user and saw no errors or prompts
> for passwords or anything.
Are you part of the wheel group and is wheel configured to be
password-less in sudo?
Dridi
> From looking at it quickly, it seems like you've updated the .spec for
> version 19.17 but have only uploaded sources for 19.16.
If he's not the maintainer he probably doesn't have the privileges to do so.
Dridi
___
devel mailing list -- devel@lists.f
On Mon, Apr 8, 2019 at 4:58 PM Jerry James wrote:
>
> On Mon, Apr 1, 2019 at 9:36 PM Jerry James wrote:
> > That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
> > Sadly, the clisp build is still failing in Rawhide, with failures in
> > the socket tests:
>
> The failing test attem
> Breaking the line with back-slashes didn't work, the modules weren't
> considered arguments to the macro:
>
> > %selinux_modules_install \
> >%{_datadir}/selinux/%{selinuxtype}/mod1.cil \
> >%{_datadir}/selinux/%{selinuxtype}/mod2.pp
>
> I tried %{selinux_modules_install} and other shenan
> > BuildRequires: selinux-policy
> > BuildRequires: /usr/share/selinux/devel/Makefile
>
>
> Thank you for the feedback. You are correct that the BuildRequires in
> the macro are useless. At this point I have no idea how to get around
> the macro expansion. I will at least add selinux-pol
On Fri, Apr 5, 2019 at 3:36 PM Dridi Boukelmoune
wrote:
>
> > I think I found the solution here:
> >
> > https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy
> >
> > BuildRequires: selinux-policy
> > %{?selinux_requires}
> &g
> I think I found the solution here:
>
> https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy
>
> BuildRequires: selinux-policy
> %{?selinux_requires}
>
> This way its expansion can be deferred at rebuild time, I suppose. But
> don't we miss the other BuildRequires tags
On Fri, Apr 5, 2019 at 3:12 PM Dridi Boukelmoune
wrote:
>
> Hello,
>
> I maintain an selinux module package for el7, and recently came across
> interesting macros [1] and in particular %selinux_requires that hides
> the dirty detail and especially one that I missed when I set t
Hello,
I maintain an selinux module package for el7, and recently came across
interesting macros [1] and in particular %selinux_requires that hides
the dirty detail and especially one that I missed when I set this up
back then.
Unfortunately, it appears to be provided by one of the packages it
Bu
Hello,
If like me you use Vagrant with VirtualBox, you may see an update to
version 6 from RPM Fusion free for f29. The problem you may face later
is that f29's version of Vagrant doesn't support VirtualBox 6.
This was enough to solve it for me:
dnf upgrade vagrant --releasever 30
Assuming
On Wed, Mar 27, 2019 at 3:06 PM Martin Gansser wrote:
>
> [martin@f30 fedora-scm]$ cat -v ~/.ssh/config
> Host pkgs.fedoraproject.org
You can probably wildcard it to *.fedoraproject.org in case you have
to ssh somewhere else in the future.
> User martinkg
> IdentityFile ~/.ssh/id_rsa.pub
>
> [ma
On Wed, Mar 27, 2019 at 8:33 AM Nicolas Mailhot
wrote:
>
> Le 2019-03-27 03:46, Nico Kadel-Garcia a écrit :
> > On Tue, Mar 26, 2019 at 3:44 AM Nicolas Mailhot
> > wrote:
>
> >> POSIX is dead as a shell compatibility target. You want to replace
> >> bash
> >> with something faster, by all means d
On Tue, Mar 26, 2019 at 4:15 PM Adam Williamson
wrote:
>
> On Tue, 2019-03-26 at 09:08 -0500, mcatanz...@gnome.org wrote:
> > On Thu, Mar 21, 2019 at 5:05 PM, Tomasz =?UTF-8?b?S8WCb2N6a28=?=
> > wrote:
> > > [tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
> > > /bin/sh
> >
> > How can this dis
On Tue, Mar 26, 2019 at 1:24 PM Nicolas Mailhot
wrote:
>
> Le 2019-03-26 12:29, Dridi Boukelmoune a écrit :
> > On Tue, Mar 26, 2019 at 8:43 AM Nicolas Mailhot
> > wrote:
> >>
> >> Le 2019-03-25 22:47, Japheth Cleaver a écrit :
> >> > If you can t
On Tue, Mar 26, 2019 at 8:43 AM Nicolas Mailhot
wrote:
>
> Le 2019-03-25 22:47, Japheth Cleaver a écrit :
> > If you can take a one-time hit to
> > remove bashisms and get a 25-40% improvement,
>
> CPU time is cheap, packager time is not. Exchanging CPU time for "you
> all should learn to write PO
On Mon, Mar 25, 2019 at 4:57 PM Japheth Cleaver wrote:
>
> On 3/25/2019 8:02 AM, Adam Williamson wrote:
>
> On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
>
> And since RPM appears to be configurable for the
> default interpreter, have it use /usr/bin/bash by
On Mon, Mar 25, 2019 at 4:27 PM Stephen John Smoogen wrote:
>
> On Mon, 25 Mar 2019 at 11:18, Kevin Fenzi wrote:
> >
> > On 3/25/19 8:02 AM, Adam Williamson wrote:
> > > On Mon, 2019-03-25 at 12:59 +0100, Dridi Boukelmoune wrote:
> > >> And since
> > > Fedora is based on GNU tools versus strict POSIX compliant ones. As
> > > such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
> > > /bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
> > > specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is not to
> > > b
On Mon, Mar 25, 2019 at 1:12 PM Florian Weimer wrote:
>
> * Dridi Boukelmoune:
>
> > This is the kind of spec that leads to spoiled upstreams putting
> > /bin/sh in shebangs and scratching their heads when they get bug
> > reports for stricter systems...
> >
>
> Try 1 at specification:
>
> Fedora is based on GNU tools versus strict POSIX compliant ones. As
> such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
> /bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
> specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is no
On Fri, Mar 22, 2019 at 6:04 PM Japheth Cleaver wrote:
>
> On 3/21/2019 3:23 PM, Richard W.M. Jones wrote:
>
>
> So what? On Fedora /bin/sh is bash, and bash is a fine shell.
>
> All this nonsense of using dash for /bin/sh on Debian is IMO a
> pointless bunch of make-work.
>
> Fedora has certainl
> This is fine, because /bin/sh is a symbolic link to /usr/bin/bash on Fedora.
>
> I always use pushd/popd in my packages.
It was also in the python packaging guidelines for py2+py3 builds.
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
T
> So what? On Fedora /bin/sh is bash, and bash is a fine shell.
I don't disagree.
> All this nonsense of using dash for /bin/sh on Debian is IMO a
> pointless bunch of make-work.
I may complain about Debian on every occasion but I think dash is a
much more sensible choice for /bin/sh, and that
On Fri, Mar 8, 2019 at 9:08 PM Kaleb Keithley wrote:
>
> The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x
> in f30/rawhide.
It just occurred to me that this was a normal update when epoch was
increased, right?
Maybe what we need is to have koji for example refusing e
On Fri, Mar 8, 2019 at 12:29 PM Miro Hrončok wrote:
>
> There is a FedoraReview port to Python 3 that needs real word testing by
> packagers.
>
> When you use FedoraReview, please use the Python 3 port instead to help us
> find
> bugs.
>
> Instructions are at https://pagure.io/FedoraReview/pull-
Hello,
On Wed, Mar 13, 2019 at 3:37 PM Stephen John Smoogen wrote:
>
> Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
> and several helpers have gotten nearly all of the python34 packages
> moves over to python36 in EPEL-7. They are being included in 6 Bodhi
> pushes becau
On Wed, Mar 13, 2019 at 1:42 PM Neal Gompa wrote:
>
> On Wed, Mar 13, 2019 at 8:39 AM Miroslav Suchý wrote:
> >
> > Hi,
> > I am curious whether we can move our repo files from
> > /etc/yum.repos.d
> > to
> > /etc/distro.repos.d
Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d?
>
On Wed, Mar 13, 2019 at 12:19 PM Jakub Jelinek wrote:
>
> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/HardenedCompiler
> >
> > == Summary ==
> > By Default enable a few security hardening flags which are used with GCC.
>
> I'm strongly aga
> All that's broken is a 3rd party's assumption that their Epoch setting
> is greater than Fedora's. Assuming Ceph want to keep using Epoch in
> this way, upstream can simply bump their Epoch again to be greater than
> Fedora's new Epoch.
Or bump their Epoch to something much less likely to confli
On Mon, Mar 11, 2019 at 11:00 AM Petr Viktorin wrote:
>
> On 3/9/19 7:33 PM, Chris wrote:
> > 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 i
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
> --ena
On Sun, Feb 24, 2019 at 10:43 PM Michael Schwendt wrote:
>
> On Sun, 24 Feb 2019 11:50:45 +0100, Dridi Boukelmoune wrote:
>
> > >The mail system
> > >
> > > (expanded from ):
> > > connect
> > > to mail1.ATrpms.ne
On Sun, Feb 24, 2019 at 11:23 AM Mail Delivery System
wrote:
>
> This is the mail system at host bastion02.phx2.fedoraproject.org.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send
Hi,
Somehow this slipped through the cracks:
> Dependencies resolved.
>
> Problem: cannot install the best update candidate for package
> devscripts-2.18.4-1.fc29.x86_64
> - nothing provides perl(GitLab::API::v4::Constants) needed by
> devscripts-2.19.2-3.fc29.x86_64
I tried this too but no
Hi Graham,
On Thu, Feb 21, 2019 at 1:23 PM Graham Leggett wrote:
>
> On 19 Feb 2019, at 12:03, Dridi Boukelmoune
> wrote:
>
> > Greetings packagers,
> >
> > I know how important RPM is to the Fedora Project, but it breaks
> > everything downstream and we
On Wed, Feb 20, 2019 at 4:30 PM Panu Matilainen wrote:
>
> On 2/20/19 5:19 PM, Sérgio Basto wrote:
> > On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
> >> No, that was a bad joke from my end, what I need is proper apt in
> >> Fedora to use sbuild.
>
On Wed, Feb 20, 2019 at 4:20 PM Sérgio Basto wrote:
>
> On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
> > No, that was a bad joke from my end, what I need is proper apt in
> > Fedora to use sbuild.
>
> If you also do the review-request for apt [1] it would b
On Wed, Feb 20, 2019 at 11:04 AM Akarshan Biswas
wrote:
>
> > I know how important RPM is to the Fedora Project, but it breaks everything
> > downstream and we'd be better off using DPKG as we should have from day one.
>
> Doesn't we have flatpaks for that purpose?
No, that was a bad joke from m
> I'm the debhelper maintainer
>
> where are your packages submissions ? (can you add me please )
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
I CC'd you just now. According to Neal we may not need to package GNU
config, l
On Tue, Feb 19, 2019 at 7:08 PM Tomasz Kłoczko wrote:
>
> On Tue, 19 Feb 2019 at 11:11, Dridi Boukelmoune
> wrote:
> [..]
>>
>> Apt is a mix of C, Perl and C++ code, so I would be reassured if I
>> could have a C++ co-maintainer too. I'm only a C developer so
> TLDR , apt-rpm should be retired because nobody use it since more than
> 10 years .
>
> I maintain a lot of debian package in Fedora but apt-debian still not
> on Official repos you can get it from my devel corp repo [1]
> My goal is make a system where rpm produce deb files , to allow Debian
>
> For what it's worth, this was a terrible lede for this email. And
I couldn't help it, my inner prankster insisted :)
> having worked extensively with both package managers, I can sincerely
> tell you both are ugly as hell, but rpm is less ugly than dpkg.
Yes, I'm not saying that rpm is perfect
On Tue, Feb 19, 2019 at 11:20 AM Emmanuel Seyman wrote:
>
> * Dridi Boukelmoune [19/02/2019 11:03] :
> >
> > Three of those packages are heavy on Perl code, and I'm not a Perl
> > Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
> > the
Greetings packagers,
I know how important RPM is to the Fedora Project, but it breaks
everything downstream and we'd be better off using DPKG as we should
have from day one.
I'm calling this initiative fedpkg: Fedora Embraces DPKG.
A bit of background here: I build both RPMs and DEBs for $DAYJOB
On Mon, Feb 18, 2019 at 11:00 PM Miro Hrončok wrote:
>
> On 18. 02. 19 21:18, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dependencies
> >
> > = Automatic strict inter-package dependencies =
> >
> > == Summary ==
> > Implement feature in RPM which wi
On Mon, Feb 18, 2019 at 9:21 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
>
> = BuildRequires Generators =
>
> == Summary ==
> Add possibility to generate build-time dependencies within RPM spec
> file and teach RPM and mock how to handle this.
>
> == Ow
> Sphinx 2.0 does not support Python 2.
I figured that much :)
> We could make it so that we only update Sphinx on python 3, but leave the old
> version on Python 2, however that kicking a dead horse, so we decided to drop
> python2-sphinx at once.
>
> > We already have python3-sphinx in f29, so
On Wed, Feb 13, 2019 at 8:38 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Sphinx2
>
> == Summary ==
> The version 2.0.x of [https://www.sphinx-doc.org/ Sphinx], popular
> Python documentation generator and framework, is expected to be
> [https://github.com/sphinx-doc/sphinx/issu
> Fedora Legacy?
Please don't call the current way of doing things legacy until
modularity shows some maturity. For now it smells like
time-to-market-driven protoduction [1] that is still missing crucial
core functionality to work end-to-end.
Dridi
[1] prototype deployed to production
__
> I've filed
> https://pagure.io/fedora-infrastructure/issue/7553
> to track this.
FWIW: https://github.com/rpm-software-management/dnf/pull/1109
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
On Mon, Feb 11, 2019 at 3:30 AM Neal Gompa wrote:
>
> On Sun, Feb 10, 2019 at 9:22 PM Dridi Boukelmoune
> wrote:
> >
> > > I don't read repodata manually, libsolv does it for me. Using libdnf
> > > and/or libmodulemd is not something what (for example) OBS
> FWIW, openQA tests have been failing relatively frequently with
> timeouts while refreshing repos or 503s from mirrormanager for the last
> few weeks. I'm pretty sure this didn't used to be anything like as
> common...
Whether it's dnf upgrade of my system or mock builds, both problems
have been
> I don't read repodata manually, libsolv does it for me. Using libdnf and/or
> libmodulemd is not something what (for example) OBS would do. They rely on
> libsolv for all dependency solving operations. And unless it will support
> modularity (which depends heavily on DNF people's ability to sp
On Tue, Feb 5, 2019 at 8:03 PM Miro Hrončok wrote:
>
> I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
> well since GCC 9:
>
> python3-debug.x86_64: E: library-not-linked-against-libc
> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
>
On Mon, Feb 4, 2019 at 9:27 PM Samuel Rakitničan
wrote:
>
> Hi,
>
> Got via e-mail that libdxflib's ABI changed in comparison to previous
> release, yet nothing changed in the package except version bump for the mass
> rebuild. Why is that?
Got that for a package too, and the major thing that c
> I've seen this errror before. It's uusally caused by upstream accidentally
> overriding CFLAGS instead appending to already set CFLAGS, which breaks
> fedora builds. Look for something like "set *CFLAGS* (foo bar)" in
> CMakeLists.txt files, and change it to *append* to the already existing va
> > Well that's news to me! This is not hosted under fp.org so I'm a bit
> > surprised.
>
> It's not, we just hacked this when he started monitoring the Python 3 porting
> progress. It's created by Fedora Python SIG without the involvement of Fedora
> Infra.
Ack.
> The important bit is to check
Hi,
Thanks everyone for such quick answers!
On Sun, Jan 13, 2019 at 6:17 PM Miro Hrončok wrote:
>
> On 13. 01. 19 16:58, Dridi Boukelmoune wrote:
> > Greetings,
> >
> > I'm planning to work on the python packages I maintain to move them to
> > python 3 only
> > after re-reading this thread, I'm still unclear on some issues. Please
> > correct me if I'm wrong.
> >
> > - The plan is to patch the Fedora package to remove support for some
> > algorithms above and beyond what upstream is removing right now.
>
> Upstream has never removed an algorithm. H
Greetings,
I'm planning to work on the python packages I maintain to move them to
python 3 only as per the python 2 deprecation in f30.
I would like to find all the dependencies of my packages of interest,
but couldn't find an off-the-shelf script I would feed SRPM names that
would recursively re
> - Now that I've mentioned it, maybe we should add something like "fedpkg
> fas-login"? Personally I've put "alias koji-init='kinit
> my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to solve
> the "koji says I'm unauthenticated" error got boring after the third time.
Mine
> Yup. I don't fancy reimplementing user/group management in rpm directly,
> I'm thinking more about integrating with existing solutions one way or
> the other. Sysusers is a good candidate since, as you point out, it has
> a declarative syntax already. The biggest problems with any approach
> tend
On Thu, Jan 3, 2019, 09:59 Panu Matilainen On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
> >> "FV" == Fabio Valentini writes:
> >
> > FV> - unless those other, main icon theme packages have also added
> > FV> %transfiletrigger* scriptlets, like I've done for elementary and
> > FV> Paper.
> >
> Consider the Go case: we know that most Go packages will be statically
> linked (issues with that are a different topic), so we know they will
> work fine once built. However, if the application upstream cannot
> build with the latest "stable" version because of
> backwards-incompatible changes,
> The advantage for packagers is just temporary, as long as the
> (supposedly) older library they still use is maintained. One day, they
> will need to move forward. This is just postponing the inevitable.
And for the same reason we have compat packages, we can't always honor
the First principle b
On Tue, Nov 6, 2018 at 6:06 PM Stephen Gallagher wrote:
>
>
> I find myself repeating this reply over and over again in various places...
Sorry about that.
> The feedback that we (Red Hat) got about SCLs that was filtered down
> to Engineering was this:
>
> 1) Customers really like having the o
> I'm with you in the sense that I too fail to see practical benefits of
> modules so far. But e.g. the java-sig says it makes their life easier,
> and it is their choice. The decision was made to proceed with
> modularity in Fedora. Once that decision was made, we cannot forbid
> packagers from ma
On Fri, Oct 19, 2018 at 5:15 PM Kamil Paral wrote:
>
> I don't know how to build Proton and the people who reported Proton works for
> them on Fedora are simply referring to the bundled Proton in Steam
> installation, I believe.
Makes sense! And this is exactly what I'm trying to avoid... Non-f
On Thu, Oct 18, 2018 at 5:21 PM Rex Dieter wrote:
>
> Steam is currently available from rpmfusion, fwiw/fyi/ymmv :
> https://pkgs.rpmfusion.org/cgit/nonfree/steam.git/
It is, and as usual, thanks to the rpmfusion folks! The reason why I
tried this outside of Fedora first is that steam is part of
Hello,
Following the discussion on raising the fileno limit to make Steam
Proton [1] work well on Fedora I was wondering if anyone managed to
build it and document it somewhere. I believe someone did it since
they reported completely stable compatibility [2] on Fedora 28 but
couldn't find build in
> I just submitted a review request [1] for kcov [2] that I recently
> discovered. It has no relation to Linux's kcov and is more akin to
> lcov, except that all it needs is a binary with DWARF debuginfo
> instead of requiring compile-time instrumentation.
>
> I came across kcov when I was looking
On Wed, Jul 4, 2018 at 9:44 PM, Miro Hrončok wrote:
> Hi again,
>
> this as a reminder that you package still requires Python 3.6. It needs a
> rebuild and the build is failing. Please fix it and rebuild your package.
I finally got around to fixing python-blockdiag and rebuilding its dependent
pa
2018-06-28 20:41 GMT+02:00 Miro Hrončok :
> This is a reminder that your package FTBFS with Python 3.7. Please fix it.
> We'd like to merge the side tag soon and your package will likely get broken
> deps afterwards. Chances are your package blocks others.
>
> If nothing depends on your package and
> To be completely clear here, crypto-mining is not a valid use of Fedora
> Project resources. Hopefully our community realizes and respects this.
To be completely clear here (just in case it was misinterpreted=) I
was expressing my concern. I'm not worried about our community but it
is my underst
Hello list,
Since I work on a project that uses the Coverity Scan free plan for
open source software it came to my attention today that free scans
were put on hold and resumed recently because people were abusing it
for crypto mining.
Since I couldn't find any discussion on this list around this
> I really do like this. There are only two issues I have with it:
>
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.
>
> 2. Mandating a forge is going to be tricky for self-hosted s
> And also, at some point in the future once this is implemented and the
> new setup has been around for a while, systemd should start emitting a
> warning during boot, to notify people that such setups will stop being
> supported at some future point.
But your average user won't see that. For sta
Sorry for the top post, on my phone...
Telling third party software to link against a different soname suffixed
with 64 would be pkg-config's job, usually.
Dridi
On Jan 10, 2018 14:59, "Sandro Mani" wrote:
Hi
I've received a request to package a version of scotch with 64bit integers
(as oppos
On Mon, Nov 13, 2017 at 11:01 PM, Tomasz Kłoczko
wrote:
> On 13 November 2017 at 10:52, Björn 'besser82' Esser
> wrote:
> However AFAIK only reason of any issues related to use -Wl,--as-needed
> is using WRONG list -l parameters (lack of some -l) and this
> needs to be not treated by apply some
solution is one problem, but not the reason why I
brought this to the devel list instead of filing a bug. But this is
interesting to know, thanks!
On Wed, Aug 30, 2017 at 12:52 PM, Martin Stransky wrote:
> On 08/24/2017 04:46 PM, Dridi Boukelmoune wrote:
>> Maybe someone confused Conflicts wi
Hello,
For some reason I fail to understand, a non-devel package is
conflicting with a devel package :-/
According to dnf it's the only explicit conflict for the package:
$ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64
pkgconfig(nspr) >= 4.16
Maybe someone confused Conflicts wi
-- Forwarded message --
From:
Date: Wed, Aug 16, 2017 at 5:46 PM
Subject: pkgdb created branch 'f27' for the 'rpms/varnish-agent' package
To: dridi.boukelmo...@gmail.com
pkgdb created branch 'f27' for the 'rpms/varnish-agent' package
https://src.fedoraproject.org/rpms/va
Greetings developers,
I just submitted a review request [1] for kcov [2] that I recently
discovered. It has no relation to Linux's kcov and is more akin to
lcov, except that all it needs is a binary with DWARF debuginfo
instead of requiring compile-time instrumentation.
I came across kcov when I
On Tue, May 30, 2017 at 1:05 PM, Pavel Zhukov
wrote:
> Hello.
> Due to many CVEs and low quality/security of these packages as well as
> Windows oriented upstream I'm going to orphan both jbig2dec and mupdf
> packages in Fedora/EPEL.
> Sometimes the build doesn't reach stable branch just becaus
> I forwarded your post to the list owners... they are at least the first
> line of folks to talk to about this.
Thanks! I'll try to keep that in mind (no promises=)
> If they can't clear things up, then an infrastructure ticket and we can
> see what we can do from there.
It's gone now.
Cheers
Hi there,
I'm not sure where it's best to report but today I wanted to probe the
progress of Fedora MIPS [1] but since I'm not registered to this list
I opted for the web archive. The first non-spam message [2] I could
find is from March, everything after that is just noise.
I suppose members of
> No I'm not talking audio/video packages. There are other packages
> missing from Fedora and RPM Fusion, which are available on Ubuntu and on
> arch repositories or AUR and they are qualified to included in the
> Fedora's repositories. For example I need for my university ns2, nam,
>
That's cool
> I've seen many users (especially youtubers) avoiding Fedora because of some
> missing packages and because it's not so user friendly.
> So, my goal is to contribute to Fedora by creating some simple packages which
> I've seen many people ask for.
Hello,
I will go ahead and make the assumption
101 - 200 of 288 matches
Mail list logo
