Unable to enable Pulseaudio Multicast/RTP receiver
Hello I m using Fedora 12 and I m trying to enable the Multicast/RTP receiver of pulseaudio. In the preferences window of the padevchooser applet, under the Multicast/RTP tab, the checkboxes are disabled. A Install button is available. When I click on this button, a window tells me that the file /usr/lib/pulse-0.9.19/modules/module-rtp-recv.so is needed. When I try to continue, packagekit try to install the package pulseaudio-0.9.19-2.fc12. Off course pulseaudio is already installed, and this process fails. Here is the list of pulseaudio RPMs installed : pulseaudio-gdm-hooks-0.9.21-2.fc12.i686 pulseaudio-utils-0.9.21-2.fc12.i686 pulseaudio-libs-0.9.21-2.fc12.i686 pulseaudio-libs-glib2-0.9.21-2.fc12.i686 pulseaudio-module-bluetooth-0.9.21-2.fc12.i686 pulseaudio-0.9.21-2.fc12.i686 pulseaudio-libs-zeroconf-0.9.21-2.fc12.i686 pulseaudio-module-gconf-0.9.21-2.fc12.i686 pulseaudio-libs-devel-0.9.21-2.fc12.i686 kde-settings-pulseaudio-4.3-15.1.noarch pulseaudio-module-x11-0.9.21-2.fc12.i686 alsa-plugins-pulseaudio-1.0.21-2.fc12.i686 projectM-pulseaudio-1.2.0-5.fc12.i686 So, how can I solve this problem, or is there another way to enable the multicast rtp receiver ? Thanks for your help Axel -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Help: No internet connection
On Mon, Dec 14, 2009 at 09:09:32PM +0100, Simon Schneebeli wrote: On 12/14/2009 08:52 PM, Craig White wrote: On Mon, 2009-12-14 at 20:40 +0100, Simon Schneebeli wrote: On 12/14/2009 05:58 PM, R. G. Newbury wrote: As for wicd: I used that when working with Ubuntu and was always quite happy. So let's give it a try: I downloaded wicd from here: http://atrpms.net/dist/f12/wicd/ It tells me the following: python-urwid is needed by package wicd-1.6.2.2-1.fc12.i686 (/wicd-1.6.2.2-1.fc12.i686) So I get python-urwid from http://atrpms.net/dist/f12/python-urwid/ Test Transaction Errors: file /usr/lib/python2.6/site-packages/urwid-0.9.8.4-py2.6.egg-info from install of python-urwid-0.9.8.4-3.fc12.i686 conflicts with file from package urwid-0.9.8.4-6.1.i386 urwid-0.9.8.4-6.1.i386 is not part of a Fedora repo, browsing the net indicates that this is from opensuse? You should uninstall urwid, point yum to ATrpms and just yum install wicd (if you want to use wicd). Geoff's advice to use wicd just creates another layer of headache that is unnecessary here. Forget installing the packages from Axel (atrpms) until you get comfortable with Fedora and repositories. Actually this is about mixing Fedora and opensuse, there third party repo usage just uncovered this. My experience with wicd on Ubuntu was actually really good, so if there is an easy way to do it on my computer and if furthermore this could help solve my problem, I'd be more than willing to give it a try. Simon -- Axel.Thimm at ATrpms.net pgpnYnBVljPIR.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: does fedora have anything requiring :mail rw access?
On Fri, Oct 09, 2009 at 03:31:45PM +0200, Michal Hlavinka wrote: I've got quite simple question from dovecot's upstream: Why do we have rw access on mails for mail group? There are two popular models for MTA/MDAs. Run as root and drop priviledges to the receiving user or run under another uid/gid (like using gid mail) which then needs write access to all mailboxes. So depending on the security model of the MTAs you use you may or may not need the mail group being able to write into your mailboxes. I wouldn't change it, because if you don't seem to need it then no process is obviously running as gid mail. And in case you do switch to another MTA/MDA with a different security model you will not be surpised by mails not being delivered. -- Axel.Thimm at ATrpms.net pgpLovO3NV1NZ.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are packages w/o necessary kernel modules allowed?
On Thu, Oct 15, 2009 at 12:51:01AM -0500, Bruno Wolff III wrote: Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time without having a version for a specific version Fedora. For example there is no rawhide version now and there was a long period without one for F11. I uploaded some F12 builds. about a month or so before the targeted release date (which means about now). I don't think that F11 was w/o dahdi-linux kmdls for any long period. Possibly it was during the F11 rawhide period that I looked and I didn't check back for a while after the release. Unfortunately my tdm card is in my only machine at home that has 3d graphics at all working using the drivers in Fedora. And I needed to go to rawhide to get that working more than I needed to having tdm card working (though in the end I got both). Give the current packages a try, if there are issues we'll get them fixed. `recursion' warnings due to rpm's limitation of macros depth (which has nothing to do with recursion), which is at 16, but in reality means about 3-4 nested macros. Yes. But I didn't see any clear instructions for how to work around it. It seems that for some people using --define can work around the problem if you know what to define. There was also a comment that you don't see the problem because of something in your environment but I didn't see any directions on how to set up a similar environment. I use --define kmdl_kernelsrcdir /.../, that's all. But the error is still just cosmetic, if I encounter it in a manual build, the build still succeeds. What I had to do for F12 is grab a spec file (that get's updates at the source) that was proposed for rpmfusion (but never got adopted by them) and then use an svn version of dahdi that has a fix for a change in the way the kernel is being built (some compatibility feature that got dropped in 2.6.32). That box has been extra unstable lately, though I don't know if that is do to 3D graphics or dahdi-linux. Have you tried the common src.rpm at ATrpms? Maybe you should check out ATrpms in a couple of days and see whether there is dahdi support for F12 there. I tried using the dahdi-linux src rpm while having atrpms-rpm-config installed, but hit the recursion problem and got stuck there. I would still have had the problem with the last released dahdi not working with 2.6.31 kernels. But fixing that would have taken the same route as with the path I ended up taking. -- Axel.Thimm at ATrpms.net pgp1NMNcpaKTG.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are packages w/o necessary kernel modules allowed?
On Wed, Oct 14, 2009 at 12:25:00PM -0500, Bruno Wolff III wrote: On Wed, Oct 14, 2009 at 18:31:03 +0200, Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time without having a version for a specific version Fedora. For example there is no rawhide version now and there was a long period without one for F11. Rawhide support has quite low demand and the kernel changes daily or more frequently in early rawhide, so any kernel bound support is outdated before it is released. We usually fire up the rawhide support about a month or so before the targeted release date (which means about now). I don't think that F11 was w/o dahdi-linux kmdls for any long period. There are issues trying to rebuild atrpms src rpms on fedora. Just grabbing atrms-rpm-config doesn't help with recursion issues that Alex doesn't see because of his custom environment. Who's Alex, and why doesn't atrms-rpm-config work? You may see `recursion' warnings due to rpm's limitation of macros depth (which has nothing to do with recursion), which is at 16, but in reality means about 3-4 nested macros. What I had to do for F12 is grab a spec file (that get's updates at the source) that was proposed for rpmfusion (but never got adopted by them) and then use an svn version of dahdi that has a fix for a change in the way the kernel is being built (some compatibility feature that got dropped in 2.6.32). That box has been extra unstable lately, though I don't know if that is do to 3D graphics or dahdi-linux. Have you tried the common src.rpm at ATrpms? Maybe you should check out ATrpms in a couple of days and see whether there is dahdi support for F12 there. -- Axel.Thimm at ATrpms.net pgpRRJRTbNBbo.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm-4.6.x friends for RHEL5 (was: hosts for rawhide build chroots - different rpm versions?)
Hi, On Tue, Apr 14, 2009 at 10:14:24PM +0300, Axel Thimm wrote: we are running a version of rpm 4.6.0 on rhel5. This is only so mock can populate chroots with rpms with stronger hashes rhel5's rpm doesnt support. All srpm creation now takes place in chroots so features of the target rpm are always available. Thanks for the explanation, Dennis. Can I get these tailored rpm rpms from somewhere? I just tried rebuilding rpm from rawhide on RHEL5 and the dependencies look endless. http://infrastructure.fedoraproject.org/builder-rpms/ This worked for quite a while including Bill's update to rpm, but since the util-linux-ng update in F11 a couple of weeks ago yum/rpm on the RHEL5 host fails on util-linux-ng with [...] Running Transaction error: util-linux-ng-2.14.2-11.fc11: Header V3 RSA/SHA256 signature: BAD, key ID d22e77f2 Warning: scriptlet or other non-fatal errors occurred during transaction. [...] Other packages (even built later than util-linux-ng-2.14.2-11.fc11) install fine, the keys are installed, and I even tried with --nogpgcheck. Shouldn't --nogpgcheck avoid the test in the first place, and why does it fail (only) on util-linux-ng? -- Axel.Thimm at ATrpms.net pgpNow64KJuoM.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: how to determain those no longer required packages
On Mon, Aug 31, 2009 at 10:42:12AM -0400, James Antill wrote: On Sat, 2009-08-29 at 19:06 -0500, Jason L Tibbitts III wrote: AT == Axel Thimm axel.th...@atrpms.net writes: AT I don't think apt traces whether a packages was a pulled in manually AT or automatically, does it? yum does keep track of many things in the yumdb and I think the reason key is supposed to track this, but for me it seems reason is always user. I think the intent is to track packages which were installed because the user requested them directly separately from packages which were pulled in purely because of dependencies. Yes, the reason attribute in yumdb is there primarily to start on solving this problem. This sounds like a nice addition to yum, I hadn't heard yet of the yumdb! Will other frontends like PackageKit also pass down this information to yum (e.g. which packages are user chosen, which are automatically pulled in), so the yumdb info is universal? -- Axel.Thimm at ATrpms.net pgpc3IaYxTfYw.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: how to determain those no longer required packages
On Sun, Aug 30, 2009 at 07:21:30AM +0800, Ray Chen wrote: 在 2009-08-29六的 17:32 +0300，Muayyad AlSadi写道： warning: leaves in package-cleanup or remove-with-leaves could be your preferred application because it's a leaf [ie. no installed package depends on it, eg. pidgin or uget] Yum does not trace if some package is installed per user request or pulled for dependency yes, that's the question. seems like yum doesn't have the feature like 'isAutoRemovable' in APT. I think this feature is good for users, hope yum developers can support this feature, or make 'package-cleanup --leaves' and 'remove-with-leaves' plugin more stable. I don't think apt traces whether a packages was a pulled in manually or automatically, does it? If so where does it store that information? And if that information were from invokations of apt-get only (e.g. stored under /var/*/apt) then it would miss yum, yumex, PackageKit, smart etc. interactions. But it would be a usefull feature for yum probably requiring an origin field in the rpmdb to remember whether the user or the system pulled in the package. -- Axel.Thimm at ATrpms.net pgpFVfaQTLyN6.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mediawiki rpm for fedora 11 broken?
On Mon, Aug 24, 2009 at 01:47:38PM -0700, Eli Morris wrote: With Fedora 11, I tried installing mediawiki through the normal 'yum install mediawiki'. The only files that appear to be in the rpm are: /usr/share/doc/mediawiki-1.14.0 This can't be the result of yum install unless you use a broken and aged mirror. mediawiki has been upgraded to 1.15.1 a long time ago. A proper yum install mediawiki yields (note the three mediawiki related subpackages): [...] Dependencies Resolved PackageArch VersionRepository Size Installing: mediawiki x86_64 1.15.1-48.fc11 updates 161 k Installing for dependencies: mediawiki-math x86_64 1.15.1-48.fc11 updates 516 k mediawiki-nomath x86_64 1.15.1-48.fc11 updates10 M php-gd x86_64 5.2.9-2.fc11 fedora125 k php-pgsql x86_64 5.2.9-2.fc11 fedora 71 k php-xmlx86_64 5.2.9-2.fc11 fedora119 k Transaction Summary Install 6 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 11 M Is this ok [y/N]: -- Axel.Thimm at ATrpms.net pgprI6Zm7nndk.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: nvidia vs suspend to disk
Hi, On Wed, Aug 19, 2009 at 09:50:03AM -0400, Paul W. Frields wrote: On Wed, Aug 19, 2009 at 03:27:13PM +0200, Chris Rouch wrote: On Mon, Aug 17, 2009 at 3:31 PM, Michael Hennebryhenne...@web.cs.ndsu.nodak.edu wrote: Does anyone currently have suspend to disk working with nvidia's drivers? If so, how? One of the items I googled hinted that it might not be possible with SMP. In another thread (no hardware acceleration?), another poster mentioned pm-suspend quirks, but I've not been able to figure out how to use them. pm-suspend just gives me an error message. Prior to installing the nvidia driver, the KDE gui would let me suspend to disk. I'm running fedora 9 on a pentium 4 with hyperthreading. I have tuxonice suspend working on F11 (and previously F10) with nvidia drivers. You need a patched kernel (kernel-tuxonice, available from atrpms) and the suspend process is different, but the end result is the same. Normal suspend and hibernate works properly on my laptop using the rpmfusion.org NVidia drivers on Fedora 11. I didn't have to patch or change anything. I have a NVidia GeForce 8400M GS in my Dell XPS M1330 laptop. While I'm not thrilled about using the proprietary driver, that driver for now is the only way suspend and hibernate work properly. Nouveau fails to return a working display: https://bugzilla.redhat.com/show_bug.cgi?id=502334 I also use on some systems with various nvidia chips the non-tuxonice kernel with the proprietary nvidia drivers packaged at ATrpms w/o any ill-effects on suspend, but there seems to be an issue with hibernation which tuxonice seems to handle better than the stock bits. -- Axel.Thimm at ATrpms.net pgpyqmWWyENOy.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
2.6.31-0.112.rc4.git3.fc12 on F11: flashing intel xorg driver
Hi, in order to debug https://bugzilla.redhat.com/show_bug.cgi?id=514918 I installed a rawhide kernel (2.6.31-0.112.rc4.git3.fc12). Unfortunately X flashes all the time which makes working graphically very difficult to impossible. But I need to test NetworkManager so I need to get into a non-flashing X somehow. Before I blindly upgrade half my system to rawhide, is there anything I could tune to fix this or maybe a minimal set of packages to upgrade to rawhide? I could perhaps ssh to the system in question, but part of the exercise is to get a working laptop with modbile broadband cababilities, so I do need a working X at the end :) -- Axel.Thimm at ATrpms.net pgpv5BtE2KD2E.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 2.6.31-0.112.rc4.git3.fc12 on F11: flashing intel xorg driver
On Sun, Aug 02, 2009 at 06:19:22PM +0100, Matthew Garrett wrote: On Sun, Aug 02, 2009 at 01:02:43PM +0300, Axel Thimm wrote: Thanks, I added a comment, but it looks like your issue was fixed with the kernel I am using. -112 was tagged just before I committed the workaround code. I tested kernel-2.6.31-0.118.rc5.fc12.x86_64 and it seems to be OK again, thanks! It is now not associating with my AP, and the mobile broadband issue wasn't fixed in this kernel either, but the graphics are fine. -- Axel.Thimm at ATrpms.net pgphJnLsrJVkz.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 rpm on F11 (rpmlib(PayloadIsXz))
On Sat, Aug 01, 2009 at 02:04:41PM -0500, Jason L Tibbitts III wrote: AT == Axel Thimm axel.th...@atrpms.net writes: AT Is there an upgrade-rpm-for-F11 available? In updates-testing. Thanks! On Sat, Aug 01, 2009 at 08:04:52PM +0100, Naheem Zaffar wrote: AFAIK there should be an F11 rpm in updates-testing that will work with Fedora 12 rpms. Thanks^2!! On Sat, Aug 01, 2009 at 01:06:31PM -0600, Kevin Fenzi wrote: yum --enablerepo=updates-testing update rpm\* Thanks^3!!! :) -- Axel.Thimm at ATrpms.net pgpH40wVbrxQP.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for Fedora 12
Hi, On Mon, Jul 20, 2009 at 04:14:39PM -0400, Bill Nottingham wrote: Fedora Release Enginerering is going to be starting a mass rebuild this Thursday, July 28th, for the following Fedora 12 features: - XZ RPM Payloads - x86 Architecture Support Just as in the Fedora 11 mass rebuild, if you'd like to opt out for your packages, check a file into your package's devel/ branch, named 'noautobuild'. This file should contain a short rationale of why you wish to do the build yourself. Note that if you do not do a rebuild during the timeframe before Alpha, one will be done regardless of the presence of this file. Also note that delta RPMS will be disabled in rawhide for the duration of this mass rebuild; delta rpms across payload format changes in RPM are not useful. For more information, see: https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild if I touch a package today, would it need to be rebuilt, and if not, would I need to create the noautobuild file? Thanks! -- Axel.Thimm at ATrpms.net pgpW82qKes8Yd.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates since June 3rd/4th?
Hi, maybe I missed some announcement somewhere, but there haven't been any updates in F10/F11 updates since more than 10 days. Am I looking at the wrong mirrors (including mine), or is there just a small hiatus for fixing some issues? Thanks! -- Axel.Thimm at ATrpms.net pgpUN52mucgOc.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anybody know how to contact Axel Thimm?
On Sat, Jun 13, 2009 at 02:38:28PM -0300, Itamar Reis Peixoto wrote: that's true. I am also have a bug reported for nx package waiting for a long time. There are new nx packages in updates-testing since a week now. Which bug are you referring to? On Sat, Jun 13, 2009 at 2:36 PM, Ricky Zhouri...@fedoraproject.org wrote: Hi, as per the process at http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers, does anybody know how to contact Axel Thimm? I know. We've been pinging him at https://bugzilla.redhat.com/show_bug.cgi?id=484855 for over two weeks now, although the bug has sat there for much longer already. It's correct that the bug is open a while, but technically your first ping as on 2009-06-05 00:05:35 EDT, that's hardly two weeks. I was waiting for 1.15.0 (out three days ago) to check whether the patch is still neccessary. But it looks like it still is. Anyway there will be an upgrade and I'll try to fix the issue en passant. -- Axel.Thimm at ATrpms.net pgp1zU6Eb5E0t.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: One (more) week slip of Fedora 11 Release
On Thu, May 28, 2009 at 10:36:18AM -0700, Jesse Keating wrote: A late discovered and just potentially fixed anaconda storage bug[1] has necessitated another week slip of our schedule. The change is important but invasive enough to require re-validating our storage tests. We were already late in producing the Release Candidate and there is not enough time to produce another one and validate it in time for next Tuesday's release date. Therefor we have decided to enact another week long slip of the release. This gives us time to create a second release candidate and fully validate it and hand it off to the mirrors in plenty of time to sync up for the new release date of June 9th. As much as we regret slipping, we also wish to avoid easily trigger-able bugs in our release, particularly in software that cannot be fixed with a 0-day update. At this time we would only accept tag requests for critical issues. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=500808 Does it make sense to fold in the f11 updates into the next preview release? E.g. to move all current updates back to rawhide? -- Axel.Thimm at ATrpms.net pgpHgXNOxxSIi.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Broken video DVDs (no executable bits on *_TS folders)
Hi, On Sat, May 23, 2009 at 08:45:36PM -0400, Bill Davidsen wrote: Axel Thimm wrote: some home made DVDs by some software is creating *_TS folders with 0400 permissions. This means that only root can really change into these folders. Is there a way to tell Fedora to always paste executional bits onto video DVDs? I'm trying to convert some people to use Fedora for their home systems and when they find out that Fedora will ignore their home made DVDs they don't really care that their Wincrap software generated a bad DVD (after all it runs on the DVD player). So while Fedora is actually doing The Right Thing, it is hindering its own acceptance. :( I can't imagine any change which would make that work and still be remotely functional behavior. Turning off permissions checking on directories isn't going to happen. Turns out that this just happened in 2.6.30 :) There are mode and dmode parameters that devicekit sets to full permissions. The DVDs are broken, tell your friends their software is crap. And that the media will not play in certain Blu-Ray players which check properly. That might make a better connection. There are just too many broken DVDs out there to be The Right One. And while digging into it I found out that not only home-made, but many commercial DVDs are broken as well. I wish the 2.6.30 mode/dmode patch makes it into F11. On Sat, May 23, 2009 at 07:11:23PM -0700, Suvayu Ali wrote: How are you mounting your DVDs? Is it auto-mounted by HAL? Yes. I sometimes use Windowmaker as my desktop and it doesn't automount any external storage device. Then I have to mount it by hand. I use the following to do that successfully. $ sudo mount -o uid=regular-user -o gid=group-of-user [other options] The problem is that there was no option for altering the permissions. In the near furture you will be able to do -o mode=xxx,dmode=yyy as well. I think similar other options for -o allow you to mount with the executable bit set. The DVDs might work if you mounted it like this. True, but you need the kernel to understand dmode and mode. Looks like it's going to be = 2.6.30 unless it is backported to the Fedora kernels. -- Axel.Thimm at ATrpms.net pgpmQictowLt1.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Broken video DVDs (no executable bits on *_TS folders)
Hi, some home made DVDs by some software is creating *_TS folders with 0400 permissions. This means that only root can really change into these folders. Is there a way to tell Fedora to always paste executional bits onto video DVDs? I'm trying to convert some people to use Fedora for their home systems and when they find out that Fedora will ignore their home made DVDs they don't really care that their Wincrap software generated a bad DVD (after all it runs on the DVD player). So while Fedora is actually doing The Right Thing, it is hindering its own acceptance. :( -- Axel.Thimm at ATrpms.net pgpTITcPKcYVM.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: What software is missing in the Fedora repository?
Le 07/05/2009 13:01, Rahul Sundaram a écrit : Hi, I am doing a quick survey for software that you use on a regular basis that is not available via the Fedora repository. Software that you suggest should be free and open source, free of patent and other legal issues. Tell me the home page of the software and give me a brief description on what it does. Bonus points if you can see in Google for software-name fedora package review to figure it if it is already in the Fedora package review queue. If you know of RPM packages in other distributions for the software your are suggesting, that information is useful as well. Rahul mbrowse, a graphical SNMP MIB browser, available on debian/ubuntu. License : GPL. Ubuntu package : http://packages.ubuntu.com/jaunty/mbrowse Homepage : http://www.kill-9.org/mbrowse/ (down at this moment) -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Statistics problem
On Thu, Apr 30, 2009 at 09:15:32AM -0500, Mike McGrath wrote:
On Thu, 30 Apr 2009, Paul W. Frields wrote:
On Wed, Apr 29, 2009 at 06:59:17PM -0500, Mike McGrath wrote:
On Wed, 29 Apr 2009, Paul W. Frields wrote:
On Wed, Apr 29, 2009 at 09:40:40PM +0300, Axel Thimm wrote:
Isn't a range request sent in the header of the HTTP request which
would hit the Fedora servers before being redirected?
Can someone on the Infrastructure guru team help me pull some relevant
lines from the logs, expurgating the IP address and any other
identifying information so we're not running afoul of any privacy
concerns?
255.255.255.255 - - [22/Mar/2009:23:59:44 +] GET
/pub/fedora/linux/releases/10/Live/i686/F10-i686-Live.iso HTTP/1.1 302
-http://fedoraproject.org/en/get-fedora; Mozilla/4.0 (compatible; MSIE
7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Bam!
Is there one that includes a range request of the kind Axel talks
about? Sorry to be dense.
Nope.
Which doesn't mean you can't put them there:
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats
e.g. a %{Range}i and %{If-Range}i in a CustomLog would yield the Range
headers in the logs sent with the non-redirected request.
Next one would need to examine the behaviour of popular download
accellerators and check for their pattern in these fields. Most
prominently whether the last HTTP request logged has them or not.
You wouldn't be able to recover past information, of course (although
one could extrapolate the percentage of download accelerators back in
time).
--
Axel.Thimm at ATrpms.net
pgpFNQhFZ78TK.pgp
Description: PGP signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Thu, Apr 30, 2009 at 09:53:39AM -0700, Toshio Kuratomi wrote: Mike McGrath wrote: On Thu, 30 Apr 2009, Ricky Zhou wrote: In some distant future version of FAS, I'd like to play with the idea of storing the data in LDAP while handling our group sponsorship system in postgres. Ick heh :-) I think ricky's approach could work but it would need planning. The idea would be to increase the complexity of FAS but decrease the complexity for everything we deploy that needs authentication. We'd want to examine that assumption in the planning phase to make sure it's actually true for us. For instance, there was the thought that having cached credentials on our servers was preferable to what happens to when the LDAP server goes down. Still a concern? You can have slave LDAP servers, of course, and if you don't trust their location, you can have slices of LDAP mirrored differently, e.g. not all attributes, not all trees etc. We currently mask a lot of information for the privacy policy, can we do that with LDAP? (Or just not put the information in there?) Sure, there are rather fine-coarsed ACL systems in both openldap and ds. We let third parties (like the hosts to let packagers try building on ppc, x86_64, etc) use fas to get ssh keys. Would we let them connect to and get that information from the LDAP server instead? There would be no security downside compared to other retieval solution. Absolute security is to let this be done by a trusted human. We let people use their normal accounts to get a subset of data for authenticating to their web apps while they're developing them. Would we enable the same setup with LDAP? Yes, check out the ACLs in either or the two popular projects. -- Axel.Thimm at ATrpms.net pgpHMyoidqSVx.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Thu, Apr 30, 2009 at 07:54:42AM -0500, Mike McGrath wrote: On Thu, 30 Apr 2009, Axel Thimm wrote: On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote: We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group. Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes? Or rephrased: Can't any SQL field in a table be always mapped onto some (custom) ldap attribute? If you can map a problem onto an SQL database it should be possible to go ldap IMHO. Seems like it should work that way, and we spent months trying to get it to work right (even working with the fedora-ds people) but it just ended up being very hacky and not very good. Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP? -- Axel.Thimm at ATrpms.net pgpC66Nluam2r.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Wed, Apr 29, 2009 at 11:23:55PM -0500, Matt Domsch wrote: On Thu, Apr 30, 2009 at 06:44:09AM +0300, Axel Thimm wrote: On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote: We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group. Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes? Can I reverse the question? Instead of a pam_fas module, what about creating a way to export FAS information as LDAP, such that all LDAP-consuming apps would just work, albeit not able to access the FAS-specific information? That was further up the thread: One could have FAS export the parts Mike needs in an ldif formated file and cron-import them into a *read only* ldap backend. You would need a sibling ldap instance running for serving ldap requests. If you mean having an ldap (read-only) interface to FAS coded, then I think that this is quite a lot of work. -- Axel.Thimm at ATrpms.net pgpsM00AjEuu6.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Statistics problem
On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: Maybe the cleanest solution is to count downloaded bytes and divide by image size. That way you properly count ranged downloads. Command suggestions are very welcome. I really don't have time to delve into this incredibly deeply at the moment. Could you post a small fragment of the raw logs? But it seems like all we see are the primary redirects, possibly w/o noting ranges in the logs. E.g. for better statistics the logs would need to capture the ranges from the head as well. -- Axel.Thimm at ATrpms.net pgp5tdCgCdnCR.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Statistics problem
On Wed, Apr 29, 2009 at 09:09:27PM +0800, Basil Mohamed Gohar wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2009 08:20 PM, Axel Thimm wrote: On Tue, Apr 28, 2009 at 11:17:55AM -0400, Paul W. Frields wrote: Maybe the cleanest solution is to count downloaded bytes and divide by image size. That way you properly count ranged downloads. Command suggestions are very welcome. I really don't have time to delve into this incredibly deeply at the moment. Could you post a small fragment of the raw logs? But it seems like all we see are the primary redirects, possibly w/o noting ranges in the logs. E.g. for better statistics the logs would need to capture the ranges from the head as well. I think that information is not available, because no one (almost) downloads directly from the Fedora servers, only from the mirrors. Therefore, the real data, like range requests, etc., would only be on the mirror servers themselves, and not on the primary ones. Isn't a range request sent in the header of the HTTP request which would hit the Fedora servers before being redirected? -- Axel.Thimm at ATrpms.net pgpZA8BzPOq9T.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Wed, Apr 29, 2009 at 01:03:03PM -0500, Mike McGrath wrote: Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it. Sorry for butting in like this, but I always assumed FAS would use LDAP as a backend, so that 3rd parties, if they wanted to plug in to the system, would utilize LDAP. Is that not the case? Correct, that's not the case. Instead of LDAP we have a postgres backend and use json to auth, third parties use python-fedora to authenticate. We tried pretty hard to get LDAP working with our account system but ran into many problems and decided to go back to postgres. I'd third the LDAP love here, e.g. either a read-only cron'd export to LDAP or rewriting the FAS backend for LDAP. Any future tool you may want to attach to FAS will most probably have LDAP support out of the box, but any other kind of authentication would need special coding (like your pam module request), which is both time consuming and a security risk if not written properly. -- Axel.Thimm at ATrpms.net pgpmA3HstfoAY.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote: We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group. Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes? Or rephrased: Can't any SQL field in a table be always mapped onto some (custom) ldap attribute? If you can map a problem onto an SQL database it should be possible to go ldap IMHO. -- Axel.Thimm at ATrpms.net pgpXSxiyJZ8T6.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Software request
Le 29/04/2009 16:50, Patrick O'Callaghan a écrit : On Wed, 2009-04-29 at 14:09 +, Beartooth wrote: Could some kind soul make an rpm and put it into a repository for gnome-format? It's at http://live.gnome.org/gnome-format -- and there are .debs there, but no .rpms. It *might* (I'm told) be able to handle the trouble some of us have been having wiping Conficker-prone M$-foulness (automount, I think) off thumb drives. What's wrong with mkfs.vfat? poc User interface is wrong. We are in 2009. Any desktop should provide such a tool. The package gnome-disk-utility-format is available in Fedora 11. I don't know if something like this is available for Fedora 10. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: nVidia vs. ATI graphics card for fedora
Le 28/04/2009 16:25, Globe Trotter a écrit : Hi, I am ordering a souped-up workstation and I was wondering which graphics card is preferable for running fedora: a 256 MB PCIe x16 nVidia NVS 290, Dual Monitor capable or a ATI Fire GL V3600 256MB, Dual Monitor DVI Capable ATI3600 What would you suggest? I do not need huge 3-d acceleration and stuff, but want it to work well. Please let me know if I should provide more information. Best wishes, Trotter I would personnaly choose a nvidia card, and I would use the proprietary driver. Every-day user-experience is more smooth and looks prettier to me (windows rendering, refresh, switch, and so on) with the proprietary drivers. (Same for ATI imho). -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
rpm-4.6.x friends for RHEL5 (was: hosts for rawhide build chroots - different rpm versions?)
Hi, On Sun, Mar 22, 2009 at 11:53:09AM -0500, Dennis Gilmore wrote: On Sunday 22 March 2009 05:02:41 am Axel Thimm wrote: AFAIK the build hosts are RHEL5 (or maybe F10 by now?). At any rate the rpm used in rawhide is quite different than the ones from the hosts, how has this been solved in the build hosts? Has the hosting OS upgraded its rpm to be compatible to all hosted chroots? Or is the rpm within the chroot used? I'm asking in a double context: First I'd like to understand if smart can properly handle chroots of rawhide/F11 on F10/RHEL5 hosts. Anders Björklund (in the Cc, please keep him there on replies) has put a great deal of effort to have smart working on F10 and F11, and a smart version for managing F11 and later chroots on F10 or earlier would be great. And second I'd like to know how to setup a build environment for F11 for getting some ATrpms packages out. we are running a version of rpm 4.6.0 on rhel5. This is only so mock can populate chroots with rpms with stronger hashes rhel5's rpm doesnt support. All srpm creation now takes place in chroots so features of the target rpm are always available. rpm in F-10 updates is compatible with the new rpm features. but rpm from F-9 and RHEL4 and 5 can not handle the new rpm at all. you cannot make chroots on them with rawhide rpms. you could use koji on F-10/rawhide or F-9/RHEL5 by replacing the hosts rpm to build your packages. Thanks for the explanation, Dennis. Can I get these tailored rpm rpms from somewhere? I just tried rebuilding rpm from rawhide on RHEL5 and the dependencies look endless. -- Axel.Thimm at ATrpms.net pgp7EVD9Gntys.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: rpm-4.6.x friends for RHEL5 (was: hosts for rawhide build chroots - different rpm versions?)
On Tue, Apr 14, 2009 at 01:15:21PM -0500, Jeffrey Ollie wrote: On Tue, Apr 14, 2009 at 12:37 PM, Axel Thimm axel.th...@atrpms.net wrote: On Sun, Mar 22, 2009 at 11:53:09AM -0500, Dennis Gilmore wrote: we are running a version of rpm 4.6.0 on rhel5. This is only so mock can populate chroots with rpms with stronger hashes rhel5's rpm doesnt support. All srpm creation now takes place in chroots so features of the target rpm are always available. Thanks for the explanation, Dennis. Can I get these tailored rpm rpms from somewhere? I just tried rebuilding rpm from rawhide on RHEL5 and the dependencies look endless. http://infrastructure.fedoraproject.org/ Thanks, I guess it's http://infrastructure.fedoraproject.org/builder-rpms/ It's missing popt builds, but these were easy to rebuild from Fedora. I just metion it in case a) I'm pulling the wrong bits, b) someone else wants to use RHEL5 hosts with F11 roots. -- Axel.Thimm at ATrpms.net pgpWpMWGV5epm.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
hosts for rawhide build chroots - different rpm versions?
Hi, AFAIK the build hosts are RHEL5 (or maybe F10 by now?). At any rate the rpm used in rawhide is quite different than the ones from the hosts, how has this been solved in the build hosts? Has the hosting OS upgraded its rpm to be compatible to all hosted chroots? Or is the rpm within the chroot used? I'm asking in a double context: First I'd like to understand if smart can properly handle chroots of rawhide/F11 on F10/RHEL5 hosts. Anders Björklund (in the Cc, please keep him there on replies) has put a great deal of effort to have smart working on F10 and F11, and a smart version for managing F11 and later chroots on F10 or earlier would be great. And second I'd like to know how to setup a build environment for F11 for getting some ATrpms packages out. Thanks! -- Axel.Thimm at ATrpms.net pgpcy4KlxzMtE.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: What are these yum plugins for ? (kmod-nvidia related)
On Wed, Mar 04, 2009 at 10:47:54AM -0700, Linuxguy123 wrote: What are the following yum plugins for ? downloadonly, kmdl, priorities, refresh-packagekit Could any of them interfere with my ability to see (ie yum list) the most recent kmod-nvidia package ? kmdl is the plugin to make sure that future kernel updates will pull in kmdl updates of kmdls you have installed. While there are nvidia kmdls (which I highly recommend over kmods, but as a kmdl packager I guess I count as biased ;) this plugin does not filter away anything. Neither should the other plugins do, but at the very end you will only know for sure if you start disabling them one by one. Edit /etc/yum/pluginconf.d/*.conf and set enabled=0 to disable the plugin(s) and try again. -- Axel.Thimm at ATrpms.net pgpnA5qcV3AZ5.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: What are these yum plugins for ? (kmod-nvidia related)
On Wed, Mar 04, 2009 at 02:02:00PM -0700, Linuxguy123 wrote: On Wed, 2009-03-04 at 10:36 -0800, suvayu ali wrote: 2009/3/4 Axel Thimm axel.th...@atrpms.net: Neither should the other plugins do, but at the very end you will only know for sure if you start disabling them one by one. Edit /etc/yum/pluginconf.d/*.conf and set enabled=0 to disable the plugin(s) and try again. or use yum --disableplugin=[plugin] I disabled all of them. No kmod-nvidia packages become available. Have you tried yum install nvidia-graphics [1]? That might fix all your issues, although it would still be a mistery why your system doesn't see some packages. [1] Requires an enabled ATrpms repo -- Axel.Thimm at ATrpms.net pgpeChiDxT0eh.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: opengroupware evaluation
Hi, On Thu, Feb 19, 2009 at 11:03:22AM -0600, Mike McGrath wrote: I'd like one of our volunteers to install opengroupware on a publictest server for our evaluation. https://fedorahosted.org/fedora-infrastructure/ticket/1197 This is going to take between 5 and 15 hours a week. Don't volunteer unless you can commit that much time to it. I've tried to setup ogo a couple of times, and it is cumbersome work. I also tried to package it and push it into Fedora, but that's non-trivial, from the use of non-FHSable gnustep-make to an own foundation library to non-compliant init scripts in sope etc. The gnustep-make package for example needs to currently decide at build time whether to support ogo or the rest of gnustep-* packages in the review queue. :( I dont know about sogo, I hope things have improved (at least the binary packages' versions show updates needed for bridging the gap between gnustep-* and ogo), and the evaluation will show the status, but from what I've looked up recently it looks like bedework is also a good candidate for a Fedora calendaring system. http://www.bedework.org/bedework/ Please consider giving bedework a try as well. -- Axel.Thimm at ATrpms.net pgpaaCDUlCaxu.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
bedeford (was: opengroupware evaluation)
On Tue, Mar 03, 2009 at 08:52:12AM -0600, Mike McGrath wrote: Please consider giving bedework a try as well. Thanks, that looks pretty slick too. I'll add it to our list to look at. BTW according to our fedora-devel archives there was a guy on fedora-devel, Trever L. Adams, whom I Cc'd, who mentioned wanting to package up bedework. He periodically mentioned this in the last 12 months and maybe all he needs is a little help with java packaging. Trever, are you still interested in packaging bedeford for Fedora? The current needs in infrastructure will certainly make many more people help and assist in any such efforts. -- Axel.Thimm at ATrpms.net pgpIkKlbYTtqu.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: A reminder of EOL for F8
On Tue, Feb 17, 2009 at 11:27:00AM -0600, Marc Schwartz wrote: Bill Crawford billcrawford1...@gmail.com writes: On Tuesday 17 February 2009 15:43:28 Marc Schwartz wrote: If there is a bug preventing you from installing, get it filed. Otherwise, you have a decision to make here. Stay with F8 at your own peril or move to another Linux distribution that works for you. The problems appear mostly to be non-distro-specific, I am CCed on a couple of bugs relating to video problems with multiple GPUs, and yes, I am a little stuck here. I provided logs from Xorg for both working and non-working situations, I'm now just waiting for Xorg to support multiple graphics cards sensibly again ... Is this in a system with multiple GPUs from the same vendor (eg. nVidia) or is this a heterogeneous GPU vendor system? This is a know issue of F9 and F10, but Chris Tyler is working on it for F11. You will find background information at https://fedoraproject.org/wiki/Features/Multiseat And if you really want to see it in F11 one should ask Chris what he'd like you to test, or just participate on the Talk page above. -- Axel.Thimm at ATrpms.net pgpQbm1ttfjka.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Video playback color problem in totem or vlc
Hello Video playback used to be good but now color rendering isn't accurate anymore. Blue parts are now green, green parts are violet, and so on, in video playback . I tried totem (gstreamer backend) and VLC. I m using nvidia driver from the livna repository. I launched gstreamer-properties, moving the autodected to the X-Window System (without Xv) entry fixes the problem, other items doesn't change anything. How could I fix it and use the autodetect entry ? What could I have done which caused this problem ? Thanks in advance. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: /releases/10/Everything: several packages changed
On Sat, Jan 31, 2009 at 01:58:28PM -0800, Jesse Keating wrote: On Sat, 2009-01-31 at 12:21 -0800, Jesse Keating wrote: This was certainly unexpected, and repairing this is going to be... interesting. Through some fun work with /sbin/hardlink I got a lot of the packages fixed up. There are some more that aren't quite right, due to the development tree having moved on, so I'll have to fix this individually. Isn't there a backup of /releases/ to pull back the original files? -- Axel.Thimm at ATrpms.net ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Where to find old kernel-devel packages?
Hi, there is some build regression with openafs and the latest Fedora 10 x86_64 kernel and it could be either due to the kernel or due to other changes in the build environment. Is there a way to retrieve older kernel-devel packages to test this? (Actually I think I know the answer is yes, so the question is rather how :) Thanks! -- Axel.Thimm at ATrpms.net ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Where to find old kernel-devel packages?
On Sun, Feb 01, 2009 at 10:44:54AM +0100, Matthias Hensler wrote: On Sun, Feb 01, 2009 at 10:31:10AM +0100, Axel Thimm wrote: there is some build regression with openafs and the latest Fedora 10 x86_64 kernel and it could be either due to the kernel or due to other changes in the build environment. Is there a way to retrieve older kernel-devel packages to test this? (Actually I think I know the answer is yes, so the question is rather how :) As far as I see all recent (at least over 1000) kernelbuilds are available here: http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Thanks! -- Axel.Thimm at ATrpms.net ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
alsa forth and back?
Hi, alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel packages. Could someone explain why? Thanks! -- Axel.Thimm at ATrpms.net ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: alsa forth and back?
On Fri, Jan 30, 2009 at 04:30:02PM -0800, Conrad Meyer wrote: On Friday 30 January 2009 04:20:30 pm Axel Thimm wrote: Hi, alsa was demoted from 1.0.18 to 1.0.17 in the latest kernel packages. Could someone explain why? Thanks! If you follow fedora-devel-list, you'll notice there were some regressions in 1.0.18 that broke sound for some users. They decided to revert to 1.0.17 instead of waiting for 1.0.19 release. I think that whatever I saw on fedora-devel was accompanied with a patch. -- Axel.Thimm at ATrpms.net ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: A reminder of EOL for F8
On Mon, Jan 05, 2009 at 03:30:32PM -0500, Kevin J. Cummings wrote: Chris Snook wrote: Do the F8 repos disappear on Jan 7th as well? I'd hate to be the admin who doesn't notice until Jan. 8th, Starting Jan. 8th there are no security updates anymore, so if the system is exposed in any way you should upgrade before that. and needs some tool that's not installed in order to migrate gracefully. The tool is already installed: yum. :) ATRPMs for F8 will disappear almost immediately, the other repos leave their last stuff around for a long time. Indeed, ATrpms makes quite often a hard switch off of EOL'd releases. The bits are still there, especially since the src.rpms are shared, but if someone really needs to stay on an EOL release he should probably better make copies of the binary packages. -- Axel.Thimm at ATrpms.net pgpNdhvF46naA.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: F10 -- How do I start AR5413 interface?
On Thu, Dec 04, 2008 at 01:47:57PM -0500, Robert Moskowitz wrote: If neither of the above work, file a bug (my guess would be against HAL or udev) and use the madwifi packages from rpmfusion or atrpms until the bug is fixed. Challenge with atrpms is kernel patching. I got to like the dkms approach that is available via rpmforge for Centos. I was hoping that things would be more integrated... ATrpms doesn't do/need kernel patching. The kmdl are shipped as an add on package for the supported kernels, you just install the kmdls and if you also install yum/plugin-kmdl then yum will also keep up the needed kmdls for future kernels. And if you need a kmdl for you own specific breed of kernel packages then you just grap the src.rpm and do an rpmbuild --rebuild on it. -- Axel.Thimm at ATrpms.net pgpOYQxN9X8BJ.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: ATrpms for Fedora 10; upcoming EOL for Fedora 8
On Thu, Nov 27, 2008 at 12:38:02PM +1030, Tim wrote: On Tue, 2008-11-25 at 21:21 +0200, Axel Thimm wrote: F10 support will be EOL'd once the Fedora Project drops support for it (e.g. in about a month's time). Oh ye of little faith... ;-) Oops, that was for F8 not F10. :) -- Axel.Thimm at ATrpms.net pgpQ02zqt2wDi.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
ATrpms for Fedora 10; upcoming EOL for Fedora 8
ATrpms is officially launching Fedora 9 support. http://ATrpms.net/dist/f10/ o The actual download location is http://dl.atrpms.net/. Mirrors are listed at http://atrpms.net/mirrors/ o stable, testing and bleeding, the three subrepos per distribution are not cumulative inclusive on the server side. E.g. you need to add stable for testing, and both stable and testing for bleeding. ATrpms is a 3rd party general purpose package repository. It currently supports o F10/i386, F10/x86_64, F9/i386, F9/x86_64, F8/i386, F8/x86_64 o RHEL5/i386, RHEL5/x86_64, RHEL4/i386, RHEL4/x86_64, RHEL3/i386, RHEL3/x86_64 F10 support will be EOL'd once the Fedora Project drops support for it (e.g. in about a month's time). Configuration for package resolvers (replace i386 with x86_64 or ppc as needed) o yum [atrpms] name=Fedora 10 - i386 - ATrpms baseurl=http://dl.atrpms.net/f10-i386/atrpms/stable o smart [atrpms] name=Fedora 10 - i386 - ATrpms baseurl=http://dl.atrpms.net/f10-i386/atrpms/stable type=rpm-md o apt repomd http://dl.atrpms.net f10-i386/atrpms/stable you can provide feedback or request support on the ATrpms lists (http://lists.atrpms.net/), or the common bug tracker (http://bugzilla.atrpms.net/). Enjoy! -- Axel.Thimm at ATrpms.net pgpbCslvMUmQt.pgp Description: PGP signature -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Re: Reviving Education SIG
On Mon, Oct 20, 2008 at 08:48:15PM +0200, Sebastian Dziallas wrote: Hi everybody, it has been calm over the past weeks here. In fact, alarmingly calm. I had a talk with Rex some time ago and we decided that some things needed to change here. So why am I posting and why are we doing this? * to make you aware that we've an almost empty wishlist here: https://fedoraproject.org/wiki/SIGs/Education/Apps#Wishlist * to show you that there's still a lot of work to be done (tasks): https://fedoraproject.org/wiki/SIGs/Education/Meetings * to bring other things than just spins to the surface * to *not* let this project die easily Again, we *need* some kind of feedback from the people! So please speak up, if you're interested, have an idea or want to help. Just for a project wishlist: o teaching/monitoring tools like italc (I submitted a package some time ago) o multiseat support in Fedora -- Axel.Thimm at ATrpms.net pgpvpwmffD9uy.pgp Description: PGP signature ___ Fedora-education-list mailing list Fedora-education-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-education-list
Re: CentOS 3rd party repositories?
On Thu, Oct 02, 2008 at 08:07:04PM +, Marko Vojinovic wrote: On Thursday 02 October 2008 13:24, Axel Thimm wrote: rant ATrpms has way too obsolete installation instructions (some others too --- Dries comes to mind) to be seriously considered as a reliable repository. For example, Livna has a .rpm file for each Fedora distro that I just have to install and it is ready to go. On ATrpms website I was told to manually edit the .repo files according to the template given for Fedora 7 (!!!), changing some parameters to suit my own distro (???)... Wtf? Did I miss the right instructions page? This is just user-unfriendly, to say the least. But I may even try it out if someone just gives me the exact contents of the appropriate .repo file that works with CentOS 5.2, and if ATrpms has all these packages that I need, updated more often than their website... /rant rantback Try http://atrpms.net/name/atrpms-package-config/ /rantback unrant Oh, well, that is a nice surprise! Apologies for the rant. :-) /unrant Btw, what is medley? An old attempt to provide a package that would enable many 3rd party repos. The attempt failed because the repos would not report new/old repo support and the medley was getting out of date. -- Axel.Thimm at ATrpms.net pgpbsj87OXKrj.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: CentOS 3rd party repositories?
On Thu, Oct 02, 2008 at 11:54:27AM +, Marko Vojinovic wrote: Forgive me for querrying the Fedora list for this, but I really don't want to subscribe to a Yet Another Mailing List just to have this one single basic question answered. It is quite unlikely that I will be having any more questions about CentOS in the future, so... Ok, to the problem --- I have one (soon to be two) CentOS 5.2 machine(s), and I seem to miss some packages that I am used to in Fedora: 1) kmod-nvidia and kmod-fglrx --- searching through the web, all I see about CentOS is installing/compiling drivers straight from nVidia and ATI. Are there maintained yumable packages that get autoupdated along with CentOS kernel like the ones for Fedora? 2) BackupPC --- so far it was running quite well for me on Fedora, but it does not seem to exist for CentOS, which comes with some other (equivalent) tools. Am I destined to use those, or am I missing some repository where backuppc can be found? Or should I compile it myself? 3) Cairo-dock --- ok, this is not essential, but I like it :-). However, yum says no matches found. Just to note, so far I have enabled the default base, extras, updates repositories from CentOS, and in addition the Dag repository for RHEL5 and adobe repository for flash. rant ATrpms has way too obsolete installation instructions (some others too --- Dries comes to mind) to be seriously considered as a reliable repository. For example, Livna has a .rpm file for each Fedora distro that I just have to install and it is ready to go. On ATrpms website I was told to manually edit the .repo files according to the template given for Fedora 7 (!!!), changing some parameters to suit my own distro (???)... Wtf? Did I miss the right instructions page? This is just user-unfriendly, to say the least. But I may even try it out if someone just gives me the exact contents of the appropriate .repo file that works with CentOS 5.2, and if ATrpms has all these packages that I need, updated more often than their website... /rant rantback Try http://atrpms.net/name/atrpms-package-config/ /rantback This machine is meant to be unattended (physically, not remotely) for a period of 3 years, so I guessed that CentOS is the distro that would Just Work in such conditions, and at the same time it is similar enough to Fedora that I shall be comfortable admining it remotely as neccessary. The other machine is to be used as a desktop machine by a serve-on-a-plate kind of user who knows nothing beyond kde menus (hence the question about automatic graphics drivers), also admined by me remotely. I will be thankful for any suggestions about the above. I do not insist on yum and will content to build from source, if I can be guaranteed that such setup will not break after 3 years of possible (regular) kernel updates. Excuse me again for not going to CentOS list for this, it seems obvious that a lot of people here use CentOS as well, so... ;-) Best, :-) Marko -- Axel.Thimm at ATrpms.net pgpCC3lzkMGch.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: how-to create rpm from rpms (atrpms)
On Fri, Sep 26, 2008 at 07:09:27PM +0200, David Hláčik wrote: Hello guys, i am trying to create alsa-driver and alsa-kmod-`uname -r` driver for my Fedora 9 computer, as kernel i am using does not have pre-builded kmdl binaries What kernel is that? Do you have a matching kernel-devel installed? I am trying to build it from alsa-driver at http://atrpms.net/dist/f9/alsa-driver/ . when i will do rpmbuild -bb on alsa-driver.spec file , this is what i get : [EMAIL PROTECTED] SPECS]$ rpmbuild -bb alsa-driver.spec error: line 1: Unknown tag: %kmdl alsa Try yum install atrpms-rpm-config before the rpmbuild command. This is how specfile looks like http://dl.atrpms.net/all/alsa-driver.spec . Thanks in advance David -- Axel.Thimm at ATrpms.net pgpuI1ZWOzhT1.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: New Key Repo Locations
On Sun, Aug 31, 2008 at 12:06:00AM -0400, Seth Vidal wrote:
On Sat, 2008-08-30 at 23:53 -0400, Warren Togami wrote:
Anyhow, updates should begin flowing soon, and shortly thereafter
the old key is removed. Oh, did you actually test rpm -e during
%post? According to skvidal it doesn't work because it locks the
transaction. Jeremy thinks the only assured way we can remove the
old key is with a hardcoded hack in rpm that will be removed in
F10 rpm.
I tested rpm -e during %post on two f9 systems, It locked the rpmdb
hard.
Have you tried with gpg-pubkey entries? I had asked on rpm-devel back
in these days when I was using the following snippet:
%post
if [ $1 = 1 ]; then
for key in \
gpg-pubkey-db42a60e-37ea5438,RPM-GPG-KEY.redhat \
gpg-pubkey-66534c2b-3e60b428,RPM-GPG-KEY.atrpms \
gpg-pubkey-e42d547b-3960bdf1,RPM-GPG-KEY.freshrpms \
gpg-pubkey-b8693f2c-3f48c249,RPM-GPG-KEY.newrpms \
gpg-pubkey-6b8d79e6-3f49313d,RPM-GPG-KEY.dag \
gpg-pubkey-bbf04688-4018dbeb,RPM-GPG-KEY.biorpms \
gpg-pubkey-68d9802a-406db022,RPM-GPG-KEY.ccrma \
gpg-pubkey-4f2a6fd2-3f9d9d3b,RPM-GPG-KEY.redhat-fedora \
; do
:
rpm -e --allmatches `echo $key | awk -F, '{print $1}'` /dev/null 21 || :
rpm --import /usr/share/atrpms/`echo $key | awk -F, '{print $2}'`
done
fi
I'm not using this anymore, since I can't vouch for the trust to all
third party repos, but the code was running fine back then w/o locking
up rpmdb. Maybe an rpm regression? Or maybe it works for gpg-pubkeys
only? Should we loop in Panu?
--
Axel.Thimm at ATrpms.net
pgpNRnWheds3y.pgp
Description: PGP signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
On Sun, Aug 31, 2008 at 01:18:25AM -0700, Toshio Kuratomi wrote: Warren Togami wrote: Matt Domsch wrote: On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote: On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: We're using MM to redirect ALL requests for the old repo location to mirrors that we have ultimate control over. I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is. that's the plan, it's not implemented yet. In fact, I'll probably just do it with plain HTTP redirects in an httpd.conf file rather than special-case it in MM. http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html Matt, you are misunderstanding the plan. No redirections are necessary at any level of this plan. Warren, I think we need to add redirection as step 6.1. If we don't lock out mirrors that we don't control at that stage, there's nothing to prevent the following scenario:: Person with the key has brute forced passphrase and compromises mirror. uploads packages signed with old key to the F-9 repo on the old mirror. Among other things these packages subvert yum so that it will only update from compromised mirrors and removes the new key from the NEWREPO. User downloads F-9 ISO. Installs F-9 with old key as valid. User hits the compromised mirror on first yum update and installs compromised packages. I more and more like the idea of killing F8 and F9 and going F8.1 and F9.1. The person with the F9 DVD might even manually download a bad signed package and think it is Fedora signed. He might even turn on malicious or compromized 3rd party repos that carry malicious packages signed with the old key and not notice how willing his DVD install will swallow these packages in. Once again, either the intruder is considered unable to sign packages due to a very good passphrase (and then we don't even need to start this stepdance), or if signed malware is realistic then the old key and all assorted bits need to be considered dead including old F9 DVDs. Much more than RHEL Fedora is an open system with many software flow channels from volunteer mirrors to 3rd party repos, driver ISVs, sf.net rpms, etc. as well as manual installs. So even if the Fedora mirrors issue is dealt with there are still lots of open spots. I propose to a) resping F8/F9 with updates (all signed with the new key) to create 8.1, 9.1. Fedora unity recenty did some respins, so maybe it is just cut and paste. b) empty F8/F9 updates and just place a package in there that will automatically upgrade any F8/F9 system to F8.1/F9.1. Redirect all mirrormanager controlled URLs to a controlled entity that only serves this package for F8/F9. Being a single package this will be a much lighter load than turning off all mirrors. The mirrors will still be used for 8.1/9.1. c) make sure users get alerted about this, maybe by some applet. -- Axel.Thimm at ATrpms.net pgpNPuSYDcYK5.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
One person - several FAS accounts? (was: bodhi abuse?)
On Sat, Aug 30, 2008 at 05:01:24PM +0200, Michael Schwendt wrote: Secondly, in my opinion, it is not okay that one person opens multiple Fedora accounts. [...] In case there are no rules yet, it's about time to create some. I agree with Michael about 10^10%. FAS accounts should be only one for each user. If there are needs for having several accounts for one person, these needs should be explained and either the FAS system extended to cover these cases, or special cased by whatever entity (fesco, fab, Fedora infra team?) is authoritative. Isn't there perhaps already some texting that one needs to click through that has the user sign that he will use only that account? Otherwise could someone add this? Besides bodhi fake voting this can even be used for fab/fesco fake voting (although it is probably harder to mark several same-person-accounts as packager accounts w/o anyone noticing it)! -- Axel.Thimm at ATrpms.net pgp3PSsw63lj2.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New Key Repo Locations
On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: 2008/8/29 Axel Thimm [EMAIL PROTECTED]: If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open. I don't think that the key is considered stolen atm. What has happened (to my limited knowledge) is that the machine storing the (encrypted) key was compromised, however, during the window of the compromise, the passphrase to the key was not entered. Therefore, what they have is an encrypted key that they don't know the passphrase to. IOW the users do need to acknowledge the change of keys (like you do when an ssh host key has been changed). Otherwise any user with an F9 DVD is susceptible for being spoofed anyway, we won't be able to cure that: The people that stole the key just need to get control over a Let's assume that the key *was* actually compromised, passhphrase and all. With the current plan, without additional intermediate compromises (say the user's DNS server), I still don't see the risk. We're using MM to redirect ALL requests for the old repo location to mirrors that we have ultimate control over. I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is. One of them is mine, and for what I know I could be the one having stolen the key injecting bad packages right now. Or maybe the key passphrase show up on some hacker forums and anyone and his cat will be able to spoof us up. Also most security breaches actually happen with insider knowledge, so I could have registered a mirror just for trojaning the users that would be redirected to me. We'll see what the investigation will turn up, maybe we will see former Fedorians exercising criminal skills alongside packaging. Therefore, they can setup a mirror and sign stuff with the old key, but it won't be used by the default config. Why not? See above. Maybe new mirrors since the incident have not been allowed to registered, but what if the intruder registered them beforehand? Which brings up an interesting question in my mind - how are we ensuring that the old key is actually removed from user machines and no longer trusted? I remember something about the new fedora-release obsoleting the old key, but that was seen as not something we could do. Why not? I also don't see a reason. Removing a key in %pre or %post is not an issue with rpm = 4.3 (maybe even earlier). The only way to not have this happen is to loudly announce that the old key is being revoked and content signed with it needs to be cast away and replaced. That's pretty much what's happening. The issue that we have with a clean transistion is that the PackageKit that was included in Fedora 9 GA did not have the ability to import new keys, and we want this transition to be as painless as possible for our users. Possibly better to have a non-painless and non-automatic transition, so F9 DVD owners don't get into any bad mirrors. All this assumes that there is real suspicion that the old key has been stolen, but the new key procedure does indicate that case. Otherwise, if it is just being done for good measure, then it's a bad step. Why is it bad to exercise an abundance of caution in this situation? Because there is not really such a thing as a grey zone in security assertions, it is either a security issue (of a certain gravity) or not. Either the key is considered compromized and one needs to do the full program, or it is reasonably considered safe (by a brute-force safe passphrase and really assuming the passphrase has not been lost to the intruder as well), in which case no steps are needed, but phasing it out before the computing power gets accessible to break it (e.g. new keys for F10 upwards). The current program looks like a mix of assuming safe (so the old key can be used for signing new packages, even if it just a few) and assuming compromised needing a resiging of all content. But actually w/o knowing the details and the outcome of the current investigation one can't really say much. It just looks like contradicting security measures (assuming safe vs compromized). [1] # lynx --dump 'http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9arch=x86_64' # repo = fedora-9 arch = x86_64 Using preferred netblock Using Internet2 countr y = DE country = RO country = GB country = PL country = EE country = IT country = ES country = MD country = IL country = FR country = FI country = NL country = NO country = CH country = CZ country = SE country = DK country = LV country = IS country = AT country = IE http://mirror.atrpms.net/fedora/linux/releases/9/Everything/x86_64/os http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/releases/9/ Everything/x86_64/os http://sunsite.informatik.rwth-aachen.de/ftp/pub
Re: New Key Repo Locations
On Fri, Aug 29, 2008 at 12:15:23AM -0400, Warren Togami wrote: Jeroen van Meeuwen wrote: I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files. You misunderstand the New Key plan. Mirrormanager for the existing repos fedora, updates and updates-testing will not redirect to the new location. Please read the plan again carefully. Hi, where can this plan be read, I didn't see it in this list or any URL pointing to it. W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? -- Axel.Thimm at ATrpms.net pgpDuLg6sLPi9.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: Axel Thimm wrote: W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? I think then the problem becomes that every existing installation points to os/ where it would need os.oldkey/ to get the packages it can check gpg keys on. But isn't this desired behaviour? We don't actually want os.oldkey/ to be used anymore (mid-term) as we need to revoce the key in case it has been stolen. Maybe we don't need os.*key at all. E.g. if a key has been stolen, burn all signed stuff and recreate them with a new key. -- Axel.Thimm at ATrpms.net pgpKINfqI3ENi.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
On Fri, Aug 29, 2008 at 03:42:31PM +0200, Jeroen van Meeuwen wrote: Axel Thimm wrote: On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: Axel Thimm wrote: W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? I think then the problem becomes that every existing installation points to os/ where it would need os.oldkey/ to get the packages it can check gpg keys on. But isn't this desired behaviour? We don't actually want os.oldkey/ to be used anymore (mid-term) as we need to revoce the key in case it has been stolen. Maybe we don't need os.*key at all. E.g. if a key has been stolen, burn all signed stuff and recreate them with a new key. The problem then becomes that a fedora-release package update needs to come from the old location which is the only location a currently running client knows about, signed with the old key (which again is all the running client knows about at this point). If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open. IOW the users do need to acknowledge the change of keys (like you do when an ssh host key has been changed). Otherwise any user with an F9 DVD is susceptible for being spoofed anyway, we won't be able to cure that: The people that stole the key just need to get control over a mirror or even worse officially setup a mirror of their own and distribute their own content signed with the stolen key! The only way to not have this happen is to loudly announce that the old key is being revoked and content signed with it needs to be cast away and replaced. All this assumes that there is real suspicion that the old key has been stolen, but the new key procedure does indicate that case. Otherwise, if it is just being done for good measure, then it's a bad step. -- Axel.Thimm at ATrpms.net pgpG9S2GfL8G3.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Maintaining a partial cvs workarea
On Sun, Aug 24, 2008 at 02:55:41PM -0700, Chris Weyl wrote: 2008/8/24 Dennis Gilmore [EMAIL PROTECTED]: That shouldnt work with the Makefiles. since they all use cvs.fedoraproject.org not the old legacy address :) s/cvs.fedora.redhat.com/cvs.fedoraproject.org/ in the above then :) I've never had any issues Though, I _really_ ought to update my checkout to use the new addy. (Yes, I've had my cvs checkout since way before it became an old legacy address, and I hate change :-) ) I also need to move my Roots to something new age. Wasn't there a tool for CVS? Or some perl/sed magic to do that? -- Axel.Thimm at ATrpms.net pgpBbr2d317cr.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Please restore ssh-dsa (was: cvs: Permission denied (publickey).)
On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: The primary reason is that it's nearly impossible to tell if the key was generated on a Debian system with the compromised OpenSSL versions. OK, I checked and it is far from impossible. After all the bug was that there are only 32k possible keys per arch/size/type - Debian has even issued blacklists for all keys of typical und some untypical sizes like 1024/2048/1023/2047/4096/8192 and for some sizes they even packaged it up, see http://packages.debian.org/unstable/main/openssh-blacklist http://packages.debian.org/unstable/main/openssh-blacklist-extra If there is paranoia floating around, then why not use that blacklist in Fedora/RHEL as well instead of nuking all DSA keys and still allowing the bad RSA keys? And if your are really paranoic then one can package up these blacklists for general use by Fedora/RHEL's openssh. I don't know if openssh has a blacklist-reject ability already coded in, though. -- Axel.Thimm at ATrpms.net pgpde22xacK2E.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Please restore ssh-dsa (was: cvs: Permission denied (publickey).)
On Sun, Aug 24, 2008 at 09:34:36AM -0600, Stephen John Smoogen wrote: * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... Have DSA keys now been banned? Yes. Why? The primary reason is that it's nearly impossible to tell if the key was generated on a Debian system with the compromised OpenSSL versions. That's overreacting. What happens if Gentoo makes a similar mistake with RSA keys, will we ban them, too? DSA is a decent technology. No because RSA doesn't leak information into your public key nor does it rely on the 'random' secret key to the same extent. Th Your mixing different issues: What you are referring to is using a good DSA key from a bad host. The context above was about the DSA/RSA keys generated in the bad two year window. Both DSA and RSA from that time frame are equally predictable. I've heard rumblings that DSA keys are weaker for other reasons, but I've not seen any good explanations. Hearsay, your honour! On the contrary, I've heard that DSA gathers at 1024 bits at least as much entropy as RSA with 2048, and DSA was the recommended new algorithm half a decade ago. Currently RSA and DSA are equal up. I take your hearsay, and counter with my hearsay that DSA will be replaced next year with DSA2 which can use 4 bits of entropy and be as secure as 4096 RSA. Cool, then let the hearsays determine our processes. -- Axel.Thimm at ATrpms.net pgpqToW1CPXUU.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Please restore ssh-dsa
On Sun, Aug 24, 2008 at 09:39:15AM -0600, Stephen John Smoogen wrote: 2008/8/24 Axel Thimm [EMAIL PROTECTED]: On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: The primary reason is that it's nearly impossible to tell if the key was generated on a Debian system with the compromised OpenSSL versions. OK, I checked and it is far from impossible. After all the bug was that there are only 32k possible keys per arch/size/type - Debian has even issued blacklists for all keys of typical und some untypical sizes like 1024/2048/1023/2047/4096/8192 and for some sizes they even packaged it up, see http://packages.debian.org/unstable/main/openssh-blacklist http://packages.debian.org/unstable/main/openssh-blacklist-extra If there is paranoia floating around, then why not use that blacklist in Fedora/RHEL as well instead of nuking all DSA keys and still allowing the bad RSA keys? All RSA keys were nuked too. Please read up the complete thread (and maybe the subject line as well :) - with nuking of ssh keys I'm not referring to the internally used ssh keys, which were all replaced, but the nuking of all user DSA keys for using in FAS/cvs. s/nuked/banned/g for a better phrasing - sorry, me no naitif ingisch spieka. -- Axel.Thimm at ATrpms.net pgpQTIBVj5fsg.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Maintaining a partial cvs workarea
Hi, I'm keeping only a partial checkout of the packages, e.g. the ones I'm maintaining. Now I'd like to be able to cvs up and have all updates flow in, but if I do so cvs will want to get all other thousand packages in. Until now I'm using a poor man's solution with a for loop and pushd/popd, but it's extremely slow due to login in for each package. Is there a more clever way to get cvs up running w/o pulling in all of the cvsroot? I could probably manually edit CVS/Entries, but this feels a bit dirty. What are other packagers doing? -- Axel.Thimm at ATrpms.net pgpPKzUFJ7D84.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Maintaining a partial cvs workarea
Hi, On Sun, Aug 24, 2008 at 07:44:39PM +0300, Axel Thimm wrote: I'm keeping only a partial checkout of the packages, e.g. the ones I'm maintaining. Now I'd like to be able to cvs up and have all updates flow in, but if I do so cvs will want to get all other thousand packages in. Until now I'm using a poor man's solution with a for loop and pushd/popd, but it's extremely slow due to login in for each package. Is there a more clever way to get cvs up running w/o pulling in all of the cvsroot? I could probably manually edit CVS/Entries, but this feels a bit dirty. What are other packagers doing? Sometimes it helps posting a problem to think more about it and solve it. For posterity and google searches: Actually what I wanted is already the default. But one usually wants cvs to automatically discover new folders and pull them in (the -d option). This is so common, that at one time in your cvs life you will add it to ~/.cvsrc as a default option like $ cat ~/.cvsrc diff -ud update -P -d and you will forget about it, and you will make silly help requests like the one I did above. :) Now you dont need to remove the otherwise useful -d switch to update, instead use cvs -fq up to get the desired (non-verbose) updating w/o getting new packages in. -- Axel.Thimm at ATrpms.net pgp6CefG8iIIX.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
cvs: Permission denied (publickey).
Hi, I saw that some people are using CVS again, so I tried as well, but I got: [EMAIL PROTECTED](1012):/home/.../smart/devel$ cvs up Permission denied (publickey). cvs [update aborted]: end of file from server (consult above messages if any) I have a new FAS password, all certs updated, I even checked the cvs procedures for newbies on fpo, but I had no luck. What am I doing wrong? Thanks! -- Axel.Thimm at ATrpms.net pgpzF8N0e660H.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: cvs: Permission denied (publickey).
On Sat, Aug 23, 2008 at 04:06:07PM -0500, Jeffrey Ollie wrote: 2008/8/23 Axel Thimm [EMAIL PROTECTED]: I saw that some people are using CVS again, so I tried as well, but I got: [EMAIL PROTECTED](1012):/home/.../smart/devel$ cvs up Permission denied (publickey). cvs [update aborted]: end of file from server (consult above messages if any) I have a new FAS password, all certs updated, I even checked the cvs procedures for newbies on fpo, but I had no luck. What am I doing wrong? Did you upload a new SSH public key? It won't let me: Error! The following error(s) have occured with your request: * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... Have DSA keys now been banned? Why? -- Axel.Thimm at ATrpms.net pgptIr49OaevH.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
FAS password reset mail not arriving
Hi, as per the mailed instructions I submitted a password reset by entering account mail into the FAS web portal. But I never received the mail with the URL reset. Thanks! -- Axel.Thimm at ATrpms.net pgpe9mWppzHUa.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Anyone using stateless linux?
Hi, On Sun, Aug 03, 2008 at 12:50:20PM +0100, Marcelo M. Garcia wrote: I was reading about stateless linux and seems a great idea. I would like to know if it's being used, the overall experience, in other words, if it is ready for to be used in a production environment. stateless linux is not something you install like a package, but rather a general concept and marketing name. And all parts that have been implemented in Fedora until now are already being used. In special as corporate desktop with local storage. Maybe what you are looking for is cobbler and maybe also bcfg2/puppet/cfengine. -- Axel.Thimm at ATrpms.net pgpU3hYfWJIaC.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Any LiveCD/USB experts in the house?
Not really a direct answer (I'd wish I were a LiveCD/USB expert to help out), but maybe these questions are better targeted at the real experts gathered at fedora-livecd-list? See http://www.redhat.com/mailman/listinfo/fedora-livecd-list Some are certainly on this list, but your questions may get lost here in the higher volume list. -- Axel.Thimm at ATrpms.net pgpgnQbyZgNQ6.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: howto: write a init script
On Thu, Jul 31, 2008 at 02:05:39PM +0200, Christoph Höger wrote: is there some documentation out there about how to write a init script for fedora9 for a given binary? Maybe even a insert your binary here-tempate? Indeed there is with even LSB support and lots of docs: http://fedoraproject.org/wiki/Packaging/SysVInitScript Consider this the most authoritative Fedora source of information. :) -- Axel.Thimm at ATrpms.net pgpRP3HbJOXlS.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: updating my getting started with QEMU under fedora howto
On Tue, Jul 29, 2008 at 06:11:42AM -0400, Robert P. J. Day wrote: On Tue, 29 Jul 2008, Axel Thimm wrote: p.s. refresh my memory, axel, if you would -- are your AT packages compatible with livna packages? It often depends on the livna packager. Suffice it to say that I've been a mirror for livna for several years now, so actually my intentions were to be compatible. But there are many cases were this didn't happen. would there be any difference in which qemu packages i used that aren't available in the stock fedora repo? The packages at ATrpms are not conflicting with the stock repo or replacing anything. They are just accelerating qemu. E.g. you will need the Fedora stock qemu to get started anyway, and you can (optionally) add kqemu kmdls to speed it up. http://bellard.org/qemu/kqemu-tech.html -- Axel.Thimm at ATrpms.net pgpWCnipKg4Rl.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: updating my getting started with QEMU under fedora howto
Hi, On Mon, Jul 28, 2008 at 02:06:24PM -0400, Robert P. J. Day wrote: i was going to take what i thought was a couple minutes and update my writeup on QEMU under fedora: http://www.crashcourse.ca/wiki/index.php/QEMU for fedora 9 but, apparently, it's not going to be a simple s/8/9/g. there doesn't appear to be a (livna) kqemu-kmdl package anymore; instead, it's kmod-kqemu. then there's this akmod-kqemu package there as well, which i've never seen before. i'm sure it won't take long to sort out the new packages, but if this has already been written up somewhere for f9, i'd be fine with that. otherwise, i'll do it myself. The URL above uses ATrpms' kmdl packages for Fedora 8 and indeed the recipe for Fedora 9 would be s/8/9/g. -- Axel.Thimm at ATrpms.net pgpvjhc5DDOpG.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Online resizing NTFS ext3
On Sun, Jun 29, 2008 at 07:48:35PM +0200, Roberto Ragusa wrote: Axel Thimm wrote: I have a running F9 installation where I want to move some free space from the NTFS partition to Fedora's. It is important to understand how your disk is configured. (LVM?) Please post the output of fdisk -l /dev/sda df things like those. I was hoping the solution would be generic, but here is my specific setup: # /sbin/fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x79b87714 Device Boot Start End Blocks Id System /dev/sda1 1 192 1536000 27 Unknown Partition 1 does not end on cylinder boundary. /dev/sda2 * 1927488586096647 HPFS/NTFS /dev/sda374897501 104422+ 83 Linux /dev/sda47502 14593569664905 Extended /dev/sda57502 1459356966458+ 8e Linux LVM -- Axel.Thimm at ATrpms.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Online resizing NTFS ext3
Hi, I have a running F9 installation where I want to move some free space from the NTFS partition to Fedora's. Usually I don't even have an NTFS partition to get into this problem, and if so I wipe the Linux partitions away, resize the NTFS partition and reinstall Fedora/RHEL. Now with F9 doing a resize upon installation this is even easier. But wiping the Fedora partition isn't an option either in this case. So how does one proceed? Which tools are the best for o shrinking the inactive NTFS partition (fs partition!) and o enlarging the online ext3 fs partition? Or is this not feasable with ext3 online? Maybe only from a rescue disk? I googled, but all I found were quite old references not including the shinny new F9 support for stuff like this. And the docu for anaconda is only for during installs, but I need to keep the old Linux partition (or maybe anaconda would even allow that?) Possibly also a good topic for the Fedora FAQ. -- Axel.Thimm at ATrpms.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: smartrpm
On Thu, Jun 12, 2008 at 03:43:01PM -0700, Kam Leo wrote: 2008/6/12 Todd Zullinger [EMAIL PROTECTED]: Kam Leo wrote: Don't bother. Multiple bug reports have already been filed. I'm surprised that this problem keeps re-occurring. Same thing happened for the Fedora 8 release. Axel must have his hands full. Actually since this is a bug out of my reach (buildssystem or bodhi) I can't do much about it. The package ACLs appear to allow cvsextras members to commit. Any guess why some other maintainer who uses smart just fix it? I've never used smart at all, else I'd consider doing it myself. The bug fix is trivial. The problem is that the fixed package, supposedly supplied on 21 May, has gone AWOL. How can it be trivial, if you see that it was built, committed as an update and even pushed to stable updates, but it never made it to the surface. Luke has been doing some magic to get it back to the living, so maybe it's already old news by the time you read this. -- Axel.Thimm at ATrpms.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Older kernel shipped as F7 kernel update?
On Sat, Feb 02, 2008 at 10:28:25AM +0100, Thorsten Leemhuis wrote:
Hi all!
/me is a bit puzzled
On 28 Jan 2008 22:14:47 -0700 kernel-2.6.23.14-64.fc7 was shipped as
update:
https://www.redhat.com/archives/fedora-package-announce/2008-January/msg00968.html
Some minutes ago on 02 Feb 2008 02:01:59 -0700 kernel-2.6.23.14-60.fc7
was shipped as update:
https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00061.html
Just wanted to report the same thing, glad it's not just me that
thinks 6064. ;)
AFAIK, -60 wasn't even a test release, or was it (???). BTW FC6 was
the last release to send test update notificatiopn to fedora-test,
this seems to have been discontinued since F7. Not a Good Think IMHO.
$ rpmdev-vercmp 2.6.23.14-64.fc7 2.6.23.14-60.fc7
0:2.6.23.14-64.fc7 is newer
Epochs involved? No doesn't look like it:
rpm -qp kernel-2.6.23.14-60.fc7.i686.rpm --qf '%{EPOCH}\n'
Was is 2.6.23.14-64.fc7 revoked? Never shipped properly? Ohh, no, some
servers carry it:
http://ftp.stw-bonn.de/pub/fedora/linux/updates/7/i386/kernel-2.6.23.14-64.fc7.i686.rpm
http://download.fedora.redhat.com/pub/fedora/linux/updates/7/i386/kernel-2.6.23.14-64.fc7.i686.rpm
/me wonders how long the letter will remain there
Bodhi error?
I thought we had one-way upgrade paths checks in the compilation
tools. At least if several candidates are available the tools are
supposed to pick the latest, right?
Several things look like having gone south for this to happen. Is it
now possible to track down the path the older package went on to
show up at the wrong place, so we can find and squash the bugs?
--
Axel.Thimm at ATrpms.net
pgpR7chA746ah.pgp
Description: PGP signature
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
ATrpms for Fedora 8; EOL for Fedora Core 6
ATrpms is officially launching Fedora 8 support for i386, x86_64 and ppc. http://ATrpms.net/dist/f8/ o The actual download location is http://dl.atrpms.net/. Mirrors are listed at http://atrpms.net/mirrors/ o stable, testing and bleeding, the three subrepos per distribution are not cumulative inclusive on the server side. E.g. you need to add stable for testing, and both stable and testing for bleeding. ATrpms is a 3rd party general purpose package repository. It currently supports o F8/i386, F8/x86_64, F8/ppc, F7/i386, F7/x86_64, F7/ppc, FC6/i386, FC6/x86_64, FC6/ppc o RHEL5/i386, RHEL5/x86_64, RHEL4/i386, RHEL4/x86_64, RHEL3/i386, RHEL3/x86_64 FC6 support will be EOL'd once the Fedora Project drops support for it (e.g. on December 7, 2007). Configuration for package resolvers (replace i386 with x86_64 or ppc as needed) o yum [atrpms] name=Fedora 8 - i386 - ATrpms baseurl=http://dl.atrpms.net/f8-i386/atrpms/stable o smart [atrpms] name=Fedora 8 - i386 - ATrpms baseurl=http://dl.atrpms.net/f8-i386/atrpms/stable type=rpm-md o apt repomd http://dl.atrpms.net f8-i386/atrpms/stable you can provide feedback or request support on the ATrpms lists (http://lists.atrpms.net/), or the common bug tracker (http://bugzilla.atrpms.net/). Enjoy! -- Axel.Thimm at ATrpms.net pgpD5gwyNvnnZ.pgp Description: PGP signature -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Missing kernel update (with security fix!)
Hi, a kernel rpm with a security fix has been pushed 24h ago by bodhi, but no mirror has it yet, all donwloadX show the old kernel but a couple that give connection refused. -- Axel.Thimm at ATrpms.net pgpjVwRFKNOjI.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Security issue: Can't build mediawiki - F7 thinks it's F8
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250819#c1 mediawiki resists my attempts to build it in various ways. The current one is that building (or trying to build) under F7 automatically elevates the package to mediawiki-1.9.3-34.fc8, e.g. an F8 package. What is wrong? -- Axel.Thimm at ATrpms.net pgp9sJL9LR5Ce.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Security issue: Can't build mediawiki - F7 thinks it's F8
On Mon, Aug 06, 2007 at 08:06:20AM -0400, Jesse Keating wrote: On Mon, 6 Aug 2007 08:03:29 -0400 Jesse Keating [EMAIL PROTECTED] wrote: This task is the one you're probably concerned with: http://koji.fedoraproject.org/koji/getfile?taskID=89866name=srpm.log I'm not entirely certain how that produced a .fc8 srpm at the end of it, looking into it. Bingo. mediawiki-1_9_3-34_fc7:devel:athimm:1172147229 You previously tagged this source as 1.9.3-34 when on the devel/ branch, presumably before the branching happened for F-7. Since the CVS tag you asked for lives ^ Typo? in devel, koji gets a little confused when making the srpm for you. You'll most likely need to bump/tag on F-7 then you can build and it will get the proper .fc7 tag to it. Hm, this sounds more like a bug that should be fixed in koji. Wouldn't that apply to any kind of branching CVS, e.g. koji inherits bad tags to branches? This bug only surfaces if the tagsing and building is intermitted by the branch, but consider adding new archs to Fedora, it will hit all packages (as the build for the new arch will be after the branching, unless new archs are limited to devel). -- Axel.Thimm at ATrpms.net pgpqWoPjLlth3.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Security issue: Can't build mediawiki - F7 thinks it's F8
On Mon, Aug 06, 2007 at 08:25:20AM -0400, Jesse Keating wrote: On Mon, 6 Aug 2007 14:18:36 +0200 Axel Thimm [EMAIL PROTECTED] wrote: You previously tagged this source as 1.9.3-34 when on the devel/ branch, presumably before the branching happened for F-7. Since the CVS tag you asked for lives ^ Typo? Not exactly. Expression mismatch. The tag was /applied/ on the devel/ branch, so when cvs is asked for that tag, it tries to pull it from devel/ and bad things happen. I was referring to lives in devel, koji gets a little confused when making the srpm for you. You'll most likely need to bump/tag on F-7 then you can build and it will get the proper .fc7 tag to it. Hm, this sounds more like a bug that should be fixed in koji. Wouldn't that apply to any kind of branching CVS, e.g. koji inherits bad tags to branches? This bug only surfaces if the tagsing and building is intermitted by the branch, but consider adding new archs to Fedora, it will hit all packages (as the build for the new arch will be after the branching, unless new archs are limited to devel). I'm not entirely sure how this is going to be handled. It probably does need looking into, something deep in the cvs branching scripts we use. My cvs-fu isn't nearly that strong :( OK, so for now bump-and-go and worry about mass issues only once they arrive? -- Axel.Thimm at ATrpms.net pgpHoZsGHUsH7.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Security issue: Can't build mediawiki - F7 thinks it's F8
On Mon, Aug 06, 2007 at 08:37:45AM -0400, Jesse Keating wrote: On Mon, 6 Aug 2007 14:35:33 +0200 Axel Thimm [EMAIL PROTECTED] wrote: CVS tag you asked for lives ^ Typo? Not exactly. Expression mismatch. The tag was /applied/ on the devel/ branch, so when cvs is asked for that tag, it tries to pull it from devel/ and bad things happen. I was referring to lives I know. I used the term 'lives' to indicate that the reference to that tag exists on the devel/ branch, IE it lives there, that's it's home. OK, sorry, my bad reading - I thought you referred to http://lives.sourceforge.net/ OK, so for now bump-and-go and worry about mass issues only once they arrive? Feel free to examine the branching tools and cvs layout to try to make it better. I'm just saying that I can't right now. Examine branching tools under CVS? I closed with CVS half a decade ago after it tortured me for quite longer than a decade ;) (me is eagerly watching the discussion about koji/svn hoping there will be an scm-abstraction in koji soon to allow for hg/git) -- Axel.Thimm at ATrpms.net pgpiO58Hxwbq3.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Security issue: Can't build mediawiki - F7 thinks it's F8
On Mon, Aug 06, 2007 at 10:54:53AM -0400, Jesse Keating wrote: On Mon, 6 Aug 2007 16:49:13 +0200 Axel Thimm [EMAIL PROTECTED] wrote: OK, we got that far, but how will you support a new arch in the tree? Usually we rebuild the package to pick up the arch. Which is something one can only do in a devel cycle, e.g. with the current setup there will never be new archs for released Fedora cuts. It's just something to think about whether this is wanted at all - with the current Fedora release cycles it doesn't hurt to add a new arch to devel only. But if koji is used for RHEL or other longer-cycle products not being able to add an arch for a released product (or having to rebuild everything for all other arches as well due to artificial release bumps) could become an issue. -- Axel.Thimm at ATrpms.net pgpUK7tmQyE2U.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Security issue: Can't build mediawiki - F7 thinks it's F8
On Mon, Aug 06, 2007 at 11:22:02AM -0400, Jesse Keating wrote: On Mon, 6 Aug 2007 17:06:25 +0200 Axel Thimm [EMAIL PROTECTED] wrote: It's just something to think about whether this is wanted at all - with the current Fedora release cycles it doesn't hurt to add a new arch to devel only. But if koji is used for RHEL or other longer-cycle products not being able to add an arch for a released product (or having to rebuild everything for all other arches as well due to artificial release bumps) could become an issue. In RHEL at least we'd want to rebuild the package anyway. You can't come along 4 months or 2 years later to request that another arch be done of that build, unless you can generate a repodata set that matched the original repodata set and all the original used packages to build your package 4 months or 2 years ago. Buildroot content changes over time and you don't want 3 of your arches using one set of build tools and your new arch using potentially vastly different ones. RHEL is quite different and already equipped to do builds in fixed environments like for customer requested RHEL X update Y states. Furthermore RHEL is not update happy, certainly not in comparison to Fedora, so 4 months or 2 years usually still means the same API/ABI (short of the kernel, of course). But I was told in the interim that the pain of the past of adding archs to released RHELs hardened the RHEL engineering teem enough to fence off any such future requests. ;) -- Axel.Thimm at ATrpms.net pgp6hhYSGXKQF.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Kernel rpm versioning changes
On Mon, Jul 02, 2007 at 04:22:24PM -0400, Jarod Wilson wrote: Okay, here's the first draft of spec changes to alter the kernel rpm version and release fields to more closely match what the actual upstream kernel base is. Its heavily commented at the moment to try to explain what's going on. The basic approach is this: 1st fedora build of 2.6.21.5: kernel-2.6.21.5-1.fc7 2nd fedora build of 2.6.21.5: kernel-2.6.21.5-2.fc7 1st fedora build of 2.6.22-rc6-git3: kernel-2.6.22-0.rc6.git3.1.fc8 2nd fedora build of 2.6.22-rc7: kernel-2.6.22-0.rc7.2.fc8 I'd suggest kernel-2.6.22-1.rc6.git3.fc8 kernel-2.6.22-2.rc7.fc8 an no resetting of the buildtag (the first integer) when rc6 becomes rc7 and the like o The shove-the-zero-in-front method is a method from the past when a third party would assume the vendor to start using Release tags starting with 1 and needed to make the package auto-overridable. But it makes no sense whatsoever to have the vendor himself do that ... (yes, it's part of the current guideline, but worth fixing and this could be a motivation to do so, not that many packages use non-released upstream - the kernel is the very exception here) o The buildtag doesn't mix well with the upstream extra version. Is it rc6.git3 or rc6.git3.1? Are there rc7.2 upstream releases? o indepdendence of the rpm-ordering of upstream's extra versioning, e.g. not basing the versioing scheme on facts that git rc, so we're lucky this time- ;) The don't-reset-buildtag-on-prereleases allows upstream to do anything they like and you're safe. o It also fits well with the non rc packaging scheme, e.g. going form git28 to rc1, then rc2.git1 etc. You just increase the buildtag and let upstream put the steam off wth any sub versioning they like. Yes, finally you'll end up with kernel-2.6.22-23.f8 That's OK, we've been in 4 figure integers already. And if someone really needs the first 2.6.22 build to be called kernel-2.6.22-1.f8, then modify the above to using 0.integer, e.g. kernel-2.6.22-0.1.rc6.git3.fc8 kernel-2.6.22-0.2.rc7.fc8 Still better to prepend the upstream's extra version part than to suffix it due to the ordering issues and the semantic mixing effects. -- Axel.Thimm at ATrpms.net pgpMjUXgXLoyl.pgp Description: PGP signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Infrastructure SCM
On Mon, Jul 02, 2007 at 08:10:17PM +0530, Rahul Sundaram wrote: Mike McGrath wrote: Actually this SCM is just for our infrastructure stuff (not the packages) so it replaces what is now in: http://cvs.fedoraproject.org/viewcvs/?root=fedora Wouldn't it be better to make the decision for both together and settle down on one SCM instead? That would be good, of course, but I think the packages' SCM has quite a bit higher set of specificiation constraints than infratsructure, so a common SCM would mean deciding one for packages. If Mike wants to do something for infrastructure now, bundling this decision with the packages' SCM will stall him. The evaluation for the latter will take quite a while still and require being blessed by many key positions. While Mike could cast a decision for infrastruture by the end of the day. -- Axel.Thimm at ATrpms.net pgpUz38EJaiOD.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Infrastructure SCM
On Mon, Jul 02, 2007 at 11:24:39AM -0400, Jesse Keating wrote: On Monday 02 July 2007 10:50:39 Axel Thimm wrote: +1. There's also better intergration with other tools like trac, and it's written in Fedora's favourite script language, so when something comes up we'd be able to attack it instead of submitting feature requests. The Trac integration is only marginally better than git's. It's still missing a lot and could use just about as much love as the alpha git plugin. In the trac camp there's love for mercurial but not for git, don't ask me why. Also when 0.10 hit the streets mercurial support for it was working and managable, while git was in experimental planning stage. But don't rust me, just look at the metrics, the changelog of the mercurial plugin at trac goes until 20070628, e.g. a couple of days ago, while the gitplugin's last date is 2006 (8 months) and OLPC's git efforts go until 20060822 (10 months). So, it's actually quite far from calling the difference in support between mercurial and git marginal, perhaps it's more like existing and not. ;) -- Axel.Thimm at ATrpms.net pgpd1dWdiT7Gi.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: You need to create a bugzilla account for [EMAIL PROTECTED]
On Sat, Jun 30, 2007 at 08:29:03PM +1200, Nigel Jones wrote: Axel Thimm wrote: As the mail admits this is amazingly stupid, unless someone wiped my bugzilla account ... Heh On Sat, Jun 30, 2007 at 01:08:37AM -0400, [EMAIL PROTECTED] wrote: In order to make bugzilla components for Fedora-related programs, we need to have an existing bugzilla account for the listed owner. You ([EMAIL PROTECTED]) do not have a bugzilla account, but are listed as the owner for the following components: Fedora (apt) Please create a bugzilla account for [EMAIL PROTECTED] immediately, because this amazingly stupid cron job will keep sending you an e-mail every hour until you do :) 1. Can you still login to Bugzilla Yes (wiping the sweat of the forehead ;). 2. Are you getting the email hourly? Hourly? Even if the script were not detecting false positives, would it make sense to spam up such a user's mailbox that way? Especially on a weekend? Are you sure this was going to be hourly and not say daily/weekly? I suspect this may be due to the maintenance that took place today. -- Axel.Thimm at ATrpms.net pgpIfl0n42sM5.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Error processing Fedora Account System email
On Sat, Jun 30, 2007 at 02:17:11AM -0700, Thomas Chung wrote: On 6/30/07, Axel Thimm [EMAIL PROTECTED] wrote: ??? On Sat, Jun 30, 2007 at 01:15:34AM -0700, Fedora Account System wrote: With regards to Re: You need to create a bugzilla account for [EMAIL PROTECTED]. Your message could not be processed. Reason: The signature could not be processed. The signature may have been created or attached improperly, it might not match the key ID you have registered in the Account System, or the public key may not have been found on the key server. For guidance, please see the following page: http://fedoraproject.org/wiki/Infrastructure/AccountSystem/CLAHowTo I see cla_done in your Fedora Account[1] already. Are you trying to request another CLA? [1] http://fedoraproject.org/wiki/Infrastructure/AccountSystem/QueryAccount Regards, No, I just replied to the self-proclaimed amazingly stupid mail I received about not having a bugzilla account anymore. So now I have to shiver in agony whether both my bugzilla account *and* cla_done bit are scheduled for erasure? Not. -- Axel.Thimm at ATrpms.net pgp56DZoqiNYT.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: kmods poll
On Tue, Jun 19, 2007 at 03:01:07PM -0500, Josh Boyer wrote: I'd like to just do a brief poll here just to see how many are yay or nay for kmods. And I'm not talking about their current implementation or the other various ways that the idea can be accomplished, but rather on the idea of having kernel modules as separate packages in general. If you're against the general idea and want to follow up with reasons why that's fine. I'm late in the query, but definitely, yes. People come screaming at ATrpms to get kmdl updates which can't go in as afast into either the kernel sources proper or a patch into the kernel rpm. Any kernel module project will have external kernel module build setups available before being able to get into the kernel, even the ones that already have a slot there. Arguing that one should wait for the vanilla kernel to incorporate those patches while OTOh we are talking about how to evr CVS/svn/git/hg cuts of everything else is a bit hypocritical. Especially with all the patching that still happens in the Fedora kernel. I just want to avoid implementation discussions at the moment if possible. Unfortunately the (bad) implementations and lack of a standard (and standard is not always what is written in the guidelines ...) add to the problem enormously. I don't think you can really separate the discussion. If you had a nicely working scheme everybody would support, you wouldn't have that much hostility against packaging kernel modules. Heck, *some* of the patches to the Fedora kernel could be managed as external kernel modules and save the pain of upgrading the main kernel package when such a subsystem is touched. In fact many such changes that people would like to see fixed have to wait to queue up to make a kernel update worthwhile for all Fedora users. Anyway the latter is a pipe dream - unless the kernel packager group at Fedora sees truly painlessly working kernel module packages there won't be any such outsourcing. But getting an infrastructure that supports building sane kernel module packages would be a plus in any relation, even if not used by Fedora itself for more than half a dozen packages. As a fact currently several repos are looking at using koji and one blocker is whether adding kernel module support would be possible. There are also some RHEL-only related benefits to endorse external kernel module packages, but I won't dwel into that on *fedora-kernel* :) -- Axel.Thimm at ATrpms.net pgpZC69yllnwe.pgp Description: PGP signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: bodhi and security updates/updates-testing
On Thu, Jun 21, 2007 at 08:33:16PM -0400, Jesse Keating wrote: On Thursday 21 June 2007 18:21:58 Axel Thimm wrote: And trac munges the back operation in the browser. Looks like the login timeouts are insanely short and trac has no recovery mechanism for that. That's... odd. how long does it take you to enter the ticket? I typed in the ticket, then checked back with the email whether there was anything else I forgot to write and when returning to the browser I modified some text and pressed on Preview. Then Boom, no TRAC_CREATE permissions and my ticket submission couldn't be recovered by going back (nice wiping that tracs makes ...). Maybe I'm an infinitesimally slow typer. All in all the issue is not how fast can a ticket submitter type, but whether there are proper recovery mechanisms for reauthetication and whether the reauthetication intervall isn't paranoically short (we don't have any reauthetication timeouts with bugzilla.redhat.com, and that works well there). I've seen similar with mirrormanager, but there the session recovers and continues smoothly after the reauthetication, while trac didn't even try to reauthenticate and ate my data. Don't ask me to file that somewhere that will time out again ... ;) -- Axel.Thimm at ATrpms.net pgpK19QGoIX8K.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bodhi and security updates/updates-testing
On Fri, Jun 22, 2007 at 09:47:02AM -0400, Jesse Keating wrote: On Friday 22 June 2007 03:11:06 Axel Thimm wrote: Don't ask me to file that somewhere that will time out again ... You mean like Trac's upstream? (: I know that trac upstream doesn't time out login sessions, at least not by default, as I've set up quite a lot of trac instances by now. And any transparent authentication proxy set in front of it should be ... transparent. ;) -- Axel.Thimm at ATrpms.net pgp4AH8krJcmQ.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: bodhi and security updates/updates-testing
On Fri, Jun 22, 2007 at 10:14:05AM -0400, Jesse Keating wrote: On Friday 22 June 2007 10:14:36 Axel Thimm wrote: I know that trac upstream doesn't time out login sessions, at least not by default, as I've set up quite a lot of trac instances by now. And any transparent authentication proxy set in front of it should be ... transparent. Hrm, would you like to lend me a hand then? We're just using http auth to a postgres server. Find me on IRC at your convenience and we'll go over http configs? We could do that, but I just verified Till's assumption that there is no timeout in fp.o's trac, but something else was amiss soem hours ago that logged us all out: I kept a session in bodhi's ticketing system idle for more than two hours and the session was still functional. Of course, perhaps there really was a timeout problem and someone already fixed it by now. The remaining question would be what happened this morning that logged out Till and me. Perhaps the logs of the machine indicate something, maybe someone performing upgrades and/or rebooting the system. -- Axel.Thimm at ATrpms.net pgpONNVs3LGRv.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: kqemu inclusion in kernel
On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: Hi folks, I've started playing around with virtualization at work and the first thing I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It was GPL'd in February and although I realise Axel is packaging kmdl/kmods kmods? Heaven forbid, no. ;) it would be good to know if this is being queued up for mainline. If not then can it be backported for Fedora kernels. If that is not possible then can it be moved into the default repos to save users (me) bolting on another repo (no offence Axel). No offense taken. Last summer I tried to get the kmdl mechanism into Fedora proper but the usual suspects didn't let it happen. If we had nice working kmdls in Fedora it would be a matter of a day to get it in there. But replicating a kmod pair out of the kmdl would just make it more difficult to bolt on another repo. I also know that the main kernel packagers don't really like the idea of any added kernel modules outside the kernel (partly for good reasons, they can't really make a proper QA/bug diagnosis if they don't know how many and which kmdls you have installed in addition to what they packaged into the kernel rpm, although until now it was never really a significant issue in practice). Please forgive dual list posting but I know DJ reads the kernel list and might want to comment whereas I'm not sure AT does. And vice versa. We're both everywhere. Trimming to the kernel list. -- Axel.Thimm at ATrpms.net pgptFCwipBPrT.pgp Description: PGP signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Build once, serve many
Hi, some packages are best build for all releases once only like for example firmware, game data and other packages that you know will not change from release to release. Currently such operations are made manually and one needs to find the right person to talk to. I think it would be more consistent if koji and friends allowed one to tag a package as such. Perhaps koji's tagging is alread enought to hardlink a package source and binary-wise across releases? If so, please enlighten me with the mechanism details, if not, please consider this an RFE. :) -- Axel.Thimm at ATrpms.net pgp910xcwLSEd.pgp Description: PGP signature -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Upgrade metrics
Hi, is it possible to create some relative metrics of release upgrades, e.g. FC5 - FC6, FC5 - F7? The interesting part is to create a graph over time to answer the question whether the 13 month EOL is really paying off. And perhaps on base of that graph one could revise this decision. At the very leats it would be interesting to notice the upgrade behaviour of Fedora users. I have no idea how to do that other than marking the HTTP Agent of yum on FN accordingly, as well as the HTTP Agent in anaconda's yum (noting fresh installs vs upgrades). Worth to add this for F8? -- Axel.Thimm at ATrpms.net pgpuyJXHslXxb.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Upgrade metrics
On Fri, Jun 15, 2007 at 08:54:53AM -0500, Mike McGrath wrote: Axel Thimm wrote: Hi, is it possible to create some relative metrics of release upgrades, e.g. FC5 - FC6, FC5 - F7? We didn't really start taking metrics until FC6. Yes, I know, I was just giving examples of where it would had been useful in today's context. Testing 13 month life span would probable be better done in the F8 release time, e.g. checking how many FC6 users really upgrade to F8 skipping one release (which is what the 13 month span was about). If we need FC6 to send out more info in some way (smolt, yum http agent etc) we should implant that early in both FC6 and F7, so we know in autumn what people are really doing (always in relative numbers, e.g. FC6-F8 upgrades in comparison to F7-F8 upgrades and F8 install from scratch) The interesting part is to create a graph over time to answer the question whether the 13 month EOL is really paying off. And perhaps on base of that graph one could revise this decision. At the very leats it would be interesting to notice the upgrade behaviour of Fedora users. I have no idea how to do that other than marking the HTTP Agent of yum on FN accordingly, as well as the HTTP Agent in anaconda's yum (noting fresh installs vs upgrades). Worth to add this for F8? So here's a graph of the smolt vs yum ip stuff: https://admin.fedoraproject.org/cacti/graph.php?action=viewrra_id=alllocal_graph_id=253 Nice graph! This gives us an estimate of absolute numbers, but not yet upgrades vs bare metal installs. It nicely shows that smolt and yum data are coherent. The problem with the smolt numbers is that anyone doing kickstarts, installing via runlevel 3, yum upgrades or anaconda upgrades will never get prompted to enable smolt and there are privacy concerns just enabling it by default. That doesn't matter, we won't get everyone and there will be an unknown dark factor. But the numbers we get can be divided to remove that unknown constant, e.g. create relative numbers. For example: In the first 4 weeks after the release of F8 and until EOL of FC6 we saw that: 70% did a bare metal install 20% upgraded from F7 9% upgraded from FC6 1% did something else (like upgrading from RHL9) These are the numbers we would need to justify a 13 month EOL time including all efforts that go with it, or whether it wasn't worth it because say only 1% would make really use for FC6-F8 upgrades and we better invest that man time into something else. also if these numbers can be seen over time we can spot when the user do the bare metal installs and the upgrades. I would guess that after a release one would have a large bare-metal-install peak and some time after that the upgrades would slowly grow as well. The scary thing is I still regularly get requests regarding Fedora Core 1!! (we moved it from the primary mirror to http://archives.fedoraproject.org/fedora/linux/core/1/ and that brought some people out of the woodwork) Wow, that's really scary. FC1 should of course live forever in archives.fp.o for historical reason, but actually using it is really questionable :) -- Axel.Thimm at ATrpms.net pgpT6FjBEE4ku.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: end of Fedora Legacy mirror at Iowa State
On Mon, Jun 11, 2007 at 09:28:21AM -0500, Dave Edsall - JETSETer wrote: Max Spevack announced last month that Fedora Core 5's end of life would be June 29th. That gives us a good milestone for removing our Fedora Legacy mirror. Traffic was high for two months after the announcement of Fedora Legacy's demise but has dwindled since April. So, beginning July 1, 2007, Iowa State will no longer offer a mirror of Fedora Legacy. Grab what you would like between now and then. Would whoever is responsible for http://download.fedoralegacy.org/download/f edoralegacy-mirrors.php please remove us from that page at your leisure? Could you also remove ATrpms' mirror? Many thanks to everyone who worked on that project! Dito! -- Axel.Thimm at ATrpms.net pgpYZbxCoka7U.pgp Description: PGP signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: atop?
On Fri, Jun 08, 2007 at 03:47:34PM -0400, Bill Nottingham wrote: Axel Thimm ([EMAIL PROTECTED]) said: These patches: a) aren't upstream b) change the format of /proc/stat c) change process accounting in an incompatible way So... no. OK, fair enough (I wasn't aware of b) and c)). Any other way then to achive the stated goals? I haven't tried, but blktrace? Very nice! One does get process - I/O bandwidth. No filesystem info, though, but I shouldn't be greedy ;) If I find a minute I'll submit a package for this. Thanks for pushing me to the right track! -- Axel.Thimm at ATrpms.net pgpUy2S28sDR9.pgp Description: PGP signature ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
