Question of forbiddeness: rippit
Howdy, all. As a weekend project, I created 'rippit', a super simple no-frills command line CD ripper. It aims to take zero parameters and produce lossless rips in .flac format, properly tagged with musicbrainz, etc. In the future, I plan on extending it to also rip DVDs in the same fashion. i.e. type 'rippit' and it finds your DVD drive and starts ripping the video to some free format like mkv, theora, or somesuch. Haven't decided yet.. Rippit is built entirely using gstreamer packages that are available in Fedora. When I add DVD support, I plan on making the relevant non-free decoders and elements accessible via rpmfusion.org a pure runtime dependency. No linking, no failure to compile, etc. As such, it doesn't directly do anything more than what you can do via gst-launch. When dvd ripping is later added, would this put rippit at risk of not being included in fedora (and potentially other copyright-wary distros)? I can't imagine it would, since you can achieve exactly the same result that rippit provides (in the future) by running gst-launch. -- Trever Fischer (tdfischer) Fedora Ambassador, KDE Hacker http://wm161.net GPG: C40F2998 hkp://wwwkeys.pgp.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110326 changes
Compose started at Sat Mar 26 13:15:49 UTC 2011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: > IIRC you can set: > NM_CONTROLLED="no" > in /etc/sysconfig/network-scripts/ifcfg-ethX > Supposedly that will take ethX off the reservation and allow you to use the > ifup > script and ifconfig utility as you traditionally would. I remain unconvinced that in rawhide it's possibly to truly instruct all these wonderful bells and whistles to leave an interface alone. In the end, I gave up and used a system without NM or any of the other stuff, since turning it off for a few minutes was getting too involved. On that other system, adding a manual ARP entry and an interface alias with another IP stuck, didn't change randomly, and did what I wanted. Not very web 2.0 I know, but I like it that way. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ixgbe/udev mystery
2011/3/26 Andy Gospodarek > [...] > I don't have any great suggestions about why this is broken, but I would > suggest you open a bug at bugzilla.redhat.com with the full details of > this failure. If you let me know what the bug # is (email is fine) > after you open it, I'll make sure the right folks take a look. > Done, bug ID is 691122. Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Axel Thimm: Unresponsive maintainer?
On Sat, 26 Mar 2011 14:41:31 -0600 Stephen John Smoogen wrote: > > I have someone very interested in taking over > > mediawiki-openid and php-pear-Auth-OpenID, so I will probably > > approve them for those packages soon since they are both very > > broken and need love, but I wonder how many of the others are in > > the same state. :( > > Who? I need help on them for the new mediawiki packages. Kurt Seifried has fixed up those two packages and I've set them up to co-maintain for now. Hopefully he will be interested in getting more involved now as well. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Axel Thimm: Unresponsive maintainer?
On Sat, Mar 26, 2011 at 14:41, Stephen John Smoogen wrote: > On Sat, Mar 26, 2011 at 11:52, Kevin Fenzi wrote: > > Who? I need help on them for the new mediawiki packages. > s/new/EPEL/ sorry about that. And sorry for not cropping list on a private email. -- 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: Axel Thimm: Unresponsive maintainer?
On Sat, Mar 26, 2011 at 11:52, Kevin Fenzi wrote: > Greetings. > > Does anyone have a means to contact Axel Thimm and confirm he's ok and > if he wishes to maintain his packages in Fedora moving forward? > (I've cc'ed him on this as well). > > The last commit I see from him was > http://lists.fedoraproject.org/pipermail/scm-commits/2010-November/516359.html > Wed Nov 3 2010 > > I mailed him privately on Feb 20th with no reply. > > He has 27 packages with owner/commit/approveacls: > > https://admin.fedoraproject.org/pkgdb/users/packages/athimm?acls=owner&acls=approveacls&acls=commit > > He has 60 bugs assigned: > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&emailtype2=substring&bug_status=NEW&bug_status=ASSIGNED&email2=Axel.Thimm%40ATrpms.net&emailassigned_to2=1&classification=Fedora > > I have someone very interested in taking over > mediawiki-openid and php-pear-Auth-OpenID, so I will probably approve > them for those packages soon since they are both very broken and need > love, but I wonder how many of the others are in the same state. :( Who? I need help on them for the new mediawiki packages. -- 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
Axel Thimm: Unresponsive maintainer?
Greetings. Does anyone have a means to contact Axel Thimm and confirm he's ok and if he wishes to maintain his packages in Fedora moving forward? (I've cc'ed him on this as well). The last commit I see from him was http://lists.fedoraproject.org/pipermail/scm-commits/2010-November/516359.html Wed Nov 3 2010 I mailed him privately on Feb 20th with no reply. He has 27 packages with owner/commit/approveacls: https://admin.fedoraproject.org/pkgdb/users/packages/athimm?acls=owner&acls=approveacls&acls=commit He has 60 bugs assigned: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&emailtype2=substring&bug_status=NEW&bug_status=ASSIGNED&email2=Axel.Thimm%40ATrpms.net&emailassigned_to2=1&classification=Fedora I have someone very interested in taking over mediawiki-openid and php-pear-Auth-OpenID, so I will probably approve them for those packages soon since they are both very broken and need love, but I wonder how many of the others are in the same state. :( Hope he's ok and will return to Fedora someday. If someone can get a hold of him, we should at least get co-maintainers for his packages so he doesn't need to worry about them. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ixgbe/udev mystery
On Fri, Mar 25, 2011 at 07:01:02PM +0100, Thomas Bendler wrote: > 2011/3/25 Thomas Bendler > > > [...] > > > One remark, the error occured with the standard ixgbe module (2.0.62-k2), so > > I upgraded the module to the latest version (3.2.10-NAPI) but still have the > > same error. > > > > And another remark, the network card work without problems when using Ubuntu > 11.04.2 instead of Fedora (ixgbe driver version 2.0.44-k2). > So like the older Ubuntu driver works fine, but newer drivers in Fedora or the Intel SourceForge driver are problematic. It sounds like you must be either failing an additional check that was added or hitting some sort of regression that was introduced between driver version 2.0.44-k2 and 2.0.62-k2. I don't have any great suggestions about why this is broken, but I would suggest you open a bug at bugzilla.redhat.com with the full details of this failure. If you let me know what the bug # is (email is fine) after you open it, I'll make sure the right folks take a look. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora on USB flash drive is broken on update
Am 26.03.2011 18:13, schrieb Xose Vazquez Perez: > hi, > > every time I do "yum -y update" on a usb stick the system broke. > tested on two diferent machines with two diferent usb sticks > > can anyone verify it ? > > https://bugzilla.redhat.com/show_bug.cgi?id=682597 Maybe you "overlay-space" ran full You should also exclude kernel because it would be installed and fill your overlay-space but by deign of a live-medium it will never be used signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora on USB flash drive is broken on update
hi, every time I do "yum -y update" on a usb stick the system broke. tested on two diferent machines with two diferent usb sticks can anyone verify it ? https://bugzilla.redhat.com/show_bug.cgi?id=682597 -- «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra; que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y dé pecho a mi valor.» -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
wireless-tools is DEPRECATED
hi, wireless-tools is deprecated since time ago. iw/rfkill should be used instead it. these packages still depend on it: conky dracut-modules-olpc i3status knemo olpc-netutils python-iwlib wavemon weplab wicd wifi-radar wifiroamd wlassistant xsupplicant https://bugzilla.redhat.com/show_bug.cgi?id=687924 -- «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra; que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y dé pecho a mi valor.» -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
net-tools must die
hi, net-tools ( http://net-tools.berlios.de/ ) is deprecated since time ago. iproute is the way to go. net-tools future http://lists.debian.org/debian-devel/2009/03/thrd2.html#00780 Original Message Subject: net-tools future Date: Sun, 15 Mar 2009 17:30:18 From: Martín Ferrari To: debian-devel@@lists.debian.org Hi, Luk Claes and me, as the current maintainers of net-tools, we've been thinking about it's future. Net-tools has been a core part of Debian and any other linux based distro for many years, but it's showing its age. It doesnt support many of the modern features of the linux kernel, the interface is far from optimal and difficult to use in automatisation, and also, it hasn't got much love in the last years. On the other side, the iproute suite, introduced around the 2.2 kernel line, has both a much better and consistent interface, is more powerful, and is almost ten years old, so nobody would say it's untested. Hence, our plans are to replace net-tools completely with iproute, maybe leading the route for other distributions to follow. Of course, most people and tools use and remember the venerable old interface, so the first step would be to write wrappers, trying to be compatible with net-tools. At the same time, we believe that most packages using net-tools should be patched to use iproute instead, while others can continue using the wrappers for some time. The ifupdown package is obviously the first candidate, but it seems that a version using iproute has been available in experimental since 2007. So, the roadmap would be: - Send patches to net-tools using packages to use iproute instead - Development of the wrapper scripts - Uploading to experimental a net-tools-compat package, to allow wider testing. - Upload to unstable About the wrapper scripts: * ipconfig, route: the most difficult ones, both can be replaced by calls to "ip", maybe except for some obscure options. * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line * rarp should be dropped, as the linux kernel doesn't support it anymore, since the 2.3 series. The replacement, arpd, is already included in iproute. * ipmaddr works exactly as "ip maddr", in fact, the code is from the iproute sources. Same for iptunnel and "ip tunnel". In both cases, they're just replaced by a symlinkm, as the ip command recognises that. * nameif: can be replaced by "ip link", not sure if it's worth the effort (does anybody actually use it?) Problematic tools: * mii-tool: it could be dropped and replaced by a pointer to ethtool as it's not meant to be used automatically by scripts. On the other hand, it's distributed as a stand-alone tool [0] and we could do the same. * plipsetup, slattach: we don't know of any replacement for those, but could be distributed separately too. Also, it's dubious if anyone still uses them. 0: http://freshmeat.net/projects/mii-tool/ -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org ---end--- It's still required by: bontmia bwm-ng dracut egd firehol globus-common initscripts libguestfs netdump-server nmbscan ocfs2-tools ocsinventory-agent olpc-netutils openvpn openwsman rkhunter smokeping wicd wifi-radar wlassistant https://bugzilla.redhat.com/show_bug.cgi?id=687920 -- «Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra; que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y dé pecho a mi valor.» -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, Mar 26, 2011 at 07:24:24AM -0400, Jon Masters wrote: > On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: > > On 03/26/2011 12:05 PM, Jon Masters wrote: > > > Then it became necessary to: > > > > > > /etc/init.d/NetworkManager stop > > > > > > Then it became necessary to: > > > > > > systemctl disable NetworkManager.service > > > > The last two are equivalent to "service NetworkManager stop", which > > still works even with systemd. > > Nope. It doesn't :) I tried that, and as I said, NM restarted > immediately. The only way to stop it was to disable the service, and > even then something was unconfiguring the port on link loss. Argh. > > Jon. > IIRC you can set: NM_CONTROLLED="no" in /etc/sysconfig/network-scripts/ifcfg-ethX Supposedly that will take ethX off the reservation and allow you to use the ifup script and ifconfig utility as you traditionally would. Neil > > -- > 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
Re: Going off-line for a while
On Sat, Mar 26, 2011 at 9:04 AM, Paul F. Johnson wrote: > Hi, > > I'm going off for quite a bit as my new job dictates very little time > and having to endure the evils that is Win7. The Linux box will still be > on, just no time for much else on it. > > For some reason, I can't sign the vacation page, but that's currently > not much of an issue... > > Catch you all in a bit > > TTFN > > PFJ > -- > Vertraue mir, ich weiss, was ich mache... > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I was all ready to wish you a happy vacation... damn. Well, good luck with the new job! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Going off-line for a while
Hi, I'm going off for quite a bit as my new job dictates very little time and having to endure the evils that is Win7. The Linux box will still be on, just no time for much else on it. For some reason, I can't sign the vacation page, but that's currently not much of an issue... Catch you all in a bit TTFN PFJ -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-15 Branched report: 20110325 changes
On Fri, 25 Mar 2011 21:09:57 -0700, Garrett wrote: > On 3/25/2011 17:38, Branched Report wrote: > > Compose started at Fri Mar 25 13:15:31 UTC 2011 > > > > An empty list? Quick, ship it! > > In all seriousness, did something go wrong with the compose or are there > actually no depsolving problems? An empty "Branched Report" with no repodiff output at the bottom is an indication of a compose that failed. With regard to the depsolving problems, F-15 Branched currently contains 71 builds that suffer from broken deps: http://lists.fedoraproject.org/pipermail/test/2011-March/098183.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ixgbe/udev mystery
2011/3/26 Gilboa Davara > [...] > Have you tried using the latest ixgbe drivers from intel.com [1]? > It's far newer (v3.2.10) than the one shipped with the kernel and in the > past, I've had far less issues with it. > [...] > Yep, compiled and installed this one as well but same error. Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 07:05 -0400, Jon Masters wrote: > So, back in the good old days, one could just type this: > Just to try to get the interface left alone. Isn't "the way" just to put NM_CONTROLLED=no in the relevant interface config file? Even if you're not statically configuring an actual network at that point it should leave the device alone. Ta Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 12:23 +0100, Reindl Harald wrote: > Nobody stops you to disable Network-Manager, DHCP, AVAHI and the other > noob-crap > and write your /etc/sysconfig/network-scripts/ifcfg-eth0 manually as i do > everytime directly after the first boot and i guess the next 20 years > this will be the same on a unix-like system Right. This is exactly what I do on non-laptops. But I find NM useful for WiFi sometimes so I keep it installed...but now it seems it's becoming very difficult to just temporarily configure an interface that won't be touched when I plug/unplug a cable or whatnot. Really, there should be a better way that turning off every network service and script for the 5 minutes I want this. I have other machines, etc. and this is rawhide, but it's also the future. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Am 26.03.2011 12:24, schrieb Jon Masters: > On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: >> On 03/26/2011 12:05 PM, Jon Masters wrote: >>> Then it became necessary to: >>> >>> /etc/init.d/NetworkManager stop >>> >>> Then it became necessary to: >>> >>> systemctl disable NetworkManager.service >> >> The last two are equivalent to "service NetworkManager stop", which >> still works even with systemd. > > Nope. It doesn't :) I tried that, and as I said, NM restarted > immediately. The only way to stop it was to disable the service, and > even then something was unconfiguring the port on link loss. Argh. * prepare your static configuration * send all commands to stop/dsiable/start/mv in one line * your network is running signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Am 26.03.2011 12:05, schrieb Jon Masters: > Hello, > > So, back in the good old days, one could just type this: > > ifconfig eth0 some_temp_ip up > > Then it became necessary to: > > /etc/init.d/NetworkManager stop > > Then it became necessary to: > > systemctl disable NetworkManager.service > > Just to try to get the interface left alone. > > But when the link it's attached to drops, the settings are immediately > being dropped and the interface unconfigured. So, what have I missed? > What's the other thing that's trying to be all "helpful" but actually > preventing me from running TFTP usefully? Sure, I could plug it into a > switch and go all Windows 95 on this, but...I'd rather not. Nobody stops you to disable Network-Manager, DHCP, AVAHI and the other noob-crap and write your /etc/sysconfig/network-scripts/ifcfg-eth0 manually as i do everytime directly after the first boot and i guess the next 20 years this will be the same on a unix-like system the whole network-config can be like this replace 127.0.0.1 by your namservers, disable all things you do not need and type * chkconfig network on * service network start after the basic configuration [root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 IPADDR=192.168.1.2 NETWORK=192.168.1.0 GATEWAY=192.168.1.1 BROADCAST=192.168.1.255 NETMASK=255.255.255.0 TYPE=Ethernet BOOTPROTO=static ONBOOT=yes NM_CONTROLLED=no USERCTL=no IPV6INIT=no [root@srv-rhsoft:~]$ cat /etc/resolv.conf nameserver 127.0.0.1 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, 2011-03-26 at 12:10 +0100, Michel Alexandre Salim wrote: > On 03/26/2011 12:05 PM, Jon Masters wrote: > > Then it became necessary to: > > > > /etc/init.d/NetworkManager stop > > > > Then it became necessary to: > > > > systemctl disable NetworkManager.service > > The last two are equivalent to "service NetworkManager stop", which > still works even with systemd. Nope. It doesn't :) I tried that, and as I said, NM restarted immediately. The only way to stop it was to disable the service, and even then something was unconfiguring the port on link loss. Argh. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
Jon, have you seen nmcli? If you can't do what you want to with it, maybe a feature request is in order. I get the impression that NM will generally do the right thing for most people most of the time, and when we are hacking on firmware, running a tftp server and the like we might want to use nmcli to take a device temporarily from NM's clutches and take manual control. I'm not sure it that's possible though with the current nmcli. I tried nmcli dev disconnect iface eth0 on my netbook which was connected to wlan0 and had nothing on eth0 - it errored saying that eth0 wasn't active to start with. I think keeping NM running for the system is a good thing, taking one device over for your own purposes is a better thing to do *if possible* than disabling NM entirely. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On 03/26/2011 12:05 PM, Jon Masters wrote: > Then it became necessary to: > > /etc/init.d/NetworkManager stop > > Then it became necessary to: > > systemctl disable NetworkManager.service The last two are equivalent to "service NetworkManager stop", which still works even with systemd. -- Michel Alexandre Salim () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
manually fixing IPs
Hello, So, back in the good old days, one could just type this: ifconfig eth0 some_temp_ip up Then it became necessary to: /etc/init.d/NetworkManager stop Then it became necessary to: systemctl disable NetworkManager.service Just to try to get the interface left alone. But when the link it's attached to drops, the settings are immediately being dropped and the interface unconfigured. So, what have I missed? What's the other thing that's trying to be all "helpful" but actually preventing me from running TFTP usefully? Sure, I could plug it into a switch and go all Windows 95 on this, but...I'd rather not. Thanks, Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ixgbe/udev mystery
On Fri, 2011-03-25 at 19:01 +0100, Thomas Bendler wrote: > 2011/3/25 Thomas Bendler > [...] > > One remark, the error occured with the standard ixgbe module > (2.0.62-k2), so I upgraded the module to the latest version > (3.2.10-NAPI) but still have the same error. > > > And another remark, the network card work without problems when using > Ubuntu 11.04.2 instead of Fedora (ixgbe driver version 2.0.44-k2). > > Regards, Thomas > Have you tried using the latest ixgbe drivers from intel.com [1]? It's far newer (v3.2.10) than the one shipped with the kernel and in the past, I've had far less issues with it. - Gilboa [1] http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=14687&ProdId=2914&lang=eng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
