Fwd: Broken dependencies: fedpkg
by Chenxiong Qi
I have no idea why this happens. Can anyone (maybe Bodhi developers I
guess, I'm not sure) help to solve this?
-------- Forwarded Message --------
Subject: Broken dependencies: fedpkg
Date: Mon, 7 Nov 2016 14:21:23 +0000 (UTC)
From: buildsys(a)fedoraproject.org
To: fedpkg-owner(a)fedoraproject.org
fedpkg has broken dependencies in the rawhide tree:
On ppc64:
fedpkg-1.25-1.fc26.noarch requires bodhi-client
Please resolve this as soon as possible.
7 years, 5 months
COPR auto-rebuilds on pagure commits
by Michal Novotny
Hey,
I'd like to announce that we now support package auto-rebuilding on a new
commit(s) into a Pagure repository. Apart from having your package repo
hosted in Pagure, you just need to enable firing of fedmsg notifications
for new commits by clicking a single checkbox in 'Hooks' section...well,
then you also need to save this setting and have auto-rebuilding enabled
for the copr package but that really is it, I promise :).
clime
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
7 years, 5 months
fc24 packages when running dnf on f25
by Dusty Mabe
Is it normal to have fc24 packages get installed when I install a package on F25?
This system started as an F25 cloud instance based on the cloud image.
$ rpm -qa | grep fc24 | wc -l
116
$ cat /etc/redhat-release
Fedora release 25 (Twenty Five)
- Dusty
7 years, 5 months
DNF and PackageKit background data usage
by Adam Williamson
Hi folks!
I kinda hate kicking off discussions like this without having a solid
solution to propose or being able to promise to work on one, but this
really seems important. Unfortunately I can't claim I'm gonna have time
to do any concrete work on it, though I'd really *like* to. But I
thought it would be worthwhile to kick around still; perhaps someone
else will be inspired.
I just read Hedayat's review of Fedora 25 Beta:
https://hedayatvk.wordpress.com/2016/10/30/fedora-25-beta
and this really jumped out at me:
"And, if you care about your internet usage, make sure that you disable
both dnf makecache timer, and stop PackageKit from downloading updates
automatically. I don’t allow a new Fedora installation to access
internet before doing these, as it might just eat a considerable amount
of data."
There's two things I think are somewhat unfortunate here:
1) Both dnf and GNOME Software / PackageKit default to performing
fairly data-hungry transactions in the background, out of the box,
without telling you about it. GNOME's is particularly bad, as it will
happily download available updates in the background, which can be
gigabytes worth of data. DNF only updates its metadata caches (on a
systemd timer), but even that could be behaviour that users in certain
circumstances really really do not want.
2) There is no particularly obvious or visible mechanism for a 'typical
user' (or, if you prefer, many of the target 'personas' for our
flavors) to configure this behaviour...and you have to figure out two
completely *different* configuration mechanisms in order to shut off
both.
I think this is kind of poor behaviour on our part and we should make
it better. Do I have a specific concrete proposal? No. But I do have
some vague ideas.
* We could have some kind of configuration interface appear on install
/ first boot. This would require integration with anaconda and/or
initial-setup and gnome-initial-setup.
* We could invert the defaults and have the apps ask the user if they
want to enable data-hungry background operations on first interaction:
the first time you use dnf (without -y) it could say 'hey, do you want
to turn on background cache refreshes?' Similarly, the first time you
run GNOME Software or click on an update notification, it could say
'hey, do you want to turn on background update downloads'?
* We could at least make both of them respect one single config setting
for 'do data hungry background operations' (this is kinda one small
part of the bigger issue that is 'dnf and PK-based stuff don't share
any configuration aside from repo definitions').
Anyone have thoughts on this? Any DNF or Software devs want to say I'm
totally wrong and an idiot? Anyone inspired to do something more
concrete than a mailing list post? :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 5 months
Re: RFH: Annotating ELF binaries
by Florian Weimer
On 11/07/2016 07:00 PM, Joseph Myers wrote:
> On Sun, 6 Nov 2016, Ian Lance Taylor wrote:
>
>> The only sensible way to write the psABI is for it to say "this is how
>> to pass an 80 or 128 bit floating point value." The psABI can't say
>
> I would advise using IEEE 754-2008 names in psABIs where available (e.g.
> binary128). (Of course you need to deal with the non-IEEE types such as
> x86 extended precision, but IEEE names are standard and unambiguous up to
> endianness for binary interchange formats, and unambiguous up to
> endianness and BID / DPD choice for decimal interchange formats.)
Most people in the community don't have access to IEEE 754-2008 and
therefore will not know what these terms mean (and considering how much
stuff has been made up about IEEE 754 due to its secretive nature, I
wouldn't want to rely on a paraphrase).
Florian
7 years, 5 months
Fwd: Broken dependencies: deluge
by Michael Cronenworth
Can someone please fix this? I don't own pygame. Pygame wasn't rebuilt for ppc
builds. I'm getting spammed daily for something I cannot fix.
-------- Forwarded Message --------
Subject: Broken dependencies: deluge
Date: Mon, 7 Nov 2016 14:21:25 +0000 (UTC)
From: buildsys(a)fedoraproject.org
To: deluge-owner(a)fedoraproject.org
deluge has broken dependencies in the rawhide tree:
On ppc64:
deluge-common-1.3.13-1.fc25.noarch requires pygame
On ppc64le:
deluge-common-1.3.13-1.fc25.noarch requires pygame
Please resolve this as soon as possible.
7 years, 5 months
dnf pulling in kernel-debug for L2TP
by Chris Adams
I was trying to figure out why I had kernel-debug* packages installed,
and tracked it to xl2tpd wanting "kmod(l2tp_ppp.ko)". That is provided
by kernel-debug-modules-extra and kernel-modules-extra; dnf choose to
install the -debug version (which then pulls in the debug kernel as
well).
That means that any kernel update downloads more data and takes longer
to install, and the boot menu has twice as many options (which can be
confusing to some people).
I looked in bugzilla, and there are already two bugs (at least) for
this:
https://bugzilla.redhat.com/show_bug.cgi?id=1192189
https://bugzilla.redhat.com/show_bug.cgi?id=1284228
The first one is almost 2 years old! That means that anybody that wants
L2TP support (which is in some default package sets I believe) gets
unneeded debug kernels. Surely something can be done to fix this?
It seems that the root of the problem is that dnf resolves dependencies
differently from yum and refuses to change to the old well-known
behavior.
--
Chris Adams <linux(a)cmadams.net>
7 years, 5 months
