Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
by Peter Robinson
On Tue, Jun 10, 2014 at 10:37 PM, Adam Goode <adam(a)spicenitz.org> wrote:
> I seem to remember some kind of koji diff report that would come out
> periodically. Is there an automated run of this? I would love a
> dashboard or NxN matrix of diffs between all the arches. A timeseries
> would be perfect (to see the trends Matthew is referring to).
>
> Aha, found what I was thinking of:
> https://lists.fedoraproject.org/pipermail/arm/2013-February/005336.html
That was a diff between primarily and a secondary arch koji, not
actually a diff between x86 and ARM but rather an indication of how
far the secondary was behind primary in terms of pure package builds.
It was also generally quite inaccurate due to bugs in the script and
sometimes a single build failure of a core dependency could causes
bottle necks that could block builds due to dep chains and the fix to
that is always reactionary (get bug fixed, tested, pushed upstream,
generally manually build package to unblock bottle neck).
> Can this be rolled into automation in a more official way?
Not that I'm aware on a primary <-> primary diff with the current
tools. At the moment we basically ask rel-eng to use their mass check
out to to comparisons and that's generally on just Exclude/Exclusive
Arch and doesn't cover arch subsets of features of packages.
> Even something per-package like what Debian does is a start:
> https://packages.debian.org/wheezy/mlton-compiler
> vs.
> https://apps.fedoraproject.org/packages/mlton
The mention of PPC builds is presumably to to messages on the fedmsg
bus coming from the secondary arch PPC koji, the first in that list
covers all 3 mainline arches due to being a single koji instance.
Presumably koji/fedmsg could be enhanced to emit the arch builds
(arm/noarch/ix86/x86_64 too if it doesn't already and then pkgdb
display that info. I'll file a RFE, thanks for the suggestion.
Peter
9 years, 10 months
first and only X needs to be on tty7
by Felix Miata
How can I get it to go there and stay there? When starting F21 in multi-user, logging
in on tty3 and running startx, KDE shows up on tty3, where, as it's currently
broken[1], it needs to be killed to escape it. Ctrl-Alt-BS fails to kill it (in spite
of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose), and
switching to tty3 is unavailable to use Ctrl-C to kill it as can be done when started
from tty3 but running on tty7. The only way out is logging in somewhere else, or CAD.
This shouldn't be.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1092852
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
9 years, 10 months
19->20 fedup-0.8.0-4.fc19 messages worrisome?
by Felix Miata
Does what follows suggest to not proceed with to reboot the fedup grub stanza?
setting up system for upgrade
Finished. Reboot to start upgrade.
Packages without updates:
compat-libstdc++-33
fedup
firefox # versionlock set to avoid australis/FF29
kernel-PAE 3.11.10
kernel-PAE 3.13.9
libgssglue
python-urlgrabber
WARNING: problems were encountered during transaction test:
broken dependencies
firefox 25 requires xulrunner 25
package conflicts
Traceback (most recent call last):
File "/bin/fedup", line 239, in <module>
main(args)
File "/bin/fedup", line 219, in main
for line in s.format_details():
AttributeError: 'ProblemSummary' object has no attribute 'format_details'
As I'm doing this on a clone partition, I can start over as a troubleshooting
exercise if necessary.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
9 years, 10 months
F21 Self Contained Change: Remote Journal Logging
by Jaroslav Reznik
= Proposed Self Contained Change: Remote Journal Logging =
https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
Systemd journal can be configured to forward events to a remote server.
Entries are forwarded including full metadata, and are stored in normal
journal files, identically to locally generated logs.
== Detailed Description ==
Systemd's journal currently provides a replacement for most functionality
offered by traditional syslog daemons,
with two notable exceptions: arbitrary filtering of messages and forwarding of
messages over the network. This Change targets the latter.
The high-level goal is to have a mechanism where journal logging can be
extended
to keep a copy of logs on a remote server, without requiring any maintenance,
done
fairly efficiently and in a secure way.
Two new daemons are added as part of the systemd package:
* on the receiver side systemd-journal-remote accepts messages in the Journal
Export Format [1]. The export format is a simple serialization of journal
entries, supporting both text and binary fields. This means that the messages
are transferred intact, apart from the "cursors", which specify the location
in the journal file. Received entries are stored in local journal files
underneath /var/log/journal. Those files are subject to normal journald rules
for rotation, and the older ones will be removed as necessary to stay within
disk usage limits. Once entries have been written to the journal file, they
can be read using journalctl and the journal APIs, and are available to all
clients, e.g. Gnome Logs [2].
* on the sender side systemd-journal-upload is a journal client, which exports
all available journal messages and uploads them over the network. The (local)
cursor of the last message successfully forwarded is stored on disk, so when
systemd-journal-upload is restarted (possibly after a reboot of the machine),
it will send all recent messages found in the journal and then new ones as
they arrive.
The communication between the two daemons is done over standard HTTPS,
following rather simple rules, so it is possible to create alternate
implementations without much work. For example, curl can be easily used to
upload journal entries from a text file containing entries in the export
format. Basically, the data are sent in an HTTP POST to /upload with Content-
Type: application/vnd.fdo.journal. When doing "live" forwarding, the size of
the transfer cannot be known in advance, so Transfer-Encoding: chunked is
used. All communication is encrypted, and the identity of both sides is
verified by checking for appropriate signatures on the certificates.
== Scope ==
* Proposal owners:
The code in systemd for systemd-journal-remote and systemd-journal-upload will
have to be added. The first is done, and has already been released in the
latest Rawhide systemd package. The second is mostly done, and will be
submitted upstream soon. Necessary units will have to be created, and a
location with suitable permissions will have to be created so that systemd-
journal-remote can run unprivileged. This means that systemd-journal-remote
should probably be packaged as a separate subpackage, similarly to systemd-
journal-gatewayd. systemd-journal-upload uses libcurl, and thus should be also
packaged as a separate subpackage to avoid introducing a new dependency for
systemd.
Suitable defaults for timeouts for transfers and maximum accepted entry sizes
have to be chosen.
A port will have to be picked: systemd-journal-gatewayd uses 19531, so
systemd-journal-remote should probably use 19532.
Two new users will have to be created when the packages are installed.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
[1] http://www.freedesktop.org/wiki/Software/systemd/export/
[2] https://wiki.gnome.org/Apps/Logs
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 10 months
How to troubleshoot build flags
by Richard Shaw
Does anyone have a favorite method of figuring out what build flags are
causing an issue?
I'm trying to package WSPR[1] for the ham radio sig. It is autotools based
and when I use %configure the build fails but when I just use plain
configure it succeeds. It uses gfortran and f2py extensively which I think
is part of it.
The last command prior to the error is identical regardless of which
configure I use so I'm guessing the build flags for one of the input
objects to the gfortran linking phase is causing the issue.
Here's a snippet of the error although my question is how to troubleshoot
these types of problems in general:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
rmbadname1: Replacing "len" with "len_bn".
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
error: Command "/usr/bin/gfortran -Wall -Wl,-z,relro -Wl,-z,relro
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/wmodule.o
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/fortranobject.o
/tmp/tmpom3x2m/wspr1.o /tmp/tmpom3x2m/getfile.o
/tmp/tmpom3x2m/paterminate.o /tmp/tmpom3x2m/audiodev.o
/tmp/tmpom3x2m/tmp/tmpom3x2m/src.linux-x86_64-3.3/w-f2pywrappers.o thnix.o
libwspr.a -L/usr/lib64 -lfftw3f -lgfortran -lportaudio -lpthread
-lsamplerate -lpython3.3m -lgfortran -o ./w.cpython-33m.so" failed with
exit status 1
make: *** [WsprMod/w.so] Error 1
Thanks,
Richard
[1] http://physics.princeton.edu/pulsar/K1JT/wspr.html
9 years, 10 months
koji uploads (for scratch builds) broken?
by Richard W.M. Jones
I'm not sure if this is a local problem, but currently I'm unable
to upload the SRPM to do a scratch build:
$ fedpkg srpm
Wrote: /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
$ koji build --scratch rawhide /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
Uploading srpm: /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm
[ ] 00% 00:00:00 0.00 B - B/sec
At this point it hangs for a very long time, before eventually printing:
GenericError: upload path exists: /mnt/koji/work/cli-build/1402417278.641677.KCBIWmof/libguestfs-1.27.14-3.fc21.src.rpm
I've tried this a few times, including bumping the release, but it
fails in the same way each time.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
9 years, 10 months
NetworkManager-0.9.95 update in rawhide
by Igor Gnatenko
Hi,
After latest update i can't use my wifi in NM. Probably this bug not
in NM, but I don't know how to debug this :(
$ nmcli device status
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
enp0s20u2 ethernet connected enp0s26u1u2
virbr0-nic tap connected virbr0-nic
cdc-wdm2 gsm unavailable --
lo loopback unmanaged --
wlp3s0 wifi unmanaged --
$ nmcli general
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
connected full enabled enabled enabled enabled
$ sudo iwconfig
wlp3s0 IEEE 802.11abgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Let me know what info is needed!
--
-Igor Gnatenko
9 years, 10 months
This Weeks FESCo Meeting: Cancelled
by Toshio Kuratomi
Sorry for the late notification. I took a look at making an agenda for this
week and saw that we only have a few tickets to look at and all of them
are pending input from various other people so I'm cancelling the meeting.
That's two week's in a row so plan on having a meeting next week. We should
hopefully have information back from maintainers on a few tickets and WG
activity reports among others.
-Toshio
9 years, 10 months