Re: jack2
On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 and firefox
I read somewhere that firefox 4 would be out in november. Fedora 14 will be released at the end of october. So will fedora 14 include firefox 4 ? Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trouble locally reproducing koji build error
Zach Carter z.car...@f5.com writes: Howeverthe question remains, why did it build just fine with the function header as-is on a rawhide machine and in my local mockbuild, but not when the build was run on the koji server? Some difference in the autotools, g++ compiler, boost? Any theories? Have you tried looking at config.log? Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, Jul 20, 2010 at 00:33, Roland McGrath rol...@redhat.com wrote: My opinion is that a branch called F-n/master is the nicest thing. Actually, all else being equal, I'd probably go for it being called fn/master, since gratuitous caps and punctuation in branch names is not a normal git convention. (But I only really care about the structure of the names, not the spelling.) same here. I also prefer lower case. (package names and dist tags are lower-case too). I would avoid the magic with HEAD, it might be to confusing. master might also be confusing, but I can't think of anything better at the moment. f13/update or f13/release came to mind, but they are not very good either. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Booting from SCSI CDROM
On 10/07/10 18:50, Emilio Fernandes wrote: Hi all again... I have a motherboard that has no entries IDEs only sata. When I try to install fedora 8 on this machine by the cdrom, the instalation process started normally but when will it start anaconda does not find the cdrom:/ks8.cfg. The cdrom is sata. I tried to pass multiple arguments to the kernel, such as hda=none, hda=noprobe, ide0=noprobe, ide=nodma, max_scsi_luns=1 among other attempts but all failed, I wonder if anyone knows some other parameters to the kernel I can help. The fedora 8 cd's with the vmlinuz and initrd.img of kernel 2.6.23. Fedora 8 reached its End of Life on 7th January 2009 and as such you're unlikely to find any support for it here. Why aren't you trying to install a more recent (supported) release? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100720 changes
Compose started at Tue Jul 20 08:15:21 UTC 2010 Broken deps for x86_64 -- BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) almanah-0.7.3-2.fc14.x86_64 requires libecal-1.2.so.7()(64bit) almanah-0.7.3-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) 1:anerley-0.2.14-2.fc14.i686 requires libebook-1.2.so.9 1:anerley-0.2.14-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) ardour-2.8.11-1.fc14.x86_64 requires liblo.so.0()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) csound-5.10.1-18.fc14.i686 requires liblo.so.0 csound-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-dssi-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-fltk-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-fluidsynth-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-gui-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-jack-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-java-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-osc-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-python-5.10.1-18.fc14.i686 requires liblo.so.0 csound-python-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-tk-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) csound-virtual-keyboard-5.10.1-18.fc14.x86_64 requires liblo.so.0()(64bit) dates-0.4.11-3.fc14.x86_64 requires libecal-1.2.so.7()(64bit) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) dssi-1.0.0-4.fc13.x86_64 requires liblo.so.0()(64bit) dssi-examples-1.0.0-4.fc13.x86_64 requires liblo.so.0()(64bit) dssi-vst-0.9.2-1.fc14.x86_64 requires liblo.so.0()(64bit) ekiga-3.2.7-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-0.4.so.0()(64bit) emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4) emerillon-devel-0.1.1-2.fc13.x86_64 requires pkgconfig(champlain-0.4) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-rss-0.1.9-7.20100525git.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) evolution-rss-0.1.9-7.20100525git.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) fluidsynth-dssi-1.0.0-2.fc12.x86_64 requires liblo.so.0()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) giggle-0.5-2.fc14.i686 requires libebook-1.2.so.9 giggle-0.5-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) glabels-2.2.8-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit)
Re: Fedora 14 and firefox
It'll come through as an update in the updates repo, I suspect. There might be a beta version included depending on its stability at the time of a F14 release I guess. Regards -- Chris Jones Freelance Photographic Imaging Professional and Graphic Designer ABN: 98 317 740 240 PHOTO RESOLUTIONS - Photo - Graphic - Web W: http://photoresolutions.freehostia.com E: chrisjo...@comcen.com.au or ubuntu...@comcen.com.au Fedora Design Suite Developer and Co-Maintainer E: foxmulder...@fedoraproject.org GnuPG v2.0.15 (GNU/Linux) keys.gnupg.net KeyID: 769A8262 Public Key Fingerprint: 94D0 BFAE 87A5 376E FCB2 CEBD C717 CD87 769A 8262 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On 07/19/2010 06:41 PM, Hans de Goede wrote: In a systemd world we can fix this in a much nicer way: libvirtd.service would just have a Wants: iscsid.service in it. That way when libvirtd is started iscsid is started too. And if people use iscsid in other areas too they can just add a single symlink (/etc/systemd/system/multi-user.target.wants/iscsid.service → /lib/systemd/system/iscsid.service) and it is started on boot, regadless whether libvirtd is enabled or not. I'm afraid that is not how the relation between libvirt and iscsi-initiator-utils works. I don't know exactly what libvirt needs iscsi-initiator-utils for, but I think it does not require iscsid to be running. I guess we need to involve one of the libvirt guys into this discussion to tell us what exactly libvirt uses iscsi-initiator-utils for. Libvirt allows connecting to an iscsi target, using that storage as a local 'libvirt storage pool'. AIUI all libvirt uses is iscsiadm. Here's a list of commands it can run behind the scenes: ISCSIADM --mode session ISCSIADM --mode iface ISCSIADM --mode iface --interface $IFNAME --op new ISCSIADM --mode iface --interface $IFNAME --op update --name iface.initiatorname --value $IQN ISCSIADM --mode discovery --type sendtargets --portal $PORTAL ISCSIADM --mode node --portal portal --targetname $TARGETPATH --interface $IFACE $ACTION ISCSIADM --mode node --portal portal --targetname $TARGETPATH $ACTION ISCSIADM --mode session -r $SESSION -R ISCSIADM --mode discovery --type sendtargets --portal $PORTAL You can check the relevant code here: http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/storage/storage_backend_iscsi.c;hb=HEAD - Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Tue, Jul 20, 2010 at 12:41:11AM +0200, Hans de Goede wrote: I think the problem was that the iscsid service was on by default, so when things like libvirt install it iscsid would always start but many times not be needed. In a systemd world we can fix this in a much nicer way: libvirtd.service would just have a Wants: iscsid.service in it. That way when libvirtd is started iscsid is started too. And if people use iscsid in other areas too they can just add a single symlink (/etc/systemd/system/multi-user.target.wants/iscsid.service → /lib/systemd/system/iscsid.service) and it is started on boot, regadless whether libvirtd is enabled or not. I'm afraid that is not how the relation between libvirt and iscsi-initiator-utils works. I don't know exactly what libvirt needs iscsi-initiator-utils for, but I think it does not require iscsid to be running. I guess we need to involve one of the libvirt guys into this discussion to tell us what exactly libvirt uses iscsi-initiator-utils for. libvirt doesn't directly care about iscsid at all. It just issues commands using iscsiadm to login/out of targets query LUNs, etc. If iscsiadm requires that iscsid be running in order to work, then I guess it should activate it when required ? Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Intending to retire xorg-x11-drv-radeonhd package
Hi, I would like to retire the xorg-x11-drv-radeonhd package before it gets into F-14. Kernel based modesetting (KMS) and xorg-x11-drv-ati work really nicely and radeonhd's upstream appears stalled and has no support for KMS, so I do not see any advantage to Fedora in carrying a radeonhd package any more. If no one wants to pick xorg-x11-drv-radeonhd, I will start following https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life in a few days. Uli -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gathering useful statistics for Package Maintainers
Hello, we would like to help Package Maintainers to increase public participation in their activities. We believe that an important step in achieving that is in rewarding the most active participants with fame in different top tens, ladders and charts. Therefore we would like to extend the current Fedora Community website [1] with different statistics regarding user participation in different areas relevant to your team. We have called this project Fedora Hall of Fame [2]. This information can then be used in different newsletters (FWN, etc) to praise the best people and motivate the others. The information we hope to receive from you is: 1. What are the most important tools you would like to have tracked? For example it can be your wiki, mailing lists, Bugzilla, Koji, Bodhi, Transifex, packages' source code, and so on. 2. What are the most important characteristics you would like to see gathered? For example: # of wiki edits, # of new bug reports, # of package updates released, etc. Some of our ideas are at [3]. In short, we're looking for hints which statistical data would help this team most in evaluating your best contributors. We can't promise you we will gather exactly the information that you would like to see. But if you tell us what you need, we can concentrate on the relevant tasks for you rather than on the irrelevant. Feel free to ask for any details.[4] Thanks, Kamil Páral [1] https://admin.fedoraproject.org/community [2] https://fedoraproject.org/wiki/User:Kparal/Idea:Fedora_Hall_of_Fame [3] https://fedoraproject.org/wiki/User:Kparal/Idea:Fedora_Hall_of_Fame#Hall_of_Fame_proposal [4] This email was sent to many teams' mailing lists, so it might be a little generic. But the meaning should be clear, I hope. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Fri, 2010-07-16 at 17:07 -0700, Jesse Keating wrote: I've been struggling with a particular wrinkle in dist-git, how fedpkg is supposed to reliably discover what Fedora release a packager is working on. In other words: How does fedpkg map the currently checked out git HEAD to a Fedora release? (Unless fedpkg is specifically given a Fedora release to build for on the command line.) In the CVS world, we used a branch file. This is OK, but I think it would be cleaner if we didn't have to rely upon that. It's the last file that wouldn't be exact across all the Fedora releases if a package is kept in sync. So what I'd like to do is rely upon discovering the top level upstream branch, say F-13. 100% Ack. This gets difficult if we allow maintainers to create and operate on their own upstream branches (which we should), as I have not found a reliable way to work from a local branch to which remote branch it tracks to which top level remote branch it was created from. Is this problem solvable at all? Every merge commit has (at least) two parents. If you have once merged the F-12 branch into the F-13 branch, how can fedpkg decide which of the parents was the real one to track back to? One suggestion has been to make use of directory based branching, so that any maintainer created branch is in a subdir of a top level branch. This phrasing might be a little confusing. We are NOT talking about having different branches' files in different subdirectories on the filesystem here, like we were doing with the CVS checkouts. We are talking about branches named like directories (e.g. 'F-13/foo'). EG we'd a user could create an F-13/kernel-2.7 branch, and call it whatever they want locally. fedpkg would be able to work from the local branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the path from origin/ to discover F-13. Then fedpkg can assume F-13 for the branch and do all the dist conversions and koji target discovery from that. This doesn't put too much restraint on what maintainers call their branches, particularly locally. The wrinkle with the above though is the base top level branch. When we do this with directories, it's not possible to have a simple origin/F-13 branch that a user could interact with (git checkout F-13 would automatically detect that there is an origin/F-13 remote branch and setup a local F-13 branch to track it and still allow for an F-13/foobar branch. So we have to make the first base upstream branch F-13/something. One suggested something has been to call it HEAD, because git seems to have another short cut that would allow you to do git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it will automatically use that. HEAD seems to be a special name in this context. However it is pointed out that using HEAD here could be confusing to people who are more familiar with git and naming conventions. Another suggestion is to call it F-13/master since master is a more appropriate and expected name. However that means you can't use the short cut and have to do a full git checkout -b F-13 origin/F-13/master. Since you have to use the full path here, we aren't bound by the name master and we could name it anything we want, something that might make sense to Fedora or dist-git. I would call it something short and sweet and to the point. Using F-13/HEAD appears hackish, and does things one might not expect, so I would be careful with that. Whether it is called F-13/master, F-13/koji, or F-13/official, however, I don't care, as long as it is consistent over all packages. Now, these are fairly low details which can be hidden behind fedpkg (there is a proposed patch to give fedpkg a 'switch-branch' command that will switch you from one to the other, and we can make calls to F-13 attempt origin/F-13/master or whatever), but I feel that this is a detail I shouldn't just decide on my own. So, I welcome the discussion. My first idea would be for fedpkg to do something similar to the following when trying to find out the target to build for: 0. If --target F-13 is given, use that as target. If not, continue. 1. Determine the current git branch ($origbranch=$curbranch). 2. Check 'git config branch.$curbranch.fedora-target'. If set, use that as target. If not, continue. 3. Check whether $curbranch starts with F-13/. If so, use F-13 as the target. If not, continue. 4. Check what branch $curbranch is tracking. If it tracks one, set curbranch to that branch and go to step 2. Otherwise, bail out and ask for --target or 'git config branch.$origbranch.fedora-target' to be set. This would allow * Easy building of the currently checked out branch for all targets with something like fedpkg mockbuild --target F-13. * Easy building of some special local branch for F-13 by default even if it is not called F-13/foo. * Building of branches for the
Re: Question regarding dist-git aesthetics with branches
On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote: Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... I'm not around enough right now to be able to test anything :-(. I also don't really understand the choices you're presenting since they're based on git conventions that I don't know. master is just a convention in git? HEAD is treated specially but doesn't exist normally in a repository? I think the only way to do this is to implement one thing and then be willing to either change that (or let someone else contribute work to change it) once people use it and tell you ZOMG WHY [...]. That said, I don't think I'd use either HEAD or master as the branch name since they both have some sort of association with how git itself works unless the name actually matches 100% with the concept that you're trying to express here. When you make a UI choice where a feature has the same name as another feature but they are onlt 80% compatible you cause problems for the people that try to do something in that 20% space. When they switch from one feature to the other they run into incompatibilities, googling will turn up the wrong feature, they will ask on IRC and get answers that concern the wrong feature, etc. It's better to have a distinct name for something that is different. -Toshio pgp9RXWzt1rBW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I am not available
On 07/19/2010 08:19 PM, Chris Jones wrote: On Tue, Jul 20, 2010 at 10:59 AM, Rahul Sundarammethe...@gmail.com wrote: It is all listed at https://fedoraproject.org/wiki/TillMaas Rahul Thanks mate. Chris I found the following more immediately useful: https://admin.fedoraproject.org/pkgdb/users/packages/till -J -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Mon, 19.07.10 13:52, Daniel J Walsh (dwa...@redhat.com) wrote:
I am noticing the following in F14
type=1400 audit(1279559591.480:31): avc: denied { read } for pid=526
comm=udevd name=/ dev=autofs ino=9519
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=1400 audit(1279559595.968:35): avc: denied { read } for pid=880
comm=blkid name=/ dev=autofs ino=9522
scontext=system_u:system_r:fsadm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=AVC msg=audit(1279559629.289:59): avc: denied { read } for
pid=2013 comm=vgchange name=/ dev=autofs ino=9522
scontext=system_u:system_r:lvm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:autofs_t:s0 tclass=dir
type=PATH msg=audit(1279559629.289:59): item=0 name=/dev/mqueue
inode=9522 dev=00:21 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:autofs_t:s0
These AVC messages indicate lots of daemons that are trying to list the
contents of a directory labeled autofs_t. udevd, blkid, vgchange.
Do you have any idea what is going on here? Am I going to have to allow
all daemons to list the contents of autofs_t?
Those are the automount directories we install for /dev/mqueue,
/dev/hugepages, /proc/sys/fs/binfmt_misc, and the other API mounts. On
first access those automount points will be replaced by the actual file
systems. That allows us to make the mounts available right-away without
actually having to load the modules implementing them.
I am not entirely sure though why those processes actually access those
dirs in this case. Maybe they are iterating through the files in /dev?
Smells a bit broken to me.
Will I have to allow all daemons to list the contents of hugetlbfs_t?
Well, I see no reason why the LVM tools, or udev might need to access
the mqueue or hugetlbfs file system. They should not need access to it.
Or could these be leaks?
No, unlikely.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote: On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the No problem. Although I was the one collecting the pieces, it was rather a collective work. Thanks to everyone who is involved. We need to do some testing now, and clean up the glitches before F-14. question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. I thought about doing that once. Jack1's and jack2's source codes are distributed on the same website [1], We know that JACK stands for Jack-Audio-Connection-Kit. So there shouldn't be any confusion. Sadly, there is no unique agreement on the package name across distribution. As far as I know, we were the only distro distributing jack1 under the full name jack-audio-connection-kit. There is also a very different project called jack [2], although we don't have it on Fedora. This adds more to the subtlety as Mandriva distributes this jack as just jack. What do other maintainers think? Orcan [1] http://jackaudio.org/download [2] http://www.home.unix-ag.org/arne/jack/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Tue, 20.07.10 16:04, Lennart Poettering (mzerq...@0pointer.de) wrote: I am not entirely sure though why those processes actually access those dirs in this case. Maybe they are iterating through the files in /dev? Smells a bit broken to me. OK, the udevd is a result from /lib/udev/devices/ which is copied to /dev early on boot by udevd. Kay says that this dir reeally should not be put in /lib/udev/devices/. Still puzzled why LVM wants with /dev/mqueue though. Anybody from LVM around who can say something about this? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, Jul 20, 2010 at 5:04 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote: question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. I thought about doing that once. Jack1's and jack2's source codes are distributed on the same website [1], We know that JACK stands for Jack-Audio-Connection-Kit. So there shouldn't be any confusion. There is rule in Fedora http://fedoraproject.org/wiki/PackageNamingGuidelines#General_Naming In our case it's a bit odd. However, I vote to call package in the same way as main tarball. -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Lost all empathy accounts after update this morning (F13)
When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Here's yum.log from this morning. Can anybody offer any guesses? Jul 20 09:56:21 Updated: 2:gimp-libs-2.6.10-1.fc13.x86_64 Jul 20 09:56:25 Updated: libvirt-client-0.8.2-2.fc13.x86_64 Jul 20 09:56:28 Updated: 1:qt-4.6.3-8.fc13.x86_64 Jul 20 09:56:30 Updated: 1:qt-sqlite-4.6.3-8.fc13.x86_64 Jul 20 09:56:31 Updated: libvirt-python-0.8.2-2.fc13.x86_64 Jul 20 09:56:33 Updated: iscsi-initiator-utils-6.2.0.872-7.fc13.x86_64 Jul 20 09:56:34 Updated: ffmpeg-libs-0.6-2.fc13.x86_64 Jul 20 09:56:36 Updated: openldap-2.4.21-9.fc13.x86_64 Jul 20 09:56:37 Updated: v8-2.3.0-1.20100716svn5088.fc13.x86_64 Jul 20 09:56:38 Updated: m17n-contrib-1.1.10-5.fc13.noarch Jul 20 09:56:41 Updated: xsane-common-0.997-10.fc13.x86_64 Jul 20 09:56:42 Updated: mplayer-common-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:56:47 Updated: chromium-libs-6.0.467.0-2.fc13.x86_64 Jul 20 09:56:48 Updated: 1:perl-Pod-Escapes-1.04-114.fc13.x86_64 Jul 20 09:56:49 Updated: 4:perl-libs-5.10.1-114.fc13.x86_64 Jul 20 09:56:50 Updated: 1:perl-Module-Pluggable-3.90-114.fc13.x86_64 Jul 20 09:56:52 Updated: 1:perl-Pod-Simple-3.07-114.fc13.x86_64 Jul 20 09:57:03 Updated: 4:perl-5.10.1-114.fc13.x86_64 Jul 20 09:57:03 Updated: 1:perl-ExtUtils-ParseXS-2.20-114.fc13.x86_64 Jul 20 09:57:05 Updated: 4:perl-devel-5.10.1-114.fc13.x86_64 Jul 20 09:57:07 Updated: perl-Test-Harness-3.17-114.fc13.x86_64 Jul 20 09:57:09 Updated: perl-ExtUtils-MakeMaker-6.55-114.fc13.x86_64 Jul 20 09:57:10 Updated: 1:perl-ExtUtils-CBuilder-0.27-114.fc13.x86_64 Jul 20 09:57:11 Updated: 1:perl-Package-Constants-0.02-114.fc13.x86_64 Jul 20 09:57:11 Updated: 1:perl-IO-Zlib-1.09-114.fc13.x86_64 Jul 20 09:57:12 Updated: perl-Archive-Tar-1.62-114.fc13.x86_64 Jul 20 09:57:32 Updated: selinux-policy-3.7.19-37.fc13.noarch Jul 20 09:57:33 Installed: compat-db-headers-4.7.25-15.fc13.noarch Jul 20 09:57:36 Updated: papyon-0.4.9-1.fc13.noarch Jul 20 09:57:47 Installed: oxygen-icon-theme-4.4.5-1.fc13.noarch Jul 20 09:57:48 Updated: xdg-utils-1.0.2-20.20100709.fc13.noarch Jul 20 09:58:02 Updated: 2:gimp-2.6.10-1.fc13.x86_64 Jul 20 09:58:03 Updated: flex-static-2.5.35-11.fc13.x86_64 Jul 20 09:58:04 Updated: smc-fonts-common-4.4-1.fc13.noarch Jul 20 09:58:05 Updated: koji-1.4.0-2.fc13.noarch Jul 20 09:58:06 Updated: flex-2.5.35-11.fc13.x86_64 Jul 20 09:58:07 Updated: 2:gimp-help-browser-2.6.10-1.fc13.x86_64 Jul 20 09:58:08 Updated: xsane-gimp-0.997-10.fc13.x86_64 Jul 20 09:58:10 Updated: compat-db47-4.7.25-15.fc13.x86_64 Jul 20 09:58:10 Updated: 4:perl-suidperl-5.10.1-114.fc13.x86_64 Jul 20 09:58:14 Updated: chromium-6.0.467.0-2.fc13.x86_64 Jul 20 09:58:16 Updated: mencoder-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:58:17 Updated: mplayer-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:58:19 Updated: xsane-0.997-10.fc13.x86_64 Jul 20 09:58:20 Updated: openldap-clients-2.4.21-9.fc13.x86_64 Jul 20 09:58:21 Updated: ffmpeg-0.6-2.fc13.x86_64 Jul 20 09:58:24 Updated: libvirt-0.8.2-2.fc13.x86_64 Jul 20 09:58:30 Updated: 1:qt-x11-4.6.3-8.fc13.x86_64 Jul 20 09:58:32 Updated: mysql-libs-5.1.48-2.fc13.x86_64 Jul 20 09:58:33 Updated: clutter-1.2.10-1.fc13.x86_64 Jul 20 09:58:35 Updated: telepathy-gabble-0.9.11-2.fc13.x86_64 Jul 20 09:58:36 Updated: upower-0.9.5-1.fc13.x86_64 Jul 20 09:58:38 Updated: libgnomekbd-2.30.2-1.fc13.x86_64 Jul 20 09:58:40 Updated: ppp-2.4.5-9.fc13.x86_64 Jul 20 09:58:41 Updated: cairomm-1.8.4-2.fc13.x86_64 Jul 20 09:58:42 Updated: ibus-m17n-1.3.0-2.fc13.x86_64 Jul 20 09:58:43 Updated: 3:traceroute-2.0.15-1.fc13.x86_64 Jul 20 09:58:44 Updated: xorg-x11-xinit-1.0.9-17.fc13.x86_64 Jul 20 09:58:45 Updated: finger-0.17-41.fc13.x86_64 Jul 20 09:58:46 Updated: farsight2-0.0.20-2.fc13.x86_64 Jul 20 09:58:47 Updated: fedora-packager-0.4.2.3-1.fc13.noarch Jul 20 09:58:48 Updated: fedora-easy-karma-0-0.7.20100709git561718c8.fc13.noarch Jul 20 09:58:51 Updated: smc-meera-fonts-4.4-1.fc13.noarch Jul 20 09:58:52 Updated: fedora-kde-icon-theme-0.0.2-3.fc13.noarch Jul 20 09:58:54 Updated: telepathy-butterfly-0.5.12-1.fc13.noarch Jul 20 09:59:58 Updated: selinux-policy-targeted-3.7.19-37.fc13.noarch Jul 20 09:59:59 Updated: 1:perl-Module-Build-0.3500-114.fc13.x86_64 Jul 20 10:00:00 Updated: perl-HTML-Parser-3.66-1.fc13.x86_64 Jul 20 10:00:02 Updated: redhat-lsb-4.0-5.fc13.x86_64 Jul 20 10:00:02 Updated: m17n-contrib-maithili-1.1.10-5.fc13.noarch
Re: Lost all empathy accounts after update this morning (F13)
Le mardi 20 juillet 2010 à 16:16 +0100, Matthew Booth a écrit : When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Here's yum.log from this morning. Can anybody offer any guesses? Jul 20 09:56:21 Updated: 2:gimp-libs-2.6.10-1.fc13.x86_64 Jul 20 09:56:25 Updated: libvirt-client-0.8.2-2.fc13.x86_64 Jul 20 09:56:28 Updated: 1:qt-4.6.3-8.fc13.x86_64 Jul 20 09:56:30 Updated: 1:qt-sqlite-4.6.3-8.fc13.x86_64 Jul 20 09:56:31 Updated: libvirt-python-0.8.2-2.fc13.x86_64 Jul 20 09:56:33 Updated: iscsi-initiator-utils-6.2.0.872-7.fc13.x86_64 Jul 20 09:56:34 Updated: ffmpeg-libs-0.6-2.fc13.x86_64 Jul 20 09:56:36 Updated: openldap-2.4.21-9.fc13.x86_64 Jul 20 09:56:37 Updated: v8-2.3.0-1.20100716svn5088.fc13.x86_64 Jul 20 09:56:38 Updated: m17n-contrib-1.1.10-5.fc13.noarch Jul 20 09:56:41 Updated: xsane-common-0.997-10.fc13.x86_64 Jul 20 09:56:42 Updated: mplayer-common-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:56:47 Updated: chromium-libs-6.0.467.0-2.fc13.x86_64 Jul 20 09:56:48 Updated: 1:perl-Pod-Escapes-1.04-114.fc13.x86_64 Jul 20 09:56:49 Updated: 4:perl-libs-5.10.1-114.fc13.x86_64 Jul 20 09:56:50 Updated: 1:perl-Module-Pluggable-3.90-114.fc13.x86_64 Jul 20 09:56:52 Updated: 1:perl-Pod-Simple-3.07-114.fc13.x86_64 Jul 20 09:57:03 Updated: 4:perl-5.10.1-114.fc13.x86_64 Jul 20 09:57:03 Updated: 1:perl-ExtUtils-ParseXS-2.20-114.fc13.x86_64 Jul 20 09:57:05 Updated: 4:perl-devel-5.10.1-114.fc13.x86_64 Jul 20 09:57:07 Updated: perl-Test-Harness-3.17-114.fc13.x86_64 Jul 20 09:57:09 Updated: perl-ExtUtils-MakeMaker-6.55-114.fc13.x86_64 Jul 20 09:57:10 Updated: 1:perl-ExtUtils-CBuilder-0.27-114.fc13.x86_64 Jul 20 09:57:11 Updated: 1:perl-Package-Constants-0.02-114.fc13.x86_64 Jul 20 09:57:11 Updated: 1:perl-IO-Zlib-1.09-114.fc13.x86_64 Jul 20 09:57:12 Updated: perl-Archive-Tar-1.62-114.fc13.x86_64 Jul 20 09:57:32 Updated: selinux-policy-3.7.19-37.fc13.noarch Jul 20 09:57:33 Installed: compat-db-headers-4.7.25-15.fc13.noarch Jul 20 09:57:36 Updated: papyon-0.4.9-1.fc13.noarch Jul 20 09:57:47 Installed: oxygen-icon-theme-4.4.5-1.fc13.noarch Jul 20 09:57:48 Updated: xdg-utils-1.0.2-20.20100709.fc13.noarch Jul 20 09:58:02 Updated: 2:gimp-2.6.10-1.fc13.x86_64 Jul 20 09:58:03 Updated: flex-static-2.5.35-11.fc13.x86_64 Jul 20 09:58:04 Updated: smc-fonts-common-4.4-1.fc13.noarch Jul 20 09:58:05 Updated: koji-1.4.0-2.fc13.noarch Jul 20 09:58:06 Updated: flex-2.5.35-11.fc13.x86_64 Jul 20 09:58:07 Updated: 2:gimp-help-browser-2.6.10-1.fc13.x86_64 Jul 20 09:58:08 Updated: xsane-gimp-0.997-10.fc13.x86_64 Jul 20 09:58:10 Updated: compat-db47-4.7.25-15.fc13.x86_64 Jul 20 09:58:10 Updated: 4:perl-suidperl-5.10.1-114.fc13.x86_64 Jul 20 09:58:14 Updated: chromium-6.0.467.0-2.fc13.x86_64 Jul 20 09:58:16 Updated: mencoder-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:58:17 Updated: mplayer-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:58:19 Updated: xsane-0.997-10.fc13.x86_64 Jul 20 09:58:20 Updated: openldap-clients-2.4.21-9.fc13.x86_64 Jul 20 09:58:21 Updated: ffmpeg-0.6-2.fc13.x86_64 Jul 20 09:58:24 Updated: libvirt-0.8.2-2.fc13.x86_64 Jul 20 09:58:30 Updated: 1:qt-x11-4.6.3-8.fc13.x86_64 Jul 20 09:58:32 Updated: mysql-libs-5.1.48-2.fc13.x86_64 Jul 20 09:58:33 Updated: clutter-1.2.10-1.fc13.x86_64 Jul 20 09:58:35 Updated: telepathy-gabble-0.9.11-2.fc13.x86_64 Jul 20 09:58:36 Updated: upower-0.9.5-1.fc13.x86_64 Jul 20 09:58:38 Updated: libgnomekbd-2.30.2-1.fc13.x86_64 Jul 20 09:58:40 Updated: ppp-2.4.5-9.fc13.x86_64 Jul 20 09:58:41 Updated: cairomm-1.8.4-2.fc13.x86_64 Jul 20 09:58:42 Updated: ibus-m17n-1.3.0-2.fc13.x86_64 Jul 20 09:58:43 Updated: 3:traceroute-2.0.15-1.fc13.x86_64 Jul 20 09:58:44 Updated: xorg-x11-xinit-1.0.9-17.fc13.x86_64 Jul 20 09:58:45 Updated: finger-0.17-41.fc13.x86_64 Jul 20 09:58:46 Updated: farsight2-0.0.20-2.fc13.x86_64 Jul 20 09:58:47 Updated: fedora-packager-0.4.2.3-1.fc13.noarch Jul 20 09:58:48 Updated: fedora-easy-karma-0-0.7.20100709git561718c8.fc13.noarch Jul 20 09:58:51 Updated: smc-meera-fonts-4.4-1.fc13.noarch Jul 20 09:58:52 Updated: fedora-kde-icon-theme-0.0.2-3.fc13.noarch Jul 20 09:58:54 Updated: telepathy-butterfly-0.5.12-1.fc13.noarch Jul 20 09:59:58 Updated: selinux-policy-targeted-3.7.19-37.fc13.noarch Jul 20 09:59:59 Updated: 1:perl-Module-Build-0.3500-114.fc13.x86_64 Jul 20 10:00:00 Updated:
KDE-SIG meeting report (29/2010)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 29/2010 Time: 2010-07-20 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-20 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2010-07-20/kde-sig.2010-07-20-14.04.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2010-07-20/kde- sig.2010-07-20-14.04.log.html -- = Participants = * Jaroslav Reznik * Kevin Kofler * Rex Dieter * Steven Parrish * Than Ngo * Radek Novacek * kalev * nucleo * dgilmore and KDEPIM guests ;-) -- = Agenda = * topics to discuss: o F-14: to kdepim-4.5 or not to kdepim-4.5, that is the question o include both plasma-nm and nm-applet on kde spin? o cmake macros: drop -DBUILD_SHARED_LIBS:BOOL=ON (by default)? * recent bugs: o fedora-kde-icon-theme : Inherits=oxygen not working as expected [1] = Summary = F-14: to kdepim-4.5 or not to kdepim-4.5, that is the question * AGREED: kde-sig (majority) agrees to not include kdepim-4.5 in F-14 o but we need strong statement from upstream + release schedule + stable datastorage (so no data loss while updating) + data migration issues solved include both plasma-nm and nm-applet on kde spin? * AGREED: revert recent change to spin-kickstarts, do not include nm- applet on kde spin o it's a non sense to ship both (not easy to switch, space etc.) * more testing needed for plasma-nm o HELP: kde-sig'ers test test test plasma-nm * what's the minimal functionality? cmake macros: drop -DBUILD_SHARED_LIBS:BOOL=ON (by default)? * AGREED: (majority) NACK'd cmake proposal to drop - DBUILD_SHARED_LIBS:BOOL=ON fedora-kde-icon-theme : Inherits=oxygen not working as expected * several reports recently about mimetypes with '?' icons o problem with inherit code loading o suspect: kdebase-runtime-4.1.1-iconthemes-inherit.patch -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-27 = Links = [1] https://bugzilla.redhat.com/615621 -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On 20/07/10 16:19, Jonathan MERCIER wrote: Le mardi 20 juillet 2010 à 16:16 +0100, Matthew Booth a écrit : When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Here's yum.log from this morning. Can anybody offer any guesses? ... you can check this file: ~/.mission-control/accounts/accounts.cfg That file contains all my account info. Also, I've just discovered empathy-debugger, which is full of messages like this: publish_to_all_am_prepared_cb: Failed to prepare account manager: Failed to execute program /usr/libexec/mission-control-5: Success So the question is, what might have killed mission control? Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I am not available
On 07/18/2010 11:05 PM, Till Maas wrote: Hi, I cannot maintain my packages or handle anything else until further notice, because I had an accident. Regards Till I'm sorry to hear and get well soon. I hope it's nothing serious. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
Le mardi 20 juillet 2010 à 16:28 +0100, Matthew Booth a écrit : On 20/07/10 16:19, Jonathan MERCIER wrote: Le mardi 20 juillet 2010 à 16:16 +0100, Matthew Booth a écrit : When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Here's yum.log from this morning. Can anybody offer any guesses? ... you can check this file: ~/.mission-control/accounts/accounts.cfg That file contains all my account info. Also, I've just discovered empathy-debugger, which is full of messages like this: publish_to_all_am_prepared_cb: Failed to prepare account manager: Failed to execute program /usr/libexec/mission-control-5: Success So the question is, what might have killed mission control? Matt I think you can open a bug. you cancheck if file /usr/libexec/mission-control-5 exist but not more. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On Tue, Jul 20, 2010 at 11:16 AM, Matthew Booth mbo...@redhat.com wrote: When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Yeah, neither tp-gabble or tp-butterfly should be causing this. tp-gabble's update only changed where tp-gabble looks for ssl certificated on Fedora, and tp-butterfly was only a bugfix release. I saw a bug report similar to this recently, but haven't been able to to reproduce this. Later, /B -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On 20/07/10 17:22, Brian Pepple wrote: On Tue, Jul 20, 2010 at 11:16 AM, Matthew Boothmbo...@redhat.com wrote: When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Yeah, neither tp-gabble or tp-butterfly should be causing this. tp-gabble's update only changed where tp-gabble looks for ssl certificated on Fedora, and tp-butterfly was only a bugfix release. I saw a bug report similar to this recently, but haven't been able to to reproduce this. https://bugzilla.redhat.com/show_bug.cgi?id=616506 It seems empathy and everything related to it has lost the ability to execute programs. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, 2010-07-20 at 10:04 -0400, Orcan Ogetbil wrote: On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote: On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the No problem. Although I was the one collecting the pieces, it was rather a collective work. Thanks to everyone who is involved. We need to do some testing now, and clean up the glitches before F-14. question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. I thought about doing that once. Jack1's and jack2's source codes are distributed on the same website [1], We know that JACK stands for Jack-Audio-Connection-Kit. So there shouldn't be any confusion. Sadly, there is no unique agreement on the package name across distribution. As far as I know, we were the only distro distributing jack1 under the full name jack-audio-connection-kit. There is also a very different project called jack [2], although we don't have it on Fedora. This adds more to the subtlety as Mandriva distributes this jack as just jack. What do other maintainers think? jack-audio-connection-kit is the official name of the project and it has been the suggested name for packages - I could try to dig through my very old email and find an email from Paul on the subject. I have used that name since 2001 or so (version 0.37) - I may have been one of the first if not the first to package Jack as part of Planet CCRMA. The jack1 tarball is actually named jack-audio-connection-kit, not jack. As mentioned above jack2 is a different code base that implements the same official jack API and was developed independently. Its developer chose to name the tarball jack (I don't know why, we could ask). Who knows what the future could bring. I certainly don't know :-) When/if jack2 becomes the official jack maybe the tarball will change to jack-audio-connection-kit. Of jack1 could evolve, supplant the current jack2 as the next version, and the tarball would still be jack-audio-connection-kit. I would keep the current name. -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
Le mardi 20 juillet 2010 ? 16:16 +0100, Matthew Booth a ?crit : When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Here's yum.log from this morning. Can anybody offer any guesses? Jul 20 09:56:21 Updated: 2:gimp-libs-2.6.10-1.fc13.x86_64 Jul 20 09:56:25 Updated: libvirt-client-0.8.2-2.fc13.x86_64 Jul 20 09:56:28 Updated: 1:qt-4.6.3-8.fc13.x86_64 Jul 20 09:56:30 Updated: 1:qt-sqlite-4.6.3-8.fc13.x86_64 Jul 20 09:56:31 Updated: libvirt-python-0.8.2-2.fc13.x86_64 Jul 20 09:56:33 Updated: iscsi-initiator-utils-6.2.0.872-7.fc13.x86_64 Jul 20 09:56:34 Updated: ffmpeg-libs-0.6-2.fc13.x86_64 Jul 20 09:56:36 Updated: openldap-2.4.21-9.fc13.x86_64 Jul 20 09:56:37 Updated: v8-2.3.0-1.20100716svn5088.fc13.x86_64 Jul 20 09:56:38 Updated: m17n-contrib-1.1.10-5.fc13.noarch Jul 20 09:56:41 Updated: xsane-common-0.997-10.fc13.x86_64 Jul 20 09:56:42 Updated: mplayer-common-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:56:47 Updated: chromium-libs-6.0.467.0-2.fc13.x86_64 Jul 20 09:56:48 Updated: 1:perl-Pod-Escapes-1.04-114.fc13.x86_64 Jul 20 09:56:49 Updated: 4:perl-libs-5.10.1-114.fc13.x86_64 Jul 20 09:56:50 Updated: 1:perl-Module-Pluggable-3.90-114.fc13.x86_64 Jul 20 09:56:52 Updated: 1:perl-Pod-Simple-3.07-114.fc13.x86_64 Jul 20 09:57:03 Updated: 4:perl-5.10.1-114.fc13.x86_64 Jul 20 09:57:03 Updated: 1:perl-ExtUtils-ParseXS-2.20-114.fc13.x86_64 Jul 20 09:57:05 Updated: 4:perl-devel-5.10.1-114.fc13.x86_64 Jul 20 09:57:07 Updated: perl-Test-Harness-3.17-114.fc13.x86_64 Jul 20 09:57:09 Updated: perl-ExtUtils-MakeMaker-6.55-114.fc13.x86_64 Jul 20 09:57:10 Updated: 1:perl-ExtUtils-CBuilder-0.27-114.fc13.x86_64 Jul 20 09:57:11 Updated: 1:perl-Package-Constants-0.02-114.fc13.x86_64 Jul 20 09:57:11 Updated: 1:perl-IO-Zlib-1.09-114.fc13.x86_64 Jul 20 09:57:12 Updated: perl-Archive-Tar-1.62-114.fc13.x86_64 Jul 20 09:57:32 Updated: selinux-policy-3.7.19-37.fc13.noarch Jul 20 09:57:33 Installed: compat-db-headers-4.7.25-15.fc13.noarch Jul 20 09:57:36 Updated: papyon-0.4.9-1.fc13.noarch Jul 20 09:57:47 Installed: oxygen-icon-theme-4.4.5-1.fc13.noarch Jul 20 09:57:48 Updated: xdg-utils-1.0.2-20.20100709.fc13.noarch Jul 20 09:58:02 Updated: 2:gimp-2.6.10-1.fc13.x86_64 Jul 20 09:58:03 Updated: flex-static-2.5.35-11.fc13.x86_64 Jul 20 09:58:04 Updated: smc-fonts-common-4.4-1.fc13.noarch Jul 20 09:58:05 Updated: koji-1.4.0-2.fc13.noarch Jul 20 09:58:06 Updated: flex-2.5.35-11.fc13.x86_64 Jul 20 09:58:07 Updated: 2:gimp-help-browser-2.6.10-1.fc13.x86_64 Jul 20 09:58:08 Updated: xsane-gimp-0.997-10.fc13.x86_64 Jul 20 09:58:10 Updated: compat-db47-4.7.25-15.fc13.x86_64 Jul 20 09:58:10 Updated: 4:perl-suidperl-5.10.1-114.fc13.x86_64 Jul 20 09:58:14 Updated: chromium-6.0.467.0-2.fc13.x86_64 Jul 20 09:58:16 Updated: mencoder-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:58:17 Updated: mplayer-1.0-0.117.20100703svn.fc13.x86_64 Jul 20 09:58:19 Updated: xsane-0.997-10.fc13.x86_64 Jul 20 09:58:20 Updated: openldap-clients-2.4.21-9.fc13.x86_64 Jul 20 09:58:21 Updated: ffmpeg-0.6-2.fc13.x86_64 Jul 20 09:58:24 Updated: libvirt-0.8.2-2.fc13.x86_64 Jul 20 09:58:30 Updated: 1:qt-x11-4.6.3-8.fc13.x86_64 Jul 20 09:58:32 Updated: mysql-libs-5.1.48-2.fc13.x86_64 Jul 20 09:58:33 Updated: clutter-1.2.10-1.fc13.x86_64 Jul 20 09:58:35 Updated: telepathy-gabble-0.9.11-2.fc13.x86_64 Jul 20 09:58:36 Updated: upower-0.9.5-1.fc13.x86_64 Jul 20 09:58:38 Updated: libgnomekbd-2.30.2-1.fc13.x86_64 Jul 20 09:58:40 Updated: ppp-2.4.5-9.fc13.x86_64 Jul 20 09:58:41 Updated: cairomm-1.8.4-2.fc13.x86_64 Jul 20 09:58:42 Updated: ibus-m17n-1.3.0-2.fc13.x86_64 Jul 20 09:58:43 Updated: 3:traceroute-2.0.15-1.fc13.x86_64 Jul 20 09:58:44 Updated: xorg-x11-xinit-1.0.9-17.fc13.x86_64 Jul 20 09:58:45 Updated: finger-0.17-41.fc13.x86_64 Jul 20 09:58:46 Updated: farsight2-0.0.20-2.fc13.x86_64 Jul 20 09:58:47 Updated: fedora-packager-0.4.2.3-1.fc13.noarch Jul 20 09:58:48 Updated: fedora-easy-karma-0-0.7.20100709git561718c8.fc13.noarch Jul 20 09:58:51 Updated: smc-meera-fonts-4.4-1.fc13.noarch Jul 20 09:58:52 Updated: fedora-kde-icon-theme-0.0.2-3.fc13.noarch Jul 20 09:58:54 Updated: telepathy-butterfly-0.5.12-1.fc13.noarch Jul 20 09:59:58 Updated: selinux-policy-targeted-3.7.19-37.fc13.noarch Jul 20 09:59:59
Re: Lost all empathy accounts after update this morning (F13)
On Tue, 2010-07-20 at 16:16 +0100, Matthew Booth wrote: When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. I can't see anything obvious in yum.log which might have caused this, hence this email rather than a BZ or some negative karma. This is obviously a serious problem which I'd like to see others avoid if it hasn't already escaped updates-testing. The only suspects I had were updates to telepathy-butterfly and telepathy-gabble, but they don't seem to run any scripts. Don't see anything relating to gconf either... Here's yum.log from this morning. Can anybody offer any guesses? A handy alternative to looking at the yum.log: yum history list then you can see the transactions by date. then: yum history info transaction id to get a lot of info on what changed. http://yum.baseurl.org/wiki/YumHistory for more info. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 612875] perl-Class-C3 FTBFS : BuildRequires Self!
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=612875 Mark Chappell trem...@tremble.org.uk changed: What|Removed |Added Status|NEW |CLOSED Resolution||NEXTRELEASE -- 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: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 05:52 AM, Hans Ulrich Niedermann wrote: On Fri, 2010-07-16 at 17:07 -0700, Jesse Keating wrote: I've been struggling with a particular wrinkle in dist-git, how fedpkg is supposed to reliably discover what Fedora release a packager is working on. In other words: How does fedpkg map the currently checked out git HEAD to a Fedora release? (Unless fedpkg is specifically given a Fedora release to build for on the command line.) That's right. In the CVS world, we used a branch file. This is OK, but I think it would be cleaner if we didn't have to rely upon that. It's the last file that wouldn't be exact across all the Fedora releases if a package is kept in sync. So what I'd like to do is rely upon discovering the top level upstream branch, say F-13. 100% Ack. This gets difficult if we allow maintainers to create and operate on their own upstream branches (which we should), as I have not found a reliable way to work from a local branch to which remote branch it tracks to which top level remote branch it was created from. Is this problem solvable at all? Every merge commit has (at least) two parents. If you have once merged the F-12 branch into the F-13 branch, how can fedpkg decide which of the parents was the real one to track back to? I don't think it is solvable, without enforcing some form of naming convention. One suggestion has been to make use of directory based branching, so that any maintainer created branch is in a subdir of a top level branch. This phrasing might be a little confusing. We are NOT talking about having different branches' files in different subdirectories on the filesystem here, like we were doing with the CVS checkouts. We are talking about branches named like directories (e.g. 'F-13/foo'). I'm going to make it slightly more confusing here, but bear with me. As far as the client is concerned and maintainer checkouts, there will not be a subdirectory. These are real git branches and you switch between them which will update your working copy. The branches would just be named with a directory like structure. Now, on the back end, the git repo server, the git metadata would actually create a F-13 directory and put things like the master and other files within that directory. Clients don't care about this, but it does make some things convenient when looking at the git repo structure. There is also a fedpkg command that will setup your git checkouts to look like it did with CVS, where you have module/devel module/F-13 module/F-12 etc... and there would be a clone/checkout in each of those subdirs from the appropriate remote branch. EG we'd a user could create an F-13/kernel-2.7 branch, and call it whatever they want locally. fedpkg would be able to work from the local branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the path from origin/ to discover F-13. Then fedpkg can assume F-13 for the branch and do all the dist conversions and koji target discovery from that. This doesn't put too much restraint on what maintainers call their branches, particularly locally. The wrinkle with the above though is the base top level branch. When we do this with directories, it's not possible to have a simple origin/F-13 branch that a user could interact with (git checkout F-13 would automatically detect that there is an origin/F-13 remote branch and setup a local F-13 branch to track it and still allow for an F-13/foobar branch. So we have to make the first base upstream branch F-13/something. One suggested something has been to call it HEAD, because git seems to have another short cut that would allow you to do git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it will automatically use that. HEAD seems to be a special name in this context. However it is pointed out that using HEAD here could be confusing to people who are more familiar with git and naming conventions. Another suggestion is to call it F-13/master since master is a more appropriate and expected name. However that means you can't use the short cut and have to do a full git checkout -b F-13 origin/F-13/master. Since you have to use the full path here, we aren't bound by the name master and we could name it anything we want, something that might make sense to Fedora or dist-git. I would call it something short and sweet and to the point. Using F-13/HEAD appears hackish, and does things one might not expect, so I would be careful with that. Whether it is called F-13/master, F-13/koji, or F-13/official, however, I don't care, as long as it is consistent over all packages. Now, these are fairly low details which can be hidden behind fedpkg (there is a proposed patch to give fedpkg a 'switch-branch' command that will switch you from one to the other, and we can make calls to F-13 attempt origin/F-13/master or whatever), but I
Re: Lost all empathy accounts after update this morning (F13)
On Tue, Jul 20, 2010 at 05:30:04PM +0100, Matthew Booth wrote: It seems empathy and everything related to it has lost the ability to execute programs. What if you setenforce 0? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-07-20)
On Mon, Jul 19, 2010 at 12:41:39PM -0600, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. I must send my regrets for todays meeting, I've got to run an errand this afternoon and I suspect I won't be back in time. I'll leave my client idling in the channel and review the logs when I get back. Apologies for the late notice, it's just come up at the last minute. regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
That said, I don't think I'd use either HEAD or master as the branch name since they both have some sort of association with how git itself works unless the name actually matches 100% with the concept that you're trying to express here. This is nothing more or less than our convention for git branch names, so the generic git conventions for branch names exactly match the concept. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
My first idea would be for fedpkg to do something similar to the following when trying to find out the target to build for: 0. If --target F-13 is given, use that as target. If not, continue. 1. Determine the current git branch ($origbranch=$curbranch). 2. Check 'git config branch.$curbranch.fedora-target'. If set, use that as target. If not, continue. 3. Check whether $curbranch starts with F-13/. If so, use F-13 as the target. If not, continue. 4. Check what branch $curbranch is tracking. If it tracks one, set curbranch to that branch and go to step 2. Otherwise, bail out and ask for --target or 'git config branch.$origbranch.fedora-target' to be set. I'd suggested something just about like this. Jesse is concerned by the fact that some local state (the .git/config file in your local repo) affects this. I think the fear is that you could easily manage to confuse yourself about what magic cookie is driving your dwim build target behavior, so another developer you're collaborating with might end up having a local git repo you both looks the same as yours, but builds pick a different target. My first suggestion was not to have the magical leading F-n/ matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. I can see both sides of Jesse's point about the extra locally-confusable magic setting here. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On Tue, Jul 20, 2010 at 04:16:04PM +0100, Matthew Booth wrote: When I booted my machine this morning and started Empathy everything was fine. I did a rather big yum update this morning (including updates-testing), and I had reason to reboot my machine this afternoon. Empathy no longer has any of my accounts in it. Recently mission control started to crash for me: https://bugzilla.redhat.com/show_bug.cgi?id=615749 -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo meeting (2010-07-20)
=== #fedora-meeting: FESCO (2010-07-20) === Meeting started by nirik at 19:30:04 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-07-20/fesco.2010-07-20-19.30.log.html Meeting summary --- * init process (nirik, 19:30:04) * kylem notting and mclasen indicated they would be unable to attend today. (nirik, 19:30:50) * ajax also unable to attend (nirik, 19:31:43) * #351 Create a policy for updates - status report on implementation (nirik, 19:34:51) * #382 Implementing Stable Release Vision (nirik, 19:36:57) * #409 Feature Request: GNUstep (nirik, 19:41:37) * LINK: https://fedoraproject.org/wiki/Talk:Features/GNUstep has some info (nirik, 19:42:38) * Feature is approved. (nirik, 19:50:24) * #423 F14Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik, 19:50:33) * will revisit later in the meeting hopefully with jlaw around. (nirik, 19:52:35) * #432 Add new FPL to fesco list (nirik, 19:52:46) * AGREED: will re-add stickster for a bit. (nirik, 19:54:42) * #439: dist-git rollout plan (nirik, 19:56:33) * LINK: http://cvs.fedoraproject.org/webfiles/ (nirik, 20:13:26) * AGREED: Go forth and GIT. Move forward at F14 branch time with a migration. (nirik, 20:21:00) * Till Maass unavailable (nirik, 20:21:39) * #431 Exception for Recoll bundling other libraries modified (nirik, 20:26:21) * AGREED: exception granted in this case. (nirik, 20:29:19) * #433 F14Feature: CryptographyInKernel - https://fedoraproject.org/wiki/Features/CryptographyInKernel (nirik, 20:29:26) * AGREED: Feature is approved. (nirik, 20:37:51) * #434 F14Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 20:38:32) * will ask questions of feature owner and revisit next week. (nirik, 20:40:57) * ACTION: mjg59 to ask for more input on this feature. (nirik, 20:43:08) * #435 F14Feature: F14EclipseHelios - https://fedoraproject.org/wiki/Features/F14EclipseHelios (nirik, 20:43:11) * AGREED: Feature is approved. (nirik, 20:45:39) * #436 F14Feature: KDE45 - https://fedoraproject.org/wiki/Features/KDE45 (nirik, 20:45:45) * AGREED: Feature is approved. (nirik, 20:47:20) * #437 F14Feature: MemoryDebuggingTools - https://fedoraproject.org/wiki/Features/MemoryDebuggingTools (nirik, 20:47:27) * AGREED: Feature is approved. (nirik, 20:49:22) * #438 F14Feature: Ruby_1.87 - https://fedoraproject.org/wiki/Features/Ruby_1.8.7 (nirik, 20:49:29) * will gather more info and revisit next week. (nirik, 20:55:15) * Open Floor (nirik, 20:56:03) * LINK: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild (dmalcolm, 20:57:15) * Python 2.7 mass rebuild (nirik, 20:57:15) * LINK: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild (dmalcolm, 20:57:19) * Open Floor (nirik, 21:14:49) Meeting ended at 21:17:10 UTC. -- 19:30:04 nirik #startmeeting FESCO (2010-07-20) 19:30:04 zodbot Meeting started Tue Jul 20 19:30:04 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:04 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:04 nirik #meetingname fesco 19:30:04 zodbot The meeting name has been set to 'fesco' 19:30:04 nirik #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:04 nirik #topic init process 19:30:04 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:10 mjg59 \o/ 19:30:50 nirik #info kylem notting and mclasen indicated they would be unable to attend today. 19:31:02 nirik so, hopefully we still have quorum. ;) 19:31:14 pjones ajax is also out 19:31:27 mjg59 Oops. 19:31:43 SMParrish I am here, but expecting a delivery soon so may have to jet for a few 19:31:43 nirik #info ajax also unable to attend 19:31:54 nirik so, we never everyone else... 19:32:14 * cwickert is sorry to be late 19:32:14 pjones we what? 19:32:22 Oxf13 hrm. those are some of the key people I wanted around for the dist-git discussion. 19:33:10 pjones so right now it's nirik, smparrish, cwickert, mjg59, and pjones? 19:33:11 nirik pjones: in order for 5 of the 9 of us to be present. 19:33:39 nirik yep. Seems we do have 5 folks. 19:33:41 cwickert nirik: I can leave again if you want me to ;) 19:34:06 pjones smparrish only counts as half, right? since he's going to be gone soon anyway? 19:34:07 Southern_Gentlem yep you barely have a quorium (under roberts rules of order) 19:34:08 nirik cwickert: would make for a shorter meeting, but please do stay. ;) 19:34:11 drago01 which means everyone has veto powers ;) 19:34:38 pjones Southern_Gentlem: we don't actually subscribe to robert's rules in any way... 19:34:42 nirik ok, lets go ahead and get started... 19:34:51 nirik #topic #351 Create a policy
[389-devel] Please Review: (adminserver) Fix perl URL parsing code to work with OpenLDAP
From 56824d9699ad2f471ac4ec30c24c0600735e42f7 Mon Sep 17 00:00:00 2001
From: Nathan Kinder nkin...@redhat.com
Date: Tue, 20 Jul 2010 14:18:00 -0700
Subject: [PATCH] Fix perl URL parsing code to work with OpenLDAP.
When using PerLDAP built against OpenLDAP, the URL parsing works
a bit differently. This patch makes the Admin Server perl code
work with PerLDAP that uses either OpenLDAP or MozLDAP under the
covers.
---
admserv/newinst/src/AdminUtil.pm.in | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/admserv/newinst/src/AdminUtil.pm.in
b/admserv/newinst/src/AdminUtil.pm.in
index d3808cc..587d408 100644
--- a/admserv/newinst/src/AdminUtil.pm.in
+++ b/admserv/newinst/src/AdminUtil.pm.in
@@ -168,7 +168,15 @@ sub getConfigDSConn {
my $host = $h-{host};
my $port = $h-{port};
my $basedn = $h-{dn};
-if ($h-{options} LDAP_URL_OPT_SECURE) {
+
+# If PerLDAP was build using OpenLDAP, we must check the URL scheme
+# to see if we're using LDAPS. If MozLDAP is being used, we need
+# to check for the secure option.
+if ($h-{scheme}) {
+if ($h-{scheme} eq ldaps) {
+$certdir = getCertDir($configdir);
+}
+} elsif ($h-{options} LDAP_URL_OPT_SECURE) {
$certdir = getCertDir($configdir);
}
--
1.6.2.5
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please Review: (adminserver) Fix perl URL parsing code to work with OpenLDAP
Nathan Kinder wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please Review: (adminserver) Fix perl URL parsing code to work with OpenLDAP
On 07/20/2010 02:27 PM, Rich Megginson wrote: Nathan Kinder wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack Thanks. Pushed to master. Counting objects: 11, done. Delta compression using 2 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 790 bytes, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/admin.git 3e3b158..56824d9 master - master -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 09:03 -0400, Toshio Kuratomi wrote: On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote: Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... I'm not around enough right now to be able to test anything :-(. I also don't really understand the choices you're presenting since they're based on git conventions that I don't know. master is just a convention in git? HEAD is treated specially but doesn't exist normally in a repository? I think the only way to do this is to implement one thing and then be willing to either change that (or let someone else contribute work to change it) once people use it and tell you ZOMG WHY [...]. Definitely this is where I stand. It's too new and different for me to have a reliable mental map of it to know what to think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 03:07 PM, Adam Williamson wrote: On Tue, 2010-07-20 at 09:03 -0400, Toshio Kuratomi wrote: On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote: Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... I'm not around enough right now to be able to test anything :-(. I also don't really understand the choices you're presenting since they're based on git conventions that I don't know. master is just a convention in git? HEAD is treated specially but doesn't exist normally in a repository? I think the only way to do this is to implement one thing and then be willing to either change that (or let someone else contribute work to change it) once people use it and tell you ZOMG WHY [...]. Definitely this is where I stand. It's too new and different for me to have a reliable mental map of it to know what to think. Thankfully it's pretty easy to move this stuff around if we need to after the conversion. It may break people's existing clones, but those are cheap. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxGH/MACgkQ4v2HLvE71NUxbgCeN3f4zmg4oyiig+f35LqzriUq YwcAnRbz4aLYDgOGtDtTyDW8IEpegQqH =5QUJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
Roland McGrath wrote: My first suggestion was not to have the magical leading F-n/ matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. +1 to this. After switching from CVS to git for my own projects over the course of the past year I am beginning to see the high value in branching with git. Linus' suggestion of using branches everywhere is something hard to grasp at first but it is the right direction. Here's one nice feature I'd like to see for a simple scenario of when upstream releases a new stable version: 1. Edit the 'master' branch spec file. 2. git commit my change. 3. git rebase my F-* branches to master. 4. Submit my builds! Keeping separate directories per release seems cumbersome and I just submitted my first package yesterday. You guys have been doing far too much work with the current method of package upkeep. :P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage: Updates - 2010-07-21 16:00 UTC
There will be an outage starting at 2010-07-21 16:00 UTC, which will last approximately 3 hours. Outages will be small but noticeable for small segments as systems are updated and rebooted. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-07-21 16:00 UTC' Reason for outage: Updates to xen and other critical packages require rebooting servers to take effect. Affected Services: BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ CVS / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2280 Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -- 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: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 03:32 PM, Michael Cronenworth wrote: Roland McGrath wrote: My first suggestion was not to have the magical leading F-n/ matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. +1 to this. After switching from CVS to git for my own projects over the course of the past year I am beginning to see the high value in branching with git. Linus' suggestion of using branches everywhere is something hard to grasp at first but it is the right direction. Here's one nice feature I'd like to see for a simple scenario of when upstream releases a new stable version: 1. Edit the 'master' branch spec file. 2. git commit my change. 3. git rebase my F-* branches to master. 4. Submit my builds! Keeping separate directories per release seems cumbersome and I just submitted my first package yesterday. You guys have been doing far too much work with the current method of package upkeep. :P I think you've misunderstood the proposal. There won't be separate directories per release, just separate branches. The branch names will look like they have directory structure though, which will help programatically detect the Fedora target. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxGKrUACgkQ4v2HLvE71NXRAQCfaNvQ78C3OKvp8uSd/uX+Uu1r wT4An2KH7XmN/QVTBxG1GTGhcbgkbjZM =FpZ/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I am not available
Hello all, Sundarammethe...@gmail.com wrote: It is all listed at https://fedoraproject.org/wiki/TillMaas Despite I'm don't have sponsorship yet, I'd like to help as much as I can. If it is possible, I'd like to be co-maintainer of some packages of yours. Regards and I hope you get well very soon Till! Rafael Aquini -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Partial mass rebuild for Python 2.7 coming soon (I hope)
I'm planning to do a partial mass-rebuild for Python 2.7. This would cover all Python 2 users within the distribution, roughly 1000 src.rpms. Some notes can be seen at: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild I hoped to start this tomorrow (2010-07-21) at 16:00 UTC, but it looks like I need to wait until at least after the outage that's due for that time [1]. Further, I'm still waiting to hear back to see if the build should be done with the gold linker, rather than gnu-ld [2]. I will delay the build until after a decision is made on this. This may mean that I'll wait until 2010-07-22. Some areas of uncertainty remain: - the script to do this, as written, assumes no build ordering is needed. I know that some ordering is needed, and plan to manually order the first four builds which I hope is the bulk of it, but it's not clear to me if more is needed; I'm running some tests to try to better determine this. Hope this makes sense Dave [1] https://fedorahosted.org/fedora-infrastructure/ticket/2280 [2] https://fedoraproject.org/wiki/Features/GoldLinkerDefault -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 17:32 -0500, Michael Cronenworth wrote: Here's one nice feature I'd like to see for a simple scenario of when upstream releases a new stable version: 1. Edit the 'master' branch spec file. 2. git commit my change. 3. git rebase my F-* branches to master. 4. Submit my builds! Uhm. Rebase, i.e. rewriting branch history, and requiring a git push -f to force non-fast-forward merging of the public branches? Is that really a good idea? I would have presumed something like (using pseudo names for the branches) F-13 --o-m / master O \ F-12 -o--m if you are keeping F-12 and F-13 in sync or devel ---O \ F-13 -m \ F-12 ---m if you are keeping all three branches devel, F-13, F-12 in sync. A subsequent push (without -f) of the F-13 and F-12 (and devel in the second case) branches and a build request would conclude the process. BTW, while typing the above, I have noted that master or devel or f13 are quite easy to type, while F-13 with capital letter and hyphen is relatively complicated. Perhaps that could be an argument when choosing branch names. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Partial mass rebuild for Python 2.7 coming soon (I hope)
On Tue, Jul 20, 2010 at 4:02 PM, David Malcolm dmalc...@redhat.com wrote: I'm planning to do a partial mass-rebuild for Python 2.7. Please, when you hit build failures, and you will if you can provide a link to a failure report that is easily searchable(if not sorted by) primary package owner. That will help me,help you, do any clean up for packages I have some modicum of clue about and feel accountable for. Good luck. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 14, 2010 at 2:50 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote: Perhaps someone could put together a wiki page for lazy sysadmins with a QA? ie, I used to do this in upstart/sysvinit, how do I do it with systemd? Jóhann Guðmundsson (viking_ice) has been working on something along these lines: http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd it was mentioned in the QA meeting a few weeks back. I have a few requests for things to add to that page :-) * What replaces chkconfig * What replaces /etc/init.d/SERVICENAME start | stop ? Similarly, for packaging guidelines updates, how do we install packages that provide services and have them not start up? -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, Jul 20, 2010 at 9:54 AM, Christof Damian chris...@damian.net wrote: On Tue, Jul 20, 2010 at 00:33, Roland McGrath rol...@redhat.com wrote: My opinion is that a branch called F-n/master is the nicest thing. Actually, all else being equal, I'd probably go for it being called fn/master, since gratuitous caps and punctuation in branch names is not a normal git convention. (But I only really care about the structure of the names, not the spelling.) same here. I also prefer lower case. (package names and dist tags are lower-case too). +1 for lower-case branch names without punctuation. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
BTW, while typing the above, I have noted that master or devel or
f13 are quite easy to type, while F-13 with capital letter and
hyphen is relatively complicated. Perhaps that could be an argument when
choosing branch names.
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
If rawhide development is supposed to happen on origin/master, then how
do branches for rawhide work? Does fedpkg just default to building for
rawhide when a branch doesn't appear in a release's branch namespace?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Reminder: Fedora 14 Feature Freeze is Next Week (2010-07-27)
It's hard to believe, but the window for full blown feature development closes soon. A friendly reminder that next Tuesday, July 27, 2010 is Feature Freeze for Fedora 14. Feature Freeze means that all accepted feature for the release are *significantly* feature complete, ready for testing, and have a current status. https://fedoraproject.org/wiki/Feature_Freeze_Policy. https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze If you have any questions about what this means, please ask now. Features which are not significantly feature complete at Feature Freeze will be be allowed to remain on an exception basis by FESCo or deferred to Fedora 15. Thank you, John ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, Jul 20, 2010 at 12:54 PM, Fernando Lopez-Lezcano wrote: On Tue, 2010-07-20 at 10:04 -0400, Orcan Ogetbil wrote: On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote: question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. I thought about doing that once. Jack1's and jack2's source codes are distributed on the same website [1], We know that JACK stands for Jack-Audio-Connection-Kit. So there shouldn't be any confusion. jack-audio-connection-kit is the official name of the project and it has been the suggested name for packages. Yes. Therefore I think we are safe from the guidelines' point of view: When naming a package, the name should match the upstream tarball or project name from which this software came. from http://fedoraproject.org/wiki/PackageNamingGuidelines#General_Naming Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
BTW, while typing the above, I have noted that master or devel or
f13 are quite easy to type, while F-13 with capital letter and
hyphen is relatively complicated. Perhaps that could be an argument when
choosing branch names.
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
If rawhide development is supposed to happen on origin/master, then how
do branches for rawhide work? Does fedpkg just default to building for
rawhide when a branch doesn't appear in a release's branch namespace?
Yes. Branches of rawhide would be of the form origin/branch so if we
don't find one of our expected f(c)??,el?,olpc? we default to building
for rawhide.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxGgokACgkQ4v2HLvE71NV8WwCfcVOK9lNRJwb+RQJC22Ngixk3
Oa0AoMVsIdKMM3xqw28UwibrivN5Fy9z
=hKZP
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
2010/7/20 Andy Shevchenko andy.shevche...@gmail.com: On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. -- With Best Regards, Andy Shevchenko -- Package name jack conflicts with some other opensource softwares, it'll better to persuade jack-audio-connection-kit upstream to avoid of using jack as package name. FYI, debian use jackd2 as package name for jack-audio-connection-kit 2. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
dist-git wordsmithing wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It was suggested to keep the Makefile that exists in every package module/branch in CVS right now, but set it up so that any Make command issued would print a reminder to the user that the Make system has been retired and to use fedpkg. I could use some word smithing on this message. What I have right now is this: $ make tag Make system retired, please use fedpkg. See fedpkg --help Suggestions on what to put in here? - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxGh8QACgkQ4v2HLvE71NX/XwCfboto3bl8DxzSuVMH6HaSUhja j1gAnRoBJAjTZhIN5i7JDwxBdo/3UYb1 =cWMe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
On Tue, 2010-07-20 at 22:38 -0700, Jesse Keating wrote: $ make tag Make system retired, please use fedpkg. See fedpkg --help Suggestions on what to put in here? Might be nice to already print the equivalent command: $ make tag Make system retired, please use fedpkg. The equivalent function is: For more information see fedpkg --help But that might be a bit long though. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Class-Autouse/devel perl-Class-Autouse.spec,1.19,1.20
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Class-Autouse/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv18031
Modified Files:
perl-Class-Autouse.spec
Log Message:
* Tue Jul 20 2010 Ralf Corsépius corse...@fedoraproject.org - 1.29-9
- Reenable pmv test.
Index: perl-Class-Autouse.spec
===
RCS file: /cvs/pkgs/rpms/perl-Class-Autouse/devel/perl-Class-Autouse.spec,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- perl-Class-Autouse.spec 5 May 2010 11:17:18 - 1.19
+++ perl-Class-Autouse.spec 20 Jul 2010 06:49:58 - 1.20
@@ -1,6 +1,6 @@
Name: perl-Class-Autouse
Version: 1.29
-Release: 8%{?dist}
+Release: 9%{?dist}
Summary: Run-time class loading on first method call
License: GPL+ or Artistic
Group: Development/Libraries
@@ -49,8 +49,6 @@ chmod -R u+w $RPM_BUILD_ROOT/*
rm -rf $RPM_BUILD_ROOT
%check
-# remove until fix of Perl::MinimalVersion and version.pm
-rm -rf t/99_pmv.t
make test AUTOMATED_TESTING=1
%files
@@ -60,6 +58,9 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Tue Jul 20 2010 Ralf Corsépius corse...@fedoraproject.org - 1.29-9
+- Reenable pmv test.
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.29-8
- Mass rebuild with perl-5.12.0
--
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 Set-IntSpan-1.14.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Set-IntSpan: 700bdabd4343cc1dd29fde70ecbd18e2 Set-IntSpan-1.14.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
rpms/perl-Set-IntSpan/devel .cvsignore, 1.8, 1.9 perl-Set-IntSpan.spec, 1.19, 1.20 sources, 1.8, 1.9
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Set-IntSpan/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21927
Modified Files:
.cvsignore perl-Set-IntSpan.spec sources
Log Message:
* Tue Jul 20 2010 Ralf Corsépius rc040...@freenet.de - 1.14.1
- Upstream update.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Set-IntSpan/devel/.cvsignore,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- .cvsignore 31 Oct 2007 03:38:37 - 1.8
+++ .cvsignore 20 Jul 2010 07:09:52 - 1.9
@@ -1 +1 @@
-Set-IntSpan-1.13.tar.gz
+Set-IntSpan-1.14.tar.gz
Index: perl-Set-IntSpan.spec
===
RCS file: /cvs/pkgs/rpms/perl-Set-IntSpan/devel/perl-Set-IntSpan.spec,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- perl-Set-IntSpan.spec 6 May 2010 11:52:49 - 1.19
+++ perl-Set-IntSpan.spec 20 Jul 2010 07:09:52 - 1.20
@@ -1,6 +1,6 @@
Name: perl-Set-IntSpan
-Version:1.13
-Release:6%{?dist}
+Version:1.14
+Release:1%{?dist}
Summary:Perl module for managing sets of integers
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Jul 20 2010 Ralf Corsépius rc040...@freenet.de - 1.14.1
+- Upstream update.
+
* Thu May 06 2010 Marcela Maslanova mmasl...@redhat.com - 1.13-6
- Mass rebuild with perl-5.12.0
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Set-IntSpan/devel/sources,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- sources 31 Oct 2007 03:38:37 - 1.8
+++ sources 20 Jul 2010 07:09:52 - 1.9
@@ -1 +1 @@
-c1633328e9bfece889abe0949992ce04 Set-IntSpan-1.13.tar.gz
+700bdabd4343cc1dd29fde70ecbd18e2 Set-IntSpan-1.14.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: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) 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-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) 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-DBI-Dumper
perl-DBI-Dumper has broken dependencies in the rawhide tree: On x86_64: perl-DBI-Dumper-2.01-8.fc12.x86_64 requires perl(:MODULE_COMPAT_5.10.0) On i386: perl-DBI-Dumper-2.01-8.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0) 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 616626] New: python-pip pkg conflict with perl-pip
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: python-pip pkg conflict with perl-pip https://bugzilla.redhat.com/show_bug.cgi?id=616626 Summary: python-pip pkg conflict with perl-pip Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-pip AssignedTo: mmasl...@redhat.com ReportedBy: asto...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, phalli...@excelsiorsystems.net Depends on: 616399 Classification: Fedora Target Release: --- Clone Of: 616399 +++ This bug was initially created as a clone of Bug #616399 +++ Description of problem: Attempting to do a wildcard install of both python and perl packages results a file conflict for both python-pip and perl-pip Version-Release number of selected component (if applicable): python-pip 0.6.3-1 perl-pip 1.16-1 How reproducible: 100% Steps to Reproduce: 1. yum install python* perl* 2. 3. Actual results: Running Transaction Test Transaction Check Error: file /usr/bin/pip conflicts between attempted installs of python-pip-0.6.3-1.fc13.noarch and perl-pip-1.16-1.fc13.noarch Expected results: No conflicts Additional info: --- Additional comment from phalli...@excelsiorsystems.net on 2010-07-20 14:26:35 EDT --- Well, I think the Debian approach (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551926) should be done here. Both packages should have to rename their /usr/bin/pip. Something like /usr/bin/pip-perl and /usr/bin/pip-python. That way completion will work at least. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
