Re: Build issue with llvm on EL6?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2014 10:31 PM, Dave Johansen wrote:
On Sun, Feb 2, 2014 at 7:58 PM, Dave Johansen
davejohan...@gmail.com mailto:davejohan...@gmail.com wrote:
The EL6 build of llvm 3.4 is currently in testing and it was just
pointed out that there's a potential issue with the build (
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0264/llvm-3.4-5.el6
).
If you examine the build.log (
http://kojipkgs.fedoraproject.org//work/tasks/593/6470593/build.log
) It looks like the include path is being included twice and that's
causing the warning about the invalid host type. Is there
something wrong with the .spec file? Or is there something I can do
to fix/prevent this issue?
Thanks, Dave
I was able to get a hold of the original submitter of the issue and
the issue is because of the multiple paths that exist on EL6.
Here's his explanation and recommended solution:
$ echo /usr/lib/gcc/x86_64*/*/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
EL6 originally had gcc-4.4.4 and gcc-4-4.7 still has the old
path
included for compatibility. Because of the space inbetween
configure thinks /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include is
a host type.
The files in /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include have
nothing to do with C++. Clang has own versions of these files in
/usr/lib/clang/3.4/include.
Therefore it should just be
--with-c-include-dirs=%{_includedir},
which is also the default if you specify nothing.
C++ headers and runtime libs from gcc are selected by clang at
runtime:
$ clang -v clang version 3.4 (tags/RELEASE_34/final) Target:
x86_64-redhat-linux-gnu Thread model: posix Found candidate GCC
installation: /usr/lib/gcc/x86_64-redhat-linux/4.4.4 Found
candidate GCC installation:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7 Selected GCC installation:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7
So my question is if the same sort of change also needs to be made
in the Fedora .spec file that the EL6 one is based on.
On Fedora there is no compatibility symlink; IIRC the
00with-c-include-dirs was added (by myself) because at the time LLVM
and Clang's detection routines were less reliable (there was a list of
GCC versions it knows about, and if the version installed is newer -
as is likely at every Fedora cycle - it breaks, unless the include
directory is manually specified)
I'm no longer routinely involved in LLVM maintenance, but agree that
it might be worth re-checking the Fedora .spec.
I'll try rebuilding Pure once the LLVM update lands - does Clang now
ship a complete set of C++ headers as well? That was a sticking point
earlier as the headers shipped by GCC in EL6 is too old for newer
versions of LLVM-targeting apps.
Best regards,
- --
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: sali...@fedoraproject.org | GPG key ID: A36A937A
Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS8fOBAAoJEEr1VKujapN6zxkIAJly8nZFv353aA6LkPOEK5Uh
qiZR0L2p0rfoaGmdw11+r24BGmmBjcZHdTpg+HS4GZxVrENF9dQYeVvVGLse6QJZ
dlJAzL7u9oJZYF4YBr9vsJy9+fP7p0T0miHj12GZG+wqhBn0UItcYimwmlVpEat7
5UWMCWzAZckZPPFqzYbVwDtjkXObMumqY5cXy7uOEeTHa1HIsoiomnL3KeHwEdiF
UHCqCsCDaAuYJy14i9U4JDC0Lt67uV/czVzstrBUN+CP7PfZZkDQvbYbPeCwrjxT
RtosUNBPQQarnoLeDkFSUwlUv0Gxpc8y75dA2ZkzachAbxRlzWmTrRVdcgqt8xw=
=yaSw
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-HTTP-BrowserDetect/epel7] (3 commits) ...Update to 1.61
Summary of changes: c73598e... Perl 5.18 rebuild (*) 75efdda... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) dd8b89e... Update to 1.61 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-DAV/epel7] (3 commits) ...Update to 0.47
Summary of changes: e8b4be3... Perl 5.18 rebuild (*) 538f55a... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 5423c80... Update to 0.47 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: New UEFI guide on the wiki
On Wed, 2014-02-05 at 01:41 -0500, David wrote: On 2/5/2014 12:52 AM, Adam Williamson wrote: On Tue, 2014-02-04 at 21:47 -0500, David wrote: On 2/4/2014 5:41 PM, Adam Williamson wrote: On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) I always enjoy these UEFI threads. Not. EfI has been a replacement-in-progress for the old BIOS for a long time. U(universal)EFI has been around a while as an upgrade for EFI. Someday, perhaps soon, BIOS will die. Which means? If Linux can not play nice with UEFI then Linux will die with BIOS. Er. What's your point? This whole thread started from a rather extensive guide to installing Fedora on UEFI which I wrote. We're now discussing rather pie-in-the-sky stuff that doesn't have much to do with what you posted. Sure it does. In a way. Whenever UEFI is mentioned there is a panic in the ranks. Windows!! Windows!! Microsoft!! Microsoft!! Which is crap. There is no real problem. You need to fix the conspiracy crap. Fix it? Or live/die with it. What? I didn't say anything about Microsoft. I opined that firmware vendors couldn't find their rear ends with two hands and a map, which isn't a particularly controversial opinion among anyone who's had to deal with their work. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2014 10:37 PM, Adam Williamson wrote: On Tue, 2014-02-04 at 10:21 +0100, Stephen Gallagher wrote: On 02/01/2014 11:07 PM, Kevin Kofler wrote: Stephen Gallagher wrote: Right now, the vision essentially looks like: Fedora Products: This *is* Fedora. It comes in three flavors. I don't like the hardcoded three there at all, because if KDE is to ever become a full-fledged Product (which IMHO it should have been from the beginning!), it will need to change (unless you're dropping one of your 3 sacred spins). Well, I thought it was clear, since I did include the words Right now, but yes: I do think that other products should be both permitted and planned. One thing I've been discussing as an option with some of the members of the KDE SIG is to promote Fedora Scientific, based on the present-day KDE and Scientific Spins, as a fourth Fedora Product. I think this would be valuable as it would also act as a prototype for what the new-product process will need to be going forward. This still seems kind of bizarre to me. Scientific Workstation is a very niche spin for a particular audience which happens to use the KDE desktop because, I dunno, the person who built the spin had to pick *some* desktop and they liked KDE more than GNOME or something. KDE is our most significant desktop spin after GNOME. If we're expanding the product set, Fedora KDE seems like a reasonable Product candidate, but smooshing it together with Scientific Workstation seems a bit bizarre. It's not just that, actually. It has to do with the fact that the majority of the scientific-focused applications are built atop the QT4 and other KDE libraries, making it much better suited to operating atop the KDE desktop environment. Certainly it *can* be run in GNOME at the cost of additional memory usage and other resources. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLx94cACgkQeiVVYja6o6NGNQCeKT3nPbjJ04q8htyShHqymZ5h Ue4AnRgzkAplJWv6KcZRAtqfA3tWHrWk =egPd -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Matthew Miller (mat...@fedoraproject.org) said: On Tue, Feb 04, 2014 at 08:48:12AM -0500, Jaroslav Reznik wrote: I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. Is there a way that isn't currently allowed actually? Spins can put anything into %post, and some do modify configuration. (If nothing else, the desktop spins change the default desktop...) And sendmail/rsyslog was one example. So yes, spin already do so. But stating this formally/documented way would be worthy. That was a particularly gray area because it's simply a matter of installing a package or not. Installing rsyslog but configuring it to log differently than the standard is another level of change (although of course also murky when other applications change their behavior based on the presence or absence of some other package). Yeah; the idea behind the guideline is that you want documentation to be generally valid, for example - if you have resources that have to say if you're on X, do A, if you're on Y, do B... it gets very unwieldy very fast, and makes it much harder for users as well. We obviously are going to have some of this with the assorted desktop spins, but imagine that level of differences spread to yum vs apt (as a theoretical bad example.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:18:27PM -0700, Chris Murphy wrote: Does anyone know why the convention is to create the ESP as the first partition? Because that's the only configuration anyone's likely to have tested. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 02:45:29PM -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 2:41 PM, Adam Williamson awill...@redhat.com wrote: You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) Not really -- I figure that either the firmware is only parsing the protective MBR (in which case the existence of an ESP won't even be detectable) or that the firmware actually supports UEFI, in which case I'd be fairly impressed if it matters. You're missing the not uncommon case of UEFI firmware with CSM forcibly enabled and no UEFI boot option which was much of the market between 2009 and 2011. These implementations will frequently understand GPT well enough to decide that a disk isn't BIOS bootable, but won't let you perform a UEFI boot instead. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Feb 05, 2014 at 10:27:44AM +0100, Bill Nottingham wrote: That was a particularly gray area because it's simply a matter of installing a package or not. Installing rsyslog but configuring it to log differently than the standard is another level of change (although of course also murky when other applications change their behavior based on the presence or absence of some other package). Yeah; the idea behind the guideline is that you want documentation to be generally valid, for example - if you have resources that have to say if you're on X, do A, if you're on Y, do B... it gets very unwieldy very fast, and makes it much harder for users as well. We obviously are going to have some of this with the assorted desktop spins, but imagine that level of differences spread to yum vs apt (as a theoretical bad example.) Agreed -- I think changes should be in proportion to the amount of separate branding the spin has. If I'm running something which configures the system in a very different way, I should *know*. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
- Original Message - bkabrda python3 amcnabb,bkabrda,mstuchli,tomspur Fixed in python3-3.3.2-9.fc21 bkabrda python bkabrda,dmalcolm,ivazquez,jsteffan,mstuchli,tomspur,tradej Fixed in python-2.7.6-2.fc21 -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
Hello, On Fri, Jan 31, 2014 at 9:23 PM, Ville Skyttä ville.sky...@iki.fi wrote: List of affected packages follows (maintainer package comaintainers): Wouldn't it be better to mass-file bugs? Yes, it's more work initially, but the work would have a larger impact (the bug would keep being tracked, unlike an e-mail that is easily forgotten, and the rest of the mailing list wouldn't have to read fixed in... mail. (I truly don't know; perhaps it really is better to do small cleanups with a simple email without worrying whether the mass-filing script will run amok. So I'm asking.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On 5 February 2014 10:20, Miloslav Trmač m...@volny.cz wrote: Wouldn't it be better to mass-file bugs? For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On 01/31/2014 09:23 PM, Ville Skyttä wrote: msuchy rhn-client-tools mzazrive Filed upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1061013 -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On Wed, Feb 05, 2014 at 11:20:15AM +0100, Miloslav Trmač wrote: Wouldn't it be better to mass-file bugs? There is a rough Guideline about mass bug filing: https://fedoraproject.org/wiki/Mass_bug_filing If not all packages are fixed after a while, the bugs can still be filed. However it is also quite annoying if a lot of bugs are filed prematurely. For example I a lot of bugs were filed for missing AArch64 support but this was something that was fixed (for most if not all packages) at RPM level and not the individual package, resulting in lots of unnecessary bugs for which nobody felt responsible closing after they became invalid. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On Wed, Feb 05, 2014 at 10:40:20AM +, Richard Hughes wrote: On 5 February 2014 10:20, Miloslav Trmač m...@volny.cz wrote: Wouldn't it be better to mass-file bugs? For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. +1 Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On Wed, Feb 5, 2014 at 11:40 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 February 2014 10:20, Miloslav Trmač m...@volny.cz wrote: Wouldn't it be better to mass-file bugs? For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. Well, yes. That (or getting an automated check so that it is fixed once for all) puts an even bigger burden on the person noticing the problem. It should be possible to just flag a problem without committing to fix it personally - with the number of packages we have, we do need to distribute the work. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On 02/05/2014 11:40 AM, Richard Hughes wrote: For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. Usually yes. But e.g. in rhn-client-tools this path is used in code and the change is non-trivial. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, Feb 5, 2014 at 4:44 AM, Florian Weimer fwei...@redhat.com wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? Fedora doesn't support 32-bit UEFI (at the moment). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 02/05/2014 01:09 PM, Josh Boyer wrote: On Wed, Feb 5, 2014 at 4:44 AM, Florian Weimer fwei...@redhat.com wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? Fedora doesn't support 32-bit UEFI (at the moment). Okay. What would be a good spot to add this to in the document? After the list in the Do I have a UEFI firmware? section? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
Miroslav Suchý msu...@redhat.com writes: On 02/05/2014 11:40 AM, Richard Hughes wrote: For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. Usually yes. But e.g. in rhn-client-tools this path is used in code and the change is non-trivial. It was similar in javapackages-tools. It included a change in documentation which would have most likely been missed by eager provenpackager and maintainers could just ignore a closed bug so this wouldn't have been fixed... Generally filing those 42 (yay, what a nice number) bugs would have been better IMO, but if you are willing to re-run that repoquery in a few months and file bugs for remaining packages I see no harm. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpXDPd_2OdUR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
May take on the Spins 1) Spins have given us a great way to show people what is in Fedora without installing 2) We have been producing Multi-Live media for several years to give out at events. 3) The multi-lives make the display machines very easy to maintain (new release wipe hd and reinstall multi-live ) 4) I personally produce updated Live isos for the community. We have seen that they do and have many times solved issues that people had installing on the original release. 5) yes Spins create a overhead as far as testing etc. but in the end run they are the best way to get a enduser to experiment to see if they like running Fedora. 6) now do i think we need spins for any group other than Workstation no -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
API Bumps for package: cogl
I've built cogl 1.17.2 in rawhide (required by clutter, in turn required by mutter, in turn required by gnome-shell) and I'm just in the process of building clutter 1.17.2 also. Due to the vast number of things that depend on cogl I'm going to need some help. At least for cogl, this is the depchain: caribou cheese-libs clutter (i've got this) clutter-gst clutter-gst2 clutter-gtk libchamplain libmash libmx media-explorer muffin mutter (I've got this) mutter-wayland (I've got this) rhythmbox totem I can help out with the others as time allows, but I'm not a cogl expert, and am also off to Brno for the devconf tmw. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Build issue with llvm on EL6?
On Wed, Feb 5, 2014 at 1:17 AM, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2014 10:31 PM, Dave Johansen wrote:
On Sun, Feb 2, 2014 at 7:58 PM, Dave Johansen
davejohan...@gmail.com mailto:davejohan...@gmail.com wrote:
The EL6 build of llvm 3.4 is currently in testing and it was just
pointed out that there's a potential issue with the build (
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0264/llvm-3.4-5.el6
).
If you examine the build.log (
http://kojipkgs.fedoraproject.org//work/tasks/593/6470593/build.log
) It looks like the include path is being included twice and that's
causing the warning about the invalid host type. Is there
something wrong with the .spec file? Or is there something I can do
to fix/prevent this issue?
Thanks, Dave
I was able to get a hold of the original submitter of the issue and
the issue is because of the multiple paths that exist on EL6.
Here's his explanation and recommended solution:
$ echo /usr/lib/gcc/x86_64*/*/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
EL6 originally had gcc-4.4.4 and gcc-4-4.7 still has the old
path
included for compatibility. Because of the space inbetween
configure thinks /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include is
a host type.
The files in /usr/lib/gcc/x86_64-redhat-linux/4.4.7/include have
nothing to do with C++. Clang has own versions of these files in
/usr/lib/clang/3.4/include.
Therefore it should just be
--with-c-include-dirs=%{_includedir},
which is also the default if you specify nothing.
C++ headers and runtime libs from gcc are selected by clang at
runtime:
$ clang -v clang version 3.4 (tags/RELEASE_34/final) Target:
x86_64-redhat-linux-gnu Thread model: posix Found candidate GCC
installation: /usr/lib/gcc/x86_64-redhat-linux/4.4.4 Found
candidate GCC installation:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7 Selected GCC installation:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7
So my question is if the same sort of change also needs to be made
in the Fedora .spec file that the EL6 one is based on.
On Fedora there is no compatibility symlink; IIRC the
00with-c-include-dirs was added (by myself) because at the time LLVM
and Clang's detection routines were less reliable (there was a list of
GCC versions it knows about, and if the version installed is newer -
as is likely at every Fedora cycle - it breaks, unless the include
directory is manually specified)
I'm no longer routinely involved in LLVM maintenance, but agree that
it might be worth re-checking the Fedora .spec.
I don't have a machine with rawhide available at the moment, but it sounds
like this is worth looking into.
I'll try rebuilding Pure once the LLVM update lands - does Clang now
ship a complete set of C++ headers as well? That was a sticking point
earlier as the headers shipped by GCC in EL6 is too old for newer
versions of LLVM-targeting apps.
I'm not familiar with Pure, but apparently the newest version doesn't work
with the glibc that's available on EL6 ( see
https://bugzilla.redhat.com/show_bug.cgi?id=1058472 ), so it's just
obsoleted by the llvm 3.4 package for the time being.
libc++ is complete ( http://libcxx.llvm.org/ ) and I've been wondering if
the EL6 llvm package should ship with them just so the C+11/14 stuff will
work, but are there going to be any issues with that?
One other issue is that I had to make the following change to get libffi
support working properly in EL6. I'm not sure if the same change is needed
on Fedora or not, but I just wanted to throw it out there so that someone
with a rawhide machine could see if this same change was need there as well.
http://pkgs.fedoraproject.org/cgit/llvm.git/commit/?h=el6id=5b96b3dfff9ec6beaaa7d4fa7ee17a79cd58214c
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:56:02PM +, Matthew Garrett wrote: Yeah it's really a mistake for us to be using the linux/initrd commands under any circumstances. I have created the following bug report https://bugzilla.redhat.com/show_bug.cgi?id=1055157 which was reverted because the maintain wrote the EFI boot is the prefered method for booting Fedora Linu on an MacBook Pro. I'm wondering why RHEL 7 Beta - which I have instelld in a VM (Parallels) - uses linux16/initrd16 in the grub.cfg file. This may have a reason. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, 2014-02-05 at 10:44 +0100, Florian Weimer wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? It's not officially supported. I have such a system sitting right here (one of those annoying Bay Trail tablets) and it's fairly trivial to generate an image that boots on it, and even do an installation to it (I helped one of the guys at Intel do that, and it worked). If we ever get the hardware support for the first-gen Bay Trail devices in a usable state I'll probably release an unofficial F20-based image that's 32-bit UEFI capable, but we're unlikely to support 32-bit UEFI officially: the next generation of Bay Trail-based devices will use 64-bit firmwares, it's only the first gen and the first gen of x86 Apples (which are not pretty much obsolete) that used 32-bit UEFI firmwares in the wild. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Wed, 2014-02-05 at 13:30 +0100, Florian Weimer wrote: On 02/05/2014 01:09 PM, Josh Boyer wrote: On Wed, Feb 5, 2014 at 4:44 AM, Florian Weimer fwei...@redhat.com wrote: On 02/04/2014 05:09 AM, Adam Williamson wrote: It's a (hopefully) not too long and not too technical help for installing Fedora on UEFI systems. Should cover the 'greatest hits' that show up in bug reports, forums and IRC the most. What about installations on systems which only offer 32-bit UEFI? Is this supported at all, or just not by the x86_64 installer? Fedora doesn't support 32-bit UEFI (at the moment). Okay. What would be a good spot to add this to in the document? After the list in the Do I have a UEFI firmware? section? Sounds about right, yep. We can make the note very specific - I'd say the Bay Trail devices are the only ones we really have to care about. Hell, there's few enough that we can just list them by name. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 04, 2014 at 08:54:15 -0500, Jaroslav Reznik jrez...@redhat.com wrote: Seems to be pretty outdated (*), we're past many things written there aka Live CD size - for example for desktop and KDE spins. So the CD part could be removed, I know several spins doing changes in defaults and it's really up to SIG standing behind spin than Spins SIG. The intention was that the Spins SIG would set these standards and enforce them. However, when participation in the Spins SIG stopped (even though someone from each spin was supposed to be participating), this became impracticle. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 02/05/2014 03:34 AM, Stephen Gallagher wrote: It's not just that, actually. It has to do with the fact that the majority of the scientific-focused applications are built atop the QT4 and other KDE libraries, making it much better suited to operating atop the KDE desktop environment. Certainly it *can* be run in GNOME at the cost of additional memory usage and other resources This doesn't sound right. yum group info 'Engineering and Scientific' lists 148 applications, of which 14 require Qt (*). The method I used is pretty ad-hoc so perhaps I am missing something, but it seems to me that KDE is not really correlated to the 'scientificness'. This reflects my personal experience---I have been using Fedora for scientific computing for a long time, always under Gnome and I never felt the need to switch to KDE. Adam is probably right that KDE might just be a personal preference of the spin authors. This actually illustrates a problem I have with spins: if you treat them too much like separate products, they detract from modularity that is really the strength of Linux and Fedora. It should work just fine to combine Scientific and Security, for instance if someone wanted to do a statistical analysis on WiFi security survey scans :). If you look at spins as a PR/marketing effort around groupinstall, the modularity is easily available. If you look at spins as a customized remixes creating a specialized environment, not so much. Greetings przemek (*) as determined by for a in `yum group info 'Engineering and Scientific'` ; do if repoquery --requires $a | grep -iq qt; then echo $a; fi ; done -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, IIRC: LILO would use BIOS calls to load the kernel, and it would work on the original install because kernel was dropped on disk early on and end up in the low sectors, but would fail on kernel upgrade when the kernel blocks would end up in the filesystem areas beyond the BIOS reach. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
change Selinux context in %post?
Are there official guidelines on how to handle selinux contexts in
packaging? I can still only find the draft which seems way more complicated
than necessary for my needs.
I'm working on a package that uses mongodb internally (runs it's own
instance). Selinux is complaining because it has mongodb creating the
database (and logs) outside of the normal locations.
I think I can fix this with a chcon -t mongod_var_lib_t
%{_sharedstatedir}/db/location and chcon -t mongod_log_t /log/path or
something like that.
Is it a good idea to do this in %post?
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Wed, Feb 5, 2014 at 11:24 AM, Richard Shaw hobbes1...@gmail.com wrote:
Are there official guidelines on how to handle selinux contexts in
packaging? I can still only find the draft which seems way more complicated
than necessary for my needs.
I'm working on a package that uses mongodb internally (runs it's own
instance). Selinux is complaining because it has mongodb creating the
database (and logs) outside of the normal locations.
I think I can fix this with a chcon -t mongod_var_lib_t
%{_sharedstatedir}/db/location and chcon -t mongod_log_t /log/path or
something like that.
Is it a good idea to do this in %post?
No. For one thing, the next relabel will blow it away.
That being said, you can sometime fix* this kind of issue by using
something like runcon or setpriv --selinux-label to invoke the binary
that selinux otherwise wants to label in an unfortunate way.
* If pressed, I will actually defend this practice. Just because
you're running the mongodb binary does *not* mean that you're running
something that, from a MAC perspective, should be treated as the
system mongodb daemon. I use a similar trick to get private mysql
instances to work right on apparmor systems.
--Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned packages
We no longer have valid contact information for the following packagers due to changes in their work duties: * npajkovs * fkocina * zpavlas For packages that they own we have orphaned the packages and made them comaintainers. In the future, if their current fas email addresses start to bounce, we will need to remove the accounts from the pkgdb altogether. If anyone knows of a way to contact them to ask if they would still like to maintain any of their packages we would appreciate it. They'd need to update their email address in fas and retake ownership of packages that were orphaned as part of this. The following packages have been orphaned. Feel free to take them over if you care about them: npajkovs: * inn (f19-devel and epel7) * iptraf-ng (f19-devel epel5-6) * irssi-xmpp (f19-devel) fkocina: * librtas (f19-devel) * libservicelog (f19-devel) * netatalk (f19-devel epel5-6) * powerpc-utils-python (f19-devel) * servicelog (f19-devel) -Toshio pgpWuMr1K_5Wr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On Wed, Feb 5, 2014 at 12:40 PM, Richard Hughes hughsi...@gmail.com wrote: On 5 February 2014 10:20, Miloslav Trmač m...@volny.cz wrote: Wouldn't it be better to mass-file bugs? I do keep track of the affected packages and may end up doing that, depending on what happens in a week or two since I posted the initial message. It's good to see some maintainers fix their packages, but I don't think posting fixed messages on list has any value. For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. The problem with doing that is that it may end up keeping unmaintained packages lingering around unnoticed as they won't get flagged for not being built/updated by maintainers for N releases. I've done a bunch of such sweeping changes, for example fixed a lot of packages for the unversioned docdirs change in F-20 but I'm afraid that if maintainers couldn't be bothered to do such a simple think (and many not even bothered to simply merge the changes I made to rawhide to their F-20 branches and ship the update, nor replying to the filed bug), many of the packages I touched were effectively unmaintained and should have got new maintainers or be retired. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Auto-expiring bugs are getting absurd
Like this: https://bugzilla.redhat.com/show_bug.cgi?id=959071 I specifically followed up to say the issue continues in Fedora 19, and nothing changed. The bug tracker should not expire bugs if there's been a comment after the EOL warning. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 5 Feb 2014 13:51:41 -0800 David Timothy Strauss da...@davidstrauss.net wrote: Like this: https://bugzilla.redhat.com/show_bug.cgi?id=959071 I specifically followed up to say the issue continues in Fedora 19, and nothing changed. The bug tracker should not expire bugs if there's been a comment after the EOL warning. You just need to change the Version tag. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 1:53 PM, Susi Lehtola jussileht...@fedoraproject.org wrote: You just need to change the Version tag. That is not something I appear to have access to do. And, if I don't, very few people do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 984185] perl should be a hardened build
https://bugzilla.redhat.com/show_bug.cgi?id=984185 Fedora End Of Life endofl...@fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2014-02-05 17:07:40 --- Comment #6 from Fedora End Of Life endofl...@fedoraproject.org --- Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=aZC6T3HeuQa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Auto-expiring bugs are getting absurd
David Timothy Strauss wrote: That is not something I appear to have access to do. And, if I don't, very few people do. If you'd like to help update bugs then apply for the Bugzappers group in FAS and you'll get editbugs access to be able to change the version in the future. As far as the bug is concerned, I'd create an upstream report. The Intel developer is usually responsive to reports. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 987706] [abrt] perl-Padre-0.90-6.fc18: gtk_file_system_model_sort: Process /usr/bin/perl was killed by signal 6 (SIGABRT)
https://bugzilla.redhat.com/show_bug.cgi?id=987706 Fedora End Of Life endofl...@fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2014-02-05 17:10:37 --- Comment #13 from Fedora End Of Life endofl...@fedoraproject.org --- Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9itdj2oLAJa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 16:09 -0600, Michael Cronenworth wrote: David Timothy Strauss wrote: That is not something I appear to have access to do. And, if I don't, very few people do. Rather a lot do, actually - see below. If you'd like to help update bugs then apply for the Bugzappers group in FAS and you'll get editbugs access to be able to change the version in the future. Please don't. This is not accurate. Bugzappers has been inactive for years now. Packagers and QA team members (and possibly other groups I don't know about) get editbugs privileges via automatic inheritance into the 'fedorabugs' group, and 'fedorabugs' group admins can hand them out on a case-by-case basis. Quite a lot of people have editbugs - I think it's in the hundreds or thousands - but you do actually have to be a packager or QA person or have some other specific reason to have editbugs privs. Just for a single bug like this the simple thing is to get someone to do it. Usually *someone* with editbugs privs will be CCed on a report and should catch the comment and re-open it - as a packager, ajax certainly has such privs, for instance, but I guess he was busy. In this case David highlighted the issue and someone re-opened the report almost immediately; doesn't seem like anything went terribly wrong. As far as the bug is concerned, I'd create an upstream report. The Intel developer is usually responsive to reports. This is probably a good idea - our X devs do try and cover downstream reports, but they're overworked, and upstream should have more people able to respond. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
Adam Williamson wrote: Please don't. This is not accurate. Bugzappers has been inactive for years now. Packagers and QA team members (and possibly other groups I don't know about) get editbugs privileges via automatic inheritance into the 'fedorabugs' group, and 'fedorabugs' group admins can hand them out on a case-by-case basis. Yes, I'm fully aware Bugzappers is dead (I subscribe to the same lists you do, Adam). Perhaps David doesn't want to become a packager to edit a bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 16:36 -0600, Michael Cronenworth wrote: Adam Williamson wrote: Please don't. This is not accurate. Bugzappers has been inactive for years now. Packagers and QA team members (and possibly other groups I don't know about) get editbugs privileges via automatic inheritance into the 'fedorabugs' group, and 'fedorabugs' group admins can hand them out on a case-by-case basis. Yes, I'm fully aware Bugzappers is dead (I subscribe to the same lists you do, Adam). So, er, why did you advise someone to apply to it? For now its functions are subsumed into QA, so if you want to get editbugs privs in order to do triage work, the appropriate thing to do is follow the QA group join procedure - https://fedoraproject.org/wiki/QA/Join - and apply for the qa FAS group. Perhaps David doesn't want to become a packager to edit a bug. You sort of skipped the bit about the QA team, and about just asking someone else to re-open it, which is what has happened. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 2:33 PM, Adam Williamson awill...@redhat.com wrote: Quite a lot of people have editbugs - I think it's in the hundreds or thousands I mean few people in the sense that it requires a specific grant of permissions, more than to just report bugs. Telling me to join a group is also not addressing my complaint. My complaint is that Fedora is auto-setting EOL on bugs with no clear way for even the users who reported the bugs to stop it from happening. Obviously, my comment wasn't enough to get human intervention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 2:39 PM, David Timothy Strauss da...@davidstrauss.net wrote: Telling me to join a group is also not addressing my complaint. My complaint is that Fedora is auto-setting EOL on bugs with no clear way for even the users who reported the bugs to stop it from happening. Obviously, my comment wasn't enough to get human intervention. This is also not the first time this has happened to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 14:39 -0800, David Timothy Strauss wrote: On Wed, Feb 5, 2014 at 2:33 PM, Adam Williamson awill...@redhat.com wrote: Quite a lot of people have editbugs - I think it's in the hundreds or thousands I mean few people in the sense that it requires a specific grant of permissions, more than to just report bugs. Telling me to join a group is also not addressing my complaint. My complaint is that Fedora is auto-setting EOL on bugs with no clear way for even the users who reported the bugs to stop it from happening. Obviously, my comment wasn't enough to get human intervention. Like I said, usually it will be, but no process is perfect. I can't imagine there's ever a time when no-one in #fedora or #fedora-devel or on devel@/test@ has editbugs privs, so it seems perfectly reasonable to just drop a line in any of those places if you need a bug re-opened and it should happen quickly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
David Timothy Strauss wrote: On Wed, Feb 5, 2014 at 2:39 PM, David Timothy Strauss da...@davidstrauss.net wrote: Telling me to join a group is also not addressing my complaint. My complaint is that Fedora is auto-setting EOL on bugs with no clear way for even the users who reported the bugs to stop it from happening. Obviously, my comment wasn't enough to get human intervention. This is also not the first time this has happened to me. We have limited resources so this is expected and not absurd. Follow Adam's advice if you wish to negate this from happening in the future. Worse case: Open a new bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On 05/02/14 22:42, David Timothy Strauss wrote: This is also not the first time this has happened to me. I'll chime in: when I first switched to Fedora (F14/15 era), I found this quite obnoxious, enough that I remember it. So there is also an issue of being a welcoming community to newcomers. best, Colin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 22:48 +, Colin Macdonald wrote: On 05/02/14 22:42, David Timothy Strauss wrote: This is also not the first time this has happened to me. I'll chime in: when I first switched to Fedora (F14/15 era), I found this quite obnoxious, enough that I remember it. So there is also an issue of being a welcoming community to newcomers. The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. The idea of not closing bugs that have comments after the EOL notification doesn't necessarily make things better, I don't think; we'd just have errors in the other direction. Say someone dropped a note 'oh yeah, this is working now!' - it would be silly not to close the bug, right? algorithms are never perfect, but we do have to use them, as a perennially under-resourced project. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On 05/02/14 22:50, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. What about allowing the reporter to update the version and/or reopen it if it does get closed? or is BZ not able to offer that as an option? TBH I thought the whole point was that the reporter was expected to update the version if they wanted it to stay open so I'm a bit surprised to hear that they can't unless they are also a packager. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On 05/02/14 22:57, Tom Hughes wrote: TBH I thought the whole point was that the reporter was expected to update the version if they wanted it to stay open so I'm a bit surprised to hear that they can't unless they are also a packager. In fact the first message actually tells the reporter to do that: : Thank you for reporting this issue and we are sorry that we may not : be able to fix it before Fedora 18 is end of life. If you would still : like to see this bug fixed and are able to reproduce it against a : later version of Fedora, you are encouraged change the 'version' to : a later Fedora version prior to Fedora 18's end of life. so if they can't do so then that message seems a little suboptimal. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 2:50 PM, Adam Williamson awill...@redhat.com wrote: The idea of not closing bugs that have comments after the EOL notification doesn't necessarily make things better, I don't think; we'd just have errors in the other direction. Say someone dropped a note 'oh yeah, this is working now!' - it would be silly not to close the bug, right? The question here is what's more common: * This works for me comment after an EOL warning. With my proposal, the maintainer would have to manually set the bug to WONTFIX. * This is still a problem comment after an EOL warning. Currently, this requires a maintainer to intervene and bump the version. I assume the latter is more common. On Wed, Feb 5, 2014 at 2:59 PM, Tom Hughes t...@compton.nu wrote: In fact the first message actually tells the reporter to do that: : Thank you for reporting this issue and we are sorry that we may not : be able to fix it before Fedora 18 is end of life. If you would still : like to see this bug fixed and are able to reproduce it against a : later version of Fedora, you are encouraged change the 'version' to : a later Fedora version prior to Fedora 18's end of life. so if they can't do so then that message seems a little suboptimal. Not only that, the message provides no guidance to the bug reporter if the problem still occurs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 2:57 PM, Tom Hughes t...@compton.nu wrote: TBH I thought the whole point was that the reporter was expected to update the version if they wanted it to stay open so I'm a bit surprised to hear that they can't unless they are also a packager. Regular bug reporters definitely can't. Of course, many people here can, which is why I get unhelpful replies like You just need to change the Version tag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On 05/02/14 23:02, David Timothy Strauss wrote: On Wed, Feb 5, 2014 at 2:59 PM, Tom Hughes t...@compton.nu wrote: In fact the first message actually tells the reporter to do that: : Thank you for reporting this issue and we are sorry that we may not : be able to fix it before Fedora 18 is end of life. If you would still : like to see this bug fixed and are able to reproduce it against a : later version of Fedora, you are encouraged change the 'version' to : a later Fedora version prior to Fedora 18's end of life. so if they can't do so then that message seems a little suboptimal. Not only that, the message provides no guidance to the bug reporter if the problem still occurs. Sure it does - it tells them to update the version if the problem still occurs. Of course we now know they can't actually do that, so the guidance isn't much use, but it is there. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 05 Feb 2014 22:59:46 + Tom Hughes t...@compton.nu wrote: On 05/02/14 22:57, Tom Hughes wrote: TBH I thought the whole point was that the reporter was expected to update the version if they wanted it to stay open so I'm a bit surprised to hear that they can't unless they are also a packager. In fact the first message actually tells the reporter to do that: : Thank you for reporting this issue and we are sorry that we may not : be able to fix it before Fedora 18 is end of life. If you would still : like to see this bug fixed and are able to reproduce it against a : later version of Fedora, you are encouraged change the 'version' to : a later Fedora version prior to Fedora 18's end of life. so if they can't do so then that message seems a little suboptimal. This person was not the reporter. They simply added that they saw it also in f19. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 22:57 +, Tom Hughes wrote: On 05/02/14 22:50, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. What about allowing the reporter to update the version and/or reopen it if it does get closed? or is BZ not able to offer that as an option? The reporter already can. The problem comes when the reporter goes inactive, but someone else knows the bug is still valid, and that person doesn't have editbugs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 15:04 -0800, David Timothy Strauss wrote: On Wed, Feb 5, 2014 at 2:57 PM, Tom Hughes t...@compton.nu wrote: TBH I thought the whole point was that the reporter was expected to update the version if they wanted it to stay open so I'm a bit surprised to hear that they can't unless they are also a packager. Regular bug reporters definitely can't. You can do so for your *own* bugs (and bugs assigned to you). You can't do so for other people's. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 3:08 PM, Tom Hughes t...@compton.nu wrote: Sure it does - it tells them to update the version if the problem still occurs. Those instructions start with Package Maintainer: so they are not directed at the people experiencing the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 3:11 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-02-05 at 15:04 -0800, David Timothy Strauss wrote: On Wed, Feb 5, 2014 at 2:57 PM, Tom Hughes t...@compton.nu wrote: TBH I thought the whole point was that the reporter was expected to update the version if they wanted it to stay open so I'm a bit surprised to hear that they can't unless they are also a packager. Regular bug reporters definitely can't. You can do so for your *own* bugs (and bugs assigned to you). You can't do so for other people's. Indeed, you're right. I must have missed that I wasn't the original reporter for the driver issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 2014-02-05 at 14:50 -0800, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. Everyone does not need reopen: just the ability to change the version would suffice. (Unless there are serious worries about the risk of allowing users to deface version fields?) I think auto-expiration would work great with this tweak. I've taken to cloning bugs that get prematurely closed... a bit silly that I can clone, but not change the version. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 5, 2014 at 4:12 PM, Michael Catanzaro mcatanz...@gnome.org wrote: Everyone does not need reopen: just the ability to change the version would suffice. (Unless there are serious worries about the risk of allowing users to deface version fields?) I think auto-expiration would work great with this tweak. +1. We could update the instructions so that reporters, maintainers, and other people experiencing the bug could respond to EOL bots. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
Add in Keywords field: FutureFeature Or edit the title with [RFE] prefixed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On 02/05/2014 12:24 PM, Richard Shaw wrote:
Are there official guidelines on how to handle selinux contexts in
packaging? I can still only find the draft which seems way more
complicated than necessary for my needs.
I'm working on a package that uses mongodb internally (runs it's own
instance). Selinux is complaining because it has mongodb creating the
database (and logs) outside of the normal locations.
I think I can fix this with a chcon -t mongod_var_lib_t
%{_sharedstatedir}/db/location and chcon -t mongod_log_t /log/path or
something like that.
Is it a good idea to do this in %post?
Thanks,
Richard
You need a semanage fcontext call to make it permanent.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Wed, 2014-02-05 at 13:24 -0600, Richard Shaw wrote: Are there official guidelines on how to handle selinux contexts in packaging? I can still only find the draft which seems way more complicated than necessary for my needs. I'm working on a package that uses mongodb internally (runs it's own instance). Does it *contain* its own copy of mongodb or just *run the system copy* in a special way? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Wed, Feb 5, 2014 at 9:05 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-02-05 at 13:24 -0600, Richard Shaw wrote: Are there official guidelines on how to handle selinux contexts in packaging? I can still only find the draft which seems way more complicated than necessary for my needs. I'm working on a package that uses mongodb internally (runs it's own instance). Does it *contain* its own copy of mongodb or just *run the system copy* in a special way? It runs an instance of the system mongodb via a symbolic link within it's own bin folder (the symbolic link being the only thing in the bin folder). I guess I was intentionally not saying what software I was packaging because it's not FOSS... It's the controller for Ubiquity and it's java based. It will have to go into RPM Fusion non-free but if you have one of their access points I haven't found any other way to configure them. I think it's preferable to have the controller on your own Fedora/RHEL server than be forced to run it in a windows VM. It runs self-contained except for the symbolic link to the mongod executable. I tried splitting it up between /usr/shared/unifi for the static bits and symlink over to /var/lib/unifi for the writable bits but it was getting way too complicated for me, so for now I have everything going into /var/lib/unifi. I adopted and modified a systemd service file and have it working well with selinux in permissive mode running as its own user (unifi). I just really don't know enough about selinux to put together a policy for it, though I've been doing some reading today along those lines. One interesting part is it uses port 8080 which it redirects to 8443 for a secure connection, which seems to work ok, but the default db port is 27117 which is in unreserverd_port_t... I assume I need to grab that for mongod? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On 05/02/14 05:46 PM, Przemek Klosowski wrote: On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, It still happens: I just had a case of this on Dell R620 (Ivy Bridge Xeon) with over 3TB disk space and RHEL 6.5... Grub couldn't reach it's files to boot OS. Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1061604] New: Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=1061604 Bug ID: 1061604 Summary: Upgrade to new upstream version Product: Fedora EPEL Version: epel7 Component: stompclt Assignee: massimo.pala...@gmail.com Reporter: lionel.c...@cern.ch QA Contact: extras...@fedoraproject.org CC: massimo.pala...@gmail.com, perl-devel@lists.fedoraproject.org The latest version of stompclt is now 1.1. This is the version to use everywhere. Please upgrade in EPEL. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dTKEXe9TGWa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File threads-shared-1.46.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads-shared: b17841a6f1c60f06ebf1a0290530b266 threads-shared-1.46.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-threads-shared] 1.46 bump
commit f9dbe7ed2c9c25109e1e7cc40fdfc1789a746268
Author: Petr Písař ppi...@redhat.com
Date: Wed Feb 5 09:02:24 2014 +0100
1.46 bump
.gitignore |1 +
perl-threads-shared.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e565a51..6367d84 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
/threads-shared-1.42.tar.gz
/threads-shared-1.43.tar.gz
/threads-shared-1.45.tar.gz
+/threads-shared-1.46.tar.gz
diff --git a/perl-threads-shared.spec b/perl-threads-shared.spec
index b553b39..6c3aa85 100644
--- a/perl-threads-shared.spec
+++ b/perl-threads-shared.spec
@@ -1,5 +1,5 @@
Name: perl-threads-shared
-Version:1.45
+Version:1.46
Release:1%{?dist}
Summary:Perl extension for sharing data structures between threads
License:GPL+ or Artistic
@@ -60,6 +60,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Feb 05 2014 Petr Pisar ppi...@redhat.com - 1.46-1
+- 1.46 bump
+
* Thu Nov 14 2013 Petr Pisar ppi...@redhat.com - 1.45-1
- 1.45 bump
diff --git a/sources b/sources
index 6aad59f..24a618e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fddf251253b52745e66ad43345fa9c3e threads-shared-1.45.tar.gz
+b17841a6f1c60f06ebf1a0290530b266 threads-shared-1.46.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-threads-shared/f20] 1.46 bump
Summary of changes: f9dbe7e... 1.46 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-threads-shared/f19] 1.46 bump
commit 5523abc10bf04487007ca55a54344c3abb004b1d
Author: Petr Písař ppi...@redhat.com
Date: Wed Feb 5 09:02:24 2014 +0100
1.46 bump
.gitignore |1 +
perl-threads-shared.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e565a51..6367d84 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
/threads-shared-1.42.tar.gz
/threads-shared-1.43.tar.gz
/threads-shared-1.45.tar.gz
+/threads-shared-1.46.tar.gz
diff --git a/perl-threads-shared.spec b/perl-threads-shared.spec
index 4c6a405..9fd444d 100644
--- a/perl-threads-shared.spec
+++ b/perl-threads-shared.spec
@@ -1,5 +1,5 @@
Name: perl-threads-shared
-Version:1.45
+Version:1.46
Release:1%{?dist}
Summary:Perl extension for sharing data structures between threads
License:GPL+ or Artistic
@@ -60,6 +60,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Feb 05 2014 Petr Pisar ppi...@redhat.com - 1.46-1
+- 1.46 bump
+
* Thu Nov 14 2013 Petr Pisar ppi...@redhat.com - 1.45-1
- 1.45 bump
diff --git a/sources b/sources
index 6aad59f..24a618e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fddf251253b52745e66ad43345fa9c3e threads-shared-1.45.tar.gz
+b17841a6f1c60f06ebf1a0290530b266 threads-shared-1.46.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: dspam
dspam has broken dependencies in the epel-7 tree: On x86_64: dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) On ppc64: dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) On x86_64: dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::bars) On ppc64: dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::bars) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-SOAP-Lite
perl-SOAP-Lite has broken dependencies in the epel-7 tree: On x86_64: perl-SOAP-Lite-0.716-1.el7.noarch requires perl(SOAP::Transport::TCP) On ppc64: perl-SOAP-Lite-0.716-1.el7.noarch requires perl(SOAP::Transport::TCP) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: w3c-markup-validator
w3c-markup-validator has broken dependencies in the epel-7 tree: On x86_64: w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) On ppc64: w3c-markup-validator-1.3-4.el7.noarch requires perl(SGML::Parser::OpenSP) = 0:0.991 w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) On x86_64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds On ppc64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On x86_64: perl-PDL-2.7.0-2.el7.1.x86_64 requires perl(Prima::MsgBox) On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(Prima::MsgBox) perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-DAV] Created tag perl-HTTP-DAV-0.47-1.el7
The lightweight tag 'perl-HTTP-DAV-0.47-1.el7' was created pointing to: 5423c80... Update to 0.47 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-BrowserDetect] Created tag perl-HTTP-BrowserDetect-1.61-1.el7
The lightweight tag 'perl-HTTP-BrowserDetect-1.61-1.el7' was created pointing to: dd8b89e... Update to 1.61 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Text-Aligner-0.10.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Text-Aligner: 3bd3688114a5d442f41e6d886d3aa1a7 Text-Aligner-0.10.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Aligner] 0.10 bump
commit 79e374a9ea89ad75d05fb2fd9c53654b0152855d
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Feb 5 10:51:03 2014 +0100
0.10 bump
.gitignore |1 +
perl-Text-Aligner.spec |8 +---
sources|2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9b85503..830cc6a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Text-Aligner-0.03.tar.gz
/Text-Aligner-0.07.tar.gz
/Text-Aligner-0.08.tar.gz
/Text-Aligner-0.09.tar.gz
+/Text-Aligner-0.10.tar.gz
diff --git a/perl-Text-Aligner.spec b/perl-Text-Aligner.spec
index 04fefe7..5ee3353 100644
--- a/perl-Text-Aligner.spec
+++ b/perl-Text-Aligner.spec
@@ -1,5 +1,5 @@
Name: perl-Text-Aligner
-Version:0.09
+Version:0.10
Release:1%{?dist}
Summary:Text::Aligner Perl module
License:GPL+ or Artistic
@@ -12,7 +12,7 @@ BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(Exporter)
-BuildRequires: perl(Term::ANSIColor) = 2.01
+BuildRequires: perl(Term::ANSIColor) = 2.02
BuildRequires: perl(vars)
# Tests only
BuildRequires: perl(constant)
@@ -22,7 +22,6 @@ BuildRequires: perl(IO::Handle)
BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(Term::ANSIColor) = 2.01
%{?perl_default_filter:
%filter_from_requires /^perl(Term::ANSIColor)$/d
@@ -60,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Feb 05 2014 Jitka Plesnikova jples...@redhat.com - 0.10-1
+- 0.10 bump
+
* Mon Feb 03 2014 Jitka Plesnikova jples...@redhat.com - 0.09-1
- 0.09 bump
diff --git a/sources b/sources
index da04049..1b22dd3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-56a3c1b21f4a66f2f0c5064848abc0d3 Text-Aligner-0.09.tar.gz
+3bd3688114a5d442f41e6d886d3aa1a7 Text-Aligner-0.10.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Not all packages are from CPAN, not all maintainers want to receive upstream updates. Or is there a rule that more specific match wins? That could be used to override perl-* glob for non-CPAN packages. -- Petr pgp21ak6aUxmn.pgp Description: PGP signature -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 12:36 PM, Petr Pisar wrote: On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Not all packages are from CPAN, Also, CPAN is not free of bugs. not all maintainers want to receive upstream updates. Well, I do not want to receive such update notification mails, because they significantly contribute the mail traffic, I am already receiving. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 12:44 PM, Till Maas wrote: On Wed, Feb 05, 2014 at 12:36:12PM +0100, Petr Pisar wrote: On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Not all packages are from CPAN, not all maintainers want to receive upstream updates. If someone does not want notifications for their packages, they can add their name to this list: https://fedoraproject.org/wiki/Upstream_release_monitoring#Package_Owner_Ignore_List IMO, such stuff MUST be opt-in, not opt-out. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-SOAP-Lite ownership changed
Package perl-SOAP-Lite in Fedora EPEL 7 was orphaned by psabata To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-SOAP-Lite -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-SOAP-Lite ownership changed
Package perl-SOAP-Lite in Fedora EPEL 7 is now owned by averi To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-SOAP-Lite -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File YAML-Tiny-1.58.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-YAML-Tiny: b206daf7e3cbf1be15e069081a09ff29 YAML-Tiny-1.58.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-SOAP-Lite had acl change status
averi has set the approveacls acl on perl-SOAP-Lite (Fedora EPEL 7) to Obsolete for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-SOAP-Lite -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-SOAP-Lite had acl change status
averi has set the approveacls acl on perl-SOAP-Lite (Fedora EPEL 7) to Approved for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-SOAP-Lite -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML-Tiny] Update to 1.58
commit d1f2c8ab23f8646ad2d8671cca49d312c668f503
Author: Paul Howarth p...@city-fan.org
Date: Wed Feb 5 12:00:50 2014 +
Update to 1.58
- New upstream release 1.58
- 1.57 omitted a change entry for the following change:
Incompatible change:
- Previously, YAML::Tiny was sloppy about file encodings; it is now strict
- The 'read' method and 'LoadFile' function expect UTF-8 encoded files
- The 'write' method and 'DumpFile' function produce UTF-8 encoded files
- The 'read_string' and 'write_string' methods and the 'Load' and 'Dump'
functions expect or generate (decoded) character data
perl-YAML-Tiny.spec | 12 +++-
sources |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
---
diff --git a/perl-YAML-Tiny.spec b/perl-YAML-Tiny.spec
index bbd1d8f..3153f0f 100644
--- a/perl-YAML-Tiny.spec
+++ b/perl-YAML-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-YAML-Tiny
-Version:1.57
+Version:1.58
Release:1%{?dist}
Summary:Read/Write YAML files with as little code as possible
License:GPL+ or Artistic
@@ -70,6 +70,16 @@ perl Build.PL --installdirs=vendor
%{_mandir}/man3/YAML::Tiny.3pm*
%changelog
+* Wed Feb 5 2014 Paul Howarth p...@city-fan.org 1.58-1
+- Update to 1.58
+ - 1.57 omitted a change entry for the following change:
+ Incompatible change:
+ - Previously, YAML::Tiny was sloppy about file encodings; it is now strict
+ - The 'read' method and 'LoadFile' function expect UTF-8 encoded files
+ - The 'write' method and 'DumpFile' function produce UTF-8 encoded files
+ - The 'read_string' and 'write_string' methods and the 'Load' and 'Dump'
+functions expect or generate (decoded) character data
+
* Fri Jan 31 2014 Paul Howarth p...@city-fan.org 1.57-1
- Update to 1.57
Incompatible change:
diff --git a/sources b/sources
index 8b2c554..6e8a424 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5df8450dba06fdc64e73992a071d012b YAML-Tiny-1.57.tar.gz
+b206daf7e3cbf1be15e069081a09ff29 YAML-Tiny-1.58.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-SOAP-Lite/epel7] (11 commits) ...1.10 bump
Summary of changes: de25d98... Add a comment about the bundled IO modules (*) 97fdf6c... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 6713845... Perl 5.18 rebuild (*) 438410f... Adjust tests for Perl 5.18 (*) 28143ad... 1.06 bump (*) 66d02c3... Add a missing, undetected runtime dependency on LWP::UserAg (*) 0fa459f... Properly obsolete/provide SOAP-Transport-TCP (*) 8ed6d9a... 1.08 bump, no code changes (*) 3109f1a... Update the source URL (*) a330987... 1.09 bugfix bump (*) 09a222c... 1.10 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-qpid_proton
perl-qpid_proton has broken dependencies in the rawhide tree: On x86_64: perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid::proton::ExceptionHandling) On i386: perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid::proton::ExceptionHandling) On armhfp: perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid::proton::ExceptionHandling) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 871442] Broken configuration for httpd 2.4
https://bugzilla.redhat.com/show_bug.cgi?id=871442 Fedora End Of Life endofl...@fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2014-02-05 07:46:36 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1Wy5uul7EUa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 871442] Broken configuration for httpd 2.4
https://bugzilla.redhat.com/show_bug.cgi?id=871442 --- Comment #9 from Fedora End Of Life endofl...@fedoraproject.org --- Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FNBKbB8njKa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-IO-SessionData ownership changed
Package perl-IO-SessionData in Fedora EPEL 7 was orphaned by psabata To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-SessionData -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-IO-SessionData ownership changed
Package perl-IO-SessionData in Fedora EPEL 7 is now owned by averi To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-SessionData -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 01:21 PM, Till Maas wrote: On Wed, Feb 05, 2014 at 12:46:58PM +0100, Ralf Corsepius wrote: On 02/05/2014 12:44 PM, Till Maas wrote: If someone does not want notifications for their packages, they can add their name to this list: https://fedoraproject.org/wiki/Upstream_release_monitoring#Package_Owner_Ignore_List IMO, such stuff MUST be opt-in, not opt-out. I added your username already a long time ago, so you/your packages are not affected. It's not about indiviiduals it's about defaults and it's about the harm your defaults are causing: 1000s of emails plastering various mailing lists and inboxes. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Synopsis-0.07.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Synopsis: f661ccae395008e4b6a2888e6cd331a3 Test-Synopsis-0.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907704] Use the plain `perl` command instead of the `%{_perl}` macro in generated specfiles
https://bugzilla.redhat.com/show_bug.cgi?id=907704 Fedora End Of Life endofl...@fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2014-02-05 13:52:52 --- Comment #5 from Fedora End Of Life endofl...@fedoraproject.org --- Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=0v3agyOArKa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
