preupgrade-cli...
So I was playing around with preupgrade-cli to move from F13 to F14... It has downloaded everything however I was concerned with this... Saving Primary metadata Saving file lists metadata Saving other metadata Generating sqlite DBs Sqlite DBs complete Preparing system to boot into installer DEBUG /sbin/grubby --title="Upgrade to Fedora 14 (Laughlin)" --remove-kernel="/boot/upgrade/vmlinuz" --add-kernel="/boot/upgrade/vmlinuz" --initrd="/boot/upgrade/initrd.img" --args="preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=5c913c14-e58a-4696-9da7-b701550e1f41:/upgrade/ks.cfg stage2=http://mirror.csclub.uwaterloo.ca/fedora/linux/development/14/x86_64/os/images/install.img"; sh: /sbin/grub: No such file or directory /bin/echo: write error: Broken pipe All finished. The upgrade will begin when you reboot. I'm a bit concerned with the /sbin/grub and broken pipe. However grub.conf has the upgrade to F14 in it. Something to be concerned with? Seems benign but wondering about why its there. Worth a bug report? -- Nathanael d. Noblet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Advice on bug...
Hello I've recently run into a selinux 'bug' [1] which it turns out isn't a selinux bug. I tried setting up a VPN via NetworkManager. Selecting all the keys and certs and all. It works however because the keys aren't in ~/.cert the selinux context is wrong and they can't be read. I'm wondering why NM doesn't create/copy/manage the .cert directory. Currently the original bug reported against selinux is closed but I still think the underlying issue needs to be discussed... Even if it was as much as a notice or checkbox to request having the files moved to .cert Thoughts? https://bugzilla.redhat.com/show_bug.cgi?id=638691 -- Nathanael d. Noblet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
The march toward Release Candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After a flurry of composes and tests and fixes over the past couple days, we're finally to the point where we can make the Release Candidate. We have a few more things going into stable tonight, which will show up in tomorrow's Branched report. I will be making the release candidate against that repository, so everybody else can play along and test it at home from this repository as well. Once I get the compose done, I'll work on bodhi so that we can do "stable" pushes that actually will become 0-day updates to Fedora and we'll start populating the updates directories. Nothing else will go into Fedora 14 itself without releng / qa oversight. We have a chance at a strong finish to a darn good release cycle. Lets pull together and make it happen! - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky/tm8ACgkQ4v2HLvE71NWrygCfRU/uIDrUy7aZMLXgbLJThhJy JYQAn2cyUdQDya+g6ArUg65DPVcDZ1o2 =lgwi -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Asynchronous disk space monitoring
On Wed, Oct 20, 2010 at 16:26, Orion Poplawski wrote: > On 10/20/2010 04:18 PM, Stephen John Smoogen wrote: >> On Wed, Oct 20, 2010 at 15:52, Orion Poplawski wrote: >>> Somewhat OT, but not sure where else to ask. I'm looking into an issue >>> where >>> the nepomuk strigi service is preventing a desktop with an NFS mounted home >>> directory from going into hibernate. I think this is because it continually >>> checks the available disk space in the home directory (about once every 20 >>> seconds in current 4.5.2, once every 10 seconds in 4.4.5). >> >> hibernate + network file systems has always been a rather tough nut . >> NFS is built on the fact that multiple clients may have the same tree >> open at the same time... so if you are going to hibernate you are >> going to need to basicallly unmount because there is no guarentee that >> anything underneath you will be there when you come out of >> hibernation. > > Yeah, unfortunately unmounting causes other problems. See > https://bugzilla.redhat.com/show_bug.cgi?id=287411 Well yes... again it is the nature of NFS for as long as I can remember and something always brought up as why AFS was superior. If I remember correctly (which is doubtful) NFS does not guarantee inode consistency between mounts so if a mount goes away and comes back open file descriptors are defined not to work. I believe NFSv4 in a clustered environment works differently but in the case where the client unmounts the partition and there are still open file descriptors.. its the clients problem. [Not sure if NFSv4 worked out local caching to 'fix' this.] > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 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 > -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More mono/koji problems
On Wed, Oct 20, 2010 at 07:24:05PM +0100, Paul F. Johnson wrote: > Hi, > > I'm still trying to get to the bottom as to why mono is failing to build > on koji as either a scratch build or as a live build and I've come > across this on the x86 build - can anyone shed any light on it as it's > about as useful an error throw back as 4/10 was back on the ZX81! > > make[3]: *** [libmonoruntimesgen_la-reflection.lo] Error 130 > > > I've looked up Error 130 and it's no real help. Can anyone shed any > light on what it means? It's not 'make' that is generating the error, it is just reporting it. The error comes from the return code of the command that last ran. For example: $ cat test.make all: exit 130 $ make -f test.make exit 130 make: *** [all] Error 130 I'm assuming from the target that the last command must have been libtool. But you can't really tell from that last line what the real error was. It must have been printed on the preceeding lines. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Asynchronous disk space monitoring
On 10/20/2010 04:18 PM, Stephen John Smoogen wrote: > On Wed, Oct 20, 2010 at 15:52, Orion Poplawski wrote: >> Somewhat OT, but not sure where else to ask. I'm looking into an issue where >> the nepomuk strigi service is preventing a desktop with an NFS mounted home >> directory from going into hibernate. I think this is because it continually >> checks the available disk space in the home directory (about once every 20 >> seconds in current 4.5.2, once every 10 seconds in 4.4.5). > > hibernate + network file systems has always been a rather tough nut . > NFS is built on the fact that multiple clients may have the same tree > open at the same time... so if you are going to hibernate you are > going to need to basicallly unmount because there is no guarentee that > anything underneath you will be there when you come out of > hibernation. Yeah, unfortunately unmounting causes other problems. See https://bugzilla.redhat.com/show_bug.cgi?id=287411 -- 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
Re: Asynchronous disk space monitoring
On Wed, Oct 20, 2010 at 15:52, Orion Poplawski wrote: > Somewhat OT, but not sure where else to ask. I'm looking into an issue where > the nepomuk strigi service is preventing a desktop with an NFS mounted home > directory from going into hibernate. I think this is because it continually > checks the available disk space in the home directory (about once every 20 > seconds in current 4.5.2, once every 10 seconds in 4.4.5). hibernate + network file systems has always been a rather tough nut . NFS is built on the fact that multiple clients may have the same tree open at the same time... so if you are going to hibernate you are going to need to basicallly unmount because there is no guarentee that anything underneath you will be there when you come out of hibernation. > I'm wondering if there is any better way to monitor disk space than by this > kind of polling. Any kind of inotify service? Or would this be worse on a > busy mount? Unless you could request notification only for reaching a > threshold. > inotify would only work if the server somehow was able to give information back to the client over inotify. > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 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 > -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Eclipse Fedora Packager: Call for Testers and Contributors
Hi Fedora Packagers, I would like to bring a new Eclipse plug-in to your attention: Eclipse Fedora Packager[1] It's a tool which can help speeding up your Fedora packaging work :-) In a nutshell, it offers similar features as the command-line client fedpkg, but with a GUI. Here's a list of its current features (more to come): - Conveniently clone Fedora Git projects, switch branches etc. - RPM-spec-file editor with syntax highlighting, auto-completion and changelog support (++C keyboard shortcut) - Download source files and upload new source files - Prepare local builds (execute %prep section of your spec-file) - Create source RPM files based on current spec-file - Execute local builds - Push builds to Koji (the Fedora build system) - Mock builds - Push Bodhi updates (the Fedora updates system) - Eclipse Git support (via EGit) If those features cover all (most) tasks you usually carry out when packaging your software for Fedora, Eclipse Fedora Packager may be a tool for you to look into. Still not sure? It might be the right tool for your Fedora packaging if: - You prefer GUI tools over command-line-clients - You are already familiar with Eclipse or some other IDE - You are a developer and you use Eclipse on a daily basis - You have never packaged something for Fedora, but would like to do so. - You don't know much about how software gets into Fedora but need to get it packaged for it. - Your main goal is to get your software packaged for Fedora as opposed to learning a lot of tooling. Sounds interesting? Want to try it out? Here's what you need to do (please note that Eclipse Fedora Packager will officially come with Fedora 14 for the first time): If you have a F14 box, "yum install eclipse-fedorapackager". Then fire up Eclipse and follow instructions of our user guide: https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide On F13 (I'm using it) and older (untested) you need to install some rawhide packages. This is what I usually do: 1.) Install dependencies (non-rawhide): $ yum install eclipse eclipse-changelog eclipse-rpm-editor \ fedora-release-rawhide fedora-packager 2.) Install eclipse-fedorapackager and eclipse-egit from rawhide $ yum install --enablerepo=rawhide eclipse-fedorapackger 3.) Follow our user guide[2] for information on how to get started using the plug-in. The latest version of eclipse-fedorapackager is 0.1.8 (in rawhide). Here's a link to today's build: https://koji.fedoraproject.org/koji/buildinfo?buildID=201275 Feedback, testing, bug reports, contributions are very much appreciated. Our Trac instance is here (use your FAS to login): https://fedorahosted.org/eclipse-fedorapackager/ If you have questions, run into problems or would be interested in contributing please let me know: email: sgehwolf AT redhat DOT com (this list is preferred) IRC: my nick is "jerboaa" (e.g. #fedora-devel or #fedora-java) I'll get back to you as soon as possible. In any case, let us know what you think ;-) Thanks, Severin [1] https://fedorahosted.org/eclipse-fedorapackager/ (Trac/wiki) [2] https://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unowned dirs
Orcan Ogetbil wrote: > On Wed, Oct 20, 2010 at 5:14 PM, Adam Jackson wrote: >> On Wed, 2010-10-20 at 17:07 -0400, Neal Becker wrote: >> >>> BTW, it's annoying that rpm allows only 1 %files -f. >> >> http://rpm.org/wiki/Releases/4.8.0 >> >> %files now accepts multiple filelists through -f (ticket #70, >> RhBug:475359) >> > > What is wrong with > cat list1 list2 list3 > listall > %files -f listall > > or even > cat list1 list2 >> list3 > %files -f list3 > > Orcan That's what I used to do. It's annoying (I have a low tolerance) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Asynchronous disk space monitoring
Somewhat OT, but not sure where else to ask. I'm looking into an issue where the nepomuk strigi service is preventing a desktop with an NFS mounted home directory from going into hibernate. I think this is because it continually checks the available disk space in the home directory (about once every 20 seconds in current 4.5.2, once every 10 seconds in 4.4.5). I'm wondering if there is any better way to monitor disk space than by this kind of polling. Any kind of inotify service? Or would this be worse on a busy mount? Unless you could request notification only for reaching a threshold. -- 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
Re: unowned dirs
On Wed, Oct 20, 2010 at 5:14 PM, Adam Jackson wrote: > On Wed, 2010-10-20 at 17:07 -0400, Neal Becker wrote: > >> BTW, it's annoying that rpm allows only 1 %files -f. > > http://rpm.org/wiki/Releases/4.8.0 > > %files now accepts multiple filelists through -f (ticket #70, > RhBug:475359) > What is wrong with cat list1 list2 list3 > listall %files -f listall or even cat list1 list2 >> list3 %files -f list3 Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unowned dirs
Ville Skyttä wrote:
> On Thursday 21 October 2010, Neal Becker wrote:
>
>> Right now I have:
>> %dir %{python_sitearch}/mercurial
>> %dir %{python_sitearch}/hgext
>>
>> I guess owning the parent dirs is not sufficient?
>
> Right.
>
>> I could auto-generate a list of directories, but don't know what to do
>> with it.
>>
>> Right now, I auto-generate lists of files, which are then used as:
>> %files -f %{name}-base+hg.lang.files
>
> Something like this in an appropriate place in %install should work
> (untested):
>
> find $RPM_BUILD_ROOT%{python_sitearch}/{mercurial,hgext}/* -type d \
> | sed -e "s|^$RPM_BUILD_ROOT\(.*\)|%%dir \1|" >>
> | %{name}-base+hg.lang.files
>
> (Or drop the "/*" and the explicitly listed mercurial and hgext %dir's you
> now have in %files.)
So I can have:
%dir blah
in a file included by -f? Didn't know that. (Wonder if it's documented?)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unowned dirs
On Thursday 21 October 2010, Neal Becker wrote:
> Right now I have:
> %dir %{python_sitearch}/mercurial
> %dir %{python_sitearch}/hgext
>
> I guess owning the parent dirs is not sufficient?
Right.
> I could auto-generate a list of directories, but don't know what to do with
> it.
>
> Right now, I auto-generate lists of files, which are then used as:
> %files -f %{name}-base+hg.lang.files
Something like this in an appropriate place in %install should work
(untested):
find $RPM_BUILD_ROOT%{python_sitearch}/{mercurial,hgext}/* -type d \
| sed -e "s|^$RPM_BUILD_ROOT\(.*\)|%%dir \1|" >> %{name}-base+hg.lang.files
(Or drop the "/*" and the explicitly listed mercurial and hgext %dir's you now
have in %files.)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unowned dirs
Adam Jackson wrote: > On Wed, 2010-10-20 at 17:07 -0400, Neal Becker wrote: > >> BTW, it's annoying that rpm allows only 1 %files -f. > > http://rpm.org/wiki/Releases/4.8.0 > > %files now accepts multiple filelists through -f (ticket #70, > RhBug:475359) > > - ajax I guess fedora guidelines need updating then. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libOSMesa soname bump and etc
On Wed, 2010-10-20 at 12:12 -0600, Orion Poplawski wrote: > Please fix https://bugzilla.redhat.com/show_bug.cgi?id=635865 while you're at > it, or paraview won't build. Thanks! Done (upstream, even), thanks! - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unowned dirs
On Wed, 2010-10-20 at 17:07 -0400, Neal Becker wrote: > BTW, it's annoying that rpm allows only 1 %files -f. http://rpm.org/wiki/Releases/4.8.0 %files now accepts multiple filelists through -f (ticket #70, RhBug:475359) - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
unowned dirs
https://bugzilla.redhat.com/show_bug.cgi?id=645079
Various dirs are created by the install process. These dirs under hgext
could vary depending on whatever extensions upstream decides to package.
I'd prefer not to have to keep changing the spec to reflect those changes,
but to automate the process.
Right now I have:
%dir %{python_sitearch}/mercurial
%dir %{python_sitearch}/hgext
I guess owning the parent dirs is not sufficient?
I could auto-generate a list of directories, but don't know what to do with
it.
Right now, I auto-generate lists of files, which are then used as:
%files -f %{name}-base+hg.lang.files
Would adding directories to %files -f fix this?
BTW, it's annoying that rpm allows only 1 %files -f.
BTW, it's annoying that rpm doesn't use a real programming language, e.g.,
python.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Updated openmpi in rawhide
I upgraded the openmpi in rawhide to 1.5, which involves a soname bump. Therefore the following packages need to be recompiled: R-RScaLAPACK ScientificPython boost freefem++ gromacs paraview pypar towhee valgrind (The other packages that depend on openmpi have already been rebuilt.) I'm also going to update openmpi in F-13 and F-14 to 1.4.3, but that won't require rebuilds of dependent packages. -- JF -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Viewing a scratch-build
On Wed, 20 Oct 2010, Paul F. Johnson wrote: > Hi, > > I've followed the instructions on the fedoraproject website to try and > view a scratch-build result (go to tasks and select the scratch build), > but it's not showing anything for rawhide scratch builds. > > Is there some sort of magic I need to invoke to get it to show? Go to the koji users page http://koji.fedoraproject.org/koji/users find yourself in the list, select the view tasks button on your row, then change State from active to all (other options like closed probably work as well). Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo meeting (2010-10-20) NEW TIME!
=== #fedora-meeting: FESCO (2010-10-20) === Meeting started by nirik at 18:30:10 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-20/fesco.2010-10-20-18.30.log.html Meeting summary --- * init process (nirik, 18:30:11) * Updates policy / Vision implementation status (nirik, 18:33:36) * #475 fesco ok with kde-sig requesting custom f12 koji target to make an unofficial kde-4.5 update? (nirik, 18:40:37) * AGREED: request granted. Please untag when done. Will try and gather more resources for koji disk moving forward. (nirik, 18:56:23) * AGREED: This feature is approved. (nirik, 19:01:15) * AGREED: This feature is approved. (nirik, 19:03:17) * AGREED: This feature is approved. (nirik, 19:05:57) * Open Floor (nirik, 19:06:21) * LINK: http://torrent.fedoraproject.org:6969/ (nirik, 19:09:38) * AGREED: Will drop split cd media in f15. (nirik, 19:15:16) Meeting ended at 19:22:08 UTC. -- 18:30:10 #startmeeting FESCO (2010-10-20) 18:30:10 Meeting started Wed Oct 20 18:30:10 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:11 #meetingname fesco 18:30:11 The meeting name has been set to 'fesco' 18:30:11 #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 18:30:11 #topic init process 18:30:11 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 18:30:19 Afternoon 18:31:09 I think notting was going to be traveling today. 18:31:13 yeah 18:31:21 not sure if mclasen was going to be able to make it or not. 18:31:30 18:31:38 * SMParrish here 18:33:04 ok, I see ajax, kylem, mjg59, nirik, and pjones here. mclasen, notting, cwickert absent. 18:33:31 so, I guess lets go ahead... 18:33:36 #topic Updates policy / Vision implementation status 18:33:36 .fesco 351 18:33:36 .fesco 382 18:33:37 nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 18:33:41 nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 18:33:50 our fine updates topic. 18:33:58 SMParrish: any news on stats gathering? 18:34:58 nirik: Unfortunately no. Been a hectic week here ( 18:35:05 yeah, I know the feeling. 18:35:21 would anyone have time in the upcoming week to help work on it? perhaps adding a few folks could get it moving along? 18:36:01 Help would be appreciated. I will be out of town all weekend attending OLPC-SFO so I wont have time until I get back on Tuesday 18:36:15 * nirik is also going to be traveling from tomorrow->sunday. 18:37:48 i'd volunteer but my week is pretty booked as it is 18:37:56 ok, well, I guess we will get to it as we get time. Perhaps we could brainstorm some in ticket? or ask luke what is generated now and go from there? 18:38:13 nirik: sounds like a good idea 18:38:32 ok. 18:39:01 Also, we have pending here: enforcement (save for last) and possibly doing a enhancement/features repo... (cwickert was going to work on that) 18:39:25 anything else on updates for now? or shall we move on? 18:40:22 ok, moving on then... 18:40:37 #topic #475 fesco ok with kde-sig requesting custom f12 koji target to make an unofficial kde-4.5 update? 18:40:38 .fesco 475 18:40:38 nirik: #475 (fesco ok with kde-sig requesting custom f12 koji target to make an unofficial kde-4.5 update?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/475 18:40:58 go wild. 18:41:06 * rdieter lurks for any questions 18:41:07 * nirik has no particular issue with it. 18:41:26 i'm generally in favor of targetted koji tags like that 18:41:34 Yes, I think this is a good plan 18:41:40 rdieter: would it build from some other branch? or ? 18:42:10 as teh person who looks after koji, i do think we need to consider the stroage and extra load that it will cause 18:42:18 nirik: I'm going to try that first yeah, but will do whatever it takes 18:42:50 dgilmore: do we have any guidance on what kind of added loads are acceptable for this kind of thing? 18:42:51 dgilmore: If it's an issue, then I think we should ask the board for resources to support this 18:43:03 dgilmore: I promise to --background everything 18:43:18 rdieter: that really doesnt matter 18:43:19 dgilmore: This kind of thing is a natural outcome of the updates policy - I'm pretty certain that we'll be seeing more examples of updates like this 18:43:40 im fighting a loosing fight to keep more than 10% free on /mnt/koji 18:43:49 the builds take up disk space 18:43:52 and KDE is big 18:44:00 * nirik gets a phone call. 18:44:09 dgilmore: Ok. Should we be asking the board for more disk? 18:44:09 dgilmore: If I understand it tag will be temporary 18:44:19 dgilmore: when we're done, I don't mind garbage collecting it all, if that m
Re: PyQt + python3?
Neal Becker wrote: > Rex Dieter wrote: > >> Stanislav Ochotnicky wrote: >> >>> On 10/20/2010 02:38 PM, Neal Becker wrote: Has anyone attempted a pyqt for python3? >>> >>> I did. It failed (not on Fedora though and I didn't investigate at the >>> time). I seem to remember some symbol problems with QString class that >>> was reported when I tried to import PyQt from python3 interpreter. >> >> python3-PyQt4 should work (theoretically), but has seen very little real- >> world use or testing yet. Please file bugs. > Only for f14+, correct? yes (though I think we could also theoretically provide f13 builds too, for good cause) -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 645060] New: perl-JSON-2.26 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-JSON-2.26 is available https://bugzilla.redhat.com/show_bug.cgi?id=645060 Summary: perl-JSON-2.26 is available Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-JSON AssignedTo: cw...@alumni.drew.edu ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora Latest upstream release: 2.26 Current version in Fedora Rawhide: 2.17 URL: http://search.cpan.org/dist/JSON/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: PyQt + python3?
Rex Dieter wrote: > Stanislav Ochotnicky wrote: > >> On 10/20/2010 02:38 PM, Neal Becker wrote: >>> Has anyone attempted a pyqt for python3? >> >> I did. It failed (not on Fedora though and I didn't investigate at the >> time). I seem to remember some symbol problems with QString class that >> was reported when I tried to import PyQt from python3 interpreter. > > python3-PyQt4 should work (theoretically), but has seen very little real- > world use or testing yet. Please file bugs. > > -- Rex > > Only for f14+, correct? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there anyone known how to contact Xavier Lamien?
On Thu, Oct 21, 2010 at 01:33:56AM +0800, Chen Lei wrote: > Hi, > > Currently, pitivi 0.13.4 in fedora crashes frequently, I want to > update pitivi to the latest verison. But we need to update > gstreamer-python to 0.10.19 first, can anybody help to contact Xavier > Lamien? If you are on IRC try to contact SmootherFroGz (not sure about the case though). Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
More mono/koji problems
Hi, I'm still trying to get to the bottom as to why mono is failing to build on koji as either a scratch build or as a live build and I've come across this on the x86 build - can anyone shed any light on it as it's about as useful an error throw back as 4/10 was back on the ZX81! make[3]: *** [libmonoruntimesgen_la-reflection.lo] Error 130 I've looked up Error 130 and it's no real help. Can anyone shed any light on what it means? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Viewing a scratch-build
Hi, I've followed the instructions on the fedoraproject website to try and view a scratch-build result (go to tasks and select the scratch build), but it's not showing anything for rawhide scratch builds. Is there some sort of magic I need to invoke to get it to show? TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: libOSMesa soname bump and etc
On 10/20/2010 11:49 AM, Adam Jackson wrote: > We've been carrying a patch to libOSMesa for far too long now to fix the > soname at .6, since there was no actual ABI change between .6 and .7. > I'm tired of porting the patch so it'll be libOSMesa.so.7 in the next > Mesa build in F15. > > The only affected packages seem to be vtk and paraview, so I'll kick off > rebuilds for them as well. > > In related news, nothing seems to be using libOSMesa16 or libOSMesa32, > so they're getting dropped. If they're being used in an external repo > please let me know, and if they are then we should probably figure out > alternate packaging for them since it doesn't make sense to upgrade them > at the same rate as the DRI drivers. > > - ajax > Please fix https://bugzilla.redhat.com/show_bug.cgi?id=635865 while you're at it, or paraview won't build. Thanks! -- 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
Heads up: libOSMesa soname bump and etc
We've been carrying a patch to libOSMesa for far too long now to fix the soname at .6, since there was no actual ABI change between .6 and .7. I'm tired of porting the patch so it'll be libOSMesa.so.7 in the next Mesa build in F15. The only affected packages seem to be vtk and paraview, so I'll kick off rebuilds for them as well. In related news, nothing seems to be using libOSMesa16 or libOSMesa32, so they're getting dropped. If they're being used in an external repo please let me know, and if they are then we should probably figure out alternate packaging for them since it doesn't make sense to upgrade them at the same rate as the DRI drivers. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 04:13 PM, James Antill wrote: > Also, are we sure that people don't want to change any options other > than "ro" (the only thing you can tweak with the bind trick, AIUI)? I > thought someone mentioned noatime... I don't really think noatime is as big of a consideration any more, now that we're normally mounting with relatime. -- Peter THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is there anyone known how to contact Xavier Lamien?
Hi, Currently, pitivi 0.13.4 in fedora crashes frequently, I want to update pitivi to the latest verison. But we need to update gstreamer-python to 0.10.19 first, can anybody help to contact Xavier Lamien? See https://bugzilla.redhat.com/show_bug.cgi?id=634093 Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Who is working on python3 packages?
On Wed, Oct 20, 2010 at 03:57:07PM +0200, Thomas Spura wrote: > On Wed, 20 Oct 2010 09:22:14 -0400 > Neal Becker wrote: > > > Thomas Spura wrote: > > > > > On Wed, 20 Oct 2010 08:36:23 -0400 > > > Neal Becker wrote: > > > > > >> I have started porting to python3. So far I have a patch for > > >> fpconst. I have not so far been able to contact upstream. > > >> > > >> Maybe we should start a SIG for this? > > >> > > > > > >>From time to time, I try to enable a python3 subpackage and open a > > >>bug, > > > so the original maintainer accept that change to the package. > > > If upstream released an extra python3 package, I sometimes package > > > that and get it in fedora. > > > > > > I don't think we need a python3 SIG for that. Isn't the python SIG > > > enought? ;-) > > > http://fedoraproject.org/wiki/SIGs/Python > > > > > +1 Python SIG is small but reasonably active. We've worked on the python-2.x rebuilds and python-3.x (smaller package set) rebuilds together. > > Going forward, we should expect the current fedora packagers to > > provide python3 versions? So bug reports (patches for python3) for > > fedora python packages should be directed to the respective > > maintainers? > > > > It depends on the respective upstream, some upstreams release two > different tar balls for python2 and python3 (e.g. chardet). Then we > need two different packages, if not it's possible to do it in one spec. > See: > https://fedoraproject.org/wiki/Packaging:Python#Common_SRPM_vs_split_SRPMs > > But if the maintainer of the python2 package hesitates to build a > python3 package and you want one, you cannot force him to do so... > Then I don't see another way, than submit a new package review request > for the python3 package. > > So to answer your question: > I don't 'expect' the current fedora > packagers to provide python3 versions, but I 'hope' they do so... > > In your case, you still need to try to contact upstream, or you are > doing a fork (see > https://fedoraproject.org/wiki/Packaging:Python#Subpackages). > In particular, that section says not to package a module for python3 without upstream support. If upstream is not responsive (either at all or specifically doesn't want to make a python3 package) you *can* fork it and start a python3 version. However, you are forking and becoming upstream for the forked version -- so you need to budget your time for that and make upstream releases (probably on pypi), etc. This would also make it a case of having two upstream tarballs and therefore two packages in Fedora. One last note -- I've been talking with Barry Warsaw (mailman author, upstream python hacker, one of the python guys for Ubuntu) about the possibility of creating a common project for distributions to get together and help port modules to python3. If anyone has some ideas about requirements for doing that, I'd be interested in hearing ideas. -Toshio pgpbSXdFRUa8a.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Who is working on python3 packages?
On Wed, 2010-10-20 at 15:57 +0200, Thomas Spura wrote: > On Wed, 20 Oct 2010 09:22:14 -0400 > Neal Becker wrote: > > > Thomas Spura wrote: > > > > > On Wed, 20 Oct 2010 08:36:23 -0400 > > > Neal Becker wrote: > > > > > >> I have started porting to python3. So far I have a patch for > > >> fpconst. I have not so far been able to contact upstream. > > >> > > >> Maybe we should start a SIG for this? > > >> > > > > > >>From time to time, I try to enable a python3 subpackage and open a > > >>bug, > > > so the original maintainer accept that change to the package. > > > If upstream released an extra python3 package, I sometimes package > > > that and get it in fedora. > > > > > > I don't think we need a python3 SIG for that. Isn't the python SIG > > > enought? ;-) > > > http://fedoraproject.org/wiki/SIGs/Python > > > > > > > Going forward, we should expect the current fedora packagers to > > provide python3 versions? So bug reports (patches for python3) for > > fedora python packages should be directed to the respective > > maintainers? > > > > It depends on the respective upstream, some upstreams release two > different tar balls for python2 and python3 (e.g. chardet). Then we > need two different packages, if not it's possible to do it in one spec. > See: > https://fedoraproject.org/wiki/Packaging:Python#Common_SRPM_vs_split_SRPMs > > But if the maintainer of the python2 package hesitates to build a > python3 package and you want one, you cannot force him to do so... > Then I don't see another way, than submit a new package review request > for the python3 package. > > So to answer your question: > I don't 'expect' the current fedora > packagers to provide python3 versions, but I 'hope' they do so... > > In your case, you still need to try to contact upstream, or you are > doing a fork (see > https://fedoraproject.org/wiki/Packaging:Python#Subpackages). Ditto to everything Thomas said, however we may be running into another problem. If I'm reading: http://pypi.python.org/pypi/fpconst/ correctly, that project hasn't had an upstream update in over four years, and the upstream home page seems to be dead. So there may be a number of python 2 modules that are either mature or "good enough", but need porting to work with python 3, and in some of these cases, upstream may have either disappeared, or lost interest. My feeling here is that you should make a strong effort to contact upstream (I'm guessing you've already tried this). If that fails, http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream has some notes on "Dead Or Unresponsive Upstream Projects": "In cases where upstream projects are either dead or unresponsive, it might be acceptable to patch the software. If upstream is dead, you might want to consider sharing patches with other distributions or taking over maintenance if you have the time, skills, and interest. Be wary of maintaining software with no upstream since all the burden of maintaining the codebase as well as packaging issues are with you. If upstream is unresponsive and many distributions are deviating significantly, it might be a opportunity for a cross distribution fork (Similar to XFree86 and Xorg)." I see that you sent a patch to the python-dev mailing list: http://mail.python.org/pipermail/python-dev/2010-October/104784.html asking about this specific project. I'm not sure how best to go forward with this kind of thing. IIRC "fpconst" is a fairly simple module, and the patch looks simple enough that it seems reasonable to patch downstream and get a python3-fpconst - but we don't want every different Linux distribution patching things in different ways, so perhaps you should talk to e.g. Debian and Gentoo maintainers of fpconst as well? Perhaps we need a new category on: https://fedoraproject.org/wiki/Python3#Porting_status something like "Python 3 code based on Python 2 code with apparently-dead upstream" or somesuch? Hope this is helpful. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101020 changes
Compose started at Wed Oct 20 13:15:08 UTC 2010 Broken deps for x86_64 -- fldigi-3.20.28-2.fc14.x86_64 requires libxmlrpc++.so.7()(64bit) fldigi-3.20.28-2.fc14.x86_64 requires libxmlrpc_server++.so.7()(64bit) fldigi-3.20.28-2.fc14.x86_64 requires libxmlrpc_server_abyss++.so.7()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) Broken deps for i386 -- fldigi-3.20.28-2.fc14.i686 requires libxmlrpc_server++.so.7 fldigi-3.20.28-2.fc14.i686 requires libxmlrpc_server_abyss++.so.7 fldigi-3.20.28-2.fc14.i686 requires libxmlrpc++.so.7 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rakudo-0.0.2010.08_2.7.0-1.fc14.i686 requires libparrot.so.2.7.0 Updated Packages: anaconda-14.21-1.fc14 - * Mon Oct 18 2010 Brian C. Lane - 14.21-1 - Take into account hidden disks (#583906) (bcl) * Thu Oct 14 2010 David Lehman - 14.20-1 - Make sure we have the container before the member arrays. (#642765) (dlehman) - use different approach to tweak gconf settings in the image (#642358). (akozumpl) - anaconda: Disable X server regenerations (#609245) (ajax) - Rescan disks when moving back through upgrade check (#635778) (bcl) - Turn off betanag. (#642483) (dlehman) * Mon Oct 11 2010 David Lehman - 14.19-1 - Attempt to bring the network up before saving a bug report (#635821). (clumens) - Honor selected hostname on Live CD (#638634) (rvykydal) - Fix permissions of wepkey file to 0600 (#636099) (rvykydal) - Preset default config for immediate Close in nm-c-e enablement (#641308) (rvykydal) - Fix non-dhcp network enablement in stage 2 (#640951) (rvykydal) * Wed Oct 06 2010 David Lehman - 14.18-1 - Fix a storage logging import (#636621). (clumens) - Fix setting of $HOME (pjones) - Properly rescan storage with Reset in partition GUI (#635778) (bcl) - Save the partition type selection when moving back (#635778) (bcl) - Properly rescan disks when moving back (#635778) (bcl) - Fix EFI bootloader install problems (#635873, #635887) (bcl) - Re-add cleardiskssel step when autopart is chosen. (#635332) (dlehman) - Pull boot splash image from correct location (#635330) (bcl) - Add files for polkit to initrd.img (#633315) (rvykydal) - Remove old kernels with new bootloader (#633234) (bcl) - Both the inittab and systemd sections can return. Move this part earlier. (notting) - Pass xdriver to anaconda in liveinst (#633827) (bcl) - Reset resolver after network device activation (#632489) (rvykydal) - Fix importing the netconfig UI in rescue mode (#632510). (clumens) - iscsi: rename variable in addIscsiDrive. (akozumpl) - Re-fix systemd default link (#627401, mschmidt). (clumens) - Remove losetup and unlosetup from isys (bcl) - Remove losetup usage (bcl) - Various upd-instroot cleanups, most importantly for firstaidkit (#627758). (clumens) fldigi-3.20.28-2.fc14 - * Wed Oct 13 2010 Randall J. Berry - 3.20.28-2 - Rebuild for libxmlrpc_*.so.7 BZ 641904 * Tue Oct 12 2010 Randall J. Berry - 3.20.28-1 - Upstream Update 3.20.28 * Tue Oct 12 2010 Randall J. Berry - 3.20.27-2 - Rebuild for broken dep xmlrpc BZ 641904 * Sun Sep 05 2010 Randall J. Berry - 3.20.27-1 - Upstream update to 3.20.27 - Added call to Abort_ARQ when double ESC pressed (panic) - Added supporting code in modem class. * Fri Sep 03 2010 Randall J. Berry 3.20.25-2 - Rebuild for broken deps F14 * Mon Aug 30 2010 Randall J. Berry 3.20.25-1 - Upstream update 3.20.25 * Sat Aug 28 2010 Randall J. Berry 3.20.24-1 - Upstream update to 3.20.24 - Rebuild for F15-Rawhide * Sat Aug 07 2010 Randall J. Berry 3.20.22-1 - Upstream update to 3.20.22 - Cleanup spec glibc-2.12.90-17 * Tue Oct 19 2010 Andreas Schwab - 2.12.90-17 - Update from master - Fix some fma issues, implement fmal (BZ#3268, #43358) - Expect PLT call to _Unwind_Find_FDE on s390*-linux - Never expand $ORIGIN in privileged programs (#643306, CVE-2010-3847) * Thu Oct 14 2010 Andreas Schwab - 2.12.90-16 - Update from master - Implement accurate fma (BZ#3268, #43358) - Fix alignment of AVX save area on x86-64 (BZ#12113) - Fix regex memory leaks (BZ#12078) - Improve output of psiginfo (BZ#12107, BZ#12108) - Don't return NULL address in getifaddrs (BZ#12093) - Fix strstr and memmem algorithm (BZ#12092, #641124) - Don't discard result of decoding ACE if AI_CANONIDN (#636642) - Remove /etc/gai.conf from glibc-common and mark it %ghost in glibc - Require exact glibc version in nscd lvm2-2.02.73-3.fc14 --- * Fri Oct 15 2010 Alasdair Kergon - 2.02.73-3 - Add --setuuid to dmsetup rename. - Add dm_task_set_newuuid to set uuid of mapped device post-creation. * Wed Sep 29 2010 jkeating - 2.02.73-2.1 - Rebuilt for gcc bug 634757 * Wed Aug 25
Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Oct 2010 14:02:49 +0200, you wrote: >The question is (we agreed on KDE SIG meeting yesterday) - should we update Qt >to 4.7 too or build KDE stack with current 4.6 series? As there are a few Qt >packages outside of KDE SIG/Qt maintainers scope, we'd like to hear any >objections against update - bugs we can fix etc. Qt 4.7 is quite well tested, >thanks to work on Fedora 14 (Qt 4.7 is already included) and a lot of users >are >actually using this combination in Fedora 13. Is there a version of PyQt built agains qt-4.7. If so, I can build my application which are depending on it agains the new release. I think there should no issue to build my applications agains a new qt release. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.0.2 (Build 13) Charset: us-ascii wj8DBQFMvv+QT2AHK6txfgwRAp2CAJsFLrzbXv5bv/sk/5XuL3rnsSRW6wCfaHTc PtrusXpH7FaQtScMWnq1m6Y= =ZfW6 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Bill Nottingham wrote: > Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, > and so on were just symlinks to /usr/bin, /usr/lib, and so on. Tru64 (Yes, it's still supported!) does: gho...@seraph ~ % uname -a OSF1 seraph.tetraforge.com V5.1 2650 alpha gho...@seraph ~ % ls -l /bin /lib lrwxr-xr-x 1 root system 7 Apr 21 2010 /bin@ -> usr/bin/ lrwxr-xr-x 1 root system 7 Apr 21 2010 /lib@ -> usr/lib/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PyQt + python3?
Stanislav Ochotnicky wrote: > On 10/20/2010 02:38 PM, Neal Becker wrote: >> Has anyone attempted a pyqt for python3? > > I did. It failed (not on Fedora though and I didn't investigate at the > time). I seem to remember some symbol problems with QString class that > was reported when I tried to import PyQt from python3 interpreter. python3-PyQt4 should work (theoretically), but has seen very little real- world use or testing yet. Please file bugs. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Who is working on python3 packages?
On Wed, 20 Oct 2010 09:22:14 -0400 Neal Becker wrote: > Thomas Spura wrote: > > > On Wed, 20 Oct 2010 08:36:23 -0400 > > Neal Becker wrote: > > > >> I have started porting to python3. So far I have a patch for > >> fpconst. I have not so far been able to contact upstream. > >> > >> Maybe we should start a SIG for this? > >> > > > >>From time to time, I try to enable a python3 subpackage and open a > >>bug, > > so the original maintainer accept that change to the package. > > If upstream released an extra python3 package, I sometimes package > > that and get it in fedora. > > > > I don't think we need a python3 SIG for that. Isn't the python SIG > > enought? ;-) > > http://fedoraproject.org/wiki/SIGs/Python > > > > Going forward, we should expect the current fedora packagers to > provide python3 versions? So bug reports (patches for python3) for > fedora python packages should be directed to the respective > maintainers? > It depends on the respective upstream, some upstreams release two different tar balls for python2 and python3 (e.g. chardet). Then we need two different packages, if not it's possible to do it in one spec. See: https://fedoraproject.org/wiki/Packaging:Python#Common_SRPM_vs_split_SRPMs But if the maintainer of the python2 package hesitates to build a python3 package and you want one, you cannot force him to do so... Then I don't see another way, than submit a new package review request for the python3 package. So to answer your question: I don't 'expect' the current fedora packagers to provide python3 versions, but I 'hope' they do so... In your case, you still need to try to contact upstream, or you are doing a fork (see https://fedoraproject.org/wiki/Packaging:Python#Subpackages). -- Thomas Spura -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Who is working on python3 packages?
Thomas Spura wrote: > On Wed, 20 Oct 2010 08:36:23 -0400 > Neal Becker wrote: > >> I have started porting to python3. So far I have a patch for >> fpconst. I have not so far been able to contact upstream. >> >> Maybe we should start a SIG for this? >> > >>From time to time, I try to enable a python3 subpackage and open a bug, > so the original maintainer accept that change to the package. > If upstream released an extra python3 package, I sometimes package that > and get it in fedora. > > I don't think we need a python3 SIG for that. Isn't the python SIG > enought? ;-) > http://fedoraproject.org/wiki/SIGs/Python > Going forward, we should expect the current fedora packagers to provide python3 versions? So bug reports (patches for python3) for fedora python packages should be directed to the respective maintainers? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101020 changes
On Wed, 20 Oct 2010 13:11:20 + Rawhide Report wrote: > Compose started at Wed Oct 20 08:15:04 UTC 2010 > > Broken deps for x86_64 > -- > dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 > > > Broken deps for i386 > -- > dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 Should be fixed now: http://koji.fedoraproject.org/koji/buildinfo?buildID=201221 -- Thomas Spura -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Who is working on python3 packages?
On Wed, 20 Oct 2010 08:36:23 -0400 Neal Becker wrote: > I have started porting to python3. So far I have a patch for > fpconst. I have not so far been able to contact upstream. > > Maybe we should start a SIG for this? > >From time to time, I try to enable a python3 subpackage and open a bug, so the original maintainer accept that change to the package. If upstream released an extra python3 package, I sometimes package that and get it in fedora. I don't think we need a python3 SIG for that. Isn't the python SIG enought? ;-) http://fedoraproject.org/wiki/SIGs/Python -- Thomas Spura -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101020 changes
Compose started at Wed Oct 20 08:15:04 UTC 2010 Broken deps for x86_64 -- R-RScaLAPACK-0.6.1-4.fc14.x86_64 requires libmpi.so.0()(64bit) R-RScaLAPACK-0.6.1-4.fc14.x86_64 requires libopen-rte.so.0()(64bit) R-RScaLAPACK-0.6.1-4.fc14.x86_64 requires libopen-pal.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libmpi.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libopen-rte.so.0()(64bit) ScientificPython-2.8-11.fc14.x86_64 requires libopen-pal.so.0()(64bit) 1:anjuta-2.31.90.0-3.fc15.i686 requires libvala-0.10.so.0 1:anjuta-2.31.90.0-3.fc15.x86_64 requires libvala-0.10.so.0()(64bit) boost-graph-mpich2-1.44.0-1.fc15.i686 requires libmpich.so.1.2 boost-graph-mpich2-1.44.0-1.fc15.i686 requires libmpichcxx.so.1.2 boost-graph-mpich2-1.44.0-1.fc15.x86_64 requires libmpich.so.1.2()(64bit) boost-graph-mpich2-1.44.0-1.fc15.x86_64 requires libmpichcxx.so.1.2()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libmpi.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) boost-graph-openmpi-1.44.0-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) boost-mpich2-1.44.0-1.fc15.i686 requires libmpich.so.1.2 boost-mpich2-1.44.0-1.fc15.i686 requires libmpichcxx.so.1.2 boost-mpich2-1.44.0-1.fc15.x86_64 requires libmpich.so.1.2()(64bit) boost-mpich2-1.44.0-1.fc15.x86_64 requires libmpichcxx.so.1.2()(64bit) boost-mpich2-python-1.44.0-1.fc15.i686 requires libmpich.so.1.2 boost-mpich2-python-1.44.0-1.fc15.i686 requires libmpichcxx.so.1.2 boost-mpich2-python-1.44.0-1.fc15.x86_64 requires libmpich.so.1.2()(64bit) boost-mpich2-python-1.44.0-1.fc15.x86_64 requires libmpichcxx.so.1.2()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libmpi.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) boost-openmpi-1.44.0-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libmpi.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libopen-rte.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) boost-openmpi-python-1.44.0-1.fc15.x86_64 requires libopen-pal.so.0()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-rte.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libmpi_cxx.so.0()(64bit) freefem++-mpi-3.9-2.1.fc15.x86_64 requires libopen-pal.so.0()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel >= 0:2.91 gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gromacs-mpich2-4.5.1-1.fc15.i686 requires libmpich.so.1.2 gromacs-mpich2-4.5.1-1.fc15.i686 requires libmpichcxx.so.1.2 gromacs-mpich2-4.5.1-1.fc15.x86_64 requires libm
Re: rawhide report: 20101019 changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 08:13 AM, Daniel J Walsh wrote: > On 10/20/2010 07:52 AM, Richard W.M. Jones wrote: >> On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote: >>> On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: Once upon a time, James Antill said: > Putting my really old sysadmin hat on, one other reason for > having /tmp, /var and /usr as separate mount points was so that you > could allocate different disk space to each (and they couldn't break > each other) ... do we have other solutions for that? On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well. >>> >>> Not to get too far off into the weeds but Polyinstantianed tmpdir >>> (pam_namespace) are a good idea here. Everyone gets their on /tmp >>> and /var/tmp and no one else can see them. > >> +1 ... we should have had this a long time ago. > >> Rich. > > I have been trying to get system processes to stop using /tmp for years. > > http://danwalsh.livejournal.com/11467.html > > As some one who lives with polyinstatiated namespace /tmp, The only > problem I know of now is handing of kerberos tickets. Whenever a system > process (root) needs to communicate with a user via /tmp. namespace > /tmp breaks it. sssd can not create kerberos tickets in my /tmp and > gssd can not find my kerberos tickets in /tmp. I believe the solution > to both is to move the tickets to be managed by sssd and leave /tmp to > users. > > BTW, X has solved this problem a couple of years ago by using virtual > namespace for its sockets. https://fedorahosted.org/sssd/ticket/652 has been opened upstream with SSSD to add this functionality. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky+52gACgkQeiVVYja6o6OS4gCfb3UpMz3sEUmKg6/t6YGiCYqC 3lMAoKQRiHRbnINBuM4nKxXshnrpTzOh =sJcU -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PyQt + python3?
On 10/20/2010 02:38 PM, Neal Becker wrote: > Has anyone attempted a pyqt for python3? I did. It failed (not on Fedora though and I didn't investigate at the time). I seem to remember some symbol problems with QString class that was reported when I tried to import PyQt from python3 interpreter. -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Who is working on python3 packages?
I have started porting to python3. So far I have a patch for fpconst. I have not so far been able to contact upstream. Maybe we should start a SIG for this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PyQt + python3?
Has anyone attempted a pyqt for python3? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 07:52 AM, Richard W.M. Jones wrote: > On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote: >> On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: >>> Once upon a time, James Antill said: Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that? >>> >>> On a multi-user server (and that includes web access like PHP or CGI), >>> you really don't want user-writable directories on a filesystem with >>> anything important, especially security-sensitive things like setuid >>> binaries. Hard-link tricks are evil. I run with a separate /tmp >>> (usually tmpfs now) and bind mount it to /var/tmp as well. >> >> Not to get too far off into the weeds but Polyinstantianed tmpdir >> (pam_namespace) are a good idea here. Everyone gets their on /tmp >> and /var/tmp and no one else can see them. > > +1 ... we should have had this a long time ago. > > Rich. > I have been trying to get system processes to stop using /tmp for years. http://danwalsh.livejournal.com/11467.html As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users. BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky+3P8ACgkQrlYvE4MpobNZLgCffWqapIi1E1FkfC1TnRjjE/xY 3uoAoIvTwYGvXao91mSzubGiTssKHNAx =Qw58 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote: > On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: > > Once upon a time, James Antill said: > > > Putting my really old sysadmin hat on, one other reason for > > > having /tmp, /var and /usr as separate mount points was so that you > > > could allocate different disk space to each (and they couldn't break > > > each other) ... do we have other solutions for that? > > > > On a multi-user server (and that includes web access like PHP or CGI), > > you really don't want user-writable directories on a filesystem with > > anything important, especially security-sensitive things like setuid > > binaries. Hard-link tricks are evil. I run with a separate /tmp > > (usually tmpfs now) and bind mount it to /var/tmp as well. > > Not to get too far off into the weeds but Polyinstantianed tmpdir > (pam_namespace) are a good idea here. Everyone gets their on /tmp > and /var/tmp and no one else can see them. +1 ... we should have had this a long time ago. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Java SIG Oct 19 meeting minutes & summary
Hi everyone, We had our bi-weekly meeting yesterday so I'm going to summarize what is happening right now in Fedora-Java world. People present: * cspike * ggraz * mbooth * akurtakov * sochotni Status updates: * Maven 3 - work on custom resolver is starting ** will publish git repo on java-devel in due time * Packages monitored by java sig ** List is getting longer, once semi-finished akurtakov will ask for java-sig user to be created and added to these packages for watchcommits ** agreed that commits will be sent to java-devel * New guidelines are shaping up, several new improvements suggested ** see, comment, improve: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate * Finishing up jakarta->apache rename (packages ready, need maintainers of original packages to retire them - fnasser, jmrodri) ** also create apache-commons-parent package with proper requires/pom.xml Meetbot minutes (note that assigned actions look a bit like two man show, but that's not the case...we just forgot to do #action properly :-) ) = #fedora-meeting: Java SIG -- https://fedoraproject.org/wiki/SIGs/Java = Meeting started by akurtakov_ at 17:02:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-19/fedora-meeting.2010-10-19-17.02.log.html . Meeting summary --- * roll-call (akurtakov_, 17:03:38) * akurtakov_ cspike ggraz mbooth sochotni present (sochotni, 17:04:00) * akurtakov_ cspike ggraz mbooth sochotni present (akurtakov_, 17:04:25) * maven 3 status (akurtakov_, 17:05:33) * LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm (sochotni, 17:06:37) * LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm maven 3 source rpm (sochotni, 17:06:45) * LINK: https://fedoraproject.org/wiki/MavenUpdate#Maven_3 may be helpful, too (cspike, 17:06:58) * LINK: http://sochotni.fedorapeople.org/maven-3.0-1.fc15.noarch.rpm maven 3 binary rpm (sochotni, 17:07:01) * ACTION: sochotni will put maven 3 spec for review (sochotni, 17:12:25) * ACTION: sochotni will create public git repo with custom resolver so others can see/review (sochotni, 17:12:56) * new resolver should be basically re-implemented maven-aether-provider (sochotni, 17:14:45) * Java packages monitoring (sochotni, 17:15:04) * LINK: https://fedoraproject.org/wiki/SIGs/Java/Monitored_packages Wiki to collect Java packages for monitoring (sochotni, 17:15:27) * LINK: https://fedorahosted.org/fedora-infrastructure/ infra ticketing system (sochotni, 17:19:26) * ACTION: akurtakov_ will file infra ticket asking for java pseudo user (sochotni, 17:19:44) * java-sig user will forward to java-devel mailing list (sochotni, 17:26:08) * New packaging guidelines (akurtakov_, 17:26:54) * LINK: https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate Draft (sochotni, 17:27:15) * ACTION: akurtakov_ to add javadoc:aggregate to guidelines (akurtakov_, 17:31:31) * ACTION: akurtakov_ add to guidelines that ant packages that have pom files MUST install them (akurtakov_, 17:35:38) * ACTION: akurtakov_ f there is no pom consider using the one from maven central addition to guidelines (akurtakov_, 17:37:40) * ACTION: akurtakov_ merge parts from JPPMavenReadme and explain when usage of depmap is reasonable and when one have to patch the pom.xml file (akurtakov_, 17:43:42) * LINK: http://fedoraproject.org/wiki/Fedora_meeting_channel (cspike, 17:54:56) * Update Java SIG wiki (sochotni, 17:57:27) * open-floor (akurtakov_, 17:58:15) * LINK: http://fedoraproject.org/wiki/JakartaCommonsRename (cspike, 17:59:12) * LINK: http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life (cspike, 18:01:11) * ACTION: sochotni try to contact jmrodri and fnasser about orphaning their jakarta packages (sochotni, 18:05:32) Meeting ended at 18:25:51 UTC. Action Items * sochotni will put maven 3 spec for review * sochotni will create public git repo with custom resolver so others can see/review * akurtakov_ will file infra ticket asking for java pseudo user * akurtakov_ to add javadoc:aggregate to guidelines * akurtakov_ add to guidelines that ant packages that have pom files MUST install them * akurtakov_ f there is no pom consider using the one from maven central addition to guidelines * akurtakov_ merge parts from JPPMavenReadme and explain when usage of depmap is reasonable and when one have to patch the pom.xml file * sochotni try to contact jmrodri and fnasser about orphaning their jakarta packages Action Items, by person --- * akurtakov_ * akurtakov_ will file infra ticket asking for java pseudo user
[Test-Announce] Fedora 14 Final TC Validation Test Recap
Greetings testers, Fedora 14 Final TC validation test event has come to an end, this time we have more testers participating in the events and therefore more bugs were identified including blocker bugs, so many thanks for the ones who leaded/attended/payed attention on the test event. As before, test results are summarized below for your reference: === Installation = * F14Blocker(538277): 642358 CLOSED ERRATA - Up arrow tries to run gnome-screenshot 643742 CLOSED DUPLICATE of 643580 - blank screen on dvd install, working on livecd 642483 CLOSED ERRATA - Remove the 'Pre-release Software' Warning Screen 583906 CLOSED ERRATA - Backtrace in clearpart_gui when only uninitialized disks are found 642557 CLOSED ERRATA - after a split-media install, system fails to boot * F14-accepted(635218): 643580 ON_QA - Fedora 14 TC1 DVD Graphical Install Fails 642699 CLOSED ERRATA - Booting a system with multiple encrypted devices over serial console, prompts for passphrase multiple times * Warnings: 642913 NEW - RepoError: database disk image is malformed 642955 NEW - anaconda asks for existing encryption passphrase twice 585006 NEW - anaconda and livecd-creator are creating i386 and x86_64 ISOs which are larger than indicated by the ISO header 528232 ASSIGNED - Hang with EFI booting on iMac and Macbook Pro 6.2 642951 ASSIGNED - DVD upgrading requires cd install media 615572 CLOSED WORKSFORME - Network installation not possible without IPv4 DHCP available. = Desktop = * F14-accepted(635218): 643416 CLOSED ERRATA - F14 TC1.1 LXDE Spin: Unable to input any character to text box in User Manager screen. * Warnings: 643838 NEW - Crash in QRasterPaintEngine::fillRect on Cirrus video card (KVM) 643223 NEW - gnome-dictionary's default source, dict.org, is down 643316 NEW - fedora release is not shown 640793 NEW - [abrt] nautilus-2.32.0-1.fc14: g_type_check_instance_cast: Process /usr/bin/nautilus was killed by signal 11 (SIGSEGV) 643435 NEW - Automatically unlock function seems break. It always asks password when I'm logged in. 643388 CLOSED UPSTREAM - [abrt] lxpanel-0.5.6-1.fc14: IA__gtk_widget_show: Process /usr/bin/lxpanel was killed by signal 11 (SIGSEGV) 643835 CLOSED DUPLICATE of 643108 - system-config-firewall org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.firewall.auth: The detailed result pages are in: https://fedoraproject.org/wiki/Category:Fedora_14_Final_TC_Test_Results If you have interest, please help track and verify the bugs listed or marked as blockers. Also be noticed that Fedora 14 Final Release Candidate(RC) validation test event is coming soon[1], its announcement will be sent out once F14-Final-RC1 is available. Stay tuned for this! Thanks, Hurry [1] http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html -- Contacts Hurry FAS Name: Rhe Timezone: UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
