Re: Proposal: fedora-release-rawhide subpackage
On Thu, Jan 07, 2010 at 02:02:24PM -0700, Kevin Fenzi wrote: On Thu, 07 Jan 2010 15:24:05 +0100 Till Maas opensou...@till.name wrote: You propose that the repo should be enabled by default if the package is installed. I don't like this. This make it a lot easier to break a system with Rawhide, if one installs the repo file, e.g. only to be able to easily download the src.rpm files with yumdownloader or to query it with repoquery, but not to actually install the unsigned packages from it. How many folks do this? I suppose this is a downside... we could also ship it with default disabled, so you would need to install and then enable it. I guess the use of repoquery for rawhide is quite common for Fedora developers who want to inspect the impact of updating their packages. Also I guess at least the selective installation of some Rawhide package might be quite common to verify bugfixes. Imho the danger of accidently breaking the system is a lot higher if there is a package that will auto-destruct the system with the next yum update than it is with the current setup, where a manual change of a config file is required. It will probably also auto break systems that just install everything, which is also not nice. I don't think it's possible to 'install everything'. There are a number of packages in the collection that conflict. Or do you have some other meaning for 'everything'? I believe that I have read about people installing everything except for conflicting packages to find some packaging bugs, e.g. non explicit conflicts. Regards Till pgpUnhCKsqc6m.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, Jan 07, 2010 at 09:28:26AM -0800, Jesse Keating wrote:
As I proceed to port our make system over into fedpkg, I've ran across a
couple targets that are giving me pause.
Is anybody out there making use of the following targets?
patch
I use this quite often to generate patches, but unluckily it only works
if the tarball is extracted into a dir called %{name}-%{version}.
I believe there is also a rediff target, which just renegerates a
patch and copies the comment above the patch.
unused-patches
I use this to easily get a list of patches I can cvs remove after I
removed them from the spec.
Regards
Till
pgptxnl3ULAbr.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, Jan 07, 2010 at 07:47:10PM +0100, Enrico Scholz wrote: Jonathan Underwood jonathan.underw...@gmail.com writes: I have used make patch quite a bit when developing patches. I guess it's just a wrapper around gendiff though, so it maybe redundant i.e. in my use case I could have been using gendiff. fwiw, 'gendiff' does not retain comments in patches and fails when one file is touched by multiple patches. I wrote a wrapper around 'quilt' which is used like Iirc there is a rediff target to keep the comments in a spec. gendiff works with multiple patches if one only wants to modify the last patch and the patches are applied with the right backup-suffixes in %patch. | %apply -n23 -p1 This expands to | quilt import -p 1 %PATCH23 | quilt push -f resp. | %patch23 -p1 on systems without this macro. Refreshing and developing of patches is very easy in this way. Would you please provide more instructions about how to implement it and how to use it? Regards Till pgpIFCjyNs1uS.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, Jan 06, 2010 at 03:59:14PM -0500, Owen Taylor wrote: On Wed, 2010-01-06 at 16:00 +0100, nodata wrote: I'd like to suggest an enhancement for Fedora 13: nothing should ever steal focus from the window I am typing in. If I am typing in a shell window, or in a word processor, or an e-mail, nothing should ever take keyboard focus away from that window. Clearly I'm missing something, otherwise we would have this, hence the posting to the list :) I'm not sure what you are missing, but I know what I'm missing here - a description of when exactly focus was stolen from you that was a problem. In almost all cases, if you are typing into one application in Fedora, and a window pops up from another application and steals away your focus, and your typing goes to the wrong place, that's a bug that should be filed against one of: I just realised that not only focus stealing when typing, but also when reading is annoying. E.g. here firefox just crashed, so I restarted it and while it opened all its tabs and windows, I wanted to read mails. But then firefox steals the focus several times for its windows. Is this something that is supposed to happen? Regards Till pgpSFXiFZNjpp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 10:22:58PM +0100, Hans Ulrich Niedermann wrote: I thought the canonical URL for downloads from sourceforge.net has been http://prdownloads.sourceforge.net/PROJECT/NAME-VERSION.tar.gz? It should be downloads... not prdownloads... according to the SourceURL ^^ Guidelines: https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net Regards Till pgpuRWAhL7Lr4.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Wed, Jan 06, 2010 at 08:47:09PM -0700, Kevin Fenzi wrote: I'd like to propose splitting out the /etc/yum.repos.d/fedora-rawhide.repo file into a fedora-release-rawhide subpackage which is NOT installed by default or shipped on the live media. I wrote up this using the Feature template, but I don't guess it's really that much of a feature: https://fedoraproject.org/wiki/Features/RawhideRepoSubpackage (except in that it needs coordination across the distro and docs updates, etc). Thoughts? You propose that the repo should be enabled by default if the package is installed. I don't like this. This make it a lot easier to break a system with Rawhide, if one installs the repo file, e.g. only to be able to easily download the src.rpm files with yumdownloader or to query it with repoquery, but not to actually install the unsigned packages from it. It will probably also auto break systems that just install everything, which is also not nice. Regards Till pgpaZkcQf2OFn.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 11:38:20AM -0700, Kevin Fenzi wrote: till:BADURL:dsmidiwifi-v1.01a.tgz:dsmidiwifi this seems to be now on google, I'll have to fix it. till:BADURL:john-1.7.0.2.tar.bz2:john I'll work on that later, too. After an update the old version was removed afaics. till:BADURL:aircrack-ng-1.0-20081109.tar.gz:aircrack-ng till:BADURL:libHX-1.25.tar.bz2:libHX Both packages are already newer in Rawhide, which version did you check? And at least libHX has a newer tarball in F11. Regards Till pgphYvmmWFt7y.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, Jan 06, 2010 at 02:24:17PM -0500, Adam Jackson wrote: On Wed, 2010-01-06 at 13:27 -0500, Fulko Hew wrote: On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson a...@redhat.com wrote: There is no case where _you_ want this, sure. I'd say... only take focus if its a child/creation of the window currently in focus. creation of is not something that's particularly well defined in X. Child windows are clipped to (wholly contained within) their parent, so in the evolution example from earlier, the compose window is a child of the root window, not of the mailbox view window. So at window creation time, there's no obvious relationship between the compose and mailbox windows. They do happen to have the same WM_CLASS and WM_CLIENT_LEADER window properties. But that still only addresses automatic focus changes within a single application. Automatic focus changes across apps is probably desirable; otherwise, nothing you launch from the gnome panel will launch focused, which is rather absurd. How about making the gnome-panel give away its focus to the newly created window? Within the gnome-panel, it should be pretty obvious which actions should give away the focus and which should not. I do not know, how easy to implement it is, though. Regards Till pgpYvOX2NgEnR.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, Jan 06, 2010 at 03:32:26PM -0500, Peter Jones wrote: On 01/06/2010 03:21 PM, Till Maas wrote: How about making the gnome-panel give away its focus to the newly created window? Within the gnome-panel, it should be pretty obvious which actions should give away the focus and which should not. I do not know, how easy to implement it is, though. That's pretty difficult for a launcher - how does the panel know that the launcher is going to create a window vs which is not? And how does it know what window it is? If you click on the firefox launcher, it runs a shell script. That script (may) eventually run an X application, but it in itself isn't one. What's the launcher telling the wm in that case under your proposed model? It could tell the WM, if a new window opens within the next second, focus it. I guess this should work in many cases. But in a better world, the launcher could maybe tell the WM if this process or a child of it creates a new window, then give the focus to it. Btw. I do not like it in general if a newly started application does not immediately open a new window and is ready to be used, but instead takes several seconds to startup and then take away focus if I am already doing something else then to wait for it. This is also why I propose a timeout for the focus giveaway. Regards Till pgpAntZzLc3h1.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 03:29:22PM -0500, Dave Jones wrote:
Before..
Source0:
http://download.sourceforge.net/usb-midi-fw/midisport-firmware-%{version}.tar.gz
After
Source0:
http://downloads.sourceforge.net/project/usb-midi-fw/midisport-firmware/%{version}.tar.gz
For 1.2 as version, this works (which is also the URL the SourceURL
guidelines recommends[0]):
http://downloads.sourceforge.net/usb-midi-fw/midisport-firmware-%{version}.tar.gz
Regards
Till
[0] https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net
pgpyrbfhkpmpN.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Tue, Jan 05, 2010 at 11:48:47AM -0500, Tom spot Callaway wrote: On 01/05/2010 11:30 AM, Jesse Keating wrote: On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... Isn't that a chicken/egg problem? It really is. I mean, we could create the Packaging Police to run around and enforce the guidelines by force (either by fixing them manually, or by threatening maintainers until they do it), but is that really what we want? I would skip the threatening part, but allowing provenpackagers to fix violations to the packaging guidelines after a short notice to the maintainers is something we should encourage imho. It just plain sucks if there are bugs that can be fixed easily and may cause issues, but it takes several weeks to be able to fix them oneself. Regards Till pgpRgIi5QJllp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How did I end up as the package owner for emacs?
On Sun, Jan 03, 2010 at 10:53:26PM +0100, Karel Klic wrote: you became the owner in the pkgdb when Daniel Novotny and I agreed to transfer the package ownership to me. We discovered that the next person with commit access become the owner when a package is orphaned, and the package owner cannot be changed in pkgdb. I asked about the solution on IRC, and when I got no answer I postponed it. From my point of view it is not important who is the owner when I can fix bugs and commit changes. Here is an but report about this, so hopefully this will be fixed eventually: https://fedorahosted.org/packagedb/ticket/152 Regards Till pgpkMAQTfzv9E.pgp Description: PGP signature -- 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
On Fri, Dec 18, 2009 at 04:35:07PM +0200, Debarshi Ray wrote: What happens now? Not much I guess, as the list archive obfuscates email [...] that give you a feeling of accomplishment? Just trying to point out the futility of trying to avoid publishing your Fedora ID. It took me less than a minute to find it without asking any human. One might even put up a web page with your Fedora email address all over it. He did not wrote about his Fedora ID, but about publishing the e-mail address not obfuscated. Also he clearly stated that he wishes that nobody publishes it obfuscated. If you just want to point out, that you can research the address, you still do not need to post it. For me it was only rude behaviour. Regards Till pgp7ZTbruD5Gq.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add extra generated RPM requires - how?
On Fri, Dec 18, 2009 at 03:54:53PM -0500, Adam Jackson wrote: On Fri, 2009-12-18 at 20:26 +, Richard W.M. Jones wrote: For libguestfs [RHBZ#547496] I want to add some extra 'Requires' dependencies by running a shell script over a particular file that gets generated during the build. What's the best way, or a way, to do this? It's... not easy. You want to overload the %__find_provides macro to invoke your script as well as the standard script for things like library sonames. If you get it working let me know, I want basically the same thing for the X server and have so far been defeated. I once created this for ghc/haskell packages, but I believe it was never used. I got inspired by a pythondeps.sh script. The trick here is to run the rpm default dependency script from within the new script. My attempt is available here: http://till.fedorapeople.org/ghcdeps.sh Regards Till pgp0qek7x4byR.pgp Description: PGP signature -- 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?
On Wed, Nov 18, 2009 at 11:18:28PM +0530, Rahul Sundaram wrote: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. To me it looks like the F12 i386 Everything repository is not signed: $ curl -sI http://download.fedoraproject.org/pub/fedoralinux/releases/12/Everything/i386/os/repodata/repomd.xml.asc | head -n1 HTTP/1.1 404 NOT FOUND So at least one major security protection measure is not in place and attackers can create their own repositories with signed packages that have well known security flaws, e.g. a package with a bad setuid root binary, and install it, if it is not already installed in a newer version. Regards Till pgppWah6SU9pr.pgp Description: PGP signature -- 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?
On Thu, Nov 19, 2009 at 04:36:27AM -0500, Ricky Zhou wrote: On 2009-11-19 10:23:53 AM, Till Maas wrote: So at least one major security protection measure is not in place and attackers can create their own repositories with signed packages that have well known security flaws, e.g. a package with a bad setuid root binary, and install it, if it is not already installed in a newer version. I might be wrong on this, but wouldn't the attacker need to trick yum/packagekit into using the malicious repo first? I didn't think that was allowed for non-root users. Yes packagekit must be tricked into using the malicious repo, but this is not something that needs to be done on the system, but can also be done by an MITM attack on the network traffic or compromising DNS. Note that even if the repomd.xml files were signed, it'd be easy for an attacker to just take an old one with a valid signature and host a repo with outdated packages. I thought metalink (https://mirrors.fedoraproject.org/metalink?repo=updates-released-f12arch=x86_64) over https was supposed to address the problem of outdated repos though. It seems that at least the information provided in the metalink is enough to perform proper verification and deny outdated repositories, since there are timestamps and secure hashes provided for the repomd.xml file. But there might be still a problem with third party repositories, if they do not use metalink. And if the metalink information is not used in a secure way by yum. Regards Till pgpG8JfxSSm2j.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Missing links on Fedora CVS
On Mon, Nov 09, 2009 at 07:19:33AM +, Quentin Armitage wrote: I'm not sure where the correct place to report this is, so apologies if this is not the right place. The right place is here: https://fedorahosted.org/fedora-infrastructure/ Regards Till pgph1AOZytKWY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-11-01
On Sun, Nov 08, 2009 at 09:23:08AM -0700, Kevin Fenzi wrote: On Sat, 7 Nov 2009 16:38:38 -0600 Bruno Wolff III br...@wolff.to wrote: I tried grabbing http://dl.sf.net/glest/glest_data_3.2.1.zip and it seemed to work. The actual URL in the spec file has the %version macro. Is the macro or something with sourceforge the problem? It's sourceforge. I use 'spectool -g foo.spec', which expands all the macros... Here's what my script said for that spec: --2009-11-01 17:16:41-- http://dl.sf.net/glest/glest_data_3.2.1.zip Resolving dl.sf.net... 128.101.240.209, 150.65.7.130, 198.142.1.17, ... Connecting to dl.sf.net|128.101.240.209|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-11-01 17:16:42 ERROR 404: Not Found. Sadly, I think sf is just unreliable. ;( The SourceURL Guidelines[0] mandate to use in this case http://downloads.sourceforge.net/glest/glest_data_3.2.1.zip instead of the dl.sf.net version. Regards Till [0] https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net pgpCRVbk8o023.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: source file audit - 2009-11-01
On Thu, Nov 05, 2009 at 09:33:48PM +0200, Ville Skyttä wrote: On Thursday 05 November 2009, Jason L Tibbitts III wrote: KF == Kevin Fenzi ke...@scrye.com writes: KF Well, the script I am running uses 'spectool -g' and indeed, it KF doesn't handle self signed certs: Honestly, I find it easier to just hack spectool rather than reject valid URLs that just happen to use self-signed certificates. You might also be able to tweak /etc/fedora/wgetrc to achieve the same thing. Unless there are objections, I'll make spectool use wget --no-check- certificate in the next rpmdevtools release (internally, because shipping a /etc/fedora/wgetrc would be a backwards incompatible change that could break stuff). Please make it also an paramater, e.g. only spectool -g --no-check-certificate foo.spec will disable the certificate checking. In case upstream provides a https URL with a well known CA, it should be easily for packagers to use it to update their package. Regards Till pgpaIEHPyLeyN.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CVS daily checkout seeds
On Wed, Nov 04, 2009 at 02:51:27PM +, Quentin Armitage wrote: The CVS daily checkout seeds at http://cvs.fedoraproject.org/webfiles/ don't contain a checkout for F-12. Would it be possible for someone to add that? I have also noted that a checkout seed for F-9 is still included, which seems somewhat superfluous. I have created a ticket for this in the infrastructure bug tracker: https://fedorahosted.org/fedora-infrastructure/ticket/1784 If you have an FAS account, you can also create tickets there by yourself, because this is not the right mailing list to report such issues. You can also add yourself on the CC list, if you have FAS account to get notified in case someone works on it. Regards Till pgpQcYK0HSUi6.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On Sat, Oct 24, 2009 at 07:14:39AM -0700, Ulrich Drepper wrote: On 10/23/2009 07:01 PM, Kevin Kofler wrote: It was (mostly) ignored because it doubles the download size and makes the image no longer fit on a CD, for little benefit. Yes. It is a solution which adds costs in many, many places for a problem that doesn't exist. I don't see why people even spend a second thinking about this. For me it would be useful to have a simple way to make a USB installation device for both my 32bit and 64bit machines. Also a single rescue system for both 64bit and 32bit machines would be nice. Regards Till -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] Include a link to /verify for pre-releases
On Fri, Oct 23, 2009 at 10:36:07AM -0400, Todd Zullinger wrote: Some beta users asked how to verify their downloads. Others didn't know the checksum used SHA-256 instead of SHA-1. As a first step, adding a link to the /verify page might help. Imho the link should go to the https version of the page to make it more likely that people use the https link, e.g. when they bookmark the page for later use. Regards Till pgpujCwCgD6FZ.pgp Description: PGP signature -- Fedora-websites-list mailing list Fedora-websites-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-websites-list
Re: Simplify non-responsive maintainers policy Part 2
On Wed, Oct 21, 2009 at 11:10:22AM -0700, Toshio Kuratomi wrote: * Should we expedite these requests in the future if the email address for the maintainer is no longer in existence? Yes, please. If the mail address of a maintainers do not work anymore, then their packages should be orphaned, so that others can maintain them. If the mail address does not work, then all bug report notifications would get lost and also communication attempts using the package-owner aliases. Therefore it should be made sure there is always someone caring about these messages for each package. * Should we formalize the unwritten policy for Red Hat maintainers who leave the company and don't want to maintain their packages anymore? Yes, unwritten policies are always bad. * Do we need sanity checks to be sure maintainers who do want to keep their packages do so? What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. * Do we want something more generic that covers other compaines that pay their employees to package for Fedora? Does it need to be different than the currently unwritted Red Hat policy? If not, then it could just be the same policy Red Hat can be used as an example, if needed. Regards Till pgpu9CLr9PhC2.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Status of touchpad support in F12 for kdm?
On Mon October 19 2009, mcloaked wrote: Given the recent long thread concerning upstream decisions about defaults in Thunderbird 3.0beta4 it seems to me that just because upstream makes a specific decision does not always mean that is the best decision. What That discussion was not about the default in general, but about changing the default in an update for a stable Fedora release. I guess the default for Rawhide/F12 will be the same that upstream has. Regards Till 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: [Fwd: Junior Jobs]
On Mon, Oct 19, 2009 at 08:32:56AM +0200, Miroslav Suchý wrote: Původní zpráva Předmět: [opensuse-packaging] Junior Jobs Datum: Tue, 13 Oct 2009 14:46:58 +0200 Od: Michal Hrusecky mhruse...@suse.cz Komu: opensuse-packag...@opensuse.org lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of openSUSE packages can choose some of theirs easy bugs and mark them as Junior Jobs. Then anybody from community can volunteer and fix these issues. These tasks will be easily fixable and their purpose is to let people learn how to contribute and to create some easy task so anybody can join and start participating. I would like to have something like this, too. But currently more an easy way to ask a provenpackager for help for anything, even trivial issues. So that packagers that do not currently have the time to look into something flag the bug report and there is a list for provenpackers to go through and fix the issues. Regards Till pgpmBSiQOy3xo.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On Tue, Oct 20, 2009 at 10:20:17AM +0200, Tomas Mraz wrote: What would this be good for? Actually for some files it would be a known bad file hashes because these files (binaries or scripts) would contain known vulnerabilities and so knowing that you have a file that was once included in Fedora does not guarantee you almost anything. Having a hash list of well known files might also help in forensics analysis to find suspicious files. Also with determining the correct RPM NVR one could use the repo metadata to check wether there are known vulnerabilities for certain files or just to detect that the file is not from an uptodate RPM. Regards Till pgpYK0z2GyCzq.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On Wed, Oct 21, 2009 at 12:00:23AM +0200, nodata wrote: Am 2009-10-20 23:48, schrieb Till Maas: Having a hash list of well known files might also help in forensics analysis to find suspicious files. Also with determining the correct RPM NVR one could use the repo metadata to check wether there are known vulnerabilities for certain files or just to detect that the file is not from an uptodate RPM. How is this check going to be done? The hash for each file on a filesystem is computed and then compared with the list. Is the filesystem going to be mounted in a known clean environment? If not, what's the point? Filesystems can also be accessed without actually mounting it. But a clean environment should off course be used. If yes, how do you know the filesystem hasn't been returned to a clean state? The process of forensics analysis is more complex than just running one single command. Nevertheless getting a list of suspicious files can lead to find the information one is interested in. And if all files match the hash of a well known file, then this information can also be used to decide to investigate using other methods. Regards Till pgp5DMQRjJ0CO.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
On Fri, Oct 16, 2009 at 10:48:24AM +0400, Peter Lemenkov wrote: Please, disconnect yourself from the Internet asap, because it's full of obscene videos, jokes, sexism and so on. And that's great! Even if something is on the internet, this does not meant that it has a place within the Fedora Community or Collection. Somewhere in the wiki, there is also some information about this hidden iirc. Especially sexism or obscenity does not have its place within Fedora, as well as racism and discrimination against anything at all. You may also want to think about whether you really find it great that there's sexism on the internet, because you might have confused it with sexual content. From Wikipedia[0], the free encyclopedia: | Sexism, a term coined in the mid-20th century,[1] is the belief or | attitude that one gender or sex is inferior to, less competent, or less | valuable than the other. I don't think it's great, that there is sexism anywhere. Regards Till [0] http://en.wikipedia.org/wiki/Sexism pgpt4cuur10yj.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who do I send to get a package removed because of bad language.
On Fri, Oct 16, 2009 at 01:10:09PM +0400, Peter Lemenkov wrote: 2009/10/16 Rahul Sundaram sunda...@fedoraproject.org: On 10/16/2009 02:29 PM, Peter Lemenkov wrote: You see, I personally prefer to live in the society with some level of aggressively thinking and speaking minorities, rather than in dark ages of censorship, brainwashing and hypocrisy. You seem to be equating aggressive thinking with sexism and racism and censorship with a requirement for civil and decent behaviour in communities. Civil and decent behavior is to be tolerant to others, right? So, please, be tolerant to sexists/racists/multiple other-ists. Being tolerant does not mean to support or accept intolerant behaviour, but not to discriminate against them because of their sex, race or other characteristics. Nobody here is suggesting that racists or sexists should be discriminated against because of their sex or race. But it does not mean that their intolerant behaviour will be accepted. Also racism and sexism do not contradict to censorship and brainwashing but they support each other. Nevertheless, if you prefer a racist and sexist environment, you are wrong here in the Fedora Project. Regards Till pgpn4924vwCHp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What to do if a deprecated license is used? nescc java files with intel license
On Fri, Oct 16, 2009 at 10:58:16AM -0400, Tom spot Callaway wrote: On 10/15/2009 10:02 AM, Till Maas wrote: Hiyas, I looked into packaging the nesc compiler (https://sourceforge.net/projects/nescc) and I noticed that it uses the deprecated intel license for some java files: http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2view=markup http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL-LICENSE?revision=1.1view=markup I opened a bug in their bug tracking system for this: https://sourceforge.net/tracker/?func=detailaid=2879881group_id=56288atid=480036 The Intel license is OSI approved, but deprecated and therefore currently not allowed for Fedora afaics: https://fedoraproject.org/wiki/Licensing#Bad_Licenses Btw. it's a should not, so maybe it is ok, nevertheless. Or it should be a must not guideline, e.g. because it also affects non OSI approved liceneses afaics. I've updated the wording there to clarify that no Fedora package may use anything under a Bad License. Thanks. Can you maybe also give me some arguments, why I should get the project to change from the Intel license? There is also a huge actively maintained project using that license and it also states that it is a BSD-style license: http://www.tinyos.net/contrib.html I just checked and the main difference between the New BSD license (no advertising, 3 clause) is, that it also adds a note about export regulations. So afaics, if it was not explicitly be banned from Fedora, then one could use it just with the BSD shortname afaics. This is very confusing. Regards Till pgpV9DDOwoNhn.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What to do if a deprecated license is used? nescc java files with intel license
On Fri, Oct 16, 2009 at 08:57:55PM +0200, Kevin Kofler wrote: Till Maas wrote: I looked into packaging the nesc compiler (https://sourceforge.net/projects/nescc) and I noticed that it uses the deprecated intel license for some java files: http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/COPYRIGHT?revision=1.2view=markup http://nescc.cvs.sourceforge.net/viewvc/nescc/nesc/INTEL- LICENSE?revision=1.1view=markup Are you sure it's really using the deprecated license? The INTEL-LICENSE file above doesn't have that added Export Laws paragraph which the deprecated: http://opensource.org/licenses/intel-open-source-license.php has, so to me it seems to be just regular BSD. You are right. I'll try to get them to also mention this explicitly. Regards Till pgpnHnDNgmTqB.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are packages w/o necessary kernel modules allowed?
On Wed, Oct 14, 2009 at 06:31:03PM +0200, Felix Kaechele wrote: From the opposite POV: Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. IMHO having both in RPMFusion with a proper dependency is the easiest way to install it. Having some package with a missing kernel module dependency in Fedora would only make it more complicated for other repositories that provide the kernel module and can therefore provide a package with a unbroken dependency. Regards Till pgpgVpR0UuxiG.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: wmii window manager
On Sat, Oct 03, 2009 at 10:12:04AM +0100, Ilyes Gouta wrote: Do we have wmii (a window manager, http://wmii.suckless.org) packaged for Fedora? I packaged it a while ago for myself, but I am currently using xmonad. Maybe you can use my old SPECS / SRPMS: http://till.fedorapeople.org/tmp/libixp-0.2-1.src.rpm http://till.fedorapeople.org/tmp/libixp.spec http://till.fedorapeople.org/tmp/wmii-3.5.1-1.src.rpm http://till.fedorapeople.org/tmp/wmii-4.0-0.1.20060705.src.rpm http://till.fedorapeople.org/tmp/wmii.spec Regards Till pgpkp3LCUqjpK.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: wmii window manager
On Sat, Oct 03, 2009 at 11:10:35PM +0100, Ilyes Gouta wrote: Is it in line with rawhide? Did you ever pushed it into koji? Do you have a packaged p2p (plan9 on Unix)? I never submitted it into Fedora, I just created the SPEC for myself to test wmii. As you can see from the dates of the changelogs, the files are from February 2007 and probably need some adjusting. I don't think I created a SPEC for p2p. Regards Till pgpINAvhC8YFn.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Mon, Sep 28, 2009 at 12:53:21PM -0700, Adam Williamson wrote: Secondly, where would be the appropriate place to propose accepting zsync with the internal zlib? Is that something I should bring to the packaging committee? This proposal has already been declined by FESCo: https://fedorahosted.org/fesco/ticket/134 Regards Till pgpeZoVTUZ1HP.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Non-responsive maintainer process for kurzawa / Krzysztof Kurzawski
On Fri, Sep 25, 2009 at 07:24:01PM +0200, Rafał Psota wrote: 2009/9/25 Kevin Fenzi ke...@scrye.com The following packages have been orphaned: youtube-dl Also, I would be happy to take 'greyhounds'. Co-maintainers welcome. I'm a maintainer of metacafe-dl which is similar to youtube-dl, so I would like to take it. Please take ownership then: https://admin.fedoraproject.org/pkgdb/packages/name/youtube-dl Afaics, you need to create a new review request for the package afterwards: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure Please feel free to add me t the CC list, after you updated the spec, I will then review it. Regards Till pgpWMLP9JW38P.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 10:20:21AM -0400, James Antill wrote: ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If nobody can fix xz before F12 GA then IMNSO we should revert the compression to something that works ... the minor savings in xz compression isn't worth as much as delta's. I guess there won't be any deltarpms to update from F11 to F12, so afaics it would be enough to only switch back to gzip payload for everthing that is going into F12 updates(-testing). Is this true? Then we would still save space on the iso images and for the Everything Repository, but deltarpms would still be possible. Regards Till pgpFb7V9FfCR7.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 10:58:23AM -0400, Seth Vidal wrote: On Wed, 23 Sep 2009, Till Maas wrote: On Wed, Sep 23, 2009 at 10:20:21AM -0400, James Antill wrote: ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If nobody can fix xz before F12 GA then IMNSO we should revert the compression to something that works ... the minor savings in xz compression isn't worth as much as delta's. I guess there won't be any deltarpms to update from F11 to F12, so afaics it would be enough to only switch back to gzip payload for everthing that is going into F12 updates(-testing). Is this true? Then we would still save space on the iso images and for the Everything Repository, but deltarpms would still be possible. We'd need a mass rebuild to all pkgs in rawhide/f12-candidate to shake Xz out of the payload compression. That's non-trivial. Why do we need a mass rebuild? Afaics it is only needed to change the compression back to gzip at the time of the final freeze, so that all newly build packages (which are the ones going to F12-updates(-testing) are build with gzip compression. Then delta rpms can be created from F12 Everything to F12 updates-testing. For packages that are built to break the freeze, there could be a seperate build target tag, that still uses the xz compression. This is all under the assumption, that delta rpm creation from a xz compressed rpm to a gzip compressed rpm works. Regards Till pgpVHZ63y5dmX.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Where is Callum Lerwick / seg? (was: Re: Where is the openjpeg maintainer?)
On Wed, Sep 23, 2009 at 12:19:10PM -0400, Adam Goode wrote: In the bug report, the maintainer seems to suggest that having co-maintainers are ok: feel free to merge it, but never approves them. Can someone approve these co-maintainers? I will probably help to also mention the name and FAS username of the openjpeg maintainer, which are Callum Lerwick and seg. I also CC'ed him to this mail, so maybe this helps to get his attention. Regards Till pgp7zHiMc7gVn.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 09:00:37AM -0700, Jesse Keating wrote: On Wed, 2009-09-23 at 10:23 -0400, Seth Vidal wrote: ...but to me this is all a _problem_in_xz_, not presto/deltarpms. If nobody can fix xz before F12 GA then IMNSO we should revert the compression to something that works ... the minor savings in xz compression isn't worth as much as delta's. agreed. Dropping xz at this point would mean another full mass rebuild. Do-able but needs to happen very very soon. I'm still wondering why it is not possible to use xz for the Everything/ and iso rpm and gz for the rpms going to updates. Regards Till pgpwmkKjQqeKh.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Wed, Sep 23, 2009 at 07:38:24PM -0400, Andre Robatino wrote: On 09/23/2009 07:17 PM, Bill Nottingham wrote: Andre Robatino (an...@bwh.harvard.edu) said: If I understand correctly what the problem is - that successfully xz-uncompressing a file requires being on the same endian arch as the one it was compressed on - that's just wrong. It shouldn't be platform-dependent at all. That is not the issue. There are two issues: - Compressing a file on different arches, while it produces output that any arch can decompress, does produce *different* output. - Compression of xz is not fast. Ah, OK. But hasn't openSUSE been using xz in their deltarpms since 11.0 (over a year ago)? What are they doing differently so they aren't affected? 1) Maybe they don't build noarch rpms on ppc 2) They use a faster compression, that creates bigger output. At least I remember something like this mentioned in this thread or some other discussion. Regards Till pgpGmcA0YAMxU.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: should file ncrack-services go to /etc?
On Tue, Sep 22, 2009 at 10:42:20AM -0700, Toshio Kuratomi wrote: On 09/22/2009 02:43 AM, Martin Gieseking wrote: Am 21.09.2009 23:24, Till Maas wrote: On Mon, Sep 21, 2009 at 04:58:32PM -0400, Casey Dahlin wrote: On 09/21/2009 04:04 PM, Till Maas wrote: On Mon, Sep 21, 2009 at 08:47:24PM +0200, Martin Gieseking wrote: during the review of ncrack (https://bugzilla.redhat.com/show_bug.cgi?id=523199) I noticed that the file ncrack-services is placed in /usr/share/ncrack by default. Since it is a kind of configuration file that contains mappings between port numbers and protocol names (similar to /etc/services), I'm not sure whether the location /usr/share/ncrack is OK or whether it's required to move it to /etc. Here's its content: Imho it does not need to be moved to /etc, because it should only be edited by experienced users and then the user can specify a the edited file at the commandline. Neither of which are factors considered by the FHS. Since the file is not meant to be edited, it is not a host-specific config file, but a package version specific config file, which is managed by upstream and not by the user. So from the users point of view, it's more a data file than a config file. Casey and Till, thanks for your comments. If I interpret them correctly, there's no Fedora policy that demands moving the file to /etc even if /etc could also be a proper location. Then we can finish the review of ncrack. :) This is an Incorrect summary. Fedora has a policy of following the FHS. If the files are config, then they go in /etc. Till is making incorrect statements when he uses this reasoning: Imho it does not need to be moved to /etc, because it should only be edited by experienced users and then the user can specify a the edited file at the commandline. The level of experience of the user is irrelevant. If the user edits the file to configure the program, then it goes into /etc. Maybe experience was not the right word here. Imho it does not really matter, whether the users edits a file, to change the beheaviour of a program, but whether the file is intended to be used for this. E.g. experienced users could also edit python scripts or shell scripts to configure them, e.g. to set a certain default beheaviour, e.g. if the program does not provide a interface using a config file for this. Still the program is not a config file. My comment here was in reaction of the quoted manpage in https://bugzilla.redhat.com/show_bug.cgi?id=523199#c12 | It could go in /etc/ ... but the man page has this: | |--datadir directoryname (Specify custom Ncrack data file location) . |Ncrack needs a file called ncrack-services to load a |lookup-table of |supported services/ports. This file shouldn´t be changed, |unless you know what |you are doing (e.g extending Ncrack for additional modules). Another example which kind of fits here, are imho .desktop files. They also allow to configure which files are how openend by xdg-open. Oh, but thinking more about it, .desktop files seem even better to belong to /etc than to /usr, unless there exists some intended way to mask them with other .desktop files in /etc. Nevertheless, the distinctions seems to be kind of fuzzy to me and the FHS does not really provide a clear guidance for this. In his next message, though, he says this: Since the file is not meant to be edited, it is not a host-specific config file and concludes that the file is a data file. This is a more correct stating of the Guidelines. Btw. as far as I understand the program, if the config file is changed, then an addional module, which is written in C++, that covers the new service needs to be added, too. Not necessarily. There might be scenarios where you want to change the default ports for several services, maybe because the ssh daemons in your local network are configured to listen on port 12345. In this case the admin possibly would like to adapt the default settings of ncrack. This means that the file must go in /etc. If this is really a valid use case for the file. But then this should be also cleanly communicated, e.g. datadir and data file substituted with confidir and config file in the manpage and this should be given as an example. Maybe it should be also made clear in the file, that changing it is not expected by upstream, e.g. in case of bug reports, where something does not work, because of changes to the file. Regards Till pgp4bPzhdJkjL.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: should file ncrack-services go to /etc?
On Mon, Sep 21, 2009 at 08:47:24PM +0200, Martin Gieseking wrote: during the review of ncrack (https://bugzilla.redhat.com/show_bug.cgi?id=523199) I noticed that the file ncrack-services is placed in /usr/share/ncrack by default. Since it is a kind of configuration file that contains mappings between port numbers and protocol names (similar to /etc/services), I'm not sure whether the location /usr/share/ncrack is OK or whether it's required to move it to /etc. Here's its content: Imho it does not need to be moved to /etc, because it should only be edited by experienced users and then the user can specify a the edited file at the commandline. Regards Till pgpAPMnpCmmPo.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: should file ncrack-services go to /etc?
On Mon, Sep 21, 2009 at 04:58:32PM -0400, Casey Dahlin wrote: On 09/21/2009 04:04 PM, Till Maas wrote: On Mon, Sep 21, 2009 at 08:47:24PM +0200, Martin Gieseking wrote: during the review of ncrack (https://bugzilla.redhat.com/show_bug.cgi?id=523199) I noticed that the file ncrack-services is placed in /usr/share/ncrack by default. Since it is a kind of configuration file that contains mappings between port numbers and protocol names (similar to /etc/services), I'm not sure whether the location /usr/share/ncrack is OK or whether it's required to move it to /etc. Here's its content: Imho it does not need to be moved to /etc, because it should only be edited by experienced users and then the user can specify a the edited file at the commandline. Neither of which are factors considered by the FHS. Since the file is not meant to be edited, it is not a host-specific config file, but a package version specific config file, which is managed by upstream and not by the user. So from the users point of view, it's more a data file than a config file. Btw. as far as I understand the program, if the config file is changed, then an addional module, which is written in C++, that covers the new service needs to be added, too. Regards Till pgpN8OBjoXBvu.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Fri, Sep 18, 2009 at 09:31:49AM +0200, Jan Zeleny wrote: I already have one developer, who is willing to join me. I'd like to know your opinion of this project. And of course if there is anybody who would like to join, just let me know, I'd be happy to gather some more people to work on this. There is a distributions mailinglist at freedesktop.org, where you could coordinate with other distributions and fin more interested people. Regards Till -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Non-responsive maintainer process for kurzawa / Krzysztof Kurzawski
On Sat, Sep 12, 2009 at 10:13:52AM +0200, Michael Schwendt wrote: The single month you're willing to wait is not much of a problem. There is a more fundamental problem. The non-responsive packager procedure could have been started _several_ months earlier. Perhaps one year ago already. There have been dead silent bugzilla tickets that ought to have raised an alarm-bell. I would have started the process earlier, if I did not have to write several mails for it in specific intervalls, e.g. when I spotted the first bug report. But imho it is too much a PITA to write these mails at these intervalls and also if I spot a problem, then I normally have some spare time to spend on Fedora, which might not be the case when the process is finished and I could start the actual work. Regards Till -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090910 changes
On Fri, Sep 11, 2009 at 10:37:59AM +0100, Peter Robinson wrote: This was discussed a couple of days ago against another rawhide report. I would check out the list archives for the reasoning. I fail to find it. :-( The last report in the old format was 20090902 and I did not find any discussion looking back up to 20090811. This is somehow strange again, because I would expected to also receive an announcement if the report format is changed, e.g. I just assumed that the script was somehow broken, because it did not report any new packages anymore or something else. I did not bother to scoll beyond the broken dependencies, because I do not really care to read them. If my package has a broken dependency, I get a personal e-mail. Regards Till pgpuSsjuKDQBK.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Non-responsive maintainer process for kurzawa / Krzysztof Kurzawski
On Fri, Sep 11, 2009 at 08:10:03PM +0200, Till Maas wrote: Maybe something like people need to convince at least two FESCo members and have no FESCo member object to get this done: 1) Write a mail to fedora-devel with the problems of the package and a summary of communication attempts and open a ticket in FESCo to track all this. 2) If nobody from FESCo objects and two members agree after three days, the package can be reassigned. I have created an official proposal for this on FESCo trac: https://fedorahosted.org/fesco/ticket/251 Regards Till pgpZlRHZAuPNW.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Heads up] FUSE so-name bump is coming.
On Tue, Sep 08, 2009 at 11:41:58AM +0400, Peter Lemenkov wrote: I'll plan to upgrade fuse in Rawhide (and, possibly, in F-11) up to ver. 2.8.0, and there will be so-name bump. I'll do it next week, if nobody have any objections. Also I'll try to test all (or as much as I can) FUSE-related packages for compatibility with new package before (this weekend, probably). There might be also F-12 branches around for fuse dependent packages. Maybe you also want to first branch F-12 off, so there can be builds in Rawhide for F-13 that will not disturb the F-12 Rawhide. Will you also rebuild the packages once the new fuse is in place? Regards Till pgpq2KwbtSztl.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On Sun, Aug 23, 2009 at 09:32:11PM -0700, Elio Maldonado wrote: You are right. By reading at Makefile.common it seems that make new-source nss-softokn-3.12.3.99.3-stripped.tar.bz2 would be the way to place them in the lookaside cache (after I do the cvs remove on them). You probably need to run it using the variable FILES: make new-source FILES=nss-softokn-3.12.3.99.3-stripped.tar.bz2 Regards Till pgpZEIjAOa4Yk.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-08-20
On Fri, Aug 21, 2009 at 03:07:47PM +0200, Kevin Kofler wrote: Michael Schwendt wrote: Indeed. A single tomboy build obsoleted more than a dozen Mono packages and actually got marked stable sometimes later without anyone adding a comment. I'd blame the tomboy maintainer for the chaos there. Before you push an update to a package, you MUST check for previous updates for the package (possibly filed by somebody else, Bodhi will NOT mail you about them, even if you are the maintainer!), and if it's a grouped update, you CANNOT push a new update for your package, you MUST get it updated in the group instead. I'd blame the bad workflow and the unexpected beheaviour of bodhi. Btw. all your steps are not documented in the Package Update Howto[0] and are probably not valid anymore, since the auto obsoletion is disabled now. But I do not really know how Bodhi would behave now. Regards Till [0] https://fedoraproject.org/wiki/Package_update_HOWTO pgpe0kVTrakjl.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FAS correction
On Wed, Aug 19, 2009 at 04:12:02PM -0400, Todd Zullinger wrote: solarflow99 wrote: hi, just noticed a little mistake, the [i]info for the client side certificate should say to save it as .rpmfusion.cert not fedora.cert. I couldn't seem to do anything to edit that myself.. Do you mean .fedora.cert instead of .rpmfusion.cert above? And which URL are you seeing this? I guess the problem is at the RPM Fusion FAS setup: https://fas.rpmfusion.org/accounts/ There the webmas...@fpo address is mentioned to report bugs, probably because the address is hardcoded in the templates instead of being an item in the configuration file. I created a ticket for this here: https://fedorahosted.org/fas/ticket/107 Regards Till pgpvY3y5SR77X.pgp Description: PGP signature -- Fedora-websites-list mailing list Fedora-websites-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-websites-list
Re: naive live USB question
On Thu, Aug 13, 2009 at 12:12:35PM +0100, psmith wrote: jeez when i brought up the idea of fedora using hybrid iso's a few months back i was basically lambasted by most on this list, now all of a sudden it's a new F12 feature? wtf??? I am not sure, what the right word is, but there seem to be unfounded(?) criticism every now and then on this list, which is best to ignore or to disprove, depending on whether the people who would actually work on the projects in question listen to it or not. Nevertheless, Jeremy Katz, afaik the main developer of the livecd tools, was positive about your suggestion back then: https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00698.html Regards Till pgppxDqGkCagS.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Cannot rely on /dev being present in %post scripts?
On Wed, Aug 12, 2009 at 03:18:16PM +0100, David Woodhouse wrote: According to bug #517013, %post scripts should not assume that /dev is available -- so we can't do anything that requires the existence of /dev/null, /dev/urandom, etc. Is this a known and expected packaging rule, or is it a bug in the way that the user is attempting to install the packages? I mentioned it already in the bug report: There are some scriptlet recommendations that use /dev/null: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets Regards Till pgpVetQ7miiwI.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Fri, Aug 07, 2009 at 10:48:34AM -0400, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: I considered IT might be redundant information, too, when I created the groups, but also both the terms Forensics or Wireless are not IT specific, therefore I put the IT-security explanation into the description. There can be wireless analysis that is not security related, e.g. to find sources of disturbance and there are a lot of forensics tasks that are not IT-security related, but still could be assisted via software. Rather than going back and forth about concepts, I might as well just describe how I would organize what you have now: network-debugging - Network Analysis Tools - Tools for analyzing and securing computer networks. (This would include the packages from both your proposed 'reconnaissance' and 'wireless' groups, as well as some other tools currently in 'System Tools'.) Imho most of these tools are more helpful to demonstrate security weaknesses, than to debug faulty networks. E.g. it is imho more reliable to run tcpdump on a host or to plugin a seperate hub, then to use ettercap to get to analyse the traffic in the network. Most of the tools are imho primarly useful to perform a penetration test and to demonstrate the security vulnerabilities for a customer. But in general a network-debugging group would be useful, too. forensics - Computer Forensic Tools - Tools for performing computer forensics and data recovery. (I'd move the password tools here, as well. Not sure how clamav fits here; I think its current placement at the mail server level makes more sense.) Password recovery tools do not really fit into the forensics group, too. If forensics are performed to analyse a security incidense, one normally does not need to recover passwords to get a timeline of what happened. It might be used as an interem step in forensics performed by the police to get to e.g. acquire the password of a encrypted volume, but then it would still not be the primary target of the forensic actions. The intrusion detection group looks OK as a concept. As for the code analysis group, I'd argue that should be moved into the development category. Is this something you'd find usable? It is more usable for me to have these groups than not to have these. But if I cannot easily install all these related groups, i.e. with one simple command, without the need to memorize all the separate groups, it is not useful enough for me, to put much work into it. Right now our toplevel groups are: - Language support (self explanatory) - Desktops (fairly self explanatory) - Applications (End-user desktop applications) - Development (tools for software development) - Servers (various system services) - Base system (administration tools, and other components) Perhaps a better solution is a new toplevel category of 'System Administration' (where most of your new groups would fall under); this widens the scope of it from just 'IT Security' to a larger scope that fits the existing categories. That might be a larger reorganization, though, as the group changes would have to filter down to the various spins. This sounds sane in general. - the 'all packages are default' paradigm I could accept to make packages not default that are e.g. already meant to be deprecated by upstream, like airsnort. But I do not think that the audience of these tools would only want to be presented some random password cracker like it is a guideline to have only one IM client on the Fedora Desktop live image. This is also reflected with the package set of the security live image, which also contains all these tools and not only selected ones. Sure, but the live spin can do %group --optional to pull those in. To expand on what I said before, we have three main concepts for applying defaults in comps: - Lots of tools that occupy the same usage case (office tools, etc.) Pick one best-of-breed default, the rest are optional. - Lots of tools that occupy the same space, but are not interchangable. (games) Everything's optional. Pick what you want. - A basic usage case, with various add-ons and similar tools. (many of the server groups, 'system tools', etc.) A base set that's default; other tools are optional. Imho it is not that easy to apply this to security analysis. E.g. it is clear what one wants to do more or less with office tools: Writing documents. Then it does not matter that much, whether the GUI is developed for KDE or Gnome. But for a security analysis work, everything depends on the target network or system. It may and will normally differ in a lot of ways. Also since the tools may produce different results (e.g. forensic analysis tools), one would more likely use every tool to get as much results as possible, instead of only acquiring a subset of the available information. So to be prepared for these tasks, one needs more or less
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote: On 08/06/2009 09:33 PM, Till Maas wrote: currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. I'd prefer this system to be kept opt-in, because I think Do I understand it corretly, that if you won't get any false bug reports, then you don't have any objection? a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. I am not sure what's the problem you are seeing here. Maybe it was a bad use of the word opt-out. If the monitoring system does not check a package, the maintainer obviously does not need to opt out, but also it does not create any more problems. Or what are the cases you are referring to? b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? I plan to handle it on a case to case basis, e.g. either make the version comparison work or ignore the package. Also the data source that can might be added, already normalises the data for the affected packages. Currently the monitoring system supports some rc/pre releases and checks whether or not the upstream version can be found in the CVS sources file to avoid bogus bug reports. If you have some ideas, which versions may cause problems, please provide some examples. I will then add them to the unittests and see, how well they are handled. For this I need at least one upstream version, one rpm version/release pair and an expected result (which should be newer or are both the same). c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some more or less unstable URL-redirection. How do you want to hangle this? The options are to ignore the package or to update the URL when they change. Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. alarm bell ring/ Website? == yet more bureaucracy I don't get how you might even expect more bureaucracy from some status website. What do you think this website might be? It will not require anybody to look at it, but provide the information to interested people. Regards Till pgpK7apk6pFgO.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 06, 2009 at 11:27:23PM -0500, Eric Sandeen wrote: Speaking just for myself, I'd be happy to have it automatic for my packages. But wow, who's going to key in all those regexps and keep it up to date? On source of normalized data is Oswatershed[0]. My long time vision would be to manage this data in a central place like there and to coordinate the management of the data also with other distributions. Regards Till [0]http://oswatershed.org/ pgpPyKFWKRLu2.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 10:56:03AM +0200, Pierre-Yves wrote: It remembers me a website made by Remi[1] which list for all the package available, for all the branch what version are in the repo. It also provides comparison between upstream and repo for some packages such as the PECL, PEAR and R packages. [1] http://rpms.famillecollet.com/rpmphp/ Thx, I added it to the list of these kind of projects: https://fedoraproject.org/wiki/Upstream_Release_Monitoring#Related_Projects Regards Till pgpD31DcmBk4k.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 06, 2009 at 10:21:20PM -0800, Jeff Spaleta wrote: On Thu, Aug 6, 2009 at 10:11 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: I would prefer the system to be opt-out. For completely new maintainers or anyone maintaining more than a few packages, it certainly is very useful to get notification via bugzilla about new upstream releases. Err, uhm...I'd rather not see bugzilla overloaded with this sort of notification. But I would LOVE to see this integrated as notification information into the Fedora Community portal concept. Fedora Community portal integration would be a good thing, but bugs may still be needed, e.g. if a package update depends on something else: Recently there was some latex breakage iirc that prevented a an update of some package to happen. Nowadays this is solved with blocking on the other bug report. For this to work with the portal, it probably also needs advanced bugzilla skills and it would be nice to have portal support in bugzilla. Is there something like python-fedora to create notifications within the portal? Regards Till pgptGzw3717WJ.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 12:28:50PM +0200, Ralf Corsepius wrote: On 08/07/2009 10:48 AM, Till Maas wrote: On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote: On 08/06/2009 09:33 PM, Till Maas wrote: currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. I'd prefer this system to be kept opt-in, because I think Do I understand it corretly, that if you won't get any false bug reports, then you don't have any objection? Correct. Such a system may be useful for some people and applicable to some cases, therefore I don't see many reasons why people in such situations shouldn't be using it (== opt-in). The question is, wether there are more people benefiting from it than are are being disturbed by it. If more people are benefiting, then imho opt-out is ok, if not, then it should be opt-in. But I am mainly interested in whether people are disturbed by such bug reportes, even if the bug report is valid, i.e. if the package really has a newer upstream version available. a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. I am not sure what's the problem you are seeing here. Package maintainers (e.g. me) are not interested in more Fedora bureaucracy nor in having to cope with yet another system (besides bugzilla, trac, kojo, bodhi, packagedb, cvs, repos, steering organs (FPB, FESCO, FPC, Fedora committee de jour etc.). Nobody will be forced to use it and opting-out would be less work then writing this mail btw. But don't worry. In case there will be a consesus to make this opt-out, I will add you myself to the blacklist, so you won't be bothered. Maybe it was a bad use of the word opt-out. If the monitoring system does not check a package, the maintainer obviously does not need to opt out, but also it does not create any more problems. Or what are the cases you are referring to? I sense a miscommunication. As I understood your mail and [0], you are offering a service, maintainers can opt-in to use. Now you would like to make your service the default (== opt-out) and are asking for opinions. Did I misunderstand? No, but I did not understand A system _can_ only be made opt-out, if... Do you maybe mean should instead of can there? But there is also the restriction that the service will only be provided in cases where I do not expect bogus bug reports, so there may be still be packages that are not yet monitored. The opt-in/out mainly addresses of whether or not accurate bug reports should filed automatically. b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? I plan to handle it on a case to case basis, e.g. either make the version comparison work or ignore the package. Also the data source that can might be added, already normalises the data for the affected packages. Currently the monitoring system supports some rc/pre releases and checks whether or not the upstream version can be found in the CVS sources file to avoid bogus bug reports. I am not sure if this can ever be achieved, because there exist many varients of versioning schemes and because it's not uncommon for upstreams switch between several. If you have some ideas, which versions may cause problems, please provide some examples. Some classic cases: * 1.2pre .. pre release , 1.2 release, 1.2a bugfix a. * 1.2a .. 1.2a release, 1.2b 1.2b release. * 1.2pre .. pre release, 1.2. release, 1.2.1 successor of 1.2 * 1.2 ... latest release, 1.3 successor of 1.2 (GNU versioning) Above are all handled correctly now, it did not yet handle 1.2pre correctly, but this could be fixed with adding a questionmark to the regex, because I expected a number after the pre. * 1.1, 1.2a, 1.2b, 1.2 (A variant of the GNU versioning, releases are using numerical versions, versions with suffix a,b,c... are prereleases) These are not handled correctly, i.e. from this list of versions it is not possible to determine the latest version. But since there won't be any new pre-releases after 1.2 was released, it would currently result in 1.2 being silently ignored if the system would have reported all other releases. If there is a way to only get the latest release using the regex, e.g. because upstream publishes something like the latest release
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 06, 2009 at 09:33:06PM +0200, Till Maas wrote: Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. It was decided on todays FeSCO meeting, that the service will stay to be opt-in. The full discussion is available at: http://meetbot.fedoraproject.org/fedora-meeting/2009-08-07/fedora-meeting.2009-08-07-17.00.log.html#l-296 Eventually, it will become possible to opt-in as a packager and not only with some package. Then for every package that the service can monitor, you will receive notifications. Regards Till pgp0K7NOYN5YE.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Fri, Aug 07, 2009 at 10:56:10AM -0400, Bill Nottingham wrote: - BZ seems the wrong place. It's the only push mechanism we have other than raw e-mail, though. Pushing messages to maintainers is not the only necessary feature. The maintainers also need to be able to easily coordinate who will work on this or comment why this update won't take place or is delayed, e.g. because of bugs in other packages or missing dependencies. - Not to generalize too much, but we have maintainers: - who maintain only a few packages Likely, these people are already plugged into their upstreams and don't need the extra notification. Or they are not that well organised, that they may not notice upstream features. If the request was not declined, I was about to gather some statistics for the currently monitored packages, but this is moot now. - who maintain a lot of packages (woo, 100 perl modules) These people are more likely to need it. Or they have already their procedures to do this. Who knows? Nevertheless, both do not provide a public interace that can be consumed by other people than the package maintainers. Regards Till pgp9ldJmwDPv8.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bugzilla bot account / Fedora mail alias
On Fri, Jul 17, 2009 at 11:51:41AM -0500, matt_dom...@dell.com wrote: My FTBFS bugzilla account is in the 'editbugs' group in bugzilla so it can set the blocked/dependson lists. That may also be necessary to change them to ASSIGNED. You have to first file the bug as NEW, then modify it to be ASSIGNED (and set nomail=1 to avoid sending the mail on this act). It is now possible to directly create bugs with state ASSIGNED: https://bugzilla.redhat.com/show_bug.cgi?id=516208 Regards Till pgpnWSvuz3Vtw.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 01:24:24PM -0400, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. No, it's not just in the description. These tools can be used to perform IT security related wireless auditing. In this example, IT security related (aside from missing a hyphen or two) is completely superfluous. 1) It is not a prefix in the description 2) It does not allow easy selection of the packages, which was the feature you said that it allows to have and which is the necessary context you removed: | I'm not sure they need to be bundled. Especially with 'IT' as a | prefix; 3) The description will be translated / meant to be human readable and not to be a machine readible property. I don't understand what you want to say with password recovery is password recovery. There is nothing to argue about, but nevertheles the groups are related to each other, How so? aide is not really related to password recovery at all, at least not in any generally describable way. So the assignement of tools to the groups can be improved. Does this make the groups useless? I say no, there I don't see how this does belong to this general discussion about whether or not there should be these groups in comps. already expresses itself that they are all on the security spin. Also it allows other people to easier ignore them, instead of cluttering other categories. Put it this way: - These packages are all in other groups under 'Base System' - Ergo, if they're being grouped together, the resulting group should still be under 'Base System' It is not technically possible to have subgroups, as you can see in the answer from Jesse Keating. Tagging would help with this; as it stands now, 'yum search wireless' or 'yum search wireless sniffer' would return the packages in your wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. Yes, but is there an easy search expression that will result with the groups that I added? Afaik no. Does 'yum search wireless' returns 43 lines of packages, so it does not qualify. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Everyone on a multi user system can use the tool of his preference. ... So, the goal of this is for a multi-user forensic system, where you have multiple users working on the same system su-ing to root and running the tools of their choice? That's an odd usage case to design for by default. Afaics I did not mention the forensics group. I can't answer your questions if you refer to different groups with the group and then argue against the answer using some other group. The forensics group had 15 packages in it if I counted correclty and e.g. pdfresurect and chkrootkit are completely different applications. But how does searching for good or bad examples help here? Also there may be a feature in one application, that is missing in another. Then fix one app so that it's reasonable enough. To quote Adam Jackson: In reality, one does not very often have the time to first fix a bug, before a task can be completed. So this does not help me right now if I need to perform a task. Nevertheles the fixing can still be done later. Choice is not the goal. We have many interesting problems to solve and forcing the user to care about their choice of solutions is both bad UI and actively detracts from the real goal, which is making it work out of the box and enabling people to work on the really cool stuff at the edges. I do not know users who prefer to wait several days to months to perform a task with one application instead of doing it with another application. Especially not if the need to perform the task right now. In comps, in most any group, the default item is the best-of-breed app; other implementations are optional. I see, comps is not the right place to implement the feature that fulfills my need. Btw. I fail to understand what trouble this is causing you. Thanks to bundling all together into one category, it will even disturb you less than six (or more) groups in some other category, where the stuff you are interested is. It's about not presenting bad UI and bad groups to our users - it's a design thing. I do not agree that my groups are bad or that they are bad by their nature. Nevertheless, I do not see that this discussion is leading anywhere, that will allow to fulfill my needs (Easy installation of the software, easy finding of the software, allowing many people to do this and not maintaining the same information in several places) and your requests. Also it looks for me that you do not want these groups at any cost, because of the way you argue. In conclusion I have reverted the IT-security related changes
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 12:24:18PM +0530, Rahul Sundaram wrote: On 08/06/2009 02:37 AM, Till Maas wrote: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. That's not true. yum -v grouplist will display them. I use them all the time as a shorter form of the full group names. Something like # yum install @xfce-desktop Thanks, this is very helpful. Regards Till pgpmNwQUbTxST.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Hiyas, currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. It might be easily possible in the future to monitor a bunch more packages and create bugs in case there are newer versions available at upstream. Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. Regards Till [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring pgpbOvtHTy8yY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 03:21:41PM -0400, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. No, it's not just in the description. These tools can be used to perform IT security related wireless auditing. In this example, IT security related (aside from missing a hyphen or two) is completely superfluous. 1) It is not a prefix in the description 2) It does not allow easy selection of the packages, which was the feature you said that it allows to have and which is the necessary context you removed: | I'm not sure they need to be bundled. Especially with 'IT' as a | prefix; Sorry, I should have expanded. It's bad to use the acronym at all. I don't understand what you want to say with password recovery is password recovery. There is nothing to argue about, but nevertheles the groups are related to each other, How so? aide is not really related to password recovery at all, at least not in any generally describable way. So the assignement of tools to the groups can be improved. Does this make the groups useless? I say no, there I don't see how this does belong to this general discussion about whether or not there should be these groups in comps. You're stating that IT should be in the description as the groups are 'related'. I don't see how they're really that strongly related at all, and IT is superfluous information to the use case. No, I did not state that, but maybe it was not obvious. I stated that the groups should be put together. I agree that the IT security is not needed in the password tools description and that the typo should be fixed, it the term is used. I fail to understand why you think they are not strongly related, they existence of the security spin proves that they are imho. I considered IT might be redundant information, too, when I created the groups, but also both the terms Forensics or Wireless are not IT specific, therefore I put the IT-security explanation into the description. There can be wireless analysis that is not security related, e.g. to find sources of disturbance and there are a lot of forensics tasks that are not IT-security related, but still could be assisted via software. But I do not care that much to keep the term in the description, this was just my motivation to put it there. already expresses itself that they are all on the security spin. Also it allows other people to easier ignore them, instead of cluttering other categories. Put it this way: - These packages are all in other groups under 'Base System' - Ergo, if they're being grouped together, the resulting group should still be under 'Base System' It is not technically possible to have subgroups, as you can see in the answer from Jesse Keating. Additional groups under Base System, not sub-sub-groups. This is no solution to grouping the packages together and still be able to know which packages are for which sub group of tasks. Btw. these tools to also not build a base system or at least what I would think of a base system, because their use case is for certain special tasks and does not form a base for other tools to build on, e.g. cron performs a base set of features that can be used by other packages. But this might not the criteria for packages in the base system category. Tagging would help with this; as it stands now, 'yum search wireless' or 'yum search wireless sniffer' would return the packages in your wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. Yes, but is there an easy search expression that will result with the groups that I added? Afaik no. Does 'yum search wireless' returns 43 lines of packages, so it does not qualify. # yum search wireless sniffer Loaded plugins: refresh-packagekit, verify == Matched: sniffer, wireless == aircrack-ng.x86_64 : 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker kismet.x86_64 : WLAN detector, sniffer and IDS kismet-extras.x86_64 : Non-core programs for 'kismet' I am impressed, I believe to have worse search experiences with yum search. Nevertheless, airsnort is missing there, but on the other hand kismet-extras is maybe missing in comps. But I do not currently know whether or not comps is subpackage aware. My objections are: - the use of a toplevel category (they should be under the existing categories) This is addressed in my new proposal, they would be in no category or can be in any existing category. - the excessive use of IT-security most everywhere, when it's not needed I'm fine with removing it from the description, but I would like to keep this or only security as a common prefix. - the potential explosion of small groups
Re: New facility to request tagging actions
On Tue, Aug 04, 2009 at 09:35:28PM -0700, Jesse Keating wrote: This will function much like the 'update' target, it will prompt you to edit a file to fill in the target and a description of your change. It will use a cli tool (fedora-hosted) to file a ticket in the rel-eng trac for you, and you should receive an email with the results of the filing. This is a cool feature. +# Description of your tag request\n\ +notes=Here is where you give a description of what you want to change,\n\ +rational for why the change is important enough to break the freeze,\n\ +impact of not accepting the change, and what testing has been done.\ +Or if this is a tag request for updates, just the info about the updates.\ I did not yet try it out, but there is some information missing: tag requests are also needed for buildroot overrides and not only to break a freeze. + $(FEDORAHOSTED) -u $(USER) -P rel-eng new-ticket -s \ + Tag request $(NAME)-$(VERSION)-$(RELEASE) for $$target \ + -d $$descript; \ You might want to check whether or not this is a EPEL branch and set the component to EPEL for EPEL tag requests. Regards Till pgpFamHKrAnwb.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Wed, Aug 05, 2009 at 10:00:24AM -0400, Bill Nottingham wrote: Recently, you've added the following groups to comps: it-security-code-analysis it-security-forensics it-security-intrusion-detection it-security-reconnaissance it-security-wireless it-security-password-recovery You've also added a new toplevel category. This means this new nebulous 'IT Securty' item is pushed at the toplevel, much as 'Desktops' or 'Language Support'. That seems misplaced to me. How can I bundle the groups, if not with a category? Or can there be subcategories? While I know that we do allow some discretion in adding to comps, none of this was discussed beforehand on this list (that I saw), or in FESCo. These sorts of large scale changes are the sorts of things that should be discussed. I asked on this list and got a reply from Jesse Keating: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02292.html What is the overall goal of these changes? The goal is to make it easier to find software related to specific IT security related tasks. Why isn't this just done via a menus package in the security spin? Wouldn't that be more useful? No, because this does not help me with my search from yum. Btw. this is true for other package groups, too. E.g. we have a KDE spin and a KDE group in comps. Many of these packages are *already* in other groups; having them now be explicitly listed in multiple groups doesn't really make sense to me, especially when we already have 'Administration Tools' and 'System Tools' groups. I believe the restriction that packages may only belong to one group is gone. I don't see why it is not helpful to be easily able to install these related packages. Regards Till pgpA7FGLA0KUM.pgp Description: PGP signature -- 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-07-31
On Fri, Jul 31, 2009 at 12:44:52PM -0700, Jesse Keating wrote: On Sat, 2009-08-01 at 00:58 +0530, Rahul Sundaram wrote: I don't think anybody is going to argue that extracting source from srpm or pulling tarball + patches from our package cvs is ideal. So I don't see why we should continue have a lame exception. Yeah, it's not idea. They should just pull it from our upstream source repo by the tag we apply when we make the release we package. Then they're much better setup to provide patches back to us in a preferred manner. Lets start moving beyond the tarball crap. Is there already support for this in rpmbuild? Can I use a SCM url as Source0 in spec files? This would be off course very useful. Regards Till pgphQsA1bfMpv.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Tue, Jul 28, 2009 at 01:54:20PM -0700, Toshio Kuratomi wrote: It was in my post to the last thread:: Is someone in a position to verify whether setting security flags on a bug prevents someone who would be put in the CC list by the default cc attribute would or would not let people see those bugs? Is someone in a position to tell me if watching a person in bugzilla would also let you violate this? I think people are generally amenable to autoapproving CC to watchbugzilla as long as security bugs do not send updates out to random people who have signed up to be CC'd. Knowing just how security bugs work allows us to evaluate what the risks are. How about just test this? Is the following what to think may cause trouble? 1) Security bug 12345 against package foo is created 2) Alice requests watchbugzilla for package foo 3) Alice can now watch bug 12345 We can test this with this bug I marked as security sensitive: https://bugzilla.redhat.com/show_bug.cgi?id=472110 You can now apply for watchbugzilla here: https://admin.fedoraproject.org/pkgdb/packages/name/pam_mount According to the Bugzilla docs, only people that are already on the CC list can access restricted bugs, and this can also be disabled: http://www.bugzilla.org/docs/tip/en/html/groups.html | By default, bugs can also be seen by the Assignee, the Reporter, and by | everyone on the CC List, regardless of whether or not the bug would | typically be viewable by them. Visibility to the Reporter and CC List | can be overridden (on a per-bug basis) by bringing up the bug, finding | the section that starts with Users in the roles selected below... and | un-checking the box next to either 'Reporter' or 'CC List' (or both). Regards Till -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Wed, Jul 29, 2009 at 06:30:27AM -0700, Toshio Kuratomi wrote: Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. I created https://bugzilla.redhat.com/show_bug.cgi?id=514518 According to bugzilla, you did not receive any mails, but only security-response-team@ rh.. Regards Till pgpkucXsdtMK9.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFE] Auto-approve watchcommits and watchbugzilla in Pkgdb (2nd try)
On Wed, Jul 29, 2009 at 07:12:00AM -0700, Toshio Kuratomi wrote: On 07/29/2009 07:05 AM, Till Maas wrote: On Wed, Jul 29, 2009 at 06:30:27AM -0700, Toshio Kuratomi wrote: Is the same thing true of watching a person? till, I'm now watching till-opensource.name, if you want to open a new security bug and see if I get CC'd. I created https://bugzilla.redhat.com/show_bug.cgi?id=514518 According to bugzilla, you did not receive any mails, but only security-response-team@ rh.. Confirmed. So autoapproving watchbugzilla would open up security bugs in a way that watching a person does not. According to Tomas Hoger, who replied to the bug, creating a security sensitive bug also skips initialccs, therefore there seems to be no security issue at all with autoapproving watchbugzilla in reality afaics. I also oberserved that I was not added to the CC list of the bug, which would be the default beheaviour. Regards Till pgpbri2UiUP4Y.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning glade2
On Wed, Jul 29, 2009 at 08:41:49PM -0400, Matthias Clasen wrote: I'm going to orphan glade2. glade3 is the only actively maintained version of glade, and I don't see a reason to keep glade2 around any longer. You should probably retire glade2 if nobody rejects. For more information look at this page: https://fedoraproject.org/wiki/Retired_packages Regards Till pgpiyad8clALY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/kmess/F-11 kmess.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Wed, Jul 29, 2009 at 06:36:42PM -0500, Jason L Tibbitts III wrote: SMP == Steven M Parrish tuxbr...@fedoraproject.org writes: SMP Summary: A MSN Messenger Clone Please don't build a package with this summary. Please explain why. Regards Till pgpkbPjcHnHO3.pgp Description: PGP signature -- 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-07-24
On Fri July 24 2009, Jon Stanley wrote: Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2 009-07-24-16.59.log.html 17:01:18 jds2001 #topic No frozen rawhide proposal 17:01:22 jds2001 .fesco 224 17:01:25 * jwb is here 17:01:41 * nirik goes to look over the page again 17:01:51 * skvidal is here 17:02:20 * dgilmore is here but needs to leave in 30 minutes 17:02:27 * j-rod in and out for a sec... 17:02:59 nirik f13: so, bits go to 12/Everything at branch time. Is The log seems to be incomplete, e.g. after the .fesco 224 line, there should probably be some line by zodbot(?) that presents a URL to the ticket or some other information about it. Regards Till 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: Packages tracked by FEver that need to be updated
On Sat July 18 2009, Caolán McNamara wrote: FWIW I stuck my own dubious hacky little script I use to keep track of the latest versions of packages I maintain, which include a lot of painfully upstream sequenced packages at http://people.redhat.com/caolanm/latestpackages/ if it helps anyone. It looks interesting, especially the advanced support to define search patterns. I created a new section to store pointers to projects of this kind at: https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes#Related_Projects Regards Till 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: Bugzilla bot account / Fedora mail alias
On Fri July 17 2009, Toshio Kuratomi wrote: So I guess I need a seperate FAS account for this and apply for fedorabugs or is there some other way to do this? The ftbfs bugzilla account is capable of changing the status iirc. Okay, I've taken care of this in FAS. It should sync to bugzilla within the hour. If not, let me know. According to the bugzilla preferences[0], the upstream-release-monitoring account still does not have any permissions. Regards Till [0] https://bugzilla.redhat.com/userprefs.cgi?tab=permissions signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Bugzilla bot account / Fedora mail alias
On Tue July 14 2009, Jon Stanley wrote: Also, have you filed an RFR to get this hosted in Fedora? Afaics[0] I need a sponsor to get it hosted in Fedora. Can and will you be the sponsor? Regards Till [0] https://fedoraproject.org/wiki/Infrastructure/RFR signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Bugzilla bot account / Fedora mail alias
On Fri July 17 2009, Toshio Kuratomi wrote: So I guess I need a seperate FAS account for this and apply for fedorabugs or is there some other way to do this? The ftbfs bugzilla account is capable of changing the status iirc. Okay, I've taken care of this in FAS. It should sync to bugzilla within the hour. If not, let me know. I just checked again and the permissions are now there. Strangely it is still not possible to create new bugs with status ASSIGNED. It now returns an exception: Fault 32000: 'You are not allowed to file new bugs with the\n ASSIGNED status.' Previously it was silently ignored. Setting them to ASSIGNED afterwards is now possible and also reporting them with the FutureFeature keyword. Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Packages tracked by FEver that need to be updated
On Fri July 17 2009, Rahul Sundaram wrote: On 07/16/2009 11:22 PM, Till Maas wrote: It would be useful to have a dynamically generated webpage that shows how close we are to upstream versions across different Fedora versions similar to the distrowatch packages page. A static webpage that is regenerated every now and then should be easy enough, that I might create it. On my blog the project leader of http://oswatershed.org/ mentioned his project, which is something similiar for different distributions, but it currently does not show any packages for Fedora. Maybe allow package maintainers to add in comments indicating what their plans are, even. For example, if a update is going to break the ABI in a intrusive way (let's say XULRunner) or change the configuration file format (nagios), I as a package maintainer would like to convey that information to my users so they know why I haven't pushed an update despite new features or even minor bug fixes. The bug report could be linked on the page and then the maintainer can use it for this. This should also then be easily doable. Regards Till 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: Bugzilla bot account / Fedora mail alias
On Tue July 14 2009, Jon Stanley wrote: On Tue, Jul 14, 2009 at 5:08 PM, Till Maasopensou...@till.name wrote: How about the alias upstream-release-monitoring? Please forward it to cnucnu.fedora till name with '@' and '.' added. I'd personally prefer to make a mailing list for this, rather than put the point of failure on a single person (again). Btw. I just remembered which bot bugzilla account already exists: ftbfs - https://admin.fedoraproject.org/accounts/user/view/ftbfs There seems to be no mailing list involved, too. Nevertheless, what is the next step for this? Has this to be discussed on some meeting or should I file a ticket somewhere? Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Bugzilla bot account / Fedora mail alias
On Fri July 17 2009, Matt Domsch wrote: On Fri, Jul 17, 2009 at 08:42:53AM -0400, Jon Stanley wrote: The alias is created - it's just a mail alias, not a full FAS account. You'll have to make a Bugzilla account with that mail address, and that's it! :). It may take up to 30 minutes to be live, though. The trick is, you can't create a bugzilla account with @fedoraproject.org directly for some reason. Maybe this is fixed. I had to create a bugzilla account with another email address, then request of the bugzilla administrators to change the email address for the account. Thank you both, I'll report back, whether or not it worked. Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Bugzilla bot account / Fedora mail alias
On Fri July 17 2009, Ricky Zhou wrote: On 2009-07-17 07:48:34 AM, Matt Domsch wrote: The trick is, you can't create a bugzilla account with @fedoraproject.org directly for some reason. Maybe this is fixed. I had to create a bugzilla account with another email address, then request of the bugzilla administrators to change the email address for the account. Hi, are you talking about a restriction in bugzilla, or the current limitation where FAS doesn't assign bugzilla permissions to accounts that don't match the email address given in FAS? If it's the former, hopefully that's fixed now - I think I've created an @fedoraproject.org account once at some point in the past 2 years or so I was able to create the bugzilla account using the @fpo address. Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Bugzilla bot account / Fedora mail alias
On Fri July 17 2009, Jon Stanley wrote: On Fri, Jul 17, 2009 at 3:44 AM, Till Maasopensou...@till.name wrote: Btw. I just remembered which bot bugzilla account already exists: ftbfs - https://admin.fedoraproject.org/accounts/user/view/ftbfs There seems to be no mailing list involved, too. Nah, I don't much care if no one cares to see the mail. ftbfs goes to /dev/null pretty much (actually to ft...@domsch.com). I can create the requested alias, and you can create a bugzilla account with it. It needs no special permissions to file bugs (which is all it should be doing). Unfortunately I seem to need some special permissions, because I would like to file the bugs with status ASSIGNED and with Keywords FutureFeature, because this is what the triage SIG wanted for the old FEVer bugs. If I try to set the status from NEW to ASSGINED after the bug is created, I get an error that the account does not have the necessary permissions. I also specified both when I created the bug, but both were silently not set. The first bug I created is: https://bugzilla.redhat.com/show_bug.cgi?id=512384 So I guess I need a seperate FAS account for this and apply for fedorabugs or is there some other way to do this? The ftbfs bugzilla account is capable of changing the status iirc. Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Packages tracked by FEver that need to be updated
On Saturday 11 July 2009 13:29:59 Rakesh Pandit wrote: Thanks for nice work. I too mailed other some time back .. but did not recieved any mail back. May you share the program ;) My current code is available at http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=summary But don't be disappointed, because it does not yet do very much. Regards Till 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: Bugzilla bot account / Fedora mail alias
On Tue July 14 2009, Jon Stanley wrote: On Tue, Jul 14, 2009 at 5:08 PM, Till Maasopensou...@till.name wrote: How about the alias upstream-release-monitoring? Please forward it to cnucnu.fedora till name with '@' and '.' added. I'd personally prefer to make a mailing list for this, rather than put the point of failure on a single person (again). If it really makes sense, why not. But I do not see any advantages in this. If I become MIA, then someone from Fedora Infrastructure can just change the target of the alias to get the e-mail addresses, that are send there. Nevertheless I am not quite sure, if someone even needs to receive these e- mails, because they are probably only bugzilla notification mails. In case there is an mailinglist, then it needs to be made sure that only trusted people can join it, because they all can recover the bugzilla password. Also, have you filed an RFR to get this hosted in Fedora? I do not yet have anything ready that can be hosted. Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: epel-release in Fedora repos?
On Tue July 14 2009, Jason L Tibbitts III wrote: JK == Jesse Keating jkeat...@redhat.com writes: JK At 7000+ srpms there is no way I could evaluate each and every one JK for validity before submitting it for a rebuild. I think the point is that the package owner should have deleted it from devel so that there would be nothing for rel-eng to rebuild. Imho if the devel branch is a problem, then it should not be created when the package is imported to CVS, if it is a epel-only package. Requesting such strange actions from package maintainers who may not know all the magic behind the build system will only lead to errors like this one. Regards Till 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: epel-release in Fedora repos?
On Tue July 14 2009, Josh Boyer wrote: You have a valid point. I'm not sure if the cvs scripts or pkgdb can currently cope with that though. If you have the time to look into it, I'm sure it would be appreciated. Do you know which script parses the cvs requests and generates the module(?)? The easiest (workaround) way to do it woul probably be just to run cvs rm -f devel right after it was created by the script. If it works when the maintainer does it, it should also work when a cvs-admin does it. :-) Regards Till 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: Packages tracked by FEver that need to be updated
On Sat July 11 2009, Jon Stanley wrote: On Sat, Jul 11, 2009 at 12:25 PM, Till Maasopensou...@till.name wrote: Probably and afaik the original author also planned to do so. Unluckily the code that handled the bugzilla tickets is afaik not publicly available, therefore this needs to be rewritten. What language is it written in? Should be easy to implement using python-bugzilla assuming it's written in python. It's written in python and python-bugzilla would allow to make this easier. But afaics it does not yet allow to set the whiteboard of new bugs to FutureFeature, which is something the triage SIG would like to have. Regards Till 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: Bugzilla bot account / Fedora mail alias
Hiyas, On Tue July 14 2009, Nick Bebout wrote: What would you like the alias to be, and where would you like the email to go to? How about the alias upstream-release-monitoring? Please forward it to cnucnu.fedora till name with '@' and '.' added. Regards Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: $HOME/bin
On Mon July 13 2009, Michal Hlavinka wrote: if su (instead of su -) is used, root will inherit user's environment including PATH. So why should a malicious user be able to change the contents of ~/bin, but not set the variable PATH to an arbitrary value? Regards Till 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
Bugzilla bot account / Fedora mail alias
Hiyas, I will eventually want to use a bugzilla account for a certain service[0]. To make it easier for someone else to reclaim this account in case i vanish, I would like to use a Fedora mail alias for this. Is there some type of bot account type in FAS that I can use to create the additional mail alias or some other procedure for this? Regards Till [0] https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Packages tracked by FEver that need to be updated
On Sat July 11 2009, Kevin Kofler wrote: Till Maas wrote: mingw32-nsis2.44 207b0 Hmmm, the regex is somehow picking up something broken. The current version is actually 2.45. I should probably make it read http://nsis.sourceforge.net/Download instead. In 2005 they released a tarball named nsis-207b0-src.tar.bz2. With the other URL it works, therefore I changed it. Regards Till 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: Packages tracked by FEver that need to be updated
On Sat July 11 2009, Eric Sandeen wrote: I wonder, can FEver become part of the Fedora infrastructure, so it's not quite so bus-sensitive? Probably and afaik the original author also planned to do so. Unluckily the code that handled the bugzilla tickets is afaik not publicly available, therefore this needs to be rewritten. Regards Till 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: Packages tracked by FEver that need to be updated
On Sat July 11 2009, Rakesh Pandit wrote: Thanks for nice work. I too mailed other some time back .. but did not recieved any mail back. May you share the program ;) I'll share the program once I setup some repo for it, which will probably happen the next time I spend a reasonable amount of time on it. Regards Till 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
Packages tracked by FEver that need to be updated
Aloas, some of you added your packages to: https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes Unfortunately seems the original author of fever not to be around anymore, e.g. his fedorapeople account is removed/backed-up. Therefore I started to write a new framework to replace it. My tool is not ready to bug you via private mail or create bug reports, therefore I only post the current findings here: Outdated packages: Name Rawhide Version Upstream Version === abook 0.6.0 0.6.0pre2 aria2 1.3.1 1.5.0b+20090705 bouml 4.13 4.13.1 bouml-doc 4.3.2 4.12.4 bti 015023 bygfoot2.2.0 2.2.1 chemtool 1.6.11 1.6.12 conduit 0.3.15 0.3.16 cpl4.2.0 5.0.1 crm114 0 200904023 crossvc1.5.21.5.2-0 ctorrent 1.3.4 1.3.4-dnh3 dblatex 0.2.10 0.2.11 debootstrap 1.0.10 1.0.13 ekg2 0.20.2-rc1 emacs-auctex 11.85 11.85-e22.3-msw Falcon 0.8.14.2 0.9.2 fdupes 1.50 1.50-PR2 fio 1.24 1.31 fusecompress 2.52.6 g2clib 1.1.8 1.1.9 gajim 0.12.1 0.12.3 gengetopt 2.22.1 2.22.2 gifsicle1.52 1.55 glpk4.36 4.38 guilt 0.32 0.32.1 gxine0.5.9030.5.904 hping30.0.20051105 20051105 hplip 3.9.2 3.9.6b httrack 3.43.2 3.43-5 kdesvn 1.3.0 1.3.2 ldtp 1.3.0 1.6.0 libedit 2.113.0 libextractor 0.5.22 0.5.23 libfplll 3.0.11 3.0.12 libtlen0 20060309 lightning1.2 1.2c mimetic0.9.5 0.9.6rc2 mingw32-nsis2.44 207b0 mkvtoolnix 2.6.0 2.9.7 mysqltuner 1.0.0 1.0.0-rc1 openbabel 2.2.1 2.2.2b6-20090709-r3138 perl-HTML-Template-Pro 0.74 0.75 perl-TAP-Harness-Archive0.12 0.13 perl-Test-WWW-Selenium 1.15 1.17 perl-XML-Atom-SimpleFeed0.82 0.86 php 5.2.10 5.3.0 php-pear-DB 1.7.13 1.7.14RC1 php-pecl-apc 3.0.19 3.1.2 python-sphinx 0.6.1 0.6.2 rapidsvn 0.9.8 0.9.8/ sextractor 2.5.0 2.8.6 sonata 1.5.2 1.6.2 sundials 2.3.0 2.4.0 tesseract 2.03 2.04 tor 0.2.0.34 0.2.0.35 tre0.7.5 0.7.6 uncrustify 0.52 0.53 valknut0.4.9 9 varconf0.6.5 0.6.6 warzone21002.1.2 2.2.1 wgrib21.7.8g 1.7.8j wormux 0.8.3 0.8.4 xchm1.14 1.17 xcb-util 0.3.4 0.3.5 Packages new in Rawhide than at upstream (may indicate outdated FEver URL) Name Rawhide Version Upstream Version === a2ps4.14 4.13 aircrack-ng 1.0 0.9.3 anjuta 2.26.1.0 2.25.903.0 centerim 4.22.7 4.22.6 cups 1.4 1.3.9 ekg 1.81.7 giggle0.4.910.4 glade3 3.6.7 3.6.0 inkscape0.47 0.46 kile 2.1 2.0.3 libgdl2.26.0 0.7.11 milter-greylist4.2.2 2.1.12 monotone0.440.9 opencdk0.6.6 0.6.0 pyicq-t 0.8.1.3 0.8b python-mutagen 1.16 1.15 strigi 0.6.5 0.5.11 sunbird 1.00.8 swing-layout 1.0.3 1 up-imapproxy 1.2.7 1.2.6 xalan-c 1.10.0 1.10 xmlrpc-c 1.16.61.06.35 Packages that could not be checked because of
hall monitor / moderation policies (was: Re: an update to automake-1.11?)
On Thu July 9 2009, Tom spot Callaway wrote: Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the hall monitor/moderation policies. Is the policy documented somewhere? I only found a meeting summary, which imho does not qualify as proper documentation: http://fedoraproject.org/wiki/Board/Meetings/2009-05-14 Regards Till 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: prelink: is it worth it?
On Thu July 9 2009, yersinia wrote: But something one have to pay a security prize on not disabling it : it render impossible to have a centralizzated security integrity management (e.g. rfc.sf.net for example) or one have to skip from check the prelink binary. Very bad i think. You pay a security prize if you disable prelink, because it also performs address space randomization: http://lwn.net/Articles/190139/ Btw. you can also patch the remote integrity checker to use prelink to either get a checksum of the perlinked binary or undo the prelinking before checking it. Regards Till 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: delaying an update
On Wed July 8 2009, Christoph Höger wrote: Am Mittwoch, den 08.07.2009, 17:41 +0300 schrieb Jussi Lehtola: On Wed, 2009-07-08 at 09:30 -0500, Michael Cronenworth wrote: Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? Since you have not submitted it for stable I do not see any problem. Don't do anything. :) You might want to disable the automatic push to stable, though, in case the package gets too much karma.. That's what I meant with delay. So how do I do that? You can unselect it here: https://admin.fedoraproject.org/updates/edit/offlineimap-6.1.0-2.fc11 And revoke the push request here: https://admin.fedoraproject.org/updates/revoke/offlineimap-6.1.0-2.fc11 Regards Till 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
