Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
Use valgrind. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: net-snmp soname bump in rawhide
On Thursday 07 of July 2011 15:23:19 Jan Safranek wrote: net-snmp-5.7 is heading to rawhide, please rebuild your packages if you depend on it. $ repoquery --whatrequires net-snmp-libs net-snmp net-snmp-devel net-snmp-perl net-snmp-python --alldeps -s | sort | uniq ... apcupsd done ... and ... nut done -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Lack of space on /
Hi, Something strange has happened on my system. At the start of last week, / was reporting that I had about 8Gb free. It now reports that / is completely full. chkrootkit is reporting nothing untoward. I have noticed that putting things in the wastebasket and then saying empty hasn't been doing so recently, but that shouldn't account for 8Gb! Any ideas? PFJ -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lack of space on /
On Fri, Jul 08, 2011 at 09:47:13AM +0100, Paul F. Johnson wrote: Something strange has happened on my system. At the start of last week, / was reporting that I had about 8Gb free. It now reports that / is completely full. Wrong list, I think, this is the Fedora DEVELOPMENT list. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lack of space on /
2011/7/8 Paul F. Johnson p...@all-the-johnsons.co.uk: Hi, Something strange has happened on my system. At the start of last week, / was reporting that I had about 8Gb free. It now reports that / is completely full. chkrootkit is reporting nothing untoward. I have noticed that putting things in the wastebasket and then saying empty hasn't been doing so recently, but that shouldn't account for 8Gb! Any ideas? What $ du -h -d 1 / says? PFJ -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Thu, Jul 07, 2011 at 10:57:54PM -0400, Steve Dickson wrote: Hello, One of the maintainers of systemd and I have been working together on trying to convert the NFS SysV init scripts into systemd services. Here is the long trail... https://bugzilla.redhat.com/show_bug.cgi?id=699040 The point is this, with fairly complicated system, some events need to have happen, like loading modules, before other events happen, like setting parameters of those loaded modules. Currently the ExecStart commands can be started and end before the ExecStartPre even start. This means setting modules parameters within the same service file are impossible. I would have though intuitively that Pre commands would complete prior to ExecStart command in the same service file. To not do so seems like a bug to me. Neil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On 07/06/2011 10:43 PM, Casey Dahlin wrote: On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote: I no longer have a need/care for these packages, they are up for grabs: contacts inotail I'll take inotail. --CJD Just for the note - there tailf util in util-linux package does the same. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: net-snmp soname bump in rawhide
On 07/07/2011 09:19 PM, Jeffrey Ollie wrote: On Thu, Jul 7, 2011 at 8:23 AM, Jan Safranek jsafr...@redhat.com wrote: net-snmp-5.7 is heading to rawhide, please rebuild your packages if you depend on it. asterisk I haven't dug into this deeply yet, but this seems to have broken the asterisk build. Sorry, I messed up the update and net-snmp-config returned wrong link options. This is fixed in net-snmp-5.7-2 and I've checked that asterisk builds just fine with it. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lack of space on /
On 07/08/2011 04:47 AM, Paul F. Johnson wrote: Hi, Something strange has happened on my system. At the start of last week, / was reporting that I had about 8Gb free. It now reports that / is completely full. .. Any ideas? Probably should be users list not dev (unless you're running rawhide) - but see if yum clean packages does anything. Also take a look in /tmp and /var/tmp if that doesn't take care of it. gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110708 changes
Compose started at Fri Jul 8 08:15:10 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9-0.2.a2.fc16.x86_64 requires libnetsnmp.so.25()(64bit) 389-ds-base-1.2.9-0.2.a2.fc16.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9-0.2.a2.fc16.x86_64 requires libnetsnmpagent.so.25()(64bit) OpenIPMI-2.0.18-7.fc15.x86_64 requires libnetsnmp.so.25()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) 1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26 1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) 1:anjuta-3.1.2-1.fc16.i686 requires libvala-0.12.so.0 1:anjuta-3.1.2-1.fc16.x86_64 requires libvala-0.12.so.0()(64bit) asterisk-snmp-1.8.5-0.1.rc1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) asterisk-snmp-1.8.5-0.1.rc1.fc16.x86_64 requires libnetsnmpagent.so.25()(64bit) asterisk-snmp-1.8.5-0.1.rc1.fc16.x86_64 requires libnetsnmpmibs.so.25()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) cluster-glue-1.0.6-2.fc15.1.x86_64 requires libnetsnmp.so.25()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) collectd-snmp-4.10.3-3.fc16.x86_64 requires libnetsnmp.so.25()(64bit) cpqarrayd-2.3-15.fc15.x86_64 requires libnetsnmp.so.25()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.0-10.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libebook-1.2.so.10()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-provider-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libgnome-desktop-3.so.0()(64bit) evolution-sharp-0.21.1-14.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) foghorn-0.1.2-4.fc16.x86_64 requires libnetsnmpmibs.so.25()(64bit) foghorn-0.1.2-4.fc16.x86_64 requires libnetsnmp.so.25()(64bit) foghorn-0.1.2-4.fc16.x86_64 requires libnetsnmpagent.so.25()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-6.20110701git808152718e3ab.fc16.x86_64 requires libvala-0.12.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires
Re: systemd: Is it wrong?
On Thu, 07.07.11 22:57, Steve Dickson (ste...@redhat.com) wrote: Hello, One of the maintainers of systemd and I have been working together on trying to convert the NFS SysV init scripts into systemd services. Here is the long trail... https://bugzilla.redhat.com/show_bug.cgi?id=699040 The point is this, with fairly complicated system, some events need to have happen, like loading modules, before other events happen, like setting parameters of those loaded modules. Currently the ExecStart commands can be started and end before the ExecStartPre even start. This means setting modules parameters within the same service file are impossible. I suggested that a boundary be set that all ExecStartPre commands finish before any ExecStart commands start, which would allow complicated subsystems, like NFS, to start in a very stable way... So is it wrong? Shouldn't there away to allow certain parts of a system to synchronously configure some things so other parts will come up as expected? I am pretty sure systemd-devel is the better place to discuss this. But here are a few comments after reading throught the bug report: Yes, we want that people place each service in an individual service file. Only then we can supervise the services properly. It is possible to spawn multiple high-level processes from a single service, but that is mostly intended as compat kludge to support SysV init scripts where this is possible. In general however, we want people to do have a 1:1 mapping. Only then we can restart services if needed, we can catch crashes, and show proper information about your service. So, I'd suggest strongly not to try starting all services from a single file. There's a reason why we explicitly forbid having more than one ExecStart= in a unit file (except for Type=oneshot services). Note that systemd unit files are not a programming language. And that for a reason. If you want shell, then use shell, but don't try to misuse the purposefully simple service file syntax for that. Also, you should not spawn forking processes in ExecStartPre=, that's not what it is for. In fact I am pretty sure I will change systemd now to kill off all remaining processes after each ExecStartPre= command now that I am aware that people are misusing it like this. ExecStartPre= is executed strictly in order, and in the order they appear in the unit file. I believe that services should be enabled/disabled at one place only, and that is where you can use systemctl enable and systemctl disable. Adding a service-specific second-level of disabling in /etc/sysconfig/ is confusing to the user, and not necessary. You'll do a great service to your users if they can enable/disable all individual services the same way. (And UI writers will be thankful for that too) There's no point in ever unloading kernel modules, unless you do it for debugging or testing reasons. No init script should ever include an rmmod or modprobe -r. And we try to make static module loading unnecessary. There's nowadays auto-loading for most modules in one way or another, using MODALIAS and similar constructs in the kernel modules. If you really need to load a module statically, then please do so via /etc/modules-load.d/ so that the user has centralized control on this. This is not going to work: ExecStart=$FOO bar waldo I.e. variable substitution for the binary path (it will work for the arguments, just not for the binary path). This limitation is necessary due to some SELinux innerworkings in systemd. It's a limitation we probably could fix if we wanted to, but tbh I find it quite questionable if you spawn two completely different binaries and still call it by the same service file. In general if services use a lot of /etc/sysconfig/ settings then this is probably an indication that the service code should be fixed and should just get proper configuration files. If you need to interpret these files, outside of the daemon, and the simple variable substitution is not sufficient, and you need a programming language to interpret the settings, then use a programming language, for example shell. You can start shell scripts from systemd, like any other executable, and then exec the real binary in the end. Of course, these solutions are somewhat hacky, and I think in the long run binaries should be stand-alone and should be able to read their own configuration themselves. But if you really need a shell script, then go for it, stick it in /usr/lib/yourpackage/scripts/ or so, and execute that from ExecStart=. I will probably blog about sysconfig in a systemd world soon. Type=oneshot is for one shot services, not continously running services. Type=oneshot is for stuff like fsck, that runs once at boot and finishes, and only after it finished boot will continue. I am aware that some things I point out above are not how people used to do things on SysV, but well, we want to get things right, and if you use systemd natively,
Re: systemd: Is it wrong?
On Fri, 08.07.11 06:47, Neil Horman (nhor...@redhat.com) wrote: On Thu, Jul 07, 2011 at 10:57:54PM -0400, Steve Dickson wrote: Hello, One of the maintainers of systemd and I have been working together on trying to convert the NFS SysV init scripts into systemd services. Here is the long trail... https://bugzilla.redhat.com/show_bug.cgi?id=699040 The point is this, with fairly complicated system, some events need to have happen, like loading modules, before other events happen, like setting parameters of those loaded modules. Currently the ExecStart commands can be started and end before the ExecStartPre even start. This means setting modules parameters within the same service file are impossible. I would have though intuitively that Pre commands would complete prior to ExecStart command in the same service file. To not do so seems like a bug to me. Yes, correct. ExecStartPre= lines are executed in the same order as they appear in the unit file, and one by one. There is never more than one ExecStartPre= process running, and if it is then this would be a bug. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Jóhann B. Guðmundsson johannbg at gmail.com writes: On 07/08/2011 11:42 AM, JB wrote: Hi, you are right about the synchronization problem within a service file exec environment, at least as you showed it in that particular Bugzilla case. snip No he did not and you are wrong the problem has nothing to do with order timing and execution but everything to do with this.. ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT Further explanation can be found on the bug report and a correct working native systemd nfslock service is attached to that report along with the necessary modification he needs to do in the sysconfig file he is using. JBG Johann, I think you are fixing it to work according to your world view :-) $ man sysctl ... SYNOPSIS ... sysctl [-n] [-e] [-q] -w variable=value ... ... So, if nfslock.service file contains: ... ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT ... then this is the correct syntax. If this does not work as processed by systemd, then that means a bug ... JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/08/2011 12:41 PM, JB wrote: Johann, I think you are fixing it to work according to your world view :-) Nope $ man sysctl ... SYNOPSIS ... sysctl [-n] [-e] [-q] -w variable=value ... ... So, if nfslock.service file contains: ... ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT ... then this is the correct syntax. If this does not work as processed by systemd, then that means a bug ... Or more likely this means that the content of the $LOCKD_TCPPORT variable is not being delivered to /sbin/sysctl -w fs.nfs.nlm_tcpport= Like for instance if he left it hashed out in the sysconfig file the service would fail since fs.nfs.nlm_tcpport= is expecting to have some value as I explained on the bug report in comment 43 I repeatly asked to see that sysconfig file so I could diagnose the problem further but I got responses like.. How does your /etc/sysconfig file look like basically why does this matter? Its the default one that is installed... ( Which eventually led me to loose my cool because I really needed to see what he was passing if any to that command something I'm not particularly proud of ) So does not the default have the $LOCKD_TCPPORT line hashed out #$LOCKD_TCPPORT which means you arent passing anything to /sbin/sysctl -w fs.nfs.nlm_tcpport= which then would result in this.. [root@valhalla system]# /sbin/sysctl -w fs.nfs.nlm_tcpport= error: Malformed setting fs.nfs.nlm_tcpport= And the service would fail to start.. Nothing to do with systemd to but everything to do with the command and or the sysconfig file Anyway I fixed his service and it works now as he wanted to be afaikt so he should be happy and ships the native systemd service file which makes me be happy and I can cross nfs off https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On 07/08/2011 08:23 AM, Lennart Poettering wrote: On Thu, 07.07.11 22:57, Steve Dickson (ste...@redhat.com) wrote: Hello, One of the maintainers of systemd and I have been working together on trying to convert the NFS SysV init scripts into systemd services. Here is the long trail... https://bugzilla.redhat.com/show_bug.cgi?id=699040 The point is this, with fairly complicated system, some events need to have happen, like loading modules, before other events happen, like setting parameters of those loaded modules. Currently the ExecStart commands can be started and end before the ExecStartPre even start. This means setting modules parameters within the same service file are impossible. I suggested that a boundary be set that all ExecStartPre commands finish before any ExecStart commands start, which would allow complicated subsystems, like NFS, to start in a very stable way... So is it wrong? Shouldn't there away to allow certain parts of a system to synchronously configure some things so other parts will come up as expected? I am pretty sure systemd-devel is the better place to discuss this. But here are a few comments after reading throught the bug report: I didn't know it existed... Yes, we want that people place each service in an individual service file. Only then we can supervise the services properly. It is possible to spawn multiple high-level processes from a single service, but that is mostly intended as compat kludge to support SysV init scripts where this is possible. In general however, we want people to do have a 1:1 mapping. Only then we can restart services if needed, we can catch crashes, and show proper information about your service. So, I'd suggest strongly not to try starting all services from a single file. There's a reason why we explicitly forbid having more than one ExecStart= in a unit file (except for Type=oneshot services). Thank you for this explanation. It appears your definition of a service might be a bit too simple for many subsystems. You seem to think that on service will only start one system daemon, which is not the case in the more complex subsystems. Note that systemd unit files are not a programming language. And that for a reason. If you want shell, then use shell, but don't try to misuse the purposefully simple service file syntax for that. Boy... What I would give for a shell!! 8-) Also, you should not spawn forking processes in ExecStartPre=, that's not what it is for. In fact I am pretty sure I will change systemd now to kill off all remaining processes after each ExecStartPre= command now that I am aware that people are misusing it like this. If they are not for forking off process, what are the for? It seems quite logical that one would use a number of ExecStartPre= commands to do some set up and then use the ExecStart= to start the daemon. ExecStartPre= is executed strictly in order, and in the order they appear in the unit file. True, but there is no synchronization. Meaning first process can end after the second process, which think is a problem. I believe that services should be enabled/disabled at one place only, and that is where you can use systemctl enable and systemctl disable. Adding a service-specific second-level of disabling in /etc/sysconfig/ is confusing to the user, and not necessary. You'll do a great service to your users if they can enable/disable all individual services the same way. (And UI writers will be thankful for that too) In a simple subsystem maybe, but many subsystems have a large number of configuration knobs that are needed so the subsystem can function in a large number of different environments. So in the past its been very handy and straightforward to be able to tweak one file to set configurations on different, but related, subsystems. There's no point in ever unloading kernel modules, unless you do it for debugging or testing reasons. No init script should ever include an rmmod or modprobe -r. And we try to make static module loading unnecessary. There's nowadays auto-loading for most modules in one way or another, using MODALIAS and similar constructs in the kernel modules. If you really need to load a module statically, then please do so via /etc/modules-load.d/ so that the user has centralized control on this. I agree unloading modules is unnecessary, but, IMHO, its much similar to manage one start up file that loads multiple modules than one start up script and multiple modules-load.d files.. This is not going to work: ExecStart=$FOO bar waldo I.e. variable substitution for the binary path (it will work for the arguments, just not for the binary path). This limitation is necessary due to some SELinux innerworkings in systemd. It's a limitation we probably could fix if we wanted to, but tbh I find it quite questionable if you spawn two completely different binaries and still call it by the same
Re: systemd: Is it wrong?
Jóhann B. Guðmundsson johannbg at gmail.com writes: On 07/08/2011 12:41 PM, JB wrote: Johann, I think you are fixing it to work according to your world view Nope $ man sysctl ... SYNOPSIS ... sysctl [-n] [-e] [-q] -w variable=value ... ... So, if nfslock.service file contains: ... ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT ... then this is the correct syntax. If this does not work as processed by systemd, then that means a bug ... Or more likely this means that the content of the $LOCKD_TCPPORT variable is not being delivered to /sbin/sysctl -w fs.nfs.nlm_tcpport= Like for instance if he left it hashed out in the sysconfig file the service would fail since fs.nfs.nlm_tcpport= is expecting to have some value as I explained on the bug report in comment 43 ... Johann, we know that. But the fact is that you do not understand how the systemd program should work. The nfslock.service file contains this: EnvironmentFile=-/etc/sysconfig/nfsservices Let's assume that LOCKD_TCPPORT is hashed out. That means, in bash, you get unset variable value: # echo $LOCKD_TCPPORT # Then this entry: ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT is formatted as follows after substitution: ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport= That's why you get, when executing manually in bash, this: # /sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT error: Malformed setting fs.nfs.nlm_tcpport= This entry is passed to systemd for execution, as is ! It is the responsibility of systemd to parse it, determine what entry it is (you could put in there any garbage, perhaps a virus, rootkit, etc), then if a valid executable entry then it should validate its syntax and arguments (are you still here, Johann ... ?!), and if not valid the entry should not be executed, that is aborted or error completion code returned to calling env. So, it is a systemd bug if it does not work ... Btw, if you are able to pass your version of this entry to systemd's execution environment and it is taken despite a violation of sysctl syntax and programming security, then Gold help us :-) JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File MIME-Charset-1.009.1.tar.gz uploaded to lookaside cache by xavierb
A file has been added to the lookaside cache for perl-MIME-Charset: ee982e66423738b1b13f45cdde4fe1cf MIME-Charset-1.009.1.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MIME-Charset] Update to 1.009.1
commit 9e404739ce61febdbddce56a873367f6b1c50269
Author: Xavier Bachelot xav...@bachelot.org
Date: Fri Jul 8 16:16:14 2011 +0200
Update to 1.009.1
.gitignore |1 +
perl-MIME-Charset.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e9047c0..f330693 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ MIME-Charset-1.006.2.tar.gz
/MIME-Charset-1.008.tar.gz
/MIME-Charset-1.008.1.tar.gz
/MIME-Charset-1.008.2.tar.gz
+/MIME-Charset-1.009.1.tar.gz
diff --git a/perl-MIME-Charset.spec b/perl-MIME-Charset.spec
index 70645d6..5883012 100644
--- a/perl-MIME-Charset.spec
+++ b/perl-MIME-Charset.spec
@@ -1,6 +1,6 @@
Name: perl-MIME-Charset
-Version:1.008.2
-Release:2%{?dist}
+Version:1.009.1
+Release:1%{?dist}
Summary:Charset Informations for MIME
License:GPL+ or Artistic
Group: Development/Libraries
@@ -63,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Jul 08 2011 Xavier Bachelot xav...@bachelot.org 1.009.1-1
+- Update to 1.009.1.
+
* Mon Jun 20 2011 Marcela Mašláňová mmasl...@redhat.com - 1.008.2-2
- Perl mass rebuild
diff --git a/sources b/sources
index 89e9c74..2baae67 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8bb1e361e90b1f9eae8f64a4067e563f MIME-Charset-1.008.2.tar.gz
+ee982e66423738b1b13f45cdde4fe1cf MIME-Charset-1.009.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
releasing ownership of coda stack
Hi, I have not used Coda in some time, so I am going to release ownership of items in the coda stack. The only concern is that EPEL packages won't have an owner, but Coda itself isn't supported there because of the missing kernel module. Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning fvwm and libstroke
Hi, I am orphaning fvwm and libstroke. It's been fun! Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 712038] perl-MIME-Charset-1.009.1 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712038 Xavier Bachelot xav...@bachelot.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2011-07-08 10:25:52 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: orphaning fvwm and libstroke
Hello All! 2011/7/8 Adam Goode a...@spicenitz.org: Hi, I am orphaning fvwm and libstroke. It's been fun! I'm using fvwm (and thus libstroke) so I could take care of both. Any other volunteers? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On Fri, Jul 8, 2011 at 2:13 PM, Kevin Wilson wkev...@gmail.com wrote: Hello, I have biosdevname-0.3.8-1.fc15.x86_64 on fedora 15 machine. I see from man biosdevname , that the name of the devices should be: .. emport for embedded NICs pcislot#port_virtual instance for cards in PCI slots .. ifconfig shows I have em1, p2p1; indded em1 is embedded NICs. However , the second nic is PCI nic. Why does it not defined as pcislot#port? is this some udev definition (some policy) which sets other names for pci nics ? any idea where this policy is defined and how can I choose a different policy ? Have a look in the rpm and you'll see the rule file listed. p2 is pci slot 2 and p1 is port 1. Looks consistent to me. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On Fri, 2011-07-08 at 16:13 +0300, Kevin Wilson wrote: Hello, I have biosdevname-0.3.8-1.fc15.x86_64 on fedora 15 machine. I see from man biosdevname , that the name of the devices should be: .. emport for embedded NICs pcislot#port_virtual instance for cards in PCI slots .. ifconfig shows I have em1, p2p1; indded em1 is embedded NICs. However , the second nic is PCI nic. Why does it not defined as pcislot#port? is this some udev definition (some policy) which sets other names for pci nics ? any idea where this policy is defined and how can I choose a different policy ? The man page is out of date. pciXp_Y got changed to pXpY, I believe because it turned out to be important that the names be kept below a certain length. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
Adam Williamson wrote: ifconfig shows I have em1, p2p1; Why does it not defined as pcislot#port? The man page is out of date. pciXp_Y got changed to pXpY, I believe because it turned out to be important that the names be kept below a certain length. I also have biosdevname-0.3.8-1.fc15.x86_64, but ifconfig says I have eth0 and eth1 for the wireless. How come? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Application-Plugin-Authentication] Update to 0.20, add new BuildRequires and clean up spec file
commit cfafb990bf1cac77366c3fc40c68981ebd6c1605
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Fri Jul 8 17:00:09 2011 +0200
Update to 0.20, add new BuildRequires and clean up spec file
.gitignore |1 +
perl-CGI-Application-Plugin-Authentication.spec | 18 +-
sources |2 +-
3 files changed, 11 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 97e7444..da74c9e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
CGI-Application-Plugin-Authentication-0.18.tar.gz
/CGI-Application-Plugin-Authentication-0.19.tar.gz
+/CGI-Application-Plugin-Authentication-0.20.tar.gz
diff --git a/perl-CGI-Application-Plugin-Authentication.spec
b/perl-CGI-Application-Plugin-Authentication.spec
index 843d1b0..b546aa5 100644
--- a/perl-CGI-Application-Plugin-Authentication.spec
+++ b/perl-CGI-Application-Plugin-Authentication.spec
@@ -1,12 +1,11 @@
Name: perl-CGI-Application-Plugin-Authentication
-Version:0.19
-Release:2%{?dist}
+Version:0.20
+Release:1%{?dist}
Summary:Authentication framework for CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:
http://search.cpan.org/dist/CGI-Application-Plugin-Authentication/
Source0:
http://www.cpan.org/authors/id/S/SI/SILASMONK/CGI-Application-Plugin-Authentication-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(Apache::Htpasswd)
@@ -21,7 +20,9 @@ BuildRequires: perl(Crypt::PasswdMD5)
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(Digest::SHA1)
BuildRequires: perl(Module::Build)
+BuildRequires: perl(Readonly)
BuildRequires: perl(Task::Weaken)
+BuildRequires: perl(Test::ConsistentVersion)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::MockObject)
BuildRequires: perl(Test::More)
@@ -51,8 +52,6 @@ CGI::Application::Plugin::Authentication plugin.
./Build
%install
-rm -rf $RPM_BUILD_ROOT
-
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
@@ -61,16 +60,17 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
./Build test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes README example
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Jul 08 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.20-1
+- Update to 0.20
+- Add new BuildRequires
+- Clean up spec file
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.19-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 402f0b0..dad4961 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-778f9e3c5ec4ba7702cc932d37bf9230
CGI-Application-Plugin-Authentication-0.19.tar.gz
+5b4ff96b2f703b11bae13308aee7bd30
CGI-Application-Plugin-Authentication-0.20.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd: Is it wrong?
On 07/08/2011 10:06 AM, JB wrote: This entry is passed to systemd for execution, as is ! It is the responsibility of systemd to parse it, determine what entry it is (you could put in there any garbage, perhaps a virus, rootkit, etc), then if a valid executable entry then it should validate its syntax and arguments (are you still here, Johann ... ?!), and if not valid the entry should not be executed, that is aborted or error completion code returned to calling env. That sounds extraordinarily unreasonable to me. If the unit file is broken with bad input it is broken - it is not systemd's job to detect/fix bad input to an application - it should do what it is being asked to do and run it as per the inputs in the file. If the application fails due to bad input then systemd should (and presumably does) report the failure that the application itself reports to systemd. Systemd cannot possibly know what valid arguments and syntax are/might be for every application existing and not yet written - and should not. Thats the job of each application itself - to exit with an error if the inputs are bad and then systemd should report that error information. systemd does enough - leave it alone :-) gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Development only package?
I'm working on making a package of OpenImageIO[1] which is used by a new branch of blender, blender-cycles[2], which uses the cycles rendering engine[3]. There appears to be one bundled library, pugixml[4] but it's only 3 files (1 c, and 2 header files) and doesn't not compile on it's own. It looks to be designed intentionally to be built in to other programs. Should I package it as pugixml-devel only? Or just pugixml? Thanks, Richard [1] https://sites.google.com/site/openimageio/home [2] http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/Building [3] http://www.youtube.com/watch?v=8KgrBjt4e9k (video demo) [4] http://pugixml.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI-Application-Plugin-ValidateRM] Update to 2.4 and clean up spec file
commit a41ce51aa2e59eb1dec7c8119bf8e4293386fc91
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Fri Jul 8 17:13:55 2011 +0200
Update to 2.4 and clean up spec file
.gitignore |1 +
perl-CGI-Application-Plugin-ValidateRM.spec | 17 -
sources |2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7871a00..c4619a9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CGI-Application-Plugin-ValidateRM-2.3.tar.gz
+/CGI-Application-Plugin-ValidateRM-2.4.tar.gz
diff --git a/perl-CGI-Application-Plugin-ValidateRM.spec
b/perl-CGI-Application-Plugin-ValidateRM.spec
index 9b0dada..be3a4ab 100644
--- a/perl-CGI-Application-Plugin-ValidateRM.spec
+++ b/perl-CGI-Application-Plugin-ValidateRM.spec
@@ -1,12 +1,11 @@
Name: perl-CGI-Application-Plugin-ValidateRM
-Version:2.3
-Release:8%{?dist}
+Version:2.4
+Release:1%{?dist}
Summary:Help validate CGI::Application run modes using
Data::FormValidator
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-ValidateRM/
Source0:
http://www.cpan.org/authors/id/M/MA/MARKSTOS/CGI-Application-Plugin-ValidateRM-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI)
BuildRequires: perl(CGI::Application)
@@ -17,6 +16,8 @@ BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+%{?perl_default_filter}
+
%description
CGI::Application::Plugin::ValidateRM helps to validate web forms when using
the CGI::Application framework and the Data::FormValidator module.
@@ -30,8 +31,6 @@ chmod 644 Changes
./Build
%install
-rm -rf $RPM_BUILD_ROOT
-
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
@@ -41,16 +40,16 @@ chmod 0644
$RPM_BUILD_ROOT/%{perl_vendorlib}/CGI/Application/Plugin/ValidateRM.p
%check
./Build test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Fri Jul 08 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 2.4-1
+- Update to 2.4
+- Clean up spec file
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.3-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 97b9fd7..ea0f3ac 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-689de4b8db1052d8902f8c4a2b7f5d35 CGI-Application-Plugin-ValidateRM-2.3.tar.gz
+39a1677de948fc9db519bf38fd645716 CGI-Application-Plugin-ValidateRM-2.4.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Config-Auto-0.36.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Config-Auto: e49f1314ee58972c91792977e9a99776 Config-Auto-0.36.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Sys-Virt] Update to 0.9.2 release
commit 8b8ec5e921508c67e649a7ae4468f0b80b4987d2
Author: Daniel P. Berrange berra...@redhat.com
Date: Fri Jul 8 16:25:47 2011 +0100
Update to 0.9.2 release
perl-Sys-Virt.spec |7 +--
sources|1 -
2 files changed, 5 insertions(+), 3 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 0d3d83b..25cd23a 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,5 +1,5 @@
Name: perl-Sys-Virt
-Version:0.2.7
+Version:0.9.2
Release:1%{?dist}
Summary:Represent and manage a libvirt hypervisor connection
License:GPLv2+ or Artistic
@@ -11,7 +11,7 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(XML::XPath)
-BuildRequires: libvirt-devel = 0.8.8
+BuildRequires: libvirt-devel = 0.9.2
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Jul 8 2011 Daniel P. Berrange berra...@redhat.com - 0.9.2-1
+- Update to 0.9.2 release
+
* Wed Jun 29 2011 Daniel P. Berrange berra...@redhat.com - 0.2.7-1
- Update to 0.2.7 release
diff --git a/sources b/sources
index 858a756..5100e2e 100644
--- a/sources
+++ b/sources
@@ -1,2 +1 @@
-968641ea0f85c6ad25ed13ba235f06ff Sys-Virt-0.2.7.tar.gz
7dbf47975e43a6debce21ca8034fa0ab Sys-Virt-0.9.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On Fri, 2011-07-08 at 08:45 -0600, Petrus de Calguarium wrote: Adam Williamson wrote: ifconfig shows I have em1, p2p1; Why does it not defined as pcislot#port? The man page is out of date. pciXp_Y got changed to pXpY, I believe because it turned out to be important that the names be kept below a certain length. I also have biosdevname-0.3.8-1.fc15.x86_64, but ifconfig says I have eth0 and eth1 for the wireless. How come? That would indicate your BIOS doesn't have the necessary support; quite a few don't. There's some notes on what's needed for biosdevname to work at https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Naming_With_Biosdevname#Hardware_Requirements , the test day we ran on this function in the last cycle. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
Adam Williamson wrote: That would indicate your BIOS doesn't have the necessary support; quite a few don't. There's some notes on what's needed for biosdevname to work at https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Nami ng_With_Biosdevname#Hardware_Requirements I ran the script, output: Checking hardware requirements [ OK ] Checking for SMBIOS type 41 support[FAILED] Checking for SMBIOS type 9 support [ OK ] Checking for PCI Interrupt Routing support [ OK ] The instructions say: If the output of the script is [ OK ] and any of the following checks is [ OK ], your hardware is supported by biosdevname. So, what's wrong? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On 08/07/11 17:02, Petrus de Calguarium wrote: I ran the script, output: Checking hardware requirements [ OK ] Checking for SMBIOS type 41 support[FAILED] Checking for SMBIOS type 9 support [ OK ] Checking for PCI Interrupt Routing support [ OK ] The instructions say: If the output of the script is [ OK ] and any of the following checks is [ OK ], your hardware is supported by biosdevname. So, what's wrong? Did you upgrade this machine from an earlier version of Fedora? If so then I suspect the old names will stick because you will have udev persistent naming rules for them. Check /etc/udev/rules.d/70-persistent-net.rules and I bet you have rules that are forcing the ethX names. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On Fri, 2011-07-08 at 10:02 -0600, Petrus de Calguarium wrote: Adam Williamson wrote: That would indicate your BIOS doesn't have the necessary support; quite a few don't. There's some notes on what's needed for biosdevname to work at https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Nami ng_With_Biosdevname#Hardware_Requirements I ran the script, output: Checking hardware requirements [ OK ] Checking for SMBIOS type 41 support[FAILED] Checking for SMBIOS type 9 support [ OK ] Checking for PCI Interrupt Routing support [ OK ] The instructions say: If the output of the script is [ OK ] and any of the following checks is [ OK ], your hardware is supported by biosdevname. So, what's wrong? I plead ignorance - you reached the limits of my knowledge on the topic :) Matt Domsch might be able to help, when he comes by. Oh, if you upgrade from earlier Fedora releases, I believe it preserves your previous interface names by default: you have to wipe out a few config files to make it use the new ones, starting with the /etc/udev/rules.d file that specifies interface names. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
Hi, 2011/7/8 Andreas Schwab sch...@redhat.com: Use valgrind. I attach valgrind output. ==1312== 1 errors in context 1 of 116: ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) ==1312==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) ==1312==by 0x401835: ??? (in /sbin/mount.ecryptfs) ==1312==by 0x5E3039C: (below main) (in /lib64/libc-2.14.so) Could this be related to - Fix static linking with checking x86/x86-64 memcpy (BZ#12653) or is it an eCryptfs problem? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ mount-valgrind.tar.bz2 Description: BZip2 compressed data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
Tom Hughes wrote: Did you upgrade this machine from an earlier version of Fedora? If so then I suspect the old names will stick because you will have udev persistent naming rules for them. No, I did a clean install. I installed a week before the first Test Candidate for the first Release Candidate of the Alpha for Fedora 15 came out. Check /etc/udev/rules.d/70-persistent-net.rules and I bet you have rules that are forcing the ethX names. Yes, this file is present. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: Hi, 2011/7/8 Andreas Schwab sch...@redhat.com: Use valgrind. I attach valgrind output. ==1312== 1 errors in context 1 of 116: ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) ==1312== at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) ==1312== by 0x401835: ??? (in /sbin/mount.ecryptfs) ==1312== by 0x5E3039C: (below main) (in /lib64/libc-2.14.so) I installed ecryptfs-utils-debuginfo package and now it's more readable ==1815== 1 errors in context 1 of 116: ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) ==1815==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) ==1815==by 0x401835: main (string3.h:52) Could this be related to - Fix static linking with checking x86/x86-64 memcpy (BZ#12653) or is it an eCryptfs problem? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- Best regards, Michal http://eventhorizon.pl/ valgrind-bad.txt.bz2 Description: BZip2 compressed data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Genes MailLists lists at sapience.com writes: ... Yes, it is a little bit harsh. I was not precise by mentioning systemd only with regard to entry validation. I should have said systemd (by its own code or that from any utilities) or the called app itself. Having said that, there is probably a need to pre-edit/pre-validate input and systemd execution environment with regard to what could be passed for execution as a called app. This stuff is run with root rights, so just passing to it WMD indiscriminately, without any preconditions, would be dangerous. JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
On 07/08/2011 12:32 PM, Michał Piotrowski wrote: W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: Hi, 2011/7/8 Andreas Schwabsch...@redhat.com: Use valgrind. I attach valgrind output. ==1312== 1 errors in context 1 of 116: ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) ==1312==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) ==1312==by 0x401835: ??? (in /sbin/mount.ecryptfs) ==1312==by 0x5E3039C: (below main) (in /lib64/libc-2.14.so) I installed ecryptfs-utils-debuginfo package and now it's more readable ==1815== 1 errors in context 1 of 116: ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) ==1815==at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) ==1815==by 0x401835: main (string3.h:52) So it does appear to be related to the memcpy change in libc. Could this be related to - Fix static linking with checking x86/x86-64 memcpy (BZ#12653) or is it an eCryptfs problem? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
On Fri, Jul 08, 2011 at 01:12:04PM -0400, Steve Clark wrote: So it does appear to be related to the memcpy change in libc. So eCryptfs is buggy, just fix it. The compatibility stuff that has been added to glibc to workaround buggy old programs was just for programs linked against old glibc. If you compile it again and you want it still working, fix it. It isn't that hard. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
2011/7/8 Jakub Jelinek ja...@redhat.com: On Fri, Jul 08, 2011 at 01:12:04PM -0400, Steve Clark wrote: So it does appear to be related to the memcpy change in libc. So eCryptfs is buggy, just fix it. The compatibility stuff that has been added to glibc to workaround buggy old programs was just for programs linked against old glibc. If you compile it again and you want it still working, fix it. It isn't that hard. I'll try tomorrow, I hope it is obvious bug. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
On 07/08/2011 01:19 PM, Michał Piotrowski wrote: 2011/7/8 Jakub Jelinekja...@redhat.com: On Fri, Jul 08, 2011 at 01:12:04PM -0400, Steve Clark wrote: So it does appear to be related to the memcpy change in libc. So eCryptfs is buggy, just fix it. The compatibility stuff that has been added to glibc to workaround buggy old programs was just for programs linked against old glibc. If you compile it again and you want it still working, fix it. It isn't that hard. I'll try tomorrow, I hope it is obvious bug. memove should be used if areas overlap that are being copied. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
On Fri, Jul 08, 2011 at 01:27:45PM -0400, Steve Clark wrote: memove should be used if areas overlap that are being copied. If they overlap or may overlap. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development only package?
On Fri, Jul 8, 2011 at 11:48 AM, Toshio Kuratomi a.bad...@gmail.com wrote: The tarball (I actually downloaded the zip but I hope that upstream made the tarball contain identical files :-) seems to compile fine on its own: cd scripts cmake CMakeLists.txt make ls -al libpugixml.a -rw-rw-r--. 1 badger badger 342992 Jul 8 09:42 libpugixml.a Thanks, I don't know why I didn't look there, I guess I was looking for some sort of makefile in the root of the archive. Should I package it as pugixml-devel only? Or just pugixml? Since only static libraries are created you should be able to use these guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries I'll take a look. Thanks! Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development only package?
Ok, another question. I edited the CMakeLists.txt and changed the STATIC to SHARED and it compiled without issue creating a shared library. Is there any down side to doing this? I guess now I have something for the pugixml package and then can create a -devel subpackage with the header file and API documentation. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development only package?
On Fri, Jul 8, 2011 at 12:48 PM, Toshio Kuratomi wrote: On Fri, Jul 08, 2011 at 10:06:56AM -0500, Richard Shaw wrote: I'm working on making a package of OpenImageIO[1] which is used by a new branch of blender, blender-cycles[2], which uses the cycles rendering engine[3]. There appears to be one bundled library, pugixml[4] but it's only 3 files (1 c, and 2 header files) and doesn't not compile on it's own. It looks to be designed intentionally to be built in to other programs. The tarball (I actually downloaded the zip but I hope that upstream made the tarball contain identical files :-) seems to compile fine on its own: cd scripts cmake CMakeLists.txt make ls -al libpugixml.a -rw-rw-r--. 1 badger badger 342992 Jul 8 09:42 libpugixml.a What about the case where the upstream tarball is not directly capable of generating a dynamic or static library? This is the situation for a review that I am doing [1]. vmpk bundles the rtmidi [2], but rtmidi is not available as an independent library. It consists of 1 source and 2 header files and is designed to be bundled in other software. Is it okay to bundle rtmidi in our vmpk package? Thanks, Orcan [1] https://bugzilla.redhat.com/show_bug.cgi?id=710917 [2] http://www.music.mcgill.ca/~gary/rtmidi/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
[ removing extraneous copy of old Fedora devel list ] On Fri, 2011-07-08 at 09:57 -0400, Steve Dickson wrote: On 07/08/2011 08:23 AM, Lennart Poettering wrote: I am pretty sure systemd-devel is the better place to discuss this. But here are a few comments after reading throught the bug report: I didn't know it existed... My $0.02 on this is that this conversation *explcitly* *does not* belong on systemd-devel. I subscribed to that list to monitor for such conversations, but most people aren't going to do that. Problems with Fedora packaging, in the Fedora distribution should be discussed here. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development only package?
On Fri, Jul 08, 2011 at 12:46:37PM -0500, Richard Shaw wrote: Ok, another question. I edited the CMakeLists.txt and changed the STATIC to SHARED and it compiled without issue creating a shared library. Is there any down side to doing this? I guess now I have something for the pugixml package and then can create a -devel subpackage with the header file and API documentation. The downside is that the dynamic linker has a limited understanding of versioning so that libfoo.so.2 and libfoo.so.3 are considered incompatible but libfoo.so.2.0 and libfoo.so.2.1 are compatible. If upstream is making releases of its libraries without thinking about compatibility and versioning you may lead people to make false assumptions about this. The best bet here is to talk to the pugixml upstream, letting them know how easy it is to build shared libraries and asking if they're interested in managing their versions appropriately for that use case. -Toshio pgpI7tWMP9otR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development only package?
On Fri, Jul 8, 2011 at 2:50 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, Jul 08, 2011 at 12:46:37PM -0500, Richard Shaw wrote: Ok, another question. I edited the CMakeLists.txt and changed the STATIC to SHARED and it compiled without issue creating a shared library. Is there any down side to doing this? I guess now I have something for the pugixml package and then can create a -devel subpackage with the header file and API documentation. The downside is that the dynamic linker has a limited understanding of versioning so that libfoo.so.2 and libfoo.so.3 are considered incompatible but libfoo.so.2.0 and libfoo.so.2.1 are compatible. If upstream is making releases of its libraries without thinking about compatibility and versioning you may lead people to make false assumptions about this. The best bet here is to talk to the pugixml upstream, letting them know how easy it is to build shared libraries and asking if they're interested in managing their versions appropriately for that use case. Well I went ahead and created a shared library package with soname, for now it's the same as the version. I submitted the patch upstream so we'll see what they think. Thanks for the help! Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Fri, 08.07.11 14:52, Jon Masters (jonat...@jonmasters.org) wrote: I am pretty sure systemd-devel is the better place to discuss this. But here are a few comments after reading throught the bug report: I didn't know it existed... My $0.02 on this is that this conversation *explcitly* *does not* belong on systemd-devel. I subscribed to that list to monitor for such conversations, but most people aren't going to do that. Problems with Fedora packaging, in the Fedora distribution should be discussed here. This is not really about packaging, more about writing unit files. Since unit files are intended to be included upstream this is better discussed on systemd-devel. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development only package?
On Fri, Jul 08, 2011 at 01:50:34PM -0400, Orcan Ogetbil wrote: What about the case where the upstream tarball is not directly capable of generating a dynamic or static library? This would not be a guarantee that it is okay to bundle the library. It would be one indicator but not the most important one. This is the situation for a review that I am doing [1]. vmpk bundles the rtmidi [2], but rtmidi is not available as an independent library. It consists of 1 source and 2 header files and is designed to be bundled in other software. Is it okay to bundle rtmidi in our vmpk package? You're definitely getting into a grey area here and may well want to submit this case to the FPC for an exception. Process and standard questions to answer here: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions In general, if the library is being distributed as a separate upstream, you can err on the side of making it available as a library and the packaging guidelines will be happy but to bundle it you'll have to show that there's a good reason for that. The idea is that as the library upstream releases new code the apps need to be kept up-to-date with that new code. Sometimes this is because the library is making security fixes which means that we have to update. Sometimes it's because some API is changing incompatibly and the library upstream is not going to put any maintainance effort into the old API. The latter can tempt upstream apps to bundle the library. But unless they simultaneously commit to maintaining their fork of the code in case of the former problems, we end up being on the hook to audit and produce security fixes for the bundled libraries at a later date. If the software is designed to be bundled into other software and modified by those consuming the code (with appropriate records of that on upstream websites, etc) then the FPC may grant an exception but we will have an easier time granting an exception if it can be shown that the application doing the bundling recognizes that they're assuming the burden of fixing the bundled library, are capable of making security fixes to the bundled library and understand the gravity of what they're doing. In many cases, upstreams only look at the short term cost savings of being able to take someone else's implementation of something into their code base without thinking about the long term cost of maintaining that foreign code into the future. -Toshio pgpLe1ngTaIfh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need Support For Hardware Live Usb Issue + Bugs version 0.1
I have Dell Xps 15 with config:- 8 Gb RAM 2nd generation i7 processor 2.2 GHz Boost 2.0 upto 3.30 GHz Dual Graphics Card Intel HD 3000 nvidia geforce GT 540M with Optimus Techonology 720 GB hardisk Motherboard Dell XPS system L502X Intel centrino 6230 Network Card with BT 3.0 I have installed 2 linux distro on my External USB portable seagate 500 GB hardisk fedora 15 Ubuntu 11.04. i have installed these distro by using HP pavilion dv 2762 tx with config:- Core2duo 1.83Ghz 2Gb ram nvidia geforce 9600m graphics card Both these distro works with all other older laptops Like HP, Dell studio 1 yr old config , Compaq 5 yr old, but not on my Dell XPS 15. To check my laptops hardware compatibility i used a Ubuntu 10.10 live Cd. it works fine . i use this cd as a live media but when i tried same Ubuntu 10.10 on live usb it gives blank screen or error which i mentioned below. To check that my iso file damaged or my download has been corrupted or not, i tried different distros with different desktop enviornment like Gnome,KDE,Xcfe Lxde. i tried fedora 15, ubuntu 10.10, ubuntu 10.04, ubuntu 11.04. slackware,eduboss each with avail flavors. But all i have tried gives almost same error with each distro. i don't know what is this some kind of bug or lack of support with dell chipset (hardware). if live cd boots well then i think there is nohardware compatibility issue with linux. I think this is lack of usb support because may be Linux has no support until now for latest motherboards or hardware architects. These are the errors i got with different distros. i am not able to figure out what's going on bcz i'm rookie in Linux programming. But if anyone can do it, plz help me i haven't run my linux from previous 1 and half month and i'm a linux addicted. starting from Fedora 15 gnome(almost same for kde except starting numbers) error:- [ 2.571729] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED [ 2.571847] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED Dropping to debug shell. sh.can't acess tty:job control off dracut:/# Fedora 15 LXDE [ 2.514402] nonveau :01:00.0:invalid ROM contents [ 2.614971] [drm] nonveau :01:00.0:POINTER to BIT load vol table invalid [ 2.639331] [drm] nonveau :01:00.0:0xd518:12cwr fail: -6 [ 2.75332] [drm] nonveau :01:00.0:PGRAPH:unsupported chipset,please report! [ 2.753646] [drm] nonveau :01:00.0:PGRAPH:unknown config:2/0/0/0,1 [ 2.755342] [drm] nonveau :01:00.0: failed to load fuc 409 d [ 2.919340] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED [ 2.919447] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED Dropping to debug shell. sh.can't acess tty:job control off dracut:/# Fedora 15 XCFE [ 2.563563] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED [ 2.563680] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED Dropping to debug shell. sh.can't acess tty:job control off dracut:/# EDUBOSS (Debian derivative) (I apologize but i have write the full error i got bcz may be it helps somebody to find what's going on) BOOT FAILED ! The debian live image failed to boot. Please file a bug against the 'live-initramfs' package or email the debian Live mailing list at debian-l...@lists.debian.org make sure to note the exact version, name and distribution of the image you were attempt to boot. The file /live.log contains same debugging information but booting with debug command line parameter will greatly increase it's verbosity which is extremely useful when diagnosing issues. live-initramfs will start a shell. The error message was: Unable to find a medium containing a live file system. Busy Box v.1.10.2 (Debian 1:1.10.2-2) built in shell (ash) Enter 'help' for a list of built in commands. bin/sh:can't access tty:job control turned off (initramfs)- Ubuntu 11.04 Gnome Black screen nothing. Ubuntu 10.10 10.04 gnome (Both gave same error Backtrack 5 also bcz it is ubuntu 10.04 based distro) GLIB_(some kind of error i could note bcz it stays for few seconds) stdin:error0 /init:line7:can't open /dev/sr0:no medium found /init:line7:can't open /dev/sr0:no medium found same error repeating I also tried to check disc for error option but same error as above . Slackware Bcz it's command line it has direct option of installation no live media. I have created live usb using unetbootin latest version. if i get any update regarding problem soon i'll release it's second version. lolz!!! [?][?] [?][?][?][?] Regards Navdeep Singh 338.png360.gif-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need Support For Hardware Live Usb Issue + Bugs version 0.1
I have Dell Xps 15 with config:- 8 Gb RAM 2nd generation i7 processor 2.2 GHz Boost 2.0 upto 3.30 GHz Dual Graphics Card Intel HD 3000 nvidia geforce GT 540M with Optimus Techonology 720 GB hardisk Motherboard Dell XPS system L502X Intel centrino 6230 Network Card with BT 3.0 I have installed 2 linux distro on my External USB portable seagate 500 GB hardisk fedora 15 Ubuntu 11.04. i have installed these distro by using HP pavilion dv 2762 tx with config:- Core2duo 1.83Ghz 2Gb ram nvidia geforce 9600m graphics card Both these distro works with all other older laptops Like HP, Dell studio 1 yr old config , Compaq 5 yr old, but not on my Dell XPS 15. To check my laptops hardware compatibility i used a Ubuntu 10.10 live Cd. it works fine . i use this cd as a live media but when i tried same Ubuntu 10.10 on live usb it gives blank screen or error which i mentioned below. To check that my iso file damaged or my download has been corrupted or not, i tried different distros with different desktop enviornment like Gnome,KDE,Xcfe Lxde. i tried fedora 15, ubuntu 10.10, ubuntu 10.04, ubuntu 11.04. slackware,eduboss each with avail flavors. But all i have tried gives almost same error with each distro. i don't know what is this some kind of bug or lack of support with dell chipset (hardware). if live cd boots well then i think there is nohardware compatibility issue with linux. I think this is lack of usb support because may be Linux has no support until now for latest motherboards or hardware architects. These are the errors i got with different distros. i am not able to figure out what's going on bcz i'm rookie in Linux programming. But if anyone can do it, plz help me i haven't run my linux from previous 1 and half month and i'm a linux addicted. starting from Fedora 15 gnome(almost same for kde except starting numbers) error:- [ 2.571729] [drm:intel_drm_platform_mux_ info] *ERROR* MUX INFO CALL FAILED [ 2.571847] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED Dropping to debug shell. sh.can't acess tty:job control off dracut:/# Fedora 15 LXDE [ 2.514402] nonveau :01:00.0:invalid ROM contents [ 2.614971] [drm] nonveau :01:00.0:POINTER to BIT load vol table invalid [ 2.639331] [drm] nonveau :01:00.0:0xd518:12cwr fail: -6 [ 2.75332] [drm] nonveau :01:00.0:PGRAPH:unsupported chipset,please report! [ 2.753646] [drm] nonveau :01:00.0:PGRAPH:unknown config:2/0/0/0,1 [ 2.755342] [drm] nonveau :01:00.0: failed to load fuc 409 d [ 2.919340] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED [ 2.919447] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED Dropping to debug shell. sh.can't acess tty:job control off dracut:/# Fedora 15 XCFE [ 2.563563] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED [ 2.563680] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED Dropping to debug shell. sh.can't acess tty:job control off dracut:/# EDUBOSS (Debian derivative) (I apologize but i have write the full error i got bcz may be it helps somebody to find what's going on) BOOT FAILED ! The debian live image failed to boot. Please file a bug against the 'live-initramfs' package or email the debian Live mailing list at debian-l...@lists.debian.org make sure to note the exact version, name and distribution of the image you were attempt to boot. The file /live.log contains same debugging information but booting with debug command line parameter will greatly increase it's verbosity which is extremely useful when diagnosing issues. live-initramfs will start a shell. The error message was: Unable to find a medium containing a live file system. Busy Box v.1.10.2 (Debian 1:1.10.2-2) built in shell (ash) Enter 'help' for a list of built in commands. bin/sh:can't access tty:job control turned off (initramfs)- Ubuntu 11.04 Gnome Black screen nothing. Ubuntu 10.10 10.04 gnome (Both gave same error Backtrack 5 also bcz it is ubuntu 10.04 based distro) GLIB_(some kind of error i could note bcz it stays for few seconds) stdin:error0 /init:line7:can't open /dev/sr0:no medium found /init:line7:can't open /dev/sr0:no medium found same error repeating I also tried to check disc for error option but same error as above . Slackware Bcz it's command line it has direct option of installation no live media. I have created live usb using unetbootin latest version. if i get any update regarding problem soon i'll release it's second version. lolz!!! Regards Navdeep Singh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
On Fri, Jul 8, 2011 at 11:54 AM, Lennart Poettering mzerq...@0pointer.de wrote: This is not really about packaging, more about writing unit files. Since unit files are intended to be included upstream this is better discussed on systemd-devel. There is some benefit in making it possible for distribution packagers to be aware of the these sorts of unit file writing pitfall conversations. I'm not saying the discussion needs to be here. But cherry-picking some salient to make us aware of, once and awhile, with some good meaty examples of sysv styled pitfalls wouldn't hurt. In fact it could be quite instructive for many of us. I think a lot of us firmly entrenched at the distribution level have a lot of shell scripting unlearning to do in how we approach service init. As hard as learning is, unlearning is that much harder. it can be difficult to pick these conversations out of the chatter here or on the systemd list (cant keep up with every conversation). That being said you might consider organizing a compendium of such pitfalls and adding it to your growing amount of tutorial documentation for a handy reference if you haven't already begun doing that already (and you may have and I've missed it). -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage: Cleanup of Red Hat located systems - 2011-07-11 20:00 UTC
Outage: Cleanup of Red Hat located systems - 2011-07-11 20:00 UTC To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2011-07-11 20:00 UTC' Reason for outage: We will be removing old systems and putting in new ones at the Red Hat colocation facility in Phoenix. At the moment outages are planned for 2011-07-12 00:00 UTC - Secondary Architecutures - QA systems - some Fedora community hardware No other outages are planned, but deracking of old machines and racking new ones could result in outages or instability in existing services. Due to the nature of the work, while we will try to send out daily announcements of what services will be affected that day, the primary source of information will need to be announced on Freenode IRC #fedora-admin Affected Services: QA Services Secondary Architectures Possibly Affected Services: BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ Docs - http://docs.fedoraproject.org/ GIT / Source Control Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Insight- https://insight.fedoraproject.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager- https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Email system Fedora Hosted - https://fedorahosted.org/ Fedora People - http://fedorapeople.org/ Torrent - http://torrent.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2870 Contact Information: Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: biosdevname in fedora 15 - why is this inconsistency?
shyam_i...@dell.com wrote: Can you create a BZ with the following output.. ? sudo /sbin/biosdevname -d sudo /usr/sbin/dmidecode sudo /usr/sbin/biosdecode lspci -tv https://bugzilla.redhat.com/show_bug.cgi?id=720068 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintaining and/or help for qucs and freehdl
On Sun, Jul 03, 2011 at 22:30:01 +0200, Eric Tanguy eric.tan...@gmail.com wrote: At the same time qucs-0.0.16 were out a new version of freehdl appeared 0.0.8 but when i try to build it i have an error about rpath and i don't know how to solve it : Could you help me for this problem also ? I did a local build of freehdl 0.0.8 and I didn't get an rpath warning. I ran rpmlint on the output rpm and didn't see any reference to rpath. (There were some other things that were complained about.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
Hi, thanks for your answer. I had looked in the rpm and I suppose you mean this file: /lib/udev/rules.d/71-biosdevname.rules it doesn't talk pci ports/slots, but your explanation of biosdevname is enough for me, I hope the man page will be updated in the future. On Fri, Jul 8, 2011 at 5:32 PM, Peter Robinson pbrobin...@gmail.com wrote: On Fri, Jul 8, 2011 at 2:13 PM, Kevin Wilson wkev...@gmail.com wrote: Hello, I have biosdevname-0.3.8-1.fc15.x86_64 on fedora 15 machine. I see from man biosdevname , that the name of the devices should be: .. emport for embedded NICs pcislot#port_virtual instance for cards in PCI slots .. ifconfig shows I have em1, p2p1; indded em1 is embedded NICs. However , the second nic is PCI nic. Why does it not defined as pcislot#port? is this some udev definition (some policy) which sets other names for pci nics ? any idea where this policy is defined and how can I choose a different policy ? Have a look in the rpm and you'll see the rule file listed. p2 is pci slot 2 and p1 is port 1. Looks consistent to me. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 719874] New: perl-threads-lite keeps hanging during self checks
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-threads-lite keeps hanging during self checks https://bugzilla.redhat.com/show_bug.cgi?id=719874 Summary: perl-threads-lite keeps hanging during self checks Product: Fedora Version: rawhide Platform: powerpc OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-threads-lite AssignedTo: ppi...@redhat.com ReportedBy: kars...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com, psab...@redhat.com Blocks: 718269 Classification: Fedora Story Points: --- Description of problem: During a mass rebuild on PPC and PPC64, perl-threads-lite-0.031-2.fc16 gets stuck while doing self checks on ppc. ppc64 completed the build just fine. I have to either cancel the job or wait until mock gets a timeout. Here's where it is hanging: # Testing threads::lite 0.031, Perl 5.012003, /usr/bin/perl t/00-load.t ... ok t/10-basics.t . Failed 5/6 subtests Version-Release number of selected component (if applicable): perl-threads-lite-0.031-2.fc16 Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=249482 Note how ppc64 completed the build within 2 minutes and ppc was still working on it after more than 9 hours when I've canceled the job. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 719874] perl-threads-lite keeps hanging during self checks
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=719874 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED External Bug ID||CPAN 69354 --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-07-08 06:31:46 EDT --- Subtests 2--5 in t/10-basics.t fails (inter-thread message queue) and the only subtest in t/11-input.t dead-locks. I will pass the problem to upstream, however don't be disappointed. Upstream usually lacks of specific hardware and it usually blame us that Fedora does not package perl well. OTOH this package has not yet been tested on ppc according http://matrix.cpantesters.org/?dist=threads-lite%200.031;reports=1;os=linux;perl=5.12.3. I can exclude ppc architecture from this package as a quick work-around. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-MapUTF8] Add perl(:MODULE_COMPAT_*) dependency
commit 6931b72e31eccc72efb6fa5af4095446ed11b42f
Author: Paul Howarth p...@city-fan.org
Date: Fri Jul 8 12:29:47 2011 +0100
Add perl(:MODULE_COMPAT_*) dependency
perl-Unicode-MapUTF8.spec |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Unicode-MapUTF8.spec b/perl-Unicode-MapUTF8.spec
index 4fc90d3..a4f149a 100644
--- a/perl-Unicode-MapUTF8.spec
+++ b/perl-Unicode-MapUTF8.spec
@@ -1,6 +1,6 @@
Name: perl-Unicode-MapUTF8
Version:1.11
-Release:13%{?dist}
+Release:14%{?dist}
Summary:Conversions to and from arbitrary character sets and UTF8
@@ -15,6 +15,7 @@ BuildRequires: perl(ExtUtils::MakeMaker), perl(Jcode)
BuildRequires: perl(Unicode::Map), perl(Unicode::Map8), perl(Unicode::String)
BuildRequires: perl(Test::More), perl(Test::Pod), perl(Test::Pod::Coverage)
BuildRequires: perl(Test::Distribution)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Unicode::MapUTF8 Provides an adapter layer between core routines for
@@ -61,11 +62,14 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Jul 8 2011 Paul Howarth p...@city-fan.org - 1.11-14
+- Add perl(:MODULE_COMPAT_*) dependency
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.11-13
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 1.11-12
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.11-11
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-MapUTF8] Created tag perl-Unicode-MapUTF8-1.11-14.fc16
The lightweight tag 'perl-Unicode-MapUTF8-1.11-14.fc16' was created pointing to: 6931b72... Add perl(:MODULE_COMPAT_*) dependency -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-Map8] Add perl(:MODULE_COMPAT_*) dependency
commit 5c77ebca7a8f4327bfc152da8419b2c1a9f5de28
Author: Paul Howarth p...@city-fan.org
Date: Fri Jul 8 12:42:02 2011 +0100
Add perl(:MODULE_COMPAT_*) dependency
perl-Unicode-Map8.spec |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Unicode-Map8.spec b/perl-Unicode-Map8.spec
index a5310fb..1987e44 100644
--- a/perl-Unicode-Map8.spec
+++ b/perl-Unicode-Map8.spec
@@ -2,7 +2,7 @@
Name: perl-Unicode-Map8
Version:0.13
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Mapping table between 8-bit chars and Unicode for Perl
@@ -15,6 +15,7 @@ Patch1: perl-Unicode-Map8-0.12-type.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker), perl(Unicode::String)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -71,11 +72,14 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Jul 8 2011 Paul Howarth p...@city-fan.org - 0.13-5
+- Add perl(:MODULE_COMPAT_*) dependency
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.13-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-3
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-2
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-Map8] Created tag perl-Unicode-Map8-0.13-5.fc16
The lightweight tag 'perl-Unicode-Map8-0.13-5.fc16' was created pointing to: 5c77ebc... Add perl(:MODULE_COMPAT_*) dependency -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-Map] Add perl(:MODULE_COMPAT_*) dependency
commit 84606c59ab7919c33d7c8ad64f9940faa7eac85c
Author: Paul Howarth p...@city-fan.org
Date: Fri Jul 8 12:51:00 2011 +0100
Add perl(:MODULE_COMPAT_*) dependency
perl-Unicode-Map.spec |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Unicode-Map.spec b/perl-Unicode-Map.spec
index 138c847..35d7cdd 100644
--- a/perl-Unicode-Map.spec
+++ b/perl-Unicode-Map.spec
@@ -2,7 +2,7 @@
Name: perl-Unicode-Map
Version:0.112
-Release:20%{?dist}
+Release:21%{?dist}
Summary:Perl module for mapping charsets from and to utf16 unicode
@@ -13,6 +13,7 @@ Source0:
http://www.cpan.org/authors/id/M/MS/MSCHWARTZ/Unicode-Map-0.112.
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This module converts strings from and to 2-byte Unicode UCS2
@@ -75,11 +76,14 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Jul 8 2011 Paul Howarth p...@city-fan.org - 0.112-21
+- Add perl(:MODULE_COMPAT_*) dependency
+
* Wed Feb 09 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.112-20
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.112-19
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.112-18
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Unicode-Map] Created tag perl-Unicode-Map-0.112-21.fc16
The lightweight tag 'perl-Unicode-Map-0.112-21.fc16' was created pointing to: 84606c5... Add perl(:MODULE_COMPAT_*) dependency -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
