-----BEGIN PGP SIGNED MESSAGE-----
I am packaging rasmol.
The rasmol source has a dual GPLv2/RASMOL license, so for Fedora we can
consider that it is licensed gplv2. There are some libraries that are
included that are licensed lgpl. Clearly, the finished rasmol binary is
gplv2 since the lgpl parts are statically linked into the final binary.
The final rpm does not provide separate .so files for those embedded
I think that means that the .spec file should simply say
Is that correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
-----END PGP SIGNATURE-----
> Author: knol
> Update of /cvs/pkgs/rpms/getmail/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25409
> Added Files:
> Log Message:
> another try
> --- NEW FILE getmail-4.14.0.tar.gz ---
More important than getmail.spec not belonging in the lookaside
cache, the tarball most definitely should NOT be committed to cvs.
If you need a hand, please post here or stop by #fedora-devel or
#fedora-admin on IRC and I'm sure someone can help get you squared
away with a getmail update.
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
I could never recommend the use of drugs or alcohol to anyone, but
they've always worked for me.
-- Hunter S. Thompson
> A file has been added to the lookaside cache for getmail:
> 22e21aeb5cbf34b25326fe6a5bd5db17 getmail.spec
Just a friendly FYI, the spec file doesn't have any reason to be in
the lookaside cache, nor in sources. :)
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
The things most people want to know are usually none of their
Good evening all,
I've setup an authorized key for a server I regularly use, but when I
tried to run ssh-add as root, it wouldn't work until I had copied the
SSH_AUTH_SOCK environment variable from my normal user.
I wonder if anyone can tell me the correct way get this variable set
I can run..
which does sets the variable for me, but I don't want to put that
command in say the .bashrc, or should I???
Thanks in advance
ps. I'm using F12 X86_64
I package GrNotify but the project is dead. I have reported some bug
to upstream and I have proposed some patch but no new release since 9
months. I think remove it from Fedora but I don't know any replacement
That do you think about this ?
Jabber/Gtalk : llaumgui(a)gmail.com
Hi, guys. Just a quick note - Matej Cepl pointed out that the
already-agreed BugZappers plan to switch to using the Triaged keyword
only for Fedora 13 and later presents problems. Most significantly, it's
impossible to reliably construct a Bugzilla search which will find bugs
that have been triaged under *both* the F13+ and F12- methods.
So, we've come up with a plan. With the help of David Lawrence we
propose to add the Triaged keyword to all existing F10-F12 bugs that are
in ASSIGNED state, with the exception of anaconda bugs, PackageReview
bugs and FutureFeature bugs.
No other change will be made to the bugs (they won't, for instance, be
changed back to NEW). This will be done without generating any email
notifications, so there won't be an email flood.
We can't think of any problems this could cause; some bugs that haven't
actually gone through the triage process may get marked as 'Triaged',
but that won't have any negative effects. All we really use the flag for
is searching to find which bugs need triage and which don't.
If anyone can see why this may present a big problem, please let us
know; we're holding off on the change for a day or so just in case.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
I was thinking and thought id get an idea out there.
rather than ship 2 dvds one for i386 and one for x86_64 we would ship one dvd
that has the package set for both arches. they would likely only have the
packages for a desktop install on them we would need to have both arches under
2.4GiB, you could choose your own adventure by enabling the everything repo.
this way you could carry a usb key or dvd that you can plug into any intel
based machine and be sure of having it installable. this would end the
discussions of what arch to promote we have a single install media.
syslinux would need to be able to detect the arch to install and likely also
have a flag to force 32 bit we could easily implement the 64 bit kernel and 32
bit userland idea that was put forward a few releases ago. pungi will need to
learn how to make the new iso. but i think it is achievable.
I think we should also push the netinstall.iso along with kickstarting
machines. we could make a single netinstall.iso for both arches as well. it
would make it ~375MB iso.
Alexandre Oliva wrote:
>> Yes, we may rename the Live images to i386.
> If we're going to rename directories to match base arches...
> How about using “x86_32”?
Not only does it not match uname, but it's not specific - is it i386,
i586, i686? I'd like to see the install images named i686 like the live
images are now. If the purpose of the basearch convention is to not
have to waste time making changes each time the subarch changes, it
doesn't apply here, since it's known that this particular subarch (i686)
will never change again.
Firstly, I'd like to say I think abrt is fantastic. Call what follows a
nit-pick. It's just a pretty in-your-face nit.
After installing F12, after a short while I got presented with a couple
of SELinux errors. This is nothing unusual in a new Fedora release, but
this time it asked me for my bugzilla login details and offered to
submit the bug automatically for me. Fantastic! The lazy person in me
who wants to do the right thing truly appreciates this. Turns out I
wasn't the first person report them, so it added me to the CC list.
There are, however, still 2 significant problems with this. Firstly it
needed a BZ login. I happen to have one, and I use it often enough that
I don't need a password reset every time. However, I'll bet I'm in the
minority of Fedora users. To get useful bug reports from the unwashed
masses we need anonymous submission, or at least submission which
doesn't require any kind of account creation or authentication.
Secondly, I'm now being subjected to bugzilla spam every time anybody
else does the right thing. I have received 24 bugzilla spams in the last
12 hours telling me that other people have been added to the CC list.
This information is interesting to people who want to know how to
prioritise bugs, but it's not interesting to me, the submitter. I can
remove myself from the CC list, but the lazy person in me whispers it
might just be easier not to submit bugs.
If you've used Windows, you'll be familiar with the Windows send bug
report dialog. I've once seen it additionally give me useful
information. After submission it told me a fix was available and sent me
to a web page which told me where to get an updated third-party driver.
That's what I really want to know: can I fix it?
So, turning that into some feature requests:
1. Can Fedora enable anonymous/unauthenticated bug submission.
2. Can abrt not add duplicate reports to the CC list.
3. Can abrt/Fedora please ensure that original abrt reporters don't get
4. Can abrt/Fedora track abrt submitted BZs and report only when there's
a fix available.
5. Can abrt give me a list of submitted BZs so I can browse them if I
I suspect much of this would require infrastructure changes, so it would
extend beyond abrt. However, I think this is the last mile required to
get bug reports from absolutely everybody.
 As is everybody on this list! I know you all have BZ accounts, and
know the passwords.
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490