Re: /usr/bin/sync hangs up if called in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/15/2012 10:27 PM, Pedro Francisco wrote: On Sun, Apr 15, 2012 at 12:11 PM, Kalev Lember kalevlem...@gmail.com wrote: On 04/15/2012 01:50 PM, Kalev Lember wrote: On 04/15/2012 10:18 AM, Joachim Backes wrote: Calling /usr/bin/sync manually will hang up. System continues to operate and reboots normally. This happens with kernel-3.3.1-5.fc17, kernel-3.3.2-1.fc17 and glibc-2.15-32.fc17.x86_64. Anybody sees this too? I just ran into the same thing. Both sync and echo 3 /proc/sys/vm/drop_caches commands hang for me on F17. Did some more poking around and killing the fusermount process appears to help. Same here; suspend and hibernate also don't work since I suppose they call sync. Bug report here, opened by the original poster: https://bugzilla.redhat.com/show_bug.cgi?id=812588 . Could be related to bug 808795: https://bugzilla.redhat.com/show_bug.cgi?id=808795 Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+L6poACgkQ6YSQoMYUY95AZgCgh7WnQIIrn13N2xLolng5Gv2F 4Q0AoLKm8Xtllpj+2QTKa8b8R8LxjTw7 =uMTO -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: wvdial crash
On Mon, Apr 16, 2012 at 2:28 AM, R P Herrold herr...@owlriver.com wrote: On Sun, 15 Apr 2012, Pedro Francisco wrote: wvdial is crashing when trying to start a connection. Modem = /dev/ttyACM0. $ sudo wvdial -- WvDial: Internet dialer version 1.61 -- Cannot get information for serial port. this looks ominous ... is there a SElinux intercept from some need to re-label? (I built and installed a fresh WVdial from RawHide last week, and so the package itself seems working) I believe Cannot get information for serial port. appeared on F16/F15 (can't recall) and on F15/F16 it would work well. SEapplet showed nothing. I did get curious with warning: .dynamic section for /lib/libwvstreams.so.4.6 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /lib/libwvutils.so.4.6 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /lib/libwvbase.so.4.6 is not at the expected address (wrong library or version mismatch?) found in one of the bug's attachments -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-17 Branched report: 20120416 changes
Compose started at Mon Apr 16 08:15:03 UTC 2012 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [ale] ale-0.9.0.3-6.fc17.x86_64 requires libMagickCore.so.4()(64bit) [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [cuneiform] cuneiform-1.1.0-6.fc17.i686 requires libMagick++.so.4 cuneiform-1.1.0-6.fc17.x86_64 requires libMagick++.so.4()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dmapd] dmapd-0.0.47-2.fc17.i686 requires libMagickWand.so.4 dmapd-0.0.47-2.fc17.i686 requires libMagickCore.so.4 dmapd-0.0.47-2.fc17.x86_64 requires libMagickWand.so.4()(64bit) dmapd-0.0.47-2.fc17.x86_64 requires libMagickCore.so.4()(64bit) [dogtag-pki] dogtag-pki-9.0.0-10.fc17.noarch requires pki-util-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-util = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-tks = 0:9.0.9 dogtag-pki-9.0.0-10.fc17.noarch requires pki-symkey = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-silent = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-setup = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-selinux = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-ocsp = 0:9.0.9 dogtag-pki-9.0.0-10.fc17.noarch requires pki-native-tools = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-kra = 0:9.0.10 dogtag-pki-9.0.0-10.fc17.noarch requires pki-java-tools-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-java-tools = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-common-javadoc = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-common = 0:9.0.18 dogtag-pki-9.0.0-10.fc17.noarch requires pki-ca = 0:9.0.18 [drawtiming] drawtiming-0.7.1-5.fc17.x86_64 requires libMagickCore.so.4()(64bit) drawtiming-0.7.1-5.fc17.x86_64 requires libMagick++.so.4()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [dx] dx-4.4.4-21.fc17.x86_64 requires libMagickCore.so.4()(64bit) dx-libs-4.4.4-21.fc17.i686 requires libMagickCore.so.4 dx-libs-4.4.4-21.fc17.x86_64 requires libMagickCore.so.4()(64bit) [egoboo] egoboo-2.7.5-11.fc17.x86_64 requires libenet-1.2.1.so()(64bit) [entangle] entangle-0.3.2-1.fc17.x86_64 requires libgexiv2.so.0()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-gucharmap] ibus-gucharmap-1.4.0-4.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-2.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-2.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [imageinfo] imageinfo-0.05-14.fc17.x86_64 requires libMagickCore.so.4()(64bit) [inkscape] inkscape-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) [jboss-as] jboss-as-7.1.0-2.fc17.noarch requires slf4j-jboss-logmanager [k3d] k3d-0.8.0.2-6.fc17.i686 requires libMagickCore.so.4 k3d-0.8.0.2-6.fc17.i686 requires libMagick++.so.4 k3d-0.8.0.2-6.fc17.x86_64 requires libMagickCore.so.4()(64bit) k3d-0.8.0.2-6.fc17.x86_64 requires libMagick++.so.4()(64bit) [kxstitch] kxstitch-0.8.4.1-8.fc17.x86_64 requires libMagickCore.so.4()(64bit)
Re: python discrepancies
On Mon, Apr 16, 2012 at 6:30 AM, Rob Healey robheal...@gmail.com wrote: Greetings: The only part that I had in question was why were there in Python2.7, the use of /usr/lib64... In Python3.3, it always used /usr/lib ... Why would Python3.3 which I did compile from source not see that I have a 64bit computer and use it instead for the directories??? Because multilib is not used by upstream directly and therefore needs be patched in in any build: http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob;f=python-3.2.3-lib64.patch Greetings, Tom -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Launching WINE causes screen flicker in Screen#2 on a dual-head setup..
On Sun, 2012-04-15 at 11:04 -0300, Fernando Cassia wrote: When I launch any win32 app under WINE the screen flickers for about 2 seconds, but only on the 2nd display. Then it returns to normal. As soon as the win32 app launches, I can work with it just fine, move it between displays, and the screen doesnt flicker anymore. Just a minor anonyance but perhaps there's something WINE is doing that shouldn't be happening? Wine appears to be using the RANDR 1.1 interface, which is not multihead-aware, and xserver's internal emulation of that on multihead-capable hardware has some intrinsic quirks like that. So, if it were me, I'd want to fix wine to use the newer RANDR API when available. - ajax signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Launching WINE causes screen flicker in Screen#2 on a dual-head setup..
On Mon, Apr 16, 2012 at 10:36, Adam Jackson a...@redhat.com wrote: So, if it were me, I'd want to fix wine to use the newer RANDR API when available. Thanks so much! FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20120416 changes
Compose started at Mon Apr 16 08:15:05 UTC 2012 Broken deps for x86_64 -- [389-ds-base] 389-ds-base-1.2.11-0.1.a1.fc18.x86_64 requires libdb-5.2.so()(64bit) [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [anaconda] anaconda-18.1-1.fc18.x86_64 requires librpmio.so.2()(64bit) anaconda-18.1-1.fc18.x86_64 requires librpm.so.2()(64bit) [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gnome-applet-sensors] gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gridsite] gridsite-1.7.19-1.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [inkscape] inkscape-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) [lcgdm-dav] lcgdm-dav-server-0.7.0-1.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [libapreq2] libapreq2-2.13-6.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 libapreq2-2.13-6.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mcollective] mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8 [meshlab] meshlab-1.3.1-2.fc17.x86_64 requires libmuparser.so.0()(64bit) [mod_auth_pam] mod_auth_pam-1.1.1-11.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_cband] mod_cband-0.9.7.5-7.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_cluster] mod_cluster-1.1.1-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_geoip] mod_geoip-1.2.5-6.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_limitipconn] mod_limitipconn-0.23-5.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_line_edit] mod_line_edit-1.0.0-8.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_log_post] mod_log_post-0.1.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_perl] mod_perl-2.0.5-8.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_python] mod_python-3.3.1-17.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_scgi] mod_scgi-1.13-5.fc15.x86_64 requires httpd-mmn = 0:20051115 [mod_security] mod_security-2.5.13-3.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_suphp] mod_suphp-0.6.3-8.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [moksha] moksha-0.5.0-5.fc15.noarch requires pyevent [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [ocaml-augeas] ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0
Re: new Release Criterion proposal: kernel+initrd boot
Wording...how about: It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run Great, I like it, and the meaning is the same. I like the basic idea of the criterion. I'm still not really sold on what phase we should be applying it to, though PXE and virt-install together are obviously fairly good arguments for alpha or beta... In the Alpha criteria we already require that all provided boot methods work, which means netinst, DVD and Live [1]. I don't think PXE/kernel boot should be different in this case, the images are provided in the compose alongside netinst, DVD and Live. This criterion just states that we consider vmlinuz+initrd as part of this all provided boot methods as well (which is a correct thing in my view). We could even just easily append it to that criterion [1] itself. But since there are more options in PXE boot (installer not being part of initrd and other complications), we would have to assume a lot of things silently, or mention it explicitly anyways, so a separate criterion seems better and more readable. [1] The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media If there are no further objections I'll put it into Alpha criteria tomorrow. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to install some software that requires Python 2.6 and rejects 2.7?
On 12.4.2012 23:43, Fernando Cassia wrote: I think it'd be nice if you could do a small txt explaining what you had to change, and then forward it to Matej, the person doing the builds at the fedorapeople url mentioned on the OP. I did a Google search: Matej Ceplmcepl (@) redhat ! com Sorry, I was busy with some other work so I am now only ploughing through fedora.testers ... scribes.src.rpm is completely unmaintained, I have in a burst of optimism fixed it work with RHEL-6, but I don't use it on day-to-day basis anymore. If anybody wants to take over maintenance of scribes-nightly (or more than half-yearly ;)) I would love to remove my src.rpm. Please, contact the upstream which points to my URL on his webpage (which was the only reason I kept it there). If you want to push scribes back to Fedora proper (does the upstream makes releases again?, but certainly git snapshots are legitimate), I would be glad to help as much as I can (being a provenpackager, unfortunately not a sponsor). Best, Matěj -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On 14.4.2012 15:14, Fernando Cassia wrote: I find the photo import app in Fedora 17 the most intrusive, annoying piece of software I've seen in a long, long time. It certainly must be said ... but not here. bugzilla.redhat.com is the proper space to relieve your frustration. Please, if you are not willing to file bugs, what you are doing here? Matěj -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On Mon, Apr 16, 2012 at 11:23, Matej Cepl mc...@redhat.com wrote: Please, if you are not willing to file bugs, what you are doing here? Matěj Who said I wasn' t?. Just posted it here to try see if others shared my view or maybe there was some trick to make it behave differently. Best regards... FC -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to install some software that requires Python 2.6 and rejects 2.7?
On 13.4.2012 17:58, Horst H. von Brand wrote: I find it strange that there is a EPEL package that isn't also available for Fedora proper. Isn't that a requirement for EPEL? It is not a proper package maintained in EPEL (or elsewhere). Just my build of scribes for RHEL-6, hosted on fedorapeople.org not in any official repository. Matěj -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rawhide report: 20120416 changes
On Mon, Apr 16, 2012 at 02:03:45PM +, Fedora Rawhide Report wrote: Compose started at Mon Apr 16 08:15:05 UTC 2012 Broken deps for x86_64 -- [vdsm] vdsm-4.9.3.2-0.fc17.x86_64 requires /usr/sbin/saslpasswd2 Jindrich Novy has updated cyrus-sasl to re-enable the saslpasswd2 binary, so this should be resolved in tomorrows dep-check. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2012-04-16 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-04-16 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! Apologies for the late notice but we're still planning to hold a QA meeting in a couple hours. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120409 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 17 Beta Retrospective 4. Test Day report 5. Upcoming QA events 6. AutoQA update 7. Open floor signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On 04/16/2012 10:27 PM, Fernando Cassia wrote: On Mon, Apr 16, 2012 at 11:23, Matej Cepl mc...@redhat.com mailto:mc...@redhat.com wrote: Please, if you are not willing to file bugs, what you are doing here? Matěj Who said I wasn' t?. Just posted it here to try see if others shared my view or maybe there was some trick to make it behave differently. Well, I must say that your original post read, to me, more like a rant than seeking opinions/assistance. So much so that I dismissed it. FWIW, when folks say things such asWho in his right mind thought these only two options were the only possible options? and write Subject lines like yours, I don't give their posts much thought That's just me. But, if I have time later tomorrow (almost midnight), I may take a look at it to see if there is something you're missing or if your rant has any merit. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: wvdial crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2012 07:22 AM, Pedro Francisco wrote: On Mon, Apr 16, 2012 at 2:28 AM, R P Herrold herr...@owlriver.com wrote: On Sun, 15 Apr 2012, Pedro Francisco wrote: wvdial is crashing when trying to start a connection. Modem = /dev/ttyACM0. $ sudo wvdial -- WvDial: Internet dialer version 1.61 -- Cannot get information for serial port. this looks ominous ... is there a SElinux intercept from some need to re-label? (I built and installed a fresh WVdial from RawHide last week, and so the package itself seems working) I believe Cannot get information for serial port. appeared on F16/F15 (can't recall) and on F15/F16 it would work well. SEapplet showed nothing. I did get curious with warning: .dynamic section for /lib/libwvstreams.so.4.6 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /lib/libwvutils.so.4.6 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /lib/libwvbase.so.4.6 is not at the expected address (wrong library or version mismatch?) found in one of the bug's attachments Are you seeing avc messages sudo ausearch -m avc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MOl8ACgkQrlYvE4MpobMhwQCfaxA4qyVhAWh+cX4IJ8+Aqlsa BCUAn3v3W9YWKju6tFqwxWUlSSPyRNrp =JwCm -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Move from /media to /run/media/$USER
On 04/13/2012 07:48 AM, Bill Nottingham wrote: Ankur Sinha (sanjay.an...@gmail.com) said: On Fri, 2012-04-13 at 19:09 +0530, Ankur Sinha wrote: Hello, I just got into F17 today. It looks great. I do have one tiny query though: my USB media, and other partitions that I mount on-demand are no longer showing up in /media. They show up in /run/media/$USER. Can anyone shed some light on this? Where is this move documented for instance? I've looked at the new FHS[1] which doesn't appear to hold anything on this. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html It looks like it's related to udisks2[1]. This needs to be documented someplace IMO. Thoughts? Release notes seem fine. Basically, removable media mounted in the user's session are now mounted in a user-specific directory. Bill Thanks for bringing this up, I've just added it to the release notes. --pete -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
old TCs/RCs downloads - do you need them?
Usually all the old test and release composes are available there: http://dl.fedoraproject.org/pub/alt/stage/ Recently it was wiped clean. After a few people asked on #fedora-admin, the latest composes were added back. However, there seems to be a policy to delete all old composes (even the latest ones) once a milestone is declared GOLD. It means the gold composes are unavailable for several days until they are officially published. The rationale for this policy was bandwidth/storage concerns and (quoting dgilmore) 'to build up anticipation for the release'. The first part doesn't seem to apply anymore, at least if I understood nirik correctly. I'd like to ask people to voice their opinions on that policy. Do you have some use cases where you would still use the old and latest composes, or do you not need them? I'd like RelEng team to keep all the composes until Fedora Branched is Final (if technically possible) and I'd like to have some more use cases as an argument than just my personal opinions (maybe I just failed to explain them properly on #fedora-admin, so you might be more convincing). Use cases I see: 1. Old TCs/RCs benefit QA team because we can do regression testing (find out in which compose a bug first appeared). 2. Latest RCs benefit Test Days owners, they can use them instead of building their own or relying on nightlies (often broken). If we delete them, Test Days around Alpha/Beta milestones will have a hard time. 3. Bug reports often reference certain TC/RC, so their availability might help developers find a problem (if I say I see it broken on RC3 Live, it's easier to reproduce for the developer than if I see it on my installed system - every installed system is different). 4. If I haven't stored the latest ISOs locally, I can't test and report many bugs for which that particular install media is required. Removing them just to build up anticipation hurts quality. Thoughts? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: old TCs/RCs downloads - do you need them?
On Mon, Apr 16, 2012 at 12:07:33 -0400, Kamil Paral kpa...@redhat.com wrote: Usually all the old test and release composes are available there: I'd like RelEng team to keep all the composes until Fedora Branched is Final (if technically possible) and I'd like to have some more use cases as an argument than just my personal opinions (maybe I just failed to explain them properly on #fedora-admin, so you might be more convincing). I sometimes use them to be able to quickly start seeding once torrents are open. But pretty much just for final as the games spin isn't produced for alpha and beta. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: old TCs/RCs downloads - do you need them?
On Mon, 16 Apr 2012 12:07:33 -0400 (EDT) Kamil Paral kpa...@redhat.com wrote: Usually all the old test and release composes are available there: http://dl.fedoraproject.org/pub/alt/stage/ Recently it was wiped clean. After a few people asked on #fedora-admin, the latest composes were added back. However, there seems to be a policy to delete all old composes (even the latest ones) once a milestone is declared GOLD. It means the gold composes are unavailable for several days until they are officially published. The rationale for this policy was bandwidth/storage concerns and (quoting dgilmore) 'to build up anticipation for the release'. The first part doesn't seem to apply anymore, at least if I understood nirik correctly. Some history here: In the past we mirrored this content to serverbeach01. It had a small amount of disk space, so we needed to clean our old TC's/RC's pretty often or it would run out of disk space. In the further past when we started staging testing content on alt and it was a seperate machine, we would get times where a new TC/RC would be uploaded and so many people hit it that actual QA/Rel-eng folks wouldn't be able to get it, the BW on the machine was simply swamped. We now have download-ib01 as our mirror of that content, which has lots of space, so that constraint is mostly gone. Also, alt is gone and now we just have this content on our regular download boxes. BW has increased a great deal since then as well, so I have not noticed problems with TC/RC's sucking up all our BW. (which is not to say it won't happen). kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
old TCs/RCs downloads - do you need them?
In case people don't know, the install TCs/RCs back to F14 development can be rebuilt from the delta ISOs in http://dl.fedoraproject.org/pub/alt/stage/deltaisos/archive/ . (Not that this helps for Lives, and it's slow to get a specific TC/RC since to minimize space I only save deltas between successive TCs/RCs so you have to do successive builds to get the one you want.) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: old TCs/RCs downloads - do you need them?
BW has increased a great deal since then as well, so I have not noticed problems with TC/RC's sucking up all our BW. (which is not to say it won't happen). If that happens we can take some measures. One thing from top of my head would be providing torrents. We would then add torrent links as the primary links in our announcements. Or, in the worst case, actually removing those composes (but I assume old RCs don't cause much bandwidth and the latest ones are needed, so we would probably need to come up with something else). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On Mon, Apr 16, 2012 at 12:16, Ed Greshko ed.gres...@greshko.com wrote: FWIW, when folks say things such asWho in his right mind thought these only two options were the only possible options? and write Subject lines like yours, I don't give their posts much thought That's just me. :) Dramatic effect. Must be being Latin and all.. I bet in Italy they'd be yelling and chasing programmers around a large table with a knife, instead of wriing to mailing lists. ;-) JOKE JOKE! FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: wvdial crash
On Mon, Apr 16, 2012 at 4:27 PM, Daniel J Walsh dwa...@redhat.com wrote: On 04/16/2012 07:22 AM, Pedro Francisco wrote: On Mon, Apr 16, 2012 at 2:28 AM, R P Herrold herr...@owlriver.com wrote: On Sun, 15 Apr 2012, Pedro Francisco wrote: wvdial is crashing when trying to start a connection. Modem = /dev/ttyACM0. $ sudo wvdial -- WvDial: Internet dialer version 1.61 -- Cannot get information for serial port. this looks ominous ... is there a SElinux intercept from some need to re-label? (I built and installed a fresh WVdial from RawHide last week, and so the package itself seems working) I believe Cannot get information for serial port. appeared on F16/F15 (can't recall) and on F15/F16 it would work well. SEapplet showed nothing. I did get curious with warning: .dynamic section for /lib/libwvstreams.so.4.6 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /lib/libwvutils.so.4.6 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /lib/libwvbase.so.4.6 is not at the expected address (wrong library or version mismatch?) found in one of the bug's attachments Are you seeing avc messages sudo ausearch -m avc Nope, for wvdial/wvstreams no. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
How to install openresolv in F17?
Anybody knows how to install openresolv for OpenVPN usage in F17? Is there a RPM available? I googled unsucessfully. Kind regards Joachim Backes joachim.bac...@rhrk.uni-kl.de http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Update to Infrastructure, help catch problems before beta
* Note: For FESCo and QA, this is just an FYI Fedora Infrastructure uses the puppet configuration management software to push configuration files out to all of its machines. A new release of puppet has been created and pushed out to the EPEL repositories today. This release includes several security fixes [1]_ that we have decided are very important for us to apply. Due to that, we are going to be updating puppet on all of our machines. We're sending this message out to alert you to the potential for disruptions from this, including disruptions that could slip the Fedora Beta release. We do not anticipate such problems because the actual changes to the puppet code should be rather small. We're not even anticipating any interruption of services. However, this update is going out to all of our machines so we want people to be aware that problems could occur and if they experience any problems in the critical path to releasing the Beta on time to report them to us ASAP [2]_. .. [1]_: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.15 .. [2]_: Contact us in #fedora-admin on irc.freenode.net, via our ticketing system at https://fedorahosted.org/fedora-infrastructure , or our mailing list: infrastruct...@lists.fedoraproject.org Thank you, Your friendly neighborhood infrastructure team pgpwFw4v5RPAw.pgp Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Move from /media to /run/media/$USER
Jonathan Kamens (j...@kamens.us) said: It is absurdly unpredictable that if I stick a DVD in my drive after logging in, it is mounted underneath /run/media/$USER, but if my computer than crashes, or I reboot it by hand, and I log in immediately after the reboot, that DVD is no longer mounted. Independent of whether the move from /media to /run/media/$USER is a good idea, and I'm reserving judgment on that, clearly the behavior I just described above is entirely unexpected by the user and therefore wrong. The alternative here would be... it magically gets mounted by the first user? That's a bit odd, as well. Note that you should be able to configure static mounts of a cd with something like: /lib/systemd/system/media-cd.mount: [Unit] Description=My CD [Mount] What=/dev/disk/by-path/somewhere/somehow/ Where=/media/cd Bill Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to install openresolv in F17?
On 16/04/12 19:01, Joachim Backes wrote: Anybody knows how to install openresolv for OpenVPN usage in F17? No Is there a RPM available? No I googled unsucessfully. https://bugzilla.redhat.com/show_bug.cgi?id=668153 -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Move from /media to /run/media/$USER
On 4/16/2012 2:09 PM, Bill Nottingham wrote: Jonathan Kamens (j...@kamens.us) said: It is absurdly unpredictable that if I stick a DVD in my drive after logging in, it is mounted underneath /run/media/$USER, but if my computer than crashes, or I reboot it by hand, and I log in immediately after the reboot, that DVD is no longer mounted. Independent of whether the move from /media to /run/media/$USER is a good idea, and I'm reserving judgment on that, clearly the behavior I just described above is entirely unexpected by the user and therefore wrong. The alternative here would be... it magically gets mounted by the first user? That's a bit odd, as well. Oh, I don't know, maybe the alternative would be to mount devices under /media instead of /run/media/$USER? Seriously. Or perhaps the system could keep track of mounted devices and when the computer enters the same state as it was in when the device was previously mounted, mount it again automatically. In other words, If device x is mounted for $USER, and $USER logs out or the system reboots while the device is still mounted, and the same device is still available the next time $USER logs in, then remount it in the same place it was mounted before. That would be both intuitive and useful behavior. The current behavior is neither. It's also not like the behavior of any other OS of which I'm aware. Note that you should be able to configure static mounts of a cd with something like: I am not talking about static mounts. I'm talking about if I have a removable device inserted / plugged in / whatever, then when I log in, I should see it. This is what users expect. Period. Bugzillad: https://bugzilla.redhat.com/show_bug.cgi?id=813069 jik -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: old TCs/RCs downloads - do you need them?
On Mon, 16 Apr 2012 12:34:35 -0400 (EDT) Kamil Paral kpa...@redhat.com wrote: BW has increased a great deal since then as well, so I have not noticed problems with TC/RC's sucking up all our BW. (which is not to say it won't happen). If that happens we can take some measures. One thing from top of my head would be providing torrents. We would then add torrent links as the primary links in our announcements. We would really rather use less torrents rather than more, also older versions would then likely have 0 seeds and be unreachable anyhow. ;( Or, in the worst case, actually removing those composes (but I assume old RCs don't cause much bandwidth and the latest ones are needed, so we would probably need to come up with something else). Well, the worst case in the distant past was the RC's for the final release. Once that was given a go many people started grabbing the images ahead of release day just because they didn't want to wait, and spreading around the links with If you don't want to wait until tuesday, you can get the final release at... Anyhow, like I said, I don't know how much problem it will really turn out to be. kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: old TCs/RCs downloads - do you need them?
On 04/16/2012 04:07 PM, Kamil Paral wrote: I'd like to ask people to voice their opinions on that policy. Do you have some use cases where you would still use the old and latest composes, or do you not need them? From my point of view we should not need them since we can always downgrade packages should components be broken on relevant newer spin so basically this boils down to the Installer and if necessary we can keep the files relevant to Anaconda should we for some reason need to downgrade the installer... Basically I think the policy should be this. Always keep the latest successful nightly build of all spins - delete rest ( including once from previous release cycles ) Always keep the latest milestone - delete rest ( including once from previous release cycles ) Infra could store previous milestone someplace internally if necessary for some history purpose or to server on demand. Keep files relevant to test the installer throughout the development cycle once we go GA delete them First and foremost infrastructure should provide direct downloads to the iso's at all times preferably with a link latest naming scheme to it so we can write and provide script(s) for reporters to fetch the latest ISO bits. Alternative download methods such as torrents and what not should come after that. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Python discrepancies...
On Sun, 2012-04-15 at 00:18 -0700, Rob Healey wrote: Greetings: Could anyone explain why there are so many discrepancies between Python-2.7.2-12 and Python-3.3.02? This is from Python-3.3.0a2: -- [Frog@DancingSquirrels Documents]$ python3 Python 3.3.0a2 (default, Apr 13 2012, 16:55:12) This appears to be a python that you've built locally from the 3.3.0a2 tarball; the giveaway are all the locals in the sysconfig e.g. this one: [...snip...] platstdlib = /usr/local/lib/python3.3 [...snip...] From Python-2.7.2-12 This is the python from rpm [...] stdlib = /usr/lib64/python2.7 The lib64 stuff is from a patch we apply downstream when we build our RPMs in order to allow both 32-bit and 64-bit build of python to be installed: 32-bit builds go in /usr/lib; 64-bit ones go in /usr/lib64. The jargon name for this is multilib. Hope this is helpful Dave -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On 04/14/2012 09:14 PM, Fernando Cassia wrote: I plug a removable USB drive into the system and the transparent window pops up telling me if I want to: 1. Import the pictures into this software 2. Eject. FWIW, I just installed the latest F17 Live Desktop beta. Upon plugging in a USB flash drive I get a popup at the bottom with the options for... 1. Open with Files 2. Eject I don't get Import the pictures into this software I installed both shotwell and digikam and I don't get any options to import into either of them. So, I don't see what you are seeing. What else have you installed? -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On Tue, Apr 17, 2012 at 00:54, Ed Greshko ed.gres...@greshko.com wrote: So, I don't see what you are seeing. What else have you installed? Maybe shotwell is not installed by default on the livecd? I made an install to hd of f17 beta (rc3). Upon I got fed up with shotwell and removed it from my system, it returned to the behaviour you are seeing, which is fine by me. I guess in the end the point that should be made to shotwell devs is that in any case if the program overrides the standard notifications, then the program´s own notifications should not be just the two current ones Import pics, or eject but rather also open as files... (or I´d add, ´do nothing´) FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: It must be said: the photo import app in F17 is the most intrusive annoying piece of sw I've seen
On 04/17/2012 12:14 PM, Fernando Cassia wrote: On Tue, Apr 17, 2012 at 00:54, Ed Greshko ed.gres...@greshko.com wrote: So, I don't see what you are seeing. What else have you installed? Maybe shotwell is not installed by default on the livecd? I made an install to hd of f17 beta (rc3). It is not. That is why I said I installed both shotwell and digikam. (After doing an install to HD, which I failed to mention.) I *never* saw the behavior you reported with shotwell, digikam, and now gwenview installed. So, I don't know how you got into the situation you did in order to complain about it. So, with that in mind, I don't feel there is anything to tell anyone unless the issue can be reproduced. -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Move from /media to /run/media/$USER
On 04/13/2012 09:39 PM, Ankur Sinha wrote: Hello, I just got into F17 today. It looks great. I do have one tiny query though: my USB media, and other partitions that I mount on-demand are no longer showing up in /media. They show up in /run/media/$USER. Can anyone shed some light on this? Where is this move documented for instance? I've looked at the new FHS[1] which doesn't appear to hold anything on this. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html FWIW, as KDE user I'm happy to note that this seems to be a GNOME thing. :-) -- Never be afraid to laugh at yourself, after all, you could be missing out on the joke of the century. -- Dame Edna Everage -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
