Re: Help wanted with dist-cvs to git conversion
Christopher Brown wrote: > This is a non-issue. It may be a non-issue to you but not to Seth Vidal obviously. > Both my fpo and non-fpo are published regularly > in commits and whatnot and I receive about 1 spam per week. But then I > have gmail. :) Well I have received zero spams since April when I flipped the switch to enforcing mode (except when the spam blocker crashed; there seems to be a race condition that I haven't tracked down yet.) Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
Debarshi Ray wrote: > Now what? What happens now? Not much I guess, as the list archive obfuscates email addresses, but if you managed to reach a spammer with that message, what happens is that my mailbox is still spam-free but a number of innocent third parties may be getting an increased amount of junk in their mailboxes. Does that give you a feeling of accomplishment? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
Seth Vidal wrote: > And let me put it this way: if fedora decides to post my non @fp.o address > somewhere, like in git entries, I'm going to be extremely pissed off about > it. As for me, I don't mind publishing my real email address but I would prefer not to have my fedoraproject.org alias published where the spammers can find it. I don't particularly like having forwarding aliases created for me, but if you have to give me one then please don't publish it. I have a spam blocker that makes my address pretty much unspammable. It's unspammable even if the spam comes through a forwarding alias, but in that case backscatter may be generated. The spam blocker is implemented such that my own server never sends out backscatter, but I naturally have no control over the fedoraproject.org server or other forwarding servers. Therefore I try to avoid using forwarding aliases in ways that might allow spammers to find them, not because it affects me but to be nice to other netizens who don't have as effectual spam blockers as I have. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are conflicts in debuginfo packages OK?
Jan Kratochvil wrote:
> On Tue, 10 Nov 2009 22:15:47 +0100, Björn Persson wrote:
> > Generated files can be placed in separate subdirectories, for example
> > /usr/src/debug//%{_arch}.
>
> My patch uses there:
> /usr/src/debug/name-version-release.arch
Duplicating the entire source tree seems a bit wasteful when it's only
generated files that sometimes need to be separated, but I suppose that's the
only way if you want to do it without patching makefiles in numerous packages.
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are conflicts in debuginfo packages OK?
Bill Nottingham wrote:
> Frank Ch. Eigler (f...@redhat.com) said:
> > > I'm guessing that "we don't offer them multilib" means that 32-bit
> > > debuginfo packages aren't meant to be installed on 64-bit systems,
> > > so I'll take this to mean that I shouldn't bother doing anything to
> > > avoid conflicts.
> >
> > Well, hold on, debuginfo for multilib'd libraries like glibc should be
> > absolutely installable in parallel.
>
> Not unless someone changes the layout of debuginfo entirely, as they
> use common paths:
>
> /usr/src/debug/
I think can handle those. For true source code files there is no problem,
because they will be identical in both packages. Generated files can be placed
in separate subdirectories, for example
/usr/src/debug//%{_arch}.
This may of course require more or less complicated patches to makefiles or
other build scripts. I'm trying to find out wheter I should do this.
> /usr/lib/debug/usr/bin/...
Those are the ones I can't do anything about on my own, but perhaps the same
exception could be applied there as in /usr/bin?
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are conflicts in debuginfo packages OK?
Jesse Keating wrote: > On Tue, 2009-11-10 at 00:01 +0100, Björn Persson wrote: > > I don't see that I as a packager can do anything to prevent these > > conflicts. Shall I conclude that I don't need to care about conflicts > > between architecture versions of debuginfo packages? Or shall I try to > > avoid conflicts in debuginfo packages for libraries, but not for > > programs? I think I can avoid debuginfo conflicts in packages that > > provide only libraries, but maybe I shouldn't bother? > > debuginfo packages cannot be multilib, that is why we don't offer them > multilib. I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F13 Naming: Leonidas -> Constantine -> ?
inode0 wrote: > With Fedora 12 just a few days from release it is time to begin the > naming process for the next Fedora release. After F12 comes Print Screen of course. ;-) Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Are conflicts in debuginfo packages OK?
Hello, could someone help me understand the rules about file conflicts and debuginfo packages? I thought there was a rule that if the 32-bit and 64-bit versions of a package provide the same file, then the file's contents must be identical in both packages, with an exception for binary executable files in standard locations like /usr/bin. Now I've noticed that lots of debuginfo packages seem to be violating this rule. The debuginfo packages put files in /usr/lib/debug/usr/bin and similar directories, and the exception doesn't seem to apply to these directories, because RPM complains about conflicts when I try to install both architecture versions of a debuginfo package. I don't see that I as a packager can do anything to prevent these conflicts. Shall I conclude that I don't need to care about conflicts between architecture versions of debuginfo packages? Or shall I try to avoid conflicts in debuginfo packages for libraries, but not for programs? I think I can avoid debuginfo conflicts in packages that provide only libraries, but maybe I shouldn't bother? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20091104 changes - excluding noarch packages
Jesse Keating wrote: > On Wed, 2009-11-04 at 17:20 +, Paul Howarth wrote: > > So a noarch script package that depends on its arch script interpreter > > (e.g. all python and perl packages) should be arch packages? > > And bash for that matter. Unless the interpreter is available on all of the architectures that Fedora supports, which Python, Perl and Bash are as far as I can see. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > Don't security risks grow exponentially as software 'bit rots'? If someone finds and publishes a security hole, and no one tries to fix it, then the risk increases dramatically. If no holes are published and the software doesn't change, then I'd say the risk is fairly constant. There is always the possibility that some bad guy finds a hole that the good guys haven't found and fixed yet. The bad guy can then use the hole in a few directed attacks against selected targets. (In the case of id3lib he could for example send a malformed MP3 file to the victim by email.) In that case you're at risk only if you are the bad guy's target. He can also use the hole in a large-scale attack against the entire userbase (for example publish a malformed MP3 file on some popular file sharing networks), but only once, because then the hole will become publicly known and presumably fixed, and after that the risk is the same as for any other published hole. All of this is true both for stable software and for software in active development, and although the developers in an active project may occasionally find a hole and fix it, they may also introduce a new hole at any time. I'm much more nervous over programs like Squirrelmail, Firefox and Thunderbird, for which there is a steady stream of security fixes, because it indicates that the code is of low quality or that the design is fundamentally flawed. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
Peter Robinson wrote: > In fact the proper way to do this it to have the same hardware in the > group of servers that VMs might be live migrated between so that its > not an issue. Then the only time this would then come into play is > when you are upgrading the group/cluster of machines to newer hardware > and that shouldn't be an issue as the newer hardware should have more > features in the CPU and not less. Unless you upgrade from old PowerPC Macs to new Intel Macs. :-) Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
Lyos Gemini Norezel wrote: > Is there valid, logical, reasoning to continue to support such old code? Are there any bugs that are so severe that we can't continue using the software? If not: Why throw out working software just because it's old? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dracut, or should booting a LiveCD touch the hard disk?
Chuck Anderson wrote: > Should the LiveCD by default access and > activate storage volumes, including encrypted partitions, on the hard > disks? There should be an easy and intuitive way to access the hard disks from the live system. Whether unencrypted volumes are mounted at boot or on demand doesn't matter much to me, as long as nothing is modified except on the user's request. Encrypted volumes should be unlocked only on demand. Failing that, a choice should be offered at boot. > Should the LUKS prompts better identify the volume so that > users know what passphrase to enter? Absolutely! Asking for a passphrase and not specifying which passphrase is a very bad idea. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package Review Stats for last 12 days
This looks like a nice initiative. I hope it will lead to more reviews getting done and reduce the waiting time. Rakesh Pandit wrote: > Below is the > number of package reviews completed. [55 bugzilla links] > Total reviews modified: 55 I think the wording needs to be improved here. Is it completed reviews or modified reviews? > Review Requests: 53 If that's 53 out of the 55, it makes me wonder what the last two were. If it means 53 *new* review requests submitted, that could be made clearer. If it's not 53 new review requests, would it be possible to include that number too, so we can see whether the backlog is growing or shrinking? Björn Persson -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bugzilla Desktop Client
Yaakov Nemoy wrote: > You can always revoke a pub uuid in the future. Perhaps a message > about that will encourage people to be more forthcoming with Smolt > profiles within such a tool. Obviously, including a smolt profile just > automates certain kinds of information (read: privacy) disclosures, > which is sometimes necessary in a bug report anyways. Unless that > information as cached elsewhere, revoking a public UUID essentially > makes people forget the details though. Once published, always public. You can of course hope that nobody saved a copy of your details before you retracted them, but you can never be sure. The only safe assumption is that any information you publish remains public forever. That said, I'm personally not very concerned about letting people know what hardware I have; my secrets are of other kinds. (But of course I wouldn't want anything to be published without my permission.) Björn Persson signature.asc Description: This is a digitally signed message part. -- 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?
Colin Walters wrote: > On Tue, Sep 1, 2009 at 5:07 PM, Matthew > > Woehlke wrote: > > No, the easiest method is: > > > > "The following updates require their respective services to be restarted > > for the updates to take effect. Proceed? [Yes] [No]" > > I don't think it makes sense to treat everything that presently has an > /etc/init.d script equally. For example, if cupsd has no queue, it's > probably safe for it to just restart itself at some period of time. > Probably the easiest way to implement this would be a flag in the init > script which says whether it's safe to "service restart" on updates. I thought a condrestart in %post was the way to do this for those services that can be restarted safely. > For other things, an important question is whether the currently > running desktop depends on it. If it does, it's not safe to have such > a UI. For those services I think a message should be displayed to inform the user that some of the updates will take effect the next time they log out. If it's a security update, the message should urge the user to log out and log in again as soon as possible. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Page size pain / localisation / possible F13 feature
Caolán McNamara wrote: > Well, FWIW there is the (rather weird) en_DK locale, which has > -MM-YY dates (I think its the only locale where this is the default) Assuming you meant -MM-DD, sv_SE has that: [be...@hactar beorn]$ locale LANG=sv_SE.utf8 LC_CTYPE="sv_SE.utf8" LC_NUMERIC="sv_SE.utf8" LC_TIME="sv_SE.utf8" LC_COLLATE="sv_SE.utf8" LC_MONETARY="sv_SE.utf8" LC_MESSAGES="sv_SE.utf8" LC_PAPER="sv_SE.utf8" LC_NAME="sv_SE.utf8" LC_ADDRESS="sv_SE.utf8" LC_TELEPHONE="sv_SE.utf8" LC_MEASUREMENT="sv_SE.utf8" LC_IDENTIFICATION="sv_SE.utf8" LC_ALL= [be...@hactar beorn]$ date +%x 2009-08-28 I don't think I have customized that because I have no idea how to do it. (If I knew how, I'd fix the time format to get a colon in the clock in the Gnome panel.) Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Page size pain / localisation / possible F13 feature
Kevin Kofler wrote: > Maybe we just need an en_INTL locale which defaults to US English > translations, but ISO standards everywhere else (ISO -mm-dd dates, ISO > A4 paper, metric units etc.)? (Currency would be a problem though, default > to €? $? The generic currency sign ¤ almost nobody actually uses? Or > something silly like "%f bucks"? ;-) ) Such a locale might even become the > default (though it'd irritate US folks ;-) ). I think it'd cover the needs > of most of the non-US users of en_US, and details could still be overidden > where needed. :-) I don't think that will happen but it's fun to think of. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Jeff Spaleta wrote: > Are you suggesting that things are out of balance now? > [...] > Are you seriously suggesting expending the manpower at the > distribution level to poke at which functional calls need to broken > out into more libraries? All I have suggested is that we should have a certain tool. Rahul Sundaram described a way to check for unnecessary dependencies. I found that method somewhat unwieldy and suggested that there should be a tool to make such a check easier to do for those who want to do it. That's all. I don't understand why you react as if I had claimed that Fedora's packaging is horribly broken. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Rajeesh K Nambiar wrote:
> 2009/8/24 Björn Persson :
> > That's not all that quick. There ought to be a tool for this. Given a
> > package name it should print the dependency tree for that package. It
> > could have an option to suppress packages in the base set. Couldn't Yum
> > be taught to answer that kind of queries?
>
> I'm not sure this is exactly what you want, but I was using this in my
> .bashrc:
>
> function dependencylist
> {
> yum groupinfo Base | grep -v Packages | sed 1,12d | awk '{print
> $1}' > BaseList; yum deplist "$*" | grep provider | awk '{if("grep -q
> $2 BaseList") print $2}' | sort | uniq
> }
If I understand that function right, it lists only the direct dependencies of
a given package, not the dependencies of the dependencies, so it won't help
with discovering situations like the one that prompted this discussion.
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
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: > It's not like those dependencies bite. ;-) HDD space is cheap. 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. It would be nice if things could be set up such that kdebase-workspace-akonadi gets installed by default if both kdebase-workspace and akonadi are installed, but not if only one of them is installed. If RPM had a "Suggests" tag it would at least be possible to inform users that there is a related package available that they can install if they want to. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Jeff Spaleta wrote: > 2009/8/24 Björn Persson : > > One likely cause is that package C, somewhere in the dependency chain > > between A and E, contains too many different functions. In that case C > > should probably be split into subpackages C1 and C2, where C1 depends on > > A but E depends on C2. Then E would no longer depend on A. > > I hope you understand that chasing down every single instance of this > situation ultimately leads to a situation that is more easily > duplicated by making the build process automatically split every > library binary into its own subpackage. If we aren't willing to do > that automatically, then why is it worth the time to have multiple > individuals systematically chase them down? I'm wary that the sort of > checking you want to do is a rabbit hole that will require significant > continued human effort as codebases shift. On the other hand, not addressing such situations at all ultimately leads to a huge tangle where every single package depends on pretty much all of Fedora Everything. It's a matter of finding a good balance. Splitting every library binary into its own subpackage might not always resolve the situation by the way. I have seen libraries that lump together all sorts of unrelated functions in a single .so file. There are also libraries written in interpreted languages that aren't compiled into binaries, and in some cases the dependencies might not even be libraries at all. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
James Antill wrote: > There is already: > > http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py > > ...obviously any random custom behaviour (like ignoring packages in > @base) is possible, someone just has to write it. Well, that looks like a good start, but it definitely needs some way to avoid listing glibc, like, seven hundred times over. It would also be nice if I could use it on a newly built package that isn't available in the Yum repositories. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Seth Vidal wrote: > On Sun, 23 Aug 2009, Björn Persson wrote: > > I want to check whether a package drags in other packages > > unnecessarily. > > define "unnecessarily"? When you're forced to install package A to be able to install package E even though E doesn't use any of the functionality that A provides. For example, Michael Schwendt demonstrated that ktorrent pulls in qt-mysql, which in turn depends on mysql-libs. That's OK if Ktorrent can actually do something that results in queries to a MySQL database. Otherwise it drags in the MySQL client libraries unnecessarily – that is, I should be allowed to install Ktorrent without installing the MySQL client libraries. One likely cause is that package C, somewhere in the dependency chain between A and E, contains too many different functions. In that case C should probably be split into subpackages C1 and C2, where C1 depends on A but E depends on C2. Then E would no longer depend on A. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Debayan Banerjee wrote: > 2009/8/24 Björn Persson > > That's not all that quick. There ought to be a tool for this. Given a > > package > > name it should print the dependency tree for that package. It could have > > an option to suppress packages in the base set. Couldn't Yum be taught to > > answer > > that kind of queries? > > edos-rpmcheck > > http://www.edos-project.org/xwiki/bin/view/Main/debcheck_home Judging from the description on that page, that's not what I want. It says the program checks whether a package is installable. Yum can do that. I want to check whether a package drags in other packages unnecessarily. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
showing dependency trees
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. That's not all that quick. There ought to be a tool for this. Given a package name it should print the dependency tree for that package. It could have an option to suppress packages in the base set. Couldn't Yum be taught to answer that kind of queries? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
Ralf Corsepius wrote: > On 07/26/2009 02:37 PM, Seth Vidal wrote: > > On Sat, 25 Jul 2009, Alan Cox wrote: > >> "all of my system has a wrong openssl version" > >> > >> all these symptoms sound like your upgrade went horribly wrong. I've > >> seen preupgrade mash up a box by half upgrading like that. It's the main > >> reason > >> I don't think preupgrade is actually safe to use yet. > > > > Preupgrade's process is to depsolve - using the same method anaconda > > does, download the pkgs it solves out. Put them in a cachedir. Download > > a kernel and an initrd, Setup a ks.cfg. then reboot the machine and > > allow anaconda to do the install. > > > > Specific issues we've had with preupgrade are related to not being able > > to find a mirror and/or not being able to get pkgs. > > Mine were > * preupgrade running out of diskspace on / when trying to fill > /var/cache/yum (my "/"'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? > * anaconda failing during reboots due not being able to process fstab > correctly (FC11's anaconda misparses fstab and is unable able to process > bind-mounts nor nfs-mounts). > > * anaconda's depsolving failed when upgrading an FC10 + FC10-updates > system due to NEVR issues. Those would be Anaconda issues, not Preupgrade issues – which makes them all the more serious. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
oleksandr korneta wrote: > on 07/25/2009 11:46 AM Chuck Anderson wrote: > > I don't even upgrade anymore. I just keep two partitions (Logical > > Volumes actually)--one for Fedora N and one for Fedora N+1. > > interesting idea. Do you keep the same home for both? I have two root partitions and two /boot partitions so that I can keep Fedora n as a fallback until I see that Fedora n+1 (or sometimes n+2) is working acceptably. I have a separate /home partition so I can keep it when I reinstall or upgrade, but I've found that logging in to Fedora n after having run Fedora n+1 with the same /home can be dangerous. I completely trashed my Kmail configuration that way. Since then I'm more careful and test Fedora n+1 before I move the /home partition over. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
Farkas Levente wrote: > it was a mistake to mention preupgrade. i use dvd to upgrade my system > only after the dvd installer crash i try preupgrade which also crash. As it's Anaconda that does the work with both Preupgrade and the DVD, it's not surprising that it crashed the same way both times. The only way to avoid Anaconda is to upgrade by Yum. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
Fortunately I had read in this list that upgrading breaks Yum so I did a fresh install instead, and only had to spend a few days getting all the configuration back into shape. Sound started working after I deleted ~/.pulse. The primary reason why Fedora 11 is the worst ever for me is a badly broken compiler. (https://bugzilla.redhat.com/show_bug.cgi?id=507247) Luckily I've finally found the error, so I can at least build fixed compiler packages for myself until Fedora 12 is released with GCC 4.4.1 where the bug is fixed. Or maybe some GCC maintainer will even find it worth their time to apply my patch. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Matthew Woehlke wrote: > Björn Persson wrote: > > 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"? It could be because you're not actually making it any harder for the bad guys, only for yourself and for me. > > 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.) Your address will go on the "try other exploits" list anyway, because the bad guys know that many people think they're more secure if they're "stealthy". They won't conclude that your machine doesn't exist. They'll only conclude (correctly) that there's no public SMTP service at that address. > > 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.) 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. > Besides, you didn't address the original question: if DROP is as > non-useful as you claim, why does it exist? I did address that question. DROP exists so I can DROP disallowed broadcast and multicast packets and REJECT only unicast packets. If I'd REJECT broadcast packets I'd violate some RFCs and become a traffic multiplier for DDOS attacks. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
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. 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. They'll go straight on port 25. 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). My personal packet filter drops disallowed packets if either address is a multicast or broadcast address. If both addresses are unicast addresses it rejects the packet with the "administratively prohibited" code. This makes troubleshooting a whole lot easier than if the packets just disappear. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Colin Walters wrote: > Ok, how about this - gnome-user-share and vino are by default tied to > networks, rather than global. So instead of one global GConf key, > they have per-network state stored either in /system/networking or > based of some key in their own config. When the network changes, they > adjust. If each service would have its own independent per-network state, then yes, that's better. Not as a replacement for strong authentication and access control, but as a complement. > If we do ship a firewall on by default, then yes we would need a way > for these desktop apps to poke holes programatically. Personally I would prefer not shipping insecure services by default, so that no "firewall" is needed. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Colin Walters wrote: > 2009/7/24 Björn Persson : > > Colin Walters wrote: > >> If for > >> example I enable desktop sharing before leaving work, then head to the > >> airport, and log on there to WiFi, you really don't want the desktop > >> sharing still enabled. Nor likely do you want sshd. > > > > – Internal tech support, Randy Hacker speaking. > > – Hi Randy, Joe Salesman here. I'm at the airport. Something's wrong > > with my laptop. The screen just goes black when I try to start Open > > Office Impress. It worked fine yesterday. If I can't get it to work > > before I get to the customer's site I won't be able to show the > > presentation. > > – OK Joe, I'll SSH into your laptop and look at the logs. What's your > > current IP address? > > In this case, when the firewall is re-enabled, it would be enabled to > whatever the system administrator has configured it to do. In other > words if they added an explicit passthrough for port 22, that would > continue to work. Fair enough. Just don't assume that nobody would want SSH at an airport. > > Joe might have file sharing enabled to share his documents with his > > colleagues in his own company, but just because Joe wants to let people > > see the presentation, that doesn't mean he wants anyone who might be > > connected to the customer's network to read all his documents. > > Hmm? How would they be able to read all his documents? Isn't that one thing that the so called firewall is supposed to prevent? Surely Vino isn't the only thing you want to block when the network is considered untrusted? > > In one known attack against the concept of trusted networks, an attacker > > configures his laptop to present itself as a WiFi access point and > > broadcast a large number of strategically chosen SSIDs. Then he sits down > > in a public place and waits for unsuspecting laptops to recognize the > > SSID of their home network and connect automatically. > > I believe NetworkManager's connection list is based on the pair of MAC > address + SSID, not just SSID. So in a large building with many access points you have to add each access point to the connection list individually? The attack I read about was of course primarily targeted at Windows. Perhaps Windows looks only at the SSID. Still, I wonder how long it would take to loop through the MAC address ranges of all the big manufacturers of access points. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
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? To protect against possible security bugs in the little piece of TCP code that would otherwise reply with RST, or the little piece of UDP code that would just drop the packet anyway? I doubt a security bug in the little piece of IPtables code that drops packets is any less likely. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
Colin Walters wrote: > If for > example I enable desktop sharing before leaving work, then head to the > airport, and log on there to WiFi, you really don't want the desktop > sharing still enabled. Nor likely do you want sshd. – Internal tech support, Randy Hacker speaking. – Hi Randy, Joe Salesman here. I'm at the airport. Something's wrong with my laptop. The screen just goes black when I try to start Open Office Impress. It worked fine yesterday. If I can't get it to work before I get to the customer's site I won't be able to show the presentation. – OK Joe, I'll SSH into your laptop and look at the logs. What's your current IP address? > Which leads me to think that rather than being based on individual > ports and time, we just need a nice way to globally toggle the > firewall. And that could come down to marking networks as explicitly > trusted in NetworkManager, say. That sounds like a really bad idea, because: > 1) Joe is a salesperson who is visiting another company and connected > to their public WiFi. He wants to enable desktop sharing so people > not in the conference room can easily see his presentation. He goes > into vino and selects sharing. Vino sends a dbus message to > NetworkManager which says it's requesting a service. NetworkManager > knows this network isn't yet trusted, and sends a message to nm-applet > asking whether to make the network trusted or not. If the network > transitions from untrusted to trusted, the firewall is disabled for > the time he is connected to that network. This is a transient state - > if Joe suspends his computer, shuts down, or connects to another > network, the firewall goes back up. Joe might have file sharing enabled to share his documents with his colleagues in his own company, but just because Joe wants to let people see the presentation, that doesn't mean he wants anyone who might be connected to the customer's network to read all his documents. Should he evaluate the trustworthiness of all the customer's employees as well as the security of their network before he starts Vino? In one known attack against the concept of trusted networks, an attacker configures his laptop to present itself as a WiFi access point and broadcast a large number of strategically chosen SSIDs. Then he sits down in a public place and waits for unsuspecting laptops to recognize the SSID of their home network and connect automatically. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
weird debuginfo problem
I seem to have finally discovered the cause of a problem I've had with debuginfo packages. Apparently the component that extracts debuginfo doesn't like symlinks. /home on this system is a symlink to /disk/data/home, and %_topdir was "/home/beorn/rpm". This caused debuginfo packages without sources, where the .debug files referenced the sources in the build directory. After I changed %_topdir to "/disk/data/home/beorn/rpm" the debuginfo packages seem correct. Is this expected behaviour or should I file a bug report against RPM? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Is BuildRoot still mandatory?
I understand that RPMbuild in the current versions of Fedora uses a buildroot under %_topdir/BUILDROOT, regardless of any BuildRoot tag in the spec file, so it appears that the only reason to have a BuildRoot tag in a Fedora package is if it will also be built for EPEL. The packages I've made would at least need several workarounds to build on EPEL 4 or 5, and they might not even work at all. I don't feel ready to get into EPEL yet anyway, so I decided that I may try to build my packages for EPEL 6 when that time comes, but not before that. Therefore I found BuildRoot tags to be unnecessary and left them out, but RPMlint complains and so do the commenters. So my question is: If there are no plans to build a package on any distribution release where a BuildRoot tag is needed, and it is known that the package won't build cleanly on such a release, is a BuildRoot tag still required for the package to be approved for Fedora? For reference, these are my review requests: https://bugzilla.redhat.com/show_bug.cgi?id=509158 https://bugzilla.redhat.com/show_bug.cgi?id=509159 https://bugzilla.redhat.com/show_bug.cgi?id=509160 Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Better ways to format USB disks (file fomats etc)
Andreas Tunek wrote: > I would > like to have the extremely high usability/minimal security of fat32 > (anyone who mounts the disk can read and write everything on the disk) > and it seems that this is not possible using ext3/ext4. Try this command: setfacl --modify other::rwX --modify default:other::rwX It will give everybody read and write permissions on the specified directory and all new files and directories created in it. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090627 changes
Orcan Ogetbil wrote: > Honestly, I couldn't think of a scenario where this package name will > break some system. If the only concern were to avoid name collisions that would break things, then packages wouldn't have names at all. It would be easier and more efficient to just give each package a unique number. The names are for humans to read. > PS: Is this really so important? Names are important. If I saw a package called "SevenZip", and I hadn't read this discussion, I would think it was a port of the program 7-Zip. That's not what it is, which means that the name is misleading. Luckily the summary and the description reflect what the content actually is, so the misunderstanding would be rectified quickly, but it would be better to avoid the misunderstanding in the first place. Björn Persson signature.asc Description: This is a digitally signed message part. -- 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
Matthew Woehlke wrote: > Peter Robinson wrote: > >>> I've never attempted an RPM-based update from e.g. Fedora 10 to > >>> Fedora 11. How well does that work out for regular Fedora users? > >> > >> Lot's of people will tell you that it works fine. However, this is not > >> a supported path for upgrade. Users should use Pre-Upgrade instead. > > > > Well its not supported completely, the simple fact that a lot of > > people use it means that its supported within certain constraints. > > I think you confuse "supported" and "functional". Upgrade via yum is > mostly /functional/. It is "(officially) supported" exactly to the > extent that you get to keep the pieces. If you are lucky, people /might/ > help you put them back together :-). 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? If I upgrade from the DVD, or by Preupgrade, and it breaks, who should I send the pieces to? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F11: LVM over MD is broken. Switch back to F10?
Gilboa Davara wrote: > Far worse, the F9 workstations are reaching EOL, and I cannot install > F10 on them due to known anaconda issue (That was fixed during the F11 > devel cycle) so in short, I'm in deep ... Can you upgrade them by Yum? That should avoid any Anaconda bugs. Björn Persson signature.asc Description: This is a digitally signed message part. -- 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
Bill Nottingham wrote: > If you honestly feel someone is intentionally stacking the Smolt results... > well, I don't know what to say. No, just that there are any number of reasons why different physical and virtual machines might send or not send data to Smolt, so that the sample is most likely skewed in various ways and none of us has a chance to know in what ways or how much. Björn Persson signature.asc Description: This is a digitally signed message part. -- 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
Bill Nottingham wrote: > According to public smolt stats: > http://smolt.fedoraproject.org/static/stats/stats.html > > only 0.38% of the userbase is non-Intel/AMD. (Number of registered systems > that report as Geode: 4.) Do you know the difference between a scientific study and a poll on a website? Scientists take care to select a representative sample. In a web poll the sample is completely uncontrolled. Which of the two does Smolt resemble most? Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: iptables/firewall brainstorming
Thomas Woerner wrote: > Please think of a scenario like this: Service A is adding > firewall rules for opening port 20 and 21 (ftp-data and ftp) for > everyone and service B is opening port 20 and 21 only for a specific > network segment. What do you want to have here? If you apply A's rules > first then 20 and 21 is open for everyone and the rules from B are not > used at all. But if you apply B's rules first, ... What is the right > ordering here? Should A or B win? A and B will collide anyway when they try to listen on the same ports. I don't see why it's important to make the packet filter rules coexist when the daemons won't. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Action requested: check dist tags and conditionals
Dennis Gilmore wrote:
> %if 0%{?fedora} <= 8 || 0%{?rhel} <= 5
Won't that expression always be true, except if both %{fedora} and %{rhel} are
defined? I can only guess on how this works but it seems to me that, in
Fedora 10 for example, it will be expanded to "%if 010 <= 8 || 0 <= 5", which
will be true because 0 is less than 5. (I'm assuming that "||" is the "or"
operator from C.)
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
James Laska wrote: > 1. How did you find out about Fedora Test Days? fedora-devel-announce > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? The instructions were sufficient. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? I found out about the Intel graphics test day too late to be able to participate on the right day. I first had to create a FAS account as I hadn't yet taken all the steps to become a packager. I got side-tracked by an incorrect error message in FAS and had some problems before I could report that. Then I had to create a Smolt profile. SmoltGUI crashed but I could work around the crash by changing the locale. Smolt using two kinds of UUIDs caused some confusion. I could eventually go through the test cases for Intel graphics a week after the actual test day. See also the next question: > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Live CD images were linked from the wiki pages. I had no problems downloading them. I eventually managed to make a working live USB stick from the one for the Intel test day, after I transferred it to my work computer where I had Fedora 10 and could install the latest Syslinux from Rawhide. It wasn't possible to do this on Fedora 9. The live USB stick I made from the CD image for the Nvidia test day was more dead than live. It wouldn't boot, so I couldn't participate in that test day. > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? I expected that someone would attempt to fix the bugs I reported. No such attempts have been mentioned in Bugzilla so far. I suppose I'll se whether they've been fixed when I upgrade to Fedora 11. Perhaps there would have been more interest in my reports if I had submitted them during the actual test day. > 6. Would you participate again in future Fedora Test Days? If they cover some functionality that's particularly important to me or some less than common hardware that I have. Björn Persson signature.asc Description: This is a digitally signed message part. -- 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
Jesse Keating wrote: > On Mon, 2009-06-01 at 20:56 -0500, Bruno Wolff III wrote: > > Do you hard link the new release files to the ones identical in rawhide > > so that rsync doesn't have to transfer them to places mirroring rawhide? > > Yes and no. We do use hardlinks, however the mechanism that gets it > from PHX to Raleigh is Netapp snapmirror, which works at the block > level. I don't know enough about snapmirror to know if it is helped by > hardlinks or not. The individual files aren't the real problem, it's > the isos, particularly the live isos. A program similar to Jigdo could speed this up. Transfer only the RPM packages (taking advantage of hard links) and information on what packages are in each ISO image, and then recreate the ISO images at the destination. That way each package would only be transferred once, regardless of how many ISO images it occurs in. Björn Persson signature.asc Description: This is a digitally signed message part. -- 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
Jesse Keating wrote: > Conceivably though you can have a scenario where if a suggested package > is present, you'll want to make use of it in the %pre section of the > suggesting package, and fail gracefully if it isn't there. So Suggests: > isn't enough, you'd need to order it so that if you choose to install > the suggestion, it gets installed prior to the suggesting package, hence > Suggests(post). You have to handle the situation where the user installs package A and then two months later installs package B. You also have to handle the situation where the user installs B and then later installs A. This is true for any two packages A and B as long as none of them has a hard requirement on the other. It seems to me that once you handle both of those cases correctly, it doesn't matter which order RPM chooses when the user installs both packages at once. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why not to create Fedora-us and Fedora-non-us branches?
Gregory Maxwell wrote: > On Tue, May 26, 2009 at 3:17 PM, Frank Murphy wrote: > > Patents are *currently* illegal in Europe, (though they may be granted). > > The patents offices being self-funding and all that. > > Codec patents are generally not 'software patents' in the common > patent-speak meaning of the words. Not if you ask the patent lawyers, no. > The bulk of codec patent holders are European companies (I.e. > Fraunhofer, Nokia, etc). The collection of royalties for codecs is a > multi-billion dollar a year industry. There are many well funded > companies spending considerable amounts of money licensing codecs, > even on products which they only intend to market in Europe. On that > basis, I think it's safe to conclude that there is more to the > situation than you are suggesting. That's certainly true. None the less, Frank is right. These patents *are* illegal, if you read what the convention and the national laws actually say, and yet they are granted by routine. Whether they would hold up in court doesn't matter much apparently. They are effective anyway. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean
Tom "spot" Callaway wrote: > mkdir -p `dirname "$RPM_BUILD_ROOT"`\ > mkdir "$RPM_BUILD_ROOT"\ Is that somehow better than just «mkdir -p "$RPM_BUILD_ROOT"»? Just curious. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: List of packages including country flags
Toshio Kuratomi wrote: > A two year old (through kindergartener or first grader) is certainly > capable of choosing a symbol that they've been taught to use from a > table of other symbols. The real question is whether there's a time in > a child's development when they can pick out an image that gets them > into a program but can't pick out a two letter abbreviation to do the same. It's not really about getting into the program but rather configuring the program. Gcompris uses the locale from the environment by default, like all well-behaved programs do, but you can go to the configuration screen and choose another locale if you want to. Then you need to exit Gcompris and start it again before the change takes effect on the whole program, so I doubt that the intention is that children should choose their locale every time they start Gcompris. I haven't quite figured out why the developers felt a need to have a separate locale setting just for Gcompris, but in those cases where it's needed I think a parent or teacher will configure the program and then tell the children not to touch the settings. > BTW, gcompris, has audio in various languages for children to learn > from. So it's not just text that's being translated by the language > selection. In that case I would suggest a recorded voice that says "Should I speak English?" and the equivalent in each language – if the intention really is that children who can't read should be able to choose their language. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: List of packages including country flags
On Mon, 1 Jun 2009, Richard W.M. Jones wrote: (Obviously it'll be Fedora/free software-related content) You can always make a request to Infrastructure at https://fedorahosted.org/fedora-infrastructure/. We've hosted some Fedora-related things there before. No idea if we have any sort of policy on what goes there though. It'll probably depend on how much space we have and how long it needs to be there for, etc. Thanks - I also found this page: http://fedoraproject.org/wiki/Torrent_Releases_Infrastructure_SOP Not really the sort of open tracker I was looking for ... Opening the question a bit, does anyone know a good tracker hosting service for use by free software projects? http://legaltorrents.com/ seems mostly oriented towards media content (& is in a permanent state of beta). More 'mainstream' services like TPB might support it, but then my users would have to navigate through pictures of nekkid ladies, other content they might find objectionable, and may be blocked from those sites anyway. What sort of content are we talking about and how often are you talking about adding/changing it? Thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
