Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Nicolas Mailhot wrote: When i18n asked what was the exact need for bitmap-fonts no one answered. Legibility? I don't know about font systems, is Terminuis a core font? It is bitmapped, but I don't know if that automatically makes it a core font. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Do not expose to extreme heat, cold, or open flame. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Konstantin Ryabitsev wrote: Moreover, even sudo doesn't ask me again if I invoke it within 5 minutes of using it (or however long it is). It does if it was kdesu asking (at least, it's supposed to; otherwise a malicious app can gain privilege by waiting for you to use kdesu and then immediately asking for privilege). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- KATE: Awesome Text Editor -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Kevin Kofler wrote: Petrus de Calguarium wrote: By the way, colours on old kde3 apps doesn't work, either, despite enabling for non-kde4 applications in system settings (kftpgrabber) - I can see it already: file a bug report :-) There's already an ages-old bug report, the upstream KDE developers don't care. :-( ...or maybe the upstream developers don't know how to fix it. Help welcomed. (Actually, it's more accurate to say that I am not aware of anyone maintaining the 'export colors' functionality. Jeremy Whiting and I are - last I knew, anyway :-) - the nominal maintainers for color kcm stuff, and I certainly fix anything I can, but I know next to nothing about how the export colors stuff works. Ergo, I am not able to fix it.) FTR, exporting colors to GTK seems flaky also, but I'm not sure it's a KDE problem. I've noticed that after I force the export code to run (basically, make any change and apply it - even toggle a checkbox twice, you just need to be able to press 'apply'), the first app will be right, but the next one gets default colors. At least for Mozilla apps (FF, TB) and IIRC gitk. OTOH, Inkscape seems okay. I might try to fix this somehow. If you are able to help, that would be /much/ appreciated. Please don't hesitate to work upstream, I would very much like to see these issues resolved. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- HIPPOS feel unacknowledged. HIPPOS get angry. PRAISE HIPPOS HIPPOS seem somewhat placated. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
Adam Williamson wrote: On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote: On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote: Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages', Because not all files in -devel packages cover multiple target platforms. Example: You could not build for i686 with headers that are specific to x86_64, and you would also need the .so symlinks for libraries in the appropriate libdir. Well, that's only valid if we actually do anything to ensure multilib compilation actually *works*, right now all we enforce is that the packages don't conflict (which isn't the same thing at all). Well... at $DAYJOB we *depend* on being able to compile 32-bit on 64-bit for at least a couple products. And not just on Red Hat (and in my case, Fedora), but also on Solaris, HP-UX, Darwin and AIX, all of which support this just fine. (Yes, all includes Fedora/RH, at least for the admittedly limited set of libs we use.) That said, I'm not asking for it to be actually tested in Fedora, just that if it breaks and I complain, the reply won't be we don't care because that is not supported and therefore it will not be fixed. IOW I am fine with the current status quo, but I don't want to see multilib dropped (not even sure it can be due to wine) or the policy otherwise become explicitly hostile toward multilib compilation. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- The government is not trying to destroy Microsoft, it's simply seeking to compel Microsoft to obey the law. It's quite revealing that Mr. Gates equates the two. -- A government official -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: libprojectM Packaging Problem
Michael Schwendt wrote:
On Sun, 11 Oct 2009 09:33:12 -0400, Jameson wrote:
My current attempt at their SVN code can be found at:
http://www.vtscrew.com/libprojectM-1.2.0r1295-9.fc11.src.rpm
Patch attached. Do the same for any other directories where it may be
necessary.
SET (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fPIC)
SET (CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -fPIC)
This seems fishy. Why is adding -fPIC needed (i.e. why is CMake not
taking care of this)?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
The government is not trying to destroy Microsoft, it's simply seeking
to compel Microsoft to obey the law. It's quite revealing that Mr. Gates
equates the two. -- A government official
--
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
James Antill wrote: ATM we don't carry reason=dep across updates To ask the obvious... why not? An update is not necessarily a user action (I run 'yum upgrade -y' in cron jobs on two machines, and may start doing it on more). IMO updating an existing package should *never* change the reason. Installing a package via update should only set reason=user if the package was named in the arguments to yum (which should be the behavior also for 'yum install', actually). ...and I suppose 'yum update' should warn when updating a package named in the arguments if that package is not marked reason=user. (Why not auto-mark? Because maybe I am updating a library to fix a bug in some dependent program I use; I probably don't care about keeping that library if I later remove the program that needs it.) Probably the sanest request here is that if you do: 1. yum install blah 2. try out blah, don't like it 3. yum remove blah ...you don't get rid of any extra stuff you got with blah, hopefully yum history undo will solve that in a better way by recording what happened at #1 and undoing it instead of trying to piece together what might have happened at #1 after the fact. Actually, I disagree. Let's say I install bar, with dependencies cow and pig. Then I install foo with dependencies cow and dog. What I would like to see happen is 'yum remove bar' removes bar and pig (but not cow, because foo needs it). If I then later 'yum remove foo', that should take care of foo, cow and dog. 'history undo' only works if nothing happens between the request to undo, and the action being undone (or else intervening actions have a net effect of nothing). If reason worked correctly, I don't see a problem with 'yum remove' always removing dependencies when no longer needed. ¹ It's also true that saving 1 cent of disk space isn't at the top of my list of things to do. Unneeded packages don't just use disk space, they also use CPU, network bandwidth, and cause excess disk wear due to the stream of updates for packages you don't need. (Plus that they can add up.) And I've mentioned before that I hate this 'disk space is cheap' argument; it doesn't (yet) apply to SSD's and its rooted in the make the user buy better hardware attitude that IMO is a very bad thing. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Hey! Where's the witty punchline? (with apologies to Hostess) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
David Cantrell wrote: But I explained in the previous reply how to cycle the interface using either the network service or NetworkManager. I still view this as something more technical users will be familiar with and for the average user, simply rebooting the system is the easiest method. No, the easiest method is: The following updates require their respective services to be restarted for the updates to take effect. List of services. Proceed? [Yes] [No] Well, easiest for users. Not so much for developers :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Unknown/Anonymous -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
Dariusz J. Garbowski wrote: Hi, something that bothers me a bit... More and more system restart requests with each update (even if one doesn't use the package at the time). This is a real shame. One of the selling points of Linux is that you *don't* need to reboot for every little upgrade (unlike a certain other OS I shan't name). Is this necessary for dhclient and dhcp update packages to require restart? Wouldn't service network restart and service dhcpd restart in the install/upgrade scripts do the trick (after checking that the service is actually running)? Ssh used to do that since, well, as far as I remember. Yes, please. Though maybe with prompting; we shouldn't go restarting possibly-critical services without good warning. As David said, for dhcpd, 'service restart dhcpd' should be fine. For dhclient I would question why /any/ restart is needed. If your dhcp connection is currently established, is dhclient even running? And even if it is, what benefit do you get cycling the interface /now/, if the new dhclient takes over whenever the interface cycles anyway? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- For great justice!! -- Captain (Zero Wing) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Kevin Kofler wrote: Rahul Sundaram wrote: A quick way to actually check for such dependencies is to switch to another desktop environment, say Xfce, remove all the KDE packages and install one of the KDE apps. It usually reveals dependencies which are rather silly. I have seen kde-settings, background packages and kdebase pull in odd dependencies on occasions. k3b, ktorrent, scribus et all are often used outside KDE. It's not like those dependencies bite. ;-) HDD space is cheap. Not on netbooks it isn't! I'd have to buy a new machine to get bigger than the 4 G ssd I currently have. There's a reason I nuked the entire printing support chain, even though it deprived me (for no good reason IMO) of kcalc. I don't find it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- workspace drags in Akonadi (and thus MySQL, which is a hard requirement of Akonadi) and I'm not sure the current subpackage explosion (FYI, rdieter split out subpackages to break both the links in the offending chain: in upcoming updates, ktorrent no longer requires kdebase-workspace, only the kde-plasma-ktorrent subpackage does, and kdebase-workspace no longer requires akonadi, only the kdebase-workspace-akonadi subpackage does) are a step in the right direction (as they mean the default installations of both ktorrent and kdebase-workspace/Plasma will be missing features). I'd rather have unneccessary dependencies than useful features not installed by default. I have to disagree with part of this. I don't disagree with kdebase-workspace having a hard dependency on akonadi, but I /am/ leery of anything that doesn't enhance the KDE desktop having a hard dependency on kdebase-workspace. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- $ kill bill kill: can't find process bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Jesse Keating wrote: On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote: I don't draw the line, the maintainers of each package draw their own line. I just sit back and comfortably sip on my mai tai while the people who know best make the proper decisions. But you obviously have a personal line somewhere. Where is your line that you're willing to take latest upstream builds, but won't move to rawhide? For me, that's easy. I don't want updates that the packagers don't consider stable. It sure sounds to me like Christopher feels the same way. I am willing to take the latest upstream builds because the maintainer considers them safe. I am not willing to use rawhide because it's considered a free-for-all. (I don't use updates-testing either, which IMO if I slurped everything relevant from updates-testing, would be about the same thing as using rawhide.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Thank you for reading all the way to this .sig. You may stop reading now. Really. It is safe to stop. There is no more content. Why are you still reading? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Jesse Keating wrote: On Fri, 2009-08-07 at 11:05 -0500, Matthew Woehlke wrote: For me, that's easy. I don't want updates that the packagers don't consider stable. It sure sounds to me like Christopher feels the same way. I am willing to take the latest upstream builds because the maintainer considers them safe. I am not willing to use rawhide because it's considered a free-for-all. (I don't use updates-testing either, which IMO if I slurped everything relevant from updates-testing, would be about the same thing as using rawhide.) So if rawhide had an updates-testing like repo, you wouldn't mind using it? If that put an end to stuff like 'sorry, that last glibc rpm bricks your system if you have the misfortune of installing it'... maybe. As I said, right now my line is packages that the maintainers consider stable. If rawhide became that (and some new rawhide-testing or such for the current free-for-all), then I suppose I might use it. I'd also ask how that differs in any significant way from a rolling release. To be clear, 1. I would be in favor of a rolling release system, and 2. development /needs/ a free for all environment. So please don't take the above as being in any way opposed to such an environment existing... just so long as I can opt out of it ;-). Oh, and on a related note, it would be really helpful if it was possible to enable updates-testing only for certain packages (and when needed, dependencies thereof) on a permanent whitelist basis. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Thank you for reading all the way to this .sig. You may stop reading now. Really. It is safe to stop. There is no more content. Why are you still reading? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Jesse Keating wrote:
Well with the no frozen rawhide proposal, from the Alpha freeze point on
there would be such an updates-testing for the pending release, while
rawhide remains the wild west. You could say install F12, then at F13
Alpha jump onto F13 and have the much newer more often content that has
had some testing. Just keep jumping to the next Alpha and you have your
rolling release as it were.
How does that differ from the current situation (except for being a
little more bleeding)?
A true rolling release is install-once, update-forever. Yes you can more
or less do this with upgrade-via-yum, but it is still a large chunk of
effort at 6- or 12-month intervals.
Oh, and on a related note, it would be really helpful if it was possible
to enable updates-testing only for certain packages (and when needed,
dependencies thereof) on a permanent whitelist basis.
include=package in the yum conf for updates-testing.
Will that also use packages from -testing when needed to resolve
dependencies for something in the include list? Or will it just break?
('man yum.conf' makes it sound like the latter...)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Thank you for reading all the way to this .sig. You may stop reading
now. Really. It is safe to stop. There is no more content. Why are you
still reading?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson wrote: Same question for KDE - someone writes a tool for their group based on some KDE libraries, doesn't expect an update to come along and do a major KDE version bump and break some interface the tool relied on... KDE would generally consider it a bug if that happened (API compat broken by a non-major* update), unless it was an interface that already had a big BC/SC not guaranteed warning label. (* major = e.g. KDE3 - KDE4) There may be situations in which such a break would be done anyway, but there would have to be a strong argument why such change is so critical as to warrant a compatibility break. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Thank you for reading all the way to this .sig. You may stop reading now. Really. It is safe to stop. There is no more content. Why are you still reading? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Doug Ledford wrote: Every system I build still keeps the analog signal cable between the CD/DVD and the soundcard. This doesn't help if I try to watch a movie as that signal has to be decoded and then played, but for audio CDs it is still a perfectly acceptable means of playing the music. So I'm not sure where this CD in is obsolete comes from. Even the motherboard I bought about 2 months ago still has a CD in port and the CD/DVD in that machine still has an analog output. CD is digital and can be read in digital format by your CPU and sent in digital to the sound device. This is lossless. You want to: (D-A) do the DAC in the CD drive (A) toss that on an analog wire (A/A-D-A) apply an analog volume adjustment (if you're lucky; you might actually end up doing a ADC, digital volume adjustment, DAC) (A/A-D) toss that on a different wire that might be digital (A/D-A) hear it from your speakers You could: (D) read the CD digital data (D) toss said data to the sound device (losslessly!) (D/D-A) apply a digital volume adjustment (or maybe analog volume adjustment after DAC) (D/D-A) send that, maybe digitally, to your speakers (A/D-A) hear it from your speakers What exactly is better about the first scenario? At *best* you're moving the analog signal across a longer run of wire (and one that is inside your computer case with who-knows-what shielding picking up who-knows-what interference). At worst you've tossed several analog elements into a process that could have been digital from disc to speaker cones. Seriously... do I miss something? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Disadvantage: Bad Puns [-5] You constantly utter puns so egregious as to cause mental distress to anyone hearing them. This can, however, be used to distract enemies. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: Modern sound card designs don't do hw mixing anymore, it's like fm synthesis or wavetable audio. /me misses fm synth :-) (At least, I'm still looking for something that will turn a MIDI into a .wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is the closest I've found so far, but it sucks for batch processing.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Disadvantage: Bad Puns [-5] You constantly utter puns so egregious as to cause mental distress to anyone hearing them. This can, however, be used to distract enemies. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: On Thu, 30.07.09 17:09, Matthew Woehlke (elided) wrote: Please do not quote my e-mail address unobfuscated in message bodies. Lennart Poettering wrote: Modern sound card designs don't do hw mixing anymore, it's like fm synthesis or wavetable audio. /me misses fm synth :-) (At least, I'm still looking for something that will turn a MIDI into a .wav/.ogg/etc that sounds like an SB16... DOS MIDI player in dosbox is the closest I've found so far, but it sucks for batch processing.) Try timidity. You have a soundfont that sounds like an OPL3? If so, I would be much appreciative if you could hook me up. (But I'm guessing you failed to read the part about sounds like an SB16... i.e. an OPL3 fm synth chip, not the AWE-generation wavetable stuff. I *do* still have my Creative AWE .sf2's, thank you.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Disadvantage: Bad Puns [-5] You constantly utter puns so egregious as to cause mental distress to anyone hearing them. This can, however, be used to distract enemies. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: On Thu, 30.07.09 16:53, Matthew Woehlke (elided) wrote: Please do not quote my e-mail address unobfuscated in message bodies. The analog path for CDDA is completely broken and obsolete: - It doesn't work if you have more than one cd drive Sure it does (assuming you have something to plug the second drive into). I've used two drives with one card; second drive was on AUX. - It doesn't work if you have more than one audio device Not really true, you just can only play via one device. Of course, the other points are all valid. (Well, didn't know about not working with SPDIF, I would have assumed there would be an ADC in that case...) -- Matthew Disadvantage: Bad Puns [-5] You constantly utter puns so egregious as to cause mental distress to anyone hearing them. This can, however, be used to distract enemies. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Bill McGonigle wrote: What's it going to take to make most people who shut off SELinux stop doing that? ...being able to install bleeding-edge devel KDE to /usr/local/my-kde-install and be able to use that as my primary desktop. I guess that would - at best - take some kind of smart auto-labeling on the first exec of an unlabeled process. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Disadvantage: Bad Puns [-5] You constantly utter puns so egregious as to cause mental distress to anyone hearing them. This can, however, be used to distract enemies. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Adam Williamson wrote: On Thu, 2009-07-23 at 17:17 -0500, Matthew Woehlke wrote: I have to ask... when are we going to see Linux allow network access based on the checksum of the process that wants to use it? After all, 'doze has had this ability for years. (Maybe SELinux can provide this already?) It's probably a good thing we didn't do this a few years ago. With md5 checksums. ;) Not really; checksums just provide an additional layer of security above the process name (or better, full path, which means root-owned are already pretty well protected without the checksum). Besides *any* form of per-process permissions would be more than we have now. Although checksumming isn't needed if you do it via SELinux contexts in a way that you can't accidentally set a context, and any change to a binary causes the context to be dropped. (This is probably better because a: you rely on the OS to drop the context on /any/ change, so there is no checksum that can be spoofed, and b: you can trust the package manager to assign contexts, which results in less maintenance since updates via the PM don't require updating checksums.) (And I realize that I am pretty sure SELinux doesn't provide real per-process security; maybe for listening, but for outbound, a good per-process firewall can restrict what addresses a process can talk to. I don't think SELinux can do this? And if it can, it is certainly wandering very badly into iptables' territory.) I guess one way to do this would be to (maybe using SELinux?) toss sockets opened by a process (identified by full path and checksum) onto a specified iptables chain rather than the default OUTPUT. This would require the least changes to iptables, and is roughly what Tiny (Windows, best firewall I've encountered yet in terms of function) does. INPUT unfortunately must be done differently since you are blocking above the socket layer. Besides the ability to make temporary holes (which I like), I think the best thing would be to have an iptables rule that allows stuff if there is a socket that will receive it, otherwise can drop (if you don't drop, you're just using 'allow' permanently and letting the OS handle the close notification). Then use SELinux or something similar to control if a process is allowed to open listen sockets in the first place. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Björn Persson wrote: Matthew Woehlke wrote: an iptables rule that allows stuff if there is a socket that will receive it, otherwise can drop Where's the point in that? Stealth? You might as well ask what is the point of using DROP (instead of REJECT) at all. Obviously there is a reason or else it wouldn't exist. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Stephen Gallagher wrote: On 07/24/2009 12:03 PM, Matthew Woehlke wrote: Stephen Gallagher wrote: Python does not make for a particularly efficient long-running daemon. And if your plan is to monitor for port openings in order to prompt, it's going to need to be a long-running daemon (also you'll probably want a kernel module component to signal your daemon when a port is opened) If I might suggest, you probably want to use a compiled language like C. The GLib C framework is probably a good approach, especially with its excellent glib-dbus integration. If I might suggest, C++ and Qt would also be a fine approach :-), the object model isn't built on C hacks, and Qt also has great dbus integration. (And it's bloody easy to design UI's in Qt. And you could make friends by working with KDE instead of making them play catch-up, for a change.) Why does everyone have to reach for glibc first? Sorry, wasn't trying to start a holy-war. :-) Since I also do not wish to start a holy war, I'll stop now. Both camps have now been suggested, that is enough for me. I reached for GLib mainly because it's written in C and doesn't require pulling in the entire C++ shared object set. TBH I have (almost) no experience with glib, but the mere idea of trying to write OO in C scares me ;-). (Conversely I have pretty decent experience with Qt, and absolutely love it.) C++ was designed for OO; little things like ctors/dtors make life s much easier. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Björn Persson wrote: Matthew Woehlke wrote: Björn Persson wrote: Matthew Woehlke wrote: an iptables rule that allows stuff if there is a socket that will receive it, otherwise can drop Where's the point in that? Stealth? You might as well ask what is the point of using DROP (instead of REJECT) at all. Obviously there is a reason or else it wouldn't exist. That's obscurity, not security. Why is it people seem to have a problem with obscurity *on top of* security? What's wrong with making it as hard as possible for the bad guys? If there's a hole in Sendmail for example, then attackers trying to exploit that hole won't start by probing port 26384 and then connect to port 25 only if they get an RST packet from port 26384. ...and if I happen to not be running sendmail at the time, my machine will appear to not exist, rather than going on the 'try other exploits' list. (Especially if I happen to be not running /any/ services at the time and am therefore truly stealthy.) You're not truly stealth unless you drop *all* packets, at which point you can just as well unplug the network cable (or turn WiFi off with the kill switch). Not all packets, just incoming ones that don't belong to established connections. (I'll assume we're not talking about a black hat to whose server you have explicitly connected.) Besides, you didn't address the original question: if DROP is as non-useful as you claim, why does it exist? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Casey Dahlin wrote: On 07/24/2009 02:09 AM, Aioanei Rares wrote: I tend to agree here. Maybe C++ would be a far better option (biased, of course :) Ugh. I think C will do just fine. Its perfectly adequate without growing any tumorous appendages. C is just fine for device drivers, just don't make me write a GUI using only C ;-). (Tumorous appendage? I object to that...) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Bill McGonigle wrote: On 07/23/2009 06:17 PM, Matthew Woehlke wrote: I have to ask... when are we going to see Linux allow network access based on the checksum of the process that wants to use it? After all, 'doze has had this ability for years. (Maybe SELinux can provide this already?) Is this a checksum of the binary that got launched? Make sure prelink can update whatever database of checksums is being kept. And that prelink isn't exploitable. :) True. For us, something based on SELinux contexts, which should be dropped by the kernel on any modification (and allowed to be set by trusted components, say prelink and yum/rpm) is probably as good or better than using checksums. (Which still requires prelink to be secure, but then that's already required, as rogue prelink could be wreaking who-knows-what havoc...) This can't be a default on MSW, right? My spam filter's pain would seem to deny that possibility. It's not built into MSW if that's what you mean. It's from Tiny, which I used before switching totally to Fedora. By has this ability I mean that FW's for MSW exist which have this feature. (Also, Tiny is *not* a firewall for people that don't know what they are doing; using Tiny is, I would say, on par with 'vi /etc/sysconfig/iptables' in terms of user-friendliness. Powerful, really not bad when you know what you are doing, but absolutely not for 'Joe Sixpack'.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
'Content-Type: format=flowed' would be really nice, as opposed to the 'one line per paragraph' you sent... Casey Dahlin wrote: A couple of mentions of SELinux have cropped up in the FireKit thread, which got me thinking about the Firewall and SELinux and ways in which they are similar. I had the following thought: SELinux already has a lot of policy information from which we might like to determine whether ports should be open to a particular program. The simplest mechanism I can see for doing that is to allow SELinux context to be referenced in the firewall rules. This prevents either system from having to be grotesquely modified. An example rule might look like this: -A INPUT -Z apache_t -j ACCEPT Here we tell the firewall to allow incoming traffic that will be intercepted in userspace by a process in the apache_t context. My question is, can this even work? There is a reason I suggested that on the /INPUT/ side, iptables have no more smarts than 'is there a socket that will accept this packet'. (Then use SELinux to allow/prevent those sockets from being opened in the first place.) I like the idea for the OUTPUT chain, however. This does break in at least one way from traditional SELinux policy: something external to SELinux is interpreting the meaning of the context. The firewall rules can change while the actual SELinux policy stays put. I don't know how serious a problem that is (if it is one). I think this makes sense. You may want the rules for $DAEMON to change based on network connectivity, or even intangible parameters (e.g. I just called IT and they asked for ssh access, I want to enable it but only for the next five minutes). This seems easier to express in iptables than changing the SELinux context to cope with such events. Especially since the SELinux context in this case really becomes more of a tag than a rule set; the user determines the rules. That said, I'm not familiar with SECMARK, so it's hard to say if it can accomplish the same things. (It does, however, seem to be backwards w.r.t. how you want rules to be defined. Can I use SECMARK to e.g. allow Konqueror to browse YouTube, but block Firefox?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Björn Persson wrote: Your address will go on the try other exploits list anyway, *If* they scan a port that is not DROP'd. You're also assuming that the attacker doesn't already own any of the other machines in the local network, or café, or airport, or wherever you are at the moment. If he does, he'll be able to eavesdrop your established connections, and probably hijack them too. Even if those connections are encrypted and authenticated he'll still discover that your machine exists, despite all your stealthiness. I'll let you spot the gaping flaw in this argument. I'm sick of this conversation. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- unsubscribe me plz!! -- Newbies -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Michael Cronenworth wrote: Ahmed Kamal on 07/23/2009 04:54 PM wrote: Exactly the point, the user shares his desktop, or starts some service using the services GUI, and FireKit should offer to help. Moreover, this actually would improve desktop security, since without FireKit, a typical user after wasting half an hour, would understand it was the firewall blocking him, and would simply disable it for good. This happens on any OS. However, with FireKit, pro-actively offering to help the user, and requesting by default a limited time-window for opening the ports, actually ensures a better desktop security The user should simply be prompted: Do you want Vino Remote Desktop to be allowed network access? (Yes or No) I have to ask... when are we going to see Linux allow network access based on the checksum of the process that wants to use it? After all, 'doze has had this ability for years. (Maybe SELinux can provide this already?) Having said that, something like FireKit is obviously a step in the right direction. I presume in addition to time there will be options to open a port 'forever', 'until reboot', 'until the process using the port goes away'. Also, Do you want app to be allowed to accept connections from the network? :-) ...outbound access != inbound access. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- What is a release plan, anyway? -- Oswald Buddenhagen ...who I'm sure did not mean it seriously ;-) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
Jesse Keating wrote: List of deps left behind by orphan removal: Orphan: jline lucene requires jline = 0.9.94-0.3.fc11 ...which is required by OpenOffice.org. That's going to be a problem... except that F11 lucene doesn't need jline. Orphan: libatomic_ops pulseaudio requires libatomic_ops-devel = 1.2-6.fc12 Obviously, this is also a problem, except that again F11 has no such dependency. Are these really both different in rawhide? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- NT was a marketing name that stood for New Technology, but it was still an amusing coincidence that WNT was VMS with each letter replaced by the next one. -- Jeremy Reimer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Against what do I file this bug?
S.A. Hartsuiker wrote: Now for my problem. Although Anaconda installed grub in the bootsector of the fakeraid mirrored device, I never actually get to a grub prompt, it just loads the kernel. Um... do you mean that grub loads the latest kernel without pausing to ask if that's what you want? Because as I understand that is intended behavior with F11 (with F10 already, I want to say). Hold some key during boot to get the grub menu (ctrl works well, being unused by most BIOS's). Presumably due to the possibility that grub can't find the /boot partition. This makes no sense. If grub was failing to find /boot, you would get a grub error, since there would be nothing for it to boot (nor would it find grub.conf, I think). IOW, you would get slightly farther than the BIOS failing to find a MBR, but certainly no maintenance mode (which implies a roughly-functional kernel and initrd). However during the mounting stage of the boot process the /boot partition can also not be found and I am dropped into maintance mode. This sounds like an initrd problem to me, but I am no expert. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- insert bad pun... on second thought, better not -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Braden McDaniel wrote: Breaking compatibility with previous versions of automake, autoconf, or libtool has no impact on released tarballs made using those tools; they continue to work as intended because they do not depend on the presence of these tools. ...but they depend on a slew of *other* things, like a POSIX shell and many POSIX tools. And IIRC I've run into problems when those weren't the /GNU/ versions thereof. There's a lot to be said for /one/ tool that - while, granted, it needs to be installed - not only allows you to build, but also do full development without having to hunt down some precise version thereof, have several versions installed at once, etc. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
(Since I see some people here doing it... *cough*Please do not quote my e-mail address unobfuscated in message bodies.*cough* Thank you.) Simo Sorce wrote: People, why don't you all stop playing lawyer and wait that some lawyer actually comment on the promise? I guess some organization like the SFLC might be willing to comment if there is enough demand (and maybe they are already working on that). Um... really? You mean they haven't, already? GIYF: http://www.google.com/search?sourceid=mozclientie=utf-8oe=utf-8q=sflc+microsoft+patent+promise (Granted, much of that is about OOXML, but it seems to be referring to the same OSP, and even so, given the opinion on how poorly OOXML is covered, I doubt M$ would do anything to make the Mono/C#/CLI situation appreciably better.) Oh, and drago01: I doubt that any lawyer would interprets it the way [Riu does]. I don't about exact agreement with Riu's specific arguments, but they sure don't seem to share /your/ comfort level. Next time, either check that 5 seconds of googling doesn't make you look like you don't know what you are talking about, or else point out why said googling does not invalidate your point :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
drago01 wrote: On Wed, Jul 8, 2009 at 12:11 AM, Matthew Woehlke wrote: (Thank you.) http://www.google.com/search?sourceid=mozclientie=utf-8oe=utf-8q=sflc+microsoft+patent+promise (Granted, much of that is about OOXML, but it seems to be referring to the same OSP, and even so, given the opinion on how poorly OOXML is covered, I doubt M$ would do anything to make the Mono/C#/CLI situation appreciably better.) No its not the same Open Specification Promise != Community Promise ...but there are certainly people weighing in on both. Hmm, I thought I'd seen an actual statement from SFLC on the CP, but now I can't find it again. Still most of what I saw is others that feel the CP is no better than the OSP (some even said it is worse). Certainly some of the same points apply. Oh, and drago01: I doubt that any lawyer would interprets it the way [Riu does]. I don't about exact agreement with Riu's specific arguments, but they sure don't seem to share /your/ comfort level. I stated serval times that I am not a laywer and therefore can be wrong, than Riu stated that we don't need laywers because his point is obivious (to him). Fair enough. The point was just that your argument is better if 5 seconds of google doesn't appear to refute it. It was just a friendly suggest on 'how to make a better argument'. But unfortunatly the US laws suck, and that won't change anytime soon. Unfortunate, yes :-). When providing links make sure that they cover the same topic ;) Because than _you_ look that you have no idea what you are talking about. Touché. (Though my point was partly the obvious google results.) Still, you are right. How about these? http://opendotdotdot.blogspot.com/2009/07/are-microsofts-promises-for-ever.html http://mono-nono.com/2009/07/07/is-it-enough/ -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
Rui Miguel Silva Seabra wrote: In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the promise down the drain. ...if only. The odds of *any* company that might buy out M$ (well, if it isn't started by Gates and/or Ballmer and/or such) being as bad as M$ have got to be pretty high ;-). More likely, M$ sells the patents to a puppet company that has made no such promise. Said company happily starts bringing lawsuits. Hey, they've already got Myhrvold (Intellectual Ventures) to sell to, and OIN is useless against a tro^H NPE. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
drago01 wrote: So what about the patents owned by redhat? http://www.redhat.com/legal/patent_policy.html It's also just promise. True. However anything RH shipped as GPLv3 that uses a RH patent is no longer a mere promise, it's a legally binding patent license. Something that has yet to come out of M$. (The same can be argued for GPLv2, just that v3 has a better license in this regard.) ...and I suspect you'd have more luck getting an actual license from RH if you asked for one. In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the promise down the drain. Same applies to Redhat. The question to ask here is how this applies when an actual license has been granted, as in the case of distributing GPLv3 software. (Especially as I don't see irrevocable in Section 11... or, indeed, anything about the term of the GPLv3 implicit patent license. Hmm, this is actually a good question at first glance.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- You're on your own for the pony. -- Richard Hughes, on feature requests -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Ralf Corsepius wrote: Kevin Kofler wrote: Ralf Corsepius wrote: a) it will cause some moderate stir-up to those packages whose upstreams are still abusing the autotools. s/ab// ;-) Why can't we just move to a better build system with higher focus on backwards compatibility? Because a) the autotools are not as bad as you in your want to make them appear. Sorry, but any build system where you can't patch the build system without risking the sky falling *is* that bad. Why is it that to build a cmake-based project, it is a given that I run cmake, but to build an autotools-based project, I am expected to fear and dread and avoid-at-all-costs running autotools? Do you /really/, honestly not see anything wrong with that? As Conrad noted, [the] phobia of regenerating an auto-generated script just goes to show how completely broken autotools is. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- It is training and experience that gives us the ability to abstract problems, remain objective, use previous knowledge, interact with users, and herd cats. -- Celeste Lyn Paul, on Usability Experts -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
Adam Williamson wrote: On Thu, 2009-07-02 at 12:43 -0400, Bill Nottingham wrote: I'm not sure how distributable the KJV is or isnt' It's been out of copyright for some little time, now. Probably.(*) * Of course, one could potentially make some quite interesting legal arguments about the author credit, and whether said author counts as 'living' within the terms of copyright laws that grant copyright during the lifetime of the author... I think it's safe to assume that the Author grants permission to redistribute ;-). (In fact, I'm pretty sure I could make an argument that that's explicitly granted...) Permission to modify, on the other hand... (To be clear, I'm just trying to amuse folks, not argue that KJV should be included in Fedora. At the least, I /would/ argue that we'd have to allow other religious texts if we allow any, but I generally agree it's better not to start down that slope.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- It is training and experience that gives us the ability to abstract problems, remain objective, use previous knowledge, interact with users, and herd cats. -- Celeste Lyn Paul, on Usability Experts -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: evolution+openchange crash
Milan Crha wrote: On Thu, 2009-06-25 at 12:32 -0500, Matthew Woehlke wrote: If I file this, should it be against evolution-mapi, or libical? Hi, and thanks, it's already filled under this bug: http://bugzilla.gnome.org/show_bug.cgi?id=580706 Milan Meh, google must not index b.g.o :-(. Anyway, thanks, though I dispute that this is actually bug 580706. (I believe it is rather bug 581642, which was - IMO wrongly - marked a duplicate of 580706. I've said as much on the respective bugs.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- pinotree uses the large trout on tsdgeos and PutHuhn :) PutHuhn runs tsdgeos lights a fire and eats the trout (with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came up with this entirely on their own) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Kevin Kofler wrote: As Orcan's and John's reply show, I'm far from the only one who thinks the current naming of the GNOME-based spin is misleading and biased (which was another thing the opponents to my proposal claimed during the meeting). ...and they're just the ones annoyed enough to speak up. Well, count me now in that number also. I too would like to see KDE treated as a first-class citizen, rather than blindly pushing Gnome to the ignorant masses. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- pinotree uses the large trout on tsdgeos and PutHuhn :) PutHuhn runs tsdgeos lights a fire and eats the trout (with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came up with this entirely on their own) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Please do not quote my e-mail address unobfuscated in message bodies. Adam Miller wrote: On Fri, Jun 26, 2009 at 5:27 PM, Matthew Woehlke wrote: I too would like to see KDE treated as a first-class citizen, rather than blindly pushing Gnome to the ignorant masses. The problem with this is that you are now pushing two things blindly at ignorant masses, so not only do they have no clue what their doing because its a different operating system from what they are (generally) used to but there are two default interfaces to it. How does this make sense? ...more so than the choice they already face between Fedora, Ubuntu, Mandrake, Mint, insert favorite distro? (Yes, I know, bring on the old 'straw, camel' story...) Also, I want to pick at your use of blindly; who says it has to be blind? Why not work to educate users about the difference? A Take a Tour would probably be good publicity anyway. (You know, take the edge off that no clue what they're doing thing...) -- Matthew pinotree uses the large trout on tsdgeos and PutHuhn :) PutHuhn runs tsdgeos lights a fire and eats the trout (with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came up with this entirely on their own) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Seth Vidal wrote: On Fri, 26 Jun 2009, Orcan Ogetbil wrote: - A topic was brought up to FESCo. It was concerning an unease of an important fraction of our members. and I disagree with that fraction. - You may not find it an important issue personally. But that doesn't change the fact that there is an issue. Actually, I disagree that it is an issue that was cause for [much] concern. Great. Thank you for marginalizing us. Maybe it's time to reconsider Mandriva... -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- pinotree uses the large trout on tsdgeos and PutHuhn :) PutHuhn runs tsdgeos lights a fire and eats the trout (with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came up with this entirely on their own) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
Matthew Garrett wrote: Gnome in Fedora simply gets more development effort, has more documentation based around it and therefore deserves to be the default. Pretending that KDE has the same level of support does nothing to benefit KDE. There is a self-fulfilling prophecy in there. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- pinotree uses the large trout on tsdgeos and PutHuhn :) PutHuhn runs tsdgeos lights a fire and eats the trout (with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came up with this entirely on their own) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
Adam Williamson wrote: On Wed, 2009-06-24 at 11:05 +0100, Peter Robinson wrote: The problem with preupgrade is that it needs user interaction and a lot of space. It downloads the distro update locally, reboots the machine and then runs anaconda. Well, as yum doesn't group transactions, yum upgrades also require a lot of space (enough to store the entire set of upgrade packages, as they're _all_ downloaded prior to the operation). ...if you just run 'yum upgrade' and not 'yum upgrade list'. I don't know that I've /ever/ done all-at-once, if only because of more risk of the transaction taking so long that something bad happens (e.g. power failure). F10 - F11 was just especially bad due to all of KDE needing to be upgraded in order to upgrade yum (due to openssl deps). The trick, as I've discovered, is not to reboot in between chunks ;-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Who wants to sing? -- Orcs (Warcraft II) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
Björn Persson wrote: What does supported mean in this context anyway? Isn't Fedora community-supported? So if someone from the community helps you when you have problems with a Yum upgrade, then Yum upgrades are supported, right? Something like officially sanctioned. If anaconda upgrade doesn't work, the official response is to treat it as a bug. If yum upgrade doesn't work, the official response is too bad. Note official... as in, the /unofficial/ response may be different. If I upgrade from the DVD, or by Preupgrade, and it breaks, who should I send the pieces to? bugzilla.redhat.com? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Do you know where your towel is? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
Adam Jackson wrote: On Wed, 2009-06-17 at 10:06 -0400, Chuck Anderson wrote: On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Thought: Define system library directories to a sane default set. Start with this. For each package, when doing autoprovides calculation, recurse down the tree of rpms needed by this package. For any that change /etc/ld.so.conf.d, add the appropriate directory to the set of system library directories. Now see if the rpm installs any libraries into those locations. If so, those are autoprovides. Sound sane? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- XFS is not something I look into the innards of, as I don't have enough chickens to sacrifice. -- Alan Cox -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: system-config-firewall picking up slack where firestarter fell off
Adam Miller wrote: 1) Cisco VPN I don't use this myself but I was told it just needs these rules, so I don't see a big issue here: $IPT -A FORWARD -i $IF -o $INIF -p udp --dport 500 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $IF -o $INIF -p tcp --dport 500 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $IF -o $INIF -p 50 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -i $INIF -o $IF -p 50 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Hmm... $DAYJOB uses Cisco VPN, and the only rule I seem to have for it is: -A INPUT -i cipsec0 -m state --state RELATED,ESTABLISHED -j ACCEPT (...and similar in FORWARD, as this box is a gateway router) Either vpnc auto-manages the needed rules, or open port 500 isn't universally required. 2) Auto setup of Internet Sharing, so autoconfig of dhcpd and providing a bridge between WAN and LAN. This is one that I'm not entirely sure there is really in the scope of system-config-firewall and might need to be its own utility. Maybe. As above, I've done it by hand and it's not trivial (not hard, but requires more than one thing set up). You can pick defaults for many things, but to set up forwarding you need: - forwarding on in kernel (/etc/sysctl.conf) - iptables rules - configure dnsmasq (else fiddling with updating dns servers via dhcp is a pain) - configure dhcpd (or use dnsmasq) - somehow ask user or guess what is external, internal interfaces (Don't forget to bind dnsmasqd/dhcpd to the lan interface, please!) And it should ideally let you configure (in advanced mode): - specify net/subnet and ranges for dhcp - static hosts for dhcp - forwarded ports other machines in the LAN FWIW, 'doze apparently has point-and-click internet connection sharing, so this would be a good thing to address. Say, how come s-c-f isn't merged into NM yet? ;-) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- The spiraling shape will make you go insane! -- They Might Be Giants -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Peter Robinson wrote: [...] why maintain x86 at all? Because it's 58% of our userbase (source: F11 torrent stats.) How much of that 58% is actually 64 bit machines running the 32 bit OS? I'm going to guess, a lot of it? 60% of my installations are x86 (75% if you count only hardware, and 25% of my hardware is i686-without-sse2). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Websites such as ... Wikipedia ... are reputed to occupy users for periods in excess of 5 hours. -- Wikipedia article on Internet Addiction -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
Casey Dahlin wrote: Really, init scripts should open the firewall ports they need when their service comes up (and I'll propose something for upstart 1.0 later today to make that make more sense.) How is that supposed to work when I only want to allow connections to a service on a whitelist of IP addresses? Right now I do this with static iptables rules that I have set up (which, since I am never /not/ running the daemon in question, doesn't have any drawbacks I can think of off the top of my head). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- End of Transmission -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
Matthew Woehlke wrote: Configuration is fine, just as long as there /is/ configuration and not running a service always exposes it to the world with no way to prevent that. (Prevention by editing init-scripts doesn't count ;-).) That's terrible. Unfortunately, I noticed after hitting 'send' :-(. I meant (adding quotes, to properly group ideas): Configuration is fine, just as long as there /is/ configuration and not running a service always exposes it to the world with no way to prevent that. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- End of Transmission -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
Jon Ciesla wrote: Also, I was wondering, myself aside, are the newer processors as prevalent all geographic locations? Forget geographic locations, I would be more worried about economic status. I worry that we're shutting out not only poorer /countries/, but poorer /people/ everywhere, e.g. initiatives like the Helios Project. (I don't think Ken uses Fedora anyway, but I really don't want to make it /impossible/ for him, others involved in similar projects, or the beneficiaries of such projects, to use Fedora.) ...besides all the people (like me) that simply don't want to spend the $$ to replace hardware that is working fine today :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- End of Transmission -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
Matt Domsch wrote: On Mon, Jun 01, 2009 at 04:03:04PM -0400, Paul W. Frields wrote: I'm getting out of my ken here, but could this be done in stages with I2 connected hosts getting the bits early/first and then moving on to others? We need to move ~130GB to each of ~230 mirrors, in about 4 days. We already have in place a limited amount of tiering. The Tier 0/1 mirrors get the bits first, then downstream mirrors pull from them. We have nearly all our Tier 1 mirrors on I2 (all but the us.kernel.org). Right now it's not mandatory, but no new mirrors (those signed up in the last 18 months or so) have been granted ACL permissions to download from the masters. http://fedoraproject.org/wiki/Infrastructure/Mirroring/Tiering One of my hopes for the F12 cycle is that we will have increased use of tiering and push mirroring. What about dropping hierarchical mirroring altogether? Why hasn't someone developed a distributed (i.e. bittorrent-like) system for mass mirroring? :-) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Congratulations! You've won a free trip to the future! All you have to do to claim your prize is wait five minutes... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
José Matos wrote: On Wednesday 27 May 2009 17:23:33 Adam Williamson wrote: Well, yeah, I actually noted in my email that MDV's tool does exactly that (well, it doesn't show them as separate sets, it shows them in one long list with (suggests) to note the suggested ones. But doing it in sets would, I imagine, be trivial). ...and consistent with how yum currently works. Wishful thinking. :-) Why? It is easy to come with an example where those sets overlap, i.e. there is one package that only shows as (suggests) in more than one package. Sure. Why does that matter? So I am not sure if it is worth the trouble to show all the separate sets. How else are you going to display things? Specifically how are you going to display things that isn't /broken/? We have two groups right now, 'updating' and 'installing for dependencies'. Putting packages pulled in (only; directly or indirectly) by suggests: into either of those is clearly wrong. I don't see why this is hard. I do 'yum update'. It wants (with suggests: feature) to install packages for any combination of three reasons: - package is installed and is being updated - package is required by some package in transaction - package is suggested by some package in transaction (Without suggests: feature you only have first two.) Any package may belong to all three states, true. However it is placed in the group with the strongest reason for it being in the transaction. (The above are listed from strongest to weakest.) If it's installed already, set required flag and update flag. If it was required by something, set required flag iff what required it has required flag. Packages with update go in 'updating' group, with required but not update in 'installing for dependencies', everything else in 'installing for suggestions'. How hard is that, really? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Sorry, but I can't look into that right now. I'm running low on sacrificial chickens. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
