Dead package wiki page
I have been following the end of life process documented here: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life The very last step contains a link to file a ticket asking rel-eng to block the package. Clicking on that link takes me to a page that says: Forbidden TICKET_CREATE privileges are required to perform this operation I'll see if I can create a ticket some other way, but I thought I should alert somebody about this. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Anyone using aplus-fsf?
I have a long-standing bug report against aplus-fsf (https://bugzilla.redhat.com/show_bug.cgi?id=523882). The maintainer, Jochen Schmitt, hasn't responded in over a year. I'm finally getting around to starting the unresponsive maintainer process, so if he doesn't respond soon, I'll ask here whether anyone knows how to contact him. I thought I should give fair warning to anyone who might be using aplus-fsf, though: if Jochen fails to respond and I become aplus-fsf maintainer, I intend to kill that package. If you want to keep it alive, taking action soon would be a good idea. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: One big old problem and one new with Rawhide
On Sat, Jul 16, 2011 at 2:49 PM, Lucas wrote: > One big problem is that my laptop can't go through systemd startup with > selinux enabled. > Boot hangs at random points - setup keyboard, stdio syslog bridge, kernel > variables. Laptop just > hangs, nothing happens and all I can do it turn it off. The only way is to > add "selinux=0". If you are running a 32-bit kernel, you might be seeing this bug: https://bugzilla.redhat.com/show_bug.cgi?id=714478 I don't know what could be causing your second problem. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RPM version goes backward in Rawhide
I just did a "package-cleanup --orphans" on my Rawhide machine to see which of the just-blocked packages are installed there. To my surprise, I got this: # package-cleanup --orphans Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit [snip stuff that I need to take care of] rpm-4.9.1-2.fc16.x86_64 rpm-build-4.9.1-2.fc16.x86_64 rpm-build-libs-4.9.1-2.fc16.x86_64 rpm-devel-4.9.1-2.fc16.x86_64 rpm-libs-4.9.1-2.fc16.x86_64 rpm-python-4.9.1-2.fc16.x86_64 # repoquery rpm rpm-0:4.9.0-10.fc16.x86_64 Was this intentional? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On Tue, Jul 26, 2011 at 2:14 PM, Michael Schwendt wrote: > Yes, It got untagged. See last week's thread on this list: > Subject: rpm builds failing with "Installed (but unpackaged) file(s) found" Thanks for the replies, Tomas and Michael. I somehow missed the part where I needed to downgrade rpm. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto not strip .so on install
On Wed, Jul 27, 2011 at 9:48 AM, Neal Becker wrote: > Trying to help packaging dmtcp. There are 2 shared libs installed. They are > stripped by the rpm install, and then fail when attempting to dlopen them (or > 1 > of them). Fail how? What's the error? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto not strip .so on install
On Wed, Jul 27, 2011 at 11:34 AM, Neal Becker wrote: > 7. Verify that the only difference is replacing the shared libs installed via > rpm vs. the same shared libs installed without rpm. > > So something that rpm does to the shared libs (in /usr/lib64/dmtcp) is > breaking > things. The only thing I can think of is strip. > > 8. Notice the error: > > dlerror() = /usr/lib64/dmtcp/libmtcp.so: undefined symbol: > mtcp_restore_start > > But it is defined! > nm -D /usr/lib64/dmtcp/libmtcp.so | grep mtcp_restore_start > 911c T mtcp_restore_start > > That was the non-working version of libmtcp.so, which has been stripped. It isn't strip. If I run strip on the version of libmtcp.so left in the build dir and copy it over /usr/lib64/dmtcp/libmtcp.so, then it also works. But that version is different from the one installed by rpm. Watch this: $ ldd -r /usr/lib64/dmtcp/libmtcp.so linux-vdso.so.1 => (0x7fff7d7c3000) libdl.so.2 => /lib64/libdl.so.2 (0x7f913f396000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f913f17b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f913ef65000) libc.so.6 => /lib64/libc.so.6 (0x7f913ebcc000) /lib64/ld-linux-x86-64.so.2 (0x00352060) undefined symbol: mtcp_restore_start(/usr/lib64/dmtcp/libmtcp.so) undefined symbol: dmtcp_exists (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_restore_argv_start_addr (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_sys_errno(/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_get_thread_sysinfo (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_no (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_dump_tls (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_readdec (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: test_and_prepare_for_forked_ckpt (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: write_ckpt_to_file(/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_readchar (/usr/lib64/dmtcp/libmtcp.so) $ ldd -r /tmp/libmtcp-stripped.so linux-vdso.so.1 => (0x7fffcd3ff000) libdl.so.2 => /lib64/libdl.so.2 (0x7f02082b3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f0208098000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f0207e82000) libc.so.6 => /lib64/libc.so.6 (0x7f0207ae9000) /lib64/ld-linux-x86-64.so.2 (0x00352060) The program /usr/lib/rpm/debugedit is used to extract debug information from ELF objects when building RPMs. It looks like it is damaging the shared object somehow. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto not strip .so on install
On Wed, Jul 27, 2011 at 12:06 PM, Jerry James wrote:
> It isn't strip. If I run strip on the version of libmtcp.so left in
> the build dir and copy it over /usr/lib64/dmtcp/libmtcp.so, then it
> also works. But that version is different from the one installed by
> rpm. Watch this:
>
> $ ldd -r /usr/lib64/dmtcp/libmtcp.so
> linux-vdso.so.1 => (0x7fff7d7c3000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f913f396000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f913f17b000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f913ef65000)
> libc.so.6 => /lib64/libc.so.6 (0x7f913ebcc000)
> /lib64/ld-linux-x86-64.so.2 (0x00352060)
> undefined symbol: mtcp_restore_start (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: dmtcp_exists (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_restore_argv_start_addr (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_sys_errno (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_get_thread_sysinfo (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_no (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_dump_tls (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_readdec (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: test_and_prepare_for_forked_ckpt
> (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: write_ckpt_to_file (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_readchar (/usr/lib64/dmtcp/libmtcp.so)
> $ ldd -r /tmp/libmtcp-stripped.so
> linux-vdso.so.1 => (0x7fffcd3ff000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f02082b3000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f0208098000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f0207e82000)
> libc.so.6 => /lib64/libc.so.6 (0x7f0207ae9000)
> /lib64/ld-linux-x86-64.so.2 (0x00352060)
>
> The program /usr/lib/rpm/debugedit is used to extract debug
> information from ELF objects when building RPMs. It looks like it is
> damaging the shared object somehow.
H, the dmtcp project is patching the default linker script:
make[1]: Entering directory
`/home/jamesjer/rpmbuild/BUILD/dmtcp-1.2.3+svn1214/mtcp'
rm -f mtcp.t
ld -shared --verbose > mtcp.t
sed -i -e '1,// d' mtcp.t
sed -i -e '//,$ d' mtcp.t
rm -f mtcp.t-fail
if test x86_64 = x86_64; then \
if patch mtcp.t mtcp.t.patch-x86_64; then \
:; \
else \
mv mtcp.t mtcp.t-fail; false; \
fi \
else \
if patch mtcp.t mtcp.t.patch-i386; then \
:; \
else \
mv mtcp.t mtcp.t-fail; false; \
fi \
fi
patching file mtcp.t
Hunk #1 succeeded at 6 with fuzz 2.
Hunk #2 succeeded at 189 (offset 14 lines).
...
gcc -shared -fPIC -T mtcp.t -Wl,-Map,mtcp.map -o libmtcp.so \
mtcp.o mtcp_restart_nolibc.o mtcp_maybebpt.o mtcp_printf.o
mtcp_util.o mtcp_safemmap.o mtcp_safe_open.o mtcp_state.o
mtcp_check_vdso.o mtcp_sigaction.o mtcp_ptrace.o mtcp_fastckpt.o -ldl
-lpthread
Here's the diff against the default linker script:
--- linker.default 2011-07-27 12:09:30.492379093 -0600
+++ mtcp.t 2011-07-27 11:48:10.803379078 -0600
@@ -1,12 +1,3 @@
-GNU ld version 2.21.51.0.6-6.fc15 20110118
- Supported emulations:
- elf_x86_64
- elf32_x86_64
- elf_i386
- i386linux
- elf_l1om
-using internal linker script:
-==
/* Script for --shared -z combreloc: shared library, combine & sort relocs */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
"elf64-x86-64")
@@ -15,6 +6,9 @@
SEARCH_DIR("/usr/x86_64-redhat-linux/lib64");
SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64");
SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib");
SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib");
SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
SECTIONS
{
+ .the.begin : {
+ *(__shareable_begin)
+ }
/* Read-only sections, merged into text segment: */
. = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;
.note.gnu.build-id : { *(.note.gnu.build-id) }
@@ -195,6 +189,9 @@
*(.ldata .ldata.* .gnu.linkonce.l.*)
. = ALIGN(. != 0 ? 64 / 8 : 1);
}
+ .the.end : {
+ *(__shareable_end)
+ }
. = ALIGN(64 / 8);
_end = .; PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
@@ -239,4 +236,3 @@
}
-==
That may or may not have something to do with your problem, but it
probably bears looking into.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto not strip .so on install
On Wed, Jul 27, 2011 at 12:23 PM, Neal Becker wrote: > Sounds like the best course of action is to just disable debugedit? > 1. Would this be acceptable for a fedora package? > 2. Is it possible to disable debugedit? I don't think disabling debugedit is necessary. I think I see the problem. Caveat: I don't REALLY know what I'm talking about. You should get someone who understands the linker to help out. Upstream is adding new sections named .the.begin and .the.end, containing __shareable_begin and __shareable_end, respectively, in order to bracket the range of addresses they need to worry about. However, their altered linker script does not put these new sections in any particular segment, and since ld doesn't recognize the section names, they aren't added to any of the default segments, so they aren't marked as either loadable or allocatable. That means they can be garbage collected, which debugedit dutifully does. In short, this is an upstream bug. If that shared library was in /usr/lib64 where prelink could see it, I bet that prelink would nuke those sections, too. The solution is for upstream to change their linker scripts to put those new sections into a segment that won't be garbage collected. Take a look at the output of "readelf -S libmtcp.so". Note the absence of any flags on the ".the.begin" and ".the.end" sections. Also, the output of "readelf -l libmtcp.so" shows that there is no section-to-segment mapping for the new sections. Hoping-this-is-not-utter-nonsense-ly yours, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: ipython-0.11 breaking anything :)
On Sun, Jul 31, 2011 at 12:53 PM, Thomas Spura wrote: > Hi list, > > I just build ipython-0.11 in rawhide, which changed pretty much > anything internally, so *ALL* dependant packages will be possible > broken. > > repoquery just reports 2 packages, but it should be more...: > python-networkx > python-polybori I comaintain these two. I think python-networkx should not depend on ipython. One example mentions in a comment that it should be run with ipython, but there is no direct dependency. As for python-polybori, the command-line tool ipbori invokes ipython, but by running it in a subshell, not via the library interface. So as long as the command line options haven't changed, python-polybori should be okay, too. Unfortunately, I can't test it. I waited for today's Rawhide update so I could get the new version of ipython. About 2 seconds after the yum transaction finished, X suddenly quit. I rebooted (since there was a new kernel and a new systemd, after all), but now I can't login. Logging in from GDM results in the screen clearing for a fraction of a second, and then GDM starts back up. Likewise, Ctrl-Alt-F2 gives me a TTY. If I attempt to login, the screen clears momentarily, and then the TTY login prompt reappears. Plus, GDM keeps restarting every few seconds, which makes working on a TTY problematic anyway. Something is really broken. As soon as the brokenness gets cleared up, I'll test python-polybori to see if it is okay with the new ipython. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: ipython-0.11 breaking anything :)
On Tue, Aug 2, 2011 at 1:29 PM, Jerry James wrote:
> Unfortunately, I can't test it. I waited for today's Rawhide update
> so I could get the new version of ipython. About 2 seconds after the
> yum transaction finished, X suddenly quit. I rebooted (since there
> was a new kernel and a new systemd, after all), but now I can't login.
> Logging in from GDM results in the screen clearing for a fraction of
> a second, and then GDM starts back up. Likewise, Ctrl-Alt-F2 gives me
> a TTY. If I attempt to login, the screen clears momentarily, and then
> the TTY login prompt reappears. Plus, GDM keeps restarting every few
> seconds, which makes working on a TTY problematic anyway. Something
> is really broken. As soon as the brokenness gets cleared up, I'll
> test python-polybori to see if it is okay with the new ipython.
It looks like the problem is SELinux-related. I did a full relabel to
see if it would clear things up, but it didn't. I can login
successfully after booting with enforcing=0, though. I'm seeing lots
of AVC denials in the logs. Here are the denials I see in
/var/log/messages (with enforcing=0):
[8.206691] type=1400 audit(1312314954.461:3): avc: denied {
dyntransition } for pid=1 comm="systemd"
scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:system_r:init_t:s0 tclass=process
[ 11.777659] type=1400 audit(1312314958.032:4): avc: denied { read
} for pid=572 comm="systemd-sysctl" name="sysctl.conf" dev=dm-1
ino=131521 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_conf_t:s0 tclass=file
[ 11.781152] type=1400 audit(1312314958.035:5): avc: denied { open
} for pid=572 comm="systemd-sysctl" name="sysctl.conf" dev=dm-1
ino=131521 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_conf_t:s0 tclass=file
[ 11.800415] type=1400 audit(1312314958.055:6): avc: denied {
getattr } for pid=572 comm="systemd-sysctl" path="/etc/sysctl.conf"
dev=dm-1 ino=131521 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:system_conf_t:s0 tclass=file
[ 17.387700] type=1400 audit(1312314963.642:7): avc: denied {
relabelto } for pid=663 comm="systemd-tmpfile" name="seats" dev=tmpfs
ino=12579 scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=dir
[ 17.393413] type=1400 audit(1312314963.648:8): avc: denied {
relabelto } for pid=663 comm="systemd-tmpfile" name="sessions"
dev=tmpfs ino=12583 scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=dir
[ 19.280082] type=1400 audit(1312314965.535:9): avc: denied {
unlink } for pid=677 comm="NetworkManager" name="resolv.conf"
dev=dm-1 ino=131244 scontext=system_u:system_r:NetworkManager_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file
[ 19.629917] type=1400 audit(1312314965.884:10): avc: denied {
name_bind } for pid=840 comm="dhclient" src=11807
scontext=system_u:system_r:dhcpc_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
[ 20.125998] type=1400 audit(1312314966.380:11): ac: denied {
rename } for pid=904 comm="Xorg" name="Xorg.0.log" dev=dm-1 ino=392488
scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_log_t:s0 tclass=file
[ 20.130982] type=1400 audit(1312314966.384:12): avc: denied {
unlink } for pid=904 comm="Xorg" name="Xorg.0.log.old" dev=dm-1
ino=392491 scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_log_t:s0 tclass=file
[ 607.234395] type=1400 audit(1312315564.790:13): avc: denied {
read } for pid=1745 comm="sendmail" name="online" dev=sysfs ino=34
scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sysfs_t:s0 tclass=file
[ 607.234488] type=1400 audit(1312315564.790:14): avc: denied {
open } for pid=1745 comm="sendmail" name="online" dev=sysfs ino=34
scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sysfs_t:s0 tclass=file
In addition, looking back farther in the log, I see LOTS of these when
SELinux was in enforcing mode:
avc: denied { sigchld } for pid=1 comm="systemd"
scontext=system_u:system_r:loadkeys_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=process
Also, I can test now, and it looks like python-polybori is broken by
the new ipython. When I try to run ipbori, I get an ipython help
message, followed by this:
[TerminalIPythonApp] Unrecognized flag: '-rcfile'
So ... what? Is --ipython-dir what we should use now?
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 11:06 AM, Richard W.M. Jones wrote: > OTOH including tiny programs that remind people that real religious > belief is nonsense has to be a good thing. On the contrary, biting one's tongue instead of offering off-topic gratuitous insults to fellow Fedorans has to b a good thing. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [antlr3] fix build on other arches
On Fri, Sep 9, 2011 at 11:30 AM, Dan Horák wrote:
> commit ee88cf13670b752fc9fa94f39b1b2e2fe97849c3
> Author: Dan Horák
> Date: Fri Sep 9 19:30:19 2011 +0200
>
> fix build on other arches
>
> antlr3.spec | 15 +--
> 1 files changed, 9 insertions(+), 6 deletions(-)
> ---
> diff --git a/antlr3.spec b/antlr3.spec
> index 48daab3..9e86cca 100644
> --- a/antlr3.spec
> +++ b/antlr3.spec
> @@ -9,7 +9,7 @@
> Summary: ANother Tool for Language Recognition
> Name: antlr3
> Version: %{antlr_version}
> -Release: 14%{?dist}
> +Release: 15%{?dist}
> URL: http://www.antlr.org/
> Source0:
> http://www.antlr.org/download/antlr-%{antlr_version}.tar.gz
> Source1:
> http://www.antlr.org/download/C/libantlr3c-%{antlr_version}.tar.gz
> @@ -203,11 +203,11 @@ popd
> # Build the C runtime
> pushd libantlr3c-%{antlr_version}
>
> -%ifarch x86_64 ppc64
> -%configure --disable-abiflags --enable-debuginfo --enable-64bit
> -%endif
> -%ifarch %{ix86} ppc
> -%configure --disable-abiflags --enable-debuginfo
> +%configure --disable-abiflags --enable-debuginfo \
> +%ifarch x86_64 ppc64 s390x sparc64
> + --enable-64bit
> +%else
> + %{nil}
> %endif
[snip]
FWIW, in the couple of packages I maintain where configure isn't smart
enough to figure out 32- vs. 64-bitness on its own (e.g., csdp), I've
done this to be (hopefully) future-architecture-proof:
if [ %{__isa_bits} = "64" ]; then
magic_command_to_enable_64_bit_build
fi
It might be nice to encapsulate that in an RPM macro so that the above
could read something like this:
%configure --disable-abiflags --enable-debuginfo \
%ifarch64
--enable-64bit
%else
%{nil}
%endif
Regards,
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff III wrote: > Chain building is allowed for rawhide to help get groups of packages > built. The chain-build facility is very useful. But when you've got a chain of 3 packages to build, and the build of the second one fails, then you're done for the day. You can't restart the chain-build, because the first package has already been built. You can't restart the chain-build from the second package, because the already-built first package won't be available to build against until the next repo compose. Is there any way of addressing this that isn't prohibitively expensive? That is, can we either: - make chain-build atomic, so the failure of any build causes all builds in the chain to be marked as failed (allows restarting the chain-build); or - have a buildroot-override kind of functionality, where we can ask that the newly built packages be added to the Rawhide buildroot temporarily, so that the chain-build can be restarted at the failed build? Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20111012 changes
On Wed, Oct 12, 2011 at 7:41 AM, Rawhide Report wrote: > Compose started at Wed Oct 12 08:16:19 UTC 2011 > > Broken deps for x86_64 > -- [snip] > acheck-0.5.1-5.fc17.noarch requires perl(Text::Aspell) [snip] > Updated Packages: [snip] > acheck-0.5.1-5.fc17 > --- > * Tue Oct 11 2011 Peter Robinson - 0.5.1-5 > - Rebuild A mere rebuild isn't going to fix this package. I retired perl-Text-Aspell back in early May [1]. I informed the acheck maintainer (rakesh, CCed) at that time that perl-Text-Aspell was going away. I have never received a response, and acheck has been on the broken deps report ever since. This package needs to be ported to perl-Text-Hunspell or retired. Here are the packages owned by rakesh, with the date of rakesh's last build: Mayavi (2011-01-05) acheck (2009-06-21) acheck-rules (2009-06-17) bunny (2008-10-29) code2html (2009-03-17) coredumper (2009-09-24) cpptest (2010-05-05) ctemplate (2010-05-05) dayplanner (2009-01-15) django-mako (2010-06-01) djvulibre (2010-05-19) dnrd (2008-07-18) dvtm (2009-08-06) enet (2009-12-03) examiner (2009-08-23) flickcurl (2010-05-05) freeimage (never) fuse-zip (2010-01-30) gedit-plugins (2010-09-02) gflags (2010-01-30) ginac (2010-09-07) gnaural (2010-05-04) gnucap (2010-01-13) jed (2010-12-28) libao (2010-09-02) libeXosip2 (never) libkml (2009-04-12) libogg (2009-11-10) libosip2 (never) linphone (2008-12-21) lynis (2010-01-30) nebula (2009-01-16) ntop (2010-05-04) octave (2009-09-23) opencv (2010-01-08) ortp (2009-11-30) pdf2djvu (2010-05-25) perl-Search-Xapian (2010-05-03) php-markdown (2010-05-03) php-oauth (2008-08-23) php-pear-Auth (2010-05-03) php-xmpphp (2010-05-03) pstreams-devel (2010-05-13) python-AppTools (2011-01-05) python-EnthoughtBase (2011-01-05) python-EnvisageCore (2011-01-05) python-EnvisagePlugins (2011-01-05) python-Traits (2011-01-05) python-TraitsBackendQt (2011-01-05) python-TraitsGUI (2011-01-05) python-durus (2010-05-03) python-setupdocs (2011-01-05) ratproxy (2009-08-23) sitecopy (2010-01-16) stardict-dic-hi (2009-02-02) svgalib (2009-08-05) taskcoach (2010-12-28) tinyxml (2011-04-06) txt2rss (2010-01-13) unhide (2010-05-03) up-imapproxy (2010-12-16) uriparser (2010-09-07) xsel (2011-04-06) zile (2010-12-28) I don't see anything since early April, which is consistent with the lack of response to my late April notification of perl-Text-Aspell's imminent demise. Rakesh's last post to this mailing list was in March [2]. Rakesh, are you still around? Do you need some help with your packages? References: [1] http://lists.fedoraproject.org/pipermail/devel/2011-April/150915.html [2] http://lists.fedoraproject.org/pipermail/devel/2011-March/149309.html -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20111012 changes
On Wed, Oct 12, 2011 at 10:12 AM, Tom Callaway wrote: > Actually, I revived perl-Text-Aspell, but I haven't built it yet: > https://bugzilla.redhat.com/show_bug.cgi?id=742759 I see. This isn't exactly an emergency, given how long acheck has been broken, with 0 bug reports. The right thing to do is leave perl-Text-Aspell dead and fix acheck to use perl-Text-Hunspell. But if you really want to go this route, then would you like to take over the F-14, F-15, EPEL-4, EPEL-5, or EPEL-6 branches? I'll happily release them in pkgdb if so. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to update GMP-using packages
How should those of us with gmp-using packages manage updates while the update to GMP 5.x is underway? I've got a handful of updates I want to build for Rawhide at some point, but I don't want to cause problems. Should I wait until the GMP update is done and the packages are all tagged, or go ahead now? If the former, is there an ETA? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
I've got 3 packages languishing in the review queue that I need for a package update. Would someone swap reviews with me for these? https://bugzilla.redhat.com/show_bug.cgi?id=719150 flocq - Formalization of floating point numbers for Coq https://bugzilla.redhat.com/show_bug.cgi?id=719152 gappalib-coq - Coq support library for gappa (requires flocq) https://bugzilla.redhat.com/show_bug.cgi?id=719757 apron - Numerical abstract domain library The first two should be dead easy. From Fedora's point of view, they're just data packages; no libraries or binaries are involved. The third one is a bit complex. I had to tweak a lot of pathnames to match existing Fedora practice, as well as do some violence to the Makefiles to eliminate unused direct shared library dependencies and undefined non-weak symbols. So please swap me for 2 easy and one hard review of your own. :-) Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On Wed, Oct 26, 2011 at 12:50 PM, Thomas Spura wrote: > Do you consider this an easy or a hard one: ;) > espresso - Extensible Simulation Package for Research on Soft matter > https://bugzilla.redhat.com/show_bug.cgi?id=740846 Molecular dynamics simulations! Wow, I suddenly flashed back to grad school. :-) > I'll try to have a look at your hard one, but I have no ocalm > experience yet. So maybe I'll just review your first one - we'll see ;) Well, I have no MPI experience, so I think we're about equal. I'll give it a try. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On Wed, Oct 26, 2011 at 9:18 AM, Jerry James wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=719152 > gappalib-coq - Coq support library for gappa (requires flocq) > > https://bugzilla.redhat.com/show_bug.cgi?id=719757 > apron - Numerical abstract domain library Thomas swapped 1 review with me for the flocq review, but I still need reviews for gappalib-coq (easy) and apron (not so easy). Would anyone like to swap a review or 2 with me for one or both of these? Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
f17-gmp and glibc-2.14.90-13
One of my packages (xemacs) failed the final build in the f17-gmp build target [1], and was marked FTBFS [2]. I see that the f17-gmp builds are now being merged into Rawhide. As I pointed out on that bug, the xemacs build failure was due to building against glibc 2.14.90-13. I don't know the exact cause, but the build is happy again with glibc 2.14.90-15. If other packages in the f17-gmp tag were built against the buggy glibc, we might be merging a bunch of buggy builds into Rawhide. References: [1] https://fedorahosted.org/rel-eng/ticket/4929 [2] https://bugzilla.redhat.com/show_bug.cgi?id=749236 -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Owning /usr/share/icons/hicolor
I need some advice for a package review I'm doing. The package owns all the directories from /usr/share/icons/hicolor down to /usr/share/icons/hicolor/48x48/apps, where it stores its icons. When I objected that these directories were already owned by hicolor-icon-theme, the packager said: "This package does not require hicolor-icon-theme neither implicit nor explecit. Acourding to the Package guidlines (The directory is owned by a package which is not required for your package to function) this package must own these directories." [sic] On my system, with lots of icon-using packages installed, /usr/share/icons/hicolor is owned by 3 packages: hicolor-icon-theme, fedora-logos, and setroubleshoot, so there is precedent to back up the packager in this case. On the other hand, there are gobs of packages with icons below that directory that do NOT own /usr/share/icons/hicolor. I haven't been able to find anything about this issue in the packaging guidelines; https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache doesn't address this issue. Are the fedora-logos and setroubleshoot packages doing it the right way, and other icon-installing packages need to be fixed? Are they doing it the wrong way, and should be fixed themselves? Does ownership of that directory depend on some other feature of the package? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Owning /usr/share/icons/hicolor
On Mon, Oct 31, 2011 at 1:06 PM, Mattias Ellert wrote: > mån 2011-10-31 klockan 19:02 +0100 skrev Till Maas: >> I guess the directory /usr/share/icons/hicolor and the usual >> subdirectories should be owned by the filesystem package. >> >> Regards >> Till > > hicolor-icon-theme is a filesystem package. Apart from a README, a > COPYING, a Changelog and one %ghost it contains one (1) file. > > And 340 directories. > > This is the filesystem package that packages that install icons are > supposed to depend on. > > Mattias That's the answer I needed. Thank you. IMO, this is not clear in the current packaging guidelines. In fact, the icon cache section says: "Note that no dependencies should be added for this." It appears that it is actually talking about not depending on gtk2 or /usr/bin/gtk-update-icon-cache, but that is confusing the issue of depending on hicolor-icon-theme. Could the packaging committee please clarify this issue? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Buildroot override problem
I have 2 new packages. The first one, flocq, has been in F16 testing for 5 days. It is needed to build the second one, gappalib-coq. I go to the BuildRoot override page to submit an override for flocq. After typing in flocq, it offers me "flocq-1.4.0-2.fc16", which is wrong. That version had a mistake in the spec file that renders it unusable. Why doesn't it offer me flocq-1.4.0-3.fc16, which is the version in testing? No matter. I manually edit the requested override to -3 instead of -2. After pushing the button to submit, I get this message: Error: buildroot override for u'flocq-1.4.0-3.fc16' already exists What's with the "u" before the package name? And what does it mean that a buildroot override already exists? This is manifestly untrue, since doing a "fedpkg build" for gappalib-coq results in this (http://koji.fedoraproject.org/koji/taskinfo?taskID=3482805): DEBUG util.py:247: Getting requirements for gappalib-coq-0.16.0-3.fc16.src DEBUG util.py:247: --> coq-8.3pl2-2.fc16.x86_64 DEBUG util.py:247: Error: No Package found for flocq DEBUG util.py:320: Child returncode was: 1 How do I build gappalib-coq against flocq-1.4.0-3? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot override problem
On Thu, Nov 3, 2011 at 9:35 AM, Adam Jackson wrote: > I would guess because it's only considering packages in > -updates-candidate as buildroot override candidates, and -3 is in > -updates-testing. Hmmm. Then I'm stuck until F16 starts taking updates again, it seems. Thanks for the reply. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libedit update in F15 & Rawhide
I just built a new libedit snapshot (20110227) for Rawhide and F-15 to pick up some bug fixes. This rebuild doesn't involve an soname change, but I thought I should give a heads-up anyway, for two reasons. First, I previously did an update to the 20100424 snapshot on February 7, the same day as the mass rebuild. That update added UTF-8 support. Consuming packages may need to be checked for configure options that will let them take advantage of this support. Second, today's build solves an rpmlint warning about an unused direct shared library dependency. Previous builds of libedit linked against libncurses, which is linked against libtinfo. However, libedit really only needs the latter. So if there's anything out there that expects to pick up libncurses by linking against libedit, that will now fail. (I don't think this is possible with the new linker option, but I thought I'd better mention it, just in case.) Packages that directly require libedit in the Rawhide repository: Io-language asterisk ceph chrony firebird-classic-common firebird-superserver ghc-editline kaya libreadline-java link-grammar ntp openssh-clients php-cli php-pecl-xdebug pure uim Let me know if anything breaks. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libedit update needs karma
Hi all, The latest libedit update is CRITPATH, so it needs some karma. The direct consumers of libedit, if my repoquery-fu is up to the task, are the following, with their maintainers listed first, followed by comaintainers: Io-language: limb asterisk: jcollie, fabbione, itamarjp ceph: josef, boodle, jdieter, steve, stingray, tremble, zaniyah chrony: mlichvar firebird (-class-common, -superserver): makowski ghc-editline: s4504kr kaya: s4504kr libedit: kdudka, jcollie, jjames libreadline-java: akurtakov link-grammar: uwog ntp: mlichvar, pertusus openssh: jfch, dwalsh, ellert, lkundrak, mgrepl, mitr, sgrubb, tmraz php (-cli): jorton, rdieter, remi, timj php-pecl-xdebug: remi, cdamian, hubbitus pure: salimma uim: tagoh, i18n-team I'm jjames, and kdudka has already provided karma. Will some of the rest of you please test the update and leave your feedback on the update page? https://admin.fedoraproject.org/updates/libedit-3.0-3.20110227cvs.fc15 Thank you very much, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libedit update needs karma
On Wed, Mar 30, 2011 at 11:32 AM, Adam Williamson wrote: > On Wed, 2011-03-30 at 10:34 -0600, Jerry James wrote: > > Hi all, > > > > The latest libedit update is CRITPATH, so it needs some karma. The > > direct consumers of libedit, if my repoquery-fu is up to the task, are > > the following, with their maintainers listed first, followed by > > comaintainers: > > > > Io-language: limb > > asterisk: jcollie, fabbione, itamarjp > > ceph: josef, boodle, jdieter, steve, stingray, tremble, zaniyah > > chrony: mlichvar > > firebird (-class-common, -superserver): makowski > > ghc-editline: s4504kr > > kaya: s4504kr > > libedit: kdudka, jcollie, jjames > > libreadline-java: akurtakov > > link-grammar: uwog > > ntp: mlichvar, pertusus > > openssh: jfch, dwalsh, ellert, lkundrak, mgrepl, mitr, sgrubb, tmraz > > php (-cli): jorton, rdieter, remi, timj > > php-pecl-xdebug: remi, cdamian, hubbitus > > pure: salimma > > uim: tagoh, i18n-team > > > > I'm jjames, and kdudka has already provided karma. Will some of the > > rest of you please test the update and leave your feedback on the > > update page? > > > > https://admin.fedoraproject.org/updates/libedit-3.0-3.20110227cvs.fc15 > > > > Thank you very much, > > Yeah, handling cases like this where a somewhat 'obscure' library hits > critpath through deps is something I've been thinking about. > package-specific test cases would help, if someone would write them. :) > I think this gets to be critpath via the openssh and possibly ntp > requirements; it may help to know exactly what those apps _do_ with > libedit. But from a critpath perspective, this update is okay as long as > dependent critpath apps still work. > > It would be nice if Bodhi could say 'this update is critical path > because of the following dependency chain:', but I don't know how > practical that is... And, as an aside, that update still only has karma of 2. How do I tell if either of the respondents is a proventester? Is that indicated in the feedback somehow? This is my first experience with a critpath update, so I'm feeling pretty ignorant of how it's supposed to work. If I still need a proventester, what kind of bribe do I need to offer? Regards, -- Jerry "And a gummy worm in every pot" James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package with x86 vector instruction support
I've got a question whose answer I expected to find on one of these pages, but no joy: https://fedoraproject.org/wiki/Architectures https://fedoraproject.org/wiki/Architectures/x86 https://fedoraproject.org/wiki/Architectures/x86-64 I'm packaging a library that does some heavy mathematical computations. The build system tries to cleverly determine whether an Intel CPU with vector instructions is being used. Until I can convince upstream to do this at runtime, I'll need to build the package (a library) for the lowest common denominator. The package checks for MMX, SSE, SSE2, SSE3, and SSSE3. For i686, can I assume MMX? SSE? I believe I can also build an SSE2 version of the library and drop it into /usr/lib/sse2. How about for x86_64? Can I assume SSE2 is available? (I thought I could, but I see that /usr/lib64/sse2 exists on my machine, so now I'm uncertain.) I don't see a /usr/lib64/sse3 or /usr/lib64/ssse3, so I just have to forget those, right? If there is a wiki page that answers these questions, I'd appreciate a pointer. If not, perhaps someone with edit privileges could add the answer to one of the pages listed above. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with x86 vector instruction support
On Wed, Apr 20, 2011 at 3:32 PM, Adam Jackson wrote: > The least capable processor we've gone out of our way to fix things for is > the AMD Geode GX, which has MMX and 3DNow, but is also slightly less than a > proper Pentium Pro in that it doesn't have nopl or cmov. > > However, rpm sets --march=i686, which implies only Pentium Pro and does not > imply MMX or anything newer. Not that I know of anyone who's tried running > Fedora on a bare i686 in recent memory. OK, that's fine. I'll compile without any of the fancy vector instructions for i686, then explicitly pass an -march arg of my own (I see some other packages use -march=pentium4) for the version that will live in /usr/lib/sse2. For x86_64, I'll make sure that SSE3 and SSSE3 support is off and let it do its thing otherwise. Thanks, Ajax! -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package with x86 vector instruction support
On Wed, Apr 20, 2011 at 5:27 PM, Jussi Lehtola wrote: > What package are we talking about? > > There is already at least one package in Fedora which does a similar > thing: ATLAS. It normally automatically tunes itself for the optimal > build flags, so some special tricks have to be done for packaging. > > ATLAS has currently the following versions on Fedora: > > i686: plain, 3dnow, sse, sse2 and sse3 > x86_64: plain and sse2 > > The plain stands for the "atlas" package. I don't know what flags it > uses. I"m trying to update the m4ri package, which now does such tricks. Thanks for the pointer. I'll look at the atlas spec file and see how it's done there. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring perl-Text-Aspell
I would like to invoke the EOL process for perl-Text-Aspell in Rawhide. I will continue to maintain it in Fedora through the F-15 lifecycle, and in EPEL through the EPEL 6 lifecycle. The package is already semi-crippled in EPEL 6, since only the aspell-en and aspell-sk dictionaries are available in RHEL 6. The packages that depend on perl-Text-Aspell in Rawhide are: acheck moodle xinha The packages that depend on perl-Text-Aspell in EPEL 6 are: moodle These packages should be migrated to perl-Text-Hunspell. I will wait 1 week before retiring perl-Text-Aspell in Rawhide to give the maintainers of these packages a chance to decide what to do. If one of you would like to take over maintenance, I will orphan the package instead of retiring it. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retiring perl-Text-Aspell
On Wed, Apr 27, 2011 at 10:00 AM, Jon Ciesla wrote: > Hi, moodle maintainer. > > I just took a quick look through 2.0.2, and I don't see where the limited > Perl present uses perl-text-aspell, so it may just be a hard-coded Requires > that I can drop. Can someone with stronger Perl-Fu take a gander and > confirm this for me, please? > > -J > > -- > in your fear, seek only peace > in your fear, seek only love > > -d. bowie Agreed. It looks like moodle is invoking aspell directly, rather than via perl-Text-Aspell. Somewhat ironically, I created the perl-Text-Aspell package in the first place because it was embedded in the moodle sources, and I was the moodle maintainer at the time (some 4 years ago). You may want to look at changing moodle to use hunspell anyway, due to the limited number of aspell dictionaries available in RHEL 6. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi all, I'd like to swap a couple of reviews. My packages: openfst: https://bugzilla.redhat.com/show_bug.cgi?id=681976 This is the next chunk of a voice recognition stack (CMU Sphinx) I've slowly been pushing into Fedora. csdp: https://bugzilla.redhat.com/show_bug.cgi?id=689039 This is used by some theorem provers, namely coq (which is already in Fedora, and complains bitterly that csdp is missing if you do certain things), and Isabelle (which I hope to see in Fedora sometime before I die). Both are moderately complex packages. Let me know what I can review for you in exchange. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
XEmacs is GPLv3+
I've just built the latest version of XEmacs in Rawhide. The license has changed from GPLv2+ to GPLv3+. I do not expect the change to affect any packages. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15's /usr/include/rpc has disappeared; uncompilable
On Thu, May 5, 2011 at 10:52 AM, Pete Zaitcev wrote: > The question is: what is TI-RPC and where one finds it? > Is it even packaged in Fedora? It's the libtirpc package. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning gbirthday and linbox
On Thu, May 12, 2011 at 6:46 AM, Thomas Spura wrote: > * linbox: > Required for SAGE [1], but FTBFS since a while and the new > version now requires another package, not yet in fedora. This > is hard to maintain, because of many multilib problems/hacks > etc. > (CC'ing givaro maintainer, so he doesn't need to wait for an > upgrade for linbox.) What other package, not yet in Fedora, does the new version require? I've been collecting SAGE-related packages lately, so I might be willing to take this one, too. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning gbirthday and linbox
On Sun, May 15, 2011 at 4:58 AM, Thomas Spura wrote: > The latest version 1.2.0 is now complaining with: > ERROR: Fflas-Ffpack not found! > and I gave up, because linbox is quite hacky. > > Maybe it would be better to use the sage sourcepackage of linbox and > not packaging it from the upstream webpage... > > Greetings, > Thomas I've taken ownership of this package and will see what I can do to get it building again. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning gbirthday and linbox
On Mon, May 16, 2011 at 9:26 AM, Jerry James wrote: > I've taken ownership of this package and will see what I can do to get > it building again. Here's the review request for the new dependency: https://bugzilla.redhat.com/show_bug.cgi?id=705585 Let me know if I can review something in return. It looks like linbox's primary problem is that specific versions of linbox work only with specific versions of givaro, so the two need to be updated in lockstep. I'll talk to the givaro maintainer about that. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request/swap: gnupg-pkcs11-scd and spim
On Thu, May 19, 2011 at 12:25 PM, W. Michael Petullo wrote: > I have two packages that need to be reviewed. I'd be willing to review > two others in exchange. I'll take spim. Can you review one of the following in exchange (your choice)? ocaml-dpt: A SAT solver (used by Isabelle, which I hope to submit some day) https://bugzilla.redhat.com/show_bug.cgi?id=693831 surfer: an algebraic geometry visualizer, used by Singular, a component of SAGE. This package needs surf-geometry, which is currently under review. https://bugzilla.redhat.com/show_bug.cgi?id=700587 TOPCOM: Triangulations Of Point Configurations and Oriented Matroids. This package is used by a couple of SAGE components. https://bugzilla.redhat.com/show_bug.cgi?id=700959 cmuclmtk: Language model trainer for CMU Sphinx speech decoders https://bugzilla.redhat.com/show_bug.cgi?id=705917 python3-cvxopt: A Python Package for Convex Optimization. Fedora already has python-cvxopt, the Python 2 version. Upstream released a python 3 version, so this package is a pretty straightforward alteration of the Python 2 version. https://bugzilla.redhat.com/show_bug.cgi?id=706299 Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: File nauty24r2.tar.gz uploaded to lookaside cache by rdieter
On Fri, May 27, 2011 at 9:35 AM, Rex Dieter wrote: > A file has been added to the lookaside cache for Macaulay2: > > 53f83420491a32e3fe9b03a44c559a89 nauty24r2.tar.gz > -- > scm-commits mailing list > scm-comm...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/scm-commits Given the name and version number, I presume you just uploaded this nauty: http://cs.anu.edu.au/~bdm/nauty/ Given the usage restrictions on nauty (cannot redistribute for profit, cannot use in any application with nontrivial military significance), we can't have that in Fedora, can we? I presumed not, which is why I've been planning to see if I can rip nauty out of polymake (http://polymake.org/) and replace it with bliss (http://www.tcs.hut.fi/Software/bliss/). I haven't gotten around to starting on that yet, though. If you've worked out some kind of unrestricted license with the nauty author, please let me know. He hasn't been responding to my emails. Even in that case, this should go into a separate nauty package, not into Macaulay2, no? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: File nauty24r2.tar.gz uploaded to lookaside cache by rdieter
On Fri, May 27, 2011 at 7:25 PM, Kevin Kofler wrote: > The use of Nauty in Polymake is quite localized. AFAICT, you only have to > touch the following locations: Thanks, Kevin. This is useful information. > You should also unbundle cdd and lrs (i.e. use separate packages for those) > and check that you don't have GPL version conflicts (v2 only vs. v3 only). > (FYI, bliss is GPLv3.) cdd is already available in Fedora as cddlib, and I have a test package of lrs that I'm trying out on my machine before inflicting it on an unsuspecting world. (The lrs package required me to do some violence to the build infrastructure, as the author provided only a very primitive Makefile that builds the binaries, copying the relevant library .o files into each binary. I'm going to write him and offer to give him a nice libtoolized infrastructure, if he wants it.) The GPLv2 vs. GPLv3 issue looks to be a deal breaker, though. Drat. I wonder if I can talk the bliss authors into releasing a GPLv2+ or LGPLv2+ version. It's worth a try. So far I haven't been able to get a response out of the nauty developer, so little chance of a license change there. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap
I need a new package to do an update on another package I maintain: https://bugzilla.redhat.com/show_bug.cgi?id=707819 DSDP: Software for semidefinite programming Let me know what I can review for you in exchange. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
2011/6/5 Reindl Harald : > has anybody an idea for which package i should file a bugreport > for this? i guess "vnstat" is only the postman Maybe. I notice that the bad value is 16777216.00 TiB, which is 2**64 ... on a 64-bit machine. A quick look through the vnstat code shows that it is using floating point arithmetic with rounding to print this value, so that's exactly what I would expect to see if somebody managed to stuff -1 (or any other negative value of small magnitude) into an unsigned 64-bit variable. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
On Mon, Jun 6, 2011 at 9:19 AM, Reindl Harald wrote: > ok - so i should file a bugreport to "vnstat" if i understand you right? I think so, yes. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linux kernel 3.0 + SELinux problem
I'm having some kind of problem with SELinux on the Rawhide 3.0 kernels. The boot process gets stuck loading the SELinux policy over and over again. I get a long series of messages like this for a few minutes: [ timestamp] type=1403 audit(various numbers): policy loaded auid=4294967295 ses=4294967295 Then something times out, I think. It always scrolls by too quickly for me to read it, but it looks like a typical stuck process kernel backtrace. Then I get some variety, and start seeing an endless parade of these: [ timestamp] type=1403 audit(various numbers): policy loaded auid=4294967295 ses=4294967295 [ timestamp] SELinux: 2048 avtab hash slots, 223865 rules. [ timestamp] SELinux: 2048 avtab hash slots, 223865 rules. [ timestamp] SELinux: 9 users, 13 roles, 3663 types, 193 bools, 1 sens, 1024 cats [ timestamp] SELinux: 81 classes, 223865 rules Well, at least I guess it's endless. I've let it go for as long as 10 minutes in the hope that something else would happen. I've tried both kernel 3.0-0.rc1.git0.2 and kernel 3.0-0.rc2.git0.1 and have the same problem with both. I touched /.autorelabel and rebooted with the last 2.6.39 kernel, but that didn't help. The only way I can boot these kernels is to use "selinux=0" on the boot line. I'm seeing this on 2 virtual machines, one x86_64 and one i686, both with fully updated Rawhide as of today and (almost) the same set of packages installed. Both "yum upgrade" and "package-cleanup --orphans" show nothing to do. On both, after booting with selinux=0, "systemctl --failed" lists 0 units. Both started life as F-14 machines, became F-15 Alpha and then F-15 Beta boxes, and were upgraded to Rawhide after the release of F-15. It's possible some configuration got screwed up along the way. If anyone has a theory about what's going on, I'm all ears. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux kernel 3.0 + SELinux problem
On Wed, Jun 8, 2011 at 4:58 PM, Tom London wrote: > See https://bugzilla.redhat.com/show_bug.cgi?id=711015 > > Believe updated systemd is building. Would you believe I scanned the entire list of bugs against the "kernel" component looking for this, and never thought about looking at the "systemd" component? Thanks, Tom! I'll patiently wait for the new systemd. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III wrote: > The 3.0 kernels are not working for me. (A cpu lockup is reporting during > boot.) I am wondering if things are broken for everyone where I should > probably just wait for updates and try again, or if I should get a picture > of the traceback and file a bug? I've been using today's x86_64 Rawhide kernel with no problems. I had to attempt a boot 6 times before I finally got the i686 version off the ground, though. Twice udev segfaulted during boot, and I got some kind of lockup (perhaps what you are seeing) on the other 3 attempts. But the 6th time, it worked great. Unlike Tom's experience, the gdm login screen looked fine for me on both x86_64 and i686. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On Tue, Jun 14, 2011 at 12:25 PM, Matthew Miller wrote: > Are you sure it's not doing an fsck? (There's an open bug for that.) I'm having the same problem with an i686 Rawhide virtual machine (using KVM, on a Fedora 15 x86_64 host). The last few lines I see before the hang are these: Started udev Kernel Device Manager. Starting Stdio Syslog Bridge... Started Stdio Syslog Bridge. Started udev Coldplug all Devices. Starting udev Wait for Complete Device Initialization... [9.542951] EXT4-fs (dm-1): re-mounted. Opts: (null) Started Remount API VFS. Started Remount Root FS. Started Apply Kernel Variables. Starting File System Quota Check... Starting Configure read-only root support... At that point output stops for awhile. The "CPU usage" graph on virt-manager jumps up to about 25% to 30% (eyeballing it), and the "Disk I/O" graph drops to zero. If I leave it like that for awhile to see if anything else will happen, I eventually start seeing messages about CPU stalls. Just in case it is relevant, earlier in the boot, I see this: [2.540079] [ cut here ] [2.541048] WARNING: at arch/x86/mm/highmem_32.c:81 __kunmap_atomic+0x64/0xbd() [2.542788] Hardware name: Bochs [2.543587] Modules linked in: [2.544668] Pid: 123, comm: udevd Not tainted 3.0-0.rc2.git0.1.fc16.i686.PAE #1 [2.546240] Call Trace: [2.547040] [] ? printk+0x2d/0x2f [2.547852] [] warn_slowpath_common+0x7c/0x91 [2.548750] [] ? __kunmap_atomic+0x64/0xbd [2.550188] [] ? __kunmap_atomic+0x64/0xbd [2.551140] [] warn_slowpath_null+0x22/0x24 [2.552109] [] __kunmap_atomic+0x64/0xbd [2.553178] [] unmap_vmas+0x47d/0x570 [2.554534] [] exit_mmap+0x90/0xe0 [2.555625] [] ? trace_hardirqs_off+0xc/0xd [2.556779] [] mmput+0x68/0xd2 [2.557786] [] flush_old_exec+0x427/0x4db [2.558660] [] load_elf_binary+0x2c3/0x1012 [2.559539] [] ? trace_hardirqs_off+0xb/0xd [2.560428] [] ? local_clock+0x32/0x49 [2.561326] [] search_binary_handler+0xb0/0x20e [2.562308] [] ? load_elf_library+0x20d/0x20d [2.563325] [] load_script+0x1b1/0x1cc [2.564262] [] ? trace_hardirqs_off+0xb/0xd [2.565157] [] ? local_clock+0x32/0x49 [2.566036] [] ? lock_release_holdtime.part.8+0x5d/0x63 [2.566938] [] ? trace_hardirqs_off+0xb/0xd [2.567804] [] ? local_clock+0x32/0x49 [2.568692] [] ? lock_release_holdtime.part.8+0x5d/0x63 [2.569579] [] ? lock_release+0x163/0x184 [2.570489] [] search_binary_handler+0xb0/0x20e [2.571445] [] ? bm_status_write+0xa2/0xa2 [2.572363] [] do_execve+0x15f/0x220 [2.573339] [] sys_execve+0x36/0x5d [2.574599] [] ptregs_execve+0x12/0x18 [2.575488] [] ? sysenter_do_call+0x12/0x38 [2.576359] --[end trace ed088c908e3ad521 ]--- Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On Tue, Jun 14, 2011 at 1:16 PM, Jerry James wrote: > I'm having the same problem with an i686 Rawhide virtual machine > (using KVM, on a Fedora 15 x86_64 host). The last few lines I see > before the hang are these: Like Lucas, I can boot with selinux=0. I did so, and upgraded to today's Rawhide packages. Since reinstalling selinux-policy and selinux-policy-targeted has been mentioned, I tried that. Yum reported no errors. On reboot, I got all the way to gdm, but ran into https://bugzilla.redhat.com/show_bug.cgi?id=692573#c10. After making the symbolic link by hand and touching /.autorelabel, I rebooted. I got a hang in the same place. So I rebooted with enforcing=0. I got a hang in the same place. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
On Tue, Jun 14, 2011 at 3:08 PM, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/14/2011 04:42 PM, Jerry James wrote: [snip] >> Like Lucas, I can boot with selinux=0. I did so, and upgraded to >> today's Rawhide packages. Since reinstalling selinux-policy and >> selinux-policy-targeted has been mentioned, I tried that. Yum >> reported no errors. On reboot, I got all the way to gdm, but ran into >> https://bugzilla.redhat.com/show_bug.cgi?id=692573#c10. After making >> the symbolic link by hand and touching /.autorelabel, I rebooted. I >> got a hang in the same place. So I rebooted with enforcing=0. I got >> a hang in the same place. ^ >| > Could you boot in permissive mode and after you boot run | | You mean with enforcing=0? It hangs - Actually, I just got lucky. I've tried rebooting a few more times, since past experience has shown that once in awhile the boot is successful. Since I touched /.autorelabel, I just got a full relabel. Lots and lots of file relabels. And on reboot, it has now hung in the same place once again. (* several reboots later *) Okay, I got a successful rescue shell with "enforcing=0 single". And "restorecon -R -v /var" shows no output. I'll stay in the rescue shell for awhile in case anyone has any other ideas. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system can't finish boot with systemd-28-4.fc16 and kernel-3.0-0.rc2.git0.2.fc16
led to set security context system_u:object_r:var_run_t:s0 for /run: Permission denied [ 14.365093] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:var_t:s0 for /var: Permission denied [ 14.368169] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:var_t:s0 for /var: Permission denied [ 14.375580] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:var_run_t:s0 for /run: Permission denied [ 14.381680] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:tmp_t:s0 for /tmp: Permission denied [ 14.385635] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:tmp_t:s0 for /tmp: Permission denied [ 14.397205] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:tmp_t:s0 for /tmp: Permission denied [ 14.406395] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:tmp_t:s0 for /tmp: Permission denied [ 14.410923] systemd-tmpfiles[612]: Failed to set security context system_u:object_r:tmp_t:s0 for /tmp: Permission denied Started Recreate Volatile Files and Directories. ... When I check the labeling immediately after the boot process finishes, /run, /tmp/, and /var all have the correct labels. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
/dev/pts/ptmx SELinux label
While trying to debug the Rawhide boot lockup on my i686 virtual machine that has been discussed here recently, I've had to do a number of SELinux relabels. Every single time, I see this one: reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0 So restorecon disagrees with whatever creates /dev/pts/ptmx about what type it should be. What does create /dev/pts/ptmx, and which type is right? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
On Mon, Jun 20, 2011 at 11:34 AM, Toshio Kuratomi wrote: > E > frama-c > gappa > ltl2ba > minisat2 I can take these. I already comaintain gappa. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
On Tue, Jun 21, 2011 at 6:12 PM, Toshio Kuratomi wrote: > stp > tex-zfuzz > zenon Since nobody else has spoken for these, I'll take them, but comaintainers would be very welcome. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package drops due to FTBFS
On Thu, Jun 23, 2011 at 9:09 AM, Matt Domsch wrote: > linbox-1.1.7-0.2.svn3214.fc13 [u'631173 NEW'] (build/make) jjames This one needs a new package, fflas-ffpack, which is in the middle of the review process now. Once that package hits the repositories, I need to coordinate with the givaro maintainer (a newer version of givaro is needed), and then we can get linbox builds going again. I have all 3 packages running together successfully on my desktop. I just need a little time to jump through the remaining hoops. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I'm givaro comaintainer ... or am I?
I recently asked the givaro maintainer, D Haley (CCed), for permission to become comaintainer, so I can push out a coordinated update of givaro and linbox. I received a reply stating that this had been done in pkgdb. Today I built new givaro and linbox versions for Rawhide. I would also like to push Fedora 15 updates for the 2 packages. So I built the same new version of givaro, and went to https://admin.fedoraproject.org/updates/ to get a buildroot override for givaro, so I can kick off the linbox build. I got this message: Error: You do not have commit privileges to givaro So I go to pkgdb, and sure enough, it shows my requests for commit access as "Awaiting Review". What's going on here? If I don't have commit privileges (which D Haley assured me were approved), then how did I update givaro for F-15 and Rawhide, and build the new version in both places? If I do, then why can't I get a buildroot override? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'm givaro comaintainer ... or am I?
On Tue, Jul 5, 2011 at 12:57 PM, Michael Schwendt wrote: > You are a member of the Advanced Fedora Packager Group (aka provenpackagers), > which made it possible for you to commit in git. Bodhi, however, doesn't > handle provenpackagers membership in the same way. Wow, my memory must be worse than I thought. When did that happen? I remember applying to become a sponsor, but I have no memory of applying to become a provenpackager. D. Haley, can you try pushing the buttons one more time to grant me commit access to givaro in pkgdb? Thanks. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'm givaro comaintainer ... or am I?
On Tue, Jul 5, 2011 at 3:18 PM, Michael Schwendt wrote: > Google finds these: > > https://fedorahosted.org/fesco/ticket/386 > -> > https://www.redhat.com/archives/fedora-devel-announce/2009-March/msg00010.html Thanks. I remember reading that fedora-devel message, but somehow concluded that I would need to apply for membership, instead of noting that current sponsors would be included in provenpackagers. Well, the upside of this is that I haven't used my provenpackager powers to do any damage ... until today, anyway! -- Jerry James, who plans to continue limiting the damage http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, Jul 6, 2011 at 2:26 PM, Adam Williamson wrote: > http://fedoraproject.org/wiki/AutoReqProv_%28draft%29#Removing_items_from_the_provides_stream_.28post-scan_filtering.29 Or rather https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering, and I can't use that in a couple of similar cases due to the restrictions in the Usage section. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, Jul 6, 2011 at 3:28 PM, Ville Skyttä wrote: > For rpm >= 4.9, there's __provides_exclude and __provides_exclude_from > which I believe don't have those problems. > > http://rpm.org/wiki/PackagerDocs/DependencyGenerator#TweakingDependencyGenerators Oh, excellent! Thanks, Ville. That's F15+, I believe. Off to fix some packages -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Thu, Jul 7, 2011 at 10:54 AM, Toshio Kuratomi wrote: > If you spend the time to figure out how to make these work, the FPC would > love to have the Guidelines that deal with Filtering updated. There's > a start of a draft linked from this ticket: > > https://fedorahosted.org/fpc/ticket/76 > > but it's stuck because we need someone with enough experience with/knowledge > of the new implementation to finish up questions in the draft. > > -Toshio Some of the questions were answered by a previous respondent, and I just added a bit more information to the ticket from what little I've learned so far. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I'll take auto-destdir
The package auto-destdir was recently orphaned due to a maintainer that didn't sign the new agreement. One of my packages BRs it. I tried to take it myself in pkgdb, but wound up as comaintainer to the Orphan maintainer instead. If somebody with privileges would assign that package to me, I'd appreciate it. I'll take all of the branches. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Buildroot broken? (iproute)
I can't build for Rawhide today. Here's an example: http://koji.fedoraproject.org/koji/getfile?taskID=3191106&name=root.log Here's an excerpt: DEBUG backend.py:739: ['/usr/bin/yum', '--installroot', '/var/lib/mock/dist-f16-build-1097005-168601/root/', 'groupinstall', 'srpm-build'] DEBUG util.py:284: Executing command: ['/usr/bin/yum', '--installroot', '/var/lib/mock/dist-f16-build-1097005-168601/root/', 'groupinstall', 'srpm-build'] DEBUG util.py:250: Ignored option -c (probably due to merging -yc != -y -c) DEBUG util.py:250: Error: Package: iproute-2.6.39-1.fc16.x86_64 (build) DEBUG util.py:250: Requires: libxtables.so.5()(64bit) DEBUG util.py:250: You could try using --skip-broken to work around the problem DEBUG util.py:250: You could try running: rpm -Va --nofiles --nodigest DEBUG util.py:323: Child returncode was: 1 -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'll take auto-destdir
On Thu, Jul 7, 2011 at 2:22 PM, Jerry James wrote: > The package auto-destdir was recently orphaned due to a maintainer > that didn't sign the new agreement. One of my packages BRs it. I > tried to take it myself in pkgdb, but wound up as comaintainer to the > Orphan maintainer instead. If somebody with privileges would assign > that package to me, I'd appreciate it. I'll take all of the branches. Ping. Interestingly, this package was NOT on the list of orphan packages to be dropped from Fedora that was just sent to the list. Is it some kind of weird zombie state? I still don't see the button that would let me take ownership. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'll take auto-destdir
On Tue, Jul 12, 2011 at 2:12 PM, Toshio Kuratomi wrote: > Sorry I didn't see this at first. I've made you owner of all the branches. Great. Thanks, Toshio. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Sun, Feb 7, 2010 at 6:16 AM, Jiri Moskovcak wrote: > - it actually does work, but it's bug detection/analyse is too general for > some apps, this is something we know about and it's not in our powers to fix > (it's not even considered a bug). This is actually the reason why is ABRT > extendible by plugins and every devel who maintains some bigger app can > write it's own abrt plugin to make the reports to suit his needs. If devel > doesn't want to get ABRT reports at all, he can always send me an email and > it can be added to ABRT blacklist. Where can information about the plugin API be found? The abrt-plugins man page has very little information. It basically just says to read PLUGINS-HOWTO "in the documentation directory". Which documentation directory is that? I don't see such a file in any of the abrt-* packages. (I expected to find it in abrt-devel, BTW. That package contains only 2 symlinks. Where are the header files? Are they not needed by plugin authors?) Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Comaintainers or maintainers sought
I changed jobs about a year ago and, as a result, no longer use a number of packages that I maintain. (No more Java programming for me; I'm a C coder now, with a little bit of Common Lisp thrown in just to keep things interesting.) It would be good to have somebody who actually uses these packages either maintain or comaintain them. I won't orphan them if nobody is interested; I'll do my best to keep maintaining them. If you are interested in comaintaining, just apply for permission in pkgdb. If you would like to maintain, let me know which packages and I'll orphan them so you can pick them up. In that case, also let me know if you want me to stay on as comaintainer. (I'm happy to answer questions even if I don't comaintain.) 1. Findbugs packages: new releases about every 4-5 months. We're in a long dry spell now leading up to a massively revamped 2.0. eclipse-findbugs findbugs findbugs-bcel findbugs-contrib (actually a separate project) jFormatString (no activity since initial October 2008 release) jcip-annotations (almost no activity since 2006) jsr-305 Also, it would be good to package http://mojo.codehaus.org/findbugs-maven-plugin/. 2. PMD packages: new releases about every 1-2 months. We're in a long dry spell now leading up to a massively revamped 5.0. emacs-common-pmd (upstream appears dead) pmd Also, it would be good to package more of these: http://pmd.sourceforge.net/integrations.html (the maven2 plugin is already packaged, just not owned by me) 3. Other packages idw-gpl: this was originally needed by findbugs, but isn't anymore. Repoquery says that nothing is using it, so I should probably orphan this package. latexmk: I don't use LaTeX anymore. This was my first package (*sniff*). perl-Text-Aspell: last new version was released in Sep 2007. This is required by acheck, moodle, perl-Text-SpellChecker, and xinha. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F16: dual monitor woes (nouveau)
[ 1133.765] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.765] drmOpenDevice: node name is /dev/dri/card5 [ 1133.769] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.769] drmOpenDevice: node name is /dev/dri/card6 [ 1133.773] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.773] drmOpenDevice: node name is /dev/dri/card7 [ 1133.777] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.777] drmOpenDevice: node name is /dev/dri/card8 [ 1133.780] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.780] drmOpenDevice: node name is /dev/dri/card9 [ 1133.784] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.784] drmOpenDevice: node name is /dev/dri/card10 [ 1133.788] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.788] drmOpenDevice: node name is /dev/dri/card11 [ 1133.792] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.792] drmOpenDevice: node name is /dev/dri/card12 [ 1133.796] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.796] drmOpenDevice: node name is /dev/dri/card13 [ 1133.800] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.800] drmOpenDevice: node name is /dev/dri/card14 [ 1133.804] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.804] drmOpenDevice: node name is /dev/dri/card15 [ 1133.808] drmOpenByBusid: drmOpenMinor returns -1 [ 1133.808] drmOpenDevice: node name is /dev/dri/card0 [ 1133.814] drmOpenDevice: node name is /dev/dri/card0 [ 1133.818] drmOpenDevice: node name is /dev/dri/card1 [ 1133.822] drmOpenDevice: node name is /dev/dri/card2 [ 1133.825] drmOpenDevice: node name is /dev/dri/card3 [ 1133.829] drmOpenDevice: node name is /dev/dri/card4 [ 1133.833] drmOpenDevice: node name is /dev/dri/card5 [ 1133.837] drmOpenDevice: node name is /dev/dri/card6 [ 1133.841] drmOpenDevice: node name is /dev/dri/card7 [ 1133.845] drmOpenDevice: node name is /dev/dri/card8 [ 1133.849] drmOpenDevice: node name is /dev/dri/card9 [ 1133.853] drmOpenDevice: node name is /dev/dri/card10 [ 1133.857] drmOpenDevice: node name is /dev/dri/card11 [ 1133.861] drmOpenDevice: node name is /dev/dri/card12 [ 1133.865] drmOpenDevice: node name is /dev/dri/card13 [ 1133.869] drmOpenDevice: node name is /dev/dri/card14 [ 1133.873] drmOpenDevice: node name is /dev/dri/card15 [ 1133.877] (EE) [drm] failed to open device [ 1133.877] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so Does anybody have any clue what's going on here? Thanks in advance. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: dual monitor woes (nouveau)
On Fri, Nov 11, 2011 at 1:03 PM, Adam Williamson wrote: > That's https://bugzilla.redhat.com/show_bug.cgi?id=725219 . Ah, thanks. > Another option is just to disconnect one of the monitors for > installation and plug it back in when you're done. Well, the damage has been done already. :-) > You need to remove 'nomodeset' from the kernel parameters. Argh, of course! And here I was proud of myself for remembering to delete /etc/X11/xorg.conf. Thanks, Adam, you just made my day. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Is anyone willing to swap a couple of reviews? I need reviews for: cryptominisat: https://bugzilla.redhat.com/show_bug.cgi?id=721174 In spite of the name, there's nothing cryptographic about this package. The author thinks it would be a useful tool for cryptographers, but it is just another SAT solver. This is a new dependency for stp, which I would like to upgrade. polybori: https://bugzilla.redhat.com/show_bug.cgi?id=742388 This is a package rename. The current package, python-polybori, mixes the C++ and python interfaces into a single package. This rename separates the C++ and python interfaces into separate packages. Thanks! -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning expatmm
I have orphaned expatmm. I don't use it anymore, and nothing in Fedora depends on it. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: On F16 and F17 I am seeing lots of apps requiring access to /sys/devices/system/cpu/online
On Fri, Dec 2, 2011 at 11:46 AM, Daniel J Walsh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Anyone know what library is causing this?
>
> type=AVC msg=audit(1322851411.945:2185): avc: denied { read } for
> pid=1499 comm="dbus-daemon" name="online" dev=sysfs ino=34
> scontext=staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:sysfs_t:s0 tclass=file
> type=PATH msg=audit(1322851411.945:2185): item=0
> name="/sys/devices/system/cpu/online" inode=34 dev=00:10 mode=0100444
> ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sysfs_t:s0
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk7ZHQ8ACgkQrlYvE4MpobPCTACghScyiL/pEuYf8vSocaKj+nHV
> vKUAoJ5bRMYMLT66hK33Qw2+3lCoL+IH
> =/7kR
> -END PGP SIGNATURE-
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
$ strings /lib64/libc.so.6 | grep -F cpu/online
/sys/devices/system/cpu/online
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
DWARF 4
Are there known obstacles in the way of replacing -g with "-gdwarf-4
-fvar-tracking-assignments" in our %{optflags}? I'm eager to be rid
of gdb telling me that the one value I really have to know to diagnose
a crash has been optimized away. Are there bits of the toolchain that
can't handle DWARF 4? Will debuginfo grow significantly in size?
Just curious, because I've taken to use -gdwarf-4
-fvar-tracking-assignments in the projects I work on for my employer.
I haven't had a problem yet, and just wondered if there's a brick wall
up ahead somewhere...
Thanks,
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
I need reviews for the following: ocaml-dpt https://bugzilla.redhat.com/show_bug.cgi?id=693831 This is used by the theorem prover Isabelle, which I still hope to see in Fedora some day. polybori https://bugzilla.redhat.com/show_bug.cgi?id=742388 This is a package rename review. The original package, python-polybori, ships the C++ and Python interfaces in the same package. The package is being renamed to facilitate splitting the C++ and Python interfaces into separate packages. gap https://bugzilla.redhat.com/show_bug.cgi?id=756635 This is one of the components of SAGE. The GAP "packages" will have to be handled separately, as they have a multitude of upstreams, and there are licensing questions about many of them. I have packaged one (https://bugzilla.redhat.com/show_bug.cgi?id=769450), but we need GAP itself first Let me know what I can review for you. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On Wed, Dec 21, 2011 at 3:20 AM, Scott Tsai wrote: > I'll trade you js-of-ocaml: > https://bugzilla.redhat.com/show_bug.cgi?id=767042 > for gap. Sounds great. Thanks, Scott. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
On Wed, Dec 21, 2011 at 3:45 AM, Brendan Jones wrote: > On 12/20/2011 10:27 PM, Jerry James wrote: > >> >> polybori >> https://bugzilla.redhat.com/show_bug.cgi?id=742388 >> This is a package rename review. The original package, >> python-polybori, ships the C++ and Python interfaces in the same >> package. The package is being renamed to facilitate splitting the C++ >> and Python interfaces into separate packages. >> > > If interested I'll take this for: > > https://bugzilla.redhat.com/show_bug.cgi?id=767583 > python-poppler-qt4 - Qt4 poppler bindings > > regards, > > Brendan I'm interested! Thanks, Brendan. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OCaml 3.12.1 (was 3.12.0) in Rawhide
On Fri, Jan 6, 2012 at 11:16 AM, Richard W.M. Jones wrote: > Below are the ones that I HAVEN'T done. Feel free to jump in! > However please check the upstream for each package to see if there is > a new version, and if so, update to it. > > ocaml-apron-0.9.10-4.fc17 > ocaml-ocamlgraph-1.8.1-1.fc17 > coq These 3 are on my list. I'm attempting to do an ordered rebuild of my packages. Wish me luck. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package: DSDP-5.8-4.fc17 Tag: f17-rebuild Status: complete Built by: ausil
On Thu, Jan 12, 2012 at 1:25 PM, Fedora Koji Build System wrote: > Package: DSDP-5.8-4.fc17 > Tag: f17-rebuild > Status: complete > Built by: ausil > ID: 283023 > Started: Thu, 12 Jan 2012 20:20:16 UTC > Finished: Thu, 12 Jan 2012 20:24:38 UTC > Changelog: > * Thu Jan 12 2012 Fedora Release Engineering > - 5.8-4 > - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild > > * Sat Jan 07 2012 Jerry James - 5.8-3 > - Rebuild for GCC 4.7 Wait, wait, wait. I thought we were told that we could rebuild our own packages, then those that weren't rebuilt would be part of the mass rebuild. So why is the mass rebuild rebuilding packages that I already rebuilt? Did I waste my time rebuilding all of my packages over the last week? Also, I've got 2 packages that are still failing to build. Can I exempt them from the mass rebuild, since I know those builds will fail anyway? (I'm working on it) -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
On Thu, Jan 26, 2012 at 4:49 PM, Volker Froehlich wrote: > Hello, > > I'd like to get ahead with wxpropgrid, as it blocks another package. > > https://bugzilla.redhat.com/show_bug.cgi?id=767082 > > Does somebody like to swap reviews? > > Thanks in advance, > > Volker Well, it would make sense for me to jump in and help out, wouldn't it? :-) If you'd like to swap another package with me, I have these waiting for review. Take your pick: ocaml-dpt: https://bugzilla.redhat.com/show_bug.cgi?id=693831 TOPCOM: https://bugzilla.redhat.com/show_bug.cgi?id=700959 lrslib: https://bugzilla.redhat.com/show_bug.cgi?id=723752 why3: https://bugzilla.redhat.com/show_bug.cgi?id=768538 meataxe: https://bugzilla.redhat.com/show_bug.cgi?id=783015 Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
On Tue, Jan 31, 2012 at 9:32 AM, Mattia Verga wrote: > Hello all, > Is there any problem with koji in these days? > I'm getting random koji problems while building packages like > http://koji.fedoraproject.org/koji/getfile?taskID=3748927&name=build.log > > Yesterday was the same, however today, just a couple of minutes before the > error I posted in link, I succesfully build on master... An empty build log like that tells you that something went wrong with installing the BRs. Look at root.log instead. In your case, you fell victim to the gstreamer-plugins-bad-free breakage that brought my building to a halt yesterday as well. It was finally rebuilt for Rawhide a couple of hours ago by Rex Dieter (thanks, Rex!); see http://koji.fedoraproject.org/koji/packageinfo?packageID=9859. However, the new libvpx is *still* in the Fedora 16 build root overrides, which is breaking package builds. Spot, if you're done rebuilding gstreamer-plugins-bad-free, could you expire that override, please? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SELinux-related Rawhide breakage today
After installing today's Rawhide updates on an x86_64 VM, I started having troubles running programs. Nothing linked with libselinux.so.1 could actually open that library; the programs were getting EACCESS on the attempt. I figured I needed to do a relabel, but since restorecon is linked with libselinux.so.1, . I touched /.autorelabel and rebooted. The system couldn't even shut down, so I had to do a sync and a forced shutoff. When the system came back up, it immediately started complaining about lots of programs that were unable to load libcrypt. So I forced it off again and rebooted with enforcing=0. That worked, but skipped the relabeling step! I got a root shell and ran restorecon by hand to relabel. The only file that got relabeled was this, which looks wrong: restorecon reset /lib64/libproc-3.2.8.so context system_u:object_r:lib_t:s0->system_u:object_r:default_t:s0 Is something broken in SELinux land today? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
On Tue, Jan 31, 2012 at 9:56 AM, Mattia Verga wrote: > I see I didn't thought to look at root.log. So I will wait some day to > retry the build. > Thanks for the tip! You shouldn't have to wait, for Rawhide at least. The fixed package is in the build root now. My rebuild that was similarly blocked yesterday succeeded when I tried again about half an hour ago. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Request for trident
On Tue, Jan 31, 2012 at 1:22 PM, Sven Baus wrote:
> Hello everybody,
>
> I'm trying to build a trident package
> (https://bugzilla.redhat.com/show_bug.cgi?id=771480) , because it is
> needed by my main review request for tv-browser
> (https://bugzilla.redhat.com/show_bug.cgi?id=754246)
>
> I ran into some problems building the jar from ant:
> "[javac]
> /home/makerpm/rpmbuild/BUILD/trident-1.3/src/org/pushingpixels/trident/android/AndroidPropertyInterpolators.java:37:
> package android.graphics does not exist
> [javac] import android.graphics.*;
> [javac] ^"
>
> Does anybody know, how to fix this? I'm a bit out of ideas ;).
Since you are not building for the Android platform, I suggest adding
this to %prep:
rm -fr src/org/pushingpixels/trident/android
You'll also need to BR eclipse-swt and add %{_libdir}/java/swt.jar to
the classpath. Also, set jdk.home in build.properties to something
reasonable, say /usr/lib/jvm/java. Regards,
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
On Wed, Feb 1, 2012 at 9:46 AM, Rex Dieter wrote: > Jerry James wrote: > >> On Tue, Jan 31, 2012 at 12:42 PM, Tom Callaway >> wrote: >>> No, because xulrunner needs it to rebuild. Why is libvpx breaking >>> package builds? Almost nothing should depend on it. The plan is for the >>> libvpx update to go out at the same time as the xulrunner update. >> >> Sorry, got busy with Real Life and couldn't get back to this thread >> yesterday. In my case, it is because of this chain of dependencies: >> >> PyQt4-devel => >> PyQt4 (via libQtWebKit) => >> qtwebkit (via libQtLocation & libQtSensors) => >> qt-mobility (via libgstphotography) => >> gstreamer-plugins-bad-free => >> libvpx > > Which buildroot? rawhide? f16? (As far as I recall, rawhide, f16 should > have the new libvpx, gstreamer-plugins-bad-free tagged properly) Yes, the buildroots are both fine now. Thanks for fixing them. I was just responding to spot's apparent surprise that an updated libvpx in the buildroot should have broken package building for other people. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap
Is anyone up for a review swap? I need a review for lrslib: https://bugzilla.redhat.com/show_bug.cgi?id=723752. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
This is not the power switch you are looking for
Fallout from usrmove, perhaps? I tried to shutdown a VM running Rawhide: Clicked on the power button symbol in the upper right hand corner of the GDM desktop and chose "Power Off". Nothing. Clicked it again, just in case. Nothing. Okay, so Ctrl-Alt-F3, login as root, and then this: [root@jerry-rawhide32 ~]# shutdown -P now Unknown operation now [root@jerry-rawhide32 ~]# man shutdown Nope, I had the syntax right. Well, there's a poweroff command, right? Haven't used it for awhile... [root@jerry-rawhide32 ~]# man poweroff man: can't open /usr/share/man/halt.8: No such file or directory [root@jerry-rawhide32 ~]# man halt Okay, that worked. I don't need to pass any arguments, just plain poweroff. Cool. [root@jerry-rawhide32 ~]# poweroff UNIT LOAD ACTIVE SUB JOB DESCRIPTION proc-sys...misc.automount loaded active waiting Arbitrary Executable File ... followed by several more pages of systemd output piped to less. Okay, I give up. How am I supposed to turn this thing off? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This is not the power switch you are looking for
On Tue, Feb 7, 2012 at 3:06 PM, Michal Schmidt wrote: > A bad systemd build due to a binutils bug: > https://bugzilla.redhat.com/show_bug.cgi?id=788107 Thank you very much for the link. It'll be interesting to see if the man page problem is related. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This is not the power switch you are looking for
On Tue, Feb 7, 2012 at 3:51 PM, Michal Schmidt wrote: > You mean this error message?: > man: can't open /usr/share/man/halt.8: No such file or directory Yes. > > No, that's not related to the binutils bug. > The error seems harmless, because it does open the expected > man page afterwards. I'm not sure what you mean by that; "man poweroff" only shows the error message. I just noticed from the error message that I should try "man halt" instead. You're right that it's not related, though. $ zcat /usr/share/man/man8/poweroff.8.gz .so halt.8 That should be: .so man8/halt.8 I'll file a bug. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? -> about the future
On Fri, Feb 10, 2012 at 11:52 AM, Jef Spaleta wrote: > On Fri, Feb 10, 2012 at 9:17 AM, Reindl Harald wrote: >>> What is the exact symptoms encapsulated in "not shutdown cleanly?" >> >> "can not connect to systembus" or some "connection refused" >> somewhat in this direction > > apologizes to the list. I meant to ask Adam that in private email, so > I could have a reasonable technical discussion devoid of overly > emotional responses which seem to be radiating more heat than light at > the moment. Some light may yet be generated. When I've had this happen, the error has been "Failed to get D-Bus connection". If I ever see this again, I'll be sure to take better notes -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wed, Feb 29, 2012 at 4:05 AM, Tore Anderson wrote: > However, this is not the only problem related to IPv6. I just tested the > F17 Alpha Live CD, and one particular egregious issue is that by > default, the toggle «Require IPv4 addressing for this connection to > complete» is enabled in NM's connection profiles. This essentially means > that IPv6-only networks are not supported out by default. If I try to > connect the F17 Alpha to an IPv6-only WLAN (not making any changes to the > default settings), the connection is successfully activated and remains > fully functional for about 40 seconds, at which point NM gives up on > waiting for replies from the non-existent DHCPv4 server. Then the entire > connection is torn down, IPv6 included, before the process starts over > again in a seemingly endless loop. Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120229 changes
On Wed, Feb 29, 2012 at 10:15 AM, Rawhide Report wrote: > [emacs] > 1:emacs-24.0.94-1.fc18.x86_64 requires libMagickWand.so.4()(64bit) > 1:emacs-24.0.94-1.fc18.x86_64 requires libMagickCore.so.4()(64bit) A couple of my packages failed to be "Rebuilt for c++ ABI breakage" because they BR emacs, and it was broken in the build root. Will packages that failed the rebuild due to this breakage be rebuilt automatically once emacs is fixed, or are we maintainers on the hook for that? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gmp-ecm license change
The license of gmp-ecm is currently "LGPLv2+ and GPLv2+". In Rawhide and F17 only, the main package will now be "GPLv3+", and there is a new -libs subpackage that is "LGPLv3+". I don't expect this to cause any problems as repoquery shows that nothing depends on this package. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Milmeister Mass-Orphaning Request
On Tue, Nov 16, 2010 at 11:12 AM, Richard W.M. Jones wrote: > which are these one ... > > https://admin.fedoraproject.org/pkgdb/users/packages/gemi > > I will take ocaml* and unison*. > > Rich. I'm already comaintainer on clisp and ecl. I can take those if nobody else has a burning desire to do so. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New gtk-vnc slower?
I have a collection of virtual machines that I use to test cross-platform compatibility of some code I'm developing. Today, the virtual machine I was working on kept getting slower and slower whenever a window refresh was needed. It got to the point that refreshing a terminal window was taking nearly half a second per line. My eyes could easily track the refresh going on. Moving a window was impossible, as I could see the entire window being redrawn, pixel by pixel, and it would just keep going long after I had released the mouse. Keys were repeating right and left, probably because of a sequence like . I shut everything down, logged out, and even rebooted, to see if it was some weird behavior caused by a recent update that had only partly taken effect. When I started my VM back up, it was very snappy. But then, over time, it got a little slower and a little slower, until eventually I was back to watching refreshes happen line by line again. This never happened before today. I looked through the recent updates my machine has received. All I can see that might be relevant was an update to gtk-vnc-0.4.2-1.fc14.x86_64. The machine in question is a quad-core Intel with 8GB of RAM and an Nvidia video card of some kind. (Sorry, should have checked which one before leaving work.) The host is fine; it's just the virtual machines I open with virt-manager that are affected. I tried several, and they're all behaving like this today, which argues for the problem being on the host side. Is anybody else seeing this? Is there any other component besides gtk-vnc that I should examine as a possible source of the slowdown? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all of my packages :(
On Thu, Dec 16, 2010 at 10:55 AM, Toshio Kuratomi wrote: > The following packages have been orphaned in Fedora 13, 14, and devel: [snip] > latexmk -- A make-like utility for LaTeX files Er, hold on there. I'm the maintainer for that package; mef was comaintainer. Anyway, it looks like it is not orphaned in packagedb, so I guess we're okay. More comaintainers are welcome if anyone else would like to pile on. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AF_INET6 sockets and IPv4 connections, etc.
On Tue, Jan 11, 2011 at 1:46 PM, Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > so how can I tell in a couple of lines of code if the connection will > result in IPv4? > I'm not entirely sure what you're talking about. What software are you attempting to patch, for example? But anyway, is the IN6_IS_ADDR_V4MAPPED macro in what you are looking for? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning pmd
Hello all, I haven't used pmd for almost 2 years now. I think it is time to have somebody who does use it take over maintainership. There are no open bugs at this time. Also, I intended to package pmd-eclipse-plugin at some point, but never got around to it. Let me know if you want this package, and I'll release it in pkgdb. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning pmd
On Mon, Jan 31, 2011 at 8:47 AM, Jerry James wrote: > I haven't used pmd for almost 2 years now. I think it is time to have > somebody who does use it take over maintainership. There are no open > bugs at this time. I'm afraid I have to force the issue. I just picked up several orphaned packages, and I really need to let this one go. I have orphaned: emacs-common-pmd pmd In addition, I am also orphaning this package: idw-gpl which was needed for findbugs at one time, but is no longer necessary. There are no open bugs against any of these packages. Please give them a good home. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
On Mon, Feb 7, 2011 at 1:59 PM, Bill Nottingham wrote: > Orphan bigloo >comaintained by: salimma > > Orphan ffcall >comaintained by: salimma > I need these two to work, so I can either maintain or comaintain if the existing comaintainer would like me to. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
